Kubernetes 入门部署指南：从零搭建 K8s 集群

两三台服务器的时候，用 Docker Compose 就够了；等应用拆成十几个服务、需要自动扩容、要应对节点宕机时，单机的容器编排就开始吃力。Kubernetes（K8s）就是为这个规模而生的容器编排系统——它管理容器的调度、扩缩容、自愈和滚动更新，已经成为云原生时代的「操作系统」。本文从概念讲起，带你用 minikube 在本地搭一个能动手的集群。

一、核心概念

先建立一套最小的心智模型，K8s 里天天打交道的就这几个对象：

概念	说明
Pod	最小的部署单元，包含一个或多个容器，共享网络和存储
Service	网络抽象层，为 Pod 提供稳定的访问入口
Deployment	声明式地管理 Pod 的副本数、镜像版本和滚动更新
Namespace	逻辑上的资源隔离分组，多团队/多环境用
ConfigMap	把配置从镜像里抽出来，不重新构建就能改
Secret	管理密码、token 等敏感信息的专用对象

理解 Pod 是理解一切的基础。Pod 是调度的最小单位，一个 Pod 里的容器共享同一个 IP；Service 则负责把「会变动的 Pod IP」收敛成一个稳定的入口，客户端只需要记住 Service 的名字。

二、本地搭建（Minikube）

不用先买三台服务器。Minikube 在本地起一个单节点集群，用来学习和试验完全够：

# 安装 minikube
brew install minikube

# 启动集群（指定 CPU 和内存）
minikube start --cpus 4 --memory 8192

# 查看状态
kubectl cluster-info
kubectl get nodes

kubectl 是操作集群的命令行工具，所有「对集群做什么」的指令都通过它发出。minikube start 首次会下载镜像，慢的话换一下镜像源或耐心等一等。

三、部署第一个应用

用一个 Deployment 加一个 Service，把 Nginx 跑起来。Deployment 描述「我要 3 个副本、用 nginx 镜像」；Service 描述「给这些 Pod 一个固定入口，类型 NodePort」：

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
  type: NodePort

执行并验证：

kubectl apply -f deployment.yaml
kubectl get pods
kubectl get services
minikube service nginx-service

apply 是声明式的核心动作：你把期望状态写进 YAML，K8s 负责让它成为现实。如果某个 Pod 挂了，控制器会自动拉起一个新的，这就是「自愈」。要观察这些对象的状态，kubectl get all 能一次列出当前 namespace 下的主要资源；配合 kubectl port-forward svc/nginx-service 8080:80，可以把集群内的服务映射到本地端口直接访问，调试时非常方便。

四、常用命令

命令	作用
`kubectl get pods`	查看 Pod 状态
`kubectl get deployments`	查看 Deployment
`kubectl logs pod-name`	查看某个 Pod 的日志
`kubectl exec -it pod-name -- sh`	进入 Pod 里的容器
`kubectl describe pod pod-name`	查看 Pod 的详细事件
`kubectl scale deployment nginx --replicas=5`	扩缩容到 5 个副本

describe 是排查问题时的第一步：Pod 起不来，事件里会写清楚是镜像拉取失败、资源不足还是探针失败。

五、滚动更新与回滚

改一下镜像版本再 kubectl apply，K8s 会以滚动更新的方式升级：先起新的 Pod，等就绪后再逐个替换旧的，服务全程不中断。想看升级过程用 kubectl rollout status deployment/nginx-deployment；升级出问题，kubectl rollout undo deployment/nginx-deployment 一步回到上一版本。部署策略还可以配置成先停旧再起新（Recreate），或者用蓝绿、金丝雀这类更精细的方式——对多数应用来说，默认的滚动更新已经足够。这套「无感知升级 + 一键回滚」是手工部署最难复制的体验，也是 K8s 在日常运维里最实在的价值之一。

六、生产环境建议

本地集群和真实生产差别很大，从 minikube 走向生产时注意这几条：

用托管服务：优先用 EKS、AKS、GKE 这类托管 K8s，控制平面不用自己运维，升级和备份都省心。
配置资源请求与限制：给每个容器写明 CPU/内存的 requests 和 limits，避免某个服务把节点吃满拖垮邻居。
设置 HPA 自动伸缩：根据 CPU 或自定义指标自动扩缩副本数，流量高峰不用人工干预。
用 Helm 管理发布：把一堆 YAML 打包成 Chart，版本管理、回滚、参数化都方便。

一个场景案例

一个日活几十万的资讯站，后端拆成了网关、用户、内容、推送四个服务。高峰期网关 CPU 到 80%，HPA 自动把副本从 6 个扩到 18 个；凌晨流量回落再缩回去。一台节点出故障，Pod 自动被调度到健康节点，服务基本无感。这套能力用 Compose 很难实现，这正是引入 K8s 的典型理由。

常见问题

Pod 一直 Pending？ 大概率是节点资源不足或调度不满足，kubectl describe pod 看事件。
服务访问不通？ 先确认 Service 的 selector 和 Pod 的 label 是否匹配，再检查端口类型（ClusterIP/NodePort/LoadBalancer）。
本地和线上行为不一致？ minikube 只是单节点、无持久化存储，很多生产特性（多可用区、PVC 动态供给）本地体验不到，别拿它当生产替代品。
节点多了怎么管理？ 用 namespace 隔离团队和应用，用 label/taint 控制调度，把运维操作收敛到少数几个有权限的人手上。

参考：Kubernetes 官方文档 https://kubernetes.io/docs/ ；minikube 文档 https://minikube.sigs.k8s.io/docs/