Dear Kubernetes community members:
In August[0], fellow contributor Smaine Kahlouch started an incubation
proposal request to bring Kargo into the Kubernetes Incubator. It
seems that there is a requirement for a SIG to sponsor any new
incubation project. We thought that the clear choice for supporting an
Ansible-based configuration management tool for Kubernetes would be
sig-cluster-lifecycle or sig-cluster-ops.
Given the evidence that sig-cluster-lifecycle acts principally as a
workshop for developing kubeadm, I don’t think that the
cluster-lifecycle SIG is the right place to appeal for an incubation
request. I’d like to ask the general Kubernetes community who can
point us to an appropriate SIG that would take an interest in
endorsing the development of a flexible Kubernetes deployment system
geared toward production readiness?
For those not already familiar with Kargo, I would like to share a bit
about our project and its key features. Kargo deploys Kubernetes with
flexibility in node role distribution, support for popular network
plugins (Weave, Calico, Flannel), supports upgrades, several popular
operating systems, deploying in an all-containerized manner. Kargo
offers an HA apiserver through a localhost nginx reverse proxy
(workaround for [1]).
For many deployers, an idempotent tool plays a huge role in validating
deployments and uniformity. As it goes, Ansible serves as one of the
major configuration management tools du jour. The contrib/ansible
project has largely gone by the wayside without much attention in the
last several months. The Kubernetes community should definitely
consider embracing ancillary projects that deploy Kubernetes through
traditional configuration management because they do the tasks that
golang itself isn’t suited for.
I would also like to address some of the concerns you might have with
our incubation request.
Why aren’t we simply contributing to kubeadm?
Kubeadm is a tool that creates a master and joins minion Kubernetes
nodes. It does not handle package management of Docker and Kubernetes
core components. While it still lacks upgrades and HA, those are
definitely areas that really deserve attention. I have every intention
of implementing kubeadm in Kargo if and when it becomes “production
ready”. Additionally, my colleagues and I are looking at where we can
make effective contributions there already.
What about kubernetes/contrib/ansible?
The entire contrib project was excluded from incubation. If they were
automatically included, we would have merged efforts with that team.
I’ve already had several conversations with those developers and
discovered that it is not very actively maintained. I highly
anticipate we will consolidate those efforts and feature sets if and
when Kargo reaches incubation.
We already have lots of deployment tools in kubernetes GitHub space.
Why is Kargo different?
There are several repositories with deployment tools located in
github.com/kubernetes space, including in kube-deploy, kops, and
contrib. None of these are incubated and most come from a single
vendor. Kargo has a considerably more diverse contributor base and a
strong roadmap[2].
[0]
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-dev/UqyPxAqwXLo/qAgRfoCBCAAJ
[1]
https://github.com/kubernetes/kubernetes/issues/19989
[2]
https://github.com/kubespray/kargo/blob/master/docs/roadmap.md
Best Regards,
Matthew Mosesohn