多个入口控制器不同区域裸机

Question

I have two-zone, each has to master node. Today I created a simple ingress-nginx controller and successfully pointed a DNS test.example.com to one of the public IP in zone-1. But now I want to create another nginx-controller in zone-2 and point test.example.com to the public IP address of that zone with cloud DNS. What approach should I take? Is there any best practice?

Answer 1

Your question is unclear and needs to be improved with any minimal reproducible example. You can find the manual here .

According to your subject, you're using Kubernetes cluster in bare-metal, however you mentioned using cloud DNS. Where did you get cloud DNS?

If you're using pure bare metal, then consider using MetalLB .

MetalLB provides a network load-balancer implementation for Kubernetes clusters that do not run on a supported cloud provider, effectively allowing the usage of LoadBalancer Services within any cluster.

But this approach has a few other limitations one ought to be aware of, one of them is about Ingress status:

• Because NodePort Services do not get a LoadBalancerIP assigned by definition, the NGINX Ingress controller does not update the status of Ingress objects it manages

$ kubectl get ingress
NAME           HOSTS               ADDRESS   PORTS
test-ingress   myapp.example.com             80

Despite the fact there is no load balancer providing a public IP address to the NGINX Ingress controller, it is possible to force the status update of all managed Ingress objects by setting the externalIPs field of the ingress-nginx Service.

Please see the example below:

Given the following 3-node Kubernetes cluster (the external IP is added as an example, in most bare-metal environments this value is )

$ kubectl get node
NAME     STATUS   ROLES    EXTERNAL-IP
host-1   Ready    master   203.0.113.1
host-2   Ready    node     203.0.113.2
host-3   Ready    node     203.0.113.3

one could edit the ingress-nginx Service and add the following field to the object spec

spec:
  externalIPs:
  - 203.0.113.1
  - 203.0.113.2
  - 203.0.113.3

which would in turn be reflected on Ingress objects as follows:

$ kubectl get ingress -o wide
NAME           HOSTS               ADDRESS                               PORTS
test-ingress   myapp.example.com   203.0.113.1,203.0.113.2,203.0.113.3   80

See more detailed info here