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).

Installation

• If you are using your own database server, set the connection parameters in ModuleConfig/commander.

• The PostgreSQL database can also be deployed to the cluster with postgres-operator, which can be installed to the cluster by enabling the operator-postgres module. In this case you need to enable it first and ensure that the CRDs from this module appear in the cluster. Then you can enable the Deckhouse Commander module.

Below, we will describe these options in more detail.

If you are using your PostgreSQL DB installation

Important: PostgreSQL extensions plpgsql and pgcrypto are required for Deckhouse Commander to work properly.

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’re using the operator-postgres module

Step 1: Enabling operator-postgres (optional)

You can use your own postgres-operator installation version v1.10.0 or later.

First, enable the postgres operator module and wait for it to become active:

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

Then, wait until the Deckhouse task queue becomes empty to make sure the module is enabled:

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

After that ensure that necessary CRDs are installed:

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

Step 2: Enable Deckhouse Commander

Next, enable the Deckhouse Commander module.

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: commander
spec:
  enabled: true
  version: 1
  settings:
    nodeSelector:
      node.deckhouse.io/group: commander
    postgres:
      mode: Internal

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.