Kubernetes 入门到实战:把概念讲人话

官方文档一打开,Controller、Reconcile、CRD、CNI、CSI……一堆词砸过来,大多数人在第三页就放弃了。但说实话,K8s 的核心概念比它看上去简单得多——你只要想清楚"把一个 web 应用跑在多台机器上需要解决哪几件事",剩下的只是术语映射。

这篇文章不讲全套,只讲一个开发者真正需要懂的那 20%,并带你本地跑通一个应用。

一、K8s 到底解决了什么问题

先不谈概念,想象一个场景:你写了个 web 服务,用 Docker 跑得好好的。某天流量来了,你要扩到 3 个实例,还要保证挂掉一个能自动拉起来、升级的时候不能停服、配置不能写死在镜像里、还要能通过一个域名访问。

这些事你自己用 docker run + nginx + 一堆 shell 脚本也能凑合干,但一上规模就崩。K8s 就是一个专门干这些"容器周围杂活"的系统,业内叫"容器编排",说白了就是:

• 多机部署:把容器调度到一群机器上跑,哪台机器资源够就放哪台
• 扩缩容:一行命令(或一个指标)把实例数从 3 变成 30
• 自愈:某个容器挂了、某台机器宕机了,自动在别处重新拉起来
• 滚动更新:新版本灰度上线,一个一个换,不停服
• 配置/密钥管理:配置和镜像解耦,同一镜像能跑 dev/staging/prod

这些能力组合在一起,就是 K8s 的价值。它不是"让单机跑 Docker 更顺",而是"让你能像管一台机器一样管一百台机器"。

二、核心对象,用大白话讲

K8s 里一切都是"对象"(声明式的 YAML),你告诉系统"我想要的状态",它负责把现状调成你想要的样子。核心就那么几个,我用公司组织架构来类比:

Pod(豆荚)—— 最小运行单元。注意,不是容器。Pod 是 K8s 调度的最小单位,里面可以放一个或多个紧耦合的容器(共享网络和存储)。99% 的情况下一个 Pod 就一个容器,所以你可以粗略地把 Pod 理解成"一个被 K8s 管着的容器实例"。但它有自己独立的 IP,Pod 内的容器共享这个 IP。

Deployment —— Pod 的经理。你很少直接创建 Pod,而是写一个 Deployment,告诉它"我要 3 个这种 Pod 的副本",它就会帮你维持这个数量(少了自己补,多了自己杀)。滚动更新和回滚也是它负责的。Deployment 像一个永远盯着副本数的工头。

Service —— Pod 的稳定门牌号。Pod 是会死会重生的,每次重启 IP 都变,你没法直接拿 IP 去访问。Service 就是在一组 Pod 前面挂了一个固定的名字和 IP,顺带做负载均衡。你访问 Service,它自动把流量转发到后面某个活着的 Pod 上。

Ingress —— 集群的对外大门。Service 默认是集群内部的,想要从外面(浏览器)通过域名访问,还得有个东西接住 80/443 端口的流量、根据域名路由到对应的 Service,这就是 Ingress。你可以理解成集群版的 nginx。

ConfigMap / Secret —— 配置和密钥。把配置文件、环境变量从镜像里抽出来,以文件或 env 形式挂进 Pod。Secret 和 ConfigMap 用法一样,只是 base64 编码了一下、语义上表示"这是敏感数据"(别真拿它当加密用,生产环境还是要配合 KMS 或外部 secret manager)。

记住这五个 + Secret/ConfigMap,你已经能搞定 80% 的日常了。CRD、Operator、调度策略那些高级货,等你真的需要再学。

三、它们是怎么协作起来的

一句话串起来:请求从外面进来,先撞上 Ingress,Ingress 根据域名转给某个 Service,Service 再负载均衡到 Deployment 管着的一堆 Pod 里。

具体一次 HTTP 请求的旅程:

浏览器 → Ingress Controller(集群大门,80/443)
        → 按域名匹配 Ingress 规则
        → 转发到 Service(一个虚拟 IP + 域名)
        → Service 用 label selector 找到所有匹配的 Pod
        → 负载均衡到其中一个 Pod
        → Pod 里的容器处理请求

而 Deployment 在背后一直盯着副本数,某个 Pod 挂了就再拉一个顶上,对外完全无感。ConfigMap 和 Secret 在启动时就被挂进去,容器读到的就是当前环境的配置。

这张图一旦在脑子里成型,后面所有的 yaml 你都能对号入座。

四、本地实操:5 分钟跑起来一个应用

别等线上才第一次摸 K8s。本地有两条路,任选其一:

• kind(Kubernetes in Docker):用 Docker 容器模拟 K8s 节点,启动快、资源占用小,个人首推
• minikube:老牌方案,功能全,但比 kind 重一点

装好后,kubectl 就是你的唯一遥控器。下面以部署一个 nginx 为例。

先建 deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3                  # 我要 3 个副本
  selector:
    matchLabels:
      app: my-app              # Deployment 通过这个 label 找它管的 Pod
  template:                    # Pod 的模板
    metadata:
      labels:
        app: my-app            # 给 Pod 打上同样的 label(关键!)
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits:   { cpu: 500m, memory: 256Mi }

再建 service.yaml,给这些 Pod 一个稳定入口:

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app                # 同样靠 label 找 Pod
  ports:
    - port: 80                 # Service 对外的端口
      targetPort: 80           # 转发到容器的端口
  type: ClusterIP              # 默认类型,集群内可访问

两条命令搞定:

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

kubectl get pods          # 应该能看到 3 个 Running 的 Pod
kubectl get svc my-app    # 看到 Service 分配的集群 IP

想从本机浏览器访问?本地开发用 port-forward 最快:

kubectl port-forward svc/my-app 8080:80
# 访问 http://localhost:8080

线上要域名访问时,再加一个 Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app
                port:
                  number: 80

看出来了吗?每个对象各管一摊,通过 label 串起来。selector 和 labels 对得上,流量就能流到对的地方——这是 K8s 最核心的"接线"机制。

五、kubectl 日常操作(背下来就行)

这些命令你每天都会用,熟到肌肉记忆:

# 看状态
kubectl get pods / deployments / svc / ingress
kubectl get pods -o wide            # 带 IP 和节点
kubectl describe pod <name>         # 排错神器,看事件和状态

# 看日志 / 进容器
kubectl logs <pod>                  # 看日志
kubectl logs -f <pod> --tail=100    # 实时跟踪最后 100 行
kubectl exec -it <pod> -- sh        # 进容器敲命令

# 扩缩容(秒级)
kubectl scale deployment my-app --replicas=5

# 滚动更新:改镜像就算
kubectl set image deployment/my-app nginx=nginx:1.28
kubectl rollout status deployment/my-app    # 看进度

# 回滚(出事了救命用)
kubectl rollout undo deployment/my-app
kubectl rollout history deployment/my-app   # 看历史版本

记住一个原则:能用 yaml 描述的就别敲命令。kubectl create 这种命令式操作只适合临时实验,正式环境一律 kubectl apply -f,版本控制起来,后面接 GitOps(CI/CD 推 yaml)才顺。

六、什么时候该上 K8s,什么时候别上

这点很重要,因为 K8s 不是银弹,它是一种有显著运维成本的技术选择。

该上的场景:

• 多服务、多语言、多团队,需要统一的部署和治理底座
• 有多机部署、跨可用区高可用的真实需求
• 流量波动大,需要根据指标自动扩缩容
• 团队有人能持续投入维护(K8s 集群本身要打补丁、升级、监控)

不该上的场景(别给自己找罪受):

• 一个单体应用 + 一个数据库的小项目,docker compose 5 行配置搞定
• 没有 DevOps 人手的小团队,上 PaaS(Render、Fly、阿里云 SAE、Vercel)能解决 90% 的事
• 压根没有多机需求,一两台 ECS 就够用

我见过太多团队因为"看起来高级"上 K8s,结果没人维护,版本停在 1.2x 不敢动,证书过期、etcd 出问题、CNI 网络抽风……K8s 的复杂度是借来的债,你迟早要还。

一个朴素的标准:如果 docker compose 已经开始让你难受了(比如要多机、要自动扩缩容、要零停机更新),再认真考虑 K8s。在那之前,所有"为了未来扩展性"而引入 K8s 的决定,大概率会成为负资产。

七、学习路径建议

最后给一条不会走弯路的路径:

1. 先把一个应用跑通。别一上来啃架构图。按本文第四节的步骤,在 kind 里把一个 Pod + Service + Ingress 完整跑一遍,访问到响应为止。
2. 把 kubectl 的十几个常用命令用熟。get / describe / logs / exec / apply / rollout 这几个能覆盖 90% 日常。
3. 理解声明式和 Reconcile 的思想。K8s 之所以是 K8s,核心在这个"我告诉你想要的状态、系统持续把现状调成那样"的模型。吃透这一点,后面 CRD、Operator 都是一脉相承。
4. 再学 Helm(包管理)、Ingress Controller 选型、持久化存储(PV/PVC)。
5. 最后才是进阶:调度策略、网络插件原理、RBAC、GitOps(ArgoCD)、Service Mesh。

顺序千万别反。我见过太多人一上来啃《Kubernetes 权威指南》六七百页,啃完还是不会部署一个应用。

小结

• K8s 的价值在容器编排:多机调度、扩缩容、自愈、滚动更新,不是"让 Docker 更好用"
• 核心对象就五个:Pod(运行)→ Deployment(管理)→ Service(门牌)→ Ingress(大门)→ ConfigMap/Secret(配置),靠 label 串起来
• 请求链路:Ingress → Service → Deployment 管的 Pod,这条线在脑子里成型,剩下都是细节
• 本地用 kind,apply 一份 yaml 就能跑通,别等线上才学
• K8s 是有运维成本的负债,不是 KPI 装饰品。小项目请用 docker compose 或 PaaS

一句话收尾:别被文档吓住,先跑通一个应用。会用 K8s 的人,和只会背 K8s 概念的人,中间隔着一百次 kubectl apply。