Kubernetes与Minikube

Kubernetes与Minikube

• Kubernetes
• • [K8s 的核心架构](#K8s 的核心架构)
  • [K8s 核心标准 API 资源对象](#K8s 核心标准 API 资源对象)
• Minikube
• • 基础运行架构
  • [启动默认配置的单节点 K8s 集群](#启动默认配置的单节点 K8s 集群)

Kubernetes

Kubernetes（常缩写为 K8s） 是由 CNCF（云原生计算基金会）托管的开源容器编排引擎，它的核心目标是自动化管理大规模容器化应用的全生命周期。

诞生背景：为什么需要 K8s？

Docker 本质是单机容器管理工具，当业务从单机走向分布式集群，出现了 Docker 无法解决的核心痛点：

大规模容器的调度与分发：如何把成千上万个容器合理分配到多台服务器上？

故障自愈：容器崩溃、服务器宕机时，如何让业务自动恢复，无需人工介入？

弹性伸缩：流量洪峰时如何快速扩容，低谷时如何释放资源降本？

服务访问：容器 IP 是动态变化的，如何实现稳定的服务发现与负载均衡？

发布安全：如何实现无宕机的滚动更新、故障时一键回滚？

K8s 正是为解决这些集群级容器编排痛点而生，它提供了一套完整的自动化管理体系。

K8s 的核心架构

K8s 集群由控制平面（Control Plane） 和工作节点（Worker Node） 两大部分组成，协同实现集群的完整能力。

1. 控制平面（Control Plane）
   控制平面是集群的全局决策中枢与状态管理核心，负责集群的 API 响应、元数据存储、调度决策、状态闭环控制、全局配置管理，是整个集群的 "大脑"。生产环境中，控制平面通常采用多节点高可用部署，避免单点故障。其核心组件及职责如下：

组件名称	核心职责
kube-apiserver	集群唯一的入口与交互枢纽，提供 RESTful API，所有组件、用户的操作都必须经过它；负责认证、授权、准入控制，是集群的 "大门"。
etcd	集群唯一的分布式键值数据库，仅与 apiserver 通信，存储整个集群的所有状态、配置数据，是集群的 "数据库"，生产环境必须做高可用
kube-scheduler	集群调度器，核心职责是为新创建的 Pod，按照调度规则，分配到最合适的工作节点上
kube-controller-manager	控制器管理器，运行各类闭环控制器，持续监控集群状态，把实际状态收敛到用户定义的期望状态
cloud-controller-manager	云控制器管理器，对接公有云厂商 API，解耦集群与底层云资源（虚拟机、负载均衡、存储等），非云环境可省略

2. 工作节点（Worker Node）
   工作节点是集群的业务承载节点，负责运行用户的容器化应用，执行控制平面下发的指令，每个工作节点都运行以下核心组件：

组件名称	核心职责
kubelet	节点上的 "代理"，与控制平面 apiserver 持续通信，负责管理本节点上的 Pod 和容器，确保容器按照预期运行，执行健康检查，上报节点和 Pod 的状态
kube-proxy	节点网络代理，维护节点的 iptables/ipvs 规则，实现 Service 的负载均衡、集群内网络通信，为 Pod 提供固定、稳定的网络访问能力
容器运行时（CRI）	真正负责运行容器的底层软件，符合 K8s CRI（容器运行时接口）标准，主流实现为 containerd、CRI-O，早期 Docker 已不再是默认运行时

K8s 核心标准 API 资源对象

上述架构组件是集群的 "运行底座"，而以下核心资源是用户与集群交互、定义业务负载、管理应用生命周期的核心载体，也是 K8s 能力落地的核心单元。K8s 的所有业务定义、集群操作均通过声明式 API 资源对象实现，按功能维度分类：

• 核心基础资源

  Pod

  Pod 是 K8s 中最小的部署、调度与运行单元，并非单一容器，而是由一个或多个紧密耦合的容器组成的逻辑组。同 Pod 内的所有容器共享网络命名空间、UTS 命名空间、IPC 命名空间与共享存储卷，拥有完全一致的生命周期。K8s 不直接管理容器，所有容器必须运行在 Pod 中。

• 工作负载控制器

  工作负载控制器是 Pod 的管理载体，解决 Pod 无自愈、无副本管理、无发布策略等核心痛点，适配不同业务场景的 Pod 管理需求；生产环境通过控制器管理 Pod。

  • Deployment
    K8s 中最常用的无状态应用管理控制器，基于 ReplicaSet（副本集）实现，是日常业务部署的核心资源。核心职责是管理无状态应用 Pod 的副本数量、滚动更新、版本回滚、发布历史管理，确保应用的高可用与发布稳定性，适用于 Java 后端服务、前端 Nginx 服务、API 网关等无本地持久化数据、Pod 可完全互换的无状态应用。
  • StatefulSet
    专为有状态应用设计的管理控制器，核心解决 Deployment 无法适配有状态服务的痛点。为每个 Pod 分配终身不变的稳定网络标识（DNS 主机名）、固定绑定的持久化存储，提供严格有序的部署 / 扩缩容 / 更新策略，完美适配 MySQL、Redis、Kafka、Elasticsearch 等需要稳定标识、持久化存储、有序部署的有状态中间件与应用。
  • DaemonSet
    节点级守护进程控制器，核心特性是无需指定副本数量，自动在每个符合条件的工作节点上运行且仅运行一个 Pod 副本；集群新增节点时自动创建对应 Pod，节点移除时自动清理对应 Pod。适用于节点监控 Agent、日志采集组件、网络插件、存储插件等需要在每个节点上常驻运行的集群组件。

• 网络与流量管理资源

  解决 Pod 动态变化带来的访问难题，实现集群内、外流量的稳定转发与管理。

  • Service
    匹配一组具备相同业务标识的后端 Pod，为其分配固定不变的集群内访问入口（ClusterIP）与 DNS 域名，即使后端 Pod 全量重建、IP 完全更换，Service 的访问入口始终保持稳定；解决 Pod 生命周期临时、IP 随重建与扩缩容动态变化、访问地址频繁失效的问题。
    核心特性：工作在 OSI 四层传输层，支持 TCP/UDP 协议，无硬性套接字连接数限制，仅负责流量的可靠转发与四层负载均衡，覆盖集群内通信、跨节点访问、公网暴露等场景。
  • Ingress
    Ingress 资源本身仅声明 HTTP/HTTPS 七层流量的路由规则，不具备流量转发能力，依赖集群内提前部署的 Ingress Controller 才能真正生效。可通过单一公网 IP 与统一入口，承载数十上百个业务服务的公网访问。
    流量链路：最终将匹配到的公网流量转发至后端对应的 Service，再由 Service 转发至具体 Pod，形成「公网用户→Ingress Controller→Service→Pod」的完整访问链路。

• 配置与敏感信息管理资源

  实现应用配置与容器镜像的完全解耦，避免配置硬编码，适配多环境部署需求。

  • ConfigMap
    用于存储应用的非敏感配置信息，包括配置文件、环境变量、启动参数、命令行参数等，支持以环境变量、文件挂载两种方式注入到 Pod 的容器中，实现配置与镜像的解耦，一次镜像构建可适配多环境部署需求。
  • Secret
    专门用于存储应用的敏感信息，包括数据库密码、API 密钥、SSL/TLS 证书、镜像拉取凭证等；默认以 Base64 格式编码存储，支持通过 K8s 静态加密机制实现数据落盘加密，可通过环境变量、文件挂载方式注入到 Pod 中，避免敏感信息硬编码到镜像或配置文件中，降低信息泄露风险。

• 集群隔离与多租户管理资源

  Namespace

  K8s 集群的逻辑隔离单元，可将单套物理集群划分为多个互相隔离的虚拟集群，不同 Namespace 内的资源名称可重复，资源操作默认仅在当前 Namespace 内生效。配合 RBAC 基于角色的访问控制、ResourceQuota 资源配额，可实现开发 / 测试 / 生产环境隔离、多业务线隔离、多租户精细化管理。

集群核心运行逻辑闭环：

用户通过 kubectl 提交 Deployment YAML 文件，请求发送至 kube-apiserver，apiserver 完成认证、授权、准入控制后，将 Deployment 的定义写入 etcd；

kube-controller-manager 监听到 Deployment 资源的创建，根据定义生成对应的 ReplicaSet，再由 ReplicaSet 控制器创建对应数量的 Pod 资源，更新至 etcd；

kube-scheduler 监听到未分配节点的 Pod，经过调度算法匹配，为每个 Pod 分配最优的工作节点，将节点绑定信息更新至 etcd；

目标工作节点的 kubelet 监听到 apiserver 下发的 Pod 规约，调用本机容器运行时拉取镜像、启动容器，并持续执行健康检查，上报 Pod 运行状态至 apiserver；

配套创建 Service、Ingress 资源后，kube-proxy 在各节点更新网络规则，实现流量的负载均衡与转发；

全流程中，kube-controller-manager 持续监控集群状态，若出现 Pod 副本数不足、节点故障等异常，自动触发 Pod 重建、重新调度，将集群状态持续收敛到用户声明的期望状态，实现故障自愈。

Minikube

Minikube 是 Kubernetes（简称 K8s）官方维护的轻量化单节点发行版，是 K8s 生态的核心入门工具，完全兼容原生 K8s 的核心 API 与标准操作，专为本地学习、开发、测试场景设计，是标准 K8s 集群在单机环境的轻量化实现。

它的核心设计目标，是解决标准生产级 K8s 集群搭建门槛高、资源占用大、不适合单机环境使用的痛点，让用户无需多台服务器，即可在本地快速获得与生产集群行为一致的 K8s 运行环境，所有在 Minikube 中验证的配置、开发的应用、积累的操作经验，均可无缝迁移到生产级 K8s 集群。

基础运行架构

Minikube 本质是在本地创建一个隔离的运行环境，在这个环境中部署了一套完整的 K8s 集群，基础运行架构如下：

默认采用单节点融合部署：将 K8s 控制平面组件与工作节点组件合设在同一个实例中，兼顾功能完整性与轻量化；

可选多节点模式：支持一键创建多节点集群，可在本地模拟生产级多节点集群的调度、亲和性、故障转移等场景；

完全兼容 K8s 核心机制：包括 Pod 共享命名空间、Pause 基础设施容器、声明式 API、控制器闭环、Service 负载均衡等所有 K8s 原生核心机制，与标准集群行为完全一致。

启动默认配置的单节点 K8s 集群

Minikube 官方下载链接：https://github.com/kubernetes/minikube/releases

minikube start

检查状态

进入查看镜像

核心操作命令：

# 查看集群状态
minikube status

# 查看集群信息，确认 kubectl 已自动适配集群
kubectl cluster-info

# 启用 K8s 官方 Dashboard 可视化面板
minikube dashboard

# 启用 Ingress 控制器
minikube addons enable ingress

# 暂停集群，释放资源
minikube pause

# 恢复集群
minikube unpause

# 停止集群
minikube stop

# 删除集群
minikube delete

Docker Desktop 能看到、能检测到 Minikube，打开 Docker Desktop → Containers → 会看到一个 minikube 容器在运行

minikube dashboard

Minikube Dashboard 是 Kubernetes 官方提供的 Web 可视化管理界面，在 Minikube 中作为内置插件存在，它把原本需要通过 kubectl 命令行操作的集群管理功能，变成了直观的图形化界面。

Dashboard 本质是调用 K8s API 进行操作，和 kubectl 是同源的，界面上的每一个操作，背后都对应着一条 kubectl 命令。

部署 Nginx Pod（Deployment）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

这是一个 Deployment 控制器，负责管理 Nginx 应用的 Pod。

K8s 会自动创建一个 ReplicaSet，再由 ReplicaSet 创建 1 个运行 Nginx 的 Pod，并负责 Pod 的故障自愈、扩缩容等。

创建集群内访问入口（ClusterIP Service）

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80

这是一个 ClusterIP 类型的 Service，为 Nginx Pod 分配固定的集群内访问地址（ClusterIP）。

集群内的其他 Pod 或服务可以通过 nginx-service 这个名称（或其 ClusterIP）访问 Nginx，而无需关心 Pod 的动态 IP。

创建外部访问入口（Ingress）

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: nginx.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80

这是 Ingress 资源，将集群内的 nginx-service 暴露到外部，通过 nginx.local 域名访问，但实际无法访问 http://nginx.local，原因有二：

Ingress 未分配访问 IP（kubectl get ingress 中 ADDRESS 为空）；

本地 hosts 文件未配置 nginx.local 到 Ingress IP 的解析规则。

kubectl get pods：查看 Pod 状态

kubectl get service：查看 Service 状态

kubectl get ingress：查看 Ingress 状态

minikube service list：查看 Minikube 可暴露的 Service

所有 Service 都是 ClusterIP 类型，没有配置 NodePort 端口（NodePort 是 Service 暴露到集群节点的端口），所以 TARGET PORT 显示 No node port，默认无法通过节点 IP和端口访问。

快捷访问：Minikube 端口转发

minikube service nginx-service --url

Minikube 提供了本地端口转发方案，把本机 127.0.0.1:53886 的请求，直接转发到集群内 nginx-service:80，再到 Nginx Pod。不需要 Ingress Controller、不需要配置 hosts、不需要等 IP 分配，只要 Pod 和 Service 正常运行，就能立即访问。

打开浏览器访问 http://127.0.0.1:53886