CKA
CKA 준비에 도움이 되는 장애 대응 문제 955개를 모았습니다.
먼저 읽을 가이드
추천 문제
모든 문제 955개
K8S-375CSI 스냅샷 복원은 성공했는데 init 스크립트 하나가 앱 시작 전에 오래된 사이드 채널에서 데이터 디렉터리를 다시 채움 (단계적 폐기 중)복구는 되는데 첫 시작 경로가 조용히 그것을 덮어씁니다. 주 경로로는 서비스가 계속 되고, 옛 구성 요소가 완전히 빠질 때만 의존성 하나가 실패합니다.Kubernetes고급18분ProK8S-121DaemonSet surge 업데이트가 hostPort 바인딩을 두 배로 만들어 절반의 노드에서 새 pod가 끝내 Ready가 되지 않음서류상 롤아웃 전략이 더 안전해 보이는데 host 레벨 포트 배타성 때문에 옛 pod와 새 pod가 겹칠 수 없습니다.Kubernetes고급18분ProK8S-156externalSecrets 컨트롤러가 Secret을 갱신하는데 마운트된 CSI 볼륨이 직전 버전을 캐시해 앱이 섞인 자격 증명을 봄secret 상태는 중앙에서 갱신되는데 전달 경로마다 런타임에 서로 다른 세대를 서빙합니다.Kubernetes고급18분ProK8S-111Gateway API는 HTTPRoute를 accepted로 보고하는데 listener hostname 불일치로 실제 연결이 이뤄지지 않음상태 조건은 유망해 보이는데 트래픽이 끝내 도착하지 않습니다 — route가 컨트롤러에 받아들여지긴 했는데 의도한 hostname listener에 바인딩되지 않았습니다.Kubernetes고급18분ProK8S-1241HPA가 Deployment를 확장하는데 지연이 계속 나쁨canary 롤아웃에 오토스케일링을 추가했는데, 늘어난 pod가 정작 흡수해야 할 트래픽을 받지 못합니다.Kubernetes고급18분ProK8S-1235init 작업이 권한은 고치는데 주 컨테이너가 계속 실패CSI 마운트와 init 로직의 상대적 타이밍에 따라 pod가 어떤 재시작에서는 성공하고 어떤 때는 실패합니다.Kubernetes중급18분ProK8S-1216init 컨테이너는 맞아 보이는데 계속 빈 secret 파일을 읽음pod가 마운트된 secret을 읽는 init 단계를 거쳐 부팅하는데 콜드 스타트에서만 실패합니다.Kubernetes고급18분ProK8S-136mutating webhook이 timeoutPolicy Ignore를 써서 객체가 일부만 변형된 채 통과, 일부 pod만 기대한 sidecar 설정을 받음admission이 더는 막지 않는데 워크로드 동작이 갈립니다 — 지연 상황에서 mutation 계약이 더는 결정적이지 않습니다.Kubernetes고급18분ProK8S-186Pod Security가, 볼륨 소유권 모델이 의존하던 init 컨테이너 우회를 차단 (failover 리허설 중)앱과 볼륨은 따로 보면 정상인데 호환용 shim이 더는 실행을 허용받지 못합니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Kubernetes고급18분ProK8S-294Secret store CSI 볼륨은 제대로 갱신되는데 init 컨테이너가 옛 값을 앱이 계속 쓰는 쓰기 가능 경로에 복사해 둠 (failover 리허설 중)secret 소스는 최신인데 애플리케이션이 앞서 만들어둔 낡은 그림자 사본을 계속 읽습니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Kubernetes고급18분ProK8S-264source-range 규칙이 노드 주소를 신뢰하는데 externalTrafficPolicy Local이 zone 하나에 유효한 ingress 경로를 남기지 않음 (failover 리허설 중)로드밸런서 정책은 맞는데 locality가 실제로 트래픽을 받을 수 있는 노드를 바꿉니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Kubernetes고급18분ProK8S-345topology spread 규칙은 균형 잡혀 보이는데 정작 비상 폴백 pod가 실제로 뜰 수 있는 유일한 곳이 taint 걸린 노드 풀 하나 (단계적 폐기 중)장애가 스케줄러를 호환 taint를 가진 유일한 도메인으로 몰아넣기 전까지는 분산이 공평해 보입니다. 주 경로로는 서비스가 계속 되고, 옛 구성 요소가 완전히 빠질 때만 의존성 하나가 실패합니다.Kubernetes고급18분ProK8S-102topology spread 제약은 유효해 보이는데 matchLabelKeys가 새 롤아웃 리비전을 제외해 새 pod가 전부 한 zone에 몰림서류상 정책은 정상으로 보이는데 새 ReplicaSet만 분산 규칙에서 빠집니다 — 그 리비전 label이 spread match 집합에 들어 있지 않습니다.Kubernetes고급18분ProK8S-252validating admission 정책이 생성은 허용하고 갱신을 막음Kubernetes고급18분ProK8S-324validating 정책이 생성 요청은 허용하는데 컨트롤러가 만든 갱신 경로가 필드 불변성 전제를 위반 (failover 리허설 중)원래 manifest 형태는 유효한데 컨트롤러 자신의 이후 변형 경로가 그렇지 않습니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Kubernetes고급18분ProK8S-141노드 drain이 PodDisruptionBudget은 지키는데 커스텀 컨트롤러가 헬퍼 pod를 즉시 다시 만들어 drain이 끝내 수렴하지 않음Kubernetes는 제대로 동작하는데 다른 컨트롤러가 점검이 축출하려는 바로 그 pod를 계속 다시 채웁니다.Kubernetes고급18분ProK8S-160노드 이미지 업그레이드가 cgroup v2를 켜자 Java 워크로드 하나가 힙 한도를 잘못 보고하기 시작해 HPA가 엉뚱한 사용률 기준으로 스케일앱은 계속 도는데 노드 이미지와 함께 런타임 메모리 집계가 바뀌어 오토스케일링 결정을 왜곡합니다.Kubernetes고급18분ProK8S-216로컬 스토리지 워크로드가 정상으로 보이다가 축소가 지역성을 만족하는 유일한 노드를 제거 (failover 리허설 중)데이터가 남아 있어 컴퓨트 용량은 유지되는데 스케줄 가능성이 사라집니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Kubernetes고급18분ProK8S-1220메모리를 올리자 pod 재시작은 멈췄는데 롤아웃이 계속 실패팀이 직접적인 크래시 원인은 고쳤는데, health 타이밍 계약을 갱신하지 않아 롤아웃을 끝내지 못합니다.Kubernetes고급18분ProK8S-123복원된 PersistentVolume이 옛 zone의 node affinity를 유지해 대체 pod가 새 리전 구간에서 끝내 마운트하지 못함스토리지 측면에서는 복원이 성공했는데 스케줄링과 attach 로직이 계속 원본 토폴로지를 반영합니다.Kubernetes고급18분Pro