loader

    Knowledge Base

    Setting up load balancing with Ingress and Service resources

    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]