文章目录

  • kubernetes06（pod的生命周期）
  • 一.引子
  • 二.pod的生命周期
  • （一）.pod简介
  • （二）.pause容器和init容器
  • （三）.pod的生命周期


kubernetes06（pod的生命周期）

一.引子

再kubernetes开篇的时候,笔者给大家介绍了pod这个Kubernetes可以调度的最小单位.本篇笔者带大家走进pod的生命周期的世界.

二.pod的生命周期

（一）.pod简介

Pod 是 kubernetes 系统的基础单元，是由用户创建或部署的最小组件，也是 kubernetes 系统上运行容器化应用的资源对象。Kubernetes 集群中其他资源对象都是为 pod 这个资源对象做支撑来实现 kubernetes 管理应用服务的目的。Kubernetes 集群组件主要包括主节点组件API Server、Controller Manager、Scheduler 以及子节点组件 kubelet、container Runtime（如docker）、kube-proxy 等。

（二）.pause容器和init容器

在了解pod的生命周期之前我们必须要了解pause容器和init容器。

1.pause容器

Pause容器，又叫Infra容器。我们检查node节点的时候会发现每个node上都运行了很多的pause容器。pod容器之间的通信就是通过pause进行的。

kubernetes中的pause容器主要为每个业务容器提供以下功能：

  • 在pod中担任Linux命名空间共享的基础；
  • 启用pid命名空间，开启init进程。
[root@k8s-node01 ~]# docker ps |grep pause
0cbf85d4af9e    k8s.gcr.io/pause:3.1   "/pause"     7 days ago  Up 7 days   k8s_POD_myapp-848b5b879b-ksgnv_default_0af41a40-a771-11e8-84d2-000c2972dc1f_0
d6e4d77960a7    k8s.gcr.io/pause:3.1   "/pause"     7 days ago  Up 7 days   k8s_POD_myapp-848b5b879b-5f69p_default_09bc0ba1-a771-11e8-84d2-000c2972dc1f_0
5f7777c55d2a    k8s.gcr.io/pause:3.1   "/pause"     7 days ago  Up 7 days   k8s_POD_kube-flannel-ds-pgpr7_kube-system_23dc27e3-a5af-11e8-84d2-000c2972dc1f_1
8e56ef2564c2    k8s.gcr.io/pause:3.1   "/pause"     7 days ago  Up 7 days   k8s_POD_client2_default_17dad486-a769-11e8-84d2-000c2972dc1f_1
7815c0d69e99    k8s.gcr.io/pause:3.1   "/pause"     7 days ago  Up 7 days   k8s_POD_nginx-deploy-5b595999-872c7_default_7e9df9f3-a6b6-11e8-84d2-000c2972dc1f_2
b4e806fa7083    k8s.gcr.io/pause:3.1   "/pause"     7 days ago  Up 7 days   k8s_POD_kube-proxy-vxckf_kube-system_23dc0141-a5af-11e8-84d2-000c2972dc1f_2

2.init容器

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

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

  • Init 容器总是运行到成功完成为止。
  • 每个 Init 容器都必须在下一个 Init 容器启动之前成功完成。
  • 如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy 为 Never，它不会重新启动。

（三）.pod的生命周期

1.pod生命周期中的状态（status）

  • 挂起（Pending）：APIServer创建了Pod资源对象并已经存入了etcd中，但是它并未被调度完成，或者仍然处于从仓库下载镜像的过程中。
  • 运行中（Running）：Pod已经被调度到某节点之上，并且所有容器都已经被kubelet创建完成。
  • 成功（Succeeded）：Pod 中的所有容器都被成功终止，并且不会再重启。
  • 失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
  • 未知（Unknown）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。

为pod里的容器绑定卷 pod pause容器_Pod


2.pod创建过程中与API Server及schedule交互

（1）.API Server交互

API Server 提供了集群与外部交互的接口，通过 kubectl 命令或者其他 API 客户端提交 pod spec 给 API Server 作为pod创建的起始。Pod 与 API Server 交互的主要流程如下：

  • 1.API Server 在接收到创建pod的请求之后，会根据用户提交的参数值来创建一个运行时的pod对象。
  • 2.根据 API Server 请求的上下文的元数据来验证两者的 namespace 是否匹配，如果不匹配则创建失败。
  • 3.Namespace 匹配成功之后，会向 pod 对象注入一些系统数据，如果 pod 未提供 pod 的名字，则 API Server 会将 pod 的 uid 作为 pod 的名字。
  • 4.API Server 接下来会检查 pod 对象的必需字段是否为空，如果为空，创建失败。
  • 5.上述准备工作完成之后会将在 etcd 中持久化这个对象，将异步调用返回结果封装成 restful.response，完成结果反馈。

至此，API Server 创建过程完成，剩下的由 scheduler 和 kubelet 来完成，此时 pod 处于 pending 状态。

（2）.与scheduler交互

当提交创建 pod 的请求与 API Server 的交互完成之后，接下来由 scheduler 进行工作，该组件主要是完成 pod 的调度来决定 pod 具体运行在集群的哪个节点上。注意，此处声明一点，API Server 完成任务之后，将信息写入到 etcd 中，此时 scheduler 通过 watch 机制监听到写入到 etcd 的信息然后再进行工作。Scheduler 读取到写入到 etcd 中的 pod 信息，然后基于一系列规则从集群中挑选一个合适的节点来运行它，调度时主要通过三步来确定 pod 运行节点：

  • 1.节点预选：基于一系列预选规则（如 PodFitsResource 和 MatchNode-Selector 等）对每个节点进行检查，将不符合的节点过滤掉从而完成节点预选。
  • 2.节点优选：对预选出的节点进行优先级排序，以便选出最适合运行 pod 对象的节点。
  • 3.从优先级结果中挑选出优先级最高的节点来运行 pod 对象，当此类节点多个时则随机选择一个。

3.pod的启动(kubelet启动pod流程分析)

kubelet 通过 API Server 监听 etcd 目录，同步 pod 列表。如果发现有新的 pod 绑定到本节点，则按照 pod 清单要求创建 pod，如果是发现 pod 被更新，则做出相应更改。读取到 pod 的信息之后，如果是创建和修改 pod 的任务，则做如下处理：

  • 1.为该 pod 创建一个数据目录
  • 2.从 API Server 读取该 pod 清单
  • 3.为该 pod 挂载外部卷
  • 4.下载 pod 所需的 Secret
  • 5.检查已经运行在节点中 pod，如果该 pod 没有容器或者 Pause 容器没有启动，则先停止pod里所有的容器进程。
  • 6.使用 pause 镜像为每个pod创建一个容器，该容器用于接管 Pod 中所有其他容器的网络。
  • 7.为 pod 中的每个容器做如下处理：1.为容器计算一个 hash 值，然后用容器的名字去查询对于 docker 容器的 hash 值。若查找到容器，且两者的 hash 值不同，则停止 docker 中容器中进程，并停止与之关联的 pause容器，若相同，则不做处理。若容器被终止了，且容器没有指定的重启策略，则不做任何处理调用 docker client 下载容器镜像，并启动容器。

4.pod的存活性探测

（4）Pod存活性探测

在pod生命周期中可以做的一些事情。主容器启动前可以完成初始化容器，初始化容器可以有多个，他们是串行执行的，执行完成后就推出了，在主程序刚刚启动的时候可以指定一个post start 主程序启动开始后执行一些操作，在主程序结束前可以指定一个 pre stop 表示主程序结束前执行的一些操作。在程序启动后可以做两类检测 liveness probe（存活性探测） 和 readness probe（就绪性探测）。如下图：

为pod里的容器绑定卷 pod pause容器_Server_02

探针是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的Handler。其探测的方法有以下三种：

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

（1.）设置exec探针：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness-exec
  name: liveness-exec
spec:
  containers:
  - name: liveness-exec-demo
    image: busybox
    args: ["/bin/sh","-c","touch /tmp/healthy;sleep 60;rm -rf /tmp/healthy;"sleep 600]
    livenessProbe:
      exec:
        command: ["test","-e","/tmp/healthy"]

上面的资源清单中定义了一个Pod 对象， 基于 busybox 镜像 启动 一个 运行“ touch/ tmp/ healthy； sleep 60； rm- rf/ tmp/ healthy； sleep 600” 命令 的 容器， 此 命令 在 容器 启动 时 创建/ tmp/ healthy 文件， 并于 60 秒 之后 将其 删除。 存活 性 探针 运行“ test -e/ tmp/ healthy” 命令 检查/ tmp/healthy 文件 的 存在 性， 若 文件 存在 则 返回 状态 码 0， 表示 成功 通过 测试。

（2.）设置HTTP探针：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness-http
  name: liveness-http
spec:
  containers:
  - name: liveness-http-demo
    image: nginx:1.12-alpine
    ports:
    - name: http
      containerPort: 80
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh","-c","echo healthy > /usr/share/nginx/html/healthy"]
    livenessProbe:
      httpGet:
        path: /healthy
        port: http
        scheme: HTTP

上面 清单 文件 中 定义 的 httpGet 测试 中， 请求 的 资源 路径 为“/ healthy”， 地址 默认 为 Pod IP， 端口 使用 了 容器 中 定义 的 端口 名称 HTTP， 这也 是 明确 为 容器 指明 要 暴露 的 端口 的 用途 之一。

（3.）设置TCP探针举例：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness-tcp
  name: liveness-tcp
spec:
  containers:
  - name: liveness-tcp-demo
    image: nginx:1.12-alpine
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      tcpSocket:
        port: http

上面的资源清单文件，向Pod IP的80/tcp端口发起连接请求，并根据连接建立的状态判断Pod存活状态。

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

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

Kubelet 可以选择是否执行在容器上运行的两种探针执行和做出反应：

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

此篇翻过，相信大家对pod的基础和其生命周期有了一定的了解。那pod的生命周期是由哪些组件控制的呢。下一篇，我们进行控制pod生命周期的组件的讲解。