11. How long should a stable API element in Kubernetes be supported (at minimum) after deprecation?
- A. 9 months
- B. 24 months
- C. 12 months
- D. 6 months
[해석]
How long should: 얼마나 오래 해야하나요
a stable API element in Kubernetes: 쿠버네티스에서 안정된 API요소가
be supported (at minimum): 최소한의 지원을 받다
after deprecation?: 사용 중단 공지 이후에
"쿠버네티스에서 안정된 API요소가 사용 중단 공지 이후에 최소한 얼마나 오래 지원받아야 하나요?"
[풀이]
이 문제는 쿠버네티스 사용자가 stable API를 사용하는 과정에서, 특정 API가 deprecated 상태로 전환되었을 때, 얼마나 긴 시간 동안 그 API를 계속 안정적으로 사용할 수 있는지, 즉 API 생명주기 정책에 대한 이해도를 확인하기 위한 문제이다.
쿠버네티스의 API는 기능이 얼마나 안정적이고 신뢰할 수 있는지에 따라 크게 Alpha → Beta → Stable의 3단계로 나누어져있다.
Alpha: 가장 초기 단계로 실험적 기능이 제공되며, 언제든지 기능이 변경되거나 삭제될 수 있다.
(변경빈도: 높음 / 지원 보장 기간: 없음 / 프로덕션 권장: 권장X)
Beta: 기능이 비교적 안정화된 단계로, 일부 프로덕션 환경에서 테스트 목적으로 사용할 수 있다.
(변경빈도: 중간 / 지원 보장 기간: 짧음 / 프로덕션 권장: 제한적)
Stable: 프로덕션 환경에서 안정적으로 사용할 수 있도록 설계된 API 단계이다. 큰 변화가 생길 때에는 Deprecated(지원 중단 예정) 기간을 두고 충분한 사전 공지를 제공한다.
(변경빈도: 낮음 / 지원 보장 기간: 최소 12개월 / 프로덕션 권장: 권장O)
어떤 API 버전을 사용할지는 전적으로 사용자의 선택이다.
=============================================================================
12. What is the name of the lightweight Kubernetes distribution built for IoT and edge computing?
- A. OpenShift
- B. k3s
- C. RKE
- D. k1s
[해석]
What is the name: 이름이 뭔가요
of the lightweight Kubernetes distribution: 경량 쿠버네티스 배포판의
built for IoT and edge computing?: IoT 및 엣지 컴퓨팅을 위해 만들어진
"IoT 및 엣지 컴퓨팅을 위해 만들어진 경량 쿠버네티스 배포판의 이름이 무엇인가요?"
[풀이]
k3s는 Rancher Labs에서 개발한 매우 가볍고 경량화된 쿠버네티스 배포판이다. IoT, 엣지 컴퓨팅 및 리소스가 제한된 환경에서 사용하기 적합하도록 설계되었다. 최소 CPU/메모리로 구동 가능하여 라즈베리파이 등에도 적합하다.
=============================================================================
13. Kubernetes ___ allows you to automatically manage the number of nodes in your cluster to meet demand.
- A. Node Autoscaler
- B. Cluster Autoscaler
- C. Horizontal Pod Autoscaler
- D. Vertical Pod Autoscaler
[해석]
Kubernetes ___ allows you: 쿠버네티스의 ___는 당신이 ~할수있도록 해준다
to automatically manage: 자동으로 관리할수있도록
the number of nodes: 노드들의 개수를
in your cluster: 당신의 클러스터 내에서
to meet demand.: 요청에 따라
"쿠버네티스의 ___는 요청에 따라 당신의 클러스터 내에서 노드들의 개수를 자동으로 관리할수있도록 해준다."
[풀이]
Cluter Autoscaler는 쿠버네티스에서 클러스터의 노드 개수를 트래픽과 리소스 요구사항에 따라 자동으로 조정하는 역할을 한다. 즉, 요청(수요)에 따라 Pod가 추가로 생성되는데 노드 리소스가 부족할 경우, Cluster Autoscaler가 노드를 자동으로 추가해준다. 반대로 리소스가 과다할 경우, 불필요한 노드를 자동으로 제거하여 비용과 리소스를 최적화한다.
Horizontal Pod Autoscaler(HPA)는 Pod 개수를 자동으로 조정하는 기능이다. (수평적 오토스케일)
Vertical Pod Autoscaler(VPA)는 Pod의 리소스 양을 자동으로 조정하는 기능이다. (수직적 오토스케일)
=============================================================================
14. Which of the following statements is correct concerning Open Policy Agent (OPA)?
- A. The policies must be written in Python language.
- B. Kubernetes can use it to validate requests and apply policies.
- C. Policies can only be tested when published.
- D. It cannot be used outside Kubernetes.
[해석]
Which: 어느 것인가요
of the following statements: 다음의 진술들 중에서
is correct: 올바른 것은
concerning Open Policy Agent?: OPA에 관한것
"다음의 설명들 중에서 OPA에 관한 올바른 것은 어느것인가요?"
[풀이]
A. The policies must be written in Python language.
The policies: 정책들
must be written: 작성되어야만 한다
in Python language.: 파이썬 언어로
"정책들은 파이썬 언어로 작성되어야만 한다."
※ OPA 정책은 Rego 언어로 작성되며, Python은 사용되지 않는다.
B. Kubernetes can use it to validate requests and apply policies.
Kubernetes can use it: 쿠버네티스는 OPA를 사용할수있다
to validate requests: 요청들을 검증하는데
and apply poplicies.: 그리고 정책들을 적용하는데
"쿠버네티스는 요청들을 검증하고 정책들을 적용하는데에 OPA를 사용할 수 있다."
※ OPA는 Gatekeeper나 Kubernetes의 입장 제어 웹훅을 통해 Kubernetes 리소스에 대한 정책을 검증하고 적용할 수 있다. 이는 OPA의 주요 사용 사례 중 하나로, 요청이 정의된 정책을 준수하는지 확인한다.
※ Gatekeeper란?: Kubernetes환경에서 OPA를 보다 쉽게 통합하고 활용하기 위해 개발된 오픈소스 프로젝트이다.
※ 입장 제어 웹훅이란?: Kubernetes에서 API서버로 들어오는 요청을 처리하기 전에 추가적인 검증 또는 변환 작업을 수행할 수 있도록 하는 메커니즘이다. Kubernetes의 입장 제어(Admission Control)단계에서 동작하며, 클러스터의 보안, 정책 적용, 리소스 관리 등을 강화하는데 사용 된다.
C. Policies can only be tested when published.
Policies: 정책들
can only be tested: ~만 테스트될 수 있다
when published.: 게시되었을 때
"정책들이 게시되었을때만 테스트될 수 있다."
※ OPA는 OPA CLI나 Rego Playground 같은 도구를 제공하여 정책을 로컬 또는 개발 환경에서 게시하지 않고도 테스트할 수 있다. 샘플 입력으로 정책의 동작을 확인할 수 있다.
D. It cannot be used outside Kubernetes.
It: OPA
cannot be used: 사용될 수 없다
outside Kubernetes: 쿠버네티스 외에서
"OPA는 쿠버네티스 외에서는 사용될 수 없다."
※ OPA는 Kubernetes에 국한되지 않는 범용 정책 엔진이다. 마이크로서비스, CI/CD 파이프라인 등 다양한 환경에서 사용할 수 있다.
=============================================================================
15. In a cloud native world, what does the IaC abbreviation stands for?
- A. Infrastructure and Code
- B. Infrastructure as Code
- C. Infrastructure above Code
- D. Infrastructure across Code
[해석]
In a cloud native world,: 클라우드 네이티브 환경에서,
what does the IaC abbreviation stands for?: IaC 약어는 무엇을 의미하나요?
"클라우드 네이티브 환경에서 IaC 약어는 무엇을 의미하나요?"
[풀이]
IaC(Infrastructure as Code)는 인프라(서버, 네트워크, 스토리지 등)를 코드로 정의하고 관리하는 접근 방식이다. 이를 통해 수동 설정 대신 프로그래밍 방식으로 인프라를 프로비저닝하고 관리할 수 있으며, 대표적인 도구로는 Terraform, Ansible, CloudFormation 등이 있다.
=============================================================================
16. In which framework do the developers no longer have to deal with capacity, deployments, scaling and fault tolerance, and OS?
- A. Docker Swam
- B. Kubernetes
- C. Mesos
- D. Serverless
[해석]
In which framework: 어떤 프레임워크에서
do the developers: 개발자들이
no longer have to: 더이상 할 필요가 없다
deal with capacity, deployments, scaling and fault tolerance, and OS: 용량, 배포, 스케일링, 장애 복구 능력, 운영체제를 처리하다(=관리하다)
?: 의문문
"어떤 프레임워크에서 개발자들이 용량, 배포, 스케일링, 장애 복구 능력, 운영체제를 관리할 필요가 없나요?"
[풀이]
A. Docker Swam
※ 이것은 컨테이너 오케스트레이션 도구이다. 컨테이너를 관리하고 배포를 간소화하지만 여전히 개발자가 클러스터의 용량 계획, 스케일링 설정, 장애 복구 전략, 그리고 기본 OS관리를 신경 써야 한다.
B. Kubernetes
※ 쿠버네티스는 강력한 컨테이너 오케스트레이션 플랫폼이다. 자동 스케일링, 배포, 장애 복구를 지원하지만 여전히 클러스터 설정, 노드 관리, OS 유지보수 등 인프라 관련 작업을 어느 정도 관리해야 한다.
C. Mesos
※ Apache Mesos는 클러스터 리소스 관리와 작업 스케줄링을 위한 플랫폼이다. 쿠버네티스와 마찬가지로 스케일링과 배포를 지원하지만 개발자가 클러스터 리소스와 OS 관리에 관여해야 하므로 완전한 추상화는 제공하지 않는다.
D. Serverless
※ Serverless 아키텍처(ex. AWS Lambda, Google Cloud Functions, Azure Functions)에서는 클라우드 제공업체가 서버 용량, 배포, 스케일링, 장애 복구, 그리고 OS 관리를 모두 처리한다. 개발자는 코드 작성과 비즈니스 로직에만 집중하면 된다.
=============================================================================
17. Which of the following characteristics is associated with container orchestration?
- A. Application message distribution
- B. Dynamic scheduling
- C. Deploying application JAR files
- D. Virtual Machine distribution
[해석]
Which: 어느 것
of the following characteristics: 다음의 특징들 중
is associated: 관련된것은?
with container orchestaration?: 컨테이너 오케스트레이션과
"다음의 특징들 중 컨테이너 오케스트레이션과 관련된것은 어느것인가요?"
[풀이]
A. Application message distribution
※ 애플리케이션 메시지 분배는 주로 메시지 브로커(ex. RabbitMQ, Kafka)나 이벤트 드리븐 아키텍처와 관련된 기능이다. 컨테이너 오케스트레이션은 컨테이너의 배포와 관리에 초점을 맞추며, 메시지 분배는 일반적으로 포함되지 않는다.※ 메시지 브로커란?: 애플리케이션, 서비스, 또는 시스템 간의 메시지(데이터)를 중개하고 전달하는 소프트웨어 컴포넌트이다.※ 이벤트 드리븐 아키텍처(Event-Driven Architecture)란?: 시스템이 이벤트(특정 상태 변화나 액션)를 생성하고 이를 다른 시스템이 감지하여 반응하도록 설계된 소프트웨어 아키텍처 패턴이다. 이벤트는 메시지 형태로 전달되며 메시지 브로커를 통해 처리되는 경우가 많다.
B. Dynamic scheduling
※ 동적 스케줄링은 컨테이너 오케스트레이션의 핵심 기능이다. 예를 들어, 쿠버네티스는 클러스터의 리소스 가용성, 노드 상태, 애플리케이션 요구사항을 기반으로 컨테이너를 적절한 노드에 동적으로 배치한다. 이는 컨테이너 오케스트레이션의 주요 역할 중 하나로 이 선택지가 정답이다.
C. Deploying application JAR files
※ JAR파일 배포는 주로 Java 애플리케이션과 관련된 작업으로, 컨테이너 오케스트레이션은 JAR 파일 자체를 직접 다루지 않는다. 대신, 컨테이너 이미지 내에 JAR 파일을 포함시켜 배포하고 관리한다.
D. Virtual Machine distribution
※ 컨테이너 오케스트레이션은 컨테이너를 관리하는 데 초점을 맞추며, 가상 머신(VM) 분배는 가상화 플랫폼(ex. VMware, Hyper-V) 또는 클라우드 인프라 관리와 관련된다. 컨테이너는 VM보다 가볍도 빠르며, 오케스트레이션은 VM 배포와는 별개이다.
=============================================================================
18. Which of the following workload require a headless service while deploying into the namespace?
- A. StatefulSet
- B. CronJob
- C. Deployment
- D. DaemonSet
[해석]
Which: 어느 것
of the following workload: 다음 워크로드 중
require a headless service: 헤드리스 서비스를 필요로하는
while deploying into the namespace: 네임스페이스에 배포할 때
?: 의문문
"다음 워크로드 중 네임스페이스에 배포할 때 헤드리스 서비스를 필요로 하는것은 어느것인가요?"
[풀이]
A. StatefulSet
※ StatefulSet은 상태를 유지하는 애플리케이션(ex. 데이터베이스, 분산 스토리지 시스템)을 관리하는 데 사용된다. StatefulSet의 각 파드는 고유한 식별자와 순서를 가지며, 파드 간 직접 통신이 필요할 때 헤드리스 서비스를 사용한다. 헤드리스 서비스는 각 파드의 DNS 이름을 제공하여, 파드가 특정 파드에 직접 접근할 수 있게 한다. 따라서 StatefulSet은 헤드리스 서비스와 자주 연계된다.
B. CronJob
※ CronJob은 주기적으로 실행되는 작업을 관리하며, 일반적으로 파드가 독립적으로 실행되고 서비스 디스커버리가 필요하지 않다. CronJob의 파드는 상태를 유지하지 않으며, 헤드리스 서비스가 필요한 경우는 드물다.
※ 서비스 디스커버리(Service Discovery)란?: 분산 시스템, 특히 마이크로서비스 아키텍처나 컨테이너 기반 환경에서 애플리케이션이 다른 서비스를 동적으로 찾아서 통신할 수 있도록 하는 메커니즘이다. 주로 서비스의 위치(ex. IP주소, 포트)와 상태를 자동으로 관리하여 애플리케이션이 이를 쉽게 찾고 연결할 수 있도록 해준다. 특히 컨테이너 환경에서는 컨테이너가 동적으로 생성되고 삭제되며 IP 주소가 자주 변경되기 때문에, 정적인 IP나 호스트명을 사용하는 대신 서비스 디스커버리가 필수적이다.
C. Deployment
※ Deployment는 stateless 애플리케이션을 관리하며, 파드는 서로 독립적이고 동일한 역할을 수행한다. 일반적으로 Deployment는 클러스터 IP를 가진 일반 서비스를 사용하여 트래픽을 로드밸런싱 한다. 헤드리스 서비스는 파드 간 고유 식별자가 필요하지 않은 Deployment의 특성과 맞지 않다.
D. DaemonSet
※ DaemonSet은 모든 노드에 하나의 파드를 배포하며, 주로 모니터링 에이전트나 로그 수집기 같은 노드 단위 작업에 사용된다. DaemonSet의 파드는 일반적으로 독립적으로 동작하며, 헤드리스 서비스를 통해 파드 간 직접 통신이 필요한 경우는 드물다.
=============================================================================
19. What is Helm?
- A. An open source dashboard for Kubernetes.
- B. A package manager for Kubernetes applications.
- C. A custom scheduler for Kubernetes.
- D. An end to end testing project for Kubernetes applications.
[해석]
What is Helm?: "Helm이란 무엇인가?"
[풀이]
Helm은 Kubernetes 애플리케이션을 패키징하고 관리하기 위한 패키지 매니저이다. Helm은 차트(Charts)라는 패키지 형식을 사용하여 Kubernetes 리소스(ex. Deployment, Service, ConfigMap)를 정의하고, 이를 쉽게 설치, 업그레이드, 관리할 수 있게 한다. 예를 들어, Helm 차트를 통해 MySQL, WordPress 같은 복잡한 애플리케이션을 간단하게 배포할 수 있다.
A. An open source dashboard for Kubernetes
An open source dashboard: 한 오픈 소스 대시보드
for Kubernetes: 쿠버네티스를 위한
"쿠버네티스를 위한 오픈소스 대시보드이다."
※ Helm은 대시보드가 아니다. Kubernetes 대시보드는 클러스터의 상태를 시각화하고 관리하는 도구이다.
B. A package manager for Kubernetes applications
A package manager: 패키지 매니저
for Kubernetes applications: 쿠버네티스 애플리케이션을 위한
"쿠버네티스 애플리케이션을 위한 패키지 매니저이다."
※ 정답
C. A custom scheduler for Kubernetes
A custom scheduler: 커스텀 스케줄러
"쿠버네티스를 위한 커스텀 스케줄러이다."
※ Helm은 스케줄러가 아니다. Kubernetes 스케줄러는 파드를 클러스터의 노드에 배치하는 역할을 한다.
D. An end to end testing project for Kubernetes applications
An end to end testing project: 종단간 테스트 프로젝트
"쿠버네티스 애플리케이션을 위한 종단간 테스트 프로젝트이다."
※ Helm은 테스트 도구가 아니다. Kubernetes 애플리케이션 테스트는 다른 도구로 수행된다.
=============================================================================
20. Which is the correct kubectl command to display logs in real time?
- A. kubectl logs -p test-container-1
- B. kubectl logs -c test-container-1
- C. kubectl logs -l test-container-1
- D. kubectl logs -f test-container-1
[해석]
Which is: 어느것이 ~인가?
the correct kubectl command: 올바른 kubectl 명령어
to display logs: 로그를 보여주는
in real time: 실시간으로
?: 의문문
"어느것이 실시간으로 로그를 보여주는 올바른 kubectl 명령어 인가요?"
[풀이]
옵션별 설명
-p: 이전에 종료된(past) 컨테이너의 로그를 출력하는 옵션
-c: 파드 내 여러 컨테이너 중 특정 컨테이너(Container)의 로그를 출력하는 옵션
-l: 라벨(label)을 기준으로 로그를 출력하는 옵션
-f: 로그를 실시간으로(following) 계속 출력하여 보여주는 옵션
