service：分布式集群架构的核心

service的几个特性：

• 唯一的名字
• 拥有一个虚拟IP和端口号
• 具有远程服务的 能力
• 映射到提供这种服务能力的一组容器上

集群管理

图片描述：k8s将急群众的机器划分为一个Master节点和一群工作节点（Node）。

Master节点上运行这kube-apiserver、kube-controller-manager和kube-scheduler进程，这些进程负责的功能有(都是自动完成的)：

• 资源管理
• Pod调度
• 弹性伸缩
• 安全控制
• 系统监控
• 纠错
• 资源管理
• 资源管理

Kubernetes API Server（kube-apiserver）：提供了HTTP REST接口的关键服务进程，是Kubernates里所有资源的增删改查操作的唯一入口，也是集群控制的入口进程。

Kubernetes Controller Manager（kube-controller-manager）：kubernetes中所有资源对象的自动化控制中心，可以理解为资源对象的大脑。

Kubernetes Scheduler（kube-scheduler）：负责资源调度（Pod调度）的进程。

Node

图片解释：Node既可以是物理机也可以是虚拟机。每个Node节点都会呗Master分配一些工作负载，当某个Node宕机是，其他上的工作负载会被Master自动转移到其他节点上去。Node节点中运行这许多的Pod，每个Pod里运行这一个Pause容器和多个业务容器，其中这些业务容器共享Pause容器的网络栈和Volume挂在卷，方便业务容器之间的高效通信和数据交换。
Node中运行着kubelet、kube-proxy和Docker Engine进程，两个进程负责的功能有:

• 创建POD
• 启动POD
• 监控POD
• 重启POD
• 销毁POD
• 实现软件模式的负载均衡

kubelet：负责Pod对应的容器的创建，启动等任务，同时与Master节点密切协作，实现集群管理的基本功能。

kube-proxy：实现Kubernetes Service的通信与负载均衡的重要组件。

Docker Engine：Docker引擎，负责本机的容器创建和管理工作。

Pod

Pod 运行在Node中，每个Pod里运行这一个Pause容器和多个业务容器，其中这些业务容器共享Pause容器的网络栈和Volume挂在卷，方便业务容器之间的高效通信和数据交换。
为什么Kubernetes会设计一个全新的Pod概念并且有这样特殊的组成结构？

• 以一组容器为单元的话，很难对整体简单的判断及有效的进行行动，而以不易死亡的Pause容器作为Pod的根容器，用它的状态来代表整个容器组的状态，从而简化判断和行动。
• 业务容器共享Pause容器的网络栈和Volume挂在卷，方便业务容器之间的高效通信和数据交换。

kuberbetes要求底层网络支持集群内部任意两个Pod之间的TCP/IP直接通信，才用虚拟二层技术实现。
Pod有两种类型：普通的Pod和静态的Pod

• 静态Pod不存放在Kuberbetes的etcd里面，而是放在某个具体的Node上的一个具体的文件中，并且只有在此Node上启动运行
• 普通Pod一旦被创建，就会放入到etcd中存储，随后会被Kubernetes Master调度到某个具体的Node上并进行绑定，随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动起来。

扩容和服务升级

kubernetes集群中，只要为需要扩容的Service关联的Podcast创建一个RC即可，RC（Replication Controller）包括三个关键的信息：

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

创建好RC之后，kubernetes会通过RC中定义的Label筛选出对应的Pod实例并实时监控器状态和数量，如果实例少于定义的副本数量，则会根据RC定义的Pod模板来创建新的Pod，但后调度到合适的Node上运行。

本文转自SegmentFault-从Rancher 1.6到2.0：术语及概念变化对比