1
votes

Le pool de nœuds provisionné automatiquement n'est pas nettoyé

J'ai un cluster Kubernetes avec le provisionnement automatique activé sur GKE.

$ kubectl get nodes
NAME                                                  STATUS   ROLES    AGE   VERSION
gke-some-name-default-pool-5003d6ff-pd1p        Ready    <none>   21h   v1.13.11-gke.14
gke-some-name-nap-n1-highcpu-8--585d94be-vbxw   Ready    <none>   21h   v1.13.11-gke.14

$ kubectl get deployments
No resources found in default namespace.

$ kubectl get events
No resources found in default namespace.

J'ai exécuté un déploiement qui ne cadrerait pas avec le nœud existant (qui a 1 processeur). p >

kubectl delete deployment say-lol

L'auto-provisioner a correctement détecté qu'un nouveau pool de nœuds était nécessaire, a créé un nouveau cluster et a commencé à exécuter le nouveau déploiement. Cependant, il n'a pas pu le supprimer car il n'était plus nécessaire.

kubectl run say-lol --image ubuntu:18.04 --requests cpu=4 -- bash -c 'echo lolol && sleep 30'

Une fois que tous les pods ont disparu, le nouveau cluster est resté en place inactif pendant plus de 20 heures.

gcloud beta container clusters create "some-name" --zone "us-central1-a" \
  --no-enable-basic-auth --cluster-version "1.13.11-gke.14" \
  --machine-type "n1-standard-1" --image-type "COS" \
  --disk-type "pd-standard" --disk-size "100" \
  --metadata disable-legacy-endpoints=true \
  --scopes "https://www.googleapis.com/auth/devstorage.read_only","https://www.googleapis.com/auth/logging.write","https://www.googleapis.com/auth/monitoring","https://www.googleapis.com/auth/servicecontrol","https://www.googleapis.com/auth/service.management.readonly","https://www.googleapis.com/auth/trace.append" \
  --num-nodes "1" --enable-stackdriver-kubernetes --enable-ip-alias \
  --network "projects/default-project/global/networks/default" \
  --subnetwork "projects/default-project/regions/us-central1/subnetworks/default" \
  --default-max-pods-per-node "110" \
  --enable-autoscaling --min-nodes "0" --max-nodes "8" \
  --addons HorizontalPodAutoscaling,KubernetesDashboard \
  --enable-autoupgrade --enable-autorepair \
  --enable-autoprovisioning --min-cpu 1 --max-cpu 40 --min-memory 1 --max-memory 64

Pourquoi ne nettoie-t-il pas le coûteux pool de nœuds?

google-cloud-platform kubernetes google-kubernetes-engine

0 commentaires

3 Réponses :

1
votes

"Lors de la réduction, l'autoscaler du cluster respecte une période de résiliation progressive de 10 minutes pour replanifier les pods du nœud sur un nœud différent avant de forcer l'arrêt du nœud.

Il arrive parfois que l'autoscaler de cluster ne puisse pas être réduit complètement et qu'un nœud supplémentaire existe après la réduction. Cela peut se produire lorsque les pods système requis sont planifiés sur différents nœuds, car il n’existe aucun déclencheur pour aucun de ces Pods à déplacer vers un autre nœud ."
Veuillez vérifier ceci link" J'ai quelques nœuds avec une faible utilisation, mais ils ne sont pas réduits. Pourquoi? ». Pour contourner cette limitation, vous pouvez configurer un budget de perturbation du pod . < / p>

2 commentaires

Existe-t-il un moyen d'indiquer à l'approvisionneur automatique de créer un cluster qui n'exécutera jamais de pods système? Peut-être avec des teintures?

Non ce n'est pas possible. Parce que les DaemonSets déploient des tâches d'arrière-plan en cours que vous devez exécuter sur tous ou certains nœuds [1]. Ce document [2] clarifie le provisionnement automatique des nœuds qui crée des pools de nœuds de nœuds avec des étiquettes et des teintes. [1] cloud.google.com/kubernetes-engine/docs/concepts /… [2] cloud .google.com / kubernetes-engine / docs / how-to /…

0
votes

Je me reproduisais sur mes deux clusters et j'ai découvert que le coupable était étroitement lié au pod kube-dns. Sur le cluster 1, pour le nœud mis à l'échelle, il n'y avait pas de pod kube-dns et une réduction s'est produite après la suppression de say-lol . Sur le cluster 2, à cause du pod kube-dns, le nœud secondaire n'a pas été réduit.

Suite à cela doc / Comment définir les PDB sur permettre à CA de déplacer les pods kube-system?

NAME           MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
kube-dns-pdb   N/A             1                 1                     28m

J'ai créé un pdb pour permettre la perturbation du pod kube-dns permettant ainsi une réduction d'échelle. Vous pouvez vérifier si les perturbations sont autorisées en exécutant

kubectl get pdb -n kube-system

Les perturbations autorisées doivent avoir une valeur non nulle pour que le processus fonctionne.

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: kube-dns-pdb
  namespace: kube-system
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      k8s-app: kube-dns

0 commentaires

2
votes

En plus de la réponse acceptée, il existe une approche utilisant des teintes . Si le pod non planifiable comporte des tolérances, le provisionneur automatique créera un nœud dans le nouveau pool de nœuds avec des teintes correspondantes ( voir la documentation ). Étant donné que les nouveaux nœuds sont corrompus, les autres pods ne fonctionneront pas sur eux et les empêcheront de se réduire. Je trouve cette approche plus simple et plus facile à comprendre que l’approche PDB.

0 commentaires