Planificar una actualización

En esta página, se proporciona información para ayudarte a planificar una actualización de Anthos Service Mesh. Te recomendamos que también revises las notas de actualización de Istio.

Acerca de las actualizaciones canary

Recomendamos que primero ejecutes una implementación de versiones canary del nuevo plano de control para actualizar Anthos Service Mesh. Con una actualización canary, asmcli instala una revisión nueva del plano de control junto con el plano de control anterior. Los planos de control antiguos y nuevos se etiquetan con una etiqueta revision, que funciona como identificador para los planos de control.

Migra las cargas de trabajo al nuevo plano de control

1. Establece la etiqueta revision del nuevo plano de control en uno de tus espacios de nombres.

2. Realiza un reinicio progresivo. El reinicio vuelve a insertar los proxies de sidecar en los Pods para que los proxies usen el plano de control nuevo.

3. Supervisa el efecto de la actualización en las cargas de trabajo. Si es necesario para probar tu aplicación, repite los pasos anteriores.

4. Después de probar la aplicación, puedes migrar todo el tráfico al nuevo plano de control o revertir al plano de control anterior.

Una actualización canary es mucho más segura que realizar una actualización in situ en la que el plano de control nuevo reemplaza al plano de control anterior. Para ver pasos más detallados, consulta Cambia al plano de control nuevo.

Personaliza el plano de control

Si personalizaste la instalación anterior, necesitas usar las mismas personalizaciones cuando actualices Anthos Service Mesh. Si personalizaste la instalación agregando la marca --set values a istioctl install, debes agregar esa configuración a un archivo YAML IstioOperator, denominado archivo de superposición. Especifica el archivo de superposición mediante la opción --custom_overlay con el nombre del archivo cuando ejecutes asmcli.

Precaución: Omitir el archivo de configuración da como resultado una instalación correcta. Sin embargo, la malla de servicios tiene una configuración diferente de la deseada, ya que los valores omitidos se restablecen a los valores predeterminados cuando se vuelve a implementar el plano de control.

El paquete anthos-service-mesh en GitHub contiene muchos archivos de superposición. Estos archivos contienen personalizaciones comunes de la configuración predeterminada. Puedes usar estos archivos tal como están o puedes realizar cambios adicionales según sea necesario. Algunos de los archivos son necesarios para habilitar las funciones opcionales de Anthos Service Mesh. El paquete anthos-service-mesh se descarga cuando ejecutas asmcli para validar tu proyecto y clúster.

Cuando instalas Anthos Service Mesh mediante asmcli install, puedes especificar uno o más archivos de superposición con --option o --custom_overlay. Si no necesitas realizar cambios en los archivos del repositorio anthos-service-mesh, puedes usar --option y la secuencia de comandos recupera el archivo de GitHub. De lo contrario, puedes realizar cambios en el archivo de superposición y, luego, usar la opción --custom_overlay para pasarlo a la secuencia de comandos asmcli.

Elige una autoridad certificadora

Nota de la plataforma: La CA de Mesh no es compatible con GKE en AWS, Amazon EKS ni Microsoft AKS. Si ejecutas asmcli install y especificas --ca mesh_ca en estas plataformas, la instalación fallará.

Si tu instalación actual de Anthos Service Mesh usa la autoridad certificada de Anthos Service Mesh (CA de Mesh) como autoridad certificada (CA) para emitir certificados mutuos de TLS (mTLS), se recomienda que continúes usando la CA de Mesh por los siguientes motivos:

• La CA de Mesh es un servicio altamente confiable y escalable que está optimizado para cargas de trabajo escaladas de forma dinámica en Google Cloud.
• Con la CA de Mesh, Google administra la seguridad y la disponibilidad del backend de CA.
• La CA de Mesh te permite tener una sola raíz de confianza entre clústeres.

Si tu instalación actual de Anthos Service Mesh usa la CA de Istio (antes llamada “Citadel”), puedes cambiar a la CA de Mesh cuando actualices, pero debes programar el tiempo de inactividad. Durante la actualización, el tráfico de mTLS se interrumpe hasta que todas las cargas de trabajo cambien al plano de control nuevo con la CA de Mesh.

Nota de la plataforma: CA Service solo es compatible con las siguientes plataformas: clústeres de GKE en Google Cloud, GKE en VMware y GDCV para Bare Metal. Si ejecutas asmcli install y especificas --ca gcp_cas en otras plataformas, la instalación parecerá exitosa, pero las cargas de trabajo no se iniciarán.

En los certificados de CA de Mesh, se incluyen los siguientes datos sobre los servicios de tu aplicación:

• El ID del proyecto de Google Cloud
• El espacio de nombres de GKE
• El nombre de la cuenta de servicio de GKE

Importante: Los certificados emitidos por la CA de Mesh solo deben usarse a fin de habilitar la comunicación segura de servicio a servicio dentro de la malla de servicios, y no para otros propósitos. Estos certificados se envían cada vez que los servicios intentan comunicarse entre sí mediante TLS mutuo. Asegúrate de no exponer de forma involuntaria información confidencial mediante estos certificados cuando te comunicas fuera de la malla de servicios.

Identifica tu CA

Cuando ejecutas asmcli install para la actualización, especificas la CA que asmcli debe habilitar en el plano de control nuevo.

Cambiar las CA causa tiempo de inactividad cuando las cargas de trabajo de implementación se realizan en el plano de control nuevo. Si no puedes programar el tiempo de inactividad, asegúrate de especificar esa misma CA para el nuevo plano de control que usa el plano de control anterior. Si no estás seguro de qué CA está habilitada en tu malla, ejecuta los siguientes comandos:

1. Obtén una lista de pods de uno de tus espacios de nombres:

   kubectl get pods -n NAMESPACE
   

2. Reemplaza POD_NAME por el nombre de uno de los Pods en el siguiente comando:

   kubectl get pod POD_NAME -n NAMESPACE -o yaml | grep CA_ADDR -A 1
   

   Si la CA de Mesh está habilitada en el espacio de nombres, verás el siguiente resultado:

   - name: CA_ADDR
     value: meshca.googleapis.com:443
   

Prepara la configuración de la puerta de enlace

Anthos Service Mesh te brinda la opción de implementar y administrar puertas de enlace como parte de tu malla de servicios. Una puerta de enlace describe un balanceador de cargas que opera en el perímetro de la malla que recibe conexiones HTTP/TCP entrantes o salientes. Las puertas de enlace son proxies de Envoy que te brindan un control detallado sobre el tráfico que entra y sale de la malla.

De forma predeterminada, asmcli no se instala istio-ingressgateway. Te recomendamos que implementes y administres el plano de control y las puertas de enlace por separado. Para obtener más información, consulta Instala y actualiza puertas de enlace. Si necesitas que el istio-ingressgateway predeterminado esté instalado con el plano de control en el clúster, incluye el argumento --option legacy-default-ingressgateway.

Actualiza tu plataforma (opcional)

Como práctica recomendada, debes actualizar Anthos Service Mesh a la versión compatible más reciente que también sea compatible con tu plataforma actual. Luego, actualiza el entorno para que esté dentro del rango de plataformas y versiones de Kubernetes compatibles. Por último, si es necesario, actualiza a la versión compatible más reciente de Anthos Service Mesh.

Próximos pasos

• Instala herramientas dependientes y valida clústeres