Onderwerp
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
Het vlootoverzicht is één beeld van de hele vloot: welke clusters beschikbaar zijn, hoeveel capaciteit ze gebruiken en hoe gezond ze zijn. Het vlootbeheer haalt daarvoor van ieder cluster een vaste selectie samengevatte metingen op, met een kleine verzamelaar per cluster en eigen verwerkings- en opslagcapaciteit op het vlootcluster. De historie staat in de objectopslag van cel 1.
Het vlootbeheer heeft de observability al in huis, zodat de eerste levering een vlootoverzicht krijgt zonder te wachten op nieuwe apparatuur. Een vaste lijst begrenst het volume en daarmee de opslag. Omdat het overzicht geen schakel is in de meldingsroute, raakt uitval ervan alleen het overzicht en de historie, niet de signalering per cluster.
Het vlootoverzicht draait op het vlootcluster met de observability van Red Hat Advanced Cluster Management, met Thanos voor de historie en Grafana voor de dashboards. Het haalt van alle clusters een vaste selectie samengevatte metingen op en toont één overzicht van beschikbaarheid, capaciteit en gezondheid van de vloot.
Perses-dashboards zijn in deze observability nog Technology Preview en worden daarom in de eerste levering niet gebruikt.
De eerste levering werkt met wat het platform al heeft: de bewaking per cluster en de samengevatte metingen in het vlootbeheer, dat de observability al in huis heeft. Er wordt niet gewacht op nieuwe apparatuur; de eigen bewakingsvoorziening, met logopslag en een historie van verkeersstromen, volgt in groeipadstap 2.
Afgewezen alternatief: een tijdelijk bewakingscluster als gehost cluster met eigen werkers en logopslag. Dat vraagt voor een voorziening die weer verdwijnt drie grote virtuele werkers en terabytes aan opslag, en valt uit met het clusterbeheer of de werkervirtualisatie.
Een nieuw cluster krijgt de verzamelaar van het vlootoverzicht, de bewaking en de doorsturing zonder handeling via het vlootbeheer, en staat binnen 30 minuten na zijn aansluiting in het vlootoverzicht.
Eén inrichting voor alle clusters; de termijn is gelijk aan de aansluittermijn van het vlootbeheer. Voorwaarde bij de acceptatie: de leverancier ondersteunt de observability-addon op gehoste clusters met KubeVirt-infrastructuur, ook in tussenliggende upgradecombinaties. Zonder addon blijven de metingen van een gehost cluster in zijn eigen bewaking en toont het vlootoverzicht alleen zijn status.
De samengevatte metingen staan in een eigen bucket van 200 GB in de realm platform van de objectopslag van cel 1; het geheim van die bucket komt via External Secrets uit het geheimenbeheer. Ruwe metingen blijven 7 dagen bewaard, per 5 minuten samengevatte metingen 30 dagen en per uur samengevatte metingen 90 dagen.
De bucket gebruikt HTTPS met het certificaat van de objectgateway en staat in rust op de versleutelde schijven van het opslagcluster. Een certificaatketen buiten de tussen-CA van de cel is een afwijking met reden.
Het vlootbeheer haalt alleen de metingen van de vaste lijst op. De lijst staat als code in versiebeheer; uitbreiding gaat via een wijzigingsvoorstel met een schatting van het volume.
Zo blijft de opslag begrensd; de drempel op de ruimte bewaakt het volume.
De vaste lijst bevat de beschikbaarheid van API en applicatie-ingang, de capaciteit en gezondheid per cluster, de opslagbezetting per cluster en de afleverstatus van Alertmanager, en voor de beheerde database de beschikbaarheid, de replicatievertraging en de back-upstatus.
De drempels voor de beheerde database horen bij Beheerde databases & koppelingen. Nieuwe knooppuntsoorten krijgen vanaf groeipadstap 3 hun metingen in de vaste lijst.
Bij 65 procent van de 200 GB krijgt platformbeheer een melding, gelijk aan de grens voor het vlootcluster; het kort dan de vaste lijst in of vraagt meer ruimte aan. Meer ruimte is een quotumaanvraag bij opslagbeheer, binnen de grenzen van het opslagcluster.
Het volume volgt het aantal clusters en de lengte van de vaste lijst. Bij de uitbreiding naar 24 gehoste clusters in cel 1 worden ruimte en volume herijkt.
Valt het vlootoverzicht uit, dan detecteren de lokale metingen een fout of grensoverschrijding en routeert de Alertmanager van het cluster de melding op eigenaar en profiel, zonder tussenkomst van het vlootbeheer. Beheer gebruikt die lokale signalen en herstelt het overzicht. In de eerste levering is er dan geen volledige centrale historie: ontbrekende meetperioden worden als onbekend weergegeven.
Het gebruik van processor, geheugen en opslag is per dienst en per afnemer uit de samengevatte metingen te halen. Vanaf groeipadstap 3 zijn zij de basis voor de kostentoerekening per dienst door het kostenbeheer.
Beproefd in de toets kosten en gebruik per dienst.
In de eerste levering bewaakt het vlootoverzicht ten hoogste 14 clusters: het vlootcluster, het basisdienstencluster, de werkervirtualisatie, het clusterbeheer en tien plaatsen voor gehoste clusters, namelijk het bouwcluster, het portaalcluster, zeven clusters voor teams en één voor de herstelomgeving. Na uitbreiding van het clusterbeheer zijn er 24 gehoste clusters per cel. In groeipadstap 2 krijgt cel 2 dezelfde inrichting en toont het vlootoverzicht beide cellen; in groeipadstap 4 sluiten nieuwe clusterdiensten aan via dezelfde standaardinrichting.