平台能力总览¶
集群能启动，只是平台工程的起点。真正让 Kubernetes 可用的，是网络、存储、可观测性、证书、备份这些「第二层能力」。本章给出一张依赖地图，帮你决定先装什么、后装什么，以及哪些其实可以不装。
你将学到¶
- 平台能力的七个层次，以及它们之间的依赖关系
- 一份可以照着执行的安装顺序，而不是一堆并列的组件清单
- CNI、负载均衡、存储、监控、日志的选型判断
- 小集群 / 生产集群的差异化取舍
- 每个能力域对应的章节与验证入口
先分清「集群」和「平台」¶
kubeadm init 成功、节点 Ready，只说明控制平面和 kubelet 能工作。此时你得到的是一台「能调度 Pod 的机器」，还不是一个平台：
| 能力 | 没有它会发生什么 | 典型组件 |
|---|---|---|
| Pod 网络 | Pod 之间无法互通，CoreDNS 起不来 | Calico、Cilium、Flannel |
| 服务入口 | 集群外无法访问，LoadBalancer 一直 Pending | MetalLB、OpenELB、ingress-nginx |
| 持久存储 | 数据库 Pod 重建即丢数据 | OpenEBS、NFS CSI、云盘 CSI |
| 指标 | 无法 kubectl top，HPA 没有数据 |
metrics-server、Prometheus Adapter |
| 日志 | 容器重建后日志消失，无法检索 | Loki、Elasticsearch + Filebeat |
| 证书 | Ingress TLS 靠手工签发和续期 | cert-manager |
| 备份 | 误删 namespace 等于数据消失 | Velero |
这些能力不是平级的。网络是地基，存储和入口依赖它；监控依赖存储；证书依赖入口；备份依赖存储。按依赖顺序安装，能避免大量「Pod Pending / CrashLoopBackOff」的无效排错。
依赖地图¶
flowchart TB
subgraph L0[集群底座]
K[Kubernetes v1.31]
C[CNI: Calico / Cilium / Flannel]
end
subgraph L1[基础设施]
M[MetalLB / OpenELB]
S[StorageClass: OpenEBS / NFS CSI]
MS[metrics-server]
end
subgraph L2[平台服务]
I[ingress-nginx]
P[Prometheus + Grafana]
L[Loki / Elasticsearch]
CM[cert-manager]
end
subgraph L3[运营能力]
V[Velero]
KA[Karmada]
end
K --> C
C --> M
C --> S
C --> MS
M --> I
S --> P
S --> L
I --> CM
P --> V
S --> V
K --> KA图：平台能力的依赖关系。箭头表示「前者是后者的前置条件」，不是数据流。
推荐安装顺序¶
下面这份顺序按「最小可用 → 可观测 → 可恢复」组织。每一步都给出验证命令，装完再进入下一步。
| 步骤 | 安装内容 | 依赖 | 验证 | 对应章节 |
|---|---|---|---|---|
| 1 | CNI 插件 | 集群初始化时指定 Pod CIDR | kubectl get pods -n kube-system |
CNI 网络 |
| 2 | metrics-server | CNI、kubelet 证书 | kubectl top nodes |
调度与弹性 |
| 3 | StorageClass | 磁盘 / NFS / LVM | PVC 变为 Bound |
存储扩展 |
| 4 | MetalLB / OpenELB | CNI、可用 IP 段 | Service 获得 EXTERNAL-IP |
负载均衡 |
| 5 | ingress-nginx | MetalLB 或 NodePort | curl 命中后端 |
负载均衡 |
| 6 | Prometheus / Grafana | StorageClass | Target 全部 UP |
Prometheus |
| 7 | Loki 或 ECK | StorageClass、对象存储 | Grafana 能查到日志 | 日志与 ELK |
| 8 | cert-manager | ingress-nginx | Certificate 变为 Ready |
证书管理 |
| 9 | Velero | 对象存储、快照能力 | Backup 状态 Completed |
备份与恢复 |
| 10 | Karmada | 多个可用集群 | 资源被分发到成员集群 | 多集群 |
不要一次装完
在 4C8G 的单机实验环境里同时安装 Prometheus、Loki、ECK、GitLab，最常见的结局是节点 OOM，然后误以为是 Kubernetes 的问题。一次只加一个能力域，记录资源占用，再决定是否保留。
选型判断¶
CNI 怎么选¶
| 场景 | 建议 | 理由 |
|---|---|---|
| 初学、追求简单 | Flannel（VXLAN） | 配置少，排错路径短 |
| 需要 NetworkPolicy、BGP | Calico | 成熟、文档多，支持 IPIP/VXLAN/BGP |
| 需要 eBPF、Hubble、L7 可见性 | Cilium | 性能与可观测性强，可替换 kube-proxy |
| 云托管集群 | 跟随云厂商 | 避免与云网络叠加冲突 |
负载均衡怎么选¶
- 裸金属 / 自建虚拟机：MetalLB（L2 模式最简单）或 OpenELB。
- 云上：直接使用云 LoadBalancer，通常不必再装 MetalLB。
- 只有单节点 / 本地开发：
NodePort+port-forward足够，不必为了「看起来完整」引入 BGP。
存储怎么选¶
- 单机学习：OpenEBS hostpath 或 local-path-provisioner。
- 需要跨节点共享：NFS CSI（RWX），但要接受 NFS 的单点与性能边界。
- 需要块存储 / 快照：OpenEBS LVM 或云盘 CSI。
- 对象存储：MinIO 用于实验与 S3 兼容场景，生产要评估租户隔离与纠删码。
可观测性怎么选¶
Prometheus 负责指标，日志侧二选一即可：
| 维度 | Loki | Elasticsearch + Filebeat |
|---|---|---|
| 存储成本 | 低（只索引标签） | 高（全文索引） |
| 查询能力 | LogQL，适合按标签过滤 | 全文检索、聚合强 |
| 运维复杂度 | 较低 | 较高 |
| 适用场景 | 云原生、按 Pod/namespace 查日志 | 需要复杂检索、合规审计 |
版本基线¶
以下是本站在实验中使用的主版本，不要求完全一致，但不要让组件跨太多大版本：
| 组件 | 建议版本 | 说明 |
|---|---|---|
| Kubernetes | v1.31.x | 仓库中的 kubeadm 示例基线 |
| Helm | 3.16+ | 不再需要 Tiller |
| Calico | 3.29+ | 与 K8s 1.31 兼容 |
| Cilium | 1.16+ | 使用 cilium install 管理 |
| MetalLB | 0.14+ | v1beta1 API |
| OpenEBS | 4.1+ | 4.x 与 3.x 差异很大 |
| cert-manager | 1.17+ | v1 API |
| Velero | 1.15+ | 注意 node-agent 与 CSI |
| Karmada | 1.13+ | 与成员集群版本保持兼容 |
版本不是越新越好
平台组件与 Kubernetes 有版本 skew 限制。升级集群前，先查组件的兼容矩阵；升级 CNI / CSI 时，先在测试集群验证 Pod 网络与 PVC 挂载。
实验：检查你的平台完成度¶
在集群上执行下面这段脚本，逐项确认基础能力是否就绪：
#!/usr/bin/env bash
set -u
echo "== 节点 =="
kubectl get nodes -o wide
echo "== CNI Pod =="
kubectl get pods -n kube-system | grep -E 'calico|cilium|flannel' || true
echo "== metrics-server =="
kubectl top nodes 2>&1 | head -5
echo "== StorageClass =="
kubectl get storageclass
echo "== LoadBalancer Service =="
kubectl get svc -A | awk '$3=="LoadBalancer"'
echo "== IngressClass =="
kubectl get ingressclass
echo "== 监控 Target =="
kubectl get servicemonitors -A 2>/dev/null | head -10
预期至少看到：
- 所有节点
Ready； - 至少一个 CNI Pod 处于
Running； - 至少一个非
kubernetes.io/no-provisioner的 StorageClass； - 如果装了 MetalLB，LoadBalancer Service 不再停留在
<pending>。
常见问题¶
| 现象 | 可能原因 | 处理 |
|---|---|---|
CoreDNS Pending |
没有 CNI，或 CNI Pod 未就绪 | 先装 CNI，再等 CoreDNS 重建 |
kubectl top 报 metrics not available |
metrics-server 未装或 TLS 证书不匹配 | 检查 --kubelet-insecure-tls 与 APIService |
PVC 一直 Pending |
没有默认 StorageClass，或 WaitForFirstConsumer 未调度 |
指定 storageClassName，或先创建 Pod |
LoadBalancer <pending> |
没有 LB 实现，或地址池耗尽 | 装 MetalLB 并创建 IPAddressPool |
| Ingress 502 | Service 名字/端口错，或后端未 Ready | kubectl get endpoints 对照 |
Prometheus Target DOWN |
ServiceMonitor 标签不匹配 | 检查 selector.matchLabels 与 Service 标签 |
小结¶
- 平台能力有明确的依赖顺序：CNI → 指标/存储 → 入口 → 可观测性 → 证书/备份 → 多集群。
- 不要为了「全家桶」而安装；每个组件都要能回答「它解决什么问题、坏了怎么发现」。
- 先建立验证命令，再安装组件。没有验收标准的安装，等于没装。