Kubernetes集群联邦：架构与API对象解析

### Kubernetes集群联邦：架构、对象与应用解析 #### 1. 集群联邦概述 在面对数据中心整体故障的风险时，将应用部署在多个数据中心或云可用区是确保高可用性的关键策略。当某个数据中心或可用区不可用时，客户端请求可被路由至其他健康区域运行的应用。虽然Kubernetes不强制要求控制平面和节点位于同一数据中心，但为降低网络延迟和避免连接中断，通常会选择这样部署。相较于将单个集群分散在多个位置，在每个位置部署独立的Kubernetes集群是更好的选择，这就是集群联邦的核心理念。 Kubernetes通过集群联邦允许用户将多个集群组合成一个超级集群，实现跨不同地理位置、不同云提供商以及本地集群（混合云）的应用部署和管理。其动机不仅在于确保高可用性，还在于将多个异构集群整合为一个通过单一管理界面管理的超级集群。例如，可以将本地集群与云提供商基础设施上的集群结合，将对隐私敏感的应用组件部署在本地，非敏感部分部署在云端；或者最初在小型本地集群运行应用，当计算需求超出集群容量时，将应用扩展到云集群。 #### 2. 集群联邦架构 集群联邦可类比为常规集群，只不过其中的节点被完整的集群所取代。如同Kubernetes集群由控制平面和多个工作节点组成，联邦集群由联邦控制平面和多个Kubernetes集群构成。联邦控制平面负责管理多个集群，类似于Kubernetes控制平面管理一组工作节点。 联邦控制平面主要由以下三部分组成： - **etcd**：用于存储联邦API对象。 - **联邦API服务器**：作为所有其他组件通信的REST端点。 - **联邦控制器管理器**：运行各种联邦控制器，根据用户通过API服务器创建的API对象执行操作。 用户与联邦API服务器交互创建联邦API对象（或联邦资源），联邦控制器监控这些对象，然后与底层集群的API服务器通信，创建常规的Kubernetes资源。以下是集群联邦架构的简单示意： ```mermaid graph LR classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; subgraph "Federated Control Plane" etcd(etcd):::process FedAPIServer(Federation API server):::process FedControllerMgr(Federation Controller Manager):::process end subgraph "Cluster 1 (e.g., San Francisco)" C1ControlPlane(Control Plane):::process C1WorkerNode1(Worker node):::process C1WorkerNode2(Worker node):::process C1WorkerNode3(Worker node):::process end subgraph "Cluster 2 (e.g., London)" C2ControlPlane(Control Plane):::process C2WorkerNode1(Worker node):::process C2WorkerNode2(Worker node):::process C2WorkerNode3(Worker node):::process end FedAPIServer --> etcd FedAPIServer --> FedControllerMgr FedControllerMgr --> C1ControlPlane FedControllerMgr --> C2ControlPlane C1ControlPlane --> C1WorkerNode1 C1ControlPlane --> C1WorkerNode2 C1ControlPlane --> C1WorkerNode3 C2ControlPlane --> C2WorkerNode1 C2ControlPlane --> C2WorkerNode2 C2ControlPlane --> C2WorkerNode3 ``` #### 3. 联邦API对象 联邦API服务器允许创建在Kubernetes中所学对象的联邦变体。目前支持的联邦资源包括： - **命名空间（Namespaces）** - **配置映射和密钥（ConfigMaps and Secrets）** - **服务和入口（Services and Ingresses）** - **部署、副本集、作业和守护进程集（Deployments, ReplicaSets, Jobs, and Daemonsets）** - **水平Pod自动伸缩器（HorizontalPodAutoscalers）** 此外，联邦API服务器还支持`Cluster`对象，它代表底层的Kubernetes集群，类似于常规Kubernetes集群中的`Node`对象代表工作节点。 当在联邦API服务器中创建部分联邦对象时，联邦控制器管理器中的控制器会在所有底层Kubernetes集群中创建常规的集群范围资源，并进行管理，直到联邦对象被删除。不同类型的联邦资源在底层集群中的创建情况有所不同： - **精确复制类型**：如命名空间、配置映射、密钥、服务和守护进程集，在底层集群中创建的资源是联邦资源的精确副本。例如，在联邦API服务器中创建一个命名空间，所有底层集群都会创建同名的命名空间；在该命名空间内创建联邦配置映射，所有底层集群的相同命名空间中都会创建具有相同名称和内容的配置映射。 - **调整复制类型**：如副本集和部署，不会简单地复制到底层集群。当指定所需副本数时，联邦控制器会在底层集群中创建相应的部署/副本集，使它们的所需副本数之和等于联邦部署或副本集中指定的副本数。默认情况下，副本会均匀分布在各个集群，但可进行调整。 - **特殊类型**：联邦入口资源不会在底层集群中创建任何入口对象，而是创建一个跨所有底层集群服务的全局、多集群范围的入口点。不过，这需要一个联邦入口控制器。 需要注意的是，目前需要分别连接到每个集群的API服务器才能获取该集群中运行的Pod列表，无法通过联邦API服务器列出所有集群的Pod。 #### 4. 集群操作与资源管理 在Kubernetes中，集群的操作和资源管理涉及多个方面，包括集群的创建、连接、资源限制和安全控制等。 ##### 4.1 集群操作 - **集群创建与管理**：可以使用不同方式创建和管理Kubernetes集群，如使用Minikube运行本地单节点集群，或使用kubeadm创建多节点集群。创建多节点集群时，需要配置主节点和工作节点，包括设置操作系统和所需软件包。 - **Minikube**：可快速搭建本地单节点集群，方便开发和测试。通过以下步骤启动： ```bash minikube start ``` - **kubeadm**：创建多节点集群的步骤如下： 1. 设置操作系统和所需软件包。 2. 配置主节点： ```bash kubeadm init --apiserver-advertise-address=<MASTER_IP> ``` 3. 配置工作节点，加入集群： ```bash kubeadm join <MASTER_IP>:<PORT> --token <TOKEN> --discovery-token-ca-cert-hash <HASH> ``` - **集群连接与切换**：使用kubeconfig文件管理多个集群的连接信息，可通过以下操作进行管理： - **添加集群配置**： ```bash kubectl config set-cluster <CLUSTER_NAME> --server=<SERVER_URL> --certificate-authority=<CA_PATH> ``` - **切换上下文**： ```bash kubectl config use-context <CONTEXT_NAME> ``` ##### 4.2 资源管理 - **资源限制**：对容器可用的计算资源进行限制，包括CPU和内存。可以设置硬限制和请求资源量，以确保资源的合理使用。 - **设置资源限制**：在Pod定义中添加资源限制： ```yaml apiVersion: v ```