Personalizar o plano de migração para VMs do Linux

Revise e, se preferir, personalize o plano de migração antes de executá-lo. Os detalhes do plano de migração são usados para extrair os artefatos do contêiner da carga de trabalho da VM de origem e gerar arquivos de implantação do Kubernetes que você pode usar na implementação da imagem do contêiner em outros clusters, como os de produção.

Nesta página, você verá uma descrição do conteúdo do plano de migração e dos tipos de personalização disponíveis antes de executar a migração e gerar artefatos de implantação.

Antes de começar

Para seguir este tópico, é necessário criar um plano de migração e ter o respectivo arquivo.

Editar o plano de migração

Depois de copiar o sistema de arquivos e analisá-lo, encontre o plano de migração no novo diretório criado no caminho de saída especificado: ANALYSIS_OUTPUT_PATH/config.yaml.

Edite o plano de migração conforme necessário e salve as alterações.

Confira os detalhes e os comentários de orientação do plano de migração para adicionar informações que você acredita serem necessárias. Mais especificamente, considere editar as seções a seguir.

Especificar o conteúdo a ser excluído da migração

Por padrão, o Migrate to Containers exclui o conteúdo típico da VM que não é relevante no contexto do GKE. É possível personalizar esse filtro.

O valor do campo filters inclui uma lista dos caminhos que precisam ser excluídos da migração e não farão parte da imagem do contêiner. Use esse valor para listar as regras de filtragem de rsync que especificam os arquivos a serem transferidos e ignorados. Insira um sinal de menos no começo de cada caminho ou arquivo para especificar que o item na lista precisa ser excluído da migração. A lista é processada seguindo a ordem das linhas no YAML, e as exclusões/inclusões são avaliadas de acordo com isso.

Saiba mais sobre as regras de filtro do rsync.

Os arquivos que são muito grandes para inclusão na imagem Docker são listados no arquivo YAML. Esse procedimento sinaliza os arquivos com mais de 1 GB para você analisar. Imagens Docker muito grandes ou maiores do que 15 GB correm o risco de falhar durante a migração.

É possível editar a lista YAML para adicionar ou remover caminhos. Confira uma amostra de YAML abaixo, que inclui exemplos de exclusões e notificações de arquivos grandes e esparsos. Siga as orientações inline para realizar uma das seguintes ações:

Para excluir as pastas detectadas, remova a marca de comentário delas e coloque-as na seção de filtros globais.
Mova as pastas detectadas para um volume permanente removendo a marca de comentário delas e colocando-as na seção da pasta de dados.

Também é possível excluir ou mover os arquivos esparsos detectados da mesma maneira.

  global:
    # Files and directories to exclude from the migration, in rsync format.
    filters:
      - "- *.swp"
      - "- /etc/fstab"
      - "- /boot/"
      - "- /tmp/*"
      - "- /var/log/*.log*"
      - "- /var/log/*/*.log*"
      - "- /var/cache/*"

    ## The data folders below are too large to be included in the docker image.
    ## Consider uncommenting and placing them under either the global filters
    ## or the data folder section.
      # - '- /a' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/c' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

    ## Sparse files will fail the run of a docker image. Consider excluding the below
    ## detected files and any other sparse files by uncommenting and placing them in 
    ## the global filters section, or export them to a persistent volume by specifying
    ## them in the data folder section.
      # - '- /a/b' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/d' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

Definir o nome da imagem do contêiner

O valor do campo name na seção image define o nome da imagem que foi criada de uma VM migrada, usada para o contêiner. É possível alterar esse valor se preferir usar outro nome.

image:
     # Review and set the name for runnable container image.
     name: linux-system

Personalizar a lista de serviços

Por padrão, o Migrate to Containers desativa os serviços desnecessários em uma VM quando ela é migrada para um contêiner. Esses serviços às vezes podem causar problemas no contêiner migrado ou não são necessários no contexto do contêiner.

É possível desativar outros serviços além daqueles que o Migrate to Containers desativa automaticamente:

O Migrate to Containers descobre automaticamente serviços que você pode desativar e os lista no plano de migração. Esses serviços, como ssh ou um servidor da web, podem não ser necessários na carga de trabalho migrada, mas cabe a você tomar essa decisão. Se necessário, edite o plano de migração para desativar esses serviços.
O Migrate to Containers não lista todos os serviços em execução na VM de origem. Por exemplo, ele omite os serviços relacionados ao sistema operacional. Também é possível editar o plano de migração para adicionar sua própria lista de serviços a serem desativados no contêiner migrado.

O campo systemServices especifica a lista de serviços descobertos pelo Migrate to Containers. Por exemplo:

    systemServices:
    - enabled: true|false
      name: service-name
      probed: true|false
    - enabled: true|false
      name: service-name
      probed: true|false
      ...

Para desativar um serviço, defina enabled como false.

O Migrate to Containers não lista todos os serviços em execução na VM de origem, como aqueles relacionados ao sistema operacional. Também é possível adicionar outros serviços à lista. Por exemplo, para desativar service2 e o serviço cron:

    systemServices:
    - enabled: true
      name: service1
      probed: false
    - enabled: false
      name: service2
      probed: false
    - enabled: false
      name: cron
      probed: false

Quando você executa uma migração para gerar os artefatos de migração, o Migrate to Containers cria o arquivo blocklist.yaml. Esse arquivo lista os serviços de contêiner que serão desativados com base nas configurações no plano de migração. Por exemplo:

service_list:
- name: disabled-services
  services:
  # Because you used systemServices above to disabled service2 and cron:
  - service2
  - cron

Se você quiser modificar a lista de serviços desativados em outro momento:

Edite-a no plano de migração.
Execute a migração para gerar os artefatos novamente, incluindo um blocklist.yaml atualizado.

Outra opção é editar o arquivo blocklist.yaml diretamente, depois de executar a migração para gerar os devidos artefatos, e criar e implantar a imagem do contêiner usando o Skaffold.

Personalizar endpoints de serviço

O plano de migração inclui a matriz endpoints que define as portas e os protocolos usados para criar os serviços do Kubernetes fornecidos pela carga de trabalho migrada. É possível adicionar, editar ou excluir definições de endpoint para personalizar o plano de migração.

Para recuperar as portas dos endpoints, verifique os programas que as detectam:

sudo netstat --programs --listening --tcp --udp [--sctp]

Para cada endpoint de Serviço, adicione a seguinte definição ao plano de migração:

    endpoints:
    - port: PORT_NUMBER
      protocol: PORT_PROTOCOL
      name: PORT_NAME

Em que:

PORT_NUMBER especifica o número da porta do contêiner para roteamento das solicitações enviadas ao serviço;
PORT_PROTOCOL especifica o protocolo da porta, como HTTP, HTTPS ou TCP. Consulte Protocolos compatíveis para ver a lista completa;
PORT_NAME especifica o nome usado para acessar o endpoint de Serviço. O Migrate to Containers gera uma PORT_NAME exclusiva para cada definição de endpoint gerada.

Por exemplo, o Migrate to Containers detecta os seguintes endpoints:

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 6379
      protocol: TCP
      name: backend-server-redis

Para definir o valor da propriedade name, o Migrate to Containers combina o nome da VM de origem, backend-server neste exemplo, com o nome do programa do Serviço. Os nomes gerados são compatíveis com as convenções de nomenclatura do Kubernetes e exclusivos no plano de migração. Por exemplo, o plano de migração acima cria um Serviço que direciona o Nginx à porta 80 por HTTP.

Para nomes duplicados, o Migrate to Containers adiciona um sufixo de contador ao final. Por exemplo, se o Nginx está associado a duas portas, ele adiciona o sufixo -2 ao name na segunda definição:

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 8080
      protocol: HTTPS
      name: backend-server-nginx-2
    - port: 6379
      protocol: TCP
      name: backend-server-redis

Quando você executa uma migração para gerar os devidos artefatos, o Migrate to Containers cria uma definição Serviço no arquivo deployment_spec.yaml para cada endpoint.

Por exemplo, confira a seguir a definição Service no arquivo deployment_spec.yaml:

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  name: backend-server-nginx
spec:
  ports:
  - port: 80
    protocol: HTTP
    targetPort: 80
  selector:
    app: backend-server
status:
  loadBalancer: {}

Personalizar montagens do NFS

O Migrate to Containers inclui montagens do NFS no plano de migração gerado. Essas informações são coletadas do arquivo fstab e gravadas na matriz nfsMounts no plano de migração. É possível adicionar ou editar definições de ponto de montagem do NFS para personalizar o plano de migração.

O Migrate to Containers faz o seguinte ao gerar o plano de migração:

Ignora as montagens do NFS para /sys e /dev.
Ignora as montagens do NFS com um tipo diferente de nfs ou nfs4.

Cada montagem do NFS no plano de migração inclui o endereço IP do servidor e o caminho de montagem local no formato:

    nfsMounts:
    - mountPoint: MOUNT_POINT
      exportedDirectory: DIR_NAME
      nfsServer: IP
      mountOptions:
         - OPTION_1
         - OPTION_2
      enabled: false|true

Em que:

MOUNT_POINT especifica o ponto de montagem obtido de fstab;
DIR_NAME especifica o nome do diretório compartilhado;
IP especifica o endereço IP do servidor que hospeda o ponto de montagem;
OPTION_N especifica qualquer opção extraída do fstab para o ponto de montagem.

Por exemplo, no caso da seguinte entrada em fstab:

<file system>       <mount point>   <type>  <options>   <dump>  <pass>
10.49.232.26:/vol1  /mnt/test       nfs     rw,hard     0       0

O Migrate to Containers gera esta entrada no plano de migração:

    nfsMounts:
    - mountPoint: /mnt/test
      exportedDirectory: /vol1
      nfsServer: 10.49.232.26
      mountOptions:
         - rw
         - hard
      enabled: false

Para configurar o Migrate to Containers de modo a processar entradas na matriz nfsMounts, defina enabled como true na entrada mountPoint. É possível ativar uma, algumas ou todas as entradas mountPoints e editar ou adicionar as próprias entradas.

Quando você executa uma migração para gerar os devidos artefatos, o Migrate to Containers cria uma definição volumes e volumeMounts e PersistentVolume e PersistentVolumeClaim no arquivo deployment_spec.yaml para cada montagem do NFS ativada.

Por exemplo, confira a seguir a definição volumeMounts no arquivo deployment_spec.yaml:

    spec:
      containers:
          - image: gcr.io/myimage-1/image-name
            name: some-app
            volumeMounts:
                   - mountPath: /sys/fs/cgroup
                     name: cgroups
                   - mountPath: /mnt/test
                     name: nfs-pv

Em que o valor de name é um identificador exclusivo gerado pelo Migrate to Containers.

Confira abaixo um exemplo de definições de PersistentVolumeClaim e PersistentVolume no arquivo deployment_spec.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Mi
  storageClassName: ""
  volumeName: nfs-pv

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  mountOptions:
    - rw
    - hard
  nfs:
    path: /vol1
    server: 10.49.232.26

Personalizar dados de registro gravados no Cloud Logging

Uma VM de origem costuma gravar informações em um ou mais arquivos de registro. Como parte da migração da VM, é possível configurar a carga de trabalho migrada para gravar as informações de registro no Cloud Logging.

Quando você gera o plano de migração, o Migrate to Containers pesquisa automaticamente os arquivos de destino do registro na VM de origem. Depois disso, o Migrate to Containers grava informações sobre os arquivos detectados na área logPaths do plano de migração:

deployment:
    ...
    logPaths:
    - appName: APP_NAME
      globs:
      - LOG_PATH

Por exemplo:

deployment:
    ...
    logPaths:
    - appName: tomcat
      globs:
      - /var/log/tomcat*/catalina.out

Quando você gera os artefatos de migração, o Migrate to Containers cria o arquivo logs.yaml do plano de migração. Nele consta uma lista de arquivos de registro detectados na VM de origem. Por exemplo, na definição logsPath acima, logs.yaml contém:

logs:
  tomcat:
  - /var/log/tomcat*/catalina.out

Neste exemplo, quando você implanta a carga de trabalho migrada, as informações de registro gravadas em catalina.out são automaticamente salvas no Cloud Logging.

Cada entrada aparece em uma linha no registro, no seguinte formato:

DATE TIME APP_NAME LOG_OUTPUT

O exemplo a seguir ilustra o formulário com uma entrada do Tomcat:

2019-09-22 12:43:08.681193976 +0000 UTC tomcat log-output

Para configurar a geração de registros, as opções são:

Editar o plano de migração antes de gerar os devidos artefatos para adicionar, remover ou alterar as entradas logPaths. Quando você gera os artefatos de migração, as edições são refletidas no arquivo logs.yaml.
Editar logs.yaml depois de gerar os artefatos de migração para adicionar, remover ou alterar as entradas logs.

A vantagem de editar o plano de migração é que as edições serão refletidas em logs.yaml sempre que você gerar os artefatos. Se você editar logs.yaml diretamente e gerar os artefatos novamente por algum motivo, será necessário reaplicar as edições ao logs.yaml.

Definir sondagens de integridade do v2kServiceManager do Linux

É possível monitorar a inatividade e o status de prontidão dos contêineres gerenciados especificando as sondagens no plano de migração do servidor da web do Tomcat. O monitoramento da sondagem de integridade pode reduzir a inatividade dos contêineres migrados e aprimorar o controle.

Os estados de integridade desconhecidos podem levar a degradação de disponibilidade, monitoramento de disponibilidade com falsos positivos e possível perda de dados. Sem uma sondagem de integridade, o kubelet apenas deduz a integridade de um contêiner e pode enviar o tráfego a uma instância de contêiner que não está pronta. Isso pode causar perda de tráfego. O kubelet também pode não detectar quando há contêineres em estado travado e deixar de reiniciá-los.

Para realizar uma sondagem de integridade, é preciso executar uma pequena instrução de script quando o contêiner é iniciado. O script verifica em cada período se há condições de sucesso, ou seja, aquelas definidas pelo tipo de sondagem usada. O período é definido no plano de migração por um campo periodSeconds. É possível executar ou definir esses scripts manualmente.

Para saber mais sobre as sondagens do kubelet, consulte Configurar sondagens de atividade, prontidão e inicialização na documentação do Kubernetes.

Há dois tipos de sondagens disponíveis para configuração, que são probe-v1-core definidas na referência de probe-v1-core e compartilham a mesma função que os campos correspondentes de container-v1-core.

Sondagem de atividade: usada para saber quando reiniciar um contêiner.

Observação: se um processo no contêiner pode emitir uma falha sozinho quando encontra um problema, ou passa a ser não íntegro, você não precisa de uma sondagem de atividade. O kubelet executará automaticamente a ação correta de acordo com o restartPolicy do pod.

Sondagem de prontidão: usada para saber quando um contêiner está pronto para começar a aceitar tráfego. Especifique uma sondagem de prontidão para começar a enviar tráfego a um pod somente quando a sondagem for bem-sucedida. A sondagem de prontidão pode atuar de maneira semelhante a uma de atividade, mas a sondagem de prontidão nas especificações indica que um pod começa sem receber tráfego e só o recebe depois que a sondagem é concluída.

Após a descoberta, a configuração da sondagem é adicionada ao plano de migração. As sondagens podem ser usadas com a configuração padrão, conforme mostrado a seguir. Para desativar as sondagens, remova a seção probes do yaml.

deployment:
  probes:
    livenessProbe:
      exec:
        command:
        - /ko-app/service-manager-runtime
        - /probe

    readinessProbe:
      exec:
        command:
        - gamma
        - /probe
      initialDelaySeconds: 60
      periodSeconds: 5

image:
  # Disable system services that do not need to be executed at the migrated workload containers.
  # Enable the 'probed' property to include system services in the container health checks.
  systemServices:
  - enabled: true
    name: apache2
    probed: true
  - enabled: true
    name: atd
    probed: false

Por padrão, todas as sondagens de serviço estão desativadas. Defina o subconjunto de serviços que será monitorado.

Há quatro maneiras predefinidas de verificar um contêiner por sondagem. Cada sondagem precisa definir exatamente um destes quatro mecanismos:

exec: executa um comando especificado no contêiner. A execução é considerada bem-sucedida quando o código de status de saída é 0.
grpc: executa uma chamada de procedimento remoto com gRPC. As sondagens gRPC são um recurso Alfa.
httpGet: faz uma solicitação GET HTTP para o endereço IP do pod em uma porta e um caminho especificados. A solicitação é considerada bem-sucedida quando o código de status é maior ou igual a 200 e menor que 400.
tcpSocket: executa uma verificação TCP no endereço IP do pod em uma porta especificada. O diagnóstico é considerado bem-sucedido quando a porta está aberta.

Por padrão, um plano de migração ativa o método de sondagem exec. Use a configuração manual no plano de migração para ativar outro método.

Para adicionar dependências externas à sondagem de prontidão e usar a sondagem de atividade padrão, defina uma sondagem de prontidão de execução e um script que implemente a lógica.

A seguir

Saiba como executar a migração.