Configuring and managing your Kubernetes clusters can be a complex, time-consuming task. We aim to provide a simple way for users to configure their clusters within GitLab; tasks such as scaling, adding, and deleting clusters become simple, single-click events.
Related grab-bad epic gitlab.com/groups/gitlab-org/-/epics/253
Interested in joining the conversation for this category? Please join us in our public epic where we discuss this topic and can answer any questions you may have. Your contributions are more than welcome.
In order to make the applications provided as part of GitLab-managed apps customizable, we are evolving the Kubernetes integration to manage all install/upgrade/uninstall actions via GitLab CI. This will provide not only the ability to customize applications, but will also provide version control, security, and all the GitLab features we know and love. The next step in this journey is to create CI templates for all the applications we support today.
These features will take our Kubernetes integration to viable maturity.
This category is currently at the "Viable" maturity level, and our next maturity target is Complete.
GitLab is the most popular way to deploy to Kubernetes. Many organizations (of all scales) have adopted Kubernetes prior to their use of our GitLab. We will support this model by identifying the most common set of use cases where Kubernetes clusters exist. We'll then enable those existing clusters to be plugged in to GitLab so users can gain the value of using our integrated development approach. This includes both enterprise users of Kubernetes (typically OpenShift) and startup Kubernetes use (typically public cloud providers).
Our Kubernetes integration currently operates under the assumption of
cluster-admin privilege. While this is acceptable
for most use cases, there is a large minority that, appropriately, operates strictly on least-privilege security
principle. In these environments only single-namespace access is allowed and cluster-wide access is denyed. To encourage
adoption of these principles, we will provide the same rich integration we provide today for this further restricted use
Kubespray provides a set of Ansible roles for Kubernetes deployment and configuration. Kubespray can use AWS, GCE, Azure, OpenStack or a bare metal Infrastructure as a Service (IaaS) platform. Kubespray is an open-source project with an open development model. The tool is a good choice for people who already know Ansible as there’s no need to use another tool for provisioning and orchestration. Kubespray uses kubeadm under the hood.
Kubeadm is a Kubernetes distribution tool since version 1.4. The tool helps to bootstrap best-practice Kubernetes clusters on existing infrastructure. Kubeadm cannot provision infrastructure for you though. Its main advantage is the ability to launch minimum viable Kubernetes clusters anywhere. Add-ons and networking setup are both out of Kubeadm’s scope though, so you will need to install this manually or using another tool.
Kops helps you create, destroy, upgrade, and maintain production-grade, highly available Kubernetes clusters from the command line. Amazon Web Services (AWS) is currently officially supported, with GCE in beta support, and VMware vSphere in alpha, and other platform support is planned. Kops allows you to control the full Kubernetes cluster lifecycle; from infrastructure provisioning to cluster deletion.
Conjure-up is a Canonical product which allows you to deploy “The Canonical Distribution of Kubernetes on Ubuntu” with a few simple commands. It supports AWS, GCE, Azure, Joyent, OpenStack, VMware, bare metal, and localhost deployments. Juju, MAAS, and LXD are the underlying technology for Conjure-up.
This category doesn't quite fit the "configuration management" area as it relates only to Kubernetes. No analyst area currently defined.