etcd、kube-apiserver、kube-controller-manager和kube-scheduler有什么区别
在我们部署K8S集群的时候
初始化master节点之后（在master上面执行这条初始化命令）
kubeadm init --apiserver-advertise-address=10.0.1.176 --image-repository registry.aliyuncs.com/google_containers --kubernetes-version v1.16.0 --service-cidr=10.140.0.0/16 --pod-network-cidr=10.240.0.0/16
然后就会在master机器上面的/etc/kubernetes/manifests看到
etcd、kube-apiserver、kube-controller-manager和kube-scheduler的配置文件
1. 相同点
- **集群关键组件**：它们都是Kubernetes集群中非常重要的组成部分，共同协作来保证集群的正常运行。就像一个交响乐团中的不同乐器组，虽然各自有分工，但要一起演奏才能呈现出完整的乐曲。
- **数据共享与交互**：这些组件之间相互关联，会共享和交互数据。它们通过各种方式（如API调用、消息传递等）来协调工作，确保整个集群的状态是一致的。
- 不同点和用处
- etcd
- 功能形象比喻：可以把etcd看作是集群的“记忆中心”或者“信息仓库”。
- 具体作用：它是一个分布式的键 - 值存储系统，用于存储Kubernetes集群的所有配置数据和状态信息。例如，每个Pod的详细信息（如IP地址、所属的服务等）、各种资源对象（如Deployment、Service等）的定义和状态都存储在etcd中。当其他组件（如kube - apiserver）需要查询或者更新这些信息时，就会和etcd进行交互。这就好比乐团的乐谱管理中心，所有的曲目（集群信息）都存放在这里，供乐手（其他组件）查阅和修改。
- kube - apiserver
- 功能形象比喻：如同集群的“总服务台”或者“通信枢纽”。
- 具体作用：它提供了集群的API接口，接收来自外部（如用户通过kubectl命令行工具或者其他自动化系统）的请求，这些请求包括创建、读取、更新和删除集群中的各种资源（如Pod、Service等）。它还负责与集群内的其他组件进行通信，协调它们的工作。就像乐团的指挥助理，接收来自观众（外部请求）的要求，并传达给各个乐器组（其他组件）。
- kube - controller - manager
- 功能形象比喻：类似于集群的“状态监管员”或者“自动修正小队”。
- 具体作用：它管理着一组控制器，这些控制器负责不断检查和维护集群的状态。例如，副本控制器会确保某个应用的副本数量符合用户设定的要求；节点控制器会关注节点的状态，当节点出现故障时，会将该节点上的Pod重新调度到其他正常节点。它就像乐团中的调音师，时刻关注每个乐器（资源）的状态，一旦发现走音（状态异常）就会进行调整。
- kube - scheduler
- 功能形象比喻：可以看作是集群的“任务分配大师”或者“工作调度员”。
- 具体作用：它的主要职责是决定将新创建的Pod分配到哪个工作节点（Node）上运行。在做决策时，它会考虑节点的资源（如CPU、内存）空闲情况、当前的负载以及Pod的资源需求等因素。这就好比乐团排练时的座位安排员，根据每个乐手（Pod）的特点（资源需求）和座位（节点）的情况，合理地安排乐手就座。
- etcd
此外
- kube - apiserver都是在master节点上，而Master节点可以有多个，所以kube - apiserver也会有多个，为了高可用。
- kube - controller - manager
- 都是在master节点上，而Master节点可以有多个，所以kube - controller - manager也会有多个，为了高可用。，以提供冗余和高可用性。
- kube - scheduler
- 都是在master节点上，而Master节点可以有多个，所以kube - scheduler也会有多个，为了高可用。，以提供冗余和高可用性。
- etcd
- 但etcd可以独立于Master节点。etcd是一个分布式键 - 值存储系统，会在多个节点（可以是专门的etcd节点，也可以和Master节点复用）之间进行复制。这意味着etcd集群可能由多个节点组成，而不仅仅局限于Master节点。