De Nederlandse Kubernetes Podcast: gemaakt door én voor mensen met een hart voor IT. In deze reeks gaan Ronald Kers en Jan Stomphorst in gesprek over Kubernetes met als doel Kubernetes toegankelijk te maken voor iedereen.
•Ronald Kers en Jan Stomphorst•Season 4•Episode 17
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
0:00
|
28:01
Kubernetes 1.37 verscheen eind augustus onder de naam Garhwal, genoemd naar de Noord-Indiase regio waar de release lead zelf vandaan komt. Op papier een rustige release: 67 enhancements, waarvan zestien naar Stable, drieëntwintig naar Beta en zevenentwintig nieuw in Alpha. Jan constateert dat Kubernetes al een tijd steeds stabieler wordt en dat breaking changes zeldzamer worden. Goed nieuws, al maakt het de zoektocht naar een spannend verhaal voor een release-aflevering er niet makkelijker op. Deze keer valt er genoeg uit te diepen.
IPVS gaat eruit. Jan legt uit wat kube-proxy doet en waarom IPVS-mode, ooit geïntroduceerd omdat iptables te klein werd, nu zelf wordt uitgefaseerd. Het probleem is structureel: elke node draagt de IP-adressen van elke service. Bij twintig services merk je daar niks van, bij tweeduizend wel. In 1.43 verdwijnt IPVS volledig, maar het moment waarop je het gaat voelen ligt eerder. De praktische boodschap: stap over naar nftables vóór 1.40, en besef dat een upgrade dat niet voor je doet. Je moet het expliciet instellen.
iptables versus nftables. Een heldere uitleg van wat iptables eigenlijk is, namelijk firewall én routing op Linux met één lineaire regellijst die per pakket wordt doorlopen, en waarom dat in Kubernetes tegen een plafond loopt. De API ondersteunt geen incrementele updates, dus voor één regel moet de hele set opnieuw geladen worden. nftables gebruikt sets, maps en efficiëntere datastructuren, en biedt één uniform framework voor IPv4, IPv6, ARP en bridge filtering. Wel opletten: de twee zijn niet volledig compatibel met elkaar, en je hebt een recente kernel nodig.
Scale-to-zero is nu native. De HPA kan naar nul zonder dat je iets aan je bestaande configuratie hoeft te veranderen. Waar eerst één stond, kan nu nul staan. De afweging is opstarttijd bij de eerste request, maar als er niets draait betaal je ook niets. Jan wijst op het slimme detail: de HPA schaalt alleen terug omhoog als hij zelf naar nul is gegaan. Zet je de replicas handmatig op nul om iets immutables aan te passen, dan laat de autoscaler je met rust. Een herkenbare praktijkergernis, opgelost.
En KEDA dan? Ronald en Jan zetten ze naast elkaar en komen uit op complementair in plaats van concurrerend. KEDA's voordeel is dat het buiten het cluster kan kijken: een firewall of een externe dienst kan het signaal geven dat een pod moet starten. Jan schetst een bijna-serverless patroon waarin verkeer binnenkomt, KEDA de pod start, het request wordt afgehandeld en de pod daarna weer verdwijnt.
Twee harde eisen. containerd 1.x moet eruit en cgroup v1 moet eruit. Allebei niet nieuw: failCgroupV1 staat sinds 1.35 standaard op true. Jan vertelt hoe dat bij kube-spray in de praktijk uitpakte. Een mismatch tussen de cgroup-driver van de kubelet en die van de runtime levert het vervelendste type storing op. Niet kapot, maar onvoorspelbaar, met de OOM killer die processen afschiet die er niets aan kunnen doen. Bij ACC ICT wordt zoiets standaard eerst getest en worden nodes vaak simpelweg vervangen door nieuwe machines in plaats van online geüpgraded.
containerd 2.0 verandert ook je security-defaults. Containers zonder host-netwerk of user namespaces mogen nu poorten onder 1024 binden zonder CAP_NET_BIND_SERVICE, en ping draaien zonder CAP_NET_RAW. Een afspraak van decennia oud, stilzwijgend versoepeld. Terug te draaien, maar je moet het nu bewust configureren.
Verder in deze aflevering: waarom Ubuntu geen excuus meer is, hoe een onbewaakte auto-update je zomaar een major containerd-versie kan opleveren, wat managed clusters wél en niet voor je regelen, en Jans terugkerende standpunt door de hele aflevering heen: het meeste hiervan is geen probleem zodra je je machines gewoon actueel houdt.
Welkom bij een nieuwe aflevering van de Nederlandse Kubernetes Podcast. De podcast over Kubernetes voor iedereen, en powered bij ACC-ICT. Ik ben Ronal Kers en met mij is zoals altijd Jan Stomper, bij ACC-ICT. Nou wat een toeval. Jan, we zitten weer met z'n tweeën.
SPEAKER_00
Zeker voor het eerst weer in een tijdje. Sinds de laatste versie, natuurlijk.
SPEAKER_01
Ja, dus Time Flies. 1.37 Garwal, althans, Garwal. Ik weet niet hoe je het uitspreekt, maar ik denk dat ik in de goede richting zit. Komt uit een term, komt of het is een gebied in Noord-India, heb ik begrepen. Want de release lead, moet er even zijn naam erbij pakken. Die peze Rawat, komt hier zelf vandaan? U dit gebied.
SPEAKER_00
Een mooi stukje eigen waarde in de release.
SPEAKER_01
Ja, dat is sowieso wel kenmerkend voor de releases. Iedereen geeft zijn eigen persoonlijke tintje eraan. Dat is eigenlijk wel hartstikke mooi. Maar ja, in cijfers 67 enhancements. 16 naar stable, 23 naar beta en 27 nieuwe alfa. En er is één deprecation.
SPEAKER_00
Zeker.
SPEAKER_01
Ze blijven bezig. En over die deprecation gaan we het zo uitgebreid hebben. Maar eerst Jan, 1.37. Moet men daar wakker van liggen?
SPEAKER_00
Nou, aan de ene kant wel, aan andere kant niet. It depends. Ons grapje natuurlijk altijd. Ja, als je niet up-to-date bent met je machines, ja, dan heb je wat te doen. En nee, je merkt wel dat Kubernetes steeds stabieler wordt. De breking changes zijn steeds minder. We hebben het al vaker gezegd. Ze zijn gewoon bezig met een heel goed product aan het neerzetten. Een heel stabiel product. Dus voor ons is het natuurlijk wel af en toe denk je, waar zijn de scoops nou? Waar kunnen wij nou het mooiste verhaal vertellen aan jullie? Maar er valt dit keer wel echt wel wat te vertellen en wat uit te diepen. We gaan niet alle releases langs. Want ik heb zoiets van ja, dat kan je zelf ook lezen. De opvallende, voor ons in ieder geval. De interessante.
SPEAKER_01
IPvS. Heel lastige, IPvS, niet V6, maar VS. Simon, heeft met Qproxy te maken. Kan je vertellen, een beetje QProxy, wat het is, wat het doet en wat gaat eruit.
SPEAKER_00
Nou, IPvS is een manier om te zorgen dat het verkeer bij een service uitkomt. Dus dat betekent dat het IP-adressen bevat en het zorgt ervoor dat het verkeer bij de juiste plek komt. Dat is een hartstikke mooi. Dat is een proxy. Het is precies van Qproxy. Ja, dat is een hartstikke mooi iets. En we zijn blij dat het zegt. Het kan beter natuurlijk. In 1.43 wordt het helemaal verwijderd van het Kubernetes cluster. Er is wel rekening mee te houden om deze te veranderen. Dan is de volgende vraag natuurlijk: wat gaat er veranderen?
SPEAKER_01
En waar moet je op letten?
SPEAKER_00
En kan het de komende versie veranderen. En waarom natuurlijk ook, hè? IPVS is een hele mooie service die super zwaar is.
SPEAKER_01
Oké, vertel.
SPEAKER_00
Dat betekent dus dat hij een stuk zwaarder. IPvS gebruikt knel hasterbellen. En dat betekent dus dat hij gebruikt knel has te bellen voor service look-ups. Dat betekent dus dat elke machine heeft alle IP-adressen van elke service op zijn machine staan.
SPEAKER_01
Oké, op de node.
SPEAKER_00
Ja, elke node van elke service dan alle IP-adressen erop. Ik denk, nou ja, als je 20 services hebt, 40 services, is dat niet zo heel veel. Maar zodra het cluster groter wordt, en je krijgt meer nodes en je krijgt meer services. Dan heb je 1000, 2000 services. Dus dan heb je 2000 IP-adressen op elke machine staan. Dat is nogal veel.
SPEAKER_01
Ik denk dat dat nog als performance probleem komt.
SPEAKER_00
Nou ja, dat is wel interessant. Kijk, IPvS zijn we naartoe gestapt omdat IP tables eigenlijk te klein was. IP tables is hartstikke mooi iets. Maar IP tables was te klein en we zochten iets groters. Dus toen zijn we naar overgestapt naar IPv6. IPVS heeft super wijze dingen. Die kan niet alleen round robin, maar die kan veel meer trucjes. Alleen dat gaan we weer verliezen. Ik denk niet dat iemand dat echt wist en gebruikte. Maar we gaan naar NF tables.
SPEAKER_01
Oké, maar voordat we over alles heen stappen, dus we hebben nu IP tables, IPVS, NFT tables. Of NF tables. Niet NFT tables, dan zie je het altijd. Al die terminologieën hebben blijven de gang. Kan je me even meenemen, want IP tables en F-tables. Waarom zijn er twee?
SPEAKER_00
Nou, je moet bedenken, IP tables is van origine degene die het netwerkverkeer doet.
SPEAKER_01
Ja, oké.
SPEAKER_00
Binnen Kubernetes binnen Linux. Dus dat betekent dus dat IP tables een pakketje binnenkomen, die gaat hij beoordelen op basis van zijn lijstje, dus een echte tekstvuil. En dan stuurt hij door naar de plek waar het heen moet.
SPEAKER_01
Denk een beetje als een firewall met routing.
SPEAKER_00
Of er is een natuur iets. En dat zou kunnen. In IP tables kan je D-nat of source nat, kan je natten. Het is een firewall. Dus je kan zeggen van nou, poort is een open, poort is en dicht. Of het verkeer moet daarheen, zonder te nat of. Met IP tables kan je gewoon een complete router maken. Firewall router. Fantastisch iets. Dus dat is de beveiliging voor jouw netwerk. Of voor je netwerk op Linux. Dus betekent ook dat Kubernetes dat gebruikt. Het enige probleem is, wij krijgen in IP tables krijgen we gigantische lijsten van services. Want alles stond in IP tabels. Dus als jij 20 services of 100 services hebt, is dat niet zijn heel probleem. Maar als dat er heel veel zijn, dan wordt die tekstvuil heel groot.
SPEAKER_01
Ik kan me voorstellen bij een Kubernetes oplossing dat het redelijk hard kan gaan op de regen.
SPEAKER_00
En wat ook wel interessant was, de IPTabels, API, deed alles in één keer. Dus dat betekent, je kon geen één regel toevoegen.
SPEAKER_01
Dus je kon niet incrementeel regels toevoegen.
SPEAKER_00
Nee, en dat is niet handig. Als je zegt van ik heb een gigantische vuil. En ik wil een regeltje toevoegen. Dus het hele geval je opnieuw laden. Dat is dus niet erg als het wat kleiner is, dan is het helemaal geen probleem. Maar als het wat groter wordt, en waar Kubernaes clusters tegenwoordig helemaal naartoe gaan, is size, size matters. Dus de op te volgeren van IP tables is NF tables. En de meesten zullen dat wel gebruiken. En die gebruikt sets, maps en efficiëntere datastructuren om de Q proxy. Look op veel makkelijker en sneller te doen. Daarnaast biedt een uniform framework voor IPv6, IPv4 Arprids filteringen en alles wordt uniformer. Da worden we blij van.
SPEAKER_01
IP tables is vaak nog wel de default. Denk ik, of niet? Of er zit wel eens wat enfijder.
SPEAKER_00
In Ubuntu's gaan we nu veel meer naar NF tables. Eigenlijk de nieuwe versies van Ubuntu hebben NF tables. Dus dat is helemaal geen probleem. Het is alleen IP tables en NFTs zijn niet 100% compatible met elkaar. Een voorbeeld van die incompatibiliteit is Nodepoort. Dat is het servicetype dat op elke node een poort openzet. Zodat je vanaf de buitenkant via Node IP plus poortnummer erin kan. In IP tables mode is die poort bereikbaar op alle IP's van de node, inclusief 127.001. In NFTs is die alleen op de standaard IP-adresse van de node beschikbaar. En dat merk je bas in productie. Dus test de NFTs migratie expliciet op je nodenportgedrag. En kijk ook even naar de CNI-plugin en je netwerkimplementatie. Die leunen soms op het ongedocumenteerde IP-tables gedrag. Je moet heel erg goed passen. Wat gebruik ik nou? Wat ga ik nou doen?
SPEAKER_01
En op een oude kernel weet het waarschijnlijk niet. Of een oudere kernel. Ja, 5.13 of zo.
SPEAKER_00
13 moet je hebben minimaal. Maar ik ga ervan uit dat de meeste mensen wel een nieuwere kernel hebben dan 513.
SPEAKER_01
We horen wel eens spannende verhalen.
SPEAKER_00
Ja, maar dan moet je ook. Je moet blijven updaten. Dus dat is gewoon wel een belangrijk iets.
SPEAKER_01
Maar je moet het wel expliciet vermelden dat je NF tables gaat gebruiken. De update doet het niet voor je automatisch.
SPEAKER_00
Nou, kijk, dat is stap 2 waar je heel erg goed moet op gaan letten. In je Kubernetes deployment, is dat jij zegt dat jij niet meer IPVS gebruikt. Want IPVS gaat er dus in 1.43 gaat ik dat nou goed? Of 1.46 gaat hij er helemaal uit.
SPEAKER_01
Ja, 9 releases verder.
SPEAKER_00
Ja, en vanaf 1.40 gaat de Vigigate Default of Volks. Dus dan ga je het echt merken merken. Maar je moet dus praktisch gezien de IPVS moet je uitzetten en dat moet je veranderen naar NFTs. Dus dat moet je dus voor 140 doen.
SPEAKER_01
Anders zit je zo meteen met de gebakke peren.
SPEAKER_00
Nou ja, kijk, je kan het beter nu doen en testen en gaan doen dan je straks een probleem hebt.
SPEAKER_01
Oké. En nou ja, een andere feature is Skill to Zero. Die we nieuw is. Althans, de term is niet nieuw, maar hoe Kubernetes ermee omgaat.
SPEAKER_00
Die term deden we al langer, hè, Skill to Zero. Die kennen we nog bij onze grote vrienden. Ja, zeker. Je moet zo'n podcast van luisteren, hè, waar je eentje over gemaakt. Klopt. Horizontal pot autoscaler. Die kan nu naar 0. En horizontal pot outscaler, die schaalt natuurlijk op.
SPEAKER_01
Dat weet jij automatisch.
SPEAKER_00
Ja. Autoscaler.
SPEAKER_01
Maar op een Rece, op CPU en memory.
SPEAKER_00
CPU, ja. Dus je geeft CPU aan en dan kan hij gaan schalen. Maar hij kan dus nu ook wat naar 0, wat wel heel tof is. Overigens, je hoeft niks te veranderen aan de huidige horizontal pot uitskaler. Want de werking verandert niet. Je kan alleen in plaats van die 1 kan je ook een 0 maken.
SPEAKER_01
Ja, precies. Ik denk alleen dat het enige nadeel tussen aanhalendekens is: je hebt geen instans draai. Dus dan moet wel die instans weer opstarten. Dus je hebt daar een kleine vertraging.
SPEAKER_00
Ja, dus dat is natuurlijk logisch. Want je applicatie moet opstarten. En dan als er niks is, dan moet hij meer starten. Voordat hij direct een request kan geven.
SPEAKER_01
Ja, precies. Maar goed, als je niks hebt, betaal je ook niks. Dus dat is een afweging die je daar maakt natuurlijk. Het lijkt natuurlijk simpel. Maar goed, hangt van je applicatie af.
SPEAKER_00
Ja, maar het hangt zeker vanaf een workload. Als jij zegt van je workload kan gewoon down. En gebruiker vindt het niet zo heel erg dat hij twee seconden of moet wachten of ik ben hier snel dat op start, dan is het natuurlijk nooit een probleem.
SPEAKER_01
Nee, maar dat is niet het enige wat ze hebben veranderd. Er is nog een andere interessante wijziging hier.
SPEAKER_00
En dat schuurt echt wel tegen KEDA aan. Je kan nu multipod Custom Metrics kan je toevoegen. Oftewel, je kan ook kijken naar de HTTPS per seconde. Kijk, dus niet alleen CPU. Nee, zeker niet. CPU of memory. Ik kan hier naar kijken of naar een custom metric. Ik heb het nog niet getest, ik weet nog niet precies hoe. Ik denk dat daar moet wel een stukje software tussen zitten.
SPEAKER_01
Ja, het is interessant om die twee naast elkaar te zetten zometeen, denk ik. Maar ik denk dat ze elkaar meer complimentair aan elkaar zijn dan dat ze.
SPEAKER_00
CERDA heeft als voordeel dat ze ook nog eiten het cluster kunnen kijken. Dus het voordat met CERDA kan je eigenlijk overal naar kijken. Dan zou je zelfs kunnen zeggen van nou, mijn loopbellancer of mijn dienst voor Kubernetes, wat niet in Kubernetes zit, die kan hier een notificatie geven dat mijn pot moet starten. Dus wat wel tof is, je had het net over die pot naar nul geschouwd is. Wat nou als het verkeer op de firewall binnenkomt. Kenner krijgt een berichtje, start ondertussen de pot. En zodra het verkeer aankomt en de pot start heel snel, is die pot gestart, kan die request. Kan die ser vieren en daarna schiet je de pot eraf. En dan heb je eigenlijk survelus.
SPEAKER_01
Nou, interessant. Zeker interessant. Ja, weet je ook wel een leuke toevoeging is, is dat je als hij. Hij kan alleen maar starten, als hij hem zelf gestopt heeft.
SPEAKER_00
Ja, je refereert natuurlijk het feit. Stel hè, ik wil mijn dienst gewoon even downbrengen en ik als gebruiker zet hem even naar 0. Dat doe ik heel vaak. Dan denk ik, ja, weet je, ik moet iets weggooien. Of er zit een object onder wat ik moet verwijderen of aanpassen wat immutable is als de dienst nog draait, of als je deployment nog draait. Dan schaal ik hem heel vaak naar 0. Kan ik dat aanpassen. En dan kan die containers weer starten.
SPEAKER_01
Ja, en je wil dan niet dat die HPA dan weer automatisch aan staan.
SPEAKER_00
Oeh, dit is verkeerd. Ik wou mis starten voor je. Dat is hartstikke lief, maar dat hoeft niet.
SPEAKER_01
Dat hoeft niet. Dus zo intelligent hebben ze het dan alweer gemaakt. Dat ze dus daar dus al let op zijn.
SPEAKER_00
Ik denk dat ze er zelf ook tegenaan gelopen zijn. Waarschijnlijk wel. Wij zijn aan het testen. Zet het naar 0. Het gaat niet naar 0. Hij gaat wel naar 0, maar nu stak je meer. Oh, dat is lekker handig.
SPEAKER_01
Ja, precies. Ik denk dat dat een hele mooie stap voorwaarts is weer dit in de.
SPEAKER_00
Ja, het is wel tof. En dan zie je toch dat Kenna toch wel een gat gevuld had. Een heel groot gat. En we konden erop wachten natuurlijk dat ze iets nativ in zouden bouwen voor zoiets.
SPEAKER_01
Zeker. Zeker. Dan zijn er ook nog twee harde eisen die er aan gaan zitten komen waar mensen echt rekening mee moeten houden. Zeker. Nou, welke twee dingen zijn dat, Jan?
SPEAKER_00
Dat is een container D1 en Croep S1. Oké. Neem ons eens even mee. Nou, kijk, als je terug gaat naar de basis. Wij draaien om containers te starten, draaien wij een container manager. Een containerruntuin noemen we dat. Dat was voor één dokker. Het docker is eruit. En dat is het container D. Ja, een container D. Nou, dan zaten er in container D versie 1. We gaan nu over naar container D versie 2.
SPEAKER_01
Kijk, oké.
SPEAKER_00
Die slimmer, beter en sneller. Oké, denk ik.
SPEAKER_01
Ja, nou ja, dat is wel. Maar ja, wat is het support was al gestopt, toch? Bij 1.36.
SPEAKER_00
Ja. Het is nu echt een 1.37 ijs. Wat wel interessant was, is dat ook Ubuntu dat heel lang nog geen container die meegeshipt had. Container die 2. Dus dat hebben ze overigens wel aangepast. Ik zat een beetje research te doen op het internet. Ik zag op een gegeven moment. Container die is niet. Daar moet je er apart van doen. Nee, maar als je nu de laatste versie hebt, als het goed is, moet je zelf even ook controleren dat je container die 2 hebt.
SPEAKER_01
Juist, anders gaat het stuk straks.
SPEAKER_00
Nou ja, kijk, daar ga je ook leeuwen. En dan staat gewoon die noden niet op. Want hij verwacht een nieuwe versie van container D. En dan als het goed is, zijn onze luisteraars heel slim en patchen ze alles altijd.
SPEAKER_01
Nou, maar hetzelfde geldt natuurlijk ook voor die C-croep persins 1.35 staat je die al standaard op true. Zeg maar die veel C-groep.
SPEAKER_00
Maar ik weet toevallig dat in Cube Spray daar wel problemen mee waren. M35 ook. Je moet bedenken, wij draaien nooit de laatste versie bij onze klanten allemaal. Het is niet zo dat we morgen overal 1.37 gaan installeren. Nee, nee. Dus we gaan eerst alles testen altijd. Dus uitvoerig testen en kijken wat gaat er mis. Hoe gaan we begrepen? Wat is het upgradepaden alle applicaties die wij beheren doen het nog. Dus daar zit altijd wel even tijd in om dat helemaal goed te hebben voor alle clusters die wij beheren, het zijn er een hele berg. Maar bij 1.35 moesten we het toch wel even al oppassen. Want stond staan dat ook troes.
SPEAKER_01
Ja, precies. En wat je zegt, sinds 1.35 wordt Zegroep drivers automatisch en loopt het via de runtimeconfig, zie ik als goed is. En container die 2.0 ondersteunt dat 1.x niet gaat hij dood. Want de omkiller houdt ook nog de boel in de gaten. Dus ja, want je zit met verkeerde drijvers, out of memory. Dat soort geneuzel.
SPEAKER_00
Ja, en je kan hele rare dingen krijgen als je dat niet lekker update. Dus nogmaals, je moet gewoon je ontmoeten of wat vooral, als je draait, gewoon zorgen dat het alles op de laatste versies is. Want dan gaat het niet stuk.
SPEAKER_01
Nee, maar het klinkt wel als een enorm project. Dit is het echt zo ingewikkeld, het upgraden hiervan?
SPEAKER_00
Ja, ze zijn niet compatible met elkaar. Dus kijk, en wat wij veel doen tegenwoordig is gewoon nieuwe nieuwe machines neerzetten. Dus we vervangen ene machine door een hele nieuwe machine. En dan heb je geen probleem. Maar als jij online wil updaten of zo, dat gaat niet.
SPEAKER_01
Nee, of je hebt met hardcode C-groep V1-paden te maken, weet je, al in legacy applicaties. Dus dat is ook nog een dingetje. Weet je wel, scripts. Er zijn altijd wel scripts die iemand ooit gemaakt heeft waar al niet meer naar gekeken is. Dus even een reminder hierbij voor iedereen van check het even van tevoren.
SPEAKER_00
Zeker. Zeker. Het is gewoon een interessante uitdaging. Je kan wel van één naar de laatste versie toe.
SPEAKER_01
En wat ook nog goed is om te weten, container die 2.0 doet ook nog iets met de poorten.
SPEAKER_00
Wat doet hij met de poorten?
SPEAKER_01
Dat zal jij mij toch vertellen, denk ik.
SPEAKER_00
Nou, dat weet ik niet.
SPEAKER_01
Nou, dan moet ik mijn aantekening erbij pakken. Even kijken. De CRI plugin staat sinds container die standaard toe, dat containers zonder hostnetwerk of user namespaces porten onder 1024 binden. Zonder de Capnet Bind Service. En ze mogen ping draaien zonder de Capnet Raw. Zeg jou dat wat? Mijn niet direct, want ik zit er niet met mijn handjes aan aan die dingen. Poorten, zeg maar, waren altijd privileged.
SPEAKER_00
Ja. En je geeft dan je machines aan dat je niet zomaar daarheen mag pingen naar de poorten onder de 1024. Dat gaf, ja, maar eigenlijk draai je de meeste containers gewoon op poort 80 of 4. Meestal poort 80. Want als je gewoon een webservice hebt of 8080. En dat zijn allemaal beveiligde poorten. Dat is een afspraak die we ooit eemaakt hebben, alles onder de 1024 dat hebben we gealokeerd. En dat vinden wij daar weten we van welke poort wel gebruikt.
SPEAKER_01
Gaande jaren zijn de dingen wel wat soepeler geworden en dat de dingen toch open komen te staan en dat toch.
SPEAKER_00
Je moet er gewoon weer tingels van aflaten.
SPEAKER_01
Nee, dat betekent dus dat je gewoon je hebt. Je staat hier Enable unprivileged poorts en Enable unprivileged ICMP in de CRI-configuratie. Dat kan je aanzetten of uitzetten.
SPEAKER_00
Ja, dat is op containerniveau. Maar ja, nee. Dus dat is hartstikke goed.
SPEAKER_01
Dat moet je dus nu expliciet configureren.
SPEAKER_00
Overigens, 2.3 waar we nu op zit, is LTS tot 2028. Dus dan heb je weer tweejarig spijt. Weet je, dat zeg ik. Ik blijf herhalen als jij gewoon je machines blijft updaten. Na de laatste versie bent, elke keer. En sowieso met de Kubernetes upgrade, maar ook tussendoor. Want er zijn Nogal wat CVE's langsgekomen de laatste tijd weer. Dan heb je niks aan de hand. Dan ben je gewoon op de laatste versie en dan heb je gewoon ook container 2.3.
SPEAKER_01
Nou ja goed, dus dat is ook de vraag. Stel nou, je hebt deze aflevering geluisterd en je denkt van goh, hier wil ik toch wel eens even naar kijken. Wat moet ik nou als eerste doen? Jou een berichtje sturen op LinkedIn of bellen?
SPEAKER_00
Draa de control deprecations list op een bestaande container D1 nodes. Dat laat op basis van je daadwerkelijk gebruik zien. Welke wijzigingen jou raken, maar dus geen algemene lijst met break and changes, maar wat in jouw omgeving echt actief is. En er is een backboard naar container 1.6 en 1.7. Dus dit kun je gewoon draaien voordat je gaat upgraden.
SPEAKER_01
Canonical heeft zelf ook al gezegd dat het destructief kan zijn als je dit zeg maar niet bij je gaat houden.
SPEAKER_00
De laatste versies, daar zit het gewoon in. Als je nog Ubuntu 22.4 draait.
SPEAKER_01
Ook daar is het wel slim. Maar stel dat jij een soort van. Ik denk niet dat heel veel BS doet, maar als jij dus een soort van auto-update aan hebt staan op je server, op je Ubuntu, of dat mensen dat niet doen, maar het kan. Windows update selecteren doe je ook vaak soms zonder na te regen. Wat wordt er nou echt geüpdate? Maar als dan in één keer die container die versie in één keer omhoog gaat, dan zit je er misschien wat in.
SPEAKER_00
Ja, maar je doet niet zomaar een release-update. Nee, hij is best goed bewust van het is. Hij gaat mee met de release update. Dus hij zit in 2604, maar in 24.04 of 22.04 zitten die niet. Omdat je een hele berg andere libraries ook nodig hebt.
SPEAKER_01
Ja, oké. Maar goed. Het is altijd wel even een goede reminder van. Houden we het gewoon in de gaten?
SPEAKER_00
Voor ons is het. Ik blijf het herhalen. Voor ons is het gewoon geen issue, want je moet gewoon updaten naar de laatste versie.
SPEAKER_01
Ja, daar ben ik het helemaal mee eens.
SPEAKER_00
We praten hier ook over een 1.37 kabinet dus. Maar die moet je gewoon op de meest recente versie van de boete draaien. Of in ieder geval nog een gespoorde versie.
SPEAKER_01
Ja, precies. Maar ja, veel luisters die draaien natuurlijk ook op een EKS, GKE, AKS. Wordt het daar niet automatisch allemaal voor je geregeld?
SPEAKER_00
Ja, dan wordt het automatisch voor je geregeld. Want sowieso hebben ze daar eigen versies van OS'en. En daar zullen ze al voor allang. Op 1.35 zullen ze dat al gefixt hebben.
SPEAKER_01
Ja, precies. Maar goed, het wordt automatisch voor je geregeld, maar uitstellen kan ook niet. Je gaat gewoon automatisch mee met de rest.
SPEAKER_00
Nee, waar je dus wel aan moet denken, is die NF tables. Die we net hadden besproken, van de services.
SPEAKER_01
Nou ja, precies. Of dat je een aanname hebt op container. Je moet wel eventjes nalopen vanaf waar je op draait. Want anders ga je alsnog natuurlijk.
SPEAKER_00
Ja, gelukkig hebben we nieuwe versies. Je moet altijd altijd opletten waar je mee bezig bent. En als je ook in de cloud gewoon een update doet, moet je daar ook rekening in houden.
SPEAKER_01
Ja, precies. Maar als je nou echt één aan moet gaan wijzen dat je denkt van goh, dat is echt de eerste die je even moet aanpakken, welke zou je dan doen?
SPEAKER_00
Welke bedoel je?
SPEAKER_01
Nou, die IPVS dingen controleren of die versies, gewoon allemaal in één keer plannen en gewoon even doorpakken.
SPEAKER_00
Ja, gewoon even doorpakken. Want als je het ene vergeet, dan er is niet één één ding die je maar kan oppakken.
SPEAKER_01
Ja, nee precies. Maar goed, check even welke Q proxy mode je en welke containerversie je draait. Containerdiversie je draait.
SPEAKER_00
Ik denk dat die proxy mode misschien ook wel aangepakt worden door de cloud. Ik moet zeggen, ik heb het nog niet gecontroleerd. Het is wel een goed dingetje. Ik schrijf hem op. Q proxymode.
SPEAKER_01
En nou ja, op zich niet zo'n hele spannende release. Althans, je kan hem zo spannend maken als je zelf wil. Proberen wel de urgentie hier duidelijk te maken. Maar toch wel even dingen weer onder de aandacht gebracht, dat mensen er in ieder geval weer even over na moeten denken. En natuurlijk, als ze daar hier nog vragen over hebben, dan weten ze jou ongetwijfeld wel te vinden.
SPEAKER_00
Ja, ze mogen wel vast lastig vallen via de mail.
SPEAKER_01
Luisteraars, listeners, did you hear it? Nee, iedereen gehoord? Spammen Jan.
SPEAKER_00
Nee, we hebben een mailres natuurlijk, die staat op onze website. Jan aperstaje.kachts-podcast.nl.
SPEAKER_01
Ja, precies.
SPEAKER_00
En voor de rest, ja, LinkedIn staat altijd open. Dat kunnen jullie dan een berichtje sturen. En we willen sowieso wel weten van jullie of er nog dingen zijn die wij kunnen verbeteren. Of dat je denkt. Nou, ik wil graag met je praten. Ik heb een fantastisch verhaal.
SPEAKER_01
Wel.
SPEAKER_00
Of je kunt jullie het over dit onderwerp hebben, want ik weet nog niks over dit onderwerp. Of ja, ik staan helemaal open om interessante verhalen of onderwerpen. Of misschien moeten we wel echt een onderwerp uitdiepen.
SPEAKER_01
Mail mij, mail Jan. Op LinkedIn zijn we ook te vinden. En we staan natuurlijk ook nog op de Dutch Cloud Native Day. Daar zijn we ook live in. Dus trek ons vooral aan onze jas daar. En dan bedankt voor deze opname weer, met je twee. Was gezellig tot de volgende release.
