...
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 | ||||
---|---|---|---|---|
| ||||
$ 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 | ||||||
---|---|---|---|---|---|---|
| ||||||
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 | ||
---|---|---|
| ||
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 |
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)
...