CKA
CKA 준비에 도움이 되는 장애 대응 문제 955개를 모았습니다.
먼저 읽을 가이드
추천 문제
모든 문제 955개
K8S-1242CronJob은 제때 실행되는데 실제로 하는 일이 없음복사해 온 CronJob 템플릿이 유효해 보이는데, 클러스터나 클라우드 API에 접근하는 지점에서 매번 실패합니다.Kubernetes중급16분ProK8S-147Deployment가 maxUnavailable 0을 쓰는데도 노드 압박으로 옛 pod가 축출돼 롤아웃이 잠시 의도한 하한 아래로 떨어짐롤아웃 전략은 보수적인데 외부 eviction 압력이 업데이트 가정을 뒤엎습니다.Kubernetes중급16분ProK8S-1237Deployment는 Available로 보고되는데 트래픽이 계속 실패차트 리팩터나 앱 이름 변경이 깔끔히 배포되는데, 직후 Service나 Ingress 경로 하나가 죽습니다.Kubernetes중급16분ProK8S-363Gateway API route는 승인되는데 백엔드 참조 하나가 옛 ingress 컨트롤러만 이해하던 네임스페이스 alias를 계속 가리킴 (단계적 폐기 중)라우트 객체는 유효해 보이는데 컨트롤러 고유 가정 하나가 더 이상 성립하지 않습니다. 주 경로로는 서비스가 계속 되고, 옛 구성 요소가 완전히 빠질 때만 의존성 하나가 실패합니다.Kubernetes중급16분ProK8S-144headless Service가 pod A 레코드를 제대로 반환하는데 Java 클라이언트 하나가 첫 응답을 영영 캐시해 확장 후에도 분산하지 않음클러스터 DNS는 정확한데 라이브러리 하나의 조회 동작이 의도한 설계를 무력화합니다.Kubernetes중급16분ProK8S-124ingress rewrite 규칙이 websocket 경로의 끝 슬래시를 제거해, health check는 초록인데 대화형 세션만 실패일반 probe로는 서비스가 정상으로 보이는데 업그레이드된 연결이 미묘하게 다른 경로 계약에 걸립니다.Kubernetes중급16분ProK8S-381NetworkPolicy가 애플리케이션 경로는 허용하는데 node-local DNS 포워딩이 규칙이 기대한 것과 다른 source 신원을 사용 (단계적 폐기 중)앱 트래픽은 허용되는데 이름 해석이 실패합니다 — helper 경로가 더는 정책 전제와 맞지 않습니다. 주 경로로는 서비스가 계속 되고, 옛 구성 요소가 완전히 빠질 때만 의존성 하나가 실패합니다.Kubernetes중급16분ProK8S-399pod security standard가 base 이미지 하나는 허용하는데 장애 대응 중 디버그용 ephemeral 컨테이너가 restricted 계약을 위반 (단계적 폐기 중)정상 상태 워크로드는 준수하는데 긴급 진단 경로는 그렇지 않습니다. 주 경로로는 서비스가 계속 되고, 옛 구성 요소가 완전히 빠질 때만 의존성 하나가 실패합니다.Kubernetes중급16분ProK8S-270projected ConfigMap 갱신이 심볼릭 링크를 교체한 뒤 inotify 기반 sidecar가 엉뚱한 inode 집합을 감시 (failover 리허설 중)설정 변경은 있는데 watcher 로직이 올바른 파일시스템 이벤트를 끝내 보지 못합니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Kubernetes중급16분ProK8S-139롤아웃 중 HPA 축소 안정화가 여분 레플리카를 붙잡아, Deployment 예산이 다음 리비전에 필요한 용량을 끝내 비우지 못함뚜렷하게 깨진 건 없는데 컨트롤러 안전 창이 겹쳐 가용 자원에서 교착이 생깁니다.Kubernetes중급16분ProK8S-132복제한 PersistentVolume이 엉뚱한 reclaim policy를 물려받아, 테스트 claim을 지우자 마지막 남은 사본까지 삭제됨클론은 테스트용으로 안전해 보이는데 수명주기 플래그 하나가 아직 정리 동작을 원본 데이터 운명에 묶어둡니다.Kubernetes중급16분ProK8S-155앱이 downward API label에 의존하는데 롤아웃 컨트롤러가 label 키를 바꿔, pod가 크래시 없이 빈 파일을 계속 읽음배포는 성공하는데 런타임 설정이 조용히 나빠집니다 — 메타데이터 계약 하나가 바뀌었습니다.Kubernetes중급16분ProK8S-351주 API 호출에는 ServiceAccount 토큰 audience가 맞는데 admission sidecar가 같은 토큰을 다른 검증기로 전달 (단계적 폐기 중)pod 신원은 한 곳에서는 되는데 audience 검사가 더 엄격한 경로에서 재사용하면 실패합니다. 주 경로로는 서비스가 계속 되고, 옛 구성 요소가 완전히 빠질 때만 의존성 하나가 실패합니다.Kubernetes중급16분ProK8S-1228ConfigMap 키는 있는데 앱이 계속 크래시ConfigMap을 수정하면 마운트된 설정 파일이 제자리에서 갱신될 거라 여겨 애플리케이션 재시작을 건너뛰었습니다.Kubernetes중급17분ProK8S-318ConfigMap 핫 리로드가 주 컨테이너에서는 되는데 sidecar가 이전 스키마를 캐시한 채 마운트된 파일을 다시 열지 않음 (failover 리허설 중)pod에는 새 설정이 있는데 pod 안의 모든 프로세스가 그것을 아는 건 아닙니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Kubernetes중급17분ProK8S-1188ConfigMap은 제대로 바뀌었는데 애플리케이션이 새 값을 끝내 다시 로드하지 않음Kubernetes 객체 상태는 제대로 갱신되는데 실행 중인 프로세스가 옛 설정을 유지합니다 — 환경 변수나 시작 시점 설정만 읽습니다.Kubernetes중급17분ProK8S-234CSI 확장이 블록 디바이스 크기는 갱신했는데 pod 안 파일시스템은 계속 옛 지오메트리를 보고함 (failover 리허설 중)스토리지 컨트롤 플레인은 앞으로 나아갔는데 pod 안에서 보는 가용 용량은 그대로입니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Kubernetes중급17분ProK8S-300headless Service는 모든 pod 주소를 주는데 클라이언트 라이브러리가 축소 후에도 오래된 캐시 부분집합에서 무작위 선택 (failover 리허설 중)서비스 디스커버리는 정확한데 클라이언트가 더는 존재하지 않는 endpoint로 계속 연결합니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Kubernetes중급17분ProK8S-1222init 컨테이너는 완료되는데 앱이 계속 크래시init 컨테이너가 생성 설정을 성공적으로 만드는데 앱이 그것 없이 시작합니다.Kubernetes중급17분ProK8S-1204kubectl logs에 증상은 보이는데 원인은 안 보임현재 로그에는 probe나 wrapper 잡음만 있어 재시작 루프가 알 수 없어 보입니다. 정작 중요한 증거는 운영자가 보지 않은 직전 인스턴스에 있습니다.Kubernetes중급17분Pro