Migração de remoção de pod K8s e manutenção de nó de nó

Este artigo é baseado na versão k8s-v1.18.0, consulte https://cloud.tencent.com/developer/article/1552452.

1. Descrição ambiental

Nome da CPU ip versão do sistema versão docker
mestre 192.168.148.124 CentOS 7.6.1810 19.03.9
node01 192.168.148.125 CentOS 7.6.1810 19.03.9
node02 192.168.148.126 CentOS 7.6.1810 19.03.9

Dois, fundo

Quando o nó do nó executa operações como patch e atualizações do sistema operacional, ele precisa ser desligado para manutenção, que envolve remoção e migração do pod. Este artigo apresentará todo o processo de manutenção do nó em detalhes.

Três, introdução pdb

  • pdb é a abreviatura de poddisruptionbudgets, o que significa proteção de despejo ativa; sem pdb, quando a manutenção do nó é realizada, se vários pods de um determinado serviço estiverem no nó, o tempo de inatividade do nó pode causar interrupção ou degradação do serviço. Por exemplo, um serviço tem 5 pods, e o mínimo de 3 pods pode garantir a qualidade do serviço, caso contrário, ele causará uma resposta lenta e outros efeitos. Neste momento, os 4 pods do serviço estão em node01. Se node01 for encerrado para manutenção, apenas um pod pode servir externamente normalmente, e a resposta normal do serviço será afetada durante o processo de migração dos 4 pods do node01.
  • O pdb pode garantir que não menos do que um certo número de pods sejam executados durante a manutenção do nó, mantendo assim a qualidade do serviço.

Pronto para trabalhar

1. Crie um novo pod

cd /root/pkg/eg/
kubectl create deployment nginx1.18 --image=nginx:1.18 --dry-run -o yaml > nginx.yml
cat nginx.ym
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx1.18
  name: nginx1.18
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx1.18
  strategy: {
    
    }
  template:
    metadata:
      labels:
        app: nginx1.18
    spec:
      containers:
      - image: nginx:1.18
        name: nginx
kubectl apply -f nginx.yml

Insira a descrição da imagem aqui
Cinco pods, distribuídos em node01 e node02
Insira a descrição da imagem aqui

2. Crie um novo pdb

cd /root/pkg/eg
cat pdb-nginx.yaml
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: pdb-nginx
spec:
  minAvailable: 4
  selector:
    matchLabels:
      app: nginx1.18

Crie um novo pdb-nginx.yml, Label Selector e implantação são ambos app: nginx1.18, minAvailable: 4 significa que há pelo menos 4 pods nginx sobreviventes.
Insira a descrição da imagem aqui

Quatro, manutenção de nós

Este artigo apresenta a manutenção do nó node02 como um exemplo

1. Defina o nó como não programável

kubectl cordon node02

Insira a descrição da imagem aqui
Defina node02 como não programável. Verifique o status de cada nó e encontre o node02 SchedulingDisabled. Nesse momento, o mestre não agendará novos pods para este nó, mas o pod em node02 ainda está funcionando normalmente.

2. Expulsar pods no nó

kubectl drain node02 --delete-local-data --ignore-daemonsets --force

Insira a descrição da imagem aqui
Insira a descrição da imagem aqui
Insira a descrição da imagem aqui
Descrição do parâmetro:

  • --Delete-local-data: exclui mesmo se o pod usar emptyDir;
  • --Ignore-daemonsets: ignora o pod do controlador deamonset.Se não for ignorado, o pod controlado pelo controlador deamonset pode ser reiniciado neste nó imediatamente após ser excluído, que se tornará um loop infinito;
  • --Force: sem o parâmetro force, ele excluirá apenas o pod criado por ReplicationController, ReplicaSet, DaemonSet, StatefulSet ou Job no NODE. Depois de adicioná-lo, ele também excluirá o "pod de streaking" (não vinculado a nenhum controlador de replicação )

Pode-se ver que apenas um pod é migrado ao mesmo tempo, e sempre há 4 pods que fornecem serviços externos. Isso novamente verifica se apenas um pod é migrado ao mesmo tempo, e o serviço nginx sempre tem 4 pods que fornecem serviços externos.

3. Fim da manutenção

kubectl uncordon node02

Insira a descrição da imagem aqui
Depois que a manutenção terminar, defina o nó node02 para um estado planejável novamente.

Cinco, realocação de pod

Parece não haver uma boa maneira de realocar o pod. Aqui, usamos delete e rebuild para realocar.

kubectl get po -o wide
kubectl delete pod nginx1.18-7646b89d65-7klpv nginx1.18-7646b89d65-ddn9p

Insira a descrição da imagem aqui
Nos picos baixos do negócio, nginx1.18-7646b89d65-7klpv e nginx1.18-7646b89d65-ddn9p, porque os pods em node02 foram removidos antes, o uso de recursos é menor neste momento, então quando o pod é reconstruído , o nó será agendado para concluir a recuperação do pod.

Seis, exclusão de nó

1. Exclua o nó

Um determinado nó nó pode ser excluído durante a operação real e processo de manutenção. Este artigo ainda usa o nó 02 como um exemplo para apresentar como excluir um nó.

kubectl cordon node02
kubectl drain node02 --delete-local-data --ignore-daemonsets --force 
kubectl delete node node02

Insira a descrição da imagem aqui
Insira a descrição da imagem aqui

kubeadm reset

Insira a descrição da imagem aqui

2. Junte-se novamente ao nó

Executar no nó mestre

kubeadm token create --print-join-command  

Insira a descrição da imagem aqui
executar em node02

modprobe br_netfilter  
kubeadm join 192.168.148.124:6443 --token 4r4c2u.29r7tm05i6h9nfyv     --discovery-token-ca-cert-hash sha256:af6e4d737cbd7e294036d7391a5931fba589942e777811bb6f74b77ccbda3cfc #node02上运行

Insira a descrição da imagem aqui
Ver nó

kubectl get node

Insira a descrição da imagem aqui

Acho que você gosta

Origin blog.csdn.net/weixin_44729138/article/details/112603786
Recomendado
Clasificación