search

coreos / coreos-kubernetes

CoreOS Container Linux+Kubernetes documentation & Vagrant installers
https://coreos.com/kubernetes/docs/latest/
Apache License 2.0
1.1k stars 466 forks source link

Update Calico TAGS to v2 release and fix documentation #799

Closed ArchiFleKs closed 7 years ago

ArchiFleKs commented 7 years ago

In the docs the kubectl apply part to deploy calico is missing. Also in the doc /etc/kubernetes is used for calico manifest but /srv/kubernetes is used in script. The doc is fixed to match the script. Also, Calico tags are updated to v2 release (http://docs.projectcalico.org/v2.0/releases/)

caseydavenport commented 7 years ago

The Calico changes here look good to me. @ArchiFleKs would you mind making the same version bumps to the equivalent single-node manifest?

https://github.com/coreos/coreos-kubernetes/blob/master/single-node/user-data#L852

ArchiFleKs commented 7 years ago

I updated the docs and generic multi and single node script to use kube-addon-manager v6.1.

I also added heapster and updated addons manifest in documentation for the "Deploy addons section"

ArchiFleKs commented 7 years ago

@caseydavenport I'd thought they're would be some kind of convergence/magic, since calico is looking into etcd ^^.

Maybe we can start kubelet with calico and addon manager, wait for calico and then drop the addons template?

Le lun. 9 janv. 2017 à 04:39, Casey Davenport notifications@github.com a écrit :

@caseydavenport commented on this pull request.

In Documentation/deploy-master.md https://github.com/coreos/coreos-kubernetes/pull/799:

@@ -668,6 +668,14 @@ kube-controller-$node kube-proxy-$node

+### Configure Calico + +To start Calico services : + +``` +docker run --rm --net=host -v /srv/kubernetes/manifests:/host/manifests quay.io/coreos/hyperkube:v1.5.1_coreos.0 /hyperkube kubectl apply -f /host/manifests/calico.yaml

@ArchiFleKs https://github.com/ArchiFleKs the problem is that if a pod is started using the flannel without the Calico CNI plugin, then Calico won't know about the pod and thus won't be able to enforce policy on it, even if you restart Calico.

You'd have to restart the pod itself in order for it to be recreated with the Calico CNI plugin in order to make it work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/coreos/coreos-kubernetes/pull/799, or mute the thread https://github.com/notifications/unsubscribe-auth/ABN4qQ8BOaaahIzHGgZvAWRnoWKBEVGdks5rQavogaJpZM4Lbdvl .

ArchiFleKs commented 7 years ago

@caseydavenport any update on this ?

ArchiFleKs commented 7 years ago

@robszumski @caseydavenport : Hi Guys, any update on this ? :)

caseydavenport commented 7 years ago

@ArchiFleKs Sorry for the delay on this, I've been totally swamped!

I'd thought they're would be some kind of convergence/magic, since calico is looking into etcd

Calico just looks at it's own part of etcd (/calico) so it's not aware of anything that flannel might have written, so unfortunately no magic here.

I'm still leaning towards just using a kubectl applyto install Calico in the step-by-step documentation, provided @robszumski is OK with that. We could either do that here, or in the deploy-addons stage, but my preference would be here given the ordering concerns with other add-ons.

ArchiFleKs commented 7 years ago

@caseydavenport : maybe we could write the calico.yaml template with addons manager and wait for it to be ready (maybe with docker and kubectl) before writing the other addons ?

This way we get to keep addons-manager and calico without manual cURLing ?

robszumski commented 7 years ago

@caseydavenport Yeah, we might as well move forward with that

caseydavenport commented 7 years ago

maybe we could write the calico.yaml template with addons manager and wait for it to be ready (maybe with docker and kubectl) before writing the other addons ?

My concern with that is that in the future people can unknowingly add additional add-ons via the add-on manager. AFAIK the add-on manager doesn't have a concept of "wait for this to be running before deploying any other add-ons", so it's totally possible that other add-ons would be deployed before Calico.

ArchiFleKs commented 7 years ago

@caseydavenport @robszumski Yes but if calico is the first addon we write, we can may be check the state of the calico pods before writing other addons with the script. Therefore we're sure that calico is the first addons to be deploy

ArchiFleKs commented 7 years ago

@caseydavenport @robszumski I'm going to drop this, it seems to already been updated in docs