New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bringing CoreOS cloud-configs up-to-date (against 0.15.x and latest OS' alpha) #6973
Conversation
So far LGTM. Missing updated doc (make yourself the maintainer) and the AWS Cloud-Formation template. |
docs tweaked. missing now is the aws stuff and the baremetal stuff. |
Works for me after changing kubelet |
@AntonioMeireles thank you for the change to use default. I had made an equivalent change locally which works. |
missing updating now are just the cloud-formation changes, and the bare-metal ones. unless someone steps ups and offers to test/help on those fronts i don't feel brave enough to do them now in this round... other than that i 'think' that this is ready hopefully @pires @kelseyhightower @* validate plz |
@AntonioMeireles
I believe it is the same as #3185 |
@bussyjd what cloud provider are you using ? |
@AntonioMeireles I am using esxi VMs with 2 networks. I boot coreos 653.0.0 and run the cloudinit files manually. |
@bussyjd according to the upstream CoreOS docs here "The $private_ipv4 and $public_ipv4 substitution variables referenced in other documents are not supported on VMware." (sic) so you'll have to manually edit them. [afaict there is aditional upstream work going on here to get rid in the future of present cloud-config limitations] |
@AntonioMeireles I am aware of it and triple checked for mismatch. Replacing the values manually could get me to a running cluster but only with the |
@bussyjd ok, thanks. sorry i can't help you more, as i don't have right now access to the tools to try to replicate your issue locally :/ @kelseyhightower you (when back from €uro tour) perhaps ? |
727500d
to
6276273
Compare
Working fine for me |
@erictune ping. (getting this in would be probably handy for a few people as 0.15.0 is out for a while...) |
coreos: | ||
etcd2: | ||
name: ${DEFAULT_IPV4} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will not work. You need to depend on the setup-network-environment tool. That's why I've always used real unit files vs the cloud-init short cuts.
${DEFAULT_IPV4}
is set by the env file produced by setup-network-environment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just set it to master
@AntonioMeireles?
Potentially relevant to this PR: #7445 |
54859f1
to
e047fb8
Compare
@kelseyhightower et al. - just droped the overreliance in cloud-config shortcuts and rebased to accomodate f5e81c25c , so could you all plz check if there are any remaining oversights on my side when time permits. (thanks in advance) |
@hobti01 that commit applies mods to currently shipping etcd (v1) setup, and this PR puts everything in the etcd2 bandwagon. |
@erictune @kelseyhightower this LGTM but probably @AntonioMeireles should squash? |
@pires fwiw i didn't squash it yet in order to make timeline/observability a bit more easy/granular. to read/follow.. as soon as stakeholders happy i'll do it ... |
Please squash and I will merge. |
- allow payloads to run in privileged mode. - update kube-register to latest upstream (v0.0.3). - jump into the etcd2 bandwagon. - etcd master on master node. - etcd proxies in nodes. - update docs to reflect minimum required CoreOS version. - 653.0.0 is the first to ship with etcd2, which we now consume. - propagate changes on coreos/cloud-configs/ also to aws/cloud-configs/. - update tested k8s versions that this addresses in the getting-started-guides table ence making sure we are consistent across it regarding the versions we claim to have tested, add myself there as contact too. - do not assume that cloud-init shortcuts will get everything right. - they won't (as setup-network-environment who populates *_ipv4, etc only runs way later). - use flannel's plain defaults, as they should just be enough for the common case. Signed-off-by: António Meireles <antonio.meireles@reformi.st>
@erictune done 'n' thanks. |
bringing CoreOS cloud-configs up-to-date (against 0.15.x and latest OS' alpha)
@bussyjd, how is it "working fine now"? I am seeing the same pattern you described when
If I peek at the registry, I see the public IP listed:
Empirically, it appears that the Can anyone offer and explanation, or better yet, a workaround? |
@ngConsulti My guess is that this is a mismatch between the nodeID created by kube-register and the nodeID that the node is using itself while sending node status updates to the apiserver. Once we get #6949 merged the kubelets will register themselves so there shouldn't be a mismatch between the nodeIDs any longer. |
Thanks, @roberthbailey. I switched to using the public IP to get unstuck. This allowed me to register a single minion/node. However, any additional nodes fail with the following error:
Why the server says "Method Not Allowed" (HTTP 405) is beyond me...since it worked for the first node! |
Ah...good old user error. I failed to explicitly set the
|
@ngConsulti Great! |
work in progress, result of the discussion in #6281.
missing is tweaking the docs and updating the aws CoreOS cloud-configs.
@pires et al. can you plz triple check that i didn't miss anything.