Kubernetes: Se o kubelet não estiver disponível, AttachDetachController não conseguirá forçar a desconexão na exclusão do pod

[MILESTONENOTIFIER] Problema de marco: atualizado para o processo

@verult

• sig/storage : o problema será encaminhado a esses SIGs, se necessário.
• priority/important-soon : Encaminhe para os proprietários do problema e proprietário do SIG; sair do marco após várias tentativas malsucedidas de escalonamento.
• kind/bug : Corrige um bug descoberto durante a versão atual.
  
  
  
  

  Socorro

• Instruções adicionais
• Comandos para definir rótulos

Talvez eu tenha encontrado um caso semelhante, mas não o mesmo.

A sequência geral conforme abaixo:

• Config volumes.kubernetes.io/controller-managed-attach-detach para que o controlador de anexar / desanexar seja responsável pelas operações attaching e detaching ;
• Crie um statefulset com volumes provisionados por glusterfs ;
• Use iptables para simular uma falha de partição de rede do trabalhador mestre. Como resultado, kubelet no nó de trabalho não pode se comunicar com apiserver no momento;
• NodeLifecycleController subsequentemente detecta o nó inacessível e despeja os pods do nó inacessível;
• Os pods despejados serão recriados e programados para outro nó disponível com os volumes anteriores.

O controlador de anexar / desconectar funciona conforme o esperado. Eu uso a versão 1.9.3 .

@orainxiong é o terminationGracePeriod definido dentro do statefulset?

terminationGracePeriod é 0 se bem me lembro. Eu acho que pode ser a causa raiz.

@ saad-ali, podemos nos atualizar se alguém está trabalhando nesse problema?

Eu posso dar uma olhada nisso

/atribuir

@ saad-ali, @verult e eu

Olá, @ saad-ali, @verult e @gnufied.

Tenho uma preocupação sobre como corrigir esse problema.
Com relação à implementação de https://github.com/kubernetes/kubernetes/pull/67847 \ https://github.com/kubernetes/kubernetes/pull/67419 , não tenho certeza se o design de PR é suficientemente econômico.
A solução proposta neste PR foi aproveitar o DeletionGracePeriodSeconds em vez de usar o podStatus.ContainerStatuses ( AQUI ).

É bom não confiar em podStatus.ContainerStatuses porque em um cenário de crash worker o kubelet não responde e o ContainerStatuses permanecerá em execução para sempre (o que evita desconectar o POD). Portanto, adicionar DeletionGracePeriodSeconds como outro gatilho para forçar a desconexão dos PVCs de um POD sem resposta é uma boa ideia.

MAS eu acho que devemos ter muito cuidado ao forçar a desconexão de PVCs, porque se for um cenário de divisão do cérebro (o nó de trabalho não foi realmente travado, foi apenas um problema de rede) e o POD ainda está executando e gravando IO no PVC, desconectando o PVC pode levar à corrupção de dados.
Então, talvez seja muito brutal confiar neste DeletionGracePeriodSeconds (AFAIK, o cliente que enfrenta esse tempo limite é TerminationGracePeriodSeconds, que é por padrão 30 segundos se você não especificou na especificação do pod.). Portanto, se pegarmos essa implementação de PR, pode haver um aplicativo que obterá a separação forçada no cérebro dividido e talvez esses aplicativos não consigam lidar com esse desligamento.

Eu gostaria de propor uma implementação de proteção que por um lado irá separar para PODs que no cenário de nó travado, mas por outro lado será salva o suficiente também para o cenário de cérebro dividido.
A proposta é adicionar uma nova anotação na especificação do POD (por exemplo: AllowForceDetachAfterGracePeriod com o padrão falso), e apenas se o cliente especificar na especificação do pod com valor verdadeiro,
então k8s forçará a desconexão de PVCs deste POD, mas se for falso, mesmo após DeletionGracePeriodSeconds não forçará a desconexão do POD - mantendo o comportamento existente - então o cliente terá que deletar manualmente o POD (faça isso de forma manual e salva para evitar a perda de dados).
Portanto, ao adicionar essa anotação de segurança, fornecemos ao cliente a capacidade de decidir se esse pod pode se recuperar da operação de desanexação. E então você irá preencher o save para também escolher esta correção para versões mais antigas do k8s, porque você não afetará nenhum comportamento existente (somente PODs com esta anotação obterão o novo comportamento).

Pensamentos?
Deixe-me saber se é over kill, ou talvez sua proteção para o usuário evitar a perda de dados em potencial.

@gnufied e eu discutimos isso offline. Por favor, corrija-me se eu estiver errado, Hemant, mas seu argumento foi que definir a anotação como true é equivalente a definir TerminationGracePeriod muito alto, o que também "desativa" esse comportamento de desconexão atrasando-o indefinidamente.

Por outro lado, como o TerminationGracePeriod padrão é 30s, não podemos escolher com segurança este PR de volta para versões anteriores.

Uma opção é usar uma anotação + DeletionGracePeriod para todas as versões anteriores a 1.12 e apenas DeletionGracePeriod para 1.12 e posteriores.

Uma das outras coisas que podemos fazer é - somente desanexar volumes de um nó quando soubermos que ele foi desligado. Então, basicamente, use a contaminação recém-introduzida para destacar o volume. Isso significa que os volumes nunca são desconectados dos nós do Kubelet que não respondem ou travados, mas provavelmente não há problema. Se o usuário realmente deseja forçar a desconexão, ele sempre pode fazer isso via:

~> kubectl delete pod <foo> --force=true --grace-period=0

Isso significa que teremos que implantar esse PR em https://github.com/kubernetes/kubernetes/pull/67977 e obviamente não podemos fazer backport.

Versões mais antigas do AWS, Openstack e Vsphere não são afetadas por este bug btw - porque nesses provedores de nuvem um nó é excluído quando desligado. Só recentemente esse comportamento foi alterado nesses provedores de nuvem e o objeto de nó não é mais excluído e, portanto, os pods permanecem na fase "Desconhecida" e o volume nunca é desconectado.

Este bug afeta as versões desde 1.9 (ou mesmo antes disso). Mas o comportamento do provedor de nuvem é uma mudança recente. Outro problema é - usar o desligamento para detectar a desconexão do volume foi bloqueado como um recurso alfa,

Não gosto muito da opção de anotação tbh. É difícil documentar e fácil de ignorar e, como é uma alteração da API, também precisa passar pelas fases alfa e beta. Concordou que - https://github.com/kubernetes/kubernetes/pull/67977 é atualmente fechado por recurso também, mas não vejo uma forte razão para que isso deva ser fechado por recurso. cc @yastij

@gnufied - alguns clusters de produção dependem de reinicializações rápidas (ou seja, reinicializar e ainda ter discos conectados). Podemos querer dar a eles alguma largura de banda para a transição.

@yastij não deve

O motivo pelo qual não gosto particularmente de anotações também é porque desanexar volumes de nós de desligamento deve ser um comportamento padrão e não deve exigir a intervenção do usuário. Se pudermos diferenciar entre nós de desligamento e kubelets que não respondem, devemos usar essas informações para desanexar volumes e deve ser o padrão, em vez de algo que o usuário deve configurar.

Eu concordo com @gnufied nas anotações.

o plano é promovê-lo como beta em 1.13. Pelo que tenho visto, o tempo limite de remoção afeta todos os pods, o que pode ser complicado: para clusters agressivos, isso não funciona, pois o tempo limite do pod e o período de tolerância do nó são definidos mais baixos do que o normal. Esta janela (1 versão) garante que tudo corra bem.

Bons argumentos de ambos os lados. Por um lado, devemos ter muito cuidado para não causar corrupção de dados. Por outro lado, não queremos chegar a um estado em que seus dados fiquem presos e exijam intervenção manual para acesso de novas cargas de trabalho.

Concordo com @gnufied , devemos evitar adicionar outra anotação - sempre que houver uma dúvida como essa, expor a opção ao usuário final é a saída mais fácil, mas não necessariamente a melhor. Devemos tentar ser inteligentes e fazer a coisa certa automaticamente em nome do usuário.

A coisa certa neste caso é complicada. Se um nó não estiver voltando, devemos mover o disco, mesmo que ele não seja desmontado com segurança. Mas como podemos diferenciar isso de um cérebro dividido? Um algoritmo baseado em cronômetro é bastante rudimentar, mas é a melhor aproximação que temos atualmente. E não estou ciente de nenhuma maneira de detectar um cérebro dividido versus um nó morto, então acho que precisamos pesar a probabilidade dos diferentes cenários acontecendo e o pior caso para cada opção e quão dispostos estamos para tolerar isso.

Vou deixar para vocês pesar essas compensações.

@gnufied na verdade nos nós do https://github.com/kubernetes/kubernetes/pull/59931 Isso basicamente significa que, no openstack, se você desligar a instância que tinha pod com pvc, ele não pode fazer failover para outra instância.

No entanto, # 67977 corrigirá esse problema

Acabei de falar com @yastij que devemos usar o portão de recursos apenas para separar o atraso. Em seguida, ele pode desanexar os volumes no openstack novamente, se o feature gate ativado, o atraso é algo como 1min e se não for ativado, o retardo desanexado é algo como 8-10 minutos.

Você está correto, pois na AWS este problema não existe, mas se o número 59930 for aprovado (como deveria, porque outro comportamento e especificação da nuvem é que não deve excluir nós). Então o aws também terá esse problema se o # 67977 não for aprovado.

Algumas notas que fiz durante a reunião de conferência de hoje ( @verult, por favor, adicione suas notas também):

• Os PRs https://github.com/kubernetes/kubernetes/pull/67847 , https://github.com/kubernetes/kubernetes/pull/67419 devem ser suspensos, devido ao risco potencial de divisão do cérebro. E, por enquanto, o usuário terá que excluir manualmente os pods do nó com falha ou apenas excluir o objeto do nó com falha para acionar a operação de separação de PVC.

• PR https://github.com/kubernetes/kubernetes/pull/67977 ainda está em vigor, porque permitirá separar os PVCs do nó com a contaminação nodeShutdown. Mas só se aplica a drivers de provedores de nuvem.

• Tíquete aberto https://github.com/kubernetes/kubernetes/issues/68086 para tornar maxWaitForUnmountDuration como valor configurável (em vez de 6 minutos codificados permanentemente).

• É menos recomendado usar a anotação de Pod para indicar o modo de separação forçada de PVC.

Temos alguma noção do prazo para resolver esse problema? O congelamento do código ocorre na próxima semana, momento em que apenas bugs críticos / urgentes serão permitidos no marco.

Obrigado! :)

@ shay-berman PR # 67977 ainda deve estar em espera porque sem o manuseio real dos pods dos nós de desligamento, o PR # 67977 não tem nenhum efeito. Os volumes ainda não serão desconectados dos nós de desligamento.

cc @ msau42 @ jingxu97

@gnufied sim? Vamos dizer que temos 2 nós: nó1 e nó2. Então nós temos uma implantação chamada foobar que tem pvc nela. foobar agora está sendo executado em node1 e, em seguida, node1 é encerrado.

O resultado é que o pod de foobar node1 vai para um estado desconhecido e o volume é desconectado usando o volume danglingerror. O pod foobar iniciará em node2 e o volume será anexado (agora leva algo como um pouco mais de 1 minuto). O que acontece quando o node1 volta? Ele apenas encerrará o pod foobar em node1 e não afetará mais os volumes.

Acabei de testar :)

@zetaab , o que acontece se não foi encerrado?
Ou seja, o contêiner usando o pvc está funcionando e gravando no pvc.
A comunicação com o kubelet tem um problema por 1 hora, depois volta.

@zetaab dangling error deve apenas adicionar um volume ao estado real do mundo para lidar com o caso de status de pod perdidos. Em si - ele nunca deve causar desconexões de volume. Se isso acontecer, provavelmente temos um bug. Eu testei um cenário semelhante na AWS com o patch mais recente (https://github.com/kubernetes/kubernetes/pull/66835) que evita que o objeto do nó seja excluído e os volumes NÃO sejam desconectados.

Se na pilha aberta os volumes estão sendo desconectados de nós de desligamento com objetos pod ainda por perto, então eu chamaria isso de mágico / bug. :-)

@itamarh como comentei naquele PR não faz nada se houver problema com a conectividade (sem mancha). O próprio Kubernetes inicia o despejo (tenho 1 minuto de despejo), então, após 1 minuto, ele tentará criar o pod para outro nó. No entanto, como o volume não está desconectado, ele não pode ser iniciado.

Não sei se deve forçar a desconexão da unidade em caso de problema de conectividade ou não. O comportamento antes das alterações do cloudprovider era que ele esperaria 6 minutos antes de forçar a desconexão.

@gnufied é um pouco estranho que os pods sejam então despejados para outro nó? Algum controlador de pod deve verificar "isso tem volumes no nó que estão travados"?

Vamos pensar no seguinte cenário: eu tenho um pod com pvc localizado no node1, esse node trava e não pode mais iniciar. Como o kubernetes deve se comportar?

Cenários possíveis:

• não faça nada: espere até que o administrador fique online (o administrador pode, por exemplo, desanexar o volume manualmente e, em seguida, o pod iniciará em outro nó. Ou ele pode simplesmente excluir a máquina quebrada e o volume ser desconectado. A automação também pode excluir as máquinas?)
• desanexar a unidade em 6 minutos: acho que esse era o comportamento antes das atualizações do cloudprovider?
• ?

Apenas para adicionar ao que @ shay-berman escreveu a discussão completa é o seguinte:

1. Https://github.com/kubernetes/kubernetes/pull/67977 e https://github.com/kubernetes/kubernetes/pull/67847 devem estar em espera por enquanto. Porque, como descobrimos, o # 67977 não terá efeito se o pod não for removido do DSWP (estado do mundo desejado).

2. O motivo pelo qual escolhemos colocar https://github.com/kubernetes/kubernetes/pull/67847 em espera é porque qualquer valor de tempo que decidirmos para forçar a separação do volume de um pod na fase "Desconhecido" é fundamentalmente inseguro. Esta foi a recomendação de @derekwaynecarr e @liggitt também.

3. Também discutimos a possibilidade de usar a contaminação "Desligar" para remover pods do DSWP. A ideia subjacente é - se um nó tiver a contaminação "Desligar", todos os seus pods que estão totalmente encerrados ou têm DeletionTimeStamp definido podem ser removidos do DSWP e, portanto, desconectar o gatilho. O problema em fazer isso no controlador de anexação / desconexão é - o controlador de anexação / desconexão deve usar o status do pod como fonte única de verdade para realizar desvinculações. Foi apontado para nós que os conjuntos stateful e pods apoiados pelo controlador de replicação podem precisar de um case especial e, portanto, se os volumes DEVEM ser separados de um nó que está desligado, essa decisão deve ser baseada no status do pod e deve vir do controlador de ciclo de vida do nó / pod . Por exemplo - no futuro, o controlador do ciclo de vida do nó pode marcar os contêineres de um pod que estão em um nó de desligamento / desligamento como terminado / não em execução e, portanto, anexar / desconectar o controlador desconectará automaticamente os volumes dele. @derekwaynecarr @liggitt tinha alguns pontos válidos contra o caso especial deste no controlador de anexar / desconectar.

@ shay-berman, o PR que íamos manter era aquele que já estava mesclado, o que apresenta a mancha de desligamento do nó: https://github.com/kubernetes/kubernetes/pull/59323

Enviei minhas notas de reunião para o armazenamento SIG. Avise-me se tiver problemas para acessar (meu Slack está funcionando). Acredito que você precisa ser um membro do SIG Storage para acessar.

https://groups.google.com/forum/#!forum/kubernetes -sig-storage

@ jingxu97 @ msau42 e @ random-liu de sig-node discutidos offline sobre potencialmente ter um controlador de nível superior para forçar a exclusão de um pod. Um dos possíveis problemas é que pode haver uma condição de corrida se o nó voltar a funcionar logo em seguida.

Imagine que temos um pod StatefulSet com um volume não anexável e suponha que o nó de desligamento volte antes de o pod ser excluído à força. Kubelet no nó vê que o pod ainda está programado e inicia os contêineres. Em seguida, o pod é excluído à força e um novo pod é iniciado em um nó diferente. Agora, há uma chance de que os mesmos contêineres estejam sendo executados em ambos os nós.

Para desligamento intencional de um nó para manutenção, onde a transferência altamente responsiva de cargas de trabalho para outro nó é desejada, não há substituto para o isolamento / drenagem de cargas de trabalho do nó antes do desligamento.

O desejo aqui é lidar com o desligamento intencional de um nó sem encerrá-lo e sem isolá-lo / drená-lo, enquanto ainda move cargas de trabalho e volumes para outro nó?

@liggitt - Sim, também pode cobrir o encerramento de um nó quando ele precisar ser migrado e reimplantado.

Para um desligamento intencional de um nó, como uma drenagem de nó não pode ser feita?

@ msau42 - Deveria ser. O recurso cobre ambos de qualquer maneira.

Meu entendimento é que este é mais um problema de desligamento não intencional, para disponibilizar volumes previamente anexados ao nó sem causar corrupção de dados.

É uma longa discussão. Acho que temos vários problemas abordados aqui,

Quando o kubelet não responde, os estados para os objetos a seguir são os seguintes:
Nó : a condição do nó é desconhecida
Pod : tentativa de expulsar o pod após (5) minutos. A remoção do pod normalmente não será bem-sucedida porque o kubelet não responderá e o objeto do pod ainda permanecerá no servidor API. Isso fará com que o statefulset falhe ao iniciar um novo pod.
Volume : o controlador attach_detach NÃO desanexará o volume porque o pod é considerado não encerrado (o status do contêiner ainda está em execução). Isso fará com que o volume não seja capaz de se conectar a um nó diferente.

Acho que esses são os estados corretos que desejamos quando a condição do nó é realmente desconhecida. Mas, em caso de desligamento, devemos fazer algo para melhorar a situação.

Agora temos a contaminação de desligamento de nó disponível. Quando o controlador do nó da nuvem detecta que o nó está no estado de desligamento, ele irá contaminar o nó com a condição de desligamento. PR https://github.com/kubernetes/kubernetes/pull/67977 está tentando usar esse taint para corrigir o problema de separação de volume.
Depois de discutir com @yastij , podemos fazer o seguinte funcionar

1. Status do nó de atualização do controlador de nó para remover volumeInUse depois que o nó é tingido como desligado (também pode marcar o contêiner como não executando)
2. O controlador Attach_detach tentará desconectar o volume se o volume não estiver mais em uso (foi removido o volumeInUse do status do nó na etapa 1) sem problemas (ele pode passar na verificação de safeToDetach agora).

Acho que https://github.com/kubernetes/kubernetes/pull/67977 pode ser considerado uma correção de bug em vez de um recurso. Ele usa a mancha de desligamento de nó introduzida recentemente (não é fechada por recurso). Isso não resolverá o problema de o pod não ser excluído do apiserver, mas pode desconectar o volume corretamente. Então, poderíamos empurrar esse PR primeiro e depois encontrar alguma solução para o problema de exclusão do pod durante o desligamento do nó? Obrigado!

Acho que # 67977 pode ser considerado uma correção de bug em vez de um recurso. Ele usa a mancha de desligamento de nó introduzida recentemente (não é fechada por recurso). Isso não resolverá o problema de o pod não ser excluído do apiserver, mas pode desconectar o volume corretamente. Então, poderíamos empurrar esse PR primeiro e depois encontrar alguma solução para o problema de exclusão do pod durante o desligamento do nó?

Fazer com que contaminações específicas informem um controlador de "desconexão forçada" em vez da lógica do planejador / despejo não parece seguro. Coordenar a existência do objeto pod é o que eu esperava.

Existe algum precedente para usar manchas dessa forma?

A mancha de desligamento informando a condição de execução do contêiner faz mais sentido, mas ainda é atrevida

Se o objeto Pod não for excluído, o StatefulSet não conseguirá recriar um pod substituto.

Status do nó de atualização do controlador de nó para remover volumeInUse depois que o nó é tingido como desligado (também pode marcar o contêiner como não executando)

Isso é antes ou depois dos volumes serem realmente lançados? Porque uma falha de kublet após a contaminação ser adicionada e antes de os volumes serem liberados ainda seria problemática.

Tenho muito mais experiência com sistemas HA tradicionais do que com k8s, mas um princípio básico do velho mundo é que você simplesmente não sabe o que não sabe. Você pode usar heurísticas e fazer suposições, mas às vezes elas estarão erradas e, dependendo da carga de trabalho, isso pode ser problemático.

tl; dr - Eu advogaria para resolver isso com uma abordagem de esgrima integrada em vez de heurísticas

Há algum tempo, estamos investigando a melhor forma de integrar o conceito de esgrima ao k8s devido ao tipo de cenário descrito aqui. Esgrima nem sempre é um conceito popular, mas gosto de pensar em esgrima como uma forma de responder à pergunta: "X vai causar corrupção ou perda de dados?" em uma resposta "Não", permitindo também a recuperação automática dentro de um período de tempo limitado.

Nossa intenção atual é pegar carona em elementos como detector de problema de nó e as APIs de cluster / máquina em andamento para criar uma versão com mais recursos de https://github.com/kubernetes-sigs/cluster-api/blob/master /tools/repair/util/repair.go

Como isso se tornou um tópico, estou incluindo uma descrição mais projeto da cerca do

[*] Em nosso contexto, este tópico também está relacionado às preocupações sobre como garantir que o design seja viável para o metal puro. Isso é principalmente ortogonal ao conceito e à necessidade de cercas, bem como à lógica de recuperação que estamos procurando criar.

Coordenar a existência do objeto pod é o que eu esperava.

+1 deixa o controlador a / d mudo - e reage ao estado do pod.

tl; dr - Eu advogaria para resolver isso com uma abordagem de esgrima integrada em vez de heurísticas

Parece ser a abordagem certa. Melhore a lógica para determinar o estado do nó e atualizar o estado do pod de acordo, e a / d (e outros controladores) podem reagir de acordo.

A questão é: em quanto tempo esse bug será corrigido, se um PR após o outro está sendo mantido / rejeitado com tanta frequência? Este bug é bastante crítico, então IMHO ele merece ser corrigido o mais rápido possível, mesmo que a solução não seja perfeita.

Eu também gostaria de sugerir que provavelmente a maioria dos drivers de volume de rede / distribuído / replicado devem ser capazes de determinar independentemente se um volume é seguro para desconectar de um determinado nó, porque eles "sabem" a quais clientes (nós) ainda estão conectados o servidor / cluster de armazenamento. Portanto, se um nó estiver inativo (ou apenas desconectado), alguns drivers de volume podem fornecer essa informação para k8s. Por favor me corrija se eu estiver errado.

@adampl @yastij @nikopen como uma solução alternativa provisória, é possível escrever um controlador externo que monitora este nó de desligamento e força a exclusão dos pods nesse nó? Está ficando claro que reagir especificamente a essa contaminação de desligamento de nó no controlador de anexação / desconexão é precipitado e não ajudará os pods com configuração de estado, portanto, não é a solução que queremos continuar buscando.

@ msau42 e se for um recurso externo, você quer dizer como um pod rodando em kubernetes que observará as manchas do nó e reagirá de acordo com isso? Como podemos instruir todos a instalá-lo? Ou um novo controlador dentro do kubernetes?

Sim, ele pode ser executado como um pod no kubernetes. A distro / provedor precisaria fornecer instruções sobre como executá-lo.

Seria um problema semelhante se criarmos uma solução alternativa na árvore. Você precisaria instruir os usuários a habilitar o portão de recursos.

@ msau42 @liggitt @ saad-ali - Queremos corrigir isso para 1.12? Se sim, podemos abrir uma exceção para isso e começar a considerar um projeto de despejo baseado em contaminação.

Obrigado por toda a discussão. A correção que propus neste comentário https://github.com/kubernetes/kubernetes/issues/65392#issuecomment -417509512 NÃO é uma separação de força, na verdade.
Quando o nó é manchado com "desligar", temos certeza de que as montagens se foram e os contêineres não estão mais em execução. É seguro para o controlador de nó marcar o status do contêiner e remover informações VolumeInUse do status do nó (observe que o campo VolumeInUse é usado para indicar quais volumes estão montados / montados para evitar a condição de corrida entre o mestre e o kubelet para desanexar enquanto ainda está montado) .
Agora, o controlador attach_detach não precisa de nenhuma mudança. Quando o pod é removido pelo controlador de nó, como o status do contêiner não está mais em execução, o controlador attach_detach primeiro verifica se é seguro desanexá-lo e depois tenta desanexá-lo porque o status do nó mostra que o volume não está mais montado.
Portanto, acho que essa correção é segura.

A proposta que @ msau42 teve também pode ajudar a resolver o problema. Mas pode causar uma condição de corrida durante a exclusão forçada. Se o nó desligado acontecer para reiniciar neste momento. A separação pode ocorrer durante a montagem do volume. Entre em contato se tiver alguma dúvida sobre a correção ou qualquer dúvida. Obrigado!

Quando o nó é manchado com "desligar", temos certeza de que as montagens se foram e os contêineres não estão mais em execução. É seguro para o controlador de nó marcar o status do contêiner e remover informações de VolumeInUse do status do nó

Isso pode ser problemático para conjuntos com estado. Digamos que um pod apoiado por conjuntos com estado esteja em execução no nó X. O nó foi desligado e contaminado. Os contêineres do pod são marcados como "NotRunning" e o volume é desanexado do nó X. Agora, quando o nó X voltar, o pod apoiado por um conjunto com estado não poderá mais ser executado nele. afaict - não haverá novos eventos relacionados ao pod e, portanto, anexar / desconectar o controlador não reconectará o volume de volta.

@ jingxu97 @ dchen1107 e eu

Como solução alternativa de curto prazo, se você realmente precisa desse comportamento, sugerimos a solução de:
1) Tornando o tempo limite de desconexão forçada configurável no controlador A / D. Alguém precisa criar um PR para isso para congelamento de código.
2) Implementar um controlador externo que força a exclusão de pods em um nó que está desligado.

Esteja ciente de que essas duas soluções alternativas podem aumentar o risco de separar volumes quando eles ainda estão montados.

Só para ficar claro, "tornar a desconexão forçada configurável" não fará nada para mudar a lógica da desconexão de volume. Isso só fará com que a separação seja mais rápida quando o pod já estiver excluído.

@ msau42 agora, quando os nós não são mais excluídos do cluster (mudança do provedor de nuvem no comportamento na maioria das nuvens), configurar esse tempo limite de desconexão não importa. Os pods não podem mais se mover. O comportamento é este https://github.com/kubernetes/kubernetes/pull/67977#issuecomment -417233035

Se bem me lembro, o comportamento antigo antes da mudança do provedor de nuvem era que, após o tempo limite de desconexão forçada, ele desconectava a unidade e o pod era capaz de se mover.

Então, sem esse controlador externo, podemos ver alguns tickets de bug sobre isso

O comportamento anterior é que, quando um objeto Node é excluído, o coletor de lixo forçará a exclusão de pods nesse nó. Agora que o objeto Node não é mais excluído, não há nada que force a exclusão de pods. (O controlador de nó despejará pods após 5 minutos sem resposta do kubelet, mas não é uma exclusão forçada). Portanto, esta solução alternativa do controlador externo é imitar esse comportamento semelhante, como se o objeto Node fosse excluído, no entanto, com o risco aumentado de que o Node possa realmente voltar.

Retiro minha recomendação de tornar a desconexão forçada configurável e encurtá-la. Porque isso afetará nossa separação quando o mecanismo de segurança ainda estiver montado, mesmo em cenários normais de terminação de pod.

Portanto, com apenas a solução alternativa do controlador, o volume será removido à força após 6 minutos do pod sendo excluído à força.

Então, parece que:

Shutdown taint + InstanceShutdownByProviderID oferece a habilidade de diferenciar entre Shutdown e Unresponsive kubelets identificando apropriadamente encerramentos, verificando um status 'seguro para deletar / desanexar'.

No entanto, 'ISBPID' está atualmente implementado apenas para AWS e Openstack, com o resto provavelmente não sendo implementado para 1.12 (?).
E os itens acima não podem cobrir o metal puro.

Quanto à sua própria funcionalidade, pode ser tão simples e gracioso quanto iniciar um cordão / dreno, em conjunção com o provedor de nuvem, em sua forma finalizada. Eu acho que é melhor para a mancha de desligamento permanecer o mais simples possível em si mesma, expondo um status sólido e deixando outros atores agirem sobre ele.

@ msau42 Estou pensando no seguinte comportamento para o controlador externo 'temporário':

Caso de desligamento do nó (quando a contaminação é implementada e funcionando):

1. forçar a exclusão de todos os pods após um curto tempo limite (por exemplo, 5 segundos)

Caso de kubelet sem resposta:

1. Capturar evento de kubelet que não responde
2. Confirme se ele permanece sem responder várias vezes por X minutos (por exemplo, status da pesquisa a cada 20 segundos por 4 minutos)
3. Se ainda estiver baixo após o tempo limite máximo, force a exclusão de todos os pods associados a ele.

O acima pode ser relativamente seguro. Se houver algo mais que possa torná-lo mais seguro, seria bom adicioná-lo. Pode começar a trabalhar nisso logo.

Um fail-safe extra personalizado pode ser um pod secundário para pods com volumes ou / e StatefulSets que verifica se o pod principal está ativo / lê-grava o volume, em intervalos. Caso contrário, ele pode falar com o controlador e verificar se é seguro excluir e desanexar. Qualquer sugestão é bem-vinda

Para 1.13 e além, seria ótimo formar uma equipe para entregar uma solução sólida sobre a desconexão de volume em nós descartados por um longo prazo, lidando com a sincronização / utilizando esgrima / outros.

@nikopen

O acima pode ser relativamente seguro

Claro, se o nó perdeu energia, mas também há cenários (que parecem idênticos de dentro do sistema) em que o pod pode estar ativo e gravando no volume conectado. Por exemplo.

• Interrupção ou configuração incorreta da rede, a menos que o kubelet esteja usando o mesmo caminho que o volume E as gravações exijam confirmação de ponta a ponta
• Kubelet cunhado

Um fail-safe extra personalizado pode ser um pod secundário para pods com volumes ou / e StatefulSets que verifica se o pod principal está ativo / lê-grava o volume, em intervalos. Caso contrário, ele pode falar com o controlador e verificar se é seguro excluir e desanexar. Qualquer sugestão é bem-vinda

Se o controlador for local, você poderá alcançá-lo durante uma queda de rede, mas presumivelmente ele não terá nenhum conhecimento adicional para verify that it's safe to delete & detach .

Se o controlador não for local, ele será capaz de fazer a verificação, mas você não conseguirá acessá-lo de dentro do nó enquanto a rede estiver instável.

Implementar um controlador externo que força a exclusão de pods em um nó que está desligado.

@ msau42 @ jingxu97 IIUC, shutdown aqui significa que o nó está contaminado? E quanto aos volumes em nós bare-metal que não são gerenciados por provedores de nuvem?

@NickrenREN - Isso deve ser feito por algum controlador externo.

Portanto, precisamos de uma proposta detalhada e completa para isso.
Algum link de projeto ou proposta para isso? @yastij

@beekhof se 'wedged' kubelet significa kubelet não responsivo, eu já respondi isso em https://github.com/kubernetes/kubernetes/issues/65392#issuecomment -417880760 - se kubelet permanecer sem resposta, os pods deverão migrar de qualquer maneira.

re: interrupção da rede, geralmente, se estiver acontecendo, haverá problemas maiores para resolver.
Mas se o cérebro dividido é o caso do problema, ele deve ser resolvido.

Idealmente, o próprio driver de armazenamento é capaz de fornecer informações 'seguras para desanexar'.
Uma lista de provedores de nuvem e drivers de armazenamento que podem fazer isso seria muito útil.

Em configurações em que isso ainda não é possível, um sidecar local pode lidar com isso como uma funcionalidade adicional em cima do controlador externo principal: se o local / sidecar não for capaz de falar com o controlador + o kubelet está morto + o pod com problema é inativo, em seguida, force a exclusão / autodestruição do pod. As partes de verificação de verificação de 'inatividade' podem incluir alguns requisitos / interfaces para conversar, ou seja, pelo menos alpino para pods com volumes. Esta solução pode ser bastante melhorada.

Quando a maioria dos provedores de nuvem e drivers de armazenamento são capazes de fornecer o status 'seguro para desanexar', a lógica de desanexação segura deve ser mais fácil de ser integrada ao próprio código k8s / CP.

@NickrenREN @ msau42 Pelo que vejo, há muita confusão sobre o defeito de desligamento e de acordo com https://github.com/kubernetes/kubernetes/issues/58635#issuecomment -397771924
InstanceShutdownByProviderID ainda não foi implementado na maioria dos provedores de nuvem, a mancha realmente chegará a 1.12?

Um controlador externo pode funcionar para kubelets indisponíveis, independentemente do status de mancha de desligamento (o que tornaria as coisas mais fáceis, mas ainda precisa de tempo e trabalho para ser devidamente implementado no IIUC).

@nikopen https://github.com/kubernetes/kubernetes/pull/67977#issuecomment -416836342 ele existe hoje em dia em muitos.

azure https://github.com/kubernetes/kubernetes/pull/68033

gce está faltando, mas outros grandes jogadores têm isso

se o kubelet não responder, os pods deverão migrar para outro lugar de qualquer maneira.

@nikopen, mas como você organizaria isso ou confirmaria que ocorreu sem poder falar com o kubelet?

Na maioria dos casos, o k8s pode ativar pods substitutos independentemente, mas os StatefulSets e os pods com volumes persistentes devem esperar até que o kubelet volte ou algo confirme que ele é seguro. Caso contrário, existe um risco muito real de corrupção.

@beekhof Se soubermos que um nó está desligado (contaminado), é sempre seguro desanexá-lo, embora o kubelet não esteja respondendo. O kubelet sem resposta (enquanto o nó não está contaminado quando foi desligado) é um caso diferente que precisa de uma solução mais sofisticada. IMHO esses dois casos devem ser corrigidos separadamente, para que o primeiro não seja bloqueado pelo segundo.

O kubelet sem resposta já é gerenciado pelo controlador do nó, que despeja os pods (não força a exclusão) após 5 minutos.

Não acho que o desligamento do nó pode ser 100% seguro para desconectar um volume, por isso acho que forçar a exclusão de um pod após um curto tempo limite não é seguro. O desligamento do nó é apenas um estado temporário. E se o nó estiver apenas reiniciando e voltar a funcionar rapidamente?

@ msau42 @beekhof @verult

Este problema precisa ser de priority/critical-urgent para permanecer no marco 1,12. Você pode verificar e fazer a triagem?

cc @childsb @ saad-ali

O kubelet sem resposta já é gerenciado pelo controlador do nó, que despeja os pods (não força a exclusão) após 5 minutos.
@ msau42 se o kubelet não estiver respondendo, como os pods podem ser removidos dos nós para não continuar e gravar no armazenamento e corrompê-lo se usado por outro pod em outro nó?

Não acho que o desligamento do nó pode ser 100% seguro para desconectar um volume, por isso acho que forçar a exclusão de um pod após um curto tempo limite não é seguro. O desligamento do nó é apenas um estado temporário. E se o nó estiver apenas reiniciando e voltar a funcionar rapidamente?
um desligamento de nó não deve liberar o PV / PVC. um nó conhecido por ter sido desligado deve permitir forçar a exclusão do pod, liberando o armazenamento?

@ msau42 diferencie entre desligar e reiniciar no nível do provedor de nuvem, ou seja, siga o caminho do provedor de nuvem.

Dê a contaminação de desligamento apenas quando uma VM tiver emitido um sinal claro de 'desligamento'
ou
Pesquise o status da VM por 1m. Não deve estar no 'estado de desligamento' por mais do que isso ao reiniciar.

Um controlador que observa a contaminação de desligamento emite um dreno de nó, acionando também o controlador attachdetach. Isso pode ser no controlador do nó.

O recurso de mancha de desligamento, por definição, pesquisa a lógica externa, por exemplo, provedor de nuvem, para funcionar. Ele só funciona onde 'InstanceShutdownByProviderID' é implementado - atm o taint de desligamento funciona apenas em AWS e OpenStack.

Pode ser muito difícil conceber uma forma segura e abrangente tanto para o bare metal quanto para quaisquer provedores de nuvem semelhantes.

@guineveresaenger, isso não está planejado para ser resolvido em 1.12

@nikopen, o que quero dizer é que você sempre terá uma janela onde o nó pode voltar de um estado de desligamento. Não apenas uma reinicialização, mas o usuário também pode ligá-lo novamente. Portanto, qualquer valor de tempo limite que escolhermos não será livre de corrida.

Para esclarecer, aqui está uma sequência que demonstra a corrida com força excluindo o pod:

1. VM é desligada
2. Taint de desligamento é adicionado ao nó.
3. O controlador vê a mancha de desligamento no nó.
4. VM volta a ficar online e começa a executar pods novamente
5. A força do controlador exclui pods em nós
6. O controlador AD desanexa volumes enquanto o contêiner ainda os tem montados.

@ msau42 você se importaria de removê-lo do marco? Eu posso fazer isso, mas realmente não quero passar pela cabeça de ninguém. :)

Eu acho que deve ser capturado em notas de lançamento de algum tipo. Não tenho certeza de qual é a melhor maneira de fazer isso, mas como antes deste lançamento, o comportamento padrão no Openstack, vSphere e AWS era separar os volumes dos nós de desligamento após este lançamento, isso não será mais o caso. Desanexar no GCE-PD nunca funcionou, mas foi mascarado pela estratégia de implantação do GCE. Aqueles que usam kops para implantar na AWS também não podem ver esse bug, porque kops implanta tudo no ASG e um nó de desligamento é encerrado e substituído automaticamente.

@guineveresaenger eu não tenho permissões de marcos

vamos ver se eu faço ...;)
/ marco claro

@guineveresaenger : você deve ser membro da equipe do github kubernetes / kubernetes-milestone -keepers para definir o marco.

não, eu não.

cc @ saad-ali, @childsb , @tpepper - você poderia remover do marco?

@ msau42 Por favor, corrija-me se eu estiver enganado, mas o controlador de nó que despeja Pods em resposta a um kubelet que não responde não resulta realmente no encerramento dos Pods e / ou seus Volumes se tornam seguros para montar em outro lugar até depois do kubelet (ou sua substituição ) volta. Direito? Portanto, eu discordo que esse caso de uso seja tratado.

@adampl Não há objeção em tratar ambos separadamente, embora pareça que o resultado ainda será precipitado. Então, talvez seja apenas uma abordagem temporária.

@guineveresaenger , @gnufied Concordo que isso não deve

Para esclarecer, aqui está uma sequência que demonstra a corrida com força excluindo o pod:
VM é desligada
Taint de desligamento é adicionado ao nó.
O controlador vê a mancha de desligamento no nó.
VM volta a ficar online e começa a executar pods novamente
A força do controlador exclui pods em nós
O controlador AD desanexa volumes enquanto o contêiner ainda os tem montados.

@ msau42 para evitar a corrida, o controlador não deve remover a mancha de desligamento até após a exclusão forçada. o nó não deve iniciar pods enquanto estiver com defeito de desligamento?

@beekhof correto, o despejo do pod não é uma exclusão forçada de um pod, então o controlador A / D não tentará se desconectar porque o objeto Pod não será atualizado. Acho que em ambos os casos, kubelet sem resposta ou desligamento do nó, você precisa forçar a exclusão dos pods. A diferença é que, em um caso de kubelet sem resposta, realmente não podemos dizer se é seguro desanexar e, em um desligamento de nó, você pode ter uma melhor chance de acertar.

@itamarh, isso requer mudança no kubelet para procurar o defeito de desligamento. E também assume que o controlador que adiciona / remove a contaminação é o mesmo que está forçando a exclusão dos pods. Também pode haver problemas de tempo entre a sincronização de objetos da API Pod e Node que precisam ser investigados.

Se este problema tiver que ser removido do 1.12, então, pelo menos, retire o # 67977 e adicione a lógica para evitar a condição de corrida quando os pods forem reiniciados após o desligamento.

BTW, no caso de volumes RWO de tipos (drivers) que não suportam o modo RWX, a montagem dupla sempre seria rejeitada, então a corrida seria inofensiva, certo? Acho que o problema está apenas em tipos que oferecem suporte a RWX, já que eles não rejeitam montagens duplas não intencionais de volumes RWO (a menos que também estejam de alguma forma cientes do modo desejado, o que eu duvido).

/ marco claro

@adampl os AccessModes ( RWO e RWX ) realmente não afetarão as operações de montagem. Ele é projetado originalmente para correspondência de PVC / PV e, em seguida, é usado para anexar volume (não para montagens de volume).
Precisamos limpar o material de AccessModes também e enviamos um problema antes, https://github.com/kubernetes/kubernetes/issues/67936 , começará a funcionar em breve

@ msau42 @ jingxu97 - Uma das soluções seria diferenciar entre um desligamento e uma reinicialização. Os provedores de nuvem IIRC diferenciam reinicializações de desligamento e acionam uma lógica de despejo apenas se for um desligamento real. Isso poderia resolver o problema de retorno do nó. Em seguida, poderíamos marcar o pod como obsoleto usando PodConditions e montar volumes apenas para pods não obsoletos.

Na verdade, como mencionei acima.

Por exemplo: limpe os pods antes de realmente desligar, de uma maneira gentil, garantindo que os pods tenham sido excluídos.

@nikopen Para desligamento planejado, a maneira elegante é kubectl drain .

O problema é com o nó ou kubelet que não responde. Mesmo a drenagem pode falhar no meio do processo se o nó / kubelet travar ou perder a conexão inesperadamente, então o cluster deve ser capaz de isolar o nó com falha (AKA fencing). IMHO deve ser assim:

1. isolar o nó
2. iniciar o desligamento (se estiver em execução)
3. verificar desligamento
4. forçar a exclusão de todos os pods

Mas deve haver uma maneira de fazer isso em nós bare-metal também.
Portanto, precisamos de uma API para serviços externos gerenciando o status de energia de nós bare-metal.

Concordo com @adampl

O mecanismo de cerca aqui é necessário. Conversamos com @ jingxu97 @rootfs e @ msau42 offline, precisamos colocá-lo fora do kubernetes, pois é difícil consertar completamente as condições de corrida entre os componentes do kubernetes e a mudança potencial pode prejudicar muito o kubernetes.

Para esclarecer, nos preocupamos não apenas com o desligamento do nó, mas também com uma condição desconhecida, uma vez que pode causar divisão do cérebro e escrita dupla. E nós nos importamos não apenas com as instâncias de nó do provedor de nuvem, mas também com nós bare metal.

A implementação pode começar simples e aqui temos alguns clientes de banco de dados que também precisam disso.
Vamos discutir e criar um protótipo, e eles podem fornecer um ambiente de grandes instâncias de banco de dados para verificar a implementação. Enviarei a proposta quando terminar

/ cc @ jingxu97 @ msau42 @orainxiong

/ cc @ddysher

@NickrenREN Acho que a design informal

Um dos itens da minha lista TODO é incorporar o design atualizado à proposta existente, mas gostaria de receber qualquer pessoa interessada em colaborar para entrar em contato ou sugerir alterações antes disso.

/ cc @ jingxu97 @ msau42 @orainxiong @adampl @ddysher

Olá @ jingxu97 , entendi por @ saad-ali que você vai lidar com este PR para a versão 1.13.
Gostaria também de chamar a sua atenção para questões complementares -> https://github.com/kubernetes/kubernetes/issues/68086 e https://github.com/kubernetes/kubernetes/issues/69168 que da mesma forma relacionados com o sujeito.

Ei @ jingxu97 @ saad-ali @ msau42 ,

enquanto estou monitorando os problemas da equipe de lançamento do 1.13,

existe uma estimativa se este e # 68086, # 69168 chegarão à v1.13?

oi @nikopen temos alguma decisão sobre a solução e o plano de lançamento disso?
obrigado.

Eu acredito que @ jingxu97 tem uma proposta que ela fez para resolver isso. Ele requer mudanças no lado do nó, então, idealmente, precisamos de sig-node para pegá-lo.

/ milestone v1.14

@ jingxu97 - podemos sincronizar esta proposta, algum KEP lá fora?

@ jingxu97 , alguns outros caras e eu estamos conversando sobre a implementação offline do Node Fencing, enviaremos a proposta quando estiver pronta

1 em esgrima. Se for dividido em duas categorias de physical & external , podemos fazer com que os nós enviem seus detalhes STONITH na admissão, caso contrário, o provedor de nuvem (ou um provedor STONITH?) Pode fornecer resolução para solicitações de esgrima .

Olá @ jingxu97 @ saad-ali, o congelamento do código para 1.14 chegará em 10 dias. Se não estiver pronto nas próximas 2-3 semanas, sinta-se à vontade para movê-lo para o marco v1.15.

@nikopen - o aprimoramento kubernetes / realces # 719 foi movido de 1.14, este problema também deve ser movido.

Está bem!

/ milestone v1.15

Olá @yastij , como esse problema será resolvido no 1.15? por ter um novo mecanismo de esgrima ou apenas marcar manualmente a mancha para despejo?

obrigado

@ shay-berman - contaremos com a observação da contaminação e a adição de algumas alterações ao kubelet para torná-lo seguro para separar volumes dos nós.

Obrigado pela atualização.
Então, após a correção - o usuário terá que fazer algo manualmente para recuperar os PODs com estado que travaram no nó de trabalho travado?
ou será a decisão automática por k8s?

no modo cloudprovider, não haverá necessidade do usuário operar manualmente. Para configurações locais, os usuários precisarão:

• fornecer um componente externo que faça essa lógica.
• operar manualmente a operação de contaminação / não contaminação

Oi! Estamos iniciando o congelamento de código para 1.15 amanhã EOD. Apenas checando para ver se este problema ainda está planejado para o ciclo de 1,15?

@timmycarr - não está pousando em 1.15

/ marco claro

para ser revivido quando uma nova proposta for lançada

Este problema foi apontado várias vezes. Na verdade, isso prejudica muitos usuários. Os pods parados em estado indisponível por mais de 6 minutos não é uma solução sustentável para manter as cargas de trabalho de produção altamente disponíveis. Eu entendo que a solução final provavelmente não será simples e exigiria mais discussões sobre design. Mas você acha que uma correção menor, tornando ReconcilerMaxWaitForUnmountDuration configurável, é possível até que a resolução final esteja em vigor? Isso ajudaria muito os usuários.

cc @ shay-berman @liggitt

@ alena1108 obrigado por compartilhar sua preocupação. Só quero esclarecer seu cenário, seus pods pertencem a um conjunto de estados, implantação ou outra coisa? Seus pods estão sendo excluídos depois de ficarem indisponíveis por alguns minutos? Obrigado!

@ jingxu97 Já vi isso acontecer em configurações de aws de implantação (volume ebs) e vsphere para nossos usuários. Quando o nó é desligado e fica indisponível, os volumes permanecem no host por 6 minutos e o novo pod não pode ser iniciado no nó íntegro até que o volume antigo seja desconectado.

O stateful pode ser afetado por esse comportamento também. Documentamos os detalhes aqui

@ alena1108 você pode descrever os cenários em que o nó é encerrado sem fazer um cordão e drenar primeiro?

@ msau42 quando o nó é desligado / cai no lado do provedor por vários motivos - um caso de uso muito básico. Quando o administrador não tinha intenção de removê-lo do k8s e passar pelo processo de isolamento / drenagem adequado.

Você pode ser mais específico sobre os tipos de "vários motivos" que existem? Não é óbvio para mim e quero entender esse caso de uso básico.

@ msau42 Só posso falar por experiência própria aqui, mas tenho visto um comportamento como este quando o hardware subjacente de uma VM executando um nó falha. O administrador do cluster nunca tem a oportunidade de isolar / drenar o nó primeiro nesse cenário.

Isso evita que o volume seja reconectado a outro nó, mesmo se o provedor de nuvem souber que a instância está desligada (e, portanto, que o volume definitivamente não está em uso ativo nesse nó), pois, pelo que sei, não há uma mancha de nó que nos permite sinalizar esse status para k8s.

É menos problemático se você tiver escalonamento automático de nó disponível (já que o volume pode ser anexado a outro nó assim que o nó com falha for excluído), mas quando isso não é uma opção, pelo que eu sei, qualquer pods com PVs anexados pode ' t ser reprogramado até que o nó volte a ficar online ou seja totalmente removido do cluster. (Já faz um tempo que não me deparei com isso e olhei para ele, se esse não for mais o caso, eu ficaria feliz em estar errado sobre isso!)

Há um trabalho em andamento em uma nova solução para este problema: https://github.com/kubernetes/enhancements/pull/1116

No entanto, ainda não tenho certeza de como funcionará com clusters fora da nuvem.

@ msau42 As máquinas às vezes falham ...

@adampl obrigado pelo link. Resolver o problema de uma forma ou de outra, mesmo que limitado apenas a nós de provedores de nuvem, seria ótimo. Você sabe para que versão do K8s é direcionado? cc @smarterclayton

@ alena1108 - espero que 1,16

@NickrenREN Oi, alguma informação sobre a proposta de node fencing na nuvem e BM?

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

/ remove-lifecycle stale
/ ciclo de vida congelado