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