Heb je KubeCon/CloudNativeCon 2021 vorige week gemist, of had je geen tijd om alle sessies door te nemen? Niet erg! Dit zijn onze hoogtepunten en takeaways van het digitale evenement van dit jaar over alles wat met Cloud Native en Kubernetes te maken heeft.
Deze keynote was de eerste sessie die onze teamleden volgden tijdens ServiceMeshCon 2021. Hoewel het kan worden beschouwd als een verkooppraatje voor het Kuma-project , gaf het een goed beeld van de huidige uitdagingen bij het implementeren van service meshes.
Veel bedrijven - waaronder wij - hebben met succes service meshes add-ons geïnstalleerd op hun Kubernetes cluster. Nu we weten wat er mogelijk is met deze service meshes, willen we ze overal kunnen gebruiken. Denk aan meerdere clusters, on-premise en in de cloud, maar misschien ook virtuele machines. Uiteindelijk is het doel om een werklast te hebben en die ergens op onze infrastructuur in te plannen. Je hoeft niet precies te weten waar deze wordt ingepland. Patronen zoals het verspreiden van 20% belasting op VM's, 30% op on-premise Kubernetes clusters en 50% op AWS EKS clusters zijn een mogelijkheid.
Deze keynote was een goede inleiding op wat gedurende de dag dieper werd toegelicht.
Een van de krachtige functies van Kubernetes is uitbreidbaarheid: de mogelijkheid om extra functionaliteiten toe te voegen aan het cluster, waardoor het krachtiger wordt en kan worden aangepast aan je behoeften. Er zijn veel verschillende manieren om dit te bereiken. In deze sessie legde Joe verschillende uitbreidingsmogelijkheden uit.
Je kunt je eigen controllers maken, Custom Resource Definitions, je kunt Mutating en Validation WebHooks gebruiken, je kunt een API schrijven die de bestaande API uitbreidt, je kunt een specifieke CSI (Container Storage Interface), CNI (Container Network Interface), CRI (Container Runtime Interface) gebruiken. Er is ook een nieuwe manier om specifieke registers te gebruiken op basis van verschillende patronen. Als je hier meer over wilt weten, raad ik je aan de opname van deze lezing te bekijken.
Naast het toevoegen van functionaliteiten, legde Joe ook de verschuiving uit van in-tree cloud providers naar out-of-tree cloud providers. Dit betekent dat add-ons voor cloud providers zoals AWS en GCE niet langer deel zullen uitmaken van de Kubernetes core, maar een aparte plugin zullen zijn. Op deze manier is de core kleiner en makkelijker te onderhouden, omdat de cloud provider add-on minder afhankelijk is van andere code binnen de core en een eigen release cyclus heeft. Vanaf Kubernetes 1.24 (begin 2022) zullen de in-tree cloud providers niet langer beschikbaar zijn.
Het DoD heeft, net als elk ander softwarebedrijf, een infrastructuur nodig om hun applicaties op te implementeren. Net als vele anderen zijn ze de afgelopen jaren overgestapt op Kubernetes. Maar het DoD is natuurlijk geen gewoon softwarebedrijf. Het is een monolithische entiteit die verantwoordelijk is voor de hele strijdkrachten van de VS, met zijn eigen uitdagingen op het gebied van compliancy en regelgeving.
In deze presentatie vertellen Michael en Gordon hoe ze het doen en welke tools en praktijken ze gebruiken om veilige, betrouwbare en veerkrachtige software te leveren aan hun wereldwijd verspreide gebruikersbestand.
Eerst en vooral is erGit, dat de enige bron van waarheid is voor al hun infrastructuur.Flux draait bovenop deze Git die ervoor zorgt dat er geen wijzigingen worden aangebracht in de clusters zonder dat de hele uitrolpijplijn is doorlopen. Het doet dit door de commits te ondertekenen die mogen worden toegepast op de infrastructuur. Tot slot is erClusterAPI die wordt gebruikt als overzicht van alle clusters en hun beheer.
Er is ook het uitrollen van nieuwe clusters. Ook hier is git de enige bron van waarheid. Eerst zet Terraform de onderliggende netwerkcomponenten, bastion instanties en endpoints in om veilig verbinding te maken met dingen buiten het cluster. Vervolgens worden aangepaste middelen gemaakt op basis van de uitvoer van Terraform en gecommit op git. Na dit punt kom je eigenlijk terug bij Flux die ervoor zorgt dat de commits worden ondertekend en ingezet.
Deze lezing is een must voor iedereen die geïnteresseerd is in hoe je de inzet/het beheer van veilige, betrouwbare en veerkrachtige infrastructuur kunt aanpakken in een omgeving vol compliancy en regelgevingsuitdagingen. Je kuntde presentatieslides hier vinden .
Deze sessie ging overContour(Github link) een open source Kubernetes ingress controller zoalsNginx. Contour biedt een control plane voor de Envoy edge en service proxy. Het ondersteunt dynamische configuratie-updates, TLS-beëindiging, passthrough en load-balancing algoritmen.
De sessie begon met enkele nieuwe functies die het Contour-team heeft geïmplementeerd in hun laatste versie van Contour. De meest interessante nieuwe functie is Rate Limiting. Met deze Rate Limiting functie kun je bepalen hoeveel verkeer wordt toegelaten tot bepaalde services. Dit is zeker nuttig tegen sommige cyberaanvallen, zoals DDoS. Het team heeft ook Gateway API functionaliteit toegevoegd aan Contour.
Na het theoretische deel van de sessie liet Steve ons zien hoe je Global en Local rate limiting kunt gebruiken met behulp van een ConfigMap.
Dit gesprek gaf een overzicht en de recente updates vanContainerd, evenals hoe het wordt gebruikt door Kubernetes,Docker en andere container-gebaseerde systemen. In principe leer je hoe verschillende producten zoals Docker Containerd gebruiken om container services aan te bieden. Kubernetes zelf heeft directe interactie met Containerd, waar oudere K8s implementaties nogDockerd gebruikten.
Er werd ook diep ingegaan op hoe je Containerd kunt gebruiken door het uit te breiden en aan te passen aan je eigen situatie met low-level plugins zoals remote snapshotters, maar ook door je eigen Containerd client te implementeren. Een interessante uitbreiding op Containerd is een snapshotter plugin die een container in staat stelt om een lazy pull van een image te doen en al op te starten zonder te wachten tot de volledige inhoud van de image lokaal beschikbaar is.
Aankomende features en recente discussies in de Containerd gemeenschap kwamen ook aan bod. Nuttige updates in Containerd 1.5 zijn onder andere de toevoeging van het zstd compressie algoritme, wat zorgt voor een snellere compressie en decompressie, OCIcrypt decryptie standaard en nerdctl (contaiNERD ctl) als een non-core subproject. Toekomstige functies zijn onder andere bestandssysteemquota en CRI-ondersteuning voor gebruikersnaamruimten, zodat men Kubernetes-pods kan uitvoeren als een andere gebruiker dan de daemon-gebruiker.
Je kuntde dia's van de presentaties hier vinden .
GitOps Con was een van de co-located evenementen in de aanloop naar KubeCon/CloudNativeCon Europe 2021. In de openingskeynotes sprak Cornelia Davis over Git als een interface voor operaties in plaats van alleen als een opslagplaats. Git kan worden gebruikt om de gewenste staat te representeren, terwijl een K8s cluster de werkelijke staat representeert.
GitOps kan DevOps teams in staat stellen om vaker vrij te geven, de doorlooptijd te verkorten en hun applicaties effectiever te laten werken. Dit wordt bereikt door gebruik te maken van vertrouwde tooling (Git) en platformteams in staat te stellen zich te richten op beveiliging, compliance (Git log), veerkracht en kostenbeheer.
Een interessante benadering met betrekking tot beveiliging was het werken met een pull-model voor continuous delivery (CD). Door een operator in het cluster te gebruiken die implementaties bijwerkt op basis van de gewenste status in Git, is er geen centrale CD-component nodig. Dit verbetert op zijn beurt de algehele veiligheid door niet één component te hebben met toegang tot meerdere clusters.
In de cncf/podtato-head GitHub repo kun je een demoproject vinden voor het demonstreren van cloud-native applicatie delivery use cases met behulp van verschillende tools voor verschillende use cases.
Je kunt de openingskeynotes en de andere lezingen van GitOps Con vinden op het GitOps Working Group YouTube-kanaal.
Kubernetes is een coole en leuke plek om je containers te draaien. Maar is het veilig? In deze lezing lieten Ellen en Tabitha zien hoe belangrijk het is om je Kubernetes-cluster te beveiligen door RBAC, toegangscontrole en netwerkbeleid toe te voegen aan het cluster en kwetsbaarheden te updaten/patchen.
Deze lezing leek meer op een live action scene dan op het voorlezen van PowerPoint slides. In de eerste plaats lieten ze zien hoe belangrijk het is om RBAC te configureren in je cluster. Zonder RBAC of met een half geconfigureerde RBAC, is het gemakkelijk om toegang te krijgen tot iemand anders zijn werk of naamruimte. Als iemand binnen het cluster toegang heeft tot de namespaces, betekent dit ook dat iemand buiten het cluster toegang heeft tot jouw namespace. Alleen RBAC gebruiken is echter niet genoeg. Je moet ook je netwerkbeleid configureren zodat je je netwerkstroom kunt beheren door netwerkverkeer tussen pods en/of namespaces te blokkeren of toe te laten.
Een van de belangrijkste dingen om te doen is om je te abonneren op de CVE-lijst van Kubernetes. Door je in te schrijven op de CVE-lijst krijg je altijd een melding als er een nieuwe exploit is gevonden. Dit helpt je om je cluster te patchen voordat een hacker probeert binnen te dringen in je cluster.
Maar wat moet je doen als je ondanks alle inspanningen toch bent gehackt? Allereerst: wees kalm en informeer je admin hierover. Controleer samen wat er is veranderd in je cluster door audit logging of andere tools te gebruiken. Maak een sheet en schrijf alles op. Probeer vervolgens alle open kwetsbaarheden en backdoors te repareren of patchen. Doe tenslotte aangifte bij de politie.