1. 前言
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.
Urs Hölzle, Google
Kubernetes作为Docker生态圈中重要一员，是Google多年大规模容器管理技术的开源版本，是产线实践经验的最佳表现[G1] 。如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。
图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的主要构件的详细介绍：
图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
图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. 参考资料
- https://github.com/GoogleCloudPlatform/kubernetes/tree/master/docs
- http://www.slideshare.net/rajdeep
- http://www.docker.com
感谢郭蕾对本文的策划和审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。
鉴于docker如此火爆，Google推出kubernetes管理docker集群，不少人估计会进行尝试。kubernetes得到了很多大公司的支持，kubernetes集群部署工具也集成了gce，coreos，aws等iaas平台，部署起来也相当的方便。鉴于网上众多资料基于的是不少老版本，本篇文章针对最新的kubernetes及其依赖组件的部署简要阐述。通过本文可以比较粗暴的运行你的kubernetes集群，要优雅还需要更多的工作。部署主要分为三步：
1、准备机器并打通网络
如果要部署kubernetes集群至少3台机器，一个作为master两个作为minion。如果有4台机器还可以一个作为etcd服务，如果更多可以部署一个etcd集群和更多的minion，这里以4台机器为例子，这里说的机器可以是物理机也可以是kvm虚拟机。机器列表：
2、部署相关组件
kubernetes安装主要分成3部分：etcd集群、master节点和minions。
本文为了方便以4台云主机为例搭建一个kubernetes集群，云主机机器分配如下所示：
| ip | 角色 |
| 10.180.64.6 | Kubernetes master |
| 10.180.64.7 | Etcd node |
| 10.180.64.8 | Kubernetes minion1 |
| 10.180.64.9 | Kubernetes minion2 |
2.1 etcd集群
本次示例中以一台云主机作为etcd node，如需etcd集群请参照后续etcd使用介绍进行搭建。
root@cnsdev-paas-master:~# curl -L https://github.com/coreos/etcd/releases/download/v2.0.0-rc.1/etcd-v2.0.0-rc.1-linux-amd64.tar.gz-o etcd-v2.0.0-rc.1-linux-amd64.tar.gz
root@cnsdev-paas-master:~# tar xzvf etcd-v2.0.0-rc.1-linux-amd64.tar.gz
root@cnsdev-paas-master:~# cdetcd-v2.0.0-rc.1-linux-amd64
拷贝etcd下的所有可执行文件到/bin下
2.2. master节点
master节点上只涉及kubernetes安装，首先下载kubernetes执行以下指令。
root@cnsdev-paas-master:~#wget https://github.com/GoogleCloudPlatform/kubernetes/releases/download/v0.8.0/kubernetes.tar.gz
root@cnsdev-paas-master:~#tar -zxvfkubernetes.tar.gz
root@cnsdev-paas-master:~#cdkubernetes/server/kubernetes
root@cnsdev-paas-master:~#tar -zxvfkubernetes-server-linux-amd64.tar.gz
root@cnsdev-paas-master:~#cd server/bin
在master节点上将kube-apiserver、kube-controller-manager、kube-scheduler、kubecfg、kubectl拷贝到/bin
2.3. minion节点
minion节点涉及到kubernetes、cadvisor和docker的安装，master上安装是已经下载了kubernetes，将解压出的kubelet和kube-proxy拷贝到所有minion上。
在minion节点上将kubelet、kube-proxy拷贝到/bin。
（ps:拷不拷贝到/bin都无所谓，将这些可执行文件的路径加到$PATH中可以）
安装cadvisor：
root@cnsdev-paas-master:wget https://github.com/google/cadvisor/releases/download/0.7.1/cadvisor
直接是可执行文件，不用解压了，拷贝到/bin下
安装docker：
在minion上安装docker，kubernetes会调用docker api创建pod作为worker容器，同时kubernetes本身的agent线程等也可以运行在docker里面，这样kubernetes升级也会比较容易。
debian 7下安装docker可以使用ubuntu的源，运行以下指令：
root@cnsdev-paas-master:echo debhttp://get.docker.io/ubuntu docker main | sudo tee/etc/apt/sources.list.d/docker.list
root@cnsdev-paas-master:apt-key adv--keyserver keyserver.ubuntu.com --recv-keys36A1D7869245C8950F966E92D8576A8BA88D21E9
root@cnsdev-paas-master:apt-getupdate
root@cnsdev-paas-master:apt-getinstall -y lxc-docker
3、运行kubernetes集群
3.1. kubernetes配置文件
本节涉及的配置文件和在GCE上以及通过yum安装的kubernetes的配置文件不一定吻合，是全手动安装的暂时解决方案，如果已经集成到kubernetes项目下的cluster，可以运行kubernetes本身的一键部署采用salt部署整个集群，不需要手动操作，所以这里配置文件只适用于尚未被支持的平台上进行部署。所有需要的配置文件和执行脚本打包为kube-start.tar.gz。
3.1.1. etcd配置文件
etcd配置文件为cfg-etcd：
ETCD_NAME="-nameetcd-1"
etcd节点名称，如果etcd集群只有一个node，这一项可以注释不用配置，默认名称为default，这个名字后面会用到。
ETCD_PEER_ADDRESS="-initial-advertise-peer-urls http://hostip:7001"
etcd集群之间node的通讯地址，一般指定7001或者2380端口，这里etcd node的ip为10.180.64.7，所以这一项配置修改为http://10.180.64.7:7001。
ETCD_CLIENT_ADDRESS="-advertise-client-urls http://hostip:4001"
etcd node对外服务的地址，一般指定4001或者2379端口，这里修改为http://10.180.64.7:4001。
ETCD_DATA_DIR="-data-dir /home/data/etcd"
etcd存储数据的目录，自己指定，不同的目录相同的配置也会导致产生不同的etcd集群。
ETCD_LISTEN_PEER_ADDRESS="-listen-peer-urls http://0.0.0.0:7001"
etcd node监听的地址，如果为0.0.0.0将会监听所有接口，这里配置为http://0.0.0.0:7001。
ETCD_LISTEN_CLIENT_ADDRESS="-listen-client-urls http://0.0.0.0:4001"
对外服务监听地址，配置为http://0.0.0.0:4001。
ETCD_CLUSTER_MEMBERS="-initial-clusteretcd-1=http://ip_etcd-1:7001 etcd-2=http://ip_etcd-2:7001"
etcd集群成员地址的列表，因为为etcd集群内部，所以需指定7001或者2380端口，这里只有一个node，而且没有配置ETCD_NAME，那么默认名称为default，这里配置为default=http://10.180.64.7:70001。
ETCD_CLUSTER_STATE="-initial-cluster-statenew"
etcd集群状态，new表示新建一个集群，existing表示已经存在。
ETCD_ARGS=""
需要额外添加的参数，可以自己添加，etcd的所有参数可以通过etcd -h查看。
3.1.2. kubernetes集群配置文件
cfg-common：
KUBE_ETCD_SERVERS="--etcd_servers=http://10.180.64.7:4001"
etcd服务地址，前面已经启动了etcd服务，这里配置为http://10.180.64.7:4001。
KUBE_LOGTOSTDERR="--logtostderr=true"
表示错误日志记录到文件还是输出到stderr。
KUBE_LOG_LEVEL="--v=0"
日志等级。
KUBE_ALLOW_PRIV="--allow_privileged=false"
允许运行特权容器。
3.1.3. apiserver配置文件
cfg-apiserver：
KUBE_API_ADDRESS="--address=0.0.0.0"
监听的接口，如果配置为127.0.0.1则只监听localhost，配置为0.0.0.0会监听所有接口，这里配置为0.0.0.0。
KUBE_API_PORT="--port=8080"
apiserver的监听端口，默认8080，不用修改。
KUBE_MASTER="--master=10.180.64.6:8080"
apiserver的服务地址，controller-manager、scheduler及kubelet都会用到这个配置，这里配置为10.180.64.6:8080
KUBELET_PORT="--kubelet_port=10250"
minion上kubelet监听的端口，默认10250，无需修改
KUBE_SERVICE_ADDRESSES="--portal_net=10.254.0.0/16"
kubernetes可以分配的ip的范围，kubernetes启动的每一个pod以及serveice都会分配一个ip地址，将从这个范围分配。
KUBE_API_ARGS=""
需要额外添加的配置项，简单地启用一个集群无需配置。
3.1.4. controller配置文件
cfg-controller-manager：
KUBELET_ADDRESSES="--machines=10.180.64.8,10.180.64.9"
kubernetes集群中minion的列表，这里配置为10.180.64.8,10.180.64.9
KUBE_CONTROLLER_MANAGER_ARGS=""
需要额外添加的参数
3.1.5. scheduler配置文件
cfg-schedule：
如果需要额外参数可以自行添加，这里暂时不添加新的参数。
3.1.6. kubelet配置文件
cfg-kubelet：
KUBELET_ADDRESS="--address=10.180.64.8"
minion监听的地址，每个minion根据实际的ip配置，这里minion1上为10.180.64.8，minion2上为10.180.64.9。
KUBELET_PORT="--port=10250"
监听端口，不要修改，如果修改，同时需要修改master上配置文件中涉及的配置项。
KUBELET_HOSTNAME="--hostname_override=10.180.64.8"
kubernetes看到的minion的名称，使用kubecfglist minions时看到的将是这个名称而不是hostname，设置和ip地址一样便于识别。
KUBELET_ARGS=""
额外增加的参数
3.1.7. proxy配置文件
cfg-proxy：
如有额外参数自行配置，这里不需要添加。
3.2. kubernetes启动
将kube-start.tar.gz解压，拷贝cfg-etcd、kube-etcd到etcd node上，为kube-etcd增加可执行权限。拷贝其中的cfg-common、cfg-apiserver、cfg-controller-manager、cfg-schedule、apiserver、controller、schedule拷贝到master上，为apiserver、controller和schedule增加可执行权限。拷贝cfg-common、cfg-kubelet、cfg-proxy、cadv、kube、proxy到所有minion主机上，同时确保每一个minion的cfg-kubelet修改正确，为cadv、kube、proxy增加可执行权限。
首先在etcd node上运行etcd服务，执行
root@cnsdev-paas-master:./kube-etcd &
检验etcd是否正常，在master上执行
root@cnsdev-paas-master:curl -L http://10.180.64.7:4001/version
etcd 2.0.0-rc.1
然后在master上顺序执行
root@cnsdev-paas-master:./apiserver&
root@cnsdev-paas-master:./controller &
root@cnsdev-paas-master:./schedule &
最后在所有的节点上顺序执行
root@cnsdev-paas-master:./cadv &
root@cnsdev-paas-master:./kube &
root@cnsdev-paas-master:./proxy &
所有组件都运行之后，到master上检测下状态。
查看下集群状况
root@cnsdev-paas-master:~# kubecfg listminions
Minionidentifier Labels
---------- ----------
10.180.64.9
10.180.64.8
可以看出集群中有两个节点10.180.64.8和10.180.64.9，正是部署的2个节点。
查看当前集群的pod
root@cnsdev-paas-master:~#kubecfg list pods
Name Image(s) Host Labels Status
---------- ---------- ---------- ---------- ----------
e473c35e-961d-11e4-bc28-fa163e8b5289 dockerfile/redis 10.180.64.9/ name=redisRunning
这里的redis你就当没看见，如果刚创建的集群这个时候是没有pod的，当然如果你是在gce或者aws上一键创建的，默认可能会看到kubernetes命名的pod，这是默认启动的状态监测的东东。
集群已经创建好了，那就来创建个tomcat的replicationController玩玩吧。有多种接口方式可以实现这个，这里选择json，需要写一个tomcat-controller.json的文件告诉kubernetes该怎么创建这个controller。当然文件的名字可以随意点，只要能看懂就行。tomca-controller.json大概长这个样子：
{
"id":"tomcatController",
"kind":"ReplicationController",
"apiVersion":"v1beta1",
"desiredState": {
"replicas": 2,
"replicaSelector":{"name":"tomcatCluster"},
"podTemplate":{
"desiredState": {
"manifest": {
"version": "v1beta1",
"id": "tomcat",
"containers": [{
"name": "tomcat",
"image":"tutum/tomcat",
"ports":[{
"containerPort":8080,"hostPort":80}
]
}]
}
},
"labels": {"name":"tomcatCluster"}}
},
"labels": {
"name":"tomcatCluster",
}
}
里面各项值的含义看完kubernetes实现分析之后就会明白了。写好文件之后就让kubernetes执行吧。
root@cnsdev-paas-master:/home/pod# kubecfg -ctomcat-pod.json create replicationControllers
如果告诉你success，那么可以查看下集群的controller
root@cnsdev-paas-master:/home/pod# kubecfg listreplicationControllers
Name Image(s) Selector Replicas
---------- ---------- ---------- ----------
redisController dockerfile/redis name=redis 1
tomcatController tutum/tomcat name=tomcatCluster 2
请无视redis，这时候看到tomcat的replicationController已经起来了，Replicas=2表示要在集群里面运行2个docker，docker运行的镜像就是tutum/tomcat了，如果你的minion上面没有这个镜像那么kubernetes就要去docker hub上为你下载了，如果本地有这个镜像那么kubernetes就直接在minion上为你运行2个tomcat的container（pod），来看看这一切是不是真的。
root@cnsdev-paas-master:/home/pod# kubecfg listpods
Name Image(s) Host Labels Status
---------- ---------- ---------- ---------- ----------
643582db-97d1-11e4-aefa-fa163e8b5289 tutum/tomcat 10.180.64.9/ name=tomcatCluster Running
e473c35e-961d-11e4-bc28-fa163e8b5289 dockerfile/redis 10.180.64.9/ name=redis Running
64348fde-97d1-11e4-aefa-fa163e8b5289 tutum/tomcat 10.180.64.8/ name=tomcatCluster Running
2891
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
