Service type and load balancers
1. Service type and load balancers
In addition to using environmental variables and DNS to find a Service in GKE, you can also find a Service by changing the Service type. There are three principal types of Services: ClusterIP, NodePort, and LoadBalancer. A Kubernetes ClusterIP Service has a static IP address and operates as a traffic distributor within the cluster. ClusterIP Services aren’t accessible by resources outside the cluster. Other Pods will use the ClusterIP as their destination IP address when they communicate with the Service. To create a ClusterIP Service, you need to start by creating a Service object by defining its kind in a YAML file. If a Service type isn’t specified during the creation of the Service, ClusterIP will be the default Service type. Next, a label selector can be used to choose the Pods that will run the target application. In this case, the Pods with a label of “app: Backend” are selected and included as endpoints for this Service. From there, you’ll need to specify the port that the target containers are using, for example, TCP port 6000. This means that this Service will receive traffic on port 3306 and then remap it to 6000 as it delivers it to the target Pods. By creating, loading, or applying this manifest, ClusterIP Service named “my-service” will be created. When the Service is created, the cluster control plane, which is responsible for managing the cluster's nodes and workloads, assigns a virtual IP address —also known as ClusterIP— from a reserved pool of Alias IP addresses in the cluster’s virtual private cloud. This IP address won’t change throughout the lifespan of the Service. The cluster control plane selects Pods to include in the Service’s endpoints based on the label selector on the Service and the labels on the Pods. Alright, so we’ve established that the ClusterIP Service is useful for internal communication within a cluster, but what about the external communication? This is where we look at the NodePort Service. The NodePort Service is built on top of a ClusterIP Service. This means that when you create a NodePort Service, a ClusterIP Service is automatically created in the process to distribute the inbound traffic internally across the set of Pods. So, let’s say that there’s a Service that can be reached from outside of the cluster by using the IP address of any node and the corresponding NodePort number. For this to work, we’ll say that traffic through this port would need to be directed to a Service on Port 80 and further directed to one of the Pods on port 9376. NodePort Service can be useful to expose a Service through an external load balancer that you set up and manage yourself. Using this approach, you would have to deal with node management, making sure there are no port collisions. And finally, there is the LoadBalancer Service, which also builds on the ClusterIP Service and can be used to expose a Service to resources outside the cluster. With GKE, the LoadBalancer Service is implemented using Google Cloud’s passthrough Network Load Balancer. When a LoadBalancer Service is created, GKE automatically provisions an external passthrough Network Load Balancer for inbound access to the Services from outside the cluster. Client traffic will be directed to the external IP address of the Google Cloud network load balancer, and the load balancer will forward the traffic on to the nodes for this Service. The nodes will forward that traffic to the internal LoadBalancer Service, and the LoadBalancer Service will then forward the request to one of the Pods. To create a LoadBalancer Service, you need to start by specifying the type: LoadBalancer. Google Cloud will then assign a static load balancer IP address that is accessible from outside your project. When you specify kind: Service with type: LoadBalancer in the resource manifest, GKE creates a LoadBalancer Service. GKE makes appropriate Google Cloud API calls to create either an external passthrough Network Load Balancer or an internal passthrough Network Load Balancer. GKE creates an internal passthrough Network Load Balancer when you add the networking.gke.io/load-balancer-type: Internal annotation. Otherwise, GKE creates an external passthrough Network Load Balancer.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.