쿠버네티스

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

기본개념

 

로드밸런싱

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

헬스 체크

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

스케일링

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

오케스트레이션

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

 

쿠버네티스

• 개념: 구글이 개발한 오케스트레이션(커널이 관리 및 운영 자동화) 도구
• 쿠버네티스말고도 컨테이너 오케스트레이션 도구가 있지만, 쿠버네티스가 표준이 되었다.

기능

가능한 기능

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

제한 기능

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

 

쿠버네티스 클러스터

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

 

노드의 유형

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

파드

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

컨테이너 배치 기준

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

 

파드의 필요성

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

 

파드의 디자인 패턴

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

 

Deployment controller

• 개념: 파드 관리 방식, ReplicaSet을 그룹화하고 관리하는 단위

 

ReplicaSet

• 개념: 쿠버네티스에서 파드를 관리하는 기본 단위로, 지정한 수만큼의 파드 복제를 유지하는 역할
• 역할
  • 파드 복제 유지: 지정한 수의 파드를 항상 유지하여, 파드가 실패하거나 중지된 경우 자동으로 복구한다.
  • 스케일링: 파드의 수를 동적으로 조절할 수 있어, 요청의 양에 따라 파드를 늘리거나 줄일 수 있다.
  • 롤링 업데이트: 새로운 버전의 애플리케이션을 배포할 때, 이전 버전의 파드 수를 줄이고 새 버전의 파드 수를 늘려 업데이트를 수행

 

• 파드는 하나 이상의 컨테이너 그룹, 레플리카셋은 하나 이상의 파드 그룹
• 파드는 다른 유형의 컨테이너 포함, 레플리카셋은 같은 유형의 파드만 포함
• 레플리카셋은 하나 이상의 파드 그룹, 디플로이먼트는 하나이상의 레플리카셋 그룹

 

장점

• 헬스 체크: 파드의 상태를 모니터링하고, 실패한 파드를 자동으로 재시작하여 시스템의 안정성을 유지합니다.
• 스케일링 지원: 파드 수를 쉽게 조절 -> 애플리케이션의 부하에 맞게 대응 가능
• 롤링 업데이트: 오래된 레플리카셋의 파드 수는 줄이고, 새 레플리카셋의 파드 수는 늘려 파드의 새로운 버전을 점진적으로 배포할 수 있어, 다운타임을 최소화하고 안정성을 높인다.

 

Deployment:

• ReplicaSet을 그룹화하여, 여러 ReplicaSet을 생성하고 관리
• 파드의 업데이트와 스케일링을 자동으로 처리

 

레플리카셋이 유지하는 파드 수를 증감하거나 레플리카셋을 생성

 

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

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

 

컨트롤러

• 개념: 현재 상태에서 설정한 상태로 만드는 매커니즘으로, 현재 상태와 설정한 상태가 차이가 있을때 이를 조정하여 상태를 일치시킨다.
• 역할: 디플로이먼트 컨트롤러는 디플로이먼트를 특정한 상태로 유지하는 컨트롤러로, 차이의 상태에 따라서 취해야할 동작을 결정하고 동작한다.

 

참고

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