目录
1.1 控制平面组件（Control Plane Components）
云控制器管理器-(cloud-controller-manager)
上一篇介绍了使用kubeadm安装k8s，简单给出了k8s的组件图，现在本篇给组件做一下简单的介绍。
根据k8s官网文档解释
Kubernetes （k8s）是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。
我们知道docker本质其实就是进程，一个“容器”，实际上是一个由 Linux Namespace、Linux Cgroups 和 rootfs 三种技术构建出来的进程的隔离环境。
Namespace 做隔离，Cgroups 做限制，rootfs 做文件系统
一个正在运行的 Linux 容器，其实可以被“一分为二”地看待：
一组联合挂载在 /var/lib/docker/aufs/mnt 上的 rootfs，这一部分我们称为“容器镜像”（Container Image），是容器的静态视图；
一个由 Namespace+Cgroups 构成的隔离环境，这一部分我们称为“容器运行时”（Container Runtime），是容器的动态视图。
更进一步地说，作为一名开发者，我并不关心容器运行时的差异。因为，在整个“开发 - 测试 - 发布”的流程中，真正承载着容器信息进行传递的，是容器镜像，而不是容器运行时。
那k8s的本质呢，它的本质就是一个容器编排工具。
“编排”（Orchestration）在云计算行业里不算是新词汇，它主要是指用户如何通过某些工具或者配置来完成一组虚拟机以及关联资源的定义、配置、创建、删除等工作，然后由云计算平台按照这些指定的逻辑来完成的过程。
容器时代，“编排”显然就是对 Docker 容器的一系列定义、配置和创建动作的管理。
根据k8s官网的 Kubernetes 组件 中的图，如下介绍
可以分为
控制平面组件（Control Plane Components） 组件，如果从构架上可以理解为master控制节点
node组件：可以理解为计算节点
这些概念的东西官网有，还是中文的，自己看就行了，为了防止页面消失，我还是粘到附录中吧，也不会影响。
Kubernetes 项目的架构，都由 Master 和 Node 两种节点组成，而这两种角色分别对应着控制节点和计算节点。
控制节点，即 Master 节点，由三个紧密协作的独立组件组合而成，它们分别是负责 API 服务的 kube-apiserver、负责调度的 kube-scheduler，以及负责容器编排的 kube-controller-manager。整个集群的持久化数据，则由 kube-apiserver 处理后保存在 Etcd 中。
而计算节点上最核心的部分，则是一个叫作 kubelet 的组件。
这里主要是介绍一个node节点中的CNI、CRI、CSI、OCI等
kubelet 的一个重要功能，则是调用网络插件和存储插件为容器配置网络和持久化存储。这两个插件与 kubelet 进行交互的接口，分别是 CNI（Container Networking Interface）容器网络接口和 CSI（Container Storage Interface）容器存储接口。
实际上，kubelet 这个奇怪的名字，来自于 Borg 项目里的同源组件 Borglet。不过，如果你浏览过 Borg 论文的话，就会发现，这个命名方式可能是 kubelet 组件与 Borglet 组件的唯一相似之处。
在 Kubernetes 项目中，kubelet 主要负责同容器运行时（比如 Docker 项目）打交道。而这个交互所依赖的，是一个称作 CRI（Container Runtime Interface）的远程调用接口，这个接口定义了容器运行时的各项核心操作，比如：启动一个容器需要的所有参数。
PS：
归根结底，Kubernetes Node（kubelet）的主要功能就是启动和停止容器的组件，我们称之为容器运行时（Container Runtime），其中最知名的就是Docker了。为了更具扩展性，Kubernetes从1.5版本开始就加入了容器运行时插件API，即Container Runtime Interface，简称CRI。
这也是为何，Kubernetes 项目并不关心你部署的是什么容器运行时、使用的什么技术实现，只要你的这个容器运行时能够运行标准的容器镜像，它就可以通过实现 CRI 接入到 Kubernetes 项目当中。
而具体的容器运行时，比如 Docker 项目，则一般通过 OCI （Open Container Initiative，开放容器标准）这个容器运行时规范同底层的 Linux 操作系统进行交互，即：把 CRI 请求翻译成对 Linux 操作系统的调用（操作 Linux Namespace 和 Cgroups 等）。
此外，kubelet 还通过 gRPC 协议同一个叫作 Device Plugin 的插件进行交互。这个插件，是 Kubernetes 项目用来管理 GPU 等宿主机物理设备的主要组件，也是基于 Kubernetes 项目进行机器学习训练、高性能作业支持等工作必须关注的功能。
PS：
Linux基金会于2015年6月成立OCI（Open Container Initiative）组织，旨在围绕容器格式和运行时制定一个开放的工业化标准，目前主要有两个标准文档：容器运行时标准 （runtime spec）和 容器镜像标准（image spec）
制定容器格式标准的宗旨概括来说就是不受上层结构的绑定，如特定的客户端、编排栈等，同时也不受特定的供应商或项目的绑定，即不限于某种特定操作系统、硬件、CPU架构、公有云等。
这两个协议通过 OCI runtime filesytem bundle 的标准格式连接在一起，OCI 镜像可以通过工具转换成 bundle，然后 OCI 容器引擎能够识别这个 bundle 来运行容器
Kubernetes使用封装来编码Protobuf响应。 该包装器以4字节magic number开始，以帮助识别磁盘或etcd中的内容为Protobuf（而不是JSON），然后是Protobuf编码的包装器消息，它描述了底层对象的编码和类型，然后是包含的对象。
默认情况下，Kubernetes将序列化为JSON的对象返回给内容类型为application/json的对象。 这是API的默认序列化格式。 但是，客户可以请求更高效的Protobuf表示这些对象，以获得更好的大规模性能。 Kubernetes API实现了标准HTTP内容类型协商：传递带有Accept头的GET调用将请求服务器返回提供的内容类型中的对象，而进行PUT或POST调用时将Protobuf中的对象发送到服务器将获取Content-Type header。 如果支持所请求的格式，服务器将返回Content-Type header。如果提供了无效的Content Type，则返回406不可接受的错误。
有关每个API支持的内容类型的列表，请参阅API文档。
控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的 replicas 字段时，启动新的 pod）。
控制平面组件可以在集群中的任何节点上运行。然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件，并且不会在此计算机上运行用户容器。请参阅构建高可用性集群中对于多主机 VM 的设置示例。
主节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端。
kube-apiserver 在设计上考虑了水平扩缩的需要。 换言之，通过部署多个实例可以实现扩缩。 参见构造高可用集群。
etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。
您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。要了解 etcd 更深层次的信息，请参考 etcd 文档。
主节点上的组件，该组件监视那些新创建的未指定运行节点的 Pod，并选择节点让 Pod 在上面运行。
调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。
在主节点上运行控制器的组件。
从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。
这些控制器包括:
cloud-controller-manager 运行与基础云提供商交互的控制器。cloud-controller-manager 二进制文件是 Kubernetes 1.6 版本中引入的 alpha 功能。
cloud-controller-manager 仅运行云提供商特定的控制器循环。您必须在 kube-controller-manager 中禁用这些控制器循环，您可以通过在启动 kube-controller-manager 时将 --cloud-provider 参数设置为 external 来禁用控制器循环。
cloud-controller-manager 允许云供应商的代码和 Kubernetes 代码彼此独立地发展。在以前的版本中，核心的 Kubernetes 代码依赖于特定云提供商的代码来实现功能。在将来的版本中，云供应商专有的代码应由云供应商自己维护，并与运行 Kubernetes 的云控制器管理器相关联。
以下控制器具有云提供商依赖性:
节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。
一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。
kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。
kube-proxy 是集群中每个节点上运行的网络代理,实现 Kubernetes Service 概念的一部分。
kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果操作系统提供了数据包过滤层并可用的话，kube-proxy会通过它来实现网络规则。否则，kube-proxy 仅转发流量本身。
容器运行环境是负责运行容器的软件。
Kubernetes 支持多个容器运行环境: 、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI (容器运行环境接口)。
插件使用 Kubernetes 资源 (DaemonSet, Deployment等) 实现集群功能。因为这些提供集群级别的功能，所以插件的命名空间资源属于 kube-system 命名空间。
所选的插件如下所述：有关可用插件的扩展列表，请参见插件 (Addons)。
尽管并非严格要求其他附加组件，但所有示例都依赖集群 DNS，因此所有 Kubernetes 集群都应具有 DNS。
除了您环境中的其他 DNS 服务器之外，集群 DNS 还是一个 DNS 服务器，它为 Kubernetes 服务提供 DNS 记录。
Cluster DNS 是一个 DNS 服务器，和您部署环境中的其他 DNS 服务器一起工作，为 Kubernetes 服务提供DNS记录。
Kubernetes 启动的容器自动将 DNS 服务器包含在 DNS 搜索中。
Dashboard 是 Kubernetes 集群的通用基于 Web 的 UI。它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。
容器资源监控将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。
集群层面日志 机制负责将容器的日志数据保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。
本文地址：https://blog.csdn.net/hualinux/article/details/107358580
如对本文有疑问， 点击进行留言回复！！
如何在Ubuntu 18.04（实体机）上配置OpenWRT的开发环境
我要评论
网友评论