Aller au contenu

Deploy new ingresses and expose services.#

A new network strategy has been configured on the way ingress-controllers (v2) are deployed.

This network strategy applies on internal-controller services deployed by the ingress-controller configuration. It is applied thanks to the ExternalTrafficPolicy attribute on the ingress-controller K8s service, its value has changed from Cluster to Local.

When set to Cluster, Kube-Proxy formerly changed the source IP to ensure network connectivity. Whith this new setup, the Kube-Proxy SNAT is disabled, though the network chain is broken when service calls are made from within the same k8s cluster.

This side-effect is countered by a new internal service that can be deployed by the ingress-controller-v2 configuration. The coredns configuration from the targeted k8s cluster is overloaded in order to lie to local service calls and this way ensure that services are still working from within the cluster without the help of Kube-Proxy.

Advantages#

  • It allows the ingress-controller service to get the real source IP from external service call.
  • Enhanced network performance, as the internal network traffic is now confined within the k8s cluster instead of going through the LoadBalancer chain.

Drawbacks#

  • When deploying new ingress services and associated new host, the ingress-controller-v2 configuration must be redeployed.

How to deploy#

Just use trackbone to deploy the configuration as usual

trackbone [action] [-z target_zone] -c ingress_controller_v2_{name_of_ingress}

NB: When deploying a new kind of ingress fe_whitelist configuration must be applied for securiy reasons.