Estamos executando uma implantação do Kubernetes na distribuição canônica com o Juju em um cluster local do vSphere 6.5, mas notamos um problema relacionado ao DHCP ao adicionar um novo trabalhador do kubernetes (via "juju add-unit kubernetes-worker").
Enquanto a nova VM é criada sem problemas, a seguinte sequência acontece na primeira inicialização, pouco antes de a rede estar ativa:
1) o nome do host é inicialmente definido como "ubuntu"
2) a rede é iniciada e uma solicitação DHCP para uma concessão de IP é feita, usando o nome de host "ubuntu" (assim, o servidor DHCP registra a concessão como "ubuntu")
3) o nome do host é alterado para o valor adequado (ex .: "juju-fe12e1-11"), mas nenhuma solicitação DHCP adicional é enviada para atualizar as informações de concessão, deixando-a indefinidamente como "ubuntu"
Então, basicamente, no servidor DHCP, todas as concessões IP têm o mesmo nome atribuído ao "ubuntu", e o mesmo acontece no servidor DNS local, pois a atualização automática de registros pelo servidor DHCP é ativada em nosso ambiente local.
É claro que reiniciar manualmente as VMs uma vez corrige a situação, porque na segunda inicialização o nome do host já está correto e o registro DHCP tem o nome "juju-xxxxxx-xx" correto (o mesmo aconteceria também se um lançamento / renovação do dhclient comando seria emitido sem reinicialização real). O problema é que, até que uma dessas ações seja executada, o nó não é resolvido pelo nome DNS e também causa alguns problemas do lado do Kubernetes.
Todo mundo sabe de uma maneira de efetuar esse comportamento e ter o registro do nome do DHCP consistente com o nome do host real sem exigir intervenção manual?
Senão, existe alguma possibilidade de ter a sequência de operações que é executada na inicialização corrigida de forma que um comando de renovação de DHCP seja apropriadamente emitido depois que o nome do host for alterado? (isso seria suficiente para tornar os registros de nomes consistentes)
Claudio