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
Cinco pods, distribuídos em node01 e node02
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.
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
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
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
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
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
kubeadm reset
2. Junte-se novamente ao nó
Executar no nó mestre
kubeadm token create --print-join-command
executar em node02
modprobe br_netfilter
kubeadm join 192.168.148.124:6443 --token 4r4c2u.29r7tm05i6h9nfyv --discovery-token-ca-cert-hash sha256:af6e4d737cbd7e294036d7391a5931fba589942e777811bb6f74b77ccbda3cfc #node02上运行
Ver nó
kubectl get node