Leestijd 7 min

ACA Group Team

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.

Leestijd 7 min

Bregt Coenen

Binnen ACA werken meerdere teams aan verschillende (of dezelfde!) projecten. Elk team heeft zijn eigen expertisedomeinen, zoals het ontwikkelen van software op maat, marketing en communicatie, mobiele ontwikkeling en meer. De teams die gespecialiseerd zijn in Atlassian-producten en cloud-expertise combineerden hun kennis om een zeer beschikbare Atlassian-stack op Kubernetes te creëren. Niet alleen konden we op deze manier onze interne processen verbeteren, we konden deze oplossing ook aan onze klanten aanbieden! In deze blogpost leggen we uit hoe onze Atlassian- en cloudteams een hoogbeschikbare Atlassian-stack bovenop Kubernetes hebben gebouwd. We bespreken ook de voordelen van deze aanpak en de problemen die we onderweg zijn tegengekomen. Hoewel we er verdomd dichtbij zijn, zijn we toch niet perfect 😉 Tot slot bespreken we hoe we deze setup monitoren. De opzet van onze Atlassian-stack Onze Atlassian stack bestaat uit de volgende producten: Amazon EKS Amazon EFS Atlassian Jira Data Center Atlassian Confluence gegevenscentrum Amazon EBS Atlassian Bitbucket datacenter Amazon RDS Zoals je kunt zien, gebruiken we AWS als cloud provider voor onze Kubernetes setup. We maken alle resources aan met Terraform. We hebben een aparte blogpost geschreven over hoe onze Kubernetes setup er precies uitziet. Je kunt het hier lezen ! De afbeelding hieronder zou je een algemeen idee moeten geven. Het volgende diagram geeft je een idee van de opzet van ons Atlassian Data Center. Hoewel er een paar verschillen zijn tussen de producten en de opstellingen, blijft de kern hetzelfde. De applicatie wordt gestart als een of meer pods die worden beschreven door een StatefulSet. De pods worden node-0 en node-1 genoemd in het bovenstaande diagram. Het eerste verzoek wordt naar de load balancer gestuurd en wordt doorgestuurd naar de node-0 pod of de node-1 pod. Verkeer is sticky, dus al het volgende verkeer van die gebruiker wordt naar node-1 gestuurd. Zowel pod-0 als pod-1 hebben persistente opslag nodig die gebruikt wordt voor de plugin cache en indexen. Op elk van de pods wordt een ander Amazon EBS volume gemount. De meeste gegevens zoals je JIRA issues, Confluence ruimtes, ... worden opgeslagen in een database. De database wordt gedeeld, node-0 en node-1 maken beide verbinding met dezelfde database. We gebruiken meestal PostgreSQL op Amazon RDS. De node-0 en node-1 pod moeten ook grote bestanden delen die we niet in een database willen opslaan, bijvoorbeeld bijlagen. Hetzelfde Amazon EFS volume wordt op beide pods gemount. Wanneer er wijzigingen worden aangebracht, bijvoorbeeld een bijlage wordt geüpload naar een issue, is de bijlage onmiddellijk beschikbaar op beide pods. We gebruiken CloudFront (CDN) om statische assets te cachen en de responstijden op het web te verbeteren. De voordelen van deze opzet Door deze opzet te gebruiken, kunnen we gebruikmaken van de voordelen van Docker en Kubernetes en de datacenterversies van de Atlassian-tooling. Er zijn veel voordelen verbonden aan deze manier van werken, maar we hebben de belangrijkste voordelen hieronder opgesomd. Het is een zelfherstellend platform : containers en worker nodes vervangen zichzelf automatisch als er een storing optreedt. In de meeste gevallen hoeven we niets te doen en zorgt de stack voor zichzelf. Natuurlijk is het nog steeds belangrijk om storingen te onderzoeken, zodat je ze in de toekomst kunt voorkomen. Precies nul downtime implementaties : wanneer we de eerste node binnen het cluster upgraden naar een nieuwe versie, kunnen we de oude versie nog steeds aan onze klanten serveren op de tweede. Zodra de upgrade is voltooid, wordt de nieuwe versie geserveerd vanaf het eerste knooppunt en kunnen we het tweede knooppunt upgraden. Op deze manier blijft de applicatie beschikbaar, zelfs tijdens upgrades. Deployments zijn voorspelbaar : we gebruiken dezelfde Docker-container voor ontwikkeling, staging en productie. Daarom hebben we er vertrouwen in dat de container in onze productieomgeving kan starten na een succesvolle deploy naar staging. Applicaties met hoge beschikbaarheid: als er een storing optreedt op een van de nodes, kan het verkeer worden omgeleid naar de andere node. Op deze manier heb je de tijd om het probleem te onderzoeken en de kapotte node te repareren terwijl de applicatie beschikbaar blijft. Het is mogelijk om gegevens van het ene naar het andere knooppunt te synchroniseren . Zo kan het synchroniseren van de index van de ene node naar de andere om een corrupte index te herstellen in slechts enkele seconden gebeuren, terwijl een volledige herindexering veel langer kan duren. Je kunt een hoog beveiligingsniveau implementeren op alle lagen (AWS, Kubernetes, applicatie, . ..) AWS CloudTrail voorkomt ongeautoriseerde toegang op AWS en stuurt een waarschuwing in geval van een afwijking. AWS Config voorkomt wijzigingen in AWS-beveiligingsgroepen. Je kunt meer te weten komen over hoe je je cloud kunt beveiligen met AWS Config in onze blogpost. Terraform zorgt ervoor dat wijzigingen op de AWS-omgeving door het team worden goedgekeurd voordat ze worden uitgerold. Aangezien het upgraden van Kubernetes master en worker nodes weinig tot geen impact heeft, draait de stack altijd op een recente versie met de laatste beveiligingspatches. We gebruiken een combinatie van namespacing en RBAC om ervoor te zorgen dat applicaties en implementaties alleen toegang hebben tot bronnen binnen hun naamruimte met de minste privileges . Netwerkbeleid wordt uitgerold met Calico. We weigeren standaard al het verkeer tussen containers en staan alleen specifiek verkeer toe. We gebruiken recente versies van de applicaties van Atlassian en implementeren beveiligingsberichten wanneer deze door Atlassian worden gepubliceerd. Geïnteresseerd om zelf de kracht van Kubernetes te benutten? Op onze website vind je meer informatie over hoe we je kunnen helpen! {% module_block module "widget_3d4315dc-144d-44ec-b069-8558f77285de" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"Apply the power of Kubernetes"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":null,"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %} De kracht van Kubernetes toepassen Problemen die we tegenkwamen tijdens de installatie De migratie naar deze stack was niet alleen maar leuk en aardig. We zijn onderweg zeker een aantal moeilijkheden en uitdagingen tegengekomen. Door ze hier te bespreken, hopen we dat we jouw migratie naar een vergelijkbare setup kunnen vergemakkelijken! Sommige plugins (meestal oudere plugins) werkten alleen op de standalone versie van de Atlassian applicatie. We moesten een alternatieve plugin vinden of ondersteuning van een leverancier gebruiken om dezelfde functionaliteit op Atlassian Data Center te krijgen. We moesten enkele wijzigingen aanbrengen in onze Docker-containers en netwerkbeleid (bijv. firewallregels) om ervoor te zorgen dat beide nodes van een applicatie met elkaar konden communiceren. De meeste applicaties hebben wat extra tools in de container. Bijvoorbeeld Synchrony voor Confluence, ElasticSearch voor BitBucket, EazyBI voor Jira, enzovoort. Deze extra tools moesten allemaal gerefactored worden voor een multi-node opstelling met gedeelde gegevens. In onze vorige opstelling draaide elke applicatie op zijn eigen virtuele machine. In een Kubernetes-context zijn de applicaties verspreid over een aantal worker nodes. Daarom kan één worker node meerdere applicaties draaien. Elke node van elke applicatie wordt gepland op een worker node die voldoende resources beschikbaar heeft. We moesten een goed plaatsingsbeleid implementeren zodat elk knooppunt van elke applicatie voldoende geheugen beschikbaar heeft. We moesten er ook voor zorgen dat een applicatie een andere applicatie niet kon beïnvloeden als deze om meer resources vroeg. Er waren ook enkele uitdagingen met betrekking tot load balancing. We moesten een aangepast sjabloon maken voor nginx ingress-controller om ervoor te zorgen dat websockets correct werken en dat alle gezondheidscontroles binnen de applicatie een gezonde status rapporteren. Daarnaast hadden we een andere loadbalancer en URL nodig voor ons BitBucket SSH-verkeer in vergelijking met ons webverkeer naar de BitBucket UI. Onze vorige installatie bevatte veel gegevens, zowel op het bestandssysteem als in de database. We moesten alle gegevens migreren naar een Amazon EFS-volume en een nieuwe database in een nieuw AWS-account. Het was een uitdaging om een manier te vinden om een consistent synchronisatieproces te hebben dat ook niet te lang duurde, omdat tijdens de migratie alle applicaties down waren om gegevensverlies te voorkomen. Uiteindelijk konden we aan deze criteria voldoen en konden we succesvol migreren. Onze Atlassian-stack monitoren We gebruiken de volgende tools om alle resources binnen onze setup te monitoren Datadog om alle componenten te monitoren die zijn gemaakt binnen onze stack en om logging van alle componenten te centraliseren. Je kunt meer lezen over het monitoren van je stack met Datadog in onze blogpost hier . NewRelic voor APM-monitoring van het Java-proces (Jira, Confluence, Bitbucket) binnen de container. Als onze monitoring een afwijking detecteert, wordt er een alert aangemaakt binnen OpsGenie . OpsGenie zorgt ervoor dat deze waarschuwing naar het team of de oproepkracht wordt gestuurd die verantwoordelijk is voor het oplossen van het probleem. Als de oproepkracht de waarschuwing niet op tijd bevestigt, wordt de waarschuwing geëscaleerd naar het team dat verantwoordelijk is voor die specifieke waarschuwing. Conclusie Kortom, we zijn erg blij dat we zijn overgestapt op deze nieuwe stack. De combinatie van de voordelen van Kubernetes en de Atlassian Data Center versies van Jira, Confluence en BitBucket voelt als een grote stap in de goede richting. We hebben elke dag profijt van de verbeteringen op het gebied van self-healing, deployment en monitoring en het onderhoud is een stuk eenvoudiger geworden. Geïnteresseerd in je eigen Atlassian Stack? Wil je ook de kracht van Kubernetes benutten? Op onze website vind je meer informatie over hoe we je kunnen helpen ! Ons Atlassian hostingaanbod

Leestijd 6 min

Bregt Coenen

Bij ACA leven en ademen we Kubernetes. We zetten nieuwe projecten standaard op met dit populaire container orkestratiesysteem en we migreren ook bestaande klanten naar Kubernetes. Als gevolg daarvan groeit het aantal Kubernetes-clusters dat het ACA-team beheert snel! We hebben onze setup meerdere keren moeten veranderen om tegemoet te komen aan meer klanten, meer clusters, meer belasting, minder onderhoud, enzovoort. Van een Amazon ECS naar een Kubernetes setup In 2016 hadden we veel projecten die in Docker-containers draaiden. Op dat moment draaiden onze Docker-containers in Amazon ECS of op virtuele machines van Amazon EC2 waarop de Docker-daemon draaide. Helaas vergde deze opstelling veel onderhoud. We hadden een tool nodig die ons een betrouwbare manier zou bieden om deze containers in productie te draaien. We verlangden naar een orchestrator die ons hoge beschikbaarheid, automatische opschoning van oude resources, automatische containerplanning en nog veel meer zou bieden. → Enter Kubernetes ! Kubernetes bleek de perfecte kandidaat te zijn voor een container orkestratietool. Het kon containers betrouwbaar in productie draaien en de hoeveelheid onderhoud die nodig was voor onze opstelling verminderen. Een Kubernetes-gerichte aanpak creëren Behendig als we zijn, stelden we het idee voor een Kubernetes-opstelling voor een van onze volgende projecten voor. De klant zag het potentieel van onze nieuwe aanpak en stemde ermee in om deel uit te maken van de revolutie. Begin 2017 creëerden we ons eerste Kubernetes-cluster. In dit stadium waren er slechts twee zekerheden: we wilden Kubernetes draaien en het zou op AWS draaien . Daarnaast waren er nog veel vragen en uitdagingen. Hoe zouden we ons cluster opzetten en beheren? Kunnen we onze bestaande docker-containers in het cluster draaien? Wat voor toegang en informatie kunnen we de ontwikkelteams geven? We hebben geleerd dat de moeilijkste taak uiteindelijk niet het opzetten van het cluster was. In plaats daarvan bleek het creëren van een nieuwe mindset binnen ACA Group om deze nieuwe aanpak te accepteren en het betrekken van de ontwikkelteams bij onze next-gen Kubernetes setup de moeilijkste taak te zijn. Naast het zelf leren kennen van het product en het betrekken van andere teams, hadden we nog een aantal andere taken die onze aandacht vroegen: we moesten elke applicatie dockeriseren, we moesten in staat zijn om applicaties in het Kubernetes-cluster op te zetten die hoog beschikbaar en indien mogelijk ook zelfhelend waren, en geclusterde applicaties moesten hun status kunnen delen met behulp van de beschikbare methoden binnen de geselecteerde container netwerkinterface. Het bleek een hele uitdaging om te wennen aan deze nieuwe manier van werken in combinatie met andere taken, zoals het opzetten van goede monitoring, een gecentraliseerde logging setup en het implementeren van onze applicaties op een consistente en onderhoudbare manier. Gelukkig konden we deze uitdagingen overwinnen en ongeveer een half jaar nadat we ons eerste Kubernetes-cluster hadden gemaakt, ging ons eerste productiecluster live (augustus 2017). Dit waren de kernonderdelen van onze toolset anno 2017: Terraform zou de AWS VPC, netwerkcomponenten en andere afhankelijkheden voor het Kubernetes-cluster implementeren Kops voor clustercreatie en -beheer Een EFK-stack voor logging werd ingezet binnen het Kubernetes-cluster Heapster, influxdb en grafana in combinatie met Librato voor monitoring binnen het cluster Opsgenie voor waarschuwingen Leuk! ... maar het kan beter: kosten, componenten en downtime verlagen Nadat we onze eerste opstelling hadden voltooid, werd het eenvoudiger om dezelfde topologie te gebruiken en zijn we doorgegaan met het implementeren van deze opstelling voor andere klanten. Door onze infrastructure-as-code aanpak (Terraform) in combinatie met een Kubernetes cluster management tool (Kops) was de inspanning om nieuwe clusters aan te maken relatief laag. Na een tijdje begonnen we echter een aantal mogelijke risico's op te merken met betrekking tot deze setup. De hoeveelheid werk die nodig was voor de setup en de impact van updates of upgrades op onze Kubernetes-stack was te groot. Tegelijkertijd groeide het aantal klanten dat hun eigen Kubernetes-cluster wilde. We moesten dus een aantal veranderingen doorvoeren om de onderhoudsinspanning op het Kubernetes-gedeelte van deze setup te verminderen en de zaken beheersbaar te houden voor onszelf. Migratie naar Amazon EKS en Datadog Op dit punt werd de Kubernetes-service van AWS (Amazon EKS) algemeen beschikbaar. We waren in staat om alle dingen die door Kops worden beheerd te verplaatsen naar onze Terraform-code, waardoor de dingen een stuk minder complex werden. Als extra voordeel worden de Kubernetes masternodes nu beheerd door EKS. Dit betekent dat we nu minder nodes hoeven te beheren en EKS biedt ons ook clusterupgrades met één druk op de knop. Naast het verminderen van de werklast op ons Kubernetes-beheervlak, hebben we ook het aantal componenten binnen ons cluster verminderd. In de vorige opstelling gebruikten we een EFK-stack (ElasticSearch, Fluentd en Kibana) voor onze loginfrastructuur. Voor onze monitoring gebruikten we een combinatie van InfluxDB, Grafana, Heapster en Librato. Deze tools gaven ons veel flexibiliteit, maar vergden veel onderhoud, omdat ze allemaal binnen het cluster draaiden. We hebben ze allemaal vervangen door Datadog agent, waardoor onze onderhoudswerkzaamheden drastisch zijn verminderd. Upgrades in 60 minuten Bovendien waren we door de migratie naar Amazon EKS en de vermindering van het aantal componenten die binnen het Kubernetes-cluster draaien, in staat om de kosten en de impact op de beschikbaarheid van onze clusterupgrades te verminderen. Met de huidige stack, die Datadog en Amazon EKS gebruikt, kunnen we een Kubernetes-cluster binnen een uur upgraden. Als we de vorige stack zouden gebruiken, zouden we daar gemiddeld 10 uur over doen. Waar staan we nu? Op dit moment hebben we 16 Kubernetes-clusters draaien , allemaal met de laatst beschikbare EKS-versie. Op dit moment willen we onze liefde voor Kubernetes verspreiden waar we maar kunnen. Meerdere projectteams binnen ACA Group maken nu gebruik van Kubernetes, dus we organiseren workshops om ze te helpen snel met de technologie overweg te kunnen. Tegelijkertijd proberen we ook op de hoogte te blijven van de nieuwste toevoegingen aan dit snel veranderende platform. Daarom hebben we de Kubecon conferentie in Barcelona bijgewoond en onze meningen gedeeld in ons Kubecon Afterglow evenement. Wat is de volgende stap? Hoewel we erg blij zijn met onze huidige Kubernetes setup, geloven we dat er altijd ruimte is voor verbetering . Tijdens ons Kubecon Afterglow evenement hebben we een aantal interessante discussies gehad met andere Kubernetes enthousiastelingen. Deze discussies hebben ons geholpen om onze volgende stappen te definiëren en onze Kubernetes setup naar een nog hoger niveau te brengen. Enkele dingen die we in de nabije toekomst willen verbeteren: service mesh toevoegen aan onze Kubernetes stack, 100% automatische worker node upgrades zonder applicatie downtime. Natuurlijk zijn dit maar een paar aandachtspunten. We zullen veel nieuwe functies en verbeteringen implementeren zodra ze worden vrijgegeven! Hoe zit het met jou? Ben je geïnteresseerd in je eigen Kubernetes-cluster? Welke verbeteringen ben je van plan aan te brengen in je stack of Kubernetes setup? Of heb je een onbeantwoorde Kubernetes-vraag waarmee we je misschien kunnen helpen? Neem contact met ons op via cloud@aca-it.be en we helpen je verder! {% module_block module "widget_7e6bdbd6-406c-4a0a-8393-27a28f436c6d" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"Our Kubernetes services"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":{"content_id":null,"href":"https://www.acagroup/be/en/services/kubernetes","href_with_scheme":"https://www.acagroup/be/en/services/kubernetes","type":"EXTERNAL"},"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}

Leestijd 7 min

Bregt Coenen

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 Standaard En na enige tijd wordt het HEALTHY . kubectl get istiooperator -n istio-system NAME REVISION STATUS AGE istio-controlplane HEALTHY 12m Standaard Je kunt zien dat de istiod pod draait. NAMESPACE NAME READY STATUS istio-system istiod-7dc88f87f4-n86z9 Standaard 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 Standaard 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.