Kubernetes Pod 深度理解

一. 什么是 Pod

Pod 是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及运行规范。在 Pod 中，所有容器都被统一安排和调度。对于具体应用而言，Pod 是它们的逻辑主机，Pod 包含业务相关的多个应用容器。所以，Pod 是一组具有共享命名空间、IP地址和端口的容器的集合

1. 从使用的角度来看

在实际的使用时，单个容器是无法单独来支撑我们的应用的,往往需要很多微服务才能组成一个系统,并且还会存在A服务依赖B服务，B服务需要和C服务共用某个目录。另外，在使用裸容器时，很难实现对容器内进行健康检査以及横向扩容等操作，而 Pod 可以轻松解决这些问题

2. 从 Kubernetes 的角度来看

Docker 只是容器 Runtime(运行时)的一种们还有很多容器 Runtime，比如 Rkt、CRI-0等，而Kuberetes 作为目前最流行的容器编排工具，需要支持各个 Runtime 并且不依赖于底层 Runtime 的实现技术，于是就抽象出了 Pod 这个概念，用于管理多个紧密相连的符合 CRI标准的容器

Pod 可以简单的理解为一组、一个或多个容器，每个 Pod 还包含一个 Pause 容器，Pause 容器是 Pod的父容器主要负责僵尸进程的回收管理。同时，通过 Pause 容器可以使同一个 Pod 里面的不同容器共享存储、网络、PID、IPC(进程间通信)等，容器之间可以使用 Localhost:Por 的方式相互访问，可以使用 volume 实现数据共享。根据 Docker 的构造，Pod 可以被创建为一组具有共享命名空间、IP 地址和端口的容器

Pod 有两个必须知道的特点：

网络：每一个 Pod 都会被指派一个唯一的 !p 地址，在 Pod 中的每一个容器共享网络命名空间，包括Ip 地址和网络端口。在同一个 Pod 中的容器可以同 1ocalhost 进行互相通信。当 Pod 中的容器需要与Pod 外的实体进行通信时，则需要通过端口等共享的网络资源

存储：Pod 能够被指定共享存储卷的集合，在 Pod 中所有的容器能够访问共享存储卷，允许这些容器共享数据。存诸卷也允许在一个 Pod 持久化数据，以防止其中的容器需要被重启

3.Pod 的状态

（1）kubectl 命令创建 pod

[root@k8s-master ~]# ku run nginx --image=nginx:1.7.9 --labels="app=nginx"

（2）查看 pod

[root@k8s-master ~]# ku get pods -n default
[root@k8s-master ~]# ku get pods -A

（3）查看 Pod 的更多信息

[root@k8s-master ~]# ku get pods nginx -o wide

（4）查看 Pod 日志

[root@k8s-master ~]# curl 10.244.85.193
[root@k8s-master ~]# ku logs nginx

（5）以 yaml 格式显示 Pod 详细信息

[root@k8s-master ~]# ku get pod nginx -o yaml

（6）显示资源的详细描述信息

[root@k8s-master ~]# ku describe pod nginx

备注：

（7）在 Pod 的容器中执行命令

[root@k8s-master ~]# ku exec nginx -c nginx -- date

备注：

（8）登录到 Pod 中的容器中

[root@k8s-master ~]# ku exec -it nginx -c nginx -- bash

任意节点测试

备注：

（9）在线编辑运行中的资源对象

[root@k8s-master ~]# ku edit pod nginx

（10）将 Pod 的端口映射到宿主机

[root@k8s-master ~]# ku port-forward --address 0.0.0.0 pod/nginx 8080:80

任意节点测试

（11）在宿主机和 Pod 的容器之间拷贝文件

[root@k8s-master ~]# echo  "this is my k8sAndnginx" > index.html
[root@k8s-master ~]# ku cp index.html nginx:/usr/share/nginx/html

任意节点测试

（12）Pod 的状态

[root@k8s-master ~]# ku get pods -n default

可以看到此时的 Pod 的状态是 Running，Pod 的状态不仅仅只有 Running，常见的其他状态如表所示：

（13）删除 Pod

[root@k8s-master ~]# ku delete pods nginx

二. Pod 探针

在生产环境中，进程正常启动并不代表应用能正常处理请求，所以合理的设计应用的健康检査尤其重要。在使用裸机或裸容器部署时，一般很难对应用做很完善的健康检査，而 Pod 提供的探针可以很方便的用来检测容器的应用是否正常

1. Pod 探针的实现方式

目前探针有3种检测方式，可以根据不同的场景选择合适的健康检查方式，分别是ExecAction、TCPSocketAction 和 HTTPGetAction。具体实现方式如表所示

2. 容器状态

上述的检查方式可以被周期性的执行，每次检査容器后可能得到的容器状态如表所示

3. Pod 探针类型

Pod 探针有三类,分别是:livenessProbe(存活探针)、readinessProbe(就绪探针)、startupProbe(启动探针)

（1）livenessProbe（存活探针）

它被用来知道一个容器是否在正常运行。如果容器未能通过存活探针的检查，则系统会认为该容器已经进入了一个必须被重启的状态，从而自动重启这个容器。这种机制可以确保容器在出现问题后能够自动恢复到可用状态

存活探针支持以下几种类型：

（2）readinessProbe（就绪探针）

判断容器是否能够进入 ready 状态，用于确定 Pod 中的容器是否已准备好接收流量。与1ivenessProbe 不同,readinessProbe 主要关注的是容器是否已经准备好为服务提供者处理请求。如果容器没有通过就绪探针的检査，Kubernetes 将不会把任何新的网络流量路由到这个容器上

当一个容器报告自己尚未准备好时，Kubernetes可能会采取以下行动：

• 服务(service)不会将流量路由到未准备好的 Pod
• 如果 Pod 是副本集(Replicaset)、部署(Deployment)、状态集(statefulset)等的一部分控制器会认为这个实例不可用
• 对于使用 Pod 的滚动更新策略的情况,就绪探针可以帮助确保新版本的 Pod 在旧版本被终止之前就已经准备好了

就像 livenessProbe 一样，readinessProbe 也支持多种类型的探测方法：

（3）startupProbe（启动探针）

判断容器内的应用是否启动成功，在 success 状态前，其它探针都处于无效状态。它专门用于检测容器是否完成了初始化并进入了预期的运行状态。与 livenessProbe(存活探针)和 readinessProbe(就绪探针)不同，startupProbe专注于容器启动阶段，并且仅在容器启动过程中使用

startupProbe 的主要作用是在容器启动期间持续检査容器是否已经完成启动。一旦容器通过了startupProbe 的检査，Kubernetes 就会认为容器已经成功启动，并停止对该容器的启动探针检查。如果容器始终无法通过启动探针的检査，那么 Kubernetes 将会根据配置重试一定的次数，超过重试次数后可能会采取进一步的措施，如重启容器

三. Pod 镜像拉取策略和重启策略

1. 镜像拉取策略

在发布应用或者更改控制器配置时,会触发 Pod 的滚动更新,此时针对容器的镜像有不同的拉取方式。如表所示

指定拉取策略：

[root@k8s-master ~]# ku run nginx --image=nginx:1.7.9 --labels="app=nginx" --image-pull-policy=Never

2. Pod 重启策略

在 Kubernetes 中，Pod 的重启策略(Restart Policy)定义了当容器退出或失败时，kubelet 如何处理容器。重启策略是 Pod 级别的配置，适用于Pod 中的所有容器

在 Always 策略中，只要容器退出(无论退出码是什么)，kubelet 都会自动重启容器。适用于需要持续运行的服务(如 web 服务器、数据库等)

在 onFailure 策略中，只有当容器以非零退出码退出时，kubelet 才会重启容器，如果容器正常退出(退出码为 )，则不会重启。适用于任务型 Pod(如批处理任务)，任务完成后不需要重启

在 Never 策略中，无论容器以何种方式退出，kubelet 都不会重启容器。适用于一次性任务，任务完成后不需要重启

各个策略的简要说明如表：

指定重启策略：

[root@k8s-master ~]# ku delete pod nginx
[root@k8s-master ~]# ku run nginx --image=nginx:1.7.9 --labels="app=nginx" --restart=OnFailure

四. 创建一个简单的 Pod

1. 编写一个简单的 Pod

[root@k8s-master ~]# vim aaa.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  containers:
  - name: nginx01
    image: nginx:1.7.9
    ports:
    - containerPort: 80
  - name: nginx02
    image: nginx:1.7.9
    ports:
    - containerPort: 8080
[root@k8s-master ~]# ku delete pods nginx
[root@k8s-master ~]# ku get pods
No resources found in default namespace.
[root@k8s-master ~]# ku create -f aaa.yaml 
pod/nginx created
[root@k8s-master ~]# ku get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   2/2     Running   0          2s

2. 编写 Pod 配置文件 frontend-localredis-pod.yaml

[root@k8s-master ~]# vim frontend-localredis-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: redis-php
  labels:
    name: redis-php
spec:
  containers:
  - name: frontend
    image: kubeguide/guestbook-php-frontend:localredis
    imagePullPolicy: IfNotPresent
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 1
    ports:
    - containerPort: 80

  - name: redis
    image: kubeguide/redis-master
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 6379
  restartPolicy: OnFailure
[root@k8s-master ~]# ku create -f frontend-localredis-pod.yaml
[root@k8s-master ~]# ku get pods
NAME        READY   STATUS             RESTARTS       AGE
nginx       1/2     CrashLoopBackOff   10 (69s ago)   27m
redis-php   2/2     Running            0              7s

备注：

3. Pod 文件语法

（1）Pod 文件的一级属性

一级属性主要包含5部分：

• apiVersion版本,由 kubernetes 内部定义,版本号必须可以用 kubectl api-versions查询到

• kind 类型，由 kubernetes 内部定义，版本号必须可以用 kubectl api-resources 查询到

• metadata<0bject>元数据，主要是资源标识和说明，常用的有 name、namespace、labels 等

• spec描述，这是配置中最重要的一部分，里面是对各种资源配置的详细描述

• status<0bject>状态信息，里面的内容不需要定义，由 kubernetes 自动生成

（2）spec(规格)属性

在一级属性中，spec是研究的重点，它的常见子属性有：

（3）通过kubectl explain 命令来查看每种资源的可配置项

kubectl explain pod
kubectl explain deployment
kubectl explain service
kubectl explain pod.metadata
kubectl explain pod.spec.containers

（4）运行 kubectl create 命令创建此 Pod

[root@k8s-master ~]# vim nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80
[root@k8s-master ~]# ku delete pod nginx
pod "nginx" deleted
[root@k8s-master ~]# ku create -f nginx-pod.yaml 
pod/nginx created
[root@k8s-master ~]# ku get pods
\NAME        READY   STATUS    RESTARTS   AGE
nginx       1/1     Running   0          92s
redis-php   2/2     Running   0          54m

五. Pod 的基本用法

1. 编写 pod 文件，将两个容器放在同一个 pod 中

[root@k8s-master ~]# vim nginx-php.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-php
  labels:
    name: nginx-php
spec:
  containers:
  - name: nginx-app
    image: nginx:1.7.9
    ports:
    - containerPort: 80
  - name: php-app
    image: bitnami/php-fpm
    imagePullPolicy: Never
    ports:
    - containerPort: 9000

2. 部署 nginx 的 Pod 文件

[root@k8s-master ~]# ku create -f nginx-php.yaml
[root@k8s-master ~]# ku get pods

3. 查看 Pod 的详细信息

[root@k8s-master ~]# ku describe pod nginx-php

4. 暴露端口

[root@k8s-master ~]# ku expose pod nginx-php --port=8080 --target-port=80 --type=NodePort --name=nginx-php

5. 查看端口映射

[root@k8s-master ~]# ku get pod,svc nginx-php -o wide

6. 测试访问

浏览器访问：http://192.168.10.101:31533

六. 静态 Pod

静态 Pod 是由 kubelet 进行管理的仅存在于各个Node上的Pod他们不能通过 AP讲不Seni理，无法于 Replicationcontroller、Deployment 或者 DaemonSet 进行关联，并且 kubelet 无法对他们进行健康检査。静态 Pod 总是由 kubelet 创建的，并且总在 kubelet 所在的 Node 上运行

1. 编写 yaml

2. 查看 Pod

[root@k8s-master manifests]# ku get pods

3. 删除静态 Pod 的方法

失败的删除

成功的删除

备注：

不能用如下语句删除ku delete pod nginx-k8s-master这样删除，会让 pod 处于 pending 状态，但无法删除

六. Pod 启动过程与运行状态

创建完之后，直到持久运行起来，中间有很多步骤，也就有很多出错的可能，因此会有很多不Pod同的状态

在 Pod 的启动过程中，会涉及到多个关键组件，保证 Pod 能够顺利的启动完成，这些关键组件和作用如下所示：

通过这些步骤，Kubernetes确保 Pod 能够按照预期启动并运行

1. Pod 的启动过程包含的步骤

Pod 的启动过程是 Kubernetes 中一个关键的操作，涉及多个步骤和组件协同工作。以下是 Pod 启动的主要过程：

（1）用户提交 Pod 定义

用户通过 kubectl 或其他工具提交 Pod 的 YAML 或 JSON 定义文件 Kubernetes API Server

（2）API server 接收请求

API Server 接收到 Pod 创建请求后，会进行身份验证和授权检査，确保请求合法

通过检査后，API Server 将 Pod 的定义信息存储到 etcd 中

（3）scheduler 调度 Pod

Scheduler 监控 API Server，发现有待调度的 Pod

Scheduler 根据 Pod 的资源需求、节点亲和性、污点容忍等策略，选择一个合适的节点

Scheduler 将 Pod 与节点绑定，并将绑定信息更新到 etcd

（4）kubelet 创建 Pod

目标节点上的 kubelet 监控 API Server，发现有新的 Pod 被调度到本节点

kubelet 根据 Pod 定义，调用容器运行时(如 Docker、containerd)创建容器

kubelet 还会为 Pod 设置网络(通过 CNI 插件)和存储卷(如 emptyDir、hostPath 或持久卷)

（5）容器运行时启动容器

容器运行时根据 kubelet 的指令，拉取镜像(如果本地没有)并启动容器

容器启动后，运行时向 kubelet 报告容器状态

（6）kubelet 更新 Pod 状态

kubelet 监控容器的运行状态，并将 Pod 的状态更新到 API Server

API Server 将状态信息存储到 etcd

（7）Pod 进入运行状态

当所有容器成功启动并运行后，Pod 进入 Running 状态

如果容器启动失败，kubelet 会根据重启策略(如 Always、0nFailure)决定是否重启容器

（8）探针检查（可选）

如果 Pod 定义了存活探针(Liveness Probe)或就绪探针(Readiness Probe)，kubelet 会定期执行这些探针

探针检查失败可能导致容器重启或Pod 从服务端点移除

（9）Pod 可用

当 Pod 的所有容器正常运行并通过就绪探针检査后，Pod 被视为可用，可以接收流量或执行任务

（10）持续监控

kubelet 持续监控 Pod 的状态，确保其健康运行

如果 Pod 或容器出现问题，kubelet 会根据配置采取相应措施(如重启容器)

2. Pod 的运行状态