3 gode grunde til at holde din Kubernetes-platform opdateret, og hvorfor det faktisk er lidt svært…

Måske har din virksomhed allerede fået administreret dine container-baserede applikationer ved hjælp af Kubernetes, og oplever nu udfordringer med at holde den opdateret. Vi giver dig her 3 gode grunde til at holde den opdateret, samt lidt inspiration til hvad der skal til for at gøre det lettere.

3 gode grunde til at holde din Kubernetes-platform opdateret

• Hver måned kommer der, for de fleste komponenter i CNCF-landskabet, planlagte releases. Disse releases fikser ret ofte en eller flere kendte sikkerhedsfejl. Hvis du ikke holder øje med release-notes og undersøger de CVE’er de retter op på, risikerer du at din platform er usikker og har kendte fejl, som kan udnyttes.

• Hver 4. måned opdateres Kubernetes, og her er det kun de 3 seneste releases der understøttes. Det betyder i praksis at efter cirka 9 måneder, er sikkerhedsrettelser ikke længere tilgængelige for den version du kører. Læs mere og få brugbar viden om Kubernetes’ release-strategi her.

• De CNCF-komponenter du anvender har samme problematik som beskrevet ovenfor. De har egne release-cykler, og man skal derfor løbende følge med i deres release notes. Når man opdaterer sin Kubernetes-platform, skal man teste den nye version af komponenten for at sikre at den samlede platform stadig fungerer. Når du har sikret at platformen stadig fungerer som forventet, bør du også teste dine løsninger på platformen. Dette kan man med stor fordel arbejde på at automatisere, hvis du skal opdatere ofte. Du kan eventuelt prøve at opdatere manuelt 3-4 gange, og på den måde finde ud af hvad der skal automatiseres først.

Sådan håndterer du opdateringer af din Kubernetes-platform i praksis

Hos KvalitetsIT har vi etableret en gruppe på 3 medarbejdere, som hver måned læser alle release-noter for alle de komponenter vi anvender. På baggrund af dette beslutter og dokumenterer de hvorvidt en komponent skal opdateres nu, eller om det kan vente til næste måned.
Skal den opdateres, så gennemføres opdateringen i et testmiljø. Hvis opdateringen går godt, gennemføres der en standardtest for at verificere at platformen stadig fungerer med den nye opdatering.
Det kan være en enkelt test som f.eks. at betjene specifikke dele af de brugergrænseflader systemet kommer med. I praksis er det svært at verificere den tomme platform, og om den rigtige test kommer når de faktiske løsninger testes. En automatiseret installation vil her gøre løbende opdateringer lettere.

Når ovenstående er gennemført kan staging-miljøet opdateres og testen kan gentages her. Det er en god idé at holde øje med ressourceforbruget og adfærd de første par dage efter en opdatering, for at se om der gemmer sig nogle ubehagelige overraskelser. Endelig kan vi så sætte opdateringen i drift.

Det hele kræver naturligvis at man har styr på hvad man har installeret og i hvilke versioner, og så bliver det langt lettere og mindre risikofyldt, hvis man har versionsstyring af sin konfiguration. Hos KvalitetsIT arbejder vi efter det princip, der hedder GitOps, hvor vi passer på vores konfigurationskode som alt andet kode, så vi både har styr på versioner og QA processen.