深入Pod

Pod配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
apiVersion: v1 # api 文档版本
kind: Pod # 资源对象类型，也可以配置为像Deployment、StatefulSet这一类的对象
metadata: # Pod 相关的元数据，用于描述 Pod 的数据
  name: nginx-demo # Pod 的名称
  labels: # 定义 Pod 的标签
    type: app # 自定义 label 标签，名字为 type，值为 app
    test: 1.0.0 # 自定义 label 标签，描述 Pod 版本号
  namespace: 'default' # 命名空间的配置
spec: # 期望 Pod 按照这里面的描述进行创建
  containers: # 对于 Pod 中的容器描述
    - name: nginx # 容器的名称
      image: nginx:1.7.9 # 指定容器的镜像
      imagePullPolicy: IfNotPresent # 镜像拉取策略，指定如果本地有就用本地的，如果没有就拉取远程的
      command: # 指定容器启动时执行的命令
        - nginx
        - -g
        - 'daemon off;' # nginx -g 'daemon off;'
      workingDir: /usr/share/nginx/html # 定义容器启动后的工作目录
      ports:
        - name: http # 端口名称
          containerPort: 80 # 描述容器内要暴露什么端口
          protocol: TCP # 描述该端口是基于哪种协议通信的
      env: # 环境变量
        - name: JVM_OPTS # 环境变量名称
          value: '-Xms128m -Xmx128m' # 环境变量的值
      resources:
        requests: # 最少需要多少资源
          cpu: 100m # 限制 cpu 最少使用 0.1 个核心
          memory: 128Mi # 限制内存最少使用 128兆
        limits: # 最多可以用多少资源
          cpu: 200m # 限制 cpu 最多使用 0.2 个核心
          memory: 256Mi # 限制 最多使用 256兆
  restartPolicy: OnFailure # 重启策略，只有失败的情况才会重启

探针

容器内应用的监测机制，根据不同的探针来判断容器应用当前的状态

类型

StartupProbe

k8s 1.16 版本新增的探针，用于判断应用程序是否已经启动了。

当配置了 startupProbe 后，会先禁用其他探针，直到 startupProbe 成功后，其他探针才会继续。

作用：由于有时候不能准确预估应用一定是多长时间启动成功，因此配置另外两种方式不方便配置初始化时长来检测，而配置了
statupProbe 后，只有在应用启动成功了，才会执行另外两种探针，可以更加方便的结合使用另外两种探针使用。

1
2
3
4
startupProbe:
  httpGet:
    path: /api/startup
    port: 80
LivenessProbe

用于探测容器中的应用是否运行，如果探测失败，kubelet 会根据配置的重启策略进行重启，若没有配置，默认就认为容器启动成功，不会执行重启策略。

1
2
3
4
5
6
7
8
9
10
livenessProbe:
  failureThreshold: 5
  httpGet:
    path: /health
    port: 8080
    scheme: HTTP
  initialDelaySeconds: 60
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 5
ReadinessProbe

用于:否健康，它的返回值如果返回 success，那么就认为该容器已经完全启动，并且该容器是可以接收外部流量的。

1
2
3
4
5
6
7
8
9
readinessProbe:
  failureThreshold: 3 # 错误次数
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP
  periodSeconds: 10 # 间隔时间
  successThreshold: 1
  timeoutSeconds: 1

探测方式

ExeAction

在容器内部执行一个命令，如果返回值为 0，则任务容器时健康的。

1
2
3
4
5
livenessProbe:
  exec:
    command:
      - cat
      - /health
TCPSocketAction

通过 tcp 连接监测容器内端口是否开放，如果开放则证明该容器健康

1
2
3
livenessProbe:
  tcpSocket:
    port: 80
HTTPGetAction

生产环境用的较多的方式，发送 HTTP 请求到容器内的应用程序，如果接口返回的状态码在 200~400 之间，则认为容器健康。

1
2
3
4
5
6
7
8
9
livenessProbe:
  failureThreshold: 5
  httpGet:
    path: /health
    port: 8080
    scheme: HTTP
    httpHeaders:
      - name: xxx
        value: xxx

参数配置

initialDelaySeconds: 60 # 初始化时间
timeoutSeconds: 2 # 超时时间
periodSeconds: 5 # 监测间隔时间
successThreshold: 1 # 检查 1 次成功就表示成功
failureThreshold: 2 # 监测失败 2 次就表示失败

生命周期

image-20240320155720161

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
lifecycle:
  postStart: # 容创建完成后执行的动作，不能保证该操作一定在容器的 command 之前执行，一般不使用
    exec: # 可以是 exec / httpGet / tcpSocket
      command:
        - sh
        - -c
        - 'mkdir /data'
  preStop: # 在容器停止前执行的动作
    httpGet: # 发送一个 http 请求
      path: /
      port: 80
    exec: # 执行一个命令
      command:
        - sh
        - -c
        - sleep 9

Pod退出流程

删除操作

  • Endpoint删除pod的ip地址

  • Pod变成Terminating状态

    变为删除中的状态后，会给 pod 一个宽限期，让 pod 去执行一些清理或销毁操作。

    配置参数：

    1
    2
    3
    4
    # 作用与 pod 中的所有容器
    terminationGracePeriodSeconds: 30
    containers:
      - xxx

  • 执行preStop的执行

PreStop的应用

如果应用销毁操作耗时需要比较长，可以在 preStop 按照如下方式进行配置

1
2
3
4
5
6
preStop:
 exec:
  command:
    - sh
    - -c
    - 'sleep 20; kill pgrep java'

但是需要注意，由于 k8s 默认给 pod 的停止宽限时间为 30s，如果我们停止操作会超过 30s 时，不要光设置 sleep 50，还要将
terminationGracePeriodSeconds: 30 也更新成更长的时间，否则 k8s 最多只会在这个时间的基础上再宽限几秒，不会真正等待 50s

  • 注册中心下线
  • 数据清理
  • 数据销毁