Kubernetes-Anwendung läuft auf Master - DaemonSet

Question

Gibt es eine Möglichkeit, die Ausführung einer Anwendung zu vermeiden, die als DaemonSet auf dem Master bereitgestellt wird?
Ich habe gesehen, dass dies das erwartete Verhalten ist, aber ich möchte die Ausführung in irgendeiner Weise vermeiden.

Regelmäßige Pods werden nicht auf dem Master geplant, aber DaemonSet-Pods tun dies.

Wenn ja, ist es möglich, diese Informationen in der Yml-Datei (parameter..etc ??) zu setzen?

kubectl create -f mydaemon.yml 

logspri-4zwl4    1/1  Running   0   <invalid> X.X.X.X k8s-master-e7c355e2-0 
logspri-kld2w    1/1  Running   0   <invalid> X.X.X.X  k8s-agent-e7c355e2-0 
logspri-lksrh    1/1  Running   0   <invalid> X.X.X.X  k8s-agent-e7c355e2-1 

Ich möchte meine pod vermeiden läuft auf k8s-master-e7c355e2-0

Ich habe versucht:

annotations: 
      scheduler.alpha.kubernetes.io/affinity: > 
      { 
       "nodeAffinity": { 
       "requiredDuringSchedulingRequiredDuringExecution": { 
        "nodeSelectorTerms": [ 
        { 
         "matchExpressions": [ 
         { 
          "key": "kubernetes.io/role", 
          "operator": "NotIn", 
          "values": ["master"] 
         } 
         ] 
        } 
        ] 
       } 
       } 
      } 

auch versuchen, die folgende Rolle anzuwenden (wie vorgeschlagen), aber es funktioniert nicht :

kubectl get nodes 
NAME     STATUS      AGE  VERSION 
k8s-agent-e7c355e2-0 Ready      49d  v1.5.3 
k8s-agent-e7c355e2-1 Ready      49d  v1.5.3 
k8s-master-e7c355e2-0 Ready,SchedulingDisabled 49d  v1.5.3 

Soll ich ausführen:

Auch wenn es scheint, dass der Master verdorben ist, sehe ich, dass die Anwendung immer auf Master ist.

Role:   
Labels:   beta.kubernetes.io/arch=amd64 
      beta.kubernetes.io/instance-type=Standard_D2 
      beta.kubernetes.io/os=linux 
      failure-domain.beta.kubernetes.io/region=northeurope 
      failure-domain.beta.kubernetes.io/zone=0 
      kubernetes.io/hostname=k8s-master-e7c355e2-0 
Annotations:  volumes.kubernetes.io/controller-managed-attach-detach=true 
Taints:   <none> 
CreationTimestamp: Wed, 17 May 2017 14:38:06 +0200 
Phase:   
Conditions: 

Was ist los? Können Sie mir den richtigen Befehl geben?

gleiche Problem berichtet here ohne eine scheinbare Lösung von:

kubectl taint nodes nameofmaster dedicated=master:NoSchedule 

Dank Prisco

Answer 1

Von https://github.com/kubernetes/kubernetes/issues/29108 können Sie eine taint Flagge zu Ihrem Master-Knoten kubelet hinzufügen, so dass die auch die Schoten in der DaemonSet sind dort nicht geplant

Sie müssen Kubelet in Ihrem Knoten neu starten

Answer 2

Von Even if it seems that the master is tainted I see that the application is always on master., bin ich nicht sicher, ob das DaemonSet vor oder nach dem Makel erstellt wurde.

Wenn Sie zuerst verdorben und dann das DaemonSet erstellt haben, sollte der Pod ohne weitere Konfiguration vom fehlerhaften Knoten abgestoßen werden. Andernfalls wird der Pod aus dem DaemonSet nicht automatisch beendet. Um vorhandene Pods sofort zu entfernen, wird der NoExecute Taint benötigt.

Von here:

Normalerweise, wenn ein Makel mit Wirkung NoExecute zu einem Knoten hinzugefügt wird, dann irgendwelche Schoten, die nicht den Makel dulden wird sofort geräumt werden, und alle Hülsen, die das tun tolerieren Taint wird nie geräumt werden. Eine Tolerierung mit NoExecute-Effekt kann jedoch ein optionales tolerationSeconds-Feld angeben, das festlegt, wie lange der Pod nach dem Hinzufügen des Taint an den Knoten gebunden bleibt ( ).