In the land of Software-Defined Networking (SDN) there are lots of options and approaches available. Many solutions are focused on network provider features (Open Contrail), just switching (Open vSwitch), or serving as a single controller that can do everything (Open Daylight).
Project Calico is positioning itself as a complete network solution to take care of everything an application tier will need to interconnect with embedded security features.
Project Calico is not just a network overlay which encapsulates traffic in another protocol so it can be handed off to layer 2 routing when traveling between hosts or data centers. Even other SDN solutions like Open vSwitch will often use protocols like VxLAN and GRE tunnels to handle this, which adds overhead to every packet, and complexity to the holistic solution. Project Calico actually runs as its own networking layer, and handles routing and switching at layer 3 so it avoids the overhead that encapsulation creates.
- Docker – http://docs.projectcalico.org/v2.2/getting-started/docker/
- rkt – http://docs.projectcalico.org/v2.2/getting-started/rkt/
Container Management Platform:
- Kubernetes – http://docs.projectcalico.org/v2.2/getting-started/kubernetes/
- Mesos – http://docs.projectcalico.org/v2.2/getting-started/mesos/
Server Management (including Virtual Servers)
- OpenStack – http://docs.projectcalico.org/v2.2/getting-started/openstack/
- Bare Metal – http://docs.projectcalico.org/v2.2/getting-started/bare-metal/bare-metal
Deploying into Kubernetes
Presumably, the most common use for Project Calico is applying it to handle intercontainer connectivity on Kubernetes (k8s).
Installing Project Calico using a Standard Hosted Install, where Calico has its own etcd cluster, is fairly straightforward, assuming you already have Kubernetes running.
- Download calico.yaml
- Configure etcd_endpoints in the provided ConfigMap to match your etcd cluster.
- Then simply apply the manifest by running:
kubectl apply -f calico.yaml
Kubernetes is now using Project Calico for its networking base.
Project Calico Interacting with External Networks
Now that the Kubernetes environment is running Project Calico, you may wait to allow access to or from existing network services, like the Internet. Because Project Calico is not only an overlay on top of the existing network, but also its own self-sufficient stack, it will need to be configured to route traffic.
There are several ways to accomplish this, which are covered in detail in the documentation.
For outbound only, the easiest choice is to configure NAT for each Calico pool.
For inbound connections, there are two options. The first, and more common, is using orchestration-specific options, especially when just starting out with the platform. For Kubernetes, this starts by creating and exposing Services.
The second option is using BGP. BGP will be preferred in larger organizations with existing expertise. While it is a tried-and-true protocol that networks have been using for decades, it has its own quirks.
Now that your Kubernetes environment has Project Calico up and running, and you know how to connect with the rest of the networks out there, it is time to leverage some other features that really make Project Calico shine. The biggest from a pure capability standpoint is the ability to apply network policies to control access at a container or pod level. Not having to deal with the latency, complexity, and additional costs around routing all traffic out to a physical firewall (as in traditional networking environments) will really showcase how much more agile software-defined networking allows you to be.