Blog

Så mange EU-cloud… Hvilken cloud skal jeg vælge til min Kubernetes-cluster?

Introduktion Der er flere forskellige EU-cloud-udbydere, og de er ikke alle ens. De excellerer inden for forskellige områder, og måske overvejer du, hvilken der passer bedst til dine use cases. Jeg har selv prøvet et par stykker af, så du ikke behøver. Eller måske inspirere dig til selv at eksperimentere. I dette blogindlæg vil jeg […]

Introduktion

Der er flere forskellige EU-cloud-udbydere, og de er ikke alle ens. De excellerer inden for forskellige områder, og måske overvejer du, hvilken der passer bedst til dine use cases.

Jeg har selv prøvet et par stykker af, så du ikke behøver. Eller måske inspirere dig til selv at eksperimentere.

I dette blogindlæg vil jeg se nærmere på fire EU-cloud-udbydere, forsøge at lave et par eksperimenter ved hjælp af Kubernetes og andre tools, og derefter liste mine findings. Formatet af dette blogindlæg er ikke et poleret format; men minder mere om dagbogsnotater, jeg har taget undervejs på min rejse.

De fire EU-cloud-udbydere, jeg har valgt at se nærmere på, er:

• Scaleway (fransk)
• Exoscale (schweizisk)
• OVHcloud (fransk)

Der findes andre udbydere, men disse er en god og repræsentativ gruppe, hvis dit fokus er Kubernetes og EU-cloud.

Jeg har valgt eksperimenter og applikationer, der for det første ligger tæt på de use cases jeg ofte møder, og for det andet kan teste cloud-udbydernes funktionalitet.

Dette er mit perspektiv og det kan sagtens være at du har andre use cases, eller at du fokuserer på andre kriterier når du evaluerer. Andre kriterier kan eksempelvis være pris, support-pakker, tilgængelige SLA’er, historisk performance osv. Denne blog er specifikt fokuseret på Kubernetes-relaterede features ved de valgte cloud-udbydere.

Opsummering og konklusion

Lad os starte med konklusionen.

Så hvorfor er Kubernetes relevant? Jo, jeg havde brug for en applikation til mit eksperiment. Kubernetes er supporteret i alle clouds, men modenhed, funktioner og hvorvidt der findes en managed Kubernetes service varierer fra cloud til cloud.

Derudover har Kubernetes-applikationer en tendens til at være mindre besværlige at flytte fra én cloud til en anden, i modsætning til applikationer, der bruger funktioner, som er specifikke for en bestemt cloud. Og cloud-mobilitet er fokus for mange.

Først det oplagte spørgsmål: Kan jeg flytte min Kubernetes-applikation fra en af de amerikanske cloududbydere til en EU-cloud? De europæiske leverandører udvider og forbedrer deres tilbud hele tiden, så spørgsmålet er mere aktuelt end nogensinde. Som du kan se i dette indlæg, tilbyder mange europæiske clouds allerede solid understøttelse af Kubernetes. For mange virksomheder er det nu blevet afgørende at undersøge europæiske cloud-muligheder, fordi de ønsker større digital suverænitet og uafhængighed i et marked, der i høj grad domineres af amerikanske spillere.

Konklusion 1
Så er det muligt at flytte? Jeg vil sige JA. Medmindre du laver noget meget specifikt, burde du kunne flytte – måske dog med nogle ændringer i din tech stack.

Men Kubernetes i sig selv er kun en lille/brøkdeldel af billedet. Hvad med de omkringliggende services, du ofte har brug for? Jeg har lavet en ønskeliste nedenfor og baseret mine eksperimenter og applikationer på den:

Hvorfor managed Kubernetes? Hvorfor Cilium-netværk og observability osv.?

Jeg ønskede at se, hvad der ville ske, hvis jeg pressede grænserne lidt længere end blot at køre simple Kubernetes-workloads. Ville alle clouds opføre sig ens? Som du kan se nedenfor, er der altså forskelle.

Efter mit eksperiment og udrulning af applikationerne er min opsummering:

Applikation	Hetzner	Scaleway	Exoscale	OVHcloud
Managed k8s	Ikke understøttet	Ja	Ja	Ja
Terraform support	Ja	Ja	Ja	Ja
CLI support	Ja	Ja	Ja	Nej. Kun for AI-services.1
Service med cloud load balancer	Ja (CCM installeret manuelt)	Ja	Ja	Ja
Cilium support on managed k8s	N/A	Ja	Ja	Kun for udvalgte regioner
Cilium Hubble support	N/A	Ikke understøttet	Ikke understøttet	Ikke understøttet
Cilium cluster mesh support	Kun self-managed	Kun self-managed	Kun self-managed	Kun self-managed
Official CAPI provider	Ja	Ja	Nej	Nej

Hvilket leder mig frem til denne konklusion:

Hetzner	Billig, self-managed (DIY ) Kubernetes-cluster med ClusterAPI support
Scaleway	Managed Kubernetes med Cilium support og optional indbygget observability samt ClusterAPI support
Exoscale	Managed Kubernetes med Cilium support og optional observability-stack
OVHcloud	ManagedKubernetes med det laveste niveau af indbyggede ekstrafunktioner (fx ingen observability, begrænset Cilium support)
Alle	EU-hostet, flere EU-regioner, basale cloud-services, webkonsol, Terraform support

Konklusion 2 Ikke alle clouds er ens, og mere specifikt: ikke alle EU-clouds er ens. Jeg blev positivt overrasket over at finde ud af, at 3 ud af 4 understøtter Managed Kubernetes, og ofte med Cilium som fokus. Kubernetes er en prioriteret service, hvilket er forfriskende, da nogle af ”de gamle” cloud-udbydere i første omgang flyttede sig langsomt på dette område. Dokumentation og Terraform -support er dog mindre modent sammenlignet med det, du måske er vant til andre steder.
Du kan køre Kubernetes i alle fire, men du bør sandsynligvis tjekke din egen ønskeliste og dine krav, før du vælger en udbyder.

Så, du er nået hertil i bloggen. Super! Lad os nu dykke lidt dybere. Hvis du er interesseret i at se baggrunden for ovenstående konklusion, kodeeksempler og forstå præcist, hvor tingene virkede, og ikke mindst, hvor de fejlede, så læs endelig videre.

Tid til eksperimenter: mine konfigurationer og min rejse

Filer

Jeg har lagt kode og konfiguration fra mine eksperimenter i dette git repo. Og selvom jeg har inkluderet at par kodeeksempler i denne tekst, anbefaler jeg at du kigger i repoet hvis du vil se detaljerne.

1. Managed Kubernetes

Scaleway, Exoscale, OVHcloud = ja. Hetzner Cloud = nej.

Scaleway, Exoscale og OVHcloud understøtter alle en Managed Kubernetes-service
Hetzner Cloud tilbyder ikke managed Kubernetes, så her er alternativet ”Do it yourself” self-managed. Men du starter ikke fra bunden: på hetzner.com findes der udmærket dokumentation og tutorials om, hvordan man kan arbejde med Kubernetes på platformen.

Scaleway, Exoscale og OVHcloud understøtter alle udrulning af en managed cluster via Terraform.

Her er et simpelt Terraform eksempel for OVHcloud:

Terraform-koden for Scaleway og Exoscale følger samme principper

Hvordan logger jeg så på mit cluster? Med en kubeconfig-fil. Denne fil kan jeg få ved at logge ind i mine noder men… Ideelt vil jeg gerne undgå at logge på mine noder for at hente min kubeconfig-fil.

For OVHcloud kan kubeconfig eksporteres via Terraform-output:

Hvis du ikke ønsker at gemme din kubeconfig i din Terraform statefile, understøtter Scaleway og Exoscale også at hente kubeconfig via CLI:

OVHcloud har ikke et cloud CLI, så denne mulighed er ikke tilgængelig her.

2. Cloud Load Balancer

Scaleway, Exoscale, OVHcloud, Hetzner Cloud = nej.

Alle fire udbydere understøtter en cloud load balancer. Det vil sige, at alle fire udbydere understøtter Kubernetes Service-ressourcer af typen LoadBalancer, hvilket muliggør integration mellem Kubernetes service og cloud load-balancer og automatisk deployment af cloud-native load balancer.

Hetzner er lidt speciel i denne henseende, da der ikke findes managed Kubernetes. Der er dog stadig en løsning. Hetzner stiller en Cloud Control Manager til rådighed, som kan installeres via et Helm-chart, og denne Cloud Control Manager muliggør brugen af en cloud load balancer. Dette kræver dog et API-token for at kunne integrere med Hetzner API’et (naturligt, da din self-managed cluster skal deploye resourcer i Hetzner):

I alle fire clouds bruges der simple annotationer for integration og konfiguration af load balancer. Nedenfor ses et eksempeluddrag af en Hetzner manifest file. De øvrige clouds er tilsvarende, dog med andre annotationer:

3. Managed Kubernetes and Cilium Networking

Scaleway, Exoscale = ja. OVHcloud = joeh… Hetzner Cloud = nej.

Både Scaleway og Exoscale understøtter Cilium som CNI. Cilium kan vælges som CNI webkonsollen eller ved at angive det via Terraform.
Hvad angår de øvrige cloud-udbydere: Hetzner tilbyder ikke Managed Kubernetes, så manuel installation er den eneste mulighed. OVHclouds administrerede Kubernetes er lidt anderledes. Jeg kan ikke vælge min CNI via Terraform. I stedet afhænger CNI’en i øjeblikket af, hvilken region jeg bruger. Hvis jeg udruller mit cluster i UK-regionen, vil den bruge Calico, mens hvis du udruller i Paris-regionen, vil den bruge Cilium.

Her er et eksempel for Scaleway:

Og et eksempel for Exoscale:

Så enkelt er det.

4. Managed Kubernetes og Hubble Observability

Scaleway = ja. Exoscale, OVHcloud, Hetzner Cloud = nej.

Da både Scaleway og Exoscale supporterer Cilium, er jeg interesseret i, om jeg kan bruge Cilium Hubble til observability her.
Ingen af de 2 har Hubble aktiveret som standard. Da Cilium administreres af managed Kubernetes i begge clouds, kan ændringer af Cilium konfiguration potentielt være besværligt.

Scaleway

Scaleway stiller en række Helm-charts til rådighed, som kan bruges med Kubernetes.

Og jeg kan bruge et af disse Helm-chart til at installere Hubble:

Så enkelt er det.

Exocloud Scalable Kubernetes Service (SKS)

Jeg har ikke kunnet finde en reference til, hvordan man aktiverer Cilium Hubble på SKS – eller om det overhovedet er understøttet eller muligt. Jeg kan altså aktivere Cilium i managed Kubernetes, men det er uklart, om jeg kan aktivere Hubble-observability.

5. Cilium Cluster Mesh

Scaleway, Exoscale, OVHcloud, Hetzner Cloud = nej.

Connectivity mellem Kubernetes clusters kan være besværligt og kræve, at man involverer flere teams og manuel konfiguration. Cilium Cluster Mesh forsøger at forenkle denne proces og gøre den til en mere automatiseret oplevelse med indbygget network security.

Hvorfor synes jeg, at Cilium Cluster Mesh er interessant i EU-cloud-udbyder-scenariet? Det kan være et værdifuldt værktøj, når man flytter workloads ind i EU-cloud. I en migrationsfase gør det det muligt at sprede services på tværs af gamle og nye miljøer.

Så, ligesom ovenfor: Da både Scaleway og Exoscale understøtter Cilium som en CNI, er jeg interesseret i, om jeg kan bruge Cilium Cluster Mesh her. Og (igen) da Cilium administreres af managed Kubernetes i begge clouds, kan ændring af Ciliums konfiguration være besværligt. Men desværre viser det sig, at installation af Cilium Cluster Mesh ikke er supporteret. Eller, jeg har i hvert fald ikke fundet en måde.

Der er forskellige udfordringer. Et eksempel er, at cluster.id og cluster.name er ikke eksponeret via UI eller Terraform, og clustermesh-apiserver ikke umiddelbart kan aktiveres.

Som resultat gælder, at selvom Cilium er til stede og fungerer til single-cluster-brug, kræver Cluster Mesh mere self-managed miljø, hvor Cilium frit kan konfigureres med mesh-kapabiliteter.

På den anden side, hvis jeg vælger at gå self-managed, kunne jeg sætte et mesh op mellem alle fire cloud-udbydere uden nogen hindringer. Og jeg har inkluderet et par kodeeksempler i mit git-repo.

6. ClusterAPI

Scaleway, Hetzner Cloud = ja. Exoscale og OVHcloud, = nej.

Ovenfor har vi kigget på forskellige muligheder for managed Kubernetes og self-managed.

Men der er en tredje vej: for dem, der søger en mellemvej mellem kontrol og bekvemmelighed kan ClusterAPI være et interessant alternativ. ClusterAPI tilbyder en “self-managed managed Kubernetes”-oplevelse som muliggør brugen af den samme ”managed” løsning på tværs af flere clouds og on-prem. Det kan være smart både i et hybrid- og et migrationsscenarie.

2 af de EU-clouds, der er testet her, har en Cluster API Provider opført i det officielle CAPI-providerregister. Disse to er Hetzner og Scaleway.

Idéen bag ClusterAPI er, at der findes en applikation der provisionerer og manager dine clusters. Applikationen er deployet på en separat Kubernetes cluster (management cluster) og herfra kan vi så deploye workload-clusters.

For Hetzner Cloud kan jeg udrulle en workload-cluster fra min management-cluster blot ved at:

For Scaleway har jeg et meget lignende billede:

Med ClusterAPI kan jeg anvende de samme værktøjer på tværs af flere clouds og on-premises. Andre platforme som AWS, Azure, GCP, vSphere og Proxmox supporterer også Cluster API.

Hvad med Exoscale og OVHcloud? Exoscale har ganske vist en provider på GitHub, men den er ikke blevet opdateret i et stykke tid. Jeg har ikke kunnet finde nogen CAPI-integration relateret til OVHcloud.

Opsamling

Ok, lad os samle op. I dette indlæg har jeg undersøgt, hvordan fire EU-cloud-udbydere håndterer managed Kubernetes, og andre Kubernetes features inklusive Cilium. Samt overvejelser om, hvornår det kan være bedre selv at administrere sin Kubernetes cluster eller endda vælge “self-managed managed Kubernetes” ClusterAPI.

Konklusion 3
Som altid afhænger det rigtige valg af dine specifikke tekniske og compliance-krav. Så tjek din ønskeliste og dine krav, når du vælger din udbyder.
Det betyder, at hvis du foretrækker managed Kubernetes, har du én liste. Hvis du vil bruge Cilium CNI på din managed Kubernetes, bliver listen kortere. Hvis du planlægger at bruge flere clouds eller både cloud og on-prem, kan ClusterAPI være interessant – og i dette tilfælde får du en helt anden liste.

Så hvor efterlader alt det her dig? Hvis Kubernetes er centralt i din stack, kan det være tid til at begynde at teste EU-cloud-muligheder op imod dine egne krav. Som vist i dette blogindlæg er det hverken svært eller dyrt at starte et lille cluster op, afprøve managed Kubernetes (måske med Cilium eller andre funktioner) og evaluere forskellige ting som fx developer experience.

God testing! Hvis du har spørgsmål eller andre findings end mig er du mere end velkommen til at skrive til mig.

Hvis du vil læse mere, kan du tage et kig på blogindlægget “EU-cloud eller ej?” som diskuterer EU-clouds generelt (ikke kun Kubernetes).

Om forfatteren