How to Customize Kubelet Log Rotation Parameters (containerLogMaxSize / containerLogMaxFiles) in vSphere Kubernetes Service (VKS) Workload Clusters

Products

• VMware vSphere Kubernetes Service
• VMware Cloud Foundation

Issue/Introduction

Workloads running inside Tanzu Kubernetes Grid (TKG) guest clusters generate high volumes of container log output. Administrators need to modify the default Kubelet log rotation thresholds to prevent local node disk pressure or to extend log retention periods before standard log rotation occurs.

By default, the platform sets the following Kubelet configurations:

• containerLogMaxSize: 10Mi
• containerLogMaxFiles: 5

Environment

VMware Cloud Foundation (VCF)

vSphere Kubernetes Service (VKS)

Cause

The mechanism available to modify these parameters is strictly bound to the underlying ClusterClass API schema layer deployed within your vSphere environment.

In older lifecycle branches (prior to version builtin-generic-v3.5.0), Kubelet arguments are hardcoded to the platform system defaults and are not exposed as declarative variables in the runtime API topology. Customization in these versions requires localized, node-level configuration injection.

Modern lifecycle branches (builtin-generic-v3.5.0 and later) expose native osConfiguration variable hooks, allowing administrators to manage log thresholds declaratively across the cluster topology manifest.

Resolution

Select the configuration option below that matches the active ClusterClass version running in your environment.

Option 1: For Clusters Running builtin-generic-v3.5.0 and Later (Declarative / Recommended)

Starting with version builtin-generic-v3.5.0 (introduced alongside modernized vSphere Kubernetes Service frameworks), you can manage these arguments directly within your cluster deployment manifest without interacting with individual cluster nodes.

1. Open your workload cluster deployment .yaml configuration manifest.
2. Verify that the topology.class is defined as builtin-generic-v3.5.0 or later.
3. Inject or update the custom kubelet arguments block within the topology.variables array as demonstrated below:

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: your-workload-cluster
  namespace: your-vsphere-namespace
spec:
  topology:
    class: builtin-generic-v3.5.0  # Must be v3.5.0 or later
    version: v1.32.9+vmware.2-fips-vsc0.1.15
    variables:
      - name: osConfiguration
        value:
          kubelet:
            arguments:
              containerLogMaxSize: 50Mi  # Configurable up to 50Mi
              containerLogMaxFiles: 10   # Configurable up to 10

4. Apply the updated manifest to your cluster control plane context:

kubectl apply -f cluster.yaml

The cluster controller plane will automatically initiate a safe, rolling lifecycle update across your node pools to apply the adjustments.

Option 2: For Clusters Running Prior to builtin-generic-v3.5.0 (Manual Remediation)

For legacy clusters that cannot immediately be rebased to a newer topology version, the parameters are not exposed through API variables. The arguments must be applied directly to the configuration layout on each virtual machine node.

⚠️ Important: Manual runtime configuration overrides executed directly on a node are transient. They do not persist through cluster scaling, node deletion, or automated upgrade actions. Use this method as an interim workaround until you can migrate to a supported ClusterClass level.

Execute these steps on every Control Plane and Worker node within the target cluster:

1. Establish a secure SSH session to the target node VM using your authorized cluster access tokens.
2. Open the primary Kubelet configuration file using an administrative text editor:

         sudo vi /var/lib/kubelet/config.yaml

3. Locate the configuration properties block and append or modify the desired values (substitute ## with your target sizing thresholds):

          containerLogMaxSize: 50Mi

      containerLogMaxFiles: 10

4. Save your changes and exit the text editor.
5. Restart the local runtime Kubelet daemon process to reload the configuration definitions:

        sudo systemctl restart kubelet

6. Verify the operational status of the service to confirm it restarted successfully: 

         sudo systemctl status kubelet

Additional Information

For comprehensive syntax matrices and complete lists of adjustable runtime variables across modernized cluster templates, please refer to our official developer reference documentation:

🔗 Broadcom Documentation — ClusterClass Variables for Customizing a Cluster