Pod

Pod是K8s最基本的操作单元，包含一个或多个紧密相关的容器，一个Pod可以被一个容器化的环境看作应用层的“逻辑宿主机”；一个Pod中的多个容器应用通常是紧密耦合的，Pod在Node上被创建、启动或者销毁；每个Pod里运行着一个特殊的被称之为Volume挂载卷，因此他们之间通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。

同一个Pod里的容器之间仅需通过localhost就能互相通信。一个Pod中的应用容器共享五种资源：

PID命名空间：Pod中的不同应用程序可以看到其他应用程序的进程ID。
网络命名空间：Pod中的多个容器能够访问同一个IP和端口范围。
IPC命名空间：Pod中的多个容器能够使用SystemV IPC或POSIX消息队列进行通信。
UTS命名空间：Pod中的多个容器共享一个主机名。
Volumes(共享存储卷)：Pod中的各个容器可以访问在Pod级别定义的Volumes。

Pod的生命周期通过Replication Controller来管理；通过模板进行定义，然后分配到一个Node上运行，在Pod所包含容器运行结束后，Pod结束。

Kubernetes为Pod设计了一套独特的网络配置，包括：为每个Pod分配一个IP地址，使用Pod名作为容器间通信的主机名等。

二、pod生命周期

pod在整个生命周期中被系统定义为各种状态，熟悉pod的各种状态对于理解如何设置pod的调度策略、重启策略是很有必要的，pod状态如下：

状态值	描述
Pending	API Server已经创建了pod，但在pod内还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程
Running	pod内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态
Succeeded	pod内所有容器均成功执行后退出，且不会在重启
Failed	pod内所有容器均已退出，但至少有一个容器为退出失败状态
Unknown	由于某种原因无法获取该Pod的状态，可能由于网络通信不畅导致的

三、pod重启策略

pod的重启策略（RestartPolicy）应用于pod内的所有容器，并且仅在pod所处的 node 上 由kubelet 进行判断和重启操作。

当某个容器异常退出或者健康检查失败时，kubelet将根据RestartPolicy的设置进行相应的操作，pod的重启策略包括Always、OnFailure和Never（默认值为Always）：

重启策略	描述
Always	当容器失效时，由kubelet自动重启该容器
OnFailure	当容器终止运行且退出码不为0时，由kubelet自动重启该容器
Never	不论容器运行状态如何，kubelet都不会重启该容器

kubelet重启失效容器的时间间隔以symc-frequency乘以2n来计算，例如1、 2、4、8倍等，最长延时5min，并且在成功重启后的10min后重置该时间。

pod的重启策略与控制方式息息相关，当前可用于管理pod的控制器包括
ReplicationController、Job、DaemonSet，还可以通过kubelet管理（静态
pod)。每种控制器对Pod的重启策略要求如下：

控制器	要求
RC和DaemonSet	必须设置为Always，需要保证该容器持续运行
Job	OnFailure或Never，确保容器执行完成后不再重启
kubelet	在Pod失效时自动重启它，不论将RestartPolicy设置为什么值，也不会对Pod进行健康检查

结合pod的状态和重启策略，常见的状态转换场景如下：

Pod中的容器数	Pod状态	发生事件	-	不同重启策略下的结果状态	-
-	-	-	Always	OnFailure	Never
包含一个容器	Running	容器成功退出	Running	Succeeded	Succeeded
包含一个容器	Running	容器失败退出	Running	Running	Failed
包含两个容器	Running	1个容器失败退出	Running	Running	Running
包含两个容器	Running	容器内存溢出挂掉	Running	Running	Failed

四、Pod 的活性与就绪探针

1、Pod 探针机制

在 Kubernetes 中 Pod 是最小的计算单元，而一个 Pod 又由多个容器组成，相当于每个容器就是一个应用，应用在运行期间，可能因为某也意外情况致使程序挂掉。那么如何监控这些容器状态稳定性，保证服务在运行期间不会发生问题，发生问题后进行重启等机制，就成为了重中之重的事情，考虑到这点 kubernetes 推出了活性探针机制。

有了活性探针后能保证程序在运行中如果挂掉能够自动重启，但是还有个经常遇到的问题，比如说，在 Kubernetes 中启动 Pod，显示明明 Pod 已经启动成功，且能访问里面的端口，但是却返回错误信息。还有就是在执行滚动更新时候，总会出现一段时间，Pod 对外提供网络访问，但是访问却发生 404，这两个原因，都是因为 Pod 已经成功启动，但是 Pod 的的容器中应用程序还在启动中导致，考虑到这点 Kubernetes 推出了就绪探针机制。

2、Pod 三种探针简介

LivenessProbe（存活探针）：存活探针主要作用是，用指定的方式进入容器检测容器中的应用是否正常运行，如果检测失败，则认为容器不健康，那么 Kubelet 将根据 Pod 中设置的 restartPolicy （重启策略）来判断，Pod 是否要进行重启操作，如果容器配置中没有配置 livenessProbe 存活探针，Kubelet 将认为存活探针探测一直为成功状态。

ReadinessProbe（就绪探针）：用于判断容器中应用是否启动完成，当探测成功后才使 Pod 对外提供网络访问，设置容器 Ready 状态为 true，如果探测失败，则设置容器的 Ready 状态为 false。对于被 Service 管理的 Pod，Service 与 Pod、EndPoint 的关联关系也将基于 Pod 是否为 Ready 状态进行设置，如果 Pod 运行过程中 Ready 状态变为 false，则系统自动从 Service 关联的 EndPoint 列表中移除，如果 Pod 恢复为 Ready 状态。将再会被加回 Endpoint 列表。通过这种机制就能防止将流量转发到不可用的 Pod 上。

k8s 在1.16版本后增加startupProbe探针，主要解决在复杂的程序中readinessProbe、livenessProbe探针无法更好的判断程序是否启动、是否存活。进而引入startupProbe探针为readinessProbe、livenessProbe探针服务。

startupProbe（启动探针）: 探测容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功 Success。

如果三个探针同时存在，先执行startupProbe探针，其他两个探针将会被暂时禁用，直到pod满足startupProbe探针配置的条件，其他2个探针启动，如果不满足按照规则重启容器
另外两种探针在容器启动后，会按照配置，直到容器消亡才停止探测，而startupProbe探针只是在容器启动后按照配置满足一次后，不在进行后续的探测。

3、Pod 探针的探测方式与结果

目前 LivenessProbe、ReadinessProbe和startupProbe 三种探针都支持下面三种探测方法：

ExecAction：在容器中执行指定的命令，如果执行成功，退出码为 0 则探测成功。
HTTPGetAction：通过容器的IP地址、端口号及路径调用 HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器健康。
TCPSocketAction：通过容器的 IP 地址和端口号执行 TCP 检查，如果能够建立 TCP 连接，则表明容器健康。

探针探测结果有以下值：
Success：表示通过检测。
Failure：表示未通过检测。
Unknown：表示检测没有正常进行。

4、Pod 探针的相关属性

探针(Probe)有许多可选字段，可以用来更加精确的控制Liveness、Readiness和startup三种探针的行为(Probe)：

initialDelaySeconds： Pod 启动后首次进行检查的等待时间，单位“秒”。
periodSeconds：检查的间隔时间，默认为 10s，单位“秒”。
timeoutSeconds：探针执行检测请求后，等待响应的超时时间，默认为 1s，单位“秒”。
successThreshold：探针检测失败后认为成功的最小连接成功次数，默认为 1s，在 Liveness 探针中必须为 1s，最小值为 1s。
failureThreshold：探测失败的重试次数，重试一定次数后将认为失败，在 readiness 探针中，Pod会被标记为未就绪，默认为 3s，最小值为 1s。

5、两种探针的区别

ReadinessProbe 和 livenessProbe 可以使用相同探测方式，只是对 Pod 的处置方式不同：

readinessProbe 当检测失败后，将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。
livenessProbe 当检测失败后，将杀死容器并根据 Pod 的重启策略来决定作出对应的措施。

五、探针使用示例

1、LivenessProbe 探针使用示例

（1）、通过exec方式做健康探测

示例文件 liveness-exec.yaml

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  labels:
    app: liveness
spec:
  containers:
  - name: liveness
    image: busybox
    args:                       #创建测试探针探测的文件
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      failureThreshold: 3       #允许失败的次数
      initialDelaySeconds: 10   #延迟检测时间
      periodSeconds: 5          #检测时间间隔
      exec:
        command:
        - cat
        - /tmp/healthy

容器启动设置执行的命令：
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"

容器在初始化后，首先创建一个 /tmp/healthy 文件，然后执行睡眠命令，睡眠 30 秒，到时间后执行删除 /tmp/healthy 文件命令。而设置的存活探针检检测方式为执行 shell 命令，用 cat 命令输出 healthy 文件的内容，如果能成功执行这条命令，存活探针就认为探测成功，否则探测失败。在前 30 秒内，由于文件存在，所以存活探针探测时执行 cat /tmp/healthy 命令成功执行。30 秒后 healthy 文件被删除，所以执行命令失败，Kubernetes 会根据 Pod 设置的重启策略来判断，是否重启 Pod。

（2）、通过HTTP方式做健康探测

示例文件 liveness-http.yaml

apiVersion: v1
kind: Pod
metadata:
  name: liveness-http
  labels:
    test: liveness
spec:
  containers:
  - name: liveness
    image: mydlqclub/springboot-helloworld:0.0.1
    livenessProbe:
      failureThreshold: 3       #允许失败的次数
      initialDelaySeconds: 20   #延迟加载时间
      periodSeconds: 5          #重试时间间隔
      timeoutSeconds: 10        #超时时间设置
      httpGet:
        scheme: HTTP
        port: 8081
        path: /actuator/health

上面 Pod 中启动的容器是一个 SpringBoot 应用，其中引用了 Actuator 组件，提供了 /actuator/health 健康检查地址，存活探针可以使用 HTTPGet 方式向服务发起请求，请求 8081 端口的 /actuator/health 路径来进行存活判断：

任何大于或等于200且小于400的代码表示探测成功，任何其他代码表示失败，如果探测失败，则会杀死 Pod 进行重启操作。

httpGet探测方式有如下可选的控制字段:

scheme: 用于连接host的协议，默认为HTTP。
host：要连接的主机名，默认为Pod IP，可以在http request head中设置host头部。
port：容器上要访问端口号或名称。
path： http服务器上的访问URI。
httpHeaders：自定义HTTP请求headers，HTTP允许重复headers。

（3）、通过TCP方式做健康探测

示例文件 liveness-tcp.yaml

apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcp
  labels:
    app: liveness
spec:
  containers:
  - name: liveness
    image: nginx
    livenessProbe:
      failureThreshold: 3
      initialDelaySeconds: 15
      periodSeconds: 20
      tcpSocket:
        port: 80

TCP 检查方式和 HTTP 检查方式非常相似，在容器启动 initialDelaySeconds 参数设定的时间后，kubelet 将发送第一个 livenessProbe 探针，尝试连接容器的 80 端口，如果连接失败则将杀死 Pod 重启容器。

2、ReadinessProbe 探针使用示例

Pod 的 ReadinessProbe 探针使用方式和 LivenessProbe 探针探测方法一样，也是支持三种，只是一个是用于探测应用的存活，一个是判断是否对外提供流量的条件。这里用一个 Springboot 项目，设置 ReadinessProbe 探测 SpringBoot 项目的 8081 端口下的 /actuator/health 接口，如果探测成功则代表内部程序以及启动，就开放对外提供接口访问，否则内部应用没有成功启动，暂不对外提供访问，直到就绪探针探测成功。

示例文件 readiness-exec.yaml

apiVersion: v1
kind: Service
metadata:
  name: springboot
  labels:
    app: springboot
spec:
  type: NodePort
  ports:
  - name: server
    port: 8080
    targetPort: 8080
    nodePort: 31180
  - name: management
    port: 8081
    targetPort: 8081
    nodePort: 31181
  selector:
    app: springboot
---
apiVersion: v1
kind: Pod
metadata:
  name: springboot
  labels:
    app: springboot
spec:
  containers:
  - name: springboot
    image: mydlqclub/springboot-helloworld:0.0.1
    ports:
    - name: server
      containerPort: 8080
    - name: management
      containerPort: 8081
    readinessProbe:
      initialDelaySeconds: 20
      periodSeconds: 5
      timeoutSeconds: 10
      httpGet:
        scheme: HTTP
        port: 8081
        path: /actuator/health

3、ReadinessProbe + LivenessProbe 配合使用示例

一般程序中需要设置两种探针结合使用，并且也要结合实际情况，来配置初始化检查时间和检测间隔，下面列一个简单的 SpringBoot 项目的 Deployment 例子。

apiVersion: v1
kind: Service
metadata:
  name: springboot
  labels:
    app: springboot
spec:
  type: NodePort
  ports:
    - name: server
      port: 8080
      targetPort: 8080
      nodePort: 31180
    - name: management
      port: 8081
      targetPort: 8081
      nodePort: 31181
  selector:
    app: springboot
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: springboot
  labels:
    app: springboot
spec:
  replicas: 1
  selector:
    matchLabels:
      app: springboot
  template:
    metadata:
      name: springboot
      labels:
        app: springboot
    spec:
      containers:
        - name: readiness
          image: mydlqclub/springboot-helloworld:0.0.1
          ports:
            - name: server
              containerPort: 8080
            - name: management
              containerPort: 8081
          readinessProbe:
            initialDelaySeconds: 20
            periodSeconds: 5
            timeoutSeconds: 10
            httpGet:
              scheme: HTTP
              port: 8081
              path: /actuator/health
          livenessProbe:
            initialDelaySeconds: 30
            periodSeconds: 10
            timeoutSeconds: 5
            httpGet:
              scheme: HTTP
              port: 8081
              path: /actuator/health

4、探针属性

startupProbe探针属性跟 ReadinessProbe 和 livenessProbe 相同

initialDelaySeconds：容器启动后要等待多少秒后就探针开始工作，单位“秒”，默认是 0 秒，最小值是 0
periodSeconds：执行探测的时间间隔（单位是秒），默认为 10s，单位“秒”，最小值是 1
timeoutSeconds：探针执行检测请求后，等待响应的超时时间，默认为 1s，单位“秒”，最小值是 1
successThreshold：探针检测失败后认为成功的最小连接成功次数，默认为 1s，在 Liveness 探针中必须为 1s，最小值为 1s。
failureThreshold：探测失败的重试次数，重试一定次数后将认为失败，在 readiness 探针中，Pod会被标记为未就绪，默认为 3s，最小值为 1s

六、pod退出状态

pod内容器被重新拉起后，pod state与laststate描述、Restart Count

如果出现异常重启过，看到的内容如下：

    State:          Running
      Started:      Wed, 01 Jun 2022 05:56:06 +0800
    Last State:     Terminated
      Reason:       Error
      Exit Code:    3
      Started:      Tue, 31 May 2022 15:00:56 +0800
      Finished:     Wed, 01 Jun 2022 05:55:55 +0800

此时新增标签 Last State，记录上次异常退出的原因，并且Restart Count值为1，如果下次再次异常退出，那么会累加。

注意：当容器由于异常被强行终止，会由k8s创建一个全新的容器，而不是重启原来的容器。

退出代码为137，含义：表示该进程由外部信号终止。数字137=128+x，其中x是终止进程的信号编码。在这个例子中，x等于9，这个是SIGKILL的信号编号，意味着这个进程被强行终止。

底部events列出了容器为什么终止，奇怪是这里并没显示原因，只是记录了重新拉起的过程。

退出状态码的区间
必须在 0-255 之间
0 表示正常退出
外界中断将程序退出的时候状态码区间在 129-255，(操作系统给程序发送中断信号，比如 kill -9 是 SIGKILL，ctrl+c 是 SIGINT)
一般程序自身原因导致的异常退出状态区间在 1-128 (这只是一般约定，程序如果一定要用129-255的状态码也是可以的)
假如写代码指定的退出状态码时不在 0-255 之间，例如: exit(-1)，这时会自动做一个转换，最终呈现的状态码还是会在 0-255 之间。我们把状态码记为 code

当指定的退出时状态码为负数，那么转换公式如下: 256 - (|code| % 256)
当指定的退出时状态码为正数，那么转换公式如下: code % 256

137
此状态码一般是因为 pod 中容器内存达到了它的资源限制(resources.limits)，一般是内存溢出(OOM)，CPU达到限制只需要不分时间片给程序就可以。因为限制资源是通过 linux 的 cgroup 实现的，所以 cgroup 会将此容器强制杀掉，类似于 kill -9
还可能是宿主机本身资源不够用了(OOM)，内核会选取一些进程杀掉来释放内存
不管是 cgroup 限制杀掉进程还是因为节点机器本身资源不够导致进程死掉，都可以从系统日志中找到记录:
ubuntu 的系统日志在 /var/log/syslog，centos 的系统日志在 /var/log/messages，都可以用 journalctl -k 来查看系统日志 - 1 和 255

这种可能是一般错误，具体错误原因只能看容器日志，因为很多程序员写异常退出时习惯用 exit(1) 或 exit(-1)，-1 会根据转换规则转成 255