Incident Library

IL-0505 Binder Project · 2019-02-20kubernetesgcp

GKE 에서 kubectl logs 가 모든 파드에서 실패해 mybinder.org 사용자에게 빌드 로그가 가지 않았다

2019년 2월 20일 08:03 CET 부터 mybinder.org 의 GKE 클러스터에서 kubectl logs 가 모든 파드에서 No SSH tunnels currently open 오류로 실패했다. 파드 로그를 가져오지 못해 사용자에게 빌드 로그가 전달되지 않았고, 10:12 에는 작은 배포도 같은 이유로 실패했다. 빌드와 실행은 계속됐고 실행 성공률은 97.5% 아래로 떨어지지 않았다.

10:20 에 예정된 클러스터 업그레이드를 시작했지만 마스터 업그레이드와 새 노드로는 고쳐지지 않았다. 노드 쪽 SSH 설정을 하나씩 확인해 문제가 없는 것을 보고, 업그레이드로도 고쳐지지 않는 마스터 쪽 문제라고 판단했다. 12:00 에 API 서버 로그에서 노드 gke-prod-a-users-b921bb88-rd5d 의 주소를 얻지 못한다는 오류를 찾았다. 쿠버네티스는 그 노드의 ExternalIP 와 InternalIP 를 잃은 상태였다. 노드를 cordon 해 비운 뒤 풀에서 빼자 13:30 에 kubectl logs 가 돌아왔다. 운영팀은 쿠버네티스 마스터나 GKE 서비스 자체의 버그로 보인다고 적었다.

심각도
–
영향 범위
mybinder.org: users saw no build logs for new builds and kubectl logs failed for all pods; builds and launches kept working, with launch success never below 97.5%
영향 사용자
mybinder.org users running new builds
지역
–
감지까지
–
복구까지
5h 27m

증상

kubectl logs -f <pod> 가 모든 파드에서 실패했다. mybinder.org 는 파드 로그로 빌드 로그를 전달하므로 사용자가 새 빌드의 로그를 보지 못했다. 빌드 자체는 정상으로 돌았다.

오류는 Error from server: Get https://10.128.0.6:10250/containerLogs/prod/jupyter-.../notebook?follow=true: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-df315ed616f010764e03"? 였다. 10:12 에는 작은 버전 올림 배포도 SSH 터널을 만들지 못해 실패했다.

같은 문제가 2019-01-08 에도 한 번 있었다. 그때는 24시간 이어지다가 원인을 모른 채 저절로 사라졌다.

운영팀은 마스터를 업그레이드하고 새 노드를 들이면 나을 것으로 보고 예정된 클러스터 업그레이드를 시작했다. 새 노드가 다 뜬 11:17 에도 kubectl logs 는 Error from server: Get https://10.128.0.17:10250/...?follow=true: No SSH tunnels currently open. 으로 실패했다.

GKE 문제 해결 문서를 따라 마스터의 노드 SSH 접근을 점검했다. ssh-key 메타데이터는 넘치지 않았고, gke-df315ed616f010764e03 의 키가 모든 노드의 /home/gke-df315ed616f010764e03/.ssh/authorized_keys 에 있었고, 방화벽 규칙도 마스터의 SSH 를 허용했다. journalctl | grep df315 로 보니 마스터는 SSH 를 시도한 적이 없었다. 노드 쪽에는 마스터를 막는 것이 없었다.

kubectl proxy 로 받은 kube-apiserver.log 에서 ssh 를 찾자 E0220 10:59:57.797466 1 ssh.go:200] Failed to getAddresses: no preferred addresses found; known addresses: [{Hostname gke-prod-a-users-b921bb88-rd5d}] 가 되풀이돼 있었다.

kubectl get node -o json | jq '.items[] | [.status.addresses[].address]' 로 보니 이 노드만 ExternalIP 와 InternalIP 없이 ["", "gke-prod-a-users-b921bb88-rd5d"] 로 나왔다.

증상 모니터링 중단배포 실패

원인

원인 클라우드 제공자 장애

구성 요소 GKE 컨트롤 플레인쿠버네티스 API 서버
기여 요인 디버그 접근 제한
촉발
–

감지

–

조치

후속 조치

교훈

kubectl logs 가 안 되고 클러스터 전체를 업그레이드하는 동안에도 실행 성공률은 97.5% 아래로 떨어지지 않았다. 문제 노드를 빼자 모두 돌아왔다. 원인이 쿠버네티스 마스터나 GKE 서비스 자체의 버그로 보여서 찾기가 아주 어려웠다. 노드를 의심했을 때 kubectl describe node gke-prod-a-users-b921bb88-rd5d 를 받아 두었으면 정상 노드와 비교할 수 있었다. 노드 주소 목록에서 ExternalIP 와 InternalIP 가 빠진 것은 이 문제의 직접 증상으로 보이고 앞으로 진단에 쓸 수 있다.

출처

참고 문서

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: GKE 컨트롤 플레인, 쿠버네티스 API 서버. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.