在DR设置中使用Kubernetes的HAProxy



我们在本地托管了Kubernetes设置,并试图允许K8s之外的客户端连接到K8s集群中托管的服务。

为了使用HA代理(在K8s之外运行)实现这一点,我们有如下的HAProxy后端配置-

backend vault-backend
...
...
server k8s-worker-1 worker1:32200 check
server k8s-worker-2 worker2:32200 check
server k8s-worker-3 worker3:32200 check

现在,这个解决方案可以工作,但工作程序名称和相应的nodePort在这个配置中是硬编码的,当添加(或删除/更改)更多的工作程序时,这显然是不方便的。

我们遇到了HAProxy入口控制器(https://www.haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/)这听起来很有希望,但(我们觉得)有效地为混合物添加了另一层HAProxy。。从而增加了另一个故障点。

有没有更好的解决方案来实现这一要求?

现在,这个解决方案可以工作,但工作程序名称和相应的nodePorts在这个配置中是硬编码的,当添加(或删除/更改)更多的工作程序时,这显然是不方便的。

您可以显式地为您的Kubernetes服务配置NodePort,这样它就不会选择随机端口,并且您总是在外部HAProxy上使用相同的端口:

apiVersion: v1
kind: Service
metadata:
name: <my-nodeport-service>
labels:
<my-label-key>: <my-label-value>
spec:
selector:
<my-selector-key>: <my-selector-value>
type: NodePort
ports:
- port: <service-port>
nodePort: 32200

我们遇到了HAProxy入口控制器(https://www.haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/)这听起来很有希望,但(我们觉得)有效地为混合物添加了另一层HAProxy。。从而增加了另一个故障点。

您可以在集群内运行HAProxy入口,并在集群外删除HAProxy,但这实际上取决于您运行的服务类型。例如,Kubernetes入口是第7层资源。这里的DR将通过拥有HAProxy入口控制器的多个副本来处理。

最新更新