Como adicionar várias organizações híbridas a um cluster

Neste tópico, discutimos como adicionar uma segunda organização híbrida da Apigee (org) a um cluster atual do Kubernetes. Nessa configuração multi-org, as duas organizações usam e compartilham o mesmo anel Cassandra. Cada organização pode ter vários ambientes e grupos de ambientes configurados.

Opções de várias organizações

Nesta seção, descrevemos como o suporte da Apigee lida com clusters e recomendações de várias organizações para implantações futuras:

Se você tiver clusters do Kubernetes de várias organizações implantados em contextos de não produção e produção, o suporte da Apigee continuará a oferecer suporte a eles. No entanto, observe as limitações técnicas descritas na próxima seção. Recomendamos que você mude todas as implantações de produção futuras para usar uma organização da Apigee por cluster.
Se você tiver clusters de várias organizações em contextos de não produção, o suporte da Apigee continuará a oferecer suporte a eles. Recomendamos que você migre todos os clusters de produção para uma nova configuração que use uma organização da Apigee por cluster.

Limitações

Uma configuração de várias organizações por cluster é compatível com as seguintes limitações:

As métricas do pod são enviadas apenas para o primeiro projeto do Google Cloud configurado. Essa limitação é mais aparente na ferramenta Cloud Monitoring. Isso só afeta as métricas do cluster. A análise da API não é afetada. As métricas das outras organizações da Apigee não serão enviadas para o projeto correspondente do Google Cloud.
Todos os registros dos pods são enviados para o primeiro projeto do Google Cloud configurado. Essa limitação é mais aparente na ferramenta Cloud Logging. As métricas das outras organizações da Apigee não serão enviadas para o projeto correspondente do Google Cloud. Os registros ainda são capturados no nível do pod e podem ser recuperados com comandos kubectl. No entanto, eles não são enviados para o projeto do Cloud correto por meio do Cloud Logging.
Não é possível excluir dados da organização no banco de dados do Cassandra para apenas uma organização. Isso significa que não é possível remover organizações de maneira seletiva. Qualquer modificação na configuração do banco de dados afeta todas as organizações implantadas no cluster.
O procedimento de upgrade híbrido atualiza todo o cluster de uma só vez.
O backup e a restauração são feitos como um cluster e não podem ser feitos para uma organização específica.
O recurso de monitoramento da API Apigee (linha do tempo, recente, investigar) só funciona para a primeira organização que foi configurada e implantada. Ele não vai funcionar para as outras organizações em um cluster de várias organizações.

Pré-requisitos

Antes de continuar, observe o seguinte:

É necessário ter uma organização híbrida atual com um ou mais ambientes instalados e configurados em um cluster do Kubernetes de saída. Consulte as instruções de instalação híbrida.
Ao combinar várias organizações em um único cluster, todas as versões híbridas precisam ser correspondentes. Antes de adicionar uma segunda organização a um cluster, faça o upgrade da instalação híbrida atual, se necessário. Consulte Como fazer upgrade da Apigee híbrida.

Criar uma organização para adicionar ao cluster atual

Para criar a organização adicional, siga as etapas na Parte 1: configuração do projeto e da organização.

Configurar a nova organização

Nas etapas a seguir, você vai criar um novo arquivo de modificações que vai ser configurado para a nova organização. Um arquivo overrides.yaml é compatível apenas com informações de uma organização. Portanto, você precisa criar um novo arquivo overrides.yaml e aplicá-lo ao cluster atual do Kubernetes.

Crie contas de serviço para usar com a nova organização. Veja mais informações em Criar contas de serviço.
Anote os arquivos de certificado TLS (.key e .pem) no diretório certs. Se precisar criá-los novamente, siga as instruções em Criar certificados TLS.
Copie o overrides.yaml atual em um novo arquivo para usar como ponto de partida para configurar a nova organização. Por exemplo: new-overrides.yaml.

Edite o novo arquivo de modificações com as seguintes configurações:

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

A tabela a seguir descreve cada um dos valores de propriedade que você precisa fornecer no arquivo de modificações. Para mais informações, consulte Referência da propriedade de configuração.

Variável	Descrição
`new-org-name`	O nome da nova organização.
`instance-id`	Todas as organizações nesse cluster precisam ter o mesmo ID de instância. Portanto, ela precisa corresponder à entrada `instanceID` no arquivo de modificações da organização original. No caso de instalações multirregionais, cada região requer o próprio cluster. Os clusters individuais não abrangem regiões. Portanto, cada cluster precisa ter o próprio ID de instância exclusivo compartilhado por cada organização no cluster.
`existing-cluster-name`	O nome do cluster ao qual você está adicionando esta organização. Ele precisa corresponder à entrada `k8sCluster.name` no arquivo de modificações do cluster original.
`existing-cluster-analytics-region`	A região onde o cluster original é provisionado. Ele precisa corresponder à entrada `k8sCluster.region` no arquivo de modificações do cluster original.
`new-project-id`	O ID do seu novo projeto. O ID do projeto e o nome da organização são os mesmos.
`new-project-default-location`	A região de análise que você especificou ao criar a nova organização. Ele não precisa ser o mesmo da região da organização atual.
`namespace`	Todas as organizações no cluster precisam compartilhar o mesmo namespace. Use o mesmo namespace usado para a organização original. O namespace padrão é `apigee`.
`new-environment-group-name`	O novo grupo de ambiente que você criou para a nova organização.
`cert-file-name` e `key-file-name`	Os arquivos de certificado e de chave TLS do cluster que você verificou ou criou na etapa 1 nesta seção.
`new-environment-name`	O nome do ambiente que você criou para a nova organização.
`new-service-accounts-directory`	O diretório em que os arquivos de chave da conta de serviço que você criou para a nova organização estão localizados.

Aplique a configuração

Aplique a nova configuração da organização ao cluster:

Faça uma instalação de simulação para verificar se há problemas:
```
apigeectl apply -f overrides/new-overrides.yaml --org --dry-run=client
```
Observação: é recomendável fazer uma simulação antes de aplicar a configuração a fim de determinar se há algum problema.
Se não houver problemas, aplique os componentes no nível da organização. Esta etapa instala os jobs do Cassandra (usuário e esquema), Apigee Connect, Apigee Watcher e MART:
```
apigeectl apply -f overrides/new-overrides.yaml --org
```
Instale o ambiente. Nesta etapa, os componentes do ambiente de execução da Apigee, sincronizador e UDCA são instalados:
```
apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME} --dry-run=client
```
```
apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME}
```
Observação: se você tiver vários ambientes na nova organização, repita esta etapa para cada ambiente.
Aplique as alterações do balanceador de carga. Esta etapa configura a entrada para detectar os novos hosts virtuais da segunda organização:
Importante: não duplique nomes de host/nomes de domínio entre dois orgs, porque pode resultar em roteamento imprevisível.
```
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts --dry-run=client
```
```
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts
```
Ative o acesso do sincronizador à nova organização seguindo as etapas em Ativar acesso do sincronizador.