Política de rede K8s Cilium eBPF: 5 padrões essenciais para a segurança Zero-Trust dos pods

技术架构

A rede do Kubernetes em 2026 entrou plenamente na era eBPF. O Cilium, como um projeto graduado da CNCF, tornou-se o padrão de fato para a segurança Zero-Trust dos pods graças aos seus recursos de rede programáveis no nível do kernel. Dos iptables tradicionais ao dataplane eBPF, das políticas de rede L3/L4 à filtragem na camada de aplicação L7, de um único cluster à rede multi-cluster Cluster Mesh — o Cilium está redefinindo os limites da rede cloud-native. Este artigo aprofunda 5 padrões essenciais de produção, levando você da instalação a uma implantação de nível de produção, dominando por completo as políticas de rede Cilium eBPF.

Conceitos principais

Conceito Descrição Comparação tradicional
eBPF Sandbox programável do kernel que estende a rede sem modificar o código-fonte do kernel cadeias de regras iptables, correspondência O(n) à medida que as regras crescem
Cilium Plugin CNI do K8s baseado em eBPF, fornecendo rede, segurança e observabilidade Calico/Flannel, apenas políticas L3/L4
Identity Label Identidade de segurança baseada em Labels, não em endereços IP NetworkPolicy baseada em IP
L7 Policy Filtragem na camada de aplicação HTTP/gRPC, precisa até os caminhos de API apenas filtragem no nível da porta L4
Cluster Mesh Interconexão de rede multi-cluster, comunicação direta entre pods de clusters encaminhamento via VPN/gateway
Hubble Plataforma de observabilidade de rede do Cilium, visualização de tráfego em tempo real captura manual de pacotes tcpdump/Wireshark

Análise de problemas: 5 pontos críticos das políticas de rede K8s tradicionais

Ponto crítico 1: gargalo de desempenho do iptables — Em clusters em grande escala, as regras iptables podem chegar a dezenas de milhares. Cada alteração de regra dispara uma substituição completa, causando forte instabilidade na latência de rede.

Ponto crítico 2: granularidade insuficiente das políticas L3/L4 — A NetworkPolicy nativa só consegue controlar o acesso no nível da porta, sem distinguir entre GET /api/users e DELETE /api/users.

Ponto crítico 3: políticas de segurança baseadas em IP frágeis — Os IPs dos pods mudam após recriação, as regras de firewall baseadas em IP ficam inválidas instantaneamente, tornando o Zero-Trust impossível.

Ponto crítico 4: rede multi-cluster fragmentada — A comunicação de serviços entre clusters depende do encaminhamento via Ingress/gateway, com alta latência e difícil unificação de políticas.

Ponto crítico 5: caixa preta na solução de problemas de rede — Falhas de comunicação entre pods só podem ser diagnosticadas com tcpdump salto a salto, sem visualização de tráfego de ponta a ponta.

Padrão 1: Instalação do Cilium e princípios da rede eBPF

Princípios da rede eBPF

Os programas eBPF são anexados a hooks de rede do kernel (xdp, tc, cgroup etc.), processando pacotes antes que alcancem a pilha de protocolos, evitando o custo de percorrer as cadeias de regras iptables:

Packet In → XDP(eBPF) → tc ingress(eBPF) → Protocol Stack → tc egress(eBPF) → Out
                ↓              ↓                              ↓
          DDoS Protection  Policy Match/Routing         Policy Match/NAT

Instalação via Helm (substituindo o kube-proxy)

# cilium-values.yaml
# Cilium Helm installation config, kube-proxy replacement mode
kubeProxyReplacement: true
operator:
  replicas: 2

# eBPF map sizes (large-scale cluster tuning)
bpf:
  mapDynamicSizeRatio: 0.0025
  lbMapMax: 65536
  ctMapMax: 524288

# Auto-detect node networking
autoDirectNodeRoutes: true
tunnel: vxlan

# Identity allocation mode
identityAllocationMode: kvstore

# Monitoring and observability
hubble:
  enabled: true
  listenAddress: ":4244"
  metrics:
    enabled:
      - dns
      - drop
      - tcp
      - flow
      - port-distribution
      - http
  relay:
    enabled: true
    replicas: 2
  ui:
    enabled: true

# Resource limits
resources:
  requests:
    cpu: 200m
    memory: 256Mi
  limits:
    cpu: "1"
    memory: 1Gi

# Security context
securityContext:
  capabilities:
    add:
      - NET_ADMIN
      - SYS_MODULE

#!/bin/bash
# install-cilium.sh
# Cilium installation script

set -euo pipefail

CLUSTER_NAME="prod-cluster"
NAMESPACE="kube-system"

echo "=== Step 1: Add Cilium Helm repository ==="
helm repo add cilium https://helm.cilium.io/
helm repo update

echo "=== Step 2: Get API Server address ==="
API_SERVER_IP=$(kubectl get endpoints kubernetes -o jsonpath='{.subsets[0].addresses[0].ip}')
API_SERVER_PORT=$(kubectl get endpoints kubernetes -o jsonpath='{.subsets[0].ports[0].port}')

echo "API Server: ${API_SERVER_IP}:${API_SERVER_PORT}"

echo "=== Step 3: Install Cilium ==="
helm install cilium cilium/cilium \
  --namespace ${NAMESPACE} \
  --values cilium-values.yaml \
  --set kubeProxyReplacement=true \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --wait

echo "=== Step 4: Wait for Cilium readiness ==="
kubectl -n ${NAMESPACE} rollout status ds/cilium --timeout=300s
kubectl -n ${NAMESPACE} rollout status deploy/cilium-operator --timeout=120s

echo "=== Step 5: Verify eBPF program loading ==="
kubectl -n ${NAMESPACE} exec ds/cilium -- cilium bpf lb list
kubectl -n ${NAMESPACE} exec ds/cilium -- cilium status

echo "=== Step 6: Verify kube-proxy replacement ==="
kubectl -n ${NAMESPACE} exec ds/cilium -- cilium service list

echo "=== Step 7: Status check ==="
cilium status --wait

echo "✅ Cilium installation complete!"

Verificar o dataplane eBPF

#!/bin/bash
# verify-ebpf.sh
# Verify eBPF dataplane is working correctly

echo "=== Check Cilium eBPF programs ==="
kubectl -n kube-system exec ds/cilium -- cilium bpf tunnel list
kubectl -n kube-system exec ds/cilium -- cilium bpf ct list global

echo "=== Check identity mapping ==="
kubectl -n kube-system exec ds/cilium -- cilium identity list

echo "=== Network connectivity test ==="
kubectl run test-net --image=cilium/cilium:latest --restart=Never -- sleep infinity
kubectl exec test-net -- curl -s https://kubernetes.default.svc.cluster.local:443/api/v1/namespaces

echo "=== Bandwidth benchmark ==="
kubectl run iperf3-server --image=networkstatic/iperf3 --restart=Never -- iperf3 -s
kubectl run iperf3-client --image=networkstatic/iperf3 --restart=Never -- sleep infinity
CLIENT_POD=$(kubectl get pods -l run=iperf3-client -o jsonpath='{.items[0].metadata.name}')
SERVER_IP=$(kubectl get pod iperf3-server -o jsonpath='{.status.podIP}')
kubectl exec ${CLIENT_POD} -- iperf3 -c ${SERVER_IP} -t 10 -P 4

echo "✅ eBPF dataplane verification complete!"

Padrão 2: Políticas de rede L3/L4 e rótulos de identidade

Mecanismo de rótulos de identidade do Cilium

O Cilium usa Labels para calcular identidades de segurança (Identity) em vez de depender de endereços IP. Pods com os mesmos Labels compartilham a mesma Identity, e a correspondência de políticas baseia-se na Identity em vez do IP:

Pod(app=api, env=prod) → Identity: 1001 → Policy allows Identity:1001 → Identity:2001
Pod(app=web, env=prod) → Identity: 2001

Políticas de rede L3/L4 básicas

# cilium-l3-l4-policy.yaml
# L3/L4 network policy: Zero-trust access control based on identity labels
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-server-policy
  namespace: production
spec:
  description: "API service only allows frontend and internal service access, denies all other traffic"
  endpointSelector:
    matchLabels:
      app: api-server
      env: production
  ingress:
    # Rule 1: Allow frontend Pods to access API port 8080
    - fromEndpoints:
        - matchLabels:
            app: web-frontend
            env: production
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: "/api/v1/.*"
              - method: POST
                path: "/api/v1/.*"

    # Rule 2: Allow internal microservices to access gRPC port
    - fromEndpoints:
        - matchLabels:
            app: internal-service
            env: production
      toPorts:
        - ports:
            - port: "9090"
              protocol: TCP

    # Rule 3: Allow Prometheus monitoring scrape
    - fromEndpoints:
        - matchLabels:
            app.kubernetes.io/name: prometheus
      toPorts:
        - ports:
            - port: "9090"
              protocol: TCP
              endPort: 9091

  egress:
    # Allow database access
    - toEndpoints:
        - matchLabels:
            app: postgres
            env: production
      toPorts:
        - ports:
            - port: "5432"
              protocol: TCP

    # Allow DNS resolution
    - toEndpoints:
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP

    # Allow external API calls
    - toFQDNs:
        - matchName: "api.stripe.com"
        - matchPattern: "*.amazonaws.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP
---
# Default deny policy (zero-trust foundation)
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: default-deny-all
spec:
  description: "Default deny all ingress traffic, zero-trust baseline policy"
  endpointSelector: {}
  ingressDeny:
    - fromRequires:
        - {}
---
# Namespace isolation policy
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: namespace-isolation
spec:
  description: "Namespace-level isolation, only allow same-namespace communication"
  endpointSelector:
    matchLabels: {}
  ingress:
    - fromEndpoints:
        - matchLabels: {}

Políticas de rede baseadas em entidades

# entity-based-policy.yaml
# Entity-based network policy: Control intra-cluster and external traffic
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: entity-policy
spec:
  description: "Control network access between Pods and cluster entities"
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
    # Allow traffic from within the cluster
    - fromEntities:
        - cluster
        - host
        - remote-node
  egress:
    # Allow access to outside the cluster
    - toEntities:
        - world
    # Allow access to K8s API Server
    - toEntities:
        - kube-apiserver

Padrão 3: Políticas de camada de aplicação L7 (filtragem HTTP/gRPC)

Controle de acesso granular no nível HTTP

# cilium-l7-policy.yaml
# L7 application-layer policy: HTTP/gRPC fine-grained filtering
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l7-api-policy
  namespace: production
spec:
  description: "L7 policy: HTTP method + path precise control, implementing API-level zero-trust"
  endpointSelector:
    matchLabels:
      app: api-server
      env: production
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: web-frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              # Allow read-only APIs
              - method: GET
                path: "/api/v1/users(/.*)?"
              - method: GET
                path: "/api/v1/products(/.*)?"
              - method: GET
                path: "/api/v1/orders(/.*)?"
              # Allow order creation
              - method: POST
                path: "/api/v1/orders"
              # Deny delete operations (requests not in this list will be denied)
---
# gRPC method-level filtering
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: grpc-policy
  namespace: production
spec:
  description: "gRPC method-level access control"
  endpointSelector:
    matchLabels:
      app: order-service
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: api-gateway
      toPorts:
        - ports:
            - port: "50051"
              protocol: TCP
          rules:
            http:
              - method: POST
                path: "/order.OrderService/GetOrder"
              - method: POST
                path: "/order.OrderService/ListOrders"
              - method: POST
                path: "/order.OrderService/CreateOrder"
---
# HTTP Header filtering policy
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: header-filter-policy
  namespace: production
spec:
  description: "HTTP Header-based access control"
  endpointSelector:
    matchLabels:
      app: internal-api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: gateway
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: "/internal/.*"
                headers:
                  - "X-Internal-Token: ^secret-token-.*$"
---
# Kafka protocol-aware policy
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: kafka-policy
  namespace: production
spec:
  description: "Kafka topic-level access control"
  endpointSelector:
    matchLabels:
      app: kafka-broker
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: order-processor
      toPorts:
        - ports:
            - port: "9092"
              protocol: TCP
          rules:
            kafka:
              - role: produce
                topic: orders
              - role: consume
                topic: orders
    - fromEndpoints:
        - matchLabels:
            app: analytics
      toPorts:
        - ports:
            - port: "9092"
              protocol: TCP
          rules:
            kafka:
              - role: consume
                topic: orders

Script de verificação de políticas L7

#!/bin/bash
# verify-l7-policy.sh
# Verify L7 application-layer policies

echo "=== Test HTTP GET allowed ==="
kubectl exec deploy/web-frontend -- curl -s -o /dev/null -w "%{http_code}" http://api-server:8080/api/v1/users
# Expected: 200

echo ""
echo "=== Test HTTP DELETE denied ==="
kubectl exec deploy/web-frontend -- curl -s -o /dev/null -w "%{http_code}" -X DELETE http://api-server:8080/api/v1/users/123
# Expected: 403

echo ""
echo "=== Test access without Header denied ==="
kubectl exec deploy/gateway -- curl -s -o /dev/null -w "%{http_code}" http://internal-api:8080/internal/config
# Expected: 403

echo ""
echo "=== Test access with Token Header allowed ==="
kubectl exec deploy/gateway -- curl -s -o /dev/null -w "%{http_code}" -H "X-Internal-Token: secret-token-abc" http://internal-api:8080/internal/config
# Expected: 200

echo ""
echo "=== Check Cilium L7 policy status ==="
kubectl -n kube-system exec ds/cilium -- cilium policy get
kubectl -n kube-system exec ds/cilium -- cilium policy select

echo "✅ L7 policy verification complete!"

Padrão 4: Rede multi-cluster Cluster Mesh

Arquitetura do Cluster Mesh

Cluster A (us-west)          Cluster B (eu-central)
┌─────────────────┐          ┌─────────────────┐
│  Pod: api-server │◄────────►│  Pod: api-server │
│  Identity: 1001  │          │  Identity: 1001  │
│  Service: global  │          │  Service: global  │
└─────────────────┘          └─────────────────┘
        │                            │
        └──────── etcd sync ─────────┘

Configuração do Cluster Mesh

# cluster-mesh-config.yaml
# Cluster Mesh multi-cluster network configuration
# Cluster A: us-west
apiVersion: v1
kind: ConfigMap
metadata:
  name: cilium-clustermesh
  namespace: kube-system
data:
  cluster-id: "1"
  cluster-name: "us-west"
---
# Cluster B: eu-central
apiVersion: v1
kind: ConfigMap
metadata:
  name: cilium-clustermesh
  namespace: kube-system
data:
  cluster-id: "2"
  cluster-name: "eu-central"
---
# Global Service (cross-cluster load balancing)
apiVersion: v1
kind: Service
metadata:
  name: global-api-server
  namespace: production
  annotations:
    service.cilium.io/global: "true"
    service.cilium.io/affinity: "local"
spec:
  type: ClusterIP
  ports:
    - port: 8080
      targetPort: 8080
  selector:
    app: api-server
---
# Cross-cluster network policy
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: cross-cluster-policy
  namespace: production
spec:
  description: "Cross-cluster network policy: Allow us-west and eu-central mutual access"
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: api-server
            io.cilium.k8s.policy.cluster: us-west
        - matchLabels:
            app: api-server
            io.cilium.k8s.policy.cluster: eu-central
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP

#!/bin/bash
# setup-cluster-mesh.sh
# Cluster Mesh setup script

set -euo pipefail

CLUSTER_A="us-west"
CLUSTER_B="eu-central"
CONTEXT_A="kind-${CLUSTER_A}"
CONTEXT_B="kind-${CLUSTER_B}"

echo "=== Step 1: Enable Cluster Mesh on both clusters ==="
kubectl --context ${CONTEXT_A} -n kube-system exec ds/cilium -- \
  cilium clustermesh enable --cluster-id 1 --cluster-name ${CLUSTER_A}

kubectl --context ${CONTEXT_B} -n kube-system exec ds/cilium -- \
  cilium clustermesh enable --cluster-id 2 --cluster-name ${CLUSTER_B}

echo "=== Step 2: Wait for Cluster Mesh API readiness ==="
kubectl --context ${CONTEXT_A} -n kube-system rollout status deploy/clustermesh-apiserver --timeout=120s
kubectl --context ${CONTEXT_B} -n kube-system rollout status deploy/clustermesh-apiserver --timeout=120s

echo "=== Step 3: Connect the two clusters ==="
kubectl --context ${CONTEXT_A} -n kube-system exec ds/cilium -- \
  cilium clustermesh connect --destination-context ${CONTEXT_B}

echo "=== Step 4: Verify cluster connection status ==="
kubectl --context ${CONTEXT_A} -n kube-system exec ds/cilium -- \
  cilium clustermesh status

kubectl --context ${CONTEXT_B} -n kube-system exec ds/cilium -- \
  cilium clustermesh status

echo "=== Step 5: Test cross-cluster service discovery ==="
kubectl --context ${CONTEXT_A} run test-cross-cluster \
  --image=cilium/cilium:latest --restart=Never -- \
  curl -s http://global-api-server.production.svc.cluster.local:8080/health

echo "=== Step 6: Verify global Service ==="
kubectl --context ${CONTEXT_A} get svc global-api-server -n production -o yaml
kubectl --context ${CONTEXT_B} get svc global-api-server -n production -o yaml

echo "✅ Cluster Mesh setup complete!"

Teste de failover entre clusters

#!/bin/bash
# test-cross-cluster-failover.sh
# Cross-cluster failover testing

CLUSTER_A="us-west"
CLUSTER_B="eu-central"
CONTEXT_A="kind-${CLUSTER_A}"
CONTEXT_B="kind-${CLUSTER_B}"

echo "=== Baseline test: Normal cross-cluster access ==="
for i in $(seq 1 10); do
  RESULT=$(kubectl --context ${CONTEXT_A} exec deploy/test-client -- \
    curl -s http://global-api-server.production.svc.cluster.local:8080/cluster-name)
  echo "Request ${i}: ${RESULT}"
done

echo ""
echo "=== Simulate cluster B failure ==="
kubectl --context ${CONTEXT_B} scale deploy api-server -n production --replicas=0

echo "=== Verify traffic auto-switches to cluster A ==="
for i in $(seq 1 10); do
  RESULT=$(kubectl --context ${CONTEXT_A} exec deploy/test-client -- \
    curl -s http://global-api-server.production.svc.cluster.local:8080/cluster-name)
  echo "Failover Request ${i}: ${RESULT}"
done

echo "=== Restore cluster B ==="
kubectl --context ${CONTEXT_B} scale deploy api-server -n production --replicas=3

echo "✅ Failover testing complete!"

Padrão 5: Observabilidade do Hubble e rastreamento de rede

Implantação e configuração do Hubble

# hubble-values.yaml
# Hubble observability configuration
hubble:
  enabled: true
  listenAddress: ":4244"
  metrics:
    enabled:
      - dns:query
      - drop
      - tcp
      - flow
      - port-distribution
      - http:method;path;status
      - icmp
    serviceMonitor:
      enabled: true
    dashboards:
      enabled: true
      namespace: monitoring
  relay:
    enabled: true
    replicas: 2
    rollOutPods: true
  ui:
    enabled: true
    replicas: 1
    rollOutPods: true
    ingress:
      enabled: true
      className: nginx
      hosts:
        - hubble.example.com
      tls:
        secretName: hubble-tls

Rastreamento de rede via Hubble CLI

#!/bin/bash
# hubble-observability.sh
# Hubble observability and network tracing

echo "=== Real-time traffic monitoring ==="
hubble observe --since 1m --output json | jq -r '
  select(.source.namespace == "production") |
  "\(.timestamp) \(.source.pod_name) → \(.destination.pod_name) \(.event.type) \(.l7.protocol // "L4") \(.l7.method // "") \(.l7.path // "") \(.response_status // "")"
'

echo ""
echo "=== Trace traffic for a specific Pod ==="
hubble observe --pod api-server-7d9f8b6c4-x2k1p --since 5m

echo ""
echo "=== Detect denied traffic ==="
hubble observe --since 10m --type trace --verdict DROPPED | head -50

echo ""
echo "=== HTTP traffic analysis ==="
hubble observe --since 5m --protocol http --output json | jq -r '
  "\(.source.pod_name) → \(.destination.pod_name) [\(.l7.method)] \(.l7.path) → \(.l7.response_code)"
' | sort | uniq -c | sort -rn | head -20

echo ""
echo "=== DNS query monitoring ==="
hubble observe --since 5m --protocol dns --output json | jq -r '
  "\(.source.pod_name) → \(.l7.dns.query) \(.l7.dns.rcode // "OK")"
' | sort | uniq -c | sort -rn | head -20

echo ""
echo "=== Network latency analysis ==="
hubble observe --since 5m --type trace --output json | jq -r '
  select(.latency_ns != null) |
  "\(.source.pod_name) → \(.destination.pod_name) latency: \(.latency_ns / 1000000)ms"
' | sort -t: -k2 -n | tail -20

echo "✅ Hubble observability analysis complete!"

Métricas Hubble do Prometheus

# hubble-prometheus-rules.yaml
# Hubble alerting rules
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: hubble-alerts
  namespace: monitoring
spec:
  groups:
    - name: hubble-network
      rules:
        # High drop rate alert
        - alert: CiliumHighDropRate
          expr: |
            rate(hubble_drop_total{verdict="DROPPED"}[5m]) > 10
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "Cilium detected high drop rate"
            description: "Pod {{ $labels.source_pod }} in namespace {{ $labels.namespace }} drop rate exceeds 10/s"

        # DNS resolution failure alert
        - alert: CiliumDNSFailures
          expr: |
            rate(hubble_dns_responses_total{rcode="NXDOMAIN"}[5m]) > 5
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "Abnormal DNS resolution failure rate"
            description: "DNS NXDOMAIN responses in namespace {{ $labels.namespace }} exceed 5/s"

        # TCP connection reset alert
        - alert: CiliumTCPResets
          expr: |
            rate(hubble_tcp_flags_total{flag="RST"}[5m]) > 50
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Abnormal TCP RST packets"
            description: "TCP RST packets in namespace {{ $labels.namespace }} exceed 50/s"

        # Cross-cluster latency alert
        - alert: CiliumCrossClusterLatency
          expr: |
            histogram_quantile(0.99, rate(hubble_flows_processed_duration_seconds_bucket{source_cluster!=""}[5m])) > 0.5
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "High cross-cluster network latency"
            description: "P99 latency exceeds 500ms"

Guia de armadilhas

Armadilha 1: Pods não conseguem se comunicar após a instalação do Cilium

# ❌ Wrong: Incorrect tunnel mode configuration, incompatible node networking
tunnel: disabled
autoDirectNodeRoutes: false

# ✅ Correct: Choose tunnel mode based on network environment
# Cloud environment (VPC supports routing)
tunnel: disabled
autoDirectNodeRoutes: true
directRoutingSkipUnreachable: true

# General environment (VXLAN overlay)
tunnel: vxlan
tunnelPort: 8473

Armadilha 2: Políticas L7 não surtem efeito

# ❌ Wrong: L7 policy missing toPorts definition, Cilium cannot inject proxy
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: bad-l7-policy
spec:
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      rules:
        http:
          - method: GET
            path: "/api/.*"

# ✅ Correct: L7 rules must be defined under toPorts
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: good-l7-policy
spec:
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: "/api/.*"

Armadilha 3: Falha de conexão do Cluster Mesh

# ❌ Wrong: etcd certificates not properly synced
cilium clustermesh connect --destination-context other-cluster

# ✅ Correct: Ensure etcd certificates are correct first, then connect
# Check Cluster Mesh API Server status
kubectl -n kube-system get deploy/clustermesh-apiserver
kubectl -n kube-system logs deploy/clustermesh-apiserver

# Ensure certificate Secrets exist
kubectl -n kube-system get secret clustermesh-apiserver-server-certs
kubectl -n kube-system get secret clustermesh-apiserver-remote-certs

# Use the correct connection method
cilium clustermesh connect \
  --destination-context other-cluster \
  --destination-name other-cluster

Armadilha 4: A UI do Hubble não mostra tráfego

# ❌ Wrong: Hubble Relay cannot connect to Cilium Agent
hubble:
  relay:
    enabled: true
    # Missing dialTimeout config causing timeout

# ✅ Correct: Configure Hubble Relay timeout and retry
hubble:
  relay:
    enabled: true
    dialTimeout: "5s"
    retryTimeout: "30s"
    maxFlows: 10000
    sortBufferLenMax: 1000
    sortBufferFlushInterval: "1s"
    port: 4245
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 500m
        memory: 512Mi

Armadilha 5: Falha ao carregar o programa eBPF

# ❌ Wrong: Incompatible kernel version, installing directly
helm install cilium cilium/cilium

# ✅ Correct: Check kernel compatibility first
# Check kernel version (need >= 5.4, recommended >= 5.10)
uname -r

# Check eBPF feature support
kubectl -n kube-system exec ds/cilium -- cilium-dbg features

# If kernel version is low, enable compatibility mode
helm install cilium cilium/cilium \
  --set bpf.preallocateMaps=false \
  --set bpf.tproxy=false \
  --set hostFirewall.enabled=false

# Check eBPF program loading status
kubectl -n kube-system exec ds/cilium -- cilium-dbg bpf lb list
kubectl -n kube-system exec ds/cilium -- cilium-dbg status

Tabela de solução de erros

Sintoma do erro Causa possível Comando de diagnóstico Solução
Pods não conseguem se comunicar entre nós Configuração incorreta do túnel cilium bpf tunnel list Verifique o modo de túnel, garanta que a porta VXLAN 8473 esteja aberta
Pod do Cilium em CrashLoopBackOff Versão do kernel incompatível dmesg | grep -i bpf Atualize o kernel para 5.10+ ou ative o modo de compatibilidade
Políticas L7 ineficazes Definição toPorts ausente cilium policy get As regras L7 devem ser aninhadas em toPorts.ports.rules
Tempo esgotado na conexão do Cluster Mesh Certificado etcd expirado kubectl logs -n kube-system deploy/clustermesh-apiserver Regenerar certificados: cilium clustermesh enable
Hubble sem dados de tráfego O relay não consegue conectar ao agente kubectl logs -n kube-system deploy/hubble-relay Verifique dialTimeout e a porta 4244 do agente
Falha na resolução de DNS Proxy DNS eBPF anômalo cilium bpf ct list global | grep 53 Verifique a política DNS, garanta que os rótulos kube-dns estejam corretos
Pico de latência de rede Mapa eBPF cheio cilium bpf ct list global | wc -l Aumente ctMapMax, ative GC
Serviço inalcançável Conflito residual do kube-proxy iptables -L -n | grep KUBE Limpe as regras iptables completamente, confirme a remoção do kube-proxy
Conflito de alocação de identidade Backend KVStore anômalo cilium identity list Verifique a conexão etcd, reinicie o cilium-operator
Pod entre clusters inalcançável Global Service não configurado kubectl get svc -o yaml | grep global Adicione a anotação service.cilium.io/global: "true"

Otimização avançada

1. Ajuste de mapas eBPF

# Large-scale cluster eBPF Map configuration
bpf:
  mapDynamicSizeRatio: 0.0025
  ctMapMax: 524288        # Connection tracking table
  ctTcpMax: 262144        # TCP connection tracking
  ctAnyMax: 262144        # Non-TCP connection tracking
  lbMapMax: 65536         # Load balancing map
  lbServiceMapMax: 65536
  lbBackendMapMax: 65536
  natMapMax: 524288        # NAT map
  neighMapMax: 524288      # Neighbor table
  policyMapMax: 16384      # Policy map
  fragmentsMapMax: 8192    # Fragment map

2. Gerenciamento de largura de banda (EDT)

# eBPF-based bandwidth management
bandwidthManager:
  enabled: true
  bbr: true               # Enable BBR congestion control

# Set bandwidth limits for Pods
kubectl annotate pod api-server-xxx \
  kubernetes.io/egress-bandwidth=100M \
  kubernetes.io/ingress-bandwidth=100M

3. Otimização Big TCP

# Large-scale TCP optimization (kernel 5.19+)
bpf:
  tcpRto: 100ms           # TCP retransmission timeout
  tproxy: true
kubeProxyReplacement:
  true
hostPort:
  enabled: true
externalIPs:
  enabled: true
nodePort:
  enabled: true
hostLegacyRouting:
  enabled: false

4. Roteamento de host eBPF

# Host routing optimization
bpf:
  hostLegacyRouting: false  # Use eBPF instead of host routing
  lbExternalClusterIP: true
autoDirectNodeRoutes: true

5. Endurecimento de segurança

# Cilium security hardening configuration
securityContext:
  capabilities:
    add:
      - NET_ADMIN
      - SYS_MODULE
    drop:
      - ALL
  seccompProfile:
    type: RuntimeDefault
  readOnlyRootFilesystem: true

# Enable encryption
encryption:
  enabled: true
  type: wireguard
  nodeEncryption: true

Tabela comparativa

Recurso Cilium eBPF Calico Flannel Weave
Dataplane eBPF iptables/eBPF VXLAN VXLAN
Políticas L3/L4 ✅ ✅ ❌ ❌
Políticas L7 ✅ HTTP/gRPC/Kafka ❌ ❌ ❌
Observabilidade ✅ Hubble ❌ ❌ ❌
Cluster Mesh ✅ ❌ ❌ ❌
Substituição do kube-proxy ✅ ❌ ❌ ❌
Gerenciamento de largura de banda ✅ EDT/BBR ❌ ❌ ❌
Criptografia WireGuard ✅ ✅ ❌ ✅
Políticas FQDN ✅ ❌ ❌ ❌
Desempenho em grande escala O(1) O(n) O(n) O(n)
Requisito de kernel ≥5.4 ≥4.9 ≥3.10 ≥3.10

💡 Resumo: As políticas de rede Cilium eBPF representam a direção futura da segurança de rede do K8s. Dos rótulos de identidade L3/L4 à filtragem na camada de aplicação L7, do Zero-Trust de um único cluster à interconexão multi-cluster Cluster Mesh, da observabilidade em tempo real do Hubble à otimização de desempenho eBPF — 5 padrões essenciais constroem um sistema completo de segurança de rede cloud-native. Lembre-se: Zero-Trust não é um produto, mas uma filosofia de arquitetura, e o Cilium é a melhor ferramenta para implementá-lo.

Recomendação de ferramentas online

  • JSON Formatter — Formatar a saída JSON das políticas Cilium, solucionar configurações de políticas
  • cURL to Code — Converter consultas de API do Hubble em código, integrar observabilidade
  • Hash Calculator — Calcular hashes de assinatura de políticas, verificar a integridade da configuração

Experimente estas ferramentas executadas localmente no navegador — nenhum cadastro necessário →

#Cilium#eBPF#K8s网络#网络策略#2026#技术架构