应用程序

流程

1. 浏览至 Home → Project。
2. 点击 Create Project。
3. 输入项目详情。
4. 点击 Create。

1. 点 Project 下拉菜单来查看所有可用的项目。选择 Create Project。

   
2. 在 Create Project 对话框的 Name 项中输入一个唯一的名称，如 myproject。
3. 可选：为项目添加 Display Name 和 Description 详情。
4. 点击 Create。
5. 使用左侧导航面板导航到 Project 视图，在仪表板中查看您的项目。

6. 可选：

   • 在屏幕顶部的 Project 下拉菜单中选择 all projects 列出集群中的所有项目。
   • 使用 Details 选项卡查看项目详情。
   • 如果您有足够的项目权限，可以使用 Project Access 选项卡为项目提供或撤销 administrator、edit 和 view 权限。

流程

1. 运行：

流程

1. 浏览至 Home → Project。

2. 选择要查看的项目。

   在此页面上，点击 Workloads 按钮来查看项目中的工作负载。

流程

1. 要查看项目列表，请运行：

   $ oc get projects

2. 您可以从当前项目更改到其他项目，以进行 CLI 操作。然后，所有操控项目范围内容的后续操作都会使用指定的项目：

   $ oc project <project_name>

1. 在 Developer 视角中，导航到 Advanced → Project Access 页面。

2. 在 Project Access 页面中，点 Add Access 以添加新行。

   
3. 输入用户名，点 Select a role 下拉列表，然后选择适当的角色。
4. 点 Save。

流程

1. 在 Web 控制台导航菜单顶部的上下文选择器中，选择 Developer。
2. 点击 + Add
3. 在页面顶部，选择要添加到的项目的名称。
4. 点击添加到项目的方法，然后按照工作流操作。

流程

1. 浏览至 Home → Project。
2. 选择一个项目来查看其状态。

流程

1. 运行：

   $ oc status

   此命令提供当前项目的高级概述，以及它的组件和关系。

流程

1. 浏览至 Home → Project。
2. 找到您要从项目列表中删除的项目。
3. 在项目列表的最右侧，从 Options 菜单中选择 Delete Project。
4. 打开 Delete Project 界面时，在字段中输入要删除的项目名称。
5. 点击 Delete。

流程

1. 运行：

   $ oc delete project <project_name>

流程

1. 以具有 cluster-admin 特权的用户身份登录。

2. 生成默认项目模板：

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. 使用文本编辑器，通过添加对象或修改现有对象来修改生成的 template.yaml 文件。

4. 项目模板必须创建在 openshift-config 命名空间中。加载修改后的模板：

   $ oc create -f template.yaml -n openshift-config

5. 使用 Web 控制台或 CLI 编辑项目配置资源。

   • 使用 Web 控制台：

     1. 导航至 Administration → Cluster Settings 页面。
     2. 点击 Global Configuration，查看所有配置资源。
     3. 找到 Project 的条目，并点击 Edit YAML。

   • 使用 CLI：

     1. 编辑 project.config.openshift.io/cluster 资源：

        $ oc edit project.config.openshift.io/cluster

6. 更新 spec 部分，使其包含 projectRequestTemplate 和 name 参数，再设置您上传的项目模板的名称。默认名称为 project-request。

   带有自定义项目模板的项目配置资源

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestTemplate:
       name: <template_name>

7. 保存更改后，创建一个新项目来验证是否成功应用了您的更改。

流程

1. 以具有 cluster-admin 特权的用户身份登录。

2. 运行以下命令，以查看 self-provisioners 集群角色绑定用法：

   $ oc describe clusterrolebinding.rbac self-provisioners
   
   Name:		self-provisioners
   Labels:		<none>
   Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
   Role:
     Kind:	ClusterRole
     Name:	self-provisioner
   Subjects:
     Kind	Name				Namespace
     ----	----				---------
     Group	system:authenticated:oauth

   检查 self-provisioners 部分中的主题。

3. 从 system:authenticated:oauth 组中移除 self-provisioner 集群角色。

   • 如果 self-provisioners 集群角色绑定仅将 self-provisioner 角色绑定至 system:authenticated:oauth 组，请运行以下命令：

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{"subjects": null}'

   • 如果 self-provisioners 集群角色将 self-provisioner 角色绑定到 system:authenticated:oauth 组以外的多个用户、组或服务帐户，请运行以下命令：

     $ oc adm policy \
         remove-cluster-role-from-group self-provisioner \
         system:authenticated:oauth

4. 编辑 self-provisioners 集群角色绑定，以防止自动更新角色。自动更新会使集群角色重置为默认状态。

   • 使用 CLI 更新角色绑定：

     1. 运行以下命令：

        $ oc edit clusterrolebinding.rbac self-provisioners

     2. 在显示的角色绑定中，将 rbac.authorization.kubernetes.io/autoupdate 参数值设置为 false，如下例所示：

        apiVersion: authorization.openshift.io/v1
        kind: ClusterRoleBinding
        metadata:
          annotations:
            rbac.authorization.kubernetes.io/autoupdate: "false"
          ...

   • 使用单个命令更新角色绑定：

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{ "metadata": { "annotations": { "rbac.authorization.kubernetes.io/autoupdate": "false" } } }'

5. 以通过身份验证的用户身份登陆，验证是否无法再自助置备项目：

   $ oc new-project test
   
   Error from server (Forbidden): You may not request a new project via this API.

   您可以对此项目请求消息进行自定义，以提供特定于您的组织的更多有用说明。

流程

1. 使用 Web 控制台或 CLI 编辑项目配置资源。

   • 使用 Web 控制台：

     1. 导航至 Administration → Cluster Settings 页面。
     2. 点击 Global Configuration，查看所有配置资源。
     3. 找到 Project 的条目，并点击 Edit YAML。

   • 使用 CLI：

     1. 以具有 cluster-admin 特权的用户身份登录。

     2. 编辑 project.config.openshift.io/cluster 资源：

        $ oc edit project.config.openshift.io/cluster

2. 更新 spec 部分，使其包含 projectRequestMessage 参数，并将值设为您的自定义消息：

   带有自定义项目请求消息的项目配置资源

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: <message_string>

   例如：

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: To request a project, contact your system administrator at projectname@example.com.

3. 保存更改后，请尝试用无法自助置备项目的开发人员或服务帐户创建一个新项目，以验证是否成功应用了您的更改。

流程

1. 在 Add 视图中，点击 From Git 以查看 Import from git 表单。
2. 在 Git 部分中，输入您要用来创建应用程序的代码库的 Git 存储库 URL。例如，输入此示例 Node.js 应用程序的 URL https://github.com/sclorg/nodejs-ex。这个 URL 随后会被验证。

3. 可选：点 Show Advanced Git Options 来添加详情，例如：

   • git Reference，指向特定的分支、标签或提交中的代码，以用于构建应用程序。
   • Context Dir，指定要用来构建应用程序的应用程序源代码的子目录。
   • Source Secret，创建一个具有用来从私有存储库拉取源代码的凭证的 Secret Name。
4. 在 Builder 部分，当验证 URL 后，会检测到一个适当的构建器镜像，由一个星号指示，并自动选择。对于 https://github.com/sclorg/nodejs-ex Git URL，默认选择 Node.js 构建器镜像。如果需要，您可以使用 Builder Image Version 下拉列表来更改版本。

5. 在 General 部分中：

   1. 在 Application 字段中输入应用程序组别的唯一名称，例如 myapp。确保应用程序名称在命名空间中具有唯一性。

   2. 系统会基于 Git 存储库的 URL 自动填充 Name 字段，以标识为此应用程序创建的资源。

      注意

      资源名称必须在命名空间中具有唯一性。如果遇到错误，请修改资源名称。

6. 在 Resources 部分，选择：

   • Deployment，以纯 Kubernetes 风格方式创建应用程序。
   • Deployment Config，创建 OpenShift 风格的应用程序。
   • Knative Service，创建微服务。
   注意

   只有集群中安装了 Serverless Operator 时，Import from git 表单中才会显示 Knative Service 部分。如需进一步了解详细信息，请参阅有关安装 OpenShift Serverless 的文档。

7. Advanced Options 部分中默认选中 Create a route to the application，以便您可以使用公开的 URL 访问应用程序。如果不想通过公共路由公开您的应用程序，可以清除此复选框。

8. 可选：可以使用以下高级选项进一步自定义应用程序：

   路由

   点击 Routing 链接，以执行以下操作：

   • 自定义路由的主机名。
   • 指定路由器监控的路径。
   • 从下拉列表中选择流量的目标端口。

   • 选中 Secure Route 复选框来保护您的路由。从相应的下拉列表中，选择所需的 TLS 终止类型，并设置非安全流量的策略。

     对于无服务器应用程序，Knative Service 管理以上所有路由选项。但在需要时，您可以自定义流量的目标端口。如果不指定目标端口，则使用默认端口 8080。

   构建和部署配置

   点击 Build Configuration 和 Deployment Configuration 链接，以查看对应的配置选项。其中一些选项默认选中；您可以通过添加必要的触发器和环境变量来进一步自定义。对于无服务器应用程序，Deployment Configuration 选项不会显示，因为 Knative 配置资源为您的部署维护所需的状态，而不是由 DeploymentConfig 来维护。

   扩展

   点击 Scaling 链接，以定义您要初始部署的应用程序的 Pod 数或实例数。

   对于无服务器应用程序，可以：

   • autoscaler 可设置的 Pod 数设定上限和下限。如果不指定下限，则默认为零。
   • 定义给定时间上每个应用程序实例所需的并发请求数的软限值。它是自动扩展的推荐配置。如果不指定，它将使用集群配置中指定的值。
   • 定义给定时间上每个应用程序实例的并发请求数的硬限值。这在修订模板中进行配置。如果不指定，则默认为集群配置中指定的值。

   资源限值

   点击 Resource Limit 链接，设置容器在运行时保证或允许使用的 CPU 和 Memory 资源的数量。

   标签

   点击 Labels 链接，为您的应用程序添加自定义标签。

9. 点击 Create，以创建应用程序并在 Topology 视图中查看其构建状态。

流程

1. 针对此流程在 OpenShift Container Platform Web 控制台中新建一个项目。本示例所用项目名为 my-etcd。

2. 导航至 Operators → Installed Operators 页面。由集群管理员安装到集群且可供使用的 Operator 将以 ClusterServiceVersions (CSV) 列表形式显示在此处。CSV 用于启动和管理由 Operator 提供的软件。

   提示

   使用以下命令从 CLI 获得该列表：

   $ oc get csv

3. 进入 Installed Operators 页面，点击 Copied，然后点击 etcd Operator 查看更多详情和可用操作：

   图 2.1. etcd Operator 概述

   

   正如 Provided API 下所示，该 Operator 提供了三类新资源，包括一种用于 etcd Cluster 的资源（EtcdCluster 资源）。这些对象的工作方式类似于内置的原生 Kubernetes 对象（如 Deployments 或 ReplicaSets），但包含特定于管理 etcd 的逻辑。

4. 新建 etcd 集群：

   1. 在 etcd Cluster API 方框中，点击 Create New。
   2. 在下一页上，您可对 EtcdCluster 对象的最小起始模板进行任何修改，比如集群大小。现在，点击 Create 即可完成。点击后即可触发 Operator 启动 Pod、Services 和新 etcd 集群的其他组件。

5. 单击 Resources 选项卡，可以看到您的项目现在包含很多由 Operator 自动创建和配置的资源。

   图 2.2. etcd Operator 资源

   

   验证已创建了支持您从项目中的其他 Pod 访问数据库的 Kubernetes 服务。

6. 给定项目中具有 edit 角色的所有用户均可创建、管理和删除应用程序实例（本例中为 etcd 集群），这些实例由已在项目中创建的 Operator 以自助方式管理，就像云服务一样。如果要赋予其他用户这一权利，项目管理员可使用以下命令添加角色：

   $ oc policy add-role-to-user edit <user> -n <target_project>

流程

1. 在您的项目中创建并部署 MongoDB 服务，如下所示：

   1. 在 Developer 视角中，导航到 Add 视图，再选择 Database 选项来查看 Developer Catalog，其包含的多个选项可作为组件或服务添加到应用程序中。
   2. 点击 MongoDB 选项以查看该服务的详情。
   3. 点击 Instantiate Template 查看使用 MongoDB 服务的详情自动填充的模板，然后点击 Create 来创建服务。
2. 在左侧导航面板中，点击 Topology 以查看项目中部署的 MongoDB 服务。
3. 要将 MongoDB 服务添加到现有应用程序组中，请选择 mongodb Pod 并将其拖到应用程序中；MongoDB 服务会添加到现有应用程序组中。

4. 拖动组件并将其添加到应用程序组中时，会自动将所需的标签添加到组件。点击 MongoDB 服务节点，可看到标签 app.kubernetes.io/part-of=myapp 已添加到 Overview 面板中的 Labels 部分。

   

1. 要将 MongoDB 服务添加到应用程序中，请点击 mongodb Pod 以查看右侧的 Overview 面板。
2. 点击面板右上角的 Actions 下拉菜单，再选择 Edit Application Grouping。
3. 在 Edit Application Grouping 对话框中，点击 Select an Application 下拉列表，再选择适当的应用程序组。
4. 点击 Save 以查看添加到应用程序组中的 MongoDB 服务。

1. 点击您要删除的应用程序，即可看到包含应用程序资源详情的侧面板。
2. 点击面板右上角显示的 Actions 下拉菜单，然后选择 Delete Application 即可看到确认对话框。
3. 输入应用程序的名称，并点 Delete 将其删除。

流程

1. 启用服务目录 API 服务器。

   1. 使用以下命令来编辑服务目录 API 服务器资源。

      $ oc edit servicecatalogapiservers

   2. 在 spec下，将 managementState 字段设置为 Managed：

      spec:
        logLevel: Normal
        managementState: Managed

   3. 保存文件以应用更改。

      Operator 会安装服务目录 API 服务器组件。自 OpenShift Container Platform 4 起，此组件安装到 openshift-service-catalog-apiserver 命名空间中。

2. 启用服务目录控制器管理器。

   1. 使用以下命令来编辑服务目录控制器管理器资源。

      $ oc edit servicecatalogcontrollermanagers

   2. 在 spec下，将 managementState 字段设置为 Managed：

      spec:
        logLevel: Normal
        managementState: Managed

   3. 保存文件以应用更改。

      Operator 会安装服务目录控制器管理器组件。自 OpenShift Container Platform 4 起，此组件安装到 openshift-service-catalog-controller-manager 命名空间中。

1. 创建命名空间。

   1. 在 Web 控制台中导航至 Administration → Namespaces，再点击 Create Namespace。

   2. 在 Name 字段中，输入 openshift-template-service-broker 并点击 Create。

      注意

      命名空间必须以 openshift- 开头。

2. 导航到 Operators → OperatorHub 页面。验证是否已选中 openshift-template-service-broker 项目。
3. 选择 Template Service Broker Operator。
4. 阅读 Operator 的信息并点击 Install。
5. 检查默认选择并点击 Subscribe。

流程

1. 在 Web 控制台中导航到 Operators → Installed Operators，再选择 openshift-template-service-broker 项目。
2. 选择 Template Service Broker Operator。
3. 在 Provided APIs 下，点击 Template Service Broker 的 Create New。
4. 检查默认 YAML 并点击 Create。

5. 验证是否已启动 Template Service Broker。

   在 Template Service Broker 启动后，可以通过导航到 Catalog → Developer Catalog 并选中 Service Class 复选框来查看可用的模板应用程序。请注意，可能需要等几分钟后模板服务代理才会启动，并且模板应用程序可供使用。

   如果还没有看到这些服务类，您可以检查以下项目的状态：

   • Template Service Broker Pod 状态

     • 在 openshift-template-service-broker 项目的 Workloads → Pods 页面中，验证名称开头为 apiserver- 的 Pod 的状态是否为 Running 并且就绪状态是否为 Ready。

   • 集群服务代理状态

     • 在 Catalog → Broker Management → Service Brokers 页面中，验证 template-service-broker 服务代理的状态是否为 Ready。

   • 服务目录控制器管理器 Pod 日志

     • 在 openshift-service-catalog-controller-manager 项目的 Workloads → Pods 页面中，检查各个 Pod 的日志，并验证是否看到一个含有 Successfully fetched catalog entries from broker 消息的日志条目。

流程

1. 创建一个项目。

   1. 在 Web 控制台中，导航到 Home → Project 并点击 Create Project。
   2. 在 Name 字段中输入 test-postgresql，再点击 Create。

2. 创建服务实例。

   1. 导航到 Catalog → Developer Catalog 页面。
   2. 选择 PostgreSQL (Ephemeral) 模板应用程序，再点击 Create Service Instance。
   3. 检查默认选择项并设置任何其他必要的字段，然后点击 Create。

   4. 前往 Catalog → Provisioned Services，再验证 postgresql-ephemeral 服务实例是否已安装并具有 Ready 状态。

      您可以在 Home → Events 页面中查看进度。片刻之后，您应该会看到 postgresql-ephemeral 的一个事件，其含有“The instance was provisioned successfully”消息。

3. 创建服务绑定。

   1. 在 Provisioned Services 页面中，依次点击 postgresql-ephemeral 和 Create Service Binding。

   2. 检查默认服务绑定名称，再点击 Create。

      这会使用提供的名称为绑定创建一个新 secret。

4. 检查创建的 secret。

   1. 导航到 Workloads → Secrets，再验证是否创建了一个名为 postgresql-ephemeral 的 secret。
   2. 点击 postgresql-ephemeral，再查看 Data 部分中用于绑定到其他应用程序的键值对。

1. 卸载 Template Service Broker。

   1. 导航到 Operators → Installed Operators，再从下拉菜单中选择 openshift-template-service-broker 项目。
   2. 点击 Template Service Broker Operator。
   3. 选择 Template Service Broker 选项卡。
   4. 点击 template-service-broker。
   5. 在 Actions 下拉菜单中，选择 Delete Template Service Broker。

   6. 点击确认弹出窗口中的 Delete 按钮。

      Template Service Broker 现已卸载，稍后模板应用程序也会从 Developer Catalog 中移除。

2. 卸载 Template Service Broker Operator。

   1. 在 Operators → Installed Operators 页面中，滚动页面或在 Filter by name 中输入关键字以查找 Template Service Broker Operator，然后点击它。
   2. 在 Operator Details 页面的右侧，从 Actions 下拉菜单中选择 Uninstall Operator。
   3. 如果要删除所有安装相关组件，则在看到 Remove Operator Subscription 窗口提示时，勾选 Also completely remove the Operator from the selected namespace 复选框。该操作将删除 CSV，继而删除与 Operator 相关的 Pod、Deployment、CRD 和 CR。
   4. 选择 Remove。此 Operator 将停止运行，并且不再接收更新。集群中不再安装 Template Service Broker Operator。

1. 用户使用 OpenShift Container Platform Web 控制台从服务目录请求可用应用程序列表。
2. 服务目录从 OpenShift Ansible Broker 请求可用应用程序列表。
3. OpenShift Ansible Broker 与定义的容器镜像 registry 通信，以了解有哪些 APB 可用。
4. 用户发出置备特定 APB 的请求。
5. OpenShift Ansible Broker 通过调用 APB 上的置备方法来履行用户的置备请求。

1. 创建命名空间。

   1. 在 Web 控制台中导航至 Administration → Namespaces，再点击 Create Namespace。

   2. 在 Name 字段中输入 openshift-ansible-service-broker，在 Labels 字段中输入 openshift.io/cluster-monitoring=true，然后点击 Create。

      注意

      命名空间必须以 openshift- 开头。

2. 创建集群角色绑定。

   1. 导航到 Administration → Role Bindings，再点击 Create Binding。
   2. 对于 Binding Type，选择 Cluster-wide Role Binding (ClusterRoleBinding)。
   3. 对于 Role Binding，在 Name 字段中输入 ansible-service-broker。
   4. 对于 Role，选择 admin。
   5. 对于 Subject，选择 Service Account 选项，再选择 openshift-ansible-service-broker 命名空间，然后在 Subject Name 字段中输入 openshift-ansible-service-broker-operator。
   6. 点击 Create。

3. 创建用于连接 Red Hat Container Catalog 的 secret。

   1. 导航到 Workloads → Secrets。验证是否已选中 openshift-ansible-service-broker 项目。
   2. 点击 Create → Key/Value Secret。
   3. 输入 asb-registry-auth 作为 Secret Name。
   4. 添加名为 username 的 Key 和值为 Red Hat Container Catalog 用户名的 Value。
   5. 点击 Add Key/Value，再添加名为 password 的 Key 和值为 Red Hat Container Catalog 密码的 Value。
   6. 点击 Create。
4. 导航到 Operators → OperatorHub 页面。验证是否已选中 openshift-ansible-service-broker 项目。
5. 选择 OpenShift Ansible Service Broker Operator。
6. 阅读 Operator 的信息并点击 Install。
7. 检查默认选择并点击 Subscribe。

流程

1. 在 Web 控制台中导航到 Operators → Installed Operators，再选择 openshift-ansible-service-broker 项目。
2. 选择 OpenShift Ansible Service Broker Operator。
3. 在 Provided APIs 下，点击 Automation Broker 的 Create New。

4. 在提供的默认 YAML 里的 spec 字段中添加以下内容：

   registry:
     - name: rhcc
       type: rhcc
       url: https://registry.redhat.io
       auth_type: secret
       auth_name: asb-registry-auth

   这将引用安装 OpenShift Ansible Service Broker Operator 时创建的 secret，该 secret 允许您连接到 Red Hat Container Catalog。

5. 设置其他 OpenShift Ansible Broker 配置选项，再点击 Create。

6. 验证 OpenShift Ansible Broker 是否已启动。

   在 OpenShift Ansible Broker 启动后，您可以通过导航到 Catalog → Developer Catalog 并选中 Service Class 复选框来查看可用的服务捆绑包。请注意，可能需要等几分钟后 OpenShift Ansible Broker 才会启动，并且服务捆绑包可供使用。

   如果还没有看到这些服务类，您可以检查以下项目的状态：

   • OpenShift Ansible Broker Pod 状态

     • 在 openshift-ansible-service-broker 项目的 Workloads → Pods 页面中，验证名称开头为 asb- 的 Pod 的状态是否为 Running 并且就绪状态是否为 Ready。

   • 集群服务代理状态

     • 在 Catalog → Broker Management → Service Brokers 页面中，验证 ansible-service-broker 服务代理的状态是否为 Ready。

   • 服务目录控制器管理器 Pod 日志

     • 在 openshift-service-catalog-controller-manager 项目的 Workloads → Pods 页面中，检查各个 Pod 的日志，并验证是否看到一个含有 Successfully fetched catalog entries from broker 消息的日志条目。

1. 在 Web 控制台中导航到 Operators → Installed Operators，再选择 ansible-service-broker 项目。
2. 选择 OpenShift Ansible Service Broker Operator。
3. 在 Automation Broker 选项卡中，选择 ansible-service-broker。

4. 在 YAML 选项卡中，在 spec 字段中添加或更新所有 OpenShift Ansible Broker 配置选项。

   例如：

   spec:
     keepNamespace: true
     sandboxRole: edit

5. 点击 Save 以应用这些更改。

流程

1. 创建角色。

   1. 导航到 Administration → Roles，再点击 Create Role。

   2. 在编辑器中，用以下内容替换 YAML：

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: prometheus-k8s
        namespace: openshift-ansible-service-broker
      rules:
      - apiGroups:
        - ""
        resources:
        - services
        - endpoints
        - pods
        verbs:
        - get
        - list
        - watch

   3. 点击 Create。

2. 创建角色绑定。

   1. 导航到 Administration → Role Bindings，再点击 Create Binding。
   2. 对于 Binding Type，选择 Namespace Role Binding (RoleBinding)。
   3. 对于 Role Binding，在 Name 字段中输入 prometheus-k8s，并在 Namespace 字段中输入 openshift-ansible-service-broker。
   4. 对于 Role，选择 prometheus-k8s。
   5. 对于 Subject，选择 Service Account 选项，选择 openshift-monitoring 命名空间，然后在 Subject Name 字段中输入 prometheus-k8s。
   6. 点击 Create。

流程

1. 创建一个项目。

   1. 在 Web 控制台中，导航到 Home → Project 并点击 Create Project。
   2. 在 Name 字段中输入 test-postgresql-apb，再点击 Create。

2. 创建服务实例。

   1. 导航到 Catalog → Developer Catalog 页面。
   2. 选择 PostgreSQL (APB) 服务捆绑包，再点击 Create Service Instance。
   3. 检查默认选择项并设置任何其他必要的字段，然后点击 Create。

   4. 前往 Catalog → Provisioned Services，再验证 dh-postgresql-apb 服务实例是否已安装并具有 Ready 状态。

      您可以在 Home → Events 页面中查看进度。片刻之后，您应该会看到 dh-postgresql-apb 的一个事件，其含有“The instance was provisioned successfully”消息。

3. 创建服务绑定。

   1. 在 Provisioned Services 页面中，依次点击 dh-postgresql-apb 和 Create Service Binding。

   2. 检查默认服务绑定名称，再点击 Create。

      这会使用提供的名称为绑定创建一个新 secret。

4. 检查创建的 secret。

   1. 导航到 Workloads → Secrets，再验证是否创建了一个名为 dh-postgresql-apb 的 secret。
   2. 点击 dh-postgresql-apb，再查看 Data 部分中用于绑定到其他应用程序的键值对。

1. 卸载 OpenShift Ansible Broker。

   1. 导航到 Operators → Installed Operators，再从下拉菜单中选择 openshift-ansible-service-broker 项目。
   2. 点击 OpenShift Ansible Service Broker Operator。
   3. 选择 Automation Broker 选项卡。
   4. 点击 ansible-service-broker。
   5. 在 Actions 下拉菜单中，选择 Delete Automation Broker。

   6. 点击确认弹出窗口中的 Delete 按钮。

      OpenShift Ansible Broker 现已卸载，稍后服务捆绑包也会从 Developer Catalog 中移除。

2. 卸载 OpenShift Ansible Service Broker Operator。

   1. 在 Operators → Installed Operators 页面中，滚动页面或在 Filter by name 中输入关键字以查找 OpenShift Ansible Service Broker Operator，然后点击它。
   2. 在 Operator Details 页面的右侧，从 Actions 下拉菜单中选择 Uninstall Operator。
   3. 如果要删除所有安装相关组件，则在看到 Remove Operator Subscription 窗口提示时，勾选 Also completely remove the Operator from the selected namespace 复选框。该操作将删除 CSV，继而删除与 Operator 相关的 Pod、Deployment、CRD 和 CR。
   4. 选择 Remove。此 Operator 将停止运行，并且不再接收更新。

1. ReplicationController 定义的元素。
2. 自动创建新部署的触发器。
3. 在部署之间过渡的策略。
4. 生命周期 hook。

1. 执行任何 pre 生命周期 hook。
2. 根据激增数扩展新的 ReplicationController。
3. 根据最大不可用数，缩减旧的 ReplicationController。
4. 重复此扩展，直到新的 ReplicationController 达到所需的副本数，并且旧的 ReplicationController 已缩减到零。
5. 执行任何 post 生命周期 hook。

1. 执行任何 pre 生命周期 hook。
2. 将上一部署缩减到零。
3. 执行任何 mid 生命周期 hook。
4. 向上扩展新的部署。
5. 执行任何 post 生命周期 hook。

1. 在 Actions 下拉菜单中，选择 Edit Deployment Config 来查看应用程序的部署配置详情。
2. 在 YAML 编辑器中，将 spec.strategy.type 更改为 Recreate ，然后点 Save。
3. 在 Topology 视图中，选择节点即可看到侧面板中的 Overview 选项卡。Update Strategy 现在设为 Recreate。

4. 使用 Actions 下拉菜单选择 Start Rollout 以使用 Recreate 策略启动更新。Recreate 策略首先会终止旧版本应用程序的 Pod，然后为新版本启动 Pod。

   

流程

1. 在一个文件中定义配额。

2. 使用该文件创建配额，并将其应用到项目：

   $ oc create -f <file> [-n <project_name>]

   例如：

   $ oc create -f core-object-counts.yaml -n demoproject

流程

1. 获取项目中定义的配额列表。例如，对于名为 demoproject 的项目：

   $ oc get quota -n demoproject
   NAME                AGE
   besteffort          11m
   compute-resources   2m
   core-object-counts  29m

2. 描述您关注的配额，如 core-object-counts 配额：

   $ oc describe quota core-object-counts -n demoproject
   Name:			core-object-counts
   Namespace:		demoproject
   Resource		Used	Hard
   --------		----	----
   configmaps		3	10
   persistentvolumeclaims	0	4
   replicationcontrollers	3	20
   secrets			9	10
   services		2	10

流程

1. 在项目请求模板中添加资源配额定义：

   • 如果集群中不存在项目请求模板：

     1. 创建 bootstrap 项目模板并将其输出到名为 template.yaml 的文件：

        $ oc adm create-bootstrap-project-template -o yaml > template.yaml

     2. 在 template.yaml 中添加资源配额定义。以下示例定义了名为 'storage-consumption' 的资源配额。定义必须在模板的 parameter: 部分前添加：

        - apiVersion: v1
          kind: ResourceQuota
          metadata:
            name: storage-consumption
          spec:
            hard:
              persistentvolumeclaims: "10" 1
              requests.storage: "50Gi" 2
              gold.storageclass.storage.k8s.io/requests.storage: "10Gi" 3
              silver.storageclass.storage.k8s.io/requests.storage: "20Gi" 4
              silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5" 5
              bronze.storageclass.storage.k8s.io/requests.storage: "0" 6
              bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0" 7

        1

        项目中的持久性卷声明总数

        2

        在一个项目中的所有持久性卷声明中，请求的存储总和不能超过这个值。

        3

        在一个项目中的所有持久性卷声明中，金级存储类中请求的存储总和不能超过这个值。

        4

        在一个项目中的所有持久性卷声明中，银级存储类中请求的存储总和不能超过这个值。

        5

        在一个项目中的所有持久性卷声明中，银级存储类中声明总数不能超过这个值。

        6

        在一个项目中的所有持久性卷声明中，铜级存储类中请求的存储总和不能超过这个值。如果此值设为 0，则 bronze 存储类无法请求存储。

        7

        在一个项目中的所有持久性卷声明中，铜级存储类中请求的存储总和不能超过这个值。如果此值设为 0，则 bronze 存储类无法创建声明。

     3. 通过 openshift-config 命名空间中修改的 template.yaml 文件创建项目请求模板：

        $ oc create -f template.yaml -n openshift-config

        注意

        要将配置作为 kubectl.kubernetes.io/last-applied-configuration注解包括，将 --save-config 选项添加到 oc create 命令中。

        默认情况下，模板称为 project-request。

   • 如果项目请求模板已在集群中存在：

     注意

     如果您使用配置文件以声明性或必要方式管理集群中的对象，请使用这些文件编辑现有项目请求模板。

     1. 列出 openshift-config 命名空间中的模板：

        $ oc get templates -n openshift-config

     2. 编辑现有项目请求模板：

        $ oc edit template <project_request_template> -n openshift-config

     3. 将资源配额定义（如前面的 'storage-consumption' 示例）添加到现有模板中。定义必须在模板的 parameter: 部分前添加。

2. 如果您创建了项目请求模板，在集群的项目配置资源中引用它：

   1. 访问项目配置资源进行编辑：

      • 使用 web 控制台：

        1. 导航至 Administration → Cluster Settings 页面。
        2. 点击 Global Configuration，查看所有配置资源。
        3. 找到 Project 的条目，并点击 Edit YAML。

      • 使用 CLI：

        1. 编辑 project.config.openshift.io/cluster 资源：

           $ oc edit project.config.openshift.io/cluster

   2. 更新项目配置资源的 spec 部分，使其包含 projectRequestTemplate 和 name 参数。以下示例引用了默认项目请求模板（名称为 project-request）:

      apiVersion: config.openshift.io/v1
      kind: Project
      metadata:
        ...
      spec:
        projectRequestTemplate:
          name: project-request

3. 验证在创建项目时是否应用了资源配额：

   1. 创建一个项目：

      $ oc new-project <project_name>

   2. 列出项目的资源配额：

      $ oc get resourcequotas

   3. 详细描述资源配额：

      $ oc describe resourcequotas <resource_quota_name>

流程

1. 要根据注释选择项目，请运行以下命令：

   $ oc create clusterquota for-user \
        --project-annotation-selector openshift.io/requester=<user_name> \
        --hard pods=10 \
        --hard secrets=20

   这会创建以下 ClusterResourceQuota 对象：

   apiVersion: v1
   kind: ClusterResourceQuota
   metadata:
     name: for-user
   spec:
     quota: 1
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: 2
         openshift.io/requester: <user_name>
       labels: null 3
   status:
     namespaces: 4
     - namespace: ns-one
       status:
         hard:
           pods: "10"
           secrets: "20"
         used:
           pods: "1"
           secrets: "9"
     total: 5
       hard:
         pods: "10"
         secrets: "20"
       used:
         pods: "1"
         secrets: "9"

   1

   将对所选项目强制执行的 ResourceQuotaSpec 对象。

   2

   注解的简单键值选择器。

   3

   可用来选择项目的标签选择器。

   4

   描述每个所选项目中当前配额使用量的各命名空间映射。

   5

   所有选定项目的使用量合计。

   此多项目配额文档使用默认的项目请求端点控制 <user_name> 请求的所有项目。您需要有 10 个 Pod 和 20 个 secret 的限制。

2. 同样，若要根据标签选择项目，请运行以下命令：

   $  oc create clusterresourcequota for-name \ 1
       --project-label-selector=name=frontend \ 2
       --hard=pods=10 --hard=secrets=20

   1

   clusterresourcequota 和 clusterquota 是同一命令的别名。for-name 是 ClusterResourceQuota 对象的名称。

   2

   要根据标签选择项目，请使用 --project-label-selector=key=value 格式提供一个键值对。

   这会创建以下 ClusterResourceQuota 对象定义：

   apiVersion: v1
   kind: ClusterResourceQuota
   metadata:
     creationTimestamp: null
     name: for-name
   spec:
     quota:
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: null
       labels:
         matchLabels:
           name: frontend

流程

1. 要查看应用到某一项目的配额，请运行：

   $ oc describe AppliedClusterResourceQuota

   例如：

   Name:   for-user
   Namespace:  <none>
   Created:  19 hours ago
   Labels:   <none>
   Annotations:  <none>
   Label Selector: <null>
   AnnotationSelector: map[openshift.io/requester:<user-name>]
   Resource  Used  Hard
   --------  ----  ----
   pods        1     10
   secrets     9     20

流程

1. 要闲置一个服务，请运行：

   $ oc idle <service>

流程

1. 创建一个包含服务列表的文件，每个服务各自列于一行。

2. 使用 --resource-names-file 选项闲置这些服务：

   $ oc idle --resource-names-file <filename>

流程

1. 查看修剪操作要删除的对象：

   1. 最多保留三个标签修订，并且保留年龄不足 60 分钟的资源（镜像、镜像流和 Pod）：

      $ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m

   2. 修剪超过定义的限值的所有镜像：

      $ oc adm prune images --prune-over-size-limit

2. 使用上一步中的选项真正执行修剪操作：

   $ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m --confirm

   $ oc adm prune images --prune-over-size-limit --confirm

1. 建议的解决方案是保护 registry 的安全。否则，您需要强制客户端使用不安全连接，方法是在命令中附加 --force-insecure，但并不建议这样做。