Kubernetes中资源清单与Pod的生命周期（二）
一、资源清单
1，定义：
在k8s中一般使用yaml格式的文件来创建符合我们预期的资源，这样的yaml被称为资源清单。
使用资源清单创建Pod：
kubectl apply -f nginx.yaml
定义nginx.yaml内容为：
apiVersion: v1
kind: Pod
metadata:
name: my-pod #自定义的名称只能用小写字母使用 - 连接，驼峰 或者 _ 连接会报错
labels:
app: nginx-app
version: v1
spec:
containers:
- name: test-nginx
image: nginx
2，资源清单常用字段
| 字段 | 类型 | 说明 |
|---|---|---|
| apiVersion | String | k8s api 的版本，目前基本上是 v1。可以用 kubectl api-versions 命令查看 |
| kind | String | 定义的资源类型。比如定义为一个 Pod 或者 Deployment等等。 |
| metadata | Object | 声明元数据对象，固定值：metadata。 |
| metadata.name | String | 元数据对象的名字。我们自己定义，比如该资源被 kind 定义为一个 Pod，那么 Pod 的名称就是在这里定义。 |
| metadata.namespace | String | 元数据对象的命名空间。我们自己定义，不写默认为 default。这里定义的命名空间必须是已存在的。 |
| metadata.labels | Object | 标签。 |
| metadata.labels.app | String | 标签名称。 |
| metadata.labels.version | String | 标签版本号。 |
| Spec | Object | 详细定义对象。固定值：Spec。 |
| spec.containers[] | List | 这里是Spec对象的容器列表。即这个资源可以声明多个容器。 |
| spec.containers[].name | String | 容器的名字。建议不写，会自动创建。如果此处写了容器的名字，那么 k8s 对该容器进行扩容时会报错，因为不能存在相同名称的容器。 |
| spec.containers[].image | String | 容器使用的镜像。 |
| spec.containers[].imagePullPolicy | String | 镜像拉取策略。如果不设置，默认为 Always。Always：每次都拉取新的镜像；Never：仅使用本地镜像，如果本地镜像不存在则不使用该镜像；IfNotPresent：如果本地没有，就拉取新镜像。 |
| spec.containers[].command[] | List | 指定容器启动命令，可以指定多个。不指定则默认为容器打包时使用的启动命令，若指定了则会覆盖原命令。 |
| spec.containers[].args[] | List | 指定容器启动命令参数，可传入多个。 |
| spec.containers[].workingDir | String | 指定容器的工作目录。 |
| spec.containers[] | List | 指定容器北部的存储卷配置。 |
| spec.containers[].volumeMounts[].name | String | 指定可以被容器挂载的存储卷的名称。 |
| spec.containers[].volumeMounts[].mountPath | String | 指定可以被容器挂载的存储卷的路径。 |
| spec.containers[].volumeMounts[].readOnly | String | 设置存储卷路径的读写模式，ture 或 false，默认为读写模式。 |
| spec.containers[].ports[] | List | 指定容器需要用到的端口列表。 |
| spec.containers[].ports[].name | String | 指定端口名称。 |
| spec.containers[].ports[].containerPort | String | 指定容器需要监听的端口号。 |
| spec.containers[].ports[].hostPort | String | 指定容器所在主机需要监听的端口号，默认跟 containerPort 相同。设置了 hostPort ，那么同一台主机就无法启动该容器的相同副本（同一主机端口号冲突）。 |
| spec.containers[].ports[].protocol | String | 指定端口协议，支持 TCP 和 UDP，默认为 TCP。 |
| spec.containers[].env[] | List | 指定容器运行前需要设置的环境变量列表。 |
| spec.containers[].env[].name | String | 指定环境变量名称。 |
| spec.containers[].env[].value | String | 指定环境变量的值。 |
| spec.containers[].resources | Object | 指定资源限制和资源请求的值。 |
| spec.containers[].resources.limits | Object | 设置容器运行时的资源运行上限。 |
| spec.containers[].resources.limits.cpu | String | 指定 CPU 的限制，单位为 core 数，将用于 docker run -- cpu-shares 参数。 |
| spec.containers[].resources.limits.memory | String | 指定 MEM 内存的限制，单位为 MIB、GIB。 |
| spec.restartPolicy | String | Pod 重启策略。Always：Pod 一旦终止运行，不论是以什么方式终止的，kubelet 都会重启它；OnFailure：如果 Pod 的退出码是0，kubelet 不会重启，其它任何非0退出码终止的，都会重启；Never：Pod 终止后，kubelet 将退出码报告给 master 并不会重启该 Pod。 |
| spec.nodeSelector | Object | 定义 Node 的 Label 过滤标签，言外之意就是选择在哪些 Node 上执行。以 key:value 格式指定。 |
| spec.imagePullSecrets | Object | 定义 pull 镜像时使用的 secret 名称，格式为 name:secretkey 。 |
| spec.hostNetwork | Boolean | 是否使用主机网络模式，默认值为 false。ture 表示使用宿主机网络，不使用 docker 网桥，并且将无法在同一台宿主机上启动第二个副本，否则端端口冲突。 |
3，排错思路
如果我们使用资源清单进行资源的创建时发生错误（某个容器启动失败），可以通过以下思路排查（以 Pod 为例）：
# 查看 Pod，-n 指定命名空间名称 kubectl get pod -n myspace -o wide # 查看 Pod 的详细信息（假设 Pod 名称为 my-pod），查询结果包括 Pod 中所有容器的运行情况，如果某个容器正常运行，其 State 属性会是 Running kubectl describe pod my-pod -n myspace # 查看 Pod 中容器的运行日志，找出容器运行失败的原因。-c 表示要查看的容器，若 Pod 里只有一个容器，不加也可以。 kubectl log my-pod -c my-nginx -n myspace
二、Pod定义
每个Pod都会存在一个Pause根容器，是每一个Pod都会去运行的，container即为应用程序，所以Pod就是根容器Pause和应用程序container所组成，在Pod当中可以运行多个小的容器的。
1，Pod组成的意义
- 使用Pause根容器可以防止由于将多个容器组成一个单元，当其中某个容器挂掉就会导致整个单元无法使用的情况发生。
- Pod可以运行过个container，这些container是共享Pause根容器的IP地址，也共享Pause的volume挂债卷，这样既简化了关联业务容器之间的通信问题，也很好的解决了容器之间共享的问题
- 在Kubernetes中的Pod之间是可以进行相互通信的，因为他们之间是一个二层交换的网络，所以不同主机之间Pod是可以进行相互访问的
2，Pod类型划分
- 自主式Pod：直接创建一个 Pod 而不使用控制器，这种方式创建的 Pod 就称为 自主式 Pod。这种 Pod 一旦停止或被删除，就无法自动重启或重新创建。
- 控制器管理的Pod：通过 ReplicaSet、DaemonSet 等控制器创建的 Pod，称为控制器管理的 Pod。通过控制器来管理的 Pod，会有一个期望的副本数量，一旦 Pod 超出或者达不到这个数量，那么控制器就会通过重启、创建或者删除 Pod 的方式维持 Pod 的数量达到期望值。
3，Pod、容器与Node之间的关系
- 在Node当中运行着Pod，而在Pod当中是包含着容器。
- 在K8s当中都是以Docker镜像发布的，每个Pod可以理解为上面运行着多个镜像，在默认情况下，比如在Pod当中某个容器停止了，K8s会自动检查这个问题并重启这个Pod（即将Pod当中的所有容器全部重启）
- 如果Pod所在的Node宕机了，K8s会把Pod调度到其他的Node节点上
- Pod当中是可以运行多个应用的，即支持多容器运行，每一个Pod相当于一个资源池，Pod当中的容器可以共享IP和文件系统
三、Pod的生命周期
1，生命周期描述
初始化 Pod 环境：每一个 Pod 在创建时都会先初始化 Pod 运行所必须的条件。然后才继续执行后面的容器初始化操作。比如会先创建 pause 这样的容器。 Init C：Init Containers，初始化容器。 我们在 Pod 里面运行的容器，可能会依赖某些文件或者环境才能够正常启动或运行。Init C 就是来完成这些文件或者环境的创建的。 Init C 可以有多个，也可以没有。按顺序执行，必须要等到前一个执行完成（必须是正常退出，否则会根据重启策略判断是否重新执行该 Init C），才会执行后一个。 Init C 只存在容器初始化阶段，Init C 执行完成之后会消亡，不参与 Pod 的后续流程。 所有的 Init C 都正常结束后，Main C 主容器才开始创建并启动。 Main C：主容器。即运行在 Pod 里提供服务的容器。主容器一旦停止运行，那么 Pod 也就停止了。需要注意的是一个 Pod 里面可以有很多个 Main C，且每个 Main C 都有自己的 Init C 等。 start：Main C 创建之前执行的操作，可以是一条命令或一个脚本。 stop：Main C 结束之后执行的操作，可以是一条命令或一个脚本。 readiness：容器就绪检测，可以指定在容器启动之后的某个时间点执行，比如 10 秒后。只有当 readiness 正常执行完成，该 Pod 才会显示为就绪状态。 liveness：容器是否正在运行。
2，InitC
Init容器与普通的容器非常像，但是：1，Init容器总是运行到成功为止；2，每个Init容器必须都在下一个Init容器启动之前成功完成。
InitC简单实例init.yaml：(kubectl create -f init.yaml)
apiVersion: v1 kind: Pod #Pod类型 metadata: name: myapp-pod #Pod名称 labels: app: myapp spec: containers: - name: myapp-container #主容器 image: busybox command: ['sh', '-c', 'echo The app is running! && sleep 3600'] initContainers: #InitC - name: init-myservice #率先启动的Init容器 image: busybox command: [ 'sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;'] #监控myservice - name: init-mydb #在主容器之前启动，在init-myservice正常退出之后启动。 image: busybox command: [ 'sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;'] #监控mydb
myservice.yaml ：(kubectl create -f myservice.yaml)
apiVersion: v1 kind: Service metadata: name: myservice spec: ports: - protocol: TCP port: 80 targetPort: 9376
mydb.yaml ：(kubectl create -f myservice.yaml)
apiVersion: v1 kind: Service metadata: name: mydb spec: ports: - protocol: TCP port: 80 targetPort: 9377
InitC特点:
- 在 Pod 启动过程中，Init 容器会按顺序在网络和数据卷初始化之后启动（即在 pause 容器之后启动）。每个容器必须在下一个 容器启动之前成功退出。
- 如果由于运行时或失败退出，将导致容器启动失败，它会根据 Pod 的 restartPolicy 指定的策略进行重试。
- 在所有的 Init 容器没有成功之前，Pod 将不会变成 Ready 状态。Init 容器的端口将不会在 Service 中进行聚集。正在初始化中的 Pod 处于 Pending 状态，但应该会将 Initializing 状态设置为true。
- 如果 Pod 重启，所有 Init 容器必须重新执行。
- 对 Init 容器 spec 的修改被限制在容器 image 字段，修改其他字段都不会生效。更改 Init 容器的 image 字段，等价于重启该Pod。
- Init 容器具有应用容器的所有字段。除了 readinessProbe，因为 Init 容器无法定义不同于完成 （conpletion）的就绪（readiness）之外的其他状态。
- 在 Pod 中的每个 app 和 Init 容器的名称必须唯一；与任何其它容器共享同一个名称，会在验证时抛出错误。
3，探针
探针是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 Handler。有三种类型的处理程序：
-
- ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
- TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
- HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTPGet 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。
每次探测都将获得以下三种结果之一：
-
- 成功：容器通过了诊断。
- 失败：容器未通过诊断。
- 未知：诊断失败，因此不会采取任何行动。
探针有两种类型：
- readinessProbe：探测容器是否准备好服务请求（即是否就绪 [READY]）。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure 。如果容器不提供就绪探针，则默认状态为Success。
- livenessProbe：探测容器是否正常运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。
readinessProbe实例:采用HTTPGetAction(readness-httpget.yaml)
apiVersion: v1 kind: Pod metadata: name: readness-httpget-pod spec: containers: - name: readness-httpget-container image: hub.xcc.com/library/mynginx:v1 imagePullPolicy: IfNotPresent #镜像拉取策略 readinessProbe: httpGet: #探测方式 port: 80 path: /index1.html #检测路径 initialDelaySeconds: 1 #容器启动后1s开始探测 periodSeconds: 3 #如果检测失败，每3s继续探测，直到检测成功或者达到最大检测值
livenessProbe实例:采用ExecAction(liveness-exec.yaml)
apiVersion: v1 kind: Pod metadata: name: liveness-exec-pod namespace: default spec: containers: - name: lineness-exec-container image: busybox imagePullPolicy: IfNotPresent command: ['sh', '-c', 'touch /tmp/live; sleep 50; rm -rf /tmp/live; sleep 3600'] livenessProbe: exec: command: ['test', '-e', '/tmp/live'] initialDelaySeconds: 1 periodSeconds: 3
4，Pod hook
Pod hook（钩子）是由 Kubernetes 管理的 kubelet 发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中，也就是上面 Pod 生命周期 中提到的 start 和 stop。可以同时为 Pod 中的所有容器都配置 hook。
Hook的类型包括两种：
-
- exec：执行一段命令。
- HTTP：发送HTTP请求。
apiVersion: v1 kind: Pod metadata: name: lifecycle-demo spec: containers: - name: lifecycle-demo-container image: hub.xcc.com/library/mynginx:v1 lifecycle: postStart: exec: command: [......] preStop: exec: command: [......]
5，Pod相位(phase )
Pod 的 status 字段是一个 PodStatus 对象，PodStatus 中有一个 phase 字段。
Pod 的相位（phase）是 Pod 在其生命周期中的简单宏观概述。该阶段并不是对容器或 Pod 的综合汇总，也不是为了做为综合状态机。
Pod 相位的数量和含义是严格指定的，以下是当前 Pod 相位的所有值：
-
- 挂起（Pending）：Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间。
- 运行中（Running）：该 Pod 己经绑定到了一个节点上，Pod 中所有的容器都己被创建。至少有一个容器正在运行，或者正处于启动或重启状态。
- 成功（Succeeded）：Pod 中的所有容器都被成功终止，并且不会再重启。
- 失畋（Failed）：Pod 中的所有容器都己终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
- 未知（Unknown）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。
