Introduction to Calico Project: Kubernetes Networking and Security Made Simple


When working with Kubernetes, managing networking and security can get complicated. By default, Kubernetes allows all pods to communicate with each other, which is great in terms of flexibility but raises security concerns. Hence, in this blog, we will explore Project Calico and how it enhances Kubernetes networking and security. Before diving into Calico, we must first understand what CNI is. Let’s get started!
CNI (Container Networking Interface):
Imagine you have multiple houses in a city. Each house needs a way to communicate with others—via roads. Similarly, in Kubernetes, each pod (container) needs a way to communicate with other pods.
CNI (Container Network Interface) is like the road system for containers. It ensures that every container in your cluster can connect to other containers, services, and the internet. While CNI lays the roads, Calico (a CNI plugin) goes a step further by providing traffic rules, security, and observability to keep the network safe and efficient.
What is the need of Calico?
Let’s assume you have an e-commerce app running on Kubernetes, with services like:
A frontend (React) that users interact with
A backend (Go API) that processes requests
A database (PostgreSQL) storing user data
Without proper controls, any pod can talk to any other pod. If a hacker gains access to a compromised pod, they could reach sensitive services like your database! This is where Calico comes in as a saviour🛡️
By using Calico Network Policies, we can define rules to restrict communication between services. Example: Network Policy to Restrict Access.
Let's say we want to:
Allow only the backend service to access the database.
Block all other services from reaching the database.
We can create the following Calico network policy like the one below:
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
name: allow-backend-to-db
namespace: database
spec:
selector: app == "postgres"
ingress:
- action: Allow
source:
namespaceSelector: name == "backend"
selector: app == "backend"
- action: Deny
# P.S Don't worry if you aren't aware about the code. We will get to it in the later part.
How this Works?
Calico uses Network Policies to control pod-to-pod communication. These policies define which pods can talk to each other based on labels, namespaces, or IP addresses.
Denies all other pods (including frontend) from connecting to the database.
Now we can easily understand What is Calico? So….
What is Calico?
Project Calico is an open-source networking and security solution by Tigera designed for containers, Kubernetes, and cloud-native applications. It provides a way to control network traffic, enforce security policies, and ensure smooth communication between pods in a cluster.
Advantages of using Calico
Improves security by restricting unauthorized access.
Provides better control over network traffic.
Works in hybrid/multi-cloud environments.
Enhances observability by providing logs & metrics on network activity.
Components of Calico
Felix (The Enforcer)
Felix is the brain behind enforcing network policies. It ensures that the rules you define (like allowing or blocking traffic) are correctly applied to the pods.
Typha (The Traffic Manager)
When you have a large Kubernetes cluster, Typha helps reduce the load on the API server by efficiently distributing updates to all nodes.
BGP (The Traffic Router)
Calico uses BGP (Border Gateway Protocol) to share routing information between nodes, ensuring that pods can communicate across different nodes in the cluster.
IPAM (The Address Manager)
IP Address Management (IPAM) is responsible for assigning unique IP addresses to pods so they can communicate within the network.
BIRD (The Route Distributor)
BIRD is the routing daemon used in Calico when BGP is enabled. It helps exchange network routes between Kubernetes nodes.
Calico Network Policies (The Rulebook)
These policies define who can talk to whom within the cluster. Example: Only backend services can talk to the database, while others are blocked.
Calico API Server (The Configuration Hub)
Lets you manage Calico resources directly with
kubectl
.Calicoctl (The Command Center)
A CLI tool used to manage and configure Calico, allowing you to create, update, and inspect network policies.
CNI Plugin (The Connector)
The CNI plugin integrates Calico with Kubernetes by setting up network interfaces, assigning IP addresses, and ensuring pods can communicate.
Kube-Controllers (The Sync Master)
Monitors the Kubernetes API and performs actions based on cluster state.
Confd (The Config Generator)
Confd watches for changes in etcd and updates Calico’s configuration files dynamically, ensuring network settings remain up to date.
Architecture of Calico
Data Plane (Handles Traffic Flow) :
The data plane is responsible for actual packet forwarding and enforcing network policies. Calico supports multiple data planes, including Linux eBPF mode for high-performance, kernel-bypass networking, Linux IPTables mode for packet filtering and NAT, and Windows Dataplane for enabling Windows-based Kubernetes networking.
Control Plane (Manages Configuration)
The control plane manages Calico's networking and security policies, ensuring nodes and pods get the correct configurations. It includes the Calico API Server, which provides the API for managing Calico resources, Kube-Controller, which ensures Kubernetes resources are correctly represented in Calico’s datastore, and confd, which updates configuration dynamically based on cluster state.
Routing & IP Management (Ensures Pod Communication)
This layer ensures that each pod receives a unique IP address and traffic is routed correctly.
(BGP, BIRD, IPAM are part of it)
Policy Enforcement (Manages Security)
Calico ensures secure communication between pods and external services by enforcing network policies. Felix, the core Calico agent, applies these policies at the node level, while Network Policies define rules for traffic flow, ensuring proper isolation and security.
CNI Plugin (Integrates with Kubernetes)
The Calico CNI plugin configures network interfaces, assigns IPs, and connects pods to the cluster network. It ensures that networking policies are applied correctly when a pod starts.
📌 How it Works Together
Pods are scheduled on Kubernetes nodes.
The CNI plugin assigns an IP and sets up networking.
IPAM manages IP addresses to avoid conflicts.
Routing (BGP/BIRD) ensures pod-to-pod communication across nodes.
Felix enforces security policies, blocking unauthorized traffic.
Calico API Server & Controllers sync configurations with Kubernetes.
This modular and scalable architecture allows Calico to deliver high-performance networking with strong security controls in Kubernetes!
Installing Calico
Check out the Calico intallation guide here: https://docs.tigera.io/calico/latest/operations/calicoctl/install
Verify your download on Minikube
Check if Calico Pods are Running
Run the following command to check if all Calico pods are running:
kubectl get pods -n kube-system -l k8s-app=calico-node
Verify Calico DaemonSet
Check if the Calico DaemonSet is correctly deployed:
kubectl get daemonset -n kube-system calico-node
Verify calicoctl download
calicoctl version
What’s Next?
Now that we've covered the basics of Project Calico and how it enhances Kubernetes networking and security, it's time to dive deeper! 🚀
In the upcoming blogs, we will explore:
🔹 Calico Networking in Depth
🔹 Mastering Calico Network Policies
🔹 Advanced Calico Features
🔹 Monitoring & Troubleshooting
🔹 Hands-on Projects
Stay tuned as we move Calico from theory to practical implementation! If you've made it this far, thank you for finding this blog engaging and helpful. Please consider subscribing to my newsletter to receive my blogs directly in your inbox 📬.
Subscribe to my newsletter
Read articles from Sahil Naik directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

Sahil Naik
Sahil Naik
💻 Sahil learns, codes, and automates, documenting his journey every step of the way. 🚀