Kubernetes Workload Conformance: 인증된 클러스터에서도 앱이 멈추는 이유

클러스터는 정상인데 점검이 끝나지 않는 상황

사내 주문 조회 API를 다른 Kubernetes 서비스로 옮겼다고 하자. 배포는 성공했고 평소 요청도 잘 처리한다. 그런데 노드 운영체제를 업데이트하려고 앱을 다른 노드로 내보내는 단계에서 작업이 멈춘다. 또는 점검은 끝났지만, 그동안 일부 조회 요청이 시간 초과된다.

두 경우 모두 “Kubernetes가 호환된다”는 말만으로는 원인을 찾기 어렵다. 클러스터가 제공하는 기능과 앱이 그 기능을 이용하는 방식, 사용자가 받아야 할 결과가 서로 다른 층에 있기 때문이다.

2026년 10월 27일 Kubernetes 커뮤니티는 Workload Conformance Working Group 출범을 발표했다. 앱의 실행 중 동작을 공통 기준과 반복 가능한 시험으로 확인하자는 작업이다. 발표 당시에는 구체적인 요구사항과 시험법을 아직 합의하지 않았다. 안정된 첫 규격과 시험을 마련하는 목표는 Kubernetes 릴리스 두세 주기이며, 특정 날짜의 제공을 약속한 것은 아니다. 작업반 출범 발표

이 글은 11월 3일 확인한 문헌 분석이다. 아래 점검 사례는 테크독해가 만든 가정이며 실제 클러스터를 실행하거나 인증 시험을 통과한 결과가 아니다.

무엇이 인증되는지부터 구분한다

클러스터는 노드·네트워크·제어 기능을 묶어 앱을 실행하는 환경이다. 워크로드는 그 환경에서 실행할 앱과 작업을 뜻한다. Pod는 하나 이상의 컨테이너를 함께 실행하는 Kubernetes의 기본 단위이고, 복제본은 같은 역할을 맡는 Pod를 여러 개 두는 방식이다.

확인 대상	답하려는 질문	팀이 별도로 확인할 것
Certified Kubernetes	클러스터가 Kubernetes의 표준 동작을 제공하는가?	우리 앱이 요구하는 환경과 운영 조건
Kubernetes AI Conformance	클러스터가 AI·ML 작업에 필요한 기반 기능을 갖추었는가?	특정 모델의 품질·속도와 업무 적합성
추진 중인 Workload Conformance	워크로드가 합의된 실행 동작을 지키는가?	앱 고유의 업무 로직과 결과

10월 29일 공개된 AI Conformance 인터뷰는 AI 기반 기능에 초점을 맞추며 특정 프레임워크나 모델 서버에 종속되지 않는 방향을 설명한다. 작업반의 초기 목표를 달성한 뒤 SIG Architecture의 상설 하위 프로젝트로 옮겼다는 점도 확인된다. 이는 이번에 출범한 Workload Conformance와 별개의 진행 상황이다. AI Conformance의 범위와 운영

Workload Conformance의 헌장 고정본은 Kubernetes 마이너 버전별 실행 동작, 이를 검증할 방법, 상류 프로젝트의 시험 도구를 연결한다. 보안·중단 대응·자원·네트워크·저장·API 사용·관측 가능성이 범위에 들어간다. 요구사항은 프로그램으로 객관적으로 확인할 수 있어야 한다.

같은 헌장은 업무 로직, 특정 패키징 형식이나 공급자 도구의 강제, 클러스터 기반 기능의 재시험을 범위 밖으로 둔다. 표준 승인 전에는 Kubernetes 프로젝트가 인증 프로그램을 지지하거나 지원하지 않으며, 인증 프로그램 운영 자체도 작업반의 일이 아니다. 따라서 지금 제품 소개에 “새 Workload Conformance 인증 완료”라고 적을 근거로 이 출범 소식을 사용할 수 없다.

표준화의 잠재적 이익은 운영자마다 반복하던 앱 검사를 공통 증거로 바꾸는 데 있다. 다만 이는 필자의 해석이다. 아직 정해지지 않은 요구사항이나 절감 시간을 예측해 확정할 수는 없다.

첫 관문: PDB가 허용하는 것은 복제본의 중단이다

노드 점검에서 drain은 그 노드에서 관리 대상 Pod를 퇴거시키는 절차다. 정상적인 퇴거 경로는 Eviction API를 사용하고 PodDisruptionBudget(PDB)을 존중한다. PDB는 계획된 중단 중 유지해야 할 정상 복제본 수 등을 표현한다. 퇴거가 거절되면 drain은 재시도하거나 설정한 시간 제한에 도달할 수 있다. PDB와 중단 처리

여기서 정상 여부의 신호인 Ready와 실제 처리 여력을 구별해야 한다. 다음은 모든 Pod가 같은 역할을 하고, 다른 중단이나 처리 중인 퇴거가 없으며, PDB 상태가 최신이라는 단순화한 사례다. 부하와 처리량은 측정값이 아니다.

• 현재 정상 복제본: 4개
• PDB의 정수 설정: minAvailable: 3
• 점검 중 감당해야 할 요청: 초당 180건
• 응답 목표를 지키며 Pod 하나가 처리한다고 가정한 용량: 초당 55건

이 조건에서 복제본 하나를 퇴거시킬 여유는 있다. 하지만 남은 세 개의 계산상 용량은 3 × 55 = 165건/초로 요청 180건보다 작다. 퇴거 허용과 서비스 용량 충족이 동시에 성립하지 않는 사례다.

같은 가정에서 필요한 최소 정상 복제본은 올림(180 ÷ 55) = 4개다. 한 개씩 퇴거하면서 네 개를 유지하려면 점검 전 다섯 개가 필요하다. PDB만 minAvailable: 4로 바꾸고 복제본은 네 개로 두면, 용량 부족을 없앤 것이 아니라 그 퇴거를 막는 구성이 된다.

가상 설정	한 개 퇴거	남는 용량	판단
복제본 4, 최소 정상 3	개수 조건상 가능	165건/초	요청 180건을 감당하지 못함
복제본 4, 최소 정상 4	개수 조건상 차단	퇴거 전 220건/초	점검을 진행할 추가 조건이 필요
복제본 5, 최소 정상 4	개수 조건상 가능	220건/초	다음으로 종료·재배치를 시험

이 산술은 PDB 컨트롤러 시뮬레이터가 아니다. 실제로는 disruptionsAllowed, 선택된 Pod, 이미 진행 중인 중단, Ready 전환을 확인해야 한다. 다섯 번째 Pod를 놓을 자원이 없거나 모든 복제본이 같은 장애 영역에 몰려 있으면 숫자만 늘려도 계획이 성립하지 않는다. 처리량도 선형으로 합산되지 않을 수 있다. 공통 DB가 병목이면 다섯 개 구성의 이점부터 실제 부하로 확인해야 한다.

반대로 목표 요청량이 초당 120건이라면 세 개의 가정 용량 165건으로도 계산상 충분하다. 점검 시간대를 바꾸는 선택과 용량을 늘리는 선택을 함께 비교할 수 있다는 뜻이다. 어느 경우든 이 숫자를 운영 환경의 보장으로 가져가서는 안 된다.

두 번째 관문: 종료 유예는 요청 완료 시간과 맞아야 한다

복제본을 충분히 남겨도 퇴거 중인 Pod의 요청은 별도로 처리해야 한다. Kubernetes 문서의 일반적인 종료 절차에서는 preStop 훅이 먼저 실행되고, 컨테이너에 종료 신호를 보낸 뒤 유예 시간이 지나면 남은 프로세스를 강제로 종료한다. 기본 terminationGracePeriodSeconds는 30초이며, 훅 실행 시간도 이 예산 안에 포함된다. Pod 종료 절차

종료 신호 이후에야 새 요청을 받지 않고 남은 요청을 마치는 단일 컨테이너 앱을 가정하자. preStop이 8초, 신호 뒤 가장 오래 남은 요청 처리에 25초, 운영상 여유로 5초를 잡으면 필요한 예산은 8 + 25 + 5 = 38초다. 기본 30초보다 길다. 이 시나리오에서 45초를 시험 후보로 삼을 수는 있지만, 45초면 항상 안전하다는 결론은 아니다.

훅이 끝날 때까지 처리를 전혀 못 하는지, 실제 요청은 훅과 함께 진행되는지에 따라 식이 달라진다. 위 계산은 순차 처리를 가정한 것이다. 문서의 작은 일회성 훅 연장 동작을 정상 처리 예산으로 기대하지 않는다.

또한 종료하는 Pod의 EndpointSlice에는 종료 상태가 반영되고 일반적인 트래픽용 Ready 상태가 false가 된다. 이것을 모든 프록시·기존 연결이 같은 순간에 사라진다는 보장으로 읽으면 안 된다. 실제 경로에서 새 요청이 언제 멈추고 기존 요청이 언제 끝나는지 함께 관측해야 한다. 종료 중 엔드포인트 처리

긴 작업을 반드시 한 연결에서 끝낼 필요가 없다면, 작업 ID를 남겨 재조회하거나 중단 뒤 이어 처리하도록 앱 구조를 바꿀 수도 있다. 이는 이 글의 설계 선택지이며 Kubernetes가 자동으로 제공하는 업무 복구 기능은 아니다.

팀이 지금 만들 수 있는 것은 앱 인수 시험이다

아래는 공식 Workload Conformance 규격을 대신하는 목록이 아니라, 주문 API의 점검 가능 여부를 판단하기 위한 미실행 시험 설계다. 운영 점검 명령부터 실행하지 말고 격리된 시험 클러스터와 합성 요청으로 조건을 고정한다.

시험에서 볼 것	남길 증거	실패했을 때 다음 판단
퇴거가 가능한가	PDB 선택 대상·현재 정상 수·disruptionsAllowed, 퇴거 응답	셀렉터 오류인지, 이미 줄어든 정상 수인지, 예산 부족인지 구분
남은 Pod가 요청을 감당하는가	동일 입력·도착률에서 성공 건수, 시간 초과, 응답 지연	점검 시간대·복제본 수·공통 의존성 병목 비교
진행 중 요청을 마치는가	요청 ID별 시작·완료와 훅·종료 신호·프로세스 종료 시각	유예 확대 또는 중단·재처리 방식 변경
대체 Pod가 준비되는가	Pending 사유, 배치 노드, 볼륨 연결, Ready 도달 시각	자원·배치 제약·저장장치 조건을 나눠 조사
점검 후 업무가 맞는가	요청한 주문 ID와 응답 내용의 대조	정상 응답 코드만으로 업무 정합성 통과 처리하지 않음

앱 이미지와 설정, Kubernetes 버전, 관련 네트워크·저장 구성, 부하 입력, 합격 기준을 실행 전에 기록한다. 앱의 지연 목표는 팀이 정해야 한다. 시험 중 허용 실패를 넘거나 복구 상태가 불명확하면 다음 노드의 점검을 멈추고 원인을 확인한다. 다른 환경으로 옮겼을 때는 이 조건 중 달라진 것을 중심으로 다시 시험한다.

공식 drain 가이드에서 명령 성공은 제외 대상 외의 Pod가 정해진 절차로 퇴거되었음을 뜻한다. 업무 요청이 모두 성공했다는 시험 결과는 아니다. 점검 후 스케줄링을 다시 허용하는 단계도 따로 있다. 이 때문에 명령 종료 코드와 앱 결과를 한 칸에 기록하면 안 된다.

노드 점검 인수 시험 기록지 내려받기

기록지는 관측값을 비워 두었다. 복제본·용량·시간의 가정 계산과 실제 실행 기록을 별도 칸으로 나눴다. 아직 돌리지 않은 시험을 성공으로 채우지 않고, 다음 운영자에게 입력과 중단 사유를 넘기는 용도로 쓸 수 있다.

PDB로 다룰 수 없는 실패도 남는다

PDB는 노드 고장 같은 비자발적 중단 자체를 막지 않는다. Pod나 Deployment의 직접 삭제는 PDB를 우회할 수 있으며, 앱의 롤링 업데이트는 해당 워크로드의 배포 설정으로 제어한다. 따라서 이번 노드 점검 결과를 장애 전체나 모든 배포 방식의 보장으로 확장할 수 없다. 중단의 종류와 PDB의 한계

배치 작업이라면 요청 지연보다 체크포인트·재시작·중복 실행을 볼 수 있고, 상태 저장 앱이라면 남은 복제본 수뿐 아니라 데이터 복제와 쓰기 가능 조건이 중요하다. 모든 앱에 “복제본 다섯 개”를 강제하는 표준은 이 사례에서 나오지 않는다.

노드에서 앱을 내보내는 절차를 이해한 뒤 외부 의존성 장애로 시험 범위를 넓히려면 AWS Resilience Hub의 업무 지속 시험을 이어 읽을 수 있다. GPU를 공유할 때 새 버전을 올릴 공간이 문제라면 ECS의 배포 여유 계산이 다른 상황을 다룬다.

다음 점검 때는 기록지를 열어 퇴거가 허용되는가, 남은 앱이 감당하는가, 진행 중 일을 끝내는가를 각각 확인해 보자. 새 표준의 세부 요구사항이 공개되면 이 내부 증거 중 재사용할 부분과 추가할 시험을 구분할 수 있다. 이 글을 저장해 두거나 인프라 주제 모음에서 관련 운영 원리를 이어 볼 수 있다.