{"id":"IL-0505","org":"Binder Project","date":"2019-02-20","docs":["https://cloud.google.com/kubernetes-engine/docs/troubleshooting","https://github.com/jupyterhub/mybinder.org-deploy/issues/900","https://github.com/jupyterhub/mybinder.org-deploy/issues/901"],"title":{"en":"kubectl logs failed on GKE with \"No SSH tunnels currently open\" and mybinder.org build logs stopped reaching users","ko":"GKE 에서 kubectl logs 가 모든 파드에서 실패해 mybinder.org 사용자에게 빌드 로그가 가지 않았다"},"domain":["kubernetes","gcp"],"impact":{"scope":"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%","users":"mybinder.org users running new builds","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"The root cause was very difficult to identify, partly because it appears to sit in the Kubernetes master or the GKE service itself. Capturing `kubectl describe node` for the suspicious node would have allowed a comparison with healthy nodes, and a node that reports no ExternalIP or InternalIP in its status was likely a direct symptom of the problem and can be used as a diagnostic in the future.","ko":"kubectl logs 가 안 되고 클러스터 전체를 업그레이드하는 동안에도 실행 성공률은 97.5% 아래로 떨어지지 않았다. 문제 노드를 빼자 모두 돌아왔다. 원인이 쿠버네티스 마스터나 GKE 서비스 자체의 버그로 보여서 찾기가 아주 어려웠다. 노드를 의심했을 때 kubectl describe node gke-prod-a-users-b921bb88-rd5d 를 받아 두었으면 정상 노드와 비교할 수 있었다. 노드 주소 목록에서 ExternalIP 와 InternalIP 가 빠진 것은 이 문제의 직접 증상으로 보이고 앞으로 진단에 쓸 수 있다."},"related":[],"sources":[{"url":"https://github.com/jupyterhub/mybinder.org-deploy/blob/main/docs/source/incident-reports/2019-02-20-no-logs.md","kind":"github","archived":null}],"summary":{"en":"On 20 February 2019 one node of the mybinder.org GKE cluster, gke-prod-a-users-b921bb88-rd5d, had lost its ExternalIP and InternalIP in its node status, and the Kubernetes API server repeatedly failed to get addresses for it. From 08:03 CET kubectl logs, which reached the nodes' port 10250 through SSH tunnels from the master, failed for all pods with \"No SSH tunnels currently open\", so build logs no longer reached users and a deploy failed. The write-up says the cause appears to be a bug in the Kubernetes master and/or the GKE service itself, which made the root cause very hard to identify; upgrading the master and bringing in new nodes did not fix it.\n\nAfter the API server log pointed at the node, it was cordoned so it would be removed from the pool once empty. At 13:30, with the node drained and removed, kubectl logs worked again. Throughout the incident and the cluster upgrade, launch success never fell below 97.5% and was only very briefly below 100%.","ko":"2019년 2월 20일 08:03 CET 부터 mybinder.org 의 GKE 클러스터에서 kubectl logs 가 모든 파드에서 No SSH tunnels currently open 오류로 실패했다. 파드 로그를 가져오지 못해 사용자에게 빌드 로그가 전달되지 않았고, 10:12 에는 작은 배포도 같은 이유로 실패했다. 빌드와 실행은 계속됐고 실행 성공률은 97.5% 아래로 떨어지지 않았다.\n\n10:20 에 예정된 클러스터 업그레이드를 시작했지만 마스터 업그레이드와 새 노드로는 고쳐지지 않았다. 노드 쪽 SSH 설정을 하나씩 확인해 문제가 없는 것을 보고, 업그레이드로도 고쳐지지 않는 마스터 쪽 문제라고 판단했다. 12:00 에 API 서버 로그에서 노드 gke-prod-a-users-b921bb88-rd5d 의 주소를 얻지 못한다는 오류를 찾았다. 쿠버네티스는 그 노드의 ExternalIP 와 InternalIP 를 잃은 상태였다. 노드를 cordon 해 비운 뒤 풀에서 빼자 13:30 에 kubectl logs 가 돌아왔다. 운영팀은 쿠버네티스 마스터나 GKE 서비스 자체의 버그로 보인다고 적었다."},"trigger":null,"severity":"unknown","symptoms":["monitoring-down","deploys-failing"],"timeline":{"detected_after":null,"resolved_after":"5h 27m"},"date_kind":"incident","detection":null,"components":["gke-control-plane","kube-apiserver"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"Cordoned node gke-prod-a-users-b921bb88-rd5d so it would be removed from the pool once empty","ko":"API 서버 로그가 가리킨 노드 gke-prod-a-users-b921bb88-rd5d 를 cordon 하고, 비면 풀에서 빼기로 했다."}},{"text":{"en":"Drained the node and removed it from the pool, after which kubectl logs worked again","ko":"rd5d 노드를 drain 해 풀에서 빼자 kubectl logs 가 돌아오고 모두 정상으로 동작했다."}}],"action_items":[{"text":{"en":"Test that kubectl logs works and notify when it does not","ko":"kubectl logs 가 동작하는지 시험하고 동작하지 않으면 알림을 보낸다."}},{"text":{"en":"Add the command for retrieving API server logs to the SRE guide","ko":"API 서버 로그를 받는 명령을 SRE 가이드에 넣는다."}},{"text":{"en":"Describe in the SRE guide how to identify suspicious node networking status","ko":"의심스러운 네트워크 상태를 알아보는 방법을 SRE 가이드에 적는다."}}],"contributing":["limited-debug-access"],"recurrence_of":null,"symptoms_text":{"en":"On 20 February 2019 at 08:03 CET, `kubectl logs -f <pod>` stopped working for every pod in the mybinder.org cluster on GKE. Because pod logs could not be read, build logs were no longer forwarded to users, although the builds themselves ran normally.\n\nThe command failed with \"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\"?\". At 10:12 a deploy of a minor version bump failed because the SSH tunnels could not be created. The same failure had happened once before, on 2019-01-08, lasted 24 hours and went away without ever being diagnosed.\n\nA planned cluster upgrade began at 10:20 in the hope that a new master and new nodes would fix it, but at 11:17, with the new nodes running and the old ones still draining, kubectl logs failed with the same error. Following the GKE troubleshooting documentation, the team checked the master's SSH access to the nodes: the ssh-key metadata was not too full, the key for gke-df315ed616f010764e03 was in authorized_keys on all nodes, firewall rules allowed SSH from the master, and journalctl showed no SSH attempt from the master at all. Nothing on the nodes was stopping the master from opening a tunnel.\n\nAt 12:00 the API server log, fetched through `kubectl proxy` from /logs/kube-apiserver.log, showed a repeated \"Failed to getAddresses: no preferred addresses found; known addresses: [{Hostname gke-prod-a-users-b921bb88-rd5d}]\" among many repeats of the SSH tunnel error. Listing node addresses with `kubectl get node -o json | jq '.items[] | [.status.addresses[].address]'` showed that node gke-prod-a-users-b921bb88-rd5d had no InternalIP or ExternalIP, only an empty string and its hostname.","ko":"kubectl logs -f <pod> 가 모든 파드에서 실패했다. mybinder.org 는 파드 로그로 빌드 로그를 전달하므로 사용자가 새 빌드의 로그를 보지 못했다. 빌드 자체는 정상으로 돌았다.\n\n오류는 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 터널을 만들지 못해 실패했다.\n\n같은 문제가 2019-01-08 에도 한 번 있었다. 그때는 24시간 이어지다가 원인을 모른 채 저절로 사라졌다.\n\n운영팀은 마스터를 업그레이드하고 새 노드를 들이면 나을 것으로 보고 예정된 클러스터 업그레이드를 시작했다. 새 노드가 다 뜬 11:17 에도 kubectl logs 는 Error from server: Get https://10.128.0.17:10250/...?follow=true: No SSH tunnels currently open. 으로 실패했다.\n\nGKE 문제 해결 문서를 따라 마스터의 노드 SSH 접근을 점검했다. ssh-key 메타데이터는 넘치지 않았고, gke-df315ed616f010764e03 의 키가 모든 노드의 /home/gke-df315ed616f010764e03/.ssh/authorized_keys 에 있었고, 방화벽 규칙도 마스터의 SSH 를 허용했다. journalctl | grep df315 로 보니 마스터는 SSH 를 시도한 적이 없었다. 노드 쪽에는 마스터를 막는 것이 없었다.\n\nkubectl 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}] 가 되풀이돼 있었다.\n\nkubectl get node -o json | jq '.items[] | [.status.addresses[].address]' 로 보니 이 노드만 ExternalIP 와 InternalIP 없이 [\"\", \"gke-prod-a-users-b921bb88-rd5d\"] 로 나왔다."},"updated_at":"2026-11-14T12:34:14.997840Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0505","org_slug":"binder-project"}