Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Sincronizando Clusters Hospedados

A sincronização permite que o Rancher atualize os valores do cluster para que estejam atualizados com o objeto de cluster correspondente hospedado no AKS, EKS ou GKE. Isso permite que fontes além do Rancher possuam o estado de um cluster hospedado.

Você pode acidentalmente sobrescrever o estado de uma fonte se processar simultaneamente uma atualização de outra fonte. Isso também pode ocorrer se você processar uma atualização de uma fonte dentro de 5 minutos após terminar uma atualização de outra fonte.

Como funciona

Existem dois campos no objeto Cluster do Rancher que devem ser compreendidos para entender como a sincronização funciona:

  1. O objeto de configuração para o cluster, localizado na Especificação do Cluster:

    • Para AKS, o campo é chamado AKSConfig

    • Para EKS, o campo é chamado EKSConfig

    • Para GKE, o campo é chamado GKEConfig

  2. O objeto UpstreamSpec

    • Para AKS, isso está localizado no campo AKSStatus no Status do Cluster.

    • Para EKS, isso está localizado no campo EKSStatus no Status do Cluster.

    • Para GKE, isso está localizado no campo GKEStatus no Status do Cluster.

Os tipos de estrutura que definem esses objetos podem ser encontrados em seus projetos de operador correspondentes:

Todos os campos podem ser nulos, exceto pelos seguintes: o nome do cluster, a localização (região ou zona), Importado e a referência de credencial da nuvem.

O AKSConfig, EKSConfig ou GKEConfig representa o estado desejado. Valores nulos são ignorados. Os campos que não são nulos no objeto de configuração podem ser considerados gerenciados. Quando um cluster é criado no Rancher, todos os campos são não nulos e, portanto, gerenciados. Quando um cluster pré-existente é registrado no Rancher, todos os campos que podem ser nulos são definidos como nulos e não são gerenciados. Esses campos se tornam gerenciados assim que seu valor é alterado pelo Rancher.

UpstreamSpec representa o cluster como ele está no provedor de Kubernetes hospedado. Ele é atualizado a cada 5 minutos. Após a atualização do UpstreamSpec, o Rancher verifica se o cluster está com uma atualização em andamento. Se ele estiver atualmente atualizando, nada mais é feito. Se não estiver atualmente atualizando, quaisquer campos gerenciados no AKSConfig, EKSConfig ou GKEConfig são sobrescritos com seus valores correspondentes do UpstreamSpec recentemente atualizado.

Quando você importa um cluster de um provedor de nuvem para o Rancher, o UpstreamSpec representa o estado do cluster e o Config está vazio. Se você então atualizar o cluster importado através da interface do Rancher, tanto o UpstreamSpec quanto o Config se tornam não nulos. Quaisquer atualizações adicionais no cluster devem ser aplicadas por meio do Rancher. Isso ocorre porque não há uma maneira segura de determinar se as mudanças originadas do UpstreamSpec representam o estado desejado ou apenas uma incompatibilidade com a Configuração. Se você atualizar o cluster importado através do console do provedor de nuvem após aplicar quaisquer atualizações pela interface do Rancher, o controlador fará um rollback e o conteúdo de Config será considerado o estado desejado.

O estado desejado efetivo pode ser considerado como o UpstreamSpec, mais todos os campos não nulos no AKSConfig, EKSConfig ou GKEConfig. Isso é o que é exibido na interface do usuário.

Se o Rancher e outra fonte tentarem atualizar um cluster ao mesmo tempo, ou dentro de 5 minutos após a conclusão de uma atualização, quaisquer campos gerenciados provavelmente ficarão presos em uma condição de corrida. Para usar o EKS como exemplo, um cluster pode ter PrivateAccess como um campo gerenciado. Se PrivateAccess for falso e depois habilitado no console do EKS às 11:01, e as tags forem atualizadas a partir do Rancher antes das 11:05, então o valor provavelmente será sobrescrito. Isso também pode ocorrer se as tags forem atualizadas enquanto o cluster ainda estiver processando a atualização. O problema descrito neste exemplo não deve ocorrer se o cluster estiver registrado e os campos PrivateAccess forem nulos.