Tried weave and flannel but both fail when trying to access the API due to the lack of permissions to do so.
They are using the kube-system service account. This should be easily remedied.
So the conclusion from the sig was bring-your-own-RBAC-rules if you need access to the apiserver.
We need to notify the flannel, weave, calico, canal and romana guys about this.
On Tue, Feb 7, 2017 at 12:06 PM, Lucas Käldström notifications@github.com
wrote:
So the conclusion from the sig was bring-your-own-RBAC-rules if you need
access to the apiserver.
We need to notify the flannel, weave, calico, canal and romana guys about
this.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/kubeadm/issues/143#issuecomment-278087830,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKWUcAdzOERRFVsBTlnvqFHOm4jYfLGks5raLK4gaJpZM4L09cu
.
--
Cheers,
Timothy St. Clair
“Do all the good you can. By all the means you can. In all the ways you
can. In all the places you can. At all the times you can. To all the people
you can. As long as ever you can.”
Calico/canal dev here. Is this new? When did it change? Just wondering what version to test against.
This is the situation at HEAD and in v1.6.0-alpha.1 where RBAC is enabled by default.
I'm testing this out and things aren't working right now for any of the plugins I looked at.
You can test (on debian at least) by using the unstable repo. That has the latest 1.6 alpha packages.
$ cat /etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main
Also -- piggy backing on this -- we've also changed the name of the taint we are using on the master. And daemonsets now respect taints. So if you want to schedule something on the master node, you have to tolerate node-role.kubernetes.io/master.
@jbeda I've found the same thing while doing e2e testing in https://github.com/kubernetes/kubeadm/issues/190. Flannel (even with its RBAC bindings) was causing kube-dns to keep crashing/restarting, and an updated manifest for weave-net still resulted in kube-dns being stuck in ContainerCreating. I'm still looking into this myself, if you want to coordinate debugging efforts.
/cc @liggitt @kubernetes/sig-network-misc
Apparently there is a breaking change in CNI whereby the CNI_NETNS env variable can be missing on teardown. This is going to break pretty much every existing CNI provider. See also: https://github.com/weaveworks/weave/pull/2850.
FYI Calico PR with RBAC is now available: https://github.com/projectcalico/calico/pull/537/files~~
Can be tried out with this manifest: https://raw.githubusercontent.com/djosborne/calico/148d50c5395ff1ad0bf2ea55a769e2464b8bca88/master/getting-started/kubernetes/installation/hosted/kubeadm/kube-v1.6/calico-rendered.yaml~~
CC @djosborne
EDIT: This is the correct manifest: kubectl apply -f http://docs.projectcalico.org/v2.1/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml
Weave Net release 1.9.4 includes a daemonset for Kubernetes 1.6 with RBAC, and also updates other aspects like the missing CNI_NETNS
There is a new short URL so you can say kubectl apply -f https://git.io/weave-kube-1.6
Official Calico with RBAC is up: kubectl apply -f http://docs.projectcalico.org/v2.1/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml
This has been fixed, closing...
Most helpful comment
Weave Net release 1.9.4 includes a daemonset for Kubernetes 1.6 with RBAC, and also updates other aspects like the missing
CNI_NETNSThere is a new short URL so you can say
kubectl apply -f https://git.io/weave-kube-1.6