Deploying Antrea on a Kind cluster

We support running Antrea inside of Kind clusters on both Linux and macOS hosts. On macOS, support for Kind requires the use of Docker Desktop, instead of the legacy Docker Toolbox.

To deploy a released version of Antrea on an existing Kind cluster, you can use:

  1. # "fix" the host's veth interfaces (for the different Kind Nodes)
  2. kind get nodes | xargs ./hack/kind-fix-networking.sh
  3. # deploy Antrea
  4. kubectl apply -f https://github.com/vmware-tanzu/antrea/releases/download/<TAG>/antrea-kind.yml

Create a Kind cluster and deploy Antrea in a few seconds

Quick two Node Kind cluster setup

To create a two worker Node cluster with Antrea installed using scripts, do

  1. ./ci/kind/kind-setup.sh create CLUSTER_NAME

This command will execute kubectl commands to set up the cluster, and requires that kubectl be present in your PATH.

kind-setup.sh allows users to specify the number of worker Nodes, the docker bridge networks/subnets connected to worker Nodes, and some docker images to be pre-loaded in each Node. For more information on usage, run:

  1. ./ci/kind/kind-setup.sh help

Above is the short cut to a Kind setup with Antrea. Read further in order to setup a Kind cluster manually.

Create a Kind cluster manually

The only requirement is to use a Kind configuration file which disables the Kubernetes default CNI (kubenet). For example, your configuration file may look like this:

  1. kind: Cluster
  2. apiVersion: kind.x-k8s.io/v1alpha4
  3. networking:
  4.   disableDefaultCNI: true
  5.   podSubnet: 10.10.0.0/16
  6. nodes:
  7. - role: control-plane
  8. - role: worker
  9. - role: worker

Once you have created your configuration file (let’s call it kind-config.yml), create your cluster with:

  1. kind create cluster --config kind-config.yml

Deploy Antrea to your Kind cluster

These instructions assume that you have built the Antrea Docker image locally (e.g. by running make from the root of the repository).

  1. # "fix" the host's veth interfaces (for the different Kind Nodes)
  2. kind get nodes | xargs ./hack/kind-fix-networking.sh
  3. # load the Antrea Docker image in the Nodes
  4. kind load docker-image projects.registry.vmware.com/antrea/antrea-ubuntu:latest
  5. # deploy Antrea
  6. ./hack/generate-manifest.sh --kind | kubectl apply -f -

Check that everything is working

After a few seconds you should be able to observe the following when running kubectl get -n kube-system pods -l app=antrea:

  1. NAME                                 READY   STATUS    RESTARTS   AGE
  2. antrea-agent-dgsfs                   2/2     Running   0          8m56s
  3. antrea-agent-nzsmx                   2/2     Running   0          8m56s
  4. antrea-agent-zsztq                   2/2     Running   0          8m56s
  5. antrea-controller-775f4d79f8-6tksp   1/1     Running   0          8m56s

Run the Antrea e2e tests

To run the Antrea e2e test suite on your Kind cluster, please refer to this document.

FAQ

Why is the YAML manifest different when using Kind

By default Antrea uses the Open vSwitch (OVS) kernel datapath type to provide connectivity between Pods, and each Kubernetes Node runs its own datapath (named br-int by default). Because of the very nature of Kind (which uses containers to run Kubernetes Nodes), it is not possible to use the kernel datapath type for Kind clusters. Instead, we use OVS in userspace mode, which requires some changes to the way Antrea is deployed. Most notably:

  • the tun device driver needs to be mounted in the antrea-ovs container
  • the Antrea agent’s ConfigMap needs to be updated so that the userspace (netdev) OVS datapath type is used
  • the Antrea agent’s Init Container no longer needs to load the openvswitch kernel module
  • the start_ovs script used by the antrea-ovs container needs to be replaced with the start_ovs_netdev script, which creates an additional bridge (br-phy) as required for OVS userspace tunneling

Why do I need to run the hack/kind-fix-networking.sh script on my host

The script is required for Antrea to work properly in a Kind cluster. It takes care of disabling TX hardware checksum offload for the veth interface (in the host’s network namespace) of each Kind Node. This is required when using OVS in userspace mode. Refer to this Antrea Github issue 14 for more information. For Linux hosts, the script is equivalent to running ethtool directly on the Linux host to disable TX checksum offload on each Node’s veth interface. On macOS, the script is equivalent to running ethtool in the Linux HyperKit VM which runs the Docker daemon, and within which the Node’s veth interfaces are created. The hack/kind-fix-networking.sh script uses a Linux Docker container with host networking to run ethtool, which means the script can be exactly the same for both OSs.