쿠버네티스(Kubernetes)란? + workload
본문 바로가기
DevOps 부트캠프/etc.

쿠버네티스(Kubernetes)란? + workload

by liveloper jay 2022. 4. 25.

쿠버네티스에 대해서 알아보기전에 먼저 컨테이너의 개념과 Docker에 대해 학습을 진행하시면 내용을 이해하는데 도움이 될 것입니다.
https://liveloper-jay.tistory.com/90

Docker란?_ 컨테이너와 Docker

Summary 우리가 어떠한 애플리케이션을 설치하고 실행을 하려고 한다면, 그냥 실행이 되는 것이 아니라 그에 맞는 환경이 기본적으로 구축이 되어 있을 경우에 정상적으로 실행이 됩니다. 그런데

liveloper-jay.tistory.com

Kubernetes란?


쿠버네티스(kubernetes)는 오픈소스로 만들어진 컨테이너 오케스트레이션 도구로, 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링하는 등의 관리 기능을 제공합니다. 여기서 '그럼 그냥 Docker Compose 사용해서 관리하면 되는거 아니야?' 라는 의문점이 드실 겁니다. 이 부분에 대한 의문점 해결을 위해 컨테이너 오케스트레이션이란 무엇인지에 대해 알아보겠습니다.

💡 Docker Compose란?

  Docker compose는 여러개의 컨테이너 애플리케이션을 정의하고 공유하는데 도움이 되도록 개발된 두구입니다. Compose 에서는 YAML 파일을 사용하여 애플리케이션 서비스를 구성합니다. 또한 Compose의 명령어들을 이용하여 애플리케이션의 전체 수명 주기를 관리합니다.


컨테이너 오케스트레이션 도구는 수십~수백개의 컨테이너를 관리할 때 보다 더 잘 관리하기 위한 툴입니다. 그럼 어떻게 수십~ 수백개의 컨테이너가 생기게 되는 것일까요? 생기는 과정은 다음과 같습니다.

  • 아키텍처의 트렌드가 모놀리식 -> 마이크로서비스 로의 변화가 이루어집니다.
  • 그로 인해 하나의 서버안에 다양한 서비스를 구현하던 방식에서 서비스마다 컨테이너를 하나씩 생성하다보니 컨테이너의 수가 증가합니다.
  • 여기에 확장성을 고려하여 스케일링을 더하게 되면 많은 수의 컨테이너가 필요하게 됩니다.

따라서 소규모의 서비스를 운영하는 조직보다는 마이크로서비스를 운영하는 조직이 회사 내에 여러 팀이 존재하고, 그들이 최소 2개 이상의 레플리카를 만들 경우에 쿠버네티스의 도입을 고려해볼 수 있을 것입니다.





Kubernetes 적용


그럼 이러한 쿠버네티스를 언제 사용해야하고 언제 사용하지 말아야 할까요? 사용하지 말아야 하는 경우부터 먼저 알아보겠습니다.

1. 모놀리식 아키텍처 사용

- 모놀리식 아키텍처를 사용하는 경우에는 먼저 마이크로서비스 분해 전략을 세우는 것이 우선이며, 여러 Tier로 나누어지지 않았기 때문에 적합하지 않습니다.

2. 적은 수의 컨테이너를 다루는 경우

- 3~4개 밖에 안되는 적은 수의 컨테이너는 위에 설명했던 docker compose를 이용하는 것만으로도 충분합니다.

3. 아키텍처가 단순하고, 스케일링이 필요하지 않은 경우

- 이후 트래픽이 증가하거나 스케일링이 필요한 경우, 서버리스 서비스를 사용하여 관리할 수 있으며, AWS 내에서도 오토 스케일링과 같은 관리형 서비스가 배포환경에서 제공되기때문에 현재 상황에서는 사용할 필요가 없습니다.


그러면 언제 이러한 쿠버네티스를 사용하는 것일까요? 쿠버네티스가 언제 필요한지를 먼저 알아보겠습니다.

  • 마이크로서비스를 컨테이너 방식으로 운영하는 경우 (확장을 어떻게..?)
  • 무중단 서비스, 즉 고가용성을 제공해야 할때
  • 그밖의 자가 치유, 구성 관리, 로드밸런싱....

이렇게 보면 AWS와 같은 퍼블릭 클라우드 공급자와 제공하는 기능이 비슷한 듯 합니다. 그러나 퍼블릭 클라우드를 이용하는 경우 비용적인 측면에서 자유로울 수 없습니다. (돈 많으면 상관 없....) 따라서 이를 피하기 위해 쿠버네티스를 사용하기도 합니다. 정리하면 다음과 같습니다.

  • 쿠버네티스를 이용하여 온프레미스 환경에서 클라우드 인프라 구성하는 경우
  • 저렴한 클라우드 서비스의 일부분을 도입하여 쿠버네티스와 하이브리드 형대로 구성
  • 필요에 따라 쿠버네티스로 구성한 인프라를 통째로 AWS 등에 마이그레이션 하기도 합니다. (EKS)





Kubernetes Workload


워크로드는 '쿠버네티스 상에서 작동되는 애플리케이션'을 의미하며, 클라우드 분야에서는 '어떤 애플리케이션을 실행할 때 필요한 IT 리소스의 집합'이라는 의미로 통용됩니다. 쿠버네티스에서는 워크로드를 일련의 pod 집합내에서 실행합니다. 그럼 pod란 무엇일까요?

(아래 예제를 따라하기 전 minikube를 먼저 설치하고 minikube start도 실행을 먼저 시킨 후 진행하셔야합니다! https://minikube.sigs.k8s.io/docs/start/)

Pod

파드(pod)는 쿠버네티스의 배포 가능한 가장 작은 컴퓨팅 유닛입니다. 파드는 그 자체로 하나의 논리적인 호스트입니다. 파드는 다음의 요소들을 포함할 수 있습니다.

  • 애플리케이션 컨테이너
  • IP 주소
  • 볼륨과 같은 공유 스토리지

파드를 정의할 때 YAML파일을 사용하여 정의할 수 있습니다. 아래는 Pod를 생성하기 위한 간단한 yaml 예제입니다.

apiVersion: v1
kind: Pod
metadata:
  name: cozserver-pod
spec:
  containers:
  - name: cozserver-pod
    image: sebcontents/cozserver:1.0    
    imagePullPolicy: Always
    ports:
    - containerPort: 80

위의 예제는 docker hub에 존재하는 sebcontents/cozserver:1.0 이미지를 바탕으로 cozserver-pod를 만드는 예제입니다.
위 코드를 작성 후 아래 명령을 통해 확인하면 예상대로 잘 생성된 것을 확인할 수 있습니다.

kubectl apply -f {yaml 파일}   // yaml 파일 적용
kubectl get pods              // pod 확인
cozserver-pod Running 상태



실제로 쿠버네티스에서 직접 개별 파드를 만들 일은 그렇게 많지 않습니다. 왜냐하면 파드는 일시적이고, 언제나 삭제될 수 있음을 감안하고 만들기 때문입니다. 그리고 컨테이너를 수동으로 만들고 관리하는 것은 도커만 단독으로 사용해도 충분히 가능한 일입니다. 쿠버네티스의 핵심은 컨테이너를 오케스트레이션 -> 파드 장애시 복구/복제 등의 일을 자동으로 처리하는데 있습니다.
결론적으로 파드는 deployment, statefulset, demonset을 이용해 관리하는 것이 바람직합니다.

Deployment

디플로이먼드(deployment)는 파드를 업데이트하기 위한 선언적 명세입니다. 디플로이먼트 리소스를 통해 다음과 같은 작업을 할 수 있습니다.

  • 파드를 원하는 개수만큼 실행시킬 수 있습니다. (레플리카셋 이용)
  • 파드를 업데이트할 수 있습니다. (Control Plane 이용)
  • 마찬가지로, 파드를 롤백하는 것도 가능합니다.

아래 예제는 YAML파일을 이용한 deployment 예제입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sprint-cozserver
spec:
  selector:
    matchLabels:
      app: sprint-cozserver
  replicas: 2
  template:
  # 여기서부터 pod 템플릿
    metadata:
      labels:
        app: sprint-cozserver
    spec:
      containers:
      - name: sprint-cozserver
        image: sebcontents/cozserver:1.0  
        ports:
        - containerPort: 8080

위의 코드를 통해 똑같이 apply를 적용하면 sprint-cozserver라는 이름의 디플로이먼트가 생기고 레플리카셋이 2로 정의 되어있기 때문에 레플리카셋을 통해 파드가 2개 생성되어집니다. 결과는 아래와 같습니다.

아직 파드 생성중인데 그냥 캡쳐...ㅎㅎ(후에 running 확인했습니다!)



Service


클러스터 내부 파드는 각각의 고유 IP를 가지고 있지만, 우리가 내부망에 직접 접속할 수 있는 것은 아닙니다. 이러한 파드 집합에 접근할 수 있게 돕는 역할을 하는 것이 서비스 리소스입니다. 아래 예제는 LoadBalancer를 이용한 서비스 리소스의 예제입니다.

apiVersion: v1
kind: Service
metadata:
  name: cozserver-service
  namespace: default
spec:
  selector:
    app: sprint-cozserver # 배포하려는 파드를 지정합니다. 당연히 파드가 이미 실행중이어야 합니다.
  type: LoadBalancer
  ports:
  - name: cozserver-service
    protocol: TCP
    port: 80           # 외부에서 접근하는 포트
    targetPort: 8080     #타겟 포트

위의 과정을 통해 LoadBalancer로 서비스를 만들고, sprint-cozserver라는 파드에 연결되도록 지정했습니다. 여기서 kubectl create -f {yaml파일} 을 통해 적용을 시키고 kubectl tunnel 명령을 통해 External-IP를 설정하고 접속 결과를 확인해줍니다.

cozserver-service의 External-IP 확인
접속 되는 것 확인


위 과정을 통해 pod 생성과, deployment를 이용한 pod생성 그리고 Service를 이용한 외부접속까지 진행해보았습니다.




참고자료:
codestates 학습 플랫폼 - 컨테이너 오케스트레이션 자료
https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive/
https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/
https://azure.microsoft.com/ko-kr/topic/what-is-kubernetes/#features

댓글