3.1. 平台能力总览

集群能启动,只是平台工程的起点。真正让 Kubernetes 可用的,是网络、存储、可观测性、证书、备份这些「第二层能力」。本章给出一张依赖地图,帮你决定先装什么、后装什么,以及哪些其实可以不装。

层级:

L3 · 平台

难度:

进阶

预计:

30 分钟

前置:

核心对象、集群部署

3.1.1. 你将学到

  • 平台能力的七个层次,以及它们之间的依赖关系

  • 一份可以照着执行的安装顺序,而不是一堆并列的组件清单

  • CNI、负载均衡、存储、监控、日志的选型判断

  • 小集群 / 生产集群的差异化取舍

  • 每个能力域对应的章节与验证入口

3.1.2. 先分清「集群」和「平台」

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」的无效排错。

3.1.3. 依赖地图

架构图

图:平台能力的依赖关系。箭头表示「前者是后者的前置条件」,不是数据流。

3.1.4. 推荐安装顺序

下面这份顺序按「最小可用 → 可观测 → 可恢复」组织。每一步都给出验证命令,装完再进入下一步。

步骤

安装内容

依赖

验证

对应章节

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 的问题。一次只加一个能力域,记录资源占用,再决定是否保留。

3.1.5. 选型判断

3.1.5.1. CNI 怎么选

场景

建议

理由

初学、追求简单

Flannel(VXLAN)

配置少,排错路径短

需要 NetworkPolicy、BGP

Calico

成熟、文档多,支持 IPIP/VXLAN/BGP

需要 eBPF、Hubble、L7 可见性

Cilium

性能与可观测性强,可替换 kube-proxy

云托管集群

跟随云厂商

避免与云网络叠加冲突

3.1.5.2. 负载均衡怎么选

  • 裸金属 / 自建虚拟机:MetalLB(L2 模式最简单)或 OpenELB。

  • 云上:直接使用云 LoadBalancer,通常不必再装 MetalLB。

  • 只有单节点 / 本地开发:NodePort + port-forward 足够,不必为了「看起来完整」引入 BGP。

3.1.5.3. 存储怎么选

  • 单机学习:OpenEBS hostpath 或 local-path-provisioner。

  • 需要跨节点共享:NFS CSI(RWX),但要接受 NFS 的单点与性能边界。

  • 需要块存储 / 快照:OpenEBS LVM 或云盘 CSI。

  • 对象存储:MinIO 用于实验与 S3 兼容场景,生产要评估租户隔离与纠删码。

3.1.5.4. 可观测性怎么选

Prometheus 负责指标,日志侧二选一即可:

维度

Loki

Elasticsearch + Filebeat

存储成本

低(只索引标签)

高(全文索引)

查询能力

LogQL,适合按标签过滤

全文检索、聚合强

运维复杂度

较低

较高

适用场景

云原生、按 Pod/namespace 查日志

需要复杂检索、合规审计

3.1.6. 版本基线

以下是本站在实验中使用的主版本,不要求完全一致,但不要让组件跨太多大版本:

组件

建议版本

说明

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 挂载。

3.1.7. 实验:检查你的平台完成度

在集群上执行下面这段脚本,逐项确认基础能力是否就绪:

#!/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>。

3.1.8. 常见问题

现象

可能原因

处理

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 标签

3.1.9. 小结

  • 平台能力有明确的依赖顺序:CNI → 指标/存储 → 入口 → 可观测性 → 证书/备份 → 多集群。

  • 不要为了「全家桶」而安装;每个组件都要能回答「它解决什么问题、坏了怎么发现」。

  • 先建立验证命令,再安装组件。没有验收标准的安装,等于没装。

3.1.10. 延伸阅读