There are a couple different types of ingress, such as the following:

• Single service ingress: This strategy exposes a single service via creating an ingress with a default backend that has no rules. You can alternatively use Service.Type=LoadBalancer or Service.Type=NodePort, or a port proxy to accomplish something similar.
• Fanout: Given that od IP addressing is only available internally to the Kubernetes network, you'll need to use a simple fanout strategy in order to accommodate edge traffic and provide ingress to the correct endpoints in your cluster. This will resemble a load balancer in practice.
• Name-based hosting: This approach is similar to service name indication (SNI), which allows a web server to present multiple HTTPS websites with different certificates on the same TCP port and IP address.

Kubernetes uses host headers to route requests with this approach. The following example snippet ingress-example.yaml shows what name-based virtual hosting would look like:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: name-based-hosting
spec:
  rules:
  - host: example01.foo.com
    http:
      paths:
      - backend:
          serviceName: sevice01
          servicePort: 8080
  - host: example02.foo.com
    http:
      paths:
      - backend:
          serviceName: sevice02
          servicePort: 8080

As you may recall, in Chapter 1, Introduction to Kubernetes, we saw that a GCE cluster comes with a default back which provides Layer 7 load balancing capability. We can see this controller running if we look at the kube-system namespace:

$ kubectl get rc --namespace=kube-system

We should see an RC listed with the l7-default-backend-v1.0 name, as shown here:

This provides the ingress controller piece that actually routes the traffic defined in our ingress entry points. Let's create some resources for an Ingress.

First, we will create a few new replication controllers with the httpwhalesay image. This is a remix of the original whalesay that was displayed in a browser. The following listing, whale-rcs.yaml, shows the YAML. Note the three dashes that let us combine several resources into one YAML file:

apiVersion: v1
kind: ReplicationController
metadata:
  name: whale-ingress-a
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: whale-ingress-a
    spec:
      containers:
      - name: sayhey
        image: jonbaier/httpwhalesay:0.1
        command: ["node", "index.js", "Whale Type A, Here."]
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: ReplicationController
metadata:
  name: whale-ingress-b
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: whale-ingress-b
    spec:
      containers:
      - name: sayhey
        image: jonbaier/httpwhalesay:0.1
        command: ["node", "index.js", "Hey man, It's Whale B, Just
        Chillin'."]
        ports:
        - containerPort: 80

Note that we are creating pods with the same container, but different startup parameters. Take note of these parameters for later. We will also create Service endpoints for each of these RCs as shown in the whale-svcs.yaml listing:

apiVersion: v1
kind: Service
metadata:
  name: whale-svc-a
  labels:
    app: whale-ingress-a
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30301
    protocol: TCP
    name: http
  selector:
    app: whale-ingress-a
---
apiVersion: v1
kind: Service
metadata:
  name: whale-svc-b
  labels:
    app: whale-ingress-b
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30284
    protocol: TCP
    name: http
  selector:
    app: whale-ingress-b
---
apiVersion: v1
kind: Service
metadata:
 name: whale-svc-default
 labels:
   app: whale-ingress-a
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30302
    protocol: TCP
    name: http
  selector:
    app: whale-ingress-a

Again, create these with the kubectl create -f command, as follows:

$ kubectl create -f whale-rcs.yaml
$ kubectl create -f whale-svcs.yaml

We should see messages about the successful creation of the RCs and Services. Next, we need to define the Ingress entry point. We will use http://a.whale.hey and http://b.whale.hey as our demo entry points as shown in the following listing whale-ingress.yaml:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: whale-ingress
spec:
  rules:
  - host: a.whale.hey
    http:
      paths:
      - path: /
        backend:
          serviceName: whale-svc-a
          servicePort: 80
  - host: b.whale.hey
    http:
      paths:
      - path: /
        backend:
          serviceName: whale-svc-b
          servicePort: 80

Again, use kubectl create -f to create this ingress. Once this is successfully created, we will need to wait a few moments for GCE to give the ingress a static IP address. Use the following command to watch the Ingress resource:

$ kubectl get ingress

Once the Ingress has an IP, we should see an entry in ADDRESS, like the one shown here:

Since this is not a registered domain name, we will need to specify the resolution in the curl command, like this:

$ curl --resolve a.whale.hey:80:130.211.24.177 http://a.whale.hey/

This should display the following:

We can also try the second URL. Doing this, we will get our second RC:

$ curl --resolve b.whale.hey:80:130.211.24.177 http://b.whale.hey/

Note that the images are almost the same, except that the words from each whale reflect the startup parameters from each RC we started earlier. Thus, our two Ingress points are directing traffic to different backends.