Access external service from Kubernetes with consistent IP address-CodePudding

I've set up a service and some pods in an AWS Elastic Kubernetes Service (EKS) cluster which access a RabbitMQ message service and PostgreSQL database hosted externally to the cluster. At the moment, I've opened up via AWS security groups access from all IPs (0.0.0.0/0) to these services as kubernetes assigns an IP for each node when it is created.

Ideally, I'd like to route traffic from Kubernetes to these services via one consistent "external Kubernetes IP" so I can add it in to each external services security group. Currently, from Googling around I haven't found a way to do this, is it possible?

For RabbitMQ I have the current Service and Endpoint set up, but I believe this is only for routing traffic through the Kubernetes cluster and not related to the external facing side of my cluster?

kind: Service
metadata:
  name: rabbitmq-service
spec:
  selector:
    app: job-wq-1
  ports:
    - port: 15672
      targetPort: 15672
      name: management-port
    - port: 5672
      targetPort: 5672
      name: data-port
  type: LoadBalancer
---
kind: Endpoints
apiVersion: v1
metadata:
  name: rabbitmq
subsets:
- addresses:
  - ip: 'rabbitmq.server.public.ip'
  ports:
  - port: 15672
    name: 'management-port'
  - port: 5672
    name: 'data-port'

CodePudding user response：

Do you mean the IP for the outgoing traffic?

If you're trying to create a LoadBalancer Service with a static external IP, you can use the loadBalancerIP field to use a reserved IP, such as an AWS Elastic IP.

https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer

CodePudding user response：

Yes it is possible, but it is not simple.

What would you have to do is route your outbound traffic from the cluster through either a VPC Gateway, NAT Gateway, or some other EC2 instance whose purpose will be to act as a NAT. That instance can then be given a static IP which you can then whitelist at the destination (so no need to use 0.0.0.0/0)

We use a similar setup in GKE to allow us to spin up a GKE Cluster, run a workload in that, but have a known fixed IP the remote server will recognise and allow to connect.