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

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

이 절차에서는 Apigee Hybrid 버전 1.11.x에서 Apigee Hybrid 버전 1.12.0으로 업그레이드하는 방법을 다룹니다.

Apigee Hybrid v1.11의 변경사항

Apigee Hybrid 버전 1.12에는 업그레이드 프로세스에 영향을 주는 다음과 같은 변경사항이 있습니다. v1.12의 전체 기능 목록은 Hybrid v1.12.0 출시 노트를 참조하세요.

Cassandra 4.x: 버전 1.12부터 Apigee Hybrid는 Cassandra 버전 4 이상을 사용합니다.
중요: 데이터베이스 변경사항으로 인해 업그레이드된 apigee-datastore 구성요소를 롤백할 수 없습니다. 따라서 업그레이드하기 전에 Cassandra 데이터베이스와 Hybrid 설치를 백업해야 합니다. 업그레이드를 롤백해야 하는 경우 다음 시나리오를 고려하세요.
- Cassandra가 아직 업그레이드되지 않음: 모든 변경사항을 롤백할 수 있습니다.
- Cassandra가 업그레이드되고 모든 Cassandra 포드가 정상 상태임: apigee-datastore를 제외한 모든 구성요소에 대한 변경사항을 롤백할 수 있습니다. v1.11.x 설치는 Cassandra v4를 실행하는 apigee-datastore의 v1.12 인스턴스에서 계속 작동합니다.
- Cassandra가 업그레이드되고 Cassandra 포드가 비정상 상태임: Hybrid v1.12를 제거하고 백업에서 v.11 설치를 복원해야 합니다.
apigeectl 지원 중단: Apigee Hybrid는 버전 1.12부터 Hybrid 설치와 관리를 위해 Helm만 지원합니다.
주의: apigeectl은 2024년 4월 17일부터 지원 중단되었습니다. apigeectl 도구는 Apigee Hybrid v1.12에서 지원되지 않습니다. Apigee Hybrid v1.10 및 v1.11의 apigeectl 지원은 2025년 4월 17일에 종료됩니다. 자세한 내용은 apigeectl 지원 중단을 참조하세요.

중요: apigeectl로 v1.11을 관리하는 경우 버전 1.12로 업그레이드하기 전에 먼저 v1.11 설치를 마이그레이션하여 Helm을 사용해야 합니다. Apigeectl에서 Helm 차트로 Apigee Hybrid 마이그레이션의 안내를 따릅니다.
이제 Apigee 프록시 및 대상 엔드포인트를 모니터링하기 위한 새로운 측정항목 모음을 사용할 수 있습니다. Hybrid v1.12의 경우 ProxyV2 및 TargetV2 모니터링 리소스가 더 이상 기본적으로 사용되지 않습니다. 모든 프록시 및 대상 측정항목이 Proxy 및 Target 모니터링 리소스에 게시됩니다.

측정항목을 ProxyV2 및 TargetV2 모니터링 리소스로 계속 내보내려면 overrides.yaml에서 metrics.disablePrometheusPipeline을 true로 설정합니다.
측정항목 기반 알림을 구성했으면 Hybrid 설치에 올바른 측정항목을 사용하고 있는지 확인합니다. 자세한 내용은 측정항목 기반 알림을 참조하세요.

버전 1.12로 업그레이드를 시작하기 전 고려사항

Apigee Hybrid 버전 1.11에서 버전 1.12로 업그레이드하면 Cassandra 데이터베이스를 버전 3.11.x에서 버전 4.x로 업그레이드할 수 있습니다. Cassandra 업그레이드는 Apigee Hybrid 업그레이드 절차의 일부로 처리되지만 다음을 고려하여 계획을 세우세요.

Cassandra 버전 업그레이드는 백그라운드에서 진행되고 한 번에 1개의 포드(또는 Cassandra 노드)에서 수행되므로 업그레이드 중에 데이터베이스 용량 축소를 계획해야 합니다.
Cassandra 용량을 확장하고 업그레이드를 시작하기 전에 디스크 사용률이 50%에 도달했거나 미만인지 확인합니다.
Cassandra 백업 및 복원 절차를 검증하고 테스트합니다.
업그레이드를 시작하고 백업을 검증하기 전에 Hybrid 버전 1.11 설치에서 Cassandra 데이터를 백업합니다.
apigee-datastore를 업그레이드하면 Cassandra에서 수행하는 업그레이드 후 작업으로 인해 일시적으로 CPU 사용량이 증가합니다.
apigee-datastore(Cassandra) 구성요소를 업그레이드한 다음에는 이 구성요소를 이전 버전으로 다시 롤백할 수 없습니다. apigee-datastore 구성요소를 업그레이드한 후 Hybrid v1.12로 업그레이드를 롤백하는 두 가지 상황은 다음과 같습니다.
- apigee-datastore 구성요소는 정상 상태이지만 다른 구성요소에 롤백이 필요한 경우 다른 구성요소를 개별적으로 롤백할 수 있습니다.
  참고: 다양한 Hybrid 버전의 구성요소를 실행하는 동안에는 리전을 추가하거나 Cassandra 노드를 확장할 수 없습니다.
- apigee-datastore 구성요소가 잘못된 상태이면 v1.11 백업에서 v1.11 설치로 복원해야 합니다.
  참고: 복원할 때는 버전을 혼합할 수 없습니다. v1.11 설치에서 수행된 백업은 v1.11 설치로 복원해야 합니다.

단일 리전 설치를 업그레이드하기 전 고려사항

이전 버전의 Apigee Hybrid로 롤백해야 하는 경우 프로세스에 다운타임이 필요할 수 있습니다. 따라서 단일 리전 설치를 업그레이드하는 경우 두 번째 리전을 만들고 다음 순서로 한 번에 한 리전만 업그레이드할 수 있습니다.

동일한 Hybrid 버전을 사용하여 기존 설치에 두 번째 리전을 추가합니다. 버전 1.11 문서의 멀티 리전 배포를 참조하세요.
업그레이드를 시작하기 전에 첫 번째 리전에서 데이터를 백업하고 검증합니다. 버전 1.11 문서의 Cassandra 백업 개요를 참조하세요.
새로 추가된 리전을 Hybrid 1.12로 업그레이드합니다.
트래픽을 새 리전으로 전환하고 트래픽을 검증합니다.
검증이 완료되면 이전 리전을 Hybrid 1.12로 업그레이드합니다.
모든 트래픽을 이전 리전으로 다시 전환하고 트래픽을 검증합니다.
새 리전을 사용 중단합니다.

멀티 리전 설치를 업그레이드하기 전 고려사항

Apigee는 다음 순서로 멀티 리전 설치를 업그레이드할 것을 권장합니다.

업그레이드를 시작하기 전에 각 리전에서 데이터를 백업하고 검증합니다.
한 리전에서 Hybrid 버전을 업그레이드하고 모든 포드가 실행 중 상태인지 확인하여 업그레이드를 검증합니다.
새로 업그레이드된 리전에서 트래픽을 검증합니다.
이전 리전에서 트래픽을 검증한 후에만 각 후속 리전을 업그레이드합니다.
멀티 리전 배포에서 업그레이드를 롤백해야 할 가능성이 있으면 실패한 리전에서 트래픽을 전환할 준비를 하고 두 리전의 트래픽을 처리할 수 있도록 트래픽이 전환되는 리전에 충분한 용량을 추가하는 것을 고려합니다.

기본 요건

Hybrid 버전 1.12로 업그레이드하기 전 설치가 다음 요구사항을 충족하는지 확인합니다.

Helm으로 관리되는 Apigee Hybrid 버전 1.11 설치
- apigeectl로 Hybrid 설치를 관리하는 경우 먼저 클러스터를 Helm 관리로 마이그레이션해야 합니다. Hybrid v1.11 문서의 apigeectl에서 Helm으로 Apigee Hybrid 마이그레이션을 참조하세요.
- Hybrid 설치에서 v1.11 이전 버전을 실행하는 경우 v1.12로 업그레이드하기 전에 버전 1.11로 업그레이드해야 합니다. Apigee Hybrid 버전 1.11로 업그레이드를 참조하세요.
Helm 버전 v3.10 이상
kubectl 버전 1.27, 1.28 또는 1.29(권장)
cert-manager 버전 v1.13.0 필요한 경우 아래의 버전으로 업그레이드 준비 섹션에서 cert-manager를 업그레이드합니다.

제한사항

Apigee Hybrid 버전 1.11에서 버전 1.12로 업그레이드를 계획할 때는 다음 제한사항에 유의하세요. 계획은 업그레이드 후 롤백 또는 복원이 필요한 경우 다운타임의 필요성을 줄이는 데 도움이 됩니다.

두 버전 간의 비호환성으로 인해 Hybrid 1.12의 백업을 Hybrid 1.11에서 복원할 수 없으며, 그 반대의 경우도 마찬가지입니다.
버전 1.12로 업그레이드하는 동안에는 데이터 스토어 포드를 확장할 수 없습니다. Hybrid 설치 업그레이드를 시작하기 전에 모든 리전의 확장 요구사항을 해결하세요.
단일 리전 Hybrid 설치에서는 데이터 스토어 업그레이드 프로세스가 완료되면 데이터 스토어 구성요소를 롤백할 수 없습니다. Cassandra 4.x 데이터 스토어를 Cassandra 3.x 데이터 스토어로 다시 롤백할 수 없습니다. 이렇게 하려면 Cassandra 3.x 데이터의 최신 백업에서 복원해야 합니다(Hybrid 버전 1.11 설치).
업그레이드 중에는 리전을 삭제하거나 추가할 수 없습니다. 멀티 리전 업그레이드에서는 모든 리전의 업그레이드를 완료해야 리전을 추가하거나 삭제할 수 있습니다.

버전 1.12.0으로 업그레이드 개요

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

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

프로덕션에 영향을 미칠 가능성을 줄이기 위해 가능한 한 빨리 모든 클러스터를 업그레이드하는 것이 좋습니다. 첫 번째 클러스터를 업그레이드한 후 남은 클러스터를 모두 업그레이드해야 하는 기한은 정해져 있지 않습니다. 그러나 나머지 모든 클러스터가 업그레이드될 때까지 다음 작업이 영향을 받습니다.

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

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

업그레이드를 준비합니다.
- Cassandra를 백업합니다.
- Hybrid 설치 디렉터리를 백업합니다.
Hybrid 런타임 버전 1.12.0을 설치합니다.

버전 1.12로 업그레이드 준비

Cassandra 백업

적용 가능한 모든 리전에 Cassandra 데이터베이스를 백업하고 업그레이드를 시작하기 전 Hybrid 버전 1.11 설치에서 데이터를 검증합니다. 버전 1.11 문서의 백업 모니터링을 참조하세요.

업그레이드 프로세스를 시작하기 전에 클러스터의 모든 Cassandra 포드를 다시 시작하면 남아 있는 문제가 표시될 수 있습니다.

Cassandra 포드를 다시 시작하고 테스트하려면 한 번에 하나씩 각 포드를 개별적으로 삭제하면서 해당 포드가 실행 중 상태로 돌아가고 준비 프로브가 통과하는지 검증합니다.

Cassandra 포드를 나열합니다.

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

예를 들면 다음과 같습니다.

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

. . .

포드를 삭제합니다.

kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

예를 들면 다음과 같습니다.

kubectl delete pod -n apigee apigee-cassandra-default-0

Cassandra 포드를 다시 나열하여 상태를 확인합니다.

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

예를 들면 다음과 같습니다.

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          16s
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

. . .

동일한 구성을 사용하여 Hybrid 버전 1.12로 업그레이드할 수 있도록 마지막으로 알려진 재정의 파일을 다시 적용하여 변경 사항이 없는지 확인합니다.

모든 리전의 모든 Cassandra 노드가 UN(Up/Normal) 상태인지 확인합니다. Cassandra 노드가 다른 상태에 있으면 업그레이드를 시작하기 전에 먼저 이 문제를 해결하세요.

다음 명령어를 사용하여 Cassandra 노드의 상태를 확인할 수 있습니다.

Cassandra 포드를 나열합니다.

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

예를 들면 다음과 같습니다.

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h
apigee-cassandra-default-3   1/1     Running   0          16m
apigee-cassandra-default-4   1/1     Running   0          14m
apigee-cassandra-default-5   1/1     Running   0          13m
apigee-cassandra-default-6   1/1     Running   0          9m
apigee-cassandra-default-7   1/1     Running   0          9m
apigee-cassandra-default-8   1/1     Running   0          8m

kubectl nodetool status 명령어를 사용하여 각 Cassandra 포드의 노드 상태를 확인합니다.

kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME nodetool status

예를 들면 다음과 같습니다.

kubectl -n apigee exec -it apigee-cassandra-default-0 nodetool status
Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.16.2.6    690.17 KiB  256          48.8%             b02089d1-0521-42e1-bbed-900656a58b68  ra-1
UN  10.16.4.6    705.55 KiB  256          51.6%             dc6b7faf-6866-4044-9ac9-1269ebd85dab  ra-1
UN  10.16.11.11  674.36 KiB  256          48.3%             c7906366-6c98-4ff6-a4fd-17c596c33cf7  ra-1
UN  10.16.1.11   697.03 KiB  256          49.8%             ddf221aa-80aa-497d-b73f-67e576ff1a23  ra-1
UN  10.16.5.13   703.64 KiB  256          50.9%             2f01ac42-4b6a-4f9e-a4eb-4734c24def95  ra-1
UN  10.16.8.15   700.42 KiB  256          50.6%             a27f93af-f8a0-4c88-839f-2d653596efc2  ra-1
UN  10.16.11.3   697.03 KiB  256          49.8%             dad221ff-dad1-de33-2cd3-f1.672367e6f  ra-1
UN  10.16.14.16  704.04 KiB  256          50.9%             1feed042-a4b6-24ab-49a1-24d4cef95473  ra-1
UN  10.16.16.1   699.82 KiB  256          50.6%             beef93af-fee0-8e9d-8bbf-efc22d653596  ra-1

Hybrid 설치 디렉터리 백업

이 안내에서는 Helm 차트를 설치한 파일 시스템의 디렉터리에 환경 변수 APIGEE_HELM_CHARTS_HOME을 사용합니다. 필요한 경우 디렉터리를 이 디렉터리로 변경하고 다음 명령어를 사용하여 변수를 정의합니다.
Linux
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
MacOS
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
Windows
```
set APIGEE_HELM_CHARTS_HOME=%CD%
echo %APIGEE_HELM_CHARTS_HOME%
```
버전 1.11 $APIGEE_HELM_CHARTS_HOME/ 디렉터리의 백업 복사본을 만듭니다. 모든 백업 프로세스를 사용할 수 있습니다. 예를 들어 다음을 사용하여 전체 디렉터리의 tar 파일을 만들 수 있습니다.
```
tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.11-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Cassandra 백업 및 복구의 안내에 따라 Cassandra 데이터베이스를 백업합니다.

서비스 계정 인증에 대한 재정의에 서비스 인증서 파일(.json)을 사용하는 경우 서비스 계정 인증서 파일이 올바른 Helm 차트 디렉터리에 있는지 확인합니다. Helm 차트는 각 차트 디렉터리 외부의 파일을 읽을 수 없습니다.

Kubernetes 보안 비밀이나 워크로드 아이덴티티를 사용하여 서비스 계정을 인증하는 경우에는 이 단계가 필요하지 않습니다.

다음 표에서는 설치 유형에 따라 각 서비스 계정 파일의 대상을 보여줍니다.

프로덕션

서비스 계정	기본 파일 이름	Helm 차트 디렉터리
`apigee-cassandra`	`PROJECT_ID-apigee-cassandra.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/`
`apigee-logger`	`PROJECT_ID-apigee-logger.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-mart`	`PROJECT_ID-apigee-mart.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-metrics`	`PROJECT_ID-apigee-metrics.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-runtime`	`PROJECT_ID-apigee-runtime.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env`
`apigee-synchronizer`	`PROJECT_ID-apigee-synchronizer.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env/`
`apigee-udca`	`PROJECT_ID-apigee-udca.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-watcher`	`PROJECT_ID-apigee-watcher.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`

비프로덕션

다음 디렉터리 각각에 apigee-non-prod 서비스 계정 파일의 사본을 만듭니다.

서비스 계정	기본 파일 이름	Helm 차트 디렉터리
`apigee-non-prod`	`PROJECT_ID-apigee-non-prod.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/` `$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/` `$APIGEE_HELM_CHARTS_HOME/apigee-org/` `$APIGEE_HELM_CHARTS_HOME/apigee-env/`

TLS 인증서와 키 파일(.crt, .key 또는 .pem)이 $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/ 디렉터리에 있는지 확인합니다.

Kubernetes 버전 업그레이드

Kubernetes 플랫폼 버전을 확인하고 필요한 경우 Kubernetes 플랫폼을 Hybrid 1.11 및 Hybrid 1.12 모두에서 지원하는 버전으로 업그레이드합니다. 도움이 필요하면 플랫폼 문서를 참조하세요.

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

	1.9 ⁽³⁾	1.10	1.11	1.12
Anthos(Google Cloud - GKE)	1.23.x 1.24.x 1.25.x 1.26.x^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x
Anthos(AWS)	1.12.x 1.13.x(K8s v1.24.x) 1.14.x(K8s v1.25.x)	1.13.x (K8s v1.24.x) 1.14.x(K8s v1.25.x) 1.26.x⁽¹³⁾	1.14.x(K8s v1.25.x) 1.26.x⁽¹³⁾ 1.27.x	1.26.x⁽¹³⁾ 1.27.x 1.28.x
Anthos(Azure)	1.12.x 1.13.x 1.14.x	1.13.x 1.14.x 1.26.x⁽¹³⁾	1.14.x 1.26.x⁽¹³⁾ 1.27.x	1.26.x⁽¹³⁾ 1.27.x 1.28.x
Anthos(온프레미스 - VMware) ⁽¹⁾ ⁽¹⁴⁾	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x(K8s v1.26.x)	1.13.x 1.14.x 1.15.x(K8s v1.26.x) 1.16.x(K8s v1.27.x)	1.14.x 1.15.x(K8s v1.26.x) 1.16.x(K8s v1.27.x)	1.15.x(K8s v1.26.x) 1.16.x(K8s v1.27.x) 1.28.x⁽¹³⁾
Anthos(베어메탈)⁽¹⁾	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x(K8s v1.25.x) 1.15.x(K8s v1.26.x) 1.16.x(K8s v1.27.x)	1.14.x 1.15.x(K8s v1.26.x) 1.16.x(K8s v1.27.x)	1.15.x(K8s v1.26.x) 1.16.x(K8s v1.27.x) 1.28.x⁽¹³⁾
EKS⁽⁷⁾	1.23.x 1.24.x 1.25.x 1.26.x	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x
AKS⁽⁷⁾	1.23.x 1.24.x 1.25.x 1.26.x^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x
OpenShift⁽⁷⁾	4.10 4.11	4.11 4.12	4.12 4.13 4.14	4.12 4.13 4.14 4.15
Rancher Kubernetes Engine(RKE)⁽⁷⁾	1.3.8	v1.26.2+rke2r1	v1.26.2+rke2r1 v1.27.x	v1.26.2+rke2r1 v1.27.x v1.28.x
구성요소	1.9 ⁽³⁾	1.10	1.11	1.12
Anthos Service Mesh(ASM)	1.17.x⁽¹¹⁾	1.17.x⁽¹¹⁾	1.18.x⁽¹¹⁾	1.19.x⁽¹¹⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.10.x 1.11.x	1.10.x 1.11.x 1.12.x	1.11.x 1.12.x 1.13.x	1.11.x 1.12.x 1.13.x
Cassandra	3.11	3.11	3.11	4.0
Kubernetes	1.23.x 1.24.x 1.25.x	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x
kubectl				1.27.x 1.28.x 1.29.x
Helm		3.10+	3.10+	3.14.2+
Secret Store CSI 드라이버			1.3.4	1.4.1
Vault			1.13.x	1.15.2
⁽¹⁾ 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로 업그레이드하고 Hybrid 클러스터에 더 이상 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 버전 및 업그레이드 지원을 참조하세요. ⁽¹⁴⁾ Vault는 Anthos(온프레미스 - VMware)에서 인증되지 않습니다.

연결된 클러스터 정보

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 연결 클러스터는 선택사항입니다.

Hybrid 1.12.0 런타임 설치

Helm 차트 업그레이드 준비

Apigee Helm 차트를 가져옵니다.

Apigee Hybrid 차트는 Google Artifact Registry에서 호스팅됩니다.

oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts

pull 명령어를 사용하여 다음 명령어로 모든 Apigee Hybrid Helm 차트를 로컬 스토리지에 복사합니다.

export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
export CHART_VERSION=1.12.0
helm pull $CHART_REPO/apigee-operator --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-datastore --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-ingress-manager --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-org --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-redis --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-telemetry --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-virtualhost --version $CHART_VERSION --untar

필요한 경우 cert-manager를 업그레이드합니다.
cert-manager 버전을 업그레이드해야 하는 경우 다음 명령어를 사용하여 새 버전을 설치합니다.
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml
```

업데이트된 Apigee CRD를 설치합니다.

참고: Apigee CRD를 설치하는 데 지원되는 유일한 방법입니다. -k 없이 kubectl apply를 사용하지 말고 --server-side를 생략하지 마세요.

다음 명령어를 실행하여 kubectl 테스트 실행 기능을 사용합니다.

kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false --dry-run=server

테스트 실행 명령어로 유효성을 검사한 후 다음 명령어를 실행합니다.

kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false

kubectl get crds 명령어를 사용하여 설치를 검증합니다.

kubectl get crds | grep apigee

출력이 다음과 같이 표시됩니다.

apigeedatastores.apigee.cloud.google.com                    2023-10-09T14:48:30Z
apigeedeployments.apigee.cloud.google.com                   2023-10-09T14:48:30Z
apigeeenvironments.apigee.cloud.google.com                  2023-10-09T14:48:31Z
apigeeissues.apigee.cloud.google.com                        2023-10-09T14:48:31Z
apigeeorganizations.apigee.cloud.google.com                 2023-10-09T14:48:32Z
apigeeredis.apigee.cloud.google.com                         2023-10-09T14:48:33Z
apigeerouteconfigs.apigee.cloud.google.com                  2023-10-09T14:48:33Z
apigeeroutes.apigee.cloud.google.com                        2023-10-09T14:48:33Z
apigeetelemetries.apigee.cloud.google.com                   2023-10-09T14:48:34Z
cassandradatareplications.apigee.cloud.google.com           2023-10-09T14:48:35Z

클러스터 노드의 라벨을 확인합니다. 기본적으로 Apigee는 cloud.google.com/gke-nodepool=apigee-data 라벨이 있는 노드의 데이터 포드를 예약하고 런타임 포드는 cloud.google.com/gke-nodepool=apigee-runtime 라벨이 있는 노드에 예약됩니다. overrides.yaml 파일에서 노드 풀 라벨을 맞춤설정할 수 있습니다.

자세한 내용은 전용 노드 풀 구성을 참조하세요.

Apigee Hybrid Helm 차트 설치

참고: Helm 업그레이드/설치 명령어를 실행하기 전에 명령어 끝에 --dry-run를 추가하여 Helm 테스트 실행 기능을 사용하세요. 지원되는 명령어, 옵션, 사용량을 나열하려면 helm -h를 확인하세요.

그렇지 않은 경우에는 APIGEE_HELM_CHARTS_HOME 디렉터리로 이동합니다. 해당 디렉터리에서 다음 명령어를 실행합니다.

Apigee Operator/Controller를 업그레이드합니다.

참고: 이 단계에는 승격된 클러스터 권한이 필요합니다. 자세한 내용은 helm -h 또는 helm upgrade -h를 실행하세요.

테스트 실행을 수행합니다.

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  -f OVERRIDES_FILE \
  --dry-run

차트를 업그레이드합니다.

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  -f OVERRIDES_FILE

참고: 마이그레이션된 설치에는 다음을 사용하세요.

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  --force \
  -f OVERRIDES_FILE

Apigee 운영자 설치를 확인합니다.

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.0   1.12.0

가용성을 확인하여 실행 중인지 확인합니다.

kubectl -n apigee-system get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

Apigee Datastore를 업그레이드합니다.

테스트 실행을 수행합니다.

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

차트를 업그레이드합니다.

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

참고: 마이그레이션된 설치에는 다음을 사용하세요.

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

상태를 확인하여 apigeedatastore가 실행 중인지 확인합니다.

kubectl -n apigee get apigeedatastore default

NAME      STATE       AGE
default   running    2d

Apigee 원격 분석을 업그레이드합니다.

테스트 실행을 수행합니다.

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

차트를 업그레이드합니다.

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

참고: 마이그레이션된 설치에는 다음을 사용하세요.

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

상태를 확인하여 실행 중인지 확인합니다.

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Apigee Redis를 업그레이드합니다.

테스트 실행을 수행합니다.

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

차트를 업그레이드합니다.

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

참고: 마이그레이션된 설치에는 다음을 사용하세요.

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

상태를 확인하여 실행 중인지 확인합니다.

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Apigee 인그레스 관리자를 업그레이드합니다.

테스트 실행을 수행합니다.

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

차트를 업그레이드합니다.

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

참고: 마이그레이션된 설치에는 다음을 사용하세요.

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

가용성을 확인하여 실행 중인지 확인합니다.

kubectl -n apigee get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

Apigee 조직을 업그레이드합니다.

테스트 실행을 수행합니다.

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

차트를 업그레이드합니다.

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

참고: 마이그레이션된 설치에는 다음을 사용하세요.

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

해당 조직의 상태를 확인하여 실행 중인지 확인합니다.

kubectl -n apigee get apigeeorg

NAME                      STATE     AGE
apigee-org1-xxxxx          running   2d

환경을 업그레이드합니다.
한 번에 환경 하나만 설치해야 합니다. --set env=ENV_NAME으로 환경을 지정합니다.

테스트 실행을 수행합니다.
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run
```
- ENV_RELEASE_NAME은 이전에 apigee-env 차트를 설치한 이름입니다. Hybrid v1.10에서는 일반적으로 apigee-env-ENV_NAME입니다. Hybrid v1.11 이상에서는 일반적으로 ENV_NAME입니다.
- ENV_NAME은 업그레이드하는 환경의 이름입니다.
- OVERRIDES_FILE은 v.1.12.0의 새로운 재정의 파일입니다.
차트를 업그레이드합니다.
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
참고: 마이그레이션된 설치에는 다음을 사용하세요.
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  --force \
  -f OVERRIDES_FILE
```
해당 환경의 상태를 확인하여 실행 중인지 확인합니다.
```
kubectl -n apigee get apigeeenv
```
```
NAME                          STATE       AGE   GATEWAYTYPE
apigee-org1-dev-xxx            running     2d
```
환경 그룹(virtualhosts)을 업그레이드합니다.
1. 한 번에 환경 그룹(virtualhost) 하나만 설치해야 합니다. --set envgroup=ENV_GROUP_NAME으로 환경 그룹을 지정합니다. override.yaml 파일에 언급된 환경 그룹마다 다음 명령어를 반복합니다.
  테스트 실행을 수행합니다.
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE \
  --dry-run
```
  ENV_GROUP_RELEASE_NAME은 이전에 apigee-virtualhost 차트를 설치한 이름입니다. Hybrid v1.10에서는 일반적으로 apigee-virtualhost-ENV_GROUP_NAME입니다. Hybrid v1.11 이상에서는 일반적으로 ENV_GROUP_NAME입니다.
  
  차트를 업그레이드합니다.
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE
```
  참고: 마이그레이션된 설치에는 다음을 사용하세요.
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  --force \
  -f OVERRIDES_FILE
```
  참고: ENV_GROUP_NAME은 apigee 네임스페이스 내에서 고유해야 합니다. 예를 들어 prod 환경 및 환경 그룹이 있으면 이 이름을 prod-envgroup으로 설정해야 합니다. 이후 환경 그룹 이름은 prod여야 합니다.
2. ApigeeRoute(AR) 상태를 확인합니다.
  virtualhosts를 설치하면 Apigee 감시자가 제어 영역에서 환경 그룹 관련 세부정보를 가져온 후 내부적으로 ApigeeRoute(AR)를 만드는 ApigeeRouteConfig(ARC)가 생성됩니다. 따라서 해당 AR 상태가 실행 중인지 확인합니다.
```
kubectl -n apigee get arc
```
```
NAME                                STATE   AGE
apigee-org1-dev-egroup                       2d
```
```
kubectl -n apigee get ar
```
```
NAME                                        STATE     AGE
apigee-org1-dev-egroup-xxxxxx                running   2d
```

이전 버전으로 롤백

이 섹션은 Apigee Hybrid 버전 1.12로 업그레이드한 후 apigee-datastore 구성요소의 상태에 따라 여러 섹션으로 나뉩니다. apigee-datastore구성요소가 정상 상태인 단일 리전 또는 멀티 리전 롤백 절차와 apigee-datastore가 잘못된 상태일 때 백업에서 복구 또는 복원하는 절차가 있습니다.

단일 리전 롤백 및 복구

`apigee-datastore`가 정상 상태이면 롤백

이 절차에서는 apigee-datastore를 제외하고 v1.12에서 v1.11로 모든 Apigee Hybrid 구성요소를 롤백하는 방법을 설명합니다. v1.12 apigee-datastore 구성요소는 Hybrid v1.11 구성요소와 하위 호환됩니다.

경고: apigee-datastore를 롤백할 수 없습니다. Cassandra 데이터베이스의 여러 버전 간의 데이터 비호환성으로 인해 이전 버전으로 롤백되지 않습니다.

단일 리전 설치를 버전 1.11로 롤백하려면 다음 안내를 따르세요.

롤백을 시작하기 전에 모든 포드가 실행 중 상태인지 확인합니다.
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

Helm을 사용하여 구성요소의 출시 버전을 검증합니다.

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

예를 들면 다음과 같습니다.

helm -n apigee list
NAME              NAMESPACE   REVISION   UPDATED                                   STATUS     CHART                           APP VERSION
datastore         apigee      2          2024-03-29 17:08:07.917848253 +0000 UTC   deployed   apigee-datastore-1.12.0         1.12.0
ingress-manager   apigee      2          2024-03-29 17:21:02.917333616 +0000 UTC   deployed   apigee-ingress-manager-1.12.0   1.12.0
redis             apigee      2          2024-03-29 17:19:51.143728084 +0000 UTC   deployed   apigee-redis-1.12.0             1.12.0
telemetry         apigee      2          2024-03-29 17:16:09.883885403 +0000 UTC   deployed   apigee-telemetry-1.12.0         1.12.0
myhybridorg       apigee      2          2024-03-29 17:21:50.899855344 +0000 UTC   deployed   apigee-org-1.12.0               1.12.0

다음 명령어를 사용하여 apigee-datastore을 제외한 각 구성요소를 롤백합니다.

다음 환경 변수를 만듭니다.
- PREVIOUS_HELM_CHARTS_HOME: 이전 Apigee Hybrid Helm 차트가 설치된 디렉터리입니다. 롤백할 버전입니다.
virtualhost를 롤백합니다. 재정의 파일에 언급된 환경 그룹마다 다음 명령어를 반복합니다.
```
helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
ENV_GROUP_RELEASE_NAME은 이전에 apigee-virtualhost 차트를 설치한 이름입니다. Hybrid v1.10에서는 일반적으로 apigee-virtualhost-ENV_GROUP_NAME입니다. Hybrid v1.11 이상에서는 일반적으로 ENV_GROUP_NAME입니다.
환경을 롤백합니다. 재정의 파일에 언급된 환경마다 다음 명령어를 반복합니다.
```
helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
ENV_RELEASE_NAME은 이전에 apigee-env 차트를 설치한 이름입니다. Hybrid v1.10에서는 일반적으로 apigee-env-ENV_NAME입니다. Hybrid v1.11 이상에서는 일반적으로 ENV_NAME입니다.

해당 환경의 상태를 확인하여 실행 중인지 확인합니다.
```
kubectl -n apigee get apigeeenv
```
```
NAME                  STATE     AGE   GATEWAYTYPE
apigee-org1-dev-xxx   running   2d
```

조직을 롤백합니다.

helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

해당 조직의 상태를 확인하여 실행 중인지 확인합니다.

kubectl -n apigee get apigeeorg

NAME                STATE     AGE
apigee-org1-xxxxx   running   2d

인그레스 관리자를 롤백합니다.

helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

가용성을 확인하여 실행 중인지 확인합니다.

kubectl -n apigee get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

Redis를 롤백합니다.

helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

상태를 확인하여 실행 중인지 확인합니다.

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Apigee 원격 분석을 롤백합니다.

helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

상태를 확인하여 실행 중인지 확인합니다.

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Apigee Controller를 롤백합니다.

helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Apigee 운영자 설치를 확인합니다.

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.0   1.12.0

가용성을 확인하여 실행 중인지 확인합니다.

kubectl -n apigee-system get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

Apigee Hybrid CRD를 롤백합니다.

kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false

모든 포드가 실행 중이거나 완료된 상태인지 확인합니다.
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

모든 구성요소의 출시 버전을 검증합니다. Datastore를 제외한 모든 구성요소는 이전 버전이어야 합니다.

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

예를 들면 다음과 같습니다.

helm -n apigee  list
NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

`apigee-datastore`이 정상 상태가 아니면 복원

apigee-datastore 구성요소의 업그레이드에 실패하면 apigee-datastore를 버전 1.12에서 버전 1.11로 롤백할 수 없습니다. 대신 v1.11 설치로 수행된 백업에서 복원해야 합니다. 다음 순서로 이전 버전을 복원합니다.

Apigee Hybrid 버전 1.11의 활성 설치가 없는 경우(예: 다른 리전) 백업된 차트와 재정의 파일을 사용하여 v1.11의 새 설치를 만듭니다. Apigee Hybrid 버전 1.11 설치 안내를 참조하세요.
다음 안내에 따라 백업에서 v1.11 리전(또는 새 설치)을 복원합니다.
- Cloud Storage 인터페이스(CSI) 백업: Cassandra CSI 백업 및 복원
- CSI가 아닌 백업: 단일 리전에서 복원
복원된 설치에 대한 트래픽 확인
선택사항: Hybrid 런타임 제거의 안내에 따라 버전 1.12 설치를 삭제합니다.

멀티 리전 롤백 및 복구

`apigee-datastore`가 정상 상태이면 롤백

롤백을 시작하기 전에 모든 포드가 실행 중 상태인지 확인합니다.
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

모든 리전의 모든 Cassandra 노드가 UN(Up/Normal) 상태인지 확인합니다. Cassandra 노드가 다른 상태에 있으면 업그레이드 프로세스를 시작하기 전에 먼저 이 문제를 해결하세요.

다음 명령어를 사용하여 Cassandra 노드의 상태를 확인할 수 있습니다.

Cassandra 포드를 나열합니다.

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

예를 들면 다음과 같습니다.

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h
apigee-cassandra-default-3   1/1     Running   0          16m
apigee-cassandra-default-4   1/1     Running   0          14m
apigee-cassandra-default-5   1/1     Running   0          13m
apigee-cassandra-default-6   1/1     Running   0          9m
apigee-cassandra-default-7   1/1     Running   0          9m
apigee-cassandra-default-8   1/1     Running   0          8m

kubectl nodetool status 명령어를 사용하여 각 Cassandra 포드의 노드 상태를 확인합니다.

kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME -- nodetool -u JMX_USER -pw JMX_PASSWORD

예를 들면 다음과 같습니다.

kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u jmxuser -pw JMX_PASSWORD status
Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens   Owns (effective)   Host ID                                Rack
UN  10.16.2.6    690.17 KiB  256      48.8%              b02089d1-0521-42e1-bbed-900656a58b68   ra-1
UN  10.16.4.6    705.55 KiB  256      51.6%              dc6b7faf-6866-4044-9ac9-1269ebd85dab   ra-1
UN  10.16.11.11  674.36 KiB  256      48.3%              c7906366-6c98-4ff6-a4fd-17c596c33cf7   ra-1
UN  10.16.1.11   697.03 KiB  256      49.8%              ddf221aa-80aa-497d-b73f-67e576ff1a23   ra-1
UN  10.16.5.13   703.64 KiB  256      50.9%              2f01ac42-4b6a-4f9e-a4eb-4734c24def95   ra-1
UN  10.16.8.15   700.42 KiB  256      50.6%              a27f93af-f8a0-4c88-839f-2d653596efc2   ra-1
UN  10.16.11.3   697.03 KiB  256      49.8%              dad221ff-dad1-de33-2cd3-f1.672367e6f   ra-1
UN  10.16.14.16  704.04 KiB  256      50.9%              1feed042-a4b6-24ab-49a1-24d4cef95473   ra-1
UN  10.16.16.1   699.82 KiB  256      50.6%              beef93af-fee0-8e9d-8bbf-efc22d653596   ra-1

모든 Cassandra 포드가 UN 상태가 아니면 Cassandra 클러스터에서 DOWN 노드 삭제의 안내를 따르세요.

이전 Apigee Hybrid Helm 차트가 설치된 디렉터리로 이동합니다.
컨텍스트를 업그레이드된 리전으로 변경합니다.
```
kubectl config use-context UPGRADED_REGION_CONTEXT
    
```

모든 포드가 실행 중 상태인지 확인합니다.

kubectl get pods -n APIGEE_NAMESPACE

kubectl get pods -n apigee-system

helm 명령어를 사용하여 모든 출시 버전이 Hybrid v1.12로 업그레이드되었는지 확인합니다.

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

예를 들면 다음과 같습니다.

helm -n apigee list
NAME             NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore        apigee     2         2024-03-29 17:08:07.917848253 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager  apigee     2         2024-03-29 17:21:02.917333616 +0000 UTC  deployed  apigee-ingress-manager-1.12.0  1.12.0
redis            apigee     2         2024-03-29 17:19:51.143728084 +0000 UTC  deployed  apigee-redis-1.12.0            1.12.0
telemetry        apigee     2         2024-03-29 17:16:09.883885403 +0000 UTC  deployed  apigee-telemetry-1.12.0        1.12.0
myhybridorg      apigee     2         2024-03-29 17:21:50.899855344 +0000 UTC  deployed  apigee-org-1.12.0              1.12.0

다음 명령어를 사용하여 apigee-datastore을 제외한 각 구성요소를 롤백합니다.

다음 환경 변수를 만듭니다.
- PREVIOUS_HELM_CHARTS_HOME: 이전 Apigee Hybrid Helm 차트가 설치된 디렉터리입니다. 롤백할 버전입니다.
virtualhost를 롤백합니다. 재정의 파일에 언급된 환경 그룹마다 다음 명령어를 반복합니다.
```
helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
ENV_GROUP_RELEASE_NAME은 이전에 apigee-virtualhost 차트를 설치한 이름입니다. Hybrid v1.10에서는 일반적으로 apigee-virtualhost-ENV_GROUP_NAME입니다. Hybrid v1.11 이상에서는 일반적으로 ENV_GROUP_NAME입니다.
환경을 롤백합니다. 재정의 파일에 언급된 환경마다 다음 명령어를 반복합니다.
```
helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
ENV_RELEASE_NAME은 이전에 apigee-env 차트를 설치한 이름입니다. Hybrid v1.10에서는 일반적으로 apigee-env-ENV_NAME입니다. Hybrid v1.11 이상에서는 일반적으로 ENV_NAME입니다.

각 환경의 상태를 확인하여 해당 환경이 실행 중인지 확인합니다.
```
kubectl -n apigee get apigeeenv
```
```
NAME                  STATE     AGE   GATEWAYTYPE
apigee-org1-dev-xxx   running   2d
```

조직을 롤백합니다.

helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

해당 조직의 상태를 확인하여 실행 중인지 확인합니다.

kubectl -n apigee get apigeeorg

NAME                STATE     AGE
apigee-org1-xxxxx   running   2d

인그레스 관리자를 롤백합니다.

helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

가용성을 확인하여 실행 중인지 확인합니다.

kubectl -n apigee get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

Redis를 롤백합니다.

helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

상태를 확인하여 실행 중인지 확인합니다.

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Apigee 원격 분석을 롤백합니다.

helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

상태를 확인하여 실행 중인지 확인합니다.

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Apigee Controller를 롤백합니다.

helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Apigee 운영자 설치를 확인합니다.

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.0   1.12.0

가용성을 확인하여 실행 중인지 확인합니다.

kubectl -n apigee-system get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

Apigee Hybrid CRD를 롤백합니다.

kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false

모든 구성요소의 출시 버전을 검증합니다. datastore를 제외한 모든 구성요소는 이전 버전이어야 합니다.

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

예를 들면 다음과 같습니다.

helm -n apigee  list
NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

이제 datastore를 제외한 모든 출시 버전이 이전 버전으로 롤백되었습니다.

멀티 리전 설치를 이전 버전으로 복구

여러 리전 설치에서 참조를 삭제하여 멀티 리전 업그레이드에서 업그레이드가 실패한 리전을 복구합니다. 이 방법은 Hybrid 1.11에 라이브 리전이 1개 이상 있는 경우에만 사용할 수 있습니다. v1.12 데이터 스토어는 v1.11 구성요소와 호환됩니다.

정상 상태 리전에서 실패한 리전을 복구하려면 다음 단계를 수행합니다.

영향을 받는 리전에서 정상 작동하는 리전으로 API 트래픽을 리디렉션합니다. 실패한 리전에서 변경된 트래픽을 지원할 수 있도록 용량을 계획합니다.
영향을 받는 리전을 사용 중단합니다. 영향을 받는 각 리전에 대해 하이브리드 리전 해제에 설명된 단계를 따르세요. 사용 중단이 완료될 때까지 기다린 후 다음 단계로 이동합니다.
실패한 업그레이드에서 리전 복구의 안내에 따라 실패한 리전을 정리합니다.
영향을 받은 리전을 복구합니다. 복구하려면 GKE, GKE On-Prem, AKS의 멀티 리전 배포에 설명된 대로 새 리전을 만듭니다.

잘못된 상태의 `apigee-datastore`를 사용하여 백업에서 멀티 리전 설치 복원

apigee-datastore 구성요소의 업그레이드에 실패하면 버전 1.12에서 버전 1.11로 롤백할 수 없습니다. 대신 v1.11 설치로 수행된 백업에서 복원해야 합니다. 다음 순서로 이전 버전을 복원합니다.

Apigee Hybrid 버전 1.11의 활성 설치가 없는 경우(예: 다른 리전) 백업된 차트와 재정의 파일을 사용하여 v1.11의 새 설치를 만듭니다. Apigee Hybrid 버전 1.11 설치 안내를 참조하세요.
다음 안내에 따라 백업에서 v1.11 리전(또는 새 설치)을 복원합니다.
- Cloud Storage 인터페이스(CSI) 백업: Cassandra CSI 백업 및 복원
- CSI가 아닌 백업: 여러 리전에서 복원
복원된 설치에 대한 트래픽 확인
멀티 리전 설치의 경우 다음 리전을 다시 빌드하고 복원합니다. 여러 리전에서 복원의 백업에서 복원의 안내를 참조하세요.
Hybrid 런타임 제거의 안내에 따라 버전 1.12 설치를 삭제합니다.

부록: 실패한 업그레이드에서 리전 복구

1.11에서 1.12로의 업그레이드가 실패하면 데이터 센터를 삭제합니다.

라이브 리전에서 Cassandra 클러스터 상태를 검증합니다.

kubectl 컨텍스트를 삭제할 리전으로 전환합니다.
```
kubectl config use-context CONTEXT_OF_LIVE_REGION
```

Cassandra 포드를 나열합니다.

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

예를 들면 다음과 같습니다.

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                 READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

Cassandra 포드 중 하나에 실행합니다.

kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash

Cassandra 클러스터의 상태를 검증합니다.

nodetool -u JMX_USER -pw JMX_PASSWORD status

출력이 다음과 같이 표시됩니다.

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.48.12.16  813.84 KiB  256          100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.14.16  859.89 KiB  256          100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
UN  10.48.0.18   888.95 KiB  256          100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1

라이브 리전의 Cassandra 포드 IP만 표시되고 모든 IP가 동일한 스키마 버전에 표시되는지 확인하기 위해 클러스터를 설명합니다.

nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

출력이 다음과 같이 표시됩니다.

nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

Schema versions:
    4bebf2de-0582-31b4-9c5f-e36f60127e1b: [10.48.14.16, 10.48.12.16, 10.48.0.18]

Cassandra 키스페이스 복제를 정리합니다.

user-setup 작업을 가져와 삭제합니다. 새 user-setup 작업이 즉시 생성됩니다.

kubectl get jobs -n APIGEE_NAMESPACE

예를 들면 다음과 같습니다.

kubectl get jobs -n apigee
  NAME                                                           COMPLETIONS   DURATION   AGE
  apigee-cassandra-schema-setup-myhybridorg-8b3e61d          1/1           6m35s      3h5m
  apigee-cassandra-schema-val-myhybridorg-8b3e61d-28499150   1/1           10s        9m22s
 apigee-cassandra-user-setup-myhybridorg-8b3e61d            0/1           21s        21s

kubectl delete jobs USER_SETUP_JOB_NAME -n APIGEE_NAMESPACE

출력에 시작하는 새 작업이 표시됩니다.

kubectl delete jobs apigee-cassandra-user-setup-myhybridorg-8b3e61d -n apigee

  apigee-cassandra-user-setup-myhybridorg-8b3e61d-wl92b         0/1     Init:0/1    0               1s

클라이언트 컨테이너 만들기의 안내에 따라 클라이언트 컨테이너를 만들어 Cassandra 키스페이스 복제 설정을 검증합니다.

모든 키스페이스를 가져옵니다. cassandra-client 포드에 실행한 후 cqlsh 클라이언트를 시작합니다.

kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

다음 명령어를 실행하는 데 필요한 권한이 있으므로 ddl user를 사용하여 Cassandra 서버에 연결합니다.

cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

키스페이스를 가져옵니다.

select * from system_schema.keyspaces;

출력은 다음과 같아야 합니다. 여기서 dc-1은 활성 DC입니다.

select * from system_schema.keyspaces;

 keyspace_name            | durable_writes | replication
--------------------------+----------------+--------------------------------------------------------------------------------
   kvm_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
              system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
            system_schema |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
 quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
 cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   rtc_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
       system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                   system |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                   perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
            system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   kms_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}

(11 rows)

어떤 이유로든 user-setup 작업에 오류가 계속 발생하고 검증이 실패하면 다음 명령어를 사용하여 키스페이스의 복제를 수정합니다.

kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

다음 명령어를 실행하는 데 필요한 권한이 있으므로 ddl user를 사용하여 Cassandra 서버에 연결합니다.

cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

키스페이스를 가져옵니다.

select * from system_schema.keyspaces;

위 명령어에서 키스페이스 이름을 사용하고 다음 예시에서 이를 바꿉니다.

alter keyspace quota_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace kms_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace kvm_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace cache_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace perses_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace rtc_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_distributed WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_traces WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};

다음 cqlsh 명령어를 사용하여 모든 키스페이스가 올바른 리전에 복제되는지 확인합니다.

select * from system_schema.keyspaces;

예를 들면 다음과 같습니다.

select * from system_schema.keyspaces;

 keyspace_name           | durable_writes | replication
-------------------------+----------------+--------------------------------------------------------------------------------
kvm_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
          system_auth    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
        system_schema    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
rtc_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   system_distributed    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
               system    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
               perses    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
        system_traces    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
kms_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}

(11 rows)

이제 Cassandra 클러스터에서 비활성 DC에 대한 모든 참조를 완전히 삭제했습니다.

부록: Cassandra 클러스터에서 DOWN 노드 삭제

멀티 리전 설치를 롤백하고 모든 Cassandra 포드가 Up/Normal(UN) 상태가 아닌 경우 이 절차를 사용하세요.

Cassandra 포드 중 하나에 실행합니다.

kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash

Cassandra 클러스터의 상태를 검증합니다.
```
nodetool -u JMX_USER -pw JMX_PASSWORD status
```

노드가 실제로 Down(DN) 상태인지 검증합니다. Cassandra 포드를 생성할 수 없는 리전의 Cassandra 포드에 실행합니다.

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.48.12.16  1.15 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.0.18   1.21 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
UN  10.48.14.16  1.18 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1

Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
DN  10.8.4.4     432.42 KiB  256     100.0%            cd672398-5c45-4c88-a424-86d757951e53  rc-1
UN  10.8.19.6    5.8 MiB     256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
UN  10.8.21.5    5.74 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

Down(DN) 노드에 대한 참조를 삭제합니다. 위의 예시에서 호스트 10.8.4.4에 대한 참조를 삭제합니다.

kubectl exec -it -n apigee apigee-cassandra-default-2 -- /bin/bash
 nodetool -u JMX_USER -pw JMX_PASSWORD removenode HOST_ID

참조가 삭제되면 포드를 종료합니다. 새 Cassandra 포드가 나타나고 클러스터에 조인합니다.
```
kubectl delete pod -n POD_NAME
```

새 Cassandra 포드가 클러스터에 조인되었는지 확인합니다.

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.48.12.16  1.16 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.0.18   1.22 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
UN  10.48.14.16  1.19 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1

Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.8.19.6    5.77 MiB    256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
UN  10.8.4.5     246.99 KiB  256     100.0%            0182e675-eec8-4d68-a465-69211b621601  rc-1
UN  10.8.21.5    5.69 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

이제 클러스터의 나머지 리전에 대한 업그레이드 또는 롤백을 진행할 수 있습니다.

부록: 문제 해결: 롤백 후 `apigee-datastore`가 정지 상태에 있음

업그레이드 후 apigee-datastore을 Hybrid 1.11로 롤백했고 정지 상태에 있을 때 이 절차를 사용하세요.

데이터 스토어 컨트롤러 상태를 다시 수정하기 전에 releasing 상태이고 포드가 Cassandra 클러스터 상태와 함께 표시되지 않는지 확인합니다.

Helm 명령어를 사용하여 데이터 스토어가 롤백되었는지 확인합니다.

helm -n APIGEE_NAMESPACE list

예를 들면 다음과 같습니다.

helm -n apigee list
NAME              NAMESPACE  REVISION  UPDATED                                   STATUS    CHART                              APP VERSION
datastore         apigee     3         2024-04-04 22:15:08.792539892 +0000 UTC   deployed   apigee-datastore-1.11.0           1.11.0
ingress-manager   apigee     1         2024-04-02 22:24:27.564184968 +0000 UTC   deployed   apigee-ingress-manager-1.12.0     1.12.0
redis             apigee     1         2024-04-02 22:23:59.938637491 +0000 UTC   deployed   apigee-redis-1.12.0               1.12.0
telemetry         apigee     1         2024-04-02 22:23:39.458134303 +0000 UTC   deployed   apigee-telemetry-1.12             1.12.0
myhybridorg       apigee     1         2024-04-02 23:36:32.614927914 +0000 UTC   deployed   apigee-org-1.12.0                 1.12.0

Cassandra 포드의 상태를 가져옵니다.

kubectl get pods -n APIGEE_NAMESPACE

예를 들면 다음과 같습니다.

kubectl get pods -n apigee
NAME                         READY   STATUS             RESTARTS      AGE
apigee-cassandra-default-0   1/1     Running            0             2h
apigee-cassandra-default-1   1/1     Running            0             2h
apigee-cassandra-default-2   0/1     CrashLoopBackOff   4 (13s ago)   2m13s

apigeeds 컨트롤러가 출시 상태에 멈춰 있는지 확인합니다.

kubectl get apigeeds -n APIGEE_NAMESPACE

예를 들면 다음과 같습니다.

kubectl get apigeeds -n apigee
NAME      STATE       AGE
default   releasing   46h

Cassandra 노드 상태를 검증합니다(한 노드가 DN 상태이고 CrashLoopBackOff 상태에 멈춰 있음).

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

예를 들면 다음과 같습니다.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
Defaulted container "apigee-cassandra" out of: apigee-cassandra, apigee-cassandra-ulimit-init (init)
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--   Address       Load       Tokens   Owns (effective)   Host ID                               Rack
UN   10.68.7.28    2.12 MiB   256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3  rc-1
UN   10.68.10.29   2.14 MiB   256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452  rc-1
DN   10.68.6.26    5.77 MiB   256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1

1.12 차트를 사용하여 데이터 스토어를 업그레이드합니다.
참고: 컨트롤러가 다시 releasing상태로 전환되지만 이번에는 Hybrid 1.12용 이미지가 포함된 포드를 생성하고 Cassandra는 클러스터에 조인하여 UN(UP/NORMAL)이 됩니다.
```
helm upgrade datastore APIGEE_HELM_1.12.0_HOME/apigee-datastore/   --install   --namespace APIGEE_NAMESPACE   -f overrides.yaml
```

모든 포드가 Running 상태이고 Cassandra 클러스터가 다시 정상 상태인지 검증합니다.

모든 포드가 다시 READY 상태인지 확인합니다.

kubectl get pods -n APIGEE_NAMESPACE

예를 들면 다음과 같습니다.

kubectl get pods -n apigee
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          29h
apigee-cassandra-default-1   1/1     Running   0          29h
apigee-cassandra-default-2   1/1     Running   0          60m

Cassandra 클러스터 상태를 검증합니다.

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

예를 들면 다음과 같습니다.

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--   Address       Load      Tokens   Owns (effective)   Host ID                                Rack
UN   10.68.4.15    2.05 MiB  256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1
UN   10.68.7.28    3.84 MiB  256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3   rc-1
UN   10.68.10.29   3.91 MiB  256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452   rc-1

apigeeds 컨트롤러의 상태를 검증합니다.

kubectl get apigeeds -n APIGEE_NAMESPACE

예를 들면 다음과 같습니다.

kubectl get apigeeds -n apigee
NAME      STATE     AGE
default   running   2d1h

이제 데이터 스토어가 수정되었으며 running 상태여야 합니다.

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

Apigee Hybrid v1.11의 변경사항

버전 1.12로 업그레이드를 시작하기 전 고려사항

단일 리전 설치를 업그레이드하기 전 고려사항

멀티 리전 설치를 업그레이드하기 전 고려사항

기본 요건

제한사항

버전 1.12.0으로 업그레이드 개요

버전 1.12로 업그레이드 준비

Cassandra 백업

Hybrid 설치 디렉터리 백업

Linux

MacOS

Windows

프로덕션

비프로덕션

Kubernetes 버전 업그레이드

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

구성요소

연결된 클러스터 정보

Hybrid 1.12.0 런타임 설치

Helm 차트 업그레이드 준비

Apigee Hybrid Helm 차트 설치

이전 버전으로 롤백

단일 리전 롤백 및 복구

apigee-datastore가 정상 상태이면 롤백

apigee-datastore이 정상 상태가 아니면 복원

멀티 리전 롤백 및 복구

apigee-datastore가 정상 상태이면 롤백

멀티 리전 설치를 이전 버전으로 복구

잘못된 상태의 apigee-datastore를 사용하여 백업에서 멀티 리전 설치 복원

부록: 실패한 업그레이드에서 리전 복구

부록: Cassandra 클러스터에서 DOWN 노드 삭제

부록: 문제 해결: 롤백 후 apigee-datastore가 정지 상태에 있음

`apigee-datastore`가 정상 상태이면 롤백

`apigee-datastore`이 정상 상태가 아니면 복원

`apigee-datastore`가 정상 상태이면 롤백

잘못된 상태의 `apigee-datastore`를 사용하여 백업에서 멀티 리전 설치 복원

부록: 문제 해결: 롤백 후 `apigee-datastore`가 정지 상태에 있음