Onderwerp
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
De clusterdefinitie beschrijft één applicatiecluster: een HostedCluster voor de besturing op het clusterbeheer en een of meer NodePools voor de werkers op de werkervirtualisatie. Het leverpad genereert haar uit het sjabloon en de dienstbeschrijving van het team en legt haar vast in versiebeheer; het clusterbeheer voert haar uit. Het sjabloon bevat de vaste waarden en de weinige keuzes die een team heeft, en de koppeling met de werkervirtualisatie: een eigen infra-naamruimte, identiteit, netwerk en quotum per cluster.
Clusters die uit dezelfde keuzes zijn opgebouwd, kan het platform automatisch toetsen, bijwerken, bewaken en herstellen. Iedere vrije keuze is een variant die beproefd en onderhouden moet worden, en een aantal velden is na het aanmaken niet meer te wijzigen. Daarom legt dit voorstel de onveranderbare velden vooraf vast, laat het de beleidstoetsing ze controleren vóór een cluster ontstaat, en houdt het de opslag van teams buiten de werkervirtualisatie, zodat ieder cluster een eigen ruimte en eigen sleutels op het opslagcluster heeft.
Een applicatieteam neemt zijn cluster af als dienst: een applicatiecluster ontstaat, wijzigt en verdwijnt alleen via de dienstbeschrijving van het team en de clusterdefinitie die het platform daaruit genereert, zonder handwerk.
Zo blijft ieder cluster herleidbaar. De toetsen Levering via het vaste pad en Wijziging en beëindiging via de dienstbeschrijving tonen het aan; een wijziging buiten versiebeheer meldt een detectieregel.
Het leverpad genereert per cluster een HostedCluster en een of meer NodePools uit het sjabloon en de dienstbeschrijving (hcp create cluster kubevirt, in render-modus) en legt ze via een wijzigingsvoorstel vast in clusters/<naam>/ van de opslagplaats Platform. Het vrijgegeven releasebeeld (op inhoudskenmerk), de werkermaat, de quota en het onderhoudsvenster komen uit de dienstbeschrijving; geheimen staan er alleen als verwijzing in. Het clusterbeheer en iedere clusterdefinitie komen uit die opslagplaats, en een afwijking wordt binnen 5 minuten gemeld en teruggezet.
Een clusterdefinitie wordt alleen samengevoegd na een geslaagde beleidstoetsing op die vastlegging, als standaardwijziging of na goedkeuring door twee beoordelaars naast de auteur.
Takbeveiliging dwingt dat af; een proef met een afwijkende definitie toont de weigering aan.
Ieder cluster staat in de inventaris met eigenaar, profiel, versie, uitrolgolf, API-adres, VLAN en sleutelversie, binnen 1 dag bijgewerkt. Per afname worden daarnaast de adresreeks van de NodePool en de infra-identiteit op de werkervirtualisatie geregistreerd. Een adres of VLAN dat niet in NetBox staat, wordt niet gebruikt.
Een dagelijks verschilrapport vergelijkt de inventaris met de werkelijke toestand.
Clusterdefinitie en standaardinrichting zijn Kubernetes-objecten in YAML onder versiebeheer; HostedCluster en NodePool zijn vastgelegd als leverancierspecifieke uitbreiding. De applicatie-identiteit volgt SPIFFE, de aanmelding OpenID Connect, en de audit gaat als syslog volgens RFC 5424.
Zo blijft de configuratie overdraagbaar; iedere sjabloonversie wordt daarop beoordeeld.
Het sjabloon voor clusters als dienst kent bewust weinig keuzes: alleen de standaardnetwerkvariant en virtuele werkers, met de keuzes die hieronder staan. Alles daarbuiten is een afwijking die een beoordeling vraagt.
Omdat alle clusters uit dezelfde keuzes zijn opgebouwd, kan het platform ze automatisch toetsen, bewaken en herstellen; ieder extra veld is een variant die het moet beproeven en onderhouden. Alternatief: een vrij in te vullen clusterdefinitie. Dat verplaatst het werk alleen: iedere aanvraag vraagt dan een eigen beoordeling en de clusters gaan verschillen, zodat automatisering met één beproefde inrichting niet meer lukt. Een vrije keuze past alleen als afwijking met beoordeling.
Het sjabloon laat in de eerste levering alleen deze keuzes open, elk met degene die haar bepaalt.
| Keuze | Mogelijkheden in de eerste levering | Bepaald door |
|---|---|---|
| Versie | Door het platform vrijgegeven versies, binnen de ondersteuningstermijn en in een door de leverancier bevestigde combinatie met clusterbeheer en werkervirtualisatie | Platform |
| Capaciteit | Werkers in drie vaste maten, met een minimum- en maximumaantal; het maximum binnen de gereserveerde capaciteit van de werkervirtualisatie, gerekend met de processorverhouding per fysieke kern | Team, binnen het quotum |
| Profiel | Ontwikkelen en beproeven; reguliere productie pas na de vrijgave | Proceseigenaar |
| Netwerk | Standaardvariant, met een ingang via de externe verkeersverdeling | Platform en netwerkbeheer |
| Opslag | Opslagklassen van de prestatielaag ‘normaal’: blokopslag als standaard, bestandsopslag alleen voor gedeelde toegang (databases gebruiken blokopslag); quotum per cluster op de aangevraagde capaciteit; objectopslag als dienst via het platform | Team, binnen het quotum |
| Koppelingen | Gedeclareerde verbindingen na zonecontrole | Team, binnen de varianten |
| Onderhoudsvenster | Vaste vensters voor updates van besturing en werkers | Team, uit het aanbod |
De beleidstoetsing weigert een dienstbeschrijving of clusterdefinitie met een keuze buiten het sjabloon, een niet-vrijgegeven versie, een niet-toegestane zone of een maximum buiten het quotum.
Zo blijven er weinig varianten; een proef met zulke aanvragen toont de weigering aan.
Ieder team krijgt per dienstprofiel een eigen cluster, in het routeringsdomein van dat profiel. Het profiel ligt vast bij het aanmaken; een ander profiel vraagt een nieuw cluster.
Iedere clusterdefinitie bestaat uit een HostedCluster en een of meer NodePools met de vaste waarden en keuzes hieronder. De laatste kolom zegt wat na het aanmaken nog kan wijzigen.
| Onderdeel | Invulling | Bepaald door | Na aanmaak |
|---|---|---|---|
| Naam en naamruimte | Naam volgens de naamgeving van de cel, zoals onderhoud-ont-c1-01; een eigen naamruimte op het clusterbeheer, nooit met de naam clusters | Platform | Vast |
| Platform | KubeVirt met externe infrastructuur: verwijzing naar de infra-kubeconfig in het geheimenbeheer en naar de infra-naamruimte clusters-<naam> op de werkervirtualisatie | Platform | Onveranderbaar |
| Beschikbaarheid | controllerAvailabilityPolicy en infrastructureAvailabilityPolicy HighlyAvailable, beide expliciet, ook in het profiel ontwikkelen en beproeven | Platform | Onveranderbaar |
| etcd | Beheerd; drie stemmers met gereserveerde middelen, ieder op een volume van 8 GiB met opslagklasse lvms-<deviceClass> op het clusterbeheer | Platform | Onveranderbaar |
| Versleuteling | secretEncryption aescbc met een eigen sleutel per cluster uit OpenBao | Platform | Sleutel vervangbaar |
| Publicatie | APIServer als LoadBalancer (MetalLB op het clusterbeheer) met vaste hostnaam api.<naam>.<cel>.dc3.internal; OAuthServer als route met vaste hostnaam oauth.<naam>.<cel>.dc3.internal; Konnectivity en Ignition als routes op het clusterbeheer | Platform | Onveranderbaar |
| Versie | Releasebeeld uit de eigen containerregistry, vastgelegd op inhoudskenmerk | Team kiest uit de vrijgegeven versies | Per update |
| Configuratie van het gastcluster | Auditprofiel WriteRequestBodies, TLS-profiel via de configuratie van de API-server, aanmelding via OAuth met Keycloak; bij een applicatiecluster ook de aanmeldroute van de teampool als tweede identiteitsaanbieder, als enige met de groep <cel>-<team>-verhoogd | Platform | Alleen in de definitie |
| Werkers | NodePool met cores en memory uit maat S, M of L (geheugen als getal in GiB), met minimum- en maximumaantal; rootvolume van 64 GiB op de RBD-klasse van de werkervirtualisatie, in blokmodus met gedeelde toegang; verspreid over de rekken | Team, binnen het quotum | Via de dienstbeschrijving |
| Werkervervanging | upgradeType Replace, maxSurge 1, maxUnavailable 0 | Platform | Onveranderbaar |
| Netwerken van de werkers | attach-default-network false; eerst het localnet-netwerk van het cluster, alleen bij volumes daarna het opslagclientnetwerk | Netwerkbeheer wijst VLAN en reeksen toe; de dienstbeschrijving legt vast of er volumes zijn | Vast |
| Opslag in het gastcluster | storageDriver None; alleen clusters in de herstelzone storageDriver Manual met de gastklasse van de werkervirtualisatie | Platform | Onveranderbaar |
| Interne adresreeksen | Vaste reeksen voor pods en services, gelijk voor alle gastclusters en buiten de adresreeksen van het datacenternetwerk | Platform | Vast |
| Geheimen | Alleen verwijzingen, via External Secrets | Platform | Vervangbaar |
| Kenmerken en venster | Labels cel, functie, profiel en uitrolgolf; onderhoudsvenster uit het aanbod | Team kiest profiel en venster | Profiel vast |
De vaste hostnamen zijn nodig voor herstel. Beide beschikbaarheidsvelden worden expliciet gezet, omdat zij onveranderbaar zijn. Zonder het standaardnetwerk van de werkervirtualisatie zitten de werkers niet op haar clusternetwerk en bereiken zij haar API niet.
Velden die na het aanmaken niet meer te wijzigen zijn, zoals de publicatie van de besturing, de beschikbaarheid, de opslag van etcd, de werkervervanging en de opslag in het gastcluster, liggen vast in het sjabloon. De beleidstoetsing controleert ze vóór het aanmaken en weigert een afwijkend onveranderbaar veld; een andere keuze vraagt een nieuw cluster, waarnaar de toepassingen verhuizen. Iedere besturing is HighlyAvailable, ook in het profiel ontwikkelen en beproeven.
Alternatief: SingleReplica voor ontwikkelen en beproeven, met meer besturingen per werkerknooppunt. Dan legt uitval van één werkerknooppunt die besturingen stil, en omdat het veld onveranderbaar is, vraagt de stap naar reguliere productie een nieuw cluster. SingleReplica past alleen in de leeromgeving. De beleidstoetsing en het beleid op het clusterbeheer tonen de naleving aan.
De instellingen van een gehost cluster, zoals die van OAuth en de API-server, worden in de clusterdefinitie op het clusterbeheer beheerd. Een wijziging van besturingsinstellingen in het gastcluster zelf wordt teruggezet.
Per gehost cluster maakt de automatisering op de werkervirtualisatie de naamruimte clusters-<naam>, een technische identiteit met rechten alleen daarin en het gedeclareerde netwerk met het VLAN uit de registratie. De kubeconfig van die identiteit staat alleen in het geheimenbeheer en komt via External Secrets op het clusterbeheer. Het sjabloon maakt haar verplicht, want zonder haar komen de werkers op het clusterbeheer terecht. Het quotum op de infra-naamruimte begrenst de werkers op het maximum uit de dienstbeschrijving plus één.
De technische identiteit van een cluster heeft op de werkervirtualisatie een rol in de eigen infra-naamruimte voor virtuele machines, datavolumes, services, routes, endpointslices, netwerkbeleid en momentopnamen, plus leesrecht op de netwerkconfiguratie. Een negatieve proef toont aan dat zij buiten die naamruimte niets bereikt.
De rol volgt het voorbeeld in de upstreamdocumentatie, dat geen ondersteuningsverklaring is. Daarom is zij een acceptatiecriterium, met als terugvaloptie de standaardrol admin, alleen in de infra-naamruimte.
Werkers staan niet op het standaardnetwerk van de werkervirtualisatie (attach-default-network false). Hun eerste aansluiting is het localnet-netwerk van het eigen cluster: voor een applicatiecluster een VLAN uit 1000–1999, voor een gehost platformcluster uit 700–709 en in de herstelzone VLAN 690. Alleen een cluster met volumes buiten de herstelzone krijgt als tweede aansluiting het opslagclientnetwerk (VLAN 620). De netwerkdefinities hebben geen adresbeheer: op het eigen segment krijgen werkers hun adres via DHCP-doorgifte naar Infoblox, op VLAN 620 en 690 een statisch adres in de netwerkconfiguratie van de NodePool.
Een statisch adres komt uit een reeks per cluster van het maximumaantal werkers plus één, die het leverpad vóór de werkers in Infoblox en NetBox reserveert en na beëindiging vrijgeeft. Reden: zonder adresbeheer in de netwerkdefinities is er op VLAN 620 geen andere uitgifte, en uit de herstelzone loopt geen DHCP-stroom.
Teams krijgen geen opslag via de werkervirtualisatie: de clusterdefinitie koppelt geen gastklasse (storageDriver None), en de werkervirtualisatie draagt alleen de rootvolumes van de werkers. Een cluster met volumes koppelt via Data Foundation in externe modus rechtstreeks aan het opslagcluster, met een eigen ruimte en eigen sleutels; een cluster zonder volumes krijgt geen opslagkoppeling en geen aansluiting op VLAN 620. Alleen clusters in de herstelzone krijgen hun volumes via de gastklasse van de werkervirtualisatie (storageDriver Manual), zonder VLAN 620.
Alternatief: volumes van teams op de RBD-klasse van de werkervirtualisatie. Dat geeft geen eigen ruimte en sleutels per cluster en geen bestandsopslag. Het past alleen in de herstelzone, die zo geen pad naar de opslag van productie heeft; een daar teruggezet applicatiecluster krijgt een definitie met Manual, en zijn volumes gaan pas bij de terugkeer naar productie naar het opslagcluster. Gevolg: bijna iedere werker krijgt een aansluiting op VLAN 620. Dat storageDriver None werkt, is een acceptatiecriterium; de beleidstoetsing en een negatieve proef tonen de rest aan. De scheiding per afnemer op het opslagcluster zelf hoort bij het domein opslag.
Een cluster met volumes krijgt de opslagklassen normaal-blok (standaard) en normaal-bestand uit de koppeling in externe modus, met een RADOS-namespace en een subvolumegroep per cluster over VLAN 620. Een ResourceQuota per teamnaamruimte begrenst requests.storage per opslagklasse, samen ten hoogste het quotum uit de dienstbeschrijving; het feitelijke verbruik in de gedeelde pool wordt gemeten en gerapporteerd, niet per cluster hard begrensd. Er is geen objectopslagklasse en geen beheersleutel voor de objectopslag: objectopslag komt als dienst via de automatisering. Voor gedeelde bestandsvolumes liggen de SELinux-categorieën per naamruimte vast.