Kubernetes 系统架构初探\简单介绍

Kubernetes 系统架构初探\简单介绍

一、前言

Together we will ensure that Kubernetes is a strong and open container management framework for any application and in any environment, whether in a private, public or hybrid cloud.

by Urs Hölzle, Google

翻译出来的意思是:

我们将一起确保Kubernetes是一个强大的和开放的容器管理框架的任何应用程序在任何环境中,无论是在私人,公共或混合云。

Kubernetes(k8s)是自动化容器操作的开源平台,这些操作包括部署,调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器,那么可以将Docker看成Kubernetes内部使用的低级别组件。
使用Kubernetes可以:

  • 自动化容器的部署和复制
  • 随时扩展或收缩容器规模
  • 将容器组织成组,并且提供容器间的负载均衡
  • 很容易地升级应用程序容器的新版本
  • 提供容器弹性,如果容器失效就替换它,等等...

熟悉Docker的伙伴们会很有感触,Docker本身非常强大,但是是在一台机器上,是集群、跨机器、自动化等功能上,需要依赖其他工具进行管理,常见的管理工具 Kubernetes\Swram\mesos ,kubernetes 放在第一位,因为可以说,2017年,是kubernetes之年,基本上他已经拿下了容器市场,但是学习Kubernetes,还是比较吃力的,因为他非常强大,so非常复杂,门槛比较高,为学习他,我买了三台云,Kubernetes中文社区,我感觉有一些太乱了,也许是版本比较多,对于入门新人去看,很容易看的一头雾水,我这里做了一些总结,下面简单的介绍一下。

二、什么是Kubernetes

kubernetes 是Google开源的容器集群管理系统,其提供应用部署、扩展机制等功能,利用kubernetes能方便的管理跨机器运行容器化的应用,其主要功能如下:

  • 使用Docker对应用程序包装(package)、实例化(instantiate)、运行(run).
  • 以集群的方式运行、管理跨平台的容器。
  • 解决Docker跨机容器之间的通讯问题。
  • Kubernetes的自我修复机制使得容器集群是运行在用户期望的状态。

接下来分两方面阐述一下Kubernetes:

  • Kubernetes的核心概念
  • Kubernetes的核心组件

三、Kubernetes的核心概念

4个核心概念:pods、services、Replication controller、labels

1)Pods
pod是kubernetes的基本操作单元,把相关的一个或多个容器构成一个pod,每一个pod中的所有容器,都运行在同一个Minion(Host)上,看作一个统一管理单元,共享volumes和network namespace/IP和port空间。
这时候,画面是:
[pods]

2)Servies
Services层是kubernetes的基本操作单元,每一个Service后面都对应很多的容器,通过Proxy的port和服务selector决定服务请求传递给后端提供服务器的容器,对外表现为一个单一接口,外部不需要了解后端如何运行的,这点对于后续升级维护,带来了很大的便利。

3)Replication Controllers
这一层,非常重要,容器宣传的自动扩容,快速扩展、删除,都是靠着他,Replication Controllers 可以确保任何时候 Kubernetes集群中指定数量的pod副本(replicas)在运行,如果少于指定数量的pod副本(replicas),Replication Controllers会启动新的Container,反之会杀死多余的以保证数量不变,Replictaion Controller 使用预先定义的pod模版,创建pods,一旦创建成功,pod模版和创建的pods没有任何关联,可以修改pod模版,而不会对已经创建的pods有任何影响,也可以直接更新通过Replication controller创建的pods,细节介绍Replication controller的主要方法:

  • Rescheduling:保证集群中指定的pod副本在运行,即使在节点出错时。(在学习安装kubertes的时候,会发现启动不起来,但是一直在反复启动[捂脸],就是这个现象)
  • Scaling:控制副本数量来水平扩展或缩小运行pods。
  • Rolling updates:Replication controller的设计原则使得可以一个一个的替换pods来实现rolling updates服务。(这个就是俗称的滚动升级,蓝绿发布)
  • Multiple release tracks:支持多版本,如果有这样的需求,Replication Controller使用labels来区分multiple releas tracks.

4)Labels
Labels是用于区分Pod、Service、Replication Controller的key/value键值对,Pod、Service、Replication Controller 可以有多个label,但是每个label的key职能对应一个value,Labels是Service和Replication controller运行的基础,为了将访问service的请求转发给后端提供的多个容器,正式通过标识容器的labels来正确选择容器。同样,也是通过labels来管理pod模版,这样Replication controller可以更加容易、方便地管理多个容器,无论有多少容器。

四、Kubernetes的核心组件

kubernetes整体框架如下图,主要包括 kubecfg 、Master API Server、Kubelet、Minion(Host)以及Proxy,还有很多细节组件,分工非常明确。

[图]
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 等组成。
[下图]
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节点上。

2)Minion Registry
Minion Registry 负责跟踪Kubernetes 集群中有多少 Minion(Host),Kubernetes 封装Minion Registry 成实现 Kubernetes API Server 的 RESTful API 接口 REST ,通过这些API,我们可以对pod进行Create、Get、List、Update、Delete操作,并将Pod的信息存储到etcd中,而且可以通过Watch接口监视Pod的变化,比如一个Pod被新建、删除或更新。

3)Pod Registry
Pod Registry 负责跟踪Kubernetes集群中有多少Pod在运行,以及这些Pod跟Minion是如何的映射关系,将pod Registry和Cloud Provider 信息及其他相关信息封装成Kubernetes API Server的RESTful API 接口REST 。 通过这些API , 我门可以对Pod进行 Cretate 、 Get、List 、Update、Delete 操作,并将 pod 的信息存储到etcd中,而且可以通过Watch 接口监视pod被新建、删除或更新。

4)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

5)Controller Registry
Controller Registry 负责跟踪Kubernetes 集群中所有的Replication Controller,Replication Controller维护着制定数量的pod副本,如果其中一个容器死掉,Replication Controller 会自动启动一个新的容器,如果死掉的容器恢复,其惠杀死多出的容器以保证制定的拷贝不变,通过封装Controller Registry 未实现Kubernetes API Server 的RESTful API 接口REST , 利用这些接口,我们可以对Replication Controller 进行 Create 、 Get 、List 、Update、Delete 炒作,并且监视 Replication Controller 的变化情况的watch操作,并把Replication Controller 信息存储到etcd。

6)Endpoints Registry
Endpoints Registry 负责收集Service 的 endponit , 比如Name:"name", Endpoints:["10.10.10.1:3333","10.10.11.1:3334"],同时Pod Registry,同Pod Registry,Controller Registry也实现了Kubernetes API Server的RESTful API接口,可以做Create、Get、List、Update、Delete以及watch操作。

7)Binding Registry
Bingding 包括一个需要绑定pod的ID和Pod被绑定的Host,Scheduler鞋Binding Registry后,需绑定的Pod被绑定到一个host。Binding Registry 也实现了Kubernetes API Server 的 ReSTful API 接口,但Binding Registry 是一个write-only对象,所以只有Create操作,可以使用,否则引起错误。

8)Scheduler
Scheduler 收集和分析当亲啊Kubernetes集群中所有Minion 节点的资源(内存、CPU)负载情况,然后依次分发,新建的pod到Kubernetes集群中可用的节点。由于一旦Minion节点的资源被分配给Pod,那这些资源就不能再分配给其他Pod,除非这些Pod被删除或者退出,因此,Kubernetes需要分析集群中所有Minio的资源使用情况,保证分发的工作负载不会超出当前Minio节点的可用资源范围。具体来说,Scheduler做以下工作:

  • 实时监测Kubernetes集群中未分发的Pod。
  • 实时监测Kubernetes集群中所有运行的Pod,Scheduler需要根据这些Pod的资源状况安全的将未分发的Pod分发到指定的Minion节点上。
  • Scheduler也监测Minion节点信息,由于会频繁查找Minion节点,Scheduler会缓存一份最新的信息在本地。
  • 最后,Scheduler在分发Pod到指定的Minion节点后,会把Pod相关信息Binding写回API Server。

Kubelet

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)在容器中运行命令。

Proxy

Proxy 是为了解决外部网络能够访问跨机器集群中容器提供的应用服务而设计的。Proxy服务也运行在每个Minion上,Proxy提供TCP/UDP sockets 的 proxy , 每创建一种Service,Proxy主要从etcd获取Services 和 Endpoints 的配置信息,或则也可以从file获取,然后根据配置信息在Minion上启动一个Proxy的进程并监听相应的服务器端口,当外部请求发生时,Proxy会根据Load Balancer 将请求分发到后台正确的容器处理。

参考资料:
http://www.infoq.com/cn/articles/Kubernetes-system-architecture-introduction
http://www.dockone.io/article/932

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,185评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,445评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,684评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,564评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,681评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,874评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,025评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,761评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,217评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,545评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,694评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,351评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,988评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,778评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,007评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,427评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,580评论 2 349

推荐阅读更多精彩内容