安装 Minikube 并启动本地集群

Minikube 适合本地学习和快速验证，它让你在笔记本上就能获得一个真实的 Kubernetes API。你可以用它练习 YAML、验证部署流程、测试 Ingress 和常用插件，而无需依赖云集群。

下面在原有快速上手的基础上补充了驱动选择、资源配置与示例工作负载，帮助你从安装到验证形成完整闭环。

为什么用 Minikube

单节点轻量集群，适合开发和教学。
支持多种驱动（Docker、Hyper-V、VirtualBox 等）。
提供 Ingress、metrics-server、Dashboard 等插件。
出错后可快速重置。

预备条件

64 位系统，支持虚拟化（或已安装 Docker Desktop）。
建议 2 核 CPU 与 4GB 内存以上。
已安装 kubectl 并可在 PATH 中调用。

安装 kubectl

以 Linux 为例：

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 version --client

安装 Minikube

Linux 示例：

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

查看版本：

minikube version

选择驱动

Docker：最常见且安装成本低。
Hyper-V / VirtualBox：Windows 常用，但需要开启虚拟化。
VMware / HyperKit：Mac 可选。

如果 Docker 可用，优先使用 Docker 驱动。

驱动说明与取舍

Docker 驱动最简单，但会与本地 Docker 共享资源和网络配置。如果你处在公司代理或私有仓库环境，可能需要额外设置。基于虚拟机的驱动隔离性更强，但需要更多磁盘空间，且对宿主机虚拟化支持有要求。

Windows 环境要注意 Hyper-V 与 VirtualBox 不要同时启用，否则可能导致启动失败。macOS 上通常使用 Docker Desktop 更省心。

启动集群

推荐显式配置 CPU 与内存，稳定性更好：

minikube start --driver=docker --cpus=4 --memory=6g
minikube status
kubectl get nodes

如果需要多个集群，可以用 profile：

minikube start -p demo --driver=docker
minikube profile demo

日常使用建议

可以用 profile 区分不同用途的集群，例如一个用于快速实验，一个用于长期演示。执行 kubectl 前确认当前 context，避免操作到错误集群：

kubectl config get-contexts
kubectl config use-context minikube

如果你经常清理重建集群，建议把常用参数写成脚本，保证每次起步的资源配置一致。

规模与预期

Minikube 是单节点集群，控制平面与工作负载共享资源。日常开发建议 4 核 6-8GB 内存起步。如果你启用了 metrics-server 与 dashboard，建议再多给一点内存，避免 Pod 被 OOM。

常用操作

minikube addons enable ingress
minikube addons enable metrics-server
minikube dashboard
minikube stop
minikube delete

部署一个示例工作负载

创建 Nginx Deployment 和 Service：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: web
        image: nginx:1.27
        ports:
        - containerPort: 80

apiVersion: v1
kind: Service
metadata:
  name: hello
spec:
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 80

kubectl apply -f deploy.yaml
kubectl apply -f svc.yaml
kubectl get pods -o wide

访问服务

Minikube 提供多种访问方式：

minikube service hello --url

或使用端口转发：

kubectl port-forward svc/hello 8080:80

如果要测试 LoadBalancer 类型服务，运行：

minikube tunnel

网络与 DNS 提示

Minikube 的 Service IP 和集群 DNS 只在节点内部可见，宿主机无法直接访问是正常现象。你需要通过 minikube service、端口转发或 Ingress + hosts 映射来打通访问路径。

当访问失败时，可以先 minikube ssh 到节点内部，用 curl 测试 Service，以区分是集群问题还是宿主机网络问题。

Ingress 示例

启用 ingress 插件后创建 Ingress 规则：

minikube addons enable ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello
spec:
  rules:
  - host: hello.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: hello
            port:
              number: 80

获取 Minikube IP，并在 hosts 文件中添加映射：

minikube ip

把 hello.local 指向 <minikube-ip>，然后访问 http://hello.local。

本地镜像加载

本地构建镜像时，可以直接加载到 Minikube：

minikube image load my-app:dev
kubectl set image deployment/hello web=my-app:dev

这样无需推送到远程镜像仓库。

代理与私有仓库

如果处于公司代理环境，建议在启动 Minikube 前设置 HTTP_PROXY、HTTPS_PROXY、NO_PROXY，并把集群网段加入 NO_PROXY，避免内部访问绕代理。

私有镜像仓库可以选择在节点内登录，或者直接使用 minikube image load 进行镜像加载，后者对本地开发更省事。

存储基础

Minikube 自带默认 StorageClass。你可以先创建一个 PVC 并挂载到 Pod，验证持久化流程，为后续迁移到真实存储打基础。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: demo-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

重置与清理

实验过程中出错是常态，建议熟悉重置操作：\n- minikube stop 暂停集群但保留状态。\n- minikube delete 删除集群但保留二进制。\n- minikube delete --all --purge 清理所有 profile 和缓存镜像。

如果遇到反复启动失败，彻底清理通常能解决残留的网络或缓存问题。

常见问题与排查

节点 NotReady：检查驱动和镜像下载，执行 minikube logs。
端口不可访问：优先使用 minikube service 或 kubectl port-forward。
Pod 一直 Pending：查看资源与调度原因，kubectl describe pod。
Ingress 不生效：确认已启用 ingress 插件并检查控制器 Pod 状态。

常用诊断命令：

minikube status
minikube logs
kubectl get events -A
kubectl describe node

实操要点

先做快速盘点：kubectl get nodes、kubectl get pods -A、kubectl get events -A。
对比“期望状态”和“实际状态”，kubectl describe 往往能解释漂移或失败原因。
名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。

快速检查清单

资源定义与业务意图一致。
Namespace、权限、镜像与环境匹配。
上线前具备健康探针与可观测日志。