Installing Calico for policy and networking (recommended)

4 MINUTE READ

Before you begin

Ensure that you have a Kubernetes cluster that meets the Calico system requirements. If you don’t, follow the steps in Using kubeadm to create a cluster.

If you’re installing on CoreOS, you should also see this FAQ as there are required changes to the provided manifests.

Installing Calico for policy and networking

Selecting your datastore type and number of nodes

The procedure differs according to the type of datastore you want Calico to use and the number of nodes. Refer to the section that matches your desired datastore type and number of nodes.

Installing with the Kubernetes API datastore—50 nodes or less

  1. Download the Calico networking manifest for the Kubernetes API datastore.

    $ curl https://docs.projectcalico.org/archive/v3.12/manifests/calico.yaml -O

  2. If you are using pod CIDR 192.168.0.0/16, skip to the next step. If you are using a different pod CIDR, use the following commands to set an environment variable called POD_CIDR containing your pod CIDR and replace 192.168.0.0/16 in the manifest with your pod CIDR.

    $ POD_CIDR="<your-pod-cidr>" \
sed -i -e "s?192.168.0.0/16?$POD_CIDR?g" calico.yaml

  3. Apply the manifest using the following command.

    $ kubectl apply -f calico.yaml

  4. If you wish to enforce application layer policies and secure workload-to-workload communications with mutual TLS authentication, continue to Enabling application layer policy (optional).

Installing with the Kubernetes API datastore—more than 50 nodes

  1. Download the Calico networking manifest for the Kubernetes API datastore.

    $ curl https://docs.projectcalico.org/archive/v3.12/manifests/calico-typha.yaml -o calico.yaml

  2. If you are using pod CIDR 10.244.0.0/16, skip to the next step. If you are using a different pod CIDR, use the following commands to set an environment variable called POD_CIDR containing your pod CIDR and replace 10.244.0.0/16 in the manifest with your pod CIDR.

    $ POD_CIDR="<your-pod-cidr>" \
sed -i -e "s?10.244.0.0/16?$POD_CIDR?g" calico-typha.yaml

  3. Modify the replica count in theDeployment named calico-typha to the desired number of replicas.

    apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: calico-typha
  ...
spec:
  ...
  replicas: <number of replicas>

    We recommend at least one replica for every 200 nodes and no more than 20 replicas. In production, we recommend a minimum of three replicas to reduce the impact of rolling upgrades and failures. The number of replicas should always be less than the number of nodes, otherwise rolling upgrades will stall. In addition, Typha only helps with scale if there are fewer Typha instances than there are nodes.

    Warning: If you set typha_service_name without increasing the replica count from its default of 0 Felix will try to connect to Typha, find no Typha instances to connect to, and fail to start.

  4. Apply the manifest.

    $ kubectl apply -f calico.yaml

  5. If you wish to enforce application layer policies and secure workload-to-workload communications with mutual TLS authentication, continue to Enabling application layer policy (optional).

Installing with the etcd datastore

  1. Download the Calico networking manifest for etcd.

    $ curl https://docs.projectcalico.org/archive/v3.12/manifests/calico-etcd.yaml%20-o%20calico.yaml

  2. If you are using pod CIDR 10.244.0.0/16, skip to the next step. If you are using a different pod CIDR, use the following commands to set an environment variable called POD_CIDR containing your pod CIDR and replace 10.244.0.0/16 in the manifest with your pod CIDR.

    $ POD_CIDR="<your-pod-cidr>" \
sed -i -e "s?10.244.0.0/16?$POD_CIDR?g" calico-etcd.yaml

  3. In the ConfigMap named calico-config, set the value of etcd_endpoints to the IP address and port of your etcd server.

    Tip: You can specify more than one using commas as delimiters.

  4. Apply the manifest using the following command.

    $ kubectl apply -f calico.yaml

  5. If you wish to enforce application layer policies and secure workload-to-workload communications with mutual TLS authentication, continue to Enabling application layer policy (optional).