|
dotnet
project.json
、
*.csproj
pom.xml
nodejs
app.json
、
package.json
cpanfile
、
index.pl
composer.json
、
index.php
python
requirements.txt
、
setup.py
Gemfile
、
Rakefile
、
config.ru
scala
build.sbt
golang
Godeps
、
main.go
检测了语言后，
new-app
会在 OpenShift Container Platform 服务器上搜索具有与所检测语言匹配的
suppors
注解的镜像流标签，或与所检测语言的名称匹配的镜像流。如果找不到匹配项，
new-app
会在
Docker Hub registry
中搜索名称上与所检测语言匹配的镜像。
您可以通过指定镜像（镜像流或容器规格）和存储库（以
~
作为分隔符），来覆盖构建器用于特定源存储库的镜像。请注意，如果进行这一操作，就不会执行构建策略检测和语言检测。
例如，使用
myproject/my-ruby
镜像流以及位于远程存储库中的源：
$ oc new-app myproject/my-ruby~https://github.com/openshift/ruby-hello-world.git
使用
openshift/ruby-20-centos7:latest
容器镜像流以及本地仓库中的源：
$ oc new-app openshift/ruby-20-centos7:latest~/home/user/code/my-ruby-app
语言检测需要在本地安装 Git 客户端，以便克隆并检查您的存储库。如果 Git 不可用，您可以使用
<image>～<repository>
语法指定要与存储库搭配使用的构建器镜像，以避免语言检测步骤。
调用
-i <image> <repository>
需要
new-app
尝试克隆
repository
，从而判断其工件类型；如果 Git 不可用，此操作会失败。
调用
-i <image> --code <repository>
需要
new-app
克隆
repository
，从而能判断
image
应用作源代码的构建器，还是另外部署（使用数据库镜像时）。
您可以从现有镜像部署应用程序。镜像可以来自 OpenShift Container Platform 服务器中的镜像流、特定 registry 中的镜像或本地 Docker 服务器中的镜像。
new-app
命令尝试确定传递给它的参数中指定的镜像类型。但是，您可以使用
--docker-image
参数明确告知
new-app
镜像是一个容器镜像，或使用
-i|--image-stream
参数明确告知镜像是一个镜像流。
如果指定本地 Docker 存储库中的镜像，必须确保同一镜像可供 OpenShift Container Platform 节点使用。
3.3.2.1. Docker Hub MySQL 镜像
从 Dockerhub MySQL 镜像创建应用程序，例如：
$ oc new-app mysql
3.3.2.2. 私有 registry 中的镜像
使用私有 registry 中的镜像创建应用程序时，请指定完整容器镜像规格：
$ oc new-app myregistry:5000/example/myimage
从现有镜像流和可选镜像流标签创建应用程序：
$ oc new-app my-stream:v1
您可以使用之前存储的模板或模板文件创建应用程序，方法是将模板名称指定为参数。例如，您可以存储一个示例应用程序模板，并使用它来创建应用程序。
将应用程序模板上传到当前项目的模板库。以下示例从名为
example/sample-app/application-template-stibuild.json
的文件上传一个应用程序模板：
$ oc create -f examples/sample-app/application-template-stibuild.json
然后，通过引用应用程序模板来创建新应用程序。在本例中，模板名称为
ruby-helloworld-sample
:
$ oc new-app ruby-helloworld-sample
要通过引用本地文件系统中的模板文件创建新应用程序，而无需首先将其保存到 OpenShift Container Platform 中，使用
-f|--file
参数。例如：
$ oc new-app -f examples/sample-app/application-template-stibuild.json
在基于模板创建应用程序时，请使用
-p|--param
参数来设置模板定义的参数值：
$ oc new-app ruby-helloworld-sample \
-p ADMIN_USERNAME=admin -p ADMIN_PASSWORD=mypassword
您可以将参数保存到文件中，然后在实例化模板时通过
--param-file
来使用该文件。如果要从标准输入中读取参数，请使用
--param-file=-
。以下是一个名为
helloworld.params
的示例文件：
ADMIN_USERNAME=admin
ADMIN_PASSWORD=mypassword
在实例化模板时引用文件中的参数：
$ oc new-app ruby-helloworld-sample --param-file=helloworld.params
new-app
命令生成用于构建、部署和运行所创建应用程序的 OpenShift Container Platform 对象。通常情况下，这些对象是在当前项目中创建的，并分配有从输入源存储库或输入镜像中获得的名称。但是，您可以使用
new-app
修改这种行为。
表 3.2. new-app 输出对象
|
对象
|
描述
|
|
BuildConfig
为命令行中指定的每个源存储库创建一个
BuildConfig
对象。
BuildConfig
对象指定要使用的策略、源位置和构建输出位置。
ImageStreams
对于
BuildConfig
对象，通常会创建两个镜像流。其一代表输入镜像。进行源构建时，这是构建器镜像。进行
Docker
构建时，这是
FROM
镜像。其二代表输出镜像。如果容器镜像指定为
new-app
的输入，那么也会为该镜像创建镜像流。
DeploymentConfig
创建一个
DeploymentConfig
对象来部署构建的输出或指定的镜像。
new-app
命令为生成的
DeploymentConfig
对象中包含的容器中指定的所有 Docker 卷创建
emptyDir
卷。
Service
new-app
命令会尝试检测输入镜像中公开的端口。它使用编号最小的已公开端口来生成公开该端口的服务。要公开一个不同的端口，只需在
new-app
完成后使用
oc expose
命令生成额外服务。
根据模板，可在实例化模板时生成其他对象。
|
从模板、源或镜像生成应用程序时，您可以在运行时使用
-e|--env
参数将环境变量传递给应用程序容器：
$ oc new-app openshift/postgresql-92-centos7 \
-e POSTGRESQL_USER=user \
-e POSTGRESQL_DATABASE=db \
-e POSTGRESQL_PASSWORD=password
这些变量可使用
--env-file
参数从文件中读取。以下是一个名为
postgresql.env
的示例文件：
POSTGRESQL_USER=user
POSTGRESQL_DATABASE=db
POSTGRESQL_PASSWORD=password
从文件中读取变量：
$ oc new-app openshift/postgresql-92-centos7 --env-file=postgresql.env
另外，也可使用
--env-file=-
在标准输入上给定环境变量：
$ cat postgresql.env | oc new-app openshift/postgresql-92-centos7 --env-file=-
在
new-app
处理过程中创建的任何
BuildConfig
对象，都不能使用通过
-e|--env
或
--env-file
参数传递的环境变量进行更新。
从模板、源或镜像生成应用程序时，您可以在运行时使用
--build-env
参数将环境变量传递给构建容器：
$ oc new-app openshift/ruby-23-centos7 \
--build-env HTTP_PROXY=http://myproxy.net:1337/ \
--build-env GEM_HOME=~/.gem
这些变量可使用
--build-env-file
参数从文件中读取。以下是一个名为
ruby.env
的示例文件：
HTTP_PROXY=http://myproxy.net:1337/
GEM_HOME=~/.gem
从文件中读取变量：
$ oc new-app openshift/ruby-23-centos7 --build-env-file=ruby.env
另外，也可使用
--build-env-file=-
在标准输入上给定环境变量：
$ cat ruby.env | oc new-app openshift/ruby-23-centos7 --build-env-file=-
从源、镜像或模板生成应用程序时，您可以使用
-l|--label
参数为创建的对象添加标签。借助标签，您可以轻松地集中选择、配置和删除与应用程序关联的对象。
$ oc new-app https://github.com/openshift/ruby-hello-world -l name=hello-world
要查看运行
new-app
命令的空运行，您可以使用
-o|--output
参数及
yaml
或
json
值。然后，您可以使用输出结果预览创建的对象，或将其重定向到可以编辑的文件。满意之后，您可以使用
oc create
创建 OpenShift Container Platform 对象。
要将
new-app
工件输出到一个文件，请运行以下命令：
$ oc new-app https://github.com/openshift/ruby-hello-world \
-o yaml > myapp.yaml
编辑该文件：
$ vi myapp.yaml
通过引用该文件来创建新应用程序：
$ oc create -f myapp.yaml
new-app
创建的对象通常命名自用于生成它们的源存储库或镜像。您可以通过在命令中添加
--name
标志来设置生成的对象名称：
$ oc new-app https://github.com/openshift/ruby-hello-world --name=myapp
通常，
new-app
会在当前项目中创建对象。不过，您可以使用
-n|--namespace
参数在另一项目中创建对象：
$ oc new-app https://github.com/openshift/ruby-hello-world -n myproject
new-app
命令允许创建多个应用程序，为
new-app
指定多个参数便可实现。命令行中指定的标签将应用到单一命令创建的所有对象。环境变量应用到从源或镜像创建的所有组件。
从源存储库和 Docker Hub 镜像创建应用程序：
$ oc new-app https://github.com/openshift/ruby-hello-world mysql
如果以独立参数形式指定源代码存储库和构建器镜像，
new-app
会将构建器镜像用作源代码存储库的构建器。如果这不是您的用意，请使用
~
分隔符为源指定所需的构建器镜像。
3.3.4.8. 在单个 pod 中对镜像和源进行分组
new-app
命令允许在一个 pod 中一起部署多个镜像。要指定要将哪些镜像分组在一起，使用
+
分隔符。也可使用
--group
命令行参数来指定应分组在一起的镜像。要将源存储库中构建的镜像与其他镜像一起分组，请在组中指定其构建器镜像：
$ oc new-app ruby+mysql
将通过源构建的镜像和外部镜像一起部署：
$ oc new-app \
ruby~https://github.com/openshift/ruby-hello-world \
mysql \
--group=ruby+mysql
第 4 章 使用 Topology 视图查看应用程序组成情况
Web 控制台的
Developer
视角中有一个
Topology
视图，它以可视化方式展示项目中的所有应用程序、它们的构建状态，以及关联的组件和服务。
您可以使用
Developer
视角中的左侧导航面板进入
Topology
视图。部署应用程序后，您会自动定向到
Graph view
，从中可查看应用程序 pod 状态，快速访问公共 URL 上的应用程序，访问源代码以进行修改，以及查看上一次构建的状态。您可以缩放视图来查看特定应用程序的更多详情。
Topology
视图也为您提供了使用
List
视图监控应用程序的选项。使用
List 视图
图标
查看所有应用程序的列表，并使用
图形视图
图标 (
) 切回到图形视图。
您可以使用以下命令自定义视图：
使用
Find by name
字段查找所需组件。搜索结果可能会出现在可见区域之外 ; 点击左侧工具栏中的
Fit to Screen
来改变
Topology
视图的大小来显示所有组件。
使用
Display Options
下拉列表配置各种应用程序的
Topology
视图。这些选项取决于项目中部署的组件的类型：
模式
（
Connectivity
或
Consumption
）
连接 ：选择以显示拓扑中不同节点之间的所有连接。
消耗：显示拓扑中所有节点的资源消耗。
虚拟机：切换到显示或隐藏虚拟机。
应用程序分组：通过概述应用程序组和与其关联的警报，将应用程序组压缩到卡中。
Helm 发行版本：清除用于将部署为 Helm Release 的组件整合到卡中，并概述给定发行版本。
Knative Services:清除用于将 Knative Service 组件压缩到带有给定组件概述的卡中。
Operator 组：清除用于将 Operator 部署的组件整合到卡中，并包含给定组的概述。
Show
项基于
Pod Count
或
Labels
Pod 数量：选择以显示组件图标中组件的 pod 数量。
标签：切换到显示或隐藏组件标签。
Web 控制台的
Developer
视角中的
Topology
视图提供了如下可与应用程序和组件进行交互的选项：
点
Open URL(
)查看通过公共 URL 上的路由公开的应用程序。
点击
Edit Source code
可访问您的源代码并进行修改。
只有使用
From Git
、
From Catalog
和
From Dockerfile
选项创建了应用程序时，此功能才可用。
光标悬停在 Pod 左下方图标上，可查看最新构建的名称及其状态。应用程序构建的状态显示为
New
(
)、
Pending
(
)、
Running
(
)、
Complemented
(
)、
Failed
(
)和
Canceled(
pod 的状态或阶段由不同的颜色和工具提示来表示：
Running
(
)：pod 绑定到某个节点，并创建所有容器。至少一个容器仍在运行，或正在启动或重启过程中。
Not Ready
(
):运行多个容器的 pod，不是所有容器都已就绪。
)：pod 中的容器被终止，但终止不成功。有些容器可能是其他状态。
)：pod 中的所有容器都终止，但至少一个容器出现故障而终止。也代表，容器以非零状态退出，或者被系统终止。
)：Kubernetes 集群接受 pod，但一个或多个容器尚未设置并准备好运行。这包括 pod 等待调度的时间，以及通过网络下载容器镜像的时间。
Succeeded
(
)：pod 中的所有容器都成功终止，且不会重启。
)：当 pod 被删除时，一些 kubectl 命令会显示
Terminating
。
Terminating
状态不是 pod 的一个阶段。一个 pod 会被赋予一个安全终止期，默认为 30 秒。
unknown
(
)：无法获取 pod 的状态。此阶段通常是由于与 pod 应该运行的节点通信时出错造成的。
创建应用程序并部署镜像后，其状态会显示为
Pending
。构建应用程序后，它会显示为
Running
。
应用程序资源名称附有代表不同类型资源对象的指示符，如下所示：
CJ
:
CronJob
D
：
Deployment
DC
：
DeploymentConfig
DS
：
DaemonSet
J
:
作业
P
:
Pod
SS
：
StatefulSet
(Knative)：无服务器应用程序
无服务器应用程序需要一些时间才能加载并显示在
Graph 视图
中。部署无服务器应用程序时，首先会创建一个服务资源，然后创建一个修订。之后，它会被部署并显示在
Graph 视图
中。如果它是唯一的工作负载，可能会重定向到
Add
页面。部署修订后，无服务器应用程序会显示在
Graph 视图
中。
您还可以使用上下文菜单，点拓扑
Graph view
将服务（如
Import from Git
,
Container Image
,
Database
,
From Catalog
,
Operator Backed
,
Helm Charts
,
Samples
, 或
Upload JAR file
）添加到您的项目。
4.4. 扩展应用程序 Pod 以及检查构建和路由
Topology
视图在
Overview
面板中提供所部署组件的详情。您可以使用
Overview
和
Resources
选项卡来缩放应用程序 pod，以及检查构建状态、服务和路由等，如下所示：
点击组件节点，以查看右侧的
Overview
面板。使用
Overview
选项卡可以：
使用向上和向下箭头缩放 pod，手动增加或减少应用程序的实例数。对于无服务器应用程序，pod 数在空闲时会自动缩减为零，而且能根据频道流量扩展。
检查应用程序的
Labels
、
Annotations
和
Status
。
点击
Resources
选项卡可以：
查看所有 pod 列表，查看其状态，访问日志，还能点击 pod 来查看 pod 详情。
查看构建及其状态，访问日志，并在需要时启动新的构建。
查看组件所使用的服务和路由。
对于无服务器应用程序，
Resources
选项卡提供用于该组件的版本、路由和配置的有关信息。
流程
-
点击左侧导航窗格旁的
Add to Project
(
)或按
Ctrl
+
Space
搜索组件并选择
Create
或按
Enter
将组件添加到项目中，并在拓扑
Graph 视图中
查看它。
另外，您还可以通过右键单击拓扑
Graph 视图
中的上下文菜单中使用
Import from Git
、
Container Image
、
Database
、
From Catalog
、
Operator Backed
、
Helm Charts
、
Samples
或
Upload JAR file
选项来为您的项目添加组件。
您可以使用
+Add
视图在项目中添加多个组件或服务，并使用拓扑
图形视图
对应用程序组中的应用程序和资源进行分组。
您已使用
Developer 视角
在 OpenShift Container Platform 上创建并部署了最少两个或多个组件。
要将服务添加到现有应用程序组中，请按
Shift
+ 将它拖动到现有应用程序组中。拖动组件并将其添加到应用程序组中时，会将所需的标签添加到组件。
另外，您还可以在应用程序中添加组件，如下所示：
点服务 pod 查看右侧的
Overview
面板。
单击
Actions
下拉菜单，再选择
Edit Application Grouping
。
在
Edit Application Grouping
对话框中，单击
Application
下拉列表，然后选择适当的应用程序组。
单击
Save
，将服务添加到应用组中。
要从应用程序组中删除组件，您可以选择组件并使用
Shift
+ 拖动操作将组件从应用程序组中拖出。
要在应用程序中添加服务，请使用使用拓扑
图形视图中
的上下文菜单的
+Add
操作。
除了上下文菜单外，您还可以使用边栏添加服务，或者将鼠标悬停在应用程序组中并拖动悬挂的箭头。
右键单击拓扑
图形视图
中的应用程序组，以显示上下文菜单。
使用
Add to Application
选择将服务添加到应用程序组中的方法，如
From Git
、
Container Image
、
From Dockerfile
、
From Devfile
、
Upload JAR 文件
、
Event Source
、
Channel
或
Broker
。
完成您选择的方法的表单，再单击
Create
。例如，若要根据 Git 存储库中的源代码添加服务，请选择
From Git
方法，填写
Import from Git
表单，然后单击
Create
。
在拓扑
图形视图
中，使用上下文菜单从应用程序中删除服务。
在拓扑
图形视图
中的应用程序组中右键单击应用程序组中的服务，以显示上下文菜单。
选择
Delete Deployment
以删除服务。
除了对一个应用程序中的多个组件进行分组外，还可以使用
Topology
视图来相互连接组件。您可以使用绑定连接器或视觉连接器来连接组件。
只有当目标节点是 Operator 支持的服务时，才可以在组件之间建立绑定连接。为了表示这种情况，当您将箭头拖到这样的目标节点上时，会出现
Create a binding connector
工具提示。当应用程序使用绑定连接器连接到服务时，会创建服务绑定请求。然后，Service Binding Operator 控制器使用一个中间的 secret 将所需的绑定数据注入应用程序部署中作为环境变量。请求成功后，会重新部署应用程序以在连接的组件间建立交互。
视觉连接器只在组件之间建立视觉连接，描述连接意图。没有建立组件之间的交互。如果目标节点不是一个 Operator 支持的服务，当您将箭头拖到目标节点上时，将会显示
Create a visual connector
工具提示。
您可以使用可视连接器来描述连接应用程序组件的意图。
此流程介绍了在 MongoDB 服务与 Node.js 应用程序间创建可视连接的示例。
确保您已使用
Developer
视角创建并部署了 Node.js 应用程序。
确保已使用
Developer
视角创建并部署了 MongoDB 服务。
光标悬停到 MongoDB 服务上，节点上出现悬浮的箭头。
点击箭头并将它拖向 Node.js 组件，使它与 MongoDB 服务连接。
点击 MongoDB 服务以查看
Overview
面板。在
Annotations
部分，点编辑图标，查看
Key =
app.openshift.io/connects-to
和
Value =
[{"apiVersion":"apps.openshift.io/v1", "kind":"DeploymentConfig","name":"nodejs-ex"}]
注解被添加到该服务。
同样，您可以创建其他应用程序和组件，并在它们之间建立连接。
服务绑定只是一个技术预览功能。红帽产品服务等级协议 (SLA) 不支持技术预览功能，且可能无法完成。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的详情，请参阅
https://access.redhat.com/support/offerings/techpreview/
。
目前，只有几个特定的 Operator（如
etcd
和
PostgresSQL Database
）的 Operator 服务实例可以绑定。
您可以与 Operator 支持的组件建立绑定连接。
此流程介绍了在 PostgreSQL 数据库服务和 Node.js 应用程序间创建绑定连接的示例。要创建与 PostgreSQL Database Operator 支持的服务的绑定连接，必须首先使用
CatalogSource
资源将红帽提供的 PostgreSQL Database Operator 添加到
OperatorHub
，然后安装 Operator。然后，PostSQL Database Operator 会创建和管理
Database
资源，这会在 secret、配置映射、状态和 spec 属性中公开绑定信息。
确保您已使用
Developer
视角创建并部署了 Node.js 应用程序。
确保您已从 OperatorHub 安装了
Service Binding Operator
。
创建一个
CatalogSource
资源，将红帽提供的 PostgresSQL Database Operator 添加到
OperatorHub
。
在
+Add
视图中，点
YAML
选项查看
Import YAML
屏幕。
添加以下 YAML 文件以应用
CatalogSource
资源：
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
name: sample-db-operators
namespace: openshift-marketplace
spec:
sourceType: grpc
image: quay.io/redhat-developer/sample-db-operators-olm:v1
displayName: Sample DB OLM registry
updateStrategy:
registryPoll:
interval: 30m
点击
Create
在集群中创建
CatalogSource
资源。
安装红帽提供的
PostgreSQL Database
Operator:
在控制台的
Administrator
视角中，进入
Operators → OperatorHub
。
在
Database
类别中，选择
PostgreSQL Database
Operator 并安装它。
为应用程序创建数据库 (DB) 实例：
切换到
Developer
视角，并确保您处于适当的项目中，例如
test-project
。
在
+Add
视图中，点
YAML
选项查看
Import YAML
屏幕。
在编辑器中添加服务实例 YAML，并点击
Create
部署该服务。服务 YAML 将如以下示例所示：
apiVersion: postgresql.baiju.dev/v1alpha1
kind: Database
metadata:
name: db-demo
spec:
image: docker.io/postgres
imageName: postgres
dbName: db-demo
DB 实例现在部署在
Topology
视图中。
在
Topology
视图中，将鼠标悬停在 Node.js 组件上可看到节点上悬浮的箭头。
点击箭头并拖向
db-demo-postgresql
服务，以便与 Node.js 应用程序进行绑定连接。服务绑定请求被创建，
Service Binding Operator
控制器会将 DB 连接信息作为环境变量注入应用程序部署中。请求成功后，会重新部署应用程序并建立连接。
您还可以通过拖动悬挂箭头以添加和创建与 Operator 支持的服务的绑定连接来使用上下文菜单。
4.10. 用于 Topology 视图的标签和注解
Topology
使用下列标签和注解：
-
节点中显示的图标
-
节点中的图标是通过使用
app.openshift.io/runtime
标签（随后是
app.kubernetes.io/name
标签）查找匹配图标来定义的。这种匹配是通过预定义的图标集合来完成的。
-
到源代码编辑器或源的链接
-
app.openshift.io/vcs-uri
注解用于创建源代码编辑器的链接。
-
节点连接器
-
app.openshift.io/connects-to
注解用于连接节点。
-
应用程序分组
-
app.kubernetes.io/part-of=<appname>
标签用于对应用程序、服务和组件进行分组。
如需了解 OpenShift Container Platform 应用程序必须使用的标签和注解，请参阅
OpenShift 应用程序的标签和注解指南
。
Helm 是一个软件包管理程序，它简化了应用程序和服务部署到 OpenShift Container Platform 集群的过程。
Helm 使用名为
charts
的打包格式。Helm chart 是描述 OpenShift Container Platform 资源的一个文件集合。
在集群中运行的一个 chart 实例被称为
release
。当每次一个 chart 在集群中安装时，一个新的 release 会被创建。
在每次安装 chart，或一个版本被升级或回滚时，都会创建增量修订版本。
Helm 提供以下功能：
搜索存储在 chart 存储库中的一个大型 chart 集合。
修改现有 chart。
使用 OpenShift Container Platform 或 Kubernetes 资源创建自己的 chart。
将应用程序打包为 chart 并共享。
5.1.2. 红帽 OpenShift Helm chart 认证
您可以选择由红帽为要在 Red Hat OpenShift Container Platform 上部署的所有组件验证并认证 Helm chart。图表采用自动化红帽 OpenShift 认证工作流，确保安全合规，以及与平台的最佳集成和经验。认证可确保 chart 的完整性，并确保 Helm Chart 在 Red Hat OpenShift 集群上无缝工作。
下面的部分论述了如何使用 CLI 在不同的平台中安装 Helm。
在 OpenShift Container Platform web 控制台中，点右上角的
?
图标并选
Command Line Tools
。
已安装了 Go 版本 1.13 或更高版本。
-
下载 Helm 二进制文件并将其添加到您的路径中：
# curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64 -o /usr/local/bin/helm
-
使二进制文件可执行：
# chmod +x /usr/local/bin/helm
-
检查已安装的版本：
$ helm version
-
下载最新的
.exe
文件
并放入您自己选择的目录 。
右键点击
Start
并点击
Control Panel
。
选择
系统和安全性
，然后点击
系统
。
在左侧的菜单中选择
高级系统设置
并点击底部的
环境变量
按钮。
在
变量
部分选择
路径
并点
编辑
。
点
新建
并输入到
.exe
文件的路径，或者点击
浏览
并选择目录，然后点
确定
。
-
下载最新的
.exe
文件
并放入您自己选择的目录 。
点击
搜索
并输入
env
或者
environment
。
选择
为您的帐户编辑环境变量
。
在
变量
部分选择
路径
并点
编辑
。
点
新建
并输入到 exe 文件所在目录的路径，或者点击
浏览
并选择目录，然后点击
确定
。
-
下载 Helm 二进制文件并将其添加到您的路径中：
# curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-darwin-amd64 -o /usr/local/bin/helm
-
使二进制文件可执行：
# chmod +x /usr/local/bin/helm
-
检查已安装的版本：
$ helm version
您可以使用以下方法在 OpenShift Container Platform 集群上安装 Helm chart：
Web 控制台的
Developer
视角。
在 web 控制台的
Developer
视角中，
Developer Catalog
显示集群中可用的 Helm chart。默认情况下，它会从 Red Hat OpenShift Helm Chart 仓库中列出 Helm chart。如需 chart 列表，请参阅
Red Hat
Helm index
文件
。
作为集群管理员，您可以添加多个 Helm Chart 仓库（默认仓库除外），并在
Developer Catalog
中显示这些仓库中的 Helm chart。
5.3.1. 在 OpenShift Container Platform 集群中安装 Helm chart
先决条件
-
您有一个正在运行的 OpenShift Container Platform 集群，并已登录该集群。
您已安装 Helm。
创建一个新项目：
$ oc new-project mysql
-
将一个 Helm chart 存储库添加到本地 Helm 客户端：
$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/
-
安装示例 MySQL chart：
$ helm install example-mysql stable/mysql
-
验证 chart 是否已成功安装：
$ helm list
5.3.2. 使用 Developer 视角安装 Helm chart
您可以使用 web 控制台中的
Developer
视角或 CLI 从
Developer Catalog
中列出的 Helm chart 中选择并安装 chart。您可以通过安装 Helm chart 来创建 Helm 发行版本，并在 web 控制台的
Developer
视角中查看它们。
已登陆到 web 控制台并切换到
Developer
视角
。
通过
Developer Catalog
提供的 Helm chart 来创建 Helm 发行版本：
在
Developer
视角中，进入
+Add
视图并选择一个项目。然后点击
Helm Chart
选项来查看
Developer Catalog
中的所有 Helm Chart。
选择一个 chart，查看它的描述信息、README 和其他与之相关的信息。
点
Install Helm Chart
。
在
Install Helm Chart
页面中：
在
Release Name
项中输入 release 的唯一名称。
从
Chart Version
下拉列表中选择所需的 chart 版本。
使用
Form View
或
YAML View
配置 Helm Chart。
在可用情况下，您可以在
YAML View
和
Form View
间切换。在不同视图间切换时数据会被保留。
点击
Install
创建 Helm release。
Topology
视图将会显示，其中包括了发行版本。如果 Helm chart 带有发行注记，则 chart 会被预先选择，右侧面板会显示该发行版本的发行注记。
您可以使用侧面面板上的
Actions
按钮或右键点击 Helm 发行版本来升级、回滚或卸载 Helm 发行版本。
您可以通过在 web 控制台的
Developer
视角中初始化 web 终端来使用 Helm。如需更多信息，请参阅
使用 Web 终端
。
5.3.4. 在 OpenShift Container Platform 上创建自定义 Helm chart
流程
-
创建一个新项目：
$ oc new-project nodejs-ex-k
-
下载包含 OpenShift Container Platform 对象的示例 Node.js chart：
$ git clone https://github.com/redhat-developer/redhat-helm-charts
-
进入包含 chart 示例的目录：
$ cd redhat-helm-charts/alpha/nodejs-ex-k/
-
编辑
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
-
1
-
Chart API 版本。对于至少需要 Helm 3 的 Helm Chart，它应该是
v2
。
chart 的名称。
chart 的描述。
用作图标的图形的 URL。
验证 chart 格式是否正确：
$ helm lint
-
安装 chart：
$ helm install nodejs-chart nodejs-ex-k
-
验证 chart 是否已成功安装：
$ helm list
5.3.5. 添加自定义 Helm Chart 仓库
作为集群管理员，您可以将自定义 Helm Chart 存储库添加到集群中，并在
Developer Catalog
中启用从这些仓库中获得 Helm chart 的访问权限。
要添加新的 Helm Chart 仓库，您必须将 Helm Chart 仓库自定义资源（CR）添加到集群中。
5.3.6. 创建凭证和 CA 证书以添加 Helm Chart 仓库
有些 Helm Chart 仓库需要凭证和自定义证书颁发机构（CA）证书才能与其连接。您可以使用 Web 控制台和 CLI 添加凭证和证书。
配置凭证和证书，然后使用 CLI 添加 Helm Chart 仓库：
在
openshift-config
命名空间中，使用 PEM 编码格式的自定义 CA 证书创建一个
configmap
，并将它存储在配置映射中的
ca-bundle.crt
键下：
$ oc create configmap helm-ca-cert \
--from-file=ca-bundle.crt=/path/to/certs/ca.crt \
-n openshift-config
在
openshift-config
命名空间中，创建一个
Secret
对象来添加客户端 TLS 配置：
$ oc create secret tls helm-tls-configs \
--cert=/path/to/certs/client.crt \
--key=/path/to/certs/client.key \
-n openshift-config
请注意：客户端证书和密钥必须采用 PEM 编码格式，并分别保存在
tls.crt
和
tls.key
密钥中。
按如下所示添加 Helm 仓库：
$ cat <<EOF | oc apply -f -
apiVersion: helm.openshift.io/v1beta1
kind: HelmChartRepository
metadata:
name: <helm-repository>
spec:
name: <helm-repository>
connectionConfig:
url: <URL for the Helm repository>
tlsConfig:
name: helm-tls-configs
name: helm-ca-cert
ConfigMap 和 Secret 使用 tlsConfig 和 ca 字段在 HelmChartRepository CR 中消耗。这些证书用于连接 Helm 仓库 URL。
默认情况下，所有经过身份验证的用户都可以访问所有配置的 chart。但是，对于需要证书的 Chart 仓库，您必须为用户提供对 openshift-config 命名空间中 helm-ca-cert 配置映射和 helm-tls-configs secret 的读取访问权限，如下所示：
$ cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: openshift-config
name: helm-chartrepos-tls-conf-viewer
rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["helm-ca-cert"]
verbs: ["get"]
- apiGroups: [""]
resources: ["secrets"]
resourceNames: ["helm-tls-configs"]
verbs: ["get"]
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: openshift-config
name: helm-chartrepos-tls-conf-viewer
subjects:
- kind: Group
apiGroup: rbac.authorization.k8s.io
name: 'system:authenticated'
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: helm-chartrepos-tls-conf-viewer
EOF
5.3.7. 根据它们的认证级别过滤 Helm Chart
您可以在
Developer Catalog
中根据它们的认证级别过滤 Helm chart。
在
Developer
视角中，进入
+Add
视图并选择一个项目。
在
Developer Catalog
标题中，选择
Helm Chart
选项来查看
Developer Catalog
中的所有 Helm chart。
使用 Helm chart 列表左侧的过滤器过滤所需的 chart:
使用
Chart Repositories
过滤器过滤由
Red Hat Certification Charts
或
OpenShift Helm Charts
提供的 chart。
使用
Source
过滤器过滤来自
合作伙伴、
社区
或
红帽
的 chart。认证图表显示为(
如果只有一个供应商类型，则
Source
过滤器不可见。
现在，您可以选择所需的 chart 并安装它。
您可以通过将
HelmChartRepository
自定义资源中的
disabled
属性设置为
true
，从目录中的特定 Helm Chart 仓库禁用 Helm Charts。
要通过 CLI 禁用 Helm Chart 仓库，将
disabled: true
标志添加到自定义资源中。例如，要删除 Azure 示例 chart 存储库，请运行：
$ cat <<EOF | oc apply -f -
apiVersion: helm.openshift.io/v1beta1
kind: HelmChartRepository
metadata:
name: azure-sample-repo
spec:
connectionConfig:
url:https://raw.githubusercontent.com/Azure-Samples/helm-charts/master/docs
disabled: true
使用 Web 控制台禁用最近添加的 Helm Chart 仓库：
进入 自定义资源定义 并搜索 HelmChartRepository 自定义资源。
进入 实例，找到您要禁用的存储库，并点击其名称。
进入 YAML 选项卡，在 spec 部分添加 disabled: true 标志，点 Save。
spec:
connectionConfig:
url: <url-of-the-repositoru-to-be-disabled>
disabled: true
现在，这个仓库已被禁用，并不会出现在目录中。
您可以使用 web 控制台中的
Developer
视角来更新、回滚或卸载 Helm 发行版本。
您可以把一个 Helm 发行版本升级到新的 chart 版本，或更发行版本的配置。
在
Topology
视图中，选择 Helm 发行本来查看侧面面板。
点
Actions
→
Upgrade Helm Release
。
在
Upgrade Helm Release
页面中，选择您要升级到的
Chart Version
，然后点
Upgrade
以创建另一个 Helm 发行版本。
Helm Releases
页面会显示两个修订版本。
如果一个发行版本有问题，您可以将 Helm 发行版本恢复到上一个版本。
使用
Helm
视图回滚发行版本：
在
Developer
视角中，导航到
Helm
视图以查看命名空间中的
Helm Release
版本。
点击列出的发行版本
旁边的
Options
菜单，然后选择
Rollback
。
在
Rollback Helm Release
页中，选择要回滚到的
Revision
，点
Rollback
。
在
Helm Releases
页面中，点 chart 查看该发行版本的详情和资源。
进入
Revision History
标签页来查看这个 chart 的所有修订版本。
如果需要，您可以进一步使用一个特定修订版本旁的
Options
选项
并选择回滚到的修订版本。
流程
-
在
Topology
视图中，右键点击 Helm 发行版本并选择
Uninstall Helm Release
。
在确认提示中，输入 chart 的名称并点击
Uninstall
。
6.1. 了解 Deployment 和 DeploymentConfig 对象
OpenShift Container Platform 中的
Deployment
和
DeploymentConfig
API 对象提供了两个类似但不同的方法来对常见用户应用程序进行精细管理。由以下独立 API 对象组成：
DeploymentConfig
或
Deployment
，各自将应用程序特定组件的所需状态描述为 pod 模板。
DeploymentConfig
对象涉及一个或多个
复制控制器
，其中包含部署状态的时间点记录，作为 pod 模板。同样,
Deployment
对象涉及一个或多个
副本集
，即复制控制器的后续。
一个或多个 pod,，表应用程序某一特定版本的实例。
Deployment 和部署配置分别通过使用原生 Kubernetes API 对象
ReplicaSet
和
ReplicationController
来启用，作为构建块。
用户不必操作复制控制器、副本集或
DeploymentConfig
对象或部署所拥有的 pod。部署系统可确保正确传播更改。
如果现有部署策略不适用于您的用例，而且必须在部署的生命周期内执行手动步骤，那么应考虑创建自定义部署策略。
以下部分详细介绍了这些对象。
复制控制器确保任何时候都运行指定数量的 pod 副本。如果 pod 退出或被删除，复制控制器会做出反应，实例化更多 pod 来达到定义的数量。同样，如果运行中的数量超过所需的数目，它会根据需要删除相应数量的 Pod，使其与定义的数量相符。
复制控制器配置包括：
需要的副本数量，可在运行时调整。
创建复制
Pod
时要使用的 Pod 定义。
用于标识受管 pod 的选择器。
选择器是分配给由复制控制器管理的 pod 的一组标签。这些标签包含在复制控制器实例化的
Pod
定义中。复制控制器使用选择器来决定已在运行的 pod 实例数量，以便根据需要进行调整。
复制控制器不会基于负载或流量执行自动扩展，因为复制控制器不会跟踪它们。相反，这需要由外部自动缩放器调整其副本数。
以下是复制控制器的示例定义：
apiVersion: v1
kind: ReplicationController
metadata:
name: frontend-1
spec:
replicas: 1 1
selector: 2
name: frontend
template: 3
metadata:
labels: 4
name: frontend 5
spec:
containers:
- image: openshift/hello-openshift
name: helloworld
ports:
- containerPort: 8080
protocol: TCP
restartPolicy: Always
-
1
-
要运行的 pod 的副本数。
要运行的 pod 的标签选择器。
控制器创建的 pod 模板。
pod 上的标签应该包括标签选择器中的标签。
扩展任何参数后的最大名称长度为 63 个字符。
6.1.1.2. 副本集（Replica set）
与复制控制器类似,
ReplicaSet
是一个原生 Kubernetes API 对象，可以确保在任意给定时间运行指定数量的 pod 副本。副本集与复制控制器之间的区别在于，副本集支持基于集合的选择器要求，而复制控制器只支持基于相等的选择器要求。
只有您需要自定义更新编配，或根本不需要更新时，才使用副本集。否则，使用部署。副本集可以独立使用，但由部署使用用来编配 pod 创建、删除和更新。部署会自动管理其副本集，为 pod 提供声明性更新，且不需要手动管理它们创建的副本集。
以下是
ReplicaSet
定义示例：
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend-1
labels:
tier: frontend
spec:
replicas: 3
selector: 1
matchLabels: 2
tier: frontend
matchExpressions: 3
- {key: tier, operator: In, values: [frontend]}
template:
metadata:
labels:
tier: frontend
spec:
containers:
- image: openshift/hello-openshift
name: helloworld
ports:
- containerPort: 8080
protocol: TCP
restartPolicy: Always
-
1
-
对一组资源进行的标签查询。
matchLabels
和
matchExpressions
的结果在逻辑上是组合在一起的。
基于相等的选择器，使用与选择器匹配的标签指定资源。
基于集合的选择器，用于过滤键。这将选择键等于
tier
并且值等于
frontend
的所有资源。
6.1.2. DeploymentConfig 对象
在复制控制器的基础上，OpenShift Container Platform 增加了对软件开发和部署生命周期的支持,，及
DeploymentConfig
对象的概念。在最简单的情形中，
DeploymentConfig
对象会创建一个新的复制控制器，并允许它启动 pod。
但是，从
DeploymentConfig
对象部署的 OpenShift Container Platform 也支持从镜像的现有部署过渡到新部署，同时还可以定义在创建复制控制器之前或之后运行的 hook。
DeploymentConfig
部署系统提供以下功能：
DeploymentConfig
对象，这是运行应用程序的模板。
为响应事件而触发自动化部署的触发器。
用户可自定义的部署策略，用于从上一版本过渡到新版本。在 pod 内运行的策略，通常称为部署过程。
一组 hook（生命周期 hook），用于在部署生命周期的不同点上执行自定义行为。
应用程序的版本控制，以便在部署失败时支持手动或自动的回滚。
复制的手动扩展和自动扩展。
在创建
DeploymentConfig
对象时，会创建一个复制控制器来代表
DeploymentConfig
对象的 pod 模板。如果部署被改变，则会使用最新的 pod 模板创建一个新的复制控制器，并运行部署过程来缩减旧复制控制器并扩展新的复制控制器。
在创建时，自动从服务负载均衡器和路由器中添加和移除应用程序的实例。只要应用程序支持接收
TERM
信号时安全关机，您可以确保运行的用户连接拥有正常完成的机会。
OpenShift Container Platform
DeploymentConfig
对象定义以下详细信息：
ReplicationController
定义的元素。
自动创建新部署的触发器。
在部署之间过渡的策略。
生命周期 hook。
每次触发部署时，无论是手动还是自动，部署器 Pod 均管理部署（包括缩减旧复制控制器、扩展新复制控制器以及运行 hook）。部署 pod 在完成部署后会无限期保留，以便保留其部署日志。当部署被另一个部署替换时，以前的复制控制器会被保留，以便在需要时轻松回滚。
Kubernetes 在 OpenShift Container Platform 中提供了一流的原生 API 对象类型，名为
Deployment
。
Deployment
对象充当针对一个 OpenShift Container Platform
DeploymentConfig
的后代。
与
DeploymentConfig
对象一样，
Deployment
对象将应用程序特定组件的所需状态描述为 pod 模板。Deployment 创建副本集，用于编配 pod 生命周期。
例如，以下部署定义会创建一个副本集来启动一个
hello-openshift
pod:
6.1.4. Deployment 和 DeploymentConfig 对象的比较
OpenShift Container Platform 支持 Kubernetes
Deployment
对象和 OpenShift Container Platform 提供的
DeploymentConfig
对象，但建议您使用
Deployment
对象，除非您需要
DeploymentConfig
对象提供的特定功能或行为。
以下部分详细阐述两种对象之间的区别，以进一步协助您决定使用哪一种类型。
Deployment
和
DeploymentConfig
对象之间的一个重要区别是为推出（rollout）过程所选择的
CAP theorem
属性。
DeploymentConfig
对象以一致性为先，而
Deployments
对象优先于可用性。
对于
DeploymentConfig
对象，如果运行一个部署器 pod 的节点停机，它不会被替换掉。流程会等待节点重新在线或被手动删除。手动删除节点也会删除对应的 pod。这意味着您无法删除 pod 来取消推出部署，因为 kubelet 负责删除相关联的 pod。
但是，部署推出由控制器管理器驱动。控制器管理器在 master 上运行高可用性模式，并使用群首选举算法提高可用性与一致性相比的价值。在故障期间，其他 master 有可能同时对同一部署做出反应，但这个问题会在故障发生后很快进行调节。
6.1.4.2. deploymentConfig 对象相关的功能
自动回滚
目前，在出现故障时，部署不支持自动回滚到上次成功部署的副本集。
部署有一个隐式配置更改触发器，每次更改部署的 Pod 模板都会自动触发新的推出部署。如果您不想在 Pod 模板更改时进行新的推出部署，请暂停部署：
$ oc rollout pause deployments/<name>
生命周期 hook
Deployment 尚不支持任何生命周期 hook。
自定义策略
部署尚不支持用户指定的自定义部署策略。
滚动
Deployment
的部署过程是由控制器循环推动的，这与使用部署器 Pod 进行每次新推出部署的
DeploymentConfig
相反。这意味着
Deployment
对象可以拥有尽可能多的活跃副本集，最终部署控制器将缩减所有旧副本集，并扩展最新的副本集。
DeploymentConfig
对象最多可以有一个部署器 pod 运行，否则多个部署器在试图扩展其认为是最新的复制控制器时会导致冲突。因此，任何时间点上只能有两个复制控制器处于活跃状态。最终，这会转化为
Deployment
能够更快地进行推出部署。
按比例扩展
因为部署控制器是适合由
Deployment
对象拥有的新和旧副本集的大小的唯一来源，所以它能够扩展持续推出部署。额外副本会根据每个副本集的大小按比例分发。
当推出（rollout）进行的过程中，
DeploymentConfig
对象无法被扩展，因为控制器会遇到部署器进程中有关新 ReplicationController 大小的问题。
中途暂停推出部署
Deployment 可以在任何时间暂停，这意味着可以暂停正在进行的推出部署。另一方面，当前还无法暂停部署器 Pod。因此，如果您尝试在推出部署进行期间暂停部署，则部署器进程不受影响，它会继续运行直到完成为止。
6.2.1. 管理 DeploymentConfig 对象
DeploymentConfig
对象可以通过 OpenShift Container Platform Web 控制台的
Workloads
页面或使用
oc
CLI 管理。以下流程演示了 CLI 的用法（除非另有说明）。
您可以启动一个部署推出（rollout）来开始应用程序的部署过程。
要从现有的
DeploymentConfig
对象启动新的部署过程，请运行以下命令：
$ oc rollout latest dc/<name>
如果部署过程已在进行中，此命令会显示一条消息，不会部署新的复制控制器。
您可以查看部署来获取应用程序所有可用修订的基本信息。
要显示所有最近为提供的
DeploymentConfig
对象创建的复制控制器的详细信息，包括任何当前运行的部署过程，请运行以下命令：
$ oc rollout history dc/<name>
要查看修订的相关细节，请使用
--revision
标志：
$ oc rollout history dc/<name> --revision=1
如需有关
DeploymentConfig
对象和最新修订的详细信息，请使用
oc describe
命令：
$ oc describe dc <name>
如果
DeploymentConfig
对象的当前修订无法部署，您可以重启部署过程。
重启已经失败的部署过程：
$ oc rollout retry dc/<name>
如果成功部署了最新的修订，该命令会显示一条消息，且不会重试部署过程。
重试部署会重启部署过程，且不创建新的部署修订。重启的复制控制器具有与失败时相同的配置。
回滚将应用恢复到上一修订，可通过 REST API、命令行或 Web 控制台进行。
回滚到配置的最近一次部署成功的修订：
$ oc rollout undo dc/<name>
恢复
DeploymentConfig
对象的模板以匹配 undo 命令中指定的部署修订，并且会启动新的复制控制器。如果没有通过
--to-revision
指定修订，则使用最近一次成功部署的修订。
部署过程中会禁用
DeploymentConfig
对象中的镜像更改触发器，以防止在回滚完成不久后意外启动新的部署过程。
重新启用镜像更改触发器：
$ oc set triggers dc/<name> --auto
部署配置也支持最新部署过程失败时自动回滚到配置的最近一次成功修订。这时，系统会原样保留部署失败的最新模板，由用户来修复其配置。
您可以为容器添加命令，用来覆盖决镜像的
ENTRYPOINT
设置来改变容器的启动行为。这与生命周期 hook 不同，后者在每个部署的指定时间点上运行一次。
在
DeploymentConfig
对象的
spec
字段中添加
command
参数。您也可以添加
args
字段来修改
command
（如果
command
不存在，则修改
ENTRYPOINT
）。
spec:
containers:
- name: <container_name>
image: 'image'
command:
- '<command>'
args:
- '<argument_1>'
- '<argument_2>'
- '<argument_3>'
例如，使用
-jar
和
/opt/app-root/springboots2idemo.jar
参数来执行
java
命令：
spec:
containers:
- name: example-spring-boot
image: 'image'
command:
- java
args:
- '-jar'
- /opt/app-root/springboots2idemo.jar
流程
-
输出给定
DeploymentConfig
对象的最新修订的日志：
$ oc logs -f dc/<name>
如果最新的修订正在运行或已失败，命令会返回负责部署 Pod 的进程的日志。如果成功，它将从应用程序的 pod 返回日志。
您还可以查看来自旧的失败部署进程的日志，只要存在这些进程（旧的复制控制器及其部署器 pod）并且没有手动清理或删除：
$ oc logs --version=1 dc/<name>
DeploymentConfig
对象可以包含触发器，推动创建新部署过程以响应集群中的事件。
如果
DeploymentConfig
对象上没有定义任何触发器，则默认添加配置更改触发器。如果触发器定义为空白字段，则必须手动启动部署。
配置更改部署触发器
当在
DeploymentConfig
对象的 pod 模板中发现配置改变时，配置更改触发器会生成一个新的复制控制器。
如果在
DeploymentConfig
对象上定义了配置更改触发器，则在
DeploymentConfig
对象本身创建后会自动创建第一个复制控制器,且不会暂停。
镜像更改部署触发器
镜像更改触发器会在镜像流标签内容更改时（推送镜像的新版本时）产生新的复制控制器。
流程
-
您可以使用
oc set triggers
命令为
DeploymentConfig
对象设置部署触发器。例如，要设置镜像更改触发器，请使用以下命令：
$ oc set triggers dc/<dc_name> \
--from-image=<project>/<image>:<tag> -c <container_name>
部署由节点上消耗资源（内存、CPU 和临时存储）的 pod 完成。默认情况下，pod 消耗无限的节点资源。但是，如果某个项目指定了默认容器限值，则 pod 消耗的资源会被限制在这些限值范围内。
部署的最小内存限值为 12MB。如果容器因为一个
Cannot allocate memory
pod 事件启动失败，这代表内存限制太低。增加或删除内存限制。删除限制可让 pod 消耗无限的节点资源。
您还可以在部署策略中指定资源限值来限制资源使用。部署资源可用于 recreate、rolling 或 custom 部署策略。
在以下示例中，
resources
、
cpu
、
memory
和
ephemeral-storage
中每一个都是可选的：
type: "Recreate"
resources:
limits:
cpu: "100m" 1
memory: "256Mi" 2
ephemeral-storage: "1Gi" 3
-
1
-
cpu
以 CPU 单元表示：
100m
代表 0.1 CPU 单元（100 * 1e-3）。
内存
以字节为单位：
256Mi
代表 268435456 字节(256 * 2 ^ 20)。
ephemeral-storage
以字节为单位：
1Gi
表示 1073741824 字节(2 ^ 30)。
不过，如果您的项目定义了配额，则需要以下两项之一：
设定了显式
requests
的
resources
部分：
type: "Recreate"
resources:
requests: 1
cpu: "100m"
memory: "256Mi"
ephemeral-storage: "1Gi"
-
1
-
requests
对象包含与配额中资源列表对应的资源列表。
您项目中定义的限值范围，其中
LimitRange
对象中的默认值应用到部署过程中创建的 pod。
要设置部署资源，请选择以上选项之一。否则，部署 pod 创建失败，显示无法满足配额要求。
如需有关资源限值和请求的更多信息，请参阅
了解管理应用程序内存
。
除了回滚外，您还可以通过手动缩放来对副本数量进行细致的控制。
也可以使用
oc autoscale
命令自动扩展 Pod。
要手动扩展
DeploymentConfig
对象，请使用
oc scale
命令。例如，以下命令将
frontend
DeploymentConfig
对象中的副本设置为
3
。
$ oc scale dc frontend --replicas=3
副本数量最终会传播到
DeploymentConfig
对象
frontend
配置的部署的预期和当前状态。
6.2.1.10. 从 DeploymentConfig 对象访问私有存储库
您可以在
DeploymentConfig
对象中添加 secret，以便它可以从私有存储库访问镜像。此流程演示了 OpenShift Container Platform Web 控制台方法。
创建一个新项目。
在
Workloads
页面中，创建一个含有用于访问私有镜像存储库的凭证的 secret。
创建
DeploymentConfig
对象。
在
DeploymentConfig
对象编辑器页面中，设置
Pull Secret
并保存您的更改。
您可以结合使用节点选择器和带标签的节点来控制 pod 的放置。
集群管理员可为项目设置默认的节点选择器，以便将 pod 放置限制到特定的节点。作为开发人员，您可以设置
Pod
配置的节点选择器来进一步限制节点。
要在创建 Pod 时添加节点选择器，请编辑
Pod
配置并添加
nodeSelector
值。这可添加到单个
Pod
配置中，也可以添加到
Pod
模板中：
apiVersion: v1
kind: Pod
spec:
nodeSelector:
disktype: ssd
具有节点选择器时创建的 Pod 会分配给带有指定标签的节点。这里指定的标签将与集群管理员添加的标签结合使用。
例如，如果项目中包含由集群管理员添加的 type=user-node 和 region=east 标签，并且您将上述 disktype: ssd 标签添加到某一 pod，那么该 pod 仅会调度到具有所有这三个标签的节点上。
标签只能设置为一个值；因此，如果在具有管理员设置的默认值 region=east 的 Pod 配置中设置节点选择器 region=west，这会导致 pod 永不会被调度。
您可以使用非默认服务帐户运行 pod。
编辑
DeploymentConfig
对象：
$ oc edit dc/<deployment_config>
将
serviceAccount
和
serviceAccountName
参数添加到
spec
字段，再指定您要使用的服务帐户：
spec:
securityContext: {}
serviceAccount: <service_account>
serviceAccountName: <service_account>
部署策略
是更改或升级应用程序的一种方法。其目的是在无需停机的前提下进行修改，从而使用户几乎不会注意到这些变化。
因为最终用户通常通过由路由器控制的路由访问应用程序，所以部署策略侧重于
DeploymentConfig
对象功能或路由功能。注重部署的策略会影响所有使用该应用程序的路由。侧重于路由功能的策略则会影响到单个的路由。
许多部署策略通过
DeploymentConfig
对象支持，一些额外的策略则通过路由器功能支持。本节将讨论部署策略。
选择部署策略
选择部署策略时请考虑以下几点：
长时间运行的连接必须被恰当处理。
数据库转换可能比较复杂，且必须和应用程序一同执行并回滚。
如果应用程序由微服务和传统组件构成，则可能需要停机才能完成转换。
您必须拥有进行此操作的基础架构。
如果您的测试环境没有被隔离，则可能会破坏到新版本和旧版本。
部署策略使用就绪度检查来确定新 pod 是否准备就绪。如果就绪度检查失败，
DeploymentConfig
对象会重新尝试运行 pod，直到超时为止。默认超时为
10m
，其值在
dc.spec.strategy.*params
的
TimeoutSeconds
中设置。
滚动部署会逐渐将应用程序旧版本实例替换为应用程序的新版本实例。如果
DeploymentConfig
对象上没有指定任何策略，则滚动策略是默认的部署策略。
在缩减旧组件前，滚动部署通常会 等待新 pod 变为
ready
。如果发生严重问题，可以中止 Rolling 部署。
使用滚动部署：
希望在应用程序更新过程中不需要停机时。
应用程序同时支持运行旧代码和新代码时。
滚动部署意味着您同时运行旧版和新版本的代码。这通常需要您的应用程序可以处理 N-1 兼容性。
在部署过程中，新复制控制器以递增方式扩展。新 pod 标记为
ready
（通过就绪度检查）后，部署过程将继续。
如果 pod 尚未就绪，该过程会中止，部署回滚到之前的版本。
6.3.1.3. 使用 Developer 视角启动滚动部署
先决条件
-
确认您使用 web 控制台的
Developer
视角。
确保您已使用
Add
视图创建了一个应用程序，并可以在
Topology
视图中查看它。
要启动滚动部署来升级应用程序：
在
Developer
视角的
Topology
视图中，点应用程序节点，查看侧面面板中的
Overview
选项卡。请注意，
Update Strategy
被设置为默认的
Rolling
策略 。
在
Actions
下拉菜单中，选择
Start Rollout
来启动滚动更新。滚动部署将应用程序更新到新版本，然后终止旧版本。
Recreate（重新创建）策略具有基本的推出部署行为，并支持使用生命周期 hook 将代码注入到部署过程中。
6.3.3. 使用 Developer 视角启动重新创建的部署
您可以使用 web 控制台中的
Developer
视角将部署策略从默认的滚动模式切换到重新创建模式。
确认您使用 web 控制台的
Developer
视角。
确保您已使用
Add
视图创建了一个应用程序，并可以在
Topology
视图中查看它。
切换到重新创建的更新策略并升级应用程序：
在
Actions
下拉菜单中，选择
Edit Deployment Config
来查看应用程序的部署配置详情。
在 YAML 编辑器中，将
spec.strategy.type
更改为
Recreate
，然后点
Save
。
在
Topology
视图中，选择节点即可看到侧面板中的
Overview
选项卡。
Update Strategy
现在设为
Recreate
。
使用
Actions
下拉菜单选择
Start Rollout
以使用 recreate 策略启动更新。recreate 策略首先会终止旧版本应用程序的 pod，然后为新版本启动 pod。
自定义（Custom）策略允许您提供自己的部署行为。
|
