Install Calico for Windows on your Kubernetes cluster in approximately 5 minutes.
Concepts
Calico for Windows is a hybrid implementation that requires a Linux control node for Calico components, and a Windows cluster for Windows nodes.
Before you begin
Datastore requirements
Whether you use etcd or Kubernetes datastore (kdd), the datastore for the Windows node/Kubernetes cluster must be the same as the datastore for the Linux control node. (You cannot mix datastores in a Calico for Windows implementation.)
Kubernetes cluster requirements
Kubernetes clusters with versions 1.18, 1.17, or 1.16
Windows node requirements
Windows Server 1903 (AKA 19H1) build 18317 or greater, with Docker service enabled
Remote access to the Windows node via Remote Desktop Protocol (RDP) or Windows Remote Management (WinRM)
Additionally, for EKS:
The VPC controllers must be installed be installed to run Windows pods.
The Windows instance role must have access to secrets in the kube-system namespace.
Linux control node requirements
Installed with Calico v3.12+
If Calico networking is being used:
Networking must be VXLAN. (Note: for EKS, networking is set to none since AWS VPC networking is used.)
Configure strict affinity for clusters using Calico networking
For Linux control nodes using Calico networking, strict affinity must be set to true.
This is required to prevent Linux nodes from borrowing IP addresses from Windows nodes:
calicoctl ipam configure --strictaffinity=true
Install Calico for Windows
The following steps install a Kubernetes cluster on a single Windows node, with a Linux control node.
Kubernetes
The geeky details of what you get by default:
Policy
Calico
Calico Policy
Kubernetes network policies are implemented by network plugins rather than Kubernetes itself. Simply creating a network policy resource without a network plugin to implement it, will have no effect on network traffic.
The Calico plugin implements the full set of Kubernetes network policy features. In addition, Calico supports Calico network policies, providing additional features and capabilities beyond Kubernetes network policies. Kubernetes and Calico network policies work together seamlessly, so you can choose whichever is right for you, and mix and match as desired.
IPAM
Calico
Calico IPAM
How Kubernetes assigns IP address to pods is determined by the IPAM (IP Address Management) plugin being used.
The Calico IPAM plugin dynamically allocates small blocks of IP addresses to nodes as required, to give efficient overall use of the available IP address space. In addition, Calico IPAM supports advanced features such as multiple IP pools, the ability to specify a specific IP address range that a namespace or pod should use, or even the specific IP address a pod should use.
CNI
Calico
Calico CNI
The CNI (Container Network Interface) plugin being used by Kubernetes determines the details of exactly how pods are connected to the underlying network.
The Calico CNI plugin connects pods to the host networking using L3 routing, without the need for an L2 bridge. This is simple and easy to understand, and more efficient than other common alternatives such as kubenet or flannel.
Overlay
VXLAN
VXLAN Overlay
An overlay network allows pods to communicate between nodes without the underlying network being aware of the pods or pod IP addresses.
Packets between pods on different nodes are encapsulated using VXLAN, wrapping each original packet in an outer packet that uses node IPs, and hiding the pod IPs of the inner packet. This can be done very efficiently by the Linux kernel, but it still represents a small overhead, which you might want to avoid if running particularly network intensive workloads.
For completeness, in contrast, operating without using an overlay provides the highest performance network. The packets that leave your pods are the packets that go on the wire.
Routing
BGP
BGP Routing
BGP (Border Gateway Protocol) is used to dynamically program routes for pod traffic between nodes.
BGP is a standards-based routing protocol used to build the internet. It scales exceptionally well, and even the largest Kubernetes clusters represent a tiny amount of load compared to what BGP can cope with.
Calico can run BGP in three modes:
Full mesh - where each node talks BGP to each other, easily scaling to 100 nodes, on top of an underlying L2 network or using IPIP overlay
With route reflectors - where each node talks to one or more BGP route reflectors, scaling beyond 100 nodes, on top of an underlying L2 network or using IPIP overlay
Peered with TOR (Top of Rack) routers - in a physical data center where each node talks to routers in the top of the corresponding rack, scaling to the limits of your physical data center.
Datastore
Kubernetes
Kubernetes Datastore
Calico stores the operational and configuration state of your cluster in a central datastore. If the datastore is unavailable, your Calico network continues operating, but cannot be updated (no new pods can be networked, no policy changes can be applied, etc.).
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
The advantages of using Kubernetes as the datastore are:
It doesn’t require an extra datastore, so is simpler to install and manage
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 using etcd as the datastore 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.
?
Calico Deployment Options
Calico’s flexible modular architecture supports a wide range of deployment options, so you can select the best networking and network policy options for your specific environment. This includes the ability to run with a variety of CNI and IPAM plugins, and underlying networking options.
The Calico Getting Started guides default to the options most commonly used in each environment, so you don’t have to dive into the details unless you want to.
You can click on any deployment option to learn more.
EKS
The geeky details of what you get by default:
Policy
Calico
Calico Policy
Kubernetes network policies are implemented by network plugins rather than Kubernetes itself. Simply creating a network policy resource without a network plugin to implement it, will have no effect on network traffic.
The Calico plugin implements the full set of Kubernetes network policy features. In addition, Calico supports Calico network policies, providing additional features and capabilities beyond Kubernetes network policies. Kubernetes and Calico network policies work together seamlessly, so you can choose whichever is right for you, and mix and match as desired.
IPAM
AWS
AWS IPAM
How Kubernetes assigns IP address to pods is determined by the IPAM (IP Address Management) plugin being used.
The AWS IPAM plugin dynamically allocates small blocks of IP addresses to nodes as required, using IP addresses from the underlying VPC (Virtual Private Cloud). The AWS IPAM plugin is used in conjunction with the Amazon VPC CNI plugin to provide VPC native pod networking.
CNI
AWS
AWS CNI
The CNI (Container Network Interface) plugin being used by Kubernetes determines the details of exactly how pods are connected to the underlying network.
The AWS Amazon VPC CNI and IPAM plugins provide pods with IP addresses from the underlying VPC (Virtual Private Cloud) to provide a VPC-Native pod network. The AWS VPC is used to route pod traffic between nodes, and understands which pod IP address are located on which nodes. This avoids the need for an overlay, and typically has good network performance characteristics.
In addition, pod IPs are understood by the broader AWS network, so for example, VMs outside of the cluster can connect directly to any pod without going via a Kubernetes service if desired.
Overlay
No
No Overlay
Operating without using an overlay provides the highest performance network. The packets that leave your pods are the packets that go on the wire.
For completeness, in contrast, with an overlay network, packets between pods on different nodes are encapsulated using a protocol such as VXLAN or IPIP, wrapping each original packet in an outer packet that uses node IPs, and hiding the pod IPs of the inner packet. This can be done very efficiently by the Linux kernel, but it still represents a small overhead, which you might want to avoid if running particularly network intensive workloads.
Routing
VPC Native
VPC Native Routing
The underlying cloud VPC (Virtual Private Cloud) is used to route pod traffic between nodes, and understands which pod IP address are located on which nodes. This avoids the need for an overlay, and typically has good performance characteristics.
In addition, pod IPs are understood by the broader cloud network, so for example, VMs outside of the cluster can connect directly to any pod without going via a Kubernetes service if desired.
Datastore
Kubernetes
Kubernetes Datastore
Calico stores the operational and configuration state of your cluster in a central datastore. If the datastore is unavailable, your Calico network continues operating, but cannot be updated (no new pods can be networked, no policy changes can be applied, etc.).
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
The advantages of using Kubernetes as the datastore are:
It doesn’t require an extra datastore, so is simpler to install and manage
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 using etcd as the datastore 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.
?
Calico Deployment Options
Calico’s flexible modular architecture supports a wide range of deployment options, so you can select the best networking and network policy options for your specific environment. This includes the ability to run with a variety of CNI and IPAM plugins, and underlying networking options.
The Calico Getting Started guides default to the options most commonly used in each environment, so you don’t have to dive into the details unless you want to.
You can click on any deployment option to learn more.
Run install-calico-windows.ps1 for your datastore with parameters for your implementation.
You do not need to pass a parameter if the default value of the parameter is correct for you cluster.
Run install-calico-windows.ps1 for your datastore with parameters for your implementation.
You do not need to pass a parameter if the default value of the parameter is correct for you cluster.
Version of Kubernetes binaries to use. If value is empty string (default), the Calico for Windows installation script does not download Kubernetes binaries and run Kubernetes service. Use the default for managed public cloud.
””
DownloadOnly
Download without installing Calico for Windows. Set to yes to manually install and configure Calico for Windows. For example, Calico for Windows the hard way.
no
Datastore
Calico for Windows datastore type [kubernetes or etcdv3] for reading endpoints and policy information.
kubernetes
EtcdEndpoints
Comma-delimited list of etcd connection endpoints. Example: http://127.0.0.1:2379,http://127.0.0.2:2379. Valid only if Datastore is set to etcdv3.
””
ServiceCidr
Service IP range of the Kubernetes cluster. Not required for most managed Kubernetes clusters. Note: EKS has non-default value.
10.96.0.0/12
DNSServerIPs
Comma-delimited list of DNS service IPs used by Windows pod. Not required for most managed Kubernetes clusters. Note: EKS has a non-default value.
10.96.0.10
Congratulations! You now have a Kubernetes cluster with Calico for Windows and a Linux control node.
Next steps
You can now use the Calico Linux-based docs site for your documentation. Before you continue, review the Limitations and known issues to understand the features (and sections of documentation) that do not apply to Windows.