TIL - 발표과제 정리

문한성·2023년 5월 18일
0

부트캠프

목록 보기
90/123
post-thumbnail

디플로이먼트가 지원하는 배포 전략에서 블루/그린이나 카나리는 찾아볼 수 없습니다. 어떻게 블루/그린이나 카나리 배포를 할 수 있을까요?

Kubernetes 배포에는 블루/그린 또는 카나리아 배포에 대한 기본 제공 지원이 없지만 다양한 기술과 Kubernetes 기능을 사용하여 이러한 배포 전략을 달성할 수 있습니다. 다음은 Kubernetes에서 블루/그린 및 카나리아 배포를 구현하는 몇 가지 접근 방식입니다.

블루/그린 배포:

  • Kubernetes 클러스터에서 "파란색" 및 "녹색"과 같은 두 개의 별도 포드 세트 또는 복제본 세트를 설정합니다.
  • 처음에는 모든 트래픽을 현재 프로덕션 환경을 나타내는 "파란색" 세트로 보냅니다.
  • 응용 프로그램의 업데이트된 버전을 "그린" 세트에 배포하여 테스트되고 올바르게 작동하는지 확인합니다.
  • 서비스 또는 인그레스 구성을 점진적으로 업데이트하여 트래픽의 일부를 "그린" 세트로 리디렉션합니다.
  • 모든 문제에 대해 "녹색" 세트의 새 배포를 모니터링합니다.
  • 문제가 발생하면 서비스 또는 인그레스 구성을 업데이트하여 트래픽을 "파란색" 세트로 빠르게 전환할 수 있습니다.
  • "녹색" 세트의 안정성에 확신이 들면 "파란색" 세트를 폐기하거나 백업으로 유지할 수 있습니다.

카나리 배포

track 레이블을 사용하여 다른 릴리스를 구별할 수 있다.

기본(primary), 안정(stable) 릴리스에는 값이 stable 인 track 레이블이 있다.

     name: frontend
     replicas: 3
     ...
     labels:
        app: guestbook
        tier: frontend
        track: stable
     ...
     image**: gb-frontend:v3

그런 다음 서로 다른 값(예: canary)으로 track 레이블을 전달하는 방명록 프론트엔드의 새 릴리스를 생성하여, 두 세트의 파드가 겹치지 않도록 할 수 있다.

     name: frontend-canary
     replicas: 1
     ...
     labels:
        app: guestbook
        tier: frontend
        track: canary
     ...
     image: gb-frontend:v4

프론트엔드 서비스는 레이블의 공통 서브셋을 선택하여(즉, track 레이블 생략) 두 레플리카 세트에 걸쳐 있으므로, 트래픽이 두 애플리케이션으로 리디렉션된다.

  selector:
     app: guestbook
     tier: frontend

안정 및 카나리 릴리스의 레플리카 수를 조정하여 실제 운영 트래픽을 수신할 각 릴리스의 비율을 결정한다(이 경우, 3:1).

확신이 들면, 안정 릴리스의 track을 새로운 애플리케이션 릴리스로 업데이트하고 카나리를 제거할 수 있다.

서비스의 타입은 ClusterIP, NodePort, LoadBalancer, ExternalName 네 가지가 있습니다. 이들은 어떻게 다른가요?

Kubernetes의 네 가지 서비스 유형(ClusterIP, NodePort, LoadBalancer 및 ExternalName)은 서로 다른 용도로 사용되며 고유한 특성을 가지고 있습니다. 각 유형에 대한 분석은 다음과 같습니다.

  1. 클러스터IP:
    • ClusterIP는 Kubernetes의 기본 서비스 유형입니다.
    • 클러스터 내부 IP 주소에 서비스를 노출합니다.
    • 서비스는 클러스터 내에서만 액세스할 수 있습니다.
    • ClusterIP는 클러스터 내의 서로 다른 구성 요소 간의 내부 통신에 적합합니다.
  2. 노드 포트:
    • NodePort는 클러스터의 모든 노드에서 특정 포트의 서비스를 노출합니다.
    • 각 노드의 IP 주소와 할당된 포트에 리스너를 생성합니다.
    • 할당된 포트에서 노드의 IP 주소에 연결하여 클러스터 외부에서 서비스에 액세스할 수 있습니다.
    • NodePort는 개발 및 테스트 목적으로 자주 사용되지만 보안 고려 사항으로 인해 프로덕션 환경에는 권장되지 않습니다.
  3. 로드밸런서:
    • LoadBalancer는 외부 로드 밸런서(기본 인프라에서 지원하는 경우)를 프로비저닝하여 서비스 전체에 트래픽을 분산합니다.
    • 일반적으로 서비스에 대한 공인 IP 주소를 제공합니다.
    • 서비스는 로드 밸런서의 IP 주소를 통해 클러스터 외부에서 액세스할 수 있습니다.
    • LoadBalancer는 인터넷 또는 외부 사용자에게 서비스를 노출하는 데 적합하여 로드 밸런싱 및 고가용성을 제공합니다.
  4. 외부 이름:
    • ExternalName은 서비스를 외부 DNS 이름에 매핑합니다.
    • 프록시 또는 로드 밸런싱 기능을 생성하지 않습니다.
    • 대신 IP 주소가 아닌 DNS 이름을 사용하여 외부 서비스에 액세스할 수 있습니다.
    • ExternalName은 종종 Kubernetes 클러스터 외부에 있는 서비스와 통합하는 데 사용됩니다.

요약하면 ClusterIP 및 NodePort는 주로 내부 클러스터 통신 및 개발/테스트 시나리오에 사용되는 반면 LoadBalancer는 로드 밸런싱 기능으로 서비스를 공개적으로 노출하는 데 사용됩니다. 반면에 ExternalName은 프록시 또는 로드 밸런싱 기능 없이 서비스를 외부 DNS 이름에 매핑하기 위한 것입니다.

profile
기록하고 공유하려고 노력하는 DevOps 엔지니어

0개의 댓글