3.5. 在全局配置工作区
本节描述了管理员如何全局配置工作区。
3.5.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.5.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.5.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 文档有关 git-config)。例 3.15.
/etc/gitconfig
文件的内容[http "https://10.33.177.118:3000"] sslCAInfo = /etc/config/che-git-tls-creds/certificate
3.5.4. 配置工作区 nodeSelector
本节论述了如何为 OpenShift Dev Spaces 工作区的 Pod 配置 nodeSelector
。
流程
使用 NodeSelector
OpenShift Dev Spaces 使用
CheCluster
自定义资源来配置nodeSelector
:spec: devEnvironments: nodeSelector: key: value
本节必须包含 每个节点标签 的一组
key=value
对,以组成 nodeSelector 规则。使用 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
必须在 OpenShift Dev Spaces 安装过程中配置 nodeSelector
。这可防止现有工作区因为现有工作区 PVC 和 Pod 被调度到不同区中造成的卷关联性冲突而运行失败。
为了避免在大型多区集群上的不同区中调度 Pod 和 PVC,请创建一个额外的 StorageClass
对象(请注意 allowedTopologies
字段),它将协调 PVC 创建过程。
通过 CheCluster
自定义资源将这个新创建的 StorageClass
的名称传递给 OpenShift Dev Spaces。如需更多信息,请参阅:第 3.9.1 节 “配置存储类”。
3.5.5. 打开 VSX 注册表 URL
为搜索和安装扩展,Microsoft Visual Studio Code - 开源编辑器使用嵌入的 Open VSX 注册表实例。您还可以将 OpenShift Dev Spaces 配置为使用另一个 Open VSX registry 实例,而不是嵌入的实例。
流程
在 CheCluster Custom Resource
spec.components.pluginRegistry.openVSXURL
字段中设置 Open VSX registry 实例的 URL。spec: components: # [...] pluginRegistry: openVSXURL: <your_open_vsx_registy> # [...]
3.5.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.16/html-single/user_guide/index#end-user-guide:mounting-configmaps
- https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.16/html-single/user_guide/index#end-user-guide:mounting-secrets
- https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.16/html-single/user_guide/index#end-user-guide:requesting-persistent-storage-for-workspaces
- 自动挂载卷、configmap 和 secret