Vanliga krav för att distribuera OpenShift Container Platform 3.11 i Azure

  • Artikel

Gäller för: ✔️ Flexibla skalningsuppsättningar för virtuella Linux-datorer ✔️

Den här artikeln beskriver vanliga förutsättningar för att distribuera OpenShift Container Platform eller OKD i Azure.

Installationen av OpenShift använder Ansible-spelböcker. Ansible använder Secure Shell (SSH) för att ansluta till alla klustervärdar för att slutföra installationsstegen.

När ansible gör SSH-anslutningen till fjärrvärdarna kan den inte ange något lösenord. Av den anledningen kan den privata nyckeln inte ha ett lösenord (lösenfras) associerat med det eller så misslyckas distributionen.

Eftersom de virtuella datorerna distribueras via Azure Resource Manager mallar används samma offentliga nyckel för åtkomst till alla virtuella datorer. Motsvarande privata nyckel måste finnas på den virtuella datorn som även kör alla spelböcker. För att utföra den här åtgärden på ett säkert sätt används ett Azure-nyckelvalv för att skicka den privata nyckeln till den virtuella datorn.

Om det finns ett behov av beständig lagring för containrar krävs beständiga volymer. OpenShift stöder virtuella Azure-hårddiskar (VHD) för beständiga volymer, men Azure måste först konfigureras som molnleverantör.

I den här modellen, OpenShift:

  • Skapar ett VHD-objekt i ett Azure Storage-konto eller en hanterad disk.
  • Monterar den virtuella hårddisken på en virtuell dator och formaterar volymen.
  • Monterar volymen till podden.

För att den här konfigurationen ska fungera behöver OpenShift behörighet att utföra dessa uppgifter i Azure. Ett huvudnamn för tjänsten används för detta ändamål. Tjänstens huvudnamn är ett säkerhetskonto i Azure Active Directory som beviljas behörigheter till resurser.

Tjänstens huvudnamn måste ha åtkomst till de lagringskonton och virtuella datorer som utgör klustret. Om alla OpenShift-klusterresurser distribueras till en enskild resursgrupp kan tjänstens huvudnamn beviljas behörighet till den resursgruppen.

Den här guiden beskriver hur du skapar artefakter som är associerade med förutsättningarna.

  • Skapa ett nyckelvalv för att hantera SSH-nycklar för OpenShift-klustret.
  • Skapa ett huvudnamn för tjänsten för användning av Azure Cloud Provider.

Om du inte har någon Azure-prenumeration kan du skapa ett kostnadsfritt konto innan du börjar.

Logga in på Azure

Logga in på din Azure-prenumeration med kommandot az login och följ anvisningarna på skärmen, eller klicka på Prova om du vill använda Cloud Shell.

az login

Skapa en resursgrupp

Skapa en resursgrupp med kommandot az group create. En Azure-resursgrupp är en logisk container där Azure-resurser distribueras och hanteras. Du bör använda en dedikerad resursgrupp som värd för nyckelvalvet. Den här gruppen är separat från den resursgrupp som OpenShift-klusterresurserna distribuerar till.

I följande exempel skapas en resursgrupp med namnet keyvaultrg på platsen eastus :

az group create --name keyvaultrg --location eastus

Skapa ett nyckelvalv

Skapa ett nyckelvalv för att lagra SSH-nycklarna för klustret med kommandot az keyvault create . Nyckelvalvets namn måste vara globalt unikt och måste vara aktiverat för malldistribution, annars misslyckas distributionen med felet "KeyVaultParameterReferenceSecretrieveFailed".

I följande exempel skapas ett nyckelvalv med namnet keyvault i resursgruppen keyvaultrg :

az keyvault create --resource-group keyvaultrg --name keyvault \
       --enabled-for-template-deployment true \
       --location eastus

Skapa en SSH-nyckel

En SSH-nyckel krävs för att skydda åtkomsten till OpenShift-klustret. Skapa ett SSH-nyckelpar med hjälp ssh-keygen av kommandot (på Linux eller macOS):

ssh-keygen -f ~/.ssh/openshift_rsa -t rsa -N ''

Anteckning

SSH-nyckelparet kan inte ha ett lösenord/lösenfras.

Mer information om SSH-nycklar i Windows finns i Så här skapar du SSH-nycklar i Windows. Se till att exportera den privata nyckeln i OpenSSH-format.

Lagra den privata SSH-nyckeln i Azure Key Vault

OpenShift-distributionen använder SSH-nyckeln som du skapade för att skydda åtkomsten till OpenShift-huvudservern. Om du vill aktivera distributionen för att på ett säkert sätt hämta SSH-nyckeln lagrar du nyckeln i Key Vault med hjälp av följande kommando:

az keyvault secret set --vault-name keyvault --name keysecret --file ~/.ssh/openshift_rsa

Skapa ett huvudnamn för tjänsten

OpenShift kommunicerar med Azure med ett användarnamn och lösenord eller ett huvudnamn för tjänsten. Ett Huvudnamn för Azure-tjänsten är en säkerhetsidentitet som du kan använda med appar, tjänster och automatiseringsverktyg som OpenShift. Du styr och definierar behörigheterna för vilka åtgärder tjänstens huvudnamn kan utföra i Azure. Det är bäst att begränsa behörigheterna för tjänstens huvudnamn till specifika resursgrupper i stället för hela prenumerationen.

Skapa ett huvudnamn för tjänsten med az ad sp create-for-rbac och mata ut de autentiseringsuppgifter som OpenShift behöver.

I följande exempel skapas ett huvudnamn för tjänsten och behörigheter tilldelas till en resursgrupp med namnet openshiftrg.

Skapa först resursgruppen openshiftrg:

az group create -l eastus -n openshiftrg

Skapa tjänstens huvudnamn:

az group show --name openshiftrg --query id

Spara kommandots utdata och använd i stället för $scope i nästa kommando

az ad sp create-for-rbac --name openshiftsp \
      --role Contributor --scopes $scope \

Anteckna egenskapen appId och lösenordet som returneras från kommandot:

{
  "appId": "11111111-abcd-1234-efgh-111111111111",
  "displayName": "openshiftsp",
  "name": "http://openshiftsp",
  "password": {Strong Password},
  "tenant": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
}

Varning

Se till att skriva ned det säkra lösenordet eftersom det inte går att hämta det här lösenordet igen.

Mer information om tjänstens huvudnamn finns i Skapa ett Huvudnamn för Azure-tjänsten med Azure CLI.

Krav som endast gäller för Resource Manager mall

Hemligheter måste skapas för den privata SSH-nyckeln (sshPrivateKey), Azure AD klienthemlighet (aadClientSecret), OpenShift-administratörslösenord (openshiftPassword) och Red Hat Subscription Manager-lösenord eller aktiveringsnyckel (rhsmPasswordOrActivationKey). Om anpassade TLS/SSL-certifikat används måste ytterligare sex hemligheter skapas – routingcafile, routingcertfile, routingkeyfile, mastercafile, mastercertfile och masterkeyfile. Dessa parametrar förklaras mer detaljerat.

Mallen refererar till specifika hemliga namn så att du måste använda de fetstilade namnen som anges ovan (skiftlägeskänsligt).

Anpassade certifikat

Som standard distribuerar mallen ett OpenShift-kluster med självsignerade certifikat för OpenShift-webbkonsolen och routningsdomänen. Om du vill använda anpassade TLS/SSL-certifikat anger du "routingCertType" till "custom" och "masterCertType" till "custom". Du behöver ca-, certifikat- och nyckelfilerna i .pem-format för certifikaten. Det går att använda anpassade certifikat för det ena men inte det andra.

Du måste lagra dessa filer i Key Vault hemligheter. Använd samma Key Vault som den som används för den privata nyckeln. I stället för att kräva ytterligare 6 indata för de hemliga namnen är mallen hårdkodad för att använda specifika hemliga namn för var och en av TLS/SSL-certifikatfilerna. Lagra certifikatdata med hjälp av informationen från följande tabell.

Hemligt namn Certifikatfil
mastercafile huvud-CA-fil
mastercertfile cert-huvudfil
masterkeyfile huvudnyckelfil
routingcafile routnings-CA-fil
routingcertfile routning av CERT-fil
routingkeyfile routningsnyckelfil

Skapa hemligheterna med hjälp av Azure CLI. Nedan visas ett exempel.

az keyvault secret set --vault-name KeyVaultName -n mastercafile --file ~/certificates/masterca.pem

Nästa steg

I den här artikeln beskrivs följande ämnen:

  • Skapa ett nyckelvalv för att hantera SSH-nycklar för OpenShift-klustret.
  • Skapa ett huvudnamn för tjänsten för användning av Azure Cloud Solution Provider.

Distribuera sedan ett OpenShift-kluster: