클러스터를 손으로 열어보기

목표

진짜 쿠버네티스 클러스터에 붙어 네임스페이스·노드·API 리소스를 직접 조회하고, 라벨 셀렉터와
-o jsonpath 로 원하는 값만 뽑아낸 뒤, 같은 디플로이먼트를 명령형과 선언형 두 방식으로 만들어
차이를 눈으로 확인합니다.

왜 중요한가

쿠버네티스를 쓰는 사람은 크게 둘로 갈립니다. 매번 문서 사이트를 검색하는 사람과, **클러스터에게
직접 물어보는 사람**입니다. kubectl api-resources 와 kubectl explain 은 이 클러스터가 지금
실제로 아는 것을 알려 주므로 문서보다 정확합니다. CRD 로 확장된 리소스까지 나오니까요.

그리고 라벨 셀렉터. 쿠버네티스에는 오브젝트끼리의 직접 참조가 거의 없습니다. Service 가 파드를 찾는
방법도, ReplicaSet 이 자기 파드를 세는 방법도 전부 라벨 셀렉터입니다. 이 느슨한 연결 덕분에 파드를
마음대로 갈아치울 수 있지만, 대가로 셀렉터 오타는 오류 없이 조용히 아무것도 못 찾습니다.

마지막으로 선언형. kubectl run 은 편하지만 무엇을 만들었는지 기록이 남지 않습니다. 매니페스트를
파일로 두고 apply 하면 그 파일이 곧 이 클러스터의 진실이 되고, 리뷰·버전 관리·롤백이 가능해집니다.
GitOps 라는 말은 이 습관을 조직 규모로 키운 것에 지나지 않습니다.

단계

1. 네임스페이스 kcna-arch 를 만들고 라벨 tier=lab 을 붙입니다.
2. 클러스터의 모든 노드 이름을 한 줄에 하나씩 /root/kcna-arch/nodes.txt 에 저장합니다. 이름만 담고 node/ 같은 접두어는 넣지 않습니다.
3. kubectl api-resources 를 보고 deployments 의 APIVERSION 값을 /root/kcna-arch/deploy-apiversion.txt 에, services 의 축약형(SHORTNAMES)을 /root/kcna-arch/svc-short.txt 에 각각 한 줄로 저장합니다.
4. kubectl explain 으로 파드를 스케줄러 없이 특정 노드에 직접 배치하는 spec 필드를 찾고, 그 필드를 써서 네임스페이스 kcna-arch 에 이미지 nginx:1.27-alpine 인 파드 pinned 를 만듭니다. 노드 이름은 2단계 목록에 있는 것 중 하나여야 합니다.
5. /root/kcna-arch/components.txt 에 아래 네 줄을 그대로 채워 넣습니다 — serve-rest-api=, store-cluster-state=, watch-and-place-pods=, reconcile-desired-state= 뒤에 각각 알맞은 컴포넌트 이름(kube-apiserver, etcd, kube-scheduler, kube-controller-manager)을 붙입니다. 그리고 kubectl get --raw 로 API 서버의 /healthz 를 호출해 그 응답을 /root/kcna-arch/healthz.txt 에 저장합니다.
6. 네임스페이스 kcna-arch 에 파드 3개를 만듭니다 — web-1(app=web,tier=front), web-2(app=web,tier=back), db-1(app=db,tier=back). 그다음 셀렉터 app=web,tier=back 으로 고른 파드 이름을 /root/kcna-arch/selected.txt 에 한 줄에 하나씩 저장합니다.
7. kubectl create deployment 에 --dry-run=client -o yaml 을 붙여 이름 kcna-web, 이미지 nginx:1.27-alpine, replicas 2 인 디플로이먼트 매니페스트를 /root/kcna-arch/kcna-web.yaml 로 저장한 뒤, 그 파일을 네임스페이스 kcna-arch 에 선언형으로 반영합니다.

참고

• kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' 처럼 range 로 반복하면 한 줄에 하나씩 뽑을 수 있습니다.
• kubectl explain pod.spec --recursive 는 필드 트리를 통째로 보여 줍니다. 이름을 모를 때 grep 과 같이 쓰면 빠릅니다.
• 흔한 실수 1: 3단계에서 deployments.apps 처럼 리소스 이름을 적는 것. 필요한 것은 APIVERSION 열의 값입니다.
• 흔한 실수 2: 7단계에서 kubectl create deployment 로 클러스터에 바로 만들어 버리는 것. 그러면 매니페스트 파일은 있어도 오브젝트에는 선언형 반영의 흔적이 남지 않아 채점을 통과하지 못합니다.

단계 7개

1. 작업용 네임스페이스 만들기
2. 노드 목록을 파일로 뽑기
3. api-resources 로 API 그룹과 축약형 찾기
4. explain 으로 필드를 찾아 파드를 노드에 고정하기
5. 컴포넌트 역할 정리하고 API 서버 상태 받아오기
6. 라벨 붙이고 셀렉터로 골라내기
7. 명령형으로 만든 YAML 을 선언형으로 반영하기