云原生技术与应用-Kubernetes Pod深度理解
一.什么是pod一.什么是podPod 是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及运行规范。在 Pod 中，所有容器都被统一安排和调度。对于具体应用而言，Pod 是它们的逻辑主机，Pod 包含业务相关的多个应用容器。所以，Pod 是一组具有共享命名空间、IP 地址和端口的容器的集合。1.从使用的角度来看在实际的使用时，单个容器是无法单独来支撑我们的应用的，往往需要很多微服务才能
·
目录
2.编写pod配置文件frontend-localredis-pod.yaml
一.什么是pod
Pod 是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及运行规范。在 Pod 中，所有容器都被统一安排和调度。对于具体应用而言，Pod 是它们的逻辑主机，Pod 包含业务相关的多个应用容器。所以，Pod 是一组具有共享命名空间、IP 地址和端口的容器的集合。
1.从使用的角度来看
在实际的使用时，单个容器是无法单独来支撑我们的应用的，往往需要很多微服务才能组成一个系统，并且还会存在 A 服务依赖 B 服务，B 服务需要和 C 服务共用某个目录。另外，在使用裸容器时，很难实现对容器内进行健康检查以及横向扩容等操作，而 Pod 可以轻松解决这些问题。
2.从kubernetes的角度来看
Docker 只是容器 Runtime（运行时）的一种们还有很多容器 Runtime，比如 Rkt、CRI-O 等，而Kubernetes 作为目前最流行的容器编排工具，需要支持各个 Runtime 并且不依赖于底层 Runtime 的实现技术，于是就抽象出了 Pod 这个概念，用于管理多个紧密相连的符合 CRI 标准的容器。
Pod 可以简单的理解为一组、一个或多个容器，每个 Pod 还包含一个 Pause 容器，Pause 容器是 Pod 的父容器，主要负责僵尸进程的回收管理。同时，通过 Pause 容器可以使同一个 Pod 里面的不同容器共享存储、网络、PID、IPC（进程间通信）等，容器之间可以使用 Localhost:Port 的方式相互访问，可以使用 volume 实现数据共享。根据 Docker 的构造，Pod 可以被创建为一组具有共享命名空间、IP 地址和端口的容器。
Pod 有两个必须知道的特点：
网络：每一个 Pod 都会被指派一个唯一的 Ip 地址，在 Pod 中的每一个容器共享网络命名空间，包括 Ip 地址和网络端口。在同一个 Pod 中的容器可以同 localhost 进行互相通信。当 Pod 中的容器需要与 Pod 外的实体进行通信时，则需要通过端口等共享的网络资源。
存储：Pod 能够被指定共享存储卷的集合，在 Pod 中所有的容器能够访问共享存储卷，允许这些容器共享数据。存储卷也允许在一个 Pod 持久化数据，以防止其中的容器需要被重启。
3.pod的状态
（1）kubectl命令创建pod
[root@k8s-master ~]#kubectl run nginx --images=nginx:1.7.9 --labels="app=nginx"
（2）查看pod
[root@k8s-master ~]# kubectl get pods -n default
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 5m57s
（3）显示pod的更多信息
[root@k8s-master ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 8m16s 10.244.58.193 k8s-node02 <none> <none>
（4）查看pod日志
[root@k8s-master ~]# curl 10.244.58.193
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p><p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p><p><em>Thank you for using nginx.</em></p>
</body>
</html>ku logs nginx
10.244.235.192 - - [18/Jul/2025:06:30:56 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/8.4.0" "-"
（5）以yaml格式显示pod详细信息
[root@k8s-master ~]# kubectl get pod -o yaml
apiVersion: v1
items:
- apiVersion: v1
kind: Pod
metadata:
annotations:
cni.projectcalico.org/containerID: a78fc4507cb22e43f1cfb0ae528d1aa1c7a2bf69ebff2191736018b0693499f1
cni.projectcalico.org/podIP: 10.244.58.193/32
cni.projectcalico.org/podIPs: 10.244.58.193/32
creationTimestamp: "2025-07-18T06:21:17Z"
labels:
app: nginx
name: nginx
namespace: default
resourceVersion: "7184"
uid: f7d7f986-6dcc-48cf-be32-d34bd673231f
spec:
containers:
- image: nginx:1.7.9
imagePullPolicy: IfNotPresent
name: nginx
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: kube-api-access-46sdc
readOnly: true
dnsPolicy: ClusterFirst
enableServiceLinks: true
nodeName: k8s-node02
preemptionPolicy: PreemptLowerPriority
priority: 0
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: default
serviceAccountName: default
terminationGracePeriodSeconds: 30
tolerations:
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
volumes:
- name: kube-api-access-46sdc
projected:
defaultMode: 420
sources:
- serviceAccountToken:
expirationSeconds: 3607
path: token
- configMap:
items:
- key: ca.crt
path: ca.crt
name: kube-root-ca.crt
- downwardAPI:
items:
- fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
path: namespace
status:
conditions:
- lastProbeTime: null
lastTransitionTime: "2025-07-18T06:21:17Z"
status: "True"
type: Initialized
- lastProbeTime: null
lastTransitionTime: "2025-07-18T06:21:18Z"
status: "True"
type: Ready
- lastProbeTime: null
lastTransitionTime: "2025-07-18T06:21:18Z"
status: "True"
type: ContainersReady
- lastProbeTime: null
lastTransitionTime: "2025-07-18T06:21:17Z"
status: "True"
type: PodScheduled
containerStatuses:
- containerID: docker://7e66fac7ac6a9b53e937a106de28444d351d037c0837c80d1810447210638939
image: nginx:1.7.9
imageID: docker://sha256:84581e99d807a703c9c03bd1a31cd9621815155ac72a7365fd02311264512656
lastState: {}
name: nginx
ready: true
restartCount: 0
started: true
state:
running:
startedAt: "2025-07-18T06:21:18Z"
hostIP: 192.168.10.103
phase: Running
podIP: 10.244.58.193
podIPs:
- ip: 10.244.58.193
qosClass: BestEffort
startTime: "2025-07-18T06:21:17Z"
kind: List
metadata:
resourceVersion: ""
selfLink: ""
（6）显示资源的详细描述信息
[root@k8s-master ~]# kubectl describe pod nginx
Name: nginx
Namespace: default
Priority: 0
Node: k8s-node02/192.168.10.103
Start Time: Fri, 18 Jul 2025 14:21:17 +0800
Labels: app=nginx
Annotations: cni.projectcalico.org/containerID: a78fc4507cb22e43f1cfb0ae528d1aa1c7a2bf69ebff2191736018b0693499f1
cni.projectcalico.org/podIP: 10.244.58.193/32
cni.projectcalico.org/podIPs: 10.244.58.193/32
Status: Running
IP: 10.244.58.193
IPs:
IP: 10.244.58.193
Containers:
nginx:
Container ID: docker://7e66fac7ac6a9b53e937a106de28444d351d037c0837c80d1810447210638939
Image: nginx:1.7.9
Image ID: docker://sha256:84581e99d807a703c9c03bd1a31cd9621815155ac72a7365fd02311264512656
Port: <none>
Host Port: <none>
State: Running
Started: Fri, 18 Jul 2025 14:21:18 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-46sdc (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kube-api-access-46sdc:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 22m default-scheduler Successfully assigned default/nginx to k8s-node02
Normal Pulled 22m kubelet Container image "nginx:1.7.9" already present on machine
Normal Created 22m kubelet Created container nginx
Normal Started 22m kubelet Started container nginx
（7）登录到pod中的容器中
[root@k8s-master ~]# ku exec -it nginx -c nginx -- bash
root@nginx:/# cd /usr/share//nginx/html/
root@nginx:/usr/share/nginx/html# ls
50x.html index.html
root@nginx:/usr/share/nginx/html# cd
root@nginx:~#
root@nginx:~# exit
exit
（8）pod的状态
[root@k8s-master ~]# ku get pods -n default
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 3h29m
pod状态字段phase的不同取值
| 状态 | 说明 |
|---|---|
| Pending（挂起） | Pod 已经被 Kubernetes 系统接收，但是仍有一个或多个容器未被创建，可以通过 kubectl describe 查看处于 Pending 状态的原因。 |
| Running（运行中） | Pod 已经被绑定到一个节点上，并且所有的容器都已经被创建，而且至少有一个是运行的状态、正在启动或者重启，可以通过 kubectl logs 查看 Pod 的日志。 |
| Succeeded | 所有容器执行成功，并终止，并且不会再次重启，可以通过 kubectl logs 查看 Pod 的日志 |
| Failed（失败） | 所有容器都已终止，并且至少一个容器以失败的方式终止，也就是说这个容器要么以非零状态退出，要么被系统终止，可以通过 logs 和 describe 查看 Pod 的日志和状态 |
| Unknown（未知） | 通常是由于通信问题造成的无法获得 Pod 的状态 |
| ImagePullBackOff ErrImagePull | 镜像拉取失败，一般是由于镜像不存在、网络不通或者需要登录认证引起的，可以使用 describe 命令查看具体的原因 |
| CrashLoopBackOff | 容器启动失败，可以通过 logs 命令查看具体的原因，一般为启动命令不正确、健康检查不通过等原因 |
| OOMKilled | 容器内存溢出，一般是容器的内存 Limit 设置的过小，或者程序本身有内存溢出，可以通过 logs 查看程序的启动日志 |
| Terminating | Pod 正在被删除，可以通过 describe 查看状态 |
| SysctlForbiden | Pod 自定义了内核配置，但 kubectl 没有添加内核配置或配置的内核参数不支持，可以通过 describe 查看具体原因 |
| Completed | 容器内部主进程退出，一般计划任务执行结束会显示该该状态，此时可以通过 logs 查看容器日志 |
| ContainerCreating | Pod 正在创建，一般正在下载镜像，或者有配置不当的地方，可以通过 describe 查看具体原因 |
（9）删除pod
kubectl delete pod nginx
二：Pod 探针
在生产环境中，进程正常启动并不代表应用能正常处理请求，所以合理的设计应用的健康检查尤其重要。在使用裸机或虚拟机部署时，一般很难对应用做完善的健康检查，而 Pod 提供的探针可以很方便的用来检测容器的应用是否正常。
1：Pod 探针的实现方式
目前探针有 3 种检测方式，可以根据不同的场景选择合适的健康检查方式，分别是 ExecAction、TCPSocketAction 和 HTTPGetAction，具体实现方式如表 2 所示。
表 2：Pod 探针的实现方式
实现方式 |
说明 |
|---|---|
ExecAction |
在容器内执行一个指定的命令，如果命令返回值为 0，则认为容器健康 |
TCPSocketAction |
通过 TCP 连接检查容器指定的端口，如果端口开放，则认为容器健康 |
HTTPGetAction |
对指定的 URL 进行 get 请求，如果状态码在 200 - 400 之间，则认为容器健康 |
2：容器状态
上述的检查方式可以被周期性的执行，每次检查容器后可能得到的容器状态如表 3 所示。
表 3：Pod 探针检查容器后可能得到的状态
状态 |
说明 |
|---|---|
Success（成功） |
容器通过检查 |
Failure（失败） |
容器检查失败 |
Unknown（未知） |
诊断失败，因此不采取任何措施 |
3：Pod 探针类型
Pod 探针有三类，分别是：livenessProbe（存活探针）、readinessProbe（就绪探针）、startupProbe（启动探针）。
（1）livenessProbe（存活探针）
它被用来知道一个容器是否在正常运行。如果容器未能通过存活探针的检查，则系统会认为该容器已经进入了一个必须被重启的状态，从而自动重启这个容器。这种机制可以确保容器在出现问题后能够自动恢复到可用状态。
存活探针支持以下几种类型：
-
HTTP GET 请求 ：通过发送 HTTP 请求到容器内的某个 URL 来检测容器是否处于健康状态。
-
Exec 执行命令 ：在容器内执行一个自定义命令或可执行文件，并根据其返回码判断容器是否健康。
-
TCP Socket ：尝试打开一个 TCP socket 连接到容器上的指定端口，如果连接成功则认为容器是健康的。
（2）readinessProbe（就绪探针）
判断容器是否能够进入 ready 状态，用于确定 Pod 中的容器是否已准备好接收流量。与 livenessProbe 不同，readinessProbe 主要关注的是容器是否已经准备好为服务提供者处理请求。如果容器没有通过就绪探针的检查，Kubernetes 将不会把任何新的网络流量路由到这个容器上。
当一个容器报告自己尚未准备好时，Kubernetes 可能会采取以下行动： -
服务（Service）不会将流量路由到未准备好的 Pod。
-
如果 Pod 是副本集（ReplicaSet）、部署（Deployment）、状态集（StatefulSet）等的一部分，控制器会认为这个实例不可用。
-
对于使用 Pod 的滚动更新策略的情况，就绪探针可以帮助确保新版本的 Pod 在旧版本被终止之前就已经准备好了。
就像 livenessProbe 一样，readinessProbe 也支持多种类型的探测方法：
-
HTTP GET 请求：发送 HTTP 请求到容器内的某个 URL。
-
Exec 执行命令：在容器内执行一个自定义命令或可执行文件。
-
TCP Socket：尝试建立一个到容器上的指定端口的 TCP 连接。
（3）startupProbe（启动探针）
判断容器内的应用是否启动成功，在 success 状态前，其它探针都处于无效状态。它专门用于检测容器是否完成了初始化并进入了预期的运行状态。与 livenessProbe（存活探针）和 readinessProbe（就绪探针）不同，startupProbe 专用于容器启动阶段，并且仅在容器启动过程中使用。
startupProbe 的主要作用是在容器启动期间持续检查容器是否已经完成启动。一旦容器通过 startupProbe 的检查，Kubernetes 就会认为容器已经成功启动，并停止对该容器的启动探针检查。如果容器始终无法通过启动探针的检查，那么 Kubernetes 将会根据配置重试一定的次数，超过重试次数后可能会采取进一步的措施，如重启容器。
三.pod镜像拉取策略和重启策略
1: 镜像拉取策略
在发布应用或者更新镜像版本时，会触发 Pod 的滚动更新，此时针对镜像的拉取有不同的拉取方式， 如表 4 所示。
表 4: 镜像拉取策略
拉取方式 |
说明 |
|---|---|
Always |
总是拉取，无论镜像是否存在，总是拉取镜像进行部署（如 sidecar 容器、 初始化容器等 ）。 |
Never |
永远不会有任何拉取镜像操作，适用于任务型 Pod（如批处理任务 ），当完成后不需要重启。 |
IfNotPresent |
如果不存在的话则拉取，默认是 lfNotPresent 策略，且总是拉取 tag 为 latest ，需注意拉取 |
指定拉取策略： |
|
kubectl run nginx --image=nginx:1.7.9 --labels="app=nginx" --image -pull -policy=never |
2: Pod 重启策略
在 Kubernetes 中，Pod 重启策略（RestartPolicy）定义了容器退出或发生异常（unhealthy）如何处理策略，重启策略是 Pod 级别的设置，适用于 Pod 中的所有容器。
在 Always 策略中，只要容器退出（无论退出码是什么 ），kubelet 都会自动重启容器，适用于需要保持持续运行的任务（如 Web 服务器、数据库等 ）。
在 OnFailure 策略中，只有当容器以非零退出码退出时，kubelet 才重启容器，如果容器正常退出（返回码为 0 ），则不会重启，适用于任务型 Pod（如批处理任务 ），当完成后不需要重启。
在 Never 策略中，无论容器以何种方式退出，kubelet 都不会重启容器，适用于一次性任务，任务完成后不需要重启。
各个策略的管理控制如表 5。
表 5: Pod 重启策略
策略方式 |
说明 |
|---|---|
Always |
容器退出即重启，适用于长期运行的服务。 |
OnFailure |
容器失败时重启，适用于任务型工作负载。 |
Never |
容器退出后不重启，适用于一次性任务。 |
指定重启策略： |
|
kubectl delete pod nginx |
|
kubectl run nginx --image=nginx:1.7.9 --labels="app=nginx" --restart=OnFailure |
四.创建一个简单的pod
1.编写一个简单的pod
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
2.编写 Pod 配置文件 frontend-localredis-pod.yaml
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
apiVersion: v1 ## 必选，版本号，
kind: Pod ## 必选，资源类型
metadata: ## 必选，元数据
name: redis-php ## 必选，Pod 名称
labels: ## 自定义的 pod 标签列表
name: redis-php ## 标签值
spec: ## 必选，Pod 中容器的详细信息
containers: ## 必选，Pod 中的容器列表
-
name: frontend ## 必选，自定义的容器名称
image: kubeguide/guestbook-php-frontend:localredis ## 必选，容器的镜像名称
imagePullPolicy: IfNotPresent ## 镜像拉取策略
livenessProbe: 设置存活探针
tcpSocket: ## 测试某端口是否可以连接
port: 80 ## 指定要测试的端口
initialDelaySeconds: 1 #指定 kubelet 在执行第一次探测前应该等待 1 秒，即第一次探测是
# 在容器启动后的第 2 秒才开始执行。默认是 0 秒，最小值是 0
periodSeconds: 3 #指定了 kubelet 应该每 3 秒执行一次存活探测。默认是 10 秒。最小值是 1
timeoutSeconds: 1 ## 当探测失败时，kubernetes 在超时之前等待的时间。存活探测情况下的放
## 弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标
## 签。默认值是 3。最小值是 1
ports: ## 需要暴露的端口号列表-
containerPort: 80 ## 容器需要监听的端口号
-
-
name: redis ## 另一个容器的名字
image: kubeguide/redis-master ## 另一个容器的镜像
ports: ## 需要暴露的另一个容器的端口列表-
containerPort: 6379 ## 容器需要监听的端口号
restartPolicy: OnFailure ## 重启策略
-
3. Pod 文件语法
(1) Pod 文件的一级属性
一级属性主要包含 5 部分：
-
apiVersion <string> 版本，由 kubernetes 内部定义，版本号必须可以用 kubectl api-versions 查询到
-
kind <string> 类型，由 kubernetes 内部定义，版本号必须可以用 kubectl api-resources 查询到
-
metadata <Object> 元数据，主要是资源标识和说明，常用的有 name、namespace、labels 等
-
spec <Object> 描述，是总配置中最重要的一部分，里面是对各种资源配置的详细描述
-
status <Object> 状态信息，里面的内容不需要定义，由 kubernetes 自动生成
(2) spec（规格）属性
在一级属性中，spec 是研究的重点，它的常见子属性有：
-
containers <[] Object> 容器列表，用于定义容器的详细信息
-
nodeName <string> 根据 nodeName 的值将 pod 调度到指定的 Node 节点上
-
nodeSelector <map []> 根据 NodeSelector 中定义的信息选择将该 Pod 调度到包含这些 label 的 Node 上
-
hostNetwork <boolean> 是否使用主机网络模式，默认为 false，如果设置为 true，表示使用宿主主机网络
-
volumes <[] Object> 存储卷，用于定义 Pod 上面挂在的存储信息
-
restartPolicy<string> 重启策略，表示 Pod 在遇到故障时的处理策略
（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
kubectl create -f nginx-pod.yaml
kubectl create -f frontend-localredis-pod.yaml
5.查看已经创建的 Pod
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 5s
redis-php 2/2 Running 0 31s
6. 查看 pod 详细创建信息
7:.删除 pod
kubectl describe pod redis-php
kubectl delete -f frontend-localredis-pod.yaml
五.pod的基本用法
1: 编写 pod 文件，将两个容器放在同一个 pod 中
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 文件
kubectl apply -f nginx-php.yaml
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-php 2/2 Running 0 28s
备注：
此时可以看到 pod 中有两个容器处于 running 状态中
3: 查看 pod 的详细信息
kubectl describe pod nginx-php
4: 暴露端口
kubectl expose pod nginx-php --port=8080 --target-port=80 --type=NodePort --name=nginx-php
5: 查看端口映射
kubectl get pod,svc nginx-php -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/nginx-php 2/2 Running 0 2455s 172.25.244.109 k8s-master01 <none> <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/nginx-php NodePort 10.99.26.216 <none> 8080:32508/TCP 242s name=nginx-php
6: 测试访问
用外部主机，访问 master 的 ip 地址：映射的端口
http://192.168.10.181:32508/
7.删除pod
kubectl delete -f nginx-php.yaml
六.静态pod
静态 Pod 是由 kubelet 进行管理的仅存在于各个 Node 上的 Pod，他们不能通过 API Server 进行管理，无法于 ReplicationController、Deployment 或者 DaemonSet 进行关联，并且 kubelet 无法对他们进行健康检查。静态 Pod 总是由 kubelet 创建的，并且总在 kubelet 所在的 Node 上运行。
1: 编写 yaml 文件
vim /etc/kubernetes/manifests/nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
name: static-web
spec:
containers:
-
name: static-web
image: nginx:1.7.9
ports:-
name: nginx
containerPort: 80
-
2: 不需执行部署命令，过一会，查看 pod
kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-php 2/2 Running 4 (18m ago) 20m
static-web-k8s-master01 1/1 Running 0 20s
3: 删除静态 pod 的方法
rm -rf /etc/kubernetes/manifests/nginx-pod.yaml
备注：
不能用如下语句删除
kubectl delete pod static-web-k8s-master01
这样删除，会让 pod 处于 pending 状态，但无法删除
开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。
更多推荐
30
0- 0
已为社区贡献2条内容
所有评论(0)