Azure
Azure 負載均衡
使用 Azure Cloud Provider 後,Kubernetes 會爲 LoadBalancer 類型的 Service 創建 Azure 負載均衡器以及相關的 公網 IP、BackendPool 和 Network Security Group (NSG)。注意目前 Azure Cloud Provider 僅支持 Basic
SKU 的負載均衡,並將在 v1.11 中支持 Standard SKU。Basic
與 Standard
SKU 負載均衡相比有一定的侷限:
Back-end pool size
up to 100
up to 1,000
Back-end pool boundary
Availability Set
virtual network, region
Back-end pool design
VMs in Availability Set, virtual machine scale set in Availability Set
Any VM instance in the virtual network
HA Ports
Not supported
Available
Diagnostics
Limited, public only
Available
VIP Availability
Not supported
Available
Fast IP Mobility
Not supported
Available
Availability Zones scenarios
Zonal only
Zonal, Zone-redundant, Cross-zone load-balancing
Outbound SNAT algorithm
On-demand
Preallocated
Outbound SNAT front-end selection
Not configurable, multiple candidates
Optional configuration to reduce candidates
Network Security Group
Optional on NIC/subnet
Required
同樣,對應的 Public IP 也是 Basic SKU,與 Standard SKU 相比也有一定的侷限:
Availability Zones scenarios
Zonal only
Zone-redundant (default), zonal (optional)
Fast IP Mobility
Not supported
Available
VIP Availability
Not supported
Available
Counters
Not supported
Available
Network Security Group
Optional on NIC
Required
在創建 Service 時,可以通過 metadata.annotation
來自定義 Azure 負載均衡的行爲,可選的 Annotation 列表請參考 Cloud Provider Azure 文檔。
在 Kubernetes 中,負載均衡的創建邏輯都在 kube-controller-manager 中,因而排查負載均衡相關的問題時,除了查看 Service 自身的狀態,如
還需要查看 kube-controller-manager 是否有異常發生:
LoadBalancer Service 一直處於 pending 狀態
查看 Service kubectl describe service <service-name>
沒有錯誤信息,但 EXTERNAL-IP 一直是 <pending>
,說明 Azure Cloud Provider 在創建 LB/NSG/PublicIP 過程中出錯。一般按照前面的步驟查看 kube-controller-manager 可以查到具體失敗的原因,可能的因素包括
clientId、clientSecret、tenandId 或 subscriptionId 配置錯誤導致 Azure API 認證失敗:更新所有節點的
/etc/kubernetes/azure.json
,修復錯誤的配置即可恢復服務配置的客戶端無權管理 LB/NSG/PublicIP/VM:可以爲使用的 clientId 增加授權或創建新的
az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>"
Kuberentes v1.8.X 中還有可能出現
Security rule must specify SourceAddressPrefixes, SourceAddressPrefix, or SourceApplicationSecurityGroups
的錯誤,這是由於 Azure Go SDK 的問題導致的,可以通過升級集群到 v1.9.X/v1.10.X 或者將 SourceAddressPrefixes 替換爲多條 SourceAddressPrefix 規則來解決
負載均衡公網 IP 無法訪問
Azure Cloud Provider 會爲負載均衡器創建探測器,只有探測正常的服務纔可以響應用戶的請求。負載均衡公網 IP 無法訪問一般是探測失敗導致的,可能原因有:
後端 VM 本身不正常(可以重啓 VM 恢復)
後端容器未監聽在設置的端口上(可通過配置正確的端口解決)
防火牆或網絡安全組阻止了要訪問的端口(可通過增加安全規則解決)
當使用內網負載均衡時,從同一個 ILB 的後端 VM 上訪問 ILB VIP 時也會失敗,這是 Azure 的預期行爲(此時可以訪問 service 的 clusterIP)
後端容器不響應(部分或者全部)外部請求時也會導致負載均衡 IP 無法訪問。注意這裏包含部分容器不響應的場景,這是由於 Azure 探測器與 Kubernetes 服務發現機制共同導致的結果:
(1)Azure 探測器定期去訪問 service 的端口(即 NodeIP:NodePort)
(2)Kubernetes 將其負載均衡到後端容器中
(3)當負載均衡到異常容器時,訪問失敗會導致探測失敗,進而 Azure 可能會將 VM 移出負載均衡
該問題的解決方法是使用健康探針,保證異常容器自動從服務的後端(endpoints)中刪除。
內網負載均衡 BackendPool 爲空
Kubernetes 1.9.0-1.9.3 中會有這個問題(kubernetes#59746 kubernetes#60060 acs-engine#2151),這是由於一個查找負載均衡所屬 AvaibilitySet 的缺陷導致的。
該問題的修復(kubernetes#59747 kubernetes#59083)將包含到 v1.9.4 和 v1.10 中。
外網負載均衡均衡 BackendPool 爲空
在使用不支持 Cloud Provider 的工具(如 kubeadm)部署的集群中,如果未給 Kubelet 配置 --cloud-provider=azure --cloud-config=/etc/kubernetes/cloud-config
,那麼 Kubelet 會以 hostname 將其註冊到集群中。此時,查看該 Node 的信息(kubectl get node -o yaml),可以發現其 externalID 與 hostname 相同。此時,kube-controller-manager 也無法將其加入到負載均衡的後端中。
一個簡單的確認方式是查看 Node 的 externalID 和 name 是否不同:
該問題的解決方法是先刪除 Node kubectl delete node <node-name>
,爲 Kubelet 配置 --cloud-provider=azure --cloud-config=/etc/kubernetes/cloud-config
,最後再重啓 Kubelet。
Service 刪除後 Azure 公網 IP 未自動刪除
Kubernetes 1.9.0-1.9.3 中會有這個問題(kubernetes#59255):當創建超過 10 個 LoadBalancer Service 後有可能會碰到由於超過 FrontendIPConfiguations Quota(默認爲 10)導致負載均衡無法創建的錯誤。此時雖然負載均衡無法創建,但公網 IP 已經創建成功了,由於 Cloud Provider 的缺陷導致刪除 Service 後公網 IP 卻未刪除。
該問題的修復(kubernetes#59340)將包含到 v1.9.4 和 v1.10 中。
另外,超過 FrontendIPConfiguations Quota 的問題可以參考 Azure subscription and service limits, quotas, and constraints 增加 Quota 來解決。
MSI 無法使用
配置 "useManagedIdentityExtension": true
後,可以使用 Managed Service Identity (MSI) 來管理 Azure API 的認證授權。但由於 Cloud Provider 的缺陷(kubernetes #60691 未定義 useManagedIdentityExtension
yaml 標籤導致無法解析該選項。
該問題的修復(kubernetes#60775)將包含在 v1.10 中。
Azure ARM API 調用請求過多
有時 kube-controller-manager 或者 kubelet 會因請求調用過多而導致 Azure ARM API 失敗的情況,比如
特別是在 Kubernetes 集群創建或者批量增加 Nodes 的時候。從 v1.9.2 和 v1.10 開始, Azure cloud provider 爲一些列的 Azure 資源(如 VM、VMSS、安全組和路由表等)增加了緩存,大大緩解了這個問題。
一般來說,如果該問題重複出現可以考慮
使用 Azure instance metadata,即爲所有 Node 的
/etc/kubernetes/azure.json
設置"useInstanceMetadata": true
並重啓 kubelet爲 kube-controller-manager 增大
--route-reconciliation-period
(默認爲 10s),比如在/etc/kubernetes/manifests/kube-controller-manager.yaml
中設置--route-reconciliation-period=1m
後 kubelet 會自動重新創建 kube-controller-manager Pod。
AKS kubectl logs connection timed out
kubectl logs
命令報 getsockopt: connection timed out
的錯誤(AKS#232):
在 AKS 中,kubectl logs, exec, and attach 等命令需要 Master 與 Nodes 節點之間建立隧道連接。在 kube-system
namespace 中可以看到 tunnelfront
和 kube-svc-redirect
Pod:
如果它們不是處於 Running
狀態或者 Exec/Logs/PortForward 等命令報 net/http: TLS handshake timeout
錯誤,刪除 tunnelfront
Pod,稍等一會就會自動創建新的出來,如:
使用 Virtual Kubelet 後 LoadBalancer Service 無法分配公網 IP
使用 Virtual Kubelet 後,LoadBalancer Service 可能會一直處於 pending 狀態,無法分配 IP 地址。查看該服務的事件(如 kubectl describe svc)
會發現錯誤 CreatingLoadBalancerFailed 4m (x15 over 45m) service-controller Error creating load balancer (will retry): failed to ensure load balancer for service default/nginx: ensure(default/nginx): lb(kubernetes) - failed to ensure host in pool: "instance not found"
。這是由於 Virtual Kubelet 創建的虛擬 Node 並不存在於 Azure 雲平臺中,因而無法將其加入到 Azure Load Balancer 的後端中。
解決方法是開啓 ServiceNodeExclusion 特性,即設置 kube-controller-manager --feature-gates=ServiceNodeExclusion=true
。開啓後,所有帶有 alpha.service-controller.kubernetes.io/exclude-balancer
標籤的 Node 都不會加入到雲平臺負載均衡的後端中。
注意該特性僅適用於 Kubernetes 1.9 及以上版本。
Node 的 GPU 數總是 0
當在 AKS 集群中運行 GPU 負載時,發現它們無法調度,這可能是由於 Node 容量中的 nvidia.com/gpu
總是0。
解決方法是重新部署 nvidia-gpu 設備插件擴展:
Azure ServicePrincipal 過期
默認情況下,Service Principal 的過期時間是 1 年,可以通過以下的命令延長過期時間:
Node 自動重啓
爲了保護 AKS 群集,安全更新自動應用於所有的 Linux 節點。 這些更新包括 OS 安全修復項或內核更新,其中的部分更新需要重啓節點才能完成。 AKS 不會自動重新啓動這些 Linux 節點,但你可以參考這裏配置 kured 來自動重啓節點。
除此之外,如果你還想收到節點需要重啓的通知,可以參考Dashboard and notifications on AKS for required worker nodes reboots 進行配置。
AKS Periscope
AKS Periscope 是一個用於排查 AKS 集群問題的調試工具,開源在 <github.com/Azure/aks-periscope>。
使用方法:
已知問題及修復版本
手動更新 VMSS VM 到最新時 Azure LoadBalancer 後端丟失問題
Basic LoadBalancer 修復版本: v1.14.7, v1.15.4, v1.16.0 及更高版本
Standard LoadBalancer 修復版本: v1.15.12, v1.16.9, v1.17.5, v1.18.1 及更高版本
Service 未配置 DNS 標籤導致公網 IP 上 DNS 標籤丟失問題
受影響版本:v1.17.0-v1.17.2, v1.16.0-v1.16.6, v1.15.7-v1.15.9, v1.14.10
修復版本:v1.15.10, v1.16.7, v1.17.3, v1.18.0 及更高版本
路由表併發更新衝突問題
修復版本:v1.15.11, v1.16.8, v1.17.4, v1.18.0 及更高版本
VMSS VM 併發更新衝突問題
修復版本:v1.15.11, v1.16.8, v1.17.4, v1.18.0 及更高版本
僅包含在 v1.18.0 或更高版本中的性能優化: https://github.com/kubernetes/kubernetes/pull/88699
VMSS 緩存不一致問題
受影響版本:v1.15.8-v1.15.11, v1.16.5-v1.16.8, v1.17.1-v1.17.4
修復版本:v1.15.12, v1.16.9, v1.17.5, v1.18.0 及更高版本
參考文檔
更多的 AKS 排錯信息可以參考 AKS 常見問題。
Last updated