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 users 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 during creation.

Individual User Isolation

Workspaces isolated at the individual user level 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 organizational administrators, cannot access these workspaces. However, organizational administrators can suspend or delete workspaces.

Below is a comprehensive list of available operations:

Namespace Isolation

Workspaces isolated at the namespace level are accessible by users with the [org-edit Role] for the namespace in which the workspace was created. This enables sharing workspaces among users who have appropriate permissions for the namespace.

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

[org-edit Role]: ./role-binding.md#pfcp-Standard-Provided Roles and Groups

Creating a Workspace

Note

Workspaces utilize computational resources from your organization. If computational 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 instructions on assigning ClusterRoles, see 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 on the URL link in the column corresponding to the workspace you wish to access.

   Pausing and Resuming Workspaces

Warning

Pausing a workspace will delete all data contained within it. Data stored in PersistentVolumes will be preserved during the pause period.

Pausing unused workspaces can help conserve computational resources.

1. Access the Workspaces page in the portal.

2. Select the workspace you want to pause and click the Pause button. Pause-enabled workspaces can be resumed using the same procedure.

3. Access the Workspaces page in the portal.

4. Select the workspace you want to resume and click the Resume button.

Deleting Workspaces

Warning

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

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

Managing Workspaces Using Kubernetes Manifests

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

Workspace Custom Resource

Each workspace instance is represented by a Workspace custom resource.

The Workspace resource automatically creates the underlying 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 detailed field descriptions by running 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 be applied to the workspace.

• spec.podTemplate field

  • Specifies the PodTemplateSpec to be applied to the underlying Pod that forms the workspace.

• spec.volumeClaimTemplates field

  • Specifies a list of [PersistentVolumeClaims] to be created from the workspace.
  • By referencing the PersistentVolumeClaims created in spec.podTemplate, the workspace can utilize PersistentVolumes.

Presets

You can pre-define the configuration for the underlying Pod of a workspace as a preset. Defining presets simplifies the management of workspaces with similar configurations.

A preset specifies default values for the spec.podTemplate field that will be applied to the workspace. When creating a workspace’s underlying Pod from a Workspace resource, any fields not specified in the Workspace resource’s spec.podTemplate field will be inherited from the preset. Fields explicitly defined in the spec.podTemplate field will override the preset values and will be used to create the Pod.

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

ClusterWorkspacePreset Custom Resource

A ClusterWorkspacePreset custom resource is a shared preset used across the entire PFCP-managed cluster. It can be utilized by workspaces across all organizations.

Available ClusterWorkspacePreset resources can be listed using the kubectl get clusterworkspacepreset command (or kubectl get cwspreset). To apply a specific ClusterWorkspacePreset, you can set the spec.presetRef field in your 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. Below is a partial excerpt of some values from the default ClusterWorkspacePreset:

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 is not specified in the Workspace resource, 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, and other parameters in the spec.podTemplate field. Additionally, you can configure resource requests for the workspace container and add other containers in addition to the workspace container.

WorkspacePreset Custom Resource

The WorkspacePreset custom resource is a shared preset defined at the namespace level. Users with the [org-edit Role] for the namespace can create, update, or delete this resource.

WorkspacePreset resources within a namespace can be listed using the kubectl get workspacepreset command (or kubectl get wspreset). You can apply a specific WorkspacePreset by setting 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, both the Workspace and WorkspacePreset must reside in the same namespace.