云原生系列二【Kubernetes】Kubernetes是如何运行的？

一、概述

随着系统可部署组件的数量增长，把它们都管理起来会变得越来越困难。需要一个更好的方式来部署和管理这些组件， 并支持基础设施的全球性伸缩，谷歌可能是第一个意识到这一点的公司。谷歌等全球少数几个公司运行着成千上万的服务器，而且在如此海量规模下，不得不处理部署管理的问题。这推动着他们找出解决方案使成千上万组件的管理变得有效且成本低廉。

初衷

• 这些年来，谷歌开发出了一个叫Borg的内部系统（后来还有一个新 系统叫Omega），应用开发者和系统管理员管理那些数以千计的应用程序和服务都受益于它的帮助。除了简化开发和管理，它也帮助他们获得了更高的基础设施利用率，在你的组织如此庞大时，这很重要。当你运行成千上万台机器时，哪怕一丁点的利用率提升也意味着节约了数百万美元，所以，开发这个系统的动机是显而易见的
  在保守Borg和Omega秘密数十年之后，2014年，谷歌开放了Kubernetes，一个基于Borg、Omega及其他谷歌内部系统实践的开源系统。
• Kubernetes是一个软件系统，它允许你在其上很容易地部署和管理容器化的应用。它依赖于Linux容器的特性来运行异构应用，而无须知道这些应用的内部详情，也不需要手动将这些应用部署到每台机器。因为这些应用运行在容器里，它们不会影响运行在同一台服务器上的其他应用，当你是为完全不同的组织机构运行应用时，这就很关键了。这对于云供应商来说是至关重要的，因为它们在追求高硬件可用率的同时也必须保障所承载应用的完全隔离。Kubernetes使你在数以千计的电脑节点上运行软件时就像所有这些节点是单个大节点一样。它将底层基础设施抽象，这样做同时简化了应用的开发、部署，以及对开发和运维团队的管理
  通过Kubernetes部署应用程序时，你的集群包含多少节点都是一样的。集群规模不会造成什么差异性，额外的集群节点只是代表一些额外的可用来部署应用的资源

Kubernetes的核心功能：

下图展示了一幅最简单的Kubernetes系统图。整个系统由一个主节点和若干个工作节点组成。开发者把一个应用列表提交到主节点， Kubernetes会将它们部署到集群的工作节点。组件被部署在哪个节点对 于开发者和系统管理员来说都不用关心
开发者能指定一些应用必须一起运行，Kubernetes将会在一个工作节点上部署它们。其他的将被分散部署到集群中，但是不管部署在哪 儿，它们都能以相同的方式互相通信。

• 帮助开发者聚焦核心应用功能：Kubernetes可以被当作集群的一个操作系统来看待。它降低了开发者不得不在他们的应用里实现一些和基础设施相关服务的心智负担。他们现在依赖于Kubernetes来提供这些服务，包括服务发现、扩容、负载均衡、自恢复，甚至领导者的选举。应用程序开发者因此能集中精力实现应用本身的功能而不用浪费时间思索怎样集成应用与基础设施。​​​​​
  -帮助运维团队获取更高的资源利用率：Kubernetes将你的容器化应用运行在集群的某个地方，并提供信息给应用组件来发现彼此并保证它们的运行。因为你的应用程序不关心它 运行在哪个节点上，Kubernetes能在任何时间迁移应用并通过混合和匹 配应用来获得比手动调度高很多的资源利用率

二、核心组件

在硬件级别，一个Kubernetes集群由很多节点Node组成，Node是Kubernetes中的工作机器，可以是实体机可以是虚拟机，这些节点被分成以下两种类型：
1、主节点（master Node），它承载着Kubernetes控制和管理整个集群系统的控制面板；

• etcd 保存了整个集群的状态，是一个分布式的，一致的 key-value 存储，主要用途是共享配置和服务发现，保存集群状态数据，比如 Pod、Service 等对象信息；
• apiserver 是集群的统一入口，各组件协调者，以 HTTP Rest 提供接口服务，所有对象资源的增、删、改、查和监听操作都交给 apiserver 处理后再提交给 Etcd 存储；
• controller manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等，是 K8S 里所有资源对象的自动化控制中心，处理集群中常规后台任务，一个资源对应一个控制器，而 controller-manager 就是负责管理这些控制器的；
• scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上，根据调度算法为新创建的 Pod 选择一个 Node 节点，可以任意部署，可以部署在同一个节点上，也可以部署在不同的节点上；

2、工作节点（worker Node），它们运行用户实际部署的应用；

除了 Master，K8S 集群中的其它机器被称为 Node 节点，Node 节点是 K8S 集群中的工作负载节点，每个 Node 都会被 Master 分配一些工作负载，当某个 Node 宕机时，其上的工作负载会被 Master 自动转移到其它节点上去。

• kubelet 负责与api server通信，并维护容器的生命周期，负责 Pod 对应的容器的创建、启停等任务，实现集群管理的基本功能，同时也负责 Volume（CVI）和网络（CNI）的管理。类似Master大王派我来巡山；
• Container runtime 负责镜像管理以及 Pod 和容器的真正运行（CRI）；
• kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡，在 Node 节点上实现 Pod 网络代理，实现 Kubernetes Service 的通信，维护网络规则和四层负载均衡工作。
• docker engine：Docker 引擎，负责本机的容器创建和管理工作。Node 节点可以在运行期间动态增加到 K8S 集群中，前提是这个节点上已经正确安装、配置和启动了上述关键组件。在默认情况下 kubelet 会向 Master 注册自己，一旦 Node 被纳入集群管理范围，kubelet 就会定时向 Master 节点汇报自身的情况，例如操作系统、Docker 版本、机器的 CPU 和内存情况，以及之前有哪些 Pod 在运行等，这样 Master 可以获知每个 Node 的资源使用情况，并实现高效均衡的资源调度策略。而某个 Node 超过指定时间不上报信息时，会被 Master 判定为“失联”，Node 的状态被标记为不可用（Not Ready），随后 Master 会触发“工作负载大转移”的自动流程。