Ingress Controllers

If your application contains Kubernetes Ingress, this may require some changes to be compatible with Replicated. Ingress resources are unique in Kubernetes because a cluster must have a functional ingress controller running before an ingress resource type can be deployed.

Ingress in the Cloud

When running Kubernetes in a cloud provider or in a managed Kubernetes stack such as GKE or Azure Container Service, the cloud provider often deploys and configures an ingress controller into every cluster automatically. These are propietary controllers that make use of the other infrastructure components offered by the cloud provider. For example, a GKE cluster has an ingress controller that will automatically provision a Google Cloud Load Balancer with an external IP address.

Ingress in the Replicated Appliance

Replicated ships with the Contour ingress controller, which runs in the heptio-contour namespace.
A NodePort service forwards incoming traffic on ports 80 and 443 to Contour through every node in your cluster.

The Contour ingress controller supports a variety of options through annotations.
These options may not be supported in all your customers’ cloud environments with different ingress controller implementations.

Ingress with TLS on Contour

To configure Contour to serve HTTPS requests on port 443, first define a Secret in your yaml that contains a certificate and private key.
This certificate may come from a file uploaded on the customer’s config screen or can be generated with the cert_out command as shown below.

Contour uses Envoy’s SNI feature to provide TLS support.
This requires that your certificate be associated with a valid host domain name (not an IP address) and the hostname appears in the ingress’s spec.tls.hosts and spec.rules.host fields as shown below.