Installation

System requirements

To start using Deckhouse Commander, you need a cluster based on Deckhouse Kubernetes Platform. If you don’t have a cluster yet, refer to the installation instructions.

We recommend creating a fault-tolerant management cluster that will include the following node sets (NodeGroup):

• PostgreSQL in HighAvailability mode in two replicas requires 1 core and 1 GB of memory on 2 separate nodes.
• The API server in HighAvailability mode for two replicas needs 1 core and 1GB of memory on two separate nodes.
• Service components used for rendering configurations and connecting to application clusters require 0.5 cores and 128 MB of memory per cluster.
• Cluster manager and dhctl server together require resources based on the number of clusters they serve and the number of DKP versions they serve simultaneously.
• Up to 2 cores per node can be occupied by DKP service components (for example: runtime-audit-engine, istio, cilium, log-shipper).

Prepare DBMS

Deckhouse Commander works with the PostgreSQL database management system. PostgreSQL extensions plpgsql and pgcrypto are required for Deckhouse Commander to function properly.

Option 1: External DBMS

This is the recommended way to use Deckhouse Commander in production environments. To use Deckhouse Commander, you need to prepare the connection parameters to the database.

Option 2: operator-postgres module

This is not a recommended method for use in production environments. However, the use of operator-postgres is convenient for quick start with Deckhouse Commander or for environments where there are no high availability and support requirements.

It is important to enable the Deckhouse Commander module after CRDs from the operator-postgres module have appeared in the cluster.

The operator-postgres module uses the PostgreSQL operator. You can use your own postgres-operator installation version v1.10.0 or later.

Step 1: Enabling operator-postgres

First, you need to enable the postgres operator module and wait for it to be enabled.

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: operator-postgres
spec:
  enabled: true

Step 2: Complete the installation

To make sure that the module is enabled, wait for the Deckhouse task queue to become empty:

kubectl -n d8-system exec svc/deckhouse-leader -c deckhouse -- deckhouse-controller queue main

Check for the necessary CRDs in the cluster:

kubectl get crd | grep postgresqls.acid.zalan.do

Enabling Deckhouse Commander

If you are using your own PostgreSQL database installation

To enable Deckhouse Commander, create a ModuleConfig:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: commander
spec:
  enabled: true
  version: 1
  settings:
    postgres:
      mode: External
      external:
        host: "..."     # Mandatory field
        port: "..."     # Mandatory field
        user: "..."     # Mandatory field
        password: "..." # Mandatory field
        db: "..."       # Mandatory field

If you are using the operator-postgres module

It is enough to enable the commander module in the Internal database connection mode. Deckhouse Commander will independently configure the database in the PostgreSQL operator.

Please note that the default storage class (StorageClass) will be used for the database. For Deckhouse Commander the storage class can be set explicitly:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: commander
spec:
  enabled: true
  version: 1
  settings:
    postgres:
      mode: Internal
      internal:
        storageClass: my-storage-class  # optional setting

Setting up access control (optional)

Starting with version 1.11, experimental access control support has been added to Deckhouse Commander. Access control is disabled by default, so all users have the same maximum permissions as in previous versions. No additional actions are required to use Deckhouse Commander in this mode.

If access control is enabled, all users and groups who previously used Deckhouse Commander will automatically become administrators. This makes it possible to maintain compatibility in permissions, but they can be limited.

To activate access control, specify the value permissionsEnabled: true in the featureFlags field in ModuleConfig.

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: commander
spec:
  enabled: true
  version: 1
  settings:
    featureFlags:
      permissionsEnabled: true

If you then turn off access control (permissionsEnabled: false), then all users who enter the Deckhouse Commander interface will get maximum permissions again.

Thus, in version 1.11, you can enable and disable access control without losing the default behavior (without restrictions on permissions). However, in future versions, access control support will become permanent and will not be disabled.

In case of emergency, it is possible to assign temporary administrators. This may be required in the following situations:

• Deckhouse Commander was launched with access control before anyone entered its interface, as a result, there is not a single user or group with any permissions in the system.
• During the process of configuring access control, the administrator’s permissions were lost and must be restored.

Assign temporary administrators to configure access control (optional)

Create a commander-admins ConfigMap in the d8-commander namespace, specifying the users and groups that require temporary administrative access:

apiVersion: v1
kind: ConfigMap
metadata:
  name: commander-admins
  namespace: d8-commander
data:
  users: |
    john.doe@example.com
    jane.doe@example.com
  groups: |
    Enterprise Admins
    Administrators

Users and group members will receive maximum permissions in the Deckhouse Commander interface.

Attention! After completing the configuration of the required roles and role bindings, the ConfigMap commander-admins must be deleted. After deletion, temporary access will be revoked, and only manually issued permissions will take effect.