探针与资源管理：让集群理解你的应用

探针解决什么问题#

前面几章我们一直在做同一件事：让 Pod 跑起来。但「跑起来」和「能用」是两回事：进程还在，不代表配置加载完了；端口还在监听，不代表数据库连得上；内存悄悄涨到上限，容器会被内核直接杀掉，而 Deployment 只会默默换一个新的。

如果集群对应用的状态一无所知，它只能靠猜：服务刚启动就把流量打进来，用户看到 502；某个副本卡死了（进程活着但不再响应），Service 还一直把请求发给它；死锁的进程永远不退出，Pod 就那么挂着，没人发现。

探针（Probe）就是应用主动告诉集群「我现在怎么样」的接口。 你定义探测方式和判断标准，kubelet 按周期去问，然后根据结果做三件事：把 Pod 从 Service 的流量列表里摘掉、重启容器、或者干脆先别管它。

三种探针的分工#

三个探针可以同时存在，执行顺序是：startupProbe 成功之前，livenessProbe 和 readinessProbe 都不会执行。所以有了 startupProbe，就不用再给 liveness 配一个很大的 initialDelaySeconds 去赌启动时间。共通的字段有 periodSeconds（探测间隔）、failureThreshold（连续失败几次算失败）、successThreshold（连续成功几次算恢复，liveness 只能是 1）。

判定流程和失败后果串起来是这样：

容器启动 ──► startupProbe：启动完成了吗？
                 │ ✓ 成功                     ✗ 连续失败 ──► 重启容器
                 ▼
             readinessProbe：现在能接流量吗？ ── ✗ 失败 ──► 标记 NotReady，
                 │ ✓ 成功                                  从 EndpointSlice 摘掉
                 ▼                                        （容器不重启，只是没流量）
             livenessProbe：还活着吗？ ──────── ✗ 失败 ──► 重启容器（RESTARTS 增长，
                 │ ✓ 成功                                  可能进入 CrashLoopBackOff）
                 ▼
             Service 把流量发给这个 Ready 的 Pod

三种探测方式#

httpGet 最常用，也最贴近真实流量；tcpSocket 适合没有 HTTP 接口的服务（比如 redis、MySQL）；exec 适合用脚本做复杂判断，但命令是在容器里执行的，镜像里没有那个命令，探针就会一直失败。

探针的判断标准要尽量轻量、无副作用。它会被高频调用，写一个每次都查全表的接口，等于给自己加了一个慢查询。

探针参数怎么定#

阈值不是拍脑袋写的，它们决定了「多久发现故障」和「会不会误判」之间的平衡：

startupProbe 的 periodSeconds × failureThreshold 就是允许的最长启动时间，按应用实测启动时间留 2 到 3 倍余量即可。

动手：给 web 加上三种探针#

把 nginx 部署成 web，加上完整的三种探针和一个 Service。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - name: http
              containerPort: 80
          startupProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 2
            failureThreshold: 30
          readinessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 5
            timeoutSeconds: 2
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi
---
apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: demo
spec:
  selector:
    app: web
  ports:
    - name: http
      port: 80
      targetPort: http

kubectl apply -f web-probes.yaml
kubectl get pods -n demo -l app=web
kubectl get endpointslices -n demo

kubectl get pods 里两个 Pod 都显示 READY 1/1、STATUS Running（分子是就绪容器数，分母是容器总数）；kubectl get endpointslices 中 web 这一行的 ENDPOINTS 列会列出两个 Pod IP。只有 Ready 的 Pod 才会出现在这里，这是 Service 能做负载均衡的基础。

验证：readiness 摘流量，liveness 重启容器#

做一次「故意写错探针」的实验，这是理解三种探针差别最快的方式。先准备一份探针写错的清单：web-bad 只有一个副本，readiness 指向 nginx 并不存在的 /healthz。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-bad
  namespace: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web-bad
  template:
    metadata:
      labels:
        app: web-bad
    spec:
      containers:
        - name: web
          image: nginx:1.27
          readinessProbe:
            httpGet:
              path: /healthz
              port: 80
            periodSeconds: 5
            failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
  name: web-bad
  namespace: demo
spec:
  selector:
    app: web-bad
  ports:
    - name: http
      port: 80
      targetPort: 80

kubectl apply -f web-bad.yaml
kubectl get pods -n demo -l app=web-bad
kubectl get endpointslices -n demo
kubectl describe pod -n demo -l app=web-bad

kubectl patch deployment web-bad -n demo --type=json -p '[
  {"op": "replace", "path": "/spec/template/spec/containers/0/readinessProbe/httpGet/path", "value": "/"}
]'
kubectl rollout status deployment/web-bad -n demo
kubectl get endpointslices -n demo

kubectl patch deployment web-bad -n demo --type=json -p '[
  {"op": "remove", "path": "/spec/template/spec/containers/0/readinessProbe"},
  {"op": "add", "path": "/spec/template/spec/containers/0/livenessProbe",
   "value": {"httpGet": {"path": "/healthz", "port": 80}, "periodSeconds": 5, "failureThreshold": 2}}
]'
kubectl get pods -n demo -l app=web-bad -w

requests 与 limits：让调度器和内核都心里有数#

探针管的是「健康」，资源字段管的是「够不够用」。它们是一对：

调度器怎么用 requests 挑节点，见第 14 章 调度。单位要记清楚：CPU 的 1 表示 1 个核，500m 是半个核，100m 是 0.1 个核（m 是毫核）；内存的 Mi、Gi 是 1024 进制，M、G 是 1000 进制，Kubernetes 里习惯用 Mi。

实践上有个简单的起点：requests 填「平时用量」，limits 填「峰值留一点余量」。内存的 limits 不要低于 JVM、Node.js 这类运行时自己声明的堆上限，否则容器会在你以为还早的时候就 OOMKilled。

QoS 类别、LimitRange 与 ResourceQuota#

Kubernetes 会按 requests/limits 的组合给 Pod 打上 QoS 标签，节点资源紧张时按这个顺序驱逐：

kubectl get pod -n demo -l app=web -o jsonpath='{.items[0].status.qosClass}{"\n"}'

上面 web 的配置里 requests 和 limits 不相等，所以结果是 Burstable。团队协作时还有两个常用对象：LimitRange 给命名空间里的容器设默认值和上下限，新人忘了写 requests 也能拿到默认值；ResourceQuota 限制整个命名空间的总量，比如「最多 4 核 CPU、8Gi 内存、20 个 Pod」，超过就创建失败。

用 kubectl top 看真实用量#

requests 是你猜的，kubectl top 才是实测。它依赖集群里的 metrics-server，kind 默认没装，可以这样补上：

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.7.2/components.yaml
kubectl patch deployment metrics-server -n kube-system --type=json \
  -p '[{"op":"add","path":"/spec/template/spec/containers/0/args/-","value":"--kubelet-insecure-tls"}]'
kubectl -n kube-system rollout status deployment metrics-server

kind 的 kubelet 用的是自签证书，所以需要 --kubelet-insecure-tls，否则 metrics-server 抓不到数据。等半分钟左右再执行：

kubectl top pod -n demo
kubectl top node

输出是 NAME / CPU(cores) / MEMORY(bytes) 三列。如果提示 error: Metrics API not available，说明 metrics-server 还没就绪，用 kubectl -n kube-system get pod 和 kubectl -n kube-system logs deploy/metrics-server 继续查。

metrics-server 的证书、校验与 HPA 的指标来源#

上一节用一条 kubectl apply 就装上了 metrics-server，但它在生产里最容易坏在两个 TLS 环节上。先看它到底插在哪条链路里：

kubectl top / HPA 控制器
        │  读 metrics.k8s.io/v1beta1
        ▼
   API Server ──（APIService 聚合代理）──▶ metrics-server
                                                │ HTTPS 10250
                                                ▼
                            kubelet /metrics/resource（每个节点一个）

metrics-server 不是一个普通的 Deployment，它通过 Aggregation Layer 把自己注册成 API Server 的一个扩展接口（APIService v1beta1.metrics.k8s.io）。kubectl top 和 HPA 都只是去读这个接口，从不直接连 metrics-server。链路上有两处证书校验，排错时先分清是哪一个：

第二种在 kind、k3s 这类本地集群里几乎必然出现：kubelet 用自签证书，证书里也没有节点 IP 的 SAN。--kubelet-insecure-tls 的作用就是跳过这次校验，代价是放弃了对 kubelet 的身份验证——理论上任何人都能冒充 kubelet 给 metrics-server 喂假数据，而 HPA 会照着假数据扩缩容。所以它的定位是「本地开发/测试集群的临时开关」，生产上应该把集群 CA 挂进去，让它正常校验：

# 仅本地测试：跳过 kubelet 证书校验
helm install metrics-server metrics-server/metrics-server --namespace kube-system \
  --set 'args={--kubelet-insecure-tls}'

# 生产：把集群 CA 挂进容器（需另外配 volume），并指定 CA 路径
helm install metrics-server metrics-server/metrics-server --namespace kube-system \
  --set 'args={--kubelet-certificate-authority=/etc/ssl/certs/kube-ca.crt,--kubelet-preferred-address-types=InternalIP}'

装完不要只看 Pod 是不是 Running，要把聚合层验一遍：

kubectl get apiservice v1beta1.metrics.k8s.io                 # AVAILABLE 必须为 True
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes | head -c 300
kubectl top nodes

apiservice 那一行显示 True、--raw 能返回 JSON，才说明「API Server → metrics-server → kubelet」整条链路通了。只看到 Pod Running 但 AVAILABLE=False，问题一定在上面那两处 TLS 环节之一。

HPA 的指标来源也是它。autoscaling/v2 的 HPA 在 type: Resource 时读的就是 metrics.k8s.io 给出的容器实际用量，再除以 requests 算出利用率——目标工作负载必须写 requests，否则百分比算不出来：

kubectl get hpa -n demo
kubectl describe hpa web -n demo | tail -20

TARGETS 列显示 <unknown>/50% 时按顺序查两件事：kubectl top pod -n demo 有没有数字（没有就是 metrics-server 的问题），Pod 有没有写 resources.requests（没写就是配置的问题）。还要记住 metrics-server 的定位：默认每 15 秒采集一次（--metric-resolution），只保留最近几分钟的瞬时值，不能查历史、不能做告警。要回溯「三天前开始变慢」这类问题，得靠 可观测性 里的 Prometheus 或 VictoriaMetrics。

参考：reference/k8s-in-action/addons/metrics-server/README.md

常见坑与排错#

自测题#

小结#

• startupProbe 管启动、readinessProbe 管接不接流量、livenessProbe 管要不要重启，三者职责不能混。
• readiness 失败只会把 Pod 从 Service 的 EndpointSlice 摘掉，liveness 失败才会重启容器。
• 探测方式有 httpGet、tcpSocket、exec 三种，判断标准要轻量、无副作用。
• requests 决定调度与 CPU 分配，limits 是硬上限：内存超了 OOMKilled，CPU 超了被限流。
• QoS 按 requests/limits 的组合分为 Guaranteed、Burstable、BestEffort，节点资源紧张时按这个顺序被驱逐。

练习#

1. 把 web 的 limits.memory 改成 8Mi 再 apply，观察 Pod 状态变化，并用 kubectl describe pod 找出原因，然后改回来。
2. 给 redis 写一个 tcpSocket 的 readinessProbe（端口 6379），验证它在 kubectl get endpointslices 里的表现。
3. 给 demo 命名空间建一个 LimitRange，把默认 requests 设为 cpu: 50m、memory: 64Mi，然后创建一个没写 resources 的 Pod，看它的 QoS 类别变成什么。

应用的健康和资源都有了保障，但一个集群往往要给多个团队用：怎么隔离、怎么限制、谁有权限看哪个命名空间？下一章第 12 章 命名空间与 RBAC回答这些问题。

相关章节：第 7 章 Service（EndpointSlice 与流量分发）、第 14 章 调度（requests 如何影响调度）、第 15 章 排障手册（CrashLoopBackOff 的排查流程）。