k8s - Pod资源解读

可以通过 kubectl explain 查看资源清单包含了那些字段kubectl explain Pod可以通过提供的More info 网页查看具体的配置样例apiVersion 定义了对象版本Kind 定义了资源类型matadata 定义了元属性信息spec 定义了Pod的规格，具体容器信息status 定义了状态，不可修改，不需要定义。查看matadata对象该如何定义kubectl ex

王小栋857

800人浏览 · 2022-03-07 17:00:23

王小栋857 · 2022-03-07 17:00:23 发布

yaml 编写

可以通过 kubectl explain 查看资源清单包含了那些字段

kubectl explain Pod

可以通过提供的More info 网页查看具体的配置样例

apiVersion 定义了对象版本

Kind 定义了资源类型

matadata 定义了元属性信息 <资源名称>

spec 定义了Pod的规格，具体容器信息

status 定义了状态，不可修改，不需要定义。

查看matadata对象该如何定义

kubectl explain Pod.metadata

查看对象该如何定义直接在后面.+对象名即可。

字段类型为 <string> 字符串

apiVersion: v1

字段类型为 <Object> 对象

metadata:

字段类型为 <map[string]string> map集合

key: value

字段类型为 <[]Object> 对象列表

- name: tomcat-pod-java

带有required 为必填

常见属性：

metadate:

labels 创建资源具有的标签
namespace 资源所属命名空间（默认default）

spec:

activeDeadlineSeconds pod可运行的最长时间
affinity pod亲和性
containers 定义容器必填字段,至少要有一个容器
dnsConfig
dnsPolicy

pod.spec.containers

args
command
env
envFrom
image 用来指定容器需要的镜像
imagePullPolicy 镜像拉取策略，Always 一直重新拉取、Never 从不拉取镜像、IfNotPresent优先使用本地镜像，没有在拉取镜像。
name 必须字段指定pod中容器的名字
ports 端口

pod.spec.containers.ports

containerPort 必须字段，端口号
hostIP 将容器中的服务暴露到宿主机的端口上时，可以指定绑定的宿主机 IP
hostPort 容器中的服务在宿主机上映射的端口
name 端口名称

样例：

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod1
  labels:
    app: myapp
spec:
  containers:
  - name:  tomcat-pod-java
    ports:
    - containerPort: 8080
    image: tomcat

命名空间

k8s中物理集群中的虚拟集群。可以给不同用户、租户、环境或项目创建对应的命名空间。

命名空间的名称仅能是字母、数字、下划线、连接线等字符组成。

命名空间通过资源配额可以限制资源。

删除命名空间，级联下的资源对象也会被删除。

# 创建命名空间
kubectl create namespace test
# 切换当前命名空间。切换命名空间后，kubectl get pods 如果不指定-n，查看的就是test命名空间的资源了。
kubectl  config set-context --current --namespace=test
# 查看哪些资源属于命名空间级别的
kubectl api-resources --namespaced=true

资源限额

命名空间可以通过ResourceQuota限制空间资源

kubectl explain resourcequotas

apiVersion: v1
kind: ResourceQuota
metadata:
  name: test-rq
  # 指定名称空间
  namespace: test
spec:
  hard:
# 所有容器的内存请求总额不得超过
    requests.cpu: "1"
# 所有容器的CPU请求总额不得超过
    requests.memory: 1Gi
# 所有容器的内存限额总额不得超过
    limits.cpu: "2"
# 所有容器的CPU限额总额不得超过
    limits.memory: 2Gi

名称空间下的每个容器必须设置内存请求（memory request），内存限额（memory limit），cpu请求（cpu request）和cpu限额（cpu limit）。

查看限额

kubectl get quota -n test

# 查看pods 标签，其他资源也可以用--show-labels查看标签
kubectl get pods --show-labels
# 对已经存在的pod打标签
kubectl label pod pod名称  key=value

# 列出默认命名空间下所有标签 key=app,不显示标签
kubectl get pods -l app
# 列出默认命名空间下所有标签 key是app,value是myapp 不显示标签
kubectl get pods -l app=myapp
# 列出默认名称空间下标签key是app的所有pod，并打印对应的标签值
kubectl get pods -L app
# 查看所有名称空间下的所有pod的标签
kubectl get pods --all-namespace --show-labels

node节点选择器

我们创建pod资源的时候，pod会根据schduler进行调度，那么默认会调度到随机的一个工作节点，如果我们想要pod调度到指定节点或调度到一些具有相同特点的node节点可以使用pod中的nodeName或nodeSelector字段指定调度到的节点

nodeName

kubectl explain pod.spec

通过nodeName 可以直接指定调度到那个节点

样例：

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod1
  labels:
    app: myapp
spec:
  nodeName: k8snode02
  containers:
  - name: tomcat-pod-java
    ports:
    - containerPort: 8080
    image: tomcat

nodeSelector

通过node节点标签选择器，进行调度

样例：

# 节点打标签
kubectl label node k8snode01 dome=test
# dome yaml文件
apiVersion: v1
kind: Pod
metadata:
  name: demo-pod1
  labels:
    app: myapp
spec:
  nodeSelector:
    dome: test
  containers:
  - name: tomcat-pod-java
    ports:
    - containerPort: 8080
    image: tomcat

污点和容忍度

亲和性（affinity）

kubectl explain pod.spec.affinity

node节点亲和性（nodeAffinity）

Node节点亲和性针对的是pod和node的关系，Pod调度到node节点的时候匹配的条件

preferredDuringSchedulingIgnoredDuringExecution （软亲和性）

requiredDuringSchedulingIgnoredDuringExecution （硬亲和性，必须满足）

查看文档可以获得填写规则

kubectl explain pod.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchExpressions

填写筛选条件 values 可以设置多个满足其中一个即可。

样例：根据节点标签dome=test完成调度

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod1
  labels:
    app: myapp
spec:
  containers:
  - name: tomcat-pod-java
    ports:
    - containerPort: 8080
    image: tomcat
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: dome
            operator: In
            values:
            - test
            - dev

Pod节点亲和性

kubectl explain pod.spec.affinity

pod 自身亲和性调度有两种表现形式

podAffinity （pod亲和性）

podAntiAffinity （pod反亲和性）

使用pod亲和性必须添加位置拓扑键 topologyKey，完成调度的参照。

样例：

节点亲和性

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
  labels:
    dome: aff
spec:
  containers:
  - name: tomcat-pod
    ports:
    - containerPort: 8080
    image: tomcat
  affinity:
    # 节点亲和性
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      # 列表字段有同级属性时，子属性多缩进两个空格
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - myapp
        # 位置拓扑键参照主机名调度
        topologyKey: kubernetes.io/hostname

节点反亲和性：

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod2
  labels:
    dome2: noaff
spec:
  containers:
  - name: tomcat-pod2
    ports:
    - containerPort: 8080
    image: tomcat
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - myapp
        topologyKey: kubernetes.io/hostname

污点

给节点选择的主动权，我们给节点打个污点，不能容忍的pod就运行不上来。

污点是定义在节点上的键值属性数据。taints是键值对数据。

污点等级

NoSchedule (仅影响pod调度，后来的pod不容忍这个污点无法调度到该节点，已存在的pod不受影响)
NoExecute(既影响现有pod也影响pod调度，节点中现有pod会被剔除)
PreferNoSchedule （最好不也可以是NoSchedule的柔性版本）

# 查看污点 
kubectl describe nodes |grep Taints
# 给节点打污点
kubectl taint nodes 节点名 key=value:NoSchedule
# 删除污点
kubectl taint nodes 节点名 key-

污点容忍

kubectl explain pod.spec.tolerations

如果 operator 的值是 Exists，则 value 属性可省略
如果 operator 的值是 Equal，则表示其 key 与 value 之间的关系是 equal(等于)
如果不指定 operator 属性，则默认值为 Equal
另外，还有两个特殊值：

空的 key 如果再配合 Exists 就能匹配所有的 key 与 value，也是是能容忍所有 node 的所有 Taints
空的 effect 匹配所有的 effect

样例：

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod1
  labels:
    app: myapp
spec:
  containers:
  - name: tomcat-pod-java
    ports:
    - containerPort: 8080
    image: tomcat
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: dome
            operator: In
            values:
            - test
  tolerations:
  - key: "taint"
    operator: "Equal"
    value: "node02"
    effect: "NoSchedule"

pod常见状态

pod的status简述了其生命周期的阶段。

挂起（pending）: pod创建时调度条件不满足，多会处于此状态。

运行中（running）: pod正常运行。

成功（succeeded）: pod成功运行结束，并且不在重启

失败（failed): pod中容器异常终止，或者说容器以非0状态推出

未知(unknown):未知状态，pod所在节点kubelet故障未上报pod信息，

Evicted: 这种状态多见系统内存不足

CrashLoopBackOff: 容器启动又异常退出，重启次数过多也会出现此状态

Error 状态：Pod 启动过程中发生了错误

ready 代表pod的容器状态

问题排查命令

查看pod详情

kubectl describe pod pod名称（如果不是默认空间需要指定空间名）

查看pod容器日志

kubectl logs test-host -c test-host

pod 重启策略

pod重启策略（RestartPolicy）应用于pod内的所有容器，pod所在的node上的kubelet会进行判断和重启操作。某个容器异常推出或健康检测失败会。kubelet会根据重启策略进行操作

pod的重启策略包括： Always、OnFailure、Never 默认是Always

Always：当容器失败时，由kubelet自动重启该容器。

OnFailure：当容器终止运行且退出码不为0时，由kubelet自动重启该容器。

Never：不论容器运行状态如何，kubelet都不会重启该容器。

示例：

apiVersion: v1
kind: Pod
metadata:
  name: test2
spec:
  restartPolicy: Never
  containers:
  - name: test2
    image: nginx

生命周期

init容器

pod中可以定义多个容器，部署应用的容器称为主容器。pod创建时可以有一个或多个先于主容器启动的init容器，init容器中的程序执行完了才会运行主容器，由于pod中共享存储，多用于主容器启动前的一些初始化工作

init容器与主容器区别：

1 init容器运行完，主容器才会启动。

2 每个init容器必须运行成功，才可以执行下一个init容器

3 如果init容器运行失败，pod会不断重启，知道运行成功，如果重启策略设置为Never，他不会重启

示例：

apiVersion: v1
kind: Pod
metadata:
  name: init-test
spec:
  initContainers:
  - name: init-con
    image: centos
    command: ["sh", "-c", "echo '123' > /temdir/123"]
    volumeMounts:
    - mountPath: "/temdir"
      name: vol
  containers:
  - name: zhu-con
    image: centos
    command: ["sh", "-c", "cat /temdir/123 && sleep 3600"]
    volumeMounts:
    - mountPath: "/temdir"
      name: vol
  volumes:
  - name: vol
    emptyDir: {}

容器探测

容器钩子

初始化容器启动之后，开始启动主容器，在主容器启动之前有一个post start hook（容器启动后钩子）和pre stop hook（容器结束前钩子），无论启动后还是结束前所做的事我们可以把它放两个钩子，这个钩子就表示用户可以用它来钩住一些命令，来执行它，做开场前的预设，结束前的清理，如awk有begin，end，和这个效果类似；

postStart：该钩子在容器被创建后立刻触发，通知容器它已经被创建。如果该钩子对应的hook handler执行失败，则该容器会被杀死，并根据该容器的重启策略决定是否要重启该容器，这个钩子不需要传递任何参数。

preStop：该钩子在容器被删除前触发，其所对应的hook handler必须在删除该容器的请求发送给Docker daemon之前完成。在该钩子对应的hook handler完成后不论执行的结果如何，Docker daemon会发送一个SGTERN信号量给Docker daemon来删除该容器，这个钩子不需要传递任何参数。

在k8s中支持两类对pod的检测，第一类叫做livenessprobe（pod存活性探测）：

存活探针主要作用是，用指定的方式检测pod中的容器应用是否正常运行，如果检测失败，则认为容器不健康，那么Kubelet将根据Pod中设置的 restartPolicy来判断Pod 是否要进行重启操作，如果容器配置中没有配置 livenessProbe，Kubelet 将认为存活探针探测一直为成功状态。

第二类是状态检readinessprobe（pod就绪性探测）：用于判断容器中应用是否启动完成，当探测成功后才使Pod对外提供网络访问，设置容器Ready状态为true，如果探测失败，则设置容器的Ready状态为false。

postStart：容器创建成功后，运行前的任务，用于资源部署、环境准备等。

preStop：在容器被终止前的任务，用于优雅关闭应用程序、通知其他系统等。

lifecycle

......
containers:
- image: sample:v2  
     name: war
     lifecycle：
      postStart:
       exec:
         command:
          - “cp”
          - “/sample.war”
          - “/app”
      prestop:
       httpGet:
        host: monitor.com
        path: /waring
        port: 8080
        scheme: HTTP
......

而在容器终止之前，发送HTTP警告请求到监控系统。

优雅的删除资源对象

当用户请求删除含有pod的资源对象时（如RC、deployment等），K8S为了让应用程序优雅关闭（即让应用程序完成正在处理的请求后，再关闭软件），K8S提供两种信息通知：

1）、默认：K8S通知node执行docker stop命令，docker会先向容器中PID为1的进程发送系统信号SIGTERM，然后等待容器中的应用程序终止执行，如果等待时间达到设定的超时时间，或者默认超时时间（30s），会继续发送SIGKILL的系统信号强行kill掉进程。

2）、使用pod生命周期（利用PreStop回调函数），它执行在发送终止信号之前。默认情况下，所有的删除操作的优雅退出时间都在30秒以内。kubectl delete命令支持--grace-period=的选项，以运行用户来修改默认值。0表示删除立即执行，并且立即从API中删除pod。在节点上，被设置了立即结束的的pod，仍然会给一个很短的优雅退出时间段，才会开始被强制杀死。

    spec:
      containers:
      - name: nginx-demo
        image: centos:nginx
        lifecycle:
          preStop:
            exec:
              # nginx -s quit gracefully terminate while SIGTERM triggers a quick exit
              command: ["/usr/local/nginx/sbin/nginx","-s","quit"]
        ports:
          - name: http
            containerPort: 80

pod阶段

当用户创建pod时，这个请求给apiserver，apiserver把创建请求的状态保存在etcd中；接下来apiserver会请求scheduler来完成调度，如果调度成功，会把调度的结果（如调度到哪个节点上了，运行在哪个节点上了，把它更新到etcd的pod资源状态中）保存在etcd中，一旦存到etcd中并且完成更新以后，节点上的kubelet通过apiserver当中的状态变化知道有一些任务被执行了，所以此时此kubelet会拿到用户创建时所提交的清单，这个清单会在当前节点上运行或者启动这个pod，如果创建成功或者失败会有一个当前状态，当前这个状态会发给apiserver，apiserver在存到etcd中；在这个过程中，etcd和apiserver一直在打交道，不停的交互，scheduler也参与其中，负责调度pod到合适的node节点上，这个就是pod的创建过程。

pod探测

三种探测方法：

1、ExecAction：在容器中执行指定的命令，如果执行成功，退出码为 0 则探测成功。

2、TCPSocketAction：通过容器的 IP 地址和端口号执行 TCP 检查，如果能够建立 TCP 连接，则表明容器健康。

3、HTTPGetAction：通过容器的IP地址、端口号及路径调用 HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器健康

存活性探测livenessProbe

K8S提供livenessProbe来检测容器是否正常运行，许多应用程序经过长时间运行，最终过渡到无法运行的状态。这时候检测到容器异常，kubelet会根据重启策略重启容器。

示例：

Exec：

apiVersion: v1
kind: Pod
metadata:
  name: liveness
spec:
  containers:
  - image: centos
    name: test-liv
    command: ["sh", "-c", "touch /123 && sleep 120 && rm -rf /123 && sleep 600"]
    livenessProbe:
      initialDelaySeconds: 10
      periodSeconds: 5
      exec:
        command: ["sh", "-c", "cat /123"]


# #netstat -an|grep 80
# #echo $? 查看上面命令执行后的状态码



# 相关属性：
# initialDelaySeconds： Pod启动后首次进行检查的等待时间，单位“秒”。
# periodSeconds： 检查的间隔时间，默认为10s，单位“秒”。
# timeoutSeconds： 探针执行检测请求后，等待响应的超时时间，默认为1s，单位“秒”。
# successThreshold：连续探测几次成功，才认为探测成功，默认为 1，在 Liveness 探针中必须为1，最小值为1。
# failureThreshold： 探测失败的重试次数，重试一定次数后将认为失败，在 readiness 探针中，Pod会被标记为未就绪，默认为 3，最小值为

tcp

apiVersion: v1
kind: Pod
metadata:
  name: test-tcp
spec:
  containers:
  - name: test-tcp
    image: nginx
    # 存活性探测
    livenessProbe:
      # 容器启动多长时间后开始探测，默认是秒
      initialDelaySeconds: 10
      # 探测间隔时间，默认是秒
      periodSeconds: 5
      # 探测超时时间
      timeoutSeconds： 10
      # 探测端口
      tcpSocket:
        port: 80
        # host 默认是本机

#TCP 检查方式和 HTTP 检查方式非常相似，在容器启动 initialDelaySeconds 参数设定的时间后，kubelet将发送第一个 livenessProbe 探针，尝试连接容器的 80 端口，如果连接失败则将杀死 Pod 重启容器。

http

apiVersion: v1
kind: Pod
metadata:
  name: test-http
spec:
  containers:
  - name: test-http
    image: nginx
    livenessProbe:
      initialDelaySeconds: 10
      periodSeconds: 5
      httpGet:
        port: 80

# httpGet探测方式有如下可选的控制字段:
# scheme: 用于连接host的协议，默认为HTTP。
# host：要连接的主机名，默认为Pod IP，可以在http request head中设置host头部。
# port：容器上要访问端口号或名称。
# path：http服务器上的访问URI。
# httpHeaders：自定义HTTP请求headers，HTTP允许重复headers。

就绪性探测readinessProbe

没有配置就绪性探测，pod中容器运行后默认成功。

就绪性探测和存活性探测配置方法类似。

区别在于：

存活性探测失败后会由kubelet根据重启策略操作pod.

就绪性探测失败后会从EndPoint中移除。

存活性探测和就绪性探测配合使用案例：

apiVersion: v1
kind: Pod
metadata:
  name: test-live-read
spec:
  containers:
  - name: test-live-read
    image: nginx
    livenessProbe:
      initialDelaySeconds: 10
      periodSeconds: 5
      httpGet:
        port: 80
    readinessProbe:
      initialDelaySeconds: 10
      periodSeconds: 5
      httpGet:
        port: 80

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub