认识Kubernetes以及与Docker的关系
认识Kubernetes以及与Docker的关系
西柚Kubernetes(k8s)的发展影响着全球IT技术的基础设施平台,也推动了云原生应用、微服务架构、Service Mesh等热门技术的普及和落地。现在,Kubernetes(k8s)已经成为明显项目,其开源项目拥有超过两万名贡献者,成为开源历史上发展速度超快的项目之一。
Kubernetes与Docker的关系
通常,我们会把Kubernetes(k8s)看作Docker的上层架构,就好像Java与J2EE的关系一样:J2EE是以Java为基础的企业级软件架构,Kubernetes(k8s)则以Docker为基础打造了一个云计算时代的全新分布式系统架构。但Kubernetes(k8s)与Docker之间还存在着更为复杂的关系,从表面上看,似乎Kubernets(k8s)离不开Docker,但实际上在Kubernetes(k8s)的架构里,Docker只是其目前支持的两种底层容器技术之一,另一种容器技术则是Rocket,Rocker为CentOS退出的竞争产品。
Kubernetes是什么
首先,它是一个全新的基于容器技术的分布式架构领先方案。这个方案虽然还很新,但它是谷歌十几年以来大规模应用容器技术的经验积累和升华的重要成果。确切地说,Kubernetes(k8s)是谷歌严格保密十几年的秘密武器–Borg的一个开源版本。Borg是谷歌的一个久负盛名的内部使用的大规模集群管理系统。它基于容器技术,目的是实现资源管理的自动化,以及跨多个数据中心的资源利用率的最大化。
十几年以来,谷歌一直通过Borg系统管理着数量庞大的应用程序集群。由于谷歌员工都签署了保密协议,即便离职也不能泄露Borg的内部设计,所以外界一直无法了解关于它的更多信息。直到2015年4月,传闻许久的Borg论文伴随Kubernetes的高调宣传被谷歌首次公开,大家才得以了解它的更多内幕。正是由于站在Borg这个前辈的肩膀上,汲取了Borg过去十年间的经验与教训,所以Kubernetes(k8s)一经开源就一鸣惊人,并迅速称霸容器领域。
其次,如果我们系统设计遵循了Kubernetes的设计思想,那么就不必考虑传统的系统架构中的业务跟底层代码以及功能模块,不必枉费心思考虑负载均衡跟部署实施的问题。总之使用Kubernetes提供的解决方案,不仅可以节省不少于30%的开发成本,还可以将精力集中于业务本身。而且由于Kubernetes提供了强大的自动化机制,所以系统后期的运维成本跟难度会大幅度降低。
然后,Kubernetes是一个开放的开发平台。与J2EE不同,它不局限于任何一种编程语言,没有限定任何编程接口,所以不论用什么语言编写的服务,都可以被映射为Kubernetes的Service(服务),并通过标准的TCP协议进行交互。此外,Kubernetes平台对现有的编程语言、编程框架、中间件没有任何侵入性,因此现有的系统也很容易改造升级并迁移到Kubernetes平台上。
最后Kubernetes是一个完备的分布式系统支撑平台。Kubernetes具有完备的集群管理能力,包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制。同时,Kubernetes提供了完善的管理工具。
Kubernetes的基本概念
在Kubernetes中,Service是分布式集群架构的核心,一个Service对象拥有如下关键特征。
- 拥有唯一指定名称(比如mysql-server)。
- 拥有一个虚拟IP(Cluster IP、Service IP 或 VIP)和端口号。
- 能够提供某种远程服务能力。
- 被映射到提供这种服务能力的一组容器应用上。
Service的服务进程目前都基于Socket通信方式对外提供服务,比如Redis、Memcachhe、MySQL、Web Server,或者是实现了某个具体业务的特定TCP Server进程。虽然一个Service通常由多个相关的服务进程提供服务,每个服务进程都有一个独立的Endpoint(IP+Port)访问点,但Kubernetes能够让我们通过Service(虚拟Cluster IP + Service Port)连接到指定的Service
容器提供了强大的隔离功能,所以有必要把为Service提供服务的这组进程放入容器中进行隔离。为此,Kubernetes设计了Pod对象,将每个服务进程都包装到相应的Pod中,使其为在Pod中运行的一个容器(Container)
这里先简单介绍一下Pod的概念。首先,Pod运行在一个被称为节点(Node)的环境中,这个节点既可以是物理机,也可以是私有云或者公有云中的一个虚拟机,通常一个节点上运行几百个Pod;其次,在每个Pod中都运行着一个特殊的被称为Pause的容器,其他容器则为业务容器,这些业务容器共享Pause容器的网络栈和Volume挂载卷,因此它们之间的通信和数据交换更为高效,在设计时我们可以利用这一特性把密切相关的服务进程放入同一个Pod中;最后需要注意的是,并不是每个Pod和它里面运行的容器都能被映射到一个Service上,只有提供服务(无论是对内还是对外)的那组Pod才会被映射为一个服务。
Kubernetes为传统IT系统的扩容和服务升级提供了全新的解决思路。在Kubernetes集群中,只需为需要扩容的Service关联的Pod创建一个RC (Replication Controller),服务扩容以至服务升级等令人头疼的问题都迎刃而解。在一个RC定义文件中包括以下3个关键信息。
- 目标Pod的定义
- 目标Pod需要运行的副本数量(Replicas)
- 要监控的目标Pod的标签
后记
本文主要是关于Kubernetes(k8s)的一些基本概念的介绍,后续还有其他像了解的内容可以在文章下发留言,尽量为大家写出来。也很欢迎各位大佬的斧正。