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：不会将状态存放到Etcd存储数据库中，而是放到了某个Node上的具体文件当中，并且只有在这个Node上才能启动运行

　　普通Pod：普通Pod一旦被创建成功，那么Pod状态信息就会放到Etcd存储数据库当中，状态就会实时进行更新，就会被Master节点绑定到某个Node节点上进行调度和资源分配，随后Pod就放到了指定的Node上面，相当于把一个应用实例化成了一组相关Docker容器并启动去运行

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 所在主机通信失败。