容器的生命周期

一、容器的生命周期

在这里插入图片描述

二、组成介绍

2.1 Init容器

Pod能够具有多个容器，应用运行在容器里面。但是它也可能有一个或多个先于应用容器启动的Init容器

Init容器与普通容器非常相像，除了以下两点：

Init容器总是运行到成功完成为止
每个Init容器都必须在下一个Init容器启动之前成功完成

如果Pod的Init容器失败，Kubernetes会不断地重启该Pod，直到Init容器成功为止。然而，如果Pod对应的restartPolicy为Never，它不会重新启动

Init容器模版

apiVersion:v1
kind:Pod
metadata:
  name:myapp-pod
  labels:
    app:myapp
spec:
  containers:
 - name:myapp-container
	images:busybox
	command:["sh", "-c", "echo The App is Running! && 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;"]

特别说明：

在Pod启动过程中，Init容器会按照顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出
如果由于运行时或失败退出，将导致容器启动失败，Init容器会根据Pod的restartPolicy指定的策略进行重试
在所有的Init容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集（即多个Init容器端口相同并不会冲突，因为Init容器运行成功后就会退出，再启动下一个Init容器）。正在初始化中的Pod处于Pending状态，但应该会将Initializing状态设置为true
如果Pod重启，所有Init容器必须重启
对Init容器 spec 的修改被限制在容器image字段，修改其他字段都不会生效。更改Init容器的image字段，等价于重启该Pod
Init容器具有应用容器的所有字段，除了readinessProbe。因为Init容器无法定义不同于完成（completion）的就绪（readiness）之外的其他状态。这会在验证中强制执行（？？？）
在Pod中的每个app 和 Init容器的名称必须唯一；与任何其他容器共享同一个名称，会在验证时抛出错误

2.2 容器探针

探针是由kubelet对容器执行的定期诊断。要执行诊断，kubelet调用由容器实现的Handler。

存在三种类型的处理程序：

ExecAction：在容器内执行指定命令，如果命令退出时返回码为0则认为诊断成功
TCPSocketAction：对指定端口上的容器IP地址进行TCP检查。如果端口打开，则诊断被认为是成功的
HTTPGetAction：对指定的端口和路径上的容器的IP地址执行HTTP Get请求。如果响应的状态码大于等于200 且小于400，则诊断被认为是成功的

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

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

探测方式：

livenessProbe：指示容器是否正在运行。如果存活探测失败，则kubelet会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success
readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与Pod匹配的所有Service的端点中删除该Pod的IP地址。初始延迟之前的就绪状态默认为Failure。如果容器不提供该就绪探针，则默认状态为Success

举例1：就绪探针

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

举例2：存活检测

apiVersion:v1
kind:Pod
metadata:
  name:liveness-exec-pod
  namespace:default
spec:
  containers:
 - name:liveness-exec-container
    image:hub.atguigu.com/library/busybox
    imagePullPolicy:IfNotPresentports
    command:["/bin/sh","-c","touch /tmp/live;sleep 60;rm -rf /tmp/live;sleep 3600"]
    livenessProbe:
      exec:
        command:["test","-e", "/tmp/live"]
      initialDelaySeconds:1
      periodSceonds:3

2.3 Pod phase（终止）可能存在的值

挂起（Pending）：Pod已被Kubernetes系统接受，但是有一个或多个容器镜像尚未创建。等待时间包括调度Pod的时间和通过网络下载镜像的时间，这可能需要花点时间
运行中（Running）：该Pod已经绑定到了一个节点上，Pod中所有的容器都已经被创建。至少有一个容器正在运行，或者正处于启动或重启状态
成功（Succeeded）：Pod中所有容器都被成功终止，并不会再重启
失败（Failed）：Pod中所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止
未知（Unknown）：因为某些原因无法取得Pod的状态，通常因为与Pod所在主机通信失败

2.4 Pod分类

自主式Pod：Pod退出了，此类型的Pod不会被创建
控制器管理的Pod：在控制器的生命周期里，始终要维持Pod的副本数目