【云原生技术】- Kubernetes两类节点 主节点（Master Node）和工作节点（Worker Node）介绍
主节点（Master Node）和工作节点（Worker Node）介绍
- 一、主节点（Master Node）
-
- 1. **定义**：
- 2. **作用**：
-
- 2.1 **API Server**：作为集群的管理接口，处理外部和内部的请求。
- 2.2 **Scheduler**：负责调度 Pod 到合适的工作节点上。
- 2.3 **Controller Manager**：管理控制器，监控集群的状态。
- 2.4 **etcd**：用作集群的配置和状态数据存储。
- 3. **示例**：
-
-
- 步骤 1: 创建部署和 Pod 请求
- 步骤 2: API Server 处理请求
- 步骤 3: 调度器选择节点
- 步骤 4: Pod 在工作节点上启动
- 步骤 5: 运行状态和健康检查
- 结论
-
- 二、工作节点（Worker Node）
-
- 1. **定义**：
- 2. **作用**：
-
- 2.1 **Kubelet**：负责启动和管理 Pod，以及与主节点通信。
- 2.2 **Kube-Proxy**：管理节点的网络规则，使得 Pod 能够相互通信和与外部通。
- 2.3 **Container Runtime**：容器运行时环境，用于运行容器（如 Docker）。
- 3. **示例**：
-
-
- 步骤 1: 创建和调度 Pod
- 步骤 2: Kubelet 管理 Pod
- 步骤 3: Kube-Proxy 处理网络流量
- 步骤 4: 数据持久化和状态管理
- 步骤 5: 监控和日志
- 总结
-
- 三、联系与区别
在 Kubernetes（K8s）中，主要有两种类型的节点：主节点（Master Node）和工作节点（Worker Node）。每种节点在集群中扮演不同的角色。
一、主节点（Master Node）
1. 定义：
- 主节点是 Kubernetes 集群的控制节点，负责整个集群的管理和控制。
2. 作用：
2.1 API Server：作为集群的管理接口，处理外部和内部的请求。
API Server通常运行在 Kubernetes 集群的主节点（Master Node）中。它是 Kubernetes 控制平面的关键组件之一，作为集群的管理接口，处理外部和内部的请求
**API Server 的角色和功能**
1. **请求处理**：API Server 处理来自用户、内部组件和外部客户端的 RESTful API 请求。
2. **数据存储**：它将集群的状态数据（如 Pod、Service 配置）存储在 etcd 中。
3. **身份验证和授权**：API Server 对请求进行身份验证和授权，确保只有合法和授权的操作能被执行。
4. **API 资源暴露**：它暴露了 Kubernetes API，使得各种工具和客户端（如 kubectl、控制器等）可以与集群交互。
**运行位置**
- 在单主节点的 Kubernetes 集群中，API Server 只在这个主节点上运行。
- 在具有多个主节点的高可用（HA）集群中，每个主节点上都运行一个 API Server 实例，以提供冗余和负载均衡。
**与其他组件的交互**
- **etcd**：API Server 读写 etcd 存储，这是集群的主要数据存储。
- **调度器（Scheduler）**和**控制器管理器（Controller Manager）**：这些组件通过 API Server 监视集群状态并作出相应的调整。
总之，API Server 是 Kubernetes 架构中至关重要的组件，位于集群的管理中心，处理所有的 API 请求，并维护着集群的状态和配置信息。
2.2 Scheduler：负责调度 Pod 到合适的工作节点上。
Scheduler（调度器）通常运行在 Kubernetes 集群的主节点（Master Node）中。它是 Kubernetes 控制平面的关键组件之一，负责决定将新创建的 Pod 放置在哪个工作节点（Worker Node）上。
### Scheduler 的角色和功能
1. **Pod 调度**：当一个新的 Pod 被创建并需要被调度时，Scheduler 会选择一个最适合的节点来运行这个 Pod。
2. **资源考量**：在选择节点时，Scheduler 考虑多个因素，包括但不限于节点的资源使用情况（如 CPU、内存可用性）、Pod 的特定需求（如亲和性、反亲和性规则）、污点和容忍度、网络拓扑等。
3. **负载均衡**：Scheduler 还尝试平衡集群的负载，避免某些节点过载而其他节点空闲。
### 运行位置
- 在**单主节点的集群**中，Scheduler 运行在同一个主节点上，与 API Server、Controller Manager 和 etcd 一起。
- 在**高可用（HA）集群**中，可以在多个主节点上运行 Scheduler 的副本，以提高可靠性和容错能力。
### 与其他组件的交互
- Scheduler 与 **API Server** 紧密交互，通过 API Server 监视集群中的 Pod 和节点状态，并根据这些信息做出调度决策。
- 一旦决定了 Pod 的调度位置，Scheduler 会更新 Pod 的信息，指明它应该在哪个节点上运行。然后，节点上的 **Kubelet** 开始启动和管理这个 Pod。
### 总结
Scheduler 是 Kubernetes 集群中的一个重要组件，负责高效地将 Pod 分配到合适的节点上。它的智能调度策略确保了集群资源的有效利用和应用性能的优化。Scheduler 通常部署在主节点上，但在大型或高可用性的集群配置中，可能会以不同方式部署以提高性能和可靠性。
2.3 Controller Manager：管理控制器，监控集群的状态。
Controller Manager（kube-controller-manager）它是 Kubernetes 控制平面的核心组件之一，负责运行集群级别的控制循环。
### Controller Manager 的角色和功能
1. **控制循环运行**：Controller Manager 运行多个控制器，每个控制器都是一个控制循环，负责维护集群的特定方面。
2. **响应集群事件**：控制器监视集群的状态，并对变化做出反应，以确保实际状态与期望状态一致。
3. **管理资源**：包括节点、Pod、服务端点等。
### 常见的控制器
- **节点控制器**：负责监测节点的状态。
- **复制控制器**：确保指定数量的 Pod 副本始终运行。
- **端点控制器**：填充服务（Service）的端点。
- **服务账户和令牌控制器**：为新的命名空间创建默认账户和 API 访问令牌。
### 部署方式
- 在**单主节点的集群**中，Controller Manager 与 API Server、Scheduler 和 etcd 一起运行在同一个主节点上。
- 在**高可用（HA）集群**中，可以在多个主节点上运行 Controller Manager 的副本，以提高可靠性和容错能力。
### 与其他组件的交互
- Controller Manager 通过与 API Server 的通信来监控和更新集群状态。
- 它不直接与集群内的工作节点或 Pod 通信，而是通过 API Server 来影响这些资源。
### 主要的控制器
Kubernetes 的 Controller Manager 包含多个控制器，每个控制器负责管理集群中的特定资源或行为。以下是一些主要的控制器：
1. **Node Controller**：
- 管理节点，负责在节点发生故障时进行通知和响应。
2. **Replication Controller**：
- 确保指定数量的 Pod 副本始终运行。
3. **Endpoints Controller**：
- 填充 Service 的 Endpoints，即维护服务和 Pod 之间的映射关系。
4. **Service Account & Token Controllers**：
- 为新的命名空间创建默认账户和 API 访问令牌。
5. **Deployment Controller**：
- 处理 Deployment 资源，确保应用的部署状态符合用户定义的期望状态。
6. **DaemonSet Controller**：
- 确保所有（或某些特定）节点运行一个 Pod 的副本。
7. **Job Controller**：
- 监控 Job 对象，确保指定数量的 Pod 成功完成。
8. **ReplicaSet Controller**：
- Deployment Controller 的一部分，确保 ReplicaSet 对象中定义的 Pod 副本数量保持正确。
9. **StatefulSet Controller**：
- 管理 StatefulSet 资源，确保应用的有状态操作按预期执行。
10. **PersistentVolume Controller**：
- 处理持久卷（PV）和持久卷申领（PVC）的绑定。
11. **Namespace Controller**：
- 清理已删除的命名空间下的资源。
这些控制器共同工作，管理 Kubernetes 集群的不同方面，确保集群的稳定运行和资源的正确分配。每个控制器都专注于特定的任务，通过不断地观察集群状态，对资源变化做出响应，以实现声明的期望状态。
### 总结
Controller Manager 在 Kubernetes 集群中起着关键作用，运行多种控制器来管理和维护集群的正常运行。它通常部署在主节点上，但在大型或高可用性的集群配置中，可能会以不同方式部署以提高性能和可靠性。
2.4 etcd：用作集群的配置和状态数据存储。
etcd 通常运行在 Kubernetes 集群的主节点（Master Node）上，但它的部署方式可以根据集群的大小和需求有所不同。
### etcd 在单主节点集群中
- 在小型或测试用途的 Kubernetes 集群中，`etcd` 通常与 API Server、调度器（Scheduler）和控制器管理器（Controller Manager）一起部署在同一个主节点上。
### etcd 在高可用（HA）集群中
- 在大型或生产环境中，特别是在需要高可用的场景下，`etcd` 通常部署在一个独立的集群中。这种部署方式可以防止单点故障，提高整体集群的稳定性和可靠性。
- 在这种配置中，`etcd` 集群由多个节点组成，以确保数据的一致性和可靠性。同时，多个 Kubernetes 主节点上的 API Server 会连接到这个 `etcd` 集群。
### etcd 的作用
- `etcd` 是一个分布式键值存储，用来保存 Kubernetes 集群的所有重要信息，包括集群配置、状态和元数据。
- 它是 Kubernetes 集群的主要数据存储，由于其对数据一致性的要求，`etcd` 的部署和运行需要谨慎管理。
### 总结
在 Kubernetes 集群中，`etcd` 可以部署在主节点上，也可以为了高可用性和性能部署在一个独立的集群中。它是 Kubernetes 集群的关键组件，负责存储集群的状态和配置数据。集群规模和需求决定了 `etcd` 的最佳部署方式。
3. 示例：
-
在一个 Kubernetes 集群中，主节点监控集群的状态，比如一个部署的 Pod 数量不足。主节点的调度器会决定在哪个工作节点上启动新的 Pod 来满足部署配置。
在 Kubernetes 集群中，主节点的调度器（Scheduler）负责决定 Pod 在哪个工作节点上启动，以满足部署配置。这个过程涉及多个步骤和组件的协同工作。以下是这个过程的具体细节：步骤 1: 创建部署和 Pod 请求
- 用户创建部署：用户通过 Kubernetes API（使用
kubectl或其他 API 客户端）提交一个部署（Deployment）请求。部署定义了应用的期望状态，包括需要运行的 Pod 副本数量、容器镜像等。
步骤 2: API Server 处理请求
- API Server 接收请求：API Server 接收到部署请求后，将其存储在 etcd 中。
- 部署控制器响应：部署控制器（一种 Kubernetes 控制器）监测到新的部署请求，根据部署定义创建一组 Pod。
步骤 3: 调度器选择节点
- 调度器决定 Pod 放置：新创建的 Pod 初始状态为 Pending。调度器（Scheduler）观察到这些 Pod 后，开始选择合适的工作节点来运行它们。
- 选择标准：调度器根据多个因素选择节点，包括：
- 资源需求（如 CPU、内存）。
- 亲和性和反亲和性规则。
- 污点和容忍度。
- 节点的健康状况和其他约束。
步骤 4: Pod 在工作节点上启动
- 节点上的 Kubelet 启动 Pod：一旦调度器选择了工作节点，Pod 的状态被更新，包含它应该运行在哪个节点上。被选中的节点上的 Kubelet 会被通知这一决定。
- Kubelet 启动容器：Kubelet 与容器运行时（如 Docker）协作，根据 Pod 规范在节点上启动容器。
步骤 5: 运行状态和健康检查
- Kubelet 监控 Pod 状态：Kubelet 定期向 API Server 报告 Pod 的状态和健康信息。
- 服务发现和负载均衡：一旦 Pod 成功启动，如果有相关的服务（Service）定义，集群内的其他 Pod 可以通过服务发现机制与新 Pod 通信。
结论
这个过程展示了 Kubernetes 如何自动管理和维护应用的期望状态。主节点的调度器确保了 Pod 能够在满足其资源和约束条件的工作节点上启动，而工作节点上的 Kubelet 负责实际启动和监控 Pod。通过这种方式，Kubernetes 实现了自动化的容器编排和集群管理。
- 用户创建部署：用户通过 Kubernetes API（使用
二、工作节点（Worker Node）
1. 定义：
- 工作节点是运行应用容器（Pod）的节点，是集群的执行者。
2. 作用：
2.1 Kubelet：负责启动和管理 Pod，以及与主节点通信。
Kubelet、Kube-Proxy 和 Container Runtime 都是 Kubernetes 集群中工作节点（Worker Node）的关键组件。它们在每个工作节点上运行，共同负责管理容器和节点级别的任务。
Kubelet 和 Kube-Proxy 在 Kubernetes 中扮演着关键的角色，它们分别负责管理 Pod 的生命周期和处理节点上的网络流量。以下是它们各自的工作方式和相互协作的过程：
### Kubelet 管理 Pod
1. **Pod 生命周期管理**：
- 当调度器（Scheduler）决定在某个节点上运行 Pod 时，它会通知那个节点的 `Kubelet`。
- `Kubelet` 接收到 Pod 创建指令后，会调用容器运行时（如 Docker）来启动 Pod 中的容器。
2. **健康检查**：
- `Kubelet` 定期对节点上的 Pod 进行健康检查，确保它们按预期运行。
- 如果检测到容器失败，`Kubelet` 会尝试重启它，以保持 Pod 的健康状态。
3. **资源分配**：
- `Kubelet` 管理节点上的资源（如 CPU、内存），根据 Pod 的配置分配资源。
4. **与 API Server 通信**：
- `Kubelet` 定期向 API Server 报告 Pod 的状态信息。
2.2 Kube-Proxy：管理节点的网络规则，使得 Pod 能够相互通信和与外部通。
### Kube-Proxy 处理网络流量
1. **网络规则设置**：
- `Kube-Proxy` 在每个节点上运行，负责设置和维护网络规则。
- 这些规则允许网络流量从外部世界和集群内部流向 Pod。
2. **服务负载均衡**：
- 当在 Kubernetes 中创建一个 Service 时，`Kube-Proxy` 会更新节点上的网络规则，以实现对该 Service 的负载均衡。
- 这确保了当请求到达 Service 的 IP 和端口时，`Kube-Proxy` 能够将请求转发到正确的 Pod。
3. **支持不同的网络模式**：
- `Kube-Proxy` 支持多种网络模式，包括 iptables、IPVS 等，以适应不同的网络需求。
### Kubelet 和 Kube-Proxy 的协作
- `Kubelet` 负责启动和管理 Pod，而 `Kube-Proxy` 负责处理 Pod 的网络流量。
- 当 `Kubelet` 启动新的 Pod 时，它会为 Pod 分配一个 IP 地址。然后 `Kube-Proxy` 会根据这个 IP 地址和与 Pod 关联的 Service 更新网络规则，以确保 Pod 可以被正确访问。
- 在整个过程中，`Kubelet` 和 `Kube-Proxy` 与 Kubernetes API Server 保持通信，以获取指令和同步状态。
通过这种方式，`Kubelet` 和 `Kube-Proxy` 共同确保了 Kubernetes 集群中的 Pod 不仅能够正确运行，而且可以被网络正确访问。
2.3 Container Runtime：容器运行时环境，用于运行容器（如 Docker）。
### Kubelet
1. **作用**：
- Kubelet 是 Kubernetes 集群中每个工作节点的主要代理，负责管理节点上的 Pod 和容器。
- 它根据 API Server 下发的 Pod 规范（PodSpecs），在节点上启动、停止和维护容器。
2. **职责**：
- 与 API Server 通信，获取分配给节点的 Pod 信息。
- 管理 Pod 的生命周期，包括创建、启动、更新和终止容器。
- 监控容器的健康状态，并根据需要进行自愈操作。
### Kube-Proxy
1. **作用**：
- Kube-Proxy 在每个工作节点上运行，负责处理节点上的网络代理。
- 它管理网络规则，允许网络流量从外部世界和集群内部流向 Pod。
2. **职责**：
- 实现 Pod 间的网络通信。
- 处理服务（Service）的负载均衡和网络转发。
### Container Runtime
1. **作用**：
- 容器运行时（如 Docker、containerd、CRI-O）是在节点上运行容器的基础软件。
- 它负责实际的容器创建、执行、监控和终止。
2. **职责**：
- 根据 Kubelet 的指令运行容器。
- 管理容器的生命周期和容器镜像。
### 总结
在 Kubernetes 的工作节点上，Kubelet、Kube-Proxy 和容器运行时协同工作，以确保容器的正常运行和网络通信的有效处理。Kubelet 作为节点代理，管理容器的生命周期和节点级别的任务；Kube-Proxy 负责网络相关的工作，如服务发现和负载均衡；而容器运行时则负责底层的容器操作。这些组件的集成为 Kubernetes 集群的运行提供了必要的支持。
3. 示例：
-
假设有一个运行在线购物应用的 Kubernetes 集群。应用的每个组件（如前端、数据库）都封装在 Pod 中，这些 Pod 被调度并运行在工作节点上。工作节点使用 Kubelet 来管理这些 Pod，并通过 Kube-Proxy 来处理网络流量。以下是这个过程的具体步骤：
步骤 1: 创建和调度 Pod
-
定义 Pod：应用的每个组件（前端、数据库等）都定义在一个或多个 Pod 中。这通常通过创建 Deployment、StatefulSet（对于数据库等有状态服务）等资源完成。
-
调度 Pod：创建 Pod 后，Kubernetes 的调度器（Scheduler）会根据集群的当前状态和 Pod 的需求（如资源请求、亲和性规则）决定在哪个工作节点上运行这些 Pod。
步骤 2: Kubelet 管理 Pod
-
启动 Pod：一旦 Pod 被调度到某个节点，该节点的
Kubelet会与容器运行时（如 Docker）通信，根据 Pod 定义启动容器。 -
健康检查：
Kubelet对 Pod 进行健康检查，确保容器正常运行。如果检测到容器失败，Kubelet可以尝试重启它。 -
资源管理：
Kubelet管理分配给 Pod 的资源（如 CPU、内存），并确保 Pod 不会超出其请求的资源限制。
步骤 3: Kube-Proxy 处理网络流量
-
服务发现：通过 Kubernetes Service 对外暴露 Pod。例如，前端服务可能有一个 Service，允许其他 Pod 或外部流量访问它。
-
网络流量转发：
Kube-Proxy在每个节点上设置适当的网络规则，使得内部或外部的流量可以正确地路由到 Service，再由 Service 路由到后端的 Pod。 -
负载均衡：当 Service 有多个后端 Pod 时，
Kube-Proxy提供负载均衡，将请求分发到这些 Pod 上。
步骤 4: 数据持久化和状态管理
-
数据库存储：对于需要持久化数据的服务（如数据库），可以使用持久卷（Persistent Volumes）和持久卷声明（Persistent Volume Claims）来存储数据。
-
状态管理：StatefulSets 用于管理有状态服务，确保这些服务的持久化存储和唯一性。
步骤 5: 监控和日志
- 监控：集成监控工具（如 Prometheus）来监控 Pod 的性能和资源使用情况。
- 日志管理：收集和分析 Pod 日志，以便于故障排查和性能优化。
总结
在这个 Kubernetes 集群中，每个应用组件被封装在 Pod 中，由
Kubelet在工作节点上管理。Kube-Proxy负责处理 Pod 的网络流量，确保服务之间可以相互通信。通过这种方式，Kubernetes 集群能够高效地运行和管理一个复杂的在线购物应用。 -
三、联系与区别
- 联系：主节点和工作节点共同构成 Kubernetes 集群，相互协作以确保应用顺利运行。主节点负责调度和管理，而工作节点负责执行和运行实际的应用。
- 区别：
- 主节点负责集群的调度和管理，不运行用户应用。
- 工作节点负责运行用户的应用容器。
在 Kubernetes 的早期版本中，主节点和工作节点的角色是严格分开的。但在最新版本的 Kubernetes 中，这种分离不再那么明显，单个节点可以同时具备主节点和工作节点的功能，尤其在小型或测试环境中。