Kuberneters解决了负载均衡器的选型、部署实施问题、服务治理、服务监控、故障处理。
Kuberneters没有限定任何编程接口。都可以毫无困难地映射为 Kuberneters 的 Service, 并通过标准的 TCP 通信协议进行交互。
Kuberneters 具有完备的集群管理能力,包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制,以及多粒度的资源配额管理能力
Kuberneters 提供了完善的管理工具,这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。因此,Kuberneters是一个全新的基于容器技术的分布式架构解决方案,并且是一个一站式的完备的分布式系统开发和支撑平台。
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将集群中的机器划分为一个Master节点和一群工作节点(Node)。其中,在Master节点上运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler,这些进程实现了整个集群的资源管理、 Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理功能,并且都是全自动完成的。 Node作为集群中的工作节点,运行真正的应用程序,在 Node 上 Kuberneters 管理的最小运行单元是 Pod。 Node 上运行着 Kuberneters 的 kubelet、kube-proxy 服务进程,这些服务进程负责 Pod 的创建、启动、监控、重启、销毁,以及实现软件模式的负载均衡器。
只需为需要扩容的 Service 关联的 Pod 创建一个 RC (Replication Controller),则该 Service 的扩容以至于后来的 Service 升级等头疼问题都迎刃而解。在一个 RC 定义文件中包括以下3个关键信息。
在创建好 RC(系统将自动创建好 Pod)后,Kuberneters 会通过 RC 中定义的 Label 筛选出对应的 Pod 实例并实时监控其状态和数量,如果实例数量少于定义的副本数量(Replicas)
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中的。
每个Node节点上的组件包括:
每个Pod都有一个特殊的被称为“根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分,除了Pause容器,每个Pod还包含一个或多个紧密相关的用户业务容器。
设计pod原因:
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配额也是一个绝对值,它的单位是内存字节数。
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(标签选择器)
Annotation(注解)则是用户任意定义的“附加”信息,便于用户自行的一些查找行为
"metadata": { "annotations": { "key1" : "value1", "key2" : "value2" } }
RC的定义包括如下几个部分: