Pré-visualização da nova instalação e administração do Apigee Hybrid

Esta pré-visualização foi descontinuada.

Pré-visualização — Apigee hybrid new install process (discontinued)

Esta funcionalidade está sujeita aos "Termos das Ofertas de Pré-DG" na secção Termos Gerais de Serviço dos Termos Específicos do Serviço. As funcionalidades de pré-DG estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

---

Guia do utilizador de pré-visualização:
pré-visualização dos novos procedimentos de instalação e administração para o Apigee hybrid v1.8.

---

Neste documento:

• Pré-visualizar
  • Feedback
• Vista geral
  • Alterações no novo processo de instalação
• Pré-requisitos
  • Versão de pré-visualização
  • Configuração do Apigee Hybrid
  • Ferramentas
• Instalação básica do Apigee Hybrid
  • Transfira ficheiros de configuração
  • Configuração de corrida
• Instalação personalizada do Apigee Hybrid
  • Transfira ficheiros de configuração
  • Criar espaço de nomes
  • Usar imagens de Docker de repositórios privados (opcional)
  • Configurar imagePullSecrets (opcional)
  • Configurar proxy de encaminhamento (opcional)
  • Especificar certificados TLS de entrada
  • Atualize a implementação de entrada
  • Configurar contas de serviço personalizadas do Google Cloud
  • Usar identidades de cargas de trabalho
  • Edite ficheiros YAML de recursos
  • Crie recursos de inicialização e um controlador
  • Conceda autorizações à conta de serviço do sincronizador para interagir com o plano de controlo
  • Crie componentes do plano de dados do Apigee
  • Aguarde o início dos recursos
  • Personalize a instalação do cert-manager num espaço de nomes personalizado
• Kustomize e componentes
  • Overview
  • Como usar os componentes
  • OpenShift
  • imagepullsecret
  • nodeselector
  • workload-identity
  • http-proxy
  • logger e métricas
  • gcs-backup e gcs-restore
  • non-gcs-backup e non-gcs-restore
  • http-client
  • non-sni-client
  • http-and-non-sni-client
  • multirregião
• Conceitos
  • Adicionar um novo ambiente
  • Usar a eliminação forçada no Apigee Datastore
• Compreender o guião
• Estrutura de pastas de configuração do Apigee Hybrid
• Armazenar chaves de contas de serviço em cofres externos
• Atualização do Apigee Hybrid
  • Criar cópia de segurança
  • Atualize a sua plataforma Kubernetes, se necessário
  • Transfira ficheiros de configuração
  • Atualize as autorizações da conta de serviço, se necessário
  • Atualize o controlador
  • Atualize os componentes do Kubernetes da Apigee
• Reversão do Apigee Hybrid
  • Restaure o apigee-hybrid-setup
  • Reverta os componentes do Kubernetes
  • Reverter controlador
• Limpeza
• Eliminar um ambiente
  • Eliminar uma configuração híbrida
• Instalação de várias instâncias
  • Configuração de várias instâncias no GKE
  • Resolução de problemas
  • Guia de capacidade de suporte, diagnóstico e resolução de problemas
  • Limpeza manual após usar o forceDelete na configuração do Apigee Hybrid em várias regiões

Pré-visualização

---

Nota: este documento e o software que está a documentar fazem parte de uma versão de pré-visualização. A Apigee não garante o software nem os procedimentos nesta pré-visualização. A documentação e o software estão sujeitos a alterações sem aviso prévio.

Este documento destina-se à personagem do operador do Apigee (utilizadores que instalam/gerem/administram instalações híbridas do Apigee). A experiência na instalação do Apigee hybrid numa das plataformas Kubernetes suportadas é um pré-requisito para seguir as instruções neste documento. Recomendamos que crie uma organização do Apigee de avaliação para experimentar os passos abaixo.

Feedback

Envie feedback sobre este processo para [e-mail].

---

Vista geral

A nova experiência de instalação do Apigee Hybrid instala componentes do Apigee através do kubectl e integra a instalação e a gestão do Apigee Hybrid com ferramentas de orquestração de configuração do Kubernetes, como o Kustomize. As validações e a visibilidade melhoradas dos componentes que estão a ser instalados oferecem uma melhor capacidade de depuração e melhoram o processo de instalação geral.

Um script de instalação, apigee-hybrid-setup.sh, oferece uma ferramenta simples para a instalação básica. Pode usá-lo para criar a sua instalação híbrida e, em seguida, modificá-la para se adequar às suas necessidades com o kubectl, ou pode criar a sua instalação híbrida do zero usando o kubectl. Todas as propriedades de configuração do Apigee hybrid são armazenadas em ficheiros YAML, um para cada componente principal. Isto permite um controlo muito mais detalhado da sua instalação híbrida no ambiente do Kubernetes. Pode encontrar os ficheiros de configuração e os scripts de instalação no repositório no GitHub.

Alterações no novo processo de instalação

O Apigee está a alterar o processo de instalação do Apigee Hybrid pelos seguintes motivos:

• O novo método de instalação do Apigee hybrid pode ser integrado com ferramentas de CI/CD do Kubernetes existentes, como o Argo, o Flux ou o Anthos Config Management, que não usam um ficheiro de configuração overrides.yaml.
• O Apigee Hybrid forneceu apigeectl, uma ferramenta de criação de modelos personalizada que gera manifestos do Kubernetes (entre outras coisas) para instalar e gerir o Apigee Hybrid em clusters do Kubernetes. O novo processo de instalação e gestão oferece uma experiência semelhante à de outros fornecedores de software.
• O novo processo permite uma instalação básica rápida através da criação automática de contas de serviço com as autorizações necessárias, certificados TLS, preenchimento prévio de valores predefinidos e outros elementos fundamentais necessários.

Pré-requisitos

Antes de usar esta instalação de pré-visualização, tem de cumprir os seguintes pré-requisitos:

Versão de pré-visualização

Esta pré-visualização destina-se a funcionar com a versão 1.8.x do Apigee Hybrid. As versões posteriores do Apigee hybrid não são suportadas.

Configuração do Apigee Hybrid

Antes de avançar com a instalação real do Apigee Hybrid, espera-se que tenha concluído as seguintes instruções indicadas nas secções seguintes da documentação:

1. Configuração do projeto e da organização
   • Vista geral dos pré-requisitos para instalar o Apigee Hybrid.
   • Passo 1: ative as APIs
   • Passo 2: crie uma organização
   • Passo 3: crie um ambiente e um grupo de ambientes
2. Configuração do tempo de execução híbrido
   • Passo 1: crie um cluster
   • Passo 2: instale o cert-manager

Ferramentas

Além disso, tem de ter as seguintes ferramentas transferidas e configuradas na sua estação de trabalho:

• curl
• O docker é necessário para executar o script apigee-hybrid-setup.sh. Siga as instruções em Obter Docker para instalar o Docker.
• O comando envsubst deve estar disponível na maioria dos sistemas baseados em Linux/UNIX. Para o MacOS e outros sistemas, siga as instruções neste repositório.
• A app jq deve estar instalada. Transfira o jq.

• kpt Transferir kpt.

  Nota: as versões v0.39 e inferiores do KPT não são suportadas. Transfira o kpt a partir do link mencionado acima (v1.0+) para garantir que está a funcionar.

• kubectl versão 1.23 ou mais recente. Consulte o artigo Instalar ferramentas: kubectl na documentação do Kubernetes.

Variáveis comuns usadas neste guia

Este guia usa as seguintes variáveis de ambiente em vários passos. Pode defini-los na linha de comandos ou com um script, ou pode substituir o texto nos comandos quando os introduz.

• APIGEE_NAMESPACE: o seu espaço de nomes do Apigee. Por predefinição, esta opção é apigee. No entanto, pode usar um espaço de nomes diferente.
• CLUSTER_NAME: o nome do cluster onde está a instalar o Apigee Hybrid. Este é o cluster que cria no Passo 1: crie um cluster
• CLUSTER_LOCATION: a região do seu cluster. Os procedimentos neste guia pressupõem que está a usar um cluster regional. Se estiver a usar um cluster zonal, consulte as instruções no Passo 1: crie um cluster
• ENV_GROUP: o nome do grupo de ambientes para a sua instalação do Apigee Hybrid. Este é o grupo de ambientes que cria no Passo 3: crie um grupo de ambientes. Pode criar vários grupos de ambientes.
• ENV_NAME: o nome do grupo de ambientes para a sua instalação do Apigee Hybrid. Este é o grupo de ambientes que cria no Passo 3: crie um grupo de ambientes. Pode criar vários grupos de ambientes.
• INSTALL_DIR: o diretório onde instala o Apigee Hybrid. Por predefinição, este é o subdiretório apigee-hybrid-install/ do diretório onde transfere o instalador, por exemplo: /myhybrid/apigee-hybrid-install/. Este é o diretório de raiz da estrutura de ficheiros documentada em Estrutura de pastas de configuração do Apigee Hybrid.
• INSTANCE_DIR: o diretório de uma instância híbrida específica do Apigee. Por predefinição, a primeira instância tem o nome instance-1. O diretório da instância é um subdiretório de ${INSTALL_DIR}/overlays/instances/. Pode especificar qualquer nome para as suas instâncias híbridas. Consulte o artigo Instalação de várias instâncias.
• ORG_NAME: o nome da sua organização do Apigee Hybrid. Tem de ser igual ao ID do seu projeto do Google Cloud. Consulte: Passo 2: crie uma organização.

Instalação básica do Apigee Hybrid

Para instalar rapidamente o Apigee Hybrid sem personalização complexa, pode usar o seguinte procedimento de dois passos.

---

Nota: uma instalação básica tem a seguinte configuração:

• Um único ambiente
• Um único grupo de ambientes
• É criada e usada uma única conta de serviço do Google Cloud para todos os componentes individuais
• Valores predefinidos para todas as chaves de encriptação e palavras-passe.

---

1. Transfira ficheiros de configuração
2. Configuração de corrida

Transfira ficheiros de configuração

Transfira e prepare os ficheiros de configuração clonando o repositório do GitHub em https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1:

1. Clone o repositório:

   git clone https://github.com/apigee/apigee-hybrid-install.git
   

2. Navegue para o diretório do repositório clonado:

   cd apigee-hybrid-install
   

3. Crie uma ramificação a partir da etiqueta preview-1:

   git branch preview-1 preview-1
   git checkout preview-1
   

4. Torne o script de configuração executável:

   chmod +x ./tools/apigee-hybrid-setup.sh
   

   O repositório clonado tem uma estrutura semelhante à descrita em Estrutura de pastas de configuração do Apigee Hybrid:

Execute a configuração

Execute o script de shell apigee-hybrid-setup.sh localizado na pasta tools/.

./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION --org $ORG_NAME --setup-all

---

Nota: a execução do script com estes argumentos usa a organização, o ambiente e o grupo de ambientes do Apigee que criou em Pré-requisitos.

Se encontrar erros, experimente executar o script uma segunda vez.

---

Outras opções que pode querer usar:

• --env $ENV_NAME especifica o nome do ambiente do Apigee.
• --envgroup $ENV_GROUP especifica o grupo de ambientes.
• --ingress-domain $HOSTNAME especifica o nome do anfitrião que forneceu para o seu grupo de ambientes.
• --gcp-project-id $PROJECT_ID especifica o ID do seu projeto do Google Cloud.

Para mais opções, consulte o artigo Compreender o script.

Todos os erros durante a execução são impressos na saída padrão.

Quando o script for concluído com êxito, terá concluído a instalação híbrida básica. Pode testar a instalação criando um proxy de exemplo, conforme detalhado no artigo Crie e implemente um novo proxy de API.

Instalação personalizada do Apigee Hybrid

Para utilizadores mais avançados que pretendam um controlo detalhado sobre a instalação, podem seguir esta sequência de passos (para muitos dos passos indicados abaixo, pode optar por realizar o passo manualmente ou usar o script de shell para automatizar esse passo individual):

---

Nota: estes passos requerem uma compreensão básica dos conceitos do Kubernetes. Consulte a secção Conceitos ou a documentação do Kubernetes para ver mais detalhes.

---

Transfira ficheiros de configuração

Transfira e prepare os ficheiros de configuração:

1. Clone o repositório do GitHub em https://github.com/apigee/apigee-hybrid-install/

   O repositório clonado tem uma estrutura semelhante à descrita em Estrutura de pastas de configuração do Apigee Hybrid:

2. cd para o diretório apigee-hybrid-install/

3. Torne o script de configuração executável:

   chmod +x ./tools/apigee-hybrid-setup.sh
   

Crie um espaço de nomes

Crie um espaço de nomes do Kubernetes no seu cluster que contenha todos os componentes do cluster do Apigee.

kubectl create namespace apigee

---

Nota: Apigee é o nome predefinido para o espaço de nomes. Pode usar um nome diferente.

---

Se escolher outro nome para o espaço de nomes, pode optar por seguir uma das três opções abaixo:

• (Recomendado) Use --namespace={YOUR_NAMESPACE_NAME} ao pré-preencher valores em Editar YAMLs de recursos.

• Execute os dois comandos seguintes:

  1. Use kpt para especificar o espaço de nomes do 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 kpt
     

  2. Use sed para substituir o espaço de nomes em 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"
     

• Em alternativa, pode alterar manualmente os recursos individualmente para serem criados no espaço de nomes da sua escolha.

Usar imagens do Docker de repositórios privados (opcional)

Pode optar por não usar as imagens alojadas publicamente e usar imagens dos seus próprios repositórios privados:

1. O primeiro passo é enviar todas as imagens para o seu repositório privado. Para tal, siga os passos descritos em apigee-pull-push | Apigee X. Por predefinição, as imagens são etiquetadas com a versão do Apigee Hybrid à qual correspondem, e é recomendável que não edite estas etiquetas. Também recomendamos que não edite os nomes das imagens para que o caminho da imagem final possa ser construído conforme explicado no centro de imagens.

2. Defina o valor do campo imageHub presente no ficheiro apigee-hybrid-config.yaml para o caminho do anfitrião do repositório privado. (Consulte o centro de imagens para ver detalhes).

   imageHub: "your.private.repo/apigee/hybrid"
   

Isto garante que todos os componentes do Apigee hybrid usam as imagens do seu repositório privado.

Além disso, também pode querer usar uma imagem privada para o controlador e o gateway de entrada do Apigee. Para tal, tem de editar os ficheiros apigee-controller-deployment.yaml e apigee-ingressgateway-manager-deployment.yaml e substituir todos os campos image pela imagem do respetivo repositório privado.

---

Nota: se estiver a extrair imagens de um repositório privado, é muito provável que tenha de se autenticar para extrair essas imagens. As credenciais necessárias para esta autenticação são especificadas como imagePullSecrets, que foram abordadas detalhadamente em Configurar imagePullSecrets (opcional).

---

Configurar imagePullSecrets (opcional)

1. Crie um segredo do Kubernetes que contenha as credenciais para autenticação com os repositórios privados. Consulte o artigo Extraia uma imagem de um registo privado para compreender como o segredo tem de ser criado.
2. Depois de criar o segredo, só tem de fazer referência a esse segredo. Para tal, edite o ficheiro apigee-hybrid-config.yaml e defina o valor do campo imagePullSecret para o nome do segredo criado anteriormente e ative o componente imagePullSecret no ficheiro kustomization.yaml correspondente.

---

Nota: se também estiver a usar imagens privadas para o controlador, também pode ter de adicionar campos imagePullSecrets na especificação de implementação presente nos ficheiros apigee-controller-deployment.yaml e apigee-ingressgateway-manager-deployment.yaml.

Se especificar o imagePullSecrets em ambos os locais, o presente no ficheiro apigee-controller-manager.yaml tem prioridade.

---

Configurar proxy de encaminhamento (opcional)

Os proxies de encaminhamento podem ser configurados adicionando o campo forwardProxy ao ficheiro apigee-hybrid-config.yaml. Por exemplo:

  forwardProxy: |
    scheme: HTTP
    host: 10.12.0.47
    port: 3128

Especificar certificados TLS de entrada

Usar o script

./tools/apigee-hybrid-setup.sh --create-ingress-tls-certs

Consulte o artigo Compreender o script para ver mais detalhes acerca desta sinalização.

Manual

Tem de fornecer certificados TLS que vão ser usados para o gateway de entrada do Istio. Pode:

• Usar certificados assinados por uma autoridade conhecida através dos passos mencionados em Obtenha certificados TLS: um exemplo | Apigee X
• Ou gerar certificados autoassinados.

Aqui, vamos usar certificados autoassinados como exemplo. Os certificados autoassinados podem ser gerados através de (partindo do princípio de que DOMAIN foi definido corretamente e deve corresponder ao nome do anfitrião definido no seu grupo de ambiente):

openssl req -nodes -new -x509 -keyout ./tls.key -out ./tls.crt -subj '/CN='$DOMAIN'' -days 3650

Esta ação cria dois ficheiros com os nomes tls.key e tls.crt.

Em seguida, tem de criar um segredo com o seguinte formato. Pode usar kubectl create ou kubectl apply, conforme explicado em Usar um certificado/par de chaves personalizado para a autoridade de assinatura de certificados (opcional):

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}

---

Exemplo de criação do segredo com kubectl create:

kubectl create secret tls {ORG_NAME}-{ENV_GROUP_NAME} \
  --cert="tls.crt" \
  --key="tls.key" \
  -n {$APIGEE_NAMESPACE}

---

Nota: se alterar o nome do segredo acima, tem de fazer uma alteração correspondente em apigee-route-config.yaml alterando o valor de secretNameRef para YOUR_SECRET_NAME

---

Atualize a implementação de entrada

Para criar/modificar implementações de entrada, tem de modificar o campo spec.components.ingressGateways no recurso personalizado ApigeeOrganization em bases/initialization/crds/customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml.

Por predefinição, criamos uma implementação de entrada com parâmetros predefinidos(os valores predefinidos são apresentados nos documentos de referência de CR ):

ingressGateways:
- name: "prod-1"

Exemplos:

A. Substituir campos do serviço de entrada

ingressGateways:
- name: "prod-1"
  serviceSpec:
    annotations:
      {KEY}: ${VALUE}
    loadBalancerIP: ${IP}

B. Altere o número mínimo/máximo de réplicas

ingressGateways:
- name: "prod-1"
  ​​autoScaler:
    minReplicas: 4
    maxReplicas: 10

C. Adicionar nova implementação de entrada

ingressGateways:
- name: "prod-1"
- name: "prod-2"

Configurar contas de serviço personalizadas do Google Cloud

---

Nota: tem de configurar contas de serviço personalizadas do Google Cloud ou usar identidades de carga de trabalho)

---

Usar o script

./tools/apigee-hybrid-setup.sh --create-gcp-sa-and-secrets  --namespace APIGEE_NAMESPACE

Onde APIGEE_NAMESPACE é o seu espaço de nomes personalizado. O espaço de nomes predefinido é apigee.

Consulte o artigo Compreender o script para ver mais detalhes acerca das flags.

Manual

As chaves da conta de serviço do Google Cloud têm de ser armazenadas como segredos no cluster. O YAML secreto deve ter a seguinte estrutura:

apiVersion: v1
kind: Secret
metadata:
  name: "{NAME}"
  namespace: {APIGEE_NAMESPACE}
type: Opaque
data:
  client_secret.json: |
    {BASE64_ENCODED_SA_KEY}

Para mais detalhes sobre todas as contas de serviço necessárias e os nomes dos segredos, consulte a secção Contas de serviço do Google Cloud.

Pode escolher um nome diferente para os segredos, mas, em seguida, tem de fazer uma alteração correspondente no componente onde esse nome secreto foi usado. Por exemplo, se decidir alterar o nome do segredo da conta de serviço de tempo de execução de apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME} para my-runtime-svc, tem de fazer uma alteração correspondente no apigee-environment.yaml para esse ambiente

---

Nota: os segredos que contêm as chaves da conta de serviço podem ser obtidos a partir de ferramentas de gestão de segredos externas, como o Vault. Consulte a secção Armazenar chaves de contas de serviço em cofres externos para ver detalhes sobre como o fazer.

---

Usar identidades de carga de trabalho

---

Nota: as identidades de carga de trabalho só podem ser usadas com clusters do GKE no Google Cloud.

Uma das opções Configurar contas de serviço do Google Cloud personalizadas ou Usar identidades de carga de trabalho é obrigatória.

---

Pré-requisitos

Antes de usar identidades de cargas de trabalho, certifique-se de que o seu cluster do GKE tem o suporte ativado. Consulte o artigo Atualizar node pools | Apigee X para ver detalhes.

Ativar o Workload Identity

Consulte a secção Identidades de carga de trabalho em Kustomize e componentes para ver detalhes sobre como pode ativar as identidades de carga de trabalho antes da instalação.

Edite ficheiros YAML de recursos

Alguns locais nos ficheiros YAML dos componentes requerem a presença dos nomes corretos da organização, do ambiente e do grupo de ambientes. Pode definir estes valores manualmente ou usar o script de shell para preencher automaticamente estes valores.

Usar o script

./tools/apigee-hybrid-setup.sh --fill-values

Crie recursos de inicialização e um controlador

#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

Conceda autorizações à conta de serviço do sincronizador para interagir com o plano de controlo

Siga os passos no Passo 8: ative o acesso do sincronizador, substituindo o nome da conta de serviço, apigee-non-prod ou apigee-synchronizer, por apigee-all-sa, o nome da conta de serviço criada pelo novo processo de instalação.

---

★ Importante: certifique-se de que altera o nome da conta de serviço nas instruções em Ative o acesso do sincronizador. Caso contrário, a ativação do acesso para o sincronizador falha.

---

Crie componentes do plano de dados do Apigee

Se tiver alterado os nomes de algum dos recursos nos passos anteriores, tem de fazer uma alteração correspondente noutros ficheiros YAML onde esse recurso foi referenciado. Quando terminar, use os comandos no seguinte exemplo:

# Create the rest of the resources.
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}

para instalar todos os componentes.

Aguarde que os recursos sejam iniciados

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

Personalize a instalação do cert-manager num espaço de nomes personalizado

Personalize o espaço de nomes onde o cert-manager está a ser executado com o seguinte procedimento.

Se o cert-manager estiver instalado no cluster num espaço de nomes diferente de cert-manager, tem de atualizar o espaço de nomes usado para criar o certificado de raiz do Apigee.

1. Edite o ficheiro customization.yaml para a criação de certificados: $INSTALL_DIR/overlays/initialization/certificates/kustomize.yaml

2. Adicione o seguinte ao final do ficheiro.

   - patch: |-
   - op: replace
     path: /metadata/namespace
     value: "gk-cert-manager"
   target:
   group: cert-manager.io
   version: v1
   kind: Certificate
   name: apigee-root-certificate
   

3. Guarde o ficheiro

Kustomize e componentes

Vista geral

A nova instalação híbrida herda a ideologia do Kustomize de estruturar ficheiros YAML sob a forma de bases e sobreposições

• As bases são ficheiros fornecidos pela Apigee, que podem mudar entre cada novo lançamento do Hybrid. Não deve modificar estes ficheiros. Estes ficheiros contêm alguns valores predefinidos fornecidos pelo Apigee. Todos os ficheiros na pasta bases/ de nível superior contêm estas bases

• As sobreposições contêm a configuração do utilizador e servem como meio através do qual pode modificar os valores predefinidos especificados nas bases. Todos os ficheiros na pasta overlays/ de nível superior contêm estas sobreposições

  ---

  Nota: para compreender melhor o Kustomize e como as sobreposições foram usadas para modificar bases, recomendamos vivamente que consulte o artigo Patches do Kustomize.

  ---

Como usar os componentes

As subpastas no diretório de nível superior overlays/ foram estruturadas de forma que pode ativar (ou desativar) uma determinada funcionalidade adicional comentando (ou descomentando) determinadas linhas nos ficheiros kustomization.yaml.

Por exemplo, é assim que se apresenta a estrutura de pastas 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

Veja como os ficheiros telemetry/kustomization.yaml provavelmente seriam apresentados por predefinição:

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

Podemos ver que a linha ./components/logger foi comentada, o que significa simplesmente que não ativámos o registador do Google Cloud por predefinição. Para o ativar, basta remover o comentário dessa linha da seguinte forma:

components:

- ./components/logger

Da mesma forma, para desativar métricas, pode comentar a linha ./components/metrics:

...
components:
...
# - ./components/metrics
…

As secções seguintes abordam todos estes componentes diferentes, quando podem ser usados e como podem ser configurados.

OpenShift

Para os utilizadores que pretendem instalar o Apigee Hybrid num cluster OpenShift, pode ter de ativar alguns componentes/recursos antes de realizar a instalação. (Isto é necessário se não usar o script para fazer a instalação). Os ficheiros que têm de ser modificados são:

• overlays/initialization/openshift/kustomization.yaml . Na secção resources:, descomente:

  # - ../../../bases/initialization/openshift/
  

• overlays/instances/{INSTANCE_NAME}/datastore/kustomization.yaml Descomentar:

  # - ./components/openshift-scc
  

  e descomente o campo "components:" se ainda estiver comentado.

• overlays/instances/{INSTANCE_NAME}/telemetry/kustomization.yaml Descomentar:

  # - ./components/openshift-scc
  

  e descomente o campo "components:" se ainda estiver comentado.

Em seguida, pode avançar com os passos de instalação.

imagepullsecret

Este componente pode ser ativado quando tiver imagens armazenadas no seu repositório privado. Para extrair imagens de um repositório privado, pode criar um segredo do Kubernetes que tenha os seus detalhes de autenticação e, em seguida, referenciar este segredo no interior. Consulte o artigo Configurar imagePullSecrets (opcional) para obter instruções. Consulte o artigo Extrair uma imagem de um registo privado | Kubernetes na documentação do Kubernetes para mais informações.

Disponível nos seguintes países:

• overlays/controllers/apigee-controller
• overlays/controllers/istiod
• overlays/instances/{INSTANCE_NAME}/datastore
• overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
• overlays/instances/{INSTANCE_NAME}/organization
• overlays/instances/{INSTANCE_NAME}/redis
• overlays/instances/{INSTANCE_NAME}/telemetry

Ativação:

Descomente a linha "./components/imagepullsecret/" nos ficheiros kustomization.yaml respetivos sempre que necessário.

Modificações a serem feitas:

• components/imagepullsecret/patch.yaml
  • OBRIGATÓRIO Adicione nomes de segredos relevantes à lista em spec.template.spec.imagePullSecrets

Utilização:

1. Se ainda não instalou o Apigee Hybrid, pode continuar com os passos de instalação e estas alterações são aplicadas no processo

2. Se já tiver o Apigee Hybrid instalado, tem de aplicar estas novas alterações através do seguinte:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

nodeselector

Este componente permite-lhe agendar pods para um recurso do Apigee em nós específicos. Consulte o artigo Atribuir pods a nós | Kubernetes para ver informações adicionais.

Disponível nos seguintes países:

• overlays/controllers/apigee-controller
• overlays/controllers/istiod
• overlays/instances/{INSTANCE_NAME}/datastore
• overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
• overlays/instances/{INSTANCE_NAME}/organization
• overlays/instances/{INSTANCE_NAME}/redis
• overlays/instances/{INSTANCE_NAME}/telemetry

Ativação:

Descomente a linha "./components/nodeselector" nos ficheiros kustomization.yaml respetivos sempre que necessário.

Modificações a serem feitas:

• components/nodeselector/patch.yaml
  • OPCIONAL Altere o valor da etiqueta do seletor de nós de apigee-runtime ou apigee-data para o desejado.

Utilização:

1. Se ainda não instalou o Apigee Hybrid, pode continuar com os passos de instalação e estas alterações são aplicadas no processo

2. Se já tiver o Apigee Hybrid instalado, tem de aplicar estas novas alterações através do seguinte:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

workload-identity

Vários contentores no ecossistema híbrido do Apigee requerem autorizações para fazer determinadas chamadas API para o plano de controlo / plano de gestão do Apigee. A identidade de carga de trabalho é uma das formas de conceder estas autorizações aos pods (e aos contentores no interior). Seguem-se alguns recursos úteis para ler mais sobre este assunto: - Apresentamos o Workload Identity: melhor autenticação para as suas aplicações do GKE | Blogue do Google Cloud - Use o Workload Identity | Documentação do Kubernetes Engine | Google Cloud

Disponível nos seguintes países:

• overlays/instances/{INSTANCE_NAME}/datastore
• overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
• overlays/instances/{INSTANCE_NAME}/organization
• overlays/instances/{INSTANCE_NAME}/redis
• overlays/instances/{INSTANCE_NAME}/telemetry

Pré-requisito:

Antes de poder usar a identidade da carga de trabalho, tem de conceder as autorizações relevantes no seu projeto do Google Cloud através do seguinte comando:

    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

onde: - ${ORG_NAME} - O nome da sua organização do Apigee. - ${APIGEE_NAMESPACE} – O espaço de nomes do Kubernetes onde os componentes do Apigee foram instalados. Normalmente, é apigee, a menos que o utilizador o altere explicitamente durante a instalação - ${KSA_NAME} - O nome do espaço de nomes do Kubernetes. Tem de executar este comando para cada conta de serviço do Kubernetes mencionada em Contas de serviço do Kubernetes - ${GSA_NAME} - O nome da conta de serviço do Google Cloud. Se não tiver feito alterações durante a instalação, este parâmetro tem o valor apigee-all-sa. Se configurar várias contas de serviço do Google Cloud para componentes individuais, tem de fazer corresponder o KSA_NAME ao GSA_NAME correspondente. Pode comparar as tabelas em contas de serviço do Google Cloud com contas de serviço do Kubernetes para encontrar os equivalentes.

Ativação:

Descomente a linha ./components/workload-identity nos ficheiros kustomization.yaml respetivos sempre que necessário. Tenha em atenção que, na telemetria, temos suplementos de identidade de carga de trabalho separados para os componentes metrics e logger, que podem ser ativados individualmente.

Utilização:

1. Se ainda não instalou o modo híbrido, pode simplesmente ativar a workload-identity, conforme mencionado na secção anterior, e continuar com a instalação, que irá usar automaticamente a workload-identity.

2. Se já tiver o Apigee Hybrid instalado, tem de aplicar estas novas alterações através do seguinte:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

http-proxy

Pode configurar um servidor proxy em cada um dos seguintes componentes para que o tráfego desse componente passe pelo proxy HTTP configurado para esse componente. Pode configurar o proxy para cada componente do Apigee individualmente.

Disponível nos seguintes países:

• overlays/instances/{INSTANCE_NAME}/datastore
• overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
• overlays/instances/{INSTANCE_NAME}/organization
• overlays/instances/{INSTANCE_NAME}/telemetry

Ativação:

Descomente a linha "./components/http-proxy/" nos ficheiros kustomization.yaml respetivos sempre que necessário.

Modificações a serem feitas:

• components/http-proxy/patch.yaml Pode configurar os seguintes parâmetros em spec.httpForwardProxy
  • scheme: OBRIGATÓRIO Um de HTTP ou HTTPS
  • host: OBRIGATÓRIO O endereço do anfitrião do seu proxy
  • port: OBRIGATÓRIO O número da porta
  • username: OPCIONAL O nome de utilizador associado ao seu proxy
  • password: OPCIONAL A palavra-passe para aceder ao proxy

Utilização:

1. Se ainda não instalou o Apigee Hybrid, pode continuar com os passos de instalação e estas alterações são aplicadas no processo

2. Se já tiver o Apigee Hybrid instalado, tem de aplicar estas novas alterações através do seguinte:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

logger e métricas

Pode ativar ou desativar individualmente o registador ou as métricas em overlays/instances/{INSTANCE_NAME}/telemetry. Por predefinição, o registador está desativado e as métricas estão ativadas. Para ativá-las ou desativá-las, basta remover ou adicionar o comentário às respetivas linhas no ficheiro telemetry/kustomization.yaml

gcs-backup e gcs-restore

Este componente do Kustomize pode ser usado para fazer uma cópia de segurança e restaurar a base de dados Cassandra no Google Cloud Storage.

Disponível nos seguintes países:

• overlays/instances/{INSTANCE_NAME}/datastore

Pré-requisito:

1. Transfira as chaves das contas de serviço do Google Cloud para uma conta que tenha a função de administrador de objetos de armazenamento.

   • Se usou o script para fazer a instalação e não usou identidades de carga de trabalho, pode reutilizar as chaves transferidas disponíveis na pasta service-accounts criada pelo script.

   • Também pode usar o script create-service-account.sh para criar uma nova conta de serviço e transferir as respetivas chaves:

     ./tools/create-service-accounts=.sh --env prod --profile apigee‑cassandra
     

2. Depois de transferir as chaves, tem de criar um segredo do Kubernetes com o nome apigee-cassandra-backup-and-restore-gcp-sa-key, o que pode fazer através do comando:

   kubectl create secret generic "apigee-cassandra-backup-and-restore-gcp-sa-key" \
             --from-file="dbbackup_key.json=${PATH_TO_SA_KEY}" \
             -n "${APIGEE_NAMESPACE}"
   

   Onde:

   • ${PATH_TO_SA_KEY} - Caminho para o ficheiro que contém as chaves da conta de serviço.
   • ${APIGEE_NAMESPACE}: o espaço de nomes do Kubernetes onde os componentes do Apigee foram instalados. Normalmente, este é o valor de apigee, a menos que tenha sido alterado explicitamente durante a instalação

Em alternativa, pode usar os modelos de ficheiros templates/secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml para criar este segredo.

Ativação:

• Se quiser ativar a cópia de segurança, descomente a linha "./components/gcs-backup" no ficheiro datastore kustomization.yaml.
• Se quiser restaurar uma cópia de segurança, descomente a linha "./components/gcs-restore" no ficheiro datastore kustomization.yaml.

Modificações apenas para cópia de segurança

• components/gcs-backup/apigee-datastore-patch.yaml
  • OBRIGATÓRIO: altere o valor da variável de ambiente DATABASE_STORAGE_BUCKET, que terá o formato gs://BUCKET_NAME e aponta para o contentor do Google Cloud Storage onde os dados têm de ser copiados. A descrição corresponde a dbStorageBucket descrito aqui.
• components/gcs-backup/cron-patch.yaml
  • OBRIGATÓRIO Altere spec.schedule para especificar a frequência da cópia de segurança. O campo aceita o formato de agendamento Crontab padrão. A descrição corresponde à programação descrita aqui.
  • OBRIGATÓRIO: altere o valor da variável de ambiente DATABASE_STORAGE_BUCKET, que terá o formato gs://BUCKET_NAME e aponta para o contentor do Google Cloud Storage onde os dados têm de ser copiados. A descrição corresponde a dbStorageBucket descrito aqui.
  • OPCIONAL Altere o valor de HTTP_PROXY_URL para apontar para qualquer proxy configurado. O formato pode ser o seguinte:
    • 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}

A fazer cópia de segurança

Pode fazer a cópia de segurança com o seguinte comando:

kubectl apply -k overlays/instances/{INSTANCE_NAME}

Para aplicar as alterações e ativar a cópia de segurança:

Modificações apenas para restauro

• components/gcs-restore/apigee-datastore-patch.yaml
  • OBRIGATÓRIO: altere o valor da variável de ambiente DATABASE_STORAGE_BUCKET, que terá o formato gs://BUCKET_NAME e aponta para o contentor do Google Cloud Storage onde os dados têm de ser copiados. A descrição corresponde a dbStorageBucket, descrito aqui.
• components/gcs-restore/job-patch.yaml
  • OBRIGATÓRIO: altere o valor da variável de ambiente DATABASE_STORAGE_BUCKET, que terá o formato gs://BUCKET_NAME e aponta para o contentor do Google Cloud Storage onde os dados têm de ser copiados.
  • OBRIGATÓRIO Altere o valor da variável de ambiente BACKUP_SNAPSHOT_TIMESTAMP. A descrição corresponde a restore:snapshotTimestamp descrito aqui.
  • OPCIONAL Altere o valor de HTTP_PROXY_URL para apontar para qualquer proxy configurado. O formato pode ser o seguinte:
    • 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}

Realizar o restauro:

Para informações gerais sobre o restauro de cópias de segurança, consulte o artigo Restaurar cópias de segurança | Apigee X | Google Cloud

1. Crie um novo cluster do Kubernetes com um novo espaço de nomes no qual restaurar a implementação do tempo de execução híbrido. Não pode usar o mesmo cluster e espaço de nomes que usou para a instalação híbrida original.

2. Instale o Hybrid no novo cluster com as definições configuradas acima, além de quaisquer outras definições que pretender:

   • Pode usar a instalação básica e instalar o híbrido no novo espaço de nomes:

   ./tools/apigee-hybrid-setup.sh \
   --cluster-name $CLUSTER_NAME \
   --cluster-region $CLUSTER_LOCATION \
   --namespace ${NEW_APIGEE_NAMESPACE}
   

   • Em alternativa, siga a instalação personalizada do Apigee Hybrid para configurar as opções à sua escolha.

3. Assim que a restauração estiver concluída, todos os recursos no espaço de nomes antigo podem ser eliminados e mudados para o novo espaço de nomes.

Para mais informações, consulte o artigo Restaurar cópias de segurança.

non-gcs-backup e non-gcs-restore

Este componente do Kustomize pode ser usado para fazer uma cópia de segurança e restaurar a base de dados Cassandra no Google Cloud Storage.

Disponível nos seguintes países:

• overlays/instances/{INSTANCE_NAME}/datastore

Pré-requisito:

1. Pode usar os passos da documentação já existente para configurar o servidor e o SSH.

2. Nos passos acima, tem de usar a chave privada SSH que está disponível no ficheiro "ssh_key" gerado seguindo os passos anteriores. Em seguida, criamos um segredo do Kubernetes com o nome apigee-cassandra-backup-and-restore-gcp-sa-key, que contém esta chave privada SSH.

   ---

   Nota: certifique-se de que o ficheiro da chave privada SSH tem uma nova linha no final.

   ---

   O segredo do Kubernetes pode ser criado através do seguinte comando:

   kubectl create secret generic "apigee-cassandra-backup-and-restore-key-file" \
           --from-file="key=${PATH_TO_SSH_PRIVATE_KEY}" \
           -n "${APIGEE_NAMESPACE}"
   

   Onde:

   • ${PATH_TO_SSH_PRIVATE_KEY} - Caminho para o ficheiro que contém a chave privada de SSH
   • ${APIGEE_NAMESPACE}: o namespace do Kubernetes onde os componentes do Apigee foram instalados. Normalmente, este é o valor de apigee, a menos que tenha sido alterado explicitamente durante a instalação

   Em alternativa, pode usar o ficheiro de modelo templates/secret-apigee-cassandra-backup-and-restore-key-file.yaml para criar este segredo.

Ativação:

• Se quiser ativar a cópia de segurança, descomente a linha "./components/non-gcs-backup" no ficheiro datastore kustomization.yaml.
• Se quiser restaurar uma cópia de segurança, descomente a linha "./components/non-gcs-restore" no ficheiro datastore kustomization.yaml.

Modificações apenas para cópia de segurança

• components/non-gcs-backup/apigee-datastore-patch.yaml
  • OBRIGATÓRIO Altere o valor de BACKUP_SERVER_IP. A descrição corresponde ao BACKUP_SERVER_IP descrito aqui.
  • OBRIGATÓRIO Altere o valor de BACKUP_STORAGE_DIR. A descrição corresponde a BACKUP_STORAGE_DIR descrito aqui.
• components/non-gcs-backup/cron-patch.yaml
  • OBRIGATÓRIO Altere spec.schedule para especificar a frequência da cópia de segurança. O campo aceita o formato de agendamento Crontab padrão. A descrição corresponde à programação descrita aqui.
  • OBRIGATÓRIO Altere o valor de BACKUP_SERVER_IP. A descrição corresponde ao BACKUP_SERVER_IP descrito aqui.
  • OBRIGATÓRIO Altere o valor de BACKUP_STORAGE_DIR. A descrição corresponde a BACKUP_STORAGE_DIR descrito aqui.
  • OPCIONAL Altere o valor de HTTP_PROXY_URL para apontar para qualquer proxy configurado. O formato pode ser o seguinte:
    • 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}

A fazer cópia de segurança

Pode fazer a cópia de segurança com o seguinte comando:

kubectl apply -k overlays/instances/{INSTANCE_NAME}

Para aplicar as alterações e ativar a cópia de segurança:

Modificações apenas para cópia de segurança

• components/non-gcs-restore/apigee-datastore-patch.yaml
  • REQUIRED Altere o valor de BACKUP_SERVER_IP. A descrição corresponde ao BACKUP_SERVER_IP descrito aqui.
  • OBRIGATÓRIO Altere o valor de BACKUP_STORAGE_DIR. A descrição corresponde ao BACKUP_STORAGE_DIR descrito aqui.
• components/non-gcs-restore/job-patch.yaml
  • OBRIGATÓRIO: altere o valor da variável de ambiente BACKUP_SNAPSHOT_TIMESTAMP. A descrição corresponde ao restore:snapshotTimestamp descrito aqui.
  • REQUIRED Altere o valor de BACKUP_SERVER_IP. A descrição corresponde ao BACKUP_SERVER_IP descrito aqui.
  • REQUIRED Altere o valor de BACKUP_STORAGE_DIR. A descrição corresponde ao BACKUP_STORAGE_DIR descrito aqui.
  • OPCIONAL Altere o valor de HTTP_PROXY_URL para apontar para qualquer proxy configurado. O formato pode ser o seguinte:
    • 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}

Realizar o restauro:

Para uma vista geral sobre o restauro de cópias de segurança, consulte o artigo Vista geral do restauro do Cassandra.

1. Crie um novo cluster do Kubernetes com um novo espaço de nomes no qual restaurar a implementação do tempo de execução híbrido. Não pode usar o mesmo cluster e espaço de nomes que usou para a instalação híbrida original.

2. Instale o Hybrid no novo cluster com as definições configuradas acima, além de quaisquer outras definições que pretender: Pode usar a instalação básica e instalar o Hybrid no novo espaço de nomes:

   ./tools/apigee-hybrid-setup.sh \
     --cluster-name $CLUSTER_NAME \
     --cluster-region $CLUSTER_LOCATION \
     --namespace ${NEW_APIGEE_NAMESPACE}
   

   Em alternativa, siga a instalação personalizada do Apigee Hybrid para configurar as opções à sua escolha.

3. Assim que a restauração estiver concluída, todos os recursos no espaço de nomes antigo podem ser eliminados e mudados para o novo espaço de nomes.

   Para mais informações, consulte o artigo Programar cópias de segurança num servidor remoto.

http-client

Para ver instruções, consulte o artigo Ative clientes HTTP | Apigee.

Disponível nos seguintes países:

• overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}

Ativação:

Descomente a linha "./components/http-client" no ficheiro route-config/${ENV_GROUP}/kustomization.yaml respetivo

Modificações a serem feitas:

• Não são necessárias modificações obrigatórias.

Utilização:

1. Se ainda não instalou o Apigee Hybrid, pode continuar com os passos de instalação e estas alterações são aplicadas no processo

2. Se já tiver o Apigee Hybrid instalado, tem de aplicar estas novas alterações através do seguinte:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

non-sni-client

Equivalente ao artigo já existente Como configurar um cliente não SNI | Apigee.

Disponível nos seguintes países:

• overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}

Ativação:

Descomente a linha "./components/non-sni-client" no ficheiro route-config/${ENV_GROUP}/kustomization.yaml respetivo

Modificações a serem feitas:

• components/non-sni-client/apigee-route.yaml
  • OBRIGATÓRIO credentialName A descrição corresponde ao credential_name descrito aqui.

Utilização:

1. Se ainda não instalou o Apigee Hybrid, pode continuar com os passos de instalação e estas alterações são aplicadas no processo

2. Se já tiver o Apigee Hybrid instalado, tem de aplicar estas novas alterações através do seguinte:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

http-and-non-sni-client

Para ver instruções, consulte o artigo Ative o suporte para clientes HTTP e não SNI | Apigee.

Ativação:

Descomente a linha "./components/http-and-non-sni-client" no ficheiro route-config/${ENV_GROUP}/kustomization.yaml respetivo

Modificações a serem feitas:

• components/http-and-non-sni-client/apigee-route.yaml
  • OBRIGATÓRIO credentialName A descrição corresponde ao credential_name descrito aqui.

Utilização:

1. Se ainda não instalou o Apigee Hybrid, pode continuar com os passos de instalação e estas alterações são aplicadas no processo

2. Se já tiver o Apigee Hybrid instalado, tem de aplicar estas novas alterações através do seguinte:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

multirregião

Este componente pode ser usado ao configurar uma implementação do Cassandra em várias regiões. Para mais informações, consulte o artigo Implementação em várias regiões no GKE e GKE on-prem

Ativação:

Descomente a linha "./components/multi-region" no ficheiro datastore/kustomization.yaml

Modificações a serem feitas:

• components/multi-region/cassandra-data-replication.yaml

  • OBRIGATÓRIO source.region O nome do centro de dados do Cassandra de origem que vai ser usado para replicar dados. Pode ser identificado através do seguinte comando no cluster de origem:

  kubectl get apigeedatastore -n ${APIGEE_NAMESPACE} -o=jsonpath='{.items[*].spec.components.cassandra.properties.datacenter}'
  

• components/multi-region/patch.yaml

  • OBRIGATÓRIO spec.components.properties.multiRegionSeedHost O IP do agrupamento de qualquer um dos agrupamentos cassandra de origem. Podemos usar:

  kubectl get pods -n ${APIGEE_NAMESPACE} -o wide
  

  • Para apresentar uma lista de todos os pods e obter o IP de qualquer pod do Cassandra, use o seguinte comando:

  kubectl get pods -o wide -n apigee
  

  O resultado deve ter um aspeto semelhante ao seguinte:

  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
  

Para mais informações, consulte os pré-requisitos para o GKE em "Implementação em várias regiões no GKE, GKE on-prem e AKS":

Utilização:

A utilização deste componente faz sentido principalmente quando está a configurar o Apigee Hybrid num novo cluster e já tem outra configuração funcional do Apigee Hybrid.

1. O novo cluster e o cluster existente têm de usar os mesmos certificados TLS para garantir a comunicação adequada entre os pods do Cassandra. Por isso, temos de copiar o segredo apigee-root-certificate do cluster existente e usá-lo também no mais recente:

2. Corrida:

   kubectl config get-contexts
   

   • Para obter uma lista de todos os contextos do Kubernetes e, em seguida, executar

   kubectl config use-context SOURCE_CLUSTER_CONTEXT
   

   em que SOURCE_CLUSTER_CONTEXT é o nome do contexto do cluster do Kubernetes de origem.

3. Armazene o Secret do certificado de raiz num ficheiro:

   kubectl get secret/apigee-root-certificate -n cert-manager -o yaml > apigee-root-certificate.yaml
   

4. Mude o contexto do cluster para o novo cluster onde está a instalar o Apigee Hybrid.

   kubectl config use-context ${NEW_CLUSTER_CONTEXT}
   

5. Crie o segredo principal no novo cluster:

   kubectl -n cert-manager apply -f apigee-root-certificate.yaml
   

6. Desative a criação de um novo certificado de raiz. Isto garante que não criamos um novo apigee-root-certificate e acabamos por substituir o que criámos no passo anterior.

7. Descomente as seguintes linhas no ficheiro overlays/initialization/certificates/kustomization.yaml:

   # components:
   # - ./components/disable-apigee-root-certificate-generation
   

8. Continue com o resto da instalação do Apigee Hybrid através da instalação básica do Apigee Hybrid ou da instalação personalizada do Apigee Hybrid. Por exemplo, após a instalação híbrida básica do Apigee, pode executar:

   ./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION
   

9. Valide o estado da reconstrução através do seguinte comando.

   ---

   Nota: a operação de reconstrução pode demorar várias horas, consoante o tamanho dos dados.

   ---

   kubectl -n ${APIGEE_NAMESPACE} get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
   

10. Valide os processos de reconstrução a partir dos registos. Além disso, verifique o tamanho dos dados através do comando nodetool status:

    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
    

11. Valide o estado da reconstrução através do seguinte comando.

    ---

    Nota: a operação de reconstrução pode demorar várias horas, consoante o tamanho dos dados.

    ---

    kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
    

    Os resultados devem ter um aspeto semelhante ao seguinte:

    {
    "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
    }
    

    Veja também: Implementação em várias regiões.

12. Remover as seguintes linhas de components/multi-region/patch.yaml:

      properties:
        multiRegionSeedHost: {IP_ADDRESS} # To be modified. REQUIRED
    

13. Aplique as alterações:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}
    

Conceitos

Image Hub

Geralmente, as imagens de contentores do Docker são especificadas no formato:

${REGISTRY_HOST_PATH}/${IMAGE_NAME}:${IMAGE_TAG}

ou que usam um resumo, como:

${REGISTRY_HOST_PATH}/${IMAGE_NAME}@${DIGEST}

O Apigee usa o conceito de "Image Hub", que nos formatos acima se refere a ${REGISTRY_HOST_PATH}. O valor predefinido do hub de imagens é gcr.io/apigee-release/hybrid/.

(As imagens que usam o DIGEST têm de ser definidas individualmente em cada subcomponente)

O Apigee cria o caminho da imagem final combinando o valor do seguinte:

• "Image Hub", que pode ser substituído em apigee-hybrid-config.yaml (consulte a secção Usar imagens do Docker de repositórios privados para ver passos detalhados sobre como substituir o Image Hub).
• O valor de IMAGE_TAG é obtido a partir do campo version, que está presente no ficheiro YAML para cada um dos componentes individuais (por exemplo, apigee-organization.yaml). O Apigee etiqueta as imagens com a versão do Apigee Hybrid, o que significa que IMAGE_TAG é 1.8 para a versão 1.8 do Apigee Hybrid
• IMAGE_NAME é determinado implicitamente a partir do nome do contentor onde a imagem vai ser usada. Por exemplo, para o contentor apigee-runtime, o IMAGE_NAME é apigee-runtime.

Assim, um exemplo completo de um caminho de imagem seria gcr.io/apigee-release/hybrid/apigee-runtime:1.8.0

Desta forma, é construído o caminho da imagem final, que seria usado em cada um dos contentores nos respetivos pods.

Contas de serviço do Google Cloud

As contas de serviço do Google Cloud são contas usadas pelas aplicações para fazer chamadas autorizadas para APIs Google. As chaves da conta de serviço do Google Cloud podem ser transferidas e, em seguida, usadas para fins de autenticação. O Apigee espera que o utilizador forneça chaves de contas de serviço através da criação de segredos. Seguem-se os nomes dos componentes e o nome predefinido do segredo onde procura chaves de contas de serviço:

Componente	Subcomponente	Nome do segredo do Kubernetes predefinido que contém a chave da conta de serviço
organização
	connectAgent	apigee-connect-agent-gcp-sa-key-${ORG_NAME}
	observador	apigee-watcher-gcp-sa-key-${ORG_NAME}
	mart	apigee-mart-gcp-sa-key-${ORG_NAME}
	udca	apigee-udca-gcp-sa-key-${ORG_NAME}
	ingressGateways	N/A
ambiente
	tempo de execução	apigee-runtime-gcp-sa-key-${ORG_NAME}-${ENV_NAME}
	udca	apigee-udca-gcp-sa-key-${ORG_NAME}-${ENV_NAME}
	sincronizador	apigee-synchronizer-gcp-sa-key-${ORG_NAME}-${ENV_NAME}
telemetry
	métricas	apigee-metrics-gcp-sa-key
	containerLogs	apigee-logger-gcp-sa-key

Contas de serviço do Kubernetes

As contas de serviço do Kubernetes fornecem identidades aos pods no seu cluster. Por predefinição, o controlador do Apigee cria-os por si. No entanto, se quiser substituir a criação (por exemplo, quando estiver a usar identidades de carga de trabalho), pode fazê-lo especificando o campo podServiceAccountName nos vários subcomponentes.

Lista de componentes e respetivos subcomponentes onde a conta de serviço do Kubernetes pode ser especificada juntamente com o nome predefinido da conta de serviço do k8s quando ativa a correção da identidade da carga de trabalho para os mesmos.

Componente	Subcomponente	Nome predefinido (disponível quando ativou a correção do Workload Identity)
organização
	connectAgent	apigee-connect-agent-svc-account-${ORG_NAME}
	observador	apigee-watcher-svc-account-${ORG_NAME}
	mart	apigee-mart-svc-account-${ORG_NAME}
	udca	apigee-udca-svc-account-${ORG_NAME}
ambiente
	sincronizador	apigee-synchronizer-svc-account-${ORG_NAME}-${ENV_NAME}
	udca	apigee-udca-svc-account-${ORG_NAME}-${ENV_NAME}
	tempo de execução	apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME}
datastore
	cassandra	apigee-datastore-svc-account
telemetry
	metricsApp	apigee-metricsApp-svc-account
	metricsProxy	apigee-metricsProxy-svc-account
	metricsAdapter	apigee-metricsAdapter-svc-account
	containerLogs	apigee-container-logs-svc-account

Identidades de carga de trabalho

As identidades de cargas de trabalho permitem que os pods (que usam contas de serviço do Kubernetes) em execução no GKE façam a autenticação diretamente com as APIs Google Cloud sem necessitarem de chaves de contas de serviço do Google Cloud.

Adicionar um novo ambiente

.
├── ...
├── instances/instance1/components
│   ├── ...
│   ├── environments
│   │   ├── dev
│   │   │   └── apigee-environment.yaml
│   │   │   └── secrets.yaml
│   │   └── new-env-name (new)
│   │       └── apigee-environment.yaml (new)
│   │       └── secrets.yaml (new)
└── ...

Adicionar um novo ambiente é tão simples como:

1. Criar uma nova pasta no diretório environments (ou na estrutura de pastas que tiver definido)
2. Copiar o ficheiro apigee-environment.yaml de qualquer ambiente existente para a nova pasta.
3. Se quiser criar uma nova conta de serviço e chaves de encriptação para o novo ambiente, copie o ficheiro secrets.yaml para a nova pasta e mude o nome dos segredos adequadamente para os distinguir dos outros ambientes existentes (normalmente, isto é feito adicionando o nome do ambiente como um sufixo)
4. Fazer as alterações adequadas ao apigee-environment.yaml, como:
   • Alterar o nome do ambiente
   • Se forem criadas novas contas de serviço e chaves de encriptação, estas têm de ser corretamente referenciadas no YAML.
5. Aplicar os yamls:

kubectl apply -f components/environments/new-env-name/secrets.yaml
kubectl apply -f components/environments/new-env-name/apigee-environment.yaml

Usar a eliminação forçada no Apigee Datastore

Se a eliminação do repositório de dados não estiver a progredir por qualquer motivo, agora, o repositório de dados do Apigee pode ser eliminado à força através dos seguintes comandos, independentemente do estado atual do cluster.

---

Nota: a utilização da eliminação forçada também elimina os PVCs. Assim, se a implementação atual do Apigee Hybrid for de motivo único, faça uma cópia de segurança antes de continuar.

---

---

Nota: a utilização da eliminação forçada em clusters de várias regiões requer uma limpeza manual noutras regiões após a conclusão da eliminação do Datastore para manter o Cassandra em bom estado. Consulte o guia de resolução de problemas para saber como fazer a limpeza manual.

---

1. Elimine apigeeds no espaço de nomes apigee:

   Kubectl delete -n apigee apigeeds default
   

   Se este passo ficar bloqueado, pode sair com CTRL + C.

2. Edite um novo apigeeds:

   Kubectl edit -n apigee apigeeds default
   

3. Adicione/atualize o campo forceDelete na especificação do arquivo de dados do Apigee

   spec:
   forceDelete: true
   

4. Guarde o ficheiro e saia.

Agora, aguarde até que o arquivo de dados seja eliminado. A eliminação de todos os recursos do Cassandra pode demorar alguns minutos.

Compreender o script

O script apigee-hybrid-setup.shexecuta algumas validações básicas e ajuda a automatizar os passos que, de outra forma, teria de realizar se quisesse uma personalização mais detalhada, conforme documentado no artigo Instalação híbrida do Apigee personalizada. Mesmo com a instalação personalizada, ainda pode usar parcialmente o script para ajudar com determinadas tarefas.

Pode executar ./tools/apigee-hybrid-setup.sh --help para ver uma lista de flags suportadas e receber ajuda adicional com o script. As seguintes flags são suportadas de momento:

• --namespace Por predefinição, o script instala todos os componentes no espaço de nomes apigee. Pode alterar este comportamento especificando o nome do espaço de nomes através desta flag.
• --org Usado para fornecer o nome da organização do Apigee. Se não for especificado, o projeto do Google Cloud predefinido é o atualmente selecionado em gcloud
• --envgroup Usado para fornecer o nome do grupo de ambientes na sua organização. Se não for especificado, é feita uma tentativa de consultar as APIs do plano de controlo para determinar o nome do grupo de ambientes. Se forem encontrados vários grupos de ambientes, é devolvido um erro e o script é terminado.
• --env Usado para fornecer o nome do ambiente na sua organização. Se não for especificado, é feita uma tentativa de consultar as APIs do plano de controlo para determinar o nome do ambiente. Se forem encontrados vários ambientes ou o ambiente não fizer parte do grupo de ambientes, é devolvido um erro e o script é terminado.
• --cluster-name O nome do cluster do Kubernetes.
• --cluster-region A região onde o cluster do Kubernetes está localizado
• --gcp-project-id O ID do projeto do Google Cloud onde o cluster do Kubernetes existe
• --ingress-domain Especifica o nome do anfitrião/nome do domínio que vai ser usado para gerar os certificados TLS autoassinados para o istio ingress-gateway. Se não for especificado nenhum, é feita uma tentativa de determinar o valor consultando as APIs do plano de controlo para obter o valor do grupo de ambiente. Se existirem problemas na determinação do grupo de ambiente ou se existirem vários nomes de anfitrião configurados para o grupo de ambiente, é devolvido um erro e o script é terminado.
• --generate-internal-tls-certs Esta ação gera um segredo do Kubernetes denominado apigee-ca que contém um certificado e um par de chaves gerados por nós.
• --create-ingress-tls-certs Isto gera um segredo denominado {ORG_NAME}-{ENV_GROUP_NAME} (derivado do nome da organização e do grupo de ambientes) no espaço de nomes istio-system que contém um certificado e um par de chaves que vão ser usados para a comunicação TLS. O nome do domínio usado para gerar estes certificados é derivado do valor encontrado na configuração do grupo de ambientes. Em caso de conflitos (como quando encontramos vários domínios), são apresentadas mensagens de erro adequadas.
• --create-gcp-sa-and-secrets Cria uma única conta de serviço do Google Cloud no projeto do Google Cloud, transfere as chaves e, em seguida, cria os segredos do Kubernetes que contêm a chave. Pode encontrar os nomes dos segredos nas contas de serviço do Google Cloud.
• --fill-values Substitui os valores de org, env, envgroup e outros nomes sempre que forem necessários nos vários ficheiros YAML.
• --apply-configuration Isto cria os emissores de certificados, as definições de recursos personalizados, os webhooks, as funções e o recurso do controlador. Os recursos são criados pela ordem correta e o comando é bloqueado até que todos estejam em bom estado.
• -- rename-directories Mude o nome do ambiente e do grupo de ambientes para os nomes do ambiente e do grupo de ambientes corretos.
• --verbose Mostra a saída detalhada para depuração.
• --help Apresentar informações de utilização.
• --setup-all Esta ação executa todas as tarefas que podem ser realizadas por este script

Estrutura de pastas de configuração do Apigee Hybrid

Por predefinição, a pasta apigee-hybrid-setup tem a seguinte estrutura hierárquica:

.
├── 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

Pode encontrar uma versão dos ficheiros acima na etiqueta preview-1 do repositório do GitHub em: https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1.

A pasta acima contém manifestos do Kubernetes para o tempo de execução do Apigee hybrid e usa o Kustomize para a gestão da configuração. Os manifestos são organizados com base no conceito de bases e sobreposições do Kustomize. A pasta bases contém a configuração mínima necessária para cada componente do Apigee. A pasta de sobreposições contém várias funcionalidades adicionais(configurações) que são definidas como componentes. Pode um componente descomentando a referência do componente no kustomization.yaml

Exemplo : para ativar o gcs-backup para o banco de dados do Apigee, o componente gcs-backup foi retirado do comentário na personalização.yaml abaixo.

Caminho : ${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

Qualquer valor que exija personalizações tem de ser definido no ficheiro patch.yaml correspondente para gcs-backup. No ficheiro abaixo, o valor de CLOUD_STORAGE_BUCKET_PATH tem de ser definido pelo utilizador

Caminho: $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"

Da mesma forma, qualquer funcionalidade/configuração que exija personalizações pode ser ativada descomentando o componente no kustomization.yaml do componente apigee. Além disso, conforme necessário, os valores correspondentes dos campos no ficheiro patch.yaml do componente têm de ser definidos em conformidade.

Breve explicação das pastas e dos ficheiros:

bases

Esta pasta tem os modelos com a configuração mínima necessária para cada um dos componentes do Apigee. Não é necessário fazer modificações nos manifestos nesta pasta.

sobreposições

Esta pasta contém os modelos de componentes do Kustomize para as configurações adicionais

inicialização

namespaces.yaml

O espaço de nomes onde os componentes do plano de dados da Apigee vão ser instalados. O nome do espaço de nomes predefinido é apigee

certificados

Contém os recursos Issuer e Certificate que são usados para emitir certificados para os webhooks. Também contém o Issuer que é usado para emitir certificados para vários pods para comunicação TLS.

rbac

Contém os elementos Role, ClusterRole, RoleBinding e ClusterRoleBinding que vão ser usados por vários componentes.

crds

    Contains the definition of all the CRDs which are used by Apigee.

webhooks

Contém ValidatingWebhookConfiguration e MutatingWebhookConfiguration que vão ser usados para fazer validações nos recursos personalizados.

entrada

Contém a configuração aplicável a todos os PODs de entrada. Por exemplo, Modificação de cabeçalho comum, verificação de funcionamento, etc.

openshift

Contém a definição de SecurityContextConstraints do OpenShift.

Controladores

apigee-controller

apigee-hybrid-config.yaml

Contém um ConfigMap que é fornecido como entrada em apigee-controller-manager.yaml. Este ConfigMap contém configurações como imageHub, imagePullSecrets e forwardProxy, entre outras.

apigee-controller-deployment.yaml

Contém dois serviços para o controlador e o webhook, e a implementação para o controlador. Se quiser usar uma imagem privada para o controlador, é aqui que tem de fazer a alteração.

istiod

Apigee-istio-mesh-config.yaml Contém a configuração da malha para o Istio usado pelo Apigee. Isto não é aplicável a outras instalações do ASM/Istio no cluster.

apigee-ingressgateway-manager-deployment-patch.yaml

Contém um serviço e uma implementação do Istiod. Este é um istiod privado usado apenas para os exemplos de utilização do Apigee.

instances/{instanceName}

armazenamento de dados

apigee-datastore.yaml

Contém o recurso personalizado ApigeeDatastore que gere o Cassandra.

secrets.yaml

Contém credenciais predefinidas para o arquivo de dados.

redis

apigee-redis.yaml

Contém o recurso personalizado ApigeeRedis que gere o Redis.

secrets.yaml

Contém credenciais predefinidas para o arquivo de dados.

organização

apigee-organization.yaml

Contém o recurso personalizado ApigeeOrganization que gere outros subcomponentes, como connectAgent, watcherAndSynchronizer, MART, UDCA e Ingress.

secrets.yaml

Contém os Secrets que são referenciados em apigee-organization.yaml. Alguns segredos são comentados porque são gerados pelo script. Se desativar a respetiva geração, tem de os criar manualmente

ambientes

Contém todo o ambiente na sua organização. Deve criar uma pasta separada para cada ambiente copiando a que já lhe foi fornecida e configurando-a de acordo com os requisitos.

dev

apigee-environment.yaml

Contém o recurso personalizado ApigeeEnvironment que gere outros subcomponentes, como o tempo de execução.

secrets.yaml

Contém os Secrets que são referenciados em apigee-environment.yaml. Alguns segredos são comentados porque são gerados pelo script. Se desativar a respetiva geração, tem de criar manualmente esses

telemetria

apigee-telemetry.yaml

Contém o recurso personalizado ApigeeTelemetry.

secrets.yaml

Contém os Secrets que são referidos em apigee-telemetry.yaml. Alguns segredos são comentados porque são gerados pelo script. Se desativar a respetiva geração, tem de os criar manualmente

route-config

dev-envgroup

apigee-route-config.yaml

Contém o recurso personalizado ApigeeRouteConfig.

secrets.yaml

Contém um Secret que é referenciado em apigee-route-config.yaml. Está comentado porque é gerado automaticamente pelo script apigee-hybrid-setup.sh e é mantido aí para fornecer um exemplo do aspeto que o segredo deve ter se o criar manualmente.

diagnóstico

diagnostic-collector.yaml

Recursos que vão ser usados para implementar o diagnóstico

ferramentas

apigee-hybrid-setup.sh

apigee-create-service-account.sh

dump-kubernetes.sh

apigee-pull-push.sh

Armazenar chaves de contas de serviço em cofres externos

O Vault (da Hashicorp) é um sistema de gestão de segredos popular que tem várias integrações com lojas de segredos fornecidas pela Google, Azure, AWS e outros. O Hashicorp Vault permite-lhe obter segredos de uma origem externa e, em seguida, usá-los em recursos do Kubernetes. Existem várias formas de usar o Vault para obter segredos. Os passos seguintes servem como exemplo básico de como usar o Vault CSI Provider para montar chaves de contas de serviço do Google Cloud armazenadas num motor secreto fornecido pelo Vault.

---

Nota: neste exemplo, estamos a instalar o Vault no modo de desenvolvimento para fins de teste. Para um sistema de produção real, recomendamos que instale o Helm num dos outros modos indicados aqui. Para ver passos detalhados sobre a instalação do Vault para casos de utilização de produção, consulte o guia de implementação do Vault no Kubernetes | Vault.

---

1. Vamos usar o Helm para instalar recursos relacionados com o Vault no seu cluster. Siga os passos em Instalar o Helm sobre como configurar o Helm no seu sistema.

2. Siga os passos em Instale o gráfico Helm do Vault, nomeadamente:

   1. Adicionar o repositório Hashicorp ao Helm

      helm repo add hashicorp https://helm.releases.hashicorp.com
      

   2. Atualize os repositórios Helm

      helm repo update
      

   3. Instalar o Vault

      helm install vault hashicorp/vault \
      --set "server.dev.enabled=true" \
      --set "injector.enabled=false" \
      --set "csi.enabled=true"
      

3. Agora, vamos armazenar o segredo no Vault.

   1. Obtenha um shell no agrupamento de desenvolvimento do cofre

      kubectl exec -it vault-0 -- /bin/sh
       ```
      

   2. Neste exemplo, vamos usar o motor secreto de chave/valor para armazenar dados.

      vault kv put secret/runtime-gcp-sa-key key="${BASE_64_ENCODED_KEY}"
      

   3. Para verificar se a chave foi armazenada com êxito, use:

      vault kv get secret/runtime-gcp-sa-key
      

4. Configure a autenticação para permitir que o pod de tempo de execução extraia a chave. Conforme abordado em Contas de serviço do Kubernetes, as contas de serviço do Kubernetes fornecem identidade aos pods e permitem que estes façam a autenticação noutros sistemas.

   1. Obtenha um shell no agrupamento de desenvolvimento do cofre

      kubectl exec -it vault-0 -- /bin/sh
      

   2. Ative o método de autenticação do Kubernetes

      vault auth enable kubernetes
      

   3. Escreva a configuração de autorização

      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
      

   4. Crie a política de autorização

      vault policy write apigee-runtime-app - <<EOF
      path "secret/data/runtime-gcp-sa-key" {
      capabilities = ["read"]
      }
      EOF
      

   5. Associe a política à conta de serviço

      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
      

   Aqui, assumimos que a conta de serviço está no espaço de nomes apigee. Se tiver outro espaço de nomes para instalar o Apigee, vai usar esse nome.

   1. Saia da shell no interior do cofre-0

      exit
      

5. Instale o controlador CSI da loja de segredos

   # 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-driver
   

6. Crie um recurso do Kubernetes SecretProviderClass que faça referência ao segredo que criou no cofre

   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"
   EOF
   

7. Aplique o yaml

   kubectl apply -f spc-vault.yaml
   

8. Crie a conta de serviço do Kubernetes à qual atribuímos as autorizações no passo (4.e)

   kubectl create serviceaccount -n ${APIGEE_NAMESPACE} apigee-runtime-sa
   

9. Modifique o ficheiro apigee-environment.yaml para o ambiente e adicione as seguintes linhas:

   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"
   

10. Aplique as alterações:

    kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/$ENV_NAME
    

Atualização do Apigee Hybrid

---

Nota: - Este procedimento abrange as atualizações entre versões híbridas que suportam o novo modelo de instalação. Não abrange a migração da experiência apigeectl para o novo modelo de instalação.

---

Deve ter concluído todos os requisitos mencionados em Pré-requisitos. Além disso, recomendamos que faça um reinício contínuo de todos os componentes para verificar se o cluster está em bom estado. A ordem dos reinícios é Cassandra, Redis, ApigeeOrganization e ApigeeEnvironment.

Criar cópia de segurança

1. Crie uma cópia de segurança da configuração híbrida atual. É necessária uma cópia de segurança caso precise de reverter a atualização para a versão atual.

   tar -czvf apigee-hybrid-install.v-X.Y.Z.tar.gz $HYBRID_INSTALL_BASE_DIR
   

2. Crie uma cópia de segurança da base de dados Cassandra. As cópias de segurança do Cassandra são uma medida de proteção importante contra cenários de desastre.

Atualize a sua plataforma Kubernetes, se necessário

Este passo não é necessário sempre, mas tem de atualizar a sua plataforma Kubernetes, como o Kubernetes, o OpenShift e os componentes, como o cert-manager, o Cassandra, etc., se a versão já não for suportada pela versão mais recente do Apigee Hybrid. A documentação vai conter as versões suportadas de plataformas e componentes.

Transfira ficheiros de configuração

Transfira o repositório e substitua a pasta bases e tools na configuração híbrida do Apigee existente por uma mais recente:

1. Clone a etiqueta preview-1 do repositório do GitHub em https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1

   O repositório clonado tem uma estrutura semelhante à descrita em Estrutura de pastas de configuração do Apigee Hybrid:

2. substituir a inicialização, as ferramentas e a pasta do controlador na configuração híbrida do Apigee existente.

   export HYBRID_INSTALL_HOME=PATH_TO_PREVIOUS_HYBRID_INSTALL_DIRECTORY
   mv -f bases $HYBRID_INSTALL_HOME/bases
   mv -f tools $HYBRID_INSTALL_HOME/tools
   

Atualize as autorizações da conta de serviço, se necessário

Este passo também não é necessário sempre, mas tem de criar uma nova conta de serviço ou atualizar as autorizações das contas de serviço existentes, se necessário. O guia de atualização fornece os detalhes sobre as contas de serviço que têm de ser modificadas ou criadas e as funções que têm de ser adicionadas.

• Se precisar de modificar as autorizações de contas de serviço existentes, use o comando gcloud adequado. O guia de atualização tem comandos e funções detalhados que têm de ser adicionados.

  gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-component@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/$NEW_ROLE"
  

• Se a versão mais recente do Apigee Hybrid puder exigir uma conta de serviço adicional para componentes novos / existentes, tem de criá-los. Pode usar o script apigee-create-service-account.sh enviado na pasta da ferramenta para criar novas contas de serviço. Uma vez que o script já vai ser atualizado como parte do passo 4, vai ter detalhes e um novo perfil necessários para uma nova conta de serviço que tem de ser criada.

  O nome da conta de serviço recém-criada tem de ser referenciado no CR do componente correspondente.

  ./tools/create-service-account --env prod --profile apigee-component
  

Atualize o comando

Altere os campos de versão dos componentes indicados em ${INSTALL_DIR}/overlays/instances/$INSTANCE_DIR/kustomization.yaml para a versão híbrida relevante.

Segue-se um exemplo de um ficheiro $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/kustomization.yaml. O valor do campo de versão tem de ser atualizado para a versão relevante

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)

Siga o mesmo conjunto de passos fornecidos em Crie recursos de inicialização e controlador no fluxo de trabalho de instalação híbrida do Apigee. Pode usar um script ou seguir os passos manuais fornecidos para atualizar os recursos de inicialização e o controlador.

Atualize os componentes do Apigee Kubernetes

Tem de fazer as seguintes alterações: - No caso de alterações arquitetónicas ou introdução de novos campos ou descontinuação de campos antigos, tem de modificar os CRs com as alterações adequadas de acordo com as instruções fornecidas no guia de atualização. – No mínimo, tem de atualizar os campos de versão nos CRs (que indicam a versão do Apigee Hybrid instalada) para a versão mais recente do Apigee Hybrid.

Aplique as alterações aos CRs do Apigee. Para o ambiente de não produção, pode aplicar todas as alterações aos componentes do Apigee em simultâneo

kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}

Reversão do Apigee Hybrid

1. Restaure o apigee-hybrid-setup

   Mova-se para o diretório que contém a versão anterior da configuração híbrida do Apigee. Se não estiver disponível, restaure-o a partir do ficheiro ZIP criado no passo 1[link] durante a atualização do Apigee Hybrid.

2. Reverta os componentes do Kubernetes

   Aplique as alterações para CRs do Apigee

   kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
   

3. Controlador de reversão

   Siga o mesmo conjunto de passos fornecidos para criar recursos de inicialização e um controlador no fluxo de trabalho de instalação híbrida do Apigee. Pode usar um script ou seguir os passos manuais fornecidos para reverter os recursos de inicialização e o controlador.

4. Limpeza

   Tem de limpar todos os novos recursos adicionais criados durante a atualização, como novos componentes ou contas de serviço introduzidos na versão mais recente do híbrido. Todos os recursos que têm de ser limpos e os passos para os limpar são fornecidos no guia de atualização.

Eliminar um ambiente

---

Aviso: se tiver vários ambientes, certifique-se de que os segredos que está a eliminar não são referenciados nos outros ambientes. Para verificar, execute o comando kubectl get env -n ${APIGEE_NAMESPACE} ${ENV_RESOURCE_NAME} -o yaml e, em seguida, procure o recurso que planeia eliminar.

---

Seguem-se os passos para eliminar todos os recursos relacionados com um ambiente do seu cluster do Kubernetes:

1. Obtenha o nome do CR do ambiente. Pode fazê-lo obtendo todos os ambientes:

   kubectl get env -n ${APIGEE_NAMESPACE}
   

   Armazene o nome do recurso na variável de ambiente APIGEE_ENV.

2. Elimine as chaves de encriptação do ambiente. Por exemplo, se não tiver alterado o nome das chaves de encriptação, pode eliminá-las através do seguinte comando:

   kubectl delete secret -n ${APIGEE_NAMESPACE} $APIGEE_ENV-encryption-keys
   

3. Elimine segredos da conta de serviço da Google Cloud:

   kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}')
   

4. Elimine contas de serviço do Kubernetes:

   kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')
   

5. Elimine o recurso personalizado do ambiente do Apigee:

   kubectl -n ${APIGEE_NAMESPACE} delete env $APIGEE_ENV
   

Eliminar uma configuração híbrida

---

Aviso: é assim que os passos são apresentados para a instalação normal do Apigee Hybrid. Os passos diferem ligeiramente para casos avançados, como ter uma segunda organização no mesmo cluster, etc.

---

Seguem-se os passos para eliminar todos os recursos relacionados com o Apigee Hybrid do seu cluster do Kubernetes:

1. Tem de eliminar as tarefas de configuração do utilizador e do esquema do 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')
   

2. Tem de eliminar os componentes do plano de dados híbrido do Apigee implementados. Use o seguinte comando para eliminar todos os componentes:

   kubectl delete -k ${INSTALL_DIR}/overlays/instances/$INSTANCE_NAME
   

3. Este passo só é necessário se não tiver usado o nome predefinido para os segredos da conta de serviço do Kubernetes, os segredos da conta de serviço do Google Cloud, etc. Se tiver usado os nomes predefinidos, estes são eliminados no passo seguinte. Caso contrário, tem de os eliminar manualmente através dos seguintes comandos:

   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}')
   

4. No caso do OpenShift, tem de eliminar o SCC (Security Context Constraints) criado durante a instalação do Apigee Hybrid.

   kubectl delete scc ${SECURITY_CONTEXT_CONSTRAINTS_NAME}
   

5. Execute o comando abaixo para eliminar funções, associações de funções, CRDs, implementações de controladores, etc.

   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
   

6. Execute o comando abaixo para eliminar o espaço de nomes apigee

   kubectl delete -f ${INSTALL_DIR}/overlays/initialization/namespace.yaml
   

   Em alternativa, use o comando:

   kubectl delete $APIGEE_NAMESPACE
   

Instalação de várias instâncias

A configuração de várias instâncias refere-se à configuração híbrida que pode abranger várias regiões ou também dentro das mesmas regiões. A Apigee recomenda que organize as configurações da 2.ª instância numa estrutura de diretórios separada, uma vez que as configurações do ambiente (réplicas, etc.) são invariavelmente diferentes entre instâncias. As configurações de cada instância estão separadas e organizadas de forma independente nas respetivas estruturas de pastas.

Por exemplo, para uma configuração ativa-passiva num cenário de várias regiões, pode querer configurar uma 2.ª região em espera ativa com dimensionamentos e configurações diferentes.

Na estrutura de pastas abaixo, pode fazer uma cópia do diretório instance1 denominado instance2 e modificar as configurações de armazenamento de dados e de entrada conforme necessário.

apigee-hybrid-setup estrutura de pastas para a configuração de várias instâncias.]

.
├── 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

Configuração de várias instâncias no GKE

Pré-requisitos

Antes de configurar várias instâncias do modo híbrido, espera-se que tenha concluído os seguintes pré-requisitos:

• Configure clusters do Kubernetes em várias regiões(iguais ou diferentes) com diferentes blocos CIDR
• Configure a comunicação entre regiões
• Abra as portas 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões (a porta 7000 pode ser usada como opção de cópia de segurança durante a resolução de problemas). Consulte também o artigo Configurar portas.

---

Nota: a Apigee recomenda que se certifique de que as horas dos seus servidores estão sincronizadas. Várias funcionalidades, como a expiração e a revogação de tokens, dependem de horas do sistema precisas. Se alojar os componentes de tempo de execução em diferentes centros de dados, certifique-se de que as horas do sistema estão sincronizadas.

Pode usar uma ferramenta como ntpdate para verificar se as horas do servidor estão sincronizadas.

---

Configure o anfitrião de origem multirregião

1. Faça uma cópia da pasta $INSTANCE_NAME da sua instância existente e adicione-a à pasta instances.
2. Modifique o valor do campo do espaço de nomes se for diferente do espaço de nomes instance1.
3. Siga os passos especificados em Especificar certificados TLS de entrada para modificar a configuração de entrada da outra instância.

4. Consulte o artigo Gerir gateway de entrada do Apigee para obter informações sobre a configuração do IP do equilibrador de carga para a outra instância

   ---

   Nota: recomenda-se que não modifique as configurações dos restantes componentes, exceto as indicadas nos passos seguintes.

   ---

5. Defina o contexto do kubectl para o cluster original antes de obter o nome da semente

   kubectl config use-context original-cluster-name
   

6. Execute o seguinte comando kubectl para identificar um endereço de anfitrião inicial para o Cassandra na região atual.

   kubectl get pods -o wide -n apigee -l app=apigee-cassandra
   

7. Qualquer um dos IPs do agrupamento devolvidos pelo comando anterior pode ser considerado o anfitrião de origem multirregional.

8. Na 2.ª instância, configure o valor de multiRegionSeedHost no CR do arquivo de dados do Apigee em ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/apigee-datastore.yaml

Configure a nova instância

1. Defina o contexto para o cluster existente

   kubectl config use-context existing-cluster-name
   

2. Exporte o segredo apigee-ca para um ficheiro

   kubectl -n cert-manager get secret apigee-root-certificate -o yaml > apigee-root-certificate.yaml
   

3. Defina o contexto para o nome do cluster da nova região:

   kubectl config use-context NEW_CLUSTER_NAME
   

4. Importe o segredo para o novo cluster

   kubectl -n cert-manager apply -f apigee-root-certificate.yaml
   

5. Instale o modo híbrido na nova instância (região) seguindo os passos descritos em Crie recursos de inicialização e um controlador.

6. Configure o Cassandra em todos os pods nos novos centros de dados. Obtenha o apigeeorg do cluster com o seguinte comando:

   kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
   

7. Crie um ficheiro de recurso personalizado (YAML) de replicação de dados do Cassandra. O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml. O ficheiro tem de conter o seguinte

   apiVersion: apigee.cloud.google.com/v1alpha1
   kind: CassandraDataReplication
   metadata:
   name: REGION_EXPANSION
   namespace: NAMESPACE
   spec:
   organizationRef: APIGEEORG_VALUE
   force: false
   source:
     region: SOURCE_REGION
   

   Onde:

   • REGION_EXPANSION é o nome que está a dar a estes metadados. Pode escolher um nome como "cassandra-data-replication"
   • NAMESPACE é o mesmo espaço de nomes que foi escolhido para a 2.ª instância. Normalmente, é "apigee".
   • APIGEEORG_VALUE é o valor produzido pelo comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" no passo anterior.
   • SOURCE_REGION é o valor do valor do centro de dados do Cassandra do estado da ferramenta de nó do cluster de origem.

8. Aplique o CassandraDataReplication com o seguinte comando:

   kubectl apply -f datareplication.yaml
   

9. Valide o estado da reconstrução através do seguinte comando.

   ---

   Nota: a operação de reconstrução pode demorar várias horas, consoante o tamanho dos dados.

   ---

   kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
   

   O resultado deve ter um aspeto semelhante a

   {
   "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
   }
   

10. Valide os processos de reconstrução a partir dos registos. Além disso, verifique o tamanho dos dados através do comando nodetool status:

    kubectl logs apigee-cassandra-default-0 -f -n apigee
    

    Consulte o datastore/secrets.yaml para o JMX_user e o JMX_password

    kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status
    

11. Remova multiRegionSeedHost do CR do banco de dados do Apigee e execute o comando abaixo para aplicar a alteração

    kubectl apply k apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore
    

12. Verifique o estado do cluster do Cassandra

    O comando seguinte é útil para ver se a configuração do cluster foi bem-sucedida em dois centros de dados. O comando verifica o estado do nodetool para as duas regiões.

    kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status
    
    

    Datacenter: 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
    

Resolução de problemas

Guia de capacidade de apoio técnico, diagnóstico e resolução de problemas

https://cloud.google.com/apigee/docs/api-platform/troubleshoot/playbooks/troubleshooting-apigee-hybrid.

Limpeza manual após usar o forceDelete na configuração do Apigee Hybrid de várias regiões

• No exemplo seguinte, existem 2 regiões: us-east1 e us-west1.
• Na região us-west1, o arquivo de dados do Apigee foi eliminado através da eliminação forçada.
• Na região us-east1, o cassandra ainda está em funcionamento.

• Verifique se o cartão apigeeds foi eliminado através do comando

  kubectl get apigeeds -n apigee
  No resources found in apigee namespace.
  

• Altere o contexto do kubectl para a outra região onde o cluster do Cassandra ainda está em funcionamento (aqui, a região us-east1).

• Verifique se o arquivo de dados está em estado de execução

  kubectl get apigeeds -n apigee
  NAME      STATE     AGE
  default      running    23h
  

• Executar num dos pods do Cassandra na região de carregamento (aqui, a região us-east1)

  kubectl exec -it -n apigee apigee-cassandra-default-0 -- bash
  apigee@apigee-cassandra-default-0:~$
  

• Verifique o estado da ferramenta nodetool. Esta vai mostrar todos os nós inativos na região eliminada (neste caso, a região us-west1)

  apigee@apigee-cassandra-default-0:~$ nodetool -u ${APIGEE_JMX_USER} -pw ${APIGEE_JMX_PASSWORD} status
  

  Datacenter: 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
  

• Remova todos os nós na região eliminada (aqui 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
  

• Verifique se não restam nós da região eliminada (aqui us-west1)

  apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status
  
  

  Datacenter: 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
  

• Assim que este processo estiver concluído, elimine a tarefa de configuração do utilizador na região de carregamento (aqui, us-east1). A tarefa é recriada automaticamente no espaço de alguns segundos.

  kubectl get jobs -n apigee
  
  

  ​​NAME                                                                                    COMPLETIONS   DURATION   AGE
  apigee-cassandra-schema-setup-apigee--0d2504c                    0/1           5m54s      5m54s
  apigee-cassandra-user-setup--apigee--0d2504c                          0/1            7s         7s
  
  

  kubectl delete job apigee-cassandra-user-setup--apigee--0d2504c
  

• Aguarde pela conclusão da tarefa de configuração do utilizador

  kubectl get jobs -n apigee
  

  ​​NAME                                                                                    COMPLETIONS   DURATION   AGE
  apigee-cassandra-schema-setup-apigee--0d2504c                    1/1           5m54s      5m54s
  apigee-cassandra-user-setup--apigee--0d2504c                      1/1           7m                7m
  

• Verifique se os espaços de chaves não têm a região eliminada.

• Crie um pod de depuração do Cassandra.

  • Siga a versão híbrida 1.5 ou superior, siga a documentação do guia de resolução de problemas do Cassandra (por exemplo, para a versão híbrida 1.5: link, híbrida 1.6: link) e, em seguida, execute no pod criado

• Inicie sessão no cqlsh no pod de depuração através do comando

  apigee@cassandra-debug-client:~$ cqlsh apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local -u ddl_user --ssl
  Password:
  

• Verifique se a região us-west1 foi removida de todos os espaços de chaves

  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)