Kubernetes

함께 실행해야 하는 컨테이너를 파드로 구성했을 때의 배치·네트워크·파일 공유를 살펴봅니다.

한 파드의 컨테이너들은 같은 노드에 배치되고 네트워크를 공유합니다.

공유 볼륨을 마운트하면 같은 파일을 사용할 수 있습니다. 파드의 컨테이너들은 포트 공간도 공유하므로 같은 주소의 같은 포트를 동시에 사용할 수 없습니다.

보조 컨테이너와 앱을 함께 배치할지 정하거나, 파드 내부 통신과 볼륨 공유를 이해할 때 사용합니다.

파드를 실행하는 노드의 구성 요소와 자원, 장애 후 복구 과정을 살펴봅니다.

파드는 하나의 노드에서 실행되며, 다른 노드에서 실행하려면 대체 파드를 생성합니다.

kubelet과 컨테이너 런타임이 파드 실행을 관리합니다. 스케줄러는 노드의 할당 가능 자원을 확인해 배치하며, 노드 장애 시 기존 파드를 이동하는 대신 새 파드를 만들 수 있습니다.

노드 자원과 파드 배치를 구분하고, 장애 시 파드의 이름·IP가 바뀌는 이유를 이해할 때 활용합니다.

정해진 횟수만큼 성공하면 종료되는 작업을 Job으로 실행합니다.

Job은 실행 중인 파드 수가 아니라 작업의 성공 횟수를 관리합니다.

completions는 필요한 성공 횟수, parallelism은 동시 실행할 파드 수를 정합니다. 실패한 작업은 설정된 한도까지 재시도하며, CronJob으로 반복 일정을 지정할 수 있습니다.

정산, 데이터 이전, 일회성 처리와 예약 작업을 실행할 때 사용합니다.

선언한 파드 수와 실제 상태가 다를 때 쿠버네티스가 어떻게 복구하는지 살펴봅니다.

컨트롤러는 원하는 상태와 현재 상태를 반복해서 비교해 필요한 작업을 수행합니다.

API 서버에 저장한 설정을 바탕으로 파드를 생성하고, 스케줄러가 실행할 노드를 정하며, kubelet이 컨테이너 실행을 관리합니다. 장애로 개수가 부족해지면 대체 파드를 생성합니다.

선언적 설정과 컨트롤러의 역할을 이해하거나 장애 복구가 어떤 구성 요소에서 진행되는지 확인할 때 사용합니다.

새 버전의 파드를 점진적으로 생성하고 기존 파드를 종료하는 롤링 업데이트를 살펴봅니다.

새 ReplicaSet을 늘리고 기존 ReplicaSet을 줄여 파드의 버전을 교체합니다.

사용 가능한 파드 수와 추가 생성 수는 업데이트 설정에 따라 달라집니다. 준비 상태를 확인한 뒤 기존 파드를 종료하며, 이전 ReplicaSet을 이용해 롤백할 수 있습니다.

배포 중 가용성을 유지하는 조건과 버전 교체·롤백 과정을 이해할 때 사용합니다.

HPA가 CPU 사용률을 확인해 파드 수를 늘리거나 줄이는 과정을 살펴봅니다.

현재 지표와 목표의 비율로 필요한 파드 수를 계산하고 설정한 최소·최대 범위를 적용합니다.

작은 지표 변화에는 허용 오차를 적용하고, 축소 시에는 안정화 시간을 둘 수 있습니다. 파드 수를 조절하는 HPA와 노드 용량을 조절하는 기능은 구분해야 합니다.

부하 변화에 대응할 파드 수의 목표와 범위, 잦은 증감 방지 설정을 이해할 때 활용합니다.

readiness·liveness·startup 검사가 요청 전달과 컨테이너 재시작에 미치는 영향을 살펴봅니다.

readiness는 요청을 받을 준비를, liveness는 재시작이 필요한 상태를 확인합니다.

readiness 실패만으로 컨테이너를 종료하지는 않습니다. liveness 실패는 재시작으로 이어질 수 있으며, 시작이 느린 앱에는 startupProbe로 초기화 시간을 확보할 수 있습니다.

상태 검사 기준을 정하거나 트래픽 제외와 컨테이너 재시작을 구분할 때 사용합니다.

파드가 교체되거나 늘어나도 같은 이름으로 접속할 수 있도록 서비스를 사용합니다.

서비스는 선택 조건에 맞는 파드를 찾고 안정적인 접속 주소를 제공합니다.

파드의 IP가 바뀌어도 라벨이 일치하면 연결 대상으로 등록할 수 있습니다. readiness 등 준비 상태에 따라 요청을 전달할 엔드포인트를 관리합니다.

파드 IP를 직접 참조하지 않는 서비스 연결과 배포 중 요청 분배를 이해할 때 활용합니다.

인그레스 규칙으로 외부 HTTP 요청을 여러 서비스에 전달하는 과정을 살펴봅니다.

요청의 호스트 이름과 경로를 확인해 대상 서비스를 선택합니다.

규칙을 실제로 적용하려면 인그레스 컨트롤러가 필요합니다. 이 예제는 하나의 외부 주소를 공유하고 인그레스에서 TLS 연결을 종료하는 구성을 사용합니다.

여러 도메인과 경로의 요청을 분배하거나 외부 접속과 인증서 처리 위치를 설계할 때 활용합니다.

이미지를 바꾸지 않고 환경별 설정을 전달하는 ConfigMap과 Secret을 살펴봅니다.

설정은 환경변수나 마운트한 파일로 컨테이너에 전달할 수 있습니다.

환경변수 값은 기존 컨테이너에 자동 갱신되지 않습니다. 일반적인 ConfigMap 볼륨의 파일은 갱신되지만 앱이 다시 읽어야 합니다. Secret의 인코딩은 암호화가 아니므로 접근 권한과 저장 데이터 보호도 설정해야 합니다.

개발·운영 환경의 설정을 분리하고 설정 변경의 반영 방식과 민감한 값의 관리 방법을 정할 때 사용합니다.

컨테이너 쓰기 계층·emptyDir·영구 볼륨의 데이터 보존 범위를 비교합니다.

emptyDir는 파드의 수명을 따르고, PVC로 연결한 영구 볼륨은 파드 교체 후에도 유지할 수 있습니다.

컨테이너를 새로 만들면 쓰기 계층은 초기화되지만 같은 파드의 emptyDir는 남습니다. 영구 데이터는 PVC로 요청한 볼륨에 저장하며, 접근 모드와 회수 정책을 함께 설정합니다.

캐시·임시 파일과 보관할 데이터를 구분하고 파드 재시작·교체 시 데이터가 남는 위치를 판단할 때 사용합니다.

스케줄러가 자원 요청과 배치 조건으로 파드를 실행할 노드를 선택하는 과정을 살펴봅니다.

현재 사용량이 아니라 선언한 requests를 기준으로 자원이 충분한 노드를 찾습니다.

배치 조건을 만족하는 노드를 거른 뒤 점수 정책으로 후보를 평가합니다. limits는 실행 중 자원 사용의 상한이며, CPU 제한과 메모리 초과의 동작은 다릅니다.

파드의 자원 요청을 정하거나 Pending 상태, 노드 선택과 자원 부족의 원인을 확인할 때 사용합니다.