A kind cluster created from scratch does not have an internal Docker registry, containerd certs.d mirror, or ingress-nginx configured. Without these, ops setup fails with 'connection refused' on every test (redis, postgres, login, etc.).
Known manual procedure to get a working cluster:
helm install docker-registry + expose via NodePort- On every node: create a containerd
certs.d/<registry-host>/hosts.toml mirror pointing to the NodePort, add config_path in /etc/containerd/config.toml, restart containerd
kubectl apply the ingress-nginx manifest + label the control-plane node ingress-ready=true
It's not clear whether this should be automated inside ~/kind-reset.sh (or an equivalent bootstrap script) or whether it's already handled elsewhere in the project and I'm missing it. If it's not automated anywhere, it might be worth adding a documented bootstrap script for kind-based development, since right now every contributor working with kind seems to have to rediscover this manually.
A kind cluster created from scratch does not have an internal Docker registry, containerd certs.d mirror, or ingress-nginx configured. Without these,
ops setupfails with 'connection refused' on every test (redis, postgres, login, etc.).Known manual procedure to get a working cluster:
helm install docker-registry+ expose via NodePortcerts.d/<registry-host>/hosts.tomlmirror pointing to the NodePort, addconfig_pathin/etc/containerd/config.toml, restart containerdkubectl applythe ingress-nginx manifest + label the control-plane nodeingress-ready=trueIt's not clear whether this should be automated inside
~/kind-reset.sh(or an equivalent bootstrap script) or whether it's already handled elsewhere in the project and I'm missing it. If it's not automated anywhere, it might be worth adding a documented bootstrap script for kind-based development, since right now every contributor working with kind seems to have to rediscover this manually.