01 引言

至此，pod的相关知识已经讲解完了，下面是整理的脑图：

在这里插入图片描述

02 总结

下面是关于pod的文章详情总结：

2.1 定义与基本用法

pod定义的完整内容如下：

apiVersion: v1
kind: Pod
    metadata:
        name: string
        namespace: string
        labels:
        - name: string
        annotations:
        - name: string
spec:
    containers:
    - name: string
      image: string
      imagePullPolicy: [Always Never IfNotPresent] 
      command: [string]
      args: [string]
      workingDir: string
      volumeMounts: 
      - name: string
        mountPath: string
        readonly: boolean
      ports:
      - name: string
        containerPort: int
        hostPort: int
        protocol: string
      env:
      - name: string
      - value: string
      resources:
        limits:
          cpu: string
          memory: string
        requests:
          cpu: string
          memory: string
      livenessProbe:
        exec:
          command: [string]
        httpGet:
          path: string
          port: number
          host: string
          scheme: string
          httpHeaders:
          - name: string
            value: string
        tcpSocket:
            port: number
        initialDelaySeconds: 0 
        timeoutSeconds: 0
        periodSeconds: 0
        successThreshold: 0
        failureThreshold: 0
      securityContext:
        privileged: false
    restartPolicy: [Always | Never | OnFailure] 
    nodeselector: object
    imagePullSecrets:
    - name: string
    hostNetwork: false
    volumes:
    - name: string
      emptyDir: {}
      hostPath:
        path: string
      secret:
        secretName: string
        items:
        - key: string
          path: string
      configMap: 
      - name: string 
        items:
        - key: string
          path: string

属性含义：
在这里插入图片描述

2.2 容器共享volume

详情参考：《k8s教程（pod篇）-容器共享volume》

容器共享volume：同一个 Pod 中的多个容器能够共享Pod级别的存储卷 Volume。

举例：在 Pod 内包含两个容器（tomcat 和 busybox），在 Pod 级别设置 Volume “app-logs”，用于 tomcat 容器向其中写日志文件，busybox 容器从中读日志文件。

apiversion: v1
kind: Pod
metadata:
    name: volume-pod
spec:
    containers:
    - name: tomcat
      image: tomcat
      ports:
      - containerPort: 8080
      volumeMounts: 
      - name: app-logs
        mountPath: /usr/local/tomcat/logs
    - name: busybox
      image: busybox
      command: ["sh","-c","tail-f /logs/catalina*.log"] 
      volumeMounts:
      - name: app-logs
        mountPath: /logs
    volumes:
    - name: app-logs
      emptyDir: {}

这里设置的 Volume 名称为 app-logs，类型为 emptyDir（也可以设置为其他类型），挂载到 tomcat容器内的/usr/local/tomcat/logs目录下，同时挂载到busybox容器内的/logs目录下。

tomcat容器在启动后会向/usr/local/tomcat/logs目录写文件，busybox 容器就可以读取其中的文件了。

2.3 配置管理

详情参考：《k8s教程（pod篇）-配置管理》

Pod可以使用 ConfigMap进行配置管理，ConfigMap以一个或多个key:value的形式保存在Kubenetes系统中供应用使用，它既可以表示一个变量的值（例如： apploglevel=info），也可以用于表示一个完整的配置文件内容（例如：server.xml=<?xml...>）。

典型用法如下：

生成容器的环境变量；
设置容器启动命令的启动参数（需要设置为环境变量）；
以Volume的形式挂载为容器内部的文件或目录。

下面展示将两个配置文件（server.xml和logging.properties）定义为ConfigMap的用法，设置key为配置文件的别名，value则是配置文件的全部文本内容：

apiVersion: v1
kind: ConfigMap
metadata: 
name: cm-appconfigfiles 
data: 
    key-serverxml: |
        <?xml version='1.0'encoding='utf-8'?>
        .......此处省略内容
    key-loggingproperties: 
        "handlers=catalina.org.apache.juli ......此处省略内容"

接着使用kubectl命令创建该ConfigMap：

$ kubectl create -f cm-appconfigfiles.yaml 
configmap "cm-appconfigfiles" created

然在Pod "cm-test-app" 的定义中，将ConfigMap “cm-appconfigfiles”中的内容以文件的形式挂载到容器内部的/configfiles目录下，Pod配置文件cm-test-app.yaml的内容如下：

apiVersion: v1
kind: Pod
metadata:
    name: cm-test-app
spec:
    containers:
    - name: cm-test-app
      image: kubeguide/tomcat-app:v1
      ports:
      - containerPort: 8080
      volumeMounts: 
      - name: serverxml     #引用Volume的名称
        mountPath: /configfiles    #挂载到容器内的目录
    volumes:
    - name: serverxml    #定义Volume的名称
      configMap:
        name: cm-appconfigfiles    #使用ConfigMap"cm-appconfigfiles"
        items:
        - key: key-serverxml  # key=key-serverxml
          path: server.xml    #value将server.ml文件名进行挂载
        - key: key-loggingproperties # key=key-loggingproperties
          path: logging.properties  #value将logging,properties文件名进行挂载

创建完该Pod之后，登录容器，查看到在/configfiles目录下存在server.xml和logging.properties文件，他们的内容就是ConigMap “cm-appconfigfiles” 中两个key定义的内容：
在这里插入图片描述

2.4 容器获取pod信息（Downward API）

详情参考：《k8s教程（pod篇）-容器获取pod信息（Downward API）》

Downward API可以通过以下两种方式将Pod和容器的元数据信息注入容器内部:

环境变量：将Pod或Container信息设置为容器内的环境变量；
Volume挂载：将Pod或Container信息以文件的形式挂载到容器内部。

下面仅举例通过Downward API将Pod的 IP、名称和所在命名空间注入容器的环境变量中（通过Volume挂载的方式可以看原文）：

apiVersion: v1
kind: Pod
metadata: 
    name: dapi-envars-fieldref
spec:
    containers:
    - name: test-container
      image: busybox
      command: ["sh","-c"]
      args:
      - while true;do
            echo -en '\n';
            printenv MY NODE NAME MY POD NAME MY POD NAMESPACE; 
            printenv MY POD IP MY POD SERVICE ACCOUNT; 
            sleep 10; 
        done;
    env:
    - name: MY NODE NAME 
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName 
    - name: MY POD NAME 
      valueFrom:
        fieldRef:
          fieldPath: metadata.name 
    - name: MY POD NAMESPACE 
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace
    - name: MY POD IP 
      valueFrom:
        fieldRef:
          fieldPath: status.podIP 
    - name: MY POD SERVICE ACCOUNT 
      valueFrom:
        fieldRef:
          fieldPath: spec.serviceAccountName
    restartPolicy: Never

yaml设置的环境变量有：

spec.nodeName：Pod所在Node的名称；
metadata.name：Pod名称；
metadata.namespace：Pod所在命名空间的名称；
status.podIP：Pod的IP地址；
spec.serviceAccountName：Pod使用的ServiceAccount名称。

使用命令创建pod之后，进入容器，可以看到环境变量的配置了：
在这里插入图片描述

2.5 生命周期、重启策略及健康检查

详情参考：《k8s教程（pod篇）-生命周期、重启策略及健康检查》

Pod的生命周期：

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

Pod的重启策略：当某个容器异常退出或者健康检查失败时，kubelet将根据RestartPolicy的设置进行相应的操作，pod的重启策略包括Always、OnFailure和Never（默认值为Always）：

重启策略	描述
Always	当容器失效时，由kubelet自动重启该容器
OnFailure	当容器终止运行且退出码不为0时，由kubelet自动重启该容器
Never	不论容器运行状态如何，kubelet都不会重启该容器

Pod健康检查：Kubernetes对Pod的健康状态可以通过三类探针来检查：LivenessProbe、ReadinessProbe及StartupProbe，其中最主要的探针为LivenessProbe与ReadinessProbe，kubelet会定期执行这两类探针来诊断容器的健康状况。

探针	作用
LivenessProbe探针	用于判断容器是否存活(Running状态)，如果LivenessProbe探针探测到容器不健康，则kubelet“将“杀掉”该容器，并根据容器的重启策略做相应的处理。如果一个容器不包含LivenessProbe探针，那么kubelet认为该容器的LivenessProbe探针返回的值永远是Success
ReadinessProbe探针	用于判断容器服务是否可用(Ready状态)，达到Ready状态的Pod才可以接收请求。对于被Service管理的Pod、Service与PodEndpoint的关联关系也将基于Pod是否Ready进行设置。如果在运行过程中Ready 状态变为False，则系统自动将其从Service的后端Endpoint列表中隔离出去，后续再把恢复到Ready状态的Pod加回后端Endpoint列表。这样就能保证客户端在访问Service时不会被转发到服务不可用的Pod实例上。需要注意的是ReadinessProbe也是定期触发执行的，存在于Pod的整个生命周期中
StartupProbe探针	某些应用会遇到启动比较慢的情况，例如应用程序启动时需要与远程服务器建立网络连接，或者遇到网络访问较慢等情况时，会造成容器启动缓慢，此时ReadinessProbe就不适用了，因为这属于“有且仅有一次” 的超长延时，可以通过StartupProbe探针解决该问题

2.6 pod调度

详情参考：

之前已经写了总结了，可以参考：《k8s教程（pod篇）-调度总结》

2.7 初始化容器

详情参考：《k8s教程（pod篇）-初始化容器》

init container(初始化容器)，用于在启动应用容器（app container)之前启动一个或多个初始化容器，完成应用容器所需的预置条件。

下面以nginx应用为例，在启动nginx之前，通过初始化容器busybox，为nginx 创建一个index.html主页文件：

apiversion: v1
kind: Pod
metadata:
    name: nginx
    annotations:
spec:
    # These containers are run during pod initialization 
    initContainers:
    - name: install
      image: busybox
      command:
      - wget
      -"-o"
      -"/work-dir/index.html" 
      - http://kubernetes.io 
      volumeMounts:
      - name: workdir
        mountPath: "/work-dir"
    
    containers:
    - name: nginx
      image: nginx
      ports:
      - containerPort: 80
      volumeMounts:
      - name: workdir
        mountPath: /usr/share/nginx/html 
    dnsPolicy: Default
    
    volumes: 
    - name: workdir
      emptyDir: {}

创建完成后，在运行init container的过程中查看Pod的状态，可见init过程还未完成：

$ kubectl create -f nginx-init-containers.yaml 
pod "nginx"created

$ kubectl get pods
NAME    READY    STATUS        RESTARTS    AGE
nginx    0/1        Init:0/1    0            1m

在init container成功运行完成后，系统继续启动Nginx容器，再次查看Pod的状态：

$ kubectl get pods
NAME    READY    STATUS    RESTARTS     AGE
nginx    1/1        Running    0        7s

查看Pod的事件，可以看到系统首先创建并运行init container容器（名为install)，成功后继续创建和运行Nginx容器。

2.8 升级与回滚

详情参考：《k8s教程（pod篇）-升级与回滚》

Pod的升级方式有两种：

通过kubectl set image命令为Deployment设置新的镜像名称
使用kubectl edit命令修改Deployment的配置，将 spec.template.spec.containers[0].image从nginx: 1.7.9更改为nginx:1.9.1

Pod的回滚方式：

撤销本次发布并回滚到上一个部署版本：

Pod暂停和恢复Deployment操作：

通过kubectl rollout pause命令暂停Deployment的更新操作:
修改完后，恢复这个Deployment的部署操作：

2.9 扩缩容

详情参考：《k8s教程（pod篇）-扩缩容》

Pod扩缩容分为两种：

手动扩缩容：例如通过kubectl scale命令可以将Pod副本数量从初始的3个更新为5个
自动扩缩容：使用HPA控制器，用于实现基于CPU使用率进行自动Pod扩缩容的功能，详情查看《k8s教程（pod篇）-扩缩容》。

2.10 使用StatefulSet搭建MongoDB集群

详情参考：《k8s教程（pod篇）-使用StatefulSet搭建MongoDB集群》

原理图如下：
在这里插入图片描述
为了完成MongoDB集群的搭建，需要部署以下三个资源对象，分别为：

StorageClass：用于StatefulSet自动为各个应用Pod申请PVC；
Headless Service：用于设置MongoDB实例的域名；
StatefulSet

详情查看原文：《k8s教程（pod篇）-使用StatefulSet搭建MongoDB集群》

03 文末

本文主要总结了前段时间对k8s pod的知识点整理，希望能帮助到大家，谢谢大家的阅读，本文完！

k8s pod 超详细总结

01 引言

02 总结

2.1 定义与基本用法

2.2 容器共享volume

2.3 配置管理

2.4 容器获取pod信息（Downward API）

2.5 生命周期、重启策略及健康检查

2.6 pod调度

2.7 初始化容器

2.8 升级与回滚

2.9 扩缩容

2.10 使用StatefulSet搭建MongoDB集群

03 文末

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像