The Book of Kubernetes: A Complete Guide to Container Orchestration by Alan Hohn

Author:Alan Hohn
Language: eng
Format: mobi, epub
Publisher: No Starch Press, Inc.
Published: 2022-08-15T00:00:00+00:00

Ingress in Production

The curl command in Listing 9-3 still looks a little strange, as we’re required to override the HTTP Host header manually. We need to perform a few additional steps to use Ingress resources to expose services in a production cluster.

First, we need our cluster to have an externally routable IP address together with a well-known name that is registered in DNS. The best way to do that is with a wildcard DNS scheme so that all hosts in a given domain are all routed to the cluster’s external IP. For example, if we own the domain cluster.example.com, we could create a DNS entry so that *.cluster.example.com routes to the cluster’s external IP address.

This approach still works with larger clusters that span multiple networks. We just need to have multiple IP addresses associated with the DNS entry, possibly using location-aware DNS servers that route clients to the closest service.

Next, we need to create an SSL certificate for our ingress controller that includes our wildcard DNS as a Subject Alternative Name (SAN). This will allow our ingress controller to provide a secure HTTP connection for external users no matter what specific service hostname they are using.

Finally, when we define our Services, we need to specify the fully qualified domain name for the host field. For the preceding example, we would specify web01.cluster.example.com rather than just web01.

After we’ve performed these additional steps, any external user would be able to connect via HTTPS to the fully qualified hostname of our Service, such as https://web01.cluster.example.com. This hostname would resolve to our cluster’s external IP address, and the load balancer would route it to one of the cluster’s nodes. At that point, our ingress controller, listening on the standard port of 443, would offer its wildcard certificate, which would match what the client expects. As soon as the secure connection is established, the ingress controller would inspect the HTTP Host header and proxy a connection to the correct Service, sending back the HTTP response to the client.

The advantage of this approach is that after we have it set up, we can deploy a new Ingress resource at any time to expose a Service externally, and as long as we choose a unique hostname, it won’t collide with any other exposed Service. After the initial setup, all of the configuration is maintained within the cluster itself, and we still have a highly available configuration for all of our Services.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.