Hi, I also have a preference for minikube – even if Kind has the ability of launching multi-node clusters, which minikube can't do.
Historically, Kind was used in one single place: the run.sh script at the root of the repo. I think it was chosen so that we can launch a local Docker registry (cf. the companion kind-registry.sh script) to upload Docker images for Polaris. But minikube has a much easier way of achieving that [1], so my take is that we don't need Kind at all at this point. Thanks, Alex [1]: https://minikube.sigs.k8s.io/docs/handbook/pushing/#1-pushing-directly-to-the-in-cluster-docker-daemon-docker-env On Mon, Jul 7, 2025 at 11:57 PM Yufei Gu <flyrain...@gmail.com> wrote: > +1 on picking one, instead of having both. I don't have any preference > though. > > Yufei > > > On Mon, Jul 7, 2025 at 1:37 PM Dmitri Bourlatchkov <di...@apache.org> > wrote: > > > My personal preference is minikube. > > > > Cheers, > > Dmitri. > > > > On Sat, Jul 5, 2025 at 8:22 PM Yong Zheng <yzh...@apache.org> wrote: > > > > > Hello, > > > > > > Currently, we provide Kubernetes references for both Kind ( > > > https://kind.sigs.k8s.io/) and Minikube ( > > > https://minikube.sigs.k8s.io/docs/). In terms of tooling, Kind is very > > > lightweight, whereas Minikube is much more feature-rich and works out > of > > > the box. (Some workarounds or additional steps are required to make > Kind > > do > > > the same, but those details are out of scope for this discussion.) > > > > > > In terms of the features and documentation we offer to others, either > > > option will work. However, I think the overhead of maintaining support > > for > > > both tools is unnecessary. I don’t have a strong preference for which > one > > > we choose, but I believe it will be easier to support additional > > automation > > > if we stick to a single tool. > > > > > > Thanks, > > > Yong Zheng > > > > > >
