Как обновить лицензию

Если срок действия лицензии истек и/или платформа в открытом контуре:

1. Примените SSP к shturval-backend.
2. Снимите запрет на изменение лицензии в ClusterConfig.
3. Замените лицензию в ClusterConfig.
4. Верните проверку ClusterConfig.
5. Замените лицензию в ClusterProfile.
6. Для кластеров с провайдером Shturval v2 замените лицензию в ShturvalProvider.
7. Замените лицензионный токен в NodeConfigItem.
8. Замените лицензионный токен в /etc/std/nci.json на узлах и аннотацию NodeConfig.

Если в закрытом контуре срок действия лицензии истек, выполните шаги 1–5: SSP, ClusterConfig и ClusterProfile. При этом графический интерфейс после применения SSP и перезапуска подов может быть недоступен — используйте CLI.

Шаг 1. Применить SSP shturval-backend #

1. Подключитесь к кластеру управления в консоли.
2. Сохраните манифест и примените 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: <ваше значение параметра>

3. Проверьте, что объект создан: kubectl get shturvalservicepatch shturval-backend-license.
4. Перезапустите поды shturval-backend в неймспейсе shturval-backend и дождитесь, пока они станут готовы:

kubectl -n shturval-backend rollout restart deployment shturval-backend
kubectl -n shturval-backend rollout status deployment shturval-backend

Шаг 2. Снять запрет на смену лицензии в ClusterConfig #

Изменение лицензии в ClusterConfig в кластере управления запрещают два webhook этого ресурса. Чтобы снять запрет, выполните:

1. Сохраните YAML объектов, которые будете менять: webhook ClusterConfig, deployment shturval-cluster-manager-cluster-manager, ClusterConfig, ClusterProfile, ShturvalProvider (если кластер с провайдером Shturval v2), NodeConfigItem и NodeConfig (для закрытого контура).

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

Пропустите ShturvalProvider, если в платформе нет провайдера Shturval v2. NodeConfigItem и NodeConfig клиентского кластера получите теми же командами get с kubeconfig этого кластера.

2. Снимите запрет и остановите cluster-manager. Запомните, что у обоих webhook было failurePolicy: Fail, и прежнее количество реплик. Webhook профиля в том же объекте не меняйте.

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}'

kubectl patch mutatingwebhookconfiguration <имя> --type json -p '[{"op":"test","path":"/webhooks/<индекс>/name","value":"defaulting-webhook-clusterconfig-v1beta1.cluster.shturval.tech"},{"op":"replace","path":"/webhooks/<индекс>/failurePolicy","value":"Ignore"}]'
kubectl patch validatingwebhookconfiguration <имя> --type json -p '[{"op":"test","path":"/webhooks/<индекс>/name","value":"vclusterconfig-v1beta1.kb.io"},{"op":"replace","path":"/webhooks/<индекс>/failurePolicy","value":"Ignore"}]'

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

kubectl -n shturval-cluster-manager get pods

Шаг 3. Обновить лицензию в ClusterConfig #

ClusterConfigs всех кластеров доступны в кластере управления. Имя объекта и его неймспейс совпадают с именем кластера. Лицензия — поле spec.license. Подробнее в Кастомные ресурсы платформы.

Замените spec.license в ClusterConfig кластера управления и каждого клиентского кластера. Если лицензия истекла, графический интерфейс недоступен — используйте CLI.

apiVersion: cluster.shturval.tech/v1beta1
kind: ClusterConfig
metadata:
  name: clustername
  namespace: clustername
spec:
  license: <новый токен>

kubectl patch clusterconfig clustername -n clustername --type merge -p '{"spec":{"license":"<новый токен>"}}'

Шаг 4. Вернуть проверку ClusterConfig #

Верните deployment и webhook в прежнее состояние.

kubectl -n shturval-cluster-manager scale deployment/shturval-cluster-manager-cluster-manager --replicas=<прежнее число>
kubectl -n shturval-cluster-manager rollout status deployment/shturval-cluster-manager-cluster-manager --timeout=180s

kubectl patch mutatingwebhookconfiguration <имя> --type json -p '[{"op":"test","path":"/webhooks/<индекс>/name","value":"defaulting-webhook-clusterconfig-v1beta1.cluster.shturval.tech"},{"op":"replace","path":"/webhooks/<индекс>/failurePolicy","value":"Fail"}]'
kubectl patch validatingwebhookconfiguration <имя> --type json -p '[{"op":"test","path":"/webhooks/<индекс>/name","value":"vclusterconfig-v1beta1.kb.io"},{"op":"replace","path":"/webhooks/<индекс>/failurePolicy","value":"Fail"}]'

Шаг 5. Обновить лицензию в ClusterProfile #

Профили кластера (ClusterProfile) доступны в неймспейсе kube-system кластера управления. Лицензия — поле spec.license. Изменение spec.license в ClusterConfig не обновляет профили автоматически. См. Что такое профили кластеров (ClusterProfile).

Изменение профиля не применяет изменения в созданных клиентских кластерах.

В графическом интерфейсе изменение default-client-cluster-profile заблокировано. Этот профиль обновите в CLI. Остальные поля профиля не меняйте. Если лицензия истекла, графический интерфейс недоступен.

apiVersion: cluster.shturval.tech/v1beta1
kind: ClusterProfile
metadata:
  name: <имя-профиля>
  namespace: kube-system
spec:
  license: <новый токен>

kubectl patch clusterprofile <имя-профиля> -n kube-system --type merge -p '{"spec":{"license":"<новый токен>"}}'

Шаг 6. Обновить лицензию в ShturvalProvider #

Шаг только для провайдера Shturval v2. Новый хост скачивает пакет shturvald с реестра r.shturval.tech: логин user, пароль — spec.licenseToken. В файл /etc/std/nci.json на узле этот пароль не записывается. См. Создание ShturvalProvider.

Замените лицензию во всех ShturvalProvider в кластере управления.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: ShturvalProvider
metadata:
  name: <имя-провайдера>
spec:
  licenseToken: <новый токен>

kubectl patch shturvalprovider <имя-провайдера> --type merge -p '{"spec":{"licenseToken":"<новый токен>"}}'

Шаг 7. Обновить токен в NodeConfigItem #

В открытом контуре лицензия лежит в NodeConfigItem (NCI) generic-init-config, в разделе Container Runtime: реестр r.shturval.tech, поле Авторизация для репозитория (spec.runtimecfg.registries[].license).

В поле запишите Basic и через пробел результат команды. Кодируется строка user:<лицензия> целиком: логин реестра user, пароль — лицензия.

echo -n 'user:<лицензия>' | base64 -w 0

Изменения потребуется внести в NCI в кластере управления и в каждом клиентском кластере платформы. Kubeconfig клиентского кластера хранится в кластере управления Secret <имя-кластера>-kubeconfig неймспейса <имя-кластера>. См. Доступ к дочерним кластерам.

kubectl get nodeconfigitem generic-init-config -o yaml

Шаг 8. Обновить файл на уже работающих узлах #

В открытом контуре проверьте авторизацию узла в реестр и обновите лицензию в /etc/std/nci.json, если она отличается от новой. Выполните обновление для каждого узла во всех кластерах. Подключитесь к узлу кластера и проверьте авторизацию узла в реестр:

sudo grep -c Authorization /etc/containerd/certs.d/<имя-реестра>/hosts.toml

В открытом контуре <имя-реестра> - r.shturval.tech. Если команда вывела 0, узел не передаёт лицензию в реестр, внесение изменений в файл /etc/std/nci.json не требуются. shturvald берёт его из NCI и записывает в hosts.toml. Число больше нуля значит, что токен записан в файл. Тогда замените его в /etc/std/nci.json, как приведено далее:

1. Перед заменой скопируйте /etc/std/nci.json.
2. Откройте /etc/std/nci.json. Найдите старый токен и замените его на новый. Он записан в строке password, в адресе https://user:<токен>@ и в значении "license": "Basic ...".
3. Запишите файл и выставьте права 0600.
4. На узле посчитайте sha256 файла и запишите сумму. Аннотация node.shturval.tech/initchecksum стоит на NodeConfig с именем узла. Имя NodeConfig совпадает с именем узла. В команду подставьте саму сумму из вывода sha256sum, символы до пробела.

shturvald на каждом цикле считает sha256 файла /etc/std/nci.json и сверяет его с этой аннотацией. После правки файла сумма меняется, поэтому и необходимо записать новую сумму, иначе применение конфигурации останавливается (ConfigApplied=False, причина ChecksumMismatch). Подробнее — в разделе Цикл применения конфигурации сервиса shturval-node-config.

Выполните на узле:

sudo sha256sum /etc/std/nci.json

Выполните в кластере:

kubectl annotate nodeconfig <имя-узла> node.shturval.tech/initchecksum=<сумма> --overwrite

Проверьте лицензию на странице «О системе» (стартовая страница веб-интерфейса). Если узел передаёт лицензию в реестр, проверьте, что на нём применилась новая авторизация: на странице узла во вкладке Конфигурация узла нет статуса Не применено, а строка Authorization в /etc/containerd/certs.d/<имя-реестра>/hosts.toml совпадает с полем license в NCI. В выводе есть токен. В кластере у NodeConfig этого узла в колонке READY должно быть True:

kubectl get nodeconfig <имя-узла>

Дополнительно проверьте, что у обоих webhook ClusterConfig снова failurePolicy: Fail, а количество реплик deployment shturval-cluster-manager-cluster-manager прежнее.