第 20 篇 搭建 Kubernetes 实验环境：Minikube 与 kubectl

IT策士 10余年一线大厂经验，专注 IT 思维、架构、职场进阶。我会在各个平台持续发布最新文章，助你少走弯路。

在第 19 篇中，我们把 Kubernetes 的架构拆解了一遍------控制平面的四大组件、工作节点的三大组件、以及一个 Pod 从创建到运行的完整旅程。但架构图看得再多，不如亲手敲一行 kubectl get nodes。

从本篇开始，我们正式进入动手阶段。今天的目标很明确：在你的电脑上启动一个 K8s 集群，安装 kubectl 命令行工具，部署你的第一个 Pod，亲眼看看控制平面和 kubelet 是怎么协作的。这也是我们贯穿案例 Flask + Redis 计数器应用 K8s 化的起点------从第 10 篇我们用纯 Docker 命令启动了它，到第 44-45 篇我们将把它完整部署到 K8s 集群上。

一、为什么是 Minikube？

搭建 K8s 集群的方案很多，不同阶段适合不同的工具：

为什么本系列选择 Minikube？三个原因：它提供了最接近标准 K8s 的体验（包含控制平面全套组件）；一条 minikube start 就能搞定，不折腾；社区活跃，官方支持所有主流操作系统。

等到第 47 篇讲生产级考量时，我们会回过头来讨论 kubeadm 多节点部署和云托管方案。

二、安装 kubectl

kubectl 是你和 K8s 集群交互的唯一 CLI 工具。无论你用 Minikube、kubeadm 还是云托管，都靠它下命令。请先完成本节安装，否则后续所有示例都无法执行。

2.1 各平台安装

macOS（推荐 Homebrew）：

Windows（推荐 winget）：

winget install Kubernetes.kubectl

安装完成后，关闭并重新打开 PowerShell 或 Windows Terminal。

Linux（通过包管理器）：

以 Ubuntu/Debian 为例：

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg

# 添加 K8s 官方 GPG 密钥（2025 年底起建议使用新版获取方式）
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.32/deb/Release.key | \
  sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

# 添加 K8s APT 仓库
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.32/deb/ /" | \
  sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubectl

版本说明 ：本文以 v1.32 为例。如需安装其他版本，请将命令中的 v1.32 替换为目标版本号。版本兼容性策略是 kubelet 版本与 API Server 不超过 ±1 个次要版本。对于本地实验环境，kubectl 版本可以等于或略新于集群版本。

所有平台通用安装方式：

# 下载最新稳定版
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

# 安装
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

2.2 验证安装

输出：

Client Version: v1.32.0
Kustomize Version: v5.5.0

如果你看到 Server Version 报错（The connection to the server localhost:8080 was refused），这是正常的------因为集群还没启动。我们在第 47 篇会深入 kubectl 的 kubeconfig 配置机制。

三、安装 Minikube 并启动集群

Minikube 的安装方式按操作系统分为三种路径，请根据你的操作系统选择。

3.1 各平台安装 Minikube

macOS：

Windows（推荐 winget）：

Linux（推荐直接下载二进制）：

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube && rm minikube-linux-amd64

3.2 启动集群

Minikube 支持多种驱动（driver），用于运行 K8s 节点。操作系统与推荐驱动的对应关系如下：

确认 Docker 驱动可用：

minikube start --driver=docker

输出关键行：

😄  minikube v1.34.0 on Ubuntu 22.04
✨  Using the docker driver based on existing profile
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
💾  Downloading Kubernetes v1.31.0 preload ...
🔥  Creating docker container (CPUs=2, Memory=2200MB) ...
🐳  Preparing Kubernetes v1.31.0 on Docker 27.2.0 ...
🔎  Verifying Kubernetes components...
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster

Minikube 帮你做了什么？它自动下载了包含 K8s 组件的 ISO 镜像，创建了一个 Docker 容器来运行单节点集群，并将 kubectl 的配置指向了这个新集群。

3.3 验证集群状态

输出：

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   30s   v1.31.0

ROLES 列显示 control-plane，因为 Minikube 的单节点集一身承担了控制平面和工作节点的双重角色。

输出：

Kubernetes control plane is running at https://192.168.49.2:8443
CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

3.4 查看控制平面组件的真实面貌

我们在第 19 篇学过，控制平面组件运行在 kube-system 命名空间中。来亲眼看一看：

kubectl get pods -n kube-system

输出：

NAME                               READY   STATUS    RESTARTS   AGE
coredns-7c8b6f9d5f-abcde           1/1     Running   0          2m
etcd-minikube                      1/1     Running   0          2m
kube-apiserver-minikube            1/1     Running   0          2m
kube-controller-manager-minikube   1/1     Running   0          2m
kube-proxy-xyz12                   1/1     Running   0          2m
kube-scheduler-minikube            1/1     Running   0          2m
storage-provisioner                1/1     Running   0          2m

对照第 19 篇的架构图，你看到了 etcd、kube-apiserver、kube-scheduler、kube-controller-manager，还有工作节点上的 kube-proxy。架构图里的抽象概念，此刻正在你的电脑上真实运行着。

四、部署第一个应用：Nginx

环境就绪，来跑一个真正的应用。

4.1 创建一个 Deployment

kubectl create deployment my-nginx --image=nginx:alpine

输出：

deployment.apps/my-nginx created

这条命令在 K8s 中做了什么？它创建了一个 Deployment 对象（控制器），Deployment Controller 监听到后创建了 ReplicaSet，ReplicaSet Controller 创建了一个 Pod，Scheduler 将 Pod 分配给了唯一的节点，节点上的 kubelet 拉取镜像并启动了 Nginx 容器。整个过程就是第 19 篇讲的 7 步完整链路。对比一下，在 Docker 中你要执行 docker run -d --name my-nginx nginx:alpine，只涉及本地 Docker Daemon；而在 K8s 中，控制平面组件和 kubelet 协作完成了相同的效果。

4.2 查看 Pod 状态

输出：

NAME                        READY   STATUS    RESTARTS   AGE
my-nginx-5c6d7f8b9f-abcde   1/1     Running   0          30s

• READY 1/1：Pod 中 1 个容器已就绪

• STATUS Running：Pod 正在运行

• RESTARTS 0：容器从未重启过

如果 STATUS 显示 Pending 或 ImagePullBackOff，说明调度或镜像拉取出了问题。Minikube 环境下最常见的原因是镜像拉取超时------执行 kubectl describe pod <pod名> 可以看到详细事件日志。

4.3 查看 Deployment 详情

输出：

NAME       READY   UP-TO-DATE   AVAILABLE   AGE
my-nginx   1/1     1            1           1m

• READY 1/1：期望 1 个副本，当前 1 个副本就绪

• UP-TO-DATE：已更新到最新版本的 Pod 数

• AVAILABLE：可用的 Pod 数

4.4 端口转发

在 K8s 中，Pod 的端口默认不会自动暴露到宿主机。快速测试时，可以用 port-forward 建立临时隧道：

kubectl port-forward deployment/my-nginx 8080:80

输出：

Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80

此时终端被占用，打开另一个终端：

curl http://localhost:8080

你会看到 Nginx 的欢迎页面 HTML。port-forward 绕过了 Service 和 Ingress，直接将你本机的 8080 端口流量转发到 Pod 的 80 端口。它适合调试，但不适合生产流量，因为 kubectl 进程本身就是单点故障。生产环境中，你需要用 Service（NodePort/LoadBalancer）+ Ingress 来暴露服务，这些将在第 28-31 篇展开。

按 Ctrl+C 结束端口转发。

五、体验 K8s 的核心特性

5.1 自愈能力

删除一个 Pod，观察控制器如何自动重建：

# 先记住当前 Pod 名字
kubectl get pods
# NAME                        READY   STATUS    RESTARTS   AGE
# my-nginx-5c6d7f8b9f-abcde   1/1     Running   0          5m

# 删除这个 Pod
kubectl delete pod my-nginx-5c6d7f8b9f-abcde
# pod "my-nginx-5c6d7f8b9f-abcde" deleted

# 立即查看（Pod 已被新版本替换）
kubectl get pods
# NAME                        READY   STATUS    RESTARTS   AGE
# my-nginx-5c6d7f8b9f-xyz12   1/1     Running   0          5s

旧 Pod 被删了，一个全新的 Pod（名字后半段不同）立刻被创建出来。Deployment Controller 检测到实际 Pod 数量（0）不等于期望数量（1），触发创建新 Pod。这就是控制循环的自愈能力------也是 Compose 中 restart: unless-stopped 在 K8s 层面的增强版。

5.2 扩容

将 Nginx 的副本数从 1 扩到 3：

kubectl scale deployment my-nginx --replicas=3
# deployment.apps/my-nginx scaled

kubectl get pods -w
# NAME                        READY   STATUS              RESTARTS   AGE
# my-nginx-5c6d7f8b9f-xyz12   1/1     Running             0          6m
# my-nginx-5c6d7f8b9f-def34   0/1     ContainerCreating   0          2s
# my-nginx-5c6d7f8b9f-ghi56   0/1     ContainerCreating   0          2s
# my-nginx-5c6d7f8b9f-def34   1/1     Running             0          10s
# my-nginx-5c6d7f8b9f-ghi56   1/1     Running             0          10s

三条命令，从 1 个副本变成了 3 个。对比 Compose 的 --scale，K8s 的扩容也是声明式的------修改期望副本数后控制器自动调和实际状态。在第 36 篇我们还会学习 HPA（水平自动伸缩），让 K8s 根据 CPU 和内存使用率自动调整副本数。

按 Ctrl+C 退出 watch 模式。

六、Minikube 常用管理命令

Minikube 毕竟是个实验环境，下面这些命令是日常使用的高频操作。

如果实验环境出现问题，最快恢复方式是重建集群：

minikube delete
minikube start --driver=docker

从头到尾约 2-3 分钟，适用于"环境被玩坏了"的极端情况。

6.1 集群暂停与恢复

当你不需要 K8s 运行时，可以通过暂停释放 CPU 和内存资源：

# 暂停集群（保留所有已部署的资源，但释放计算资源）
minikube pause

# 恢复集群
minikube unpause

这个操作不会丢失任何部署的资源（Pod、Deployment、Service 等），只是暂停了控制平面和工作节点进程，适合午休或长时间不用时暂时释放资源。

七、命令速查表

八、本篇总结

今天这篇是整个 K8s 实战的"起手式"------我们成功搭建了实验环境，验证了第 19 篇的架构知识，部署了第一个应用，体验了自愈和扩容这两个 K8s 最核心的特性。具体来说，你学会了在本地用 Minikube 一键启动单节点集群，使用 kubectl 管理 Deployment 和 Pod 的生命周期，验证了控制器模式下的自愈能力，实现了从 1 到 3 的副本扩容。

至此，本系列四个阶段的工具链已清晰成型：单机容器化（Docker）→ 单机编排（Compose）→ 集群编排（K8s 核心对象）→ 生产级运维（后续 30 篇将逐一覆盖的监控、日志、CI/CD、安全、服务网格） 。此刻你的电脑上已经有一个真实的 K8s 集群在跑，kubectl get pods -n kube-system 能看到全套控制平面组件------你已经站在了云原生的门槛上。

下一篇文章------第 21 篇：Pod：最小调度单元与 YAML 详解，我们将深入 K8s 最核心的概念，从 Pod 的 YAML 结构开始，理解为什么 Pod 是"最小的、不可再分的调度单元"。

想了解更多还可以去各个平台搜索「IT策士」，一起升级 IT 思维 ！