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)
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.
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/
- 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.aws.amazon.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
- Creating an Amazon EKS Cluster
- Amazon EKS cluster authentication
- Create a kubeconfig for Amazon EKS
- Access Google Kubernetes Engine
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.