文章目录

一、基本了解
二、管理命令
三、yaml文件参数大全
四、创建pod的工作流程
五、资源共享机制
- 5.1 共享网络
- 5.2 共享存储
六、生命周期+重启策略+健康检查
七、环境变量
八、Init Containe初始化容器
九、静态Pod

一、基本了解

概念：

Pod是一个逻辑抽象概念，是K8s创建和管理的最小单元，一个Pod由一个容器或多个容器组成。
可以把Pod看成一个箱子，箱子里装的就是容器，每个箱子都是互相隔离的。

特点：

一个Pod可以理解为是一个应用实例，提供服务。
Pod中容器始终部署在一个Node上。
Pod中容器共享网络、存储资源。

主要用法：

运行单个容器：最常见的用法，在这种情况下，可以将Pod看做是单个容器的抽象封装。
运行多个容器：边车模式（Sidecar），通过在Pod中定义专门容器，来执行主业务容器需要的辅助工作，其好处是将辅助功能同主业务容器解耦，实现独立发布和能力重用。

应用场景：

日志收集
应用监控

二、管理命令

注意事项：

和kubectl create deployment 命令相比，kubectl run 【Pod名称】命令更加单一，就相当于只运行了一个容器，前者可以生成多个副本等多项功能，后者没有，一般用于测试，正式环境还是用的前者。

功能	命令
创建Pod	kubectl apply -f pod.yaml 或者 kubectl run nginx --image=nginx
查看Pod	kubectl get pods 或者 kubectl describe pod <Pod名称>
查看日志	kubectl logs <Pod名称> [-c CONTAINER] 或者 kubectl logs <Pod名称> [-c CONTAINER] -f
进入容器终端	kubectl exec -it <Pod名称> [-c CONTAINER] – bash
删除Pod	kubectl delete pod <Pod名称>
查看Pod里的所有容器	kubectl get pod 【Pod名称】 -o jsonpath=“{.spec[‘containers’,‘initContainers’][*].name}”

三、yaml文件参数大全

参数	释义	是否必选
version	版本号，例如v1	必选
kind	资源对象类型，例如pod、deployment、service	必选
metadata	元数据	必选
metadata.name	对象名称	必选
metadata.namespace	对象所属的命名空间，默认值为 default	必选
metadata.labels	自定义标签列表
metadata.annotation	自定义注解列表
Spec	Pod 中容器的详细定义	必选
spec.containers	容器列表	必选
spec.containers.name	容器名称	必选
spec.containers.image	镜像名称	必选
spec.containers.imagePullPolicy	镜像拉取策略，可选值Always、Never、IfNotPresent，默认为Always。 Always：表示每次都尝试重新拉取镜像。 IfNotPresent：表示若本地有该镜像，则使用本地的镜像，若本地不存在则拉取镜像。 Never：表示仅使用本地镜像。若存在以下设置，系统则将设置成默认设置imagePullPolicy=Always： 1、不设置 imagePullPolicy，也未指定镜像的tag。 2、不设置 imagePullPolicy，镜像tag为 latest。 3、启用了名为 AlwaysPulllmages 的准入控制器Admission Controller )
spec.containers.command	容器的启动命令列表。若不指定，则使用镜像打包时使用的启动命令。
spec.containers.args	容器的启动命令参数列表。
spec.containers.workingDir	容器的工作目录
spec.containers.volumeMounts	挂载到容器内部的存储卷配置
spec.containers.volumeMounts .name	引用在volumes部分定义的共享存储卷名称
spec.containers.volumeMounts.mountPath	挂载到容器内的绝对路径
spec.containers.volumeMounts.readOnly	设置是否为只读模式，默认为读写模式
spec.containers.ports	容器需要暴露的端口号列表
spec.containers.ports.name	端口名称
spec.containers.ports.containerPort	容器内部端口
spec.containers.ports.hostPort	暴露在宿主机上的端口，默认与containerPort相同，需要保证唯一性。
spec.containers.ports.protocol	端口协议，默认为TCP，支持 TCP、UDP、SCTP
spec.containers.env	容器运行前需设置的环境变量列表。
spec.containers.env.name	变量名称
spec.containers.env.value	变量值
spec.containersl.resources	资源限制和资源请求的设置配置，用于资源配额和资源限制功能。
spec.containers.resources.limits	资源限制值，允许容器内程序最大的使用资源。
spec.containers.resources.limits.cpu	CPU 限制，可以写m也可以写浮点数，例如0.5=500m，1=1000m
spec.containers.resources.limits.memory	内存限制，单位可以为 MiB、GiB 等
spec.containers.resources.requests	容器资源请求值。告诉k8s最小分配的资源，分配的节点必须能够满足requests指定的值。
spec.containers .resources.requests.cpu	CPU请求，可以写m也可以写浮点数，例如0.5=500m，1=1000m
spec.containers.resources.requests.memo	内存请求，单位可以为MiB、GiB 等。
spec.volumes	共享存储卷列表
spec.volumes.name	共享存储卷的名称。可以定义多个 Volume，每个 Volume的 name 保持唯一。容器定义部分的containers.volumeMounts.name 将引用该共享存储卷的名称。类型有: emptyDir、hostPath、secret、nfs、iscsi等等。
spec.volumes.emptyDir	类型为emptyDir 的存储卷。表示与 Pod 同生命周期的-个临时目录，其值为一个空对象:emptyDir:{}
spec.volumes .hostPath	类型为 hostPath的存储卷。表示 Pod 容器挂载的宿主机目录，通过volumes.hostPath.path 指定
spec.volumes.hostPath.path	Pod 容器挂载的宿主机目录
spec.volumes.secret	类型为secret的存储卷，表示挂载集群预定义的secret对象到容器内部
spec.volumes.configMap	类型为 configMap 的存储卷，表示挂载集群预定义的configMap对象到容器内部
spec.volumes.livenessProbe	健康检查配置项。当探测无响应几次之后，系统将自动重启该容器。可设值有：exec、httpGet 和 tcpSocket。对一个容器仅需设置一种健康检查方法
spec.volumes.livenessProbe.exec	健康检查方式之一，exec 方式
spec.volumes.livenessProbe.exec.command	exec 方式需要指定的命令或者脚本
spec.volumes.livenessProbe.httpGet	健康检查方式之一，httpGet方式。需指定 path、port
spec.volumes.livenessProbe.tcpSocket	健康检查方式之一，cpSocket 方式。
spec.volumes.livenessProbe.initialDelaySeconds	容器启动完成后首次探测的时间，单位为s
spec.volumes .livenessProbe.timeoutSeconds	健康检查的探测等待响应超时时间，单位为 s，默认值为 1s。若超过该超时时间设置，则将认为该容器不健康，会重启该容器。
spec.volumes .livenessProbe.periodSeconds	健康检查的定期探测时间，单位为 s，默认 10s 探测一次。
spec.restartPolicy	重启策略，可选值为Always、OnFailure，默认值为Always。 Always：Pod 一旦终止运行，则无论容器是如何终止的，kubelet 都将重启它。 OnFailure：只有 Pod 以非零退出码终止时kubelet 才会重启该容器。如果容器正常结束(退出码为 0)，则 kubelet 将不会重启它。 Never：Pod 终止后，kubelet 将退出码报告给Master，不会再重启该 Pod
spec.nodeSelector	节点标签，以 key:value 格式指定，Pod将被调度到具有这些Label的节点上。
spec.imagePullSecrets	pull 镜像时使用的 Secret 名称，以name:secretkey格式指定。
spec.hostNetwork	是否使用主机网络模式，默认值为 false。设置为true，表示容器使用宿主机网络，不再使用 Docker网桥。

四、创建pod的工作流程

基本了解：

Kubernetes基于list-watch机制的控制器架构，实现组件间交互的解耦。
其他组件监控自己负责的资源，当这些资源发生变化时，kube-apiserver会通知这些组件，这个过程类似于发布与订阅。

流程图：

流程解析：
创建一个Pod命令为：kubectl run pod1 --image=nginx，命令执行过程步骤如下：

kubectl向apiserver发送一个创建pod的请求，apiserver会将数据写到etcd（实线），etcd将接受数据情况反馈给apiserver（虚线）。
scheduler调度器订阅apiserver，当apiserver有新事件时scheduler会第一时间收到，此时会根据算法选择一个节点加入分配到k8s-node1节点，并将选择结果告诉给apiserver，apiserver会将数据写到etcd（实线），etcd将接受数据情况反馈给apiserver（虚线）。
k8s-node1节点上的kubelet收到apiserver分配到我这个节点的pod，kubelet调用docker api创建容器，汇报容器的状态。

注意事项：

从以上的流程中来看，缺少两个组件的使用。
kube-controller-manager # 负责一些控制器工作的，例如deployment
kube-proxy # 负载pod网络，例如service

情景模拟流程：

把apiserver 看成 “小卖铺老板”，etcd 看成 “仓库”，scheduler看成“送货员”，其他组件看成 “学生”。
当老板接到货物时，会先把货物放进仓库，仓库返回给老板结果。
送货员根据算法规则算出货物要配送到哪个节点，将结果告诉老板。
老板根据每个组件学生的订阅要求，发布货物给各个订阅学生。
学生接收到货物后找docker api获取生成任务，并把结果返回给老板。
老板把情况记录到仓库里。

五、资源共享机制

5.1 共享网络

共享网络：将业务容器网络加入到“负责网络的容器”实现网络共享。

yaml文件示例：
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: test
  name: pod-net-test 
namespace: default
spec:
  containers:
  - image: busybox 
    name: test
    command: ["/bin/sh","-c","sleep 12h"]
  - image: nginx
    name: web

1.先尝试运行一个Pod，导出查看yaml文件。

[root@k8s-master bck]# kubectl  run nginx --image=nginx --dry-run=client -o yaml > nginx.yaml
[root@k8s-master bck]# cat nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always

2.尝试运行创建一个deployemnt,，导出查看yaml文件。

[root@k8s-master bck]# kubectl  create deployment web --image=nginx --dry-run=client --replicas=3 -o yaml > deploymnet.yaml
[root@k8s-master bck]# cat deploymnet.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  strategy: {}
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}

3.对比两个命令导出的yaml文件，Pod为对象的内容就是以deployment为对象的最后一部分内容。
在这里插入图片描述
4.修改nginx.yaml文件内容，新增辅助容器busybox使其后台运行24小时不退出。

[root@k8s-master bck]# cat nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: nginx
spec:
  containers:
  - image: nginx    ##主容器。
    name: nginx
  - image: busybox   ##辅助容器。  
    name: bs
    command:
    - sleep
    - 24h

5.导入yaml文件，并查看Pod，其内部有两个容器就是nginx和busybox。

[root@k8s-master bck]# kubectl  apply  -f nginx.yaml

在这里插入图片描述
6.进入Pod验证。没有使用-c参数指定进入哪个容器，就会提示这行。当一个Pod中有多个容器时，不指定进入容器就默认进入主容器。

[root@k8s-master bck]# kubectl  exec -it nginx -- bash

在这里插入图片描述
7.进入主容器验证。

8.进入辅助容器验证。可以监听到nginx的80端口，但是查看不到Nginx进程，是因为nginx和busybox容器是通过加入了Infra Container网络容器，该容器通过共用网络协议栈，使busybox容器和nginx容器里实现网络共享。而端口是属于协议栈中的一部分能看到，进程不属于协议栈内容就看不到。
在这里插入图片描述
9.查看Infra Container网络容器位置。

5.2 共享存储

共享存储：容器通过数据卷共享数据。

1.通过yaml文件定义数据卷。

[root@k8s-master bck]# cat nginx2.yaml 
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: nginx2
spec:
  containers:
  - image: nginx      ##主容器。
    name: nginx
    volumeMounts:       ## 数据卷挂载
    - name: log         ## 指定挂载的数据卷名称
      mountPath: /data  ## 数据卷挂载到容器中的路径
  - image: busybox    ##辅助容器。 
    name: bs
    command:
    - sleep
    - 24h
    volumeMounts:       ## 数据卷挂载
    - name: log         ## 指定挂载的数据卷名称
      mountPath: /data  ## 数据卷挂载到容器中的路径
  volumes:              ##定义数据卷
  - name: log           ##数据卷名称
    emptyDir: {}        ##数据卷类型

在这里插入图片描述
2.导入yaml文件，查看pod。

[root@k8s-master bck]# kubectl  apply  -f nginx2.yaml

在这里插入图片描述
3.进入nginx容器创建123.txt文件，之后退出进入bs容器里可以看到123.txt文件；进入bs容器创建456.txt文件，之后退出进入bs容器里可以看到456.txt文件。

在这里插入图片描述

六、生命周期+重启策略+健康检查

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

重启策略：

Always：当容器终止退出后，总是重启容器，默认策略。
OnFailure：当容器异常退出（退出状态码非0）时，才重启容器。
Never：当容器终止退出，从不重启容器。

健康检查3种类型：

livenessProbe（存活检查）：判断容器是否存活（Running状态）。若检查失败，则将杀死容器，再根据Pod的容器策略来操作。
readinessProbe（就绪检查）：判断容器服务是否可用（Ready状态），达到Ready状态的Pod才可以接收请求。如果在运行过程中Ready状态变为False，则系统自动将其从Service的后端Endpoint列表中隔离出去，后续再把恢复到Ready状态的Pod加回后端Endpoint列表，这样就能保证客户端在访问Service时不会被转发到服务不可用的Pod实例上。
startupProbe（启动检查）：检查成功才由存活检查接手，用于保护慢启动容器。适用于应用启动较慢的情况，就绪检查就不适用了，需要用启动检查。

健康检查支持的3种检查方法：

httpget：通过容器的IP地址、端口号及路径调用HTTP Get方法，返回200-400范围状态码为成功。
exec：执行Shell命令返回状态码是0为成功。
tcpSocket：通过容器的IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器健康。

1.创建deployment时，加入健康检查策略。

[root@k8s-master bck]# cat qingjun.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: qingjun
  name: qingjun
spec:
  replicas: 3
  selector:
    matchLabels:
      app: qingjun
  template:
    metadata:
      labels:
        app: qingjun
    spec:
      containers:
      - image: nginx
        name: nginx
        livenessProbe:    # 存活检查，重启容器
          httpGet:
           path: /index.html     #检查网页文件
           port: 80
          initialDelaySeconds: 10  #启动容器后多少秒后进行第一次健康检查
          periodSeconds: 30        #以后每间隔多少秒检查一次
        readinessProbe:            # 就绪检查，从Service中剔除容器
          httpGet:
           path: /index.html
           port: 80
          initialDelaySeconds: 10
          periodSeconds: 30

2.导入yaml文件，并创建service。

[root@k8s-master bck]# kubectl  apply -f qingjun.yaml 
[root@k8s-master bck]# kubectl  expose deployment qingjun --port=80 --target-port=80 --type=NodePort

3.此时查看svc的地址，集群内的三个副本都能监听到。
在这里插入图片描述
4.删除一个副本容器里的网页文件。

5.此时再查看service监听状态，被删除网页文件的副本容器IP地址监听消失，该容器日志也显示报错异常。这是就绪检查起作用。

6.过一段时间，该容器又重新生成，日志恢复，前端文件恢复。这是存活检查在起作用。
在这里插入图片描述

七、环境变量

为什么会有环境变量的用法?

创建 Pod 时，可以为其下的容器设置环境变量。官网地址

应用场景：

容器内应用程序获取Pod信息。
容器内应用程序通过用户定义的变量改变默认行为。

变量值几种定义方式：

自定义变量值。
变量值从Pod属性获取。
变量值从Secret、ConfigMap挂载获取。

设置方式	可设置的参数	释义
fieldRef	metadata.name	Pod名称
	fieldRef	metadata.namespace
fieldRef	metadata.uid	Pod的UID，从Kubernetes 1.8.0-alpha.2版本开始支持。
fieldRef	metadata.labels[‘< KEY >’]	Pod某个Label的值，通过< KEY >进行引用，从Kubernetes 1.9版本开始支持。
fieldRef	metadata.annotations[‘< KEY >’]	Pod某个Annotation的值，通过< KEY >进行引用，从Kubernetes 1.9版本开始支持。
resourceFieldRef	Container级别的CPU Limit	容器的CPU限制值
resourceFieldRef	Container级别的CPU Request。	容器的CPU请求值
resourceFieldRef	Container级别的Memory Limit。	容器的内存限制值
resourceFieldRef	Container级别的Memory Request。	容器的内存请求值
resourceFieldRef	Container级别的临时存储空间（ephemeral-storage）Limit，从K8s 1.8.0-beta.0版本开始支持。
resourceFieldRef	Container级别的临时存储空间（ephemeral-storage）Request，从K8s 1.8.0-beta.0版本开始支持。
fieldRef字段	metadata.labels	Pod的Label列表，每个Label都以key为文件名，value为文件内容，每个Label各占一行。
fieldRef字段	metadata.namannotations	Pod的Annotation列表，每个Annotation都以key为文件名，value为文件内容，每个Annotation各占一行。
Pod元数据信息	status.podIP	Pod的IP地址
Pod元数据信息	spec.serviceAccountName	Pod使用的ServiceAccount名称。
Pod元数据信息	spec.nodeName	Pod所在Node的名称，从Kubernetes 1.4.0-alpha.3版本开始支持。
Pod元数据信息	status.hostIP	Pod所在Node的IP地址，从Kubernetes 1.7.0-alpha.1版本开始支持。

1.创建一个deployment，编辑yaml文件添加环境变量。

[root@k8s-master bck]# cat env.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: env
  name: env
spec:
  replicas: 3
  selector:
    matchLabels:
      app: qingjun
  template:
    metadata:
      labels:
        app: qingjun
    spec:
      containers:
      - image: nginx
        name: nginx
        env:
        - name: ABC
          value: "123"
        - name: MY_NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName     ##pod所在node节点的名称。
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name     ##pod名称。
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace     ##pod所在命名空间的名称。
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP          ##pod的IP地址。
        - name: MY_POD_SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              fieldPath: spec.serviceAccountName       ##pod使用sa的名称。

2.导入yaml文件，进入容器，查看容器内环境变量。
在这里插入图片描述

八、Init Containe初始化容器

定义：

Init Container初始化容器用于初始化工作，执行完就结束，可以理解为一次性任务。
初始化容器与应用容器本质上是一样的，但是仅运行一次就结束任务，并且必须在成功运行完成后，系统才能继续执行下一个容器。

特点：

支持大部分应用容器配置，但不支持健康检查。
运行方式与应用容器不同，优先应用容器执行。当有多个init container时，会按顺序逐个运行，并且只有前一个init container运行成功后才能运行后一个init container。在所有init container都成功运行后，K8s才会初始化Pod的各种信息，并开始创建和运行应用容器。

应用场景：

环境检查：例如确保应用容器依赖的服务启动后再启动应用容器。
初始化配置：例如给应用容器准备配置文件。

Pod内的容器类型：

Infrastructure Container：基础容器
维护整个Pod网络空间，镜像为pause。某节点上又多少个pause镜像容器，该节点上就有多少个pod。

InitContainers：初始化容器
先于业务容器开始执行

Containers：业务容器
并行启动

注意事项：

Pod重新启动时，init container将会重新运行。
情景一，init container的镜像被更新时，init container将会重新运行，导致Pod重启。仅更新应用容器的镜像只会使得应用容器被重启。
情景二，Pod的infrastructure容器更新时，Pod将会重启。
情景三，若Pod中的所有应用容器都终止了，并且RestartPolicy=Always，则Pod会重启。

也可以对init container设置资源限制、挂载卷和安全策略等。但资源限制的设置与应用容器略有不同。
若多个init container都定义了资源请求/资源限制，则取最大的值作为所有init container的资源请求值/资源限制值。
Pod的有效（effective）资源请求值/资源限制值取以下二者中的较大值：
所有应用容器的资源请求值/资源限制值之和。
initcontainer的有效资源请求值/资源限制值。

调度算法将基于Pod的有效资源请求值/资源限制值进行计算，也就是说init container可以为初始化操作预留系统资源，即使后续应用容器无须使用这些资源。
Pod的有效QoS等级适用于init container和应用容器。
资源配额和限制将根据Pod的有效资源请求值/资源限制值计算生效。
Pod级别的cgroup将基于Pod的有效资源请求/限制，与调度机制一致。

测试初始化容器下载一个前端文件到本地并挂载共享目录，主容器从共享目录里下载前端文件。

1.创建一个Pod，编辑yaml文件。

[root@k8s-master bck]# cat init.yaml 
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: init666
spec:
  ## 初始化容器
  initContainers:           ##定义初始化容器
  - image: busybox          ##容器镜像
    name: bs                ##容器名称
    command:                ##执行动作，下载访问aliang官网前端文件到/data/index.html，并共享/data目录。
    - wget
    - "-O"
    - "/data/index.html"
    - "https://www.aliangedu.cn"
    volumeMounts:       ## 数据卷挂载
    - name: log         ## 指定挂载的数据卷名称
      mountPath: /data  ## 数据卷挂载到容器中的路径
  ## 主容器
  containers:
  - image: nginx
    name: nginx
    volumeMounts:       ## 数据卷挂载
    - name: log         ## 指定挂载的数据卷名称
      mountPath: /usr/share/nginx/html/  ## 共享目录，此时该目录下也有下载的aliang官网前端文件。
  volumes: # 定义数据卷
  - name: log # 数据卷名称
    emptyDir: {} # 数据卷类型

2.导入yaml文件，查看Pod状态。先是运行初始化容器，再运行主容器。
在这里插入图片描述
3.进入容器内检查下载文件，验证成功。

九、静态Pod

为什么会有静态Pod?

只是一种使用kubeadm方式部署k8S集群的思路，和k8s集群没有直接关系，是分开的。
正常情况下，K8s集群搭建完成后才能创建Pod，而使用Kubeadm方式搭建集群时组件又需要使用Pod来启动，这时候就需要没有容器化的Kubelet来管理静态Pod，通过静态Pod拉起K8s组件，也就是master节点上/etc/kubernetes/manifests/目录下的yaml文件。

静态Pod的特点：

Pod由特定节点上的kubelet管理。
不能使用控制器，不能通过API Server进行管理，无法与ReplicationController、Deployment、DaemonSet进行关联，也无法对它们进行健康检查。
Pod名称标识当前节点名称

实现方式：

配置文件方式。在kubelet配置文件/var/lib/kubelet/config.yaml中设置参数staticPodPath，指定需要监控的配置文件所在目录，kubelet会定期扫描该目录，并根据该目录下的.yaml或.json文件进行创建操作。
HTTP方式。在kubelet配置文件中设置参数“–manifest-url”，kubelet将会定期从该URL地址下载Pod的定义文件，并以.yaml或.json文件的格式进行解析，然后创建Pod。

注意事项：

在kubelet配置文件启用静态Pod的参数：
vi /var/lib/kubelet/config.yaml
…
staticPodPath: /etc/kubernetes/manifests
…
将部署的pod yaml放到该目录会由kubelet自动创建。
业务层面上用不到静态Pod，都是从K8s集群层面上拉取Pod。