Personalize o plano de migração para VMs Linux

Antes de executar um plano de migração, deve revê-lo e, opcionalmente, personalizá-lo. Os detalhes do seu plano de migração são usados para extrair os artefactos do contentor da VM de origem e também para gerar ficheiros de implementação do Kubernetes que pode usar para implementar a imagem do contentor noutros clusters, como um cluster de produção.

Esta página descreve os conteúdos do plano de migração e os tipos de personalizações que pode considerar antes de executar a migração e gerar artefactos de implementação.

Antes de começar

Este tópico pressupõe que já criou um plano de migração e tem o ficheiro do plano de migração resultante.

Edite o plano de migração

Depois de copiar o sistema de ficheiros e analisá-lo, pode encontrar 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 guarde as alterações.

Reveja os detalhes do plano de migração e os comentários orientadores para adicionar informações conforme necessário. Em concreto, considere fazer edições nas seguintes secções.

Especifique o conteúdo a excluir da migração

Por predefinição, o Migrate to Containers exclui o conteúdo típico de VMs que não é relevante no contexto do GKE. Pode personalizar esse filtro.

O valor do campo filters apresenta os caminhos que devem ser excluídos da migração e não farão parte da imagem do contentor. O valor do campo apresenta regras de filtro rsync que especificam os ficheiros a transferir e os ficheiros a ignorar. Preceder cada caminho e ficheiro com um sinal de menos especifica que o item na lista deve ser excluído da migração. A lista é processada de acordo com a ordem das linhas no YAML, e as exclusões/inclusões são avaliadas em conformidade.

Saiba mais acerca das regras de filtro rsync.

Os ficheiros demasiado grandes para serem incluídos na imagem do Docker são apresentados no ficheiro YAML. Isto vai sinalizar os ficheiros com mais de 1 GB para sua consideração. As imagens do Docker demasiado grandes ou com mais de 15 GB correm o risco de falhar durante a migração.

Pode editar a lista YAML para adicionar ou remover caminhos. Veja um exemplo de YAML abaixo, que inclui exclusões de exemplo, bem como notificações para ficheiros grandes e esparsos. Siga as orientações incorporadas para realizar uma das seguintes ações:

  • Exclua as pastas detetadas descomentando-as e colocando-as na secção de filtros globais.
  • Mova as pastas detetadas para um volume persistente descomentando-as e colocando-as na secção da pasta de dados.

Também pode excluir ou mover os ficheiros esparsos detetados da mesma forma.

  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)

Defina o nome da imagem do contentor

O valor do campo name na secção image define o nome da imagem criada a partir de uma VM migrada que é usada para o contentor. Pode alterar este valor se preferir usar um nome diferente.

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

Personalize a lista de serviços

Por predefinição, a ferramenta Migrate to Containers desativa os serviços desnecessários numa VM quando a migra para um contentor. Por vezes, estes serviços podem causar problemas com o contentor migrado ou não são necessários num contexto de contentor.

Juntamente com os serviços desativados automaticamente pela ferramenta Migrate to Containers, pode desativar opcionalmente outros serviços:

  • A migração para contentores descobre automaticamente os serviços que pode desativar opcionalmente e apresenta-os no plano de migração. Estes serviços, como ssh ou um servidor Web, podem não ser necessários na sua carga de trabalho migrada, mas a decisão é sua. Se necessário, edite o plano de migração para desativar estes serviços.

  • A ferramenta Migrate to Containers não lista todos os serviços em execução na VM de origem. Por exemplo, omite serviços relacionados com o sistema operativo. Opcionalmente, pode editar o plano de migração para adicionar a sua própria lista de serviços a desativar no contentor 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.

A migração para contentores não lista todos os serviços em execução na VM de origem, como os serviços relacionados com o sistema operativo. Também pode adicionar serviços adicionais à lista. Por exemplo, para desativar o serviço 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 executa uma migração para gerar os artefactos de migração, o Migrate to Containers cria o ficheiro blocklist.yaml. Este ficheiro lista os serviços de contentores a desativar com base nas suas definiçõ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 regenerar os artefactos de migração, incluindo um blocklist.yaml atualizado.

Em alternativa, depois de executar uma migração para gerar os artefactos de migração, pode editar diretamente o ficheiro blocklist.yaml e, de seguida, criar e implementar a imagem do contentor através do Skaffold.

Personalize pontos finais 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 Kubernetes fornecidos pela carga de trabalho migrada. Pode adicionar, editar ou eliminar definições de pontos finais para personalizar o plano de migração.

Para obter as portas dos pontos finais, verifique os programas que estão a ouvir portas:

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

Para cada ponto final do serviço, adicione a seguinte definição ao plano de migração:

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

Onde:

  • PORT_NUMBER especifica o número da porta do contentor para o qual os pedidos ao serviço são encaminhados.
  • PORT_PROTOCOL especifica o protocolo da porta, como HTTP, HTTPS ou TCP. Consulte os protocolos suportados para ver a lista completa de protocolos.
  • PORT_NAME especifica o nome usado para aceder ao ponto final do serviço. A migração para contentores gera um PORT_NAME único para cada definição de ponto final gerada.

Por exemplo, o Migrate to Containers deteta os seguintes pontos finais:

  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 únicos no plano de migração. Por exemplo, o plano de migração acima cria um serviço que segmenta o Nginx na porta 80 através de HTTP.

Para todos os nomes duplicados, a app Migrate to Containers acrescenta um sufixo de contador. Por exemplo, se o Nginx estiver associado a duas portas, 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 executa uma migração para gerar os artefactos de migração, o Migrate to Containers cria uma definição de serviço no ficheiro deployment_spec.yaml para cada ponto final.

Por exemplo, abaixo é apresentada uma definição de Service no ficheiro 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: {}

Personalize montagens NFS

O Migrate to Containers inclui montagens NFS no plano de migração gerado. Estas informações são recolhidas a partir do ficheiro fstab e escritas na matriz nfsMounts no plano de migração. Pode adicionar ou editar definições de ponto de montagem do NFS para personalizar o plano de migração.

Ao gerar o plano de migração, a funcionalidade Migrar para contentores:

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

Cada montagem 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

Onde:

  • MOUNT_POINT especifica o ponto de montagem obtido a partir de fstab.
  • DIR_NAME especifica o nome do diretório partilhado.
  • IP especifica o endereço IP do servidor que aloja o ponto de montagem.
  • OPTION_N especifica quaisquer opções extraídas do fstab para o ponto de montagem.

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

A ferramenta 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 a ferramenta Migrate to Containers para processar entradas na matriz nfsMounts, defina enabled como true para a entrada mountPoint. Pode ativar uma, algumas ou todas as entradas mountPoints, editar as entradas ou adicionar as suas próprias entradas.

Quando executa uma migração para gerar os artefactos de migração, o Migrate to Containers cria uma definição de volumes e volumeMounts e uma definição de PersistentVolume e PersistentVolumeClaim no ficheiro deployment_spec.yaml para cada montagem NFS ativada.

Por exemplo, abaixo é apresentada uma definição de volumeMounts no ficheiro 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 pela ferramenta Migrate to Containers.

Abaixo, encontra-se um exemplo de definições de PersistentVolumeClaim e PersistentVolume no ficheiro 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

Personalize os dados de registo escritos no Cloud Logging

Normalmente, uma VM de origem escreve informações num ou mais ficheiros de registo. Como parte da migração da VM, pode configurar a carga de trabalho migrada para escrever essas informações de registo no Cloud Logging.

Quando gera o plano de migração, o Migrate to Containers pesquisa automaticamente ficheiros de destino de registos na VM de origem. Migre para contentores e, em seguida, escreve informações sobre esses ficheiros detetados 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 gera os artefactos de migração, o Migrate to Containers gera o ficheiro logs.yaml a partir do plano de migração. Este ficheiro contém a lista de ficheiros de registo detetados na VM de origem. Por exemplo, a partir da definição de logsPath acima, logs.yaml contém:

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

Neste exemplo, quando implementa a carga de trabalho migrada, as informações de registo escritas em catalina.out são escritas automaticamente no Cloud Logging.

Cada entrada aparece numa linha no registo no seguinte formato:

DATE TIME APP_NAME LOG_OUTPUT

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

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

Para configurar o registo, pode:

  • Edite o plano de migração antes de gerar os artefactos de migração para adicionar, remover ou editar entradas logPaths. Quando gera os artefactos de migração, estas edições são refletidas no ficheiro logs.yaml.

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

A vantagem de editar o plano de migração é que as edições são refletidas logs.yaml sempre que gera os artefactos. Se editar logs.yaml diretamente e, por algum motivo, regenerar os artefactos, tem de voltar a aplicar as edições a logs.yaml.

Defina as sondas de funcionamento do Linux v2kServiceManager

Pode monitorizar o tempo de inatividade e o estado de prontidão dos seus contentores geridos especificando sondagens no plano de migração do servidor Web Tomcat. A monitorização de testes de integridade pode ajudar a reduzir o tempo de inatividade dos contentores migrados e oferecer uma melhor monitorização.

Os estados de saúde desconhecidos podem criar uma degradação da disponibilidade, uma monitorização da disponibilidade de falsos positivos e uma potencial perda de dados. Sem uma sondagem de saúde, o kubelet só pode presumir o estado de um contentor e pode enviar tráfego para uma instância de contentor que não esteja pronta. Isto pode causar perda de tráfego. O Kubelet também pode não detetar contentores que estejam num estado congelado e não os reinicia.

Uma sondagem de saúde funciona executando uma pequena declaração com script quando o contentor é iniciado. O script verifica as condições bem-sucedidas, que são definidas pelo tipo de teste usado, em todos os períodos. O período é definido no plano de migração por um campo periodSeconds. Pode executar ou definir estes scripts manualmente.

Para saber mais sobre as sondas kubelet, consulte o artigo Configure Liveness, Readiness and Startup Probes na documentação do Kubernetes.

Existem dois tipos de sondas disponíveis para configuração. Ambas as sondas são probe-v1-core definidas na referência probe-v1-core e partilham a mesma função que os campos correspondentes de container-v1-core

  • Sondagem de atividade: as sondagens de atividade são usadas para saber quando reiniciar um contentor.

  • Sondagem de disponibilidade: as sondagens de disponibilidade são usadas para saber quando um contentor está pronto para começar a aceitar tráfego. Para começar a enviar tráfego para um pod apenas quando uma sondagem for bem-sucedida, especifique uma sondagem de prontidão. Uma sondagem de disponibilidade pode funcionar de forma semelhante a uma sondagem de atividade, mas uma sondagem de disponibilidade nas especificações indica que um pod é iniciado sem receber tráfego e só começa a receber tráfego depois de a sondagem ser bem-sucedida.

Após a deteção, a configuração da sondagem é adicionada ao plano de migração. As sondas podem ser usadas na respetiva configuração predefinida, conforme mostrado abaixo. Para desativar as sondagens, remova a secçã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 predefinição, a sondagem de serviços está desativada. Tem de definir que subconjunto de serviços vai ser monitorizado.

Existem quatro formas predefinidas de verificar um contentor através de uma sonda. Cada teste tem de definir exatamente um destes quatro mecanismos:

  • exec: executa um comando especificado no contentor. A execução é considerada bem-sucedida se o código de estado de saída for 0.
  • grpc – Executa uma chamada de procedimento remoto através de `gRPC`. As sondagens `gRPC` são uma funcionalidade alfa.
  • httpGet - Executa um pedido HTTP GET no endereço IP do pod numa porta e num caminho especificados. O pedido é considerado bem-sucedido se o código de estado for igual ou superior a 200 e inferior a 400.
  • tcpSocket – Executa uma verificação TCP no endereço IP do Pod numa porta especificada. O diagnóstico é considerado bem-sucedido se a porta estiver aberta.

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

Para adicionar dependências externas para a sondagem de prontidão, enquanto usa a sondagem de atividade padrão, defina uma sondagem de prontidão exec e um script que implemente a lógica.

O que se segue?