[Kubernetes] 쿠버네티스와 Pod, Service, Deployment 알아보기

카테고리 없음

[Kubernetes] 쿠버네티스와 Pod, Service, Deployment 알아보기

혀내 2023. 5. 13. 23:38

쿠버네티스란?

여러 컨테이너 클러스터를 쉽게 다룰 수 있도록 도와주는 오케스트레이션 플랫폼

사실 도커 컨테이너를 관리할 수 있는 오케스트레이션 플랫폼은 여러 가지가 있습니다.

그러나 그 중에서도 쿠버네티스가 급부상한 이유는 다음과 같은 이점을 갖고 있기 때문입니다.

1. Load balancing(부하 분산)

들어오는 트래픽을 여러 가상 머신 인스턴스로 분산시켜주는 컴퓨터 네트워크 기법을 제공합니다.

특징

애플리케이션을 확장할 수 있습니다.
더 높은 트래픽을 지원합니다.
비정상적인 인스턴스를 감지해 자동으로 삭제합니다.
트래픽을 가장 가까운 가상 머신으로 라우팅합니다.

2. Node pools

클러스터 내에서 구성이 모두 동일한 노드 그룹을 말합니다.

여기서 말하는 '노드'란 컨테이너화된 가상 서버를 말합니다.

노드에 대한 개념은 아래에서 더 자세히 다뤄보겠습니다.

Automatic scaling

들어오는 수요에 따라 지정된 노드 풀의 크기를 자동으로 조절합니다.

수요가 적다면 크기를 최소로 줄여 비용을 줄이고, 수요가 크다면 크기를 늘려 가용성을 높입니다.

Automatic upgrades

클러스터의 노드를 클러스터 제어 영역의 버전에 맞게 자동으로 업그레이드합니다.

Node auto-repair

일정 시간 동안 비정상적인 상태로 감지되는 노드를 정상 상태로 자동 복구합니다.

Logging and Monitoring

클러스터로 전송되는 로그와 측정 항목 등을 확인할 수 있습니다.

위에서 언급되는 클러스터가 대체 무엇인가요?

아래 링크의 글에서는 클러스터를 다음과 같이 정의하고 있습니다.

클러스터란 공통의 목표를 위해 작동하는 컴퓨터 또는 애플리케이션의 그룹

클라우드 용어로서 클러스터의 개념이 궁금하신 분들은 아래 사이트를 참고해주세요.

클러스터 (Cluster)

개념 클러스터(cluster)는 공통의 목표를 위해 작동하는 컴퓨터 또는 애플리케이션들의 그룹이다. 클라우드 네이티브 컴퓨팅의 관점에서, 이 용어는 쿠버네티스에 가장 일반적으로 적용된다. 쿠

glossary.cncf.io

쿠버네티스에서는 클러스터를 다음과 같이 상세히 정의합니다.

클러스터란 컨테이너를 통해 실행되는 서비스의 집합

도커에 관한 이전 게시글에서 도커 컨테이너는 실제 화물선의 컨테이너와 같다고 비유한 적이 있었습니다.

쿠버네티스의 클러스터는 여러 컨테이너를 실은 화물선으로 비유할 수 있습니다.

그렇다면 쿠버네티스는 바다 위에 떠다니는 화물선들을 통합 관리하는 관제센터라고 볼 수 있겠네요 ⚓

[Docker] 도커란? 도커의 기본 명령어 알아보기

왜 도커를 사용하나요? 스프링 애플리케이션의 서버 환경을 구축하기 위한 투두리스트 1. Ubuntu 설치하기 2. Java 11 설치하기 3. MySQL Database 설치하기 4. MySQL Schema 생성하기 5. 80 포트 열기 6. ... 위의

aeliketodo.tistory.com

쿠버네티스의 클러스터는 하나 이상의 클러스터 마스터와 워커 머신인 여러 개의 노드로 이루어져 있습니다.

Google Cloud 문서에 따르면 클러스터 마스터는 제어 영역(Control Plane)이라고 불리기도 합니다.

출처: https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-architecture?hl=ko

제어 영역(Control Plane, 클러스터 마스터)

제어 영역은 모든 클러스터 노드에서 실행되는 대상을 관리합니다.

제어 영역에서는 Kubernetes API 서버, 스케줄러, 코어 리소스 컨트롤러와 같은 프로세스를 실행합니다.

저희는 Kubernetes API를 호출해 제어 영역에게 원하는 클러스터의 상태를 알려줄 수 있습니다.

Kubernetes API를 직접 호출하는 방법: HTTP/gRPC
Kubernetes API를 간접 호출하는 방법: kubectl 명령어 사용하기

노드(Node)

노드는 컨테이너화된 애플리케이션과 기타 워크로드를 실행하는 작업자 머신

그럼 클러스터를 직접 생성해 볼까요?

Kubernetes Engine: Qwik Start | Google Cloud Skills Boost

Google Kubernetes Engine에서는 Google 인프라를 사용하여 컨테이너화된 애플리케이션을 배포, 관리 및 확장할 수 있는 관리형 환경을 제공합니다. 이 실무형 실습에서는 Kubernetes Engine으로 컨테이너화

www.cloudskillsboost.google

위의 퀵랩을 따라 클러스터 생성과 삭제 방법을 알아보겠습니다.

gcloud container clusters create

클러스터를 생성하는 명령어입니다.

gcloud container clusters create --machine-type=e2-medium --zone=assigned_at_lab_start lab-cluster

gcloud container clusters delete

클러스터를 삭제하는 명령어입니다.

gcloud container clusters delete lab-cluster

생성한 클러스터에 컨테이너화된 애플리케이션을 배포하기 위해서는 두 가지의 쿠버네티스 객체가 필요합니다.

배포에 필요한 첫 번째 객체는 Deployment

Deployment는 웹 서버처럼 무상태 애플리케이션을 배포하기 위해 사용하는 객체

Deployment로 pod 배포에 필요한 Replica Set을 생성하고, pod의 배포 작업을 세부적으로 조작할 수 있습니다.

생성 방법만 간단히 알아보고, Deployment의 자세한 개념은 게시글의 막바지에서 다시 훑어보겠습니다.

kubectl create deployment

Deployment 객체를 생성합니다.

--image 옵션: 배포할 컨테이너 이미지를 명시합니다.

kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0

잠깐, Pod에 대해 알아보고 갑시다.

Pod(파드)은 쿠버네티스에서 가장 핵심적인 역할을 수행하는 객체입니다.

Pod이란 하나 또는 여러 개의 컨테이너 집합을 나타내는 논리적인 애플리케이션

링크: https://www.cloudskillsboost.google/focuses/557?parent=catalog

Pod의 특징

서로 연관되어 있는 여러 컨테이너들을 묶어서 하나의 논리적인 애플리케이션, Pod로 표현할 수 있습니다.
Pod 내부에 있는 컨테이너들은 Pod의 데이터 디스크 볼륨을 공유합니다.
하나의 Pod는 하나의 IP 주소를 가지며, 내부의 컨테이너들은 IP 주소와 포트를 공유합니다.

kubectl create -f

pod를 생성하는 명령어입니다.

kubectl create -f pods/monolith.yaml

kubectl get pods

실행중인 컨테이너 pod 리스트를 확인합니다.

kubectl get pods

kubectl describe pods

pod의 IP 주소, 이벤트 로그 등 자세한 정보를 조회합니다.

kubectl describe pods monolith

kubectl port-forward

pod들은 private IP 주소를 가지기 때문에 클러스터 외부에서는 접근하지 못합니다.

외부에서 pod로 접근하고 싶다면 아래 명령어를 통해 로컬 포트와 pod의 포트를 포트 포워딩해야 합니다.

kubectl port-forward monolith 10080:80

kubectl logs

pod 내부의 로그를 확인할 수 있습니다.

-f 옵션: 실시간으로 로그를 확인합니다.

kubectl logs monolith

kubectl exec

pod 내부의 Bash 쉘에 접속합니다.

exit으로 쉘을 종료할 수 있습니다.

kubectl exec monolith --stdin --tty -c monolith -- /bin/sh

배포에 필요한 두 번째 객체는 Service

Service는 인터넷을 통해 Pod로 접근하기 위한 로드 밸런싱과 몇 가지 규칙을 정의하는 객체

위에서 알아본 Pod은 영속적이지 않기 때문에 Pod이 멈추고 재시작할 때마다 동적인 IP 주소를 가질 수 있습니다.

그래서 Service는 Pod가 영속적인 상태를 유지할 수 있도록 도와주는 역할을 수행합니다.

출처: https://www.cloudskillsboost.google/focuses/557?parent=catalog

Service의 특징

Pod에 라벨을 붙여 식별할 수 있습니다.
라벨을 통해 자동으로 Pod을 선정하고 서비스 외부로 노출시킬 수 있습니다.

서비스의 타입 3가지

서비스가 Pod를 외부에 노출시키는 방법은 총 3가지가 있습니다.

1. ClusterIP (internal)

Service는 오직 클러스터 내부의 다른 리소스들로부터만 접근이 가능합니다. (기본 타입)

2. NodePort

클러스터의 각 노드에게 외부에서 접근이 가능한 IP를 제공합니다.

서비스는 외부에서 특정 IP로 들어오는 요청을 감지해, 해당 파드로 트래픽을 전달합니다.

3. LoadBalancer

서비스로 들어온 트래픽을 각 노드에게 분산시키는 클라우드 제공자 측의 로드 밸런서를 추가합니다.

서비스 생성하기

서비스 객체를 생성하는 방법도 두 가지가 있습니다.

1. kubectl expose deployment 명령어 사용하기

Deployment의 Service 객체를 생성합니다.

--port 옵션: 서비스 객체를 노출할 포트 번호를 명시합니다.
--type 옵션: 생성할 서비스 객체의 타입을 명시합니다.

kubectl expose deployment hello-server --type=LoadBalancer --port 8080

위의 코드 예시에서는 서비스 객체 타입으로 로드 밸런서를 사용하고 있습니다.

deployment에 public IP 주소를 할당해 외부에서 해당 pod에 접근할 수 있도록 도와줍니다.

2. kubectl create로 직접 생성하기

kubectl create -f services/monolith.yaml

이 때, services/monolith.yaml 파일은 다음의 설정 코드를 가지고 있습니다.

kind: Service
apiVersion: v1
metadata:
  name: "monolith"
spec:
  selector:
    app: "monolith"
    secure: "enabled"
  ports:
    - protocol: "TCP"
      port: 443
      targetPort: 443
      nodePort: 31000
  type: NodePort

이렇게 직접 생성한 서비스 객체는 방화벽 규칙을 변경해 서비스를 노출할 포트를 열어줘야 합니다.

gcloud compute firewall-rules create allow-monolith-nodeport \
  --allow=tcp:31000

그 외의 서비스 명령어들도 한 번 알아볼까요?

kubectl get service

생성된 서비스 객체 리스트를 확인할 수 있습니다.

kubectl get service

kubectl describe services

서비스에 대한 상세 정보를 조회합니다.

kubectl describe services monolith
kubectl describe services monolith | grep Endpoints    # 서비스의 엔드포인트 리스트 조회하기

Pod에 라벨을 붙여봐요

이제 Pod에 라벨을 붙인 다음 라벨을 통해 Pod을 식별해보겠습니다.

kubectl label pods

pod에 라벨을 붙이고 싶을 때 사용하는 명령어입니다.

kubectl label pods secure-monolith 'secure=enabled'

kubectl get pods

-l 옵션: 라벨로 pod을 조회합니다.
--show-labels: 지정한 pod에 붙여진 라벨들을 조회합니다.

kubectl get pods -l "app=monolith,secure=enabled"
kubectl get pods secure-monolith --show-labels

마지막으로 Deployment를 다시 알아볼까요?

Deployment는 Replica Sets를 통해 실행 중인 Pod의 개수가 실행되길 원하는 Pod의 개수와 일치할 수 있도록 도와줍니다.

Replica Set이 뭐냐면요..

Pod은 영속적이지 않아서 문제가 생겨 종료되더라도 스스로 복구되지 않습니다.

Replica Set을 활용하면 이 Pod을 정해진 수만큼 생성하고 그대로 Pod의 개수가 유지될 수 있도록 관리할 수 있습니다.

위의 그림처럼 Replica Set이 3이라고 가정해볼게요!

Node3이 모종의 이유로 다운되면서 Pod 1개가 함께 중지되었습니다.

Deployment는 Replica Set=3을 유지하기 위해서 다운된 Node3 대신 정상적인 Node2에 새로운 Pod를 생성합니다.

이러한 이유로 Pod의 실행이 실패되더라도 Deployment는 계속 종료되지 않는답니다.

여기까지 Kubernetes의 기본적인 구성 요소인 Pod, Deployment, Service에 대해 알아보았습니다 :)