Kubernetes/6.Pod资源管理
1.标签
标签是“键值”类型的数据,它们可于资源创建时直接指定,也可随时按需添加,而后即可由标签选择器进行匹配度检查从而完成资源的挑选。
你需要注意:
- 一个对象可拥有不止一个标签,而同一个标签也可被添加至多个资源之上;
- 我们可以为资源附加多个不同纬度的标签以实现灵活的资源分组管理功能,例如版本标签、环境标签等,用于交叉标识同一个资源所属的不同版本和环境。
2.标签选择器
标签选择器用于表达标签的查询条件或选择标准,支持两种选择器:
1.基于等值关系
=、==和!=三种
2.基于集合关系
in、not in等
下面我补充来一个基于label的查询常用命令:
#label的帮助命令查询 kubectl label -h #基于label的相关查询命令 [root@centos-1 dingqishi]# kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS ngx-new-cb79d555-gqwf8 1/1 Running 0 4h57m app=ngx-new,pod-template-hash=cb79d555 ngx-new-cb79d555-hcdr9 1/1 Running 0 5h9m app=ngx-new,pod-template-hash=cb79d555 [root@centos-1 dingqishi]# kubectl get pod --show-labels -A -l app=flannel NAMESPACE NAME READY STATUS RESTARTS AGE LABELS kube-system kube-flannel-ds-amd64-bc56m 1/1 Running 7 2d23h app=flannel,controller-revision-hash=67f65bfbc7,pod-template-generation=1,tier=node kube-system kube-flannel-ds-amd64-ltp9p 1/1 Running 0 2d23h app=flannel,controller-revision-hash=67f65bfbc7,pod-template-generation=1,tier=node kube-system kube-flannel-ds-amd64-v9gmq 1/1 Running 10 2d23h app=flannel,controller-revision-hash=67f65bfbc7,pod-template-generation=1,tier=node [root@centos-1 dingqishi]# kubectl get pod -A -l app=flannel -L app NAMESPACE NAME READY STATUS RESTARTS AGE APP kube-system kube-flannel-ds-amd64-bc56m 1/1 Running 7 2d23h flannel kube-system kube-flannel-ds-amd64-ltp9p 1/1 Running 0 2d23h flannel kube-system kube-flannel-ds-amd64-v9gmq 1/1 Running 10 2d23h flannel
3.资源注解(annotation)
不受字符数量的限制,你需要注意和区分的是,资源注解不用用于标签的筛选,仅用于为资源提供“元数据”信息
#资源注解的帮助命令查询 kubectl annotate -h
4.探针
探针是Pod容器声明周期中健康与否至关重要的一步的相关组件。
1.liveness
健康状态检查,用于检测Pod的健康性,后续的动作会重启
Pod
1) 你可以使用explain查询到liveness探针的字段配置说明(这个很有用!)
kubectl explain pods.spec.containers.livenessProbe
2) 我们编辑
liveness-exec.yaml,里面会增加一个livenessProbe,用于探测/tmp/healthy文件是否存在,然后使用
apply -f命令,生成该Pod
apiVersion: v1 kind: Pod metadata: labels: test: liveness-exec name: liveness-exec spec: containers: - name: liveness-demo image: busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: - test - -e - /tmp/healthy
3) 观察
pod情况,发现30秒之内,
pod探测不到
/tmp/healthy文件,并进行了重启操作,
RESTARTS为1
[root@centos-1 chapter4]# kubectl get pods NAME READY STATUS RESTARTS AGE liveness-exec 1/1 Running 1 2m39s ngx-new-cb79d555-gqwf8 1/1 Running 0 2d2h ngx-new-cb79d555-hcdr9 1/1 Running 0 2d2h describe pod liveness-exec State: Running Started: Sat, 30 Nov 2019 14:17:31 +0800 Last State: Terminated Reason: Error Exit Code: 137 Started: Sat, 30 Nov 2019 14:16:03 +0800 Finished: Sat, 30 Nov 2019 14:17:25 +0800 Ready: True Restart Count: 1 Liveness: exec [test -e /tmp/healthy] delay=0s timeout=1s period=10s #success=1 #failure=3
4) 同理可使用本页的liveness-http.yaml,进行学习和实践,相关配置清单我已经提供好了。
你只需要:1.先读懂yaml清单 2.apply测试即可
2.readiness
就绪状态检查,没有重启Pod权利,用于为Service流量分发作为依据
1) 你可以使用explain查询到readiness探针的字段配置说明(这个很有用!)
kubectl explain pods.spec.containers.readinessProbe
2) 编辑
readiness-exec.yaml,并使用
apply -f生成
Pod。这里我们增加
readiness探针,用于测试
/tmp/ready文件是否存在,该探针第一次探测为第五秒开始,探测周期为5秒
apiVersion: v1 kind: Pod metadata: labels: test: readiness-exec name: readiness-exec spec: containers: - name: readiness-demo image: busybox args: ["/bin/sh", "-c", "while true; do rm -f /tmp/ready; sleep 30; touch /tmp/ready; sleep 300; done"] readinessProbe: exec: command: ["test", "-e", "/tmp/ready"] initialDelaySeconds: 5 periodSeconds: 5
3) 观察发现,
readiness-exec启动后并没有直接进入就绪状态,而是探测到有
/tmp/ready文件后,才变成1/1
readiness-exec 0/1 Pending 0 0s <none> <none> <none> <none> readiness-exec 0/1 Pending 0 0s <none> centos-2.shared <none> <none> readiness-exec 0/1 ContainerCreating 0 0s <none> centos-2.shared <none> <none> readiness-exec 0/1 Running 0 11s 10.244.1.34 centos-2.shared <none> <none> readiness-exec 1/1 Running 0 43s 10.244.1.34 centos-2.shared <none> <none>
5.Pod对象的相位
Pod一共有5个状态,分为
Pending、
Running、
Succeeded、
Failed和
Unknown,其中:
Pending: Pod未完成调度,通常由于没有符合调度需求的node节点 Running: Pod已经调度成功,且已经被kubelet创建完成 Succeeded: Pod中的所有容器已经成功且不会被重启 Failed: Pod中至少有一个容器终止失败 Unknown: Apiserver无法获取Pod对象的状态信息,通常由于其无法与所在工作节点的kubelet通信导致
6.Pod Security
Pod对象的安全上下文用于设定Pod或容器的权限和访问控制功能,其支持设置的常用属性包括以下几个方面:
1)基于用户ID(UID)和组ID(GID)控制访问对象(如文件)时的权限 2)以特权或非特权的方式运行 3)通过Linux Capabilities为其提供部分特权 4)基于Seccomp过滤进程的系统调用 5)基于SELinux的安全标签 6)是否能够进行权限升级
其中包括2个安全级别:
两个级别: kubectl explain pod.spec.securityContext kubectl explain pod.spec.containers.[].securityContext.capabilities
最后,看一个配置清单:以
uid为1000的非特权用户运行
busybox容器,并禁止权限升级
apiVersion: v1 kind: Pod metadata: name: pod-with-securitycontext spec: containers: - name: busybox image: busybox command: ["/bin/sh","-c","sleep 86400"] securityContext: runAsNonRoot: true runAsUser: 1000 allowPrivilegeEscalation: false
测试如下:
[root@centos-1 ~]# kubectl exec -it pod-with-securitycontext -- /bin/sh / $ ps -ef|grep busy 25 1000 0:00 grep busy / $ mkdir 1 mkdir: can't create directory '1': Permission denied
7.Pod资源配额
1) 资源配合的配置文档查询
kubectl explain pod.spec.containers.resources
2) 参数说明
limits: 上限配额,最多吃的资源量 requests: 下限要求,低于下限,pod会启动失败
3)
OOM系统级别常出现的情况
节点内存太少 limits限制的太小
4) 资源配额
demo
apiVersion: v1 kind: Pod metadata: name: stress-pod spec: containers: - name: stress image: ikubernetes/stress-ng command: ["/usr/bin/stress-ng", "-c 1", "-m 1", "--metrics-brief"] resources: requests: memory: "128Mi" cpu: "200m" limits: memory: "512Mi" cpu: "400m"
8.Pod服务质量类别( QoS Class)
kubectl describe pod可查看对应的服务质量类别,共有以下三类:
1.Guaranteed
Guaranteed: 必须保证,requests和limits都有设置,且都相等,最高优先级
2.Burstable
Burstable: 尽量满足,requests或limits有一个设置了,中等优先级
3.BestEffort
BestEffort: 未设置requests或limits属性的pod资源,优先级最低
9.Pod中断预算
PDB(PodDisruptionBudget)中断预算由
k8s1.4版本引入,用于为那些自愿的中断做好预算方案,
限制可自愿中断的最大Pod副本数量或确保最少可用的
Pod副本数,以确保服务的高可用性。
1) 配置字段的查询命令
kubectl get pdb
2)
demo参考
apiVersion: policy/v1beta1 kind: PodDisruptionBudget metadata: name: ngx-new spec: minAvailable: 1 selector: matchLabels: app: ngx-new
1.非自愿中断
由不可控的外界因素所导致的Pod中断退出操作,例如:硬件或系统故障、网络故障、节点故障等
2.自愿中断
由用户特地执行的管理操作导致的Pod中断,例如:排空节点、人为删除Pod对象等
10.备注
本文原址位于我的Github,我会陆续将所有专题更新过来,其中包括docker、k8s、ceph、istio和prometheus,旨在分享云原生中大而全的技术知识点和实操过程,如果对你有用,请follow、star我的github,这也是我更新、分享下去的动力,谢谢~
- 项目管理(九)- 组织项目资源
- 操作系统如何管理CPU资源?细说操作系统进程与多任务模型问题
- kubernetes搭建 十一、Pod管理、资源限制、健康检查
- koa2 - 项目构建 - [router路由,swig模板,转换, 资源管理 ]
- 无法获得锁 /var/lib/dpkg/lock - open (11: 资源暂时不可用) 无法锁定管理目录(/var/lib/dpkg/),是否有其他进程正占用它?
- Centos常用的进程管理和资源查看工具
- 39套JAVAEE架构视频资源,springboot,springcloud微服务,ssm电商项目,分布式权限管理
- Netsharp快速入门(之10) 销售管理(插件、资源、业务建模)
- Android资源管理框架(Asset Manager)简要介绍和学习计划
- [开源发布]SVN资源权限管理系统-安全流畅极简可靠
- 简单的权限管理-资源,角色,用户,部门(一)
- QT实现CSDN上传资源管理助手Demo之(4)请求网络图片SVG并显示
- CI 中 资源管理解决方案
- 条款13 以对象管理资源
- Phalcon资源文件管理(Assets Management)
- 如何写出高效C++(资源管理)
- RAII惯用法:C++资源管理的利器
- 开发管理 CheckLists(9) -组织项目资源
- 使用RAII技术来管理资源
- 软件包管理 之 Fedora Extras(Fedora 计划的扩充资源) rpm.livna.org软件仓库的介绍和应用