Skip to content
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

Fix safe upgrade #1

Closed
wants to merge 1 commit into from
Closed

Fix safe upgrade #1

wants to merge 1 commit into from

Conversation

mlushpenko
Copy link
Owner

Problem

A kubespray cluster is running for some time and you want to safely update it to the newer version using upgrade_cluster.yml

It will fail during [kubernetes/kubeadm : Join to cluster if needed] with error:

"stdout": "[preflight] Running pre-flight checks.\n[discovery] Trying to connect to API Server \"10.94.45.185:6443\"\n[discovery] Created cluster-info discovery client, requesting info from \"https://10.94.45.185:6443\"\n[discovery] Failed to connect to API Server \"10.94.45.185:6443\": there is no JWS signed token in the cluster-info ConfigMap. This token id \"abcdef\" is invalid for this cluster, can't connect\n

Expected result

kubeadm join will succeed as kubeadm_token_ttl is set to 0 which means that token should never expire, but it is not present in kubeadm token list after cluster is provisioned (at least after it is running for some time)

Related issues

kubernetes/kubeadm#335

Solution

Create a new temporary token before the kubeadm join command

Refactoring issues

Not sure what to do with kubeadm_token and kubeadm_token_ttl that are defined in roles\kubespray-defaults\defaults\main.yml. The code I added doesn't really breake anything as much as I tested, but looks like kubeadm_token_ttl is not respected, so perhaps it can be removed. kubeadm_token is also used for master config, so can stay untouched but it's a bit weird that that token is not used then during kubeadm join because I override it with newly generated one. Please suggest if you have ideas how to optimize it.

Even though there it kubeadm_token_ttl=0 which means that kubeadm token never expires, it is not present in `kubeadm token list` after cluster is provisioned (at least after it is running for some time) and there is issue regarding this kubernetes/kubeadm#335, so we need to create a new temporary token during the cluster upgrade.
@mlushpenko mlushpenko closed this Feb 5, 2018
mlushpenko pushed a commit that referenced this pull request Sep 1, 2018
…edns

appropriately use dns_domain instead of cluster_name for coredns for coredns config map
mlushpenko pushed a commit that referenced this pull request Sep 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant