Parte 2: Arquitectura

Versiones compatibles: Calico v3.29+ / Kubernetes 1.28+ Última actualización: February 23, 2026

Descripción general

Esta sección ofrece una exploración detallada de la arquitectura de Calico. Comprender cómo funciona e interactúa cada componente es esencial para el despliegue, la resolución de problemas y la optimización eficaces de Calico en entornos de producción.

Diagrama completo de la arquitectura

Calico Architecture

Felix: el agente de Calico

Felix es el agente principal de Calico que se ejecuta en cada nodo del clúster. Es responsable de programar rutas y ACL (listas de control de acceso) en el host para proporcionar la conectividad deseada y aplicar las políticas de red.

Responsabilidades de Felix

Funciones principales

Programación de rutas: administra las rutas para los bloques CIDR de Pod
Aplicación de ACL: programa reglas de iptables/nftables/eBPF para las políticas de red
Administración de interfaces: configura las interfaces de endpoint de workload
Informes de estado: informa el estado de los nodos y endpoints al datastore
Coordinación de IPAM: administra la asignación de direcciones IP para los workloads locales

Opciones de plano de datos de Felix

Felix admite varios backends de plano de datos:

Plano de datos	Descripción	Ideal para
iptables	Firewall tradicional de Linux	Compatibilidad, despliegues maduros
nftables	Firewall moderno de Linux	Kernels más recientes, mejor rendimiento
eBPF	Programable en el kernel	Máximo rendimiento, reemplazo de kube-proxy

Recurso FelixConfiguration

yaml

apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  # Logging configuration
  logSeverityScreen: Info
  logSeverityFile: Warning
  logFilePath: /var/log/calico/felix.log

  # Data plane selection
  bpfEnabled: false                    # Set true for eBPF data plane
  bpfDataIfacePattern: ^((en|wl|eth).*|bond[0-9]+)$
  bpfConnectTimeLoadBalancingEnabled: true
  bpfExternalServiceMode: Tunnel

  # iptables configuration
  iptablesBackend: Auto               # Auto, Legacy, NFT
  iptablesRefreshInterval: 90s
  iptablesPostWriteCheckIntervalSecs: 1
  iptablesLockFilePath: /run/xtables.lock
  iptablesLockTimeoutSecs: 0
  iptablesLockProbeIntervalMillis: 50

  # Performance tuning
  ipipMTU: 1440
  vxlanMTU: 1410
  wireguardMTU: 1420

  # Health and metrics
  healthEnabled: true
  healthPort: 9099
  prometheusMetricsEnabled: true
  prometheusMetricsPort: 9091
  prometheusGoMetricsEnabled: true
  prometheusProcessMetricsEnabled: true

  # Policy configuration
  defaultEndpointToHostAction: Drop
  failsafeInboundHostPorts:
    - protocol: TCP
      port: 22
    - protocol: UDP
      port: 68
  failsafeOutboundHostPorts:
    - protocol: UDP
      port: 53
    - protocol: UDP
      port: 67

  # Interface configuration
  interfacePrefix: cali
  chainInsertMode: Insert

  # Reporting
  reportingIntervalSecs: 30
  reportingTTLSecs: 90

Estructura de reglas de iptables de Felix

Felix organiza las reglas de iptables en cadenas para un procesamiento eficiente:

                         ┌─────────────────────────────────────────┐
                         │              FORWARD Chain              │
                         └─────────────────┬───────────────────────┘
                                           │
                         ┌─────────────────▼───────────────────────┐
                         │          cali-FORWARD (Calico)          │
                         └─────────────────┬───────────────────────┘
                                           │
              ┌────────────────────────────┼────────────────────────────┐
              │                            │                            │
┌─────────────▼─────────────┐ ┌────────────▼────────────┐ ┌─────────────▼─────────────┐
│   cali-from-wl-dispatch   │ │   cali-to-wl-dispatch   │ │    cali-from-host-ep     │
│  (from workload traffic)  │ │  (to workload traffic)  │ │   (from host endpoints)   │
└─────────────┬─────────────┘ └────────────┬────────────┘ └─────────────┬─────────────┘
              │                            │                            │
┌─────────────▼─────────────┐ ┌────────────▼────────────┐ ┌─────────────▼─────────────┐
│    cali-fw-caliXXXXXX     │ │    cali-tw-caliXXXXXX   │ │    Per-endpoint policy    │
│    (per-endpoint rules)   │ │   (per-endpoint rules)  │ │          chains           │
└───────────────────────────┘ └─────────────────────────┘ └───────────────────────────┘

Flujo de datos de Felix

BIRD: demonio de enrutamiento BGP

BIRD (BIRD Internet Routing Daemon) es el demonio BGP que Calico utiliza para distribuir rutas entre nodos.

BIRD en la arquitectura de Calico

Tipos de sesión BGP

Tipo de sesión	Caso de uso	Configuración
Malla de nodo a nodo	Predeterminado para clústeres pequeños	Automática, malla completa
Route Reflector	Clústeres grandes (100+ nodos)	Nodos RR dedicados
Peering externo	Integración on-premises	Configuración manual de peer BGP

Ejemplos de configuración BGP

Malla de nodo a nodo (predeterminada)

yaml

apiVersion: projectcalico.org/v3
kind: BGPConfiguration
metadata:
  name: default
spec:
  logSeverityScreen: Info
  nodeToNodeMeshEnabled: true
  asNumber: 64512

Configuración de Route Reflector

yaml

# Disable node-to-node mesh
apiVersion: projectcalico.org/v3
kind: BGPConfiguration
metadata:
  name: default
spec:
  nodeToNodeMeshEnabled: false
  asNumber: 64512
---
# Configure route reflector nodes
apiVersion: projectcalico.org/v3
kind: Node
metadata:
  name: node-rr-1
  labels:
    route-reflector: "true"
spec:
  bgp:
    routeReflectorClusterID: 224.0.0.1
---
# Configure BGP peer to route reflector
apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: peer-to-rr
spec:
  nodeSelector: "!has(route-reflector)"
  peerSelector: route-reflector == "true"

Peering BGP externo

yaml

apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: tor-switch-peer
spec:
  peerIP: 10.0.0.1
  asNumber: 65001
  nodeSelector: rack == 'rack-1'
  password:
    secretKeyRef:
      name: bgp-passwords
      key: tor-password
  sourceAddress: UseNodeIP
  keepOriginalNextHop: false

Proceso de propagación de rutas

Comandos de estado de BIRD

bash

# Access BIRD CLI on a Calico node
kubectl exec -n calico-system calico-node-xxxxx -c calico-node -- birdcl

# Show BGP protocol status
birdcl> show protocols
name     proto    table    state  since       info
kernel1  Kernel   master   up     2024-01-01
device1  Device   master   up     2024-01-01
direct1  Direct   master   up     2024-01-01
Mesh_10_0_1_10  BGP  master  up   2024-01-01  Established
Mesh_10_0_1_11  BGP  master  up   2024-01-01  Established

# Show BGP routes
birdcl> show route protocol Mesh_10_0_1_10
192.168.1.0/26     via 10.0.1.10 on eth0 [Mesh_10_0_1_10 2024-01-01] * (100/0) [i]
192.168.1.64/26    via 10.0.1.10 on eth0 [Mesh_10_0_1_10 2024-01-01] * (100/0) [i]

# Show route details
birdcl> show route 192.168.1.0/26 all

confd: administración de configuración

confd es una herramienta ligera de administración de configuración que supervisa el datastore de Calico y genera archivos de configuración de BIRD.

Flujo de trabajo de confd

Procesamiento de plantillas de confd

confd utiliza plantillas de Go para generar la configuración de BIRD:

# Template: /etc/calico/confd/templates/bird.cfg.template
# Output: /etc/calico/confd/config/bird.cfg

router id {{.NodeIP}};

protocol kernel {
    learn;
    persist;
    scan time 2;
    import all;
    export {{if .ExportKernel}}all{{else}}none{{end}};
}

protocol device {
    scan time 2;
}

{{range .BGPPeers}}
protocol bgp {{.Name}} {
    local as {{$.LocalAS}};
    neighbor {{.PeerIP}} as {{.PeerAS}};
    import all;
    export {{if .ExportFilter}}filter {{.ExportFilter}}{{else}}all{{end}};
    {{if .Password}}password "{{.Password}}";{{end}}
    graceful restart;
}
{{end}}

Typha: componente de escalabilidad

Typha es un proxy de fan-out que se sitúa entre el servidor API de Kubernetes y los agentes Felix. Reduce la carga en el servidor API al almacenar en caché y distribuir actualizaciones del datastore.

¿Por qué Typha?

Cálculo de escalabilidad de Typha

El número recomendado de réplicas de Typha depende del tamaño del clúster:

Typha Replicas = max(3, ceil(Nodes / 200))

Examples:
- 50 nodes:   3 Typha replicas (minimum)
- 200 nodes:  3 Typha replicas
- 500 nodes:  3 Typha replicas
- 1000 nodes: 5 Typha replicas
- 2000 nodes: 10 Typha replicas

Configuración de Deployment de Typha

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: calico-typha
  namespace: calico-system
spec:
  replicas: 3
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      k8s-app: calico-typha
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        k8s-app: calico-typha
    spec:
      nodeSelector:
        kubernetes.io/os: linux
      tolerations:
      - key: CriticalAddonsOnly
        operator: Exists
      priorityClassName: system-cluster-critical
      serviceAccountName: calico-typha
      containers:
      - name: calico-typha
        image: calico/typha:v3.29.0
        ports:
        - containerPort: 5473
          name: calico-typha
          protocol: TCP
        env:
        - name: TYPHA_LOGSEVERITYSCREEN
          value: "info"
        - name: TYPHA_LOGFILEPATH
          value: "none"
        - name: TYPHA_LOGSEVERITYSYS
          value: "none"
        - name: TYPHA_CONNECTIONREBALANCINGMODE
          value: "kubernetes"
        - name: TYPHA_DATASTORETYPE
          value: "kubernetes"
        - name: TYPHA_HEALTHENABLED
          value: "true"
        - name: TYPHA_PROMETHEUSMETRICSENABLED
          value: "true"
        - name: TYPHA_PROMETHEUSMETRICSPORT
          value: "9093"
        livenessProbe:
          httpGet:
            path: /liveness
            port: 9098
          periodSeconds: 30
          initialDelaySeconds: 30
        readinessProbe:
          httpGet:
            path: /readiness
            port: 9098
          periodSeconds: 10
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 1000m
            memory: 512Mi
---
apiVersion: v1
kind: Service
metadata:
  name: calico-typha
  namespace: calico-system
spec:
  ports:
  - port: 5473
    protocol: TCP
    targetPort: calico-typha
    name: calico-typha
  selector:
    k8s-app: calico-typha

Arquitectura de fan-out de Typha

kube-controllers: integración con Kubernetes

El Pod calico-kube-controllers ejecuta un conjunto de controladores que sincronizan los recursos de Kubernetes con el datastore de Calico.

Descripción general de los controladores

Controlador	Propósito
Controlador de nodos	Sincroniza los nodos de Kubernetes con los recursos de nodo de Calico
Controlador de políticas	Sincroniza NetworkPolicy de Kubernetes con la política de Calico
Controlador de namespaces	Sincroniza las etiquetas de namespace para la administración de perfiles
Controlador de ServiceAccount	Sincroniza las etiquetas de cuentas de servicio para RBAC
Controlador de WorkloadEndpoint	Limpia los endpoints de workload obsoletos

Bucle de reconciliación del controlador

Configuración de kube-controllers

yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: calico-kube-controllers-config
  namespace: calico-system
data:
  config: |
    {
      "logSeverityScreen": "info",
      "healthEnabled": true,
      "prometheusPort": 9094,
      "controllers": {
        "node": {
          "hostEndpoint": {
            "autoCreate": "Disabled"
          },
          "syncLabels": "Enabled",
          "leakGracePeriod": "15m"
        },
        "policy": {
          "reconcilerPeriod": "5m"
        },
        "workloadEndpoint": {
          "reconcilerPeriod": "5m"
        },
        "namespace": {
          "reconcilerPeriod": "5m"
        },
        "serviceAccount": {
          "reconcilerPeriod": "5m"
        }
      }
    }

Opciones de datastore

Calico admite dos backends de datastore para almacenar su configuración y estado.

Datastore de Kubernetes API (recomendado)

Ventajas:

No hay un clúster etcd separado que administrar
Utiliza Kubernetes RBAC para el control de acceso
Modelo operativo más simple
Funciona con cualquier distribución de Kubernetes

Datastore etcd (heredado)

Ventajas:

Desacoplado del servidor API de Kubernetes
Puede utilizarse para workloads no Kubernetes (VM, bare metal)
Opción histórica para clústeres muy grandes

Comparación de datastores

Característica	Kubernetes API	etcd
Complejidad operativa	Menor	Mayor
Escalabilidad	Buena (con Typha)	Excelente
Workloads no K8s	Limitados	Soporte completo
Copia de seguridad/restauración	Mediante K8s	Herramientas independientes
Control de acceso	K8s RBAC	Autenticación de etcd
Recomendación	Opción predeterminada	Solo casos especiales

Secuencia de interacción de componentes

Análisis del flujo de paquetes

Flujo de paquetes de entrada (Pod a Pod, mismo nodo)

Flujo de paquetes de salida (Pod a Pod, nodos diferentes con IPIP)

Comparación de la estructura de paquetes

Original Pod-to-Pod Packet:
┌─────────────────────────────────────────────────────────────┐
│ Ethernet │   IP Header    │   TCP/UDP   │     Payload      │
│  Header  │ Src: 192.168.1.10 │   Header    │                  │
│          │ Dst: 192.168.2.10 │             │                  │
└─────────────────────────────────────────────────────────────┘

IPIP Encapsulated Packet:
┌───────────────────────────────────────────────────────────────────────────────┐
│ Ethernet │   Outer IP     │   Inner IP     │   TCP/UDP   │     Payload      │
│  Header  │ Src: 10.0.1.10 │ Src: 192.168.1.10 │   Header    │                  │
│          │ Dst: 10.0.1.11 │ Dst: 192.168.2.10 │             │                  │
│          │ Proto: 4 (IPIP)│                │             │                  │
└───────────────────────────────────────────────────────────────────────────────┘

Resumen

La arquitectura de Calico está diseñada para la escalabilidad, el rendimiento y la simplicidad operativa:

Felix: el agente principal de cada nodo, que programa rutas y ACL
BIRD: distribuye rutas mediante BGP, lo que permite la integración con enrutamiento nativo
confd: conecta el datastore con la configuración de BIRD
Typha: escala el sistema reduciendo la carga del servidor API
kube-controllers: mantiene Kubernetes y Calico sincronizados
Datastore: Kubernetes API (recomendado) o etcd para almacenar la configuración

Comprender estos componentes y sus interacciones es esencial para:

Resolver problemas de conectividad
Optimizar el rendimiento a escala
Planificar la capacidad y la arquitectura
Integrarse con la infraestructura de red existente

Anterior: Parte 1 - Introducción a Calico

Siguiente: Parte 3 - Modos de red

Volver a la descripción general de Calico

Cuestionario

Para comprobar lo que has aprendido en este capítulo, prueba el Cuestionario de arquitectura.

Laboratorios integrales de observabilidad

Cuestionario de ArgoCD en detalle

Cuestionario de Istio detallado

Cuestionario de Linkerd detallado

Cuestionario de Cilium Service Mesh detallado

Profundización en Cilium

Profundización en Calico

Métricas

Registro

Trazado

Alertas

Laboratorios de observabilidad

ArgoCD

Gestión del tráfico

Seguridad

Observabilidad

Resiliencia

Avanzado

Guía comparativa

Métricas

Registro

Trazado

Alertas

Parte 2: Arquitectura ​

Descripción general ​

Diagrama completo de la arquitectura ​

Felix: el agente de Calico ​

Responsabilidades de Felix ​

Funciones principales ​

Opciones de plano de datos de Felix ​

Recurso FelixConfiguration ​

Estructura de reglas de iptables de Felix ​

Flujo de datos de Felix ​

BIRD: demonio de enrutamiento BGP ​

BIRD en la arquitectura de Calico ​

Tipos de sesión BGP ​

Ejemplos de configuración BGP ​

Malla de nodo a nodo (predeterminada) ​

Configuración de Route Reflector ​

Peering BGP externo ​

Proceso de propagación de rutas ​

Comandos de estado de BIRD ​

confd: administración de configuración ​

Flujo de trabajo de confd ​

Procesamiento de plantillas de confd ​

Typha: componente de escalabilidad ​

¿Por qué Typha? ​

Cálculo de escalabilidad de Typha ​

Configuración de Deployment de Typha ​

Arquitectura de fan-out de Typha ​

kube-controllers: integración con Kubernetes ​

Descripción general de los controladores ​

Bucle de reconciliación del controlador ​

Configuración de kube-controllers ​

Opciones de datastore ​

Datastore de Kubernetes API (recomendado) ​

Datastore etcd (heredado) ​

Comparación de datastores ​

Secuencia de interacción de componentes ​

Análisis del flujo de paquetes ​

Flujo de paquetes de entrada (Pod a Pod, mismo nodo) ​

Flujo de paquetes de salida (Pod a Pod, nodos diferentes con IPIP) ​

Comparación de la estructura de paquetes ​

Resumen ​

Cuestionario ​

Parte 2: Arquitectura

Descripción general

Diagrama completo de la arquitectura

Felix: el agente de Calico

Responsabilidades de Felix

Funciones principales

Opciones de plano de datos de Felix

Recurso FelixConfiguration

Estructura de reglas de iptables de Felix

Flujo de datos de Felix

BIRD: demonio de enrutamiento BGP

BIRD en la arquitectura de Calico

Tipos de sesión BGP

Ejemplos de configuración BGP

Malla de nodo a nodo (predeterminada)

Configuración de Route Reflector

Peering BGP externo

Proceso de propagación de rutas

Comandos de estado de BIRD

confd: administración de configuración

Flujo de trabajo de confd

Procesamiento de plantillas de confd

Typha: componente de escalabilidad

¿Por qué Typha?

Cálculo de escalabilidad de Typha

Configuración de Deployment de Typha

Arquitectura de fan-out de Typha

kube-controllers: integración con Kubernetes

Descripción general de los controladores

Bucle de reconciliación del controlador

Configuración de kube-controllers

Opciones de datastore

Datastore de Kubernetes API (recomendado)

Datastore etcd (heredado)

Comparación de datastores

Secuencia de interacción de componentes

Análisis del flujo de paquetes

Flujo de paquetes de entrada (Pod a Pod, mismo nodo)

Flujo de paquetes de salida (Pod a Pod, nodos diferentes con IPIP)

Comparación de la estructura de paquetes

Resumen

Cuestionario