Hoppa till innehållet
Stackship-dokumentation English

ContainerinstanserAnvändareMaskinöversatt

Containerinstanser

Kör färdigbyggda containeravbilder som en hanterad tjänst — en eller flera komponenter, var och en sin egen podd, som bara nås utifrån via de slutpunkter du lägger till.

En containerinstans kör containeravbilder som redan är byggda — från ett publikt register eller ett privat — som en hanterad tjänst. Det finns inget byggsteg: du anger en avbild och en tagg, och plattformen kör den, håller den igång och ger den en adress. När plattformen ska bygga din kod från ett förråd använder du en app i stället.

Komponenter och containrar

  • En instans består av en eller flera komponenter. En komponent är en podd: dess containrar delar nätverksadress, volymer och livscykel, och den dimensioneras, skalas och startas om som en enhet.
  • En komponent kör en eller flera containrar, och eventuellt init-containrar, som körs klart, en i taget, innan huvudcontainrarna startar.
  • Guiden för att skapa en instans gör en instans med en komponent, main, som kör en container. Fler komponenter och containrar kan läggas till på instansens flik Komponenter. En instans som driftsatts från en blueprint har oftast flera.

En ändring av en komponent ersätter bara den komponentens poddar; de andra fortsätter köra.

Startvågor

Varje komponent har en startvåg, ett tal från 1 och uppåt. Plattformen startar komponenterna våg för våg, lägsta först, och startar en våg först när alla komponenter i vågorna före den är redo — så att en gateway inte startas innan databasen den pratar med tar emot anslutningar. En komponent som har fallerat på ett sätt som väntan inte löser — en kraschloop, en avbild som inte går att hämta, ingen plats att schemalägga den, lagring som inte går att koppla in — håller inte tillbaka de senare vågorna. En komponent vars poddar kör men aldrig blir redo gör det: de senare vågorna väntar så länge den inte är redo.

Medan en våg väntar visar instansens Översikt dess nummer som Startar våg, och komponenter i senare vågor rapporterar att de startar även när deras poddar redan kör. Slutpunkter uppdateras först när alla vågor är uppe.

Avbilder och uppdateringar

När en komponent driftsätts slår plattformen upp innehållets digest bakom varje avbildstagg och kör exakt den avbilden. Att pusha en ny avbild under samma tagg — till exempel latest — ändrar därför ingenting i sig. Distribuera om komponenten, eller Starta om instansen, så slås taggen upp igen. Går registret inte att nå vid driftsättningen kör komponenten taggen som den är, och plattformen fortsätter fråga; när registret svarar ersätts poddarna med den avbild taggen då pekar på. Avbilder i ett privat register hämtas med en distributionskällas inloggningsuppgifter; se Avbildning.

Beredskap

En komponent är redo när dess poddar är det. En huvudcontainer som deklarerar exakt en port, en TCP-port, och ingen egen beredskapsprob kontrolleras på den porten: den räknas som redo när porten tar emot anslutningar. Egna prober sätts via API:et eller en blueprintmall; portalen redigerar dem inte.

Hur en instans nås

  • Inom boundaryn. En komponent som deklarerar portar får klusternamnet <instance>-<component>, som svarar på varje port den deklarerar. Andra arbetslaster i samma resursgrupp når den med det namnet. Boundaryns nätverksregler avgör vad som får ansluta: varje arbetslast i boundaryn, i vilken av dess resursgrupper som helst, och klustrets ingress-kontroller, på vilken port som helst.
  • Från utanför klustret. Bara via en slutpunkt: ett HTTPS-värdnamn, eller en adress från en lastbalanserare för rå TCP eller UDP. En instans utan slutpunkter är endast intern. Se Slutpunkter.
  • Via en slutpunkt med lastbalanserare. Dess port är undantagen från boundaryns regler: den släpper in alla källor, arbetslaster i andra boundaries inräknade, utan någon lista över tillåtna adresser — se Slutpunkter med lastbalanserare.

Utåt kan en arbetslast öppna TCP 443 mot vilken adress som helst och TCP 6443, Kubernetes API:s port; andra portar mot adresser utanför klustret är blockerade — se Vad reglerna tillåter.

Lagring

En komponent kan deklarera volymer och montera dem i sina containrar:

  • Beständig — en disk som överlever omstarter. En komponent med en sådan kör högst en replik. Som standard behålls disken när instansen tas bort.
  • Tillfällig — arbetsyta som komponentens containrar delar, som försvinner med podden.
  • Filer — filer vars innehåll är en del av instansens konfiguration, till exempel en konfigurationsfil eller ett init-skript. Innehåll som markerats som känsligt lagras som en hemlighet och döljs när instansen läses.

Volymer deklareras via API:et, CLI:t eller en blueprintmall — se Lägg till volymer och filer. Beständiga volymer kan bläddras på fliken Filer och säkerhetskopieras med ögonblicksbilder.

Identitet och hemligheter

Varje instans får en managed identity som alla dess komponenter delar. Plattformen använder den för att hämta de valvhemligheter containrarna refererar till, och din kod kan använda den för att hämta token — se Använd en managed identity i kod. Hur en container får en valvhemlighet som miljövariabel beskrivs i Hemligheter i container instances.

Varning

Valvhemligheter levereras per komponent, inte per container. Så snart en container i en komponent refererar till en valvhemlighet kan varje container i komponenten — init-containrar inräknade — läsa alla komponentens hemliga värden i filen /secrets/env.json, och varje container som anger ett kommando eller argument får dessutom alla som miljövariabler. Lägg en container som inte får se hemligheterna i en egen komponent.

Statusar

En instans är Creating, Updating, Running, Degraded, Error eller Stopped; den sämsta komponenten avgör. Vad varje status betyder finns i Statusar.

Sidor