소개
이 종합 가이드에 오신 것을 환영합니다. Kubernetes 인터뷰에서 탁월한 성과를 거두는 데 필요한 지식과 자신감을 갖추도록 설계되었습니다. 컨테이너 오케스트레이션 여정을 막 시작했거나 숙련된 전문가로서 전문성을 심화하고자 하는 경우, 이 문서는 Kubernetes 개념을 마스터하기 위한 구조화된 접근 방식을 제공합니다. 기본 원칙 및 고급 아키텍처 고려 사항부터 실제 문제 해결, 시나리오 기반 과제, 개발자, 관리자 및 DevOps 엔지니어를 위한 역할별 문의에 이르기까지 광범위한 질문을 세심하게 선별했습니다. 이해도를 높이고 문제 해결 능력을 연마하며 모든 Kubernetes 인터뷰를 자신 있게 통과할 준비를 하십시오.
Kubernetes 기본 및 핵심 개념
Kubernetes 란 무엇이며 왜 사용되나요?
답변:
Kubernetes 는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하는 오픈 소스 컨테이너 오케스트레이션 플랫폼입니다. 프로덕션 환경에서 애플리케이션을 실행하는 복잡성을 처리하고 높은 가용성, 확장성 및 효율적인 리소스 활용을 보장하는 데 사용됩니다.
Kubernetes 에서 Pod 와 Container 의 차이점을 설명해주세요.
답변:
컨테이너는 애플리케이션 실행에 필요한 모든 것을 포함하는 가볍고 실행 가능한 소프트웨어 패키지입니다. Pod 는 Kubernetes 에서 가장 작은 배포 가능한 단위로, 하나 이상의 컨테이너, 스토리지 리소스, 고유한 네트워크 IP 및 컨테이너 실행 방식을 제어하는 옵션을 캡슐화합니다. Pod 내의 모든 컨테이너는 동일한 네트워크 네임스페이스를 공유하며 localhost 를 통해 통신할 수 있습니다.
Kubernetes 에서 Node 란 무엇인가요?
답변:
Node 는 Kubernetes 의 워커 머신으로, VM 또는 물리적 머신일 수 있습니다. 각 Node 에는 Pod 를 실행하는 데 필요한 구성 요소 (Kubelet(마스터용 에이전트), Kube-proxy(네트워크 프록시) 및 컨테이너 런타임 (예: Docker, containerd)) 가 포함됩니다.
Kubernetes 제어 평면 (마스터 노드) 의 주요 구성 요소를 설명해주세요.
답변:
제어 평면은 Kube-API Server(Kubernetes API 노출), etcd(클러스터 데이터에 대한 일관되고 고가용성 있는 키 - 값 저장소), Kube-Scheduler(새로운 Pod 를 감시하고 Node 에 할당), Kube-Controller-Manager(Node, Replication, Endpoint 및 Service Account 컨트롤러와 같은 컨트롤러 프로세스 실행) 로 구성됩니다.
Kubernetes 에서 Deployment 란 무엇이며 왜 사용되나요?
답변:
Deployment 는 Pod 및 ReplicaSet 의 원하는 상태를 관리하는 상위 수준의 추상화입니다. Pod 및 ReplicaSet 에 대한 선언적 업데이트를 제공하여 애플리케이션의 복제본 수를 정의하고 업데이트를 롤아웃하거나 이전 버전으로 롤백하는 방법을 지정할 수 있습니다.
Kubernetes 는 Pod 의 네트워킹을 어떻게 처리하나요?
답변:
Kubernetes 는 각 Pod 에 고유한 IP 주소를 할당합니다. Pod 내의 모든 컨테이너는 이 IP 를 공유하며 localhost 를 통해 통신할 수 있습니다. 다른 Node 에 있는 Pod 는 네트워크 오버레이를 구현하는 CNI(Container Network Interface) 플러그인을 사용하여 통신할 수 있습니다. Kube-proxy 는 서비스 검색 및 로드 밸런싱을 활성화하기 위해 Node 에서 네트워크 규칙을 관리합니다.
Kubernetes 에서 Service 란 무엇이며 어떤 종류가 있나요?
답변:
Service 는 Pod 집합에서 실행되는 애플리케이션을 네트워크 서비스로 노출하는 추상적인 방법입니다. Pod 그룹에 대한 안정적인 IP 주소와 DNS 이름을 제공합니다. 일반적인 유형으로는 ClusterIP(클러스터 내부), NodePort(각 Node IP 의 정적 포트로 서비스 노출), LoadBalancer(클라우드 제공업체의 로드 밸런서를 사용하여 외부로 서비스 노출) 가 있습니다.
ReplicaSet 의 목적을 설명해주세요.
답변:
ReplicaSet 은 지정된 수의 Pod 복제본이 항상 실행되도록 보장합니다. 주요 목적은 Pod 집합의 안정성과 가용성을 유지하는 것입니다. ReplicaSet 을 직접 사용할 수도 있지만, 일반적으로 롤링 업데이트와 같은 고급 기능을 위해 Deployment 에서 관리됩니다.
kubectl이란 무엇이며 주요 기능은 무엇인가요?
답변:
kubectl은 Kubernetes 클러스터와 상호 작용하기 위한 명령줄 도구입니다. 사용자는 Kubernetes 클러스터를 대상으로 명령을 실행하고, 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하고, 로그를 볼 수 있습니다. Kubernetes API 서버와 통신합니다.
Kubernetes 에서 etcd의 역할은 무엇인가요?
답변:
etcd는 Kubernetes 가 모든 클러스터 데이터를 저장하는 데 사용하는 분산되고 일관되며 고가용성 있는 키 - 값 저장소입니다. 여기에는 구성 데이터, 상태 정보, 메타데이터 및 클러스터의 원하는 상태가 포함됩니다. Kubernetes 클러스터의 단일 진실 공급원 역할을 합니다.
고급 Kubernetes 주제 및 아키텍처
Kubernetes Operator 의 개념을 설명하고 사용 사례를 예시로 들어주세요.
답변:
Kubernetes Operator 는 Kubernetes 네이티브 애플리케이션을 패키징, 배포 및 관리하는 방법입니다. Kubernetes API 를 확장하여 복잡한 애플리케이션 인스턴스를 생성, 구성 및 관리합니다. 데이터베이스 (예: Cassandra, MySQL) 와 같은 상태 저장 애플리케이션에 Operator 를 사용하여 백업, 업그레이드 및 확장과 같은 작업을 자동화할 수 있습니다.
Kubernetes 에서 Custom Resource Definition (CRD) 의 목적을 설명해주세요.
답변:
Custom Resource Definition (CRD) 을 사용하면 Kubernetes API 를 확장하여 자체 사용자 지정 리소스를 Kubernetes 에 정의할 수 있습니다. 이를 통해 Kubernetes 가 관리할 수 있는 구조화된 데이터를 저장하고 검색할 수 있습니다. CRD 는 Operator 를 구축하고 애플리케이션별 객체를 정의하는 데 기본적입니다.
Kubernetes API Server 는 요청에 대한 인증 및 권한 부여를 어떻게 처리하나요?
답변:
API Server 는 클라이언트 인증서, 베어러 토큰 또는 서비스 계정 토큰과 같은 다양한 방법을 통해 인증을 처리합니다. 인증 후 RBAC(Role-Based Access Control), Node 권한 부여 또는 ABAC(Attribute-Based Access Control) 와 같은 모듈을 사용하여 권한 부여가 수행됩니다. RBAC 가 가장 일반적이며, 권한이 있는 역할을 정의하고 이를 사용자 또는 서비스 계정에 바인딩합니다.
Kubernetes 에서 DaemonSet 과 Deployment 의 차이점은 무엇인가요?
답변:
Deployment 는 동일한 Pod 집합을 관리하며, 일반적으로 상태 비저장 애플리케이션을 위해 클러스터 전체에서 원하는 수의 복제본이 실행되도록 보장합니다. DaemonSet 은 모든 (또는 일부) 노드에서 Pod 복사본을 실행하도록 보장하며, 모든 노드에서 실행되어야 하는 로그 수집기 (예: Fluentd) 또는 모니터링 에이전트 (예: Node Exporter) 와 같은 클러스터 수준 서비스에 유용합니다.
Pod Security Policies (PSPs) 의 개념을 설명하고 왜 사용 중단되는지 알려주세요.
답변:
Pod Security Policies (PSPs) 는 Pod 및 컨테이너에 보안 표준을 적용하는 Admission Controller 였습니다. 이를 통해 클러스터 관리자는 특권 모드, 호스트 네트워크 액세스 및 볼륨 유형과 같은 보안에 민감한 측면을 제어할 수 있었습니다. PSP 는 더 유연하고 세분화된 제어를 제공하는 Pod Security Admission (PSA) 및 OPA Gatekeeper 와 같은 정책 엔진을 위해 사용 중단되고 있습니다.
Kubernetes 제어 평면의 고가용성을 어떻게 달성하나요?
답변:
제어 평면의 고가용성은 API Server, etcd, Controller Manager 및 Scheduler 의 여러 인스턴스를 실행하여 달성됩니다. etcd 는 일반적으로 쿼럼 기반 클러스터 (예: 3 개 또는 5 개 노드) 로 실행됩니다. API Server 앞에 로드 밸런서가 배치되어 트래픽을 분산하고 장애 조치를 제공합니다.
Mutating Admission Webhook 이란 무엇이며 어떻게 사용할 수 있나요?
답변:
Mutating Admission Webhook 은 Kubernetes API 서버에 대한 요청을 지속하기 전에 수정할 수 있는 HTTP 콜백입니다. 사이드카 컨테이너를 주입하거나, 레이블/주석을 추가하거나, 필드의 기본값을 설정할 수 있습니다. 예를 들어, 서비스 메시 통합을 위해 Pod 에 istio-proxy 사이드카를 자동으로 주입할 수 있습니다.
Kubernetes 클러스터에서 etcd 의 역할에 대해 설명해주세요.
답변:
etcd 는 Kubernetes 의 일관되고 고가용성 있는 키 - 값 저장소 역할을 합니다. 모든 Kubernetes 객체 (Pod, Deployment, Service 등) 에 대한 구성, 상태 및 메타데이터를 포함한 모든 클러스터 데이터를 저장합니다. 클러스터 작동에 매우 중요하며, 가용성은 클러스터의 상태에 직접적인 영향을 미칩니다.
Kubernetes 는 네트워크 정책 적용을 어떻게 처리하나요?
답변:
Kubernetes Network Policy 는 Pod 그룹이 서로 및 외부 엔드포인트와 통신하는 방법을 정의하는 사양입니다. Calico, Cilium 또는 Weave Net 과 같이 NetworkPolicy 를 지원하는 네트워크 플러그인 (CNI) 에 의해 구현됩니다. CNI 플러그인은 이러한 정책을 방화벽 규칙으로 변환합니다.
Taints 와 Tolerations 는 무엇이며 Pod 스케줄링에 어떻게 사용되나요?
답변:
Taints 는 노드에 적용되어 해당 Pod 에 일치하는 Tolerations 가 없는 한 특정 Pod 에 '부적합'으로 표시합니다. Tolerations 는 Pod 에 적용되어 Tainted 노드에 스케줄링할 수 있도록 합니다. 이 메커니즘은 특정 워크로드 (예: GPU 노드) 를 위해 노드를 예약하거나 비정상적인 노드에서 Pod 를 제거하는 데 사용됩니다.
시나리오 기반 및 설계 질문
애플리케이션 Pod 가 자주 재시작됩니다. Kubernetes 에서 이 문제를 어떻게 해결하시겠습니까?
답변:
먼저 kubectl describe pod <pod-name>을 사용하여 이벤트와 상태를 확인하겠습니다. 그런 다음 kubectl logs <pod-name>을 사용하여 오류에 대한 애플리케이션 로그를 검토하겠습니다. 마지막으로 충돌 원인을 파악하기 위해 이전 컨테이너 인스턴스의 로그에 대해 kubectl logs <pod-name> -p를 검사하겠습니다.
다운타임 없이 애플리케이션의 새 버전을 배포해야 합니다. Kubernetes 에서 이를 어떻게 달성하시겠습니까?
답변:
Deployment 에 RollingUpdate 전략을 사용하겠습니다. 이를 통해 Kubernetes 는 이전 Pod 를 새 Pod 로 점진적으로 교체하여 항상 최소한의 Pod 가 사용 가능하도록 보장합니다. 새 Pod 가 트래픽을 라우팅하기 전에 준비되었는지 확인하려면 상태 확인 (준비 상태 프로브) 이 중요합니다.
Deployment 대신 StatefulSet 을 사용해야 하는 시나리오를 설명해주세요.
답변:
안정적이고 고유한 네트워크 식별자, 안정적인 영구 스토리지 및 순서대로 정상적인 배포/확장/삭제를 요구하는 애플리케이션에 StatefulSet 을 사용하겠습니다. 각 복제본이 자체 영구 볼륨과 예측 가능한 호스트 이름을 필요로 하는 PostgreSQL 과 같은 데이터베이스 또는 Apache Kafka 와 같은 분산 시스템이 예시입니다.
Kubernetes 클러스터의 리소스 (CPU/메모리) 가 부족합니다. 이를 진단하고 완화하기 위해 어떤 단계를 취하시겠습니까?
답변:
먼저 kubectl top nodes 및 kubectl top pods를 사용하여 리소스를 많이 사용하는 것을 식별하겠습니다. 그런 다음 Pod 의 리소스 요청 및 제한을 확인하여 적절하게 설정되었는지 확인하겠습니다. 완화 단계에는 애플리케이션 리소스 사용량 최적화, 클러스터 수평 확장 또는 리소스 요청/제한 조정이 포함됩니다.
Kubernetes 에서 실행 중인 웹 애플리케이션을 인터넷에 안전하게 노출하려면 어떻게 해야 하나요?
답변:
LoadBalancer 또는 NodePort 유형의 Kubernetes Service 를 사용하여 클러스터 내 또는 외부 트래픽에 애플리케이션을 노출하겠습니다. 안전한 HTTP/HTTPS 액세스를 위해 Ingress 컨트롤러 (예: Nginx Ingress) 를 배포하고 TLS 종료가 있는 Ingress 리소스를 정의하며, 종종 Cert-Manager 와 통합하여 자동화된 인증서 프로비저닝을 수행하겠습니다.
데이터를 처리한 후 종료되는 일회성 배치 작업을 실행해야 합니다. 어떤 Kubernetes 객체를 사용하시겠습니까?
답변:
Kubernetes Job 객체를 사용하겠습니다. Job 은 지정된 수의 Pod 가 작업을 성공적으로 완료하도록 보장합니다. 반복 작업의 경우 정의된 일정에 따라 Job 객체를 생성하는 CronJob 을 사용하겠습니다.
Kubernetes 에서 중요한 마이크로서비스에 대한 고가용성 전략을 설계해주세요.
답변:
안티 - 어피니티 규칙을 사용하여 다른 노드에 분산된 여러 복제본 (예: 3 개 이상) 을 가진 Deployment 로 마이크로서비스를 배포하겠습니다. 강력한 준비 상태 및 라이브니스 프로브를 구현하겠습니다. 데이터 영속성을 위해 분산 데이터베이스 또는 영구 볼륨이 있는 StatefulSet 을 사용하겠습니다. 마지막으로 적절한 리소스 요청/제한 및 자동 확장을 보장하겠습니다.
Kubernetes 에서 애플리케이션의 API 키 또는 데이터베이스 자격 증명과 같은 민감한 정보를 어떻게 처리하시겠습니까?
답변:
Kubernetes Secrets 를 사용하여 민감한 정보를 저장하겠습니다. 이러한 비밀은 파일로 Pod 에 마운트하거나 환경 변수로 노출할 수 있습니다. 보안 강화를 위해 HashiCorp Vault 또는 클라우드 제공업체 KMS 서비스와 같은 외부 비밀 관리 시스템과 통합하겠습니다.
애플리케이션이 Kubernetes 클러스터 외부에서 실행 중인 데이터베이스에 액세스해야 합니다. 이를 안전하게 구성하려면 어떻게 해야 하나요?
답변:
클러스터 내에서 외부 데이터베이스를 나타내기 위해 ExternalName 유형의 Kubernetes Service 또는 Endpoints가 있는 헤드리스 Service 를 생성하겠습니다. 이를 통해 Pod 는 Kubernetes 서비스 이름으로 데이터베이스를 확인할 수 있습니다. 네트워크 정책을 사용하여 외부 트래픽을 데이터베이스의 IP 및 포트로만 제한하고, 자격 증명은 Kubernetes Secrets 를 통해 관리하겠습니다.
부하가 많이 걸릴 때 애플리케이션의 응답 시간이 증가하는 것을 관찰했습니다. 이를 처리하기 위해 Kubernetes 에서 애플리케이션을 어떻게 확장하시겠습니까?
답변:
CPU 사용량 또는 초당 요청 수와 같은 사용자 지정 메트릭을 기반으로 확장하도록 구성된 Deployment 에 대해 Horizontal Pod Autoscaling (HPA) 을 구현하겠습니다. 이렇게 하면 수요가 증가할 때 자동으로 더 많은 Pod 복제본이 추가됩니다. 또한 기본 클러스터에 충분한 노드 용량이 있는지 확인하거나 Cluster Autoscaler 를 구현하겠습니다.
역할별 질문 (개발자, 관리자, DevOps)
개발자: 'Pending' 상태에 머무르는 Pod 를 어떻게 해결하시겠습니까?
답변:
먼저 kubectl describe pod <pod-name>을 사용하여 리소스 부족 (CPU/메모리), 노드 어피니티/테인트 문제 또는 바인딩되지 않은 영구 볼륨 클레임과 같은 문제를 나타내는 이벤트를 확인하겠습니다. 다음으로 kubectl describe node <node-name>을 사용하여 노드의 상태 및 리소스 가용성을 검사하겠습니다.
개발자: 애플리케이션의 새 버전을 배포해야 합니다. Kubernetes 에서 다운타임을 최소화하기 위한 가장 안전한 방법은 무엇인가요?
답변:
Deployment 에 RollingUpdate 전략을 사용하겠습니다. 이를 통해 이전 Pod 를 새 Pod 로 점진적으로 교체하여 지속적인 가용성을 보장합니다. 또한 트래픽이 라우팅되기 전에 새 Pod 가 정상인지 확인하기 위해 준비 상태 프로브를 정의하겠습니다.
관리자: 사용자가 클러스터에서 실행 중인 서비스에 액세스할 수 없다고 보고합니다. 이 문제를 진단하기 위해 어떤 단계를 취하시겠습니까?
답변:
먼저 Service 의 kubectl describe service <service-name>을 확인하여 구성 및 엔드포인트 준비 상태를 확인하겠습니다. 그런 다음 서비스의 백업 Pod 를 상태 확인 (kubectl get pods -o wide) 을 위해 검사하고 애플리케이션 오류에 대한 로그를 확인하겠습니다. 네트워크 정책 또는 방화벽 규칙도 요인이 될 수 있습니다.
관리자: NetworkPolicy 를 사용해야 하는 시나리오를 설명해주세요.
답변:
NetworkPolicy 를 사용하여 Pod 간 또는 Pod 와 외부 엔드포인트 간의 트래픽 흐름을 제어하겠습니다. 예를 들어, 데이터베이스 Pod 를 격리하여 특정 애플리케이션 Pod 만 연결할 수 있도록 하거나 개발 네임스페이스에서 나가는 트래픽을 제한하겠습니다.
DevOps: Kubernetes 에서 비밀 (예: API 키, 데이터베이스 자격 증명) 을 안전하게 관리하는 방법은 무엇인가요?
답변:
Kubernetes Secrets 는 기본 인코딩을 제공하지만, 진정한 보안을 위해서는 HashiCorp Vault, AWS Secrets Manager 또는 Azure Key Vault 와 같은 외부 비밀 관리 솔루션과 통합하겠습니다. 이러한 솔루션은 비밀을 Pod 에 직접 주입하거나 CSI 드라이버를 사용하여 동적으로 마운트하여 Git 에 민감한 데이터를 직접 저장하는 것을 피할 수 있습니다.
DevOps: Helm 차트의 목적과 CI/CD 파이프라인에 어떤 이점을 주는지 설명해주세요.
답변:
Helm 차트는 Kubernetes 의 패키지 관리자로, 필요한 모든 Kubernetes 리소스 (Deployment, Service, ConfigMap 등) 를 단일 버전 관리 가능한 단위로 묶습니다. CI/CD에서는 환경 전반에 걸쳐 일관되고 반복 가능한 배포, 쉬운 버전 업그레이드/롤백 및 구성 매개변수화를 허용합니다.
DevOps: Kubernetes 에서 마이크로서비스 애플리케이션에 대한 지속적인 배포를 어떻게 구현하시겠습니까?
답변:
Argo CD 또는 Flux 와 같은 도구를 사용하여 GitOps 접근 방식을 사용하겠습니다. 코드 병합 및 테스트 후 CI 파이프라인은 Docker 이미지를 빌드하고 Kubernetes 매니페스트 (예: Git 리포지토리) 에서 이미지 태그를 업데이트합니다. 그런 다음 GitOps 연산자는 Git 의 변경 사항을 감지하고 이를 클러스터에 자동으로 적용하여 원하는 상태 동기화를 보장합니다.
DevOps: Kubernetes 클러스터 및 애플리케이션에 대해 모니터링할 주요 메트릭은 무엇인가요?
답변:
클러스터의 경우 노드 리소스 사용량 (CPU, 메모리, 디스크), API 서버 지연 시간 및 etcd 상태를 모니터링하겠습니다. 애플리케이션의 경우 주요 메트릭에는 Pod CPU/메모리 사용량, 요청 속도, 오류 속도, 지연 시간 및 애플리케이션별 비즈니스 메트릭이 포함됩니다. Prometheus 와 Grafana 는 이를 위한 일반적인 도구입니다.
DevOps: Kubernetes 에서 상태 저장 애플리케이션에 대한 영구 스토리지를 어떻게 처리하는지 설명해주세요.
답변:
PersistentVolumes (PV) 및 PersistentVolumeClaims (PVC) 를 사용하겠습니다. PVC 는 StorageClass 에 의해 프로비저닝되는 PV 에서 스토리지를 요청합니다. 이는 기본 스토리지 인프라를 추상화하여 애플리케이션이 특정 사항을 알지 못하고 스토리지를 요청할 수 있도록 하며, Pod 가 재스케줄링되더라도 데이터 영속성을 보장합니다.
Kubernetes 문제 해결 및 디버깅
Pod 가 'Pending' 상태에 머물러 있습니다. 일반적인 이유는 무엇이며 어떻게 해결하시겠습니까?
답변:
일반적인 이유로는 리소스 부족 (CPU/메모리), 노드 테인트/허용 오차 또는 영구 볼륨 문제 등이 있습니다. kubectl describe pod <pod-name>을 사용하여 스케줄링 실패, 리소스 요청 및 볼륨 바인딩 상태에 대한 이벤트를 확인하겠습니다.
Pod 가 'CrashLoopBackOff' 상태입니다. 이것은 무엇을 의미하며 어떻게 디버깅하시겠습니까?
답변:
이는 Pod 내부의 컨테이너가 반복적으로 시작되고 충돌함을 나타냅니다. 먼저 kubectl logs <pod-name>을 사용하여 애플리케이션 오류를 확인하겠습니다. 로그가 도움이 되지 않으면 kubectl describe pod <pod-name>을 사용하여 OOMKilled 이벤트 또는 준비/라이브니스 프로브 실패를 확인하겠습니다.
멀티 컨테이너 Pod 에서 특정 컨테이너의 로그를 어떻게 확인하나요?
답변:
kubectl logs에 -c 플래그를 사용하여 컨테이너 이름을 지정할 수 있습니다. 예: kubectl logs <pod-name> -c <container-name>. 이를 통해 특정 서비스의 로그를 격리할 수 있습니다.
클러스터 외부에서 서비스에 액세스할 수 없습니다. 이 문제를 진단하기 위해 어떤 단계를 취하시겠습니까?
답변:
서비스 유형 (예: NodePort, LoadBalancer) 과 외부 IP/포트를 확인하겠습니다. 그런 다음 방화벽 규칙, 보안 그룹 및 네트워크 정책을 확인하겠습니다. 마지막으로 서비스의 셀렉터가 Pod 레이블과 올바르게 일치하는지, 그리고 Pod 가 실행 중이고 정상인지 확인하겠습니다.
네트워크 정책이 애플리케이션으로의 트래픽을 차단하고 있다고 의심됩니다. 이를 어떻게 확인할 수 있나요?
답변:
kubectl describe networkpolicy <policy-name>을 사용하여 규칙을 이해하겠습니다. 그런 다음 Pod 의 레이블과 네임스페이스를 확인하여 정책의 대상이 되는지 확인하겠습니다. kube-no-trouble 또는 디버그 Pod 내의 netshoot와 같은 도구를 사용하여 연결을 테스트할 수도 있습니다.
디버깅 목적으로 실행 중인 컨테이너에 쉘을 어떻게 얻나요?
답변:
kubectl exec -it <pod-name> -- /bin/bash (bash 가 없는 경우 /bin/sh) 를 사용할 수 있습니다. 이를 통해 컨테이너의 파일 시스템을 검사하고, 명령을 실행하고, 환경 내에서 직접 문제를 진단할 수 있습니다.
'ImagePullBackOff'의 일반적인 원인은 무엇이며 어떻게 해결하시겠습니까?
답변:
일반적인 원인으로는 잘못된 이미지 이름/태그, 개인 레지스트리 인증 문제 또는 레지스트리로의 네트워크 연결 문제가 있습니다. kubectl describe pod <pod-name>을 사용하여 이미지 풀 오류를 확인하고 이미지 이름, 레지스트리 자격 증명 (비밀) 및 네트워크 액세스를 확인하겠습니다.
애플리케이션에서 높은 지연 시간이 발생하지만 Pod 는 정상으로 보입니다. 문제는 무엇일 수 있나요?
답변:
이는 리소스 경합 (CPU 스로틀링), 비효율적인 애플리케이션 코드 또는 외부 종속성 문제일 수 있습니다. Pod 의 리소스 사용량 메트릭 (CPU/메모리) 을 확인하고, 느린 쿼리에 대한 애플리케이션 로그를 검토하고, 외부 서비스로의 네트워크 지연 시간을 검사하겠습니다.
라이브니스 또는 준비 상태 프로브 실패를 어떻게 디버깅하시겠습니까?
답변:
kubectl describe pod <pod-name>을 사용하여 프로브 실패 이벤트와 사용되는 특정 명령/경로를 확인하겠습니다. 그런 다음 kubectl logs <pod-name>을 사용하여 애플리케이션이 충돌하거나 프로브의 엔드포인트에 응답하지 않는지 확인하겠습니다. 컨테이너 내부에서 프로브 명령을 수동으로 실행하는 것도 도움이 될 수 있습니다.
노드가 'NotReady' 상태입니다. 일반적인 이유는 무엇이며 어떻게 조사하시겠습니까?
답변:
일반적인 이유로는 kubelet 이 실행되지 않거나, 컨트롤 플레인과의 통신을 방해하는 네트워크 문제 또는 노드 리소스 부족 등이 있습니다. 노드에 SSH 로 접속하여 systemctl status kubelet을 확인하고, kubelet 로그 (journalctl -u kubelet) 를 검토하고, API 서버로의 네트워크 연결을 확인하겠습니다.
Kubernetes 모범 사례 및 보안
Kubernetes 클러스터를 안전하게 보호하기 위한 주요 모범 사례는 무엇인가요?
답변:
주요 사례로는 최소 권한 원칙을 적용한 역할 기반 액세스 제어 (RBAC) 구현, Kubernetes 및 해당 구성 요소의 정기적인 업데이트, 컨테이너 이미지 취약점 스캔, 네트워크 정책을 사용한 네트워크 분할, API 서버 액세스 보안 등이 있습니다.
Kubernetes RBAC 에서 '최소 권한'의 원칙을 설명해주세요.
답변:
최소 권한은 사용자 및 서비스 계정에 작업 수행에 필요한 최소한의 권한만 부여하는 것을 의미합니다. 이는 계정이 손상될 경우 잠재적인 영향을 최소화하여 클러스터 내 공격 표면을 줄입니다.
네트워크 정책은 Kubernetes 클러스터에서 보안을 어떻게 강화하나요?
답변:
네트워크 정책은 Pod 가 서로 및 외부 엔드포인트와 어떻게 통신할 수 있는지 정의합니다. 이는 Pod 수준에서 방화벽 역할을 하여 네트워크 분할을 가능하게 하고 민감한 워크로드를 격리하여 무단 통신을 방지합니다.
Kubernetes 배포를 위한 CI/CD 파이프라인에서 이미지 스캔의 중요성은 무엇인가요?
답변:
이미지 스캔은 배포 전에 컨테이너 이미지 내의 알려진 취약점 (CVE) 및 잘못된 구성을 식별합니다. 이를 CI/CD에 통합하면 보안 및 규정을 준수하는 이미지만 레지스트리로 푸시되고 클러스터에 배포되어 취약한 소프트웨어가 실행되는 것을 방지할 수 있습니다.
Kubernetes 에서 비밀을 안전하게 관리하는 일반적인 방법은 무엇인가요?
답변:
Kubernetes Secrets 는 기본 스토리지를 제공하지만, 기본적으로 base64 로 인코딩되며 저장 시 암호화되지 않습니다. 모범 사례에는 HashiCorp Vault, AWS Secrets Manager 또는 Azure Key Vault 와 같은 외부 비밀 관리 솔루션을 사용하고, 종종 CSI 드라이버 또는 외부 비밀 연산자를 통해 통합하여 민감한 데이터를 암호화하고 관리하는 것이 포함됩니다.
Pod 보안 표준 (PSS) 이란 무엇이며 왜 중요한가요?
답변:
Pod 보안 표준은 Pod 에 대한 다양한 수준의 격리 (Privileged, Baseline, Restricted) 를 정의하는 내장 보안 제어입니다. 루트 액세스 또는 호스트 경로 마운트와 같이 과도하게 허용적인 설정으로 Pod 가 실행되는 것을 방지하여 보안 모범 사례를 시행하는 데 도움이 됩니다.
Kubernetes 클러스터 내에서 권한 상승 공격을 어떻게 방지할 수 있나요?
답변:
권한 상승 방지는 여러 조치를 포함합니다. Pod 보안 표준 시행, 불변 컨테이너 사용, 호스트 액세스 제한, 엄격한 RBAC 구현, 클러스터 구성 및 사용자 활동의 정기적인 감사 등이 있습니다. 기능 제한 및 권한 있는 컨테이너 비활성화가 중요합니다.
서비스 메시 (예: Istio, Linkerd) 는 Kubernetes 보안에서 어떤 역할을 하나요?
답변:
서비스 메시는 서비스 간 암호화된 통신을 위한 mTLS(상호 TLS), 세분화된 액세스 제어 정책 및 트래픽 암호화와 같은 기능을 제공하여 보안을 강화합니다. 마이크로서비스 통신을 위한 보안 구성 및 관찰 가능성을 중앙 집중화합니다.
Kubernetes 에서 '불변 인프라'의 개념을 설명해주세요.
답변:
불변 인프라는 구성 요소 (컨테이너 이미지 또는 배포된 애플리케이션과 같은) 가 빌드 및 배포된 후에는 절대 수정되지 않음을 의미합니다. 모든 변경 사항에는 새 이미지를 빌드하고 이전 인스턴스를 교체해야 하며, 이는 구성 드리프트를 줄여 일관성, 안정성 및 보안을 향상시킵니다.
리소스 할당량 및 제한 범위는 클러스터 안정성 및 보안에 어떻게 기여하나요?
답변:
리소스 할당량은 네임스페이스에서 소비할 수 있는 CPU, 메모리 및 기타 리소스의 총량을 제한하여 리소스 고갈을 방지합니다. 제한 범위는 네임스페이스 내의 Pod 에 대한 기본 및 최대 리소스 요청/제한을 정의하여 애플리케이션이 과도한 리소스를 소비하지 않도록 하고 클러스터 안정성 및 공정성을 개선합니다.
실용적이고 실제적인 Kubernetes 도전 과제
계속해서 충돌하는 Pod 가 있습니다. 이 문제를 어떻게 해결하시겠습니까?
답변:
먼저 kubectl describe pod <pod-name>을 사용하여 이벤트와 상태를 확인하겠습니다. 그런 다음 kubectl logs <pod-name>을 사용하여 애플리케이션 로그를 검토하겠습니다. 충돌 루프인 경우 kubectl logs --previous <pod-name>을 사용하여 마지막으로 종료된 컨테이너의 로그를 확인하겠습니다.
Deployment 가 보류 상태에 머물러 있습니다. 일반적인 이유는 무엇이며 어떻게 진단하시겠습니까?
답변:
일반적인 이유로는 리소스 부족 (CPU/메모리), 노드 테인트/허용 오차 또는 노드 셀렉터/친화도 문제가 있습니다. kubectl describe pod <pod-name>을 사용하여 스케줄링 이벤트를 확인하고 kubectl get events --field-selector involvedObject.kind=Node을 사용하여 노드 조건을 확인하겠습니다.
Deployment 에서 실행 중인 상태 비저장 애플리케이션을 외부 트래픽에 노출하려면 어떻게 해야 하나요?
답변:
Deployment 를 노출하기 위해 LoadBalancer 또는 NodePort 유형의 Service 를 생성하겠습니다. 더 고급 라우팅 및 SSL 종료를 위해서는 Ingress Controller 가 필요한 Ingress 리소스를 사용하겠습니다.
다운타임 없이 Deployment 의 롤링 업데이트를 수행해야 합니다. Kubernetes 는 이를 어떻게 처리하며 주요 고려 사항은 무엇인가요?
답변:
Kubernetes Deployment 는 기본적으로 롤링 업데이트를 처리하며, maxUnavailable 및 maxSurge 설정을 기반으로 이전 Pod 를 종료하기 전에 새 Pod 를 생성합니다. 주요 고려 사항으로는 적절한 준비 상태 프로브, 충분한 리소스 할당 및 전체 롤아웃 전에 새 버전 테스트가 있습니다.
ConfigMap 과 Secret 을 사용하는 시나리오를 설명해주세요.
답변:
애플리케이션 환경 변수 또는 구성 파일과 같은 비민감 구성 데이터에는 ConfigMap 을 사용하겠습니다. API 키, 데이터베이스 자격 증명 또는 TLS 인증서와 같이 기본적으로 암호화되어 저장되는 민감한 데이터에는 Secret 을 사용하겠습니다.
특정 하드웨어 (예: GPU) 가 있는 노드에서만 Pod 가 실행되도록 하려면 어떻게 해야 하나요?
답변:
Node Selectors 또는 Node Affinity 를 사용하겠습니다. Node Selectors 는 정확한 일치 (nodeSelector: {gpu: 'true'}) 에 더 간단합니다. Node Affinity 는 requiredDuringSchedulingIgnoredDuringExecution 또는 preferredDuringSchedulingIgnoredDuringExecution 규칙으로 더 많은 유연성을 제공합니다.
Service 가 Pod 로 트래픽을 라우팅하지 않습니다. 이 문제를 디버깅하기 위해 어떤 단계를 취하시겠습니까?
답변:
먼저 kubectl describe service <service-name>을 사용하여 셀렉터가 Pod 레이블과 일치하는지 확인하겠습니다. 그런 다음 kubectl get endpoints <service-name>을 사용하여 Pod IP 가 나열되어 있는지 확인하겠습니다. 마지막으로 Pod 가 정상인지, 그리고 준비 상태 프로브가 통과하는지 확인하겠습니다.
클러스터 내에서 데이터베이스 마이그레이션과 같은 일회성 작업을 실행해야 합니다. 어떤 Kubernetes 리소스를 사용하시겠습니까?
답변:
Kubernetes Job 리소스를 사용하겠습니다. Job 은 하나 이상의 Pod 를 생성하고 지정된 수의 Pod 가 성공적으로 종료되도록 보장합니다. 예약된 작업의 경우 CronJob 을 사용하겠습니다.
PersistentVolume(PV) 및 PersistentVolumeClaim(PVC) 의 목적을 설명해주세요.
답변:
PersistentVolume(PV) 은 관리자가 프로비저닝한 클러스터 내의 스토리지 조각입니다. PersistentVolumeClaim(PVC) 은 사용자가 스토리지에 대한 요청입니다. PVC 는 적합한 PV 에 바인딩되어 Pod 가 수명 주기와 독립적으로 내구성 있는 스토리지에 액세스할 수 있도록 합니다.
Deployment 를 수동으로 및 자동으로 확장하려면 어떻게 해야 하나요?
답변:
수동으로는 kubectl scale deployment <deployment-name> --replicas=<number>를 사용하겠습니다. 자동으로 는 Horizontal Pod Autoscaler(HPA) 를 사용하여 CPU 사용량 또는 기타 사용자 정의 메트릭을 기반으로 Deployment 또는 ReplicaSet 의 Pod 수를 확장하겠습니다.
요약
Kubernetes 인터뷰를 진행하는 것은 어렵지만 보람 있는 경험이 될 수 있습니다. 이 문서는 여러분이 뛰어난 성과를 내는 데 필요한 지식과 자신감을 갖추도록 설계된 일반적인 질문과 통찰력 있는 답변에 대한 포괄적인 개요를 제공했습니다. 철저한 준비가 가장 중요하다는 것을 기억하십시오. 핵심 개념, 실제 적용 및 문제 해결 시나리오를 이해하면 성능이 크게 향상될 것입니다.
인터뷰를 넘어 Kubernetes 와 함께하는 여정은 지속적인 학습과 적응의 과정입니다. 환경은 빠르게 발전하며, 호기심을 유지하고, 새로운 기능을 실험하고, 커뮤니티에 참여하면 기술이 날카롭고 관련성을 유지할 수 있습니다. 도전을 받아들이고, 성공을 축하하며, 이 역동적이고 필수적인 기술에서 전문성을 계속 구축하십시오.
