<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>TKG on Build. Run. Repeat.</title><link>https://buildrunrepeat.com/categories/tkg/</link><description>Recent content in TKG on Build. Run. Repeat.</description><generator>Hugo</generator><language>en</language><lastBuildDate>Wed, 01 May 2024 09:00:00 -0400</lastBuildDate><atom:link href="https://buildrunrepeat.com/categories/tkg/index.xml" rel="self" type="application/rss+xml"/><item><title>Fixing Missing TKRs in Existing TKGS Deployments</title><link>https://buildrunrepeat.com/posts/fixing-missing-tkrs-in-existing-tkgs-deployment/</link><pubDate>Wed, 01 May 2024 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/fixing-missing-tkrs-in-existing-tkgs-deployment/</guid><description>&lt;p&gt;I regularly check the &lt;a href="https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-releases/services/rn/vmware-tanzu-kubernetes-releases-release-notes/index.html"&gt;Tanzu Kubernetes Releases (TKR) release notes page&lt;/a&gt; for new updates.
Yesterday, a new TKR was released with support for Kubernetes 1.28.8, and while attempting to test this new version in my TKGS environment, I realized that the TKR was not present in my environment and I started wondering why, as normally, when new TKRs are released, they immediately become available for deployment, since the vCenter is subscribed to the VMware public content library where all the TKRs are hosted. This time, that was not the case, so I started investigating.&lt;/p&gt;</description></item><item><title>CAPV: Addressing Node Provisioning Issues Due to an Invalid State of ETCD</title><link>https://buildrunrepeat.com/posts/capv-addressing-node-provisioning-issues-due-to-invalid-state-of-etcd/</link><pubDate>Fri, 01 Dec 2023 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/capv-addressing-node-provisioning-issues-due-to-invalid-state-of-etcd/</guid><description>&lt;p&gt;I recently ran into a strange scenario on a Kubernetes cluster after a sudden and unexpected crash it had experienced due to an issue in the underlying vSphere environment. In this case, the cluster was a TKG cluster (in fact, it happened to be the TKG management cluster), however, the same situation could have occurred on any cluster managed by Cluster API Provider vSphere (CAPV).&lt;/p&gt;
&lt;p&gt;I have seen clusters unexpectedly crash many times before and most of the time, they successfully went back online when all nodes were up and running. In this case, however, some of the nodes could not boot properly, and Cluster API started attempting their reconciliation.&lt;/p&gt;</description></item><item><title>CAPV: Fixing and Cleaning Up Idle vCenter Server Sessions</title><link>https://buildrunrepeat.com/posts/capv-fixing-and-cleaning-up-idle-vcenter-sessions/</link><pubDate>Wed, 01 Nov 2023 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/capv-fixing-and-cleaning-up-idle-vcenter-sessions/</guid><description>&lt;p&gt;I recently ran into an issue causing the vCenter server to crash almost daily. What seemed to be a random vCenter issue initially, turned out to be related to CAPV (Cluster API Provider vSphere), running on some of our Kubernetes clusters. That was also an edge case I had not seen before, so I decided to document and share it here.&lt;/p&gt;
&lt;p&gt;Initially, the issue we were witnessing on the vCenter server was the following:&lt;/p&gt;</description></item><item><title>TKG 2.3: Fixing the Prometheus Data Source in the Grafana Package</title><link>https://buildrunrepeat.com/posts/tkg-2-3-fixing-the-prometheus-data-source-in-the-grafana-package/</link><pubDate>Fri, 01 Sep 2023 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/tkg-2-3-fixing-the-prometheus-data-source-in-the-grafana-package/</guid><description>&lt;p&gt;With the release of TKG 2.3, the Grafana package was finally updated from version 7.5.x to 9.5.1.
If you have deployed the new Grafana package (&lt;code&gt;9.5.1+vmware.2-tkg.1&lt;/code&gt;) or upgraded your existing one to this version, you may have run into error messages in your Grafana dashboards.&lt;/p&gt;
&lt;p&gt;For example, in the &lt;code&gt;TKG Kubernetes cluster monitoring&lt;/code&gt; default dashboard, you may have run into the &lt;code&gt;Failed to call resource&lt;/code&gt; error when opening the dashboard and noticed that a lot of the data is missing.&lt;/p&gt;</description></item><item><title>TKG: Updating Pinniped Configuration and Addressing Common Issues</title><link>https://buildrunrepeat.com/posts/tkg-updating-pinniped-config-and-addressing-common-issues/</link><pubDate>Thu, 01 Jun 2023 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/tkg-updating-pinniped-config-and-addressing-common-issues/</guid><description>&lt;p&gt;Most of the TKG engagements I&amp;rsquo;ve been involved in included Pinniped for Kubernetes authentication.
On many occasions, I have seen issues where the configuration provided to Pinniped was incorrect or partially incorrect. For example, common issues may be related to the LDAPS integration. Many environments I have seen utilize Active Directory as the authentication source, and Pinniped requires the LDAPS certificate, username, and password, which are often specified incorrectly. Since this configuration is not validated during the deployment, you end up with an invalid state of Pinniped on your management cluster.&lt;/p&gt;</description></item><item><title>Streamlining and Customizing Windows Image Builder for TKG</title><link>https://buildrunrepeat.com/posts/streamlining-and-customizing-windows-image-builder-in-tkg/</link><pubDate>Wed, 01 Mar 2023 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/streamlining-and-customizing-windows-image-builder-in-tkg/</guid><description>&lt;p&gt;Tanzu Kubernetes Grid (TKG) is one of the few platforms providing out-of-the-box support and streamlined deployment of Windows Kubernetes clusters. VMware is actively investing in this area and constantly improving the support and capabilities around Windows on Kubernetes.&lt;/p&gt;
&lt;p&gt;Unlike Linux-based clusters, for which VMware provides pre-packaged base OS images (typically based on Ubuntu and Photon OS), VMware cannot offer Windows pre-packaged images, primarily due to licensing restrictions, I suppose. Therefore, building your own Windows base OS image is one of the prerequisites for deploying a TKG Windows workload cluster.
Fortunately, VMware leverages the &lt;a href="https://github.com/kubernetes-sigs/image-builder"&gt;upstream Image Builder project&lt;/a&gt; - a fantastic collection of cross-provider Kubernetes virtual machine image-building utilities intended to simplify and streamline the creation of base OS images for Kubernetes.&lt;/p&gt;</description></item><item><title>Tanzu Kubernetes Grid GPU Integration</title><link>https://buildrunrepeat.com/posts/tkg-gpu-integration/</link><pubDate>Wed, 01 Mar 2023 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/tkg-gpu-integration/</guid><description>&lt;p&gt;I recently had to demonstrate Tanzu Kubernetes Grid and its GPU integration capabilities.
Developing a good use case and assembling the demo required some preliminary research.&lt;/p&gt;
&lt;p&gt;During my research, I reached out to Jay Vyas, staff engineer at VMware, SIG Windows lead for Kubernetes, a Kubernetes legend, and an awesome guy in general. :) For those who don&amp;rsquo;t know Jay, he is also one of the authors of the fantastic book &lt;code&gt;Core Kubernetes&lt;/code&gt; (look it up!).&lt;/p&gt;</description></item><item><title>Getting Started with Carvel ytt - Real-World Examples</title><link>https://buildrunrepeat.com/posts/getting-started-with-carvel-ytt-real-world-examples/</link><pubDate>Sun, 01 Jan 2023 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/getting-started-with-carvel-ytt-real-world-examples/</guid><description>&lt;p&gt;Over the years of working with Tanzu Kubernetes Grid (TKG), one tool has stood out as a game-changer for resource customization: Carvel’s ytt. Whether tailoring cluster manifests, customizing TKG packages, or addressing unique deployment requirements, ytt has consistently been a fundamental part of the workflow. Its flexibility, power, and declarative approach make it an essential tool for anyone working deeply with Kubernetes in a TKG ecosystem.&lt;/p&gt;
&lt;p&gt;But what exactly is ytt? Short for &lt;code&gt;YAML Templating Tool&lt;/code&gt;, ytt is part of the Carvel suite of tools designed for Kubernetes resource management. It provides a powerful, programmable approach to templating YAML configurations by combining straightforward data values, overlays, and scripting capabilities. Unlike many traditional templating tools, ytt prioritizes structure and intent, making it easier to maintain, validate, and debug configurations—particularly in complex, large-scale Kubernetes environments.&lt;/p&gt;</description></item><item><title>Replacing your vCenter server certificate? TKG needs to know about it…</title><link>https://buildrunrepeat.com/posts/replacing-your-vcenter-server-certificate-tkg-needs-to-know-about-it/</link><pubDate>Sun, 01 Jan 2023 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/replacing-your-vcenter-server-certificate-tkg-needs-to-know-about-it/</guid><description>&lt;p&gt;I recently ran into an issue where TKGm had suddenly failed to connect to the vCenter server.&lt;/p&gt;
&lt;p&gt;The issue turned out to be TLS-related, and I noticed that the vCenter server certificate had been replaced&amp;hellip;&lt;/p&gt;
&lt;p&gt;Due to the certificate issue, Cluster API components failed to communicate with vSphere, causing cluster reconciliation to fail, among other vSphere-related operations.&lt;/p&gt;
&lt;p&gt;Since all TKG clusters in the environment were deployed with the &lt;code&gt;VSPHERE_TLS_THUMBPRINT&lt;/code&gt; parameter specified, replacing the vCenter certificate breaks the connection to vSphere, as the TLS thumbprint changes as well.&lt;/p&gt;</description></item><item><title>Upgrading NSX ALB in a TKG Environment</title><link>https://buildrunrepeat.com/posts/upgrading-nsx-alb-in-a-tkg-environment/</link><pubDate>Thu, 01 Sep 2022 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/upgrading-nsx-alb-in-a-tkg-environment/</guid><description>&lt;p&gt;For quite a long time, the highest version of the NSX ALB TKG supported was &lt;code&gt;20.1.6/20.1.3&lt;/code&gt;, although &lt;code&gt;21.1.x&lt;/code&gt; has been available for a while, and I have been wondering when TKG would support it.
In the release notes of TKG &lt;code&gt;1.5.4&lt;/code&gt;, I recently noticed a note that has been added regarding NSX ALB &lt;code&gt;21.1.x&lt;/code&gt; under the &lt;code&gt;Configuration variables&lt;/code&gt; section:&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;code&gt;AVI_CONTROLLER_VERSION&lt;/code&gt; sets the NSX Advanced Load Balancer (ALB) version for NSX ALB v21.1.x deployments in Tanzu Kubernetes Grid.&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Customizing Elasticsearch indices using Fluent-Bit in TKG</title><link>https://buildrunrepeat.com/posts/customizing-elasticsearch-indices-using-fluent-bit-in-tkg/</link><pubDate>Mon, 01 Aug 2022 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/customizing-elasticsearch-indices-using-fluent-bit-in-tkg/</guid><description>&lt;p&gt;Fluent-Bit is currently the preferred option for log shipping in TKG and is provided out of the box as a Tanzu package that can be easily deployed on each TKG/Kubernetes cluster.&lt;/p&gt;
&lt;p&gt;A recent implementation required shipping all Kubernetes logs to Elasticsearch, complying with a specific naming convention for the Elasticsearch indices.&lt;/p&gt;
&lt;p&gt;Applying such customizations requires you to utilize the &lt;a href="https://docs.fluentbit.io/manual/pipeline/filters/lua"&gt;Lua filter&lt;/a&gt;. Using the Lua filter, you can modify incoming records by invoking custom scripts to apply your logic when processing the records.&lt;/p&gt;</description></item><item><title>Getting Harbor to trust your LDAPS certificate in TKG</title><link>https://buildrunrepeat.com/posts/getting-harbor-to-trust-your-ldaps-certificate-in-tkg/</link><pubDate>Mon, 01 Aug 2022 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/getting-harbor-to-trust-your-ldaps-certificate-in-tkg/</guid><description>&lt;p&gt;In a recent TKG implementation, it was required to configure Harbor with LDAPS rather than LDAP.&lt;/p&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;Failed to verify LDAP server with error: error: ldap server network timeout.
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;
&lt;a href="https://buildrunrepeat.com/posts/getting-harbor-to-trust-your-ldaps-certificate-in-tkg/images/001.png" data-dimbox data-dimbox-caption="Screenshot"&gt;
 &lt;img alt="Screenshot" src="https://buildrunrepeat.com/posts/getting-harbor-to-trust-your-ldaps-certificate-in-tkg/images/001.png"/&gt;
&lt;/a&gt;
&lt;/p&gt;
&lt;p&gt;Although the error message doesn&amp;rsquo;t explicitly say there&amp;rsquo;s a certificate issue and there is nothing in the &lt;code&gt;harbor-core&lt;/code&gt; container logs, it immediately made sense to me that the &lt;code&gt;harbor-core&lt;/code&gt; container didn&amp;rsquo;t trust my LDAPS/CA certificate, so I started investigating how the certificate could be injected somehow into Harbor. The Harbor package doesn&amp;rsquo;t have any input for the LDAPS/CA certificate in its data values file, so I knew I had to create &lt;a href="https://github.com/itaytalmi/vmware-tkg/blob/main/ytt-overlays/tkg-packages/harbor/ldaps-overlay/overlay-harbor-ldaps-cert.yaml"&gt;my own YTT overlay&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>Getting kapp-controller to trust your CA certificates in TKG</title><link>https://buildrunrepeat.com/posts/getting-kapp-controller-to-trust-your-ca-certificates-in-tkg/</link><pubDate>Mon, 01 Aug 2022 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/getting-kapp-controller-to-trust-your-ca-certificates-in-tkg/</guid><description>&lt;p&gt;Have you ever had to deploy a package using kapp-controller from your Harbor private registry?&lt;/p&gt;
&lt;p&gt;I recently deployed the Tanzu RabbitMQ package to a TKGm workload cluster in an air-gapped/internet-restricted environment.&lt;/p&gt;
&lt;p&gt;Doing so in air-gapped environments requires you to push the packages into Harbor, then have kapp-controller deploy the package from Harbor.&lt;/p&gt;
&lt;p&gt;After adding the PackageRepository referencing my Harbor registry, I observed it couldn&amp;rsquo;t complete reconciling due to a certificate issue.&lt;/p&gt;</description></item><item><title>Is your TKG cluster name too long, or is it your DHCP Server…?</title><link>https://buildrunrepeat.com/posts/is-your-tkg-cluster-name-too-long-or-is-it-your-dhcp-server/</link><pubDate>Mon, 01 Aug 2022 09:00:00 -0400</pubDate><guid>https://buildrunrepeat.com/posts/is-your-tkg-cluster-name-too-long-or-is-it-your-dhcp-server/</guid><description>&lt;p&gt;Recently, when working on a TKGm implementation project, I initially ran into an issue that seemed very odd, as I hadn&amp;rsquo;t encountered such behavior in any other implementation before.&lt;/p&gt;
&lt;p&gt;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&amp;rsquo;t proceed.&lt;/p&gt;</description></item></channel></rss>