What are cluster profiles (ClusterProfile)

Purpose of a profile in the platform #

ClusterProfile is a custom resource of the API group cluster.shturval.tech (see Custom platform resources). Profile management is performed in the management cluster. The default profile is default-client-cluster-profile.

Custom profiles are useful for different environments and mass use of a standard configuration.

In the Shturval platform, using a custom cluster profile (ClusterProfile), you can override the configuration settings of client clusters:

• parameters of the image repository, logging, monitoring, time zone and NTP;
• PV cleanup policy when deleting a cluster with CSI integration enabled (spec.deletePersistentVolumes);
• configurations Cluster API, Kubelet and Kubeadm;
• add YAML object manifests, which will be created in the client cluster or in the management cluster when the client cluster is initialized.

If the default profile configuration has been changed, return it to the original values in accordance with the data from the ClusterConfig management cluster.

apiVersion: cluster.shturval.tech/v1beta1
kind: ClusterProfile
metadata:
  name: default-client-cluster-profile
  namespace: kube-system
  labels:
    shturval.tech/shturval-cluster-profile-config: ""
spec:
  license: '<license from ClusterConfig>'
  loggingEndpoint: '<loggingUrl from ClusterConfig status>'
  monitoringEndpoint: '<monitoringUrl from ClusterConfig status>'
  repositoryConfig: 
    commonUrl: '<systemRegistryConfig.commonUrl from ClusterConfig>'
  time_zone: Europe/Moscow
  ntpServers: []
  clusterAPIConfiguration:
    machineDeployment:
      nodeDeletionTimeout: 10m0s
      nodeDrainTimeout: 10m0s
      nodeVolumeDetachTimeout: 5m0s
  kubeadmControlPlaneConfiguration:
    MachineTemplate:
      nodeDeletionTimeout: 10m0s
      nodeDrainTimeout: 10m0s
      nodeVolumeDetachTimeout: 5m0s
    clusterConfiguration:
      apiServer:
        extraArgs:
          authorization-mode: Node,RBAC
          default-not-ready-toleration-seconds: '30'
          default-unavailable-toleration-seconds: '30'
          profiling: 'false'
      certificatesDir: /etc/kubernetes/pki
      controllerManager:
        extraArgs:
          bind-address: 0.0.0.0node-monitor-grace-period: 20s
          node-monitor-period: 2s
          profiling: 'false'
      etcd:
        local:
          dataDir: /var/lib/etcd
      imageRepository: <systemRegistryConfig.commonUrl from ClusterConfig Cluster Management>
      networking:
        dnsDomain: cluster.local
        podSubnet: 172.16.0.0/16
        serviceSubnet: 10.96.0.0/12
      scheduler:
        extraArgs:
          bind-address: 0.0.0.0
          profiling: 'false'
    initConfiguration:
      nodeRegistration:
        criSocket: unix:///run/containerd/containerd.sock
        imagePullPolicy: IfNotPresent
      skipPhases:
        - addon/kube-proxy
    joinConfiguration:
      nodeRegistration:
        criSocket: unix:///run/containerd/containerd.sock
        imagePullPolicy: IfNotPresent
  kubeletConfiguration:
    cgroupDriver: systemd
    enableProfilingdeployers.Handler: false
    imageGCHighThresholdPercent: 70
    imageGCLowThresholdPercent: 65
    imageMinimumGCAge: 15m0s
    nodeStatusUpdateFrequency: 4s
    readOnlyPort: 0
    rotateCertificates: true
    tlsMinVersion: VersionTLS13

Creating profiles is described on the page: How to create and apply cluster profiles (ClusterProfile).

How a cluster profile works #

ClusterProfile is a client cluster configuration template. The profile is selected during client cluster creation and applied during cluster initialization.

If some of the parameters in the custom profile are not filled in, they are automatically filled in with values from the default profile default-client-cluster-profile.

Profiles are created in the namespace kube-system of the management cluster. Updating the ClusterProfile configuration does not change the configuration of previously created client clusters with this profile.

Secrets with YAML manifests #

Through the profile, you can add YAML manifests of objects that must be created when deploying a client cluster. For example:

• settings of installed services using ShturvalServicePatch;
• Cilium network policies and Kyverno security policies;
• configuration of cluster nodes using NCI;
• MachineHealthCheck.

These objects are stored in Secrets of the namespace kube-system of the management cluster.

Secret with manifests must be requiredspruce label cluster.shturval.tech/manifest. Secrets without this label will be ignored in profiles. Additionally, it is recommended to add a unique label, by which only Secrets needed for a specific profile are selected.

In the customManifests block, the selector specifies where manifests from Secret should be used:

• clientManifestsSelector — in the client cluster;
• platformManifestsSelector — in the namespace of the client cluster in the management cluster. Manifests of resources managed by the management cluster are created only in the namespace of the client cluster. The namespace specified in the manifest is ignored in this case.

For manifests that are used in the management cluster via platformManifestsSelector, the rights shturval-cluster-manager are important. If a resource from an allowed API group is added to the profile, but cluster-manager does not have rights to create or read it, the Secret check will fail. For example, additional rights are needed to arbitrarily create users.auth.shturval.tech or pods.

All manifests from Secrets included in the selection will be applied at the initialization stage after installing the client cluster services.

The manifest application phase cannot be overridden: deployPhase: postsscdeploy is set by default.

If you need to use the name of the client cluster being created in the manifest, use the {{.ClusterName}} placeholder. When applying the manifest, the platform will replace it with the actual name of the cluster.

apiVersion: cluster.x-k8s.io/v1beta2
kind: MachineHealthCheck
metadata:
  name: "{{.ClusterName}}-default-healthcheck"
  namespace: "{{.ClusterName}}"
spec:
  checks:
    nodeStartupTimeoutSeconds: 0
    unhealthyNodeConditions:
      - status: Unknown
        timeoutSeconds: 600
        type: Ready
      - status: 'False'
        timeoutSeconds: 600
        type: Ready
  clusterName: "{{.ClusterName}}"
  remediation:
    triggerIf:
      unhealthyLessThanOrEqualTo: 39%
  selector:
    matchLabels:
      cluster.x-k8s.io/deployment-name: "{{.ClusterName}}-default"

apiVersion: cluster.shturval.tech/v1beta1
kind: ClusterProfile
metadata:
  creationTimestamp: 2026-01-22T07:55:09Z
  generation: 1
  labels:
    k8slens-edit-resource-version: v1beta1
    shturval.tech/shturval-cluster-profile-config: ""
  name: cluster-profile
  namespace: kube-system
  resourceVersion: "29842860"
  uid: 44a09930-9728-418b-a8c6-51e791a2aa64
spec:
  customManifests:
    - clientManifestsSelector:
        matchExpressions:
          - key: cluster.shturval.tech/manifest
            operator: Exists
        matchLabels:
          clientcluster: clientcluster
      platformManifestsSelector:
        matchExpressions:
          - key: cluster.shturval.tech/manifest
            operator: Exists
        matchLabels: {}
# Here will be the configuration parameters of the default cluster profile
status:
  extraManifestsStatus:
    manifestsStatus:
      - clientManifestsStatus:
          - secretRef:
              name: secretname
              namespace: kube-system
            status: valid
        deployPhase: postsscdeploy
        platformManifestsStatus:
          - secretRef:
              name: secretname
              namespace: kube-system
            status: valid
    ready:
      status: "True"

Peculiarities of working profiles with manifests #

1. The results of validation of manifests of objects included in Secret are displayed in the status ClusterProfile.
2. Any changes to Secrets that match the selector in the cluster profile, including updating and creating new Secrets, result in an automatic update in the profile.
3. It is possible to add resources to the profile for use in the management cluster only from allowed API groups.

4. Checking platform manifests takes into account not only the API group, but also the rights of the cluster-manager to act with resource. If you do not have rights in the profile status, a Secret check error will appear, and the profile cannot be selected when creating a client cluster. How to expand rights, see section If you do not have enough rights to platform manifests.
5. Profile creation does not apply manifests immediately. Manifests from a profile are only applied when creating a client cluster in which this profile is selected.

Profile status #

The profile status indicates whether the profile can be used when creating a client cluster, and is related only to the verification of manifests.