构建应用程序

1. 在 Developer 视角中，进入到 Project 页面。
2. 从 Project 菜单中选择您的项目。
3. 选择 Project Access 选项卡。

4. 点 Add access 为默认权限添加新权限行。

   图 2.2. 项目权限

   
5. 输入用户名，点 Select a role 下拉列表，然后选择适当的角色。
6. 点击 Save 添加新权限。

流程

1. 在 Administrator 视角中，进入到 Administration → Cluster settings。
2. 点 Configuration 选项卡。
3. 从 Configuration resource 列表中，选择 Console operator.openshift.io。
4. 导航到 YAML 选项卡以查看和编辑 YAML 代码。

5. 在 spec 下的 YAML 代码中，自定义可用于项目访问的集群角色列表。以下示例指定了默认的 admin、edit 和 view 角色：

   apiVersion: operator.openshift.io/v1
   kind: Console
   metadata:
     name: cluster
   # ...
   spec:
     customization:
       projectAccess:
         availableClusterRoles:
         - admin
         - edit
         - view

6. 点 Save 将更改保存到 Console 配置资源。

验证

1. 在 Developer 视角中，进入到 Project 页面。
2. 从 Project 菜单中选择一个项目。
3. 选择 Project access 选项卡。
4. 点 Role 列中的菜单，并验证可用的角色是否与应用到 Console 资源配置的配置匹配。

流程

1. 在 Developer 视角中，进入 +Add 页面。
2. 从 Project 菜单中选择您的项目。
3. 点 +Add 页面上的项目，然后按照工作流操作。

流程

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. 单击 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. 单击 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 视图中，点 Samples 标题查看 Samples 页面。
2. 在 Samples 页面中，选择一个可用的示例应用程序来查看 Create Sample Application 表单。

3. 在 Create Sample Application Form 中：

   • 在 Name 字段中，部署名称会被默认显示。您可以根据需要修改此名称。
   • 在 Builder Image Version 中，会默认选择一个构建器镜像。您可以使用 Builder Image Version 下拉列表修改此镜像版本。
   • 默认添加 Git 存储库 URL 示例。
4. 点 Create 创建示例应用程序。示例应用程序的构建状态显示在 Topology 视图中。创建示例应用程序后，您可以看到添加到应用程序的部署。

流程

1. 在 +Add 视图中，点 Getting Started resources → Build with guided documentation → View all quick start 链接来查看 Quick Starts 页面。
2. 在 Quick Starts 页面中，点您要使用的快速启动的标题。
3. 点 Start 开始快速启动。
4. 执行显示的步骤。

流程

1. 在 +Add 视图中，点 Git Repository 标题中的 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. 可选：您可以通过 Git 存储库导入 Devfile、Dockerfile、构建器镜像或 Serverless 函数，以进一步自定义部署。

   • 如果您的 Git 存储库包含 Devfile、Dockerfile、构建器镜像 或 func.yaml，则会自动检测并填充到相应的路径字段中。
   • 如果同一存储库中检测到 Devfile、Dockerfile 或构建器镜像，则默认选择 Devfile。
   • 如果在 Git 存储库中检测到 func.yaml，Import Strategy 会更改为 Serverless Function。
   • 另外，您可以使用 Git 存储库 URL 在 +Add 视图中点 Create Serverless function 来创建无服务器函数。
   • 若要编辑文件导入类型并选择不同的策略，请单击 Edit import strategy 选项。
   • 如果检测到多个 Devfiles、Dockerfile 或构建器镜像，要导入一个特定的实例，请指定相对于上下文目录的对应路径。

5. 在验证 Git URL 后，会选择建议的构建器镜像并标记为星号。如果构建器镜像没有自动探测到，请选择一个构建器镜像。对于 https://github.com/sclorg/nodejs-ex Git URL，默认选择了 Node.js 构建器镜像。

   1. 可选： 使用 Builder Image Version 下拉菜单指定版本。
   2. 可选： 使用 Edit import 策略来选择不同的策略。
   3. 可选： 对于 Node.js 构建器镜像，请使用 Run command 字段覆盖运行应用程序的命令。

6. 在 General 部分中：

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

   2. 系统会基于 Git 存储库的 URL 自动填充 Name 字段，以标识为此应用程序创建的资源（如果没有存在的应用程序）。如果已有应用程序，可以选择将组件部署到现有应用程序中，创建一个新应用程序，或保持该组件没有被分配。

      注意

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

7. 在 Resources 部分，选择：

   • Deployment，以纯 Kubernetes 风格方式创建应用程序。
   • Deployment Config，创建 Red Hat OpenShift Service on AWS 风格的应用程序。

8. 在 Pipelines 部分，选择 Add Pipeline，然后点 Show Pipeline Visualization 来查看应用程序的管道。选择了默认管道，但您可以从应用程序的可用管道列表中选择所需的管道。

   注意

   选中 Add pipeline 复选框，如果满足以下条件，则默认选择 Configure PAC ：

   • 已安装 Pipeline operator
   • 启用了 Pipelines-as-code
   • 在 Git 存储库中检测到 .tekton 目录

9. 在您的存储库中添加 webhook。如果选择了 Configure PAC 并且设置了 GitHub 应用程序，您可以看到 Use GitHub App 和 Setup a webhook 选项。如果没有设置 GitHub App，则只能看到 Setup a webhook 选项：

   1. 进入 Settings → Webhooks 并点 Add webhook。
   2. 将 Payload URL 设置为 Pipelines as Code 的公共 URL。
   3. 将内容类型选为 application/json。
   4. 添加 webhook secret 并在另一个位置记录它。在本地机器上安装 openssl 后，生成一个随机 secret。
   5. 点 Let me select individual events 并选择这些事件：Commit comments, Issue comments, Pull request, 和 Pushes.
   6. 点击 Add webhook。

10. 可选： 在 Advanced Options 部分中，默认选择 Target port 和 Create a route to the application，以便您可以使用公开的 URL 访问应用程序。

    如果您的应用程序没有在默认公共端口（80）上公开其数据，请清除复选框，并设置您想要公开的目标端口号。

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

    路由

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

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

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

      注意

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

    健康检查

    点击 Health Checks 链接为您的应用程序添加就绪（Readiness）、存活（Liveness）和启动（Startup）探测。所有探测都预先填充默认数据; 您可以使用默认数据添加探测或根据需要进行自定义。

    自定义健康探测：

    • 点 Add Readiness Probe，在需要的情况下修改参数来检查容器是否准备好处理请求，然后选择要添加的探测。
    • 点 Add Liveness Probe，在需要的情况下修改参数来检查容器是否仍在运行，选择要添加的探测。

    • 点 Add Startup Probe，在需要的情况下修改参数来检查容器内的应用程序是否已启动，选择要添加的探测。

      对于每个探测，您可以从下拉列表中指定请求类型 - HTTP GET、Container Command 或 TCP Socket。表单会根据所选请求类型进行更改。然后您可以修改其它参数的默认值，如探测成功和失败的阈值、在容器启动后执行第一个探测前的秒数、探测的频率以及超时值。

    构建配置和部署

    点 Build Configuration 和 Deployment Configuration 链接来查看对应的配置选项。一些选项会被默认选中；您可以通过添加必要的触发器和环境变量来进一步自定义。

    对于无服务器应用程序，Deployment 选项不会显示，因为 Knative 配置资源为您的部署维护所需的状态，而不是由 DeploymentConfig 资源来维护。

    扩展

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

    如果要创建无服务器部署，也可以配置以下设置：

    • 最小 Pod 决定 Knative 服务在任意给定时间运行的 pod 数量较低限制。这也被称为 minScale 设置。
    • 最大 Pod 决定了 Knative 服务可在任意给定时间运行的 pod 数量上限。这也被称为 maxScale 设置。
    • 并发目标 决定了给定时间每个应用程序实例所需的并发请求数。
    • 并发限制 决定了给定时间允许每个应用程序的并发请求数的限值。
    • 并发利用率 决定了在 Knative 扩展额外 pod 前必须满足并发请求限制的百分比，以处理额外的流量。
    • 自动扩展窗口定义了平均时间窗口，以便在自动扩展器不处于 panic 模式时提供缩放决策的输入。如果在此窗口中没有收到任何请求，服务将缩减为零。autoscale 窗口的默认持续时间为 60s。这也被称为 stable 窗口。

    资源限值

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

    标签

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

12. 单击 Create 以创建应用程序，会显示一个成功通知。您可以在 Topology 视图中查看应用程序的构建状态。

流程

1. 在 +Add 视图中，点 Container images 查看 Deploy Images 页面。

2. 在 Image 部分：

   1. 选择 Image name from external registry 部署来自一个公共或私有 registry 的镜像，或者选择 Image stream tag from internal registry 部署来自内部 registry 的镜像。
   2. 在 Runtime icon 选项卡中为您的镜像选择一个图标。

3. 在 General 部分中：

   1. 在 Application name 字段中输入应用程序分组的唯一名称。
   2. 在 Name 字段中输入唯一名称，以标识为此组件创建的资源。

4. 在 Resource type 部分中，选择要生成的资源类型：

   1. 选择 Deployment 来为 Pod 和 ReplicaSet 对象启用声明性更新。
   2. 选择 DeploymentConfig 来为 Pod 对象定义模板，并管理部署新镜像和配置源。
5. 点 Create。您可以在 Topology 视图中查看应用程序的构建状态。

流程

1. 在 Topology 视图中，右键点任何位置来查看 Add to Project 菜单。
2. 将鼠标悬停在 Add to Project 菜单上，以查看菜单选项，然后选择 Upload JAR 文件选项以查看 Upload JAR 文件表单。或者，您可以将 JAR 文件拖到 Topology 视图中。
3. 在 JAR 文件字段中，浏览本地计算机上所需的 JAR 文件并上传该文件。或者，您可以将 JAR 文件拖到字段。如果将不兼容的文件类型拖到 Topology 视图中，则右上角会显示一个警报。如果上传表单的字段中丢弃了不兼容的文件类型，则会显示字段错误。
4. 默认选择运行时图标和构建器镜像。如果构建器镜像没有自动探测到，请选择一个构建器镜像。如果需要，您可以使用 Builder Image Version 下拉列表来更改版本。
5. 可选：在 Application Name 字段中输入应用程序的唯一名称，用于资源标记。
6. 在 Name 字段中输入相关资源的唯一组件名称。
7. 可选： 使用 Resource type 下拉列表更改资源类型。
8. 在 Advanced options 菜单中，点 Create a Route to the Application 配置您部署的应用程序的公共 URL。
9. 点 Create 以部署应用。显示有提示通知，以通知您 JAR 文件正在上传。相关通知还包括用于查看构建日志的链接。

流程

1. 进入 Developer 视角 → +Add → Developer Catalog → All Services。此时会显示 Developer Catalog 中所有可用服务的列表。
2. 在 Type 下，点 Devfiles 浏览支持特定语言或框架的 devfile。另外，您可以使用 keyword 过滤器使用其名称、标签或描述搜索特定 devfile。
3. 点击您要用来创建应用程序的 devfile。devfile 标题显示 devfile 的详情，包括 devfile 的名称、描述、供应商和 devfile 文档。
4. 点 Create 创建一个应用程序，并在 Topology 视图中查看应用程序。

流程

1. 在 Developer 视角中，导航到 +Add 视图，从 Developer Catalog 标题中点击 All Services 来查看 Developer Catalog 中的所有可用服务。
2. 在 All Services 下，选择服务类型或您需要添加到项目的组件。在本例中，选择 Databases 以列出所有数据库服务，然后点击 MariaDB 查看该服务的详情。

3. 点 Instantiate Template 查看带有 MariaDB 服务详情的自动填充的模板，然后点 Create 在 Topology 视图中创建并查看 MariaDB 服务的信息。

   图 3.1. Topology 中的 MariaDB

   

流程

1. 为此流程在 Red Hat OpenShift Service on AWS Web 控制台中创建一个新项目。这个示例使用名为 my-etcd 的项目。

2. 导航至 Operators → Installed Operators 页面。由 dedicated-admin 安装到集群且可供使用的 Operator 将以集群服务版本（CSV）列表形式显示在此处。CSV 用于启动和管理由 Operator 提供的软件。

   提示

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

   $ oc get csv

3. 在 Installed Operators 页面中，点 etcd Operator 查看更多详情和可用操作。

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

4. 新建 etcd 集群：

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

5. 点 example etcd 集群，然后点 Resources 选项卡，您可以看到项目现在包含很多由 Operator 自动创建和配置的资源。

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

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

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

1. 下载 Linux x86_64 或 Linux amd64 Helm 二进制文件，并将其添加到您的路径中：

   # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64 -o /usr/local/bin/helm

2. 使二进制文件可执行：

   # chmod +x /usr/local/bin/helm

3. 检查已安装的版本：

   $ helm version

   输出示例

   version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

1. 下载最新的 .exe 文件并放入您自己选择的目录 。
2. 右键点击 Start 并点击 Control Panel。
3. 选择 系统和安全性 ，然后点击 系统。
4. 在左侧的菜单中选择高级系统设置并点击底部的环境变量按钮。
5. 在变量部分选择路径并点编辑 。
6. 点新建并输入到 .exe 文件的路径，或者点击 浏览 并选择目录，然后点 确定。

1. 下载最新的 .exe 文件并放入您自己选择的目录 。
2. 点击 搜索 并输入 env 或者 environment。
3. 选择为您的帐户编辑环境变量。
4. 在变量部分选择路径并点编辑 。
5. 点新建并输入到 exe 文件所在目录的路径，或者点击 浏览 并选择目录，然后点击确定。

1. 下载 Helm 二进制文件并将其添加到您的路径中：

   # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-darwin-amd64 -o /usr/local/bin/helm

2. 使二进制文件可执行：

   # chmod +x /usr/local/bin/helm

3. 检查已安装的版本：

   $ helm version

   输出示例

   version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

1. 在 Developer 视角中，进入 +Add 视图并选择一个项目。然后点击 Helm Chart 选项来查看 Developer Catalog 中的所有 Helm Chart。
2. 选择一个 chart，查看它的描述信息、README 和其他与之相关的信息。

3. 点 Create。

   图 5.1. Developer Catalog 中的 Helm chart

   

4. 在 Create Helm Release 页面中：

   1. 在 Release Name 项中输入 release 的唯一名称。
   2. 从 Chart Version 下拉列表中选择所需的 chart 版本。

   3. 使用 Form View 或 YAML View 配置 Helm Chart。

      注意

      在可用情况下，您可以在 YAML View 和 Form View 间切换。在不同视图间切换时数据会被保留。

   4. 点 Create 来创建 Helm 发行版本。Web 控制台在 Topology 视图中显示新版本。

      如果 Helm Chart 带有发行注记，Web 控制台会显示它们。

      如果 Helm Chart 创建工作负载，Web 控制台会在 Topology 或 Helm 发行版本详情页中显示它们。工作负载为 DaemonSet, CronJob, Pod, Deployment, 和 DeploymentConfig。

   5. 在 Helm Releases 页面中查看新创建的 Helm 发行版本。

流程

1. 创建一个新项目

   $ oc new-project nodejs-ex-k

2. 下载包含 Red Hat OpenShift Service on AWS 对象的 Node.js chart 示例：

   $ git clone https://github.com/redhat-developer/redhat-helm-charts

3. 进入包含 chart 示例的目录：

   $ cd redhat-helm-charts/alpha/nodejs-ex-k/

4. 编辑 Chart.yaml 文件并添加 chart 描述：

   apiVersion: v2 1
   name: nodejs-ex-k 2
   description: A Helm chart for OpenShift 3
   icon: https://static.redhat.com/libs/redhat/brand-assets/latest/corp/logo.svg 4
   version: 0.2.1 5

   1

   Chart API 版本。对于至少需要 Helm 3 的 Helm Chart，它应该是 v2 。

   2

   chart 的名称。

   3

   chart 的描述。

   4

   用作图标的图形的 URL。

   5

   根据 Semantic Versioning(SemVer)2.0.0 规范，您的 chart 的版本。

5. 验证 chart 格式是否正确：

   $ helm lint

   输出示例

   [INFO] Chart.yaml: icon is recommended
   
   1 chart(s) linted, 0 chart(s) failed

6. 前往上一个目录级别：

   $ cd ..

7. 安装 chart：

   $ helm install nodejs-chart nodejs-ex-k

8. 验证 chart 是否已成功安装：

   $ helm list

   输出示例

   NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
   nodejs-chart nodejs-ex-k 1 2019-12-05 15:06:51.379134163 -0500 EST deployed nodejs-0.1.0  1.16.0

流程

1. 在 Developer 视角中，进入 +Add 视图并选择一个项目。
2. 在 Developer Catalog 标题中，选择 Helm Chart 选项来查看 Developer Catalog 中的所有 Helm chart。

3. 使用 Helm chart 列表左侧的过滤器过滤所需的 chart:

   • 使用 Chart Repositories 过滤器过滤由 Red Hat Certification Charts 或 OpenShift Helm Charts 提供的 chart。
   • 使用 Source 过滤器过滤来自 合作伙伴、 社区 或 红帽 的 chart。认证图表显示为( )图标。

流程

1. 在 Topology 视图中，选择 Helm 发行本来查看侧面面板。
2. 点 Actions → Upgrade Helm Release。
3. 在 Upgrade Helm Release 页面中，选择您要升级到的 Chart Version，然后点 Upgrade 以创建另一个 Helm 发行版本。Helm Releases 页面会显示两个修订版本。

1. 在 Developer 视角中，导航到 Helm 视图以查看命名空间中的 Helm Release 版本。
2. 点击列出的发行版本 旁边的 Options 菜单，然后选择 Rollback。
3. 在 Rollback Helm Release 页中，选择要回滚到的 Revision，点 Rollback。
4. 在 Helm Releases 页面中，点 chart 查看该发行版本的详情和资源。

5. 进入 Revision History 标签页来查看这个 chart 的所有修订版本。

   图 5.2. Helm 修改历史记录

   
6. 如果需要，您可以进一步使用一个特定修订版本旁的 Options 选项 并选择回滚到的修订版本。

流程

1. 在 Topology 视图中，右键点击 Helm 发行版本并选择 Delete Helm Release。
2. 在确认提示中，输入 chart 的名称并点 Delete。

流程

1. 从私钥和公共证书创建一个新的 TLS secret，其中 fullchain.pem 和 privkey.pem 是您的公共或私有通配符证书。

   示例

   $ oc create secret tls <name>-tls --cert=fullchain.pem --key=privkey.pem -n <my_project>

2. 创建新的 CustomDomain 自定义资源(CR)：

   示例 <company_name>-custom-domain.yaml

   apiVersion: managed.openshift.io/v1alpha1
   kind: CustomDomain
   metadata:
     name: <company_name>
   spec:
     domain: apps.<company_name>.io 1
     scope: External
     loadBalancerType: Classic 2
     certificate:
       name: <name>-tls 3
       namespace: <my_project>
     routeSelector: 4
       matchLabels:
        route: acme
     namespaceSelector: 5
       matchLabels:
        type: sharded

   1

   自定义域。

   2

   自定义域的负载均衡器的类型。如果您使用网络负载均衡器，此类型可以是默认的 classic 或 NLB。

   3

   上一步中创建的 secret。

   4

   可选：过滤由 CustomDomain ingress 提供服务的 Routes 组。如果没有提供值，则默认为没有过滤。

   5

   可选：过滤由 CustomDomain ingress 提供服务的 Namespaces 组。如果没有提供值，则默认为没有过滤。

3. 应用 CR：

   示例

   $ oc apply -f <company_name>-custom-domain.yaml

4. 获取新创建的 CR 的状态：

   $ oc get customdomains

   输出示例

   NAME               ENDPOINT                                                    DOMAIN                       STATUS
   <company_name>     xxrywp.<company_name>.cluster-01.opln.s1.openshiftapps.com  *.apps.<company_name>.io     Ready

5. 使用端点值，向受管 DNS 供应商（如 Route53）添加新的通配符 CNAME 记录。

   示例

   *.apps.<company_name>.io -> xxrywp.<company_name>.cluster-01.opln.s1.openshiftapps.com

6. 创建新应用并公开它：

   示例

   $ oc new-app --docker-image=docker.io/openshift/hello-openshift -n my-project

   $ oc create route <route_name> --service=hello-openshift hello-openshift-tls --hostname hello-openshift-tls-my-project.apps.<company_name>.io -n my-project

   $ oc get route -n my-project

   $ curl https://hello-openshift-tls-my-project.apps.<company_name>.io
   Hello OpenShift!

流程

1. 创建新 secret

   $ oc create secret tls <secret-new> --cert=fullchain.pem --key=privkey.pem -n <my_project>

2. Patch CustomDomain CR

   $ oc patch customdomain <company_name> --type='merge' -p '{"spec":{"certificate":{"name":"<secret-new>"}}}'

3. 删除旧的 secret

   $ oc delete secret <secret-old> -n <my_project>

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

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

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

流程

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    REQUEST                                                                                                      LIMIT
   besteffort                     4s     pods: 1/2
   compute-resources-time-bound   10m    pods: 0/2                                                                                                    limits.cpu: 0/1, limits.memory: 0/1Gi
   core-object-counts             109s   configmaps: 2/10, persistentvolumeclaims: 1/4, replicationcontrollers: 1/20, secrets: 9/10, services: 2/10

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
            namespace: ${PROJECT_NAME}
          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. 单击 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: quota.openshift.io/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: quota.openshift.io/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