Login
      Contents x
      Ingress use cases
        • Print
        • PDF
        Contents

        Ingress use cases

          • Print
          • PDF
          Article Summary

          Available in VPC

          These are examples to use Kubectl CLI introduced in Getting started with Kubernetes Service (VPC) to deploy Ingress and perform routing.

          In Kubernetes, Ingress connects requests from outside the cluster to services inside the cluster, according to the rules defined on the Ingress resource. For more information on Ingress, refer to Ingress.

          Ingress deployment example through Kubectl

          The following example uses Kubectl to deploy Ingress and create an Ingress service.

          1. Run the command shown below to install ingress-nginx.
            kubectl --kubeconfig $KUBE_CONFIG apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.1/deploy/static/provider/cloud/deploy.yaml
          2. Run the following command to check the status of the ingress-nginx pod.
            $ kubectl --kubeconfig $KUBE_CONFIG get pods -n ingress-nginx
NAME                                       READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-wnkkp       0/1     Completed   0          4m32s
ingress-nginx-admission-patch-rw4f2        0/1     Completed   0          4m32s
ingress-nginx-controller-fd7bb8d66-wzfkd   1/1     Running     0          4m32s
          3. Run the following command to check if load balancer is created.
            • Once a load balancer is created, the value of EXTERNAL-IP changes to the actual IP address from pending.
            $ kubectl --kubeconfig $KUBE_CONFIG get svc -n ingress-nginx
NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.233.38.219   [nginx_address]   80:30033/TCP,443:31110/TCP   39s
ingress-nginx-controller-admission   ClusterIP      10.233.33.133   <none>            443/TCP                      39s

          Routing example

          The following routing example uses deployments and services, each with varied information. The example deployments are NGINX containers for showing their own host information. The example services are created as NodePort.

          1. Create the example deployments and services using the command shown below.
          kubectl --kubeconfig $KUBE_CONFIG apply -f https://raw.githubusercontent.com/NaverCloudPlatform/nks-alb-ingress-controller/main/docs/examples/pub/nks-alb-ingress-sample-services.yaml
          1. Run the following command to check the status of the example deployment and service.
          $ kubectl --kubeconfig $KUBE_CONFIG get pods
NAME                              READY   STATUS    RESTARTS   AGE
cloud-8569cb49bf-k2787            1/1     Running   0          18s
naver-7d855c949f-2wc2l            1/1     Running   0          18s
platform-68754dccf9-8wqng         1/1     Running   0          18s

$ kubectl --kubeconfig $KUBE_CONFIG get svc
NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
cloud             NodePort    10.233.6.109    <none>        80:31234/TCP   69s
naver             NodePort    10.233.29.211   <none>        80:31411/TCP   69s
platform          NodePort    10.233.2.191    <none>        80:31928/TCP   69s
          1. Run the following command to save load balancer connection information for ingress-nginx.
          $ export nginx_address=$(kubectl --kubeconfig $KUBE_CONFIG get svc -n ingress-nginx ingress-nginx-controller -o jsonpath={.status.loadBalancer.ingress[*].hostname})
$ echo $nginx_address

          URI-based routing example

          You can route by path displayed in EXTERNAL IP of the generated Ingress Service and set it to connect to different services when requesting to /naver, /cloud, and /platform.

          URI-based routing example is as follows.

          1. Set the Ingress resource to have a different backend according to each path as shown below.
            apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: path-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  ingressClassName: nginx
  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
      - path: /platform
        pathType: Prefix
        backend:
          service:
            name: platform
            port:
              number: 80
          2. Run the following command to create the Ingress.
            kubectl --kubeconfig $KUBE_CONFIG apply -f ./path-ingress.yaml
            Caution

            In the example, the TLS settings weren't done, so nginx.ingress.kubernetes.io/ssl-redirect: "false" is added to the Ingress annotation to prevent forced redirection. Remove the annotation if TLS is set.

          3. Run the following command to check the created Ingress.
            $ kubectl --kubeconfig $KUBE_CONFIG get ingress
NAME           CLASS   HOSTS   ADDRESS            PORTS   AGE
path-ingress   nginx   *       [nginx_address]    80      7s
          4. Check if access for each path accesses different service pods by checking the access result through a browser or curl.
            $ curl $nginx_address/naver
Server address: 198.18.2.178:80
Server name: naver-7d855c949f-hsf8q
Date: 24/May/2022:09:17:23 +0000
URI: /
Request ID: dcf54d3b841e06733ae75cc08dc922d0

            $ curl $nginx_address/cloud
Server address: 198.18.2.32:80
Server name: cloud-8569cb49bf-przrt
Date: 24/May/2022:09:17:26 +0000
URI: /
Request ID: 461db9ee32dc3a5e1452b426da88fce8

            $ curl $nginx_address/platform
Server address: 198.18.3.182:80
Server name: platform-68754dccf9-7przv
Date: 24/May/2022:09:17:31 +0000
URI: /
Request ID: 47ae775498a2dad86ab9c9fd0ca58537

          Host-based routing example

          You can set host-based routing where requests made to different domains for the same EXTERNAL-IP access different services.

          Host-based routing example is as follows.

          1. Set the Ingress resource to have different backend according to each host as below.
            • In the example below, the request made to svc.naver.com is set to connect to naver, and the request made to svc.cloud.com is set to connect to cloud, and other request is set to connect to platform.
            apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: host-ingress
 annotations:
   nginx.ingress.kubernetes.io/rewrite-target: /
   nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
 ingressClassName: nginx
 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
 - http:
     paths:
     - path: /
       pathType: Prefix
       backend:
         service:
           name: platform
           port:
             number: 80
          2. Run the following command to create the Ingress.
            kubectl --kubeconfig $KUBE_CONFIG apply -f ./host-ingress.yaml
          3. Run the following command to check the created Ingress.
            $ kubectl --kubeconfig $KUBE_CONFIG get ingress
NAME           CLASS   HOSTS   ADDRESS            PORTS   AGE
host-ingress   nginx   *       [nginx_address]    80      15s
          4. Add the -H host option to the curl command as in the example below, and check the access result by host if they connect to different services.
            $ curl -H host:svc.naver.com $nginx_address
Server address: 198.18.2.178:80
Server name: naver-7d855c949f-hsf8q
Date: 24/May/2022:09:25:40 +0000
URI: /
Request ID: f5cb5e2f152367632ebecc9dd2ef2942

            $ curl -H host:svc.cloud.com $nginx_address
Server address: 198.18.2.32:80
Server name: cloud-8569cb49bf-przrt
Date: 24/May/2022:09:25:50 +0000
URI: /
Request ID: e9203271c73a8d7e908fc5bf8613850f

            $ curl $nginx_address
Server address: 198.18.3.182:80
Server name: platform-68754dccf9-7przv
Date: 24/May/2022:09:25:56 +0000
URI: /
Request ID: 751e0dc1e99b79495ada5dbb06d92c4a
          Note

          • The domain set as the host in the above example doesn't actually exist. Therefore, the -H host option must be included in the curl command to run it.

          • ingress-nginx deletes request headers with underscores (_) in the name by default. This means that those kinds of request headers can't be checked in the server. In order to avoid this, you should add enable-underscores-in-headers: true to the ConfigMap for it to allow the use of underscores.

          Note

          The nodes without ingress-nginx pods is displayed as failed at the health check in Load Balancer.


          If an ingress-nginx service is created as in the example above, you can check the Service .spec.externalTrafficPolicy: Local configuration. .spec.externalTrafficPolicy is a configuration that specifies how the service routes external traffic. The available values are Cluster and Local.


          Cluster distributes external traffic to all pods. A second hop may be caused when passing the traffic to a pod in another node, but the overall load-spreading should be good for traffic to pods.
          Local passes external traffic only to the pods on local nodes. It avoids a second hop to another node, but may cause imbalanced traffic to spread.


          If the configuration of the ingress-nginx service is set as .spec.externalTrafficPolicy: Local, then traffic is only transferred to the nodes which have an ingress-nginx pod running. Therefore, and the other servers fail the health checks.


          For more information on how this works, refer to Using source IP.

          Was this article helpful?
          What's Next
          Change password!
          Changing your password will log you out immediately. Use the new password to log back in.
          Change profile
          Success!
          First name must have atleast 2 characters. Numbers and special characters are not allowed.
          Last name must have atleast 1 characters. Numbers and special characters are not allowed.
          Enter a valid email
          Enter a valid password
          Your profile has been successfully updated.
          Logout