23장 쿠버네티스가 지키려는 원하는 상태

컨테이너가 몇 개일 때는 사람이 직접 실행하고 확인할 수 있다. 수가 늘고 서버도 여러 대가 되면 어디에서 실행할지, 실패하면 어떻게 대체할지, 새 버전을 어떻게 나눠 적용할지 관리가 어려워진다. 쿠버네티스는 원하는 상태를 선언하고 실제 상태를 그에 맞추려는 제어 구조를 제공한다. 명령 한 번으로 모든 것이 즉시 완료되는 시스템으로 보면 기다리는 상태를 이해하기 어렵다.

예를 들어 복제본 세 개를 원한다고 선언하면 컨트롤러는 현재 상태와 비교해 필요한 작업을 한다. 하지만 자원이 부족하거나 이미지를 받을 수 없거나 저장소를 연결하지 못하면 원하는 상태에 도달하지 못할 수 있다. 선언이 받아들여졌다는 사실과 배포가 준비됐다는 사실은 다르다. 상태와 이벤트를 읽는 일이 필수적이다.

Pod는 컨테이너와 같지 않다

Pod는 함께 배치되고 일부 실행 환경을 공유하는 하나 이상의 컨테이너를 묶는 단위다. 흔히 주요 컨테이너 하나를 담지만 보조 컨테이너와 함께 구성할 수도 있다. 같은 Pod 안의 컨테이너는 네트워크 환경을 공유하므로 localhost로 서로 통신할 수 있다. 다른 Pod에 있는 프로그램도 localhost로 찾을 수 있다고 생각하면 안 된다.

Pod는 교체될 수 있는 단위다. 특정 Pod의 IP를 영구 주소처럼 저장하면 교체 후 연결이 깨진다. Service는 선택된 대상에 접근할 안정적인 이름과 접근 방식을 제공하는 추상화다. 실제 구현과 유형은 여러 가지다. Service를 만들었다고 반드시 인터넷에 공개되는 것은 아니며, 외부 공개에는 별도의 유형과 입구 설정을 확인해야 한다.

준비와 생존을 구별하기

readiness 검사는 트래픽을 받을 준비가 되었는지 판단하는 데 사용한다. liveness 검사는 다시 시작이 필요한 상태를 판단하는 데 쓰인다. startup 검사는 느린 시작 과정에 시간을 주는 데 도움이 된다. 이름이 비슷하다고 같은 경로와 같은 조건을 무작정 복사하면 문제가 생길 수 있다. 데이터베이스가 잠시 느리다는 이유로 모든 Pod가 재시작하는 구성을 피해야 한다.

검사 간격과 실패 횟수는 탐지 속도와 오탐의 균형이다. 너무 민감하면 작은 지연에 계속 교체되고, 너무 느리면 사용자가 오래 실패를 겪는다. 시작 시간과 평소 응답 분포를 측정해 정해야 한다. 검사 엔드포인트는 외부에 불필요한 내부 상태나 비밀을 노출하지 않도록 구성한다. 운영 편의를 위한 경로도 접근 범위를 고려해야 한다.

자원을 요청하고 제한하기

자원 요청값은 배치 판단에 사용되고 한도는 실행 중 사용을 제한하는 데 관여한다. CPU와 메모리는 제한에 걸렸을 때의 동작도 다르다. 메모리 한도를 넘으면 프로세스가 종료될 수 있고 CPU는 사용이 조절될 수 있다. 구체적인 동작은 환경과 설정을 확인해야 한다. 숫자를 너무 낮게 잡아 비용을 절약하려다가 불안정한 재시작과 긴 응답 시간을 만들 수 있다.

모든 응용 프로그램에 같은 자원값을 적용하는 것은 편하지만 좋은 근거는 아니다. 시작 순간과 평상시, 배치 작업 시의 사용량을 나누어 측정한다. 복제본을 늘릴 때 공유 데이터베이스와 외부 서비스가 감당할 수 있는지도 확인한다. 쿠버네티스는 다른 시스템의 한도를 자동으로 이해해 주지 않는다. 전체 경로의 용량 계획은 여전히 운영자의 일이다.

네임스페이스는 완전한 보안벽이 아니다

네임스페이스는 자원을 논리적으로 구분하고 관리하는 데 유용하다. 그러나 이름을 나누었다고 통신과 권한이 자동으로 완전히 분리되는 것은 아니다. 역할 기반 접근 제어와 네트워크 정책, 비밀 관리, 실행 권한을 함께 설계해야 한다. 네트워크 정책의 실제 적용에는 사용하는 네트워크 플러그인의 지원도 관련된다.

Secret이라는 이름 역시 저장과 접근의 모든 위험을 해결했다는 뜻은 아니다. 기본 표현 방식과 저장 시 암호화, 접근 권한, 로그 노출을 각각 확인해야 한다. 비밀을 YAML 파일에 넣어 공개 저장소에 올리거나 명령 출력 전체를 공유하면 이름과 관계없이 유출된다. 안전한 비밀 관리 절차는 플랫폼의 자원 이름보다 넓은 문제다.

작은 서비스에 쿠버네티스를 도입하려면 얻는 이점과 관리할 제어 시스템을 함께 계산하자. 업그레이드, 네트워크, 저장소, 권한, 장애 대응을 누가 맡는지 정하지 않고 시작하면 배포 편의보다 운영 부담이 커질 수 있다. 사용하지 않기로 한 결정도 충분한 기술적 판단이 될 수 있다. 필요한 복잡성만 받아들이는 것이 성숙한 설계다.