-
Notifications
You must be signed in to change notification settings - Fork 716
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
the v1alpha3 usage is unclear: Unable to init kubeadm 1.12 with config file #1152
Comments
hi, you should not pass |
Hello,
When: "kind: ClusterConfiguration" was added to the node, some interesing message came up:
Can anyone help with details? |
your cgroupfs driver and network address will be detected at runtime.
i agree. best information can be found in our reference docs and source code: for now
true. |
@neolit123
|
|
/lifecycle active |
@neolit123
and
If so,the 2 sources of truth must be kept manually in sync, or one takes priority (and defines the other)? |
Given that this is regressive behavior, we can cherry-pick certain changes. |
yes. |
@ReSearchITEng @neolit123 If you leave field empty, kubeadm will keep values in sync among different components, if you specify values in the kubeproxy config, this value will be preserved (up to you to keep things in sync) relevant code here: |
@fabriziopandini @timothysc |
We need more than a work-around imo. Let's discuss tomorrow on the call. |
I can tackle the long term solution, once we have a clear understanding what's needed. /assign |
Adding notes from sig-call today: 1.13
1.12
|
sadly i missed the start of the meeting:
the is fine as long as we don't expect configuration objects that are not bound to either init or join, but rather bound to another hypothetical workflow that we don't yet have. i must admit i preferred the old but also #ETOOMANYSUBCOMMANDS |
I'm not sure this is heading in the right direction, but the issue as stated was bang on to my frustration. It's hard to believe this passes for acceptable validation output in 2018:
Completely ambigous, and in fact, in this case, the kube-adm.yml file did not even exist. It is just a raw underlying lib parse error on a file that doesn't exist. No matter what YAML error was in my config file, I would get a similar error output... a line number, even though multiple YAML files are combined, so often the lines were from a particular YAML segment that was never referenced in the output. But the most frustrating was when I got to more qualitative validations... like this one:
That is a lovely error, but would you mind telling me which host field you are referring to! It was only by removing them one by one that I found the issue... an unnecessary "http://" prefix in my template triggered the parse error at line 110:
Would it be so hard to include the offending host in the error output? Or the relevant field from a list of hundreds? If this was my first experience with |
@seanhig Along this way user any user feedback is really valuable and we are taking them really seriously as you can see from this thread that already generated 3 PRs. |
Well, after some days i've been able to test the suggestions, it worked, though as stated by other folks here the new format is a bit confusing |
as of controllerManagerExtraArgs:
horizontal-pod-autoscaler-use-rest-clients: "true"
horizontal-pod-autoscaler-sync-period: "10s"
node-monitor-grace-period: "10s"
apiServerExtraArgs:
runtime-config: "api/all=true" |
^ ClusterConfiguration |
Hi, |
@ReSearchITEng the way you do it is you look for the fields that you need, you place them in XXXXXConfig structs based on the specification and separate the structs with --- if they are more than one.
hope that helps. |
@neolit123 |
should also work if you pass InitConfiguration from a file and |
No, that won't work currently, but it's on the road map for 1.13. |
@rosti
(tracked here: #1166 (comment)) |
@ReSearchITEng no, at this point you should have a running cluster and its version stored in its config map. Therefore, you don't need to specify the K8s version in any way (neither from command line, nor from config file). |
@rosti
Still, it's querying the internet. I guess @neolit123 's PR will remove the need for querying the version for activities like token creation. |
@neolit123 quick question is it possible to pass kubeletExtraArgs:
feature-gates: "BlockVolume=true" within the |
we have a full example here @ulm0 search for try passing at least --v=1 to |
Closing this issue given the update in the docs. |
Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
/sig release
/sig cluster-lifecycle
reported in kubernetes/kubernetes#69242
What happened:
According to changelog:
Printed the new config format (
kubeadm config print-default
) to see what changes i need to make in order to spin up a new 1.12 cluster, decided to test the default config (kubeadm config print-default > master.yml
) i got the from command and just changed thecriSocket
from docker to containerd, thing is i'm unable to init the cluster due to the following output:What you expected to happen:
Cluster to init with the new config format
How to reproduce it (as minimally and precisely as possible):
Use the default config and try to init the cluster with it
Anything else we need to know?:
Running just
kubead init
works (orkubeadm init --cri-socket /var/run/containerd/containerd.sock
in my case)Environment:
kubectl version
):uname -a
):Linux master 4.15.18-041518-generic #201804190330 SMP Thu Apr 19 07:34:21 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
apt-get
and containerd downloaded bywget
master.yml
The text was updated successfully, but these errors were encountered: