Uso de Kubernetes Migration Factory (KMF) para migrar de Google Kubernetes Engine (GKE) a Amazon Elastic Kubernetes Service (Amazon EKS)

Kubernetes Migration Factory (KMF) es una herramienta de código abierto (Apache 2.0) que puede migrar los recursos de Kubernetes de un clúster que se ejecuta en Google Cloud Platform (GCP) a un clúster que se ejecuta en Amazon Web Services (AWS). La herramienta KMF fue desarrollada por un grupo de consultores del equipo de servicios profesionales de AWS para migrar los recursos de Kubernetes de un clúster de Google Kubernetes Engine (GKE) a Amazon Elastic Kubernetes Service (Amazon EKS). KMF está escrito en Golang y ofrece una interfaz de línea de comandos (CLI). La herramienta debe ejecutarse en un servidor que pueda autenticarse al mismo tiempo en los clústeres de Kubernetes de origen y destino (Amazon EKS en este caso) para migrar los recursos. Además, KMF puede migrar imágenes del contenedor de Google Container Registry (GCR) al Amazon Elastic Container Registry (Amazon ECR).

KMF es una plataforma de orquestación para la migración a gran escala de cargas de trabajo en contenedores a Amazon EKS. Está diseñado para coordinar y automatizar muchos de los procesos manuales, eliminar los errores humanos y acelerar las fases de migración, que se pueden ejecutar en minutos sin requerir semanas de planificación y recopilación de datos. Con solo unos pocos datos proporcionados a la CLI de KMF, los clientes podrán migrar las cargas de trabajo del clúster de Kubernetes de GKE a Amazon EKS e imágenes de contenedores de GCR a Amazon ECR.

KMF se creó para entender los detalles de implementación de la plataforma fuente y, a continuación, manipular los archivos de manifiesto de recursos obtenidos para que sean válidos y aceptados por la implementación de destino de Kubernetes, Amazon EKS. La solución se ofrece como una herramienta de código abierto.

Prerrequisitos y limitaciones

Esta herramienta migra los recursos de un clúster de Kubernetes a Amazon EKS, por lo que necesita un clúster de Amazon EKS de destino previamente implementado. Para obtener más información, consulte la documentación para crear un clúster de Amazon EKS.
En la estación de trabajo en la que se utilizará la herramienta CLI de KMF, configure el acceso al clúster de destino. Para obtener más información sobre cómo autenticarse y acceder a un clúster de Amazon EKS, consulte la documentación de autenticación de clústeres.
Configure la CLI de Kubernetes (kubectl), a través del archivo KUBECONFIG, para acceder al clúster Amazon EKS y la configuración es suficiente para que KMF tenga acceso. Consulte el archivo de configuración de kubeconfig para obtener documentación sobre el acceso al clúster Amazon EKS.
Del mismo modo, configure el archivo KUBECONFIG para acceder al clúster de Kubernetes de origen. En el caso de Google Kubernetes Engine (GKE), puedes consultar el acceso al clúster a la documentación de GKE, del mismo modo que configuras el acceso a la herramienta CLI de Kubernetes (kubectl).

Descargue la CLI de KMF (kmf) para su plataforma aquí. Si su plataforma no está entre las versiones disponibles, puede crear el binario a partir de las fuentes e instalarlo mediante las herramientas de desarrollo de Go y la configuración de un espacio de trabajo. Consulte la documentación de descarga e instalación para obtener más información sobre cómo instalar las herramientas de desarrollo de Go en su estación de trabajo.

El clúster Amazon EKS utilizado como destino para migrar la carga de trabajo de Kubernetes debe tener acceso al registro de imágenes del contenedor utilizado en el origen. Puedes seguir esta documentación de Kubernetes para aprender a extraer una imagen de un registro privado. Si crea el secreto para el acceso al registro privado en el clúster de Kubernetes de origen y también adjunta todas las especificaciones del contenedor a todos los recursos, KMF también lo migrará.
La herramienta KMF también ayuda a migrar imágenes de repositorios de terceros, como Google Container Registry (GCR), Docker Hub y el registro privado de GitLab, al Amazon Elastic Container Registry (ECR). En la estación de trabajo en la que se utilizará la CLI de KMF, asegúrese de configurar su inicio de sesión de Docker para Amazon ECR y también añada su inicio de sesión de Docker a la lista de repositorios compatibles (GCR, GitLab, Docker Hub) destinados a la migración antes de ejecutar KMF.

La herramienta KMF utiliza los privilegios de AWS asignados al identificador de ejecución para crear un Amazon Elastic Container Registry y cargar imágenes en él. La siguiente declaración de política de IAM es el permiso mínimo requerido. Aquí y a lo largo de este artículo, recuerde reemplazar el identificador por <AccountId>el identificador de su propia cuenta de AWS y la palabra <region>para la región de AWS utilizada en el entorno de destino.

{
  «Versión»: "2012-10-17",
  «Declaración»: [
    {
      «Sid»: «Listar imágenes en el repositorio»,
      «Efecto»: «Permitir»,
      «Acción»: [
        «ECR: lista de imágenes»
      ],
      <AccountId>«Recurso»: «arn:aws:ecr :repository/*<region>»
    },
    {
      «Sid»: «Obtener el token de autorización»,
      «Efecto»: «Permitir»,
      «Acción»: [
        «ECR: getAuthorizationToken»
      ],
      «Recurso»: «*»
    },
    {
      «Sid»: «Administrar el contenido del repositorio»,
      «Efecto»: «Permitir»,
      «Acción»: [
        «ECR: disponibilidad de capas de verificación por lotes»,
        «ECR: obtenga la URL de descarga para la capa»,
        «ECR: getRepository Policy»,
        «ECR: Describa los repositorios»,
        «ECR: lista de imágenes»,
        «ECR: describe imágenes»,
        «ECR: BatchGetImage»,
        «ECR: iniciar la carga de capas»,
        «ECR: UploadLayerPart»,
        «ECR: Carga completa de capas»,
        «ECR: PutImage»
      ],
      <AccountId>«Recurso»: «arn:aws:ecr :repository/*<region>»
    }
  ]
}

Limitaciones

KMF ayudará a migrar imágenes de contenedores de registro como Google Container Registry (CGR), GitLab y Docker Hub a Amazon Elastic Container Registry (ECR) y actualizará el manifiesto de despliegue con la ubicación de la imagen que apunta a Amazon ECR, pero no enviará el archivo de despliegue a sus repositorios de Git. Los administradores deben hacerlo manualmente.

Arquitectura

Conjunto de tecnologías de entorno de origen

Google Kubernetes Engine: Google Kubernetes Engine (GKE) es un entorno gestionado y listo para la producción para ejecutar aplicaciones en contenedores que ofrece Google Cloud.

Conjunto de tecnologías del entorno objetivo

Amazon Elastic Kubernetes Service: Amazon Elastic Kubernetes Service (Amazon EKS) ofrece la flexibilidad necesaria para lanzar, lanzar y escalar aplicaciones de Kubernetes en AWS o en entornos locales. Amazon EKS lo ayuda a implementar clústeres seguros y de alta disponibilidad y automatiza las tareas clave, como la aplicación de parches, los nodos de aprovisionamiento y las actualizaciones.

KMF architecture diagram

Diagrama de arquitectura

Automação e escalabilidade

KMF tool workflow

Flujo de trabajo de herramientas KMF

KMF está escrito en Go y la herramienta de línea de comandos (CLI) se puede usar para migrar cargas de trabajo y ayudar a automatizar las migraciones. El comando se puede incluir en un script de automatización. Como se muestra en el diagrama de flujo de trabajo, la herramienta KMF utiliza el archivo de configuración de la CLI de Kubernetes (KUBECONFIG) configurado para que GKE recopile los manifiestos de los recursos solicitados, que luego se modifican para adaptarlos al clúster de Kubernetes de destino de Amazon EKS antes de implementarlos.

Configuración CLI de KMF

Usando um binário já construído:

Usando un binario ya creado:

Etapas:

Descarga el binario CLI de KMF para tu sistema operativo desde GitHub a tu estación de trabajo, donde te autenticaste en los clústeres de origen y destino. Hay binarios compilados para Mac OS, Linux y Windows en el directorio bin/ del repositorio.

Para Mac OS, el binario está disponible en bin/mac/kmf
Para el sistema operativo Linux, el binario está disponible en bin/linux/kmf
Para el sistema operativo Windows, el binario está disponible en bin/windows/kmf

Opcional: añada la herramienta a la ruta de su sistema operativo.

Construyendo el binario a partir de la fuente:

Etapas:

#1 Clona el repositorio aws-kubernetes-migration-factory.

clon de git https://github.com/awslabs/aws-kubernetes-migration-factory

#2 Cambie el directorio a aws-kubernetes-migration-factory.

cd aws-kubernetes-migration-factory/

#3 Ejecute este comando para crear el binario CLI de KMF.

go build

El binario CLI de KMF se creará dentro del directorio actual como un archivo denominado containers-migration-factory. Si quieres que sea un nombre más corto, como kmf, ejecuta el comando build de la siguiente manera:

go build -o ./bin/kmf

Ejecute la CLI de KMF

Ejecución con un archivo de configuración

Asegúrate de tener un archivo llamado config.ini en el directorio desde el que realizas las llamadas. /bin/kmf y proporcione toda la información necesaria. A continuación se comparte un archivo config.ini de ejemplo y se puede encontrar una explicación detallada de cada parámetro en la documentación de Kubernetes Migration Factory (KMF).

[COMÚN]
# parámetros comunes de configuración de migración
# ruta local donde se guardarán los gráficos de Helm generados
helm_charts_path=/Usuarios/nombre de usuario/Kuberenetes-pocs/Helm
Recursos=Todos
# Los valores válidos para ACTION son Implementar/Eliminar
Acción = Implementar
# Espacios de nombres desde los que se migrarán los recursos
# lista de espacios de nombres separados por comas o «todos»
Namespaces=Todos

# Los proveedores de nube de origen válidos son GKE, AKE, KOPS
CLOUD=GKE
# Archivo de configuración kubeconfig de origen
# Consulte la documentación del proveedor del clúster de origen correspondiente para crear el archivo kubeconfig. Para el GKE, puedes consultar https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl
kube_config=/users/nombre/.kube/gcp.config
CONTEXTO= <Kube-Context-Name>

[OBJETIVO]
# El proveedor de nube de destino válido es solo AWS
CLOUD=AWS
# Archivo de configuración de kubeconfig de destino
# Consulte la documentación de AWS para crear el archivo kubeconfig https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html
kube_config=/users/nombre/.kube/config
CONTEXTO= <Kube-Context-Name>

[MIGRAR_IMAGENES]
# Esta sección se usa para pasar valores a la CLI de KMF con el fin de realizar la migración de las imágenes del registro de contenedores a Amazon ECR, y es opcional.
# ¿Desea migrar imágenes de repositorios de terceros al registro de Amazon Elastic Container? Indique «Sí» o «No»
Consentimiento de usuario = Sí
# Lista de registros de terceros separados por comas. La herramienta admite la migración de los registros de GCR, GitLab y DockerHub.
REGISTRY=GCR

Ejecución paso a paso

Aquí, mostramos los recursos de Kubernetes que se ejecutan en un clúster de Google Kubernetes Engine (GKE) y en un clúster de Amazon Elastic Kubernetes Service (EKS) antes de realizar la migración a través de la fábrica de migración de Kubernetes (KMF). Clúster GKE

$ kubectl obtiene ns
NOMBRE, ESTADO, EDAD
appdev Active 35 m
aproximadamente 35 m de actividad
Activo predeterminado 479d
infra Active 35 m
kube-node-lease Active 479d
Kube-Public Active 479d
Sistema Kube-System Active 479d
activo compartido 35m

Cluster Amazon EKS

$ kubectl obtiene ns
NOMBRE, ESTADO, EDAD
Active 472d por defecto
kube-node-lease Active 472d
Kube-Public Active 472D
Sistema Kube-System Active 472D

Veamos ahora un ejemplo del resultado de ejecución para ver cómo KMF realiza una migración de un clúster de GKE a un clúster de Amazon EKS.

PASO 1 En su estación de trabajo, navegue hasta la ruta en la que se descargó el repositorio de KMF.

PASO 2 Actualice config.ini. En este ejemplo, estamos realizando una migración de todas las funciones compatibles de GKS a Amazon EKS.

[COMÚN]
# parámetros de configuración comunes necesarios para la migración.
# Ruta local donde se generaron los gráficos de timón para guardar
helm_charts_path=/Usuarios/nombre de usuario/Kuberenetes-pocs/Helm
Recursos=Todos
# Valor válido para ACTION Deploy/Delete
Acción = Implementar
# Espacios de nombres desde los que deben migrar los recursos
# lista de espacios de nombres separados por comas o «todos»
Namespaces=Todos
[FUENTE]
# Los valores válidos de Source Cloud Provider son GKE, AKE, KOPS
CLOUD=GKE
# Archivo de configuración de Kube de origen
kube_config=/users/nombre/.kube/gcp.config
context=gke_cmf-aws_us-central1-c_cluster-1
[OBJETIVO]
CLOUD=AWS
# Archivo de configuración de Target Kube
kube_config=/users/nombre/.kube/config
context=arn:aws:eks:us-east- 1:12233344444:cluster/eksworkshop-eksctl
[MIGRAR_IMAGENES]
# ¿Desea migrar imágenes de repositorios de terceros a Amazon Elastic Container Registry? Suministre «Sí» o «No»
Consentimiento de usuario = Sí
# Lista de registros de terceros separados por comas. La herramienta admite la migración desde los registros gcr, gitlab y dockerhub.
REGISTRY=GCR

PASO 3 Ejecute el binario CLI de KMF. Extraerá los detalles de configuración, como la configuración del clúster de origen, la configuración del clúster de destino, la lista de recursos y el espacio de nombres del archivo config.ini. Etapa 1: Recopila el manifiesto de recursos de Kubernetes del clúster de origen (GKE) La herramienta KMF comienza por conectarse al clúster de GKE mediante el KUBECONFIG definido en config.ini y recopilando el manifiesto de los recursos solicitados. En este caso, seleccionamos todos los recursos que se van a migrar de GKE al clúster Amazon EKS.

[kubernetes-migrations-factory] #. /bin/kmf
Desplegar
Recursos de GKE
GKE Obtenga detalles de la fuente...
Lista de espacios de nombres ingresada como «todos» por el usuario, por lo que se considerarán todos los espacios de nombres
Nombre del gráfico: webserver-dev
secretos: templates/NOTES.txt
secretos: templates/_helpers.tpl
secretos: templates/configmap-vhosts.yaml
secretos: templates/configmap.yaml
secretos: templates/deployment.yaml
secretos: templates/extra-list.yaml
secretos: templates/hpa.yaml
secretos: templates/gress.yaml
secretos: templates/metrics-svc.yaml
secretos: templates/pdb.yaml
secretos: templates/prometheusrules.yaml
secretos: templates/servicemonitor.yaml
secretos: templates/svc.yaml
secretos: templates/tls-secrets.yaml
Nombre del archivo: .helmignore
Nombre del archivo: Léame. md
Nombre de fichero: Files/README.md
Nombre de archivo: Files/vHosts/README.md
Ruta: /app/helm/kmfhelmcharts/namespaces/appprod
Nombre del gráfico: webserver-prod
secretos: templates/NOTES.txt
secretos: templates/_helpers.tpl
secretos: templates/configmap-vhosts.yaml
secretos: templates/configmap.yaml
secretos: templates/deployment.yaml
secretos: templates/extra-list.yaml
secretos: templates/hpa.yaml
secretos: templates/gress.yaml
secretos: templates/metrics-svc.yaml
secretos: templates/pdb.yaml
secretos: templates/prometheusrules.yaml
secretos: templates/servicemonitor.yaml
secretos: templates/svc.yaml
secretos: templates/tls-secrets.yaml
Nombre del archivo: .helmignore
Nombre del archivo: Léame. md
Nombre de fichero: Files/README.md
Nombre de archivo: Files/vHosts/README.md
GKE FormatSourceData... iniciar
Datos de origen en formato GKE... Fin

Etapa 2: Modifique el archivo de manifiesto para adaptarlo al clúster de Amazon EKS antes de la implementación y, a continuación, impleméntelo.

El KMF comienza a desplegar todos los recursos recopilados en el clúster Amazon EKS. El KMF comienza con la implementación de funciones globales, como MutatingWebHook, que no son específicas del espacio de nombres. Si el despliegue ya está presente en el clúster de destino, KMF no lo reemplazará.

EKS Desplegando recursos...
Creando MutatingWebHook: cert-manager-webhook
mutatingwebhookconfigurations.admissionregistration.k8s.io «cert-manager-webhook» ya existe
Creando MutatingWebHook: neg-annotation.config.common-webhooks.networking.gke.io
mutatingwebhookconfigurations.admissionregistration.k8s.io «neg-annotation.config.common-webhooks.networking.gke.io» ya existe
Creando MutatingWebHook: pod-identity-webhook
Creando MutatingWebHook: pod-ready.config.common-webhooks.networking.gke.io
mutatingwebhookconfigurations.admissionregistration.k8s.io «pod-ready.config.common-webhooks.networking.gke.io» ya existe
Creando MutatingWebHook: vpc-resource-mutating-webhook
mutatingwebhookconfigurations.admissionregistration.k8s.io «vpc-resource-mutating-webhook» ya existe
Creando el espacio de nombres: appdev
Creando el espacio de nombres: appprod
Crear el espacio de nombres: predeterminado
Los espacios de nombres «predeterminados» ya existen
Creando el espacio de nombres: infra
Creando el espacio de nombres: compartido
Instalación de Chart webserver-dev en el clúster EKS en el espacio de nombres appdev
 Presta atención a que recojamos lo último de tus repositorios de gráficos...
... Recibí correctamente una actualización del repositorio de gráficos «kube-state-metrics»
... Recibí correctamente una actualización del repositorio de gráficos «nginx-stable»
... Recibí una actualización exitosa del repositorio de gráficos «Jenkins»
... Recibí correctamente una actualización del repositorio de gráficos «prometheus-community»
... Recibí correctamente una actualización del repositorio de gráficos «bitnami»
Actualización completada. ¡Feliz Helming! 
Guardar 1 gráfico
Descargando common desde el repositorio https://charts.bitnami.com/bitnami
Eliminar gráficos desactualizados

 Se ha actualizado la versión «webserver-dev». ¡Feliz Helming!
NOMBRE: webserver-dev
DESPLEGADO POR ÚLTIMA VEZ: Vie 1 de julio 15:15:54 2022
ESPACIO DE NOMBRES: appdev
ESTADO: desplegado
REVISIÓN: #2
CONJUNTO DE PRUEBAS: Ninguna
NOTAS:
NOMBRE DEL GRÁFICO: Apache
VERSIÓN GRÁFICA: 9.1.12
VERSIÓN DE LA APLICACIÓN: 2.4.54

**Tenga paciencia mientras se despliega el gráfico**

#1 Obtenga la URL de Apache ejecutando:

**Asegúrese de que haya una IP externa asociada al servicio webserver-dev-apache antes de continuar**
** Observe el estado usando: kubectl get svc --namespace appdev -w webserver-dev-apache **

  export SERVICE_IP=$ (kubectl get svc --namespace appdev webserver-dev-apache --template «{range (index .status.loadBalancer.ingress 0)}} {{.} {{fin}}»)
  URL de eco: http://$SERVICE_IP/


ADVERTENCIA: No proporcionaste una aplicación web personalizada. Apache se implementará con una página predeterminada. Consulte la sección README «Despliegue de una aplicación web personalizada» en https://github.com/bitnami/charts/blob/master/bitnami/apache/README.md#deploying-your-custom-web-application.

Instalación de Chart webserver-prod en el clúster EKS en el espacio de nombres appprod
 Presta atención a que recojamos lo último de tus repositorios de gráficos...
... Recibí correctamente una actualización del repositorio de gráficos «kube-state-metrics»
... Recibí correctamente una actualización del repositorio de gráficos «nginx-stable»
... Recibí una actualización exitosa del repositorio de gráficos «Jenkins»
... Recibí correctamente una actualización del repositorio de gráficos «prometheus-community»
... Recibí correctamente una actualización del repositorio de gráficos «bitnami»
Actualización completada. ¡Feliz Helming! 
Guardar 1 gráfico
Descargando common desde el repositorio https://charts.bitnami.com/bitnami
Eliminar gráficos desactualizados

 Se ha actualizado la versión «webserver-prod». ¡Feliz Helming!
NOMBRE: webserver-prod
DESPLEGADO POR ÚLTIMA VEZ: viernes, 1 de julio de 2022, 15:16:00
ESPACIO DE NOMBRES: aprox.
ESTADO: desplegado
REVISIÓN: #2
CONJUNTO DE PRUEBAS: Ninguna
NOTAS:
NOMBRE DEL GRÁFICO: Apache
VERSIÓN GRÁFICA: 9.1.12
VERSIÓN DE LA APLICACIÓN: 2.4.54

**Tenga paciencia mientras se despliega el gráfico**

#1 Obtenga la URL de Apache ejecutando:

**Asegúrese de que haya una IP externa asociada al servicio webserver-prod-apache antes de continuar**
** Observe el estado usando: kubectl get svc --namespace appprod -w webserver-prod-apache **

  export SERVICE_IP=$ (kubectl get svc --namespace appprod webserver-prod-apache --template «{{range (index .status.loadBalancer.ingress 0)}} {{.}} {{fin}}»)
  URL de eco: http://$SERVICE_IP/


ADVERTENCIA: No proporcionaste una aplicación web personalizada. Apache se implementará con una página predeterminada. Consulte la sección README «Despliegue de una aplicación web personalizada» en https://github.com/bitnami/charts/blob/master/bitnami/apache/README.md#deploying-your-custom-web-application.

=====================================================================
Operando en el espacio de nombres: appdev
=====================================================================
===============
Creando secretos
Creando el secreto: sh.helm.release.v1.webserver-dev.v1
===============
Creando ConfigMap's
===============
Creación de clases de almacenamiento
===============
Creación de reclamos de volumen persistentes
===============
Creación de una implementación
Creando una implementación: webserver-dev-apache
===============
Creación de servicio
Servicio de creación: webserver-dev-apache
===============
Creando Daemonset
===============
Creación de entradas
===============
Creación de roles
===============
Creación de enlaces de roles
===============
Creando secretos
Creando el secreto: sh.helm.release.v1.webserver-dev.v1
los secretos «sh.helm.release.v1.webserver-dev.v1" ya existen
===============
Creación de clases de almacenamiento
===============
Creando CronJob's
===============
Creación de puestos de trabajo
===============
Creación de roles de clúster
===============
Creación de enlaces de roles de clúster
===============
Creación de escaladores automáticos de POD horizontales
===============
Creación de políticas de seguridad de Pod
===============
Creación de trabajos de cuentas de servicio
Creación de una cuenta de servicio: predeterminada
serviceaccounts «default» ya existe
=====================================================================
Operando en el espacio de nombres: appprod
=====================================================================
===============
Creando secretos
Creando el secreto: sh.helm.release.v1.webserver-prod.v1
===============
Creando ConfigMap's
===============
Creación de clases de almacenamiento
===============
Creación de reclamos de volumen persistentes
===============
Creación de una implementación
Creando una implementación: webserver-prod-apache
===============
Creación de servicio
Servicio de creación: webserver-prod-apache
===============
Creando Daemonset
===============
Creación de entradas
===============
Creación de roles
===============
Creación de enlaces de roles
===============
Creando secretos
Creando el secreto: sh.helm.release.v1.webserver-prod.v1
los secretos «sh.helm.release.v1.webserver-prod.v1" ya existen
===============
Creación de clases de almacenamiento
===============
Creando CronJob's
===============
Creación de puestos de trabajo
===============
Creación de roles de clúster
===============
Creación de enlaces de roles de clúster
===============
Creación de escaladores automáticos de POD horizontales
===============
Creación de políticas de seguridad de Pod
===============
Creación de trabajos de cuentas de servicio
Creación de una cuenta de servicio: predeterminada
serviceaccounts «default» ya existe
=====================================================================
Operar en el espacio de nombres: predeterminado
=====================================================================
===============
Creando secretos
Creando un secreto: example-app-tls
Los secretos «example-app-tls» ya existen
===============
Creando ConfigMap's
Creando ConfigMap: entry-controller-leader-nginx
configmaps «entry-controller-leader-nginx» ya existe
Creando ConfigMap: kube-root-ca.crt
configmaps «kube-root-ca.crt» ya existe
Creando ConfigMap: secure-config
configmaps «secure-config» ya existe
Creando ConfigMap: prueba
La «prueba» de Configmaps ya existe
Creando ConfigMap: test1
configmaps «test1" ya existe
===============
Creación de clases de almacenamiento
===============
Creación de reclamos de volumen persistentes
Creando PVC: jenkins-data
persistentvolume afirma que «jenkins-data» ya existe
Creando PVC: myclaim
persistentvolumenafirma que «myclaim» ya existe
===============
Creación de una implementación
Creación de una implementación: despliegue de demostración
El «demo-deployment» de deployments.apps ya existe
Creando una implementación: httpd
deployments.apps «httpd» ya existe
Creando una implementación: nginx
deployments.apps «nginx» ya existe
===============
Creación de servicio
Servicio de creación: servicio de demostración
Los servicios de «servicio de demostración» ya existen
Servicio de creación: servicio de ejemplo
los servicios «example-service» ya existen
Servicio de creación: httpd
Los servicios «httpd» ya existen
Servicio de creación: Kubernetes
Los servicios «Kubernetes» ya existen
Servicio de creación: nginx
Los servicios «nginx» ya existen
Servicio de creación: nginx-loadbalancer
Los servicios «nginx-loadbalancer» ya existen
Servicio de creación: prueba
La «prueba» de servicios ya existe
===============
Creando Daemonset
===============
Creación de entradas
===============
Creación de roles
Creación de roles: lector de cápsulas
roles.rbac.authorization.k8s.io «pod-reader» ya existe
===============
Creación de enlaces de roles
Creación de enlaces de roles: read-pods
rolebindings.rbac.authorization.k8s.io «read-pods» ya existe
===============
Creando secretos
Creando un secreto: example-app-tls
Los secretos «example-app-tls» ya existen
===============
Creación de clases de almacenamiento
===============
Creando CronJob's
Creando CronJob: hola
cronjobs.batch «hello» ya existe
===============
Creación de puestos de trabajo
Creando trabajos: hello-1640030700
jobs.batch «hello-1640030700" ya existe
Creando trabajos: hello-1640030760
jobs.batch «hello-1640030760" ya existe
Creando trabajos: hello-1640030820
jobs.batch «hello-1640030820" ya existe
Creando trabajos: hello-1640031000
jobs.batch «hello-1640031000" ya existe
Creando trabajos: hello-1645046880
jobs.batch «hello-1645046880" ya existe
Creando trabajos: hello-1645046940
jobs.batch «hello-1645046940" ya existe
Creando trabajos: hello-1645047000
jobs.batch «hello-1645047000" ya existe
Creando trabajos: hello-1645072740
jobs.batch «hello-1645072740" ya existe
Creando trabajos: hello-1645072800
jobs.batch «hello-1645072800" ya existe
Creación de trabajos: hello-1645072860
jobs.batch «hello-1645072860" ya existe
Creación de trabajos: hello-1656688380
jobs.batch «hello-1656688380" ya existe
Creando trabajos: hello-1656688440
jobs.batch «hello-1656688440» ya existe
Creando trabajos: hello-1656688500
jobs.batch «hello-1656688500" ya existe
Creación de trabajos: pi
jobs.batch «pi» ya existe
===============
Creación de roles de clúster
===============
Creación de enlaces de roles de clúster
===============
Creación de escaladores automáticos de POD horizontales
===============
Creación de políticas de seguridad de Pod
===============
Creación de trabajos de cuentas de servicio
Creación de una cuenta de servicio: predeterminada
serviceaccounts «default» ya existe
=====================================================================
Operando en el espacio de nombres: infra
=====================================================================
===============
Creando secretos
===============
Creando ConfigMap's
===============
Creación de clases de almacenamiento
===============
Creación de reclamos de volumen persistentes
===============
Creación de una implementación
===============
Creación de servicio
===============
Creando Daemonset
===============
Creación de entradas
===============
Creación de roles
===============
Creación de enlaces de roles
===============
Creando secretos
===============
Creación de clases de almacenamiento
===============
Creando CronJob's
Creando CronJob: hola
===============
Creación de puestos de trabajo
Creación de trabajos: hello-1656688380
Creando trabajos: hello-1656688440
Creando trabajos: hello-1656688500
===============
Creación de roles de clúster
===============
Creación de enlaces de roles de clúster
===============
Creación de escaladores automáticos de POD horizontales
===============
Creación de políticas de seguridad de Pod
===============
Creación de trabajos de cuentas de servicio
Creación de una cuenta de servicio: predeterminada
serviceaccounts «default» ya existe
=====================================================================
Operando en un espacio de nombres: compartido
=====================================================================
===============
Creando secretos
Creando un secreto: sharedaccesssecret
===============
Creando ConfigMap's
===============
Creación de clases de almacenamiento
===============
Creación de reclamos de volumen persistentes
===============
Creación de una implementación
===============
Creación de servicio
===============
Creando Daemonset
===============
Creación de entradas
===============
Creación de roles
===============
Creación de enlaces de roles
===============
Creando secretos
Creando un secreto: sharedaccesssecret
Los secretos «sharedaccesssecret» ya existen
===============
Creación de clases de almacenamiento
===============
Creando CronJob's
===============
Creación de puestos de trabajo
===============
Creación de roles de clúster
===============
Creación de enlaces de roles de clúster
===============
Creación de escaladores automáticos de POD horizontales
===============
Creación de políticas de seguridad de Pod
===============
Creación de trabajos de cuentas de servicio
Creación de una cuenta de servicio: predeterminada
serviceaccounts «default» ya existe

PASO 4 Verifique el resultado en el clúster Amazon EKS

[kubernetes-migrations-factory] # kubectl obtiene ns
NOMBRE, ESTADO, EDAD
appdev Active 14 m
Activo aprox. 14 m
Active 472d por defecto
infra Active 14m
kube-node-lease Active 472d
Kube-Public Active 472D
Sistema Kube-System Active 472D
activo compartido 14m

Se ejecuta como un comando de una línea

La herramienta KMF también acepta parámetros como argumentos de línea de comandos. En este caso, cualquier argumento de la CLI tiene prioridad sobre cualquier definición de config.ini.

Migración de todos los recursos de todos los espacios de nombres

A continuación se muestra un ejemplo de cómo se pueden migrar todas las funciones de Kubernetes compatibles con KMF desde todos los espacios de nombres.

$. /bin/kmf --source_kubeconfig /Usuarios/ <user-name>/.kube/gcp.config\
--destination_kubeconfig /Usuarios/ <user-name>/.kube/aws.config\
--namespaces «todos»\
--recursos «todos»\
--migrate_images «sí»\
--reg_names «gcr, dockerhub, gitlab»\
--source_context<source_kubernetes_context>\  
--contexto_de destino<destination_kubernetes_context>\
--ruta del timón<local-file-system-path>\
--despliegue de acciones

Migración de despliegues y servicios desde varios espacios de nombres

A continuación se muestra un ejemplo de cómo migrar recursos de Kubernetes seleccionados desde espacios de nombres específicos.

$. /bin/kmf --source_kubeconfig\
/Usuarios/ <user-name>/.kube/gcp.config --destination_kubeconfig\
/Usuarios/ <user-name>/.kube/aws.config\
--namespaces «dev, predeterminado»\
--resources «despliegue, servicio»\
--migrate_images «sí»\
--reg_names «gcr, dockerhub, gitlab»\
--source_context<source_kubernetes_context>\
--contexto_de destino<destination_kubernetes_context>\
--ruta del timón<local-file-system-path>\
--action Deploy

Limpieza

Para borrar la instalación de la herramienta KMF, simplemente elimine el directorio aws-kubernetes-migration-factory de la estación de trabajo en la que se clonó el repositorio. Si desea eliminar los recursos de Kubernetes migrados en el clúster de destino, simplemente elija la acción «Eliminar» en el archivo de configuración de KMF. Esto solo eliminará los recursos migrados en el clúster de Amazon EKS y no eliminará ningún recurso del clúster de GKE.

Recursos relacionados

Conclusión

La fábrica de migración de Kubernetes (KMF) se puede usar para migrar rápidamente tus cargas de trabajo de Kubernetes de GKE a un clúster de Amazon EKS. En esta entrada de blog, proporcionamos un ejemplo de cómo se puede utilizar KMF desde una terminal como herramienta de línea de comandos (CLI). El código fuente de KMF está disponible en el repositorio de GitHub y es de código abierto. Cualquier persona de la comunidad interesada en este tema puede contribuir o ponerse en contacto con nosotros a través de los problemas de GitHub.

Este artículo fue traducido del Blog da AWS em Inglés.

Acerca de los autores

Vasanth Jeyaraj es arquitecto de infraestructura de nube en Amazon Web Services (AWS). Ayuda a los clientes corporativos a crear una infraestructura siguiendo las mejores prácticas, centrándose en la automatización y la infraestructura como código, y también se centra en ayudar a los clientes a acelerar su proceso de adopción de tecnologías de nube nativas y modernizar la infraestructura de su plataforma y su arquitectura interna mediante la estrategia de microservicios, la contenerización y DevOps. Fuera del trabajo, le encanta pasar tiempo con su familia y viajar.

Kirankumar Chandrashekar es arquitecto sénior de soluciones de cuentas estratégicas en AWS. Se dedica a los clientes clave en el campo de la arquitectura DevOps y las tecnologías de contenedores, por nombrar algunos. A Kirankumar le apasionan DevOps, la infraestructura como código y la solución de problemas complejos de los clientes. Le gusta la música además de cocinar y viajar.

Mahendra Siddappa es consultor de DevOps en Amazon Web Services. Trabaja con clientes de AWS en ideas de contenedores, kubernetes y DevOps.

Revisor

César Páez Román se encuentra en Chile y es un arquitecto de soluciones AWS especializado en migraciones. César posee vasta experiencia en el campo de migraciones del segmento Enterprise y además con profundo conocimiento y experiencia de SAP, atiende el territorio de América Latina.

Blog de Amazon Web Services (AWS)