Planificar una actualización
En esta página se proporciona información para ayudarte a planificar una actualización de Cloud Service Mesh. También te recomendamos que consultes las notas de actualización de Istio.
Acerca de las actualizaciones canary
Te recomendamos que actualices Cloud Service Mesh ejecutando primero una implementación canary del nuevo plano de control. Con una actualización canary, asmcli
instala una nueva revisión del plano de control junto con el antiguo. Tanto el plano de control antiguo como el nuevo tienen la etiqueta revision
, que sirve como identificador de los planos de control.
Para migrar cargas de trabajo al nuevo plano de control, sigue estos pasos:
Define la etiqueta
revision
del nuevo plano de control en uno de tus espacios de nombres.Realiza un reinicio gradual. Al reiniciar, se vuelven a insertar los proxies sidecar en los pods para que utilicen el nuevo plano de control.
Monitoriza el efecto de la actualización en las cargas de trabajo. Si necesitas probar tu aplicación, repite los pasos anteriores.
Después de probar la aplicación, puedes migrar todo el tráfico al nuevo plano de control o volver al antiguo.
Una actualización canary es mucho más segura que una actualización in situ, en la que el nuevo plano de control sustituye al antiguo. Para ver los pasos detallados, consulta Cambiar al nuevo plano de control.
Personalizar el plano de control
Si has personalizado la instalación anterior, debes aplicar las mismas personalizaciones al actualizar Cloud Service Mesh. Si has personalizado la instalación añadiendo la marca --set values
a istioctl install
, debes añadir esos ajustes a un archivo IstioOperator
YAML, denominado archivo de superposición. Para especificar el archivo de superposición, usa la opción --custom_overlay
con el nombre de archivo cuando ejecutes asmcli
.
El paquete anthos-service-mesh
de GitHub contiene muchos archivos de superposición. Estos archivos contienen personalizaciones comunes de la configuración predeterminada. Puedes usar estos archivos tal cual o hacerles los cambios que necesites. Algunos de los archivos son necesarios para habilitar funciones opcionales de Cloud Service Mesh.
El paquete anthos-service-mesh
se descarga cuando ejecutas asmcli
para validar tu proyecto y tu clúster.
Cuando instalas Cloud Service Mesh con asmcli install
, puedes especificar uno o varios archivos de superposición con --option
o --custom_overlay
.
Si no necesitas hacer ningún cambio en los archivos del anthos-service-mesh
repositorio, puedes usar --option
y la secuencia de comandos obtendrá el archivo de GitHub por ti. De lo contrario, puedes hacer cambios en el archivo de superposición y, a continuación, usar la opción --custom_overlay
para pasarlo a asmcli
.
Elegir una autoridad de certificación
Si tu instalación actual de Cloud Service Mesh usa la autoridad de certificación de Cloud Service Mesh para emitir certificados de TLS mutuo (mTLS), te recomendamos que sigas usando la autoridad de certificación de Cloud Service Mesh por los siguientes motivos:
- La autoridad de certificación de Cloud Service Mesh es un servicio altamente fiable y escalable que está optimizado para cargas de trabajo escaladas dinámicamente.
- Con la autoridad de certificación de Cloud Service Mesh, Google gestiona la seguridad y la disponibilidad del backend de la CA.
- La autoridad de certificación de Cloud Service Mesh te permite confiar en una única raíz de confianza en todos los clústeres.
Si tu instalación actual de Cloud Service Mesh usa Istio CA (antes llamado "Citadel"), puedes cambiar a la autoridad de certificación de Cloud Service Mesh cuando actualices, pero debes programar un tiempo de inactividad. Durante la actualización, el tráfico de mTLS se interrumpe hasta que todas las cargas de trabajo cambien al nuevo plano de control con la autoridad de certificación de Cloud Service Mesh.
Los certificados de la autoridad de certificación de Cloud Service Mesh incluyen los siguientes datos sobre los servicios de tu aplicación:
- El Google Cloud ID del proyecto
- Espacio de nombres de GKE
- Nombre de la cuenta de servicio de GKE
Identificar tu CA
Cuando ejecutas asmcli install
para actualizar, especificas la CA que asmcli
debe habilitarse en el nuevo plano de control.
Si cambias las CAs, se producirá un tiempo de inactividad cuando implementes cargas de trabajo en el nuevo plano de control. Si no puedes programar un tiempo de inactividad, asegúrate de especificar la misma CA para el nuevo plano de control que usa el antiguo. Si no sabes qué AC está habilitada en tu malla, ejecuta los siguientes comandos:
Obtén una lista de pods de uno de tus espacios de nombres:
kubectl get pods -n NAMESPACE
Sustituye
POD_NAME
por el nombre de uno de tus pods en el siguiente comando:kubectl get pod POD_NAME -n NAMESPACE -o yaml | grep CA_ADDR -A 1
Si la autoridad de certificación de Cloud Service Mesh está habilitada en el espacio de nombres, verás el siguiente resultado:
- name: CA_ADDR value: meshca.googleapis.com:443
Preparar la configuración de la pasarela
Cloud Service Mesh te ofrece la opción de desplegar y gestionar gateways como parte de tu malla de servicios. Una pasarela describe un balanceador de carga que opera en el perímetro de la malla y recibe conexiones HTTP o TCP entrantes o salientes. Las pasarelas son proxies de Envoy que te ofrecen un control pormenorizado del tráfico que entra y sale de la malla.
asmcli
no instala istio-ingressgateway
. Te recomendamos que
despliegues y gestiones el plano de control y las pasarelas por separado. Para obtener más información, consulta el artículo sobre cómo instalar y actualizar gateways.
Actualizar la plataforma (opcional)
Como práctica recomendada, debes actualizar Cloud Service Mesh a la versión compatible más reciente que también sea compatible con tu plataforma actual. A continuación, actualiza tu entorno para que esté dentro del intervalo de plataformas y versiones de Kubernetes compatibles. Por último, si es necesario, actualiza a la versión admitida más reciente de Cloud Service Mesh.