第四部分 K8s 辅助工具生态

kubectl 是 Kubernetes 运维的"瑞士军刀"，但真正的资深工程师从不只靠一把刀。本部分系统梳理 Kubernetes 生态中最常用、最实用的辅助工具——从终端效率、可视化、AI 辅助诊断，到安全扫描、备份迁移、GitOps、成本容量与本地调试。每个工具都遵循"简介 → 安装 → 核心用法 → 实战案例 → 最佳实践"的结构，所有命令均基于主流稳定版本，可直接在 RKE2（K8s v1.28+）环境中验证。建议读者不要贪多求全，而是对照每章末尾的"选型建议表"和篇末的"工具箱速查表"，为自己打造一套顺手的工具组合。

适用环境：Linux 运维工程师，Kubernetes v1.28+，RKE2 集群。

RKE2 环境提示：RKE2 的 kubeconfig 默认位于 /etc/rancher/rke2/rke2.yaml，kubectl 位于 /var/lib/rancher/rke2/bin/kubectl。本教材假设你已做好如下配置，后续不再赘述：
bash
sudo ln -sf /var/lib/rancher/rke2/bin/kubectl /usr/local/bin/kubectl
mkdir -p ~/.kube
sudo cp /etc/rancher/rke2/rke2.yaml ~/.kube/config
sudo chown $(id -u):$(id -g) ~/.kube/config
chmod 600 ~/.kube/config

第 1 章终端效率工具
第 2 章集群可视化与管理
第 3 章 AI 辅助诊断（重点）
第 4 章集群健康检查与审计
第 5 章安全扫描
第 6 章备份与迁移
第 7 章 GitOps 与持续交付
第 8 章成本与容量
第 9 章网络与流量工具
第 10 章本地开发与调试
附录：运维工程师工具箱速查表

第 1 章终端效率工具

运维工程师 80% 的时间在终端里度过。本章介绍的工具能把你在终端里的重复劳动减少一半以上。

1.1 工具对比总览

工具	定位	安装方式	学习成本	推荐指数
krew	kubectl 插件管理器	官方脚本	★	★★★★★（必装）
kubectx / kubens	快速切换集群/命名空间	krew / 包管理器	★	★★★★★
k9s	终端 UI 全功能管理	二进制 / 包管理器	★★	★★★★★
stern	多 Pod 日志聚合	krew / 二进制	★	★★★★☆
kube-ps1	提示符显示当前集群/NS	脚本 source	★	★★★★☆
fzf	模糊查找（通用）	包管理器	★★	★★★★☆

1.2 krew：kubectl 插件管理器

简介：krew 是 CNCF 官方维护的 kubectl 插件包管理器，类似 apt/yum 之于 Linux。安装了 krew 之后，kubectl krew install xxx 即可一键安装 200+ 个插件（插件本质是命名为 kubectl-xxx 的二进制，安装后通过 kubectl xxx 调用）。

安装（Linux x86_64）：

bash

# 官方一键安装
(
  set -x; cd "$(mktemp -d)" &&
  OS="$(uname | tr '[:upper:]' '[:lower:]')" &&
  ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&
  KREW="krew-${OS}_${ARCH}" &&
  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&
  tar zxvf "${KREW}.tar.gz" &&
  ./"${KREW}" install krew
)

# 把 krew 的 bin 目录加入 PATH（写入 ~/.bashrc）
export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

核心用法：

bash

kubectl krew update              # 更新插件索引
kubectl krew search              # 列出所有可安装插件
kubectl krew search ctx          # 按关键字搜索
kubectl krew install ctx ns      # 安装插件（一次可装多个）
kubectl krew list                # 查看已安装插件
kubectl krew upgrade             # 升级全部插件
kubectl krew uninstall ctx       # 卸载

实战案例：运维一台新跳板机，一条命令配好常用插件集：

bash

kubectl krew install ctx ns stern neat tree access-matrix df-pv get-all images

常用插件	作用
ctx / ns	切换集群与命名空间
stern	多 Pod 日志聚合
neat	清理 kubectl get -o yaml 中的冗余字段
df-pv	查看 PV 磁盘用量（类似 df -h）
access-matrix	审计某资源的 RBAC 权限矩阵
images	列出集群中所有容器镜像
get-all	真正获取命名空间下"全部"资源

最佳实践：

插件索引来自 krew-index 仓库，定期 kubectl krew update && kubectl krew upgrade 保持最新。
生产跳板机上只装经过内部安全评审的插件；插件即二进制，拥有你 kubeconfig 的全部权限。
离线环境可直接下载插件二进制重命名为 kubectl-xxx 放入 PATH，效果与 krew 安装一致。

1.3 kubectx / kubens：多集群多命名空间切换

简介：kubectl config use-context 和 kubectl config set-context --current --namespace 又臭又长，kubectx / kubens 把它变成 4 个字母。多集群（生产/测试/灾备）运维场景下这是使用频率最高的工具，没有之一。

安装：

bash

kubectl krew install ctx ns
# 或者包管理器：brew install kubectx / dnf install kubectx

核心用法：

bash

kubectx                     # 列出所有 context
kubectx prod-cluster        # 切换到指定集群
kubectx -                   # 切回上一个 context（类似 cd -）
kubectx -c                  # 显示当前 context
kubectx prod=prod-cluster-long-name   # 起别名

kubens                      # 列出当前集群所有命名空间
kubens kube-system          # 切换当前命名空间
kubens -                    # 切回上一个命名空间

实战案例：某工程师管理 6 个集群，每天需要在生产与测试间切换几十次。使用 kubectx 后，切换从 15 秒缩短到 2 秒，配合 kubectx - 在两个集群间快速往返排查版本差异：

bash

kubectx prod && kubectl get deploy myapp -n biz
kubectx - && kubectl get deploy myapp -n biz   # 回到测试集群对比

最佳实践：

永远在切换后确认当前 context（配合 kube-ps1 在提示符上实时显示），避免"在生产集群误执行删除"这类重大事故。
给 context 起短而有意义的别名（prod / stg / dr），不要依赖长长的自动生成的名字。

1.4 k9s：终端 UI 管理工具

简介：k9s 是最流行的 Kubernetes 终端仪表盘，以 ncurses 风格界面实时展示集群资源，支持查看、编辑、删除、进容器、看日志、看事件等几乎所有日常操作。对习惯 vim 的工程师尤其友好。

安装：

bash

# 方式一：下载 release 二进制（以 v0.32.x 为例，请替换为最新版）
curl -fsSL https://github.com/derailed/k9s/releases/latest/download/k9s_Linux_amd64.tar.gz | tar xz
sudo mv k9s /usr/local/bin/

# 方式二：包管理器
brew install k9s            # macOS / Linux brew

启动：k9s（使用当前 kubeconfig context）。k9s -n myns 直接进入指定命名空间，k9s --context prod 指定集群。

核心用法（快捷键）：

快捷键	功能
`:pods` `:svc` `:deploy` `:node` `:ns` `:pv` `:crd`	冒号进入任意资源视图（支持缩写如 `:po`）
`/`	过滤当前视图
`0`~`9`	切换命名空间过滤（`0` 为全部命名空间）
`l`	查看选中 Pod 日志（`f` 开关 follow）
`s`	进入容器 shell
`d` / `y` / `e`	Describe / YAML / 编辑
`ctrl+d`	删除（有确认）
`shift+p` / `shift+f`	端口转发 / 端口转发对话框
`u`	回退到上一个视图
`q`	退出
`:xray deploy`	XRay：以树状图展示 Deployment 及其挂载的所有依赖（ConfigMap、Secret、PVC、SA 等）
`:pulses`	Pulse：集群实时动态仪表盘

皮肤（Skin）：k9s 配置文件位于 ~/.config/k9s/（新版 XDG 路径）。下载官方皮肤并启用：

bash

mkdir -p ~/.config/k9s/skins
curl -fsSL https://raw.githubusercontent.com/derailed/k9s/master/skins/catppuccin-mocha.yaml \
  -o ~/.config/k9s/skins/catppuccin-mocha.yaml

在 ~/.config/k9s/config.yaml 中设置：

yaml

k9s:
  ui:
    skin: catppuccin-mocha
    headless: false
    logoless: true

插件（Plugins）：编辑 ~/.config/k9s/plugins.yaml，例如一键跳转到 stern 日志视图：

yaml

plugins:
  stern:
    shortCut: Ctrl-L
    description: "Stern 聚合日志"
    scopes:
      - pods
    command: bash
    background: false
    args:
      - -c
      - "stern --context $CONTEXT -n $NAMESPACE $NAME | less -R"

XRay 实战案例：排查"Deployment 启动后 Pod 一直 Pending"。在 k9s 中输入 :xray deploy 找到该 Deployment，按回车逐层展开，直接看到它引用的 PVC 处于 Pending → 定位到 StorageClass 未配置的问题，整个过程不用敲一条 kubectl 命令。

最佳实践：

生产环境建议以只读 kubeconfig 使用 k9s，或在配置中关闭危险快捷键，避免误按 ctrl+d。
k9s 的刷新频率可调整（~/.config/k9s/config.yaml 中 refreshRate，默认 2 秒），大集群可调大以减轻 API Server 压力。

1.5 stern：多 Pod 日志聚合

简介：kubectl logs 一次只能看一个 Pod。stern 可以按 label、名称正则同时聚合几十上百个 Pod 的日志流，并用不同颜色区分，是排查微服务链路和滚动发布时的日志利器。

安装：

bash

kubectl krew install stern     # 之后用 kubectl stern
# 或下载二进制
curl -fsSL https://github.com/stern/stern/releases/latest/download/stern_linux_amd64.tar.gz | tar xz
sudo mv stern /usr/local/bin/

核心用法：

bash

stern myapp -n biz                      # 匹配名称含 myapp 的所有 Pod
stern -l app=myapp -n biz               # 按 label 选择（等价 --selector）
stern "frontend|backend" -n biz         # 正则匹配多个服务
stern myapp --since 15m                 # 只看最近 15 分钟
stern myapp --tail 50                   # 每个 Pod 先回显最后 50 行
stern myapp --exclude "healthz"         # 排除含关键字的行
stern myapp --include-container app     # 只含指定容器
stern myapp --timestamps                # 带时间戳输出（排查时序问题）
stern myapp -o json | jq .message       # 原始 JSON 输出后接 jq

实战案例：滚动发布新版本时实时监控全组 Pod 是否有异常：

bash

stern -l app=order-service -n biz --since 5m \
  --exclude "200 OK" --include "ERROR|Exception|panic"

一个窗口滚过整个 Deployment 的错误日志，发布有没有问题一目了然。

最佳实践：

大集群/大流量服务务必加 --since 或 --tail，避免历史日志刷屏。
stern 按 Pod 前缀着色，Pod 极多时可加 --no-follow 只抓快照。

1.6 kubectl 别名、自动补全、kube-ps1、fzf

自动补全与别名（写入 ~/.bashrc）：

bash

source <(kubectl completion bash)
alias k=kubectl
complete -o default -F __start_kubectl k

# 常用别名
alias kgp='kubectl get pods'
alias kgs='kubectl get svc'
alias kgd='kubectl get deploy'
alias kdp='kubectl describe pod'
alias kl='kubectl logs'
alias kx='kubectl exec -it'
alias kaf='kubectl apply -f'
alias kdf='kubectl delete -f'
alias kcn='kubectl config set-context --current --namespace'
alias kga='kubectl get all -o wide'

进阶技巧：export do="--dry-run=client -o yaml"，生成模板快人一步：

bash

k run tmp --image=busybox:1.36 $do -- sleep 3600 > /tmp/tmp-pod.yaml

kube-ps1：在 PS1 提示符中实时显示当前集群与命名空间，防止误操作生产：

bash

git clone https://github.com/jonmosco/kube-ps1.git ~/.kube-ps1
cat >> ~/.bashrc <<'EOF'
source ~/.kube-ps1/kube-ps1.sh
PS1='[\u@\h \W $(kube_ps1)]\$ '
EOF

fzf 模糊查找：安装 fzf 后（dnf install fzf / brew install fzf），结合 kubectl 实现交互式选择：

bash

# 模糊选一个 Pod 看日志
kubectl get pods -A --no-headers | fzf | awk '{print $1, $2}' | \
  xargs -n2 sh -c 'kubectl logs -n $0 $1'

# 模糊选一个 Pod 进 shell
kubectl get pods -A --no-headers | fzf | awk '{print $1, $2}' | \
  xargs -n2 sh -c 'kubectl exec -it -n $0 $1 -- sh'

实战案例：故障应急值班时，kube-ps1 红字显示 (⎈ |prod-cluster:kube-system)，工程师在敲 kubectl delete 前下意识瞄一眼提示符，避免一次生产事故——这类"低成本保险"值得每台跳板机标配。

最佳实践：

别名团队内部统一一份，写入共享 dotfiles 仓库，降低协作沟通成本。
自动补全对 zsh 用 source <(kubectl completion zsh) 并确保 compinit 已启用。

1.7 本章选型建议表

场景	首选	备选
多集群切换	kubectx	k9s `:ctx`
多命名空间切换	kubens	k9s 数字键
快速浏览/操作资源	k9s	kubectl + 别名
看日志（单服务多副本）	stern	k9s `l`
插件扩展能力	krew	手动二进制
防止误操作生产	kube-ps1	只读 kubeconfig
交互式选 Pod	fzf 管道	k9s 过滤

第 2 章集群可视化与管理

终端高效但不直观。给团队、给领导、给跨部门协作时，一个 Web 界面能省掉大量沟通成本。

2.1 工具对比总览

工具	形态	多集群	开源协议	特色	推荐指数
Lens	桌面客户端	强	免费（部分功能付费）	功能最全、生态成熟	★★★★☆
OpenLens	桌面客户端	强	MIT（社区构建）	Lens 的开源核心	★★★☆☆
Headlamp	Web/桌面	支持	Apache-2.0（CNCF）	插件化、可嵌入门户	★★★★☆
K8s Dashboard	Web	单集群	Apache-2.0（官方）	轻量、官方	★★★☆☆
Rancher	Web 平台	极强	Apache-2.0	企业级多集群生命周期管理	★★★★★

2.2 Lens / OpenLens

简介：Lens 号称 "Kubernetes IDE"，桌面客户端（Win/macOS/Linux），自动读取 kubeconfig 中所有集群，提供资源浏览、监控图表（内置 Prometheus 集成）、终端、日志、Helm 仓库管理等。OpenLens 是 Lens 开源核心的社区构建版本（Lens 本体在 2022 年后闭源部分功能，个人仍免费）。

安装：

bash

# Linux（Flatpak）
flatpak install flathub dev.k8slens.OpenLens
# 或到 https://k8slens.dev 下载 AppImage / rpm / deb

核心用法：添加 kubeconfig（File → Add Cluster）→ 左侧目录浏览 Workloads/Network/Storage → 节点页安装内置 metrics 查看 CPU/内存曲线 → 右键资源执行 Scale/Restart/Edit。

实战案例：新员工入职第一周不记 kubectl 命令，先用 Lens 浏览集群拓扑建立直观认识，两周后再过渡到 k9s/kubectl。

最佳实践：

Lens 使用你本地 kubeconfig 的权限，权限多大界面就能干多大的事——生产集群请用只读账号。
大集群关闭自动 metrics 采集可降低负载。

2.3 Headlamp

简介：CNCF Sandbox 项目，可部署在集群内（Web）或作为桌面应用，支持多集群，最大特色是插件体系——官方市场有 Flux、Karpenter、cert-manager 等插件，可以把 GitOps 状态直接嵌进 UI。

安装（集群内）：

bash

helm repo add headlamp https://headlamp-k8s.github.io/headlamp/
helm install headlamp headlamp/headlamp --namespace headlamp --create-namespace
# 端口转发访问
kubectl -n headlamp port-forward svc/headlamp 8080:80
# 创建访问 token
kubectl -n headlamp create token headlamp --duration=24h

浏览器打开 http://localhost:8080，粘贴 token 登录。

最佳实践：生产建议通过 Ingress + OIDC 认证暴露，不要长期依赖 port-forward 和 cluster-admin token。

2.4 Kubernetes Dashboard

简介：官方 Web UI，功能朴素但稳定可靠，适合"只在集群里装一个最基础的界面"的场景。v2.7+ 之后安装通过 Helm。

安装：

bash

helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard \
  --namespace kubernetes-dashboard --create-namespace

# 创建只读或管理员 ServiceAccount
kubectl -n kubernetes-dashboard create serviceaccount admin-user
kubectl create clusterrolebinding admin-user \
  --clusterrole=cluster-admin \
  --serviceaccount=kubernetes-dashboard:admin-user
kubectl -n kubernetes-dashboard create token admin-user --duration=24h
kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard-kong-proxy 8443:443

访问 https://localhost:8443，粘贴 token。

最佳实践：

切勿无鉴权暴露 Dashboard 到公网（历史上有大量因 Dashboard 暴露导致的挖矿入侵事件）。
长期使用建议 RBAC 细化到"只读 + 指定命名空间"。

2.5 Rancher（与 RKE2 集成要点）

简介：SUSE 开源的企业级多集群管理平台，与本教材的 RKE2 系出同门，是管理 RKE2 集群最顺手的可视化平台：集群生命周期管理（创建/升级/备份）、统一认证（AD/LDAP/OIDC）、项目与 RBAC、应用商店（Helm Chart）、监控告警（内置 Prometheus）、CIS 扫描（内置 kube-bench）一应俱全。

安装（独立管理面，建议放在单独的小集群或 Docker 上用于 POC）：

bash

# POC：单容器快速体验
docker run -d --restart=unless-stopped -p 80:80 -p 443:443 \
  --privileged rancher/rancher:v2.9.3

# 生产：Helm 安装到专用管理集群
helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
helm install rancher rancher-stable/rancher \
  --namespace cattle-system --create-namespace \
  --set hostname=rancher.example.com \
  --set replicas=3 \
  --set bootstrapPassword=xxx

RKE2 集成要点：

Rancher 可直接 provision 新的 RKE2 集群（通过 node driver 或自定义节点注册命令）。
已有 RKE2 集群用 Import 方式纳管：UI 生成注册命令，在目标集群执行 kubectl apply -f 即可安装 cattle-cluster-agent。
Rancher 纳管 RKE2 后，可在 UI 中直接升级 K8s 版本、编辑集群配置（cluster.yml 抽象）、配置 etcd 快照策略。
RKE2 的 CIS 加固 profile（cis-1.23 等）与 Rancher 内置 CIS 扫描报告互相印证。
Rancher 的 local 管理集群本身也可以是 RKE2，官方推荐架构。

实战案例：某企业 12 套 RKE2 集群（4 生产 / 8 测试），通过 Rancher 统一纳管：AD 登录 → 按项目分配命名空间配额 → 统一在 UI 触发 K8s 版本滚动升级 → CIS 扫描报告一键导出给安全团队。运维人力从 6 人降至 3 人。

最佳实践：

Rancher 管理面与业务集群分离部署；管理面做好 etcd 快照与 Velero 备份。
版本矩阵：Rancher 版本对可管理的 K8s 版本有支持范围，升级前先查官方支持矩阵。
不要在 Rancher 纳管的集群上手工改 Rancher 创建的资源（会被 agent 回滚）。

2.6 本章选型建议表

场景	首选	备选
个人桌面日常使用	Lens	OpenLens / k9s
团队共享 Web 界面	Headlamp	K8s Dashboard
企业多集群统一管理	Rancher	自建 Portal + Headlamp
嵌入 GitOps 状态展示	Headlamp 插件	ArgoCD UI
最小依赖临时排查	K8s Dashboard	kubectl port-forward + 任意

第 3 章 AI 辅助诊断（重点）

AI 辅助诊断是近两年 K8s 运维领域变化最大的方向。本章以 K8sGPT 为主线写深写透，并横向对比 kubectl-ai、HolmesGPT、botkube 等工具。

一句话理解 K8sGPT：它用一组"分析器（Analyzer）"扫描集群里的异常信号（Pod 状态、事件、资源配额、Service 无后端……），把结构化的异常上下文交给大模型，用人话解释"发生了什么、为什么、怎么修"。

3.1 K8sGPT 架构与原理

K8sGPT 是 CNCF Sandbox 项目，核心由三部分组成：

┌─────────────┐   异常信号   ┌──────────────┐   Prompt   ┌───────────────┐
│  Analyzers  │ ───────────→ │  AI Backend  │ ─────────→ │  自然语言诊断  │
│ (Pod/SVC/…) │  结构化上下文 │ (OpenAI/Ollama│  (可匿名化)  │  + 修复建议    │
└─────────────┘              │  /Bedrock/…)  │            └───────────────┘
                             └──────────────┘

Analyzer（分析器）：一组内置规则引擎（Pod、Service、Deployment、Node、PVC、Ingress、HPA、CronJob、NetworkPolicy、StatefulSet 等），通过 K8s API 发现异常（如 Pod CrashLoopBackOff、Service 无 Endpoint、PVC Pending）。Analyzer 本身是纯规则的，不依赖 AI——AI 只是负责"解释"。
AI Backend（AI 后端）：把 analyzer 产出的异常上下文（名称、命名空间、错误信息）包装成 Prompt 发送给 LLM，返回可读诊断。
Anonymizer（匿名化器）：在数据离开集群前，把敏感信息（Pod 名、IP、域名、密钥值等）替换为占位符，回来后再还原，解决"把集群内部信息发给公有 LLM"的数据安全问题。

两种部署形态：

CLI：本地/跳板机运行 k8sgpt analyze，面向人，按需执行。
Operator：部署在集群内持续扫描，结果写入 Result CRD，可与 Prometheus/Alertmanager/Slack 联动，面向平台。

3.2 安装 K8sGPT CLI

bash

# 方式一：二进制（推荐，Linux x86_64）
curl -fsSL https://github.com/k8sgpt-ai/k8sgpt/releases/latest/download/k8sgpt_linux_amd64.tar.gz | tar xz
sudo mv k8sgpt /usr/local/bin/

# 方式二：包管理器
brew install k8sgpt                 # brew
# dnf  copr enable atim/k8sgpt && dnf install k8sgpt   # Fedora/RHEL 系 copr

k8sgpt version
k8sgpt completion bash | sudo tee /etc/bash_completion.d/k8sgpt > /dev/null

3.3 Analyzer：扫描集群异常

K8sGPT 的分析器列表随版本演进，常见内置 analyzer：

Analyzer	检查内容举例
Pod	CrashLoopBackOff、ImagePullBackOff、OOMKilled、Pending 原因
Service	Service 无匹配 Endpoint（selector 与 Pod label 不符）
Deployment	副本数不达预期、ProgressDeadlineExceeded
ReplicaSet / StatefulSet	副本异常、更新卡住
Node	NotReady、资源压力（MemoryPressure/DiskPressure/PIDPressure）、污点
PersistentVolumeClaim	Pending、容量不足
Ingress	后端 Service 不存在、TLS Secret 缺失
HPA	指标获取失败、扩缩容异常
CronJob	调度失败、并发策略冲突
NetworkPolicy	过度阻断流量的常见配置错误
Log（可选）	从 Pod 日志中提取错误模式（实验性）

bash

# 查看当前可用的分析器与过滤器
k8sgpt filters list

3.4 接入 AI 后端

3.4.1 OpenAI（默认后端）

bash

k8sgpt auth add --backend openai --model gpt-4o --password <你的API_KEY>
# 非交互方式（CI/脚本）
k8sgpt auth add --backend openai --model gpt-4o --password "$OPENAI_API_KEY"

k8sgpt auth list        # 查看已配置后端
k8sgpt auth default -p openai   # 设为默认

3.4.2 Azure OpenAI

bash

k8sgpt auth add --backend azureopenai \
  --baseurl https://<你的资源名>.openai.azure.com/ \
  --engine <deployment名称> \
  --model gpt-4o \
  --password <AZURE_API_KEY>

3.4.3 Amazon Bedrock

bash

# 需要本机已配置好 AWS 凭证（~/.aws 或环境变量）且具有 bedrock:InvokeModel 权限
k8sgpt auth add --backend amazonbedrock \
  --model anthropic.claude-3-5-sonnet-20240620-v1:0
# 区域可通过环境变量指定
export AWS_REGION=us-east-1

3.4.4 Google Vertex AI / Gemini

bash

# Vertex AI：需要 GCP 凭证
k8sgpt auth add --backend googlevertexai --model gemini-1.5-pro

# 或直接走 Gemini API（google 后端）
k8sgpt auth add --backend google --model gemini-1.5-pro --password <GEMINI_API_KEY>

3.4.5 本地 Ollama（离线/私有环境首选）

bash

# 先在本地或内网 GPU 服务器安装并启动 Ollama
curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b        # 或 qwen2.5:14b 等中文更好的模型
ollama serve                   # 默认监听 127.0.0.1:11434

# K8sGPT 侧配置（注意：本地模型需要同时配置 embedding 模型）
k8sgpt auth add --backend localai \
  --baseurl http://127.0.0.1:11434/v1 \
  --model llama3.1:8b

说明：Ollama 提供 OpenAI 兼容 API（/v1），因此 K8sGPT 用 localai 后端类型指向它即可。不同版本对后端命名略有差异，可用 k8sgpt auth add --help 查看当前版本支持的 backend 列表。

3.4.6 自定义 OpenAI 兼容后端

任何提供 OpenAI 兼容接口的服务（vLLM、Xinference、one-api 网关、DeepSeek、通义等）都可接入：

bash

k8sgpt auth add --backend openai \
  --baseurl https://your-llm-gateway.example.com/v1 \
  --model your-model-name \
  --password <KEY>

3.4.7 匿名化（anonymize）数据脱敏

bash

# 单次分析开启匿名化
k8sgpt analyze --explain --anonymize

# 原理：发往 LLM 的文本中，敏感字段被替换为掩码
# 例如 Pod 名 payment-api-6f8b9d-x2abc → 占位符，返回后再还原展示

匿名化能掩盖名称类敏感信息，但不能保证日志/错误文本中内嵌的敏感数据（如连接串、token 片段）被完全清除——高合规环境仍建议使用本地模型。

3.5 `k8sgpt analyze` 用法详解

bash

# 基本分析（纯规则，不调 AI，零成本）
k8sgpt analyze

# 带 AI 解释（调用默认后端）
k8sgpt analyze --explain

# 指定过滤器（--filter 可多次指定，逗号分隔）
k8sgpt analyze --filter Pod --filter Service
k8sgpt analyze --explain --filter Pod,Deployment

# 指定命名空间
k8sgpt analyze --namespace biz --explain

# 输出为 JSON（便于管道与自动化）
k8sgpt analyze --explain --output json | jq '.problems'

# 匿名化 + 中文上下文提示
k8sgpt analyze --explain --anonymize

# 带详细元信息
k8sgpt analyze --explain --with-doc        # 附带官方文档链接（若支持）
k8sgpt analyze --backend ollama_backend --explain   # 临时指定后端

典型输出（节选）：

AI Provider: openai

0: Pod/biz/payment-api-6f8b9d-x2abc(payment-api)
- Error: Back-off pulling image "registry.example.com/payment-api:v2.3.1"
Error: 镜像拉取失败并进入退避重试。
Solution:
1. 确认镜像名与 tag 存在：crictl pull registry.example.com/payment-api:v2.3.1
2. 检查节点到镜像仓库的网络与认证（imagePullSecret 是否配置到 ServiceAccount）。
3. RKE2 环境检查 /etc/rancher/rke2/registries.yaml 中的仓库认证配置。

实战案例：值班排障一条龙

bash

# 1. 凌晨收到告警，先纯规则扫一遍（秒出结果，不花 token）
k8sgpt analyze --namespace biz

# 2. 有异常，开启 AI 解释并导出报告给群
k8sgpt analyze --namespace biz --explain --output json > /tmp/diag.json
jq -r '.results[] | "\(.kind)/\(.name): \(.error)\n  建议: \(.details)\n"' /tmp/diag.json

3.6 Integration（集成模式）

K8sGPT 支持与第三方工具联动，把它们的扫描结果也纳入 AI 解释范围：

bash

# 查看可用集成
k8sgpt integration list

# 激活 Trivy 集成（要求集群已装 trivy-operator 或本地有 trivy）
k8sgpt integration activate trivy

# 激活 Prometheus 集成（让 AI 结合监控指标分析）
k8sgpt integration activate prometheus

# 分析时自动包含集成数据
k8sgpt analyze --explain --filter VulnerabilityReport
k8sgpt analyze --explain --filter Prometheus

Trivy 集成：读取集群内 VulnerabilityReport CR（由 trivy-operator 产生），AI 解释 CVE 风险与修复优先级。
Prometheus 集成：结合指标异常（如 OOM 前的内存爬升曲线）给出根因推断。

3.7 K8sGPT Operator 与 Result CRD

简介：Operator 把 analyze 能力常驻集群：周期扫描 → 生成 Result CR → 可通过 metrics 暴露给 Prometheus → 触发告警与通知。

安装：

bash

helm repo add k8sgpt https://charts.k8sgpt.ai/
helm install k8sgpt-operator k8sgpt/k8sgpt-operator \
  --namespace k8sgpt-operator-system --create-namespace

# 创建存放 API key 的 Secret
kubectl create secret generic k8sgpt-sample-secret \
  --from-literal=openai-api-key=$OPENAI_API_KEY -n k8sgpt-operator-system

# 创建 K8sGPT 自定义资源
kubectl apply -f - <<'EOF'
apiVersion: core.k8sgpt.ai/v1alpha1
kind: K8sGPT
metadata:
  name: k8sgpt-sample
  namespace: k8sgpt-operator-system
spec:
  ai:
    enabled: true
    model: gpt-4o
    backend: openai
    secret:
      name: k8sgpt-sample-secret
      key: openai-api-key
    # anonymized: true
  noCache: false
  repository: ghcr.io/k8sgpt-ai/k8sgpt
  version: v0.4.17
EOF

查看结果：

bash

# Operator 周期性分析，产出 Result CR
kubectl get results -n k8sgpt-operator-system
kubectl describe result <name> -n k8sgpt-operator-system

# Result 同时以 Prometheus 指标暴露（k8sgpt_results_total 等），
# 可在 Grafana 建"集群健康异常数"面板，或用 Alertmanager 告警

3.8 完整实战：离线/私有环境用 Ollama 跑 K8sGPT

背景：金融客户内网环境，集群信息严禁出网，公有 LLM 全部禁用。目标：用本地大模型实现 K8sGPT 智能诊断。

拓扑：GPU 服务器（10.0.10.20，跑 Ollama）←→ 运维跳板机（跑 K8sGPT CLI）。

步骤：

bash

# ==== GPU 服务器（10.0.10.20）====
# 1. 离线安装 Ollama：在有网机器下载 ollama-linux-amd64.tgz 与模型文件后拷入
tar -C /usr/local -xzf ollama-linux-amd64.tgz
useradd -r -s /bin/false ollama
# 配置 systemd，绑定到内网地址
cat > /etc/systemd/system/ollama.service <<'EOF'
[Unit]
Description=Ollama Service
After=network.target
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_MODELS=/data/ollama/models"
ExecStart=/usr/local/bin/ollama serve
User=ollama
Restart=always
[Install]
WantedBy=multi-user.target
EOF
systemctl enable --now ollama

# 2. 导入离线模型（有网机器执行 ollama pull 后，复制 /data/ollama/models 目录即可）
ollama list        # 确认 qwen2.5:14b 已就位

# ==== 运维跳板机 ====
# 3. 安装 K8sGPT 并指向内网 Ollama
k8sgpt auth add --backend localai \
  --baseurl http://10.0.10.20:11434/v1 \
  --model qwen2.5:14b

# 4. 验证：故意制造一个故障
kubectl run broken --image=nginx:nonexistent-tag -n test
k8sgpt analyze --filter Pod -n test --explain
# 输出（中文模型效果）：
# Error: Back-off pulling image "nginx:nonexistent-tag"
# 解释：Pod 无法拉取指定镜像……建议：1. 检查镜像 tag 是否存在；2. ……

# 5. 防火墙加固：仅允许跳板机访问 11434
firewall-cmd --permanent --new-zone=llm
firewall-cmd --permanent --zone=llm --add-source=10.0.10.0/24
firewall-cmd --permanent --zone=llm --add-port=11434/tcp
firewall-cmd --reload

经验总结：

7B~14B 级别本地模型对"K8s 常见故障解释"已够用；中文场景推荐 Qwen 系列。
离线模型分发：Ollama 模型目录可直接打包拷贝，注意 blob 目录完整性。
无 GPU 时可用 CPU 推理（速度下降明显，analyze 单次可接受约 30~60 秒）。

3.9 与 Prometheus Alertmanager 联动的思路

K8sGPT 本身不替代监控，而是给监控"加解释"。常见联动架构：

Prometheus 告警 ──→ Alertmanager ──→ Webhook（自研小服务）
                                         │
                                         ├─→ 调 k8sgpt analyze --filter Pod -n <ns> --output json
                                         ├─→ 拼接 AI 解释
                                         └─→ 发送到 IM（钉钉/企微/Slack）或写回工单

要点：

Alertmanager 配置 webhook receiver，告警触发时 POST 到自研服务。
自研服务收到告警后，以 --namespace + --filter 缩小范围调用 K8sGPT（控制 token 成本与时延）。
把"原始告警 + K8sGPT 诊断 + 建议命令"渲染成卡片推送值班群。
Operator 形态下也可直接对 k8sgpt_results_total 指标建告警，实现"异常对象数 > 0 即通知"。

进阶：Robusta（见第 8 章）和 HolmesGPT（见 3.10）已经把上述链路产品化，不想自研可以直接用。

3.10 其他 AI 辅助工具对比

工具	出品方	定位	交互方式	特点
K8sGPT	CNCF 社区	集群异常诊断	CLI / Operator	Analyzer 规则 + LLM 解释，生态最成熟
kubectl-ai	Google	自然语言生成 kubectl 命令	CLI 插件	"帮我列出所有 pending pod" → 生成并确认执行命令
HolmesGPT	Robusta	告警根因分析（RCA）	Webhook/CLI	结合告警 + 日志 + 指标做深度根因推理，可接 Robusta SaaS
botkube + AI	Kubeshop	IM 内 ChatOps 助手	Slack/企微机器人	在聊天频道执行 kubectl、收告警、AI 问答

kubectl-ai 简介与用法：

bash

# 安装（Go 安装或下载 release；需配置 GEMINI_API_KEY，也兼容其他 OpenAI 接口）
go install github.com/GoogleCloudPlatform/kubectl-ai/cmd/kubectl-ai@latest
export GEMINI_API_KEY=<key>

# 用法：自然语言 → 命令
kubectl-ai "把 biz 命名空间下所有 CrashLoopBackOff 的 pod 删掉前先列出名字"
# 工具会生成 kubectl 命令并请求确认后执行

HolmesGPT 简介：Robusta 开源的告警调查 Agent，接收告警后自动执行 runbook 式的排查（查事件、查日志、查指标），输出根因报告。可与 Alertmanager webhook 对接，支持 OpenAI/Azure/Bedrock 等后端。

botkube 简介：IM 机器人网关，把 kubectl 执行能力和告警通知搬进 Slack/Mattermost/钉钉（通过插件）；新版本加入 AI 助手，可在频道里 @botkube 用自然语言问集群问题。

选型建议：

想要"告诉我集群哪里坏了、怎么修" → K8sGPT。
想要"帮我生成/执行 kubectl 命令" → kubectl-ai。
想要"告警来了自动调查并给报告" → HolmesGPT（或 Robusta）。
想要"在群里就能操作集群 + AI 问答" → botkube。

3.11 K8sGPT 最佳实践

API Key 管理：
- 绝不写入 Git；用环境变量或集群 Secret（Operator 模式）。
- 为 K8sGPT 单独申请 key，并设置用量限额/告警，防止费用失控。
数据安全：
- 公有 LLM 场景必开 --anonymize，并清楚其局限（日志内嵌敏感数据不保证脱敏）。
- 高合规环境（金融/政企）直接使用本地 Ollama/私有 LLM 网关，数据不出内网。
成本控制：
- 排障时先跑不带 --explain 的纯规则分析（零成本），确认有异常再调 AI。
- 用 --filter 和 --namespace 缩小分析范围，避免每次全集群扫描产生大量 token。
- Operator 模式的扫描间隔按需调大，配合 Result CR 缓存（noCache: false）。
结果可信度：LLM 会"一本正经地胡说八道"，AI 建议只能作为排障起点，执行任何修复命令前人工确认；Analyzer 的规则性结论（如 Service 无 Endpoint）可信度远高于 AI 推理部分。
与流程结合：把 k8sgpt analyze --output json 嵌入值班手册 SOP 与工单系统，沉淀"异常 → 诊断 → 处置"闭环。

3.12 本章选型建议表

场景	首选	备选
人工排障快速定位	K8sGPT CLI	kubectl-ai
离线/涉密环境 AI 诊断	K8sGPT + Ollama	私有 LLM 网关 + K8sGPT
集群持续健康巡检 + 告警	K8sGPT Operator	Robusta
告警自动根因分析	HolmesGPT	K8sGPT webhook 自研
自然语言生成命令	kubectl-ai	K8sGPT
IM 内 ChatOps	botkube	Robusta 通知

第 4 章集群健康检查与审计

AI 诊断解决"出事了帮我看"，本章工具解决"没出事时定期体检"——主动发现配置坏味道、规范缺失和 API 废弃风险。

4.1 工具对比总览

工具	检查对象	形态	输出	推荐指数
Popeye	在线集群资源	CLI	打分 + 问题清单	★★★★☆
kube-score	静态 YAML / 在线	CLI	评分 + 建议	★★★★☆
kube-linter	静态 YAML / Helm	CLI	lint 规则违例	★★★★☆
Polaris	在线集群 / YAML / IaC	CLI + Dashboard + Webhook	评分 + 面板	★★★★☆
Pluto	YAML / Helm / 集群	CLI	废弃 API 清单	★★★★☆
Nova	Helm release	CLI	过期 Chart 清单	★★★☆☆
kubent (kube-no-trouble)	在线集群	CLI	废弃 API 清单	★★★★☆

4.2 Popeye：集群体检打分

简介：k9s 作者 derailed 出品的"集群消毒器"，扫描在线集群各类资源（Pod 资源限制缺失、节点污点异常、PDB 配置、RBAC 过度授权、闲置 ConfigMap 等），给出 A~F 的打分报告。

安装与使用：

bash

curl -fsSL https://github.com/derailed/popeye/releases/latest/download/popeye_Linux_x86_64.tar.gz | tar xz
sudo mv popeye /usr/local/bin/

popeye                        # 扫描当前集群全命名空间
popeye -n biz                 # 只看某命名空间
popeye -s po,svc,deploy       # 只检查指定资源类型（spinach 章节）
popeye -o html > report.html  # 输出 HTML 报告（-o json/yaml/prometheus 亦可）
popeye -A --force-exit-zero   # CI 中使用：始终返回 0 退出码

实战案例：每周末 cron 执行 popeye -A -o jurassic，把报告投递到对象存储，运维周一晨会过一遍 F 级问题。

最佳实践：Popeye 默认规则偏严格，可通过 spinach.yaml 配置文件裁剪规则与豁免名单，适配团队规范。

4.3 kube-score：静态 YAML 检查

简介：对 manifest 做静态最佳实践检查：资源 requests/limits、readiness/liveness 探针、PodDisruptionBudget、anti-affinity、SecurityContext、镜像 tag 固定等，是 CI 流水线里"准入前检查"的好选择。

安装与使用：

bash

curl -fsSL https://github.com/zegl/kube-score/releases/latest/download/kube-score_linux_amd64.tar.gz | tar xz
sudo mv kube-score /usr/local/bin/

# 检查单个文件（支持 stdin、Helm template、Kustomize 输出）
kube-score score deploy.yaml
helm template myapp ./chart | kube-score score -
kubectl get deploy myapp -o yaml | kube-score score -     # 检查在线资源
kube-score score --output-format ci deploy.yaml           # CI 友好输出

实战案例：GitLab CI 中加入阶段 kube-score score --exit-one-on-warning k8s/*.yaml，任何缺 requests/limits 或探针的提交直接阻断合并，三个月后集群因资源未设限导致的 OOM 驱逐事件下降 80%。

4.4 kube-linter

简介：StackRox/Red Hat 开源的静态检查工具，定位与 kube-score 类似但更偏"lint 规则"风格，规则集（checks）可按团队规范自定义，配置成 .kube-linter.yaml 随仓库管理。

bash

# 安装
curl -fsSL https://github.com/stackrox/kube-linter/releases/latest/download/kube-linter-linux.tar.gz | tar xz
sudo mv kube-linter /usr/local/bin/

kube-linter lint deploy.yaml
kube-linter lint k8s/ --config .kube-linter.yaml
kube-linter checks list        # 查看全部内置规则

kube-score vs kube-linter：

维度	kube-score	kube-linter
侧重点	高可用/可靠性最佳实践	安全与规范 lint
规则自定义	较少	丰富（可禁用/新增/阈值化）
输出评分	有（CRITICAL/WARNING/OK）	无评分，列违例
CI 集成	简单	简单

4.5 Polaris（Fairwinds）

简介：Fairwinds 出品的配置审计工具，三种形态：CLI（扫 YAML/集群）、Dashboard（Web 可视化评分）、Admission Webhook（不合规部署直接拒绝）。检查项覆盖 Security、Reliability、Efficiency 三大类。

bash

# CLI 审计在线集群
curl -fsSL https://github.com/FairwindsOps/polaris/releases/latest/download/polaris_linux_amd64.tar.gz | tar xz
sudo mv polaris /usr/local/bin/
polaris audit --audit-path ./k8s/          # 审计目录
polaris audit                              # 审计在线集群

# Dashboard 部署
helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm install polaris fairwinds-stable/polaris --namespace polaris --create-namespace
kubectl -n polaris port-forward svc/polaris-dashboard 8080:80

实战案例：平台组将 Polaris 以 ValidatingWebhook 部署，设置 securityContext.privileged=deny、resources.limits=enforce，从入口杜绝特权容器与无限制资源进入生产集群。

4.6 Pluto / Nova：API 废弃检测

简介：K8s 每次大版本升级都会废弃一批 API（如 1.22 废弃 extensions/v1beta1 Ingress，1.25 废弃 policy/v1beta1 PodDisruptionBudget）。升级前不排查，升级后资源直接失效。

Pluto：Fairwinds 出品，检查文件、Helm release、在线资源中的废弃/移除 API。
Nova：同门工具，检查集群中 Helm release 的 Chart 是否过时。
kubent (kube-no-trouble)：专门扫描在线集群中"最后应用的 API 版本"（读取 kubectl.kubernetes.io/last-applied-configuration 注解和 Helm 存储），列出将被目标版本移除的资源。

bash

# Pluto
curl -fsSL https://github.com/FairwindsOps/pluto/releases/latest/download/pluto_linux_amd64.tar.gz | tar xz && sudo mv pluto /usr/local/bin/
pluto detect-files -d ./k8s/
pluto detect-all-in-cluster --target-versions k8s=v1.29.0
helm list -A -o json | pluto detect-helm -   # 检查 Helm release

# kubent
sh -c "$(curl -sSL https://git.io/install-kubent)"
kubent --target-version=1.29                 # 列出升级到 1.29 会出问题的资源

# Nova
curl -fsSL https://github.com/FairwindsOps/nova/releases/latest/download/nova_linux_amd64.tar.gz | tar xz && sudo mv nova /usr/local/bin/
nova find --wide                             # 列出过期的 Helm release

实战案例：RKE2 升级前检查清单

bash

# 升级 v1.28 → v1.29 前
kubent --target-version=1.29 -o json > api-deprecation.json
pluto detect-all-in-cluster --target-versions k8s=v1.29.0
nova find --wide > outdated-charts.txt
# 逐一修复后再执行 rke2 升级

最佳实践：把 Pluto/kubent 检查固化为升级 SOP 的第一步；CI 中对仓库 YAML 跑 Pluto，从源头阻止废弃 API 提交。

4.7 本章选型建议表

场景	首选	备选
集群定期体检打分	Popeye	Polaris Dashboard
CI 中检查 YAML 最佳实践	kube-score	kube-linter
团队自定义 lint 规则	kube-linter	Polaris 自定义检查
准入控制（不合规拒绝部署）	Polaris Webhook	Kyverno/OPA
升级前废弃 API 排查	kubent + Pluto	Nova（Chart 层）

第 5 章安全扫描

安全不是上线前的一次性动作，而是"镜像 → 集群配置 → 运行时"的全链路持续检查。

5.1 工具对比总览

工具	检查层	形态	依据标准	推荐指数
Trivy	镜像 CVE / IaC / K8s 配置 / 集群	CLI + Operator	CVE 数据库、K8s 最佳实践	★★★★★
kube-bench	节点与集群配置	CLI / Job	CIS Kubernetes Benchmark	★★★★★
kube-hunter	集群攻击面（黑盒视角）	CLI / Job	主动探测	★★★★☆
Falco	运行时行为	DaemonSet + eBPF	自定义规则	★★★★☆
Checkov	IaC（Terraform/Helm/YAML）	CLI	数百条合规策略	★★★★☆

5.2 Trivy：一站式扫描器

简介：Aqua Security 开源的"瑞士军刀"扫描器：容器镜像漏洞（CVE）、文件系统、Git 仓库、IaC 配置（misconfig）、K8s 集群安全态势，一个二进制全搞定；另有 trivy-operator 常驻集群持续扫描。

安装：

bash

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | \
  sudo sh -s -- -b /usr/local/bin latest

核心用法：

bash

# 1. 镜像扫描（CI 中最常用）
trivy image nginx:1.25
trivy image --severity HIGH,CRITICAL --exit-code 1 myregistry/myapp:v1.2.3
trivy image --format json -o result.json myapp:v1.2.3

# 2. 文件系统 / 仓库扫描（含秘密泄露检测）
trivy fs --scanners vuln,secret,misconfig ./myproject
trivy repo https://github.com/org/repo.git

# 3. K8s 集群扫描
trivy k8s --report summary cluster            # 集群整体安全摘要
trivy k8s -n biz --report all deploy/myapp    # 指定工作负载
trivy config ./k8s/                           # 扫描 YAML/Helm 模板配置错误

# 4. 离线环境：更新/离线分发漏洞库
trivy image --download-db-only                # 缓存 DB 后离线使用

trivy-operator（集群内持续扫描）：

bash

helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm install trivy-operator aqua/trivy-operator \
  --namespace trivy-system --create-namespace

# 扫描结果存为 CR，可查询
kubectl get vulnerabilityreports -A
kubectl get configauditreports -A
kubectl get exposedsecretreports -A

与 K8sGPT 联动（第 3 章）：k8sgpt integration activate trivy 后，AI 可直接解释这些 VulnerabilityReport。

实战案例：CI 流水线中加门禁 trivy image --severity CRITICAL --exit-code 1，CRITICAL 漏洞镜像无法进入生产仓库；集群内 trivy-operator 每日增量扫描，Grafana 面板展示各命名空间高危漏洞数趋势。

最佳实践：CI 用 --ignore-unfixed 过滤尚无修复版本的漏洞减少噪音；生产集群扫描 RBAC 收紧到只读。

5.3 kube-bench：CIS 基准检查（含 RKE2 专用 profile）

简介：按 CIS Kubernetes Benchmark 逐条检查节点与组件配置（文件权限、API Server 参数、kubelet 配置、etcd 安全等），输出 PASS/FAIL/WARN。

RKE2 环境用法（kube-bench 内置 RKE2 专用 profile）：

bash

curl -fsSL https://github.com/aquasecurity/kube-bench/releases/latest/download/kube-bench_linux_amd64.tar.gz | tar xz
sudo mv kube-bench /usr/local/bin/

# RKE2 server（控制面）节点
sudo kube-bench run --benchmark rke2-cis-1.8          # 或 rke2-cis-1.24 等，按 RKE2 版本选
# 或使用 CIS 1.8 通用检测自动识别
sudo kube-bench run --targets master,node,etcd,policies --benchmark rke2-cis-1.8

# 以 Job 方式在集群内跑（官方提供 job-rke2.yaml 类清单）
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-rke2.yaml
kubectl logs -l app=kube-bench

RKE2 注意点：RKE2 默认已按 CIS 加固思路部署（尤其使用 profile: cis 时），大量检查天然 PASS；关注剩余 WARN/FAIL 项，多为 sysctl 与文件属主类问题，按报告中的 remediation 逐条整改。

最佳实践：整改前先打快照；WARN 项（需人工判断）逐条评估业务影响；扫描报告归档作为等保/合规审计材料。

5.4 kube-hunter：攻击者视角探测

简介：与 kube-bench（白盒配置检查）互补，kube-hunter 从黑盒攻击者视角主动探测集群暴露面：开放的 API Server 匿名访问、kubelet 未鉴权端口、暴露的 Dashboard/etcd 等。

bash

# 容器方式运行（推荐，避免装 Python 依赖）
docker run --rm aquasec/kube-hunter --remote <集群某节点IP>
docker run --rm --network host aquasec/kube-hunter --cidr 10.0.10.0/24

# 输出按严重等级列出漏洞与复现路径

最佳实践：仅在授权环境运行（它是探测/攻击性工具）；把它当"渗透自查"，整改后复测闭环。

5.5 Falco：运行时安全（简介）

简介：CNCF 毕业项目，基于 eBPF/内核模块捕获系统调用，用规则检测运行时异常行为，如：

容器内启动 shell（Terminal shell in container）
读写敏感路径（/etc/shadow、证书目录）
异常出站连接、crypto mining 特征
K8s Audit 事件异常（配合 k8s audit 插件）

安装（Helm + eBPF 驱动，容器化部署免编译内核模块）：

bash

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=modern_ebpf

告警通过 falcosidekick 转发到 Slack/ES/Kafka。Falco 规则调优是持续工程，建议先以默认规则观察 2 周再逐步加白名单。

5.6 Checkov：IaC 静态合规扫描

简介：Prisma Cloud 开源的 IaC 扫描器，支持 Terraform、CloudFormation、K8s YAML、Helm、Dockerfile 等，内置数百条策略（含 CIS、等保相关），适合 CI 卡点。

bash

pip install checkov    # 建议放入 CI 镜像或 venv
checkov -d ./k8s/ --framework kubernetes
checkov -d ./terraform/ --compact --quiet
checkov -d ./k8s/ --check CKV_K8S_43    # 只跑指定规则；--skip-check 跳过

5.7 本章选型建议表

场景	首选	备选
镜像 CVE 扫描（CI 门禁）	Trivy	Grype
集群持续漏洞扫描	trivy-operator	Kubescape
CIS 合规检查（RKE2）	kube-bench（rke2 profile）	Rancher CIS 扫描
攻击面探测	kube-hunter	商业渗透服务
运行时入侵检测	Falco	Cilium Tetragon
IaC 合规卡点	Checkov	Trivy config

第 6 章备份与迁移

6.1 工具对比总览

工具	备份内容	存储后端	特色	推荐指数
Velero	K8s 资源 + PV 数据	S3 兼容 / Azure / GCS / MinIO	生态标准，备份/恢复/迁移全能	★★★★★
k8up	PV 数据（Restic）	S3 兼容	轻量、operator 化	★★★☆☆
RKE2 etcd 快照	etcd（集群状态全量）	本地 / S3	RKE2 内置，灾备兜底	★★★★★（必配）

分层备份理念：etcd 快照保"集群能重建"，Velero 保"应用能恢复"，两者互补不互替。

6.2 Velero

简介：CNCF 备份恢复事实标准。两大能力：

资源备份：把 K8s API 对象（Deployment、Service、ConfigMap、CR……）序列化备份到对象存储。
卷数据备份：通过 Restic 或 Kopia（node-agent，文件级复制）或 CSI 快照（块级）备份 PV 数据。

安装（以 S3 兼容存储/MinIO 为例）：

bash

# 1. 下载 CLI
curl -fsSL https://github.com/vmware-tanzu/velero/releases/latest/download/velero-v1.14.1-linux-amd64.tar.gz | tar xz
sudo mv velero-v1.14.1-linux-amd64/velero /usr/local/bin/

# 2. 准备对象存储凭证
cat > credentials-velero <<'EOF'
[default]
aws_access_key_id = <ACCESS_KEY>
aws_secret_access_key = <SECRET_KEY>
EOF

# 3. 安装服务端（启用 node-agent 以支持 Restic/Kopia 卷备份）
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.10.0 \
  --bucket velero-backups \
  --secret-file ./credentials-velero \
  --backup-location-config region=minio,s3ForcePathStyle=true,s3Url=http://minio.minio.svc:9000 \
  --use-node-agent \
  --default-volumes-to-fs-backup   # 默认对 Pod 卷做文件系统级备份（Kopia）

核心用法：

bash

# 备份
velero backup create biz-backup --include-namespaces biz
velero backup create full-backup --snapshot-volumes=false   # 仅资源
velero backup get / velero backup describe biz-backup --details
velero backup logs biz-backup

# 定时备份
velero schedule create daily-biz --schedule="0 2 * * *" --include-namespaces biz --ttl 720h

# 恢复
velero restore create --from-backup biz-backup
velero restore create --from-backup biz-backup --include-namespaces biz \
  --namespace-mappings biz:biz-restore       # 恢复到新命名空间（验证演练）

# 集群迁移：目标集群配置指向同一个 bucket（read-only backup location）
velero install ... --backup-location-config ...,readOnly=true
velero restore create --from-backup biz-backup   # 在新集群直接恢复

实战案例：跨集群迁移应用

场景：把 biz 命名空间从旧 RKE2 集群迁到新集群。

bash

# 旧集群
velero backup create migrate-biz --include-namespaces biz \
  --default-volumes-to-fs-backup --wait

# 新集群（同一 bucket，readOnly 安装）
velero backup get                       # 能看到 migrate-biz
velero restore create migrate-biz-restore --from-backup migrate-biz --wait
kubectl -n biz get pods                 # 验证 Pod 拉起、PVC 数据完整

实战案例：误删恢复演练——每月做一次 velero restore --namespace-mappings prod:prod-restoretest，验证备份真正可用（备份不演练等于没备份）。

最佳实践：

TTL 与保留策略按合规要求设置（如 --ttl 720h 保留 30 天）。
卷备份优先 CSI 快照（同一存储体系内，速度快）；跨存储/跨集群迁移用 Kopia/Restic 文件级。
bucket 开启版本控制与不可变（Object Lock），防勒索。
监控 Velero 的 metrics，备份失败必须告警。

6.3 k8up 简介

k8up 是 VSHN 开源的轻量备份 operator，基于 Restic，通过 Schedule/Backup/Restore CRD 管理 PVC 数据备份到 S3。适合"只要备份数据卷、不要复杂功能"的场景，资源占用比 Velero 小。

bash

helm repo add k8up-io https://k8up-io.github.io/k8up
helm install k8up k8up-io/k8up --namespace k8up-system --create-namespace
# 之后创建 Schedule CR 定义备份计划、后端与保留策略

6.4 与 RKE2 etcd 快照的配合

RKE2 内置 etcd 快照能力（无需额外工具）：

bash

# 手动快照
sudo rke2 etcd-snapshot save --name pre-upgrade

# 自动快照（/etc/rancher/rke2/config.yaml）
# etcd-snapshot-schedule-cron: "0 */6 * * *"
# etcd-snapshot-retention: 28
# etcd-s3: true
# etcd-s3-bucket: rke2-etcd-snapshots
# etcd-s3-endpoint: minio.example.com:9000

# 列出与恢复（灾难恢复场景）
sudo rke2 etcd-snapshot list
sudo rke2 server --cluster-reset --cluster-reset-restore-path=/var/lib/rancher/rke2/server/db/snapshots/pre-upgrade

配合策略：

层次	工具	恢复粒度	RTO
集群级灾难（etcd 损坏/误删集群）	RKE2 etcd 快照	整个集群状态	小时级
应用级（误删命名空间/配置回滚）	Velero	命名空间/单资源	分钟级
数据级（PVC 数据）	Velero(Kopia/CSI) / k8up	单卷	分钟~小时级

6.5 本章选型建议表

场景	首选	备选
应用备份/恢复/迁移	Velero	k8up（仅卷数据）
集群灾备兜底	RKE2 etcd 快照 + S3	外部 etcd 备份方案
跨集群迁移	Velero（同 bucket 双集群）	手工 export/import
定期恢复演练	Velero namespace-mappings	—

第 7 章 GitOps 与持续交付

GitOps 核心思想：Git 仓库是集群状态的唯一事实来源，集群内的 operator 持续把实际状态与 Git 期望状态对齐。

7.1 ArgoCD vs FluxCD

维度	ArgoCD	FluxCD
架构	集中式（api-server + repo-server + controller）	分布式 toolkit（多个专职 controller）
Web UI	功能强大的 UI（可视化应用拓扑、diff、同步）	无官方 UI（可用 Headlamp/Weave GitOps 插件）
多租户	AppProject 体系成熟	依赖 RBAC + 命名空间隔离
配置方式	Application/AppProject CR	GitRepository/Kustomization/HelmRelease CR
适用风格	平台团队统一交付门户	基础设施即代码、自动化流水线派
推荐指数	★★★★★	★★★★☆

7.2 ArgoCD

安装：

bash

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 获取初始 admin 密码
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -d

# 访问 UI
kubectl -n argocd port-forward svc/argocd-server 8443:443   # https://localhost:8443

# CLI（可选）
curl -sSL -o /tmp/argocd https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
sudo install -m 555 /tmp/argocd /usr/local/bin/argocd
argocd login localhost:8443 --insecure

核心对象：

Application：一个应用的声明（源仓库 + 路径 + 目标集群/命名空间 + 同步策略）。

yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://git.example.com/platform/myapp-config.git
    targetRevision: main
    path: overlays/prod          # Kustomize 目录；也可以是 Helm chart 目录
  destination:
    server: https://kubernetes.default.svc
    namespace: biz
  syncPolicy:
    automated:                   # 自动同步（Git 一变集群即变）
      prune: true                # 删除 Git 中已移除的资源
      selfHeal: true             # 集群被手改后自动拉回
    syncOptions:
      - CreateNamespace=true

AppProject：多租户隔离单元，限定"哪些仓库、哪些目标集群/命名空间、哪些角色"可用。

yaml

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-biz
  namespace: argocd
spec:
  sourceRepos:
    - https://git.example.com/team-biz/*
  destinations:
    - server: https://kubernetes.default.svc
      namespace: biz-*
  clusterResourceWhitelist:
    - group: ""
      kind: Namespace

ApplicationSet：批量生成 Application（按 Git 目录/集群列表/PR 等生成器），实现"一个模板管 50 个集群/50 个环境"。

yaml

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: addons-all-clusters
  namespace: argocd
spec:
  generators:
    - git:
        repoURL: https://git.example.com/platform/addons.git
        revision: main
        directories:
          - path: addons/*        # 每个子目录生成一个 Application
  template:
    metadata:
      name: '{{path.basename}}'
    spec:
      project: default
      source:
        repoURL: https://git.example.com/platform/addons.git
        targetRevision: main
        path: '{{path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{path.basename}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

同步策略要点：

automated + prune + selfHeal 是"纯 GitOps"姿态；生产初期建议先关 prune，避免误删。
手动同步：argocd app sync myapp；回滚：argocd app rollback myapp。
Sync Waves（argocd.argoproj.io/sync-wave 注解）控制资源创建顺序。

与 Helm/Kustomize 结合：

ArgoCD 原生识别 Helm chart 目录与 kustomization.yaml；source.helm.valuesFiles 可叠加多 values。
推荐模式："Helm 打包 + Kustomize overlay 分环境"或"Helm + per-env values 文件"。

实战案例：平台组用 ApplicationSet 的 cluster generator 把 ingress-nginx、cert-manager、metrics-server 三个基础组件一次性下发到 12 套 RKE2 集群；业务组在各自 Git 仓库 push 后 30 秒内 ArgoCD 自动同步上线，UI 上应用拓扑与 diff 一目了然，发布审批从工单制改为 Git PR 制。

最佳实践：

ArgoCD 自身的 RBAC 按 AppProject 细分；生产 Project 禁用来历不明的 repoURL。
开启 notifications（钉钉/Slack）感知同步失败。
ArgoCD 自身配置也放进 Git（app-of-apps 模式自举管理）。

7.3 FluxCD 简介

Flux 是 CNCF 毕业项目，由 source-controller、kustomize-controller、helm-controller、notification-controller 等组成，全部声明式 CR 驱动：

bash

# 安装 CLI 并 bootstrap（把 Flux 自身也纳入 Git 管理）
curl -s https://raw.githubusercontent.com/fluxcd/flux2/main/install/flux.sh | sudo bash
flux bootstrap gitlab \
  --owner=platform --repository=fleet --branch=main --path=clusters/prod

# 核心 CR：GitRepository（源） + Kustomization（渲染与部署） + HelmRelease（Helm 发布）

Flux 更适合"基础设施流水线"风格：与 CI、SOPS 密钥管理、镜像自动更新（image-automation）结合紧密。

7.4 本章选型建议表

场景	首选	备选
团队需要可视化发布门户	ArgoCD	—
多集群基础组件批量下发	ArgoCD ApplicationSet	Flux fleet
深度 CI/自动化集成、无 UI 需求	FluxCD	ArgoCD
强多租户隔离	ArgoCD AppProject	Flux + RBAC

第 8 章成本与容量

8.1 工具对比总览

工具	定位	形态	推荐指数
OpenCost / Kubecost	成本分摊与可视化	Helm 部署 + UI	★★★★☆
Goldilocks	VPA 资源建议可视化	Controller + Dashboard	★★★★☆
kube-capacity	节点资源利用率速览	kubectl 插件	★★★★☆
Robusta	告警增强 + 排障自动化	Helm + SaaS/自托管	★★★☆☆

8.2 Kubecost / OpenCost

简介：OpenCost 是 CNCF 开源的成本计量标准（按命名空间/Deployment/标签分摊 CPU、内存、存储、网络成本）；Kubecost 是其商业发行版，提供免费档（单集群、保留 15 天数据），自带漂亮的成本 UI。

安装（Kubecost 免费版，Helm 一键，自带 Prometheus）：

bash

helm repo add kubecost https://kubecost.github.io/cost-analyzer/
helm install kubecost kubecost/cost-analyzer \
  --namespace kubecost --create-namespace

kubectl -n kubecost port-forward svc/kubecost-cost-analyzer 9090:9090
# 浏览器打开 http://localhost:9090

若已有 Prometheus 体系，可只装 OpenCost：

bash

helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm install opencost opencost/opencost --namespace opencost --create-namespace

核心功能：按命名空间/标签的月度成本分摊、闲置资源识别（idle cost）、节点效率、储蓄建议（right-sizing）、云账单对账（对接云厂商 CUR/账单 API，自建集群可自定义单价）。

实战案例：财务要求"各业务线分摊 K8s 资源账单"。运维在 Kubecost 配置节点单价后，按命名空间标签 team 出月度报表，发现某测试命名空间占集群 30% 成本且利用率仅 8%——回收后每年节省两台高配服务器。

最佳实践：自建集群务必配置准确的节点小时单价（--set kubecostProductConfigs.defaultModelPricing 或 UI 设置），否则成本数字只有相对意义。

8.3 Goldilocks：VPA 建议可视化

简介：Fairwinds 出品。它给指定命名空间自动创建 VPA（Vertical Pod Autoscaler，recommendation 模式），再用 Dashboard 展示"当前 requests/limits vs VPA 推荐值"，是资源右配（right-sizing）最轻量的落地方案。

安装：

bash

# 1. 先装 VPA（Goldilocks 依赖）
git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler && ./hack/vpa-up.sh

# 2. 装 Goldilocks
helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm install goldilocks fairwinds-stable/goldilocks \
  --namespace goldilocks --create-namespace \
  --set dashboard.enabled=true

# 3. 给命名空间打标签启用
kubectl label ns biz goldilocks.fairwinds.com/enabled=true

kubectl -n goldilocks port-forward svc/goldilocks-dashboard 8080:80

最佳实践：VPA 只用于"给建议"（updateMode: Off），不要让它在生产自动驱逐 Pod；收集 7 天以上数据再调整 requests。

8.4 kube-capacity

简介：kubectl 插件，一条命令看清节点/ Pod 的资源请求、上限与实际用量（需 metrics-server）。

bash

kubectl krew install resource-capacity
kubectl resource-capacity                      # 节点维度
kubectl resource-capacity --pods --util        # 含 Pod 与实际利用率
kubectl resource-capacity --sort cpu.util      # 按 CPU 利用率排序

实战案例：扩容决策前 kubectl resource-capacity --util，发现 CPU request 分配率 95% 但实际利用率 22%——瓶颈是"过度申请"而非容量不足，先做 right-sizing 再谈扩容。

8.5 Robusta 简介

Robusta 是告警增强与排障自动化平台：接收 Prometheus 告警后自动附加"富上下文"（相关 Pod 日志、事件、CPU 曲线截图、OOM 分析），推送到 Slack/钉钉；另有 playbook 自动化（如 JVM 堆 dump、自动扩容副本）和 HolmesGPT AI 根因分析（见第 3 章）。可通过 Helm 自托管或接其 SaaS。

bash

helm repo add robusta https://robusta-charts.storage.googleapis.com
helm install robusta robusta/robusta -n robusta --create-namespace -f generated_values.yaml

8.6 本章选型建议表

场景	首选	备选
成本分摊报表	Kubecost 免费版	OpenCost + 自建 Grafana
requests/limits 右配	Goldilocks (VPA)	Kubecost 建议
快速看容量水位	kube-capacity	kubectl top
告警富化 + 自动排障	Robusta	自研 Alertmanager webhook

第 9 章网络与流量工具

9.1 工具对比总览

工具	原理	粒度	侵入性	推荐指数
kubeshark	节点流量嗅探（L7 解析）	全集群 API 级流量	中（注入 worker）	★★★★☆
inspektor-gadget	eBPF	系统调用/网络/文件事件	低	★★★★☆
ksniff	tcpdump 边车	单 Pod 包级	低	★★★☆☆
netshoot	调试工具镜像	手工执行	无	★★★★★（必备）

9.2 netshoot：网络调试瑞士军刀镜像

简介：nicolaka/netshoot 镜像打包了 tcpdump、dig、curl、iperf、mtr、nmap、netcat、ethtool、conntrack 等几乎所有网络工具，是容器网络排障的事实标准。

用法：

bash

# 临时 Pod 进入指定命名空间调试
kubectl run netshoot --rm -it --image=nicolaka/netshoot -n biz -- bash

# 直接共享目标 Pod 的网络命名空间（等价于在容器内部抓包）
kubectl debug -it pod/myapp-xxx -n biz --image=nicolaka/netshoot --target=myapp

# 在节点网络命名空间调试（查 CNI、宿主机 iptables/ipvs）
kubectl debug node/worker-01 -it --image=nicolaka/netshoot

常用排查命令：dig svcname.biz.svc.cluster.local、curl -v http://svc:port/health、mtr -n 目标IP、conntrack -L | grep <ip>、tcpdump -i any port 8080 -nn。

9.3 kubeshark：集群级流量嗅探

简介：把"Wireshark 抓包 + L7 协议解析"搬到 K8s：在各节点注入 worker，实时捕获并解析 HTTP/gRPC/Kafka/MySQL/DNS 等 API 级流量，Web UI 可按服务、路径、状态码过滤查询，定位"谁调谁、慢在哪、报什么错"。

安装与使用：

bash

# 安装 CLI
curl -Lo kubeshark https://github.com/kubeshark/kubeshark/releases/latest/download/kubeshark_linux_amd64
chmod +x kubeshark && sudo mv kubeshark /usr/local/bin/

kubeshark tap                      # 开始捕获，自动 port-forward 打开 http://localhost:8899
kubeshark tap -n biz               # 只看某命名空间
kubeshark tap --set tap.regex="myapp.*"   # 按名称过滤
kubeshark clean                    # 清理注入的组件

实战案例：微服务调用链中某接口偶发 502，日志无异常。kubeshark 捕获到 upstream 在 30s 时主动 FIN——定位为 ingress 与后端 keepalive 超时时间不一致，调整后故障消失。

最佳实践：生产按需短时开启（有性能与隐私影响）；捕获流量含业务数据，注意合规；用完 kubeshark clean。

9.4 inspektor-gadget / kubectl trace：eBPF 观测

简介：Inspektor Gadget 是 CNCF 项目，把一组 eBPF 工具（gadget）做成 kubectl 插件：追踪 DNS 请求、TCP 连接、文件打开、进程执行、OOM kill、信号等，无需改应用、无 sidecar。

bash

kubectl krew install gadget
kubectl gadget deploy                       # 部署到集群（新版为独立安装，见官方文档）

# 常用 gadget（新版语法为 kubectl gadget run <gadget>）
kubectl gadget run trace_dns -n biz         # 谁在做 DNS 查询、查询什么
kubectl gadget run trace_tcp -n biz         # 实时 TCP 连接
kubectl gadget run trace_exec -n biz        # 容器内执行了什么命令
kubectl gadget run trace_open -n biz        # 容器打开了哪些文件

kubectl trace：kubectl krew install trace，基于 bpftrace 的单条 eBPF 程序执行工具，适合写自定义 bpftrace 脚本的高级场景（社区活跃度低于 Inspektor Gadget，新项目优先选后者）。

实战案例：怀疑某 Pod 频繁 DNS 解析失败拖慢请求。kubectl gadget run trace_dns -n biz 观察到每秒数百次对不存在域名的 NXDOMAIN 查询——定位为代码中硬编码了已下线的依赖域名。

9.5 ksniff：给 Pod 抓包

简介：krew 插件，往目标 Pod 所在节点注入静态编译的 tcpdump，抓包结果直接管道到本地 Wireshark。

bash

kubectl krew install sniff
kubectl sniff myapp-xxx -n biz                          # 本地弹出 Wireshark
kubectl sniff myapp-xxx -n biz -f "port 3306" -o cap.pcap   # 存文件

9.6 本章选型建议表

场景	首选	备选
通用网络排障（DNS/连通性/路由）	netshoot	busybox
容器内/节点网络命名空间调试	kubectl debug + netshoot	nsenter
集群级 L7 流量分析	kubeshark	service mesh 自带观测
单 Pod 抓包看报文	ksniff	kubectl debug + tcpdump
无侵入内核级事件追踪	inspektor-gadget	kubectl trace / 手写 bpftrace

第 10 章本地开发与调试

10.1 工具对比总览

工具	解决的问题	模式	推荐指数
Telepresence	本地进程 ↔ 集群网络互通/流量拦截	VPN 式 + 拦截	★★★★☆
mirrord	本地进程借用远端 Pod 上下文（流量镜像/窃取）	注入 agent	★★★★☆
Skaffold	开发循环自动化（构建→推送→部署→日志）	声明式 pipeline	★★★★☆
Tilt	开发循环自动化 + 可视化	Starlark 配置 + UI	★★★☆☆
kubectl debug	在线 Pod/节点排障	K8s 内置	★★★★★（必备）

10.2 kubectl debug 实战（K8s 内置，务必精通）

kubectl debug 是 K8s 1.18+ 内置能力，无需安装任何工具，覆盖四类排障场景：

bash

# 场景 1：给无 shell 的精简镜像（distroless）加 ephemeral 调试容器
kubectl debug -it myapp-xxx -n biz \
  --image=nicolaka/netshoot --target=myapp --share-processes
# --share-processes 后可 ps 看到应用进程，可直接抓包/strace 目标进程

# 场景 2：复制一个 Pod 用于调试（不影响在线流量）
kubectl debug myapp-xxx -n biz -it \
  --copy-to=myapp-debug --container=myapp --image=myapp:debug

# 场景 3：调试崩溃退出的容器（替换启动命令）
kubectl debug myapp-xxx -n biz -it \
  --copy-to=myapp-debug --container=myapp -- sh -c "sleep 3600"

# 场景 4：进入节点调试（挂载宿主机根文件系统到 /host）
kubectl debug node/worker-01 -it --image=ubuntu:22.04
# 进去后 chroot /host，可查 kubelet 日志、iptables、容器运行时

实战案例：生产 distroless 镜像 Pod 偶发 CPU 飙升。kubectl debug --image=nicolaka/netshoot --target=myapp --share-processes 注入临时容器，top/strace -p <pid> 定位到某正则表达式灾难性回溯，全程未重启业务 Pod。

最佳实践：ephemeral containers 默认功能已 GA（v1.25+），RKE2 默认可用；权限受 RBAC 的 pods/ephemeralcontainers 控制，生产可只授予排障账号。

10.3 Telepresence

简介：CNCF 项目，让本地开发机"加入"集群网络：本地进程可直接访问集群内 Service DNS 与 Pod IP；更强大的是 intercept——把集群中发给某服务的流量按请求头/全部重定向到本地进程，实现"本地改代码、集群内联调全链路"。

安装与使用：

bash

# Linux 安装 CLI
sudo curl -fL https://app.getambassador.io/download/tel2oss/releases/download/v2.20.0/telepresence-linux-amd64 -o /usr/local/bin/telepresence
sudo chmod +x /usr/local/bin/telepresence

telepresence connect                  # 建立与集群的网络连接（自动部署 traffic-manager）
curl http://mysvc.biz.svc:8080        # 本地直接访问集群服务

telepresence intercept mysvc -n biz --port 8080:8080
# 之后访问集群中 mysvc 的流量会到达本地 :8080 进程；配合 --http-header 只拦截自己的流量
telepresence leave mysvc-biz          # 结束拦截
telepresence quit

最佳实践：共享集群用 --http-header 个人化拦截，避免抢走同事流量；traffic-manager 需要集群 RBAC 权限，平台组统一预装。

10.4 mirrord

简介：mirrord 往目标 Pod 所在节点注入临时 agent，让本地进程获得远端 Pod 的"环境"：环境变量、文件、以及流量（mirror 镜像模式不影响线上，steal 窃取模式直接接管）。提供 CLI 与 VS Code/IntelliJ 插件。

bash

# 安装
curl -fsSL https://raw.githubusercontent.com/metalbear-co/mirrord/main/scripts/install.sh | bash

# 本地进程在目标 Pod 上下文中运行（流量镜像）
mirrord exec -t deployment/myapp -n biz --steal=false -- node app.js
# VS Code 里配置 .mirrord/mirrord.json 后一键 Debug

Telepresence vs mirrord：

维度	Telepresence	mirrord
核心思路	本地接入集群网络 + 拦截流量	本地进程"附身"远端 Pod
环境变量/文件	需手动同步	自动继承远端 Pod
流量模式	intercept（接管）	mirror（镜像）/ steal（窃取）
IDE 集成	一般	优秀（VS Code/JetBrains 插件）

10.5 Skaffold / Tilt 简介

Skaffold（Google）：skaffold dev 一条命令打通"监听代码变化 → 构建镜像（本地/kaniko/Buildpacks）→ 推送 → helm/kubectl 部署 → 聚合日志"的开发循环，配置为 skaffold.yaml，也能用于 CI（skaffold build/deploy）。
Tilt：同类工具，用 Starlark 写 Tiltfile，带 Web UI 展示每个服务的构建/部署/健康状态，支持本地服务与 K8s 服务混编，适合多服务联调的团队。

两者都解决"改一行代码要手动敲五六条命令"的问题，选一个团队统一使用即可；纯运维工程师了解即可，主要受众是开发。

10.6 本章选型建议表

场景	首选	备选
在线 Pod 排障（无侵入）	kubectl debug	k9s shell
distroless 镜像调试	kubectl debug --target --share-processes	构建 debug 版镜像
节点级故障排查	kubectl debug node/…	SSH + nsenter
本地代码联调集群全链路	Telepresence	mirrord（steal）
本地断点调试 + IDE 体验	mirrord	Telepresence + 手动
开发循环自动化	Skaffold	Tilt

附录：运维工程师工具箱速查表

场景 → 推荐工具。按"先免费/内置、后重型平台"的原则选型。

场景	推荐工具（首选 → 备选）
多集群/多命名空间切换	kubectx / kubens → k9s
终端可视化操作集群	k9s → Lens
聚合看多副本日志	stern → kubetail
防止误操作生产	kube-ps1 + 只读 kubeconfig
团队共享 Web 管理界面	Rancher（RKE2 环境）→ Headlamp
AI 解释集群异常	K8sGPT → kubectl-ai
涉密/离线 AI 诊断	K8sGPT + 本地 Ollama
告警自动根因分析	HolmesGPT / Robusta → K8sGPT webhook 自研
集群体检打分	Popeye → Polaris Dashboard
CI 卡点 YAML 最佳实践	kube-score → kube-linter
不合规部署直接拒绝	Polaris Webhook → Kyverno
升级前废弃 API 排查	kubent + Pluto
Helm Chart 过期检查	Nova
镜像 CVE 扫描	Trivy（CI 门禁）→ trivy-operator（集群持续）
CIS 合规检查	kube-bench（rke2-cis profile）→ Rancher CIS 扫描
攻击面探测	kube-hunter
运行时入侵检测	Falco → Cilium Tetragon
IaC 合规扫描	Checkov → trivy config
应用备份/恢复/跨集群迁移	Velero → k8up（仅卷数据）
集群灾备兜底	RKE2 etcd 快照 + S3 异地
GitOps 发布（要 UI/多租户）	ArgoCD（+ApplicationSet）
GitOps 发布（流水线派）	FluxCD
成本分摊与报表	Kubecost 免费版 → OpenCost
requests/limits 右配建议	Goldilocks（VPA）→ Kubecost 建议
快速查看容量水位	kubectl resource-capacity
容器网络排障（DNS/连通性）	netshoot 镜像 + kubectl debug
集群级 L7 流量分析	kubeshark
单 Pod 抓包	ksniff → kubectl debug + tcpdump
eBPF 无侵入事件追踪	inspektor-gadget
distroless Pod 在线调试	kubectl debug --target --share-processes
节点级深度排障	kubectl debug node/…
本地进程联调集群服务	Telepresence → mirrord
开发循环自动化	Skaffold → Tilt

结语：工具的价值不在于"装了多少"，而在于"解决问题时想得起哪个"。建议读者按本部分章节顺序，先精通 krew/kubectx/k9s/stern 四件套与 kubectl debug，再按团队痛点逐步引入 AI 诊断（K8sGPT）、安全扫描（Trivy/kube-bench）、备份（Velero）与 GitOps（ArgoCD），最终形成自己团队标准化的工具箱与 SOP。

第四部分 K8s 辅助工具生态 ​

目录 ​

第 1 章 终端效率工具 ​

1.1 工具对比总览 ​

1.2 krew：kubectl 插件管理器 ​

1.3 kubectx / kubens：多集群多命名空间切换 ​

1.4 k9s：终端 UI 管理工具 ​

1.5 stern：多 Pod 日志聚合 ​

1.6 kubectl 别名、自动补全、kube-ps1、fzf ​

1.7 本章选型建议表 ​

第 2 章 集群可视化与管理 ​

2.1 工具对比总览 ​

2.2 Lens / OpenLens ​

2.3 Headlamp ​

2.4 Kubernetes Dashboard ​

2.5 Rancher（与 RKE2 集成要点） ​

2.6 本章选型建议表 ​

第 3 章 AI 辅助诊断（重点） ​

3.1 K8sGPT 架构与原理 ​

3.2 安装 K8sGPT CLI ​

3.3 Analyzer：扫描集群异常 ​

3.4 接入 AI 后端 ​

3.4.1 OpenAI（默认后端） ​

3.4.2 Azure OpenAI ​

3.4.3 Amazon Bedrock ​

3.4.4 Google Vertex AI / Gemini ​

3.4.5 本地 Ollama（离线/私有环境首选） ​

3.4.6 自定义 OpenAI 兼容后端 ​

3.4.7 匿名化（anonymize）数据脱敏 ​

3.5 k8sgpt analyze 用法详解 ​

3.6 Integration（集成模式） ​

3.7 K8sGPT Operator 与 Result CRD ​

3.8 完整实战：离线/私有环境用 Ollama 跑 K8sGPT ​

3.9 与 Prometheus Alertmanager 联动的思路 ​

3.10 其他 AI 辅助工具对比 ​

3.11 K8sGPT 最佳实践 ​

3.12 本章选型建议表 ​

第 4 章 集群健康检查与审计 ​

4.1 工具对比总览 ​

4.2 Popeye：集群体检打分 ​

4.3 kube-score：静态 YAML 检查 ​

4.4 kube-linter ​

4.5 Polaris（Fairwinds） ​

4.6 Pluto / Nova：API 废弃检测 ​

4.7 本章选型建议表 ​

第 5 章 安全扫描 ​

5.1 工具对比总览 ​

5.2 Trivy：一站式扫描器 ​

5.3 kube-bench：CIS 基准检查（含 RKE2 专用 profile） ​

5.4 kube-hunter：攻击者视角探测 ​

5.5 Falco：运行时安全（简介） ​

5.6 Checkov：IaC 静态合规扫描 ​

5.7 本章选型建议表 ​

第 6 章 备份与迁移 ​

6.1 工具对比总览 ​

6.2 Velero ​

6.3 k8up 简介 ​

6.4 与 RKE2 etcd 快照的配合 ​

6.5 本章选型建议表 ​

第 7 章 GitOps 与持续交付 ​

7.1 ArgoCD vs FluxCD ​

7.2 ArgoCD ​

7.3 FluxCD 简介 ​

7.4 本章选型建议表 ​

第 8 章 成本与容量 ​

8.1 工具对比总览 ​

8.2 Kubecost / OpenCost ​

8.3 Goldilocks：VPA 建议可视化 ​

8.4 kube-capacity ​

8.5 Robusta 简介 ​

8.6 本章选型建议表 ​

第 9 章 网络与流量工具 ​

9.1 工具对比总览 ​

9.2 netshoot：网络调试瑞士军刀镜像 ​

9.3 kubeshark：集群级流量嗅探 ​

9.4 inspektor-gadget / kubectl trace：eBPF 观测 ​

9.5 ksniff：给 Pod 抓包 ​

9.6 本章选型建议表 ​

第 10 章 本地开发与调试 ​

10.1 工具对比总览 ​

第四部分 K8s 辅助工具生态

目录

第 1 章终端效率工具

1.1 工具对比总览

1.2 krew：kubectl 插件管理器

1.3 kubectx / kubens：多集群多命名空间切换

1.4 k9s：终端 UI 管理工具

1.5 stern：多 Pod 日志聚合

1.6 kubectl 别名、自动补全、kube-ps1、fzf

1.7 本章选型建议表

第 2 章集群可视化与管理

2.1 工具对比总览

2.2 Lens / OpenLens

2.3 Headlamp

2.4 Kubernetes Dashboard

2.5 Rancher（与 RKE2 集成要点）

2.6 本章选型建议表

第 3 章 AI 辅助诊断（重点）

3.1 K8sGPT 架构与原理

3.2 安装 K8sGPT CLI

3.3 Analyzer：扫描集群异常

3.4 接入 AI 后端

3.4.1 OpenAI（默认后端）

3.4.2 Azure OpenAI

3.4.3 Amazon Bedrock

3.4.4 Google Vertex AI / Gemini

3.4.5 本地 Ollama（离线/私有环境首选）

3.4.6 自定义 OpenAI 兼容后端

3.4.7 匿名化（anonymize）数据脱敏

3.5 `k8sgpt analyze` 用法详解

3.6 Integration（集成模式）

3.7 K8sGPT Operator 与 Result CRD

3.8 完整实战：离线/私有环境用 Ollama 跑 K8sGPT

3.9 与 Prometheus Alertmanager 联动的思路

3.10 其他 AI 辅助工具对比

3.11 K8sGPT 最佳实践

3.12 本章选型建议表

第 4 章集群健康检查与审计

4.1 工具对比总览

4.2 Popeye：集群体检打分

4.3 kube-score：静态 YAML 检查

4.4 kube-linter

4.5 Polaris（Fairwinds）

4.6 Pluto / Nova：API 废弃检测

4.7 本章选型建议表

第 5 章安全扫描

5.1 工具对比总览

5.2 Trivy：一站式扫描器

5.3 kube-bench：CIS 基准检查（含 RKE2 专用 profile）

5.4 kube-hunter：攻击者视角探测

5.5 Falco：运行时安全（简介）

5.6 Checkov：IaC 静态合规扫描

5.7 本章选型建议表

第 6 章备份与迁移

6.1 工具对比总览

6.2 Velero

6.3 k8up 简介

6.4 与 RKE2 etcd 快照的配合

6.5 本章选型建议表

第 7 章 GitOps 与持续交付

7.1 ArgoCD vs FluxCD

7.2 ArgoCD

7.3 FluxCD 简介

7.4 本章选型建议表

第 8 章成本与容量

8.1 工具对比总览

8.2 Kubecost / OpenCost

8.3 Goldilocks：VPA 建议可视化

8.4 kube-capacity

8.5 Robusta 简介

8.6 本章选型建议表

第 9 章网络与流量工具

9.1 工具对比总览

9.2 netshoot：网络调试瑞士军刀镜像

9.3 kubeshark：集群级流量嗅探

9.4 inspektor-gadget / kubectl trace：eBPF 观测

9.5 ksniff：给 Pod 抓包

9.6 本章选型建议表

第 10 章本地开发与调试

10.1 工具对比总览