K8s核心组件pod:进阶篇

一、Pod 资源限制

在 Kubernetes 中，为了合理管理集群中的资源，容器的 CPU 和内存资源都可以设置请求值（requests）和限制值（limits）。这些设置确保了容器的资源分配和限制，避免资源争用和过度使用。

1.1 资源请求与限制（Request & Limit）

**请求（request）：**当容器启动时，Kubernetes 会根据容器的资源请求来决定容器应该调度到哪个节点上。这个值表示容器在运行时最少需要的资源。

**限制（limit）：**容器在运行时可以使用的最大资源量。如果容器超过了这个限制，Kubernetes 会采取措施来控制容器的资源使用，防止过度消耗。

复制代码

官网示例：
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources
container/

//Pod 和 容器 的资源请求和限制：
spec.containers[].resources.requests.cpu        //定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory     //定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu          //定义 cpu 的资源上限
spec.containers[].resources.limits.memory       //定义内存的资源上限

1.2 资源单位

1.2.1 CPU资源单位

在 Kubernetes 中，CPU 的单位表示方式如下：

● 1 CPU = 1 vCPU（或 1 核心超线程）

● CPU 请求和限制使用 "m"（毫核）作为单位。

例如：500m 表示半个 CPU，100m 表示 0.1 个 CPU，1 表示一个完整的 CPU。

● 带小数的 CPU 也是支持的，表示容器能获得的 CPU 时间片。例如， 0.25 表示该容器最多可以使用一个 CPU的四分之一。

1.2.2 内存资源单位

内存的单位有两种表示方式：

● 二进制单位：如 1Gi , 1Mi , 1Ki，分别为 1024Mi , 1024Ki 。Kubernetes 的内存限制通常使用

这些基于 2 的指数单位。

● 十进制单位：如 1GB , 1MB等，表示为以 10 为底的单位。

需要注意的是，在存储设备中，标示的单位（如GB）是基于十进制，而操作系统通常使用二进制单位（如GiB）。因此，1 GiB 的内存比 1 GB 多出大约 73MB。

官网链接：https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/

1.3 Pod案例

以下是两个常见的 Kubernetes Pod 配置示例，展示了如何为容器指定资源请求和限制：

示例：

python 复制代码

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"   # 最少 64Mi 内存
        cpu: "250m"      # 最少 0.25 CPU
      limits:
        memory: "128Mi"  # 最大 128Mi 内存
        cpu: "500m"      # 最大 0.5 CPU
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"   # 最少 64Mi 内存
        cpu: "250m"      # 最少 0.25 CPU
      limits:
        memory: "128Mi"  # 最大 128Mi 内存
        cpu: "500m"      # 最大 0.5 CPU

分析：

每个容器的 请求资源 是： 0.25 CPU 和 64Mi 内存。

每个容器的 限制资源 是： 0.5 CPU 和 128Mi 内存。

该 Pod 的 总请求资源 为 0.5 CPU 和 128Mi 内存。

该 Pod 的 总限制资源 为 1 CPU 和 256Mi 内存。

案列1：不同容器资源配置

复制代码

vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: web
  image: nginx
  env:
  - name: WEB_ROOT_PASSWORD
    value: "password"
    resources:
      requests:
        memory: "64Mi"   # 最少 64Mi 内存
        cpu: "250m"      # 最少 0.25 CPU
      limits:
        memory: "128Mi"  # 最大 128Mi 内存
        cpu: "500m"      # 最大 0.5 CPU
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "abc123"
    resources:
      requests:
        memory: "512Mi"  # 最少 512Mi 内存
        cpu: "0.5"       # 最少 0.5 CPU
      limits:
        memory: "1Gi"    # 最大 1Gi 内存
        cpu: "1"         # 最大 1 CPU
分析：
Web 容器：
请求：0.25 CPU 和 64Mi 内存
限制：0.5 CPU 和 128Mi 内存

DB 容器：
请求：0.5 CPU 和 512Mi 内存
限制：1 CPU 和 1Gi 内存

该 Pod 的总请求资源为：0.75 CPU 和 576Mi 内存
该 Pod 的总限制资源为：1.5 CPU 和 1.128Gi 内存

1.4 调度与资源分配

当 Kubernetes 调度 Pod 时，它会根据容器的资源请求（ requests ）来选择适合的节点。调度器会尝试确保节点有足够的资源来满足这些请求。如果节点上的资源不够，调度器会将 Pod 调度到其他可用节点。

Pod 调度实例：

复制代码

kubectl apply -f pod2.yaml
kubectl describe pod frontend

查看 Pod 分配资源情况：

复制代码

kubectl get pods -o wide

查看节点资源：

复制代码

kubectl describe nodes node02

二、探针（Probe）：健康检查

2.1 探针的三种规则

● livenessProbe ：判断容器是否正在运行。如果探测失败，则kubelet会杀死容器，并且容器将根据 restartPolicy 来设置 Pod 状态。如果容器不提供存活探针，则默认状态为Success。

● readinessProbe ：判断容器是否准备好接受请求。如果探测失败，端点控制器将从与 Pod 匹配的所有 service 址endpoints 中剔除删除该Pod的IP地。初始延迟之前的就绪状态默认Failure。如果容器不提供就绪探针，则默认状态为Success。

● startupProbe（这个1.17版本增加的）：判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。如果配置了 startupProbe 探测，在则在 startupProbe 状态为 Success 之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。如果 startupProbe 失败， kubelet 将杀死容器，容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe，则默认状态为 Success。

#注：以上规则可以同时定义。在readinessProbe检测成功之前，Pod的running状态是不会变成 ready状态的。

2.2 Pod的生命周期

**pending：**pod已经被系统认可了，但是内部的container还没有创建出来。这里包含调度到node上的时间以及下载镜像的时间，会持续一小段时间。

**Running：**pod已经与node绑定了（调度成功），而且pod中所有的container已经创建出来，至少有一个容器在运行中，或者容器的进程正在启动或者重启状态。--这里需要注意pod虽然已经Running 了，但是内部的container不一定完全可用。因此需要进一步检测container的状态。

**Succeeded：**这个状态很少出现，表明pod中的所有container已经成功的terminated了，而且不会再被拉起了。

**Failed：**pod中的所有容器都被terminated，至少一个container是非正常终止的。（退出的时候返回了一个非0的值或者是被系统直接终止）

**unknown：**由于某些原因pod的状态获取不到，有可能是由于通信问题。一般情况下pod最常见的就是前两种状态。而且当Running的时候，需要进一步关注container的状态。

注意： 阶段是 "宏观状态"，不代表容器的具体状态，比如 Running 阶段下，容器可能是启动中、运行中，甚至短暂重启。

2.3 Probe支持三种检查方法

● exec ：在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。

● tcpSocket ：对指定端口上的容器的IP地址进行TCP检查（三次握手）。如果端口打开，则诊断被认为是成功的。

● httpGet ：对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于 200且小于400，则诊断被认为是成功的。

每次探测都将获得以下三种结果之一：

成功：容器通过了诊断。

失败：容器未通过诊断。

未知：诊断失败，因此不会采取任何行动。

示例1：exec方式

复制代码

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/busybox:1.27.2
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 60
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      failureThreshold: 1
      initialDelaySeconds: 5
      periodSeconds: 5

#initialDelaySeconds：指定 kubelet 在执行第一次探测前应该等待5秒，即第一次探测是在容器启动
后的第6秒才开始执行。默认是 0 秒，最小值是 0。

#periodSeconds：指定了 kubelet 应该每 5 秒执行一次存活探测。默认是 10 秒。最小值是 1。

#failureThreshold: 当探测失败时，Kubernetes 将在放弃之前重试的次数。 存活探测情况下的放弃就
意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
#timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。（在 Kubernetes 1.20 
版本之前，exec 探针会忽略 timeoutSeconds 探针会无限期地 持续运行，甚至可能超过所配置的限期，
直到返回结果为止。）

可以看到 Pod 中只有一个容器。kubelet 在执行第一次探测前需要等待 5 秒，kubelet 会每 5 秒执行
一次存活探测。kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。如果命令执行成功并且返回
值为 0，kubelet 就会认为这个容器是健康存活的。 当到达第 31 秒时，这个命令返回非 0 值，
kubelet 会杀死这个容器并重新启动它

示例2：httpGet方式

复制代码

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3
在这个配置文件中，可以看到 Pod 也只有一个容器。initialDelaySeconds 字段告诉 kubelet 在执行
第一次探测前应该等待 3 秒。periodSeconds 字段指定了 kubelet 每隔 3 秒执行一次存活探测。
kubelet 会向容器内运行的服务（服务会监听 8080 端口）发送一个 HTTP GET 请求来执行探测。如果服
务器上 /healthz 路径下的处理程序返回成功代码，则 kubelet 认为容器是健康存活的。如果处理程序返
回失败代码，则 kubelet 会杀死这个容器并且重新启动它。
任何大于或等于 200 并且小于 400 的返回代码标示成功，其它返回代码都标示失败。

示例3：tcpSocket方式

复制代码

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: registry.k8s.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10

这个例子同时使用 readinessProbe 和 livenessProbe 探测。kubelet 会在容器启动 5 秒后发送第
一个 readinessProbe 探测。这会尝试连接 goproxy 容器的 8080 端口。如果探测成功，kubelet 将
继续每隔 10 秒运行一次检测。除了 readinessProbe 探测，这个配置包括了一个 livenessProbe 探
测。kubelet 会在容器启动 15 秒后进行第一次 livenessProbe 探测。就像 readinessProbe 探测
一样，会尝试连接 goproxy 容器的 8080 端口。如果 livenessProbe 探测失败，这个容器会被重新启
动

案列4：就绪检测

复制代码

vim readiness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget
  namespace: default
spec:
  containers:
  - name: readiness-httpget-container
    image: soscscs/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index1.html
      initialDelaySeconds: 1
      periodSeconds: 3
    livenessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10

#运行脚本创建容器
kubectl create -f readiness-httpget.yaml
#进入容器
kubectl exec -it readiness-httpget sh
cd /usr/share/nginx/html/
ls
50x.html    
index.html
echo 123 > index1.html 
exit
#查看pod
kubectl get pods 

NAME                READY    STATUS       RESTARTS       AGE
readiness-httpget   1/1      Running       0           2m31s

kubectl exec -it readiness-httpget -- rm -rf /usr/share/nginx/html/index.html   
   
kubectl get pods -w
NAME                READY    STATUS       RESTARTS       AGE
readiness-httpget   1/1      Running       0           4m10s 
readiness-httpget   0/1      Running       1           4m15s

案列5：就绪检测2

复制代码

vim readiness-myapp.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp1
  labels:
    app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10 
--- 分隔符
apiVersion: v1
kind: Pod
metadata:
  name: myapp2
  labels:
     app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10 
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp3
  labels:
     app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10 
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  type: ClusterIP
  ports:
  - name: http
    port: 80
    targetPort: 80

kubectl create -f readiness-myapp.yaml

kubectl get pods,svc,endpoints -o wide
NAME         READY        STATUS    RESTARTS     AGE          IP           NODE
NOMINATED NODE   READINESS GATES
pod/myapp1   1/1       Running      0         3m42s       10.244.2.13      node2   <none>                <none>
pod/myapp2   1/1       Running      0         3m42s       10.244.2.15      node1   <none>                <none>
pod/myapp3   1/1       Running      0         3m42s       10.244.2.14      node2   <none>                <none>

NAME               TYPE        CLUSTER-IP      EXTERNAL-IP     PODRT(S)        AGE
SELECTOR
......
service/myapp      ClusterIP   10.96.138.13      <none>         80/TCP        3m42s
app=myapp

NAME                      ENDPOINTS                                         AGE
...... 
endpoints/myapp        10.244.1.15:80,10.244.2.13:80,10.244.2.14:80        3m42s

kubectl exec -it pod/myapp1 -- rm -rf /usr/share/nginx/html/index.html

//readiness探测失败，Pod 无法进入READY状态，且端点控制器将从 endpoints 中剔除删除该 Pod 的 
IP 地址
kubectl get pods,svc,endpoints -o wide


NAME         READY        STATUS    RESTARTS     AGE          IP           NODE
NOMINATED NODE   READINESS GATES
pod/myapp1   0/1       Running      0         5m17s       10.244.2.13      node2   <none>                <none>
pod/myapp2   1/1       Running      0         5m17s       10.244.2.15      node1   <none>                <none>
pod/myapp3   1/1       Running      0         5m17s       10.244.2.14      node2   <none>                <none>

总结

资源分配是 Pod 稳定运行的基础保障 ，确保 Pod 有合理的资源支撑业务运行；探针是 Pod 稳定运行的监控手段 ，及时发现并处理运行异常。在实际配置中，需结合业务负载特性：高 CPU 负载的应用（如计算任务）需合理设置 CPU limits，高内存应用（如大数据处理）需关注内存 requests；探针参数需匹配应用启动与响应特性，避免因探测频率过高或初始延迟不足导致误判。

希望这篇博客能解决你的问题，有问题可以发在评论讨论。