（一）节点类型
Kubernetes 架构主要涵盖两种节点类型：主节点（Master Node）与工作节点（Worker Node）。
主节点负责管控整个集群的控制平面，犹如乐队指挥，掌控着演出节奏。它对各个工作节点予以协调和管理，以保障集群稳定运行并实现高效资源分配。
工作节点是具体执行任务的场所，负责运行实际的应用程序（即容器化的应用）。可将工作节点视作乐队中的乐手，他们依照指挥的指示，奏响美妙旋律。
（二）主节点组成
etcd：
etcd 作为分布式键值存储，类似于 Kubernetes 的“数据库”。主要用于保存集群的全部数据，包括集群状态、配置以及元数据等。借助 Raft 协议确保数据具有强一致性，即便部分节点出现故障，集群状态依旧能够保持一致。采用多节点部署方式实现高可用性，以此保证数据的可靠存储。一旦 etcd 发生问题，集群的状态和配置信息极有可能会丢失。
API Server：
Kubernetes 的 API 服务器，是集群的前端入口。负责处理外部请求，如 kubectl 命令、控制平面的组件请求等。提供认证、授权、准入控制、API 注册等功能，确保只有合法的用户和请求能够访问集群资源。所有的资源配置变更都通过 API Server 进行，它是整个 Kubernetes 集群的核心枢纽，所有组件的交互都依赖于它。
调度程序（kube-scheduler）：
负责依据调度策略将 Pod 分配到合适的工作节点上。在进行调度时，会考虑资源需求（CPU、内存等）、节点的健康状况、拓扑扩展、亲和性等因素。通过合理的调度，确保资源的高效利用和负载均衡，决定 Pod 应该在哪个节点上运行。
控制管理器（kube-controller-manager）：
是多个控制器的集合，用于管理集群的状态。每个控制器负责维护某种资源的状态。例如 ReplicationController 确保系统中有正确数量的 Pod，Node Controller 负责检测节点的状态，Endpoint Controller 管理 Service 和 Pod 之间的连接等。负责在集群中维护“所期望的状态”，即集群资源应该达到的理想状态。
kubelet：
kubelet 虽然位于工作节点上，但在主节点的控制下发挥重要作用。它负责节点上 Pod 的创建、启动、监控和销毁。从 API 服务器获取 Pod 的定义，并确保容器按照定义正确运行。还将节点和 Pod 的状态报告回主节点。
kube-proxy：
在工作节点上，负责为 Kubernetes Service 提供网络代理功能。维护网络规则，将外部请求路由到正确的 Pod。支持基于 IP 和端口的网络连接转发，以及基于 VIP 的流量负载均衡。确保服务发现和负载均衡功能能够在集群内外顺利运行。
Pod：
Pod 是 Kubernetes 的最小管理单元，它可以包含一个或多个容器。这些容器共享相同的网络命名空间和存储卷，通常一起工作，共享数据和资源。Pod 的引入允许容器之间共享数据和互相通信，同时也提供了一种逻辑封装，使应用程序和其依赖的资源能够一起部署和调度。
