Tanzu 2.x introduced the ClusterClass

One of the significant changes/updates from Tanzu 1.x to 2.x is the introduction of ClusterClass. This might be a new concept for some, so I delved into it a bit. Since my cluster is currently at 1.6x, I need to transition my plan-based cluster to a ClusterClass-based cluster.

If you’re familiar with programming languages, you might understand what a class is. In simple terms, you can think of it as creating your own class, but in this context, it’s a cluster definition that you can use as a template to deploy clusters of the same type.

Getting started with ClusterClass may seem a bit tricky at first, but once you’ve created one, you have the flexibility to modify it and create new ones as needed.

You can find a How to Create a Custom ClusterClass from here.

Learn by Example

I wasn’t entirely sure how to handle the overlay, especially since it was my first time using ytt. To clarify, I’d like to provide an example below.

I’m utilizing a self-CA for accessing the on-premise registry, which means I had to incorporate the self-CA into the worker node.

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}), expects="1+"
#@overlay/match-child-defaults missing_ok=True
---
spec:
  template:
    spec:
      #@overlay/match missing_ok=True
      files:
        #@overlay/append
        - content: #@ data.read("customCA.crt")
          owner: root:root
          permissions: "0644"
          path: /etc/ssl/certs/customCA.crt
        - content: #@ data.read("customRootCA.pem")
          owner: root:root
          permissions: "0644"
          path: /etc/ssl/certs/customRootCA.crt
      #@overlay/match missing_ok=True
      preKubeadmCommands:
        #! For Ubuntu
        #@overlay/append
        - "! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/customCA.crt /usr/local/share/ca-certificates/customCA.crt && update-ca-certificates)"
        - "! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/customRootCA.crt /usr/local/share/ca-certificates/customRootCA.crt && update-ca-certificates)"

On line #4, you can see it is altering the template “KubeadmConfigTemplate”

It adds two CAs, customCA.crt and customRootCA.crt also.

the command under the preKubeadmCommands is executed when worker nodes are up.

You need to use a different template for Master nodes, and their depth is also different. let’s see below.

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlaneTemplate"}), expects="1+"
#@overlay/match-child-defaults missing_ok=True
---
spec:
  template:
    spec:
      kubeadmConfigSpec:
        #@overlay/match missing_ok=True
        files:
        #@overlay/append
        - content: #@ data.read("customCA.crt")
          owner: root:root
          permissions: "0644"
          path: /etc/ssl/certs/customCA.crt
        - content: #@ data.read("customRootCA.pem")
          owner: root:root
          permissions: "0644"
          path: /etc/ssl/certs/customRootCA.crt
      #@overlay/match missing_ok=True
        preKubeadmCommands:
        #! For Ubuntu
        #@overlay/append
        - "! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/customCA.crt /usr/local/share/ca-certificates/customCA.crt && update-ca-certificates)"
        - "! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/customRootCA.crt /usr/local/share/ca-certificates/customRootCA.crt && update-ca-certificates)"

You’ll notice that it utilizes the KubeadmControlPlaneTemplate for master nodes. If you wish to include additional commands, simply add them as a list under the ‘preKubeadmCommands’ section.

Keep in mind that this command is executed after the machine has booted up. So, if you wish to modify sysctl parameters, you’ll need to apply them while the system is running and save them into sysctl.conf for the changes to persist across reboots.