Kubernetes CKA 자격증 실전 연습 문제 (55문제 + 실기 시뮬레이션 10개)

A) 10.0.0.0/8 B) 192.168.0.0/16 C) 별도 지정 필요 (기본값 없음) D) 172.16.0.0/12

정답: C

설명: kubeadm init은 기본 pod network CIDR을 자동으로 설정하지 않습니다. --pod-network-cidr 플래그로 직접 지정해야 합니다. CNI 플러그인에 따라 다르며, Calico는 보통 192.168.0.0/16, Flannel은 10.244.0.0/16을 사용합니다.

A) etcdctl snapshot load B) etcdctl snapshot restore C) etcdctl backup restore D) etcdctl cluster restore

정답: B

설명: ETCDCTL_API=3 etcdctl snapshot restore 명령어를 사용하여 etcd 스냅샷을 복구합니다. --data-dir 옵션으로 복구 위치를 지정하고, etcd 서비스를 재시작해야 합니다.

A) ClusterRole은 하나의 네임스페이스에만 적용된다 B) Role은 클러스터 전체 리소스에 접근할 수 있다 C) ClusterRole은 클러스터 범위 리소스 및 모든 네임스페이스에 적용 가능하다 D) ClusterRole과 Role은 기능적으로 동일하다

정답: C

설명: ClusterRole은 클러스터 범위 리소스(nodes, persistentvolumes 등)와 모든 네임스페이스의 네임스페이스 범위 리소스에 접근 권한을 부여할 수 있습니다. Role은 특정 네임스페이스 내에서만 유효합니다.

A) RoleBinding은 ClusterRole을 참조할 수 없다 B) ClusterRoleBinding은 특정 네임스페이스에만 적용된다 C) RoleBinding은 특정 네임스페이스 내에서 권한을 부여하고, ClusterRoleBinding은 클러스터 전체에 권한을 부여한다 D) 둘 다 동일한 범위에 적용된다

정답: C

설명: RoleBinding은 특정 네임스페이스 내의 리소스에 대한 권한을 부여합니다. ClusterRoleBinding은 클러스터 전체 범위에 권한을 부여합니다. RoleBinding이 ClusterRole을 참조하면, 해당 ClusterRole의 권한이 특정 네임스페이스에만 적용됩니다.

A) Control plane → Worker nodes → etcd B) etcd → Control plane → Worker nodes C) Worker nodes → Control plane → etcd D) kubeadm upgrade plan → kubeadm upgrade apply → kubelet/kubectl 업그레이드

정답: D

설명: 올바른 순서는 다음과 같습니다: 1) kubeadm upgrade plan으로 업그레이드 가능 버전 확인, 2) kubeadm upgrade apply vX.Y.Z로 control plane 업그레이드, 3) kubelet과 kubectl 업그레이드, 4) 각 worker node에서 kubeadm upgrade node 실행, 5) worker node의 kubelet 업그레이드.

A) /etc/ssl/kubernetes/ B) /var/lib/kubernetes/ C) /etc/kubernetes/pki/ D) /home/kubernetes/certs/

정답: C

설명: kubeadm으로 생성된 클러스터에서 인증서는 기본적으로 /etc/kubernetes/pki/ 디렉토리에 위치합니다. apiserver.crt, apiserver.key, ca.crt, ca.key 등이 이 디렉토리에 있습니다.

A) 새로운 kubeconfig 파일을 생성한다 B) 현재 활성 컨텍스트를 변경한다 C) 클러스터에 새 사용자를 추가한다 D) 네임스페이스를 변경한다

정답: B

설명: kubectl config use-context CONTEXT_NAME 명령어는 kubeconfig 파일에서 현재 활성 컨텍스트를 변경합니다. CKA 시험에서 각 문제마다 다른 컨텍스트로 전환해야 하므로 매우 중요한 명령어입니다.

A) kubectl label node NODE_NAME key=value:NoSchedule B) kubectl taint node NODE_NAME key=value:NoSchedule C) kubectl annotate node NODE_NAME key=value:NoSchedule D) kubectl mark node NODE_NAME key=value:NoSchedule

정답: B

설명: kubectl taint nodes NODE_NAME key=value:effect 명령어로 taint를 추가합니다. effect는 NoSchedule, PreferNoSchedule, NoExecute 중 하나입니다. 제거 시에는 마지막에 -를 붙입니다: kubectl taint nodes NODE_NAME key=value:NoSchedule-

A) kubectl create pod 명령어 사용 B) kubelet이 감시하는 디렉토리(기본: /etc/kubernetes/manifests/)에 YAML 파일 배치 C) kube-apiserver에 직접 API 호출 D) etcd에 직접 데이터 저장

정답: B

설명: Static Pod는 kubelet이 감시하는 디렉토리(기본값: /etc/kubernetes/manifests/)에 Pod 매니페스트 파일을 배치하면 자동으로 생성됩니다. kubelet이 파일을 감지하고 Pod를 실행합니다. kube-apiserver, etcd, controller-manager, scheduler 등 control plane 컴포넌트가 이 방식으로 실행됩니다.

A) 클러스터 인증서를 생성한다 B) Worker node가 Control plane에 안전하게 참여하기 위한 인증 정보이다 C) 네트워크 CNI를 설정한다 D) etcd 클러스터에 참여한다

정답: B

설명: --token은 Bootstrap Token으로 worker node가 control plane과 통신하기 위한 임시 인증 토큰입니다. --discovery-token-ca-cert-hash는 CA 인증서의 해시값으로, man-in-the-middle 공격을 방지합니다. kubeadm token create --print-join-command로 재생성할 수 있습니다.

A) maxSurge B) maxUnavailable C) minReadySeconds D) revisionHistoryLimit

정답: B

설명: spec.strategy.rollingUpdate.maxUnavailable은 롤링 업데이트 중 동시에 사용 불가능한 Pod의 최대 수(또는 비율)를 지정합니다. maxSurge는 동시에 추가로 생성될 수 있는 Pod의 최대 수를 지정합니다. 기본값은 둘 다 25%입니다.

A) BestEffort B) Burstable C) Guaranteed D) Reserved

정답: C

설명: Guaranteed QoS 클래스는 Pod의 모든 컨테이너에 CPU와 메모리의 requests와 limits가 설정되고 동일한 경우입니다. Burstable은 requests와 limits가 다르게 설정된 경우, BestEffort는 requests/limits가 전혀 설정되지 않은 경우입니다.

A) nodeSelector는 더 복잡한 규칙을 지원한다 B) nodeAffinity는 required/preferred 규칙, 다양한 연산자(In, NotIn, Exists 등)를 지원한다 C) nodeSelector는 label이 아닌 annotation을 사용한다 D) nodeAffinity는 deprecated되었다

정답: B

설명: nodeAffinity는 nodeSelector보다 더 표현력이 있습니다. requiredDuringSchedulingIgnoredDuringExecution(하드 요구사항)과 preferredDuringSchedulingIgnoredDuringExecution(소프트 요구사항)을 지원하며, In, NotIn, Exists, DoesNotExist, Gt, Lt 연산자를 사용할 수 있습니다.

A) 특정 수의 Pod 복제본을 항상 유지할 때 B) 모든 (또는 일부) 노드에 Pod를 하나씩 실행할 때 C) 순서가 있는 상태 저장 애플리케이션을 실행할 때 D) 배치 작업을 실행할 때

정답: B

설명: DaemonSet은 클러스터의 모든 노드(또는 nodeSelector로 선택된 노드)에 Pod를 하나씩 실행합니다. 노드 모니터링 에이전트, 로그 수집기, 네트워크 플러그인 등에 사용됩니다. 새로운 노드가 추가되면 자동으로 해당 노드에 Pod가 생성됩니다.

A) pod-random-suffix B) statefulset-name-0, statefulset-name-1, ... C) statefulset-name-random D) pod-0, pod-1, ...

정답: B

설명: StatefulSet의 Pod는 예측 가능한 이름을 가집니다: statefulset-이름-0, statefulset-이름-1, ... 와 같은 형식입니다. 이 안정적인 이름은 StatefulSet이 제공하는 핵심 기능 중 하나입니다.

A) completions: 동시 실행 Pod 수, parallelism: 완료해야 할 총 작업 수 B) completions: 완료해야 할 총 작업 수, parallelism: 동시에 실행되는 Pod 수 C) completions: 재시도 횟수, parallelism: 타임아웃 시간 D) 두 필드 모두 재시도와 관련된 설정이다

정답: B

설명: completions는 Job이 성공적으로 완료되어야 하는 총 Pod 수를 지정합니다. parallelism은 동시에 실행할 수 있는 Pod 수를 지정합니다. 예를 들어 completions=10, parallelism=3이면, 10개의 작업을 3개씩 병렬로 처리합니다.

A) spec.schedule 필드에 시간대 정보 포함 B) spec.timeZone 필드에 IANA 시간대 이름 지정 (Kubernetes 1.27+) C) 클러스터 전체 설정으로만 가능 D) CronJob은 timezone을 지원하지 않는다

정답: B

설명: Kubernetes 1.27부터 spec.timeZone 필드가 GA(Generally Available)로 지원됩니다. "America/New_York", "Asia/Seoul" 등 IANA 시간대 이름을 지정할 수 있습니다. 이전 버전에서는 UTC 기준으로만 스케줄을 설정해야 했습니다.

A) Pod Affinity는 특정 노드에, Pod Anti-Affinity는 특정 Pod와 같은 노드에 스케줄링 B) Pod Affinity는 특정 Pod와 같은 위치에, Pod Anti-Affinity는 특정 Pod와 다른 위치에 스케줄링 C) 두 개념은 동일하다 D) Pod Anti-Affinity는 deprecated되었다

정답: B

설명: Pod Affinity는 특정 레이블을 가진 Pod와 동일한 노드/존에 스케줄링하도록 합니다(예: 캐시와 앱을 같은 노드에 배치). Pod Anti-Affinity는 특정 레이블을 가진 Pod와 다른 노드/존에 스케줄링하도록 합니다(예: 가용성을 위해 복제본을 다른 노드에 분산).

A) 레이블 기반 필터링 B) 리소스의 특정 필드 값으로 필터링 C) 어노테이션 기반 필터링 D) 네임스페이스 필터링

정답: B

설명: --field-selector는 리소스 객체의 특정 필드 값으로 필터링합니다. --selector(또는 -l)가 레이블 기반인 것과 달리, field-selector는 status.phase, metadata.name, spec.nodeName 등 실제 리소스 필드를 기준으로 합니다.

A) Pod를 특정 노드에 강제 배치 B) Pod가 특정 taint가 있는 노드에 스케줄링될 수 있도록 허용 C) 특정 노드에서 Pod를 제거 D) 노드에 새로운 taint를 추가

정답: B

설명: Taint는 노드에 설정되어 특정 Pod가 스케줄링되지 않도록 합니다. Toleration은 Pod에 설정되어 특정 taint를 "견딜 수 있다"고 선언합니다. Toleration이 있다고 해서 해당 노드에 반드시 스케줄링되는 것은 아니며, 단지 스케줄링이 허용될 뿐입니다.

A) 클러스터 외부에서 접근 가능하다 B) 노드의 특정 포트를 통해 접근 가능하다 C) 클러스터 내부에서만 접근 가능한 가상 IP를 제공한다 D) 로드 밸런서를 자동으로 생성한다

정답: C

설명: ClusterIP 서비스는 클러스터 내부에서만 접근 가능한 가상 IP 주소(Cluster IP)를 할당합니다. 외부에서는 접근할 수 없으며, 클러스터 내부 서비스 간 통신에 사용됩니다. 기본 서비스 타입입니다.

A) 1-1024 B) 1024-65535 C) 30000-32767 D) 8000-9000

정답: C

설명: NodePort의 기본 포트 범위는 30000-32767입니다. kube-apiserver의 --service-node-port-range 플래그로 변경할 수 있습니다. 지정하지 않으면 이 범위 내에서 자동으로 포트가 할당됩니다.

A) service-name.cluster.local B) service-name.namespace.svc.cluster.local C) namespace.service-name.cluster.local D) service-name.default.kubernetes.local

정답: B

설명: Kubernetes에서 서비스의 완전한 DNS 이름은 service-name.namespace.svc.cluster.local 형식입니다. 같은 네임스페이스 내에서는 service-name만으로도 접근 가능합니다. Pod의 DNS는 pod-ip.namespace.pod.cluster.local 형식입니다(점을 대시로 변환).

A) kube-proxy가 IPVS 모드여야 한다 B) NetworkPolicy를 지원하는 CNI 플러그인이 필요하다 C) 클러스터가 cloud provider에서 실행되어야 한다 D) Ingress Controller가 설치되어 있어야 한다

정답: B

설명: NetworkPolicy는 CNI(Container Network Interface) 플러그인이 지원해야 적용됩니다. Calico, Cilium, WeaveNet 등이 NetworkPolicy를 지원합니다. Flannel은 기본적으로 NetworkPolicy를 지원하지 않습니다. CNI가 없으면 NetworkPolicy 리소스를 생성해도 트래픽 제어가 실제로 적용되지 않습니다.

A) NodePort 서비스가 있어야 한다 B) LoadBalancer 서비스가 있어야 한다 C) Ingress Controller가 클러스터에 배포되어 있어야 한다 D) kube-proxy가 실행 중이어야 한다

정답: C

설명: Ingress 리소스는 자체적으로 트래픽을 처리하지 않습니다. Nginx Ingress Controller, Traefik, HAProxy 등 Ingress Controller가 클러스터에 배포되어 있어야 Ingress 규칙이 적용됩니다. Ingress Controller는 Ingress 리소스를 감시하고 실제 라우팅을 처리합니다.

A) userspace B) iptables C) IPVS D) ebpf

정답: B

설명: kube-proxy의 기본 모드는 iptables입니다. IPVS 모드는 더 많은 로드 밸런싱 알고리즘을 지원하고 대규모 클러스터에서 더 나은 성능을 제공합니다. Cilium 같은 CNI는 kube-proxy 없이 eBPF로 서비스를 처리할 수 있습니다.

A) 외부 트래픽을 차단한다 B) 트래픽을 수신한 노드의 Pod에만 전달하여 클라이언트 IP를 보존한다 C) 모든 노드에 균등하게 트래픽을 분산한다 D) LoadBalancer 서비스에만 적용 가능하다

정답: B

설명: externalTrafficPolicy: Local을 설정하면 외부 트래픽이 해당 Pod를 실행 중인 노드에만 전달됩니다. 원본 클라이언트 IP가 보존되는 장점이 있지만, Pod가 없는 노드에서는 연결이 거부될 수 있습니다. 기본값인 Cluster는 모든 노드로 트래픽을 SNAT하여 전달합니다.

A) 컨테이너 런타임을 관리한다 B) Pod 간 네트워크 연결 및 IP 주소 할당을 담당한다 C) Kubernetes API 서버와의 통신을 처리한다 D) 스토리지 볼륨을 마운트한다

정답: B

설명: CNI 플러그인은 Pod가 생성될 때 네트워크 인터페이스를 설정하고 IP 주소를 할당하며, Pod 간 통신이 가능하도록 네트워크 라우팅을 구성합니다. Flannel, Calico, Cilium, WeaveNet, Canal 등이 대표적인 CNI 플러그인입니다.

A) 서비스가 외부에서 접근 불가능하다 B) 개별 Pod IP를 직접 DNS로 반환하여 클라이언트가 Pod를 직접 선택할 수 있다 C) 로드 밸런싱 없이 무작위로 Pod에 전달한다 D) StatefulSet에서만 사용 가능하다

정답: B

설명: Headless Service는 clusterIP: None으로 설정하며, 가상 IP 없이 DNS가 직접 Pod의 IP 목록을 반환합니다. StatefulSet과 함께 사용하면 각 Pod에 안정적인 DNS 이름(pod-0.service.namespace.svc.cluster.local)을 제공합니다.

A) 어떤 Pod도 선택하지 않는다 B) 해당 네임스페이스의 모든 Pod를 선택한다 C) 모든 네임스페이스의 모든 Pod를 선택한다 D) 시스템 Pod만 선택한다

정답: B

설명: NetworkPolicy에서 podSelector: {}는 빈 셀렉터로, 해당 NetworkPolicy가 배포된 네임스페이스의 모든 Pod를 선택합니다. 모든 Pod에 네트워크 정책을 적용하거나 기본 차단 정책을 만들 때 사용합니다.

A) PVC 삭제 시 PV도 자동으로 삭제된다 B) PVC 삭제 시 PV의 데이터가 초기화된다 C) PVC 삭제 후에도 PV가 유지되며, 관리자가 수동으로 처리해야 한다 D) PVC 삭제 시 PV가 다른 PVC에 자동으로 바인딩된다

정답: C

설명: Retain 정책은 PVC가 삭제되어도 PV를 유지합니다. PV는 Released 상태가 되며, 데이터는 보존됩니다. 관리자가 수동으로 PV의 claimRef를 제거하거나 삭제해야 재사용할 수 있습니다. Delete는 PVC 삭제 시 PV도 삭제, Recycle은 deprecated되었습니다.

A) 하나의 노드에서 읽기/쓰기 가능 B) 여러 노드에서 동시에 읽기만 가능 C) 여러 노드에서 동시에 읽기/쓰기 가능 D) 하나의 Pod에서만 읽기/쓰기 가능

정답: C

설명: ReadWriteMany(RWX)는 여러 노드에서 동시에 읽기/쓰기가 가능합니다. NFS, CephFS, Azure File 등이 지원합니다. ReadWriteOnce(RWO)는 하나의 노드에서 읽기/쓰기, ReadOnlyMany(ROX)는 여러 노드에서 읽기만 가능합니다.

A) 기존 PV를 관리한다 B) 동적 PV 프로비저닝을 위한 스토리지 속성을 정의한다 C) Pod에 직접 스토리지를 할당한다 D) 네트워크 스토리지 접근을 차단한다

정답: B

설명: StorageClass는 PVC가 생성될 때 자동으로 PV를 동적으로 프로비저닝하는 방법을 정의합니다. provisioner(예: kubernetes.io/aws-ebs), reclaimPolicy, parameters 등을 지정합니다. volumeBindingMode: WaitForFirstConsumer는 Pod가 스케줄링될 때까지 PV 생성을 지연시킵니다.

A) 노드가 재시작되어도 데이터가 유지된다 B) Pod가 삭제되면 데이터도 삭제되며, Pod 내 컨테이너 간 데이터 공유에 사용된다 C) 여러 Pod 간 데이터를 공유할 수 있다 D) PVC 없이 외부 스토리지에 접근한다

정답: B

설명: emptyDir는 Pod가 노드에 할당될 때 생성되고, Pod가 삭제되면 함께 삭제됩니다. Pod 내의 여러 컨테이너 간에 파일을 공유하는 데 유용합니다. 기본적으로 노드의 디스크를 사용하지만 medium: Memory로 tmpfs를 사용할 수도 있습니다.

A) 환경 변수로 주입하는 것보다 더 빠르다 B) 파일로 마운트되어 런타임 중 ConfigMap 변경이 자동으로 반영될 수 있다 C) 암호화된 데이터를 저장할 수 있다 D) 영구 스토리지처럼 데이터가 유지된다

정답: B

설명: ConfigMap을 볼륨으로 마운트하면 ConfigMap 업데이트 시 마운트된 파일이 자동으로 업데이트됩니다(kubelet의 syncFrequency에 따라). 환경 변수로 주입된 ConfigMap은 Pod 재시작 없이는 업데이트되지 않습니다.

A) kubectl get pod로 Pod 목록 확인 B) kubectl logs POD_NAME으로 컨테이너 로그 확인 C) kubectl delete pod로 Pod 재생성 D) Node 재시작

정답: B

설명: CrashLoopBackOff는 컨테이너가 계속 충돌하여 재시작되는 상태입니다. kubectl logs POD_NAME으로 컨테이너의 stdout/stderr 로그를 확인하고, 필요한 경우 kubectl logs POD_NAME --previous로 이전 충돌 로그를 확인합니다. kubectl describe pod로 이벤트도 확인합니다.

A) Pod의 CPU/메모리 부족 B) 잘못된 이미지 이름/태그 또는 프라이빗 레지스트리 인증 정보 없음 C) 네트워크 PolicyMap 차단 D) PVC 바인딩 실패

정답: B

설명: ImagePullBackOff의 주요 원인: 1) 이미지 이름이나 태그가 잘못됨, 2) 이미지가 존재하지 않음, 3) 프라이빗 레지스트리에 대한 인증 정보(imagePullSecrets) 미설정, 4) 네트워크 연결 문제. kubectl describe pod의 Events 섹션에서 상세 오류 메시지를 확인할 수 있습니다.

A) kube-apiserver 로그만 확인 B) kubelet 서비스 상태, 로그, 네트워크 연결, 디스크/메모리 상태 C) etcd 상태만 확인 D) Pod 삭제 후 재생성

정답: B

설명: Node NotReady 상태 진단: 1) systemctl status kubelet으로 kubelet 상태 확인, 2) journalctl -u kubelet -f로 kubelet 로그 확인, 3) 노드의 디스크 압력/메모리 압력/PID 압력 확인(kubectl describe node), 4) 네트워크 연결 확인, 5) 컨테이너 런타임(containerd/docker) 상태 확인.

A) kubectl get etcd B) etcdctl endpoint health C) systemctl status etcd D) kubectl describe etcd

정답: B

설명: ETCDCTL_API=3 etcdctl endpoint health --endpoints=https://127.0.0.1:2379 --cacert=... --cert=... --key=... 명령어로 etcd 클러스터의 상태를 확인합니다. etcdctl endpoint status는 각 멤버의 상태 및 leader 정보를 확인합니다.

A) kubectl exec POD_NAME COMMAND B) kubectl exec -it POD_NAME -- COMMAND C) kubectl run POD_NAME -- COMMAND D) kubectl attach POD_NAME -c COMMAND

정답: B

설명: kubectl exec -it POD_NAME -- /bin/sh 명령어로 Pod에 대화형 셸을 열 수 있습니다. -i는 stdin을 열고, -t는 TTY를 할당합니다. 특정 컨테이너를 지정하려면 -c CONTAINER_NAME을 추가합니다. 단일 명령 실행: kubectl exec POD_NAME -- ls /etc

A) kubectl get pod --resources B) kubectl top pod C) kubectl describe pod --metrics D) kubectl stats pod

정답: B

설명: kubectl top pod는 Pod의 CPU와 메모리 사용량을 표시합니다. 이 명령어는 Metrics Server가 클러스터에 설치되어 있어야 작동합니다. kubectl top node는 노드의 리소스 사용량을 확인합니다.

A) 컨테이너가 충돌하는 경우 B) 이미지를 찾을 수 없는 경우 C) 스케줄러가 적합한 노드를 찾지 못하거나 PVC가 바인딩되지 않은 경우 D) 네트워크 연결 문제

정답: C

설명: Pod Pending 상태의 주요 원인: 1) 리소스 부족(CPU/메모리)으로 스케줄링 불가, 2) taint/toleration 불일치, 3) nodeSelector/affinity 조건을 만족하는 노드 없음, 4) PVC가 바인딩되지 않음, 5) 스케줄러 미실행. kubectl describe pod의 Events에서 이유를 확인할 수 있습니다.

A) kubectl logs kube-apiserver -n default B) kubectl logs -n kube-system kube-apiserver-NODENAME C) systemctl logs kube-apiserver D) journalctl -u kubernetes

정답: B

설명: Static Pod로 실행되는 kube-apiserver의 로그는 kubectl logs -n kube-system kube-apiserver-controlplane으로 확인할 수 있습니다. Pod 이름은 노드 이름을 포함합니다. 또는 crictl logs CONTAINER_ID로도 확인 가능합니다.

A) CPU 한계 초과 - limits.cpu를 늘린다 B) 메모리 한계 초과 - limits.memory를 늘리거나 애플리케이션 메모리 사용 최적화 C) 디스크 공간 부족 - PVC 크기를 늘린다 D) 네트워크 타임아웃 - 재시도 설정 추가

정답: B

설명: OOMKilled(Out of Memory Killed)는 컨테이너가 limits.memory에 설정된 메모리 한계를 초과했을 때 발생합니다. 해결책: 1) limits.memory 값을 적절히 늘림, 2) 애플리케이션의 메모리 누수 확인 및 수정, 3) JVM의 경우 힙 크기(-Xmx) 조정.

A) kubectl get events B) kubectl get events --sort-by=.metadata.creationTimestamp C) kubectl describe events D) kubectl logs events

정답: B

설명: kubectl get events --sort-by=.metadata.creationTimestamp 명령어로 이벤트를 시간순으로 정렬하여 확인합니다. 특정 네임스페이스: kubectl get events -n NAMESPACE. 실시간 확인: kubectl get events --watch. kubectl describe pod 명령어의 Events 섹션에서도 Pod 관련 이벤트를 확인할 수 있습니다.

A) /etc/kubernetes/kubelet.conf B) /var/lib/kubelet/config.yaml C) /etc/kubelet/config.yaml D) /usr/local/kubernetes/kubelet.conf

정답: B

설명: kubelet의 기본 설정 파일은 /var/lib/kubelet/config.yaml이며, 시스템 서비스 설정은 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf 또는 /etc/default/kubelet에 있습니다. systemctl status kubelet으로 실행 중인 설정을 확인할 수 있습니다.

A) Pod가 실행 중이지 않기 때문 B) 요구 조건(storageClass, accessMode, capacity)을 만족하는 PV가 없거나 동적 프로비저닝에 실패 C) 네임스페이스가 잘못 설정되어 있기 때문 D) 노드에 디스크 공간이 부족하기 때문

정답: B

설명: PVC Pending 상태의 원인: 1) 요구하는 StorageClass가 없음, 2) 요구하는 accessMode를 지원하는 PV가 없음, 3) 요구하는 용량을 만족하는 PV가 없음, 4) 동적 프로비저닝 실패, 5) volumeBindingMode: WaitForFirstConsumer로 Pod 스케줄링 대기 중. kubectl describe pvc로 상세 원인 확인.

A) 컨테이너 로그 B) IP 주소, 노드 이름, 게이트웨이 C) 리소스 사용량 D) 환경 변수

정답: B

설명: -o wide 옵션은 기본 출력에 추가로 IP 주소, 노드 이름(NODE 컬럼), Nominated Node, Readiness Gates 정보를 표시합니다. Pod가 어느 노드에서 실행 중인지, 어떤 IP를 갖는지 빠르게 확인할 때 유용합니다.

A) Error B) Warning FailedScheduling C) Normal SchedulingFailed D) Critical NoNodeAvailable

정답: B

설명: kube-scheduler가 Pod를 스케줄링할 수 없을 때 Warning FailedScheduling 이벤트가 생성됩니다. kubectl describe pod POD_NAME에서 Events 섹션을 확인하면 "0/3 nodes are available: 3 Insufficient memory" 등의 상세 메시지를 볼 수 있습니다.

A) Deployment를 이전 버전으로 롤백한다 B) 롤링 방식으로 모든 Pod를 재시작한다 C) Deployment를 삭제하고 재생성한다 D) Pod를 일시 중지한다

정답: B

설명: kubectl rollout restart deployment는 Deployment의 Pod를 롤링 방식으로 재시작합니다. 이미지나 설정 변경 없이 ConfigMap이나 Secret 업데이트를 적용하거나 Pod를 갱신할 때 유용합니다. kubectl rollout status로 진행 상황을 모니터링할 수 있습니다.

A) kubectl attach B) spec.serviceAccountName 필드에 ServiceAccount 이름 지정 C) kubectl link D) Pod 레이블에 serviceaccount=NAME 추가

정답: B

설명: Pod 또는 Deployment의 spec.serviceAccountName 필드에 ServiceAccount 이름을 지정합니다. 지정하지 않으면 해당 네임스페이스의 default ServiceAccount가 자동으로 마운트됩니다. ServiceAccount 토큰은 /var/run/secrets/kubernetes.io/serviceaccount/ 경로에 마운트됩니다.

A) kubectl debug node B) kubectl run tmp --image=busybox --rm -it -- /bin/sh C) kubectl create pod debug D) kubectl network debug

정답: B

설명: kubectl run tmp --image=busybox --rm -it -- /bin/sh로 임시 디버깅 Pod를 생성합니다. --rm은 종료 후 자동 삭제, -it는 대화형 TTY를 의미합니다. nicolaka/netshoot 이미지는 다양한 네트워크 디버깅 도구를 포함하고 있어 유용합니다.

A) cluster와 user는 독립적이며 context와 관련이 없다 B) context는 cluster와 user(+ namespace)를 묶어서 어떤 클러스터에 어떤 자격증명으로 접근할지 정의한다 C) user가 cluster를 포함한다 D) cluster가 user와 context를 포함한다

정답: B

설명: kubeconfig 파일은 세 가지 섹션으로 구성됩니다: clusters(서버 주소 및 CA 정보), users(자격증명), contexts(cluster + user + namespace 조합). context는 특정 클러스터에 특정 자격증명으로 접근하는 방법을 정의합니다. kubectl config use-context로 활성 context를 변경합니다.

A) kubectl get pod -o env B) kubectl exec POD_NAME -- env C) kubectl describe pod --env D) kubectl get configmap

정답: B

설명: kubectl exec POD_NAME -- env 명령어로 실행 중인 컨테이너의 환경 변수를 확인합니다. kubectl exec POD_NAME -- printenv VARIABLE_NAME으로 특정 환경 변수 값을 확인할 수도 있습니다. kubectl describe pod에서도 환경 변수 목록을 볼 수 있습니다.

A) kube-apiserver B) kube-scheduler C) kubelet D) kube-controller-manager

정답: C

설명: kubelet은 각 노드(control plane 및 worker node)에서 실행되는 노드 에이전트로, control plane 컴포넌트가 아닙니다. Control plane 컴포넌트: kube-apiserver(API 서버), etcd(상태 저장소), kube-scheduler(Pod 스케줄링), kube-controller-manager(컨트롤러 관리). Worker node 컴포넌트: kubelet, kube-proxy, container runtime.