Kubernetes（K8s）入门

一、Kubernetes是什么

Kubernetes是什么?

        首先，它是一个全新的基于容器技术的分布式架构领先方案。这个方案虽然还很新，但它是谷歌十几年以来大规模应用容器技术的经验积累和升华的一个重要成果。确切地说，Kubernetes是谷歌严格保密十几年的秘密武器——Borg 的一个开源版本。Borg是谷歌的一个久负盛名的内部使用的大规模集群管理系统，它基于容器技术，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率的最大化。十几年来，谷歌一直通过Borg系统管理着数量庞大的应用程序集群。由于谷歌员工都签署了保密协议，即便离职也不能泄露Borg的内部设计，所以外界一直无法了解关于它的更多信息。直到2015 年4月，传闻许久的Borg 论文伴随Kubernetes的高调宣传被谷歌首次公开，大家才得以了解它的更多内幕。正是由于站在Borg这个前辈的肩膀上，吸取了Borg过去十年间的经验与教训，所以Kubermetes 一经开源就一鸣惊人，并迅速称霸了容器技术领域。

        其次，如果我们的系统设计遵循了Kubermetes的设计思想，那么传统系统架构中那些和业务没有多大关系的底层代码或功能模块，都可以立刻从我们的视线中消失，我们不必再费心于负载均衡器的选型和部署实施问题，不必再考虑引入或自己开发一个复杂的服务治理框架，不必再头疼于服务监控和故障处理模块的开发。总之，使用Kubernetes 提供的解决方案，我们不仅节省了不少于30%的开发成本，同时可以将精力更加集中于业务本身，而且由于Kubernetes提供了强大的自动化机制，所以系统后期的运维难度和运维成本大幅度降低。

        然后，Kubernetes 是-一个 开放的开发平台。与J2EE不同，它不局限于任何一种语言，没有限定任何编程接口，所以不论是用Java、Go、C++还是用Python编写的服务，都可以毫无困难地映射为Kubernetes 的Service，并通过标准的TCP通信协议进行交互。此外，由于Kubernetes平台对现有的编程语言、编程框架、中间件没有任何侵入性，因此现有的系统也很容易改造升级并迁移到Kubernetes平台上。

        最后，Kubernetes是一个完备的分布式系统支撑平台。Kubermetes具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。同时，Kubernetes 提供了完善的管理工具，这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。因此，Kubernetes是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台。

        我们首先要学习Kubernetes 的一些基本知识， 这样我们才能理解Kubernetes提供的解决方案。

        在Kubernetes中，Service (服务)是分布式集群架构的核心，一个Service对象拥有如下关键特征。

• 拥有一个唯一指定的名字(比如mysql-server)。
• 拥有一个虚拟IP (Cluster IP、 Service IP或VIP)和端口号。
• 能够提供某种远程服务能力。
• 被映射到了提供这种服务能力的一组容器应用上。

        Service的服务进程目前都基于Socket通信方式对外提供服务，比如Redis、 Memcache、MySQL、Web Server，或者是实现了某个具体业务的一个特定的TCP Server 进程。虽然一个Service通常由多个相关的服务进程来提供服务，每个服务进程都有一个独立的Endpoint(IP+Port)访问点，但Kubernetes能够让我们通过Service (虚拟Cluster IP +Service Port)连接到指定的Service上。有了Kubernetes 内建的透明负载均衡和故障恢复机制,不管后端有多少服务进程，也不管某个服务进程是否会由于发生故障而重新部署到其他机器，都不会影响到我们对服务的正常调用。更重要的是这个Service本身一旦创建就不再变化,这意味着，在Kubernetes集群中，我们再也不用为了服务的IP地址变来变去的问题而头疼了。

        容器提供了强大的隔离功能，所以有必要把为Service提供服务的这组进程放入容器中进行隔离。为此，Kubernetes设计了Pod 对象，将每个服务进程包装到相应的Pod中，使其成为Pod中运行的一个容器(Container)。 为了建立Service和Pod间的关联关系，Kubernetes 首先给每个Pod贴上一个标签(Label),给运行MySQL的Pod贴上name=mysql 标签，给运行PHP的Pod贴上name=php标签，然后给相应的Service 定义标签选择器(Label Selector)，比如MySQLService的标签选择器的选择条件为name--mysql,意为该Service要作用于所有包含name=mysqlLabel的Pod上。这样一来，就巧妙地解决了Service 与Pod的关联问题。

        说到Pod，我们这里先简单介绍其概念。首先，Pod 运行在一个我们称之为节点(Node)的环境中，这个节点既可以是物理机，也可以是私有云或者公有云中的一个虚拟机，通常在一个节点上运行几百个Pod;其次，每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此它们之间的通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中:最后，需要注意的是，并不是每个Pod和它里面运行的容器都能“映射”到一个Service.上，只有那些提供服务(无论是对内还是对外)的一组Pod才会被“映射”成一个服务。

        在集群管理方面, Kubernetes将集群中的机器划分为一个Master节点和一群工作节点(Node)。其中，在Master节点上运行着集群管理相关的一组进程kube-apiserver. kube-controller-manager和kube scheduler,这些进程实现了整个集群的资源管理、Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且都是全自动完成的。Node 作为集群中的工作节点,运行真正的应用程序，在Node.上Kubernetes 管理的最小运行单元是Pod。 Node. 上运行着Kubernetes 的kubelet、kube-proxy 服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁，以及实现软件模式的负载均衡器。

        最后，我们再来看看传统的IT 系统中服务扩容和服务升级这两个难题，以及Kubernetes所提供的全新解决思路。服务的扩容涉及资源分配(选择哪个节点进行扩容)、实例部署和启动等环节，在一个复杂的业务系统中，这两个问题基本上靠人工一步步操作才得以完成，费时费力又难以保证实施质量。

        在Kubernetes集群中，你只需为需要扩容的Service 关联的Pod创建-一个ReplicationController (简称RC)，则该Service的扩容以至于后来的Service升级等头疼问题都迎刃而解。在一个RC定义文件中包括以下3个关键信息。

• 目标Pod的定义。
• 目标Pod需要运行的副本数量(Replicas)。
• 要监控的目 标Pod的标签(Label)。

        在创建好RC (系统将自动创建好Pod)后，Kubernetes 会通过RC中定义的Label 筛选出对应的Pod实例并实时监控其状态和数量，如果实例数量少于定义的副本数量(Replicas), 则会根据RC中定义的Pod模板来创建一个新的Pod,然后将此Pod调度到合适的Node.上启动运行，直到Pod实例的数量达到预定目标。这个过程完全是自动化的，无须人工千预。有了RC，服务的扩容就变成了一个纯粹的简单数字游戏了，只要修改RC中的副本数量即可。后续的Service升级也将通过修改RC来自动完成。

二、为什么要用Kubernetes

        使用Kubernetes的理由很多，最根本的一一个理由就是: IT 从来都是一个由新技术驱动的行业。Docker这个新兴的容器化技术当前已经被很多公司所采用,其从单机走向集群已成为必然，而云计算的蓬勃发展正在加速这一-进程。 Kubernetes 作为当前唯一被 业界广泛认可和看好的Docker分布式系统解决方案，可以预见，在未来几年内，会有大量的新系统选择它，不管这些系统是运行在企业本地服务器上还是被托管到公有云上。

        使用了Kubernetes 又会收获哪些好处呢?

        首先，最直接的感受就是我们可以“轻装上阵”地开发复杂系统了。以前动不动就需要十几个人而且团队里需要不少技术达人一起分工协作才能设计实现和运维的分布式系统，在采用Kubernetes解决方案之后，只需一个精悍的小团队就能轻松应对。在这个团队里，一名架构师专注于系统中“服务组件”的提炼，几名开发工程师专注于业务代码的开发，一名系统兼运维工程师负责Kubermnetes的部署和运维，从此再也不用“996”了,这并不是因为我们少做了什么，.而是因为Kubernetes已经帮我们做了很多。

        其次，使用Kubernetes就是在全面拥抱微服务架构。微服务架构的核心是将一个巨大的单体应用分解为很多小的互相连接的微服务，一个微服务背后可能有多个实例副本在支撑，副本的数量可能会随着系统的负荷变化而进行调整，内嵌的负载均衡器在这里发挥了重要作用。微服务架构使得每个服务都可以由专门的开发团队来开发，开发者可以自由选择开发技术，这对于大规模团队来说很有价值，另外每个微服务独立开发、升级、扩展，因此系统具备很高的稳定性和快速迭代进化能力。谷歌、亚马逊、eBay、NetFlix 等众多大型互联网公司都采用了微服务架构，此次谷歌更是将微服务架构的基础设施直接打包到Kubernetes解决方案中，让我们有机会直接应用微服务架构解决复杂业务系统的架构问题。

        然后，我们的系统可以随时随地整体“搬迁”到公有云上。Kubernetes 最初的目标就是运行在谷歌自家的公有云GCE中，未来会支持更多的公有云及基于OpenStack的私有云。同时，在Kubernetes的架构方案中，底层网络的细节完全被屏蔽,基于服务的Cluster IP甚至都无须我们改变运行期的配置文件，就能将系统从物理机环境中无缝迁移到公有云中，或者在服务高峰期将部分服务对应的Pod副本放入公有云中以提升系统的吞吐量,不仅节省了公司的硬件投入，还大大改善了客户体验。我们所熟知的铁道部的12306 购票系统，在春节高峰期就租用了阿里云进行分流。

        最后，Kubernetes 系统架构具备了超强的横向扩容能力。对于互联网公司来说，用户规模就等价于资产，谁拥有更多的用户，谁就能在竞争中胜出，因此超强的横向扩容能力是互联网业务系统的关键指标之一。不用修改代码，一个Kubernetes 集群即可从只包含几个Node的小集群平滑扩展到拥有上百个Node的大规模集群，我们利用Kubernetes提供的工具，甚至可以在线完成集群扩容。只要我们的微服务设计得好，结合硬件或者公有云资源的线性增加，系统就能够承受大量用户并发访问所带来的巨大压力。

三、Kubernetes架构图

        Kubernetes系统用于管理分布式节点集群中的微服务或容器化应用程序，并且其提供了零停机时间部署、自动回滚、缩放和容器的自愈（其中包括自动配置、自动重启、自动复制的高弹性基础设施，以及容器的自动缩放等）等功能。

        Kubernetes系统最重要的设计因素之一是能够横向扩展，即调整应用程序的副本数以提高可用性。设计一套大型系统，且保证其运行时健壮、可扩展、可移植和非常具有挑战性，尤其是在系统复杂度增加时，系统的体系结构会直接影响其运行方式、对环境的依赖程度及相关组件的耦合程度。

        微服务是一种软件设计模式，适用于集群上的可扩展部署。开发人员使用这一模式能够创建小型、可组合的应用程序，通过定义良好的HTTP REST API接口进行通信。Kubernetes也是遵循微服务架构模式的程序，具有弹性、可观察性和管理功能，可以适应云平台的需求。

        Kubernetes的系统架构设计与Borg的系统架构设计理念非常相似，如Scheduler调度器、Pod资源对象管理等。Kubernetes总架构图如图1-1所示。

        Kubernetes系统架构遵循客户端/服务端（C/S）架构，系统架构分为Master和Node两部分，Master作为服务端，Node作为客户端。Kubernetes系统具有多个Master服务端，可以实现高可用。在默认的情况下，一个Master服务端即可完成所有工作。

        Master服务端也被称为主控节点，它在集群中主要负责如下任务。

• （1）集群的“大脑”，负责管理所有节点（Node）。
• （2）负责调度Pod在哪些节点上运行。
• （3）负责控制集群运行过程中的所有状态。

        Node客户端也被称为工作节点，它在集群中主要负责如下任务。

• （1）负责管理所有容器（Container）。
• （2）负责监控/上报所有Pod的运行状态。

        Master服务端（主控节点）主要负责管理和控制整个Kubernetes集群，对集群做出全局性决策，相当于整个集群的“大脑”。集群所执行的所有控制命令都由Master服务端接收并处理。Master服务端主要包含如下组件。

• kube-apiserver组件 ：集群的HTTP REST API接口，是集群控制的入口。
• kube-controller-manager组件 ：集群中所有资源对象的自动化控制中心。
• kube-scheduler组件 ：集群中Pod资源对象的调度服务。

        Node客户端（工作节点）是Kubernetes集群中的工作节点，Node节点上的工作由Master服务端进行分配，比如当某个Node节点宕机时，Master节点会将其上面的工作转移到其他Node节点上。

        Node节点主要包含如下组件。

• kubelet组件 ：负责管理节点上容器的创建、删除、启停等任务，与Master节点进行通信。
• kube-proxy组件 ：负责Kubernetes服务的通信及负载均衡服务。
• container组件 ：负责容器的基础管理服务，接收kubelet组件的指令。

四、总结与扩展

4.1、Kubernetes的优秀特性

Kubermetes有着如下的优秀特性。

• 强大的容器编排能力

        Kubernetes可以说是同Docker-起发展起来的， 深度集成了Docker,天然适应容器的特点，设计出强大的容器编排能力，比如容器组合、标签选择和服务发现等，可以满足企业级需求。

• 轻量级

        Kubermetes遵循微服务架构理论，整个系统划分出各个功能独立的组件，组件之间边界清晰，部署简单，可以轻易地运行在各种系统和环境中。同时，Kubermetes 中的许多功能都实现了插件化，可以非常方便地进行扩展和替换。

• 开放开源

        Kubermetes顺应了开放开源的趋势，吸引了大批开发者和公司参与其中，协同工作共同构建生态圈。同时，Kubernetes 同OpenStack、Docker 等开源社区积极合作、共同发展，企业和个人都可以参与其中并获益。

同时Kubernetes系统还具有如下特点：
●可移植：支持公有云、私有云、混合云、多重云（Multi-cloud）。
● 可扩展 ：模块化、插件化、可挂载、可组合。
● 自动化 ：自动部署、自动重启、自动复制、自动伸缩/扩展。

4.2、Kubernetes和Docker

        Kubernetes和Docker是两个互补的技术。比如，通常人们会使用Docker进行应用的开发，然后用Kubernetes在生产环境中对应用进行编排。

        在这样的模式中，开发者使用自己喜欢的语言编写代码，然后用Docker进行打包、测试和交付。但是最终在测试环境或生产环境中运行的过程是由Kubernetes来完成的。从运行架构上来说，假设在某生产环境中的Kubernetes集群是由10个节点构成的。那么其中的每个节点都是以Docker作为其容器运行时（Container Runtime）。也就是说，Docker是一种更加偏向底层的技术，它负责诸如启停容器的操作；而Kubernetes是一种更加偏向上层的技术，它注重集群范畴的管理，比如决定在哪个节点上运行容器、决定什么适合进行扩缩容或升级。

        图1.2阐释了由多个以Docker为容器运行时的节点构成的Kubernetes集群。

        如图1.2所示，Docker并非Kubernetes唯一支持的容器运行时。事实上，Kubernetes基于一系列特性实现了对容器运行时的抽象（从而可以兼容不同的底层容器运行时）。

        （1）容器运行时接口（Container Runtime Interface, CRI）是Kubernetes用来与第三方容器运行时进行对接的标准化的抽象层。这样容器运行时与Kubernetes是解耦的，同时又能够以一种标准化的方式予以支持。

        （2）运行时类（Runtime Class）是Kubernetes 1.12引入的新特性，并在1.14版中升级为beta。它对不同的运行时进行了归类。例如，gVisor或Kata容器运行时或许比Docker和Containerd能提供更优的隔离性。

        至本文撰写时，Containerd已经赶超Docker成为Kubernetes中最普遍使用的容器运行时。它实际上是Docker的精简版本，只保留了Kubernetes需要的部分。

        虽有提及，不过这些底层技术不会影响到Kubernetes的学习体验。无论使用哪种容器运行时，Kubernetes层面的操作（命令等）都是一样的。

4.3、Kubernetes为什么叫K8s

        K8S由google的Borg系统(博格系统，google内部使用的大规模容器编排工具)作为原型，后经Go语言延用Borg的思路重写并捐献给CNCF基金会开源。

        kubernetes的名字来自希腊语，意思是“舵手” 或 “领航员”,K8s是将8个字母“ubernete”替换为“8”的缩写。