Replacing your vCenter server certificate? TKG needs to know about it…

I recently ran into an issue where TKGm had suddenly failed to connect to the vCenter server.

The issue turned out to be TLS-related, and I noticed that the vCenter server certificate had been replaced…

Due to the certificate issue, Cluster API components failed to communicate with vSphere, causing cluster reconciliation to fail, among other vSphere-related operations.

Since all TKG clusters in the environment were deployed with the VSPHERE_TLS_THUMBPRINT parameter specified, replacing the vCenter certificate breaks the connection to vSphere, as the TLS thumbprint changes as well.

Upgrading NSX ALB in a TKG Environment

For quite a long time, the highest version of the NSX ALB TKG supported was 20.1.6/20.1.3, although 21.1.x has been available for a while, and I have been wondering when TKG would support it. In the release notes of TKG 1.5.4, I recently noticed a note that has been added regarding NSX ALB 21.1.x under the Configuration variables section:

AVI_CONTROLLER_VERSION sets the NSX Advanced Load Balancer (ALB) version for NSX ALB v21.1.x deployments in Tanzu Kubernetes Grid.

Getting Harbor to trust your LDAPS certificate in TKG

In a recent TKG implementation, it was required to configure Harbor with LDAPS rather than LDAP.

I deployed the Harbor package on the TKG shared services cluster and configured LDAP. However, when testing the connection, I received an error message that was not informative at all:

Failed to verify LDAP server with error: error: ldap server network timeout.

Although the error message doesn’t explicitly say there’s a certificate issue and there is nothing in the harbor-core container logs, it immediately made sense to me that the harbor-core container didn’t trust my LDAPS/CA certificate, so I started investigating how the certificate could be injected somehow into Harbor. The Harbor package doesn’t have any input for the LDAPS/CA certificate in its data values file, so I knew I had to create my own YTT overlay.

Getting kapp-controller to trust your CA certificates in TKG

Have you ever had to deploy a package using kapp-controller from your Harbor private registry?

I recently deployed the Tanzu RabbitMQ package to a TKGm workload cluster in an air-gapped/internet-restricted environment.

Doing so in air-gapped environments requires you to push the packages into Harbor, then have kapp-controller deploy the package from Harbor.

After adding the PackageRepository referencing my Harbor registry, I observed it couldn’t complete reconciling due to a certificate issue.

Is your TKG cluster name too long, or is it your DHCP Server…?

Recently, when working on a TKGm implementation project, I initially ran into an issue that seemed very odd, as I hadn’t encountered such behavior in any other implementation before.

The issue was that a workload cluster deployment hung after deploying the first control plane node. Until then, everything seemed just fine; as the cluster deployment had successfully initialized, NSX ALB had successfully allocated a control plane VIP. After that, however, the deployment had completely hung and seemed like it wouldn’t proceed.

Kubernetes Data Protection: Getting Started with Kasten (K10)

In a recent Kubernetes project I was involved in, our team had to conduct an in-depth proof of concept for several Kubernetes data protection solutions. The main highlights of the PoC covered data protection for stateful applications and databases, disaster recovery, and application mobility, including relocating applications across Kubernetes clusters and even different types of Kubernetes clusters (for example, from TKG on-premise to AWS EKS, etc.).

One of the solutions we evaluated was Kasten (K10), a data management platform for Kubernetes, which is now a part of Veeam. The implementation of Kasten was one of the smoothest we have ever experienced in terms of ease of use, stability, and general clarity around getting things done, as everything is very well documented, which certainly cannot be taken for granted these days. :)

Production-Grade Multi-Cluster TAP Installation Guide

• Introduction
• Prerequisites
• Prepare your Workstation
• Relocate TAP Images to your Private Registry
• Install TAP
  • View Cluster
    • Set up the Installation Namespace
    • Issue a TLS Certificate for TAP GUI
    • Set up a Database for TAP GUI
    • Set up the TAP GUI Catalog Git Repository
    • Set up RBAC for the Metadata Store
    • Set up an Authentication Provider for TAP GUI
    • Set up RBAC for the Build, Run and Iterate Clusters
    • Set an Ingress Domain, TAP GUI Hostname and CA Certificate
    • Deploy the TAP Package
  • Build Cluster
    • Set up the Installation Namespace
    • Set up Metadata Store Authentication and CA Certificate
    • Prepare a Sample Source Code Git Repository
    • Update the TAP Values File
    • Deploy the TAP Package
    • Deploy the TBS Full Dependencies Package
    • Set up the Developer Namespace and Deploy a Workload
  • Run Cluster
    • Set up the Installation Namespace
    • Update the TAP Values File
    • Deploy the TAP Package
    • Set up the Developer Namespace and Deploy a Workload
  • Iterate Cluster
    • Set up the Installation Namespace
    • Update the TAP Values File
    • Deploy the TAP Package
    • Deploy the TBS Full Dependencies Package
    • Set up the Developer Namespace and Deploy a Workload
    • Iterate on your Application
• Wrap Up

Introduction

Since my previous posts on TAP Overview and Backstage, I have been diving deeper into TAP, trying to establish the practices around it.