How to update your license

Uploading a new license to the platform.

General steps

  1. Obtain a license from the supplier (CE — via Telegram bot or form; Enterprise — under the contract).
  2. Update the license in the platform according to the circuit type.
  3. Make sure the license is applied (check the status on the About the system page).

In a closed circuit, while the license is still valid, it is enough to update the ShturvalServicePatch (SSP) for shturval-backend. shturval-backend must run in Auto (auto) control mode: when the configuration changes, service updates are applied automatically. In Manual (manual) mode the license update will not be applied.

In an open circuit and/or if the license has expired, follow the steps on the Open circuit or an expired license tab. If the license has expired, the GUI may become unavailable after you apply the SSP, so complete the remaining changes in the console.

While the license is still valid, the instruction on this tab is enough to update it. If the license has already expired, follow the instruction on the Open circuit or an expired license tab.

  1. Connect to the management cluster.
  2. Go to Services and Repositories → Installed Services.
  3. Find Platform control module (shturval-backend).
  4. Open Manage → the Service tab or Applied ShturvalServicePatch.
  5. Create a ShturvalServicePatch (SSP) for shturval-backend and set the new license in customvalues. Or use Import Manifests to load the SSP with the license.
apiVersion: ops.shturval.tech/v1beta2
kind: ShturvalServicePatch
metadata:
  name: shturval-backend-license
spec:
  shturvalServiceConfigName: shturval-backend
  customvalues:
    license_token: <your parameter value>
ParameterDescriptionData typeExample
license_tokenNew license JSON Web Token (JWT) received from the Shturval platform teamstringeyJhbm5lciI
  1. Wait until the service status is Patched.
  2. Restart the shturval-backend pods. From the shturval-backend namespace dashboard, open the workload named shturval-backend and the Pods tab. Delete the pods named shturval-backend.
  3. Wait until the pods restart.
  4. Check the license on the About the system page (the start page of the web interface). If the node sends the license to the registry, also check that the new authorization is applied on the node: on the node page, the Node Configuration tab does not show Not applied, and the Authorization line in /etc/containerd/certs.d/<registry-name>/hosts.toml matches the license field in the NCI. The output contains the token. In the cluster, READY for this node’s NodeConfig must be True:
kubectl get nodeconfig <node-name>

If the license has expired and/or the platform is in an open circuit:

  1. Apply an SSP to shturval-backend.
  2. Allow a license change in ClusterConfig.
  3. Replace the license in ClusterConfig.
  4. Restore the ClusterConfig check.
  5. Replace the license in ClusterProfile.
  6. For clusters with the Shturval v2 provider, replace the license in ShturvalProvider.
  7. Replace the license token in NodeConfigItem.
  8. Replace the license token in /etc/std/nci.json on the nodes and the NodeConfig annotation.

If the license has expired in a closed circuit, complete steps 1–5: the SSP, ClusterConfig, and ClusterProfile. After you apply the SSP and restart the pods, the GUI may be unavailable — use the CLI.

Step 1. Apply the shturval-backend SSP

  1. Connect to the management cluster in the console.
  2. Save the manifest and apply the SSP:
kubectl apply -f shturval-backend-license.yaml
apiVersion: ops.shturval.tech/v1beta2
kind: ShturvalServicePatch
metadata:
  name: shturval-backend-license
spec:
  shturvalServiceConfigName: shturval-backend
  customvalues:
    license_token: <your parameter value>
ParameterDescriptionData typeExample
license_tokenNew license JSON Web Token (JWT) received from the Shturval platform teamstringeyJhbm5lciI
  1. Confirm the object exists: kubectl get shturvalservicepatch shturval-backend-license.
  2. Restart the shturval-backend pods in the shturval-backend namespace and wait until they are ready:
kubectl -n shturval-backend rollout restart deployment shturval-backend
kubectl -n shturval-backend rollout status deployment shturval-backend

Step 2. Allow a license change in ClusterConfig

Two webhooks of this resource forbid a license change in ClusterConfig on the management cluster. To allow the change:

  1. Save the YAML of the objects you will change: the ClusterConfig webhooks, deployment shturval-cluster-manager-cluster-manager, ClusterConfig, ClusterProfile, ShturvalProvider (if the cluster uses the Shturval v2 provider), and NodeConfigItem and NodeConfig (for a closed circuit).
kubectl get mutatingwebhookconfiguration,validatingwebhookconfiguration -o yaml > backup-webhooks.yaml
kubectl -n shturval-cluster-manager get deployment shturval-cluster-manager-cluster-manager -o yaml > backup-cluster-manager.yaml
kubectl get clusterconfig -A -o yaml > backup-clusterconfig.yaml
kubectl get clusterprofile -n kube-system -o yaml > backup-clusterprofile.yaml
kubectl get shturvalprovider -o yaml > backup-provider.yaml
kubectl get nodeconfigitem -o yaml > backup-nci.yaml
kubectl get nodeconfig -o yaml > backup-nodeconfig.yaml

Skip ShturvalProvider if the platform has no Shturval v2 provider. Get NodeConfigItem and NodeConfig of a client cluster with the same get commands and that cluster’s kubeconfig.

  1. Allow the change and stop cluster-manager. Remember that both webhooks were failurePolicy: Fail, and remember the previous replica count. Do not change the profile webhook in the same object.
  1. Open Administration → Custom Resources → API group admissionregistration.k8s.io → MutatingWebhookConfiguration.
  2. Open shturval-cluster-manager-mutating-webhook-configuration.
  3. In the manifest, find name: defaulting-webhook-clusterconfig-v1beta1.cluster.shturval.tech. The failurePolicy line of this webhook is above the name. Change Fail to Ignore.
  4. Click Check, then Save.
  5. Return to Custom Resources, open ValidatingWebhookConfiguration, and go to shturval-cluster-manager-validating-webhook-configuration. For the webhook vclusterconfig-v1beta1.kb.io, change failurePolicy to Ignore.
  6. Click Check, then Save.
  7. Open Namespaces → shturval-cluster-manager → Workloads → Deployments → shturval-cluster-manager-cluster-manager.
  8. On the Deployment tab, note the replica count, set it to 0, and save.
  9. On the Pods tab, wait until the pods are deleted.
  1. Find the webhooks. The object name is the line without indentation. Its webhooks are listed under that line. If the name you need is the first line under the object, use index 0. If it is the second line, use 1. Do not change the profile line next to it.
kubectl get mutatingwebhookconfiguration -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{range .webhooks[*]}{"  "}{.name}{"\t"}{.failurePolicy}{"\n"}{end}{end}'
kubectl get validatingwebhookconfiguration -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{range .webhooks[*]}{"  "}{.name}{"\t"}{.failurePolicy}{"\n"}{end}{end}'

In the first command, find defaulting-webhook-clusterconfig-v1beta1.cluster.shturval.tech. In the second, find vclusterconfig-v1beta1.kb.io.

  1. Set failurePolicy: Ignore on these two webhooks only. Substitute the object name and the index:
kubectl patch mutatingwebhookconfiguration <name> --type json -p '[{"op":"test","path":"/webhooks/<index>/name","value":"defaulting-webhook-clusterconfig-v1beta1.cluster.shturval.tech"},{"op":"replace","path":"/webhooks/<index>/failurePolicy","value":"Ignore"}]'
kubectl patch validatingwebhookconfiguration <name> --type json -p '[{"op":"test","path":"/webhooks/<index>/name","value":"vclusterconfig-v1beta1.kb.io"},{"op":"replace","path":"/webhooks/<index>/failurePolicy","value":"Ignore"}]'
  1. Note the current replica count and stop the deployment:
kubectl -n shturval-cluster-manager get deployment shturval-cluster-manager-cluster-manager -o jsonpath='{.spec.replicas}{"\n"}'
kubectl -n shturval-cluster-manager scale deployment/shturval-cluster-manager-cluster-manager --replicas=0
  1. Wait until the pods of this deployment are deleted:
kubectl -n shturval-cluster-manager get pods

Step 3. Update the license in ClusterConfig

ClusterConfig objects of all clusters are available in the management cluster. The object name and its namespace match the cluster name. The license is the spec.license field. See Platform custom resources.

Replace spec.license in the ClusterConfig of the management cluster and of each client cluster. If the license has expired, the GUI is unavailable — use the CLI.

  1. Connect to the management cluster.
  2. Open Administration → Custom Resources → API group cluster.shturval.tech → ClusterConfig.
  3. In the manifest of each ClusterConfig, replace spec.license with the new token.
apiVersion: cluster.shturval.tech/v1beta1
kind: ClusterConfig
metadata:
  name: clustername
  namespace: clustername
spec:
  license: <new token>
  1. Connect to the management cluster.
  2. Open the list: kubectl get clusterconfig -A.
  3. Substitute the cluster name for clustername and repeat the command for each cluster:
kubectl patch clusterconfig clustername -n clustername --type merge -p '{"spec":{"license":"<new token>"}}'

Step 4. Restore the ClusterConfig check

Return the deployment and the webhooks to their previous state.

  1. Open Namespaces → shturval-cluster-manager → Workloads → Deployments → shturval-cluster-manager-cluster-manager.
  2. On the Deployment tab, restore the previous replica count and save. Wait until the pods are Ready.
  3. Open Administration → Custom Resources → API group admissionregistration.k8s.io → MutatingWebhookConfiguration.
  4. Find and open shturval-cluster-manager-mutating-webhook-configuration.
  5. In the manifest, find name: defaulting-webhook-clusterconfig-v1beta1.cluster.shturval.tech. The failurePolicy line of this webhook is above the name. Change Ignore to Fail.
  6. Click Check, then Save.
  7. Open ValidatingWebhookConfiguration → shturval-cluster-manager-validating-webhook-configuration. For the webhook vclusterconfig-v1beta1.kb.io, change failurePolicy to Fail.
  8. Click Check, then Save.
  1. Restore the previous replica count and wait until the deployment is ready:
kubectl -n shturval-cluster-manager scale deployment/shturval-cluster-manager-cluster-manager --replicas=<previous count>
kubectl -n shturval-cluster-manager rollout status deployment/shturval-cluster-manager-cluster-manager --timeout=180s
  1. Set failurePolicy: Fail on the webhook defaulting-webhook-clusterconfig-v1beta1.cluster.shturval.tech in shturval-cluster-manager-mutating-webhook-configuration and on the webhook vclusterconfig-v1beta1.kb.io in shturval-cluster-manager-validating-webhook-configuration. Substitute the object name and the index:
kubectl patch mutatingwebhookconfiguration <name> --type json -p '[{"op":"test","path":"/webhooks/<index>/name","value":"defaulting-webhook-clusterconfig-v1beta1.cluster.shturval.tech"},{"op":"replace","path":"/webhooks/<index>/failurePolicy","value":"Fail"}]'
kubectl patch validatingwebhookconfiguration <name> --type json -p '[{"op":"test","path":"/webhooks/<index>/name","value":"vclusterconfig-v1beta1.kb.io"},{"op":"replace","path":"/webhooks/<index>/failurePolicy","value":"Fail"}]'

Step 5. Update the license in ClusterProfile

Cluster profiles (ClusterProfile) are available in the kube-system namespace of the management cluster. The license is the spec.license field. A change of spec.license in ClusterConfig does not update profiles automatically. See What cluster profiles (ClusterProfile) are.

Changing a profile does not apply the changes to client clusters that are already created.

In the GUI, changing default-client-cluster-profile is blocked. Update this profile in the CLI. Do not change the other profile fields. If the license has expired, the GUI is unavailable.

  1. Open Platform → Cluster Profiles → Client Cluster Configuration Profiles → on the profile page, the Manifest tab.
  2. In each custom profile where spec.license is set, replace the token.
apiVersion: cluster.shturval.tech/v1beta1
kind: ClusterProfile
metadata:
  name: <profile-name>
  namespace: kube-system
spec:
  license: <new token>
  1. Open the profile list: kubectl get clusterprofile -n kube-system.
  2. Substitute the profile name for <profile-name> and repeat the command for each profile where spec.license is set, including default-client-cluster-profile:
kubectl patch clusterprofile <profile-name> -n kube-system --type merge -p '{"spec":{"license":"<new token>"}}'

Step 6. Update the license in ShturvalProvider

This step is only for the Shturval v2 provider. A new host downloads the shturvald package from the r.shturval.tech registry: login user, password spec.licenseToken. This password is not written to /etc/std/nci.json on the node. See Creating a ShturvalProvider.

Replace the license in every ShturvalProvider in the management cluster.

  1. Connect to the management cluster.
  2. Open Administration → Custom Resources → API group infrastructure.cluster.x-k8s.io → ShturvalProvider.
  3. In each object whose spec.licenseToken differs from the new token, replace only this field.
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: ShturvalProvider
metadata:
  name: <provider-name>
spec:
  licenseToken: <new token>
  1. Connect to the management cluster.
  2. Open the list: kubectl get shturvalprovider.
  3. Substitute the provider name and repeat the command for each object whose token differs:
kubectl patch shturvalprovider <provider-name> --type merge -p '{"spec":{"licenseToken":"<new token>"}}'

Step 7. Update the token in NodeConfigItem

In an open circuit the license is in NodeConfigItem (NCI) generic-init-config, in the Container Runtime section: registry r.shturval.tech, field Repository authorization (spec.runtimecfg.registries[].license).

Write Basic, a space, and the command output into the field. The whole string user:<license> is encoded: the registry login is user, and the password is the license.

echo -n 'user:<license>' | base64 -w 0

Update the NCI in the management cluster and in each client cluster of the platform. The client cluster kubeconfig is stored in the management cluster, in Secret <cluster-name>-kubeconfig in namespace <cluster-name>. See Access to child clusters.

  1. Open the cluster → Administration → Node Configuration.
  2. Open NCI generic-init-config.
  3. In Container Runtime, for registry r.shturval.tech, replace the license in Repository authorization. Click Save.
  1. Open NCI generic-init-config.
kubectl get nodeconfigitem generic-init-config -o yaml
  1. In spec.runtimecfg.registries, for registry r.shturval.tech, replace license with the new Basic value and apply the object.

Step 8. Update the file on nodes that are already running

In an open circuit, check the node’s authorization to the registry and update the license in /etc/std/nci.json if it differs from the new one. Do this for every node in all clusters. Connect to the cluster node and check the node’s authorization to the registry:

sudo grep -c Authorization /etc/containerd/certs.d/<registry-name>/hosts.toml

In an open circuit, <registry-name> is r.shturval.tech. If the command prints 0, the node does not send a license to the registry, and you do not need to change /etc/std/nci.json. shturvald takes the license from the NCI and writes it to hosts.toml. A number greater than zero means the token is stored in the file. Then replace it in /etc/std/nci.json, as follows:

  1. Before you replace the token, copy /etc/std/nci.json.
  2. Open /etc/std/nci.json. Find the old token and replace it with the new one. It is stored in the password line, in an address https://user:<token>@, and in a value "license": "Basic ...".
  3. Write the file and set mode 0600.
  4. On the node, calculate the sha256 of the file and write the sum. The node.shturval.tech/initchecksum annotation is on the NodeConfig with the node’s name. The NodeConfig name matches the node name. Paste the sum from the sha256sum output, the characters before the space.

On each cycle shturvald calculates the sha256 of /etc/std/nci.json and compares it with this annotation. After you edit the file, the sum changes, so write the new sum. Otherwise configuration application stops (ConfigApplied=False, reason ChecksumMismatch). See Configuration application cycle in the shturval-node-config service.

On the node:

sudo sha256sum /etc/std/nci.json

In the cluster:

kubectl annotate nodeconfig <node-name> node.shturval.tech/initchecksum=<sum> --overwrite

Check the license on the About the system page (the start page of the web interface). If the node sends the license to the registry, also check that the new authorization is applied on the node: on the node page, the Node Configuration tab does not show Not applied, and the Authorization line in /etc/containerd/certs.d/<registry-name>/hosts.toml matches the license field in the NCI. The output contains the token. In the cluster, READY for this node’s NodeConfig must be True:

kubectl get nodeconfig <node-name>

Also confirm that both ClusterConfig webhooks are failurePolicy: Fail again and that the replica count of deployment shturval-cluster-manager-cluster-manager is back to its previous value.

Recommendations

  • Renew the license before it expires.
  • Keep a copy of the license in a safe place.
  • Before the license expires, the platform shows notifications. If the license has expired, obtain a new license and complete steps 1–5 from the console, as on the Open circuit or an expired license tab.
  • On a cluster with the Shturval v2 provider, in an open circuit and when the license has expired, also complete step 6. A new host downloads shturvald with the token from ShturvalProvider.
  • In a closed circuit, steps 7 and 8 are not required even if the license has expired: update the SSP, ClusterConfig, and ClusterProfile. In an open circuit, complete steps 7 and 8 only if hosts.toml of the registry on the node contains Authorization. If it does not, do not fill in authorization. Change the token in /etc/std/nci.json only if it is already stored in that file.