Warning

This page was translated from the original Japanese version by PLaMo Translate. The Japanese version is authoritative; the English translation may contain inaccuracies.

Creating Interactive Work Environments

To create an interactive work environment on a cluster, use the Workspace feature. Workspaces are interactive work environments accessible via web browsers. They allow you to utilize PFCP’s computational resources through interfaces like JupyterLab.

Workspace Isolation

There are two isolation units for individual workspace instances: individual users and namespaces. When creating a workspace, you can select either isolation type.

Individual Users

Workspaces isolated by individual users are accessible only by the user who created the workspace. This makes them ideal for securely storing personal credentials such as SSH private keys.

Other users, including organization administrators, cannot access these workspaces. However, organization administrators can still suspend or delete workspaces.

Below is a list of available operations:

Namespaces

Workspaces isolated by namespaces are accessible to users with the org-edit Role in the namespace where the workspace was created. This enables sharing workspaces among users with appropriate namespace permissions.

Users without the org-edit Role for the namespace cannot access these workspaces.

Warning

Communication with workspace Pods is not allowed, even from Pods within the same namespace or different workspaces. For inter-Pod communication, create Pods outside the workspace scope.

Creating a Workspace

Note

Workspaces utilize the compute resources of your organization. If compute resources are insufficient, workspace creation may fail.

Note

Workspaces isolated at the individual user level can only be created in the root namespace. Therefore, creation requires granting either the org-edit or org-workspace-edit ClusterRole for the root namespace. For details on assigning ClusterRoles, refer to [Creating a RoleBinding].

1. Navigate to the [Workspaces page] in the portal and click the Create New button.
2. Fill out the form and click the Create button.

Accessing a Workspace

1. Access the [Workspaces page] in the portal.
2. Click the link in the URL column for the workspace you wish to access.

Pausing and Resuming Workspaces

Warning

Pausing a workspace will delete all data within that workspace. Data stored in PersistentVolumes will be preserved during pausing.

Pausing unused workspaces helps conserve compute resources.

1. Access the [Workspaces page] in the portal.
2. Select the workspace to pause and click the Pause button.

Paused workspaces can be resumed through the same procedure.

1. Access the [Workspaces page] in the portal.
2. Select the workspace to resume and click the Resume button.

Deleting a Workspace

Warning

Deleting an workspace will permanently remove all data within that workspace as well as any PersistentVolumes created from that workspace.

1. Access the [Workspaces page] in the portal.
2. Select the workspace to delete and click the Delete button.

Managing Workspaces Using Kubernetes Manifests

In addition to managing workspaces through the portal, you can also manage them using Kubernetes manifests. Using manifests enables automated workspace management and ensures consistent workspace configurations.

Workspace Custom Resource

Each instance of a workspace is represented by a Workspace custom resource.

The Workspace resource creates the actual Pod that constitutes the workspace. You can manage workspaces by creating, updating, or deleting Workspace resources.

Workspace resources are defined in the following format:

apiVersion: preferred.jp/v1alpha1
kind: Workspace
metadata:
  name: ...
  namespace: ...
spec:
  owner:
    type: Individual
  presetRef: ...
  podTemplate: ...
  volumeClaimTemplates:
  - ...

Tip

You can also view descriptions for each field using the kubectl explain workspace command.

• spec.owner.type field
  • Specifies the isolation type of the workspace.
  • Use Individual for user-specific isolation or Namespace for namespace-based isolation.
• spec.presetRef field
  • Specifies the [Preset] to apply to this workspace.
• spec.podTemplate field
  • Specifies the PodTemplateSpec to apply to the actual Pod that constitutes the workspace.
• spec.volumeClaimTemplates field
  • Specifies a list of [PersistentVolumeClaims] to be created from the workspace.
  • By referencing the created PersistentVolumeClaims in spec.podTemplate, the workspace can utilize PersistentVolumes.

Presets

You can pre-define the configuration of the actual Pod that constitutes the workspace as a Preset. Defining presets simplifies management of workspaces with similar configurations.

Presets define default values for the spec.podTemplate field that will be applied to the workspace. When creating the actual Pod for a workspace from the Workspace resource, any fields not specified in the spec.podTemplate field of the Workspace resource will be inherited from the preset. Fields specified in the spec.podTemplate field will be overridden with these values and the Pod will be created accordingly.

There are two types of presets: ClusterWorkspacePreset custom resources and WorkspacePreset custom resources.

ClusterWorkspacePreset Custom Resource

ClusterWorkspacePreset custom resources are presets shared across PFCP-managed clusters. They are available for use in workspaces across all organizations.

Available ClusterWorkspacePreset resources can be checked using the kubectl get clusterworkspacepreset command (or kubectl get cwspreset). You can select the desired ClusterWorkspacePreset by configuring the spec.presetRef field in the Workspace resource as follows:

apiVersion: preferred.jp/v1alpha1
kind: Workspace
spec:
  presetRef:
    apiVersion: preferred.jp/v1alpha1
    kind: ClusterWorkspacePreset
    name: NAME

If the spec.presetRef field is omitted, the default ClusterWorkspacePreset will be applied. Excerpting some values from the default ClusterWorkspacePreset, it looks like this:

apiVersion: preferred.jp/v1alpha1
kind: ClusterWorkspacePreset
metadata:
  name: default
spec:
  podTemplate:
    spec:
      containers:
      - name: workspace
        image: registry.pfcomputing.internal/mncore-sdk/mncore-sdk-full
        command:
        - /app/jupyter/bin/jupyter
        - lab

If the spec.podTemplate field in the Workspace resource is not specified, a Pod will be created with a workspace container that launches JupyterLab using the MN-Core SDK container image according to these values. You can override this default configuration by specifying container images, commands, etc. in the spec.podTemplate field. Additionally, you can configure resource requests for the workspace container and add containers other than the workspace container.

WorkspacePreset Custom Resource

WorkspacePreset custom resources are presets shared at the namespace level. Users with the org-edit Role for the namespace can create, update, or delete these resources.

WorkspacePreset resources present in the namespace can be checked using the kubectl get workspacepreset command (or kubectl get wspreset). You can select the desired WorkspacePreset by configuring the spec.presetRef field in the Workspace resource as follows:

apiVersion: preferred.jp/v1alpha1
kind: Workspace
spec:
  presetRef:
    apiVersion: preferred.jp/v1alpha1
    kind: WorkspacePreset
    name: NAME

Note

For a Workspace to reference a WorkspacePreset, the Workspace and WorkspacePreset must reside in the same namespace.