Kubernetes入门：从核心概念到集群搭建与部署实战

1. 先搞清楚k8s到底在解决什么问题

先说个场景，你去年在几台服务器上用Docker部署了业务，平时人少的时候还挺安稳。结果今年流量涨了，每次发版要靠人去登录机器拉镜像、重启容器，扩容要提前申请机器、手动加副本，流量一来某个节点挂了，还得半夜爬起来恢复服务。这时候你大概率已经听过“要不上一套k8s吧”。

k8s，全称Kubernetes，是容器编排领域的实际标准。它做的核心事情可以概括成一句话：把一堆服务器变成一个资源池，然后你告诉它“我要跑多少个实例、每个实例用什么镜像、需要多少CPU和内存”，它自己去调度、去拉起容器、去保持副本数稳定。你不直接操作具体的某台机器，你面对的是一个“集群”。

为什么大家都说它扫盲难？因为它涉及的概念确实多，而且很多概念之间相互关联。但换个思路看，你不需要一开始就搞懂所有内部机制，你只需要先回答清楚三个问题：它解决了我什么痛苦？它里面有哪些常用对象？我怎么把一个应用跑起来？

这篇文章就按这个顺序来说。适合谁看呢？适合那些用过Docker、但还没真正上手过k8s的人，也适合刚被安排去搭建集群、但不知道从哪下手的同学。我不会讲过于底层的架构源码，重点是把“用得起来”这件事讲透。

1.1 单机容器时代的“手工运维”困境

在k8s出现之前（或者说没有编排工具的情况下），用Docker部署服务是什么状态？你会在每台服务器上安装Docker，然后用docker run把容器拉起来，用--restart=always保证进程挂了能自动重启。这是单机自愈，但它有几个很现实的问题：

• 你无法自动把容器调度到空闲的机器上。所有实例都靠人肉记录“哪个服务部署在哪台机器”。
• 滚动更新很难做。要么停机更新，要么自己写脚本先启一批新的再杀旧的，脚本一旦没写好，发布到一半状态就很尴尬。
• 没有服务发现。容器A要访问容器B，你得通过端口映射、外部负载均衡或者手工维护的配置文件去连通。容器一旦换了一台机器，IP变了，你得改配置。
• 弹性伸缩基本靠运维人员“看见告警了再去加容器”，而且加完之后机器资源够不够也不好说。

我见过很多团队在没有k8s时，会自己写一套“基于SSH连接远程主机、批量执行Docker命令”的部署脚本。刚开始十几台机器、五六个服务还能忍，服务数量涨到几十个后，这套脚本就成了定时炸弹。某个服务发布失败都不知道是脚本bug还是环境差异，排查一次发布事故要花掉大半天。这不是说Docker不好，而是当你的规模上去后，单靠命令行和脚本管理容器，人的精力根本跟不上机器的节奏。

1.2 k8s给出的答案：声明式编排

k8s最大的思想转变在于，从“命令式”变成“声明式”。

命令式是什么？就是你告诉计算机“下一步做什么”。你输入docker run nginx，就是把nginx这个容器拉起来。你要扩容到10个容器，你得再输入9遍，或者写一个循环脚本。你要让这10个容器分布在不同机器上，你得知道每台机器还剩多少资源，然后手动指定。

声明式是什么？你告诉k8s“我期望最终的状态是10个nginx副本”。你写入一个YAML文件，里面写replicas: 10，然后提交给k8s。剩下的调度、拉起、健康检查、保持存活，全部由k8s内部的控制器循环去处理。如果有一台机器宕机了，上面有3个nginx副本，k8s会因为“当前实际副本数是7、期望是10”而在其它健康的机器上自动补3个。

这就像你以前每天打电话给餐厅订餐，说“今天要3份饭”，到了明天说“今天要5份饭”。而声明式是你直接告诉餐厅“我每天中午都需要保证桌上有5份饭”，至于哪桌怎么送、几点送达，餐厅自己去安排。你还是需要表达你的需求，但你不用再关心一个个具体操作。

1.3 哪些人最需要关注k8s

如果你所在的团队有以下几种情况，优先级可以往前提：

1. 微服务数量增多。服务数量超过二三十个，部署、回滚、配置管理都已经开始互相牵扯。
2. 流量有明显的峰谷。比如每天固定时间流量暴涨，需要快速扩容、闲时缩容。
3. 频繁发布迭代。一天要发很多次，每次发版都要手动操作，已经成了流程瓶颈。
4. 资源利用率低。平均每台机器负载不到20%，但你不敢回收机器，因为担心某台机器上的服务会受影响。

如果你只是在一台服务器上跑两三个服务，k8s对你不一定是刚需，你完全可以继续用docker-compose。但如果已经遇到上述痛点，早一点把编排能力建立起来，后续会省下非常多的人工成本和沟通成本。

2. 扫盲第一课：必懂的核心概念

这一部分我建议你当作“高频词汇手册”来看，不用背，知道它们是什么、在什么场景下出现，就能读得懂配置文件了。

2.1 Pod：k8s调度的最小单位

很多新手最大的困惑在于：我都已经有容器了，为什么还搞出个Pod？

一方面，k8s不直接操作容器，它认为Pod才是它调度和管理的最小单元。Pod是一个逻辑边界，里面可能运行一个容器，也可能运行多个容器。为什么需要多个容器在同一个Pod里？典型场景是边车模式（Sidecar）。比如你的业务容器是一个Web应用，旁边再挂一个日志收集容器，它俩共享网络栈和存储卷，能通过localhost直接通信，日志文件也不用跨容器拷贝。

你只需要记住一个结论：**同一Pod里的容器共享同一个IP、同一组端口和同一份存储卷，并且它们会被调度到同一台物理机上。**如果需要解耦的、各自独立扩展的服务，应该分成不同的Pod。

举个生活化类比：Pod像一个合租公寓，里面住着的几个容器室友共享水电表（网络和存储），这间公寓是整个楼栋（Node节点）里的基本出租单元，而k8s就是那个管家，它不关心室友们内部怎么分工，只管把整间公寓分配到哪栋楼去。

2.2 Deployment：你想要的副本数由它保证

你要运行一个服务，不会直接去创建Pod，因为Pod没有自愈能力——如果Pod所在的机器宕了，Pod就没了。所以你应该创建Deployment。

Deployment是k8s里最常用的控制对象，它负责管理一堆Pod副本，并保证期望的副本数。它内部还会创建ReplicaSet（副本集），Deployment的每次更新都会生成新的ReplicaSet，用来做版本管理。你改一下镜像版本，重新apply配置，Deployment就会滚动更新，一个一个替换Pod，期间服务不会全部停止。

这个对象承载了三个能力：扩容缩容、滚动更新、回滚。

打个比方，Deployment就是“门店的店长”，ReplicaSet是“排班表”，Pod是“员工”。店长一声令下“今天店里需要有10个人上班”，排班表会拉出一个10人的团队。如果一个人请假了（Pod挂了），排班表自动补充一个人进来。店长说“明天换成另一套服务标准”，排班表全部换一批员工。如果新标准出了问题，店长说“退回今天的那套”，排班表又恢复到上一个版本。

2.3 Service与Ingress：外部流量怎么进得来

你的应用在Pod里跑，Pod是有生命周期的。容器重启、节点迁移，IP都会变化，你不能让调用方记住某个Pod的IP。Service就是解决这个问题的“抽象层”。

Service给一组Pod提供了一个稳定的虚拟IP（ClusterIP），以及一个DNS名字。你部署了一个名为nginx的Deployment，然后创建同名的Service，集群内部其它应用就可以通过http://nginx:80来访问它。Service背后会自动关联匹配Label标签的Pod，并把请求负载均衡到各个健康的Pod上。

Ingress则负责集群外部访问的路由。它更像一台“七层路由”，可以通过域名和路径把请求转发给不同Service。比如你有一个域名api.example.com，可以配置Ingress规则，把/user开头的转发给用户Service，把/order开头的转发给订单Service。

这两个概念刚学时比较容易和Service的NodePort模式搞混。简单区分一下：

• ClusterIP Service：仅供集群内部访问。
• NodePort Service：通过“每台节点IP + 随机高位端口”从集群外部访问。
• LoadBalancer Service：云平台场景下创建负载均衡器，把流量打到节点上的某个端口。
• Ingress：在HTTP/HTTPS层面按域名和路径做路由，集群外部流量先到Ingress控制器，再由它转发给内部Service。

2.4 Namespace、ConfigMap、Secret这些“辅助角色”

Namespace用来隔离资源。你在团队里划环境、划部门都可以用它区分。比如dev、prod各建一个Namespace，里面的资源互不影响。新手刚上手时如果分不清，就在默认的default命名空间里操作；当资源多到无法一眼找到时，再考虑拆分。

ConfigMap和Secret都是配置管理的载体，区别是Secret用于存放敏感信息，比如数据库密码、API密钥，存储的值会做base64编码。ConfigMap存普通配置，比如环境变量、配置文件内容。它们的好处是配置和镜像解耦，不用改代码和镜像就能调整运行参数。

这组概念确实杂，但我建议按使用频率去消化：Deployment和Service是最常用、最先要懂的，Pod是你要排障时必须面对的，Namespace是项目大到需要隔离时再用，ConfigMap和Secret则是你学会写YAML之后自然而然就会遇到的。

3. 动手实操：在真实集群上把应用跑起来

概念讲完了，现在就差动手。我推荐一条不走弯路的上手路线：先用生产可用的工具（比如kubeadm）搭一个三节点集群，在上面部署一个nginx应用，把它从集群内部和外部都访问一遍。这个流程走通，你基本上就有“k8s似乎也没那么神秘”的实感了。

很多新人上来就想着先学Docker Compose，再学minikube，最后再接触kubeadm。这种路径有它的理由，但面对“k8s扫盲”这个目标，我更建议直接进入集群世界的思维模式。因为k8s和单机的思考方式差异很大，越早切换越好。

3.1 节点规划与基础环境准备

为了模拟生产又不复杂，可以准备三台Linux服务器（虚拟机就行，云主机也行）：

master节点主要负责集群的管理控制，worker节点负责调度运行应用容器。你需要配置好三台机器的静态IP，保证它们之间可以互相ping通，并且都能访问镜像仓库。内存不能太小，否则集群初始化后系统组件本身的负载就把机器压垮了，后面排障都变困难。

然后是容器运行时的选型。很多人纠结装Docker还是containerd。直接从k8s 1.24版本之后，dockershim已经被移除，kubelet不再直接兼容Docker了。虽然你依然可以在节点上装Docker，但最终kubelet对接的还是containerd。所以新手直接用containerd作为运行时，反而少一层适配问题。

我实测下来，Ubuntu系安装比较省心，因为内核版本较新，iptables相关的兼容性也比较好。三台机器上执行以下基础操作：

关闭swap，swapoff -a并注释掉/etc/fstab里的swap行。为什么必须关？因为kubelet在资源管理上如果发现swap在用，它的cgroup资源统计就会出现偏差，节点调度时算不好内存容量。

加载两个内核模块：

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter

配置sysctl，让IPv4流量转发和iptables对桥接流量可见：

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF sudo sysctl --system

这些看起来像是“仪式感”操作，但每一条都有实际作用。不装br_netfilter的话，集群内Pod之间通讯经过网络插件时，iptables规则可能匹配不到转发的流量，导致网络通不了，排查起来非常挠头。

3.2 安装containerd与crictl

很多新人在安装containerd之后，启动容器会报错，例如failed to load cni config: file does not exist之类。原因多半是containerd默认没有启用CNI配置，或者SystemdCgroup没有设置为true。这一步不做对，后面初始化集群Pod时大概率失败。

先安装依赖并添加官方源，然后安装：

sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg lsb-release sudo mkdir -p /etc/apt/sources.list.d # 添加docker官方源的步骤略，不同系统下源的配置方式不同 sudo apt-get install -y containerd

装好后需要初始化containerd的默认配置：

sudo mkdir -p /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml

然后修改这个config.toml，重点有两处：

1. 找到SystemdCgroup，把false改成true。这是因为kubelet以systemd作为cgroup驱动，containerd要和它统一，否则两边管理出现分歧。
2. 如果你在的网络环境访问官方镜像仓库比较吃力，可以在sandbox_image处把pause镜像源换成一个自己方便访问的源地址。这一步介于可改与不可改之间，取决于实际环境，我先按下不表，等遇到镜像拉取问题时再展开。

改完重启：

sudo systemctl restart containerd sudo systemctl enable containerd

同时安装crictl命令行工具，它是containerd生态里检查容器运行时的重要调试工具。后面排查容器启动失败时，crictl ps -a、crictl logs <container>是最高频的命令。

3.3 用kubeadm初始化master节点

三台节点都装好kubeadm、kubelet、kubectl之后，先在master节点执行初始化：

sudo kubeadm init --apiserver-advertise-endpoint=192.168.x.x --pod-network-cidr=10.244.0.0/16

--apiserver-advertise-endpoint填master节点的IP。--pod-network-cidr必须和后面安装的网络插件对应，比如用Flannel就用10.244.0.0/16，用Calico则用192.168.0.0/16，两者不能冲突，否则Pod网段和Service网段会乱套。

初始化成功后，会输出一段kubeadm join命令，包含token和ca证书hash，这个token默认24小时后过期。如果之后才发现忘了保存，也可以重新生成：

kubeadm token create --print-join-command

root用户执行初始化后，普通用户要连集群还要配置一下kubectl的权限文件：

mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config

这里有一个常见的坑：如果不复制admin.conf，而是直接尝试用kubectl get nodes，会报一个connection refused或者权限不足的错误。原因是kubectl默认读取$HOME/.kube/config，而kubeadm把配置生成了在/etc/kubernetes/admin.conf，两者路径没对上。

初始化完成后你会看到master节点的状态是NotReady。先不用慌，这是正常的，因为没有安装网络插件。网络插件是必须装的，它负责给每个Pod分配集群内的虚拟IP，并打通跨节点Pod间流量。以Flannel为例：

kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

然后过一两分钟再查状态：

kubectl get nodes

看到STATUS变成Ready，就算master节点完成了。

3.4 把worker节点加入集群

在worker节点上执行刚才保存的kubeadm join命令。加入后，如果节点加入失败，多半是token过期或者--cri-socket参数没有指定到containerd。如果你的节点装了不止一个容器运行时，必须添加：

kubeadm join 192.168.x.x:6443 --token xxx --discovery-token-ca-cert-hash sha256:xxx \ --cri-socket unix:///var/run/containerd/containerd.sock

在master上再查询，看到两个worker节点都Ready，就可以进行下一步了。

3.5 部署一个nginx应用并验证访问

既然集群已经就绪，我们就跑一个最经典的nginx Deployment：

kubectl create deployment nginx-demo --image=nginx:latest

为了确保正常访问，还可以通过文件方式创建。我个人建议从第一个YAML开始就用文件管理，因为后面你一定会越来越依赖Git管理这些配置。以下是最简示例：

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

保存为nginx-deploy.yaml，执行：

kubectl apply -f nginx-deploy.yaml

等待Pod拉取镜像并变成Running：

kubectl get pods -o wide

再创建一个Service，让集群内能稳定访问：

kubectl expose deployment nginx-demo --port=80 --target-port=80 --type=ClusterIP

然后你在集群内任意一台节点上，用Service的ClusterIP试一下：

curl http://<ClusterIP>

能看到nginx欢迎页，说明集群内部链路已经打通。如果你还想从集群外访问，可以把Service改成NodePort：

kubectl get svc nginx-demo # 找到显示的端口，比如80:32345/TCP

然后浏览器访问http://<任意节点IP>:32345，同样能看到页面。

这一步跑通，你对“Deployment管副本、Service管访问”的理解就能落地了。接下来不管你用不用深度知识调优，至少对k8s的运作模式已经建立了直觉。

4. 新手入坑最常见的几个“坑”

说实话，k8s出问题的时候，报错信息经常不是一般人能一眼看懂的。我把自己踩过的一些坑整理出来，你们碰到类似问题时可以少走弯路。

4.1 Pod一直Pending，半天起不来

Pending状态说明Pod在调度阶段就被卡住了。可以先看具体原因：

kubectl describe pod <pod-name>

里面Events字段会给出线索。最常见的几类原因：

1. 节点资源不足。节点头上标有taint（污点），或者CPU、内存都已被占满，Pod无法调度。这时你可以kubectl describe node <node-name>查看Allocatable资源。
2. 镜像拉取失败。Events里会出现Failed to pull image或Back-off pulling image。这种情况在下一节单独说。
3. PVC无法绑定。如果Pod声明了持久化存储，而对应的StorageClass没有提供动态供给，PVC会一直Pending，Pod自然起不来。

还有一种容易忽略的情况：master节点默认有NoSchedule污点，用来防止Pod调度到master上。如果你在测试环境只有单节点，可以在master上执行：

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

注意这个命令会移除所有节点上的控制平面污点，可以让Pod正常调度到master。生产环境不建议这么干，但单机学习时它是最快的一条路。

4.2 镜像拉取失败的正确排查顺序

新手在这里最容易懵，因为错误信息五花八门。我的排查顺序是：

1. 先看是否能本地手动拉取。在节点上执行crictl pull nginx:latest，如果这个都失败，说明确实拉不下来，基本是网络或仓库源问题。
2. 再看containerd配置里的sandbox镜像（pause）是否可用。pause镜像如果拉不下来，Pod也会卡在ContainerCreating。
3. 最后看是否设置了私有仓库认证。私有仓库需要先在节点上配置Docker registry的认证文件，并且要在kubelet/containerd层面做好引用。如果是自签证书的仓库，还要处理证书信任问题，着实不省心。

如果默认镜像源速度太慢，可以改containerd的config.toml配置，通过增加镜像的endpoint列表来指定一个更快、可用的镜像地址。这种配置方式灵活度较高，但每个版本写法略有不同，改完一定要重启containerd再测试。

4.3 节点显示NotReady，问题排不出

节点变成NotReady，首先是看kubelet是否活着：

systemctl status kubelet sudo journalctl -u kubelet -f

大多数情况下，kubelet日志里会出现类似failed to run Kubelet: ... misconfiguration: kubelet cgroup driver = systemd but cgroupfs is set的报错，这就是典型的cgroup driver不一致问题。但这种情况一般发生在老版本上。新版本里更常见的是网络插件问题。尤其是重启过节点之后，Flannel或Calico的Pod没起来，节点会仍然处于NotReady状态。

处理方式很直接：

kubectl get pods -n kube-flannel # 或者 kubectl get pods -n kube-system

看对应的网络组件Pod有没有Running。如果一直CrashLoopBackOff，删掉让它重新调度一次，多半能恢复。

还有一种很隐蔽的情况：如果你更换了节点IP，或者修改了/etc/hosts里的主机名映射，会导致kubelet上报的IP地址变化，进而让控制平面无法和节点通信。改主机名也该在装集群之前一次性定好，之后尽量避免变更。

4.4 想在一台机器上快速体验，怎么办？

如果你暂时拿不出三台机器，只是想快速看一眼k8s长什么样，可以用minikube或者Kind。minikube适合本地单机体验，它内部自带一个虚拟机或使用Docker，配置较轻。Kind更绝，直接在Docker容器里跑一套集群，每条Node都是一个容器。对于本地学习、写demo、调YAML非常友好。

不过它们的宿主机性能要求不低。minikube共默认分配2核2G，如果你电脑只有16G内存，也建议至少给k8s相关环境富余一部分出来，否则集群起来后Pod之间访问的体验会很差，出现莫名其妙的超时。等你理解了k8s的基本操作，还是建议回到kubeadm方式搭一套真正的多节点集群。毕竟很多问题只有在多节点场景才会暴露出来，比如跨节点Pod连通、节点容忍度、亲和性调度等。

4.5 关于kubectl高频命令的建议

最后补充一个我用得最多的命令清单：

# 查看资源状态，-w可以实时监听 kubectl get pods -w kubectl get nodes -o wide kubectl get svc # 详细查看事件，排障核心 kubectl describe pod <名称> # 进入容器 kubectl exec -it <pod名称> -- bash # 查看容器日志 kubectl logs <pod名称> # 临时端口转发，适合本地调试内部服务 kubectl port-forward svc/nginx-demo 8080:80

port-forward是个宝藏命令。很多服务没有对外暴露时，测试接口、调本地代码联调，都可以用它临时打通隧道，不需要特意改Service类型。

根据我个人的经验，k8s扫盲最大的门槛并不在某个单独概念有多难，而是信息太碎、术语太密，新手容易迷失在细节里。如果你能先把“Deployment管应用、Service管访问、Pod是基本单位、Node是机器抽象”这条主线抓住，再往下学就自然很多。遇到问题也不要慌，多用describe多看Events，大部分问题都会在事件里直接告诉你答案。

如果看完这篇文章，你能在一套真实的集群上成功部署一个应用并打开页面，那这个门槛基本上就算踏过去了。之后无论是继续研究Ingress、Helm，还是深入调度和网络插件，都会有自己的节奏。