Personalizar plano de migração de VMs do Linux

Antes de executar um plano de migração, confira e, opcionalmente, personalize-o. Os detalhes do plano de migração serão usados para extrair os artefatos do contêiner da carga de trabalho da VM de origem. Além disso, serão gerados arquivos de implantação do Kubernetes para implementar a imagem do contêiner em outros clusters, como os de produção.

Nesta seção, 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 uma migração e ter o arquivo do plano de migração resultante.

Editar o plano de migração

Depois de copiar o sistema de arquivos e analisá-lo, encontre o plano de modernizaçã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.

Revise os detalhes do plano de migração e os comentários de orientação para adicionar informações conforme necessário. Mais especificamente, considere editar as seguintes seções:

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.

Com o valor do campo filters, você lista os 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 quais arquivos transferir e quais ignorar. 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 serem incluídos na imagem do Docker são listados no arquivo YAML. Isso sinalizará arquivos com mais de 1 GB para você considerar. Imagens do 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 um exemplo de YAML abaixo, que inclui exclusões de exemplo, bem como notificações de arquivos grandes e esparsos. Siga as orientações in-line para realizar uma das seguintes ações:

• Para excluir as pastas detectadas, remova a marca de comentário e coloque-as na seção de filtros globais.
• Mova as pastas detectadas para um volume permanente removendo os comentários 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 criada de uma VM migrada que é usada para o contêiner. É possível alterar esse valor se preferir usar um nome diferente.

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 em um contexto de contêiner.

Além dos serviços desativados automaticamente pelo Migrate to Containers, é possível desativar opcionalmente outros serviços:

• O Migrate to Containers descobre automaticamente serviços que você pode desativar, opcionalmente, 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 serviços relacionados ao sistema operacional. Também é possível, opcionalmente, 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 os serviços 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

Ao executar 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 a serem 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

Para modificar posteriormente a lista de serviços desativados:

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

Como alternativa, depois de executar uma migração para gerar os artefatos de migração, é possível editar o arquivo blocklist.yaml diretamente e, em seguida, 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 endpoints para personalizar o plano de migração.

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

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 que as solicitações enviadas ao serviço são roteadas.
• 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 receber o endpoint do 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 são exclusivos dentro do plano de migração. Por exemplo, o plano de migração acima cria um serviço que segmenta o Nginx na porta 80 sobre HTTP.

Para nomes duplicados, o recurso o Migrate to Containers anexa um sufixo de contador. Por exemplo, se o Nginx estiver associado a duas portas, ele adicionará 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 artefatos de migração, o Migrate to Containers cria uma definição de Service no arquivo deployment_spec.yaml para cada endpoint.

Por exemplo, mostrado abaixo é uma 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 NFS

O Migrate to Containers inclui montagens de 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.

Observação: as entradas na matriz nfsMounts são desativadas por padrão. Ative-os se quiser que o Migrate to Containers gere entradas no arquivo deployment_spec.yaml para cada ativação do NFS.

Ao gerar o plano de migração, o Migrate to Containers:

• Ignora as ativações NFS para /sys e /dev.
• Ignora as montagens de NFS com um tipo diferente de nfs ou nfs4.

Cada montagem de 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 ativação.

Por exemplo, para a 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 a seguinte 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 para processar entradas na matriz nfsMounts, defina enabled como true para a entrada mountPoint. É possível ativar uma, algumas ou todas as entradas mountPoints, editar ou adicionar suas próprias entradas.

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

Observação: o Migrate to Containers exige que os servidores do NFS sejam acessíveis no cluster de implantação que hospeda a carga de trabalho do contêiner migrado. No entanto, o Migrate to Containers não valida essa conectividade. Um contêiner migrado com um problema de conectividade não pode ser iniciado e talvez seja necessário editar o arquivo deployment_spec.yaml para corrigir o problema. Consulte Acessar instâncias do Filestore com o driver CSI do Filestore para mais informações.

Por exemplo, mostrado abaixo é uma 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.

Veja abaixo um exemplo de definições 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

Normalmente, uma VM de origem grava 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 essas informações de registro no Cloud Logging.

Observação: as versões anteriores do Migrate to Containers eram compatíveis com a personalização do registro usando um ConfigMap no cluster de carga de trabalho de destino, conforme descrito em Como configurar a geração de registros no Cloud Logging. Nesta seção, descrevemos como usar o arquivo logs.yaml para configurar a geração de registros. Se o arquivo logs.yaml existir, as configurações de registro definidas por um ConfigMap serão ignoradas.

Quando você gera o plano de migração, o Migrate to Containers pesquisa automaticamente os arquivos de destino do registro na VM de origem. Em seguida, 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 gera o arquivo logs.yaml do plano de migração. Esse arquivo contém a 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 gravadas automaticamente no Cloud Logging.

As entradas aparecem 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, é possível:

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

• Edite logs.yaml depois de gerar os artefatos de migração para adicionar, remover ou editar entradas logs.

A vantagem de editar o plano de migração é que suas edições sã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 Linux v2kServiceManager

É possível monitorar o tempo de inatividade e o status pronto 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 ajudar a reduzir a inatividade dos contêineres migrados e oferecer um monitoramento melhor.

Os estados de integridade desconhecidos podem gerar degradação de disponibilidade, monitoramento de disponibilidade falso positivo e possível perda de dados. Sem uma sondagem de integridade, o kubelet só pode pressupor a integridade de um contêiner e enviar o tráfego para uma instância que não esteja pronta. Isso pode causar perda de tráfego. O Kubelet também pode não detectar contêineres que estão no estado congelado e não os reiniciará.

Uma sondagem de integridade funciona executando uma pequena instrução de script quando o contêiner é iniciado. O script verifica as condições bem-sucedidas, que são definidas pelo tipo de sondagem usada a cada período. O período é definido no plano de migração por um campo do periodSeconds. É possível executar ou definir esses scripts manualmente.

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

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

• Sondagem de atividade: são usadas para saber quando reiniciar um contêiner.
  Observação: se um processo no seu contêiner consegue falhar sozinho quando encontra um problema ou se torna não íntegro, você não precisa necessariamente de uma sondagem de atividade. O kubelet executará automaticamente a ação correta de acordo com o restartPolicy do pod.
• Sondagem de prontidão: são usadas para saber quando um contêiner está pronto para começar a aceitar tráfego. Para começar a enviar tráfego a um pod somente quando a sondagem for bem-sucedida, especifique uma sondagem de prontidão. Uma sondagem de prontidão pode atuar de maneira semelhante a uma sondagem de atividade, mas uma sondagem de prontidão nas especificações indica que um pod vai começar sem receber nenhum tráfego e só vai começar a receber tráfego depois que a sondagem for bem-sucedida.

Após a descoberta, a configuração da sondagem é adicionada ao plano de migração. As sondagens podem ser usadas na configuração padrão, conforme mostrado abaixo. 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, toda a sondagem de serviço fica desativada. Defina qual subconjunto de serviços será monitorado.

Observação: nem todos os serviços são compatíveis com a sondagem e podem causar falha na inicialização de um contêiner.

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

• exec: executa um comando especificado no contêiner. A execução será considerada bem-sucedida se o código de status de saída for 0.
• grpc: executa uma chamada de procedimento remoto usando 'gRPC". As sondagens "gRPC" são um recurso Alfa.
• httpGet: executa uma solicitação GET HTTP para o endereço IP do pod em uma porta e caminho especificados. A solicitação será considerada bem-sucedida se o código de status for 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 será considerado bem-sucedido se a porta estiver aberta.

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

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

A seguir

• Saiba como executar a migração.