容器的生命周期

╰半橙微兮° 2023-01-11 08:41 120阅读 0赞

## 一、容器的生命周期 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70]

## 二、组成介绍 ##

### 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的副本数目

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzM0MjQxODYx_size_16_color_FFFFFF_t_70]: /images/20221119/509151797683442fa55c7f4b361effee.png