k8s Pod基础（概念，容器功能及分类，镜像拉取和容器重启策略）

pod概念

Kubernetes设计Pod概念和特殊组成结构的用意

Pod内部结构：

网络共享：

存储共享：

pause容器主要功能

pod创建方式

pod使用方式

pod分类

pod的容器分类

基础容器（infrastructure container）：

查看pause容器的基础镜像

配置kubelet使用阿里云的镜像

初始化容器（init containers）：

Init 容器和普通容器的区别

应用容器（业务容器 main container）：

官方示例

完整执行示例

注意

pod 镜像拉取策略（image PullPolicy）

镜像拉取的三种策略

官方示例

测试示例

pod 容器重启策略

重启策略的三种格式

示例

pod状态

Container生命周期

pod概念

Pod是Kubernetes中最小的部署单位，它可以包含一个或多个容器，并共享相同的网络命名空间、IP地址和存储卷。Pod通常用于运行一个单一应用程序实例或者一组相互关联的应用程序实例。其他Kubernetes组件，如Deployment、StatefulSet、Service等，都是围绕Pod来管理和扩展应用的功能。Deployment和StatefulSet用于管理Pod的生命周期，Service用于暴露Pod内部的应用程序服务，而PersistentVolume用于提供Pod的持久化存储。

Kubernetes设计Pod概念和特殊组成结构的用意

解决容器组状态管理问题：
引入Pause容器作为Pod的基础容器，使得整个Pod的生命周期可以由Pause容器的状态来代表。这种设计可以简化对容器组状态的判断和管理，当一个容器死亡时，Pause容器的状态可以反映整个Pod的状态，从而触发相应的处理措施，例如重启Pod或者执行其他故障恢复操作。
简化容器间通信和资源共享：
Pod中的多个应用容器共享Pause容器的IP地址和挂载的Volume，这样可以简化应用容器之间的通信问题，使它们能够通过localhost直接通信。同时，共享Volume也解决了容器之间的文件共享问题，使得容器能够共享数据和状态，从而更轻松地进行协作和共享资源。

综合而言，Pod的设计使得容器化应用程序在Kubernetes中能够更加方便地进行管理和部署，同时提供了更高的灵活性和可靠性，使得容器组能够更加高效地运行和协作。

Pod内部结构：

每个Pod都包含一个特殊的被称为“基础容器”的Pause容器，该容器负责管理Pod内部容器的共享操作。
除了Pause容器外，Pod还包含一个或多个紧密相关的用户应用容器。

网络共享：

Pod中的所有容器共享同一个网络命名空间，拥有相同的IP地址和端口空间。
容器之间可以通过localhost进行通信，而与外部通信时，需要分配共享网络资源，例如使用宿主机的端口映射。

存储共享：

Pod可以指定多个共享的Volume，所有容器都可以访问这些共享的Volume。
Volume也可以用于持久化Pod中的存储资源，以防止容器重启导致文件丢失。

这种设计使得Pod成为了Kubernetes中的最小调度单位，为容器化应用程序提供了便捷的管理和共享资源的机制。

pause容器主要功能

提供Linux命名空间共享的基础：
Pause容器负责管理Pod中的网络命名空间等共享资源，确保所有容器在Pod内部共享相同的网络环境，从而实现容器间的通信和协作。
启用PID命名空间，充当init进程：
Pause容器在Pod中作为PID命名空间的第一个进程（PID 1），类似于Linux系统中的init进程。它负责监控和管理其他容器的生命周期，例如处理僵尸进程等。
协调其他容器的生命周期：
Pause容器负责协调Pod中其他容器的生命周期，确保它们能够按照预期启动、停止和重启，从而实现整个Pod的稳定运行。
提供健康检查和生存探针：
Pause容器通常也会提供健康检查和生存探针服务，以确保Pod中的其他容器处于健康状态，并在必要时进行故障恢复或重启操作。

pod创建方式

通过命令行工具kubectl创建Pod：您可以使用kubectl命令行工具创建Pod，并指定Pod的配置文件或直接提供Pod的定义。

kubectl create -f <pod-definition.yaml>

通过Deployment或StatefulSet创建Pod：Deployment和StatefulSet是Kubernetes中的控制器对象，它们管理Pod的生命周期，可以自动创建、扩展、更新和删除Pod。

kubectl create deployment <deployment-name> --image=<image-name>

kubectl create statefulset <statefulset-name> --image=<image-name>

通过Pod模板创建Pod：您可以定义一个Pod模板，然后使用该模板创建多个Pod实例。

apiVersion: v1
kind: Pod
metadata:name: mypod
spec:containers:- name: mycontainerimage: nginx

通过命令行工具kubectl管理Pod：使用kubectl命令行工具，您可以管理Pod的各种操作，如获取Pod信息、删除Pod、调试Pod等。

kubectl get pods
kubectl describe pod <pod-name>
kubectl delete pod <pod-name>

通过调度器将Pod调度到集群节点：Kubernetes调度器负责将Pod调度到集群中的节点上，并确保Pod的资源需求得到满足。

pod使用方式

在Kubernetes集群中，Pod有两种主要的使用方式：
一个Pod中运行一个容器：这是最常见的用法，每个Pod中只包含一个容器。在这种模式下，Pod可以被视为是封装了单个容器的最小部署单元。Kubernetes管理的是Pod，而不是直接管理容器。这种方式适用于运行独立的应用程序或服务，例如一个Web服务器或一个数据库。
在一个Pod中同时运行多个容器：一个Pod中也可以同时封装多个需要紧密耦合互相协作的容器。这些容器共享相同的网络命名空间、IP地址和存储卷，它们可以协同工作成为一个服务单元。例如，一个容器可以负责运行主要的应用程序，而另一个"sidecar"容器可以处理日志收集、监控或其他辅助任务。Pod将这些容器作为一个实体来管理，它们共享Pod的资源，可以方便地相互通信和共享数据。

pod分类

自主式Pod：
这种类型的Pod本身不具备自我修复的能力。一旦创建后，Pod会被调度到集群的Node上，并保持在该节点上，直到满足终止条件，如进程终止、被手动删除、因缺少资源而被驱逐或节点故障等。Pod不会自动迁移或恢复。
如果Pod所在的Node发生故障，或者调度器出现故障，Pod将被删除。同样地，如果Pod所在Node缺少资源或处于维护状态，Pod也会被驱逐。
控制器管理的Pod：
Kubernetes引入了更高级的抽象层称为Controller来管理Pod实例。Controller可以管理多个Pod，并提供副本管理、滚动升级和集群级别的自愈能力。
通过使用Controller，可以实现对Pod的自动化管理，例如在节点故障时自动迁移Pod到其他健康的节点上。通常情况下，Kubernetes推荐使用Controller来管理Pod，而不是直接操作Pod。

pod的容器分类

基础容器（infrastructure container）：

基础容器负责维护整个Pod的网络和存储空间，是Pod中的一个特殊容器。
每当创建一个Pod时，Kubernetes会自动启动一个基础容器，通常使用Pause容器作为基础容器。

查看pause容器的基础镜像

docker images #node01节点上

配置kubelet使用阿里云的镜像

cat /etc/sysconfig/kubelet #node01节点上查看pause配置镜像文件

空值即为默认官方镜像，修改为阿里pause镜像源

cat > /etc/sysconfig/kubelet << EOFKUBELET_EXTRA_ARGS=--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"
EOF

初始化容器（init containers）：

初始化容器是在应用容器启动之前运行的容器，用于执行初始化任务或满足先决条件。
初始化容器总是运行到成功完成为止，并且每个初始化容器必须在下一个初始化容器启动之前成功完成启动和退出。
初始化容器可以包含安装、配置或准备数据等任务，使得应用容器能够以正确的环境启动运行。
如果 Pod 的 Init 容器失败，k8s 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的重启策略（restartPolicy）为 Never，它不会重新启动。

Init 容器和普通容器的区别

包含实用工具或个性化代码：
初始化容器可以包含一些在应用容器中不存在的实用工具或个性化代码，例如sed、awk、python或dig等工具。这样就无需为了使用这些工具而构建新的应用镜像，可以在初始化容器中单独使用它们。
安全运行工具：
由于初始化容器和应用容器分离，并且初始化容器的作用是在启动前完成特定任务，因此可以安全地运行这些工具，而不会影响应用镜像的安全性。
独立工作：
创建者和部署者可以独立地为初始化容器和应用容器工作，无需联合构建单个应用镜像。这样可以提高灵活性和独立性。
具有访问权限：
初始化容器可以以不同于应用容器的文件系统视图运行，因此可以具有访问一些敏感信息如Secrets的权限。这样可以确保敏感信息在初始化过程中被安全地使用。
阻塞或延迟应用容器启动：
初始化容器必须在应用容器启动之前成功运行完成。因此，可以利用初始化容器来阻塞或延迟应用容器的启动，直到满足一组先决条件。一旦这些条件满足，Pod中的所有应用容器会并行启动。

总的来说，初始化容器为Pod提供了一种在启动前执行特定任务的机制，可以增加灵活性、安全性，并允许更细粒度地控制应用程序的启动过程。

应用容器（业务容器 main container）：

应用容器是Pod中实际运行业务逻辑的容器，它们通常并行启动。
- 应用容器并行启动是指在 Kubernetes Pod 中，所有的应用容器同时启动并运行。这意味着当 Pod 中有多个应用容器时，它们可以在相同的时间段内开始执行，而不必等待其他容器启动完成。这种并行启动可以提高应用程序的启动速度和整体性能，因为不同的容器可以在同一时间内独立地执行其任务，而不会相互阻塞或等待其他容器的完成。这种方式可以加速应用程序的启动过程，并提高整个集群的资源利用率。
应用容器执行实际的应用程序代码，并处理业务逻辑。

官方示例

官网示例： https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/init-containers/

apiVersion: v1
kind: Pod
metadata:name: myapp-podlabels:app: myapp
spec:containers:- name: myapp-containerimage: busybox:1.28command: ['sh', '-c', 'echo The app is running! && sleep 3600']initContainers:- name: init-myserviceimage: busybox:1.28command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']- name: init-mydbimage: busybox:1.28command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

这是一个官方示例，展示了一个Pod定义，其中包含一个应用容器（myapp-container）和两个初始化容器（init-myservice和init-mydb）。以下是对该示例的解释：

Pod名称和标签：
Pod的名称为myapp-pod，并设置了一个标签app: myapp。
应用容器：
应用容器的名称为myapp-container，使用了busybox:1.28镜像。
容器中的命令是['sh', '-c', 'echo The app is running! && sleep 3600']，即在启动后输出一条消息并休眠3600秒。
初始化容器：
第一个初始化容器的名称是init-myservice，使用了busybox:1.28镜像。
容器中的命令是['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']，即等待名为myservice的服务启动完成。
第二个初始化容器的名称是init-mydb，同样使用了busybox:1.28镜像。
容器中的命令是['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']，即等待名为mydb的服务启动完成。

这个示例的目的是展示如何使用初始化容器等待特定服务（myservice和mydb）启动后，再启动主应用容器。这种方式可以确保应用容器在满足一组先决条件后才开始运行。此外，所有初始化容器和应用容器都可以并行启动，提高了启动效率。

示例Pod的定义展示了一个包含初始化容器和应用容器的Pod，初始化容器等待特定服务启动后才启动应用容器。这种设计使得Pod能够按照需要完成初始化任务，并在满足条件后才启动应用程序，确保应用程序的可靠启动和运行。
通过使用基础容器、初始化容器和应用容器，Kubernetes提供了灵活而强大的容器编排能力，使得容器化应用程序的部署和管理更加简单和可靠。

完整执行示例

kubectl describe pod myapp-podkubectl logs myapp-pod -c init-myservicevim myservice.yaml
apiVersion: v1
kind: Service
metadata:name: myservice
spec:ports:- protocol: TCPport: 80targetPort: 9376kubectl create -f myservice.yamlkubectl get svckubectl get pods -n kube-systemkubectl get podsvim mydb.yaml
apiVersion: v1
kind: Service
metadata:name: mydb
spec:ports:- protocol: TCPport: 80targetPort: 9377kubectl create -f mydb.yamlkubectl get pods

这个命令序列描述了一系列 Kubernetes 命令的执行过程，用于创建和管理 Pod 中的服务以及查看相关资源状态。下面对每个命令进行解析：

kubectl describe pod myapp-pod：描述了名为 myapp-pod 的 Pod 的详细信息，包括其状态、容器信息、事件等。
kubectl logs myapp-pod -c init-myservice：检索名为 myapp-pod 的 Pod 中 init-myservice 容器的日志，用于查看初始化容器的执行情况。
vim myservice.yaml：编辑一个名为 myservice.yaml 的 YAML 文件，其中定义了一个名为 myservice 的 Service，该 Service 暴露了端口 80，目标端口为 9376。
kubectl create -f myservice.yaml：通过 YAML 文件创建名为 myservice 的 Service。
kubectl get svc：获取所有服务的列表，包括刚创建的 myservice 服务。
kubectl get pods -n kube-system：获取位于 kube-system 命名空间中的所有 Pod 的列表。
kubectl get pods：获取所有 Pod 的列表，包括主命名空间中的 Pod。
vim mydb.yaml：编辑一个名为 mydb.yaml 的 YAML 文件，其中定义了一个名为 mydb 的 Service，该 Service 暴露了端口 80，目标端口为 9377。
kubectl create -f mydb.yaml：通过 YAML 文件创建名为 mydb 的 Service。
kubectl get pods：获取所有 Pod 的列表，包括更新后的状态，其中可能包括对 myservice 和 mydb 服务的影响。

这些命令用于创建、描述和管理 Kubernetes 中的各种资源，如 Pod 和 Service。通过这些命令，您可以查看集群中各种资源的状态，以及执行与其相关的操作。

注意

Init容器启动顺序和退出条件：
在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动，并且每个容器必须在下一个容器启动之前成功退出。
Init容器的失败和重试策略：
如果Init容器由于运行时错误或失败退出，将导致容器启动失败。根据Pod的restartPolicy指定的策略进行重试。如果restartPolicy设置为Always，Init容器失败时会使用RestartPolicy策略。
Pod状态和Init容器就绪状态：
在所有的Init容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集。正在初始化中的Pod处于Pending状态，但应该会将Initializing状态设置为true。
Pod重启和Init容器：
如果Pod重启，所有Init容器必须重新执行。
修改Init容器的限制：
对Init容器spec的修改被限制在容器image字段，修改其他字段都不会生效。更改Init容器的image字段，等价于重启该Pod。
Init容器的字段：
Init容器具有应用容器的所有字段，除了readinessProbe。因为Init容器无法定义不同于完成（completion）的就绪（readiness）之外的其他状态，这会在验证过程中强制执行。
容器名称的唯一性：
在Pod中的每个应用和Init容器的名称必须唯一；与任何其他容器共享相同名称会在验证时抛出错误。

这些规则和限制有助于确保Pod和Init容器的稳健性和可靠性，并提供了对容器启动和状态的严格管理和控制。

pod 镜像拉取策略（image PullPolicy）

镜像拉取策略（image PullPolicy）对于 Kubernetes Pod 中的容器部分非常重要，它决定了在容器启动时如何获取镜像。

Pod 的核心是运行容器，必须指定容器引擎，比如 Docker，启动容器时，需要拉取镜像，k8s 的镜像拉取策略可以由用户指定

镜像拉取的三种策略

IfNotPresent：如果镜像已经存在于节点上（本地），则不会从镜像仓库中拉取镜像。只有在本地缺少该镜像时，才会从镜像仓库中拉取。这是默认的镜像拉取策略。
Always：每次创建 Pod 时，都会强制从镜像仓库中拉取镜像，即使本地已经存在该镜像的版本。
Never：Pod 不会主动从镜像仓库拉取镜像，它假定本地已经存在所需镜像。如果本地不存在该镜像，则会导致容器启动失败。
对于镜像标签为“:latest”的镜像文件，其默认的拉取策略为“Always”，这意味着每次创建 Pod 时都会重新拉取最新版本的镜像。而对于其他标签的镜像，默认的拉取策略为“IfNotPresent”，只有当本地缺少该镜像时才会拉取。

在生产环境中，避免使用:latest标签是一个良好的实践。使用:latest标签可能导致以下问题：

版本追踪困难：由于:latest一直指向最新的镜像版本，因此在运行时很难确定正在使用的确切版本。这使得故障排除、审计和版本追踪变得更加困难。
难以正确回滚：如果使用:latest标签，并且在应用升级后出现问题，回滚到先前的版本可能会变得复杂，因为:latest一直指向新的版本。使用特定版本的标签可以更容易地进行回滚操作。

为了提高生产环境中的可维护性和可追溯性，推荐以下做法：

使用明确的镜像版本标签，例如nginx:1.2，而不是nginx:latest。
定期更新使用的镜像版本，并确保及时进行测试和部署。
在部署时明确指定所使用的镜像版本，以确保重现性和可控性。

总的来说，镜像拉取策略允许 Kubernetes 用户控制容器启动时镜像的获取行为，以确保应用程序始终使用正确的镜像版本。

官方示例

官方示例： https://kubernetes.io/docs/concepts/containers/images

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:name: private-image-test-1
spec:containers:- name: uses-private-imageimage: $PRIVATE_IMAGE_NAMEimagePullPolicy: Alwayscommand: [ "echo", "SUCCESS" ]
EOF

这段命令使用了 Kubernetes 的 kubectl apply 命令，并通过标准输入（stdin）传递了一个 Pod 的 YAML 配置文件。以下是对该配置文件的解析：

apiVersion: v1：指定 Kubernetes API 的版本，这里使用的是 v1 版本。
kind: Pod：定义了要创建的 Kubernetes 资源类型，这里是一个 Pod 对象。
metadata：指定 Pod 的元数据，包括名称等信息。
name: private-image-test-1：指定 Pod 的名称为 private-image-test-1。
spec：定义了 Pod 的规格，包括容器的配置信息。
containers：指定了 Pod 中包含的容器列表。
- name: uses-private-image：定义了一个名为 uses-private-image 的容器。
- image: $PRIVATE_IMAGE_NAME：指定了容器所使用的镜像。这里使用了一个变量 $PRIVATE_IMAGE_NAME，该变量的值可能是一个私有镜像的名称。
- imagePullPolicy: Always：指定了容器的镜像拉取策略为 Always，即每次创建 Pod 时都会重新拉取镜像。
- command: [ "echo", "SUCCESS" ]：定义了容器启动时要执行的命令，这里是输出 SUCCESS 消息。

该配置文件描述了一个 Pod，其中包含一个使用私有镜像的容器。通过 imagePullPolicy: Always 指定了每次创建 Pod 都会重新拉取镜像，以确保使用的是最新的镜像版本。

master01 上操作

kubectl edit deployment/nginx-deployment
......template:metadata:creationTimestamp: nulllabels:app: nginxspec:containers:- image: nginx:1.15.4imagePullPolicy: IfNotPresent                            #镜像拉取策略为 IfNotPresentname: nginxports:- containerPort: 80protocol: TCPresources: {}terminationMessagePath: /dev/termination-logterminationMessagePolicy: FilednsPolicy: ClusterFirstrestartPolicy: Always                                        #Pod的重启策略为 Always，默认值schedulerName: default-schedulersecurityContext: {}terminationGracePeriodSeconds: 30
......

这是一个对 nginx-deployment 的 Kubernetes 部署进行编辑的命令。以下是编辑部署时对部分配置的更改和一些注释：

kubectl edit deployment/nginx-deployment：通过编辑器编辑名为 nginx-deployment 的 Kubernetes 部署。
template：指定了部署中的 Pod 模板，即在每次创建 Pod 时使用的模板。
metadata：包含了 Pod 模板的元数据。
- creationTimestamp: null：指示该 Pod 模板的创建时间戳为空，表示此时尚未创建。
- labels：定义了一些标签，其中 app: nginx 是一个标识该 Pod 所属应用的标签。
spec：包含了 Pod 模板的规格。
- containers：指定了 Pod 中包含的容器列表。
- image: nginx:1.15.4：将容器使用的 nginx 镜像版本指定为 1.15.4。
- imagePullPolicy: IfNotPresent：设置容器的镜像拉取策略为 IfNotPresent，即如果本地不存在该镜像版本才会拉取。
- name: nginx：容器的名称为 nginx。
- ports：定义了容器监听的端口。
  - containerPort: 80：容器监听的端口号为 80。
  - protocol: TCP：端口协议为 TCP。
- resources: {}：未指定容器的资源限制。
- terminationMessagePath 和 terminationMessagePolicy：配置了容器终止时的消息路径和策略。
- dnsPolicy: ClusterFirst：指定了 Pod 的 DNS 策略为 ClusterFirst。
- restartPolicy: Always：设置 Pod 的重启策略为 Always，即当 Pod 终止时，始终尝试重启。
- schedulerName: default-scheduler：使用默认的调度器。
- securityContext: {}：未指定安全上下文。
- terminationGracePeriodSeconds: 30：定义了 Pod 终止的宽限期为 30 秒。

测试示例

//创建测试案例
mkdir /opt/demo
cd /opt/demovim pod1.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-test1
spec:containers:- name: nginximage: nginximagePullPolicy: Alwayscommand: [ "echo", "SUCCESS" ]kubectl create -f pod1.yamlkubectl get pods -o wide
pod-test1                         0/1     CrashLoopBackOff   4          3m33s
//此时 Pod 的状态异常，原因是 echo 执行完进程终止，容器生命周期也就结束了kubectl describe pod pod-test1//可以发现 Pod 中的容器在生命周期结束后，由于 Pod 的重启策略为 Always，容器再次重启了，并且又重新开始拉取镜像//修改 pod1.yaml 文件
cd /opt/demo
vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-test1
spec:containers:- name: nginximage: nginx:1.14                            #修改 nginx 镜像版本imagePullPolicy: Always#command: [ "echo", "SUCCESS" ]            #删除//删除原有的资源
kubectl delete -f pod1.yaml //更新资源
kubectl apply -f pod1.yaml //查看 Pod 状态
kubectl get pods -o wide
NAME                              READY   STATUS    RESTARTS   AGE   IP            NODE            NOMINATED NODE
pod-test1                         1/1     Running   0          33s   172.17.36.4   192.168.41.31   <none>//在任意 node 节点上使用 curl 查看头部信息
curl -I http://172.17.36.4
HTTP/1.1 200 OK
Server: nginx/1.14.2
......

这个示例提供了针对一个Kubernetes Pod的测试案例的步骤和结果。首先，创建了一个Pod，其中包含一个NGINX容器，但是容器的命令会导致进程终止，从而进入CrashLoopBackOff状态。然后，通过查看Pod的描述，可以观察到容器在重启，并且重新拉取镜像。接下来，修改了Pod的配置文件，将NGINX镜像版本更新为1.14，并删除了原有的命令。随后，删除了原有的资源并应用了更新后的配置文件。最后，检查了Pod的状态，并通过在任意节点上使用curl验证了NGINX服务器是否运行正常

pod 容器重启策略

重启策略是Kubernetes中用于定义Pod中容器的重新启动行为的设置。

重启策略的三种格式

Always（总是）：当容器终止时，无论是正常还是异常退出，都会被重新启动。
OnFailure（失败时）：只有当容器异常退出（退出状态码非0）时，才会触发重新启动；正常退出（退出状态码为0）时则不会重新启动。
Never（从不）：不会自动重新启动容器，无论退出原因。

这策略可在Pod的配置中设置，如前述的 restartPolicy: Always，以控制容器的生命周期行为。

kubectl edit deployment nginx-deployment
......restartPolicy: Always

这段命令是通过编辑名为 nginx-deployment 的部署（Deployment）来修改其重启策略为 Always（总是重启）。这意味着当该部署中的Pod中的容器终止时，无论是正常退出还是异常退出，Kubernetes都会自动重新启动这些容器，以确保服务的可用性。

示例

vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:name: foo
spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 30; exit 3kubectl apply -f pod3.yaml//查看Pod状态，等容器启动后30秒后执行exit退出进程进入error状态，就会重启次数加1
kubectl get pods
NAME                              READY   STATUS             RESTARTS   AGE
foo                               1/1     Running            1          50skubectl delete -f pod3.yamlvim pod3.yaml
apiVersion: v1
kind: Pod
metadata:name: foo
spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 30; exit 3restartPolicy: Never
#注意：跟container同一个级别kubectl apply -f pod3.yaml//容器进入error状态不会进行重启
kubectl get pods -w

在这个示例中，首先创建了一个名为 foo 的Pod，其中包含一个busybox容器，其命令是睡眠30秒然后退出进程，导致容器进入错误状态，触发一次重启。然后，删除了原有的Pod并修改了Pod的配置文件，将重启策略修改为Never（从不重启）。接着，重新应用了更新后的Pod配置文件。在这种情况下，即使容器进入错误状态，由于重启策略已设置为Never，Kubernetes也不会自动重新启动该容器。

pod状态

Pending：Pod 已被系统接受，但容器尚未创建。这可能是因为调度到节点上的时间或下载镜像的时间。持续一段时间。
Running：Pod 已与节点绑定，其中至少一个容器正在运行或启动中。需要进一步检查容器状态，因为 Pod 虽然运行，但容器不一定完全可用。
Succeeded：很少见的状态，表示 Pod 中的所有容器已成功终止，并且不会重新启动。
Failed：所有容器都已非正常终止，至少一个容器返回了非零退出码或被系统直接终止。
Unknown：由于通信问题等原因，无法获取 Pod 的状态。通常情况下，最常见的是前两种状态

Container生命周期

Waiting：在启动和运行之间的等待状态，可能有等待依赖或资源。
Running：容器正在运行状态，正常运行中。
Terminated：容器已终止状态。如果长时间处于等待状态，会有一个reason字段指示其状态和原因。若原因（如ContainerCannotRun）表明容器无法启动，整个服务启动会迅速返回。这是一种失败状态返回的特性。