Home / Kong Mesh
Edit
Report

Configure the Kong Mesh CNI

Uses: Kong Mesh
Related Documentation
Mesh Documentation
Related Resources
Mesh DNS
Configure transparent proxying
Kubernetes annotations and labels

In order for traffic to flow through the Kong Mesh data plane, all inbound and outbound traffic for a service needs to go through its data plane proxy. The recommended way of accomplishing this is via transparent proxying.

On Kubernetes it’s handled automatically by default with the initContainer kuma-init, but this container requires certain privileges.

Another option is to use the Kong Mesh CNI. This frees every Pod in the mesh from requiring said privileges, which can make security compliance easier.

The CNI DaemonSet itself requires elevated privileges because it writes executables to the host filesystem as root.

Install the CNI using either

kumactl or Helm. The default settings are tuned for OpenShift with Multus. To use it in other environments, set the relevant configuration parameters.

Kong Mesh CNI applies NetworkAttachmentDefinitions to applications in any namespace with kuma.io/sidecar-injection label. To apply NetworkAttachmentDefinitions to applications not in a Mesh, add the label kuma.io/sidecar-injection with the value disabled to the namespace.

Installation

Below are the details of how to set up Kong Mesh CNI in different environments using both kumactl and helm.

kumactl install control-plane \
  --set "kuma.cni.enabled=true" \
  --set "kuma.cni.chained=true" \
  --set "kuma.cni.netDir=/etc/cni/net.d" \
  --set "kuma.cni.binDir=/opt/cni/bin" \
  --set "kuma.cni.confName=05-cilium.conflist" \
  | kubectl apply -f -

You need to set the Cilium config value cni-exclusive or the corresponding Helm chart value cni.exclusive to false in order to use Cilum and Kong Mesh together. This is necessary starting with the release of Cilium v1.14.

For installing Kong Mesh CNI with Cilium on GKE, you should follow the Google - GKE section.

For Cilium versions < 1.14 you should use kuma.cni.confName=05-cilium.conf as this has changed for version starting from Cilium 1.14.

Kong Mesh CNI taint controller

To prevent a race condition described in this issue a new controller was implemented. The controller will taint a node with NoSchedule taint to prevent scheduling before the CNI DaemonSet is running and ready. Once the CNI DaemonSet is running and ready it will remove the taint and allow other pods to be scheduled into the node.

To disable the taint controller use the following env variable:

KUMA_RUNTIME_KUBERNETES_NODE_TAINT_CONTROLLER_ENABLED="false"

Merbridge CNI with eBPF

To install merbridge CNI with eBPF append the following options to the command from installation:

To use Merbridge CNI with eBPF your environment has to use Kernel >= 5.7 and have cgroup2 available

--set ... \
--set "kuma.cni.enabled=true" \
--set "kuma.experimental.ebpf.enabled=true"

Kong Mesh CNI logs

Logs of CNI components are available via kubectl logs.

To enable debug level log, please set value of environment variable CNI_LOG_LEVEL to debug on the CNI DaemonSet kong-mesh-cni. Please note that editing the CNI DaemonSet will shutdown the current running CNI Pods hence all mesh enabled application pods are not able to start or shutdown during the restarting of the DaemonSet. Don’t do it in a production environment unless approved.

eBPF CNI currently doesn’t have support for exposing its logs.

Kong Mesh CNI architecture

The CNI DaemonSet kong-mesh-cni is formed by two components:

  1. a CNI installer
  2. a CNI binary

Involved components collaborate like this:

The CNI installer copies CNI binary kuma-cni to the CNI directory on the host. When chained, the installer also sets up chaining for kuma-cni in CNI conflist file, and when chaining is disabled, the binary kuma-cni is invoked explicitly as per pod manifest. When correctly installed, the CNI binary kuma-cni will be invoked by Kubernetes when a mesh-enabled application pod is being created so iptables rules required by the kuma-sidecar container inside the pod are properly set up.

When chained, if the CNI conflist file is unexpectedly changed causing kuma-cni to be excluded, the installer immediately detects it and restarts itself so the chaining installation re-runs and CNI functionalities heal automatically.

Did this doc help?

Something wrong?
Report an Issue | Edit this Page

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!
Contribute

Still need help

Ask in our Forum
Contact Support