Azure

Last updated 1 year ago

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 負載均衡相比有一定的：

Load Balancer

Basic

Standard

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 相比也有一定的：

Public IP

Basic

Standard

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

在 Kubernetes 中，負載均衡的創建邏輯都在 kube-controller-manager 中，因而排查負載均衡相關的問題時，除了查看 Service 自身的狀態，如

kubectl describe service <service-name>

還需要查看 kube-controller-manager 是否有異常發生：

PODNAME=$(kubectl -n kube-system get pod -l component=kube-controller-manager -o jsonpath='{.items[0].metadata.name}')
kubectl -n kube-system logs $PODNAME --tail 100

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 恢復）
後端容器未監聽在設置的端口上（可通過配置正確的端口解決）
防火牆或網絡安全組阻止了要訪問的端口（可通過增加安全規則解決）
後端容器不響應（部分或者全部）外部請求時也會導致負載均衡 IP 無法訪問。注意這裏包含部分容器不響應的場景，這是由於 Azure 探測器與 Kubernetes 服務發現機制共同導致的結果：
- （1）Azure 探測器定期去訪問 service 的端口（即 NodeIP:NodePort）
- （2）Kubernetes 將其負載均衡到後端容器中
- （3）當負載均衡到異常容器時，訪問失敗會導致探測失敗，進而 Azure 可能會將 VM 移出負載均衡

內網負載均衡 BackendPool 爲空

外網負載均衡均衡 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 是否不同：

$ kubectl get node -o jsonpath='{.items[*].metadata.name}'
k8s-agentpool1-27347916-0
$ kubectl get node -o jsonpath='{.items[*].spec.externalID}'
/subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.Compute/virtualMachines/k8s-agentpool1-27347916-0

該問題的解決方法是先刪除 Node kubectl delete node <node-name>，爲 Kubelet 配置 --cloud-provider=azure --cloud-config=/etc/kubernetes/cloud-config，最後再重啓 Kubelet。

Service 刪除後 Azure 公網 IP 未自動刪除

MSI 無法使用

Azure ARM API 調用請求過多

有時 kube-controller-manager 或者 kubelet 會因請求調用過多而導致 Azure ARM API 失敗的情況，比如

"OperationNotAllowed",\r\n    "message": "The server rejected the request because too many requests have been received for this subscription.

一般來說，如果該問題重複出現可以考慮

使用 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 --v=8 logs x
I0308 10:32:21.539580   26486 round_trippers.go:417] curl -k -v -XGET  -H "Accept: application/json, */*" -H "User-Agent: kubectl/v1.8.1 (linux/amd64) kubernetes/f38e43b" -H "Authorization: Bearer x" https://x:443/api/v1/namespaces/default/pods/x/log?container=x
I0308 10:34:32.790295   26486 round_trippers.go:436] GET https://X:443/api/v1/namespaces/default/pods/x/log?container=x 500 Internal Server Error in 131250 milliseconds
I0308 10:34:32.790356   26486 round_trippers.go:442] Response Headers:
I0308 10:34:32.790376   26486 round_trippers.go:445]     Content-Type: application/json
I0308 10:34:32.790390   26486 round_trippers.go:445]     Content-Length: 275
I0308 10:34:32.790414   26486 round_trippers.go:445]     Date: Thu, 08 Mar 2018 09:34:32 GMT
I0308 10:34:32.790504   26486 request.go:836] Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Get https://aks-nodepool1-53392281-1:10250/containerLogs/default/x: dial tcp 10.240.0.6:10250: getsockopt: connection timed out","code":500}
I0308 10:34:32.790999   26486 helpers.go:207] server response object: [{
  "metadata": {},
  "status": "Failure",
  "message": "Get https://aks-nodepool1-53392281-1:10250/containerLogs/default/x/x: dial tcp 10.240.0.6:10250: getsockopt: connection timed out",
  "code": 500
}]
F0308 10:34:32.791043   26486 helpers.go:120] Error from server: Get https://aks-nodepool1-53392281-1:10250/containerLogs/default/x/x: dial tcp 10.240.0.6:10250: getsockopt: connection timed out

在 AKS 中，kubectl logs, exec, and attach 等命令需要 Master 與 Nodes 節點之間建立隧道連接。在 kube-system namespace 中可以看到 tunnelfront 和 kube-svc-redirect Pod：

$ kubectl -n kube-system get po -l component=tunnel
NAME                           READY     STATUS    RESTARTS   AGE
tunnelfront-7644cd56b7-l5jmc   1/1       Running   0          2d

$ kubectl -n kube-system get po -l component=kube-svc-redirect
NAME                      READY     STATUS    RESTARTS   AGE
kube-svc-redirect-pq6kf   1/1       Running   0          2d
kube-svc-redirect-x6sq5   1/1       Running   0          2d
kube-svc-redirect-zjl7x   1/1       Running   1          2d

如果它們不是處於 Running 狀態或者 Exec/Logs/PortForward 等命令報 net/http: TLS handshake timeout 錯誤，刪除 tunnelfront Pod，稍等一會就會自動創建新的出來，如：

$ kubectl -n kube-system delete po -l component=tunnel
pod "tunnelfront-7644cd56b7-l5jmc" deleted

使用 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 設備插件擴展：

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  labels:
    kubernetes.io/cluster-service: "true"
  name: nvidia-device-plugin
  namespace: kube-system
spec:
  template:
    metadata:
      # Mark this pod as a critical add-on; when enabled, the critical add-on scheduler
      # reserves resources for critical add-on pods so that they can be rescheduled after
      # a failure.  This annotation works in tandem with the toleration below.
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ""
      labels:
        name: nvidia-device-plugin-ds
    spec:
      tolerations:
      # Allow this pod to be rescheduled while the node is in "critical add-ons only" mode.
      # This, along with the annotation above marks this pod as a critical add-on.
      - key: CriticalAddonsOnly
        operator: Exists
      containers:
      - image: nvidia/k8s-device-plugin:1.10
        name: nvidia-device-plugin-ctr
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
        volumeMounts:
          - name: device-plugin
            mountPath: /var/lib/kubelet/device-plugins
      volumes:
        - name: device-plugin
          hostPath:
            path: /var/lib/kubelet/device-plugins
      nodeSelector:
        beta.kubernetes.io/os: linux
        accelerator: nvidia

Azure ServicePrincipal 過期

默認情況下，Service Principal 的過期時間是 1 年，可以通過以下的命令延長過期時間：

az ad sp credential reset --name <clientId> --password <clientSecret> --years <newYears>

Node 自動重啓

AKS Periscope

使用方法：

az extension add --name aks-preview
az aks kollect -g MyResourceGroup -n MyManagedCluster --storage-account MyStorageAccount --sas-token "MySasToken"

已知問題及修復版本

手動更新 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 及更高版本
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 及更高版本

參考文檔

Previous雲平臺排錯 Next排錯工具

Last updated 1 year ago