Migración de CA in situ
Si tu malla tiene varios clústeres con cargas de trabajo que envían solicitudes a cargas de trabajo en otro clúster, sigue todos los pasos de esta guía para todos los clústeres.
Sigue los pasos que se indican en esta guía para el siguiente caso práctico:
- Migrar un plano de control de Anthos Service Mesh v1.13 o posterior en el clúster con la CA de Mesh a Certificate Authority Service
- Migrar un plano de control de Anthos Service Mesh en un canal de versiones que se asigne a la versión 1.13 o posterior con la CA de Mesh al servicio de autoridad certificadora.
Limitaciones
Las migraciones y actualizaciones de CA locales solo son compatibles con la versión 1.13 o posterior de Anthos Service Mesh. Para las migraciones del plano de control administrado, asegúrate de que el canal elegido se asigne a la versión 1.13 o posterior.
Prerequisites
Antes de seguir los pasos que se indican en esta guía, asegúrate de tener lo siguiente:
Además, asegúrate de que estás usando la versión 1.13 o posterior de Anthos Service Mesh.
Herramientas requeridas
Durante la migración, ejecutas una herramienta que proporciona Google, migrate_ca
. Esta herramienta tiene las siguientes dependencias:
awk
grep
jq
kubectl
head
sed
tr
yq
Antes de descargar la herramienta migrate_ca
, sigue los pasos que se indican en Prepárate para la migración.
Descripción general de la migración
Durante el proceso de migración, la autenticación y la autorización funcionan completamente entre las cargas de trabajo que usan la CA anterior y las que usan la CA nueva.
La herramienta de migración migrate_ca
creará un mapa de configuración de Kubernetes para realizar un seguimiento del estado de la migración de CA por canal o revisión de Anthos Service Mesh instalado.
Este es un recurso con privilegios instalado en el espacio de nombres istio-system
.
apiVersion: v1
kind: ConfigMap
metadata:
Name: asm-ca-migration-<revision>
Data:
revision:
start_time:
state_update_time:
current_state: TRUSTANCHOR_INJECT | MIGRATE_CA | ROLLBACK
old_ca:
target_ca:
La herramienta de migración creará una copia de seguridad del mapa de configuración de la malla de Istio antes de modificarla y, luego, intentará migrar la configuración de CA mediante la CRD ProxyConfig
cuando sea posible.
A continuación, se muestra un esquema de la migración de la CA:
Prepárate para la migración
Descarga la herramienta bash
migrate_ca
:curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/ca-migration/migrate_ca > migrate_ca
Haz que la herramienta sea ejecutable:
chmod +x migrate_ca
Configure el directorio de trabajo:
./migrate_ca setup --output_dir OUTPUT_DIR
Cambia el directorio de trabajo a la OUTPUT_DIR especificada en el paso anterior.
cd OUTPUT_DIR
Ejecuta el siguiente comando para asegurarte de que se cumplan todos los requisitos previos:
./migrate_ca check-prerequisites
Toma nota de la revisión (
ASM_REVISION
) del plano de control asociado con la CA anterior que se migrará. Los pasos necesarios dependen del tipo de plano de control, ya sea en el clúster o administrado.En el clúster
asm-revision=$(kubectl get deploy -n istio-system -l app=istiod -o \ "jsonpath={.items[*].metadata.labels[istio\.io/rev']}{'\n'}")
Administrado
Consulta el canal que ya está instalado.
Dado que la migración de CA local requiere que reinicies las cargas de trabajo, asegúrate de que el Presupuesto de interrupción del Pod esté configurado de forma correcta y que todas las aplicaciones cuya CA necesite migrarse tengan más de un Pod en ejecución.
Asegúrate de que el clúster ya esté registrado en una flota y que la identidad de la carga de trabajo esté habilitada en el clúster. Luego, toma nota del ID del proyecto de flota como (
FLEET_ID
) para los próximos pasos.La herramienta acepta
kubeConfig
ykubeContext
para seleccionar el clúster en el que se realizan las operaciones. Si no se pasan estos argumentos, se usa el contexto o la configuración predeterminados.Para agregar las credenciales de un clúster de GKE a
kubeConfig
, usa el siguiente comando:gcloud container clusters get-credentials CLUSTER_NAME
Si deseas cambiar el contexto
kubectl
actual o pasar el contexto a la herramienta, usa el siguiente comando:kubectl config get-contexts kubectl config use-context CLUSTER_NAME
Inicializa la CA nueva
Los pasos necesarios para inicializar la CA nueva dependen de la CA nueva a la que migras. Realiza estos pasos en todos los clústeres de flotas en los que quieras migrar la CA.
CA de Mesh
Llama al subcomando
initialize
de la herramienta de utilidad.Si especificas configuraciones personalizadas de Kubernetes:
./migrate_ca initialize --kubeconfig KUBECONFIG --kubecontext KUBECONTEXT --ca mesh_ca --old_ca OLD_CA_TYPE \ --fleet_id FLEET_ID --revision ASM_REVISION
En caso contrario:
./migrate_ca initialize --ca mesh_ca --old_ca OLD_CA_TYPE \ --fleet_id FLEET_ID --revision ASM_REVISION ```
Servicio de CA
a. Sigue los pasos necesarios para inicializar el servicio de autoridad certificadora. Toma nota de
CA_POOL
.b. Llama al subcomando
initialize
de la herramienta de utilidad:Si especificas configuraciones personalizadas de Kubernetes:
./migrate_ca initialize --kubeconfig KUBECONFIG --context KUBECONTEXT --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \ --fleet-id FLEET_ID --revision ASM_REVISION
En caso contrario:
./migrate_ca initialize --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \ --fleet-id FLEET_ID --revision ASM_REVISION
Agrega "TrustAnchors" a toda la malla para todos los clústeres de la flota.
Repite los pasos que se indican a continuación para la CA nueva y la CA anterior en todos los clústeres que forman parte de la flota.
Descarga los anclajes de confianza de la CA:
CA de Mesh
./migrate_ca download-trust-anchor --ca mesh_ca --ca_cert ROOT_CERT.pem
Servicio de CA
Almacene el certificado de CA en un archivo:
gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pem
Se agregó el valor "TrustAnchors" de la CA:
./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem
Verifica que todas las cargas de trabajo de la flota hayan recibido las TrustedAnchors. En el argumento de espacios de nombres, pasa todos los espacios de nombres en los que se implementan las cargas de trabajo:
./migrate-ca check-trust-anchor --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
Resultado esperado:
Check the CA cert in namespace nsa-1-24232 a-v1-597f875788-52c5t.nsa-1-24232 trusts root-cert.pem
Migra la CA
Migrar la configuración de CA El comando necesario depende de la CA nueva a la que migras.
CA de Mesh
./migrate_ca migrate-ca --ca mesh_ca
Servicio de CA
./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL
Reinicia todas las cargas de trabajo.
Para minimizar el riesgo de tiempo de inactividad del tráfico TLS, este paso debería afectar primero a la menor cantidad de cargas de trabajo. Solo reinicia las cargas de trabajo que están asociadas con la revisión ASM_REVISION del plano de control. Por ejemplo, si todas las cargas de trabajo en el espacio de nombres de Kubernetes NAMESPACE están asociadas al mismo plano de control de Anthos Service Mesh.
kubectl rollout restart deployment -n NAMESPACE
Verifica que las conexiones de mTLS funcionen entre cargas de trabajo en el espacio de nombres reiniciado y otras cargas de trabajo antes de repetir los pasos 1 y 2 para todos los espacios de nombres y para todos los clústeres que forman parte de la flota. Si aparecen cargas de trabajo nuevas y el tráfico de la malla no se interrumpe, repite los pasos 1 y 2 para todos los espacios de nombres y clústeres que forman parte de la flota. De lo contrario, realiza una reversión a fin de revertir la configuración de CA más reciente.
Verifica que todas las cargas de trabajo usen la nueva configuración de CA:
./migrate_ca verify-ca --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
Resultado esperado:
Check the CA configuration in namespace nsb-2-76095 b-v1-8ff557759-pds69.nsb-2-76095 is signed by root-cert.pem
Cómo realizar una reversión
Revertir la configuración de CA y quitar los anclajes de confianza recién configurados:
./migrate-ca rollback
Reinicia todas las cargas de trabajo. Asegúrate de reiniciar solo las cargas de trabajo asociadas con la revisión ASM_REVISION del plano de control. Por ejemplo, si todas las cargas de trabajo en el espacio de nombres de Kubernetes NAMESPACES están asociadas al mismo plano de control de Anthos Service Mesh.
kubectl rollout restart deployment -n NAMESPACES
Verifica que todas las cargas de trabajo usen la configuración de CA anterior (opcional).
./migrate-ca verify-ca --ca_cert older-root-cert.pem
Repite los pasos 1 a 3 para todos los clústeres de la flota en los que las cargas de trabajo usan el plano de control ASM_REVISION.
¡Felicitaciones! Realizaste correctamente una migración de CA local.