Configuring an Azure Stack Hub 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 Stack Hub account limits

The OKD cluster uses a number of Microsoft Azure Stack Hub components, and the default Quota types in Azure Stack Hub affect your ability to install OKD clusters.

The following table summarizes the Azure Stack Hub components whose limits can impact your ability to install and run OKD clusters.

ComponentNumber of components required by defaultDescription

vCPU

56

A default cluster requires 56 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, control plane, and worker machines use Standard_DS4_v2 virtual machines, which use 8 vCPUs, a default cluster requires 56 vCPUs. The bootstrap node VM is used only during installation.

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.

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 Stack Hub, disk performance is directly dependent on SSD disk sizes, so to achieve the throughput supported by Standard_DS4_v2, or other similar machine types available, and the target of 5000 IOPS, at least a P30 disk is required.

Host caching must be set to ReadOnly for low read latency and high read IOPS and throughput. The reads performed from the cache, which is present either in the VM memory or in the local SSD disk, are much faster than the reads from the data disk, which is in the blob storage.

VNet

1

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

Network interfaces

7

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

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

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

2

The public load balancer 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.

Configuring a DNS zone in Azure Stack Hub

To successfully install OKD on Azure Stack Hub, you must create DNS records in an Azure Stack Hub DNS zone. The DNS zone must be authoritative for the domain. To delegate a registrar’s DNS zone to Azure Stack Hub, see Microsoft’s documentation for Azure Stack Hub datacenter DNS integration.

Required Azure Stack Hub roles

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

  • Owner

To set roles on the Azure portal, see the Manage access to resources in Azure Stack Hub with role-based access control in the Microsoft 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

  1. Register your Azure Stack Cloud environment with your Azure CLI. For more details on this process, see Microsoft’s documentation for Connecting to Azure Stack Hub.

    1. Register your environment with the Azure CLI:

      1. $ az cloud register -n <environment_name> --endpoint-resource-manager <arm_endpoint>

    2. Set the active environment:

      1. $ az cloud set -n <environment_name>

    3. Update your environment configuration to use the specific API version for Azure Stack Hub:

      1. $ az cloud update --profile 2019-03-01-hybrid

  2. Log in to the Azure CLI:

    1. $ az login

    Log in to Azure in the web console by using your credentials. If you are in a multitenant environment, you must also supply the tenant ID.

  3. 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:

      1. $ az account list --refresh

      Example output

      1. [
      2.   {
      3.     "cloudName": AzureStackCloud",
      4.     "id": "9bab1460-96d5-40b3-a78e-17b15e978a80",
      5.     "isDefault": true,
      6.     "name": "Subscription Name",
      7.     "state": "Enabled",
      8.     "tenantId": "6057c7e9-b3ae-489d-a54e-de3f6bf6a8ee",
      9.     "user": {
      10.       "name": "you@example.com",
      11.       "type": "user"
      12.     }
      13.   }
      14. ]

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

      1. $ az account show

      Example output

      1. {
      2.   "environmentName": AzureStackCloud",
      3.   "id": "9bab1460-96d5-40b3-a78e-17b15e978a80",
      4.   "isDefault": true,
      5.   "name": "Subscription Name",
      6.   "state": "Enabled",
      7.   "tenantId": "6057c7e9-b3ae-489d-a54e-de3f6bf6a8ee", (1)
      8.   "user": {
      9.     "name": "you@example.com",
      10.     "type": "user"
      11.   }
      12. }
      1Ensure 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:

      1. $ az account set -s <id> (1)
      1Substitute 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:

      1. $ az account show

      Example output

      1. {
      2.   "environmentName": AzureStackCloud",
      3.   "id": "33212d16-bdf6-45cb-b038-f6565b61edda",
      4.   "isDefault": true,
      5.   "name": "Subscription Name",
      6.   "state": "Enabled",
      7.   "tenantId": "8049c7e9-c3de-762d-a54e-dc3f6be6a7ee",
      8.   "user": {
      9.     "name": "you@example.com",
      10.     "type": "user"
      11.   }
      12. }

  4. Record the values of the tenantId and id parameters from the previous output. You need these values during OKD installation.

  5. Create the service principal for your account:

    1. $ az ad sp create-for-rbac --role Contributor --name <service_principal> (1)
    1Replace <service_principal> with the name to assign to the service principal.

    Example output

    1. Changing "<service_principal>" to a valid URI of "http://<service_principal>", which is the required format used for service principal names
    2. Retrying role assignment creation: 1/36
    3. Retrying role assignment creation: 2/36
    4. Retrying role assignment creation: 3/36
    5. Retrying role assignment creation: 4/36
    6. {
    7.   "appId": "8bd0d04d-0ac2-43a8-928d-705c598c6956",
    8.   "displayName": "<service_principal>",
    9.   "name": "http://<service_principal>",
    10.   "password": "ac461d78-bf4b-4387-ad16-7e32e328aec6",
    11.   "tenant": "6048c7e9-b2ad-488d-a54e-dc3f6be6a7ee"
    12. }

  6. Record the values of the appId and password parameters from the previous output. You need these values during OKD installation.

Additional resources

Next steps