Pod是一个逻辑抽象概念，K8s创建和管理的最小单元，一个Pod由一个容器或多个容器组成。 特点：
Pod主要用法：
扩展：READY字段的意义:
tantianran@test-b-k8s-master:~$ kubectl get pods -n test-a
NAME READY STATUS RESTARTS AGE
goweb-demo-b98869456-25sj9 1/1 Running 1 (3m49s ago) 5d10h
在READY字段中，1/1的意义为在这个pod里，已准备的容器/一共有多少个容器。
在pod中，它可以有3种类型的容器，分别是：
共享网络的机制是由Pause容器实现，下面慢慢分析一下，啥是pause，了解一下它的作用等等。
先准备一个yaml文件（pod1.yaml ），创建一个pod，pod里包含两个容器，一个是名为nginx1的容器，还有一个是名为bs1的容器
apiVersion: v1
kind: Pod
metadata:
name: test-pod1
spec:
containers:
- image: nginx
name: nginx1
volumeMounts:
- mountPath: /cache
name: cache-volume
- image: busybox
name: bs1
command: ["/bin/sh", "-c", "sleep 12h"]
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir:
sizeLimit: 500Mi
开始创建
tantianran@test-b-k8s-master:~$ kubectl create -f pod1.yaml
pod/test-pod1 created
创建完后看看在哪个节点
tantianran@test-b-k8s-master:~$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test-pod1 2/2 Running 0 9m21s 10.244.222.44 test-b-k8s-node02
去到对应的节点查看容器
tantianran@test-b-k8s-node02:~$ sudo docker ps | grep test-pod1
0db01653bdac busybox "/bin/sh -c 'sleep 1…" 9 minutes ago Up 9 minutes k8s_bs1_test-pod1_default_c3a15f70-3ae2-4a73-8a84-d630c047d827_0
296972c29efe nginx "/docker-entrypoint.…" 9 minutes ago Up 9 minutes k8s_nginx1_test-pod1_default_c3a15f70-3ae2-4a73-8a84-d630c047d827_0
a5331fba7f11 registry.aliyuncs.com/google_containers/pause:latest "/pause" 10 minutes ago Up 10 minutes k8s_POD_test-pod1_default_c3a15f70-3ae2-4a73-8a84-d630c047d827_0
tantianran@test-b-k8s-node02:~$
通过查看容器，名为test-pod1的pod里，除了两个业务容器外（k8s_bs1_test-pod1、nginx1_test-pod1），还有一个pause容器。这个到底是什么鬼呢？
「对pause容器的理解」
nginx1容器里的nginx组件默认监听的端口是80，在bs1容器里去curl http://127.0.0.1 就可以放到nginx1容器的80端口。
# step1：查看test-pod1里的容器
kubectl get pods test-pod1 -o jsonpath={.spec.containers[*].name}
# step2：进入指定容器
kubectl exec -it test-pod1 -c bs1 -- sh
# 访问nginx（因没有curl命令，此处用wget）
/ # wget http://127.0.0.1
Connecting to 127.0.0.1 (127.0.0.1:80)
saving to 'index.html'
index.html 100% |*************************************************************************************************************| 615 0:00:00 ETA
'index.html' saved
/ #
上面看到，使用wget命令下载到了index.html文件，说明访问成功。
kubectl get pods test-pod1 -o jsonpath={.spec.containers[*].name}
kubectl exec -it test-pod1 -c nginx1 -- bash
kubectl exec -it test-pod1 -c bs1 -- sh
kubectl logs test-pod1 -c nginx1
「重启策略」
查看pod的重启策略
# 查看pod，以yaml格式输出
kubectl get pods test-pod1 -o yaml
# 找到restartPolicy字段，就是重启策略
restartPolicy: Always
「健康检查有以下3种类型：」
健康检查是检查容器里面的服务是否正常
「支持以下三种检查方法：」
「案例实战」
livenessProbe（存活探针）：使用exec的方式（执行Shell命令返回状态码是0则为成功）
apiVersion: v1
kind: Namespace
metadata:
name: test-a
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: goweb-demo
namespace: test-a
spec:
replicas: 10
selector:
matchLabels:
app: goweb-demo
template:
metadata:
labels:
app: goweb-demo
spec:
containers:
- name: goweb-demo
image: 192.168.11.247/web-demo/goweb-demo:20221229v3
livenessProbe:
exec:
command:
- ls
- /opt/goweb-demo/runserver
initialDelaySeconds: 5
periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
name: goweb-demo
namespace: test-a
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8090
selector:
app: goweb-demo
type: NodePort
periodSeconds 字段指定了 kubelet 应该每 5 秒执行一次存活探测，initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒，kubelet 在容器内执行命令 ls /opt/goweb-demo/runserver 来进行探测。 如果命令执行成功并且返回值为 0，kubelet 就会认为这个容器是健康存活的。 如果这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它。
验证存活检查的效果
# 查看某个pod的里的容器，
kubectl get pods goweb-demo-686967fd56-556m9 -n test-a -o jsonpath={.spec.containers[*].name}
# 进入某个pod里的容器
kubectl exec -it goweb-demo-686967fd56-556m9 -c goweb-demo -n test-a -- bash
# 进入容器后，手动删除掉runserver可执行文件，模拟故障
rm -rf /opt/goweb-demo/runserver
# 查看Pod详情（在输出结果的最下面，有信息显示存活探针失败了，这个失败的容器被杀死并且被重建了。）
kubectl describe pod goweb-demo-686967fd56-556m9 -n test-a
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Unhealthy 177m (x6 over 3h59m) kubelet Liveness probe failed: ls: cannot access '/opt/goweb-demo/runserver': No such file or directory
# 一旦失败的容器恢复为运行状态，RESTARTS 计数器就会增加 1
tantianran@test-b-k8s-master:~$ kubectl get pods -n test-a
NAME READY STATUS RESTARTS AGE
goweb-demo-686967fd56-556m9 1/1 Running 1 (22s ago) 13m # RESTARTS字段加1，
goweb-demo-686967fd56-8hzjb 1/1 Running 0 13m
...
livenessProbe（存活探针）：使用 httpGet 请求的方式检查uri path是否正常
apiVersion: v1
kind: Namespace
metadata:
name: test-a
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: goweb-demo
namespace: test-a
spec:
replicas: 10
selector:
matchLabels:
app: goweb-demo
template:
metadata:
labels:
app: goweb-demo
spec:
containers:
- name: goweb-demo
image: 192.168.11.247/web-demo/goweb-demo:20221229v3
livenessProbe:
httpGet:
path: /login
port: 8090
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
---
apiVersion: v1
kind: Service
metadata:
name: goweb-demo
namespace: test-a
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8090
selector:
app: goweb-demo
type: NodePort
在这个配置文件中，你可以看到 Pod 也只有一个容器。 periodSeconds 字段指定了 kubelet 每隔 3 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。 kubelet 会向容器内运行的服务（服务在监听 8090 端口）发送一个 HTTP GET 请求来执行探测。 如果服务器上 /login 路径下的处理程序返回成功代码，则 kubelet 认为容器是健康存活的。 如果处理程序返回失败代码，则 kubelet 会杀死这个容器并将其重启。返回大于或等于 200 并且小于 400 的任何代码都表示成功，其它返回代码都表示失败。
验证效果
# 进入容器删除静态文件，模拟故障
kubectl exec -it goweb-demo-586ff85ddb-4646k -c goweb-demo -n test-a -- bash
rm -rf login.html
# 查看pod的log
kubectl logs goweb-demo-586ff85ddb-4646k -n test-a
2023/01/12 06:45:19 [Recovery] 2023/01/12 - 06:45:19 panic recovered:
GET /login HTTP/1.1
Host: 10.244.222.5:8090
Connection: close
Accept: */*
Connection: close
Custom-Header: Awesome
User-Agent: kube-probe/1.25
html/template: "login.html" is undefined
/root/my-work-space/pkg/mod/github.com/gin-gonic/gin@v1.8.2/context.go:911 (0x8836d1)
/root/my-work-space/pkg/mod/github.com/gin-gonic/gin@v1.8.2/context.go:920 (0x88378c)
/root/my-work-space/src/goweb-demo/main.go:10 (0x89584e)
# 查看pod详情
kubectl describe pod goweb-demo-586ff85ddb-4646k -n test-a
Warning Unhealthy 34s (x3 over 40s) kubelet Liveness probe failed: HTTP probe failed with statuscode: 500 # 状态码为500
# 恢复后查看Pod，RESTARTS计数器已经增1
kubectl get pod goweb-demo-586ff85ddb-4646k -n test-a
NAME READY STATUS RESTARTS AGE
goweb-demo-586ff85ddb-4646k 1/1 Running 1 (80s ago) 5m39s
readinessProbe（就绪探针）结合livenessProbe（存活探针）探测tcp端口：
第三种类型的存活探测是使用 TCP 套接字。 使用这种配置时，kubelet 会尝试在指定端口和容器建立套接字链接。 如果能建立连接，这个容器就被看作是健康的，如果不能则这个容器就被看作是有问题的。
apiVersion: v1
kind: Namespace
metadata:
name: test-a
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: goweb-demo
namespace: test-a
spec:
replicas: 10
selector:
matchLabels:
app: goweb-demo
template:
metadata:
labels:
app: goweb-demo
spec:
containers:
- name: goweb-demo
image: 192.168.11.247/web-demo/goweb-demo:20221229v3
readinessProbe:
tcpSocket:
port: 8090
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8090
initialDelaySeconds: 15
periodSeconds: 20
---
apiVersion: v1
kind: Service
metadata:
name: goweb-demo
namespace: test-a
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8090
selector:
app: goweb-demo
type: NodePort
TCP 检测的配置和 HTTP 检测非常相似。 这个例子同时使用就绪和存活探针。kubelet 会在容器启动 5 秒后发送第一个就绪探针。 探针会尝试连接 goweb-demo 容器的 8090 端口。 如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次探测。除了就绪探针，这个配置包括了一个存活探针。 kubelet 会在容器启动 15 秒后进行第一次存活探测。 与就绪探针类似，存活探针会尝试连接 goweb-demo 容器的 8090 端口。 如果存活探测失败，容器会被重新启动。
验证效果
# 进入容器后，杀掉goweb-demo的进程
kubectl exec -it goweb-demo-5d7d55f846-vm2kc -c goweb-demo -n test-a -- bash
root@goweb-demo-5d7d55f846-vm2kc:/opt/goweb-demo# ps -aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 2476 576 ? Ss 07:23 0:00 /bin/sh -c /opt/goweb-demo/runserver
root@goweb-demo-5d7d55f846-vm2kc:/opt/goweb-demo# kill -9 1
# 查看pod详情，已经发出警告
kubectl describe pod goweb-demo-5d7d55f846-vm2kc -n test-a
Warning Unhealthy 16s kubelet Readiness probe failed: dial tcp 10.244.240.48:8090: connect: connection refused
Warning BackOff 16s kubelet Back-off restarting failed container
# 查看pod，RESTARTS计数器已经增加为2，因为有两个探针
tantianran@test-b-k8s-master:~$ kubectl get pod -n test-a
NAME READY STATUS RESTARTS AGE
goweb-demo-5d7d55f846-vm2kc 1/1 Running 2 (2m55s ago) 12m
使用startupProbe（启动探针）保护慢启动容器
有一种情景是这样的，某些应用在启动时需要较长的初始化时间。要这种情况下，若要不影响对死锁作出快速响应的探测，设置存活探测参数是要技巧的。 技巧就是使用相同的命令来设置启动探测，针对 HTTP 或 TCP 检测，可以通过将 failureThreshold * periodSeconds 参数设置为足够长的时间来应对糟糕情况下的启动时间。
apiVersion: v1
kind: Namespace
metadata:
name: test-a
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: goweb-demo
namespace: test-a
spec:
replicas: 10
selector:
matchLabels:
app: goweb-demo
template:
metadata:
labels:
app: goweb-demo
spec:
containers:
- name: goweb-demo
image: 192.168.11.247/web-demo/goweb-demo:20221229v3
livenessProbe:
httpGet:
path: /login
port: 8090
failureThreshold: 1
periodSeconds: 10
startupProbe:
httpGet:
path: /login
port: 8090
failureThreshold: 30
periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: goweb-demo
namespace: test-a
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8090
selector:
app: goweb-demo
type: NodePort
上面的例子，应用程序将会有最多 5 分钟（30 * 10 = 300s）的时间来完成其启动过程。 一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁作出快速响应。 如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 restartPolicy 来执行进一步处置。
创建 Pod 时，可以为其下的容器设置环境变量。通过配置文件的 env 或者 envFrom 字段来设置环境变量。
应用场景：
变量值定义的方式：
下面来个小例子，设置自定义变量，使用env给pod里的容器设置环境变量，本例子中，设置了环境变量有SAVE_TIME、MAX_CONN、DNS_ADDR。
apiVersion: v1
kind: Pod
metadata:
name: test-env-demo
spec:
containers:
- name: test-env-demo-container
image: 192.168.11.247/web-demo/goweb-demo:20221229v3
env:
- name: SAVE_TIME
value: "60"
- name: MAX_CONN
value: "1024"
- name: DNS_ADDR
value: "8.8.8.8"
开始创建pod
tantianran@test-b-k8s-master:~$ kubectl create -f test-env.yaml
pod/test-env-demo created
tantianran@test-b-k8s-master:~$
创建后，验证环境变量是否能获取到
# 使用printenv打印环境变量
tantianran@test-b-k8s-master:~/goweb-demo$ kubectl exec test-env-demo -- printenv
PATH=/go/bin:/usr/local/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=test-env-demo
SAVE_TIME=60 # 这个是
MAX_CONN=1024 # 这个是
DNS_ADDR=8.8.8.8 # 这个是
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
GOLANG_VERSION=1.19.4
GOPATH=/go
HOME=/root
tantianran@test-b-k8s-master:~/goweb-demo$
# 进入容器打印环境变量
tantianran@test-b-k8s-master:~/goweb-demo$ kubectl exec -it test-env-demo -c test-env-demo-container -- bash
root@test-env-demo:/opt/goweb-demo# echo $SAVE_TIME # 单独打印一个
60
root@test-env-demo:/opt/goweb-demo# env # 执行env命令查看
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_PORT=443
HOSTNAME=test-env-demo
PWD=/opt/goweb-demo
DNS_ADDR=8.8.8.8
HOME=/root
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
MAX_CONN=1024
GOLANG_VERSION=1.19.4
TERM=xterm
SHLVL=1
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
SAVE_TIME=60
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PORT=443
PATH=/go/bin:/usr/local/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
GOPATH=/go
_=/usr/bin/env
root@test-env-demo:/opt/goweb-demo#
再来个小例子，直接取pod的属性作为变量的值，下面的例子是拿到pod所处的节点名称
apiVersion: v1
kind: Pod
metadata:
name: test-env-demo
spec:
containers:
- name: test-env-demo-container
image: 192.168.11.247/web-demo/goweb-demo:20221229v3
env:
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
打印变量
tantianran@test-b-k8s-master:~$ kubectl exec test-env-demo -- printenv
PATH=/go/bin:/usr/local/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=test-env-demo
NODE_NAME=test-b-k8s-node02 # NODE_NAME变量，值为test-b-k8s-node02
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
GOLANG_VERSION=1.19.4
GOPATH=/go
HOME=/root
再来最后一个例子，使用容器字段作为环境变量的值，这个例子设置了资源限制的字段requests和limits，在设置环境变量中，使用资源限制的值作为了变量的值。
apiVersion: v1
kind: Pod
metadata:
name: test-env-demo
spec:
containers:
- name: test-env-demo-container
image: 192.168.11.247/web-demo/goweb-demo:20221229v3
resources:
requests:
memory: "32Mi"
cpu: "125m"
limits:
memory: "64Mi"
cpu: "250m"
env:
- name: CPU_REQUEST
valueFrom:
resourceFieldRef:
containerName: test-env-demo-container
resource: requests.cpu
- name: CPU_LIMIT
valueFrom:
resourceFieldRef:
containerName: test-env-demo-container
resource: limits.cpu
- name: MEM_REQUEST
valueFrom:
resourceFieldRef:
containerName: test-env-demo-container
resource: requests.memory
- name: MEM_LIMIT
valueFrom:
resourceFieldRef:
containerName: test-env-demo-container
resource: limits.memory
打印变量
tantianran@test-b-k8s-master:~$ kubectl exec test-env-demo -- printenv
PATH=/go/bin:/usr/local/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=test-env-demo
MEM_REQUEST=33554432
MEM_LIMIT=67108864
CPU_REQUEST=1
CPU_LIMIT=1
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT=443
GOLANG_VERSION=1.19.4
GOPATH=/go
HOME=/root
初始化容器的特点：
在实际工作中，可利用它的这种工作机制应对某些场景，比如在应用容器启动之前，需要做一些初始化相关的工作，比如初始化配置文件，测试IP或端口的连通性等等场景。
下面来个小例子，场景是这样的，我的应用容器是goweb-demo，初始化容器是init-check-mysql-ip，假设应用容器是依赖数据库的，如果数据库没起来，那么应用容器就算起来了也是服务不可用。所以，现在的主要目的是想在应用容器启动之前检查mysql服务器的IP地址是否可ping通，如果是通的才启动应用容器。这个例子应该是比较贴近实际场景了。下面，看我写好的yaml：
apiVersion: v1
kind: Namespace
metadata:
name: test-a
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: goweb-demo
namespace: test-a
spec:
replicas: 3
selector:
matchLabels:
app: goweb-demo
template:
metadata:
labels:
app: goweb-demo
spec:
containers:
- name: goweb-demo
image: 192.168.11.247/web-demo/goweb-demo:20221229v3
initContainers:
- name: init-check-mysql-ip
image: 192.168.11.247/os/busybox:latest
command: ['sh', '-c', "ping 192.168.11.248 -c 5"]
---
apiVersion: v1
kind: Service
metadata:
name: goweb-demo
namespace: test-a
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8090
selector:
app: goweb-demo
type: NodePort
mysql服务器故意没拉起，看看效果：
tantianran@test-b-k8s-master:~/goweb-demo$ kubectl get pods -n test-a
NAME READY STATUS RESTARTS AGE
goweb-demo-859cc77bd5-jpcfs 0/1 Init:0/1 2 (18s ago) 48s
goweb-demo-859cc77bd5-n8hqd 0/1 Init:0/1 2 (17s ago) 48s
goweb-demo-859cc77bd5-sns67 0/1 Init:0/1 2 (17s ago) 48s
tantianran@test-b-k8s-master:~/goweb-demo$
tantianran@test-b-k8s-master:~/goweb-demo$ kubectl get pods -n test-a
NAME READY STATUS RESTARTS AGE
goweb-demo-859cc77bd5-jpcfs 0/1 Init:Error 4 (67s ago) 2m44s
goweb-demo-859cc77bd5-n8hqd 0/1 Init:Error 4 (66s ago) 2m44s
goweb-demo-859cc77bd5-sns67 0/1 Init:Error 4 (67s ago) 2m44s
tantianran@test-b-k8s-master:~/goweb-demo$
tantianran@test-b-k8s-master:~/goweb-demo$ kubectl get pods -n test-a
NAME READY STATUS RESTARTS AGE
goweb-demo-859cc77bd5-jpcfs 0/1 Init:CrashLoopBackOff 3 (34s ago) 2m11s
goweb-demo-859cc77bd5-n8hqd 0/1 Init:CrashLoopBackOff 3 (33s ago) 2m11s
goweb-demo-859cc77bd5-sns67 0/1 Init:CrashLoopBackOff 3 (34s ago) 2m11s
tantianran@test-b-k8s-master:~/goweb-demo$
观察STATUS字段发现，它经历了3个阶段，第一阶段是正常的运行，也就是执行ping检查的操作，因为死活Ping不同，所以进入了第二阶段，状态为Error。紧接着是第三阶段，状态变成了CrashLoopBackOff，对于这个状态，我的理解是，初始化容器运行失败了，准备再次运行。总而言之，如果Mysql服务器的IP死活ping不通，它就会的状态就会一直这样：运行->Error->CrashLoopBackOff。当然这种情况是当Pod对应的restartPolicy为"Always"（这是默认策略）才会这样不断的循环检查，如果Pod对应的restartPolicy值为"Never"，并且Pod的 Init容器失败，则Kubernetes会将整个Pod状态设置为失败。
当我把mysql服务器启动后，初始化容器执行成功，那么应用容器也就成功起来了：
tantianran@test-b-k8s-master:~/goweb-demo$ kubectl get pods -n test-a
NAME READY STATUS RESTARTS AGE
goweb-demo-859cc77bd5-jpcfs 1/1 Running 0 30m
goweb-demo-859cc77bd5-n8hqd 1/1 Running 0 30m
goweb-demo-859cc77bd5-sns67 1/1 Running 0 30m
tantianran@test-b-k8s-master:~/goweb-demo$
在实际工作中，静态Pod的应用场景是毕竟少的，几乎没有。不过也还是得对它做一个简单的了解。静态Pod在指定的节点上由 kubelet 守护进程直接管理，不需要 API 服务器监管。 与由控制面管理的 Pod（例如，Deployment） 不同；kubelet 监视每个静态 Pod（在它失败之后重新启动），静态 Pod 始终都会绑定到特定节点的 Kubelet上。
在每个node节点上，kubelet的守护进程会自动在/etc/kubernetes/manifests/路径下发现yaml，因此，如果想要创建静态Pod，就得把yaml放到该目录，下面我们直接实战一下。
随便登录到某台node节点，然后创建/etc/kubernetes/manifests/static_pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-static-pod
spec:
containers:
- name: test-container
image: 192.168.11.247/web-demo/goweb-demo:20221229v3
创建后，回到master节点上查看pod
tantianran@test-b-k8s-master:~$ kubectl get pod
NAME READY STATUS RESTARTS AGE
test-static-pod-test-b-k8s-node01 1/1 Running 0 11s
通过上面的输出结果可以看到，该静态pod已经在节点test-b-k8s-node01上面正常运行了，说明kubelet守护进程已经自动发现并创建了它。你可能会问，它不是不需要API服务器监管吗？为啥在master节点能看到它？因为kubelet 会尝试通过 Kubernetes API服务器为每个静态Pod自动创建一个镜像Pod，这意味着节点上运行的静态Pod对API服务来说是可见的，但是不能通过API服务器来控制。 且Pod名称将把以连字符开头的节点主机名作为后缀。
本文转载于（喜欢的盆友关注我们）：https://mp.weixin.qq.com/s/5Kv7DU34_Ae5y17MAQVO-Q
页面更新：2024-03-18
本站资料均由网友自行发布提供，仅用于学习交流。如有版权问题，请与我联系，QQ：4156828
© CopyRight 2020-2024 All Rights Reserved. Powered By 71396.com 闽ICP备11008920号-4
闽公网安备35020302034903号
