Capaciteit en reserve

Een hoog beschikbare gehoste besturing vraagt circa 78 pods, 5 processorkernen, 18 GiB geheugen, drie etcd-volumes van 8 GiB en één API-adres (de aangevraagde middelen volgens de leveranciersdocumentatie). Vijf besturingen plus 50 tot 60 eigen pods blijven op een werkerknooppunt onder de 500 pods, terwijl zij maar 25 van de 128 kernen en 90 GiB van de 1,5 TB geheugen vragen.

Het clusterbeheer zet maxPods op 500 per werkerknooppunt (KubeletConfig), het door de leverancier aanbevolen maximum, en nooit hoger. Dat geeft vijf besturingen per werkerknooppunt: tien plaatsen bij drie werkerknooppunten, met de middelen van één werkerknooppunt als reserve, en 24 bij zes. Groei gaat via extra werkerknooppunten van hetzelfde type, niet via een hogere dichtheid; het aantal besturingsknooppunten blijft drie.

Van de tien plaatsen in cel 1 zijn er twee voor het bouwcluster en het portaalcluster, één voor de herstelomgeving en zeven voor applicatieclusters van teams, waaronder de proefgroep: clusters van teams die dat afspraken, te beginnen met dat van de testtoepassing van het eerste applicatieteam. Het besturingscluster van het dienstennetwerk telt mee vanaf zijn ingebruikname, en vanaf groeipadstap 3 komt er per profiel een plaats voor de gedeelde databasevoorziening bij. De beleidstoetsing telt de plaatsen.

De reserve van het clusterbeheer (de middelen van één werkerknooppunt, de plaats voor de herstelomgeving en de koude reserveserver) wordt niet uitgegeven. Een nieuwe besturing komt er alleen bij als na uitval van één werkerknooppunt alles nog past; anders weigert de beleidstoetsing de aanvraag, met uitleg.

De koude reserveserver van het clusterbeheer is het vervangknooppunt na blijvend verlies van een werkerknooppunt, en tegelijk schone rekenkracht voor de herstelkern. Wordt zij ingezet, dan wordt direct een nieuwe besteld.

Het clusterbeheer zet bij 80 procent van de plaatsen een uitbreiding in gang en bevriest bij volle bezetting, zodat de levertijd van servers erin past en de reserve vrij blijft. De overige grenzen en acties staan in de tabel.

Iedere groeistap van het clusterbeheer vraagt werkerknooppunten van hetzelfde type, poorten op het leaf-paar, adressen in VLAN 610 en 622, een serverprofiel met de firmwarebasislijn en een herhaalde dichtheids- en uitvalproef. Cel 2 komt uit dezelfde code, met eigen VLAN-reeksen; binnen een cluster blijft het IPv4. Buiten het clusterbeheer liggen andere grenzen: ten hoogste 1.000 clustersegmenten per cel in de fabric en circa 200 clusters per opslagcluster.

Bij de acceptatie van het clusterbeheer worden het pod-, volume-, processor- en geheugenbudget per knooppunt onder belasting gemeten, met de overhead en de reserve voor onderhoud en uitval. De meting moet aantonen dat een werkerknooppunt vijf besturingen met reserve draagt. De leeromgeving bewijst alleen werking en volgorde, geen prestaties.

Een applicatiecluster heeft 2 tot 8 werkers in het profiel ontwikkelen en beproeven en 3 tot 8 in reguliere en bedrijfskritische productie, bij bedrijfskritische productie per cel. Het quotum rekent met het maximum plus één werker. Een groter cluster kan alleen met een ontwerpbesluit.

Het maximumaantal werkers plus één past in het teamquotum en in de gereserveerde capaciteit van de werkervirtualisatie. Het quotum op de infra-naamruimte is dat aantal maal de werkermaat, met een rootvolume van 64 GiB per werker. Een aanvraag die de reserve aantast, wordt geweigerd, en de uitgegeven opslagquota blijven samen onder 75 procent van de bruikbare capaciteit.

In bedrijfskritische productie geldt voor werkers dezelfde processorverhouding als in reguliere productie: 2 vCPU per fysieke kern. Het profiel verschilt door het tweede exemplaar in de andere cel, niet door de processor, en rekent dus als reguliere productie.

Voor applicatieclusters grijpt het platform in vóór de harde grens. De actiedrempels zijn pods die 15 minuten wachten op het maximum, 85 procent van een quotum en 6.000 regels in een EgressFirewall; voor de standaardinrichting ook een geheimenkoppeling die 1 uur niet synchroniseert en een compliancescan die ouder is dan 8 dagen. De grenzen en acties staan in de tabel.

Het aanbod applicatieclusters begint in cel 1 klein en groeit langs het groeipad, zoals de tabel laat zien.

De reserve van de werkervirtualisatie, één werkerknooppunt, draagt uitval, onderhoud, de werkers van de herstelomgeving en vanaf groeipadstap 2 de overname van diensten in bedrijfskritische productie. Zij draagt geen nieuwe clusters.

Het gebruik van het clusterbeheer wordt per gehost cluster gemeten, en de toegewezen en gebruikte capaciteit per cluster is zichtbaar voor kostenbeheer.