云原生 on 吾爱主机

Headlamp Cluster API 插件发布：把多集群生命周期管理搬进 Kubernetes UI

Tue, 07 Jul 2026 09:06:20 +0800

6 月下旬 Kubernetes 官方博客介绍了 Headlamp Cluster API 插件：它把 Cluster API（CAPI）的集群、机器、控制平面和拓扑关系搬到 Headlamp 的图形界面里。对平台工程团队来说，这不是“再做一个 Kubernetes Dashboard”，而是把原本需要在多个 kubectl 命令、YAML、OwnerReference 和 Condition 之间来回切换的多集群排障流程，整理成更接近日常运维视角的可视化工作台。

本文基于 Kubernetes 官方博客、Cluster API 官方文档、Headlamp 插件文档以及插件仓库 README 做多源核验，整理它解决的问题、核心能力、落地前的检查项，以及团队应该如何把它纳入现有的多集群运维流程。

背景：Cluster API 强在声明式，弱在人工排障体验

Cluster API 是 Kubernetes SIG Cluster Lifecycle 下的项目，目标是用 Kubernetes 风格的 API 和控制器来管理 Kubernetes 集群生命周期。简单说，平台团队可以把“创建集群、升级控制面、扩缩容节点、替换机器模板”等动作表达成 Kubernetes 资源，让管理集群里的控制器去持续调谐。

典型资源包括：

Cluster：描述一个工作负载集群；
Machine、MachineSet、MachineDeployment：描述节点及其副本关系；
KubeadmControlPlane：描述基于 kubeadm 的控制平面；
KubeadmConfig：描述节点初始化或加入集群的 bootstrap 配置；
各云厂商或虚拟化平台的 Infrastructure Provider 资源。

这种模式的优点是自动化和可复现，但真实排障时仍然会遇到几个痛点：

关系链长：一个集群问题可能同时涉及 Cluster、ControlPlane、MachineDeployment、MachineSet、Machine、BootstrapConfig、InfrastructureMachine 等资源。
状态分散：健康度通常藏在 status.conditions、副本数字、事件、Provider 资源状态中。
命令切换频繁：排查时经常要反复执行 kubectl get、kubectl describe、kubectl get -o yaml，再靠人工拼 OwnerReference。
新成员学习成本高：不了解 CAPI 资源层级的人，很难快速判断“是控制面问题、节点问题、模板问题，还是 Provider 问题”。

Headlamp Cluster API 插件瞄准的正是这个体验层缺口。

这次插件带来了什么

根据 Kubernetes 官方博客和插件 README，这个插件会在 Headlamp 中新增一个专门的 Cluster API 区域，并围绕 CAPI 资源提供列表页、详情页、仪表盘和关系图。

1. 集群总览与健康仪表盘

插件提供集中化的 Cluster API Dashboard，用于汇总：

Cluster、Machine、MachineDeployment、MachinePool、MachineSet、ControlPlane 的状态；
控制面与工作节点副本数；
Provider、配置模板、资源健康情况；
当前存在的 Condition 异常与修复提示。

对平台团队来说，仪表盘的价值不是取代告警系统，而是把“告警之后进入问题现场”的第一屏做得更清楚。过去你可能需要先列出所有资源，再逐层查看；现在可以先从 Dashboard 判断故障落在哪个层级。

2. Machine 体系的可视化

插件为 MachineDeployment、MachineSet、Machine 和 MachinePool 提供专门视图，展示副本、版本、Owner 关系、Provider ID、Condition 等信息。

这对节点扩缩容和滚动升级尤其有用。例如：

kubectl get machinedeployments.cluster.x-k8s.io -A
kubectl get machines.cluster.x-k8s.io -A
kubectl describe machine <machine-name> -n <namespace>

这些命令仍然是自动化和深度排障的基础，但图形界面能更快暴露：哪个 MachineDeployment 没有达到期望副本数，哪些 Machine 没 Ready，资源之间的归属关系是否符合预期。

3. 直接从 UI 扩缩容

官方博客提到，插件支持对 MachineDeployments 和 MachineSets 执行 Scale 操作。也就是说，日常节点池扩缩容可以在 Headlamp 中完成，而不必每次手写 kubectl scale 或修改 YAML。

但这里要注意两点：

如果集群是 ClusterClass / topology 管理的，扩缩容入口可能应当在更高层级，而不是直接改底层 MachineSet；
UI 操作必须受 RBAC 控制，生产环境应限制谁能调整节点池规模。

建议团队把 UI 操作视为“人工运维入口”，而不是绕过 GitOps 的捷径。如果集群资源已经由 GitOps 管理，仍应优先从 Git 仓库修改声明式配置，Headlamp 用于观察和紧急诊断。

4. KubeadmConfig 结构化查看

在 CAPI 排障中，bootstrap 配置经常决定节点能不能正确加入集群。插件提供了对 KubeadmConfig 的结构化视图，可以查看文件、kubelet 参数、join/init 设置等内容。

这比直接阅读大段 YAML 更适合快速排查：

kubelet 参数是否和集群版本匹配；
bootstrap 文件是否缺失；
join 配置是否指向正确控制面；
是否存在模板更新但 Machine 未滚动的情况。

不过，结构化 UI 只能提升阅读效率，不能代替对敏感字段的权限治理。涉及 kubeconfig、证书、Token 的资源仍要按最小权限原则配置访问范围。

5. Map View：把 OwnerReference 变成关系图

CAPI 的核心难点之一是资源关系。Headlamp 的 Map View 可以显示 Cluster、ControlPlane、Worker 等资源之间的关系，让平台工程师不必手工追踪 OwnerReference。

在以下场景中，关系图特别有价值：

新集群创建卡住，需要定位卡在基础设施、控制面还是工作节点；
节点池升级后副本数异常，需要确认 MachineDeployment → MachineSet → Machine 的链路；
Provider 资源健康但 CAPI 资源未 Ready，需要确认引用关系是否断裂；
新成员学习 CAPI 架构，需要直观看到对象层级。

落地前的检查清单

如果你已经在用 Cluster API，可以按下面顺序评估是否引入该插件。

1. 确认 CAPI CRD 存在

kubectl get crd | grep cluster.x-k8s.io
kubectl get clusters.cluster.x-k8s.io -A
kubectl get machines.cluster.x-k8s.io -A

如果这些资源不存在，说明当前集群并不是 CAPI 管理集群，安装插件也看不到核心数据。

2. 确认 Headlamp 部署方式

Headlamp 可以以桌面应用、集群内服务或其他方式运行。对于生产环境，建议优先明确：

访问入口是否经过认证；
是否使用 OIDC 或企业身份系统；
ServiceAccount 是否按角色区分；
是否允许跨命名空间查看 CAPI 资源。

Headlamp 插件机制允许扩展侧边栏、资源详情页、仪表盘和业务逻辑，因此插件能力越强，越需要认真审计安装来源与权限边界。

3. 按 RBAC 分层授权

不要把所有 Headlamp 用户都绑定成 cluster-admin。可以按角色拆分：

角色	建议权限
观察者	只读查看 Cluster、Machine、Condition、事件
平台运维	可扩缩容 MachineDeployment / MachineSet
平台管理员	可安装插件、调整 Provider、执行升级相关动作

只读用户可以先验证 UI 的可观察性价值；有写权限的操作应纳入审计。

4. 与 GitOps 流程约定边界

如果 CAPI 资源由 Argo CD、Flux 或内部平台生成，UI 修改可能被下一次 GitOps 同步覆盖。建议明确三条规则：

常规变更走 Git；
UI 只用于观察、诊断和经过授权的紧急操作；
紧急操作后必须回写 Git，避免实际状态和声明状态长期漂移。

一个实用排障流程示例

假设某个工作负载集群扩容后节点迟迟未 Ready，可以这样组合使用 UI 与 CLI。

先在 Headlamp 的 Cluster API Dashboard 查看该 Cluster 是否有异常 Condition，确认问题集中在 worker 侧还是 control plane 侧。接着打开 MachineDeployment，检查期望副本与当前副本是否一致，再进入相关 MachineSet 和 Machine 页面查看具体状态。

如果 UI 显示某台 Machine 卡在 bootstrap 或 infrastructure 阶段，再回到 CLI 做深挖：

kubectl describe machine <machine-name> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp
kubectl get kubeadmconfig -n <namespace> -o yaml
kubectl get <provider-machine-resource> -n <namespace> -o yaml

这样做的好处是：先用 UI 缩小范围，再用 CLI 获取完整细节。排障路径会比一开始就从所有 YAML 中搜索更短。

对平台工程团队的影响

这类插件的意义不只是“好看”。它反映了 Kubernetes 平台工程的一个趋势：底层仍然保持声明式 API 和控制器模式，上层则需要更贴近人类操作习惯的可视化、关系图和上下文导航。

对团队来说，可以预期三类收益：

降低 CAPI 学习成本：新成员更容易理解 Cluster、Machine、ControlPlane 的关系；
缩短人工排障路径：状态聚合和 Map View 能减少重复命令；
提升操作一致性：常见动作如扩缩容被封装在界面中，减少手写 YAML 出错。

同时，也要警惕两类风险：

权限放大：可视化工具一旦具备写操作，就必须严控 RBAC；
流程分叉：UI 操作和 GitOps 声明式配置可能产生漂移，需要制度约束。

总结

Headlamp Cluster API 插件把 CAPI 的资源层级、健康状态、扩缩容动作和拓扑关系集中到 Kubernetes UI 中，适合已经使用 Cluster API 的平台团队试用。它不会替代 kubectl、GitOps 或告警系统，但能成为告警之后的第一诊断入口，让多集群生命周期管理从“读 YAML 拼关系”逐步走向“看状态、看关系、再深入验证”。

如果你的团队正在推进 CAPI、多云集群或自助式集群交付，建议先在测试环境启用该插件，以只读方式验证 Dashboard、资源详情页和 Map View 的价值，再逐步开放扩缩容等写操作。

参考资料

Kubernetes 官方博客：Introducing the Cluster API plugin for Headlamp（2026-06-25） https://kubernetes.io/blog/2026/06/25/headlamp-cluster-api-plugin/
Cluster API 官方文档：Introduction https://cluster-api.sigs.k8s.io/introduction
Headlamp 官方文档：Plugins https://headlamp.dev/docs/latest/development/plugins/
Headlamp 插件仓库：Cluster API Plugin README https://github.com/headlamp-k8s/plugins/blob/main/cluster-api/README.md

K3s 轻量级 Kubernetes 实战：安装、配置与生产部署

Thu, 25 Jun 2026 17:00:00 +0000

前言

K3s 是 Rancher（现为 SUSE 旗下）开源的轻量级 Kubernetes 发行版。它将 K8s 打包为一个不到 100MB 的二进制文件，资源占用极低，专为边缘计算、IoT、CI/CD 和资源受限环境设计。K3s 完全兼容标准 K8s API，是学习和部署 K8s 的绝佳选择。当前最新版本为 v1.36.2+k3s1（2026 年 6 月），内置 Kubernetes v1.36.2、Traefik v3.7.4、containerd v2.3.2。

1. K3s vs K8s 对比

对比项	K8s (kubeadm)	K3s
二进制大小	~1GB+	< 100MB
最低内存	2GB+	512MB
最低 CPU	2 核	1 核
默认存储	etcd	SQLite（可选 etcd/MySQL/PostgreSQL）
网络插件	Calico/Flannel 等	Flannel（内置）
Ingress	需单独安装	Traefik（内置）
安装时间	10-30 分钟	< 5 分钟
组件数量	多个独立组件	单一二进制
适用场景	大规模生产	边缘/IoT/轻量/学习
API 兼容性	100%	100% 完全兼容

2. 安装 K3s

2.1 Server 节点安装

# 最简安装（国内加速）
curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn sh -

# 使用阿里云镜像
curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \
 INSTALL_K3S_MIRROR=cn \
 K3S_TOKEN=mytoken \
 INSTALL_K3S_EXEC="--docker" \
 sh -

# 指定版本安装
curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \
 INSTALL_K3S_MIRROR=cn \
 INSTALL_K3S_VERSION=v1.28.4+k3s2 \
 sh -

# 使用外部数据库（高可用）
curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \
 K3S_DATASTORE_ENDPOINT="mysql://user:pass@tcp(mysql-host:3306)/k3s" \
 sh -

2.2 Agent 节点加入

# 获取 Server 节点的 token
cat /var/lib/rancher/k3s/server/node-token

# Agent 节点安装
curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \
 K3S_URL=https://server-ip:6443 \
 K3S_TOKEN=<node-token> \
 INSTALL_K3S_MIRROR=cn \
 sh -

2.3 验证安装

# 查看节点状态
kubectl get nodes

# 查看所有 Pod
kubectl get pods -A

# 查看 K3s 版本
k3s --version

# 查看 K3s 服务状态
systemctl status k3s
systemctl status k3s-agent

2.4 配置 kubectl

# Server 节点的 kubeconfig
cat /etc/rancher/k3s/k3s.yaml

# 复制到本地
mkdir -p ~/.kube
scp root@server-ip:/etc/rancher/k3s/k3s.yaml ~/.kube/config
chmod 600 ~/.kube/config

# 修改 server 地址（把 127.0.0.1 改为实际 IP）
sed -i 's/127.0.0.1/server-ip/g' ~/.kube/config

# 验证
kubectl get nodes

3. 安装选项

3.1 Server 安装参数

curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \
 INSTALL_K3S_MIRROR=cn \
 INSTALL_K3S_EXEC="server" \
 sh -s - \
 --write-kubeconfig-mode 644 \  # kubeconfig 文件权限
 --disable traefik \  # 禁用内置 Traefik
 --disable servicelb \  # 禁用内置 ServiceLB
 --datastore-endpoint "..." \  # 外部数据库
 --tls-san "my-k3s.example.com" \  # 额外的 TLS SAN
 --node-label "env=production" \  # 节点标签
 --node-taint "key=value:NoSchedule" \ # 节点污点
 --docker # 使用 Docker 而非 containerd

3.2 常用环境变量

# 安装脚本环境变量
INSTALL_K3S_MIRROR=cn # 使用国内镜像
INSTALL_K3S_VERSION=v1.28.4+k3s2 # 指定版本
INSTALL_K3S_EXEC="server" # server 或 agent
K3S_TOKEN=mytoken # 集群 token
K3S_URL=https://server:6443 # Agent 连接 Server 的地址
INSTALL_K3S_SKIP_START=true # 只安装不启动
INSTALL_K3S_SKIP_DOWNLOAD=true # 使用本地二进制

# K3s 运行时环境变量
K3S_KUBECONFIG_MODE=644
K3S_TOKEN=mytoken
K3S_DATASTORE_ENDPOINT=mysql://...

4. 卸载与重装

# 卸载 Server
/usr/local/bin/k3s-uninstall.sh

# 卸载 Agent
/usr/local/bin/k3s-agent-uninstall.sh

# 清理残留
rm -rf /etc/rancher/k3s
rm -rf /var/lib/rancher/k3s
rm -rf /var/lib/rancher/k3s/server/manifests

5. 高可用部署

5.1 架构方案

┌──────────────────────────────────────────┐
│ Load Balancer │
│ (nginx/haproxy/cloud LB) │
└────────┬────────────┬────────────┬───────┘
 │ │ │
 ┌────▼────┐ ┌────▼────┐ ┌────▼────┐
 │ Server 1│ │ Server 2│ │ Server 3│
 │ (etcd) │ │ (etcd) │ │ (etcd) │
 └─────────┘ └─────────┘ └─────────┘
 │ │ │
 ┌────▼────┐ ┌────▼────┐ ┌────▼────┐
 │ Agent 1 │ │ Agent 2 │ │ Agent 3 │
 └─────────┘ └─────────┘ └─────────┘

5.2 使用嵌入式 etcd（推荐）

# 第一个 Server 节点（初始化集群）
curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \
 INSTALL_K3S_MIRROR=cn \
 INSTALL_K3S_EXEC="server --cluster-init" \
 sh -

# 后续 Server 节点（加入集群）
curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \
 K3S_TOKEN=<token> \
 INSTALL_K3S_MIRROR=cn \
 INSTALL_K3S_EXEC="server --server https://first-server-ip:6443" \
 sh -

# 查看 etcd 状态
k3s etcd-snapshot list

5.3 使用外部数据库

# 使用 MySQL
curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \
 K3S_DATASTORE_ENDPOINT="mysql://k3s:password@tcp(mysql-host:3306)/k3s" \
 sh -

# 使用 PostgreSQL
curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \
 K3S_DATASTORE_ENDPOINT="postgres://k3s:password@postgres-host:5432/k3s?sslmode=disable" \
 sh -

6. 网络配置

6.1 Flannel 配置

# 查看 Flannel 网络
ip addr show flannel.1

# 自定义 Pod CIDR
k3s server --cluster-cidr=10.42.0.0/16 --service-cidr=10.43.0.0/16

# 使用其他后端（vxlan/host-gw/wireguard）
k3s server --flannel-backend=host-gw

6.2 替换 Flannel 为 Calico

# 安装时禁用 Flannel
k3s server --flannel-backend=none --disable-network-policy

# 安装 Calico
kubectl apply -f https://projectcalico.docs.tigera.io/manifests/calico.yaml

6.3 ServiceLB（内置负载均衡）

# K3s 内置 ServiceLB（原 klipper-lb）
# 创建 LoadBalancer 类型的 Service 会自动分配 IP

# 查看 ServiceLB 状态
kubectl get pods -n kube-system | grep svclb

# 禁用 ServiceLB（使用 MetalLB 等替代）
k3s server --disable servicelb

7. 存储配置

7.1 本地路径存储（默认）

# K3s 默认提供 local-path StorageClass
kubectl get storageclass

# 使用默认 StorageClass
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: my-pvc
spec:
 accessModes:
 - ReadWriteOnce
 storageClassName: local-path
 resources:
 requests:
 storage: 1Gi

# 自定义本地路径
k3s server --default-local-storage-path=/data/k3s-storage

7.2 NFS 存储

# 安装 NFS CSI Driver
helm repo add csi-driver-nfs https://raw.githubusercontent.com/kubernetes-csi/csi-driver-nfs/master/charts
helm install csi-driver-nfs csi-driver-nfs/csi-driver-nfs --namespace kube-system

# 创建 StorageClass
cat <<EOF | kubectl apply -f -
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: nfs-csi
provisioner: nfs.csi.k8s.io
parameters:
 server: nfs-server-ip
 share: /exported/path
reclaimPolicy: Retain
volumeBindingMode: Immediate
EOF

8. Ingress 配置

8.1 Traefik（内置）

# K3s 默认安装 Traefik 作为 Ingress Controller
kubectl get pods -n kube-system | grep traefik

# 查看 Traefik IngressClass
kubectl get ingressclass

# 使用 Traefik Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: myapp-ingress
 annotations:
 traefik.ingress.kubernetes.io/router.entrypoints: web
spec:
 rules:
 - host: app.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: myapp-svc
 port:
 number: 80

8.2 禁用 Traefik，使用 Nginx Ingress

# 安装时禁用 Traefik
k3s server --disable traefik

# 安装 Nginx Ingress Controller
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.9.0/deploy/static/provider/baremetal/deploy.yaml

9. Helm 集成

# 安装 Helm（K3s 已内置 HelmChart CRD）
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# 使用 HelmChart 自定义资源部署
cat <<EOF | kubectl apply -f -
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
 name: prometheus
 namespace: kube-system
spec:
 chart: prometheus
 repo: https://prometheus-community.github.io/helm-charts
 set:
 server.global.scrape_interval: 15s
EOF

10. 日常运维命令

# 查看集群状态
kubectl get nodes -o wide
kubectl get pods -A
kubectl top nodes
kubectl top pods -A

# K3s 特有命令
k3s --help
k3s check-config # 检查系统配置
k3s certificate # 管理证书
k3s etcd-snapshot save # 备份 etcd
k3s etcd-snapshot restore # 恢复 etcd

# 查看 K3s 日志
journalctl -u k3s -f
journalctl -u k3s-agent -f

# 重启 K3s
systemctl restart k3s # Server 节点
systemctl restart k3s-agent # Agent 节点

# 更新 K3s
curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \
 INSTALL_K3S_MIRROR=cn \
 INSTALL_K3S_VERSION=v1.29.0+k3s1 \
 sh -

11. 与 K8s 的差异点

差异	K3s	K8s
默认容器运行时	containerd	containerd
默认 CNI	Flannel	无（需手动安装）
默认 Ingress	Traefik	无（需手动安装）
默认存储	local-path	无（需手动配置）
默认 LB	ServiceLB	无（需 MetalLB 等）
etcd 备份	k3s etcd-snapshot	etcdctl snapshot
配置文件	/etc/rancher/k3s/config.yaml	各组件独立配置

12. 适用场景

场景	推荐度	说明
本地学习 K8s	⭐⭐⭐⭐⭐	安装简单，资源占用低
边缘计算	⭐⭐⭐⭐⭐	专为边缘设计
IoT 设备管理	⭐⭐⭐⭐⭐	ARM 支持好
CI/CD 环境	⭐⭐⭐⭐	快速创建销毁
小型生产环境	⭐⭐⭐⭐	足够稳定
大规模生产	⭐⭐⭐	建议用完整 K8s 或托管服务
桌面开发	⭐⭐⭐⭐⭐	Docker Desktop K8s 的替代

总结

K3s 核心优势：

轻量 — 单一二进制，< 100MB，512MB 内存即可运行
简单 — 一条命令安装，< 5 分钟上手
完整 — 100% 兼容 K8s API，内置 Traefik/Flannel/ServiceLB
安全 — 自动轮换证书，CIS 加固
多数据库 — 支持 SQLite/etcd/MySQL/PostgreSQL
ARM 支持 — 原生支持 ARM64，适合树莓派等设备

如果你是 K8s 新手，或者需要在边缘设备、小型服务器上运行 K8s，K3s 是最佳选择。

Kubernetes (K8s) 完全指南：架构、核心概念与实战命令

Thu, 25 Jun 2026 16:30:00 +0000

前言

Kubernetes（简称 K8s）是 Google 开源的容器编排平台，已成为云原生领域的事实标准。当前最新版本为 v1.36（2026 年发布）。它能自动化容器化应用的部署、扩缩容和管理。无论是微服务架构、CI/CD 流水线，还是混合云部署，K8s 都是核心基础设施。

1. 架构概述

1.1 整体架构

┌─────────────────────────────────────────────────────┐
│ Control Plane │
│ ┌──────────┐ ┌──────────┐ ┌────────┐ ┌──────────┐ │
│ │ API │ │Scheduler │ │Controller│ │ etcd │ │
│ │ Server │ │ │ │ Manager │ │ │ │
│ └──────────┘ └──────────┘ └────────┘ └──────────┘ │
└─────────────────────────────────────────────────────┘
 │
 ┌───────────┼───────────┐
 ▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Worker 1 │ │ Worker 2 │ │ Worker 3 │
│ ┌──────────┐ │ │ ┌──────────┐ │ │ ┌──────────┐ │
│ │ kubelet │ │ │ │ kubelet │ │ │ │ kubelet │ │
│ ├──────────┤ │ │ ├──────────┤ │ │ ├──────────┤ │
│ │kube-proxy│ │ │ │kube-proxy│ │ │ │kube-proxy│ │
│ ├──────────┤ │ │ ├──────────┤ │ │ ├──────────┤ │
│ │Container │ │ │ │Container │ │ │ │Container │ │
│ │ Runtime │ │ │ │ Runtime │ │ │ │ Runtime │ │
│ └──────────┘ │ │ └──────────┘ │ │ └──────────┘ │
└──────────────┘ └──────────────┘ └──────────────┘

1.2 Control Plane 组件

组件	作用
API Server	集群的统一入口，所有操作通过 REST API 进行
etcd	分布式键值存储，保存集群的所有状态数据
Scheduler	监听未调度的 Pod，根据资源/亲和性等分配到合适的节点
Controller Manager	运行各种控制器（Deployment、ReplicaSet、Node 等），确保实际状态与期望状态一致

1.3 Worker Node 组件

组件	作用
kubelet	每个节点上的代理，管理 Pod 生命周期，汇报节点状态
kube-proxy	网络代理，实现 Service 的负载均衡和网络规则
Container Runtime	容器运行时（containerd、CRI-O 等）

2. 核心概念

2.1 Pod

Pod 是 K8s 最小的部署单元，包含一个或多个容器。

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
 name: my-pod
 labels:
 app: myapp
 version: v1
spec:
 containers:
 - name: nginx
 image: nginx:1.25
 ports:
 - containerPort: 80
 resources:
 requests:
 cpu: "100m"
 memory: "128Mi"
 limits:
 cpu: "500m"
 memory: "256Mi"
 livenessProbe:
 httpGet:
 path: /healthz
 port: 80
 initialDelaySeconds: 10
 periodSeconds: 5
 readinessProbe:
 httpGet:
 path: /ready
 port: 80
 initialDelaySeconds: 5
 periodSeconds: 3
 - name: sidecar
 image: busybox
 command: ["sh", "-c", "while true; do echo hello; sleep 10; done"]

2.2 Deployment

Deployment 管理 ReplicaSet，实现应用的声明式更新。

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: myapp
 namespace: default
spec:
 replicas: 3
 selector:
 matchLabels:
 app: myapp
 strategy:
 type: RollingUpdate
 rollingUpdate:
 maxSurge: 1 # 滚动更新时最多多出 1 个 Pod
 maxUnavailable: 0 # 更新时不允许不可用
 template:
 metadata:
 labels:
 app: myapp
 spec:
 containers:
 - name: myapp
 image: myapp:1.0
 ports:
 - containerPort: 8080
 env:
 - name: DB_HOST
 valueFrom:
 configMapKeyRef:
 name: myconfig
 key: db_host
 - name: DB_PASSWORD
 valueFrom:
 secretKeyRef:
 name: mysecret
 key: db_password
 resources:
 requests:
 cpu: "250m"
 memory: "256Mi"
 limits:
 cpu: "1"
 memory: "512Mi"

2.3 Service

Service 为 Pod 提供稳定的网络访问入口。

# ClusterIP（集群内部访问）
apiVersion: v1
kind: Service
metadata:
 name: myapp-svc
spec:
 type: ClusterIP
 selector:
 app: myapp
 ports:
 - port: 80
 targetPort: 8080
 protocol: TCP

---
# NodePort（外部通过节点端口访问）
apiVersion: v1
kind: Service
metadata:
 name: myapp-nodeport
spec:
 type: NodePort
 selector:
 app: myapp
 ports:
 - port: 80
 targetPort: 8080
 nodePort: 30080 # 外部通过 <NodeIP>:30080 访问

---
# LoadBalancer（云厂商负载均衡）
apiVersion: v1
kind: Service
metadata:
 name: myapp-lb
spec:
 type: LoadBalancer
 selector:
 app: myapp
 ports:
 - port: 80
 targetPort: 8080

2.4 Ingress

Ingress 管理外部对集群服务的 HTTP/HTTPS 访问。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: myapp-ingress
 annotations:
 nginx.ingress.kubernetes.io/rewrite-target: /
 cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
 ingressClassName: nginx
 tls:
 - hosts:
 - app.example.com
 secretName: app-tls
 rules:
 - host: app.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: myapp-svc
 port:
 number: 80
 - path: /api
 pathType: Prefix
 backend:
 service:
 name: api-svc
 port:
 number: 8080

2.5 ConfigMap 和 Secret

# ConfigMap - 存储配置数据
apiVersion: v1
kind: ConfigMap
metadata:
 name: myconfig
data:
 db_host: "mysql.default.svc.cluster.local"
 db_port: "3306"
 app.properties: |
 server.port=8080
 logging.level=INFO

---
# Secret - 存储敏感数据（base64 编码）
apiVersion: v1
kind: Secret
metadata:
 name: mysecret
type: Opaque
data:
 db_password: cGFzc3dvcmQxMjM=  # echo -n 'password123' | base64
 api_key: c2VjcmV0a2V5

2.6 其他核心资源

# StatefulSet - 有状态应用（数据库、消息队列）
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: mysql
spec:
 serviceName: "mysql"
 replicas: 3
 selector:
 matchLabels:
 app: mysql
 template:
 metadata:
 labels:
 app: mysql
 spec:
 containers:
 - name: mysql
 image: mysql:8.0
 volumeMounts:
 - name: data
 mountPath: /var/lib/mysql
 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes: ["ReadWriteOnce"]
 resources:
 requests:
 storage: 10Gi

---
# DaemonSet - 每个节点运行一个 Pod
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: log-agent
spec:
 selector:
 matchLabels:
 app: log-agent
 template:
 metadata:
 labels:
 app: log-agent
 spec:
 containers:
 - name: fluentd
 image: fluentd:latest

---
# CronJob - 定时任务
apiVersion: batch/v1
kind: CronJob
metadata:
 name: backup
spec:
 schedule: "0 2 * * *" # 每天凌晨 2 点
 jobTemplate:
 spec:
 template:
 spec:
 containers:
 - name: backup
 image: backup-tool:latest
 command: ["/bin/sh", "-c", "run-backup.sh"]
 restartPolicy: OnFailure

3. 常用 kubectl 命令

3.1 集群信息

# 集群信息
kubectl cluster-info
kubectl get nodes
kubectl get nodes -o wide # 详细信息
kubectl describe node <node-name>

# 查看所有资源
kubectl get all -A # 所有命名空间
kubectl get all -n kube-system # 指定命名空间

3.2 资源管理

# 创建资源
kubectl apply -f deployment.yaml
kubectl create namespace my-ns
kubectl create configmap myconfig --from-file=config.properties
kubectl create secret generic mysecret --from-literal=password=123

# 查看资源
kubectl get pods
kubectl get pods -o wide # 显示 IP 和节点
kubectl get pods --show-labels # 显示标签
kubectl get pods -l app=myapp # 按标签过滤
kubectl get pods -A # 所有命名空间
kubectl get pods -w # 实时监听变化
kubectl get pods --field-selector=status.phase=Running

kubectl get svc
kubectl get deploy
kubectl get ingress
kubectl get configmap
kubectl get secret
kubectl get pvc # 持久卷声明
kubectl get events --sort-by='.lastTimestamp'

# 查看详情
kubectl describe pod <pod-name>
kubectl describe svc <svc-name>
kubectl describe node <node-name>

# 删除资源
kubectl delete pod <pod-name>
kubectl delete -f deployment.yaml
kubectl delete pods --all # 删除所有 Pod
kubectl delete pods --all -n my-ns

3.3 部署与更新

# 滚动更新
kubectl set image deployment/myapp myapp=myapp:2.0
kubectl apply -f deployment.yaml # 声明式更新

# 查看更新状态
kubectl rollout status deployment/myapp
kubectl rollout history deployment/myapp

# 回滚
kubectl rollout undo deployment/myapp # 回到上一个版本
kubectl rollout undo deployment/myapp --to-revision=2 # 回到指定版本

# 扩缩容
kubectl scale deployment/myapp --replicas=5
kubectl autoscale deployment/myapp --min=3 --max=10 --cpu-percent=80

3.4 调试与日志

# 查看日志
kubectl logs <pod-name>
kubectl logs <pod-name> -f # 实时追踪
kubectl logs <pod-name> --tail=100 # 最后 100 行
kubectl logs <pod-name> -c <container> # 多容器 Pod 指定容器
kubectl logs -l app=myapp # 按标签查看日志
kubectl logs --previous # 查看上次崩溃的日志

# 进入容器
kubectl exec -it <pod-name> -- /bin/bash
kubectl exec -it <pod-name> -c <container> -- /bin/sh

# 端口转发
kubectl port-forward <pod-name> 8080:80
kubectl port-forward svc/myapp-svc 8080:80

# 文件复制
kubectl cp <pod-name>:/path/file ./file
kubectl cp ./file <pod-name>:/path/file

# 查看 Pod 事件
kubectl get events --field-selector involvedObject.name=<pod-name>

# 调试 Pod（临时容器）
kubectl debug <pod-name> -it --image=busybox

3.5 命名空间管理

kubectl get namespaces
kubectl create namespace dev
kubectl config set-context --current --namespace=dev # 切换默认命名空间
kubectl delete namespace dev

4. 网络模型

4.1 Service 类型对比

类型	访问范围	使用场景
ClusterIP	集群内部	微服务间通信（默认）
NodePort	外部通过节点IP:Port	开发测试
LoadBalancer	云厂商 LB	生产环境
ExternalName	DNS CNAME	引用外部服务

4.2 网络策略

# 只允许同命名空间中 label 为 role=frontend 的 Pod 访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: allow-frontend
 namespace: production
spec:
 podSelector:
 matchLabels:
 app: backend
 policyTypes:
 - Ingress
 ingress:
 - from:
 - podSelector:
 matchLabels:
 role: frontend
 ports:
 - port: 8080

5. 存储

5.1 PersistentVolume 与 PVC

# PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
 name: my-pv
spec:
 capacity:
 storage: 10Gi
 accessModes:
 - ReadWriteOnce
 storageClassName: standard
 hostPath:
 path: /data/pv

---
# PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: my-pvc
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 5Gi
 storageClassName: standard

---
# 在 Pod 中使用
spec:
 containers:
 - name: app
 volumeMounts:
 - name: data
 mountPath: /data
 volumes:
 - name: data
 persistentVolumeClaim:
 claimName: my-pvc

5.2 StorageClass（动态供给）

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: fast
provisioner: kubernetes.io/aws-ebs
parameters:
 type: gp3
 iopsPerGB: "10"
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

6. RBAC 权限管理

# 创建角色
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: dev
 name: pod-reader
rules:
 - apiGroups: [""]
 resources: ["pods", "pods/log"]
 verbs: ["get", "list", "watch"]
 - apiGroups: ["apps"]
 resources: ["deployments"]
 verbs: ["get", "list"]

---
# 绑定角色到用户
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: read-pods
 namespace: dev
subjects:
 - kind: User
 name: developer
 apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role
 name: pod-reader
 apiGroup: rbac.authorization.k8s.io

7. 集群搭建方式

方式	适用场景	复杂度
minikube	本地学习开发	⭐
kind	CI/CD 测试	⭐⭐
kubeadm	生产部署	⭐⭐⭐
k3s	边缘/IoT/轻量	⭐⭐
托管服务	EKS/AKS/GKE	⭐⭐

8. 生产最佳实践

资源限制 — 始终设置 requests 和 limits
健康检查 — 配置 livenessProbe 和 readinessProbe
副本数 — 至少 2 个副本保证高可用
滚动更新 — 设置合理的 maxSurge 和 maxUnavailable
命名空间隔离 — 按环境（dev/staging/prod）分命名空间
网络策略 — 限制 Pod 间不必要的通信
RBAC — 最小权限原则
监控告警 — Prometheus + Grafana
日志收集 — EFK/Loki 栈
备份 etcd — 定期备份集群状态

总结

K8s 核心知识点：

架构 — Control Plane + Worker Node
Pod — 最小部署单元
Deployment — 无状态应用管理，滚动更新
Service — 为 Pod 提供稳定访问入口
Ingress — HTTP/HTTPS 路由
ConfigMap/Secret — 配置与敏感数据管理
StatefulSet — 有状态应用
PV/PVC — 持久化存储
RBAC — 权限控制
kubectl — 集群操作的核心命令