Efter uppgradering

Vissa uppgraderingar slutar med ett steg som plattformen inte kan ta själv: objekten det gäller begränsar vad plattformen får göra, och en identitet som kunde skapa dem skulle också kunna lyfta begränsningarna. Fliken Efter uppgradering under Inställningar → Livscykelhantering samlar de här stegen. Så länge något återstår visar fliken en siffra, och en påminnelse överst på varje sida länkar dit:

Plattformen fortsätter fungera medan de väntar — och just därför är de lätta att glömma.

Plattformens administratörspaket

En releases administratörspaket innehåller de klusterobjekt som avgränsar konton med breda rättigheter: kontot som uppgraderingar av tredjepartscharts körs som och den admission policy som låser det, admission-skydden, och en behörighet som låter Lifecycle-modulen läsa dem. Bara en klusteradministratör kan tillämpa det — en gång när plattformen installeras, och igen när en release ändrar det.

När den körda releasens paket inte finns helt på plats börjar fliken med avsnittet Plattformens administratörspaket: vad som saknas, varför plattformen behöver det, och kommandot, med Kopiera:

kubectl apply --server-side --field-manager=stackship-installer --force-conflicts -f <release URL>/platform-admin.yaml

Portalen visar den exakta URL:en. Lämna kommandot till en klusteradministratör, som kör det med en cluster-admin-kubeconfig. Det är säkert att tillämpa det igen, och det tar tillbaka fält som någon har ändrat för hand. Plattformen jämför paketet med klustret var femte minut, så avsnittet och påminnelsen försvinner av sig själva när det har tillämpats. Varje objekt listas som Finns, Saknas, Ändrat för hand eller Går inte att läsa — se Statusar.

En releaseutrullning som behöver paketet kan inte starta utan det: dess kontroll före uppgradering release.prerequisites kan inte åsidosättas.

Inställningar ändrade för hand

Avsnittet Plattformsavvikelser visar den senaste kontrollen av plattformsinställningar som någon har ändrat direkt i klustret, med Kontrollera nu och Adoptera i konfigurationen — se Inställningar ändrade för hand.

Tillämpa behörighetsrollerna

Plattformen skriver Kubernetes-roller för de personer och arbetslaster den ger åtkomst, under ett behörighetstak som den inte kan vidga själv — se Behörighetstaket. När en release ändrar taket måste någon som redan har reglerna tillämpa det.

1. Öppna fliken Efter uppgradering. Tabellen Kluster listar varje kluster med kolumnerna Status, Senast tillämpat och Detalj. Vad varje status betyder finns i Statusar.
2. Välj eventuellt Visa manifestet för att ladda ner den YAML som kommer att tillämpas.
3. Välj Tillämpa på alla kluster. Det kräver rbac/projector/apply på plattformens rot. Manifestet skickas till varje kluster med dina egna uppgifter, varje klusters API-server avgör vad du får skriva, och ändringen registreras på ditt namn, inte plattformens. I praktiken innebär det rollen Platform Owner.
4. När ett kluster visar Kräver en klusteradministratör lägger releasen till regler som inget konto i klustret har än. Fliken listar reglerna som saknas och kommandona, med Kopiera. En klusteradministratör kör dem en gång med en cluster-admin-kubeconfig; klustret visar sedan Klart — tillämpa igen för att registrera, och ytterligare en Tillämpa på alla kluster registrerar det.

Manifestet är detsamma för alla kluster, och att tillämpa det två gånger ändrar ingenting. När fliken dessutom säger Åtkomstgränser tillämpas inte än skriver plattformen fortfarande åtkomst med sitt eget konto i stället för det begränsade; åtkomsten fungerar i båda fallen, och att tillämpa byter över inom några minuter, utan omstart.

Om en del nekas

Ingenting går sönder: varje objekt i manifestet lägger till något, så ett kluster som missade några saknar delar i stället för att bära trasiga. Fliken listar vilka objekt som inte kom fram till vilket kluster, och varför:

• Nekat som förbjudet — ditt konto har ännu inte rollen Platform Owner i det klustret, som på ett kluster som sätts upp för första gången. Tillämpa manifestet där en gång med en cluster-admin-kubeconfig; därefter kan fliken underhålla det.
• Nekat att vidga behörighetstaket — releasen lägger till regler som inget konto i klustret har än, och klustret visar Kräver en klusteradministratör; se steg 4 ovan.
• Åtkomstpolicyer stöds inte — klustrets API-server stöder inte de admissionregistration.k8s.io/v1-policyer som manifestet använder som skydd, vilket kräver Kubernetes 1.30 eller senare. Allt annat fungerar utan dem. Uppgradera klustret och tillämpa igen.
• Tidigare Kyverno-policyer finns kvar — de Kyverno ClusterPolicies som tidigare bar samma skydd togs inte bort. De upprätthåller samma regler, så ingenting är oskyddat; en klusteradministratör tar bort dem, eller så tillämpar du igen när de andra nekandena är lösta.
• Går inte att nå — klustret kunde inte nås. Kontrollera att dess agent körs och tillämpa sedan igen.

Tillämpa igen så ofta du behöver. Kluster som redan har lyckats lämnas som de är.