Kubernetes是什么
首先，它是一个全新的基于容器技术的分布式架构领先方案，简称K8s。K8s是Borg的一个开源版本，Borg是谷歌内部一个久负盛名的大规模集群管理系统，它基于容器技术，目的是实现资源管理的自动化以及跨数据中心的资源利用率最大化。
其次，如果我们的系统设计遵循了K8s的设计思想，那么传统系统架构中那些和业务没有多大关系的底层代码或功能模块，都可以立刻从我们的视线中消失，我们不必再费心于负载均衡器的选型和部署实施问题，不必再考虑引入或自己开发一个复杂的服务治理框架，不必再头疼于服务监控和故障处理模块的开发。总之，使用K8s提供的解决方案，我们不仅节省了不少于30%的开发成本，同时可以将精力更加集中于业务本身，而且由于K8s提供了强大的自动化机制，所以系统后期的运维难度和运维成本大幅度降低。
然后，K8s是一个开放的开发平台，它不局限于任何一种语言，没有限定任何编程接口，所以不论是用Java、Go、C++还是用Python编写的服务，都可以毫无困难地映射为K8s的Service，并通过标准的TCP通信协议进行交互。
最后，K8s是一个完备的分布式系统支撑平台。K8s具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制、以及多粒度的资源配额管理能力。同时，K8s提供了完善的管理工具，这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。
因此，K8s是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台。
K8s概述
在K8s中，Service（服务）是分布式集群架构的核心，一个Service对象拥有如下关键特征：
- 拥有一个唯一指定的名字（比如MySQL-server）
- 拥有一个虚拟IP(Cluster IP、Service IP或VIP)和端口
- 能够提供某种远程服务能力
- 被映射到了提供这种服务能力的一组容器应用上。
Service的服务进程目前都基于Socket通信方式对外提供服务，比如Redis、Memcache、MySQL、Web Server或者是实现了某个具体业务的一个特定的TCP Server进程。虽然一个Service通常由多个相关的服务进程来服务，每个进程服务都有一个独立的Endpoint（IP+Port）访问点，但K8s能够让我们通过Service（虚拟Cluster IP+Service Port）链接到制定的Service上。有了K8s内建的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否会由于发生故障而重新部署到其他机器，都不会影响到我们对服务的正常调用。更重要的是这个Service本身一旦创建就不在变化，这意味着，在K8s集群中，我们再也不用为了服务的IP地址变化而头疼。
容器提供了强大的隔离功能，所以有必要把为Service提供服务的这组进程放入容器中进行隔离。为此,K8s设计了Pod对象，将每个服务进程包装到相应的Pod中，使其成为Pod中运行的一个容器（Container）。为了建立Service和Pod之间的关联关系，K8s首先会给每个Pod贴上一个标签（Label），给运行MySQL的Pod贴上 name=MySQL 标签，给运行PHP的Pod贴上name=PHP标签，然后给相应的Service定义标签选择器（Label Selector），比如MySQL Service的标签选择器的选择条件为name=MySQL，意味着该Service要作用于所有包含name=MySQL标签的Pod上。这样，就巧妙解决了Service于Pod的关联问题。
首先，Pod运行在一个我们称之为节点（Node）的环境中，这个节点既可以是物理机，也可以是私有云或者公有云中的一个虚拟机，通常在一个节点上运行几百个Pod；其次，每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此它们之间的通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放在同一个Pod中；最后，需要注意的是，并不是每个Pod和它里面运行的容器都能“映射”到一个Service上，只有那些提供服务（无论是对内还是对外）的一组Pod才会被“映射”成一个服务。
在集群管理方面，K8s将集群中的机器划分为一个Master节点和一群工作节点（Node）。其中，在Master节点上运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且都是全自动完成的。Node作为集群中的工作节点，运行真正的应用程序，在Node上K8s管理的最小运行单元是Pod。Node上运行着K8s的kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁，以及实现软件模式的负载均衡。
最后，我们再来看看传统的IT系统中服务扩容和服务升级这两个难题，以及K8s所提供的全新解决思路。服务的扩容涉及资源分配（选择哪个节点进行扩容）、实例部署和启动等环节，在一个复杂的业务系统中，这两个问题基本上靠人工一步步操作才能得以完成，费时费力又难以保证实施质量。
在K8s集群中，你只需为需要扩容的Service关联的Pod创建一个Replication Controller（RC），则该Service的扩容以至于后来的Service升级等头疼问题都迎刃而解。一个RC定义文件中包括以下三个关键信息：
- 目标Pod的定义
- 目标Pod需要运行的副本数量（Replicas）
- 要监控的目标Pod和标签（Label）
在创建好RC后，K8s会通过RC中定义的Label筛选对应的Pod实例并实时监控其状态和数量，如果实例数量少于定义的副本数（Replicas），则会根据RC中定义的Pod模板来创建一个新的Pod，然后将此Pod调度到合适的Node上启动运行，直到Pod实例的数量达到预定目标，这个过程完全是自动化的。有了RC，服务的扩容就变成了一个纯粹的简单数字游戏了，只要修改RC中副本数量即可。后续的Service升级也可以通过修改RC来自动完成。
为什么要用K8s
使用K8s的理由很多，最根本的一个理由就是：IT从来都是一个由新技术驱动的行业。
Docker这个新兴的容器化技术当前已经被很多公司所采用，其从单机走向集群已经成为必然。而云计算的蓬勃发展正在加速这一进程。K8s作为当前唯一被业务广泛认可和看好的Docker分布式系统解决方案，可以预见，在未来几年内，会有大量的新系统选择它，不管这些系统是运行在企业本地服务器上还是被托管到公有云上。
使用K8s又会收获那些好处呢？
首先，最直接的感受就是我们可以“轻装上阵”地开发复杂系统了。以前动不动就需要十几个人而且团队需要不少技术达人一起分工协作才能设计实现和运维分布式系统，在采用K8s解决方案之后，只需要一个精悍的小团队就能轻松应对。在这个团队里，一名架构师专注于系统中“服务组件”的提炼，几名开发工程师专注于业务代码的开发，一名系统运维工程师负责K8s的部署和运维，从此告别996，这并不是因为我们少做了什么，而是因为K8s已经帮我们做了很多。
其次，使用K8s就是在全面拥抱微服务架构。微服务架构的核心是将一个巨大的单体应用分解为很多小的互相连接的微服务（服务拆分），一个微服务背后可能有多个实例副本在支撑，副本的数量可能会随着系统的负荷变化而进行调整（动态扩缩容），内嵌的负载均衡器在这里发挥了重要作用。微服务架构使得每个服务都可以由专门的开发团队来开发，开发者可以自由选择开发技术（多技术栈并行），这对于大规模团队来说很有价值，另外每个微服务独立开发、升级、扩展，因此系统具备很高的稳定性和快速迭代进化能力。谷歌、亚马逊、eBay等众多大型互联网公司都采用了微服务架构，此次谷歌更是将微服务架构的基础设施直接打包到K8s解决方案中，让我们有机会直接应用微服务架构解决复杂业务系统的架构问题。
然后，我们的系统可以随时随地整体“搬迁”到公有云上（无缝迁移，动态分流）。K8s最初的目标就是运行在谷歌自家的公有云GCE中，未来会支持更多的公有云及其基于OpenStack的私有云。同时，在K8s的架构方案中，底层网络的细节完全被屏蔽，基于服务的Cluster IP甚至都无需改变运行期的配置文件，就能将系统从物理机环境中无缝迁移到公有云中，后者在服务高峰期将部分服务对应的Pod副本放入公有云中以提升系统的吞吐量，不仅节省了公司的硬件投入，还大大改善了客户体验。我们所熟知的铁道部12306购票系统，在春节高峰期就租用了阿里云进行分流。
最后，K8s系统架构具备了超强的横向扩容能力。对于互联网公司来说，用户规模就等价于资产，谁拥有更多的用户，谁就能在竞争中胜出，因此超强的横向扩容能力是互联网业务系统的关键指标之一。不用修改代码，一个K8s集群即可从只包含几个Node的小集群平滑扩展到拥有上百个Node的大规模集群，我们利用K8s提供的工具，甚至可以在线完成集群扩容。只要我们的微服务架构设计得好，结合硬件或者公有云资源的线性增加，系统就能够承受大量用户并发访问所带来的巨大压力。
内容源自：《Kubernetes权威指南》
