Kubernetes 无云提供商（第 1 部分）：CNI、动态存储、Ingress 与 Terraform 架构

抱歉，我需要您提供要翻译的完整文本内容（除代码块和 URL 之外的部分），才能为您进行翻译。请把文章的其余部分粘贴在这里，我会按照要求保留源链接并保持原有的格式和技术术语进行简体中文翻译。

介绍

长期以来——在许多本地（on‑premises）场景中仍然如此——Kubernetes 是在没有云提供商原生集成的情况下运行的。在 EKS、GKE 和 AKS 成为标准之前，运维人员需要手动配置网络、存储、Ingress、身份认证和镜像仓库。

本文是一个系列的第一篇，记录在 Kubernetes in Docker (KinD) 上构建集群的过程，重点包括：

• CNI（Pod 网络）配置
• 使用 CSI 的动态存储供应
• Ingress 配置
• 通过 Terraform 完整的结构化与自动化

TLS 与 Vault、cert‑manager 的集成将留到下一篇文章，因为我仍在完成该集成。

在托管环境中，我们会自动获得：

• 与 VPC 集成的 CNI
• 动态磁盘供应
• 负载均衡器
• 身份集成

但这些都不是 Kubernetes 本身固有的功能；它们是由提供商额外配置的组件。本项目的目标是去除这些抽象，手动实现一个功能完整的集群所需的核心能力。

添加到 KinD 集群的组件

CNI – Calico

为了实现 pod 与节点之间的通信，已安装 Calico，启用：

• 为 pod 分配 IP
• VXLAN 封装
• Network Policies（网络策略）
• 节点间通信

没有 CNI，pod 之间无法通信——这是可用集群的首要前提。

动态存储 – OpenEBS

为了替代云环境中受管磁盘的作用，部署了 OpenEBS，实现：

• 创建 StorageClasses
• 动态供应 PVCs
• 使用基于本地存储的后端

这为任何 Kubernetes 环境中的有状态应用提供预期的行为。

Ingress 控制器 – NGINX

（NGINX Ingress 控制器的安装细节此处未展开，但已作为 Terraform 模块包含。）

Terraform 架构

模块仓库：

模块 tf-module-kind-blueprint 充当 聚合模块（根模块组合模式）。在此模型中：

• 根模块不直接实现资源；它组合专用模块。
• 集中管理变量和依赖。
• 为使用者提供干净的接口。

每个组件（CNI、OpenEBS、NGINX Ingress）都封装在各自的 Terraform 模块中。

架构优势

• 责任划分清晰
• 模块化与可复用性
• 可扩展的组织结构
• 便于维护

实施过程中的关键点

• 在 providers（Kubernetes 与 Helm）之间进行协调
• 确保依赖的正确顺序
• 模块的幂等性
• 输出的链式传递
• 仅在集群可用后才初始化 Kubernetes provider

在新创建的集群中自动化基础设施组件需要特别关注资源的生命周期。

系列后续文章

• Identity Provider 配置
• OIDC 与 Workload Identity
• 使用 ExternalDNS 的 Ingress 自动 DNS
• Ingress 自动 TLS：
  • cert‑manager
  • HashiCorp Vault 作为 CA
• 向 Gateway API 的演进
• 使用 Istio 的多集群 Service Mesh
• 在 Crossplane 中作为 Composition Function 打包

结论

在没有云提供商的情况下运行 Kubernetes 并不是一种异想天开的做法——多年来，许多集群就是这样运行的，并且仍然在裸金属、边缘和私有数据中心环境中运行。云提供商只是将以下组件打包并集成：

• CNI
• CSI
• Ingress
• 身份
• PKI

手动实现这些层会彻底改变对平台的理解程度。这个项目不仅仅是为了“让它工作”，更是为了深入了解抽象背后到底发生了什么。

在下一篇文章中，我将深入身份层和 TLS——这正成为一个有趣的挑战。