Available in VPC
This is an example of showing how to release Ingress and conduct routing through Kubectl CLI introduced in Getting started with Kubernetes Service (VPC).
In Kubernetes, Ingress connects external requests of the cluster to the service in the cluster by the rules defined in the Ingress resource. For more information on Ingress, see Ingress.
Ingress release examples through Kubectl
The example of Ingress release and Ingress service creation through Kubectl is as follows:
- Install ingress-nginx for your cluster version.
- You can see Supported Versions table.
-
Run the command shown below to check the status of 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 -
Run the command shown below to check whether LoadBalancer is created.
- If the Load Balancer creation is complete, EXTERNAL-IP value changes from pending to actual IP address.
$ 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
Example of routing
Example of routing uses the example Deployment and Service with different information. Example Deployment is nginx container to indicate its host information, and example Service is Service created in NodePort type.
-
Use the command shown below to create example Deployment and Service.
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 -
Run the command shown below to check the status of 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 -
Run the command shown below to store load balancer access information of 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
Example of URI-based routing
When requesting to /naver, /cloud, /platform by routing for each path indicated in EXTERNAL IP of the created Ingress Service, you can set it to connect to each with a different service.
The example for URI-based routing is as follows:
-
Set the Ingress resource to have a different backend for each path and save it as a file.
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 -
Run the command shown below to create Ingress.
$ kubectl --kubeconfig $KUBE_CONFIG apply -f ./path-ingress.yamlCautionSince TLS is not set in the example,
nginx.ingress.kubernetes.io/ssl-redirect: "false"is added to the Ingress annotation to prevent forced redirection. Remove the annotation when setting TLS. -
Run the command shown below to check the created Ingress.
$ kubectl --kubeconfig $KUBE_CONFIG get ingress NAME CLASS HOSTS ADDRESS PORTS AGE path-ingress nginx * [nginx_address] 80 7s -
Check the access result through a browser or curl to check if the access is to a different Service Pod as shown in the example below.
$ 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
Example of host-based routing
When requesting to each different domain for the same EXTERNAL-IP, you can set it to connect to each with a different service.
The example for host-based routing is as follows:
-
Set the Ingress resource to have a different backend for each host and save it as a file.
- The example below shows how to set up to connect to Naver when requesting to svc.naver.com, to Cloud when requesting to svc.cloud.com, and to Platform with default request.
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 -
Run the command shown below to create Ingress.
$ kubectl --kubeconfig $KUBE_CONFIG apply -f ./host-ingress.yaml -
Run the command shown below to check the created Ingress.
$ kubectl --kubeconfig $KUBE_CONFIG get ingress NAME CLASS HOSTS ADDRESS PORTS AGE host-ingress nginx * [nginx_address] 80 15s -
Check the access result for each host after adding -H host option to curl commands to check if the access is to a different service as shown in the example below.
$ 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
- In the above example, the domain set as a host does not exist, so -H host option needs to be included in the curl commands to run.
- Ingress-nginx deletes the Request Header with underscore (_) in the name forcibly, so you cannot check the Request Header on the server. To avoid this, add enable-underscores-in-headers: true to ConfigMap to allow the use of underscore.
In Load Balancer, a node without ingress-nginx Pod is displayed as failed in the health check.
When ingress-nginx Service is created in the above example, you can check Service .spec.externalTrafficPolicy: Local settings. .spec.externalTrafficPolicy is a setting to route external traffic in the service, using Cluster and Local values.
When using the cluster, external traffic is distributed to the whole Pod. The second eviction may occur when delivering to Pod in a different Node, but the traffic to Pod can be distributed in balance.
Local delivers the external traffic only to Pod in the local Node. It avoids the second eviction in a different Node, but imbalanced traffic distribution may occur.
When ingress-nginx Service is set for .spec.externalTrafficPolicy: Local, traffic is only delivered to the node that ingress-nginx Pod is operating. Therefore, other servers are displayed as failed in the Health Check.
For more information on the operation, see Using Source IP.