3

I'm confused about the usage of the cluster external IP address.

Is this an address that can be used for ingress to access pods running on the cluster?

If so should this be the same as the control plane machine IP address (I only have a single control plane)? Or rather should it be an unused IP address on the subnet that the cluster sits? For example, if I have the below setup:

Master: 192.168.86.50 Worker 1: 192.168.86.101 Worker 2: 192.168.86.102 Worker 3: 192.168.86.103

Should the external IP address of the master be set to 192.168.86.50 or could I set it to 192.168.86.20 for example?

Also I notice the workers also can take an external IP address should these be set to the same external IP address as the master? If not say they were 192.168.86.21 192.168.86.22 and 192.168.86.23 would that mean I could reach any pod (with ingress setup) to access it on 192.168.86.20, 192.168.86.21, 192.168.86.22 and 192.168.86.23?

I've done some reading around it but I'm still struggling to grasp the concept of external IP address.

Improve this question
1
  • Yes, the External Ip address is used to expose your service that is outside your cluster. Refer: https://kubernetes.io/docs/tutorials/stateless-application/expose-external-ip-address/
    – Deepak Mourya
    Commented Dec 20, 2022 at 11:55

2 Answers 2

Reset to default
2

External IP address is used to access applications from outside, which is running inside the cluster.

Improve this answer
1

I wonder if you might be conflating multiple concepts when you say “cluster external ip”.

Each node in the cluster has (within the status information recorded by the kubernetes API server) a list of addresses that are believed to be able to be used to reach that machine. This can include internal and external ips. (External means not only useable from within pods on the cluster, so potentially public ips.)

If you have a node which you have assigned multiple static public ip addresses, you can create service resources of type ExternalIP so that traffic addressed to each of those public ip addresses will be forwarded (by kubeproxy on that node) to a different selection of pods in the cluster. (This could be slightly more user friendly than NodePort services, but it may create a bottleneck and also cause transient client errors when that node has to be swapped out e.g. for patches/upgrades. Also, public ips are a limited resource, whereas a load balancer can generally host multiple services with different external DNS hostnames through the same public ip.)

If you create a service resource of type ClusterIP, it will be assigned an ip address (and dns hostname) that is not directly reachable (except by other pods in the same cluster), necessitating some ingress/gateway for external access.

If you create a service resource of type LoadBalancer, then kubernetes will try to have your cloud provider provision a load balancer (or gateway proxy) to forward traffic to your pods, and then the service resource will be updated to note the external ip address of that particular load balancer. (However, it is typically more cost efficient to instead use an ingress controller that can configure one load balancer to be shared for multiple services.)

You would create a kubernetes service resource of type ExternalName if you want a local hostname that pods can use as an alias to refer to an externally provided service. (This allows changing where the service is hosted, without needing to reconfigure the pods that are clients of that service. However, some providers may not permit access under alternative hostnames.) It is implemented using kubedns.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.