Kubernetes stopt met populaire Ingress Nginx-controller door maintainerstekort

Kubernetes stopt met Ingress Nginx. Volgens de beheerders van de containertool zijn er inmiddels veel alternatieven voor de ingresscontroller, maar het stopzetten is alsnog opvallend omdat Ingress Nginx nog steeds erg populair is. De makers zeggen niet de middelen te hebben om de tool nog langer te onderhouden.

Het Kubernetes Security Response Committee, verantwoordelijk voor het beveiligingsonderhoud van de veelgebruikte containertool, schrijft dat het per maart 2026 stopt met het bijwerken van Ingress Nginx. Dat is een tool die dataverkeer naar Kubernetes-clusters op de juiste manier kan verdelen. De tool blijft na maart wel werken en wordt ook nog steeds ter installatie aangeboden, maar Ingress Nginx krijgt vanaf dat moment geen nieuwe releases meer en belangrijker: geen securityupdates en bugfixes. De organisatie raadt gebruikers aan om over te stappen naar een alternatief, bijvoorbeeld de Gateway-api. Zulke alternatieven hebben het voordeel dat ze vaak voor specifiekere doelen geschikt zijn; Ingress Nginx kan juist van alles een beetje.

Het stopzetten van Ingress Nginx komt enigszins als een verrassing, maar niet helemaal onverwacht. Vorig jaar lieten de maintainers al weten dat ze het werk, specifiek het beveiligingswerk, moeilijk meer aankonden. Dat leverde volgens de beheerders ook te weinig respons en oplossingen op. Tegelijkertijd is Ingress Nginx nog wel erg populair binnen Kubernetes. Het wordt nog veel gebruikt ondanks de vele alternatieven.

De reden dat de tool zo populair is, is ook de reden van de ondergang. Ingress Nginx is flexibel en kan veel. Volgens de beheerders is dat juist problematisch, omdat die flexibiliteit 'een onoverkomelijke hoeveelheid' techdebt heeft opgeleverd in de afgelopen jaren. Bovendien heeft Ingress Nginx vanaf dag één al weinig onderhoud gekregen vanuit maintainers.

De beheerders zeggen dat Ingress Nginx voorlopig nog best-effort maintenance krijgt. De makers hebben naar eigen zeggen alle mogelijkheden uitgezocht om dat onderhoud op een duurzame manier te waarborgen, maar dat is niet gelukt. Ze zeggen met Ingress Nginx te stoppen 'vanwege de gebruikersveiligheid'.

Reacties (65)

[Uninstall3d]

In de officiële aankondiging zit nog een belangrijk detail: Ingress NGINX wordt al jaren grotendeels onderhouden door 1–2 vrijwilligers. In combinatie met de enorme techdebt (door de flexibiliteit en o.a. `snippets`) is het simpelweg niet meer veilig om het project te blijven patchen.

Ook handig om te weten: het beoogde opvolg project ingate wordt óók stopgezet - dat is nooit volwassen geworden. De toekomst ligt daarom echt bij Gateway API of een andere (vendor) ingress/gateway-controller.

[Halfscherp]

Dit laat ook mooi de klucht zien van hoe bedrijven met open source omgaan. Ze knijpen maintainers helemaal uit. geven nooit een cent aan funding (of als ze dat doen is het 0.001% van hun winst), en als de maintainers er dan mee stoppen is de wereld ineens te klein.

Dit zie je ook bij FFmpeg of andere projecten, waar corporate bedrijven tickets open met P1 niet omdat het een kritieke fout is, maar omdat "een cliënt hier problemen mee ervaart en snel een oplossing nodig heeft". Maar funding opzetten ho maar.

[Llopigat]

Dit laat ook mooi de klucht zien van hoe bedrijven met open source omgaan. Ze knijpen maintainers helemaal uit. geven nooit een cent aan funding (of als ze dat doen is het 0.001% van hun winst), en als de maintainers er dan mee stoppen is de wereld ineens te klein.

Dit zie je ook bij FFmpeg of andere projecten, waar corporate bedrijven tickets open met P1 niet omdat het een kritieke fout is, maar omdat "een cliënt hier problemen mee ervaart en snel een oplossing nodig heeft". Maar funding opzetten ho maar.

Ja precies. Ik neem aan dat hier dan ook gewoon afwijzend op wordt gereageerd (of gewoon botweg om geld wordt gevraagd voor een support contract).

Heel toepasselijke XKCD: https://xkcd.com/2347/

[Reactie gewijzigd door Llopigat op 14 november 2025 16:58]

[supersnathan94]

kuch Leftpad kuch

On March 22, 2016, programmer Azer Koçulu took down the left-pad package that he had published to npm (a JavaScriptpackage manager). Koçulu deleted all his packages after a dispute with Kik Messenger, in which the company forcibly took control of the package name kik. As a result, thousands of software projects that used left-pad as a dependency, including the Babeltranscompiler and the React web framework, were unable to be built or installed. This caused widespread disruption, as technology corporations small and large, including Facebook, PayPal, Netflix, and Spotify, used left-pad in their software products.

[..]

Among the software technology corporations that used the package were Meta Platforms, PayPal, Netflix, Spotify^[8] — and Kik Interactive.^[1

:facepalm:

[William_H]

Zijn er initiatieven die bezig zijn om dit probleem op te pakken? Dat softwarepakketten wel open-source kunnen blijven, maar dat er wel genoeg funding en mankracht is om belangrijke software te onderhouden?

[StCreed]

Dat heet een bedrijfsmodel. Zoals RedHat of veel andere partijen dat hebben. Daarbij kun je vaak betaalde support krijgen. Verder kan je dan wel bugs melden maar die worden alleen opgepakt als men de rest heeft geholpen of het heel belangrijk vind. En dat vereist ook vaak dat er genoeg betalende klanten zijn.


Mensen verwarren open source nog steeds met gratis. Dat zijn twee verschillende zaken. En het probleem ligt hier bij gratis, niet bij open source.

[William_H]

Maar in theorie zou iemand dan ook een patch kunnen schrijven voor zo'n bug, aangezien het open source is .

Ja, dacht al dat je jndedaat met het Red Hat voorbeeld zou komen. Zo zijn er meerdere. Canonical voor Ubuntu zou je dan hetzelfde kunnen noemen, of Mozilla voor Firefox en Thunderbird.

[Solopher]

Even goed om te vermelden: Er gaat niks gebeuren met het Ingress object, je kunt dit blijven gebruiken (bijv. met een andere controller, tijdens een migratie), maar het is niet erg toekomstbestendig.

Verder denk ik dat 't een tijd nodig heeft voordat grote Helm Charts de Gateway API gaan ondersteunen.

Volgende week zelf maar eens onderzoek doen naar de Gateway API, maar op mijn "shortlist" staan voor nu:

• https://cilium.io/use-cases/gateway-api/
• https://www.haproxy.com/blog/announcing-haproxy-unified-gateway-beta

Misschien hebben jullie al naar alternatieven gekeken?

[Tubby]

is istio of traefik nog een alternatief op dit vlak?

[DeevieP]

Ja hoor. Soms levert je cloudleverancier er ook al eentje. Zelf gebruiken wij een netscaler ingress controller.

[Tubby]

wij draaien nu bij Azure (AKS), maar het grootste deel van de ingress wordt al bij CloudFlare gedaan. Waarschijnlijk hebben ze bij azure ook wel een alternatief hiervoor.

[supersnathan94]

Mja je zou de Azure Application Gateway Controller kunnen proberen?

https://learn.microsoft.com/en-us/azure/application-gateway/ingress-controller-overview

En anders hebben ze dacht ik ook Istio.

[ricjuh]

Wij gaan over naar Traefik: https://doc.traefik.io/traefik/reference/install-configuration/providers/kubernetes/kubernetes-gateway/

[Bl@ckbird]

Cilium wordt vanaf 20 hosts ongeveer interessant. Beetje afhankelijk welke features je zoekt. Daaronder is het te prijzig.

[F4RR3L]

Heb zelf net - na een aantal te bekijken en feature afwegingen - gekozen voor Envoy Gateway (de gateway-api impl van Envoy proxy).

best wel simpel om in gebruik te nemen en - voor ons in ieder geval - eigenljk alle features die we van nginx gebruiken/gebruikten zitten daar ook in én meer (zo zit OIDC, JWT e.d. daar "native" in, kon met nginx ook wel, maar was toch anders imho).

In any case, Envoy Gateway, aanrader w.m.b.

[maartenvdezz]

Ik vind Envoy Gateway voor Gateway API behoorlijk compleet. Een stuk completer dan de Cilium implementatie van Envoy.

[roelvdm3]

Wat ik begreep op KubeCon is dat er gewerkt wordt aan een opvolger InGate die de Gateway API ondersteund: https://github.com/kubernetes-sigs/ingate

KubeCon talk: YouTube: How To Gateway With Ingress - 140 Days InGate - Marco Ebert & James Strong

Persoonlijk merk ik ook dat de Nginx Ingress controller erg groot geworden is met alle annotations die het ondersteund. Daarmee lijkt de Gateway API een mooie vervolg stap.

[Yggdrasil]

In het artikel staat juist dat Ingate niet van de grond komt.

[david-v]

Zo, die gebruikten wij ook. Blij dat we uiteindelijk toch gestopt zijn met kubernetes. De inzet was te kleinschalig om daar echt baat bij te hebben.

[Scribe]

Ben eigenlijk wel benieuwd wanneer kubernetes pas echt de moeite waard wordt. Heb er zelf nog nooit mee gewerkt maar het voelt voor mij een beetje als overkill tenzij je echt grote services draait

[WernerL]

Kubernetes is nuttig als je Google bent. Applicaties die uit meerdere (micro)services bestaan en heel veel verkeer moeten kunnen verwerken en automatisch moeten schalen. Bijvoorbeeld om grote pieken in verkeer op te kunnen vangen.

Veel bedrijfsapplicaties kunnen prima wegkomen met een simpele modulaire monoliet die draait op een simpele saaie Linux VM.

Mijn ervaring is dat Kubernetes vooral voor een hoop extra complexiteit zorgt. Bij relatief eenvoudige applicaties met hoogstens 1000 gebruikers is dat compleet overbodig.

[Tubby]

de schaalbaarheid is overkill, maar kubernetes brengt ook wat andere dingen:

• rolling updates (containers updaten zonder downtime voor gebruikers / processen)
• flexibele configuratie (staging, productie, configuratie verschillen instelbaar en inzichtelijk hebben)
• updates op hosts (een kubernetes cluster heeft een aantal workers, je kunt gewoon nieuwe bijgewerkte workers toevoegen en oudere verwijderen om host updates door te kunnen voeren zonder downtime)
• portability, een kubernetes cluster kun je zelf runnen of kant-en-klaar afnemen bij Microsoft, Amazon, Google en tegenwoordig zelfs StackIT
• goede secret managment (voor env vars zoals db-passwords en api-keys) op een veilige manier kunnen gebruiken voor je applicatie (hier gebruik ik zelfs een 1Password operator voor)

je kunt er ook gewoon heel goed een monoliet in draaien als je dat wil en sterker nog; Google draait zelf niet op kubernetes ;)

[Reactie gewijzigd door Tubby op 14 november 2025 12:37]

[orvintax]

Wat ik hier nog graag op zou aanvullen is dat Kubernetes declaratief is. Wat ook in de infrastructuur wereld ontzettend waardevol is. Je beschrijft hoe je deployment er uit moet zien en Kubernetes regelt de rest.

[Tubby]

ja, klopt zeker, gitops is heel mooi te bouwen hiermee. Kubernetes op zichzelf is misschien ook wel meer de api-afspraken dan daadwerkelijke implementatie. Voor elk onderdeel opzichzelf heb je keuzevrijheid https://landscape.cncf.io/ :)

[Ed Vertijsment]

Nadeel is wel dat de voordelen relatief klein zijn ten opzichte van tooling die veel minder complex is. De meeste dingen die je beschrijft zijn prima te doen met "old school" tools als Ansible in een veel minder complex landschap.

Ik zie vaak Kubernetes gebruikt worden in omgevingen waar je, je eigenlijk wel moet afvragen of dat wel zo handig is.

De meeste applicaties gehost op een Kubernetes omgeving waarmee ik heb gewerkt voelen traag aan. Vaak eenvoudigweg omdat een containers zeer weinig resources krijgt toebedeelt (want duur) en de workload niet zozeer heel veel verkeer tegelijk, maar gewoon 1 request snel moet afhandelen. De headroom is dan heel laag en levert netto een trager resultaat op. Daarnaast krijg je bij microservices veel overhead van I/O wat het ook weer traag (en complex/fragiel) maakt.

Nu kan dit weggewuifd worden als gebrek aan kennis over hoe het goed te implementeren maar die kennis is duur (net zoals de resources om het op te draaien) en dat maakt dat veel van deze omgevingen een hoog prijskaartje hebben waarna vervolgens de resources weer teruggeschroefd worden en het weer van voor af aan begint.

De meeste organisaties hebben geen schaalbaarheid nodig die Kubernetes bied, maar gewoon fatsoenlijke out-of-the-box performance, iets waar Kubernetes absoluut niet in shined.

[supersnathan94]

De meeste organisaties hebben geen schaalbaarheid nodig die Kubernetes bied, maar gewoon fatsoenlijke out-of-the-box performance, iets waar Kubernetes absoluut niet in shined.

Kubernetes is een container orchestration platform, Of dat nou op bare metal draait of met VM's maakt weinig uit. De performance komt niet uit K8s, maar de onderliggende hardware. Er is wel een performance hit zeker, maar die is bij lange na niet zo groot dat je dat door hebt op dergelijke schaal.

Vaak eenvoudigweg omdat een containers zeer weinig resources krijgt toebedeelt (want duur)

tsja, je moet wel je sizing op orde hebben. Dat geldt ook voor VM workloads.

Kubernetes komt echter wel met een bepaald ethos wat belangrijk is. DevOps cultuur moet je dan echt wel hebben. Gone are the days of separate responsibilities.

Daarnaast krijg je bij microservices veel overhead van I/O wat het ook weer traag (en complex/fragiel) maakt.

Ik denk oprecht dat als je je processen goed afstemt op de mogelijkheden die er zijn met Microservices, dat je veel hogere efficientie en doorvoer kunt halen dan met monolitische applicaties. Het hang wel af van het type workload, maar zodra er 1 ding is wat veel gebruikt wordt en relatief veel performance vraagt, heeft het al zin om in ieder geval dat onderdeeltje schaalbaar te maken en af te splitsen.

De "modulith" is ook altijd nog een leuke optie: https://dzone.com/articles/architecture-style-modulith-vs-microservices

[Ed Vertijsment]

Ik vat het als het niet erg vind even even samen als “als je het goed doet kan het heel goed werken” , wat absoluut klopt.

Mijn put is dat die specialistisch werk is wat de kosten doet stijgen, het is dus vooral ook gewoon een heel duur platform, en die meerprijs is het heel vaak niet waard.

Je noemt dat resources goed ingedeeld moeten worden en dat, dat niet anders is als bij vm’s.

Zeker waar, maar ik vergelijk veel containers met één host, waarbij die host door headroom bijna altijd sneller is.

verder is het voor microservices heel moeilijk om een getunede relationele database te verslaan.

[supersnathan94]

Zeker waar, maar ik vergelijk veel containers met één host, waarbij die host door headroom bijna altijd sneller is.

Ja als je niet dezelfde hoeveelheid resources toekent zal het apparaat wat ongelimiteerd random dingen mag doen sneller zijn. Dat staat denk ik wel boven kijf.

Mijn put is dat die specialistisch werk is wat de kosten doet stijgen, het is dus vooral ook gewoon een heel duur platform, en die meerprijs is het heel vaak niet waard.

Het is niet specialistischer dan beheer van VMs oid. En qua licenties vaak significant goedkoper.

De vraag is vaak, wie het werk moet gaan doen. Zijn dat mensen naast je bestaande beheer groep dan is het uiteraard duurder. Is het de bestaande beheer groep of devops teams, dan is het vaak net zo duur al dan niet goedkoper omdat het op lange termijn een stuk eenvoudiger te beheren is.

verder is het voor microservices heel moeilijk om een getunede relationele database te verslaan.

Het 1 sluit het ander niet uit. Microservices hebben net zo goed baat bij een goed afgestelde database.

Overigens denk ik wel dat relationele databases soms overrated en onnodig zijn en dat eventual consistent noSQL databases veelal significant sneller kunnen zijn.

[Ed Vertijsment]

Ja als je niet dezelfde hoeveelheid resources toekent zal het apparaat wat ongelimiteerd random dingen mag doen sneller zijn. Dat staat denk ik wel boven kijf.

Als je meerdere processen op 1 machine draait, of die machine opsplitst in kleine machientjes gaat het kerst scenario vaak minder presteren doordat die niet het volledige potentieel van de host kan gebruiken. Dat kan nuttig zijn, maar vaak ook niet, en dan krijg je vooral een performance hit.

Het is niet specialistischer dan beheer van VMs oid. En qua licenties vaak significant goedkoper.

De vraag is vaak, wie het werk moet gaan doen. Zijn dat mensen naast je bestaande beheer groep dan is het uiteraard duurder. Is het de bestaande beheer groep of devops teams, dan is het vaak net zo duur al dan niet goedkoper omdat het op lange termijn een stuk eenvoudiger te beheren is.

Je vergelijkt appels met peren, infrastructure as code kan ook op andere manieren die goed te beheren zijn, ik zie de lage termijn voordelen voor kosten en beheerbaarheid in de praktijk niet (en ja, wij gebruiken k8s).

Negens heb ik enige licentiekosten genoemd trouwens.

Het 1 sluit het ander niet uit. Microservices hebben net zo goed baat bij een goed afgestelde database.

Overigens denk ik wel dat relationele databases soms overrated en onnodig zijn en dat eventual consistent noSQL databases veelal significant sneller kunnen zijn.

Een relationele database performt het best als alle data op 1 machine zit, fragmentatie over netwerk levert:

• Performance hits door io
• Matige indices en performance hits daar
• Gebroken foreign key integrity

Op te lossen met nog meer complexiteit maar dat is mijn punt weer: duur.

Microservices zijn monolieten met meer met netwerk calls

Dat data integrity klopt en op 1 machine bevraagd kan worden is underrated.

En ja: dat schaalt wel héél ver.

[Tubby]

klopt, maar wat je beschrijft heeft ook deels te maken met resources (eigen ijzer is vaak overgedimensioneerd), kosten (want goedkoper).

in veel scenario's ben je evengoed af met wat losse docker-hosts in combinatie met container. Dat "schaalt" meer dan voldoende in de meeste scenario's en die tussentijd kun je gebruiken om je applicaties beter geschikt te maken voor container gebruik (ook echt stateless maken door files / session en andere persistence beter te implementeren).

De uniformiteit (of api) van een container is wel een heel praktische gezamelijke taal voor ontwikkelaars en beheerders :)

[Ed Vertijsment]

De uniformiteit is zeker fijn, maar de last om applicaties aan te moeten passen aan een format voor uniformiteit niet. Als dat moet is dat eerder een leaky abstractie.

Eigen ijzer kan overgedimensioneerd zijn, cloud oplossingen zijn dat nog vaker (want veel goedkoper). Maar onder aan de streep haal je in veel gevallen véél meer performance uit een monoliet op een dedicated server tegen een fractie van de kosten.

[DeevieP]

Je moet echt wel niet de grootte hebben van een google om Kubernetes te gaan gebruiken. Noch moet je applicatie bestaan uit (micro)services. Ook het aantal gebruikers is niet echt van tel. Je hebt vooral nood aan voldoende maturiteit van je IT omgeving waarbij je zaken als 'infrastructure as code' toepast. Als je eigen applicaties ontwikkelt ga je ook volop voor DevOps principes. Als je alles manueel wil ontwikkelen, builden, deployen en updaten blijf dan heeeeeel ver weg van K8S en blijf bij je VM.

[TMC]

Niet mee eens. Ook voor 'homeservers' vind ik Kubernetes een uitkomst. Kubernetes is namelijk helemaal niet 'meer' werk o.i.d., alles wat je in Kubernetes doet moet je op een manier ook bij een 'klassiek' VM doen. Bij Kubernetes gaat het volgens een standaard API of format, terwijl als je geen Kubernetes gebruikt het free format is. Juist bij kleinschalige toepassingen is de structuur van Kubernetes een aanwinst omdat je dan niet de overhead hebt om zelf documentatie te schrijven of scripts te gaan ontwikkelen.

[Reactie gewijzigd door TMC op 14 november 2025 13:16]

[TMC]

Oké, maar hoe simpel is de VM nou echt? Of moet ik maar hopen dat een medewerker die er al jaren niet meer werkt ooit de reverse proxy heeft voorzien van goede documentatie?

VM's zijn vaak voorzien van scripts die lang niet zo mature zijn als de commando's van Kubernetes. Doe mij maar de universeel ondersteunde Kubernetes API i.p.v. het hobbywerk van een VM-beheerder.

[WernerL]

VM configuratie kun je volledig met Ansible automatiseren dus dat hoeft ook niet ingewikkeld te zijn.

VMs die aan elkaar hangen van custom bash-scripts zijn wel horror ja, maar dat ligt meer aan de persoon die dat ingericht heeft dan aan VMs.

Voor simpele monolieten heb ik in het verleden ook wel eens Azure AppServices gebruikt, dat werkt ook goed. Makkelijk naar toe te deployen vanuit een CI/CD pipeline, en via deployment slots kan het ook zonder downtime.

[TMC]

Ongetwijfeld werken Ansible of bepaalde Azure services heel goed in bepaalde omstandigheden. Maar zijn ze écht simpeler dan Kubernetes? Dat valt enorm tegen naar mijn ervaring.

[supersnathan94]

VM configuratie kun je volledig met Ansible automatiseren dus dat hoeft ook niet ingewikkeld te zijn.

Maar het is ansible... dus dat wordt dat heel snel wel. Ik wil daar eigenlijk niet al te veel over nadenken meer. Die complexiteit kan echt heel rap gaan.

[mocem]

Je omschrijft nu de moderne cloud engineer. Zet wat aan maar heeft geen idee wat er onder water gebeurd. Zolang je niet begrijpt hoe reverse proxies, netwerk, Linux en loadbalancers werkt is k8s of elke willekeurige een recipe for disaster.

Helaas is dit werkelijkheid aan het worden bij veel bedrijven.

[vargo]

Je zegt hier dat de moderne cloud engineer gewoon geen kennis en kunde heeft. Prutsers zijn van alle tijden en inderdaad een 'recipe for disaster', maar containers en container orchestration (zoals K8S) zijn hier niet de oorzaak van. Een moderne cloud engineer zal inderdaad moeten begrijpen hoe de app runtime werkt in de context van de hele tech stack, maar dat lijkt me niet meer dan logisch.

Deze paradigmas (containers & orchestration) bieden veel voordelen: infra-as-code, abstractie tov onderliggende tech (er is alleen een cluster), scaling & resource allocation, sidecar patterns, immutability etc. Ideen uit devops, 12-factor apps liggen in lijn met deze technologie - en zijn uiteindelijk goede practices.

En het is zeker niet zo dat vroeger de engineers wél alle kennis hadden. Toen je je "eigen" rackspace in een data center had (en die kwamen in allerlei vormen en smaken; soms geschikt soms niet), daar hardware (servers en networking) voor moest uitzoeken, en dan de hele tech stack moest opbouwen. Verschillende leveranciers voor verschillende tech: firewalls, routers, app servers, database servers, network storage, DMZ vs backend services etc etc. Er was een enorme wildgroei aan technologie, manieren om tech te configureren en te onderhouden, service contracten met leveranciers. Een crime om je security, high availability, monitoring & alerting in te regelen. Vaak werden dingen 'met de hand' gedaan, en zat kennis in de hoofden van enkele individuen. Maw er was een heel leger aan mensen met een klein stukje kennis, en die moesten tezamen er een werkend geheel van zien te maken.

[david-v]

tussen kubernetes en een VM is een hele wereld aan alternatieven. Er zijn nogal wat PAAS oplossingen waarbij er geen verschil is in werking of flexibiliteit. Een VM zie ik toch echt als een gepasseerd stadium, al zullen er genoeg usecases zijn waar een VM juist wel beter is dan een PAAS of een kubernetes cluster

[Jay-v]

Heel erg on-eens! Heb hier een klein cluster met zo'n 60 monolith applicaties.

Het maakt zo veel dingen makkelijker! Certificate vending, DNS integratie / updates, Monitoring (logs/metrics), Monitoring Alarms in yaml, Vulnerability Scanning (Trivy), Deployments, Cluster/Hosts upgrades, patching (doe ik niet, gewoon nieuwe hosts uitrollen), backups, restores, secret management, config files als code, failure recovery.

Kubernetes is zeker complex, maar je krijgt er enorm veel voor terug.

[TMC]

Deze onderwerpen zijn complex, niet zozeer Kubernetes. If anything maakt Kubernetes deze onderwerpen minder complex.

[Barsonax]

Het beheren van een VM kost echter weer veel tijd. Alternatief is dan een managed service gebruiken zoals Azure app Service zodat je je alleen met de applicatie hoeft bezig te houden, vaak ook goedkoper dan een echte VM.

Ander nadeel ten opzichte van Kubernetes dat je wat meer vendor lock in krijgt en dat is zeker tegenwoordig een hot topic. Hoewel je hier zeker moet afwegen hoeveel dat je waard is (hoe lang kost het je om te verplaatsen naar een andere provider en is dat acceptabel?)

[c-nan]

Als jij een applicatie ontwikkelt, lever je je containers/images aan en je klant kan het draaien, geen ingewikkelde installatiescripts, geen dependencies, het werkt gewoon, distro onafhankelijk. Upgrades doorvoeren is veel makkelijker, je publiceert een nieuwere versie van je image en de klant kan upgraden door enkel een versie nummer te wijzigen. Loadbalancing zit er soort van native in, het verkeer wordt gewoon verdeeld over je beschikbare pods. Op en afschalen is super simpel.

[Tubby]

"het werkt gewoon" zou ik wel met een korreltje zout nemen, maar in algemene zin is de docker image wel het niveau waarop je als software ontwikkelaar je product wil afleveren naar productie

[mocem]

Vertel mij wat. 90% van de software ontwikkelaars die zich Devops Engineer noemen kunnen geen normale images bouwen. Basis Linux kennis hebben ze niet of zeggen dat is niet belangrijk.

[bzzzt]

Dat heeft weinig met ontwikkelaars maar alles met aansturing te maken. Kennelijk vinden bedrijven het niet nodig om 'normale' images te bouwen omdat ze daar niet op afgerekend worden.
Net als in de Linux wereld zijn er veel uiteenlopende meningen wat onder 'normaal' verstaan zou moeten worden...

[Reactie gewijzigd door bzzzt op 14 november 2025 13:16]

[Tubby]

in algemene zin is "normaal" altijd een perspectief :)

[Stukfruit]

Waarom zou je moeten stoppen met Kubernetes omdat 1 optie wegvalt?

Zoals het artikel ook zegt zijn er genoeg alternatieven, zoals bijvoorbeeld Traefik.

[Reactie gewijzigd door Stukfruit op 14 november 2025 12:06]

[david-v]

Je leest mijn bericht verkeerd. We waren al een tijdje geleden (iets meer dan een jaar) gestopt met Kubernetes en ik weet van een ander team bij ons die dat ook van plan is. Heeft niks met dit bericht te maken.

[Stukfruit]

Nu ik het nog eens lees valt het inderdaad ook zo te interpreteren (of ik moet nog wakker worden ). Wat hebben jullie gekozen als alternatief?

Je hebt bijvoorbeeld niet voor alles hetzelfde qua tooling en dat is gelijk waarom dit nieuws niet echt een grote ramp is. Kubernetes is handig omdat het niet alleen een orchestrator is maar ook een heel systeem eromheen.

[david-v]

We zitten in de Azure cloud. Er draaien een aantal microservices in kubernetes. Maar dit is in dit geval teveel overhead (en de benodigde kennis die niet overal beschikbaar is). De microservices kan je prima als App services draaien in Azure, dat is waar we voor gekozen hebben. Of dat zo blijft weet je nooit. Misschien dat we over een paar jaar wel naar een gecentraliseerde kubernetes cluster gaan. Wat dat betreft beweegt het de hele tijd heen en weer

[Prozaq]

Zo te lezen omdat kubernetes niet de juiste tool was voor ze (iets wat ik in heel veel omgevingen zie)

[Stukfruit]

Snap ik, maar het klinkt vreemd dat een hele orchestrator in de ban wordt gedaan omdat de ingress controller vervangen moet worden

[valhalla77]

Traefik is een ander populaire ingress controller. K3s levert hem bijvoorbeeld by default.

[R.G]

Dus samengevat?

Als jouw bedrijf nu ingress gebruikt en massaal heeft draaien bij klanten?


Moet je dan nu overstappen op ingate?

Kan dat zomaar en is dat beschikbaar in de Azure cloud omgeving?

[Viper1995]

Wij draaien zowel Kong als Traefik in ons cluster en gebruiken de Azure App Gateway daarvoor, het is dan gewoon een nieuwe backend aanmaken en je listeners overzetten naar die backend. Je zou in theorie beide ook naast elkaar kunnen draaien en dingen rustig overzetten.

[R.G]

Is allemaal third party..

Je betaald een godsvermogen voor een fatsoenlijke cloud oplossing hoezo heeft Microsoft niet een standaard ingress component of feature..

Hoezo is ingress niet binnen Microsoft omarmt en onderhouden wordt door het Azure dev team.

Zo cruciaal component in je architectuur..

Ik vind echt dat het Azure platform keihard langzamerhand...

[Viper1995]

Tja net hoe je het zien vind, ik vind het wel fijn ergens dat het zo kan. Moet zeggen dat ik persoonlijk van de door MS verzonnen oplossing ook niet blij word. Het is altijd met een MS sausje er overheen.

Nu is traefik volledig in eigen beheer en kunnen we die instellen zoals we willen, maar als we om wat voor reden dan ook iets anders als backend achter de app gateway willen zetten kan dat ook.

[supersnathan94]

hoezo heeft Microsoft niet een standaard ingress component of feature

hebben ze wel. https://learn.microsoft.com/en-us/azure/aks/concepts-network-ingress

[Llopigat]

Als je bedrijf zichzelf afhankelijk maakt van het werk van 2 overwerkte vrijwilligers zonder die ook maar met een stuiver te steunen dan kan je ook niet raar opkijken als je met een probleem zit als ze er een keer de stekker uit trekken.

Er zal met deze software zo enorm veel winst worden gemaakt waar deze mensen nooit iets van te zien krijgen. Als elk bedrijf dat het gebruikt gewoon 50 euro naar ze stort (nog minder dan een tankbeurt van een van de bedrijfauto's) was het geen probleem geweest.

Maar volgens @Uninstall3d hierboven gaat ingate ook stoppen.

[Reactie gewijzigd door Llopigat op 14 november 2025 17:14]

[Zebby]

Oh die gebruiken we nog. Willen al een tijdje over naar gunicorn. Wordt maar eens tijd dan.

[freshy98]

Nul kennis hier, maar als ik lees

Vorig jaar lieten de maintainers al weten dat ze het werk, specifiek het beveiligingswerk, moeilijk meer aankonden.

dan moet je dat toch eigenlijk niet willen draaien? Of zie ik dat heel erg verkeerd in dit geval?

[R.G]

Precies!!

[MaestroMaus]

Dit nieuws baart me zorgen. Weet iemand hoe de staat van nginx onderhoud is buiten Kubernetes? Het liefst met bronnen als dat mogelijk is.