没有太多的花朵，直接学习K8S架构和组件学习。
K8S系统旨在遵循C-S体系结构，即图中图中的Apiserver之间的相互作用。通常在生产中有多个大师来实现高可用的K8S系统服务。K8S群集至少有一个工作节点，即一个工作节点，以及由K8在节点上管理的容器化应用程序。
主通常包括Kube-aperver，ETCD存储，Kube-Controller-Manager，Cloud-Controller-Manager，Kube-Scheduler和DNS服务器（插件）K8S服务。集群（例如调度）以及检测和响应集群事件的组件集合也称为控制平面。
实际上，K8S官员并不是这么说，但是大多数安装工具（Kubeadm）或脚本将在机器上的控制平面上安装组件，即主机，并且不会在此上运行用户容器这台机器上的机器不是强制性的，因此您还可以实施控制平面的分布式部署，但是在这种情况下，高可用性将是一个巨大的挑战。
该组件包括运行时（运行时）时使用POD的Kubelet，Kube-Porxy和容器。外部存储和注册表用于为容器提供存储和镜像仓库服务。
从kubectl开始，让我们看一下K8的基本工作流程：
Kube-Abiserverapi服务器提供了K8S群集资源操作的唯一入口，并提供认证，授权，访问控制，API注册和发现机制。
Kubernetes API服务器的主要实现是Kube-aperver.kube-aperver的设计考虑水平扩展，也就是说，它可以通过部署多个实例来扩展。
ETCDETCD是具有一致性和高可用性的钥匙值数据库。它可以用作背景数据库（例如数量，状态，名称空间等），该数据库可保存kubernetes，api对象和服务发现细节的所有群集数据。出于安全原因，只能从API服务器访问它。
ETCD也是K8S Ecology.for etcd的关键应用程序，请参阅ETCD文档。
Kube-Schedulkube-Scheduler负责监视新创建和未指定节点的新吊舱，并决定制作一个允许POD运行的节点。
例如，如果应用程序需要1GB内存和2个CPU内核，则该应用程序的POD将至少在具有这些资源的节点上安排。每个时间您需要安排POD，调度程序运行。调度计划必须知道总计可用的资源并将资源分配给每个节点上的现有工作负载。
考虑计划决策的因素包括资源需求，硬件/软件/策略约束，亲和力和反亲和力规范，数据位置，工作负载干扰以及单个POD和POD收集的资源需求的最终时间限制。
Kube-Controller-Managerk8S在后台运行许多不同的控制过程。当服务配置更改（例如，替换镜像运行pod或更改配置YAML文件中的参数）时，控制器将发现变化并朝向新的新的新的朝向新的。预期的状态工作。
从逻辑上讲，每个控制器都是一个单独的过程，但是为了降低复杂性，它们被编译为同一可执行文件并在过程中运行。
控制器包括：
Cloud-Controller-Manager云控制器管理器使您可以将群集连接到云提供商的API，同时，您可以将云平台交互组件与本地群集中的组件分开。
仅在云平台上运行控制电路。如果我们在自己的环境中运行kubernetes，大多数情况下，该组件中未使用非混合云环境。
同样，将几个逻辑独立控制电路组合到同一可执行文件中，以便您在同一过程中运行。您可以扩大执行级别（多个副本），以提高性能或增强故障 - 耐耐耐受功能。
以下控制器包含对云平台驱动器的依赖性：
节点组件在每个节点上运行，维护和运行POD并提供Kubernetes操作环境。
kubelet是在群集中的每个节点上运行的代理。它保证容器在pod.kubelet中运行。kubelet定期收到新的或修改的pod规范podspecs（主要是通过kube-aperver），并确保吊舱和容器的健康状况并运行并运行所需状态。该组件还报告给了Kube-aperver运行其主机的健康状况。
Kubelet不管理Kubernetes创建的容器。
Kube-proxykube-Proxy是群集中每个节点上运行的网络代理的一部分，该网络代理实现了Kubernetes Service（Service）Service概念的一部分。它用于处理单个主机子网并公开为外界服务。集群中的各种隔离网络将将请求转发到正确的POD/容器。
Kube-Proxy维护节点上的网络规则。这些网络规则允许网络通信和吊舱从群集内部或外部进行。
如果操作系统提供了数据包滤波器层并且可用，则Kube-Proxy将通过它实现网络规则。否则，Kube-Proxy仅将流量本身转发。
容器运行时负责在运行时创建容器操作环境。
Kubernetes在运行时支持多个容器：Docker（将被放弃），容器，CRI-O和运行时，即Kubernetes CRI的任何实现（容器运行环境接口）。
作者：qsing.github.io