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:
- Pré-lançamento
- Visão geral
- Pré-requisitos
- Instalação básica da Apigee híbrida
- Instalação híbrida personalizada da Apigee
- Fazer o download de arquivos de configuração
- Criar namespace
- Como usar imagens do Docker de repositórios particulares (opcional)
- Como configurar imagePullSecrets (opcional)
- Configurar proxy de encaminhamento (opcional)
- Como especificar certificados TLS de entrada
- Atualizar implantação de entrada
- Como configurar contas de serviço personalizadas do Google Cloud
- Como usar identidades de carga de trabalho
- Editar yaml de recursos
- Criar recursos de inicialização e um controlador
- Permitir que a conta de serviço do Syncer interaja com o plano de controle
- Criar componentes do plano de dados da Apigee
- Aguardar o início dos recursos
- Personalizar a instalação do cert-manager em um namespace personalizado
- Kustomize e componentes
- Conceitos
- Como entender o script
- Estrutura de pasta de configuração híbrida da Apigee
- Como armazenar chaves de conta de serviço em cofres externos
- Upgrade da Apigee híbrida
- Reversão híbrida da Apigee
- Limpar
- Como excluir um ambiente
- Instalação de várias instâncias
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.
Informações gerais
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:
- Configuração do projeto e da organização
- Visão geral dos pré-requisitos para instalar a Apigee híbrida.
- Etapa 1: ativar as APIs
- Etapa 2: criar uma organização
- Etapa 3: criar um ambiente e um grupo de ambientes
- 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 scriptapigee-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. 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 clusterCLUSTER_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órioapigee-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 é denominadainstance-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.
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
:
Clone o repositório:
git clone https://github.com/apigee/apigee-hybrid-install.git
Navegue até o diretório do repositório clonado:
cd apigee-hybrid-install
Crie uma ramificação com a tag Preview-1:
git branch preview-1 preview-1 git checkout preview-1
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:
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:
cd
no diretórioapigee-hybrid-install/
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:
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
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:
- 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.
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)
- 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.
- 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 componenteimagePullSecret
no arquivokustomization.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:
- usar certificados assinados por uma autoridade conhecida usando as etapas mencionadas em Receber certificados TLS: um exemplo | Apigee X
- ou gerar certificados autoassinados.
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.
- Edite o arquivo customization.yaml para a criação do certificado:
$INSTALL_DIR/overlays/initialization/certificates/kustomize.yaml
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
Salve o arquivo
Kustomize e componentes
Informações gerais
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çãoresources:
, 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
- OBRIGATÓRIO Adicione nomes de secrets relevantes à lista em
Uso:
- 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.
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
ouapigee-data
para o valor desejado.
- OPCIONAL mude o valor do identificador do seletor de nós de
Uso:
- 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.
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:
- 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.
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 entreHTTP
ouHTTPS
host
: REQUIRED o endereço do host do proxyport
: REQUIRED o número da porta.username
: OPTIONAL o nome de usuário associado ao seu proxypassword
: OPTIONAL a senha para acessar o proxy
Uso:
- 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.
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:
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
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.
- 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.
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.
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:
- As etapas da documentação já existente de Configurar o servidor e o SSH podem ser utilizadas.
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_I
P. A descrição corresponde aBACKUP_SERVER_IP
descrita aqui. - REQUIRED Altere o valor de BACKUP_STORAGE_DIR. A descrição corresponde a
BACKUP_STORAGE_DIR
descrita aqui.
- REQUIRED Mude o valor de
- components/non-gcs-restore/job-patch.yaml
- REQUIRED Mude o valor da variável de ambiente
BACKUP_SNAPSHOT_TIMESTAMP
. A descrição corresponde arestore:snapshotTimestamp
descrita aqui. - REQUIRED Mude o valor de
BACKUP_SERVER_IP
. A descrição corresponde aBACKUP_SERVER_IP
descrita aqui. - REQUIRED Mude o valor de
BACKUP_STORAGE_DIR
. A descrição corresponde aBACKUP_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}
- REQUIRED Mude o valor da variável de ambiente
Como realizar a restauração:
Para uma visão geral sobre como restaurar backups, consulte Visão geral da restauração do Cassandra.
- 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.
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.
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:
- 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.
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 acredential_name
descrita aqui.
- REQUIRED
Uso:
- 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.
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 acredential_name
descrita aqui.
- REQUIRED
Uso:
- 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.
Se você já tiver o Apigee Hybrid instalado, será necessário aplicar as novas alterações usando:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
Locais multirregionais
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}'
- REQUIRED
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
- REQUIRED
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.
- 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: Execute:
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.
Armazene o secret do certificado raiz em um arquivo:
kubectl get secret/apigee-root-certificate -n cert-manager -o yaml > apigee-root-certificate.yaml
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}
Crie o secret raiz no novo cluster:
kubectl -n cert-manager apply -f apigee-root-certificate.yaml
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.Remova a marca de comentário das seguintes linhas no arquivo
overlays/initialization/certificates/kustomization.yaml
:# components: # - ./components/disable-apigee-root-certificate-generation
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
Verifique o status de recriação usando o comando a seguir.
kubectl -n ${APIGEE_NAMESPACE} get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
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
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.
Removendo as seguintes linhas de
components/multi-region/patch.yaml
:properties: multiRegionSeedHost: {IP_ADDRESS} # To be modified. REQUIRED
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 campoversion
, 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 queIMAGE_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êinerapigee-runtime
, oIMAGE_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étricas | 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:
- Crie uma nova pasta no diretório de ambientes (ou como você tiver estruturado suas pastas)
- Copie o arquivo
apigee-environment.yaml
de qualquer ambiente para a nova pasta. - 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. - 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.
- Como aplicar as
yaml
s:
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.
Exclua
apigeeds
no namespaceapigee
:Kubectl delete -n apigee apigeeds default
Se essa etapa ficar presa, use CTRL + C para sair.
Edite um novo
apigeeds
:Kubectl edit -n apigee apigeeds default
Adicionar/atualizar o campo forceDelete na especificação do repositório de dados da Apigee
spec: forceDelete: true
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 namespaceapigee
. É 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 emgcloud
--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
Inicialização
namespaces.yaml
O namespace em que os componentes do plano de dados da Apigee serão instalados. O nome do namespace padrão é apigee
certificados
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 Secret
s 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 Secret
s 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 Secret
s 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
ferramentas
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.
- 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.
Siga as etapas em Instalar o gráfico do Helm do Vault, ou seja:
Adicionar o repositório Hashicorp ao comando
helm repo add hashicorp https://helm.releases.hashicorp.com
Atualizar repositórios do helm
helm repo update
Instalar o Vault
helm install vault hashicorp/vault \ --set "server.dev.enabled=true" \ --set "injector.enabled=false" \ --set "csi.enabled=true"
Agora armazenaremos o secret no Vault.
Receber um shell dentro do vault dev pod
kubectl exec -it vault-0 -- /bin/sh ```
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}"
Para verificar se a chave foi armazenada, use:
vault kv get secret/runtime-gcp-sa-key
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.
Receber um shell dentro do vault dev pod
kubectl exec -it vault-0 -- /bin/sh
Ativar método de autenticação do Kubernetes
vault auth enable kubernetes
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
Criar a política de autenticação
vault policy write apigee-runtime-app - <<EOF path "secret/data/runtime-gcp-sa-key" { capabilities = ["read"] } EOF
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.
Sair do shell dentro de vault-0
exit
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
Criar um recurso do Kubernetes
SecretProviderClass
que faça referência ao secret criado dentro do Vaultcat > 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
Aplique o
yaml
kubectl apply -f spc-vault.yaml
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
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"
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
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
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:
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:
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
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.
Reverter componentes do Kubernetes
Aplique as alterações para respostas automáticas da Apigee
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
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.
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:
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
.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
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}')
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}')
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:
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')
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
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}')
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}
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
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 instance1 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
- Copie a pasta $INSTANCE_NAME da instância atual e adicione-a na pasta "instances".
- Modifique o valor do campo de namespace se ele for diferente do namespace instance1.
- Siga as etapas especificadas em Como especificar certificados TLS de entrada para modificar a configuração de entrada da outra instância.
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
Defina o contexto do kubectl como o cluster original antes de recuperar o nome da propagação
kubectl config use-context original-cluster-name
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
Qualquer um dos IPs de pod retornados do comando anterior pode ser considerado o host de semente multirregional.
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
Defina o contexto como o cluster atual
kubectl config use-context existing-cluster-name
Exportar o secret da Apigee-ca para um arquivo
kubectl -n cert-manager get secret apigee-root-certificate -o yaml > apigee-root-certificate.yaml
Defina o contexto para o nome do cluster da nova região
kubectl config use-context NEW_CLUSTER_NAME
Importe o secret para o novo cluster
kubectl -n cert-manager apply -f apigee-root-certificate.yaml
Instale o ambiente híbrido na nova instância (região) seguindo as etapas descritas em Criar controlador e recursos de inicialização.
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"
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.
Aplique o CassandraDataReplication com o seguinte comando:
kubectl apply -f datareplication.yaml
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 }
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
Remova
multiRegionSeedHost
da resposta automática do repositório de dados da Apigee e execute o comando abaixo para aplicar a alteraçãokubectl apply k apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore
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
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
eus-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 comandokubectl 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ívelapigee@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.
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 keyspacesddl_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)