---
tags: [k8s, observability, logging, monitoring, devops]
create time: 2026-07-07 15:48
---

# Kubernetes 可观测性 — 日志、监控与健康检查

## 概述

可观测性（Observability）是理解系统内部状态的能力，在 Kubernetes 中通常由三大支柱构成：**Logging（日志）**、**Metrics（指标）** 和 **Tracing（链路追踪）**。日志告诉你「发生了什么」，指标告诉你「系统状态如何」，追踪告诉你「请求经过了哪里」。三者相互补充，缺一不可。在 K8s 环境中，由于 Pod 生命周期短暂、服务动态伸缩，传统的 SSH 进机器查日志方式不再适用，必须依赖系统化的可观测性方案。本文将从健康检查探针入手，逐步覆盖日志采集、指标监控和事件管理的完整实践。

---

## 健康检查（Probe）深入

Kubernetes 通过探针（Probe）机制持续监测容器的健康状态，自动完成故障隔离与自愈。这是 K8s 可观测性的第一道防线——不需要外部工具，原生能力就能实现基本的服务可用性保障。

### 三种探针详解

K8s 提供三种探针，各有分工：

| 探针 | 作用 | 失败后果 | 典型场景 |
|------|------|----------|----------|
| **livenessProbe** | 检测容器是否存活 | 杀死容器并重启（遵循 restartPolicy） | 应用死锁、无限循环 |
| **readinessProbe** | 检测容器是否就绪接收流量 | 从 Service 的 Endpoints 中摘除 | 依赖未就绪、预热加载中 |
| **startupProbe** | 检测容器是否完成启动 | 杀死容器并重启 | 慢启动应用（如 Java、大型模型加载） |

#### 配置参数说明

所有探针共享以下参数：

| 参数 | 类型 | 默认值 | 说明 |
|------|------|--------|------|
| `initialDelaySeconds` | int | 0 | 容器启动后多久开始第一次探测 |
| `periodSeconds` | int | 10 | 探测间隔（秒） |
| `timeoutSeconds` | int | 1 | 探测超时时间（秒） |
| `failureThreshold` | int | 3 | 连续失败多少次后判定为不健康 |
| `successThreshold` | int | 1 | 连续成功多少次后恢复（liveness 固定为 1） |

> [!tip] startupProbe 与 livenessProbe 的协作
> 当 `startupProbe` 配置后，`livenessProbe` 和 `readinessProbe` 会在 startupProbe 成功之后才生效。这意味着你可以用一个宽松的 startupProbe（比如 `failureThreshold: 30`、`periodSeconds: 10`，即允许最多 300 秒启动时间），而 livenessProbe 保持较严格的配置，避免慢启动应用被误杀。

### 探测方式

K8s 支持四种探测机制，选择哪种取决于应用特性和暴露的端口。

#### exec — 执行命令探测

适用于：自定义健康检查逻辑、需要检查内部状态的场景（如数据库连接池）。

```yaml
livenessProbe:
  exec:
    command:
      - /bin/sh
      - -c
      - "pg_isready -U postgres"
  initialDelaySeconds: 15
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3
```

容器内执行指定命令，退出码为 0 表示健康，非 0 表示不健康。适用于需要检查进程内部状态（如自定义脚本检测连接池）的场景。

#### httpGet — HTTP 请求探测

适用于：Web 服务、API 服务，最常用的探测方式。

```yaml
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    httpHeaders:
      - name: X-Custom-Header
        value: "k8s-probe"
  initialDelaySeconds: 10
  periodSeconds: 15
  timeoutSeconds: 3
  failureThreshold: 3
```

向容器的指定端口和路径发起 HTTP GET 请求，2xx/3xx 状态码视为健康。建议为健康检查设计轻量级的专用端点，避免在 `/` 上做复杂业务校验。

#### tcpSocket — TCP 端口探测

适用于：非 HTTP 协议的 TCP 服务（如数据库、Redis、gRPC 服务端口）。

```yaml
readinessProbe:
  tcpSocket:
    port: 3306
  initialDelaySeconds: 5
  periodSeconds: 10
  timeoutSeconds: 3
  failureThreshold: 3
```

尝试建立 TCP 连接，连接成功即视为健康。适合 MySQL、Redis 等数据库服务，或尚不支持 HTTP 健康检查端点的遗留服务。

#### gRPC — gRPC 健康检查探测

适用于：gRPC 微服务（K8s 1.24+ GA）。

```yaml
readinessProbe:
  grpc:
    port: 50051
    # 可选：指定服务名
    # service: "my-grpc-service"
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3
```

利用 gRPC 标准的 [Health Checking Protocol](https://github.com/grpc/grpc/blob/master/doc/health-checking.md) 进行探测，比 httpGet 更自然地适配 gRPC 服务。需要应用实现 `grpc.health.v1.Health` 服务。

### 探针设计原则

> [!tip] 原则一：慢启动应用必须用 startupProbe
> Java 应用、机器学习模型加载、大型缓存预热等场景，启动时间可能超过 livenessProbe 的 `initialDelaySeconds`。此时应该用 startupProbe 兜底，而不是无限增大 `initialDelaySeconds`——后者会导致所有重启都白白等待固定时长。

```yaml
# 典型的慢启动应用探针配置
startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30      # 允许最多 30 次失败
  periodSeconds: 10          # 每 10 秒检查一次
  # 总共允许 30 × 10 = 300 秒启动时间

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 15
  timeoutSeconds: 3
  failureThreshold: 3        # 启动后 3 次失败即重启
```

> [!tip] 原则二：readiness ≠ liveness，职责不能混
> - **readinessProbe**：「我准备好接收请求了吗？」——可以是暂时性的（如依赖 Redis 还没连上），摘除流量后恢复即可重新加入。
> - **livenessProbe**：「我还活着吗？」——失败意味着进程级故障（死锁、崩溃），需要重启。
> - 常见错误：把依赖检查（如数据库连接）放在 livenessProbe 里。数据库短暂不可达会导致 Pod 被重启，反而加重问题。

> [!tip] 原则三：健康端点要轻量
> livenessProbe 的 `/healthz` 端点不应该检查下游依赖（数据库、Redis 等），否则下游抖动会导致 Pod 被误杀。readinessProbe 可以做适度的依赖检查，但也要控制超时。

> [!warning] 避免探针与应用抢占资源
> exec 探针会 fork 子进程，在资源受限的容器中可能加剧 OOM。高并发场景下优先使用 httpGet 或 tcpSocket。

#### 探针决策流程图

```mermaid
flowchart TD
    A[应用需要健康检查] --> B{启动时间 > 30 秒?}
    B -->|是| C[配置 startupProbe]
    B -->|否| D{需要检查依赖?}
    C --> D
    D -->|是, 如 DB/Redis| E[readinessProbe 检查依赖]
    D -->|否| F[readinessProbe 基础端口/路径]
    E --> G{livenessProbe 如何配置?}
    F --> G
    G --> H[仅检查进程存活<br>不检查下游依赖]
    H --> I{协议类型?}
    I -->|HTTP| J[httpGet /healthz]
    I -->|gRPC| K[grpc health check]
    I -->|TCP/数据库| L[tcpSocket port]
    I -->|自定义逻辑| M[exec command]
```

---

## 日志管理

### K8s 日志架构

在 Kubernetes 中，日志的生命周期跨越三个层级：容器层、节点层、集群层。理解这个链路是做好日志管理的前提。

```mermaid
flowchart LR
    subgraph 容器层
        A[应用进程] -->|stdout / stderr| B[容器运行时<br>CRI]
    end

    subgraph 节点层
        B -->|写入文件| C["/var/log/pods/"]
        C --> D[kubelet 日志轮转]
    end

    subgraph 集群层
        D --> E[日志采集 Agent<br>Fluentd / Promtail / Filebeat]
        E --> F[存储后端<br>Elasticsearch / Loki / S3]
        F --> G[查询 UI<br>Kibana / Grafana]
    end

    A -.->|Sidecar 模式| H[日志 Sidecar 容器]
    H --> F
```

K8s 推荐的最佳实践是：**应用将日志输出到 stdout/stderr**，由 kubelet 负责写入节点磁盘，再由集群级采集工具统一收集。这样做解耦了应用和日志基础设施，应用无需关心日志的存储和传输。

### 节点级日志

#### 目录结构

kubelet 将每个容器的 stdout/stderr 写入节点上的日志文件，路径格式为：

```
/var/log/pods/<namespace>_<pod-name>_<pod-uid>/<container-name>/<restart-count>.log
```

实际示例：

```
/var/log/pods/default_nginx-7d8b49557c-abc123_5d1f3a2e-1234-5678-abcd-ef0123456789/
├── nginx/
│   ├── 0.log        # 第 0 次启动的日志
│   └── 1.log        # 第 1 次重启后的日志
└── nginx/
    └── 0.log -> /var/log/containers/nginx-xxx.log  # 符号链接
```

`/var/log/containers/` 目录下的文件是指向 `/var/log/pods/` 的符号链接，文件名包含容器名和容器 ID，方便按容器名查找。

#### 日志轮转（Log Rotation）

kubelet 通过以下参数控制日志轮转（配置在 kubelet 的 `--container-log-*` 参数中）：

| 参数 | 说明 | 默认值 |
|------|------|--------|
| `--container-log-max-size` | 单个日志文件最大大小 | 10Mi |
| `--container-log-max-files` | 每个容器保留的日志文件数 | 5 |

在 `KubeletConfiguration` 中配置：

```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
containerLogMaxSize: "50Mi"
containerLogMaxFiles: 10
```

> [!warning] 节点磁盘空间
> 日志量大的应用（如高并发网关）可能快速占满磁盘。务必设置合理的轮转策略，并配合监控节点磁盘使用率（`node_filesystem_avail_bytes` 指标）。

### 集群级方案

#### 方案对比

| 维度 | EFK（Elasticsearch + Fluentd + Kibana） | Loki + Promtail + Grafana |
|------|------------------------------------------|---------------------------|
| **存储模型** | 全文索引，存储成本高 | 标签索引 + 压缩块存储，成本低 |
| **查询语言** | KQL / Lucene | LogQL（类 PromQL 语法） |
| **全文搜索** | 原生支持，性能好 | 不支持原生全文搜索，需配合标签 |
| **资源消耗** | 高（JVM 内存、磁盘 IO） | 低（Go 二进制，无全文索引） |
| **与 Metrics 集成** | 需额外对接 Prometheus | 天然与 Prometheus/Grafana 生态融合 |
| **适用场景** | 大规模日志分析、全文检索需求强 | 资源敏感、与 Prometheus 混合部署 |
| **社区趋势** | 成熟但逐渐被替代 | CNCF 毕业项目，增长迅速 |

#### EFK 架构

```mermaid
flowchart LR
    A[Pod stdout/stderr] --> B[节点日志文件]
    B --> C[Fluentd DaemonSet]
    C --> D[Elasticsearch]
    D --> E[Kibana]
    E --> F[用户查询]
```

Fluentd 以 DaemonSet 形式部署在每个节点上，tail 节点日志文件并推送到 Elasticsearch。

#### Loki + Promtail 架构

```mermaid
flowchart LR
    A[Pod stdout/stderr] --> B[节点日志文件]
    B --> C[Promtail DaemonSet]
    C --> D[Loki]
    D --> E[Grafana]
    E --> F[用户查询]
```

Promtail 同样以 DaemonSet 部署，但它只提取标签（namespace、pod、container）和日志行，发送给 Loki 进行存储。Loki 的核心设计理念是「like Prometheus, but for logs」——只对标签建索引，日志内容以压缩块存储。

### 结构化日志

非结构化日志（纯文本）在大规模集群中难以高效查询。结构化日志以 JSON 格式输出，便于日志系统自动解析和过滤。

#### JSON 日志输出示例（Go / zap）

```go
import "go.uber.org/zap"

logger, _ := zap.NewProduction()
defer logger.Sync()

logger.Info("request processed",
    zap.String("method", "GET"),
    zap.String("path", "/api/v1/users"),
    zap.Int("status", 200),
    zap.Duration("latency", 150*time.Millisecond),
    zap.String("request_id", "abc-123"),
)
```

输出：

```json
{"level":"info","ts":1720340880.123,"msg":"request processed","method":"GET","path":"/api/v1/users","status":200,"latency":0.15,"request_id":"abc-123"}
```

#### 结构化日志最佳实践

1. **统一字段命名**：团队内约定日志字段名（如 `request_id` 而非 `reqId` / `rid`），便于跨服务聚合。
2. **必须包含的字段**：时间戳（`ts`）、日志级别（`level`）、消息（`msg`）、请求 ID（`request_id`）、服务名（`service`）。
3. **避免在日志中输出敏感信息**：密码、Token、身份证号等必须脱敏。
4. **日志级别控制**：生产环境默认 `info`，可通过环境变量动态调整为 `debug` 以便排查问题。

> [!tip] kubectl 查看结构化日志
> 使用 `kubectl logs` 结合 `jq` 可以快速过滤 JSON 日志：
> ```bash
> kubectl logs my-pod -c my-container | jq 'select(.level == "error")'
> kubectl logs my-pod -c my-container | jq 'select(.latency > 0.5)'
> ```

---

## 指标监控

### Metrics Server

Metrics Server 是 Kubernetes 内置的轻量级指标采集组件，提供 CPU 和内存使用数据，是 `kubectl top` 和 HPA（基于资源指标）的基础设施。

#### 工作原理

```mermaid
flowchart LR
    A[kubelet] -->|Summary API| B[Metrics Server]
    B -->|Metrics API| C[kubectl top]
    B -->|Metrics API| D[HPA Controller]
```

- 每个 kubelet 暴露 **Summary API**（`/stats/summary`），包含该节点上所有 Pod 的 CPU/内存使用数据。
- Metrics Server 定期（默认 15 秒）从所有 kubelet 拉取数据，聚合后通过 **Metrics API**（`metrics.k8s.io`）暴露。

#### 安装

```bash
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
```

验证：

```bash
kubectl top nodes
kubectl top pods -n default
```

#### 局限性

- 只提供 CPU 和内存指标，不支持磁盘、网络等。
- 数据只保留短期窗口（约 1 分钟），不支持历史查询。
- 不支持自定义指标——需要 Prometheus 等外部系统。

> [!info] Metrics Server vs Prometheus
> Metrics Server 是 K8s 内置的「最小可用」指标方案，适合 `kubectl top` 和基于资源的 HPA。如果你需要更丰富的指标、历史数据和告警，必须部署 Prometheus。

### Prometheus + Grafana

Prometheus 是 CNCF 毕业项目，是 Kubernetes 生态中最主流的监控方案。Grafana 作为可视化层，提供丰富的仪表盘。

#### 架构概览

```mermaid
flowchart LR
    subgraph K8s 集群
        A[应用 /export_metrics] -->|pull| B[Prometheus Server]
        C[kube-state-metrics] -->|pull| B
        D[Node Exporter] -->|pull| B
        E[ServiceMonitor CRD] -.->|配置发现| B
    end

    B --> F[Grafana]
    B --> G[Alertmanager]
    G --> H[邮件 / Slack / 钉钉]
    B --> I[长期存储<br>Thanos / VictoriaMetrics]
```

核心组件：

- **Prometheus Server**：时序数据库 + 采集引擎，定期从 targets 拉取（pull）指标。
- **kube-state-metrics**：将 K8s 对象状态（Pod、Deployment、Node 等）转换为 Prometheus 指标。
- **Node Exporter**：采集节点级系统指标（CPU、内存、磁盘、网络）。
- **ServiceMonitor CRD**：由 Prometheus Operator 提供，以声明式方式配置采集目标。
- **Alertmanager**：告警路由、去重、分组、静默。

#### ServiceMonitor 示例

```yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-app
  namespace: monitoring
  labels:
    release: prometheus    # 匹配 Prometheus 实例的标签选择器
spec:
  namespaceSelector:
    matchNames:
      - default
  selector:
    matchLabels:
      app: my-app          # 匹配目标 Service 的标签
  endpoints:
    - port: metrics        # Service 中定义的端口名
      path: /metrics
      interval: 15s
```

> [!info] ServiceMonitor 的工作方式
> Prometheus Operator 会 watch ServiceMonitor 资源的变化，自动更新 Prometheus 的采集配置。运维人员不再需要手写 `prometheus.yml` 的 scrape 配置，实现了采集配置的 GitOps 管理。

#### 常见 K8s 监控指标

| 指标名称 | 含义 | 告警建议 |
|----------|------|----------|
| `container_cpu_usage_seconds_total` | 容器累计 CPU 使用时间 | 持续 > 80% requests 告警 |
| `container_memory_working_set_bytes` | 容器内存工作集 | 接近 limits 时告警 |
| `kube_pod_restart_total` | Pod 重启次数 | 短时间内重启 > 3 次告警 |
| `kube_pod_status_phase` | Pod 状态（Pending/Running/Failed） | Pending > 5 分钟告警 |
| `kube_node_status_condition` | 节点状态（Ready/NotReady） | NotReady 告警 |
| `kube_deployment_status_replicas_available` | Deployment 可用副本数 | 小于期望副本数告警 |
| `node_filesystem_avail_bytes` | 节点可用磁盘空间 | < 10% 剩余告警 |

### HPA 自定义指标

HPA 默认支持基于 CPU/Memory 的扩缩容，但实际场景中，基于请求速率（QPS）、队列长度、延迟等自定义指标更有意义。

#### 前置条件

1. 安装 Prometheus Adapter（将 Prometheus 指标转换为 K8s Custom Metrics API）：
   ```bash
   helm install prometheus-adapter prometheus-community/prometheus-adapter \
     --namespace monitoring \
     --set prometheus.url=http://prometheus-server.monitoring.svc
   ```

2. 确认 Custom Metrics API 可用：
   ```bash
   kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq .
   ```

#### HPA 配置示例（基于 HTTP 请求速率）

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
    # 自定义指标：每 Pod 每秒请求数
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "100"    # 每个 Pod 目标 100 QPS
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Percent
          value: 50
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300    # 缩容冷却 5 分钟，避免抖动
      policies:
        - type: Percent
          value: 25
          periodSeconds: 60
```

> [!tip] 扩缩容行为配置
> `behavior` 字段（K8s 1.18+）允许精细控制扩缩容速度。建议扩容激进（快速应对流量高峰）、缩容保守（`stabilizationWindowSeconds` 设大，避免频繁抖动导致连接中断）。

---

## 事件（Events）

Kubernetes Events 是集群中发生的重大状态变更记录，是排查问题的第一手信息。

### 查看事件

```bash
# 当前 namespace 的事件，按时间排序
kubectl get events --sort-by='.lastTimestamp'

# 所有 namespace 的事件
kubectl get events -A

# 只看 Warning 级别事件
kubectl get events --field-selector type=Warning

# 查看特定 Pod 的事件
kubectl describe pod my-pod
```

### 常见事件类型

| Reason | 类型 | 含义 |
|--------|------|------|
| `Scheduled` | Normal | Pod 成功调度到节点 |
| `Pulling` / `Pulled` | Normal | 正在拉取 / 已拉取镜像 |
| `Created` / `Started` | Normal | 容器已创建 / 已启动 |
| `Unhealthy` | Warning | 健康检查失败 |
| `BackOff` | Warning | 重启退避（CrashLoopBackOff） |
| `FailedScheduling` | Warning | 调度失败（资源不足、亲和性冲突等） |
| `OOMKilling` | Warning | 容器因内存不足被杀死 |
| `Evicted` | Warning | Pod 被驱逐（磁盘压力、内存压力等） |

### 事件 TTL 与持久化

> [!warning] Events 会被自动清理
> 默认情况下，Events 的 TTL（Time To Live）为 **1 小时**。这意味着如果一个 Pod 在 2 小时前 OOMKilled，你通过 `kubectl describe pod` 看不到相关事件。

解决方法：

1. **调整 TTL**（K8s 1.19+）：
   ```bash
   # 在 kube-apiserver 中设置
   --event-ttl=24h
   ```

2. **持久化到日志系统**：将 Events 采集到 Elasticsearch/Loki 等系统中长期保存。
   - 使用 kube-state-metrics 的 `kube_event_*` 指标采集到 Prometheus。
   - 使用专门的 Events 采集工具（如 `event-exporter`）推送到日志系统。

3. **event-exporter 示例**：
   ```yaml
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: event-exporter
     namespace: monitoring
   spec:
     template:
       spec:
         containers:
           - name: event-exporter
             image: ghcr.io/resmoio/kubernetes-event-exporter:latest
             args:
               - -conf=/data/config.yaml
             volumeMounts:
               - name: config
                 mountPath: /data
         volumes:
           - name: config
             configMap:
               name: event-exporter-config
   ```

---

## 常见陷阱与最佳实践

### 陷阱一：日志量爆炸

**问题**：高并发服务的 debug 日志未关闭，一天产生几十 GB 日志，磁盘告警或 Elasticsearch 索引膨胀。

**解决方案**：
- 生产环境默认 `info` 级别，通过环境变量或配置中心动态调整。
- 使用 Fluentd/Promtail 的 filter 功能丢弃无用日志（如 kube-system 的健康检查日志）。
- 设置 Elasticsearch 的 ILM（Index Lifecycle Management）策略，自动过期删除旧索引。

```yaml
# Fluentd filter 示例：丢弃 kube-system 命名空间的日志
<filter kubernetes.**>
  @type grep
  <exclude>
    key $.kubernetes.namespace_name
    pattern /^kube-system$/
  </exclude>
</filter>
```

### 陷阱二：探针超时与应用启动时间不匹配

**问题**：Java 应用启动需要 60 秒，但 livenessProbe 的 `initialDelaySeconds` 只设了 30 秒，导致每次重启都进入 CrashLoopBackOff。

**解决方案**：使用 startupProbe 代替盲目增大 `initialDelaySeconds`（详见探针设计原则一）。

### 陷阱三：监控指标标签爆炸

**问题**：在 Prometheus 指标中使用 `user_id`、`request_path` 等高基数（high cardinality）标签，导致时间序列数暴涨，Prometheus 内存 OOM。

**解决方案**：
- 高基数字段（如 request_id、user_id）放到日志中，不作为指标标签。
- `request_path` 应归一化（如 `/api/v1/users/123` → `/api/v1/users/:id`）。
- 使用 Prometheus 的 `metric_relabel_configs` 丢弃不需要的标签。

```yaml
# Prometheus 配置：限制标签基数
metric_relabel_configs:
  - source_labels: [__name__]
    regex: "container_.*"
    action: keep
  - regex: "pod_name"
    action: labeldrop
```

### 陷阱四：readinessProbe 失败但 livenessProbe 正常

**问题**：readinessProbe 依赖 Redis，Redis 短暂不可达，Pod 被从 Endpoints 摘除。但 livenessProbe 正常，Pod 不会被重启。流量被摘除后 Pod 中积压的请求超时，用户报错。

**解决方案**：
- readinessProbe 的依赖检查要设置合理的超时（如 2 秒内无响应即判定失败）。
- 在应用内部实现熔断机制，不要完全依赖 K8s 探针。
- 确保 readinessProbe 恢复时，Pod 能快速重新加入 Endpoints（`successThreshold: 1`）。

### 陷阱五：kubectl top 数据不准

**问题**：`kubectl top pods` 显示的 CPU 使用率为 0 或与实际不符。

**原因**：
- Metrics Server 启动后需要约 1-2 分钟才能采集到数据。
- 容器的 CPU request 未设置，百分比无法计算。
- Metrics Server 的 `--kubelet-insecure-tls` 未配置导致与 kubelet 通信失败。

**解决方案**：

```bash
# 检查 Metrics Server 是否正常运行
kubectl get deployment metrics-server -n kube-system

# 检查是否有错误日志
kubectl logs -n kube-system deployment/metrics-server

# 使用 --resource 选项查看原始数值而非百分比
kubectl top pods --containers
```

### 最佳实践汇总

| 领域 | 实践 |
|------|------|
| 日志 | stdout 输出、JSON 结构化、统一字段命名、合理轮转 |
| 探针 | startupProbe 兜底慢启动、liveness 不查依赖、readiness 做适度依赖检查 |
| 监控 | Prometheus + Grafana 标准栈、ServiceMonitor 声明式配置 |
| 告警 | 分级告警（Warning/Critical）、去重分组、值班轮转 |
| 指标 | 避免高基数标签、区分 RED（Rate/Error/Duration）指标与 USE（Utilization/Saturation/Errors）指标 |
| 事件 | 配置持久化、重要事件告警 |

---

## 延伸阅读

- [[k8s-03-pod]] — Pod 生命周期、调度与资源管理
- [[k8s-02-architecture]] — K8s 控制平面与节点组件架构
- [Kubernetes 官方文档 - Logging Architecture](https://kubernetes.io/docs/concepts/cluster-administration/logging/)
- [Kubernetes 官方文档 - Configure Liveness, Readiness and Startup Probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
- [Prometheus Operator 文档](https://prometheus-operator.dev/)
- [Grafana Loki 官方文档](https://grafana.com/docs/loki/latest/)
- [Google SRE Book - Monitoring Distributed Systems](https://sre.google/sre-book/practical-alerting/)