Kas yra Cilium ir kodėl jis keičia žaidimo taisykles
Kubernetes tinklo pasaulis ilgą laiką gyveno su iptables ir tradiciniais tinklo sprendimais, kurie veikė, bet ne visada efektyviai. Cilium atėjo kaip gaivus vėjas, pasiūlydamas visiškai kitokį požiūrį – naudojant eBPF (extended Berkeley Packet Filter) technologiją tiesiogiai Linux branduolyje. Tai ne tik dar vienas CNI (Container Network Interface) pluginas, o fundamentalus poslinkis, kaip galvojame apie tinklą, saugumą ir stebėjimą Kubernetes aplinkose.
eBPF leidžia vykdyti sandboxed programas tiesiogiai Linux branduolyje be poreikio keisti branduolio kodą ar įkelti modulių. Skamba technikiškai? Praktiškai tai reiškia, kad Cilium gali apdoroti tinklo paketų maršrutizavimą, saugumo politikas ir stebėjimą daug greičiau nei tradiciniai sprendimai, nes viskas vyksta branduolio lygmenyje, išvengiant brangių konteksto perjungimų tarp branduolio ir vartotojo erdvės.
Kaip Cilium veikia po gaubtu
Tradiciniai Kubernetes tinklo sprendimai dažnai remiasi iptables taisyklėmis, kurios tampa vis lėtesnės, kai klasteris auga. Įsivaizduokite tūkstančius taisyklių, kurias reikia peržiūrėti kiekvienam paketui – tai kaip ieškoti knygos bibliotekoje be katalogo sistemos. Cilium naudoja eBPF programas, kurios veikia kaip išmanūs filtrai tiesiogiai tinklo sąsajoje.
Kai paketas patenka į sistemą, eBPF programa jį analizuoja ir priima sprendimus iškart – leisti, blokuoti, peradresuoti ar stebėti. Šios programos yra kompiliuojamos į bytecode ir vykdomos branduolyje su JIT (Just-In-Time) kompiliavimu, todėl pasiekiamas beveik natyvus našumas. Cilium agentas veikia kiekviename node kaip DaemonSet ir atsakingas už eBPF programų įkėlimą bei atnaujinimą.
Vienas iš gražiausių dalykų – Cilium naudoja BPF maps (hash lentelės branduolyje) greitam duomenų apsikeitimui. Pavyzdžiui, visi endpoint’ai, jų IP adresai ir saugumo identiteto numeriai saugomi šiose lentelėse, todėl paketų apdorojimas vyksta žaibiškai greičiau nei tradicinėse sistemose.
Identiteto pagrindu veikiantis saugumas – ne IP, o kas tu esi
Čia prasideda tikroji magija. Tradiciniai firewall’ai ir tinklo politikos remiasi IP adresais. Bet Kubernetes pasaulyje pod’ai gimsta ir miršta, IP adresai keičiasi kasdien. Cilium įveda identiteto koncepciją – kiekvienas pod’as gauna unikalų saugumo identitetą pagal Kubernetes labels.
Kai kuriate NetworkPolicy, Cilium nekonvertuoja jos į tūkstančius IP-based taisyklių. Vietoj to, jis priskiria identiteto numerį (pvz., 12345) visiems pod’ams su tam tikromis labels ir leidžia komunikaciją tarp identitetų. Kai pod’as perkuriamas su nauju IP, jo identitetas lieka tas pats – politikos automatiškai veikia be jokių papildomų operacijų.
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: allow-frontend-to-backend
spec:
endpointSelector:
matchLabels:
app: backend
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
protocol: TCP
Ši politika veikia identiteto lygmenyje. Cilium automatiškai suseka visus pod’us su label’u „app: frontend” ir „app: backend”, priskiria jiems identitetus ir sukuria efektyvias eBPF programas šiai komunikacijai leisti.
Service mesh funkcionalumas be papildomo overhead
Istio ir Linkerd yra puikūs, bet jie prideda sidecar konteinerius prie kiekvieno pod’o, o tai reiškia papildomą atminties naudojimą, CPU ciklus ir latency. Cilium siūlo alternatyvą – service mesh funkcionalumas tiesiogiai branduolyje per eBPF.
Cilium Service Mesh gali atlikti L7 (HTTP, gRPC, Kafka) protokolų maršrutizavimą, load balancing, circuit breaking ir net distributed tracing be jokių sidecar’ų. Kaip? eBPF programos gali skaityti ir modifikuoti aplikacijos lygio protokolus tiesiogiai socket lygmenyje. Tai vadinama „sidecar-less service mesh” ir tai tikrai veikia gamyboje.
Pavyzdžiui, galite sukurti HTTP-based routing taisykles:
apiVersion: cilium.io/v2
kind: CiliumEnvoyConfig
metadata:
name: http-routing
spec:
services:
- name: my-service
namespace: default
backendServices:
- name: backend-v1
namespace: default
number:
- "8080"
- name: backend-v2
namespace: default
number:
- "8080"
routingRules:
- match:
- headers:
- name: "version"
exact: "v2"
route:
- destination: backend-v2
weight: 100
Cilium integruoja Envoy proxy, bet ne kaip sidecar – vietoj to, Envoy veikia kaip shared proxy node lygmenyje, aptarnaujantis visus pod’us, kas drastiškai sumažina resource overhead.
Observability – matyk, kas vyksta tinkle realiu laiku
Vienas didžiausių Cilium privalumų – neprilygstamas visibility į tinklo srautus. Kadangi visa komunikacija eina per eBPF programas, Cilium gali stebėti ir įrašyti kiekvieną paketą, kiekvieną HTTP užklausą, kiekvieną DNS query be jokio papildomo instrumentavimo aplikacijose.
Hubble – tai Cilium observability platforma, kuri suteikia grafines sąsajas ir API tinklo srautams vizualizuoti. Galite matyti:
- Kurie pod’ai su kuriais komunikuoja (service map)
- Kokios HTTP užklausos vykdomos, jų status kodai ir latency
- DNS užklausos ir atsakymai
- Blokuoti paketai dėl NetworkPolicy
- TCP connection metrics
Visa ši informacija renkama be performance penalty, nes eBPF programos gali efektyviai agregavoti metrikas branduolyje ir siųsti tik susumuotus duomenis. Hubble UI leidžia interaktyviai naršyti šiuos duomenis, o Hubble CLI – query’inti iš komandų eilutės:
hubble observe --from-pod frontend --to-service backend --protocol http
Ši komanda parodys visas HTTP užklausas iš frontend pod’ų į backend servisą su visomis detalėmis – metodas, path, status kodas, latency. Debugging’as tampa trivialus.
Diegimas ir praktiniai patarimai
Cilium diegimas nėra sudėtingas, bet yra niuansų. Paprasčiausias būdas – per Helm chart. Prieš diegdami, įsitikinkite, kad jūsų Linux kernel versija yra bent 4.9 (rekomenduojama 5.10+), nes senesnės versijos neturi visų reikiamų eBPF funkcijų.
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium --version 1.14.5 \
--namespace kube-system \
--set kubeProxyReplacement=strict \
--set k8sServiceHost=YOUR_API_SERVER_IP \
--set k8sServicePort=6443
Parametras kubeProxyReplacement=strict yra svarbus – jis nurodo Cilium visiškai pakeisti kube-proxy funkcionalumą. Tai reiškia, kad Cilium valdys visą Service load balancing per eBPF, o ne iptables. Rezultatas – daug greitesnis service discovery ir connection handling.
Jei diegiate esamame klasteryje su kitu CNI, migracija reikalauja atsargumo. Rekomenduoju:
- Pradėti nuo test/staging aplinkos
- Įsitikinti, kad visi node’ai turi reikiamą kernel versiją
- Naudoti Cilium connectivity test po diegimo:
cilium connectivity test - Stebėti Cilium agent logus pirmąsias valandas
- Turėti rollback planą (backup senų CNI konfigūracijų)
Vienas dažnas klausimas – ar Cilium veikia su managed Kubernetes (EKS, GKE, AKS)? Atsakymas – taip, bet su niuansais. EKS ir AKS puikiai palaiko Cilium. GKE reikalauja specifinių nustatymų, nes Google turi savo VPC networking. AWS EKS net turi native Cilium palaikymą per EKS add-on sistemą.
Performance ir skalė – skaičiai, kurie įspūdingi
Teorija yra graži, bet kaip Cilium veikia praktikoje? Benchmark’ai rodo įspūdingus rezultatus. Lyginant su tradiciniais iptables-based sprendimais:
- Service lookup latency sumažėja ~90% dideliuose klasteriuose (1000+ services)
- NetworkPolicy enforcement overhead – beveik nulinis (vs 20-30% su iptables)
- Connection establishment greitis padidėja 3-5 kartus
- CPU naudojimas tinklo operacijoms sumažėja 40-60%
Realūs case studies rodo, kad kompanijos, migravusios į Cilium, pastebi:
Datadog pranešė, kad po migracijos į Cilium jų Kubernetes klasteriuose sumažėjo tinklo latency 25%, o node CPU utilization dėl tinklo operacijų nukrito nuo 15% iki 6%. Tai reiškia, kad daugiau CPU ciklų lieka aplikacijoms.
Trip.com (vienas didžiausių kelionių platformų Kinijoje) su 10,000+ node Kubernetes klasteriu pranešė, kad Cilium leido jiems valdyti 100,000+ pod’ų su stabiliu performance, kai ankstesnis sprendimas pradėjo degraduoti ties 30,000 pod’ų.
Svarbu suprasti, kad šie privalumai tampa akivaizdūs dideliuose klasteriuose. Jei turite 10 node klasterį su 50 pod’ų, skirtumas nebus dramatiškas. Bet kai skalė auga, Cilium pranašumai tampa eksponentiniai.
Troubleshooting ir dažniausios problemos
Nors Cilium yra brandus projektas, kaip ir bet kuri kompleksinė sistema, jis turi savo quirks. Štai dažniausios problemos ir sprendimai:
eBPF programos neįsikelia: Dažniausiai dėl per senos kernel versijos arba neįjungtų kernel features. Patikrinkite su cilium status – jis parodys, kokių features trūksta. Sprendimas – atnaujinti kernel arba disable tam tikras Cilium funkcijas.
Pod’ai negauna IP adresų: Paprastai IPAM (IP Address Management) konfigūracijos problema. Cilium palaiko kelis IPAM režimus – cluster-pool, kubernetes, azure, aws-eni. Įsitikinkite, kad pasirinktas tinkamas režimas jūsų aplinkai.
NetworkPolicy neveikia kaip tikėtasi: Cilium NetworkPolicy yra galingesnė nei standartinė Kubernetes NetworkPolicy, bet kartais tai sukelia painiavą. Naudokite cilium endpoint list pamatyti, kokie identitetai priskirti pod’ams, ir cilium policy get pamatyti aktyvias politikas. Hubble UI čia neįkainojamas – galite vizualiai matyti, kurie paketai blokuojami.
Performance problemos po diegimo: Retai, bet atsitinka. Paprastai dėl netinkamų tuning parametrų. Patikrinkite:
- Ar
kubeProxyReplacementnustatytas į „strict” - Ar MTU (Maximum Transmission Unit) teisingai sukonfigūruotas
- Ar BPF map sizes pakankami dideliems klasteriams
Debugging’ui naudokite cilium-dbg komandas. Pavyzdžiui, cilium-dbg bpf lb list parodys visus load balancer entries, o cilium-dbg monitor – realaus laiko paketų srautą per eBPF.
Ateities perspektyvos ir kodėl verta investuoti
Cilium nėra tik dar vienas hype train. eBPF technologija tampa Linux branduolio standartu, o Cilium – de facto standartu Kubernetes tinkle. CNCF (Cloud Native Computing Foundation) priėmė Cilium kaip incubating projektą 2021-ais, o 2023 jis pasiekė graduated statusą – tai reiškia brandumą ir community palaikymą.
Kas dar svarbiau – didžiosios cloud platformos investuoja į Cilium. Google Cloud pradėjo siūlyti GKE Dataplane V2, kuris pagrįstas Cilium. AWS EKS turi native Cilium add-on. Isovalent (kompanija už Cilium) sutraukė dešimtis milijonų investicijų ir buvo įsigyta Cisco 2023-ais už $1 milijardą – aiškus signalas, kad technologija turi ateitį.
Praktiškai, jei kuriate naują Kubernetes klasterį šiandien, Cilium turėtų būti default pasirinkimas, nebent turite specifinių apribojimų. Jei turite esamą klasterį, migracija į Cilium duos realią vertę, kai:
- Jūsų klasteris turi 50+ node’ų
- Naudojate daug NetworkPolicy
- Reikia geresnio observability
- Planuojate service mesh funkcionalumą
- Performance ir skalė yra kritiniai
Mokymosi kreivė nėra stačia. Jei suprantate Kubernetes networking pagrindus, Cilium konceptai bus intuityvūs. eBPF žinios nėra būtinos kasdieniam naudojimui – Cilium abstrahuoja sudėtingumą. Bet jei norite gilintis, eBPF mokymasis atsiveria duris į visiškai naują Linux branduolio programavimo pasaulį.
Dokumentacija yra puiki, community aktyvus Slack’e, o troubleshooting resources gausūs. Cilium taip pat turi puikų interaktyvų laboratorių – labs.cilium.io – kur galite išbandyti funkcijas be jokio setup’o.
Galiausiai, Cilium nėra silver bullet. Jis neišspręs blogai suprojektuotų aplikacijų ar architektūrinių problemų. Bet jis duoda fundamentaliai geresnę platformą tinklo, saugumo ir observability aspektams. Tai investicija į ateitį, kuri atsipirks ne tik performance, bet ir operaciniu paprastumu bei galimybėmis, kurias atrakina eBPF technologija.
