Algemene vereisten voor het implementeren van OpenShift Container Platform 3.11 in Azure

Van toepassing op: ✔️ Virtuele Linux-heavy_check_mark: flexibele schaalsets

In dit artikel worden algemene vereisten beschreven voor het implementeren van OpenShift Container Platform of OKD in Azure.

De installatie van OpenShift maakt gebruik van Ansible-playbooks. Ansible maakt gebruik van Secure Shell (SSH) om verbinding te maken met alle clusterhosts om de installatiestappen te voltooien.

Wanneer ansible de SSH-verbinding maakt met de externe hosts, kan er geen wachtwoord worden invoeren. Daarom kan er geen wachtwoord (wachtwoordzin) aan de persoonlijke sleutel worden gekoppeld of mislukt de implementatie.

Omdat de virtuele machines (VM's) via Azure Resource Manager implementeren, wordt dezelfde openbare sleutel gebruikt voor toegang tot alle virtuele machines. De bijbehorende persoonlijke sleutel moet zich op de VM staan die ook alle playbooks uitvoert. Om deze actie veilig uit te voeren, wordt een Azure-sleutelkluis gebruikt om de persoonlijke sleutel door te geven aan de VM.

Als er permanente opslag voor containers nodig is, zijn permanente volumes vereist. OpenShift ondersteunt Virtuele harde schijven (VHD's) van Azure voor permanente volumes, maar Azure moet eerst worden geconfigureerd als de cloudprovider.

In dit model: OpenShift:

• Hiermee maakt u een VHD-object in een Azure-opslagaccount of een beheerde schijf.
• De VHD wordt aan een VM bevestigd en het volume wordt geformatteerd.
• Het volume wordt aan de pod bevestigd.

Deze configuratie werkt alleen als OpenShift machtigingen heeft om deze taken in Azure uit te voeren. Hiervoor wordt een service-principal gebruikt. De service-principal is een beveiligingsaccount in Azure Active Directory dat machtigingen voor resources krijgt.

De service-principal moet toegang hebben tot de opslagaccounts en VM's waar het cluster uit bestaat. Als alle OpenShift-clusterresources worden geïmplementeerd in één resourcegroep, kan aan de service-principal machtigingen voor die resourcegroep worden verleend.

In deze handleiding wordt beschreven hoe u de artefacten maakt die zijn gekoppeld aan de vereisten.

Als u nog geen abonnement op Azure hebt, maak dan een gratis account aan voordat u begint.

Aanmelden bij Azure

Meld u aan bij uw Azure-abonnement met de opdracht az login en volg de instructies op het scherm of klik op Uitproberen om de Cloud Shell.

az login

Een resourcegroep maken

Een resourcegroep maken met de opdracht az group create. Een Azure-resourcegroep is een logische container waarin Azure-resources worden geïmplementeerd en beheerd. U moet een toegewezen resourcegroep gebruiken om de sleutelkluis te hosten. Deze groep staat los van de resourcegroep waarin de OpenShift-clusterresources worden geïmplementeerd.

In het volgende voorbeeld wordt een resourcegroep met de naam keyvaultrg gemaakt op de locatie eastus:

az group create --name keyvaultrg --location eastus

Een sleutelkluis maken

Maak een sleutelkluis om de SSH-sleutels voor het cluster op te slaan met de opdracht az keyvault create. De naam van de sleutelkluis moet wereldwijd uniek zijn en moet zijn ingeschakeld voor sjabloonimplementatie, anders mislukt de implementatie met de fout 'KeyVaultParameterReferenceSecretRetrieveFailed'.

In het volgende voorbeeld wordt een sleutelkluis met de naam keyvault gemaakt in de resourcegroep keyvaultrg:

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

Een SSH-sleutel maken

Er is een SSH-sleutel nodig om de toegang tot het OpenShift-cluster te beveiligen. Maak een SSH-sleutelpaar met behulp van ssh-keygen de opdracht (in Linux of macOS):

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

Zie SSH-sleutels maken op Windows voor meer informatie over SSH-Windows. Zorg ervoor dat u de persoonlijke sleutel in OpenSSH-indeling exporteert.

Sla de persoonlijke SSH-sleutel op in Azure Key Vault

De OpenShift-implementatie gebruikt de SSH-sleutel die u hebt gemaakt om de toegang tot de OpenShift-master te beveiligen. Als u de implementatie wilt inschakelen om de SSH-sleutel veilig op te halen, moet u de sleutel opslaan in Key Vault met behulp van de volgende opdracht:

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

Een service-principal maken

OpenShift communiceert met Azure met behulp van een gebruikersnaam en wachtwoord of een service-principal. Een Azure-service-principal is een beveiligingsidentiteit die u kunt gebruiken met apps, services en automatiseringshulpprogramma's zoals OpenShift. U bepaalt en definieert de machtigingen voor de bewerkingen die de service-principal in Azure kan uitvoeren. Het is het beste om het bereik van de machtigingen van de service-principal te wijzigen in specifieke resourcegroepen in plaats van het hele abonnement.

Maak een service-principal met az ad sp create-for-rbac en uitvoer de referenties die OpenShift nodig heeft.

In het volgende voorbeeld wordt een service-principal gemaakt en worden inzendermachtigingen toegewezen aan een resourcegroep met de naam openshiftrg.

Maak eerst de resourcegroep met de naam openshiftrg:

az group create -l eastus -n openshiftrg

Service-principal maken:

az group show --name openshiftrg --query id

Sla de uitvoer van de opdracht op en gebruik in plaats van $scope in de volgende opdracht

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

Noteer de eigenschap appId en het wachtwoord die door de opdracht worden geretourneerd:

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

Zie Een Azure-service-principal maken met Azure CLI voor meer informatie over service-principals.

Vereisten die alleen van toepassing zijn op Resource Manager sjabloon

Er moeten geheimen worden gemaakt voor de persoonlijke SSH-sleutel (sshPrivateKey), het Azure AD-clientgeheim (aadClientSecret), het OpenShift-beheerderswachtwoord (openshiftPassword) en het red Hat Subscription Manager-wachtwoord of de activeringssleutel (rhsmPasswordOrActivationKey). Als er bovendien aangepaste TLS/SSL-certificaten worden gebruikt, moeten er zes extra geheimen worden gemaakt: routingcafile, routingcertfile, routingkeyfile, mastercafile, mastercertfile en masterkeyfile. Deze parameters worden uitgebreid beschreven.

De sjabloon verwijst naar specifieke geheime namen, zodat u de vetgedrukte namen moet gebruiken die hierboven worden vermeld (casegevoelig).

Aangepaste certificaten

De sjabloon implementeert standaard een OpenShift-cluster met behulp van zelf-ondertekende certificaten voor de OpenShift-webconsole en het routeringsdomein. Als u aangepaste TLS/SSL-certificaten wilt gebruiken, stelt u routingCertType in op 'aangepast' en 'masterCertType' op 'aangepast'. U hebt de CA-, certificaat- en sleutelbestanden in PEM-indeling nodig voor de certificaten. Het is mogelijk om aangepaste certificaten voor het ene maar niet het andere certificaat te gebruiken.

U moet deze bestanden opslaan in Key Vault geheimen. Gebruik dezelfde Key Vault als de sleutel die wordt gebruikt voor de persoonlijke sleutel. In plaats van zes extra invoer voor de geheime namen te vereisen, is de sjabloon in code gecodeerd voor het gebruik van specifieke geheime namen voor elk van de TLS/SSL-certificaatbestanden. Sla de certificaatgegevens op met behulp van de gegevens uit de volgende tabel.

Maak de geheimen met behulp van de Azure CLI. Hieronder vindt u een voorbeeld.

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

Volgende stappen

In dit artikel zijn de volgende onderwerpen behandeld:

Implementeer vervolgens een OpenShift-cluster:

• OpenShift Container Platform implementeren
• OpenShift Container Platform implementeren Self-Managed Marketplace-aanbieding