Kubernetes 运维实践深度解析

Kubernetes 把应用跑起来只是开始，真正的成本在”跑稳之后”。集群组件的健康度、etcd 的备份能不能恢复、升级路径怎么走、日志怎么聚合，这些不上生产不觉得痛的问题，一旦上线就得有答案。本文围绕集群管理、备份恢复、版本升级、资源配额和日志管理五块日常运维内容展开，每块都给出可复现的命令和踩过的坑。配合监控与可观测性和故障排查与调优一起看，就是一套从”看见”到”处理”的完整运维闭环。

一、集群管理#

1.1 集群组件管理#

graph TB subgraph "Control Plane" A["kube-apiserver"] --> B["etcd"] C["kube-scheduler"] --> A D["kube-controller-manager"] --> A end subgraph "Node" E["kubelet"] --> F["kube-proxy"] E --> G["Container Runtime"] end

组件	关键指标	巡检频率
etcd	磁盘延迟、投票超时	每分钟
apiserver	请求延迟、错误率	每分钟
scheduler	调度延迟、Pending Pods	每分钟
kubelet	PLEG duration、容器状态	每分钟

1
# 查看控制平面组件状态
2
# 注意：kubectl get componentstatus（别名 cs）在 1.19 起标记弃用，1.26 起移除。
3
# 更可靠的健康度来自 /metrics 和各组件自身暴露的指标，而非 componentstatus。
4
kubectl get componentstatus
5
kubectl get pods -n kube-system
6

7
# 查看 etcd 健康状态（需在 etcd Pod 所在节点或带证书的 etcdctl）
8
kubectl exec -n kube-system etcd-<node> -- etcdctl endpoint health
9

10
# 查看 API Server 延迟
11
kubectl get --raw '/metrics' | grep apiserver_request_duration_seconds

1.2 节点管理#

1
# 节点维护操作
2
# 1. 驱逐 Pod
3
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
4

5
# 2. 标记不可调度
6
kubectl cordon <node-name>
7

8
# 3. 解除维护
9
kubectl uncordon <node-name>
10

11
# 查看节点资源
12
kubectl describe node <node-name> | grep -A 5 "Allocated resources"

二、备份与恢复#

2.1 etcd 备份#

1
# 方式一：直接备份
2
ETCDCTL_API=3 etcdctl \
3
    --endpoints=https://127.0.0.1:2379 \
4
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
5
    --cert=/etc/kubernetes/pki/etcd/server.crt \
6
    --key=/etc/kubernetes/pki/etcd/server.key \
7
    snapshot save /tmp/etcd-backup.db
8

9
# 方式二：API Server 备份
10
kubectl get all --all-namespaces -o yaml > /tmp/cluster-backup.yaml
11

12
# 定时备份脚本
13
#!/bin/bash
14
BACKUP_DIR="/var/backups/k8s"
15
DATE=$(date +%Y%m%d_%H%M%S)
16
ETCDCTL_API=3 etcdctl \
17
    --endpoints=https://127.0.0.1:2379 \
18
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
19
    --cert=/etc/kubernetes/pki/etcd/server.crt \
20
    --key=/etc/kubernetes/pki/etcd/server.key \
21
    snapshot save ${BACKUP_DIR}/etcd-${DATE}.db

2.2 恢复流程#

1
# 恢复 etcd（单节点）
2
systemctl stop etcd
3
rm -rf /var/lib/etcd
4
ETCDCTL_API=3 etcdctl snapshot restore /tmp/etcd-backup.db \
5
    --initial-cluster=new-etcd-0=https://192.168.1.10:2380 \
6
    --initial-advertise-peer-urls=https://192.168.1.10:2380 \
7
    --name=new-etcd-0 \
8
    --data-dir=/var/lib/etcd
9
systemctl start etcd

三、版本升级#

3.1 升级策略#

graph TB subgraph "升级前" A["备份 etcd"] --> B["测试环境验证"] B --> C["准备回滚方案"] end subgraph "升级控制平面" D["升级 etcd"] --> E["升级 kube-apiserver"] E --> F["升级 controller-manager"] F --> G["升级 scheduler"] end subgraph "升级 Nodes" H["升级 kubelet"] --> I["升级 kube-proxy"] I --> J["验证应用"] end

3.2 升级执行#

1
# 查看可用版本
2
apt-cache madison kubeadm
3
kubeadm upgrade plan
4

5
# 升级控制平面
6
apt-get install -y kubeadm=1.23.0-*
7
kubeadm upgrade apply v1.23.0
8

9
# 升级节点
10
apt-get install -y kubelet=1.23.0-*
11
systemctl restart kubelet
12

13
# 升级插件
14
kubectl apply -f kube-proxy.yaml
15
kubectl rollout status daemonset/kube-proxy -n kube-system

四、资源配额管理#

4.1 ResourceQuota 与 LimitRange#

1
# ResourceQuota：命名空间级别资源配额
2
apiVersion: v1
3
kind: ResourceQuota
4
metadata:
5
  name: compute-quota
6
  namespace: my-namespace
7
spec:
8
  hard:
9
    requests.cpu: "10"
10
    requests.memory: 20Gi
11
    limits.cpu: "20"
12
    limits.memory: 40Gi
13
    pods: "100"
14
    services: "20"
15

16
---
17

18
apiVersion: v1
19
kind: LimitRange
20
metadata:
21
  name: container-limits
22
  namespace: my-namespace
23
spec:
24
  limits:
25
    - max:
26
        cpu: "4"
27
        memory: 8Gi
28
      min:
29
        cpu: "100m"
30
        memory: 128Mi
31
      default:
32
        cpu: "500m"
33
        memory: 512Mi
34
      defaultRequest:
35
        cpu: "200m"
36
        memory: 256Mi
37
      type: Container

4.2 资源配额计算#

1
class ResourceCalculator:
2
    @staticmethod
3
    def calculate_node_capacity(node):
4
        """计算节点可用资源"""
5
        return {
6
            "cpu": node.status.capacity["cpu"],
7
            "memory": node.status.capacity["memory"],
8
        }
9

10
    @staticmethod
11
    def calculate_allocatable(node):
12
        """计算节点可分配资源"""
13
        capacity = ResourceCalculator.calculate_node_capacity(node)
14
        system_reserved = {
15
            "cpu": "500m",  # 系统预留
16
            "memory": "1Gi",
17
        }
18
        return {
19
            "cpu": capacity["cpu"] - parse_resources(system_reserved["cpu"]),
20
            "memory": capacity["memory"] - parse_resources(system_reserved["memory"]),
21
        }

五、日志管理#

5.1 日志架构#

graph LR A["Pod 日志"] --> B["Node"] B --> C["日志代理"] C --> D["日志存储"] C --> E["日志索引"] E --> F["日志可视化"]

1
# Fluent Bit 配置
2
apiVersion: v1
3
kind: ConfigMap
4
metadata:
5
  name: fluent-bit-config
6
  namespace: logging
7
data:
8
  fluent-bit.conf: |
9
    [SERVICE]
10
        Flush         5
11
        Log_Level     info
12

13
    [INPUT]
14
        Name              tail
15
        Path              /var/log/containers/*.log
16
        Parser            docker
17
        Tag               kube.*
18

19
    [FILTER]
20
        Name                kubernetes
21
        Match                kube.*
22
        Kube_URL            https://kubernetes.default.svc:443
23
        Kube_CA_File        /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
24
        Kube_Token_File     /var/run/secrets/kubernetes.io/serviceaccount/token
25

26
    [OUTPUT]
27
        Name              es
28
        Match               kube.*
29
        Host               elasticsearch.logging.svc
30
        Port               9200
31
        HTTP_User          elastic
32
        HTTP_Passwd        changeme
33
        Logstash_Format    On
34
        Logstash_Prefix    kubernetes

Note

Parser docker 针对 Docker 运行时的 JSON 日志格式。Kubernetes 1.24 起 dockershim 移除，默认运行时为 containerd，其日志格式不同（CRI 格式，非纯 JSON），需改用 cri parser 或在 tail 段配置 multiline。从 Docker 迁移到 containerd 时，这是日志解析最容易断的地方。

5.2 日志查询#

1
# 查看 Pod 日志
2
kubectl logs <pod-name> --previous  # 上一个容器
3
kubectl logs <pod-name> -c <container>  # 指定容器
4

5
# 实时跟踪日志
6
kubectl logs -f <pod-name>
7

8
# 查看带时间戳的日志
9
kubectl logs <pod-name> --timestamps

如果应用把日志写到文件而非 stdout（很多传统应用如此），kubectl logs 看不到。常见做法是让容器把日志目录挂到 emptyDir，再起一个 sidecar tail 这个文件打到 stdout：

1
# 日志 sidecar 示例：应用写文件，sidecar 转发到 stdout 供 kubectl logs 采集
2
apiVersion: v1
3
kind: Pod
4
metadata:
5
  name: logger
6
spec:
7
  containers:
8
  - name: logger
9
    image: busybox
10
    args:
11
    - /bin/sh
12
    - -c
13
    - |
14
        while true; do
15
          echo "$(date) - Log message" >> /var/log/app.log
16
          sleep 10
17
        done
18
    volumeMounts:
19
    - name: log
20
      mountPath: /var/log
21
  volumes:
22
  - name: log
23
    emptyDir: {}

六、运维与监控协作#

6.1 日常运维监控要点#

运维工作离不开完善的监控体系。通过监控可以提前发现问题，降低故障影响：

graph LR A["日常运维"] --> B["资源监控"] A --> C["日志分析"] A --> D["告警响应"] B --> E["Prometheus"] C --> F["Loki/ELK"] D --> G["Alertmanager"] E --> H["预防性维护"] F --> H G --> H

关键运维指标：

运维场景	监控重点	告警阈值
节点维护	CPU/内存使用率、Pod 驱逐	使用率 > 80%
集群升级	API Server 延迟、etcd 健康	延迟 > 100ms
资源扩容	资源分配率、Pending Pods	分配率 > 90%
备份验证	etcd 快照大小、备份时效	备份过期 > 24h

Tip

完整的监控配置请参考 Kubernetes 监控与可观测性。

6.2 故障排查协作#

当监控告警触发时，运维人员需要快速响应：

1
# 快速诊断脚本示例
2
#!/bin/bash
3
echo "=== Cluster Status ==="
4
kubectl get nodes
5
kubectl get pods -A | grep -v Running | head -20
6

7
echo "=== Resource Usage ==="
8
kubectl top nodes
9
kubectl top pods -A | sort -k3 -rn | head -10
10

11
echo "=== Recent Events ==="
12
kubectl get events -A --sort-by='.lastTimestamp' | tail -20