{"id":"IL-0034","org":"Airbnb","date":"2019-11-22","docs":[],"title":{"en":"A crashing stats agent sidecar marked every pod unready and the service mesh pulled all services out of traffic","ko":"메트릭 에이전트 사이드카가 업그레이드 중 크래시하자 클러스터의 모든 파드가 준비되지 않은 상태가 되어 서비스가 트래픽을 받지 못했다"},"domain":["kubernetes","observability"],"impact":{"scope":"all pods in the cluster marked not ready; services in the cluster stopped receiving traffic","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Every container in a pod affects the pod's readiness, so each sidecar needs a deliberate decision about how its health should count. A sidecar that crashes is not ready even when it has no probes, and any logic that requires all containers to be ready will take the pod out of traffic.","ko":"헬스 체크는 컨테이너마다 걸리므로 파드 안의 각 컨테이너가 파드 전체의 준비 상태에 어떻게 영향을 주는지 따져서 설정해야 한다. 프로브를 설정하지 않은 사이드카도 크래시하면 준비되지 않은 상태가 된다."},"related":[],"sources":[{"url":"https://www.youtube.com/watch?v=FrQ8Lwm9_j8","kind":"talk","license":"unknown","archived":null}],"summary":{"en":"This case comes from a KubeCon talk by two Airbnb engineers about ten ways Kubernetes broke at Airbnb. Airbnb's service discovery system, SmartStack, puts an HAProxy sidecar in every pod as its outbound proxy and decides which pods receive traffic. Its logic started from \"pod ready = true\", went through every container in the pod, set the pod to not ready if any container was not ready, and then published only ready pods to receive traffic.\n\nHealth checking in Kubernetes is per container, so every sidecar counts toward the pod's readiness. Earlier, to stop a failing stats agent from affecting services, the team had left probes off non-critical containers. When the stats agent crashed during a planned upgrade, the crashed container was not ready anyway, the service mesh logic marked the whole pod not ready, and all pods in the cluster stopped receiving traffic.\n\nThe fix went into the service mesh: containers such as the logger, tracing and the stats agent are labelled non-critical, and one added line in the readiness loop skips them. The speakers call it a stopgap that is still changing.","ko":"Airbnb 의 Melanie Cebula 와 Bruce Sherrod 가 발표 \"10 Weird Ways to Blow Up Your Kubernetes\"에서 소개한 장애 열 가지 가운데 하나다. Airbnb 는 파드마다 서비스 컨테이너 옆에 로깅, 트레이싱, 메트릭 수집 같은 사이드카를 함께 두고 운영했다. 서비스 디스커버리에는 2013년에 오픈소스로 공개한 SmartStack 을 썼다.\n\n쿠버네티스의 헬스 체크는 컨테이너마다 따로 건다. 레디니스 프로브가 실패하면 그 파드로 트래픽을 보내지 않고, 라이브니스 프로브가 실패하면 컨테이너를 교체한다. 대부분의 서비스는 두 프로브를 모두 /health 로 설정했다. 팀은 중요하지 않은 컨테이너가 서비스 상태를 좌우하면 안 된다고 보고 이 컨테이너들에 프로브를 설정하지 않았다. 하지만 크래시한 컨테이너는 프로브가 없어도 레디니스 검사에 실패한다는 사실을 몰랐다.\n\n당시 서비스 메시 로직은 파드의 컨테이너를 하나씩 확인해서 하나라도 준비되지 않았으면 파드 전체를 준비되지 않은 것으로 판단했고, 준비된 파드만 트래픽을 받도록 등록했다. 예정된 작업으로 메트릭 에이전트를 업그레이드하다가 이 에이전트 컨테이너가 크래시하자 레디니스 검사에 실패했다. 그 결과 클러스터의 모든 파드가 준비되지 않은 상태가 되어 서비스가 트래픽을 받지 못했다. 발표는 장애를 어떻게 끝냈는지, 얼마나 걸렸는지는 말하지 않는다."},"trigger":{"en":"A scheduled upgrade of the stats agent sidecar, during which the agent container crashed.","ko":"예정된 작업으로 쿠버네티스의 메트릭 에이전트를 업그레이드하던 중, 파드마다 들어 있던 메트릭 에이전트 사이드카 컨테이너가 크래시했다."},"severity":"unknown","symptoms":["readiness-probe-failures","service-unavailable"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"A reply to the operation announcement, a few minutes later, said that all of the sender's Kubernetes services appeared to be down.","ko":"작업 공지가 나가고 몇 분 뒤 서비스 담당자가 자기 쿠버네티스 서비스가 모두 내려간 것 같다는 메시지를 보내와서 알았다."},"components":["telemetry-agent","service-discovery"],"root_cause":"deploy-rollout","remediation":[],"action_items":[{"text":{"en":"Mark logging, tracing and stats agent containers as non-critical and leave them out of the service mesh's pod readiness check","ko":"로깅, 트레이싱, 메트릭 에이전트처럼 파드 준비 상태 판단에 넣지 않을 컨테이너를 중요하지 않은 컨테이너로 표시하고, 서비스 메시 로직이 파드 준비 상태를 판단할 때 이 컨테이너들을 건너뛰게 했다. 발표자는 이것을 임시 해결책이라고 했고 다른 방법도 검토했다고 했다."}}],"contributing":["assumption-unverified","blast-radius-too-wide"],"recurrence_of":null,"symptoms_text":{"en":"An operation to upgrade the stats agent in Kubernetes was announced in advance, with a warning that metrics might be unavailable to services for a few minutes. A few minutes later a reply came in saying that all of the sender's Kubernetes services seemed to be down.\n\nThe stats agent runs as a sidecar container in the pods. During the upgrade it crashed, and the crashing container made each pod unready. Because Airbnb's service discovery only sent traffic to pods it saw as ready, every pod in the cluster dropped out of traffic.\n\nThe team had expected this could not happen: they had already decided that a failing stats agent must not take a service down, and had removed the probes from non-critical containers such as logging, tracing and metrics. Removing the probes did not help, because a container that crashes fails its readiness check whether or not it has a probe.","ko":"쿠버네티스의 메트릭 에이전트를 업그레이드하는 작업이 예정되어 있다는 공지가 나갔다. 공지에는 몇 분 동안 서비스가 메트릭을 쓰지 못할 수 있다고 적혀 있었다. 몇 분 뒤 한 서비스 담당자가 자기 쿠버네티스 서비스가 지금 모두 내려간 것 같다는 메시지를 보냈다.\n\n업그레이드 중 메트릭 에이전트 컨테이너가 크래시했고, 이 컨테이너가 레디니스 검사에 실패했다. 서비스 메시 로직은 컨테이너 하나라도 준비되지 않으면 파드 전체를 준비되지 않은 것으로 보고 트래픽 대상에서 뺐다. 그래서 클러스터의 모든 파드가 준비되지 않은 상태가 되어 트래픽을 받지 못했다.\n\n팀은 이 장애 전에 이미 메트릭 에이전트 때문에 서비스가 내려가면 안 된다고 정해 두었다. 그래서 로깅, 트레이싱, 메트릭 같은 중요하지 않은 컨테이너에는 프로브를 설정하지 않았고, 이 컨테이너들은 서비스 상태에 영향을 주지 않는다고 생각했다."},"updated_at":"2026-11-10T00:00:38.041604Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0034","org_slug":"airbnb"}