Walking through the journey of Kubernetes networking, users get the idea that each Pod and Service has its private IP and corresponding port to listen on request. In practice, developers may deliver the endpoint of service, the private IP or Kubernetes DNS name, for internal clients; or, developers may expose Services externally by type of NodePort or LoadBalancer. Although the endpoint of Service is more stable than Pod, the Services are offered separately, and clients should record the IPs without much meaning to them. In this section, we will introduce Ingress, a resource that makes your Services work as a group. More than that, we could easily pack our service union as an API server while we set Ingress rules to recognize the different URLs, and then ingress controller works for passing the request to specific Services based on the rules.

Before we try on Kubernetes Ingress, we should create an ingress controller in cluster. Different from other controllers in kube-controller-manager (https://kubernetes.io/docs/reference/generated/kube-controller-manager/), ingress controller is run by custom implementation instead of working as a daemon. In the latest Kubernetes version, 1.10, nginx ingress controller is the most stable one and also generally supports many platforms. Check the official documents for the details of deployment: https://github.com/kubernetes/ingress-nginx/blob/master/README.md. We will only demonstrate our example on minikube; please see the following information box for the setup of the ingress controller.

Here comes an example to demonstrate how to work with Ingress. We would run up two Deployments and their Services, and an additional Ingress to expose them as a union. In the beginning, we would add a new hostname in the host file of Kubernetes master. It is a simple way for our demonstration. If you work on the production environment, a general use case is that the hostname should be added as a record in the DNS server:

// add a dummy hostname in local host file
$ sudo sh -c "echo `minikube ip` happy.k8s.io >> /etc/hosts"

Our first Kubernetes Deployment and Service would be echoserver, a dummy Service showing server and request information. For the other pair of Deployment and Service, we would reuse the NodePort Service example from the previous section:

$ cat echoserver.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoserver-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: echo
  template:
    metadata:
      labels:
        app: echo
    spec:
      containers:
        - name: my-echo
          image: gcr.io/google_containers/echoserver:1.8
---
apiVersion: v1
kind: Service
metadata:
  name: echoserver-svc
spec:
  selector:
    app: echo
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

Go ahead and create both set of resources through configuration files:

$ kubectl create -f echoserver.yaml
deployment.apps "echoserver-deploy" created
service "echoserver-svc" created
$ kubectl create -f nodeport-deployment.yaml
deployment.apps "nodeport-deploy" created
service "nodeport-svc" created

Our first Ingress makes two Services that listen at the separate URLs /nginx and /echoserver, with the hostname happy.k8s.io, the dummy one we added in the local host file. We use annotation rewrite-target to guarantee that traffic redirection starts from root, /. Otherwise, the client may get page not found because of surfing the wrong path. More annotations we may play with are listed at https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md:

$ cat ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: happy-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target:
spec:
  rules:
    - host: happy.k8s.io
      http:
        paths:
          - path: /nginx
            backend:
              serviceName: nodeport-svc
              servicePort: 8080
          - path: /echoserver
            backend:
              serviceName: echoserver-svc
              servicePort: 8080

Then, just create the Ingress and check its information right away:

$ kubectl create -f ingress.yaml
ingress.extensions "happy-ingress" created
// "ing" is the abbreviation of "ingress"
$ kubectl describe ing happy-ingress
Name:             happy-ingress
Namespace:        default
Address:
Default backend:  default-http-backend:80 (172.17.0.3:8080)
Rules:
  Host          Path  Backends
  ----          ----  --------
  happy.k8s.io
                /nginx        nodeport-svc:8080 (<none>)
                /echoserver   echoserver-svc:8080 (<none>)
Annotations:
  nginx.ingress.kubernetes.io/rewrite-target
Events:
  Type    Reason  Age   From                Message
  ----    ------  ----  ----                -------
  Normal  CREATE  14s   ingress-controller  Ingress default/happy-ingress

You may find that there is no IP address in the field of description. It will be attached after the first DNS lookup:

// verify the URL set in ingress rules
$ curl http://happy.k8s.io/nginx
...
<title>Welcome to nginx!</title>
...
$ curl http://happy.k8s.io/echoserver
Hostname: echoserver-deploy-5598f5796f-d8cr4
Pod Information:
     -no pod information available-
Server values:
     server_version=nginx: 1.13.3 - lua: 10008
...
// the IP address would be added after connection
$ kubectl get ing
NAME            HOSTS          ADDRESS        PORTS     AGE
happy-ingress   happy.k8s.io   192.168.64.4   80        1m

Although working with Ingress is not as straightforward as other resources, as you have to start an ingress controller implementation by yourself, it still makes our application exposed and flexible. There are many network features coming that are more stable and user friendly. Keep up with the latest updates and have fun!