Implementa una carga de trabajo de Linux en un clúster de destino

Después de migrar una carga de trabajo desde la plataforma de origen, puedes usar los artefactos de implementación que ese proceso genera para implementar el contenedor de carga de trabajo migrado a otro clúster.

Antes de comenzar

Antes de implementar tu carga de trabajo, debes hacer lo siguiente:

Asegúrate de que el clúster de destino tenga acceso de lectura al registro de Docker

Como parte de la migración, Migrate for Anthos and GKE sube las imágenes de Docker que representan una VM migrada a un registro de Docker. Estas imágenes de Docker representan los archivos y directorios de la VM que se migra.

En el registro de Docker, puedes elegir usar lo siguiente:

Consulta Definición de repositorios de datos para obtener más información.

Para implementar una carga de trabajo migrada en un clúster de destino, usa el siguiente comando:

kubectl apply -f deployment_spec.yaml

Donde deployment_spec.yaml es el archivo YAML que contiene la información de implementación de la carga de trabajo migrada. En deployment_spec.yaml, se incluye la propiedad de containers que especifica la ubicación de la imagen y del registro de Docker.

Por ejemplo:

    spec:
      containers:
      - image: gcr.io/PROJECT_ID/quickstart-instance:v1.0.0
        name: quickstart-instance

En este ejemplo, el archivo deployment_spec.yaml especifica que el registro de imágenes de Docker usa Google Container Registry (GCR).

Antes de implementar una carga de trabajo migrada en un clúster de destino, debes asegurarte de que el clúster tenga acceso de lectura al registro de Docker. En las siguientes secciones, se describe cómo habilitar el acceso a los diferentes tipos de registros.

Implementa cargas de trabajo en el clúster de procesamiento

Puedes implementar la carga de trabajo migrada en el mismo clúster que usaste para realizar la migración, que se denomina clúster de procesamiento de Migrate for Anthos and GKE. En la mayoría de las situaciones, no es necesario realizar ninguna configuración adicional en el clúster de procesamiento porque el clúster ya requiere acceso de lectura/escritura al registro de Docker para realizar una migración.

Sin embargo, si usas ECR como el registro de imágenes de Docker con clústeres de Anthos alojados en AWS, debes habilitar el acceso de lectura al grupo de nodos de AWS antes puede implementar la carga de trabajo. Consulta Realiza la implementación en un clúster de destino con ECR como registro de Docker a continuación para obtener más detalles.

Realiza la implementación en un clúster de destino con GCR como registro de Docker

A fin de asegurarte de que un clúster de destino tenga acceso a Google Container Registry (GCR), crea un Secret de Kubernetes que contenga las credenciales necesarias para acceder a GCR:

  1. Crea una cuenta de servicio para implementar una migración como se describe en Crea una cuenta de servicio para acceder a Container Registry y Cloud Storage.

    Este proceso te permite descargar un archivo de claves JSON con el nombre m4a-install.json.

  2. Crea un Secret de Kubernetes que contenga las credenciales necesarias para acceder a GCR:

    kubectl create secret docker-registry gcr-json-key \
 --docker-server=gcr.io --docker-username=_json_key --docker-password="$(cat ~/m4a-install.json)" \
 --docker-email=account@project.iam.gserviceaccount.com

    En el ejemplo anterior, se ilustra lo siguiente:

    • docker-registry especifica el nombre del Secret de Kubernetes; en este ejemplo es gcr-json-key.
    • docker-server=gcr.io especifica GCR como el servidor.
    • docker-username=_json_key especifica que el nombre de usuario está contenido en el archivo de claves JSON.
    • docker-password especifica que se use una contraseña del archivo de claves JSON.
    • docker-email especifica la dirección de correo electrónico de la cuenta de servicio.

  3. Configura el Secret de Kubernetes de las siguientes maneras:

    • Cambia el valor imagePullSecrets predeterminado:

      kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'

    • Edita el archivo deployment_spec.yaml para agregar el valor imagePullSecrets a la definición spec.template.spec, como se muestra a continuación:

      spec:
  containers:
  - image: gcr.io/PROJECT_ID/mycontainer-instance:v1.0.0
    name: mycontainer-instance
    ...
  volumes:
  - hostPath:
      path: /sys/fs/cgroup
      type: Directory
    name: cgroups
  imagePullSecrets:
  - name: gcr-json-key

Realiza la implementación en un clúster de destino con ECR como registro de Docker

Si tus clústeres de Anthos alojados en AWS usan ECR como el registro, puedes otorgarle al clúster acceso de lectura al registro.

Cuando creas clústeres de Anthos en AWS, puedes editar el archivo staging-nodepools.yaml a fin de personalizar la definición de grupo de nodos del clúster. Consulta Crea un clúster de usuario personalizado para obtener más información.

El archivo staging-nodepools.yaml contiene la propiedad iamInstanceProfile que especifica el nombre del perfil de la instancia de AWS EC2 asignado a los nodos en el grupo:

iamInstanceProfile: NODE_IAM_PROFILE

Asegúrate de que el perfil especificado tenga la función AmazonEC2ContainerRegistryReadOnly para habilitar el acceso de lectura de ECR.

Realiza la implementación en un clúster de destino con un registro de Docker con autenticación básica

Si usas un registro de Docker para almacenar imágenes de migración, el registro debe admitir la autenticación básica con un nombre de usuario y una contraseña. Debido a que existen muchas formas de configurar una conexión de solo lectura en un registro de Docker, debes usar el método adecuado para tu plataforma de clúster y registro de Docker.

Implementa una carga de trabajo en un proyecto de GCP distinto del que se usó para la migración

A menudo, tendrás varios proyectos de Google Cloud en tu entorno. Si realizas una migración en un proyecto de GCP, pero luego deseas implementar la carga de trabajo migrada en un clúster alojado en un proyecto diferente, debes asegurarte de tener los permisos configurados correctamente.

Por ejemplo, si realizas la migración en el proyecto A. En este caso, la carga de trabajo migrada se copia en un bucket de GCR alojado en el proyecto A. Por ejemplo:

gcr.io/project-a/image_name:image_tag

Luego, quieres implementar la carga de trabajo en un clúster del proyecto B. Si no configuras los permisos correctamente, el Pod de carga de trabajo no se ejecuta porque el clúster del proyecto B no tiene acceso para extraer imágenes en el proyecto A. Entonces, verás un evento en el Pod que contiene un mensaje con el siguiente formato:

Failed to pull image "gcr.io/project-a/image_name:image_tag...
pull access denied...
repository does not exist or may acquire 'docker login'...

Todos los proyectos que tienen habilitada la API de Compute Engine tienen una cuenta de servicio predeterminada de Compute Engine, que tiene la siguiente dirección de correo electrónico:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

En este ejemplo, PROJECT_NUMBER es el número de proyecto para el proyecto B.

A fin de solucionar este problema, asegúrate de que la cuenta de servicio predeterminada de Compute Engine del proyecto B tenga los permisos necesarios para acceder al bucket de GCR. Por ejemplo, puedes usar el siguiente comando de gsutil para habilitar el acceso:

gsutil iam ch serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com:objectViewer gs://artifacts.project-a.appspot.com

Aplica el archivo YAML de implementación generado

Usa kubectl para aplicar la especificación de implementación en el clúster de destino, como un clúster de producción.

kubectl

  1. Asegúrate de que el clúster de destino tenga acceso de lectura al registro de imágenes de Docker, como se describió antes en Asegúrate de que el clúster de destino tenga acceso de lectura al registro de imágenes de Docker.

  2. Implementa el contenedor:

    kubectl apply -f deployment_spec.yaml

  3. Después de completar las pruebas de validación en la carga de trabajo migrada para asegurarte de que la carga de trabajo migrada funcione de forma correcta, deberás borrar la migración para liberar recursos. Para obtener más información, consulta Borra una migración.

Borra una migración

Después de validar y probar la carga de trabajo migrada para asegurarte de que funciona de forma correcta, debes borrar la migración. Borrar la migración libera cualquier recurso que utilice la migración.

migctl

  1. Para borrar una migración completa, usa el siguiente comando: 

    migctl migration delete MIGRATION_NAME

    En el que MIGRATION_NAME es el nombre de la migración.

Console

  1. Abre la página Migrate for Anthos and GKE en Cloud Console.

    Ir a la página Migrar a contenedores

  2. Haz clic en la pestaña Migraciones para ver una tabla con las migraciones disponibles.

  3. Para hacer que la migración borre, haz clic en el ícono de papelera, , a la derecha de la tabla y, a continuación, selecciona Borrar migración.

Configura Workload Identity para AWS

Workload Identity para los clústeres de Anthos en AWS te permite vincular las cuentas de servicio de Kubernetes a las cuentas de IAM de AWS con permisos específicos. Workload Identity usa permisos de IAM de AWS para bloquear el acceso no deseado a los recursos de la nube.

Con Workload Identity, puedes asignar diferentes funciones de IAM a cada carga de trabajo. Este control detallado de los permisos te permite seguir el principio de privilegio mínimo.

Usa Workload Identity con Migrate for Anthos and GKE

Migrate for Anthos and GKE te permiten implementar tus cargas de trabajo migradas en clústeres de Anthos en AWS. Si habilitaste Workload Identity en tu clúster de implementación, debes asegurarte de configurar el entorno de implementación de forma correcta para que sea compatible con Migrate for Anthos and GKE.

Debes configurar dos variables de entorno para los servicios que usan Workload Identity

  • AWS_ROLE_ARN: Es el Amazon Resource Name (ARN) de la función de IAM.

  • AWS_WEB_IDENTITY_TOKEN_FILE: Es la ruta de acceso en la que se almacena el token.

Los pasos que debes realizar dependen del sistema init del clúster. Consulta a continuación los pasos específicos para systemd, SysV y Upstart.

Configura mediante kubectl exec

En las siguientes secciones, se describe cómo configurar un servicio para Workload Identity que inicia el sistema init. Para ejecutar comandos que usan Workload Identity en la shell del contenedor desde kubectl exec, primero debes ejecutar el siguiente comando en el Pod implementado:

ln -s /kubernetes-info/secrets /var/run/secrets

Si la activación de /var/run se borra (por un proceso en el pod o por el restablecimiento de un pod), es posible que debas ejecutar el comando nuevamente.

Configura el sistema init

Realiza los pasos que se indican a continuación para tu sistema init específico.

Configura systemd

systemd admite la configuración de variables de entorno para todos los servicios generados. Puedes agregar un archivo de configuración con el Dockerfile o automatizarlo en el contenedor externo.

Por ejemplo, edita el archivo de configuración /etc/systemd/system.conf.d/10-default-env.conf para establecer las variables de entorno:

[Manager]
DefaultEnvironment="AWS_ROLE_ARN=ROLE_ARN""AWS_WEB_IDENTITY_TOKEN_FILE=/kubernetes-info/secrets/eks.amazonaws.com/serviceaccount/token"

En el ejemplo anterior, ROLE_ARN especifica el nombre del recurso de Amazon (ARN) de la función de IAM como lo configuraste para AWS_ROLE_ARN cuando habilitaste Workload Identity.

Como alternativa, edita el Dockerfile para agregar lo siguiente:

RUN mkdir -p /etc/systemd/system.conf.d/
RUN echo '[Manager]' >> /etc/systemd/system.conf.d/10-default-env.conf
RUN echo 'DefaultEnvironment="AWS_ROLE_ARN=ROLE_ARN" "AWS_WEB_IDENTITY_TOKEN_FILE=/kubernetes-info/secrets/eks.amazonaws.com/serviceaccount/token" '>> /etc/systemd/system.conf.d/10-default-env.conf

Configura SysV/Upstart para servicios que no se ejecutan como raíz

Para los sistemas que usan SysV/Upstart en los que los servicios no se ejecutan como raíz, puedes usar pam_env a fin de configurar las variables de entorno:

  1. Agrega lo siguiente a /etc/pam.d/su:

    session required pam_env.so

  2. Agrega lo siguiente a /etc/environment:

    AWS_ROLE_ARN=ROLE_ARN
AWS_WEB_IDENTITY_TOKEN_FILE=/kubernetes-info/secrets/eks.amazonaws.com/serviceaccount/token

    En el ejemplo anterior, ROLE_ARN especifica el nombre del recurso de Amazon (ARN) de la función de IAM como lo configuraste para AWS_ROLE_ARN cuando habilitaste Workload Identity.

Como alternativa, edita el Dockerfile para agregar lo siguiente:

RUN echo "session        required      pam_env.so" >> /etc/pam.d/su
RUN echo 'AWS_ROLE_ARN=ROLE_ARN' >> /etc/environment
RUN echo 'AWS_WEB_IDENTITY_TOKEN_FILE=/kubernetes-info/secrets/eks.amazonaws.com/serviceaccount/token' >> /etc/environment

Configura SysV/Upstart para los servicios sin un usuario nuevo

En el caso de los servicios SysV/Upstart sin un usuario nuevo, se debe configurar el servicio de forma manual para que se establezca lo siguiente:

AWS_ROLE_ARN=ROLE_ARN
AWS_WEB_IDENTITY_TOKEN_FILE=/kubernetes-info/secrets/eks.amazonaws.com/serviceaccount/token

En el ejemplo anterior, ROLE_ARN especifica el nombre del recurso de Amazon (ARN) de la función de IAM como lo configuraste para AWS_ROLE_ARN cuando habilitaste Workload Identity.

Configura estas variables de entorno según el tipo de servicio:

  • SysV: Agrega líneas de exportación a tu secuencia de comandos de inicialización para configurar AWS_ROLE_ARN y AWS_WEB_IDENTITY_TOKEN_FILE..

  • Upstart: Consulta Variables de entorno para obtener más información sobre la configuración de variables de entorno, como AWS_ROLE_ARN y AWS_WEB_IDENTITY_TOKEN_FILE..

Accede al token de servicio desde un elemento no raíz dentro del contenedor

Sin importar el sistema init que tengas, para los servicios que no se ejecutan como raíz, debes otorgar acceso al token de servicio:

  1. Agrega la siguiente línea al Dockerfile: 

    RUN groupadd aws-token --gid ID_OF_CREATED_GROUP && usermod -a -G aws-token SERVICE_USER_NAME

    En el ejemplo anterior, ID_OF_CREATED_GROUP es un ID que eliges, como 1234.

  2. Agrega el siguiente a las especificaciones de implementación de la aplicación:

    securityContext:
    fsGroup: ID_OF_CREATED_GROUP

Consulta Configura un contexto de seguridad para un Pod o contenedor a fin de obtener más información.

Próximos pasos