什么是Kubernetes?

什么是Kubernetes?

首先,它是一种全新的基于容器技术的分布式架构的领先方案。这个方案虽然还很新,但却是Google十几年容器技术大规模应用经验积累和升华的重要成果。确切的说,Kubernetes是Google十多年来严格保密的秘密武器——Borg的开源版本。Borg是Google内部使用的著名大规模集群管理系统。它基于容器技术,旨在实现资源管理的自动化,最大限度地提高多个数据中心的资源利用率。十多年来,Google一直通过Borg系统管理着大量的应用集群。由于谷歌员工已经签署了保密协议,即使离职也不能透露博格的内部设计,所以外界一直无法了解更多。直到2065438+2005年4月,传闻已久的博格论文在Kubernetes的高调宣传下被谷歌首次发表,大家才得以进一步了解。正是因为站在了博格的肩膀上,吸取了博格这十年的经验教训,Kubernetes一开就一鸣惊人,迅速称霸集装箱领域。其次,如果我们的系统设计遵循Kubernetes的设计思路,传统系统架构中与业务关系不大的底层代码或功能模块可以立刻从我们的视线中消失。我们不必担心负载均衡器的选择、部署和实现,不必自己引入或开发复杂的服务治理框架,也不必担心服务监控和故障处理模块的开发。总之,有了Kubernetes提供的解决方案,我们不仅可以节省不低于30%的开发成本,还可以更加专注于业务本身。而且由于Kubernetes提供的强大自动化机制,大大降低了系统后期运维的难度和成本。

然后,Kubernetes是一个开放的开发平台。与J2EE不同的是,它不局限于任何语言,没有编程接口,所以任何用Java、Go、C++或Python编写的服务都可以映射到Kubernetes的服务,并通过标准的TCP通信协议进行交互。此外,Kubernetes平台不干扰现有的编程语言、编程框架和中间件,因此现有系统可以很容易地升级和迁移到Kubernetes平台。

最后,Kubernetes是一个完整的分布式系统支持平台。Kubernetes拥有完整的集群管理能力,包括多级安全保护和访问机制、多租户应用支持能力、透明的服务注册和服务发现机制、内置智能负载均衡器、强大的故障发现和自我修复能力、滚动服务升级和在线扩容能力、可扩展的资源自动调度机制、多粒度资源配额管理能力。同时,Kubernetes提供完善的管理工具,涵盖包括开发、部署测试、运维监控在内的各个方面。因此,Kubernetes是一个全新的基于容器技术的分布式架构解决方案,是一个一站式、完整的分布式系统开发和支持平台。

在本章开始Hello World之旅之前,我们首先要学习一些Kubernetes的基础知识,从而了解Kubernetes提供的解决方案。

在Kubernetes中,服务是分布式集群架构的核心,服务对象具有以下关键特征。

有一个唯一的名字(比如mysql-server)。

拥有虚拟IP(集群IP、服务IP或VIP)和端口号。

提供某种远程服务的能力。

被映射到一组提供此服务功能的容器应用程序。

目前Service的服务流程都是基于Socket通信对外提供服务,如Redis、Memcache、MySQL、

Web服务器,或者实现特定业务的特定TCP服务器进程。虽然一个服务通常由多个相关的服务进程提供,并且每个服务进程都有一个独立的端点(IP+Port)接入点,但是Kubernetes使我们能够通过Service(虚拟集群IP+服务端口)连接到指定的服务。有了Kubernetes内置的透明负载均衡和故障恢复机制,无论后端有多少服务进程,或者某个服务进程是否因为故障被重新部署到其他机器上,都不会影响服务的正常调用。更重要的是,一旦服务本身被创建,它将不会改变,这意味着我们不再需要担心Kubernetes集群中服务的IP地址的变化。

容器提供了强大的隔离功能,因此有必要将这组为服务提供服务的流程隔离在容器中。因此,Kubernetes设计了一个Pod对象,将每个服务流程打包到一个对应的Pod中,使其成为一个运行在Pod中的容器。为了建立服务和Pod之间的关系,Kubernetes首先对每个Pod进行标记,用name=mysql标记运行MySQL的Pod,用name=php标记运行PHP的Pod,然后为相应的服务定义一个标签选择器。比如MySQL服务的标签选择器的选择条件是name=mysql,也就是说服务要作用于所有包含name=mysql标签的pod。这样巧妙地解决了服务和Pod的关联问题。

下面简单介绍一下Pod的概念。首先,Pod运行在一个叫节点的环境中,节点可以是物理机,也可以是私有云或公有云的虚拟机,通常在一个节点上运行上百个Pod。其次,每个Pod中运行一个叫做Pause的特殊容器,其他容器都是业务容器。这些业务容器* * *共享暂停容器的网络堆栈和卷挂载卷,因此它们之间的通信和数据交换更加高效。我们可以充分利用这个特性,在设计的时候把一组紧密相关的服务流程放到同一个Pod里。最后,应该注意的是,并不是每个Pod和在其中运行的容器都可以映射到一个服务,只有提供服务的那组Pod(无论是内部的还是外部的)才会被映射到一个服务。

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

最后看看传统IT系统中的服务拓展和服务升级两大难题,以及Kubernetes提供的新解决方案。服务的扩展涉及资源分配(选择哪个节点进行扩展)、实例部署和启动。在复杂的业务系统中,这两个问题基本都是通过人工分步操作来解决的,费时费力,而且很难保证实现质量。

在Kubernetes集群中,只需为需要扩展的服务关联的Pod创建一个RC(复制控制器),服务扩展、服务升级等令人头疼的问题就迎刃而解了。在RC定义文件中包含以下三个关键信息。

目标Pod的定义。

目标Pod需要运行的副本数量。

要监控的目标Pod的标签。

创建RC后(系统将自动创建Pod),Kubernetes将实时监控RC中定义的LabelPod实例的状态和数量。如果实例数量小于定义的副本数量,将根据RC中定义的Pod模板创建一个新的Pod,然后该Pod将被分派到适当的节点开始运行,直到Pod实例数量达到预定目标。这个过程是完全自动的,不需要人工干预。有了RC,服务拓展就变成了一个纯粹简单的数字游戏,只需要修改RC中的副本数量就可以了。后续的服务升级也将通过修改RC自动完成。