- v1.15 (última)
- v1.14
- v1.13
- Lista de versiones admitidas
- v1.12
- v1.11
- v1.10
- v1.9
- v1.8
- v1.7
- Versión 1.6
- v1.5
- Versión 1.4
- Versión 1.3
- v1.2
- v1.1
Versiones compatibles:
Versiones no compatibles:
Apigee hybrid admite dos tipos de actualizaciones. La primera es una actualización in situ, en la que aplicas un cambio de configuración y el modo híbrido inicia una actualización gradual de Kubernetes. En Kubernetes, las actualizaciones continuas permiten que las actualizaciones de los despliegues se realicen sin tiempo de inactividad, ya que se actualizan de forma incremental las instancias de los pods con las nuevas.
Apigee hybrid también admite actualizaciones de tipo canario o A/B. En una actualización A/B, se implementa la nueva revisión, pero al principio solo se dirige a ella un pequeño porcentaje del tráfico. Con el tiempo, este porcentaje aumenta hasta que todo el tráfico se dirige a la revisión.
Actualizaciones in situ
Para activar una actualización in situ, solo tienes que modificar los ajustes que quieras en el archivo de anulaciones y aplicarlo al clúster. Por ejemplo, supongamos que quieres cambiar la memoria runtime
actual de 1Gi a 5Gi:
Esta es la configuración inicial:
... runtime: replicaCountMin: 2 replicaCountMax: 20 resources: requests: cpu: 1000m memory: 1Gi ...
En la nueva configuración, la memoria se cambia a 5 Gi:
... runtime: replicaCountMin: 2 replicaCountMax: 20 resources: requests: cpu: 1000m memory: 5Gi ...
Cuando apliques el cambio, los pods actualizados se iniciarán y sustituirán a los pods actuales. Gracias a la función de actualización continua de Kubernetes, los clientes no experimentan ningún tiempo de inactividad.
Cómo realizar una actualización A/B
Para realizar una actualización AB, usa la etiqueta revision
en el archivo de anulaciones.
Por ejemplo, supongamos que quieres cambiar la memoria runtime
actual de 1 Gi a 5 Gi:
En la configuración actual, revision
está definido como blue
:
... revision: blue ... runtime: replicaCountMin: 2 replicaCountMax: 20 resources: requests: cpu: 1000m memory: 1Gi ...
En la nueva configuración, si cambia revision
a green
, indica que quiere realizar una actualización gradual cuando se aplique el cambio. El valor que asignes a revision
no importa. Puedes usar cualquier cadena, siempre que la cambies del valor anterior a otro.
... revision: green ... runtime: replicaCountMin: 2 replicaCountMax: 20 resources: requests: cpu: 1000m memory: 5Gi ...
Cuando aplique el cambio, se dirigirá un pequeño porcentaje del tráfico a la nueva revisión. Con el tiempo, la nueva revisión recibe más tráfico hasta alcanzar el 100%. En ese momento, se elimina la revisión antigua.
Para activar un lanzamiento de prueba A/B, añade la etiqueta revision
si no está presente o cambia el valor de la etiqueta revision
si ya está presente. No es necesario que hagas ningún otro cambio en el archivo de anulaciones para activar un lanzamiento de pruebas A/B.
En la siguiente tabla se muestra la programación de un lanzamiento de AB:
Fase | Porcentaje de tráfico | Tiempo de espera |
---|---|---|
1 | 5 % | 60 segundos |
2 | 20 % | 10 segundos |
3 | 100 % | 10 segundos |
En la versión actual, los porcentajes y los tiempos de espera no se pueden configurar.