OpenShift-konsult – plattformen på djupet

Vad vi hjälper till med

Installation och arkitektur

Vi tar fram en arkitektur som passar er verklighet: IPI eller UPI, bare metal eller virtualiserat, enskilt kluster eller flera. Identitet, nätverk, lagring och namnrymder sätts från början så att plattformen går att förvalta, inte bara starta. Allt vi kan uttrycks som kod, så att miljön går att återskapa och granska.

IPI passar när installern kan äga infrastrukturen och ni vill ha en repeterbar väg från noll till kluster. UPI passar när nät, lastbalanserare eller virtuell infrastruktur redan finns och måste följa era regler. I båda fallen dokumenterar vi valen: var kontrollplanet kör, hur arbetarnoder kommer in och hur en återinstallation skulle se ut. Lagring, ingress och identitet är med från första dagen, så att första arbetsbelastningen inte blir den som definierar plattformen i efterhand.

Som kod betyder att installationen, namnrymderna och de grundläggande policyerna ligger i ett repo som går att läsa, granska och köra igen. När någon frågar hur klustret blev som det blev är svaret en historik, inte en skärmdump från installationsdagen.

Uppgraderingar och livscykel

OpenShift uppgraderas i kanaler. Vi planerar versionsstegen, testar i icke-produktion, tar höjd för Operators och EUS där det behövs, och genomför uppgraderingen så att den blir rutin i stället för en nattlig chansning. Ni får en tydlig plan för vad som händer före, under och efter.

En kanal är ett löfte om vilka versioner som erbjuds, inte ett löfte om att varje hopp är ofarligt. Vi tittar på vilka Operators som måste upp före klustret, vilka som kan vänta, och var ett EUS-spår är rätt när ni behöver stanna längre på en version. Testet sker i en miljö som liknar produktion tillräckligt för att fånga det som brukar gå sönder: routes, identitet, lagring och de arbetsbelastningar som inte tål ett kort avbrott. När lyftet är gjort skriver vi vad som ändrades, så att nästa gång börjar från en plan och inte från ett minne.

Operators och plattformstjänster

Många team fastnar i Operators som "nästan fungerar". Vi sätter upp och förvaltar de Operators ni faktiskt behöver (till exempel logging, monitoring, pipelines och GitOps), med versioner och uppgraderingsordning som hänger ihop med klustret. En Operator som ingen äger blir en tyst beroendeled: den uppgraderas för sent, eller för tidigt, och felet syns någon annanstans. Vi håller listan kort, versionslåst och kopplad till samma livscykel som klustret.

Vi börjar med att lista vad som redan är installerat och vad som faktiskt används. Logging och monitoring som ingen tittar på är inte en plattformstjänst, det är en uppgraderingsrisk. Pipelines och GitOps stannar när de är sättet ni levererar på. Allt annat får ett beslut: behåll, byt eller ta bort, med en ägare och en version.

Säkerhet: SCC, policyer och nätverk

Security Context Constraints, nätverkspolicyer, ingress/routes och secrets-hantering hör ihop. Vi utgår från restriktiva standarder (bland annat restricted-v2 där det passar er version), dokumenterar undantag och ser till att undantagen är medvetna, inte historiska. Härdning och spårbarhet byggs in så att ni kan visa hur plattformen styrs, till exempel inför krav kopplade till NIS2 och CRA.

restricted-v2 är utgångspunkten där er version stöder den, inte en regel vi lägger på en gammal arbetsbelastning utan plan. Varje undantag skrivs ned: vilken workload, varför, hur länge och vem som godkänt det. Nätverkspolicyer och routes går vi igenom samtidigt, så att en öppning i det ena inte tystas av en regel i det andra.

GitOps och pipelines

OpenShift GitOps (Argo CD) och OpenShift Pipelines (Tekton) ger er samma arbetssätt i alla miljöer. Vi sätter upp flöden där ändringar granskas, signeras där ni kräver det, och går att rulla tillbaka. Behöver ni bredare DevSecOps i leveranskedjan tar vi det under DevOps och DevSecOps.

Målet är att det som körs går att härleda till en commit. När något ska rullas tillbaka är det en tidigare revision, inte en manuell ändring i console som ingen kan återskapa. Signering lägger vi till där ni redan kräver det, tillsammans med en process, inte som en flagga utan ägare.

Daglig drift

Vi kan äga driften, vara andralinje åt ert team eller gå in för en avgränsad insats: versionslyft, migrering eller en plattform som behöver städas. Mer om hur vi arbetar med Kubernetes-plattformar i stort finns på Kubernetes-konsult.

Andralinje betyder att ert team tar första linjen och vi tar det som kräver plattformskännedom: en Operator som fastnat, en uppgradering som stannat eller en SCC som blockerar en release. Ett avgränsat uppdrag har ett tydligt slut, till exempel ett versionslyft eller en städning av namnrymder, undantag och gamla Operators. Full drift betyder att vi äger rutinen: övervakning, uppgraderingar och ändringsloggen.

Migrera till – eller från – OpenShift

Vanliga hinder när arbetslaster ska in i OpenShift: processer som förväntar sig köra som root, images utan rätt användare, skillnaden mellan Ingress och Routes, och SCC som stoppar det som "fungerade i vanilla Kubernetes". Vi kartlägger beroenden, bygger om det som måste byggas om och migrerar stegvis med parallelldrift och tydliga vägar tillbaka.

Kartläggningen tar fram vilka images som kör som root, vilka som saknar en numerisk användare och vilka tjänster som beror på Ingress-objekt i stället för Routes. Det som måste byggas om byggs om innan flytten. Parallelldrift betyder att den gamla vägen finns kvar tills den nya har tagit trafik, och att det finns en utpekad väg tillbaka om ett steg inte håller.

Samma disciplin gäller åt andra hållet: om ni lämnar OpenShift för Rancher eller managed Kubernetes tar vi med policyer, pipelines och observation så att ni inte tappar kontrollen på vägen. Jämförelsen mellan plattformarna finns längre ner, och drift av Linux under klustret är en del av samma arbete.

OpenShift i reglerade miljöer

I reglerade och säkerhetskritiska miljöer räcker det inte att klustret svarar. Det ska gå att visa vem som ändrade vad, vilka images som körs och hur uppgraderingar har godkänts. OpenShift ger bra byggstenar för det (RHCOS på kontrollplan, inbyggda Operators för compliance och logging, tydlig livscykel). Vi kopplar dem till er förändringshantering och till de tekniska kontroller ni behöver kunna visa upp under compliance-arbetet.

Vi har erfarenhet från skarp plattformsdrift i högt reglerad miljö (bland annat Rancher-hanterad Kubernetes på SUSE Linux åt danska försvaret, beskrivet i våra kundcase) och tar med samma disciplin till OpenShift-uppdrag: kontrollerad förändring, spårbarhet och livscykel.

RHCOS på kontrollplanet följer produktens livscykel, så nodernas uppgraderingar planeras tillsammans med klustrets. Vi skiljer på det plattformen redan loggar och det er förändringshantering behöver utöver det: vem som godkände lyftet, vilka images som var tillåtna och hur ett undantag stängs.

OpenShift eller Rancher?

OpenShift passar när ni vill ha en mer sammanhållen produkt med fler inbyggda komponenter och en tydlig supportväg från Red Hat. Rancher är ofta starkare när ni har många kluster i blandade miljöer och vill styra dem enhetligt. Vi arbetar med båda och har ingen anledning att sälja in det ena. Jämförelsen finns i artikeln SUSE Rancher vs OpenShift. Rancher-sidan: SUSE Rancher-konsult.

Valet är sällan en smakfråga. Har ni en Red Hat-standard, få kluster och vill ha console, routes och Operators i samma produkt, lutar det åt OpenShift. Har ni många kluster i blandade miljöer, inklusive kluster ni inte själva byggt, lutar det åt Rancher. Vi tar fram den jämförelsen mot er miljö innan någon licens beställs.

Vanliga frågor