Creating Load Balancers in OKS

You can give customers open access to your clusters using OKS load balancers. An OKS load balancer is a Kubernetes cluster entry that is responsible for detecting load balancer creation requests in the manifests that are applied to a cluster, creating the corresponding Load Balancing Unit (LBU), and attaching the newly created LBU to your cluster. OKS load balancers support the TCP/SSL and HTTP/HTTPS protocols.

For more information about load balancers, see About Load Balancers.

Creating a Load Balancer

To create a load balancer, you have to attach the required annotations to your manifests.

In the following example, we will create a basic load balancer granting HTTPS access to the resources on the cluster.

Manifest Sample

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoheaders
  namespace: default
  labels:
    app: echoheaders
spec:
  replicas: 1
  selector:
    matchLabels:
      app: echoheaders
  template:
    metadata:
      labels:
        app: echoheaders
    spec:
      containers:
      - name: echoheaders
        image: gcr.io/google_containers/echoserver:1.10
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
          protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: echoheaders-lb-public
  namespace: default
  labels:
    app: echoheaders
  annotations:
    service.beta.kubernetes.io/osc-load-balancer-name: "simple-lb-test"
spec:
  ports:
  - port: 80
    name: http
    protocol: TCP
    targetPort: 8080
  selector:
    app: echoheaders
  type: LoadBalancer

This micro-application would watch for HTTP requests on the TCP port 80 and return the received request headers as a response.

Using Annotations in Your Load Balancers

The table below lists supported annotations for your OKS load balancers.

Lists should be comma-separated unless specified otherwise.

Annotation Mutability Description Default value

service.beta.kubernetes.io/osc-load-balancer-name

The name of the load balancer.

namespace_of_service-name_of_service

If longer than 31 characters, it is truncated.

service.beta.kubernetes.io/osc-load-balancer-scheme

The load balancer type (internet-facing | internal).

internet-facing

service.oks.outscale.com/oks-load-balancer-instances

The number of load balancers to create for the service.

Use this annotation to deploy the load balancer across multiple Subregions for high availability.

1

service.oks.outscale.com/oks-load-balancer-zones

The list of Subregions in which to create the load balancers.

For example: eu-west-2c,eu-west-2b,eu-west-2a.

The number of Subregions must match the value set for service.oks.outscale.com/oks-load-balancer-instances.

Assigned automatically.

service.oks.outscale.com/osc-load-balancer-name

The list of names to assign to the load balancers.

For example: ext-c,ext-b,ext-a.

When several names are specified, they are matched with the Subregions listed in service.oks.outscale.com/oks-load-balancer-zones in the same order.

namespace_of_service-name_of_service

If longer than 31 characters, it is truncated.

service.beta.kubernetes.io/osc-load-balancer-target-node-pools

Yes

The list of node pool names to use as backend VMs on the LBU.

For example: node-pool-1,node-pool-2,node-pool-3.

* (all node pools)

service.oks.outscale.com/oks-ip-pool-name

The optional name of the IP pool that is linked to the Public IP that you want to use for the Load Balancer.

For example: ippool-for-lbu.

None

service.beta.kubernetes.io/osc-load-balancer-additional-resource-tags

Yes

The list of key-value pairs to record as additional tags in the LBU.

For example: Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2.

None

service.beta.kubernetes.io/osc-load-balancer-source-ranges

Specifying CIDRs in the spec.loadBalancerSourceRanges service rather than using this annotation will allow you to use the Kubernetes validator.

Yes

The list of CIDRs allowed to access the load balancer.

0.0.0.0/0 (All IPs)

service.beta.kubernetes.io/osc-load-balancer-healthcheck-interval

Yes

The time between two health check requests (from 5 to 600 seconds).

30

service.beta.kubernetes.io/osc-load-balancer-healthcheck-healthy-threshold

Yes

The number of health check requests that must succeed consecutively in order to consider the node healthy (from 2 to 10).

10

service.beta.kubernetes.io/osc-load-balancer-healthcheck-path

Yes

The optional URL path for health check requests, only used with HTTP or HTTPS health check protocols.

For example: /healthz.

None

service.beta.kubernetes.io/osc-load-balancer-healthcheck-port

Yes

The port number for health check requests (from 1 to 65535).

Assigned automatically to the nodePort of the service.

service.beta.kubernetes.io/osc-load-balancer-healthcheck-protocol

Yes

The protocol for health check requests (among HTTP/HTTPS/TCP/SSL).

Assigned automatically to the protocol of the service.

service.beta.kubernetes.io/osc-load-balancer-healthcheck-timeout

Yes

The maximum waiting time for a response before considering the node unhealthy (from 2 to 60 seconds).

5

service.beta.kubernetes.io/osc-load-balancer-healthcheck-unhealthy-threshold

Yes

The number of health check requests that must fail consecutively in order to consider the node unhealthy (from 2 to 10).

2

service.oks.outscale.com/oks-load-balancer-connection-idle-timeout

Yes

The amount of time, in seconds, that the connection is allowed to be idle (meaning no data is sent over), before it is closed by the load balancer.

30 for frontend connection and 60 for backend connection.

When you set a maximum idle time for frontend connection and then unset it, the default value changes from 30 to 60.

service.beta.kubernetes.io/osc-load-balancer-proxy-protocol

Yes

Specifies whether to enable or disable the proxy protocol to transfer connection information from a client (such as client IPs) to the load balancer backend VMs (true | false).

None

service.oks.outscale.com/oks-loadbalancer-ip-mode

Yes

The IP mode of the Ingress (Proxy | VIP).

VIP

If the proxy protocol is enabled, the default value changes to Proxy.

service.oks.outscale.com/oks-external-address

This annotation enables you to narrow the status addresses of the .status.loadBalancer.ingress object, to ensure they are compatible with other tools running on your cluster.

Yes

The returned external address(es) of the load balancer’s Ingress (both | ip-only | hostname-only).

both

If you enter an invalid value, the default value will be used, returning both the IP and DNS addresses of the load balancer.

Creating Multi-Subregion Load Balancers

You can create load balancers to distribute traffic across multiple Subregions. This improves service availability if one Subregion becomes unavailable, as traffic can continue to be routed through load balancers deployed in the other Subregions instead of relying on a single load balancer as a single point of failure (SPoF).

Multi-Subregion load balancers can be configured with either of the following schemes:

Internal: Creates a load balancer for private traffic within the network.
Internet-facing: Creates a load balancer that can be accessed from the internet.

The following example creates three internet-facing load balancers, each deployed in a different Subregion:

Internet-facing Load Balancers Sample

apiVersion: v1
kind: Service
metadata:
  name: echoheaders
  annotations:
    service.beta.kubernetes.io/osc-load-balancer-scheme: internet-facing
    service.oks.outscale.com/oks-load-balancer-instances: "3"
    service.oks.outscale.com/oks-load-balancer-zones: eu-west-2a,eu-west-2b,eu-west-2c
    service.oks.outscale.com/osc-load-balancer-name: ext-a,ext-b,ext-c
spec:
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  selector:
    app: echoheaders
  type: LoadBalancer

In this example, the load balancers are created as follows:

ext-a in the eu-west-2a Subregion
ext-b in the eu-west-2b Subregion
ext-c in the eu-west-2c Subregion

To create an internal Multi-Subregion load balancer, you can set service.beta.kubernetes.io/osc-load-balancer-scheme to internal instead.

Related Pages