(五)Kubernetes Pod状态和生命周期管理

时间  2019-11-08
标签 kubernetes pod 状态 生命周期 管理 繁體版
原文   原文链接

什么是Pod

Pod是kubernetes中你能够建立和部署的最小也是最简的单位。Pod表明着集群中运行的进程。html

Pod中封装着应用的容器（有的状况下是好几个容器），存储、独立的网络IP，管理容器如何运行的策略选项。Pod表明着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一块儿共享资源。node

Docker是kubernetes中最经常使用的容器运行时，可是Pod也支持其余容器运行时。nginx

在Kubernetes集群中Pod有以下两种方式：web

  • 一个Pod中运行一个容器。“每一个Pod中一个容器”的模式是最多见的用法；在这种使用方式中，你能够把Pod想象成单个容器的封装，Kubernetes管理的是Pod而不是直接管理容器。vim

  • 在一个Pod中同时运行多个容器。一个Pod也能够同时封装几个须要紧密耦合互相协做的容器，它们之间共享资源。这些在同一个Pod中的容器能够互相协做成为一个service单位——一个容器共享文件，另外一个“sidecar”容器来更新这些文件。Pod将这些容器的存储资源做为一个实体来管理。api

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

Pod中的容器共享IP地址和端口号，它们之间能够经过localhost互相发现。它们之间能够经过进程间通讯，例如SystemV信号或者POSIX共享内存。不一样Pod之间的容器具备不一样的IP地址，不能直接经过IPC通讯。网络

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

就像每一个应用容器，pod被认为是临时（非持久的）实体。在Pod的生命周期中讨论过，pod被建立后，被分配一个惟一的ID（UID），调度到节点上，并一致维持指望的状态直到被终结（根据重启策略）或者被删除。若是node死掉了，分配到了这个node上的pod，在通过一个超时时间后会被从新调度到其余node节点上。一个给定的pod（如UID定义的）不会被“从新调度”到新的节点上，而是被一个一样的pod取代，若是指望的话甚至能够是相同的名字，可是会有一个新的UID。ide

Pod中如何管理多个容器

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

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

Pod中能够共享两种资源：网络和存储

网络：每一个pod都会被分配一个惟一的IP地址。Pod中的全部容器共享网络空间，包括IP地址和端口。Pod内部的容器可使用localhost互相通讯。Pod中的容器与外界通讯时，必须分配共享网络资源（例如使用宿主机的端口映射）。

存储：能够为一个Pod指定多个共享的Volume。Pod中的全部容器均可以访问共享的volume。Volume也能够用来持久化Pod中的存储资源，以防容器重启后文件丢失。

使用Pod

你不多会直接在kubernetes中建立单个Pod。由于Pod的生命周期是短暂的，用后即焚的实体。当Pod被建立后（不管是由你直接建立仍是被其它Controller），都会被Kubernetes调度到集群的Node上。直到Pod的进程终止、被删掉、由于缺乏资源而被驱逐、或者Node故障以前这个Pod都会一直保持在那个Node上。

注意：重启Pod中的容器跟重启Pod不是一回事。Pod只提供容器的运行环境并保持容器的运行状态，重启容器不会形成Pod重启。

Pod不会自愈。若是Pod运行的Node故障，或者是调度器自己故障，这个Pod就会被删除。一样的，若是Pod所在Node缺乏资源或者Pod处于维护状态，Pod也会被驱逐。Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例。虽然能够直接使用Pod，可是在Kubernetes中一般是使用Controller来管理Pod的。

Controller能够建立和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，若是一个Node故障，Controller就能自动将该节点上的Pod调度到其余健康的Node上。

Pod对象的生命周期

官方文档

中文文档

Pod对象自从其建立开始至其终止退出的时间范围称为其生命周期。在这段时间中，Pod会处于多种不一样的状态，并执行一些操做；其中，建立主容器（main container）为必需的操做，其余可选的操做还包括运行初始化容器（init container）、容器启动后钩子（post start hook）、容器的存活性探测（liveness probe）、就绪性探测（readiness probe）以及容器终止前钩子（pre stop hook）等，这些操做是否执行则取决于Pod的定义。以下图所示：

Pod phase

Pod的status字段是一个PodStatus的对象，PodStatus中有一个phase字段。

不管是手动建立仍是经过Deployment等控制器建立，Pod对象老是应该处于其生命进程中如下几个相位（phase）之一。

  • 挂起（Pending）：API Server建立了pod资源对象已存入etcd中，但它还没有被调度完成，或者仍处于从仓库下载镜像的过程当中。

  • 运行中（Running）：Pod已经被调度至某节点，而且全部容器都已经被kubelet建立完成。

  • 成功（Succeeded）：Pod中的全部容器都已经成功终止而且不会被重启

  • 失败（Failed）：Pod中的全部容器都已终止了，而且至少有一个容器是由于失败终止。即容器以非0状态退出或者被系统禁止。

  • 未知（Unknown）：Api Server没法正常获取到Pod对象的状态信息，一般是因为没法与所在工做节点的kubelet通讯所致。

Pod的建立过程

Pod是kubernetes的基础单元，理解它的建立过程对于了解系统运做大有裨益。以下图描述了一个Pod资源对象的典型建立过程。

  1. 用户经过kubectl或其余API客户端提交了Pod Spec给API Server。

  2. API Server尝试着将Pod对象的相关信息存入etcd中，待写入操做执行完成，API Server即会返回确认信息至客户端。

  3. API Server开始反映etcd中的状态变化。

  4. 全部的kubernetes组件均使用“watch”机制来跟踪检查API Server上的相关的变更。

  5. kube-scheduler（调度器）经过其“watcher”觉察到API Server建立了新的Pod对象但还没有绑定至任何工做节点。

  6. kube-scheduler为Pod对象挑选一个工做节点并将结果信息更新至API Server。

  7. 调度结果信息由API Server更新至etcd存储系统，并且API Server也开始反映此Pod对象的调度结果。

  8. Pod被调度到的目标工做节点上的kubelet尝试在当前节点上调用Docker启动容器，并将容器的结果状态返回送至API Server。

  9. API Server将Pod状态信息存入etcd系统中。

  10. 在etcd确认写入操做成功完成后，API Server将确认信息发送至相关的kubelet，事件将经过它被接受。

Pod生命周期中的重要行为

1）初始化容器

初始化容器（init container）即应用程序的主容器启动以前要运行的容器，经常使用于为主容器执行一些预置操做，它们具备两种典型特征。

1）初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes须要重启它直到成功完成。（注意：若是pod的spec.restartPolicy字段值为“Never”，那么运行失败的初始化容器不会被重启。）

2）每一个初始化容器都必须按定义的顺序串行运行。

2）容器探测

容器探测（container probe）是Pod对象生命周期中的一项重要的平常任务，它是kubelet对容器周期性执行的健康状态诊断，诊断操做由容器的处理器（handler）进行定义。Kubernetes支持三种处理器用于Pod探测：

  • ExecAction：在容器内执行指定命令，并根据其返回的状态码进行诊断的操做称为Exec探测，状态码为0表示成功，不然即为不健康状态。

  • TCPSocketAction：经过与容器的某TCP端口尝试创建链接进行诊断，端口可以成功打开即为正常，不然为不健康状态。

  • HTTPGetAction：经过向容器IP地址的某指定端口的指定path发起HTTP GET请求进行诊断，响应码为2xx或3xx时即为成功，不然为失败。

任何一种探测方式均可能存在三种结果：“Success”（成功）、“Failure”（失败）、“Unknown”（未知），只有success表示成功经过检测。

容器探测分为两种类型：

  • 存活性探测（livenessProbe）：用于断定容器是否处于“运行”（Running）状态；一旦此类检测未经过，kubelet将杀死容器并根据重启策略（restartPolicy）决定是否将其重启；未定义存活检测的容器的默认状态为“Success”。

  • 就绪性探测（readinessProbe）：用于判断容器是否准备就绪并可对外提供服务；未经过检测的容器意味着其还没有准备就绪，端点控制器（如Service对象）会将其IP从全部匹配到此Pod对象的Service对象的端点列表中移除；检测经过以后，会再将其IP添加至端点列表中。

何时使用存活（liveness）和就绪（readiness）探针？

若是容器中的进程可以在遇到问题或不健康的状况下自行崩溃，则不必定须要存活探针，kubelet将根据Pod的restartPolicy自动执行正确的操做。

若是但愿容器在探测失败时被杀死并从新启动，那么请指定一个存活探针，并指定restartPolicy为Always或OnFailure。

若是要仅在探测成功时才开始向Pod发送流量，请指定就绪探针。在这种状况下，就绪探针可能与存活探针相同，可是spec中的就绪探针的存在乎味着Pod将在没有接收到任何流量的状况下启动，而且只有在探针探测成功才开始接收流量。

若是但愿容器可以自行维护，能够指定一个就绪探针，该探针检查与存活探针不一样的端点。

注意：若是只想在Pod被删除时可以排除请求，则不必定须要使用就绪探针；在删除Pod时，Pod会自动将自身置于未完成状态，不管就绪探针是否存在。当等待Pod中的容器中止时，Pod仍处于未完成状态。

容器的重启策略

PodSpec中有一个restartPolicy字段，可能的值为Always、OnFailure和Never。默认为Always。restartPolicy适用于Pod中的全部容器。并且它仅用于控制在同一节点上从新启动Pod对象的相关容器。首次须要重启的容器，将在其须要时当即进行重启，随后再次须要重启的操做将由kubelet延迟一段时间后进行，且反复的重启操做的延迟时长依次为10秒、20秒、40秒... 300秒是最大延迟时长。事实上，一旦绑定到一个节点，Pod对象将永远不会被从新绑定到另外一个节点，它要么被重启，要么终止，直到节点发生故障或被删除。

  • Always：但凡Pod对象终止就将其重启，默认值

  • OnFailure：仅在Pod对象出现错误时方才将其重启

  • Never：从不重启

Pod存活性探测示例

设置exec探针示例

[root@k8s-master ~]# vim manfests/liveness-exec.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
  namespace: default
  labels:
    test: liveness-exec
spec:
  containers:
  - name: liveness-exec-container
    image: busybox:latest
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 3600"]
    livenessProbe:
      exec:
        command: ["test","-e","/tmp/healthy"]
      initialDelaySeconds: 1
      periodSeconds: 3

[root@k8s-master ~]# kubectl create -f manfests/liveness-exec.yaml    #建立pod
pod/liveness-exec-pod created
[root@k8s-master ~]# kubectl get pods   #查看pod
NAME                READY   STATUS    RESTARTS   AGE
liveness-exec-pod   1/1     Running   0          6s

#等待一段时间后再次查看其状态
[root@k8s-master ~]# kubectl get pods
NAME                READY   STATUS    RESTARTS   AGE
liveness-exec-pod   1/1     Running   2          2m46s

上面的资源清单中定义了一个pod对象，基于busybox镜像启动一个运行“touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 3600"命令的容器，此命令在容器启动时建立了/tmp/healthy文件，并于60秒以后将其删除。存活性探针运行”test -e /tmp/healthy"命令检查/tmp/healthy文件的存在性，若文件存在则返回状态码0，表示成功经过测试。在60秒内使用“kubectl describe pods/liveness-exec-pod”查看其详细信息，其存活性探测不会出现错误。而超过60秒以后，再执行该命令查看详细信息，能够发现存活性探测出现了故障，而且还可经过“kubectl get pods"查看该pod的重启的相关信息。

设置HTTP探针示例

基于HTTP的探测（HTTPGetAction）向目标容器发起一个HTTP请求，根据其响应码进行结果断定，响应码如2xx或3xx时表示测试经过。经过该命令”# kubectl explain pod.spec.containers.livenessProbe.httpGet“查看httpGet定义的字段

host    <string>：请求的主机地址，默认为Pod IP，也能够在httpHeaders中使用“Host:”来定义。
httpHeaders    <[]Object>：自定义的请求报文首部。
port    <string>：请求的端口，必选字段。
path    <string>：请求的HTTP资源路径，即URL path。
scheme    <string>：创建链接使用的协议，仅可为HTTP或HTTPS，默认为HTTP。
[root@k8s-master ~]# vim manfests/liveness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-http
  namespace: default
  labels:
    test: liveness
spec:
  containers:
    - name: liveness-http-demo
      image: nginx:1.12
      imagePullPolicy: IfNotPresent
      ports:
      - name: http
        containerPort: 80
      lifecycle:
        postStart:
          exec:
            command: ["/bin/sh", "-c", "echo Healthz > /usr/share/nginx/html/healthz"]
      livenessProbe:
        httpGet:
          path: /healthz
          port: http
          scheme: HTTP
[root@k8s-master ~]# kubectl create -f manfests/liveness-httpget.yaml    #建立pod
pod/liveness-http created
[root@k8s-master ~]# kubectl get pods    #查看pod
NAME            READY   STATUS    RESTARTS   AGE
liveness-http   1/1     Running   0          7s

[root@k8s-master ~]# kubectl describe pods/liveness-http    #查看liveness-http详细信息
......
Containers:
  liveness-http-demo:
......
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Mon, 09 Sep 2019 15:43:29 +0800
    Ready:          True
    Restart Count:  0
......

上面清单中定义的httpGet测试中，经过lifecycle中的postStart hook建立了一个专用于httpGet测试的页面文件healthz，请求的资源路径为"/healthz"，地址默认为Pod IP，端口使用了容器中顶一个端口名称http，这也是明确了为容器指明要暴露的端口的用途之一。并查看健康状态检测相关的信息，健康状态检测正常时，容器也将正常运行。下面经过“kubectl exec”命令进入容器删除由postStart hook建立的测试页面healthz。再次查看容器状态

[root@k8s-master ~]# kubectl exec pods/liveness-http -it -- /bin/sh    #进入到上面建立的pod中
# rm -rf /usr/share/nginx/html/healthz   #删除healthz测试页面
# 

[root@k8s-master ~]# kubectl get pods 
NAME            READY   STATUS    RESTARTS   AGE
liveness-http   1/1     Running   1          10m

[root@k8s-master ~]# kubectl describe pods/liveness-http
......
Containers:
  liveness-http-demo:
......
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Mon, 09 Sep 2019 15:53:04 +0800
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Mon, 09 Sep 2019 15:43:29 +0800
      Finished:     Mon, 09 Sep 2019 15:53:03 +0800
    Ready:          True
    Restart Count:  1
......

经过上面测试能够看出，当发起http请求失败后，容器将被杀掉后进行了从新构建。

设置TCP探针

基于TCP的存活性探测（TCPSocketAction）用于向容器的特定端口发起TCP请求并创建链接进行结果断定，链接创建成功即为经过检测。相比较来讲，它比基于HTTP的探测要更高效、更节约资源，但精确度略低，毕竟链接创建成功未必意味着页面资源可用。经过该命令”# kubectl explain pod.spec.containers.livenessProbe.tcpSocket“查看tcpSocket定义的字段

host    <string>：请求链接的目标IP地址，默认为Pod IP
port    <string>：请求链接的目标端口，必选字段
[root@k8s-master ~]# vim manfests/liveness-tcp.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcp-pod
  namespace: default
  labels:
    test: liveness-tcp
spec:
  containers:
  - name: liveness-tcp-demo
    image: nginx:1.12
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      tcpSocket:
        port: http

上面清单中定义的tcpSocket测试中，经过向容器的80端口发起请求，若是端口正常，则代表正常运行。

livenessProbe行为属性

[root@k8s-master ~]# kubectl explain pods.spec.containers.livenessProbe
KIND:     Pod
VERSION:  v1

RESOURCE: livenessProbe <Object>

exec   command 的方式探测，例如 ps 一个进程是否存在

failureThreshold    探测几回失败 才算失败， 默认是连续三次

initialDelaySeconds  初始化延迟探测，即容器启动多久以后再开始探测，默认为0秒

periodSeconds  每隔多久探测一次，默认是10秒

successThreshold  处于失败状态时，探测操做至少连续多少次的成功才算经过检测，默认为1秒

timeoutSeconds  存活性探测的超时时长，默认为1秒

httpGet   http请求探测

tcpSocket    端口探测

Pod就绪性探测示例

Pod对象启动后，容器应用一般须要一段时间才能完成其初始化过程，例如加载配置或数据，甚至有些程序须要运行某类的预热过程，若在这个阶段完成以前即接入客户端的请求，势必会等待过久。所以，这时候就用到了就绪性探测（readinessProbe）。

与存活性探测机制相似，就绪性探测是用来判断容器就绪与否的周期性（默认周期为10秒钟）操做，它用于探测容器是否已经初始化完成并可服务于客户端请求，探测操做返回”success“状态时，即为传递容器已经”就绪“的信号。

就绪性探测也支持Exec、HTTPGet和TCPSocket三种探测方式，且各自的定义机制也都相同。但与存活性探测触发的操做不一样的是，探测失败时，就绪探测不会杀死或重启容器以保证其健康性，而是通知其还没有就绪，并触发依赖于其就绪状态的操做（例如，从Service对象中移除此Pod对象）以确保不会有客户端请求接入此Pod对象。

这里只是示例http探针示例，不管是httpGet仍是exec仍是tcpSocket和存活性探针相似。

设置HTTP探针示例

#终端1：
[root@k8s-master ~]# vim manfests/readiness-httpget.yaml  #编辑readiness-httpget测试pod的yaml文件
apiVersion: v1
kind: Pod
metadata:
  name: readiness-http
  namespace: default
  labels:
    test: readiness-http
spec:
  containers:
  - name: readiness-http-demo
    image: nginx:1.12
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        path: /index.html
        port: http
        scheme: HTTP
[root@k8s-master ~]# kubectl create -f manfests/readiness-httpget.yaml    #建立pod
pod/readiness-http created
[root@k8s-master ~]# kubectl get pods      查看pod状态
NAME               READY   STATUS    RESTARTS   AGE
liveness-tcp-pod   1/1     Running   1          7d18h
readiness-http     1/1     Running   0          7s


#新打开一个终端2进入到容器里面
[root@k8s-master ~]# kubectl exec pods/readiness-http -it -- /bin/sh    #进入上面建立的pod
# rm -f /usr/share/nginx/html/index.html     #删除nginx的主页面文件
# ls /usr/share/nginx/html
50x.html
# 


#回到终端1上面查看pod状态
[root@k8s-master ~]# kubectl get pods     #查看pod状态
NAME               READY   STATUS    RESTARTS   AGE
liveness-tcp-pod   1/1     Running   1          7d18h
readiness-http     0/1     Running   0          2m44s

经过上面测试能够看出，当咱们删除了nginx主页文件后，readinessProbe发起的测试就会失败，此时咱们再查看pod的状态会发现并不会将pod删除从新启动，只是在READY字段能够看出，当前的Pod处于未就绪状态。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程