Tanzu Platform 10.0

PDF
self.managed.10.1 10.0 saas

Installing Tanzu Platform Self-Managed

Last Updated March 03, 2025

After you have prepared your cluster to run Tanzu Platform Self-Managed, as described in Preparing Your Cluster to Host Tanzu Platform Self-Managed, you can proceed with the installation.

These instructions assume the use of two machines, a bootstrap machine for installation and a jumpbox for downloading, as you would use in an air-gapped environment. If your environment is not air-gapped, you can use the same machine for both.

Download and stage the installation images

Download and extract the installer for Tanzu Platform Self-Managed.

  1. Download the installer.
    You can download the installer from the Broadcom support download site at the following URL:

    https://support.broadcom.com/group/ecx/productdownloads?subfamily=Tanzu%20Platform%20Self%20Managed

  2. After the download completes, create a directory and extract the tarball into the directory. For example:

    mkdir tanzu-installer 
tar -xzvf <INSTALLER-BUNDLE-FILENAME>.tar.gz -c ./tanzu-installer

The extracted tarball in your installer directory contains the following components:

  • the tanzu-sm-installer installer
    This file is located under the cli_bundle directory for each OS.
  • a config.yaml file
    This configuration file allows you to specify details about your specific installation prior to running the installer.
  • tanzusm-collector.tar and agent-images.tar These tarballs contain the collector and extension images.
  • the tanzusm-<VERSION>.tar image bundle This tarball contains installer images.
  • a tanzu-bundle folder This folder has the tarballs that contain the binaries and plugins that you need to enable your organization to use the tanzu CLI.
  • an additional-resources folder

Push the installation images to your local image registry

Push the tarballs required for deployment and setup to your local image registry. You can perform this step directly from your jumpbox, if it has access to the registry. Otherwise, you must move them to the bootstrap machine first.

Before you begin, make sure you have already set up a local image registry, as described in Set up a local image registry.

  1. From the bootstrap machine, verify connectivity to your local image registry (for example, Harbor) using a docker login command. For example: 
    docker login <path-to-local-repo>
  2. Push installer image bundle to the registry. For example: 
    imgpkg copy --tar tanzusm-<VERSION>.tar --to-repo=<path-to-local-repo>

Edit the configuration file

The config.yaml file contains details about your specific installation. Edit this file to customize your installation. At a minimum, you must provide settings for the ingress controller and identity provider.

Profile and flavor configuration

      #Supported values are "full" or "essentials"
      flavor: full
      #supported values are "evaluation", "foundation", "regular" or "enterprise"
      profile: foundation

Seeded administrator identity and password

Tanzu Platform Self-Managed provides a seeded admin user that you can use for the initial setup.

Define the password for the seeded administrator identity in the config.yaml prior to deploying Tanzu Platform Self-Managed.

login:
  defaultUsers:
    username: tanzu_platform_admin
    admin:
      #Tanzu Platform Admin  Password, Random password will be generated if empty value provided
      #Note that this password cannot be changed later, its one time set ( both system generated and user provided one)
      password: ""

If you do not define a password, one is generated during the installation and written back to the config.yaml file. The generated password is base64 encoded. To decode the password just remove the encoded: prefix and decode the remaining string.

Certificates

The certificate provided in config.yaml file must be provided as string literal in YAML format. For example:

      certificate: |
      -----BEGIN CERTIFICATE-----
      MIIC3DCCAcSgAwIBAgIBADANBgkqhkiG9w0BAQsFADAZMRcwFQYDVQQDDA4xMC4y
      MjAuMjEyLjEyMDAeFw0yNDA5MjUxNjI1MTdaFw0yNDEwMjUxNjI1MTdaMBkxFzAV
      BgNVBAMMDjEwLjIyMC4yMTIuMTIwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
      CgKCAQEAsA9Q8QpTNRSvEIjT4OmMFyT4OIhfkQ/0EGUewZcU4Ju7GxOZpds1Esrr
      5KdeyK+iM3JJEbEoh1ZJUEorDQvIGhLO5zAotwew4AhAwjX/zHe5Vzvs3vdxvo2q
      en/T8lqzrWCK9ab+fp/Rbmmi6X4foCwaVgmsm8y0t+03+j2nowb2tw7URcUmKdga
      D84JLKVAmEKIXaI1KcQr9YQGuME5SPSNxpFgRHirXTPHXDu7OMt13Agf2nszpXly
      QFZ3bt5hzYRW/zLXM+weYo1CaOZ5I/tVXfrj8grCIvZv8Ze1aHHqHvKO6zuqK0S4
      OOmJYrWF9x5FYR4DfoUyRQ4T8/6HxwIDAQABoy8wLTAMBgNVHRMBAf8EAjAAMB0G
      A1UdDgQWBBQiUqAIOYy+qesTi6Ba1BpLJxuzrDANBgkqhkiG9w0BAQsFAAOCAQEA
      qsJQChldlYDjWsRW9d6rkHOmOLaCqpU84rab5Kb+yRgKOABsh8yLoW0tvH6QZsEg
      FFJM144N+VHtcG/OZEg+eFswy/gLMVW0mET+iGf47D1/VTLF4NAoGVcRx4N/8+nq
      GT85g/9bmwEtCrseuu5bZ/LDWdGpoqgPVp7DsAhuM/N5tg+9KKnjmFqQov+aZ9MK
      0P493hr0IwxPXvCql6tdy7n1dsggltt+/iANGqO5FAxSTKSFiRHF11ecjdYjybHd
      Tt0q9UELigtwHrqhIT/iuLPhZCPb0hEhMblAVvImRYwgGZCwvASgPM0/RI2pHpse
      BSochNiBi2zWCBe7opmGmQ==
      -----END CERTIFICATE-----

Also provide the certificate for the registry that you intend to use.

   CustomRegistryCertificate: |
   -----BEGIN CERTIFICATE-----
   ....
   ....
   -----END CERTIFICATE-----

If you are configuring VCF Collectors, make sure you are using SAN certificate.

If you are using an intermediate CA, the root CA or intermediate CAs in the chain must also be included when configuring a certificate.

Trivy DB settings for air-gapped installation

   #Daedalus Settings
 trivy:
   # Optional OCI repository to retrieve trivy-db from. Its url can be external or internal for airgapped deployment (default "ghcr.io/aquasecurity/trivy-db")
   # This repositroy should be periodically synced from ghcr.io/aquasecurity/trivy-db to get latest vulnerability for airgapped deployment.
   dbRepository: ""
   # When using SSL/TLS, Trivy can be configured to allow insecure connections to a container registry if there is no valid certificate available
   # Set allowInsecureConnections to true to allow insecure server connections; false, otherwise
   allowInsecureConnections: false

Ingress controller settings

Update the load balancer IP address, host, and optionally, the tls certificate.

  ingress:
  # Static IP address that needs to be assigned to contour load balancer
  # The host associated with this IP will be used for accessing UI and other ingress objects.
  # This is optional and If not provided, random IP address from available IP pool will be assigned to contour load balancer.
  loadBalancerIP: ""

  # DNS name that can reach the system.  If unset, and
  # `controller` is enabled, then get the external name from
  # the installed ingress controller.
  host: ""

  # TLS certificate configuration for the specified `host`
  # If unset, the cluster will generate a self-signed certificate on its own.
  tls:
    certificate: ""
    privateKey: ""

Identity provider settings

Tanzu Platform Self-Managed authenticates users using UAA as the identity broker. UAA requires an existing OIDC-compliant identity provider (IDP), and expects the issuer URL, clientID, and clientSecret to integrate with your IDP.

You can use Okta, AD, or LDAP.

LDAP settings

  login:
   ldap:
     url: 'ldap://openldap:1389/'
     credentials:
       userDN: 'cn=admin,dc=tanzu,dc=net'
       password: password
     users:
       baseDN: 'dc=tanzu,dc=net'
       searchFilter: 'cn={0}'
       mailAttribute: mail
     groups:
       baseDN: 'dc=tanzu,dc=net'
       searchFilter: 'member={0}'
       searchDepth: 10

Okta settings

   login:
   oauthProviders:
     - name: okta.test
       configUrl: 'https://my-server.okta.com/.well-known/openid-configuration'
       issuerUrl: 'https://my-server.okta.com'
       scopes:
         - openid
         - email
         - groups
       loginPageLinkText: Login with Dev Okta
       clientId: <your-client-id>
       secret: <your-client-secret>
       attributeMappings:
         username: email
         groups: groups

Storage configurations

    # Infra components
    postgresql:
      storageClass: "postgresql-storage-class"
    clickhouse:
      storageClass: "clickhouse-storage-class"
    redis:
      storageClass: "redis-storage-class"
    opensearch:
      storageClass: "opensearch-storage-class"
    seaweedfsS3:
      storageClass: "seaweedfs-storage-class"
    prometheus:
      storageClass: "prometheus-storage-class"
      tmcStorageClass: "tmc-prometheus-storage-class"
    kafka:
      storageClass: "kafka-storage-class"
    zookeeper:
      storageClass: "zk-storage-class"

Verify your deployment environment

Before deploying the stack to your cluster, verify your setup with an installer command.

Before you begin

The verify command shown below contains the following variables that you must set to fit your specific environment. You can either set these as environment variables or replace the variables directly in the command.

  • TANZU_SM_VERSION - The version of Tanzu Platform Self-Managed that you are installing. You can get the version from the config.yaml file.
  • LOCAL_REGISTRY - The name of (and path to) your local image registry.
  • REGISTRY_USERNAME - The username that the installer will use to pull images from your local image registry.
  • REGISTRY_API_TOKEN - The API token that the installer will use to pull images from your local image registry.

  • KUBECONFIG - The name of (and path to) the kubeconfig file for the workload cluster on which you are installing Tanzu Platform Self-Managed. If you do not specify a kubeconfig file, the installer uses your current kubeconfig.

  • Run the following command to verify your setup.

    tanzu-sm-installer verify -f config.yaml \ 
-u "${REGISTRY_USERNAME}:${REGISTRY_API_TOKEN}" \ 
-r ${LOCAL_REGISTRY}/hub-self-managed/${TANZU_SM_VERSION}/repo \ 
--install-version ${TANZU_SM_VERSION} \ 
--kubeconfig ${KUBECONFIG}

For information on how to interpret the output from the verify command, see Understanding installation pre-check output.

Deploy the Tanzu Platform Self-Managed stack to your cluster

After downloading and staging the installation images and editing the config.yaml file, run the installer.

Before you begin

The install command shown below contains the following variables that you must set to fit your specific environment. You can either set these as environment variables or replace the variables directly in the command.

  • TANZU_SM_VERSION - The version of Tanzu Platform Self-Managed that you are installing. You can get the version from the config.yaml file.
  • LOCAL_REGISTRY - The name of (and path to) your local image registry.
  • REGISTRY_USERNAME - The username that the installer will use to pull images from your local image registry.
  • REGISTRY_API_TOKEN - The API token that the installer will use to pull images from your local image registry.

Procedure

  1. Make sure the KUBECONFIG environment variable is set to the Kubernetes configuration of the cluster where you want to install Tanzu Platform Self-Managed.
  2. Run the following command to deploy Tanzu Platform Self-Managed to your cluster. 
    tanzu-sm-installer install -f config.yaml \ 
-u "${REGISTRY_USERNAME}:${REGISTRY_API_TOKEN}" \ 
-r ${LOCAL_REGISTRY}/hub-self-managed/${TANZU_SM_VERSION}/repo \ 
--install-version ${TANZU_SM_VERSION} --yes

The terminal displays logs showing the installation progress.

Verify your Tanzu Platform Self-Managed deployment

  1. Run the following command to verify your deployment. 
    tanzu-sm-installer post-verify --kubeconfig ${KUBECONFIG}

What’s Next

After you have successfully deployed Tanzu Platform Self-Managed, continue to Setting up Tanzu Platform Self-Managed for your organization for the first login and some final set up tasks to make Tanzu Platform available to your organization.