Kuberneters

概念

• Kuberneters解决了负载均衡器的选型、部署实施问题、服务治理、服务监控、故障处理。

• Kuberneters没有限定任何编程接口。都可以毫无困难地映射为 Kuberneters 的 Service， 并通过标准的 TCP 通信协议进行交互。

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

• Kuberneters 提供了完善的管理工具，这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。因此，Kuberneters是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台。

在 Kuberneters 中， Service (服务)是分布式集群架构的核心，一个 Service对象拥有如下关键特征。

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

Kuberneters的Pod对象

Kuberneters 设计了Pod对象，将每个服务进程包装到相应的Pod中，使其成为Pod中运行的一个容器(Container)。
Kuberneters 给每个Pod贴上一个标签(Label)，给运行MySQL的Pod贴上name=mysql标签，给运行PHP的Pod贴上name=php标签，然后给相应的 Service 定义标签选择器( Label Selector)，意为该Service要作用于所有包含name=mysql Label的Pod上。

Pod运行在一个我们称之为节点(Node)的环境中。每个 Pod 里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷。并不是每个 Pod 和它里面运行的容器都能“映射”到一个Service上，只有那些提供服务（无论是对内还是对外）的一组Pod才会被“映射”成一个服务。

Kuberneters的集群管理

Kuberneters将集群中的机器划分为一个Master节点和一群工作节点(Node)。其中，在Master节点上运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、 Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且都是全自动完成的。 Node作为集群中的工作节点，运行真正的应用程序，在 Node 上 Kuberneters 管理的最小运行单元是 Pod。 Node 上运行着 Kuberneters 的 kubelet、kube-proxy 服务进程，这些服务进程负责 Pod 的创建、启动、监控、重启、销毁，以及实现软件模式的负载均衡器。

Kuberneters的服务升级和服务扩容

只需为需要扩容的 Service 关联的 Pod 创建一个 RC (Replication Controller)，则该 Service 的扩容以至于后来的 Service 升级等头疼问题都迎刃而解。在一个 RC 定义文件中包括以下3个关键信息。

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

在创建好 RC（系统将自动创建好 Pod）后，Kuberneters 会通过 RC 中定义的 Label 筛选出对应的 Pod 实例并实时监控其状态和数量，如果实例数量少于定义的副本数量（Replicas）

Kuberneters的Master节点

Master节点上运行着以下一组关键进程。

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

• Kubernetes Controller Manager (kube-controller-manager)：Kubernetes里所有资源对象的自动化控制中心，可以理解为资源对象的“大总管”。

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

• 另外，在Master节点上还需要启动一个etcd服务，Kubernetes里的所有资源对象的数据全部是保存在etcd中的。

Kuberneters的Node节点

每个Node节点上的组件包括：

• kubelet：负责Pod对应的容器的创建、启停等任务，同时与Master节点密切协作，实现集群管理的基本功能。
• kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件。
• Docker Engine（容器运行时）：Docker引擎，负责本机的容器创建和管理工作。

Kuberneters的Pod对象

每个Pod都有一个特殊的被称为“根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器。

设计pod原因：

• 在一组容器作为一个单元的情况下，我们难以对“整体”简单地进行判断及有效地进行行动
• Pod里的多个业务容器共享Pause容器的IP，共享Pause容器挂接的Volume

Kubernetes要求底层网络支持集群内任意两个Pod之间的TCP/IP直接通信，这通常采用虚拟而层网络技术来实现，例如Flannel、Open vSwitch等

Pod其实有两种类型：普通的Pod及静态Pod（Static Pod），后者比较特殊，它并不存放在Kubernetes的etcd存储里，而是存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动运行。而普通的Pod一旦被创建，就会被放入到etcd中存储，随后会被Kubernetes Master调度到某个具体的Node上并进行绑定（Binding），随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器并且启动起来。

每个Pod都可以对其能使用的服务器上的计算资源设置限额，当前可以设置限额的计算资源有CPU与Memory两种，其中CPU的资源单位为CPU（Core）的数量，是一个绝对值而非相对值。Memory配额也是一个绝对值，它的单位是内存字节数。

Kuberneters的Label Selector

Label Selector在Kubernetes中重要的使用场景有以下几处：

• kube-controller进程通过资源对象RC上定义都Label Selector来筛选要监控的Pod副本的数量，从而实现Pod副本的数量始终符合预期设定。

• kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立起每个Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡机制。

• 通过对某些Node定义特定的Label，并且在Pod定义文件中使用NodeSelector这种标签调度策略，kube-scheduler进程可以实现Pod“定向调度”的特性。

label可以方便Kuberneters的Label进行分组管理，提升可用性。

Label具有严格的命名规则，Label定义的是Kubernetes对象的元数据（Metadata），并且用于Label Selector（标签选择器）

Kuberneters的Annotation

Annotation（注解）则是用户任意定义的“附加”信息，便于用户自行的一些查找行为

"metadata": {
  "annotations": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

Kuberneters的RC

RC的定义包括如下几个部分：

• Pod期待的副本数（replicas）。
• 用于筛选目标Pod的Label Selector。
• 当Pod的副本数量小于预期数量时，用于创建新Pod的Pod模版（template）。