一 CLI访问OpenShift资源
1.1 资源操作
OCP将OpenShift集群中的为由主节点管理的对象统称为资源，如：node、service、pod、project、deployment、user。
即使针对的是不同的资源，OpenShift命令行工具也提供了一种统一的、一致的方法来更新、修改、删除和查询这些资源。
oc命令行工具提供了在软件开发项目的整个交付生命周期中修改和管理资源的常见操作。
1.2 安装oc工具
在OpenShift安装过程中，oc命令行工具安装在所有master和node节点上，还可以在不属于OpenShift集群的机器。
安装后，可以使用用户名和密码对任何主节点通过身份验证后执行相关命令。
根据使用的平台，安装oc命令行工具有以下几种方式：
yum安装：在RHEL平台上，可通过以下命令安装oc客户端命令。
[user@host ~]$ sudo yum install atomic-openshift-clients
其它 Linux 发行版本和操作系统，需在拥有 OpenShift 订阅后，在 Red Hat Customer Portal 中下载。
提示：oc安装完成后自动补全需要退出一次才可生效，或者source /etc/bash_completion.d/oc。
1.3 oc主要查询命令
[student@workstation ~]$ oc --help #显示帮助信息
[student@workstation ~]$ oc login -u developer -p redhat https://master.lab.example.com #登录到OpenShift集群
提示：从client成功通过身份验证之后，OpenShift将授权令牌保存在用户的主文件夹中。此令牌用于后续请求，从而无需重新输入凭据或完整的主URL。
1 [root@master ~]# oc whoami 2 system:admin #master的root用户为集群的最高权限的用户 3 [student@workstation ~]$ oc whoami #查看当前用户 4 developer 5 [student@workstation ~]$ oc new-project working #创建project 6 [student@workstation ~]$ oc status #查看项目状态 7 In project working on server https://master.lab.example.com:443 8 You have no services, deployment configs, or build configs. 9 Run 'oc new-app' to create an application. 10 [student@workstation ~]$ oc delete project working #删除project 11 [student@workstation ~]$ oc logout #退出该集群。 12 [student@workstation ~]$ oc get pods #查看pod 13 NAME READY STATUS RESTARTS AGE 14 hello-openshift-1-6ls8z 1/1 Running 0 4h 15 [student@workstation ~]$ oc get all #查看所有主要组件信息 16 [student@workstation ~]$ oc get pods -w #-w表示以监视模式运行
1.4 oc 其他命令
oc describe：如果oc get提供的摘要不够，可以使用oc describe命令检索关于资源的更详细信息。
[student@workstation ~]$ oc describe pod hello-openshift-1-6ls8z
oc export：使用oc export命令导出资源的定义。典型的用例包括创建备份，或者用于修改定义。默认情况下，export命令以YAML格式输出对象表示，但是可以通过提供-o选项来更改。
oc create：使用oc create命令从资源定义创建资源。通常，这与用于编辑定义的oc export命令相匹配。
oc delete RESOURCE_TYPE name：使用oc delete命令从OpenShift集群中删除资源。
注意：部分资源直接删除后会重新创建，如基于rc的pod，需要对OpenShift体系资源展示形式有一个基本的了解。
oc exec：使用oc exec命令在容器中执行命令，可以使用此命令作为脚本的一部分运行交互式和非交互式批处理命令。
oc rsh POD：oc rsh pod命令打开到容器的远程shell会话，要远程登录到容器shell并执行命令，请运行以下命令。
[student@workstation ~]$ oc rsh
注意：oc rsh需要pod中存在相应的shell，如bash。
二 OpenShift资源类型
2.1 常见资源
OpenShift容器平台中的应用程序由不同类型的资源组成，主要常见的类型有：
- Container：如何在可移植Linux环境中运行一个或多个进程的定义。容器从一个映像启动，并且通常与同一机器上的其他容器隔离。
- Image：一个分层的Linux文件系统，包含应用程序代码、依赖关系和函数库等。image由一个名称标识，该名称可以是当前集群的本地名称，也可以指向远程Docker仓库。
- Pod：部署在节点上并共享唯一IP地址和卷(持久存储)的一个或多个容器，Pods还为每个容器定义安全性和运行时策略。
- Label：标签是键值对，可以分配给系统中的任何资源进行分组和选择。通常资源使用标签来标识其他资源集。
- Volume：默认情况下容器不是持久性的，即容器的内容在重新启动时被清除。volume是挂载在pod及其容器上的文件系统，它们可能由许多本地或网络的存储提供。最简单的卷类型是EmptyDir，它是一台机器上的临时目录。
- Node：node是集群中用来运行容器的节点，node通常由管理员管理，而不是由最终用户管理。
- Service：service是表示一组pod的逻辑名称，service被分配一个IP地址和一个DNS名称，可以通过端口或route向集群外部公开。名为SERVICE_HOST的环境变量会自动注入到其他pod中。
- Route：route是一个DNS条目，创建它是为了指向一个service，以便可以从集群外部访问它。可以配置一个或多个路由器来处理这些route，通常通过HAProxy负载均衡器。
- Replication Controller：Replication Controller基于匹配一组label的Templates维护特定数量的pod。如果删除了pod，控制器将创建该pod的新副本。Replication Controller最常用来表示基于image的应用程序部分的单个部署。
- Deployment Configuration：deployment configuration定义pod的模板，并在属性更改时管理部署新映像或配置更改。单个deployment configuration通常类似于单个微服务。deployment configuration可以支持许多不同的部署模式，包括完全重启、可定制的滚动更新以及生命周期前后的顺序。每个deployment都表示为一个replication controller。
- Build Configuration：build configuration包含如何将源代码和基本image构建为新image的描述。Build可以是基于源代码的，可以为常见语言(如Java、PHP、Ruby或Python)或基于docker的(从Dockerfile创建构建)使用构建器映像。每个build configuration都有webhook，可以通过对其基本映像的更改自动触发。
- Build：构建从源代码、其他图像、Dockerfiles或二进制输入创建新image。Build在容器中运行，具有与普通pod相同的限制。Build通常会导致将image推入Docker仓库中，但也可以选择运行post-build测试而不push到image仓库。
- Image Streams and Image Stream Tags：IS使用标记名称对相关is进行分组。它类似于源代码仓库中的分支。每个is可以有一个或多个标记(默认标记称为“latest”)，这些标记可能指向外部Docker仓库、同一is中的其他标记，或者被控制为直接指向已知image。此外，可以通过集成的Docker仓库直接将image push到docker仓库。
- Secret：secret资源可以保存文本或二进制secrets，以便注入至pod。默认情况下，在/var/run/secrets/kubernetes.io/serviceaccount上，每个容器都有一个secret，其中包含访问API有限特权的令牌。可以创建新的secret并将它们挂载到自己的pod中，也可以引用构建中的secret(用于连接远程服务器)，或者使用它们将远程image导入到is中。
- Project：所有上述资源(node除外)都存在于项目中。项目具有成员列表及其role(如view、edit或admin)，以及运行的pod上的一组安全控制，并限制项目可以使用多少资源，资源名称在项目中是惟一的。
使用oc types命令快速查看可用的概念和类型。
2.2 创建应用
简单的应用程序、复杂的多层应用程序和微服务应用程序都可以使用资源定义文件来描述。
这个文件包含许多pod定义、连接这些pod的服务定义、用于水平伸缩应用程序pod的rc或dc、用于持久存储应用程序数据的持久卷，以及OpenShift可以管理的任何其他需要的内容。
oc new-app命令可以使用-o json或-o yaml选项分别创建以json或yaml格式的定义文件的资源。可以使用oc create -f 命令调用定义文件，并将其用于创建应用程序，或者与其他资源定义文件合并以创建复合应用程序。
oc new-app命令可以以许多不同的方式创建在OpenShift上运行的pod应用程序。它可以使用source-to-image (S2I)流程从现有docker映像、Dockerfiles或原始源代码创建pod。
运行oc new-app -h命令，了解在OpenShift上创建新应用程序的所有不同选项。最常见的选项如下:
运行以下命令创建应用程序。OpenShift根据Docker配置文件的ADD_REGISTRY选项定义的仓库 pull image。
$ oc new-app mysql MYSQL_USER=user MYSQL_PASSWORD=pass MYSQL_DATABASE=testdb -l
db=mysql
根据私有仓库中的image创建应用程序。
$ oc new-app --docker-image=myregistry.com/mycompany/myapp --name=myapp
根据存储在Git库中的源代码创建应用程序。
$ oc new-app https://github.com/openshift/ruby-hello-world --name=ruby-hello
创建基于存储在Git库中的源代码并引用IS的应用程序。
$ oc new-app https://mygitrepo/php-hello -i php:7.0 --name=php-hello
从Docker配置文件的ADD_REGISTRY指令定义的可用仓库之一创建一个基于mysql映像的应用程序。l db=mysql选项定义了一个值为mysql的db标签。
$ oc new-app mysql MYSQL_USER=user \
MYSQL_PASSWORD=pass \
MYSQL_DATABASE=testdb \
-l db=mysql
下图显示了oc new-app命令在参数为容器image时创建的Kubernetes和OpenShift资源。该命令创建dc、is和svc，可以通过端口或route从外部访问。
提示：通过使用带有源代码的oc new-app，将创建一个build configuration，而bc又从源代码创建一个新的应用程序。但是，如果命令中没有使用源代码，则不会创建gc。该命令始终为应用程序创建dc和svc。
三 oc使用练习
3.1 前置准备
准备完整的OpenShift集群，参考《003.OpenShift网络》2.1。
3.2 本练习准备
[student@workstation ~]$ lab manage-oc setup
3.3 验证OpenShift
1 [student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com 2 [student@workstation ~]$ oc project default 3 Already on project "default" on server "https://master.lab.example.com:443". 4 [student@workstation ~]$ oc project default 5 Already on project "default" on server "https://master.lab.example.com:443". 6 [student@workstation ~]$ oc get nodes 7 NAME STATUS ROLES AGE VERSION 8 master.lab.example.com Ready master 23h v1.9.1+a0ce1bc657 9 node1.lab.example.com Ready compute 23h v1.9.1+a0ce1bc657 10 node2.lab.example.com Ready compute 23h v1.9.1+a0ce1bc657 11 [student@workstation ~]$ oc describe node master.lab.example.com #查看master节点详情 12 [student@workstation ~]$ oc describe node node1.lab.example.com 13 [student@workstation ~]$ oc describe node node2.lab.example.com 14 [student@workstation ~]$ oc get pods -o wide 15 NAME READY STATUS RESTARTS AGE IP NODE 16 docker-registry-1-8v7sh 1/1 Running 4 23h 10.129.0.30 node2.lab.example.com 17 docker-registry-1-rrmhm 1/1 Running 2 23h 10.128.0.12 node1.lab.example.com 18 registry-console-1-xzxxp 1/1 Running 4 23h 10.129.0.31 node2.lab.example.com 19 router-1-fwttd 1/1 Running 4 23h 172.25.250.12 node2.lab.example.com 20 router-1-xdw84 1/1 Running 2 23h 172.25.250.11 node1.lab.example.com 21 [student@workstation ~]$ oc describe pod docker-registry-1-8v7sh #查看pod详情
3.4 pod操作
[student@workstation ~]$ oc exec docker-registry-1-8v7sh hostname #执行pod中命令
docker-registry-1-8v7sh
[student@workstation ~]$ oc exec router-1-fwttd ls /
[student@workstation ~]$ oc exec docker-registry-1-8v7sh cat /etc/resolv.conf
提示：只要pod中存在的命令，都可以通过oc exec直接执行。
[student@workstation ~]$ oc rsh docker-registry-1-8v7sh #进入pod的shell
sh-4.2$ ls /
3.5 oc其他操作
[student@workstation ~]$ oc status -v #现实详细的状态
[student@workstation ~]$ oc get events #查看集群生命周期事件
[student@workstation ~]$ oc get all #获取所有资源信息
3.6 导出资源
[student@workstation ~]$ oc export pod docker-registry-1-8v7sh
提示：oc export命令通常用于导出现有资源，并将它们转换为配置文件(YAML或JSON)，以便备份或在集群的其他地方重新创建资源。
[student@workstation ~]$ oc export svc,dc docker-registry --as-template=docker-registry
#通过将--as-template选项传递给oc export命令，将多个资源作为OpenShift模板同时导出。
[student@workstation ~]$ oc export svc,dc docker-registry > docker-registry.yaml #也可以使用重定向导出
[student@workstation ~]$ oc export --help #查看帮助
四 oc常见故障排除
4.1 常见环境信息
使用RPM安装的OCP，那么master和node的ocp相关服务将作为Red Hat Enterprise Linux服务运行。从master和node使用标准的sosreport实用程序，收集关于环境的信息，以及docker和openshift相关的信息。
[root@master ~]# sosreport -k docker.all=on -k docker.logs=on
sosreport命令创建一个包含所有相关信息的压缩归档文件，并将其保存在/var/tmp目录中。
另一个有用的诊断工具是oc adm diagnostics命令，能够在OpenShift集群上运行多个诊断检查，包括network、日志、内部仓库、master节点和node节点的服务检查等等。oc adm diagnostics --help命令，获取帮助。
4.2 常见诊断命令
oc客户端命令是用来检测和排除OpenShift集群中的问题的主要工具。它有许多选项，能够检测、诊断和修复由集群管理的主机和节点、服务和资源的问题。若已授权所需的权限，可以直接编辑集群中大多数托管资源的配置。
- oc get events
事件允许OpenShift记录集群中生命周期事件的信息，以统一的方式查看关于OpenShift组件的信息。oc get events命令提供OpenShift namespace的事件信息，可实现以下事件的捕获：
- Pod创建和删除
- pod调度的节点
- master和node节点的状态
事件通常用于故障排除，从而获得关于集群中的故障和问题的高级信息，然后使用日志文件和其他oc子命令进一步定位。
示例：使用以下命令获得特定项目中的事件列表。
[student@workstation ~]$ oc get events -n
也可以通过Web控制台进行事件的查看events。
- oc log
oc logs命令查看build、deployment或pod的日志输出，。
示例1：使用oc命令查看pod的日志。
[student@workstation ~]$ oc logs pod
示例2：使用oc命令查看build的日志。
[student@workstation ~]$ oc logs bc/build-name
使用oc logs命令和-f选项实时跟踪日志输出。例如，这对于连续监视build的进度和检查错误非常有用。
也可以通过Web控制台进行事件的查看log。
- oc rsync
oc rsync命令将内容复制到正在运行的pod中的目录或从目录复制内容。如果一个pod有多个容器，可以使用-c选项指定容器ID。否则，它默认为pod中的第一个容器。通常用于从容器传输日志文件和配置文件。
示例1：将pod目录中的内容复制到本地目录。
[student@workstation ~]$ oc rsync : -c
示例2：将内容从本地目录复制到pod的目录中。
[student@workstation ~]$ oc rsync : -c
- oc port-forward
使用oc port-forward命令将一个或多个本地端口转发到pod。这允许在本地监听特定或随机端口，并将数据转发到pod中的特定端口。
示例1：本地监听3306并转发到pod的3306.
[student@workstation ~]$ oc port-forward 3306:3306
五 TS常见故障
5.1 资源限制和配额问题
对于设置了资源限制和配额的项目，不适当的资源配置将导致部署失败。使用oc get events和oc describe命令来排查失败的原因。
例如试图创建超过项目中pod数量配额限制的pod数量，那么在运行oc get events命令时会提示：
Warning FailedCreate {hello-1-deploy} Error creating: pods "hello-1" is forbidden:
exceeded quota: project-quota, requested: cpu=250m, used: cpu=750m, limited: cpu=900m
5.2 S2I build失败
使用oc logs命令查看S2I构建失败。例如，要查看名为hello的构建配置的日志:
[student@workstation ~]$ oc logs bc/hello
例如可以通过在build configuration策略中指定BUILD_LOGLEVEL环境变量来调整build日志的详细程度。
1 { 2 "sourceStrategy": { 3 ... 4 "env": [ 5 { 6 "name": "BUILD_LOGLEVEL", 7 "value": "5" 8 } 9 ] 10 } 11 }
5.3 ErrImagePull和imgpullback错误
通常是由不正确的deployment configuration造成、部署期间引用的错误或缺少image或Docker配置不当造成。
使用oc get events和oc describe命令排查，通过使用oc edit dc/编辑deployment configuration来修复错误。
5.4 docker配置异常
master和node上不正确的docker配置可能会在部署期间导致许多错误。
通常检查ADD_REGISTRY、INSECURE_REGISTRY和BLOCK_REGISTRY设置。使用systemctl status, oc logs, oc get events和oc describe命令对问题进行排查。
可以通添加/etc/sysconfig/docker配置文件中的--log-level参数来更改docker服务日志级别。
示例：将日志级别设置为debug。
OPTIONS='--insecure-registry=172.30.0.0/16 --selinux-enabled --log-level=debug'
5.5 master和node节点失败
运行systemctl status命令，对atomicopenshift-master、atom-openshift-node、etcd和docker服务中的问题进行排查。使用journalctl -u 命令查看与前面列出的服务相关的系统日志。
可以通过在各自的配置文件中编辑--loglevel变量，然后重新启动关联的服务，来增加来自atom-openshift-node、atomicopenshift-master-controllers和atom-openshift-master-api服务的详细日志记录。
示例：设置OpenShift主控制器log level为debug级别，修改/etc/sysconfig/atomic-openshift-master-controllers文件。
OPTIONS=--loglevel=4 --listen=https://0.0.0.0:8444
延伸：
Red Hat OpenShift容器平台有五个级别的日志详细程度，无论日志配置如何，日志中都会出现带有致命、错误、警告和某些信息严重程度的消息。
- 0：只有错误和警告
- 2：正常信息(默认)
- 4：debug级信息
- 6：api级debug信息(请求/响应)
- 8：带有完整请求体的API debug信息
5.6 调度pod失败
OpenShift master调度pod在node上运行，通常由于node本身没有处于就绪状态，也由于资源限制和配额，pod无法运行。
使用oc get nodes命令验证节点的状态。在调度失败期间，pod将处于挂起状态，可以使用oc get pods -o wide命令进行检查，该命令还显示了计划在哪个节点上运行pod。使用oc get events和oc describe pod命令检查调度失败的详细信息。
示例1：如下所示pod调度失败，原因是CPU不足。
{default-scheduler } Warning FailedScheduling pod (FIXEDhello-phb4j) failed to
fit in any node
fit failure on node (hello-wx0s): Insufficient cpu
fit failure on node (hello-tgfm): Insufficient cpu
fit failure on node (hello-qwds): Insufficient cpu
示例2：如下所示pod调度失败，原因是节点没有处于就绪状态，可通过oc describe排查。
{default-scheduler } Warning FailedScheduling pod (hello-phb4j): no nodes
available to schedule pods
六 常见问题排查
6.1 前置准备
准备完整的OpenShift集群，参考《003.OpenShift网络》2.1。
6.2 本练习准备
[student@workstation ~]$ lab common-troubleshoot setup
6.3 创建应用
[student@workstation ~]$ oc new-project common-troubleshoot
[student@workstation ~]$ oc new-app --name=hello -i php:5.4 \ #从源代码创建应用
> http://services.lab.example.com/php-helloworld
6.4 查看详情
[student@workstation ~]$ oc describe is php -n openshift
结论：由上可知，仓库中不存在所需镜像。
6.5 修正错误
[student@workstation ~]$ oc new-app --name=hello -i php:7.0 http://services.lab.example.com/php-helloworld
[student@workstation ~]$ oc get pod -o wide #再次查看发现一只出于pending
NAME READY STATUS RESTARTS AGE IP NODE
hello-1-build 0/1 Pending 0 40s
6.6 查看详情
1 [student@workstation ~]$ oc log hello-1-build #查看log 2 W0720 20:22:16.455008 18942 cmd.go:358] log is DEPRECATED and will be removed in a future version. Use logs instead. 3 [student@workstation ~]$ oc get events #查看事件 4 LAST SEEN FIRST SEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE 5 56s 4m 15 hello-1-build.15b31cbd8da8ff1e Pod Warning FailedScheduling default-scheduler 0/3 nodes are available: 1 MatchNodeSelector, 2 NodeNotReady. 6 [student@workstation ~]$ oc describe pod hello-1-build #查看详情 7 …… 8 Warning FailedScheduling 31s (x22 over 5m) default-scheduler 0/3 nodes are available: 1 MatchNodeSelector, 2 NodeNotReady. 9 结论：由上可知，没有node可供调度此pod。 10 [root@master ~]# oc get nodes #在master节点进一步排查node情况 11 NAME STATUS ROLES AGE VERSION 12 master.lab.example.com Ready master 1d v1.9.1+a0ce1bc657 13 node1.lab.example.com NotReady compute 1d v1.9.1+a0ce1bc657 14 node2.lab.example.com NotReady compute 1d v1.9.1+a0ce1bc657 15 结论：由上可知，node状态异常，都未出于ready状态。
6.7 检查服务
[root@node1 ~]# systemctl status atomic-openshift-node.service
[root@node2 ~]# systemctl status atomic-openshift-node.service
[root@node1 ~]# systemctl status docker
[root@node2 ~]# systemctl status docker
结论：由上可知，node节点的docker异常。
6.8 启动服务
[root@node1 ~]# systemctl start docker
[root@node2 ~]# systemctl start docker
6.9 确认验证
[root@master ~]# oc get nodes #再次查看node状态
NAME STATUS ROLES AGE VERSION
master.lab.example.com Ready master 1d v1.9.1+a0ce1bc657
node1.lab.example.com Ready compute 1d v1.9.1+a0ce1bc657
node2.lab.example.com Ready compute 1d v1.9.1+a0ce1bc657
[student@workstation ~]$ oc get pods #确认pod是否正常调度至node
NAME READY STATUS RESTARTS AGE
hello-1-build 1/1 Running 0 22m
[student@workstation ~]$ oc describe is #查看is详情
结论：由上可知，IS也将image推送至内部仓库。
七 oc命令综合实验
7.1 前置准备
准备完整的OpenShift集群，参考《003.OpenShift网络》2.1。
7.2 本练习准备
[student@workstation ~]$ lab execute-review setup
7.3 git项目至本地
[student@workstation ~]$ cd /home/student/DO280/labs/execute-review/
[student@workstation execute-review]$ git clone http://services.lab.example.com/node-hello
7.4 docker构建image
[student@workstation execute-review]$ cd node-hello/
[student@workstation node-hello]$ docker build -t node-hello:latest .
[student@workstation node-hello]$ docker images #查看image
REPOSITORY TAG IMAGE ID CREATED SIZE
node-hello latest ff48daa00d8e 12 seconds ago 495 MB
registry.lab.example.com/rhscl/nodejs-6-rhel7 latest fba56b5381b7 22 months ago 489 MB
7.5 修改docker tag
[student@workstation node-hello]$ docker tag ff48daa00d8e \
> registry.lab.example.com/node-hello:latest
[student@workstation node-hello]$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
node-hello latest ff48daa00d8e About a minute ago 495 MB
registry.lab.example.com/node-hello latest ff48daa00d8e About a minute ago 495 MB
registry.lab.example.com/rhscl/nodejs-6-rhel7 latest fba56b5381b7 22 months ago 489 MB
7.6 push image
[student@workstation node-hello]$ docker push registry.lab.example.com/node-hello:latest
7.7 创建project
[student@workstation ~]$ oc login -u developer -p redhat \
> https://master.lab.example.com
[student@workstation ~]$ oc projects
[student@workstation ~]$ oc project execute-review
[student@workstation ~]$ oc new-app registry.lab.example.com/node-hello --name hello
[student@workstation ~]$ oc get all #查看全部资源
7.8 排查ImagePullBackOff
[student@workstation ~]$ oc logs hello-1-2jkkj #查看日志
Error from server (BadRequest): container "hello" in pod "hello-1-2jkkj" is waiting to start: trying and failing to pull image
[student@workstation ~]$ oc describe pod hello-1-2jkkj #查看详情
[student@workstation ~]$ oc get events --sort-by='.metadata.creationTimestamp' #查看事件
结论：由上可知，为image pull失败。
7.9 手动pull镜像
[student@workstation ~]$ oc get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
hello-1-2jkkj 0/1 ImagePullBackOff 0 8m 10.128.0.45 node1.lab.example.com
hello-1-deploy 1/1 Running 0 8m 10.129.0.72 node2.lab.example.com
[root@node1 ~]# docker pull registry.lab.example.com/node-hello #手动拉去也失败
Using default tag: latest
Trying to pull repository registry.lab.example.com/node-hello ...
All endpoints blocked.
结论：由上可知，所有endpoint都被阻塞了。这种类型的错误通常发生在OpenShift中，原因是不正确的部署配置或无效docker配置。
7.10 修正docker配置
[root@node1 ~]# vi /etc/sysconfig/docker
将BLOCK_REGISTRY='--block-registry registry.access.redhat.com --block-registry docker.io --block-registry registry.
lab.example.com'
修改为
BLOCK_REGISTRY='--block-registry registry.access.redhat.com --block-registry docker.io'
[root@node1 ~]# systemctl restart docker
提示：node2也需要如上操作。
7.11 更新pod
[student@workstation ~]$ oc rollout latest hello
[student@workstation ~]$ oc get pods #确认
NAME READY STATUS RESTARTS AGE
hello-1-deploy 0/1 Error 0 22m
hello-2-75x9t 1/1 Running 0 47s
7.12 确认验证
[student@workstation ~]$ oc logs hello-2-75x9t #查看log
nodejs server running on http://0.0.0.0:3000
7.13 暴露服务
[student@workstation ~]$ oc expose svc hello --hostname=hello.apps.lab.example.com
route "hello" exposed
7.14 测试服务
[student@workstation ~]$ curl http://hello.apps.lab.example.com
Hi! I am running on host -> hello-2-75x9t
[student@workstation ~]$ lab execute-review grade #脚本验证试验