6.实践篇：Pod进阶之不为人知的九大细节
本章节将多以文字描述的形式，讲述Pod资源管理中的9大基础部分，可能会比较枯燥，请各位备好肥宅快乐水！那么，我们开始吧！
1.标签
标签是“键值”类型的数据，它们可于资源创建时直接指定，也可随时按需添加，而后即可由标签选择器进行匹配度检查，从而完成资源的挑选。
你需要注意：
1>一个对象可拥有不止一个标签，而同一个标签也可被添加至多个资源之上;
2>我们可以为资源附加多个不同纬度的标签以实现灵活的资源分组管理功能，例如版本标签、环境标签等，用于交叉标识同一个资源所属的不同版本和环境。
2.标签选择器
标签选择器用于表达标签的查询条件或选择标准，支持两种选择器：
1.基于等值关系 =、==和!=三种
2.基于集合关系 in、not in等
下面我补充来一个基于label的查询常用命令：
#label的帮助命令查询 kubectl label -h #基于label的pod查询命令，你可以看到每个pod的标签说明 [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 #筛选标签为app=flannel的pod [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容器生命周期中健康与否至关重要的一步的相关组件。
4.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 dingqishi]# 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的状态，这对于定位报错很有用！ kubectl 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) 同理可以使用以下yaml进行强化学习和实践，相关配置清单我已经提供好了。
apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-http spec: containers: - name: liveness-demo image: nginx:1.12-alpine ports: - name: http containerPort: 80 lifecycle: postStart: exec: command: - /bin/sh - -c - 'echo Healty > /usr/share/nginx/html/healthz' livenessProbe: httpGet: path: /healthz port: http #上面定义的变量，值为80 scheme: HTTP periodSeconds: 2 #检测频率，2秒检查1次 failureThreshold: 2 #检查失败次数，2次失败才认为失败 initialDelaySeconds: 3 #延迟检查时间，如tomcat初始化需要有一定时间，就需要用到这个参数 timeoutSeconds: 2 #超时时间为2秒
4.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内存溢出的情况，在kubernetes中往往是以下两点问题引起的：
节点内存太少 limits限制的太小
4) 资源配额demo，相信你可以很简单的看懂并测试
apiVersion: v1 kind: Pod metadata: name: stress-pod spec: containers: - name: stress image: registry.cn-hangzhou.aliyuncs.com/aaron89/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）
kubernetes语境中会根据用户是否配置了pod资源配额来分别定义对应pod资源的重要程度。
共有以下三类：（可通过kubectl describe pod可查看对应pod资源的服务质量类别）
1.Guaranteed
Guaranteed: 必须保证，requests和limits字段都有设置，且都相等，最高优先级
2.Burstable
Burstable: 尽量满足，requests或limits字段有一个设置了，中等优先级
3.BestEffort
BestEffort: 尽最大努力，未设置requests或limits字段属性的pod资源，优先级最低
Qos优先级定义的引入是十分有用的，当我们计算资源变动且出现不足情况的时候，就需要剔除pod资源，kubernetes就会先下线BestEffort级别的资源，从而保证核心业务(Guaranteed级别)的稳定性。
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对象等
@版权声明：51CTO独家出品，未经允许不能转载，否则追究法律责任