获课：xingkeit.top/18120/

在云原生时代，Kubernetes（简称 K8s）已经成为容器编排的事实标准。它像一个能力超群的“数字交响乐团指挥”，让成千上万个容器按照你的意图整齐划一地运行。但对于刚踏入这个领域的开发者来说，K8s 的概念繁多且抽象，尤其是 Pod、Deployment 和 Service 这三驾马车，构成了整个集群运转的基石。而 kubectl 则是你指挥这个乐团的“指挥棒”——掌握它的核心命令，你就拥有了驾驭分布式系统的力量。

首先，我们必须理清这三个核心资源的角色分工。如果把 K8s 集群比作一家大型物流公司：

• Pod 是运输包裹的“卡车”。它是 K8s 中最小的部署单元，一个 Pod 里可以有一辆独立的卡车（一个容器），也可以有共享车厢的多辆小车（多个紧密协作的容器）。但请记住，Pod 是“临时工”，它随时可能因为节点故障或被调度挤占而下线，它的 IP 是动态变化的。

• Deployment 是管理这些“卡车车队”的“调度中心”。它定义了你想运行多少个 Pod 副本、用哪个版本的镜像、如何滚动更新或回滚。我们几乎从不直接操作 Pod，而是通过 Deployment 来声明我们期望的状态（比如“我要一直保持 3 个 Nginx 实例在运行”），K8s 会不遗余力地将现实状态修正为你期望的状态。

• Service 则是给这些不断变化的“卡车车队”统一发放的“对外服务热线”。无论车队里的卡车如何换新、IP 如何变动，只要拨打 Service 的固定 VIP（虚拟 IP）或 DNS 名称，就能稳定地找到提供服务的 Pod 们。它解决了 Pod 动态 IP 带来的通信难题。

理解了这三者，我们就可以开始使用 kubectl 这个强大的命令行工具进行实战了。kubectl 的命令结构遵循一个清晰的语法模式：kubectl [动作] [资源类型] [资源名称] [参数]。

第一步：创建与部署

当你写好 YAML 配置文件后，第一条命令一定是 kubectl apply -f nginx-deployment.yaml。apply 是声明式创建或更新的核心命令，它会智能地比较 YAML 与集群内现有资源的差异。如果你想快速测试而不写 YAML，可以用 kubectl create deployment nginx --image=nginx:latest --replicas=3。创建后，用 kubectl get pods 可以查看 Pod 的运行状态和 IP，加上 -o wide 可以看到它们分别跑在哪个节点上。如果想看更详细的 Pod 生命周期事件，用 kubectl describe pod nginx-xxx-yyy，它会告诉你 Pod 为什么 Pending（挂起）或 CrashLoopBackOff（崩溃循环重启）。

第二步：查看与排错

get 命令是日常使用频率最高的。kubectl get deployments 会显示期望副本数、当前副本数、可用副本数以及镜像版本。kubectl get svc 则显示 Service 的 Cluster-IP（集群内部 IP）和对外暴露的端口。当 Pod 运行异常时，kubectl logs nginx-xxx-yyy 可以查看容器的标准输出日志；如果 Pod 里有多个容器，需加上 -c container-name。如果需要实时查看日志流，加上 -f 参数（类似 tail -f）。若容器内部发生问题，但日志不足，可以用 kubectl exec -it nginx-xxx-yyy -- /bin/bash 进入容器内部进行诊断，就像 SSH 进服务器一样。

第三步：访问与暴露

Pod 默认是集群内部可访问的，要让外部用户访问，就得通过 Service。如果你创建了一个 NodePort 类型的 Service，用 kubectl expose deployment nginx --type=NodePort --port=80，K8s 会在每个节点上开放一个高位端口（30000-32767）。此时用 kubectl get svc 看到端口映射，你就可以通过 http://任意节点IP:那个高位端口 访问了。在云环境下，常用的手段是 type=LoadBalancer，它会自动调配云厂商的负载均衡器，并用 kubectl get svc 观察 EXTERNAL-IP 字段从 <pending> 变为真实 IP。

第四步：更新与回滚

这恰恰是 Deployment 最亮眼的能力。当你要发布新版本时，执行 kubectl set image deployment/nginx nginx=nginx:1.20，K8s 会启动滚动更新，先启动新 Pod，等新 Pod Ready 后再优雅地终止旧 Pod。用 kubectl rollout status deployment/nginx 可以实时观察更新进度。如果不小心发布了有 Bug 的镜像，不要慌，kubectl rollout undo deployment/nginx 会立即触发回滚，恢复到上一个稳定版本。如果你想查看历史版本记录，用 kubectl rollout history deployment/nginx；回滚到指定版本则用 --to-revision=2。

第五步：缩放与资源管理

面对突增流量，用 kubectl scale deployment/nginx --replicas=10 可以瞬间扩容副本数。如果你觉得手动太麻烦，可以结合 HPA（Horizontal Pod Autoscaler），用 kubectl autoscale deployment/nginx --cpu-percent=50 --min=3 --max=10 设定自动扩缩容规则。当需要清理环境时，kubectl delete -f nginx-deployment.yaml 会优雅地删除资源；紧急情况下，kubectl delete pod nginx-xxx-yyy --force --grace-period=0 可以强制移除一个“卡死”的 Pod。

第六步：高级技巧与上下文管理

当你在多个集群或命名空间之间切换时，kubectl config get-contexts 显示当前所有上下文，kubectl config use-context prod-cluster 切换到生产集群。善用 --namespace=kube-system 参数来查看系统组件（如 CoreDNS、Ingress）。kubectl api-resources 可以列出集群支持的所有资源类型。如果想深入排查网络问题，kubectl run tmp-pod --rm -it --image=busybox -- /bin/sh 可以临时启动一个调试 Pod，并在退出后自动清理——这是诊断 DNS 解析或网络连通性的利器。

最后，给大家一个在实战中总结的重要习惯：能用 apply 就不用 create。apply 是声明式的，它让集群的最终状态与你的配置文件保持一致；而 create 是命令式的，如果后续修改 YAML 再 apply，可能会产生冲突。所有对资源的变更，尤其是生产环境，都应该通过修改 YAML 文件并 apply 来完成，这样既能版本控制，又能审计变更轨迹。

Pod、Deployment 和 Service 构成了 K8s 的“铁三角”，kubectl 则是连接你与这个复杂系统的桥梁。从 get 到 describe，从 logs 到 exec，再到 rollout 与 scale，这套命令组合拳几乎能覆盖日常运维的所有场景。掌握它们，你就拥有了在云原生洪流中稳健航行的压舱石。