Tanzu Community Edition

Documentation

Architecture

Tanzu Community Edition consists of a variety of components that enable the bootstrapping and management of Kubernetes clusters and the various platform services ran atop. This page details the architecture of:

  • Tanzu CLI
  • Managed Clusters
  • Standalone Clusters
  • Package Management

Tanzu CLI

The tanzu CLI command exposes multiple subcommands.

$ tanzu

Tanzu CLI

Usage:
  tanzu [command]

Available command groups:

  Admin
    builder                 Build Tanzu components
    codegen                 Tanzu code generation tool
    test                    Test the CLI

  Run
    cluster                 Kubernetes cluster operations
    kubernetes-release      Kubernetes release operations
    management-cluster      Kubernetes management cluster operations
    package                 Tanzu package management
    standalone-cluster      Create clusters without a dedicated management cluster

  System
    completion              Output shell completion code
    config                  Configuration for the CLI
    init                    Initialize the CLI
    login                   Login to the platform
    plugin                  Manage CLI plugins
    update                  Update the CLI
    version                 Version information


Flags:
  -h, --help   help for tanzu

Use "tanzu [command] --help" for more information about a command.

Not logged in

Each subcommand provides functionality for Tanzu Community Edition. This functionality can range from creating clusters to managing the software running in clusters. Subcommands in tanzu are independent static binaries hosted on a client system. This enables a pluggable architecture where plugins can be added, removed, and updated independent of each other. The tanzu command is expected to be installed in machine’s path. Each subcommand (binary) is expected to be installed in ${XDG_DATA_HOME}/tanzu-cli. This relationship is demonstrated below.

CLI Architecture

Click here to see where $XDG_DATA_HOME resolves to.

Tanzu Community Edition ships with the tanzu CLI and a select set of plugins. Some plugins may live in the vmware-tanzu/community-edition repository while others live in vmware-tanzu/tanzu-framework. Plugins that live in vmware-tanzu/tanzu-framework may be used in multiple Tanzu Editions. Plugins that live in vmware-tanzu/community-edition are used exclusively in Tanzu Community Edition. Plugins in vmware-tanzu/community-edition may be promoted (moved) to vmware-taznu/tanzu-framework. This move would not impact users of Tanzu Community Edition; it would only impact contributors to the plugin. Additionally, plugins may live in repositories outside of vmware-tanzu/community-edition and vmware-tanzu/tanzu-framework.

Managed Clusters

Clusters that are deployed and managed using tanzu cluster command(s) are known as managed clusters. These clusters are deployed and managed by a Tanzu management cluster (originally deployed using tanzu management-cluster. This is the primary deployment model for clusters in the Tanzu ecosystem and is recommended for production scenarios. To bootstrap managed clusters, you first need a management cluster. This is done using the tanzu management-cluster create command. When running this command, a bootstrap cluster is created locally and is used to then create the management cluster. The following diagram shows this flow.

Bootstrap cluster create

Once the management cluster has been created, the bootstrap cluster will perform a move (aka pivot) of all management objects to the management cluster. From this point forward, the management cluster is responsible for managing itself and any new clusters you create. These new clusters, managed by the management cluster, are referred to as workload clusters. The following diagram shows this relationship end-to-end.

Management cluster bootstrapping

Standalone Clusters

Clusters that run without a long-running management cluster are considered standalone clusters. This is an experimental cluster deployment model currently being iterated on by the Tanzu Community Edition team. This model provides a few benefits including:

  • Faster time to cluster (relative to managed clusters)
  • Reduced system requirements

Experiments and new development are actively being run to achieve the above. As such, this is not a recommended deployment model for production workloads.

Creating a standalone cluster is done using the tanzu standalone-cluster create command. When running this command, a bootstrap cluster is created locally and is then used to create the standalone cluster. After successful bootstrapping, the bootstrap cluster is deleted. Management resources are not moved into the standalone cluster. This newly created cluster can be referred to as a workload cluster. The following diagram shows this relationship.

Standalone cluster flow

When you’d like to delete or scale the workload cluster, a new bootstrap cluster is created and the workload cluster is deleted or scaled. This bootstrap cluster can be thought of as a temporary management cluster. Users should expect a delay in the operation as there will be time lost to re-creating the boostrap cluster. The following diagram shows this relationship.

Standalone scale example flow

Standalone clusters are implemented using a similar code path to that of management-clusters. However, we short-circuit the cluster creation to not fully “pivot” the newly created cluster into something that manages other clusters.

Package Management

Tanzu Community Edition provides package management to users via the tanzu CLI. Package management is defined as the discovery, installation, upgrading, and deletion of software that runs on Tanzu clusters. Each package is created using carvel tools and following our packaging process. Packages are put into a single bundle, called a package repository and pushed to an OCI-compliant registry. In Tanzu clusters, kapp-controller is constantly watching for package repositories. When a cluster is told about this package repository (likely via the tanzu package repository command), kapp-controller can pull down that repository and make all the packages available to the cluster. This relationship is shown below.

kapp-controller repo read

With the packages available in the cluster, users of tanzu can install various packages. Within the cluster, a PackageInstall resource is create and it instructs kapp-controller to download the package and install the software in your cluster. This flow is shown below.

tanzu package install

Ready to dive in?

Our documentation is a great place to start!

Documentation