一、名字来源

Kubernetes 这个名字，起源于古希腊，是舵手的意思，它的 logo 即像一张渔网又像一个罗盘，谷歌选择这个名字还有一个深意：既然docker把自己比作一只鲸鱼船，驮着集装箱，在大海上遨游，google 就要用Kubernetes去掌握大航海时代的话语权，去捕获和指引着这条鲸鱼按照主人设定的路线去巡游。

二、核心设计

得益于 docker 的特性，服务的创建和销毁变得非常快速、简单。Kubernetes 正是以此为基础，实现了集群规模的管理、编排方案，使应用的发布、重启、扩缩容能够自动化。其核心设计主要概况为如下三点：

编排抽象：容器平台核心点不在于创建和调度容器，而是在上层架构抽象出各种对象，便于去统一管理。Kubernetes创造性的抽象出了各个编排的关系，例如亲密关系(Pod对象)、访问关系（Service对象）等。

声明式API：声明式API是整个系统自动化的核心要点，kubernetes提供了以声明式API的方式将抽象对外暴露，同时也便于了用户管理对象。

开放插件：支持系统资源插件化（比如计算、存储、网络）；同时也支持用户自定义CRD和开发Operator。

三、架构与组件

K8s整体架构：整个系统由控制面(Master)与数据面(Worker Node)组成。如下图：

1.Master核心组件

k8s集群控制节点，对集群进行调度管理，接受集群外用户去集群操作请求； Master Node 由 API Server、Controller MangerServer 、Scheduler和ClusterState Store（ETCD 数据库）所组成。

1. API Server：集群控制的唯一入口，它是各个组件之间数据交行通信的中心枢纽。其他模块通过API Server查询或修改数据，只有API Server才直接和etcd进行交互。Kubernetes 集群中，API Server 扮演着通信枢纽的位置。API Server 不仅负责和 etcd 交互（其他组件不会直接操作 etcd），并切对外提供统一的API调用入口, 所有的交互都是以 API Server 为核心的。
   API Server 提供了以下的功能：
   1）整个集群管理的 API 接口：所有对集群进行的查询和管理都要通过 API 来进行。集群内部的组件(如kubelet)也是通过Apiserver更新和同步数据到etcd中。
   2）集群内部各个模块之间通信的枢纽：所有模块之前并不会之间互相调用，而是通过和 API Server 打交道来完成自己那部分的工作。
   3）集群安全控制：API Server 提供的验证和授权保证了整个集群的安全。
   4）数据中心枢纽: API Server 负责和 Etcd 交互存放集群用到的运行数据。

2. controller-mananger：负责编排，用于调节系统状态。内置了多种控制器（DeploymentController、- ServiceController、NodeController、HPAController等）是Kubernetes维护业务和集群状态的最核心组件。
   controller-manager 作为 k8s 集群的管理控制中心，负责集群内 Node、Namespace、Service、Token、Replication 等资源对象的管理，使集群内的资源对象维持在预期的工作状态。
   每一个 controller 通过 api-server 提供的 restful 接口实时监控集群内每个资源对象的状态，当发生故障，导致资源对象的工作状态发生变化，就进行干预，尝试将资源对象从当前状态恢复为预期的工作状态，常见的 controller 有 Namespace Controller、Node Controller、Service Controller、ServiceAccount Controller、Token Controller、ResourceQuote Controller、Replication Controller等。

3. scheduler：集群的调度器，它负责在Kubernetes集群中为Pod资源对象找到合适节点并使其在该节点上运行。
   负责节点资源管理，接收来自kube-apiserver创建Pods的任务，收到任务后它会检索出所有符合该Pod要求的Node节点（通过预选策略和优选策略），开始执行Pod调度逻辑。调度成功后将Pod绑定到目标节点上。
   

4. etcd：用于存储Kubernetes集群的数据与状态信息。
   Kubernetes中没有用到数据库，它把关键数据都存放在etcd中，这使kubernetes的整体结构变得非常简单。在kubernetes中，数据是随时发生变化的，比如说用户提交了新任务、增加了新的Node、Node宕机了、容器死掉了等等，都会触发状态数据的变更。状态数据变更之后呢，Master上的kube-scheduler和kube-controller-manager，就会重新安排工作，它们的工作安排结果也是数据。这些变化，都需要及时地通知给每一个组件。etcd有一个特别好用的特性，可以调用它的api监听其中的数据，一旦数据发生变化了，就会收到通知。有了这个特性之后，kubernetes中的每个组件只需要监听etcd中数据，就可以知道自己应该做什么。kube-scheduler和kube-controller-manager呢，也只需要把最新的工作安排写入到etcd中就可以了，不用自己费心去逐个通知了。

Kubernetes架构具备高可用：一方面Master节点高可用；另一方面所部署的业务也是高可用的。系统高可用的核心在于冗余部署，当某一个节点或程序出现异常时，其他节点或程序能分担或替换工作。Master节点高可用，主要由以下几个方面的设计实现：

• Master由多台服务器构成。
• API Server多实例同时工作，负载均衡。
• etcd多节点，一主多从。
• controller-manager与scheduler抢主实现。

2.Work Node节点组件

集群工作节点，运行用户业务应用容器。Nodes节点也叫Worker Node，包含kubelet、kube proxy 和 Pod（Container Runtime）。

• kubelet：负责Pod对应容器的创建、启停等任务，是部署在Node上的一个agent。运行在每个计算节点上：
  1）kubelet 组件通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件，然后从 etcd 获取 pod 清单，下载镜像并启动容器。
  2）同时监视分配给该Node节点的 pods，周期性获取容器状态，再通过api-server通知各个组件。
  3）镜像和容器的清理工作，保证节点上镜像不回占满磁盘，退出的容器不会占用太多资源。
• kube-proxy：实现Service通信与负载均衡机制。
  首先k8s 里所有资源都存在 etcd 中，各个组件通过 apiserver 的接口进行访问etcd来获取资源信息，kube-proxy 会作为 daemon（守护进程） 跑在每个节点上通过watch的方式监控着etcd中关于Pod的最新状态信息,它一旦检查到一个Pod资源被删除了或新建或ip变化了等一系列变动，它就立即将这些变动，反应在iptables 或 ipvs规则中，以便之后再有请求发到service时，service可以通过ipvs最新的规则将请求的分发到pod上。
• Pod(Container Runtime) ：负责本机的容器创建和管理。
  Pod是Kubernetes最基本的操作单元。一个Pod代表着集群中运行的一个进程，它内部封装了一个或多个紧密相关的容器。

本期简单给大家介绍了k8s架构及组件的基础概念。🍒如果您觉得博主的文章还不错或者有帮助的话，请关注一下博主，如果三连点赞评论收藏就更好啦！谢谢各位大佬给予的支持！