- Print
- PDF
Using ingresses
- Print
- PDF
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
In this example, we added nginx.ingress.kubernetes.io/ssl-redirect: "false"
as an Ingress annotation as TLS is not enabled. Delete the annotation if TLS is enabled.
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.