Documentation
Introduction
Cloud Deployment
Reference
- Antrea Network Policy
- antctl
- Architecture
- IPsec Configuration
- Securing Control Plane
- Troubleshooting
- OS-specific Known Issues
- OVS Pipeline
- Feature Gates
- Network Flow Visibility
- Traceflow Guide
- NoEncap and Hybrid Traffic Modes
- Egress Guide
- NodePortLocal Guide
- Versioning
- Antrea API Groups
- Antrea API Reference
Windows
Integrations
Cookbooks
Developer Guide
Project Information
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:
# "fix" the host's veth interfaces (for the different Kind Nodes)
kind get nodes | xargs ./hack/kind-fix-networking.sh
# deploy Antrea
kubectl apply -f https://github.com/antrea-io/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
./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:
./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:
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
disableDefaultCNI: true
podSubnet: 10.10.0.0/16
nodes:
- role: control-plane
- role: worker
- role: worker
Once you have created your configuration file (let’s call it kind-config.yml
),
create your cluster with:
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).
# "fix" the host's veth interfaces (for the different Kind Nodes)
kind get nodes | xargs ./hack/kind-fix-networking.sh
# load the Antrea Docker image in the Nodes
kind load docker-image projects.registry.vmware.com/antrea/antrea-ubuntu:latest
# deploy Antrea
./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
:
NAME READY STATUS RESTARTS AGE
antrea-agent-dgsfs 2/2 Running 0 8m56s
antrea-agent-nzsmx 2/2 Running 0 8m56s
antrea-agent-zsztq 2/2 Running 0 8m56s
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 theantrea-ovs
container needs to be replaced with thestart_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.