1
votes

Comment supprimer une étiquette d'un objet kubernetes simplement avec "kubectl apply -f file.yaml"?

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: {}


1 commentaires

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.


4 Réponses :


0
votes

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.


0 commentaires

0
votes

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-


0 commentaires

0
votes

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 kubectl apply -f filename.yaml commande. Il peut ne pas contenir tous les paramètres et étiquettes présents dans l'objet en direct.


0 commentaires

0
votes

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:

  • Fichier YML appliqué contenant node-role.kubernetes.io/worker: "false"
  • Un processus automatisé a été exécuté en supprimant le libellé node-role.kubernetes.io/worker du nœud (car il n'était pas spécifié dans le YML, il s'appliquerait automatiquement)

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.


0 commentaires