FeaturesKubeOneKubesprayKindKubeadmOpenShift OriginAirship
Declarative Cluster Configuration - describing the K8s cluster including infra components (eg. CRI, CNI), versions, number of nodes (master+worker), architecture, K8s certificatesYYNNYY. Uses Kustomize for layering and substitution.
Templated configurationYYNNYY. Uses Kustomize
Centralized configuration modelYYYNYY
Ability to use existing machines (from machine provisioning stage)
YYYYTBD. Recognizes the use case of "bring your own OS", but not committed to implementing in v2.0.
Ability to manage underlying infrastructure (i.e. to create and configure nodes for use by a cluster)YNunknownNdepends on infra providerYes, integrates cluster-api-provider-metal3
Support for different architectures: Arm and x86YNNYunknownN.  ARM is out of scope for v2.0. Operators are welcome to step up and add the support.
K8s clusters pass conformance testYYYYunknownTBD, May run internally.
100% open sourceYYYYYY
Support all CNCF-hosted projectsY


unknownYes. Airship architecture allows users to deploy additional extensions and add-ons. If an extension has Helm charts, it can be optionally added to Airship life cycle management experience.







Support for specific versions of K8sYNYYYY
Specific versions of K8s componentsY


YY
etcdYYYYYY
Support for deploying from HEAD / `master` branch of K8sYNYYunknown?
Container runtimes (containerd, cri-o) with specific versionsYYNYYY, uses cluster api kubeadm provider
Kubernetes add-ons/extensions installation (e.g. CNI, CSI, Service Mesh, Ingress, LB, etc.)
partially


Y







Hybrid Support both VNF and CNF




Y
Customizable - pick and choose what and when to use for installation




Y







  • No labels

4 Comments

  1. Victor Morales

    I've successfully deployed a cluster in a Raspberry Pi setup using Kubespray with the exception of the CNI, I submitted the PR but it's not clear how they're going to manage the upgrade process.

  2. Victor Morales

    IMHO, Day-2 and Multi OSes support need to be considered as part of the features in this table

  3. Victor Morales

    Kubespray uses the `kube_version` to specify the Kubernetes version to be used and this is its kubeadm's table support

  4. Fatih Degirmenci

    few more notes about kubepsray based on what is listed on the table

    • Support for specific versions of K8s: this is supported by Kubespray as oppose to what's written on the table. One of the reasons why it may be marked as N on the table could be that Kubespray community deprecates support for older versions of Kubernetes but it still has capability to deploy selected version of Kubernetes if the right version of Kubespray is used.
    • Support for deploying from HEAD / `master` branch of K8s: I believe Kubespray supports this as well. You need to modify the values in https://github.com/kubernetes-sigs/kubespray/blob/master/roles/download/defaults/main.yml as they pin shas of container images.
    • Specific versions of K8s components: similar to previous points, you have possibility to use different versions of K8s components by overriding the values.
    • Support for different architectures: Arm and x86: Kubespray supports Arm as well. (which is what Victor mentioned as well)
    • Support all CNCF-hosted projects: this depends on what "all CNCF-hosted projects" means in this context.

    Regarding "Ability to manage underlying infrastructure (i.e. to create and configure nodes for use by a cluster)": I believe they made a conscious decision to do Kubernetes installation and leave the provisioning, configuration, and management of underlying infrastructure to other tools that are built for that purpose.