Previously, users were not told where `kind` was looking for the
Kubernetes source, making the error message not actionable:
```
$ kind build node-image
ERROR: error building node image: error finding kuberoot: could not find kubernetes source
```
Now, we expose that information so the user can ensure we locate it.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
According to the [metallb 0.10.0 release notes](https://metallb.universe.tf/release-notes/#version-0-10-0), it is no longer necessary to manually create the secret `metallb-system/memberlist` if deploying from the manifests linked to in this guide.
We have a set of GitHub Action jobs that run to test cgroupv2, docker,
and podman functionality. They currently run on all PRs to main.
These are functional tests, so they are not necessary when making
documentation changes. This updates the job definitions to skip running
if the PR only contains doc changes. This is likely rare, but will save
some resources by not testing when there are no code changes.
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
While reviewing kind issues, I noticed there seems to be a regularly
recurring problem with users expecting `kind delete cluster foo` to
fail if there is not a cluster named `foo` present.
We intentionally do not fail in this case. The delete command is
idempotent, and should be able to be run repeatedly without erroring.
This is very useful in clean up scripts, and many users rely on this
behavior.
It also makes things somewhat declarative in that you are saying "I
don't want a cluster named foo", and `kind` helpfully confirms that
there is no cluster named "foo".
To try to avoid some of these repeated issues being filed, this adds a
note to the quick start docs in the "Deleting a Cluster" section to
point out that this is the expected behavior. This also helps new users
to know that they can depend on this behavior if they are scripting
things with kind.
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
The example script for creating a kind cluster with a local registry
will connect the container to the "kind" network. The first time the
local registry is created, this is fine and is what is needed. On
subsequent runs to create new clusters, if the local registry container
has already been set up, the command to attach to the "kind" network
will emit an error message to the create output that can be confusing.
This updates the example script to do a basic check of the registry
containers network configuration. If the kind network appears to be
already connected, then the script will not attempt to connect it again.
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
As per the kubeadm KEP for "master" label/taint changes:
- kubeadm 1.24 nodes will only have the "control-plane" label.
- kubeadm 1.24 nodes will have both the "master"
and "control-plane" taints.
- kubeadm 1.25 nodes will have only the "control-plane" taint
Adapt kind to these changes and add TODOs with links
for the tracking issue in k-sigs/kind.
