4.8. 配置网络


4.8.1. 配置网络策略

默认情况下,OpenShift 集群中的所有 Pod 都可以相互通信,即使它们位于不同的命名空间中。在 OpenShift Dev Spaces 中,这可能会导致一个用户项目中的工作区 Pod 将流量发送到其他用户项目中的另一个工作区 Pod。

为安全起见,可以使用 NetworkPolicy 对象配置多租户隔离,以限制用户项目中的所有传入的通信。但是,OpenShift Dev Spaces 项目中的 Pod 必须能够与用户项目中的 Pod 通信。

先决条件

  • OpenShift 集群有网络限制,如多租户隔离。

流程

  • allow-from-openshift-devspaces NetworkPolicy 应用到每个用户项目。allow-from-openshift-devspaces NetworkPolicy 允许从 OpenShift Dev Spaces 命名空间的传入流量到用户项目中的所有 Pod。

    例 4.45. allow-from-openshift-devspaces.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
        name: allow-from-openshift-devspaces
    spec:
        ingress:
        - from:
            - namespaceSelector:
                matchLabels:
                    kubernetes.io/metadata.name: openshift-devspaces   
    1
    
        podSelector: {}   
    2
    
        policyTypes:
        - Ingress
    Copy to Clipboard
    1
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces
    2
    podSelector 选择项目中的所有 Pod。
  • OPTIONAL : 在使用网络策略应用配置多租户隔离时,还必须应用 allow-from-openshift-apiserverallow-from-workspaces-namespaces NetworkPolicies 到 openshift-devspacesallow-from-openshift-apiserver NetworkPolicy 允许从 openshift-apiserver 命名空间中的传入流量到 devworkspace-webhook-server 启用 Webhook。allow-from-workspaces-namespaces NetworkPolicy 允许从每个用户项目的传入流量到 che-gateway pod。

    例 4.46. allow-from-openshift-apiserver.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-openshift-apiserver
      namespace: openshift-devspaces   
    1
    
    spec:
      podSelector:
        matchLabels:
          app.kubernetes.io/name: devworkspace-webhook-server   
    2
    
      ingress:
        - from:
            - podSelector: {}
              namespaceSelector:
                matchLabels:
                  kubernetes.io/metadata.name: openshift-apiserver
      policyTypes:
        - Ingress
    Copy to Clipboard
    1
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces
    2
    podSelector 只选择 devworkspace-webhook-server pod

    例 4.47. allow-from-workspaces-namespaces.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-workspaces-namespaces
      namespace: openshift-devspaces   
    1
    
    spec:
      podSelector: {}   
    2
    
      ingress:
        - from:
            - podSelector: {}
              namespaceSelector:
                matchLabels:
                  app.kubernetes.io/component: workspaces-namespace
      policyTypes:
        - Ingress
    Copy to Clipboard
    1
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces
    2
    podSelector 选择 OpenShift Dev Spaces 命名空间中的所有 pod。
  • 第 4.2 节 “配置项目”
  • 网络隔离
  • 使用网络策略配置多租户隔离

4.8.2. 配置 Dev Spaces 主机名

此流程描述了如何将 OpenShift Dev Spaces 配置为使用自定义主机名。

先决条件

  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门
  • 生成证书和私钥文件。
重要

要生成私钥和证书的对,相同的证书颁发机构(CA)必须与其他 OpenShift Dev Spaces 主机一起使用。

重要

请求 DNS 供应商将自定义主机名指向集群入口。

流程

  1. 为 OpenShift Dev Spaces 预创建项目:

    $ oc create project openshift-devspaces
    Copy to Clipboard
  2. 创建 TLS secret:

    $ oc create secret tls <tls_secret_name> \ 
    1
    
    --key <key_file> \ 
    2
    
    --cert <cert_file> \ 
    3
    
    -n openshift-devspaces
    Copy to Clipboard
    1
    TLS secret 名称
    2
    具有私钥的文件
    3
    具有证书的文件
  3. 在 secret 中添加所需的标签:

    $ oc label secret <tls_secret_name> \ 
    1
    
    app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
    Copy to Clipboard
    1
    TLS secret 名称
  4. 配置 CheCluster 自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

    spec:
      networking:
        hostname: <hostname>     
    1
    
        tlsSecretName: <secret>  
    2
    Copy to Clipboard
    1
    自定义 Red Hat OpenShift Dev Spaces 服务器主机名
    2
    TLS secret 名称
  5. 如果 OpenShift Dev Spaces 已部署,请等待所有 OpenShift Dev Spaces 组件的推出完成。

4.8.3. 将不可信 TLS 证书导入到 Dev Spaces

OpenShift Dev Spaces 组件与外部服务通信通过 TLS 加密。它们需要由可信证书颁发机构(CA)签名的 TLS 证书。因此,您必须导入到 OpenShift Dev Spaces 中由外部服务使用的所有不受信任的 CA 链,例如:

  • 代理
  • 身份供应商(OIDC)
  • 源代码存储库供应商(Git)

OpenShift Dev Spaces 使用 OpenShift Dev Spaces 项目中的标记 ConfigMap 作为 TLS 证书的源。ConfigMap 可以有任意数量的键,每个键都有随机数量的证书。所有证书都挂载到:

  • OpenShift Dev Spaces 服务器和仪表板 pod 的 /public-certs 位置
  • 工作区 pod 的 /etc/pki/ca-trust/extracted/pem 位置

配置 CheCluster 自定义资源,以禁用在 /etc/pki/ca-trust/extracted/pem 处的 CA 捆绑包挂载。证书将被挂载到 /public-certs,以保持之前版本中的行为。

注意

配置 CheCluster 自定义资源,以禁用在路径 /etc/pki/ca-trust/extracted/pem 下挂载 CA 捆绑包。在这种情况下,证书将被挂载到路径 /public-certs 下。

spec:
  devEnvironments:
    trustedCerts:
      disableWorkspaceCaBundleMount: true
Copy to Clipboard
重要

在 OpenShift 集群中,OpenShift Dev Spaces Operator 会自动将 Red Hat Enterprise Linux CoreOS (RHCOS)信任捆绑包添加到挂载的证书中。

先决条件

  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门
  • openshift-devspaces 项目存在。
  • 对于每个要导入的 CA 链:使用 PEM 格式的 root CA 和中间证书,采用 ca-cert-for-devspaces- <count>.pem 文件。

流程

  1. 将所有 CA 链 PEM 文件链到 custom-ca-certificates.pem 文件中,并删除与 Java 信任存储不兼容的返回字符。

    $ cat ca-cert-for-devspaces-*.pem | tr -d '\r' > custom-ca-certificates.pem
    Copy to Clipboard
  2. 使用所需的 TLS 证书创建 custom-ca-certificates ConfigMap:

    $ oc create configmap custom-ca-certificates \
        --from-file=custom-ca-certificates.pem \
        --namespace=openshift-devspaces
    Copy to Clipboard
  3. 标记 custom-ca-certificates ConfigMap:

    $ oc label configmap custom-ca-certificates \
        app.kubernetes.io/component=ca-bundle \
        app.kubernetes.io/part-of=che.eclipse.org \
        --namespace=openshift-devspaces
    Copy to Clipboard
  4. 如果之前尚未部署,部署 OpenShift Dev Spaces。否则,请等待 OpenShift Dev Spaces 组件的推出完成。
  5. 重启正在运行的工作区以使更改生效。

验证步骤

  1. 验证 ConfigMap 是否包含您的自定义 CA 证书。此命令返回 PEM 格式的 CA 捆绑包证书:

    oc get configmap \
        --namespace=openshift-devspaces \
        --output='jsonpath={.items[0:].data.custom-ca-certificates\.pem}' \
        --selector=app.kubernetes.io/component=ca-bundle,app.kubernetes.io/part-of=che.eclipse.org
    Copy to Clipboard
  2. 在 OpenShift Dev Spaces 服务器日志中验证导入的证书计数是否不是 null :

    oc logs deploy/devspaces --namespace=openshift-devspaces \
        | grep tls-ca-bundle.pem
    Copy to Clipboard
  3. 启动一个工作区,获取创建它的项目名称:< workspace_namespace > 并等待工作区启动。
  4. 验证 ca-certs-merged ConfigMap 是否包含您的自定义 CA 证书。此命令以 PEM 格式返回 OpenShift Dev Spaces CA 捆绑包证书:

    oc get configmap che-trusted-ca-certs \
        --namespace=<workspace_namespace> \
        --output='jsonpath={.data.tls-ca-bundle\.pem}'
    Copy to Clipboard
  5. 验证工作区 pod 是否挂载 ca-certs-merged ConfigMap:

    oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].spec.volumes[0:].configMap.name}' \
        | grep ca-certs-merged
    Copy to Clipboard
  6. 获取工作区 pod 名称 < workspace_pod_name>:

    oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].metadata.name}' \
    Copy to Clipboard
  7. 验证工作区容器是否具有您的自定义 CA 证书。此命令以 PEM 格式返回 OpenShift Dev Spaces CA 捆绑包证书:

    oc exec <workspace_pod_name> \
        --namespace=<workspace_namespace> \
        -- cat /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
    Copy to Clipboard

4.8.4. 添加标签和注解

4.8.4.1. 配置 OpenShift 路由以使用路由器划分

您可以为 OpenShift Route 配置标签、注解和域,以用于 路由器分片

先决条件

流程

  • 配置 CheCluster 自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

    spec:
      networking:
        labels: <labels> 
    1
    
        domain: <domain> 
    2
    
        annotations: <annotations> 
    3
    Copy to Clipboard
    1
    一个无结构的键值映射,目标入口控制器用来过滤一组 Routes to service。
    2
    目标入口控制器服务的 DNS 名称。
    3
    一个无结构的键值映射,它存储了一个资源。

4.8.5. 配置工作区端点基域

了解如何为工作区端点配置基域。默认情况下,OpenShift Dev Spaces Operator 会自动检测到基域。要更改它,您需要在 CheCluster 自定义资源中配置 CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX 属性。

spec:
  components:
    cheServer:
      extraProperties:
        CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX: "<...>" 
1
Copy to Clipboard
1
工作区端点基域,如 my-devspaces.example.com

流程

  1. 配置工作区端点基域:

    oc patch checluster/devspaces \
        --namespace openshift-devspaces \
        --type='merge' -p \
    '{"spec":
        {"components":
            {"cheServer":
                {"extraProperties":
                    {"CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX": "my-devspaces.example.com"}}}}}'
    Copy to Clipboard

4.8.6. 配置代理

了解如何为 Red Hat OpenShift Dev Spaces 配置代理。步骤包括为代理凭证创建 Kubernetes Secret,并在 CheCluster 自定义资源中配置必要的代理设置。代理设置通过环境变量传播到操作对象和工作区。

在 OpenShift 集群中,您不需要配置代理设置。OpenShift Dev Spaces Operator 会自动使用 OpenShift 集群范围的代理配置。但是,您可以通过在 CheCluster 自定义资源中指定代理设置来覆盖代理设置。

流程

  1. (可选)在 openshift-devspaces 命名空间中创建 Secret,其中包含代理服务器的用户和密码。secret 必须具有 app.kubernetes.io/part-of=che.eclipse.org 标签。如果代理服务器不需要身份验证,请跳过这一步。

    oc apply -f - <<EOF
    kind: Secret
    apiVersion: v1
    metadata:
      name: devspaces-proxy-credentials
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
    type: Opaque
    stringData:
      user: <user>          
    1
    
      password: <password>  
    2
    
    EOF
    Copy to Clipboard
    1
    代理服务器的用户名。
    2
    代理服务器的密码。
  2. 通过在 CheCluster 自定义资源中设置以下属性,为 OpenShift 集群配置代理或覆盖集群范围的代理配置:

    oc patch checluster/devspaces \
        --namespace openshift-devspaces \
        --type='merge' -p \
    '{"spec":
        {"components":
            {"cheServer":
                {"proxy":
                    {"credentialsSecretName" : "<secretName>",                      
    1
    
                     "nonProxyHosts"         : ["<host_1>"],                        
    2
    
                     "port"                  : "<port>",                            
    3
    
                     "url"                   : "<protocol>://<domain>"}}}}}'    
    4
    Copy to Clipboard
    1
    上一步中创建的凭据 secret 名称。
    2
    可以直接访问的主机列表,无需使用代理。使用以下格式,.<DOMAIN > 指定一个通配符域。OpenShift Dev Spaces Operator 会自动将 .svc 和 Kubernetes 服务主机添加到非代理主机列表中。在 OpenShift 中,OpenShift Dev Spaces Operator 将集群范围的代理配置中的非代理主机列表与自定义资源合并。
    重要

    在一些代理配置中,localhost 可能不会转换为 127.0.0.1。在这种情况下,应该同时指定 localhost127.0.0.1

    代理服务器的端口。
    代理服务器的协议和域。

验证步骤

  1. 启动工作区
  2. 验证工作区 pod 是否包含 HTTP_PROXYHTTPS_PROXYhttp_proxyhttps_proxy 环境变量,每个变量都设置为 < protocol> ://<user& gt;:<password@<domain>:<port>
  3. 验证工作区 pod 是否包含 NO_PROXYno_proxy 环境变量,每个变量都设置为用逗号分开的非代理主机列表。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat