Contrail Ingress Workflow
When an Ingress is configured in a Contrail Kubernetes environment, the event will be noticed by other system components and a lot of actions will be triggered. The deep level implementation is beyond the scope of this book, but at a high level this is the workflow:
The contrail-kube-manager keeps listening to the events of the kube-apiserver.
User creates an ingress object (rules).
The contrail-kube-manager gets the event from kube-apiserver.
The contrail-kube-manager creates a load balancer object in contrail DB, and sets the load balancer_ provider type as open contrail for ingress (where as it is native for service).
As mentioned earlier, the contrail-service-monitor component sees the load balancer creation event, based on the load balancer_provider type, and it invokes the registered load balancer driver for the specified load balancer_provider type:
If the load balancer_provider type is native, it will invoke the ECMP loadbalancer driver for ECMP load balancing, which we reviewed in the previous section.
If the load balancer_provider type is open contrail, it will invoke the haproxy load balancer driver, which triggers the haproxy processes to be launched in Kubernetes nodes.
As you can see, Contrail implements Ingress with haproxy load balancer, as you also read in the section on Contrail Kubernetes object mapping. Chapter 3 described the ingress controller, and how multiple ingress controllers can coexist in Contrail. In the Contrail environment, the contrail-kube-manager plays the Ingress controller role. It reads the ingress rules that users input, and programs them into the load balancer. Furthermore:
For each Ingress object, one load balancer will be created;
Two haproxy processes will be created for Ingress and they are working in active-standby mode:
one compute node runs the active haproxy process
the other compute node runs the standby haproxy process
Both haproxy processes are programmed with appropriate configuration, based on the rules defined in the Ingress object.