Cloud Run for Anthos의 아키텍처 개요

이 페이지에서는 Cloud Run for Anthos의 아키텍처 개요를 제공하고 Google Kubernetes Engine 클러스터에서 Cloud Run for Anthos를 사용 설정할 때 발생하는 변경사항에 대해 설명합니다.

이 정보는 다음 유형의 사용자에게 유용합니다.

  • Cloud Run for Anthos를 시작하는 사용자
  • GKE 클러스터 실행 경험이 있는 운영자
  • 효율적인 애플리케이션 디자인 또는 Cloud Run for Anthos 애플리케이션 구성을 위해 Cloud Run for Anthos와 Kubernetes 클러스터 간의 통합 방법에 대해 자세히 알고 싶은 애플리케이션 개발자

기본 설치에 포함된 구성요소

Cloud Run for Anthos를 Google Kubernetes Engine 클러스터에 부가기능으로 설치하면 knative-servinggke-system 네임스페이스가 자동으로 생성됩니다. 다음 구성요소가 이러한 네임스페이스 중 하나에 배포됩니다.

  • knative-serving 네임스페이스에서 실행되는 구성요소:

    • Activator: pod가 0으로 수평 축소되거나 버전에 요청이 과도하게 전송되면 Activator가 요청을 일시적으로 큐에 추가하고 더 많은 pod를 가동하도록 자동 확장 처리에 측정항목을 전송합니다. 자동 확장 처리가 보고된 측정항목 및 사용 가능한 Pod를 기준으로 버전을 확장하면 Activator가 큐에 넣은 요청을 버전으로 전달합니다. Activator는 데이터 영역 구성요소입니다. 데이터 영역 구성요소는 사용자 트래픽을 전달하는 모든 기능 및 프로세스를 관리합니다.
    • 자동 확장 처리: Activator 및 큐 프록시 사이드카 컨테이너의 측정항목을 집계 및 처리합니다. 요청 동시성 제한을 적용하는 데이터 영역의 구성요소입니다. 그런 다음 자동 확장 처리는 버전의 관찰된 동시성을 계산하고 원하는 Pod 수를 기준으로 배포 크기를 조정합니다. 버전에 사용 가능한 pod가 있으면 자동 확장 처리가 제어 영역 구성요소이고, 그렇지 않고 pod가 0으로 수평 축소되면 자동 확장 처리가 데이터 영역 구성요소입니다.
    • 컨트롤러: 자동 확장 처리 및 서비스 객체의 하위 리소스를 만들고 업데이트합니다. 컨트롤러는 제어 영역 구성요소입니다. 제어 영역 구성요소는 사용자 트래픽의 요청 경로를 설정하는 모든 기능 및 프로세스를 관리합니다.
    • 웹훅: 기본값을 설정하고, 일관성이 없고 잘못된 객체를 거절하고, Cloud Run for Anthos 리소스에 대해 Kubernetes API 호출을 검사변형합니다. 웹훅은 제어 영역 구성요소입니다.
  • gke-system 네임스페이스에서 실행되는 구성요소:

    • 클러스터 로컬 게이트웨이: 한 Cloud Run for Anthos에서 다른 항목으로 전달되는 내부 트래픽을 처리하는 데이터 영역의 부하 분산기입니다. 클러스터 로컬 게이트웨이는 GKE 클러스터 내에서만 액세스할 수 있으며, 비공개 정보 또는 내부 프로세스가 실수로 노출되지 않도록 방지하기 위해 외부 도메인을 등록하지 않습니다.
    • Istio 인그레스 게이트웨이: 외부 또는 내부 네트워크의 트래픽을 포함하여 클러스터 외부에서 들어오는 트래픽을 수신하고 처리하는 데이터 영역의 부하 분산기입니다.
    • Istio 파일럿: HTTP 요청을 올바른 엔드포인트에서 처리하도록 클러스터 로컬 게이트웨이 및 Istio 인그레스 게이트웨이를 구성합니다. Istio 파일럿은 제어 영역 구성요소입니다. 자세한 내용은 Istio 파일럿을 참조하세요.

Cloud Run for Anthos 구성요소는 GKE 제어 영역 클러스터가 업데이트될 때 자동으로 업데이트됩니다. 자세한 내용은 사용 가능한 GKE 버전을 참조하세요.

클러스터 리소스 사용량

Cloud Run for Anthos를 처음 설치할 때는 클러스터에 대략 1.5개의 가상 CPU와 1GB 메모리가 필요합니다. 클러스터의 노드 수는 Cloud Run for Anthos 설치의 공간 및 메모리 요구사항에 영향을 주지 않습니다.

Activator는 최대 1,000milliCPU 및 600MiB RAM으로 요청을 소비할 수 있습니다. 기존 Activator가 새로 추가되는 요청 개수를 지원할 수 없으면 추가 Activator가 가동되고 이를 위해서는 300 milliCPU 및 60 MiB RAM 예약이 필요합니다.

Cloud Run for Anthos 서비스로 생성되는 모든 Pod는 요청 동시성 제한을 적용하는 큐 프록시 사이드카를 만듭니다. 큐 프록시는 25 milliCPU를 예약하며 메모리 예약은 없습니다. 큐 프록시의 소비는 큐에 입력되는 요청 수 그리고 요청 크기에 따라 달라집니다. 소비할 수 있는 CPU 및 메모리 리소스에는 제한이 없습니다.

서비스 만들기

Cloud Run for Anthos 서비스 아키텍처를 보여주는 다이어그램
Cloud Run for Anthos 서비스 아키텍처(확대하려면 클릭)

Cloud Run for Anthos는 커스텀 리소스 정의(CRD) 집합인 서비스, 버전, 구성, 경로를 정의하여 Kubernetes를 확장합니다. 이러한 CRD는 클러스터에서 애플리케이션의 작동 방식을 정의하고 제어합니다.

  • Cloud Run for Anthos 서비스는 Cloud Run for Anthos에서 정의되는 최상위 커스텀 리소스입니다. 워크로드의 전체 수명 주기를 관리하는 단일 애플리케이션입니다. 서비스는 서비스를 업데이트할 때마다 앱에 경로, 구성 및 새 버전이 포함되는지 확인합니다.
  • 버전은 변경될 수 없도록 코드 및 구성이 포함된 특정 시점의 스냅샷입니다.
  • 구성은 최신 버전에 대한 현재 설정을 유지 관리하고 모든 이전 버전의 내역을 기록합니다. 구성을 수정하면 새 버전이 생성됩니다.
  • 경로는 HTTP 엔드포인트를 정의하고 요청이 전달되는 하나 이상의 대상 버전에 연결합니다.

사용자가 Cloud Run for Anthos 서비스를 만들면 다음 결과가 발생합니다.

  1. Cloud Run for Anthos 서비스 객체가 다음 항목을 정의합니다.

    1. 버전 제공 방법에 대한 구성
    2. 이 서비스 버전에 대한 변경될 수 없는 버전
    3. 버전에 대한 지정된 트래픽 할당을 관리하는 경로
  2. 경로 객체는 VirtualService를 만듭니다. VirtualService 객체는 게이트웨이 트래픽을 올바른 버전으로 라우팅하도록 인그레스 게이트웨이 및 클러스터 로컬 게이트웨이를 구성합니다.

  3. 버전 객체는 제어 영역 구성요소인 Kubernetes 서비스 객체와 배포 객체를 만듭니다.

  4. 네트워크 구성은 앱의 Activator, 자동 확장 처리, 부하 분산기를 연결합니다.

요청 처리

다음 다이어그램은 샘플 Google Kubernetes Engine 클러스터의 Cloud Run for Anthos 데이터 영역 구성요소를 통해 사용자 트래픽에 사용 가능한 요청 경로를 개략적으로 보여줍니다.

Cloud Run for Anthos 클러스터 아키텍처를 보여주는 다이어그램
Cloud Run for Anthos 클러스터 아키텍처(확대하려면 클릭)

다음 다이어그램은 위 다이어그램을 확장하여 사용자 트래픽의 요청 경로를 자세히 보여줍니다. 자세한 내용은 아래 설명을 참조하세요.

Cloud Run for Anthos 요청 경로를 보여주는 다이어그램
Cloud Run for Anthos 요청 경로(확대하려면 클릭)

Cloud Run for Anthos 요청 경로의 경우:

  1. 트래픽 도착 경로:

    • 클러스터 외부의 트래픽용 인그레스 게이트웨이
    • 클러스터 내부의 트래픽용 클러스터 로컬 게이트웨이
  2. 트래픽 라우팅 규칙을 지정하는 VirtualService 구성요소는 사용자 트래픽이 올바른 버전으로 라우팅되도록 게이트웨이를 구성합니다.

  3. 제어 영역 구성요소인 Kubernetes 서비스는 Pod 가용성에 따라 트래픽 처리를 위한 요청 경로의 다음 단계를 결정합니다.

    • 버전에 Pod가 없는 경우:

      1. Activator가 수신된 요청을 일시적으로 큐에 넣고 Pod를 더 확장하도록 자동 확장 처리에 측정항목을 푸시합니다.
      2. 자동 확장 처리가 배포에서 원하는 Pod 상태로 확장합니다.
      3. 배포가 추가 요청을 수신하기 위해 Pod를 더 만듭니다.
      4. Activator가 큐 프록시 사이드카에 요청을 다시 시도합니다.
    • 서비스가 수평 확장되면(Pod 사용 가능) Kubernetes 서비스가 큐 프록시 사이드카에 요청을 전송합니다.

  4. 큐 프록시 사이드카는 컨테이너가 한 번에 처리할 수 있는 요청 큐 매개변수, 단일 또는 멀티 스레드 요청을 적용합니다.

  5. 큐 프록시 사이드카에 처리할 수 있는 것보다 요청이 많으면 자동 확장 처리가 추가 요청 처리를 위해 Pod를 더 만듭니다.

  6. 큐 프록시 사이드카가 트래픽을 사용자 컨테이너로 전송합니다.