add azure disk modifier

[handlerww]

What problem does this PR solve?

This PR introduces the Azure Disk Modifier. As of Kubernetes 1.31, the VolumeModifyClass feature remains in beta and is not enabled by default on Azure. As a workaround, we have implemented the Azure Disk Modifier by drawing inspiration from this project's AWS disk modifier implementation. This enhancement allows for disk modification capabilities on Azure, aligning with the existing functionality available for AWS.

This feature will use the kubelet identity of AKS, you should grant kubelet identity permission to modify the disk.

What is changed and how does it work?

Code changes

• Has Go code change
• Has CI related scripts change

Tests

• Unit test
• E2E test
• Manual test
• No code

Side effects

• Breaking backward compatibility
• Other side effects:

Related changes

• Need to cherry-pick to the release branch
• Need to update the documentation

Release Notes

Please refer to Release Notes Language Style Guide before writing the release note.

Added support for live modification of Azure disk IOPS, throughput, and size.

Manual test

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: premium2-4000-1000
parameters:
   cachingMode: None
   skuName: PremiumV2_LRS
   DiskIOPSReadWrite: "4000"
   DiskMBpsReadWrite: "1000"
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
EOF

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: premium2-4000-800
parameters:
   cachingMode: None
   skuName: PremiumV2_LRS
   DiskIOPSReadWrite: "4000"
   DiskMBpsReadWrite: "800"
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
EOF

kubectl apply -f - <<EOF
apiVersion: pingcap.com/v1alpha1
kind: TidbCluster
metadata:
  name: basic
  namespace: tidb-cluster
spec:
  version: v8.1.0
  timezone: UTC
  pvReclaimPolicy: Delete
  enableDynamicConfiguration: true
  configUpdateStrategy: RollingUpdate
  discovery: {}
  helper:
    image: alpine:3.16.0
  pd:
    baseImage: pingcap/pd
    maxFailoverCount: 0
    replicas: 1
    storageClassName: premium2-4000-1000
    requests:
      storage: "10Gi"
    config: {}
  tikv:
    baseImage: pingcap/tikv
    maxFailoverCount: 0
    evictLeaderTimeout: 1m
    replicas: 1
    storageClassName: premium2-4000-1000
    requests:
      storage: "10Gi"
    config:
      storage:
        reserve-space: "0MB"
      rocksdb:
        max-open-files: 256
      raftdb:
        max-open-files: 256
  tidb:
    baseImage: pingcap/tidb
    maxFailoverCount: 0
    replicas: 1
    service:
      type: ClusterIP
    config: {}
EOF

Modify the storage request and storage class name, then on Azure portal the disk properties changed as expected.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 56.08466% with 83 lines in your changes missing coverage. Please review.

Project coverage is 59.23%. Comparing base (a16b2e8) to head (6b5c4f3).
Report is 9 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5958      +/-   ##
==========================================
+ Coverage   57.19%   59.23%   +2.04%     
==========================================
  Files         259      263       +4     
  Lines       33233    45655   +12422     
==========================================
+ Hits        19008    27045    +8037     
- Misses      12291    16566    +4275     
- Partials     1934     2044     +110     

Flag	Coverage Δ
e2e	20.91% <0.00%> (?)
unittest	56.98% <56.08%> (-0.21%)	⬇️

[csuzhangxc]

What's the behavior without an Azure config? can we do the same check as we did for AWS in dependences.go?

[handlerww]

1. If there is no Azure config, it should not be initialized here, and no error will be reported. It's safe for tidb-opreator deployed on AKS without any Azure app authentication config.
2. Because the subscription and resource group that needs to be operated cannot be obtained from places such as Node Role, it has to be obtained from the disk handler of PV the subscription and resource group. For the same AKS and a tidb-controller-manager process, this information should be the same after it is obtained once, and it will only be initialized once in the process.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: csuzhangxc

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [csuzhangxc]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2024-12-04 06:24:30.057072255 +0000 UTC m=+1222457.676726770: ☑️ agreed by csuzhangxc.

[csuzhangxc]

/run-pull-e2e-kind-basic

[csuzhangxc]

/cherry-pick release-1.6

[ti-chi-bot]

@csuzhangxc: new pull request created to branch release-1.6: #5962.

In response to this:

/cherry-pick release-1.6

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository.