Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 2. Prepare the installation

Ensure your OpenShift cluster meets the requirements for OpenShift Dev Spaces and install the tools you need for installation.

Review the supported platforms, install the dsc management tool, understand the OpenShift Dev Spaces architecture, and estimate resource requirements for your deployment.

2.1. Supported platforms
Copy link

OpenShift Dev Spaces is supported on specific OpenShift versions and CPU architectures.

OpenShift Dev Spaces runs on OpenShift 4.16–4.22 on the following CPU architectures:

  • AMD64 and Intel 64 (x86_64)
  • IBM Z (s390x)
  • IBM Power (ppc64le)
  • ARMv8 (arm64)

2.2. Install the dsc management tool
Copy link

Install dsc, the Red Hat OpenShift Dev Spaces command-line management tool, on Linux, macOS, or Windows to start, stop, update, and delete the OpenShift Dev Spaces server.

Prerequisites

Procedure

  1. Download the archive from https://developers.redhat.com/products/openshift-dev-spaces/download to a directory such as $HOME.
  2. Run tar xvzf on the archive to extract the /dsc directory.
  3. Add the extracted /dsc/bin subdirectory to $PATH.

Verification

  • Run dsc to view information about it. 

    $ dsc

2.3. OpenShift Dev Spaces architecture overview
Copy link

Figure 2.1. High-level OpenShift Dev Spaces architecture with the Dev Workspace operator

High-level architecture diagram showing OpenShift Dev Spaces components interacting with the Dev Workspace operator

The OpenShift Dev Spaces architecture consists of server components, user workspaces, and the Dev Workspace Operator, which together provide cloud-based development environments on OpenShift.

OpenShift Dev Spaces runs on three groups of components:

OpenShift Dev Spaces server components
Manage User project and workspaces. The main component is the User dashboard, from which users control their workspaces.
Dev Workspace operator
Creates and controls the necessary OpenShift objects to run User workspaces. Including Pods, Services, and PersistentVolumes.
User workspaces
Container-based development environments, the Integrated Development Environment (IDE) included.

The role of these OpenShift features is central:

Dev Workspace Custom Resources
Valid OpenShift objects representing the User workspaces and manipulated by OpenShift Dev Spaces. It is the communication channel for the three groups of components.
OpenShift role-based access control (RBAC)
Controls access to all resources.

2.3.1. Server components
Copy link

The OpenShift Dev Spaces server components manage multi-tenancy and workspace lifecycle. Understanding these components helps you troubleshoot issues and plan cluster capacity.

Figure 2.2. OpenShift Dev Spaces server components interacting with the Dev Workspace operator

Diagram showing OpenShift Dev Spaces server component deployments interacting with the Dev Workspace operator

2.3.2. OpenShift Dev Spaces operator
Copy link

The OpenShift Dev Spaces operator ensures full lifecycle management of the OpenShift Dev Spaces server components.

CheCluster custom resource definition (CRD)
Defines the CheCluster OpenShift object.
OpenShift Dev Spaces controller
Creates and controls the necessary OpenShift objects to run an OpenShift Dev Spaces instance, such as pods, services, and persistent volumes.
CheCluster custom resource (CR)
On a cluster with the OpenShift Dev Spaces operator, it is possible to create a CheCluster custom resource (CR). The OpenShift Dev Spaces operator ensures the full lifecycle management of the OpenShift Dev Spaces server components on this OpenShift Dev Spaces instance. These components include the Dev Workspace Operator, gateway, user dashboard, OpenShift Dev Spaces server, and plug-in registry.

2.3.3. Dev Workspace operator
Copy link

The Dev Workspace Operator (DWO) is a dependency of OpenShift Dev Spaces, and is an integral part of how OpenShift Dev Spaces functions. One of DWO’s main responsibilities is to reconcile Dev Workspace custom resources (CR).

The Dev Workspace CR is an OpenShift resource representation of an OpenShift Dev Spaces workspace. Whenever a user creates a workspace using OpenShift Dev Spaces in the background, Dashboard OpenShift Dev Spaces creates a Dev Workspace CR in the cluster. For every OpenShift Dev Spaces workspace, there is an underlying Dev Workspace CR on the cluster.

Figure 2.3. Example of a Dev Workspace CR in a cluster

DevWorkspace CR example

When creating a workspace with OpenShift Dev Spaces with a devfile, the Dev Workspace CR contains the devfile details. Additionally, OpenShift Dev Spaces adds the editor definition into the Dev Workspace CR depending on which editor was chosen for the workspace. OpenShift Dev Spaces also adds attributes to the Dev Workspace that further configure the workspace depending on how you configured the CheCluster CR.

A DevWorkspaceTemplate is a custom resource that defines a reusable spec.template for Dev Workspaces.

When a workspace is started, DWO reads the corresponding Dev Workspace CR and creates the necessary resources such as deployments, secrets, configmaps, and routes. As a result, a workspace pod representing the development environment defined in the devfile is created.

2.3.3.1. Custom Resources overview
Copy link

The following Custom Resource Definitions are provided by the Dev Workspace Operator:

  • Dev Workspace
  • DevWorkspaceTemplate
  • DevWorkspaceOperatorConfig
  • DevWorkspaceRouting

2.3.3.2. Dev Workspace
Copy link

The Dev Workspace custom resource contains details about an OpenShift Dev Spaces workspace. Notably, it contains devfile details and a reference to the editor definition.

2.3.3.3. DevWorkspaceTemplate
Copy link

In OpenShift Dev Spaces the DevWorkspaceTemplate custom resource is typically used to define an editor (such as Visual Studio Code - Open Source) for OpenShift Dev Spaces workspaces. You can use this custom resource to define reusable spec.template content that is reused by multiple Dev Workspaces.

2.3.3.4. DevWorkspaceOperatorConfig
Copy link

The DevWorkspaceOperatorConfig (DWOC) custom resource defines configuration options for the DWO. There are two different types of DWOC:

  • global configuration
  • non-global configuration

The global configuration is a DWOC custom resource named devworkspace-operator-config and is usually located in the DWO installation namespace. By default, the global configuration is not created upon installation. Configuration fields set in the global configuration apply to the DWO and all Dev Workspaces. However, the DWOC configuration can be overridden by a non-global configuration.

Any other DWOC custom resource than devworkspace-operator-config is considered to be non-global configuration. A non-global configuration does not apply to any Dev Workspaces unless the Dev Workspace contains a reference to the DWOC. If the global configuration and non-global configuration have the same fields, the non-global configuration field takes precedence.

Expand
Table 2.1. Global DWOC and OpenShift Dev Spaces-owned DWOC comparison
 Global DWOCOpenShift Dev Spaces-owned DWOC

Resource name

devworkspace-operator-config

devworkspace-config

Namespace

DWO installation namespace

OpenShift Dev Spaces installation namespace

Default creation

Not created by default upon DWO installation

Created by default on OpenShift Dev Spaces installation

Scope

Applies to the DWO itself and all Dev Workspaces managed by DWO

Applies to Dev Workspaces created by OpenShift Dev Spaces

Precedence

Overridden by fields set in OpenShift Dev Spaces-owned config

Takes precedence over global config if both define the same field

Primary use case

Used to define default, broad settings that apply to DWO in general.

Used to define specific configuration for Dev Workspaces created by OpenShift Dev Spaces

For example, by default OpenShift Dev Spaces creates and manages a non-global DWOC in the OpenShift Dev Spaces namespace named devworkspace-config. This DWOC contains configuration specific to OpenShift Dev Spaces workspaces, and is maintained by OpenShift Dev Spaces depending on how you configure the CheCluster CR. When OpenShift Dev Spaces creates a workspace, OpenShift Dev Spaces adds a reference to the OpenShift Dev Spaces-owned DWOC with the controller.devfile.io/devworkspace-config attribute.

Figure 2.4. Example of Dev Workspace configuration attribute

DevWorkspace config attribute example

2.3.3.5. DevWorkspaceRouting
Copy link

The DevWorkspaceRouting custom resource defines details about the endpoints of a Dev Workspace. Every Dev Workspace has its corresponding DevWorkspaceRouting object that specifies the workspace’s container endpoints. Endpoints defined from the devfile, as well as endpoints defined by the editor definition appear in the DevWorkspaceRouting custom resource. 

apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceRouting
metadata:
  annotations:
    controller.devfile.io/devworkspace-started: 'false'
  name: routing-workspaceb14aa33254674065
  labels:
    controller.devfile.io/devworkspace_id: workspaceb14aa33254674065
spec:
  devworkspaceId: workspaceb14aa33254674065
  endpoints:
    universal-developer-image:
      - attributes:
          cookiesAuthEnabled: true
          discoverable: false
          type: main
          urlRewriteSupported: true
        exposure: public
        name: che-code
        protocol: https
        secure: true
        targetPort: 3100
  podSelector:
    controller.devfile.io/devworkspace_id: workspaceb14aa33254674065
  routingClass: che
status:
  exposedEndpoints:
    ...

2.3.3.6. Dev Workspace Operator operands
Copy link

The Dev Workspace Operator has two operands:

  • controller deployment
  • webhook deployment. 
$ oc get pods -l 'app.kubernetes.io/part-of=devworkspace-operator' -o custom-columns=NAME:.metadata.name -n openshift-operators
NAME
devworkspace-controller-manager-66c6f674f5-l7rhj
devworkspace-webhook-server-d4958d9cd-gh7vr
devworkspace-webhook-server-d4958d9cd-rfvj6

where:

devworkspace-controller-manager-*
The Dev Workspace controller pod, which is responsible for reconciling custom resources.
devworkspace-webhook-server-*
The Dev Workspace operator webhook server pods.

You can configure the devworkspace-controller-manager pod in the Dev Workspace Operator Subscription object: 

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: devworkspace-operator
  namespace: openshift-operators
spec:
  config:
    affinity:
      nodeAffinity: ...
      podAffinity: ...
    resources:
      limits:
        memory: ...
        cpu: ...
      requests:
        memory: ...
        cpu: ...

You can configure the devworkspace-webhook-server deployment in the global DWOC: 

apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
  name: devworkspace-operator-config
  namespace: <DWO install namespace>
config:
  webhooks:
    nodeSelector: <map[string]string>
    replicas: <int>
    tolerations: <[]corev1.Toleration>

2.3.4. OpenShift Dev Spaces gateway
Copy link

The OpenShift Dev Spaces gateway routes requests, authenticates users, and applies access control policies for OpenShift Dev Spaces resources.

The OpenShift Dev Spaces gateway has the following roles:

  • Routing requests. It uses Traefik.
  • Authenticating users with OpenID Connect (OIDC). It uses OAuth2 Proxy.
  • Applying OpenShift Role Based Access Control (RBAC) policies to control access to any OpenShift Dev Spaces resource. It uses kube-rbac-proxy.

The OpenShift Dev Spaces operator manages it as the che-gateway Deployment.

It controls access to the user dashboard, the OpenShift Dev Spaces server, the plug-in registry, and user workspaces.

Figure 2.5. OpenShift Dev Spaces gateway interactions with other components

Gateway interactions

2.3.5. User dashboard
Copy link

The user dashboard is the landing page of Red Hat OpenShift Dev Spaces, providing a central interface for users to create, access, and manage their workspaces.

It needs access to the OpenShift Dev Spaces server, the plug-in registry, and the OpenShift Application Programming Interface (API).

Figure 2.6. User dashboard interactions with other components

User dashboard interactions with other components

When the user requests the user dashboard to start a workspace, the user dashboard executes this sequence of actions:

  1. Sends the repository URL to the OpenShift Dev Spaces server and expects a devfile in return, when the user is creating a workspace from a remote devfile.
  2. Reads the devfile describing the workspace.
  3. Collects the additional metadata from the plug-in registry.
  4. Converts the information into a Dev Workspace Custom Resource.
  5. Creates the Dev Workspace Custom Resource in the user project using the OpenShift API.
  6. Watches the Dev Workspace Custom Resource status.
  7. Redirects the user to the running workspace IDE.

2.3.6. OpenShift Dev Spaces server
Copy link

The OpenShift Dev Spaces server is a Java web service that manages user namespaces, provisions secrets and config maps, and integrates with Git service providers.

The OpenShift Dev Spaces server main functions are:

  • Creating user namespaces.
  • Provisioning user namespaces with required secrets and config maps.
  • Integrating with Git services providers, to fetch and validate devfiles and authentication.

The OpenShift Dev Spaces server is a Java web service exposing a Hypertext Transfer Protocol (HTTP) REST API and needs access to:

  • Git service providers
  • OpenShift API

Figure 2.7. OpenShift Dev Spaces server interactions with other components

OpenShift Dev Spaces server interactions

2.3.7. Plug-in registry
Copy link

Each OpenShift Dev Spaces workspace starts with a specific editor and set of associated extensions. The OpenShift Dev Spaces plugin registry provides the list of available editors and editor extensions. A Devfile v2 describes each editor or extension.

The user dashboard reads the content of the registry.

Figure 2.8. Plugin registries interactions with other components

Plugin registries interactions with other components

2.4. User workspaces
Copy link

Figure 2.9. User workspaces interactions with other components

User workspaces interactions with other components

User workspaces provide browser-based IDEs running in OpenShift containers, giving developers on-demand access to editors, language servers, debugging tools, and application runtimes without local setup.

A User workspace is a web application. It consists of microservices running in containers providing all the services of a modern IDE running in your browser:

  • Editor
  • Language auto-completion
  • Language server
  • Debugging tools
  • Plug-ins
  • Application runtimes

A workspace is one OpenShift Deployment containing the workspace containers and enabled plugins, plus related OpenShift components:

  • Containers
  • ConfigMaps
  • Services
  • Endpoints
  • Ingresses or Routes
  • Secrets
  • Persistent Volumes (PV)

A OpenShift Dev Spaces workspace contains the source code of the projects, persisted in an OpenShift Persistent Volume (PV). Microservices have read/write access to this shared directory.

Use the devfile v2 format to specify the tools and runtime applications of an OpenShift Dev Spaces workspace.

The following diagram shows one running OpenShift Dev Spaces workspace and its components.

Figure 2.10. OpenShift Dev Spaces workspace components

Workspace components

In the diagram, there is one running workspace.

Calculate the CPU and memory resource consumption for the OpenShift Dev Spaces Operator, Dev Workspace Controller, and user workspaces to right-size your cluster for the expected number of concurrent users.

Note

The following link to an example devfile is a pointer to material from the upstream community. This material represents the very latest available content and the most recent best practices. These tips have not yet been vetted by Red Hat’s QE department, and they have not yet been proven by a wide user group. Please, use this information cautiously. It is best used for educational and 'developmental' purposes rather than 'production' purposes.

Prerequisites

  • You have a planned or existing OpenShift Dev Spaces deployment on OpenShift Container Platform 4.16 or later.
  • You have the devfiles that define the development environments for your users.
  • You have an estimate of the number of concurrent workspaces that your users will run.

Procedure

  1. Identify the workspace resource requirements from the devfile components section. The following example uses the Quarkus API example devfile.

    • The tools component of the devfile defines the following requests and limits: 

          memoryLimit: 6G
    memoryRequest: 512M
    cpuRequest: 1000m
    cpuLimit: 4000m

    • During workspace startup, an internal che-gateway container is implicitly provisioned with the following requests and limits: 

          memoryLimit: 256M
    memoryRequest: 64M
    cpuRequest: 50m
    cpuLimit: 500m

    • Additional memory and CPU are added implicitly for the Visual Studio Code - Open Source ("Code - OSS") editor: 

          memoryLimit: 1024M
    memoryRequest: 256M
    cpuRequest: 30m
    cpuLimit: 500m

    • Additional memory and CPU are added implicitly for a JetBrains IDE, for example IntelliJ IDEA Ultimate: 

          memoryLimit: 6144M
    memoryRequest: 2048M
    cpuRequest: 1500m
    cpuLimit: 2000m

  2. Calculate the sums of the resources required for each workspace. If you intend to use multiple devfiles, repeat this calculation for every expected devfile.

    Expand
    Table 2.2. Workspace requirements for the example devfile in the previous step
    PurposePodContainer nameMemory limitMemory requestCPU limitCPU request

    Developer tools

    workspace

    tools

    6 GiB

    512 MiB

    4000 m

    1000 m

    OpenShift Dev Spaces gateway

    workspace

    che-gateway

    256 MiB

    64 MiB

    500 m

    50 m

    Visual Studio Code

    workspace

    tools

    1024 MiB

    256 MiB

    500 m

    30 m

    Total

    7.3 GiB

    832 MiB

    5000 m

    1080 m

  3. Multiply the resources calculated per workspace by the number of workspaces that you expect all of your users to run simultaneously.

  4. Calculate the sums of the requirements for the OpenShift Dev Spaces Operator, Operands, and Dev Workspace Controller.

    Expand
    Table 2.3. Default requirements for the OpenShift Dev Spaces Operator, Operands, and Dev Workspace Controller
    PurposePod nameContainer namesMemory limitMemory requestCPU limitCPU request

    OpenShift Dev Spaces operator

    devspaces-operator

    devspaces-operator

    256 MiB

    64 MiB

    500 m

    100 m

    OpenShift Dev Spaces Server

    devspaces

    devspaces-server

    1 GiB

    512 MiB

    1000 m

    100 m

    OpenShift Dev Spaces Dashboard

    devspaces-dashboard

    devspaces-dashboard

    256 MiB

    32 MiB

    500 m

    100 m

    OpenShift Dev Spaces Gateway

    devspaces-gateway

    traefik

    4 GiB

    128 MiB

    1000 m

    100 m

    OpenShift Dev Spaces Gateway

    devspaces-gateway

    configbump

    256 MiB

    64 MiB

    500 m

    50 m

    OpenShift Dev Spaces Gateway

    devspaces-gateway

    oauth-proxy

    512 MiB

    64 MiB

    500 m

    100 m

    OpenShift Dev Spaces Gateway

    devspaces-gateway

    kube-rbac-proxy

    512 MiB

    64 MiB

    500 m

    100 m

    Plugin registry

    plugin-registry

    plugin-registry

    256 MiB

    32 MiB

    500 m

    100 m

    Dev Workspace Controller Manager

    devworkspace-controller-manager

    devworkspace-controller

    5 GiB

    100 MiB

    3000 m

    250 m

    Dev Workspace Controller Manager

    devworkspace-controller-manager

    kube-rbac-proxy

    N/A

    N/A

    N/A

    N/A

    Dev Workspace Operator Catalog

    devworkspace-operator-catalog

    registry-server

    N/A

    50 MiB

    N/A

    10 m

    Dev Workspace Webhook Server

    devworkspace-webhook-server

    webhook-server

    300 MiB

    20 MiB

    200 m

    100 m

    Dev Workspace Webhook Server

    devworkspace-webhook-server

    kube-rbac-proxy

    N/A

    N/A

    N/A

    N/A

    Total

    12.3 GiB

    1.1 GiB

    8.2

    1.1

  5. Add the workspace resources from step 3 and the operator resources from step 4 to determine total cluster resource requirements.

Verification

  • Verify that the total resource requirements account for all OpenShift Dev Spaces Operator components, Dev Workspace Controller components, and the expected number of concurrent workspaces.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top