Planificar una actualización

Nota: Esta guía solo admite Cloud Service Mesh con las APIs de Istio y no las de Google Cloud. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

En esta página, se proporciona información para ayudarte a planificar una actualización de Cloud 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 Cloud 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, necesitarás las mismas personalizaciones cuando actualices Cloud 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 Directorio asmcli 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 Habilita funciones opcionales de Cloud Service Mesh. El paquete anthos-service-mesh se descarga cuando ejecutas asmcli para validar tu proyecto y clúster.

Cuando instalas Cloud Service Mesh con 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

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

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

Si tu instalación actual de Cloud Service Mesh usa la CA de Istio (antes llamada “Citadel”), puedes cambiar a la autoridad certificadora de Cloud Service 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 autoridad certificadora de Cloud Service Mesh.

Nota de la plataforma: El Servicio de CA solo es compatible con las siguientes plataformas: clústeres de GKE en Google Cloud, Google Distributed Cloud (solo software) para VMware y Distributed Cloud. 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 la autoridad certificadora de Cloud Service 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 autoridad certificadora de Cloud Service Mesh solo deben usarse para 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 autoridad certificadora de Cloud Service 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

Cloud Service Mesh te da 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.

asmcli no instala istio-ingressgateway. Te recomendamos que implementes y administres el plano de control y las puertas de enlace por separado. Para ver más consulta Instala y actualiza puertas de enlace.

Actualiza tu plataforma (opcional)

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

Próximos pasos

• Instala herramientas dependientes y valida clústeres