Início / server / Perguntas / 1002886
Accepted
tacos_tacos_tacos
Asked: 2020-02-13 19:15:34 +0800 CST

O pool de nós do Kubernetes não será dimensionado automaticamente para 0 nós

  • 772

Eu tenho uma carga de trabalho bastante cara que alguns colegas precisam executar às vezes durante a semana (não em nenhum tipo de cronograma definido). Eu uso o Google Cloud Kubernetes.

Ele consiste em três statefulsets, cada um com uma réplica.

Eu os instruí sobre como "ligar" e "desligar". Para ativá-lo, eles dimensionam cada statefulset para 1 réplica. Para desativá-lo, eles dimensionam cada statefulset para 0 réplicas.

Originalmente, eu tinha um único pool de nós de escalonamento automático com um tamanho padrão de três nós (os statefulsets consomem quase um nó inteiro de CPU e RAM). Observei que, mesmo depois de reduzir para 0, pelo menos um (e às vezes dois) nós permaneceriam após uma ou duas horas. Eu esperava que eventualmente todos os nós morressem, mas isso não acontece.

Percebi que os nós em execução ainda tinham alguns pods, apenas em um namespace diferente. Os pods restantes estão todos no kube-systemnamespace, exceto um no custom-metricsnamespace.

Então pensei, ok - talvez haja outros serviços que o Kubernetes deseja executar mesmo quando não há cargas de trabalho/pods definidos pelo usuário. Então, criei outro pool de nós, com um único nó muito pequeno, mas adequado. Esse nó é grande o suficiente para executar tudo o que o Kubernetes relata que está sendo executado nesses defaultnamespaces.

Depois que o novo pool de nós estava sendo executado com um nó, continuei a redimensionar manualmente o pool de nós original para 0. Tudo bem. Eu esperava neste ponto que eu tivesse um pool de nós de "sistema" para executar kube-systeme outras coisas, e um pool de nós de "usuário" para executar minhas próprias coisas.

Então, para o meu próximo teste, desta vez eu apenas dimensionei uma réplica statefulset. Eventualmente, um nó ficou online e o pod statefulset estava em execução/pronto. Eu então reduzi para 0 novamente e esperei... e esperei... e o nó não foi embora.

O que é necessário para fazer com que o pool de nós de escalonamento automático alcance 0 nós? Claramente estou faltando algo (ou mais do que algo), mas tive dificuldade em encontrar informações sobre o que é necessário para acionar o dimensionador de nós para reduzir o tamanho de um pool de nós para 0.

Qualquer conselho é apreciado.

informação adicional

Quando olho para o que está sendo executado no nó no pool de nós, quero ir para 0, eis o que vejo

  Namespace                  Name                                                   CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                                                   ------------  ----------  ---------------  -------------  ---
  kube-system                fluentd-gcp-v3.1.1-mfkxf                               100m (0%)     1 (3%)      200Mi (0%)       500Mi (0%)     28m
  kube-system                kube-proxy-gke-tileperformance-pool-1-14d3671d-jl76    100m (0%)     0 (0%)      0 (0%)           0 (0%)         28m
  kube-system                prometheus-to-sd-htvnw                                 1m (0%)       3m (0%)     20Mi (0%)        20Mi (0%)      28m

Se eu tentar draino nó, ele reclama que eles são gerenciados via DaemonSet, então eu poderia forçá-lo, mas obviamente estou tentando não ter que intervir manualmente de forma alguma.

Hackear

Para que o autoescalador "funcione" e reduza o tamanho para 0, adicionei temporariamente um nodeSelectora todas as kube-systemimplantações para que elas sejam atribuídas a um pool separado para kube-systemcoisas. Mas tem que haver uma maneira melhor, certo?

kubernetes google-kubernetes-engine autoscaling

2 respostas

  1. O autoescalador não reduzirá seu pool de nós para 0.

    Observação: se você especificar um mínimo de zero nós, um pool de nós inativos poderá ser reduzido completamente. No entanto, pelo menos um nó deve estar sempre disponível no cluster para executar os pods do sistema.

    -- Google Cloud: escalonador automático de cluster de mecanismo do Kubernetes

    No entanto, o autoescalador de cluster não pode reduzir completamente para zero um cluster inteiro. Pelo menos um nó deve estar sempre disponível no cluster para executar os pods do sistema. Então você precisa manter pelo menos um nó. Mas isso não significa que você precisa manter um nó caro ocioso.

    -- Medium.com: dimensione seu cluster kubernetes para quase zero com o gke autoscaler

    Você pode reduzir explicitamente seu pool de nós para zero (0) com o comando:

    $ gcloud container clusters resize CLUSTER_NAME --node-pool NAME_OF_THE_POOL --num-nodes 0

    Mas esteja ciente de que essa abordagem terá uma desvantagem.

    Imagine uma situação em que:

    • Você reduz o cluster para zero nós com o comando acima
    • Você cria uma carga de trabalho no cluster que tem zero nós

    O Autoscaler não poderá aumentar um número de nós de zero . Não terá meios para saber se são necessários recursos adicionais. Os pods que estavam sendo executados kube-systemnesses nós eram essenciais para determinar se outro nó é necessário.

    Há um artigo com caso de uso semelhante ao seu. Dê uma olhada: Medium.com: dimensione seu cluster kubernetes para quase zero com o gke autoscaler

    Outra maneira de fazer isso é com orçamentos de interrupção de pods. Por favor, dê uma olhada nos recursos abaixo:

    Possíveis motivos que podem impedir que o autoescalador de cluster remova um nó:

    • Pods com PodDisruptionBudget restritivo.
    • Pods do sistema Kube que:
    • Pods que não são apoiados por um objeto de controlador (portanto, não são criados por implantação, conjunto de réplicas, trabalho, conjunto com estado etc.).
    • Pods com armazenamento local.
    • Pods que não podem ser movidos para outro lugar devido a várias restrições (falta de recursos, seletores ou afinidade de nós não correspondentes, antiafinidade correspondente etc.)
    • Pods que têm o seguinte conjunto de anotações: "cluster-autoscaler.kubernetes.io/safe-to-evict": "false"

    A menos que o pod tenha a seguinte anotação (suportada no CA 1.0.3 ou posterior):

    "cluster-autoscaler.kubernetes.io/safe-to-evict": "true"

    -- Github.com: Kubernetes autoscaler: quais tipos de pods podem impedir que o ca remova um nó

    A CA não remove nós subutilizados se estiverem executando pods que não devem ser despejados

    Outros possíveis motivos para não reduzir:

    • o grupo de nós já tem o tamanho mínimo,
    • houve uma tentativa fracassada de remover esse nó específico, caso em que o Cluster Autoscaler aguardará 5 minutos extras antes de considerá-lo para remoção novamente,

    -- Github.com: Eu tenho alguns nós com baixa utilização, mas eles não são reduzidos por que

    • 2
  2. Best Answer

    No GKE 1.18, meus experimentos mostram que eu teria que adicionar uma mancha de nó para que o pool de nós pudesse ser reduzido a zero:

    $ gcloud container node-pools create ... \
      --min-nodes 0 \
      --max-nodes 2 \
      --node-taints=...  # Without a taint, my node pool won't scale down to zero somehow.
    • 1

relate perguntas