使用场景

  在kubernetes成为容器服务编排方案“标准”的今天，谈自动化运维就不能离开k8s，现在操作k8s有多种方式，集群外面k8s client通过kubeconfig配置文件连接k8s集群，通过k8s 暴露的apiserver服务操作k8s。通过暴露helm的服务service/tiller-deploy来操作k8s 等。k8s client和helm Client对于手工部署确实方便，但当应用程序量大的时候，通过手工来部署显然不够。通过apiserver的restfull形式的api来部署我们的应用确实可行，但k8s的相关配置文件非常多，通过apiserver这种原始的api来管理有很多的问题：难管理，不能重用，缺少依赖管理等，所以我们会引用helm来发布我们的应用,helm的服务端service/tiller-deploy也提供了grpc的接入方式，helm的客户端也就是使用了这种接入方式提交任务给到服务端的。但是它是helm的客户端是手工操作的，如何用程序来驱动tiller-deploy服务呢？这就是我们这次想要解决的问题。

一个示例

duckula是一个监听binlog的中间件，它可以通过界面（ops）配置任务并启动binlog监听任务，当然也要查看到所有任务的运行状态。它支持k8s方式的部署，如图：

那么它就必须在程序中能操控k8s部署任务并查看它的相关状态。它是如何做到的呢？

操作k8s的工具

来源

我当初要实现duckula的上述功能的时候最开始是想通过apiserver直接怼的，但接触helm后就直接放弃了这个想法，于是又想着研究helm的tiller-deploy提供的grpc服务，最后本着拿来主义在github一通找，找到了 https://github.com/microbean/microbean-helm项目，但这个项目好像不太活跃，用的时候并不能完全满足我的需求，于是在这个项目上做了一定的改造。最后变成了common-kubernetes工具项目：https://gitee.com/rjzjh/common/tree/master/common-kubernetes，上面那个duckula示例就是使用这个东东完成了需求。下面就是来说明如何使用这个jar包。

使用依赖

通过maven引入：

<!-- https://mvnrepository.com/artifact/net.wicp.tams/common-kubernetes -->
<dependency>
    <groupId>net.wicp.tams</groupId>
    <artifactId>common-kubernetes</artifactId>
    <version>最后版本</version>
</dependency>

配置

看看它支持的配置项：

#tiller
common.kubernetes.tiller.serverip=null
common.kubernetes.tiller.port=null
common.kubernetes.tiller.version=v2.9.1

#kubernetes
common.kubernetes.apiserver.master.url=null
common.kubernetes.apiserver.master.username=null
common.kubernetes.apiserver.master.password=null
common.kubernetes.apiserver.namespace.default=default

tiller.serverip: 连接的tiller-deploy的地址，这个服务部署在k8s集群内部，它部署在kube-system名称空间下的一个名为tiller-deploy service，它是一个grpc服务，如果在k8s集群外面想要连接到它，那么需要k8s暴露这个service的端口（nodeport等方式），如果你想在k8s集群外部开发调试用，建议使用port-forward来做一次转发：kubectl port-forward service/tiller-deploy 44134:44134 -n kube-system ，不过前提是你已经正确的配置好了kubeconfig文件并安装好了k8s client，总之就是你在本机能通过kubectl命令操作k8s集群了，那么你这个地址就可以配置为 localhost。 如果在集群内部访问，则可以用这个地址：tiller-deploy.kube-system 。

tiller.port：就是要连接这台服务器上的端口，默认为44134

如果你想要通过apiserver方多连接k8s集群可能设置下面属性

master.url: 示例如：https://192.168.18.242:6443

master.username：连接用户名

master.password：连接密码

namespace.default：连接成功后默认的命名空间

如果上面的配置都没有，那么也不用担心，依赖包会使用你本机kubeconfig在用的context进行连接，如：

连接tiller服务

有了这个配置后，我们需要把它们加载到内存的配置中心中，请参考：内存配置中心 章节。现在试试查看状态：

import java.util.Map;
import java.util.Properties;

import common.kubernetes.constant.ResourcesType;
import common.kubernetes.tiller.TillerClient;
import net.wicp.tams.common.Conf;
import net.wicp.tams.common.apiext.IOUtil;

public class TestChart {
	private void init() {
		Properties props = IOUtil.fileToProperties("k8s.properties", TestChart.class);
		Conf.overProp(props);
	}

	private void queryStatus() {
		Map<ResourcesType, String> queryStatus = TillerClient.getInst().queryStatus("t-demo");
		String valueStr = queryStatus.get(ResourcesType.Pod);
		String statusstr = ResourcesType.Pod.getColValue(valueStr, "STATUS");
		System.out.println("STATUS=" + statusstr);
	}

	public static void main(String[] args) {
		TestChart testChart = new TestChart();
		testChart.init();
		testChart.queryStatus();
	}
}

打印：“STATUS=Running” ，那再看看这个pod状态如何:

正是我们想要的状态。

部署应用服务

我们连接上tiller当然不是简单地查询一个状态就完事了，还想要做更复杂的事，如部署我们的应用，不要的时候删除我们的部署，甚至更改我们的配置，一句话，只要helm client能干的，我们都要求它来干。下面就来看看更复杂一点的部署动作(install)：

private void install() {
		List<Object> userList = new ArrayList<>();
		userList.add("env.taskid");
		userList.add("demo");
		Object[] userConfig = userList.toArray(new Object[userList.size()]);
		Result installDirChart = TillerClient.getInst().installDirChart("demo-test", "default",
				"D:\\source\\zjh\\duckula\\duckula-install\\k8s\\duckula_task", "values-test.yaml", userConfig);
		System.out.println(installDirChart.isSuc());
	}

installDirChart参数介绍：

demo-test：　　你要安装到k8s的名字，相当于　helm install --name=demo-test

default: 　　要安装的命名空间,相当于　helm install --namespace=default

D:\…\duckula_task chart包的本地路径，也就是要把这个chart包安装到k8s

values-test.yaml 要安装的默认配置项，相当于 helm install -f values-test.yaml，注意：这个参数可以为空或不填，默认为values.yaml，这个参数原来的microbean-helm项目是没有的，我扩展的一个特性参数。

userConfig: 值要被覆盖的项，相当于 helm install --set env.taskid=“demo”

删除部署

删除部署非常简单（相当于helm delete t-demo --purge）：

private void delete() {
		Result deleteChart = TillerClient.getInst().deleteChart("t-demo");
		System.out.println(deleteChart.isSuc());
	}

还有些其它的特性方法一起去探索吧。