3.4. 全局配置工作区
本节论述了管理员如何全局配置工作区。
3.4.1. 限制用户可以保留的工作区数量
默认情况下,用户可以在仪表板中保留无限数量的工作区,但您可以限制这个数量来减少集群的要求。
此配置是 CheCluster
自定义资源的一部分:
spec: devEnvironments: maxNumberOfWorkspacesPerUser: <kept_workspaces_limit>1
- 1
- 设置每个用户的最大工作区数。默认值
-1
允许用户保留无限数量的工作区。使用正整数设置每个用户的最大工作区数。
流程
获取 OpenShift Dev Spaces 命名空间的名称。默认值为
openshift-devspaces
。$ oc get checluster --all-namespaces \ -o=jsonpath="{.items[*].metadata.namespace}"
配置
maxNumberOfWorkspacesPerUser
:$ oc patch checluster/devspaces -n openshift-devspaces \1 --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfWorkspacesPerUser": <kept_workspaces_limit>}}}'2
3.4.2. 允许用户同时运行多个工作区
默认情况下,一个用户一次只能运行一个工作区。您可以启用用户同时运行多个工作区。
如果使用默认存储方法,如果 pod 在多节点集群中的节点间分布,则用户可能会遇到同时运行工作区时可能会出现问题。从每个用户的 通用
存储策略切换到 per-workspace
存储策略,或 使用临时存储
类型可以避免或解决这些问题。
此配置是 CheCluster
自定义资源的一部分:
spec: devEnvironments: maxNumberOfRunningWorkspacesPerUser: <running_workspaces_limit>1
- 1
- 设置每个用户同时运行工作区的最大数量。
-1
值允许用户运行无限数量的工作区。默认值为1
。
流程
获取 OpenShift Dev Spaces 命名空间的名称。默认值为
openshift-devspaces
。$ oc get checluster --all-namespaces \ -o=jsonpath="{.items[*].metadata.namespace}"
配置
maxNumberOfRunningWorkspacesPerUser
:$ oc patch checluster/devspaces -n openshift-devspaces \1 --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerUser": <running_workspaces_limit>}}}'2
3.4.3. 带有自签名证书的 Git
您可以配置 OpenShift Dev Spaces,以支持使用自签名证书的 Git 供应商上的操作。
先决条件
-
具有 OpenShift 集群的管理权限的活跃
oc
会话。请参阅 OpenShift CLI 入门。 - Git 版本 2 或更高版本
流程
创建一个新的 ConfigMap,其中包含有关 Git 服务器的详情:
$ oc create configmap che-git-self-signed-cert \ --from-file=ca.crt=<path_to_certificate> \ 1 --from-literal=githost=<git_server_url> -n openshift-devspaces 2
- 1
- 自签名证书的路径。
- 2
- 指定 Git 服务器 URL 的可选参数,例如
https://git.example.com:8443
。在省略时,通过 HTTPS 为所有存储库使用自签名证书。
注意-
证书文件通常存储为 Base64 ASCII 文件,例如:
.pem
,.crt
,.ca-bundle
.保存证书文件的所有ConfigMap
都应该使用 Base64 ASCII 证书,而不是二进制数据证书。 -
需要信任证书链。如果
ca.crt
由证书颁发机构(CA)签名,则必须将 CA 证书包含在ca.crt
文件中。
在 ConfigMap 中添加所需的标签:
$ oc label configmap che-git-self-signed-cert \ app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
配置 OpenShift Dev Spaces 操作对象,以将自签名证书用于 Git 存储库。请参阅 第 3.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。
spec: devEnvironments: trustedCerts: gitTrustedCertsConfigMapName: che-git-self-signed-cert
验证步骤
创建并启动新的工作区。工作区使用的每个容器都挂载一个包含自签名证书的文件的特殊卷。容器的
/etc/gitconfig
文件包含与 Git 服务器主机(its URL)和http
部分中证书的路径相关的信息(请参阅有关 git-config的 Git 文档)。例 3.15.
/etc/gitconfig
文件的内容[http "https://10.33.177.118:3000"] sslCAInfo = /etc/config/che-git-tls-creds/certificate
3.4.4. 配置工作区 nodeSelector
本节论述了如何为 OpenShift Dev Spaces 工作区的 Pod 配置 nodeSelector
。
流程
使用 NodeSelector
OpenShift Dev Spaces 使用
CheCluster
自定义资源来配置nodeSelector
:spec: devEnvironments: nodeSelector: key: value
本节必须为每个节点标签包含一组
key=value
对,才能组成 nodeSelector 规则。https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#built-in-node-labels使用 Taints 和 Tolerations
这的工作方式与
nodeSelector
相反。不指定 Pod 将要调度到哪些节点,而是指定 Pod 无法调度到哪些节点。如需更多信息,请参阅 :https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration。OpenShift Dev Spaces 使用
CheCluster
自定义资源来配置容限
:spec: devEnvironments: tolerations: - effect: NoSchedule key: key value: value operator: Equal
nodeSelector
必须在 OpenShift Dev Spaces 安装过程中配置。这可防止现有工作区因为卷关联性冲突而无法运行,因为现有工作区 PVC 和 Pod 调度到不同的区中。
为了避免 Pod 和 PVC 调度到大型的多区集群中的不同区中,请创建额外的 StorageClass
对象(请注意 allowedTopologies
字段),这将协调 PVC 创建过程。
通过 CheCluster
自定义资源将这个新创建的 StorageClass
的名称传递给 OpenShift Dev Spaces。如需更多信息,请参阅: 第 3.8.1 节 “配置存储类”。
3.4.5. 打开 VSX registry URL
要搜索和安装扩展,Microsoft Visual Studio Code - 开源编辑器使用嵌入式 Open VSX registry 实例。您还可以将 OpenShift Dev Spaces 配置为使用另一个 Open VSX registry 实例,而不是嵌入的 registry 实例。
流程
在 CheCluster 自定义资源
spec.components.pluginRegistry.openVSXURL
字段中设置 Open VSX registry 实例的 URL。spec: components: # [...] pluginRegistry: openVSXURL: <your_open_vsx_registy> # [...]
3.4.6. 配置用户命名空间
此流程指导您使用 OpenShift Dev Spaces 将 ConfigMap
、Secret
和 PersistentVolumeClaim
从 openshift-devspaces
命名空间复制到大量特定于用户的命名空间。OpenShift Dev Spaces 会自动同步重要配置数据,如共享凭证、配置文件和证书到用户命名空间。
如果您对 openshift-devspaces 命名空间中的 Kubernetes 资源进行更改,OpenShift Dev Spaces 将立即在所有用户命名空间中复制更改。相反,如果在用户命名空间中修改了 Kubernetes 资源,OpenShift Dev Spaces 将立即恢复更改。
流程
创建以下
ConfigMap
以将其复制到每个用户命名空间中。要增强可配置性,您可以通过添加额外的标签和注解来自定义ConfigMap
。有关其他可能的标签和注解,请参阅 自动挂载卷、configmap 和 secret。kind: ConfigMap apiVersion: v1 metadata: name: user-configmap namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config data: ...
例 3.16. 将
settings.xml
文件挂载到用户工作区:kind: ConfigMap apiVersion: v1 metadata: name: user-settings-xml namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config annotations: controller.devfile.io/mount-as: subpath controller.devfile.io/mount-path: /home/user/.m2 data: settings.xml: | <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd"> <localRepository>/home/user/.m2/repository</localRepository> <interactiveMode>true</interactiveMode> <offline>false</offline> </settings>
创建以下
Secret
以将其复制到每个用户命名空间中。要增强可配置性,您可以通过添加额外的标签和注解来自定义Secret
。有关其他可能的标签和注解,请参阅 自动挂载卷、configmap 和 secret。kind: Secret apiVersion: v1 metadata: name: user-secret namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config data: ...
例 3.17. 将证书挂载到用户工作区:
kind: Secret apiVersion: v1 metadata: name: user-certificates namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config annotations: controller.devfile.io/mount-as: subpath controller.devfile.io/mount-path: /etc/pki/ca-trust/source/anchors stringData: trusted-certificates.crt: | ...
注意在工作区启动时运行
update-ca-trust
命令以导入证书。它可以手动实现,也可以将此命令添加到 devfile 中的postStart
事件中。请参阅在 devfile 中添加事件绑定。例 3.18. 将环境变量挂载到用户工作区:
kind: Secret apiVersion: v1 metadata: name: user-env namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config annotations: controller.devfile.io/mount-as: env stringData: ENV_VAR_1: value_1 ENV_VAR_2: value_2
创建以下
PersistentVolumeClaim
,将其复制到每个用户命名空间中。要增强可配置性,您可以通过添加额外的标签和注解来自定义
PersistentVolumeClaim
。有关其他可能的标签和注解,请参阅 自动挂载卷、configmap 和 secret。要修改 'PersistentVolumeClaim',请删除它并在 openshift-devspaces 命名空间中创建一个新。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: user-pvc namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config spec: ...
例 3.19. 将
PersistentVolumeClaim
挂载到用户工作区:apiVersion: v1 kind: PersistentVolumeClaim metadata: name: user-pvc namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config controller.devfile.io/mount-to-devworkspace: 'true' annotations: controller.devfile.io/mount-path: /home/user/data controller.devfile.io/read-only: 'true' spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi volumeMode: Filesystem
其他资源
- https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.13/html-single/user_guide/index#end-user-guide:mounting-configmaps
- https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.13/html-single/user_guide/index#end-user-guide:mounting-secrets
- https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.13/html-single/user_guide/index#end-user-guide:requesting-persistent-storage-for-workspaces
- 自动挂载卷、configmap 和 secret