Installing Tanzu Application Service for Kubernetes

This topic describes how to install Tanzu Application Service for Kubernetes (TAS for Kubernetes) from the VMware Tanzu Network and from a relocated image in a private container image registry.

Overview

To configure installation settings and install TAS for Kubernetes:

  1. Prepare the Installation
  2. Generate Internal Configuration Values
  3. Install TAS for Kubernetes

Prerequisites

Before you install TAS for Kubernetes, you must:

Prepare the Installation

To prepare for installing TAS for Kubernetes:

  1. Verify that your root directory contains configuration-values and tanzu-application-service directories.
  2. Change directory to the tanzu-application-service directory.
  3. To enable support for backing up and restoring TAS for Kubernetes, copy the disaster-recovery.yml file from the config-optional directory to the config directory:

    cp config-optional/disaster-recovery.yml config/disaster-recovery.yml
    

Generate Internal Configuration Values

TAS for Kubernetes requires internal configuration values, credentials and certificates to coordinate its components. These configuration values, credentials and certificates must be supplied to the TAS for Kubernetes installation script.

To generate the internal values, credentials and certificates needed during TAS for Kubernetes installation, use a helper script in the installation resources:

  1. Change directory to the tanzu-application-service directory.
  2. To create new configuration files, run:

    ./bin/generate-values.sh CONFIG-VALUES-PATH
    


    Where CONFIG-VALUES-PATH is the path to the configuration-values directory. For example, ../configuration-values.
    The generate-values script creates:

    • _generated-values.yml: The _generated-values.yml file contains generated configuration values that will be read during installation. The default location for the _generated-values.yml file is: ../configuration-values/_generated-values.yml.
    • tas-vars: The tas-vars data store contains credentials and certificates that are not used during TAS for Kubernetes installation but may be needed for future value generation. The default location for the tas-vars data store is: ../configuration-values/vars-store/tas-vars.
    • Certificates: Self-signed system-certificate and workload-certificate certificates are created if you did not provide these certificates when completing the steps in Configuring Installation Values.

Ensure all of the generated files in the configuration-values directory are stored securely. These files contain important installation secrets and should be preserved for future installations.

Warning: Do not rotate encryption keys in the Kubernetes stack in this version of TAS for Kubernetes. The capi.database.encryption_key value should not be modified after it is initially set because the Cloud API fails during cf push for Kubernetes clusters with a modified encryption key.

Warning: Do not rotate the blobstore secret key in this version of TAS for Kubernetes. The blobstore.secret_access_key value should not be altered after it is initially set because redeployments fail when using configurations with a modified blobstore secret key.

Install TAS for Kubernetes

To install TAS for Kubernetes:

  1. Follow the procedure appropriate for the configuration you created:

  2. Configure DNS for the TAS for Kubernetes Ingress Gateway

  3. Validate Your TAS for Kubernetes Installation

Install TAS for Kubernetes from the VMware Tanzu Network

To install TAS for Kubernetes from the VMware Tanzu Network:

  1. To validate your configuration:

    kubectl cluster-info
    

    Inspect the output. Ensure that your Kubernetes client configuration targets the intended cluster for installation.

  2. Change directory into the tanzu-application-service directory.

  3. To create a cluster configurations file:

    ./bin/cluster-detect.sh > ../configuration-values/cluster-values.yml
    

    The cluster-detect script communicates with the kube API to determine deployment values and saves those values in a cluster-values configuration file.

  4. To install TAS for Kubernetes, run the installation script:

    ./bin/install-tas.sh ../configuration-values
    

    The command installs TAS for Kubernetes using the deployment values you generated previously.

Install TAS for Kubernetes from a Private System Registry

After uploading your TAS for Kubernetes images to the private registry, you can install TAS for Kubernetes using a modified installation procedure.

To install TAS for Kubernetes:

  1. To validate your configuration:

    kubectl cluster-info
    

    Inspect the output. Ensure that your Kubernetes client configuration targets the intended cluster for installation.

  2. Change directory into the tanzu-application-service directory.

  3. To create a cluster configurations file:

    ./bin/cluster-detect.sh > ../configuration-values/cluster-values.yml
    

    The cluster-detect script communicates with the kube API to determine deployment values and saves those values in a cluster-values configuration file.

  4. To deploy TAS for Kubernetes using the images in the private registry:

    ytt -f config \
          -f ../configuration-values | \
          kbld -f- -f relocated_images.yml > /tmp/final_deployment.yml
    kapp deploy -a cf -f /tmp/final_deployment.yml
    

Configure DNS for the TAS for Kubernetes Ingress Gateway

To configure DNS entries for the TAS for Kubernetes ingress gateway:

Configure the Ingress Gateway DNS With a Kubernetes Load Balancer

This section describes how to configure DNS if you have configured TAS for Kubernetes to use a Kubernetes LoadBalancer Service for the ingress gateway.

To configure DNS with your system domain resolving to the external IP address of the load balancer:

  1. To retrieve the value of the external IP address or hostname assigned to the Istio ingress gateway service:

    kubectl -n istio-system get service istio-ingressgateway -ojsonpath='{.status.loadBalancer.ingress[0].ip}'
    kubectl -n istio-system get service istio-ingressgateway -ojsonpath='{.status.loadBalancer.ingress[0].hostname}'
    

    For example:

    $ kubectl -n istio-system get service istio-ingressgateway -ojsonpath='{.status.loadBalancer.ingress[0].ip}'
    10.193.105.162
    $ kubectl -n istio-system get service istio-ingressgateway -ojsonpath='{.status.loadBalancer.ingress[0].hostname}'
    ae7b1093f9c3b44fd9982b828b32ccad-2445920965.us-west-2.elb.amazonaws.com
    

  2. In your DNS zone, create an entry for your system domain:

    • If you have an external IP address, create a wildcard A record for the system domain, resolving to the external IP address:

      *.SYSTEM-DOMAIN
      

      Where SYSTEM-DOMAIN is the system domain.

    • If you have a hostname, create a wildcard CNAME record for the system domain, resolving to the hostname:

      *.SYSTEM-DOMAIN
      

      Where SYSTEM-DOMAIN is the system domain.

    Ensure you include the *. wildcard prefix in the new record so that all subdomains of the system domain also resolve to the load balancer.

For information about configuring TAS for Kubernetes to use a Kubernetes LoadBalancer Service for the ingress gateway, see Use a LoadBalancer Service for the Ingress Gateway,

Configure the Ingress Gateway DNS With an External Load Balancer

This section describes how to configure DNS if you have an external load balancer to use for ingress to the TAS for Kubernetes installation and have deployed TAS for Kubernetes without a Kubernetes LoadBalancer service for the ingress gateway.

To configure the external load balancer to forward HTTP and HTTPS traffic to the Kubernetes worker nodes:

  1. To retrieve the list of existing worker nodes with their internal IP addresses:

    kubectl get nodes --output='wide'
    

    For example:

    $ kubectl get nodes --output='wide'
    NAME                                   STATUS   ROLES    AGE     VERSION   INTERNAL-IP    EXTERNAL-IP
    5e329c31-f1d7-4548-936b-3a58d4b166d3   Ready    <none>   5h49m   v1.15.5   10.85.87.133   10.85.87.133
    a6ad3f07-787c-4d90-b8e1-032be34e9d7f   Ready    <none>   5h43m   v1.15.5   10.85.87.134   10.85.87.134
    a8eb78a2-e3b4-4d8a-8c32-67bf0e13c0bf   Ready    <none>   5h43m   v1.15.5   10.85.87.135   10.85.87.135
    af7dc8da-a7b0-4cf2-a940-c9248168e609   Ready    <none>   5h43m   v1.15.5   10.85.87.136   10.85.87.136
    cc6ef11f-e253-4553-9cb0-bebc7d958f64   Ready    <none>   5h42m   v1.15.5   10.85.87.137   10.85.87.137
    

  2. Configure your external load balancer to forward traffic on TCP ports 80 and 443 to the set of internal IP addresses for the Kubernetes worker nodes.

  3. Configure DNS records in your DNS zone:

    • If your load balancer has a static IP, create a wildcard A record for the system domain, resolving to the external IP address of the load balancer:

      *.SYSTEM-DOMAIN
      

      Where SYSTEM-DOMAIN is the system domain.

    • If your load balancer has a DNS name instead of static IP, such as an AWS load balancer, create a wildcard CNAME record for the system domain, resolving to the external IP address of the load balancer:

      *.SYSTEM-DOMAIN
      

      Where SYSTEM-DOMAIN is the system domain.

    Ensure you include the *. wildcard prefix in the new record so that all subdomains of the system domain also resolve to this IP address.

Configure the Ingress Gateway DNS Without a Load Balancer

This section describes how to configure your DNS if you do not have an external load balancer to use for ingress and have deployed TAS for Kubernetes without a Kubernetes LoadBalancer service for the ingress gateway.

To set up your DNS records to establish ingress connectivity directly to the worker nodes:

  1. To retrieve the list of existing worker nodes with their external IP addresses:

    kubectl get node --selector='!node-role.kubernetes.io/master' -o wide
    

    For example:

    $ kubectl get node --selector='!node-role.kubernetes.io/master' -o wide
    NAME                                   STATUS   ROLES    AGE     VERSION   INTERNAL-IP    EXTERNAL-IP
    5e329c31-f1d7-4548-936b-3a58d4b166d3   Ready    <none>   5h49m   v1.15.5   10.85.87.133   10.85.87.133
    a6ad3f07-787c-4d90-b8e1-032be34e9d7f   Ready    <none>   5h43m   v1.15.5   10.85.87.134   10.85.87.134
    a8eb78a2-e3b4-4d8a-8c32-67bf0e13c0bf   Ready    <none>   5h43m   v1.15.5   10.85.87.135   10.85.87.135
    af7dc8da-a7b0-4cf2-a940-c9248168e609   Ready    <none>   5h43m   v1.15.5   10.85.87.136   10.85.87.136
    cc6ef11f-e253-4553-9cb0-bebc7d958f64   Ready    <none>   5h42m   v1.15.5   10.85.87.137   10.85.87.137
    

  2. Create a wildcard A record for the system domain in your DNS zone, resolving to the set of external IP addresses for the worker nodes:

    *.SYSTEM-DOMAIN
    

    Where SYSTEM-DOMAIN is the system domain. Include the *. wildcard prefix so that all subdomains of the system domain also resolve to the IP addresses.

Validate Your TAS for Kubernetes Installation

Note: Managing apps and services on TAS for Kubernetes requires cf CLI v7.0.1 or later.

To validate your TAS for Kubernetes installation:

  1. Use cf CLI to target the installation at the api subdomain of the system domain:

    cf api api.SYSTEM-DOMAIN --skip-ssl-validation
    

    Where SYSTEM-DOMAIN is your TAS for Kubernetes installation system domain.

  2. Change directory into the directory containing the tanzu-application-service and configuration-values directories.

  3. To set the CF_ADMIN_PASSWORD environment variable to the CF administrative password stored in the cf_admin_password key in the configuration-values/_generated-values.yml file:

    CF_ADMIN_PASSWORD="$(bosh interpolate configuration-values/_generated-values.yml \
            --path /cf_admin_password)"
    
  4. Log into the installation as the admin user:

    cf auth admin "$CF_ADMIN_PASSWORD"
    
  5. Create and target an organization and space for the verification application.

    For example:

    $ cf create-org test-org
    $ cf create-space -o test-org test-space
    $ cf target -o test-org -s test-space
    

  6. To clone the Cloud Foundry test application from GitHub to your workstation:

    git clone https://github.com/cloudfoundry-samples/test-app.git
    

    For more information see Cloud Foundry test application on GitHub.

  7. Change directory into the resulting test-app directory.

  8. To push the test app to your TAS for Kubernetes installation:

    cf push test-app --hostname test-app
    
  9. To validate the test app is running, make a request to the app after the cf push command succeeds:

    curl test-app.APPS-DOMAIN
    

    Where APPS-DOMAIN is your TAS for Kubernetes installation apps domain.

    Note: The route for the test application defaults to a subdomain of the system domain.

To validate Velero installation:

  1. Use kubectl to confirm the back up and restore components have been installed successfully:

    kubectl get pods -n cf-system -l app=cf-metadata
    

Check the Version of TAS for Kubernetes on a Cluster

To check the version of TAS for Kubernetes currently installed on a cluster, use kubectl:

kubectl get ConfigMap version -n tas-system -o jsonpath="{.data}"

This command produces output in the following format:

map[commit:__GIT_COMMIT__ version:__BUILD_NUMBER__]

For example:

map[commit:53ad0edd093dbad71debc193541b5c6f0b2b094d version:0.4.0-build.57]

Next Steps

After you complete this procedure, proceed to Configuring Back Up and Restore for Tanzu Application Service for Kubernetes.