如果你有志成为一名 DevOps（Development 开发 + Operations 运维）工程师并以初学者的身份开启你的旅程，或者你是一名希望重温 DevOps 知识或转型进入 DevOps 领域的专业人士，又或者你是一名寻求扩充知识库的学习狂热者，那么你来对地方了。如今，Kubernetes（有时简称为 K8s，8 代表 “K” 和 “s” 之间字母的数量）依然是 DevOps 领域的基石，但在 2026 年，我们不仅需要了解它，更需要结合 AI 辅助工作流（Vibe Coding） 和 云原生先进理念 来掌握它。
这份 Kubernetes 速查表 是一份全面且经过实战检验的指南，它不仅作为学习 Kubernetes 基础及高级命令的快速参考，更融入了我们作为工程师在未来技术环境下的生存法则。无论你是刚刚开始 Kubernetes 之旅的初学者，还是拥有 5 年以上经验的专业人士，本指南都提供了管理集群、节点、命名空间等所需的所有必要命令。
!Kubernetes Cheatsheet .webp)
> 前置条件： 在开始使用这份速查表之前，你应该对 Kubernetes 究竟是什么、它的用途以及它如何提供帮助有一个基本的了解。此外，拥有 EKS 和 AKS 的知识将是额外的优势。
目录
什么是 Kubernetes？
Kubernetes 是一个开源的容器管理工具，它自动化了容器部署、容器扩展和容器负载均衡（也称为容器编排工具）。它是用 Golang 编写的，并且拥有庞大的社区，因为它最初由 Google 开发，后来捐赠给了 CNCF（云原生计算基金会）。Kubernetes 可以将 ‘n‘ 个容器分组到一个逻辑单元中，以便轻松管理和部署。它与所有云供应商（即公共云、混合云和本地环境）配合得都非常出色。
> Kubectl (CLI): Kubectl 是 Kubernetes 的命令行配置工具（CLI），用于与 Kubernetes 的主节点进行交互。Kubectl 有一个名为 kubeconfig 的配置文件，该文件包含有关服务器和访问 API Server 所需的身份验证信息。
Kubernetes (Kubectl) 速查表
Kubernetes 速查表 作为 Kubernetes 集群中广泛使用的一些命令和操作的快速参考指南。在这份速查表中，我们将涵盖集群管理、节点管理、命名空间管理、资源创建、资源查看与查找、资源删除、文件和目录复制、资源修补、资源扩缩容、Pod 管理、Deployment 管理、ReplicaSets 管理、Service 管理、ConfigMaps 和 Secrets、网络、存储、StatefulSets、监控、故障排查以及其他操作。
Kubernetes 主节点组件重要术语
- API Server
- Scheduler
- Controller-Manager
- etcd
> ### API Server
>
> Kube API Server 与 API 进行交互，它是 Kubernetes 控制平面的前端。它是开发人员和其他 Kubernetes 组件的通信中心。API Server 接收来自多个客户端（包括 kubectl 命令行工具）的查询，作为 Kubernetes 控制平面的前端接口，协调集群范围内的操作。
>
> ### Scheduler
>
> 调度器监视 Pod，并将 Pod 分配到特定的主机上运行。当一个新的 Pod 形成时（无论是通过用户、部署控制器还是副本控制器），它并没有被分配到特定的节点。在评估了 Pod 的资源需求（例如 CPU 和内存使用率）以及提供的任何限制或亲和性/反亲和性规则后，调度器会选择一个合适的节点来运行 Pod。
>
> ### Controller-Manager
>
> 控制器管理器在后台运行控制器，这些控制器在 Kubernetes 集群中运行不同的任务。它执行集群级别的功能（复制、跟踪工作节点、处理故障）。
>
> ### etcd
>
> etcd 是一个简单的分布式键值存储。Kubernetes 使用 etcd 作为其数据库来存储所有集群数据。存储在 etcd 中的数据包括作业调度信息、Pod、状态信息等。在 2026 年的架构中，我们通常更加注重 etcd 的备份与加密策略。
Kubernetes 工作节点组件重要术语
工作节点是应用程序实际运行的地方。以下是我们在 2026 年的现代 DevOps 环境中，每天都会与之交互的关键组件：
- Kubelet: 它是主节点和从节点之间的代理。它监视分配给其节点的 Pod，并确保容器在 Pod 的规范中描述。
- Kube-proxy: 它管理网络规则并允许网络通信到你的 Pod。在现代 CNI（Container Network Interface）插件中，它的角色有时会被优化或替代，但依然是核心网络组件。
- Container Runtime: 负责运行容器的软件。虽然 Docker 过去很流行，但现在我们更多使用 containerd 或 CRI-O，因为它们更轻量、更高效，符合 Kubernetes 的 CRI（Container Runtime Interface）标准。
2026 增强版：AI 辅助工作流与 Vibe Coding
在我们深入具体的命令之前，让我们思考一下现在的开发范式是如何变化的。作为工程师，我们正在进入 “氛围编程” 的时代。这意味着我们不再只是孤立地敲击命令，而是将 AI（如 Cursor、Windsurf 或 GitHub Copilot）作为我们的结对编程伙伴。
如何利用 AI 优化 Kubectl 使用？
在我们的日常工作中，我们经常遇到复杂的 YAML 文件或晦涩的错误日志。不要死记硬背每一个标志。 相反，我们建议掌握核心逻辑，然后让 AI 帮助你构建具体的命令。
场景： 你需要创建一个 Deployment，但忘记了具体的字段结构。
传统做法： 去 Google 搜索，复制粘贴，然后手动修改。
2026 最佳实践： 向你的 AI IDE 询问：“生成一个在 Kubernetes 上运行 Nginx 的 Deployment YAML，限制内存为 128Mi，并包含一个 livenessProbe。”
AI 不仅生成代码，还能解释这些资源是如何相互作用的。这让我们能够专注于架构决策，而不是语法细节。
核心 Kubectl 命令详解
让我们来看看实际操作中的命令。为了便于理解，我们将它们分类讲解。
1. 集群与节点管理
作为管理员，我们首先需要确保集群本身是健康的。
# 查看集群信息
kubectl cluster-info
# 查看节点状态和详细信息
# 这在排查节点资源不足或网络问题时非常关键
kubectl get nodes -o wide
# 如果你想深入了解某个节点的详细信息（例如资源分配情况）
# 我们经常使用这个命令来查看节点是否被打上了 Taints（污点）
kubectl describe node
2. 应用部署与资源管理
这是我们要做的最常见的事情：部署应用。
# 创建资源
# -f 指定文件，如果是目录，则会递归查找该目录下的所有 YAML/YAML 文件
kubectl apply -f
# 查看所有命名空间中的 Pod
kubectl get pods --all-namespaces
# 查看特定命名空间中的 Deployment
kubectl get deployment -n
# 实时查看 Pod 状态（类似于 tail -f）
# 在生产环境中调试应用启动失败时，这是第一步操作
kubectl get pods -n --watch
3. 故障排查与日志分析
在一个复杂的微服务环境中，可观测性 是关键。我们不仅仅看日志，还要看事件和资源状态。
# 查看 Pod 日志
# 如果容器重启过，加上 --previous 查看上一个容器的日志（这是救命稻草）
kubectl logs -n --previous
# 如果一个 Pod 有多个容器，你需要指定容器名
kubectl logs -c -n
# 进入 Pod 内部进行调试（类似于 SSH）
# 注意：在生产环境中，尽量避免这样做，除非必要，以保持镜像的纯净性
kubectl exec -it -n -- /bin/bash
# 查看 Pod 的详细事件
# 当 Pod 处于 Pending 或 CrashLoopBackOff 时，这个命令通常能告诉我们原因（如图像拉取失败、OOMKilled）
kubectl describe pod -n
4. 资源扩缩容
在 2026 年，随着 AI 应用的普及，负载波动可能更加剧烈。我们需要灵活地调整资源。
# 手动扩缩容 Deployment
kubectl scale deployment --replicas= -n
# 自动扩缩容 (HPA - Horizontal Pod Autoscaler)
# 我们强烈建议在生产环境中配置 HPA，基于 CPU 或内存使用率自动调整副本数
kubectl autoscale deployment --min= --max= --cpu-percent=
实战案例：在生产环境部署一个高可用应用
让我们通过一个实际的例子，看看我们是如何从零开始部署一个应用的。假设我们要部署一个简单的 API 服务。
步骤 1: 编写 YAML (或者让 AI 帮你写)
我们通常将配置保存在代码仓库中。这是一个标准的 Deployment 示例，展示了如何定义资源限制和健康检查。
# api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-api-service
namespace: production
spec:
replicas: 3 # 我们通常至少运行 3 个副本以保证高可用
selector:
matchLabels:
app: my-api
template:
metadata:
labels:
app: my-api
spec:
containers:
- name: my-api-container
image: myregistry.azurecr.io/my-api:v1.0.0 # 请使用私有镜像仓库
ports:
- containerPort: 8080
# 定义资源限制，防止某个 Pod 吃掉所有节点的资源
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "256Mi"
cpu: "500m"
# 健康检查，Kubernetes 会定期检查这个端点
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 3
periodSeconds: 3
步骤 2: 部署与验证
现在，让我们将这个应用部署到集群中。
# 1. 首先创建命名空间（如果还没创建）
kubectl create namespace production
# 2. 应用配置
kubectl apply -f api-deployment.yaml
# 3. 验证部署状态
# 我们使用 --watch 实时观察 Pod 是否启动成功
kubectl get pods -n production -l app=my-api --watch
# 4. 如果需要更新镜像（例如发布新版本）
kubectl set image deployment/my-api-service my-api-container=myregistry.azurecr.io/my-api:v1.0.1 -n production
常见陷阱与 2026 避坑指南
在我们的职业生涯中，我们踩过无数的坑。这里分享一些最常见的错误，希望能帮你节省时间。
- 忘记设置资源限制: 这是最常见的错误。如果一个 Pod 没有设置 limits，它可能会耗尽节点的内存，导致其他关键服务（如 DNS）被驱逐。最佳实践： 总是为每个容器设置 requests 和 limits。
- 使用 latest 标签: 在生产环境中，永远不要使用 INLINECODE0687d39d。它会导致版本难以回滚，且你无法确定当前运行的是哪个代码版本。最佳实践： 使用具体的版本号（如 INLINECODE1af4e230）或 Git Commit Hash。
- 配置文件中的敏感信息: 不要把密码或 API Token 直接写在 YAML 文件里。这些文件会被提交到 Git。最佳实践： 使用 Kubernetes Secrets 或集成外部的密钥管理系统（如 HashiCorp Vault 或 Azure Key Vault）。
展望未来：Kubernetes 与 Agentic AI
展望 2026 年及以后，Kubernetes 的管理方式正在发生微妙的变化。我们看到了 Agentic AI（自主 AI 代理） 的崛起。
想象一下，你的监控系统检测到某个微服务延迟增加。你不需要手动登录终端输入 kubectl 命令，一个专门的 DevOps AI 代理可以：
- 自动分析 Metrics Server 的数据。
- 判断是 CPU 瓶颈还是数据库锁等待。
- 如果是 CPU 问题，自动修改 HPA 策略或直接扩容 Deployment。
- 在 Slack 频道中向你报告：“已将 api-service 扩容至 5 个副本以应对流量高峰。”
这意味着，我们需要从“命令执行者”转变为“架构设计者和策略制定者”。了解 Kubectl 依然重要，但理解系统架构和自动化策略将变得更为关键。
结语
Kubernetes 是一个强大的工具，掌握它的命令行工具 kubectl 是每一位 DevOps 工程师的必修课。无论你是通过手动输入命令，还是通过 AI 辅助生成脚本，理解其背后的原理——Pod 如何调度、Service 如何路由、Controller 如何协调——才是通往精通之路。
希望这份 2026 年版的速查表不仅能帮助你快速查找命令，更能启发你思考如何构建更加健壮、智能的云原生应用。让我们保持好奇心，继续探索！