Kubernetes二--Kubernetes设计架构

写在前面：整理一篇blog不易，希望大家珍惜，如果有存在异议及问题，请留言，我会尽快处理！！为了blog内容更适合初级的学员学习，我都尽量整理的详细，尽量的说的直白。一篇blog少则需要1个小时的时间，多则个把小时。编写不易，希望喜欢的童鞋多多点赞和评论，谢谢！~~

有可能整理的内容较为基础，若针对于有基础的童鞋，想了解的更深，可以多看看官网！！！

本章我们来学习Kubernetes设计架构

Kubernetes的总架构图，一切都基于分布式的存储系统。（盗图如下，大家一定要多看图，基于图片去了解要比文字性的解释好的多，至少我是这么认为的！！）


Kubernetes所有节点存在运行应用容器必备的服务，而这些都是受于Master的控制的。每个节点上都有运行Docker容器内容，Docker来负责所有具体的镜像下载和容器运行等功能。

1.Kubernetes核心组件、插件功能简介

认为不太好理解的情况下，可以对照着第一张图进行学习！

1.1核心组件

组件	功能
etcd	保存了整个集群的状态
apiserver	提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
controller manager	负责维护集群的状态，比如故障检测、自动扩展、滚动更新等
scheduler	负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上
kubelet	负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理
Container runtime	负责镜像管理以及Pod和容器的真正运行（CRI）
kube-proxy	负责为Service提供cluster内部的服务发现和负载均衡（功能可以简单理解为类似于nginx的负载均衡作用）

1.2 插件

插件	功能
kube-dns	负责为整个集群提供DNS服务
Ingress Controller	为服务提供外网入口
Heapster	提供资源监控
Dashboard	提供GUI
Federation	提供跨可用区的集群
Fluentd-elasticsearch	提供集群日志采集、存储与查询

2.分层架构理解

Kubernetes设计理念和功能可以类似Linux的分层架构来理解

层级	功能说明
核心层	Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
应用层	用于部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
管理层	系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展缩容、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
接口层	kubectl命令行工具、客户端SDK以及集群级联
生态系统	在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴
Kubernetes外部	包括日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
Kubernetes内部	包括CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

3.各组件详细介绍

3.1 Master组件Master Components

master组件提供群集的控制内容。 master组件做了出关于集群的全局决策（例如调度）以及检测和响应集群事件（当复制控制器的’副本’字段不满足时启动新的pod）。

master组件可以运行在任何的集群的机器上。 但是，为简单起见，设置脚本通常会在同一台计算机上启动所有主组件，并且不在此计算机上运行用户容器（也就是我们实际应用中说的业务和实际服务分离！）。

3.1.1 kube-apiserver

Kubernetes AP是属于master上的组件。 它是Kubernetes控制面内容的前端。它旨在水平扩展内容，也就是说，通过部署更多实例来扩展应用，更进一步构建高可用性群集。

3.1.2 etcd

一致且高可用的键值存储，用作Kubernetes的所有群集数据的后备存储,并且可以很好地存储配置数据。始终为Kubernetes集群提供etcd数据的备份计划。因为有watch(观察者)的支持，各部件协调中的改变可以很快被察觉。

3.1.3 kube-scheduler

主服务器上的组件，用于监视未创建节点和新创建的pod，并选择一个节点供其运行。调度器把未调度的pod通过binding api绑定到节点上。调度器是可以进行插拔的。调度决策所考虑的因素包括单机和集群环境的资源需求，硬件/软件/策略约束，亲和力和反亲和性规范，数据位置，工作负载间干扰和最后期限等内容。

3.1.4 kube-controller-manager

运行控制器的主服务器上的组件。

从逻辑上讲，每个控制器都是一个单独的过程，但为了降低复杂性，它们都被编译成单个二进制文件并在单个进程中运行。

这些控制器包括：

控制器	作用
节点控制器	负责在节点出现故障时反馈和响应
复制控制器	负责为系统中的每个复制控制器对象维护正确数量的pod内容
端点控制器	填充端点对象（即连接服务和窗格）
服务帐户和令牌控制器	为新的命名空间创建默认帐户和API访问令牌

3.1.5 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时链接到云控制器管理器。

以下控制器具有云提供程序依赖项：

依赖项	作用
节点控制器	用于检查云提供商，以确定节点在停止响应后是否已在云中删除
路由控制器	用于在底层云基础架构中设置路由
服务控制器	用于创建更新和删除云提供商负载均衡器
卷控制器	用于创建附加和装载卷，以及与云提供商交互以协调卷

3.2.节点组件Node Components

节点组件可以在每一个节点上运行，维护正在运行的pod并提供Kubernetes运行环境。

3.2.1 kubelet

kubelet负责管理pods和它们上面的容器，images镜像、volumes、etc等。他是在群集中的每个节点上运行的代理，确保容器在pod中运行。kubelet采用通过各种机制提供的一组PodSpecs，并确保那些PodSpecs中描述的容器运行且健康。注意： kubelet不管理不是由Kubernetes创建的容器。

3.2.2 kube-proxy

每一个节点也运行一个简单的网络代理和负载均衡（作用可以简单理解为和nginx类似 )。 正如Kubernetes API里面定义的这些服务也可以在各种终端中以轮询的方式做一些简单的TCP和UDP传输。

3.2.3 Container Runtime

容器运行时态是负责运行容器的软件。 Kubernetes支持多个运行机制内容：Docker，containerd，cri-o，rktlet以及Kubernetes CRI（容器运行时接口）的任何实现。

4.插件（Addons）

插件是实现集群功能的pod和服务。 可以通过Deployments，ReplicationControllers等管理pod。 命名空间的插件对象在kube-system命名空间中创建。

选定的插件如下所述，有关可用插件的扩展列表：

插件	作用
DNS	虽然其他插件并非进行严格的要求，但所有Kubernetes集群都应具有集群DNS，因为许多示例都依赖于它。群集DNS是DNS服务器，除了您环境中的其他DNS服务器之外，它还为Kubernetes服务提供DNS记录。Kubernetes启动的容器会在DNS搜索中自动包含此DNS服务器。
Web UI（仪表板）	仪表板是Kubernetes集群的基于Web的通用UI。 它允许用户管理和解决群集中运行的应用程序以及群集本身。
容器资源监测	容器资源监视记录有关中央数据库中容器的通用时间序列度量，并提供用于浏览该数据的UI。
群集级日志记录	集群级日志记录机制负责将容器日志保存到具有搜索/浏览界面的日志存储中心进行存储。

5.kube-master的工作流程图

在盗一张图V-V

欢迎喜欢实施运维及数据的小伙伴加入群进行谈论！
运维技术群：263859509