Kubernetes之POD

什么是Pod

Pod是可以创建和管理Kubernetes计算的最小可部署单元。一个Pod代表着集群中运行的一个进程。

Pod就像是豌豆荚一样，它由一个或者多个容器组成（例如Docker容器），它们共享容器存储、网络和容器运行配置项。Pod中的容器总是被同时调度，有共同的运行环境。你可以把单个Pod想象成是运行独立应用的“逻辑主机”——其中运行着一个或者多个紧密耦合的应用容器——在有容器之前，这些应用都是运行在几个相同的物理机或者虚拟机上。

尽管kubernetes支持多种容器运行时，但是Docker依然是最常用的运行时环境，我们可以使用Docker的术语和规则来定义Pod。

Pod中共享的环境包括Linux的namespace，cgroup和其他可能的隔绝环境，这一点跟Docker容器一致。在Pod的环境中，每个容器中可能还有更小的子隔离环境。

Pod中的容器共享IP地址和端口号，它们之间可以通过localhost互相发现。它们之间可以通过进程间通信，例如SystemV信号或者POSIX共享内存。不同Pod之间的容器具有不同的IP地址，不能直接通过IPC通信。

Pod中的容器也有访问共享volume的权限，这些volume会被定义成pod的一部分并挂载到应用容器的文件系统中。

就像每个应用容器，pod被认为是临时实体。在Pod的生命周期中，pod被创建后，被分配一个唯一的ID（UID），调度到节点上，并一致维持期望的状态直到被终结（根据重启策略）或者被删除。如果node死掉了，分配到了这个node上的pod，在经过一个超时时间后会被重新调度到其他node节点上。一个给定的pod（如UID定义的）不会被“重新调度”到新的节点上，而是被一个同样的pod取代，如果期望的话甚至可以是相同的名字，但是会有一个新的UID（查看replication controller获取详情）。

Pod中如何管理多个容器

Pod中可以同时运行多个进程（作为容器运行）协同工作。同一个Pod中的容器会自动的分配到同一个 node 上。同一个Pod中的容器共享资源、网络环境和依赖，它们总是被同时调度。

注意在一个Pod中同时运行多个容器是一种比较高级的用法。只有当你的容器需要紧密配合协作的时候才考虑用这种模式。例如，你有一个容器作为web服务器运行，需要用到共享的volume，有另一个“sidecar”容器来从远端获取资源更新这些文件。如图

Pod中可以共享两种资源

网络每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）。
存储可以Pod指定多个共享的Volume。Pod中的所有容器都可以访问共享的volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。

使用Pod

我通常把pod分为两类：

自主式Pod 这种Pod本身是不能自我修复的，当Pod被创建后（不论是由你直接创建还是被其他Controller），都会被Kuberentes调度到集群的Node上。直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上。Pod不会自愈。如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除。同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。
控制器管理的Pod Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例。Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的。

上图所示是Pod的组成示意图，我们看到每个Pod都有一个特殊的被称为“根容器”的Pause 容器。 Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或者多个紧密相关的用户业务容器。

Pod的终止

因为Pod作为在集群的节点上运行的进程，所以在不再需要的时候能够优雅的终止掉是十分必要的（比起使用发送KILL信号这种暴力的方式）。用户需要能够放松删除请求，并且知道它们何时会被终止，是否被正确的删除。用户想终止程序时发送删除pod的请求，在pod可以被强制删除前会有一个宽限期，会发送一个TERM请求到每个容器的主进程。一旦超时，将向主进程发送KILL信号并从API server中删除。如果kubelet或者container manager在等待进程终止的过程中重启，在重启后仍然会重试完整的宽限期。

示例流程如下：

用户发送删除pod的命令，默认宽限期是30秒；
在Pod超过该宽限期后API server就会更新Pod的状态为“dead”；
在客户端命令行上显示的Pod状态为“terminating”；
跟第三步同时，当kubelet发现pod被标记为“terminating”状态时，开始停止pod进程：1 如果在pod中定义了preStop hook，在停止pod前会被调用。如果在宽限期过后，preStop hook依然在运行，第二步会再增加2秒的宽限期；2 向Pod中的进程发送TERM信号；
跟第三步同时，该Pod将从该service的端点列表中删除，不再是replication controller的一部分。关闭的慢的pod将继续处理load balancer转发的流量；
过了宽限期后，将向Pod中依然运行的进程发送SIGKILL信号而杀掉进程。
Kublete会在API server中完成Pod的的删除，通过将优雅周期设置为0（立即删除）。Pod在API中消失，并且在客户端也不可见。

删除宽限期默认是30秒。 kubectl delete命令支持 --grace-period=<seconds> 选项，允许用户设置自己的宽限期。如果设置为0将强制删除pod。在kubectl>=1.5版本的命令中，你必须同时使用 --force 和 --grace-period=0 来强制删除pod。

Pause 容器

在接触Kubernetes的初期，便知道集群搭建需要下载一个gcr.io/google_containers/pause-amd64:3.0镜像，然后每次启动一个容器，都会伴随一个pause容器的启动。

但这个pause容器的功能是什么，它是如何做出来的，以及为何都伴随容器启动等等。这些问题一直在我心里，如今有缘学习相关内容。

189fbd12e903        rancher/rancher-agent:v2.0.6                                                                                           "run.sh -- share-r..."    days ago         Exited ()  days ago                              share-mnt

[root@k8s-master ~]# docker ps -a | grep pause-amd64

f30cc4df0eff        rancher/pause-amd64:3.1                                                                                                "/pause"                  days ago          Up  days                                      k8s_POD_confserver-bdf79c8cb-xxf82_confserver_f92c3ecc-a11b-11e8-a1c4-005056936694_0

af651c01f1e4        rancher/pause-amd64:3.1                                                                                                "/pause"                  days ago          Up  days                                      k8s_POD_jenkins-5cf89c84f6-h4hs6_jenkins_954201e0-a057-11e8-a1c4-005056936694_0

7ab1920551ca        rancher/pause-amd64:3.1                                                                                                "/pause"                  days ago         Up  days                                     k8s_POD_nfs-provisioner-2cjpp_nfs-provisioner_a24395b7-9c42-11e8-a1c4-005056936694_0

4f89f1c2e83b        rancher/pause-amd64:3.1                                                                                                "/pause"                  days ago         Up  days                                     k8s_POD_cattle-node-agent-s8s75_cattle-system_a2443a27-9c42-11e8-a1c4-005056936694_0

74ff9a7eb776        rancher/pause-amd64:3.1                                                                                                "/pause"                  days ago         Up  days                                     k8s_POD_nginx-ingress-controller-gl7k6_ingress-nginx_a239056d-9c42-11e8-a1c4-005056936694_0

76a3177f05ec        rancher/pause-amd64:3.1                                                                                                "/pause"                  days ago         Up  days                                     k8s_POD_calico-node-7vzlj_kube-system_a2391472-9c42-11e8-a1c4-005056936694_0

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

在pod中担任Linux命名空间共享的基础；
启用pid命名空间，开启init进程。

Pod 的生命周期

Pod phase

Pod 的 status 在信息保存在 Podstatus 中定义，其中有一个 phase 字段。

Pod 的相位（phase）是 Pod 在其生命周期中的简单宏观概述。该阶段并不是对容器或 Pod 的综合汇总，也不是为了做为综合状态机。

Pod 相位的数量和含义是严格指定的。除了本文档中列举的状态外，不应该再假定 Pod 有其他的 phase 值。

下面是 phase 可能的值：

值	描述
Pending	Pod已被Kubernetes系统接受，但尚未创建一个或多个Container图像。这包括计划之前的时间以及通过网络下载图像所花费的时间，这可能需要一段时间
Running	Pod已绑定到节点，并且已创建所有Container。至少有一个Container仍在运行，或者正在启动或重新启动
Succeeded	Pod中的所有容器都已成功终止，并且不会重新启动
Failed	Pod中的所有容器都已终止，并且至少有一个Container已终止失败。也就是说，Container要么退出非零状态，要么被系统终止
Unknown	由于某种原因，无法获得Pod的状态，这通常是由于与Pod的主机通信时出错

下图是Pod的生命周期示意图，从图中可以看到Pod状态的变化。

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

POD的重启策略

restartPolicy:

Always 默认策略
OnFailure 只有状态错误的时候重启（正常退出不会重启）
Never 重来不重启

Pod条件

Pod有一个PodStatus，它有一个PodConditions 数组， Pod已经或没有通过它。PodCondition数组的每个元素都有六个可能的字段：

该lastProbeTime字段提供上次探测Pod条件的时间戳。
该lastTransitionTime字段提供Pod最后从一个状态转换到另一个状态的时间戳
该message字段是人类可读的消息，指示有关转换的详细信息
该reason字段是该条件最后一次转换的唯一，单字，CamelCase原因
该status字段是一个字符串，可能的值为“ True”，“ False”和“ Unknown”
该type字段是一个包含以下可能值的字符串:
- PodScheduled：Pod已被安排到一个节点;
- Read: Pod能够提供请求，应该添加到所有匹配服务的负载平衡池中;
- Initialized：所有init容器都已成功启动；
- Unschedulable：调度程序现在无法调度Pod，例如由于缺少资源或其他限制
- ContainersReady：Pod中的所有容器都已准备就绪

容器探针

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

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

每个探针都有三个结果之一：

成功：Container通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不应采取任何措施。

kubelet可以选择在运行容器上执行两种探测并对其做出反应：

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

什么时候应该使用livenessProbe或readinessProbe探针？

如果您的Container中的进程在遇到问题或变得不健康时自行崩溃，则不一定需要存活探测器; kubelet将根据Pod的restartPolicy自动执行正确的操作。

如果您希望在容器探测失败时杀死并重新启动，则指定存活探测，并指定restartPolicy为Always或OnFailure。

如果您只想在探测成功时开始向Pod发送流量，请指定就绪探测。在这种情况下，就绪探针可能与存活探测相同，但spec中就绪探针的存在意味着Pod将在不接收任何流量的情况下启动，并且仅在探针探测成功后才开始接收流量。

如果Container需要在启动期间处理大型数据，配置文件或迁移，请指定就绪探针。

如果您希望Container能够自行维护，您可以指定一个就绪探针，该探针检查特定于就绪的端点，该端点与活动探针不同。

请注意，如果您只想在Pod被删除时排除请求，则不一定需要就绪探测; 在删除Pod时，无论是否存在就绪探针，Pod都会自动将其置于未完成状态。当等待 Pod 中的容器停止时，Pod 仍处于未完成状态。

`livenessProbe`详解

kubectl explain pod.spec.containers.livenessProbe

exec command 的方式探测例如 ps 一个进程
failureThreshold 探测几次失败才算失败默认是连续三次
periodSeconds 每次的多长时间探测一次默认10s
timeoutSeconds 探测超市的秒数默认1s
initialDelaySeconds 初始化延迟探测，第一次探测的时候，因为主程序未必启动完成
tcpSocket 检测端口的探测
httpGet http请求探测

案例

apiVersion: v1

kind: Pod

metadata:

  name: liveness-exec-pod

  namespace: default

  labels:

    name: myapp

spec:

  containers:

  - name: livess-exec

    image: busybox:latest

    imagePullPolicy: IfNotPresent

    command: ["/bin/sh","-c","touch /tmp/test; sleep 30; rm -f /tmp/test; sleep 3600"]

    livenessProbe:

      exec:

        command: ["test","-e","/tmp/test"]

      initialDelaySeconds:

      periodSeconds:

看一下描述信息

$  kubectl describe pods liveness-exec-pod

......

   Command:

      /bin/sh

      -c

      touch /tmp/test; sleep ; rm -f /tmp/test; sleep

    State:        Running

      Started:        Thu,  Aug  :: -

    Last State:        Terminated

      Reason:        Error

      Exit Code:

      Started:        Thu,  Aug  :: -

      Finished:        Thu,  Aug  :: -

    Ready:        True

    Restart Count:        重启次数一次（会叠加）

    Liveness:        exec [test -e /tmp/test] delay=1s timeout=1s period=3s #success= #failure=   失败3次

    Environment:    <none>

.....

$ kubectl get pods

NAME                     READY     STATUS    RESTARTS   AGE

jdk-94bcfc779-fs2cl      /       Running             9d

liveness-exec-pod        /       Running     (重启三次了)        4m

httpGet 案例

apiVersion: v1

kind: Pod

metadata:

  name: liveness-httpget-pod

  namespace: default

  labels:

    name: myapp

spec:

  containers:

  - name: livess-httpget

    image: ikubernetes/myapp:v1

    ports:

    - name: http

      containerPort:

    imagePullPolicy: IfNotPresent

    livenessProbe:

      httpGet:

        port: http

        path: /index.html

      initialDelaySeconds:

      periodSeconds:

readiness`Probe`详解

kubectl explain pod.spec.containers.readinessProbe

exec command 的方式探测例如 ps 一个进程
failureThreshold 探测几次失败才算失败默认是连续三次
periodSeconds 每次的多长时间探测一次默认10s
timeoutSeconds 探测超市的秒数默认1s
initialDelaySeconds 初始化延迟探测，第一次探测的时候，因为主程序未必启动完成
tcpSocket 检测端口的探测
httpGet http请求探测

案例

apiVersion: v1

kind: Pod

metadata:

  name: readiness-httpget-pod

  namespace: default

  labels:

    name: myapp

spec:

  containers:

  - name: readiness-httpget

    image: ikubernetes/myapp:v1

    ports:

    - name: http

      containerPort:

    imagePullPolicy: IfNotPresent

    readinessProbe:

      httpGet:

        port: http

        path: /index.html

      initialDelaySeconds:

      periodSeconds:

详情

Name:        readiness-httpget-pod

Namespace:    default

Node:        rancher-node/172.16.138.170

Start Time:    Sun,  Aug  :: -

Labels:        name=myapp

Annotations:    cni.projectcalico.org/podIP=10.42.0.194/

        kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"labels":{"name":"myapp"},"name":"readiness-httpget-pod","namece":"default"},"spec":{"c...

Status:        Running

IP:        10.42.0.194

Controllers:    <none>

Containers:

  readiness-httpget:

    Container ID:    docker://7eacd3604aa53352e9d744a33b527a35b6a4e21e5a47b26c5d1e6ead7f045c3f

    Image:        ikubernetes/myapp:v1

    Image ID:        docker-pullable://ikubernetes/myapp@sha256:9c3dc30b5219788b2b8a4b065f548b922a34479577befb54b03330999d30d513

    Port:        /TCP

    State:        Running

      Started:        Sun,  Aug  :: -

    Ready:        True

    Restart Count:

    Readiness:        http-get http://:http/index.html delay=1s timeout=1s period=3s #success=1 #failure=3

    Environment:    <none>

    Mounts:

      /var/run/secrets/kubernetes.io/serviceaccount from default-token-ws5gd (ro)

Conditions:

  Type        Status

  Initialized     True

  Ready     True

  PodScheduled     True

Volumes:
.....

lifecycle详解

极少数会用到

kubectl explain pod.spec.containers.lifecycle

postStart 启动后执行
preStop 终止前执行

同样是有三种类型

exec command 的方式例如初始化环境
httpGet http方式
tcpSocket TCP port 的方式

案例

apiVersion: v1

kind: Pod

metadata:

  name: lifecycle-poststart

  namespace: default

  labels:

    name: myapp

    tier: appfront

spec:

  containers:

  - name: lifecycle-poststart-pod

    image: nginx

    imagePullPolicy: IfNotPresent

    lifecycle:

      postStart:

        exec:

          command: ["/bin/sh","-c","echo Home+Page >> /usr/share/message"]

      preStop:

        exec:

          command: ["/usr/sbin/nginx","-s","quit"]