
.jpg?auto=compress,webp&upscale=true&width=610&height=488&name=shutterstock_2446979289%20(1).jpg)
Ik begon deze blogpost te schrijven de dag nadat ik thuiskwam van KubeCon en CloudNativeCon 2022. Het belangrijkste wat me opviel was dat de inhoud van de gesprekken de afgelopen jaren is veranderd.
De nieuwe uitdagingen van Kubernetes
Als je kijkt naar de onderwerpen van KubeCon / CloudNativeCon van dit jaar, voelt het alsof veel vragen over Kubernetes, soorten cloud, logging tools en meer worden beantwoord voor de meeste bedrijven. Dat is logisch, want steeds meer organisaties hebben Kubernetes al met succes geïmplementeerd. Kubernetes wordt niet langer beschouwd als het volgende grote ding, maar eerder als de logische keuze. We hebben echter gemerkt (tijdens de gesprekken, maar ook in ons eigen traject) dat er nieuwe problemen en uitdagingen zijn ontstaan, die tot andere vragen leiden:
- Hoe kan ik meer automatisering implementeren?
- Hoe kan ik de kosten voor deze opstellingen beheersen/verlagen?
- Is er een manier om het bestaande uit te breiden en mijn eigen functionaliteiten aan Kubernetes toe te voegen?
Een van de mogelijke manieren om functionaliteiten aan Kubernetes toe te voegen is het gebruik van Operators. In deze blogpost zal ik kort uitleggen hoe Operators werken.
Hoe Operators werken
Het concept van een operator is vrij eenvoudig. Ik denk dat de makkelijkste manier om het uit te leggen is door daadwerkelijk een operator te installeren.

Binnen ACA gebruiken we de istio operator. De exacte stappen van het installeren hangen af van de operator die je installeert, maar meestal lijken ze erg op elkaar.
Installeer eerst de istioctl binary op de machine die toegang heeft tot de Kubernetes api. De volgende stap is het uitvoeren van het commando om de operator te installeren.
curl -sL https://istio.io/downloadIstioctl | sh -
export PATH=$PATH:$HOME/.istioctl/bin
istioctl operator init
Dit zal de operator resource(s) aanmaken in de istio-system namespace. Je zou een pod moeten zien draaien.
kubectl get pods -n istio-operator
NAMESPACE NAME READY STATUS RESTARTS AGE
istio-operator istio-operator-564d46ffb7-nrw2t 1/1 Running 0 20s
kubectl get crd
NAME CREATED AT
istiooperators.install.istio.io 2022-05-21T19:19:43Z
Zoals je kunt zien, is er een nieuwe CustomResourceDefinition genaamd istiooperators.install.istio.io gemaakt. Dit is een blauwdruk die specificeert hoe resource definities moeten worden toegevoegd aan het cluster. Om config aan te maken, moeten we weten welk 'soort' config de CRD verwacht aangemaakt te worden.
kubectl get crd istiooperators.install.istio.io -oyaml
…
status:
acceptedNames:
kind: IstioOperator
…
Laten we een eenvoudig configuratiebestand maken.
kubectl apply -f - <<EOF
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
namespace: istio-system
name: istio-controlplane
spec:
profile: minimal
EOF
Zodra de ResourceDefinition die de configuratie bevat is toegevoegd aan het cluster, zal de operator ervoor zorgen dat de resources in het cluster overeenkomen met wat is gedefinieerd in de configuratie. Je zult zien dat er nieuwe resources worden aangemaakt.
kubectl get pods -A istio-system istiod-7dc88f87f4-rsc42 0/1 Pending 0 2m27s
Omdat ik een klein soort cluster draai, kan de istiod pod niet worden ingepland en staat deze vast in de status Pending. Laat me eerst het proces uitleggen voordat ik dit verander.
De istio-operator blijft het IstioOperator configuratiebestand in de gaten houden voor wijzigingen. Als er wijzigingen worden aangebracht in het bestand, zal het alleen de wijzigingen aanbrengen die nodig zijn om de bronnen in het cluster bij te werken zodat ze overeenkomen met de status die is gespecificeerd in het configuratiebestand. Dit gedrag wordt reconciliatie genoemd.
Laten we eens kijken naar de status van het configuratiebestand IstioOperator. Merk op dat het is aangemaakt in de istio-system naamruimte.
kubectl get istiooperator -n istio-system
NAME REVISION STATUS AGE
istio-controlplane RECONCILING 3m
Zoals je kunt zien, is dit nog steeds aan het afstemmen, omdat de pod niet kan starten. Na enige tijd zal deze in een ERROR status gaan.
kubectl get istiooperator -n istio-system NAME REVISION STATUS AGE istio-controlplane ERROR 6m58s
Je kunt ook de istio-operator log bekijken voor nuttige informatie.
kubectl -n istio-operator logs istio-operator-564d46ffb7-nrw2t --tail 20
- Verwerken van bronnen voor Istiod.
- Verwerking van middelen voor Istiod. Wachten op implementatie/istio-systeem/istiod
✘ Istiod kwam een fout tegen: wacht niet op bron: bronnen niet klaar na 5m0s: timed out wachten op de voorwaarde.
Aangezien ik een klein demo-cluster draai, zal ik de geheugenlimiet aanpassen zodat de POD ingepland kan worden. Dit wordt gedaan in het spec: deel van de IstioOperator-definitie.
kubectl -n istio-system edit istiooperator istio-controlplane
spec:
profiel: minimaal
componenten:
piloot:
k8s:
middelen:
aanvragen:
geheugen: 128Mi
De istiooperator gaat terug naar een RECONCILING status.
kubectl get istiooperator -n istio-system
NAME REVISION STATUS AGE
istio-controlplane RECONCILING 11m
En na enige tijd wordt het HEALTHY.
kubectl get istiooperator -n istio-system
NAME REVISION STATUS AGE
istio-controlplane HEALTHY 12m
Je kunt zien dat de istiod pod draait.
NAMESPACE NAME READY STATUS
istio-system istiod-7dc88f87f4-n86z9
Afgezien van de istiod implementatie, zijn er ook veel nieuwe CRDs toegevoegd.
authorizationpolicies.security.istio.io 2022-05-21T20:08:05Z
destinationrules.networking.istio.io 2022-05-21T20:08:05Z
envoyfilters.networking.istio.io 2022-05-21T20:08:05Z
gateways.networking.istio.io 2022-05-21T20:08:05Z
istiooperators.install.istio.io 2022-05-21T20:07:01Z
peerauthentications.security.istio.io 2022-05-21T20:08:05Z
proxyconfigs.networking.istio.io 2022-05-21T20:08:05Z
requestauthentications.security.istio.io 2022-05-21T20:08:05Z
serviceentries.networking.istio.io 2022-05-21T20:08:05Z
sidecars.networking.istio.io 2022-05-21T20:08:05Z
telemetries.telemetry.istio.io 2022-05-21T20:08:05Z
virtualservices.networking.istio.io 2022-05-21T20:08:05Z
wasmplugins.extensions.istio.io 2022-05-21T20:08:06Z
workloadentries.networking.istio.io 2022-05-21T20:08:06Z
workloadgroups.networking.istio.io 2022-05-21T20:08:06Z
Hoe de operator werkt - samenvatting
Zoals je kunt zien, is dit een zeer eenvoudige manier om istio snel in te stellen binnen ons cluster. In het kort zijn dit de stappen:
- Installeer de operator
- Een (of meer) CustomResourceDefinitions wordt toegevoegd die een blauwdruk geeft voor de objecten die kunnen worden gemaakt/beheerd. Er wordt een deployment aangemaakt, die op zijn beurt een Pod aanmaakt die de Configuraties bewaakt van de soorten die zijn gespecificeerd door de CRD.
- De gebruiker voegt een configuratie toe aan het cluster, waarvan het type is gespecificeerd door de CRD.
- De operator POD merkt de nieuwe configuratie op en neemt alle stappen die nodig zijn om ervoor te zorgen dat het cluster zich in de gewenste staat bevindt die door de configuratie is gespecificeerd.

Voordelen van de operatoraanpak
De operator-benadering maakt het eenvoudig om een verzameling resources zoals Deployments, Jobs, CustomResourceDefinitions te verpakken. Op deze manier is het eenvoudig om extra gedrag en mogelijkheden aan Kubernetes toe te voegen.
Er is een bibliotheek met een overzicht van de beschikbare operators die te vinden zijn op https://operatorhub.io/. Op het moment van schrijven zijn er 255 operators. De operators worden meestal geïnstalleerd met slechts een paar commando's of regels code.

Het is ook mogelijk om je eigen operatoren te maken. Het kan zinvol zijn om een set van deployments, jobs, CRD's, ... die een specifieke functionaliteit bieden te verpakken als een operator. De operator kan worden afgehandeld als operators en pipelines gebruiken voor CVE-validaties, E2E-tests, uitrol naar testomgevingen en meer voordat een nieuwe versie naar productie wordt gepromoot.
Valkuilen
We gebruiken Kubernetes al lange tijd binnen de ACA Group en hebben in deze periode een aantal best-practices op het gebied van beveiliging verzameld. We hebben gemerkt dat one-bestand-deployments en helikopters van het internet meestal niet zo goed geconfigureerd zijn als we zouden willen. Denk aan RBAC regels die te veel rechten geven, resources die op dit moment geen namespaced hebben of containers die als root draaien.
Wanneer je operators van operatorhub.io gebruikt, vertrouw je er in principe op dat de leverancier of provider de best practices op het gebied van beveiliging volgt. Echter ... één van de gesprekken op KubeCon 2022 die de grootste indruk op me maakte, stelde dat veel van de operators problemen hebben met de beveiliging. Ik raad je aan om Tweezering Kubernetes Resources te bekijken : Operating on Operators - Kevin Ward, ControlPlane te bekijken voordat je gaat installeren.

Wat we ook hebben gemerkt is dat het gebruik van operators het proces om nieuwe tools en functies te implementeren kan versnellen. Zorg ervoor dat je de documentatie leest die is geleverd door de maker van een operator voordat je in de geavanceerde configuratie duikt. Het is mogelijk dat niet alle mogelijkheden daadwerkelijk zijn geïmplementeerd op het CRD dat is aangemaakt door de operator. Het is echter een slechte gewoonte om de bronnen die door de operator zijn aangemaakt direct te manipuleren. De operator is niet getest tegen je handmatige wijzigingen en dit kan inconsistenties veroorzaken. Bovendien kunnen nieuwe versies van de operator je wijzigingen (gedeeltelijk) ongedaan maken, wat ook problemen kan veroorzaken.
Op dat moment zit je in principe vast, tenzij je je eigen operator maakt die extra mogelijkheden biedt. We hebben ook gemerkt dat er geen echt 'regelboek' is over hoe CRD's aan te bieden en documentatie is niet altijd gemakkelijk te vinden of te begrijpen.
Conclusie
Operators zijn momenteel een hot topic binnen de Kubernetes-gemeenschap. Het aantal beschikbare operators groeit snel, waardoor het eenvoudig is om functionaliteit aan je cluster toe te voegen. Er is echter geen regelboek of een minimale basislijn van kwaliteit. Als je operators installeert vanaf de operatorhub, controleer dan de inhoud of valideer de aangemaakte resources op een lokale opstelling. We verwachten in de nabije toekomst enkele veranderingen en verbeteringen, maar op dit moment kunnen ze al erg nuttig zijn.

What others have also read


In de complexe wereld van moderne softwareontwikkeling worden bedrijven geconfronteerd met de uitdaging om verschillende applicaties die door verschillende teams worden ontwikkeld en beheerd, naadloos te integreren. De Service Mesh is van onschatbare waarde bij het overwinnen van deze uitdaging. In dit blogartikel verdiepen we ons in Istio Service Mesh en onderzoeken we waarom investeren in een Service Mesh zoals Istio een slimme zet is." Wat is Service Mesh? Een Service Mesh is een softwarelaag die verantwoordelijk is voor alle communicatie tussen applicaties, in deze context services genoemd. Het introduceert nieuwe functionaliteiten om de interactie tussen services te beheren, zoals monitoring, logging, tracing en verkeerscontrole. Een service mesh werkt onafhankelijk van de code van elke individuele service, waardoor het over netwerkgrenzen heen kan werken en kan samenwerken met verschillende beheersystemen. Dankzij een service mesh kunnen ontwikkelaars zich richten op het bouwen van toepassingsfuncties zonder zich zorgen te maken over de complexiteit van de onderliggende communicatie-infrastructuur. Istio Service Mesh in de praktijk Denk aan het beheren van een groot cluster waarop meerdere applicaties draaien die ontwikkeld en onderhouden worden door verschillende teams, elk met verschillende afhankelijkheden zoals ElasticSearch of Kafka. Na verloop van tijd resulteert dit in een complex ecosysteem van applicaties en containers, overzien door verschillende teams. De omgeving wordt zo ingewikkeld dat het voor beheerders steeds moeilijker wordt om het overzicht te bewaren. Dit leidt tot een reeks pertinente vragen: Hoe ziet de architectuur eruit? Welke applicaties interageren met elkaar? Hoe wordt het verkeer beheerd? Bovendien zijn er specifieke uitdagingen die voor elke afzonderlijke applicatie moeten worden aangepakt: Het afhandelen van aanmeldingsprocessen Implementeren van robuuste beveiligingsmaatregelen Netwerkverkeer beheren dat naar de applicatie wordt geleid ... Een Service Mesh, zoals Istio, biedt een oplossing voor deze uitdagingen. Istio fungeert als een proxy tussen de verschillende applicaties (services) in het cluster, waarbij elk verzoek door een component van Istio gaat. Hoe werkt Istio Service Mesh? Istio introduceert een sidecar proxy voor elke service in het microservices ecosysteem. Deze sidecar proxy beheert al het inkomende en uitgaande verkeer voor de dienst. Daarnaast voegt Istio componenten toe die het inkomende en uitgaande verkeer van het cluster afhandelen. Istio's control plane maakt het mogelijk om beleidsregels te definiëren voor verkeersbeheer, beveiliging en monitoring, die vervolgens worden toegepast op de toegevoegde componenten. Voor een beter begrip van de functionaliteit van Istio Service Mesh, zie ons blogartikel "Istio Service Mesh installeren: A Comprehensive Step-by-Step Guide" , een gedetailleerde, stapsgewijze uitleg over de installatie en het gebruik van Istio. Waarom Istio Service Mesh? Verkeersbeheer: Istio maakt gedetailleerd verkeersbeheer mogelijk, waardoor ontwikkelaars eenvoudig verkeer tussen verschillende versies van hun services kunnen routeren, verdelen en controleren. Beveiliging: Istio biedt een robuuste beveiligingslaag met functies zoals verkeersversleuteling met behulp van eigen certificaten, Role-Based Access Control (RBAC) en mogelijkheden voor het implementeren van authenticatie- en autorisatiebeleid. Waarneembaarheid: Door middel van ingebouwde instrumentatie biedt Istio diepgaande observeerbaarheid met tools voor monitoring, logging en gedistribueerde tracering. Hierdoor kunnen IT-teams de prestaties van services analyseren en snel problemen opsporen. Vereenvoudigde communicatie: Istio neemt de complexiteit van servicecommunicatie weg van applicatieontwikkelaars, zodat zij zich kunnen richten op het bouwen van applicatiefuncties. Is Istio geschikt voor uw opstelling? Hoewel de voordelen duidelijk zijn, is het essentieel om te overwegen of de extra complexiteit van Istio past bij jouw specifieke opstelling. Ten eerste is er een sidecar container nodig voor elke ingezette service, wat kan leiden tot ongewenste geheugen- en CPU overhead. Daarnaast kan het zijn dat je team niet beschikt over de specialistische kennis die nodig is voor Istio. Als je overweegt om Istio Service Mesh te gaan gebruiken, vraag dan begeleiding aan specialisten met expertise. Vraag onze experts gerust om hulp. Meer informatie over Istio Istio Service Mesh is een technologische game-changer voor IT-professionals die streven naar geavanceerde controle, beveiliging en observeerbaarheid in hun microservices-architectuur. Istio vereenvoudigt en beveiligt de communicatie tussen services, waardoor IT-teams zich kunnen richten op het bouwen van betrouwbare en schaalbare applicaties. Snel antwoord nodig op al uw vragen over Istio Service Mesh? Neem contact op met onze experts
Lees verder

Bent u dit jaar niet op KubeCon geweest? Lees dan mee voor onze hoogtepunten van de KubeCon / CloudNativeCon-conferentie van dit jaar door het Cloud Native-team van ACA Group! Wat is KubeCon / CloudNativeCon? KubeCon (Kubernetes Conference) / CloudNativeCon , jaarlijks georganiseerd op EMAE door de Cloud Native Computing Foundation (CNCF), is een vlaggenschipconferentie die adopters en technologen van toonaangevende open source en cloud native gemeenschappen op één locatie samenbrengt. Dit jaar kwamen ongeveer 5.000 fysieke en 10.000 virtuele deelnemers opdagen voor de conferentie. CNCF is de open source, leverancier-neutrale hub van cloud native computing, die projecten zoals Kubernetes en Prometheus host om cloud native universeel en duurzaam te maken. Er waren meer dan 300 sessies van partners, industrieleiders, gebruikers en leveranciers over onderwerpen als CI/CD, GitOps, Kubernetes, machine learning, observeerbaarheid, netwerken, prestaties, service mesh en beveiliging. Het is duidelijk dat er altijd iets interessants te horen is op KubeCon, ongeacht je interessegebied of expertiseniveau! Het is duidelijk dat het Cloud Native ecosysteem is uitgegroeid tot een volwassen, trendsettende en revolutionaire game-changer in de industrie. Alles staat in het teken van de Kubernetes-trend en een enorme hoeveelheid organisaties die cloud native producten ondersteunen, gebruiken en hun bedrijf hebben laten groeien door ze te bouwen of te gebruiken in bedrijfskritische oplossingen. De belangrijkste thema's van 2022 Wat ons opviel tijdens KubeCon dit jaar waren de volgende hoofdthema's: De eerste was toenemende volwassenheid en stabilisatie van Kubernetes en bijbehorende producten voor monitoring, CI/CD, GitOps, operators, costing en service meshes, plus bug fixing en kleine verbeteringen. De tweede is een meer uitgebreide focus op beveiliging . Het veiliger maken van pods, het voorkomen van pod trampoline breakouts, end-to-end encryptie en het maken van volledige analyses van bedreigingen voor een complete k8s bedrijfsinfrastructuur. De derde is duurzaamheid en een groeiend bewustzijn dat systemen waarop k8s en de apps erop draaien veel energie verbruiken terwijl 60 tot 80% van de CPU ongebruikt blijft. Zelfs talen kunnen energie(on)efficiënt zijn. Java is een van de meest energie-efficiënte talen, terwijl Python dat blijkbaar veel minder is door de aard van de interpreter/compiler. Bedrijven moeten allemaal plannen maken en werken aan het verminderen van de energievoetafdruk in zowel applicaties als infrastructuur. Autoscaling zal hierbij een belangrijke rol spelen. Hoogtepunten van de sessies Duurzaamheid Datacenters verbruiken wereldwijd 8% van alle opgewekte elektriciteit. We moeten dus nadenken over het effectieve gebruik van onze infrastructuur en inactieve tijd vermijden (gemiddeld is het CPU-gebruik slechts tussen 20 en 40%) als servers draaien, laat ze dan werken met zoveel mogelijk werklasten resources afsluiten wanneer ze niet nodig zijn door het toepassen van autoscaling benaderingen de coderingstechnologie die gebruikt wordt in je software, sommige programmeertalen gebruiken minder CPU. CICD / GitOps GitOps automatiseert infrastructuur updates met behulp van een Git workflow met continue integratie (CI) en continue levering (CI/CD). Wanneer nieuwe code wordt samengevoegd, voert de CI/CD pijplijn de verandering door in de omgeving. Flux is hier een goed voorbeeld van. Flux biedt GitOps voor zowel apps als infrastructuur. Het ondersteunt GitRepository, HelmRepository en Bucket CRD als de enige bron van waarheid. Met A/B- of Canary-implementaties is het eenvoudig om nieuwe functies te implementeren zonder dat dit gevolgen heeft voor alle gebruikers. Als de implementatie mislukt, kan deze eenvoudig worden teruggedraaid. Bekijk het schema van KubeCon voor meer informatie! Kubernetes Hoewel Kubernetes 1.24 een paar weken voor de start van het evenement werd uitgebracht, waren er niet veel gesprekken gericht op de kern van Kubernetes. De meeste gesprekken waren gericht op het uitbreiden van Kubernetes (met behulp van API's, controllers, operators, ...) of best practices rond beveiliging, CI/CD, monitoring ... voor wat er ook draait binnen het Kubernetes-cluster. Als je geïnteresseerd bent in de nieuwe functies die Kubernetes 1.24 te bieden heeft, kun je de officiële website bekijken . Waarneembaarheid Inzicht krijgen in hoe je applicatie draait in je cluster is cruciaal, maar niet altijd even praktisch. Dit is waar eBPF om de hoek komt kijken, dat wordt gebruikt door tools zoals Pixie om gegevens te verzamelen zonder codewijzigingen. Bekijk het schema van KubeCon voor meer informatie! FinOps Nu steeds meer mensen Kubernetes gebruiken, zijn er veel workloads gemigreerd. Al deze containers hebben een voetafdruk. Geheugen, CPU, opslag, ... moeten worden toegewezen, en ze hebben allemaal een kostprijs. Kostenbeheer was een terugkerend onderwerp tijdens de gesprekken. Het gebruik van autoscaling (capaciteit toevoegen maar ook verwijderen) om de benodigde resources aan te passen en het identificeren van ongebruikte resources maken deel uit van deze nieuwe beweging. Nieuwe diensten zoals 'kubecost' worden steeds populairder. Prestaties Een van de meest voorkomende problemen in een cluster is niet genoeg ruimte of resources hebben. Met behulp van een Vertical Pod Autoscaler (VPA) kan dit tot het verleden behoren. Een VPA analyseert en slaat geheugen- en CPU-metriek/gegevens op om zich automatisch aan te passen aan de juiste CPU- en geheugenlimieten. De voordelen van deze aanpak laten je geld besparen, verspilling voorkomen, de onderliggende hardware optimaal dimensioneren, resources op worker nodes afstemmen en de plaatsing van pods in een Kubernetes cluster optimaliseren. Bekijk het schema van KubeCon voor meer informatie! Servicemesh We weten allemaal dat het heel belangrijk is om te weten welke applicatie data deelt met andere applicaties in je cluster. Service mesh biedt verkeerscontrole binnen uw cluster(s). Je kunt elk verzoek dat wordt verzonden of ontvangen van een applicatie naar andere applicaties blokkeren of toestaan. Het biedt ook Metrics, Specs, Split, ... informatie om de gegevensstroom te begrijpen. In de lezing Service Mesh op schaal: Hoe Xbox Cloud Gaming 22k Pods beveiligt met Linkerd , legt Chris uit waarom ze voor Linkerd hebben gekozen en wat de voordelen zijn van een service mesh. Bekijk het schema van KubeCon voor meer informatie! Beveiliging Trampoline pods, klinkt leuk, toch? Tijdens een lezing van twee beveiligingsonderzoekers van Palo Alto Networks leerden we dat ze niet zo leuk zijn. Kort gezegd zijn dit pods die gebruikt kunnen worden om cluster admin privileges te krijgen. Om meer te leren over het concept en hoe ermee om te gaan, raden we je aan om de slides op de KubeCon schedule pagina te bekijken! Lachlan Evenson van Microsoft gaf een duidelijke uitleg over Pod Security in zijn The Hitchhiker's Guide to Pod Security talk. Pod Security is een ingebouwde toelatingscontroleur die Pod-specificaties evalueert aan de hand van een vooraf gedefinieerde set Pod Security-standaarden en bepaalt of de pod moet worden toegelaten of geweigerd. - Lachlan Evenson , Programmamanager bij Microsoft . Pod Security vervangt PodSecurityPolicy vanaf Kubernetes 1.23. Dus als je PodSecurityPolicy gebruikt, is dit misschien een goed moment om Pod Security en het migratiepad verder te onderzoeken. In versie 1.25 wordt de ondersteuning voor PodSecurityPolicy verwijderd. Als je PodSecurityPolicy of Pod Security niet gebruikt, is het zeker tijd om het verder te onderzoeken! Een ander terugkerend thema van deze KubeCon 2022 waren operators. Operators maken het mogelijk om de Kubernetes API uit te breiden met operationele kennis. Dit wordt bereikt door Kubernetes-controllers te combineren met bekeken objecten die de gewenste toestand beschrijven. Ze introduceren Custom Resource Definitions, custom controllers, Kubernetes of cloud resources en logging en metrics, wat het leven makkelijker maakt voor zowel Dev als Ops. Tijdens een lezing van Kevin Ward van ControlPlane leerden we echter dat er ook risico's aan verbonden zijn. Bovendien, en dat is nog belangrijker, vertelde hij ook hoe we die risico's kunnen identificeren met tools zoals BadRobot en een operator thread matrix . Bekijk de KubeCon roosterpagina voor meer informatie! Planning Telemetry Aware Scheduling helpt u om uw workloads te plannen op basis van de statistieken van uw worker nodes. U kunt bijvoorbeeld een regel instellen om geen nieuwe werklasten te plannen op worker nodes met meer dan 90% gebruikt geheugen. Het cluster zal hier rekening mee houden bij het plannen van een pod. Een andere leuke functie van deze tool is dat het ook pods opnieuw kan inplannen om ervoor te zorgen dat uw regels in lijn blijven. Bekijk de KubeCon planningspagina voor meer informatie! Cluster autoscaling Een geweldige manier voor stateless workloads om kosteneffectief te schalen is het gebruik van AWS EC2 Spot, wat reserve VM-capaciteit is die met korting beschikbaar is. Om Spot-instanties effectief te gebruiken in een K8S cluster, moet je aws-node-termination-handler gebruiken. Op deze manier kun je je werklasten van een worker node verplaatsen wanneer Spot besluit deze terug te vorderen. Een ander goed hulpmiddel is Karpenter , een hulpmiddel om Spot-instanties precies op tijd te leveren voor je cluster. Met deze twee tools kun je je stateless workloads kosteneffectief hosten! Bekijk de KubeCon schedule pagina voor meer informatie! Event-gedreven autoscaling Het gebruik van de Horizontal Pod Autoscaler (HPA) is een geweldige manier om pods te schalen op basis van statistieken zoals CPU-gebruik, geheugengebruik en meer. In plaats van te schalen op basis van statistieken, kan Kubernetes Event Driven Autoscaling (KEDA) schalen op basis van gebeurtenissen (Apache Kafka, RabbitMQ, AWS SQS, ...) en het kan zelfs schalen tot 0 in tegenstelling tot HPA. Bekijk het schema van KubeCon voor meer informatie! Wrap-up We hebben dit jaar genoten van de conferentie. We vertrokken met een geïnspireerd gevoel dat we ongetwijfeld zullen vertalen naar interne projecten, nieuwe klantprojecten zullen aanvragen en waar van toepassing zullen bespreken met bestaande klanten. Niet alleen dat, maar we zullen ook onze collega's informeren en een afterglow sessie organiseren voor de geïnteresseerden thuis in België. Als je ons blogartikel leuk vond, stuur ons dan gerust een berichtje. We zijn altijd blij als de inhoud die we publiceren ook voor jou waardevol of interessant is. Als je denkt dat we jou of je bedrijf kunnen helpen bij de adoptie van Cloud Native, stuur me dan een berichtje op peter.jans@aca-it.be. Als laatste willen we Mona bedanken voor de logistiek, Stijn en Ronny voor deze kans en de rest van het team dat achterbleef om de systemen van onze gewaardeerde klanten in de gaten te houden.
Lees verder

Op 7 en 8 december 2023 namen verschillende ACA-leden deel aan CloudBrew 2023 , een inspirerende tweedaagse conferentie over Microsoft Azure. In het decor van de voormalige Lamot brouwerij kregen bezoekers de kans om zich te verdiepen in de nieuwste cloudontwikkelingen en hun netwerk uit te breiden. Met verschillende tracks en boeiende sprekers bood CloudBrew een schat aan informatie. De intieme setting stelde deelnemers in staat om direct contact te leggen met zowel lokale als internationale experts. In dit artikel lichten we graag enkele van de meest inspirerende lezingen van deze tweedaagse cloudbijeenkomst uit: Azure-architectuur: Verstandig kiezen Rik Hepworth , Chief Consulting Officer bij Black Marble en Microsoft Azure MVP/RD, gebruikte een klantvoorbeeld waarbij .NET ontwikkelaars verantwoordelijk waren voor het beheer van de Azure infrastructuur. Hij betrok het publiek in een interactieve discussie om de beste technologieën te kiezen. Hij benadrukte verder het belang van een gebalanceerde aanpak, waarbij nieuwe kennis wordt gecombineerd met bestaande oplossingen voor effectief beheer en ontwikkeling van de architectuur. Van gesloten platform naar landingszone met Azure Policy David de Hoop , Special Agent bij Team Rockstars IT, vertelde over de Azure Enterprise Scale Architecture, een template van Microsoft die bedrijven ondersteunt bij het opzetten van een schaalbare, veilige en beheersbare cloud-infrastructuur. De template biedt richtlijnen voor het ontwerpen van een cloudinfrastructuur die kan worden aangepast aan de behoeften van een bedrijf. Een cruciaal aspect van deze architectuur is de landingszone, een omgeving die zich houdt aan ontwerpprincipes en alle applicatieportfolio's ondersteunt. Het maakt gebruik van abonnementen om applicatie- en platformbronnen te isoleren en te schalen. Azure Policy biedt een reeks richtlijnen om Azure-infrastructuur open te stellen voor een onderneming zonder in te boeten aan beveiliging of beheer. Dit geeft engineers meer vrijheid in hun Azure-omgeving, terwijl beveiligingsfuncties automatisch worden afgedwongen op tenantniveau en zelfs applicatiespecifieke instellingen. Dit zorgt voor een evenwichtige aanpak om zowel flexibiliteit als beveiliging te garanderen, zonder dat er aparte tools of technologieën nodig zijn. De grootste Azure fouten van België waarvan ik wil dat jij ervan leert! Tijdens deze sessie presenteerde Toon Vanhoutte , Azure Solution Architect en Microsoft Azure MVP, de meest voorkomende fouten en menselijke vergissingen, gebaseerd op de ervaringen van meer dan 100 Azure engineers. Aan de hand van waardevolle praktijkvoorbeelden illustreerde hij niet alleen de fouten zelf, maar bood hij ook duidelijke oplossingen en preventieve maatregelen om soortgelijke incidenten in de toekomst te voorkomen. Zijn waardevolle inzichten hielpen zowel beginnende als ervaren Azure engineers hun kennis aan te scherpen en hun implementaties te optimaliseren. Kritieke ICS SCADA-infrastructuur beschermen met Microsoft Defender Deze presentatie van Microsoft MVP/RD, Maarten Goet , richtte zich op het gebruik van Microsoft Defender voor ICS SCADA infrastructuur in de energiesector. De spreker deelde inzichten over het belang van cyberbeveiliging in deze kritieke sector en illustreerde dit met een demo waarin de kwetsbaarheden van dergelijke systemen werden gedemonstreerd. Hij benadrukte de noodzaak van proactieve beveiligingsmaatregelen en benadrukte Microsoft Defender als een krachtige tool voor het beschermen van ICS SCADA-systemen. Azure Digital Twin gebruiken in productie Steven De Lausnay , Specialist Lead Data Architecture en IoT Architect, introduceerde Azure Digital Twin als een geavanceerde technologie om digitale replica's te maken van fysieke omgevingen. Door inzicht te geven in het proces achter Azure Digital Twin, liet hij zien hoe organisaties in productieomgevingen gebruik kunnen maken van deze technologie. Hij benadrukte de waarde van Azure Digital Twin voor het modelleren, monitoren en optimaliseren van complexe systemen. Deze technologie kan een cruciale rol spelen bij het verbeteren van de operationele efficiëntie en het nemen van datagestuurde beslissingen in verschillende industriële toepassingen. Azure Platform aanbevelingen omzetten in goud Magnus Mårtensson , CEO van Loftysoft en Microsoft Azure MVP/RD, had de eer om CloudBrew 2023 af te sluiten met een boeiende samenvatting van de hoogtepunten. Met zijn onderhoudende presentatie bood hij waardevolle reflectie op de verschillende thema's die tijdens het evenement waren besproken. Het was een perfecte afsluiting van een zeer succesvolle conferentie en gaf iedere deelnemer zin om de opgedane inzichten direct in de praktijk te brengen. We kijken nu al uit naar CloudBrew 2024! 🚀
Lees verderWant to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!

Want to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!

Want to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!

Want to dive deeper into this topic?
Get in touch with our experts today. They are happy to help!


