Guia do utilizador de pré-visualização:
pré-visualização dos novos procedimentos de instalação e administração para o Apigee hybrid v1.8.
Neste documento:
- Pré-visualizar
- Vista geral
- Pré-requisitos
- Instalação básica do Apigee Hybrid
- Instalação personalizada do Apigee Hybrid
- Transfira ficheiros de configuração
- Criar espaço de nomes
- Usar imagens de Docker de repositórios privados (opcional)
- Configurar imagePullSecrets (opcional)
- Configurar proxy de encaminhamento (opcional)
- Especificar certificados TLS de entrada
- Atualize a implementação de entrada
- Configurar contas de serviço personalizadas do Google Cloud
- Usar identidades de cargas de trabalho
- Edite ficheiros YAML de recursos
- Crie recursos de inicialização e um controlador
- Conceda autorizações à conta de serviço do sincronizador para interagir com o plano de controlo
- Crie componentes do plano de dados do Apigee
- Aguarde o início dos recursos
- Personalize a instalação do cert-manager num espaço de nomes personalizado
- Kustomize e componentes
- Conceitos
- Compreender o guião
- Estrutura de pastas de configuração do Apigee Hybrid
- Armazenar chaves de contas de serviço em cofres externos
- Atualização do Apigee Hybrid
- Reversão do Apigee Hybrid
- Limpeza
- Eliminar um ambiente
- Instalação de várias instâncias
Pré-visualização
Este documento destina-se à personagem do operador do Apigee (utilizadores que instalam/gerem/administram instalações híbridas do Apigee). A experiência na instalação do Apigee hybrid numa das plataformas Kubernetes suportadas é um pré-requisito para seguir as instruções neste documento. Recomendamos que crie uma organização do Apigee de avaliação para experimentar os passos abaixo.
Feedback
Envie feedback sobre este processo para Apigee-hybrid-install-preview@google.com.
Vista geral
A nova experiência de instalação do Apigee Hybrid instala componentes do Apigee através do kubectl e integra a instalação e a gestão do Apigee Hybrid com ferramentas de orquestração de configuração do Kubernetes, como o Kustomize. As validações e a visibilidade melhoradas dos componentes que estão a ser instalados oferecem uma melhor capacidade de depuração e melhoram o processo de instalação geral.
Um script de instalação, apigee-hybrid-setup.sh
, oferece uma ferramenta simples para a instalação básica. Pode usá-lo para criar a sua instalação híbrida e, em seguida, modificá-la para se adequar às suas necessidades com o kubectl
, ou pode criar a sua instalação híbrida do zero usando o kubectl
.
Todas as propriedades de configuração do Apigee hybrid são armazenadas em ficheiros YAML, um para cada componente principal. Isto permite um controlo muito mais detalhado da sua instalação híbrida no ambiente do Kubernetes. Pode encontrar os ficheiros de configuração e os scripts de instalação no repositório no GitHub.
Alterações no novo processo de instalação
O Apigee está a alterar o processo de instalação do Apigee Hybrid pelos seguintes motivos:
- O novo método de instalação do Apigee hybrid pode ser integrado com ferramentas de CI/CD do Kubernetes existentes, como o Argo, o Flux ou o Anthos Config Management, que não usam um ficheiro de configuração
overrides.yaml
. - O Apigee Hybrid forneceu
apigeectl
, uma ferramenta de criação de modelos personalizada que gera manifestos do Kubernetes (entre outras coisas) para instalar e gerir o Apigee Hybrid em clusters do Kubernetes. O novo processo de instalação e gestão oferece uma experiência semelhante à de outros fornecedores de software. - O novo processo permite uma instalação básica rápida através da criação automática de contas de serviço com as autorizações necessárias, certificados TLS, preenchimento prévio de valores predefinidos e outros elementos fundamentais necessários.
Pré-requisitos
Antes de usar esta instalação de pré-visualização, tem de cumprir os seguintes pré-requisitos:
Versão de pré-visualização
Esta pré-visualização destina-se a funcionar com a versão 1.8.x do Apigee Hybrid. As versões posteriores do Apigee hybrid não são suportadas.
Configuração do Apigee Hybrid
Antes de avançar com a instalação real do Apigee Hybrid, espera-se que tenha concluído as seguintes instruções indicadas nas secções seguintes da documentação:
- Configuração do projeto e da organização
- Vista geral dos pré-requisitos para instalar o Apigee Hybrid.
- Passo 1: ative as APIs
- Passo 2: crie uma organização
- Passo 3: crie um ambiente e um grupo de ambientes
- Configuração do tempo de execução híbrido
Ferramentas
Além disso, tem de ter as seguintes ferramentas transferidas e configuradas na sua estação de trabalho:
curl
- O
docker
é necessário para executar o scriptapigee-hybrid-setup.sh
. Siga as instruções em Obter Docker para instalar o Docker. - O comando
envsubst
deve estar disponível na maioria dos sistemas baseados em Linux/UNIX. Para o MacOS e outros sistemas, siga as instruções neste repositório. - A app
jq
deve estar instalada. Transfira o jq. kpt
Transferir kpt.kubectl
versão 1.23 ou mais recente. Consulte o artigo Instalar ferramentas: kubectl na documentação do Kubernetes.
Variáveis comuns usadas neste guia
Este guia usa as seguintes variáveis de ambiente em vários passos. Pode defini-los na linha de comandos ou com um script, ou pode substituir o texto nos comandos quando os introduz.
APIGEE_NAMESPACE
: o seu espaço de nomes do Apigee. Por predefinição, esta opção éapigee
. No entanto, pode usar um espaço de nomes diferente.CLUSTER_NAME
: o nome do cluster onde está a instalar o Apigee Hybrid. Este é o cluster que cria no Passo 1: crie um clusterCLUSTER_LOCATION
: a região do seu cluster. Os procedimentos neste guia pressupõem que está a usar um cluster regional. Se estiver a usar um cluster zonal, consulte as instruções no Passo 1: crie um clusterENV_GROUP
: o nome do grupo de ambientes para a sua instalação do Apigee Hybrid. Este é o grupo de ambientes que cria no Passo 3: crie um grupo de ambientes. Pode criar vários grupos de ambientes.ENV_NAME
: o nome do grupo de ambientes para a sua instalação do Apigee Hybrid. Este é o grupo de ambientes que cria no Passo 3: crie um grupo de ambientes. Pode criar vários grupos de ambientes.INSTALL_DIR
: o diretório onde instala o Apigee Hybrid. Por predefinição, este é o subdiretórioapigee-hybrid-install/
do diretório onde transfere o instalador, por exemplo:/myhybrid/apigee-hybrid-install/
. Este é o diretório de raiz da estrutura de ficheiros documentada em Estrutura de pastas de configuração do Apigee Hybrid.INSTANCE_DIR
: o diretório de uma instância híbrida específica do Apigee. Por predefinição, a primeira instância tem o nomeinstance-1
. O diretório da instância é um subdiretório de${INSTALL_DIR}/overlays/instances/
. Pode especificar qualquer nome para as suas instâncias híbridas. Consulte o artigo Instalação de várias instâncias.ORG_NAME
: o nome da sua organização do Apigee Hybrid. Tem de ser igual ao ID do seu projeto do Google Cloud. Consulte: Passo 2: crie uma organização.
Instalação básica do Apigee Hybrid
Para instalar rapidamente o Apigee Hybrid sem personalização complexa, pode usar o seguinte procedimento de dois passos.
- Um único ambiente
- Um único grupo de ambientes
- É criada e usada uma única conta de serviço do Google Cloud para todos os componentes individuais
- Valores predefinidos para todas as chaves de encriptação e palavras-passe.
Transfira ficheiros de configuração
Transfira e prepare os ficheiros de configuração clonando o repositório do GitHub em https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1
:
Clone o repositório:
git clone https://github.com/apigee/apigee-hybrid-install.git
Navegue para o diretório do repositório clonado:
cd apigee-hybrid-install
Crie uma ramificação a partir da etiqueta 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 tem uma estrutura semelhante à descrita em Estrutura de pastas de configuração do Apigee Hybrid:
Execute a configuração
Execute o script de shell apigee-hybrid-setup.sh
localizado na pasta tools/
.
./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION --org $ORG_NAME --setup-all
Se encontrar erros, experimente executar o script uma segunda vez.
Outras opções que pode querer usar:
--env $ENV_NAME
especifica o nome do ambiente do Apigee.--envgroup $ENV_GROUP
especifica o grupo de ambientes.--ingress-domain $HOSTNAME
especifica o nome do anfitrião que forneceu para o seu grupo de ambientes.--gcp-project-id $PROJECT_ID
especifica o ID do seu projeto do Google Cloud.
Para mais opções, consulte o artigo Compreender o script.
Todos os erros durante a execução são impressos na saída padrão.
Quando o script for concluído com êxito, terá concluído a instalação híbrida básica. Pode testar a instalação criando um proxy de exemplo, conforme detalhado no artigo Crie e implemente um novo proxy de API.
Instalação personalizada do Apigee Hybrid
Para utilizadores mais avançados que pretendam um controlo detalhado sobre a instalação, podem seguir esta sequência de passos (para muitos dos passos indicados abaixo, pode optar por realizar o passo manualmente ou usar o script de shell para automatizar esse passo individual):
Transfira ficheiros de configuração
Transfira e prepare os ficheiros de configuração:
Clone o repositório do GitHub em
https://github.com/apigee/apigee-hybrid-install/
O repositório clonado tem uma estrutura semelhante à descrita em Estrutura de pastas de configuração do Apigee Hybrid:
cd
para o diretórioapigee-hybrid-install/
Torne o script de configuração executável:
chmod +x ./tools/apigee-hybrid-setup.sh
Crie um espaço de nomes
Crie um espaço de nomes do Kubernetes no seu cluster que contenha todos os componentes do cluster do Apigee.
kubectl create namespace apigee
Se escolher outro nome para o espaço de nomes, pode optar por seguir uma das três opções abaixo:
- (Recomendado) Use
--namespace={YOUR_NAMESPACE_NAME}
ao pré-preencher valores em Editar YAMLs de recursos. Execute os dois comandos seguintes:
Use
kpt
para especificar o espaço de nomes do Apigee:kpt fn eval "${INSTALL_DIR}/overlays/" \ --image gcr.io/kpt-fn/apply-setters:v0.2.0 -- \ APIGEE_NAMESPACE="${APIGEE_NAMESPACE}" # This is for replacing the namespace in istio discoveryAddress which cannot be # achieved with kpt
Use
sed
para substituir o espaço de nomes em istio discoveryAddress:sed -i -E -e "s/(discoveryAddress: apigee-ingressgateway-manager\.).*(\.svc:15012)/\1${APIGEE_NAMESPACE}\2/" "${INSTALL_DIR}/overlays/controllers/istiod/apigee-istio-mesh-config.yaml"
Em alternativa, pode alterar manualmente os recursos individualmente para serem criados no espaço de nomes da sua escolha.
Usar imagens do Docker de repositórios privados (opcional)
Pode optar por não usar as imagens alojadas publicamente e usar imagens dos seus próprios repositórios privados:
- O primeiro passo é enviar todas as imagens para o seu repositório privado. Para tal, siga os passos descritos em apigee-pull-push | Apigee X. Por predefinição, as imagens são etiquetadas com a versão do Apigee Hybrid à qual correspondem, e é recomendável que não edite estas etiquetas. Também recomendamos que não edite os nomes das imagens para que o caminho da imagem final possa ser construído conforme explicado no centro de imagens.
Defina o valor do campo
imageHub
presente no ficheiro apigee-hybrid-config.yaml para o caminho do anfitrião do repositório privado. (Consulte o centro de imagens para ver detalhes).imageHub: "your.private.repo/apigee/hybrid"
Isto garante que todos os componentes do Apigee hybrid usam as imagens do seu repositório privado.
Além disso, também pode querer usar uma imagem privada para o controlador e o gateway de entrada do Apigee. Para tal, tem de editar os ficheiros apigee-controller-deployment.yaml e apigee-ingressgateway-manager-deployment.yaml e substituir todos os campos image
pela imagem do respetivo repositório privado.
Configurar imagePullSecrets (opcional)
- Crie um segredo do Kubernetes que contenha as credenciais para autenticação com os repositórios privados. Consulte o artigo Extraia uma imagem de um registo privado para compreender como o segredo tem de ser criado.
- Depois de criar o segredo, só tem de fazer referência a esse segredo. Para tal, edite o ficheiro apigee-hybrid-config.yaml e defina o valor do campo
imagePullSecret
para o nome do segredo criado anteriormente e ative o componenteimagePullSecret
no ficheirokustomization.yaml
correspondente.
Se especificar o imagePullSecrets
em ambos os locais, o presente no ficheiro apigee-controller-manager.yaml tem prioridade.
Configurar proxy de encaminhamento (opcional)
Os proxies de encaminhamento podem ser configurados adicionando o campo forwardProxy
ao ficheiro apigee-hybrid-config.yaml
. Por exemplo:
forwardProxy: |
scheme: HTTP
host: 10.12.0.47
port: 3128
Especificar certificados TLS de entrada
Usar o script
./tools/apigee-hybrid-setup.sh --create-ingress-tls-certs
Consulte o artigo Compreender o script para ver mais detalhes acerca desta sinalização.
Manual
Tem de fornecer certificados TLS que vão ser usados para o gateway de entrada do Istio. Pode:
- Usar certificados assinados por uma autoridade conhecida através dos passos mencionados em Obtenha certificados TLS: um exemplo | Apigee X
- Ou gerar certificados autoassinados.
Aqui, vamos usar certificados autoassinados como exemplo. Os certificados autoassinados podem ser gerados através de (partindo do princípio de que DOMAIN
foi definido corretamente e deve corresponder ao nome do anfitrião definido no seu grupo de ambiente):
openssl req -nodes -new -x509 -keyout ./tls.key -out ./tls.crt -subj '/CN='$DOMAIN'' -days 3650
Esta ação cria dois ficheiros com os nomes tls.key
e tls.crt
.
Em seguida, tem de criar um segredo com o seguinte formato. Pode usar kubectl create
ou kubectl apply
, conforme explicado em Usar um certificado/par de chaves personalizado para a autoridade de assinatura de certificados (opcional):
apiVersion: v1
kind: Secret
metadata:
name: "{ORG_NAME}-{ENV_GROUP_NAME}"
namespace: {$APIGEE_NAMESPACE}
type: Opaque
data:
cert: |
{BASE64_ENCODED_TLS_CRT}
key: |
{BASE64_ENCODED_TLS_KEY}
---
Exemplo de criação do segredo com kubectl create
:
kubectl create secret tls {ORG_NAME}-{ENV_GROUP_NAME} \
--cert="tls.crt" \
--key="tls.key" \
-n {$APIGEE_NAMESPACE}
Atualize a implementação de entrada
Para criar/modificar implementações de entrada, tem de modificar o campo spec.components.ingressGateways
no recurso personalizado ApigeeOrganization em bases/initialization/crds/customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
.
Por predefinição, criamos uma implementação de entrada com parâmetros predefinidos(os valores predefinidos são apresentados nos documentos de referência de CR ):
ingressGateways:
- name: "prod-1"
Exemplos:
A. Substituir campos do serviço de entrada
ingressGateways:
- name: "prod-1"
serviceSpec:
annotations:
{KEY}: ${VALUE}
loadBalancerIP: ${IP}
B. Altere o número mínimo/máximo de réplicas
ingressGateways:
- name: "prod-1"
autoScaler:
minReplicas: 4
maxReplicas: 10
C. Adicionar nova implementação de entrada
ingressGateways:
- name: "prod-1"
- name: "prod-2"
Configurar contas de serviço personalizadas do Google Cloud
Usar o script
./tools/apigee-hybrid-setup.sh --create-gcp-sa-and-secrets --namespace APIGEE_NAMESPACE
Onde APIGEE_NAMESPACE é o seu espaço de nomes personalizado. O espaço de nomes predefinido é apigee
.
Consulte o artigo Compreender o script para ver mais detalhes acerca das flags.
Manual
As chaves da conta de serviço do Google Cloud têm de ser armazenadas como segredos no cluster. O YAML secreto deve ter a seguinte estrutura:
apiVersion: v1
kind: Secret
metadata:
name: "{NAME}"
namespace: {APIGEE_NAMESPACE}
type: Opaque
data:
client_secret.json: |
{BASE64_ENCODED_SA_KEY}
Para mais detalhes sobre todas as contas de serviço necessárias e os nomes dos segredos, consulte a secção Contas de serviço do Google Cloud.
Pode escolher um nome diferente para os segredos, mas, em seguida, tem de fazer uma alteração correspondente no componente onde esse nome secreto foi usado. Por exemplo, se decidir alterar o nome do segredo da conta de serviço de tempo de execução de apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME}
para my-runtime-svc
, tem de fazer uma alteração correspondente no apigee-environment.yaml
para esse ambiente
Usar identidades de carga de trabalho
Uma das opções Configurar contas de serviço do Google Cloud personalizadas ou Usar identidades de carga de trabalho é obrigatória.
Pré-requisitos
Antes de usar identidades de cargas de trabalho, certifique-se de que o seu cluster do GKE tem o suporte ativado. Consulte o artigo Atualizar node pools | Apigee X para ver detalhes.
Ativar o Workload Identity
Consulte a secção Identidades de carga de trabalho em Kustomize e componentes para ver detalhes sobre como pode ativar as identidades de carga de trabalho antes da instalação.
Edite ficheiros YAML de recursos
Alguns locais nos ficheiros YAML dos componentes requerem a presença dos nomes corretos da organização, do ambiente e do grupo de ambientes. Pode definir estes valores manualmente ou usar o script de shell para preencher automaticamente estes valores.
Usar o script
./tools/apigee-hybrid-setup.sh --fill-values
Crie recursos de inicialização e um controlador
#Additional steps for openshift
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/openshift
//apigee datastore
kubectl apply -f ${INSTANCE_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/components/openshift-scc/scc.yaml
//telemetry
kubectl apply -f ${INSTANCE_DIR}/overlays/instances/${INSTANCE_DIR}/telemetry/components/openshift-scc/scc.yaml
#Create Apigee initialization kubernetes resources
kubectl apply -f ${INSTALL_DIR}/overlays/initialization/namespace.yaml
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/certificates
kubectl apply --server-side --force-conflicts -k ${INSTALL_DIR}/overlays/initialization/crds
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/webhooks
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/rbac
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/ingress
# Create controller config and controller
kubectl apply -k ${INSTALL_DIR}/overlays/controllers
# Wait for the controllers to be available
kubectl wait deployment/apigee-controller-manager deployment/apigee-ingressgateway-manager -n "${APIGEE_NAMESPACE}" --for=condition=available --timeout=2m
# Create the datastore and redis secrets first and then the rest of the secrets.
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/redis/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/${ENV_NAME}/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/organization/secrets.yaml
Conceda autorizações à conta de serviço do sincronizador para interagir com o plano de controlo
Siga os passos no Passo 8: ative o acesso do sincronizador,
substituindo o nome da conta de serviço, apigee-non-prod
ou apigee-synchronizer
, por
apigee-all-sa
, o nome da conta de serviço criada pelo novo processo de instalação.
★ Importante: certifique-se de que altera o nome da conta de serviço nas instruções em Ative o acesso do sincronizador. Caso contrário, a ativação do acesso para o sincronizador falha.
Crie componentes do plano de dados do Apigee
Se tiver alterado os nomes de algum dos recursos nos passos anteriores, tem de fazer uma alteração correspondente noutros ficheiros YAML onde esse recurso foi referenciado. Quando terminar, use os comandos no seguinte exemplo:
# Create the rest of the resources.
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
para instalar todos os componentes.
Aguarde que os recursos sejam iniciados
kubectl wait "apigeedatastore/default" \
"apigeeredis/default" \
"apigeeenvironment/${ORG_NAME}-${ENV_NAME}" \
"apigeeorganization/${ORG_NAME}" \
"apigeetelemetry/apigee-telemetry" \
-n "${APIGEE_NAMESPACE}" --for="jsonpath=.status.state=running" --timeout=15m
Personalize a instalação do cert-manager num espaço de nomes personalizado
Personalize o espaço de nomes onde o cert-manager está a ser executado com o seguinte procedimento.
Se o cert-manager estiver instalado no cluster num espaço de nomes diferente de cert-manager, tem de atualizar o espaço de nomes usado para criar o certificado de raiz do Apigee.
- Edite o ficheiro customization.yaml para a criação de certificados:
$INSTALL_DIR/overlays/initialization/certificates/kustomize.yaml
Adicione o seguinte ao final do ficheiro.
- patch: |- - op: replace path: /metadata/namespace value: "gk-cert-manager" target: group: cert-manager.io version: v1 kind: Certificate name: apigee-root-certificate
Guarde o ficheiro
Kustomize e componentes
Vista geral
A nova instalação híbrida herda a ideologia do Kustomize de estruturar ficheiros YAML sob a forma de bases e sobreposições
- As bases são ficheiros fornecidos pela Apigee, que podem mudar entre cada novo lançamento do Hybrid. Não deve modificar estes ficheiros. Estes ficheiros contêm alguns valores predefinidos fornecidos pelo Apigee. Todos os ficheiros na pasta
bases/
de nível superior contêm estas bases As sobreposições contêm a configuração do utilizador e servem como meio através do qual pode modificar os valores predefinidos especificados nas bases. Todos os ficheiros na pasta
overlays/
de nível superior contêm estas sobreposições
Como usar os componentes
As subpastas no diretório de nível superior overlays/
foram estruturadas de forma que pode ativar (ou desativar) uma determinada funcionalidade adicional comentando (ou descomentando) determinadas linhas nos ficheiros kustomization.yaml
.
Por exemplo, é assim que se apresenta a estrutura de pastas overlays/instances/{INSTANCE_NAME}/telemetry
:
telemetry
├── components
│ ├── http-proxy
│ ├── imagepullsecret
│ ├── logger
│ ├── metrics
│ ├── nodeselector
│ ├── openshift-scc
│ ├── workload-identity-logger
│ └── workload-identity-metrics
├── apigee-telemetry.yaml
└── kustomization.yaml
Veja como os ficheiros telemetry/kustomization.yaml
provavelmente seriam apresentados por predefinição:
resources:
- apigee-telemetry.yaml
components:
- ./components/metrics
# - ./components/workload-identity-metrics
# - ./components/logger
# - ./components/workload-identity-logger
# - ./components/http-proxy
# - ./components/nodeselector/
# - ./components/imagepullsecret
# - ./components/openshift-scc
Podemos ver que a linha ./components/logger
foi comentada, o que significa simplesmente que não ativámos o registador do Google Cloud por predefinição. Para o ativar, basta remover o comentário dessa linha da seguinte forma:
components:
- ./components/logger
Da mesma forma, para desativar métricas, pode comentar a linha ./components/metrics
:
...
components:
...
# - ./components/metrics
…
As secções seguintes abordam todos estes componentes diferentes, quando podem ser usados e como podem ser configurados.
OpenShift
Para os utilizadores que pretendem instalar o Apigee Hybrid num cluster OpenShift
, pode ter de ativar alguns componentes/recursos antes de realizar a instalação. (Isto é necessário se não usar o script para fazer a instalação). Os ficheiros que têm de ser modificados são:
overlays/initialization/openshift/kustomization.yaml
. Na secçãoresources:
, descomente:# - ../../../bases/initialization/openshift/
overlays/instances/{INSTANCE_NAME}/datastore/kustomization.yaml
Descomentar:# - ./components/openshift-scc
e descomente o campo "
components:
" se ainda estiver comentado.overlays/instances/{INSTANCE_NAME}/telemetry/kustomization.yaml
Descomentar:# - ./components/openshift-scc
e descomente o campo "
components:
" se ainda estiver comentado.
Em seguida, pode avançar com os passos de instalação.
imagepullsecret
Este componente pode ser ativado quando tiver imagens armazenadas no seu repositório privado. Para extrair imagens de um repositório privado, pode criar um segredo do Kubernetes que tenha os seus detalhes de autenticação e, em seguida, referenciar este segredo no interior. Consulte o artigo Configurar imagePullSecrets (opcional) para obter instruções. Consulte o artigo Extrair uma imagem de um registo privado | Kubernetes na documentação do Kubernetes para mais informações.
Disponível nos seguintes países:
overlays/controllers/apigee-controller
overlays/controllers/istiod
overlays/instances/{INSTANCE_NAME}/datastore
overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
overlays/instances/{INSTANCE_NAME}/organization
overlays/instances/{INSTANCE_NAME}/redis
overlays/instances/{INSTANCE_NAME}/telemetry
Ativação:
Descomente a linha "./components/imagepullsecret/
" nos ficheiros kustomization.yaml
respetivos sempre que necessário.
Modificações a serem feitas:
- components/imagepullsecret/patch.yaml
- OBRIGATÓRIO Adicione nomes de segredos relevantes à lista em
spec.template.spec.imagePullSecrets
- OBRIGATÓRIO Adicione nomes de segredos relevantes à lista em
Utilização:
- Se ainda não instalou o Apigee Hybrid, pode continuar com os passos de instalação e estas alterações são aplicadas no processo
Se já tiver o Apigee Hybrid instalado, tem de aplicar estas novas alterações através do seguinte:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
nodeselector
Este componente permite-lhe agendar pods para um recurso do Apigee em nós específicos. Consulte o artigo Atribuir pods a nós | Kubernetes para ver informações adicionais.
Disponível nos seguintes países:
overlays/controllers/apigee-controller
overlays/controllers/istiod
overlays/instances/{INSTANCE_NAME}/datastore
overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
overlays/instances/{INSTANCE_NAME}/organization
overlays/instances/{INSTANCE_NAME}/redis
overlays/instances/{INSTANCE_NAME}/telemetry
Ativação:
Descomente a linha "./components/nodeselector
" nos ficheiros kustomization.yaml
respetivos sempre que necessário.
Modificações a serem feitas:
- components/nodeselector/patch.yaml
- OPCIONAL Altere o valor da etiqueta do seletor de nós de
apigee-runtime
ouapigee-data
para o desejado.
- OPCIONAL Altere o valor da etiqueta do seletor de nós de
Utilização:
- Se ainda não instalou o Apigee Hybrid, pode continuar com os passos de instalação e estas alterações são aplicadas no processo
Se já tiver o Apigee Hybrid instalado, tem de aplicar estas novas alterações através do seguinte:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
workload-identity
Vários contentores no ecossistema híbrido do Apigee requerem autorizações para fazer determinadas chamadas API para o plano de controlo / plano de gestão do Apigee. A identidade de carga de trabalho é uma das formas de conceder estas autorizações aos pods (e aos contentores no interior). Seguem-se alguns recursos úteis para ler mais sobre este assunto: - Apresentamos o Workload Identity: melhor autenticação para as suas aplicações do GKE | Blogue do Google Cloud - Use o Workload Identity | Documentação do Kubernetes Engine | Google Cloud
Disponível nos seguintes países:
overlays/instances/{INSTANCE_NAME}/datastore
overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
overlays/instances/{INSTANCE_NAME}/organization
overlays/instances/{INSTANCE_NAME}/redis
overlays/instances/{INSTANCE_NAME}/telemetry
Pré-requisito:
Antes de poder usar a identidade da carga de trabalho, tem de conceder as autorizações relevantes no seu projeto do Google Cloud através do seguinte comando:
gcloud iam service-accounts add-iam-policy-binding \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:${ORG_NAME}.svc.id.goog[${APIGEE_NAMESPACE}/${KSA_NAME}]" \
${GSA_NAME}@${ORG_NAME}.iam.gserviceaccount.com
onde:
- ${ORG_NAME} - O nome da sua organização do Apigee.
- ${APIGEE_NAMESPACE} – O espaço de nomes do Kubernetes onde os componentes do Apigee foram instalados. Normalmente, é apigee
, a menos que o utilizador o altere explicitamente durante a instalação
- ${KSA_NAME} - O nome do espaço de nomes do Kubernetes. Tem de executar este comando para cada conta de serviço do Kubernetes mencionada em Contas de serviço do Kubernetes
- ${GSA_NAME} - O nome da conta de serviço do Google Cloud. Se não tiver feito alterações durante a instalação, este parâmetro tem o valor apigee-all-sa
. Se configurar várias contas de serviço do Google Cloud para componentes individuais, tem de fazer corresponder o KSA_NAME ao GSA_NAME correspondente. Pode comparar as tabelas em contas de serviço do Google Cloud com contas de serviço do Kubernetes para encontrar os equivalentes.
Ativação:
Descomente a linha ./components/workload-identity
nos ficheiros kustomization.yaml
respetivos sempre que necessário. Tenha em atenção que, na telemetria, temos suplementos de identidade de carga de trabalho separados para os componentes metrics
e logger
, que podem ser ativados individualmente.
Utilização:
- Se ainda não instalou o modo híbrido, pode simplesmente ativar a workload-identity, conforme mencionado na secção anterior, e continuar com a instalação, que irá usar automaticamente a workload-identity.
Se já tiver o Apigee Hybrid instalado, tem de aplicar estas novas alterações através do seguinte:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
http-proxy
Pode configurar um servidor proxy em cada um dos seguintes componentes para que o tráfego desse componente passe pelo proxy HTTP configurado para esse componente. Pode configurar o proxy para cada componente do Apigee individualmente.
Disponível nos seguintes países:
overlays/instances/{INSTANCE_NAME}/datastore
overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
overlays/instances/{INSTANCE_NAME}/organization
overlays/instances/{INSTANCE_NAME}/telemetry
Ativação:
Descomente a linha "./components/http-proxy/
" nos ficheiros kustomization.yaml
respetivos sempre que necessário.
Modificações a serem feitas:
- components/http-proxy/patch.yaml
Pode configurar os seguintes parâmetros em
spec.httpForwardProxy
scheme
: OBRIGATÓRIO Um deHTTP
ouHTTPS
host
: OBRIGATÓRIO O endereço do anfitrião do seu proxyport
: OBRIGATÓRIO O número da portausername
: OPCIONAL O nome de utilizador associado ao seu proxypassword
: OPCIONAL A palavra-passe para aceder ao proxy
Utilização:
- Se ainda não instalou o Apigee Hybrid, pode continuar com os passos de instalação e estas alterações são aplicadas no processo
Se já tiver o Apigee Hybrid instalado, tem de aplicar estas novas alterações através do seguinte:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
logger e métricas
Pode ativar ou desativar individualmente o registador ou as métricas em overlays/instances/{INSTANCE_NAME}/telemetry. Por predefinição, o registador está desativado e as métricas estão ativadas. Para ativá-las ou desativá-las, basta remover ou adicionar o comentário às respetivas linhas no ficheiro telemetry/kustomization.yaml
gcs-backup e gcs-restore
Este componente do Kustomize pode ser usado para fazer uma cópia de segurança e restaurar a base de dados Cassandra no Google Cloud Storage.
Disponível nos seguintes países:
overlays/instances/{INSTANCE_NAME}/datastore
Pré-requisito:
Transfira as chaves das contas de serviço do Google Cloud para uma conta que tenha a função de administrador de objetos de armazenamento.
- Se usou o script para fazer a instalação e não usou identidades de carga de trabalho, pode reutilizar as chaves transferidas disponíveis na pasta service-accounts criada pelo script.
Também pode usar o script create-service-account.sh para criar uma nova conta de serviço e transferir as respetivas chaves:
./tools/create-service-accounts=.sh --env prod --profile apigee‑cassandra
Depois de transferir as chaves, tem de criar um segredo do Kubernetes com o nome apigee-cassandra-backup-and-restore-gcp-sa-key, o que pode fazer através do comando:
kubectl create secret generic "apigee-cassandra-backup-and-restore-gcp-sa-key" \ --from-file="dbbackup_key.json=${PATH_TO_SA_KEY}" \ -n "${APIGEE_NAMESPACE}"
Onde:
- ${PATH_TO_SA_KEY} - Caminho para o ficheiro que contém as chaves da conta de serviço.
- ${APIGEE_NAMESPACE}: o espaço de nomes do Kubernetes onde os componentes do Apigee foram instalados. Normalmente, este é o valor de apigee, a menos que tenha sido alterado explicitamente durante a instalação
Em alternativa, pode usar os modelos de ficheiros templates/secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml para criar este segredo.
Ativação:
- Se quiser ativar a cópia de segurança, descomente a linha "./components/gcs-backup" no ficheiro datastore kustomization.yaml.
- Se quiser restaurar uma cópia de segurança, descomente a linha "./components/gcs-restore" no ficheiro datastore kustomization.yaml.
Modificações apenas para cópia de segurança
- components/gcs-backup/apigee-datastore-patch.yaml
- OBRIGATÓRIO: altere o valor da variável de ambiente DATABASE_STORAGE_BUCKET, que terá o formato gs://BUCKET_NAME e aponta para o contentor do Google Cloud Storage onde os dados têm de ser copiados. A descrição corresponde a dbStorageBucket descrito aqui.
- components/gcs-backup/cron-patch.yaml
- OBRIGATÓRIO Altere spec.schedule para especificar a frequência da cópia de segurança. O campo aceita o formato de agendamento Crontab padrão. A descrição corresponde à programação descrita aqui.
- OBRIGATÓRIO: altere o valor da variável de ambiente DATABASE_STORAGE_BUCKET, que terá o formato gs://BUCKET_NAME e aponta para o contentor do Google Cloud Storage onde os dados têm de ser copiados. A descrição corresponde a dbStorageBucket descrito aqui.
- OPCIONAL Altere o valor de HTTP_PROXY_URL para apontar para qualquer proxy configurado. O formato pode ser o seguinte:
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS>:${HOST_PORT}
A fazer cópia de segurança
Pode fazer a cópia de segurança com o seguinte comando:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
Para aplicar as alterações e ativar a cópia de segurança:
Modificações apenas para restauro
- components/gcs-restore/apigee-datastore-patch.yaml
- OBRIGATÓRIO: altere o valor da variável de ambiente DATABASE_STORAGE_BUCKET, que terá o formato gs://BUCKET_NAME e aponta para o contentor do Google Cloud Storage onde os dados têm de ser copiados. A descrição corresponde a dbStorageBucket, descrito aqui.
- components/gcs-restore/job-patch.yaml
- OBRIGATÓRIO: altere o valor da variável de ambiente DATABASE_STORAGE_BUCKET, que terá o formato gs://BUCKET_NAME e aponta para o contentor do Google Cloud Storage onde os dados têm de ser copiados.
- OBRIGATÓRIO Altere o valor da variável de ambiente BACKUP_SNAPSHOT_TIMESTAMP. A descrição corresponde a restore:snapshotTimestamp descrito aqui.
- OPCIONAL Altere o valor de HTTP_PROXY_URL para apontar para qualquer proxy configurado.
O formato pode ser o seguinte:
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
Realizar o restauro:
Para informações gerais sobre o restauro de cópias de segurança, consulte o artigo Restaurar cópias de segurança | Apigee X | Google Cloud
- Crie um novo cluster do Kubernetes com um novo espaço de nomes no qual restaurar a implementação do tempo de execução híbrido. Não pode usar o mesmo cluster e espaço de nomes que usou para a instalação híbrida original.
Instale o Hybrid no novo cluster com as definições configuradas acima, além de quaisquer outras definições que pretender:
- Pode usar a instalação básica e instalar o híbrido no novo espaço de nomes:
./tools/apigee-hybrid-setup.sh \ --cluster-name $CLUSTER_NAME \ --cluster-region $CLUSTER_LOCATION \ --namespace ${NEW_APIGEE_NAMESPACE}
- Em alternativa, siga a instalação personalizada do Apigee Hybrid para configurar as opções à sua escolha.
Assim que a restauração estiver concluída, todos os recursos no espaço de nomes antigo podem ser eliminados e mudados para o novo espaço de nomes.
Para mais informações, consulte o artigo Restaurar cópias de segurança.
non-gcs-backup e non-gcs-restore
Este componente do Kustomize pode ser usado para fazer uma cópia de segurança e restaurar a base de dados Cassandra no Google Cloud Storage.
Disponível nos seguintes países:
overlays/instances/{INSTANCE_NAME}/datastore
Pré-requisito:
- Pode usar os passos da documentação já existente para configurar o servidor e o SSH.
Nos passos acima, tem de usar a chave privada SSH que está disponível no ficheiro "ssh_key" gerado seguindo os passos anteriores. Em seguida, criamos um segredo do Kubernetes com o nome apigee-cassandra-backup-and-restore-gcp-sa-key, que contém esta chave privada SSH.
O segredo do Kubernetes pode ser criado através do seguinte comando:
kubectl create secret generic "apigee-cassandra-backup-and-restore-key-file" \ --from-file="key=${PATH_TO_SSH_PRIVATE_KEY}" \ -n "${APIGEE_NAMESPACE}"
Onde:
- ${PATH_TO_SSH_PRIVATE_KEY} - Caminho para o ficheiro que contém a chave privada de SSH
- ${APIGEE_NAMESPACE}: o namespace do Kubernetes onde os componentes do Apigee foram instalados. Normalmente, este é o valor de apigee, a menos que tenha sido alterado explicitamente durante a instalação
Em alternativa, pode usar o ficheiro de modelo templates/secret-apigee-cassandra-backup-and-restore-key-file.yaml para criar este segredo.
Ativação:
- Se quiser ativar a cópia de segurança, descomente a linha "
./components/non-gcs-backup
" no ficheiro datastore kustomization.yaml. - Se quiser restaurar uma cópia de segurança, descomente a linha "
./components/non-gcs-restore
" no ficheiro datastore kustomization.yaml.
Modificações apenas para cópia de segurança
- components/non-gcs-backup/apigee-datastore-patch.yaml
- OBRIGATÓRIO Altere o valor de BACKUP_SERVER_IP. A descrição corresponde ao BACKUP_SERVER_IP descrito aqui.
- OBRIGATÓRIO Altere o valor de BACKUP_STORAGE_DIR. A descrição corresponde a BACKUP_STORAGE_DIR descrito aqui.
- components/non-gcs-backup/cron-patch.yaml
- OBRIGATÓRIO Altere spec.schedule para especificar a frequência da cópia de segurança. O campo aceita o formato de agendamento Crontab padrão. A descrição corresponde à programação descrita aqui.
- OBRIGATÓRIO Altere o valor de BACKUP_SERVER_IP. A descrição corresponde ao BACKUP_SERVER_IP descrito aqui.
- OBRIGATÓRIO Altere o valor de BACKUP_STORAGE_DIR. A descrição corresponde a BACKUP_STORAGE_DIR descrito aqui.
- OPCIONAL Altere o valor de HTTP_PROXY_URL para apontar para qualquer proxy configurado. O formato pode ser o seguinte:
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
A fazer cópia de segurança
Pode fazer a cópia de segurança com o seguinte comando:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
Para aplicar as alterações e ativar a cópia de segurança:
Modificações apenas para cópia de segurança
- components/non-gcs-restore/apigee-datastore-patch.yaml
- REQUIRED Altere o valor de
BACKUP_SERVER_I
P. A descrição corresponde aoBACKUP_SERVER_IP
descrito aqui. - OBRIGATÓRIO Altere o valor de BACKUP_STORAGE_DIR. A descrição corresponde ao
BACKUP_STORAGE_DIR
descrito aqui.
- REQUIRED Altere o valor de
- components/non-gcs-restore/job-patch.yaml
- OBRIGATÓRIO: altere o valor da variável de ambiente
BACKUP_SNAPSHOT_TIMESTAMP
. A descrição corresponde aorestore:snapshotTimestamp
descrito aqui. - REQUIRED Altere o valor de
BACKUP_SERVER_IP
. A descrição corresponde aoBACKUP_SERVER_IP
descrito aqui. - REQUIRED Altere o valor de
BACKUP_STORAGE_DIR
. A descrição corresponde aoBACKUP_STORAGE_DIR
descrito aqui. - OPCIONAL Altere o valor de
HTTP_PROXY_URL
para apontar para qualquer proxy configurado. O formato pode ser o seguinte:http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
- OBRIGATÓRIO: altere o valor da variável de ambiente
Realizar o restauro:
Para uma vista geral sobre o restauro de cópias de segurança, consulte o artigo Vista geral do restauro do Cassandra.
- Crie um novo cluster do Kubernetes com um novo espaço de nomes no qual restaurar a implementação do tempo de execução híbrido. Não pode usar o mesmo cluster e espaço de nomes que usou para a instalação híbrida original.
Instale o Hybrid no novo cluster com as definições configuradas acima, além de quaisquer outras definições que pretender: Pode usar a instalação básica e instalar o Hybrid no novo espaço de nomes:
./tools/apigee-hybrid-setup.sh \ --cluster-name $CLUSTER_NAME \ --cluster-region $CLUSTER_LOCATION \ --namespace ${NEW_APIGEE_NAMESPACE}
Em alternativa, siga a instalação personalizada do Apigee Hybrid para configurar as opções à sua escolha.
Assim que a restauração estiver concluída, todos os recursos no espaço de nomes antigo podem ser eliminados e mudados para o novo espaço de nomes.
Para mais informações, consulte o artigo Programar cópias de segurança num servidor remoto.
http-client
Para ver instruções, consulte o artigo Ative clientes HTTP | Apigee.
Disponível nos seguintes países:
- overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}
Ativação:
Descomente a linha "./components/http-client
" no ficheiro route-config/${ENV_GROUP}/kustomization.yaml
respetivo
Modificações a serem feitas:
- Não são necessárias modificações obrigatórias.
Utilização:
- Se ainda não instalou o Apigee Hybrid, pode continuar com os passos de instalação e estas alterações são aplicadas no processo
Se já tiver o Apigee Hybrid instalado, tem de aplicar estas novas alterações através do seguinte:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
non-sni-client
Equivalente ao artigo já existente Como configurar um cliente não SNI | Apigee.
Disponível nos seguintes países:
- overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}
Ativação:
Descomente a linha "./components/non-sni-client
" no ficheiro route-config/${ENV_GROUP}/kustomization.yaml
respetivo
Modificações a serem feitas:
- components/non-sni-client/apigee-route.yaml
- OBRIGATÓRIO
credentialName
A descrição corresponde aocredential_name
descrito aqui.
- OBRIGATÓRIO
Utilização:
- Se ainda não instalou o Apigee Hybrid, pode continuar com os passos de instalação e estas alterações são aplicadas no processo
Se já tiver o Apigee Hybrid instalado, tem de aplicar estas novas alterações através do seguinte:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
http-and-non-sni-client
Para ver instruções, consulte o artigo Ative o suporte para clientes HTTP e não SNI | Apigee.
Ativação:
Descomente a linha "./components/http-and-non-sni-client
" no ficheiro route-config/${ENV_GROUP}/kustomization.yaml
respetivo
Modificações a serem feitas:
- components/http-and-non-sni-client/apigee-route.yaml
- OBRIGATÓRIO
credentialName
A descrição corresponde aocredential_name
descrito aqui.
- OBRIGATÓRIO
Utilização:
- Se ainda não instalou o Apigee Hybrid, pode continuar com os passos de instalação e estas alterações são aplicadas no processo
Se já tiver o Apigee Hybrid instalado, tem de aplicar estas novas alterações através do seguinte:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
multirregião
Este componente pode ser usado ao configurar uma implementação do Cassandra em várias regiões. Para mais informações, consulte o artigo Implementação em várias regiões no GKE e GKE on-prem
Ativação:
Descomente a linha "./components/multi-region
" no ficheiro datastore/kustomization.yaml
Modificações a serem feitas:
components/multi-region/cassandra-data-replication.yaml
- OBRIGATÓRIO
source.region
O nome do centro de dados do Cassandra de origem que vai ser usado para replicar dados. Pode ser identificado através do seguinte comando no cluster de origem:
kubectl get apigeedatastore -n ${APIGEE_NAMESPACE} -o=jsonpath='{.items[*].spec.components.cassandra.properties.datacenter}'
- OBRIGATÓRIO
components/multi-region/patch.yaml
- OBRIGATÓRIO
spec.components.properties.multiRegionSeedHost
O IP do agrupamento de qualquer um dos agrupamentos cassandra de origem. Podemos usar:
kubectl get pods -n ${APIGEE_NAMESPACE} -o wide
- Para apresentar uma lista de todos os pods e obter o IP de qualquer pod do Cassandra, use o seguinte comando:
kubectl get pods -o wide -n apigee
O resultado deve ter um aspeto semelhante ao seguinte:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE apigee-cassandra-default-0 1/1 Running 0 5d 10.0.0.11 gke-k8s-dc-2-default-pool-a2206492-p55d apigee-cassandra-default-1 1/1 Running 0 5d 10.0.2.4 gke-k8s-dc-2-default-pool-e9daaab3-tjmz apigee-cassandra-default-2 1/1 Running 0 5d 10.0.3.5 gke-k8s-dc-2-default-pool-e589awq3-kjch
- OBRIGATÓRIO
Para mais informações, consulte os pré-requisitos para o GKE em "Implementação em várias regiões no GKE, GKE on-prem e AKS":
Utilização:
A utilização deste componente faz sentido principalmente quando está a configurar o Apigee Hybrid num novo cluster e já tem outra configuração funcional do Apigee Hybrid.
- O novo cluster e o cluster existente têm de usar os mesmos certificados TLS para garantir a comunicação adequada entre os pods do Cassandra. Por isso, temos de copiar o segredo
apigee-root-certificate
do cluster existente e usá-lo também no mais recente: Corrida:
kubectl config get-contexts
- Para obter uma lista de todos os contextos do Kubernetes e, em seguida, executar
kubectl config use-context SOURCE_CLUSTER_CONTEXT
em que SOURCE_CLUSTER_CONTEXT é o nome do contexto do cluster do Kubernetes de origem.
Armazene o Secret do certificado de raiz num ficheiro:
kubectl get secret/apigee-root-certificate -n cert-manager -o yaml > apigee-root-certificate.yaml
Mude o contexto do cluster para o novo cluster onde está a instalar o Apigee Hybrid.
kubectl config use-context ${NEW_CLUSTER_CONTEXT}
Crie o segredo principal no novo cluster:
kubectl -n cert-manager apply -f apigee-root-certificate.yaml
Desative a criação de um novo certificado de raiz. Isto garante que não criamos um novo
apigee-root-certificate
e acabamos por substituir o que criámos no passo anterior.Descomente as seguintes linhas no ficheiro
overlays/initialization/certificates/kustomization.yaml
:# components: # - ./components/disable-apigee-root-certificate-generation
Continue com o resto da instalação do Apigee Hybrid através da instalação básica do Apigee Hybrid ou da instalação personalizada do Apigee Hybrid. Por exemplo, após a instalação híbrida básica do Apigee, pode executar:
./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION
Valide o estado da reconstrução através do seguinte comando.
kubectl -n ${APIGEE_NAMESPACE} get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
Valide os processos de reconstrução a partir dos registos. Além disso, verifique o tamanho dos dados através do comando nodetool status:
kubectl logs apigee-cassandra-default-0 -f -n ${APIGEE_NAMESPACE} kubectl exec apigee-cassandra-default-0 -n ${APIGEE_NAMESPACE} -- nodetool -u ${JMX_USER} -pw ${JMX_PASSWORD} status
Valide o estado da reconstrução através do seguinte comando.
kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
Os resultados devem ter um aspeto semelhante ao seguinte:
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }
Veja também: Implementação em várias regiões.
Remover 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
Image Hub
Geralmente, as imagens de contentores do Docker são especificadas no formato:
${REGISTRY_HOST_PATH}/${IMAGE_NAME}:${IMAGE_TAG}
ou que usam um resumo, como:
${REGISTRY_HOST_PATH}/${IMAGE_NAME}@${DIGEST}
O Apigee usa o conceito de "Image Hub", que nos formatos acima se refere a ${REGISTRY_HOST_PATH}
. O valor predefinido do hub de imagens é gcr.io/apigee-release/hybrid/
.
(As imagens que usam o DIGEST têm de ser definidas individualmente em cada subcomponente)
O Apigee cria o caminho da imagem final combinando o valor do seguinte:
- "Image Hub", que pode ser substituído em apigee-hybrid-config.yaml (consulte a secção Usar imagens do Docker de repositórios privados para ver passos detalhados sobre como substituir o Image Hub).
- O valor de
IMAGE_TAG
é obtido a partir do campoversion
, que está presente no ficheiro YAML para cada um dos componentes individuais (por exemplo, apigee-organization.yaml). O Apigee etiqueta as imagens com a versão do Apigee Hybrid, o que significa queIMAGE_TAG
é 1.8 para a versão 1.8 do Apigee Hybrid IMAGE_NAME
é determinado implicitamente a partir do nome do contentor onde a imagem vai ser usada. Por exemplo, para o contentorapigee-runtime
, oIMAGE_NAME
é apigee-runtime.
Assim, um exemplo completo de um caminho de imagem seria gcr.io/apigee-release/hybrid/apigee-runtime:1.8.0
Desta forma, é construído o caminho da imagem final, que seria usado em cada um dos contentores nos respetivos pods.
Contas de serviço do Google Cloud
As contas de serviço do Google Cloud são contas usadas pelas aplicações para fazer chamadas autorizadas para APIs Google. As chaves da conta de serviço do Google Cloud podem ser transferidas e, em seguida, usadas para fins de autenticação. O Apigee espera que o utilizador forneça chaves de contas de serviço através da criação de segredos. Seguem-se os nomes dos componentes e o nome predefinido do segredo onde procura chaves de contas de serviço:
Componente | Subcomponente | Nome do segredo do Kubernetes predefinido que contém a chave da conta de serviço |
---|---|---|
organização | ||
connectAgent | apigee-connect-agent-gcp-sa-key-${ORG_NAME} |
|
observador | apigee-watcher-gcp-sa-key-${ORG_NAME} |
|
mart | apigee-mart-gcp-sa-key-${ORG_NAME} |
|
udca | apigee-udca-gcp-sa-key-${ORG_NAME} |
|
ingressGateways | N/A | |
ambiente | ||
tempo de execução | apigee-runtime-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
udca | apigee-udca-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
sincronizador | apigee-synchronizer-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
telemetry | ||
métricas | apigee-metrics-gcp-sa-key |
|
containerLogs | apigee-logger-gcp-sa-key |
Contas de serviço do Kubernetes
As contas de serviço do Kubernetes fornecem identidades aos pods no seu cluster. Por predefinição, o controlador do Apigee cria-os por si. No entanto, se quiser substituir a criação (por exemplo, quando estiver a usar identidades de carga de trabalho), pode fazê-lo especificando o campo podServiceAccountName
nos vários subcomponentes.
Lista de componentes e respetivos subcomponentes onde a conta de serviço do Kubernetes pode ser especificada juntamente com o nome predefinido da conta de serviço do k8s quando ativa a correção da identidade da carga de trabalho para os mesmos.
Componente | Subcomponente | Nome predefinido (disponível quando ativou a correção do Workload Identity) |
---|---|---|
organização | ||
connectAgent | apigee-connect-agent-svc-account-${ORG_NAME} |
|
observador | apigee-watcher-svc-account-${ORG_NAME} |
|
mart | apigee-mart-svc-account-${ORG_NAME} |
|
udca | apigee-udca-svc-account-${ORG_NAME} |
|
ambiente | ||
sincronizador | apigee-synchronizer-svc-account-${ORG_NAME}-${ENV_NAME} |
|
udca | apigee-udca-svc-account-${ORG_NAME}-${ENV_NAME} |
|
tempo de execução | apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME} |
|
datastore | ||
cassandra | apigee-datastore-svc-account |
|
telemetry | ||
metricsApp | apigee-metricsApp-svc-account |
|
metricsProxy | apigee-metricsProxy-svc-account |
|
metricsAdapter | apigee-metricsAdapter-svc-account |
|
containerLogs | apigee-container-logs-svc-account |
Identidades de carga de trabalho
As identidades de cargas de trabalho permitem que os pods (que usam contas de serviço do Kubernetes) em execução no GKE façam a autenticação diretamente com as APIs Google Cloud sem necessitarem de chaves de contas de serviço do Google Cloud.
Adicionar um novo ambiente
.
├── ...
├── instances/instance1/components
│ ├── ...
│ ├── environments
│ │ ├── dev
│ │ │ └── apigee-environment.yaml
│ │ │ └── secrets.yaml
│ │ └── new-env-name (new)
│ │ └── apigee-environment.yaml (new)
│ │ └── secrets.yaml (new)
└── ...
Adicionar um novo ambiente é tão simples como:
- Criar uma nova pasta no diretório environments (ou na estrutura de pastas que tiver definido)
- Copiar o ficheiro
apigee-environment.yaml
de qualquer ambiente existente para a nova pasta. - Se quiser criar uma nova conta de serviço e chaves de encriptação para o novo ambiente, copie o ficheiro
secrets.yaml
para a nova pasta e mude o nome dos segredos adequadamente para os distinguir dos outros ambientes existentes (normalmente, isto é feito adicionando o nome do ambiente como um sufixo) - Fazer as alterações adequadas ao
apigee-environment.yaml
, como:- Alterar o nome do ambiente
- Se forem criadas novas contas de serviço e chaves de encriptação, estas têm de ser corretamente referenciadas no YAML.
- Aplicar os
yaml
s:
kubectl apply -f components/environments/new-env-name/secrets.yaml
kubectl apply -f components/environments/new-env-name/apigee-environment.yaml
Usar a eliminação forçada no Apigee Datastore
Se a eliminação do repositório de dados não estiver a progredir por qualquer motivo, agora, o repositório de dados do Apigee pode ser eliminado à força através dos seguintes comandos, independentemente do estado atual do cluster.
Elimine
apigeeds
no espaço de nomesapigee
:Kubectl delete -n apigee apigeeds default
Se este passo ficar bloqueado, pode sair com CTRL + C.
Edite um novo
apigeeds
:Kubectl edit -n apigee apigeeds default
Adicione/atualize o campo forceDelete na especificação do arquivo de dados do Apigee
spec: forceDelete: true
Guarde o ficheiro e saia.
Agora, aguarde até que o arquivo de dados seja eliminado. A eliminação de todos os recursos do Cassandra pode demorar alguns minutos.
Compreender o script
O script apigee-hybrid-setup.sh
executa algumas validações básicas e ajuda a automatizar os passos que, de outra forma, teria de realizar se quisesse uma personalização mais detalhada, conforme documentado no artigo Instalação híbrida do Apigee personalizada. Mesmo com a instalação personalizada, ainda pode usar parcialmente o script para ajudar com determinadas tarefas.
Pode executar ./tools/apigee-hybrid-setup.sh --help
para ver uma lista de flags suportadas e receber ajuda adicional com o script. As seguintes flags são suportadas de momento:
--namespace
Por predefinição, o script instala todos os componentes no espaço de nomesapigee
. Pode alterar este comportamento especificando o nome do espaço de nomes através desta flag.--org
Usado para fornecer o nome da organização do Apigee. Se não for especificado, o projeto do Google Cloud predefinido é o atualmente selecionado emgcloud
--envgroup
Usado para fornecer o nome do grupo de ambientes na sua organização. Se não for especificado, é feita uma tentativa de consultar as APIs do plano de controlo para determinar o nome do grupo de ambientes. Se forem encontrados vários grupos de ambientes, é devolvido um erro e o script é terminado.--env
Usado para fornecer o nome do ambiente na sua organização. Se não for especificado, é feita uma tentativa de consultar as APIs do plano de controlo para determinar o nome do ambiente. Se forem encontrados vários ambientes ou o ambiente não fizer parte do grupo de ambientes, é devolvido um erro e o script é terminado.--cluster-name
O nome do cluster do Kubernetes.--cluster-region
A região onde o cluster do Kubernetes está localizado--gcp-project-id
O ID do projeto do Google Cloud onde o cluster do Kubernetes existe--ingress-domain
Especifica o nome do anfitrião/nome do domínio que vai ser usado para gerar os certificados TLS autoassinados para o istio ingress-gateway. Se não for especificado nenhum, é feita uma tentativa de determinar o valor consultando as APIs do plano de controlo para obter o valor do grupo de ambiente. Se existirem problemas na determinação do grupo de ambiente ou se existirem vários nomes de anfitrião configurados para o grupo de ambiente, é devolvido um erro e o script é terminado.--generate-internal-tls-certs
Esta ação gera um segredo do Kubernetes denominado apigee-ca que contém um certificado e um par de chaves gerados por nós.--create-ingress-tls-certs
Isto gera um segredo denominado{ORG_NAME}-{ENV_GROUP_NAME}
(derivado do nome da organização e do grupo de ambientes) no espaço de nomes istio-system que contém um certificado e um par de chaves que vão ser usados para a comunicação TLS. O nome do domínio usado para gerar estes certificados é derivado do valor encontrado na configuração do grupo de ambientes. Em caso de conflitos (como quando encontramos vários domínios), são apresentadas mensagens de erro adequadas.--create-gcp-sa-and-secrets
Cria uma única conta de serviço do Google Cloud no projeto do Google Cloud, transfere as chaves e, em seguida, cria os segredos do Kubernetes que contêm a chave. Pode encontrar os nomes dos segredos nas contas de serviço do Google Cloud.--fill-values
Substitui os valores de org, env, envgroup e outros nomes sempre que forem necessários nos vários ficheiros YAML.--apply-configuration
Isto cria os emissores de certificados, as definições de recursos personalizados, os webhooks, as funções e o recurso do controlador. Os recursos são criados pela ordem correta e o comando é bloqueado até que todos estejam em bom estado.-- rename-directories
Mude o nome do ambiente e do grupo de ambientes para os nomes do ambiente e do grupo de ambientes corretos.--verbose
Mostra a saída detalhada para depuração.--help
Apresentar informações de utilização.--setup-all
Esta ação executa todas as tarefas que podem ser realizadas por este script
Estrutura de pastas de configuração do Apigee Hybrid
Por predefinição, a pasta apigee-hybrid-setup
tem a seguinte estrutura hierárquica:
.
├── bases
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-controller-deployment.yaml
│ │ │ └── kustomization.yaml
│ │ └── apigee-ingressgateway-manager
│ │ ├── apigee-ingressgateway-manager-deployment.yaml
│ │ └── kustomization.yaml
│ ├── datastore
│ │ └── backup-and-restore
│ │ ├── backup
│ │ │ ├── cronjob.yaml
│ │ │ └── kustomization.yaml
│ │ ├── common
│ │ │ ├── kustomization.yaml
│ │ │ ├── rbac.yaml
│ │ │ └── tls-certificate.yaml
│ │ └── restore
│ │ ├── job.yaml
│ │ └── kustomization.yaml
│ └── initialization
│ ├── certificates
│ │ ├── certificates-and-issuers.yaml
│ │ └── kustomization.yaml
│ ├── crds
│ │ ├── customresourcedefinition-apigeedatastores.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeedeployments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeenvironments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeredis.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeerouteconfigs.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeroutes.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeetelemetries.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-cassandradatareplications.apigee.cloud.google.com.yaml
│ │ └── kustomization.yaml
│ ├── openshift
│ │ ├── kustomization.yaml
│ │ └── scc.yaml
│ ├── rbac
│ │ ├── apigee-controller
│ │ │ ├── kustomization.yaml
│ │ │ └── rbac.yaml
│ │ └── apigee-embedded-ingress-controller
│ │ ├── cluster-role-bindings.yaml
│ │ ├── cluster-roles.yaml
│ │ ├── kustomization.yaml
│ │ └── service-account.yaml
│ └── webhooks
│ ├── kustomization.yaml
│ ├── mutatingwebhookconfiguration.yaml
│ └── validatingwebhookconfiguration.yaml
├── CONTRIBUTING.md
├── docs
│ └── api_references
│ ├── v1alpha1.md
│ └── v1alpha2.md
├── kokoro
│ ├── build.sh
│ ├── common.cfg
│ ├── continuous.cfg
│ ├── presubmit.cfg
│ └── release.cfg
├── LICENSE
├── overlays
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-hybrid-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ ├── apigee-ingressgateway-manager
│ │ │ ├── apigee-ingressgateway-manager-deployment-patch.yaml
│ │ │ ├── apigee-istio-mesh-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ ├── initialization
│ │ ├── certificates
│ │ │ ├── apigee-ingressgateway-manager-certificate-patch.yaml
│ │ │ ├── apigee-serving-cert-patch.yaml
│ │ │ ├── components
│ │ │ │ └── disable-apigee-root-certificate-generation
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ ├── crds
│ │ │ └── kustomization.yaml
│ │ ├── ingress
│ │ │ ├── envoyfilter-1.11.yaml
│ │ │ └── kustomization.yaml
│ │ ├── namespace.yaml
│ │ ├── openshift
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── rbac
│ │ │ ├── apigee-controller
│ │ │ │ └── kustomization.yaml
│ │ │ ├── apigee-ingressgateway-manager
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ └── webhooks
│ │ ├── kustomization.yaml
│ │ ├── mutatingwebhookconfiguration.yaml
│ │ └── validatingwebhookconfiguration.yaml
│ └── instances
│ └── instance1
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── gcs-backup
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── cron-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── gcs-restore
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── job-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── multi-region
│ │ │ │ ├── cassandra-data-replication.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── non-gcs-backup
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── cron-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── non-gcs-restore
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── job-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── openshift-scc
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── scc.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-envgroup
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── openshift-scc
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ └── workload-identity-metrics
│ │ ├── kustomization.yaml
│ │ ├── patch.yaml
│ │ └── service-accounts.yaml
│ └── kustomization.yaml
├── README.md
├── templates
│ ├── certificate-org-envgroup.yaml
│ ├── secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml
│ ├── secret-apigee-cassandra-backup-and-restore-key-file.yaml
│ ├── secret-gcp-sa-key.yaml
│ └── secret-ingress-tls-cert-key.yaml
└── tools
├── apigee-hybrid-setup.sh
├── apigee-pull-push.sh
├── common.sh
├── create-service-account.sh
└── dump_kubernetes.sh
Pode encontrar uma versão dos ficheiros acima na etiqueta preview-1 do repositório do GitHub em: https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1.
A pasta acima contém manifestos do Kubernetes para o tempo de execução do Apigee hybrid e usa o Kustomize para a gestão da configuração. Os manifestos são organizados com base no conceito de bases e sobreposições do Kustomize. A pasta bases contém a configuração mínima necessária para cada componente do Apigee. A pasta de sobreposições contém várias funcionalidades adicionais(configurações) que são definidas como componentes. Pode um componente descomentando a referência do componente no kustomization.yaml
Exemplo : para ativar o gcs-backup
para o banco de dados do Apigee, o componente gcs-backup
foi retirado do comentário na personalização.yaml abaixo.
Caminho : ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/kustomization.yaml
namespace: "apigee" # kpt-set: ${APIGEE_NAMESPACE}
resources:
- apigee-datastore.yaml
components:
# - ./components/http-proxy
# - ./components/nodeselector/
# - ./components/imagepullsecret
# - ./components/workload-identity
# - ./components/openshift-scc
- ./components/gcs-backup (uncommented)
# - ./components/gcs-restore
# - ./components/non-gcs-backup
# - ./components/non-gcs-restore
Qualquer valor que exija personalizações tem de ser definido no ficheiro patch.yaml correspondente para gcs-backup.
No ficheiro abaixo, o valor de CLOUD_STORAGE_BUCKET_PATH
tem de ser definido pelo utilizador
Caminho: $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/datastore/components/gcs-backup/cron-patch.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: apigee-cassandra-backup
namespace: apigee
spec:
schedule: "${YOUR_BACKUP_SCHEDULE_CODE}" # To be modified
jobTemplate:
spec:
template:
spec:
containers:
- name: apigee-cassandra-backup
env:
- name: APIGEE_CLOUDPROVIDER
value: "GCP"
- name: DATABASE_STORAGE_BUCKET
value: "${CLOUD_STORAGE_BUCKET_PATH}" # To be modified. REQUIRED
volumeMounts:
- name: apigee-cassandra-backup
mountPath: /var/secrets/google
volumes:
- name: apigee-cassandra-backup
secret:
secretName: "apigee-cassandra-backup-and-restore-svc-account"
Da mesma forma, qualquer funcionalidade/configuração que exija personalizações pode ser ativada descomentando o componente no kustomization.yaml do componente apigee. Além disso, conforme necessário, os valores correspondentes dos campos no ficheiro patch.yaml do componente têm de ser definidos em conformidade.
Breve explicação das pastas e dos ficheiros:
bases
Esta pasta tem os modelos com a configuração mínima necessária para cada um dos componentes do Apigee. Não é necessário fazer modificações nos manifestos nesta pasta.
sobreposições
Esta pasta contém os modelos de componentes do Kustomize para as configurações adicionais
inicialização
namespaces.yaml
O espaço de nomes onde os componentes do plano de dados da Apigee vão ser instalados. O nome do espaço de nomes predefinido é apigee
certificados
Contém os recursos Issuer
e Certificate
que são usados para emitir certificados para os webhooks. Também contém o Issuer
que é usado para emitir certificados para vários pods para comunicação TLS.
rbac
Contém os elementos Role
, ClusterRole
, RoleBinding
e ClusterRoleBinding
que vão ser usados por vários componentes.
crds
Contains the definition of all the CRDs which are used by Apigee.
webhooks
Contém ValidatingWebhookConfiguration
e MutatingWebhookConfiguration
que vão ser usados para fazer validações nos recursos personalizados.
entrada
Contém a configuração aplicável a todos os PODs de entrada. Por exemplo, Modificação de cabeçalho comum, verificação de funcionamento, etc.
openshift
Contém a definição de SecurityContextConstraints do OpenShift.
Controladores
apigee-controller
apigee-hybrid-config.yaml
Contém um ConfigMap
que é fornecido como entrada em apigee-controller-manager.yaml. Este ConfigMap contém configurações como imageHub
, imagePullSecrets
e forwardProxy
, entre outras.
apigee-controller-deployment.yaml
Contém dois serviços para o controlador e o webhook, e a implementação para o controlador. Se quiser usar uma imagem privada para o controlador, é aqui que tem de fazer a alteração.
istiod
Apigee-istio-mesh-config.yaml Contém a configuração da malha para o Istio usado pelo Apigee. Isto não é aplicável a outras instalações do ASM/Istio no cluster.
apigee-ingressgateway-manager-deployment-patch.yaml
Contém um serviço e uma implementação do Istiod. Este é um istiod privado usado apenas para os exemplos de utilização do Apigee.
instances/{instanceName}
armazenamento de dados
apigee-datastore.yaml
Contém o recurso personalizado ApigeeDatastore
que gere o Cassandra.
secrets.yaml
Contém credenciais predefinidas para o arquivo de dados.
redis
apigee-redis.yaml
Contém o recurso personalizado ApigeeRedis
que gere o Redis.
secrets.yaml
Contém credenciais predefinidas para o arquivo de dados.
organização
apigee-organization.yaml
Contém o recurso personalizado ApigeeOrganization
que gere outros subcomponentes, como connectAgent, watcherAndSynchronizer, MART, UDCA e Ingress.
secrets.yaml
Contém os Secret
s que são referenciados em apigee-organization.yaml. Alguns segredos são comentados porque são gerados pelo script. Se desativar a respetiva geração, tem de os criar manualmente
ambientes
Contém todo o ambiente na sua organização. Deve criar uma pasta separada para cada ambiente copiando a que já lhe foi fornecida e configurando-a de acordo com os requisitos.
dev
apigee-environment.yaml
Contém o recurso personalizado ApigeeEnvironment
que gere outros subcomponentes, como o tempo de execução.
secrets.yaml
Contém os Secret
s que são referenciados em apigee-environment.yaml. Alguns segredos são comentados porque são gerados pelo script. Se desativar a respetiva geração, tem de criar manualmente esses
telemetria
apigee-telemetry.yaml
Contém o recurso personalizado ApigeeTelemetry
.
secrets.yaml
Contém os Secret
s que são referidos em apigee-telemetry.yaml. Alguns segredos são comentados porque são gerados pelo script. Se desativar a respetiva geração, tem de os criar manualmente
route-config
dev-envgroup
apigee-route-config.yaml
Contém o recurso personalizado ApigeeRouteConfig
.
secrets.yaml
Contém um Secret
que é referenciado em apigee-route-config.yaml. Está comentado porque é gerado automaticamente pelo script apigee-hybrid-setup.sh e é mantido aí para fornecer um exemplo do aspeto que o segredo deve ter se o criar manualmente.
diagnóstico
diagnostic-collector.yaml
Recursos que vão ser usados para implementar o diagnóstico
ferramentas
apigee-hybrid-setup.sh
apigee-create-service-account.sh
dump-kubernetes.sh
apigee-pull-push.sh
Armazenar chaves de contas de serviço em cofres externos
O Vault (da Hashicorp) é um sistema de gestão de segredos popular que tem várias integrações com lojas de segredos fornecidas pela Google, Azure, AWS e outros. O Hashicorp Vault permite-lhe obter segredos de uma origem externa e, em seguida, usá-los em recursos do Kubernetes. Existem várias formas de usar o Vault para obter segredos. Os passos seguintes servem como exemplo básico de como usar o Vault CSI Provider para montar chaves de contas de serviço do Google Cloud armazenadas num motor secreto fornecido pelo Vault.
- Vamos usar o Helm para instalar recursos relacionados com o Vault no seu cluster. Siga os passos em Instalar o Helm sobre como configurar o Helm no seu sistema.
Siga os passos em Instale o gráfico Helm do Vault, nomeadamente:
Adicionar o repositório Hashicorp ao Helm
helm repo add hashicorp https://helm.releases.hashicorp.com
Atualize os repositórios 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, vamos armazenar o segredo no Vault.
Obtenha um shell no agrupamento de desenvolvimento do cofre
kubectl exec -it vault-0 -- /bin/sh ```
Neste exemplo, vamos usar o motor secreto de chave/valor para armazenar dados.
vault kv put secret/runtime-gcp-sa-key key="${BASE_64_ENCODED_KEY}"
Para verificar se a chave foi armazenada com êxito, use:
vault kv get secret/runtime-gcp-sa-key
Configure a autenticação para permitir que o pod de tempo de execução extraia a chave. Conforme abordado em Contas de serviço do Kubernetes, as contas de serviço do Kubernetes fornecem identidade aos pods e permitem que estes façam a autenticação noutros sistemas.
Obtenha um shell no agrupamento de desenvolvimento do cofre
kubectl exec -it vault-0 -- /bin/sh
Ative o método de autenticação do Kubernetes
vault auth enable kubernetes
Escreva a configuração de autorização
vault write auth/kubernetes/config \ issuer="https://kubernetes.default.svc.cluster.local" \ token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \ kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \ kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \ disable_iss_validation=true
Crie a política de autorização
vault policy write apigee-runtime-app - <<EOF path "secret/data/runtime-gcp-sa-key" { capabilities = ["read"] } EOF
Associe a política à conta de serviço
vault write auth/kubernetes/role/apigee-runtime-role \ bound_service_account_names=apigee-runtime-sa \ bound_service_account_namespaces=${APIGEE_NAMESPACE} \ policies=apigee-runtime-app \ ttl=20m
Aqui, assumimos que a conta de serviço está no espaço de nomes apigee. Se tiver outro espaço de nomes para instalar o Apigee, vai usar esse nome.
Saia da shell no interior do cofre-0
exit
Instale o controlador CSI da loja de segredos
# Add repo to helm helm repo add secrets-store-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/secrets-store-csi-driver/master/charts # Install driver in cluster helm install csi secrets-store-csi-driver/secrets-store-csi-driver
Crie um recurso do Kubernetes
SecretProviderClass
que faça referência ao segredo que criou no cofrecat > 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
Crie a conta de serviço do Kubernetes à qual atribuímos as autorizações no passo (4.e)
kubectl create serviceaccount -n ${APIGEE_NAMESPACE} apigee-runtime-sa
Modifique o ficheiro apigee-environment.yaml para o ambiente e adicione as seguintes linhas:
apiVersion: apigee.cloud.google.com/v1alpha2 kind: ApigeeEnvironment # existing content spec: name: {ENV_NAME} organizationRef: {ORG_NAME} components: runtime: # existing content pod containers: - name: apigee-runtime podServiceAccountName: apigee-runtime-sa # existing content volumeMounts: - name: secrets-store-inline mountPath: "/opt/apigee/sa" readOnly: true volumes: - name: secrets-store-inline csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: "vault-apigee-runtime-gcp-sa-key"
Aplique as alterações:
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/$ENV_NAME
Atualização do Apigee Hybrid
Deve ter concluído todos os requisitos mencionados em Pré-requisitos. Além disso, recomendamos que faça um reinício contínuo de todos os componentes para verificar se o cluster está em bom estado. A ordem dos reinícios é Cassandra, Redis, ApigeeOrganization e ApigeeEnvironment.
Criar cópia de segurança
Crie uma cópia de segurança da configuração híbrida atual. É necessária uma cópia de segurança caso precise de reverter a atualização para a versão atual.
tar -czvf apigee-hybrid-install.v-X.Y.Z.tar.gz $HYBRID_INSTALL_BASE_DIR
Crie uma cópia de segurança da base de dados Cassandra. As cópias de segurança do Cassandra são uma medida de proteção importante contra cenários de desastre.
Atualize a sua plataforma Kubernetes, se necessário
Este passo não é necessário sempre, mas tem de atualizar a sua plataforma Kubernetes, como o Kubernetes, o OpenShift e os componentes, como o cert-manager, o Cassandra, etc., se a versão já não for suportada pela versão mais recente do Apigee Hybrid. A documentação vai conter as versões suportadas de plataformas e componentes.
Transfira ficheiros de configuração
Transfira o repositório e substitua a pasta bases
e tools
na configuração híbrida do Apigee existente por uma mais recente:
Clone a etiqueta preview-1 do repositório do GitHub em
https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1
O repositório clonado tem uma estrutura semelhante à descrita em Estrutura de pastas de configuração do Apigee Hybrid:
substituir a inicialização, as ferramentas e a pasta do controlador na configuração híbrida do Apigee existente.
export HYBRID_INSTALL_HOME=PATH_TO_PREVIOUS_HYBRID_INSTALL_DIRECTORY mv -f bases $HYBRID_INSTALL_HOME/bases mv -f tools $HYBRID_INSTALL_HOME/tools
Atualize as autorizações da conta de serviço, se necessário
Este passo também não é necessário sempre, mas tem de criar uma nova conta de serviço ou atualizar as autorizações das contas de serviço existentes, se necessário. O guia de atualização fornece os detalhes sobre as contas de serviço que têm de ser modificadas ou criadas e as funções que têm de ser adicionadas.
Se precisar de modificar as autorizações de contas de serviço existentes, use o comando
gcloud
adequado. O guia de atualização tem comandos e funções detalhados que têm de ser adicionados.gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:apigee-component@$PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/$NEW_ROLE"
Se a versão mais recente do Apigee Hybrid puder exigir uma conta de serviço adicional para componentes novos / existentes, tem de criá-los. Pode usar o script
apigee-create-service-account.sh
enviado na pasta da ferramenta para criar novas contas de serviço. Uma vez que o script já vai ser atualizado como parte do passo 4, vai ter detalhes e um novo perfil necessários para uma nova conta de serviço que tem de ser criada.O nome da conta de serviço recém-criada tem de ser referenciado no CR do componente correspondente.
./tools/create-service-account --env prod --profile apigee-component
Atualize o comando
Altere os campos de versão dos componentes indicados em ${INSTALL_DIR}/overlays/instances/$INSTANCE_DIR/kustomization.yaml
para a versão híbrida relevante.
Segue-se um exemplo de um ficheiro $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/kustomization.yaml. O valor do campo de versão tem de ser atualizado para a versão relevante
resources:
- datastore/
- environments/
- organization/
- redis/
- route-config/
- telemetry/
patches:
- target:
group: apigee.cloud.google.com
version: v1alpha1
kind: ApigeeDatastore
patch: |-
- op: add
path: /spec/version
value: 1-6-1 (Modify the version)
- target:
group: apigee.cloud.google.com
version: v1alpha2
kind: ApigeeEnvironment
patch: |-
- op: add
path: /spec/version
value: 1-6-1 (Modify the version)
Siga o mesmo conjunto de passos fornecidos em Crie recursos de inicialização e controlador no fluxo de trabalho de instalação híbrida do Apigee. Pode usar um script ou seguir os passos manuais fornecidos para atualizar os recursos de inicialização e o controlador.
Atualize os componentes do Apigee Kubernetes
Tem de fazer as seguintes alterações: - No caso de alterações arquitetónicas ou introdução de novos campos ou descontinuação de campos antigos, tem de modificar os CRs com as alterações adequadas de acordo com as instruções fornecidas no guia de atualização. – No mínimo, tem de atualizar os campos de versão nos CRs (que indicam a versão do Apigee Hybrid instalada) para a versão mais recente do Apigee Hybrid.
Aplique as alterações aos CRs do Apigee. Para o ambiente de não produção, pode aplicar todas as alterações aos componentes do Apigee em simultâneo
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
Reversão do Apigee Hybrid
Restaure o apigee-hybrid-setup
Mova-se para o diretório que contém a versão anterior da configuração híbrida do Apigee. Se não estiver disponível, restaure-o a partir do ficheiro ZIP criado no passo 1[link] durante a atualização do Apigee Hybrid.
Reverta os componentes do Kubernetes
Aplique as alterações para CRs do Apigee
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
Controlador de reversão
Siga o mesmo conjunto de passos fornecidos para criar recursos de inicialização e um controlador no fluxo de trabalho de instalação híbrida do Apigee. Pode usar um script ou seguir os passos manuais fornecidos para reverter os recursos de inicialização e o controlador.
Limpeza
Tem de limpar todos os novos recursos adicionais criados durante a atualização, como novos componentes ou contas de serviço introduzidos na versão mais recente do híbrido. Todos os recursos que têm de ser limpos e os passos para os limpar são fornecidos no guia de atualização.
Eliminar um ambiente
Seguem-se os passos para eliminar todos os recursos relacionados com um ambiente do seu cluster do Kubernetes:
Obtenha o nome do CR do ambiente. Pode fazê-lo obtendo todos os ambientes:
kubectl get env -n ${APIGEE_NAMESPACE}
Armazene o nome do recurso na variável de ambiente
APIGEE_ENV
.Elimine as chaves de encriptação do ambiente. Por exemplo, se não tiver alterado o nome das chaves de encriptação, pode eliminá-las através do seguinte comando:
kubectl delete secret -n ${APIGEE_NAMESPACE} $APIGEE_ENV-encryption-keys
Elimine segredos da conta de serviço da Google Cloud:
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}')
Elimine contas de serviço do Kubernetes:
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')
Elimine o recurso personalizado do ambiente do Apigee:
kubectl -n ${APIGEE_NAMESPACE} delete env $APIGEE_ENV
Eliminar uma configuração híbrida
Seguem-se os passos para eliminar todos os recursos relacionados com o Apigee Hybrid do seu cluster do Kubernetes:
Tem de eliminar as tarefas de configuração do utilizador e do esquema do Apigee.
# To list all jobs in ${APIGEE_NAMESPACE} kubectl -n ${APIGEE_NAMESPACE} get jobs # To delete all jobs in ${APIGEE_NAMESPACE} kubectl -n ${APIGEE_NAMESPACE} delete jobs $(kubectl -n ${APIGEE_NAMESPACE} get jobs -o custom-columns=':.metadata.name')
Tem de eliminar os componentes do plano de dados híbrido do Apigee implementados. Use o seguinte comando para eliminar todos os componentes:
kubectl delete -k ${INSTALL_DIR}/overlays/instances/$INSTANCE_NAME
Este passo só é necessário se não tiver usado o nome predefinido para os segredos da conta de serviço do Kubernetes, os segredos da conta de serviço do Google Cloud, etc. Se tiver usado os nomes predefinidos, estes são eliminados no passo seguinte. Caso contrário, tem de os eliminar manualmente através dos seguintes comandos:
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get ${APIGEE_COMPONENT} ${APIGEE_COMPONENT_NAME} -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}') kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get ${APIGEE_COMPONENT} ${APIGEE_COMPONENT_NAME} -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')
No caso do OpenShift, tem de eliminar o SCC (Security Context Constraints) criado durante a instalação do Apigee Hybrid.
kubectl delete scc ${SECURITY_CONTEXT_CONSTRAINTS_NAME}
Execute o comando abaixo para eliminar funções, associações de funções, CRDs, implementações de controladores, etc.
kubectl delete -k ${INSTALL_DIR}/overlays/initialization/ingress kubectl delete -k ${INSTALL_DIR}/overlays/initialization/rbac kubectl delete -k ${INSTALL_DIR}/overlays/initialization/webhooks kubectl delete -k ${INSTALL_DIR}/overlays/initialization/crds kubectl delete -k ${INSTALL_DIR}/overlays/initialization/certificates
Execute o comando abaixo para eliminar o espaço de nomes apigee
kubectl delete -f ${INSTALL_DIR}/overlays/initialization/namespace.yaml
Em alternativa, use o comando:
kubectl delete $APIGEE_NAMESPACE
Instalação de várias instâncias
A configuração de várias instâncias refere-se à configuração híbrida que pode abranger várias regiões ou também dentro das mesmas regiões. A Apigee recomenda que organize as configurações da 2.ª instância numa estrutura de diretórios separada, uma vez que as configurações do ambiente (réplicas, etc.) são invariavelmente diferentes entre instâncias. As configurações de cada instância estão separadas e organizadas de forma independente nas respetivas estruturas de pastas.
Por exemplo, para uma configuração ativa-passiva num cenário de várias regiões, pode querer configurar uma 2.ª região em espera ativa com dimensionamentos e configurações diferentes.
Na estrutura de pastas abaixo, pode fazer uma cópia do diretório instance1 denominado instance2 e modificar as configurações de armazenamento de dados e de entrada conforme necessário.
apigee-hybrid-setup
estrutura de pastas para a configuração de várias instâncias.]
.
├── bases
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-controller-deployment.yaml
│ │ │ └── kustomization.yaml
│ │ └── istiod
│ │ ├── apigee-ingressgateway-manager-deployment.yaml
│ │ └── kustomization.yaml
│ └── initialization
│ ├── certificates
│ │ ├── certificates-and-issuers.yaml
│ │ └── kustomization.yaml
│ ├── crds
│ │ ├── customresourcedefinition-apigeedatastores.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeedeployments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeenvironments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeredis.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeerouteconfigs.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeroutes.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeetelemetries.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-cassandradatareplications.apigee.cloud.google.com.yaml
│ │ └── kustomization.yaml
│ ├── ingress
│ │ ├── envoyfilter-1.11.yaml
│ │ └── kustomization.yaml
│ ├── openshift
│ │ ├── kustomization.yaml
│ │ └── scc.yaml
│ ├── rbac
│ │ ├── apigee-controller
│ │ │ ├── kustomization.yaml
│ │ │ └── rbac.yaml
│ │ └── apigee-embedded-ingress-controller
│ │ ├── cluster-role-bindings.yaml
│ │ ├── cluster-roles.yaml
│ │ ├── kustomization.yaml
│ │ └── service-account.yaml
│ └── webhooks
│ ├── kustomization.yaml
│ ├── mutatingwebhookconfiguration.yaml
│ └── validatingwebhookconfiguration.yaml
├── instances
│ └── instance1 (Add the 2nd instance under instances directory similar to instance1)
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-env-group
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ └── workload-identity-metrics
│ │ ├── apigee-workload-identities.yaml
│ │ ├── kustomization.yaml
│ │ └── patch.yaml
│ └── kustomization.yaml
├── overlays
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-hybrid-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ ├── istiod
│ │ │ ├── apigee-ingressgateway-manager-deployment-patch.yaml
│ │ │ ├── apigee-istio-mesh-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ ├── initialization
│ │ ├── certificates
│ │ │ ├── apigee-ingressgateway-manager-certificate.yaml
│ │ │ └── kustomization.yaml
│ │ ├── crds
│ │ │ └── kustomization.yaml
│ │ ├── ingress
│ │ │ └── kustomization.yaml
│ │ ├── namespace.yaml
│ │ ├── openshift
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── rbac
│ │ │ ├── apigee-controller
│ │ │ │ └── kustomization.yaml
│ │ │ ├── apigee-embedded-ingress-controller
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ └── webhooks
│ │ ├── kustomization.yaml
│ │ ├── mutatingwebhookconfiguration.yaml
│ │ └── validatingwebhookconfiguration.yaml
│ └── instances
│ └── instance1
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── openshift-scc
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── scc.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-envgroup
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── openshift-scc
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ └── kustomization.yaml
│ │ └── workload-identity-metrics
│ │ ├── apigee-workload-identities.yaml
│ │ ├── kustomization.yaml
│ │ └── patch.yaml
│ └── kustomization.yaml
├── README.md
├── templates
│ ├── ingress-certificate.yaml
│ ├── ingress-cert-secret.yaml
│ └── service-account-key-secret.yaml
└── tools
├── apigee-hybrid-setup.sh
├── common.sh
├── create-service-account.sh
└── dump_kubernetes.sh
Configuração de várias instâncias no GKE
Pré-requisitos
Antes de configurar várias instâncias do modo híbrido, espera-se que tenha concluído os seguintes pré-requisitos:
- Configure clusters do Kubernetes em várias regiões(iguais ou diferentes) com diferentes blocos CIDR
- Configure a comunicação entre regiões
- Abra as portas 7000 e 7001 do Cassandra entre clusters do Kubernetes em todas as regiões (a porta 7000 pode ser usada como opção de cópia de segurança durante a resolução de problemas). Consulte também o artigo Configurar portas.
Pode usar uma ferramenta como ntpdate para verificar se as horas do servidor estão sincronizadas.
Configure o anfitrião de origem multirregião
- Faça uma cópia da pasta $INSTANCE_NAME da sua instância existente e adicione-a à pasta instances.
- Modifique o valor do campo do espaço de nomes se for diferente do espaço de nomes instance1.
- Siga os passos especificados em Especificar certificados TLS de entrada para modificar a configuração de entrada da outra instância.
Consulte o artigo Gerir gateway de entrada do Apigee para obter informações sobre a configuração do IP do equilibrador de carga para a outra instância
Defina o contexto do kubectl para o cluster original antes de obter o nome da semente
kubectl config use-context original-cluster-name
Execute o seguinte comando kubectl para identificar um endereço de anfitrião inicial para o Cassandra na região atual.
kubectl get pods -o wide -n apigee -l app=apigee-cassandra
Qualquer um dos IPs do agrupamento devolvidos pelo comando anterior pode ser considerado o anfitrião de origem multirregional.
Na 2.ª instância, configure o valor de multiRegionSeedHost no CR do arquivo de dados do Apigee em ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/apigee-datastore.yaml
Configure a nova instância
Defina o contexto para o cluster existente
kubectl config use-context existing-cluster-name
Exporte o segredo apigee-ca para um ficheiro
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 segredo para o novo cluster
kubectl -n cert-manager apply -f apigee-root-certificate.yaml
Instale o modo híbrido na nova instância (região) seguindo os passos descritos em Crie recursos de inicialização e um controlador.
Configure o Cassandra em todos os pods nos novos centros de dados. Obtenha o apigeeorg do cluster com o seguinte comando:
kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
Crie um ficheiro de recurso personalizado (YAML) de replicação de dados do Cassandra. O ficheiro pode ter qualquer nome. Nos exemplos seguintes, o ficheiro tem o nome datareplication.yaml. O ficheiro tem de conter o seguinte
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: REGION_EXPANSION namespace: NAMESPACE spec: organizationRef: APIGEEORG_VALUE force: false source: region: SOURCE_REGION
Onde:
- REGION_EXPANSION é o nome que está a dar a estes metadados. Pode escolher um nome como "cassandra-data-replication"
- NAMESPACE é o mesmo espaço de nomes que foi escolhido para a 2.ª instância. Normalmente, é "apigee".
- APIGEEORG_VALUE é o valor produzido pelo comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" no passo anterior.
- SOURCE_REGION é o valor do valor do centro de dados do Cassandra do estado da ferramenta de nó do cluster de origem.
Aplique o CassandraDataReplication com o seguinte comando:
kubectl apply -f datareplication.yaml
Valide o estado da reconstrução através do seguinte comando.
kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
O resultado deve ter um aspeto semelhante a
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }
Valide os processos de reconstrução a partir dos registos. Além disso, verifique o tamanho dos dados através do comando nodetool status:
kubectl logs apigee-cassandra-default-0 -f -n apigee
Consulte o datastore/secrets.yaml para o JMX_user e o JMX_password
kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool -u JMX_user -pw JMX_password status
Remova
multiRegionSeedHost
do CR do banco de dados do Apigee e execute o comando abaixo para aplicar a alteraçãokubectl apply k apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore
Verifique o estado do cluster do Cassandra
O comando seguinte é útil para ver se a configuração do cluster foi bem-sucedida em dois centros de dados. O comando verifica o estado do nodetool para as duas regiões.
kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool -u JMX_user -pw JMX_password status
Datacenter: us-central1 ======================= Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.12.1.45 112.09 KiB 256 100.0% 3c98c816-3f4d-48f0-9717-03d0c998637f ra-1 UN 10.12.4.36 95.27 KiB 256 100.0% 0a36383d-1d9e-41e2-924c-7b62be12d6cc ra-1 UN 10.12.5.22 88.7 KiB 256 100.0% 3561f4fa-af3d-4ea4-93b2-79ac7e938201 ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.4.33 78.69 KiB 256 100.0% a200217d-260b-45cd-b83c-182b27ff4c99 ra-1 UN 10.0.0.21 78.68 KiB 256 100.0% 9f3364b9-a7a1-409c-9356-b7d1d312e52b ra-1 UN 10.0.1.26 15.46 KiB 256 100.0% 1666df0f-702e-4c5b-8b6e-086d0f2e47fa ra-1
Resolução de problemas
Guia de capacidade de apoio técnico, diagnóstico e resolução de problemas
Limpeza manual após usar o forceDelete na configuração do Apigee Hybrid de várias regiões
- No exemplo seguinte, existem 2 regiões:
us-east1
eus-west1
. - Na região
us-west1
, o arquivo de dados do Apigee foi eliminado através da eliminação forçada. - Na região
us-east1
, o cassandra ainda está em funcionamento. Verifique se o cartão
apigeeds
foi eliminado através do comandokubectl get apigeeds -n apigee No resources found in apigee namespace.
Altere o contexto do kubectl para a outra região onde o cluster do Cassandra ainda está em funcionamento (aqui, a região
us-east1
).Verifique se o arquivo de dados está em estado de execução
kubectl get apigeeds -n apigee NAME STATE AGE default running 23h
Executar num dos pods do Cassandra na região de carregamento (aqui, a região
us-east1
)kubectl exec -it -n apigee apigee-cassandra-default-0 -- bash apigee@apigee-cassandra-default-0:~$
Verifique o estado da ferramenta nodetool. Esta vai mostrar todos os nós inativos na região eliminada (neste caso, a região
us-west1
)apigee@apigee-cassandra-default-0:~$ nodetool -u ${APIGEE_JMX_USER} -pw ${APIGEE_JMX_PASSWORD} status
Datacenter: us-east1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.52.0.212 685.01 KiB 256 ? e1aa61e3-4eae-4549-9b58-506d495d87ab ra-1 UN 10.52.0.72 606.75 KiB 256 ? 477dfc03-f93e-40ea-810a-d15769822ad5 ra-1 UN 10.52.0.104 648.3 KiB 256 ? a8854cff-c2e3-4f0c-a342-e692787efcab ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack DN 10.60.0.143 567.06 KiB 256 ? 355d6ace-ab77-42cb-8138-9993bfd62d0e ra-1 DN 10.60.0.40 535.99 KiB 256 ? 4ed2c903-ff56-40fa-a15e-80a3de3cb22d ra-1 DN 10.60.0.17 573.08 KiB 256 ? f9a50d19-c04a-4d0d-a088-612384bed9f5 ra-1
Remova todos os nós na região eliminada (aqui
us-west1
)apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode 355d6ace-ab77-42cb-8138-9993bfd62d0e apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode 4ed2c903-ff56-40fa-a15e-80a3de3cb22d apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode f9a50d19-c04a-4d0d-a088-612384bed9f5
Verifique se não restam nós da região eliminada (aqui
us-west1
)apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status
Datacenter: us-east1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.52.0.212 699.71 KiB 256 ? e1aa61e3-4eae-4549-9b58-506d495d87ab ra-1 UN 10.52.0.72 586.77 KiB 256 ? 477dfc03-f93e-40ea-810a-d15769822ad5 ra-1 UN 10.52.0.104 623.6 KiB 256 ? a8854cff-c2e3-4f0c-a342-e692787efcab ra-1
Assim que este processo estiver concluído, elimine a tarefa de configuração do utilizador na região de carregamento (aqui,
us-east1
). A tarefa é recriada automaticamente no espaço de alguns segundos.kubectl get jobs -n apigee
NAME COMPLETIONS DURATION AGE apigee-cassandra-schema-setup-apigee--0d2504c 0/1 5m54s 5m54s apigee-cassandra-user-setup--apigee--0d2504c 0/1 7s 7s
kubectl delete job apigee-cassandra-user-setup--apigee--0d2504c
Aguarde pela conclusão da tarefa de configuração do utilizador
kubectl get jobs -n apigee
NAME COMPLETIONS DURATION AGE apigee-cassandra-schema-setup-apigee--0d2504c 1/1 5m54s 5m54s apigee-cassandra-user-setup--apigee--0d2504c 1/1 7m 7m
Verifique se os espaços de chaves não têm a região eliminada.
Crie um pod de depuração do Cassandra.
Inicie sessão no cqlsh no pod de depuração através do comando
apigee@cassandra-debug-client:~$ cqlsh apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local -u ddl_user --ssl Password:
Verifique se a região
us-west1
foi removida de todos os espaços de chavesddl_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)