Apigee Hybrid를 버전 1.9로 업그레이드

이 절차에서는 Apigee Hybrid 버전 1.8.x에서 Apigee Hybrid 버전 1.9.4로 업그레이드하고 이전 출시 버전인 Hybrid 1.9.x에서 버전 1.9.4로 업그레이드하는 작업을 다룹니다.

부 버전 업그레이드(예: 버전 1.8에서 1.9로)와 패치 출시 버전 업그레이드(예: 1.9.0에서 1.9.4로)에 동일한 절차를 사용합니다.

Apigee Hybrid 버전 1.7 이하에서 업그레이드하는 경우 먼저 Hybrid 버전 1.8로 업그레이드한 후에 버전 1.9.4로 업그레이드해야 합니다. Apigee Hybrid를 버전 1.8로 업그레이드의 안내를 참조하세요.

Apigee Hybrid는 버전 1.9.0부터 Apigee 인그레스 게이트웨이만 인그레스 레이어로 지원합니다.

버전 1.9.4로 업그레이드 개요

Apigee Hybrid 업그레이드 절차는 다음과 같은 섹션으로 정리됩니다.

1. 업그레이드를 준비합니다.
2. Hybrid 런타임 버전 1.9.4를 설치합니다.

기본 요건

• 이 업그레이드 안내에서는 Apigee Hybrid 버전 1.8.x가 설치되어 있고 버전 1.9.4로 업그레이드하려고 한다고 가정합니다. 이전 버전에서 업데이트하는 경우 Apigee Hybrid를 버전 1.8로 업그레이드 안내를 참조하세요.
• Apigee Hybrid 버전 1.8에서는 Apigee 인그레스 게이트웨이를 Anthos Service Mesh의 대체 인그레스 레이어로 도입했습니다. Apigee Hybrid는 버전 1.9.0부터 Apigee 인그레스 게이트웨이를 사용해야 하며 더 이상 인그레스에 Anthos Service Mesh 사용을 지원하지 않습니다. 업그레이드하는 설치에서 Anthos Service Mesh를 사용하는 경우 먼저 Apigee 인그레스 게이트웨이를 사용하도록 마이그레이션한 후에 버전 1.9.4로 업그레이드해야 합니다.

  Apigee 인그레스 게이트웨이는 인그레스 게이트웨이에 Anthos Service Mesh 기능 중 일부를 사용합니다. 이러한 기능의 관리와 업그레이드는 Apigee Hybrid에서 자동으로 처리합니다. 따라서 Apigee Hybrid 인그레스 게이트웨이를 설치, 업그레이드, 관리하는 데 Anthos Service Mesh에 대한 전문 지식이 필요하지 않습니다.

  자세한 안내는 하이브리드 v1.8 문서의 Apigee 인그레스 게이트웨이로 마이그레이션을 참조하세요.

버전 1.9로 업그레이드 준비

하이브리드 설치 백업(권장)

1. 이 안내에서는 apigeectl을 설치한 파일 시스템에서 디렉터리의 환경 변수 APIGEECTL_HOME을 사용합니다. 필요한 경우 디렉터리를 apigeectl 디렉터리로 변경하고 다음 명령어를 사용하여 변수를 정의합니다.

   Linux

   export APIGEECTL_HOME=$PWD
   echo $APIGEECTL_HOME

   MacOS

   export APIGEECTL_HOME=$PWD
   echo $APIGEECTL_HOME

   Windows

   set APIGEECTL_HOME=%CD%
   echo %APIGEECTL_HOME%

2. 버전 1.8 $APIGEECTL_HOME/ 디렉터리의 백업 사본을 만듭니다. 예를 들면 다음과 같습니다.

   tar -czvf $APIGEECTL_HOME/../apigeectl-v1.8-backup.tar.gz $APIGEECTL_HOME

3. Cassandra 백업 및 복구의 안내에 따라 Cassandra 데이터베이스를 백업합니다.

Apigee 런타임의 서비스 계정에 Cloud Trace 에이전트 역할을 추가 (선택사항)

선택사항: Cloud Trace를 사용할 계획이고 Hybrid v1.8 설치에 Cloud Trace Agent 역할을 아직 추가하지 않은 경우 Apigee 런타임 서비스의 서비스 계정에 Cloud Trace 에이전트 Google Cloud IAM 역할(roles/cloudtrace.agent)이 있는지 확인하세요.

프로덕션 환경에서 런타임 서비스 계정은 apigee-runtime입니다. 비프로덕션 환경의 경우 런타임 서비스 계정은 apigee-non-prod입니다.

Cloud 콘솔 > IAM 및 관리자 > 서비스 계정 UI에서 또는 다음 명령어를 사용하여 이 작업을 수행할 수 있습니다.

1. 다음 명령어를 사용하여 서비스 계정의 이메일 주소를 가져옵니다.

   프로덕션

   gcloud iam service-accounts list --filter "apigee-runtime"

   이메일 주소가 apigee-runtime@$ORG_NAME.iam.gserviceaccount.com 패턴과 일치하면 다음 단계에서 이 패턴을 사용할 수 있습니다.

   비프로덕션

   gcloud iam service-accounts list --filter "apigee-non-prod"

   apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com 패턴과 일치하면 다음 단계에서 이 패턴을 사용할 수 있습니다.

2. 서비스 계정에 Cloud Trace 에이전트 역할을 할당합니다.

   프로덕션

   gcloud projects add-iam-policy-binding $PROJECT_ID \
       --member="serviceAccount:apigee-runtime@$PROJECT_ID.iam.gserviceaccount.com" \
       --role="roles/cloudtrace.agent"

   비프로덕션

   gcloud projects add-iam-policy-binding $PROJECT_ID \
       --member="serviceAccount:apigee-non-prod@$PROJECT_ID.iam.gserviceaccount.com" \
       --role="roles/cloudtrace.agent"

   예

   gcloud projects add-iam-policy-binding hybrid-example-project \
       --member="serviceAccount:apigee-runtime@hybrid-example-project.iam.gserviceaccount.com" \
       --role="roles/cloudtrace.agent"

   여기서 $PROJECT_ID는 Apigee Hybrid가 설치된 Google Cloud 프로젝트의 이름입니다.

설치에서 Anthos Service Mesh를 사용하는 경우 Apigee 인그레스 게이트웨이 설치

Apigee Hybrid는 버전 1.9부터 인그레스에 Anthos Service Mesh 사용을 더 이상 지원하지 않습니다. Hybrid 설치에서 Anthos Service Mesh를 사용하는 경우 Hybrid 버전 1.9를 설치하기 전에 현재 설치를 Apigee 인그레스 게이트웨이로 마이그레이션해야 합니다.

1. ingressGateways 속성을 재정의 파일에 추가합니다.

   구문

     ingressGateways:
     - name: INGRESS_NAME
       replicaCountMin: REPLICAS_MIN
       replicaCountMax: REPLICAS_MAX
       resources:
         requests:
           cpu: CPU_COUNT_REQ
           memory: MEMORY_REQ
         limits:
           cpu: CPU_COUNT_LIMIT
           memory: MEMORY_LIMIT
       svcAnnotations:  # optional.
         SVC_ANNOTATIONS_KEY: SVC_ANNOTATIONS_VALUE
       svcLoadBalancerIP: SVC_LOAD_BALANCER_IP # optional

   예

     ingressGateways:
     - name: prod1
       replicaCountMin: 2
       replicaCountMax: 100
       resources:
         requests:
           cpu: 1
           memory: 1Gi
         limits:
           cpu: 2
           memory: 2Gi
       svcAnnotations:  # optional. See Known issue 243599452.
         networking.gke.io/load-balancer-type: "Internal"
       svcLoadBalancerIP: 198.252.0.123 

   • INGRESS_NAME은 인그레스 게이트웨이 배포의 이름입니다. 다음 요구사항을 충족하는 이름이면 됩니다.
     • 최대 길이는 17자(영문 기준)입니다.
     • 소문자 영숫자 문자, '-' 또는 '.'만 포함해야 합니다.
     • 영숫자 문자로 시작해야 합니다.
     • 영숫자 문자로 끝나야 합니다.
     구성 속성 참조의 ingressGateways[].name을 참조하세요.
   • REPLICAS_MIN 및 REPLICAS_MAX: 설치에서 Apigee 인그레스 게이트웨이의 최소 및 최대 복제본 수입니다. 자세한 내용과 기본 설정은 구성 속성 참조의 ingressGateways[].replicaCountMin 및 ingressGateways[].replicaCountMax를 참조하세요.
   • CPU_COUNT_REQ 및 MEMORY_REQ: 설치에서 Apigee 인그레스 게이트웨이의 각 복제본에 대한 CPU 및 메모리 요청입니다.

     자세한 내용과 기본 설정은 구성 속성 참조의 ingressGateways[].resources.requests.cpu 및 ingressGateways[].resources.requests.memory를 참조하세요.

   • CPU_COUNT_LIMIT 및 MEMORY_LIMIT: 설치에서 Apigee 인그레스 게이트웨이의 각 복제본에 대한 최대 CPU 및 메모리 한도입니다

     자세한 내용과 기본 설정은 구성 속성 참조의 ingressGateways[].resources.limits.cpu 및 ingressGateways[].resources.limits.memory를 참조하세요.

   • SVC_ANNOTATIONS_KEY SVC_ANNOTATIONS_VALUE(선택사항):

     기본 인그레스 서비스의 주석을 제공하는 키-값 쌍입니다. 주석은 부하 분산기 유형을 내부 또는 외부로 설정하는 등, 클라우드 플랫폼에서 하이브리드 설치를 구성하는 데 사용됩니다. 예를 들면 다음과 같습니다.

     ingressGateways:
         svcAnnotations:
           networking.gke.io/load-balancer-type: "Internal"

     주석은 플랫폼마다 다릅니다. 필수 및 추천 주석은 플랫폼 문서를 참조하세요.

     구성 속성 참조의 ingressGateways[].svcAnnotations를 참조하세요.
   • SVC_LOAD_BALANCER_IP (선택사항) 부하 분산기에 고정 IP 주소를 할당할 수 있습니다. 부하 분산기 IP 주소 지정을 지원하는 플랫폼에서 이 IP 주소로 부하 분산기가 생성됩니다. 부하 분산기 IP 주소를 지정할 수 없는 플랫폼에서 이 속성은 무시됩니다.

     부하 분산기에 할당된 고정 IP 주소가 없으면 이 속성을 재정의 파일에서 제외하세요.

     구성 속성 참조의 ingressGateways[].svcLoadBalancerIP를 참조하세요.
2. 다음 명령어를 사용하여 변경사항을 적용하여 Apigee 인그레스 게이트웨이를 설치합니다.

   $APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml

3. Apigee 인그레스 게이트웨이를 노출합니다. Apigee 인그레스 게이트웨이 노출의 절차를 따릅니다.
4. 프록시를 호출하여 새 인그레스 게이트웨이를 테스트합니다. 현재 배포된 모든 중요 프록시를 테스트하는 것이 가장 좋습니다.
5. 트래픽을 전환하려면 새 Apigee 인그레스 게이트웨이의 IP 주소를 가리키도록 DNS 레코드를 업데이트합니다. DNS 제공업체에 따라 트래픽을 새 엔드포인트로 점진적으로 이동할 수 있습니다. 팁: 다음 명령어를 사용하여 Apigee 인그레스 게이트웨이의 외부 IP 주소를 찾을 수 있습니다.

   kubectl get svc -n apigee -l app=apigee-ingressgateway

   다음과 비슷한 결과가 출력됩니다.

   NAME                                        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                      AGE
   apigee-ingressgateway-prod-hybrid-37a39bd   LoadBalancer   192.0.2.123   233.252.0.123   15021:32049/TCP,80:31624/TCP,443:30723/TCP   16h

6. 대시보드를 모니터링하여 모든 런타임 트래픽이 작동하는지 확인합니다. 모든 것이 예상대로 작동하는 경우에만 다음 단계로 진행합니다. 이전 인그레스 게이트웨이(Anthos Service Mesh)를 통과하는 트래픽이 없는지 확인합니다. DNS 캐싱으로 인해 DNS 업데이트 전파 속도가 느릴 수 있습니다.
7. Apigee가 Anthos Service Mesh에 구성을 제공하지 않도록 하려면 Apigee 인그레스 게이트웨이 관리 가이드에서 ASM에 구성 제공 중지에 있는 단계를 따르세요.
8. API 프록시 트래픽을 다시 테스트하고 모니터링합니다.
9. Anthos Service Mesh 문서의 안내에 따라 클러스터에서 Anthos Service Mesh를 제거합니다.

Hybrid 1.9.4 런타임 설치

1. 하이브리드 기본 디렉터리(apigeectl 실행 파일이 있는 디렉터리의 상위 디렉터리)에 있는지 확인합니다.

   cd $APIGEECTL_HOME/..

2. 다음 명령어를 사용하여 운영체제용 출시 버전 패키지를 다운로드합니다. 다음 테이블에서 플랫폼을 선택해야 합니다.

   Linux

   Linux 64비트:

   curl -LO \
     https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.9.4/apigeectl_linux_64.tar.gz

   MacOS

   Mac 64비트:

   curl -LO \
     https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.9.4/apigeectl_mac_64.tar.gz

   Windows

   Windows 64 비트:

   curl -LO ^
     https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.9.4/apigeectl_windows_64.zip

3. 현재 apigeectl/ 디렉터리의 이름을 백업 디렉터리 이름으로 바꿉니다. 예를 들면 다음과 같습니다.

   Linux

   mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.8/

   MacOS

   mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.8/ 

   Windows

   rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.8 

4. 다운로드한 gzip 파일 콘텐츠를 Hybrid 기본 디렉터리에 추출합니다. Hybrid 기본 디렉터리는 이름이 변경된 apigeectl-v1.8 디렉터리가 있는 디렉터리입니다.

   Linux

   tar xvzf filename.tar.gz -C ./

   MacOS

   tar xvzf filename.tar.gz -C ./

   Windows

   tar xvzf filename.zip -C ./

5. tar 콘텐츠는 기본적으로 이름에 해당 버전과 플랫폼이 포함된 디렉터리로 확장됩니다. 예를 들면 ./apigeectl_1.9.4-xxxxxxx_linux_64입니다. 다음 명령어를 사용하여 디렉터리 이름을 apigeectl로 변경합니다.

   Linux

   mv apigeectl_1.9.4-xxxxxxx_linux_64 apigeectl

   MacOS

   mv apigeectl_1.9.4-xxxxxxx_mac_64 apigeectl

   Windows

   rename apigeectl_1.9.4-xxxxxxx_windows_64 apigeectl

6. apigeectl 디렉터리로 변경합니다.

   cd ./apigeectl

   이 디렉터리는 apigeectl 홈 디렉터리입니다. 여기에 apigeectl 실행 가능한 명령어가 있습니다.

7. 이 안내에서는 apigeectl 유틸리티가 설치된 파일 시스템의 디렉터리에 환경 변수 $APIGEECTL_HOME을 사용합니다. 필요한 경우 디렉터리를 apigeectl 디렉터리로 변경하고 다음 명령어를 사용하여 변수를 정의합니다.

   Linux

   export APIGEECTL_HOME=$PWD

   echo $APIGEECTL_HOME

   MacOS

   export APIGEECTL_HOME=$PWD

   echo $APIGEECTL_HOME

   Windows

   set APIGEECTL_HOME=%CD%

   echo %APIGEECTL_HOME%

8. version 명령어를 사용하여 apigeectl의 버전을 확인합니다.

   ./apigeectl version

   Version: 1.9.4

9. hybrid-base-directory/hybrid-files 디렉터리로 이동합니다. hybrid-files 디렉터리에는 재정의 파일, 인증서, 서비스 계정과 같은 구성 파일이 있습니다. 예를 들면 다음과 같습니다.

   cd $APIGEECTL_HOME/../hybrid-files

10. 다음 명령어를 사용하여 kubectl이 올바른 컨텍스트로 설정되었는지 확인합니다. 현재 컨텍스트를 Apigee Hybrid를 업그레이드하는 클러스터로 설정해야 합니다.

    kubectl config get-contexts | grep \*

11. hybrid-files 디렉터리에서 다음을 수행합니다.
    1. 다음 기호화된 링크를 $APIGEECTL_HOME으로 업데이트합니다. 이러한 링크를 사용하면 hybrid-files 디렉터리 내에서 새로 설치된 apigeectl 명령어를 실행할 수 있습니다.

       ln -nfs $APIGEECTL_HOME/tools tools
       ln -nfs $APIGEECTL_HOME/config config
       ln -nfs $APIGEECTL_HOME/templates templates
       ln -nfs $APIGEECTL_HOME/plugins plugins

    2. 심볼릭 링크가 올바르게 생성되었는지 확인하려면 이 명령어를 실행하고 링크 경로가 올바른 위치를 가리키는지 확인합니다.

       ls -l | grep ^l

12. 테스트 실행 초기화를 수행하여 오류를 확인합니다.

    ${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client

    여기서 OVERRIDES_FILE은 재정의 파일 이름입니다(예: ./overrides/overrides.yaml).

13. 오류가 없으면 Hybrid 1.9.4를 초기화합니다.

    $APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE

14. 초기화 상태를 확인합니다.

    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    성공하면 다음과 같이 출력됩니다: All containers ready.

    kubectl describe apigeeds -n apigee

    출력에서 State: running을 찾습니다.

15. --dry-run 플래그를 사용하여 apply 명령어의 테스트 실행으로 오류가 있는지 확인합니다.

    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client

16. 오류가 없으면 재정의를 적용합니다. 설치에 따라 프로덕션 환경 또는 비프로덕션 환경의 안내를 선택하여 따릅니다.

    프로덕션

    프로덕션 환경의 경우 각 Hybrid 구성요소를 개별적으로 업그레이드하고 다음 구성요소로 진행하기 전에 업그레이드된 구성요소의 상태를 확인해야 합니다.

    1. 현재 위치가 hybrid-files 디렉터리인지 확인합니다.
    2. 재정의를 적용하여 Cassandra를 업그레이드합니다.

       $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore

    3. 완료를 확인합니다.

       $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

       포드가 준비된 경우에만 다음 단계로 진행합니다.

    4. 재정의를 적용하여 원격 분석 구성요소를 업그레이드하고 완료를 확인합니다.

       $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry

       $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    5. Redis 구성요소를 가져옵니다.

       $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis

    6. 재정의를 적용하여 조직 수준 구성요소(MART, Watcher, Apigee Connect)를 업그레이드하고 완료를 확인합니다.

       $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org

       $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    7. 재정의를 적용하여 환경을 업그레이드합니다. 다음 두 가지 중에서 선택할 수 있습니다.
       • 환경별 환경: 한 번에 하나의 환경에 재정의를 적용하고 완료를 확인합니다. 환경마다 이 단계를 반복합니다.

         $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME

         $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

         여기서 ENV_NAME은 업그레이드하는 환경의 이름입니다.

       • 한 번에 모든 환경: 한 번에 모든 환경에 재정의를 적용하고 완료 여부를 확인합니다.

         $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs

         $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    8. 재정의를 적용하여 virtualhosts 구성요소를 업그레이드하고 완료를 확인합니다.

       $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts

       $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    비프로덕션

    대부분의 비프로덕션, 데모 또는 실험용 환경에서는 모든 구성요소에 재정의를 한 번에 적용할 수 있습니다. 비프로덕션 환경이 크고 복잡하거나 프로덕션 환경을 비슷하게 모방하는 경우 프로덕션 환경 업그레이드 안내를 참조하세요.

    1. 현재 위치가 hybrid-files 디렉터리인지 확인합니다.
    2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE

    3. 상태를 파악합니다.

       $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

1.9.4-hotfix.1 설치

핫픽스 출시 버전 1.9.4-hotfix.1을 설치하려면 다음 단계를 따르세요.

1. 다음 단계를 수행하기 전에 Apigee Hybrid 버전 1.9.4 이상을 설치해야 합니다. 1.9.4 이상 버전이 설치되어 있지 않으면 진행하기 전에 1.9.4로 업그레이드합니다.
2. overrides.yaml 파일을 엽니다.
3. istiod 스탠자에서 이미지 태그 버전(있는 경우)을 버전 1.17.7로 변경합니다. 예를 들면 다음과 같습니다.

   istiod:
     image:
       url: "gcr.io/apigee-release/hybrid/apigee-asm-istiod"
       tag: "1.17.7-asm.0-distroless"

4. Apigee Hybrid 설치 방법에 따라 ingressGateway 또는 ingressGateways 스탠자를 사용할 수 있습니다. 재정의 파일에 표시되는 스탠자를 찾아 이미지 태그 버전(있는 경우)을 1.17.7 버전으로 변경합니다. 예를 들어 ingressGateway 스탠자가 있는 경우는 다음과 같습니다.

   ingressGateway:
     image:
       url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
       tag: "1.17.7-asm.0-distroless"

   또는 ingressGateways 스탠자가 있는 경우는 다음과 같습니다.

   ingressGateways:
     - name: gateway1
       image:
         url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
         tag: "1.17.7-asm.0-distroless"
       ...
     - name: gateway2
       image:
         url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
         tag: "1.17.7-asm.0-distroless"
       ...
     

5. 파일을 저장합니다.
6. 다음 명령어를 실행하여 istiod 구성요소를 초기화합니다.

   $APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE

   $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

7. 다음 명령어를 실행하여 Apigee 인그레스 구성요소에 변경사항을 적용합니다. 조직이 둘 이상인 경우 각 조직에 대해 이 명령어를 반복합니다.

   $APIGEECTL_HOME/apigeectl apply --org -f OVERRIDES_FILE

   $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

8. 포드 상태를 확인합니다.

   kubectl get pods -n YOUR_APIGEE_NAMESPACE

Kubernetes 버전 업그레이드

Kubernetes 플랫폼을 Hybrid 1.9에서 지원되는 버전으로 업그레이드합니다. 도움이 필요하면 플랫폼 문서를 참조하세요.

클릭하여 지원되는 플랫폼 목록 펼치기

	Apigee hybrid 버전
플랫폼	1.6 (3)	1.7 (3)	1.8 (3)	1.9	1.10
Anthos(Google Cloud - GKE)	1.19.x 1.20.x 1.21.x	1.20.x 1.21.x 1.22.x(≥ 1.7.2) 1.23.x(≥ 1.7.2)	1.21.x(≤ 1.8.3) 1.22.x(≤ 1.8.3) 1.23.x(≤ 1.8.4) 1.24.x(≥ 1.8.4) 1.25.x(≥ 1.8.4)	1.23.x 1.24.x 1.25.x 1.26.x (≥ 1.9.2)	1.24.x 1.25.x 1.26.x
Anthos(AWS)	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.12.x(≥ 1.7.2)	1.10.x 1.11.x 1.12.x 1.13.x 1.25(13)	1.12.x 1.13.x 1.25(13)	1.13.x 1.25(13) 1.26(13)
Anthos(Azure)	1.8.x	1.9.x 1.10.x 1.12.x(≥ 1.7.2)	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x	1.12.x 1.13.x 1.14.x	1.13.x 1.14.x 1.15.x
Anthos(온프레미스 - VMware)(1)	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x(4) 1.10.x(4) 1.11.x(4)(≥ 1.7.2) 1.12.x(4)(≥ 1.7.2)	1.10.x(4) 1.11.x(4) 1.12.x(4) (5) 1.13.x(5) 1.14.x(5) 1.15.x	1.12.x (4) 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
Anthos(베어메탈)(1)	1.7.x 1.8.2+ 1.9.3+ 1.10.x	1.9.x(4) 1.10.x(4) 1.11.x(4)(≥ 1.7.2) 1.12.x(4)(≥ 1.7.2)	1.10.x(4) 1.11.x(4) 1.12.x(4) (5) 1.13.x(5) 1.14.x(5) 1.15.x	1.12.x (4) 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
EKS(7)	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x(≥ 1.7.2) 1.23.x(≥ 1.7.2)	1.22.x(≤ 1.8.3) 1.23.x(≤ 1.8.4) 1.24.x(≥ 1.8.4) 1.25.x(≥ 1.8.4)	1.23.x 1.24.x 1.25.x 1.26.x (≥ 1.9.2)	1.24.x 1.25.x 1.26.x
AKS(7)	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x(≥ 1.7.2) 1.23.x(≥ 1.7.2)	1.22.x(≤ 1.8.3) 1.23.x(≤ 1.8.4) 1.24.x(≥ 1.8.4) 1.25.x(≥ 1.8.4)	1.23.x 1.24.x 1.25.x 1.26.x (≥ 1.9.2)	1.24.x 1.25.x 1.26.x
OpenShift(7)	4.6 4.7 4.8	4.7 4.8	4.8 4.9 4.10	4.10 4.11	4.11 4.12
Rancher Kubernetes Engine(RKE)(7)	해당 사항 없음	해당 사항 없음	해당 사항 없음	1.3.8	v1.26.2+rke2r1
구성요소	1.6 (3)	1.7 (3)	1.8	1.9	1.10
Anthos Service Mesh(ASM)	1.9.x 1.10.x 1.12.x 1.13.x	1.10.x 1.11.x 1.12.x 1.13.x (≥ 1.7.2) 1.14.x 1.15.x(≥ 1.7.6)	1.11.x 1.12.x 1.13.x 1.14.x 1.15.x	1.17.x(11)	1.17.x(11)
JDK	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.5.4	1.7.x	1.7.x 1.8.x 1.9.x 1.10.x 1.11.x	1.10.x 1.11.x	1.10.x 1.11.x 1.12.x
Cassandra	3.11.10	3.11.10	3.11.10	3.11.10	3.11.10
(1) Anthos 버전 1.8, 1.9, 1.10에서 cert-manager와 충돌을 방지하려면 다음 문서의 안내를 따르세요. Anthos 1.8.2 이상: 버전 1.8.2 이상으로 업그레이드하는 경우 cert-manager와 충돌 Anthos 1.9: 버전 1.9.0 또는 1.9.1로 업그레이드하는 경우 cert-manager와 충돌 Anthos 1.10+: cert-manager 설치 충돌. (2) Apigee Hybrid 버전 1.7.2 이상에서 지원 이용 가능 (3) Apigee Hybrid 버전 1.8 이하의 공식 EOL 날짜에 도달했습니다. 일반 월간 패치는 더 이상 제공되지 않습니다. 지속적인 지원에 대한 명시적인 공식 예외가 적용되는 고객을 제외하고 이 출시 버전은 더 이상 공식적으로 지원되지 않습니다. 다른 고객은 업그레이드해야 합니다. (4)베어메탈용 Anthos 및 VMWare 버전 1.12 이하는 지원되지 않습니다. 베어메탈용 Anthos 버전 지원 정책 및 VMware용 Anthos 클러스터 버전을 참조하세요. (5)VMware용 및 베어메탈용 Anthos에는 ASM 1.14 이상이 필요합니다. Hybrid v1.8로 업그레이드하고 하이브리드 클러스터에 더 이상 ASM을 설치할 필요가 없는 Apigee 인그레스 게이트웨이로 전환하는 것이 좋습니다. (6) Apigee Hybrid 버전 1.8.4 이상에서 지원 이용 가능 (7) 연결된 클러스터에는 Apigee ingressgateway를 사용하는 Apigee Hybrid v1.8 이상이 요구되지 않습니다. (8) Apigee Hybrid 버전 1.8.4 이상에서는 지원되지 않습니다. (9) Apigee Hybrid 버전 1.7.6 이상에서 지원 이용 가능 (10) Apigee Hybrid 버전 1.8.5 이상에서는 지원되지 않습니다. (11) ASM은 Apigee Hybrid 1.9 이상에 자동으로 설치됩니다. (12) Apigee Hybrid 버전 1.9.2 이상에서 지원 이용 가능 (13) 이제 AWS용 Anthos 클러스터(멀티 클라우드) 버전 번호에 Kubernetes 버전이 반영됩니다. 버전 세부정보 및 권장되는 패치는 Anthos 버전 및 업그레이드 지원을 참조하세요.

연결된 클러스터 정보

Apigee Hybrid 버전 1.7.x 이하를 사용하는 경우 Elastic Kubernetes Service(EKS), Azure Kubernetes Service(AKS) 또는 지원되는 다른 서드 파티 Kubernetes 서비스 공급업체의 멀티 클라우드 컨텍스트에서 Apigee Hybrid를 실행하려면 Anthos 연결 클러스터를 사용해야 합니다. 클러스터 연결을 사용하면 Google에서 Anthos Service Mesh(ASM) 사용량을 측정할 수 있습니다. 서드 파티 클러스터 등록은 선택사항입니다. Google Cloud console에서 연결된 클러스터를 보려는 경우에만 등록합니다. 자세한 내용은 Google Cloud에 서드 파티 Kubernetes 클러스터 연결을 참조하세요.

Apigee Hybrid 버전 1.8.x의 경우 인그레스 게이트웨이에 Anthos Service Mesh를 사용한다면 Anthos 연결 클러스터가 필요합니다. Apigee 인그레스 게이트웨이를 사용하는 경우 Anthos 연결 클러스터는 선택사항입니다.

업그레이드 롤백

이전 업그레이드를 롤백하려면 다음 단계를 따르세요.

1. 하이브리드 런타임 네임스페이스의 완료된 작업을 삭제합니다. 여기서 NAMESPACE는 재정의 파일에 지정된 네임스페이스(네임스페이스가 지정된 경우)입니다. 그렇지 않은 경우 기본 네임스페이스는 apigee입니다.

   kubectl delete job -n NAMESPACE \
     $(kubectl get job -n NAMESPACE \
     -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

2. apigee-system 네임스페이스에 대해 완료된 작업을 삭제합니다.

   kubectl delete job -n apigee-system \
     $(kubectl get job -n apigee-system \
     -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

3. apigeectl의 이전 버전이 포함된 디렉터리를 가리키도록 APIGEECTL_HOME 변수를 변경합니다. 예를 들면 다음과 같습니다.

   export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY

4. 롤백할 설치의 루트 디렉터리에서 apigeectl apply를 실행하고 포드 상태를 확인한 후 apigeectl init를 실행합니다. 롤백하려는 버전에 원래 재정의 파일을 사용해야 합니다.
   1. Hybrid 파일 디렉터리에서 apigeectl apply를 실행합니다.

      $APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE

      여기서 ORIGINAL_OVERRIDES_FILE은 이전 버전 Hybrid 설치에 대한 재정의 파일의 상대 경로 및 파일 이름입니다(예: ./overrides/overrides1.8.yaml).

   2. 포드의 상태를 확인합니다.

      kubectl -n NAMESPACE get pods

      여기서 NAMESPACE는 Apigee Hybrid 네임스페이스입니다.

   3. apigeeds의 상태를 확인합니다.

      kubectl describe apigeeds -n apigee

      다음과 비슷한 결과가 출력됩니다.

      Status:
        Cassandra Data Replication:
        Cassandra Pod Ips:
          10.8.2.204
        Cassandra Ready Replicas:  1
        Components:
          Cassandra:
            Last Successfully Released Version:
              Revision:  v1-f8aa9a82b9f69613
              Version:   v1
            Replicas:
              Available:  1
              Ready:      1
              Total:      1
              Updated:    1
            State:        running
        Scaling:
          In Progress:         false
          Operation:
          Requested Replicas:  0
        State:                 running

      apigeeds 포드가 실행 중인 경우에만 다음 단계를 진행합니다.

   4. 다음 명령어를 실행하여 업그레이드 후 메시지 프로세서에 대한 새 복제본 수 값을 기록해 둡니다. 이 값이 이전에 설정한 값과 일치하지 않으면 재정의 파일의 값을 이전 구성과 일치하도록 변경하세요.

      apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2

      다음과 비슷한 결과가 출력됩니다.

            autoScaler:
              minReplicas: 2
              maxReplicas: 10

   5. apigeectl init을 실행합니다.

      $APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE