第七课 Kubernetes生产级实践-k8s几个重要的资源对象
tags:
- k8s
- 慕课网
categories:
- NameSpace
- Resource
- Label
文章目录
第一节 NameSpace
1.1 NameSpace介绍
- 资源对象的隔离： Service、Deployment、Pod
- 资源配额的隔离： Cpu、Memory
# 获取命名空间 默认第一个是default
kubectl get namespaces
# 获取命名空间下的pod
kubectl get pods -n default
# 创建一个命名空间 名字为dev namespace-dev.yaml
# 获取代码地址: https://gitee.com/qnhyn/deep-in-kubernetes
apiVersion: v1
kind: Namespace
metadata:
name: dev
kubectl create -f namespace-dev.yaml
# 在创建的dev中干点事 web-dev.yaml
# 和之前的web.yaml只有命名空间不同
vimdiff web-dev.yaml ~/web.yaml
kubectl create -f web-dev.yaml
kubectl kubectl get pods -n dev
# 获取dev下所有资源
kubectl get all -n dev
1.2 NameSpace作用和使用
- 测试命名空间的隔离性。
- pod ip和service ip不受到命名空间的阻碍，在k8s中Pod都可以访问
- Service Name 会收到命名空间的阻碍
kubectl exec -it k8s-web-demo1-b4b7b6445-dzhqp bash
ping tomcat-demo
cat /etc/resolv.conf
- 减少开发人员麻烦，让开发人员只能访问dev下的资源。让他们在运行命令时不需要加上-n的参数。还记得之前搭建集群时生成kubectl的配置文件的步骤，用来给kubectl访问api server使用的。
- 从下面的用户开始，赋给不同的权限，这里不做
- 这里把admin的权限增加 一个dev，更新/root/.kube/config
cp .kube/config .kube/config.backup
# 设置上下文参数 会直接写入/root/.kube/config
kubectl config set-context ctx-dev \
--cluster=kubernetes \
--user=admin \
--namespace=dev \
--kubeconfig=/root/.kube/config
# 设置默认上下文
kubectl config use-context ctx-dev --kubeconfig=/root/.kube/config
# 完成后 默认只看到dev下的pod
kubectl get all
# 还原回去
rm -rf .kube/config
mv .kube/config.backup .kube/config
1.3 NameSpace划分方式
- 按环境划分：dev、test
- 按团队划分
- 自定义多级划分
第二节 Resources
2.1 Resources介绍
- Resources包括：CPU、GPU、内存、持久化储存
- k8s集群中kubelet服务收集节点的信息上报给Api Server。
- 核心设计：
- Requests: 表示容器希望被分配的可以完全保证的量
- Limits: 表示容器可以使用容器资源的上限
- 单位不能忘。不加单位默认为字节数。内存Mi或Gi。1核心cpu=1000m
resources:
requests:
memory: 100Mi
cpu: 100m
limits:
memory: 100Mi
cpu: 200m
# 比较下代码中不同部分
vimdiff web-dev.yaml ~/web.yaml
kubectl apply -f web-dev.yaml
# 查看节点的资源
kubectl get nodes
kubectl describe node s1
# 修改后直接应用 自动更新
kubectl apply -f web-dev.yaml
# 到容器运行的节点 查看具体的容器参数
docker inspect
# 设置参数CpuShares 就是k8s穿过来的 0.1 * 1024 它是docker中的相对权重，存在资源竞争时。按照相对比例分配
# Limits设置内存参数Memory: 100 *1024
# Limits设置参数CpuPeriod: 100 * 1000 它和cpuQuta0.2 * 100000 一块使用表示在100毫秒内最多分配给容器的cpu的量。
2.2 Resources测试
- limits下如果内存设置过大，不会影响运行。超过内存容器会自动帮我们kill最耗内存的进程。
- limits下如果CPU设置过大，不会影响运行。超过后会cpu利用最大到达设置点，因为cpu是可压缩资源。可以达到400%使用率
- Requests如果设置过大，节点不能满足。那就一直处于挂载状态。
- 测试超过最大内存
# 进入到容器中 写一个吃内存的脚本
docker exec -it 82f3a9b677fb bash
# 写个shell
#!/bin/bash
str="fajslfja;fadfsasdlfdsa"
while [ TRUE ]
do
str="$str$str"
echo "扩大两倍"
sleep 0.1
done
# 发现跑了一会 自己killed了
# 容器并不会退出，所以容器会把占用最大 内存的进程kill 而不一定重启容器
- 测试超过最大cpu
# 用一个窗口观察
docker stats 82f3a9b677fb
# 用dd 命令模拟 cpu的占用 最多不会超过limits设置的值
dd if=/dev/zero of=/dev/null &
dd if=/dev/zero of=/dev/null &
dd if=/dev/zero of=/dev/null &
dd if=/dev/zero of=/dev/null &
2.3 Requests & Limits设置
- 如果设置Requests==Limits，服务是最可靠的，最稳定的。用于重要服务。
- 如果Requests & Limits都没设置，服务是最不可靠的，没有资源最先干掉的就是你
- 如果Limits > Requests, 是一个比较可靠的服务。按照优先级压缩资源。
- 为了防止不合理或错误的限制被设置，k8s提出了LimitRange资源。
# LimitRange资源模板 maxLimitRequestRatio Limit 除以 Request 不能大于
vi limits-test.yaml
# 创建一个命名空间
kubectl create ns test
# 上面资源限制模板针对namespace 所以创建时需要指定ns
kubectl create -f limits-test.yaml -n test
# 查看ns下资源限制配置
kubectl describe limits -n test
# 创建test下资源查看
kubectl apply -f web-test.yaml
kubectl get deploy -n test
# 查看deployment详细信息 这里没有默认值
kubectl get deploy -n test web-demo -o yaml
# 查看pod的详细信息 默认值加在pod上 出现默认配置
kubectl get pods -n test
kubectl get pods -n test -o yaml
# 修改比例不正确 测试一下 默认不更新查看具体信息有个message错误事件 被阻止了
# 修改cpu或内存过大 默认不更新查看具体信息有个message错误事件 被阻止了
2.4 资源配额ResourceQuota
- 为了保证资源合理分配到不同的团队手中。不能有的团队有，有的没有
# 资源配额 compute-resource.yaml
# pod最多有四个 cpu memory限制
vi compute-resource.yaml
# 还可以对其他的进行限制 object-count.yaml
# 命名空间下最多可以有configmaps有10个 最多4个pvc 还有一些资源的限制
vi object-count.yaml
kubectl apply -f compute-resource.yaml -n test
kubectl apply -f object-count.yaml -n test
# 查看资源对象
kubectl get quota -n test
kubectl describe quota resource-quota -n test
# 修改web-test.yaml 副本为5测试一下 发现只给启动四个实例
kubectl apply -f web-test.yaml
kubectl get deploy -n test
2.5 Pod驱逐策略-Eviction
- 上面资源限制和资源配额是否能达到万无一失的效果。no
- 如果节点不停的调度服务，最终很有可能有些节点达到饱和。linux内核就会去杀进程，最终可能终结掉我们的dockerd进程。
- k8s引入Eviction调整驱逐策略。
- 常见驱逐策略配置
# 软阈值 soft不是一旦发现就驱逐 而是有个一时间
--eviction-soft=memory.available<1.5Gi
# 时间设置
--eviction-soft-grace-period=memory.available=1m30s
# 当这些条件满足时立刻开始驱逐 hard
--eviction-hard=memory.available<100Mi,
nodefs.available<1Gi,nodefs.inodesFree<5%
- 磁盘紧缺。按下面顺序清理资源
- 删除死掉的pod、容器
- 删除没用的镜像
- 按优先级、资源占用情况驱逐pod
- 内存紧缺
- 驱逐不可靠的pod
- 驱逐基本可靠的pod
- 驱逐可靠的pod
第三节 Label
3.1 Label介绍
- Label的本质就是key:value
- 它可以贴在各种资源上。如Pod, Deployment, Service, Node
- 一个标签可以贴在多个资源上，一个资源也可以有多个标签。
kubectl apply -f web-dev.yaml
kubectl get deploy -n dev
# 修改matchLabels值和labels不匹配 运行出错
# 修改metadata.name web-demo-new 运行没问题
kubectl apply -f web-dev.yaml
kubectl get deploy -n dev
# 修改一个的index.html
kubectl exec -it web-demo-7bb64c74cd-kqh9g -n dev bash
cd webapps/examples
echo "hello world" > index.html
# 访问这个 刷新发现 有一个轮询 可以用来做 不同版本
http://web-dev.mooc.com/examples/index.html
3.2 Label使用
- 除了相等操作还有一些范围操作。
spec:
selector:
matchLabels:
app: web-demo
# 和上面配合操作
matchExpressions:
- {key: group, operator: In, values: [dev, test]}
replicas: 1
template:
metadata:
labels:
# 这里也要配置
group: dev
app: web-demo
- 有个PodPreset预设，可以把spec交给开发维护，把上面交给运维进行维护。然后以某中方式组合在一起，然后可以用。
# 直接执行会报错 The Deployment "web-demo" is invalid: spec.selector
kubectl delete -f web-dev.yaml
kubectl create -f web-dev.yaml
# 通过命令使用label -l
kubectl get pods -l group=dev -n dev
kubectl get pods -l app=web-demo -n dev
# 多条件 并且
kubectl get pods -l app=web-demo,group=dev -n dev
kubectl get pods -l 'group in (dev, test)' -n dev
kubectl get pods -l 'group notin (dev, test)' -n dev
- 选择节点。disktype: ssd
spec:
containers:
- name: web-demo
image: 192.168.242.130/k8s/web:v1
ports:
- containerPort: 8080
nodeSelector:
disktype: ssd
# 应用一下
kubectl apply -f web-dev.yaml -n dev
# 发现没有节点可以挂载
kubectl describe pod web-demo-1-7f47db8d5d-q8xfz -n dev
# 给节点打标签
kubectl label node s2 disktype=ssd
kubectl get nodes --show-labels
# 返现已经启动
kubectl get pods -n dev -o wide
866
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
