1.1 Kubernetes 是什么？

k8s是一个全新的基于容器技术的分布式架构领先方案。这个方案虽然还很新，但它是谷歌十几年以来大规模应用容器技术的经验积累和升华的一个重要成果 确切地说，Kubemetes 是谷歌严格保密十几年的秘密武器 一 Borg 一个开源版本。 Borg 是谷歌的个久负盛名的内部使用的大规模集群管理系统，它基于容器技术，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率的最大化。

Kubemetes 提供的解决方案，我们不仅节省了不少于 30%的开发成本，同时可以将精力更加集中于业务本身，而且由于Kubemetes提供了强大的自动化机制，所以系统后期的运维难度和运维成本大幅度降低。

Kubemetes 个开放的开发平台。与 J2EE 不同，它不局限于任何 种语言，没有限定任何编程接口，所以不论是用 Java Go C＋＋还是用 hon 编写的服务，都可以毫无困难地映射为 Kubemetes Service 并通过标准的 TCP 通信协议进行交互。

Kubemetes 是一个完备的分布式系统支撑平台。Kubemetes 具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。

Kubemetes 中， Service （服务）是分布式集群架构的核心， Service 对象拥有如下关键特征。

• 拥有一个唯一指定的名字（比如 mysql-server ）
• 拥有 个虚拟 (Cluster Service IP VIP ）和端口号
• 能够提供某种远程服务能力
• 被映射到了提供这种服务能力的 组容器应用上

因容器提供了强大的隔离功能，所以有必要把为 Service 提供服务的这组进程放入容器中进行隔离。

因此Kubemetes 设计了 Pod对象，将每个服务进程包装到相应的 Pod 中，使其成为 Pod中运行的一个容器（ Container ）。

怎么解决Service和Pod 的关联问题？
为了建立 Service Pod 间的关联关系， Kubemetes 首先给每Pod 贴上 一个标签（ Label) ，给运行 MySQL Pod 贴上 name=mysql 标签，给运行php的Pod贴上name=php 标签，然后给相应的 Service 定义标签选择器（ Label Selector ），比如 MySQL Service 的标签选择器的选择条件为 name=mysql ，意为该 Service 要作用于所有包含 name=mysql Label Pod ,这样就巧妙地解决了 Service与Pod 的关联问题。

1.2 什么是Pod ？

1、Pod 运行在一个我们称之为节点（Node)的环境中，这个节点既可以是物理机，也可以是私有云或者公有云中的 个虚拟机，**通常在一个节点上运行几百个 Pod **；

2、每个 Pod 里运行着一个特殊的被称之为 Pause 的容器，其他容器则为业务容器，这些业务容器共享 Pause 容器的网络械和 Volume 挂载卷，因此它们之间的通信和数据交换更为高效，在设计时我们可以充分利用这 特性将组密切相关的服务进程放入同 Pod 中；

3、不是每个 Pod 和它里面运行的容器都能“映射”到一个Service 上，只有那些提供服务（无论是对内还是对外）的 Pod 才会被“映射”成一个服务。

1.3 K8S集群管理

Kubemetes 将集群中的机器划分为一个Master节点和 群工作节点（Node）。

Master 节点运行着集群管理相关的一组进程：kube-apiserver kube-controller-manager、kube-scheduler ，这些进程实现了整个集群的资源管理、 Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，井且都是全自动完成的。

Node 作为集群中的工作节点，运行真正的应用程序，在 Node上 Kubemetes管理的最小运行单元是 Pod。Node 上运行着： Kubemetes的kubelet、kube-proxy服务进程，这些服务进程负责 Pod 的创建、启动、监控、重启、销毁，以及实现软件模式的负载均衡器。

1.4 K8S给服务扩容和升级新思路

在Kubemetes 集群中，你只需为需要扩容的 Service 关联的 Pod 创建一个 RC (Replication Controiller ），则该 Service 的扩容以至于后来的 Service 升级等头疼问题都迎刃而解。

RC定义文件中包括以下3个关键信息

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

在创建好 RC（系统将自动创建好 Pod ）后， Kubemetes 会通过 RC 中定义的 Label 筛选出对应的 Pod 实例井实时监控其状态和数量，如果实例数量少于定义的副本数量（ Replicas ），则会根据 RC 中定义的 Pod 模板来创建一个新的 Pod ，然后将此 Pod 调度到合适的 Node 上启动运
行，直到 Pod 实例的数 达到预定目标。

这个过程完全是自动化的，无须人工干预 有了 RC,服务的扩容就变成了一个纯粹的简单数字游戏了，只要修改 RC 中的副本数量即可。后续的Service 升级也将通过修改 RC 来自动完成。

PHP+Redis 留言板应用为例，只要为PHP旧留言板程序（frontend )创建一个有3个副本的 RC+Service ，为 Redis 读写分离集群创建两个RC ：写节点（ redis-master) ，创建一个单副本 RC+Service ，读节点（ redis-slaver ）创建一个有两个副本的 RC+Service ，就可快速完成整个集群的搭建过程。

1.5为什么要用 Kubernetes?

IT 从来都是一个由新技术驱动的行业，K8S是大势所趋！

使用了 Kubemetes 会收获哪些好处呢？

1. “轻装上阵”地开发复杂系统。
Kubemetes 解决方案之后，只需 个精悍的小团队就能轻松应对。在这个团队里，一名架构师专注于系统中“服务组件”的提炼，几名开发工程师专注于业务代码的开发， 名系统兼运维工程师负责Kubemetes 的部署和运维，从此再也不用“996 ”了，这并不是因为我们少做了什么，而是因为 Kubemetes 己经帮我们做了很多。
2. 使用 Kubemetes 就是在全面拥抱微服务架构。
微服务架构的核心是将 个巨大的单体应用分解为很多小的互相连接的微服务，一个微服务背后可能有多个实例副本在支撑，副本的数量可能会随着系统的负荷变化而进行调整，内嵌的负载均衡器在这里发挥了重要作用。微服务架构使得每个服务都可以由专门的开发团队来开发，开发者可以自由选择开发技术，这对于大规模团队来说很有价值，另外每个微服务独立开发、升级、扩展，因此系统具备很高的稳定性和快速法代进化能力。
3. 系统可以随时随地整体“搬迁”到公有云上。
Kubemetes 最初的目标就是运行在谷歌自家的公有云 GCE 中，未来会支持更多的公有云及基于 OpenStack 的私有云。同时，Kubemetes 的架构方案中，底层网络的细节完全被屏蔽，基于服务的 Cluster IP 甚至都无须我们改变运行期的配置文件，就能将系统从物理机环境中无缝迁移到公有云中，或者在服务高峰期将部分服务对应的 Pod 副本放入公有云中以提升系统的吞吐量，不仅节省了公司的硬件投入，还大大改善了客户体验 我们所熟知的铁道部的 12306 购票系统，在春节高峰期就租用了阿里云进行分流。
4. Kubemetes 系统架构具备了超强的横向扩容能力。
对于互联网公司来说，用户规模就等价于资产，谁拥有更多的用户，谁就能在竞争中胜出，因此超强的横向扩容能力是互联网业务系统的关键指标之一。 不用修改代码， ubemete 集群即可从只包含几个 Node 的小集群平滑扩展到拥有上百个 Node 的大规模集群，我们利用 ubemetes 提供的工具，甚至可以在线完成集群扩容。只要我们的微服务设计得好，结合硬件或者公有云资源的线性增加，系统就能够承受大 用户并发访问所带来的巨大压力。