Google Container Engine的Kubernets实践记录

简介

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

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

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

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

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

  • 如何测试Replication Controllers功能

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

  • 如何测试 Services功能

 

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

Kubernetes Google Container Engine Cluster

 

示例 Web App

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

Graphviz-app Cluster

 

这个集群中有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 codeSource code
DockerfileDockerfile
Docker imageDocker 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

一旦命令成功后,会显示如下信息:

Cluster created

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

Graphviz-app Container Engine Cluster

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

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

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

1

gcloud container clusters describe graphviz-app

显示如下:

Screen Shot 2016-01-01 at 23.11.48

注意在最后会看到一个用户名和密码。我们将用这个登录查看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吧/

kube-ui

 

集群的配置文件

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

这些文件在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。整体大致如下:

Graphviz-app Container Engine Cluster

 

测试 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/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小涵

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值