Back

servers.com ingress controller

Exposing complex applications running within a Kubernetes cluster to the internet and traffic routing requires a comprehensive approach.

The Ingress controller is a tool that solves these tasks along with a variety of additional options.

It offers the following key features:

  • External access to services within a cluster

  • Traffic load balancing

  • SSL/TLS termination

The advantage of the Ingress controller is that it can serve several services at once (unlike a Kubernetes service with the load balancer).

The servers.com Ingress controller is built upon our HTTP(S) (L7) Load Balancer and shares its wide set of features.

Services

It is helpful to get acquainted with the following particularities that come with using Kubernetes services with the Ingress controller:

  • ClusterIP - this service is not intended for interaction with external networks so it's not used along with the Ingress controller

  • LoadBalancer - the LoadBalancer service uses a cloud controller manager that works on top of the servers.com TCP (L4) Load Balancer. In this case, you will have two load balancers: one for the cloud controller manager and one for the Ingress controller

  • NodePort - unlike the LoadBalancer service, NodePort doesn't need an additional TCP (L4) Load Balancer

Annotations

An annotation is a Kubernetes entity that helps manage Ingress resources and service objects. In the servers.com Ingress controller, annotations are based on the servers.com L7 Load Balancer’s features.

They are briefly described in this document (for more details, refer to HTTP Load Balancer features).

Ingress controller annotations 

This set of annotations is applied to the Ingress resource. It means they will work on all the services under the Ingress controller.

Name

Default

Example

Description

servers.com/load-balancer-store-logs-region-code

nil

NL01

Defines a location for cloud storage that will keep logs from the balancer. When this annotation is not specified or has the nil value, the feature will be disabled.

The value must coincide with the cloud region code that you can find in the table at the end of this article. It's allowed to define this parameter both ways: NL01 or nl01.

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

false

true

Enables the GeoIP option.

servers.com/load-balancer-min-tls-version

1.3

1.2

Defines the minimum TLS version. Both the 1.2 and 1.3 values are available.

servers.com/load-balancer-real-ip-trusted-networks (coming soon)-

nil

172.10.1.0/24

Specifies trusted networks for the X-Real-IP header. A trusted network is one that will receive real IP addresses instead of the balancer's IP.

More details in this NGINX documentation: https://nginx.org/en/docs/http/ngx_http_realip_module.html

If this annotation is specified, the X-Real-IP feature is enabled; otherwise, disabled.

Please note: this annotation is not yet released but will be available soon.

An example of the Ingress configuration with an annotation:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    servers.com/load-balancer-geo-ip-enabled: "true"

Service annotations

The below annotations are applied to a specific Kubernetes Service (NodePort or LoadBalancer).

Name

Default

Examples

Description

servers.com/load-balancer-balancing-algorithm

random_least_connections

least_connections

Manages the balancing algorithm:

  • random_least_connections

  • least_connections

  • round_robin

servers.com/app-protocol

http

http2

Defines whether HTTP or HTTP2 is used.

servers.com/app-healthcheck-path

/healthz

/example

A path for healthcheck starting from slash.

servers.com/app-healthcheck-domain

nil

example.com

The domain for healthcheck.

servers.com/app-healthcheck-requests-method

GET

POST

An HTTP method for a healthcheck:

  • GET

  • POST

servers.com/app-healthcheck-checks-to-fail

1

2

A number of checks to consider as failed.

Range: 1-100

servers.com/app-healthcheck-checks-to-pass

3

1

A number of checks to consider as passed.

Range: 1-100

servers.com/app-healthcheck-interval

5

10

An interval between checks in seconds.

Range: 1-60

servers.com/app-healthcheck-jitter

0

1

The jitter in seconds.

Range: 1-10

An example of a configuration with Service annotations:

apiVersion: v1
kind: Service
metadata:
  name: example-service
  annotations:
    servers.com/load-balancer-balancing-algorithm: "random_least_connections"

TLS settings

For enhanced security, you can set up TLS (Transport Layer Security) protocol within the servers.com Ingress controller. There are two ways to do this:

  • Using an SSL certificate from the servers.com Customer Portal

  • Creating a Secret object in Kubernetes

Using an SSL certificate from Customer Portal

The secretName parameter has to be filled in the Ingress object specification according to this pattern:

sc-certmgr-cert-id-‹certificate ID›

<certificate ID> is a unique identifier of an SSL certificate. ID can be found on the SSL certificates page or fetched by performing the relevant API request.

The configuration may look like this for an SSL certificate with ID - ex4mp1e1D:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  ingressClassName: serverscom
  tls:
    - hosts:
        - example.com
      secretName: sc-certmgr-cert-id-ex4mp1e1D

Creating a Secret object in Kubernetes

To create a Secret object in Kubernetes, use this command:

kubectl create secret tls ${certificate-name} --key ${key-file} --cert ${certificate-file}

Key and certificate files are hosted locally on a machine from where kubectl is executed.

This is what the Secret object may look like:

apiVersion: v1
kind: Secret
metadata:
  name: example-tls
  namespace: default
data:
  tls.crt: base64 encoded cert
  tls.key: base64 encoded key
type: kubernetes.io/tls

Once the Secret object is created, it can be used within the Ingress object configuration.

Here is an example of the Ingress object with TLS configured:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  ingressClassName: serverscom
  tls:
    - hosts:
        - example.com
      secretName: example-tls

Useful materials

Cloud regions

This table contains a list of cloud region codes to use in the servers.com/load-balancer-store-logs-region-code annotation.

Region

Region code

Amsterdam

NL01

Dallas

US01

Luxembourg

LU01

Singapore

SIN01

Share

Suggested Articles

  • Kubernetes clusters

    Introducing the Kubernetes Clusters service

  • Kubernetes clusters

    Third-party Ingress controller