软件开发架构师

《Kubernetes权威指南第2版》学习(一) Kubernetes是什么

架构 49 2019-03-22 22:55

1.1 Kubernetes是什么?

  首先,它是一个全新的基于容器技术的分布式架构领先方案。是谷歌的Borg(大规模集群管理系统)的一个开源版本。

  其次,如果系统设计遵循了Kubernetes的设计思想,那么传统系统架构中的和业务没有多大关系的底层代码或功能模块(比如负载均衡,服务自理框架,服务监控,故障处理等),都可以消失。使用Kubernetes,不仅可以节省至少30%的开发成本,更专注于业务,而且由于Kubernetes提供了强大的自动化机制,所以系统后期的运维难度和运维成本大幅度降低。

  然而,Kubernetes是一个开放的平台。与J2EE不同,它不局限于任何一种语言,没有限定任何编程接口,所以不论用JAVA、Go、C++还是用Python编写的服务,都可以毫不困难的映射为Kubernetes的service,并通过标准的TCP进行交互。

  此外,由于Kubernetes平台对现有的编程语言、编程框架、中间件没有任何入侵性,因此现有的系统很容易改造升级并迁移到Kubernetes平台上。

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

  因此,Kubernetes是一个全新的基于容器技术的分布式架构解决方案,并且是一个一站式的完备的分布式系统开发和支撑平台。

  Service是分布式集群的核心,一个Service对象拥有如下关键特征:

  • 有一个唯一指定的名字
  • 有一个虚拟IP和端口号
  • 能够提供远程服务能力
  • 被映射到了提供这种服务能力的一组容器应用上

  Service的服务进程都基于Socket通信方式对外提供服务(比如Redis、Memcache、MySql、Web Server),一个Service通常由多个相关服务进程提供服务,每个服务进程都有一个独立的Endpoint(IP+Port)访问点,但Kubernetes能够让我们通过Service(虚拟Cluster IP + Service Port)连接到指定的服务上。有了Kubernetes内建的透明负载均衡和故障恢复机制,不管后端有多少个服务进程,也不管某个服务进程是否发生故障而重新部署到其他机器,都不影响我们队服务的正常调用。

  容器提供了强大的隔离功能,所以有必要把为Service提供服务的这组进程放入容器中进行隔离。为此,Kubernetes提供了Pod对象,将每个服务进程包装到相应的Pod中,使其成为Pod中运行的一个容器(Container)。为了建立Service和Pod间的关联关系,Kubernetes首先给每个Pod贴上一个标签(Label),然后给相应的Service定义标签选择器(Label Selector),这样就巧妙的解决了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的创建、启动、监控、重启、销毁,以及实现软件模式的负载均衡器。

  最后,看看服务扩容和服务升级这两个难题:在Kubernetes集群中,你只需为需要扩容的Service关联的Pod创建一个Replication Controller(RC),则该Service的扩容和升级的问题都解决了。在一个RC定义文件中包括以下3个关键信息:

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

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

1.2 为什么要用Kubernetes? 

  最根本的理由是:IT从来都是一个由新技术驱动的行业。

  Docker被广泛采用,从单机走向集群已成必然,云计算正加速这一进程。Kubernetes作为当前唯一被广泛认可和看好的Docker分布式解决方案,可以预见,在未来几年内,会有大量的系统选择它,不管这些系统是运行在本地还是托管在公有云上。

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

  首先,团队精简了,一名系统工程师负责Kubernetes的部署和运维。

  其次,使用Kubernetes就是在全面拥抱微服务架构。

  然后,我们的系统可以随时整体搬迁到公有云上。Kubernetes的架构中,底层网络的细节完全被屏蔽。

  最后,kubernetes系统架构具备了超强的横向扩容能力。

1.3 从一个简单的例子开始  

     参考下一篇博客: http://www.cnblogs.com/liufei1983/p/8549024.html 

 

 

 

 

  

文章评论