Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

As announced in the introduction, the octavia-ingress-controller needs to communicate with OpenStack cloud to create resources corresponding to the Kubernetes Ingress resourceResource, so the credentials of an OpenStack user (doesn't need to be the admin user) need to be provided in openstack section. Additionally, in order to differentiate the Ingresses between kubernetes clusters, cluster-name needs to be unique. Once you have filled in the fields appropriately (see below how), run the apply here too.

...

Create a simple web services (of type NodePort), analogous to those encountered in the previous chapter. When you create a Service of type NodePort, Kubernetes makes your Service available on a randomly selected high port number (in the range 30000-32767) on all the nodes in your cluster.

...

Code Block
languagebash
titleVerify Service
$ kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
coffee-svc   NodePort    10.110.66.194   <none>        80:31156/TCP   3d1h
tea-svc      NodePort    10.96.32.111    <none>        80:30458/TCP   3d1h
# Verify that the service is working
$ curl 10.110.66.194
Server address: 172.16.231.221:8080
Server name: coffee-6f4b79b975-v7cv2
Date: 30/Oct/2020:16:33:20 +0000
URI: /
Request ID: 8d870888961431bf04dd2305d614004f

Create an Ingress

...

Resource

Now we create an Ingress resourceResource, to make your HTTP web server application publicly accessible. The following linea lines defines an Ingress resource Resource that forwards traffic that requests http://webserver-bar.com to the webserver

Code Block
languageyml
titleConfigure Ingress resource
collapsetrue
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: lb
  annotations:
    kubernetes.io/ingress.class: "openstack"
    octavia.ingress.kubernetes.io/internal: "false"	# Set true, if you don't want your Ingress to be accessible from the public internet
spec:
  rules:
  - host: webserver-bar.com
    http:
      paths:
      - path: /tea				# Use webserver-bar.com/tea to target "tea" services
        pathType: Prefix		# This field is mandatory. Other values are "ImplementationSpecific" and "Exact"
        backend:
          service:
            name: tea-svc		# Enter the service name
            port:
              number: 80		# Enter the port number on which the service is listening
      - path: /coffee			# Use webserver-bar.com/coffee to target "coffee" services
        pathType: Prefix		# This field is mandatory. Other values are "ImplementationSpecific" and "Exact"
        backend:
          service:
            name: coffee-svc	# Enter the service name
            port:
              number: 80		# Enter the port number on which the service is listening


Warning
titleIngress and dashboard namespace

The application and the Ingress Resource must belong to the same namespace, otherwise the latter will not be able to "see" the backend service. If, on the other hand, you are feeling brave, you can experiment by implementing services of type ExternalName (reference).

Apply it and verify that Ingress Resource has been created. Please note that the IP address will not be defined right away (wait for the ADDRESS field to get populated). It is possible to follow the implementation of the LB step by step, from the creation of its components (Listener, Pool, Policy) to the assignment of the FIP, from the log of the Pod of the Ingress Controller (the whole operation can take a few minutes).

...

Using a browser or the curl command, you should be able to access the backend service by sending HTTP request to the domain name specified in the Ingress resource Resource (remember to hook the hostname to the FIP in the /etc/hosts of the machine from which the request to the service starts)

...