关于kubernetes:Kubernetes中Pod的生命周期

Pod 生命周期之 Init 容器

Init 容器

Pod 可能具备多个容器，利用运行在容器外面，然而它可能有一个或多个先于利用容器启动的 Init 容器

Init 容器于一般的容器十分像，除了如下两点：

• Init 容器总是运行到胜利实现为止
• 每个 Init 容器都必须在下一个 Init 容器启动之前胜利实现

如果 Pod 的 Init 容器失败，Kubernetes 会一直地重启该 Pod，直到 Init 容器胜利为止，然而，如果 Pod 对应的 restartPolicy 为 Nerver，它不会重新启动

因为 Init 容器具备与应用程序容器拆散的独自镜像，所以它们的启动相干代码具备如下劣势：

• 它们能够蕴含并运行实用工具，然而出于平安思考，是不倡议在应用程序容器中蕴含这些实用工具的
• 它们能够蕴含实用工具和定制化来装置，然而不能呈现在应用程序镜像中，例如，创立镜像没必要 FROM 另一个镜像，只须要在装置过程中应用相似 sed、awk、python 或 dig 这样的工具
• 应用程序镜像能够拆散出创立和部署的角色，而没有必要联结它们构建一个独自的镜像
• Init 容器应用 Linux Namespace，所以绝对应用程序容器来说具备不同的文件系统视图，因而，它们可能具备拜访 Secret 的权限，而应用程序容器则不能
• 它们必须在应用程序容器启动之前运行实现，而应用程序容器是并行运行的，所以 Init 容器可能提供一中简略的阻塞或提早应用程序容器的启动办法，直到满足了一组先决条件

Init 模板

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh','-c', 'echo The app is runing! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh','-c','until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox
    command: ['sh','-c','until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
---
kind: Service
apiVersion: v1
metadata:
  name: mydb
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9377

非凡阐明

• 在 Pod 启动过程中，Init 容器会按程序在网络和数据卷初始化（pause) 之后启动，每个容器必须在下一个容器启动之前胜利退出
• 如果因为运行时或失败退出，将导致容器启动事变，它会依据 Pod 的 restartPolicy 指定的策略进行重启，然而，如果 Pod 的 restartPolicy 设置为 Always，Init 容器失败时会应用 RestartPolicy 策略
• 在所有的 Init 容器没有胜利之前，Pod 将不会变成 Ready 状态，Init 容器的端口将不会在 Service 中进行汇集。正在初始化的 Pode 出于 Pending 状态，但应该会将 Initalizing 状态设置为 true
• 如果 Pod 重启，所有 Init 容器必须从新执行
• 对 Init 容器 spec 的批改被限度在容器 image 字段，批改其余字段都不会失效，更改 Init 容器的 image 字段，等价于重启该 Pod
• Init 容器具备利用容器的所有字段，除了 readinessProbe，因为 Init 容器无奈定义不同于实现（completion）的就绪（readiness）之外的其余状态，这会在验证过程中强制执行
• 在 Pod 中的每个 app 和 Init 容器的名称必须惟一，与任何其余容器共享一个名称，会在验证时抛出谬误

Pod 生命周期之容器探针

探针时有 kubelet 对容器执行的定期诊断，要执行诊断，kubelet 调用由容器实现的 Handler。有三种类型的处理程序：

• ExecAction：在容器内执行指定命令，如果命令退出时返回码为 0，则认为诊断胜利
• TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检测，如果端口关上，则诊断被认为时胜利的
• HTTPGetAction：对指定的端口和门路上的容器的 IP 地址执行 Get 申请，如果响应的状态码大于等于 200 且小于 400，则诊断被认为时胜利的

每次探测都将取得以下三种后果之一：

• 胜利：容器通过了诊断
• 失败：容器未通过诊断
• 未知：诊断失败，因而不会采取任何口头

livenessProbe 探针

批示容器是否正在运行，如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到重启策略的影响，如果容器不提供存活探针，则默认状态为 Success

存活检测

livenessProbe-exec

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
  namespace: dafault
spec:
  containers:
  - name: liveness-exec-container
  image: busybox
  imagePullPolicy: IfNotPresent
  command: ['/bin/sh','-c',"touch /tmp/live; sleep 60; rm -rf /tmp/live; sleep 3600"]
  livenessProbe:
    exec:
      command: ["test","-c","/tmp/live"]
    initialDeyaySeconds: 1
    periodSeconds: 3

livenessProbe-httpget

apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget-pod
  namespace: default
spec:
  containers:
  - name: liveness-httpget-container
    image: myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1
      periodSenconds: 3
      timeoutSeconds: 10

lienessProbe-tcp

apiVersion: v1
kind: Pod
metadata:
  name: probe-tcp
spec:
  containers:
  - name: nginx
    image: myapp:v1
    livenessProbe:
      initialDelaySeconds: 5
      timeoutSeconds: 1
      tcpSocket:
        port: 8080
      periodSeconds: 3

readinessProbe

批示容器是否筹备好服务申请，如果就绪探针失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址，初始提早之前的就绪状态默认为 Failure，如果容器不提供就绪探针，则默认状态为 Success

就绪检测

readinessProbe-httpget

apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget-pod
  namespace: default
spec:
  containers:
  - name: readiness-httpget-container
  image: myapp:v1
  imagePullPolicy: IfNotPresent
  readinessProbe:
    httpGet:
      port: http
      path: /index1.html
    initialDelaySeconds: 1
    periodSeconds: 3

Pod 生命周期之启动退出

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: myapp:v1
    lifecycle:
      postStart:
        exec:
          command: ["/bin/bash", "-c","echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/usr/sbin/nginx","-s","quit"]

Pod 生命周期之 Pod 的状态

• 挂起（Pending）：Pod 已被 Kubernetes 零碎承受，但有一个或者多个容器镜像尚未创立，等待时间包含调度 Pod 的工夫和通过网络下载镜像的工夫
• 运行中（Runing）：该 Pod 曾经绑定到一个节点上，Pod 中所有的容器都已被创立，至多有一个容器正在运行，或者正处于启动或重启状态
• 胜利（Successed）：Pod 中的所有容器都被胜利终止，并且不会重启
• 失败（Failed）：Pod 中的所有容器都曾经终止了，并且至多有一个容器是因为失败终止，也就是说容器已非 0 状态退出或者被零碎终止
• 未知（Unknown）：因为某些起因无奈获得 Pod 的状态，通常因为与 Pod 所在主机通信失败