Using ingresses

Available in Classic

Ingress connects requests from outside the cluster to services inside the cluster, according to rules defined on the Ingress resource.
For more information, refer to Kubernetes > Ingress.
This document describes how to set two types of routing, URI-based routing and host-based routing.

Preparation

You need a running cluster, and need to install kubectl and set environment variables.

• For how to create a cluster, refer to Create clusters.
• For how to install kubectl and set environment variables, refer to Install kubectl.

Since Ingress Controller and Service are automatically created if you select Ingress Nginx when creating a cluster, skip to Check EXTERNAL-IP below.

Deploy an Ingress controller

Execute the following command, and a namespace, “ingress-nginx” is created and resources required for ingress-nginx, an Ingress implementation.

kubectl --kubeconfig $KUBE_CONFIG apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/2de5a893aa15f14102d714e918b0045b960ad1a5/deploy/static/mandatory.yaml

• Result

namespace/ingress-nginx created
configmap/nginx-configuration created
configmap/tcp-services created
configmap/udp-services created
serviceaccount/nginx-ingress-serviceaccount created
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole created
role.rbac.authorization.k8s.io/nginx-ingress-role created
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding created
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding created
deployment.apps/nginx-ingress-controller created

Create an Ingress service

Create a load balancer type Ingress service that can be accessed from outside the cluster.

kubectl --kubeconfig $KUBE_CONFIG apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/2de5a893aa15f14102d714e918b0045b960ad1a5/deploy/static/provider/cloud-generic.yaml

• Result

service/ingress-nginx created

Check if a load balancer is created in real time

kubectl --kubeconfig $KUBE_CONFIG get service -n ingress-nginx --watch

• Result

NAME            TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx   LoadBalancer   172.17.116.11   <pending>     80:31583/TCP,443:32586/TCP   4s
ingress-nginx   LoadBalancer   172.17.116.11   slb-1976810.n...   80:31583/TCP,443:32586/TCP   27s

Check EXTERNAL-IP

If a pending service is created, check EXTERNAL-IP.

kubectl --kubeconfig $KUBE_CONFIG get service -n ingress-nginx

• Result

NAME            TYPE           CLUSTER-IP      EXTERNAL-IP                 PORT(S)                      AGE
ingress-nginx   LoadBalancer   172.17.116.11   slb-1976810.ncloudslb.com   80:31583/TCP,443:32586/TCP   59s

Deploy applications and services

Create two different deployments and services as an example. Example deployments are nginx containers for demo showing host information, and each service is a cluster IP type which cannot be accessed from outside the cluster.

kubectl --kubeconfig $KUBE_CONFIG apply -f https://gist.githubusercontent.com/NaverCloudPlatformDeveloper/c47620d8d25b2a0e08648f225043adf6/raw/675addde0a56ba727824f30f92a73b40550fb73c/nks-tutorial-hello-service.yaml

• Result

deployment.apps/a created
service/a-svc created
deployment.apps/b created
service/b-svc created

URI-based routing

Let’s route requests by path added to the external IP of the Ingress service created above, so that requests with /a and /b are connected to each different service, respectively.

Create an Ingress resource

Set the Ingress resource to have different backends for each path so that access to /a is connected to a-svc, and access to /b is connected to b-svc.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ab-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - http:
      paths:
      - path: /a
        backend:
          serviceName: a-svc
          servicePort: 80
      - path: /b
        backend:
          serviceName: b-svc
          servicePort: 80

Execute the following command to create an Ingress resource.

kubectl --kubeconfig $KUBE_CONFIG apply -f https://gist.githubusercontent.com/NaverCloudPlatformDeveloper/eca9d12336e008f1c7102892750aeae5/raw/3f3d0916d89161a1d81ed19464b9991154a8b9f8/nks-tutorial-ab-ingress.yaml

• Result

ingress.extensions/ab-ingress created

Check if an Ingress resource is created

Execute kubectl get ingress to get the created Ingress.

kubectl --kubeconfig $KUBE_CONFIG get ingress

• Result

NAME         HOSTS   ADDRESS                     PORTS   AGE
ab-ingress   *       slb-1976810.ncloudslb.com   80      19s

Check access results

Check if access for each path is connected to each different pod of the service.

Example

• http://slb-1976810.ncloudslb.com/a

$ curl http://slb-1976810.ncloudslb.com/a
Server address: 172.24.21.10:80
Server name: a-57598bbddd-9hcc6
Date: 09/Jul/2019:09:03:36 +0000
URI: /a
Request ID: add732582fb99d0cfffe3edc83169517

• http://slb-1976810.ncloudslb.com/b

$ curl http://slb-1976810.ncloudslb.com/b
Server address: 172.24.21.11:80
Server name: b-657f4794f4-k48hb
Date: 09/Jul/2019:09:03:37 +0000
URI: /b
Request ID: 6cfd25c99f677c75ad815eaf57fc24c5

Host-based routing

Let’s set host-based routing where requests made to different domains for the same external IP are connected to different services.

Delete the existing Ingress

Delete the ab-ingress previously created.

kubectl --kubeconfig $KUBE_CONFIG delete ingress ab-ingress

• Result

ingress.extensions "ab-ingress" deleted

Create an Ingress resource

As shown in the following example, set different backends for each host so that requests made to a.svc.com are connected to a-svc, and those made to b.svc.com are connected to b-svc.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ab-host-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: a.svc.com
    http:
      paths:
      - path: /
        backend:
          serviceName: a-svc
          servicePort: 80
  - host: b.svc.com
    http:
      paths:
      - path: /
        backend:
          serviceName: b-svc
          servicePort: 80

Execute the following command to create an Ingress resource.

kubectl --kubeconfig $KUBE_CONFIG apply -f https://gist.githubusercontent.com/NaverCloudPlatformDeveloper/39913ee1025c45aaa0d50753db8a7555/raw/91082b01c0f26313b0a11e61df8984ac6c6b5c46/nks-tutorial-ab-host-ingress.yaml

• Result

ingress.extensions/ab-host-ingress created

Check if an Ingress resource is created

Execute kubectl get ingress to get the created Ingress where HOSTS has a.svc.com and b.svc.com.

kubectl --kubeconfig $KUBE_CONFIG get ingress

• Result

NAME              HOSTS                 ADDRESS                     PORTS   AGE
ab-host-ingress   a.svc.com,b.svc.com   slb-1976810.ncloudslb.com   80      3m57s

Check access results

The domain specified as a host in this example does not actually exist, so add -H host to the curl command to check if different services are displayed when you access each host.

Example

• a.svc.com

$ curl -H host:a.svc.com http://slb-1976810.ncloudslb.com
Server address: 172.24.21.10:80
Server name: a-57598bbddd-9hcc6
Date: 09/Jul/2019:08:33:03 +0000
URI: /
Request ID: b340711ab142bef67fdb07e7fd077ddb

• b.svc.com

$ curl -H host:b.svc.com http://slb-1976810.ncloudslb.com
Server address: 172.24.21.11:80
Server name: b-657f4794f4-k48hb
Date: 09/Jul/2019:08:33:12 +0000
URI: /
Request ID: eb6a876acbb2db7155ff26992b6635e4

Note

A request header which has an underscore (_) in the name is not recognized by the server.

ingress-nginx forcibly deletes an underscore in a request header’s name. To avoid this, add enable-underscores-in-headers: true to ConfigMap. For more information, ConfigMaps of ingress-nginx.

From the server’s point of view, the client IP of the request seems like an IP address inside the cluster.

In order to get the real IP address of the client through ingress-nginx, the proxy protocol of the load balancer and use-proxy-protocol: true ConfigMap of ingress-nginx should be enabled.
For how to enable the proxy protocol of the load balancer, refer to "Integrate with Load Balancer",
and for how to set ConfigMap of ingress-nginx, refer to ConfigMaps of ingress-nginx.

Nodes that do not have ingress-nginx pods in the load balancer fail health checks.

When an ingress-nginx service is created as in the example above, you can see that .spec.externalTrafficPolicy: Local is set.

.spec.externalTrafficPolicy specifies how the service routes external traffic. The available values are Cluster (default) and Local.

• Cluster: Distributes external traffic to all pods. It may cause a second hop to another node, but should have good overall load-spreading.
• Local: Transfers external traffic only to pods on the local node. It avoids a second hop to another node, but may cause imbalanced traffic spreading.

If .spec.externalTrafficPolicy: Local of the ingress-nginx service is set, traffic is transferred only to the node which has an ingress-nginx pod running and thus other servers fail health checks.

For more information, refer to Kubernetes;
Specify the option as needed for your service.