50. What is the goal of load balancing?
- A. Automatically measure request performance across instances of an application.
- B. Automatically distribute requests across different versions of an application.
- C. Automatically distribute instances of an application across the cluster.
- D. Automatically distribute requests across instances of an application.
[해석]
What is: ~는 무엇인가요
the goal: 목적
of load balancing: 로드밸런싱의
"로드밸런싱의 목적은 무엇인가"
[풀이]
A. Automatically measure request performance across instances of an application.
Automatically measure: 자동으로 측정한다
request performance: 요청 성능
across instances: 여러 인스턴스를 걸쳐
of an application: 한 애플리케이션의
"한 애플리케이션의 여러 인스턴스를 걸쳐 요청 성능을 자동으로 측정한다."
※ 의역하자면 애플리케이션이 여러 개 실행될 때, 각 인스턴스의 요청 성능을 자동으로 측정한다는 것이다. 요청의 성능을 자동으로 측정하는 것은 모니터링과 관련된 개념이며 로드밸런싱의 본래 목적이 아니다.
B. Automatically distribute requests across different versions of an application.
Automatically distribute: 자동으로 분배한다(분산한다)
requests: 요청
across different versions: 다른 버전들
of an application: 한 애플리케이션의
"한 애플리케이션의 다른 버전들 간에 요청을 자동으로 분배(분산)한다."
※ 이것은 애플리케이션에 기능 추가 또는 수정이 이루어졌을 때, 기존 버전과 새 버전을 동시에 운영하며 요청을 분산하여 새 버전이 안정적인지 점검하는 카나리 배포(Canary Deployment)를 의미한다. 로드밸런싱의 핵심 목적은 아니다.
C. Automatically distribute instances of an application across the cluster.
Automatically distribute: 자동으로 분배(분산)한다
instances: 인스턴스들
of an application: 한 애플리케이션의
across the cluster: 클러스터 전반에 걸쳐
"클러스터 전반에 걸쳐 한 애플리케이션의 인스턴스들을 자동으로 분배(분산)한다."
※ 애플리케이션의 인스턴스를 클러스터 내 노드에 분산하는 것은 스케줄링(scheduling)을 의미한다. 이것은 Kubernetes의 스케줄러가 담당하는 역할이다.
D. Automatically distribute requests across instances of an application.
Automatically distribute requests: 자동으로 요청을 분산한다
across instances: 여러 인스턴스들 간에
of an application: 한 애플리케이션의
"한 애플리케이션의 여러 인스턴스들 간에 요청을 자동으로 분산한다."
※ 로드 밸런싱은 하나의 애플리케이션이 여러 개의 인스턴스를 가지고 있을 때, 요청을 그 인스턴스들 사이에서 균등하게 분산하여 시스템 성능과 가용성을 높이는 기술이다.
====================================================================
51. How are ReplicaSets and Deployments related?
- A. Deployments manage ReplicaSets and provide declarative updates to Pods.
- B. ReplicaSets manage stateful applications, Deployments manage stateless applications.
- C. Deployments are runtime instances of ReplicaSets.
- D. ReplicaSets are subsets of Jobs and CronJobs which use imperative Deployments.
[해석]
How: 어떤, 어떻게(의문사)
are ~ related: 관련된(동사+보어)
ReplicaSets and Deployments: ReplicaSets와 Deployments가
"ReplicaSet와 Deployment는 어떤 관계인가"
[풀이]
※ Deployment란?: 쿠버네티스에서 애플리케이션의 배포, 업데이트 및 관리를 선언적으로 처리하는 객체이다. 사용자가 원하는 상태(desired state)를 정의하면, Deployment는 그 상태를 항상 유지하도록 관리한다. Pod를 생성하거나 삭제하여 애플리케이션을 확장/축소하고, 롤링 업데이트를 통해 버전 업데이트를 수행한다.
※ ReplicaSet이란?: 쿠버네티스에서 Pod의 개수를 항상 일정하게 유지하도록 관리하는 객체이다. Pod가 종료되거나 삭제되면 자동으로 다시 생성하여 개수를 맞춘다.
※ 즉, ReplicaSet은 Deployment의 역할 중 일부이며, Deployment에 의해 관리되는 하위 리소스이다.
A. Deployments manage ReplicaSets and provide declarative updates to Pods.
Deployments manage ReplicaSets: Deployment는 ReplicaSet을 관리한다
and: 그리고
provide declarative updates: 선언적 업데이트를 제공한다
to Pods: Pod에
"Deployment는 ReplicaSet을 관리하고 Pod에 선언적 업데이트를 제공한다"
※ 옳은 설명
B. ReplicaSets manage stateful applications, Deployments manage stateless applications.
ReplicaSets manage stateful applications: ReplicaSet은 stateful 애플리케이션을 관리하고
Deployments manage stateless applications: Deployment는 stateless 애플리케이션을 관리한다.
※ ReplicaSet과 Deployment 모두 주로 stateless 애플리케이션에 사용된다. stateful 애플리케이션은 StatefulSet을 사용한다.
※ stateful 애플리케이션: 상태(세션 정보, 데이터베이스 데이터, 사용자 환경 설정 등)가 지속적으로 저장되거나 유지되어야 하는 애플리케이션을 말한다. 대표적으로 MySQL, PostgreSQL과 같은 데이터베이스 시스템이 있다.
※ stateless 애플리케이션: 상태를 보관하거나 유지하지 않는 애플리케이션을 말한다. 들어오는 각 요청을 처리할 때, 이전 요청의 상태나 데이터에 의존하지 않고 독립적으로 처리한다. 각 인스턴스는 완전히 동일한 작업을 수행하며 서로 대체 가능하다. 대표적으로 웹서버가 있다.
C. Deployments are runtime instances of ReplicaSets.
"Deployment는 ReplicaSet의 런타임 인스턴스이다."
※ 그 반대임. ReplicaSet이 Deployment의 일부(런타임 인스턴스)임
D. ReplicaSets are subsets of Jobs and CronJobs which use imperative Deployments.
ReplicaSets are subsets of Jobs and CronJobs: ReplicaSet은 Job과 CronJob의 하위집합이다.
which: 관계대명사로 쓰임(=that). 여러 개의 명사를 동시에 수식할경우에는 which가 조금 더 자연스러운 표현이라고함
use imperative Deployments: imperative(명령형) Deployment를 사용하는
"ReplicaSet은 imperative Deployment를 사용하는 Job과 CronJob의 하위 집합이다."
※ imperative Deployment라는 용어 자체가 적합하지 않은 용어이고, ReplicaSet은 Job이나 CronJob과 직접적인 관계가 없음.
====================================================================
52. What factors influence the Kubernetes scheduler when it places Pods on nodes?
- A. Pod memory requests, node taints, and Pod affinity.
- B. Pod labels, node labels, and request labels.
- C. Node taints, node level, and Pod priority.
- D. Pod priority, container command, and node labels.
[해석]
What factors: 무슨 요소들이
influence: 영향을 미치나요
the Kubernetes scheduler: 쿠버네티스 스케줄러가
when it places Pods on nodes: 노드에 Pod를 배치할 때
"쿠버네티스 스케줄러가 노드에 Pod를 배치할 때 영향을 미치는 요소들은 무엇인가요?"
[풀이]
※ Pod Memory Requests: Pod가 실행될 때 요구하는 최소 메모리 자원량을 나타내는 값이다. 스케줄러는 노드의 메모리 용량과 이 요청을 비교하여 배치할 노드를 결정한다.
※ Node Taints: 특정 노드에 설정하여 일부 Pod가 해당 노드에 배치되지 못하도록 제한하는 설정이다. Toleration(용인)을 설정한 Pod만 해당 노드에 배치될 수 있다.
※ Pod Affinity: 특정 Pod가 다른 특정 Pod와 가깝게(동일 노드에) 배치되도록 설정하는 기능이다. 특정 조건을 가진 Pod들과 함께 배치되어 성능 향상 및 네트워크 지연 최소화를 목적으로 한다.
이 세 가지 요소가 Kubernetes 스케줄러가 노드를 선택하는 데 핵심적으로 영향을 미친다.
※ Pod labels: Pod에 붙이는 키-값 형태의 메타데이터. 서비스, ReplicaSet, Deployment 등에서 특정 Pod를 선택할 때 주로 사용한다.
※ Node labels: 노드에 붙이는 키-값 형태의 메타데이터. 특정 노드를 선택적으로 스케줄링할 때 사용한다.
※ Request labels: 존재하지 않는 용어
label은 단순 식별자로 사용된다. 이것만으로 스케줄러가 배치를 결정하지는 않는다.
※ Pod priority: Pod의 중요도를 나타내는 수치로, 스케줄링과 퇴거(eviction) 시 우선순위를 결정한다.
Pod priority는 스케줄링 우선순위에 영향을 주지만, 선택지에 있는 Node Level이라는것은 없는 개념이기 때문에 정답이 아니다.
※ Container command: 컨테이너 실행 시 최초로 실행할 명령어를 말한다. 컨테이너의 동작을 결정하지만 스케줄러가 Pod를 배치하는데 영향을 주지는 않는다.
====================================================================
53. What is the core metric type in Prometheus used to represent a single numerical value that can go up and down?
- A. Summary
- B. Counter
- C. Histogram
- D. Gauge
[해석]
What is the core metric type: 핵심 메트릭 유형은 무엇인가요
in Prometheus: 프로메테우스에서
used to represent: 나타내는데 사용되는
a single numerical value: 하나의 숫자 값(단일 수치)을
that: 관계대명사(숫자 값을 수식)
can go up and down: 증가하거나 감소할 수 있는
"프로메테우스에서 증가하거나 감소할 수 있는 하나의 숫자 값을 나타내는데 사용되는 핵심 메트릭 유형은 무엇인가"
[풀이]
A. Summary
※ 일정 기간 동안의 관측값을 요약하여 분포와 분위수를 나타내는 메트릭이다. 주로 시간에 따른 요청 지속시간을 분석할 때 사용된다.
B. Counter
※ 값이 오직 증가만 하는 메트릭이다.
C. Histogram
※ 값의 분포를 표현하는 메트릭으로, 값을 범위로 나누어 표현한다. 요청 시간 분포 등을 측정할 때 사용된다. 값이 하나가 아니라 여러 bucket(범위)로 나뉘므로 단일 값을 나타내기 어렵다.
D. Gauge
※ 프로메테우스에서 하나의 숫자 값(단일 값)을 표현하는 메트릭이다. 값이 증가하거나 감소할 수 있다. 대표적으로 현재 온도, CPU 사용량, 메모리 사용량 등을 표현한다.
====================================================================
54. What is the primary mechanism to identify grouped objects in a Kubernetes cluster?
- A. Custom Resources
- B. Labels
- C. Label Selector
- D. Pod
[해석]
What is the primary mechanism: 무엇이 주된 메커니즘(방법)인가요
to identify grouped objects: 그룹화된 객체들을 식별하기 위한
in a Kubernetes cluster: 쿠버네티스 클러스터 내에서
"쿠버네티스 클러스터 내에서 그룹화된 객체들을 식별하기 위한 주된 방법은 무엇인가요?"
[풀이]
A. Custom Resources
※ 사용자 정의 리소스는 쿠버네티스에서 기본 제공되지 않는 새로운 객체 유형을 사용자가 정의할 때 사용된다.
B. Labels
※ 라벨은 쿠버네티스 객체에 키-값 형태로 붙이는 메타데이터이다. 객체를 그룹화하거나 특정 목적의 객체를 선택하고 식별하는 주된 메커니즘으로 널리 사용된다.
C. Label Selector
※ 라벨 셀렉터는 이미 존재하는 라벨을 기반으로 특정 객체를 선택할 때 사용된다.
D. Pod
※ 파드는 쿠버네티스에서 애플리케이션 컨테이너의 기본 실행 단위이다. 객체를 그룹화하거나 식별하기 위한 메커니즘이 아니라, 컨테이너를 실행하는 객체 그 자체이다.
====================================================================
55. What is the name of the Kubernetes resource used to expose an application?
- A. Port
- B. Service
- C. DNS
- D. Deployment
[해석]
What is the name: 이름이 무엇인가요
of the Kubernetes resource: 쿠버네티스 리소스의
used to expose an application: 한 애플리케이션을 노출(공개)하는데 사용되는
"애플리케이션을 외부에 노출하는 데 사용되는 쿠버네티스 리소스의 이름이 무엇인가요"
[풀이]
A. Port
※ 포트는 통신시 사용되는 번호이다. 리소스의 종류가 아니다.
B. Service
※ 쿠버네티스에서 애플리케이션을 내부 또는 외부에 노출(공개)할 때 사용하는 공식적인 리소스이다. ClusterIP, NodePort, LoadBalancer와 같은 다양한 유형으로 애플리케이션을 외부에 노출시킨다.
C. DNS
※ 도메인 이름을 IP주소로 변환하는 시스템이다. 쿠버네티스 리소스가 아니다.
D. Deployment
※ 쿠버네티스에서 애플리케이션의 Pod를 관리하고 업데이트하는 리소스이다. Deployment는 애플리케이션을 배치하고 관리하지만, 직접 외부에 노출시키지는 않는다.
====================================================================
56. What is a DaemonSet?
- A. It's a type of workload that ensures a specific set of nodes run a copy of a Pod.
- B. It's a type of workload responsible for maintaining a stable set of replica Pods running in any node.
- C. It's a type of workload that needs to be run periodically on a given schedule.
- D. It's a type of workload that provides guarantees about ordering, uniqueness, and identity of a set of Pods.
[해석]
What is a DaemonSet?
"DaemonSet은 무엇인가요?"
[풀이]
A. It's a type of workload that ensures a specific set of nodes run a copy of a Pod.
It's a type of workload: 그것은 워크로드 유형입니다.
that: 관계대명사(어떤 워크로드인지 수식)
ensures: 보장한다
a specific set of nodes: 특정한 노드 집합들이
run a copy of a Pod: 하나의 파드 복제본을 실행하는
"특정한 노드 집합들이 하나의 파드 복제본을 실행하도록 보장하는 워크로드 유형입니다."
※ DaemonSet은 Kubernetes의 특정 워크로드 유형으로, 지정된 노드 집합에 각 노드마다 Pod가 하나씩 반드시 실행되도록 보장하는 역할을 수행한다. 주로 클러스터의 모든 노드에서 실행되어야 하는 시스템 로깅, 모니터링, 네트워크 설정과 같은 작업에 사용된다.
B. It's a type of workload responsible for maintaining a stable set of replica Pods running in any node.
It's a type of workload: 그것은 워크로드 유형입니다.
responsible: 책임지는, 담당하는
for maintaining a stable set of replica Pods: 안정적인 복제 Pod들의 집합을 유지관리하는 것을
running in any node: 어느 노드에서든 실행 중인
"어느 노드에서든 실행중인 안정적인 복제 Pod들의 집합을 유지관리하는 것을 책임지는 워크로드 유형입니다."
※ 이것은 ReplicaSet에 대한 설명이다. ReplicaSet은 특정 개수의 Pod를 항상 유지하는 역할을 하는 워크로드이다. Pod가 종료되면 새 Pod를 자동 생성하여 안정적인 개수(stable set)을 유지한다.
C. It's a type of workload that needs to be run periodically on a given schedule.
It's a type of workload: 그것은 워크로드 유형입니다.
that: 관계대명사(어떤 워크로드인지 수식)
needs to be run periodically: 주기적으로 실행되어야 하는(need to는 "~해야 한다"라는 뜻으로 널리 쓰이는 표현)
on a given schedule: 주어진 일정에 따라(시간적 개념을 나타내기 때문에 on이 "위에"가 아닌, "따라, 맞추어"로 해석된다)
"주어진 일정에 따라 주기적으로 실행되어야 하는 워크로드 유형입니다."
※ 이것은 CronJob에 대한 설명이다.
D. It's a type of workload that provides guarantees about ordering, uniqueness, and identity of a set of Pods.
It's a type of workload: 그것은 워크로드 유형입니다.
that: 관계대명사(어떤 워크로드인지 수식)
provides guarantees: 보증을 제공하는(=보장하는)
about: ~에 대한, ~에 대해서ordering, uniqueness, and identity: 순서, 고유성, 그리고 식별성of a set of Pods: Pod 집합의
"Pod 집합의 순서와 고유성, 그리고 식별성에 대해 보장하는 워크로드 유형입니다."
※ 이것은 StatefulSet에 대한 설명이다. Pod가 항상 순서대로 생성 및 종료되도록 하고, 각 Pod가 고유한 이름과 DNS 식별자를 갖도록 하고, 각 Pod가 고정된 네트워크 ID를 갖고 지속적인 데이터 저장소를 갖도록 하는것이다. 이러한 특징들은 데이터베이스, 캐싱 서비스 등의 Stateful 애플리케이션이 필요로 하는 것이다. ====================================================================
57. What is the telemetry component that represents a series of related distributed events that encode the end-to-end request flow through a distributed system?
- A. Metrics
- B. Logs
- C. Spans
- D. Traces
[해석]
What is the telemetry component: 텔레메트리 구성요소는 무엇인가요?
that: 관계대명사(어떤 텔레메트리 구성요소를 말하는건지 수식함)
represents: 나타내는
a series of related distributed events: 일련의 관련된 분산 이벤트들을
that: 관계대명사(어떤 일련의 관련된 분산 이벤트들을 말하는건지 수식함)
encode the end-to-end request flow: 종단간 요청 흐름을 인코딩하는(표현하는, 나타내는)
through a distributed system: 분산 시스템을 통해
"분산 시스템을 통하는 종단간 요청 흐름을 표현하고, 서로 관련된 일련의 분산 이벤트들을 나타내는 텔레메트리 구성요소는 무엇인가"
[풀이]
지문을 한글로 해석하려다보니 다소 난해한데, 풀이해보면 다음과 같다.
분산 시스템(Distributed system)은 하나의 요청을 처리할 때 여러 개의 서비스나 구성 요소가 서로 연결되어 작동하는 시스템이다.
이러한 시스템에서는 하나의 요청이 처음부터 끝까지(end-to-end) 여러 서비스를 거쳐서 처리된다.
이 "하나의 요청이 처음부터 끝까지 처리되는 전체 과정"을 기록한 정보(텔레메트리 구성요소)가 무엇인지 묻는 문제이다.
A. Metrics
※ 메트릭은 주로 숫자 값을 나타내는 데이터로서 성능, 리소스 사용량 등을 측정하는 데 사용된다.
B. Logs
※ 로그는 시스템이나 애플리케이션이 실행되는 중에 발생하는 개별적인 이벤트를 기록한 텍스트 데이터다.
C. Spans
※ 스팬은 Trace 내의 개별 작업 단위를 나타내며, 하나의 Span은 작업의 시작과 끝을 나타낸다. 즉, Span은 Trace의 구성요소이다.
D. Traces
※ 트레이스는 분산 시스템에서 요청의 시작부터 끝까지를 나타내는 계층적이고 연관된 Span의 집합이다. 트레이스는 전체 요청 흐름을 시각적으로 보여준다. 대표적으로 특정 웹 요청이 API 서버, 데이터베이스, 캐시를 거쳐 클라이언트에 응답될 때 그 전체 흐름을 표현한다.
※ Span은 개별 작업, Trace는 Span의 집합체이며 전체 요청 흐름을 표현.
====================================================================
58. In the Kubernetes platform, which component is responsible for running containers?
- A. etcd
- B. CRI-O
- C. cloud-controller-manager
- D. kube-controller-manager
[해석]
In the Kubernetes platform: 쿠버네티스 플랫폼에서
which component: 어떤 컴포넌트(구성요소)인가요
is responsible: 책임이 있는(=담당하는)
for running containers: 컨테이너를 실행하기 위한
"쿠버네티스 플랫폼에서 컨테이너 실행을 담당하는 것은 어떤 컴포넌트(구성요소)인가요"
[풀이]
A. etcd
※ etcd는 클러스터의 상태 정보를 저장하는 분산 키-값 저장소로 사용된다. 컨트롤 플레인(Control Plane)의 핵심 구성 요소로서, API 서버가 상태를 관리할 때 etcd를 통해 데이터를 읽고 쓴다. 컨테이너를 직접 실행하지는 않는다.
B. CRI-O
※ CRI-O(Container Runtime Interface + Open Container Initiative)는 쿠버네티스가 표준화된 CRI를 통해 컨테이너를 실행할 때 사용되는 구현체이다. 쿠버네티스에 최적화된 경량의 전용 컨테이너 런타임이다. Docker와 같은 추가적인 중간 계층 없이 컨테이너를 직접 실행할 수 있게 해준다.
※ CRI란?: 쿠버네티스가 다양한 '컨테이너 런타임'과 상호작용하기 위한 '표준 인터페이스'이다. 쿠버네티스에서 컨테이너를 생성하고 관리하는 역할을 담당하는 구성요소는 'Kubelet'이다. Kubelet이 컨테이너를 실행할 때, 컨테이너 런타임(Docker, CRI-O, containerd 등)과 소통하기 위한 일종의 표준 API이다.
※ OCI란?: 컨테이너 생태계의 표준화를 위해 만들어진 비영리 단체이며, 컨테이너 런타임과 이미지의 규격을 표준화하는 것을 목표로 한다. 특히, Docker, containerd, CRI-O 등 다양한 컨테이너 런타임과 이미지가 호환성을 유지할 수 있도록 표준화 한다.
C. cloud-controller-manager
※ 클라우드 공급자와 관련된 컴포넌트로 클라우드 인프라 리소스(로드밸런서, 스토리지 등)를 관리한다. 컨테이너 실행과는 관련이 없다.
D. kube-controller-manager
※ 쿠버네티스 클러스터 내부에서 ReplicaSet, Deployment 등 리소스를 관리하는 컴포넌트이다. 실제 컨테이너 실행과는 관련이 없다.
====================================================================
59. Services and Pods in Kubernetes are ______ objects.
- A. JSON
- B. YAML
- C. Java
- D. REST
[해석]
Services and Pods: 서비스와 파드는
in Kubernetes: 쿠버네티스에서
are _____ objects: ~객체이다.
"Serivce와 Pod는 쿠버네티스에서 ?? 객체이다."
[풀이]
Kubernetes의 모든 객체(Service, Pod 등)는 REST 객체이며, 쿠버네티스 API 서버를 통해 RESTful API로 관리된다.
※ REST(Representational State Transfer)란?: 네트워크상의 리소스를 다루기 위한 아키텍처 스타일이다.
주로 웹 기반 애플리케이션과 서비스 간 통신을 위해 사용된다. 쉽게 말하면, 웹 서비스가 서로 통신할 때 지켜야 하는 설계 원칙이다. REST의 핵심은 다음과 같은 원칙을 따르는 것이다.
1. 모든 자원은 고유한 URI를 가진다.
2. 클라이언트-서버 간의 통신은 HTTP 프로토콜을 기반으로 한다.
3. 상태 정보는 서버에 저장하지 않고, 클라이언트가 관리한다.(Stateless)
4. 데이터 표현 방식으로 주로 JSON 또는 XML을 사용한다.
