Prévia da nova instalação e administração híbrida da Apigee

Guia do usuário do pré-lançamento:
pré-lançamento dos novos procedimentos de instalação e administração para a Apigee híbrida v1.8.

Neste documento:

Visualizar

Este documento é destinado ao perfil de operador da Apigee (usuários que instalam/gerenciam/administram instalações híbridas da Apigee). A experiência na instalação da Apigee híbrida em uma das plataformas compatíveis do Kubernetes é um pré-requisito para seguir as instruções neste documento. Recomendamos criar uma organização de avaliação da Apigee para testar as etapas abaixo.

Feedback

Envie feedback sobre esse processo para Apigee-hybrid-install-preview@google.com.

Visão geral

A nova experiência de instalação híbrida da Apigee instala componentes da Apigee usando kubectl e integra a instalação e o gerenciamento da Apigee híbrida com ferramentas de orquestração de configuração do Kubernetes, como Kustomize. As validações aprimoradas e a visibilidade dos componentes que estão sendo instalados oferecem melhor depuração e melhoram o processo geral de instalação.

Um script de instalação, apigee-hybrid-setup.sh, oferece uma ferramenta fácil de instalação básica. Você pode usar isso para criar sua instalação híbrida e depois modificá-la de acordo com suas necessidades com o kubectl, ou criar a instalação híbrida do zero usando kubectl. Todas as propriedades de configuração híbrida da Apigee são armazenadas em arquivos yaml, um para cada componente principal. Isso permite um controle muito mais granular da sua instalação híbrida no ambiente do Kubernetes. Você encontra os arquivos de configuração e os scripts de instalação no repositório do GitHub.

Mudanças no novo processo de instalação

A Apigee está mudando o processo de instalação da Apigee híbrida pelos seguintes motivos:

  • O novo método de instalação da Apigee híbrida pode ser integrado a ferramentas de CI/CD do Kubernetes, como Argo, Flux ou Anthos Config Management que não usam um arquivo de configuração overrides.yaml.
  • A Apigee híbrida forneceu o apigeectl, uma ferramenta de modelos personalizados que gera manifestos do Kubernetes, entre outros itens, para instalar e gerenciar a Apigee híbrida em clusters do Kubernetes. O novo processo de instalação e gerenciamento oferece uma experiência semelhante a de outros fornecedores de software.
  • O novo processo permite a instalação básica rapidamente, criando automaticamente contas de serviço com as permissões necessárias, certificados TLS, preenchimento automático dos padrões e outros elementos básicos necessários.

Pré-requisitos

Antes de usar esta instalação de pré-lançamento, você precisa atender aos seguintes pré-requisitos:

Versão para visualização

Este pré-lançamento foi criado para funcionar com a versão 1.8.x da Apigee híbrida. Versões posteriores da Apigee híbrida não são compatíveis.

Configuração híbrida da Apigee

Antes de continuar a instalação da Apigee Hybrid, é provável que você tenha concluído as seguintes instruções listadas nas seções a seguir da documentação:

  1. Configuração do projeto e da organização
  2. Configuração do ambiente de execução híbrido

Ferramentas

Além disso, as seguintes ferramentas precisam estar disponíveis para download e ser configuradas na sua estação de trabalho:

  • curl
  • É necessário docker para executar o script apigee-hybrid-setup.sh. Siga as instruções em Conseguir o Docker para sua instalação.
  • O envsubst precisa estar disponível na maioria dos sistemas baseados em Linux/UNIX. Para MacOS e outros sistemas, siga as instruções neste repositório.
  • O jq precisa ser instalado. Fazer o download do jq.

  • kpt Faça o download do kpt.

  • kubectl versão 1.23 ou mais recente Consulte 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árias etapas. É possível definir essas variáveis na linha de comando ou por um script ou substituir o texto nos comandos ao inseri-los.

  • APIGEE_NAMESPACE: seu namespace da Apigee. Por padrão, ele é apigee. No entanto, é possível usar um namespace diferente.
  • CLUSTER_NAME: o nome do cluster em que você está instalando a Apigee híbrida. Este é o cluster que você criará na Etapa 1: criar um cluster
  • CLUSTER_LOCATION: a região do cluster. Os procedimentos neste guia presumem que você está usando um cluster regional. Se você estiver usando um cluster zonal, consulte as instruções da Etapa 1: criar um cluster.
  • ENV_GROUP: o nome do grupo de ambiente para sua instalação da Apigee híbrida. Esse é o grupo de ambientes criado na Etapa 3: criar um grupo de ambiente. É possível criar vários grupos de ambiente.
  • ENV_NAME: o nome do grupo de ambiente para sua instalação da Apigee híbrida. Esse é o grupo de ambientes criado na Etapa 3: criar um grupo de ambiente. É possível criar vários grupos de ambiente.
  • INSTALL_DIR: o diretório em que você instala a Apigee híbrida. Por padrão, este é o subdiretório apigee-hybrid-install/ do diretório em que você faz o download do instalador, por exemplo: /myhybrid/apigee-hybrid-install/. Este é o diretório raiz da estrutura de arquivos documentado em Estrutura de pasta de configuração híbrida da Apigee.
  • INSTANCE_DIR: o diretório de uma instância híbrida da Apigee específica. Por padrão, a primeira instância é denominada instance-1. O diretório de instância é um subdiretório de ${INSTALL_DIR}/overlays/instances/. É possível especificar qualquer nome para suas instâncias híbridas. Consulte Instalação de várias instâncias.
  • ORG_NAME: o nome da sua organização híbrida da Apigee. Precisa ser igual ao ID do projeto do Google Cloud. Consulte: Etapa 2: criar uma organização.

Instalação básica da Apigee híbrida

Para instalar rapidamente a Apigee Hybrid, sem uma personalização pesada, use o procedimento de duas etapas a seguir.

  • Um único ambiente
  • Um único grupo de ambiente
  • Uma única conta de serviço do Google Cloud é criada e usada para todos os componentes individuais
  • Valores padrão para todas as chaves de criptografia e senhas.
  1. Fazer o download de arquivos de configuração
  2. Executar configuração

Fazer o download dos arquivos de configuração

Faça o download e prepare os arquivos 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 até o diretório do repositório clonado:

    cd apigee-hybrid-install

  3. Crie uma ramificação com a tag 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 terá uma estrutura semelhante à descrita em Estrutura de pasta de configuração híbrida da Apigee:

Executar 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

Se você encontrar erros, execute o script novamente.

Outras opções que você pode usar:

  • --env $ENV_NAME especifica o nome do ambiente da Apigee.
  • --envgroup $ENV_GROUP especifica o grupo de ambiente.
  • --ingress-domain $HOSTNAME especifica o nome do host fornecido para o grupo de ambiente.
  • --gcp-project-id $PROJECT_ID especifica o ID do projeto do Google Cloud.

Veja mais opções em Noções básicas sobre o script.

Os erros durante a execução serão impressos na saída padrão.

Depois que o script for concluído, você terá concluído a instalação híbrida básica. Teste a instalação ao criar um proxy de amostra, conforme detalhado em Criar e implantar um novo proxy de API.

Instalação personalizada da Apigee híbrida

Para usuários mais avançados que querem um controle detalhado sobre a instalação, siga esta sequência de etapas. Para muitas das etapas abaixo, é possível executar a etapa manualmente ou usar o script de shell para automatizar essa etapa individual:

Fazer o download dos arquivos de configuração

Faça o download e prepare os arquivos de configuração:

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

    O repositório clonado terá uma estrutura semelhante à descrita em Estrutura de pasta de configuração híbrida da Apigee:

  2. cd no diretório apigee-hybrid-install/

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

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

Criar namespace

Crie um namespace do Kubernetes no cluster que contenha todos os componentes do cluster da Apigee.

kubectl create namespace apigee

Caso você escolha outro nome para o namespace, siga uma das três opções abaixo:

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

  • Execute os dois comandos a seguir:

    1. Use kpt para especificar o namespace da 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 namespace no 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"

  • Como alternativa, é possível alterar manualmente os recursos individualmente para serem criados no namespace de sua escolha.

Como usar imagens do Docker de repositórios particulares (opcional)

Você pode optar por não usar as imagens hospedadas publicamente e pode usar imagens dos seus próprios repositórios particulares:

  1. A primeira etapa é enviar todas as imagens para seu repositório privado. Para isso, siga as etapas em apigee-pull-push | Apigee X. Por padrão, as imagens são marcadas com a versão híbrida da Apigee a que correspondem, e é recomendável não editar essas tags. Também recomendamos que você não edite os nomes das imagens para que o caminho final da imagem possa ser construído, conforme explicado em Hub de imagens.

  2. Defina o valor do campo imageHub presente no arquivo apigee-hybrid-config.yaml como o caminho do host do repositório privado. Consulte Hub de imagens para mais detalhes.

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

Isso garantirá que todos os componentes híbridos da Apigee usem as imagens do seu repositório particular.

Além disso, use uma imagem particular para o controlador e o gateway de entrada da Apigee. Para isso, edite os campos apigee-controller-deployment.yaml e apigee-ingressgateway-manager-deployment.yaml e substitua todos os campos image pela imagem do repositório particular.

Como configurar imagePullSecrets (opcional)

  1. Crie um secret do Kubernetes com as credenciais para autenticar nos repositórios particulares. Consulte Extrair uma imagem de um registro particular para entender como o secret precisa ser criado.
  2. Após criar o secret, falta apenas consultar esse secret, o que pode ser feito editando o arquivo apigee-hybrid-config.yaml e definindo o valor do campo imagePullSecret como o nome do secret criado anteriormente e ativando o componente imagePullSecret no arquivo kustomization.yaml correspondente.

Caso você especifique o imagePullSecrets nos dois lugares, o que estiver no arquivo apigee-controller-manager.yaml terá precedência.

Configurar proxy de encaminhamento (opcional)

Para configurar proxies futuros, adicione o campo forwardProxy ao arquivo apigee-hybrid-config.yaml. Exemplo:

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

Como especificar certificados TLS de entrada

Como usar o script

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

Consulte a seção Noções básicas sobre o script para mais detalhes sobre essas sinalizações.

Manual

Você deve fornecer certificados TLS que serão usados para o gateway de entrada do istio. É possível:

Aqui, usaremos certificados autoassinados como exemplo. Os certificados autoassinados podem ser gerados usando (supondo que DOMAIN tenha sido definido corretamente e seja igual ao nome do host definido no seu envgroup):

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

Isso vai criar dois arquivos chamados tls.key e tls.crt.

Em seguida, crie um secret com o seguinte formato. Use kubectl create ou kubectl apply, conforme explicado em "Como usar um par de chaves/certificados personalizados 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 secret usando kubectl create:

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

Atualizar implantação de entrada

Para criar/modificar implantações de entrada, é necessário modificar o campo spec.components.ingressGateways no recurso personalizado da ApigeeOrganization no bases/initialization/crds/customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml.

Por padrão, criamos uma implantação de entrada com parâmetros padrão (os valores padrão serão exibidos na documentação de referência da resposta automática ):

ingressGateways:
- name: "prod-1"

Exemplos:

A. Como substituir campos do serviço de entrada

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

B. Alterar réplica mínima/máxima

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

C. Como adicionar uma nova implantação de entrada

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

Como configurar contas de serviço personalizadas do Google Cloud

Como usar o script

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

Em que APIGEE_NAMESPACE é seu namespace personalizado. O namespace padrão é apigee.

Consulte a seção Noções básicas sobre o script para mais detalhes sobre as sinalizações.

Manual

As chaves da conta de serviço do Google Cloud precisam ser armazenadas como secrets 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}

Veja mais detalhes sobre todas as contas de serviço obrigatórias e os nomes dos secrets na seção Contas de serviço do Google Cloud.

Você pode escolher um nome diferente para os secrets, mas terá que fazer uma mudança correspondente no componente em que esse nome foi usado. Por exemplo, se você decidir mudar o nome do secret da conta de serviço de ambiente de execução de apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME} para my-runtime-svc, será necessário fazer uma mudança correspondente no apigee-environment.yaml para esse ambiente.

Como usar identidades de carga de trabalho

É obrigatório configurar uma conta de serviço personalizada do Google Cloud ou usar identidades de carga de trabalho.

Pré-requisitos

Antes de usar identidades de carga de trabalho, verifique se o cluster do GKE tem o suporte ativado. Consulte Como atualizar pools de nós | Apigee X para saber mais detalhes.

Como ativar a carga de trabalho da identidade

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

Editar yaml de recursos

Alguns locais nos yamls de componentes exigem que os nomes corretos da organização, do ambiente e do grupo de ambiente estejam presentes. Você pode definir esses valores manualmente ou usar o script de shell para preenchê-los automaticamente.

Como usar o script

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

Criar 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

Permitir que a conta de serviço do Syncer interaja com o plano de controle

Siga as instruções da Etapa 8: ativar 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: altere o nome da conta de serviço nas instruções em Ativar acesso do sincronizador. Caso contrário, ocorrerá uma falha ao ativar o acesso do sincronizador.

Criar componentes do plano de dados da Apigee

Se você alterou os nomes de qualquer um dos recursos nas etapas anteriores, será necessário fazer uma alteração correspondente em outros arquivos YAML em que o recurso foi referenciado. Depois de fazer isso, use os comandos do exemplo a seguir:

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

para instalar todos os componentes.

Aguardar o início dos recursos

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

Personalizar a instalação do cert-manager em um namespace personalizado

Personalize o namespace em que o cert-manager está em execução com o procedimento a seguir.

Se o cert-manager estiver instalado no seu cluster em um namespace diferente de cert-manager, você precisará atualizar o namespace usado para criar o certificado raiz da Apigee.

  1. Edite o arquivo customization.yaml para a criação do certificado: $INSTALL_DIR/overlays/initialization/certificates/kustomize.yaml

  2. Adicione isto ao final do arquivo:

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

  3. Salve o arquivo

Kustomize e componentes

Visão geral

A nova instalação híbrida herda a ideologia Kustomize de estruturar yaml na forma de Bases e Overlays

  • As bases são arquivos fornecidos pela Apigee, que podem mudar a cada nova versão híbrida. Não é esperado que você modifique esses arquivos. Esses arquivos contêm alguns valores padrão fornecidos pela Apigee. Todos os arquivos na pasta de nível superior bases/ contêm Bases

  • As overlays mantêm a configuração do usuário e servem como o meio pelo qual vocês pode modificar os valores padrão especificados nas bases. Todos os arquivos na pasta de nível superior overlays/ contêm Overlays

Como usar componentes

As subpastas no diretório overlays/ de nível superior foram estruturadas de modo que você possa ativar (ou desativar) um determinado recurso adicional comentando ou removendo a marca de comentário de algumas linhas nos arquivos kustomization.yaml.

Por exemplo, a estrutura de pastas overlays/instances/{INSTANCE_NAME}/telemetry é assim:

telemetry
├── components
│   ├── http-proxy
│   ├── imagepullsecret
│   ├── logger
│   ├── metrics
│   ├── nodeselector
│   ├── openshift-scc
│   ├── workload-identity-logger
│   └── workload-identity-metrics
├── apigee-telemetry.yaml
└── kustomization.yaml

Confira como os arquivos telemetry/kustomization.yaml provavelmente vão ficar por padrã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

O ./components/logger foi comentado, o que significa simplesmente que o logger do Google Cloud não foi ativado por padrão. Para permitir isso, basta remover a marca de comentário dessa maneira:

components:

- ./components/logger

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

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

As seções a seguir mostram todos esses componentes, quando podem ser usados e como podem ser configurados.

OpenShift

Os usuários que quiserem instalar a Apigee Hybrid em um cluster OpenShift talvez precisem ativar alguns componentes/recursos antes de realizar a instalação. Isso é necessário se você não usar o script para realizar a instalação. Estes são os arquivos que precisam ser modificados:

  • overlays/initialization/openshift/kustomization.yaml Na seção resources:, remova a marca de comentário:

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

  • overlays/instances/{INSTANCE_NAME}/datastore/kustomization.yaml Remover marca de comentário:

    # - ./components/openshift-scc

    e remover o comentário do campo "components:" se ele ainda estiver comentado.

  • overlays/instances/{INSTANCE_NAME}/telemetry/kustomization.yaml Remover marca de comentário:

    # - ./components/openshift-scc

    e remover o comentário do campo "components:" se ele ainda estiver comentado.

Depois, você pode prosseguir com as etapas de instalação.

imagepullsecret

Esse componente pode ser ativado quando você tem imagens armazenadas no repositório particular. Para extrair imagens de um repositório particular, crie um secret do Kubernetes, que terá os detalhes de autenticação e poderá fazer referência a esse secret dentro dele. Consulte Como configurar imagePullSecrets (opcional) para ver instruções. Consulte Extrair uma imagem de um registro privado | Kubernetes na documentação do Kubernetes para mais informações.

Disponível em:

  • 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

Ativando:

Remova a marca de comentário da linha "./components/imagepullsecret/" nos respectivos arquivos kustomization.yaml, sempre que necessário.

Modificações a serem feitas:

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

Uso:

  1. Se você ainda não instalou a Apigee Hybrid, continue com as etapas de instalação. Essas mudanças vão ser aplicadas no processo.

  2. Se você já tiver o Apigee Hybrid instalado, será necessário aplicar as novas alterações usando:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

nodeselector

Esse componente permite programar pods para um recurso da Apigee em nós específicos. Consulte Como atribuir pods a nós | Kubernetes para mais informações.

Disponível em:

  • 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

Ativando:

Remova a marca de comentário da linha "./components/nodeselector" nos respectivos arquivos kustomization.yaml, sempre que necessário.

Modificações a serem feitas:

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

Uso:

  1. Se você ainda não instalou a Apigee Hybrid, continue com as etapas de instalação. Essas mudanças vão ser aplicadas no processo.

  2. Se você já tiver o Apigee Hybrid instalado, será necessário aplicar as novas alterações usando:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

workload-identity

Vários contêineres no ecossistema híbrido da Apigee exigem permissões para fazer determinadas chamadas de API para o plano de controle / plano de gerenciamento da Apigee. A Identidade da carga de trabalho concede esses permissões aos pods e aos contêineres deles. Recursos úteis para ler mais sobre isso incluem: - Introdução da Identidade da carga de trabalho: melhor autenticação para aplicativos do GKE | Blog do Google Cloud - Usar a Identidade da carga de trabalho | Documentação do Kubernetes Engine | Google Cloud

Disponível em:

  • 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 usar a identidade da carga de trabalho, você precisará conceder as permissões relevantes no seu projeto do Google Cloud usando:

    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

em que: - ${ORG_NAME}: o nome da sua organização da Apigee. - ${APIGEE_NAMESPACE}: o namespace do Kubernetes em que os componentes da Apigee foram instalados. Normalmente, seria apigee, a menos que tenha sido explicitamente alterado pelo usuário durante a instalação. - ${KSA_NAME}: o nome do namespace do Kubernetes. Você precisará executar esse 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 você não fez alterações durante a instalação, o valor será apigee-all-sa. Se você configurar várias contas de serviço do Google Cloud para componentes individuais, precisará corresponder o KSA_NAME ao GSA_NAME correspondente. Compare as tabelas nas contas de serviço do Google Cloud com as contas de serviço do Kubernetes para encontrar os equivalentes.

Ativando:

Remova a marca de comentário da linha ./components/workload-identity nos respectivos arquivos kustomization.yaml sempre que necessário. Na telemetria, temos complementos separados de identidade de carga de trabalho para componentes metrics e logger, que podem ser ativados individualmente.

Uso:

  1. Se você ainda não instalou o híbrido, basta ativar a identidade da carga de trabalho, conforme mencionado na seção anterior, e continuar com a instalação, que usará automaticamente a identidade da carga de trabalho.

  2. Se você já tiver o Apigee Hybrid instalado, será necessário aplicar as novas alterações usando:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

http-proxy

É possível configurar um servidor proxy em cada um dos componentes a seguir para que o tráfego por ele passe pelo proxy http configurado para ele. É possível configurar o proxy para cada componente da Apigee individualmente.

Disponível em:

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

Ativando:

Remova a marca de comentário da linha "./components/http-proxy/" nos respectivos arquivos kustomization.yaml, sempre que necessário.

Modificações a serem feitas:

  • component/http-proxy/patch.yaml Os parâmetros a seguir podem ser configurados no spec.httpForwardProxy
    • scheme: REQUIRED entre HTTP ou HTTPS
    • host: REQUIRED o endereço do host do proxy
    • port: REQUIRED o número da porta.
    • username: OPTIONAL o nome de usuário associado ao seu proxy
    • password: OPTIONAL a senha para acessar o proxy

Uso:

  1. Se você ainda não instalou a Apigee Hybrid, continue com as etapas de instalação. Essas mudanças vão ser aplicadas no processo.

  2. Se você já tiver o Apigee Hybrid instalado, será necessário aplicar as novas alterações usando:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

registrador e métricas

É possível ativar ou desativar individualmente o logger ou as métricas em overlays/instances/{INSTANCE_NAME}/telemetry. Por padrão, o logger está desativado e as métricas estão ativadas. Para ativá-las ou desativá-las, basta remover a marca de comentário ou comentar as linhas em telemetry/kustomization.yaml

gcs-backup e gcs-restore

Esse componente Kustomize pode ser usado para fazer um backup e a restauração do banco de dados do Cassandra no Google Cloud Storage.

Disponível em:

  • overlays/instances/{INSTANCE_NAME}/datastore

Pré-requisito:

  1. Faça o download das chaves das contas de serviço do Google Cloud em uma conta que tenha o papel de administrador de objetos do Storage.

    • Se você usou o script para executar a instalação e não usou identidades de carga de trabalho, é possível reutilizar as chaves transferidas por download disponíveis na pasta de contas de serviço que são criadas pelo script.

    • Também é possível usar o script create-service-account.sh para criar uma nova conta de serviço e fazer o download das chaves dela:

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

  2. Após o download das chaves, você precisa criar um secret do Kubernetes com o nome apigee-cassandra-backup-and-restore-gcp-sa-key, que pode ser feito usando o 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}"

    Em que:

    • ${PATH_TO_SA_KEY}: caminho para o arquivo que contém as chaves da conta de serviço.
    • ${APIGEE_NAMESPACE}: o namespace do Kubernetes em que os componentes da Apigee foram instalados. Geralmente, seria apigee, a menos que tenha sido explicitamente mudado durante a instalação

Se preferir, use o modelo do arquivo templates/secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml para criar o scret.

Ativando:

  • Caso queira ativar o backup, remova a marca de comentário da linha "./components/gcs-backup" no arquivo kustomization.yaml do repositório de dados.
  • Para restaurar um backup, remova a marca de comentário da linha "./components/gcs-restore" no arquivo kustomization.yaml do repositório de dados.

Modificações somente para backup

  • components/gcs-backup/apigee-datastore-patch.yaml
    • REQUIRED Mude o valor da variável de ambiente DATABASE_STORAGE_BUCKET, que terá o formato gs://BUCKET_NAME e aponta para o bucket do Google Cloud Storage em que os dados precisam ser armazenados em backup. A descrição corresponde ao dbStorageBucket descrito aqui.
  • components/gcs-backup/cron-patch.yaml
    • REQUIRED Altere spec.schedule para especificar a frequência do backup. O campo aceita o formato de programação padrão do Crontab. A descrição corresponde à programação descrita aqui.
    • REQUIRED Mude o valor da variável de ambiente DATABASE_STORAGE_BUCKET, que terá o formato gs://BUCKET_NAME e aponta para o bucket do Google Cloud Storage em que os dados precisam ser armazenados em backup. A descrição corresponde ao dbStorageBucket descrito aqui.
    • OPTIONAL altere o valor de HTTP_PROXY_URL para indicar 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}

Como fazer backup

Faça o backup com o seguinte comando:

kubectl apply -k overlays/instances/{INSTANCE_NAME}

Para aplicar as mudanças e ativar o backup, faça o seguinte:

Modificações apenas para restauração

  • components/gcs-restore/apigee-datastore-patch.yaml
    • REQUIRED Mude o valor da variável de ambiente DATABASE_STORAGE_BUCKET, que terá o formato gs://BUCKET_NAME e aponta para o bucket do Google Cloud Storage em que os dados precisam ser armazenados em backup. A descrição corresponde ao dbStorageBucket descrito aqui.
  • components/gcs-restore/job-patch.yaml
    • REQUIRED Mude o valor da variável de ambiente DATABASE_STORAGE_BUCKET, que terá o formato gs://BUCKET_NAME e aponta para o bucket do Google Cloud Storage em que os dados precisam ser armazenados em backup.
    • REQUIRED Altere o valor da variável de ambiente BACKUP_SNAPSHOT_TIMESTAMP. A descrição corresponde a restore:snapshotTimestamp descrita aqui.
    • OPTIONAL altere o valor de HTTP_PROXY_URL para indicar 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}

Como realizar a restauração:

Para ver informações sobre como restaurar backups, consulte Restaurar backups | Apigee X | Google Cloud.

  1. Crie um novo cluster do Kubernetes com um novo namespace para restaurar a implantação do ambiente de execução híbrido. Não é possível usar o mesmo cluster e namespace que você utilizou para a instalação híbrida original.

  2. Instale o híbrido no novo cluster com as configurações definidas acima, além de qualquer outra configuração que você quiser:

    • É possível usar a instalação básica e instalar o híbrido no novo namespace:
    ./tools/apigee-hybrid-setup.sh \
--cluster-name $CLUSTER_NAME \
--cluster-region $CLUSTER_LOCATION \
--namespace ${NEW_APIGEE_NAMESPACE}

  3. Quando a restauração for concluída, todos os recursos no namespace antigo poderão ser excluídos e alternados para o novo namespace.

Para mais informações, consulte Restaurar backups.

non-gcs-backup e non-gcs-restore

Esse componente Kustomize pode ser usado para fazer um backup e a restauração do banco de dados do Cassandra no Google Cloud Storage.

Disponível em:

  • overlays/instances/{INSTANCE_NAME}/datastore

Pré-requisito:

  1. As etapas da documentação já existente de Configurar o servidor e o SSH podem ser utilizadas.

  2. Nas etapas acima, você precisará usar a chave privada SSH, que está disponível no arquivo "ssh_key" gerado seguindo as etapas anteriores. Em seguida, criaremos um secret do Kubernetes com o nome apigee-cassandra-backup-and-restore-gcp-sa-key que contém essa chave privada SSH.

    É possível criar o secret do Kubernetes usando o seguinte comando:

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

    Em que:

    • ${PATH_TO_SSH_PRIVATE_KEY}: caminho para o arquivo que contém a chave privada SSH
    • ${APIGEE_NAMESPACE}: o namespace do Kubernetes em que os componentes da Apigee foram instalados. Geralmente, seria apigee, a menos que tenha sido explicitamente mudado durante a instalação

    Se preferir, use o modelo do arquivo templates/secret-apigee-cassandra-backup-and-restore-key-file.yaml para criar esse secret.

Ativando:

  • Caso queira ativar o backup, remova a marca de comentário da linha "./components/non-gcs-backup" no arquivo kustomization.yaml do repositório de dados.
  • Para restaurar um backup, remova a marca de comentário da linha "./components/non-gcs-restore" no arquivo kustomization.yaml do repositório de dados.

Modificações somente para backup

  • components/non-gcs-backup/apigee-datastore-patch.yaml
    • 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 a BACKUP_STORAGE_DIR descrita aqui.
  • components/non-gcs-backup/cron-patch.yaml
    • REQUIRED Altere spec.schedule para especificar a frequência do backup. O campo aceita o formato de programação padrão do Crontab. A descrição corresponde à programação descrita 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 a BACKUP_STORAGE_DIR descrita aqui.
    • OPTIONAL altere o valor de HTTP_PROXY_URL para indicar 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}

Como fazer backup

Faça o backup com o seguinte comando:

kubectl apply -k overlays/instances/{INSTANCE_NAME}

Para aplicar as mudanças e ativar o backup, faça o seguinte:

Modificações somente para backup

  • components/non-gcs-restore/apigee-datastore-patch.yaml
    • REQUIRED Mude o valor de BACKUP_SERVER_IP. A descrição corresponde a BACKUP_SERVER_IP descrita aqui.
    • REQUIRED Altere o valor de BACKUP_STORAGE_DIR. A descrição corresponde a BACKUP_STORAGE_DIR descrita aqui.
  • components/non-gcs-restore/job-patch.yaml
    • REQUIRED Mude o valor da variável de ambiente BACKUP_SNAPSHOT_TIMESTAMP. A descrição corresponde a restore:snapshotTimestamp descrita aqui.
    • REQUIRED Mude o valor de BACKUP_SERVER_IP. A descrição corresponde a BACKUP_SERVER_IP descrita aqui.
    • REQUIRED Mude o valor de BACKUP_STORAGE_DIR. A descrição corresponde a BACKUP_STORAGE_DIR descrita aqui.
    • OPTIONAL altere o valor de HTTP_PROXY_URL para indicar 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}

Como realizar a restauração:

Para uma visão geral sobre como restaurar backups, consulte Visão geral da restauração do Cassandra.

  1. Crie um novo cluster do Kubernetes com um novo namespace para restaurar a implantação do ambiente de execução híbrido. Não é possível usar o mesmo cluster e namespace que você utilizou para a instalação híbrida original.

  2. Instale o híbrido no novo cluster com as configurações definidas acima, além de qualquer outra configuração que você quiser: É possível usar a instalação básica e instalar o híbrido no novo namespace:

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

    Se preferir, siga a instalação híbrida da Apigee personalizada para configurar o que você preferir.

  3. Quando a restauração for concluída, todos os recursos no namespace antigo poderão ser excluídos e alternados para o novo namespace.

    Para ver mais informações, consulte Como programar backups em um servidor remoto.

http-client

Para instruções, consulte Ativar clientes HTTP | Apigee.

Disponível em:

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

Ativando:

Remova a marca de comentário da linha "./components/http-client" no respectivo arquivo route-config/${ENV_GROUP}/kustomization.yaml

Modificações a serem feitas:

  • Não é necessária nenhuma modificação obrigatória.

Uso:

  1. Se você ainda não instalou a Apigee Hybrid, continue com as etapas de instalação. Essas mudanças vão ser aplicadas no processo.

  2. Se você já tiver o Apigee Hybrid instalado, será necessário aplicar as novas alterações usando:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

non-sni-client

Equivalente à opção atual How to configure a non-SNI client | Apigee.

Disponível em:

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

Ativando:

Remova a marca de comentário da linha "./components/non-sni-client" no respectivo arquivo route-config/${ENV_GROUP}/kustomization.yaml

Modificações a serem feitas:

  • components/non-sni-client/apigee-route.yaml
    • REQUIRED credentialName A descrição corresponde a credential_name descrita aqui.

Uso:

  1. Se você ainda não instalou a Apigee Hybrid, continue com as etapas de instalação. Essas mudanças vão ser aplicadas no processo.

  2. Se você já tiver o Apigee Hybrid instalado, será necessário aplicar as novas alterações usando:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

http-and-non-sni-client

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

Ativando:

Remova a marca de comentário da linha "./components/http-and-non-sni-client" no respectivo arquivo route-config/${ENV_GROUP}/kustomization.yaml

Modificações a serem feitas:

  • components/http-and-non-sni-client/apigee-route.yaml
    • REQUIRED credentialName A descrição corresponde a credential_name descrita aqui.

Uso:

  1. Se você ainda não instalou a Apigee Hybrid, continue com as etapas de instalação. Essas mudanças vão ser aplicadas no processo.

  2. Se você já tiver o Apigee Hybrid instalado, será necessário aplicar as novas alterações usando:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

multirregional

Este componente pode ser usado durante a configuração de uma implantação cassandra multirregional. Para mais informações, consulte Implantação multirregional no GKE e no GKE On-Prem

Ativando:

Remova a marca de comentário da linha "./components/multi-region" no arquivo datastore/kustomization.yaml

Modificações a serem feitas:

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

    • REQUIRED source.region O nome do data center de origem do Cassandra que será usado para replicar dados. É possível identificar usando o 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

    • REQUIRED spec.components.properties.multiRegionSeedHost O IP do pod de qualquer um dos pods do cassandra de origem. Podemos usar:
    kubectl get pods -n ${APIGEE_NAMESPACE} -o wide
    • Para listar todos os pods e receber o IP de qualquer pod do cassandra, use o seguinte comando:
    kubectl get pods -o wide -n apigee

    A resposta será semelhante a esta:

    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 Pré-requisitos do GKE em "Implantação multirregional no GKE, GKE On-Prem e AKS":

Uso:

Em geral, o uso desse componente faz sentido quando você está configurando a Apigee híbrida para um novo cluster e já tem outra configuração de trabalho da Apigee híbrida.

  1. O cluster novo e o existente precisam usar os mesmos certificados TLS para garantir a comunicação adequada entre os pods do Cassandra. Portanto, vamos precisar copiar o secret apigee-root-certificate do cluster e usá-lo no mais recente também:

  2. Executar:

    kubectl config get-contexts
    • Para receber 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 raiz em um arquivo:

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

  4. Migre o contexto do cluster para o novo cluster em que você está instalando a Apigee Híbrida.

    kubectl config use-context ${NEW_CLUSTER_CONTEXT}

  5. Crie o secret raiz no novo cluster:

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

  6. Desativar a criação de um novo certificado raiz. Assim, não vamos criar um novo apigee-root-certificate e substituir o que criamos na etapa anterior.

  7. Remova a marca de comentário das seguintes linhas no arquivo overlays/initialization/certificates/kustomization.yaml:

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

  8. Continue com o restante da instalação híbrida da Apigee usando a instalação básica da Apigee híbrida ou a instalação híbrida da Apigee personalizada. Por exemplo, após a instalação básica da Apigee híbrida, é possível executar:

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

  9. Verifique o status de recriação usando o comando a seguir.

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

  10. Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o 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. Verifique o status de recriação usando o comando a seguir.

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

    Os resultados terão esta aparência:

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

    Consulte também: Implantação multirregional.

  12. Removendo 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

Hub de imagens

As imagens de contêiner do Docker são geralmente especificadas no formato:

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

ou as que usam um resumo têm a seguinte aparência:

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

A Apigee usa o conceito de "Hub de imagem", que nos formatos acima se refere ao ${REGISTRY_HOST_PATH}. O valor padrão do Hub de imagem é gcr.io/apigee-release/hybrid/.

As imagens que usam DIGEST precisarão ser definidas individualmente em cada subcomponente.

A Apigee cria o caminho final da imagem combinando o valor de:

  • "Hub de imagens" que pode ser substituído em apigee-hybrid-config.yaml. Cconsulte Como usar imagens do Docker de repositórios particulares para ver etapas detalhadas sobre como substituir o Hub de imagens.
  • O valor de IMAGE_TAG é recebido do campo version, que está dentro do arquivo yaml de cada um dos componentes individuais (por exemplo, apigee-organization.yaml). A Apigee marca as imagens com a versão da Apigee híbrida, o que significa que IMAGE_TAG é 1.8 para a versão da Apigee 1.8
  • O IMAGE_NAME é determinado implicitamente pelo nome do contêiner em que a imagem será usada. Por exemplo, para o contêiner apigee-runtime, o IMAGE_NAME será o ambiente de execução da Apigee.

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

Dessa forma, o caminho da imagem final é criado e usado em cada um dos contêineres nos respectivos pods.

Contas de serviço do Google Cloud

As contas de serviço do Google Cloud são usadas por aplicativos para fazer chamadas autorizadas para as APIs do Google. É possível fazer o download das chaves da conta de serviço do Google Cloud, que podem ser usadas para fins de autenticação. A Apigee espera que o usuário forneça chaves de conta de serviço criando secrets. Veja a seguir os nomes dos componentes e o nome padrão do secret em que as chaves da conta de serviço são procuradas:

Componente Subcomponente Nome do secret padrão do Kubernetes contendo a chave da conta de serviço
organization
connectAgent apigee-connect-agent-gcp-sa-key-${ORG_NAME}
watcher apigee-watcher-gcp-sa-key-${ORG_NAME}
mart apigee-mart-gcp-sa-key-${ORG_NAME}
udca apigee-udca-gcp-sa-key-${ORG_NAME}
ingressGateways N/A
ambiente
runtime apigee-runtime-gcp-sa-key-${ORG_NAME}-${ENV_NAME}
udca apigee-udca-gcp-sa-key-${ORG_NAME}-${ENV_NAME}
synchronizer apigee-synchronizer-gcp-sa-key-${ORG_NAME}-${ENV_NAME}
telemetry
métrica apigee-metrics-gcp-sa-key
containerLogs apigee-logger-gcp-sa-key

Contas de Serviço Kubernetes

As contas de serviço do Kubernetes fornecem identidades para os pods no seu cluster. Por padrão, o controlador da Apigee os cria para você. No entanto, se você quiser substituir a criação, por exemplo, quando estiver usando Identidades de carga de trabalho, especifique o campo podServiceAccountName nos vários subcomponentes.

Lista de componentes e os respectivos subcomponentes em que a conta de serviço do Kubernetes pode ser especificada com o nome padrão da conta de serviço do k8s quando você ativa o patch de identidade da carga de trabalho para eles.

Componente Subcomponente Nome padrão (disponível quando você ativou o patch de identidade da carga de trabalho)
organization
connectAgent apigee-connect-agent-svc-account-${ORG_NAME}
watcher apigee-watcher-svc-account-${ORG_NAME}
mart apigee-mart-svc-account-${ORG_NAME}
udca apigee-udca-svc-account-${ORG_NAME}
ambiente
synchronizer apigee-synchronizer-svc-account-${ORG_NAME}-${ENV_NAME}
udca apigee-udca-svc-account-${ORG_NAME}-${ENV_NAME}
runtime apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME}
datastore
cassandra apigee-datastore-svc-account
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 carga de trabalho permitem que pods (que usam contas de serviço do Kubernetes) em execução no GKE sejam autenticados diretamente com as APIs do Google Cloud sem exigir chaves de conta de serviço do Google Cloud.

Como 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 é simples:

  1. Crie uma nova pasta no diretório de ambientes (ou como você tiver estruturado suas pastas)
  2. Copie o arquivo apigee-environment.yaml de qualquer ambiente para a nova pasta.
  3. Se você quiser criar uma nova conta de serviço e chaves de criptografia para o novo ambiente, copie o secrets.yaml para a nova pasta e renomeie os secrets corretamente para diferenciá-los dos outros ambientes atuais. Normalmente, isso é feito adicionando o nome do ambiente como sufixo.
  4. Fazer as mudanças adequadas no apigee-environment.yaml, como:
    • Como alterar o nome do ambiente
    • Se novas contas de serviço e chaves de criptografia forem criadas, elas precisarão ser referenciadas corretamente no yaml.
  5. Como aplicar as yamls:
kubectl apply -f components/environments/new-env-name/secrets.yaml
kubectl apply -f components/environments/new-env-name/apigee-environment.yaml

Como usar a exclusão forçada no Datastore da Apigee

Se a exclusão do repositório de dados não estiver em andamento por algum motivo, agora o armazenamento de dados da Apigee pode ser excluído usando os comandos a seguir, independentemente do estado atual do cluster.

  1. Exclua apigeeds no namespace apigee:

    Kubectl delete -n apigee apigeeds default

    Se essa etapa ficar presa, use CTRL + C para sair.

  2. Edite um novo apigeeds:

    Kubectl edit -n apigee apigeeds default

  3. Adicionar/atualizar o campo forceDelete na especificação do repositório de dados da Apigee

    spec:
forceDelete: true

  4. Salve o arquivo e saia.

Agora aguarde a exclusão do repositório de dados. A exclusão de todos os recursos da cassandra pode levar alguns minutos.

Como entender o script

O script apigee-hybrid-setup.sh realiza algumas validações básicas e ajuda a automatizar as etapas que você precisaria fazer se quiser uma personalização mais detalhada, conforme documentado em Instalação híbrida personalizada da Apigee. Mesmo com a instalação personalizada, você ainda pode usar o script parcialmente para ajudar com determinadas tarefas.

Execute ./tools/apigee-hybrid-setup.sh --help para ver uma lista de sinalizações compatíveis e receber ajuda com o script. No momento, as seguintes sinalizações são compatíveis:

  • --namespace Por padrão, o script instala todos os componentes no namespace apigee. É possível alterar esse comportamento especificando o nome do namespace com essa sinalização.
  • --org usado para informar o nome da organização da Apigee. Se não for especificado, o padrão vai ser o projeto do Google Cloud selecionado no momento em gcloud
  • --envgroup Usado para informar o nome do grupo de ambiente na sua organização. Se não for especificado, será feita uma tentativa de consultar as APIs do plano de controle para determinar o nome do grupo do ambiente. Se vários grupos de ambiente forem encontrados, o erro será retornado e o script será encerrado.
  • --env Usado para informar o nome do ambiente dentro da sua organização. Se não for especificado, será feita uma tentativa de consultar as APIs do plano de controle para determinar o nome do ambiente. Se vários ambientes forem encontrados ou o ambiente não fizer parte do grupo, o erro será retornado e o script será encerrado.
  • --cluster-name O nome do cluster do Kubernetes.
  • --cluster-region a região em que o cluster do Kubernetes está localizado
  • --gcp-project-id o ID do projeto do Google Cloud em que o cluster do Kubernetes está localizado
  • --ingress-domain especifica o nome do host/nome de domínio que será usado para gerar os certificados TLS autoassinados para o istio ingress-gateway. Se nenhum for especificado, será feita uma tentativa de determinar o valor consultando as APIs do plano de controle para receber o valor do envgroup. Se ocorrer algum problema ao determinar o envgroup ou se houver vários nomes de host configurados para o envgroup, o erro será retornado e o script será encerrado.
  • --generate-internal-tls-certs Isso gerará um secret do Kubernetes chamado apigee-ca que contém um certificado e um par de chaves gerados por nós.
  • --create-ingress-tls-certs Isso gerará um Secret chamado {ORG_NAME}-{ENV_GROUP_NAME} (derivado do nome da organização e do envgroup) no namespace istio-system que conterá um certificado e um par de chaves que serão usados para comunicação TLS. O nome de domínio usado para gerar esses certificados é derivado do valor encontrado na configuração envgroup. Em caso de conflito (como quando encontramos vários domínios), as mensagens de erro apropriadas são exibidas.
  • --create-gcp-sa-and-secrets Cria uma única conta de serviço do Google Cloud no projeto do Google Cloud, faz o download das chaves e, em seguida, cria os secrets do Kubernetes que contêm a chave. Os nomes das chaves secretas podem ser encontrados 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 yaml.
  • --apply-configuration Isso vai criar os emissores de certificado, as definições de recursos personalizadas, os webhooks, os papéis e o recurso do controlador. Os recursos serão criados na ordem correta, e o comando será bloqueado até que todos estejam íntegros.
  • -- rename-directories Renomeie o ambiente e o grupo do ambiente pelos nomes dos ambientes e grupo corretos.
  • --verbose: mostra uma saída detalhada para depuração.
  • --help Exibe informações de uso.
  • --setup-all Isso executará todas as tarefas que podem ser realizadas por esse script

Estrutura de pasta de configuração híbrida da Apigee

Por padrã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

Uma versão dos arquivos acima pode ser encontrada na tag "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 ambiente de execução da Apigee híbrida e usa o Kustomize para o gerenciamento de configurações. Os manifestos são organizados com base no conceito de bases e overlays do Kustomize. A pasta bases contém a configuração mínima necessária para cada componente da Apigee. A pasta overlays contém vários recursos adicionais (configurações) que são definidos como componentes. Remova a marca de comentário da referência do componente no kustomization.yaml

Exemplo: para ativar o gcs-backup para o repositório de dados da Apigee, o componente gcs-backup foi removido da seção de comentários no customization.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 precise de personalizações precisará ser definido no patch.yaml correspondente para gcs-backup. No arquivo abaixo, o valor de CLOUD_STORAGE_BUCKET_PATH precisa ser definido pelo usuário

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 recurso/configuração que exija personalizações pode ser ativado com a remoção do comentário do componente no kustomization.yaml do componente da Apigee. Além disso, conforme necessário, os valores correspondentes para os campos no patch.yaml do componente precisam ser definidos corretamente.

Breve explicação das pastas e arquivos:

bases

Essa pasta tem os modelos com configuração mínima exigida por cada um dos componentes da Apigee. Não seria necessário modificar os manifestos nessa pasta.

overlays

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

initialization

namespaces.yaml

O namespace em que os componentes do plano de dados da Apigee serão instalados. O nome do namespace padrão é apigee

certificates

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

rbac

Contém a Role, a ClusterRole, a RoleBinding e a ClusterRoleBinding que serão usadas por vários componentes.

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

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

entrada

Contém a configuração que se aplica a todos os PODs de entrada. Por exemplo: Modificação de cabeçalho comum, verificação de integridade etc.

openshift

Contém a definição SecurityContextConstraintsdo 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, forwardProxy, entre outros.

apigee-controller-deployment.yaml

Contém dois Serviços para o controlador e webhook e a Implantação para o controlador. Se você quiser usar uma imagem particular para o controlador, é aqui que você precisará fazer a alteração.

istiod

Apigee-istio-mesh-config.yaml Contém configuração de malha para o Istio usada pela Apigee. Isso não se aplica a outras instalações do ASM/Istio no cluster.

apigee-ingressgateway-manager-deployment-patch.yaml

Contém um serviço e implantação do Istiod. Este é um istiod particular usado apenas nos casos de uso da Apigee.

instances/{instanceName}

datastore
apigee-datastore.yaml

Contém o recurso personalizado ApigeeDatastore que gerencia Cassandra.

secrets.yaml

Contém credenciais padrão para o repositório de dados.

redis
apigee-redis.yaml

Contém o recurso personalizado ApigeeRedis que gerencia Redis.

secrets.yaml

Contém credenciais padrão para o repositório de dados.

organização
apigee-organization.yaml

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

secrets.yaml

Contém os Secrets que são referenciados em apigee-organization.yaml. Alguns secrets são comentados, já que são gerados pelo script. Se você desativar a geração de conteúdo, precisará criá-lo manualmente

environments

Contém todo o ambiente da sua organização. Para criar uma pasta separada para cada ambiente, copie a pasta que já foi fornecida e configure-a conforme necessário.

dev
apigee-environment.yaml

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

secrets.yaml

Contém os Secrets que são referenciados em apigee-environment.yaml. Alguns secrets são comentados, já que são gerados pelo script. Se você desativar a geração de conteúdo, precisará criá-lo manualmente

telemetry
apigee-telemetry.yaml

Contém o recurso personalizado ApigeeTelemetry.

secrets.yaml

Contém os Secrets que são referenciados em apigee-telemetry.yaml. Alguns secrets são comentados, já que são gerados pelo script. Se você desativar a geração de conteúdo, precisará criá-lo 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. Ele é comentado, porque é gerado automaticamente pelo script apigee-hibrid-setup.sh e é mantido ali para fornecer uma amostra de como o secret deve ser caso você decida criá-lo manualmente.

diagnóstico

diagnostic-collector.yaml

Recursos que serão usados para iniciar a implantação do diagnóstico

tools

apigee-hybrid-setup.sh
apigee-create-service-account.sh
dump-kubernetes.sh
apigee-pull-push.sh

Como armazenar chaves de conta de serviço em cofres externos

O Vault (da Hashicorp) é um sistema de gerenciamento de secrets conhecido que tem várias integrações com armazenamento de secrets fornecidos pelo Google, Azure, AWS e outros. O Hashicorp Vault permite buscar secrets de uma fonte externa e usá-los nos recursos do Kubernetes. Há várias maneiras de usar o Vault para conseguir secrets. As etapas a seguir servirão como um exemplo básico sobre como usar o Provedor de CSI do Vault para montar chaves de conta de serviço do Google Cloud armazenadas em algum mecanismo secreto fornecido pelo Vault.

  1. Usaremos o Helm para instalar os recursos relacionados ao Vault no cluster. Siga as etapas em Como instalar o Helm para saber como configurar o helm no seu sistema.

  2. Siga as etapas em Instalar o gráfico do Helm do Vault, ou seja:

    1. Adicionar o repositório Hashicorp ao comando

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

    2. Atualizar repositórios do 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 armazenaremos o secret no Vault.

    1. Receber um shell dentro do vault dev pod

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

    2. Usaremos o mecanismo de secret de chave-valor para armazenar dados neste exemplo.

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

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

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

  4. Configure a autenticação para permitir que o pod de ambiente de execução extraia a chave. Conforme discutido em Contas de serviço do Kubernetes, as contas de serviço do Kubernetes fornecem identidade aos pods e permitem que elas sejam autenticadas com outros sistemas.

    1. Receber um shell dentro do vault dev pod

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

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

      vault auth enable kubernetes

    3. Gravar a configuração de autenticaçã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. Criar a política de autenticação

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

    5. Vincular 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, supomos que a conta de serviço está dentro do namespace da Apigee. Se você tiver outro namespace para instalar a Apigee, use esse nome.

    1. Sair do shell dentro de vault-0

      exit

  5. Instalar driver CSI de armazenamento de secrets

    # 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. Criar um recurso do Kubernetes SecretProviderClass que faça referência ao secret criado dentro do Vault

    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. Criar a conta de serviço do Kubernetes a que as permissões foram atribuídas na etapa (4.e)

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

  9. Modificar o arquivo apigee-environment.yaml e adicionar 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

Upgrade da Apigee híbrida

Os usuários precisam ter atendido a todos os requisitos mencionados em Pré-requisitos. Além disso, recomendamos que você reinicie todos os componentes para verificar se o cluster está íntegro. A ordem das reinicializações será Cassandra, Redis, ApigeeOrganization e ApigeeAmbient.

Criar backup

  1. Crie uma cópia de backup da configuração híbrida atual. O backup será necessário caso você precise reverter o upgrade para a versão atual.

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

  2. Criar backup do banco de dados cassandra. Os backups do Cassandra são uma medida importante de proteção contra cenários de desastres.

Fazer upgrade da plataforma do Kubernetes, se necessário

Essa etapa não é obrigatória todas as vezes, você vai precisar fazer upgrade da plataforma do Kubernetes, como Kubernetes, OpenShift e componentes, como cert-manager, cassandra e outros, se ela não for mais compatível com a versão mais recente da Apigee híbrida. A documentação incluirá versões compatíveis de plataformas e componentes.

Fazer o download dos arquivos de configuração

Faça o download do repositório e substitua as pastas bases e tools na configuração híbrida da Apigee atual por uma mais recente:

  1. Clone a tag de visualização-1 do repositório do GitHub em https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1

    O repositório clonado terá uma estrutura semelhante à descrita em Estrutura de pasta de configuração híbrida da Apigee:

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

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

Atualizar as permissões da conta de serviço, se necessário

Essa etapa também não é obrigatória, mas você vai precisar criar uma nova conta de serviço ou atualizar as permissões das contas de serviço atuais, se necessário. O guia de upgrade apresenta em detalhes quais contas de serviço precisam ser modificadas ou criadas e quais papéis precisam ser adicionados.

  • Se você precisar modificar as permissões das contas de serviço atuais, use o comando gcloud apropriado. O guia de upgrade vai ter comandos e papéis detalhados que precisam 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 híbrida mais recente da Apigee puder exigir uma conta de serviço adicional para componentes novos/existentes, será necessário criá-los. É possível usar o script apigee-create-service-account.sh enviado na pasta de ferramentas para criar novas contas de serviço. Como o script já será atualizado como parte da etapa 4, ele terá detalhes e um novo perfil necessários para uma nova conta de serviço que precise ser criada.

    O nome da conta de serviço recém-criado precisa ser referenciado na resposta automática do componente correspondente.

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

Fazer upgrade do controlador

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

Veja um exemplo de arquivo $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/kustomization.yaml. O valor do campo de versão precisa 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 etapas fornecido em Criar recursos de inicialização e controlador no fluxo de trabalho de instalação híbrida da Apigee. Use o script ou siga as etapas manuais fornecidas para fazer upgrade dos recursos de inicialização e controlador.

Atualizar componentes do Kubernetes para Apigee

Você vai precisar fazer as seguintes mudanças: - Em caso de alterações arquitetônicas ou introdução de novos campos ou descontinuação de campos antigos, você vai precisar modificar as respostas automáticas com as alterações apropriadas de acordo com as instruções fornecidas no guia de upgrade. - No mínimo, você precisa atualizar os campos de versão nas respostas automáticas (que indicarão a versão da híbrida instalada da Apigee) para a versão mais recente híbrida da Apigee.

Aplique as alterações para respostas automáticas da Apigee. Para ambientes que não são de produção, você pode aplicar todas as mudanças aos componentes da Apigee simultaneamente.

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

Reversão híbrida da Apigee

  1. Restaurar Apigee-hybrid-setup

    Mude para o diretório que contém a versão anterior da configuração da Apigee híbrida. Se ele não estiver disponível, restaure-o no arquivo ZIP criado na etapa 1[link] durante o upgrade híbrido da Apigee.

  2. Reverter componentes do Kubernetes

    Aplique as alterações para respostas automáticas da Apigee

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

  3. Controlador de reversão

    Siga o mesmo conjunto de etapas fornecido em Criar recursos de inicialização e controlador no fluxo de trabalho de instalação híbrida da Apigee. Use um script ou siga as etapas manuais fornecidas para reverter os recursos de inicialização e o controlador.

  4. Limpeza

    Você vai precisar limpar todos os novos recursos adicionais criados durante o upgrade, como novos componentes ou contas de serviço introduzidos na versão mais recente do híbrida. O que todos os recursos precisam é de limpeza, e as etapas para limpá-los serão apresentados no guia de upgrade.

Como excluir um ambiente

Veja a seguir as etapas para excluir todos os recursos relacionados a um ambiente do cluster do Kubernetes:

  1. Receber o nome da resposta automática do ambiente. Você pode fazer isso acessando todos os ambientes:

    kubectl get env -n ${APIGEE_NAMESPACE}

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

  2. Exclua as chaves de criptografia do ambiente. Por exemplo, se você não mudou o nome das chaves de criptografia, então poderá excluí-las usando:

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

  3. Exclua os secrets da conta de serviço do Google Cloud:

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

  4. Exclua as 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. Exclua o recurso personalizado do ambiente da Apigee:

    kubectl -n ${APIGEE_NAMESPACE} delete env $APIGEE_ENV

Como excluir uma configuração híbrida

Confira a seguir as etapas para excluir todos os recursos relacionados ao Apigee híbrido do seu cluster do Kubernetes:

  1. Você vai precisar excluir a configuração do usuário da Apigee e os jobs de configuração do esquema.

    # 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. Será preciso excluir os componentes do plano de dados híbrido da Apigee implantado Use o comando a seguir para excluir todos os componentes:

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

  3. Essa etapa só será necessária se você não depender do nome padrão para secrets da conta de serviço do Kubernetes, secrets da conta de serviço do Google Cloud etc. Caso você depender de nomes padrão, eles serão excluídos na próxima etapa. Caso contrário, você terá de excluí-los manualmente usando os 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, você precisará excluir o scc (restrições de contexto de segurança) criado durante a instalação híbrida da Apigee.

    kubectl delete scc ${SECURITY_CONTEXT_CONSTRAINTS_NAME}

  5. Execute o comando abaixo para excluir papéis, vinculações de papéis, CRDs, implantaçõ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 excluir o namespace da Apigee

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

    Como alternativa, use o comando:

    kubectl delete $APIGEE_NAMESPACE

Instalação de várias instâncias

A configuração de várias instâncias se refere à configuração híbrida que pode abranger várias regiões ou dentro das mesmas regiões. A Apigee recomenda organizar as configurações da segunda instância em uma estrutura de diretórios separada, já que as configurações do ambiente (réplicas etc.) são invariavelmente diferentes entre as instâncias. As configurações de cada instância são separadas e organizadas de maneira independente nas respectivas estruturas de pastas.

Por exemplo: para uma configuração Active-Passive em um cenário com várias regiões, pode ser conveniente configurar uma segunda região em um modo de espera morno com diferentes tamanhos e configurações.

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

Estrutura de pastas apigee-hybrid-setup 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 de trabalho híbrido, é esperado que você tenha concluído os seguintes pré-requisitos:

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

Use uma ferramenta como ntpdate para verificar se os horários dos servidores estão sincronizados.

Configurar o host de propagação multirregional

  1. Copie a pasta $INSTANCE_NAME da instância atual e adicione-a na pasta "instances".
  2. Modifique o valor do campo de namespace se ele for diferente do namespace instance1.
  3. Siga as etapas especificadas em Como especificar certificados TLS de entrada para modificar a configuração de entrada da outra instância.

  4. Consulte Como gerenciar o gateway de entrada da Apigee para informações sobre como configurar o IP do balanceador de carga para a outra instância

  5. Defina o contexto do kubectl como o cluster original antes de recuperar o nome da propagação

    kubectl config use-context original-cluster-name

  6. Execute o comando kubectl a seguir para identificar um endereço do host de propagação do Cassandra na região atual.

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

  7. Qualquer um dos IPs de pod retornados do comando anterior pode ser considerado o host de semente multirregional.

  8. Na segunda instância, configure o valor de multiRegionSeedHost na resposta automática do repositório de dados da Apigee em ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/apigee-datastore.yaml

Configurar a nova instância

  1. Defina o contexto como o cluster atual

    kubectl config use-context existing-cluster-name

  2. Exportar o secret da Apigee-ca para um arquivo

    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 secret para o novo cluster

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

  5. Instale o ambiente híbrido na nova instância (região) seguindo as etapas descritas em Criar controlador e recursos de inicialização.

  6. Configurar o Cassandra em todos os pods nos novos data centers. Receba apigeeorg do cluster com o seguinte comando:

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

  7. Crie um arquivo de recurso personalizado de replicação de dados do Cassandra (YAML). O arquivo pode ter qualquer nome. Nos exemplos a seguir, o arquivo terá o nome datareplication.yaml. O arquivo deve 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

    Em que:

    • REGION_EXPANSION é o nome que você está fornecendo a esses metadados. Você pode escolher um nome como "cassandra-data-replication"
    • NAMESPACE é o mesmo namespace escolhido para a segunda instância. Normalmente, é a "Apigee".
    • APIGEEORG_VALUE é a saída do valor de kubectl get apigeeorg -n apigee -o json | comando jq ".items[].metadata.name" na etapa anterior.
    • SOURCE_REGION é o valor do datacenter da cassandra a partir do status do nodetool do cluster de origem.

  8. Aplique o CassandraDataReplication com o seguinte comando:

    kubectl apply -f datareplication.yaml

  9. Verifique o status de recriação usando o comando a seguir.

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

    O resultado será parecido com este:

    {
"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. Verifique os processos de recompilação nos registros. Além disso, verifique o tamanho dos dados usando o comando nodetool status:

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

    Consultar 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 da resposta automática do repositório de dados da Apigee e execute o comando abaixo para aplicar a alteração

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

  12. Verificar o status do cluster do Cassandra

    O comando a seguir é útil para ver se a configuração do cluster foi bem-sucedida nos dois data centers. O comando verifica o status de nodetool das 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

Solução de problemas

Guia de suporte, diagnóstico e solução de problemas

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

Limpeza manual após o uso do forceDelete na configuração híbrida da Apigee multirregional

  • No exemplo a seguir, há duas regiões: us-east1 e us-west1.
  • Na região us-west1, o repositório de dados da Apigee foi excluído usando a exclusão forçada.
  • Na região us-east1, a cassandra ainda está funcionando.

  • Verifique se o apigeeds foi excluído usando o comando

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

  • Mude o contexto do kubectl para a outra região em que o cluster do cassandra ainda está em execução (aqui, us-east1).

  • Verificar se o repositório de dados está em execução

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

  • Executar em um dos pods da cassandra na região acima (aqui us-east1).

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

  • Verifique o status do nodetool. Ele mostrará todos os nós na região excluída (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   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 da região excluída (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 nenhum nó da região excluída (aqui us-west1) está disponível

    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

  • Depois disso, exclua o job de configuração de usuário na região superior (aqui, us-east1). O job será recriado automaticamente em 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 a conclusão do job de configuração do usuário

    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

  • Confirme que os keyspaces não estão na região excluída.

  • Criar um pod de depuração do cassandra.

    • Siga a versão híbrida 1.5+, siga a documentação do guia de solução de problemas do cassandra (por exemplo, para híbrido 1.5 - link, híbrido 1.6 - link) e faça a execução no pod criado

  • Faça login no cqlsh no pod de depuração usando o comando

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

  • Confirme que a região us-west1 foi removida de todos os keyspaces

    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)