一、配置文件详解

创建Pod nginx样例

apiVersion: v1 # api文档版本
kind: Pod # 资源对象类型，Pod, Deployment,StatefulSet
metadata: # Pod相关的元数据，用于描述Pod的数据
  name: nginx-demo # Pod的名称
  labels: # 定义Pod的标签
    type: app # 自定义lable标签，名称为tyoe，值为app
    test: 1.0.0 # 自定义lable标签，描述Pod版本号
  namespace: 'default' # 命名空间的配置
spec: # 期望Pod按照这里的描述进行创建
  containers: # Pod中的容器描述
  - name: nginx # 容器名称
    image: arm64v8/nginx:latest # 指定容器的镜像
    imagePullPolicy: IfNotPresent # 镜像拉取策略，Always, Never, 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: '-Xms120m -Xmx128m' # 环境变量的值

    resources:
      requests: # 最少需要多少资源
        cpu: 100m # 限制cpu最多使用0.1个核心
        memory: 128Mi # 限制内存最少使用128兆
      limits: # 最多可以用多少资源
        cpu: 200m # 限制cpu最多使用0.2个核心
        memory: 256Mi # 限制最多使用256兆

  restartPolicy: OnFailure # pod重启策略，Always,OnFailure,Never,默认值为Always, OnFailure 只有pod非零推出码终止时，kubelet才会重启改容器，容器正常>结束的退出码为0

K8S 的资源清单

二、探针

为什么需要存活探针和就绪探针

上面的配置文件中，通过配置restartPolicy字段来对容器退出后执行3种不同的重启策略，但这并不能解决我们所有的问题，比如容器中的Java应用程序抛出OutOfMemoryErrors，但JVM进程会一致存在，容器并没有退出，再比如，Java停止响应或死锁，容器也没有终止等等，这时如果有一种机制来告诉kubernetes来重启容器那就最好了，在k8s中，提供了一种存活探针的机制来实现上诉的问题。

livenessProbe，叫做存活探针，是为了检测容器是否正在运行，是否活着；
readinessProbe，叫做就绪探针，是为了检测容器是否准备就绪，是否能接受客户端请求；
startupProbe，叫做启动探针，用于判断容器进程是否已经启动。

关于探针看这篇文章，写的太好了⬇️
pod健康检查之容器的存活探针、就绪探针

1、StartupProbe启动探针

k8s 1.16 版本新增的探针，用于判断应用程序是否已经启动了。
当配置了 startupProbe 后，会先禁用其他探针，直到 startupProbe 成功后，其他探针才会继续。

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

startupProbe:  #启动探针配置
  httpGet:  # 探测方式，基于http请求探测
    path: /api/startup # http请求路径
    port: 80 # 请求端口

2、LivenessProbe就绪探针

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

livenessProbe: #就绪探针配置
  httpGet: # 探测方式，基于http请求探测
    path: /health # http请求路径
    port: 8080 # 请求端口
    scheme: HTTP
  initialDelaySeconds: 60 # 初始延时，表示容器启动60秒后才开始探测
  failureThreshold: 5  # 失败多少次才算真正失败
  periodSeconds: 10 # 间隔时间
  successThreshold: 1 # 多少次检测成功才算成功
  timeoutSeconds: 5  # 请求的超时时间

3、ReadinessProbe存活探针

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

readinessProbe: # 存活探针配置
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP
  failureThreshold: 3 # 错误次数
  periodSeconds: 10 # 间隔时间
  successThreshold: 1 # 多少次检测成功才算成功
  timeoutSeconds: 1 # 请求的超时时间

4、三种探测方式

# 1.ExecAction 
# 在容器内部执行一个命令，如果返回值为 0，则任务容器时健康的。
livenessProbe:
  exec:
    command:
      - cat
      - /health

# 2.TCPSocketAction
# 通过 tcp 连接监测容器内端口是否开放，如果开放则证明该容器健康
livenessProbe:
  tcpSocket:
    port: 80

# 3.HTTPGetAction
# 生产环境用的较多的方式，发送 HTTP 请求到容器内的应用程序，如果接口返回的状态码在 200~400 之间，则认为容器健康。
livenessProbe:
  failureThreshold: 5
  httpGet:
    path: /health
    port: 8080
    scheme: HTTP
    httpHeaders:
      - name: xxx
        value: xxx

5、探针的附加参数配置

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

三、Pod生命周期

生命周期阅读这篇文章⬇️
pod生命周期以及探针介绍

深入Pod详解-LMLPHP

Pod 退出流程（删除操作）

Endpoint 删除 pod 的 ip 地址
Pod 变成 Terminating 状态
执行 preStop 的指令

PreStop 的应用

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

青衫落拓客

深入Pod详解