罗永浩|图文并茂！带你深度解析Kubernetes( 五 )

成熟的技术前身

优秀的框架架构

良好的核心设计

（一）Kubernetes前身Kubernetes的基础特性，并不是几个工程师突然“拍脑袋”想出来的东西，而是 Google 公司在容器化基础设施领域多年来实践经验的沉淀与升华。这个实践与升华的过程，就是Kubernetes的前身是Borg系统。
Borg系统一直以来都被誉为Google内部最强大的“秘密武器” ，是Google整个基础设施的核心依赖。很多应用框架已经运行在Borg上多年，其中包括了内部的MapReduce、GFS、BigTable、Megastore等，上层应用程序更是有这些耳熟能详的产品：Gmail、Google Docs、Google Search等。
其架构图如下所示：

架构分析：

集群分为Master节点与Worker节点。

Master节点由多台机器构成，一主多备。

BorgMaster由主进程和scheduler进程组成，主进程处理clientRpc请求， scheduler负责调度tasks 。

Borglet是Worker节点上的代理进程，用于启停tasks 。

根据2015年4月google发布的Large-scale clustermanagement at Google with Borg ，与其2020年7月发布的Borg: the nextgeneration ，两篇论文中的数据表明：Borg系统通过对在线任务与离线任务进行混合部署，可以节约20%-30%的资源，极大提高了资源利用率。下表是2011年与2019年的Borg集群，与2015年AWS、Facebool、Twitter数据中心资源利用率的对比图。

对于成熟高效的Borg系统，继承者Kubernetes从中获得了宝贵的经验：

Pods 。 Pod是Kubernetes中调度的单位。它是一个或多个容器在其中运行的资源封装。保证属于同一 Pod的容器可以一起调度到同一台计算机上，并且可以通过本地卷共享状态。 Borg有一个类似的抽象，称为alloc（“资源分配”的缩写）。

Service 。 Kubernetes使用服务抽象支持命名和负载均衡：带名字的服务，会映射到由标签选择器定义的一组动态Pod集。集群中的任何容器都可以使用服务名访问服务。

Labels 。通过使用标签组织Pod ， Kubernetes比Borg支持更灵活的集合，标签是用户附加到Pod（实际上是系统中的任何对象）的任意键值对。

Ip-per-Pod 。 Borg容器只能共享主机网络，必须将端口作为调度的资源。在Kubernetes中IP是以Pod为单位分配的，一个Pod内部的所有容器共享一个网络堆栈。

（二）Kubernetes架构

整体架构

Kubernets整体架构，如下所示：

整个系统由控制面(Master)与数据面(Worker Node)组成。 Master核心组件：

API Server 。集群控制的唯一入口，它是各个组件通信的中心枢纽。

controller-mananger 。负责编排，用于调节系统状态。内置了多种控制器（DeploymentController、- ServiceController、NodeController、HPAController等）是Kubernetes维护业务和集群状态的最核心组件。

scheduler 。集群的调度器，它负责在Kubernetes集群中为Pod资源对象找到合适节点并使其在该节点上运行。

etcd 。用于存储Kubernetes集群的数据与状态信息。
- 上一页
- 1
- 2
- 3
- 4
- 5
- 6
- 下一页