This is a cache of https://docs.openshift.com/container-platform/4.2/installing/installing_azure/installing-azure-account.html. It is a snapshot of the page at 2024-11-30T02:06:44.291+0000.
Configuring an Azure account - Installing on Azure | Installing | OpenShift Container Platform 4.2
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

Configuring an Azure account

Before you can install OpenShift Container Platform, you must configure a Microsoft Azure account.

All Azure resources that are available through public endpoints are subject to resource name restrictions, and you cannot create resources that use certain terms. For a list of terms that Azure restricts, see Resolve reserved resource name errors in the Azure documentation.

Azure account limits

The OpenShift Container Platform cluster uses a number of Microsoft Azure components, and the default Azure subscription and service limits, quotas, and constraints affect your ability to install OpenShift Container Platform clusters.

Default limits vary by offer category types, such as Free Trial and Pay-As-You-Go, and by series, such as Dv2, F, and G. For example, the default for Enterprise Agreement subscriptions is 350 cores.

Check the limits for your subscription type and if necessary, increase quota limits for your account before you install a default cluster on Azure.

The following table summarizes the Azure components whose limits can impact your ability to install and run OpenShift Container Platform clusters.

Component Number of components required by default Default Azure limit Description

vCPU

34

20 per region

A default cluster requires 34 vCPUs, so you must increase the account limit.

By default, each cluster creates the following instances:

  • One bootstrap machine, which is removed after installation

  • Three control plane machines

  • Three compute machines

Because the bootstrap machine uses Standard_D4s_v3 machines, which use 4 vCPUS, the control plane machines use Standard_D8s_v3 virtual machines, which use 8 vCPUs, and the worker machines use Standard_D2s_v3 virtual machines, which use 2 vCPUs, a default cluster requires 34 vCPUs.

To deploy more worker nodes, enable autoscaling, deploy large workloads, or use a different instance type, you must further increase the vCPU limit for your account to ensure that your cluster can deploy the machines that you require.

By default, the installation program distributes control plane and compute machines across all availability zones within a region. To ensure high availability for your cluster, select a region with at least three availablity zones. If your region contains fewer than three availability zones, the installation program places more than one control plane machine in the available zones.

VNet

1

1000 per region

Each default cluster requires one Virtual Network (VNet), which contains two subnets.

Network interfaces

6

65,536 per region

Each default cluster requires six network interfaces. If you create more machines or your deployed workloads create load balancers, your cluster uses more network interfaces.

Network security groups

2

5000

Each default cluster Each cluster creates network security groups for each subnet in the VNet. The default cluster creates network security groups for the control plane and for the compute node subnets:

controlplane

Allows the control plane machines to be reached on port 6443 from anywhere
node

Allows worker nodes to be reached from the internet on ports 80 and 443

Network load balancers

3

1000 per region

Each cluster creates the following load balancers:

default

Public IP address that load balances requests to ports 80 and 443 across worker machines
internal

Private IP address that load balances requests to ports 6443 and 22623 across control plane machines
external

Public IP address that load balances requests to port 6443 across control plane machines

If your applications create more Kubernetes LoadBalancer Service objects, your cluster uses more load balancers.

Public IP addresses

3

Each of the two public load balancers uses a public IP address. The bootstrap machine also uses a public IP address so that you can SSH into the machine to troubleshoot issues during installation. The IP address for the bootstrap node is used only during installation.

Private IP addresses

7

The internal loadbalancer, each of the three control plane machines, and each of the three worker machines each use a private IP address.

Configuring a public DNS zone in Azure

To install OpenShift Container Platform, the Microsoft Azure account you use must have a dedicated public hosted DNS zone in your account. This zone must be authoritative for the domain. This service provides cluster DNS resolution and name lookup for external connections to the cluster.

Procedure

  1. Identify your domain, or subdomain, and registrar. You can transfer an existing domain and registrar or obtain a new one through Azure or another source.

    For more information about purchasing domains through Azure, see Buy a custom domain name for Azure App Service in the Azure documentation.

  2. If you are using an existing domain and registrar, migrate its DNS to Azure. See Migrate an active DNS name to Azure App Service in the Azure documentation.

  3. Configure DNS for your domain. Follow the steps in the Tutorial: Host your domain in Azure DNS in the Azure documentation to create a public hosted zone for your domain or subdomain, extract the new authoritative name servers, and update the registrar records for the name servers that your domain uses.

    Use an appropriate root domain, such as openshiftcorp.com, or subdomain, such as clusters.openshiftcorp.com.

  4. If you use a subdomain, follow your company’s procedures to add its delegation records to the parent domain.

Increasing Azure account limits

To increase an account limit, file a support request on the Azure portal.

You can increase only one type of quota per support request.
Procedure

  1. From the Azure portal, click Help + support in the lower left corner.

  2. Click New support request and then select the required values:

    1. From the Issue type list, select Service and subscription limits (quotas).

    2. From the Subscription list, select the subscription to modify.

    3. From the Quota type list, select the quota to increase. For example, select Compute-VM (cores-vCPUs) subscription limit increases to increase the number of vCPUs, which is required to install a cluster.

    4. Click Next: Solutions.

  3. On the PROBLEM DETAILS page, provide the required information for your quota increase:

    1. Click Provide details and provide the required details in the "Quota details" window.

    2. In the SUPPORT METHOD and CONTACT INFO sections, provide the issue severity and your contact details.

  4. Click Next: Review + create and then click Create.

Required Azure roles

Your Microsoft Azure account must have the following roles for the subscription that you use:

  • user Access Administrator

To set roles on the Azure portal, see the Manage access to Azure resources using RBAC and the Azure portal in the Azure documentation.

Creating a service principal

Because OpenShift Container Platform and its installation program must create Microsoft Azure resources through Azure Resource Manager, you must create a service principal to represent it.

Prerequisites

  • Install or update the Azure CLI.

  • Install the jq package.

  • Your Azure account has the required roles for the subscription that you use.

Procedure

  1. Log in to the Azure CLI:

    $ az login

    Log in to Azure in the web console by using your credentials.

  2. If your Azure account uses subscriptions, ensure that you are using the right subscription.

    1. View the list of available accounts and record the tenantId value for the subscription you want to use for your cluster:

      $ az account list --refresh
[
  {
    "cloudName": "AzureCloud",
    "id": "9bab1460-96d5-40b3-a78e-17b15e978a80",
    "isDefault": true,
    "name": "Subscription Name",
    "state": "Enabled",
    "tenantId": "6057c7e9-b3ae-489d-a54e-de3f6bf6a8ee",
    "user": {
      "name": "you@example.com",
      "type": "user"
    }
  }
]

    2. View your active account details and confirm that the tenantId matches the subscription you want to use:

      $ az account show
{
  "environmentName": "AzureCloud",
  "id": "9bab1460-96d5-40b3-a78e-17b15e978a80",
  "isDefault": true,
  "name": "Subscription Name",
  "state": "Enabled",
  "tenantId": "6057c7e9-b3ae-489d-a54e-de3f6bf6a8ee", (1)
  "user": {
    "name": "you@example.com",
    "type": "user"
  }
}
      1 Ensure that the value of the tenantId parameter is the UUID of the correct subscription.

    3. If you are not using the right subscription, change the active subscription:

      $ az account set -s <id> (1)
      1 Substitute the value of the id for the subscription that you want to use for <id>.

    4. If you changed the active subscription, display your account information again:

      $ az account show

{
  "environmentName": "AzureCloud",
  "id": "33212d16-bdf6-45cb-b038-f6565b61edda",
  "isDefault": true,
  "name": "Subscription Name",
  "state": "Enabled",
  "tenantId": "8049c7e9-c3de-762d-a54e-dc3f6be6a7ee",
  "user": {
    "name": "you@example.com",
    "type": "user"
  }
}

  3. Record the values of the tenantId and id parameters from the previous output. You need these values during OpenShift Container Platform installation.

  4. Create the service principal for your account:

    $ az ad sp create-for-rbac --role Contributor --name <service_principal> (1)
Changing "<service_principal>" to a valid URI of "http://<service_principal>", which is the required format used for service principal names
Retrying role assignment creation: 1/36
Retrying role assignment creation: 2/36
Retrying role assignment creation: 3/36
Retrying role assignment creation: 4/36
{
  "appId": "8bd0d04d-0ac2-43a8-928d-705c598c6956",
  "displayName": "<service_principal>",
  "name": "http://<service_principal>",
  "password": "ac461d78-bf4b-4387-ad16-7e32e328aec6",
  "tenant": "6048c7e9-b2ad-488d-a54e-dc3f6be6a7ee"
}
    1 Replace <service_principal> with the name to assign to the service principal.

  5. Record the values of the appId and password parameters from the previous output. You need these values during OpenShift Container Platform installation.

  6. Grant additional permissions to the service principal. The service principal requires the legacy Azure Active Directory Graph → Application.ReadWrite.OwnedBy permission and the user Access Administrator role for the cluster to assign credentials for its components.

    1. To assign the user Access Administrator role, run the following command:

      $ az role assignment create --role "user Access Administrator" \
    --assignee-object-id $(az ad sp list --filter "appId eq '<appId>'" \ (1)
       | jq '.[0].objectId' -r)
      1 Replace <appId> with the appId parameter value for your service principal.

    2. To assign the Azure Active Directory Graph permission, run the following command:

      $ az ad app permission add --id <appId> \ (1)
     --api 00000002-0000-0000-c000-000000000000 \
     --api-permissions 824c81eb-e3f8-4ee6-8f6d-de7f50d565b7=Role

     Invoking "az ad app permission grant --id 46d33abc-b8a3-46d8-8c84-f0fd58177435 --api 00000002-0000-0000-c000-000000000000" is needed to make the change effective
      1 Replace <appId> with the appId parameter value for your service principal.

      For more information about the specific permissions that you grant with this command, see the GUID Table for Windows Azure Active Directory Permissions.

    3. Approve the permissions request. If your account does not have the Azure Active Directory tenant administrator role, follow the guidelines for your organization to request that the tenant administrator approve your permissions request.

      $ az ad app permission grant --id <appId> \ (1)
     --api 00000002-0000-0000-c000-000000000000
      1 Replace <appId> with the appId parameter value for your service principal.

Supported Azure regions

The installation program dynamically generates the list of available Microsoft Azure regions based on your subscription. The following Azure regions were tested and validated in OpenShift Container Platform version 4.2.0:

  • centralus (Central US)

  • eastus (East US)

  • eastus2 (East US 2)

  • northcentralus (North Central US)

  • southcentralus (South Central US)

  • westcentralus (West Central US)

  • westus (West US)

  • westus2 (West US 2)

  • uksouth (UK South)

  • ukwest (UK West)

  • francecentral (France Central)

  • northeurope (North Europe)

  • westeurope (West Europe)

  • japaneast (Japan East)

  • japanwest (Japan West)

  • koreacentral (Korea Central)

  • koreasouth (Korea South)

  • eastasia (East Asia)

  • southeastasia (Southeast Asia)

  • southindia (South India)

  • centralindia (Central India)

  • westindia (West India)

  • uaenorth (UAE North)

Next steps