Deploying Antrea on a Kind cluster

    To deploy a released version of Antrea on an existing Kind cluster, you can simply use the same command as for other types of clusters:

    To create a simple two worker Node cluster and deploy a released version of Antrea, use:

    1. kubectl apply -f https://github.com/antrea-io/antrea/releases/download/<TAG>/antrea.yml

    Or, for the latest version of Antrea, use:

    1. ./ci/kind/kind-setup.sh create <CLUSTER_NAME>
    2. kubectl apply -f https://raw.githubusercontent.com/antrea-io/antrea/main/build/yamls/antrea.yml

    The kind-setup.sh script may execute kubectl commands to set up the cluster, and requires that kubectl be present in your PATH.

    To specify a different number of worker Nodes, use --num-workers <NUM>. To specify the IP family of the kind cluster, use --ip-family <ipv4|ipv6|dual>. To specify the Kubernetes version of the kind cluster, use --k8s-version <VERSION>. To specify the Service Cluster IP range, use --service-cidr <CIDR>.

    1. docker pull projects.registry.vmware.com/antrea/antrea-ubuntu:<TAG>
    2. ./ci/kind/kind-setup.sh --images projects.registry.vmware.com/antrea/antrea-ubuntu:<TAG> create <CLUSTER_NAME>
    3. kubectl apply -f https://github.com/antrea-io/antrea/releases/download/<TAG>/antrea.yml

    The kind-setup.sh is a convenience script typically used by developers for testing. For more information on how to create a Kind cluster manually and deploy Antrea, read the following sections.

    As an Antrea developer

    If you are an Antrea developer and you need to deploy Antrea with your local changes and locally built Antrea image, use:

    kind-setup.sh allows developers to specify the number of worker Nodes, the docker bridge networks/subnets connected to the worker Nodes (to test Antrea in different encap modes), and a list of docker images to be pre-loaded in each Node. For more information on usage, run:

    As a developer, you do usually want to provide the --antrea-cni flag, so that the kind-setup.sh can generate the appropriate Antrea YAML manifest for you on the fly, and apply it to the created cluster directly.

    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
    1. kind create cluster --config kind-config.yml

    Deploy a local build of Antrea to your Kind cluster (for developers)

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

    1. # load the Antrea Docker image in the Nodes
    2. # deploy Antrea
    3. kubectl apply -f build/yamls/antrea.yml

    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

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

    Antrea Agents are not starting on macOS, what could it be?

    Some older versions of Docker Desktop did not include all the required Kernel modules to run the Antrea Agent, and in particular the openvswitch Kernel module. See for more information. This issue does not exist with recent Docker Desktop versions (>= 2.5).

    At this time, we do not officially support Antrea for Kind clusters running on Windows hosts. In recent Docker Desktop versions, the default way of running Linux containers on Windows is by using the . However, the Linux Kernel used by default in WSL 2 does not include all the required Kernel modules to run the Antrea Agent, and in particular the openvswitch Kernel module. There are 2 different ways to work around this issue, which we will not detail in this document:

    • build a custom Kernel for WSL, with the required Kernel configuration:

      1. CONFIG_NETFILTER_XT_MATCH_RECENT=y
      2. CONFIG_NETFILTER_XT_TARGET_CT=y
      3. CONFIG_OPENVSWITCH=y
      4. CONFIG_OPENVSWITCH_GRE=y
      5. CONFIG_OPENVSWITCH_VXLAN=y