🔴 Advanced

Kubernetes Networking — Siete v K8s

Networking je jedným z najdôležitejších aspektov Kubernetes. Každý pod, service a externý prístup závisí od správne nakonfigurovanej sieťovej vrstvy. V tomto článku si prejdeme všetko od pod-to-pod komunikácie až po Service Mesh.

Pod-to-Pod komunikácia

Kubernetes definuje základné sieťové pravidlá:

Každý pod má vlastnú IP adresu — pody nepotrebujú NAT na vzájomnú komunikáciu
Všetky pody môžu komunikovať s akýmkoľvek iným podom bez NAT (v rámci klastra)
Agenti na node (kubelet, kube-proxy) môžu komunikovať so všetkými podmi na danom node

┌─────────── Node 1 ───────────┐    ┌─────────── Node 2 ───────────┐
│  Pod A (10.244.1.2)           │    │  Pod C (10.244.2.3)           │
│  Pod B (10.244.1.3)           │    │  Pod D (10.244.2.4)           │
└───────────┬───────────────────┘    └───────────┬───────────────────┘
            │         Pod-to-Pod (flat network)   │
            └─────────────────────────────────────┘

Ako to funguje v praxi

Pody na rovnakom node komunikujú cez Linux bridge (cbr0/cni0)
Pody na rôznych nodoch používajú overlay network (VXLAN, WireGuard) alebo BGP routing
CNI plugin zabezpečuje prideľovanie IP adries a routing

Services — Stabilný prístup k podom

Pody sú ephemeral — ich IP adresy sa menia. Service poskytuje stabilnú virtuálnu IP (ClusterIP) a DNS meno.

ClusterIP (default)

Interný prístup v rámci klastra:

apiVersion: v1
kind: Service
metadata:
  name: backend-svc
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

Dostupný len zvnútra klastra
Kube-proxy vytvára iptables/IPVS pravidlá pre load balancing
DNS: backend-svc.default.svc.cluster.local

NodePort

Exponuje service na statickej porte (30000–32767) na každom node:

apiVersion: v1
kind: Service
metadata:
  name: frontend-svc
spec:
  type: NodePort
  selector:
    app: frontend
  ports:
    - port: 80
      targetPort: 3000
      nodePort: 31000

Prístup: <NodeIP>:31000
Vhodné pre development a testovacie prostredia
V produkcii zvyčajne nahradené LoadBalancerom alebo Ingressom

LoadBalancer

Automaticky vytvorí externý load balancer (cloud provider):

apiVersion: v1
kind: Service
metadata:
  name: api-svc
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - port: 443
      targetPort: 8443

Funguje s cloud providermi (AWS ELB, GCP LB, Azure LB)
On-premise: MetalLB ako alternatíva
Každý LoadBalancer service = vlastná externá IP (môže byť drahé)

Porovnanie typov Services

Typ	Prístup	Use case
ClusterIP	Len interný	Backend služby, databázy
NodePort	`<NodeIP>:<Port>`	Dev/test, jednoduché nasadenia
LoadBalancer	Externá IP	Produkčné služby v cloude
ExternalName	CNAME redirect	Externé služby (RDS, API)

Ingress — HTTP/HTTPS routing

Ingress poskytuje HTTP(S) routing na viacero services cez jednu IP adresu:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - app.example.com
      secretName: tls-secret
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-svc
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-svc
                port:
                  number: 80

Nginx Ingress Controller

Najpopulárnejší ingress controller:

# Inštalácia cez Helm
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx --create-namespace

Kľúčové funkcie:

SSL termination, rate limiting, rewrites
Canary deployments (weight-based routing)
Custom error pages, CORS konfigurácia

Traefik Ingress Controller

Moderný, cloud-native ingress controller:

helm repo add traefik https://traefik.github.io/charts
helm install traefik traefik/traefik \
  --namespace traefik --create-namespace

Výhody Traefiku:

Automatické Let's Encrypt certifikáty
Middleware (auth, rate-limit, circuit breaker)
Dashboard pre monitoring
Natívna podpora IngressRoute CRD

# Traefik IngressRoute
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: app-route
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`app.example.com`) && PathPrefix(`/api`)
      kind: Rule
      services:
        - name: api-svc
          port: 80
  tls:
    certResolver: letsencrypt

CNI pluginy

Container Network Interface (CNI) je štandard pre sieťové pluginy v Kubernetes. CNI plugin je zodpovedný za prideľovanie IP adries podom a routing medzi nimi.

Calico

Najrozšírenejší CNI plugin pre produkčné prostredia:

L3 routing cez BGP (bez overlay) — nízka latencia
Podpora overlay (VXLAN, IP-in-IP) pre multi-cloud
Pokročilé Network Policies (vrátane egress, DNS pravidiel)
WireGuard šifrovanie medzi nodami

# Inštalácia
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/calico.yaml

Flannel

Jednoduchý overlay network — ideálny na začiatok:

VXLAN overlay (default)
Minimálna konfigurácia, jednoduché nasadenie
Bez podpory Network Policies (nutný doplnok, napr. Calico)
Vhodný pre menšie klastre a learning

kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

Cilium

Moderný CNI postavený na eBPF:

eBPF-based — nahradí iptables, vyšší výkon
L3/L4/L7 Network Policies (vrátane HTTP, gRPC, Kafka)
Transparentné šifrovanie (WireGuard/IPsec)
Vstavaný Hubble pre network observability
Service Mesh bez sidecar proxy

# Inštalácia cez Cilium CLI
cilium install --version 1.15.0
cilium hubble enable --ui

Porovnanie CNI pluginov

Feature	Calico	Flannel	Cilium
Network Policies	✅ Pokročilé	❌	✅ L7
Overlay	Voliteľný	VXLAN	Voliteľný
Výkon	Vysoký (BGP)	Stredný	Vysoký (eBPF)
Zložitosť	Stredná	Nízka	Vyššia
Observability	Základná	Žiadna	Hubble

Network Policies

Network Policies sú K8s natívny spôsob ako kontrolovať sieťovú komunikáciu medzi podmi (mikro-segmentácia):

Deny all — baseline politika

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Povolenie špecifickej komunikácie

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Best practices pre Network Policies

Začni s deny-all v každom namespace
Postupne pridávaj allow pravidlá podľa potreby
Používaj labels konzistentne (app, tier, environment)
Testuj policies cez kubectl exec a curl/wget
Cilium/Calico ponúkajú rozšírené policies (DNS, L7)

DNS v Kubernetes

Kubernetes má vstavaný DNS server (zvyčajne CoreDNS), ktorý umožňuje service discovery cez DNS mená.

DNS formát

<service>.<namespace>.svc.cluster.local

Príklady:

backend-svc.default.svc.cluster.local → plné meno
backend-svc.default → v rámci klastra
backend-svc → v rámci rovnakého namespace

CoreDNS konfigurácia

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
        }
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

Headless Service — pre StatefulSets

apiVersion: v1
kind: Service
metadata:
  name: db-headless
spec:
  clusterIP: None  # Headless
  selector:
    app: postgres
  ports:
    - port: 5432

DNS záznamy pre headless service:

db-headless.default.svc.cluster.local → vráti IP všetkých podov
pod-0.db-headless.default.svc.cluster.local → konkrétny pod (StatefulSet)

Debugging DNS

# Spusti debug pod
kubectl run dns-test --image=busybox:1.36 --rm -it -- sh

# Testuj DNS resolution
nslookup backend-svc.default.svc.cluster.local
nslookup kubernetes.default

# Skontroluj CoreDNS logy
kubectl logs -n kube-system -l k8s-app=kube-dns

Service Mesh — úvod

Service Mesh pridáva sieťovú vrstvu nad K8s networking pre pokročilé funkcie medzi službami.

Čo rieši Service Mesh?

mTLS — automatické šifrovanie medzi službami
Observability — metriky, traces, logy pre každý request
Traffic management — canary releases, circuit breaking, retries
Authorization — granulárne pravidlá (kto môže volať koho)

Populárne riešenia

Istio — najrozšírenejší, plne vybavený:

istioctl install --set profile=demo
kubectl label namespace default istio-injection=enabled

Linkerd — lightweight, jednoduchší na prevádzku:

linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
linkerd inject deployment.yaml | kubectl apply -f -

Cilium Service Mesh — bez sidecar proxy (eBPF):

Nižšia latencia a resource overhead
Menej moving parts
Integrácia s Cilium CNI

Kedy použiť Service Mesh?

Scenár	Potrebuješ SM?
<10 služieb, interný traffic	Pravdepodobne nie
Regulované prostredie (mTLS povinné)	Áno
Komplexný microservices systém	Áno
Potreba canary/traffic splitting	Áno
Malý tím, jednoduché nasadenie	Nie, prílišná komplexita

Best Practices

Networking

Používaj Network Policies — vždy deny-all ako default
Nepriraduj hostNetwork podom pokiaľ to nie je nevyhnutné
Vyber správny CNI — Flannel na learning, Calico/Cilium na produkciu
Monitoruj sieťový traffic — Hubble (Cilium), Grafana dashboards

Services & Ingress

Používaj Ingress namiesto NodePort/LoadBalancer pre HTTP služby
TLS termination na Ingress úrovni — nie v aplikácii
Health checks — vždy definuj readiness a liveness probes
Resource limits — nastav pre ingress controller aj aplikácie

DNS & Service Discovery

Používaj krátke DNS mená v rámci namespace (svc-name nie FQDN)

Nastav ndots správne — zníženie DNS lookupov:

spec:
  dnsConfig:
    options:
      - name: ndots
        value: "2"

Security

mTLS — zapni ak máš Service Mesh alebo použi Cilium WireGuard
Segreguj namespaces — jeden namespace na tím/prostredie
Obmedz egress — povol len potrebnú externú komunikáciu
Pravidelný audit — kubectl get networkpolicies -A

Zhrnutie

Kubernetes networking je rozsiahla téma, ale dá sa rozdeliť do prehľadných vrstiev:

Vrstva	Komponent	Účel
Pod network	CNI plugin	IP adresy, routing medzi podmi
Service	kube-proxy	Stabilná IP, load balancing
Ingress	Ingress controller	HTTP routing, TLS
Policy	NetworkPolicy	Mikro-segmentácia
DNS	CoreDNS	Service discovery
Mesh	Istio/Linkerd/Cilium	mTLS, observability, traffic mgmt

Pochopenie týchto vrstiev je kľúčové pre spoľahlivú a bezpečnú prevádzku Kubernetes klastrov.