从单机到分布式：Kubernetes集群搭建实战指南

1. 为什么我劝你先搞懂单机再碰集群前两年我刚开始碰Kubernetes的时候犯过一个特别蠢的错误。当时项目着急上线我直接照着网上的教程搭了一个三节点集群结果Pod调度、网络插件、存储卷各种问题轮着来整整折腾了两个星期才勉强跑通。后来把环境推倒重来先从单机版一步步摸清原理再往分布式集群扩展反而三天就搞定了。所以这篇内容我想按我自己走过的这条路来聊——先讲清楚Kubernetes到底解决了什么问题再带你从单机环境搭建开始逐步过渡到真正的多节点分布式集群。整个过程会穿插我用过、踩过、最终沉淀下来的命令、配置和排查思路。我默认你至少知道Docker是什么、能跑起一个容器、对Linux基本操作不陌生。如果你连Docker都还没摸过建议先花半天把Docker的镜像、容器、网络这三个概念弄清楚再回来看这篇文章。Kubernetes这个单词来自希腊语意思是“舵手”或者“领航员”。名字起得很贴切——它就是一群容器的领航员负责告诉你这帮容器应该跑在哪台机器上、怎么互相通信、挂了之后怎么恢复。你可能听过很多关于它的形容词容器编排平台、生产级别的容器管理神器、云原生基础设施的操作系统。这些说法都没错但对于一个刚从单机Docker走过来的开发者来说最直接的理解方式是这样的Docker解决了“怎么把一个应用打包成标准构件”的问题而Kubernetes解决的是“怎么把几十上百个这样的构件组织起来让它们像一个整体一样运行”的问题。Docker像集装箱Kubernetes像港口调度系统。你用Docker把货物装进标准尺寸的箱子里港口系统负责安排这些箱子运到哪、存放在哪、哪艘船先装、出现损坏怎么替换。没有港口调度集装箱再多也是一堆散货没有集装箱标准化调度系统也无从下手。两个工具不是替代关系而是上下游配合的关系。这篇文章的面向对象很明确想系统学习Kubernetes的运维工程师、后端开发、DevOps新手以及那些已经会Docker但对集群架构一头雾水的人。我会尽量少讲空泛的理论多给你能直接复制运行的命令、能解释设计原因的对比、能应对实际故障的排查思路。看完之后你不光能搭出一个能用的集群还能理解为什么每一步命令是这么写的出了问题大致往哪个方向查。2. 核心设计拆解K8s到底用哪些组件替你干活在动手搭建之前我强烈建议你先花半小时把Kubernetes的组件模型理清楚。我见过太多人一上来就装集群装完了把kubectl get nodes的输出当作图腾来拜出了故障完全不知道应该检查谁。Kubernetes的架构可以概括为“一主多从控制面与工作面相分离”。整个集群分成两大部分控制平面Control Plane和工作节点Worker Nodes。控制平面是大脑负责决策工作节点是手脚负责干活。2.1 控制平面四大件API Server、etcd、Scheduler、Controller ManagerAPI Server是集群的总入口。所有对集群的操作——你运行的所有kubectl命令、各个组件之间的内部通信、外部系统的调用——最终都要经过API Server。它是一个RESTful API服务也是唯一直接操作etcd的组件。这句话翻译成人话就是API Server是整个集群的“唯一审批窗口”什么请求都得先到它这里登记它确认没问题了才会真正执行。安全管控、权限校验、资源配额这些功能全部集中在这一层。etcd是集群的“记忆体”一个高可用的键值数据库专门存放集群的所有状态信息有哪些节点、每个节点上有哪些Pod、哪个Deployment想要多少个副本、哪个Service绑定了哪些Pod全在这里面。你可以把它理解成航空管制中心的飞行记录系统每一架飞机的位置、航向、高度都必须实时更新到这里。etcd挂了整个集群就会失去判断力——API Server读不到状态就没法审批新请求Kubernetes整个瘫痪。所以生产环境里etcd一定要做集群化部署至少三节点做Raft投票这是后话但你得现在就知道它有多重要。Scheduler是“分配员”。它专门盯着那些被创建出来但还没分配到节点的Pod根据资源余量、节点亲和性、污点和容忍度、数据本地性等一系列规则决定这个Pod应该放到哪台机器上。Scheduler本身不运行Pod它只是做决策然后把决策结果写回API Server。类似房产中介只负责帮你找到匹配的房子并签下合同入住的事情由你和水电师傅自己搞定。Controller Manager是“纠察队”兼“修复工”。它里面跑着一堆控制器每个控制器盯着集群里的某类资源状态。比如Deployment控制器发现实际运行的Pod数量比期望的少了一个它就会去找API Server申请创建新的PodNode控制器发现某个节点心跳中断就会把这个节点标记为NotReady并把上面的Pod迁移到其他节点。这些控制器构成了Kubernetes“面向期望状态”的闭环逻辑。2.2 工作节点三件套Kubelet、Container Runtime、Kube-proxyKubelet是每个工作节点上的“大管家”也是Kubelet和API Server对话的唯一代表。API Server通过kubelet来指令节点执行任务——创建Pod、销毁Pod、获取节点状态、采集容器日志。Kubelet会持续上报节点的资源使用情况同时有心跳机制让控制平面知道它还活着。如果你发现某个节点上的Pod一直起不来第一件事就是去查kubelet的日志。Container Runtime就是真正跑容器的组件比如containerd、CRI-ODocker也算一种。Kubernetes本身不直接操作容器它通过容器运行时接口CRI来和容器运行时通信。你把runtime换成containerd之后会发现Pod日志还是在但docker命令看不到容器了要靠crictl。这个变化曾经坑了我很长时间现在提前告诉你。Kube-proxy是节点上的“网络规则配置员”。它负责实现Service的负载均衡逻辑把访问Service VIP的流量转发到后端真实的Pod上。它的实现方式主要有三种userspace老古董别用、iptables默认模式稳定但规则量大的时候有性能隐患、IPVS大规模集群推荐后面搭建的时候我会让你开这个。它不处理Pod之间的直接通信那种由CNI插件管。2.3 我理解的控制面-工作面协作流程把上面这些组件串起来看一个最简单的应用发布流程你写了一个Deployment的YAML执行kubectl apply。命令先打到API ServerAPI Server校验格式和权限然后把期望状态写入etcd。Scheduler观察到有一个Deployment对应的Pod还没找到节点经过打分选出最合适的节点把这个决策写入API Server。API Server再写入etcd。Kubelet通过长连接监听到分配到自己节点的Pod创建事件于是调Container Runtime去拉镜像、起容器然后回报状态。Controller Manager持续对比实际状态和期望状态保证偏差被不断纠正。这个流程你不需要背但我希望你能画出这张图——哪个组件做决策、哪个组件干执行、哪个组件存状态。这些关系你捋清楚了后面排查任何问题都有方向感。不然你连scheduler日志在哪个节点上看的都不知道谈何运维。3. 工具选型解析不同阶段的K8s环境怎么搭选工具这件事实在太重要了我先单独说一段。Kubernetes环境搭建的工具五花八门很多人在这里选择困难。我给不同目标的读者几个明确建议。3.1 学习阶段怎么选minikube / kind / K3s如果你只是自己学习Kubernetes的API资源、练习YAML编写、跑通工作负载我推荐minikube。它能在你本机拉起一个单节点的Kubernetes集群所有控制面组件和工作组件跑在同一个小环境里kubectl指哪打哪回馈非常及时。而且它对系统要求不高8G内存的笔记本完全能跑。kindKubernetes in Docker是把Kubernetes集群的每个节点都放进Docker容器里运行的方案。你可以在一个宿主机上模拟出多节点的集群拓扑特别适合做控制器开发测试和CI流水线。它比minikube更轻但网络隔离更严格排查问题时对你的网络知识要求更高。K3s是轻量级发行版尤其适合边缘计算和资源受限的环境ARM设备上跑起来很流畅。我建议的学习路线是先minikube玩两星期熟悉Pod、Deployment、Service、ConfigMap这些核心资源然后再上K3s搭一个真的多节点集群体验节点加入、Pod迁移和故障恢复。这个顺序最平滑也最省时间。3.2 生产环境怎么选kubeadm / 云厂商托管K8sEKS / AKS / GKE生产环境如果想自己运维集群kubeadm是官方推荐的工具。它把搭建Kubernetes集群的复杂步骤封装成两条命令——kubeadm init和kubeadm join但仍然需要你手动搞定容器运行时、网络插件、证书管理、高可用架构等外围任务。好处是对底层完全可控坏处是你得能Hold住运维。我搭生产环境基本都用kubeadm出问题心里有数。如果你不想自己管控制平面云厂商的托管Kubernetes服务EKS、AKS、GKE更适合。控制面由云厂商维护你只需要管理工作节点、网络和存储升级也算省心。代价是跟特定云厂商产生绑定且一些高级网络、存储Feature的支持滞后。我的建议是对于没有专职K8s运维团队的公司买托管服务是性价比最高的选择对于已经有运维经验和自定义需求的公司kubeadm自建更能积累团队能力。3.3 千万别在生产环境用的Docker Desktop的K8s、单节点集群Docker Desktop里带一个单节点的Kubernetes开发调试很好用但你要是拿它跑生产我只能劝你想清楚。单节点意味着etcd没有高可用API Server挂了集群就没了控制面和工作面混在一起一个节点宕机就是全站故障。就算是跑内部小工具也不推荐——你部署的就是不可靠。真正生产环境至少保证三点第一控制平面至少三个节点做高可用etcd跟着一起三副本允许少数派故障不影响集群决策第二工作节点至少两个这样Pod才能调度到不同机器一台宕机另一台还能接流量第三网络插件选型和底层基础设施匹配这个后面细说。4. 实操全过程从零搭建单机K8s到三节点分布式集群接下来是全文的重头戏。我会用kubeadm带你从零开始先搭单节点集群确认组件正常再扩容成三节点分布式集群最后部署nginx验证端到端流程。全程注释清晰、命令可直接复制。假设操作系统是Ubuntu 22.04 LTSKubernetes版本选用1.28.x容器运行时用containerd。4.1 环境准备与前置检查这一步是被很多人跳过的坑。开始装之前我建议你用下面的命令逐台检查主机名、IP、系统版本、CPU内存、端口占用别急着下载安装包。# 检查操作系统版本 cat /etc/os-release # 检查主机名和IP hostnamectl set-hostname k8s-master hostname ip addr show # 检查CPU和内存最低要求2C4G生产建议4C8G起步 nproc free -h # 检查磁盘空间至少20G可用 df -h # 确保各节点时间同步集群对时钟漂移极其敏感 timedatectl set-ntp true timedatectl status主机名的设置有个小技巧Kubernetes节点的主机名会作为Node对象的名字注册进集群而且不能和已有节点重复。我在一次扩容时有一台机器的主机名忘了改结果加进集群之后跟旧节点重名Pod调度直接错乱。所以下面三台机器的规划是这样角色主机名建议配置Masterk8s-master4C8G30G磁盘Worker-1k8s-worker-14C8G50G磁盘Worker-2k8s-worker-24C8G50G磁盘另外所有节点上最好把交换分区关掉或者调低swappiness。Kubernetes的kubelet默认不希望你用swap它希望用内存上限来精确控制Pod的QoS。swap一开内存回收的时机就变得不可控Pod可能被OOM Killer杀掉而kubelet还一团雾水。我这个版本已经比老版本宽容多了但还是别给自己挖坑。4.2 安装containerd并配置CRI插件之前提到Kubernetes通过CRI对接容器运行时所以我这里直接用containerd不装Docker。理由主要有两点第一containerd本身更轻资源占用小第二它的CRI接口是原生集成不需要额外做适配层。你要是装了Docker也得通过Docker专门开启containerd内置CRI才能被Kubernetes识别绕了一圈。# 安装必要依赖 apt update apt install -y apt-transport-https ca-certificates curl gpg # 添加Docker官方GPG密钥和源containerd属于Docker项目 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /usr/share/keyrings/docker.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | tee /etc/apt/sources.list.d/docker.list /dev/null # 安装containerd apt update apt install -y containerd.io # 生成默认配置并修改 mkdir -p /etc/containerd containerd config default | tee /etc/containerd/config.toml这里有一个绝对关键的修改SystemdCgroup要设置为true。如果不改Kubernetes和containerd会对容器cgroup的驱动方式产生分歧Pod启动后你会在kubelet日志里看到一堆cgroup相关的报错。我用的是sed命令直接替换# 修改SystemdCgroup开启cgroup v2的正确姿势 sed -i s/SystemdCgroup false/SystemdCgroup true/ /etc/containerd/config.toml # 修改sandbox镜像地址避免因网络问题拉不到pause镜像 # 如果你有条件访问原始镜像源可以直接跳过否则建议改成能访问的镜像源 grep sandbox_image /etc/containerd/config.toml # 重启containerd systemctl daemon-reload systemctl restart containerd systemctl status containerdsandbox_image这个参数指的是Pod的基础“沙箱”镜像每个Pod启动的时候首先得创建这个pause容器它负责承载Pod的网络和命名空间。如果你拉不到pause镜像所有Pod都会卡在ContainerCreating状态。国内用户经常会卡在这里所以我把这个改动也一起说了。测试containerd能否正常run容器可以用crictl工具# 安装crictl并设置端点 VERSIONv1.28.0 curl -L https://github.com/kubernetes-sigs/cri-tools/releases/download/$VERSION/crictl-linux-amd64.tar.gz | tar -C /usr/local/bin -xz cat /etc/crictl.yaml EOF runtime-endpoint: unix:///run/containerd/containerd.sock image-endpoint: unix:///run/containerd/containerd.sock timeout: 10 debug: false EOF crictl version4.3 安装kubeadm、kubelet、kubectl这把三件套用apt直接装。这里有版本锁定的讲究kubelet的版本不能和kubeadm、kubectl差太多而且kubelet的版本决定了你所管理的Kubernetes API版本能力。我统一用1.28.x后面校验版本命令会看到详细输出。# 添加Kubernetes官方GPG密钥和apt源 curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | gpg --dearmor -o /usr/share/keyrings/kubernetes.gpg echo deb [signed-by/usr/share/keyrings/kubernetes.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ / | tee /etc/apt/sources.list.d/kubernetes.list # 安装指定版本 apt update apt install -y kubelet1.28.2-1.1 kubeadm1.28.2-1.1 kubectl1.28.2-1.1 # 锁定版本防止apt upgrade误升级 apt-mark hold kubelet kubeadm kubectl这里得提醒一件事装完不要急着启动kubelet因为现在集群还没有启动kubelet会不断报错找不到API Server这是正常的。先检查一下这几个命令的版本kubeadm version kubectl version --client kubelet --version4.4 用kubeadm初始化单节点Master节点现在开始初始化集群。先拉取需要用到的镜像这样能提前暴露网络问题而不是等到kubeadm init所有步骤都卡住才发现kubeadm config images pull如果这一步骤出现镜像拉取超时解决思路有两个要么配置代理要么手动改kubeadm配置里的imageRepository为可访问的镜像仓库然后重新pull。我建议在没有特殊网络条件的情况下直接改为能访问的镜像仓库。修改方式如下kubeadm init --kubernetes-versionv1.28.2 --pod-network-cidr10.244.0.0/16 --apiserver-advertise-address192.168.1.10 --image-repository registry.aliyuncs.com/google_containers各参数解释一下。--pod-network-cidr是Pod网络的网段这个网段必须和后面安装的CNI插件要求一致。我这里写10.244.0.0/16是适配Flannel的默认网段如果你用Calico一般建议10.244.0.0/16或192.168.0.0/16具体按插件文档来。--apiserver-advertise-address是API Server对外宣告的IP必须是Master节点的真实IP不能写错不然后面Worker节点join不上。init执行成功后屏幕最后几行会输出三组关键信息第一组是kubectl配置文件拷贝命令第二组是Pod网络必须安装的命令提示第三组是kubeadm join指令后面Worker节点加入就用它。先执行配置命令mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config # 验证集群状态 kubectl get nodes kubectl get pods -n kube-system这时候Master节点状态应该显示NotReady因为还没有安装CNI插件。不要慌这是正常流程。4.5 安装CNI网络插件FlannelCNI插件负责实现Pod之间的网络互通和网络策略可以说是Kubernetes网络的基础设施。我推荐Flannel作为进阶者的第一款CNI原因有两条第一它的架构简单用VXLAN或host-gw模式好理解适合排查问题第二它和上面--pod-network-cidr指定的10.244.0.0/16正好匹配装完基本零配置就能通。kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml等待一两分钟之后查看kubectl get pods -n kube-flannel kubectl get nodes看到节点状态从NotReady变成Ready说明Master已经完成单机集群的就绪状态。Pod网路通了之后你可以先在这个Master上部署一个nginx测试一下然后把整个集群再扩容到三节点。这里单独说明如果想在Master上调度业务Pod得先移除Master的污点否则Pod只会调度到Worker节点。# 查看Master上的污点 kubectl describe node k8s-master | grep Taints # 单机测试时去掉污点生产环境不建议这样做 kubectl taint nodes k8s-master node-role.kubernetes.io/control-plane:NoSchedule-4.6 Worker节点加入组成分布式集群现在开始真正的分布式集群搭建。Worker节点上我重复执行前面4.1到4.3的步骤但不需要执行kubeadm init直接用Master初始化成功后的join命令即可。在Master节点上重新生成一条join指令万一之前的输出丢了或者过期了kubeadm token create --print-join-command注意token默认有效期是24小时如果过期就需要重新生成。这条命令会打印类似这样的内容kubeadm join 192.168.1.10:6443 --token abcdef.0123456789abcdef --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxx在k8s-worker-1和k8s-worker-2上分别执行这条命令然后回到Master节点查看kubectl get nodes kubectl get pods -n kube-system正常情况下你会看到三个Node都处于Ready状态。这里有一个经验之谈如果Worker节点一直没有Ready先别急着删掉重加。查看kubelet的日志判断原因命令是journalctl -u kubelet -f。比较常见的问题有join命令参数写错、hostname重复、证书过期、网络端口6443不通。4.7 部署nginx验证端到端流程集群建好之后用nginx做一次完整的发布验证。先创建一个Deployment指定两个副本并设置标签cat EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: nginx-demo labels: app: nginx spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.25-alpine ports: - containerPort: 80 EOF查看Pod调度情况注意观察两个副本会不会分别调度到两个Worker节点上kubectl get pods -o wide为了验证Service的负载均衡能力再创建一个Servicecat EOF | kubectl apply -f - apiVersion: v1 kind: Service metadata: name: nginx-svc spec: selector: app: nginx ports: - port: 80 targetPort: 80 type: NodePort EOF查看Service分配的NodePort端口kubectl get svc nginx-svc假设NodePort端口为32080任意一个节点的IP加上32080就能访问到nginx服务。你可以在Master上执行curl http://192.168.1.11:32080 curl http://192.168.1.12:32080两个地址都会返回nginx的欢迎页面说明流量已经能通过Service分发到不同的Pod上了。到这里从单机到分布式集群的核心链路已经打通。5. 我在实操中踩过的坑和排查思路这一节是很多官方文档不会告诉你的内容。我把自己在搭建和运维过程中真实遇到过的棘手问题整理成经验清单希望你能少走弯路。5.1 节点NotReady问题排查三板斧节点NotReady基本可以分成三种情况容器运行时异常、kubelet与API Server通信异常、网络插件异常。第一步先看kubelet服务状态systemctl status kubelet journalctl -u kubelet -n 100 --no-pager日志里有几个高频关键词要记住。如果看到“Failed to get systemd cgroup”说明SystemdCgroup配置没改对回去改containerd配置。如果看到“Unable to update cni config”说明CNI插件有问题检查Flannel DaemonSet的Pod日志。如果看到“container runtime is down”说明containerd服务挂了或者CRI端点没连上。第二步检查containerdsystemctl status containerd crictl ps第三步检查网络插件Podkubectl get pods -n kube-flannel -o wide kubectl logs -n kube-flannel -l appflannel --tail100大部分NotReady问题按照这套顺序排查都能定位到根因。千万不要一上来就node delete重加那样往往解决不了问题还可能引入更多不可控状态。5.2 containerd配置里的SystemdCgroup为什么如此重要这个点值得展开说一下。系统里的进程管理方式在现代Linux发行版上采用了cgroup v2而systemd接管了cgroup的权责划分。如果你的容器运行时和kubelet在cgroup驱动上不一致两个组件会同时尝试管理同一批进程的cgroup目录造成资源统计错乱严重时Pod会被错误地杀掉。判断当前系统是否使用cgroup v2grep cgroup /proc/filesystems输出中有cgroup2就说明用的是v2。在cgroup v2环境下SystemdCgroup true是准没错的。每次我搭新环境第一件检查事情就是它。5.3 Worker节点加入集群后Pod一直ContainerCreating正常情况下join成功后Pod开始创建。但如果卡在ContainerCreating大概率是镜像拉不下来。用crictl查看crictl images crictl pull nginx:1.25-alpine如果拉镜像超时可以在每个Worker节点上配置一个镜像仓库加速或者手动拉到本地。还有一个被我忽略很久的细节Flannel的镜像如果在Worker节点上拉不到整个Pod网络就无法建立节点状态永远NotReady。所以我在安装Flannel之前会在所有节点先把相关镜像拉好。5.4 kubeadm token过期后如何重新获取我之前已经出现过多次token过期的情况这里再补一发完整的重新生成命令kubeadm token list kubeadm token create --print-join-command新生成的join命令可以直接复制到Worker节点执行。如果你的ca-cert-hash也忘记了可以用这个命令找回openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2/dev/null | openssl dgst -sha256 -hex | sed s/^.* //格式化的join命令生成之后建议临时保存到一个文件里避免再次丢失。5.5 生产环境扩容时最容易忽略的资源规划问题很多人在扩容集群的时候只看CPU内存够不够忽略了三个隐性因素端口号冲突、IP地址段规划、镜像仓库连通性。集群节点之间需要开通的端口包括Master的6443API Server、2379-2380etcd、10250kubelet、10259kube-scheduler、10257kube-controller-manager以及NodePort范围默认的30000-32767。如果你的安全组或防火墙没有放行这些端口节点之间通信会各种超时。IP规划上Pod网段、Service网段、Node真实IP网段三者不能重叠。我曾经在测试环境里不小心把Pod网段设成了和某个网络设备冲突的地址结果Flannel的路由一直错误Pod间通信彻底断了。改起来非常痛苦因为涉及每个节点的路由表。所以初始化之前这三个网段的规划一定要先画清楚。镜像仓库连通性这个对生产集群尤其重要。建议搭建一个内部的镜像仓库把所有业务镜像提前push进去然后配置containerd的registry mirror。不要在集群运行时才拉公网镜像一旦网络抖动Pod启动就全卡住了。6. 一个更稳妥的分布式集群架构补充建议从单机到三节点这个阶段你已经掌握了Kubernetes最核心的交互逻辑。但如果你真正要上生产我建议你在上述集群的基础上做三件事。第一件事把Master的控制平面做成高可用。三个Master节点共享一个虚拟IP用Keepalived或者云厂商的负载均衡器来承载API Server通过这个VIP对外提供服务。这样任何一个Master挂了其余Master能继续处理请求etcd依然能凑够投票的法定人数不会脑裂。具体操作步骤这次不展开了但你至少要知道单Master节点的容错性为零是不能抗生产的。第二件事严格控制工作负载在Master上的调度。我前面为了单机测试临时移除了Master的污点。生产环境里一定要让Master只跑控制面组件和必要的附加组件业务Pod全部调度到Worker节点。如果你的集群规模小到只有两个Worker那也应该通过节点亲和性和污点容忍做到按角色隔离不要贪图方便让Master混跑业务。第三件事启用Kubernetes的审计日志和监控告警。审计日志能记录操作者对集群的每次变更监控方面至少要采集节点指标和Pod指标。没有监控你根本不知道集群什么时候会出问题等用户反馈才发现故障就已经太晚了。我习惯在环境搭好之后立刻部署Prometheus kube-state-metrics node-exporter第一时间看到集群健康度曲线。7. 常用运维命令速查最后送大家一份我平时高频使用的命令清单。它涵盖集群管理、资源查看、日志排查、故障隔离都是实际工作中反复用到的。查看类# 查看节点状态和资源 kubectl get nodes -o wide kubectl top nodes # 查看Pod状态和调度位置 kubectl get pods -o wide -A kubectl describe pod pod-name -n namespace # 查看Service和Endpoint kubectl get svc -A kubectl get endpoints -A操作类# 进入Pod容器执行命令 kubectl exec -it pod-name -n namespace -- /bin/sh # 实时查看Pod日志 kubectl logs -f pod-name -n namespace # 复制文件到Pod内 kubectl cp ./local-file pod-name:/tmp/remote-file -n namespace # 临时端口转发调试 kubectl port-forward svc/nginx-svc 8080:80排障类# 查看kubelet日志 journalctl -u kubelet -f # 查看containerd中的容器和镜像 crictl ps -a crictl images # 查看事件Events非常关键新手总是习惯只看Pod状态忽略events kubectl get events --sort-by.metadata.creationTimestamp -A最后再说一个我个人的使用心得kubectl的字段选择器和标签选择器非常好用比如你想一次性删除某个标签下的所有Podkubectl delete pods -l appnginx-demo还可以结合jq做更复杂的输出解析比如获取所有节点的内部IPkubectl get nodes -o json | jq -r .items[].status.addresses[] | select(.typeInternalIP) | .address有了这些命令日常操作会顺手很多。这个项目从单机构建到三节点分布式集群整体走下来我的体会是Kubernetes的学习曲线确实陡峭但它陡在每个组件各司其职而你只需要理解它们的协作关系。环境搭建出问题时不要急着到处搜索复制命令先静下心看日志找线索日志会告诉你绝大多数问题的真相。希望这篇文章能成为你从Docker走向Kubernetes的一条稳定过道让你少撞几面墙。