The latest metallb version is configurable via CRs instead of configmap.
Here we suggest using the latest version and we change the configuration
from configmap to CRs.
Signed-off-by: Federico Paolinelli <fedepaol@gmail.com>
This adds some detail to the known issues for those using Docker Desktop
and trying to deploy a k8s version prior to 1.19. Newer Docker Desktop
releases instantiate a VM that defaults to cgroupv2, which was not
supported by those k8s releases.
This gives the user the options of either downgrading their Docker
Desktop to an older release that still used cgroupv1, or using the newer
configuration option introduced in Docker Desktop 4.4.2 for forcing the
VM back to cgroupv1.
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
We are in the process of transitioning metallb's configuration from
configmap to crds, and the main branch is just half way through it.
Here we instruct users to consume the latest stable release that uses
the configmap for configuring it.
Signed-off-by: Federico Paolinelli <fpaoline@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.
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.
Following discussions under issue #2411, documenting problem with finding rootfs
device with BTRFS (and maybe other unrecognised filesystems), along with the
workaround of adding devices as extra mounts.
Also threw in a quick reminder at the top of the page about how to obtain logs
if cluster creation fails.
kind-registry is accessed from inside docker, so
regardless of what port is used when starting it with:
-p "127.0.0.1:${reg_port}:5000"
It must always be accessed as kind-registry:5000 and not
kind-registry:${reg_port}
