203 lines
14 KiB
Markdown
203 lines
14 KiB
Markdown
在Kubernetes中，集群分为Master节点（也称为控制平面节点）和Worker节点（也称为Node节点）。每个节点类型上运行着不同的组件，这些组件共同工作以管理Kubernetes集群。
|
||
|
||
### 一、Master节点（控制平面）组件：
|
||
|
||
1. **kube-apiserver**：作为Kubernetes API的服务端，它是集群的管理中心，其他组件都通过API与之通信。
|
||
2. **etcd**：一个分布式键值存储，用于保存所有集群数据，是集群状态的“真理源”
|
||
3. **kube-scheduler**：负责决定将新创建的Pods分配到哪个节点上，根据资源需求、服务质量要求、亲和性和反亲和性规范等因素进行调度
|
||
4. **kube-controller-manager**：它运行集群级别的控制循环，例如节点控制器、副本控制器、端点控制器、服务帐户和令牌控制器等
|
||
5. **cloud-controller-manager**（可选）：当Kubernetes运行在云服务提供商的环境中时，该组件允许将集群操作与云服务提供商的APIs相链接
|
||
|
||
### 二、Node节点组件：
|
||
|
||
1. **kubelet**：在每个Node节点上运行的代理，确保容器在Pods中正确运行。它管理的操作包括Pod的创建、启动、监控等
|
||
2. **kube-proxy**：在Node节点上运行的网络代理，用于维护节点上的网络规则，实现Service资源的网络连接
|
||
3. **Container Runtime**：容器运行环境，负责运行容器。常见的容器运行时包括Docker、containerd和CRI-O
|
||
|
||
### 三、其他重要组件：
|
||
|
||
- **CoreDNS**（或者Kube-DNS）：提供集群内部的DNS服务，使得Pods和Services可以通过名称互相查找
|
||
- **Metrics Server**（可选）：用于收集资源使用信息，这对于资源自动扩展（如Horizontal Pod Autoscaler）是必要的
|
||
- **Dashboard**（可选）：提供了一个基本的Web UI，可以用来查看和管理集群
|
||
- **Ingress Controller**（可选）：用于处理外部访问集群服务的规则和路由，常见的有nginx-ingress、traefik等
|
||
|
||
请注意，Kubernetes项目经常更新，所以特定版本的Kubernetes可能引入或弃用某些组件。此外，Kubernetes生态系统中还有许多其他的插件和扩展，可以根据需要添加到集群中
|
||
|
||
### 四、Kubernetes 组件架构图
|
||
|
||
|
||
|
||
### 五、具体组件
|
||
|
||
#### 1. etcd
|
||
|
||
> 详细解读，后续加入 ../etcd/etcd.md
|
||
|
||
##### 1.1 概述
|
||
|
||
etcd是一个分布式键值数据库，它使用Raft协议实现了强一致性和高可用性。etcd专为分布式系统设计，可以忍受网络分区并保持可用性，同时保证了读写操作的一致性。
|
||
|
||
- **Raft协议**：Raft是一个一致性算法，Raft通过选举一个领导者来管理日志复制。在etcd集群中，所有的变更（如写操作）都通过领导者进行协调，这些变更被分发到其他节点（称为Follower）以保持状态一致
|
||
|
||
- **存储模型**：etcd使用键值对存储数据。它支持事务、监视键的变化、时间点快照（snapshot）和自动清理（compaction）
|
||
|
||
- **gRPC和HTTP/2**：etcd使用gRPC作为其客户端和服务器之间的通信机制，它基于HTTP/2协议提供了双向流、头部压缩、多路复用请求等特性
|
||
|
||
##### 1.2 功能
|
||
|
||
etcd在Kubernetes中是保存整个集群状态的后端数据库。以下是它在Kubernetes集群中承担的一些关键功能：
|
||
|
||
- **保存集群数据**：etcd存储了整个Kubernetes的状态信息，包括节点信息、Pods状态、配置数据、Secrets、Deployments、DaemonSets等资源的状态和元数据。
|
||
|
||
- **服务发现**：etcd可以用作服务发现机制，因为它保存了所有Pods和服务的信息以及它们的位置。
|
||
|
||
- **分布式系统的同步**：etcd为Kubernetes提供了一个可靠的服务，以同步分布在集群中的服务的状态。
|
||
|
||
- **持久化存储**：即使Kubernetes控制平面的组件出现故障，etcd确保集群的配置数据不会丢失。
|
||
|
||
- **实现锁和领导者选举**：etcd的强一致性模型可以用于实现分布式锁或选举集群中的领导者
|
||
|
||
- **观察变更**：客户端可以监视特定键的变化，当这些键被修改时，etcd会通知客户端。这对于实现自动更新配置非常有用
|
||
|
||
##### 1.3 组件交互
|
||
|
||
###### 1.3.1. kube-apiserver与etcd的交互
|
||
|
||
kube-apiserver是与etcd交互最频繁的组件。它作为Kubernetes API的前端服务，处理用户、内部组件和外部组件的所有请求。当这些请求涉及到集群状态的变更或查询时，kube-apiserver会与etcd通信：
|
||
|
||
- **读取操作**：当需要获取集群状态时（例如，获取Pod列表），kube-apiserver会从etcd读取数据
|
||
- **写入操作**：当创建、更新或删除Kubernetes资源（如Deployments、Services等）时，kube-apiserver会将这些变更写入etcd
|
||
- **监视操作**：kube-apiserver还可以监视etcd中的资源变更。这使得控制器可以响应资源状态的变化，执行相应的业务逻辑（如调度Pod或更新Endpoints）
|
||
|
||
###### 1.3.2控制器与etcd的交互
|
||
|
||
虽然控制器通常不直接与etcd交互，但它们依赖于kube-apiserver提供的信息，这些信息最终来源于etcd：
|
||
|
||
- **控制循环**：控制器通过kube-apiserver观察集群状态的变化（例如，新的Pod需要被调度），并在状态变化时作出响应，执行必要的操作以推动集群状态向期望状态转变
|
||
- **状态更新**：当控制器作出决策并执行操作后（如创建新的Pods），它们会通过kube-apiserver将新状态写回etcd
|
||
|
||
###### 1.3.3. kube-scheduler与etcd的交互
|
||
|
||
kube-scheduler负责决定将Pods分配给哪个节点。它使用的信息同样来自etcd，但通过kube-apiserver提供：
|
||
|
||
- **调度决策**：kube-scheduler监视新创建且未分配到节点的Pods，选择最适合的节点进行调度，并通过kube-apiserver更新Pods的信息，这些信息最终保存在etcd中
|
||
|
||
###### 1.3.4. kubelet与etcd的交互
|
||
|
||
kubelet负责管理分配给其节点的Pods，并保证Pods的状态与etcd中保存的期望状态一致。不过，kubelet与etcd的交互也是通过kube-apiserver进行的：
|
||
|
||
- **状态报告**：kubelet定期向kube-apiserver报告Pod状态，这些状态信息随后被存储在etcd中
|
||
- **配置获取**：当kubelet启动或运行时，它会从kube-apiserver获取必要的配置信息，这些信息最终来自etcd
|
||
|
||
#### 2. kube-apiserver
|
||
|
||
##### 2.1 概述
|
||
|
||
kube-apiserver 是 Kubernetes 控制平面的核心组件，它提供了 Kubernetes API 的服务端实现。kube-apiserver 设计成了一个无状态的 HTTP 服务器，它处理集群内外的 REST API 请求，并提供 JSON 格式的资源状态数据。可以通过增加 kube-apiserver 实例的数量来横向扩展服务，以支持更高的负载
|
||
|
||
##### 2.2 功能
|
||
|
||
- **API 提供**：作为 Kubernetes API 的入口点，提供 RESTful API 供用户、外部系统和集群内部组件调用
|
||
|
||
- **资源操作**：处理对各种 Kubernetes 资源（如 Pods、Services、Deployments 等）的操作请求
|
||
|
||
- **认证和授权**：确保所有进入集群的请求都经过适当的安全检查
|
||
|
||
- **数据校验**：在将数据持久化到 etcd 之前，对资源定义进行校验，保证数据的完整性和准确性
|
||
|
||
- **集群状态管理**：维护和管理集群的状态信息，包括资源的创建、更新、删除和查询
|
||
|
||
- **API 聚合**：通过 API 聚合层，kube-apiserver 能够扩展新的 API 服务器，支持自定义资源和扩展 Kubernetes API
|
||
|
||
- **扩展机制**：支持通过 Webhooks 或其他机制扩展其功能，如自定义调度器、准入控制器等
|
||
|
||
- **监控和日志**：提供监控 API 端点，允许集群监控和日志系统访问集群操作数据
|
||
|
||
- **服务发现**：通过 API 提供服务发现机制，允许 Pods 通过服务名来互相发现和通信
|
||
|
||
<img src="https://blog-heysq-1255479807.cos.ap-beijing.myqcloud.com/halo2/202401241133880.png" alt="How to Monitor Kubernetes API Server – Sysdig" style="zoom:67%;" />
|
||
|
||
|
||
|
||
#### 3. kube-scheduler
|
||
|
||
##### 3.1 概述
|
||
|
||
负责集群中的Pod调度。其基本工作原理是：在Kubernetes集群中，当我们创建一个Pod并提交给kube-apiserver后，kube-scheduler会根据当前集群的状态，通过一系列复杂的调度算法，决定将Pod放置到哪个Node上运行
|
||
|
||
##### 3.2 功能
|
||
|
||
- **负载均衡：**通过合理的调度策略，kube-scheduler可以将工作负载分散到各个工作节点，避免资源的浪费和瓶颈
|
||
|
||
- **高可用：**在节点失效时，kube-scheduler可以将其上的Pod重新调度到其他节点，保证应用的可用性
|
||
|
||
- **亲和性和反亲和性调度：**kube-scheduler可以根据用户定义的亲和性和反亲和性规则，将相关联的Pod调度到同一或不同的节点上
|
||
|
||
- **资源预留和限制：**kube-scheduler可以根据Pod的资源请求和限制进行调度，确保每个Pod在运行时都能获取到足够的资源
|
||
|
||
- **多租户支持：**kube-scheduler支持通过Namespace和ResourceQuota进行多租户调度，保证每个租户获得公平的资源分配
|
||
|
||
##### 3.3 工作过程概述
|
||
|
||
- kube-scheduler从etcd中获取集群所有节点的信息
|
||
|
||
- kube-scheduler监听kube-apiserver的Pod事件，当有新的Pod创建时，kube-scheduler会接收到这个事件。
|
||
|
||
- 对于接收到的每个未调度的Pod，kube-scheduler都会开始进行调度
|
||
|
||
- 调度过程首先会进行预选（Predicates）阶段，过滤掉不符合调度要求（例如资源不足、标签不匹配等）的节点
|
||
|
||
- 然后进入优选（Priorities）阶段，对剩余的节点进行打分，分数高的节点将被选为候选节点
|
||
|
||
- 最后，kube-scheduler会将Pod的nodeName字段设置为选定的节点，然后kubelet会在该节点上启动Pod
|
||
|
||
#### 4. kube-controller-manager
|
||
|
||
##### 4.1 概述
|
||
|
||
kube-controller-manager是Kubernetes集群中的一个重要组件，它负责管理和运行控制器。控制器是Kubernetes中实现其各种功能的后台线程，例如，Node控制器负责处理节点故障，Replica控制器负责维护Pod副本的正确数量，Service控制器负责设置负载均衡器等
|
||
|
||
##### 4.2 功能
|
||
|
||
- **节点管理：**Node控制器负责处理节点故障，如果一个节点在一定时间内没有响应，节点控制器就会把该节点上的Pod移动到其他节点上。
|
||
- **Pod副本管理：**Replica控制器负责维护每个ReplicaSet或Deployment中Pod的正确数量。
|
||
- **服务负载均衡：**Service控制器负责设置云提供商的负载均衡器，以实现Service的LoadBalancer类型。
|
||
- **卷管理：**PersientVolume控制器负责管理持久卷和持久卷声明，例如创建、删除和挂载卷。
|
||
- **名称空间管理：**Namespace控制器负责删除在命名空间中的所有资源，当该命名空间被删除时。
|
||
- **服务账户和令牌管理：**ServiceAccount控制器创建默认服务账户和API访问令牌。
|
||
- **Job和CronJob管理：**Job控制器和CronJob控制器负责管理Job和CronJob，例如创建和删除Job，以及触发CronJob。
|
||
|
||
#### 5. kubelet
|
||
|
||
##### 5.1 概述
|
||
|
||
kubelet是Kubernetes集群中每个节点上运行的代理，它负责管理该节点上的容器运行时，以及Pod的创建、启动、停止等生命周期操作。kubelet主要和Kubernetes API服务器交互，获取需要运行的Pod信息，然后确保这些Pod和其中的容器正确运行
|
||
|
||
##### 5.2 功能
|
||
|
||
- Pod生命周期管理：kubelet负责创建、启动和停止Pod，以及Pod中的容器
|
||
- 节点状态管理：kubelet会周期性地收集节点和容器的状态信息，并将这些信息报告给Kubernetes API服务器
|
||
- 容器运行时管理：kubelet负责和容器运行时（例如Docker或rkt）交互，创建和管理容器
|
||
- 资源监控：kubelet可以收集和报告节点和容器的资源使用信息，例如CPU、内存和存储的使用情况
|
||
- 日志管理：kubelet可以帮助用户收集和存储容器的日志，方便用户查看和调试
|
||
- 安全和隔离：kubelet可以设置Pod的网络和安全上下文，例如网络策略、安全上下文和SELinux标签，以确保容器的隔离和安全
|
||
|
||
#### 6. kube-proxy
|
||
|
||
##### 6.1 概述
|
||
|
||
kube-proxy是Kubernetes集群中每个节点上运行的网络代理，负责实现Kubernetes Service的概念。它的主要职责是管理节点上的网络规则，并进行连接转发，以实现服务发现和负载均衡
|
||
|
||
kube-proxy的实现原理主要包括以下几个步骤：
|
||
|
||
1. kube-proxy首先会从Kubernetes API服务器获取集群中Service和Endpoint的信息
|
||
2. 然后，kube-proxy会在节点上设置网络规则，以捕获到达Service Cluster IP和Port的流量，并将这些流量转发到正确的Pod
|
||
3. kube-proxy会周期性地检查从API服务器获取的Service和Endpoint信息，如果有任何变化，kube-proxy会相应地更新网络规则
|
||
|
||
##### 6.2 功能
|
||
|
||
- 服务发现：kube-proxy负责实现Kubernetes Service的概念，使得应用可以通过Service名称来发现服务，而不需要知道具体的Pod IP
|
||
- 负载均衡：kube-proxy可以将到达Service的连接转发到后端的多个Pod，从而实现负载均衡。转发策略可以是轮询（Round Robin）、随机（Random）或者基于源IP的hash
|
||
- 网络规则管理：kube-proxy负责在节点上设置和管理网络规则，以实现服务发现和负载均衡
|
||
- 健康检查：kube-proxy会周期性地检查后端Pod的健康状态，如果某个Pod不健康，kube-proxy会将其从服务的后端列表中移除
|
||
- 流量控制：kube-proxy支持基于Session Affinity的流量控制，可以将来自同一客户端的所有请求都转发到同一个Pod |