Quartz 4

정리 문제

52 min read

1장

  1. 쿠버네티스 클러스터의 모든 상태 정보를 저장하는 유일한 컴포넌트는? a. API 서버 b. 스케줄러 c. etcd d. 쿠블릿

  2. 구글이 매주 수십억 개의 컨테이너를 관리하기 위해 사용했던 내부 시스템은? a. Docker b. Borg c. Linux d. CNCF

  3. 워커 노드에서 실행되며 컨테이너를 실행하고 상태를 보고하는 에이전트는? a. 쿠브 프록시 b. 컨트롤러 c. 쿠블릿 d. 컨테이너 런타임

  4. 다음 중 마이크로서비스가 몇 개 이상일 때 쿠버네티스 도입이 가장 권장되는가? a. 1개 b. 5개 c. 10개 d. 20개

  5. 개발자가 결과 상태를 기술하면 시스템이 이를 실현하고 유지하는 모델의 명칭은? 정답: 선언적 모델

  6. 하드웨어 세부 사항을 숨기고 전체 클러스터를 하나의 배포 영역으로 보이게 하는 계층은? 정답: 인프라 추상화

  7. kubectl 명령줄 도구가 실제로 통신하는 중앙 컴포넌트의 명칭은? 정답: API 서버

  8. 마이크로서비스 환경에서 왜 쿠버네티스 같은 자동화 시스템이 필수적인가? 모놀리스와 달리 수백 개의 독립된 프로세스로 나뉘어 배포되므로 수동 관리가 불가능하며 각 서비스의 의존성과 장애 대응을 개별적으로 자동화해야 하기 때문임

  9. 새 애플리케이션 인스턴스를 실행할 노드를 결정하는 과정과 담당 컴포넌트를 설명하시오 스케줄러가 가용 리소스를 고려해 최적의 노드를 결정하고 API 서버를 통해 정보를 업데이트하면 해당 노드의 쿠블릿이 이를 감지해 컨테이너를 실행함

  10. 직접 구축 대신 관리형 서비스(GKE 등) 사용이 조직에 유리한 이유는? 쿠버네티스 자체의 설치와 관리는 극도로 복잡하고 전문 지식이 필요하므로 운영 부담을 전문가에게 맡기고 개발자는 앱 구현에만 집중하기 위함임

2장

  1. 쿠버네티스가 다양한 컨테이너 기술(Docker, CRI-O 등)을 지원할 수 있게 해주는 인터페이스는? a. API Server b. CRI c. etcd d. Kubelet

  2. 다음 중 도커의 경량 대안이며 OCI 표준을 준수하는 런타임은? a. rkt b. runC c. CRI-O d. Kata

  3. 컨테이너가 호스트 머신에서 직접 실행되는 것과 같다고 볼 때, 공유되는 요소는? a. OS 파일시스템 b. 애플리케이션 라이브러리 c. OS 커널 d. 패키지 매니저

  4. 컨테이너화된 애플리케이션의 로그는 주로 어디로 출력해야 하는가? a. /var/log/app.log b. 표준 출력(stdout) c. API 서버 d. etcd

  5. 컨테이너를 가상 머신처럼 격리된 공간으로 보이게 만드는 리눅스 커널 기능을 무엇이라 하는가? 정답: 네임스페이스(Namespace)

  6. 쿠버네티스의 기본 배포 단위이며 하나 이상의 컨테이너 그룹을 의미하는 것은? 정답: 포드(Pod)

  7. 책에서 소개된 실습용 데모 애플리케이션의 이름은? 정답: Kiada

  8. 왜 한 컨테이너 안에 여러 프로세스를 실행하는 것을 권장하지 않는가? 컨테이너 기술 자체가 단일 프로세스 관리에 최적화되어 설계되었으므로 여러 프로세스를 넣으면 관리가 어렵고 컨테이너의 장점인 격리와 자가 치유 기능을 활용하기 힘들기 때문

  9. CRI의 도입이 쿠버네티스 생태계에 주는 이점은 무엇인가? 쿠버네티스 코드를 수정하지 않고도 도커 외에 다양한 컨테이너 런타임(CRI-O, runC 등)을 플러그인 형태로 사용할 수 있게 하여 유연성을 제공함

  10. 가상 머신과 비교했을 때 컨테이너의 리소스 효율성이 높은 이유는? 가상 머신은 각 인스턴스마다 전체 게스트 OS를 실행해야 하지만 컨테이너는 호스트 OS의 커널을 공유하며 프로세스 수준의 격리만 제공하기 때문임

3장

  1. 쿠버네티스에서 컨테이너를 직접 배포하지 않고 사용하는 최소 배포 단위는? a. Container b. Node c. Pod d. Cluster

  2. 클러스터 상태를 조회하거나 명령을 내릴 때 사용하는 CLI 도구의 이름은? a. docker b. gcloud c. kubectl d. kube-admin

  3. Pod가 삭제되고 다시 생성되어도 유지되는 고정된 진입점(IP)을 제공하는 객체는? a. Deployment b. Service c. ReplicaSet d. Node

  4. 로컬 PC에서 단일 노드 클러스터를 실행하기 위해 커뮤니티에서 유지 관리하는 도구는? a. Docker Desktop b. Minikube c. GKE d. EKS

  5. kubectl이 어느 클러스터와 통신할지 결정하는 정보를 담은 설정 파일의 이름은? kubeconfig

  6. Pod를 어느 워커 노드에서 실행할지 결정하는 프로세스를 무엇이라 하는가? 스케줄링(Scheduling)

  7. 복제본 개수를 늘려 시스템의 처리 능력을 향상시키는 과정을 무엇이라 하는가? 수평적 확장(Scaling out)

  8. 왜 사용자는 Pod를 직접 생성하기보다 Deployment를 통해 생성해야 하는가? Deployment는 자가 치유 기능을 제공하여 Pod가 실패할 경우 자동으로 새 인스턴스를 생성하고 원하는 복제본 수를 유지하며 선언적 관리를 가능하게 하기 때문

  9. 서비스 타입 중 LoadBalancer가 하는 역할과 클라우드 인프라와의 관계를 설명하시오 LoadBalancer 타입은 외부 클라이언트가 접근할 수 있는 공인 IP를 제공하며 쿠버네티스가 클라우드 인프라에 외부 로드 밸런서를 프로비저닝하도록 요청하여 연결함

  10. Pod가 일시적(Ephemeral)이라는 특성이 서비스 주소 지정에 어떤 문제를 일으키며 쿠버네티스는 이를 어떻게 해결하는가? Pod는 언제든 종료되거나 교체될 수 있으며 그때마다 IP가 바뀌어 고정 주소로 접근하기 어려움 쿠버네티스는 Service 객체를 통해 Pod들이 바뀌어도 유지되는 정적 IP를 제공하여 이 문제를 해결함

4장

  1. 쿠버네티스 API 오브젝트의 필드 중 ‘원하는 상태’를 기술하는 섹션은? ① Metadata ② Spec ③ Status ④ Type Metadata

  2. API 서버가 오브젝트를 반환할 때 사용하는 기본 데이터 포맷은? ① YAML ② XML ③ JSON ④ TOML

  3. Event 오브젝트가 생성된 후 자동으로 삭제되는 시점은? ① 10분 뒤 ② 1시간 뒤 ③ 24시간 뒤 ④ 삭제되지 않음

  4. Node 오브젝트의 상태 정보 중 디스크 공간 부족을 나타내는 조건은? ① MemoryPressure ② PIDPressure ③ DiskPressure ④ Ready

  5. API 리소스와 오브젝트 유형에 대한 도움말과 필드 설명을 터미널에서 확인하는 명령은? 정답 : kubectl explain

  6. 오브젝트의 실제 상태를 보고하고 결과를 Status에 기록하는 컴포넌트의 명칭은? 정답 : 컨트롤러(Controller)

  7. Node 오브젝트를 API 서버에 등록하고 관리하는 노드 상의 에이전트는? 정답 : 쿠블릿(Kubelet)

  8. 쿠버네티스에서 ‘선언적 모델’이 운영 효율성을 높이는 이유를 설명하시오. 답안 : 사용자가 개별적인 명령을 내리는 대신 최종 목표 상태(Spec)만 정의하면 시스템이 자가 치유와 상태 일치 루프를 통해 자동으로 그 상태를 유지하기 때문임

  9. 오브젝트의 Spec과 Status 섹션이 없는 경우는 어떤 경우이며 그 이유는 무엇인가? 답안 : Event 오브젝트와 같이 정적인 데이터만 포함하는 경우임 별도의 컨트롤러가 상태를 일치시킬 필요가 없으므로 원하는 상태와 실제 상태를 구분하지 않음

  10. 디버깅 시 Event 오브젝트를 확인해야 하는 이유는 무엇인가? 답안 : 컨트롤러가 상태를 일치시키는 과정에서 수행한 작업 내용이나 실패 원인(Warning)이 기록되어 있어 오브젝트가 왜 정상 상태가 아닌지 파악할 수 있기 때문임

5장

  1. 포드에 대한 설명으로 틀린 것은? ① 하나의 포드는 여러 노드에 걸쳐 실행될 수 있다. ② 포드 내의 컨테이너들은 네트워크 네임스페이스를 공유한다. ③ 포드는 쿠버네티스의 최소 배포 단위이다. ④ 전형적인 컨테이너는 하나의 프로세스만 실행한다.

  2. 포드의 상태(Phase) 중 컨테이너 이미지를 내려받거나 예약 중인 상태는? ① Running ② Succeeded ③ Pending ④ Failed

  3. 초기화 컨테이너에 대한 설명으로 옳은 것은? ① 메인 컨테이너와 동시에 시작된다. ② 모든 초기화 컨테이너는 순차적으로 실행되어야 한다. ③ 초기화 컨테이너가 실패해도 메인 컨테이너는 시작된다. ④ 포드당 하나만 정의할 수 있다.

  4. 실행 중인 컨테이너 안에서 명령어를 실행하기 위해 사용하는 도구는? ① kubectl logs ② kubectl exec ③ kubectl cp ④ kubectl attach

  5. 주 컨테이너 기능을 보완하기 위해 포드에 추가되는 보조 컨테이너 패턴의 명칭은? 정답: 사이드카

  6. 포드의 IP 주소와 실행 중인 노드 정보를 포함하여 상세 정보를 보여주는 명령어 옵션은? 정답: -o wide

  7. 로컬 컴퓨터의 파일을 실행 중인 컨테이너로 복사하는 명령어는? 정답: kubectl cp

  8. 왜 프런트엔드와 백엔드 프로세스를 하나의 포드가 아닌 별개의 포드로 분리해야 하는가? 답안: 두 프로세스는 확장 요구사항이 다를 수 있으며, 포드 단위로 수평 확장이 이루어지므로 각기 다른 노드에서 독립적으로 복제하고 관리하기 위함임

  9. 포드 내의 컨테이너들이 localhost를 통해 통신할 수 있는 이유는 무엇인가? 답안: 포드 내의 모든 컨테이너가 동일한 네트워크 네임스페이스와 IP 주소, 포트 공간을 공유하기 때문

  10. 초기화 컨테이너가 메인 컨테이너 실행 전 Precondition을 체크하는 용도로 사용되는 사례를 설명하시오. 답안: 메인 애플리케이션이 의존하는 외부 서비스가 준비될 때까지 시작을 지연시키거나, 보안 저장소에서 인증서를 미리 내려받는 등의 작업에 사용됨

6장

  1. 포드의 수명 주기 중 “노드에 할당되었지만 이미지를 내려받는 중”인 단계는? ① Running ② Pending ③ Succeeded ④ Unknown

  2. 컨테이너 재시작이 반복될 때 삽입되는 최대 지연 시간은? ① 1분 ② 5분 ③ 10분 ④ 지연 시간 없음

  3. 라이브니스 프로브 실패로 컨테이너가 강제 종료될 때, 프로세스가 반환하는 종료 코드(Exit Code)는? ① 0 ② 1 ③ 137 ④ 255

  4. 다음 중 라이브니스 프로브가 지원하지 않는 방식은? ① HTTP GET ② Exec ③ TCP Socket ④ UDP Ping

  5. 컨테이너 재시작 실패가 반복될 때 표시되는 포드 상태 메시지는? 정답: CrashLoopBackOff

  6. 포드 종료 시 안전한 마감을 위해 부여되는 시간 설정의 명칭은? 정답: terminationGracePeriodSeconds / 삭제 유예 기간

  7. 컨테이너 시작 직후 메인 프로세스와 비동기적으로 실행되는 훅은? 정답: Post-start hook

  8. 애플리케이션 초기화 시간이 매우 긴 경우, 왜 라이브니스 프로브만 사용하는 것보다 스타트업 프로브를 병용하는 것이 유리한가? 답안: 라이브니스 프로브만 쓰면 앱이 기동 중인데도 건강하지 않다고 판단해 무한 재시작에 빠질 수 있으나, 스타트업 프로브는 앱이 뜰 때까지 충분한 시간을 벌어주며 라이브니스를 비활성화하기 때문임

  9. 쿠버네티스에서 컨테이너를 종료하는 3단계 시퀀스를 설명하시오. 답안: 1) 설정된 경우 Pre-stop 훅 실행, 2) 메인 프로세스에 TERM 신호 전송, 3) 유예 기간 내 미종료 시 KILL 신호로 강제 종료

  10. 재시작 정책(restartPolicy)이 Never인 포드에서 포스트 시작 훅(Post-start hook)이 실패하면 포드 상태는 어떻게 되는가? 답안: 포드의 상태는 Completed로 표시됨

7장

  1. 포드의 수명 주기와 동일한 생애 주기를 가지며, 처음엔 비어있는 볼륨 타입은? ① hostPath ② nfs ③ emptyDir ④ gcePersistentDisk

  2. emptyDir 볼륨을 디스크 대신 메모리(RAM)에 생성하도록 설정하는 필드는? ① storage: Memory ② medium: Memory ③ fsType: tmpfs ④ type: RAM

  3. 다음 중 hostPath 볼륨의 특징으로 틀린 것은? ① 노드 파일시스템의 특정 경로에 접근할 수 있다. ② 시스템 수준의 포드(로그 수집 등)에서 주로 사용한다. ③ 포드가 다른 노드로 이동해도 데이터를 유지할 수 있다. ④ 보안상 위험하므로 주의해서 사용해야 한다.

  4. 컨테이너 내부에서 볼륨의 특정 파일이나 하위 경로만 마운트하고 싶을 때 사용하는 필드는? ① subPath ② mountOnly ③ filePath ④ partial

  5. 볼륨을 읽기 전용으로 마운트하기 위해 volumeMounts 섹션 아래 설정하는 필드명은? 정답: readOnly

  6. 볼륨을 생성하고 설정하는 필드는 spec.volumes이고, 이를 컨테이너에 연결하는 필드는? 정답: volumeMounts

  7. Google 클라우드 환경에서 영구 저장소를 위해 사용하는 볼륨 타입 명칭은? 정답: gcePersistentDisk

  8. **왜 데이터베이스 데이터를 저장할 때 hostPath보다 네트워크 부착 저장소(GCE PD 등)를 권장하는가? 답안: hostPath는 특정 노드의 로컬 디스크에 데이터를 저장하므로 포드가 다른 노드로 재스케줄링되면 기존 데이터에 접근할 수 없게 되지만, 네트워크 저장소는 노드 이동 시에도 함께 부착될 수 있어 영속성을 보장하기 때문임

  9. 사이드카 패턴에서 공유 볼륨이 수행하는 역할은 무엇인가? 답안: 주 컨테이너와 보조 컨테이너가 동일한 볼륨을 마운트하여 서로의 파일 시스템을 통해 데이터를 주고받거나 보완 작업을 수행할 수 있게 함

  10. init 컨테이너와 emptyDir 볼륨을 조합하여 어떤 작업을 자동화할 수 있는가? 답안: 메인 컨테이너가 시작되기 전, init 컨테이너가 외부 소스(Git 등)에서 데이터를 받아 emptyDir 볼륨을 채워 넣어 메인 앱에 필요한 데이터를 미리 준비할 수 있음

8장

  1. 다음 중 여러 노드에서 동시에 읽기 전용으로 마운트할 수 있는 PersistentVolume의 접근 모드는? (p.378) ① ReadWriteOnce ② ReadOnlyMany ③ ReadWriteMany ④ WriteOnceMany

  2. PVC가 삭제된 후 PV 오브젝트는 남지만 상태가 ‘Released’가 되어 재사용을 방지하는 기본 회수 정책은? (p.400) ① Delete ② Recycle ③ Retain ④ Archive

  3. 동적 프로비저닝을 사용할 때, 특정 볼륨 유형(예: pd-ssd)을 정의하기 위해 사용하는 오브젝트는? (p.450) ① PersistentVolume ② PersistentVolumeClaim ③ StorageClass ④ ConfigMap

  4. 클라우드 환경에서 블록 스토리지를 여러 노드에 동시에 Read/Write 모드로 연결할 수 없는 이유는? (p.350) ① 쿠버네티스 소프트웨어의 버그 ② 블록 스토리지 기술 자체의 물리적 제한 ③ etcd의 저장 용량 부족 ④ API 서버의 응답 지연

  5. PVC 매니페스트에서 동적 프로비저닝을 사용하지 않고 기존 PV에 명시적으로 바인딩하기 위해 빈 문자열("")로 설정해야 하는 필드는? (정답: storageClassName, p.383)

  6. PVC에서 특정 PV를 이름으로 직접 지칭하여 바인딩하고 싶을 때 사용하는 필드는? (정답: volumeName, p.383)

  7. 볼륨 바인딩을 포드가 실제 스케줄링될 때까지 지연시키는 StorageClass의 설정 옵션은? (정답: WaitForFirstConsumer, p.447, p.448)

  8. 왜 개발자가 포드 매니페스트에 직접 NFS 주소나 GCE PD 명칭을 적으면 안 되는지 설명하시오. (답안: 매니페스트가 특정 클러스터 인프라에 종속되어 다른 환경(다른 클라우드나 온프레미스)으로 옮길 때마다 수동으로 수정해야 하므로 이식성이 떨어지기 때문임. p.360, p.361)

  9. 동적 프로비저닝(Dynamic Provisioning)이 관리자의 부담을 줄여주는 이유를 설명하시오. (답안: 관리자가 수많은 PV를 미리 생성해둘 필요 없이, 사용자가 PVC를 생성할 때 시스템이 실시간으로 실제 저장소를 생성하고 PV를 자동으로 등록해주기 때문임. p.428, p.429, p.462)

  10. PV의 회수 정책이 ‘Retain’인 경우, 다른 사용자가 해당 PV를 다시 사용하기 위해 관리자가 거쳐야 하는 과정은? (답안: PV 오브젝트를 수동으로 삭제하고 재생성하거나, PV 매니페스트에서 claimRef 정보를 제거하여 상태를 ‘Available’로 되돌려야 함. p.396, p.397)

9장

  1. 컨테이너 이미지의 ENTRYPOINT를 오버라이드하기 위해 포드 spec에서 사용하는 필드는? ① args ② command ③ env ④ image

  2. 다음 중 Downward API를 통해 주입할 수 있는 정보가 아닌 것은? ① 포드의 IP ② 노드의 이름 ③ 포드의 CPU 제한 ④ 클러스터의 전체 노드 수

  3. ConfigMap 변경 시 볼륨으로 마운트된 파일들이 한꺼번에 업데이트되도록 돕는 기술적 요소는? ① 하드 링크 ② 심볼릭 링크 ③ etcd 스냅샷 ④ 컨테이너 재시작

  4. Secret 볼륨에 마운트된 데이터가 저장되는 물리적 위치는? ① 워커 노드의 SSD ② etcd 저장소 ③ 메모리(tmpfs) ④ 네트워크 스토리지

  5. Secret 매니페스트 작성 시 인코딩되지 않은 문자열을 직접 입력할 수 있는 필드명은? (정답: stringData,)

  6. 설정값이 없을 때도 컨테이너가 정상 기동되도록 설정 참조 시 추가하는 필드는? (정답: optional,)

  7. 여러 개의 ConfigMap과 Secret을 하나의 디렉터리에 마운트할 때 사용하는 볼륨 타입은? (정답: projected,)

  8. 왜 민감한 데이터를 환경 변수(env)보다 볼륨 마운트 방식으로 전달하는 것이 더 안전한가? (답안: 환경 변수는 로그에 노출되거나 kubectl describe 명령으로 쉽게 확인될 위험이 크지만, 볼륨 마운트 방식은 파일 권한을 제어할 수 있고 메모리에만 존재하도록(tmpfs) 설정할 수 있기 때문임)

  9. Downward API가 ‘Kubernetes-agnostic’한 설계인 이유는 무엇인가? (답안: 애플리케이션이 자신의 메타데이터를 얻기 위해 쿠버네티스 API 서버에 직접 요청을 보낼 필요 없이, 익숙한 환경 변수나 파일 시스템을 통해 정보를 얻을 수 있게 해주기 때문임)

  10. Immutable ConfigMap을 사용했을 때 얻을 수 있는 운영상의 이점을 설명하시오. (답안: 실수로 설정이 변경되는 것을 방지하여 안정성을 높이고, Kubelet이 API 서버의 변경 사항을 계속 모니터링할 필요가 없어 대규모 클러스터에서 API 서버의 부하를 줄여줌)

10장

  1. 다음 중 네임스페이스에 속하지 않는(Cluster-scoped) 리소스는? (p.519) ① Pod ② ConfigMap ③ Node ④ Event

  2. 레이블 셀렉터 중 ‘특정 레이블 키의 존재 여부’만으로 객체를 찾는 방식은? (p.567) ① Equality-based ② Field selector ③ Set-based ④ Annotation

  3. 네임스페이스 삭제 시 일어나는 현상으로 옳은 것은? (p.535) ① 네임스페이스 객체만 삭제되고 내부 포드는 유지된다. ② 네임스페이스 내부의 모든 객체가 자동으로 삭제된다. ③ 삭제 명령은 즉시 완료되며 취소할 수 없다. ④ 서비스(Service) 객체는 수동으로 먼저 지워야 한다.

  4. 어노테이션(Annotation)의 특징이 아닌 것은? (p.591-592) ① 레이블보다 큰 용량의 데이터를 담을 수 있다. ② 객체를 필터링하는 셀렉터의 조건으로 사용할 수 있다. ③ 도구들이 객체의 상태 정보를 기록하는 용도로 사용한다. ④ 문자열 값 내에 공백이나 특수문자를 포함할 수 있다.

  5. kubectl 명령 실행 시 매번 네임스페이스를 지정하지 않도록 현재 컨텍스트를 수정하는 명령 옵션은? (정답: —current —namespace, p.530)

  6. 포드 매니페스트 내에서 특정 레이블을 가진 노드에만 포드를 실행하도록 강제하는 필드명은? (정답: nodeSelector, p.582)

  7. 레이블 값의 최대 길이는 몇 자인가? (정답: 63자, p.591)

  8. 왜 개발 환경과 운영 환경을 네임스페이스만으로 분리하는 것을 권장하지 않는가? (답안: 네임스페이스는 논리적 분리와 이름 충돌 방지 기능만 제공할 뿐, 물리적인 노드 자원을 공유하므로 런타임 격리가 완벽하지 않아 운영 환경의 안정성을 해칠 수 있기 때문임. p.534-535)

  9. 레이블 셀렉터의 두 가지 유형(Equality-based, Set-based)의 차이점을 설명하시오. (답안: 등치 기반은 값이 같은지 혹은 다른지만 비교할 수 있으나, 집합 기반은 특정 값 목록에 포함되는지(in) 또는 레이블 키 자체가 존재하는지 등을 따질 수 있어 더 정교한 쿼리가 가능함. p.566-567)

  10. 쿠버네티스 API가 진화하는 과정에서 어노테이션이 수행하는 역할은 무엇인가? (답안: 정식 API 필드를 추가하기 전 신기능을 실험하는 임시 저장소 역할을 하며, 실제 운영에서 효용성이 입증되면 이후 정식 필드로 승격되고 어노테이션은 제거됨. p.593)

11장

  1. 서비스 유형 중 외부 클라우드 인프라에 로드 밸런서 생성을 요청하는 것은? (p.639) ① ClusterIP ② NodePort ③ LoadBalancer ④ ExternalName

  2. 서비스의 ClusterIP에 대해 ping을 보냈을 때 발생하는 현상은? (p.627) ① 포드로 전달된다. ② 즉시 응답이 온다. ③ 응답이 오지 않는다. ④ 에러 메시지가 출력된다.

  3. 준비성 프로브(Readiness Probe)가 실패한 포드에 대해 서비스가 취하는 행동은? (p.677) ① 컨테이너를 재시작한다. ② 포드를 삭제한다. ③ 엔드포인트 목록에서 제외한다. ④ 노드를 교체한다.

  4. 헤드리스 서비스(Headless Service)를 만들기 위해 설정해야 하는 값은? (p.662) ① type: Headless ② clusterIP: None ③ selector: None ④ ports: []

  5. 서비스가 트래픽을 전달할 대상 포드들을 결정하기 위해 사용하는 필드의 명칭은? (정답: 레이블 셀렉터 / selector, p.603)

  6. 클러스터 DNS에서 서비스 이름이 해석되는 기본 도메인 접미사는? (정답: cluster.local, p.620)

  7. 서비스가 참조하는 실제 포드들의 IP 주소와 포트 정보를 담고 있는 보조 객체의 이름은? (정답: Endpoints / EndpointSlice, p.644, p.648)

  8. 왜 클라이언트는 포드 IP에 직접 연결하지 않고 서비스 IP를 통해 연결해야 하는가? (답안: 포드는 언제든 소멸하고 재생성될 수 있어 IP 주소가 계속 바뀌지만, 서비스 IP는 고정되어 있어 클라이언트가 주소 변경에 신경 쓰지 않고 안정적으로 통신할 수 있기 때문임. p.599, p.602)

  9. 준비성 프로브(Readiness Probe)에서 외부 종속성(예: 외부 데이터베이스)을 체크하는 것이 권장되지 않는 이유는? (답안: 일시적인 네트워크 지연 등으로 외부 서비스 연결이 끊겼을 때, 포드 자체는 정상임에도 불구하고 모든 포드가 서비스에서 제외되어 전체 시스템 장애로 이어질 수 있기 때문임. p.696, p.697)

  10. 스테이트풀셋(StatefulSet)에서 일반 서비스와 헤드리스 서비스를 함께 사용하는 이유는 무엇인가? (답안: 일반 서비스는 클라이언트에게 단일 진입점을 제공하기 위함이고, 헤드리스 서비스는 분산 시스템의 멤버(포드)들이 서로의 개별 주소를 DNS를 통해 찾기(Peer Discovery) 위함임. p.880, p.911)

12장

  1. 다음 중 인그레스가 서비스(Service) 오브젝트와 비교했을 때 갖는 가장 큰 장점은? (p.697) ① 포드 간 통신 속도 향상 ② 각 서비스마다 공인 IP를 할당할 필요 없음 ③ 내부 네트워크 격리 강화 ④ 데이터베이스 복제 자동화

  2. 인그레스 객체 생성을 감시하고 리버스 프록시 설정을 갱신하는 컴포넌트는? (p.703) ① Kube-Proxy ② API Server ③ Ingress Controller ④ Scheduler

  3. 인그레스에서 특정 호스트 이름에 대해 TLS 인증서를 적용할 때 참조하는 객체는? (p.727) ① ConfigMap ② Secret ③ PersistentVolume ④ ServiceAccount

  4. 다음 중 인그레스가 지원하는 경로 매칭 타입(pathType)이 아닌 것은? (p.720) ① Exact ② Prefix ③ Regex ④ ImplementationSpecific (교재 12.1 표 기반)

  5. 트래픽 요청이 인그레스에 정의된 어떤 규칙과도 일치하지 않을 때 트래픽을 처리하는 서비스의 명칭은? (정답: 디폴트 백엔드 / Default Backend, p.723)

  6. 클러스터에 여러 인그레스 컨트롤러가 있을 때, 특정 인그레스가 어떤 컨트롤러에 의해 처리될지 명시하는 객체는? (정답: IngressClass, p.736)

  7. 서비스가 인그레스를 통해 노출될 때, 서비스 객체의 type은 일반적으로 무엇으로 설정되는가? (정답: ClusterIP, p.701)

  8. 왜 인그레스를 통한 TLS 종단(Termination) 처리가 개발자에게 편리함을 주는가? (답안: 개별 애플리케이션 포드마다 복잡한 TLS 인증서 관리 및 복호화 로직을 구현할 필요 없이, 인그레스 프록시에서 이를 일괄 처리해주기 때문임. p.728)

  9. 인그레스 컨트롤러와 리버스 프록시의 관계를 설명하시오. (답안: 컨트롤러는 API 서버를 모니터링하여 인그레스 규칙의 변경사항을 감지하는 제어부 역할을 하며, 리버스 프록시는 컨트롤러에 의해 생성된 설정에 따라 실제 트래픽을 배분하는 실행부 역할을 함. p.703)

  10. 쿠키 기반 세션 고정(Session Affinity) 기능을 인그레스에서 설정할 때 왜 어노테이션(Annotation)을 자주 사용하는가? (답안: 쿠버네티스 인그레스 API 표준에는 L7 세부 설정 필드가 부족하므로, Nginx나 GKE 등 각 인그레스 컨트롤러 구현체마다 제공하는 고유 기능을 활성화하기 위해 어노테이션을 활용함. p.729-730)

13장

  1. 레플리카셋의 복제본 수(replicas)를 3에서 5로 변경했을 때 일어나는 일은? (p.758-759) ① 기존 포드 3개가 모두 재시작된다. ② 새로운 포드 2개가 추가로 생성된다. ③ 아무 일도 일어나지 않는다. ④ 기존 포드가 삭제되고 5개가 새로 생성된다.

  2. 레플리카셋이 삭제될 때 종속된 포드들을 함께 삭제하는 쿠버네티스의 메커니즘은? (p.757) ① 오토 스케일링 ② 가비지 컬렉션 ③ 스케줄링 ④ 롤링 업데이트

  3. 레플리카셋 스케일 다운 시 가장 먼저 삭제되는 포드는? (p.761) ① 가장 오래 실행된 포드 ② 준비 상태(Ready)인 포드 ③ 노드에 아직 할당되지 않은 포드 ④ 이름이 가장 빠른 포드

  4. 포드 매니페스트에서 이 포드를 제어하는 레플리카셋 정보를 확인할 수 있는 필드는? (p.755-756) ① metadata.labels ② metadata.ownerReferences ③ spec.template ④ status.phase

  5. 레플리카셋 컨트롤러가 상태를 일치시키기 위해 관찰-비교-조정 과정을 반복하는 루프의 명칭은? (정답: 조정 루프 / Reconciliation Loop, p.771-772)

  6. 레플리카셋 객체는 삭제하되 관리하던 포드들은 클러스터에 남겨두고 싶을 때 사용하는 옵션은? (정답: —cascade=orphan, p.790)

  7. 레플리카셋의 구성 요소 중 생성 후에는 절대 변경할 수 없는 필드는? (정답: 레이블 셀렉터 / selector, p.766)

  8. 레플리카셋의 ‘포드 템플릿’을 수정했을 때, 왜 현재 실행 중인 포드들은 즉시 바뀌지 않는지 설명하시오. (답안: 레플리카셋 컨트롤러는 포드 수를 맞추는 역할만 할 뿐, 실행 중인 포드의 내용을 수정하는 기능은 없기 때문임. 템플릿은 오직 포드 수가 부족하여 ‘새로 만들 때’만 사용되는 쿠키 커터와 같음. p.768, p.792)

  9. 노드 장애 상황에서 레플리카셋이 포드 가용성을 보장하는 과정을 설명하시오. (답안: 노드 장애로 인해 포드가 Terminating 상태가 되거나 응답이 없으면, 레플리카셋 컨트롤러는 실제 포드 수가 원하는 수보다 적음을 감지하고 건강한 다른 노드에 새 포드 인스턴스를 생성함. p.780-781)

  10. 특정 포드를 레플리카셋의 관리 범위에서 벗어나게 하여 디버깅하고 싶을 때 어떤 조치를 취해야 하는가? (답안: 해당 포드의 레이블을 변경하여 레플리카셋의 레이블 셀렉터와 일치하지 않게 만들면 됨. 그러면 레플리카셋은 포드 하나가 부족하다고 판단해 새 포드를 만들고, 기존 포드는 독립적인 객체가 됨. p.784-785)

14장

  1. 디플로이먼트가 포드를 관리하기 위해 내부적으로 자동으로 생성하고 제어하는 객체는? ① Pod ② Service ③ ReplicaSet ④ Namespace

  2. 디플로이먼트의 업데이트 전략 중 서비스 가동 중지 시간이 발생하는 전략은? ① RollingUpdate ② Recreate ③ Canary ④ Blue/Green

  3. 업데이트 중 잘못된 버전임을 감지했을 때, 가장 빠르게 이전 버전으로 되돌리는 명령은? ① kubectl delete ② kubectl apply ③ kubectl rollout undo ④ kubectl edit

  4. 디플로이먼트가 여러 레플리카셋을 구분하기 위해 사용하는 특수 레이블은? ① app ② version ③ pod-template-hash ④ revision

  5. 포드가 생성된 후 실제 트래픽을 받을 수 있는 ‘Available’ 상태가 되기까지 기다려야 하는 최소 시간을 설정하는 필드는? (정답: minReadySeconds,)

  6. 디플로이먼트가 보관하는 이전 실행 이력의 최대 개수를 정의하는 필드는? (정답: revisionHistoryLimit,)

  7. 배포 진행 상태(진행 중, 완료 등)를 확인하기 위해 사용하는 kubectl 명령은? (정답: kubectl rollout status,)

  8. 왜 실무에서는 레플리카셋을 직접 사용하기보다 디플로이먼트를 사용하는 것이 권장되는가? (답안: 레플리카셋은 포드 복제본의 수를 유지하는 기능만 있지만, 디플로이먼트는 포드 템플릿 수정을 통한 선언적 업데이트, 롤백, 배포 전략 설정 등 애플리케이션 수명 주기 관리에 필수적인 기능을 자동화해주기 때문임)

  9. RollingUpdate 전략에서 maxSurge와 maxUnavailable 필드가 수행하는 역할은 무엇인가? (답안: maxSurge는 업데이트 중 의도한 복제본 수보다 얼마나 더 많은 포드를 동시에 띄울 수 있는지 결정하고, maxUnavailable은 업데이트 중 동시에 삭제되어 사용할 수 없는 상태가 되어도 되는 포드의 최대치를 결정하여 배포 속도와 가용성 사이의 균형을 조절함)

  10. 새 버전의 포드가 기동 직후 크래시(Crash)가 발생할 경우, 디플로이먼트의 롤아웃이 중단되는 매커니즘을 설명하시오. (답안: 새 포드가 준비성 프로브를 통과하지 못하면 Ready 상태가 되지 않고, 따라서 minReadySeconds를 충족하지 못해 Available 상태로 전환되지 않음. 디플로이먼트 컨트롤러는 새 포드가 Available해질 때까지 다음 단계의 업데이트를 진행하지 않으므로 전체 롤아웃이 중단됨)

15장

  1. 스테이트풀셋 포드들에게 개별적인 DNS 주소를 부여하기 위해 반드시 함께 생성해야 하는 객체는? (p.850-851) ① LoadBalancer Service ② Headless Service ③ Ingress ④ ConfigMap

  2. 스테이트풀셋의 기본 포드 관리 정책(podManagementPolicy)은? (p.905) ① Parallel ② OrderedReady ③ RollingUpdate ④ OnDelete

  3. 스테이트풀셋을 스케일 다운할 때 가장 먼저 삭제되는 포드는? (p.893) ① 0번 포드 ② 가장 최근에 생성된(가장 높은 번호) 포드 ③ 가장 오래된 포드 ④ 랜덤하게 선택된 포드

  4. 스테이트풀셋의 업데이트 전략 중 특정 인덱스 이상의 포드만 먼저 업데이트하도록 제어하는 필드는? (p.922) ① maxSurge ② maxUnavailable ③ partition ④ revisionHistoryLimit

  5. 스테이트풀셋에서 각 포드마다 독립적인 PVC를 자동으로 생성하기 위해 spec에 정의하는 섹션 이름은? (정답: volumeClaimTemplates, p.856)

  6. 한 번에 최대 하나의 포드만 실행되도록 보장하여 데이터 오염을 방지하는 원칙을 무엇이라 하는가? (정답: at-most-one semantics, p.880)

  7. 스테이트풀셋의 업데이트 이력을 스냅샷 형태로 저장하는 API 객체의 명칭은? (정답: ControllerRevision, p.920)

  8. 왜 스테이트풀셋은 스케일 다운 시 PVC를 자동으로 삭제하지 않는가? (답안: 데이터는 앱의 가장 중요한 자산이므로, 실수로 포드 수를 줄였을 때 데이터까지 영구적으로 소실되는 것을 방지하기 위해 사용자가 직접 PVC를 삭제하도록 설계됨. p.894)

  9. 분산 시스템에서 ‘피어 디스커버리(Peer Discovery)‘를 위해 스테이트풀셋과 헤드리스 서비스를 조합하는 이유를 설명하시오. (답안: 각 노드가 서로의 존재를 알아야 하므로 Cluster IP를 통한 추상화 대신, 헤드리스 서비스가 제공하는 개별 포드의 DNS 고유 주소를 사용하여 서로를 식별하고 통신하기 위함임. p.868, p.870)

  10. 노드 장애로 인해 포드 상태가 ‘Unknown’이 되었을 때, 스테이트풀셋 컨트롤러가 즉시 새 포드를 만들지 않는 이유는 무엇인가? (답안: 네트워크 일시 단절일 경우 기존 포드가 여전히 실행 중일 수 있으며, 새 포드를 즉시 만들면 동일한 정체성과 볼륨을 가진 두 개의 포드가 동시에 실행되어 데이터가 오염될 위험이 있기 때문임. p.884)

16장

  1. 다음 중 데몬셋이 포드를 생성하는 기준은? (p.946, p.949) ① 사용자가 지정한 replicas 수 ② 클러스터 내의 전체 노드 수 ③ 컨트롤 플레인 노드의 수 ④ 가용 가능한 CPU 용량

  2. 데몬셋 포드를 마스터 노드에 배포하기 위해 필요한 설정은? (p.962) ① nodeSelector ② PriorityClass ③ Tolerations ④ hostNetwork

  3. 데몬셋의 업데이트 전략 중 수동으로 포드를 삭제해야 새 버전이 반영되는 방식은? (p.979) ① RollingUpdate ② Recreate ③ OnDelete ④ Parallel

  4. 시스템에 자원이 부족할 때 데몬셋 포드가 퇴출당하지 않도록 설정하는 필드는? (p.992) ① schedulerName ② priorityClassName ③ hostPath ④ runtimeClassName

  5. 데몬셋 포드가 호스트 노드의 네트워크 환경을 그대로 사용하여 노드 IP로 통신하게 만드는 필드는? (정답: hostNetwork, p.999)

  6. 클라이언트 포드가 같은 노드에 있는 데몬 포드와만 통신하도록 서비스에 설정하는 정책은? (정답: internalTrafficPolicy: Local, p.1002)

  7. 특정 노드(예: GPU 노드)에만 데몬셋을 배포하기 위해 사용하는 PodSpec 내의 필드는? (정답: nodeSelector, p.967)

  8. 왜 데몬셋 포드에 system-node-critical****과 같은 높은 우선순위를 부여해야 하는가? (답안: 에이전트 포드는 노드 운영에 필수적인 서비스를 제공하므로, 자원이 부족한 상황에서 일반 워크로드 포드 때문에 퇴출되어 시스템 전체의 가시성이나 네트워크 기능이 마비되는 것을 방지하기 위함임. p.993)

  9. 데몬셋 컨트롤러가 노드 추가를 감지했을 때 수행하는 작업을 설명하시오. (답안: 새 노드가 추가되면 컨트롤러는 해당 노드에 데몬셋의 레이블 셀렉터에 일치하는 포드가 없음을 감지하고, 노드 어피니티가 설정된 새 포드 인스턴스를 해당 노드에 생성함. p.949, p.965)

  10. hostPath 볼륨을 사용하는 데몬셋 포드의 보안상 위험성에 대해 설명하시오. (답안: 호스트 노드의 파일시스템에 직접 접근할 수 있으므로, 해당 컨테이너를 장악한 공격자가 노드의 중요한 설정 파일을 수정하거나 노드 전체의 프로세스를 조작할 위험이 있음. p.988)

17장

  1. Job 리소스의 Pod 템플릿에서 사용할 수 없는 restartPolicy는? (p.1018) ① OnFailure ② Never ③ Always ④ 모두 사용 가능

  2. Job이 5번 성공해야 하고 동시에 2개씩 실행되게 하려면 설정해야 할 값은? (p.1033) ① completions: 2, parallelism: 5 ② completions: 5, parallelism: 2 ③ replicas: 5 ④ replicas: 2

  3. Indexed Job에서 각 Pod에 부여된 인덱스 번호를 확인할 수 있는 환경 변수는? (p.1065) ① POD_INDEX ② JOB_INDEX ③ JOB_COMPLETION_INDEX ④ COMPLETION_ID

  4. CronJob에서 스케줄을 “매분” 실행되도록 설정하는 값은? (p.1095) ① * * * * * ② 0 * * * * ③ @daily ④ 1 * * * *

  5. Job이 무한히 실패하는 것을 방지하기 위해 전체 실행 시간을 제한하는 필드는? (정답: activeDeadlineSeconds, p.1047)

  6. CronJob이 생성한 이전 Job들의 이력을 제한하기 위해 설정하는 필드는? (정답: successfulJobsHistoryLimit, p.1105)

  7. Job 컨트롤러가 Pod를 생성할 때 자동으로 부여하는 레이블 이름은? (정답: job-name, p.1022)

  8. 왜 Job 환경에서 restartPolicy: Always****를 사용할 수 없는지 설명하시오. (답안: Always는 프로세스가 성공적으로 종료되어도 다시 시작시키므로, 작업의 ‘완료’를 목표로 하는 Job의 논리와 충돌하기 때문임. p.1018)

  9. Indexed Job이 대규모 데이터 처리 시 갖는 장점은 무엇인가? (답안: 각 Pod에 고유한 인덱스가 부여되므로, 이를 활용해 전체 데이터셋 중 자신이 처리해야 할 특정 부분(정수 기반 파티션)을 식별하여 중복 없이 분산 처리할 수 있음. p.1051, p.1061)

  10. 노드 장애 발생 시 Job이 생성한 Pod는 어떻게 처리되는가? (답안: Job 컨트롤러는 Pod가 실행 중인 노드가 실패하여 Pod가 사라지면, 성공 횟수를 맞추기 위해 다른 건강한 노드에 새 Pod 인스턴스를 스케줄링하여 작업을 이어나감. p.1011, p.1106)

Graph View