K8S Pod 进阶（资源限制、pod容器探针、pod容器启动退出动作）

一、资源限制

1. 简单介绍

常见限制资源： cpu、内存

当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。 最常见的可设定资源是 CPU 和内存大小，以及其他类型的资源。

当为 Pod 中的容器指定了 request 资源时，调度器就使用该信息来决定将 Pod 调度到哪个节点上。当还为容器指定了 limit 资源时，kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。kubelet 还会为容器预留所设的 request 资源量， 供该容器使用。

如果 Pod 运行所在的节点具有足够的可用资源，容器可以使用超出所设置的 request 资源量。不过，容器不可以使用超出所设置的 limit 资源量。

如果给容器设置了内存的 limit 值，但未设置内存的 request 值，Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。 类似的，如果给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值，则 Kubernetes 自动为其设置 CPU 的 request 值 并使之与 CPU 的 limit 值匹配。

官网示例：
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

2. Pod 和 容器 的资源请求和限制

限制	含义
spec.containers[].resources.requests.cpu	定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory	定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu	定义 cpu 的资源上限
spec.containers[].resources.limits.memory	定义内存的资源上限

3. CPU 资源单位

CPU 资源的 request 和 limit 以 cpu 为单位。Kubernetes 中的一个 cpu 相当于1个 vCPU（1个超线程）。

Kubernetes 也支持带小数 CPU 的请求。spec.containers[].resources.requests.cpu 为 0.5 的容器能够获得一个 cpu 的一半 CPU 资源（类似于Cgroup对CPU资源的时间分片）。表达式 0.1 等价于表达式 100m（毫核），表示每 1000 毫秒内容器可以使用的 CPU 时间总量为 0.1*1000 毫秒。
Kubernetes 不允许设置精度小于 1m 的 CPU 资源。

4. 内存 资源单位

内存的 request 和 limit 以字节为单位。可以以整数表示，或者以10为底数的指数的单位（E、P、T、G、M、K）来表示， 或者以2为底数的指数的单位（Ei、Pi、Ti、Gi、Mi、Ki）来表示。

如： 1KB=10^{3=1000，1MB=10}6=1000000=1000KB，1GB=10^9=1000000000=1000MB
1KiB=2^{10=1024，1MiB=2}20=1048576=1024KiB

PS：在买硬盘的时候，操作系统报的数量要比产品标出或商家号称的小一些，主要原因是标出的是以 MB、GB为单位的，1GB 就是1,000,000,000Byte，而操作系统是以2进制为处理单位的，因此检查硬盘容量时是以MiB、GiB为单位，1GiB=2^30=1,073,741,824，相比较而言，1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte，所以检测实际结果要比标出的少一些。

官网示例：

https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"   
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

此例子中的 Pod 有两个容器。每个容器的 request 值为 0.25 cpu 和 64MiB 内存，每个容器的 limit 值为 0.5 cpu 和 128MiB 内存。那么可以认为该 Pod 的总的资源 request 为 0.5 cpu 和 128 MiB 内存，总的资源 limit 为 1 cpu 和 256MiB 内存。

5. 示例

编辑 yaml 文件

vim pod2.yaml 

apiVersion: v1  # Kubernetes API 版本号，此处为 v1
kind: Pod  # 资源类型为 Pod
metadata:  # 元数据（名称、标签等）
  name: pod2  # Pod 名称为 "pod2"
spec:  # Pod 的规格定义
  containers:  # 容器列表
  - name: web  # 第 1 个容器的名称为 "web"
    image: nginx  # 容器使用的镜像为 nginx
    env:  # 容器的环境变量
    - name: WEB_ROOT_PASSWORD  # 环境变量名称为 WEB_ROOT_PASSWORD
      value: 'password'  # 环境变量值为 password
    resources:  # 容器的资源请求和限制
      requests:  # 容器请求的资源
        memory: '64Mi'  # 请求内存为 64 MB
        cpu: '250m'  # 请求 CPU 为 250 毫核（0.25 核）
      limits:  # 容器的资源限制
        memory: '128Mi'  # 限制内存为 128 MB
        cpu: '500m'  # 限制 CPU 为 500 毫核（0.5 核）
  - name: db  # 第 2 个容器的名称为 "db"
    image: mysql  # 容器使用的镜像为 mysql
    env:  # 容器的环境变量
    - name: MYSQL_ROOT_PASSWORD  # 环境变量名称为 MYSQL_ROOT_PASSWORD
      value: 'abc123'  # 环境变量值为 abc123
    resources:  # 容器的资源请求和限制
      requests:  # 容器请求的资源
        memory: '512Mi'  # 请求内存为 512 MB
        cpu: '0.5'  # 请求 CPU 为 0.5 核
      limits:  # 容器的资源限制
        memory: '1Gi'  # 限制内存为 1 GB
        cpu: '1'  # 限制 CPU 为 1 核

创建pod

kubectl apply -f pod2.yaml 
kubectl get pod

查看pod的资源限制信息

kubectl describe pod pod2

二、Pod 容器探针（健康检查）

探针是由kubelet对容器执行的定期诊断。

官方示例：https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

1. 探针的三种规则

livenessProbe ： 判断容器是否正在运行。如果探测失败，则kubelet会杀死容器，并且容器将根据 restartPolicy 来设置 Pod 状态。 如果容器不提供存活探针，则默认状态为Success。

readinessProbe ： 判断容器是否准备好接受请求。如果探测失败，端点控制器将从与 Pod 匹配的所有 service endpoints 中剔除删除该Pod的IP地址。 初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。

startupProbe（这个1.17版本增加的）： 判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。如果配置了 startupProbe 探测，则在 startupProbe 状态为 Success 之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。 如果 startupProbe 失败，kubelet 将杀死容器，容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe， 则默认状态为 Success。

注：以上规则可以同时定义。在readinessProbe检测成功之前，Pod的running状态是不会变成ready状态的。

2. Probe 支持三种检查方法

• exec ： 在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
• tcpSocket ： 对指定端口上的容器的IP地址进行TCP检查（三次握手）。如果端口打开，则诊断被认为是成功的。
• httpGet ： 对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的

每次探测都将获得以下三种结果之一：

• 成功：容器通过了诊断。
• 失败：容器未通过诊断。
• 未知：诊断失败，因此不会采取任何行动

3. 示例一 exec 方式

vim exec.yaml
apiVersion: v1  # 使用的Kubernetes API版本
kind: Pod  # 创建Pod资源
metadata:  # 元数据部分，包含标签和名称等信息
  labels:  # 标签集合
    test: liveness  # 添加一个名为"test"的标签，并设置其值为"liveness"
  name: liveness-exec  # Pod的名称
spec:  # Pod规范
  containers:  # 容器列表
  - name: liveness  # 容器名称
    image: busybox  # 使用的容器镜像
    args:  # 启动容器时的参数
    - /bin/sh  # 使用的shell
    - -c  # 执行命令选项
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60  # 容器启动后执行的命令
    livenessProbe:  # 存活探针配置
      exec:  # 使用执行命令的方式进行存活检查
        command:  # 检查使用的具体命令
        - cat  # 查看文件内容的命令
        - /tmp/healthy  # 需要查看的文件路径
      failureThreshold: 1  # 连续失败的次数达到阈值后认为容器不健康
      initialDelaySeconds: 5  # 容器启动后等待多少秒开始执行存活检查
      periodSeconds: 5  # 存活探针的执行周期

• initialDelaySeconds：指定 kubelet 在执行第一次探测前应该等待5秒，即第一次探测是在容器启动后的第6秒才开始执行。默认是 0 秒，最小值是 0。
• periodSeconds：指定了 kubelet 应该每 5 秒执行一次存活探测。默认是 10 秒。最小值是 1。
• failureThreshold：当探测失败时，Kubernetes 将在放弃之前重试的次数。 存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
• timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。（在 Kubernetes 1.20 版本之前，exec 探针会忽略 timeoutSeconds 探针会无限期地 持续运行，甚至可能超过所配置的限期，直到返回结果为止）。

可以看到 Pod 中只有一个容器。kubelet 在执行第一次探测前需要等待 5 秒，kubelet 会每 5 秒执行一次存活探测。kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。如果命令执行成功并且返回值为 0，kubelet 就会认为这个容器是健康存活的。 当到达第 31 秒时，这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它。

kubectl apply -f exec.yaml
kubectl get pod
kubectl get pod -w
kubectl describe pod liveness-exec

4. 示例二 tcpSocket 方式

vim tcpsocket.yaml

apiVersion: v1  # 指定使用的 Kubernetes API 版本
kind: Pod  # 定义资源类型为 Pod
metadata:  # 元数据信息，用于描述 Pod 的属性
  name: probe-tcp  # 指定 Pod 的名称
spec:  # 指定 Pod 的规格
  containers:  # 定义 Pod 中的容器列表
  - name: nginx  # 容器的名称
    image: soscscs/myapp:v1  # 容器所使用的镜像
    livenessProbe:  # 定义存活探针用于检测容器是否正常运行
      initialDelaySeconds: 5  # 容器启动后等待多少秒开始进行探测
      timeoutSeconds: 1  # 探测超时时间，如果在该时间内未成功响应，则认为失败
      tcpSocket:  # 使用 TCP Socket 进行探测
        port: 8080  # 探测的目标端口号
      periodSeconds: 10  # 两次探测之间的间隔时间
      failureThreshold: 2  # 连续多少次探测失败后认为容器不正常，并重启容器

定义了一个名为 probe-tcp 的Pod，其中包含一个名为 nginx 的容器，使用镜像 soscscs/myapp:v1。该容器还配置了一个存活探针，通过向端口 8080 发送 TCP Socket 连接来检测容器是否正常运行。在容器启动后的5秒钟开始进行探测，每10秒进行一次探测，如果连续两次探测失败，则认为容器不正常，并触发容器的重启操作。

kubectl apply -f tcpsocket.yaml
kubectl get pod -w

5. 示例三 httpget 方式

apiVersion: v1  # 指定使用的 Kubernetes API 版本
kind: Pod  # 定义资源类型为 Pod
metadata:  # 元数据信息，用于描述 Pod 的属性
  name: liveness-httpget  # 指定 Pod 的名称
  namespace: default  # 指定 Pod 所属的命名空间
spec:  # 指定 Pod 的规格
  containers:  # 定义 Pod 中的容器列表
  - name: liveness-httpget-container  # 容器的名称
    image: soscscs/myapp:v1  # 容器所使用的镜像
    imagePullPolicy: IfNotPresent  # 镜像拉取策略，如果本地不存在该镜像则进行拉取
    ports:  # 定义容器暴露的端口
    - name: http  # 端口的名称
      containerPort: 80  # 容器监听的端口号
    livenessProbe:  # 定义存活探针用于检测容器是否正常运行
      httpGet:  # 使用 HTTP GET 请求进行探测
        port: http  # 探测的目标端口号
        path: /index.html  # GET 请求的路径
      initialDelaySeconds: 1  # 容器启动后等待多少秒开始进行探测
      periodSeconds: 3  # 两次探测之间的间隔时间
      timeoutSeconds: 10  # 探测超时时间，如果在该时间内未成功响应，则认为失败

该文件定义了一个名为 liveness-httpget 的 Pod，在默认命名空间中运行。Pod 中包含一个名为 liveness-httpget-container 的容器，使用镜像 soscscs/myapp:v1。该容器暴露的端口为 80，通过 HTTP GET 请求向 /index.html 路径进行存活探测。在容器启动后的 1 秒钟开始进行探测，每 3 秒进行一次探测，如果在 10 秒内未成功响应，则认为存活探测失败。

任何大于或等于 200 并且小于 400 的返回代码标示成功，其它返回代码都标示失败。

kubectl apply -f httpget.yaml

kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html

6. 示例四 就绪检测1

vim readiness-httpget.yaml

apiVersion: v1  # Kubernetes API 版本号，此处为 v1
kind: Pod  # 资源类型为 Pod
metadata:  # 元数据（名称、标签等）
  name: readiness-httpget  # Pod 名称为 "readiness-httpget"
  namespace: default  # 命名空间为 default
spec:  # Pod 的规格定义
  containers:  # 容器列表
  - name: readiness-httpget-container  # 第 1 个容器的名称为 "readiness-httpget-container"
    image: soscscs/myapp:v1  # 容器使用的镜像为 soscscs/myapp:v1
    imagePullPolicy: IfNotPresent  # 镜像拉取策略为如果本地不存在才拉取
    ports:  # 容器暴露的端口列表
    - name: http  # 端口名称为 "http"
      containerPort: 80  # 容器监听的端口号为 80
    readinessProbe:  # 就绪探针设置
      httpGet:  # 使用 HTTP GET 方法进行探测
        port: 80  # 对容器的 80 端口进行探测
        path: /index1.html  # 探测路径为 /index1.html
      initialDelaySeconds: 1  # 容器启动后延迟 1 秒开始进行探测
      periodSeconds: 3  # 探测间隔为 3 秒
    livenessProbe:  # 存活探针设置
      httpGet:  # 使用 HTTP GET 方法进行探测
        port: http  # 对容器的 http 端口进行探测
        path: /index.html  # 探测路径为 /index.html
      initialDelaySeconds: 1  # 容器启动后延迟 1 秒开始进行探测
      periodSeconds: 3  # 探测间隔为 3 秒
      timeoutSeconds: 10  # 超时时间为 10 秒

（1）readinessProbe：用于判断容器是否已经就绪，可以接收流量。

• 在此配置中，readinessProbe 使用 HTTP GET 方法检查容器的就绪状态。
• 它通过发送请求到容器的端口 80，并访问路径 /index1.html。
• initialDelaySeconds 设置为 1，表示在容器启动后等待一秒钟开始首次进行检测。
• periodSeconds 设置为 3，表示每隔 3 秒执行一次检测。

（2）livenessProbe：用于判断容器是否处于存活状态，如果容器不健康则会触发重启操作。

• 在此配置中，livenessProbe 也使用 HTTP GET 方法检查容器的存活状态。
• 它通过发送请求到容器的端口 80，并访问路径 /index.html。
• initialDelaySeconds 设置为 1，表示在容器启动后等待一秒钟开始首次进行检测。
• periodSeconds 设置为 3，表示每隔 3 秒执行一次检测。
• timeoutSeconds 设置为 10，表示每次探测请求的超时时间为 10 秒。

这样配置的效果是，当该 Pod 的容器启动后，Kubernetes 将会定期检测容器的就绪状态和存活状态。如果容器的就绪状态不满足预期，它将不会被加入到负载均衡器中，即不会接收流量。对于存活性探测，如果容器在一定时间内无响应或返回非成功状态码，Kubernetes 将会自动重启该容器，以确保应用程序的可用性。

kubectl create -f readiness-httpget.yaml

kubectl get pods 

kubectl exec -it readiness-httpget sh

cd /usr/share/nginx/html/
ls
50x.html    index.html
echo 123 > index1.html 
exit

kubectl get pods 

kubectl exec -it readiness-httpget -- rm -rf /usr/share/nginx/html/index.html

kubectl get pods -w

7. 示例四 就绪检测2

vim readiness-myapp.yaml

apiVersion: v1  # Kubernetes API 版本号，此处为 v1
kind: Pod  # 资源类型为 Pod
metadata:  # 元数据（名称、标签等）
  name: myapp1  # Pod 名称为 "myapp1"
  labels:  # Pod 的标签
     app: myapp
spec:  # Pod 的规格定义
  containers:  # 容器列表
  - name: myapp  # 第 1 个容器的名称为 "myapp"
    image: soscscs/myapp:v1  # 容器使用的镜像为 soscscs/myapp:v1
    ports:  # 容器暴露的端口列表
    - name: http  # 端口名称为 "http"
      containerPort: 80  # 容器监听的端口号为 80
    readinessProbe:  # 就绪探针设置
      httpGet:  # 使用 HTTP GET 方法进行探测
        port: 80  # 对容器的 80 端口进行探测
        path: /index.html  # 探测路径为 /index.html
      initialDelaySeconds: 5  # 容器启动后延迟 5 秒开始进行探测
      periodSeconds: 5  # 探测间隔为 5 秒
      timeoutSeconds: 10  # 超时时间为 10 秒

---

apiVersion: v1  # Kubernetes API 版本号，此处为 v1
kind: Pod  # 资源类型为 Pod
metadata:  # 元数据（名称、标签等）
  name: myapp2  # Pod 名称为 "myapp2"
  labels:  # Pod 的标签
     app: myapp
spec:  # Pod 的规格定义
  containers:  # 容器列表
  - name: myapp  # 第 1 个容器的名称为 "myapp"
    image: soscscs/myapp:v1  # 容器使用的镜像为 soscscs/myapp:v1
    ports:  # 容器暴露的端口列表
    - name: http  # 端口名称为 "http"
      containerPort: 80  # 容器监听的端口号为 80
    readinessProbe:  # 就绪探针设置
      httpGet:  # 使用 HTTP GET 方法进行探测
        port: 80  # 对容器的 80 端口进行探测
        path: /index.html  # 探测路径为 /index.html
      initialDelaySeconds: 5  # 容器启动后延迟 5 秒开始进行探测
      periodSeconds: 5  # 探测间隔为 5 秒
      timeoutSeconds: 10  # 超时时间为 10 秒

---

apiVersion: v1  # Kubernetes API 版本号，此处为 v1
kind: Pod  # 资源类型为 Pod
metadata:  # 元数据（名称、标签等）
  name: myapp3  # Pod 名称为 "myapp3"
  labels:  # Pod 的标签
     app: myapp
spec:  # Pod 的规格定义
  containers:  # 容器列表
  - name: myapp  # 第 1 个容器的名称为 "myapp"
    image: soscscs/myapp:v1  # 容器使用的镜像为 soscscs/myapp:v1
    ports:  # 容器暴露的端口列表
    - name: http  # 端口名称为 "http"
      containerPort: 80  # 容器监听的端口号为 80
    readinessProbe:  # 就绪探针设置
      httpGet:  # 使用 HTTP GET 方法进行探测
        port: 80  # 对容器的 80 端口进行探测
        path: /index.html  # 探测路径为 /index.html
      initialDelaySeconds: 5  # 容器启动后延迟 5 秒开始进行探测
      periodSeconds: 5  # 探测间隔为 5 秒
      timeoutSeconds: 10  # 超时时间为 10 秒

---

apiVersion: v1  # Kubernetes API 版本号，此处为 v1
kind: Service  # 资源类型为 Service
metadata:  # 元数据（名称、标签等）
  name: myapp  # Service 名称为 "myapp"
spec:  # Service 的规格定义
  selector:  # 选择器，用于选择对应的 Pod
    app: myapp  # 选择具有 app=myapp 标签的 Pod
  type: ClusterIP  # Service 类型为 ClusterIP
  ports:  # Service 暴露的端口列表
  - name: http  # 端口名称为 "http"
    port: 80  # Service 监听的端口号为 80
    targetPort: 80  # 将流量转发到 Pod 的 80 端口

创建名为 myapp1、myapp2 和 myapp3 的 Pod，并创建名为 myapp 的 Service，该 Service 选择具有 app=myapp 的标签的 Pod，并将流量转发到 Pod 的 80 端口。每个 Pod 都配置了就绪探针，通过 GET 请求检查容器是否已准备好接受流量。

kubectl create -f readiness-myapp.yaml

kubectl get pods,svc,endpoints -o wide

kubectl exec -it pod/myapp1 -- rm -rf /usr/share/nginx/html/index.html

readiness探测失败，Pod 无法进入READY状态，且端点控制器将从 endpoints 中剔除删除该 Pod 的 IP 地址

kubectl get pods,svc,endpoints -o wide

三、启动 退出动作

vim post.yaml

apiVersion: v1  # Kubernetes API 版本号，此处为 v1
kind: Pod  # 资源类型为 Pod
metadata:  # 元数据（名称、标签等）
  name: lifecycle-demo  # Pod 名称为 "lifecycle-demo"
spec:  # Pod 的规格定义
  containers:  # 容器列表
  - name: lifecycle-demo-container  # 第一个容器的名称为 "lifecycle-demo-container"
    image: soscscs/myapp:v1  # 容器使用的镜像为 soscscs/myapp:v1
    lifecycle:  # 生命周期定义 
      postStart:  # 容器启动后的处理
        exec:  # 执行命令
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler >> /var/log/nginx/message"]
          # 运行一个命令，在容器内执行 echo 命令并将输出追加到 /var/log/nginx/message 文件中
      preStop:  # 容器停止前的处理
        exec:  # 执行命令
          command: ["/bin/sh", "-c", "echo Hello from the poststop handler >> /var/log/nginx/message"]
          # 运行一个命令，在容器内执行 echo 命令并将输出追加到 /var/log/nginx/message 文件中
    volumeMounts:  # 挂载卷配置
    - name: message-log  # 卷的名称为 "message-log"
      mountPath: /var/log/nginx/  # 将卷挂载到容器的 /var/log/nginx/ 目录
      readOnly: false  # 卷的访问权限为可读写
  initContainers:  # 初始化容器列表
  - name: init-myservice  # 初始化容器的名称为 "init-myservice"
    image: soscscs/myapp:v1  # 容器使用的镜像为 soscscs/myapp:v1
    command: ["/bin/sh", "-c", "echo 'Hello initContainers'   >> /var/log/nginx/message"]
    # 在初始化容器内执行 echo 命令并将输出追加到 /var/log/nginx/message 文件中
    volumeMounts:  # 挂载卷配置
    - name: message-log  # 卷的名称为 "message-log"
      mountPath: /var/log/nginx/  # 将卷挂载到容器的 /var/log/nginx/ 目录
      readOnly: false  # 卷的访问权限为可读写
  volumes:  # 卷配置
  - name: message-log  # 卷的名称为 "message-log"
    hostPath:  # 主机路径挂载
      path: /data/volumes/nginx/log/  # 主机上的路径为 /data/volumes/nginx/log/
      type: DirectoryOrCreate  # 如果路径不存在则创建目录

创建一个名为 lifecycle-demo 的 Pod。该 Pod 包含一个名为 lifecycle-demo-container 的容器和一个名为 init-myservice 的初始化容器。在容器启动后，执行命令将文本追加到 /var/log/nginx/message 文件中。在容器停止前，执行命令也将文本追加到同一个文件中。此外，该 Pod 还定义了一个名为 message-log 的卷，并将其挂载到容器的 /var/log/nginx/ 目录中，以便容器可以访问和修改该目录下的文件。初始化容器也会将文本追加到相同的文件中。卷使用主机路径挂载方式，将主机上的 /data/volumes/nginx/log/ 路径挂载到容器中。如果路径不存在，则创建相应的目录。

kubectl create -f post.yaml

kubectl exec -it lifecycle-demo -- cat /var/log/nginx/message
Hello initContainers
Hello from the postStart handler

kubectl get pod -o wide

在 node01 节点上查看

init Container先执行，然后当一个主容器启动后，Kubernetes 将立即发送 postStart 事件

cd /data/volumes/nginx/log/
ls
access.log  error.log  message

cat message 
Hello initContainers
Hello from the postStart handler

删除 pod 后，再在 node01 节点上查看

当在容器被终结之前， Kubernetes 将发送一个 preStop 事件

kubectl delete pod lifecycle-demo

cat message 
Hello initContainers
Hello from the postStart handler
Hello from the poststop handler

总结

1. pod资源限制

sepc.containers.resources.requests.cpu / memory

创建Pod容器时需要预留的资源量0.5 500M

sepc.containers.resources.limits.cpu/memory

pod容器能够使用的资源量的上限Mi Gi(2为底数) M G(10为底数)

2. pod容器探针（健康检查）

存活探针(livenessProbe)： 判断容器是否运行正常，如果探测失败则杀掉容器（不是pod),容器会根据容器策略决定是否重启

就绪探针（readnessProbe)： 判断pod是否能够进入ready状态，做好接受请求的准备;探测失败后进入notready状态并且从service资源的endpoints中剔除，service将不会把访问请求转发给这个pod

启动探针(startupProbe)： 判断容器内的应用是否成功，在探测成功状态为success之前，其他探针都会处于失效状态

3. 三种探测方式

exec： 通过command 设置执行在容器内执行的Linux命令来探测，如果返回状态码为0，则认为探测成功的

httpget： 通过httpget请求访问指定的容器端口url路劲，如果返回状态码为>=200且<400 (?xx3xx) ，则认为探测成功的

tcpsocket： 通过对指定的端口发送tcp连接，如果端口无误且三次握手(TCP连接成功)，则为探测成功

4. Pod 容器的启动动作和退出动作

spec.containers.lifecycle.postStart 配合 exec.command字段 当容器启动时，会执行额外的操作

spec.comtainers.lifecyle.postStop 配合 exec.command字段 当容器启动时，会执行额外的操作