😉😉 欢迎加入我们的学习交流群呀！

✅✅1：这是孙哥suns给大家的福利！

✨✨2：我们免费分享Netty、Dubbo、k8s、Mybatis、Spring、SpringSecurity、Docker、Grpc、各种MQ、Rpc、SpringCloud等等很多应用和源码级别高质量视频和笔记资料，你想学的我们这里都有！

🥭🥭3：QQ群：583783824   📚📚  工作VX：BigTreeJava 拉你进VX群，免费领取！

💞💞4：以上内容，进群免费领取呦~ 💞💞💞💞

🥭🥭5：学完帮你进大厂~~

一：kubernetes组件

1：集群组件概述

官方说法：

        当部署完 Kubernetes，便拥有了一个完整的集群。一组工作机器，称为节点， 会运行容器化应用程序。 每个集群至少有一个工作节点 。工作节点会 托管Pod ，而 Pod 就是作为应用负载的组件。控制平面管理集群中的工作节点和Pod。

说人话版本：

        集群：cluster，多个几点被组织到一起共同为系统提供服务过程称之为集群。本质上是将承载同一个软件服务节点组织到一起，称之为该软件(服务)的集群，当然集群中的节点身份地位是不一样的。

        k8s集群也是如此，他也是多个节点组成。不过，在k8s世界中，一组工作的机器才被称之为节点。

        k8s集群中有多个节点，我们一般建议是三个节点。三个节点有两种，第一种是Control Plane控制节点，这个类似于我们常规理解的master节点，第二种节点是work node节点类似于我们常规理解的slave。

        控制节点主要是负责调度的，他主要是负责容器的管理和资源分配。真正的work节点才是真正运行咱们得应用程序容器的。

        k8s管理的单元不是容器而是Pod，Pod不是容器，Pod相当于是给容器进行了包裹。一个Pod里边可以运行多个容器。Pod就是负载组件，控制平台管理集群中的工作节点和Pod

·        官方给的这个图：左侧是控制平面组件，右侧是我们的工作节点，一共有三个，工作节点是用来真正运行工作容器的。

        控制节点上边就是运行了一堆k8s的组件，后边我们都会分享。

2：控制平面组件 （Control Plane Components）

官方版：

        控制平面组件会为集群做出全局决策，比如资源的调度。以及检测和响应集群事件，例如当不满足部署的replicas字段时，要启动新的 pod

说人话版：        

        控制平面组件这个组件就是管调度的。检测、资源调度等等。

        控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此物理机上运行用户容器，也就是Master上不会跑Pod。

(一)：kube-apiserver

官方版：

        API server是 Kubernetes 控制平面的组件，该组件负责公开了Kubernetes API，负责处理接受请求的工作。API server是 Kubernetes控制平面的前端。Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行kube-apiserver 的多个实例，并在这些实例之间平衡流量。

说人话版：

        说白了就是操作k8s的集群的API总入口，我们操作整个的k8s集群需要些写一些命令，这些命令会优先会被apiserver接收到，我们通过Rest或者是命令的方式去调度就行了。他就是控制平面组件的总入口，就是接口用户命令的。API Server是控制平台组件的前端，但是他的真正底层实现是基于接口实现的方式，基于kube-apiserver他可以通过部署多个实例来进行扩缩，在诸多实例中实现流量平衡。

        这玩意就是接收命令请求的。

(二)：etcd

        一致且高度可用的键值存储，用作k8s所有集群数据的后台数据库

        这里边存储的是集群元数据，所谓元数据就是记录集群信息的，类似于MySQL数据库，information_schema下的数据。

(三)：kube-scheduler

官方说法：

        kube-scheduler是控制平面的组件，负责监视新创建的、未指定运行节点node的 Pods， 并选择节点来让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 及Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。

(四)：kube-controller-manager

        kube-controller-manager 是控制平面的组件，负责运行控制器进。从逻辑上讲，但是为了降低复杂性，它们每个控制器都是一个单独的进程，都被编译到同一个可执行文件，并在同一个进程中运行。

这些控制器包括：

        节点控制器(Node Controller)：负责在节点出现故障时进行通知和响应。

        任务控制器(Job Controller)：监测代表一次性任务的Job 对象，然后创建 Pods 来运行这些任务直至完成。

        端点分片控制器(EndpointSlice controller)：填充端点分片(EndpointSLice)对象(以提供 Service 和 Pod 之间的链接)。

        服务账号控制器(ServiceAccount controller)：为新的命名空间创建默认的服务账号(ServiceAccount)

(五)：cloud-controller-manager

        一个Kubernetes控制平面组件，嵌入了特定云平台的控制逻辑。云控制器管理器(Cloud Controller Manager)允许你将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。

        cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不需要有云控制器管理器。与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中， 供你以同一进程的方式运行。 你可以对其执行水平扩容(运行不止一个副本)以提升性能或者增强容错能力。

         下面的控制器都包含对云平台驱动的依赖:
        节点控制器(Node Controller):用于在节点终止响应后检查云提供商以确定节点是否已被删除。

        路由控制器(RouteController):用于在底层云基础架构中设置路由

        服务控制器(Service Controller):用于创建、更新和删除云提供商负载均衡器

        如果咱们使用云平台的话，一般云平台中都直接选用现成的k8s集群使用。这个目前研究太深意义不大。