AzureDisk
AzureDisk 爲 Azure 上面運行的虛擬機提供了彈性塊存儲服務，它以 VHD 的形式掛載到虛擬機中，並可以在 Kubernetes 容器中使用。AzureDisk 優點是性能高，特別是 Premium Storage 提供了非常好的性能；其缺點是不支持共享，只可以用在單個 Pod 內。
根據配置的不同，Kubernetes 支持的 AzureDisk 可以分爲以下幾類
Managed Disks: 由 Azure 自動管理磁盤和存儲賬戶
Blob Disks:
Dedicated (默認)：爲每個 AzureDisk 創建單獨的存儲賬戶，當刪除 PVC 的時候刪除該存儲賬戶
Shared：AzureDisk 共享 ResourceGroup 內的同一個存儲賬戶，這時刪除 PVC 不會刪除該存儲賬戶
注意：
AzureDisk 的類型必須跟 VM OS Disk 類型一致，即要麼都是 Manged Disks，要麼都是 Blob Disks。當兩者不一致時，AzureDisk PV 會報無法掛載的錯誤。
由於 Managed Disks 需要創建和管理存儲賬戶，其創建過程會比 Blob Disks 慢（3 分鐘 vs 1-2 分鐘）。
但節點最大支持同時掛載 16 個 AzureDisk。
使用 AzureDisk 推薦的版本：
1.12
1.12.9 或更高版本
1.13
1.13.6 或更高版本
1.14
1.14.2 或更高版本
>=1.15
>=1.15
使用 aks-engine 部署的 Kubernetes 集群，會自動創建兩個 StorageClass，默認爲managed-standard（即HDD）：
kubectl get storageclass
NAME PROVISIONER AGE
default (default) kubernetes.io/azure-disk 45d
managed-premium kubernetes.io/azure-disk 53d
managed-standard kubernetes.io/azure-disk 53dAzureDisk 掛載失敗
在 AzureDisk 從一個 Pod 遷移到另一 Node 上面的 Pod 時或者同一臺 Node 上面使用了多塊 AzureDisk 時有可能會碰到這個問題。這是由於 kube-controller-manager 未對 AttachDisk 和 DetachDisk 操作加鎖從而引發了競爭問題（kubernetes#60101 acs-engine#2002 ACS#12）。
通過 kube-controller-manager 的日誌，可以查看具體的錯誤原因。常見的錯誤日誌爲
Cannot attach data disk 'cdb-dynamic-pvc-92972088-11b9-11e8-888f-000d3a018174' to VM 'kn-edge-0' because the disk is currently being detached or the last detach operation failed. Please wait until the disk is completely detached and then try again or delete/detach the disk explicitly again.臨時性解決方法爲
（1）更新所有受影響的虛擬機狀態
使用powershell：
$vm = Get-AzureRMVM -ResourceGroupName $rg -Name $vmname
Update-AzureRmVM -ResourceGroupName $rg -VM $vm -verbose -debug使用 Azure CLI：
# For VM:
az vm update -n <VM_NAME> -g <RESOURCE_GROUP_NAME>
# For VMSS:
az vmss update-instances -g <RESOURCE_GROUP_NAME> --name <VMSS_NAME> --instance-id <ID>（2）重啓虛擬機
kubectl cordon NODE如果 Node 上運行有 StatefulSet，需要手動刪除相應的 Pod
kubectl drain NODEGet-AzureRMVM -ResourceGroupName $rg -Name $vmname | Restart-AzureVMkubectl uncordon NODE
該問題的修復 #60183 已包含在 v1.10 中。
掛載新的 AzureDisk 後，該 Node 中其他 Pod 已掛載的 AzureDisk 不可用
在 Kubernetes v1.7 中，AzureDisk 默認的緩存策略修改爲 ReadWrite，這會導致在同一個 Node 中掛載超過 5 塊 AzureDisk 時，已有 AzureDisk 的盤符會隨機改變（kubernetes#60344 kubernetes#57444 AKS#201 acs-engine#1918）。比如，當掛載第六塊 AzureDisk 後，原來 lun0 磁盤的掛載盤符有可能從 sdc 變成 sdk：
$ tree /dev/disk/azure
...
└── scsi1
├── lun0 -> ../../../sdk
├── lun1 -> ../../../sdj
├── lun2 -> ../../../sde
├── lun3 -> ../../../sdf
├── lun4 -> ../../../sdg
├── lun5 -> ../../../sdh
└── lun6 -> ../../../sdi這樣，原來使用 lun0 磁盤的 Pod 就無法訪問 AzureDisk 了
[root@admin-0 /]# ls /datadisk
ls: reading directory .: Input/output error臨時性解決方法是設置 AzureDisk StorageClass 的 cachingmode: None，如
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: managed-standard
provisioner: kubernetes.io/azure-disk
parameters:
skuname: Standard_LRS
kind: Managed
cachingmode: None該問題的修復 #60346 將包含在 v1.10 中。
AzureDisk 掛載慢
AzureDisk PVC 的掛載過程一般需要 1 分鐘的時間，這些時間主要消耗在 Azure ARM API 的調用上（查詢 VM 以及掛載 Disk）。#57432 爲 Azure VM 增加了一個緩存，消除了 VM 的查詢時間，將整個掛載過程縮短到大約 30 秒。該修復包含在v1.9.2+ 和 v1.10 中。
另外，如果 Node 使用了 Standard_B1s 類型的虛擬機，那麼 AzureDisk 的第一次掛載一般會超時，等再次重複時纔會掛載成功。這是因爲在 Standard_B1s 虛擬機中格式化 AzureDisk 就需要很長時間（如超過 70 秒）。
$ kubectl describe pod <pod-name>
...
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
8m 8m 1 default-scheduler Normal Scheduled Successfully assigned nginx-azuredisk to aks-nodepool1-15012548-0
7m 7m 1 kubelet, aks-nodepool1-15012548-0 Normal SuccessfulMountVolume MountVolume.SetUp succeeded for volume "default-token-mrw8h"
5m 5m 1 kubelet, aks-nodepool1-15012548-0 Warning FailedMount Unable to mount volumes for pod "nginx-azuredisk_default(4eb22bb2-0bb5-11e8-8
d9e-0a58ac1f0a2e)": timeout expired waiting for volumes to attach/mount for pod "default"/"nginx-azuredisk". list of unattached/unmounted volumes=[disk01]
5m 5m 1 kubelet, aks-nodepool1-15012548-0 Warning FailedSync Error syncing pod
4m 4m 1 kubelet, aks-nodepool1-15012548-0 Normal SuccessfulMountVolume MountVolume.SetUp succeeded for volume "pvc-20240841-0bb5-11e8-8d9e-0a58ac1f0
a2e"
4m 4m 1 kubelet, aks-nodepool1-15012548-0 spec.containers{nginx-azuredisk} Normal Pulling pulling image "nginx"
3m 3m 1 kubelet, aks-nodepool1-15012548-0 spec.containers{nginx-azuredisk} Normal Pulled Successfully pulled image "nginx"
3m 3m 1 kubelet, aks-nodepool1-15012548-0 spec.containers{nginx-azuredisk} Normal Created Created container
2m 2m 1 kubelet, aks-nodepool1-15012548-0 spec.containers{nginx-azuredisk} Normal Started Started containerAzure German Cloud 無法使用 AzureDisk
Azure German Cloud 僅在 v1.7.9+、v1.8.3+ 以及更新版本中支持（#50673），升級 Kubernetes 版本即可解決。
MountVolume.WaitForAttach failed
MountVolume.WaitForAttach failed for volume "pvc-f1562ecb-3e5f-11e8-ab6b-000d3af9f967" : azureDisk - Wait for attach expect device path as a lun number, instead got: /dev/disk/azure/scsi1/lun1 (strconv.Atoi: parsing "/dev/disk/azure/scsi1/lun1": invalid syntax)該問題 僅在 Kubernetes v1.10.0 和 v1.10.1 中存在，將在 v1.10.2 中修復。
在 mountOptions 中設置 uid 和 gid 時失敗
默認情況下，Azure 磁盤使用 ext4、xfs filesystem 和 mountOptions，如 uid = x，gid = x 無法在裝入時設置。 例如，如果你嘗試設置 mountOptions uid = 999，gid = 999，將看到類似於以下內容的錯誤:
Warning FailedMount 63s kubelet, aks-nodepool1-29460110-0 MountVolume.MountDevice failed for volume "pvc-d783d0e4-85a1-11e9-8a90-369885447933" : azureDisk - mountDevice:FormatAndMount failed with mount failed: exit status 32
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m436970985 --scope -- mount -t xfs -o dir_mode=0777,file_mode=0777,uid=1000,gid=1000,defaults /dev/disk/azure/scsi1/lun2 /var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m436970985
Output: Running scope as unit run-rb21966413ab449b3a242ae9b0fbc9398.scope.
mount: wrong fs type, bad option, bad superblock on /dev/sde,
missing codepage or helper program, or other error可以通過執行以下操作之一來緩解此問題
通過在 fsGroup 中的 runAsUser 和 gid 中設置 uid 來配置 pod 的安全上下文。例如，以下設置會將 pod 設置爲 root，使其可供任何文件訪問：
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 0
fsGroup: 0備註: 因爲 gid 和 uid 默認裝載爲 root 或0。如果 gid 或 uid 設置爲非根（例如1000），則 Kubernetes 將使用
chown更改該磁盤下的所有目錄和文件。此操作可能非常耗時，並且可能會導致裝載磁盤的速度非常慢。
使用 initContainers 中的
chown設置 gid 和 uid。例如：
initContainers:
- name: volume-mount
image: busybox
command: ["sh", "-c", "chown -R 100:100 /data"]
volumeMounts:
- name: <your data volume>
mountPath: /data刪除 pod 使用的 Azure 磁盤 PersistentVolumeClaim 時出錯
如果嘗試刪除 pod 使用的 Azure 磁盤 PersistentVolumeClaim，可能會看到錯誤。例如：
$ kubectl describe pv pvc-d8eebc1d-74d3-11e8-902b-e22b71bb1c06
...
Message: disk.DisksClient#Delete: Failure responding to request: StatusCode=409 -- Original Error: autorest/azure: Service returned an error. Status=409 Code="OperationNotAllowed" Message="Disk kubernetes-dynamic-pvc-d8eebc1d-74d3-11e8-902b-e22b71bb1c06 is attached to VM /subscriptions/{subs-id}/resourceGroups/MC_markito-aks-pvc_markito-aks-pvc_westus/providers/Microsoft.Compute/virtualMachines/aks-agentpool-25259074-0."在 Kubernetes 版本1.10 及更高版本中，默認情況下已啓用 PersistentVolumeClaim protection 功能以防止此錯誤。如果你使用的 Kubernetes 版本不能解決此問題，則可以通過在刪除 PersistentVolumeClaim 前使用 PersistentVolumeClaim 刪除 pod 來緩解此問題。
參考文檔
Last updated