如何使用Azure Container Service Engine在Azure中国区部署容器服务（二）：Kubernetes篇

前言

在上个章节中，我们介绍了如何使用Azure Container Service Engine部署一个DCOS集群，这篇文章我们主要介绍一下如何使用acs engine在Azure中国区部署一个Kubernetes集群。

Kubernetes简介

Kubernetes是Google开源的容器集群管理系统。它构建于docker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能。下图是一张Kubernetes架构总览：

操作对象

Kubernetes以RESTful形式开放接口，用户可操作的核心对象有三个：

• pod：是Kubernetes最基本的部署调度单元，可以包含container，逻辑上表示某种应用的一个实例。比如一个web站点应用由前端、后端及数据库构建而成，这三个组件将运行在各自的容器中，那么我们可以创建包含三个container的pod。

• service：是pod的路由代理抽象，用于解决pod之间的服务发现问题。因为pod的运行状态可动态变化(比如切换机器了、缩容过程中被终止了等)，所以访问端不能以写死IP的方式去访问该pod提供的服务。service的引入旨在保证pod的动态变化对访问端透明，访问端只需要知道service的地址，由service来提供代理。

• replication controller：是pod的复制抽象，用于解决pod的扩容缩容问题。通常，分布式应用为了性能或高可用性的考虑，需要复制多份资源，并且根据负载情况动态伸缩。通过replication controller，我们可以指定一个应用需要几份复制，Kubernetes将为每份复制创建一个pod，并且保证实际运行pod数量总是与该复制数量相等(例如，当前某个pod宕机时，自动创建新的pod来替换)。

可以看到，service和replication controller只是建立在pod之上的抽象，最终是要作用于pod的，那么它们如何跟pod联系起来呢？这就要引入label的概念：label其实很好理解，就是为pod加上可用于搜索或关联的一组key/value标签，而service和replication controller正是通过label来与pod关联的。如下图所示，有三个pod都有label为”app=backend”，创建service和replication Controller时可以指定同样的label:”app=backend”，再通过label selector机制，就将它们与这三个pod关联起来了。例如，当有其他frontend pod访问该service时，自动会转发到其中的一个backend pod。

功能组件

如下图所示是官方文档里的集群架构图，一个典型的master/slave模型。

master运行三个组件：

• apiserver：作为kubernetes系统的入口，封装了核心对象的增删改查操作，以RESTful接口方式提供给外部客户和内部组件调用。它维护的REST对象将持久化到etcd（一个分布式强一致性的key/value存储）。
• scheduler：负责集群的资源调度，为新建的pod分配机器。这部分工作分出来变成一个组件，意味着可以很方便地替换成其他的调度器。
• controller-manager：负责执行各种控制器，目前有两类：
  
  • endpoint-controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。
  • replication-controller：定期关联replication controller和pod，保证replication controller定义的复制数量与实际运行pod的数量总是一致的。

slave(称作minion)运行两个组件：

• kubelet：负责管控docker容器，如启动/停止、监控运行状态等。它会定期从etcd获取分配到本机的pod，并根据pod信息启动或停止相应的容器。同时，它也会接收apiserver的HTTP请求，汇报pod的运行状态。
• proxy：负责为pod提供代理。它会定期从etcd获取所有的service，并根据service信息创建代理。当某个客户pod要访问其他pod时，访问请求会经过本机proxy做转发。

了解完kubernetes大致的结构以后，我们就可以开始部署Kubernetes集群了。

部署准备

由于国内外网络情况的差异，默认的acs engine是无法顺利在Azure中国区部署的，我们需要对源码进行少量的修改，将默认对google和docker的依赖组件镜像到国内才能顺利部署。这些修改大体上包含如下几步：

• 在Azure Active Directory中创建Service Principal，使得kubernetes在Azure上有权限动态创建负载均衡
• 修改examples/kubernetes.json集群描述文件，配置集群规模
• 修改pkg/acsengine/azureconst.go文件，让acs engine默认支持中国区
• 修改parts/kubernetesmastercustomscript.sh脚本，将Active Directory的访问地址指向中国区
• 修改acs engine源码，将Docker和kubctl的下载链接镜像到国内, 将需要从google访问的Docker镜像改到国内能够访问的地方
• 重新生成pkg/acsengine/template.go文件
• 编译acs engine

在Azure Active Directory中创建Service Principal

这个service principal的主要目的是让kubernetes有权限访问Azure，并在其中为kubernetes集群中的service创建对应的负载均衡。
1. 登录Azure经典管理门户，点击Active Directory

2. 点击选择对应的AD，进入配置主界面

3. 点击“应用程序”按钮，创建一个新的应用程序

4. 根据弹出的创建向导，创建对应的应用程序