회고

[회고] 쿠버네티스

hyuntohoon 2024. 9. 7. 03:42

[아쉬운 하루]

쿠버네티스의 컨테이너 자동 관리 시스템 및 모니터링에 매료되어 이번 프로젝트는 쿠버네티스를 사용하고자 했다. 또한 한번 경험한 MSA에서의 아쉬운 부분인 테스트 환경(front, backend 테스트)에서 argo를 적극적으로 활용한다면 효과적일 것이라 생각했다.

그래서 쿠버네티스를 조금씩 공부하고 있었다.

내가 이해한 쿠버네티스는 다음과 같다.

쿠버네티스 개요

1. 클러스터와 노드

  • 쿠버네티스는 하나의 클러스터로 구성됨
  • 클러스터는 여러 노드(Node)로 구성되며, 노드는 마스터 노드(Master Node)와 워커 노드(Worker Node)로 나뉨
  • 마스터 노드는 클러스터를 제어하고 관리하는 역할을 하며, 여러 개의 마스터 노드가 존재할 수 있음
  • 워커 노드는 실제 애플리케이션이 실행되는 Pod를 호스팅함
  • ReplicaSet은 워커 노드에서 여러 Pod를 복제하고 관리함

2. Pod과 컨테이너

  • Pod는 하나 이상의 컨테이너를 포함하며, 일반적으로 Docker 같은 컨테이너 런타임을 사용함
  • Pod는 쿠버네티스에서 애플리케이션이 배포되고 실행되는 가장 작은 단위

3. Ingress와 Service

  • Ingress는 외부에서 들어오는 HTTP 요청을 처리하여 이를 내부의 Service로 라우팅함
  • Service는 Pod 간의 네트워크 통신을 위한 고정된 엔드포인트를 제공함. 이를 통해 Pod가 동적으로 변경되어도 네트워크 통신이 안정적으로 이루어짐

4. 리소스 구성

  • 쿠버네티스의 리소스는 네 가지 주요 구성 요소로 정의됨:
    1. apiVersion: 리소스가 속한 API의 버전
    2. kind: 리소스의 유형을 정의하며, Pod, Service, Deployment, StatefulSet 등으로 구분
    3. metadata: 리소스의 이름, 라벨 등 메타데이터 정보를 포함
    4. spec: 리소스의 구체적인 동작을 정의하는 부분으로, replicas, containers, ports 등 설정을 포함

5. 상태 리소스와 비상태 리소스

  • 상태 리소스(StatefulSet)는 데이터가 영구적으로 저장되고, Pod의 상태가 중요하며, 재시작 시에도 동일한 상태가 유지되는 애플리케이션을 관리함. 예: 데이터베이스
  • 비상태 리소스(Deployment)는 데이터가 영구적으로 저장되지 않으며, 필요 시 언제든지 새로운 Pod로 대체해도 무관한 애플리케이션을 관리함. 예: Spring 서버

6. 자가 치유 기능

  • 쿠버네티스는 자가 치유(Self-Healing) 기능을 갖추고 있음. 사용자가 선언한 상태와 실제 상태가 다를 경우 자동으로 복구하여 리소스를 다시 실행하거나 생성함

7. 네임스페이스(Namespace)

  • 네임스페이스는 쿠버네티스에서 리소스를 격리하여 관리하기 위한 방법으로, 여러 팀이 같은 클러스터에서 작업할 때 충돌을 방지하고 리소스를 효율적으로 분리할 수 있도록 돕는 역할

8. Helm

  • Helm은 쿠버네티스에서 복잡한 리소스를 관리하기 위한 패키지 매니저. 여러 리소스를 하나의 차트(Chart)로 묶어 일관성 있게 배포하고 관리함

전체적인 흐름은 이전에 공부하고, 서버 관리의 경험을 통해서 이해되는 부분이 많았다.

다만 이렇게 이해한 부분 말고도 추가적으로 알아야 되는 내용이 너무 많고, 관리 방식의 다양함이 존재하는 것 같다.

그리고 어려움이 존재했는데, 쿠버네티스를 공부하고, 실습해볼 수 있는 환경 자체가 좋지 않다고 생각한다.

쿠버네티스는 일반적인 배포를 떠나 운영체제에 적용되는 효과적인 스케쥴링 방식 같은 내부적으로 동작하는 하나의 생태계 같다는 느낌을 받을 수 있었다.

예를 들어 이전의 서버는 서버 개발자, 관리자가 하나씩 설정하고, 이를 관리하는 느낌이라면,

쿠버네티스 자체는 설정 자체에 대해서 선언적으로 동작을 구성한다면 자동으로 관리되는 생태계라고 생각했다.

이러한 생태계를 기본적으로 사용한다면, 1차원적인 간편함과 다양하고, 좋은 기술을 사용할 수 있어서 좋을 것 같지만,

내부적인 동작을 건들이고, 수정해야하는 상황이 온다면 운영체제를 건들이는듯한 어려움이 존재할 것이라고 생각한다.

쿠버네티스를 효과적으로 경험하기 위해서는 다중 노드를 사용해봐야한다고 생각한다.

하지만 현재 상황에서 다중노드를 효과적으로 테스트하는 방법은 쉽지 않을 것 같다고 생각한다.

1. 단일 노드 사용 (Single Node Cluster)

단일 노드 클러스터는 하나의 노드에서 마스터와 워커 역할을 동시에 수행하는 구조를 의미함. 일반적으로 개발, 테스트 또는 소규모 애플리케이션에서 사용됨.

장점:

  • 설치와 설정이 간단: 단일 노드만 관리하면 되므로 설정과 유지보수가 간단함.
  • 자원 절약: 별도의 마스터 노드와 워커 노드를 분리하지 않으므로 자원 사용량이 적음. 소규모 환경에서 효율적으로 자원을 사용 가능.
  • 테스트 및 개발에 적합: 로컬 개발 환경이나 소규모 테스트 환경에 적합. 쿠버네티스의 기능을 실험하기 위한 간단한 클러스터로 사용 가능.

단점:

  • 확장성 부족: 단일 노드로는 대규모 애플리케이션을 운영하기 어렵고, 부하가 증가할 경우 쉽게 한계에 도달할 수 있음.
  • 내결함성 부족: 노드가 중단되면 클러스터 전체가 다운됨. 고가용성이나 안정성이 중요한 프로덕션 환경에는 적합하지 않음.
  • 성능 제한: 마스터와 워커 역할을 한 노드가 모두 담당하므로, 리소스가 충분히 분배되지 않으면 성능 저하가 발생할 수 있음.

2. 마스터 노드와 워커 노드를 분리한 사용 (Multi-Node Cluster)

이 방식은 마스터 노드와 워커 노드를 분리하여 사용하며, 마스터 노드는 클러스터의 관리와 제어, 워커 노드는 애플리케이션을 실행함. 보통 프로덕션 환경이나 대규모 애플리케이션에서 사용됨.

장점:

  • 확장성: 워커 노드를 여러 개 추가하여 애플리케이션을 확장할 수 있음. 수평 확장이 가능하므로 많은 애플리케이션을 동시에 운영 가능.
  • 고가용성: 마스터 노드와 워커 노드를 분리하면, 마스터 노드를 여러 개 복제하여 고가용성을 보장할 수 있음. 노드 중 하나가 장애가 발생해도 클러스터는 계속 동작.
  • 부하 분산: 마스터와 워커 노드를 분리해 각 노드에 적절한 역할을 할당하므로 리소스가 더 효율적으로 분배되고 관리됨.
  • 안정성: 클러스터 관리와 애플리케이션 운영이 분리되므로 장애 상황에 더 안정적으로 대응할 수 있음.

단점:

  • 설정 복잡성: 다수의 노드를 관리해야 하므로 설치와 설정이 복잡하고 유지보수 비용이 높음.
  • 자원 소모: 마스터 노드와 워커 노드를 각각 운영해야 하므로 자원 소모가 많음. 특히 작은 애플리케이션을 운영할 때는 과도한 자원을 소모할 수 있음.
  • 관리 오버헤드: 마스터와 워커 노드가 분리되어 있으면 클러스터 전체를 관리하기 위한 추가적인 도구나 관리자가 필요할 수 있음.

그래서 일단은 로컬환경에서 k3s로 개발하여 이해를 한 후 추가적인 학습을 통해 다중 노드를 사용하볼지 고민해봐야겠다.