深入理解Pod对象

深入理解Pod对象

深入理解Pod对象

POD的基本概念

什么是POD

Pod是Kubernetes中最小的单元，它由一组、一个或多个容器组成 每个Pod还包含了一个Pause容器，Pause容器是Pod的父容器，主要负责僵尸进程的回收管理 通过Pause容器可以使同一个Pod里面的多个容器共享存储、网络、PID、IPC等。 Pod支持横向扩展和复制 Pod的生命周期是短暂的, 用后即焚的实体 注意: 重启Pod中的容器和重启Pod不是一回事 Pod只提供容器的运行环境并保持容器的运行状态, 重启容器不会造成Pod重启 Pod不会自愈, 如果Pod运行的Node故障, 或者是调度器本身故障, 这个Pod就会被删除 控制器(Deployment)可以自动创建和管理多个Pod, 提供副本管理, 滚动升级和集群级别的自愈能力

Pod实现机制与设计模式

Pod本身是一个逻辑概念，没有具体存在，那究竟是怎么实现的呢？

众所周知，容器之间是通过Namespace隔离的，Pod要想解决上述应用场景，那么就要让Pod里的容器之间高效共享。

具体分为两个部分：网络和存储

共享网络

kubernetes的解法是这样的：会在每个Pod里先启动一个infra container小容器，然后让其他的容器连接进来这个网络命名空间，然后其他容器看到的网络试图就完全一样了，即网络设备、IP地址、Mac地址等，这就是解决网络共享问题。在Pod的IP地址就是infra container的IP地址。

共享存储

比如有两个容器，一个是nginx，另一个是普通的容器，普通容器要想访问nginx里的文件，就需要nginx容器将共享目录通过volume挂载出来，然后让普通容器挂载的这个volume，最后大家看到这个共享目录的内容一样。

例如：

# pod.yaml apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: write image: centos command: ["bash","-c","for i in {1..100};do echo $i >> /data/hello;sleep 1;done"] volumeMounts: - name: data mountPath: /data - name: read image: centos command: ["bash","-c","tail -f /data/hello"] volumeMounts: - name: data mountPath: /data volumes: - name: data emptyDir: {}

上述示例中有两个容器，write容器负责提供数据，read消费数据，通过数据卷将写入数据的目录和读取数据的目录都放到了该卷中，这样每个容器都能看到该目录。

验证：

kubectl apply -f pod.yaml kubectl logs my-pod -c read -f

在Pod中容器分为以下几个类型：

Infrastructure Container：基础容器，维护整个Pod网络空间，对用户不可见 InitContainers：初始化容器，先于业务容器开始执行，一般用于业务容器的初始化工作 Containers：业务容器，具体跑应用程序的镜像

Pod的生命周期

Pod对象自从其创建开始至终止退出的时间范围称为其生命周期 在这段时间中, Pod会处于多种不同的状态, 并执行一些操作 创建主容器(main container) 为必须的操作 其他可选的操作还包括 初始化容器init container 容器启动后钩子post start hook 启动状态检测StartupProbe：便于用户使用同livenessProbe不同参数或阈值； 容器的存活性探测liveness probe：周期性检测，检测未通过时，kubelet会根据restartPolicy的定义来决定是否会重启该容器；未定义时，Kubelet认为只容器未终止，即为健康； 容器就绪性探测readiness probe：周期性检测，检测未通过时，与该Pod关联的Service，会将该Pod从Service的后端可用端点列表中删除；直接再次就绪，重新添加回来。未定义时，只要容器未终止，即为就绪； 容器终止前钩子pre stop hook 上述操作是否执行取决于Pod的定义

pod的探针：

StartupProbe：k8s1.16版本后新加的探测方式，用于判断容器内应用程序是否已经启动。如果配置了startupProbe，就会先禁止其他的探测，直到它成功为止，成功后将不在进行探测。 LivenessProbe：周期性检测，检测未通过时，与该Pod关联的Service，会将该Pod从Service的后端可用端点列表中删除；直接再次就绪，重新添加回来。未定义时，只要容器未终止，即为就绪； ReadinessProbe：周期性检测，一般用于探测容器内的程序是否健康，它的返回值如果为success，那么就代表这个容器已经完成启动，并且程序已经是可以接受流量的状态。

镜像拉取策略

apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: java image: lizhenliang/java-demo imagePullPolicy: IfNotPresent

imagePullPolicy 字段有三个可选值：

IfNotPresent：默认值，镜像在宿主机上不存在时才拉取（镜像标签是指定版本时的默认选项） Always：每次创建 Pod 都会重新拉取一次镜像（镜像标签是latest的默认选项） Never： Pod 永远不会主动拉取这个镜像

如果拉取公开的镜像，直接按照上述示例即可，但要拉取私有的镜像，是必须认证镜像仓库才可以，即docker login，而在K8S集群中会有多个Node，显然这种方式是很不放方便的！为了解决这个问题，K8s 实现了自动拉取镜像的功能。 以secret方式保存到K8S中，然后传给kubelet。

apiVersion: v1 kind: Pod metadata: name: my-pod spec: imagePullSecrets: - name: myregistrykey containers: - name: java image: lizhenliang/java-demo imagePullPolicy: IfNotPresent

上述中名为 myregistrykey 的secret是由kubectl create secret docker-registry命令创建：

kubectl create secret docker-registry myregistrykey --docker-username=admin --docker-password=Harbor12345 --docker-email=admin@harbor.com --docker-server=192.168.31.70

docker-server: 指定docke仓库地址 docker-username: 指定docker仓库账号 docker-password: 指定docker仓库密码 docker-email: 指定邮件地址(选填)

POD的YAML清单

YAML内容解析

在K8S部署一个应用的YAML内容大致分为两部分：

控制器定义：定义控制器属性

被控制对象：Pod模板，定义容器属性

具体字段意义：

资源字段太多，记不住怎么办？

很多同学YAML不会写！主要原因还是用的少，里面都是由于各个资源组成，熟悉了每个资源应用，自然就会写了，但也不用等到熟悉各种资源，这里教你几个技巧，帮助快速上手。

用run命令生成部署模板 kubectl create deployment nginx --image=nginx:1.14 -o yaml --dry-run> my-deploy.yaml 用get命令将已有部署的应用yaml导出 kubectl get my-deploy/nginx -o=yaml --export > my-deploy.yaml 如果某个字段单词不记得了，可以通过explain查看更详细的帮助文档获得 kubectl explain pods.spec.containers

定义一个pod

apiVersion: v1 # 必选，API的版本号 kind: Pod # 必选，类型Pod metadata: # 必选，元数据 name: nginx # 必选，符合RFC 1035规范的Pod名称 namespace: default # 可选，Pod所在的命名空间，不指定默认为default，可以使用-n指定namespace labels: # 可选，标签选择器，一般用于过滤和区分Pod app: nginx role: frontend # 可以写多个 annotations: # 可选，注释列表，可以写多个 app: nginx spec: # 必选，用于定义容器的详细信息 initContainers: # 初始化容器，在容器启动之前执行的一些初始化操作 - command: - sh - -c - echo "I am InitContainer for init some configuration" image: busybox imagePullPolicy: IfNotPresent name: init-container containers: # 必选，容器列表 - name: nginx # 必选，符合RFC 1035规范的容器名称 image: nginx:latest # 必选，容器所用的镜像的地址 imagePullPolicy: Always # 可选，镜像拉取策略 command: # 可选，容器启动执行的命令 - nginx - -g - "daemon off;" workingDir: /usr/share/nginx/html # 可选，容器的工作目录 volumeMounts: # 可选，存储卷配置，可以配置多个 - name: webroot # 存储卷名称 mountPath: /usr/share/nginx/html # 挂载目录 readOnly: true # 只读 ports: # 可选，容器需要暴露的端口号列表 - name: # 端口名称 containerPort: 80 # 端口号 protocol: TCP # 端口协议，默认TCP env: # 可选，环境变量配置列表 - name: TZ # 变量名 value: Asia/Shanghai # 变量的值 - name: LANG value: en_US.utf8 resources: # 可选，资源限制和资源请求限制 limits: # 最大限制设置 cpu: 1000m #1核=1000m memory: 1024Mi requests: # 启动所需的资源 cpu: 100m memory: 512Mi startupProbe: # 可选，检测容器内进程是否完成启动。注意三种检查方式同时只能使用一种。 # httpGet检测方式，生产环境建议使用httpGet实现接口级健康检查，健康检查由应用程序提供。 path: /api/successStart # 检查路径 port: 80 readinessProbe: # 可选，健康检查。注意三种检查方式同时只能使用一种。 # httpGet检测方式，生产环境建议使用httpGet实现接口级健康检查，健康检查由应用程序提供。 path: / # 检查路径 port: 80 # 监控端口 livenessProbe: # 可选，健康检查 exec: # 执行容器命令检测方式 #command: #- cat #- /health # httpGet检测方式 path: /_health # 检查路径 port: 8080 # 检查的请求头 - name: end-user value: Jason tcpSocket: # 端口检测方式 port: 80 initialDelaySeconds: 60 # 初始化时间 timeoutSeconds: 2 # 超时时间 periodSeconds: 5 # 检测间隔 successThreshold: 1 # 检查成功为2次表示就绪 failureThreshold: 2 # 检测失败1次表示未就绪 lifecycle: postStart: # 容器创建完成后执行的指令, 可以是exec TCPSocket exec: command: - sh - -c - 'mkdir /data/ ' preStop: path: / port: 80 exec: command: - sh - -c - sleep 9 restartPolicy: Always # 可选，默认为Always,容器故障或者没有启动成功，那就自动重启该容器，Onfailure: 容器以不为0的状态终止，自动重启该容器, Never:无论何种状态，都不会重启 nodeSelector: # 可选，指定Node节点 region: subnet7 imagePullSecrets: # 可选，拉取镜像使用的secret，可以配置多个 - name: default-dockercfg-86258 hostNetwork: false # 可选，是否为主机模式，如是，会占用主机端口 volumes: # 共享存储卷列表 - name: webroot # 名称，与上述对应 emptyDir: {} # 挂载目录 hostPath: # 挂载本机目录 path: /etc/hosts

Pod的生命周期

Pod对象自从其创建开始至终止退出的时间范围称为其生命周期 在这段时间中, Pod会处于多种不同的状态, 并执行一些操作 创建主容器(main container) 为必须的操作 其他可选的操作还包括 初始化容器init container 容器启动后钩子post start hook 启动状态检测StartupProbe 容器的存活性探测liveness probe 容器就绪性探测readiness probe 容器终止前钩子pre stop hook： 上述操作是否执行取决于Pod的定义

在Pod中容器分为以下几个类型：

Infrastructure Container：基础容器，维护整个Pod网络空间，对用户不可见 InitContainers：初始化容器，先于业务容器开始执行，一般用于业务容器的初始化工作 Containers：业务容器，具体跑应用程序的镜像

初始化容器init container

先于主容器启动，有些比较重要的初始化操作，需要在主容器启动前启动。 一般情况下，在一个pod内，使用init container来进行特权操作，因为init container执行完就终止。 init container执行完对整个容器内的网络名称空间已经生效，然后init container退出，再运行主容器 主容器内核继承了init container的执行结果，但主容器不具有特权

init-container

apiVersion: v1 kind: Pod metadata: name: init-container-demo namespace: default spec: initContainers: - name: iptables-init image: ikubernetes/admin-box:latest imagePullPolicy: IfNotPresent command: ['/bin/sh','-c'] args: ['iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80'] securityContext: capabilities: add: - NET_ADMIN containers: - name: demo image: ikubernetes/demoapp:v1.0 imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80

post start hook和pre stop hook的作用

post start hook：容器创建完成后立即运行的钩子处理器，主要为容器启动后做一些简单初始化操作，只有启动成功了pod才能正常工作，处于running状态 pre stop hook：主进程结束前做一些清理操作，清理完成后pod才会成功终止

lifecycle-demo

apiVersion: v1 kind: Pod metadata: name: lifecycle-demo namespace: default spec: containers: - name: demo image: ikubernetes/demoapp:v1.0 imagePullPolicy: IfNotPresent securityContext: capabilities: add: - NET_ADMIN livenessProbe: httpGet: path: '/livez' port: 80 scheme: HTTP initialDelaySeconds: 5 lifecycle: postStart: exec: command: ['/bin/sh','-c','iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-ports 80'] preStop: exec: command: ['/bin/sh','-c','while killall python3; do sleep 1; done'] restartPolicy: Always

也支持三种探针

pod的三种探针：

spec: containers: - name: … image: … livenessProbe: exec