소개
kubectl은 CKAD 스타일의 쿠버네티스 작업 전반에서 사용할 명령줄 도구입니다. 파드 (Pod), 디플로이먼트 (Deployment), 서비스 (Service) 또는 구성 객체를 생성하기 전에, kubectl이 어떤 클러스터와 통신하고 있으며 기본적으로 어떤 네임스페이스를 대상으로 명령을 수행하는지 파악해야 합니다.
이번 실습에서는 활성화된 쿠버네티스 컨텍스트를 확인하고, 네임스페이스 목록을 조회하며, 실습용 네임스페이스를 현재 네임스페이스로 설정해 봅니다. 또한, 간단한 ConfigMap 을 생성하여 네임스페이스가 지정된 객체들이 어떻게 격리되는지 확인합니다. 실습의 확인 과정은 정확한 명령 출력 형식보다는 생성한 쿠버네티스의 핵심 상태에 중점을 둡니다.
kubectl 접근 확인
이 단계에서는 kubectl이 준비된 쿠버네티스 클러스터에 접근할 수 있는지 확인하고, 현재 명령에서 사용 중인 컨텍스트를 식별합니다.
먼저 /home/labex/project에서 시작합니다. mkdir -p 명령은 디렉토리가 없으면 생성하고, 이미 존재하면 아무런 작업도 수행하지 않습니다. 이 과정에서는 학습자의 작업물을 해당 디렉토리에 유지하여 이후 실습에서도 매니페스트와 보조 파일을 일관된 위치에서 생성할 수 있도록 합니다.
mkdir -p /home/labex/project
cd /home/labex/project
쿠버네티스 컨텍스트는 kubeconfig 에 저장된 연결 설정입니다. 이는 kubectl에 어떤 클러스터, 사용자 자격 증명, 기본 네임스페이스를 사용할지 알려줍니다. 객체를 변경하는 명령을 실행하기 전에 활성 컨텍스트를 확인하십시오.
kubectl config current-context
준비된 LabEx 쿠버네티스 프로필 이름이 표시되어야 합니다:
labex-v135
예측 가능한 시작점을 위해 현재 컨텍스트의 네임스페이스를 default로 설정합니다. 여기서는 객체를 생성하는 것이 아니라, 이후 네임스페이스 관련 명령에서 --namespace 옵션을 생략할 경우 kubectl이 어떤 네임스페이스를 사용할지 지정하는 것입니다.
kubectl config set-context --current --namespace=default
현재 컨텍스트가 업데이트되었음을 알리는 출력이 나타납니다:
Context "labex-v135" modified.
VM 이 시작된 직후에는 쿠버네티스 프로필이 준비되기까지 잠시 시간이 걸릴 수 있습니다. 먼저 클러스터 노드 목록을 확인하십시오. 만약 API 서버가 아직 준비되지 않았다는 메시지가 나오면, 몇 초 기다린 후 노드가 Ready 상태가 될 때까지 동일한 명령을 다시 실행하십시오.
kubectl get nodes --request-timeout=5s
예상 출력에는 준비된 노드와 쿠버네티스 버전이 포함됩니다:
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
이제 API 서버에 기본적인 클러스터 정보를 요청합니다. 이는 터미널이 단순히 kubectl 바이너리를 찾는 것뿐만 아니라, 실제로 실행 중인 클러스터에 인증되었음을 증명합니다.
kubectl cluster-info
출력에는 쿠버네티스 컨트롤 플레인 엔드포인트가 언급되어야 합니다:
Kubernetes control plane is running at ...
...
네임스페이스 읽기
이 단계에서는 쿠버네티스 네임스페이스를 검사하고 현재 컨텍스트가 기본적으로 어떤 네임스페이스를 사용하는지 확인합니다.
네임스페이스는 동일한 클러스터 내에서 네임스페이스가 지정된 쿠버네티스 객체를 별도의 범위로 나누는 방법입니다. 파드, 디플로이먼트, 서비스, 시크릿 (Secret), ConfigMap 과 같은 많은 애플리케이션 리소스는 정확히 하나의 네임스페이스 내에 존재합니다.
클러스터에 이미 존재하는 네임스페이스 목록을 확인합니다:
kubectl get namespaces
kube-system과 같은 시스템 네임스페이스와 일반적인 애플리케이션 네임스페이스인 default가 표시되어야 합니다:
NAME STATUS AGE
default Active ...
kube-system Active ...
...
컨텍스트에는 기본 네임스페이스를 저장할 수도 있습니다. --namespace 옵션 없이 네임스페이스 관련 명령을 실행하면 kubectl은 해당 기본 네임스페이스를 사용합니다. --minify 옵션은 활성 컨텍스트만 보여주며, jsonpath 표현식은 네임스페이스 필드만 출력합니다.
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
이전 단계에서 컨텍스트 네임스페이스를 설정했으므로, 결과는 default로 출력됩니다:
default
단일 명령에 대해서는 --namespace를 사용하여 현재 네임스페이스를 항상 재정의할 수 있습니다. 예를 들어, 컨텍스트를 변경하지 않고 쿠버네티스 시스템 네임스페이스의 파드를 확인하려면 다음과 같이 합니다:
kubectl get pods --namespace kube-system
정확한 파드 이름은 다를 수 있지만, 명령은 CoreDNS, 네트워킹 또는 스토리지 구성 요소와 같은 시스템 파드를 반환해야 합니다:
NAME READY STATUS RESTARTS AGE
... ... ... ... ...
실습용 네임스페이스 선택
이 단계에서는 이번 실습을 위한 네임스페이스를 생성하고, 이후 명령을 위한 기본 네임스페이스로 설정합니다.
ckad-prep-contexts라는 이름의 네임스페이스를 생성합니다. 네임스페이스 이름은 객체 식별자의 일부입니다. 즉, 한 네임스페이스의 app-settings라는 ConfigMap 은 다른 네임스페이스의 같은 이름의 ConfigMap 과는 서로 다른 객체입니다.
kubectl create namespace ckad-prep-contexts
생성 명령은 새로운 네임스페이스가 만들어졌음을 확인해 줍니다:
namespace/ckad-prep-contexts created
이제 --namespace 옵션이 없는 명령이 ckad-prep-contexts를 대상으로 하도록 현재 컨텍스트를 업데이트합니다. --current 옵션은 컨텍스트 이름을 수동으로 지정하는 대신 "현재 사용 중인 컨텍스트를 수정"하라는 의미입니다.
kubectl config set-context --current --namespace=ckad-prep-contexts
출력은 컨텍스트가 수정되었음을 확인해 줍니다:
Context "labex-v135" modified.
활성 컨텍스트에 저장된 네임스페이스를 다시 확인합니다:
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
이제 다음과 같이 출력되어야 합니다:
ckad-prep-contexts
--namespace 옵션 없이 간단한 파드 목록을 조회합니다. 현재 네임스페이스가 ckad-prep-contexts로 설정되어 있으므로, 이 명령은 실습용 네임스페이스 내부를 조회합니다. 네임스페이스가 비어 있는 것은 정상입니다.
kubectl get pods
예상 출력:
No resources found in ckad-prep-contexts namespace.
네임스페이스 범위 관찰
이 단계에서는 작은 ConfigMap 을 생성하고, 이를 사용하여 현재 네임스페이스가 객체 조회에 어떤 영향을 미치는지 관찰합니다.
ConfigMap 은 애플리케이션을 위한 민감하지 않은 구성 데이터를 저장합니다. 가볍고 생성이 빠르며 네임스페이스가 지정되므로, 실제 애플리케이션을 배포하기 전에 네임스페이스 동작을 연습하는 데 유용합니다.
--namespace 옵션을 전달하지 않고 app-settings라는 이름의 ConfigMap 을 생성합니다. 이전 단계에서 ckad-prep-contexts를 선택했으므로, 쿠버네티스는 해당 네임스페이스에 객체를 생성합니다.
kubectl create configmap app-settings --from-literal=mode=prep
명령 결과는 다음과 같아야 합니다:
configmap/app-settings created
네임스페이스 플래그 없이 ConfigMap 목록을 조회합니다. 이는 현재 컨텍스트의 네임스페이스를 사용합니다.
kubectl get configmap app-settings
예상 출력:
NAME DATA AGE
app-settings 1 ...
이제 명시적인 네임스페이스를 지정하여 동일한 객체를 요청합니다. ckad-prep-contexts에 생성했으므로 동일한 ConfigMap 이 반환되어야 합니다.
kubectl get configmap app-settings --namespace ckad-prep-contexts
마지막으로 default 네임스페이스를 확인합니다. --ignore-not-found 옵션을 사용하면 객체가 존재하지 않을 때 kubectl이 성공적으로 종료되고 아무것도 출력하지 않습니다. 이는 실습에서 객체가 없는 것이 예상된 결과일 때 유용합니다.
kubectl get configmap app-settings --namespace default --ignore-not-found
출력이 없다는 것은 ConfigMap 이 default 네임스페이스에 생성되지 않았음을 의미합니다. 이제 현재 컨텍스트에서 네임스페이스를 설정하는 것이 어떤 실질적인 효과를 주는지 확인했습니다.
요약
kubectl이 준비된 쿠버네티스 클러스터에 접근할 수 있음을 확인하고, 활성 컨텍스트를 식별하며, 기존 네임스페이스를 검사하고, 현재 컨텍스트의 네임스페이스를 변경한 뒤 ConfigMap 을 생성하여 네임스페이스 범위를 관찰했습니다. 이러한 기초 지식은 이후 CKAD 준비 실습의 토대가 되며, 애플리케이션 객체를 생성할 때 각 객체가 정확히 어디에 생성되고 조회되는지 파악하는 데 필수적입니다.
