Containar

쿠버네티스 기초 다지기: 동작 원리, kubectl 사용법

hwlee9905 2024. 6. 1. 19:22

쿠버네티스 아키텍처

 

 

쿠버네티스 클러스터는 worker machines들의 집합으로 구성되고, worker machine들을 node라고 부른다.

 

노드는 컨테이너화된 앱을 실행할 수 있으며 클러스터는 적어도 하나의 node가 포함되어 구성되고, node가 호스팅하고 있는 컨테이너화 된 앱을 pod라고 하며, pods와 nodes들을 contorl plane이 관리하게 된다.

 

 

  • 클러스터 (Cluster): 쿠버네티스 클러스터는 하나의 마스터 노드와 다수의 워커 노드로 구성된 컨테이너화된 애플리케이션을 실행하는 집합체이다.
  • 노드 (Node): 클러스터의 일부로, 실제 애플리케이션 워크로드가 실행되는 물리적 또는 가상 머신이다.
  • 마스터 (Master): 클러스터 전체를 제어하고 관리하는 노드이다. 스케줄링, 클러스터 이벤트 모니터링 등의 역할을 한다.
  • 파드 (Pod): 쿠버네티스 애플리케이션의 기본 실행 단위로, 하나 이상의 컨테이너로 구성된다.
  • 컨트롤 플레인(Control Plane):  클러스터 전체를 관리하고 제어하는 핵심 컴포넌트들의 집합이다.

 

컨트롤 플레인의 구성요소

kube-apiserver

 

Kubernetes 컨트롤 플레인의 구성 요소로서 Kubernetes API를 노출한다. 컨트롤 플레인 컴포넌트들은 kube-apiserver, etcd, kube-scheduler, kube-controller-manager 등이 있는데, 이 중에서 kube-apiserver는 유일하게 클러스터 외부와 통신할 수 있는 컴포넌트이다.

 

 

etcd

 

Kubernetes의 모든 클러스터 데이터를 위한 백업 스토어로 사용되는 일관되고 고가용성의 키-값 저장소이다. 

 

kube-scheduler

 

할당된 노드가 없는 새로 생성된 파드를 감시하고, 해당 파드가 실행될 노드를 선택하는 컨트롤 플레인 구성 요소이다. 

 

kube-controller-manager

 

컨트롤러 프로세스를 실행하는 컨트롤 플레인 구성 요소이다.

 

cloud-controller-manager

 

클라우드별 제어 로직을 포함하는 Kubernetes 컨트롤 플레인 구성 요소이다. cloud-controller-manager는 클러스터를 클라우드 제공자의 API에 연결하고 클라우드 플랫폼과 상호 작용하는 구성 요소를 클러스터와 상호 작용하는 구성 요소와 분리하는데,. cloud-controller-manager는 특정 클라우드 제공자에 특화된 컨트롤러만 실행한다.

 

상황을 예시로 들어 컨트롤 플레인 컴포넌트들의 역할을 설명하자면,

  1. 사용자가 "nginx pod 3개 run 해줘" 명령을 내린다. -> 선언적 API
  2. kube-scheduler가 etcd에 저장되어 있는 클러스터 데이터를 통해 어떤 node에 어떤 pod를 배치할지 선택한다.
  3. kube-scheduler 의 내용을 kube-apiserver가 실행한다.
  4. 실행되고 있는 pod중에 특정 pod가 다운되어 사용자가 입력한 선언적 api(여기선 pod 3개 run 해줘라는 명령) 상태를 만족하지 못하게되었다.
  5. 이를 kube-controller-manager가 감지하고 kube-scheduler한테 전달하여 pod 1개를 더 실행하도록 한다.
  6. 이 모든 과정이 etcd에 저장된다.

kubectl 사용법

kubectl create

# nginx 컨테이너 1개로 구성된 pod 생성
kubectl create -f nginx.yaml

# deployment 생성 (nginx 컨테이너 3개로 구성된 레플리카셋 관리)
kubectl create deployment nginx-app --image=nginx --replicas=3

 

kubectl describe

# nginx pod에 대한 상세 정보 조회
kubectl describe pod nginx

# nginx-app deployment에 대한 상세 정보 조회
kubectl describe deployment nginx-app

 

kubectl delete

# nginx pod 삭제
kubectl delete pod nginx

# nginx-app deployment 삭제 (연관된 레플리카셋, 파드도 함께 삭제됨)
kubectl delete deployment nginx-app
 
 

kubectl get

# 현재 namespace의 모든 pod 조회
kubectl get pods

# 모든 namespace의 모든 service 조회
kubectl get services --all-namespaces

# node 리소스와 상세 정보 조회
kubectl get nodes -o wide

 

Q.run과 create는 뭐가 다른지?

 

run과 create 명령어는 모두 쿠버네티스 리소스를 생성하는 데 사용되지만, 약간의 차이점이 있다.

 

run

  • 주로 간단한 작업을 위해 일회성으로 파드나 디플로이먼트를 생성할 때 사용한다.
  • 복잡한 설정이 필요 없는 경우에 유용하다.
  • 예: kubectl run nginx --image=nginx

create

  • 모든 유형의 리소스를 생성할 수 있는 보다 일반적인 명령이다.
  • YAML/JSON 파일로 리소스 스펙을 정의해야 한다.
  • 복잡한 설정이 필요한 리소스를 생성할 때 유용하다
  • 예: kubectl create -f nginx.yaml

즉, run 명령어는 간단한 파드나 디플로이먼트를 신속하게 생성하는 데 편리하지만, create 명령어는 보다 유연하고 세부적인 설정이 가능하다.

 

run 명령어로 생성된 리소스도 기본적으로 YAML/JSON 포맷으로 정의되지만, 옵션이 제한적인 반면, create로 직접 YAML/JSON 파일을 지정하면 리소스에 대한 보다 세부적인 커스터마이징이 가능하다.

 

프로덕션 환경에서는 대부분 YAML/JSON 파일로 리소스를 정의하고 create 명령어를 사용하는 것이 일반적이지만 개발/테스트 환경에서는 run 명령어로 간단하게 리소스를 생성하기도 한다.

curl 명령으로 직접 pod안에 들어가 볼 수 도 있다!