1. dubna 2025

Rejekts 2025 v Londýně – druhý den

Jsem v Londýně na šestidenním "maratonu" konferencí: Cloud Native Rejekts (30.–31. 3.), KubeCon co-located events (1. 4.) a KubeCon samotný (2.–4. 4.). Rejekts jsou první – a já mám za sebou druhý den. Jaký byl?

Co jsou Cloud Native Rejekts

Rejekts je malá dvoudenní konference pro přednášky, které se nedostaly na KubeCon.

Jejich vlastními slovy:

Cloud Native Rejekts is the b-side conference giving a second chance to the many wonderful, but rejected talks leading to KubeCon + CloudNativeCon.

Rejekts jsou díky sponzorům zdarma a konají se na zajímavém místě, ale s velmi omezenou kapacitou – je tedy těžké se sem dostat. Sám jsem se dostal až z čekací listiny přetlaku.

Vojta Mareš na Rejekts

Ano, také se přidávám k trendu ChatGPT a obrázků předělaných do stylu studia Ghibli.

Co mají společného Rejekts a KubeCon

Jak jsem psal výše – Rejekts jsou přednášky, se kterými se lidé hlásili na KubeCon (a CloudNativeCon), ale nedostali se. Jejich druhou šancí, jak přednášet, se tedy stává Rejekts.

Co zajímavého jsem se dozvěděl

V pondělí jsem byl opět na několika přednáškách – některé lepší, jiné slabší. Tady jsou moje postřehy.

Evaluating Global Load Balancing Options for Kubernetes in Practice

Za mě asi nejzajímavější přednáška dne.

Přednášeli Tobias Schneck a Nicolai Ort.

Jak na load balancing v Kubernetes?

Můžu si koupit hotové HA řešení například od Google Cloudu (GSLB), Cloudflare, Fastly, Akamai… ale pokud nechci kupovat hotovou věc, můžu si to postavit sám.

Více clusterů a jejich propojení: Cilium Cluster Mesh. Mám k dispozici interní endpointy a prosíťované clustery, funguje to dobře, ale neřeší to ingress, když jeden cluster vypadne. Zároveň se clustery musí vzájemně vidět a nesmí si překrývat IP rozsahy.

Ingress řešení: K8GB – Kubernetes native Global Load Balancer. K8GB funguje tak, že v clusteru spustí vlastní CoreDNS instanci, která se stará o DNS A záznamy pro ingress domény, a pomocí external-dns konfiguruje třeba Cloudflare, kde přidává DNS NS záznamy pro nové CoreDNS instance. Ty pak resolvují DNS.

Je to velice pěkné řešení. Samozřejmě, v případě multi-clusteru je třeba propojit K8GB mezi clustery, aby si navzájem nesahaly do konfigurace. A protože DNS je zdrojem všech problémů (vždycky je to DNS…) a hlavně se cachuje, může v případě failoveru nastat krátkodobý výpadek. Na live demu byl kratší než jedna minuta.

Co jsem si odnesl: Failover/HA jde řešit přes více clusterů a Cilium Cluster Mesh pro interní služby. Pro public služby (API apod.) buď použít hotové řešení, nebo K8GB.

Simplifying Cross-Cloud, Cross-Cluster Connectivity with Dapr & Cilium

Přednášeli Alice Gibbons a Manuel Zapf.

Tahle přednáška byla vlastně jeden velký fičák – a to, co si odnáším, je, že Dapr je každý rok lepší a lepší. Pomocí jeho SDK dokážu vývojářům neskutečně usnadnit život, a platform tým se stará o jednotlivé služby (Redis, Kafka…). Vývojáře to vlastně vůbec nezajímá a všechno funguje velmi pěkně. No a v kombinaci s Cilium – zpátky u Cluster Meshe a propojení více clusterů – je Dapru úplně jedno, kde co běží. Prostě paráda 🎉!

The Service Mesh Wars: A New Hope for Kubernetes

Přednášel Henrik Rexed.

Přednáška byla velké srovnání různých Service Mesh řešení: Kuma, Linkerd, Cilium, Istio, Ambient a spojení s Gateway API.

V tomhle není žádný jednoznačný vítěz – záleží na tom, co hledáte pro svůj use case. Za mě důležité rozhodovací body jsou:

A co Gateway API? Specifikace zatím neumí retries, circuit breaking nebo rate limiting, ale třeba Envoy Gateway to zvládá pomocí vlastního CRD. Iniciativa Gateway API GAMMA (Gateway API for Service Mesh) se rozjíždí a třeba za dva roky to vyřeší všechny naše problémy…

Co jsem si odnesl: Eeeeh, záleží, co chci – a podle toho si musím vybrat. Zatím není jednoznačný vítěz.

The Kubernetes Guardians: A Deep Dive Into Your Security Avengers

Přednášeli Henrik Rexed a Ben Hirschberg.

Opět šlo hlavně o srovnání nástrojů pro security: Falco, KubeArmor, Tetragon, Kubescape. Ale tentokrát tu je vítěz.

Ne všechny nástroje jsou si rovné. Některé fungují jako runtime policy engine – tedy vymáhají pravidla za běhu, jiné spíše jen reportují události. Konfiguraci každý řeší po svém a i deployment model se liší – od DaemonSetu po řešení s operátorem, několika CRD, deploymenty a DaemonSetem k tomu.

Co jsem si odnesl: Kubescape je nejsnadnější, má rozumné smart defaults a stačí ho nasadit do clusteru – a hned dostávám smysluplné informace. Všechna řešení ale přidávají latenci, klidně i 10 ms v callstacku mikroslužeb.

Scaling PDBs: Introducing Multi-Cluster Resilience with x-pdb

Přednášel Moritz Johner.

Jak řešit PodDisruptionBudget ve světě multi-clusteru a udržet počet podů i napříč clustery.

Use case: Form3 provozuje clustery napříč cloud providery a on-prem řešením a potřebují zajistit vysokou dostupnost CockroachDB (distribuovaná SQL databáze). A protože CockroachDB využívá Raft (algoritmus pro distribuovaný consensus), je vždy potřeba nadpoloviční většina nodů v Raft clusteru. Klasický PodDisruptionBudget tohle řeší a umožňuje definovat, o kolik podů můžeme přijít skrz běžnou evikci (Evictions), ale neřeší vynucené evikce (node pressure – RAM, disk, CPU, síť).

Proto ve Form3 vytvořili open source projekt x-pdb, který řeší PDB napříč clustery 😲. x-pdb funguje na bázi admission webhooku a hijackingu Eviction API volání, takže je nezávislý na Kubernetes providerovi. Jednotlivé controllery jsou propojené a využívají nativní Kubernetes objekt lease pro získání zámku v každém clusteru, než začnou manipulovat s pody. Řešení není dokonalé a mohou nastat race conditions v okrajových případech – ale za rok se jim to nestalo ani jednou. Pokud controller nezíská zámek v ostatních clusterech, výchozí chování je, že neumožní žádnou manipulaci s pody.

Co jsem si odnesl: Multi-cluster není sranda – hlavně u stateful aplikací (např. databáze), které jsou rozprostřené napříč clustery. U stateless aplikací (např. backend k API) se to dá zvládnout lépe – a případně aplikace chvilku běží v degraded stavu, což ale u Raftu nejde – cluster by se rozpadl.

The Infinite Hotel: Scaling Multi-Tenant Platforms through a Unified API

Přednášeli Carlos Mestre del Pino a Christopher Haar.

Zábavná přednáška s analogií nekonečného hotelu, s nekonečnými patry, místnostmi, službami… aneb jak si nezamotat hlavu kolem nekonečna a jak se tohle promítá do multi-tenantních řešení.

Nešlo o technický deep dive, ale velmi pěkně to shrnulo problematiku škálování „do nekonečna“ – a že to jen tak nejde. Je potřeba se na škálování připravit. Doporučuji záznam, pokud je multi-tenance něco, co řešíte.

Co jsem si odnesl: Multi-tenance není sranda. Je dobré investovat čas do promyšlení řešení a neskočit do toho po hlavě. Loft vCluster je super pro provozování tenantů ve vlastním Kubernetes clusteru – a přitom nemusím mít stovky samostatných clusterů v cloudu.

Wasm, Envoy, and Hyperlight Walk Into a Pod: No Vulnerabilities Allowed

Přednášeli Danilo (Dan) Chiarlone a Mikhail Krinkin.

Představení projektu Hyperlight – Virtual Machine Manager (VMM) v Rustu pro WASM aplikace – a jak Hyperlight implementuje Envoy pro filtry. Důležitá poznámka: Hyperlight sandbox zaniká po každém volání filtru a nemá žádná perzistentní data.

Obecně je možné Hyperlight použít pro bezpečné spouštění kódu třetích stran – protože neumožňuje přímé volání žádných SYSCALLs. Vše jde přes Hyperlight a konkrétní funkce musí být přímo poskytnuty WASM programu, který je volá přes Hyperlight.

Lightning talks

Na závěr Rejekts následoval sled několika tzv. lightning talků, tedy přednášek na 5 minut.

Protože to byly pětiminutovky, vezmu to ve zkratce:

Záznam

Pro vás, kdo nejste v Londýně a chcete se podívat na přednášky alespoň ze záznamu – Rejekts mají veřejný playlist na YouTube se záznamem všech přednášek.

Další články

Sem budu v průběhu týdne doplňovat další články z každého dne konferencí.