O blog da AWS

Usando o Kubernetes Migration Factory (KMF) para migrar do Google Kubernetes Engine (GKE) para o Amazon Elastic Kubernetes Service (Amazon EKS)

Por Vasanth Jeyaraj, Arquiteto de infraestrutura na AWS;
Kirankumar Chandrashekar, Arquiteto sênior de soluções na AWS e
Mahendra Revanasiddappa consultor de DevOps na AWS
O Kubernetes Migration Factory (KMF) é uma ferramenta de código aberto (Apache 2.0) que pode migrar recursos do Kubernetes de um cluster em execução no Google Cloud Platform (GCP) para um cluster executado no Amazon Web Services (AWS). A ferramenta KMF foi desenvolvida por um grupo de consultores do time da AWS Professional Services para migrar recursos do Kubernetes de um cluster do Google Kubernetes Engine (GKE) para o Amazon Elastic Kubernetes Service (Amazon EKS). O KMF é escrito em Golang e oferece uma interface de linha de comando (CLI). A ferramenta deve ser executada em um servidor que pode se autenticar ao mesmo tempo no cluster Kubernetes de origem e no de destino — Amazon EKS neste caso — para migrar recursos. Além disso, o KMF pode migrar as imagens do contêiner do Google Container Registry (GCR) para o Amazon Elastic Container Registry (Amazon ECR).

O KMF é uma plataforma de orquestração para migração em grande escala de cargas de trabalho conteinerizadas para o Amazon EKS. Ele foi projetado para coordenar e automatizar muitos dos processos manuais, eliminando erros humanos e acelerando as fases de migração, que podem ser executadas em minutos sem demandar semanas de planejamento e coleta de dados. Com apenas algumas informações fornecidas à CLI do KMF, os clientes poderão migrar cargas de trabalho do cluster Kubernetes do GKE para o Amazon EKS e imagens de contêiner do GCR para o Amazon ECR.

O KMF foi criado para entender os detalhes de implementação da plataforma de origem e, em seguida, manipular os arquivos de manifesto dos recursos obtidos para que sejam válidos e aceitos pela implementação de destino do Kubernetes, o Amazon EKS. A solução é oferecida como uma ferramenta de código aberto.

Pré-requisitos e limitações

  • Essa ferramenta migra recursos de um cluster Kubernetes para o Amazon EKS, então ela precisa de um cluster Amazon EKS de destino previamente implantado. Para obter mais informações, consulte a documentação de criação de um cluster do Amazon EKS.
  • Na estação de trabalho em que a ferramenta CLI do KMF será usada, configure o acesso para o cluster de destino. Para obter mais informações sobre como autenticar e acessar um cluster Amazon EKS, consulte a documentação de autenticação de clusters.
  • Configure a CLI do Kubernetes (kubectl), através do arquivo KUBECONFIG, para acessar o Amazon EKS Cluster e a configuração é suficiente para que o KMF tenha acesso. Consulte o arquivo de configuração kubeconfig para obter a documentação de acesso ao cluster do Amazon EKS.
  • Da mesma forma, configure o arquivo KUBECONFIG para o acesso ao cluster Kubernetes de origem. Para o Google Kubernetes Engine (GKE), você pode consultar o acesso ao cluster à documentação do GKE, da mesma forma que configura o acesso à ferramenta Kubernetes CLI (kubectl).
  • Baixe a CLI do KMF (kmf) para sua plataforma aqui. Se sua plataforma não estiver entre as versões disponíveis, você pode construir o binário a partir dos fontes e instalar através das ferramentas de desenvolvimento Go e da configuração de um Workspace. Consulte a documentação de download e instalação para obter mais informações sobre como instalar as ferramentas de desenvolvimento Go em sua estação de trabalho.
  • O cluster do Amazon EKS usado como destino para migrar a carga de trabalho do Kubernetes deve ter acesso ao registro de imagens de container usado na origem. Você pode seguir esta documentação do Kubernetes para aprender como extrair uma imagem de um registro privado. Se você criar o Secret para acesso ao registro privado no cluster Kubernetes de origem e também anexar todas as especificações do contêiner em todos os recursos, o KMF também migrará isso.
  • A ferramenta KMF também ajuda a migrar imagens de repositórios de terceiros, como Google Container Registry (GCR), Docker Hub e registro privado do GitLab, para o Amazon Elastic Container Registry (ECR). Na estação de trabalho em que a CLI do KMF será usada, certifique-se de configurar seu login do Docker para o Amazon ECR e também adicionar seu login do Docker à lista de repositórios compatíveis (GCR, GitLab, Docker Hub) destinados à migração antes da execução do KMF.
  • A ferramenta KMF usa os privilégios da AWS atribuídos ao ID de execução para criar um Amazon Elastic Container Registry e enviar imagens para ele. A declaração da IAM Policy a seguir é a permissão mínima necessária. Aqui e ao longo deste artigo, lembre-se de substituir o <AccountId> pelo ID da sua própria conta AWS e a palavra <region> pela região AWS em uso no ambiente de destino.
  • {
    "Version":"2012-10-17",
    "Statement":[
    {
    "Sid":"ListImagesInRepository",
    "Effect":"Allow",
    "Action":[
    "ecr:ListImages"
    ],
    "Resource":"arn:aws:ecr:<region>:<AccountId>:repository/*"
    },
    {
    "Sid":"GetAuthorizationToken",
    "Effect":"Allow",
    "Action":[
    "ecr:GetAuthorizationToken"
    ],
    "Resource":"*"
    },
    {
    "Sid":"ManageRepositoryContents",
    "Effect":"Allow",
    "Action":[
    "ecr:BatchCheckLayerAvailability",
    "ecr:GetDownloadUrlForLayer",
    "ecr:GetRepositoryPolicy",
    "ecr:DescribeRepositories",
    "ecr:ListImages",
    "ecr:DescribeImages",
    "ecr:BatchGetImage",
    "ecr:InitiateLayerUpload",
    "ecr:UploadLayerPart",
    "ecr:CompleteLayerUpload",
    "ecr:PutImage"
    ],
    "Resource":"arn:aws:ecr:<region>:<AccountId>:repository/*"
    }
    ]
    }

Limitações

  • O KMF ajudará a migrar imagens de contêineres de registros como Google Container Registry (CGR), GitLab e Docker Hub para o Amazon Elastic Container Registry (ECR) e atualizará o manifesto de implantação com a localização da imagem apontando para o Amazon ECR, mas não enviará o arquivo de implantação para seus repositórios Git. Isso deve ser feito manualmente pelos administradores.

Arquitetura

Pilha de tecnologia do ambiente de origem

Google Kubernetes Engine — O Google Kubernetes Engine (GKE) é um ambiente gerenciado e pronto para produção para executar aplicativos em contêineres oferecidos pelo Google Cloud.

Pilha de tecnologia do ambiente de destino

Amazon Elastic Kubernetes Service — O Amazon Elastic Kubernetes Service (Amazon EKS) oferece a flexibilidade de iniciar, executar e escalar aplicativos Kubernetes na AWS ou em ambientes locais. O Amazon EKS ajuda você a implantar clusters seguros e altamente disponíveis, e automatiza as principais tarefas, como aplicação de patches, provisionamento de nós e atualizações.

KMF architecture diagram

Diagrama de arquitetura

Automação e escalabilidade

KMF tool workflow

Fluxo de trabalho da ferramenta KMF

O KMF é escrito em Go, e a ferramenta de linha de comando (CLI) pode ser usada para migrar cargas de trabalho e ajudar a automatizar as migrações. O comando pode ser incluído em um script de automação. Conforme mostrado no diagrama do fluxo de trabalho, a ferramenta KMF usa o arquivo de configuração da CLI do Kubernetes (KUBECONFIG) configurado para o GKE para coletar manifestos dos recursos solicitados, que são então modificados para se adequar ao cluster Kubernetes de destino do Amazon EKS antes de implantá-los.

Configuração da CLI do KMF

Usando um binário já construído:

Etapas:

  1. Baixe a binário da CLI do KMF para seu sistema operacional do GitHub para sua estação de trabalho, onde você se autenticou nos clusters de origem e de destino. Há binários compilados para Mac OS, Linux e Windows no diretório bin/ do repositório.
  • Para Mac OS, o binário está disponível em bin/mac/kmf
  • Para o sistema operacional Linux, o binário está disponível em bin/linux/kmf
  • Para o sistema operacional Windows, o binário está disponível em bin/windows/kmf
  1. Opcional: adicione a ferramenta ao caminho do seu sistema operacional.

Construindo o binário a partir da fonte:

Etapas:

1. Clone o repositório aws-kubernetes-migration-factory.

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

2. Altere o diretório para aws-kubernetes-migration-factory.

cd aws-kubernetes-migration-factory/
  1. Execute esse comando para criar o binário da CLI do KMF.
go build

O binário KMF CLI será construído dentro do diretório atual como um arquivo chamado containers-migration-factory. Se você quiser que esse seja um nome mais curto, como kmf, execute o comando build desta forma:

go build -o ./bin/kmf

Execute o KMF CLI

Executando com um arquivo de configuração

Certifique-se de ter um arquivo chamado config.ini no diretório de onde você está fazendo chamadas para o ./bin/kmf e forneça todas as informações necessárias. Um exemplo de arquivo config.ini é compartilhado abaixo, e uma explicação detalhada para cada parâmetro pode ser encontrada na documentação do Kubernetes Migration Factory (KMF).

[COMMON]
# parâmetros comuns de configuração da migração
# caminho local onde os Helm Charts gerados serão salvos
HELM_CHARTS_PATH=/Users/username/kuberenetes-pocs/helm
RESOURCES=all
# Valores válidos para ACTION são Deploy/Delete
ACTION=Deploy
# Namespaces de onde os recursos serão migrados
# lista de namespaces separados por virgula, ou “all”
NAMESPACES=all

# Provedores de nuvem de origem validos são GKE,AKE,KOPS
CLOUD=GKE
# Arquivo de configuração kubeconfig da origem
# Consulte a documentação do respectivo provedor de cluster de origem para criar o arquivo kubeconfig. Para o GKE, você pode consultar https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl
KUBE_CONFIG=/Users/username/.kube/gcp.config
CONTEXT=<Kube-Context-Name>

[TARGET]
# Provedor de nuvem de destino valido é somente AWS
CLOUD=AWS
# Arquivo de configuração kubeconfig do destino
# Consulte a documentação da AWS para criar o arquivo kubeconfig https://docs.thinkwithwp.com/eks/latest/userguide/create-kubeconfig.html
KUBE_CONFIG=/Users/username/.kube/config
CONTEXT=<Kube-Context-Name>

[MIGRATE_IMAGES]
# Esta seção é usada para passar valores para a CLI do KMF para realizar a migração de imagens de registro de contêineres para o Amazon ECR, e isso é opcional.
# Você deseja migrar imagens de repositórios de terceiros para o Amazon Elastic Container Registry? Forneça “Yes” ou “No”
USERCONSENT=Yes
# Lista separada por vírgulas de registros de terceiros. A ferramenta suporta a migração dos registros GCR, GitLab e DockerHub.
REGISTRY=GCR

Passo a passo da execução

Aqui, mostramos os recursos do Kubernetes em execução em um cluster Google Kubernetes Engine (GKE) e um cluster Amazon Elastic Kubernetes Service (EKS) antes de executar a migração através do Kubernetes Migration Factory (KMF).

GKE cluster

$ kubectl get ns
NAME              STATUS   AGE
appdev            Active   35m
appprod           Active   35m
default           Active   479d
infra             Active   35m
kube-node-lease   Active   479d
kube-public       Active   479d
kube-system       Active   479d
shared            Active   35m

Cluster Amazon EKS

$ kubectl get ns
NAME              STATUS   AGE
default           Active   472d
kube-node-lease   Active   472d
kube-public       Active   472d
kube-system       Active   472d

Agora, vamos analisar um exemplo de saída de execução para ver como o KMF realiza uma migração de um cluster GKE para um cluster do Amazon EKS.

Passo 1. Em sua estação de trabalho, navegue até o caminho em que o repositório KMF foi baixado.

Passo 2. Atualize config.ini. Neste exemplo, estamos realizando uma migração de todos os recursos suportados do GKS para o Amazon EKS.

[COMMON]
# common configuration params required for migration.
# Local path where generated helm charts to be saved
HELM_CHARTS_PATH=/Users/username/kuberenetes-pocs/helm
RESOURCES=all
# Valid Value for ACTION Deploy/Delete
ACTION=Deploy
# Namespaces from which the resources need to migrated
# comma seperated list of namespace or "all"
NAMESPACES=all
[SOURCE]
# Source Cloud Provider valid values are GKE,AKE,KOPS
CLOUD=GKE
# Source kube config file
KUBE_CONFIG=/Users/username/.kube/gcp.config
CONTEXT=gke_cmf-aws_us-central1-c_cluster-1
[TARGET]
CLOUD=AWS
# Target kube config file
KUBE_CONFIG=/Users/username/.kube/config
CONTEXT=arn:aws:eks:us-east-1:12233344444:cluster/eksworkshop-eksctl
[MIGRATE_IMAGES]
# Do you wish to migrate images from 3rd party repositories to Amazon Elastic Container Registry? Supply either "Yes" or "No"
USERCONSENT=Yes
# Comma separated list of 3rd party registries. Tool supports migration from gcr, gitlab, dockerhub registries.
REGISTRY=GCR

 Passo 3. Execute o binário da CLI do KMF. Ele extrairá detalhes de configuração, como configuração do cluster de origem, configuração do cluster de destino, lista de recursos e namespace do arquivo 
        config.ini. Estágio 1: Coletar o manifesto de recursos do Kubernetes do cluster de origem (GKE) A ferramenta KMF começa conectando-se ao cluster do GKE usando o 
        KUBECONFIG definido em 
        config.ini e coletando o manifesto dos recursos solicitados. Nesse caso, selecionamos todos os recursos a serem migrados do GKE para o cluster Amazon EKS. 
        
[kubernetes-migrations-factory]# ./bin/kmf
Deploy
GKE Resources
GKE GetSourceDetails....
Namespace list entered as 'all' by user, hence all namespaces will be considered
Chart Name: webserver-dev
secrets: templates/NOTES.txt
secrets: templates/_helpers.tpl
secrets: templates/configmap-vhosts.yaml
secrets: templates/configmap.yaml
secrets: templates/deployment.yaml
secrets: templates/extra-list.yaml
secrets: templates/hpa.yaml
secrets: templates/ingress.yaml
secrets: templates/metrics-svc.yaml
secrets: templates/pdb.yaml
secrets: templates/prometheusrules.yaml
secrets: templates/servicemonitor.yaml
secrets: templates/svc.yaml
secrets: templates/tls-secrets.yaml
Files Name: .helmignore
Files Name: README.md
Files Name: files/README.md
Files Name: files/vhosts/README.md
Path : /app/helm/KMFHelmCharts/namespaces/appprod
Chart Name: webserver-prod
secrets: templates/NOTES.txt
secrets: templates/_helpers.tpl
secrets: templates/configmap-vhosts.yaml
secrets: templates/configmap.yaml
secrets: templates/deployment.yaml
secrets: templates/extra-list.yaml
secrets: templates/hpa.yaml
secrets: templates/ingress.yaml
secrets: templates/metrics-svc.yaml
secrets: templates/pdb.yaml
secrets: templates/prometheusrules.yaml
secrets: templates/servicemonitor.yaml
secrets: templates/svc.yaml
secrets: templates/tls-secrets.yaml
Files Name: .helmignore
Files Name: README.md
Files Name: files/README.md
Files Name: files/vhosts/README.md
GKE FormatSourceData....start
GKE FormatSourceData....End
 
        
Estágio 2: Modifique o arquivo de manifesto para se adequar ao cluster do Amazon EKS antes da implantação e, em seguida, implante-o.
 
        
O KMF começa a implantar todos os recursos coletados no cluster Amazon EKS. O KMF começa implantando recursos globais, como MutatingWebhook, que não são específicos de namespaces. Se a implantação já estiver presente no cluster de destino, o KMF não a substituirá.
 
        
EKS Deploying resources....
Creating MutatingWebhook:  cert-manager-webhook
mutatingwebhookconfigurations.admissionregistration.k8s.io "cert-manager-webhook" already exists
Creating MutatingWebhook:  neg-annotation.config.common-webhooks.networking.gke.io
mutatingwebhookconfigurations.admissionregistration.k8s.io "neg-annotation.config.common-webhooks.networking.gke.io" already exists
Creating MutatingWebhook:  pod-identity-webhook
Creating MutatingWebhook:  pod-ready.config.common-webhooks.networking.gke.io
mutatingwebhookconfigurations.admissionregistration.k8s.io "pod-ready.config.common-webhooks.networking.gke.io" already exists
Creating MutatingWebhook:  vpc-resource-mutating-webhook
mutatingwebhookconfigurations.admissionregistration.k8s.io "vpc-resource-mutating-webhook" already exists
 
        
Creating the namespace:  appdev
Creating the namespace:  appprod
Creating the namespace:  default
namespaces "default" already exists
Creating the namespace:  infra
Creating the namespace:  shared
Installing Chart  webserver-dev  on EKS cluster in namespace  appdev
 Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "kube-state-metrics" chart repository
...Successfully got an update from the "nginx-stable" chart repository
...Successfully got an update from the "jenkins" chart repository
...Successfully got an update from the "prometheus-community" chart repository
...Successfully got an update from the "bitnami" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 1 charts
Downloading common from repo https://charts.bitnami.com/bitnami
Deleting outdated charts

 Release "webserver-dev" has been upgraded. Happy Helming!
NAME: webserver-dev
LAST DEPLOYED: Fri Jul  1 15:15:54 2022
NAMESPACE: appdev
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:
CHART NAME: apache
CHART VERSION: 9.1.12
APP VERSION: 2.4.54

** Please be patient while the chart is being deployed **

1. Get the Apache URL by running:

** Please ensure an external IP is associated to the webserver-dev-apache service before proceeding **
** Watch the status using: 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) }}{{ . }}{{ end }}")
  echo URL            : http://$SERVICE_IP/


WARNING: You did not provide a custom web application. Apache will be deployed with a default page. Check the README section "Deploying your custom web application" in https://github.com/bitnami/charts/blob/master/bitnami/apache/README.md#deploying-your-custom-web-application.

Installing Chart  webserver-prod  on EKS cluster in namespace  appprod
 Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "kube-state-metrics" chart repository
...Successfully got an update from the "nginx-stable" chart repository
...Successfully got an update from the "jenkins" chart repository
...Successfully got an update from the "prometheus-community" chart repository
...Successfully got an update from the "bitnami" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 1 charts
Downloading common from repo https://charts.bitnami.com/bitnami
Deleting outdated charts

 Release "webserver-prod" has been upgraded. Happy Helming!
NAME: webserver-prod
LAST DEPLOYED: Fri Jul  1 15:16:00 2022
NAMESPACE: appprod
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:
CHART NAME: apache
CHART VERSION: 9.1.12
APP VERSION: 2.4.54

** Please be patient while the chart is being deployed **

1. Get the Apache URL by running:

** Please ensure an external IP is associated to the webserver-prod-apache service before proceeding **
** Watch the status using: 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) }}{{ . }}{{ end }}")
  echo URL            : http://$SERVICE_IP/


WARNING: You did not provide a custom web application. Apache will be deployed with a default page. Check the README section "Deploying your custom web application" in https://github.com/bitnami/charts/blob/master/bitnami/apache/README.md#deploying-your-custom-web-application.

=====================================================================
Operating on namespace:  appdev
=====================================================================
===============
Creating Secrets
Creating Secret:  sh.helm.release.v1.webserver-dev.v1
===============
Creating ConfigMap's
===============
Creating StorageClasses
===============
Creating PersistentVolumeClaims
===============
Creating Deployment
Creating Deployment:  webserver-dev-apache
===============
Creating Service
Creating Service:  webserver-dev-apache
===============
Creating Daemonset
===============
Creating Ingresses
===============
Creating Roles
===============
Creating Role Bindings
===============
Creating Secrets
Creating Secret:  sh.helm.release.v1.webserver-dev.v1
secrets "sh.helm.release.v1.webserver-dev.v1" already exists
===============
Creating StorageClasses
===============
Creating CronJob's
===============
Creating Job's
===============
Creating Cluster Roles
===============
Creating Cluster Role Bindings
===============
Creating HorizontalPodAutoscalers
===============
Creating Pod security policies
===============
Creating Service Account Job's
Creating Service Account:  default
serviceaccounts "default" already exists
=====================================================================
Operating on namespace:  appprod
=====================================================================
===============
Creating Secrets
Creating Secret:  sh.helm.release.v1.webserver-prod.v1
===============
Creating ConfigMap's
===============
Creating StorageClasses
===============
Creating PersistentVolumeClaims
===============
Creating Deployment
Creating Deployment:  webserver-prod-apache
===============
Creating Service
Creating Service:  webserver-prod-apache
===============
Creating Daemonset
===============
Creating Ingresses
===============
Creating Roles
===============
Creating Role Bindings
===============
Creating Secrets
Creating Secret:  sh.helm.release.v1.webserver-prod.v1
secrets "sh.helm.release.v1.webserver-prod.v1" already exists
===============
Creating StorageClasses
===============
Creating CronJob's
===============
Creating Job's
===============
Creating Cluster Roles
===============
Creating Cluster Role Bindings
===============
Creating HorizontalPodAutoscalers
===============
Creating Pod security policies
===============
Creating Service Account Job's
Creating Service Account:  default
serviceaccounts "default" already exists
=====================================================================
Operating on namespace:  default
=====================================================================
===============
Creating Secrets
Creating Secret:  example-app-tls
secrets "example-app-tls" already exists
===============
Creating ConfigMap's
Creating ConfigMap:  ingress-controller-leader-nginx
configmaps "ingress-controller-leader-nginx" already exists
Creating ConfigMap:  kube-root-ca.crt
configmaps "kube-root-ca.crt" already exists
Creating ConfigMap:  secure-config
configmaps "secure-config" already exists
Creating ConfigMap:  test
configmaps "test" already exists
Creating ConfigMap:  test1
configmaps "test1" already exists
===============
Creating StorageClasses
===============
Creating PersistentVolumeClaims
Creating PVC:  jenkins-data
persistentvolumeclaims "jenkins-data" already exists
Creating PVC:  myclaim
persistentvolumeclaims "myclaim" already exists
===============
Creating Deployment
Creating Deployment:  demo-deployment
deployments.apps "demo-deployment" already exists
Creating Deployment:  httpd
deployments.apps "httpd" already exists
Creating Deployment:  nginx
deployments.apps "nginx" already exists
===============
Creating Service
Creating Service:  demo-service
services "demo-service" already exists
Creating Service:  example-service
services "example-service" already exists
Creating Service:  httpd
services "httpd" already exists
Creating Service:  kubernetes
services "kubernetes" already exists
Creating Service:  nginx
services "nginx" already exists
Creating Service:  nginx-loadbalancer
services "nginx-loadbalancer" already exists
Creating Service:  test
services "test" already exists
===============
Creating Daemonset
===============
Creating Ingresses
===============
Creating Roles
Creating Roles:  pod-reader
roles.rbac.authorization.k8s.io "pod-reader" already exists
===============
Creating Role Bindings
Creating Role Bindings:  read-pods
rolebindings.rbac.authorization.k8s.io "read-pods" already exists
===============
Creating Secrets
Creating Secret:  example-app-tls
secrets "example-app-tls" already exists
===============
Creating StorageClasses
===============
Creating CronJob's
Creating CronJob:  hello
cronjobs.batch "hello" already exists
===============
Creating Job's
Creating Job's:  hello-1640030700
jobs.batch "hello-1640030700" already exists
Creating Job's:  hello-1640030760
jobs.batch "hello-1640030760" already exists
Creating Job's:  hello-1640030820
jobs.batch "hello-1640030820" already exists
Creating Job's:  hello-1640031000
jobs.batch "hello-1640031000" already exists
Creating Job's:  hello-1645046880
jobs.batch "hello-1645046880" already exists
Creating Job's:  hello-1645046940
jobs.batch "hello-1645046940" already exists
Creating Job's:  hello-1645047000
jobs.batch "hello-1645047000" already exists
Creating Job's:  hello-1645072740
jobs.batch "hello-1645072740" already exists
Creating Job's:  hello-1645072800
jobs.batch "hello-1645072800" already exists
Creating Job's:  hello-1645072860
jobs.batch "hello-1645072860" already exists
Creating Job's:  hello-1656688380
jobs.batch "hello-1656688380" already exists
Creating Job's:  hello-1656688440
jobs.batch "hello-1656688440" already exists
Creating Job's:  hello-1656688500
jobs.batch "hello-1656688500" already exists
Creating Job's:  pi
jobs.batch "pi" already exists
===============
Creating Cluster Roles
===============
Creating Cluster Role Bindings
===============
Creating HorizontalPodAutoscalers
===============
Creating Pod security policies
===============
Creating Service Account Job's
Creating Service Account:  default
serviceaccounts "default" already exists
=====================================================================
Operating on namespace:  infra
=====================================================================
===============
Creating Secrets
===============
Creating ConfigMap's
===============
Creating StorageClasses
===============
Creating PersistentVolumeClaims
===============
Creating Deployment
===============
Creating Service
===============
Creating Daemonset
===============
Creating Ingresses
===============
Creating Roles
===============
Creating Role Bindings
===============
Creating Secrets
===============
Creating StorageClasses
===============
Creating CronJob's
Creating CronJob:  hello
===============
Creating Job's
Creating Job's:  hello-1656688380
Creating Job's:  hello-1656688440
Creating Job's:  hello-1656688500
===============
Creating Cluster Roles
===============
Creating Cluster Role Bindings
===============
Creating HorizontalPodAutoscalers
===============
Creating Pod security policies
===============
Creating Service Account Job's
Creating Service Account:  default
serviceaccounts "default" already exists
=====================================================================
Operating on namespace:  shared
=====================================================================
===============
Creating Secrets
Creating Secret:  sharedaccesssecret
===============
Creating ConfigMap's
===============
Creating StorageClasses
===============
Creating PersistentVolumeClaims
===============
Creating Deployment
===============
Creating Service
===============
Creating Daemonset
===============
Creating Ingresses
===============
Creating Roles
===============
Creating Role Bindings
===============
Creating Secrets
Creating Secret:  sharedaccesssecret
secrets "sharedaccesssecret" already exists
===============
Creating StorageClasses
===============
Creating CronJob's
===============
Creating Job's
===============
Creating Cluster Roles
===============
Creating Cluster Role Bindings
===============
Creating HorizontalPodAutoscalers
===============
Creating Pod security policies
===============
Creating Service Account Job's
Creating Service Account:  default
serviceaccounts "default" already exists
 
        
Passo 4: Verificar o resultado no cluster do Amazon EKS
 
        
[kubernetes-migrations-factory]# kubectl get ns
NAME              STATUS   AGE
appdev            Active   14m
appprod           Active   14m
default           Active   472d
infra             Active   14m
kube-node-lease   Active   472d
kube-public       Active   472d
kube-system       Active   472d
shared            Active   14m
 
        
Executando como um comando de uma linha
 
        
A ferramenta KMF também aceita parâmetros como argumentos de linha de comando. Nesse caso, qualquer argumento da CLI tem precedência sobre qualquer definição em config.ini.
 
        
Migração de todos os recursos de todos os namespaces
 
        
Abaixo está um exemplo de como todos os recursos do Kubernetes suportados pelo KMF podem ser migrados de todos os namespaces.
 
        
$ ./bin/kmf --source_kubeconfig  /Users/<user-name>/.kube/gcp.config \
--destination_kubeconfig /Users/<user-name>/.kube/aws.config \
--namespaces "all" \
--resources "all" \
--migrate_images "yes" \
--reg_names "gcr, dockerhub, gitlab" \
--source_context <source_kubernetes_context> \  
--destination_context <destination_kubernetes_context> \
--helm_path <local-file-system-path> \
--action Deploy
 
        
Migração de implantações e serviços de vários namespaces
 
        
Abaixo está um exemplo de como migrar recursos selecionados do Kubernetes de namespaces específicos.
 
        
$ ./bin/kmf --source_kubeconfig  \
/Users/<user-name>/.kube/gcp.config --destination_kubeconfig \
/Users/<user-name>/.kube/aws.config \
--namespaces "dev,default" \
--resources "deployment,service" \
--migrate_images "yes" \
--reg_names "gcr, dockerhub, gitlab" \
--source_context <source_kubernetes_context>  \
--destination_context <destination_kubernetes_context> \
--helm_path <local-file-system-path> \
--action Deploy
 
        
 
 
        
Limpeza
 
        
Para limpar a instalação da ferramenta KMF, basta remover o diretório aws-kubernetes-migration-factory da estação de trabalho em que o repositório foi clonado. Se você quiser excluir os recursos migrados do Kubernetes no cluster de destino, basta escolher a ação como “Excluir” no arquivo de configuração do KMF. Isso excluirá somente os recursos migrados no cluster do Amazon EKS e não excluirá nenhum recurso no cluster do GKE.
 
        
 
        
Recursos relacionados
 
         
        
 
        
Conclusão
 
        
O Kubernetes Migration Factory (KMF) pode ser usado para migrar rapidamente suas cargas de trabalho do Kubernetes do GKE para um cluster do Amazon EKS. Nesta postagem do blog, fornecemos um exemplo de como o KMF pode ser usado a partir de um terminal como uma ferramenta de linha de comando (CLI). O código-fonte do KMF está disponível no repositório do GitHub e é de código aberto. Qualquer pessoa da comunidade interessada nesse assunto pode contribuir com ele ou entrar em contato conosco usando problemas do GitHub.
 
       
 
       
 
 
       
Este artigo foi traduzido do Blog da AWS em Inglês.
 
       
 
 
       
 
       
Sobre os autores
 
       
Vasanth Jeyaraj é arquiteto de infraestrutura de nuvem na Amazon Web Services (AWS). Ele apoia clientes corporativos na construção de uma infraestrutura seguindo boas práticas, com foco em automação, infraestrutura como código, e também se concentrou em ajudar os clientes a acelerar sua jornada de adoção de tecnologias nativas de nuvem, modernizando sua infraestrutura de plataforma e arquitetura interna usando a estratégia de microserviços, Containerização, DevOps. Fora do trabalho, ele adora passar tempo com a família e viajar.
 
       
 
 
       
 
 
       
 
 
       
 
 
       
Kirankumar Chandrashekar é arquiteto sênior de soluções para contas estratégicas na AWS. Ele se dedica a clientes chaves nas jornadas de arquitetura de DevOps e tecnologias de contêineres, para citar alguns. Kirankumar é apaixonado por DevOps, Infraestrutura como Código e por resolver problemas complexos de clientes. Ele gosta de música, além de cozinhar e viajar.
 
       
 
 
       
 
 
       
 
 
       
 
 
       
Mahendra Siddappa é consultor de DevOps na Amazon Web Services. Ele trabalha com clientes da AWS em ideias de contêineres, kubernetes e DevOps.
 
       
 
 
       
 
 
       
 
 
       
 
 
       
 
 
       
Tradutor
 
       
Davi Garcia está localizado no Brasil e é arquiteto de soluções da AWS especializado em modernização de infraestrutura e aplicações na nuvem, ajudando clientes de diversos segmentos na América Latina. Possui larga experiência em plataforma de containers, arquiteturas nativas de nuvem e automação. No seu tempo livre, ele gosta de contribuir com projetos open-source, se divertir em família com jogos de tabuleiros e viajar.
 
       
 
 
       
 
 
       
 
 
       
 
 
       
Revisor
 
       
Thiago Mantovani está localizado no Brasil e é arquiteto de soluções da AWS com especialização em migrações. Seu maior foco é ajudar os clientes de diversos segmentos na América da Latina em sua jornada para nuvem de forma resiliente e escalável. Fora do trabalho, ele adora se divertir com sua família é um grande fã e praticante de esportes.