쿠버네티스 환경 구축 및 주요 구성

1. 환경 구축

쿠버네티스를 실습할 때 직접 install 하지 않고 온라인 테스트 환경에서 진행해보려고 한다.

https://labs.play-with-k8s.com/

Play with Kubernetes

 

(나는 도커 로그인으로 진행했다.)

로그인하면 다음과 같은 초기 화면이 나오는데 여기서는 4시간 동안 세션이 유지된다.

kubernetes 실습 초기 화면

여기서 + ADD NEW INSTANCE를 클릭하면 다음과 같이 새로운 노드가 생성된 걸 확인할 수 있다.

노드 생성 완료

 

2. 쿠버네티스 아키텍처

쿠버네티스 개념

쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장 및 운영을 자동화하기 위한 오픈 소스 시스템이다. 구글에 의해 개발되었으며, CNCF(Cloud Native Computing Foundation)에 기여했다.

쿠버네티스 주요 특징

• 자동화된 롤아웃 및 롤백: 애플리케이션 업데이트 시 롤아웃을 자동으로 관리하고 문제 발생 시 이전 버전으로 자동으로 롤백
• 서비스 발견 및 로드 밸런싱: 서비스를 사용하여 클러스터 내의 애플리케이션에 쉽게 접근하고, 트래픽을 자동으로 분산
• 스케일링: 애플리케이션의 리소스 사용에 따라 자동 또는 수동으로 스케일링
• 자체 치유: 실패한 컨테이너를 재시작하고, 건강하지 않은 컨테이너를 교체하며, 준비되지 않은 노드로부터 애플리케이션을 이전

위 특징은 정확히 말하자면 쿠버네티스만의 특징은 아니고 오케스트레이션을 해주는 이런 툴들은 이런 게 가능해야 이런 툴을 쓰는 의미가 있다.

쿠버네티스 아키텍처

Master-Node 구조로 이루어진 클러스터를 사용한다.
아래 사진을 보면 각 Node가 있고 이 노드들을 관리하는 Control Plane이 있다. 여기서 오케스트레이터 한다. 이 사진 전체는 쿠버네티스 클러스터 하나라고 보면 된다.

쿠버네티스 클러스터 구조

 

마스터 컴포넌트

• API 서버 (kube-apiserver): 쿠버네티스 API를 제공하며, 사용자와 내부 컴포넌트 간의 중재자 역할
• 스케줄러 (kube-scheduler): 새로 생성된 파드를 어떤 노드에 할당할지 결정.
  • 예) 파드들을 관리하는 조금 더 큰 그룹에 넣어서 로드밸런싱
• 컨트롤러 매니저 (kube-controller-manager): 여러 컨트롤러를 실행. 예를 들어, 노드 컨트롤러, 레플리케이션 컨트롤러를 실행한다.
• etcd: 모든 클러스터 데이터를 저장하는 경량의 분산 키-값 저장소

이런 컴포넌트들이 오케스트레이션을 잘할 수 있도록 구조를 잘 잡아주고 있다.

(MLOps를 공부하는 입장에서 쿠버네티스는 주로 스케줄러를 위주로 다루게 된다. 파드는 하나의 컨테이너라고 생각하면 된다. 이따 hello world 찍는 컨테이너 하나가 파드 하나라고 생각하면 된다. 엄밀히 말하면 파드 안에 여러 컨테이너가 있을 수 있는데 일단은~)

 

노드 컴포넌트

• kubelet: 각 노드에서 실행되며, 파드 스펙(Spec)에 설명된 대로 컨테이너가 실행되고 있는지 확인
• kube-proxy: 각 노드의 네트워크 규칙을 관리하여 네트워크 통신을 가능
• 컨테이너 런타임: 컨테이너 실행을 담당하는 소프트웨어 (예: Docker, containerd, CRI-O 등).

 

3. 쿠버네티스 주요 구성 요소

쿠버네티스 작동 방식

쿠버네티스는 다음과 같은과정을 거쳐 클러스터를 구성하게 된다.

• 클러스터 구성: 먼저 쿠버네티스 클러스터를 구성. 이 클러스터는 여러 노드(물리적 또는 가상 머신)와 이들을 관리하는 마스터 노드로 구성
• API 서버와의 통신: 사용자는 kubectl 명령줄 인터페이스나 API를 통해 API 서버와 통신. 이를 통해 파드 생성, 업데이트, 삭제 등의 작업을 요청 (여기서 파드는 컨테이너 하나/여러 개를 의미)
• 스케줄링과 실행: 스케줄러는 새로운 파드에 대해 가장 적합한 노드를 선택. kubelet은 해당 노드에서 파드의 컨테이너가 올바르게 실행되도록 관리
• 서비스 관리: kube proxy는 서비스를 통한 네트워크 트래픽을 관리. 서비스는 파드 그룹에 안정적인 접근점을 제공
• 자동화된 롤아웃 및 롤백: 디플로이먼트를 통해 애플리케이션의 업데이트, 롤아웃 및 롤백을 자동으로 관리
• 스케일링과 자체 치유: 클러스터는 애플리케이션의 수요에 따라 자동으로 스케일링하고, 실패한 파드를 재시작하는 등의 자체 치유 기능을 제공

Pod

Pod는 쿠버네티스에서 배포할 수 있는 가장 작은 작업 단위를 말한다. 하나 이상의 컨테이너를 포함할 수 있고 이들은 스토리지와 네트워크를 공유한다.

 

주요 특징은 다음과 같다.

• 컨테이너 그룹핑: 파드는 하나 이상의 밀접하게 관련된 컨테이너를 그룹화하며, 이 컨테이너들은 같은 컴퓨팅 리소스를 공유
• 공유 리소스: 파드 내의 컨테이너는 같은 IP 주소와 포트 공간을 공유하고, 서로 localhost를 통해 통신
• 일시적인 성격: 파드는 일시적인 성격을 띤다. 즉, 파드가 삭제되면 그 안의 컨테이너도 함께 삭제. 이는 파드가 불변적이지 않고 변경 가능한 리소스로 간주됨을 의미
• 생명주기: 파드는 생성되고, 실행되며, 종료될 때까지의 생명주기를 가진다. 파드가 종료되면, 쿠버네티스 클러스터에서 제거

Service

서비스는 파드의 집합에 대한 안정적인 네트워크 주소를 제공한다. 서비스를 통해 파드 집합에 대한 접근을 관리하고, 로드 밸런싱 및 서비스 발견이 가능하다.

 

주요 특징은 다음과 같다.

• 안정적인 주소 제공: 서비스는 파드 집합에 지속적으로 접근할 수 있는 안정적인 IP 주소와 포트를 제공
• 로드 밸런싱: 서비스는 요청을 여러 파드에 분산시켜 로드 밸런싱을 수행
• 서비스 발견: DNS 또는 환경 변수를 통해 클러스터 내의 다른 파드가 서비스를 쉽게 찾을 수 있음
• 서비스 타입: 다양한 서비스 타입(ClusterIP, NodePort, LoadBalancer, ExternalName)을 통해 다양한 네트워크 요구 사항을 충족

Deployment

디플로이먼트는 쿠버네티스에서 파드와 레플리카셋의 상태를 선언적으로 관리하는 API 오브젝트다. 애플리케이션의 배포, 업데이트, 스케일링 등을 자동화하고 관리한다.

 

예를 들어:

1. 특정 파드가 있다고 가정하자. 이 파드를 5개로 늘리고 싶다면 단순히 파드를 개별적으로 5개 만드는 대신 레플리카셋(ReplicaSet)을 통해 관리하도록 요청할 수 있다.
2. 디플로이먼트를 이용하면 “이 파드의 레플리카가 항상 5개가 있어야 한다”는 상태를 선언적으로 정의한다.
3. 만약 실행 중인 5개의 파드 중 하나가 오류로 인해 중단된다면 디플로이먼트는 자동으로 새로운 파드를 생성해 5개의 상태를 유지한다.

즉, “항상 원하는 상태를 유지하도록 관리하는 방식”이 선언적 관리고, 디플로이먼트는 이를 구현하는 주요 도구이다.

 

주요 특징은 다음과 같다.

• 자동화된 롤아웃과 롤백: 디플로이먼트는 애플리케이션의 새 버전을 롤아웃하고, 필요한 경우 이전 버전으로 롤백하는 프로세스를 자동화
• 상태 관리: 원하는 상태(Desired State)를 정의하고, 쿠버네티스가 실제 상태(Current State)를 그 상태로 유지
• 선언적 업데이트: YAML 파일이나 JSON 형식을 사용하여 애플리케이션을 업데이트하는 방식을 선언
• 스케일링: 파드의 수를 수동 또는 자동으로 조절하여 애플리케이션을 스케일링

사용 예시

• 새 버전 배포: 디플로이먼트를 사용하여 애플리케이션의 새 버전을 롤아웃
• 스케일링: kubectlscale deployment명령어를 사용하여 디플로이먼트를 확장하거나 축소

ReplicaSet

레플리카셋은 파드의 복제본을 유지 관리하는 쿠버네티스 오브젝트다. 파드의 원하는 복제본 수를 지정하고, 지정된 수의 파드 복제본이 항상 실행되고 있도록 보장한다.

주요 특징은 다음과 같다.

• 복제본 수 관리: 지정된 수의 파드 복제본을 유지
• 자체 치유: 실패한 파드를 자동으로 대체하여 복제본 수를 유지
• 유연한 파드 선택: 레이블 선택기(Label Selector)를 사용하여 관리할 파드를 결정

 

4. 쿠버네티스 실습

아까 만든 인스턴스창을 보면 경고가 떠있다.

경고 로그

여기서 우리가 쿠버네티스를 잘 실습하려면 이 클러스터를 부트스트랩 해줘야 한다. 그 명령어로는 첫 번째 명령어, 두 번째 명령어를 실행해 주면 된다.

 

이러면 환경 구축은 완료됐고, 파드 실습을 진행해 보자.

Pod 실습

Pod는 한 개 이상의 컨테이너를 실행해 주는 거라고 했는데 여기서 nginx 웹서버를 실행해 보자.

kubectl run fastcampusserver --image=nginx:latest --port 80

pod 생성 완료

 

이렇게 생성해 주면 된다.

pod 상태를 확인하는 명령어는 다음과 같다.

kubectl get pods

pods 목록

조금 오래 걸리기 때문에 아직 Pending인걸 볼 수 있다.

조금 더 자세히 보고 싶으면 describe를 사용하면 된다.

kubectl describe pod

pod 상세 정보

이 파드는 쿠버네티스 오케스트레이션이 컨테이너를 관리해야 하는데 관리하는 가장 최소의 단위를 파드라고 이해하면 된다. 왜 그럼 직접적으로 도커 컨테이너를 관리 안 하느냐? 파드 안에 있는 컨테이너가 도커 기반 컨테이너가 아니라 기술 기반 컨테이너일 수도 있기 때문에 확장성 때문에 파드라는 계층을 뒀다.라고 이해하면 좋을 것 같다.

 

(그리고 pod생성하는데 이게 실습 환경이 지금 인터넷 기반이라 100분이 넘어가도록 계속 Pending이 길레 일단 실행 테스트는 못해봤다. 만약에 생성 완료 테스트를 진행하고 싶으면 아래 명령어로 인터넷 접속을 해보면 된다!)

curl [IP Address]:80

 

Deployment 실습

Deployment는 파드랑 레플리카셋을 써서 관리해 주는 것이다.

Deployment를 생성하는 명령어는 다음과 같다. (여기서 replica를 2개로 만들어보는 실습이다.)

kubectl create deployment fastcampusdeployment --image=nginx --replicas=2

deployment 생성

생성 확인 명령어는 다음과 같다.

kubectl get deployments.apps

deployment 생성 확인

위 그림에서 확인할 거는 위 디플로이가 파드 두 개를 관리하고 있다.로 이해하면 된다.

kubectl get pods

파드 목록

 

이렇게 파드를 확인해 보면 아까는 1개였는데 지금은 3개로 늘어난 걸 확인할 수 있다.

이제 디플로이를 수정해 보자.

kubectl edit deployments.apps fastcampusdeployment

이렇게 치면 수정할 수 있는 에디터창이 보인다.

deployment 상세 설정

replicas를 5로 수정해 보자.

replicas를 5로 수정

이렇게 수정해 주고 저장하고 나오면 성공한 로그가 나온다.

deployment 수정 완료

그리고 파드를 확인해 보면 더 생긴 걸 확인할 수 있다.

파드 목록

 

AGE가 5분 남짓한 건 이전에 만들어진 2개고 나머지 3개는 방금 수정으로 인해 생성된 것 들이다.

 

만약에 이렇게 실행하다가 하나의 파드에서 에러가 나서 멈춘다면 deployment의 레플리카셋이 알아서 자동으로 하나 더 생성해 줘서 아까 위에서 선언한 5개를 자동으로 맞춰준다.