sigs.k8s.io/cluster-api-provider-azure@v1.14.3/docs/book/src/topics/cloud-provider-config.md (about) 1 # Configuring the Kubernetes Cloud Provider for Azure 2 3 The [Azure cloud provider](https://github.com/kubernetes-sigs/cloud-provider-azure) has a number of configuration options driven by a file on cluster nodes. This file canonically lives on a node at /etc/kubernetes/azure.json. The Azure cloud provider documentation details the [configuration options exposed](https://github.com/kubernetes-sigs/cloud-provider-azure/blob/master/docs/cloud-provider-config.md#cloud-provider-config) by this file. 4 5 CAPZ automatically generates this file based on user-provided values in AzureMachineTemplate and AzureMachine. All AzureMachines in the same MachineDeployment or control plane will all share a single cloud provider secret, while AzureMachines created inidividually will have their own secret. 6 7 For AzureMachineTemplate and standalone AzureMachines, the generated secret will have the name "${RESOURCE}-azure-json", where "${RESOURCE}" is the name of either the AzureMachineTemplate or AzureMachine. The secret will have two data fields: `control-plane-azure.json` and `worker-node-azure.json`, with the raw content for that file containing the control plane and worker node data respectively. When the secret `${RESOURCE}-azure-json` already exists in the same namespace as an AzureCluster and does not have the label `"${CLUSTER_NAME}": "owned"`, CAPZ will not generate the default described above. Instead it will directly use whatever the user provides in that secret. 8 9 <aside class="note warning"> 10 11 <h1> Warning </h1> 12 13 For backwards compatibility, the generated secret will also have the `azure.json` field with the control plane data. 14 But, this is deprecated and will be removed in capz `v0.6.x`. It is recommended to use the `control-plane-azure.json` and `worker-node-azure.json` fields instead. 15 16 </aside> 17 18 ### Overriding Cloud Provider Config 19 20 While many of the cloud provider config values are inferred from the capz infrastructure spec, there are other configuration parameters that cannot be inferred, and hence default to the values set by the azure cloud provider. In order to provider custom values to such configuration options through capz, you must use the `spec.cloudProviderConfigOverrides` in `AzureCluster`. The following example overrides the load balancer rate limit configuration: 21 ```yaml 22 apiVersion: infrastructure.cluster.x-k8s.io/v1beta1 23 kind: AzureCluster 24 metadata: 25 name: ${CLUSTER_NAME} 26 namespace: default 27 spec: 28 location: eastus 29 networkSpec: 30 vnet: 31 name: ${CLUSTER_NAME}-vnet 32 resourceGroup: cherry 33 subscriptionID: ${AZURE_SUBSCRIPTION_ID} 34 cloudProviderConfigOverrides: 35 rateLimits: 36 - name: "defaultRateLimit" 37 config: 38 cloudProviderRateLimit: true 39 cloudProviderRateLimitBucket: 1 40 cloudProviderRateLimitBucketWrite: 1 41 cloudProviderRateLimitQPS: 1, 42 cloudProviderRateLimitQPSWrite: 1, 43 - name: "loadBalancerRateLimit" 44 config: 45 cloudProviderRateLimit: true 46 cloudProviderRateLimitBucket: 2, 47 CloudProviderRateLimitBucketWrite: 2, 48 cloudProviderRateLimitQPS: 0, 49 CloudProviderRateLimitQPSWrite: 0 50 ``` 51 52 <aside class="note warning"> 53 54 <h1> Warning </h1> 55 56 Presently, only rate limit configuration is supported for overrides, and this works only on clusters running Kubernetes versions above `v1.18.0`. 57 See [per client rate limiting](https://cloud-provider-azure.sigs.k8s.io/install/configs/#per-client-rate-limiting) for more info. 58 59 </aside> 60 61 <aside class="note warning"> 62 63 <h1> Warning </h1> 64 65 All cloud provider config values can be customized by creating the `${RESOURCE}-azure-json` secret beforehand. `cloudProviderConfigOverrides` is only applicable when the secret is managed by the Azure Provider. 66 67 </aside> 68 69