소개
이 랩에서는 Minikube 를 사용하여 로컬 Kubernetes 클러스터를 탐색합니다. 클러스터를 시작하고, 설정을 확인하며, 파드 (pod) 및 배포 (deployment) 와 같은 기본적인 클러스터 리소스를 검사합니다. 이 실습 경험은 Kubernetes 환경의 기본적인 구성 요소와 명령을 이해하는 데 도움이 되며, 추가 탐색 및 개발을 위한 기반을 마련합니다.
먼저 로컬 머신에 Minikube 클러스터를 설정하여 클러스터가 실행 중이고 사용할 준비가 되었는지 확인합니다. 그런 다음, kubectl cluster-info 및 kubectl get nodes와 같은 필수 kubectl 명령을 사용하여 클러스터의 구성 및 상태를 확인합니다. 마지막으로, Kubernetes 객체 모델과 클러스터의 전반적인 상태에 익숙해지기 위해 파드 및 배포를 포함한 기본적인 클러스터 리소스를 검사합니다.
로컬 Kubernetes 클러스터 시작
이 단계에서는 학습 및 개발을 위해 단일 노드 Kubernetes 환경을 설정하는 간단한 방법을 제공하는 Minikube 를 사용하여 로컬 Kubernetes 클러스터를 시작하고 확인합니다.
먼저 프로젝트 디렉토리로 이동합니다.
cd ~/project
Minikube 클러스터를 시작합니다.
참고: 무료 사용자는 인터넷에 연결할 수 없으므로 랩을 시작할 때 minikube 가 이미 미리 시작되어 있습니다. 클러스터 상태를 확인하려면 아래 코드 섹션으로 이동할 수 있습니다. 직접 클러스터를 시작하는 연습을 하려면 Pro 로 업그레이드하세요.
Pro 사용자 전용
minikube start
예시 출력:
😄 minikube v1.29.0 on Ubuntu 22.04
✨ Automatically selected the docker driver
📌 Using Docker driver with root permissions
🔥 Creating kubernetes in kubernetes cluster
🔄 Restarting existing kubernetes cluster
🐳 Preparing Kubernetes v1.26.1 on Docker 20.10.23 ...
🚀 Launching Kubernetes ...
🌟 Enabling addons: storage-provisioner, default-storageclass
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace
여러 명령을 사용하여 클러스터 상태를 확인합니다.
minikube status
예시 출력:
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
클러스터 노드를 확인합니다.
kubectl get nodes
예시 출력:
NAME STATUS ROLES AGE VERSION
minikube Ready control-plane 1m v1.26.1
이러한 명령은 다음을 확인합니다.
- Minikube 가 성공적으로 시작되었습니다.
- 로컬 Kubernetes 클러스터가 실행 중입니다.
- 클러스터가 사용할 준비가 되었습니다.
- 제어 평면 (control plane) 기능을 갖춘 단일 노드 클러스터가 있습니다.
Minikube 클러스터는 로컬 머신에 완전한 Kubernetes 환경을 제공하므로 전체 다중 노드 클러스터 없이도 애플리케이션을 개발하고 테스트할 수 있습니다.
Kubernetes 아키텍처 개요
Kubernetes 는 클라이언트 - 서버 모델로 작동하며, 중앙 집중식 제어 평면 (Control Plane) 이 클러스터의 상태를 관리하고, 일련의 작업자 노드 (worker Node) 가 워크로드를 실행합니다. 일반적으로 사용자 (대개 개발자) 는 명령줄 도구 또는 API 를 통해 Kubernetes 클러스터와 상호 작용합니다. 제어 평면은 무엇을 어디에서 실행할지 결정하고, 클러스터의 상태를 모니터링하며, 원하는 상태가 달성되도록 보장합니다. 작업자 노드는 파드 (Pod)—하나 이상의 컨테이너 그룹—에서 애플리케이션을 호스팅하고, 애플리케이션을 실행하는 데 필요한 컴퓨팅 및 스토리지 리소스를 제공합니다.
제어 평면 (Control Plane)
이것은 클러스터의 "두뇌"이며, 전체 시스템을 관리하기 위해 함께 작동하는 여러 구성 요소로 구성됩니다.
- kube-apiserver (API): 클러스터의 정문 역할을 합니다. 모든 관리 명령 및 리소스 요청은 이를 통과합니다.
- etcd (Key Value Store): 모든 구성 데이터와 클러스터의 현재 상태를 저장합니다. etcd 데이터를 잃으면 클러스터의 상태를 잃게 됩니다.
- kube-scheduler (SCH): 리소스 요구 사항, 제약 조건 및 정책을 기반으로 파드를 노드에 할당합니다.
- kube-controller-manager (CTLM): 클러스터의 상태를 지속적으로 조정하여 배포 및 구성에 의해 정의된 원하는 상태와 실제 상태가 일치하도록 보장하는 다양한 컨트롤러를 실행합니다.
노드 (작업 머신)
노드는 워크로드가 실행되는 곳입니다. 각 노드에는 다음이 있습니다.
- kubelet (KLT): 제어 평면과 통신하는 노드 수준 에이전트입니다. 파드가 실행 중인지 확인하고 상태를 제어 평면에 다시 보고합니다.
- Container Runtime (CR): 컨테이너를 실행하고 관리하는 소프트웨어 (예: Docker 또는 containerd). 파드 내에서 컨테이너화된 애플리케이션을 생성하고 관리합니다.
파드 (Pods)
파드는 Kubernetes 에서 배포 가능한 가장 작은 단위로, 일반적으로 실행 중인 애플리케이션의 단일 인스턴스를 나타냅니다. 파드는 동일한 네트워크 네임스페이스와 스토리지 볼륨을 공유하는 하나 이상의 컨테이너를 포함할 수 있습니다.
서비스 (Services)
서비스는 파드의 논리적 집합과 이에 접근하는 방법에 대한 정책을 정의하는 추상화입니다. 서비스는 안정적인 IP 주소, DNS 이름 및 로드 밸런싱을 제공하여 외부 소비자 및 기타 클러스터 구성 요소가 파드가 노드 간에 이동하거나 스케일링 또는 롤링 업데이트 중에 교체되더라도 애플리케이션에 안정적으로 연결할 수 있도록 보장합니다.
클러스터와 상호 작용
- 개발자 및 관리자는
kubectl또는 기타 Kubernetes 클라이언트를 사용하여 kube-apiserver와 상호 작용합니다. - 새 애플리케이션이 배포되면 제어 평면 구성 요소 (스케줄러, 컨트롤러) 가 파드를 적절한 노드에 배치하기 위해 작동합니다.
- 각 노드의 kubelet 은 파드가 정상적으로 실행되고 있는지 확인합니다.
- 서비스는 트래픽을 올바른 파드로 라우팅하여 클라이언트가 파드 위치 변경을 추적하지 않고도 애플리케이션에 액세스할 수 있도록 합니다.
flowchart TB
%% User interacting with the cluster
User((Developer))
User -->|kubectl CLI| API[kube-apiserver]
%% Control Plane Components
subgraph ControlPlane[Control Plane]
API
ETCD[etcd - Key Value Store]
SCH[kube-scheduler]
CTLM[kube-controller-manager]
API --> ETCD
API --> SCH
API --> CTLM
end
%% Worker Node 1
subgraph Node1[Worker Node]
KLT1[kubelet]
CR1[Container Runtime]
subgraph Pods1[Pods]
P1[Pod]
P2[Pod]
end
KLT1 --> CR1
CR1 --> P1
CR1 --> P2
end
%% Worker Node 2
subgraph Node2[Worker Node]
KLT2[kubelet]
CR2[Container Runtime]
subgraph Pods2[Pods]
P3[Pod]
P4[Pod]
end
KLT2 --> CR2
CR2 --> P3
CR2 --> P4
end
%% Connections between Control Plane and Nodes
API --> KLT1
API --> KLT2
%% Service connecting to Pods across different Nodes
Service[Service]
Service --> P1
Service --> P2
Service --> P3
Service --> P4
다이어그램에서:
- 개발자는
kubectl과 같은 CLI 도구를 통해kube-apiserver(API) 와 상호 작용합니다. - 제어 평면 구성 요소 (API, etcd, Scheduler, Controller Manager) 는 클러스터 상태를 관리하고 워크로드를 오케스트레이션합니다.
- 각 작업자 노드는 kubelet 과 컨테이너 런타임을 실행하여 여러 파드를 호스팅합니다.
- 서비스는 외부 또는 내부 트래픽을 올바른 파드로 라우팅하여 파드 수명 주기 및 IP 변경의 복잡성을 추상화하는 안정적인 엔드포인트를 제공합니다.
이 정신적 모델은 클러스터의 상태를 검사하고, 노드 상태를 확인하고, 파드를 나열하고, 서비스를 쿼리할 때 무엇을 보고 있는지 이해하는 데 도움이 됩니다. 이는 kubectl 명령을 사용하여 Kubernetes 를 계속 탐색하면서 적용할 개념입니다.
클러스터 설정 확인
이 단계에서는 필수 kubectl 명령을 사용하여 Kubernetes 클러스터의 구성 및 상태를 확인하는 방법을 배웁니다. 이러한 명령은 클러스터의 현재 상태와 연결성을 이해하는 데 도움이 됩니다.
먼저 클러스터 정보를 확인합니다.
kubectl cluster-info
예시 출력:
Kubernetes control plane is running at https://192.168.49.2:8443
CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'
이 명령은 Kubernetes 제어 평면 및 CoreDNS 와 같은 핵심 서비스에 대한 세부 정보를 제공합니다.
다음으로, 클러스터 노드에 대한 자세한 보기를 가져옵니다.
kubectl get nodes -o wide
예시 출력:
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION
minikube Ready control-plane 15m v1.26.1 192.168.49.2 <none> Ubuntu 22.04 LTS 5.15.0-72-generic
노드 세부 정보를 보다 포괄적으로 살펴보겠습니다.
kubectl describe node minikube
예시 출력 (부분):
Name: minikube
Roles: control-plane
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
kubernetes.io/hostname=minikube
kubernetes.io/os=linux
minikube.k8s.io/commit=86a3b7e45a9a35cdcf8f4c80a4c6a46d20dda00f
Annotations: node.alpha.kubernetes.io/ttl: 0
volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp: [Current Timestamp]
Capacity:
cpu: 2
ephemeral-storage: 17784212Ki
memory: 1947748Ki
pods: 110
Allocatable:
cpu: 2
ephemeral-storage: 16388876Ki
memory: 1845348Ki
pods: 110
이러한 명령의 주요 통찰력:
- 클러스터 제어 평면이 실행 중인지 확인
- 노드 상태 확인 (Ready/NotReady)
- 노드 리소스 및 구성 이해
- Kubernetes 버전 및 노드 세부 정보 확인
기본 클러스터 리소스 검사
이 단계에서는 모든 네임스페이스에서 Pod, Deployment, Service 와 같은 기본 Kubernetes 리소스를 검사합니다. -A (또는 --all-namespaces) 플래그를 사용하면 전체 클러스터에서 리소스가 어떻게 구성되어 있는지 확인할 수 있습니다. 이는 Kubernetes 에서 **네임스페이스 (Namespaces)**의 개념을 소개하고 이해하는 훌륭한 기회입니다.
네임스페이스: 리소스 격리
네임스페이스는 Kubernetes 클러스터 내의 논리적 파티션으로, 리소스를 구성하고 관리하는 데 도움이 됩니다. 관련 객체를 그룹화하고 세분화된 수준에서 정책, 액세스 제어 및 리소스 할당량을 적용하는 방법을 제공합니다. 리소스를 서로 다른 네임스페이스로 분리하면 다음과 같은 이점을 얻을 수 있습니다.
- 조직 개선: 관련 워크로드 (예: 프로젝트, 팀 또는 환경별—dev, test, production 등) 를 그룹화합니다.
- 보안 및 액세스 제어 강화: 특정 네임스페이스의 리소스를 보고 수정할 수 있는 사용자 또는 서비스 계정을 제한합니다.
- 리소스 관리 단순화: 리소스 제한, 네트워크 정책 및 기타 클러스터 전체 구성을 보다 효과적으로 적용합니다.
-A (또는 --all-namespaces) 플래그로 리소스를 나열하면 Kubernetes 시스템에 속하는 구성 요소가 클러스터 수준 인프라에 전념하는 kube-system 네임스페이스에 있음을 알 수 있습니다. 사용자가 생성한 애플리케이션은 일반적으로 default 네임스페이스 또는 사용자가 정의한 다른 사용자 지정 네임스페이스에 있습니다.
네임스페이스 및 리소스
flowchart LR
%% User interacts with the cluster via kube-apiserver
User((Developer))
User -->|kubectl get pods -A| API[kube-apiserver]
%% Control Plane Subgraph
subgraph ControlPlane[Control Plane]
API
ETCD[etcd]
SCH[kube-scheduler]
CTLM[kube-controller-manager]
end
API --> ETCD
API --> SCH
API --> CTLM
%% kube-system namespace
subgraph kube-system[Namespace: kube-system]
SysDeployment[Deployment: coredns]
SysPod1[Pod: coredns-xxx]
SysService[Service: kube-dns]
SysDeployment --> SysPod1
SysService --> SysPod1
end
%% default namespace (renamed to avoid parse issues)
subgraph defaultNs[Namespace: default]
DefDeployment[Deployment: my-app]
DefPod1[Pod: my-app-pod1]
DefPod2[Pod: my-app-pod2]
DefService[Service: my-app-service]
DefDeployment --> DefPod1
DefDeployment --> DefPod2
DefService --> DefPod1
DefService --> DefPod2
end
%% dev namespace
subgraph dev[Namespace: dev]
DevDeployment[Deployment: dev-app]
DevPod[Pod: dev-app-pod]
DevService[Service: dev-app-service]
DevDeployment --> DevPod
DevService --> DevPod
end
%% Demonstration of communication
API --> kube-system
API --> defaultNs
API --> dev
다이어그램에서:
- **제어 평면 (Control Plane)**은 전체 클러스터를 관리하며, 노드와 통신하고 워크로드를 제어합니다.
- 네임스페이스 (Namespaces) (예:
kube-system,default,dev) 는 클러스터 내에서 리소스를 논리적으로 분리합니다.kube-system은 CoreDNS 및 kube-dns 와 같은 시스템 수준 구성 요소를 보유합니다.default는 일반적으로 일반 워크로드에 사용되며, 여기서는my-app배포로 표시됩니다.dev는 프로덕션 워크로드와 격리된 개발 환경을 나타낼 수 있습니다.
모든 네임스페이스에서 리소스를 보면 이러한 논리적 파티션이 구성되고 안전한 클러스터를 유지하는 데 어떻게 도움이 되는지 포괄적으로 이해할 수 있습니다.
예시:
모든 네임스페이스에서 모든 파드를 나열합니다.
kubectl get pods -A
예시 출력:
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-787d4945fb-j8rhx 1/1 Running 0 20m
kube-system etcd-minikube 1/1 Running 0 20m
kube-system kube-apiserver-minikube 1/1 Running 0 20m
kube-system kube-controller-manager-minikube 1/1 Running 0 20m
kube-system kube-proxy-xb9rz 1/1 Running 0 20m
kube-system kube-scheduler-minikube 1/1 Running 0 20m
kube-system storage-provisioner 1/1 Running 1 (20m ago) 20m
여기에서 kube-system 네임스페이스에서 실행 중인 모든 시스템 관련 파드를 볼 수 있습니다. 다른 네임스페이스에 다른 배포 또는 서비스가 있는 경우, 해당 네임스페이스별로 명확하게 범위가 지정되어 이 목록에도 표시됩니다.
모든 네임스페이스에서 모든 배포를 나열합니다.
kubectl get deployments -A
예시 출력:
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
kube-system coredns 1/1 1 1 20m
coredns 배포는 kube-system 네임스페이스에 있습니다.
모든 네임스페이스에서 모든 리소스에 대한 포괄적인 보기를 가져옵니다.
kubectl get all -A
이 명령은 서로 다른 네임스페이스에서 파드, 서비스 및 배포에 대한 개요를 표시하여 이러한 리소스가 클러스터 전체에 어떻게 분산되어 있는지 이해하는 데 도움이 됩니다.
주요 내용:
- **네임스페이스 (Namespaces)**는 Kubernetes 클러스터 내에서 논리적 격리 및 구성을 제공합니다.
- 서로 다른 Kubernetes 구성 요소 및 리소스는 특정 네임스페이스로 구성됩니다 (예: 핵심 서비스의 경우
kube-system, 일반 워크로드의 경우default, 사용자가 생성하는 추가 네임스페이스). -A를 사용하여 모든 네임스페이스에서 리소스를 보면 클러스터가 어떻게 구성되어 있는지, 그리고 네임스페이스가 리소스 구성 및 액세스 제어의 경계 역할을 하는지 알 수 있습니다.
네임스페이스가 논리적 환경으로 어떻게 작동하는지 이해하면 배포를 확장하고 Kubernetes 환경에 더 많은 복잡성을 도입할 때 특히 워크로드 및 관련 클러스터 리소스를 더 잘 탐색, 격리 및 관리할 수 있습니다.
요약
이 랩에서는 학습 및 개발을 위해 단일 노드 Kubernetes 환경을 설정하는 간단한 방법을 제공하는 Minikube 를 사용하여 로컬 Kubernetes 클러스터를 시작하고 확인했습니다. Minikube 클러스터가 성공적으로 시작되었고, 로컬 Kubernetes 클러스터가 실행 중이며, 클러스터를 사용할 준비가 되었고, 제어 평면 기능을 갖춘 단일 노드 클러스터가 있음을 확인했습니다. 또한 kubectl cluster-info 및 kubectl get nodes와 같은 필수 kubectl 명령을 사용하여 Kubernetes 클러스터의 구성 및 상태를 확인하는 방법을 배웠으며, 이를 통해 클러스터의 현재 상태와 연결성을 이해하는 데 도움이 되었습니다.


