Kubernetes集群搭建与Pod管理入门：从单机k3s到排障验证，一次把核心流程跑通

开场：OK，今天我们直接把 Kubernetes 跑起来

哈喽各位，eccfy开场！今天不讲虚的，直接上屏幕演示：从单机 k3s 到 Pod 管理，你看完就能自己搭一个能跑业务的最小集群。OK so，如果你现在搜的是“kubernetes集群搭建教程”“pod管理入门”“kubectl怎么用”，这篇就是给你的。

我先说结论：新手别一上来就硬啃 kubeadm 全家桶，先用 k3s 或 kind 把概念跑通，再回头补复杂度。这样你会更快理解 Pod、Deployment、Service 到底在干嘛，而不是只会复制粘贴 YAML。

第一章：先把集群搭起来，别让环境先把你劝退

接下来我们做最小可用集群。我在一台 Ubuntu 22.04 虚拟机上测试，2 vCPU、4GB 内存足够起一个轻量集群。安装 k3s 的好处是快，通常1 到 2 分钟就能完成，适合“先看到结果再学原理”。

执行：

curl -sfL https://get.k3s.io | sh -

装完后立刻验证：

sudo kubectl get nodes

如果你想在本机用 kubectl，先复制配置：

sudo cat /etc/rancher/k3s/k3s.yaml

把它保存到 ~/.kube/config，或者先临时导出：

export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

现在 watch this，节点状态如果是 Ready，说明控制面至少活了。新手常见坑有三个：一是虚拟机内存太小导致镜像拉不动；二是 Docker/containerd 端口冲突；三是 DNS 没配好导致 Pod 起了但拉镜像慢得像蜗牛。我的建议是先跑 kubectl get pods -A 看系统组件是否都在 Running。

第二章：Pod 是什么，怎么创建、查看、删掉、重建

Pod 不是“容器本身”，而是 Kubernetes 调度和管理的最小单位。你可以把它理解成一个“容器小组”，一个 Pod 里通常放一个主容器，必要时再挂 sidecar。接下来我们直接创建一个最简单的 Pod，别怕 YAML，先看结构。

保存为 nginx-pod.yaml：

apiVersion: v1 kind: Pod metadata: name: nginx-demo spec: containers: - name: nginx image: nginx:1.27 ports: - containerPort: 80

应用它：

kubectl apply -f nginx-pod.yaml

然后看状态：

kubectl get pod -o wide

你会看到 Pod 的 NAME、READY、STATUS、IP。如果卡在 ContainerCreating，就别急着重启，先看事件：

kubectl describe pod nginx-demo

这个命令非常关键。比如我测试时，镜像拉取失败会直接提示 ImagePullBackOff，节点资源不足会提示 Insufficient cpu/memory。这比“凭感觉猜”快太多了。

再来几个高频操作，你直接记：删除 Pod 用 kubectl delete pod nginx-demo；看日志用 kubectl logs nginx-demo；进容器排查用 kubectl exec -it nginx-demo -- sh。如果容器里没有 shell，换成 alpine 或 busybox 容器先练手。Pod管理命令教程最核心的不是背命令，而是知道哪个命令看状态、哪个命令看原因、哪个命令看日志。

第三章：从手动 Pod 到 Deployment，顺手学会验证和排障

OK so，单个 Pod 挂了就没了，所以正式场景一般上 Deployment。它能帮你保持副本数、滚动更新、自动重建。下面这个例子最适合新手理解：

apiVersion: apps/v1 kind: Deployment metadata: name: web-demo spec: replicas: 3 selector: matchLabels: app: web-demo template: metadata: labels: app: web-demo spec: containers: - name: nginx image: nginx:1.27 ports: - containerPort: 80

应用后检查：

kubectl get deploy,pod -o wide

我在测试里把其中一个 Pod 手动删掉，10 秒内就被重新拉起，这就是声明式管理的威力。接着做一个小验证：把镜像改成一个错误版本，比如 nginx:does-not-exist，再执行 kubectl apply -f，你会马上看到 ImagePullBackOff，这就是“故障可复现”。

这里给你一个实战排障顺序，照着来基本不会乱：

先看 kubectl get pod -o wide，确认是不是调度问题。
再看 kubectl describe pod，找事件里的报错关键词。
然后看 kubectl logs，确认应用自己有没有崩。
最后看节点资源：kubectl top nodes 或者先装 metrics-server 再看。

如果你是做开发机环境，建议你额外练一次端口转发：

kubectl port-forward pod/nginx-demo 8080:80

然后浏览器打开 http://127.0.0.1:8080。这一步能直接告诉你：网络、Service、Pod 三层到底哪层有问题。kubernetes集群搭建教程看起来复杂，实际上你只要把“创建—查看—日志—事件—重建”这条链跑顺，就已经入门成功了。

最后：怎么确认你真的修好了

验证别靠“好像可以了”，按这三个标准来：

执行 kubectl get nodes，节点状态是 Ready。
执行 kubectl get pod，Pod 状态是 Running，并且 READY 1/1 或 3/3。
执行 kubectl logs 能看到应用正常输出，kubectl port-forward 后页面能打开。

如果你按这套流程跑通了，恭喜，你已经不是“只会听 Kubernetes 这个词”的阶段了。想继续，我下一期可以直接带你做 Service、Ingress、ConfigMap、Secret 的实战连招。最后如果你想把这套流程做成更省心的环境，也可以把免费/官方路线先跑一遍，再考虑像 roxi.cc 这类方案作为后续选择之一。