[ad_1]
Poluições e tolerâncias são um mecanismo do Kubernetes para controlar como os pods são agendados nos nós do cluster. Corrupções são aplicadas aos nós e atuam como uma barreira repelente contra novos pods. Nós contaminados só aceitarão pods que foram marcados com a tolerância correspondente.
Os poluentes são um dos mecanismos de agendamento mais avançados do Kubernetes. Eles facilitam muitos casos de uso diferentes em que você deseja impedir que os pods acabem em nós indesejados. Neste artigo, você aprenderá o que são contaminações e tolerâncias e como usá-las em seu próprio cluster.
como funciona a programação
Kubernetes é um sistema distribuído em que você pode implantar aplicativos em contêiner (pods) em vários hosts físicos (nós). Quando você cria um novo pod, o Kubernetes deve determinar o conjunto de nós nos quais ele pode ser colocado. É disso que se trata a programação.
O agendador considera muitos fatores diferentes para estabelecer um local adequado para cada pod. Por padrão, um nó que pode fornecer recursos suficientes para atender às solicitações de CPU e memória do pod será selecionado.
No entanto, o nó selecionado não será necessariamente apropriado para sua implantação. Ele pode não ter o hardware necessário ou ser reservado para uso em desenvolvimento. As contaminações de nós são um mecanismo para impor essas restrições, impedindo a atribuição arbitrária de pods a nós.
Casos de uso de corrupção
A coloração de um nó significa que ele começará a repelir pods, forçando o escalonador a considerar o próximo nó candidato. Você pode superar a contaminação definindo uma tolerância correspondente no Pod. Isso fornece um mecanismo para permitir pods específicos no Node.
As corrupções são frequentemente usadas para manter os pods longe de nós reservados para fins específicos. Alguns clusters do Kubernetes podem hospedar vários ambientes, como preparação e produção. Nessa situação, você desejará evitar que implantações temporárias terminem em hardware de produção dedicado.
Você pode obter o comportamento desejado poluindo o nó de produção e definindo uma tolerância correspondente nos pods de produção. Os pods de preparo serão limitados aos outros nós em seu cluster, evitando que eles consumam recursos de produção.
Corrupções também podem ajudar a distinguir entre nós com hardware específico. Os operadores podem implantar um subconjunto de nós com GPUs dedicadas para uso com cargas de trabalho de IA. A poluição desses nós garante que os pods que não precisam da GPU não possam ser agendados neles.
Efeitos da corrupção
Cada mancha de nó pode ter um dos três efeitos diferentes nas decisões de agendamento do Kubernetes:
NoSchedule– Pods que não toleram contaminação não serão agendados no Node. Os pods que já estão agendados para o Node não são afetados, mesmo que não tolerem contaminação.PreferNoSchedule– O Kubernetes evitará a programação de Pods sem tolerância à corrupção. O Pod ainda pode ser programado para o Node como uma opção de último recurso. Isso não afeta os pods existentes.NoExecute– Funciona de forma semelhanteNoScheduleexceto que os pods existentes também são afetados. Os pods sem tolerância serão imediatamente despejados do nó, fazendo com que sejam reprogramados para outros nós do cluster.
a NoExecute O efeito é útil quando você altera a função de um nó que já está executando algumas cargas de trabalho. NoSchedule é mais apropriado se você deseja proteger o nó de receber novos pods, sem interromper as implantações existentes.
manchar um nó
Corrupções são aplicadas a nós usando o kubectl taint domínio. Leva o nome do nó de destino, uma chave e um valor para a contaminação e um efeito.
Aqui está um exemplo de poluir um nó para atribuí-lo a um ambiente específico:
$ kubectl taint nodes demo-node env=production:NoSchedule node/demo-node tainted
Você pode aplicar vários taints a um nó repetindo o comando. O valor da chave é opcional – você pode criar contaminações binárias se omiti-lo:
$ kubectl taint nodes demo-node has-gpu:NoSchedule
Para remover uma mancha aplicada anteriormente, repita o comando, mas adicione um traço (-) para o nome do efeito:
$ kubectl taint nodes demo-node has-gpu:NoSchedule- node/demo-node untainted
Isso removerá a corrupção correspondente, se houver.
Você pode recuperar uma lista de todas as corrupções aplicadas a um nó usando o describe domínio. As manchas serão exibidas na parte superior da saída, após os rótulos e anotações do nó:
$ kubectl describe node demo-node Name: demo-node ... Taints: env=production:NoSchedule ...
Adicionando tolerâncias a pods
O exemplo acima contaminado demo-node com a intenção de reservá-lo para cargas de trabalho de produção. A próxima etapa é adicionar uma tolerância equivalente aos seus pods de produção para que eles possam ser agendados no Node.
As tolerâncias das cápsulas são declaradas no spec.tolerations campo manifesto:
apiVersion: v1
kind: Pod
metadata:
name: api
spec:
containers:
- name: api
image: example.com/api:latest
tolerations:
- key: env
operator: Equals
value: production
effect: NoSchedule
Esta tolerância permite api Pod para agendar nós que têm um env mancha com um valor de production S NoSchedule como o efeito. O pod de amostra agora pode ser programado para demo-node.
Para tolerar corrupções inúteis, use o Exists operador em vez disso:
apiVersion: v1
kind: Pod
metadata:
name: api
spec:
containers:
- name: api
image: example.com/api:latest
tolerations:
- key: has-gpu
operator: Exists
effect: NoSchedule
O Pod agora tolera has-gpu taint, se um valor foi definido ou não.
tolerâncias não são exigir que o pod está programado para um nó contaminado. Este é um equívoco comum em torno de manchas e tolerâncias. O mecanismo diz apenas que um Node não pode hospedar um Pod; não expressa a opinião alternativa de que um Pod deve ser colocado em um Node específico. Corrupções são comumente combinadas com afinidades para atingir esse comportamento bidirecional.
Regras de matchmaking de corrupção e tolerância
Nós corrompidos só recebem pods que toleram todas as suas contaminações. O Kubernetes primeiro descobre as contaminações no nó e, em seguida, filtra as contaminações que são toleradas pelo pod. Os efeitos solicitados pelo conjunto restante de corrupções serão aplicados ao Pod.
Há um caso especial para NoExecute efeito. Os pods que toleram esse tipo de corrupção geralmente permanecerão no nó após a aplicação da corrupção. Você pode modificar esse comportamento para que os pods se desloquem voluntariamente após um certo período de tempo, apesar de tolerar a característica:
apiVersion: v1
kind: Pod
metadata:
name: api
spec:
containers:
- name: api
image: example.com/api:latest
tolerations:
- key: env
operator: Equals
value: production
effect: NoExecute
tolerationSeconds: 900
Um nó que hospeda este pod, mas é posteriormente contaminado com env=production:NoExecute permitirá que o Pod permaneça presente por até 15 minutos após a aplicação da contaminação. O Pod será então despejado apesar de ter o NoExecute tolerância.
corrupções automáticas
O plano de controle do Kubernetes polui automaticamente os nós para remover pods e evitar o agendamento quando ocorre a contenção de recursos. manchas como node.kubernetes.io/memory-pressure S node.kubernetes.io/disk-pressure isso significa que o Kubernetes está impedindo o Node de receber novos Pods porque não tem recursos suficientes.
Outras manchas comumente aplicadas incluem node.kubernetes.io/not-readyquando um novo nó não aceita pods e node.kubernetes.io/unschedulable. O último é aplicado a nós isolados para interromper todas as atividades de agendamento de pods.
Essas contaminações implementam os sistemas de despejo e gerenciamento de nós do Kubernetes. Normalmente, você não precisa pensar sobre eles e não precisa gerenciar essas corrupções manualmente. Se você os vir em um nó, é porque o Kubernetes os aplicou em resposta a mudanças nas condições ou a outro comando que você emitiu. É possível criar tolerâncias de pod para essas contaminações, mas isso pode levar ao esgotamento de recursos e a um comportamento inesperado.
Resumo
Contaminações e tolerâncias são um mecanismo para repelir pods de nós individuais do Kubernetes. Eles ajudam a evitar resultados de agendamento indesejados, impedindo que os pods sejam atribuídos automaticamente a nós arbitrários.
A poluição não é o único mecanismo que fornece controle sobre o comportamento de programação. Afinidades de pod e afinidades anti-pod são uma técnica relacionada para restringir os nós que podem receber um pod. A afinidade também pode ser definida em um nível entre os pods, permitindo que você tome decisões de agendamento com base em quais pods já estão sendo executados em um nó. Você pode combinar afinidade com intolerâncias e tolerâncias para configurar regras de agendamento avançadas.
[ad_2]
