Cilium bez bočnih proxy-a: eBPF-napajana mrežna povezanost u 2026.

Model bočnih proxy-a bio je zadana arhitektura mrežne mreže od kada je Istio objavljen 2017. Svaki pod dobiva svoj Envoy proxy — pravila iptables-a preusmjeravaju promet u proxy-e u prostoru korisnika, od kojih svaki troši 50–100 MB RAM-a i 0,1–0,5 vCPU-a. U prosječnom Kubernetes imenu s 100 podova, to je 5–10 GB memorije i 10–50 vCPU jezgri namijenjenih overhead-u proxy-a. Istraživanje CNCF-a iz 2024. pokazalo je da 62% timova navodi overhead resursima kao primarnu frustraciju s mrežnom mrežom. Cilium eliminiše bočni proxy potpuno pokretanjem podatkovne ravnine u Linux kernelu putem eBPF-a.

Što mrežna mreža zapravo čini

Mrežna mreža omogućava pet temeljnih mogućnosti transparentnih za kod aplikacija: otpornu povezanost između usluga (balanсiranje opterećenja, pokušaji, preklapanje kruga), upravljanje prometom L7 (rutiranje HTTP-a, manipulacija zaglavljem, dijeljenje prometa), sigurnost temeljenu na identitetu (međusobni TLS, primjena politike), promatranje (zapisnici toka, metrike, karte usluga) i transparentnost — bez izmjena koda u spremnicama aplikacija. Cilium isporučuje svih pet bez per-pod proxy-a.

Model bočnog proxy-a u kontekstu

U klasičnom modelu bočnog proxy-a (Istio klasično), zahtjev od klijentskog bočnog proxy-a prema serveru prolazi kroz dva Envoy proxy-a:

Client Pod           Server Pod
+--------------+    +--------------+
| App → Envoy  |    | Envoy → App  |
+------+-------+    +------+-------+
       |                   |
       +─────→Kernel───────+
             (iptables redirects)

Svaki zahtjev nastaje dva dodatna skoka u prostoru korisnika. Pravila iptables-a koja preusmjeravaju promet u bočni proxy dodaju latenciju i operativnu složenost. Restartanja bočnih proxy-a tijekom postavljanja uzrokuju prekide veze. Trošak resursa raste linearno s brojem podova.

Ulazak eBPF-a: Programabilnost na razini kernela

eBPF (prošireni Berkeley Packet Filter) dozvoljava sandboxirane programe da se izvršavaju unutar Linux kernela bez izmjene izvora kernela ili učitavanja kernelskih modula. eBPF verifikator osigurava da su programi sigurni — nema beskonačnih petlji, nema nesigurnog pristupa memoriji. Cilium koristi eBPF za rutiranje usluga i balanсiranje opterećenja (izravni povrat servera, Maglev konzistentno raspršivanje, NAT46/64), primjenu mrežne politike na L3/L4, šifriranje temeljeno na WireGuard-u, izvoz metapodataka toka u Hubble i kriptografsko upravljanje identitetom podova putem BPF mapa.

Zahtjev kernela je kritičan: Cilium trebanja Linux 4.9+ za minimalnu podršku, 5.10+ za produkciju i 6.1+ za cijeli skup mogućnosti. Stariji korporativni Kubernetes klasteri na RHEL 8 (kernel 4.18) ili ekvivalentnog ne mogu pokrenuti Cilium nativno.

Ciliumova arhitektura bez bočnih proxy-a

Podatkovne ravnine

Cilium premješta L3/L4 obradu — rutiranje, balanсiranje opterećenja, primjenu politike i šifriranje — u Linux kernel putem eBPF programa prikačenih na XDP, TC i cgroup hook-ove. Nema dodatnih skokova u prostoru korisnika za te operacije. Identitet bočnog proxy-a (kriptografski heš skupa oznaka bočnog proxy-a) je priložen svakom paketu putem BPF mapa, tako da se odluke o politici zbivaju na brzini kernela bez prebacivanja konteksta.

Client Pod           Server Pod
+----------+        +----------+
|   App    |        |   App    |
+----+-----+        +----^-----+
     |                    |
     +─────→eBPF in──────+
             Kernel
       (identity-based routing,
        policy enforcement,
        load balancing)

Za L7 promet (HTTP, gRPC, WebSocket), Cilium raspodijeljuje zajedničkog Envoy proxy-a po čvoru — ne po bočnom proxy-u. Ovo je kritična arhitekturna razlika od modela bočnog proxy-a; kada se L7 politika poklapa, eBPF programi transparentno preusmjeravaju promet na per-node Envoy, koji obrađuje inspekciju HTTP metode/zaglavlja/putanje, zatim vraća odluku kernelu za primjenu.

Kontrolne ravnine

Ciliumova kontrolna ravnina ima četiri komponente:

Komponenta	Postavljanje	Uloga
Cilium Agent	DaemonSet (jedan po čvoru)	Upravljanje eBPF programima, konfiguracija Envoy-a, dodjela identiteta, izračun politike
Cilium Operator	Deployment (1–2 replike)	CIDR dodjela, upravljanje CRD-om, orkestracija Cluster Mesh-a
Hubble	DaemonSet + Deployment	Praćenje toka, Relay za prikaz cijelog klastera, UI za karte ovisnosti usluga
Envoy	Ugrađen u Cilium Agent ili autonomni DaemonSet	L7 proxy za HTTP/gRPC politiku, Gateway API, Ingress

Cilium agent na svakom čvoru prati API server Kubernetes-a radi promjena podova, usluga, endpointa i politike. Kompajlira ta opažanja u eBPF programe i BPF mape, zatim ih učitava u kernel. Ažuriranja politike se šire u milisekundama — ne sekundama.

L7 upravljanje prometom s Gateway API-jem

Cilium podupire Gateway API v1.6.1 sa svim temeljnim testovima podudarnosti prolazećim: GatewayClass, Gateway, HTTPRoute, GRPCRoute, TLSRoute, TCPRoute, UDPRoute, BackendTLSPolicy i ReferenceGrant. Također podupire GAMMA (Gateway API za upravljanje mrežnom mrežom i administraciju), što omogućava upravljanje L7 prometom od istoka do zapada za komunikaciju između internih usluga.

Sljedeći primjer kreira Gateway i HTTPRoute za promet od istoka do zapada između dviju usluga:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: internal-gateway
spec:
  gatewayClassName: cilium
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
  - name: internal-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api/v2
    backendRefs:
    - name: api-service
      port: 8080

U pozadini, Cilium Operator prati Gateway API resurse, potvrđuje ih i prevodi ih u CiliumEnvoyConfig (CEC) resurse. Cilium Agent preuzima CEC i programira per-node Envoy. Ta indirekcija je bitna pri otklanjanju grešaka — CEC-ovi imaju minimalnu potvrdu i nema rješavanja sukoba, tako da pogrešno konfigurirani pravila rutiranja zahtijevaju izravnu inspekciju Envoy konfiguracije.

Mrežna politika na L3/L4 i L7

CiliumNetworkPolicy provodi politike temeljene na identitetu na razini kernela. Oznake, ne IP adrese, identificiraju krajnje točke — ovo čini politike otpornim na promjene podova i preraspodijeljenja.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: api-l7-policy
spec:
  endpointSelector:
    matchLabels:
      app: my-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/public"

Ova politika odabira podove s oznakom app: my-api, dozvoljava ingress samo od podova s oznakom app: frontend i na L7 samo dopušta GET /public zahtjeve — sve ostale HTTP metode i putanje su odbijene. Dodavanje L7 pravila automatski omogućava default-deny za taj port. Za promatranje L7 prometa bez filtriranja, koristite praznu HTTP pravila: http: [{}].

Sigurnost: Međusobna autentikacija i šifriranje

Ciliumov model sigurnosti radi na dvije razine s različitim stupnjevima zrelosti.

Šifriranje WireGuard (stabilno): Šifriranje na razini čvora šifrira sav promet između Cilium-upravljanih čvorova. Ovo je sprema za produkciju i nezavisno od značajke mTLS mrežne mreže.

Međusobna autentikacija / mTLS (beta stanje od Cilium 1.20 / srpanj 2026): Ciliumova implementacija mTLS-a koristi SPIFFE/SPIRE za identitet opterećenja. Per-node SPIRE agenti potvrđuju opterećenja i izdaju SVID-ove; Cilium agenti izvršavaju out-of-band mTLS rukovanje koristeći cache autentikacije. Plan razvoja mTLS-a je iskren o tome što još trebanja:

Značajka	Stanje
SPIFFE/SPIRE integracija	Beta
API autentikacije	Beta
mTLS rukovanje između agenata	Beta
Podrška politike	Beta
WireGuard integracija	TODO
Rukovanje po konekciji	TODO
Testiranje penetracije	TODO
Pregled stabilne zrelosti	TODO

Za timove koji trebaju auditu, testiranje penetracijom mTLS-om u produkciji, sidecar Istio ili Ambient način ostaju sigurniji izbor u sredini 2026. Ciliumov mTLS je upotrebljiv za procjenu i manje kritične putnje, ali plan razvoja ima nekoliko sigurnosti kritičnih stavki još označenih kao TODO.

Hubble — promatranje

Hubble pruža automatsku vidljivost toka bez instrumentacije ili bočnih proxy-a. EBPF podatkovne ravnine izvožu metapodatke toka — L3/L4 tokovi (tko je razgovarao s kime, na kojem portu, kada) i L7 tokovi (HTTP metoda, putanja, kod statusa, latencija) — izravno iz kernela.

# Promatrajte sve tokove za specifičan pod
hubble observe --pod default/my-pod

# Promatrajte samo L7 HTTP tokove
hubble observe --pod default/my-pod --type l7

# Promatrajte tokove između dva imena
hubble observe --from-namespace frontend --to-namespace backend

Hubble Relay agregira podatke kroz čvorove za upite na razini cijelog klastera. Hubble UI prikazuje vizualnu kartu ovisnosti usluga pokazujući obrasce prometa u stvarnom vremenu. Izvoz metrika u Prometheus za integraciju s postojećim nadzornim pločama.

Praktična instalacija

Instalirajte Cilium s mrežnom mrežom mogućnostima putem Helm-a:

helm upgrade cilium cilium/cilium --version 1.20.0 \
  --namespace kube-system \
  --reuse-values \
  --set kubeProxyReplacement=true \
  --set ingressController.enabled=true \
  --set ingressController.loadbalancerMode=dedicated \
  --set envoyConfig.enabled=true \
  --set loadBalancer.l7.backend=envoy

Omogućite Hubble Relay i UI za promatranje:

helm upgrade cilium cilium/cilium --version 1.20.0 \
  --namespace kube-system --reuse-values \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

Za međusobnu autentikaciju (beta), instalirajte SPIRE uz Cilium:

cilium install --version 1.20.0 \
  --set authentication.mutual.spire.enabled=true \
  --set authentication.mutual.spire.install.enabled=true

Cilium nasuprot mrežnim mrežama temeljenim na bočnim proxy-ima

Dimenzija	Cilium (bez bočnog proxy-a)	Istio klasično (bočni proxy)	Istio Ambient
L3/L4 podatkovne putanje	U kernelu eBPF	iptables → proxy u prostoru korisnika	Per-node ztunnel
Dodatna latencija	~0–1 ms L3/L4, ~1–2 ms L7	~2–5 ms po skok	~1–3 ms L4, ~2–5 ms L7
Memorija po čvoru	~100–200 MB ukupno	~50–100 MB × N podova	~50 MB ztunnel + waypoint-ovi
mTLS zrelost	Beta (SPIFFE/SPIRE)	Stabilna	Stabilna
Zahtjev kernela	Linux 5.10+, 6.1+ preporučeno	Nema	Nema
Izolacija bočnog proxy-a	Zajednički Envoy po čvoru	Envoy po bočnom proxy-u (izoliran)	Zajednički ztunnel + opcijski izoliran Envoy

Kompromisi i ograničenja

Ciliumov pristup bez bočnog proxy-a ima prava operativna ograničenja koja timovi trebaju procijeniti prije usvajanja.

Beta mTLS. Za okruženja produkcije koja trebaju zrelu, testiranje penetracijom provjerenu međusobnu TLS, Istio ostaje sigurniji izbor. Ciliumov plan razvoja mTLS-a navodi testiranje penetracije, rukovanje po konekciji i pregled stabilne zrelosti kao TODO.

Izolacija zajednog Envoy-a. Jedan per-node Envoy obrađuje L7 promet za sve podove na tom čvoru. Pogrešno konfiguriran CiliumEnvoyConfig za jednu uslugu može utjecati na promet za druge usluge na istom čvoru. U modelu bočnog proxy-a, rušenje Envoy-a ili pogrešna konfiguracija utječe samo na jedan pod.

Krhkost CiliumEnvoyConfig-a. CEC CRD ima minimalnu potvrdu, nema definiranog rješavanja sukoba i nema bogatog povratnog signala greške. Zvanična dokumentacija upozorenja da CEC resursi “trebali bi biti tretirani kao resursi administratora klastera.” Otklanjanje grešaka zahtijeva izravnu inspekciju Envoy konfiguracije i dnevnika.

Ovisnost o verziji kernela. Cilium trebanja Linux 5.10+ za produkciju. Timovi koji pokrenuti starije distribucije Kubernetes-a (RHEL 8 s kernelom 4.18) ne mogu usvojiti Cilium bez nadogradnje čvorova. Mrežne mreže temeljene na bočnim proxy-ima rade na bilo kojem kernelu.

Cluster Mesh + mTLS nekompatibilnost. Prema dokumentaciji Cilium 1.20, klasteri povezani u Cluster Mesh ne mogu koristiti međusobnu autentikaciju. Nema jedne domene povjerenja preko klastera za kombiniranje Cluster Mesh-a i mrežne mreže.

Integracija trećih strana. Ciliumova Gateway API i Ingress implementacije su Cilium-specifične. Za razliku od Istio-a, koji koristi standardne xDS API-je Envoy-a koji rade s mnogo alata u ekosustavu, Ciliumova Envoy integracija koristi prilagođene CiliumEnvoyConfig resurse.

Razmatranja migracije

Od običnog Kubernetes-a (bez postojeće mrežne mreže): Cilium se može instalirati uz postojeće CNI postavke s oprezom. Novi klasteri trebali bi samo instalirati Cilium s pravim Helm zastavicama. Nula promjena koda za aplikacije — Ciliumovo uhvaćanje prometa je transparentno za kod bočnog proxy-a.

Od Istio bočnih proxy-a: Istio i Cilium ne mogu trčati side-by-side kao konkurentne mreže na istim opterećenjima. Preporučena strategija je postavljanje Cilium kao CNI uz Istio (mogu koexist na CNI razini s pravilnom konfiguracijom), zatim migracija opterećenja jedan po jedan po imenu. CiliumNetworkPolicy zamjenjuje Istio AuthorizationPolicy — politike trebali bi biti ponovno kreirane. Ako se oslanjate na Istio-ovu stabilnu mTLS, čekajte dok Ciliumova međusobna autentikacija dosegne stabilnu prije migracije tih opterećenja. Na kraju, onemogućite Istio injiciranje i restartajte podove za uklanjanje bočnih proxy-a.

Zaključci za 2026.

Cilium je zadana CNI na GKE, EKS i AKS u 2026, i njegove mogućnosti mrežne mreže su dovoljno zrele za L3/L4 slučajeve upotrebe i upravljanje L7 prometom u produkciji — sve dok možete raditi unutar mTLS i ograničenja izolacije. Za nove Kubernetes klastre gdje je zahtjev kernela ispunjen i mTLS nije odmah potreban zahtjev produkcije, Ciliumov pristup bez bočnog proxy-a nudi manju latenciju, manju potrošnju resursa i jednostavnije upravljanje od alternativa temeljenih na bočnim proxy-ima.

eBPF vještine postaju sve vrijednije kako Cilium i slični projekti (Falco, Pixie, Katran) grade na istoj osnovi. Inženjeri koji razumiju mrežnu povezanost na razini kernela biti će inženjeri platforme koji osmišljavaju sljedeću generaciju cloud infrastrukture.

Cilium v1.20.0 je objavljen 2026-07-29. Zrelost značajke i zahtjevi kernela temelje se na ovoj verziji. Za ažurirane smjernice, provjerite službenu Cilium dokumentaciju. Izvori: Cilium Service Mesh Overview, Gateway API Support, L7 Traffic Management, Mutual Authentication, Hubble, CiliumNetworkPolicy, eBPF.io, GitHub: cilium/cilium, Gateway API Implementations, mTLS Design CFP, mTLS Roadmap.