ALB Ingress Controller examples

Article Summary

Share feedback

Thanks for sharing your feedback!

Available in VPC

In Ncloud Kubernetes Service, you can add annotations to Service and Ingress to create various routing strategies. This guide provides use examples based on Setting up ALB Ingress Controller.

Install example workload

Run the following command to install example deployments and services. When you run the command, deployments and services of which names are "naver," "cloud," and "platform" are created.

kubectl --kubeconfig=$KUBE_CONFIG apply -f https://raw.githubusercontent.com/NaverCloudPlatform/nks-alb-ingress-controller/main/docs/en/examples/pub/nks-alb-ingress-sample-services.yaml

ALB Ingress Controller examples

Example of path-based routing

This example shows how to route a request to different services based on the specified path. Incoming requests to the /naver path are routed to the naver service, while incoming requests to the /cloud path are routed to the cloud service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: path-ingress
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /naver
        pathType: Prefix
        backend:
          service:
            name: naver 
            port:
              number: 80
      - path: /cloud
        pathType: Prefix
        backend:
          service:
            name: cloud
            port:
              number: 80

Example of host-based routing

This example shows how to route a request to different services based on the specified host. All incoming requests to the /svc.naver.com host are routed to the naver service, while all incoming requests to the svc.cloud.com host are routed to the cloud service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: host-ingress
spec:
  ingressClassName: alb
  rules:
  - host: svc.naver.com
    http:
      paths:
      - path: /*
        pathType: Prefix
        backend:
          service:
            name: naver
            port:
              number: 80
  - host: svc.cloud.com
    http:
      paths:
      - path: /*
        pathType: Prefix
        backend:
          service:
            name: cloud
            port:
              number: 80

Example of HTTP header-based routing

This example shows how to route traffic based on the HTTP header value. It uses the alb.ingress.kubernetes.io/conditions annotation to define the HTTP header rules. Here, only requests where the HTTP header "HeaderName" includes "HeaderValue1" or "HeaderValue2" are routed to the NAVER service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: condition-ingress
  annotations:
    alb.ingress.kubernetes.io/conditions.naver: >
      [{"field":"httpHeader","httpHeader":{"key": "HeaderName", "values":["HeaderValue1", "HeaderValue2"]}}]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /*
            pathType: Prefix
            backend:
              service:
                name: naver
                port:
                  number: 80

Example of using port name of service

You can define traffic routing rule in the Ingress rule by using the port name (port.name) of the service. For this, you need to explicitly set port.name when defining the service. In this example, the name "http-web" is assigned for the NAVER service port and is referred to by the Ingress rule.

apiVersion: v1
kind: Service
metadata:
  name: naver
spec:
  ports:
  - name: http-web
    nodePort: 30080
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: naver
  type: NodePort
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: portname-ingress
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /naver
        pathType: Prefix
        backend:
          service:
            name: naver
            port:
              name: http-web

Example of redirecting HTTP to HTTPS

This example shows how to redirect the traffic coming from HTTP to HTTPS using the ssl-redirect annotation. To execute this example, the following elements are required.

Domain
The certificate of the domain registered to Certificate Manager

To redirect the traffic coming to HTTP(80) to HTTPS(443), create an Ingress as shown in the example below.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS":443}]'
    alb.ingress.kubernetes.io/ssl-certificate-no: "1004"
    alb.ingress.kubernetes.io/ssl-redirect: "443"
  name: redirect-ingress
spec:
  ingressClassName: alb
  defaultBackend:
    service:
      name: cloud
      port:
        number: 80

The following describes how to add two ports in order to redirect Port 80 to Port 443 in the above settings.
```
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS":443}]'
```
The following describes how to get the certificate number to register to the HTTPS listener in the above settings.
```
alb.ingress.kubernetes.io/ssl-certificate-no: "1004"
```
Note
The certificate number can be checked at the nrn of Resource Manager. (e.g., nrn:PUB:CertificateManager::000:Certificate/External/${certificateNo})
The following describes how to register the port for redirection in the above setting.
```
alb.ingress.kubernetes.io/ssl-redirect: "443"
```

Example of using multi-certificates

You can register multiple certificates to a load balancer. This example shows how to configure the default certificate and additional certificates.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS":443}]'
    alb.ingress.kubernetes.io/ssl-certificate-no: "1234, 1004"
    alb.ingress.kubernetes.io/ssl-redirect: "443"
  name: multi-ssl-ingress
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /*
        pathType: Prefix
        backend:
          service:
            name: naver 
            port:
              number: 80

The following describes how to register the certificates in the above setting. The first certificate is added as the default certificate and the rest are set as additional certificates.
```
alb.ingress.kubernetes.io/ssl-certificate-no: "1234, 1004"
```

Example of weighted routing through action

This example defines how to handle the traffic to a specific path using Ingress and annotation. For the /navercloud path, use the annotation to redirect traffic to either naver or cloud service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: action-ingress
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
    alb.ingress.kubernetes.io/description: 'alb ingress controller'
    alb.ingress.kubernetes.io/actions.navercloud: >
      {"type":"targetGroup","targetGroup":{"targetGroups":[{"serviceName":"naver","servicePort":80,"weight":50},{"serviceName":"cloud","servicePort":80,"weight":50}]}}
spec:
  ingressClassName: alb
  defaultBackend:
    service:
      name: naver
      port:
        number: 80
  rules:
    - http:
        paths:
          - path: /platform
            pathType: Prefix
            backend:
              service:
                name: platform
                port:
                  number: 80
          - path: /navercloud
            pathType: Exact
            backend:
              service:
                name: navercloud
                port:
                  name: use-annotation

Below is the part where traffic is distributed to the naver and cloud services in the setting above.

alb.ingress.kubernetes.io/actions.navercloud: >
  {"type":"targetGroup","targetGroup":{"targetGroups":[{"serviceName":"naver","servicePort":80,"weight":50},{"serviceName":"cloud","servicePort":80,"weight":50}]}}

To apply the annotation, the path defined in Ingress specifications and the actionName in actions.${actionName} must match.

Example of using condition to add a condition

This example defines how to add a condition for a specific path using Ingress and annotation. The traffic is routed from the /naver path to the naver service following the rules specified in the specifications, and annotations are used to add conditions.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: condition-ingress
  annotations:
    alb.ingress.kubernetes.io/conditions.naver: >
      [{"field":"hostHeader","hostHeader":{"values":["svc.naver.com"]}},{"field":"pathPattern","pathPattern":{"values":["/cloud"]}}]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /naver
            pathType: Prefix
            backend:
              service:
                name: naver
                port:
                  number: 80

Below is the part where the svc.naver.com host header conditions and additional paths are applied in the setting above.

alb.ingress.kubernetes.io/conditions.naver: >
  [{"field":"hostHeader","hostHeader":{"values":["svc.naver.com"]}},{"field":"pathPattern","pathPattern":{"values":["/cloud"]}}]

To apply annotation, the path defined in Ingress specifications and the conditionName in conditions.${conditionName} must match.

Example of setting the health check path per target group

If the target of annotation is Ingress or Service, annotation is available for both resource types. If the same annotation is found in both Ingress and Service, the annotation applied to Service takes priority.

In this example, the health check for each service registered in each path is set individually. The specific health check setting for each service is implemented by the annotation of Service.

# naver-service.yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    alb.ingress.kubernetes.io/healthcheck-path: /naver
  name: naver
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: naver
  type: NodePort
---
# cloud-service.yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    alb.ingress.kubernetes.io/healthcheck-path: /cloud
  name: cloud
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: cloud
  type: NodePort
---
# healthcheck-alb.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: healthcheck-alb
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
    alb.ingress.kubernetes.io/healthcheck-path: "/"
spec:
  defaultBackend:
    service:
      name: platform 
      port:
        number: 80
  rules:
  - http:
      paths:
      - path: /naver
        pathType: Prefix
        backend:
          service:
            name: naver
            port:
              number: 80
      - path: /cloud
        pathType: Prefix
        backend:
          service:
            name: cloud
            port:
              number: 80

The health check condition of the target group to be routed to the /naver path in the setting above is as follows. These settings must be defined by the annotation of the service to apply specific health check conditions to each target group.
```
alb.ingress.kubernetes.io/healthcheck-path: /naver
```

Example of specifying Sticky Session

Sticky Session of a load balancer is provided as the Sticky Session feature configurable in the listener rule and the Sticky Session feature configurable in the target group.
In this example, we're going to specify the Sticky Sessions of all target groups created and set to use the Sticky Sessions of the rules created through action.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: sticky-ingress 
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
    alb.ingress.kubernetes.io/enable-sticky-session: 'true'
    alb.ingress.kubernetes.io/actions.targets: >
      {"type":"targetGroup","targetGroup":{"targetGroups":[{"serviceName":"naver","servicePort":80,"weight":50},{"serviceName":"cloud","servicePort":80,"weight":50}],"enableStickySession":true}}
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /navercloud
        pathType: Prefix
        backend:
          service:
            name: targets 
            port:
              name: use-annotation 
      - path: /platform
        pathType: Prefix
        backend:
          service:
            name: platform 
            port:
              number: 80

In the setting above, the following is the part where the Sticky Session of the target group is used.
```
alb.ingress.kubernetes.io/enable-sticky-session: 'true'
```

In the setting above, the following is the part where the Sticky Session is used for the requests coming to the /navercloud path.

alb.ingress.kubernetes.io/actions.targets: >
  {"type":"targetGroup","targetGroup":{"targetGroups":[{"serviceName":"naver","servicePort":80,"weight":50},{"serviceName":"cloud","servicePort":80,"weight":50}],"enableStickySession":true}}

Was this article helpful?

What's Next

Examples of block storage CSI

Table of contents