이 페이지는 Cloud Translation API를 통해 번역되었습니다.

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

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

부 버전 업그레이드(예: 버전 1.7~1.8)와 패치 출시 버전 업그레이드(예: 1.8.0~1.8.8)에 동일한 절차를 사용합니다.

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

이미 Hybrid v1.8.0을 사용 중이고 Anthos Service Mesh에서 Apigee 인그레스 게이트웨이로 마이그레이션하려는 경우 Apigee 인그레스 게이트웨이로 마이그레이션을 참조하세요.

Apigee 인그레스 게이트웨이 소개

Apigee Hybrid는 버전 1.8부터 하이브리드 설치용 인그레스 게이트웨이 Apigee 인그레스 게이트웨이를 관리하는 새로운 기능을 제공합니다. Anthos Service Mesh는 더 이상 하이브리드 설치를 위한 기본 요건이 아닙니다. Apigee 인그레스 게이트웨이를 사용하면 Apigee는 더 이상 Anthos Service Mesh에 라우팅 구성을 제공하지 않습니다. 업그레이드 후에는 이 기능을 사용하기 전에 트래픽을 새 Apigee 인그레스 게이트웨이로 마이그레이션해야 합니다.

Apigee는 인그레스 게이트웨이에 Anthos Service Mesh 기능 중 일부를 사용합니다. Hybrid 버전 1.8부터 Apigee Hybrid 업그레이드의 일부로 설치 및 업그레이드되는 인그레스 게이트웨이가 Apigee Hybrid에 포함됩니다. 따라서 Apigee Hybrid 설치, 업그레이드, 관리를 위해 Anthos Service Mesh에 대한 전문 지식을 구축할 필요가 없습니다. 인그레스 게이트웨이 버전 및 Apigee Hybrid 출시 버전과의 호환성 관련 문제는 자동으로 처리됩니다.

마이그레이션을 위한 두 가지 시나리오는 다음과 같습니다.

멀티 클러스터 또는 멀티 리전 마이그레이션(권장):
새 Apigee용 인그레스로 전환하기 전에 마이그레이션하는 클러스터에서 다른 클러스터 또는 리전으로 모든 트래픽을 드레이닝합니다. 이렇게 하면 새 Apigee 인그레스 게이트웨이가 예상대로 작동하는지 테스트할 수 있습니다. 그런 다음 트래픽을 업그레이드된 클러스터로 다시 전환합니다.
인플레이스 업그레이드(프로덕션 환경에서는 권장되지 않음):
업그레이드 중에 Apigee는 지정된 IP 주소를 사용하여 새 인그레스 게이트웨이를 가동합니다. 그런 다음 새 Apigee 인그레스 게이트웨이가 예상대로 작동하는지 테스트하고 트래픽을 새 인그레스로 이동할 수 있습니다. 이 업그레이드 중에 다운타임이 발생할 수 있습니다.

Apigee Hybrid를 버전 1.8로 업그레이드하는 경우 재정의 파일에서 Apigee 인그레스 게이트웨이를 구성해야 합니다. 업그레이드 후에는 등록기관의 A 또는 CNAME 레코드를 Apigee 인그레스 게이트웨이 또는 Anthos Service Mesh의 IP 주소로 전달하여 클러스터에서 사용할 인그레스 게이트웨이 유형을 제어합니다.

버전 1.8.8로 업그레이드 개요

Apigee Hybrid 버전 1.8로 업그레이드하려면 다운타임이 필요할 수 있습니다.

Apigee 컨트롤러를 버전 1.8.8로 업그레이드하면 모든 Apigee 배포가 지속적 재시작을 거칩니다. 지속적 재시작 중에 프로덕션 하이브리드 환경에서 다운타임을 최소화하려면 클러스터를 최소 두 개 이상(동일하거나 다른 리전/데이터 센터에서)을 실행해야 합니다. 모든 프로덕션 트래픽을 단일 클러스터로 전환하고 오프라인으로 업그레이드하려는 클러스터를 적용한 후 업그레이드 절차를 진행합니다. 클러스터마다 이 절차를 반복합니다.

Apigee는 프로덕션에 미치는 영향을 줄이기 위해 가능한 한 빨리 모든 클러스터를 업그레이드하는 것이 좋습니다. 첫 번째 클러스터가 업그레이드된 후 남은 클러스터를 모두 업그레이드해야 하는 경우 시간 제한이 없습니다. 그러나 나머지 모든 클러스터가 업그레이드될 때까지 다음 작업이 영향을 받습니다.

Cassandra 백업 및 복원은 혼합 버전에서 작동할 수 없습니다. 예를 들어 Hybrid 1.7의 백업을 사용하여 Hybrid 1.8 인스턴스를 복원할 수 없습니다.
Cassandra 데이터 스트리밍은 혼합 Hybrid 버전 간에 작동하지 않습니다. 따라서 Cassandra 클러스터를 수평으로 확장할 수 없습니다.
이러한 작업은 Cassandra 데이터 스트리밍에 의존하므로 리전 확장 및 중단이 영향을 받습니다.

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

업그레이드를 준비합니다.
Hybrid 런타임 버전 1.8.8을 설치합니다.
인그레스 게이트웨이의 경우 다음 옵션 중 하나를 선택합니다.
- (권장) 새 Apigee 인그레스 게이트웨이를 사용하여 Anthos Service Mesh에서 Apigee 인그레스 게이트웨이로 트래픽 전환의 단계를 따르세요.
- 인그레스 게이트웨이에 Anthos Service Mesh를 계속 사용합니다.

기본 요건

이 업그레이드 안내에서는 Apigee Hybrid 버전 1.7.x 또는 버전 1.8.x의 이전 패치 출시 버전이 설치되어 있고 버전 1.8.8로 업그레이드한다고 가정합니다. 이전 버전에서 업데이트하는 경우 Apigee Hybrid를 버전 1.7로 업그레이드 안내를 참조하세요.

Anthos Service Mesh를 계속 사용하려면 Anthos Service Mesh를 지원되는 버전으로 업그레이드해야 합니다. 지원되는 Anthos Service Mesh 버전은 지원되는 플랫폼 표를 참조하세요.

버전 1.8로 업그레이드 준비

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

이 안내에서는 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%
```
버전 1.7 $APIGEECTL_HOME/ 디렉터리의 백업 사본을 만듭니다. 예를 들면 다음과 같습니다.
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.7-backup.tar.gz $APIGEECTL_HOME
```
Cassandra 백업 및 복구의 안내에 따라 Cassandra 데이터베이스를 백업합니다.

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

선택사항: Cloud Trace를 사용할 계획이고 하이브리드 v1.7 설치에서 이 단계를 아직 수행하지 않았으면 Apigee 런타임 서비스의 서비스 계정에 Cloud Trace 에이전트 Google 역할이 있는지 확인하세요. (roles/cloudtrace.agent)를 선택합니다.

프로덕션 환경에서는 일반적으로 apigee-runtime 서비스 계정이 사용됩니다. 비프로덕션 환경의 경우 일반적으로 apigee-non-prod 서비스 계정이 사용됩니다.

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

다음 명령어를 사용하여 서비스 계정의 이메일 주소를 가져옵니다.
프로덕션
```
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 패턴과 일치하면 다음 단계에서 이 패턴을 사용할 수 있습니다.

서비스 계정에 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 프로젝트의 이름입니다.

참고: 설치에서 서비스 계정의 커스텀 이름을 사용하는 경우 명령어에서 이 이름을 apigee-runtime 또는 apigee-non-prod로 대체합니다.

Apigee 인그레스 게이트웨이 설치 준비

업그레이드의 일부로 Apigee 인그레스 게이트웨이를 설치하려면 재정의 파일에 다음 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. See Known issue 243599452.
    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

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

자세한 내용과 기본 설정은 구성 속성 참조의 ingressGateways[].resources.requests.cpu 및 ingressGateways[].resources.requests.memory를 참조하세요.
CPU_COUNT_LIMIT 및 MEMORY_LIMIT: 설치에서 Apigee 인그레스 게이트웨이의 각 복제본에 대한 최대 CPU 및 메모리 한도입니다.
이러한 속성은 overlay.yaml과 같은 파일에서 이전에 Anthos Service Mesh 인그레스 게이트웨이에 대해 설정한 경우에만 설정하세요.

자세한 내용과 기본 설정은 구성 속성 참조의 ingressGateways[].resources.limits.cpu 및 ingressGateways[].resources.limits.memory를 참조하세요.
SVC_ANNOTATIONS_KEY 및 SVC_ANNOTATIONS_VALUE(선택사항):
참고: overrides.yaml의 ingressGateways[].svcAnnotations 필드가 예상대로 작동하지 않습니다. 알려진 문제 243599452를 참조하세요.

기본 인그레스 서비스의 주석을 제공하는 키-값 쌍입니다. 주석은 부하분산기 유형을 내부 또는 외부로 설정하는 등, 클라우드 플랫폼에서 하이브리드 설치를 구성하는 데 사용됩니다. 예를 들면 다음과 같습니다.
```
ingressGateways:
  svcAnnotations:
    networking.gke.io/load-balancer-type: "Internal"
```
주석은 플랫폼마다 다릅니다. 필수 및 추천 주석은 플랫폼 문서를 참조하세요.

참고: Apigee 인그레스 게이트웨이 노출에 설명된 대로 인그레스 배포를 위한 자체 Kubernetes 서비스를 만드는 경우 Annotations를 설정할 필요가 없습니다.
구성 속성 참조는 ingressGateways[].svcAnnotations를 참조하세요.
SVC_LOAD_BALANCER_IP (선택사항) 부하 분산기에 고정 IP 주소를 할당할 수 있습니다. 부하 분산기 IP 주소 지정을 지원하는 플랫폼에서 이 IP 주소로 부하 분산기가 생성됩니다. 부하 분산기 IP 주소를 지정할 수 없는 플랫폼에서 이 속성은 무시됩니다.
부하 분산기에 할당된 고정 IP 주소가 없으면 이 속성을 재정의 파일에서 제외하세요.

주의: 현재 istio-ingressgateway와 동일한 IP 주소를 지정하지 마세요. 이로 인해 해당 서비스가 클러스터에 아직 남아 있는 동안 문제가 발생할 수 있습니다.
참고: Apigee 인그레스 게이트웨이 노출에 설명된 대로 인그레스 배포를 위한 자체 Kubernetes 서비스를 만드는 경우 LoadBalancerIP를 설정할 필요가 없습니다.
구성 속성 참조의 ingressGateways[].svcLoadBalancerIP를 참조하세요.

선택적 v1.8 기능을 사용 설정 또는 중지하기 위해 재정의 파일을 추가로 변경

Hybrid v1.8에서 새 기능을 사용 설정하려면 overrides.yaml 파일에 다음 속성을 추가합니다. 이러한 기능은 선택사항입니다.

이제 조직 범위 UDCA가 기본적으로 사용 설정됩니다. 단일 UDCA 배포를 사용하여 모든 환경의 트래픽을 처리하면 UDCA 포드의 사용률이 낮아지는 것을 방지하고 다른 Apigee 구성요소의 노드 리소스 가용성이 증가합니다. 조직 범위 UDCA는 모든 환경에 대해 단일 서비스 계정(apigee-udca)을 사용합니다.
서로 다른 환경에서 UDCA에 서로 다른 서비스 계정을 사용하는 경우 이제 envs:udca:serviceAccountPath를 사용한 환경 수준에서 지정된 서비스 계정 대신 udca:serviceAccountPath를 사용한 재정의 파일의 조직 수준에서 지정된 서비스 계정을 사용한다는 점에 유의하세요.

Apigee Hybrid v1.8은 환경 범위 UDCA를 지원합니다. 환경별 UDCA를 유지하려면 orgScopedUDCA: false를 설정합니다.

참고: 환경 범위 UDCA에 대한 지원은 향후 Apigee Hybrid 출시 버전에서 사용할 수 없습니다.

구성 속성 참조의 orgScopedUDCA를 참조하세요.
Apigee 조직 및 환경이 활성 상태이고 overrides 파일에 지정된 Google Cloud Platform 프로젝트와 작동하는지 엄격하게 검증하려면 validateOrg를 사용 설정하세요.
```
validateOrg: true
```
참고: Apigee Hybrid에서는 엄격한 조직 검증을 사용할 수 없습니다. 기능을 중지하려면 validateOrg: false를 설정하세요.

구성 속성 참조의 validateOrg를 참조하세요.

Hybrid 1.8.8 런타임 설치

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

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

Linux

Linux 64비트:

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

MacOS

Mac 64비트:

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

Windows

Windows 64 비트:

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

현재 apigeectl/ 디렉터리의 이름을 백업 디렉터리 이름으로 바꿉니다. 예를 들면 다음과 같습니다.
Linux
```
mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/
```
MacOS
```
mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/ 
```
Windows
```
rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.7 
```
다운로드한 gzip 파일 콘텐츠를 Hybrid 기본 디렉터리에 추출합니다. 하이브리드 기본 디렉터리는 이름이 변경된 apigeectl-v1.7 디렉터리가 있는 디렉터리입니다.
Linux
```
tar xvzf filename.tar.gz -C ./
```
MacOS
```
tar xvzf filename.tar.gz -C ./
```
Windows
```
tar xvzf filename.zip -C ./
```
tar 콘텐츠는 기본적으로 이름에 해당 버전과 플랫폼이 포함된 디렉터리로 확장됩니다. 예를 들면 ./apigeectl_1.8.8-xxxxxxx_linux_64입니다. 다음 명령어를 사용하여 디렉터리 이름을 apigeectl로 변경합니다.
Linux
```
mv apigeectl_1.8.8-xxxxxxx_linux_64 apigeectl
```
MacOS
```
mv apigeectl_1.8.8-xxxxxxx_mac_64 apigeectl
```
Windows
```
rename apigeectl_1.8.8-xxxxxxx_windows_64 apigeectl
```
apigeectl 디렉터리로 변경합니다.
```
cd ./apigeectl
```
이 디렉터리는 apigeectl 홈 디렉터리입니다. 여기에 apigeectl 실행 가능한 명령어가 있습니다.
이 안내에서는 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%
```
version 명령어를 사용하여 apigeectl 버전을 확인합니다.
```
./apigeectl version
```
```
Version: 1.8.8
```
hybrid-base-directory/hybrid-files 디렉터리로 이동합니다. hybrid-files 디렉터리에는 재정의 파일, 인증서, 서비스 계정과 같은 구성 파일이 있습니다. 예를 들면 다음과 같습니다.
```
cd $APIGEECTL_HOME/../hybrid-files
```
다음 명령어를 사용하여 kubectl이 올바른 컨텍스트로 설정되었는지 확인합니다. 현재 컨텍스트를 Apigee Hybrid를 업그레이드하는 클러스터로 설정해야 합니다.
```
kubectl config get-contexts | grep \*
```
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
```
테스트 실행 초기화를 수행하여 오류를 확인합니다.
```
${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client
```
여기서 OVERRIDES_FILE은 재정의 파일 이름입니다(예: ./overrides/overrides.yaml).

팁: 위의 코드 샘플에서 OVERRIDES_FILE을 재정의 파일의 이름과 경로로 바꾸면 이 페이지의 모든 인스턴스가 바뀝니다.
오류가 없으면 Hybrid 1.8.8을 초기화합니다. 이 명령어는 Apigee 인그레스 게이트웨이를 설치하고 구성합니다.
```
$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
```
초기화 상태를 확인합니다.
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```
성공하면 다음과 같이 출력됩니다: All containers ready.

알려진 문제: init을 실행하고 check-ready가 성공한 것을 확인한 후 포드를 보면 Cassandra 스키마 유효성 검사가 오류 상태임을 알 수 있습니다. 이 상태는 알려진 문제 (#245664917)로 볼 수 있으며 무해합니다. 이 오류는 무시해도 되며 다음 단계인 apigeectl apply로 넘어갈 수 있습니다.

추가 검사를 위해 다음 명령어를 실행하여 ApigeeDataStore 상태를 확인할 수도 있습니다.
```
kubectl describe apigeeds -n apigee
```
출력에서 State: running을 찾습니다.
--dry-run 플래그를 사용하여 apply 명령어의 테스트 실행으로 오류가 있는지 확인합니다.
```
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
```
오류가 없으면 재정의를 적용합니다. 설치에 따라 프로덕션 환경 또는 비프로덕션 환경의 안내를 선택하여 따릅니다.
업그레이드 프로세스 중에 각 구성요소가 순차적 재시작을 수행합니다. 따라서 프로덕션 환경의 경우 한 번에 한 구성요소에 업그레이드를 적용하는 것이 가장 좋습니다.
프로덕션

프로덕션 환경의 경우 각 하이브리드 구성요소를 개별적으로 업그레이드하고 다음 구성요소로 진행하기 전에 업그레이드된 구성요소의 상태를 확인해야 합니다.
1. 현재 위치가 hybrid-files 디렉터리인지 확인합니다.
2. 재정의를 적용하여 Cassandra를 업그레이드합니다.
```
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
```
3. 완료를 확인합니다.
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```
  팁: check-ready가 실패하면 다음을 사용하여 포드에 대한 자세한 내용을 확인할 수 있습니다.
  kubectl -n NAMESPACE get pods
  
  여기서 NAMESPACE는 Apigee Hybrid 네임스페이스입니다.
  포드가 준비된 경우에만 다음 단계로 진행합니다.
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
```

Kubernetes 버전 업그레이드

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

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

	Apigee hybrid 버전
플랫폼	1.6 ⁽³⁾	1.7 ⁽³⁾	1.8 ⁽³⁾	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⁽¹³⁾	1.12.x 1.13.x 1.25⁽¹³⁾	1.13.x 1.25⁽¹³⁾ 1.26⁽¹³⁾
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.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x⁽⁴⁾ 1.10.x⁽⁴⁾ 1.11.x⁽⁴⁾^{(≥ 1.7.2)} 1.12.x⁽⁴⁾^{(≥ 1.7.2)}	1.10.x⁽⁴⁾ 1.11.x⁽⁴⁾ 1.12.x⁽⁴⁾ ⁽⁵⁾ 1.13.x⁽⁵⁾ 1.14.x⁽⁵⁾ 1.15.x	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
Anthos(베어메탈)⁽¹⁾	1.7.x 1.8.2+ 1.9.3+ 1.10.x	1.9.x⁽⁴⁾ 1.10.x⁽⁴⁾ 1.11.x⁽⁴⁾^{(≥ 1.7.2)} 1.12.x⁽⁴⁾^{(≥ 1.7.2)}	1.10.x⁽⁴⁾ 1.11.x⁽⁴⁾ 1.12.x⁽⁴⁾ ⁽⁵⁾ 1.13.x⁽⁵⁾ 1.14.x⁽⁵⁾ 1.15.x	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
EKS⁽⁷⁾	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⁽⁷⁾	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⁽⁷⁾	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)⁽⁷⁾	해당 사항 없음	해당 사항 없음	해당 사항 없음	1.3.8	v1.26.2+rke2r1
구성요소	1.6 ⁽³⁾	1.7 ⁽³⁾	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⁽¹¹⁾	1.17.x⁽¹¹⁾
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
⁽¹⁾ 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` 설치 충돌. ⁽²⁾ Apigee Hybrid 버전 1.7.2 이상에서 지원 이용 가능 ⁽³⁾ Apigee Hybrid 버전 1.8 이하의 공식 EOL 날짜에 도달했습니다. 일반 월간 패치는 더 이상 제공되지 않습니다. 지속적인 지원에 대한 명시적인 공식 예외가 적용되는 고객을 제외하고 이 출시 버전은 더 이상 공식적으로 지원되지 않습니다. 다른 고객은 업그레이드해야 합니다. ⁽⁴⁾베어메탈용 Anthos 및 VMWare 버전 1.12 이하는 지원되지 않습니다. 베어메탈용 Anthos 버전 지원 정책 및 VMware용 Anthos 클러스터 버전을 참조하세요. ⁽⁵⁾VMware용 및 베어메탈용 Anthos에는 ASM 1.14 이상이 필요합니다. Hybrid v1.8로 업그레이드하고 하이브리드 클러스터에 더 이상 ASM을 설치할 필요가 없는 Apigee 인그레스 게이트웨이로 전환하는 것이 좋습니다. ⁽⁶⁾ Apigee Hybrid 버전 1.8.4 이상에서 지원 이용 가능 ⁽⁷⁾ 연결된 클러스터에는 Apigee ingressgateway를 사용하는 Apigee Hybrid v1.8 이상이 요구되지 않습니다. ⁽⁸⁾ Apigee Hybrid 버전 1.8.4 이상에서는 지원되지 않습니다. ⁽⁹⁾ Apigee Hybrid 버전 1.7.6 이상에서 지원 이용 가능 ⁽¹⁰⁾ Apigee Hybrid 버전 1.8.5 이상에서는 지원되지 않습니다. ⁽¹¹⁾ ASM은 Apigee Hybrid 1.9 이상에 자동으로 설치됩니다. ⁽¹²⁾ Apigee Hybrid 버전 1.9.2 이상에서 지원 이용 가능 ⁽¹³⁾ 이제 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 콘솔에서 연결된 클러스터를 보려는 경우에만 등록합니다. 자세한 내용은 서드 파티 Kubernetes 클러스터를 Google Cloud에 연결을 참조하세요.

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

Anthos Service Mesh에서 Apigee 인그레스 게이트웨이로 트래픽 전환

트래픽을 Apigee 인그레스 게이트웨이로 전환하려면 다음 안내를 따르세요.

Apigee 인그레스 게이트웨이를 노출합니다. Apigee 인그레스 게이트웨이 노출의 절차를 따릅니다.
프록시를 호출하여 새 인그레스 게이트웨이를 테스트합니다. 현재 배포된 모든 중요 프록시를 테스트하는 것이 가장 좋습니다.
트래픽을 전환하려면 새 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
```
대시보드를 모니터링하여 모든 런타임 트래픽이 작동하는지 확인합니다. 모든 것이 예상대로 작동하는 경우에만 다음 단계로 진행합니다. 이전 인그레스 게이트웨이(Anthos Service Mesh)를 통과하는 트래픽이 없는지 확인합니다. DNS 캐싱으로 인해 DNS 업데이트 전파 속도가 느릴 수 있습니다.
Apigee가 Anthos Service Mesh에 구성을 제공하지 않도록 하려면 Apigee 인그레스 게이트웨이 관리 가이드에서 ASM에 구성 제공 중지에 있는 단계를 따르세요.
API 프록시 트래픽을 다시 테스트하고 모니터링합니다.
Anthos Service Mesh 문서의 안내에 따라 클러스터에서 Anthos Service Mesh를 제거합니다.

Anthos Service Mesh를 버전 1.15로 업그레이드

플랫폼에 적합한 Anthos Service Mesh 문서를 사용하여 절차를 수행합니다.

Anthos Service Mesh 설치 및 구성 안내는 플랫폼에 따라 다릅니다. 플랫폼은 다음 카테고리로 분류됩니다.

GKE: Google Cloud에서 실행되는 Google Kubernetes Engine 클러스터입니다.
Google Cloud 외부: 다음 위치에서 실행되는 Anthos 클러스터:
- VMware용 Anthos 클러스터(GKE On-Prem)
- 베어메탈용 Anthos
- Anthos clusters on AWS
- Amazon EKS
기타 Kubernetes 플랫폼: 다음 제품에서 생성 및 실행되는 규정 준수 클러스터입니다.
- AKS
- EKS
- OpenShift

GKE

Hybrid 설치에서 Anthos Service Mesh 1.13.9 버전으로 업그레이드하는 순서는 다음과 같습니다.

업그레이드를 준비합니다.
Anthos Service Mesh 새 버전을 설치합니다.
현재 설치에서 이전 Anthos Service Mesh 버전의 배포, 서비스, 웹훅을 삭제합니다.
게이트웨이를 업그레이드하고 새 웹훅을 구성합니다.

Anthos Service Mesh를 1.13.9버전으로 업그레이드할 준비

Anthos Service Mesh 업그레이드의 요구사항을 검토하지만 아직 업그레이드를 수행하지 마세요.
새 버전을 설치하기 전 현재 버전을 확인합니다. 현재 설치에서 이전 Anthos Service Mesh 버전의 배포, 서비스, 웹훅을 삭제하려면 이 정보가 필요합니다. 다음 명령어를 사용하여 현재 istiod 버전을 환경 변수에 저장합니다.
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
1.12.9-asm.2과 비슷한 출력이 표시되어야 합니다.

참고: 명령어에서 값을 여러 개 반환하면 DELETE_REV 값을 가장 오래된 버전으로 설정하고 절차에 따라 가장 오래된 버전을 삭제한 후 모든 버전이 삭제될 때까지 프로세스를 반복하세요.

새 overlay.yaml 파일을 만들거나 기존 overlay.yaml에 다음 콘텐츠가 포함되었는지 확인합니다.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Anthos Service Mesh 문서의 다음 섹션에 있는 안내를 따릅니다.
중요: 선택적 옵션을 사용하여 Anthos Service Mesh를 업그레이드하고 overlay.yaml을 포함하는 안내를 따라야 합니다.
1. asmcli를 다운로드합니다.
2. 클러스터에 관리자 권한을 부여합니다.
3. 프로젝트 및 클러스터를 검증합니다.
4. 선택적 기능을 사용하여 업그레이드합니다. '게이트웨이 업그레이드 섹션'을 시작하기 전에 중지하세요.
새 제어 영역으로 전환합니다.
1. istiod에 있는 버전 라벨을 가져옵니다.
```
kubectl get pod -n istio-system -L istio.io/rev
```
  명령어 출력은 다음과 비슷합니다.
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. 최신 버전 라벨을 환경 변수에 할당합니다.
  출력의 REV 열에서 새 버전에 대한 버전 라벨 값을 확인합니다. 이 예시에서 값은 asm-1139-10입니다.
```
export UPGRADE_REV="REVISION_LABEL"
```
3. istio-system 네임스페이스에 버전 라벨을 추가하고 다음 명령어를 사용하여 istio-injection 라벨(있는 경우)을 삭제합니다.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  출력에 "istio-injection not found"가 표시되면 무시해도 됩니다. 이것은 이전에 네임스페이스에 istio-injection 라벨이 없음을 의미합니다. 네임스페이스에 istio-injection 및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든 kubectl label 명령어에는 istio-injection 라벨 삭제가 포함됩니다.
4. 포드를 다시 시작하여 재삽입을 트리거합니다.
```
kubectl rollout restart deployment -n istio-system
```
5. 애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.
6. 다른 네임스페이스에 워크로드가 있으면 단계를 반복하여 네임스페이스에 라벨을 지정하고 포드를 다시 시작합니다.

이전 버전을 삭제합니다.

asmcli를 설치한 디렉터리로 이동합니다.
Anthos Service Mesh 설치의 출력 디렉터리를 DIR_PATH 환경 변수에 저장합니다. 이 디렉터리는 선택적 기능을 사용하여 업그레이드 절차에서 지정한 디렉터리와 동일합니다.
```
export DIR_PATH=OUTPUT_DIR
```

다음 명령어가 포함된 셸 스크립트를 만듭니다.

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

스크립트를 실행하여 이전 버전을 삭제합니다.

Google Cloud 외부

이 안내에서는 다음에서 Anthos Service Mesh 업그레이드를 설명합니다.

VMware용 Anthos 클러스터(GKE On-Prem)
베어메탈용 Anthos
Anthos clusters on AWS
Amazon EKS

Hybrid 설치에서 Anthos Service Mesh 1.13.9 버전으로 업그레이드하는 순서는 다음과 같습니다.

업그레이드를 준비합니다.
Anthos Service Mesh 새 버전을 설치합니다.
현재 설치에서 이전 Anthos Service Mesh 버전의 배포, 서비스, 웹훅을 삭제합니다.
게이트웨이를 업그레이드하고 새 웹훅을 구성합니다.

Anthos Service Mesh를 1.13.9버전으로 업그레이드할 준비

Anthos Service Mesh 업그레이드의 요구사항을 검토하지만 아직 업그레이드를 수행하지 마세요.
새 버전을 설치하기 전 현재 버전을 확인합니다. 현재 설치에서 이전 Anthos Service Mesh 버전의 배포, 서비스, 웹훅을 삭제하려면 이 정보가 필요합니다. 다음 명령어를 사용하여 현재 istiod 버전을 환경 변수에 저장합니다.
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
1.12.9-asm.2과 비슷한 출력이 표시되어야 합니다.

참고: 명령어에서 값을 여러 개 반환하면 DELETE_REV 값을 가장 오래된 버전으로 설정하고 절차에 따라 가장 오래된 버전을 삭제한 후 모든 버전이 삭제될 때까지 프로세스를 반복하세요.

새 overlay.yaml 파일을 만들거나 기존 overlay.yaml에 다음 콘텐츠가 포함되었는지 확인합니다.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:  
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  values:
    gateways:
      istio-ingressgateway:
        runAsRoot: true

  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Anthos Service Mesh 문서의 다음 섹션에 있는 안내를 따릅니다.
중요: 선택적 옵션을 사용하여 Anthos Service Mesh를 업그레이드하고 overlay.yaml을 포함하는 안내를 따라야 합니다.
1. asmcli를 다운로드합니다.
2. 클러스터에 관리자 권한을 부여합니다.
3. 프로젝트 및 클러스터를 검증합니다.
4. 선택적 기능을 사용하여 업그레이드합니다. '게이트웨이 업그레이드 섹션'을 시작하기 전에 중지하세요.
새 제어 영역으로 전환합니다.
1. istiod에 있는 버전 라벨을 가져옵니다.
```
kubectl get pod -n istio-system -L istio.io/rev
```
  명령어 출력은 다음과 비슷합니다.
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. 최신 버전 라벨을 환경 변수에 할당합니다.
  출력의 REV 열에서 새 버전에 대한 버전 라벨 값을 확인합니다. 이 예시에서 값은 asm-1139-10입니다.
```
export UPGRADE_REV="REVISION_LABEL"
```
3. istio-system 네임스페이스에 버전 라벨을 추가하고 다음 명령어를 사용하여 istio-injection 라벨(있는 경우)을 삭제합니다.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  출력에 "istio-injection not found"가 표시되면 무시해도 됩니다. 이것은 이전에 네임스페이스에 istio-injection 라벨이 없음을 의미합니다. 네임스페이스에 istio-injection 및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든 kubectl label 명령어에는 istio-injection 라벨 삭제가 포함됩니다.
4. 포드를 다시 시작하여 재삽입을 트리거합니다.
```
kubectl rollout restart deployment -n istio-system
```
5. 애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.
6. 다른 네임스페이스에 워크로드가 있으면 단계를 반복하여 네임스페이스에 라벨을 지정하고 포드를 다시 시작합니다.

이전 버전을 삭제합니다.

asmcli를 설치한 디렉터리로 이동합니다.
Anthos Service Mesh 설치의 출력 디렉터리를 DIR_PATH 환경 변수에 저장합니다. 이 디렉터리는 선택적 기능을 사용하여 업그레이드 절차에서 지정한 디렉터리와 동일합니다.
```
export DIR_PATH=OUTPUT_DIR
```

다음 명령어가 포함된 셸 스크립트를 만듭니다.

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

스크립트를 실행하여 이전 버전을 삭제합니다.

AKS/EKS

이 안내에서 Anthos가 연결된 클러스터에서 Anthos Service Mesh(ASM) istio-1.13.9-asm.10 버전을 업그레이드하는 프로세스는 새로 설치하는 프로세스와 동일합니다.

Anthos Service Mesh 설치 준비

새 버전을 설치하기 전 현재 버전을 확인합니다. 현재 Anthos Service Mesh 설치에서 웹훅 유효성 검사 및 웹훅 변형을 삭제하려면 이 정보가 필요합니다. 다음 명령어를 사용하여 현재 istiod 버전을 환경 변수에 저장합니다.
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
1.12.9-asm.2과 비슷한 출력이 표시되어야 합니다.

참고: 명령어에서 값을 여러 개 반환하면 DELETE_REV 값을 가장 오래된 버전으로 설정하고 절차에 따라 가장 오래된 버전을 삭제한 후 모든 버전이 삭제될 때까지 프로세스를 반복하세요.

Linux

Anthos Service Mesh 설치 파일을 현재 작업 디렉터리에 다운로드합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz

서명 파일을 다운로드하고 OpenSSL을 사용하여 서명을 확인합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음 명령어를 실행합니다.

tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

이 명령어는 다음을 포함하는 현재 작업 디렉터리에 istio-1.13.9-asm.10이라는 설치 디렉터리를 만듭니다.

샘플 애플리케이션은 samples 디렉터리에 있습니다.
Anthos Service Mesh를 설치하는 데 사용하는 istioctl 명령줄 도구는 bin 디렉터리에 있습니다.
Anthos Service Mesh 구성 프로필은 manifests/profiles 디렉터리에 있습니다.

Anthos Service Mesh 설치 루트 디렉터리에 있는지 확인합니다.

cd istio-1.13.9-asm.10

편의를 위해 /bin 디렉터리의 도구를 PATH에 추가합니다.

export PATH=$PWD/bin:$PATH

MacOS

Anthos Service Mesh 설치 파일을 현재 작업 디렉터리에 다운로드합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz

서명 파일을 다운로드하고 OpenSSL을 사용하여 서명을 확인합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음 명령어를 실행합니다.

tar xzf istio-1.13.9-asm.10-osx.tar.gz

이 명령어는 다음을 포함하는 현재 작업 디렉터리에 istio-1.13.9-asm.10이라는 설치 디렉터리를 만듭니다.

샘플 애플리케이션은 samples 디렉터리에 있습니다.
Anthos Service Mesh를 설치하는 데 사용하는 istioctl 명령줄 도구는 bin 디렉터리에 있습니다.
Anthos Service Mesh 구성 프로필은 manifests/profiles 디렉터리에 있습니다.

Anthos Service Mesh 설치 루트 디렉터리에 있는지 확인합니다.

cd istio-1.13.9-asm.10

편의를 위해 /bin 디렉터리의 도구를 PATH에 추가합니다.

export PATH=$PWD/bin:$PATH

Windows

Anthos Service Mesh 설치 파일을 현재 작업 디렉터리에 다운로드합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip

서명 파일을 다운로드하고 OpenSSL을 사용하여 서명을 확인합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig

openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음 명령어를 실행합니다.

tar xzf istio-1.13.9-asm.10-win.zip

이 명령어는 다음을 포함하는 현재 작업 디렉터리에 istio-1.13.9-asm.10이라는 설치 디렉터리를 만듭니다.

샘플 애플리케이션은 samples 디렉터리에 있습니다.
Anthos Service Mesh를 설치하는 데 사용하는 istioctl 명령줄 도구는 bin 디렉터리에 있습니다.
Anthos Service Mesh 구성 프로필은 manifests\profiles 디렉터리에 있습니다.

Anthos Service Mesh 설치 루트 디렉터리에 있는지 확인합니다.

cd istio-1.13.9-asm.10

편의를 위해 \bin 디렉터리의 도구를 PATH에 추가합니다.

set PATH=%CD%\bin:%PATH%

이제 Anthos Service Mesh Istio가 설치되었으므로 istioctl 버전을 확인합니다.
```
istioctl version
```
제어 영역 구성요소에 istio-system이라는 네임스페이스를 만듭니다.
```
kubectl create namespace istio-system
```

Anthos Service Mesh 설치

overlay.yaml 파일을 수정하거나 다음 콘텐츠가 포함된 새 파일을 만듭니다.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        service:
          type: LoadBalancer
          ports:
          - name: status-port
            port: 15021
            targetPort: 15021
          - name: http2
            port: 80
            targetPort: 8080
          - name: https
            port: 443
            targetPort: 8443

asm-multicloud 프로필을 사용하여 istioctl로 Anthos Service Mesh를 설치합니다.
```
istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1139-10" \
    --filename overlay.yaml
```
다음과 비슷한 결과가 출력됩니다.
```
kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s
```
--set revision 인수는 istio.io/rev=asm-1139-10 형식의 버전 라벨을 istiod에 추가합니다. 버전 라벨은 자동 사이드카 인젝터 웹훅에서 삽입된 사이드카를 특정 istiod 버전과 연결하는 데 사용됩니다. 네임스페이스에 사이드카 자동 삽입을 사용 설정하려면 istiod의 라벨과 일치하는 버전으로 라벨을 지정해야 합니다.

설치가 완료되었는지 확인합니다.

kubectl get svc -n istio-system

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

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

새 제어 영역으로 전환합니다.
1. istiod에 있는 버전 라벨을 가져옵니다.
```
kubectl get pod -n istio-system -L istio.io/rev
```
  명령어 출력은 다음과 비슷합니다.
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. 최신 버전 라벨을 환경 변수에 할당합니다.
  출력의 REV 열에서 새 버전에 대한 버전 라벨 값을 확인합니다. 이 예시에서 값은 asm-1139-10입니다.
```
export UPGRADE_REV="REVISION_LABEL"
```
3. istio-system 네임스페이스에 버전 라벨을 추가하고 다음 명령어를 사용하여 istio-injection 라벨(있는 경우)을 삭제합니다.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  출력에 "istio-injection not found"가 표시되면 무시해도 됩니다. 이것은 이전에 네임스페이스에 istio-injection 라벨이 없음을 의미합니다. 네임스페이스에 istio-injection 및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든 kubectl label 명령어에는 istio-injection 라벨 삭제가 포함됩니다.
4. 포드를 다시 시작하여 재삽입을 트리거합니다.
```
kubectl rollout restart deployment -n istio-system
```
5. 애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.
6. 다른 네임스페이스에 워크로드가 있으면 단계를 반복하여 네임스페이스에 라벨을 지정하고 포드를 다시 시작합니다.

이전 버전을 삭제합니다.

asmcli를 설치한 디렉터리로 이동합니다.

다음 명령어가 포함된 셸 스크립트를 만듭니다.

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

스크립트를 실행하여 이전 버전을 삭제합니다.

OpenShift

이 안내에서 Anthos가 연결된 클러스터에서 Anthos Service Mesh(ASM) istio-1.13.9-asm.10 버전을 업그레이드하는 프로세스는 새로 설치하는 프로세스와 동일합니다.

Anthos Service Mesh 설치 준비

새 버전을 설치하기 전 현재 버전을 확인합니다. 현재 Anthos Service Mesh 설치에서 웹훅 유효성 검사 및 웹훅 변형을 삭제하려면 이 정보가 필요합니다. 다음 명령어를 사용하여 현재 istiod 버전을 환경 변수에 저장합니다.
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
1.12.9-asm.2과 비슷한 출력이 표시되어야 합니다.

참고: 명령어에서 값을 여러 개 반환하면 DELETE_REV 값을 가장 오래된 버전으로 설정하고 절차에 따라 가장 오래된 버전을 삭제한 후 모든 버전이 삭제될 때까지 프로세스를 반복하세요.

Linux

다음 OpenShift CLI(oc) 명령어를 사용하여 istio-system에 anyuid 보안 컨텍스트 제약조건(SCC)를 부여합니다.

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Anthos Service Mesh 설치 파일을 현재 작업 디렉터리에 다운로드합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz

서명 파일을 다운로드하고 OpenSSL을 사용하여 서명을 확인합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음 명령어를 실행합니다.

tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

이 명령어는 다음을 포함하는 현재 작업 디렉터리에 istio-1.13.9-asm.10이라는 설치 디렉터리를 만듭니다.

샘플 애플리케이션은 samples 디렉터리에 있습니다.
Anthos Service Mesh를 설치하는 데 사용하는 istioctl 명령줄 도구는 bin 디렉터리에 있습니다.
Anthos Service Mesh 구성 프로필은 manifests/profiles 디렉터리에 있습니다.

Anthos Service Mesh 설치 루트 디렉터리에 있는지 확인합니다.

cd istio-1.13.9-asm.10

편의를 위해 /bin 디렉터리의 도구를 PATH에 추가합니다.

export PATH=$PWD/bin:$PATH

MacOS

다음 OpenShift CLI(oc) 명령어를 사용하여 istio-system에 anyuid 보안 컨텍스트 제약조건(SCC)를 부여합니다.

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Anthos Service Mesh 설치 파일을 현재 작업 디렉터리에 다운로드합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz

서명 파일을 다운로드하고 OpenSSL을 사용하여 서명을 확인합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음 명령어를 실행합니다.

tar xzf istio-1.13.9-asm.10-osx.tar.gz

이 명령어는 다음을 포함하는 현재 작업 디렉터리에 istio-1.13.9-asm.10이라는 설치 디렉터리를 만듭니다.

샘플 애플리케이션은 samples 디렉터리에 있습니다.
Anthos Service Mesh를 설치하는 데 사용하는 istioctl 명령줄 도구는 bin 디렉터리에 있습니다.
Anthos Service Mesh 구성 프로필은 manifests/profiles 디렉터리에 있습니다.

Anthos Service Mesh 설치 루트 디렉터리에 있는지 확인합니다.

cd istio-1.13.9-asm.10

편의를 위해 /bin 디렉터리의 도구를 PATH에 추가합니다.

export PATH=$PWD/bin:$PATH

Windows

다음 OpenShift CLI(oc) 명령어를 사용하여 istio-system에 anyuid 보안 컨텍스트 제약조건(SCC)를 부여합니다.

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Anthos Service Mesh 설치 파일을 현재 작업 디렉터리에 다운로드합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip

서명 파일을 다운로드하고 OpenSSL을 사용하여 서명을 확인합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig

openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음 명령어를 실행합니다.

tar xzf istio-1.13.9-asm.10-win.zip

이 명령어는 다음을 포함하는 현재 작업 디렉터리에 istio-1.13.9-asm.10이라는 설치 디렉터리를 만듭니다.

샘플 애플리케이션은 samples 디렉터리에 있습니다.
Anthos Service Mesh를 설치하는 데 사용하는 istioctl 명령줄 도구는 bin 디렉터리에 있습니다.
Anthos Service Mesh 구성 프로필은 manifests\profiles 디렉터리에 있습니다.

Anthos Service Mesh 설치 루트 디렉터리에 있는지 확인합니다.

cd istio-1.13.9-asm.10

편의를 위해 \bin 디렉터리의 도구를 PATH에 추가합니다.

set PATH=%CD%\bin:%PATH%

이제 Anthos Service Mesh Istio가 설치되었으므로 istioctl 버전을 확인합니다.
```
istioctl version
```
제어 영역 구성요소에 istio-system이라는 네임스페이스를 만듭니다.
```
kubectl create namespace istio-system
```

유효성 검증 웹훅 구성

Anthos Service Mesh를 설치할 때 istiod에 버전 라벨을 설정합니다. 유효성 검증 웹훅에 동일한 버전을 설정해야 합니다.

다음 콘텐츠로 istiod-service.yaml 파일을 만듭니다.

apiVersion: v1
kind: Service
metadata:
  name: istiod
  namespace: istio-system
  labels:
    istio.io/rev: asm-1139-10
    app: istiod
    istio: pilot
    release: istio
spec:
  ports:
    - port: 15010
      name: grpc-xds # plaintext
      protocol: TCP
    - port: 15012
      name: https-dns # mTLS with k8s-signed cert
      protocol: TCP
    - port: 443
      name: https-webhook # validation and injection
      targetPort: 15017
      protocol: TCP
    - port: 15014
      name: http-monitoring # prometheus stats
      protocol: TCP
  selector:
    app: istiod
    istio.io/rev: asm-1139-10
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

kubectl을 사용하여 유효성 검증 웹훅 구성을 적용합니다.
```
kubectl apply -f istiod-service.yaml
```

구성이 적용되었는지 확인합니다.

kubectl get svc -n istio-system

다음과 비슷한 응답이 표시됩니다.

NAME     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
istiod   ClusterIP   172.200.18.133   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP   22s

Anthos Service Mesh 설치

overlay.yaml 파일을 수정하거나 다음 콘텐츠가 포함된 새 파일을 만듭니다.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          service:
            type: LoadBalancer
            ports:
            - name: status-port
              port: 15021
              targetPort: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443

asm-multicloud 프로필을 사용하여 istioctl로 Anthos Service Mesh를 설치합니다.
```
istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1139-10" \
    --filename overlayfile.yaml
```
다음과 비슷한 결과가 출력됩니다.
```
kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s
```
--set revision 인수는 istio.io/rev=1.6.11-asm.1 형식의 버전 라벨을 istiod에 추가합니다. 버전 라벨은 자동 사이드카 인젝터 웹훅에서 삽입된 사이드카를 특정 istiod 버전과 연결하는 데 사용됩니다. 네임스페이스에 사이드카 자동 삽입을 사용 설정하려면 istiod의 라벨과 일치하는 버전으로 라벨을 지정해야 합니다.

설치가 완료되었는지 확인합니다.

kubectl get svc -n istio-system

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

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

새 제어 영역으로 전환합니다.
1. istiod에 있는 버전 라벨을 가져옵니다.
```
kubectl get pod -n istio-system -L istio.io/rev
```
  명령어 출력은 다음과 비슷합니다.
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. 최신 버전 라벨을 환경 변수에 할당합니다.
  출력의 REV 열에서 새 버전에 대한 버전 라벨 값을 확인합니다. 이 예시에서 값은 asm-1139-10입니다.
```
export UPGRADE_REV="REVISION_LABEL"
```
3. istio-system 네임스페이스에 버전 라벨을 추가하고 다음 명령어를 사용하여 istio-injection 라벨(있는 경우)을 삭제합니다.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  출력에 "istio-injection not found"가 표시되면 무시해도 됩니다. 이것은 이전에 네임스페이스에 istio-injection 라벨이 없음을 의미합니다. 네임스페이스에 istio-injection 및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든 kubectl label 명령어에는 istio-injection 라벨 삭제가 포함됩니다.
4. 포드를 다시 시작하여 재삽입을 트리거합니다.
```
kubectl rollout restart deployment -n istio-system
```
5. 애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.
6. 다른 네임스페이스에 워크로드가 있으면 단계를 반복하여 네임스페이스에 라벨을 지정하고 포드를 다시 시작합니다.

이전 버전을 삭제합니다.

asmcli를 설치한 디렉터리로 이동합니다.

다음 명령어가 포함된 셸 스크립트를 만듭니다.

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

스크립트를 실행하여 이전 버전을 삭제합니다.

업그레이드 롤백

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

하이브리드 런타임 네임스페이스의 완료된 작업을 삭제합니다. 여기서 NAMESPACE는 재정의 파일에 지정된 네임스페이스(네임스페이스가 지정된 경우)입니다. 그렇지 않은 경우 기본 네임스페이스는 apigee입니다.
```
kubectl delete job -n NAMESPACE \
  $(kubectl get job -n NAMESPACE \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

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

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

apigeectl의 이전 버전이 포함된 디렉터리를 가리키도록 APIGEECTL_HOME 변수를 변경합니다. 예를 들면
```
export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
```
입니다.
overrides 파일의 변경사항을 실행취소합니다.
1. ingressGateways 및 모든 속성을 삭제하거나 주석 처리합니다.
2. virtualhosts.selector.app 값을 이전 값으로 설정합니다. 예를 들면 다음과 같습니다.
```
virtualhosts:
  - name: my-env-group
    selector:
      app: istio-ingressgateway
```
3. ao.args.disableIstioConfigInAPIServer를 삭제하거나 주석 처리합니다.
롤백할 설치의 루트 디렉터리에서 apigeectl apply를 실행하고 포드 상태를 확인한 후 apigeectl init를 실행합니다. 롤백하려는 버전에 원래 재정의 파일을 사용해야 합니다.
1. Hybrid 파일 디렉터리에서 apigeectl apply를 실행합니다.
```
$APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE
```
  여기서 ORIGINAL_OVERRIDES_FILE은 이전 버전 하이브리드 설치에 대한 재정의 파일의 상대 경로 및 파일 이름입니다(예: ./overrides/overrides1.7.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. Hybrid v1.8.4 이하로 롤백하는 경우 Hybrid v1.8.5 이상에서 사용한 컨트롤러 배포를 삭제합니다.
```
kubectl -n apigee-system delete deploy apigee-controller-manager
```
6. apigeectl init를 실행합니다.
```
$APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
```
Apigee 인그레스 게이트웨이 관리자 배포를 삭제합니다. 이 구성요소는 Apigee Hybrid 버전 1.8 이상하고만 관련이 있습니다.
```
kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager
```
여기서 NAMESPACE는 Apigee Hybrid 네임스페이스입니다.

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

Apigee 인그레스 게이트웨이 소개

버전 1.8.8로 업그레이드 개요

기본 요건

버전 1.8로 업그레이드 준비

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

Linux

MacOS

Windows

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

프로덕션

비프로덕션

프로덕션

비프로덕션

예

Apigee 인그레스 게이트웨이 설치 준비

구문

예

선택적 v1.8 기능을 사용 설정 또는 중지하기 위해 재정의 파일을 추가로 변경

Hybrid 1.8.8 런타임 설치

Linux

MacOS

Windows

Linux

MacOS

Windows

Linux

MacOS

Windows

Linux

MacOS

Windows

Linux

MacOS

Windows

프로덕션

비프로덕션

Kubernetes 버전 업그레이드

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

플랫폼

구성요소

연결된 클러스터 정보

Anthos Service Mesh에서 Apigee 인그레스 게이트웨이로 트래픽 전환

Anthos Service Mesh를 버전 1.15로 업그레이드

GKE

Anthos Service Mesh를 1.13.9버전으로 업그레이드할 준비

Google Cloud 외부

Anthos Service Mesh를 1.13.9버전으로 업그레이드할 준비

AKS/EKS

Anthos Service Mesh 설치 준비

Linux

MacOS

Windows

Anthos Service Mesh 설치

OpenShift

Anthos Service Mesh 설치 준비

Linux

MacOS

Windows

유효성 검증 웹훅 구성

Anthos Service Mesh 설치

업그레이드 롤백