北京快三开奖

  • <tr id="U9YkSO"><strong id="U9YkSO"></strong><small id="U9YkSO"></small><button id="U9YkSO"></button><li id="U9YkSO"><noscript id="U9YkSO"><big id="U9YkSO"></big><dt id="U9YkSO"></dt></noscript></li></tr><ol id="U9YkSO"><option id="U9YkSO"><table id="U9YkSO"><blockquote id="U9YkSO"><tbody id="U9YkSO"></tbody></blockquote></table></option></ol><u id="U9YkSO"></u><kbd id="U9YkSO"><kbd id="U9YkSO"></kbd></kbd>

    <code id="U9YkSO"><strong id="U9YkSO"></strong></code>

    <fieldset id="U9YkSO"></fieldset>
          <span id="U9YkSO"></span>

              <ins id="U9YkSO"></ins>
              <acronym id="U9YkSO"><em id="U9YkSO"></em><td id="U9YkSO"><div id="U9YkSO"></div></td></acronym><address id="U9YkSO"><big id="U9YkSO"><big id="U9YkSO"></big><legend id="U9YkSO"></legend></big></address>

              <i id="U9YkSO"><div id="U9YkSO"><ins id="U9YkSO"></ins></div></i>
              <i id="U9YkSO"></i>
            1. <dl id="U9YkSO"></dl>
              1. <blockquote id="U9YkSO"><q id="U9YkSO"><noscript id="U9YkSO"></noscript><dt id="U9YkSO"></dt></q></blockquote><noframes id="U9YkSO"><i id="U9YkSO"></i>
                企业空间 推销商城 存储论坛
                北京快三开奖全闪存阵列 IBM云盘算 Acronis 安克诺斯 安腾普 腾保数据
                首页 > 技能园地 > Docker > 注释

                Google开源的容器集群办理零碎Kubernetes零碎架构简介

                2017-10-05 22:14泉源:CISCO杨章显
                导读:Google开源的容器集群办理零碎Kubernetes零碎架构简介,应用Kubernetes能方便地办理跨呆板运转容器化的使用。

                Kubernetes作为Docker生态圈中紧张一员,是Google多年大范围容器办理技能的开源版本,是产线理论经历的最佳体现。如Urs Hölzle所说,无论是私有云照旧公有云乃至混淆云,Kubernetes将作为一个为任何使用,任何情况的容器办理框架无处不在。正由于云云, 现在遭到各大巨擘及首创公司的喜爱,如Microsoft、VMWare、Red Hat、CoreOS、Mesos等,纷繁参加给Kubernetes奉献代码。随着Kubernetes社区及各大厂商的精益求精、开展,Kuberentes将成为容器办理范畴的向导者。

                接上去我们会用一系列文章逐一探究Kubernetes是什么、能做什么以及怎样做。

                2. 什么是Kubernetes

                Kubernetes是Google开源的容器集群办理零碎,其提供给用摆设、维护、 扩展机制等功用,应用Kubernetes能方便地办理跨呆板运转容器化的使用,其次要功用如下: 

                1) 运用Docker对使用顺序包装(package)、实例化(instantiate)、运转(run)。

                2) 以集群的方法运转、办理跨呆板的容器。

                3) 处理Docker跨呆板容器之间的通讯题目。

                4) Kubernetes的自我修复机制使得容器集群总是运转在用户希冀的形态。

                以后Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure等平台,除此之外,也可以间接运转在物理机上。

                接上去本文次要从以下几方面论述Kubernetes:

                1) Kubernetes的次要观点。

                2) Kubernetes的构件,包罗Master组件、Kubelet、Proxy的细致引见。

                3. Kubernetes次要观点

                3.1. Pods

                Pod是Kubernetes的根本操纵单位,把相干的一个或多个容器组成一个Pod,通常Pod里的容器运转相反的使用。Pod包括的容器运转在统一个Minion(Host)上,看作一个一致办理单位,共享相反的volumes和network namespace/IP和Port空间。

                3.2. Services

                Services也是Kubernetes的根本操纵单位,是真实使用效劳的笼统,每一个效劳前面都有许多对应的容器来支持,经过Proxy的port和效劳selector决议效劳恳求通报给后端提供效劳的容器,对表面现为一个单一拜访接口,内部不需求理解后端怎样运转,这给扩展或维护后端带来很大的益处。

                3.3. Replication Controllers

                Replication Controller确保任何时分Kubernetes集群中有指定命量的pod正本(replicas)在运转, 假如少于指定命量的pod正本(replicas),Replication Controller会启动新的Container,反之会杀去世多余的以包管数目稳定。Replication Controller运用事后界说的pod模板创立pods,一旦创立乐成,pod 模板和创立的pods没有任何干联,可以修正pod 模板而不会对已创立pods有任何影响,也可以间接更新经过Replication Controller创立的pods。关于应用pod 模板创立的pods,Replication Controller依据label selector来联系关系,经过修正pods的label可以删除对应的pods。Replication Controller次要有如下用法:

                1) Rescheduling

                如上所述,Replication Controller会确保Kubernetes集群中指定的pod正本(replicas)在运转, 即便在节点堕落时。

                2) Scaling

                经过修正Replication Controller的正本(replicas)数目来程度扩展或许减少运转的pods。

                3) Rolling updates

                Replication Controller的设计准绳使得可以一个一个地交换pods来rolling updates效劳。

                4) Multiple release tracks

                假如需求在零碎中运转multiple release的效劳,Replication Controller运用labels来区分multiple release tracks。

                3.4. Labels

                Labels是用于区分Pod、Service、Replication Controller的key/value键值对,Pod、Service、 Replication Controller可以有多个label,但是每个label的key只能对应一个value。Labels是Service和Replication Controller运转的根底,为了将拜访Service的恳求转发给后端提供效劳的多个容器,正是经过标识容器的labels来选择准确的容器。异样,Replication Controller也运用labels来办理经过pod 模板创立的一组容器,如许Replication Controller可以愈加容易,方便地办理多个容器,无论有几多容器。

                4. Kubernetes构件

                Kubenetes全体框架如下图3-1,次要包罗kubecfg、Master API Server、Kubelet、Minion(Host)以及Proxy。

                Google开源的容器集群办理零碎Kubernetes零碎架构简介

                图3-1 Kubernetes High Level构件

                4.1. Master

                Master界说了Kubernetes 集群Master/API Server的次要声明,包罗Pod Registry、Controller Registry、Service Registry、Endpoint Registry、Minion Registry、Binding Registry、RESTStorage以及Client, 是client(Kubecfg)挪用Kubernetes API,办理Kubernetes次要构件Pods、Services、Minions、容器的入口。Master由API Server、Scheduler以及Registry等构成。从下图3-2可知Master的任务流次要分以下步调:

                1) Kubecfg将特定的恳求,比方创立Pod,发送给Kubernetes Client。

                2) Kubernetes Client将恳求发送给API server。

                3) API Server依据恳求的范例,比方创立Pod时storage范例是pods,然后依此选择何种REST Storage API对恳求作来由理。

                4) REST Storage API对的恳求作相应的处置。

                5) 将处置的后果存入高可用键值存储零碎Etcd中。

                6) 在API Server呼应Kubecfg的恳求后,Scheduler会依据Kubernetes Client获取集群中运转Pod及Minion信息。

                7) 根据从Kubernetes Client获取的信息,Scheduler将未分发的Pod分发到可用的Minion节点上。

                上面是Master的次要构件的细致引见:

                Google开源的容器集群办理零碎Kubernetes零碎架构简介

                图3-2 Master次要构件及任务流

                3.1.1. Minion Registry

                Minion Registry担任跟踪Kubernetes 集群中有几多Minion(Host)。Kubernetes封装Minion Registry成完成Kubernetes API Server的RESTful API接口REST,经过这些API,我们可以对Minion Registry做Create、Get、List、Delete操纵,由于Minon只能被创立或删除,以是不支持Update操纵,并把Minion的相干设置装备摆设信息存储到etcd。除此之外,Scheduler算法依据Minion的资源容量来确定能否将新建Pod分发到该Minion节点。

                3.1.2. Pod Registry

                Pod Registry担任跟踪Kubernetes集群中有几多Pod在运转,以及这些Pod跟Minion是怎样的映射干系。将Pod Registry和Cloud Provider信息及其他相干信息封装成完成Kubernetes API Server的RESTful API接口REST。经过这些API,我们可以对Pod停止Create、Get、List、Update、Delete操纵,并将Pod的信息存储到etcd中,并且可以经过Watch接口监督Pod的变革状况,比方一个Pod被新建、删除或许更新。

                3.1.3. Service Registry

                Service Registry担任跟踪Kubernetes集群中运转的一切效劳。依据提供的Cloud Provider及Minion Registry信息把Service Registry封装成完成Kubernetes API Server需求的RESTful API接口REST。应用这些接口,我们可以对Service停止Create、Get、List、Update、Delete操纵,以及监督Service变革状况的watch操纵,并把Service信息存储到etcd。

                3.1.4. Controller Registry

                Controller Registry担任跟踪Kubernetes集群中一切的Replication Controller,Replication Controller维护着指定命量的pod 正本(replicas)拷贝,假如此中的一个容器去世失,Replication Controller会主动启动一个新的容器,假如去世失的容器规复,其会杀去世多出的容器以包管指定的拷贝稳定。经过封装Controller Registry为完成Kubernetes API Server的RESTful API接口REST, 应用这些接口,我们可以对Replication Controller停止Create、Get、List、Update、Delete操纵,以及监督Replication Controller变革状况的watch操纵,并把Replication Controller信息存储到etcd。

                3.1.5. Endpoints Registry

                Endpoints Registry担任搜集Service的endpoint,比方Name:"mysql",Endpoints: ["10.10.1.1:1909","10.10.2.2:8834"],同Pod Registry,Controller Registry也完成了Kubernetes API Server的RESTful API接口,可以做Create、Get、List、Update、Delete以及watch操纵。

                3.1.6. Binding Registry

                Binding包罗一个需求绑定Pod的ID和Pod被绑定的Host,Scheduler写Binding Registry后,需绑定的Pod被绑定到一个host。Binding Registry也完成了Kubernetes API Server的RESTful API接口,但Binding Registry是一个write-only工具,一切只要Create操纵可以运用, 不然会惹起错误。

                3.1.7. Scheduler

                Scheduler搜集和剖析以后Kubernetes集群中一切Minion节点的资源(内存、CPU)负载状况,然后依此分发新建的Pod到Kubernetes集群中可用的节点。由于一旦Minion节点的资源被分派给Pod,那这些资源就不克不及再分派给其他Pod, 除非这些Pod被删除或许加入, 因而,Kubernetes需求剖析集群中一切Minion的资源运用状况,包管分发的任务负载不会凌驾以后该Minion节点的可用资源范畴。详细来说,Scheduler做以下任务:

                1) 及时监测Kubernetes集群中未分发的Pod。

                2) 及时监测Kubernetes集群中一切运转的Pod,Scheduler需求依据这些Pod的资源情况平安地将未分发的Pod分发到指定的Minion节点上。

                3) Scheduler也监测Minion节点信息,由于会频仍查找Minion节点,Scheduler会缓存一份最新的信息在当地。

                4) 最初,Scheduler在分发Pod到指定的Minion节点后,会把Pod相干的信息Binding写回API Server。

                4.2. Kubelet

                Google开源的容器集群办理零碎Kubernetes零碎架构简介

                图3-3 Kubernetes细致构件

                依据上图3-3可知Kubelet是Kubernetes集群中每个Minion和Master API Server的衔接点,Kubelet运转在每个Minion上,是Master API Server和Minion之间的桥梁,接纳Master API Server分派给它的commands和work,与耐久性键值存储etcd、file、server和http停止交互,读取设置装备摆设信息。Kubelet的次要任务是办理Pod和容器的生命周期,其包罗Docker Client、Root Directory、Pod Workers、Etcd Client、Cadvisor Client以及Health Checker组件,详细任务如下:

                1) 经过Worker给Pod异步运转特定的Action。

                2) 设置容器的情况变量。

                3) 给容器绑定Volume。

                4) 给容器绑定Port。

                5) 依据指定的Pod运转一个单一容器。

                6) 杀去世容器。

                7) 给指定的Pod创立network 容器。

                8) 删除Pod的一切容器。

                9) 同步Pod的形态。

                10) 从Cadvisor获取container info、 pod info、root info、machine info。

                11) 检测Pod的容器安康形态信息。

                12) 在容器中运转下令。

                4.3. Proxy

                Proxy是为理解决内部网络可以拜访跨呆板集群中容器提供的使用效劳而设计的,从上图3-3可知Proxy效劳也运转在每个Minion上。Proxy提供TCP/UDP sockets的proxy,每创立一种Service,Proxy次要从etcd获取Services和Endpoints的设置装备摆设信息,或许也可以从file获取,然后依据设置装备摆设信息在Minion上启动一个Proxy的历程并监听相应的效劳端口,当内部恳求发作时,Proxy会依据Load Balancer将恳求分发到后端准确的容器处置。

                5. 下篇主题

                下篇报告在CentOS7上用Kubernetes来办理容器。

                6. 团体简介

                杨章显,现就职于Cisco,次要从事WebEx SaaS效劳运维,零碎功能剖析等任务。特殊存眷云盘算,主动化运维,摆设等技能,尤其是Go、OpenvSwitch、Docker及其生态圈技能,如Kubernetes、Flocker等Docker相干开源项目。Email: yangzhangxian@gmail.com

                7. 参考材料

                1. http://github.com/GoogleCloudPlatform/kubernetes/tree/master/docs
                2. http://www.slideshare.net/rajdeep
                3. http://www.docker.com
                持续阅读
                要害词 :
                Kubernetes
                中国存储网声明:此文观念不代表本站态度,若有版权疑问请联络我们。
                相干阅读
                产物引荐

                头条阅读
                栏目热门

                Copyright @ 2006-2019 ChinaStor.COM 版权一切 京ICP备14047533号

                中国存储网

                存储第一站,存储流派,存储在线交换平台