IL-0146 Microsoft Azure · 2020-12-04kubernetesazurenetworking
2020년 12월 4일 00:00 UTC 무렵부터 12월 15일 00:10 UTC 무렵까지 Central India 에서 Azure CNI 로 새로 만든 클러스터에 터널 연결 문제가 생길 수 있었다. kubenet 을 쓰는 클러스터는 영향이 없었다.
이 리전의 VM 들이 이전보다 훨씬 높은 값의 MAC 주소를 받기 시작했다. 평소에는 00 으로 시작했는데 이번에는 06 으로 시작하는 주소가 나왔다. 그러자 Azure CNI 에서 오랫동안 드러나지 않던 버그가 나타났다. 이 버그는 bridge 모드에서만 문제가 됐고, 더 이상 bridge 를 쓰지 않는 최신 Azure CNI 는 영향을 받지 않았다.
Microsoft 는 VMAS 클러스터에는 클러스터를 늘린 뒤 영향을 받은 VM 을 지우라고 안내했다. VMSS 클러스터에는 노드 이미지를 업그레이드해 최신 CNI 를 받는 방법이 가장 안전하다고 권했다. 쿠버네티스 패치 버전 업그레이드로도 고칠 수 있었고, 막 만든 클러스터라면 다시 만드는 것도 방법이었다. 이미 있는 클러스터는 이 절차로 직접 업그레이드해야 했다.
2020년 12월 4일 00:00 UTC 무렵부터 Central India 에서 Azure CNI 로 새로 만든 AKS 클러스터에 터널 연결 문제가 생겼다. 진단 페이지에는 터널 exec 문제가 표시됐다.
kubectl exec 와 kubectl logs 가 타임아웃될 수 있었다. 파드와 파드 사이, 파드와 노드 사이의 통신도 타임아웃될 수 있었다. kubenet 을 쓰는 클러스터는 영향을 받지 않았다.
영향을 받았는지는 노드에서 `ip addr show eth0 && cat /etc/cni/net.d/10-azure.conflist` 를 실행해 확인할 수 있었다. VMSS 는 `az vmss run-command invoke`, VMAS 는 `az vm run-command invoke` 로 같은 명령을 돌릴 수 있었다. 출력에 `link/ether 60:45:..` 와 `"mode":"bridge"` 가 함께 나오면 영향을 받은 노드였다. `link/ether 00:0d:..` 이면서 bridge 모드이거나, `link/ether 60:45:..` 이면서 `"mode":"transparent"` 이면 영향을 받지 않았다.
증상 ? 간헐적 타임아웃
원인 ? 소프트웨어 결함
–
VM 에 배정되는 MAC 주소 범위처럼 플랫폼 쪽에서 바뀐 값 하나가 오래 드러나지 않던 CNI 버그를 드러낼 수 있다. 같은 증상이라도 노드의 MAC 주소와 CNI 모드를 함께 봐야 영향 여부를 가를 수 있다.
같은 원인 · 공통 노드 운영체제 이미지
같은 원인 · 공통 노드 운영체제 이미지
같은 원인 · 공통 노드 운영체제 이미지
같은 원인 · 공통 노드 운영체제 이미지
같은 원인 · 공통 노드 운영체제 이미지