Je joue avec GitOps et ArgoCD dans Redhat Openshift. Mon objectif est de basculer un nœud de travail vers un nœud infra.
Je veux faire cela avec des fichiers YAML descriptifs, et PAS manuellement en utilisant la ligne de commande (c'est facile avec le nœud d'étiquette kubectl ...)
Afin de faire du nœud un nœud infra, je veux ajouter une étiquette "infra" et en retirer l'étiquette "worker". Avant, l'objet ressemble à ceci (étiquettes non pertinentes omises):
apiVersion: v1 kind: Node metadata: labels: node-role.kubernetes.io/worker: "" name: node6.example.com spec: {}
Après avoir appliqué un fichier YAML, il est censé ressembler à ça:
apiVersion: v1 kind: Node metadata: labels: node-role.kubernetes.io/infra: "" name: node6.example.com spec: {}
4 Réponses :
vous pouvez supprimer le libellé avec
kubectl label node node6.example.com node-role.kubernetes.io/infra-
que vous pouvez exécuter à nouveau kubectl apply
avec le nouveau libellé.
Vous serez opérationnel.
Je dirais que ce n'est pas possible de faire avec kubectl apply
, au moins j'ai essayé et je n'ai pas trouvé d'informations à ce sujet.
Comme @Petr Kotas l'a mentionné, vous pouvez toujours utiliser p>
from pprint import pprint from kubernetes import client, config config.load_kube_config() client.configuration.debug = True api_instance = client.CoreV1Api() body = { "metadata": { "labels": { "label-name": None} } } api_response = api_instance.patch_node("minikube", body) print(api_response)
Mais je vois que vous cherchez autre chose
Je veux faire cela avec des fichiers YAML descriptifs, et PAS manuellement en utilisant la ligne de commande (c'est facile avec le nœud d'étiquette kubectl ...)
Alors peut-être que la réponse pourrait être d'utiliser des clients API, par exemple python ? J'ai trouvé cet exemple ici , réalisé par @Prafull Ladha
Comme déjà mentionné, corrigez l'exemple kubectl pour supprimer l'étiquette, mais il n'est pas fait mention de la suppression des étiquettes à l'aide de clients API. si vous souhaitez supprimer l'étiquette à l'aide de l'API, vous devez fournir un nouveau corps avec le
labelname: None
, puis appliquer un patch à ce corps au nœud ou au pod. J'utilise l'API client python de kubernetes à des fins d'exemple
kubectl label node node6.example.com node-role.kubernetes.io/infra-
J'ai réussi à modifier une étiquette de nœud dans mon cluster Kubernetes (créé à l'aide de kubeadm) à l'aide de kubectl replace
et kubectl apply
.
Obligatoire: Si la configuration de votre nœud a été modifiée manuellement à l'aide d'une commande impérative telle que kubectl label
, il est nécessaire de corriger l'annotation last-applied-configuration
à l'aide de la commande suivante (remplacer node2 avec le nom de votre nœud) :
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
Remarque: Cela fonctionne de la même manière avec tous les types d'objets Kubernetes (avec un peu conséquences différentes. Vérifiez toujours les résultats).
Note2 : L'argument --export
pour kubectl get
est obsolète, et il fonctionne bien sans lui, mais si vous utilisez-la, l'annotation last-applied-configuration
semble beaucoup plus courte et plus facile à lire.
Sans appliquer la configuration existante, la prochaine commande kubectl apply
ignorera tous les champs qui ne sont pas présents dans l'annotation last-applied-configuration
.
L'exemple suivant montre que comportement :
# Check the original label ( last filter removes last applied config annotation line) $ kubectl get node node2 -o yaml | grep node-role | grep -v apiVersion node-role.kubernetes.io/infra: "" # Replace the label using kubectl replace syntax $ kubectl get node node2 -o yaml | sed 's@node-role.kubernetes.io/infra: ""@node-role.kubernetes.io/worker: ""@' | kubectl replace -f - node/node2 replaced # check the new state of the label $ kubectl get node node2 -o yaml | grep node-role | grep -v apiVersion node-role.kubernetes.io/worker: "" # Replace the label using kubectl apply syntax $ kubectl get node node2 -o yaml | sed 's@node-role.kubernetes.io/worker: ""@node-role.kubernetes.io/infra: ""@' | kubectl apply -f - node/node2 configured # check the new state of the label $ kubectl get node node2 -o yaml | grep node-role | grep -v apiVersion node-role.kubernetes.io/infra: "" # Remove the label from the node ( for demonstration purpose) $ kubectl get node node2 -o yaml | sed 's@node-role.kubernetes.io/infra: ""@@' | kubectl apply -f - node/node2 configured # check the new state of the label $ kubectl get node node2 -o yaml | grep node-role | grep -v apiVersion # empty output
Vérifions ce qui s'est passé avec l'étiquette node-role.kubernetes.io/santa
si j'essaye pour remplacer le worker par infra et supprimer santa , ( worker est présent dans l'annotation): p >
kubectl get node node2 -o yaml | sed 's@node-role.kubernetes.io/worker: ""@node-role.kubernetes.io/infra: ""@' | sed 's@node-role.kubernetes.io/santa: ""@@'| kubectl diff -f - diff -u -N /tmp/LIVE-107488917/v1.Node..node2 /tmp/MERGED-924858096/v1.Node..node2 --- /tmp/LIVE-107488917/v1.Node..node2 2020-04-08 18:01:55.776699954 +0000 +++ /tmp/MERGED-924858096/v1.Node..node2 2020-04-08 18:01:55.792699954 +0000 @@ -18,8 +18,7 @@ kubernetes.io/arch: amd64 kubernetes.io/hostname: node2 kubernetes.io/os: linux - node-role.kubernetes.io/santa: "" # <-- removed - node-role.kubernetes.io/worker: "" # <-- removed + node-role.kubernetes.io/infra: "" # <-- created name: node2 resourceVersion: "60978298" selfLink: /api/v1/nodes/node2 exit status 1
Après avoir corrigé l'annotation, kubectl apply
fonctionne assez bien en remplaçant et en supprimant les étiquettes:
kubectl get node node2 -o yaml | sed 's@node-role.kubernetes.io/worker: ""@node-role.kubernetes.io/infra: ""@' | sed 's@node-role.kubernetes.io/santa: ""@@'| kubectl diff -f - diff -u -N /tmp/LIVE-380689040/v1.Node..node2 /tmp/MERGED-682760879/v1.Node..node2 --- /tmp/LIVE-380689040/v1.Node..node2 2020-04-08 17:20:18.108809972 +0000 +++ /tmp/MERGED-682760879/v1.Node..node2 2020-04-08 17:20:18.120809972 +0000 @@ -18,8 +18,8 @@ kubernetes.io/arch: amd64 kubernetes.io/hostname: node2 kubernetes.io/os: linux + node-role.kubernetes.io/infra: "" # <-- created node-role.kubernetes.io/santa: "" # <-- ignored - node-role.kubernetes.io/worker: "" # <-- removed name: node2 resourceVersion: "60973814" selfLink: /api/v1/nodes/node2 exit status 1
Voici quelques autres exemples:
kubectl get node node2 -o yaml | grep node-role {"apiVersion":"v1","kind":"Node","metadata":{"annotations":{"flannel.alpha.coreos.com/backend-data":"{\"VtepMAC\":\"46:c6:d1:f0:6c:0a\"}","flannel.alpha.coreos.com/backend-type":"vxlan","flannel.alpha.coreos.com/kube-subnet-manager":"true","flannel.alpha.coreos.com/public-ip":"10.156.0.11","kubeadm.alpha.kubernetes.io/cri-socket":"/var/run/dockershim.sock","node.alpha.kubernetes.io/ttl":"0","volumes.kubernetes.io/controller-managed-attach-detach":"true"},"creationTimestamp":null, "labels":{ "beta.kubernetes.io/arch":"amd64", "beta.kubernetes.io/os":"linux", "kubernetes.io/arch":"amd64", "kubernetes.io/hostname":"node2", "kubernetes.io/os":"linux", "node-role.kubernetes.io/worker":""}, # <--- important line "name":"node2","selfLink":"/api/v1/nodes/node2"},"spec":{"podCIDR":"10.244.2.0/24"},"status":{"daemonEndpoints":{"kubeletEndpoint":{"Port":0}},"nodeInfo":{"architecture":"","bootID":"","containerRuntimeVersion":"","kernelVersion":"","kubeProxyVersion":"","kubeletVersion":"","machineID":"","operatingSystem":"","osImage":"","systemUUID":""}}} node-role.kubernetes.io/santa: "" node-role.kubernetes.io/worker: ""
Vous pouvez voir l'avertissement suivant lorsque vous utilisez kubectl apply -f
sur la ressource créée à l'aide de commandes impératives comme kubectl create
ou kubectl expose
pour la première fois:
kubectl get node node2 -o yaml | kubectl apply -f -
Dans ce cas, last-applied-configuration code> l'annotation sera créée avec le contenu du fichier utilisé dans
commande. Il peut ne pas contenir tous les paramètres et étiquettes présents dans l'objet en direct.
Essayez de définir le libellé du collaborateur sur false:
node-role.kubernetes.io/worker: "false"
A travaillé pour moi sur OpenShift 4.4.
Modifier: Cela ne marche pas. Ce qui s'est passé est:
Ce qui est drôle, c'est que le processus automatisé ne supprimerait pas l'étiquette si elle était vide au lieu d'être définie sur false.
Je ne pense pas que ce soit une bonne idée de changer l'étiquette sur le nœud au lieu de créer de nouveaux MachineSets pour le nœud d'infrastructure.