Configuring an Azure account
Before you can install OKD, 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 OKD cluster uses a number of Microsoft Azure components, and the default Azure subscription and service limits, quotas, and constraints affect your ability to install OKD 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 OKD clusters.
Component | Number of components required by default | Default Azure limit | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
vCPU | 40 | 20 per region | A default cluster requires 40 vCPUs, so you must increase the account limit. By default, each cluster creates the following instances:
Because the bootstrap machine uses 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 availability zones. If your region contains fewer than three availability zones, the installation program places more than one control plane machine in the available zones. | ||||||
OS Disk | 7 | VM OS disk must be able to sustain a minimum throughput of 5000 IOPS / 200MBps. This throughput can be provided by having a minimum of 1 TiB Premium SSD (P30). In Azure, disk performance is directly dependent on SSD disk sizes, so to achieve the throughput supported by Host caching must be set to | |||||||
VNet | 1 | 1000 per region | Each default cluster requires one Virtual Network (VNet), which contains two subnets. | ||||||
Network interfaces | 7 | 65,536 per region | Each default cluster requires seven 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 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:
| ||||||
Network load balancers | 3 | 1000 per region | Each cluster creates the following load balancers:
If your applications create more Kubernetes | ||||||
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 load balancer, each of the three control plane machines, and each of the three worker machines each use a private IP address. | |||||||
Spot VM vCPUs (optional) | 0 If you configure spot VMs, your cluster must have two spot VM vCPUs for every compute node. | 20 per region | This is an optional component. To use spot VMs, you must increase the Azure default limit to at least twice the number of compute nodes in your cluster.
|
Configuring a public DNS zone in Azure
To install OKD, 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
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.
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.
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 asclusters.openshiftcorp.com
.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
From the Azure portal, click Help + support in the lower left corner.
Click New support request and then select the required values:
From the Issue type list, select Service and subscription limits (quotas).
From the Subscription list, select the subscription to modify.
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.
Click Next: Solutions.
On the Problem Details page, provide the required information for your quota increase:
Click Provide details and provide the required details in the Quota details window.
In the SUPPORT METHOD and CONTACT INFO sections, provide the issue severity and your contact details.
Click Next: Review + create and then click Create.
Required Azure roles
OKD needs a service principal so it can manage Microsoft Azure resources. Before you can create a service principal, your Azure account subscription must have the following roles:
User Access Administrator
Owner
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 OKD 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
Log in to the Azure CLI:
$ az login
Log in to Azure in the web console by using your credentials.
If your Azure account uses subscriptions, ensure that you are using the right subscription.
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
Example output
[
{
"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"
}
}
]
View your active account details and confirm that the
tenantId
value matches the subscription you want to use:$ az account show
Example output
{
"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.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>
.If you changed the active subscription, display your account information again:
$ az account show
Example output
{
"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"
}
}
Record the values of the
tenantId
andid
parameters from the previous output. You need these values during OKD installation.Create the service principal for your account:
$ az ad sp create-for-rbac --role Contributor --name <service_principal> (1)
1 Replace <service_principal>
with the name to assign to the service principal.Example output
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"
}
Record the values of the
appId
andpassword
parameters from the previous output. You need these values during OKD installation.Grant additional permissions to the service principal.
You must always add the
Contributor
andUser Access Administrator
roles to the app registration service principal so the cluster can assign credentials for its components.To operate the Cloud Credential Operator (CCO) in mint mode, the app registration service principal also requires the
Azure Active Directory Graph/Application.ReadWrite.OwnedBy
API permission.To operate the CCO in passthrough mode, the app registration service principal does not require additional API permissions.
For more information about CCO modes, see “About the Cloud Credential Operator” in the “Managing cloud provider credentials” section of the Authentication and authorization guide.
If you limit the service principal scope of the OKD installation program to an already existing Azure resource group, you must ensure all other resources used by the installation program in your environment have the necessary permissions, such as the public DNS zone and virtual network. Destroying a cluster using the installation program deletes this resource group.
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>'" \
| jq '.[0].id' -r) (1)
1 Replace <appId>
with theappId
parameter value for your service principal.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
1 Replace <appId>
with theappId
parameter value for your service principal.Example output
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
For more information about the specific permissions that you grant with this command, see the GUID Table for Windows Azure Active Directory Permissions.
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 theappId
parameter value for your service principal.
Additional resources
- For more information about CCO modes, see About the Cloud Credential Operator.
Supported Azure regions
The installation program dynamically generates the list of available Microsoft Azure regions based on your subscription.
Supported Azure public regions
australiacentral
(Australia Central)australiaeast
(Australia East)australiasoutheast
(Australia South East)brazilsouth
(Brazil South)canadacentral
(Canada Central)canadaeast
(Canada East)centralindia
(Central India)centralus
(Central US)eastasia
(East Asia)eastus
(East US)eastus2
(East US 2)francecentral
(France Central)germanywestcentral
(Germany West Central)japaneast
(Japan East)japanwest
(Japan West)koreacentral
(Korea Central)koreasouth
(Korea South)northcentralus
(North Central US)northeurope
(North Europe)norwayeast
(Norway East)southafricanorth
(South Africa North)southcentralus
(South Central US)southeastasia
(Southeast Asia)southindia
(South India)swedencentral
(Sweden Central)switzerlandnorth
(Switzerland North)uaenorth
(UAE North)uksouth
(UK South)ukwest
(UK West)westcentralus
(West Central US)westeurope
(West Europe)westindia
(West India)westus
(West US)westus2
(West US 2)westus3
(West US 3)
Supported Azure Government regions
Support for the following Microsoft Azure Government (MAG) regions was added in OKD version 4.6:
usgovtexas
(US Gov Texas)usgovvirginia
(US Gov Virginia)
You can reference all available MAG regions in the Azure documentation. Other provided MAG regions are expected to work with OKD, but have not been tested.
Next steps
- Install an OKD cluster on Azure. You can install a customized cluster or quickly install a cluster with default options.