Esta página se ha traducido con Cloud Translation API.

Actualizar Apigee Hybrid a la versión 1.8

<0x

Sigue los mismos procedimientos para actualizar versiones secundarias (por ejemplo, de la versión 1.7 a la 1.8) y para actualizar versiones de parche (por ejemplo, de la versión 1.8.0 a la 1.8.8).

Si vas a actualizar desde la versión 1.6 o una anterior de Apigee hybrid, primero debes actualizar a la versión 1.7 antes de actualizar a la 1.8.8. Consulta las instrucciones para actualizar Apigee Hybrid a la versión 1.7.

Si ya tienes la versión 1.8.0 de Hybrid y quieres migrar a la puerta de enlace de entrada de Apigee desde Anthos Service Mesh, consulta el artículo Migrar a la puerta de enlace de entrada de Apigee.

Presentamos la pasarela de entrada de Apigee

A partir de la versión 1.8, Apigee Hybrid ofrece una nueva función para gestionar la puerta de enlace de entrada de tu instalación híbrida: puerta de enlace de entrada de Apigee. Anthos Service Mesh ya no es un requisito previo para la instalación híbrida. Con la pasarela de entrada de Apigee, Apigee dejará de proporcionar configuración de enrutamiento a Anthos Service Mesh. Después de la actualización, debes migrar el tráfico a la nueva puerta de enlace de entrada de Apigee para poder empezar a usar la función.

Apigee usa un pequeño subconjunto de las funciones de Anthos Service Mesh para la puerta de enlace de entrada. A partir de la versión 1.8 de Apigee Hybrid, Apigee Hybrid incluye una pasarela de entrada que se instala y actualiza como parte de las actualizaciones de Apigee Hybrid. Por lo tanto, no es necesario que tengas experiencia con Anthos Service Mesh para instalar, actualizar y gestionar Apigee Hybrid. Los problemas relacionados con las versiones de la puerta de enlace de entrada y la compatibilidad con las versiones de Apigee Hybrid se gestionan automáticamente.

Hay dos situaciones en las que se puede migrar:

Migración entre varios clústeres o varias regiones (recomendado):
Antes de cambiar a un nuevo Ingress para Apigee, deriva todo el tráfico a otro clúster u otra región desde el clúster que estés migrando. De este modo, tendrá tiempo para comprobar si la nueva pasarela de entrada de Apigee funciona correctamente. A continuación, vuelve a dirigir el tráfico al clúster actualizado.
Actualización in situ (no recomendada en entornos de producción):
Durante la actualización, Apigee activará la nueva pasarela de entrada con la dirección IP que especifiques. Después, puedes probar si la nueva pasarela de entrada de Apigee funciona correctamente y, a continuación, desviar el tráfico a la nueva entrada. Puede que haya un periodo de inactividad durante esta actualización.

Cuando actualices Apigee hybrid a la versión 1.8, debes configurar la pasarela de entrada de Apigee en tu archivo de anulaciones. Después de actualizar, usted controla qué tipo de pasarela de entrada usarán sus clústeres dirigiendo los registros A o CNAME de su registrador a la dirección IP de la pasarela de entrada de Apigee o de Anthos Service Mesh.

Información general sobre la actualización a la versión 1.8.8

La actualización a la versión 1.8 de Apigee Hybrid puede requerir un tiempo de inactividad.

Al actualizar el controlador de Apigee a la versión 1.8.8, todas las implementaciones de Apigee se reinician de forma gradual. Para minimizar el tiempo de inactividad en entornos híbridos de producción durante un reinicio gradual, asegúrate de que tienes al menos dos clústeres (en la misma región o centro de datos, o en regiones o centros de datos diferentes). Desvía todo el tráfico de producción a un solo clúster y desconecta el clúster que vas a actualizar. A continuación, continúa con el proceso de actualización. Repite el proceso con cada clúster.

Apigee recomienda que actualice todos los clústeres lo antes posible para reducir las probabilidades de que se produzcan problemas en producción. No hay límite de tiempo para actualizar todos los clústeres restantes después de que se haya actualizado el primero. Sin embargo, hasta que se actualicen todos los clústeres restantes, se verán afectadas las siguientes operaciones:

La copia de seguridad y la restauración de Cassandra no funcionan con versiones mixtas. Por ejemplo, una copia de seguridad de Hybrid 1.7 no se puede usar para restaurar una instancia de Hybrid 1.8.
La transmisión de datos de Cassandra no funcionará entre versiones híbridas mixtas. Por lo tanto, tus clústeres de Cassandra no se pueden escalar horizontalmente.
La ampliación y la retirada de regiones se verán afectadas, ya que estas operaciones dependen del streaming de datos de Cassandra.

Los procedimientos para actualizar Apigee hybrid se organizan en las siguientes secciones:

Prepárate para cambiar a un plan superior.
Instala la versión 1.8.8 del entorno de ejecución híbrido.
En el caso de la pasarela de entrada, elige una de las siguientes opciones:
- (Recomendado) Usa la nueva pasarela de entrada de Apigee y sigue los pasos que se indican en el artículo Cambiar el tráfico de Anthos Service Mesh a la pasarela de entrada de Apigee.
- Sigue usando Anthos Service Mesh para tu pasarela de entrada.

Requisitos previos

En estas instrucciones de actualización se da por hecho que tienes instalada la versión 1.7.x de Apigee hybrid o una versión anterior de la versión 1.8.x y que quieres actualizarla a la versión 1.8.8. Si vas a actualizar desde una versión anterior, consulta las instrucciones para actualizar Apigee hybrid a la versión 1.7.

Si prefieres seguir usando Anthos Service Mesh, debes asegurarte de que se actualice a una versión compatible. Consulta la tabla Plataformas compatibles para ver las versiones compatibles de Anthos Service Mesh.

Prepararse para actualizar a la versión 1.8

Crear una copia de seguridad de tu instalación híbrida (recomendado)

En estas instrucciones se usa la variable de entorno APIGEECTL_HOME para el directorio del sistema de archivos en el que has instalado apigeectl. Si es necesario, cambia el directorio al directorio apigeectl y define la variable con el siguiente comando:
Linux
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
macOS
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
echo %APIGEECTL_HOME%
```
Crea una copia de seguridad del directorio 1.7 de $APIGEECTL_HOME/. Por ejemplo:
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.7-backup.tar.gz $APIGEECTL_HOME
```
Crea una copia de seguridad de tu base de datos de Cassandra siguiendo las instrucciones de Copia de seguridad y recuperación de Cassandra.

Añade el rol Agente de Cloud Trace a la cuenta de servicio del entorno de ejecución de Apigee. (Opcional)

Opcional: Si tienes previsto usar Cloud Trace y aún no has realizado este paso en tu instalación híbrida v1.7, asegúrate de que la cuenta de servicio de tus servicios de tiempo de ejecución de Apigee tenga el rol de Google Agente de Cloud Trace. (roles/cloudtrace.agent).

En los entornos de producción, suele ser la cuenta de servicio apigee-runtime. En los entornos que no son de producción, suele ser la cuenta de servicio apigee-non-prod.

Puedes añadir el rol en la interfaz de usuario Consola de Cloud > Gestión de identidades y accesos > Administración > Cuentas de servicio o con los siguientes comandos:

Obtén la dirección de correo de tu cuenta de servicio con el siguiente comando:
Producción
```
gcloud iam service-accounts list --filter "apigee-runtime"
```
Si coincide con el patrón apigee-runtime@$ORG_NAME.iam.gserviceaccount.com, puedes usarlo en el siguiente paso.
Non-Prod
```
gcloud iam service-accounts list --filter "apigee-non-prod"
```
Si coincide con el patrón apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com, puedes usarlo en el siguiente paso.

Asigna el rol Agente de Cloud Trace a la cuenta de servicio:

Producción

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

Non-Prod

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-non-prod@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Ejemplo

gcloud projects add-iam-policy-binding hybrid-example-project \
    --member="serviceAccount:apigee-runtime@hybrid-example-project.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Donde $PROJECT_ID es el nombre del proyecto de Google Cloud en el que está instalado Apigee hybrid.

Nota: Si tu instalación usa un nombre personalizado para la cuenta de servicio, sustituye ese nombre por apigee-runtime o apigee-non-prod en el comando.

Prepararse para instalar la pasarela de entrada de Apigee

Para instalar la pasarela de entrada de Apigee como parte de la actualización. Debe añadir la siguiente propiedad ingressGateways a su archivo de anulaciones.

Sintaxis

ingressGateways:
- name: INGRESS_NAME
  replicaCountMin: REPLICAS_MIN
  replicaCountMax: REPLICAS_MAX
  resources:
    requests:
      cpu: CPU_COUNT_REQ
      memory: MEMORY_REQ
    limits:
      cpu: CPU_COUNT_LIMIT
      memory: MEMORY_LIMIT
  svcAnnotations:  # optional. See Known issue 243599452.
    SVC_ANNOTATIONS_KEY: SVC_ANNOTATIONS_VALUE
  svcLoadBalancerIP: SVC_LOAD_BALANCER_IP # optional

Ejemplo

ingressGateways:
- name: prod1
  replicaCountMin: 2
  replicaCountMax: 100
  resources:
    requests:
      cpu: 1
      memory: 1Gi
    limits:
      cpu: 2
      memory: 2Gi

INGRESS_NAME es el nombre del despliegue de entrada. Puede ser cualquier nombre que cumpla los siguientes requisitos:
- Tener una longitud máxima de 17 caracteres
- Contener solo caracteres alfanuméricos en minúscula, guiones ("-") o puntos (".").
- Empezar con un carácter alfanumérico
- Terminar con un carácter alfanumérico
Consulta ingressGateways[].name en la referencia de la propiedad de configuración.
REPLICAS_MIN y REPLICAS_MAX son el número mínimo y máximo de réplicas de la puerta de enlace de entrada de Apigee en tu instalación. Para obtener más información y conocer los ajustes predeterminados, consulta ingressGateways[].replicaCountMin y ingressGateways[].replicaCountMax en la referencia de la propiedad Configuration.
CPU_COUNT_REQ y MEMORY_REQ son la solicitud de CPU y memoria de cada réplica de la puerta de enlace de entrada de Apigee en tu instalación.
Solo debes definir estas propiedades si ya las has definido para tu pasarela de entrada de Anthos Service Mesh, por ejemplo, en tu archivo overlay.yaml.

Para obtener más información y conocer los ajustes predeterminados, consulta ingressGateways[].resources.requests.cpu y ingressGateways[].resources.requests.memory en la referencia de la propiedad Configuration.
CPU_COUNT_LIMIT y MEMORY_LIMIT: los límites máximos de CPU y memoria de cada réplica de la puerta de enlace de entrada de Apigee en tu instalación.
Solo debes definir estas propiedades si ya las has definido para tu pasarela de entrada de Anthos Service Mesh, por ejemplo, en tu archivo overlay.yaml.

Para obtener más información y conocer los ajustes predeterminados, consulta ingressGateways[].resources.limits.cpu y ingressGateways[].resources.limits.memory en la referencia de la propiedad Configuration.
SVC_ANNOTATIONS_KEY y SVC_ANNOTATIONS_VALUE (opcional):
Nota: El campo ingressGateways[].svcAnnotations de overrides.yaml no funciona como se espera. Consulta el problema conocido 243599452
.
Se trata de un par clave-valor que proporciona anotaciones para tu servicio de entrada predeterminado. Tu plataforma en la nube usa las anotaciones para ayudarte a configurar tu instalación híbrida. Por ejemplo, puedes definir el tipo de balanceador de carga como interno o externo. Por ejemplo:
```
ingressGateways:
  svcAnnotations:
    networking.gke.io/load-balancer-type: "Internal"
```
Las anotaciones varían de una plataforma a otra. Consulta la documentación de tu plataforma para ver las anotaciones obligatorias y sugeridas.

Nota: No es necesario que defina Annotations si va a crear su propio servicio de Kubernetes para la implementación de entrada, tal como se describe en el artículo Exponer la pasarela de entrada de Apigee.
Consulta ingressGateways[].svcAnnotations en la referencia de la propiedad de configuración.
SVC_LOAD_BALANCER_IP (opcional) Te permite asignar una dirección IP estática a tu balanceador de carga. En las plataformas que admiten la especificación de la dirección IP del balanceador de carga, este se creará con esa dirección IP. En las plataformas que no permiten especificar la dirección IP del balanceador de carga, esta propiedad se ignora.
Si no tienes una dirección IP estática asignada a tu balanceador de carga, no incluyas esta propiedad en tu archivo de anulaciones.

Precaución: No especifiques la misma dirección IP que el istio-ingressgateway actual. Esto podría causar problemas mientras ese servicio siga en el clúster.

Nota: No es necesario que definas LoadBalancerIP si vas a crear tu propio servicio de Kubernetes para la implementación de ingress, tal como se describe en el artículo Exponer la pasarela de ingress de Apigee.
Consulta ingressGateways[].svcLoadBalancerIP en la referencia de la propiedad de configuración.

Haz cambios adicionales en el archivo de anulaciones para habilitar o inhabilitar funciones opcionales de la versión 1.8

Añade las siguientes propiedades a tu archivo overrides.yaml para habilitar las nuevas funciones de la versión 1.8 de híbrida. Estas funciones son opcionales.

La UDCA de ámbito de organización ahora está activada de forma predeterminada. Si usas una sola implementación de UDCA para gestionar el tráfico de todos los entornos, se evita la infrautilización de los pods de UDCA y se aumenta la disponibilidad de los recursos de los nodos para otros componentes de Apigee. La UDCA con ámbito de organización usa una sola cuenta de servicio para todos los entornos, apigee-udca.
Si usas diferentes cuentas de servicio para UDCA en distintos entornos, ten en cuenta que ahora se usará la cuenta de servicio especificada a nivel de organización en tu archivo de anulaciones con udca:serviceAccountPath, en lugar de las especificadas a nivel de entorno con envs:udca:serviceAccountPath.

Apigee Hybrid v. 1.8 admite UDCA con ámbito de entorno. Para mantener la UDCA por entorno, defina orgScopedUDCA: false.

Nota: La compatibilidad con UDCA con ámbito de entorno no estará disponible en futuras versiones de Apigee hybrid.

Consulta orgScopedUDCA en la referencia de propiedades de configuración.
Habilita validateOrg para requerir una validación estricta de que la organización y el entorno de Apigee estén activos y funcionen con el proyecto de Google Cloud Platform especificado en tu archivo overrides.
```
validateOrg: true
```
Nota: Apigee hybrid permite no usar la validación estricta de organizaciones. Para desactivar la función, asigna el valor validateOrg: false.

Consulta validateOrg en la referencia de propiedades de configuración.

Instalar el entorno de ejecución híbrido 1.8.8

Asegúrate de que estás en el directorio base híbrido (el elemento superior del directorio en el que se encuentra el archivo ejecutable apigeectl):
```
cd $APIGEECTL_HOME/..
```

Descarga el paquete de lanzamiento de tu sistema operativo con el siguiente comando. Selecciona tu plataforma en la siguiente tabla:

Linux

Linux de 64 bits:

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_linux_64.tar.gz

macOS

Mac de 64 bits:

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_mac_64.tar.gz

Windows

Windows (64 bits):

curl -LO ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_windows_64.zip

Cambia el nombre del directorio apigeectl/ actual por el de un directorio de copia de seguridad. Por ejemplo:

Linux

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

macOS

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

Windows

rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.7

Extrae el contenido del archivo gzip descargado en el directorio base híbrido. El directorio base híbrido es el directorio en el que se encuentra el directorio apigeectl-v1.7 renombrado:
Linux
```
tar xvzf filename.tar.gz -C ./
```
macOS
```
tar xvzf filename.tar.gz -C ./
```
Windows
```
tar xvzf filename.zip -C ./
```
De forma predeterminada, el contenido de tar se expande en un directorio con la versión y la plataforma en su nombre. Por ejemplo: ./apigeectl_1.8.8-xxxxxxx_linux_64. Cambia el nombre de ese directorio a apigeectl con el siguiente comando:
Linux
```
mv apigeectl_1.8.8-xxxxxxx_linux_64 apigeectl
```
macOS
```
mv apigeectl_1.8.8-xxxxxxx_mac_64 apigeectl
```
Windows
```
rename apigeectl_1.8.8-xxxxxxx_windows_64 apigeectl
```
Cambia al directorio apigeectl:
```
cd ./apigeectl
```
Este directorio es el apigeectldirectorio principal. Es donde se encuentra el comando ejecutable apigeectl.
En estas instrucciones se usa la variable de entorno $APIGEECTL_HOME para el directorio de tu sistema de archivos en el que está instalada la utilidad apigeectl. Si es necesario, cambia el directorio al directorio apigeectl y define la variable con el siguiente comando:
Linux
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
macOS
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
```
```
echo %APIGEECTL_HOME%
```
Verifica la versión de apigeectl con el comando version:
```
./apigeectl version
```
```
Version: 1.8.8
```
Ve al directorio hybrid-base-directory/hybrid-files. El directorio hybrid-files es donde se encuentran los archivos de configuración, como el archivo de anulaciones, los certificados y las cuentas de servicio. Por ejemplo:
```
cd $APIGEECTL_HOME/../hybrid-files
```
Verifica que kubectl esté configurado en el contexto correcto con el siguiente comando. El contexto actual debe ser el clúster en el que vas a actualizar Apigee Hybrid.
```
kubectl config get-contexts | grep \*
```
En el directorio hybrid-files:
1. Actualiza los siguientes enlaces simbólicos a $APIGEECTL_HOME. Estos enlaces te permiten ejecutar el comando apigeectl recién instalado desde el directorio hybrid-files:
```
ln -nfs $APIGEECTL_HOME/tools tools
ln -nfs $APIGEECTL_HOME/config config
ln -nfs $APIGEECTL_HOME/templates templates
ln -nfs $APIGEECTL_HOME/plugins plugins
```
2. Para comprobar que los enlaces simbólicos se han creado correctamente, ejecuta el siguiente comando y asegúrate de que las rutas de los enlaces apuntan a las ubicaciones correctas:
```
ls -l | grep ^l
```
Haz una inicialización de prueba para comprobar si hay errores:
```
${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client
```
Donde OVERRIDES_FILE es el nombre del archivo de anulaciones. Por ejemplo, ./overrides/overrides.yaml.

Nota: Puedes sustituir OVERRIDES_FILE en el código de ejemplo anterior por el nombre y la ruta de tu archivo de anulaciones. Todas las instancias de esta página se sustituirán.
Si no hay errores, inicializa la versión 1.8.8 de Hybrid. Este comando también instala y configura la pasarela de entrada de Apigee:
```
$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
```
Comprueba el estado de inicialización:
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```
Si la operación se realiza correctamente, se mostrará el siguiente mensaje: All containers ready.

Problema conocido: Después de ejecutar init y confirmar que check-ready se ha completado correctamente, puede que observes, si ves los pods, que la validación del esquema de Cassandra está en un estado de error. Este estado se considera un problema conocido (n.º 245664917) y no supone ningún riesgo. Puedes ignorar el error y continuar con el siguiente paso: apigeectl apply
.
Como comprobación adicional, también puedes ejecutar este comando para comprobar el estado de ApigeeDataStore:
```
kubectl describe apigeeds -n apigee
```
En el resultado, busca State: running.
Comprueba si hay errores con una prueba de funcionamiento del comando apply mediante la marca --dry-run:
```
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
```
Si no hay errores, aplica las anulaciones. Seleccione y siga las instrucciones para entornos de producción o de no producción, según su instalación.
Durante el proceso de actualización, cada componente realizará un reinicio progresivo. Por lo tanto, en los entornos de producción, es mejor aplicar la actualización a un componente cada vez.
Producción

En los entornos de producción, debes actualizar cada componente híbrido por separado y comprobar el estado del componente actualizado antes de pasar al siguiente.
1. Asegúrate de que estás en el directorio hybrid-files.
2. Aplica las anulaciones para actualizar Cassandra:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
3. Comprobación completada:
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
  Nota: Si check-ready falla, puedes obtener más información sobre tus pods con el siguiente comando:
  kubectl -n NAMESPACE get pods
  
  Donde NAMESPACE es el espacio de nombres de Apigee hybrid.
  Continúa con el siguiente paso solo cuando los pods estén listos.
4. Aplica las anulaciones para actualizar los componentes de Telemetría y comprueba que se han completado:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
5. Inicia los componentes de Redis:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
6. Aplica las anulaciones para actualizar los componentes a nivel de organización (MART, Watcher y Apigee Connect) y comprueba si se han completado:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
7. Aplica las anulaciones para actualizar tus entornos. Tienes dos opciones:
  - Entorno por entorno: aplica las anulaciones a un entorno cada vez y comprueba que se completan. Repite este paso para cada entorno:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    
    Donde ENV_NAME es el nombre del entorno que vas a actualizar.
  - Todos los entornos a la vez: aplica las anulaciones a todos los entornos a la vez y comprueba si se han completado:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
8. Aplica las anulaciones para actualizar los componentes virtualhosts y comprueba si se han completado:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
No producción

En la mayoría de los entornos que no son de producción, de demostración o experimentales, puedes aplicar las anulaciones a todos los componentes a la vez. Si tu entorno de no producción es grande y complejo o se parece mucho a un entorno de producción, te recomendamos que sigas las instrucciones para actualizar entornos de producción.
1. Asegúrate de que estás en el directorio hybrid-files.
2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
3. Comprueba el estado:
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Actualizar la versión de Kubernetes

Actualiza tu plataforma de Kubernetes a las versiones compatibles con Hybrid 1.8. Si necesitas ayuda, consulta la documentación de tu plataforma.

Haz clic para desplegar una lista de plataformas compatibles

	Versiones de Apigee Hybrid
Plataformas	1,6 ⁽³⁾	1,7 ⁽³⁾	1,8 ⁽³⁾	1.9	1.10
Anthos (Google Cloud - GKE)	1.19.x 1.20.x 1.21.x	1.20.x 1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.21.x ^{(≤ 1.8.3)} 1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
Anthos (AWS)	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.25⁽¹³⁾	1.12.x 1.13.x 1.25⁽¹³⁾	1.13.x 1.25⁽¹³⁾ 1.26⁽¹³⁾
Anthos (Azure)	1.8.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x	1.12.x 1.13.x 1.14.x	1.13.x 1.14.x 1.15.x
Anthos (on-premises - VMware)⁽¹⁾	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x ⁽⁴⁾ 1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} 1.12.x ⁽⁴⁾ ^{(≥ 1.7.2)}	1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ 1.12.x ⁽⁴⁾ ⁽⁵⁾ 1.13.x ⁽⁵⁾ 1.14.x ⁽⁵⁾ 1.15.x	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
Anthos (Bare Metal)⁽¹⁾	1.7.x 1.8.2+ 1.9.3+ 1.10.x	1.9.x ⁽⁴⁾ 1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} 1.12.x ⁽⁴⁾ ^{(≥ 1.7.2)}	1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ 1.12.x ⁽⁴⁾ ⁽⁵⁾ 1.13.x ⁽⁵⁾ 1.14.x ⁽⁵⁾ 1.15.x	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
EKS⁽⁷⁾	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
AKS⁽⁷⁾	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
OpenShift⁽⁷⁾	4,6 4,7 4,8	4,7 4,8	4,8 4,9 4,10	4.10 4.11	4.11 4.12
Rancher Kubernetes Engine (RKE)⁽⁷⁾	N/A	N/A	N/A	1.3.8	v1.26.2+rke2r1
Componentes	1.6 ⁽³⁾	1,7 ⁽³⁾	1,8	1.9	1.10
Anthos Service Mesh (ASM)	1.9.x 1.10.x 1.12.x 1.13.x	1.10.x 1.11.x 1.12.x 1.13.x ^{(≥ 1.7.2)} 1.14.x 1.15.x ^{(≥ 1.7.6)}	1.11.x 1.12.x 1.13.x 1.14.x 1.15.x	1.17.x⁽¹¹⁾	1.17.x⁽¹¹⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.5.4	1.7.x	1.7.x 1.8.x 1.9.x 1.10.x 1.11.x	1.10.x 1.11.x	1.10.x 1.11.x 1.12.x
Cassandra	3.11.10	3.11.10	3.11.10	3.11.10	3.11.10
⁽¹⁾ En las versiones 1.8, 1.9 y 1.10 de Anthos, sigue las instrucciones de estos documentos para evitar conflictos con `cert-manager`: Anthos 1.8.2 o versiones posteriores: Conflicto con `cert-manager` al actualizar a la versión 1.8.2 o una posterior. Anthos 1.9: Conflicto con `cert-manager` al actualizar a la versión 1.9.0 o 1.9.1. Anthos 1.10 o versiones posteriores: Instalación de `cert-manager` en conflicto. ⁽²⁾ La asistencia está disponible con Apigee hybrid versión 1.7.2 y posteriores. ⁽³⁾ Se han alcanzado las fechas oficiales de finalización del ciclo de vida de las versiones 1.8 y anteriores de Apigee hybrid. Los parches mensuales periódicos ya no están disponibles. Estas versiones ya no se admiten oficialmente, excepto para los clientes que tengan excepciones explícitas y oficiales para seguir recibiendo asistencia. Otros clientes deben actualizarse. ⁽⁴⁾Las versiones 1.12 y anteriores de Anthos en Bare Metal y VMware ya no tienen asistencia. Consulta la política de asistencia de versiones de Anthos en Bare Metal y las versiones de clústeres de Anthos en VMware. ⁽⁵⁾Anthos en Bare Metal y VMware requiere ASM 1.14 o una versión posterior. Te recomendamos que actualices a la versión 1.8 híbrida y que cambies a la puerta de enlace de entrada de Apigee, que ya no requiere que instales ASM en tu clúster híbrido. ⁽⁶⁾ La asistencia está disponible en Apigee hybrid versión 1.8.4 y posteriores. ⁽⁷⁾ Los clústeres adjuntos no son necesarios para Apigee hybrid v1.8 y versiones posteriores que usen Apigee ingressgateway. ⁽⁸⁾ No se admite en Apigee hybrid versión 1.8.4 y posteriores. ⁽⁹⁾ La asistencia está disponible en Apigee hybrid versión 1.7.6 y posteriores. ⁽¹⁰⁾ No se admite en Apigee Hybrid versión 1.8.5 y posteriores. ⁽¹¹⁾ ASM se instala automáticamente con Apigee hybrid 1.9 y versiones posteriores. ⁽¹²⁾ La asistencia está disponible con Apigee Hybrid versión 1.9.2 y posteriores. ⁽¹³⁾ Los números de versión de los clústeres de Anthos en AWS (multinube) ahora reflejan las versiones de Kubernetes. Consulta la compatibilidad con versiones y actualizaciones de Anthos para obtener información sobre las versiones y los parches recomendados.

Acerca de los clústeres vinculados

En las versiones híbridas de Apigee 1.7.x y anteriores, debes usar clústeres adjuntos de Anthos si quieres ejecutar Apigee hybrid en un contexto multicloud en Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) u otro proveedor de servicios de Kubernetes de terceros compatible. La asociación de clústeres permite a Google medir el uso de Anthos Service Mesh (ASM). Registrar el clúster de terceros es opcional. Regístrate solo si quieres ver el clúster adjunto en la Google Cloud console. Para obtener más información, consulta el artículo sobre cómo asociar clústeres de Kubernetes de terceros a Google Cloud.

En la versión híbrida 1.8.x de Apigee, se necesitan clústeres adjuntos de Anthos si usas Anthos Service Mesh para tu pasarela de entrada. Si utilizas la pasarela de entrada de Apigee, los clústeres adjuntos de Anthos son opcionales.

Cambiar el tráfico de Anthos Service Mesh a la pasarela de entrada de Apigee

Para cambiar el tráfico a la pasarela de entrada de Apigee, sigue estos pasos:

Exponga la pasarela de entrada de Apigee. Sigue los procedimientos que se indican en Exponer la pasarela de entrada de Apigee.
Prueba tu nueva pasarela de entrada llamando a un proxy. Lo ideal es que pruebes todos los proxies cruciales que tengas implementados.
Para cambiar el tráfico, actualiza tus registros DNS para que apunten a la dirección IP de tu nueva pasarela de entrada de Apigee. En función de tu proveedor de DNS, es posible que puedas transferir el tráfico gradualmente al nuevo endpoint.
Nota: Puedes encontrar la dirección IP externa de la pasarela de entrada de Apigee con el siguiente comando:
```
kubectl get svc -n apigee -l app=apigee-ingressgateway
```
La salida debería tener un aspecto similar a este:
```
NAME                                        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                      AGE
apigee-ingressgateway-prod-hybrid-37a39bd   LoadBalancer   192.0.2.123   233.252.0.123   15021:32049/TCP,80:31624/TCP,443:30723/TCP   16h
```
Para comprobar que todo el tráfico de tiempo de ejecución funciona, monitoriza tus paneles de control. Solo debes continuar con el siguiente paso si todo funciona correctamente. Asegúrate de que no haya tráfico que pase por tu antigua puerta de enlace de entrada (Anthos Service Mesh), ya que la actualización del DNS puede tardar en propagarse debido al almacenamiento en caché del DNS.
Para evitar que Apigee proporcione configuración a Anthos Service Mesh, sigue los pasos que se indican en Dejar de proporcionar configuración a ASM en la guía para gestionar la pasarela de entrada de Apigee.
Vuelve a probar y monitoriza el tráfico del proxy de API.
Sigue las instrucciones de la documentación de Anthos Service Mesh para desinstalar Anthos Service Mesh del clúster.

Actualizar Anthos Service Mesh a la versión 1.15

Sigue los procedimientos que se indican en la documentación de Anthos Service Mesh correspondiente a tu plataforma:

Las instrucciones para instalar y configurar Anthos Service Mesh varían en función de la plataforma. Las plataformas se dividen en las siguientes categorías:

GKE clústeres de Google Kubernetes Engine que se ejecutan en Google Cloud.
Fuera de Google Cloud: clústeres de Anthos que se ejecutan en:
- Clústeres de Anthos en VMware (GKE On-Prem)
- Anthos en Bare Metal
- Clústeres de Anthos en AWS
- Amazon EKS
Otras plataformas de Kubernetes: clústeres conformes creados y ejecutados en:
- AKS
- EKS
- OpenShift

GKE

La secuencia para actualizar a la versión 1.17.8 de Anthos Service Mesh en tu instalación híbrida es la siguiente:

Prepárate para la actualización.
Instala la nueva versión de Anthos Service Mesh.
Elimina las implementaciones, los servicios y los webhooks de la versión anterior de Anthos Service Mesh de tu instalación actual.
Actualiza tus pasarelas y configura los nuevos webhooks.

Prepararse para actualizar Anthos Service Mesh a la versión 1.17.8

Consulta los requisitos en Actualizar Anthos Service Mesh, pero no realices la actualización todavía.
Antes de instalar la nueva versión, determina la revisión actual. Necesitarás esta información para eliminar las implementaciones, los servicios y los webhooks de la versión anterior de Anthos Service Mesh de tu instalación actual. Usa el siguiente comando para almacenar la revisión actual de istiod en una variable de entorno:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
La salida debería tener un aspecto similar a este: 1.16

Nota: Si el comando devuelve varios valores, asigna el valor de DELETE_REV a la versión más antigua y sigue el procedimiento para eliminarla. A continuación, repite el proceso hasta que hayas eliminado todas las versiones.

Crea un archivo overlay.yaml o comprueba que el que ya tienes contiene lo siguiente:overlay.yaml

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Sigue las instrucciones de las siguientes secciones de la documentación de Anthos Service Mesh:
Importante: Asegúrate de seguir las instrucciones para actualizar Anthos Service Mesh con funciones opcionales e incluir tu overlay.yaml.
1. Descargar asmcli
2. Conceder permisos de administrador de clústeres
3. Validar proyecto y clúster
4. Actualiza tu plan con funciones opcionales. Detente antes de empezar la sección "Actualizar pasarelas".
Cambia al nuevo plano de control:
1. Obtén la etiqueta de revisión de istiod:
```
kubectl get pod -n istio-system -L istio.io/rev
```
  El resultado del comando es similar al siguiente.
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
```
2. Asigna la etiqueta de la revisión más reciente a una variable de entorno.
  En el resultado, en la columna REV, anota el valor de la etiqueta de revisión de la nueva versión. En este ejemplo, el valor es asm-1178-1
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Añade la etiqueta de revisión al espacio de nombres istio-system y quita la etiqueta istio-injection (si existe) con el siguiente comando.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Si ves "istio-injection not found" en el resultado, puedes ignorarlo. Esto significa que el espacio de nombres no tenía la etiqueta istio-injection. Como la inyección automática falla si un espacio de nombres tiene tanto la etiqueta istio-injection como la de revisión, todos los comandos kubectl label de la documentación de Anthos Service Mesh incluyen la eliminación de la etiqueta istio-injection.
4. Reinicia los pods para activar la reinyección.
```
kubectl rollout restart deployment -n istio-system
```
5. Prueba tu aplicación para verificar que las cargas de trabajo funcionan correctamente.
6. Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos para etiquetar el espacio de nombres y reiniciar los pods.

Elimina las versiones anteriores:

Ve al directorio en el que has instalado asmcli.
Almacena el directorio de salida de tu instalación de Anthos Service Mesh en la variable de entorno DIR_PATH. Es el mismo directorio que especificaste en el procedimiento Actualizar con funciones opcionales.
```
export DIR_PATH=OUTPUT_DIR
```

Crea un shell script que contenga los siguientes comandos:

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Ejecuta la secuencia de comandos para eliminar las versiones anteriores.

Fuera de Google Cloud

Estas instrucciones explican cómo actualizar Anthos Service Mesh en los siguientes entornos:

Clústeres de Anthos en VMware (GKE On-Prem)
Anthos en Bare Metal
Clústeres de Anthos en AWS
Amazon EKS

La secuencia para actualizar a la versión 1.17.8 de Anthos Service Mesh en tu instalación híbrida es la siguiente:

Prepárate para la actualización.
Instala la nueva versión de Anthos Service Mesh.
Elimina las implementaciones, los servicios y los webhooks de la versión anterior de Anthos Service Mesh de tu instalación actual.
Actualiza tus pasarelas y configura los nuevos webhooks.

Prepararse para actualizar Anthos Service Mesh a la versión 1.17.8

Consulta los requisitos en Actualizar Anthos Service Mesh, pero no realices la actualización todavía.
Antes de instalar la nueva versión, determina la revisión actual. Necesitarás esta información para eliminar las implementaciones, los servicios y los webhooks de la versión anterior de Anthos Service Mesh de tu instalación actual. Usa el siguiente comando para almacenar la revisión actual de istiod en una variable de entorno:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
La salida debería tener un aspecto similar a este: 1.16

Nota: Si el comando devuelve varios valores, asigna el valor de DELETE_REV a la versión más antigua y sigue el procedimiento para eliminarla. A continuación, repite el proceso hasta que hayas eliminado todas las versiones.

Crea un archivo overlay.yaml o comprueba que el que ya tienes contiene lo siguiente:overlay.yaml

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:  
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  values:
    gateways:
      istio-ingressgateway:
        runAsRoot: true

  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Sigue las instrucciones de las siguientes secciones de la documentación de Anthos Service Mesh:
Importante: Asegúrate de seguir las instrucciones para actualizar Anthos Service Mesh con funciones opcionales e incluir tu overlay.yaml.
1. Descargar asmcli
2. Conceder permisos de administrador de clústeres
3. Validar proyecto y clúster
4. Actualiza tu plan con funciones opcionales. Detente antes de empezar la sección "Actualizar pasarelas".
Cambia al nuevo plano de control:
1. Obtén la etiqueta de revisión de istiod:
```
kubectl get pod -n istio-system -L istio.io/rev
```
  El resultado del comando es similar al siguiente.
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
```
2. Asigna la etiqueta de la revisión más reciente a una variable de entorno.
  En el resultado, en la columna REV, anota el valor de la etiqueta de revisión de la nueva versión. En este ejemplo, el valor es asm-1178-1
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Añade la etiqueta de revisión al espacio de nombres istio-system y quita la etiqueta istio-injection (si existe) con el siguiente comando.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Si ves "istio-injection not found" en el resultado, puedes ignorarlo. Esto significa que el espacio de nombres no tenía la etiqueta istio-injection. Como la inyección automática falla si un espacio de nombres tiene tanto la etiqueta istio-injection como la de revisión, todos los comandos kubectl label de la documentación de Anthos Service Mesh incluyen la eliminación de la etiqueta istio-injection.
4. Reinicia los pods para activar la reinyección.
```
kubectl rollout restart deployment -n istio-system
```
5. Prueba tu aplicación para verificar que las cargas de trabajo funcionan correctamente.
6. Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos para etiquetar el espacio de nombres y reiniciar los pods.

Elimina las versiones anteriores:

Ve al directorio en el que has instalado asmcli.
Almacena el directorio de salida de tu instalación de Anthos Service Mesh en la variable de entorno DIR_PATH. Es el mismo directorio que especificaste en el procedimiento Actualizar con funciones opcionales.
```
export DIR_PATH=OUTPUT_DIR
```

Crea un shell script que contenga los siguientes comandos:

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Ejecuta la secuencia de comandos para eliminar las versiones anteriores.

AKS/EKS

En estas instrucciones, el proceso de actualización de la versión 1.17.8-asm.4-distroless de Anthos Service Mesh en clústeres adjuntos de Anthos es el mismo que el de una instalación nueva.

Prepararse para instalar Anthos Service Mesh

Antes de instalar la nueva versión, determina la revisión actual. Necesitará esta información para eliminar el webhook de validación y el webhook de mutación de su instalación actual de Anthos Service Mesh. Usa el siguiente comando para almacenar la revisión actual de istiod en una variable de entorno:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
La salida debería tener un aspecto similar a este: 1.16

Nota: Si el comando devuelve varios valores, asigna a DELETE_REV el valor de la versión más antigua y sigue el procedimiento para eliminarla. A continuación, repite el proceso hasta que hayas eliminado todas las versiones.

Linux

Descarga el archivo de instalación de Anthos Service Mesh en tu directorio de trabajo actual:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz

Descarga el archivo de firma y usa OpenSSL para verificar la firma:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature 1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Extrae el contenido del archivo a cualquier ubicación de tu sistema de archivos. Por ejemplo, para extraer el contenido al directorio de trabajo actual, haz lo siguiente:

tar xzf 1.17.8-asm.4-distroless-linux-amd64.tar.gz

El comando crea un directorio de instalación en tu directorio de trabajo actual llamado 1.17.8-asm.4-distroless que contiene lo siguiente:

Aplicaciones de ejemplo en el directorio samples.
La herramienta de línea de comandos istioctl que usas para instalar Anthos Service Mesh se encuentra en el directorio bin.
Los perfiles de configuración de Anthos Service Mesh se encuentran en el directorio manifests/profiles.

Asegúrate de que te encuentras en el directorio raíz de la instalación de Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

Para mayor comodidad, añade las herramientas del directorio /bin a tu PATH:

export PATH=$PWD/bin:$PATH

macOS

Descarga el archivo de instalación de Anthos Service Mesh en tu directorio de trabajo actual:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz

Descarga el archivo de firma y usa OpenSSL para verificar la firma:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature 1.17.8-asm.4-distroless-osx.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Extrae el contenido del archivo a cualquier ubicación de tu sistema de archivos. Por ejemplo, para extraer el contenido al directorio de trabajo actual, haz lo siguiente:

tar xzf 1.17.8-asm.4-distroless-osx.tar.gz

El comando crea un directorio de instalación en tu directorio de trabajo actual llamado 1.17.8-asm.4-distroless que contiene lo siguiente:

Aplicaciones de ejemplo en el directorio samples.
La herramienta de línea de comandos istioctl que usas para instalar Anthos Service Mesh se encuentra en el directorio bin.
Los perfiles de configuración de Anthos Service Mesh se encuentran en el directorio manifests/profiles.

Asegúrate de que te encuentras en el directorio raíz de la instalación de Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

Para mayor comodidad, añade las herramientas del directorio /bin a tu PATH:

export PATH=$PWD/bin:$PATH

Windows

Descarga el archivo de instalación de Anthos Service Mesh en tu directorio de trabajo actual:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip

Descarga el archivo de firma y usa OpenSSL para verificar la firma:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip.1.sig

openssl dgst -verify - -signature 1.17.8-asm.4-distroless-win.zip.1.sig 1.17.8-asm.4-distroless.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Extrae el contenido del archivo a cualquier ubicación de tu sistema de archivos. Por ejemplo, para extraer el contenido al directorio de trabajo actual, haz lo siguiente:

tar xzf 1.17.8-asm.4-distroless-win.zip

El comando crea un directorio de instalación en tu directorio de trabajo actual llamado 1.17.8-asm.4-distroless que contiene lo siguiente:

Aplicaciones de ejemplo en el directorio samples.
La herramienta de línea de comandos istioctl que usas para instalar Anthos Service Mesh se encuentra en el directorio bin.
Los perfiles de configuración de Anthos Service Mesh se encuentran en el directorio manifests\profiles.

Asegúrate de que te encuentras en el directorio raíz de la instalación de Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

Para mayor comodidad, añade las herramientas del directorio \bin a tu PATH:

set PATH=%CD%\bin:%PATH%

Ahora que se ha instalado Anthos Service Mesh Istio, comprueba la versión de istioctl:
```
istioctl version
```
Crea un espacio de nombres llamado istio-system para los componentes del plano de control:
```
kubectl create namespace istio-system
```

Instalar Anthos Service Mesh

Edita el archivo overlay.yaml o crea uno con el siguiente contenido:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        service:
          type: LoadBalancer
          ports:
          - name: status-port
            port: 15021
            targetPort: 15021
          - name: http2
            port: 80
            targetPort: 8080
          - name: https
            port: 443
            targetPort: 8443

Instala Anthos Service Mesh con istioctl mediante el perfil asm-multicloud:
```
istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1178-1" \
    --filename overlay.yaml
```
La salida debería tener un aspecto similar a este:
```
kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1178-1-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1178-1-798ffb964-fnj8c       1/1     Running   1          3m21s
```
El argumento --set revision añade una etiqueta de revisión con el formato istio.io/rev=asm-1178-1 a istiod. El webhook del inyector automático de sidecars usa la etiqueta de revisión para asociar los sidecars inyectados con una revisión istiod concreta. Para habilitar la inyección automática de sidecar en un espacio de nombres, debes etiquetarlo con una revisión que coincida con la etiqueta de istiod.

Comprueba que la instalación se ha completado:

kubectl get svc -n istio-system

La salida debería tener un aspecto similar a este:

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1178-1       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

Cambia al nuevo plano de control:
1. Obtén la etiqueta de revisión de istiod:
```
kubectl get pod -n istio-system -L istio.io/rev
```
  El resultado del comando es similar al siguiente.
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
```
2. Asigna la etiqueta de la revisión más reciente a una variable de entorno.
  En el resultado, en la columna REV, anota el valor de la etiqueta de revisión de la nueva versión. En este ejemplo, el valor es asm-1178-1
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Añade la etiqueta de revisión al espacio de nombres istio-system y quita la etiqueta istio-injection (si existe) con el siguiente comando.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Si ves "istio-injection not found" en el resultado, puedes ignorarlo. Esto significa que el espacio de nombres no tenía la etiqueta istio-injection. Como la inyección automática falla si un espacio de nombres tiene tanto la etiqueta istio-injection como la de revisión, todos los comandos kubectl label de la documentación de Anthos Service Mesh incluyen la eliminación de la etiqueta istio-injection.
4. Reinicia los pods para activar la reinyección.
```
kubectl rollout restart deployment -n istio-system
```
5. Prueba tu aplicación para verificar que las cargas de trabajo funcionan correctamente.
6. Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos para etiquetar el espacio de nombres y reiniciar los pods.

Elimina las versiones anteriores:

Ve al directorio en el que has instalado asmcli.

Crea un shell script que contenga los siguientes comandos:

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Ejecuta la secuencia de comandos para eliminar las versiones anteriores.

OpenShift

En estas instrucciones, el proceso de actualización de la versión 1.17.8-asm.4-distroless de Anthos Service Mesh en clústeres adjuntos de Anthos es el mismo que el de una instalación nueva.

Prepararse para instalar Anthos Service Mesh

Antes de instalar la nueva versión, determina la revisión actual. Necesitará esta información para eliminar el webhook de validación y el webhook de mutación de su instalación actual de Anthos Service Mesh. Usa el siguiente comando para almacenar la revisión actual de istiod en una variable de entorno:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
La salida debería tener un aspecto similar a este: 1.16

Nota: Si el comando devuelve varios valores, asigna a DELETE_REV el valor de la versión más antigua y sigue el procedimiento para eliminarla. A continuación, repite el proceso hasta que hayas eliminado todas las versiones.

Linux

Asigna la restricción de contexto de seguridad (SCC) anyuid a istio-system con el siguiente comando de la CLI de OpenShift (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Descarga el archivo de instalación de Anthos Service Mesh en tu directorio de trabajo actual:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz

Descarga el archivo de firma y usa OpenSSL para verificar la firma:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature 1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Extrae el contenido del archivo a cualquier ubicación de tu sistema de archivos. Por ejemplo, para extraer el contenido al directorio de trabajo actual, haz lo siguiente:

tar xzf 1.17.8-asm.4-distroless-linux-amd64.tar.gz

El comando crea un directorio de instalación en tu directorio de trabajo actual llamado 1.17.8-asm.4-distroless que contiene lo siguiente:

Aplicaciones de ejemplo en el directorio samples.
La herramienta de línea de comandos istioctl que usas para instalar Anthos Service Mesh se encuentra en el directorio bin.
Los perfiles de configuración de Anthos Service Mesh se encuentran en el directorio manifests/profiles.

Asegúrate de que te encuentras en el directorio raíz de la instalación de Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

Para mayor comodidad, añade las herramientas del directorio /bin a tu PATH:

export PATH=$PWD/bin:$PATH

macOS

Asigna la restricción de contexto de seguridad (SCC) anyuid a istio-system con el siguiente comando de la CLI de OpenShift (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Descarga el archivo de instalación de Anthos Service Mesh en tu directorio de trabajo actual:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz

Descarga el archivo de firma y usa OpenSSL para verificar la firma:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature 1.17.8-asm.4-distroless-osx.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Extrae el contenido del archivo a cualquier ubicación de tu sistema de archivos. Por ejemplo, para extraer el contenido al directorio de trabajo actual, haz lo siguiente:

tar xzf 1.17.8-asm.4-distroless-osx.tar.gz

El comando crea un directorio de instalación en tu directorio de trabajo actual llamado 1.17.8-asm.4-distroless que contiene lo siguiente:

Aplicaciones de ejemplo en el directorio samples.
La herramienta de línea de comandos istioctl que usas para instalar Anthos Service Mesh se encuentra en el directorio bin.
Los perfiles de configuración de Anthos Service Mesh se encuentran en el directorio manifests/profiles.

Asegúrate de que te encuentras en el directorio raíz de la instalación de Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

Para mayor comodidad, añade las herramientas del directorio /bin a tu PATH:

export PATH=$PWD/bin:$PATH

Windows

Asigna la restricción de contexto de seguridad (SCC) anyuid a istio-system con el siguiente comando de la CLI de OpenShift (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Descarga el archivo de instalación de Anthos Service Mesh en tu directorio de trabajo actual:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip

Descarga el archivo de firma y usa OpenSSL para verificar la firma:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip.1.sig

openssl dgst -verify - -signature 1.17.8-asm.4-distroless-win.zip.1.sig 1.17.8-asm.4-distroless.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Extrae el contenido del archivo a cualquier ubicación de tu sistema de archivos. Por ejemplo, para extraer el contenido al directorio de trabajo actual, haz lo siguiente:

tar xzf 1.17.8-asm.4-distroless-win.zip

El comando crea un directorio de instalación en tu directorio de trabajo actual llamado 1.17.8-asm.4-distroless que contiene lo siguiente:

Aplicaciones de ejemplo en el directorio samples.
La herramienta de línea de comandos istioctl que usas para instalar Anthos Service Mesh se encuentra en el directorio bin.
Los perfiles de configuración de Anthos Service Mesh se encuentran en el directorio manifests\profiles.

Asegúrate de que te encuentras en el directorio raíz de la instalación de Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

Para mayor comodidad, añade las herramientas del directorio \bin a tu PATH:

set PATH=%CD%\bin:%PATH%

Ahora que se ha instalado Anthos Service Mesh Istio, comprueba la versión de istioctl:
```
istioctl version
```
Crea un espacio de nombres llamado istio-system para los componentes del plano de control:
```
kubectl create namespace istio-system
```

Configurar el webhook de validación

Cuando instalas Anthos Service Mesh, asignas una etiqueta de revisión a istiod. Debes definir la misma revisión en el webhook de validación.

Crea un archivo llamado istiod-service.yaml con el siguiente contenido:

apiVersion: v1
kind: Service
metadata:
  name: istiod
  namespace: istio-system
  labels:
    istio.io/rev: asm-1178-1
    app: istiod
    istio: pilot
    release: istio
spec:
  ports:
    - port: 15010
      name: grpc-xds # plaintext
      protocol: TCP
    - port: 15012
      name: https-dns # mTLS with k8s-signed cert
      protocol: TCP
    - port: 443
      name: https-webhook # validation and injection
      targetPort: 15017
      protocol: TCP
    - port: 15014
      name: http-monitoring # prometheus stats
      protocol: TCP
  selector:
    app: istiod
    istio.io/rev: asm-1178-1
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Usa kubectl para aplicar la configuración del webhook de validación:
```
kubectl apply -f istiod-service.yaml
```

Verifica que se ha aplicado la configuración:

kubectl get svc -n istio-system

La respuesta debería ser similar a esta:

NAME     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
istiod   ClusterIP   172.200.18.133   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP   22s

Instalar Anthos Service Mesh

Edita el archivo overlay.yaml o crea uno con el siguiente contenido:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          service:
            type: LoadBalancer
            ports:
            - name: status-port
              port: 15021
              targetPort: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443

Instala Anthos Service Mesh con istioctl mediante el perfil asm-multicloud:
```
istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1178-1" \
    --filename overlayfile.yaml
```
La salida debería tener un aspecto similar a este:
```
kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1178-1-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1178-1-798ffb964-fnj8c       1/1     Running   1          3m21s
```
El argumento --set revision añade una etiqueta de revisión con el formato istio.io/rev=1.6.11-asm.1 a istiod. El webhook del inyector automático de sidecars usa la etiqueta de revisión para asociar los sidecars inyectados con una revisión istiod concreta. Para habilitar la inyección automática de sidecar en un espacio de nombres, debes etiquetarlo con una revisión que coincida con la etiqueta de istiod.

Comprueba que la instalación se ha completado:

kubectl get svc -n istio-system

La salida debería tener un aspecto similar a este:

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1178-1       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

Cambia al nuevo plano de control:
1. Obtén la etiqueta de revisión de istiod:
```
kubectl get pod -n istio-system -L istio.io/rev
```
  El resultado del comando es similar al siguiente.
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
```
2. Asigna la etiqueta de la revisión más reciente a una variable de entorno.
  En el resultado, en la columna REV, anota el valor de la etiqueta de revisión de la nueva versión. En este ejemplo, el valor es asm-1178-1
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Añade la etiqueta de revisión al espacio de nombres istio-system y quita la etiqueta istio-injection (si existe) con el siguiente comando.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Si ves "istio-injection not found" en el resultado, puedes ignorarlo. Esto significa que el espacio de nombres no tenía la etiqueta istio-injection. Como la inyección automática falla si un espacio de nombres tiene tanto la etiqueta istio-injection como la de revisión, todos los comandos kubectl label de la documentación de Anthos Service Mesh incluyen la eliminación de la etiqueta istio-injection.
4. Reinicia los pods para activar la reinyección.
```
kubectl rollout restart deployment -n istio-system
```
5. Prueba tu aplicación para verificar que las cargas de trabajo funcionan correctamente.
6. Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos para etiquetar el espacio de nombres y reiniciar los pods.

Elimina las versiones anteriores:

Ve al directorio en el que has instalado asmcli.

Crea un shell script que contenga los siguientes comandos:

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Ejecuta la secuencia de comandos para eliminar las versiones anteriores.

Restaurar una versión anterior de una actualización

Sigue estos pasos para revertir una actualización anterior:

Limpia las tareas completadas del espacio de nombres del tiempo de ejecución híbrido, donde NAMESPACE es el espacio de nombres especificado en el archivo de anulaciones (si has especificado alguno). Si no es así, el espacio de nombres predeterminado es apigee:
```
kubectl delete job -n NAMESPACE \
  $(kubectl get job -n NAMESPACE \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

Limpia las tareas completadas del espacio de nombres apigee-system:

kubectl delete job -n apigee-system \
  $(kubectl get job -n apigee-system \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

Cambia la variable APIGEECTL_HOME para que apunte al directorio que contiene la versión anterior de apigeectl. Por ejemplo:
```
export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
```
Para deshacer los cambios en el archivo overrides, sigue estos pasos:
1. Elimina o comenta ingressGateways y todas sus propiedades.
2. Asigna a virtualhosts.selector.app el valor anterior. Por ejemplo:
```
virtualhosts:
  - name: my-env-group
    selector:
      app: istio-ingressgateway
```
3. Elimina o comenta ao.args.disableIstioConfigInAPIServer.
En el directorio raíz de la instalación a la que quieras volver, ejecuta apigeectl apply, comprueba el estado de tus pods y, a continuación, ejecuta apigeectl init. Asegúrate de usar el archivo de anulaciones original de la versión a la que quieras volver:
1. En el directorio hybrid-files, ejecuta apigeectl apply:
```
$APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE
```
  Donde ORIGINAL_OVERRIDES_FILE es la ruta relativa y el nombre de archivo de las anulaciones de la versión híbrida anterior, por ejemplo, ./overrides/overrides1.7.yaml.
2. Verifica el estado de tus pods:
```
kubectl -n NAMESPACE get pods
```
  Donde NAMESPACE es el espacio de nombres de Apigee hybrid.
3. Comprueba el estado de apigeeds:
```
kubectl describe apigeeds -n apigee
```
  La salida debería tener un aspecto similar a este:
```
Status:
  Cassandra Data Replication:
  Cassandra Pod Ips:
    10.8.2.204
  Cassandra Ready Replicas:  1
  Components:
    Cassandra:
      Last Successfully Released Version:
        Revision:  v1-f8aa9a82b9f69613
        Version:   v1
      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  Scaling:
    In Progress:         false
    Operation:
    Requested Replicas:  0
  State:                 running
```
  Continúa con el siguiente paso solo cuando el pod apigeeds esté en ejecución.
4. Ejecuta el siguiente comando para anotar los nuevos valores del recuento de réplicas del procesador de mensajes después de la actualización.Si estos valores no coinciden con los que has definido anteriormente, cambia los valores del archivo de anulaciones para que coincidan con la configuración anterior.
```
apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2
```
  La salida debería tener un aspecto similar a este:
```
      autoScaler:
        minReplicas: 2
        maxReplicas: 10
```
5. Si vas a revertir a la versión híbrida 1.8.4 o anterior, elimina la implementación del controlador que usa la versión híbrida 1.8.5 y posteriores:
```
kubectl -n apigee-system delete deploy apigee-controller-manager
```
6. Ejecuta apigeectl init:
```
$APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
```
Elimina el despliegue del gestor de pasarela de entrada de Apigee. Este componente solo es relevante para las versiones 1.8 y posteriores de Apigee hybrid.
```
kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager
```
Donde NAMESPACE es el espacio de nombres de Apigee hybrid.

Actualizar Apigee Hybrid a la versión 1.8 Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Presentamos la pasarela de entrada de Apigee

Información general sobre la actualización a la versión 1.8.8

Requisitos previos

Prepararse para actualizar a la versión 1.8

Crear una copia de seguridad de tu instalación híbrida (recomendado)

Linux

macOS

Windows

Añade el rol Agente de Cloud Trace a la cuenta de servicio del entorno de ejecución de Apigee. (Opcional)

Producción

Non-Prod

Producción

Non-Prod

Ejemplo

Prepararse para instalar la pasarela de entrada de Apigee

Sintaxis

Ejemplo

Haz cambios adicionales en el archivo de anulaciones para habilitar o inhabilitar funciones opcionales de la versión 1.8

Instalar el entorno de ejecución híbrido 1.8.8

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

Producción

No producción

Actualizar la versión de Kubernetes

Haz clic para desplegar una lista de plataformas compatibles

Plataformas

Componentes

Acerca de los clústeres vinculados

Cambiar el tráfico de Anthos Service Mesh a la pasarela de entrada de Apigee

Actualizar Anthos Service Mesh a la versión 1.15

GKE

Prepararse para actualizar Anthos Service Mesh a la versión 1.17.8

Fuera de Google Cloud

Prepararse para actualizar Anthos Service Mesh a la versión 1.17.8

AKS/EKS

Prepararse para instalar Anthos Service Mesh

Linux

macOS

Windows

Instalar Anthos Service Mesh

OpenShift

Prepararse para instalar Anthos Service Mesh

Linux

macOS

Windows

Configurar el webhook de validación

Instalar Anthos Service Mesh

Restaurar una versión anterior de una actualización

Actualizar Apigee Hybrid a la versión 1.8