两年前,笔者还可以轻松地部署Kubernetes应用程序,并使其在集群之外可用。现在同样的过程行不通了。更具体地说,很难从局域网访问Kubernetes应用程序和服务。
说真的,不应该这么难。
Kubernetes文档也没有什么帮助。几个月前似乎奏效的做法失败了。而且笔者遇到的每一份第三方文档都是残缺不全、过时的,或者忽略了在集群之外发布应用程序或服务所需的一些重要步骤。
这令人沮丧。
这是一个笔者过去如何做到这一点的例子,使用InluxDB时间序列数据库进行演示。
在Kubernetes控制器上,使用以下命令创建一个新的YAML文件:
1 | nano influxdb.yml |
在该文件中,粘贴以下内容:
apiVersion: v1
kind: Pod
metadata:
name: influxdb
spec:
hostNetwork: true
containers:
- name: influxdb
image: influxdb
The important bit here is:
hostNetwork: true
这里重要的一点是:hostNetwork:true
保存并关闭文件。
要部署InluxDB pod,发出以下命令:
kubectl create -f influxdb.yml
要测试InluxDB pod的外部访问,必须使用以下命令找出pod部署到哪个节点:
kubectl describe pods influxdb
在输出中,你会看到这样一行:
IP: 192.168.1.112
然后可以使用以下命令测试连接:
1 | curl -v http://IP:8086/ping |
其中IP是上面输出中打印的IP地址。
之前每次都奏效。现在不行了。
技术的发展速度远远快于我们大多数人。当像Kubernetes这样重要的技术继续进行如此关键的更改,并且无法帮助用户提供高质量的文档来简化转换时,就会出现一个大问题。这个大问题在Kubernetes上尤为明显。
对一个必须定期使用这项技术的人来说,当曾经有用的东西不再有用时,会非常令人沮丧。雪上加霜的是,目前的文件并没有缓解这种沮丧。
这就是Portainer的作用所在。笔者对这个基于web的GUI是进行容器管理的首选工具没有异议。在MicroK8s的帮助下,部署Portainer以管理Kubernetes集群变得更加容易。但这种简单性并不局限于集群的部署和基于web的GUI。在Portainer的帮助下,笔者可以部署一个应用程序,使其可以在集群外部访问,这是Kubernetes无法比拟的。
要求
要实现这一点,你需要一个正在运行的Portiner实例。最好的部署方式是通过MicroK8s:将Portiner部署到MicroK8s集群。准备好后,登录Portiner,单击本地环境,然后单击左侧导航中的应用程序。在结果窗口中,单击AddWithForm,这将带你进入一个页面,你可以快速创建一个简单的NGINX应用程序来测试它。在该页面上,选择默认命名空间,将应用程序命名为nginxtest,然后在Image字段中键入nginx。完成后,向下滚动到发布应用程序的位置(图1)。

图1:这是允许你在集群外部公开应用程序的部分。
从下拉列表中,选择NodePort,然后单击创建服务。在生成的部分中,填写以下内容:
Container Port: 80
Service Port: 80
Nodeport: 30088
完成后,向下滚动并单击部署应用程序。给应用程序一分钟左右的时间进行部署,然后打开web浏览器http://SERVER:30088(其中SERVER是托管服务器的IP地址)。如果在创建应用程序期间,将实例计数设置为3,则可以从与Kubernetes集群关联的任何IP地址访问NGINX服务器,例如:
192.168.1.70:30088
192.168.1.71:30088
192.168.1.72:30088
这就是使用Portiner在集群外公开Kubernetes应用程序的全部内容。应该这么容易,Kubernetes开发社区应该注意到这一点。事实上,使用Kubernetes是一项极具挑战性的技术,似乎只有开发人员和那些在整个工作时间都使用和管理技术的人才能真正获得这项技术。正因为如此,Kubernetes的进入壁垒是如此具有挑战性,对于那些新技术的人来说,他们总是很难启动并运行它。
然而,笔者想对那些刚接触Kubernetes的人说,跳过命令行,直接转到Portiner。