Distribuera ett Kubernetes-kluster med AKS-motorn på Azure Stack Hub

Artikel
10/30/2024

Du kan distribuera ett Kubernetes-kluster på Azure Stack Hub från en virtuell klientdator som kör AKS-motorn. I den här artikeln tittar vi på att skriva en klusterspecifikation, distribuera ett kluster med filen apimodel.json och kontrollera klustret genom att distribuera MySQL med Helm.

Definiera en klusterspecifikation

Du kan ange en klusterspecifikation i en dokumentfil med hjälp av JSON-formatet som kallas API-modellen. AKS-motorn använder en klusterspecifikation i API-modellen för att skapa klustret.

Du kan hitta exempel på API-modellen för ditt operativsystem och AKS-motorns versionsnummer för de senaste versionerna på AKS-motorn och motsvarande bildmappning.

Leta reda på aks-motorns versionsnummer, v.0.63.0till exempel , i tabellen.
I tabellen API-modellexempel väljer du och öppnar länken för operativsystemet.
Välj Rå. Du kan använda URL:en i följande instruktioner.

En URL till API-modellen kan se ut så här:

https://raw.githubusercontent.com/Azure/aks-engine-azurestack/master/examples/azure-stack/kubernetes-azurestack.json

Ersätt med URL:en för vart och ett av följande exempel <URL for the API Model> .

Uppdatera API-modellen

I det här avsnittet tittar vi på hur du skapar en API-modell för klustret.

Börja med att använda en Azure Stack Hub API-modellfil för Linux eller Windows. Från datorn installerade du AKS-motorn och kör:
```
curl -o kubernetes-azurestack.json <URL for the API Model>
```
Kommentar

Om du är frånkopplad kan du ladda ned filen och manuellt kopiera den till den frånkopplade datorn där du planerar att redigera den. Du kan kopiera filen till linux-datorn med hjälp av verktyg som PuTTY eller WinSCP.
Om du vill öppna API-modellen i en redigerare kan du använda nano:
```
nano ./kubernetes-azurestack.json
```
Kommentar

Om du inte har nano installerat kan du installera nano på Ubuntu: sudo apt-get install nano.
I filen kubernetes-azurestack.json hittar du orchestratorRelease och orchestratorVersion. Välj en av kubernetes-versionerna som stöds. du hittar versionstabellen i viktig information. orchestratorRelease Ange som x.xx och orchestratorVersion som x.xx.x. En lista över aktuella versioner finns i AKS-motorversioner som stöds
Leta upp customCloudProfile och ange URL:en till klientportalen. Exempel: https://portal.local.azurestack.external
Lägg till "identitySystem":"adfs" om du använder AD FS. Exempel:
```
    "customCloudProfile": {
        "portalURL": "https://portal.local.azurestack.external",
        "identitySystem": "adfs"
    },
```
Kommentar

Om du använder Microsoft Entra-ID för ditt identitetssystem behöver du inte lägga till fältet identitySystem .

I masterProfileanger du följande fält:

Fält	beskrivning
dnsPrefix	Ange en unik sträng som ska användas för att identifiera värdnamnet för virtuella datorer. Till exempel ett namn baserat på resursgruppens namn.
antal	Ange det antal original som du vill använda för distributionen. Minimivärdet för en HA-distribution är 3, men 1 tillåts för icke-HA-distributioner.
vmSize	Ange en storlek som stöds av Azure Stack Hub, till exempel `Standard_D2_v2`.
distro	Ange `aks-ubuntu-18.04` eller `aks-ubuntu-20.04`.

I agentPoolProfiles uppdatering:

Fält	beskrivning
antal	Ange det antal agenter som du vill använda för distributionen. Det maximala antalet noder som ska användas per prenumeration är 50. Om du distribuerar fler än ett kluster per prenumeration kontrollerar du att det totala antalet agenter inte överskrider 50. Se till att använda konfigurationsobjekten som anges i JSON-exempelfilen för API-modellen.
vmSize	Ange en storlek som stöds av Azure Stack Hub, till exempel `Standard_D2_v2`.
distro	Ange `aks-ubuntu-18.04`, `aks-ubuntu-20.04` eller `Windows`. Används `Windows` för agenter som ska köras i Windows. Se till exempel kubernetes-windows.json

I linuxProfile uppdatering:

Fält	beskrivning
adminUsername	Ange administratörsanvändarnamnet för den virtuella datorn.
ssh	Ange den offentliga nyckel som ska användas för SSH-autentisering med virtuella datorer. Använd `ssh-rsa` och sedan nyckeln. Anvisningar om hur du skapar en offentlig nyckel finns i Skapa en SSH-nyckel för Linux.

Om du distribuerar till ett anpassat virtuellt nätverk kan du hitta instruktioner för att hitta och lägga till nödvändig nyckel och värden i lämpliga matriser i API-modellen i Distribuera ett Kubernetes-kluster till ett anpassat virtuellt nätverk.

Kommentar

AKS-motorn för Azure Stack Hub tillåter inte att du anger egna certifikat för att skapa klustret.

Om du använder Windows windowsProfile uppdaterar du värdena adminUsername: för och adminPassword:
```
"windowsProfile": {
"adminUsername": "azureuser",
"adminPassword": "",
"sshEnabled": true
}
```

Mer information om API-modellen

En fullständig referens för alla tillgängliga alternativ i API-modellen finns i klusterdefinitionerna.
Information om specifika alternativ för Azure Stack Hub finns i definitionsspecifika azure Stack Hub-kluster.

Lägga till certifikat när du använder ASDK

Om du distribuerar ett kluster i Azure Stack Development Kit (ASDK) och använder Linux måste du lägga till rotcertifikatet i det betrodda certifikatarkivet för den virtuella klientdatorn som kör AKS-motorn.

Hitta rotcertifikatet på den virtuella datorn i den här katalogen: /var/lib/waagent/Certificates.pem.

Kopiera certifikatfilen:

sudo cp /var/lib/waagent/Certificates.pem /usr/local/share/ca-certificates/azurestacka.crt
sudo update-ca-certificates

Distribuera ett Kubernetes-kluster

När du har samlat in alla nödvändiga värden i API-modellen kan du skapa klustret. Nu bör du:

Be din Azure Stack Hub-operatör att:

Kontrollera systemets hälsotillstånd, föreslå körning Test-AzureStack och OEM-leverantörens maskinvaruövervakningsverktyg.
Kontrollera systemkapaciteten, inklusive resurser som minne, lagring och offentliga IP-adresser.
Ange information om den kvot som är associerad med din prenumeration så att du kan kontrollera att det fortfarande finns tillräckligt med utrymme för det antal virtuella datorer som du planerar att använda.

Fortsätt att distribuera ett kluster:

Granska de tillgängliga parametrarna för AKS-motorn på Azure Stack Hub CLI-flaggor.

Parameter	Exempel	beskrivning
azure-env	AzureStackCloud	Om du vill ange för AKS-motorn att målplattformen är Azure Stack Hub använder du `AzureStackCloud`.
identitetssystem	adfs	Valfritt. Ange din identitetshanteringslösning om du använder Active Directory Federated Services (AD FS).
plats	lokal	Regionnamnet för din Azure Stack Hub. För ASDK är regionen inställd på `local`.
resource-group	kube-rg	Ange namnet på en ny resursgrupp eller välj en befintlig resursgrupp. Resursnamnet måste vara alfanumeriskt och gemener.
api-modell	./kubernetes-azurestack.json	Sökväg till klusterkonfigurationsfilen eller API-modellen.
output-directory	kube-rg	Ange namnet på katalogen som ska innehålla utdatafilen apimodel.json och andra genererade filer.
klient-ID	xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx	Ange tjänstens huvudnamns-GUID. Klient-ID:t identifierades som program-ID när Azure Stack Hub-administratören skapade tjänstens huvudnamn.
klienthemlighet	xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx	Ange tjänstens huvudnamnshemlighet. Du konfigurerar klienthemligheten när du skapar tjänsten.
prenumerations-ID	xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx	Ange ditt prenumerations-ID. Du måste ange en prenumeration för klientorganisationen. Distribution till den administrativa prenumerationen stöds inte. Mer information finns i Prenumerera på ett erbjudande

Här är ett exempel:

Kommentar

För AKSe version 0.75.3 och senare är aks-engine-azurestack deploykommandot för att distribuera ett AKS-motorkluster .

aks-engine deploy \
--azure-env AzureStackCloud \
--location <for asdk is local> \
--resource-group kube-rg \
--api-model ./kubernetes-azurestack.json \
--output-directory kube-rg \
--client-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
--client-secret xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
--subscription-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
--identity-system adfs # required if using AD FS

Om körningen av någon anledning misslyckas när utdatakatalogen har skapats kan du åtgärda problemet och köra kommandot igen. Om du kör distributionen igen och hade använt samma utdatakatalog tidigare returnerar AKS-motorn ett fel om att katalogen redan finns. Du kan skriva över den befintliga katalogen med hjälp av flaggan: --force-overwrite.
Spara AKS-motorns klusterkonfiguration på en säker och krypterad plats.

Leta upp filen apimodel.json. Spara den på en säker plats. Den här filen används som indata i alla dina andra AKS-motoråtgärder.

Den genererade apimodel.json-filen innehåller tjänstens huvudnamn, hemlighet och den offentliga SSH-nyckel som du använder i indata-API-modellen. Filen har också alla andra metadata som krävs av AKS-motorn för att utföra alla andra åtgärder. Om du förlorar filen kommer AKS-motorn inte att kunna konfigurera klustret.

Hemligheterna är okrypterade. Förvara filen på en krypterad och säker plats.

Verifiera klustret

Kontrollera klustret genom att ansluta till kubectl, hämta informationen och sedan hämta nodernas tillstånd.

kubeconfig Hämta filen för att ansluta till kontrollplanet.
- Om du redan har kubectl installerat kontrollerar kubeconfig du filen för det nyligen skapade klustret i den här katalogsökvägen /kubeconfig/kubeconfig.json. Du kan lägga till i /kubeconfig.json .kube katalogen och byta namn på den till "config" för att få åtkomst till det nya klustret.
  Om du inte har installerat kubectlgår du till Installera verktyg för att installera kubernetes-kommandoradsverktyget. Annars följer du anvisningarna nedan för att komma åt klustret från en av kontrollplansnoderna.
Hämta den offentliga IP-adressen för en av dina kontrollplansnoder med hjälp av Azure Stack Hub-portalen.
Från en dator med åtkomst till din Azure Stack Hub-instans ansluter du via SSH till den nya kontrollplansnoden med hjälp av en klient som PuTTY eller MobaXterm.
För SSH-användarnamnet använder du "azureuser" och den privata nyckelfilen för nyckelparet som du angav för distributionen av klustret.

Kontrollera att klusterslutpunkterna körs:

kubectl cluster-info

Utdata bör se ut ungefär så här:

Kubernetes master is running at https://democluster01.location.domain.com
CoreDNS is running at https://democluster01.location.domain.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://democluster01.location.domain.com/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy

Granska sedan nodtillstånd:

kubectl get nodes

Resultatet bör likna följande:

k8s-linuxpool-29969128-0   Ready      agent    9d    v1.15.5
k8s-linuxpool-29969128-1   Ready      agent    9d    v1.15.5
k8s-linuxpool-29969128-2   Ready      agent    9d    v1.15.5
k8s-master-29969128-0      Ready      master   9d    v1.15.5
k8s-master-29969128-1      Ready      master   9d    v1.15.5
k8s-master-29969128-2      Ready      master   9d    v1.15.5

Felsöka klusterdistribution

När det uppstår fel när du distribuerar ett Kubernetes-kluster med hjälp av AKS-motorn kan du kontrollera:

Använder du rätt autentiseringsuppgifter för tjänstens huvudnamn (SPN)?
Har SPN rollen "Deltagare" i Azure Stack Hub-prenumerationen?
Har du en tillräckligt stor kvot i din Azure Stack Hub-plan?
Har Azure Stack Hub-instansen en korrigering eller uppgradering som tillämpas?

Mer information finns i artikeln Felsökning i GitHub-lagringsplatsen Azure/aks-engine-azurestack .

Rotera tjänstens principhemlighet

Efter distributionen av Kubernetes-klustret med AKS-motorn används tjänstens huvudnamn (SPN) för att hantera interaktioner med Azure Resource Manager på din Azure Stack Hub-instans. Någon gång kan hemligheten för tjänstens huvudnamn upphöra att gälla. Om hemligheten upphör att gälla kan du uppdatera autentiseringsuppgifterna genom att:

Uppdaterar varje nod med den nya hemligheten för tjänstens huvudnamn.
Eller uppdatera API-modellens autentiseringsuppgifter och köra uppgraderingen.

Uppdatera varje nod manuellt

Hämta en ny hemlighet för tjänstens huvudnamn från molnoperatören. Anvisningar för Azure Stack Hub finns i Använda en appidentitet för att få åtkomst till Azure Stack Hub-resurser.
Använd de nya autentiseringsuppgifterna som tillhandahålls av molnoperatören för att uppdatera /etc/kubernetes/azure.json på varje nod. När du har gjort uppdateringen startar du om både kubele och kube-controller-manager.

Uppdatera klustret med aks-engine update

Alternativt kan du ersätta autentiseringsuppgifterna i apimodel.json och köra uppgraderingen med hjälp av den uppdaterade .json filen till samma eller nyare Kubernetes-version. Anvisningar om hur du uppgraderar modellen finns i Uppgradera ett Kubernetes-kluster på Azure Stack Hub

Nästa steg

Felsöka AKS-motorn på Azure Stack Hub

Dela via