Справочник компонентов Cozystack

Переопределение параметров компонентов

Иногда требуется изменить отдельные параметры компонентов. Для этого измените соответствующий ресурс Package и задайте значения в секции spec.components. Структура значений соответствует файлу values.yaml соответствующего системного chart’а в репозитории Cozystack.

Например, чтобы включить режим FRR-K8s для MetalLB, посмотрите его values.yaml, чтобы понять доступные параметры, а затем измените Package cozystack.metallb:

apiVersion: cozystack.io/v1alpha1
kind: Package
metadata:
  name: cozystack.metallb
  namespace: cozy-system
spec:
  variant: default
  components:
    metallb:
      values:
        metallb:
          frrk8s:
            enabled: true

Включение и отключение компонентов

В bundle есть необязательные компоненты, которые нужно явно включать в установку. Обычные компоненты bundle, наоборот, можно отключить, если они не нужны.

Use bundles.enabledPackages and bundles.disabledPackages in the Platform Package values. Every entry in those lists is a fully-qualified name under the cozystack. prefix (for example, cozystack.metallb, cozystack.hetzner-robotlb, cozystack.nfs-driver). Run kubectl get packagesource to see the exact names available on your cluster before editing the Platform Package. kubectl get package answers only for disabledPackages, because an optional component has no Package object until its name is already in enabledPackages.

Например, при установке Cozystack в Hetzner нужно заменить стандартный балансировщик нагрузки MetalLB на RobotLB, созданный специально для Hetzner:

apiVersion: cozystack.io/v1alpha1
kind: Package
metadata:
  name: cozystack.cozystack-platform
spec:
  variant: isp-full
  components:
    platform:
      values:
        bundles:
          disabledPackages:
            - cozystack.metallb
          enabledPackages:
            - cozystack.hetzner-robotlb
        # rest of the config

Disabling components must be done before installing Cozystack. Applying updated configuration with disabledPackages will not remove components that are already installed. Removing one that is already installed takes two steps. Add its name to disabledPackages in the Platform Package above, then wait for the operator to carry that edit across. The name appears in this output once it has:

kubectl get helmrelease cozystack-platform --namespace cozy-system \
  --output jsonpath='{.spec.values.bundles.disabledPackages}'

Then delete the Package object.

The namespace a component installs into is the exception: the operator applies that one itself, outside the component’s release and with no ownerReference, so the uninstall never had it to remove.

List the releases the Package owns before deleting it. The operator labels every HelmRelease it renders with the name of the Package that produced it, and one Package can own several:

kubectl get helmrelease --all-namespaces --selector cozystack.io/package=<package-name> \
  --output custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,SUSPENDED:.spec.suspend'

Clear spec.suspend on any release that shows true before going on. Flux skips the uninstall for a suspended HelmRelease and only drops its own finalizer, so that release disappears with everything it installed left behind and nothing left managing it.

kubectl delete package.cozystack.io <package-name>

Nothing holds a finalizer on the Package, so this command returns as soon as the object is gone and the uninstall it triggers runs afterwards. Wait on each release from the listing to know the destructive part has finished:

kubectl wait --for=delete helmrelease/<name> --namespace <namespace> --timeout=10m

kubectl wait --for=delete exits 0 for a name that was never there, silently and with nothing to tell it apart from a deletion it watched, so take both values from the listing rather than guessing them. A returned wait says the HelmRelease is gone, not that the uninstall ran.

Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.

kubectl delete hr is not a lighter-weight version of this. Flux uninstalls the release when an unsuspended HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.