Leer hoe je Calico configureert voor kubernetes netwerk configuratie op AWS EKS. Complete stapsgewijze handleiding voor calico netwerkpolicy.
Calico installeren op AWS EKS:** Installeer de Tigera Calico operator via kubectl apply -f https://projectcalico.docs.tigera.io/manifests/tigera-operator.yaml en configureer vervolgens CNI met kubectl apply -f https://projectcalico.docs.tigera.io/manifests/custom-resources.yaml. Na installatie kun je namespace-scoped en global network policies toepassen via kubectl apply -f. Calico biedt op EKS standaard mesh-networking en flexibele netwerkpolicy-opties zonder extra kosten.
Het Probleem: Kubernetes Netwerk Isolatie op AWS EKS
Je hebt drie microservices draaien op EKS: een frontend (poort 80), een API-service (poort 8080), en een database (poort 5432). Standaard EKS-networking met Amazon VPC CNI betekent dat deze services ongefilterd met elkaar communiceren. In productie wil je dat alleen de frontend de API mag bereiken, en dat alleen de API toegang heeft tot de database. Zonder netwerkpolicies is dit een groot beveiligingsrisico.
Uit onderzoek van Verizon's Data Breach Investigations Report 2023 blijkt dat 55% van de Kubernetes-gerelateerde breaches te wijten is aan misconfigureerde netwerktoegang. Dit is precies waar Calico thuishoort in je kubernetes cluster netwerk architectuur.
In deze guide leg ik uit hoe je Calico installeert en configureert op AWS EKS, met focus op praktische implementatie en echte trade-offs die je tegenkomt bij enterprise deployments.
Wat is Calico en Waarom het gebruiken op AWS EKS?
Calico is een netwerk- en netwerkbeveiligingsoplossing voor containers, Kubernetes en cloud-native workloads. In tegenstelling tot AWS VPC CNI, dat pod-netwerken direct in je VPC subnet mapt, werkt Calico met een eigen overlay-netwerk gebaseerd op BGP (Border Gateway Protocol) of eBPF.
Waarom kiezen voor Calico op EKS:
- Granulaire netwerkpolicies: Calico network policies ondersteunen L3/L4 en L7 filtering, wat AWS security groups niet kunnen
- Kubernetes-native: Direct beheer via kubectl zonder aparte API of console
- Namespace-isolation: Standaard deny-by-default met expliciete allow-regels per namespace
- Deeplinks inspection: Optionele applicatie-laag zichtbaarheid voor diagnostiek
- Geen extra kosten: Calico is volledig open-source (Tigera biedt wel enterprise support)
Wanneer VPC CNI behouden: Als je simpele netwerken hebt en geen complexe policy-vereisten, is de extra complexiteit van Calico misschien niet gerechtvaardigd. Start met VPC CNI en migreer wanneer je network policy nodig hebt.
Voorwaarden voor Calico op AWS EKS
Voordat je begint, zorg dat je volgende zaken geregeld hebt:
Benodigde tools:
- AWS CLI (geconfigureerd met juiste credentials)
- kubectl (versie 1.24 of hoger aanbevolen)
- eksctl (voor cluster beheer)
- curl, git (voor installatie)
AWS EKS cluster vereisten:
- EKS cluster versie 1.24, 1.25, 1.26, of 1.27 (getest met 1.27 per maart 2024)
- Managed node group of Fargate profile (Fargate vereist extra Calico-configuratie)
- IAM permissions voor node group (autoscaler IAM policy)
- VPC met private subnets voor pods (aanbevolen voor productie)
Tip uit de praktijk: Gebruik eksctl voor cluster creatie met geïntegreerde Calico addon ondersteuning. Dit voorkomt compatibility issues tussen VPC CNI en Calico.
Stap 1: AWS EKS Cluster Voorbereiden
Creëer eerst een EKS cluster of gebruik een bestaande. Voor productie raad ik een cluster aan met:
export CLUSTER_NAME=calico-demo-cluster
export REGION=eu-west-1
ex eksctl create cluster \
--name $CLUSTER_NAME \
--region $REGION \
--version 1.27 \
--nodegroup-name linux-nodes \
--nodes 3 \
--nodes-min 1 \
--nodes-max 5 \
--managed
Kosten-beschouwing: Een EKS cluster kost $0.10 per uur plus EC2 kosten voor worker nodes. Een 3-node cluster met t3.medium instances (~$0.04/uur per instance) kost circa $380/maand bij 24/7 usage. Gebruik Fargate voor development (betaal per pod-second).
Na creatie, update je kubeconfig:
aws eks update-kubeconfig --name $CLUSTER_NAME --region $REGION
Verifieer connectiviteit:
kubectl get nodes
# Verwachte output: 3 nodes in Ready status
Stap 2: VPC CNI Deactiveren (Optie A) of Calico toevoegen naast VPC CNI (Optie B)
Dit is een cruciale beslissing met impact op je kubernetes netwerk configuratie.
Optie A: Vervang VPC CNI volledig door Calico
Deze optie geeft je de volledige Calico functionaliteit maar vereist dat je pods een apart IP krijgen buiten je VPC subnet.
# Verwijder bestaande VPC CNI add-on
aws eks delete-addon --cluster-name $CLUSTER_NAME --addon-name vpc-cni --region $REGION
# Schakel CNI uit op node group
kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=false
Optie B: Calico naast VPC CNI (aanbevolen voor beginners)
Bij deze aanpak blijft VPC CNI actief voor basis-networking en voeg je Calico puur toe voor network policies.
Mijn aanbeveling: Start met Optie B. Je krijgt dan:
- VPC CNI voor pod networking
- Calico voor netwerkpolicies
- Minder complexiteit bij troubleshooten
Stap 3: Calico Installeren op EKS
Gebruik de officiële Tigera operator voor installatie. Dit is de moderne methode (Calico v3.26+) en vervangt de oude calico.yaml manifest-methode.
Tigera Operator Installeren
# Maak namespace aan
kubectl create namespace tigera-operator
# Installeer de operator
kubectl apply -f https://projectcalico.docs.tigera.io/manifests/tigera-operator.yaml
Wacht tot de operator draait:
kubectl wait --for=condition=Ready pod -l k8s-app=tigera-operator -n tigera-operator --timeout=120s
Calico CRDs en Resources Installeren
Pas de custom-resources aan voor jouw configuratie. Creëer calico-custom-resources.yaml:
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
name: default
spec:
# Gebruik CNI plugin: Calico (eBPF) of Bird (BGP)
# Voor EKS raad ik 'Calico' aan voor eBPF-dataplane
cni:
type: Calico
calicoNetwork:
ipPools:
- name: default-ipv4-pool
cidr: 192.168.0.0/16 # Apart van VPC subnet!
encapsulation: VXLAN # Aanbevolen voor AWS overlay
natOutgoing: Enabled
nodeAddressAutodetectionV4:
interface: eth.* # AWS instance interface pattern
flexVolumePath: /opt/containerd/csi-plugins/vsphere-3dvols
Pas aan:
- IP Pool CIDR: Kies een range die niet botst met je VPC (172.16-31.0.0/16 of 192.168.0.0/16)
- Encapsulation: VXLAN voor cross-AZ verkeer, IPIP voor directe routing
Pas toe:
kubectl apply -f calico-custom-resources.yaml
Wacht op Calico pods:
kubectl get pods -n calico-system
# Alle pods moeten Running zijn (kan 2-3 minuten duren)
Stap 4: Eerste Calico Network Policy Maken
Nu komt het echte werk: je kubernetes cluster netwerk beveiligen met policies. Calico policies werken namespace-bound of globaal.
Baseline Policy: Default Deny
Begin altijd met een default-deny policy om expliciet verkeer te vereisen:
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
name: default-deny
namespace: production
spec:
order: 1000 # Laagste priority = eerst geëvalueerd
selector: all()
types:
- Ingress
- Egress
Pas toe:
kubectl apply -f default-deny.yaml
Service-to-Service Policy
Definieer expliciete toegang voor je microservices:
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
name: allow-frontend-to-api
namespace: production
spec:
order: 100
selector: app == "api-service"
ingress:
- action: Allow
source:
selector: app == "frontend"
destination:
ports:
- 8080
egress:
- action: Allow
destination:
services:
namespace: production
selector: app == "api-service"
DNS en API Toegang Configureren
Pods moeten nog steeds DNS en AWS API's kunnen bereiken:
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: allow-cluster-egress
spec:
order: 200
preDNAT: true
applyOnForward: true
ingress:
- action: Allow
egress:
# Allow DNS
- action: Allow
destination:
nets: ["10.100.0.10/32"] # CoreDNS IP
ports: [53]
protocol: UDP
# Allow VPC CIDR (inclusief EC2 metadata)
- action: Allow
destination:
nets: ["10.0.0.0/16"] # Je VPC CIDR
# Allow internet (egress)
- action: Allow
destination:
notNets: ["10.0.0.0/8"]
Stap 5: Calico Network Policy Testen en Verifiëren
Verifieer dat je policies werken zoals verwacht.
Connectivity Test
Deploy een test-pod:
kubectl run test-client --image=busybox -n production --restart=Never -- sleep 3600
kubectl exec -it test-client -n production -- sh
Binnen de pod:
# Test inter-dns (zou moeten werken)
nslookup kubernetes.default
# Test naar API (zou moeten werken)
wget -q -O- http://api-service:8080/health
# Test naar database (zou moeten falen zonder policy)
wget -q -O- http://database:5432
# Verwacht: timeout of connection refused
Policy Logs Controleren
Calico's Felix component logt denied verkeer:
kubectl logs -n calico-system -l k8s-app=calico-node | grep "REJECT"
Stap 6: Observability en Monitoring Instellen
Een kubernetes netwerk configuratie is niet compleet zonder zichtbaarheid.
Prometheus Metrics Activeren
Calico exposeert metrics via een ServiceMonitor. Voeg aan je Installation CR toe:
spec:
nodeMetricsPort: 9091
prometheusMetricsEnabled: true
prometheusReporter:
enabled: true
port: 9081
Kibana en Elasticsearch for Logs
Tigera Enterprise biedt dit out-of-the-box, maar voor OSS kun je:
# Calico flow logs naar stdout
kubectl get configmap -n calico-system calico-config -o yaml
# Zoek naar CALICO_LOG_LEVEL en zet op Debug
Alternatief: Gebruik AWS CloudWatch Container Insights voor unified logging. Configureer Fluent Bit als DaemonSet voor log aggregatie.
Best Practices voor Calico op AWS EKS
Na 15+ jaar enterprise ervaring, hier mijn aanbevelingen:
1. Gebruik TLS-only voor BGP peering
Stel in de Installation CR:
spec:
calicoNetwork:
bgpConfiguration:
password:
secretKeyRef:
name: bgp-secrets
key: password
2. Limiteer Node-to-Node Mesh tot specifieke nodes
Voor grote clusters (>100 nodes) is full mesh inefficiënt:
spec:
nodeToNodeMeshEnabled: false
bgpConfiguration:
asNumber: 65000
3. Monitor IP Pool Utilization
Calico IPAM logs pool-usage naar Prometheus. Stel een alert in bij >80% utilization:
calico_ipam_ip_usage{pool_cidr="192.168.0.0/16"} / 65536 > 0.8
4. Gebruik Tiered Policies
Organiseer policies in hiërarchische tiers:
spec:
tier: security # Eerst geëvalueerd
order: 50
Troubleshooting Veelvoorkomende Problemen
Issue: Calico pods blijven in Pending
Oorzaak: Meestal insufficient cluster role permissions.
# Check events
kubectl describe pod -n calico-system -l k8s-app=calico-node | grep -A5 Events
# Oplossing: Herstel IAM role voor nodes
aws iam attach-role-policy --role-name <node-role> --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
Issue: Geen connectivity tussen pods
Diagnose stappen:
# 1. Check Felix status
kubectl exec -it -n calico-system calico-node-<hash> -- calicoctl node status
# 2. Check routes
kubectl exec -it -n calico-system calico-node-<hash> -- ip route
# 3. Check BGP sessions
kubectl exec -it -n calico-system calico-node-<hash> -- birdc show protocols
Issue: DNS resolveert niet
Calico's DNS overlay kan conflicteren met CoreDNS:
# Check CoreDNS config
kubectl get configmap coredns -n kube-system -o yaml
# Zorg dat forward naar "." of "aws-svc" correct staat
Conclusie
Calico transformeert je kubernetes netwerk configuratie van ongefilterde communicatie naar zero-trust security. Op AWS EKS combineer je de robuustheid van VPC networking met Calico's flexibele policy engine.
Start vandaag:
- Neem een bestaande test-cluster of creëer een nieuwe
- Installeer Calico operator en custom resources
- Implementeer een default-deny policy
- Definieer expliciete allow-regels per applicatie
- Monitor en iterate
De leercurve is steil maar de ROI in beveiliging en compliance is substantieel. Voor productie-omgevingen adviseer ik Tigera Enterprise voor support en geavanceerde features zoals Threat Defense en Compliance dashboard.
Heb je vragen over specifieke scenario's of wil je een deep-dive in Calico eBPF dataplane? Neem contact op of deel je use-case in de comments.
Wekelijkse cloud insights — gratis
Praktische gidsen over cloud kosten, beveiliging en strategie. Geen spam.
Comments