In the language of Kubernetes, a pod is a deployment unit that can refer to a single container or tightly coupled containers with shared resources. Microservices are deployed as a set of pods that are created and destroyed dynamically. That means the set of pods that refer to a microservice is constantly changing.
Kubernetes provides services that define a logical set of pods, as well as policies to access them. These services can be used to expose microservices both inside and outside the cluster. There are three primary types of services you can use: ClusterIP, NodePort, and LoadBalancer. Each provides a different paradigm through which services are exposed.
In this blog, we’ll look at service of type LoadBalancer and how it can be used to provision an external load balancer on the Tier 1 Citrix ADC (VPX, MPX) on bare-metal clusters. This can be achieved using Citrix ingress controller and the Citrix IPAM controller. We’ll also cover the difference between service of type LoadBalancer and ingress; support in cloud vs. on-prem deployments; and some upcoming enhancements.
Service of Type LoadBalancer
Service of type LoadBalancer in Kubernetes enables you to directly expose services to the outside world without using an ingress resource. It’s generally made available only by cloud providers, who spin up their own native cloud load balancers and assign an external IP through which the service can be accessed. This helps users to deploy microservices easily and expose them to the outside world.
By default, in a bare metal cluster, service of type LoadBalancer simply exposes NodePorts for the service. It doesn’t configure external load balancers.
The Citrix ingress controller watches the kubernetes api server and configures the ingress device — the Citrix ADC — whenever changes occur. Beginning with version 1.2.0, the Citrix ingress controller supports service of type LoadBalancer on bare-metal clusters, as well. If such a service is created in the cluster, the Citrix ingress controller will automatically configure the service on the external load balancer in the Tier 1 Citrix ADC, and you can access the service using the external IP. The Citrix ingress controller allocates this IP to the LoadBalancer service with the help of the Citrix IPAM controller, an auxiliary pod that runs parallel to the Citrix ingress controller and is responsible for managing IP addresses.
How the Citrix IPAM Controller Works
The Citrix IPAM controller pod runs in the cluster and is responsible for managing IP addresses. At start up, the IP address ranges pass through the yaml file to the Citrix IPAM controller, which uses them to allocate IPs to each load balancer service on that cluster. The deployment architecture is shown below:
The Citrix IPAM controller also requires vip CRD to be installed because it’s used for internal communication between the Citrix ingress controller and the Citrix IPAM controller.
Once the service is deployed in the cluster, the Citrix ingress controller creates a vip CRD object for that service. The Citrix IPAM controller allocates IPs to the vip CRD objects. These CRD objects are then consumed by the Citrix ingress controller for configuring the VPX. The IP address allocated by the Citrix IPAM controller is used to access the service from outside.
The Citrix ingress controller, along with Citrix IPAM controller, provides an end-to-end solution for service of type LoadBalancer in a on-prem Kubernetes cluster. There, it can take care of IP management and configuration of the external load balancer.
Extending the Support of Service of Type LoadBalancer
You can deploy Citrix ingress controller along with the Citrix IPAM controller in a multi-cluster topology. Here’s an example of a multi-cluster deployment (click to see the image larger):
You can configure the multi-cluster case using the environment variable NS_APPS_NAME_PREFIX which can be provided to the Citrix ingress controller through yaml while deployment. This variable allows differentiating configurations produced by Citrix ingress controllers in different clusters in a shared Tier 1 ADC.
You also need to run the Citrix IPAM controller in all the clusters and ensure that, in each cluster, the input IP ranges provided are mutually exclusive to each other. Any overlap in IP ranges might make the service unreachable.
Support in Cloud vs. On-Prem Deployments
In cloud environment, service type LoadBalancer is handled by the cloud infrastructure itself and nothing else is required.
When running service of type LoadBalancer in bare metal clusters, you need to provide the IP by running the Citrix IAPM controller with vip range and run the Citrix ingress controller with the –ipam=”citrix-ipam-controller” option and deploy the vip CRD. Only then will the service of type LoadBalancer be configured properly.
Ingress vs. service of type LoadBalancer
Ingress and service of type LoadBalancer both enable you to expose services to the outside world. Ingress offers a very powerful solution through which you can use both path-based and subdomain-based routing to back-end services. For example, you can send everything on www.example.com/foo to the foo service, and everything under the www.example.com/bar path to the bar service. You can’t do that with service of type LoadBalancer.
But service of type LoadBalancer does give you an easy way to spin up a service, simply by using the service yaml itself. And you don’t have to worry about IP management, making it a breeze to spin up services and test them during development.
Keep in mind, though, that these services will have no routing. Additionally, each service you expose as type LoadBalancer will get its own IP address, which might cause problems because of limited resources for IPs.
Service of Type LoadBalancer: An Example Deployment
Here’s how to deploy a service of type LoadBalancer. The related yamls can be found here.
- Deploy vip.yaml to create the VIP crd
kubectl create -f vip.yaml
- Deploy cic-vpx.yaml with –ipam=citrix-ipam-controller passed as argument
kubectl create -f cic.yaml
- Deploy the ipam_deploy.yaml file to run ipam controller
Update the appropriate routable IP range with a valid CIDR in ipam_deploy.yaml for example:
– name: “VIP_RANGE”
value: ‘[“10.217.212.18/31”]’
kubectl create -f ipam_deploy.yaml
- Create any service of type LB, service used here is a sample app
kubectl create -f hot_drink.yaml
The gif below provides shows the steps above and the expected outcome of deploying the service of type LoadBalancer.
The service of type LoadBalancer is available to use after the pods are up and running. You can view the service with ‘kubectl get svc’ and test it using curl <external IP>.
What’s Next?
Learn more about the service of type LoadBalancer feature and the Citrix IPAM controller. And keep an eye out. We’re planning to integrate Citrix ingress controller’s service of type LoadBalancer functionality with other externally available IP management implementations to provide more flexibility in the future. We also plan to make the Citrix IPAM controller functionality available for ingress and to make managing IPs easier.
Citrix Tech Bytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.
Click here for more Tech Bytes and subscribe.
Want specific Tech Bytes? Let us know! tech-content-feedback@citrix.com.
