When a cluster which has been provisioned by TMC, and therefore managed by TMC, has an available upgrade, you will see an “i” icon next to the version on the clusters UI view, hovering over this will tell you there is an upgrade ready.
Click the cluster name to take you into the cluster object to see the full details,
click the actions button
and select upgrade.
The Upgrade Cluster dialogue will appear. Select the version you want to upgrade to and click upgrade.
On both the Cluster list and Cluster Detailed view, the status will change to upgrading.
Once the upgrade has completed, the cluster will change back to ready and show the updated version.
Wrap-up and Resources
In this quick blog post, we used Tanzu Mission Control to upgrade a provisioned Tanzu Kubernetes Grid cluster which was running in AWS. All the steps provided in this blog post can be replicated using the TMC CLI as well.
As a reminder, to take real advantage of TMC I recommend you read the follow posts:
This blog post will cover a technical walk-through on using Tanzu Mission Control to deploy Tanzu Kubernetes clusters to AWS.
The follow up blog posts in this series are:
Tanzu Mission Control
- Getting Started with TMC
- - What is Tanzu Mission Control?
- - Creating a Cluster Group
- - Attaching a cluster to Tanzu Mission Control
- - Viewing your Cluster Objects
- - Where can I demo/test/trial this myself?
- Cluster Inspections
- - What Inspections are available
- - Performing Inspections
- - Viewing Inspections
- Workspaces and Policies
- - Creating a workspace
- - Creating a managed Namespace
- - Policy Driven Cluster Management
- - Creating Policies
- Using the Data Protection feature for backups and restores
- - Data Protection Overview
- - Create a AWS Data Protection Credential
- - Enable Data Protection on a Cluster
- - Running a backup manually or via an automatic schedule
- - Restoring your data
Using the AWS Hosted Management Cluster
In this example, we will use the default provided AWS Hosted Management cluster.
Alternatively, you can use the Tanzu CLI to provision a TKG Management cluster into AWS and attach this to Tanzu Mission Control.
Currently it is not supported to have a Management Cluster manage clusters across platforms.
I.e. Management Cluster in AWS that manages workload clusters in Azure.
To get started:
Go to Administration
Click the Management Clusters Tab
Click on the “aws-hosted” cluster object name
Create a provisioner
The default tab when selecting the “aws-hosted” management cluster object is the provisioner tab.
Click create provisioner
Provide a name for the provisioner
You will be taken back to your provisioner object which is created. Using the radio button to select the object will allow you to delete it. No other action is available.
I was trying to download a software release from GitHub using Curl and hitting an issue, the file wasn’t large enough for a start, it was unusable and clearly not the file I expected.
curl -O https://github.com/kastenhq/external-tools/releases/download/3.0.12/k10tools_3.0.12_linux_amd64
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 635 100 635 0 0 2387 0 --:--:-- --:--:-- --:--:-- 2387
I tested this in a browser and found the link redirects elsewhere, hence the issue.
Just needed to specify a few extra arguments.
curl -LJO https://github.com/kastenhq/external-tools/releases/download/3.0.12/k10tools_3.0.12_linux_amd64
# Explanation of the arguments
-L, --location Follow redirects
-J, --remote-header-name Use the header-provided filename
-O, --remote-name Write output to a file named as the remote file
If you wish to use wget instead.
wget --content-disposition https://github.com/kastenhq/external-tools/releases/download/3.0.12/k10tools_3.0.12_linux_amd64
# Explanation of the argument
--content-disposition honor the Content-Disposition header when choosing local file names (EXPERIMENTAL)
I was helping a customer build some customized automation tasks using vRealize Automation Codestream. These tasks required the use of a container image with certain tools installed, usually we can include a CI task to download the tools into the container image on the fly. However, my customer’s environment is offline, so I needed to provide them a container image with everything installed by default.
Before we dive into the process of running a container and committing the changes, it is recommended where possible to create a new docker file that would build your docker image as needed with the associated commands such as the below:
RUN apk add --no-cache python g++ make
COPY . .
RUN yarn install --production
CMD ["node", "src/index.js"]
Committing changes to a container image in this way can cause the image to become bloated. But sometimes there’s a need to do just do it this way.