Kind + Kubeadm v1Beta2 Patches

[sager-tech]

I am using kind 0.5.1 and when I try to do kind create cluster with the following manifest:

kind: Cluster
apiVersion: kind.sigs.k8s.io/v1alpha3
nodes:
- role: control-plane
- role: worker
- role: worker
kubeadmConfigPatches:
- |
 apiVersion: kubeadm.k8s.io/v1beta2
 kind: ClusterConfiguration
 metadata:
   name: config
 networking:
   serviceSubnet: "10.96.0.1/12"
   podSubnet: "10.244.0.0/16"

I get an error saying:

Error: failed to create cluster: failed to generate kubeadm config content: no matches for OriginalId kubeadm.k8s.io_v1beta2_ClusterConfiguration|~X|config; no matches for CurrentId kubeadm.k8s.io_v1beta2_ClusterConfiguration|~X|config; failed to find unique target for patch kubeadm.k8s.io_v1beta2_ClusterConfiguration|config

When I build kind from HEAD (resulting in kind 0.6.0-alpha), I am able to kind create cluster successfully. Based on what I've read from the other issues, I should be able to bring up the cluster with 0.5.1. I am guessing the kubeadm version is the issue at hand, but any ideas or insight as to why this may be happening?

[BenTheElder]

the patch runtime changed at HEAD to be more flexible.
the default kubernetes version also changed.

what's your full commandline?

if you run with --loglevel=debug it should print out the kubeadm config generated.

[sager-tech]

Thanks @BenTheElder

Ah, I see. I need the kind version for linux, is it possible to build that from HEAD?

The full commandline is: kind create cluster --config find . -name config.yaml--image kindest/node:v1.13.7

There were a few kubeadm configurations generated, but none of them were with apiVersion: kubelet.config.k8s.io/v1beta2. They were either v1beta1 or v1alpha1

[BenTheElder]

yes, try make install, though 0.5.1 should work fine.

There were a few kubeadm configurations generated, but none of them were with apiVersion: kubelet.config.k8s.io/v1beta2. They were either v1beta1 or v1alpha1

yes, that's because of kindest/node:v1.13.7, the kubeadm API version is matched to the kubernetes version.

[BenTheElder]

with HEAD you can skip the apiVersion (and metadata.name) and cross your fingers that the fields are the same (eg most of them are for beta1 / beta2).

0.5.1 and down need to specify the matching API version

[sager-tech]

@BenTheElder make install works on linux as well? Running ./bin/kind version returns kind v0.6.0-alpha+85a46de118167a go1.13.3 darwin/amd64 which I would assume is for darwin only? Unless it means that it was built on darwin?

[BenTheElder]

did you build on a darwin host?
make install builds and installs for the host. to build for another platform you can do something like make build GOOS=linux

[sager-tech]

@BenTheElder

I'm testing on a remote CI worker that doesn't retain the environment so debugging is a bit tough but:

1. I did make build GOOS=linux and uploaded the binary to be used
2. It brings up the cluster with kind create cluster --config dep.yaml --image kindest/node:v1.13.7
3. It ends with saying:

Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

We later need to run a few kubectl commands which fail with:

Received unexpected error:
.kube/kind-config-kind: no such file or directory

Running kubectl get kubeconfig returns empty.

However, running locally on darwin bringing up the cluster gives:

Cluster creation complete. You can now use the cluster with:

export KUBECONFIG="$(kind get kubeconfig-path --name="kind")"
kubectl cluster-info

And we are able to execute our kubectl commands successfully.

Also of note:
Linux: kind version: kind v0.6.0-alpha+7a7e23ce88e43f go1.13.4 linux/amd64
Darwin: kind version: kind v0.6.0-alpha+85a46de118167a go1.13.3 darwin/amd64

Why are there 2 different versions for the different OS' when being built from the same HEAD? How do we forcefully get output for kubectl get kubeconfig?

[BenTheElder]

HEAD is not really a supported release, if you set the correct apiVersion this should work with v0.5.1

at HEAD we are shipping most of #850 to bring kubectl management in line with other tools.

currently that does not include get kubeconfig-path because it uses the standard path.

Received unexpected error:
.kube/kind-config-kind: no such file or directory

that's because you're using the old path for kubeconfig. export KUBECONFIG="$(kind get kubeconfig-path --name="kind")" is not used in HEAD.

Why are there 2 different versions for the different OS' when being built from the same HEAD?

You must have used different commits.

We can tell this is the case because actually at HEAD this output does not exist:

Cluster creation complete. You can now use the cluster with:

export KUBECONFIG="$(kind get kubeconfig-path --name="kind")"
kubectl cluster-info

but this does:

Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

[BenTheElder]

How do we forcefully get output for kubectl get kubeconfig?

one of:

• don't export KUBECONFIG if using HEAD
• export KUBECONFIG but set your own path before calling kind create cluster e.g. export KUBECONFIG=$HOME/.kube/kind-config-foo
• leverage kind get kubeconfig to get the kubeconfig contents.

there will be a migration guide for this in the release. we're also going to add back a deprecated form of kind get kubeconfig-path that warns about migrating.

[sager-tech]

Interesting. I've made the updates and am using 0.5.1 with v1beta1 and everything looks good at the moment. Thanks!

[BenTheElder]

awesome.

definitely aware of the issues switching to the new kubeconfig as well ... not shipping a release until we're in better shape there, leaving #850 open 😅