Movendo um app baseado em VM para o Kubernetes
Este tutorial pode incorrer em custos. Use o Estimador de custos para gerar uma estimativa do custo baseada em seu uso projetado.
Este tutorial guia você no processo de mover um aplicativo com base em VM para um cluster de Kubernetes usando o Kubernetes Service. O Kubernetes Service fornece ferramentas poderosas que combinam as tecnologias de contêiner e Kubernetes, uma experiência de usuário intuitiva e segurança e isolamento integrados para automatizar a implementação, operação, escalonamento e monitoramento de aplicativos conteinerizados em um cluster de hosts de computação.
As lições neste tutorial incluem conceitos de como pega um app existente, conteinerizar o app e implementar o app em um cluster Kubernetes. Para conteinerizar seu app baseado em VM, é possível escolher entre as opções a seguir.
- Identificar os componentes de um aplicativo monolítico que podem ser separados em seu próprio microsserviço. Você pode colocar esses microsserviços em contêineres e implantá-los em um cluster Kubernetes.
- Conteinerize o app inteiro e implemente o app em um cluster Kubernetes.
Dependendo do tipo de app que você tem, as etapas para migrar seu app podem variar. É possível usar esse tutorial para aprender sobre as etapas gerais que você tem que tomar e as coisas que devem ser consideradas antes de migrar seu app.
Objetivos
- Entenda como identificar microsserviços em um aplicativo baseado em VM e saiba como mapear componentes entre VMs e Kubernetes.
- Aprender como conteinerizar um app baseado em VM.
- Aprender como implementar o contêiner em um cluster Kubernetes no Kubernetes Service.
- Colocar tudo o que foi aprendido em prática, executar o app JPetStore em seu cluster.
Arquitetura
Arquitetura de app tradicional com VMs
O diagrama a seguir mostra um exemplo de uma arquitetura de app tradicional que é baseada em máquinas virtuais.

- O usuário envia uma solicitação para o terminal público do aplicativo. O terminal público é representado por um serviço de balanceador de carga que balanceia o tráfego de rede recebido entre as instâncias do servidor de aplicativos disponíveis.
- O balanceador de carga seleciona uma das instâncias do servidor de aplicativos funcional que são executadas em uma VM e encaminha a solicitação. Os arquivos do aplicativo, como o código do aplicativo, os arquivos de configuração e as dependências, são armazenados na VM do servidor de aplicativos.
- O servidor de aplicativos armazena os dados do aplicativo em um banco de dados MySQL que é executado em uma VM de banco de dados.
Arquitetura conteinerizada
O diagrama a seguir mostra um exemplo de uma arquitetura de contêiner moderno que é executada em um cluster Kubernetes.

- O usuário envia uma solicitação para o terminal público do aplicativo. O terminal público é representado por um balanceador de carga do aplicativo (ALB) do Ingresso que balanceia o tráfego de rede recebido entre os pods de app no cluster. O ALB é uma coleção de regras que permitem o tráfego de rede de entrada para um app exposto publicamente.
- O ALB encaminha a solicitação para um dos pods de app disponíveis no cluster. Os pods de app são executados nos nós do trabalhador que podem ser uma máquina virtual ou física.
- Os pods de app armazenam dados em volumes persistentes. Os volumes persistentes podem ser usados para compartilhar dados entre instâncias do app ou nós do trabalhador.
- Os pods de app armazenam dados em um serviço de banco de dados do IBM Cloud. É possível executar seu próprio banco de dados dentro do cluster Kubernetes, mas usar um banco de dados como um serviço (DBaaS) gerenciado é geralmente mais fácil de configurar e fornece backups e ajuste de escala integrados. É possível localizar muitos tipos de bancos de dados no catálogo do IBM Cloud.
VMs, contêineres e Kubernetes
O Kubernetes Service fornece a capacidade de executar apps conteinerizados em clusters Kubernetes e entrega as ferramentas e funções a seguir:
- Experiência de usuário intuitiva e ferramentas avançadas.
- Segurança e isolamento integrados para permitir o fornecimento rápido de aplicativos seguros.
- Serviços em nuvem que incluem recursos cognitivos do IBM® Watson™.
- Capacidade de gerenciar recursos de cluster dedicados para aplicativos sem estado e cargas de trabalho com estado.
Máquinas virtuais vs contêineres
VMs, os apps tradicionais são executados no hardware nativo. Um único app geralmente não usa os recursos integrais de um único host de cálculo. A maioria das organizações tenta executar múltiplos apps em um único host de cálculo para evitar desperdício de recursos. É possível executar múltiplas cópias do mesmo app, mas para fornecer isolamento, é possível usar VMs para executar múltiplas instâncias de app (VMs) no mesmo hardware. Essas VMs têm pilhas completas de sistemas operacionais que as tornam relativamente ineficientes devido à duplicação no tempo de execução e no disco.
Os contêineres são uma maneira padrão de empacotar apps e todas as suas dependências para que seja possível mover facilmente os apps entre ambientes. Ao contrário de máquinas virtuais, os contêineres não empacotam o sistema operacional. Somente o código de app, o tempo de execução, as ferramentas de sistema, as bibliotecas e as configurações são empacotados dentro de contêineres. Os contêineres são mais leves, móveis e eficientes do que máquinas virtuais.
Além disso, os contêineres permitem que você compartilhe o S.O. do host. Isso reduz a duplicação enquanto ainda fornece o isolamento. Os contêineres também permitem a você eliminar arquivos desnecessários, como bibliotecas do sistema e binários, para economizar espaço e reduzir sua superfície de ataque. Leia mais sobre máquinas virtuais e contêineres em O que são contêineres??
Orquestração do Kubernetes
Kubernetes é um orquestrador de contêineres para gerenciar o ciclo de vida de aplicativos em contêineres em um cluster de nós de trabalho. Seus apps podem precisar de muitos outros recursos para execução, como volumes, redes e segredos, que ajudarão a se conectar a outros serviços de nuvem e chaves seguras. O Kubernetes ajuda você a incluir esses recursos em seu app. O paradigma chave do Kubernetes é seu modelo declarativo. O usuário fornece o estado desejado e as tentativas do Kubernetes de se adequar e, em seguida, mantém o estado descrito.
Este workshop individualizado sobre Kubernetes pode ajudá-lo a obter sua primeira experiência prática com o Kubernetes. Além disso, confira a página de documentação de conceitos do Kubernetes para saber mais sobre os conceitos do Kubernetes.
O que a IBM está fazendo para você
Usando clusters Kubernetes com o IBM Cloud Kubernetes Service, você obtém os benefícios a seguir:
- Múltiplos data centers nos quais é possível implementar seus clusters.
- Suporte para opções de rede de ingresso e de balanceador de carga.
- Suporte de volume persistente dinâmico.
- Os principais do Kubernetes altamente disponíveis e gerenciados pela IBM.
Dimensionando clusters
À medida que projeta sua arquitetura de cluster, você deseja balancear os custos com relação à disponibilidade, confiabilidade, complexidade e recuperação. Os clusters Kubernetes no IBM Cloud Kubernetes Service fornecem opções arquiteturais com base nas necessidades de seus apps. Com um pouco de planejamento, é possível obter o máximo de seus recursos em nuvem sem arquitetura excessiva ou gasto excessivo. Mesmo que você superestime ou subestime, é possível aumentar ou diminuir facilmente o cluster, alterando o número ou o tipo de nós de trabalho.
Para executar um app de produção na nuvem usando o Kubernetes, considere os itens a seguir:
- Você espera tráfego de um local geográfico específico? Se sim, selecione o local que está fisicamente mais próximo de você para obter melhor desempenho.
- Quantas réplicas de seu cluster você deseja para maior disponibilidade? Um bom ponto de início pode ser três clusters, um para o desenvolvimento, um para teste e um para produção. Confira o guia de solução Melhores práticas para organizar recursos e designar acesso para criar diversos ambientes.
- Qual hardware você precisa para os nós do trabalhador? Máquinas virtuais ou bare metal?
- Quantos nós do trabalhador você precisa? Isso depende altamente da escala dos apps, quanto mais nós você tiver mais resiliente seu aplicativo será.
- Quantas réplicas é necessário ter para maior disponibilidade? Implemente os clusters de réplicas em múltiplos locais para tornar seu app mais disponível e proteger o app de ficar inativo devido a uma falha de local.
- Qual é o conjunto mínimo de recursos que seu aplicativo precisa para iniciar? Você pode desejar testar seu app para a quantia de memória e CPU que ele requer para execução. Em seguida, seu nó do trabalhador deve ter recursos suficientes para implementar e iniciar o app. Certifique-se de configurar as cotas de recurso como parte das especificações de pod. Essa configuração é o que o Kubernetes usa para selecionar (ou planejar) um nó do trabalhador que tem capacidade suficiente para suportar a solicitação. Estime quantos pods serão executados no nó do trabalhador e os requisitos de recurso para esses pods.
- Quando aumentar o número de nós de trabalho? É possível monitorar o uso do cluster e aumentar os nós quando necessário. Consulte Monitoramento da integridade do cluster.
- Você precisa de armazenamento redundante e confiável? Se sim, crie uma reivindicação de volume persistente para o armazenamento NFS ou associe um serviço de banco de dados IBM Cloud ao seu pod.
- Você precisa implementar um cluster na Infraestrutura da Virtual Private Cloud ou na Infraestrutura clássica? A VPC fornece a segurança de um ambiente de nuvem particular com a escalabilidade dinâmica de uma nuvem pública.
Para tornar as etapas anteriores mais específicas, vamos supor que você queira executar um aplicativo Web de produção na nuvem e espere uma carga de tráfego moderada a alta. Vamos explorar quais recursos seriam necessários:
- Configure três clusters, um para desenvolvimento, um para teste e outro para produção.
- Os clusters de desenvolvimento e teste podem começar com uma opção mínima de RAM e CPU (por exemplo, 2 CPUs, 4GB de RAM e um nó de trabalho para cada cluster).
- Para o cluster de produção, você pode desejar ter mais recursos para desempenho, alta disponibilidade e resiliência. Podemos escolher uma opção dedicada ou até mesmo bare metal e ter pelo menos 4 CPUs, 16GB de RAM e dois nós de trabalho.
Decidir qual opção do Banco de Dados usar
Com o Kubernetes, você tem duas opções para manipular bancos de dados:
- É possível executar seu banco de dados dentro do cluster Kubernetes, para fazer isso, você precisaria criar um microsserviço para executar o banco de dados. Por exemplo, se você estiver usando um banco de dados MySQL, será necessário concluir
as etapas a seguir:
- Crie um Dockerfile MySQL ; veja um exemplo de Dockerfile MySQL aqui.
- Você precisaria usar segredos para armazenar a credencial do banco de dados. Veja o exemplo deste aqui
- Você precisaria de um arquivo
deployment.yaml
com a configuração de seu banco de dados para implementado no Kubernetes. Veja o exemplo deste aqui
- A segunda opção seria usar a opção de banco de dados como um serviço (DBaaS) gerenciado. Essa opção é geralmente mais fácil de configurar e fornece backups e ajuste de escala integrados. É possível localizar muitos tipos de bancos de dados
no catálogo do IBM Cloud. Para usar essa opção, seria necessário fazer o seguinte:
- Crie um banco de dados como um serviço (DBaaS) gerenciado do catálogo do IBM Cloud.
- Armazene credenciais do banco de dados dentro de um segredo. Você saberá mais sobre segredos na seção Armazenar credenciais nos segredos Kubernetes.
- Use o banco de dados como um serviço (DBaaS) em seu aplicativo.
Decidir onde armazenar os arquivos de aplicativo
O Kubernetes Service fornece várias opções para armazenar e compartilhar dados entre os pods. Nem todas as opções de armazenamento oferecem o mesmo nível de persistência e disponibilidade em situações de desastre.
Armazenamento de dados não persistentes
Os contêineres e os pods são, pelo design, de curta duração e podem falhar inesperadamente. É possível armazenar dados no sistema de arquivos local de um contêiner. Os dados dentro de um contêiner não podem ser compartilhados com outros contêineres ou pods e são perdidos quando o contêiner trava ou é removido.
Aprender como criar armazenamento de dados persistentes para seu app
Você pode manter os dados do aplicativo e os dados do contêiner no armazenamento de arquivos NFS ou no armazenamento em bloco usando volumes persistentes nativos Kubernetes.
Para provisionar armazenamento de arquivo NFS ou armazenamento de bloco, deve-se solicitar armazenamento para seu pod criando uma solicitação de volume persistente (PVC). Em seu PVC, você pode escolher entre classes de armazenamento predefinidas que definem o tipo de armazenamento, a capacidade de armazenamento em gigabytes, IOPS, a política de retenção de dados e as permissões de leitura e gravação do armazenamento. Um PVC provisiona dinamicamente um volume persistente (PV) que representa um dispositivo de armazenamento real no IBM Cloud. É possível montar o PVC em seu pod para ler e gravar no PV. Os dados que são armazenados em PVs estão disponíveis, mesmo se o contêiner trava ou o pod é reagendado. O armazenamento de arquivos NFS e o armazenamento em bloco que faz o backup do PV são agrupados em cluster pela IBM para fornecer alta disponibilidade para seus dados.
Para aprender como criar um PVC, siga as etapas abrangidas na documentação de armazenamento do Kubernetes Service.
Aprender como mover os dados existentes para o armazenamento persistente
Para copiar dados de sua máquina local para seu armazenamento persistente, deve-se montar o PVC em um pod. Em seguida, é possível copiar dados de sua máquina local para o volume persistente em seu pod.
-
Para copiar dados, primeiro, você precisaria criar uma configuração que se pareça com algo deste tipo:
kind: Pod apiVersion: v1 metadata: name: task-pv-pod spec: volumes: - name: task-pv-storage persistentVolumeClaim: claimName: mypvc containers: - name: task-pv-container image: nginx ports: - containerPort: 80 name: "http-server" volumeMounts: - mountPath: "/mnt/data" name: task-pv-storage
-
Em seguida, para copiar dados de sua máquina local para o pod, você usaria um comando como este:
kubectl cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath>
-
Copie dados de um pod em seu cluster para sua máquina local:
kubectl cp <namespace>/<pod>:<pod_filepath>/<filename> <local_filepath>/<filename>
Configurar backups para armazenamento persistente
Os compartilhamentos de arquivo e armazenamento de bloco são provisionados no mesmo local de seu cluster. O armazenamento em si é hospedado em servidores em cluster pela IBM para fornecer alta disponibilidade. No entanto, os compartilhamentos de arquivo e o armazenamento de bloco não são submetidos a backup automaticamente e poderão ficar inacessíveis se o local inteiro falhar. Para proteger seus dados contra dano ou perda, é possível configurar backups periódicos, que podem ser usados para restaurar seus dados quando necessário.
Para obter mais informações, consulte Planejamento para armazenamento options for NFS file storage and block storage.
Preparar seu código
Aplicar os princípios de 12 fatores
O aplicativo de doze fatores é uma metodologia para criar aplicativos nativos da nuvem. Quando você desejar conteinerizar um app, mova esse app para a nuvem e orquestre o app com o Kubernetes, é importante entender e aplicar alguns desses princípios. Alguns desses princípios são necessários no IBM Cloud.
Os princípios chave a seguir são necessários:
- Código base - todos os arquivos de código-fonte e de configuração são rastreados dentro de um sistema de controle de versão (por exemplo, um repositório GIT), isso é necessário se você está usando o pipeline do DevOps para implementação.
- Construir, liberar, executar - o app de 12 fatores usa separação estrita entre os estágios de construção, liberação e execução. Isso pode ser automatizado com um pipeline de entrega do DevOps integrado para construir e testar o app antes de implementá-lo no cluster. Confira o tutorial Implementar um app no Kubernetes para saber como configurar um pipeline de integração e entrega contínuas. Ele abrange a configuração dos estágios de controle de origem, compilação, teste e implantação e mostra como adicionar integrações, como scanners de segurança, notificações e análises.
- Configuração - todas as informações de configuração são armazenadas em variáveis de ambiente. Nenhuma credencial de serviço é codificada permanentemente dentro do código do app. Para armazenar credenciais, é possível usar segredos do Kubernetes. Mais sobre credenciais mais tarde.
Armazenar credenciais em segredos do Kubernetes
Nunca é uma boa prática armazenar credenciais dentro do código do app. Em vez disso, Kubernetes fornece os chamados "segredos" que contêm informações confidenciais, como senhas, tokens OAuth ou chaves SSH. Os segredos do Kubernetes são criptografados por padrão, o que torna os segredos uma opção mais segura e flexível para armazenar dados sensíveis do que armazenar
esses dados literalmente em uma definição de pod
ou em uma imagem de contêiner.
Uma maneira de usar segredos no Kubernetes é fazendo algo como este:
-
Crie um arquivo chamado
cloud-secrets.txt
e armazene as credenciais de serviço de qualquer serviço de nuvem dentro dele.{ "url": "<SERVICE_URL>", "api_key": <API_Key> }
-
Em seguida, crie um segredo Kubernetes executando o seguinte comando e verifique se o segredo foi criado usando
kubectl get secrets
depois de executar o seguinte comando:kubectl create secret generic cloud-service-secret --from-file=cloud-secrets.txt=./cloud-secrets.txt
Conteinerizar seu app
Para conteinerizar o app, deve-se criar uma imagem de contêiner.
Uma imagem é criada a partir de um Dockerfile, que é um arquivo que contém instruções e comandos para construir a imagem. Um Dockerfile pode referenciar os artefatos de construção em suas instruções que são armazenadas separadamente, como um app, a configuração do app e suas dependências.
Para construir seu próprio Dockerfile para o app existente, é possível usar os comandos a seguir:
- FROM - escolha uma imagem pai para definir o tempo de execução do contêiner.
- ADD/COPY - copie o conteúdo de um diretório para o contêiner.
- WORKDIR - configure o diretório ativo dentro do contêiner.
- RUN - instalar pacotes de software que os apps precisam durante o tempo de execução.
- EXPOSE - disponibilize uma porta fora do contêiner.
- ENV NAME - defina variáveis de ambiente.
- CMD - defina comandos que são executados quando o contêiner é ativado.
Normalmente, as imagens são armazenadas em um registro que pode ser acessível ao público (registro público) ou configurado com acesso limitado a um grupo de usuários (registro privado). Os registros públicos, como Docker Hub, podem ser usados na introdução ao Docker e Kubernetes para criar seu primeiro app conteinerizado em um cluster. Mas quando se trata de apps corporativos, use um registro privado, como aquele fornecido no IBM Cloud Container Registry para proteger suas imagens de serem usadas e mudadas por usuários não autorizados.
Para conteinerizar um app e armazená-lo no IBM Cloud Container Registry:
- Você precisaria criar um Dockerfile, o código a seguir é um exemplo de um Dockerfile.
# Build JPetStore war FROM openjdk:8 as builder COPY . /src WORKDIR /src RUN ./build.sh all # Use WebSphere Liberty base image from the Docker Store FROM websphere-liberty:latest # Copy war from build stage and server.xml into image COPY --from=builder /src/dist/jpetstore.war /opt/ibm/wlp/usr/servers/defaultServer/apps/ COPY --from=builder /src/server.xml /opt/ibm/wlp/usr/servers/defaultServer/ RUN mkdir -p /config/lib/global COPY lib/mysql-connector-java-3.0.17-ga-bin.jar /config/lib/global
- Após a criação de um Dockerfile, em seguida, seria necessário construir a imagem de contêiner e enviá-la por push para o IBM Cloud Container Registry. É possível construir um contêiner usando um comando como:
docker build . -t <image_name> docker push <image_name>
Implementar seu app em um cluster Kubernetes
Depois que uma imagem de contêiner é construída e enviada por push para a nuvem, em seguida, é necessário implementar em seu cluster Kubernetes. Para fazer isso, seria necessário criar um arquivo deployment.yaml.
Aprender como criar um arquivo yaml de implementação do Kubernetes
Para criar arquivos deployment.yaml do Kubernetes, seria necessário fazer algo como isto:
-
Crie um arquivo deployment.yaml. Aqui está um exemplo de um arquivo YAML de implantação.
-
No arquivo deployment.yaml, é possível definir cotas de recursos para os contêineres para especificar a quantidade de CPU e memória que cada contêiner precisa para iniciar corretamente. Se os contêineres tiverem cotas de recurso especificadas, o planejador do Kubernetes poderá tomar melhores decisões sobre o nó do trabalhador no qual colocar seus pods.
-
Em seguida, você pode usar os seguintes comandos para criar e visualizar a implantação e os serviços criados:
kubectl create -f <filepath/deployment.yaml> kubectl get deployments kubectl get services kubectl get pods
Resumo
Neste tutorial, você aprendeu o seguinte:
- As diferenças entre VMs, contêineres e Kubernetes.
- Como definir clusters para diferentes tipos de ambiente (desenvolvimento, teste e produção).
- Como manipular o armazenamento de dados e a importância do armazenamento de dados persistentes.
- Aplique os princípios de 12 fatores a seu app e use segredos para credenciais no Kubernetes.
- Construa imagens de contêiner e envie-as por push para IBM Cloud Container Registry.
- Crie arquivos de implementação do Kubernetes e implemente a imagem de contêiner no Kubernetes.
Colocar tudo o que foi aprendido em prática, executar o app JPetStore em seu cluster.
Para colocar tudo o que você aprendeu em prática, siga a demonstração para executar o aplicativo JPetStore em seu cluster e aplique os conceitos aprendidos. O app JPetStore tem alguma funcionalidade estendida para permitir que você amplie um app no Kubernetes executando a classificação de imagem como um microsserviço separado.