Google Container Engine的Kubernets实践记录

简介

本文简单介绍在Google Container Engine上如何使用Kubernets. 开始本文前，假设你已经了解kubernets相关的基本概念。

我们将在GCE上部署一个多层次包含前端后端的web程序。文中将涉及一下topics：

• 对即将部署的程序的简单介绍

• 如何在 Google Container Engine中创建Kubernetes 集群

• 通过副本控制器（Replication Controllers）部署containers 和 Pods.

• 如何测试Replication Controllers功能

• 通过部署Services 来帮助实现负载均衡

• 如何测试 Services功能

 

下图是我们最终实现的效果。不要慌张，具体细节我们稍后一 一探究。

 

示例 Web App

我们将部署如下一个程序集群：

 

这个集群中有3个前端容器运行Jetty和一个简单的web app。还有2个后端容器运行http服务和Graphviz app。Graphviz是一个强大的开源的图形可视化布局工具。图形使用DOT语言（纯文本描述语言）编辑。

你可以在容器化之前试一下这个web app。用户在前端编辑界面粘贴DOT文本后，点击【Render】按钮，就会触发Ajax请求到Jetty服务器，然后向后端graphviz服务器中请求渲染图像。最终，向用户显示svg格式的矢量图像。

我已经把前后端的程序的Docker image上传到公共Docker Registry和我的私有的Google Container Registry服务器中了。他们的源码，Dockerfile和images的组成结构描述如下：

 

Frontend (graphviz-webapp)	Backend (graphviz-server)
Source code	Source code
Dockerfile	Dockerfile
Docker image	Docker image

 

【选读】容器化模式

你可以跳过这段，但是我建议你读一读。随着容器技术的应用越来越广泛，人们对特定模式容器技术的重用来解决特定问题的需求也越来越大。想一下“四人帮”当年为软件开发设计的设计模式。你也可以问问你自己，如果怎么才能让你前端的容器镜像得到最大化的利用价值？毕竟，在这个镜像中存在着Jetty server和 WAR程序文件两大部分。这意味着每次我们更新新的war文件程序，我们就不得不build一个新的镜像。所有，最好是我们将war分离出来。从而达到重用的目的。

说到容器化模式，这里我们提个‘sidecar’模式来阐述这个和我们的示例很相似的模式。Kubernets的示例中也包含了一个sidecar的类似部署war的示例。同时还提供了文档来解释这些经典的模式。

 

创建Kubernets集群

Ok, 继续。

首先我们去google cloud console中创建一个project，然后从左侧列表中选择【Container Engine and Compute Engine services】开启。这样我们就可以使用他们的API了。然后点击右上角的【Cloud Shell】图标激活它。接下来：

首先我们设置 Compute Engine Zone. 我们用sdk的命令来列举下当前的zones：

1	gcloud compute zones list

然后选择： us-central1-a

1	gcloud config set compute/zone us-central1-a

然后创建 Kubernetes cluster：

1	gcloud container clusters create graphviz-app

默认情况下我们没有指定Node的数量和类型，这样Container Engine会使用3个VM(1 vCPU, 3.75 GB memory) 来运行在这个cluster中。

如果我们要显示的指定节点数量和类型，可以使用下面的命令：

1 2 3

gcloud container clusters create graphviz-app \ --num-nodes 1 \ --machine-type g1-small

一旦命令成功后，会显示如下信息：

这时，容器引擎已经创建了一个计算引擎集群，并在其中安装了Kubernets。整体大致结构如下：

集群中的Node现在只是简单的VM，我们可以通过cloud console看到他们的信息，也可以ssh进去：

然而，Kubernets Master是由容器引擎管理的，我们不能ssh进去。但是我们可以通过web ui访问它，后面我们会解释。如果你自己部署了一个集群，那么master和其他节点你都要进行管理。而使用GE，master节点由引擎自动为我们管理。

现在我们看一下新创建的集群的信息：

1	gcloud container clusters describe graphviz-app

显示如下：

注意在最后会看到一个用户名和密码。我们将用这个登录查看master节点的web ui界面。

 

kubectl 命令

到现在我们使用gcloud来和cluster进行了交互。由于集群设置了kubernets平台，我们现在开始用kubectl命令来交互。

1	kubectl cluster-info

显示如下：

你可以看到关于master url和一些kubernets服务相关的url。我们将使用这个URL来访问master的web界面。

这里你会问：kubectl是如何找到我们的集群的呢？

其实，kubectl会访问一个 .kube的目录，该目录在用户的home目录下。包含一个config文件。google cloud sdk已经创建好了所有相关的配置信息。

 

KubeUI – Kubernetes Web UI

现在让我访问下上面的URL吧/

 

集群的配置文件

集群配置文件包括如下yaml文件，注意，也可以使用json格式编写。

• backend-controller.yaml – Replication Controller “backend-contr” , 将部署 2 个 Pods.

• frontend-controller.yaml  – Replication Controller “frontend-contr” 将部署 3 个 Pods.

• backend-service.yaml – Service “backend-service”，后端pod的负载均衡服务.

• frontend-service.yaml – Service “frontend-service” 一个外部的负责前端的负载均衡服务来接收web请求流.

这些文件在github上可以找到：https://github.com/omerio/

 

部署Pod

首先我们checkout下yaml文件：

1 2	git clone https://github.com/omerio/kubernetes-graphviz.git cd kubernetes-graphviz

然后，通过如下命令创建后端副本控制器（以及对应会创建pod）：

1	kubectl create -f backend-controller.yaml

查看创建的控制器:

1	kubectl get rc

让我们确认下是否已经创建了后端的pod：

1	kubectl get pods -o wide

显示了我们创建的pod主机名和状态：

我们可以ssh进去看下 (10.240.0.3 或者 10.240.0.4)

1	gcloud compute ssh gke-graphviz-app-e92dffb2-node-4hnk

一旦ssh进去后，可以使用docker命令查看运行的容器服务：

1	sudo docker ps

显示我们刚刚创建的两个个容器后端程序服务：

通过查看Kube-UI面板，我们看到两个pod分别在Node1，3上面创建的。以及一些cpu内存相关信息。

进入Pod界面，会看到pod的运行状态：

同上，我们部署我们的前端副本控制器和Pod：

1	kubectl create -f frontend-controller.yaml

同样的命令查看控制器状态：

1	kubectl get rc

POD：

1	kubectl get pods -o wide

最终，我们拥有 5 个Pod。整体大致如下：

 

测试 Replication Controller

在这我们将测试一下副本控制功能，我们kill掉一个前端的docker容器，首先ssh进去其中一个node中：

1	gcloud compute ssh gke-graphviz-app-e92dffb2-node-4hnk

1	sudo docker ps

Kill：

1	sudo docker kill 23fec0b159c3

然后我们再查看下容器状态：

1	sudo docker ps

你可以看到，我们刚刚kill掉的容器不一会就被一个新的容器替换 了，现在，我们再看下pod状态：

1	kubectl get pods

我们看到，pod在17m前被控制器重启了一次。我们还可以通过控制器来【伸缩】pod。例如，我们再创建2个pod，只需简单的运行：

1	kubectl scale rc frontend-contr --replicas=5

 

部署后端服务（ Backend Service）

现在，让我们部署后端服务以便于DNS解析和后端pod间的负载均衡。在我们的前端web app容器中，jetty服务只是使用URL：“http://backend-service/svg” 来访问后端服务器。

我们希望主机名 backend-service 能够解析到可靠的后端服务IP，这样前端才能使用。

首先，我们需要部署后端服务： ‘backend-service’

1	kubectl create -f backend-service.yaml

查看下服务状态：

1	kubectl get services

让我们进入到前端的pod中，来确认前端的容器中能够正确解析主机名： ‘backend-service’.

1	gcloud compute ssh gke-graphviz-app-e92dffb2-node-v28i

1	sudo docker ps

1 2	sudo docker exec -it b96d9d24092d bash nslookup backend-service

(Note: 运行 ‘apt-get install dnsutils’ 来使用nslookup命令)

你可以看到主机名 ‘backend-service’ 已经成功解析到ip地址：10.91.245.125。

这是Kubernets服务提供的一个关键功能。

 

部署前端服务 Frontend Service

前端服务会使用一个外部的负载均衡器来处理到前端web app的请求。这是Kubernets之外的功能，是由Compute Engine创建的负载均衡。

1	kubectl create -f frontend-service.yaml

查看服务：

1	kubectl get services

我们使用命令查看下前端负载均衡服务：

1	kubectl describe services frontend

 

 

“LoadBalancer Ingress” 是外部负载均衡的ip. 然后我们在Google Cloud Console中可以看到一个网络负载均衡器已经被创建了。

测试负载均衡服务

这里我们会确认下前后端的负载均衡服务是否正常运作。所幸我们部署的程序在我们访问的时候都会打印log日志，我们可以tail这些来查看负载均衡的运行情况。下面是我们使用外部负载均衡IP地址访问前端web程序：

web界面会从其中一个pod中的程序提供：

当我点击【Render Graph】按钮，它会发送请求到后端服务, 使用url： http://backend-service/svg. Kubernets服务会将请求分配到其中一个后端pod程序中。

 

清理工作

我们用如下命令删除前端服务，它同时会删除外部的负载均衡器：

1	kubectl delete services frontend-service

最后，删除集群：

1	gcloud container clusters delete graphviz-app

 

总结

本文，我们简述了如何使用GCE部署一个多层次的web app到kubernets的集群中。

有任何问题，请留言。Twitter @omerio

原文：http://omerio.com/2016/01/02/getting-started-with-kubernetes-on-google-container-engine/