Docker教程六：Docker集群管理之Kubernetes
一、概念简介
Kubernetes是Google开源的容器集群管理系统。它构建Ddocker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，本质上可看作是基于容器技术的mini-PaaS平台。本文旨在梳理Kubernetes的架构、概念及基本工作流，并且通过运行一个简单的示例应用来介绍如何使用Kubernetes。
本文出自：http://blog.liuker.cn/index.php/docker/32.html
优点：
---轻量级、简单
---公有云、私有云、混合云部署
---模块化、可插拔化、可挂接、可组合
---自动恢复、自动重启、自动复制
总体概览
如下图（网上摘的，经典图）所示，基本上可以从如下三个维度来认识Kubernetes。
操作对象
Kubernetes以RESTFul形式开放接口，用户可操作的REST对象有三个：
- pod：是Kubernetes最基本的部署调度单元，可以包含container，逻辑上表示某种应用的一个实例。比如一个web站点应用由前端、后端及数据库构建而成，这三个组件将运行在各自的容器中，那么我们可以创建包含三个container的pod。
- service：是pod的路由代理抽象，用于解决pod之间的服务发现问题。因为pod的运行状态可动态变化(比如切换机器了、缩容过程中被终止了等)，所以访问端不能以写死IP的方式去访问该pod提供的服务。service的引入旨在保证pod的动态变化对访问端透明，访问端只需要知道service的地址，由service来提供代理。
- replicationController：是pod的复制抽象，用于解决pod的扩容缩容问题。通常，分布式应用为了性能或高可用性的考虑，需要复制多份资源，并且根据负载情况动态伸缩。通过replicationController，我们可以指定一个应用需要几份复制，Kubernetes将为每份复制创建一个pod，并且保证实际运行pod数量总是与该复制数量相等(例如，当前某个pod宕机时，自动创建新的pod来替换)。可以看到，service和replicationController只是建立在pod之上的抽象，最终是要作用于pod的，那么它们如何跟pod联系起来呢？这就要引入label的概念：label其实很好理解，就是为pod加上可用于搜索或关联的一组key/value标签，而service和replicationController正是通过label来与pod关联的。如下图所示，有三个pod都有label为"app=backend"，创建service和replicationController时可以指定同样的label:"app=backend"，再通过label selector机制，就将它们与这三个pod关联起来了。例如，当有其他frontend pod访问该service时，自动会转发到其中的一个backend pod。
功能组件
本文出自：http://blog.liuker.cn/index.php/docker/32.html
master运行三个组件：
apiserver：作为kubernetes系统的入口，封装了核心对象的增删改查操作，以RESTFul接口方式提供给外部客户和内部组件调用。它维护的REST对象将持久化到etcd（一个分布式强一致性的key/value存储）。
scheduler：负责集群的资源调度，为新建的pod分配机器。这部分工作分出来变成一个组件，意味着可以很方便地替换成其他的调度器。
controller-manager：负责执行各种控制器，目前有两类：
endpoint-controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。
replication-controller：定期关联replicationController和pod，保证replicationController定义的复制数量与实际运行pod的数量总是一致的。
slave(称作minion)运行两个组件：
- kubelet：负责管控docker容器，如启动/停止、监控运行状态等。它会定期从etcd获取分配到本机的pod，并根据pod信息启动或停止相应的容器。同时，它也会接收apiserver的HTTP请求，汇报pod的运行状态。
- proxy：负责为pod提供代理。它会定期从etcd获取所有的service，并根据service信息创建代理。当某个客户pod要访问其他pod时，访问请求会经过本机proxy做转发。
功能特性
将在之后慢慢融入
二、最初搭建
需要至少一个master和一个minion，为了方便以后操作，可以先定义hosts（这里只用了两台，如果做两台以上需要网络支持，参考之前Docker网络部分）
10.20.161.77 centos-master
10.20.161.88 centos-minion
1、使用yum安装【master、minion】
vim /etc/yum.repos.d/virt7-testing.repo
[virt7-testing]name=virt7-testingbaseurl=http://cbs.centos.org/repos/virt7-testing/x86_64/os/gpgcheck=0如果之前安装了docker，防止版本冲突，需要卸载之前安装的版本，安装kubernetes的时候会自动安装docker。
yum -y install --enablerepo=virt7-testing kubernetes2、关闭防火墙【master、minion】
systemctl disable iptables-services firewalld
systemctl stop iptables-services firewalld
3、修改公共配置文件【master、minion】
vim /etc/kubernetes/config
KUBE_MASTER="--master=http://centos-master:8080"
KUBE_ETCD_SERVERS="--etcd_servers=http://centos-master:4001" # 下面安装
4、安装etcd【master】
yum install http://cbs.centos.org/kojifiles/packages/etcd/0.4.6/7.el7.centos/x86_64/etcd-0.4.6-7.el7.centos.x86_64.rpm
5、修改apiserver配置文件【master】
vim /etc/kubernetes/apiserver
KUBE_API_ADDRESS="--address=0.0.0.0"
KUBE_API_PORT="--port=8080"
# KUBE_ETCD_SERVERS="--etcd_servers=http://127.0.0.1:2379" 注释掉
6、启动master相关服务（全部为active running状态则为正常，否则tail -f /var/log/messages |grep kube查看错误日志）
vim /etc/init.d/kubernetes-master
# !/bin/bashusage () { echo -en "Usage: $0 {start|stop|restart|status|enable}\n" 1>&2 exit 1}CMD="$1"if [ -z "${CMD}" ];then usagefi# For minion# for SERVICES in kube-proxy kubelet docker# For masterfor SERVICES in etcd kube-apiserver kube-controller-manager kube-schedulerdo case "${CMD}" in 'start'*) systemctl start $SERVICES ;; 'stop'*) systemctl stop $SERVICES ;; 'restart'*) systemctl restart $SERVICES ;; 'status'*) systemctl status $SERVICES ;; 'enable'*) systemctl enable $SERVICES ;; *) usage exit 1 ;; esacdone7、修改kubelet配置文件【minion】
vim /etc/kubernetes/kubelet
KUBELET_ADDRESS="--address=0.0.0.0"
KUBELET_PORT="--port=10250"
KUBELET_HOSTNAME="--hostname_override=centos-minion"
KUBELET_API_SERVER="--api_servers=http://centos-master:8080“
8、启动minion相关服务【minion】
vim kubernetes-minion
参考上面脚本修改即可。
9、minion导入根镜像pause【minion】PS：所有容器的根镜像，必备。因可能被墙，所以需要手动导入。
下载地址：http://pan.baidu.com/s/1o72tqSq
docker load )nsenter --target $PID --mount --uts --ipc --net --pid2、Debian安装nano编辑器apt-get install nano -y3、修改/var/www/html/index.html 将//netdna.bootstrapcdn.com/bootstrap/3.1.1/css/bootstrap.min.css修改为//cdn.bootcss.com/bootstrap/3.1.1/css/bootstrap.min.css将https://ajax.googleapis.com/ajax/libs/angularjs/1.2.12/angular.min.js修改为//cdn.bootcss.com/angular.js/1.2.12/angular.min.jsPS：CTRL+O回车保存，CTRL+X退出4、重启服务apache2-foreground------ 11、在利用yaml文件创建Pod过程中，报“Error from server：the server could not find the requested resource” 这个问题最坑，原因是Kubernetes版本太低，虽然node节点的状态显示是Ready，但无法创建Pod。伴随现象：在描述节点状态时，显示如下，正常的是没有红色方框部分。而且显示的版本信息如下：注意：该版本信息却与Kubernetes官方提供的yum源中的版本信息吻合：http://cbs.centos.org/repos/virt7-testing/x86_64/os/Packages/而最新的版本信息为： Kubelet Version: v1.0.3.34+b9a88a7d0e357b 问题原因： 用了CentOS自带光盘作为本地yum源，而删除了CentOS自带的网络yum源的配置文件 解决方法： 使用CentOS自带的网络yum源的配置文件。------ 12、kube-apiserver.service启动异常，查看错误日志，发现类似如下报错 Failed to list *api.Namespace: Get http://0.0.0.0:8080/api/v1/namespaces: dial tcp 0.0.0.0:8080: connection refusedFailed to list *api.LimitRange: Get http://0.0.0.0:8080/api/v1/limitranges: dial tcp 0.0.0.0:8080: connection refused解决办法：尝试单独多重启etcd试试，直至各个服务都正常。------ 13、无法创建任何资源，如发现如下报错 failed to find fit for pod redis-master-1nd8y on node centos-minion01: MatchNodeSelector解决办法：检查yaml文件是否包含nodeSelector字段，而这个字段标签是否正确设置。本文出自：[http://blog.liuker.cn/index.php/docker/32.html](http://blog.liuker.cn/index.php/docker/32.html) 六、附录 附1：解析kube-proxy之iptables 本文出自：http://blog.liuker.cn/index.php/docker/32.html当创建了service之后，就可以对内/外提供服务。那么其具体是通过什么原理来实现的呢？仔细观察node上的iptables会发现其中的奥妙。会在nat表里生成4个chainKUBE-PORTALS-CONTAINER：主要是处理所有service对象的cluster IP和port到kube-proxy本地端口的映射KUBE-PORTALS-HOST：同上类似，只不过此为针对node本地进程，上条为针对容器进程。KUBE-NODEPORT-CONTAINER：主要是处理所有service对象的NodePort类型的cluster IP和port到kube-proxy本地端口的映射KUBE-NODEPORT-HOST：同上类似，只不过此为针对node本地进程，上条为针对容器进程。以service默认的ClusterIP方式为例：创建service以后，kube-proxy会自动在集群里的node上创建以下两条规则：-A KUBE-PORTALS-CONTAINER -d 10.254.217.168/32 -p tcp -m comment --comment "default/frontend:" -m tcp --dport 80 -j REDIRECT --to-ports 45587解释：10.254.217.168是kubernetes分配给当前service的全局唯一地址，80为service定义的端口，45587为kube-proxy分配到本机的随机端口。意思是本地容器到10.254.217.168:8080的流量重定向到45587端口-A KUBE-PORTALS-HOST -d 10.254.217.168/32 -p tcp -m comment --comment "default/frontend:" -m tcp --dport 80 -j DNAT --to-destination 192.168.1.124:45587解释：本机到10.254.217.168:8080的流量重定向到45587端口如果是NodePort方式，还会额外生成两条：-A KUBE-NODEPORT-CONTAINER -p tcp -m comment --comment "default/frontend:" -m tcp --dport 30002 -j REDIRECT --to-ports 45587解释：本地容器访问本地30002端口的流量重定向到45587端口-A KUBE-NODEPORT-HOST -p tcp -m comment --comment "default/frontend:" -m tcp --dport 30002 -j DNAT --to-destination 192.168.1.124:45587解释：本地进程访问本地30002端口的流量重定向到45587端口见下图：流程解析：（以NodePort为例）1、外部访问service 192.168.1.124:30002，然后根据iptables的规则，重定向到45587。外部client启动随机端口与45587连接。tcp6 0 0 192.168.1.124:45587 192.168.1.121:35845 ESTABLISHED 13101/kube-proxy 2、kube-proxy会在本机启动一个随机端口，与service分配的pod完成连接。tcp 0 0 192.168.1.124:40614 172.18.0.9:80 ESTABLISHED 13101/kube-proxy node相当于一个反向代理的意思外部clientnodeservice(pod)------------------（以下摘自互联网）gcr.io已被墙，如果在本地用脚本在虚拟机安装，请全程翻墙。如果在服务器上就自己想办法下载，然后在配置文件中指定镜像地址。并发拉取镜像导致镜像文件破坏（https://github.com/kubernetes/kubernetes/issues/10623） 这个和docker也相关，建议先用脚本在各node上pull镜像再部署。同一个pod内的多个容器启动顺序问题 同一个pod的多个容器定义中没有优先级，启动顺序不能保证。比如kube-dns中，etcd要先启动，然后skydns连接etcd创建基本的目录，最后kube2sky启动，将kube中已经定义的数据同步到dns中。如果顺序不对dns数据就不正常。如果遇到这种问题按顺序重启一下对应的容器即可。这种问题当前需要应用自己通过重试机制解决。容器内访问外部网络 如果使用了Flannel方案，但容器内无法访问公网(node可以的情况)，一般是iptables被搞坏了(https://github.com/coreos/flannel/issues/115)。当前的Kubernetes没有应用的概念，我们的应用包含4个自己开发的服务组件，还有一些依赖（mysql,redis,mongodb等），定义下来一共要20多个yaml。要实现一键安装或者更新，还需要做不少工作。Kubernetes的公网负载均衡的解决方案依赖IaaS的实现，不够灵活。kube-proxy的性能问题，简单的压测结果如下: 10.254.2.99:80是service地址，后面有两个pod。11.1.16.15:3000是其中一个pod。代码是golang官方网站首页的那个helloword。#docker#版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
