Answers: <p>External IP address is used to access applications from outside, which is running inside the cluster.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-11-17T07:34:15.083Z
Answers: 2022-11-17T07:34:15.083Z
Answers: Nitor Infotech
Answers: <p>I wonder if you might be conflating multiple concepts when you say “cluster external ip”.</p>
  <p>Each node in the cluster has (within the status information recorded by the kubernetes API server) a list of <a href="https://kubernetes.io/docs/concepts/architecture/nodes/#addresses" rel="nofollow noreferrer">addresses</a> that are believed to be able to be used to reach that machine. This can include internal and external ips. (External means <em>not only</em> useable from within pods on the cluster, so potentially public ips.)</p>
  <p>If you have a node which you have assigned multiple static public ip addresses, you can create service resources of type <strong>ExternalIP</strong> 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.)</p>
  <p>If you create a service resource of type <strong>ClusterIP</strong>, it will be assigned an ip address (and dns hostname) that is <em>not</em> directly reachable (except by other pods in the same cluster), necessitating some ingress/gateway for external access.</p>
  <p>If you create a service resource of type <strong>LoadBalancer</strong>, 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.)</p>
  <p>You would create a kubernetes service resource of type <strong>ExternalName</strong> 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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-12-23T21:09:05.090Z
Answers: 2022-12-28T22:22:02.887Z
Answers: 2022-12-28T22:22:02.887Z
Answers: benjimin
Body: <p>I'm confused about the usage of the cluster external IP address.</p>
  <p>Is this an address that can be used for ingress to access pods running on the cluster?</p>
  <p>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:</p>
  <pre><code>Master: 192.168.86.50 Worker 1: 192.168.86.101 Worker 2: 192.168.86.102 Worker 3: 192.168.86.103
  </code></pre>
  <p>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?</p>
  <p>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?</p>
  <p>I've done some reading around it but I'm still struggling to grasp the concept of external IP address.</p>
  
Comments: CC BY-SA 4.0
Comments: 2022-12-20T11:55:10.663Z
Comments: 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/```
Comments: Deepak Mourya
Tags: <kubernetes><networking>
Title: What is the usage of the cluster external IP address?
UserDisplayName: Daniel Wood
ThreadText: # What is the usage of the cluster external IP address?
  
  (Asked by: username_0 on 2022-09-10)
  
  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.
  
  **Tags:** kubernetes, networking
  
  > **Comments:**
  > **username_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/```  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2022-11-17. Score: 2
  
  External IP address is used to access applications from outside, which is running inside the cluster.
  
  
  ---
  
  ### Answer by username_3 on 2022-12-23. Score: 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](https://kubernetes.io/docs/concepts/architecture/nodes/#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.
  
  
  ---
  
  