AzureFile
AzureFile 提供了基於 SMB 協議（也稱 CIFS）託管文件共享服務。它支持 Windows 和 Linux 容器，並支持跨主機的共享，可用於多個 Pod 之間的共享存儲。AzureFile 的缺點是性能較差（AKS#223），並且不提供 Premium 存儲。
推薦基於 StorageClass 來使用 AzureFile，即
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使用 AzureFile 推薦的版本：
1.12
1.12.6 或更高版本
1.13
1.13.4 或更高版本
1.14
1.14.0 或更高版本
>=1.15
>=1.15
訪問權限
AzureFile 使用 mount.cifs 將其遠端存儲掛載到 Node 上，而fileMode 和 dirMode 控制了掛載後文件和目錄的訪問權限。不同的 Kubernetes 版本，fileMode 和 dirMode 的默認選項是不同的
v1.6.x, v1.7.x
0777
v1.8.0-v1.8.5
0700
v1.8.6 or above
0755
v1.9.0
0700
v1.9.1-v1.12.1
0755
>=v1.12.2
0777
按照默認的權限會導致非跟用戶無法在目錄中創建新的文件，解決方法爲
v1.8.0-v1.8.5：設置容器以 root 用戶運行，如設置
spec.securityContext.runAsUser: 0v1.8.6 以及更新版本：在 AzureFile StorageClass 通過 mountOptions 設置默認權限，比如設置爲
0777的方法爲
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
- mfsymlinks
- nobrl
- cache=none
parameters:
skuName: Standard_LRSWindows Node 重啓後無法訪問 AzureFile
Windows Node 重啓後，掛載 AzureFile 的 Pod 可以看到如下錯誤（#60624）：
Warning Failed 1m (x7 over 1m) kubelet, 77890k8s9010 Error: Error response from daemon: invalid bind mount spec "c:\\var\\lib\\kubelet\\pods\\07251c5c-1cfc-11e8-8f70-000d3afd4b43\\volumes\\kubernetes.io~azure-file\\pvc-fb6159f6-1cfb-11e8-8f70-000d3afd4b43:c:/mnt/azure": invalid volume specification: 'c:\var\lib\kubelet\pods\07251c5c-1cfc-11e8-8f70-000d3afd4b43\volumes\kubernetes.io~azure-file\pvc-fb6159f6-1cfb-11e8-8f70-000d3afd4b43:c:/mnt/azure': invalid mount config for type "bind": bind source path does not exist
Normal SandboxChanged 1m (x8 over 1m) kubelet, 77890k8s9010 Pod sandbox changed, it will be killed and re-created.臨時性解決方法爲刪除並重新創建使用了 AzureFile 的 Pod。當 Pod 使用控制器（如 Deployment、StatefulSet等）時，刪除 Pod 後控制器會自動創建一個新的 Pod。
該問題的修復 #60625 包含在 v1.10 中。
AzureFile ProvisioningFailed
Azure 文件共享的名字最大隻允許 63 個字節，因而在集群名字較長的集群（Kubernetes v1.7.10 或者更老的集群）裏面有可能會碰到 AzureFile 名字長度超限的情況，導致 AzureFile ProvisioningFailed：
persistentvolume-controller Warning ProvisioningFailed Failed to provision volume with StorageClass "azurefile": failed to find a matching storage account碰到該問題時可以通過升級集群解決，其修復 #48326 已經包含在 v1.7.11、v1.8 以及更新版本中。
在開啓 RBAC 的集群中，由於 AzureFile 需要訪問 Secret，而 kube-controller-manager 中並未爲 AzureFile 自動授權，從而也會導致 ProvisioningFailed：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ProvisioningFailed 8s persistentvolume-controller Failed to provision volume with StorageClass "azurefile": Couldn't create secret secrets is forbidden: User "system:serviceaccount:kube-syste
m:persistent-volume-binder" cannot create secrets in the namespace "default"
Warning ProvisioningFailed 8s persistentvolume-controller Failed to provision volume with StorageClass "azurefile": failed to find a matching storage account解決方法是爲 ServiceAccount persistent-volume-binder 授予 Secret 的訪問權限：
---
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/v1beta1
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: persistent-volume-binder
namespace: kube-systemAzure German Cloud 無法使用 AzureFile
Azure German Cloud 僅在 v1.7.11+、v1.8+ 以及更新版本中支持（#48460），升級 Kubernetes 版本即可解決。
"could not change permissions" 錯誤
在 Azure Files 插件上運行 PostgreSQL 時，可能會看到類似於以下內容的錯誤：
initdb: could not change permissions of directory "/var/lib/postgresql/data": Operation not permitted
fixing permissions on existing directory /var/lib/postgresql/data此錯誤是由使用 cifs/SMB 協議的 Azure 文件插件導致的。 使用 cifs/SMB 協議時，無法在裝載後更改文件和目錄權限。 若要解決此問題，請將子路徑與 Azure 磁盤插件結合使用。
參考文檔
Last updated