And thanks for reporting this. If it is "working as intended" it is at least surprising, and the behavior and rationale should be clearly documented. But it does seem like a bug to me.
On Fri, Oct 6, 2017 at 4:49 PM, Budai Laszlo <laszlo.bu...@gmail.com> wrote: > lbudai74 > > Thank you. > Laszlo > > > On 07.10.2017 02:47, 'David Oppenheimer' via Kubernetes user discussion > and Q&A wrote: > >> If you tell me your Github username I can @ mention you on the issue. >> >> >> On Fri, Oct 6, 2017 at 4:46 PM, Laszlo Budai <laszlo.bu...@gmail.com >> <mailto:laszlo.bu...@gmail.com>> wrote: >> >> The worst part of the story is that if we run cluster components like >> kube-proxy and the network plugin as DaemonSets (kubeadm does that) then >> if a user sets a NoSchedule taint on a node that will render the node close >> to useless as it will evict the DS managed Pods .... >> >> Can I follow the github issue somehow? >> >> Kind regards, >> Laszlo >> >> >> On Saturday, October 7, 2017 at 2:37:17 AM UTC+3, David Oppenheimer >> wrote: >> >> Yeah, sorry, I forgot about DaemonSet. It tolerates certain >> system-added taints by default (you can see the list here < >> https://github.com/kubernetes/kubernetes/blob/master/pkg/ >> controller/daemon/daemon_controller.go#L1147>) but user-added taints >> will cause eviction. The thing that seems less than ideal is that >> user-added NoSchedule taints will cause eviction. I don't know if this was >> intentional or accidental, but I will file a Github issue. >> >> >> On Fri, Oct 6, 2017 at 4:32 PM, Laszlo Budai <laszlo...@gmail.com> >> wrote: >> >> I have just repeated the test using a deployment also. The >> pods belonging to the deployment were not affected. Only those belonging to >> the daemonset as you can see below: >> >> root@master1 $> kubectl get po -o wide >> NAME READY STATUS RESTARTS AGE >> IP NODE >> nginx-deployment-4234284026-pbt8m 1/1 Running >> 0 42s 10.32.0.4 worker1 >> nginx-deployment-4234284026-spp7j 1/1 Running >> 0 13s 10.47.0.3 worker2 >> nginx-deployment-4234284026-v479b 1/1 Running >> 0 42s 10.44.0.3 worker3 >> pod1 1/1 Running 2 2h >> 10.44.0.1 worker3 >> taint-ds-test-1d9d7 1/1 Running 0 >> 10m 10.32.0.3 worker1 >> taint-ds-test-5x20k 1/1 Running 0 >> 10m 10.47.0.2 worker2 >> taint-ds-test-j5g69 1/1 Running 0 >> 1m 10.44.0.2 worker3 >> >> root@master1 $> kubectl taint nodes worker3 >> mykey=myvalue:NoSchedule >> node "worker3" tainted >> >> root@master1 $> kubectl get po -o wide >> NAME READY STATUS RESTARTS AGE >> IP NODE >> nginx-deployment-4234284026-pbt8m 1/1 Running >> 0 1m 10.32.0.4 worker1 >> nginx-deployment-4234284026-spp7j 1/1 Running >> 0 41s 10.47.0.3 worker2 >> nginx-deployment-4234284026-v479b 1/1 Running >> 0 1m 10.44.0.3 worker3 >> pod1 1/1 Running 2 2h >> 10.44.0.1 worker3 >> taint-ds-test-1d9d7 1/1 Running 0 >> 10m 10.32.0.3 worker1 >> taint-ds-test-5x20k 1/1 Running 0 >> 10m 10.47.0.2 worker2 >> taint-ds-test-j5g69 0/1 Terminating 0 >> 1m <none> worker3 >> >> >> Kind regards, >> Laszlo >> >> >> On Saturday, October 7, 2017 at 2:22:32 AM UTC+3, Laszlo >> Budai wrote: >> >> It seems it causes pod eviction if the pod was created by >> a daemonset ... Just tested it with the following steps: >> >> 1. created a test daemonset: >> >> root@master1 $> cat ds1.yaml >> apiVersion: extensions/v1beta1 >> kind: DaemonSet >> metadata: >> name: taint-ds-test >> spec: >> selector: >> matchLabels: >> app: nginx >> template: >> metadata: >> labels: >> app: nginx >> spec: >> containers: >> - name: nginx >> image: nginx:1.7.9 >> ports: >> - containerPort: 80 >> >> >> root@master1 $> kubectl create -f ds1.yaml >> daemonset "taint-ds-test" created >> >> root@master1 $> kubectl get pod -o wide >> NAME READY STATUS RESTARTS AGE >> IP NODE >> pod1 1/1 Running 2 2h >> 10.44.0.1 worker3 >> taint-ds-test-1d9d7 1/1 Running 0 16s >> 10.32.0.3 worker1 >> taint-ds-test-5x20k 1/1 Running 0 16s >> 10.47.0.2 worker2 >> taint-ds-test-99z5q 1/1 Running 0 16s >> 10.44.0.2 worker3 >> root@master1 $> >> >> 2. added a taint to worker3 >> >> root@master1 $> kubectl taint nodes worker3 >> mykey=myvalue:NoSchedule >> node "worker3" tainted >> >> 3. tested the pods again: >> >> root@master1 $> kubectl get pod -o wide >> NAME READY STATUS RESTARTS >> AGE IP NODE >> pod1 1/1 Running 2 >> 2h 10.44.0.1 worker3 >> taint-ds-test-1d9d7 1/1 Running 0 >> 1m 10.32.0.3 worker1 >> taint-ds-test-5x20k 1/1 Running 0 >> 1m 10.47.0.2 worker2 >> taint-ds-test-99z5q 0/1 Terminating 0 >> 1m <none> worker3 >> >> and agin later on: >> >> root@master1 $> kubectl get pod -o wide >> NAME READY STATUS RESTARTS AGE >> IP NODE >> pod1 1/1 Running 2 2h >> 10.44.0.1 worker3 >> taint-ds-test-1d9d7 1/1 Running 0 5m >> 10.32.0.3 worker1 >> taint-ds-test-5x20k 1/1 Running 0 5m >> 10.47.0.2 worker2 >> root@master1 $> >> >> >> so pod1 (created directly as a pod) was not affected by >> the NoSchedule taint, while all the pods managed by a DaemonSet were >> evicted ... >> >> Am I missing something related to taints and daemonsets? >> >> Kind regards, >> Laszlo >> >> >> >> >> On 07.10.2017 01:46, 'David Oppenheimer' via Kubernetes >> user discussion and Q&A wrote: >> > Adding a NoSchedule taint to a node should not cause >> any pod evictions. Something else must be going on. >> > >> >> -- You received this message because you are >> subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. >> To unsubscribe from this group and stop receiving emails from >> it, send an email to kubernetes-use...@googlegroups.com. >> To post to this group, send email to >> kubernet...@googlegroups.com. >> Visit this group at https://groups.google.com/grou >> p/kubernetes-users <https://groups.google.com/group/kubernetes-users>. >> For more options, visit https://groups.google.com/d/optout < >> https://groups.google.com/d/optout>. >> >> >> -- You received this message because you are subscribed to the >> Google Groups "Kubernetes user discussion and Q&A" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an email to kubernetes-users+unsubscr...@googlegroups.com <mailto: >> kubernetes-users+unsubscr...@googlegroups.com>. >> To post to this group, send email to kubernetes-users@googlegroups. >> com <mailto:kubernetes-users@googlegroups.com>. >> Visit this group at https://groups.google.com/group/kubernetes-users >> <https://groups.google.com/group/kubernetes-users>. >> For more options, visit https://groups.google.com/d/optout < >> https://groups.google.com/d/optout>. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Kubernetes user discussion and Q&A" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to kubernetes-users+unsubscr...@googlegroups.com <mailto: >> kubernetes-users+unsubscr...@googlegroups.com>. >> To post to this group, send email to kubernetes-users@googlegroups.com >> <mailto:kubernetes-users@googlegroups.com>. >> Visit this group at https://groups.google.com/group/kubernetes-users. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Kubernetes user discussion and Q&A" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kubernetes-users+unsubscr...@googlegroups.com. > To post to this group, send email to kubernetes-users@googlegroups.com. > Visit this group at https://groups.google.com/group/kubernetes-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
