쿠버네티스

쿠버네티스를 알아보기 앞서, 오케스트레이션과 그에 관련한 개념들을 알아보자!!

 

기본개념

 

로드밸런싱

• 개념: 여러 컨테이너에 요청을 분산시켜 부하를 균등하게 배분하는 것
• 방법: 로드밸런싱 장치가 컨테이너 앞에 배치된다. 이를 통해 컨테이너당 부하를 줄이고 처리 시간 단축 가능

헬스 체크

• 개념: 컨테이너가 정상적으로 실행 중인지 여부를 모니터링하는 프로세스
• 방법: 컨테이너에 요청을 보내고 컨테이너가 정상적으로 응답을 반환하는지 확인. 만약 응답이 반환되지 않으면 문제가 있다고 여기고, 해당 컨테이너를 비활성화하여 시스템이 정상적으로 가동되는 시간을 늘린다. (= 가용성을 유지한다.)

스케일링

• 개념: 요청 규모에 따라 컨테이너 수를 조절하는 것
• 방법:임계값에 따라 리소스를 자동으로 늘리거나 줄여 성능과 효율성을 유지
  • 수직적 스케일링
  • 수평적 스케일링

 

오케스트레이션

 

• 개념: 컨테이너의 관리 및 운영을 자동화하는 프로세스
• 필요성: 컨테이너가 수동으로 관리되면 각 컨테이너가 독립적으로 운영되어 엉망진창으로 돌아다닐 것! 오케스트레이션을 통해 일관성 있고 효율적인 관리가 가능해진다.
• 위에 설명한 로드밸런싱, 헬스체크는 수동으로 실행할 수 있지만, 관리해야할 컨테이너의 수가 증가하면 이를 수동으로 처리하기 어렵다.
• 컨테이너를 활용한 애플리케이션이 보급되고 그 규모가 커질수록 컨테이너 오케스트레이션의 필요성은 더욱 커질것이다.

 

쿠버네티스

어원: 조타수, 조종사라는 그리스어

• 개념: 구글이 개발한 오케스트레이션(커널이 관리 및 운영 자동화) 도구
  • 다수의 컨테이너를 효율적으로 배포, 확장 및 관리하기 위한 오픈소스 시스템
• 쿠버네티스말고도 컨테이너 오케스트레이션 도구(도커 스웜모드 등)가 있지만, 쿠버네티스가 표준이 되었다.

 

기능

 

가능한 기능

• 컨테이너 관리 및 운영 자동화: 컨테이너를 활용한 애플리케이션의 운영을 간소화하고, 필요에 따라 리소스를 효율적으로 분산할 수 있다.
• 헬스 체크 및 재시작: 컨테이너의 상태를 모니터링하고, 실패한 컨테이너를 자동으로 재시작
• 엔드포인트 제공 및 로드 밸런싱: 컨테이너에 대한 접근을 효율적으로 관리하고, 요청을 여러 컨테이너로 분산
• 컨테이너 배포 및 롤링 업데이트: 애플리케이션의 새로운 버전을 점진적으로 배포하고, 필요시 롤백
• 스토리지 관리: 컨테이너와 연동된 스토리지를 효율적으로 관리
• 기밀 정보 및 구성 정보 저장: 중요한 정보를 안전하게 저장하고 관리

제한 기능

• 자동 빌드 및 미들웨어 기능: 쿠버네티스는 자동으로 애플리케이션을 빌드하거나 메시지 브로커, 데이터베이스와 같은 미들웨어 기능을 제공하지 않는다.
• 하드웨어 서버  관리: 쿠버네티스는 컨테이너와 클러스터 관리에 중점을 두며, 서버의 하드웨어나 운영체제 자체를 관리하지 않는다.
• 로그 기록 및 감시: 기본적으로 로그 기록이나 감시 기능은 제공하지 않으며, 이러한 기능을 추가하기 위해 다른 도구와의 연동이 필요

 

쿠버네티스 클러스터

 

• 정의: 대량의 컨테이너와 서버를 효율적으로 관리하고 운영하는 시스템의 집합
• 노드: 클러스터를 구성하는 각 서버

 

노드의 유형

 

• 워커 노드: 실제로 파드(컨테이너를 실행하는 최소 단위)를 구동하는 노드
• 마스터 노드: 워커 노드를 제어하고 관리하는 노드로, 파드의 배치와 스케줄링을 담당

 

파드

• 정의: 파드는 하나 이상의 컨테이너를 포함하는 쿠버네티스의 관리하는 최소 단위
• 같은 파드 내의 컨테이너는 네트워크와 스토리지를 공유하며, 서로 밀접하게 협력한다.
• 사용자 인터페이스: 사용자는 직접 워커 노드에서 파드를 실행하지 않고, 마스터 노드를 통해 파드를 관리
• 주요 특성
  • 네트워크 공유: 같은 파드에 포함된 컨테이너들은 동일한 네트워크 네임스페이스를 공유한다. 즉, 같은 IP 주소를 사용하고, 로컬 호스트를 통해 서로 통신 가능
  • 스토리지 공유: 파드 내의 컨테이너들은 같은 볼륨을 마운트하여 데이터를 공유
  • 라이프사이클: 같은 파드에 포함된 컨테이너는 같은 라이프사이클을 갖는다. 즉, 파드가 생성되거나 삭제될 때 모든 컨테이너가 함께 생성되거나 삭제된다. 예를 들어 따라서 컨테이너 A, 컨테이너 B가 같은 파드에 있다면, 컨테이너 A만 구동하고나 컨테이너 A만 구동할 수 없다.

.yaml 파일

apiVersion: v1 # Pod를 생성할 때는 v1이라고 기재한다.
kind: Pod # Pod를 생성한다고 명시
metadata:
  name: nginx-pod # Pod 이름
spec:
  containers:
    - name: nginx-container # 생성할 컨테이너의 이름
      image: nginx # 컨테이너를 생성할 때 사용할 Docker 이미지
      ports:
        - containerPort: 80

이때  spec.containers.ports.containerPort : 실제 작동에는 영향을 미치지 않는다. 명시적으로 나타내기 위한 문서화용

즉, 어차피 80번 포트에서 실행된다.

• 쿠버네티스는 위의 .yaml파일을 Manifest File이라 한다. 
• 쿠버네티스에서 다양한 리소스(파드, 서비스, 볼륨 등)을 생성하고 관리하기 위해 사용

 

컨테이너 배치 기준

• 밀접한 관계: 일반적으로 같은 파드에 포함된 컨테이너들은 서로 밀접한 관계가 있어야 한다.
  • 예를 들어, 데이터베이스와 데이터베이스 관리 도구를 같은 파드에 두면 좋다.
• 상호 작용: 서로 긴밀하게 상호 작용하는 컨테이너들은 같은 파드에 포함
  • 이는 네트워크 성능을 최적화하고 데이터 공유를 용이하게 하기 위함
• 독립성: 컨테이너가 서로 독립적으로 동작해야 한다면, 같은 파드에 포함할 필요는 없다. 어차피 네트워킹 기능을 통해 서로 다른 파드에 있는 컨테이너들도 통신할 수 있다.

 

파드의 필요성(왜 사용해야 할까?)

• 운영 부하 경감: 컨테이너에서 여러 프로세스를 시작하면 직접 프로세스를 관리해야 하지만, 여러 컨테이너를 같은 파드에 포함시키면 쿠버네티스가 이들을 관리하고, 라이프사이클을 일치켜서 수동으로 프로세스를 관리해야 하는 부담을 줄인다.
• 리소스 소비 최적화: 파드 내의 컨테이너들이 공유하는 리소스(스토리지, 네트워크) 덕분에 리소스 소비를 최적화 가능
• 패키지 관리: 컨테이너별로 필요한 최소한의 패키지만 설치하여, 불필요한 작업과 리소스 낭비를 줄인다.

 

파드의 디자인 패턴

• One-Container-Per-Pod: 가장 일반적인 패턴으로, 파드 당 하나의 컨테이너를 실행. 간단한 애플리케이션의 경우 유용
• Sidecar 컨테이너: 하나의 주 애플리케이션 컨테이너와 함께 보조 역할을 하는 컨테이너를 포함하는 패턴
  • 예를 들어, 로그 수집기, 모니터링 도구 등이 Sidecar 컨테이너로 동작할 수 있다.

 

 

 

Deployments and ReplicaSets

• 개념: 파드 관리 방식, ReplicaSet을 그룹화하고 관리하는 단위
• 파드는 하나 이상의 컨테이너 그룹, 레플리카셋은 하나 이상의 파드 그룹, 디플로이먼트는 하나이상의 레플리카셋 그룹
• 파드는 다른 유형의 컨테이너 포함, 레플리카셋은 같은 유형의 파드만 포함, 디플로이먼트는 다른 유형 포함 가능하나 같은 레플리카셋의 다른 버전을 포함

 

ReplicaSet

• 개념: 쿠버네티스에서 파드를 관리하는 기본 단위로, 지정한 수만큼의 파드 복제를 유지하는 역할
• 역할
  • 헬스 체크: 파드의 상태를 모니터링하고, 실패한 파드를 자동으로 재시작하여 시스템의 안정성을 유지한다.
  • 스케일링: 파드의 수를 동적으로 조절 -> 요청의 양에 따라 파드를 늘리거나 줄일 수 있다.
  • 롤링 업데이트: 오래된 레플리카셋의 파드 수는 줄이고, 새 레플리카셋의 파드 수는 늘려 파드의 새로운 버전을 점진적으로 배포할 수 있어, 다운타임을 최소화하고 안정성을 높인다. 

 

Deployment

• 개념: 쿠버네티스에서 ReplicaSet을 관리하는 상위 개념, 레플리카셋이 유지하는 파드 수를 증감하거나 레플리카셋을 생성
• 역할
  • ReplicaSet 관리: 사용자가 정의한 파드의 개수를 유지하기 위해 내부적으로 ReplicaSet을 생성 및 조정한다
  • 롤링 업데이트: 기존 파드를 점진적으로 대체하여 다운타임 없이 애플리케이션을 업데이트할 수 있다.
  • 롤백: 문제가 발생하면 이전 버전으로 쉽게 되돌릴 수 있어 서비스의 안정성을 보장한다.
  • 스케일링: 수동 또는 자동으로 파드 개수를 조정하여 트래픽 변화에 유연하게 대응할 수 있다.
  • Self-healing: 장애가 발생한 경우 자동으로 파드를 재생성하여 서비스 가용성을 유지한다.

 

디플로이먼트가 필요한 이유: 자신을 포함하는 레플리카셋이나 파드를 자동으로 갱신하기 위한 구조를 갖추고 있기 때문

레플리카셋으로 파드 수를 늘리거나 줄여서 스케일링,롤링 업데이트 되지만, 디플로이먼트 사용하면 쿠버네티스가 자동으로 파드 수 조정하고 새 레플리카 셋을 만들 수 있다. 일반적으로 같은 레플리카셋의 다른 버전을 포함한다.

 

컨트롤러

• 개념: 현재 상태에서 설정한 상태로 만드는 매커니즘으로, 현재 상태와 설정한 상태가 차이가 있을때 이를 조정하여 상태를 일치시킨다.

 

deployment == deployment controller?

 

• Deployment는 쿠버네티스에서 애플리케이션 배포를 정의하는 리소스로, 사용자가 원하는 파드의 개수, 업데이트 방식, 롤백 전략 등을 선언적으로 설정할 수 있다. 이를 통해 애플리케이션을 롤링 업데이트 방식으로 배포하거나, 문제가 발생했을 때 이전 버전으로 쉽게 되돌릴 수 있으며, 필요에 따라 파드 개수를 조정하여 트래픽 변화에 대응할 수도 있다. 하지만 Deployment 자체는 단순히 배포 전략을 정의하는 역할만 하며, 이를 실제로 실행하고 관리하는 것은 Deployment Controller다.
• Deployment Controller는 쿠버네티스의 컨트롤러 중 하나로, Deployment가 기대하는 상태를 유지하도록 지속적으로 모니터링하고 필요한 조치를 수행한다. 예를 들어, 사용자가 새로운 Deployment를 생성하면 Deployment Controller는 이를 감지하고, 내부적으로 ReplicaSet을 생성하여 지정된 개수만큼의 파드를 배포한다. 또한, 기존 Deployment를 업데이트할 경우, 이전 ReplicaSet의 파드 개수를 줄이면서 새로운 ReplicaSet의 파드를 점진적으로 늘리는 롤링 업데이트를 수행하여 서비스의 중단을 최소화한다. 만약 배포 과정에서 문제가 발생하면 Deployment Controller는 이를 감지하고, 사용자가 설정한 조건에 따라 롤백을 수행할 수도 있다. 즉, Deployment Controller는 Deployment의 목표 상태와 실제 상태를 지속적으로 비교하면서, 불일치가 발생할 경우 이를 자동으로 조정하여 애플리케이션이 안정적으로 운영되도록 보장하는 역할을 한다.

 

구조 정리

1. Pod: 애플리케이션이 실제로 실행되는 최소 배포 단위
2. ReplicaSet: 여러 개의 Pod를 관리하고, 지정된 개수를 유지하는 역할
3. Deployment: ReplicaSet을 생성하고, 파드의 배포, 업데이트,  롤백, 스케일링을 선언적으로 정의하는 리소스
4. Deployment Controller: Deployment 객체를 감시하고, 목표 상태(ReplicaSet 개수, 파드 상태 등)를 유지하도록 관리

즉, Deployment → ReplicaSet → Pod 는 쿠버네티스의 배포 구조이고, 이를 지속적으로 감시하고 유지하는 컨트롤러가 Deployment Controller

 

뒤에 배울 것들을 아울러 서비스, 디플로이먼트, 파드 같은 리소스를 통틀어서 Object라 한다.

 

 

참고

https://www.copado.com/resources/blog/kubernetes-deployment-vs-service-managing-your-pods