6.实践篇：Pod进阶之不为人知的九大细节

WaterBear • 2021年10月1日 am9:31 • 订阅专题

本章节将多以文字描述的形式，讲述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.非自愿中断