Balanceando a Disponibilidade e o Custo do Serviço ao Reiniciar Nós Gerenciados em Pools de Nós

Descubra como equilibrar a disponibilidade e o custo do serviço ao reiniciar nós gerenciados em pools de nós que você criou usando o Kubernetes Engine (OKE).

Ao reiniciar nós gerenciados em pools de nós para substituir volumes de inicialização ou para encerrar e substituir nós, o Kubernetes Engine cancela automaticamente os nós existentes para torná-los indisponíveis e drena os nós (usando as definições de Cordon e dreno especificadas para o pool de nós).

Você pode personalizar o comportamento do Kubernetes Engine para atender aos seus próprios requisitos de disponibilidade e custo do serviço da seguinte forma:

• Ao substituir volumes de inicialização e ao encerrar e substituir nós, você pode especificar o número de nós a serem indisponíveis durante a operação (conhecido como Máximo indisponível ou maxUnavailable para abreviar). Quanto maior o número de nós que você permite ficar indisponível, mais nós o Kubernetes Engine poderá atualizar em paralelo sem aumentar os custos. No entanto, quanto maior o número de nós que você permite ficar indisponível, mais disponibilidade de serviço poderá ser comprometida.
• Ao encerrar e substituir nós, você pode especificar o número de nós adicionais a serem permitidos temporariamente durante a operação de atualização (conhecida como Surgimento máximo ou maxSurge para abreviar). Quanto maior o número de nós adicionais que você permite, mais nós o Kubernetes Engine pode atualizar em paralelo sem comprometer a disponibilidade do serviço. No entanto, quanto maior o número de nós adicionais que você permitir, maior o custo.

Para maxUnavailable e maxSurge, você pode especificar o número permitido de nós como um inteiro ou como uma porcentagem do número de nós mostrados na propriedade Contagem de nós do pool de nós na Console (a propriedade Tamanho do pool de nós na API).

Ao encerrar e substituir nós, se você não especificar explicitamente os números permitidos para nós adicionais (maxSurge) e nós indisponíveis (maxUnavailable), o seguinte será aplicado:

• Se você não especificar um valor para maxSurge ou maxUnavailable, o padrão de maxSurge será 1 e o padrão de maxUnavailable será 0.
• Se você especificar apenas um valor para maxSurge, maxUnavailable assumirá como padrão 0.
• Se você especificar apenas um valor para maxUnavailable, maxSurge assumirá como padrão 1.
• Não é possível especificar 0 como o número permitido para nós adicionais (maxSurge) e nós indisponíveis (maxUnavailable).

Ao substituir volumes de inicialização, se você não especificar explicitamente um número permitido para nós indisponíveis (maxUnavailable), o seguinte será aplicado:

• Se você não especificar um valor para maxUnavailable, maxUnavailable assumirá como padrão 1.
• Não é possível especificar 0 como o número permitido para maxUnavailable.

Observe o seguinte:

• No final da operação, o número de nós no pool de nós retorna ao número especificado pela propriedade Contagem de nós do pool de nós mostrada na Console (a propriedade Tamanho do pool de nós na API).
• Ao encerrar e substituir nós, se você especificar um valor para maxSurge durante a operação, sua tenancy deverá ter cota suficiente para o número de nós adicionais que você especificar.
• Quando você especifica um valor para maxUnavailable, se o pool de nós não puder tornar esse número de nós indisponíveis (por exemplo, devido a um orçamento de interrupção de pod), a operação falhará.
• Se você informar uma porcentagem como o valor de maxUnavailable, o Kubernetes Engine arredondará a porcentagem para o número inteiro mais próximo ao calcular o número permitido de nós.
• Ao atualizar pools de nós grandes, esteja ciente de que os valores especificados para maxUnavailable podem resultar em tempos de ciclo inaceitavelmente longos. Por exemplo, se você especificar 1 como o valor de maxUnavailable ao reiniciar os nós de um pool de nós com 1000 nós, o Kubernetes Engine poderá levar vários dias para reiniciar todos os nós do pool de nós. Se a operação de ciclo do nó não for concluída em até 30 dias, o status da solicitação de serviço associada será definido como Com falha. Envie outra solicitação de ciclo de nó para retomar a operação.
• Ao reiniciar nós gerenciados em um pool de nós para reduzir o pool de nós, lembre-se de que o número de nós no pool de nós pode ser reduzido para o número especificado como o valor de maxUnavailable. Como resultado, as operações subsequentes podem reduzir o número de nós disponíveis abaixo do que você pretendia, comprometendo a disponibilidade do serviço e impactando as cargas de trabalho. Nessas situações, prossiga com cuidado e considere reduzir o valor maxUnavailable.