This is a cache of https://docs.okd.io/4.9/installing/installing_azure_stack_hub/installing-azure-stack-hub-account.html. It is a snapshot of the page at 2024-11-17T23:11:23.433+0000.
Configuring an Azure Stack Hub account - Installing on Azure Stack Hub | Installing | OKD 4.9
  1. Documentation
×

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.

Component Number of components required by default Description

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 tested and recommended minimum throughput of 5000 IOPS / 200MBps for control plane machines. 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_D8s_v3, 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 create Microsoft Azure resources by using the Azure Resource Manager, you must create a service principal to represent it.

Prerequisites

  • Install or update the Azure CLI.

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

Procedure

  1. Register your environment:

    $ az cloud register -n AzureStackCloud --endpoint-resource-manager <endpoint> (1)
    1 Specify the Azure Resource Manager endpoint, `https://management.<region>.<fqdn>/`.

    See the Microsoft documentation for details.

  2. Set the active environment:

    $ az cloud set -n AzureStackCloud

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

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

  4. Log in to the Azure CLI:

    $ az login

    If you are in a multitenant environment, you must also supply the tenant ID.

  5. 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
      Example output
      [
  {
    "cloudName": AzureStackCloud",
    "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 value matches the subscription you want to use:

      $ az account show
      Example output
      {
  "environmentName": AzureStackCloud",
  "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 correct subscription ID.

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

      $ az account set -s <subscription_id> (1)
      1 Specify the subscription ID.

    4. Verify the subscription ID update:

      $ az account show
      Example output
      {
  "environmentName": AzureStackCloud",
  "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"
  }
}

  6. Record the tenantId and id parameter values from the output. You need these values during the OKD installation.

  7. Create the service principal for your account:

    $ az ad sp create-for-rbac --role Contributor --name <service_principal> \ (1)
  --scopes /subscriptions/<subscription_id> (2)
  --years <years> (3)
    1 Specify the service principal name.
    2 Specify the subscription ID.
    3 Specify the number of years. By default, a service principal expires in one year. By using the --years option you can extend the validity of your service principal.
    Example output
    Creating 'Contributor' role assignment under scope '/subscriptions/<subscription_id>'
The output includes credentials that you must protect. Be sure that you do not
include these credentials in your code or check the credentials into your source
control. For more information, see https://aka.ms/azadsp-cli
{
  "appId": "ac461d78-bf4b-4387-ad16-7e32e328aec6",
  "displayName": <service_principal>",
  "password": "00000000-0000-0000-0000-000000000000",
  "tenantId": "8049c7e9-c3de-762d-a54e-dc3f6be6a7ee"
}

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

Additional resources

Next steps