컨테이너 오케스트레이션 - 복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구
쿠버네티스 - 컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화 해주는 오픈소스 플랫폼
- 무한한 확장성
- 사실상의 표준
쿠버네티스 공식홈페이지에 설명이 아주 잘 되어 있다.
https://kubernetes.io/ko/docs/concepts/overview/
쿠버네티스 치트 시트(kubectl 명령어)
https://kubernetes.io/ko/docs/reference/kubectl/cheatsheet/
- 디플로이먼트가 지원하는 배포 전략에서 블루/그린이나 카나리는 찾아볼 수 없습니다. 어떻게 블루/그린이나 카나리 배포를 할 수 있을까요?
블루/그린 또는 카나리 배포 전략은 일반적으로 디플로이먼트의 내장된 기능은 아니지만, Kubernetes와 같은 컨테이너 오케스트레이션 툴을 사용하면 이러한 전략을 구현할 수 있습니다. 아래에서 각 전략에 대해 설명하겠습니다.-
블루/그린 배포(Blue/Green Deployment):
블루/그린 배포는 새로운 버전의 애플리케이션을 배포하기 전에 기존 버전의 애플리케이션과 완전히 분리된 새로운 환경(그린)을 구성하고, 이 환경에서 테스트와 검증을 수행한 후에 트래픽을 새 버전으로 전환하는 전략입니다. 이를 위해 일반적으로 두 개의 별도 Kubernetes 디플로이먼트를 생성하고, 서비스의 라우팅 규칙을 변경하여 트래픽을 전환합니다. -
카나리 배포(Canary Deployment):
카나리 배포는 실제 트래픽 일부를 새로운 버전으로 전환하는 전략입니다. 예를 들어, 5%의 트래픽을 새 버전으로 보내고 나머지 95%는 기존 버전을 사용합니다. 이를 통해 신규 버전의 성능과 안정성을 모니터링하고, 문제가 발생할 경우 전체 트래픽을 롤백하여 안정성을 유지할 수 있습니다. 이 역시 Kubernetes를 사용하여 별도의 디플로이먼트를 생성하고, 트래픽 라우팅 규칙을 조정하여 카나리 배포를 수행합니다.블루/그린 및 카나리 배포를 구현하기 위해 Kubernetes에서는 일반적으로 Ingress 컨트롤러를 사용하여 트래픽을 조정하고, 롤링 업데이트 및 롤백 등의 기능을 제공하는 디플로이먼트 전략을 설정합니다. 이를 통해 애플리케이션의 버전 업그레이드와 롤백을 관리할 수 있습니다.
-
- 서비스의 타입은 ClusterIP, NodePort, LoadBalancer, ExternalName 네 가지가 있습니다. 이들은 어떻게 다른가요?
서비스의 타입(ClusterIP, NodePort, LoadBalancer, ExternalName)은 Kubernetes에서 서비스가 클러스터 내부 및 외부에서 접근 가능한 방식을 정의합니다. 각 타입은 다음과 같은 특징을 가지고 있습니다:-
ClusterIP:
- ClusterIP 타입은 기본적으로 생성되는 서비스 타입입니다.
- 클러스터 내부에서만 접근 가능한 가상 IP 주소를 할당합니다.
- 외부로부터의 접근은 차단되며, 다른 리소스(파드, 서비스 등) 내에서만 사용됩니다.
- 일반적으로 내부 서비스 간 통신에 사용됩니다.
-
NodePort:
- NodePort 타입은 클러스터 외부에서 접근 가능한 포트를 각 노드에 할당합니다.
- 클러스터 내의 모든 노드의 특정 포트를 통해 서비스에 접근할 수 있습니다.
- 지정된 포트를 통해 클러스터 내부의 서비스에 접근할 수 있으며, 클러스터 외부에서도 노드의 IP와 지정된 포트를 통해 서비스에 접근할 수 있습니다.
- 개방된 포트를 통해 외부로부터의 접근이 가능하므로, 보안을 고려해야 합니다.
-
LoadBalancer:
- LoadBalancer 타입은 클라우드 공급자가 제공하는 로드 밸런서를 사용하여 외부로부터의 트래픽을 분산합니다.
- 클러스터 외부에서 서비스에 접근하기 위해 공인 IP와 로드 밸런서를 자동으로 프로비저닝합니다.
- 클라우드 제공 업체에 따라 지원 여부가 다를 수 있으며, 로드 밸런서의 구성은 클라우드 제공 업체에 따라 달라집니다.
-
ExternalName:
- ExternalName 타입은 클러스터 내에서 외부 서비스에 대한 CNAME을 정의합니다.
- 서비스가 외부의 DNS 이름으로 해결되도록 하며, 클러스터 내에서 해당 외부 이름으로 서비스에 접근할 수 있습니다.
- 주로 외부 서비스에 대한 프록시 역할을 할 때 사용됩니다.서비스의 타입은 클러스터의 네트워크 환경 및 요구 사항에 따라 선택되어야 합니다. 내부 통신에만 사용되는 서비스인지, 외부에서의 접근이 필요한 서비스인지에 따라 적합한 타입을 선택하여 서비스를 정의해야 합니다.
-
- 애플리케이션에 HTTP 500과 같은 에러가 발생한 경우, 컨테이너를 다시 실행해야 할 것입니다. HTTP 에러가 발생했다는 것을 어떻게 알 수 있을까요? 어떻게 해야 쿠버네티스가 에러가 발생한 컨테이너를 자동으로 재시작하게 만들 수 있을까요? (힌트:
liveness probe키워드를 검색하세요)
HTTP 500과 같은 에러가 발생한 경우, 주로 애플리케이션에서 생성하는 로그를 확인하여 알 수 있습니다. 컨테이너의 로그는 일반적으로 쿠버네티스의 로그 집계 시스템 또는 컨테이너 실행 환경(예: Docker 로그)에서 확인할 수 있습니다. 로그에는 애플리케이션에서 발생한 에러와 관련된 정보가 포함될 수 있습니다. 쿠버네티스는 컨테이너의 상태를 주기적으로 확인하고, 컨테이너가 비정상적인 종료(예: 에러가 발생하여 종료)한 경우 해당 컨테이너를 자동으로 재시작할 수 있습니다. 이를 위해 다음과 같은 방법을 사용할 수 있습니다:-
Liveness 프로브: Liveness 프로브는 컨테이너의 상태를 주기적으로 확인하고, 컨테이너가 살아있는지 여부를 결정합니다. HTTP 요청을 보내는 방식으로 Liveness 프로브를 구성할 수 있으며, 응답이 성공적으로 반환되지 않거나 일정 시간 내에 응답이 없으면 컨테이너가 실패로 표시됩니다. 쿠버네티스는 실패한 컨테이너를 자동으로 재시작합니다.
-
재시작 정책: 쿠버네티스는 파드의 재시작 정책을 구성할 수 있습니다. 재시작 정책은 컨테이너의 재시작을 제어하는 방법을 정의합니다. 예를 들어, 재시작을 항상 수행하도록 설정하거나, 일정 횟수 이상의 실패가 발생한 경우에만 재시작하도록 설정할 수 있습니다.
-
에러 핸들링: 일부 애플리케이션은 HTTP 500과 같은 에러를 처리하는 기능을 내장하고 있을 수 있습니다. 이러한 애플리케이션은 에러가 발생했을 때 자체적으로 컨테이너를 종료하도록 구성할 수 있습니다. 쿠버네티스는 종료된 컨테이너를 감지하고 재시작 정책에 따라 재시작할 수 있습니다.
위의 방법을 사용하여 쿠버네티스가 에러가 발생한 컨테이너를 자동으로 재시작하도록 구성할 수 있습니다. 이를 통해 애플리케이션의 가용성을 유지하고 장애 복구를 자동화할 수 있습니다.
-
- 왜 파드와 PV(퍼시스턴스볼륨)를 직접 연결하지 않는 걸까요?
쿠버네티스에서 파드와 퍼시스턴스 볼륨을 직접 연결하는 것은 권장되지 않습니다. 여기에는 몇 가지 이유가 있습니다:-
유연성과 확장성: 파드와 퍼시스턴스 볼륨을 직접 연결하면 파드가 특정 노드에 바인딩되고 해당 노드에서만 실행됩니다. 이는 유연성과 확장성을 제한할 수 있습니다. 파드의 수명 주기 동안 노드 장애가 발생하거나 파드가 재스케줄링되어야 할 경우, 데이터에 대한 액세스가 중단될 수 있습니다.
-
호스트 종속성: 파드와 퍼시스턴스 볼륨을 직접 연결하면 퍼시스턴스 볼륨이 특정 노드의 로컬 스토리지에 의존하게 됩니다. 이는 다중 노드 클러스터에서 작동하는 쿠버네티스 클러스터의 장점을 제한합니다. 노드 간에 파드를 이동하거나 복제하는 경우 데이터 일관성과 가용성의 문제가 발생할 수 있습니다.
-
관리의 어려움: 파드와 퍼시스턴스 볼륨을 직접 연결하면 관리 및 운영이 더 어려워집니다. 파드와 퍼시스턴스 볼륨 간의 연결을 수동으로 설정하고 업데이트해야 하며, 볼륨의 수명 주기와 파드의 수명 주기를 동기화해야 합니다. 이는 시스템 관리자에게 추가 작업 부담을 줄 수 있습니다.
따라서 쿠버네티스에서는 파드와 퍼시스턴스 볼륨 간에 추상화 계층을 제공하는 볼륨 개념을 사용합니다. 볼륨을 사용하면 파드는 퍼시스턴스 데이터에 일관된 방식으로 액세스할 수 있으며, 클러스터의 다른 노드로 파드를 이동하거나 복제하는 경우에도 데이터의 가용성과 일관성을 보장할 수 있습니다.
-
