将裸机kubernetes集群暴露于互联网

时间:2019-01-14 00:12:39

标签: kubernetes juju bare-metal-server

我正在尝试在裸机专用服务器上设置自己的单节点kubernetes集群。我没有开发经验,但是我需要为自己的项目部署一些服务。我已经在juju上使用conjure-up kubernetesLXD进行了集群设置。我已经很好地运行了群集。

$ juju status

Model                         Controller                Cloud/Region         Version  SLA          Timestamp
conjure-canonical-kubern-3b3  conjure-up-localhost-db9  localhost/localhost  2.4.3    unsupported  23:49:09Z

App                    Version  Status  Scale  Charm                  Store       Rev  OS      Notes
easyrsa                3.0.1    active      1  easyrsa                jujucharms  195  ubuntu
etcd                   3.2.10   active      3  etcd                   jujucharms  338  ubuntu
flannel                0.10.0   active      2  flannel                jujucharms  351  ubuntu
kubeapi-load-balancer  1.14.0   active      1  kubeapi-load-balancer  jujucharms  525  ubuntu  exposed
kubernetes-master      1.13.1   active      1  kubernetes-master      jujucharms  542  ubuntu
kubernetes-worker      1.13.1   active      1  kubernetes-worker      jujucharms  398  ubuntu  exposed

Unit                      Workload  Agent  Machine  Public address  Ports           Message
easyrsa/0*                active    idle   0        10.213.117.66                   Certificate Authority connected.
etcd/0*                   active    idle   1        10.213.117.171  2379/tcp        Healthy with 3 known peers
etcd/1                    active    idle   2        10.213.117.10   2379/tcp        Healthy with 3 known peers
etcd/2                    active    idle   3        10.213.117.238  2379/tcp        Healthy with 3 known peers
kubeapi-load-balancer/0*  active    idle   4        10.213.117.123  443/tcp         Loadbalancer ready.
kubernetes-master/0*      active    idle   5        10.213.117.172  6443/tcp        Kubernetes master running.
  flannel/1*              active    idle            10.213.117.172                  Flannel subnet 10.1.83.1/24
kubernetes-worker/0*      active    idle   7        10.213.117.136  80/tcp,443/tcp  Kubernetes worker running.
  flannel/4               active    idle            10.213.117.136                  Flannel subnet 10.1.27.1/24

Entity  Meter status  Message
model   amber         user verification pending

Machine  State    DNS             Inst id        Series  AZ  Message
0        started  10.213.117.66   juju-b03445-0  bionic      Running
1        started  10.213.117.171  juju-b03445-1  bionic      Running
2        started  10.213.117.10   juju-b03445-2  bionic      Running
3        started  10.213.117.238  juju-b03445-3  bionic      Running
4        started  10.213.117.123  juju-b03445-4  bionic      Running
5        started  10.213.117.172  juju-b03445-5  bionic      Running
7        started  10.213.117.136  juju-b03445-7  bionic      Running

我还部署了Hello world应用程序,以在Pod内的端口8080nginx-ingress上输出一些问候,以将流量重新路由到指定主机上的该服务。

NAME                               READY   STATUS    RESTARTS   AGE
pod/hello-world-696b6b59bd-fznwr   1/1     Running   1          176m

NAME                      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/example-service   NodePort    10.152.183.53   <none>        8080:30450/TCP   176m
service/kubernetes        ClusterIP   10.152.183.1    <none>        443/TCP          10h

NAME                          READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/hello-world   1/1     1            1           176m

NAME                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/hello-world-696b6b59bd   1         1         1       176m

当我按预期进行curl localhost时,我得到了connection refused,它看起来还不错,因为它没有暴露在群集中。当我在端口kubernetes-worker/0(我从10.213.117.136获得)上使用公共地址30450卷曲kubectl get all

$ curl 10.213.117.136:30450
Hello Kubernetes!

一切都像魅力(很明显)。

curl -H "Host: testhost.com" 10.213.117.136
Hello Kubernetes!

它再次像魅力一样工作!这意味着入口控制器已根据host规则成功路由了端口80以更正服务。在这一点上,我100%确信群集可以正常工作。

现在,我正在尝试从外部通过Internet访问此服务。当我加载<server_ip>时,显然没有任何负载,因为它位于自己的lxd子网中。因此,我正在考虑将端口80从服务器eth0转发到此IP。因此,我将此规则添加到了iptables

sudo iptables -t nat -A PREROUTING -p tcp -j DNAT --to-destination 10.213.117.136(为示例起见,我们不仅路由端口80,还路由所有路由)。现在,当我在计算机http://<server_ip>上打开计算机时,它将加载!

所以真正的问题是如何在生产中做到这一点?我应该在iptables中设置此转发规则吗?是正常的方法还是骇人听闻的解决方案,而我缺少某些“标准”?事情是添加带有静态worker节点的该规则将使集群完全静态。 IP最终发生了变化,我可以为工作人员删除/添加设备,它将停止工作。我正在考虑编写脚本,该脚本将像这样从juju获取此IP地址:

$ juju status kubernetes-worker/0 --format=json | jq '.machines["7"]."dns-name"'
"10.213.117.136"

并将其添加到IP表中,这比硬编码IP更好,但我仍然觉得这很棘手,必须有更好的方法。

最后一个想法是,我可以直接在计算机上在集群外部运行HAProxy,并将流量转发给所有可用的工作程序。这最终可能也会起作用。但是我仍然不知道答案是什么correct解决方案以及在这种情况下通常使用的解决方案。谢谢!

1 个答案:

答案 0 :(得分:2)

  

所以真正的问题是如何在生产中做到这一点?

在生产系统中执行此操作的通常方法是使用Service

最简单的情况是,您只希望可以从节点上的外部访问应用程序。在这种情况下,您可以使用Type NodePort服务。这将创建必要的iptables规则,以将流量从主机IP地址转发到提供服务的pod。

如果您有一个节点(在生产中不建议这样做!),那么您现在就准备好了。

如果您的Kubernetes集群中有多个节点,则它们都将由Kubernetes配置为提供对服务的访问(您的客户端可以使用它们中的任何一个来访问服务)。不过,您必须解决以下问题:客户端将如何知道可以联系哪些节点...

有几种处理方法:

  • 使用客户端理解的协议来发布当前可用的IP地址(例如DNS)

  • 使用由Kubernetes节点上的某些软件(例如,心脏起搏器/同步)上的某些软件管理的浮动(故障转移,虚拟,HA)IP地址,并将客户端定向到该地址,

  • 使用单独配置的外部负载均衡器将流量转发到某些操作节点,

  • 使用由Kubernetes使用云提供商集成脚本(通过使用Type LoadBalancer服务)自动配置的外部负载平衡器将流量转发到某些操作节点。

    < / li>