Pod 状态管理

Pod 状态管理

在容器内获取Pod信息（Downward API）

Downward API有提供了两种方式来实现从容器内部获取POD信息的方法：

环境变量的方式 Downward API 卷文件挂载

通过这两种方式，可以将pod的标签信息，资源信息，状态信息传递到Pod内部。

环境变量方式-将Pod信息注入为环境变量

1、使用pod参数方式

使用如下文件：

apiVersion: v1 kind: Pod metadata: name: envars-pod spec: containers: - name: test-container image: busybox command: [ "sh", "-c"] args: - while true; do echo -en '\n'; printenv MY_NODE_NAME MY_POD_NAME MY_POD_NAMESPACE; printenv MY_POD_IP MY_POD_SERVICE_ACCOUNT; sleep 10; done; env: - name: MY_NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName - name: MY_POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: MY_POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: MY_POD_IP valueFrom: fieldRef: fieldPath: status.podIP - name: MY_POD_SERVICE_ACCOUNT valueFrom: fieldRef: fieldPath: spec.serviceAccountName restartPolicy: Never

创建pod之后，通过logs查看：

# kubectl logs envars-pod 10.0.0.3 envars-pod default 10.2.6.23 default

登录pod,可以直接查看，发现环境变量中已经加载了这些参数：

kubectl exec -it envars-pod -- sh / # env MY_POD_SERVICE_ACCOUNT=default KUBERNETES_SERVICE_PORT=443 KUBERNETES_PORT=tcp://10.1.0.1:443 HOSTNAME=envars-pod SHLVL=1 HOME=/root MY_POD_NAMESPACE=default TERM=xterm MY_POD_IP=10.2.6.23 KUBERNETES_PORT_443_TCP_ADDR=10.1.0.1 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin KUBERNETES_PORT_443_TCP_PORT=443 KUBERNETES_PORT_443_TCP_PROTO=tcp MY_NODE_NAME=10.0.0.3 KUBERNETES_SERVICE_PORT_HTTPS=443 KUBERNETES_PORT_443_TCP=tcp://10.1.0.1:443 KUBERNETES_SERVICE_HOST=10.1.0.1 PWD=/ MY_POD_NAME=envars-pod

通过yaml文件中指定的valueFrom这种方式的Downward语法获取相关Pod信息。

2、 使用容器参数方式

如下文件：

apiVersion: v1 kind: Pod metadata: name: envars-con spec: containers: - name: test-container image: busybox:1.24 command: [ "sh", "-c"] args: - while true; do echo -en '\n'; printenv MY_CPU_REQUEST MY_CPU_LIMIT; printenv MY_MEM_REQUEST MY_MEM_LIMIT; sleep 10; done; resources: requests: memory: "32Mi" cpu: "125m" limits: memory: "64Mi" cpu: "250m" env: - name: MY_CPU_REQUEST valueFrom: resourceFieldRef: containerName: test-container resource: requests.cpu - name: MY_CPU_LIMIT valueFrom: resourceFieldRef: containerName: test-container resource: limits.cpu - name: MY_MEM_REQUEST valueFrom: resourceFieldRef: containerName: test-container resource: requests.memory - name: MY_MEM_LIMIT valueFrom: resourceFieldRef: containerName: test-container resource: limits.memory restartPolicy: Never

运行此pod，查看日志：

1 1 33554432 67108864

使用volume方式

1、使用Pod 参数创建如下文件：

apiVersion: v1 kind: Pod metadata: name: kubernetes-downwardapi-volume-example labels: zone: us-est-coast cluster: test-cluster1 rack: rack-22 annotations: build: two builder: john-doe spec: containers: - name: client-container image: busybox command: ["sh", "-c"] args: - while true; do if [[ -e /etc/podinfo/labels ]]; then echo -en '\n\n'; cat /etc/podinfo/labels; fi; if [[ -e /etc/podinfo/annotations ]]; then echo -en '\n\n'; cat /etc/podinfo/annotations; fi; sleep 5; done; volumeMounts: - name: podinfo mountPath: /etc/podinfo readOnly: false volumes: - name: podinfo downwardAPI: items: - path: "labels" fieldRef: fieldPath: metadata.labels - path: "annotations" fieldRef: fieldPath: metadata.annotations

通过downward API的volume方式，将pod的labels中的所有参数和annotations中的所有参数传递给了pod内。在对应的路径下，有一个隐藏的文件目录，存放了这两个文件。

2、通容器参数传递资源配额如下Pod文件：

apiVersion: v1 kind: Pod metadata: name: kubernetes-downwardapi-volume-example-2 spec: containers: - name: client-container image: k8s.gcr.io/busybox:1.24 command: ["sh", "-c"] args: - while true; do echo -en '\n'; if [[ -e /etc/podinfo/cpu_limit ]]; then echo -en '\n'; cat /etc/podinfo/cpu_limit; fi; if [[ -e /etc/podinfo/cpu_request ]]; then echo -en '\n'; cat /etc/podinfo/cpu_request; fi; if [[ -e /etc/podinfo/mem_limit ]]; then echo -en '\n'; cat /etc/podinfo/mem_limit; fi; if [[ -e /etc/podinfo/mem_request ]]; then echo -en '\n'; cat /etc/podinfo/mem_request; fi; sleep 5; done; resources: requests: memory: "32Mi" cpu: "125m" limits: memory: "64Mi" cpu: "250m" volumeMounts: - name: podinfo mountPath: /etc/podinfo readOnly: false volumes: - name: podinfo downwardAPI: items: - path: "cpu_limit" resourceFieldRef: containerName: client-container resource: limits.cpu - path: "cpu_request" resourceFieldRef: containerName: client-container resource: requests.cpu - path: "mem_limit" resourceFieldRef: containerName: client-container resource: limits.memory - path: "mem_request" resourceFieldRef: containerName: client-container resource: requests.memory

通过如下方式，查看pod中传递的参数：

kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh /# cat /etc/podinfo/cpu_limit

Downward API的应用主要是在某些场景中，集群中的每个节点将需要将自身的标识（ID）及进程绑定IP地址等信息事先写入配置文件中，进程启动时读取这些信息发布到服务的注册中心，实现集群节点的自动发现功能。

Pod生命周期和重启策略

Pod的常见状态

当我们执行kubectl describe pod <pod-name>时，会发现Pod都会有一个状态值，下面列举了Pod的5中状态：

Pending: API server 已经创建该Pod,但是Pod内还有一个或多个容器镜像没有创建，一般是在下载镜像。 Running: Pod内的所有容器均已经创建，且至少有一个容器处于运行状态、正在启动或重启状态。 Succeeded: Pod内所有容器均已经成功执行退出，且不再重启 Failed: Pod内所有容器均已退出，但至少有一个容器退出为失败状态。 Unknown: 由于某种原因无法获取Pod状态，可能由于网络通信不畅导致。

Pod重启策略（RestartPolicy）

Pod的重启策略应用于Pod中的所有容器，并且仅在Pod所处的Node上由Kubelet进行判断和重启操作。RestartPolicy包含三个设定：

Always: 当容器失效时，由kubelet自动重启该容器。 OnFailure: 当容器终止运行且退出码不为0时，由Kubelet自动重启该容器。 Never: 不论容器的运行状态如何，Kubelet都不会重启该容器。当管理Pod的控制包括ReplicationController、Job、DaemonSet以及直接通过Kubelet管理（静态Pod），对应的控制器对Pod的重启策略要求如下： RC和DaemonSet，ReplicaSet，Deployment： 必须设置为Always，需要保证容器的持续运行 Job: OnFailure 或Never,确保容器不再执行 kubelet: 在Pod失效时自动重启它，不论将RestartPolicy设置为什么值，也不会对Pod进行健康检查。

Pod健康检查

对Pod的健康状态检查可以通过两类探针来检查：LivenessProbe和ReadinessProbe。

livenessProbe: 判断容器是否存活（running）,如果检测到容器不健康，则kubelet将杀掉该容器，并根据容器的重启策略做相应的处理。如果容器不包含LivenessProbe探针，则返回永远是Success。 readinessProbe: 用于判断容器是否启动完成（ready），可以接受请求。如果ReadinessProbe探针检测到失败，则Pod的状态将被修改。Endpoint Controller将从Service的EndPoint中删除包含该容器所在的Pod的EndPoint。

容器的探针对容器有3中实现方式：

ExecAction： 在容器内执行一条命令，如果命令的返回码为0，则表示容器健康。 TCPSocketAction: 通过容器的端口号和IP地址执行TCP检测，如果能够建立TCP连接表示容器健康。 HTTPGetAction: 通过容器的IP地址、端口号及路径调用HTTP Get方法，如果相应的状态码大于等于200且小于400，则认为容器状态健康。

下面是对应的三个示例，阐述了这3中实现方式：

1、使用ExecAction方式:

apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-exec spec: containers: - name: liveness image: busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 # 从容器启动时，到第一次执行健康探测的时间间隔 periodSeconds: 5 # 每隔5s 检查一次 timeoutSeconds: 1 # 健康检查发送请求后的等待响应时间，默认为1S，超时无响应，则会认为无法提供服务，kubelet会重启该容器。

通过如下命令，可以查看到pod的健康状态和重启次数：

kubectl get pod -o wide kubectl describe pod liveness-exec

2、使用TCPSockAction如下文件示例：

apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80 readinessProbe: tcpSocket: port: 80 initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: tcpSocket: port: 80 initialDelaySeconds: 15 periodSeconds: 20

3、使用HTTPGetAction

apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-http spec: containers: - name: liveness image: mirrorgooglecontainers/liveness args: - /server livenessProbe: httpGet: path: /healthz port: 8080 httpHeaders: - name: X-Custom-Header value: Awesome initialDelaySeconds: 3 periodSeconds: 3

readinessProbe 和livenessProbe 用法十分相似，只需要把 readinessProbe替换为livenessProbe即可。它们可以同时使用在同一个容器上，来确保流量不会流入未准备好的容器，并且让容器在失败的时候重新启动。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。