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 모드를 함께 봐야 영향 여부를 가를 수 있다.
IL-0171 Bottlerocket AMI 에 libdcgm.so 가 없어 GPU 노드의 AcceleratedHardwareReady 가 False 가 됐고, Karpenter 노드 자동 복구가 Ready 뒤 10~11분마다 GPU 노드를 교체하는 일을 끝없이 되풀이했다.Inflab · 2025같은 원인 · 공통 노드 운영체제 이미지
IL-0147 AKS 202508 노드 이미지가 캐시되지 않은 쿠버네티스 바이너리를 받을 때 HTTP 프록시 설정을 쓰지 않아, 프록시 뒤에 있는 노드의 프로비저닝이 CSE 종료 코드 31 로 실패했다.Microsoft · 2025같은 원인 · 공통 노드 운영체제 이미지
IL-0112 나중에 회수된 EKS 노드 AMI 로 노드를 교체한 뒤 노드가 PLEG is not healthy 를 보고하며 NotReady 를 오갔고 파드 네트워크 타임아웃이 났다DFDS · 2022같은 원인 · 공통 노드 운영체제 이미지
같은 원인 · 공통 노드 운영체제 이미지
같은 원인 · 공통 노드 운영체제 이미지
https://incidentlib-mcp.benchlet.com/mcpAPI 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.