KCNA — Kubernetes and Cloud Native Associate

Opening a Cluster by Hand

한국어 원문으로 표시합니다.

목표

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

왜 중요한가

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

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

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

단계

네임스페이스 kcna-arch 를 만들고 라벨 tier=lab 을 붙입니다.
클러스터의 모든 노드 이름을 한 줄에 하나씩 /root/kcna-arch/nodes.txt 에 저장합니다. 이름만 담고 node/ 같은 접두어는 넣지 않습니다.
kubectl api-resources 를 보고 deployments 의 APIVERSION 값을 /root/kcna-arch/deploy-apiversion.txt 에, services 의 축약형(SHORTNAMES)을 /root/kcna-arch/svc-short.txt 에 각각 한 줄로 저장합니다.
kubectl explain 으로 파드를 스케줄러 없이 특정 노드에 직접 배치하는 spec 필드를 찾고, 그 필드를 써서 네임스페이스 kcna-arch 에 이미지 nginx:1.27-alpine 인 파드 pinned 를 만듭니다. 노드 이름은 2단계 목록에 있는 것 중 하나여야 합니다.
/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 에 저장합니다.
네임스페이스 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 에 한 줄에 하나씩 저장합니다.
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 로 클러스터에 바로 만들어 버리는 것. 그러면 매니페스트 파일은 있어도 오브젝트에는 선언형 반영의 흔적이 남지 않아 채점을 통과하지 못합니다.

작업용 네임스페이스 만들기

네임스페이스 kcna-arch 를 만들고 라벨 tier=lab 을 붙입니다.

네임스페이스는 클러스터 안의 이름 공간입니다. 만들 때 라벨을 함께 주거나, 만든 뒤 kubectl label 로 붙일 수 있습니다. 라벨 키는 tier, 값은 lab 입니다.

노드 목록을 파일로 뽑기

클러스터의 모든 노드 이름을 한 줄에 하나씩 /root/kcna-arch/nodes.txt 에 저장합니다. 이름만 담고 node/ 같은 접두어는 넣지 않습니다.

kubectl get nodes 의 기본 출력에는 헤더와 여러 열이 섞여 있습니다. 이름만 한 줄에 하나씩 필요하니 -o 로 출력 형식을 바꾸는 편이 깔끔합니다. -o name 을 쓰면 node/ 접두어가 붙는다는 점도 확인해 보세요.

api-resources 로 API 그룹과 축약형 찾기

kubectl api-resources 를 보고 deployments 의 APIVERSION 값을 /root/kcna-arch/deploy-apiversion.txt 에, services 의 축약형(SHORTNAMES)을 /root/kcna-arch/svc-short.txt 에 각각 한 줄로 저장합니다.

kubectl api-resources 는 이 클러스터가 아는 모든 리소스를 NAME/SHORTNAMES/APIVERSION/NAMESPACED/KIND 열로 보여 줍니다. 검색은 grep 으로 좁히면 됩니다. APIVERSION 은 '그룹/버전' 형태이고, 코어 그룹은 그룹 이름이 비어 있다는 점에 주의하세요.

explain 으로 필드를 찾아 파드를 노드에 고정하기

kubectl explain 으로 파드를 스케줄러 없이 특정 노드에 직접 배치하는 spec 필드를 찾고, 그 필드를 써서 네임스페이스 kcna-arch 에 이미지 nginx:1.27-alpine 인 파드 pinned 를 만듭니다. 노드 이름은 2단계 목록에 있는 것 중 하나여야 합니다.

kubectl explain pod.spec 를 실행하면 spec 아래 필드 설명이 쭉 나옵니다. 스케줄러를 건너뛰고 특정 노드에 직접 배치하는 필드가 그 안에 있습니다. 노드 이름은 2단계에서 뽑은 목록 중 아무거나 쓰면 됩니다.

컴포넌트 역할 정리하고 API 서버 상태 받아오기

/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 에 저장합니다.

앞의 읽을거리에서 다룬 네 컴포넌트의 역할을 key=value 한 줄씩 적습니다. 그리고 kubectl 은 --raw 옵션으로 API 서버의 임의 경로를 그대로 호출할 수 있습니다. 헬스 엔드포인트의 응답은 아주 짧습니다.

라벨 붙이고 셀렉터로 골라내기

네임스페이스 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 에 한 줄에 하나씩 저장합니다.

파드 3개에 서로 다른 라벨 조합을 붙입니다. 그다음 kubectl get 의 -l 옵션에 조건을 콤마로 이어 쓰면 AND 로 동작합니다. 결과를 파일로 남길 때는 이름만 나오게 출력 형식을 지정하세요.

명령형으로 만든 YAML 을 선언형으로 반영하기

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 create 에 --dry-run=client -o yaml 을 붙이면 클러스터를 건드리지 않고 매니페스트만 뽑아낼 수 있습니다. 그 파일을 apply 로 반영하면 create 로 만들었을 때는 없던 주석이 오브젝트에 하나 생깁니다. 채점은 그 주석의 유무로 두 방식을 구분합니다.