Rancher-Azure-Cloud-Provider-Storage-Classes

00-notes.md

storageClass with PersistentVolumeClaims are really the way to do storage with Kubernetes.

For Azure There are 3 types of storage avalible.

• (Slow, Limited, Going to cause tears) AzureFiles - CIFS share, with all the limitaions of CIFS :(
• (Better) Azure Disk (Storage Account) - You can use this type with Azure "Node Driver" VMs in Rancher.
• (Best) Azure Disk (Managed) - You will need to create your own VMs that support managed disk with premium storage, then use the "Custom" option.

01-cloud-provider.md

Cloud Provider

Configure the Cloud-Provider when you create the cluster with Rancher.

Global -> Cluster -> Add Cluster -> Expand Cluster Options -> Cloud Provider -> Toggle Azure

Required Options

As long as you are doing sane things (one cluster per Resource Group), These are the only options required to make storage and load balancers work.

Auth

• aadClientId - UUID for the Service Principle
• aadClientSecret - Secret for the Service Principle
• subscriptionId - Can find this with az account show
• tenantId - Can find this with az account show

Leave the rest defaults or blank.

Full options are here: https://github.com/kubernetes/cloud-provider-azure/blob/master/docs/cloud-provider-config.md

NOTE: Becasue Azure API is slow, it may take a rancher couple of retry loops to register that the kubelet is healthy.

Troubleshooting

SSH into your node and check the kubelet container log.

docker logs -f kubelet

02-azure-files.md

AzureFiles

Fisrt, Just Don't. Its slooooow, like KB/s-max-speed-slow, and CIFS is not POSIX friendly filesystem, a lot of things just won't work.

If you must

After you spin up the cluster you will have to run a couple of kubectl commands to give the azure-cloud-provider enough permissions to save the share credentials as a secret in the Namespace the PVC is created in.

You can do this in the web console as a cluster admin user.

Cluster -> Launch kubectl

kubectl create clusterrole system:azure-cloud-provider --verb=get,create --resource=secrets
kubectl create clusterrolebinding system:azure-cloud-provider --clusterrole=system:azure-cloud-provider --serviceaccount=kube-system:persistent-volume-binder

storageClass

Cluster -> Storage -> Storage Class -> Add Class

Required Options

• Provisioner: Azure File
• Sku Name: Standard_LRS

This will automatically use a Standard_LRS in the same resource group or create one if there isn't one.

NOTE: You will probably need to add mount options to your storageClass. This means setting up different storageClasses for different apps if they run as specific uid/gid.

Testing

Go into your Project and create a Volume using the storageClass.

If the volume makes it to "Bound" its working.

Troubleshooting

SSH into your nodes and check the kube-controller-manager container log

docker logs -f kube-controller-manager

03-azure-disk.md

Azure Disk

You really want to use Premium_LRS disk here. The "Standard" will make you really sad. Make sure your VMs support "Premium" Storage.

Unmanaged Disk

If you created your VMs with the Rancher Azure Node Driver or are still using Azure Storage Accounts for your VHDs, the provider will create VHDs in a Storage Account inside your Resourse Group.

Storage Class

Cluster -> Storage -> Storage Class -> Add Class

Required Options

• Toggle: New Azure Disk
• Storage Account Type: Premium_LRS
• Kind: Shared or Dedicated - Volumes are created in one Storage Account (shared) or each volume gets its own Storage Account (dedicated).

Remember that Storage Accounts have a per-Azure Subscription limit.

Managed Disk (prefered)

Right now to use Managed Disks, you need to create your own VMs with Avaliblity Sets that support Managed Disk.

Storage Class

Cluster -> Storage -> Storage Class -> Add Class

Required Options

• Toggle: New Azure Disk
• Storage Account Type: Premium_LRS
• Kind: Managed.

Testing

Go into your Project and create a Volume using the storageClass.

If the volume makes it to "Bound" its working.

Troubleshooting

SSH into your nodes and check the kube-controller-manager container log

docker logs -f kube-controller-manager