현대화를 위한 구성 업데이트

이 문서에서는 메시를 ISTIOD 컨트롤 플레인에서 TRAFFIC_DIRECTOR 컨트롤 플레인으로 현대화하기 전에 관리형 Cloud Service Mesh에 적용해야 할 수 있는 구성 업데이트를 설명합니다.

다음은 클러스터 현대화를 위해 클러스터를 준비하는 데 필요한 구성 업데이트 목록입니다. 업데이트 안내는 각 섹션을 참고하세요.

현대화 워크플로에 관한 자세한 내용은 관리형 컨트롤 플레인 현대화 페이지를 참고하세요.

Istio 보안 비밀에서 multicluster_mode로 마이그레이션

클러스터에서 TRAFFIC_DIRECTOR 컨트롤 플레인을 사용하는 경우 멀티 클러스터 보안 비밀은 지원되지 않습니다. 이 문서에서는 Istio 멀티 클러스터 보안 비밀 사용에서 multicluster_mode 사용으로 현대화하는 방법을 설명합니다.

Istio 보안 비밀과 선언적 API 개요

오픈소스 Istio 멀티 클러스터 엔드포인트 검색은 istioctl 또는 기타 도구를 사용하여 클러스터에 Kubernetes 보안 비밀을 만드는 방식으로 작동합니다. 이 보안 비밀을 사용하면 클러스터가 메시의 다른 클러스터로 트래픽 부하를 분산할 수 있습니다. 그러면 ISTIOD 컨트롤 플레인에서 이 보안 비밀을 읽고 다른 클러스터로 트래픽 라우팅을 시작합니다.

Cloud Service Mesh에는 Istio 보안 비밀을 직접 만드는 대신 멀티 클러스터 트래픽을 제어하는 선언적 API가 있습니다. 이 API는 Istio 보안 비밀을 구현 세부정보로 취급하며 Istio 보안 비밀을 수동으로 만드는 것보다 안정적입니다. 향후 Cloud Service Mesh 기능은 선언적 API에 종속되며 Istio 보안 비밀로 이러한 새 기능을 직접 사용할 수 없습니다. 선언적 API는 앞으로 지원되는 유일한 경로입니다.

Istio 보안 비밀을 사용하는 경우 선언적 API를 사용하는 것으로 최대한 빨리 마이그레이션하세요. multicluster_mode 설정은 각 클러스터가 메시의 다른 모든 클러스터로 트래픽을 전달하도록 지시합니다. 보안 비밀을 사용하면 더 유연하게 구성할 수 있으므로 각 클러스터에 대해 메시에서 트래픽을 전달할 다른 클러스터를 구성할 수 있습니다. 선언적 API와 Istio 보안 비밀의 지원되는 기능 간의 차이점의 전체 목록은 Istio API를 사용하는 지원 기능을 참고하세요.

Istio 보안 비밀에서 선언적 API로 마이그레이션

Fleet 기능 API를 사용하여 자동 관리를 통해 Cloud Service Mesh를 프로비저닝한 경우 이 안내를 따르지 않아도 됩니다. 이 단계는 asmcli --managed를 사용하여 온보딩한 경우에만 적용됩니다.

이 프로세스는 클러스터를 가리키는 보안 비밀을 변경합니다. 이 과정에서 엔드포인트가 삭제되었다가 다시 추가됩니다. 엔드포인트가 삭제되고 추가되는 사이에 트래픽이 다른 클러스터로 부하 분산되는 대신 잠시 로컬 라우팅으로 되돌아갑니다. 자세한 내용은 GitHub 문제를 참고하세요.

Istio 보안 비밀 사용에서 선언적 API로 전환하려면 다음 단계를 따르세요. 다음 단계를 동시에 또는 연속으로 실행합니다.

  1. multicluster_mode=connected를 설정하여 멀티 클러스터 엔드포인트 검색을 사용 설정하려는 Fleet의 각 클러스터에 선언적 API를 사용 설정합니다. 클러스터를 검색할 수 없도록 하려면 multicluster_mode=disconnected를 명시적으로 설정해야 합니다.

    다음 명령어를 사용하여 멀티 클러스터 엔드포인트 검색을 위한 클러스터를 선택합니다.

     kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'

    다음 명령어를 사용하여 클러스터에서 엔드포인트 검색을 선택 해제합니다.

     kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'

  2. 이전 보안 비밀을 삭제합니다.

    클러스터에서 multicluster_mode=connected를 설정하면 각 클러스터에 multicluster_mode=connected가 설정된 다른 모든 클러스터에 대해 새 보안 비밀이 생성됩니다. 보안 비밀은 istio-system 네임스페이스에 배치되며 다음 형식입니다.

    istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS

    각 보안 비밀에 istio.io/owned-by: mesh.googleapis.com 라벨도 적용됩니다.

    새 보안 비밀이 생성되면 istioctl create-remote-secret으로 수동으로 만든 보안 비밀을 삭제할 수 있습니다.

    kubectl delete secret SECRET_NAME -n istio-system

마이그레이션이 완료되면 요청 측정항목을 확인하여 예상대로 라우팅되는지 확인합니다.

GKE용 워크로드 아이덴티티 제휴 사용 설정

워크로드 아이덴티티 제휴는 Google Kubernetes Engine 워크로드에 권장되는 안전한 방법입니다. 이를 통해 Compute Engine, BigQuery, Machine Learning API와 같은 Google Cloud 서비스에 액세스할 수 있습니다. 워크로드 아이덴티티 제휴는 IAM 정책을 사용하므로 수동 구성이나 서비스 계정 키 파일과 같은 보안 수준이 낮은 방법이 필요하지 않습니다. 워크로드 아이덴티티 제휴에 관한 자세한 내용은 GKE용 워크로드 아이덴티티 제휴 작동 방식을 참고하세요.

다음 섹션에서는 워크로드 아이덴티티 제휴를 사용 설정하는 방법을 설명합니다.

클러스터에서 워크로드 아이덴티티 제휴 사용 설정

  1. 클러스터에 워크로드 아이덴티티 제휴가 사용 설정되어 있는지 확인합니다. 이렇게 하려면 IAM 사용자 인증 정보 유효성 검사에 필수적인 워크로드 아이덴티티 제휴 풀이 GKE 클러스터에 구성되어 있는지 확인합니다.

    다음 명령어를 사용하여 클러스터에 설정된 워크로드 ID 풀을 확인합니다.

    gcloud container clusters describe CLUSTER_NAME \
  --format="value(workloadIdentityConfig.workloadPool)"

    CLUSTER_NAME을 GKE 클러스터 이름으로 바꿉니다. gcloud의 기본 영역 또는 리전을 아직 지정하지 않았으면 이 명령어를 실행할 때 --region 또는 --zone 플래그를 지정해야 할 수도 있습니다.

  2. 출력이 비어 있으면 기존 클러스터 업데이트의 안내에 따라 기존 GKE 클러스터에서 워크로드 ID를 사용 설정합니다.

노드 풀에서 워크로드 아이덴티티 제휴 사용 설정

클러스터에서 워크로드 아이덴티티 제휴를 사용 설정한 후에는 GKE 메타데이터 서버를 사용하도록 노드 풀을 구성해야 합니다.

  1. Standard 클러스터의 모든 노드 풀을 나열합니다. gcloud container node-pools list 명령어를 실행합니다.

    gcloud container node-pools list --cluster CLUSTER_NAME

    CLUSTER_NAME을 GKE 클러스터 이름으로 바꿉니다. gcloud의 기본 영역 또는 리전을 아직 지정하지 않았으면 이 명령어를 실행할 때 --region 또는 --zone 플래그를 지정해야 할 수도 있습니다.

  2. 각 노드 풀이 GKE 메타데이터 서버를 사용하고 있는지 확인합니다.

    gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"

    다음을 바꿉니다.

    • NODEPOOL_NAME을 노드 풀 이름으로 바꿉니다.
    • CLUSTER_NAME을 GKE 클러스터 이름으로 바꿉니다.

  3. 출력에 GKE_METADATA가 포함되지 않으면 기존 노드 풀 업데이트 가이드를 사용하여 노드 풀을 업데이트합니다.

관리형 컨테이너 네트워크 인터페이스(CNI) 사용 설정

이 섹션에서는 Google Kubernetes Engine에서 Cloud Service Mesh에 관리형 CNI를 사용 설정하는 방법을 안내합니다.

관리형 CNI 개요

관리형 컨테이너 네트워크 인터페이스(CNI)는 Istio CNI의 Google 관리 구현입니다. CNI 플러그인은 iptables 규칙을 구성하여 포드 네트워킹을 간소화합니다. 이렇게 하면 애플리케이션과 Envoy 프록시 간에 트래픽 리디렉션이 가능해져 iptables를 관리하는 데 필요한 init-container에 대한 권한이 필요하지 않게 됩니다.

Istio CNI 플러그인이 istio-init 컨테이너를 대체합니다. 이전에는 istio-init 컨테이너가 Istio 사이드카의 트래픽 가로채기를 사용 설정하기 위해 포드의 네트워크 환경을 설정하는 역할을 했습니다. CNI 플러그인은 동일한 네트워크 리디렉션 함수를 수행하지만 승격된 권한의 필요성을 줄여 보안을 강화하는 추가 이점이 있습니다.

따라서 보안 및 안정성을 강화하고 관리 및 문제 해결을 간소화하려면 모든 관리형 Cloud Service Mesh 배포에서 관리형 CNI가 필요합니다.

init 컨테이너에 미치는 영향

init 컨테이너는 설정 태스크를 위해 애플리케이션 컨테이너 전에 실행되는 특수화된 컨테이너입니다. 설정 태스크에는 구성 파일 다운로드, 외부 서비스와 통신, 적용 전 초기화 수행과 같은 태스크가 포함될 수 있습니다. 클러스터에서 관리형 CNI가 사용 설정된 경우 네트워크 액세스를 사용하는 init 컨테이너에 문제가 발생할 수 있습니다.

관리형 CNI를 사용한 포드 설정 프로세스는 다음과 같습니다.

  1. CNI 플러그인은 포드 네트워크 인터페이스를 설정하고 포드 IP를 할당하며 아직 시작되지 않은 Istio 사이드카 프록시로 트래픽을 리디렉션합니다.
  2. 모든 init 컨테이너가 실행되고 완료됩니다.
  3. Istio 사이드카 프록시는 애플리케이션 컨테이너와 함께 시작됩니다.

따라서 init 컨테이너가 아웃바운드 네트워크 연결을 시도하거나 메시 내의 서비스에 연결하려고 하면 init 컨테이너의 네트워크 요청이 삭제되거나 잘못 라우팅될 수 있습니다. 이는 요청이 있을 때 포드의 네트워크 트래픽을 관리하는 Istio 사이드카 프록시가 실행되지 않기 때문입니다. 자세한 내용은 Istio CNI 문서를 참고하세요.

클러스터에 관리형 CNI 사용 설정

클러스터에서 관리형 CNI를 사용 설정하려면 이 섹션의 단계를 따르세요.

  1. init 컨테이너에서 네트워크 종속 항목을 삭제합니다. 다음 대안을 고려해 보세요.

    • 애플리케이션 로직 또는 컨테이너 수정: 사이드카 프록시가 시작된 후 네트워크 요청이 필요하거나 애플리케이션 컨테이너 내에서 네트워크 작업을 수행하는 init 컨테이너에 대한 종속 항목을 삭제하도록 서비스를 수정할 수 있습니다.
    • Kubernetes ConfigMap 또는 보안 비밀 사용: 네트워크 요청에서 가져온 구성 데이터를 Kubernetes ConfigMap 또는 보안 비밀에 저장하고 애플리케이션 컨테이너에 마운트합니다. 대체 솔루션은 Istio 문서를 참고하세요.

  2. 클러스터에서 관리형 CNI를 사용 설정합니다.

    1. 다음과 같이 구성을 변경합니다.

      1. 다음 명령어를 실행하여 controlPlaneRevision을 찾습니다. 

        kubectl get controlplanerevision -n istio-system

      2. ControlPlaneRevision(CPR) 커스텀 리소스(CR)에서 라벨 mesh.cloud.google.com/managed-cni-enabled를 true로 설정합니다.

        kubectl label controlplanerevision CPR_NAME -n istio-system mesh.cloud.google.com/managed-cni-enabled=true --overwrite

        CPR_NAME을 이전 단계의 출력에서 NAME 열 아래의 값으로 바꿉니다.

      3. asm-options ConfigMap에서 ASM_OPTS 값을 CNI=on으로 설정합니다.

        kubectl patch configmap asm-options -n istio-system -p '{"data":{"ASM_OPTS":"CNI=on"}}'

      4. ControlPlaneRevision(CPR) 커스텀 리소스(CR)에서 라벨 mesh.cloud.google.com/force-reprovision을 true로 설정합니다. 이 작업은 컨트롤 플레인 재시작을 트리거합니다.

        kubectl label controlplanerevision CPR_NAME -n istio-system mesh.cloud.google.com/force-reprovision=true --overwrite

    2. 기능 상태를 확인합니다. 다음 명령어를 사용하여 기능 상태를 가져옵니다.

      gcloud container fleet mesh describe --project FLEET_PROJECT_ID

      FLEET_PROJECT_ID를 Fleet 호스트 프로젝트의 ID로 바꿉니다. 일반적으로 FLEET_PROJECT_ID의 이름은 프로젝트와 동일합니다.

      • MANAGED_CNI_NOT_ENABLED 조건이 servicemesh.conditions에서 삭제되었는지 확인합니다.
      • 상태가 업데이트되는 데 최대 15~20분이 걸릴 수 있습니다. 몇 분 정도 기다린 후 명령어를 다시 실행해 보세요.

    3. 클러스터의 기능에서 controlPlaneManagement.state가 Active가 되면 포드를 다시 시작합니다.

지원되지 않는 바이너리 사용에서 전환

TRAFFIC_DIRECTOR 컨트롤 플레인은 distroless 이미지 유형만 지원합니다. 이 섹션에서는 배포를 이 이미지 유형과 호환되도록 하는 방법을 제안합니다.

Distroless Envoy 프록시 사이드카 이미지

Cloud Service Mesh는 컨트롤 플레인 구성에 따라 두 가지 유형의 Envoy 프록시 사이드카 이미지(다양한 바이너리가 포함된 Ubuntu 기반 이미지 및 Distroless 이미지)를 사용합니다. Distroless 기본 이미지는 필수 구성요소만 포함하여 보안 및 리소스 최적화에 우선순위를 두는 최소 컨테이너 이미지입니다. 취약점을 방지하기 위해 공격 표면이 줄어듭니다. 자세한 내용은 Distroless 프록시 이미지 문서를 참고하세요.

현대화 및 바이너리 호환성

현대화의 일환으로 Cloud Service Mesh는 distroless 사이드카 이미지로 전환하고 있습니다. 이 이미지는 최소한의 종속 항목 세트를 보유하고 있으며, 모든 비필수 실행 파일, 라이브러리, 디버깅 도구가 제거됩니다. 따라서 컨테이너 내에서 셸 명령어를 실행하거나 curl, ping 또는 kubectl exec와 같은 기타 디버그 유틸리티를 사용할 수 없습니다.

클러스터를 현대화하려면 현재 사용량이 distroless 사이드카 이미지와 호환되어야 합니다.

클러스터를 distroless 이미지와 호환되도록 만들기

  • 구성에서 지원되지 않는 바이너리(예: bash 또는 curl)에 대한 참조를 삭제합니다. 특히 준비, 시작, 활성 프로브 내부와 istio-proxy, istio-init 또는 istio-validation 컨테이너 내의 Lifecycle PostStart 및 PreStop 후크 내부에서 삭제합니다.
  • 특정 사용 사례의 경우 holdApplicationUntilProxyStarts와 같은 대안을 고려하세요.
  • 디버깅의 경우 임시 컨테이너를 사용하여 실행 중인 워크로드 포드에 연결할 수 있습니다. 그런 다음 이를 검사하고 커스텀 명령어를 실행할 수 있습니다. 예시는 Cloud Service Mesh 로그 수집을 참고하세요.

특정 사용 사례에 대한 해결 방법을 찾을 수 없는 경우 지원 받기에서 Google Cloud지원팀에 문의하세요.