Azure requirements

Before you configure Azure as a cloud provider and deploy IBM Cloud Private on Azure, you must review the applicable Azure requirements.

Review and configure, if necessary, the following required components for Azure:

Azure roles
Service principal
Resource group
Virtual Network and subnet
Network security group
Azure load balancers
Availability sets
Availability zones
Instance sizing
Storage account

Azure roles

You must create the Microsoft® Azure role, Contributor to create, and manage all of the Azure resources. For more information, see Microsoft Azure RBAC roles Opens in a new tab . To create a role assignment with the Azure command line interface, see Azure Create Role Assignment .

Service principal

A service principal is required to configure Azure. Create a unique service principal with permissions for the Azure resource group where your IBM Cloud Private cluster is deployed. The Azure service principal for your cluster is used to create and manage Kubernetes-service load balancers and disks for persistent storage. With a service principal, You can complete the following tasks:

Update the Azure route table with custom routes to the pods that run on a specific node.
Create and modify Azure load balancers to meet the Kubernetes service type LoadBalancer requests.
Modify security groups to meet the Kubernetes Service type LoadBalancer requests.
Create and attach Azure disks and files to meet the Kubernetes persistent volume claims with Azure Storageclass requests.

Add the service principal values to the /etc/cfc/conf/azure.conf directory for your IBM Cloud Private cluster nodes. For more information, see How to create an Azure service principal Opens in a new tab .

To create a service principal with the Azure CLI, run the following command:

  az ad sp create-for-rbac --name icpprovidersp \
     --password <secret> --role contributor \
     --scopes /subscriptions/<subscription>/resourceGroups/<resource-group>

Your Azure JSON file might resemble the following output:

  {
    "appId": "<app-id>",
    "displayName": "icpprovidersp",
    "name": "http://icpprovidersp",
    "password": "<secret>",
    "tenant": "<tenant-id>"
  }

For more information, see Create an Azure service principal with Azure CLI Opens in a new tab .

Note: If a service principal is not available, contact your Azure owner to help create a service principal that you can use. The creation of a service principal in Azure requires the User Access Administrator role.

Resource group

Resource groups contain all the Azure components that make up the deployment for IBM Cloud Private on Azure. For more information, see the Resource groups section from the Azure Resource Manager overview Opens in a new tab for further details.

Virtual Network and subnet

Azure Virtual Network is an Azure resource that supports the isolation of cluster networks from each other, and allows resources in the virtual network to communicate with each other and to the internet.

You must create a subnet in the Azure Virtual Network. Specify the pod network for the network_cidr parameter in your config.yaml file. For more information, see Azure Virtual Networks Opens in a new tab .

Network security group

Network security groups filter network traffic to and from resources in the Azure virtual network. Network security groups define a list of rules to allow or deny traffic with a numeric value to indicate priority. For more information, see Azure Virtual Networks Opens in a new tab .

Azure load balancers

You can use Azure load balancers to create high-availability services as you deploy IBM Cloud Private onto Azure. For more information, see Azure Load Balancer Opens in a new tab .

All non-master nodes must be in the same security group because the Azure cloud provider updates the security group that is specified in the config.yaml file. If the proxy, Vulnerability Advisor (VA), etcd, and management nodes have different security groups, the load balancers communicate with the nodes, but their security groups drop the traffic. Requests that are sent to your application might fail. You can exclude nodes from the load balancer with the following node annotation: alpha.service-controller.kubernetes.io/exclude-balancer=true. For more information, see Kuberenetes Loadbalancer Opens in a new tab .

Testing load balancer integration

To test the Azure Load Balancer integration, deploy a workload and expose its service by running the following commands:

  kubectl run mynginx --image=nginx --replicas=2 --port=80
  kubectl expose deployment mynginx --port=80 --type=LoadBalancer

Obtain the IP address for the Azure load balancer by running the following command:

  kubectl get svc

Availability sets

Availability sets are an Azure anti-colocation feature that ensures virtual machines (VM) that serve the same role in a high-availability solution are placed in different failure and update domains within the same data center. For a high-availability scale, it is ideal to place your master nodes in an availability set to maintain availability if hardware fails in an Azure data center. Similarly, your worker nodes must be placed in an availability set to improve the availability of your Kubernetes workloads.

Azure load balancer supports Basic and Standard SKU. As you use the Basic SKU load balancer with availability sets, you must place all non-master VMs in the same availability set. If you want to exclude the Azure load balancer, you must add the following node notation to all non-master worker nodes: alpha.service-controller.kubernetes.io/exclude-balancer=true.

Availability zones

Availability zones are unique physical locations within an Azure region that protect applications against data center failures. As you use availability zones with IBM Cloud Private, you must use the Standard SKU load balancer.

Instance sizing

View the IBM Cloud Private system requirements to ensure that your environment meets the minimum requirements.

Storage account

View the IBM Cloud Private Storage guide to ensure that you meet the minimum storage requirement for your cluster.

Storage class deployment (Azure disks)

A storage class object is required for persistent storage for applications in an IBM Cloud Private deployment. Complete the following steps to define a default storage class object for an IBM Cloud Private deployment on Azure that is associated to Azure disks:

Create the storageclass-azure-disk.yaml file to define the Azure disks backed storage:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
 name: standard
 annotations:
   storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/azure-disk
parameters:
 storageaccounttype: Standard_LRS
 kind: managed

Create the storage class object by running the following command:
```
kubectl apply -f storageclass-azure-disk.yaml
```

For more information, see Azure disk from the MicrosoftDocs in GitHub Opens in a new tab .

Storage class deployment (Azure files)

Create a storage class deployment that is associated to Azure files.

Create the storage class, storageclass-azure-file.yaml file for an Azure file.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
 name: azurefile
provisioner: kubernetes.io/azure-file
mountOptions:
 - dir_mode=0777
 - file_mode=0777
 - uid=1000
 - gid=1000
parameters:
 skuName: Standard_LRS

Create the storage class in your IBM Cloud Private cluster by running the following command:
```
kubectl apply -f storageclass-azure-file.yaml
```

For more information, see Azure file from the MicrosoftDocs in GitHub Opens in a new tab

IBM Cloud Private cluster role and cluster role binding

To use the Azure storage providers, you must add the following cluster role and cluster role binding object:

Create a file that is named roles-azure-cloud-provider.yaml by entering the following content:

 ---
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
   name: system:azure-cloud-provider
 rules:
   - apiGroups:
       - ""
     resources:
       - secrets
     verbs:
       - get
       - create

 ---
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
   name: system:azure-cloud-provider
 roleRef:
   kind: ClusterRole
   apiGroup: rbac.authorization.k8s.io
   name: system:azure-cloud-provider
 subjects:
   - kind: ServiceAccount
     name: azure-cloud-provider
     namespace: kube-system

Run the following command to add the roles to your cluster:
```
 kubectl apply -f roles-azure-cloud-provider.yaml
```