Kubernetes-概述_kubernetes通过以下哪个配置可以保持容器集群中的容器个数按定义的阈值一直运行

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 就是在全面拥抱微服务架构。
微服务架构的核心是将 个巨大的单体应用分解为很多小的互相连接的微服务，一个微服务背后可能有多个实例副本在支撑，副本的数量可能会随着系统的负荷变化而进行调整，内嵌的负载均衡器在这里发挥了重要作用。微服务架构使得每个服务都可以由专门的开发团队来开发，开发者可以自由选择开发技术，这对于大规模团队来说很有价值，另外每个微服务独立开发、升级、扩展，因此系统具备很高的稳定性和快速法代进化能力。