Configuring Ingress Controllers with Consul on Kubernetes
The following information requires Consul 1.10+, Consul-k8s 0.26+, Consul-helm 0.32+ configured with Transparent Proxy mode enabled.
This page describes a general approach for integrating Ingress Controllers with Consul on Kubernetes to secure traffic from the Controller to the backend services. This allows Consul to transparently secure traffic from the ingress point through the entire traffic flow of the service.
A few steps are generally required to enable an Ingress controller to join the mesh and pass traffic through to a service:
Note: Depending on which ingress controller you use, these stanzas may differ in name and layout, but it is important to apply these annotations to the pods of your ingress controller.
The Ingress Controller’s ServiceAccount name and Service name differ by default in some platforms. Consul on Kubernetes requires the ServiceAccount and Service to have the same name. To resolve this be sure to explicitly set ServiceAccount name the same as the ingress controller service name using it’s respective helm configurations.
If the Ingress Controller does not have the correct inbound ports excluded it will fail to start and the Ingress’ service will not get created, causing the controller to hang in the init container. The required container ports are not always readily available in the helm charts, so in order to resolve this examine the ingress controller’s underlying pod spec and look for the required container ports, adding these to the annotation on the ingress controller deployment.
Examples:
Here are a couple example configurations which can be used as reference points in setting up your own ingress controller configuration! These were used in dev environments and are not intended to be fully supported but should provide some idea how to extend the information above to your own uses cases.