📚 课程目录第2章 Kubernetes基础回顾

2. Kubernetes 基础回顾：Pod、Deployment、StatefulSet、Service、Ingress、ConfigMap、Secret 核心概念

在深入 MinIO 高可用部署之前，必须牢固掌握 Kubernetes 的七个核心原语。这些资源共同构成了应用声明式生命周期管理、网络暴露、配置注入与敏感信息存储的基石。本章将逐一拆解其定义、适用场景及在 MinIO 部署中的典型角色。

2.1 核心工作负载：Pod、Deployment、StatefulSet

Kubernetes 中最小的可调度单元是 Pod，而 Deployment 与 StatefulSet 则是管理 Pod 副本与生命周期的控制器。三者关系如下图所示：

2.1.1 Pod

Pod 是 Kubernetes 中可创建和部署的最小计算单元，包含一个或多个共享网络栈、存储卷的容器。在 MinIO 场景中，一个 Pod 通常只运行一个 MinIO 容器，并通过 emptyDir 或 PersistentVolumeClaim 挂载数据目录。

MinIO 中的 Pod 特征：

每个 MinIO Pod 拥有独立的 IP 地址。
通过 readinessProbe 和 livenessProbe 实现健康检查。
数据卷通过 PVC 持久化，Pod 重建后数据不丢失。

2.1.2 Deployment

Deployment 管理无状态应用的声明式更新与扩缩容。它保证指定数量的 Pod 副本始终运行，支持滚动更新、回滚。对于 MinIO 的 网关模式（Gateway Mode）或 负载均衡器前端，Deployment 是首选。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minio-gateway
spec:
  replicas: 3
  selector:
    matchLabels:
      app: minio-gateway
  template:
    metadata:
      labels:
        app: minio-gateway
    spec:
      containers:
      - name: minio
        image: minio/minio:latest
        args: ["gateway", "azure"]
        ports:
        - containerPort: 9000

2.1.3 StatefulSet

StatefulSet 专为有状态应用设计，提供稳定的网络标识（Pod 名称固定）和有序的部署/伸缩。每个 Pod 可绑定独立的 PersistentVolumeClaim，这是 MinIO 分布式模式高可用的核心要求。

特性	Deployment	StatefulSet
Pod 名称	随机后缀（如 `minio-abc123`）	有序索引（如 `minio-0`, `minio-1`）
存储卷	所有 Pod 共享同一 PVC 模板	每个 Pod 可绑定独立 PVC
扩缩容顺序	并行创建/删除	顺序创建（0→N），逆序删除（N→0）
MinIO 适用场景	网关模式、缓存层	分布式模式（Erasure Code）

最佳实践： 生产环境 MinIO 分布式集群必须使用 StatefulSet + Headless Service，以保证每个 MinIO 实例拥有固定的 DNS 名称（如 minio-0.minio-hl.svc.cluster.local），这是节点间组建 Erasure Code 集群的前提。

2.2 网络与流量管理：Service、Ingress

Pod 是动态的，其 IP 会随重建而变化。Kubernetes 通过 Service 提供稳定的网络端点，Ingress 则负责七层路由与 TLS 终止。

2.2.1 Service

Service 为一组 Pod 提供稳定的虚拟 IP 和 DNS 名称，并实现负载均衡。MinIO 部署中常用的 Service 类型：

ClusterIP：默认类型，仅在集群内部可达，适合 MinIO 内部节点间通信。
NodePort：在每个节点上暴露端口，适合开发测试。
LoadBalancer：云环境自动分配公网 IP，适合生产 MinIO 对外暴露。
Headless Service（clusterIP: None）：不分配虚拟 IP，直接返回 Pod IP 列表，是 StatefulSet 实现稳定 DNS 标识的关键。

# MinIO 分布式集群使用的 Headless Service 示例
apiVersion: v1
kind: Service
metadata:
  name: minio-hl
spec:
  clusterIP: None
  selector:
    app: minio
  ports:
  - port: 9000
    name: minio-api

2.2.2 Ingress

Ingress 提供基于 HTTP/HTTPS 的七层路由规则，支持虚拟主机、路径转发、TLS 证书挂载。对于 MinIO 的 S3 API 访问，Ingress 可配置 nginx.ingress.kubernetes.io/proxy-body-size: "0" 以支持大文件上传。

注意： MinIO 的 S3 签名请求（V4）要求 Host 头与端点一致。使用 Ingress 时，必须启用 preserve-host: true 注解，否则签名验证会失败。

2.3 配置与敏感信息：ConfigMap、Secret

Kubernetes 将配置与镜像解耦，通过 ConfigMap 管理非敏感配置，Secret 管理敏感数据（如密钥、证书）。

资源	存储内容	编码方式	MinIO 典型用途
ConfigMap	配置文件、环境变量、命令行参数	明文（Base64 仅用于传输）	MinIO 启动参数、Region 配置、日志级别
Secret	密码、Token、TLS 证书、SSH 密钥	Base64 编码（etcd 中可加密）	MINIO_ROOT_USER、MINIO_ROOT_PASSWORD、TLS 私钥

2.3.1 ConfigMap 使用示例

apiVersion: v1
kind: ConfigMap
metadata:
  name: minio-config
data:
  MINIO_REGION: "cn-east-1"
  MINIO_BROWSER: "on"
  MINIO_STORAGE_CLASS_STANDARD: "EC:4"

2.3.2 Secret 使用示例

apiVersion: v1
kind: Secret
metadata:
  name: minio-secret
type: Opaque
data:
  MINIO_ROOT_USER: YWRtaW4=          # admin
  MINIO_ROOT_PASSWORD: cGFzc3dvcmQ=  # password

安全建议： 生产环境应使用 External Secrets Operator 或 Vault 动态注入 Secret，避免明文 Base64 值暴露在 YAML 文件中。MinIO 的 TLS 证书应通过 kubernetes.io/tls 类型的 Secret 挂载。

2.4 核心概念在 MinIO 高可用中的角色总结

下表将七个核心资源与 MinIO 高可用架构的对应关系进行汇总：

Kubernetes 资源	MinIO 高可用中的职责	关键配置要点
Pod	运行 MinIO 容器实例	资源请求/限制、健康探针、卷挂载
StatefulSet	管理分布式 MinIO 节点，保证有序启动与独立存储	`serviceName` 指向 Headless Service
Deployment	管理 MinIO 网关或代理层	滚动更新策略、反亲和性
Service	提供稳定的 MinIO 访问端点	Headless Service 用于节点发现；LoadBalancer 用于外部访问
Ingress	七层路由、TLS 终止、域名绑定	启用 `preserve-host`，设置大 body 限制
ConfigMap	注入 MinIO 环境变量与配置	Region、存储类、日志参数
Secret	存储 MinIO 根凭证与 TLS 证书	使用 `stringData` 简化明文输入