[CKA 준비] 섹션 2: Core Concepts Labs 진행 간 Q&A

1. 명령어 옵션이 기억 안 날 때: --help의 마법

Q: --replicas 같은 옵션명이 정확히 기억 안 나거나 replicaset으로 착각하면 어쩌죠?

A: 당황하지 말고 명령어 뒤에 --help를 붙이세요. 예를 들어 kubectl create deployment --help를 치면 하단에 [--replicas=count]와 같이 정확한 옵션 명칭과 사용법이 나옵니다. CKA 시험장에서 공식 문서를 찾는 것보다 훨씬 빠릅니다.

2. Port vs TargetPort: "누가 진짜 정답인가?"

Q: k get service 결과에 443 포트가 보이는데, targetPort를 묻는 문제에서 왜 443이 오답인가요?

A: get service 결과의 포트는 서비스 자체의 입구(Port)일 뿐입니다. targetPort는 트래픽이 최종적으로 도달할 Pod 내부의 실제 포트를 의미합니다.

• 확인 방법: k describe svc [이름] 명령어를 통해 TargetPort 항목을 직접 확인해야 합니다. 보통 API 서버의 서비스 포트는 443이지만, 실제 targetPort는 6443인 경우가 많습니다.

3. 접속 불가(Connection Error) 해결의 첫걸음

Q: Deployment는 잘 떠 있는데 웹 UI나 curl 접속이 안 됩니다. 원인이 뭘까요?

A: 중간 다리인 Service가 없거나 잘못 설정되었기 때문입니다.

• 진단: k get svc로 서비스 존재 여부를 확인하고, k get ep(Endpoints)로 서비스가 Pod들의 IP를 잘 잡고 있는지 확인하세요. 만약 서비스는 있는데 Endpoints가 <none>이라면, 서비스의 selector가 Pod의 label과 일치하지 않는 것입니다.

4. 서비스 포트 3형제 완벽 이해 (NodePort, Port, TargetPort)

Q: 이 세 가지 포트가 너무 헷갈립니다. 한 번에 정리해 주세요.

A: 트래픽이 들어오는 순서대로 '관문'이라고 생각하면 쉽습니다.

1. NodePort (30000-32767): 외부 사용자가 노드 IP를 통해 들어오는 아파트 단지 정문.
2. Port: 서비스 객체가 클러스터 내부에서 사용하는 동 현관문.
3. TargetPort: 트래픽이 최종 도달하는 실제 Pod 내부의 집 문.

5. kubectl expose vs create service

Q: 서비스를 만들 때 어떤 명령어가 더 유리한가요?

A: 이미 존재하는 Pod나 Deployment를 서비스로 노출할 때는 kubectl expose가 훨씬 유리합니다. Pod가 가진 라벨 정보를 자동으로 가져와서 selector를 알아서 설정해 주기 때문입니다. 반면 create service는 라벨 등을 수동으로 맞춰야 할 확률이 높습니다.

6. 네임스페이스(Namespace) 지정의 중요성

Q: 분명 Pod를 만들었는데 k get pods에 안 보입니다.

왜 그럴까요? A: 특정 네임스페이스(finance 등)에 만들라는 문제에서 -n 옵션을 빼먹었기 때문입니다. 지정하지 않으면 무조건 default 네임스페이스에 생성됩니다.

• 해결: k get pods -A (전체 조회)로 내가 어디에 만들었는지 확인하고, 다시 -n [이름]을 붙여 생성하세요.

7. 모든 네임스페이스 리소스 한꺼번에 보기

Q: 내가 클러스터 전체에 어떤 리소스를 만들었는지 한눈에 보고 싶다면?

A: -A 또는 --all-namespaces 옵션을 사용하세요. k get pods -A는 시험 중에 내 실수를 잡아내는 가장 강력한 무기입니다.

8. DNS를 통한 네임스페이스 간 통신

Q: 다른 네임스페이스에 있는 서비스에 접속하려면 주소를 어떻게 써야 하나요?

A: 서비스 이름만으로는 안 됩니다. [서비스이름].[네임스페이스] 형식을 써야 합니다.

• 예시: marketing 네임스페이스의 redis-db에 접속하려면 주소창에 redis-db.marketing이라고 입력해야 DNS가 해석할 수 있습니다.

9. 쿠버네티스 전체 주소(FQDN) 구조

Q: 서비스의 가장 길고 정확한 전체 주소 형식은 무엇인가요?

A: [서비스명].[네임스페이스].svc.cluster.local 입니다.

• 이유: svc는 리소스 타입(Service)을, cluster.local은 클러스터 기본 도메인을 의미합니다.

10. curl 결과: "Empty reply from server"는 성공인가?

Q: 터미널에서 curl을 날렸는데 아무 내용도 안 나오고 저 메시지만 뜨면 실패인가요?

A: 성공입니다! 네트워크 연결은 이미 된 것입니다. 다만 접속한 대상이 HTTP 웹 서버가 아니라 Redis 같은 다른 프로토콜을 사용하는 서비스라 curl(HTTP 도구)이 응답 내용을 해석하지 못했을 뿐입니다. 즉, "연결은 잘 됐다"는 신호입니다.

11. HPA(Horizontal Pod Autoscaler)의 작동 조건

Q: Pod를 자동으로 늘려주는 HPA가 작동하지 않습니다. 체크할 점은?

A: 두 가지가 필수입니다.

1. 클러스터에 사용량을 수집하는 Metrics Server가 떠 있어야 합니다.
2. 대상 Pod 설계도에 resources.requests (최소 요구 사양)가 정의되어 있어야 HPA가 "현재 몇 %를 쓰고 있다"는 것을 계산할 수 있습니다.

12. 클러스터 범위 자원(Cluster-scoped) 구분하기

Q: 모든 리소스가 네임스페이스 안에 사나요? A: 아닙니다.

Nodes, Namespaces, PersistentVolumes 등은 특정 네임스페이스에 속하지 않는 전역 자원입니다. 아파트 단지로 치면 각 가구(네임스페이스)가 아니라 단지 전체가 공유하는 '땅'이나 '건물 외벽'과 같습니다. 이 정보를 모른다고 하더라도 kubectl api-resources 명령어로 확인할 수 있습니다. 예를들어, kubectl api-resources --namespaced=false 하면 namespace가 필수가 아닌 리소스가 나열됩니다.

13. YAML 설계도 읽는 법: kubectl explain

Q: YAML을 짤 때 containers 필드가 어디 밑에 들어가는지 헷갈리면?

A: k explain pod.spec.containers를 입력하세요. 마치 사전처럼 해당 경로의 필드들이 무엇인지, 어떤 타입(String, Array 등)인지 상세히 설명해 줍니다.

 

14. YAML 작성 시 '하이픈(-)'을 붙일지 말지 헷갈릴 때, 가장 정확한 확인법은?

A: kubectl explain 명령어로 리소스의 데이터 타입을 확인하는 것입니다.

단순히 리소스의 설명을 보는 수준을 넘어, 상세 경로를 찍어보면 YAML 문법 에러를 원천 봉쇄할 수 있습니다.

• 실전 예시: kubectl explain pod.spec.containers
• 확인 포인트: 출력 결과의 KIND 필드를 확인하세요.
  • []Object (리스트 형태): 이름 앞에 하이픈(-)이 반드시 필요합니다. (예: containers는 여러 개가 올 수 있는 배열이므로 - name: my-app처럼 작성)
  • Object (단일 객체): 하이픈 없이 바로 필드명을 적습니다. (예: spec은 하나뿐이므로 하이픈 없이 작성)
•