Setting up load balancing with Ingress and Service resources

The Servers.com ingress controller is available only for the 1.24.16 Kubernetes cluster versions and lower. If you have the 1.26.9 version and higher, use a third-party's one as described in this instruction.

In Kubernetes, a Service is an abstraction which defines a logical set of Pods and a policy by which to access them (sometimes this pattern is called a micro-service). Service allows exposing an application running on a set of Pods as a network service by setting service type.

You can also use Ingress to expose your Service. Ingress is not a service type, but it acts as the entry point for your cluster. It lets you consolidate your routing rules into a single resource as it can expose multiple services under the same IP address.

Servers.com offers integrated support for two types of load balancing to make a Service (ie application) publicly accessible:

• TCP load balancing for Service objects;

• HTTP(S) load balancing for Ingress resources.

Enabling TCP load balancing for a Service object

As already mentioned, Service allows exposing an application running on a set of Pods as a network service by setting service type. The 'type' value can be one of the following:

• ClusterIP (default),

• NodePort,

• LoadBalancer,

• ExternalName.

On the Servers.com platform, setting the 'type' value of a Service object to 'LoadBalancer' cause an L4 (TCP) load balancer to be provisioned for such Service. An actual load balancer instance is not part of your cluster and is provisioned outside of the cluster by the cloud-controller-manager. The cloud-controller-manager is a Kubernetes control plane component and it is provisioned with the cluster.

When you create a Service object of the LoadBalancer type in your cluster, the Servers.com's cloud-controller-manager implementation creates a load balancer instance and configures it to route traffic to your application. 

IP address and fees associated with load balancing

The actual creation of the load balancer happens asynchronously, and information about the provisioned balancer and its IP address is pushed back into the '.status.loadBalancer' field of a Service object. When created automatically for a Service object, the load balancer is set up with an ephemeral IP address. Once the Service object is destroyed, its IP address is returned to the shared pool, and will eventually be assigned to another object.

For each Service object with the 'type' field set to LoadBalancer, fees associated with a Load Balancer instance are applicable.

Service example

---
apiVersion: v1
kind: Service
metadata:
  name: hello-world-svc
  annotations:
    servers.com/service.proxy-protocol: "false"
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: hello-world-app
  type: LoadBalancer

Annotations specific to the Servers.com's cloud-controller-manager

servers.com/service.proxy-protocol

Description: Enables/disables the PROXY protocol on a load balancer. The PROXY protocol enables applications to receive client connection information passed through a load balancer. The information passed via the PROXY protocol is the client IP address, the load balancer IP address, and both port numbers.

Type: stringified boolean ( "false", "true" )

Default: "false"

Enabling HTTP(S) load balancing for an Ingress resource

Ingress is a Kubernetes resource that encapsulates a collection of rules and a configuration for routing external HTTP(S) traffic to internal Services.

For the Ingress resource to work, the cluster must have an ingress controller running. On the Servers.com platform, Ingress is implemented around the Load Balancing service. The Ingress controller is provisioned with the cluster.

When you create an Ingress resource in your cluster, the Servers.com's Ingress controller creates a load balancer instance and configures it to route traffic to your application based on the Ingress resource configuration.

The class name for the Servers.com's Ingress controller

When creating an Ingress, you should annotate each Ingress with the appropriate 'ingress.class' to indicate which ingress controller should be used.

The "kubernetes.io/ingress.class" annotation should be set to "serverscom" for the Servers.com controller to be used.

Service types compatible with the Servers.com's Ingress controller

Since the load balancer instance backing an Ingress resource is provisioned outside of the cluster, it can't access services by their cluster-internal IPs. Thus the 'type' value for a Service annotation has to be NodePort or LoadBalancer for the service to be accessible via an Ingress resource.

IP address and fees associated with load balancing

The actual creation of the load balancer happens asynchronously, and information about the provisioned balancer and its IP address is pushed back into the '.status.loadBalancer' field of an Ingress resource object. The load balancer is provisioned outside the cluster and set up with an ephemeral IP address. Once the Ingress resource is removed, its IP address is returned to the shared pool, and will eventually be assigned to another object or resource.

For each Ingress resource, fees associated with a Load Balancer instance are applicable.

Ingress example

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: hello-world-ingress
  annotations:
    kubernetes.io/ingress.class: "serverscom"
    servers.com/ingress.load-balancer-healthcheck-path: "/healthz"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: hello-world-svc
          servicePort: 80

Annotations specific to the Servers.com's Ingress controller

servers.com/ingress.load-balancer-healthcheck-path 

Description: Sets the healthcheck path for the Ingress-resource-backing load balancer. See the "Healthcheck URI" section in the documentation for the Load Balancing service.

Type: string, uri path

Default: /healthz

servers.com/ingress.load-balancer-geo-ip

Description: Enables/disables GeoIP headers for the Ingress-resource-backing load balancer. See the "GeoIP headers injection" section in the documentation for the Load Balancing service.

Type: stringified boolean ( "false", "true" )

Default: "false"

servers.com/ingress.load-balancer-redirect-http

Description: Enables/disables redirection of HTTP to HTTPS for the Ingress-resource-backing load balancer. See the "SSL termination & Forwarding rules" section in the documentation for the Load Balancing service.

Type: stringified boolean ( "false", "true" )

Default: "false"

ingress.kubernetes.io/load-balancer-status

Description: This annotation is used to record debug information on the Load balancer current status. The value is overwritten by the Ingress controller.  [1]

Suggested Articles