미리보기 사용자 가이드:
Apigee Hybrid v1.8의 새 설치 및 관리 절차를 미리봅니다.
이 문서에서는 다음과 같은 내용을 다룹니다.
- 미리보기
- 개요
- 기본 요건
- 기본 Apigee Hybrid 설치
- 맞춤설정된 Apigee Hybrid 설치
- 설정 파일 다운로드
- 네임스페이스 만들기
- 비공개 저장소의 Docker 이미지 사용(선택사항)
- imagePullSecret 구성(선택사항)
- 전달 프록시 구성(선택사항)
- 인그레스 TLS 인증서 지정
- 인그레스 배포 업데이트
- 커스텀 Google Cloud 서비스 계정 구성
- 워크로드 아이덴티티 사용
- 리소스 yaml 수정
- 초기화 리소스 및 컨트롤러 만들기
- 동기화 담당자 서비스 계정에 제어 영역과 상호작용하는 권한 부여
- Apigee 데이터 영역 구성요소 만들기
- 리소스가 시작될 때까지 대기
- 커스텀 네임스페이스의 cert-manager 설치 맞춤설정
- Kustomize 및 구성요소
- 개념
- 스크립트 이해
- Apigee Hybrid 설정 폴더 구조
- 외부 Vault에 서비스 계정 키 저장
- Apigee Hybrid 업그레이드
- Apigee Hybrid 롤백
- 삭제
- 환경 삭제
- 멀티 인스턴스 설치
미리보기
이 문서는 Apigee 작업 사용자(Apigee Hybrid 설치를 설치/유지/관리하는 사용자)를 대상으로 합니다. 이 문서의 안내를 따르기 위해서는 지원되는 Kubernetes 플랫폼 중 하나에 Apigee Hybrid를 설치해 본 경험이 있어야 합니다. Apigee 평가 조직을 만들어 아래 단계를 시도해 보는 것이 좋습니다.
의견
Apigee-hybrid-install-preview@google.com으로 이 프로세스에 대한 의견을 보내주세요.
개요
새로운 Apigee Hybrid 설치 환경에서는 kubectl을 사용하여 Apigee 구성요소를 설치하고 Apigee Hybrid 설치 및 관리를 Kustomize와 같은 Kubernetes 구성 조정 도구와 통합합니다. 설치되는 구성요소의 향상된 유효성 검사와 가시성을 통해 더 나은 디버깅 가능성을 제공하고 전반적인 설치 프로세스를 개선합니다.
설치 스크립트인 apigee-hybrid-setup.sh는 간편한 기본 설치 도구를 제공합니다. 이를 통해 Hybrid 설치를 만든 후 kubectl을 사용하여 필요에 맞게 수정하거나 kubectl을 사용하여 Hybrid 설치를 처음부터 만들 수 있습니다.
모든 Apigee Hybrid 구성 속성은 각 주요 구성요소마다 하나씩 yaml 파일에 저장됩니다. 이를 통해 Kubernetes 환경에서 하이브리드 설치를 보다 세밀하게 제어할 수 있습니다. GitHub의 저장소에서 구성 파일 및 설치 스크립트를 찾을 수 있습니다.
새 설치 프로세스의 변경사항
Apigee는 다음과 같은 이유로 Apigee Hybrid 설치 프로세스를 변경하고 있습니다.
- 새로운 Apigee Hybrid 설치 방법은
overrides.yaml구성 파일을 사용하지 않는 Argo, Flux 또는 Anthos Config Management와 같은 기존 Kubernetes CI/CD 도구와 통합할 수 있습니다. - Apigee Hybrid는 Kubernetes 클러스터에서 Apigee Hybrid 설치 및 관리를 위해 Kubernetes 매니페스트를 생성하는 커스텀 템플릿 도구인
apigeectl을 제공합니다. 새로운 설치 및 관리 프로세스는 다른 소프트웨어 공급업체의 환경과 비슷한 환경을 제공합니다. - 새 프로세스에서는 필수 권한, TLS 인증서, 자동 입력된 기본값, 기타 필요한 기본 요소를 사용하여 서비스 계정을 자동으로 만들어 기본 설치를 빠르게 수행할 수 있습니다.
기본 요건
이 미리보기 설치를 사용하기 전에 다음 기본 요건을 충족해야 합니다.
미리보기 버전
이 미리보기는 Apigee Hybrid 버전 1.8.x에서 작동합니다. 이후 버전의 Apigee Hybrid는 지원되지 않습니다.
Apigee Hybrid 설정
Apigee Hybrid를 실제로 설치하기 전에 문서의 다음 섹션에 나열된 다음 안내를 완료해야 합니다.
- 프로젝트 및 조직 설정
- Apigee Hybrid 설치 기본 요건에 대한 개요
- 1단계: API 사용 설정
- 2단계: 조직 만들기
- 3단계: 환경 및 환경 그룹 만들기
- 하이브리드 런타임 설정
도구
또한 워크스테이션에 다음 도구를 다운로드하고 구성해야 합니다.
curlapigee-hybrid-setup.sh스크립트를 실행하려면docker가 필요합니다. Docker 가져오기의 안내에 따라 Docker를 설치합니다.envsubst는 대부분의 Linux/UNIX 기반 시스템에서 사용할 수 있습니다. MacOS 및 기타 시스템의 경우 이 저장소의 안내를 따릅니다.jq를 설치해야 합니다. jq를 다운로드합니다.kptkpt를 다운로드합니다.kubectl버전 1.23 이상입니다. Kubernetes 문서의 도구 설치: kubectl을 참조하세요.
이 가이드에서 사용된 공통 변수
이 가이드는 여러 단계에서 다음과 같은 환경 변수를 사용합니다. 명령줄 또는 스크립트로 환경 변수를 정의하거나 입력할 때 명령어의 텍스트를 바꿀 수 있습니다.
APIGEE_NAMESPACE: Apigee 네임스페이스입니다. 기본적으로apigee입니다. 하지만 다른 네임스페이스를 사용할 수 있습니다.CLUSTER_NAME: Apigee Hybrid를 설치 중인 클러스터의 이름입니다. 이 클러스터는 1단계: 클러스터 만들기에서 만드는 클러스터입니다.CLUSTER_LOCATION: 클러스터의 리전입니다. 이 가이드의 절차에서는 리전 클러스터를 사용한다고 가정합니다. 영역 클러스터를 사용하는 경우 1단계: 클러스터 만들기의 안내를 참조하세요.ENV_GROUP: Apigee Hybrid 설치를 위한 환경 그룹의 이름입니다. 3단계: 환경 그룹 만들기에서 만드는 환경 그룹입니다. 여러 환경 그룹을 만들 수 있습니다.ENV_NAME: Apigee Hybrid 설치를 위한 환경 그룹의 이름입니다. 3단계: 환경 그룹 만들기에서 만드는 환경 그룹입니다. 여러 환경 그룹을 만들 수 있습니다.INSTALL_DIR: Apigee Hybrid를 설치하는 디렉터리입니다. 기본적으로 설치 프로그램을 다운로드할 디렉터리의apigee-hybrid-install/하위 디렉터리입니다(예:/myhybrid/apigee-hybrid-install/). Apigee Hybrid 설정 폴더 구조에 설명된 파일 구조의 루트 디렉터리입니다.INSTANCE_DIR: 특정 Apigee Hybrid 인스턴스의 디렉터리입니다. 기본적으로 첫 번째 인스턴스의 이름은instance-1입니다. 인스턴스 디렉터리는${INSTALL_DIR}/overlays/instances/의 하위 디렉터리입니다. 하이브리드 인스턴스에 원하는 이름을 지정할 수 있습니다. 멀티 인스턴스 설치를 참조하세요.ORG_NAME: Apigee Hybrid 조직의 이름입니다. Google Cloud 프로젝트 ID와 동일해야 합니다. 2단계: 조직 만들기를 참조하세요.
기본 Apigee Hybrid 설치
많은 맞춤설정 없이 Apigee Hybrid를 빠르게 설치하려면 다음 2단계 절차를 사용하면 됩니다.
- 단일 환경
- 단일 환경 그룹
- 단일 Google Cloud 서비스 계정이 생성되고 모든 개별 구성요소에 사용됩니다.
- 모든 암호화 키 및 비밀번호의 기본값입니다.
설정 파일 다운로드
https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1에서 GitHub 저장소를 클론하여 설정 파일을 다운로드하고 준비합니다.
저장소를 복제합니다.
git clone https://github.com/apigee/apigee-hybrid-install.git클론된 저장소의 디렉터리로 이동합니다.
cd apigee-hybrid-installpreview-1 태그에서 브랜치를 만듭니다.
git branch preview-1 preview-1 git checkout preview-1설정 스크립트를 실행 가능하게 만듭니다.
chmod +x ./tools/apigee-hybrid-setup.sh클론된 저장소의 구조는 Apigee Hybrid 설정 폴더 구조에 설명된 것과 유사합니다.
설정 실행
tools/ 폴더 내에 있는 apigee-hybrid-setup.sh 셸 스크립트를 실행합니다.
./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION --org $ORG_NAME --setup-all
오류가 발생하면 스크립트를 다시 실행해 보세요.
사용할 수 있는 추가 옵션은 다음과 같습니다.
--env $ENV_NAME은 Apigee 환경의 이름을 지정합니다.--envgroup $ENV_GROUP은 환경 그룹을 지정합니다.--ingress-domain $HOSTNAME은 환경 그룹에 제공한 호스트 이름을 지정합니다.--gcp-project-id $PROJECT_ID는 Google Cloud 프로젝트의 ID를 지정합니다.
더 많은 옵션은 스크립트 이해를 참조하세요.
실행 중에 발생하는 오류는 표준 출력에 표시됩니다.
스크립트가 성공적으로 완료되면 기본 Hybrid 설치가 완료됩니다. 새 API 프록시 만들기 및 배포에 설명된 대로 샘플 프록시를 만들어 설치를 테스트할 수 있습니다.
맞춤설정된 Apigee Hybrid 설치
설치 과정을 더욱 세부적으로 제어하려는 고급 사용자의 경우 다음 단계 시퀀스를 수행할 수 있습니다. 아래에 나오는 여러 단계에서 수동으로 단계를 수행하거나 셸 스크립트를 사용하여 개별 단계를 자동화할 수 있습니다.
설정 파일 다운로드
설정 파일을 다운로드하고 준비합니다.
https://github.com/apigee/apigee-hybrid-install/에서 GitHub 저장소를 클론합니다.클론된 저장소의 구조는 Apigee Hybrid 설정 폴더 구조에 설명된 것과 유사합니다.
cd명령어를 사용하여apigee-hybrid-install/디렉터리로 이동합니다.설정 스크립트를 실행 가능하게 만듭니다.
chmod +x ./tools/apigee-hybrid-setup.sh
네임스페이스 만들기
모든 Apigee 클러스터 구성요소를 포함하는 클러스터에 Kubernetes 네임스페이스를 만듭니다.
kubectl create namespace apigee
네임스페이스에 대해 다른 이름을 선택할 경우 아래 세 가지 옵션 중 하나를 따르도록 선택할 수 있습니다.
- (권장) 리소스 yaml 수정에서 값을 사전 작성하는 동안
--namespace={YOUR_NAMESPACE_NAME}을 사용합니다. 다음 두 명령어를 실행합니다.
kpt를 사용하여 Apigee 네임스페이스를 지정합니다.kpt fn eval "${INSTALL_DIR}/overlays/" \ --image gcr.io/kpt-fn/apply-setters:v0.2.0 -- \ APIGEE_NAMESPACE="${APIGEE_NAMESPACE}" # This is for replacing the namespace in istio discoveryAddress which cannot be # achieved with kptsed를 사용하여 istio discoveryAddress의 네임스페이스를 바꿉니다.sed -i -E -e "s/(discoveryAddress: apigee-ingressgateway-manager\.).*(\.svc:15012)/\1${APIGEE_NAMESPACE}\2/" "${INSTALL_DIR}/overlays/controllers/istiod/apigee-istio-mesh-config.yaml"
또는 선택한 네임스페이스에 개별적으로 생성되도록 리소스를 수동으로 변경할 수 있습니다.
비공개 저장소의 Docker 이미지 사용(선택사항)
공개적으로 호스팅되는 이미지를 사용하지 않도록 선택하고 자체 비공개 저장소의 이미지를 사용할 수 있습니다.
- 첫 번째 단계는 apigee-pull-push | Apigee X의 단계를 따라 모든 이미지를 비공개 저장소로 푸시하는 것입니다. 기본적으로 이미지는 해당하는 Apigee Hybrid 버전으로 태그되므로 이러한 태그는 수정하지 않는 것이 좋습니다. 또한 이미지 허브에 설명된 대로 최종 이미지 경로를 생성할 수 있도록 이미지 이름을 수정하지 않는 것이 좋습니다.
apigee-hybrid-config.yaml 파일 내부에 있는
imageHub필드의 값을 비공개 저장소 호스트 경로로 설정합니다. 자세한 내용은 이미지 허브를 참조하세요.imageHub: "your.private.repo/apigee/hybrid"
이렇게 하면 모든 Apigee Hybrid 구성요소에 비공개 저장소의 이미지가 사용됩니다.
이 외에도 컨트롤러 및 Apigee 인그레스 게이트웨이에 비공개 이미지를 사용할 수도 있습니다. 이 경우 apigee-controller-deployment.yaml 및 apigee-ingressgateway-manager-deployment.yaml 파일을 모두 바꾸고 image 필드를 비공개 저장소의 이미지로 바꿉니다.
imagePullSecret 구성(선택사항)
- 비공개 저장소에 인증하기 위해 사용자 인증 정보가 포함된 kubernetes 보안 비밀을 만듭니다. 보안 비밀을 만드는 방법을 보려면 비공개 레지스트리에서 이미지 가져오기를 참조하세요.
- 보안 비밀을 만든 후에는 apigee-hybrid-config.yaml 파일을 수정하고
imagePullSecret필드의 값을 이전에 만든 보안 비밀의 이름으로 설정하여 이 보안 비밀을 참조하고 해당kustomization.yaml파일에서imagePullSecret구성요소를 사용 설정하기만 하면 됩니다.
두 위치에서 모두 imagePullSecrets를 지정하면 apigee-controller-manager.yaml 파일 내에 있는 항목이 우선 적용됩니다.
전달 프록시 구성(선택사항)
apigee-hybrid-config.yaml 파일에 forwardProxy 필드를 추가하여 전달 프록시를 구성할 수 있습니다. 예를 들면 다음과 같습니다.
forwardProxy: |
scheme: HTTP
host: 10.12.0.47
port: 3128
인그레스 TLS 인증서 지정
스크립트 사용
./tools/apigee-hybrid-setup.sh --create-ingress-tls-certs
이 플래그에 대한 자세한 내용은 스크립트 이해를 참조하세요.
수동
사용자가 istio 인그레스 게이트웨이에 사용되는 TLS 인증서를 제공해야 합니다. 다음과 같은 작업을 할 수 있습니다.
- TLS 인증서 가져오기: 예시 | Apigee X에 설명된 단계에 따라 알려진 인증 기관에서 서명한 인증서를 사용하거나
- 자체 서명 인증서를 생성할 수 있습니다.
여기에서는 예시로 자체 서명된 인증서를 사용합니다. 자체 서명된 인증서는 다음(DOMAIN이 올바르게 설정되었으며 envgroup에 설정된 호스트 이름과 일치한다고 가정)을 사용하여 생성될 수 있습니다.
openssl req -nodes -new -x509 -keyout ./tls.key -out ./tls.crt -subj '/CN='$DOMAIN'' -days 3650
그러면 tls.key 및 tls.crt라는 2개 파일이 생성됩니다.
그런 다음 아래 형식의 보안 비밀을 만들어야 합니다. 인증서 서명 기관에 커스텀 인증서/키 쌍 사용에서 설명한 대로 kubectl create 또는 kubectl apply를 사용하여 수행하면 됩니다(선택사항).
apiVersion: v1
kind: Secret
metadata:
name: "{ORG_NAME}-{ENV_GROUP_NAME}"
namespace: {$APIGEE_NAMESPACE}
type: Opaque
data:
cert: |
{BASE64_ENCODED_TLS_CRT}
key: |
{BASE64_ENCODED_TLS_KEY}
---
kubectl create를 사용하여 보안 비밀을 만드는 예시는 다음과 같습니다.
kubectl create secret tls {ORG_NAME}-{ENV_GROUP_NAME} \
--cert="tls.crt" \
--key="tls.key" \
-n {$APIGEE_NAMESPACE}
인그레스 배포 업데이트
인그레스 배포를 만들거나 수정하려면 bases/initialization/crds/customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml에서 ApigeeOrganization 커스텀 리소스의 spec.components.ingressGateways 필드를 수정해야 합니다.
기본적으로 기본 매개변수가 있는 인그레스 배포 1개를 만듭니다(기본값은 CR 참조 문서 에 표시됨).
ingressGateways:
- name: "prod-1"
예를 들면 다음과 같습니다.
A. 인그레스 서비스 필드 재정의
ingressGateways:
- name: "prod-1"
serviceSpec:
annotations:
{KEY}: ${VALUE}
loadBalancerIP: ${IP}
B. 복제본 최솟값/최댓값 변경
ingressGateways:
- name: "prod-1"
autoScaler:
minReplicas: 4
maxReplicas: 10
C. 새 인그레스 배포 추가
ingressGateways:
- name: "prod-1"
- name: "prod-2"
커스텀 Google Cloud 서비스 계정 구성
스크립트 사용
./tools/apigee-hybrid-setup.sh --create-gcp-sa-and-secrets --namespace APIGEE_NAMESPACE
여기서 APIGEE_NAMESPACE는 커스텀 네임스페이스입니다. 기본 네임스페이스는 apigee입니다.
플래그에 대한 자세한 내용은 스크립트 이해를 참조하세요.
수동
Google Cloud 서비스 계정 키는 클러스터에 보안 비밀로 저장해야 합니다. 보안 비밀 yaml 구조는 다음과 같습니다.
apiVersion: v1
kind: Secret
metadata:
name: "{NAME}"
namespace: {APIGEE_NAMESPACE}
type: Opaque
data:
client_secret.json: |
{BASE64_ENCODED_SA_KEY}
필요한 모든 서비스 계정과 보안 비밀의 이름에 대한 자세한 내용은 Google Cloud 서비스 계정 섹션을 참조하세요.
보안 비밀에 다른 이름을 자유롭게 선택할 수 있지만 그러면 해당 보안 비밀 이름이 사용된 구성요소에서 적절하게 변경해야 합니다. 예를 들어 런타임 서비스 계정 보안 비밀의 이름을 apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME}에서 my-runtime-svc로 변경하려면 해당 환경의 apigee-environment.yaml에 해당 변경사항을 적용해야 합니다.
워크로드 아이덴티티 사용
커스텀 Google Cloud 서비스 계정 구성 또는 워크로드 아이덴티티 사용 중 하나는 필수입니다.
기본 요건
워크로드 아이덴티티를 사용하기 전에 GKE 클러스터에 지원이 사용 설정되어 있는지 확인합니다. 자세한 내용은 노드 풀 업데이트 | Apigee X를 참조하세요.
워크로드 아이덴티티 사용 설정
설치 전 워크로드 아이덴티티를 사용 설정하는 방법은 Kustomize 및 구성요소 아래에서 워크로드 아이덴티티 섹션을 참조하세요.
리소스 yaml 수정
구성요소 yaml의 일부 장소에는 올바른 조직, 환경, 환경 그룹 이름이 있어야 합니다. 이러한 값을 수동으로 설정하거나 셀 스크립트를 사용해서 값을 자동으로 입력할 수 있습니다.
스크립트 사용
./tools/apigee-hybrid-setup.sh --fill-values
초기화 리소스 및 컨트롤러 만들기
#Additional steps for openshift
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/openshift
//apigee datastore
kubectl apply -f ${INSTANCE_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/components/openshift-scc/scc.yaml
//telemetry
kubectl apply -f ${INSTANCE_DIR}/overlays/instances/${INSTANCE_DIR}/telemetry/components/openshift-scc/scc.yaml
#Create Apigee initialization kubernetes resources
kubectl apply -f ${INSTALL_DIR}/overlays/initialization/namespace.yaml
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/certificates
kubectl apply --server-side --force-conflicts -k ${INSTALL_DIR}/overlays/initialization/crds
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/webhooks
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/rbac
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/ingress
# Create controller config and controller
kubectl apply -k ${INSTALL_DIR}/overlays/controllers
# Wait for the controllers to be available
kubectl wait deployment/apigee-controller-manager deployment/apigee-ingressgateway-manager -n "${APIGEE_NAMESPACE}" --for=condition=available --timeout=2m
# Create the datastore and redis secrets first and then the rest of the secrets.
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/redis/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/${ENV_NAME}/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/organization/secrets.yaml
동기화 담당자 서비스 계정에 제어 영역과 상호작용하는 권한 부여
8단계: 동기화 담당자 액세스 사용 설정의 단계를 따라 서비스 계정의 이름(apigee-non-prod 또는 apigee-synchronizer)을 새 설치 프로세스로 생성된 서비스 계정의 이름인 apigee-all-sa로 바꿉니다.
★ 중요: 동기화 담당자 액세스 사용 설정 아래의 안내에 따라 서비스 계정 이름을 변경해야 합니다. 그렇지 않으면 동기화 담당자에 대한 액세스가 사용 설정되지 않습니다.
Apigee 데이터 영역 구성요소 만들기
이전 단계에서 리소스 이름을 변경한 경우 이 리소스가 참조된 다른 YAML 파일에도 그에 해당하는 변경사항을 적용해야 합니다. 변경한 후 다음 예시의 명령어를 사용합니다.
# Create the rest of the resources.
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
클릭하여 모든 구성요소를 설치합니다.
리소스가 시작될 때까지 대기
kubectl wait "apigeedatastore/default" \
"apigeeredis/default" \
"apigeeenvironment/${ORG_NAME}-${ENV_NAME}" \
"apigeeorganization/${ORG_NAME}" \
"apigeetelemetry/apigee-telemetry" \
-n "${APIGEE_NAMESPACE}" --for="jsonpath=.status.state=running" --timeout=15m
커스텀 네임스페이스의 cert-manager 설치 맞춤설정
다음 절차에 따라 cert-manager가 실행 중인 네임스페이스를 맞춤설정합니다.
cert-manager가 클러스터에서 cert-manager 외의 네임스페이스에 설치된 경우 Apigee 루트 인증서를 만드는 데 사용한 네임스페이스를 업데이트해야 합니다.
- 인증서 생성을 위한 customization.yaml 파일을 수정합니다.
$INSTALL_DIR/overlays/initialization/certificates/kustomize.yaml 파일 끝에 다음을 추가합니다.
- patch: |- - op: replace path: /metadata/namespace value: "gk-cert-manager" target: group: cert-manager.io version: v1 kind: Certificate name: apigee-root-certificate파일을 저장합니다.
Kustomize 및 구성요소
개요
새 Hybrid 설치는 기본 및 오버레이 형식으로 yaml을 구조화하는 Kustomize 이론을 상속합니다.
- 기본 파일은 Apigee에서 제공하는 파일로, 각각의 새로운 Hybrid 버전 사이에 변경될 수 있습니다. 이러한 파일은 수정하지 않아야 합니다. 이러한 파일에는 Apigee에서 제공되는 일부 기본값이 포함됩니다. 최상위
bases/폴더 아래의 모든 파일에는 이 기본 파일이 포함됩니다. 오버레이는 사용자 구성을 포함하며 기본 파일에 지정된 기본값을 수정할 수 있는 수단으로 사용됩니다. 최상위
overlays/폴더 아래의 모든 파일에는 이 오버레이 파일이 포함됩니다.
구성요소 사용 방법
최상위 overlays/ 디렉터리 내에 있는 하위 폴더는 kustomization.yaml 파일에서 특정 줄을 주석 처리(또는 주석 처리 삭제)하여 특정 추가 기능을 사용 설정(또는 사용 중지)할 수 있는 방식으로 구성되어 있습니다.
예를 들어 overlays/instances/{INSTANCE_NAME}/telemetry 폴더 구조는 다음과 같이 표시됩니다.
telemetry
├── components
│ ├── http-proxy
│ ├── imagepullsecret
│ ├── logger
│ ├── metrics
│ ├── nodeselector
│ ├── openshift-scc
│ ├── workload-identity-logger
│ └── workload-identity-metrics
├── apigee-telemetry.yaml
└── kustomization.yaml
telemetry/kustomization.yaml 파일의 기본값은 다음과 같습니다.
resources:
- apigee-telemetry.yaml
components:
- ./components/metrics
# - ./components/workload-identity-metrics
# - ./components/logger
# - ./components/workload-identity-logger
# - ./components/http-proxy
# - ./components/nodeselector/
# - ./components/imagepullsecret
# - ./components/openshift-scc
./components/logger가 주석 처리되었으므로 Google Cloud logger가 기본적으로 사용 설정되지 않은 것입니다. 이를 사용 설정하려면 다음과 같이 해당 줄의 주석 처리를 삭제하면 됩니다.
components:
- ./components/logger
마찬가지로 측정항목을 중지하려면 ./components/metrics 줄을 주석 처리합니다.
...
components:
...
# - ./components/metrics
…
다음 섹션에서는 다양한 구성요소, 구성요소를 사용할 수 있는 시기, 구성요소를 구성하는 방법을 설명합니다.
OpenShift
OpenShift 클러스터에 Apigee Hybrid를 설치하려는 사용자의 경우 설치를 수행하기 전에 일부 구성요소/리소스를 사용 설정해야 할 수 있습니다. 이 절차는 스크립트를 사용해서 설치를 수행하지 않는 경우에 필요합니다. 수정해야 하는 파일은 다음과 같습니다.
overlays/initialization/openshift/kustomization.yamlresources:섹션에서 다음과 같이 주석 처리를 삭제합니다.# - ../../../bases/initialization/openshift/overlays/instances/{INSTANCE_NAME}/datastore/kustomization.yaml주석 처리 삭제:# - ./components/openshift-scc그리고 "
components:" 필드도 아직 주석 처리되어 있으면 주석 처리를 삭제합니다.overlays/instances/{INSTANCE_NAME}/telemetry/kustomization.yaml주석 처리 삭제:# - ./components/openshift-scc그리고 "
components:" 필드도 아직 주석 처리되어 있으면 주석 처리를 삭제합니다.
그런 후 설치 단계를 진행하면 됩니다.
imagepullsecret
비공개 저장소에 이미지가 저장되어 있으면 이 구성요소를 사용 설정할 수 있습니다. 비공개 저장소에서 이미지를 가져오려면 인증 세부정보가 포함되는 kubernetes 보안 비밀을 만들 고 내부에서 이 보안 비밀을 참조하면 됩니다. 자세한 내용은 imagePullSecret 구성(선택사항)을 참조하세요. 자세한 내용은 Kubernetes 문서의 비공개 레지스트리에서 이미지 가져오기 | Kubernetes를 참조하세요.
제공 언어:
overlays/controllers/apigee-controlleroverlays/controllers/istiodoverlays/instances/{INSTANCE_NAME}/datastoreoverlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}overlays/instances/{INSTANCE_NAME}/organizationoverlays/instances/{INSTANCE_NAME}/redisoverlays/instances/{INSTANCE_NAME}/telemetry
사용 설정:
필요한 경우 각 kustomization.yaml 파일에서 './components/imagepullsecret/' 줄의 주석 처리를 삭제합니다.
수행할 수정사항:
- components/imagepullsecret/patch.yaml
- 필수
spec.template.spec.imagePullSecrets의 목록에 관련 보안 비밀 이름을 추가합니다.
- 필수
사용법:
- Apigee Hybrid를 아직 설치하지 않은 경우 설치 단계를 계속 진행하면 과정 중에 변경사항이 적용됩니다.
Apigee Hybrid를 이미 설치했으면 다음을 사용해서 새로운 변경사항을 적용해야 합니다.
kubectl apply -k overlays/instances/{INSTANCE_NAME}
nodeselector
이 구성요소를 사용하면 특정 노드에서 Apigee 리소스의 포드를 예약할 수 있습니다. 자세한 내용은 노드에 포드 할당 | Kubernetes를 참조하세요.
제공 언어:
overlays/controllers/apigee-controlleroverlays/controllers/istiodoverlays/instances/{INSTANCE_NAME}/datastoreoverlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}overlays/instances/{INSTANCE_NAME}/organizationoverlays/instances/{INSTANCE_NAME}/redisoverlays/instances/{INSTANCE_NAME}/telemetry
사용 설정:
필요한 경우 각 kustomization.yaml 파일에서 './components/nodeselector' 줄의 주석 처리를 삭제합니다.
수행할 수정사항:
- components/nodeselector/patch.yaml
- 선택사항
apigee-runtime또는apigee-data에서 원하는 항목으로 노드 선택기 라벨의 값을 변경합니다.
- 선택사항
사용법:
- Apigee Hybrid를 아직 설치하지 않은 경우 설치 단계를 계속 진행하면 과정 중에 변경사항이 적용됩니다.
Apigee Hybrid를 이미 설치했으면 다음을 사용해서 새로운 변경사항을 적용해야 합니다.
kubectl apply -k overlays/instances/{INSTANCE_NAME}
workload-identity
Apigee Hybrid 에코시스템의 여러 컨테이너는 Apigee 제어 영역/관리 영역에 대해 특정 API 호출을 수행할 수 있는 권한이 필요합니다. 워크로드 아이덴티티는 포드(및 내부 컨테이너)에 이러한 권한을 부여하는 것입니다. 이와 관련해서 읽어볼 수 있는 유용한 리소스에는 워크로드 아이덴티티 소개: GKE 애플리케이션의 인증 향상 | Google Cloud 블로그, 워크로드 아이덴티티 사용 | Kubernetes Engine 문서 | Google Cloud가 포함됩니다.
제공 언어:
overlays/instances/{INSTANCE_NAME}/datastoreoverlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}overlays/instances/{INSTANCE_NAME}/organizationoverlays/instances/{INSTANCE_NAME}/redisoverlays/instances/{INSTANCE_NAME}/telemetry
선행 조건:
워크로드 아이덴티티를 사용하려면 먼저 다음을 사용해 Google Cloud 프로젝트 내에서 관련 권한을 부여해야 합니다.
gcloud iam service-accounts add-iam-policy-binding \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:${ORG_NAME}.svc.id.goog[${APIGEE_NAMESPACE}/${KSA_NAME}]" \
${GSA_NAME}@${ORG_NAME}.iam.gserviceaccount.com
각 항목의 의미는 다음과 같습니다.
- ${ORG_NAME} - Apigee 조직의 이름입니다.
- ${APIGEE_NAMESPACE} - Apigee 구성요소가 설치된 kubernetes 네임스페이스입니다. 설치 중 사용자가 명시적으로 변경하지 않는 한 일반적으로 apigee입니다. - ${KSA_NAME} - Kubernetes 네임스페이스의 이름입니다. Kubernetes 서비스 계정에 언급된 각 Kubernetes 서비스 계정마다 이 명령어를 실행해야 합니다.
- ${GSA_NAME} - Google Cloud 서비스 계정 이름입니다. 설치 중에 아무것도 변경하지 않으면 apigee-all-sa 값이 됩니다. 개별 구성요소에 대해 여러 Google Cloud 서비스 계정을 설정하는 경우 KSA_NAME을 해당 GSA_NAME과 일치시켜야 합니다. Google Cloud 서비스 계정의 표를 Kubernetes 서비스 계정과 비교하여 그에 해당하는 계정을 찾을 수 있습니다.
사용 설정:
필요한 경우 각 kustomization.yaml 파일에서 ./components/workload-identity 줄의 주석 처리를 삭제합니다. 원격 분석 내에서 개별적으로 사용 설정할 수 있는 metrics 및 logger 구성요소에 대한 별도의 워크로드 아이덴티티 부가기능이 있습니다.
사용법:
- 아직 하이브리드를 설치하지 않았으면 이전 섹션에 설명된 대로 워크로드 아이덴티티를 사용 설정하고 워크로드 아이덴티티가 자동으로 사용되는 설치를 계속하면 됩니다.
Apigee Hybrid를 이미 설치했으면 다음을 사용해서 새로운 변경사항을 적용해야 합니다.
kubectl apply -k overlays/instances/{INSTANCE_NAME}
http-proxy
다음 각 구성 요소에 프록시 서버를 구성하여 해당 구성 요소에 대한 트래픽이 해당 구성 요소에 대해 구성된 HTTP 프록시를 거치도록 할 수 있습니다. 각 Apigee 구성요소에 대해 프록시를 개별적으로 구성할 수 있습니다.
제공 언어:
overlays/instances/{INSTANCE_NAME}/datastoreoverlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}overlays/instances/{INSTANCE_NAME}/organizationoverlays/instances/{INSTANCE_NAME}/telemetry
사용 설정:
필요한 경우 각 kustomization.yaml 파일에서 './components/http-proxy/' 줄의 주석 처리를 삭제합니다.
수행할 수정사항:
- components/http-proxy/patch.yaml
다음 매개변수는
spec.httpForwardProxy에서 구성할 수 있습니다.scheme: 필수HTTP또는HTTPS중 하나입니다.host: 필수 프록시의 호스트 주소입니다.port: 필수 포트 번호입니다.username: 선택사항 프록시와 연결된 사용자 이름입니다.password: 선택사항 프록시에 액세스하기 위한 비밀번호입니다.
사용법:
- Apigee Hybrid를 아직 설치하지 않은 경우 설치 단계를 계속 진행하면 과정 중에 변경사항이 적용됩니다.
Apigee Hybrid를 이미 설치했으면 다음을 사용해서 새로운 변경사항을 적용해야 합니다.
kubectl apply -k overlays/instances/{INSTANCE_NAME}
Logger 및 측정항목
오버레이/인스턴스/{INSTANCE_NAME}/원격 분석 내에서 logger 또는 측정항목을 개별적으로 사용 설정하거나 사용 중지할 수 있습니다. Logger는 기본적으로 사용 중지되며 측정항목은 사용 설정됩니다. 사용 설정 또는 사용 중지는 telemetry/kustomization.yaml에서 해당 줄의 주석 처리를 삭제하거나 주석 처리하면 됩니다.
gcs-backup 및 gcs-restore
이 kustomize 구성요소는 Google Cloud Storage에 대해 cassandra 데이터베이스를 백업 및 복원하는 데 사용할 수 있습니다.
제공 언어:
overlays/instances/{INSTANCE_NAME}/datastore
선행 조건:
스토리지 객체 관리자 역할이 있는 계정의 Google Cloud 서비스 계정 키를 다운로드합니다.
- 스크립트를 사용하여 설치를 수행하고 워크로드 아이덴티티를 사용하지 않은 경우 스크립트로 생성된 서비스 계정 폴더에서 사용 가능한 다운로드한 키를 재사용할 수 있습니다.
create-service-account.sh 스크립트를 사용하여 새 서비스 계정을 만들고 키를 다운로드할 수도 있습니다.
./tools/create-service-accounts=.sh --env prod --profile apigee‑cassandra
키를 다운로드한 후 다음 명령어를 사용하여 apigee-cassandra-backup-and-restore-gcp-sa-key라는 Kubernetes 보안 비밀을 만들어야 합니다.
kubectl create secret generic "apigee-cassandra-backup-and-restore-gcp-sa-key" \ --from-file="dbbackup_key.json=${PATH_TO_SA_KEY}" \ -n "${APIGEE_NAMESPACE}"각 항목의 의미는 다음과 같습니다.
- ${PATH_TO_SA_KEY} - 서비스 계정 키가 포함된 파일의 경로입니다.
- ${APIGEE_NAMESPACE} - Apigee 구성요소가 설치된 Kubernetes 네임스페이스입니다. 일반적으로 설치 중에 명시적으로 변경되지 않는 한 apigee가 사용됩니다.
또는 템플릿 파일 templates/secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml을 사용하여 이 보안 비밀을 만들 수 있습니다.
사용 설정:
- 백업을 사용 설정하려면 datastore kustomization.yaml 파일의 './components/gcs-backup' 줄에 대한 주석 처리를 삭제합니다.
- 백업을 복원하려면 datastore kustomization.yaml 파일의 './components/gcs-restore' 줄의 주석 처리를 삭제합니다.
백업 전용 수정사항
- components/gcs-backup/apigee-datastore-patch.yaml
- 필수 DATABASE_STORAGE_BUCKET 환경 변수의 값을 변경합니다. 이 값은 gs://BUCKET_NAME 형식이며 데이터를 백업해야 할 Google Cloud Storage 버킷을 가리킵니다. 설명은 여기에 설명된 dbStorageBucket과 일치합니다.
- components/gcs-backup/cron-patch.yaml
- 필수 spec.schedule을 변경하여 백업 빈도를 지정합니다. 필드에는 표준 Crontab 예약 형식이 사용됩니다. 설명은 여기에 설명된 일정과 일치합니다.
- 필수 DATABASE_STORAGE_BUCKET 환경 변수의 값을 변경합니다. 이 값은 gs://BUCKET_NAME 형식이며 데이터를 백업해야 할 Google Cloud Storage 버킷을 가리킵니다. 설명은 여기에 설명된 dbStorageBucket과 일치합니다.
- 선택사항 구성된 프록시를 가리키도록 HTTP_PROXY_URL 값을 변경합니다. 다음 형식을 사용할 수 있습니다.
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS>:${HOST_PORT}
백업 수행
다음 명령어로 백업을 수행할 수 있습니다.
kubectl apply -k overlays/instances/{INSTANCE_NAME}
변경사항을 적용하고 백업을 사용 설정하려면 다음 안내를 따르세요.
복원 전용 수정사항
- components/gcs-restore/apigee-datastore-patch.yaml
- 필수 DATABASE_STORAGE_BUCKET 환경 변수의 값을 변경합니다. 이 값은 gs://BUCKET_NAME 형식이며 데이터를 백업해야 할 Google Cloud Storage 버킷을 가리킵니다. 설명은 여기에 설명된 dbStorageBucket과 일치합니다.
- components/gcs-restore/job-patch.yaml
- 필수 DATABASE_STORAGE_BUCKET 환경 변수의 값을 변경합니다. 이 값은 gs://BUCKET_NAME 형식이며 데이터를 백업해야 할 Google Cloud Storage 버킷을 가리킵니다.
- 필수 BACKUP_SNAPSHOT_TIMESTAMP 환경 변수의 값을 변경합니다. 설명은 여기에 설명된 restore:snapshotTimestamp와 일치합니다.
- 선택사항 구성된 프록시를 가리키도록 HTTP_PROXY_URL 값을 변경합니다.
다음 형식을 사용할 수 있습니다.
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS}:${HOST_PORT}
복원 수행:
백업 복원에 대한 배경 정보는 백업 복원 | Apigee X | Google Cloud를 참조하세요.
- 하이브리드 런타임 배포를 복원할 새 Kubernetes 클러스터를 새 네임스페이스를 사용하여 만듭니다. 원래 하이브리드 설치에 사용했던 것과 동일한 클러스터 및 네임스페이스는 사용할 수 없습니다.
위에서 구성한 설정과 원하는 다른 설정을 사용해서 새 클러스터에 하이브리드를 설치합니다.
- 기본 설치 및 새 네임스페이스에 하이브리드 설치를 사용할 수 있습니다.
./tools/apigee-hybrid-setup.sh \ --cluster-name $CLUSTER_NAME \ --cluster-region $CLUSTER_LOCATION \ --namespace ${NEW_APIGEE_NAMESPACE}- 또는 맞춤설정된 Apigee Hybrid 설치를 사용해서 원하는 대로 항목을 구성할 수 있습니다.
복원이 완료되면 이전 네임스페이스의 모든 리소스를 삭제하고 새 네임스페이스로 전환할 수 있습니다.
자세한 내용은 백업 복원을 참조하세요.
non-gcs-backup 및 non-gcs-restore
이 kustomize 구성요소는 Google Cloud Storage에 대해 cassandra 데이터베이스를 백업 및 복원하는 데 사용할 수 있습니다.
제공 언어:
overlays/instances/{INSTANCE_NAME}/datastore
선행 조건:
- 서버 및 SSH 설정에 대해 기존 문서에 설명된 단계를 활용할 수 있습니다.
위 단계에서는 이전 단계를 수행하여 생성된 "ssh_key" 파일에서 사용할 수 있는 SSH 비공개 키를 사용해야 합니다. 그런 다음 이 SSH 비공개 키가 포함된 apigee-cassandra-backup-and-restore-gcp-sa-key라는 이름으로 Kubernetes 보안 비밀을 만듭니다.
Kubernetes 보안 비밀은 다음 명령어를 사용하여 만들 수 있습니다.
kubectl create secret generic "apigee-cassandra-backup-and-restore-key-file" \ --from-file="key=${PATH_TO_SSH_PRIVATE_KEY}" \ -n "${APIGEE_NAMESPACE}"각 항목의 의미는 다음과 같습니다.
- ${PATH_TO_SSH_PRIVATE_KEY} - SSH 비공개 키가 포함된 파일의 경로입니다.
- ${APIGEE_NAMESPACE} - Apigee 구성요소가 설치된 Kubernetes 네임스페이스입니다. 일반적으로 설치 중에 명시적으로 변경되지 않는 한 apigee가 사용됩니다.
또는 템플릿 파일 templates/secret-apigee-cassandra-backup-and-restore-key-file.yaml을 사용하여 이 보안 비밀을 만들 수 있습니다.
사용 설정:
- 백업을 사용 설정하려면 Datastore kustomization.yaml 파일의 "
./components/non-gcs-backup" 줄에서 주석 처리를 삭제합니다. - 백업을 복원하려면 Datastore kustomization.yaml 파일의 "
./components/non-gcs-restore" 줄에서 주석 처리를 삭제합니다.
백업 전용 수정사항
- components/non-gcs-backup/apigee-datastore-patch.yaml
- components/non-gcs-backup/cron-patch.yaml
- 필수 spec.schedule을 변경하여 백업 빈도를 지정합니다. 필드에는 표준 Crontab 예약 형식이 사용됩니다. 설명은 여기에 설명된 일정과 일치합니다.
- 필수 BACKUP_SERVER_IP 값을 변경합니다. 설명은 여기에 설명된 BACKUP_SERVER_IP와 일치합니다.
- 필수 BACKUP_STORAGE_DIR 값을 변경합니다. 설명은 여기에 설명된 BACKUP_STORAGE_DIR과 일치합니다.
- 선택사항 구성된 프록시를 가리키도록 HTTP_PROXY_URL 값을 변경합니다. 다음 형식을 사용할 수 있습니다.
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS}:${HOST_PORT}
백업 수행
다음 명령어로 백업을 수행할 수 있습니다.
kubectl apply -k overlays/instances/{INSTANCE_NAME}
변경사항을 적용하고 백업을 사용 설정하려면 다음 안내를 따르세요.
백업 전용 수정사항
- components/non-gcs-restore/apigee-datastore-patch.yaml
- components/non-gcs-restore/job-patch.yaml
- 필수
BACKUP_SNAPSHOT_TIMESTAMP환경 변수의 값을 변경합니다. 설명은 여기에 설명된restore:snapshotTimestamp와 일치합니다. - 필수
BACKUP_SERVER_IP의 값을 변경합니다. 설명은 여기에 설명된BACKUP_SERVER_IP와 일치합니다. - 필수
BACKUP_STORAGE_DIR의 값을 변경합니다. 설명은 여기에 설명된BACKUP_STORAGE_DIR와 일치합니다. - 선택사항 구성된 프록시를 가리키도록
HTTP_PROXY_URL값을 변경합니다. 다음 형식을 사용할 수 있습니다.http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS}:${HOST_PORT}http://${HOST_IP_ADDRESS}:${HOST_PORT}
- 필수
복원 수행:
백업 복원에 대한 개요는 Cassandra 복원 개요를 참조하세요.
- 하이브리드 런타임 배포를 복원할 새 Kubernetes 클러스터를 새 네임스페이스를 사용하여 만듭니다. 원래 하이브리드 설치에 사용했던 것과 동일한 클러스터 및 네임스페이스는 사용할 수 없습니다.
원하는 다른 설정 외에도 위에 구성된 설정을 사용해서 새 클러스터에 Hybrid를 설치합니다. 기본 설치 및 새 네임스페이스에 하이브리드 설치를 사용할 수 있습니다.
./tools/apigee-hybrid-setup.sh \ --cluster-name $CLUSTER_NAME \ --cluster-region $CLUSTER_LOCATION \ --namespace ${NEW_APIGEE_NAMESPACE}또는 맞춤설정된 Apigee Hybrid 설치를 사용해서 원하는 대로 항목을 구성할 수 있습니다.
복원이 완료되면 이전 네임스페이스의 모든 리소스를 삭제하고 새 네임스페이스로 전환할 수 있습니다.
자세한 내용은 원격 서버에서 백업 예약을 참조하세요.
http-client
자세한 내용은 HTTP 클라이언트 사용 설정 | Apigee을 참조하세요.
제공 언어:
- overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}
사용 설정:
각 route-config/${ENV_GROUP}/kustomization.yaml 파일에서 "./components/http-client" 줄의 주석 처리를 삭제합니다.
수행할 수정사항:
- 필수 수정사항은 필요하지 않습니다.
사용법:
- Apigee Hybrid를 아직 설치하지 않은 경우 설치 단계를 계속 진행하면 과정 중에 변경사항이 적용됩니다.
Apigee Hybrid를 이미 설치했으면 다음을 사용해서 새로운 변경사항을 적용해야 합니다.
kubectl apply -k overlays/instances/{INSTANCE_NAME}
non-sni-client
기존 SNI 이외의 클라이언트 구성 방법 | Apigee에 해당합니다.
제공 언어:
- overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}
사용 설정:
각 route-config/${ENV_GROUP}/kustomization.yaml 파일에서 "./components/non-sni-client" 줄의 주석 처리를 삭제합니다.
수행할 수정사항:
- components/non-sni-client/apigee-route.yaml
- 필수
credentialName설명은 여기에 설명된credential_name과 일치합니다.
- 필수
사용법:
- Apigee Hybrid를 아직 설치하지 않은 경우 설치 단계를 계속 진행하면 과정 중에 변경사항이 적용됩니다.
Apigee Hybrid를 이미 설치했으면 다음을 사용해서 새로운 변경사항을 적용해야 합니다.
kubectl apply -k overlays/instances/{INSTANCE_NAME}
http-and-non-sni-client
자세한 내용은 SNI 이외의 클라이언트 및 HTTP 클라이언트 모두에 대한 지원 사용 | Apigee를 참조하세요.
사용 설정:
각 route-config/${ENV_GROUP}/kustomization.yaml 파일에서 "./components/http-and-non-sni-client" 줄의 주석 처리를 삭제합니다.
수행할 수정사항:
- components/http-and-non-sni-client/apigee-route.yaml
- 필수
credentialName설명은 여기에 설명된credential_name과 일치합니다.
- 필수
사용법:
- Apigee Hybrid를 아직 설치하지 않은 경우 설치 단계를 계속 진행하면 과정 중에 변경사항이 적용됩니다.
Apigee Hybrid를 이미 설치했으면 다음을 사용해서 새로운 변경사항을 적용해야 합니다.
kubectl apply -k overlays/instances/{INSTANCE_NAME}
멀티 리전
이 구성요소는 멀티 리전 cassandra 배포를 구성하는 동안 사용할 수 있습니다. 자세한 내용은 GKE 및 GKE On-Prem의 멀티 리전 배포를 참조하세요.
사용 설정:
datastore/kustomization.yaml 파일에서 "./components/multi-region" 줄의 주석 처리를 삭제합니다.
수행할 수정사항:
components/multi-region/cassandra-data-replication.yaml
- 필수
source.region데이터 복제를 위해 사용되는 소스 Cassandra 데이터 센터 이름입니다. 소스 클러스터에서 다음 명령어를 사용하여 식별할 수 있습니다.
kubectl get apigeedatastore -n ${APIGEE_NAMESPACE} -o=jsonpath='{.items[*].spec.components.cassandra.properties.datacenter}'- 필수
components/multi-region/patch.yaml
- 필수
spec.components.properties.multiRegionSeedHost모든 소스 cassandra 포드의 포드 IP입니다. 다음을 사용할 수 있습니다.
kubectl get pods -n ${APIGEE_NAMESPACE} -o wide- 모든 포드를 나열하고 cassandra 포드의 IP를 가져오려면 다음 명령어를 사용합니다.
kubectl get pods -o wide -n apigee출력이 다음과 같이 표시됩니다.
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE apigee-cassandra-default-0 1/1 Running 0 5d 10.0.0.11 gke-k8s-dc-2-default-pool-a2206492-p55d apigee-cassandra-default-1 1/1 Running 0 5d 10.0.2.4 gke-k8s-dc-2-default-pool-e9daaab3-tjmz apigee-cassandra-default-2 1/1 Running 0 5d 10.0.3.5 gke-k8s-dc-2-default-pool-e589awq3-kjch- 필수
자세한 내용은 "GKE, GKE On-Prem, AKS의 멀티 리전 배포"의 GKE 기본 요건을 참조하세요.
사용법:
이 구성요소는 대부분 새로운 클러스터에서 Apigee Hybrid를 설정 중이고 다른 작동 중인 Apigee Hybrid 설정이 이미 있는 경우에 사용하는 것이 적합합니다.
- Cassandra 포드 간의 적절한 통신을 보장하려면 새 클러스터와 기존 클러스터가 모두 동일한 TLS 인증서를 사용해야 합니다. 따라서 기존 클러스터에서
apigee-root-certificate보안 비밀을 복사하고 이를 새 클러스터에서도 사용해야 합니다. 실행:
kubectl config get-contexts- 모든 kubernetes 컨텍스트 목록을 가져오고 실행하려면 다음 안내를 따르세요.
kubectl config use-context SOURCE_CLUSTER_CONTEXT여기서 SOURCE_CLUSTER_CONTEXT는 소스 Kubernetes 클러스터 컨텍스트의 이름입니다.
파일에 루트 인증서 보안 비밀을 저장합니다.
kubectl get secret/apigee-root-certificate -n cert-manager -o yaml > apigee-root-certificate.yaml클러스터 컨텍스트를 Apigee Hybrid를 설치 중인 새 클러스터로 전환합니다.
kubectl config use-context ${NEW_CLUSTER_CONTEXT}새 클러스터에 루트 보안 비밀을 만듭니다.
kubectl -n cert-manager apply -f apigee-root-certificate.yaml새 루트 인증서 만들기를 사용 중지합니다. 이렇게 하면 새
apigee-root-certificate가 생성되지 않고 이전 단계에서 만든 루트 인증서가 덮어쓰기됩니다.overlays/initialization/certificates/kustomization.yaml파일의 다음 줄에서 주석 처리를 삭제합니다.# components: # - ./components/disable-apigee-root-certificate-generation기본 Apigee Hybrid 설치 또는 맞춤설정된 Apigee Hybrid 설치를 사용해서 나머지 Apigee Hybrid 설치를 계속합니다. 예를 들어 기본 Apigee Hybrid 설치를 따라 다음을 실행할 수 있습니다.
./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION다음 명령어를 사용하여 다시 빌드 상태를 확인합니다.
kubectl -n ${APIGEE_NAMESPACE} get apigeeds -o json | jq ".items[].status.cassandraDataReplication"로그에서 재빌드 프로세스를 확인합니다. 또한 nodetool 상태 명령어를 사용하여 데이터 크기를 확인합니다.
kubectl logs apigee-cassandra-default-0 -f -n ${APIGEE_NAMESPACE} kubectl exec apigee-cassandra-default-0 -n ${APIGEE_NAMESPACE} -- nodetool -u ${JMX_USER} -pw ${JMX_PASSWORD} status다음 명령어를 사용하여 다시 빌드 상태를 확인합니다.
kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"다음과 같은 결과가 표시됩니다.
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }참조: 멀티 리전 배포
components/multi-region/patch.yaml에서 다음 줄을 삭제합니다.properties: multiRegionSeedHost: {IP_ADDRESS} # To be modified. REQUIRED변경사항을 적용합니다.
kubectl apply -k overlays/instances/{INSTANCE_NAME}
개념
이미지 허브
Docker 컨테이너 이미지는 일반적으로 다음 형식으로 지정됩니다.
${REGISTRY_HOST_PATH}/${IMAGE_NAME}:${IMAGE_TAG}
다이제스트를 사용하는 경우는 다음과 같습니다.
${REGISTRY_HOST_PATH}/${IMAGE_NAME}@${DIGEST}
Apigee에는 "이미지 허브" 개념이 사용됩니다. 여기에서 위 형식은 ${REGISTRY_HOST_PATH}를 참조합니다. 이미지 허브의 기본값은 gcr.io/apigee-release/hybrid/입니다.
DIGEST를 사용하는 이미지는 각 하위 구성요소에 개별적으로 설정해야 합니다.
Apigee는 다음 값을 조합하여 최종 이미지 경로를 생성합니다.
- apigee-hybrid-config.yaml에서 재정의할 수 있는 '이미지 허브'(이미지 허브를 재정의하는 방법에 대한 자세한 단계는 비공개 저장소의 Docker 이미지 사용 섹션 참조)
- 각 개별 구성요소의 yaml 파일 내부에 있는
version필드에서 가져온IMAGE_TAG값(예:apigee-organization.yaml). Apigee는 Apigee Hybrid 버전으로 이미지를 태그합니다. 즉, Apigee Hybrid 버전 1.8의 경우IMAGE_TAG는 1.8입니다. IMAGE_NAME은 이미지가 사용될 컨테이너의 이름에서 암시적으로 결정됩니다. 예를 들어apigee-runtime컨테이너의 경우IMAGE_NAME은 apigee-runtime이 됩니다.
따라서 이미지 경로의 전체 예시는 gcr.io/apigee-release/hybrid/apigee-runtime:1.8.0이 됩니다.
이러한 방식으로 최종 이미지 경로가 생성되고, 그런 다음 해당 포드의 각 컨테이너 내에서 사용됩니다.
Google Cloud 서비스 계정
Google Cloud 서비스 계정은 애플리케이션에서 Google API에 승인된 호출을 하는 데 사용하는 계정입니다. Google Cloud 서비스 계정 키를 다운로드한 다음 인증 용도로 사용할 수 있습니다. Apigee는 사용자가 보안 비밀을 만들어 서비스 계정 키를 제공할 것으로 예상합니다. 다음은 서비스 계정 키를 조회하는 보안 비밀의 기본 이름과 구성요소의 이름입니다.
| 구성요소 | 하위 구성요소 | 서비스 계정 키가 포함된 기본 kubernetes 보안 비밀 이름 |
|---|---|---|
| 조직 | ||
| connectAgent | apigee-connect-agent-gcp-sa-key-${ORG_NAME} |
|
| watcher | apigee-watcher-gcp-sa-key-${ORG_NAME} |
|
| mart | apigee-mart-gcp-sa-key-${ORG_NAME} |
|
| udca | apigee-udca-gcp-sa-key-${ORG_NAME} |
|
| ingressGateways | 해당 사항 없음 | |
| environment | ||
| runtime | apigee-runtime-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
| udca | apigee-udca-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
| synchronizer | apigee-synchronizer-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
| 원격 분석 | ||
| 측정항목 | apigee-metrics-gcp-sa-key |
|
| containerLogs | apigee-logger-gcp-sa-key |
Kubernetes 서비스 계정
Kubernetes 서비스 계정은 클러스터의 포드에 ID를 제공합니다. 기본적으로 Apigee 컨트롤러는 자동으로 이를 만듭니다. 하지만 만들기를 재정의하려는 경우(예: 워크로드 아이덴티티 사용 시), 다양한 하위 구성요소에서 podServiceAccountName 필드를 지정하면 됩니다.
워크로드 아이덴티티 패치를 사용 설정할 때 k8s 서비스 계정의 기본 이름과 함께 kubernetes 서비스 계정을 지정할 수 있는 구성요소 및 해당 하위 구성요소의 목록입니다.
| 구성요소 | 하위 구성요소 | 기본 이름(워크로드 아이덴티티 패치를 사용 설정한 경우에 사용 가능) |
|---|---|---|
| 조직 | ||
| connectAgent | apigee-connect-agent-svc-account-${ORG_NAME} |
|
| watcher | apigee-watcher-svc-account-${ORG_NAME} |
|
| mart | apigee-mart-svc-account-${ORG_NAME} |
|
| udca | apigee-udca-svc-account-${ORG_NAME} |
|
| environment | ||
| synchronizer | apigee-synchronizer-svc-account-${ORG_NAME}-${ENV_NAME} |
|
| udca | apigee-udca-svc-account-${ORG_NAME}-${ENV_NAME} |
|
| runtime | apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME} |
|
| datastore | ||
| Cassandra | apigee-datastore-svc-account |
|
| 원격 분석 | ||
| metricsApp | apigee-metricsApp-svc-account |
|
| metricsProxy | apigee-metricsProxy-svc-account |
|
| metricsAdapter | apigee-metricsAdapter-svc-account |
|
| containerLogs | apigee-container-logs-svc-account |
워크로드 아이덴티티
워크로드 아이덴티티를 사용하면 GKE에서 실행되는 포드(kubernetes 서비스 계정 사용)가 Google Cloud 서비스 계정 키 없이 Google Cloud API로 직접 인증할 수 있습니다.
새 환경 추가
.
├── ...
├── instances/instance1/components
│ ├── ...
│ ├── environments
│ │ ├── dev
│ │ │ └── apigee-environment.yaml
│ │ │ └── secrets.yaml
│ │ └── new-env-name (new)
│ │ └── apigee-environment.yaml (new)
│ │ └── secrets.yaml (new)
└── ...
새 환경을 추가하는 것은 다음과 같이 간단합니다.
- 환경 디렉터리(또는 폴더를 구조화한 방식) 내에 새 폴더를 만듭니다.
apigee-environment.yaml파일을 기존 환경에서 새 폴더로 복사합니다.- 새 환경에 새 서비스 계정 및 암호화 키를 만들려면
secrets.yaml을 새 폴더에 복사하고 다른 기존 환경과 구분되도록 보안 비밀의 이름을 적절하게 변경합니다(일반적으로 환경 이름을 서픽스로 추가). - 다음과 같이
apigee-environment.yaml을 적절하게 변경합니다.- 환경 이름을 변경합니다.
- 새 서비스 계정 및 암호화 키를 만들려면 yaml에서 이를 올바르게 참조해야 합니다.
yaml을 적용합니다.
kubectl apply -f components/environments/new-env-name/secrets.yaml
kubectl apply -f components/environments/new-env-name/apigee-environment.yaml
Apigee Datastore에서 강제 삭제 사용
어떠한 이유로 데이터 스토어 삭제가 진행되지 않으면 이제 클러스터의 현재 상태와 관계없이 다음 명령어를 사용하여 Apigee Datastore를 강제로 삭제할 수 있습니다.
apigee네임스페이스에서apigeeds를 삭제합니다.Kubectl delete -n apigee apigeeds default이 단계가 중지되면 CTRL + C를 사용해서 단계를 종료할 수 있습니다.
새
apigeeds를 수정합니다.Kubectl edit -n apigee apigeeds defaultapigee datastore spec에서 forceDelete 필드 추가/업데이트
spec: forceDelete: true파일을 저장하고 종료합니다.
이제 데이터 스토어가 삭제될 때까지 기다립니다. 모든 cassandra 리소스를 삭제하려면 몇 분 정도 걸릴 수 있습니다.
스크립트 이해
apigee-hybrid-setup.sh 스크립트는 몇 가지 기본 검증을 수행하고 맞춤설정된 Apigee Hybrid 설치에 설명된 대로 더 자세한 맞춤설정이 필요한 경우 수행해야 하는 단계를 자동화하도록 도와줍니다. 맞춤설정된 설치를 사용하더라도 스크립트를 부분적으로 사용하여 특정 태스크를 지원할 수 있습니다.
./tools/apigee-hybrid-setup.sh --help를 실행해서 지원되는 플래그 목록을 보고 스크립트에 대한 추가 도움말을 확인할 수 있습니다. 현재 지원되는 플래그는 다음과 같습니다.
--namespace기본적으로 이 스크립트는apigee네임스페이스에 모든 구성요소를 설치합니다. 이 플래그를 사용해서 네임스페이스 이름을 지정하여 이 동작을 변경할 수 있습니다.--orgApigee 조직의 이름을 제공하는 데 사용됩니다. 지정하지 않으면 현재gcloud에서 선택된 Google Cloud 프로젝트가 기본값으로 사용됩니다.--envgroup조직 내 환경 그룹의 이름을 제공하는 데 사용됩니다. 지정하지 않으면 환경 그룹 이름을 확인하기 위해 제어 영역 API에 쿼리를 수행하려고 시도합니다. 환경 그룹이 여러 개 발견되면 오류가 반환되고 스크립트가 종료됩니다.--env조직 내 환경의 이름을 제공하는 데 사용됩니다. 지정하지 않으면 환경 이름을 확인하기 위해 제어 영역 API에 쿼리를 수행하려고 시도합니다. 환경이 여러 개 발견되거나 환경이 환경 그룹의 일부가 아니면 오류가 반환되고 스크립트가 종료됩니다.--cluster-nameKubernetes 클러스터 이름입니다.--cluster-regionKubernetes 클러스터가 위치한 리전입니다.--gcp-project-idKubernetes 클러스터가 있는 Google Cloud 프로젝트 ID입니다.--ingress-domainistio ingress-gateway의 자체 서명 TLS 인증서를 생성하는 데 사용할 호스트 이름/도메인 이름을 지정합니다. 아무것도 지정하지 않은 경우 envgroup에서 값을 가져오도록 제어 영역 API를 쿼리하여 값을 확인하려고 시도합니다. 환경 그룹을 확인하는 데 문제가 있거나 환경 그룹에 구성된 호스트 이름이 여러 개 있으면 오류가 반환되고 스크립트가 종료됩니다.--generate-internal-tls-certsGoogle에서 생성한 인증서와 키 쌍이 포함된 apigee-ca라는 Kubernetes 보안 비밀이 생성됩니다.--create-ingress-tls-certsTLS 통신에 사용될 인증서 및 키 쌍을 포함하는 istio-system 네임스페이스 내에{ORG_NAME}-{ENV_GROUP_NAME}(조직 및 envgroup 이름에서 파생)이라는 보안 비밀을 생성합니다. 이러한 인증서를 생성하는 데 사용된 도메인 이름은 envgroup 구성에서 발견된 값에서 파생됩니다. 충돌이 발생할 경우(예: 여러 도메인을 찾은 경우) 적절한 오류 메시지가 표시됩니다.--create-gcp-sa-and-secretsGoogle Cloud 프로젝트에 단일 Google Cloud 서비스 계정을 만들고 키를 다운로드한 후 키가 포함된 Kubernetes 보안 비밀을 만듭니다. 보안 비밀의 이름은 Google Cloud 서비스 계정에서 찾을 수 있습니다.--fill-values다양한 yaml에서 필요에 따라 org, env, envgroup 및 기타 이름의 값을 바꿉니다.--apply-configuration인증서 발급기관, 커스텀 리소스 정의, 웹훅, 역할, 컨트롤러 리소스를 만듭니다. 리소스가 올바른 순서로 생성되고 모든 리소스가 정상이 될 때까지 명령이 차단됩니다.-- rename-directories환경 및 환경 그룹 이름을 올바른 환경 및 환경 그룹 이름으로 바꿉니다.--verbose디버깅할 세부 출력을 표시합니다.--help사용 정보를 표시합니다.--setup-all이 스크립트로 수행할 수 있는 모든 태스크를 실행합니다.
Apigee Hybrid 설정 폴더 구조
apigee-hybrid-setup 폴더의 계층 구조는 기본적으로 다음과 같습니다.
.
├── bases
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-controller-deployment.yaml
│ │ │ └── kustomization.yaml
│ │ └── apigee-ingressgateway-manager
│ │ ├── apigee-ingressgateway-manager-deployment.yaml
│ │ └── kustomization.yaml
│ ├── datastore
│ │ └── backup-and-restore
│ │ ├── backup
│ │ │ ├── cronjob.yaml
│ │ │ └── kustomization.yaml
│ │ ├── common
│ │ │ ├── kustomization.yaml
│ │ │ ├── rbac.yaml
│ │ │ └── tls-certificate.yaml
│ │ └── restore
│ │ ├── job.yaml
│ │ └── kustomization.yaml
│ └── initialization
│ ├── certificates
│ │ ├── certificates-and-issuers.yaml
│ │ └── kustomization.yaml
│ ├── crds
│ │ ├── customresourcedefinition-apigeedatastores.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeedeployments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeenvironments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeredis.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeerouteconfigs.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeroutes.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeetelemetries.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-cassandradatareplications.apigee.cloud.google.com.yaml
│ │ └── kustomization.yaml
│ ├── openshift
│ │ ├── kustomization.yaml
│ │ └── scc.yaml
│ ├── rbac
│ │ ├── apigee-controller
│ │ │ ├── kustomization.yaml
│ │ │ └── rbac.yaml
│ │ └── apigee-embedded-ingress-controller
│ │ ├── cluster-role-bindings.yaml
│ │ ├── cluster-roles.yaml
│ │ ├── kustomization.yaml
│ │ └── service-account.yaml
│ └── webhooks
│ ├── kustomization.yaml
│ ├── mutatingwebhookconfiguration.yaml
│ └── validatingwebhookconfiguration.yaml
├── CONTRIBUTING.md
├── docs
│ └── api_references
│ ├── v1alpha1.md
│ └── v1alpha2.md
├── kokoro
│ ├── build.sh
│ ├── common.cfg
│ ├── continuous.cfg
│ ├── presubmit.cfg
│ └── release.cfg
├── LICENSE
├── overlays
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-hybrid-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ ├── apigee-ingressgateway-manager
│ │ │ ├── apigee-ingressgateway-manager-deployment-patch.yaml
│ │ │ ├── apigee-istio-mesh-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ ├── initialization
│ │ ├── certificates
│ │ │ ├── apigee-ingressgateway-manager-certificate-patch.yaml
│ │ │ ├── apigee-serving-cert-patch.yaml
│ │ │ ├── components
│ │ │ │ └── disable-apigee-root-certificate-generation
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ ├── crds
│ │ │ └── kustomization.yaml
│ │ ├── ingress
│ │ │ ├── envoyfilter-1.11.yaml
│ │ │ └── kustomization.yaml
│ │ ├── namespace.yaml
│ │ ├── openshift
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── rbac
│ │ │ ├── apigee-controller
│ │ │ │ └── kustomization.yaml
│ │ │ ├── apigee-ingressgateway-manager
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ └── webhooks
│ │ ├── kustomization.yaml
│ │ ├── mutatingwebhookconfiguration.yaml
│ │ └── validatingwebhookconfiguration.yaml
│ └── instances
│ └── instance1
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── gcs-backup
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── cron-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── gcs-restore
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── job-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── multi-region
│ │ │ │ ├── cassandra-data-replication.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── non-gcs-backup
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── cron-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── non-gcs-restore
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── job-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── openshift-scc
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── scc.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-envgroup
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── openshift-scc
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ └── workload-identity-metrics
│ │ ├── kustomization.yaml
│ │ ├── patch.yaml
│ │ └── service-accounts.yaml
│ └── kustomization.yaml
├── README.md
├── templates
│ ├── certificate-org-envgroup.yaml
│ ├── secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml
│ ├── secret-apigee-cassandra-backup-and-restore-key-file.yaml
│ ├── secret-gcp-sa-key.yaml
│ └── secret-ingress-tls-cert-key.yaml
└── tools
├── apigee-hybrid-setup.sh
├── apigee-pull-push.sh
├── common.sh
├── create-service-account.sh
└── dump_kubernetes.sh
위의 파일 버전은 GitHub 저장소의 preview-1 태그에서 찾을 수 있습니다. https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1
위의 폴더는 Apigee Hybrid 런타임에 대한 Kubernetes 매니페스트를 포함하며 구성 관리를 위해 Kustomize를 사용합니다. 매니페스트는 Kustomize 기본 및 오버레이의 개념을 기반으로 구성됩니다. 기본 폴더에는 모든 Apigee 구성요소에 대한 최소 필수 구성이 포함됩니다. 오버레이 폴더에는 구성요소로 정의된 여러 추가 기능(구성)이 포함됩니다. kustomization.yaml에서 구성요소 참조의 주석 처리를 삭제하여 구성요소를 정의할 수 있습니다.
예 : Apigee Datastore에 대해 gcs-backup을 사용 설정하기 위해 gcs-backup 구성요소는 아래 customization.yaml에서 주석 처리가 삭제되었습니다.
경로 : ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/kustomization.yaml
namespace: "apigee" # kpt-set: ${APIGEE_NAMESPACE}
resources:
- apigee-datastore.yaml
components:
# - ./components/http-proxy
# - ./components/nodeselector/
# - ./components/imagepullsecret
# - ./components/workload-identity
# - ./components/openshift-scc
- ./components/gcs-backup (uncommented)
# - ./components/gcs-restore
# - ./components/non-gcs-backup
# - ./components/non-gcs-restore
맞춤설정이 필요한 값은 gcs 백업을 위해 해당 patch.yaml에 설정해야 합니다.
아래 파일에서 CLOUD_STORAGE_BUCKET_PATH의 값을 사용자가 설정해야 합니다.
경로: $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/datastore/components/gcs-backup/cron-patch.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: apigee-cassandra-backup
namespace: apigee
spec:
schedule: "${YOUR_BACKUP_SCHEDULE_CODE}" # To be modified
jobTemplate:
spec:
template:
spec:
containers:
- name: apigee-cassandra-backup
env:
- name: APIGEE_CLOUDPROVIDER
value: "GCP"
- name: DATABASE_STORAGE_BUCKET
value: "${CLOUD_STORAGE_BUCKET_PATH}" # To be modified. REQUIRED
volumeMounts:
- name: apigee-cassandra-backup
mountPath: /var/secrets/google
volumes:
- name: apigee-cassandra-backup
secret:
secretName: "apigee-cassandra-backup-and-restore-svc-account"
마찬가지로 Apigee 구성요소의 kustomization.yaml에 있는 구성요소에 대해 주석 처리를 삭제해서 맞춤설정이 필요한 모든 기능/구성을 사용 설정해야 합니다. 또한 필요에 따라 구성요소의 patch.yaml에 있는 필드의 해당 값을 적절하게 설정해야 합니다.
폴더 및 파일에 대한 간단한 설명은 다음과 같습니다.
기본
이 폴더에는 각 Apigee 구성요소에 필요한 최소 구성이 포함된 템플릿이 있습니다. 이 폴더에서 매니페스트를 수정할 필요는 없습니다.
오버레이
이 폴더에는 추가 구성요소에 대한 kustomize 구성요소 템플릿이 포함되어 있습니다.
초기화
namespaces.yaml
Apigee 데이터 영역 구성요소를 설치할 네임스페이스입니다. 기본 네임스페이스 이름은 apigee입니다.
certificates
웹훅에 인증서를 발급하는 데 사용되는 Issuer 및 Certificate 리소스를 포함합니다. TLS 통신을 위해 다양한 포드에 인증서를 발급하는 데 사용되는 Issuer도 포함됩니다.
rbac
다양한 구성요소에서 사용되는 Role, ClusterRole, RoleBinding, ClusterRoleBinding이 포함됩니다.
crds
Contains the definition of all the CRDs which are used by Apigee.
웹훅
커스텀 리소스에서 유효성 검사를 수행하는 데 사용되는 ValidatingWebhookConfiguration 및 MutatingWebhookConfiguration을 포함합니다.
수신
모든 인그레스 포드에 적용할 수 있는 구성을 포함합니다. 예: 일반적인 헤더 수정, 상태 점검 등
openshift
openshift SecurityContextConstraints의 정의를 포함합니다.
컨트롤러
apigee-controller
apigee-hybrid-config.yaml
apigee-controller-manager.yaml에 입력으로 제공되는 ConfigMap을 포함합니다. 이 ConfigMap에는 그 중에서도 imageHub, imagePullSecrets, forwardProxy 등의 구성이 포함되어 있습니다.
apigee-controller-deployment.yaml
컨트롤러 및 웹훅에 대한 2개 서비스와 컨트롤러의 배포를 포함합니다. 컨트롤러에 비공개 이미지를 사용하려는 경우 여기에서 항목을 변경해야 합니다.
istiod
Apigee-istio-mesh-config.yaml Apigee에서 사용하는 Istio의 메시 구성이 포함됩니다. 클러스터에서 ASM/Istio의 다른 설치에는 적용되지 않습니다.
apigee-ingressgateway-manager-deployment-patch.yaml
Istiod의 서비스 및 배포를 포함합니다. Apigee 사용 사례에만 사용되는 비공개 istiod입니다.
instances/{instanceName}
datastore
apigee-datastore.yaml
Cassandra를 관리하는 ApigeeDatastore 커스텀 리소스가 포함됩니다.
secrets.yaml
데이터 스토어의 기본 사용자 인증 정보를 포함합니다.
redis
apigee-redis.yaml
redis를 관리하는 ApigeeRedis 커스텀 리소스를 포함합니다.
secrets.yaml
데이터 스토어의 기본 사용자 인증 정보를 포함합니다.
조직
apigee-organization.yaml
connectAgent, watcherAndSynchronizer, MART, UDCA, 인그레스와 같은 Ingress.다른 하위 구성요소를 관리하는 ApigeeOrganization 커스텀 리소스를 포함합니다.
secrets.yaml
apigee-organization.yaml에서 참조되는 Secret을 포함합니다. 일부 보안 비밀은 스크립트에서 생성되는 대로 주석 처리됩니다. 생성을 중지하면 직접 만들어야 합니다.
environments
조직의 모든 환경을 포함합니다. 사용자가 이미 제공한 항목을 복사하고 요구사항에 따라 구성하여 각 환경에 대해 개별 폴더를 만들 수 있습니다.
dev
apigee-environment.yaml
런타임과 같은 다른 하위 구성요소를 관리하는 ApigeeEnvironment 커스텀 리소스를 포함합니다.
secrets.yaml
apigee-environment.yaml에서 참조되는 Secret을 포함합니다. 일부 보안 비밀은 스크립트에서 생성되는 대로 주석 처리됩니다. 생성을 중지하면 직접 만들어야 합니다.
원격 분석
apigee-telemetry.yaml
ApigeeTelemetry 커스텀 리소스를 포함합니다.
secrets.yaml
apigee-telemetry.yaml에서 참조되는 Secret을 포함합니다. 일부 보안 비밀은 스크립트에서 생성되는 대로 주석 처리됩니다. 생성을 중지하면 직접 만들어야 합니다.
route-config
dev-envgroup
apigee-route-config.yaml
ApigeeRouteConfig 커스텀 리소스를 포함합니다.
secrets.yaml
apigee-route-config.yaml에서 참조되는 Secret을 포함합니다. apigee-hybrid-setup.sh 스크립트를 통해 자동으로 생성되기 때문에 주석 처리되며 수동으로 만들려는 결정한 경우 어떤 형태의 보안 비밀인지 샘플을 제공하기 위해 보관됩니다.
diagnostic
diagnostic-collector.yaml
진단 배포를 표시하는 데 사용되는 리소스입니다.
tools
apigee-hybrid-setup.sh
apigee-create-service-account.sh
dump-kubernetes.sh
apigee-pull-push.sh
외부 Vault에 서비스 계정 키 저장
Vault(Hashicorp)는 Google, Azure, AWS 등에서 제공하는 보안 비밀 저장소와 여러 가지 통합을 제공하는 인기 있는 보안 비밀 관리 시스템입니다. Hashicorp Vault를 사용하면 외부 소스에서 보안 비밀을 가져온 후 kubernetes 리소스 내에서 사용할 수 있습니다. Vault를 사용하여 보안 비밀을 가져올 수 있는 몇 가지 방법이 있습니다. 다음 단계는 Vault CSI 제공업체를 사용하여 Vault에서 제공하는 일부 보안 비밀 엔진에 저장된 Google Cloud 서비스 계정 키를 마운트하는 방법의 기본 예시입니다.
- Helm을 사용해서 클러스터에 Vault 관련 리소스를 설치합니다. 시스템에 helm을 설정하는 방법에 대한 Helm 설치의 단계를 따릅니다.
다음과 같이 Vault Helm 차트의 단계를 수행합니다.
Helm에 Hashicorp 저장소 추가
helm repo add hashicorp https://helm.releases.hashicorp.comHelm 저장소 업데이트
helm repo updateVault 설치
helm install vault hashicorp/vault \ --set "server.dev.enabled=true" \ --set "injector.enabled=false" \ --set "csi.enabled=true"
이제 Vault 내에 보안 비밀을 저장합니다.
기본 dev 포드 내에서 셸 가져오기
kubectl exec -it vault-0 -- /bin/sh ```이 예시에서는 데이터 저장을 위해 키/값 보안 비밀 엔진을 사용합니다.
vault kv put secret/runtime-gcp-sa-key key="${BASE_64_ENCODED_KEY}"키가 성공적으로 저장되었는지 확인하려면 다음 안내를 따르세요.
vault kv get secret/runtime-gcp-sa-key
런타임 포드가 키를 가져올 수 있도록 인증을 설정합니다. Kubernetes 서비스 계정에서 설명한 대로 Kubernetes 서비스 계정은 포드에 ID를 제공하며 다른 시스템에서 인증할 수 있도록 합니다.
기본 dev 포드 내에서 셸 가져오기
kubectl exec -it vault-0 -- /bin/shkubernetes 인증 방법 사용 설정
vault auth enable kubernetes인증 구성 작성
vault write auth/kubernetes/config \ issuer="https://kubernetes.default.svc.cluster.local" \ token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \ kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \ kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \ disable_iss_validation=true인증 정책 만들기
vault policy write apigee-runtime-app - <<EOF path "secret/data/runtime-gcp-sa-key" { capabilities = ["read"] } EOF정책을 서비스 계정에 바인딩
vault write auth/kubernetes/role/apigee-runtime-role \ bound_service_account_names=apigee-runtime-sa \ bound_service_account_namespaces=${APIGEE_NAMESPACE} \ policies=apigee-runtime-app \ ttl=20m
여기에서는 서비스 계정이 Apigee 네임스페이스 내에 있다고 가정합니다. Apigee 설치를 위해 다른 네임스페이스가 있으면 해당 이름을 사용합니다.
vault-0 내에서 셸 종료
exit
보안 비밀 저장소 CSI 드라이버 설치
# Add repo to helm helm repo add secrets-store-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/secrets-store-csi-driver/master/charts # Install driver in cluster helm install csi secrets-store-csi-driver/secrets-store-csi-driverVault 내에서 만든 보안 비밀을 참조하는
SecretProviderClasskubernetes 리소스를 만듭니다.cat > spc-vault.yaml <<EOF apiVersion: secrets-store.csi.x-k8s.io/v1alpha1 kind: SecretProviderClass metadata: name: vault-apigee-runtime-gcp-sa-key spec: provider: vault parameters: vaultAddress: "http://vault.default:8200" roleName: "apigee-runtime-role" objects: | - objectName: "client_secret.json" secretPath: "secret/data/runtime-gcp-sa-key" secretKey: "key" EOFyaml을 적용합니다.kubectl apply -f spc-vault.yaml4.e 단계에서 권한을 할당한 kubernetes 서비스 계정을 만듭니다.
kubectl create serviceaccount -n ${APIGEE_NAMESPACE} apigee-runtime-sa환경의 apigee-environment.yaml 파일을 수정하고 다음 줄을 추가합니다.
apiVersion: apigee.cloud.google.com/v1alpha2 kind: ApigeeEnvironment # existing content spec: name: {ENV_NAME} organizationRef: {ORG_NAME} components: runtime: # existing content pod containers: - name: apigee-runtime podServiceAccountName: apigee-runtime-sa # existing content volumeMounts: - name: secrets-store-inline mountPath: "/opt/apigee/sa" readOnly: true volumes: - name: secrets-store-inline csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: "vault-apigee-runtime-gcp-sa-key"변경사항을 적용합니다.
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/$ENV_NAME
Apigee Hybrid 업그레이드
기본 요건에 언급된 모든 요구사항을 완료해야 합니다. 또한 모든 구성요소를 연속으로 재시작해서 클러스터가 정상 상태인지 확인하는 것이 좋습니다. 다시 시작하는 순서는 Cassandra, Redis, ApigeeOrganization, ApigeeEnvironment입니다.
백업 만들기
현재 Hybrid 설정의 백업 사본을 만듭니다. 업그레이드를 현재 버전으로 다시 롤백해야 하는 경우 백업이 필요합니다.
tar -czvf apigee-hybrid-install.v-X.Y.Z.tar.gz $HYBRID_INSTALL_BASE_DIRCassandra 데이터베이스의 백업을 만듭니다. Cassandra 백업은 재해 시나리오에 대비할 수 있는 중요한 보호 수단입니다.
필요한 경우 Kubernetes 플랫폼 업그레이드
이 단계가 매번 필요하지는 않지만 최신 버전의 Apigee Hybrid에서 더 이상 지원되지 않는 경우 Kubernetes, OpenShift 및 cert-manager, cassandra 등의 구성요소와 같은 Kubernetes 플랫폼을 업그레이드해야 합니다. 문서에는 지원되는 버전의 플랫폼 및 구성요소가 포함됩니다.
설정 파일 다운로드
저장소를 다운로드하고 기존 Apigee Hybrid 설정의 bases 및 tools 폴더를 새 폴더로 바꿉니다.
https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1에서 GitHub 저장소 preview-1 태그를 클론합니다.클론된 저장소의 구조는 Apigee Hybrid 설정 폴더 구조에 설명된 것과 유사합니다.
기존 Apigee Hybrid 설정에서 초기화, 도구, 컨트롤러 폴더를 바꿉니다.
export HYBRID_INSTALL_HOME=PATH_TO_PREVIOUS_HYBRID_INSTALL_DIRECTORY mv -f bases $HYBRID_INSTALL_HOME/bases mv -f tools $HYBRID_INSTALL_HOME/tools
필요한 경우 서비스 계정 권한 업데이트
이 단계는 매번 필요하지는 않지만 새 서비스 계정을 만들거나 필요한 경우 기존 서비스 계정의 권한을 업데이트해야 합니다. 업그레이드 가이드에서는 수정하거나 만들어야 하는 서비스 계정과 추가해야 하는 역할에 대한 자세한 내용을 제공합니다.
기존 서비스 계정의 권한을 수정해야 하는 경우 적절한
gcloud명령어를 사용합니다. 업그레이드 가이드에 자세한 명령어와 추가해야 하는 역할이 나와 있습니다.gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:apigee-component@$PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/$NEW_ROLE"최신 Apigee Hybrid 버전에 신규/기존 구성요소를 위한 추가 서비스 계정이 필요할 수 있는 경우 서비스 계정을 만들어야 합니다. 도구 폴더 내에서 제공된
apigee-create-service-account.sh스크립트를 사용하여 새 서비스 계정을 만들 수 있습니다. 스크립트는 4단계에서 이미 업데이트되므로 만들어야 하는 새 서비스 계정에 필요한 세부정보와 새 프로필이 있습니다.새로 만든 서비스 계정 이름은 해당 구성요소 CR에 참조되어야 합니다.
./tools/create-service-account --env prod --profile apigee-component
컨트롤러 업그레이드
${INSTALL_DIR}/overlays/instances/$INSTANCE_DIR/kustomization.yaml에 나열된 구성요소의 버전 필드를 관련 하이브리드 버전으로 변경합니다.
다음은 샘플 $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/kustomization.yaml 파일입니다. 버전 필드의 값을 관련 버전으로 업데이트해야 합니다.
resources:
- datastore/
- environments/
- organization/
- redis/
- route-config/
- telemetry/
patches:
- target:
group: apigee.cloud.google.com
version: v1alpha1
kind: ApigeeDatastore
patch: |-
- op: add
path: /spec/version
value: 1-6-1 (Modify the version)
- target:
group: apigee.cloud.google.com
version: v1alpha2
kind: ApigeeEnvironment
patch: |-
- op: add
path: /spec/version
value: 1-6-1 (Modify the version)
Apigee Hybrid 설치 워크플로의 초기화 리소스 및 컨트롤러 만들기와 동일한 단계를 따릅니다. 스크립트를 사용하거나 제공된 수동 단계에 따라 초기화 리소스 및 컨트롤러를 업그레이드할 수 있습니다.
Apigee Kubernetes 구성요소 업데이트
다음과 같이 변경해야 합니다. - 아키텍처 변경, 새로운 필드의 도입 또는 기존 필드의 지원 중단이 발생한 경우 업그레이드 가이드에 제공된 안내에 따라 적절한 변경사항으로 CR을 수정해야 합니다. - 최소한 CR 내에서 버전 필드(설치된 Apigee Hybrid 버전)를 새로운 Apigee Hybrid 버전으로 업데이트해야 합니다.
Apigee CR의 변경사항을 적용합니다. 비프로덕션 환경의 경우 모든 변경사항을 Apigee 구성요소에 동시에 적용할 수 있습니다.
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
Apigee Hybrid 롤백
apigee-hybrid-setup 복원
이전 버전의 Apigee Hybrid 설정이 포함된 디렉터리로 이동합니다. 사용할 수 없는 경우 Apigee Hybrid 업그레이드 중 1단계[링크]에서 만든 ZIP 파일에서 복원합니다.
Kubernetes 구성요소 롤백
Apigee CR 변경사항
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}컨트롤러 롤백
Apigee Hybrid 설치 워크플로의 초기화 리소스 및 컨트롤러 만들기와 동일한 단계를 따릅니다. 스크립트를 사용하거나 제공된 수동 단계에 따라 초기화 리소스 및 컨트롤러를 롤백할 수 있습니다.
삭제
새 버전의 Hybrid에 도입된 새 구성요소 또는 서비스 계정과 같이 업그레이드 중에 생성된 모든 새 추가 리소스를 삭제해야 합니다. 삭제해야 할 모든 리소스와 이를 삭제하는 단계가 업그레이드 가이드에 제공됩니다.
환경 삭제
다음은 kubernetes 클러스터에서 환경에 관련된 모든 리소스를 삭제하기 위한 단계에 대한 설명입니다.
환경 CR의 이름을 가져옵니다. 이렇게 하려면 모든 환경을 가져오면 됩니다.
kubectl get env -n ${APIGEE_NAMESPACE}APIGEE_ENV환경 변수에 리소스 이름을 저장합니다.환경 암호화 키를 삭제합니다. 예를 들어 암호화 키 이름을 변경하지 않은 경우 다음을 사용하여 삭제할 수 있습니다.
kubectl delete secret -n ${APIGEE_NAMESPACE} $APIGEE_ENV-encryption-keysGoogle Cloud 서비스 계정 보안 비밀을 삭제합니다.
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}')Kubernetes 서비스 계정을 삭제합니다.
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')Apigee 환경 커스텀 리소스를 삭제합니다.
kubectl -n ${APIGEE_NAMESPACE} delete env $APIGEE_ENV
Hybrid 설정 삭제
Kubernetes 클러스터에서 Apigee Hybrid와 관련된 모든 리소스를 삭제하는 단계는 다음과 같습니다.
Apigee 사용자 설정 및 스키마 설정 작업을 삭제해야 합니다.
# To list all jobs in ${APIGEE_NAMESPACE} kubectl -n ${APIGEE_NAMESPACE} get jobs # To delete all jobs in ${APIGEE_NAMESPACE} kubectl -n ${APIGEE_NAMESPACE} delete jobs $(kubectl -n ${APIGEE_NAMESPACE} get jobs -o custom-columns=':.metadata.name')배포된 Apigee Hybrid 데이터 영역 구성요소를 삭제해야 합니다. 다음 명령어를 사용하여 모든 구성요소를 삭제합니다.
kubectl delete -k ${INSTALL_DIR}/overlays/instances/$INSTANCE_NAME이 단계는 kubernetes 서비스 계정 보안 비밀, Google Cloud 서비스 계정 보안 비밀 등의 기본 이름을 사용하지 않는 경우에만 필요합니다. 기본 이름을 사용하고 있다면 다음 단계에서 삭제되며 그렇지 않으면 다음 명령어를 사용하여 수동으로 삭제해야 합니다.
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get ${APIGEE_COMPONENT} ${APIGEE_COMPONENT_NAME} -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}') kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get ${APIGEE_COMPONENT} ${APIGEE_COMPONENT_NAME} -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')OpenShift의 경우 Apigee Hybrid 설치 중에 생성된 scc(보안 컨텍스트 제약조건)를 삭제해야 합니다.
kubectl delete scc ${SECURITY_CONTEXT_CONSTRAINTS_NAME}아래 명령어를 실행하여 역할, 역할 바인딩, CRD, 컨트롤러 배포 등을 삭제합니다.
kubectl delete -k ${INSTALL_DIR}/overlays/initialization/ingress kubectl delete -k ${INSTALL_DIR}/overlays/initialization/rbac kubectl delete -k ${INSTALL_DIR}/overlays/initialization/webhooks kubectl delete -k ${INSTALL_DIR}/overlays/initialization/crds kubectl delete -k ${INSTALL_DIR}/overlays/initialization/certificates아래 명령어를 실행하여 Apigee 네임스페이스를 삭제합니다.
kubectl delete -f ${INSTALL_DIR}/overlays/initialization/namespace.yaml또는 다음 명령어를 사용합니다.
kubectl delete $APIGEE_NAMESPACE
멀티 인스턴스 설치
멀티 인스턴스 설정은 여러 리전에 걸쳐서 확장될 수 있거나 동일한 리전 내에 있을 수 있는 하이브리드 설정을 나타냅니다. 환경 구성(복제본 등)이 인스턴스마다 항상 다르기 때문에 Apigee는 별도의 디렉터리 구조에 두 번째 인스턴스 구성을 조직하는 것을 권장합니다. 모든 인스턴스의 구성은 분리되며 해당하는 폴더 구조로 독립적으로 구성됩니다.
예를 들어 멀티 리전 시나리오에서 Active-Passive 설정의 경우 다양한 크기와 구성으로 웜 대기 상태의 두 번째 리전을 구성할 수 있습니다.
아래 폴더 구조에서 instance1라는 instance1 디렉터리의 사본을 만들고 필요에 따라 데이터 스토어와 인그레스 구성을 수정할 수 있습니다.
apigee-hybrid-setup: 다중 인스턴스 설정을 위한 폴더 구조
.
├── bases
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-controller-deployment.yaml
│ │ │ └── kustomization.yaml
│ │ └── istiod
│ │ ├── apigee-ingressgateway-manager-deployment.yaml
│ │ └── kustomization.yaml
│ └── initialization
│ ├── certificates
│ │ ├── certificates-and-issuers.yaml
│ │ └── kustomization.yaml
│ ├── crds
│ │ ├── customresourcedefinition-apigeedatastores.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeedeployments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeenvironments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeredis.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeerouteconfigs.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeroutes.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeetelemetries.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-cassandradatareplications.apigee.cloud.google.com.yaml
│ │ └── kustomization.yaml
│ ├── ingress
│ │ ├── envoyfilter-1.11.yaml
│ │ └── kustomization.yaml
│ ├── openshift
│ │ ├── kustomization.yaml
│ │ └── scc.yaml
│ ├── rbac
│ │ ├── apigee-controller
│ │ │ ├── kustomization.yaml
│ │ │ └── rbac.yaml
│ │ └── apigee-embedded-ingress-controller
│ │ ├── cluster-role-bindings.yaml
│ │ ├── cluster-roles.yaml
│ │ ├── kustomization.yaml
│ │ └── service-account.yaml
│ └── webhooks
│ ├── kustomization.yaml
│ ├── mutatingwebhookconfiguration.yaml
│ └── validatingwebhookconfiguration.yaml
├── instances
│ └── instance1 (Add the 2nd instance under instances directory similar to instance1)
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-env-group
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ └── workload-identity-metrics
│ │ ├── apigee-workload-identities.yaml
│ │ ├── kustomization.yaml
│ │ └── patch.yaml
│ └── kustomization.yaml
├── overlays
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-hybrid-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ ├── istiod
│ │ │ ├── apigee-ingressgateway-manager-deployment-patch.yaml
│ │ │ ├── apigee-istio-mesh-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ ├── initialization
│ │ ├── certificates
│ │ │ ├── apigee-ingressgateway-manager-certificate.yaml
│ │ │ └── kustomization.yaml
│ │ ├── crds
│ │ │ └── kustomization.yaml
│ │ ├── ingress
│ │ │ └── kustomization.yaml
│ │ ├── namespace.yaml
│ │ ├── openshift
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── rbac
│ │ │ ├── apigee-controller
│ │ │ │ └── kustomization.yaml
│ │ │ ├── apigee-embedded-ingress-controller
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ └── webhooks
│ │ ├── kustomization.yaml
│ │ ├── mutatingwebhookconfiguration.yaml
│ │ └── validatingwebhookconfiguration.yaml
│ └── instances
│ └── instance1
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── openshift-scc
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── scc.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-envgroup
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── openshift-scc
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ └── kustomization.yaml
│ │ └── workload-identity-metrics
│ │ ├── apigee-workload-identities.yaml
│ │ ├── kustomization.yaml
│ │ └── patch.yaml
│ └── kustomization.yaml
├── README.md
├── templates
│ ├── ingress-certificate.yaml
│ ├── ingress-cert-secret.yaml
│ └── service-account-key-secret.yaml
└── tools
├── apigee-hybrid-setup.sh
├── common.sh
├── create-service-account.sh
└── dump_kubernetes.sh
GKE에 멀티 인스턴스 설정
기본 요건
Hybrid의 여러 인스턴스를 구성하기 전에 다음 기본 요건을 완료해야 합니다.
- 여러 가지 CIDR 블록을 사용하여 (같거나 다른) 여러 리전에 Kubernetes 클러스터를 설정합니다.
- 리전 간 통신 설정
- 모든 리전의 Kubernetes 클러스터 사이에서 Cassandra 포트 7000과 7001을 엽니다(7000은 문제 해결 중에 백업 옵션으로 사용할 수 있음). 포트 구성도 참조하세요.
ntpdate와 같은 도구를 사용하여 서버 시간이 동기화되었는지 확인할 수 있습니다.
멀티 리전 시드 호스트 구성
- 기존 인스턴스에서 $INSTANCE_NAME 폴더의 사본을 만들고 인스턴스 폴더에 추가합니다.
- instance1 네임스페이스와 다른 경우 네임스페이스 필드의 값을 수정합니다.
- 인그레스 TLS 인증서 지정에 나온 단계에 따라 다른 인스턴스의 인그레스 구성을 수정합니다.
다른 인스턴스의 부하 분산기 IP를 구성하는 방법에 대한 자세한 내용은 Apigee 인그레스 게이트웨이 관리를 참조하세요.
kubectl 컨텍스트를 원래 클러스터로 설정한 후에 시드 이름을 검색합니다.
kubectl config use-context original-cluster-name다음 kubectl 명령어를 실행하여 현재 리전에서 Cassandra의 시드 호스트 주소를 식별합니다.
kubectl get pods -o wide -n apigee -l app=apigee-cassandra이전 명령어에서 반환된 모든 포드 IP는 멀티 리전 시드 호스트로 간주될 수 있습니다.
두 번째 인스턴스에서 ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/apigee-datastore.yaml 아래의 Apigee 데이터 스토어 CR의 multiRegionSeedHost 값을 구성합니다.
새 인스턴스 설정
컨텍스트를 기존 클러스터로 설정합니다.
kubectl config use-context existing-cluster-nameapigee-ca 보안 비밀을 파일로 내보냅니다.
kubectl -n cert-manager get secret apigee-root-certificate -o yaml > apigee-root-certificate.yaml컨텍스트를 새 리전의 클러스터 이름으로 설정합니다.
kubectl config use-context NEW_CLUSTER_NAME보안 비밀을 새 클러스터로 가져옵니다.
kubectl -n cert-manager apply -f apigee-root-certificate.yaml초기화 리소스 및 컨트롤러 만들기에 설명된 단계에 따라 새 인스턴스(리전)에 하이브리드를 설치합니다.
새 데이터 센터의 모든 포드에 Cassandra를 설정합니다. 다음 명령어를 사용하여 클러스터에서 apigeeorg를 가져옵니다.
kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"cassandra 데이터 복제 커스텀 리소스(YAML) 파일을 만듭니다. 파일 이름에는 제한이 없습니다. 다음 예시에서 파일 이름은 datareplication.yaml입니다. 파일에는 다음이 포함되어야 합니다.
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: REGION_EXPANSION namespace: NAMESPACE spec: organizationRef: APIGEEORG_VALUE force: false source: region: SOURCE_REGION각 항목의 의미는 다음과 같습니다.
- REGION_EXPANSION은 이 메타데이터에 지정할 이름입니다. 'cassandra-data-replication'과 같은 이름을 선택할 수 있습니다.
- NAMESPACE는 두 번째 인스턴스에 대해 선택한 동일한 네임스페이스입니다. 일반적으로 "apigee"입니다.
- APIGEEORG_VALUE는 이전 단계의 kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" 명령어의 값 출력입니다.
- SOURCE_REGION은 소스 클러스터의 nodetool 상태의 cassandra 데이터 센터 값입니다.
다음 명령어를 사용하여 CassandraDataReplication을 적용합니다.
kubectl apply -f datareplication.yaml다음 명령어를 사용하여 다시 빌드 상태를 확인합니다.
kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"결과는 다음과 같이 표시됩니다.
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }로그에서 재빌드 프로세스를 확인합니다. 또한 nodetool 상태 명령어를 사용하여 데이터 크기를 확인합니다.
kubectl logs apigee-cassandra-default-0 -f -n apigeeJMX_user 및 JMX_password의 경우 datastore/secrets.yaml을 참조하세요.
kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool -u JMX_user -pw JMX_password statusApigee Datastore CR에서
multiRegionSeedHost를 삭제하고 아래 명령어를 실행하여 변경사항을 적용합니다.kubectl apply k apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastoreCassandra 클러스터 상태 확인
다음 명령어는 두 데이터 센터에서 클러스터 설정이 성공했는지 여부를 확인하는 데 유용합니다. 이 명령어는 두 리전의 nodetool 상태를 확인합니다.
kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool -u JMX_user -pw JMX_password statusDatacenter: us-central1 ======================= Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.12.1.45 112.09 KiB 256 100.0% 3c98c816-3f4d-48f0-9717-03d0c998637f ra-1 UN 10.12.4.36 95.27 KiB 256 100.0% 0a36383d-1d9e-41e2-924c-7b62be12d6cc ra-1 UN 10.12.5.22 88.7 KiB 256 100.0% 3561f4fa-af3d-4ea4-93b2-79ac7e938201 ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.4.33 78.69 KiB 256 100.0% a200217d-260b-45cd-b83c-182b27ff4c99 ra-1 UN 10.0.0.21 78.68 KiB 256 100.0% 9f3364b9-a7a1-409c-9356-b7d1d312e52b ra-1 UN 10.0.1.26 15.46 KiB 256 100.0% 1666df0f-702e-4c5b-8b6e-086d0f2e47fa ra-1
문제 해결
지원 가능성, 진단, 문제 해결 가이드
멀티 리전 Apigee Hybrid 설정에서 forceDelete를 사용한 후 수동 삭제
- 다음 예시에서는
us-east1및us-west1의 2개 리전이 있습니다. us-west1리전에서 강제 삭제를 사용하여 Apigee Datastore가 삭제되었습니다.us-east1리전에는 cassandra가 작동되어 실행 중입니다.다음 명령어를 사용하여
apigeeds가 삭제되었는지 확인합니다.kubectl get apigeeds -n apigee No resources found in apigee namespace.kubectl 컨텍스트를 cassandra 클러스터가 계속 실행 중인 다른 리전(여기서는
us-east1)으로 변경합니다.데이터 스토어가 실행 중인 상태인지 확인
kubectl get apigeeds -n apigee NAME STATE AGE default running 23h실행 리전(여기서는
us-east1)의 cassandra 포드 중 하나로 실행kubectl exec -it -n apigee apigee-cassandra-default-0 -- bash apigee@apigee-cassandra-default-0:~$nodetool 상태를 확인합니다. 삭제된 리전(여기서는
us-west1)의 모든 노드가 표시됩니다.apigee@apigee-cassandra-default-0:~$ nodetool -u ${APIGEE_JMX_USER} -pw ${APIGEE_JMX_PASSWORD} statusDatacenter: us-east1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.52.0.212 685.01 KiB 256 ? e1aa61e3-4eae-4549-9b58-506d495d87ab ra-1 UN 10.52.0.72 606.75 KiB 256 ? 477dfc03-f93e-40ea-810a-d15769822ad5 ra-1 UN 10.52.0.104 648.3 KiB 256 ? a8854cff-c2e3-4f0c-a342-e692787efcab ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack DN 10.60.0.143 567.06 KiB 256 ? 355d6ace-ab77-42cb-8138-9993bfd62d0e ra-1 DN 10.60.0.40 535.99 KiB 256 ? 4ed2c903-ff56-40fa-a15e-80a3de3cb22d ra-1 DN 10.60.0.17 573.08 KiB 256 ? f9a50d19-c04a-4d0d-a088-612384bed9f5 ra-1삭제된 리전(여기서는
us-west1)의 모든 노드 삭제apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode 355d6ace-ab77-42cb-8138-9993bfd62d0e apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode 4ed2c903-ff56-40fa-a15e-80a3de3cb22d apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode f9a50d19-c04a-4d0d-a088-612384bed9f5삭제된 리전 (여기서는
us-west1)의 노드가 남아 있지 않은지 확인합니다.apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD statusDatacenter: us-east1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.52.0.212 699.71 KiB 256 ? e1aa61e3-4eae-4549-9b58-506d495d87ab ra-1 UN 10.52.0.72 586.77 KiB 256 ? 477dfc03-f93e-40ea-810a-d15769822ad5 ra-1 UN 10.52.0.104 623.6 KiB 256 ? a8854cff-c2e3-4f0c-a342-e692787efcab ra-1이 작업이 완료되면 상위 리전(여기서는
us-east1)에서 사용자 설정 작업을 삭제합니다. 몇 초 후에 작업이 자동으로 다시 생성됩니다.kubectl get jobs -n apigeeNAME COMPLETIONS DURATION AGE apigee-cassandra-schema-setup-apigee--0d2504c 0/1 5m54s 5m54s apigee-cassandra-user-setup--apigee--0d2504c 0/1 7s 7skubectl delete job apigee-cassandra-user-setup--apigee--0d2504c사용자 설정 작업이 완료될 때까지 기다립니다.
kubectl get jobs -n apigeeNAME COMPLETIONS DURATION AGE apigee-cassandra-schema-setup-apigee--0d2504c 1/1 5m54s 5m54s apigee-cassandra-user-setup--apigee--0d2504c 1/1 7m 7m키스페이스에 삭제된 리전이 없는지 확인합니다.
Cassandra 디버깅 포드를 만듭니다.
다음 명령어를 사용하여 디버깅 포드의 cqlsh에 로그인합니다.
apigee@cassandra-debug-client:~$ cqlsh apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local -u ddl_user --ssl Password:모든 키스페이스에서
us-west1리전이 삭제되었는지 확인합니다.ddl_user@cqlsh> SELECT * FROM system_schema.keyspaces;keyspace_name | durable_writes | replication ---------------------------+----------------+----------------------------------------------------------------------------------- cache_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} rtc_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system_auth | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system_schema | True | {'class': 'org.apache.cassandra.locator.LocalStrategy'} quota_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} kms_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system_distributed | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system | True | {'class': 'org.apache.cassandra.locator.LocalStrategy'} perses | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} kvm_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system_traces | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} (11 rows)