사례47건

47건 중 15~19번째

1. IL-0007 EKS 클러스터에서 VPC-CNI 가 파드마다 VPC IP 를 쓰다가 서브넷 IP 가 바닥나 파드가 IP 를 받지 못했다

   Adevinta2024

   증상

   어느 저녁 일부 DaemonSet 이 실패하고 있다는 호출이 왔다. 당직자가 서버에 들어가 파드 상태를 보니 다음 오류가 찍혀 있었다: name=“aws-cni” failed (add): add cmd: failed to assign an IP address to container

   IP 주소 고갈파드 Pending

   촉발

   첫 호출의 계기는 원문에 나오지 않는다. 호출은 6월, kube-aws 기반 SCHIP 에서 EKS 기반 클러스터로 옮기던 중에 왔다. 원문은 클러스터의 IP 가 바닥나는 경우로, 잡이 폭주하거나 실패하면서도 회수될 때까지 IP 를 붙잡고 있어 파드가 갑자기 늘어나는 경우를 든다.

   원인

   용량 한계

   구성 요소

   AWS VPC CNIVPC 서브넷 또는 파드 주소 범위Karpenter

   기여 요인

   기본 설정 방치용량 계획 부재

   감지

   어느 저녁 일부 DaemonSet 이 실패한다는 호출이 왔다. 당직자가 서버에 들어가 파드 상태를 확인하다 aws-cni 의 IP 할당 실패 오류를 보았다. 팀은 그전부터 IP 사용량을 감시하고 있었다.

   조치

   • 8월 말부터 작은 클러스터에 Secondary CIDR 를 쓰는 VPC-CNI 커스텀 네트워킹을 배포했다.
   • 9월에 사용 가능한 IP 가 너무 적어지자 EKS 이전을 잠시 멈췄다.
   • 커스텀 네트워킹을 나머지 클러스터 전체에 배포했다.
   • Karpenter 배포에 --reserved-enis 파라미터를 더했다.

   후속 조치

   • 커스텀 네트워킹을 나머지 클러스터 전체에 배포해 IP 여유를 되찾고 EKS 이전을 끝냈다.
   • Karpenter 배포에 --reserved-enis 파라미터를 더해 커스텀 네트워킹이 쓰는 첫 번째 ENI 를 빼고 노드당 파드 수를 계산하게 했다.

   교훈

   플랫폼 팀이나 클러스터 운영자가 용량 계획에 시간을 들이지 않으면, VPC-CNI 는 큰 규모의 운영 환경에 바로 쓸 수 있는 도구가 아니다. 선택지마다 장단점이 있다. 지금 큰 클러스터를 새로 띄운다면 더 싸고 앞으로도 오래 쓸 수 있는 IPv6 를 쓸 수 있는지 먼저 확인할 만하다. 작은 클러스터에서 되던 것이 규모를 키워도 된다고 가정하면 안 된다. 예측과 용량 계획을 잘하면 이 요구는 감당할 수 있다. 하지만 폭주하는 잡이나, 실패하면서도 회수될 때까지 IP 를 붙잡는 잡을 여럿 띄우는 잘못된 설정 때문에 파드가 갑자기 늘 수 있다.

   사례 보기
2. IL-0046 계획된 재시작 뒤 Prometheus 가 WAL 을 다 읽기 전에 startupProbe 에 걸려 재시작을 반복했고 지표가 빠졌다

   UK Ministry of Justice2024

   증상

   2024-04-15 12:32 에 계획된 Prometheus 변경을 적용한 뒤 Prometheus 를 쓸 수 없게 되었다. 팀은 prometheus 파드가 여러 번 재시작한 것을 보았다. 그동안 Cloud Platform 에는 모니터링이 없었고 지표가 빠졌다.

   모니터링 중단프로브 실패

   촉발

   계획된 변경으로 Prometheus 를 재시작했는데 그때 WAL 수가 평소보다 많아, WAL 다시 읽기가 startupProbe 기본 허용 시간인 15분 안에 끝나지 않았다.

   원인

   용량 한계

   구성 요소

   Prometheus

   기여 요인

   기본 설정 방치한계 미인지

   감지

   계획된 Prometheus 변경 뒤 팀이 prometheus 파드가 여러 번 재시작한 것을 보고 알았다. 처음 감지한 시각은 2024-04-15 12:32 였다.

   조치

   • startupProbe 허용 시간을 기본값 15분에서 30분으로 늘려 WAL 다시 읽기가 끝날 때까지 기다리게 했다.

   후속 조치

   • 팀은 계획된 Prometheus 재시작을 WAL 수가 적을 때 해서 재시작 시간을 줄이는 방안을 논의했다.
   • Prometheus 의 기본 CPU 와 메모리 요청값을 최대 사용량에 맞춰 설정했다.
   • 운영 환경의 WAL 수를 재현하는 테스트 환경을 만든다.
   • memory-snapshot-on-shutdown 과 auto-gomaxprocs 기능 플래그를 검토한다.
   • WAL 파일을 다른 위치의 원격 저장소에 두는 방법을 검토한다.
   • 운영과 같은 구성의 블루그린 Prometheus 를 만들어 운영에 적용하기 전에 변경을 시험하는 방안을 알아본다.
   • Amazon Managed Prometheus 를 간단히 조사한다.

   사례 보기
3. IL-0128 1만 개 넘는 GPU 로 학습하는 클러스터에서 네트워크 인터페이스가 몇 초씩 끊겼다 붙는 플래핑이 NCCL 타임아웃을 일으켜 학습이 멈추거나 느려졌다.

   ByteDance2024

   증상

   학습이 멈추거나 학습 속도가 떨어지는 일이 가끔 일어났다. 원인은 네트워크 인터페이스가 자주 끊겼다 다시 붙는 플래핑이었다.

   링크 플래핑NCCL 타임아웃처리량 저하

   촉발

   네트워크 인터페이스가 몇 초 동안 내려갔다가 다시 올라오는 플래핑이 일어났다.

   원인

   DNS·네트워크 장애

   구성 요소

   NCCLNIC·케이블·스위치 포트 링크

   기여 요인

   기본 설정 방치

   감지

   MegaScale 은 초 단위 모니터링으로 링크 플래핑 같은 NIC 문제를 추적한다. 하트비트에 담긴 RDMA 트래픽 지표가 크게 떨어지거나 비정상적으로 흔들리면 드라이버가 사람이 조사하도록 알림을 보내고, 트래픽이 완전히 끊기면 자동으로 장애 복구 절차를 시작한다.

   조치

   • NCCL 의 타임아웃 기준을 기본값보다 큰 값으로 명시적으로 잡았다.
   • 링크 플래핑에서 빨리 회복하도록 NCCL 의 재전송 타이머와 재시도 횟수를 조정했다.
   • NIC 의 adap_retrans 기능을 켰다.
   • 네트워크 카드 신호 세기, AOC 케이블 품질, 스위치 쪽 신호 세기를 하드웨어 수준에서 관리해 플래핑 빈도를 줄였다.

   교훈

   타임아웃 기준은 기본값에 맡기지 말고 명시적으로 크게 잡아야 한다. 기본값으로 두면 NCCL 은 네트워크 카드가 돌아오기 전에 타임아웃을 낸다. 플래핑의 근본 원인은 링크 품질이었다. 네트워크 카드, AOC 케이블, 스위치의 신호 품질을 하드웨어 수준에서 관리하고 나서야 빈도가 줄었다.

   사례 보기
4. IL-0065 Argo CD의 Redis 캐시가 기본으로 암호 없이 클러스터 안 모든 파드에 열려 있어, 캐시된 매니페스트를 바꿔치기해 클러스터를 장악할 수 있었다

   Cycode2024

   증상

   운영 중 장애로 드러난 증상은 없다. 이 사례는 Cycode Labs가 Argo CD를 조사하다 찾은 취약점 CVE-2024-31989이고, 심각도 점수는 9.1이다.

   무단 접근과 낯선 워크로드

   촉발

   클러스터 안의 권한 낮은 파드 하나가 kube-DNS로 Argo CD Redis 주소를 찾아 6379 포트로 암호 없이 접속할 수 있었다. Argo CD는 캐시에 든 매니페스트를 cacheEntryHash로 검증했는데, 이 해시는 비밀 키 없이 fnv64a로 만든 값이라 누구나 다시 계산할 수 있었다.

   원인

   소프트웨어 결함

   구성 요소

   Argo CD

   기여 요인

   기본 설정 방치과도한 영향 범위설정 내 자격 증명

   감지

   Cycode Labs가 Argo CD의 쿠버네티스 구성 요소를 조사하다 찾았다. 2024년 1월 18일 GitHub Security Advisories로 Argo CD 팀에 알렸다.

   조치

   • Argo CD 팀이 2024년 5월 21일 Redis 서버 암호를 미리 정해 두는 2.11.1, 2.10.10, 2.9.15, 2.8.19 버전을 냈다. 사전 정보 없이는 Redis에 접속할 수 없게 됐지만, 문제를 일부만 막는 조치였다.

   교훈

   Argo CD를 2.11.1, 2.10.10, 2.9.15, 2.8.19 이상으로 올린다. argocd-redis-network-policy 네트워크 정책이 있고 켜져 있는지 확인한다. 네트워크 정책이 실제로 적용되려면 CNI가 제대로 설정돼 동작해야 한다. Argo CD 플러그인으로 Secret을 넣지 말고 컨트롤러 방식의 Secret 관리 도구를 써서 Secret이 Redis에 남지 않게 한다. 보안을 더 챙기려면 Argo CD를 다른 애플리케이션과 분리된 전용 클러스터에 둔다. 비밀 키 없이 만든 해시는 아무나 다시 계산할 수 있어서 무결성을 지켜 주지 못한다.

   사례 보기
5. IL-0153 DOKS 1.27.6-do.0 과 1.28.2-do.0 워커 노드에서 매일 아침 도는 apt 자동 업그레이드가 15분 타임아웃에 걸려 강제 종료되면서 노드 네트워킹이 망가지고, 노드가 사흘 연속 NotReady 가 됐다.

   DigitalOcean2023

   증상

   2023년 10월 8일 06:00 UTC 무렵부터 일부 Managed Kubernetes 클러스터의 워커 노드가 NotReady 가 됐고, 그 노드에서 돌던 서비스와 애플리케이션이 멈췄다. 07:43부터 노드를 교체하면 해결되는 워커 노드 장애를 알리는 고객 보고가 드문드문 들어왔다.

   노드 NotReady서비스 중단

   촉발

   DigitalOcean Debian 이미지의 systemd 타이머가 매일 06:00 UTC에 최대 60분의 무작위 지연을 두고 apt 업그레이드를 시작했다.

   원인

   설정 변경

   구성 요소

   노드 운영체제 이미지리눅스 커널kubelet

   기여 요인

   기본 설정 방치디버그 접근 제한늦게 드러난 변경

   감지

   10월 8일 07:43 UTC부터 노드 교체로 해결되는 워커 노드 장애를 알리는 고객 보고가 드문드문 들어왔다. 장애가 시작되고 약 1시간 43분 뒤였다. 내부 장애 대응은 영향이 여러 리전으로 번진 뒤인 10월 9일 07:10에 시작됐다.

   조치

   • 고객에게 영향받은 머신을 교체하거나 재부팅해 장애를 줄이라고 안내했다.
   • 장애가 없는 동안 워커 노드에 SSH 와 콘솔 접근을 마련했고, 10월 10일 영향받은 노드에 붙어 실시간으로 디버깅했다.
   • 각 워커 노드에서 apt 업그레이드 systemd 타이머를 끄는 DaemonSet 을 만들어 10월 11일 03:08 UTC에 영향받은 모든 클러스터에 배포했다.
   • 자동 업그레이드 과정을 없앤 새 노드 이미지를 배포했다.

   후속 조치

   • 노드 프로비저닝 과정에서 같은 수정을 적용해 워커 노드에 타이머가 처음부터 켜지지 않게 한다. 그 뒤 모든 클러스터에서 DaemonSet 을 지운다.
   • 새 클러스터 버전마다 도는 내부 적합성 테스트에 자동 업그레이드와 원하지 않는 다른 타이머가 꺼져 있는지 확인하는 검사를 넣었다.
   • 평소 쓰는 접근 경로가 막혀도 워커 노드 머신에 로그인할 수 있게 한다.

   교훈

   베이스 이미지에 기본으로 켜진 자동 업그레이드 타이머가 운영 중인 노드에 지원하지 않는 패키지 버전을 들일 수 있다. 업그레이드 중 커널 같은 시스템 패키지가 타임아웃으로 강제 종료되면 노드 네트워킹이 망가질 수 있다. 네트워크가 끊긴 노드에 들어갈 방법이 없으면 깊은 조사는 장애가 없는 시간까지 밀린다. 매일 같은 시각에 반복되고 특정 버전에만 나는 장애는 노드에서 주기적으로 도는 작업을 가리켰다.

   사례 보기

원인별11