Project Calico provides layer 3 networking and network isolation for scalable Kubernetes and container workloads. This document demonstrates how to set up and test network isolation between rkt containers using Calico on a multi-node cluster. It describes creating Calico networking configurations and profiles for two rkt networks, deploying containers to each network on different nodes, and validating that containers can communicate within but not across networks due to Calico network policies.

1. Anirban Sen Chowdhary

2. Project Calico, a Tigera open-source project that provides a
layer 3 network implementation, aimed at scalable datacenter
deployments.
This slides explains provides a simple way to try out rkt
network isolation with Calico. It requires a cluster of nodes
configured with Calico networking, and expects that you
have rkt installed and calicoctl configured to interact with the
cluster.

3. Calico with rkt
Calico supports networking and network policy in a pure rkt container environment.
1) Verifying Calico service is running:
Installation should have installed and started the Calico service on each node. We can
check that it's running using sudo rkt list.

4. Calico with rkt
Calico supports networking and network policy in a pure rkt container environment.
2) Creating the networks:
We can configure multiple networks when we are using rkt. Each network can
represented by a configuration file in /etc/rkt/net.d/.
We can define a rkt network for Calico by creatinga configuration file
in /etc/rkt/net.d/.
1) Each network needs to be given a unique "name".
2) Using Calico networking, we need to specify "type": "calico"
3) Using Calico IPAM, specify "type": "calico-ipam" in the "ipam" section.

5. Calico creates an identically named profile for each Calico-rkt network.
By default the policy that is specified in the profile allows full communication between
all containers within the network but restricts ingress traffic from a containers that is
located on other networks.
This worked example creates two rkt networks. We will run these commands on
both calico-01 and calico-02:

6. And on calico-02:

7. 3) Create test container :
Now the networks is created, so we can start some containers.
We'll create a container on calico-01 in network1, and then we will create containers
on calico-02 in each network so that we can check connectivity to the first container.
The container we create on calico-01 will run a busybox image running a simple HTTP
daemon httpd serving up the containers local filesystem over HTTP.

8. On calico-01
We will create the container in network1, we will include a suffix :IP=192.168.0.0, which is used to pass
the IP environment through to the network plugin which Calico IPAM uses to assign a specific IP address.
We use a fixed IP address.
Use rkt list to see the IP:
We can see that a busybox container running on the network network1 with an IP address of 192.168.0.0.
We see that rkt also creates a second network called default-restricted - this is used for communication
with the rkt service

9. 4) Validating intra-network connectivity :
Since we created the container on calico-01 and we know its IP address, we can now
able to access it using wget from containers running on either host, as long as they are
created in the same network.
Expected output will:
We can repeat this command on calico-01 and check that access works the same

10. 5) Verify Calico profiles were created
We can use the calicoctl get profiles command line tool to verify that the Calico CNI
plugin created two profiles, network1 and network2.

11. For more information visit
https://www.projectcalico.org/
https://docs.projectcalico.org/v2.6/introduction/
https://blog.tigera.io/tagged/calico