Nueva versión preliminar de instalación y administración de Apigee Hybrid

Esta vista previa ya no está disponible.

Vista previa — Apigee hybrid new install process (discontinued)

Esta función está sujetas a los "Términos de las Ofertas de Acceso Previo a la Disponibilidad General" de la sección Términos Generales de los Servicios de los Términos Específicos de los Servicios. Las funciones previas a la disponibilidad general están disponibles tal cual y pueden tener una compatibilidad y asistencia limitadas. Para obtener más información, consulta las descripciones de las fases de lanzamiento.

---

Guía del usuario de la versión preliminar:
Versión preliminar de los nuevos procedimientos de instalación y administración de Apigee Hybrid 1.8.

---

En este documento:

• Vista previa
  • Comentarios
• Descripción general
  • Cambios en el nuevo proceso de instalación
• Requisitos
  • Versión de vista previa
  • Configuración de Apigee hybrid
  • Herramientas
• Instalación básica de Apigee Hybrid
  • Descargar archivos de configuración
  • Ejecutar configuración
• Instalación personalizada de Apigee Hybrid
  • Descargar archivos de configuración
  • Crear espacio de nombres
  • Usar imágenes de Docker de repositorios privados (opcional)
  • Configurar imagePullSecrets (opcional)
  • Configurar un proxy de reenvío (opcional)
  • Especificar certificados TLS de entrada
  • Actualizar la implementación de entrada
  • Configurar cuentas de servicio de Google Cloud personalizadas
  • Usar identidades de carga de trabajo
  • Editar archivos YAML de recursos
  • Crear recursos de inicialización y controlador
  • Dar permisos a la cuenta de servicio de Synchronizer para interactuar con el plano de control
  • Crear componentes del plano de datos de Apigee
  • Espera a que se inicien los recursos
  • Personalizar la instalación de cert-manager en un espacio de nombres personalizado
• Kustomize y componentes
  • Descripción general
  • Cómo usar los componentes
  • OpenShift
  • imagepullsecret
  • nodeselector
  • workload-identity
  • http-proxy
  • registrador y métricas
  • gcs-backup y gcs-restore
  • non-gcs-backup y non-gcs-restore
  • http-client
  • non-sni-client
  • http-and-non-sni-client
  • multirregional
• Conceptos
  • Añadir un entorno
  • Usar la eliminación forzada en Apigee Datastore
• Interpretar la secuencia de comandos
• Estructura de carpetas de configuración de Apigee Hybrid
• Almacenar claves de cuentas de servicio en almacenes externos
• Actualización de Apigee Hybrid
  • Crear copia de seguridad
  • Actualiza tu plataforma de Kubernetes si es necesario.
  • Descargar archivos de configuración
  • Actualizar los permisos de la cuenta de servicio si es necesario
  • Controlador de actualización
  • Actualizar componentes de Apigee Kubernetes
• Restauración de Apigee Hybrid
  • Restaurar apigee-hybrid-setup
  • Restaurar componentes de Kubernetes
  • Controlador de restauración
• Limpieza
• Eliminar un entorno
  • Eliminar una configuración híbrida
• Instalación de varias instancias
  • Configuración de varias instancias en GKE
  • Solución de problemas
  • Guía de asistencia, diagnóstico y solución de problemas
  • Limpieza manual después de usar forceDelete en una configuración de Apigee Hybrid multirregión

Vista previa

---

Nota: Este documento y el software que describe forman parte de una versión preliminar. Apigee no garantiza el software ni los procedimientos de esta vista previa. La documentación y el software están sujetos a cambios sin previo aviso.

Este documento está dirigido a los operadores de Apigee (usuarios que instalan, gestionan y administran instalaciones de Apigee Hybrid). Para seguir las instrucciones de este documento, debes tener experiencia en la instalación de Apigee Hybrid en una de las plataformas de Kubernetes compatibles. Te recomendamos que crees una organización de Apigee de evaluación para probar los pasos que se indican a continuación.

Comentarios

Envía tus comentarios sobre este proceso a [e-mail].

---

Información general

La nueva experiencia de instalación de Apigee Hybrid instala los componentes de Apigee mediante kubectl e integra la instalación y la gestión de Apigee Hybrid con herramientas de orquestación de la configuración de Kubernetes, como Kustomize. Las validaciones y la visibilidad mejoradas de los componentes que se instalan ofrecen una mejor capacidad de depuración y mejoran el proceso de instalación en general.

Una secuencia de comandos de instalación, apigee-hybrid-setup.sh, proporciona una herramienta sencilla para la instalación básica. Puedes usarlo para crear tu instalación híbrida y, después, modificarla con kubectl para que se ajuste a tus necesidades. También puedes crear tu instalación híbrida desde cero con kubectl. Todas las propiedades de configuración de Apigee Hybrid se almacenan en archivos YAML, uno por cada componente principal. De esta forma, puedes controlar tu instalación híbrida en tu entorno de Kubernetes de forma mucho más granular. Puedes encontrar los archivos de configuración y las secuencias de comandos de instalación en el repositorio de GitHub.

Cambios en el nuevo proceso de instalación

Apigee va a cambiar el proceso de instalación de Apigee Hybrid por los siguientes motivos:

• El nuevo método de instalación de Apigee hybrid se puede integrar con herramientas de CI/CD de Kubernetes como Argo, Flux o Anthos Config Management, que no usan un archivo de configuración overrides.yaml.
• Apigee Hybrid proporciona apigeectl, una herramienta de plantillas personalizada que genera manifiestos de Kubernetes (entre otras cosas) para instalar y gestionar Apigee Hybrid en clústeres de Kubernetes. El nuevo proceso de instalación y gestión ofrece una experiencia similar a la de otros proveedores de software.
• El nuevo proceso permite realizar una instalación básica rápidamente, ya que crea automáticamente cuentas de servicio con los permisos necesarios, certificados TLS, valores predeterminados y otros elementos fundamentales.

Requisitos previos

Antes de usar esta versión preliminar, debes cumplir los siguientes requisitos:

Versión preliminar

Esta vista previa está diseñada para funcionar con la versión 1.8.x de Apigee Hybrid. No se admiten versiones posteriores de Apigee hybrid.

Configuración de Apigee Hybrid

Antes de proceder con la instalación de Apigee Hybrid, debes haber completado las instrucciones que se indican en las siguientes secciones de la documentación:

1. Configuración de proyectos y organizaciones
   • Descripción general de los requisitos previos para instalar Apigee Hybrid.
   • Paso 1: Habilita las APIs
   • Paso 2: Crea una organización
   • Paso 3: Crea un entorno y un grupo de entornos
2. Configuración de un entorno de ejecución híbrido
   • Paso 1: Crea un clúster
   • Paso 2: Instala cert-manager

Herramientas

Además, debes descargar y configurar las siguientes herramientas en tu estación de trabajo:

• curl
• docker es necesario para ejecutar la secuencia de comandos apigee-hybrid-setup.sh. Sigue las instrucciones de Get Docker para instalar Docker.
• envsubst debería estar disponible en la mayoría de los sistemas basados en Linux o UNIX. En macOS y otros sistemas, sigue las instrucciones de este repositorio.
• jq debe estar instalado. Descarga jq.

• kpt Descarga kpt.

  Nota: No se admiten las versiones v0.39 y anteriores de KPT. Descarga kpt desde el enlace mencionado anteriormente (versión 1.0 o posterior) para asegurarte de que funciona.

• kubectl versión 1.23 o posterior. Consulta Install Tools: kubectl (Instalar herramientas: kubectl) en la documentación de Kubernetes.

Variables comunes usadas en esta guía

En esta guía se usan las siguientes variables de entorno en varios pasos. Puedes definirlas en la línea de comandos o con una secuencia de comandos, o bien sustituir el texto de los comandos cuando los introduzcas.

• APIGEE_NAMESPACE: tu espacio de nombres de Apigee. El valor predeterminado es apigee. Sin embargo, puedes usar otro espacio de nombres.
• CLUSTER_NAME: el nombre del clúster en el que vas a instalar Apigee hybrid. Este es el clúster que creas en el paso 1: Crea un clúster.
• CLUSTER_LOCATION: la región de tu clúster. Los procedimientos de esta guía parten de la base de que usas un clúster regional. Si utilizas un clúster zonal, consulta las instrucciones del paso 1: Crea un clúster.
• ENV_GROUP: el nombre del grupo de entornos de tu instalación de Apigee hybrid. Este es el grupo de entorno que creas en el paso 3: Crea un grupo de entorno. Puedes crear varios grupos de entornos.
• ENV_NAME: el nombre del grupo de entornos de tu instalación de Apigee hybrid. Este es el grupo de entorno que creas en el paso 3: Crea un grupo de entorno. Puedes crear varios grupos de entornos.
• INSTALL_DIR: el directorio en el que instales Apigee hybrid. De forma predeterminada, se trata del subdirectorio apigee-hybrid-install/ del directorio en el que descargues el instalador. Por ejemplo: /myhybrid/apigee-hybrid-install/. Este es el directorio raíz de la estructura de archivos que se describe en Estructura de carpetas de configuración de Apigee Hybrid.
• INSTANCE_DIR: el directorio de una instancia específica de Apigee hybrid. De forma predeterminada, la primera instancia se llama instance-1. El directorio de la instancia es un subdirectorio de ${INSTALL_DIR}/overlays/instances/. Puedes especificar cualquier nombre para tus instancias híbridas. Consulta Instalación de varias instancias.
• ORG_NAME: el nombre de tu organización de Apigee Hybrid. Debe ser el mismo que el ID de tu proyecto de Google Cloud. Consulta el paso 2: Crea una organización.

Instalación básica de Apigee Hybrid

Para instalar Apigee Hybrid rápidamente sin tener que personalizarlo en profundidad, puedes seguir este procedimiento de dos pasos.

---

Nota: Una instalación básica tiene la siguiente configuración:

• Un solo entorno
• Un solo grupo de entornos
• Se crea una única cuenta de servicio de Google Cloud que se usa para todos los componentes individuales.
• Valores predeterminados de todas las claves de cifrado y contraseñas.

---

1. Descargar archivos de configuración
2. Ejecutar configuración

Descargar archivos de configuración

Descarga y prepara los archivos de configuración clonando el repositorio de GitHub en https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1:

1. Clona el repositorio:

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

2. Ve al directorio del repositorio clonado:

   cd apigee-hybrid-install
   

3. Crea una rama a partir de la etiqueta preview-1:

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

4. Haz que la secuencia de comandos de configuración sea ejecutable:

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

   El repositorio clonado tendrá una estructura similar a la que se describe en Estructura de carpetas de configuración de Apigee Hybrid:

Ejecutar configuración

Ejecuta la secuencia de comandos apigee-hybrid-setup.sh ubicada en la carpeta tools/.

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

---

Nota: Al ejecutar la secuencia de comandos con estos argumentos, se usan la organización, el entorno y el grupo de entornos de Apigee que has creado en Requisitos previos.

Si se producen errores, prueba a ejecutar la secuencia de comandos una segunda vez.

---

Otras opciones que puedes usar son las siguientes:

• --env $ENV_NAME especifica el nombre del entorno de Apigee.
• --envgroup $ENV_GROUP especifica el grupo de entornos.
• --ingress-domain $HOSTNAME especifica el nombre de host que has proporcionado para tu grupo de entornos.
• --gcp-project-id $PROJECT_ID especifica el ID de tu proyecto de Google Cloud.

Para ver más opciones, consulta Información sobre la secuencia de comandos.

Los errores que se produzcan durante la ejecución se mostrarán en la salida estándar.

Una vez que la secuencia de comandos se haya completado correctamente, habrás completado la instalación híbrida básica. Para probar la instalación, puedes crear un proxy de ejemplo tal como se explica en el artículo Crear y desplegar un proxy de APIs.

Instalación personalizada de Apigee Hybrid

Los usuarios más avanzados que quieran tener un control preciso sobre la instalación pueden seguir esta secuencia de pasos. En muchos de los pasos que se indican a continuación, puedes elegir entre realizarlos manualmente o usar la secuencia de comandos shell para automatizarlos:

---

Nota: Para seguir estos pasos, debes tener conocimientos básicos sobre los conceptos de Kubernetes. Consulta la sección Conceptos o la documentación de Kubernetes para obtener más información.

---

Descargar archivos de configuración

Descarga y prepara los archivos de configuración:

1. Clona el repositorio de GitHub en https://github.com/apigee/apigee-hybrid-install/.

   El repositorio clonado tendrá una estructura similar a la que se describe en Estructura de carpetas de configuración de Apigee Hybrid:

2. cd en el directorio apigee-hybrid-install/

3. Haz que la secuencia de comandos de configuración sea ejecutable:

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

Crear espacio de nombres

Crea un espacio de nombres de Kubernetes en tu clúster que contenga todos los componentes del clúster de Apigee.

kubectl create namespace apigee

---

Nota: Apigee es el nombre predeterminado del espacio de nombres. Puedes usar otro nombre.

---

Si eliges otro nombre para el espacio de nombres, puedes seguir una de las tres opciones que se indican a continuación:

• (Recomendado) Usa --namespace={YOUR_NAMESPACE_NAME} al rellenar previamente los valores en Editar archivos YAML de recursos.

• Ejecuta los dos comandos siguientes:

  1. Usa kpt para especificar el espacio de nombres de Apigee:

     kpt fn eval "${INSTALL_DIR}/overlays/" \
       --image gcr.io/kpt-fn/apply-setters:v0.2.0 -- \
       APIGEE_NAMESPACE="${APIGEE_NAMESPACE}"
     # This is for replacing the namespace in istio discoveryAddress which cannot be
     # achieved with kpt
     

  2. Usa sed para sustituir el espacio de nombres en 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"
     

• También puedes cambiar manualmente los recursos de forma individual para que se creen en el espacio de nombres que elijas.

Usar imágenes de Docker de repositorios privados (opcional)

Puedes elegir no usar las imágenes alojadas públicamente y usar imágenes de tus propios repositorios privados:

1. El primer paso es enviar todas las imágenes a tu repositorio privado. Para ello, sigue los pasos que se indican en apigee-pull-push | Apigee X. De forma predeterminada, las imágenes se etiquetan con la versión de Apigee Hybrid a la que corresponden. Te recomendamos que no edites estas etiquetas. También le recomendamos que no edite los nombres de las imágenes para que la ruta de la imagen final se pueda crear tal como se explica en Image Hub.

2. Define el valor del campo imageHub del archivo apigee-hybrid-config.yaml en la ruta del host del repositorio privado. Consulta más información en el centro de imágenes.

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

De esta forma, todos los componentes de Apigee hybrid usarán las imágenes de tu repositorio privado.

Además, puede que quieras usar una imagen privada para el controlador y la puerta de enlace de entrada de Apigee. Para ello, tendrás que editar los archivos apigee-controller-deployment.yaml y apigee-ingressgateway-manager-deployment.yaml y sustituir todos los campos image por la imagen de su repositorio privado.

---

Nota: Si extraes imágenes de un repositorio privado, lo más probable es que tengas que autenticarte para hacerlo. Las credenciales necesarias para esta autenticación se especifican como imagePullSecrets, que se ha explicado detalladamente en Configurar imagePullSecrets (opcional).

---

Configurar imagePullSecrets (opcional)

1. Crea un secreto de Kubernetes que contenga las credenciales para autenticarte en los repositorios privados. Consulta Extraer una imagen de un registro privado para saber cómo se debe crear el secreto.
2. Una vez creado el secreto, solo queda hacer referencia a él. Para ello, edita el archivo apigee-hybrid-config.yaml, asigna al campo imagePullSecret el nombre del secreto que has creado y habilita el componente imagePullSecret en el archivo kustomization.yaml correspondiente.

---

Nota: Si también usas imágenes privadas para el controlador, puede que tengas que añadir campos imagePullSecrets en la especificación de implementación presente en los archivos apigee-controller-deployment.yaml y apigee-ingressgateway-manager-deployment.yaml.

Si especificas imagePullSecrets en ambos sitios, tendrá prioridad el que esté en el archivo apigee-controller-manager.yaml.

---

Configurar un proxy de reenvío (opcional)

Los proxies de reenvío se pueden configurar añadiendo el campo forwardProxy al archivo apigee-hybrid-config.yaml. Por ejemplo:

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

Especificar certificados TLS de entrada

Usar la secuencia de comandos

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

Consulta la sección Información sobre la secuencia de comandos para obtener más detalles sobre esta marca.

Manual

Debes proporcionar certificados TLS que se usarán para la pasarela de entrada de Istio. Puedes hacer lo siguiente:

• Usar certificados firmados por una autoridad conocida siguiendo los pasos que se indican en Obtener certificados TLS: ejemplo | Apigee X
• o generar certificados autofirmados.

En este caso, usaremos certificados autofirmados como ejemplo. Los certificados autofirmados se pueden generar mediante (suponiendo que DOMAIN se ha configurado correctamente y debe coincidir con el nombre de host definido en tu grupo de entorno):

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

Se crearán dos archivos llamados tls.key y tls.crt.

A continuación, debe crear un secreto con el siguiente formato. Puede usar kubectl create o kubectl apply, tal como se explica en la sección sobre cómo usar un par de clave y certificado personalizados para la autoridad de certificación (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}

---

Ejemplo de creación del secreto con kubectl create:

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

---

Nota: Si cambias el nombre del secreto anterior, tendrás que hacer el cambio correspondiente en apigee-route-config.yaml. Para ello, cambia el valor de secretNameRef a YOUR_SECRET_NAME

---

Actualizar el despliegue de entrada

Para crear o modificar implementaciones de entrada, debe modificar el campo spec.components.ingressGateways en el recurso personalizado ApigeeOrganization de bases/initialization/crds/customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml.

De forma predeterminada, creamos una implementación de entrada con parámetros predeterminados(los valores predeterminados se mostrarán en los documentos de referencia de CR ):

ingressGateways:
- name: "prod-1"

Ejemplos:

A. Anular campos de servicio de entrada

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

B. Cambiar el mínimo o el máximo de réplicas

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

C. Añadir un nuevo despliegue de Ingress

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

Configurar cuentas de servicio de Google Cloud personalizadas

---

Nota: Es obligatorio configurar cuentas de servicio de Google Cloud personalizadas o usar identidades de carga de trabajo.

---

Usar la secuencia de comandos

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

Donde APIGEE_NAMESPACE es tu espacio de nombres personalizado. El espacio de nombres predeterminado es apigee.

Consulta Información sobre la secuencia de comandos para obtener más detalles sobre las marcas.

Manual

Las claves de cuenta de servicio de Google Cloud deben almacenarse como secretos en el clúster. El archivo YAML de secretos debe tener la siguiente estructura:

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

Para obtener más información sobre las cuentas de servicio necesarias y los nombres de los secretos, consulta la sección Cuentas de servicio de Google Cloud.

Puedes elegir otro nombre para los secretos, pero tendrás que hacer el cambio correspondiente en el componente en el que se haya usado ese nombre. Por ejemplo, si decides cambiar el nombre del secreto de la cuenta de servicio del tiempo de ejecución de apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME} a my-runtime-svc, tendrás que hacer el cambio correspondiente en el apigee-environment.yaml de ese entorno.

---

Nota: Los secretos que contienen las claves de las cuentas de servicio se pueden obtener de herramientas de gestión de secretos externas, como Vault. Consulta la sección Almacenar claves de cuentas de servicio en almacenes externos para obtener información sobre cómo hacerlo.

---

Usar identidades de carga de trabajo

---

Nota: Las identidades de carga de trabajo solo se pueden usar con clústeres de GKE en Google Cloud.

Es obligatorio configurar cuentas de servicio de Google Cloud personalizadas o usar identidades de carga de trabajo.

---

Requisitos previos

Antes de usar identidades de carga de trabajo, asegúrate de que tu clúster de GKE tenga habilitada la compatibilidad. Consulta Actualizar grupos de nodos | Apigee X para obtener más información.

Habilitar workload-identity

Consulta la sección Identidades de carga de trabajo en Kustomize y componentes para obtener información sobre cómo habilitar las identidades de carga de trabajo antes de la instalación.

Editar archivos YAML de recursos

En algunos lugares de los archivos YAML de los componentes, deben figurar los nombres correctos de la organización, el entorno y el grupo de entornos. Puede definir estos valores manualmente o usar la secuencia de comandos shell para rellenarlos automáticamente.

Usar la secuencia de comandos

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

Crear recursos de inicialización y un 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

Conceder permisos a la cuenta de servicio de sincronización para interactuar con el plano de control

Sigue los pasos que se indican en el paso 8: Habilita el acceso del sincronizador y sustituye el nombre de la cuenta de servicio, apigee-non-prod o apigee-synchronizer, por apigee-all-sa, el nombre de la cuenta de servicio creada por el nuevo proceso de instalación.

---

★ Importante: Asegúrate de cambiar el nombre de la cuenta de servicio en las instrucciones de la sección Habilitar el acceso del sincronizador. De lo contrario, no se podrá habilitar el acceso del sincronizador.

---

Crear componentes del plano de datos de Apigee

Si has cambiado el nombre de alguno de los recursos en los pasos anteriores, tendrás que hacer el cambio correspondiente en otros archivos YAML en los que se haga referencia a ese recurso. Una vez hecho esto, usa los comandos del siguiente ejemplo:

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

para instalar todos los componentes.

Espera a que se inicien los recursos

kubectl wait "apigeedatastore/default" \
"apigeeredis/default" \
"apigeeenvironment/${ORG_NAME}-${ENV_NAME}" \
"apigeeorganization/${ORG_NAME}" \
"apigeetelemetry/apigee-telemetry" \
-n "${APIGEE_NAMESPACE}" --for="jsonpath=.status.state=running" --timeout=15m

Personalizar la instalación de cert-manager en un espacio de nombres personalizado

Personaliza el espacio de nombres en el que se ejecuta cert-manager con el siguiente procedimiento.

Si cert-manager está instalado en tu clúster en un espacio de nombres distinto de cert-manager, tendrás que actualizar el espacio de nombres que se usa para crear el certificado raíz de Apigee.

1. Edita el archivo customization.yaml para crear el certificado: $INSTALL_DIR/overlays/initialization/certificates/kustomize.yaml

2. Añade lo siguiente al final del archivo.

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

3. Guarda el archivo.

Kustomize y componentes

Información general

La nueva instalación híbrida hereda la ideología de Kustomize de estructurar archivos YAML en forma de bases y superposiciones.

• Las bases son archivos proporcionados por Apigee que pueden cambiar entre cada nueva versión de Hybrid. No tienes que modificar estos archivos. Estos archivos contienen algunos valores predeterminados proporcionados por Apigee. Todos los archivos de la carpeta de nivel superior bases/ contienen estas bases.

• Las superposiciones contienen la configuración de los usuarios y sirven como medio para modificar los valores predeterminados especificados en las bases. Todos los archivos de la carpeta overlays/ de nivel superior contienen estas superposiciones.

  ---

  Nota: Para entender mejor Kustomize y cómo se han usado las superposiciones para modificar las bases, te recomendamos que consultes el artículo Parches de Kustomize.

  ---

Cómo usar los componentes

Las subcarpetas del directorio overlays/ de nivel superior se han estructurado de forma que puedas habilitar (o inhabilitar) una función adicional comentando (o descomentando) determinadas líneas de los archivos kustomization.yaml.

Por ejemplo, esta es la estructura de carpetas de 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

Así es como se verían los archivos telemetry/kustomization.yaml de forma predeterminada:

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

Vemos que se ha comentado ./components/logger, lo que significa que no hemos habilitado uGoogle Clod Logger de forma predeterminada. Para habilitarlo, solo tienes que quitar el comentario de esa línea de esta forma:

components:

- ./components/logger

Del mismo modo, para inhabilitar las métricas, puedes comentar la línea ./components/metrics:

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

En las siguientes secciones se hablará de todos estos componentes, cuándo se pueden usar y cómo se pueden configurar.

OpenShift

Si quieres instalar Apigee Hybrid en un clúster de OpenShift, es posible que tengas que habilitar algunos componentes o recursos antes de realizar la instalación. Este paso es obligatorio si no usas la secuencia de comandos para realizar la instalación. Los archivos que deben modificarse son los siguientes:

• overlays/initialization/openshift/kustomization.yaml . En la sección resources:, descomenta lo siguiente:

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

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

  # - ./components/openshift-scc
  

  y descomenta el campo "components:" si sigue comentado.

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

  # - ./components/openshift-scc
  

  y descomenta el campo "components:" si sigue comentado.

A continuación, puedes seguir los pasos de instalación.

imagepullsecret

Este componente se puede habilitar cuando tengas imágenes almacenadas en tu repositorio privado. Para extraer imágenes de un repositorio privado, puedes crear un secreto de Kubernetes que contenga tus detalles de autenticación y, a continuación, hacer referencia a este secreto. Para obtener instrucciones, consulta Configurar imagePullSecrets (opcional). Consulta más información en el artículo Extraer una imagen de un registro privado | Kubernetes de la documentación de Kubernetes.

Idioma

• 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

Habilitar:

Descomenta la línea "./components/imagepullsecret/" en los archivos kustomization.yaml correspondientes cuando sea necesario.

Cambios que debes hacer:

• components/imagepullsecret/patch.yaml
  • OBLIGATORIO Añade los nombres de los secretos pertinentes a la lista de spec.template.spec.imagePullSecrets.

Uso:

1. Si aún no has instalado Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán durante el proceso.

2. Si ya tiene instalado Apigee Hybrid, deberá aplicar estos nuevos cambios con el siguiente comando:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

nodeselector

Este componente te permite programar pods para un recurso de Apigee en nodos específicos. Consulta Asignar pods a nodos | Kubernetes para obtener más información.

Idioma

• 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

Habilitar:

Descomenta la línea "./components/nodeselector" en los archivos kustomization.yaml correspondientes cuando sea necesario.

Cambios que debes hacer:

• components/nodeselector/patch.yaml
  • OPCIONAL: Cambia el valor de la etiqueta del selector de nodos de apigee-runtime o apigee-data al que quieras.

Uso:

1. Si aún no has instalado Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán durante el proceso.

2. Si ya tiene instalado Apigee Hybrid, deberá aplicar estos nuevos cambios con el siguiente comando:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

workload-identity

Varios contenedores del ecosistema de Apigee Hybrid requieren permisos para hacer determinadas llamadas a la API del plano de control o de gestión de Apigee. La identidad de carga de trabajo es una de las formas de conceder estos permisos a los pods (y a los contenedores que contienen). Estos son algunos recursos útiles para obtener más información: - Presentamos Workload Identity: una mejor autenticación para tus aplicaciones de GKE | Blog de Google Cloud - Usar Workload Identity | Documentación de Kubernetes Engine | Google Cloud

Idioma

• 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

Requisito:

Para poder usar Workload Identity, debes conceder los permisos pertinentes en tu proyecto de Google Cloud mediante lo siguiente:

    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

donde: - ${ORG_NAME}: el nombre de tu organización de Apigee. - ${APIGEE_NAMESPACE}: el espacio de nombres de Kubernetes en el que se han instalado los componentes de Apigee. Normalmente, sería apigee, a menos que el usuario lo cambie explícitamente durante la instalación. - ${KSA_NAME}: el nombre del espacio de nombres de Kubernetes. Deberás ejecutar este comando para cada cuenta de servicio de Kubernetes mencionada en Cuentas de servicio de Kubernetes - ${GSA_NAME}: nombre de la cuenta de servicio de Google Cloud. Si no has hecho ningún cambio durante la instalación, tendrá el valor apigee-all-sa. Si configuras varias cuentas de servicio de Google Cloud para componentes individuales, tendrás que hacer coincidir el valor de KSA_NAME con el de GSA_NAME correspondiente. Puedes comparar las tablas de cuentas de servicio de Google Cloud con las de cuentas de servicio de Kubernetes para encontrar las equivalencias.

Habilitar:

Descomenta la línea ./components/workload-identity en los archivos kustomization.yaml correspondientes cuando sea necesario. Ten en cuenta que, en la telemetría, tenemos complementos de identidad de carga de trabajo independientes para los componentes metrics y logger, que se pueden habilitar individualmente.

Uso:

1. Si aún no has instalado la opción híbrida, puedes habilitar la identidad de carga de trabajo como se menciona en la sección anterior y continuar con la instalación, que usará automáticamente la identidad de carga de trabajo.

2. Si ya tiene instalado Apigee Hybrid, deberá aplicar estos nuevos cambios con el siguiente comando:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

http-proxy

Puede configurar un servidor proxy en cada uno de los siguientes componentes para que el tráfico de ese componente pase por el proxy HTTP configurado para él. Puedes configurar el proxy de cada componente de Apigee por separado.

Idioma

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

Habilitar:

Descomenta la línea "./components/http-proxy/" en los archivos kustomization.yaml correspondientes cuando sea necesario.

Cambios que debes hacer:

• components/http-proxy/patch.yaml Los siguientes parámetros se pueden configurar en spec.httpForwardProxy
  • scheme: OBLIGATORIO. Uno de los valores HTTP o HTTPS.
  • host: OBLIGATORIO La dirección de host de tu proxy.
  • port: OBLIGATORIO El número de puerto.
  • username: OPCIONAL El nombre de usuario asociado a tu proxy.
  • password: OPCIONAL La contraseña para acceder al proxy.

Uso:

1. Si aún no has instalado Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán durante el proceso.

2. Si ya tiene instalado Apigee Hybrid, deberá aplicar estos nuevos cambios con el siguiente comando:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

registrador y métricas

Puede habilitar o inhabilitar individualmente los registradores o las métricas en overlays/instances/{INSTANCE_NAME}/telemetry. De forma predeterminada, el registrador está inhabilitado y las métricas están habilitadas. Para habilitarlas o inhabilitarlas, solo tienes que quitar o añadir el comentario de sus líneas en telemetry/kustomization.yaml.

gcs-backup y gcs-restore

Este componente de Kustomize se puede usar para crear una copia de seguridad y restaurar la base de datos de Cassandra en Google Cloud Storage.

Idioma

• overlays/instances/{INSTANCE_NAME}/datastore

Requisito:

1. Descarga las claves de las cuentas de servicio de Google Cloud de una cuenta que tenga el rol Administrador de objetos de Storage.

   • Si has usado la secuencia de comandos para realizar la instalación y no has usado identidades de carga de trabajo, puedes reutilizar las claves descargadas disponibles en la carpeta service-accounts, que crea la secuencia de comandos.

   • También puedes usar la secuencia de comandos create-service-account.sh para crear una cuenta de servicio y descargar sus claves:

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

2. Una vez que se hayan descargado las claves, debes crear un secreto de Kubernetes con el nombre apigee-cassandra-backup-and-restore-gcp-sa-key. Para ello, puedes usar el siguiente 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}"
   

   Donde:

   • ${PATH_TO_SA_KEY}: ruta al archivo que contiene las claves de la cuenta de servicio.
   • ${APIGEE_NAMESPACE}: el espacio de nombres de Kubernetes en el que se han instalado los componentes de Apigee. Normalmente, sería apigee, a menos que se haya cambiado explícitamente durante la instalación.

También puedes usar el archivo de plantilla templates/secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml para crear este secreto.

Habilitar:

• Si quieres habilitar la copia de seguridad, quita el comentario de la línea "./components/gcs-backup" del archivo datastore kustomization.yaml.
• Si quieres restaurar una copia de seguridad, quita el comentario de la línea "./components/gcs-restore" del archivo datastore kustomization.yaml.

Modificaciones solo para copias de seguridad

• components/gcs-backup/apigee-datastore-patch.yaml
  • OBLIGATORIO Cambia el valor de la variable de entorno DATABASE_STORAGE_BUCKET, que tendrá el formato gs://BUCKET_NAME y apuntará al segmento de Google Cloud Storage en el que se deben crear copias de seguridad de los datos. La descripción coincide con dbStorageBucket, descrito aquí.
• components/gcs-backup/cron-patch.yaml
  • OBLIGATORIO Cambia spec.schedule para especificar la frecuencia de la copia de seguridad. El campo acepta el formato de programación Crontab estándar. La descripción coincide con la programación descrita aquí.
  • OBLIGATORIO Cambia el valor de la variable de entorno DATABASE_STORAGE_BUCKET, que tendrá el formato gs://BUCKET_NAME y apuntará al segmento de Google Cloud Storage en el que se deben crear copias de seguridad de los datos. La descripción coincide con dbStorageBucket, descrito aquí.
  • OPCIONAL: cambia el valor de HTTP_PROXY_URL para que apunte a cualquier proxy configurado. El formato podría ser el siguiente:
    • 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}

Realizando copia de seguridad

Puedes hacer la copia de seguridad con el siguiente comando:

kubectl apply -k overlays/instances/{INSTANCE_NAME}

Para aplicar los cambios y habilitar la copia de seguridad, sigue estos pasos:

Modificaciones solo para restaurar

• components/gcs-restore/apigee-datastore-patch.yaml
  • OBLIGATORIO Cambia el valor de la variable de entorno DATABASE_STORAGE_BUCKET, que tendrá el formato gs://NOMBRE_DEL_SEGMENTO y apuntará al segmento de Google Cloud Storage en el que se deben crear copias de seguridad de los datos. La descripción coincide con dbStorageBucket descrito aquí.
• components/gcs-restore/job-patch.yaml
  • OBLIGATORIO Cambia el valor de la variable de entorno DATABASE_STORAGE_BUCKET, que tendrá el formato gs://NOMBRE_DEL_SEGMENTO y apuntará al segmento de Google Cloud Storage en el que se deben crear copias de seguridad de los datos.
  • OBLIGATORIO Cambia el valor de la variable de entorno BACKUP_SNAPSHOT_TIMESTAMP. La descripción coincide con la restauración:snapshotTimestamp descrita aquí.
  • OPCIONAL: cambia el valor de HTTP_PROXY_URL para que apunte a cualquier proxy configurado. El formato podría ser el siguiente:
    • 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}

Para realizar la restauración, sigue estos pasos:

Para obtener información general sobre la restauración de copias de seguridad, consulta el artículo Restaurar copias de seguridad | Apigee X | Google Cloud.

1. Crea un clúster de Kubernetes con un nuevo espacio de nombres en el que restaurar la implementación del tiempo de ejecución híbrido. No puedes usar el mismo clúster y espacio de nombres que usaste en la instalación híbrida original.

2. Instala Hybrid en el nuevo clúster con los ajustes configurados anteriormente, además de cualquier otro ajuste que quieras:

   • Puedes usar la instalación básica e instalar la versión híbrida en el nuevo espacio de nombres:

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

   • También puedes seguir las instrucciones para realizar una instalación personalizada de Apigee Hybrid y configurar los elementos que quieras.

3. Una vez que se haya completado la restauración, se podrán eliminar todos los recursos del espacio de nombres antiguo y cambiarlos al nuevo.

Para obtener más información, consulta Restaurar copias de seguridad.

non-gcs-backup y non-gcs-restore

Este componente de Kustomize se puede usar para crear una copia de seguridad y restaurar la base de datos de Cassandra en Google Cloud Storage.

Idioma

• overlays/instances/{INSTANCE_NAME}/datastore

Requisito:

1. Puedes seguir los pasos de la documentación que ya existe para configurar el servidor y SSH.

2. En los pasos anteriores, has tenido que usar la clave privada SSH, que está disponible en el archivo "ssh_key" generado. A continuación, crearemos un secreto de Kubernetes con el nombre apigee-cassandra-backup-and-restore-gcp-sa-key que contenga esta clave privada SSH.

   ---

   Nota: Asegúrate de que tu archivo de clave privada SSH tenga una línea nueva al final.

   ---

   El secreto de Kubernetes se puede crear con el siguiente comando:

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

   Donde:

   • ${PATH_TO_SSH_PRIVATE_KEY}: ruta al archivo que contiene la clave SSH privada
   • ${APIGEE_NAMESPACE}: el espacio de nombres de Kubernetes en el que se han instalado los componentes de Apigee. Normalmente, sería apigee, a menos que se haya cambiado explícitamente durante la instalación.

   También puedes usar el archivo de plantilla templates/secret-apigee-cassandra-backup-and-restore-key-file.yaml para crear este secreto.

Habilitar:

• Si quieres habilitar la copia de seguridad, quita el comentario de la línea "./components/non-gcs-backup" del archivo datastore kustomization.yaml.
• Si quieres restaurar una copia de seguridad, quita el comentario de la línea "./components/non-gcs-restore" del archivo datastore kustomization.yaml.

Modificaciones solo para copias de seguridad

• components/non-gcs-backup/apigee-datastore-patch.yaml
  • OBLIGATORIO Cambia el valor de BACKUP_SERVER_IP. La descripción coincide con BACKUP_SERVER_IP, descrito aquí.
  • OBLIGATORIO Cambia el valor de BACKUP_STORAGE_DIR. La descripción coincide con BACKUP_STORAGE_DIR, descrito aquí.
• components/non-gcs-backup/cron-patch.yaml
  • OBLIGATORIO Cambia spec.schedule para especificar la frecuencia de la copia de seguridad. El campo acepta el formato de programación Crontab estándar. La descripción coincide con la programación descrita aquí.
  • OBLIGATORIO Cambia el valor de BACKUP_SERVER_IP. La descripción coincide con BACKUP_SERVER_IP, descrito aquí.
  • OBLIGATORIO Cambia el valor de BACKUP_STORAGE_DIR. La descripción coincide con BACKUP_STORAGE_DIR, descrito aquí.
  • OPCIONAL: cambia el valor de HTTP_PROXY_URL para que apunte a cualquier proxy configurado. El formato podría ser el siguiente:
    • 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}

Realizando copia de seguridad

Puedes hacer la copia de seguridad con el siguiente comando:

kubectl apply -k overlays/instances/{INSTANCE_NAME}

Para aplicar los cambios y habilitar la copia de seguridad, sigue estos pasos:

Modificaciones solo para copias de seguridad

• components/non-gcs-restore/apigee-datastore-patch.yaml
  • OBLIGATORIO Cambia el valor de BACKUP_SERVER_IP. La descripción coincide con la BACKUP_SERVER_IP descrita aquí.
  • OBLIGATORIO Cambia el valor de BACKUP_STORAGE_DIR. La descripción coincide con la BACKUP_STORAGE_DIR descrita aquí.
• components/non-gcs-restore/job-patch.yaml
  • OBLIGATORIO Cambia el valor de la variable de entorno BACKUP_SNAPSHOT_TIMESTAMP. La descripción coincide con la restore:snapshotTimestamp descrita aquí.
  • OBLIGATORIO Cambia el valor de BACKUP_SERVER_IP. La descripción coincide con la BACKUP_SERVER_IP descrita aquí.
  • OBLIGATORIO Cambia el valor de BACKUP_STORAGE_DIR. La descripción coincide con la BACKUP_STORAGE_DIR descrita aquí.
  • OPCIONAL Cambia el valor de HTTP_PROXY_URL para que apunte a cualquier proxy configurado. El formato podría ser el siguiente:
    • 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}

Para realizar la restauración, sigue estos pasos:

Para obtener información general sobre la restauración de copias de seguridad, consulta Información general sobre la restauración de Cassandra.

1. Crea un clúster de Kubernetes con un nuevo espacio de nombres en el que restaurar la implementación del tiempo de ejecución híbrido. No puedes usar el mismo clúster y espacio de nombres que usaste en la instalación híbrida original.

2. Instala Hybrid en el nuevo clúster con los ajustes configurados anteriormente, además de cualquier otro ajuste que quieras: Puedes usar la instalación básica y instalar Hybrid en el nuevo espacio de nombres:

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

   También puedes seguir las instrucciones para realizar una instalación personalizada de Apigee Hybrid y configurar los elementos que quieras.

3. Una vez que se haya completado la restauración, se podrán eliminar todos los recursos del espacio de nombres antiguo y cambiarlos al nuevo.

   Para obtener más información, consulta Programar copias de seguridad en un servidor remoto.

http-client

Para obtener instrucciones, consulta Habilitar clientes HTTP | Apigee.

Idioma

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

Habilitar:

Quita el comentario de la línea "./components/http-client" del archivo route-config/${ENV_GROUP}/kustomization.yaml correspondiente

Cambios que debes hacer:

• No es necesario hacer ninguna modificación obligatoria.

Uso:

1. Si aún no has instalado Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán durante el proceso.

2. Si ya tiene instalado Apigee Hybrid, deberá aplicar estos nuevos cambios con el siguiente comando:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

non-sni-client

Es el equivalente al artículo Cómo configurar un cliente que no es de la SNI | Apigee.

Idioma

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

Habilitar:

Quita el comentario de la línea "./components/non-sni-client" del archivo route-config/${ENV_GROUP}/kustomization.yaml correspondiente

Cambios que debes hacer:

• components/non-sni-client/apigee-route.yaml
  • OBLIGATORIO credentialName La descripción coincide con lo credential_name que se indica aquí.

Uso:

1. Si aún no has instalado Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán durante el proceso.

2. Si ya tiene instalado Apigee Hybrid, deberá aplicar estos nuevos cambios con el siguiente comando:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

http-and-non-sni-client

Para obtener instrucciones, consulta Habilitar la compatibilidad con clientes que no sean SNI ni HTTP | Apigee.

Habilitar:

Quita el comentario de la línea "./components/http-and-non-sni-client" del archivo route-config/${ENV_GROUP}/kustomization.yaml correspondiente

Cambios que debes hacer:

• components/http-and-non-sni-client/apigee-route.yaml
  • OBLIGATORIO credentialName La descripción coincide con lo credential_name que se indica aquí.

Uso:

1. Si aún no has instalado Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán durante el proceso.

2. Si ya tiene instalado Apigee Hybrid, deberá aplicar estos nuevos cambios con el siguiente comando:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

multirregional

Este componente se puede usar al configurar una implementación de Cassandra multirregional. Para obtener más información, consulta Despliegues multirregionales en GKE y GKE On-Prem.

Habilitar:

Quita el comentario de la línea "./components/multi-region" del archivo datastore/kustomization.yaml

Cambios que debes hacer:

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

  • OBLIGATORIO source.region Nombre del centro de datos de Cassandra de origen que se usará para replicar los datos. Se puede identificar mediante el siguiente comando en el clúster de origen:

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

• components/multi-region/patch.yaml

  • OBLIGATORIO spec.components.properties.multiRegionSeedHost La IP del pod de cualquiera de los pods de Cassandra de origen. Podemos usar:

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

  • Para obtener una lista con todos los pods y la IP de cualquier pod de Cassandra, usa el siguiente comando:

  kubectl get pods -o wide -n apigee
  

  La salida debería tener un aspecto similar al siguiente:

  NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
  apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
  apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
  apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch
  

Para obtener más información, consulta los requisitos de GKE en "Despliegues multirregionales en GKE, GKE On-Prem y AKS":

Uso:

El uso de este componente tiene sentido sobre todo cuando configuras Apigee Hybrid en un clúster nuevo y ya tienes otra configuración de Apigee Hybrid que funciona.

1. Tanto el clúster nuevo como el antiguo deben usar los mismos certificados TLS para asegurar que los pods de Cassandra se comuniquen correctamente. Por lo tanto, tendremos que copiar el secreto apigee-root-certificate del clúster actual y usarlo también en el nuevo:

2. Ejecuta lo siguiente:

   kubectl config get-contexts
   

   • Para obtener una lista de todos los contextos de Kubernetes y, a continuación, ejecutar

   kubectl config use-context SOURCE_CLUSTER_CONTEXT
   

   donde SOURCE_CLUSTER_CONTEXT es el nombre del contexto del clúster de Kubernetes de origen.

3. Almacena el secreto del certificado raíz en un archivo:

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

4. Cambia el contexto del clúster al nuevo clúster en el que vas a instalar Apigee Hybrid.

   kubectl config use-context ${NEW_CLUSTER_CONTEXT}
   

5. Crea el secreto raíz en el nuevo clúster:

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

6. Inhabilita la creación de un nuevo certificado raíz. De esta forma, nos aseguraremos de no crear un nuevo apigee-root-certificate y sobrescribir el que hemos creado en el paso anterior.

7. Descomenta las siguientes líneas del archivo overlays/initialization/certificates/kustomization.yaml:

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

8. Continúa con el resto de la instalación de Apigee Hybrid mediante la instalación básica de Apigee Hybrid o la instalación personalizada de Apigee Hybrid. Por ejemplo, siguiendo la instalación básica de Apigee Hybrid, puedes ejecutar lo siguiente:

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

9. Verifica el estado de la recompilación con el siguiente comando.

   ---

   Nota: La operación de reconstrucción puede tardar varias horas en función del tamaño de los datos.

   ---

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

10. Verifica los procesos de recompilación en los registros. Además, comprueba el tamaño de los datos con el comando de estado de nodetool:

    kubectl logs apigee-cassandra-default-0 -f -n ${APIGEE_NAMESPACE}
    kubectl exec apigee-cassandra-default-0 -n ${APIGEE_NAMESPACE}  -- nodetool -u ${JMX_USER} -pw ${JMX_PASSWORD} status
    

11. Verifica el estado de la recompilación con el siguiente comando.

    ---

    Nota: La operación de reconstrucción puede tardar varias horas en función del tamaño de los datos.

    ---

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

    Los resultados deberían ser similares a los siguientes:

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

    Consulta también Despliegue multirregional.

12. Elimine las siguientes líneas de components/multi-region/patch.yaml:

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

13. Aplica los cambios:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}
    

Conceptos

Image Hub

Las imágenes de contenedor Docker suelen especificarse en el siguiente formato:

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

o que usan un resumen, como este:

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

Apigee usa el concepto de "Image Hub", que en los formatos anteriores hace referencia a ${REGISTRY_HOST_PATH}. El valor predeterminado del centro de imágenes es gcr.io/apigee-release/hybrid/.

Las imágenes que utilicen DIGEST deberán configurarse individualmente en cada subcomponente.

Apigee crea la ruta de imagen final combinando los siguientes valores:

• "Image Hub", que se puede anular en apigee-hybrid-config.yaml (consulta la sección Usar imágenes de Docker de repositorios privados para ver los pasos detallados sobre cómo anular Image Hub).
• El valor de IMAGE_TAG se obtiene del campo version, que se encuentra en el archivo YAML de cada uno de los componentes (por ejemplo, apigee-organization.yaml). Apigee etiqueta las imágenes con la versión de Apigee Hybrid, lo que significa que IMAGE_TAG es 1.8 para la versión 1.8 de Apigee Hybrid.
• IMAGE_NAME se determina implícitamente a partir del nombre del contenedor en el que se usará la imagen. Por ejemplo, en el caso del contenedor apigee-runtime, IMAGE_NAME será apigee-runtime.

Por lo tanto, un ejemplo completo de una ruta de imagen sería gcr.io/apigee-release/hybrid/apigee-runtime:1.8.0

De esta forma, se construye la ruta de la imagen final, que se usaría en cada uno de los contenedores de sus respectivos pods.

Cuentas de servicio de Google Cloud

Las cuentas de servicio de Google Cloud son cuentas que usan las aplicaciones para hacer llamadas autorizadas a las APIs de Google. Se pueden descargar claves de cuentas de servicio de Google Cloud, que se pueden usar para la autenticación. Apigee espera que el usuario proporcione claves de cuenta de servicio creando secretos. A continuación, se indican los nombres de los componentes y el nombre predeterminado del secreto en el que busca las claves de cuenta de servicio:

Componente	Subcomponente	Nombre de secreto de Kubernetes predeterminado que contiene la clave de la cuenta de servicio
organización
	connectAgent	apigee-connect-agent-gcp-sa-key-${ORG_NAME}
	watcher	apigee-watcher-gcp-sa-key-${ORG_NAME}
	mart	apigee-mart-gcp-sa-key-${ORG_NAME}
	udca	apigee-udca-gcp-sa-key-${ORG_NAME}
	ingressGateways	N/A
entorno
	runtime	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}
telemetría
	métricas	apigee-metrics-gcp-sa-key
	containerLogs	apigee-logger-gcp-sa-key

Cuentas de servicio de Kubernetes

Las cuentas de servicio de Kubernetes proporcionan identidades a los pods de tu clúster. De forma predeterminada, el controlador de Apigee los crea automáticamente. Sin embargo, si quieres anular la creación (por ejemplo, cuando usas identidades de carga de trabajo), puedes hacerlo especificando el campo podServiceAccountName en los distintos subcomponentes.

Lista de componentes y sus respectivos subcomponentes en los que se puede especificar la cuenta de servicio de Kubernetes junto con el nombre predeterminado de la cuenta de servicio de Kubernetes cuando se habilita el parche de identidad de carga de trabajo.

Componente	Subcomponente	Nombre predeterminado (disponible cuando se ha habilitado el parche de Workload Identity)
organización
	connectAgent	apigee-connect-agent-svc-account-${ORG_NAME}
	watcher	apigee-watcher-svc-account-${ORG_NAME}
	mart	apigee-mart-svc-account-${ORG_NAME}
	udca	apigee-udca-svc-account-${ORG_NAME}
entorno
	sincronizador	apigee-synchronizer-svc-account-${ORG_NAME}-${ENV_NAME}
	udca	apigee-udca-svc-account-${ORG_NAME}-${ENV_NAME}
	runtime	apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME}
datastore
	cassandra	apigee-datastore-svc-account
telemetría
	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 trabajo

Las identidades de carga de trabajo permiten que los pods (que usan cuentas de servicio de Kubernetes) que se ejecutan en GKE se autentiquen directamente en las APIs de Google Cloud sin necesidad de usar claves de cuentas de servicio de Google Cloud.

Añadir un nuevo entorno

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

Añadir un nuevo entorno es tan sencillo como hacer lo siguiente:

1. Crear una carpeta en el directorio de entornos (o en la estructura de carpetas que hayas definido)
2. Copiar el archivo apigee-environment.yaml de cualquier entorno en la carpeta nueva.
3. Si quieres crear una cuenta de servicio y claves de cifrado para el nuevo entorno, copia el secrets.yaml en la nueva carpeta y cambia el nombre de los secretos para distinguirlos de los de los demás entornos (normalmente, se añade el nombre del entorno como sufijo).
4. Hacer los cambios oportunos en el apigee-environment.yaml, como:
   • Cambiar el nombre del entorno
   • Si se van a crear nuevas cuentas de servicio y claves de cifrado, deben referenciarse correctamente en el archivo YAML.
5. Aplicar los yaml:

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

Usar la eliminación forzada en Apigee Datastore

Si la eliminación del almacén de datos no avanza por algún motivo, ahora se puede forzar la eliminación del almacén de datos de Apigee con los siguientes comandos, independientemente del estado actual del clúster.

---

Nota: Si usas la eliminación forzada, también se eliminarán los PVCs. Por lo tanto, si la implementación actual de Apigee Hybrid es de un solo motivo, haz una copia de seguridad antes de continuar.

---

---

Nota: Si se usa la eliminación forzada en clústeres multirregión, es necesario realizar una limpieza manual en otras regiones una vez que se haya completado la eliminación del almacén de datos para que Cassandra siga funcionando correctamente. Consulta la guía de solución de problemas para saber cómo hacer una limpieza manual.

---

1. Elimina apigeeds en el espacio de nombres apigee:

   Kubectl delete -n apigee apigeeds default
   

   Si este paso se bloquea, puedes salir con CTRL + C.

2. Editar un apigeeds nuevo:

   Kubectl edit -n apigee apigeeds default
   

3. Añadir o actualizar el campo forceDelete en la especificación del almacén de datos de Apigee

   spec:
   forceDelete: true
   

4. Guarda el archivo y sal.

Ahora, espera a que se elimine el almacén de datos. Eliminar todos los recursos de Cassandra puede tardar unos minutos.

Información sobre la secuencia de comandos

La secuencia de comandos apigee-hybrid-setup.sh realiza algunas validaciones básicas y ayuda a automatizar los pasos que, de lo contrario, tendrías que seguir si quieres una personalización más detallada, tal como se describe en Instalación personalizada de Apigee Hybrid. Incluso con la instalación personalizada, puedes usar el script parcialmente para que te ayude con determinadas tareas.

Puedes ejecutar ./tools/apigee-hybrid-setup.sh --help para ver una lista de las marcas admitidas y obtener ayuda adicional con la secuencia de comandos. Por el momento, se admiten las siguientes marcas:

• --namespace De forma predeterminada, la secuencia de comandos instala todos los componentes en el espacio de nombres apigee. Puedes cambiar este comportamiento especificando el nombre del espacio de nombres con esta marca.
• --org Se usa para proporcionar el nombre de la organización de Apigee. Si no se especifica ningún valor, se utiliza el proyecto de Google Cloud seleccionado en gcloud de forma predeterminada.
• --envgroup Se usa para proporcionar el nombre del grupo de entornos de tu organización. Si no se especifica, se intenta consultar las APIs del plano de control para determinar el nombre del grupo de entornos. Si se encuentran varios grupos de entornos, se devuelve un error y se cierra la secuencia de comandos.
• --env Se usa para proporcionar el nombre del entorno de tu organización. Si no se especifica, se intenta consultar las APIs del plano de control para determinar el nombre del entorno. Si se encuentran varios entornos o el entorno no forma parte del grupo de entornos, se devuelve un error y se cierra la secuencia de comandos.
• --cluster-name Nombre del clúster de Kubernetes.
• --cluster-region La región en la que se encuentra el clúster de Kubernetes
• --gcp-project-id El ID del proyecto de Google Cloud en el que se encuentra el clúster de Kubernetes.
• --ingress-domain Especifica el nombre de host o de dominio que se usará para generar los certificados TLS autofirmados de istio ingress-gateway. Si no se especifica ninguno, se intenta determinar el valor consultando las APIs del plano de control para obtener el valor del grupo de entornos. Si ha habido algún problema al determinar el grupo de entornos o se han configurado varios nombres de host para el grupo de entornos, se devuelve un error y el script se cierra.
• --generate-internal-tls-certs Se generará un secreto de Kubernetes llamado apigee-ca que contiene un par de claves y un certificado generados por nosotros.
• --create-ingress-tls-certs Se generará un secreto llamado {ORG_NAME}-{ENV_GROUP_NAME} (derivado del nombre de la organización y del grupo de entornos) en el espacio de nombres istio-system, que contendrá un par de certificado y clave que se usará para la comunicación TLS. El nombre de dominio que se usa para generar estos certificados se deriva del valor que se encuentra en la configuración de envgroup. En caso de conflicto (por ejemplo, si encontramos varios dominios), se mostrarán los mensajes de error correspondientes.
• --create-gcp-sa-and-secrets Crea una cuenta de servicio de Google Cloud en el proyecto de Google Cloud, descarga las claves y, a continuación, crea los secretos de Kubernetes que contienen la clave. Los nombres de los secretos se pueden encontrar en las cuentas de servicio de Google Cloud.
• --fill-values Sustituye los valores de org, env, envgroup y otros nombres en los distintos archivos YAML en los que se requieran.
• --apply-configuration Se crearán los emisores de certificados, las definiciones de recursos personalizados, los webhooks, los roles y el recurso de controlador. Los recursos se crearán en el orden correcto y el comando se bloqueará hasta que todos estén en buen estado.
• -- rename-directories Cambia el nombre del entorno y del grupo de entornos por los nombres correctos.
• --verbose Muestra una salida detallada para depurar.
• --help Muestra información de uso.
• --setup-all Se ejecutarán todas las tareas que puede realizar este script.

Estructura de carpetas de configuración de Apigee Hybrid

La carpeta apigee-hybrid-setup tiene la siguiente estructura jerárquica de forma predeterminada:

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

Puedes encontrar una versión de los archivos anteriores en la etiqueta preview-1 del repositorio de GitHub: https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1.

La carpeta anterior contiene manifiestos de Kubernetes para el entorno de ejecución de Apigee hybrid y usa Kustomize para gestionar la configuración. Los manifiestos se organizan según el concepto de bases y superposiciones de Kustomize. La carpeta bases contiene la configuración mínima necesaria para cada componente de Apigee. La carpeta de superposiciones contiene varias funciones adicionales(configuraciones) que se definen como componentes. Para activar un componente, descomenta la referencia del componente en el archivo kustomization.yaml.

Ejemplo : Para habilitar gcs-backup en el almacén de datos de Apigee, se ha quitado el comentario del componente gcs-backup en el archivo customization.yaml que se muestra a continuación.

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

Cualquier valor que requiera personalizaciones deberá definirse en el archivo patch.yaml correspondiente de gcs-backup. En el archivo de abajo, el usuario debe definir el valor de CLOUD_STORAGE_BUCKET_PATH.

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

Del mismo modo, cualquier función o configuración que requiera personalizaciones se puede habilitar descomentando el componente en el archivo kustomization.yaml del componente apigee. Además, según sea necesario, se deben definir los valores correspondientes de los campos del archivo patch.yaml del componente.

Breve explicación de las carpetas y los archivos:

bases

Esta carpeta contiene las plantillas con la configuración mínima necesaria para cada uno de los componentes de Apigee. No sería necesario modificar los manifiestos de esta carpeta.

superposiciones

Esta carpeta contiene las plantillas de componentes de Kustomize para las configuraciones adicionales.

inicialización

namespaces.yaml

Espacio de nombres en el que se instalarán los componentes del plano de datos de Apigee. El nombre del espacio de nombres predeterminado es apigee.

certificados

Contiene los recursos Issuer y Certificate que se usan para emitir certificados a los webhooks. También contiene el Issuer que se usa para emitir certificados a varios pods para la comunicación TLS.

rbac

Contiene los Role, ClusterRole, RoleBinding y ClusterRoleBinding que usarán varios componentes.

crds

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

Webhooks

Contiene ValidatingWebhookConfiguration y MutatingWebhookConfiguration que se usarán para realizar validaciones en los recursos personalizados.

entrada

Contiene la configuración que se aplica a todos los pods de entrada. Por ejemplo, Modificación de encabezados comunes, comprobación del estado, etc.

openshift

Contiene la definición de SecurityContextConstraints de OpenShift.

Controladores

apigee-controller

apigee-hybrid-config.yaml

Contiene un ConfigMap que se proporciona como entrada en apigee-controller-manager.yaml. Este ConfigMap contiene configuraciones como imageHub, imagePullSecrets y forwardProxy, entre otras.

apigee-controller-deployment.yaml

Contiene dos servicios para el controlador y el webhook, así como el Deployment del controlador. Si quieres usar una imagen privada para el controlador, aquí es donde tendrás que hacer el cambio.

istiod

Apigee-istio-mesh-config.yaml Contiene la configuración de la malla de Istio que usa Apigee. Esto no se aplica a otras instalaciones de ASM o Istio en el clúster.

apigee-ingressgateway-manager-deployment-patch.yaml

Contiene un servicio y una implementación de Istiod. Se trata de un istiod privado que solo se usa en los casos prácticos de Apigee.

instances/{instanceName}

datastore

apigee-datastore.yaml

Contiene el ApigeeDatastore recurso personalizado que gestiona Cassandra.

secrets.yaml

Contiene las credenciales predeterminadas del almacén de datos.

redis

apigee-redis.yaml

Contiene el recurso personalizado ApigeeRedis que gestiona Redis.

secrets.yaml

Contiene las credenciales predeterminadas del almacén de datos.

organización

apigee-organization.yaml

Contiene el recurso personalizado ApigeeOrganization, que gestiona otros subcomponentes, como connectAgent, watcherAndSynchronizer, MART, UDCA e Ingress.

secrets.yaml

Contiene los Secrets a los que se hace referencia en apigee-organization.yaml. Algunos secretos se comentan porque los genera la secuencia de comandos. Si inhabilitas su generación, tendrás que crear manualmente esas

environments

Contiene todo el entorno de tu organización. Debe crear una carpeta independiente para cada entorno copiando la que ya se le ha proporcionado y configurándola según sus necesidades.

dev

apigee-environment.yaml

Contiene el recurso personalizado ApigeeEnvironment, que gestiona otros subcomponentes, como el tiempo de ejecución.

secrets.yaml

Contiene los Secrets a los que se hace referencia en apigee-environment.yaml. Algunos secretos se comentan porque los genera la secuencia de comandos. Si inhabilitas su generación, tendrás que crear esos

telemetría

apigee-telemetry.yaml

Contiene el recurso personalizado ApigeeTelemetry.

secrets.yaml

Contiene los Secrets a los que se hace referencia en apigee-telemetry.yaml. Algunos secretos se comentan porque los genera la secuencia de comandos. Si inhabilitas su generación, tendrás que crear manualmente esas

route-config

dev-envgroup

apigee-route-config.yaml

Contiene el recurso personalizado ApigeeRouteConfig.

secrets.yaml

Contiene un Secret al que se hace referencia en apigee-route-config.yaml. Se ha comentado porque el script apigee-hybrid-setup.sh lo genera automáticamente y se mantiene ahí para proporcionar un ejemplo de cómo debería ser el secreto si lo crearas manualmente.

diagnóstico

diagnostic-collector.yaml

Recursos que se usarán para poner en marcha la implementación de diagnóstico

herramientas

apigee-hybrid-setup.sh

apigee-create-service-account.sh

dump-kubernetes.sh

apigee-pull-push.sh

Almacenar claves de cuentas de servicio en almacenes externos

Vault (de HashiCorp) es un sistema de gestión de secretos popular que tiene varias integraciones con almacenes de secretos proporcionados por Google, Azure, AWS y otros. HashiCorp Vault te permite obtener secretos de una fuente externa y, a continuación, usarlos en recursos de Kubernetes. Hay varias formas de usar Vault para obtener secretos. Los siguientes pasos sirven como ejemplo básico de cómo usar el proveedor de CSI de Vault para montar claves de cuentas de servicio de Google Cloud almacenadas en algún motor de secretos proporcionado por Vault.

---

Nota: En este ejemplo, vamos a instalar Vault en modo de desarrollo para hacer pruebas. En un sistema de producción real, te recomendamos que instales Helm en uno de los otros modos que se indican aquí. Para obtener información detallada sobre cómo instalar Vault para casos prácticos de producción, consulta la guía de implementación de Vault en Kubernetes | Vault

.

---

1. Usaremos Helm para instalar recursos relacionados con Vault en tu clúster. Sigue los pasos que se indican en Instalar Helm para configurar Helm en tu sistema.

2. Sigue los pasos que se indican en el artículo Instalar el gráfico de Helm de Vault, es decir:

   1. Añadir el repositorio de HashiCorp a Helm

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

   2. Actualizar repositorios de Helm

      helm repo update
      

   3. Instalar Vault

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

3. Ahora vamos a almacenar el secreto en Vault.

   1. Obtener un shell en el pod de desarrollo de Vault

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

   2. En este ejemplo, usaremos el motor secreto de clave/valor para almacenar datos.

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

   3. Para verificar que la clave se ha almacenado correctamente, usa el siguiente comando:

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

4. Configura la autenticación para permitir que el pod de tiempo de ejecución extraiga la clave. Como se explica en Cuentas de servicio de Kubernetes, las cuentas de servicio de Kubernetes proporcionan identidad a los pods y les permiten autenticarse en otros sistemas.

   1. Obtener un shell en el pod de desarrollo de Vault

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

   2. Habilitar el método de autenticación de Kubernetes

      vault auth enable kubernetes
      

   3. Escribir la configuración de autenticación

      vault write auth/kubernetes/config \
      issuer="https://kubernetes.default.svc.cluster.local" \
      token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
      kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \
      kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
      disable_iss_validation=true
      

   4. Crea la política de autenticación

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

   5. Vincular la política con la cuenta de servicio

      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
      

   Aquí, suponemos que la cuenta de servicio está en el espacio de nombres apigee. Si tienes otro espacio de nombres para instalar apigee, usarás ese nombre.

   1. Salir del shell dentro de vault-0

      exit
      

5. Instalar el controlador de CSI de almacén de secretos

   # Add repo to helm
   helm repo add secrets-store-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/secrets-store-csi-driver/master/charts
   # Install driver in cluster
   helm install csi secrets-store-csi-driver/secrets-store-csi-driver
   

6. Crea un recurso de SecretProviderClass de Kubernetes que haga referencia al secreto que has creado en Vault.

   cat > spc-vault.yaml <<EOF
   apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
   kind: SecretProviderClass
   metadata:
   name: vault-apigee-runtime-gcp-sa-key
   spec:
   provider: vault
   parameters:
     vaultAddress: "http://vault.default:8200"
     roleName: "apigee-runtime-role"
     objects: |
       - objectName: "client_secret.json"
         secretPath: "secret/data/runtime-gcp-sa-key"
         secretKey: "key"
   EOF
   

7. Aplica la yaml

   kubectl apply -f spc-vault.yaml
   

8. Crea la cuenta de servicio de Kubernetes a la que hemos asignado los permisos en el paso 4.e.

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

9. Modifica el archivo apigee-environment.yaml del entorno y añade las siguientes líneas:

   apiVersion: apigee.cloud.google.com/v1alpha2
   kind: ApigeeEnvironment
   # existing content
   spec:
   name: {ENV_NAME}
   organizationRef: {ORG_NAME}
   components:
    runtime:
   # existing content
      pod
      containers:
      - name: apigee-runtime
        podServiceAccountName: apigee-runtime-sa
   # existing content
        volumeMounts:
        - name: secrets-store-inline
          mountPath: "/opt/apigee/sa"
          readOnly: true
      volumes:
      - name: secrets-store-inline
        csi:
          driver: secrets-store.csi.k8s.io
          readOnly: true
          volumeAttributes:
            secretProviderClass: "vault-apigee-runtime-gcp-sa-key"
   

10. Aplica los cambios:

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

Actualización de Apigee Hybrid

---

Nota: Este procedimiento abarca las actualizaciones entre versiones híbridas que admiten el nuevo modelo de instalación. No se explica cómo migrar de la experiencia de apigeectl al nuevo modelo de instalación.

---

Debes haber completado todos los requisitos mencionados en la sección Requisitos previos. También te recomendamos que reinicies todos los componentes de forma gradual para comprobar si el clúster está en buen estado. El orden de los reinicios será Cassandra, Redis, ApigeeOrganization y ApigeeEnvironment.

Crear copia de seguridad

1. Crea una copia de seguridad de la configuración híbrida actual. Necesitarás una copia de seguridad por si tienes que revertir la actualización a la versión actual.

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

2. Crea una copia de seguridad de la base de datos de Cassandra. Las copias de seguridad de Cassandra son una medida de protección importante frente a situaciones de desastre.

Actualizar la plataforma de Kubernetes si es necesario

No es necesario realizar este paso cada vez, pero tendrás que actualizar tu plataforma de Kubernetes (como Kubernetes y OpenShift) y componentes (como cert-manager y Cassandra) si ya no son compatibles con la versión más reciente de Apigee Hybrid. La documentación incluirá las versiones compatibles de las plataformas y los componentes.

Descargar archivos de configuración

Descarga el repositorio y sustituye las carpetas bases y tools de la configuración de Apigee hybrid por una más reciente:

1. Clona la etiqueta preview-1 del repositorio de GitHub en https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1.

   El repositorio clonado tendrá una estructura similar a la que se describe en Estructura de carpetas de configuración de Apigee Hybrid:

2. Sustituye las carpetas de inicialización, herramientas y controlador en la configuración de Apigee hybrid.

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

Actualizar los permisos de la cuenta de servicio si es necesario

Este paso tampoco es necesario cada vez, pero tendrás que crear una cuenta de servicio o actualizar los permisos de las cuentas de servicio que ya tengas si es necesario. En la guía de actualización se indica qué cuentas de servicio se deben modificar o crear y qué roles se deben añadir.

• Si necesitas modificar los permisos de las cuentas de servicio, usa el comando gcloud adecuado. En la guía de actualización se incluirán los comandos y los roles detallados que se deben añadir.

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

• Si la versión más reciente de Apigee Hybrid requiere una cuenta de servicio adicional para los componentes nuevos o actuales, debes crearla. Puedes usar la secuencia de comandos apigee-create-service-account.sh incluida en la carpeta de la herramienta para crear cuentas de servicio. Como la secuencia de comandos ya se habrá actualizado en el paso 4, tendrá los detalles y el nuevo perfil necesarios para crear una cuenta de servicio.

  El nombre de la cuenta de servicio que acabas de crear debe aparecer en el CR del componente correspondiente.

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

Actualizar el mando

Cambia los campos de versión de los componentes que se indican en ${INSTALL_DIR}/overlays/instances/$INSTANCE_DIR/kustomization.yaml a la versión híbrida correspondiente.

A continuación se muestra un archivo $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/kustomization.yaml de ejemplo. El valor del campo de versión debe actualizarse a la versión correspondiente

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)

Sigue los mismos pasos que se indican en Crear recursos de inicialización y controlador en el flujo de trabajo de instalación de Apigee Hybrid. Puedes usar una secuencia de comandos o seguir los pasos manuales que se indican para actualizar los recursos de inicialización y el controlador.

Actualizar componentes de Kubernetes de Apigee

Deberá hacer los siguientes cambios: - En caso de que se produzcan cambios en la arquitectura, se introduzcan campos nuevos o se dejen de usar campos antiguos, tendrá que modificar los CRs con los cambios adecuados según las instrucciones de la guía de actualización. - Como mínimo, debes actualizar los campos de versión de los CRs (que indicarán la versión de Apigee Hybrid instalada) a la versión más reciente de Apigee Hybrid.

Aplica los cambios en los CRs de Apigee. En el entorno de no producción, puede aplicar todos los cambios a los componentes de Apigee simultáneamente.

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

Restauración de Apigee Hybrid

1. Restaurar apigee-hybrid-setup

   Ve al directorio que contiene la versión anterior de la configuración de Apigee Hybrid. Si no está disponible, restáuralo desde el archivo ZIP creado en el paso 1[link] durante la actualización de Apigee Hybrid.

2. Revertir componentes de Kubernetes

   Aplica los cambios en los CRs de Apigee

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

3. Controlador de restauración

   Sigue los mismos pasos que se indican en Crear recursos de inicialización y controlador del flujo de trabajo de instalación de Apigee Hybrid. Puedes usar una secuencia de comandos o seguir los pasos manuales que se indican para revertir los recursos de inicialización y el controlador.

4. Limpieza

   Deberá eliminar los recursos adicionales que se hayan creado durante la actualización, como los componentes o las cuentas de servicio que se hayan introducido en la versión más reciente del híbrido. En la guía de actualización se indicarán todos los recursos que se deben limpiar y los pasos para hacerlo.

Eliminar un entorno

---

Precaución: Si tienes varios entornos, asegúrate de que los secretos que vas a eliminar no se referencien en los demás entornos. Para comprobarlo, ejecuta kubectl get env -n ${APIGEE_NAMESPACE} ${ENV_RESOURCE_NAME} -o yaml y, a continuación, busca el recurso que quieras eliminar.

---

A continuación, se indican los pasos para eliminar todos los recursos relacionados con un entorno de tu clúster de Kubernetes:

1. Obtén el nombre del CR de Environment. Para ello, puedes obtener todos los entornos:

   kubectl get env -n ${APIGEE_NAMESPACE}
   

   Almacena el nombre del recurso en la variable de entorno APIGEE_ENV.

2. Elimina las claves de cifrado del entorno. Por ejemplo, si no has cambiado el nombre de las claves de cifrado, puedes eliminarlas con el siguiente comando:

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

3. Elimina los secretos de la cuenta de servicio de Google Cloud:

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

4. Elimina las cuentas de servicio de Kubernetes:

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

5. Elimina el recurso personalizado del entorno de Apigee:

   kubectl -n ${APIGEE_NAMESPACE} delete env $APIGEE_ENV
   

Eliminar una configuración híbrida

---

Precaución: Estos son los pasos que se deben seguir para instalar Apigee Hybrid de forma normal. Los pasos varían ligeramente en casos avanzados, como cuando se tiene una segunda organización en el mismo clúster, etc.

---

A continuación, se indican los pasos para eliminar todos los recursos relacionados con Apigee Hybrid de tu clúster de Kubernetes:

1. Deberá eliminar los trabajos de configuración de usuario y de configuración de esquema de Apigee.

   # To list all jobs in ${APIGEE_NAMESPACE}
   kubectl -n ${APIGEE_NAMESPACE} get jobs
   # To delete all jobs in ${APIGEE_NAMESPACE}
   kubectl -n ${APIGEE_NAMESPACE} delete jobs $(kubectl -n ${APIGEE_NAMESPACE} get jobs -o custom-columns=':.metadata.name')
   

2. Tendrás que eliminar los componentes del plano de datos de Apigee hybrid implementados. Usa el siguiente comando para eliminar todos los componentes:

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

3. Este paso solo es necesario si no has usado el nombre predeterminado para los secretos de la cuenta de servicio de Kubernetes, los secretos de la cuenta de servicio de Google Cloud, etc. Si has usado los nombres predeterminados, se eliminarán en el siguiente paso. De lo contrario, tendrás que eliminarlos manualmente con los siguientes comandos:

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

4. En el caso de OpenShift, tendrás que eliminar los SCCs (Security Context Constraints) creados durante la instalación de Apigee hybrid.

   kubectl delete scc ${SECURITY_CONTEXT_CONSTRAINTS_NAME}
   

5. Ejecuta el siguiente comando para eliminar roles, RoleBindings, CRDs, implementaciones de controladores, etc.

   kubectl delete -k ${INSTALL_DIR}/overlays/initialization/ingress
   kubectl delete -k ${INSTALL_DIR}/overlays/initialization/rbac
   kubectl delete -k ${INSTALL_DIR}/overlays/initialization/webhooks
   kubectl delete -k ${INSTALL_DIR}/overlays/initialization/crds
   kubectl delete -k ${INSTALL_DIR}/overlays/initialization/certificates
   

6. Ejecuta el siguiente comando para eliminar el espacio de nombres de Apigee:

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

   También puedes usar el comando:

   kubectl delete $APIGEE_NAMESPACE
   

Instalación de varias instancias

La configuración de varias instancias hace referencia a la configuración híbrida que puede abarcar varias regiones o estar en la misma región. Apigee recomienda organizar las configuraciones de la segunda instancia en una estructura de directorios independiente, ya que las configuraciones del entorno (réplicas, etc.) siempre son diferentes entre las instancias. Las configuraciones de cada instancia están desacopladas y se organizan de forma independiente en sus respectivas estructuras de carpetas.

Por ejemplo, en una configuración Activa-Pasiva en un escenario multirregional, puede que quieras configurar una segunda región en espera activa con diferentes tamaños y configuraciones.

En la estructura de carpetas que se muestra a continuación, puede hacer una copia del directorio instance1 llamada instance2 y modificar las configuraciones de almacenamiento de datos y de entrada según sea necesario.

apigee-hybrid-setup estructura de carpetas para la configuración de varias instancias.]

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

Configuración de varias instancias en GKE

Requisitos previos

Antes de configurar varias instancias de híbrido, debes haber completado los siguientes requisitos previos:

• Configurar clústeres de Kubernetes en varias regiones(iguales o diferentes) con diferentes bloques CIDR
• Configurar la comunicación entre regiones
• Abre los puertos 7000 y 7001 de Cassandra entre los clústeres de Kubernetes de todas las regiones (el puerto 7000 se puede usar como opción de copia de seguridad durante la solución de problemas). Consulta también Configurar puertos.

---

Nota: Apigee recomienda que te asegures de que la hora de tus servidores esté sincronizada. Varias funciones, como la caducidad y la revocación de tokens, dependen de la hora del sistema. Si alojas los componentes del tiempo de ejecución en centros de datos diferentes, asegúrate de que las horas del sistema estén sincronizadas.

Puedes usar una herramienta como ntpdate para comprobar que las horas del servidor estén sincronizadas.

---

Configurar el host de seed multirregional

1. Crea una copia de la carpeta $INSTANCE_NAME de tu instancia y añádela a la carpeta instances.
2. Modifique el valor del campo de espacio de nombres si es diferente del espacio de nombres de instance1.
3. Sigue los pasos que se indican en Especificar certificados TLS de entrada para modificar la configuración de entrada de la otra instancia.

4. Consulta el artículo Gestionar la puerta de enlace de entrada de Apigee para obtener información sobre cómo configurar la IP del balanceador de carga de la otra instancia.

   ---

   Nota: No se recomienda modificar las configuraciones del resto de los componentes, excepto las que se indican en los próximos pasos.

   ---

5. Define el contexto de kubectl en el clúster original antes de obtener el nombre de la semilla

   kubectl config use-context original-cluster-name
   

6. Ejecuta el siguiente comando kubectl para identificar una dirección de host de inicialización de Cassandra en la región actual.

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

7. Cualquiera de las IPs de Pod devueltas por el comando anterior se puede considerar como el host de seed multirregión.

8. En la segunda instancia, configura el valor de multiRegionSeedHost en el CR de almacén de datos de Apigee en ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/apigee-datastore.yaml.

Configurar la nueva instancia

1. Define el contexto en el clúster

   kubectl config use-context existing-cluster-name
   

2. Exportar el secreto apigee-ca a un archivo

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

3. Define el contexto con el nombre del clúster de la nueva región:

   kubectl config use-context NEW_CLUSTER_NAME
   

4. Importar el secreto al nuevo clúster

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

5. Instala el modo híbrido en la nueva instancia (región) siguiendo los pasos que se indican en Crear recursos de inicialización y controlador.

6. Configura Cassandra en todos los pods de los nuevos centros de datos. Obtén apigeeorg del clúster con el siguiente comando:

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

7. Crea un archivo de recurso personalizado de replicación de datos de Cassandra (YAML). El archivo puede tener cualquier nombre. En los siguientes ejemplos, el archivo se llamará datareplication.yaml. El archivo debe contener lo siguiente:

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

   Donde:

   • REGION_EXPANSION es el nombre que le asignas a estos metadatos. Puedes elegir un nombre como "cassandra-data-replication".
   • NAMESPACE es el mismo espacio de nombres que se eligió para la segunda instancia. Normalmente es "apigee".
   • APIGEEORG_VALUE es el valor que devuelve el comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" del paso anterior.
   • SOURCE_REGION es el valor del centro de datos de Cassandra del estado de la herramienta de nodos del clúster de origen.

8. Aplica CassandraDataReplication con el siguiente comando:

   kubectl apply -f datareplication.yaml
   

9. Verifica el estado de la recompilación con el siguiente comando.

   ---

   Nota: La operación de reconstrucción puede tardar varias horas en función del tamaño de los datos.

   ---

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

   El resultado debería ser similar a este:

   {
   "rebuildDetails": {
     "apigee-cassandra-default-0": {
       "state": "complete",
       "updated": 1623105760
     },
     "apigee-cassandra-default-1": {
       "state": "complete",
       "updated": 1623105765
     },
     "apigee-cassandra-default-2": {
       "state": "complete",
       "updated": 1623105770
     }
   },
   "state": "complete",
   "updated": 1623105770
   }
   

10. Verifica los procesos de recompilación en los registros. Además, comprueba el tamaño de los datos con el comando de estado de nodetool:

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

    Consulta datastore/secrets.yaml para obtener el JMX_user y el JMX_password.

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

11. Quita multiRegionSeedHost del CR del almacén de datos de Apigee y ejecuta el siguiente comando para aplicar el cambio:

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

12. Comprobar el estado del clúster de Cassandra

    El siguiente comando es útil para comprobar si la configuración del clúster se ha realizado correctamente en dos centros de datos. El comando comprueba el estado de nodetool de las dos regiones.

    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
    

Solución de problemas

Guía de asistencia, diagnóstico y solución de problemas

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

Limpieza manual después de usar forceDelete en una configuración de Apigee Hybrid multirregión

• En el siguiente ejemplo, hay dos regiones: us-east1 y us-west1.
• En la región us-west1, se ha eliminado el almacén de datos de Apigee mediante la eliminación forzada.
• En la región us-east1, Cassandra sigue funcionando.

• Verificar que apigeeds se ha eliminado mediante un comando

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

• Cambia el contexto de kubectl a la otra región en la que el clúster de Cassandra siga activo (en este caso, us-east1).

• Verificar que el almacén de datos está en estado de ejecución

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

• Ejecuta en uno de los pods de Cassandra de la región activa (en este caso, la región us-east1).

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

• Comprueba el estado de nodetool. Verás que todos los nodos de la región eliminada (en este caso, us-west1) están inactivos.

  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
  

• Elimina todos los nodos de la región eliminada (en este caso, 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
  

• Verifica que no queden nodos de la región eliminada (aquí 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
  

• Una vez completado este paso, elimina el trabajo de configuración del usuario en la región superior (en este caso, us-east1). El trabajo se volverá a crear automáticamente en unos 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
  

• Esperar a que se complete el trabajo de configuración del usuario

  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
  

• Verifica que los espacios de claves no tengan la región eliminada.

• Crea un pod de depuración de Cassandra.

  • Si tienes la versión 1.5 o posterior de Hybrid, sigue la documentación de la guía de solución de problemas de Cassandra (por ejemplo, para Hybrid 1.5, consulta este enlace y, para Hybrid 1. 6, este enlace). Después, ejecuta el pod creado.

• Inicia sesión en cqlsh en el pod de depuración con el comando

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

• Verifica que la región us-west1 se haya quitado de todos los espacios de claves

  ddl_user@cqlsh> SELECT * FROM system_schema.keyspaces;
  

  keyspace_name              | durable_writes | replication
  ---------------------------+----------------+-----------------------------------------------------------------------------------
  cache_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
    rtc_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
                  system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
                system_schema |           True |                            {'class': 'org.apache.cassandra.locator.LocalStrategy'}
  quota_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
    kms_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
           system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
                       system |           True |                            {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                       perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
    kvm_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
                system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
  (11 rows)