Kubernetes笔记（五）：了解Pod（容器组）

时间 2020-09-21

标签 kubernetes 笔记了解 pod 容器繁體版

原文原文链接

Kubernetes 中，容器老是以 Pod（容器组）的方式进行调度与运行。所以对 Pod 的理解与掌握是学习 Kubernetes 的基础。html

理解 Pod

Pod（容器组）是 Kubernetes 中最小的调度单元，每个Pod都是某个应用程序的一个运行实例。之前咱们的 Web 应用都是以 Tomcat 等 Web 容器进程的形式运行在操做系统中，在 Kubernetes 中，咱们须要将 Web 应用打成镜像，以容器的方式运行在 Pod 中。node

Kubernetes 不会直接管理容器，而是经过 Pod 来管理。一个Pod包含以下内容：nginx

一个或多个容器，通常是一个，除非多个容器紧密耦合共享资源才放在一个 Pod 中；
共享的存储资源（如数据卷），一个 Pod 中的容器是能够共享存储空间的；
一个共享的 IP 地址，Pod 中容器之间能够经过 localhost:port 彼此访问；
定义容器该如何运行的选项。

Pod 中的容器可包括两种类型：docker

工做容器：就是咱们一般运行服务进程的容器
初始化容器：完成一些初始化操做的容器，初始化容器在工做容器以前运行，全部的初始化容器成功执行后，才开始启动工做容器

管理 Pod

建立 Pod

在 Kubernetes 中，咱们通常不直接建立 Pod，而是经过控制器来调度管理（Deployment，StatefulSet，DaemonSet 等），这里为了便于了解，先经过 yaml 配置文件的方式定义 Pod 来直接建立 Pod。定义配置文件 pod-test.yaml 以下，shell

apiVersion: v1
kind: Pod
metadata:
  name: pod-test  # pod 名称
  namespace: default # pod 建立的 namespace
spec:
  containers:     # pod 中容器定义
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
      hostPort: 8081
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html
  restartPolicy: OnFailure # 重启策略
  volumes:                 # 数据卷定义
  - name: workdir
    hostPath:
      path: /tmp
      type: Directory

其中 spec 部分的 containers 定义了该 Pod 中运行的容器，从 containers 的复数形式也能够看出一个 Pod 中是能够运行多个容器的。api

执行 kubectl create 或 kubectl apply 命令建立 Pod，bash

[root@kmaster test]# kubectl create -f pod-test.yaml

或

[root@kmaster test]# kubectl apply -f pod-test.yaml

该 Pod 建立后将会拉取一个最新的 nginx 镜像，运行一个 nginx 容器，并将容器的 80 端口映射到宿主机的 8081 端口。app

查看 Pod

可以使用 kubectl get pods 命令查看当前 namesapce 下的全部 Pod，加 Pod 名称查看具体某个 Pod。若是须要查看 Pod 调度到了哪一个节点，可加 -o wide 选项，若是查看 yaml 文件信息则可加 -o yaml 选项，以下所示负载均衡

[root@kmaster test]# kubectl get pods
NAME                           READY   STATUS    RESTARTS   AGE
pod-test                       1/1     Running   0          116s

[root@kmaster test]# kubectl get pods pod-test -o wide
NAME                           READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
pod-test                       1/1     Running   0          2m19s   10.244.1.42   knode2   <none>           <none>

[root@kmaster test]# kubectl get pods pod-test -o yaml

若是要查看更多的信息，可以使用 kubectl describe 命令，tcp

[root@kmaster test]# kubectl describe pod pod-test

该命令输出内容以下图，

各部分说明：

Status: Pending，表示 Pod 的总体状态，当前处于 Pending 状态；
State: Waiting，Pod 中每一个容器都有一个本身的状态 State，当前容器 nginx 处于 Waiting 状态，Reason: ContainerCreating 表示容器还处于建立中，Ready：False 代表容器还未就绪，还不能对外提供服务；
Conditions，这部分聚合了一些状态，第一个 Initialized：True，代表已经完成了初始化；而第二个 Ready：False，代表 Pod 还未就绪；ContainersReady：False，代表容器还未就绪； PodScheduled：True，代表 Pod 已经被调度到某个具体的节点上了；
3中不一样的状态之间的转换都会发生相应的事件，事件类型包括 Normal 与 Warning 两种，从上图可看到一个 Pulling image 的 Normal 事件，表示当前正在拉取 Pod 中容器的镜像。

当 Pod 在调度或运行中出现问题时，咱们均可以使用 kubectl describe 命令来进行排查，经过其中的状态及事件来判断问题产生的可能缘由。

进入 Pod 容器

经过 kubectl exec 命令可进入 Pod，相似于 docker exec，如

# 若是 Pod 中只有一个容器
[root@kmaster test]# kubectl exec -it pod-test bash
root@pod-test:/#

# 若是 Pod 中有多个容器
kubectl exec -it pod-name -c container-name /bin/bash

若是一个 Pod 中有多个容器，则须要经过 -c 指定进入哪一个容器。

更新/删除 Pod

Kubernetes 对 Pod 的更新作了限制，除了更改 Pod 中容器（包括工做容器与初始化容器）的镜像，以及 activeDeadlineSeconds （对 Job 类型的 Pod 定义失败重试的最大时间）， tolerations （Pod 对污点的容忍），修改其它部分将不会产生做用，如咱们能够尝试在前面 Pod 定义文档 pod-test.yaml 中将宿主机端口 8081 改成 8082，从新执行 kubectl apply，将提示以下错误，

[root@kmaster test]# kubectl apply -f pod-test.yaml
The Pod "pod-test" is invalid: spec: Forbidden: pod updates may not change fields other than `spec.containers[*].image`, `spec.initContainers[*].image`, `spec.activeDeadlineSeconds` or `spec.tolerations` (only additions to existing tolerations)

经过 kubectl delete 命令可删除一个 Pod

[root@kmaster test]# kubectl delete pod pod-test

在 Kubernetes 中，通常不直接建立，更新或删除单个 Pod，而是经过 Kubernetes 的 Controller（控制器）来管理 Pod，包括 ReplicSet（通常也不直接用，推荐Deployment方式）， Deployment，StatefulSet，DaemonSet 等。

控制器提供以下功能：

水平伸缩，控制运行 Pod 指定个数的副本
rollout，即版本更新
故障恢复，当一个节点出现故障，或资源不够，或进入维护中，控制器会自动在另外一个合适的节点调度一个同样的 Pod，以保障 Pod 以必定的副本数运行

Pod 状态

Pod状态并非容器的状态，容器的状态通常包括：

Waiting：容器的初始状态，处于 Waiting 状态的容器，表示仍然有对应的操做在执行，例如：拉取镜像、应用 Secrets等
Running：容器处于正常运行的状态
Terminated：容器处于结束运行的状态

而Pod的状态通常包括：

Pending： Kubernetes 已经建立并确认该 Pod，可能两种状况： 1. Pod 还未完成调度（例如没有合适的节点）；2. 正在从 docker registry 下载镜像
Running：该 Pod 已经被绑定到一个节点，而且该 Pod 全部的容器都已经成功建立，其中至少有一个容器正在运行，或者正在启动/重启
Succeeded：Pod 中的全部容器都已经成功终止，而且不会再被重启
Failed：Pod 中的全部容器都已经终止，至少一个容器终止于失败状态：容器的进程退出码不是 0，或者被系统 kill
Unknown：由于某些未知缘由，不能肯定 Pod 的状态，一般的缘由是 master 与 Pod 所在节点之间的通讯故障

状态之间的变迁关系如图

Pod 刚开始处于 Pending 的状态，接下来可能会转换到 Running，也可能转换到 Unknown，甚至可能转换到 Failed。而后，当 Running 执行了一段时间以后，它能够转换到相似像 Successded 或者是 Failed。当出现 Unknown 这个状态时，可能因为一些状态的恢复，它会从新恢复到 Running 或者 Successded 或者是 Failed。

重启策略

定义 Pod 或工做负载时，能够指定 restartPolicy，可选的值有：

Always：默认值，只要退出就重启
OnFailure：失败退出时（exit code 不为 0）才重启
Never：永远不重启

restartPolicy 做用于 Pod 中的全部容器。kubelete 将在五分钟内，按照递延的时间间隔（10s, 20s, 40s ...）尝试重启已退出的容器，并在十分钟后再次启动这个循环，直到容器成功启动，或者 Pod 被删除。在控制器 Deployment/StatefulSet/DaemonSet 中，只支持 Always 这一个选项，不支持 OnFailure 和 Never 选项。

健康检查

提升应用服务的可用性与稳定性，通常可从两个方面来进行：

首先是提升应用的可观测性，如对应用的健康状态，资源的使用状况，应用日志等可进行实时的观测
第二是提升应用的可恢复能力，在应用出现故障时，能经过自动重启等方式进行恢复

Kubernetes 中对 Pod 的健康检查提供了两种方式：

Readiness probe，就绪探测，用来判断一个 Pod 是否处于就绪状态，是否能对外提供相应服务了。当Pod处于就绪状态时，负载均衡器才会将流量打到这个 Pod，不然将把流量从这个 Pod 上面摘除。
Liveness probe，存活探测，用来判断一个 Pod 是否处于存活状态，若是一个 Pod 被探测到不处于存活状态，则由上层判断机制来处理，若是上层配置重启策略为 restart always 的话，Pod 就会被重启。

Liveness probe 适用场景是支持那些能够从新拉起的应用，而 Readiness probe 主要应对的是启动以后没法当即对外提供服务的应用。

就绪探测、存活探测目前支持三种不一样的探测方式：

httpGet，经过发送http Get请求来判断，返回状态码在 200-399之间，认为是探测成功
Exec，经过执行容器中的一个命令来判断服务是否正常，若是命令的退出状态码为 0，表示成功
tcpSocket，经过容器的IP，端口来进行TCP链接检查，若是TCP链接能被正常创建，则认为成功

以 httpGet 为例，示例配置文件以下，

apiVersion: v1
kind: Pod
metadata:
  name: pod-test
spec:
  containers:
  - # ... 与前同
    - name: workdir
      mountPath: /usr/share/nginx/html
    livenessProbe:
      httpGet:
        path: /
        port: 80
        httpHeaders: # 此处header无心义，仅做示例
        - name: purpose
          value: for-test
      initialDelaySeconds: 2
      periodSeconds: 5
  # ... 与前同

删除以前的 Pod，从新建立，使用 kubectl describe 查看，可看到 Events 部分以下图，

Http 存活探测失败，状态码返回 403，致使容器重启。出现这个错误的缘由是前面作目录挂载时将 nginx 的 html 目录挂载到了宿主机的 /tmp 目录，而 /tmp 目录没有 index.html 文件，致使请求返回403，在 Pod 调度到的宿主机 /tmp 目录下建立 index.html 文件便可。

echo '<h1>Hello, K8s!</h1>' > /tmp/index.html

其它 Exec，tcpSocket 探测的配置示例以下（配置在 containers 元素下），

# exec
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

# tcpSocket
livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10

支持的参数说明：

initialDelaySeconds：延迟探测时间，表示 Pod 启动延迟多久后进行一次检查，好比某个应用启动时间若是较长的话，能够设置该值为略大于启动时间；
periodSeconds：探测频率，表示探测的时间间隔，正常默认的这个值是 10 秒；
timeoutSeconds：超时时间，表示探测的超时时间，当超时时间以内没有检测成功，那会认为失败；
successThreshold：健康阈值，表示当这个 Pod 从探测失败到再一次判断探测成功，所须要的阈值次数，默认状况下是 1 次。若是以前探测失败，接下来的一次探测成功了，就会认为这个 Pod 是处在一个正常的状态；
failureThreshold：不健康阈值，与 successThreshold 相对，表示认为探测失败须要重试的次数，默认值是 3。意思是当从一个健康的状态连续探测到 3 次失败，就会认为Pod 的状态处在一个失败的状态。

readinessProbe 配置与 livenessProbe 相似。阿里云上配置就绪检查如图所示：

健康检查的结果分为三种：

Success，表示 container 经过了健康检查，也就是 Liveness probe 或 Readiness probe 是正常的一个状态；
Failure，表示 container 没有经过健康检查。针对 Readiness probe，service 层就会将没有经过 Readiness probe 的 pod 进行摘除，再也不分发请求到该 Pod；针对 Liveness probe，就会将这个 pod 进行从新拉起，或者是删除。
Unknown，表示当前的执行机制没有进行完整的一个执行，多是由于相似像超时或者像一些脚本没有及时返回，此时 Readiness probe 或 Liveness probe 不作任何操做，会等待下一次的机制来进行检查。

健康检查的一些实践建议：

若是容器中的进程在碰到问题时能够本身 crash，就不须要执行存活探测，由于 kubelet 能够自动的根据 Pod 的 restartPolicy（重启策略）来执行对应的动做；
若是但愿在容器的进程无响应后，将容器重启，则指定一个存活探测 livenessProbe，并同时指定 restartPolicy（重启策略）为 Always 或者 OnFailure；
若是但愿在 Pod 确实就绪以后才向其分发服务请求，就指定一个就绪检查 readinessProbe；
适当调大 exec 探测的超时阈值，由于在容器里面执行一个 shell 脚本，它的执行时长是很是长的，平时在一台虚机上执行可能 3 秒返回的一个脚本在容器里面可能须要 30 秒。能够适当调大超时阈值，来防止因为容器压力比较大的时候出现偶发的超时；
调整失败判断的次数，3 次的默认值有时候可能不必定是最佳实践，适当调整一下判断的次数也是一个比较好的方式；
使用 tcpSocket 方式进行判断的时候，若是遇到了 TLS 的服务，那可能会形成后边 TLS 里面有不少这种未鉴权的 tcp 链接，这时候须要本身针对业务场景判断这种链接是否会对业务形成影响。

总结

本文对 Pod 的概念与基本的管理操做，Pod 的状态变迁机制与重启策略进行了介绍，对 Pod 的健康检查进行了详细的了解。但在 Kubernetes 中，咱们通常不直接建立 Pod，而是经过控制器，如Deployment，StatefulSet，DaemonSet，由于控制器能为咱们提供水平伸缩，rollout（版本更新），self-healing（故障恢复）等能力。咱们将在接下来的文章了解控制器。

[转载请注明出处]
做者：雨歌
欢迎关注做者公众号：半路雨歌，查看更多技术干货文章