从集群扩容到平台工程：基础设施工程师的云原生进阶路线

预计阅读时间：9 分钟

基础设施工程师正处在云原生体系最繁忙的交叉口：Kubernetes 集群要扩容，网络要保持连通，存储要跟随工作负载，平台要让开发者用得顺手，安全控制还不能成为交付瓶颈。面对 KubeCon + CloudNativeCon North America 2026 这样的技术大会，与其收集一长串工具名称，不如围绕真实故障和交付目标建立自己的学习路线。

不要按产品学习，要按故障链路学习

一个应用无法访问时，问题可能出在 Service、DNS、NetworkPolicy、CNI、负载均衡器，甚至云网络路由。Pod 调度失败，也可能同时涉及资源请求、节点容量、存储拓扑和安全策略。

因此，基础设施工程师可以把能力拆成五条相互连接的链路：

计算与调度：节点池、资源请求、弹性伸缩、升级和故障转移。
网络：服务发现、入口流量、东西向通信、网络策略与可观测性。
存储：StorageClass、动态供应、快照、备份，以及有状态应用恢复。
平台体验：把复杂基础设施包装成模板、API、流水线和自助服务。
安全与治理：身份、最小权限、镜像供应链、策略执行和审计。

这几条链路不能孤立学习。例如，扩容不只是把副本数从 3 改成 30：调度器是否有容量、网络是否能承载连接数、存储是否允许跨节点挂载、策略是否允许新副本通信，都要一起验证。

用问题清单规划大会内容

选择议题时，可以先写下团队当前最昂贵的三个问题，再去匹配技术方向：

真实问题	应关注的方向	会后应得到的产物
扩容后 Pod 长时间 Pending	调度、容量规划、集群自动扩缩	一份 Pending 排查手册
服务偶发超时但指标正常	CNI、DNS、服务网格、网络观测	一套网络诊断命令
有状态应用恢复时间不可控	CSI、快照、备份与灾难恢复	一次可计时的恢复演练
开发团队直接复制 YAML	平台工程、模板、策略即代码	一个受约束的服务模板
权限不断累积	身份、RBAC、准入控制	权限审计与回收流程

听完一个议题后，不妨强制记录三件事：它解决什么故障，依赖哪些前提，如何在测试集群证明效果。这样得到的是可验证的工程知识，而不是一页工具清单。

一个可以动手改造的基础设施实验

下面的实验不是大会提供的固定环境，而是一种可以这样实践的最小项目。它把调度、网络、存储和安全放进同一个本地集群。运行前需要安装 Docker、minikube 和 kubectl。

先创建带 Calico CNI 的三节点集群：

minikube start \
  --driver=docker \
  --nodes=3 \
  --cni=calico \
  --cpus=2 \
  --memory=3072

kubectl get nodes -o wide
kubectl get pods -n kube-system

保存以下内容为 infra-lab.yaml：

apiVersion: v1
kind: Namespace
metadata:
  name: infra-lab
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo
  namespace: infra-lab
spec:
  replicas: 3
  selector:
    matchLabels:
      app: echo
  template:
    metadata:
      labels:
        app: echo
    spec:
      containers:
        - name: echo
          image: hashicorp/http-echo:1.0
          args:
            - -listen=:5678
            - -text=hello-from-infra-lab
          ports:
            - containerPort: 5678
          resources:
            requests:
              cpu: 50m
              memory: 32Mi
            limits:
              cpu: 200m
              memory: 64Mi
          readinessProbe:
            httpGet:
              path: /
              port: 5678
          securityContext:
            allowPrivilegeEscalation: false
            runAsNonRoot: true
            runAsUser: 1000
            capabilities:
              drop: ["ALL"]
---
apiVersion: v1
kind: Service
metadata:
  name: echo
  namespace: infra-lab
spec:
  selector:
    app: echo
  ports:
    - port: 5678
      targetPort: 5678
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: lab-data
  namespace: infra-lab
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: storage-writer
  namespace: infra-lab
spec:
  containers:
    - name: writer
      image: busybox:1.36
      command: ["sh", "-c", "date > /data/created-at && sleep 3600"]
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: lab-data
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: echo-ingress
  namespace: infra-lab
spec:
  podSelector:
    matchLabels:
      app: echo
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              access: granted
      ports:
        - protocol: TCP
          port: 5678

应用并检查资源：

kubectl apply -f infra-lab.yaml
kubectl get pods,pvc,svc -n infra-lab -o wide
kubectl rollout status deployment/echo -n infra-lab
kubectl exec -n infra-lab storage-writer -- cat /data/created-at

验证网络策略。没有标签的客户端应该超时，带有允许标签的客户端应该收到响应：

kubectl run blocked \
  -n infra-lab \
  --rm -it --restart=Never \
  --image=curlimages/curl:8.10.1 \
  -- curl --max-time 3 http://echo:5678

kubectl run allowed \
  -n infra-lab \
  --labels=access=granted \
  --rm -it --restart=Never \
  --image=curlimages/curl:8.10.1 \
  -- curl --fail http://echo:5678

还可以把副本扩到 6 个，观察调度结果和节点分布：

kubectl scale deployment/echo -n infra-lab --replicas=6
kubectl get pods -n infra-lab -l app=echo -o wide
kubectl describe deployment echo -n infra-lab

这个实验值得继续改造：删除一个节点观察恢复过程；给节点增加污点并配置容忍；加入 PodDisruptionBudget；删除 storage-writer 后重新挂载 PVC；或者故意写错 NetworkPolicy，再用日志和网络观测工具定位问题。

实验结束后可清理集群：

minikube delete

从“维护集群”走向“交付平台”

成熟的基础设施工作不应要求每位开发者理解 CNI、CSI 和调度器细节。平台团队需要把这些能力封装成有边界的产品，例如一个服务模板可以自动生成 Deployment、Service、资源限制、探针、默认网络策略和监控配置。

但抽象不能掩盖故障。平台至少要暴露以下信息：

工作负载为什么没有被调度；
流量在哪一层被拒绝；
存储卷位于哪个故障域；
哪条策略阻止了部署；
当前变更是否可以安全回滚。

好的平台既减少日常选择，也保留深入排障的入口。

带着可验证成果结束学习

规划基础设施工程师的云原生旅程时，可以用这份检查表约束投入：

为计算、网络、存储、平台和安全各选择一个当前问题；
每个方向只追踪少量核心项目，避免工具驱动的学习；
为关键结论设计一次故障注入或恢复实验；
把命令、指标和判断条件写进运行手册；
将重复操作变成模板或自动化流程；
同时记录方案的成本、复杂度和团队维护能力。

大会可以提供地图，但真正形成能力的是会后完成的实验、运行手册和平台改进。衡量学习效果的标准，不是记住多少项目名称，而是下一次集群、网络或存储出现问题时，能否更快地定位、恢复，并避免同类故障再次发生。