Chapitre 11 : Networking

11.1 Introduction au Networking

11.1.1 Le modele OSI

Le modele OSI (Open Systems Interconnection) est un standard de communication en 7 couches :

Dans le contexte DevOps/Cloud, on travaille principalement avec les couches 4 (Transport) et 7 (Application).

11.1.2 HTTP/2 vs HTTP/3

HTTP/2 (2015) :

• Multiplexage des requetes sur une seule connexion TCP
• Server push
• Compression des headers (HPACK)
• Binaire (vs textuel en HTTP/1.1)

HTTP/3 (2022) :

• Base sur QUIC (UDP) au lieu de TCP
• 0-RTT handshake
• Meilleure gestion de la perte de paquets
• Migration de connexion (changement de reseau sans interruption)

11.2 DNS

11.2.1 Principes du DNS

Le DNS (Domain Name System) traduit les noms de domaine en adresses IP.

Resolution DNS typique :

1. Client -> Resolver local (stub resolver)
2. Resolver -> Root DNS server
3. Resolver -> TLD DNS server (.com, .org, .io)
4. Resolver -> Authoritative DNS server (example.com)
5. Resolver -> Client (avec l'IP)

11.2.2 CoreDNS

CoreDNS est le DNS server standard dans Kubernetes :

# Corefile
.:53 {
    errors
    health {
        lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf {
        max_concurrent 1000
    }
    cache 30
    loop
    reload
    loadbalance
}

Fonctionnalites cles :

• Resolution DNS pour les Services Kubernetes
• Service discovery pour les pods
• Cache DNS integre
• Metriques Prometheus
• Plugins extensibles

11.2.3 Route53 (AWS)

Route53 est le service DNS gere d'AWS :

# Terraform Route53 record
resource "aws_route53_record" "api" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"

  alias {
    name                   = aws_lb.main.dns_name
    zone_id                = aws_lb.main.zone_id
    evaluate_target_health = true
  }
}

# Health check
resource "aws_route53_health_check" "api" {
  fqdn              = "api.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}

11.3 TLS et mTLS

11.3.1 TLS en pratique

TLS (Transport Layer Security) chiffre les communications :

# Ingress Kubernetes avec TLS
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
    - hosts:
        - api.example.com
      secretName: api-tls
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 443

11.3.2 Mutual TLS (mTLS)

Le mTLS authentifie les deux cotes de la connexion :

Client                    Server
  │                         │
  ├── Client Hello ────────>│
  │<── Server Hello ───────┤
  │<── Server Certificate ─┤
  │<── Request Client Cert ─┤
  ├── Client Certificate ──>│
  ├── Client Verify ───────>│
  │<── Server Verify ──────┤
  │                         │
  │<── Encrypted Data ─────┤
  ├── Encrypted Data ──────>│

Configuration dans Istio :

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT  # STRICT, PERMISSIVE, DISABLE

11.3.3 ACME et cert-manager

cert-manager automatise la gestion des certificats TLS :

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-private-key
    solvers:
      - http01:
          ingress:
            class: nginx

11.4 Proxies

11.4.1 Nginx (Ingress Controller)

Nginx est un serveur web et reverse proxy :

# nginx-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-config
data:
  proxy-connect-timeout: "10"
  proxy-read-timeout: "120"
  proxy-send-timeout: "120"
  proxy-buffer-size: "8k"
  client-max-body-size: "100m"
  ssl-protocols: "TLSv1.2 TLSv1.3"
  ssl-ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256"

11.4.2 Envoy Proxy

Envoy est un proxy de couche 7 performant, utilise par Istio :

# envoy-config.yaml
static_resources:
  listeners:
    - name: listener_0
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 10000
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: ingress_http
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: backend
                      domains: ["*"]
                      routes:
                        - match:
                            prefix: "/"
                          route:
                            cluster: service_backend
                http_filters:
                  - name: envoy.filters.http.router
  clusters:
    - name: service_backend
      type: STRICT_DNS
      lb_policy: ROUND_ROBIN
      load_assignment:
        cluster_name: service_backend
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: backend-service
                      port_value: 8080

11.5 Service Mesh

11.5.1 Istio

Istio est le service mesh le plus populaire :

# istio-operator.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  profile: default
  components:
    pilot:
      k8s:
        resources:
          requests:
            cpu: 500m
            memory: 2Gi
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          hpaSpec:
            minReplicas: 2
            maxReplicas: 10
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"

Fonctionnalites Istio :

• Traffic Management : Routing, mirroring, fault injection
• Security : mTLS, RBAC, JWT validation
• Observability : Metriques, traces, logs
• Resilience : Retries, circuit breakers, timeouts

Exemple de VirtualService :

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-routing
spec:
  hosts:
    - api.example.com
  gateways:
    - api-gateway
  http:
    - match:
        - headers:
            version:
              exact: v2
      route:
        - destination:
            host: api-service
            subset: v2
    - route:
        - destination:
            host: api-service
            subset: v1
          weight: 80
        - destination:
            host: api-service
            subset: v2
          weight: 20

11.5.2 Linkerd

Linkerd est un service mesh plus leger :

# Installation Linkerd CLI
curl -sL https://run.linkerd.io/install | sh

# Verification du cluster
linkerd check --pre

# Installation du control plane
linkerd install | kubectl apply -f -

# Injection du proxy dans un deployment
kubectl get deploy api -o yaml | linkerd inject - | kubectl apply -f -

11.5.3 Consul

Consul de HashiCorp combine service mesh et service discovery :

# consul-config.yaml
apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceDefaults
metadata:
  name: api-service
spec:
  protocol: http
  meshGateway:
    mode: local
  upstreamConfig:
    defaults:
      connectTimeout: 5s
      limits:
        maxConnections: 100
        maxPendingRequests: 100
        maxRequests: 100

11.6 Load Balancing

11.6.1 ALB vs NLB (AWS)

Application Load Balancer (Couche 7) :

• Routing base sur le contenu (path, host, headers)
• Support WebSocket et HTTP/2
• WAF integration
• Target groups par service

Network Load Balancer (Couche 4) :

• Ultra-haute performance (millions de requetes/s)
• Preservation de l'IP source
• TLS termination
• Static IP support

# Terraform ALB
resource "aws_lb" "main" {
  name               = "app-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets           = aws_subnet.public[*].id

  enable_deletion_protection = true
  enable_http2              = true
  idle_timeout              = 60
}

resource "aws_lb_target_group" "api" {
  name        = "api-tg"
  port        = 3000
  protocol    = "HTTP"
  vpc_id      = aws_vpc.main.id
  target_type = "ip"

  health_check {
    path                = "/health"
    interval            = 30
    timeout             = 5
    healthy_threshold   = 2
    unhealthy_threshold = 3
  }
}

11.6.2 HAProxy

HAProxy est un load balancer open-source performant :

# haproxy.cfg
global
    log /dev/log local0
    maxconn 4096
    tune.ssl.default-dh-param 2048

defaults
    log global
    mode http
    option httplog
    option dontlognull
    retries 3
    timeout connect 5000
    timeout client 50000
    timeout server 50000

frontend http-in
    bind *:80
    bind *:443 ssl crt /etc/ssl/certs/example.pem
    redirect scheme https if !{ ssl_fc }
    
    acl is_api path_beg /api
    acl is_static path_beg /static
    
    use_backend api_servers if is_api
    use_backend static_servers if is_static
    default_backend web_servers

backend api_servers
    balance roundrobin
    option httpchk GET /health
    server api1 10.0.1.10:3000 check
    server api2 10.0.1.11:3000 check
    server api3 10.0.1.12:3000 check

11.7 Network Policies

11.7.1 Kubernetes NetworkPolicies

Les NetworkPolicies controlent le trafic entre pods :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-network-policy
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: frontend
        - podSelector:
            matchLabels:
              app: ingress-gateway
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: database
      ports:
        - protocol: TCP
          port: 5432

11.7.2 Calico

Calico offre des NetworkPolicies avancees :

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: security-policy
  namespace: production
spec:
  selector: app == 'api'
  ingress:
    - action: Allow
      protocol: TCP
      source:
        selector: app == 'frontend'
      destination:
        ports:
          - 8080
    - action: Allow
      protocol: TCP
      source:
        namespaceSelector: projectcalico.org/name == 'monitoring'
      destination:
        ports:
          - 9090
  egress:
    - action: Allow
      protocol: TCP
      destination:
        selector: app == 'database'
        ports:
          - 5432
    - action: Deny
      destination: {}

11.7.3 Cilium

Cilium utilise eBPF pour le networking et la securite :

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-policy
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
  egress:
    - toEndpoints:
        - matchLabels:
            app: database
      toPorts:
        - ports:
            - port: "5432"
              protocol: TCP
    - toFQDNs:
        - matchName: "api.external.com"

11.8 eBPF

11.8.1 Qu'est-ce qu'eBPF ?

eBPF (extended Berkeley Packet Filter) permet d'executer du code sable dans le noyau Linux :

Application ──> Syscall ──> eBPF Program ──> Kernel
                                        │
                                   Maps (data)
                                        │
                                   Userspace

Cas d'usage :

• Networking (Cilium)
• Observabilite (Pixie, Hubble)
• Securite (Falco, Tetragon)
• Tracing (bpftrace)

11.8.2 Cilium avec eBPF

Cilium remplace kube-proxy et CNI avec eBPF :

# cilium-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: cilium-config
  namespace: kube-system
data:
  kube-proxy-replacement: strict
  enable-endpoint-routes: "true"
  auto-direct-node-routes: "true"
  ipam: cluster-pool
  cluster-pool-ipv4-cidr: "10.0.0.0/16"
  cluster-pool-ipv4-mask-size: "24"
  tunnel: "disabled"
  native-routing-cidr: "10.0.0.0/8"
  enable-hubble: "true"
  hubble-listen-address: ":4244"
  hubble-relay-enabled: "true"

Avantages de Cilium/eBPF :

• 5-10x meilleures performances que iptables
• Visibilite L7 sur tout le trafic
• Securite au niveau du noyau
• Observabilite native (Hubble)
• Remplacement de kube-proxy

Resume

• Le modele OSI a 7 couches structure les communications reseau
• CoreDNS est le DNS natif Kubernetes, Route53 pour AWS
• TLS chiffre les communications, mTLS authentifie les deux cotes
• Nginx et Envoy sont les proxies les plus utilises dans le cloud
• Istio est le service mesh le plus complet, Linkerd le plus leger
• ALB (L7) vs NLB (L4) selon les besoins de routing
• Les NetworkPolicies sont essentielles pour la securite reseau
• eBPF revolutionne le networking avec des performances inegalees