클러스터에 여러 하이브리드 조직 추가

이 주제에서는 두 번째 Apigee Hybrid 조직을 기존 Kubernetes 클러스터에 추가하는 방법을 설명합니다. 이 멀티 조직 구성에서는 두 조직 모두 같은 Cassandra 링을 사용하고 공유합니다. 조직마다 여러 환경 및 환경 그룹이 구성될 수 있습니다.

제한사항

클러스터별 다중 조직 구성은 다음 제한 사항과 함께 지원됩니다. 이러한 제한사항이 완화될 때까지 이 구성을 사용하지 않는 것이 좋습니다.

Apigee Hybrid 인스턴스를 여러 개 사용하려면 인스턴스마다 고유한 클러스터가 있어야 합니다. 동일한 Kubernetes 클러스터에서 실행되는 여러 Apigee Hybrid 인스턴스에서는 불안정 문제가 발생하여 다운타임이 발생할 수 있습니다.
포드 측정항목은 구성된 첫 번째 Google Cloud 프로젝트로만 전송됩니다. 이러한 제한은 Cloud Monitoring 도구에서 가장 두드러집니다. 클러스터 측정항목에만 영향을 미치며 API 분석은 영향을 받지 않습니다. 다른 Apigee 조직의 측정항목은 일치하는 Google Cloud 프로젝트로 전송되지 않습니다.
포드의 모든 로깅은 구성된 첫 번째 Google Cloud 프로젝트로 전송됩니다. 이러한 제한은 Cloud Logging 도구에서 가장 두드러집니다. 다른 Apigee 조직의 로그는 일치하는 Google Cloud 프로젝트로 전송되지 않습니다. 로그는 계속 포드 수준에서 캡처되며 kubectl 명령어로 검색될 수 있습니다. 하지만 Cloud Logging을 통해 올바른 Cloud 프로젝트로 전송되지 않습니다.
조직 하나의 Cassandra 데이터베이스에서 조직 데이터를 삭제할 수 없습니다. 즉, 조직을 선택적으로 삭제할 수 없습니다. 데이터베이스 구성을 수정하면 해당 클러스터에 배포된 모든 조직이 영향을 받습니다.
하이브리드 업그레이드 절차는 전체 클러스터를 한 번에 모두 업그레이드합니다.
백업과 복원은 클러스터로 수행되며 특정 조직에 대해 수행될 수 없습니다.
Apigee API 모니터링 기능(타임라인, 최근, 조사)은 구성 및 배포된 첫 번째 조직에서만 작동합니다. 다중 조직 클러스터의 다른 조직에서는 작동하지 않습니다.

다중 조직 옵션

이 섹션에서는 Apigee 지원팀에서 향후 배포를 위해 기존 다중 조직 클러스터와 권장사항을 처리하는 방법을 설명합니다.

기존 멀티 조직 Kubernetes 클러스터가 비프로덕션 및 프로덕션 컨텍스트에 배포된 경우 Apigee 지원팀은 이를 계속 지원합니다. 하지만 다음 섹션에서 설명하는 기술 제한사항에 유의하세요. 향후 프로덕션 배포를 변경하여 클러스터당 Apigee 조직 하나를 사용하는 것이 좋습니다.
비프로덕션 컨텍스트에 기존 멀티 조직 클러스터가 있으면 Apigee 지원팀은 이를 계속 지원합니다. 프로덕션 클러스터를 클러스터당 Apigee 조직 하나를 사용하는 새 구성으로 마이그레이션하는 것이 좋습니다.

기본 요건

계속하기 전에 다음 사항에 유의하세요.

기존 하이브리드 조직에 환경이 하나 이상 설치되어 있고 기존 Kubernetes 클러스터에서 구성되어 있어야 합니다. 하이브리드 설치 안내를 참조하세요.
단일 클러스터에서 조직 여러 개를 결합하면 하이브리드 버전이 모두 일치해야 합니다. 두 번째 조직을 클러스터에 추가하기 전에 필요한 경우 기존 하이브리드 설치를 업그레이드합니다. Apigee Hybrid 업그레이드를 참조하세요.

기존 클러스터에 추가할 조직 만들기

추가 조직을 만들려면 1부: 프로젝트 및 조직 설정의 단계를 수행합니다.

새 조직 구성

다음 단계에서는 새 재정의 파일을 만들고 새 조직에 맞게 구성합니다. overrides.yaml 파일에서는 조직 하나의 정보만 지원할 수 있습니다. 따라서 새 overrides.yaml 파일을 만들어 기존 Kubernetes 클러스터에 적용해야 합니다.

새 조직에서 사용할 서비스 계정을 만듭니다. 서비스 계정 만들기를 참조하세요.
certs 디렉터리의 TLS 인증서 파일(.key 및 .pem)을 기록해 둡니다. 인증서를 다시 만들어야 하는 경우 TLS 인증서 만들기의 안내를 따르면 됩니다.
기존 overrides.yaml을 새 파일에 복사하여 새 조직을 구성하기 위한 시작점으로 사용합니다. 예를 들면 new-overrides.yaml입니다.

다음 구성으로 새 재정의 파일을 수정합니다.

org: "new-org-name"
instanceID: "instance-id"   ## Must match the instanceID of your existing org.

k8sCluster:
  name: "existing-cluster-name"
  region: "existing-cluster-analytics-region"

gcp:
  projectID: "new-project-id"
  name: "new-project-id"
  region: "new-project-default-location"

namespace: namespace ## must be the same for both new and existing orgs

virtualhosts:
  - name: new-environment-group-name
    sslCertPath: ./certs/cert-file-name # .crt or .pem
    sslKeyPath: ./certs/key-file-name # .key

envs:
  - name: new-environment-name
    serviceAccountPaths:
      runtime: ./new-service-accounts-directory/new-project-id-apigee-runtime.json
      synchronizer: ./new-service-accounts-directory/new-project-id-apigee-synchronizer.json
      udca: ./new-service-accounts-directory/new-project-id-apigee-udca.json

connectAgent:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-mart.json

mart:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-mart.json

metrics:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-metrics.json

watcher:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-watcher.json

다음 표에서는 재정의 파일에 제공해야 하는 각 속성 값을 설명합니다. 자세한 내용은 구성 속성 참조를 참조하세요.

변수	설명
`new-org-name`	새 조직의 이름입니다.
`instance-id`	이 클러스터의 모든 조직에 동일한 인스턴스 ID가 있어야 합니다. 따라서 원래 조직의 재정의 파일에 있는 `instanceID` 항목과 일치해야 합니다. 멀티 리전 설치의 경우 개별 클러스터는 리전에 걸쳐 있지 않으므로 리전마다 고유한 클러스터가 필요합니다. 따라서 클러스터마다 클러스터의 모든 조직에서 공유하는 고유한 인스턴스 ID가 있어야 합니다.
`existing-cluster-name`	이 조직을 추가할 클러스터의 이름입니다. 원본 클러스터의 재정의 파일에 있는 `k8sCluster.name` 항목과 일치해야 합니다.
`existing-cluster-analytics-region`	원래 클러스터가 프로비저닝된 리전입니다. 원본 클러스터의 재정의 파일에 있는 `k8sCluster.region` 항목과 일치해야 합니다.
`new-project-id`	새로운 프로젝트의 프로젝트 ID입니다. 프로젝트 ID와 조직 이름은 동일합니다.
`new-project-default-location`	새 조직을 만들 때 지정한 분석 리전입니다. 기존 조직의 리전과 동일하지 않아도 됩니다.
`namespace`	클러스터의 모든 조직은 같은 네임스페이스를 공유해야 합니다. 원래 조직에 사용된 네임스페이스와 동일한 네임스페이스를 사용해야 합니다. 기본 네임스페이스는 `apigee`입니다.
`new-environment-group-name`	새 조직을 위해 만든 새 환경 그룹입니다.
`cert-file-name` 및 `key-file-name`	이 섹션의 1단계에서 확인하거나 만든 클러스터의 TLS 인증서와 키 파일입니다.
`new-environment-name`	새 조직을 위해 만든 환경의 이름입니다.
`new-service-accounts-directory`	새 조직을 위해 만든 서비스 계정 키 파일이 있는 디렉터리입니다.

구성 적용

새 조직 구성을 클러스터에 적용합니다.

테스트 실행 설치를 수행하여 문제가 있는지 확인합니다.
```
apigeectl apply -f overrides/new-overrides.yaml --org --dry-run=client
```
참고: 구성을 적용하기 전에 테스트 실행을 수행하여 문제가 있는지 확인하는 것이 좋습니다.
문제가 없으면 조직 수준 구성요소를 적용합니다. 이 단계에서는 Cassandra 작업(사용자 및 스키마), Apigee Connect, Apigee Watcher, MART 서비스를 설치합니다.
```
apigeectl apply -f overrides/new-overrides.yaml --org
```
환경을 설치합니다. 이 단계에서는 환경별로 apigee-runtime, 동기화 담당자, UDCA 구성요소를 설치합니다.
```
apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME} --dry-run=client
```
```
apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME}
```
참고: 새 조직에 환경이 여러 개 있는 경우 환경마다 이 단계를 반복하세요.
부하 분산기 변경사항을 적용합니다. 이 단계는 인그레스에서 두 번째 조직의 새 가상 호스트를 리슨하도록 구성합니다.
중요: 두 조직 간에 호스트 이름/도메인 이름을 복제하지 마세요. 그렇지 않으면 예측할 수 없는 라우팅이 발생할 수 있습니다.
```
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts --dry-run=client
```
```
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts
```
동기화 담당자 액세스 사용 설정의 다음 단계에 따라 새 조직에 대한 동기화 담당자 액세스를 사용 설정합니다.