生态与进阶方向

走到这里，你已经把 Kubernetes 的核心知识点过了一遍。但 k8s 真正的威力，往往不在它本身，而在它庞大的生态。本章不深入细节，只做”地图式”的概览，帮你认路。

65-1 为什么需要生态

Kubernetes 解决的是”容器编排”这个核心问题。但真实业务还有更多需求：流量怎么治理、配置怎么版本化管理、集群怎么跨地域扩展。

这些需求，社区和厂商用各种扩展填上了。它们绝大多数都遵循 k8s 的套路：声明式 API、控制器模式、自定义资源（CRD）。所以你学过的概念，在生态里一样通用。

65-2 服务网格（Service Mesh）

微服务多了以后，服务之间怎么调用、怎么做限流熔断、怎么加密通信，靠应用自己写很累。服务网格把这些问题下沉到基础设施层。

它的典型做法：给每个 Pod 注入一个”边车”（sidecar）代理，所有流量都从代理过。这样应用代码完全不用改，治理能力却统一了。

# 以 Istio 为例，给命名空间开启自动注入
kubectl label namespace default istio-injection=enabled

# 查看注入的边车代理
kubectl get pods -n default

其他常见选择还有 Linkerd（轻量、易上手）和 Cilium Service Mesh（基于 eBPF，性能出色）。对大多数团队，先理解”为什么需要网格”，比急着上手更重要。

65-3 GitOps 与 Argo CD

传统部署是”人敲命令 push 到集群”。GitOps 反过来：把集群的期望状态写进 Git 仓库，由一个控制器持续比对、自动把集群拉向 Git 里的状态。

好处很明显：Git 就是唯一真相源，所有变更可审计、可回滚。Argo CD 是这一领域的代表工具。

# 把 Git 仓库里的配置，同步到一个 Argo CD Application
argocd app create myapp \
  --repo https://github.com/your/repo.git \
  --path manifests \
  --dest-server https://kubernetes.default.svc

同类工具还有 Flux。它们不限于 k8s，但和 k8s 是天作之合。

65-4 边缘 k8s

标准的 k8s 集群，往往是几个配置很猛的数据中心节点。但边缘场景——工厂、门店、基站——节点又弱又分散、网络还时断时续。

于是出现了”轻量版”Kubernetes，把控制面做得更小，能跑在树莓派这种设备上：

• K3s：极简发行版，单二进制就能起集群，常被用在边缘和 IoT。
• KubeEdge：主打云边协同，把云端管控延伸到边缘节点。
• OpenYurt / 同类方案：在原版 k8s 上做”边缘化”改造，让中心集群能管住边缘。

# K3s 在边缘节点上的一键安装（示意）
curl -sfL https://get.k3s.io | sh -

65-5 多集群管理

当业务跨可用区、跨云、跨地域，一个集群就不够了。多集群要解决的是：怎么把应用分布到多个集群、怎么做故障转移、怎么统一管控。

常见思路有两种。一是”联邦”式，由一个中心统一编排多个集群；二是”独立部署”式，各集群自治，靠上层工具或 DNS 做流量分发。

65-6 其他值得关注的生态

生态太大，这里再点几个名字，你知道它们在哪一类就行：

• 可观测性：Prometheus（指标）、Loki（日志）、Tempo（链路追踪），常和 Grafana 配成”黄金三角”。
• 安全：OPA / Gatekeeper（策略校验）、SPIFFE / SPIRE（身份认证）。
• 存储：Rook（把 Ceph 等存储跑成 k8s 原生资源）、各类 CSI 驱动。
• 网络：Cilium（基于 eBPF，集网络、安全、可观测于一体）正快速普及。

65-7 怎么规划下一步

学到这里，建议按”先深后广”的节奏走：

1. 把前面 64 章的核心概念吃透，能在本地集群里验证。
2. 选一个你工作最相关的进阶方向，比如做微服务的先看服务网格。
3. 用真实小项目练手，而不是只读书。

一句话：k8s 不是终点，而是一张通往云原生世界的大门。门后面很大，慢慢逛。