2. 环境准备：Kubernetes集群搭建（Minikube/Kind）、kubectl配置、Helm安装

本章聚焦于搭建一套可用于《事故响应台账》部署与验证的本地Kubernetes环境。我们将依次完成Minikube与Kind两种单节点集群的搭建、kubectl命令行工具的配置，以及Helm包管理器的安装。选择Minikube或Kind取决于你的操作系统与资源限制，两者均可满足后续课程实验需求。

2.1 集群方案对比与选型建议

在开始安装前，先明确Minikube与Kind的核心差异，以便根据自身环境做出选择。

特性 Minikube Kind (Kubernetes in Docker)
底层依赖 虚拟机（Hyper-V / VirtualBox / KVM）或 Docker 仅需 Docker
启动速度 较慢（需创建虚拟机） 快（容器模拟节点）
资源占用 较高（完整VM） 较低（共享Docker引擎）
多节点支持 支持（需额外配置） 原生支持（通过配置文件）
适用场景 需要完整VM隔离、模拟真实节点 CI/CD、快速迭代、资源受限环境
推荐人群 Windows/macOS新手、需要完整体验 Linux用户、DevOps工程师
选型建议： 如果你的机器内存 ≥ 8GB 且希望体验最接近生产环境的集群，选择 Minikube；如果内存 ≤ 4GB 或主要用于快速验证，选择 Kind。本课程后续实验同时兼容两种集群，你无需担心切换成本。

2.2 安装Minikube（虚拟机模式）

Minikube通过创建轻量级虚拟机来运行单节点Kubernetes集群。以下步骤以Linux（Ubuntu 22.04）为例，Windows/macOS操作类似，仅驱动选择不同。

2.2.1 前置检查

  • 确认已安装Docker或Hypervisor（如VirtualBox）。
  • 确认CPU支持虚拟化（BIOS中已开启VT-x/AMD-V）。
  • 确认curl、wget等工具可用。

2.2.2 下载并安装Minikube

# 下载最新版Minikube二进制文件
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64

# 安装到系统路径
sudo install minikube-linux-amd64 /usr/local/bin/minikube

# 验证安装
minikube version

2.2.3 启动集群

# 使用Docker驱动启动（无需额外虚拟机软件）
minikube start --driver=docker --cpus=2 --memory=4096

# 等待集群就绪，输出类似：
# * minikube v1.32.0 on Ubuntu 22.04
# * Using the docker driver based on existing profile
# * Starting control plane node minikube in cluster minikube
# * Pulling base image ...
# * Preparing Kubernetes v1.28.3 on Docker 24.0.7 ...
# * Done! kubectl is now configured to use "minikube" cluster

2.2.4 验证集群状态

# 查看节点状态
minikube status

# 查看集群信息
kubectl cluster-info

# 查看所有Pod（应看到coredns等系统组件运行）
kubectl get pods -n kube-system
常见问题： 如果启动失败，执行 minikube delete 清理后重试，或指定更低的资源 --cpus=2 --memory=2048。Windows用户建议使用Hyper-V驱动以获得最佳稳定性。

2.3 安装Kind（容器化模式）

Kind将Kubernetes节点作为Docker容器运行，启动速度极快，特别适合CI/CD流水线。

2.3.1 安装Kind CLI

# 使用go install（需先安装Go 1.17+）
go install sigs.k8s.io/kind@latest

# 或使用二进制下载（推荐）
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.20.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

# 验证
kind version

2.3.2 创建集群

# 使用默认配置创建单节点集群
kind create cluster --name incident-response

# 输出示例：
# Creating cluster "incident-response" ...
#  ✓ Ensuring node image (kindest/node:v1.28.0) 🖼
#  ✓ Preparing nodes 📦
#  ✓ Writing configuration 📜
#  ✓ Starting control-plane 🕹️
#  ✓ Installing CNI 🔌
#  ✓ Installing StorageClass 💾
# Set kubectl context to "kind-incident-response"

2.3.3 验证集群

# 查看集群节点（容器）
kind get nodes --name incident-response

# 查看kubeconfig上下文
kubectl config current-context

# 查看节点状态
kubectl get nodes
注意： Kind创建的集群默认不暴露NodePort端口到宿主机。如需访问服务，需使用 kubectl port-forward 或配置Ingress。后续章节会专门讲解端口转发策略。

2.4 kubectl配置与验证

kubectl是操作Kubernetes集群的核心命令行工具。无论使用Minikube还是Kind，kubectl的配置逻辑一致。

2.4.1 安装kubectl

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

# 赋予执行权限并移动到系统路径
chmod +x kubectl
sudo mv kubectl /usr/local/bin/kubectl

# 验证版本
kubectl version --client

2.4.2 kubeconfig文件结构

kubectl通过 ~/.kube/config 文件管理集群访问凭证。该文件包含三个核心部分：

  • clusters：集群API Server地址与CA证书。
  • users：客户端证书或。
  • contexts：将集群与用户绑定，并指定默认命名空间。

Minikube和Kind在创建集群后会自动更新kubeconfig。你可以通过以下命令查看当前上下文：

# 查看完整配置
kubectl config view

# 查看当前上下文
kubectl config current-context

# 切换上下文（例如从minikube切换到kind）
kubectl config use-context kind-incident-response

2.4.3 验证kubectl与集群通信

# 测试API Server连通性
kubectl cluster-info

# 列出所有可用的API资源
kubectl api-resources | head -20

# 创建一个测试Pod验证工作正常
kubectl run test-pod --image=nginx --restart=Never
kubectl get pods
kubectl delete pod test-pod
多集群管理技巧： 使用 kubectl config set-context 为不同集群设置别名，配合 kubectx 工具可快速切换。建议将生产、预发、开发集群的上下文名称区分清楚，避免误操作。

2.5 Helm安装与初始化

Helm是Kubernetes的包管理器，用于简化应用的部署、升级和回滚。《事故响应台账》将使用Helm Chart进行一键部署。

2.5.1 安装Helm CLI

# 使用官方脚本安装（自动检测系统架构）
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# 或使用二进制下载
wget https://get.helm.sh/helm-v3.13.2-linux-amd64.tar.gz
tar -zxvf helm-v3.13.2-linux-amd64.tar.gz
sudo mv linux-amd64/helm /usr/local/bin/helm

# 验证版本
helm version

2.5.2 添加Helm仓库

安装完成后，需要添加常用的Chart仓库：

# 添加官方稳定仓库
helm repo add stable https://charts.helm.sh/stable

# 添加Bitnami仓库（常用中间件）
helm repo add bitnami https://charts.bitnami.com/bitnami

# 更新仓库缓存
helm repo update

# 查看已添加的仓库
helm repo list

2.5.3 验证Helm与集群交互

# 查看Helm环境信息
helm env

# 在集群中初始化Helm（Helm 3无需Tiller，直接可用）
# 测试部署一个Nginx Chart
helm install test-nginx bitnami/nginx --namespace default --create-namespace

# 查看部署状态
helm list
kubectl get pods,svc

# 清理测试
helm uninstall test-nginx
Helm 3重要变化： 移除了Tiller服务端组件，所有操作通过kubectl直接与API Server通信，安全性大幅提升。无需再执行 helm init 命令。

2.6 环境验证清单

完成上述步骤后，建议执行以下验证清单，确保环境完全就绪：

检查项 验证命令 预期结果
集群节点状态 kubectl get nodes 节点状态为 Ready
系统Pod运行 kubectl get pods -n kube-system coredns、kube-proxy等Pod均为 Running
kubectl上下文 kubectl config current-context 显示正确的集群名称
Helm版本 helm version 输出 v3.x.x 版本号
Helm仓库 helm repo list 至少包含一个可用仓库
部署测试 helm install test bitnami/nginx 安装成功，Pod启动
避坑提醒： 如果 kubectl get nodes 显示 NotReady，请检查容器运行时（Docker/containerd）是否正常运行，以及CNI网络插件是否安装。Minikube默认安装Calico，Kind默认安装kindnetd，两者均无需额外操作。若使用自定义CNI，请参考对应文档。
Kubernetes本地环境搭建流程 选择集群方案 Minikube（虚拟机模式） Kind（容器化模式） kubectl 配置与验证 Helm 安装与仓库配置 环境就绪 ✓

2.7 本章小结

至此，你已经完成了《事故响应台账》部署所需的全部基础环境搭建：

  • 集群层：Minikube或Kind单节点集群运行正常。
  • 工具层：kubectl已配置正确的上下文，可与集群通信。
  • 包管理层：Helm v3已安装，并添加了必要的Chart仓库。
← 上一章 📖 返回目录 下一章 →