The Calico datastore
Calico has two datastore drivers you can choose from
- etcd - for direct connection to an etcd cluster
- Kubernetes - for connection to a Kubernetes API server
This guide uses the Kubernetes API datastore driver. The advantages of this driver when using Calico on Kubernetes are
- You can use Kubernetes RBAC to control access to Calico resources
- You can use Kubernetes audit logging to generate audit logs of changes to Calico resources
For completeness, the advantages of the etcd driver are
- Allows you to run Calico on non-Kubernetes platforms (e.g. OpenStack)
- Allows separation of concerns between Kubernetes and Calico resources, for example allowing you to scale the datastores independently
- Allows you to run a Calico cluster that contains more than just a single Kubernetes cluster, for example, bare metal servers with Calico host protection interworking with a Kubernetes cluster; or multiple Kubernetes clusters.
When using the Kubernetes API datastore driver, most Calico resources are stored as Kubernetes custom resources.
A few Calico resources are not stored as custom resources and instead are backed by corresponding native Kubernetes resources. For example, are Kubernetes pods.
Download and examine the list of Calico custom resource definitions, and open it in a file editor.
Create the custom resource definitions in Kubernetes.
To interact directly with the Calico datastore, use the calicoctl
client tool.
Download the
calicoctl
binary to a Linux host with access to Kubernetes.Configure
calicoctl
to access Kubernetes.export DATASTORE_TYPE=kubernetes
Test
Verify calicoctl
can reach your datastore by running
You should see output similar to
NAME
ip-172-31-37-123
ip-172-31-40-30
ip-172-31-42-47
ip-172-31-45-29
Nodes are backed by the Kubernetes node object, so you should see names that match kubectl get nodes
.
Try to get an object backed by a custom resource
You should see an empty result
NAME CIDR SELECTOR