007.OpenShift管理应用部署
一 REPLICATION CONTROLLERS
1.1 RC概述
RC确保pod指定数量的副本一直运行。如果pod被杀死或被管理员显式删除，复制控制器将自动部署相应的pod。类似地，如果运行的pod数量超过所需的数量，它会根据需要删除pod，以匹配指定的副本计数。
RC的定义主要包括:
- 所需的副本数量
- 用于创建复制pod的pod定义
- 用于标识后续管理操作的selector
selector是一组label，RC管理的所有pod都必须匹配这些标签。RC实例化的pod定义中必须包含相同的标签集。RC使用这个selector来确定已经运行了多少pod实例，以便根据需要进行调整。
提示：不执行自动缩放，因为它不跟踪负载或流量。
尽管Kubernetes通常直接管理RC，但OpenShift推荐的方法是管理根据需要创建或更改RC的DC。
1.2 从DC创建RC
在OpenShift中创建应用程序的最常见方法是使用oc new-app命令或web控制台。以这种方式创建的应用程序使用DeploymentConfig资源在运行时创建RC来创建应用程序pod。DeploymentConfig资源定义定义了要创建的pod的副本的数量，以及要创建的pod的模板。
注意：不要将DeploymentConfig或ReplicationController资源中的template属性误认为OpenShift模板资源类型，OpenShift模板资源用于基于一些常用的语言运行时和框架构建应用程序。
1.3 pod副本数控制
DeploymentConfig或ReplicationController资源中的副本数量可以使用oc scale命令动态更改。
$ oc get dc
NAME REVISION DESIRED CURRENT TRIGGERED BY
myapp 1 3 3 config,image(scaling:latest)
$ oc scale --replicas=5 dc myapp
DeploymentConfig资源将更改信息传递至ReplicationController，该控制器通过创建新的pod(副本)或删除现有的pod来响应更改。
虽然可以直接操作ReplicationController资源，但推荐的做法是操作DeploymentConfig资源。在触发部署时，直接对ReplicationController资源所做的更改可能会丢失，例如，使用容器image的新版本重新创建pod。
1.4 自动伸缩pod
OpenShift可以通过HorizontalPodAutoscaler资源类型根据应用程序pod上的当前负载自动调整部署配置。
HorizontalPodAutoscaler (HPA)资源使用OpenShift metrics子系统收集的性能指标，即如果没有度量子系统（模块），更确切地说是Heapster组件，自动缩放是不可能的。
创建HorizontalPodAutoscaler资源的推荐方法是使用oc autoscale命令，例如:
$ oc autoscale dc/myapp --min 1 --max 10 --cpu-percent=80
该命令创建一个HorizontalPodAutoscaler资源，该资源更改myapp部署配置上的副本数量，以将其pod的CPU使用量控制在请求的总CPU使用量的80%以下。
oc autoscale命令使用DC的名称作为参数(在前面的示例中是myapp)创建一个HorizontalPodAutoscaler资源。
HorizontalPodAutoscaler资源的最大值和最小值用于容纳突发负载，并避免重载OpenShift集群。如果应用程序上的负载变化太快，建议保留一些备用的pod来处理突然出现的用户请求。相反，过多的pod会耗尽所有集群容量，并影响共享相同OpenShift集群的其他应用程序。
要获取当前项目中关于HorizontalPodAutoscaler资源的信息，可使用oc get和oc describe命令。例如
$ oc get hpa/frontend
$ oc describe hpa/frontend
注意：HorizontalPodAutoscaler资源只适用于为引用性能指标定义资源请求的pod。
oc new-app命令创建的大多数pod没有定义任何资源请求。因此，使用OpenShift autoscaler可能需要为应用程序创建定制的YAML或JSON资源文件，或者向项目添加资源范围资源。
二 扩展程序实验
2.1 前置准备
准备完整的OpenShift集群，参考《003.OpenShift网络》2.1。
2.2 创建应用
[student@workstation ~]$ oc login -u developer -p redhat https://master.lab.example.com
[student@workstation ~]$ oc new-project scaling
[student@workstation ~]$ oc new-app -o yaml -i php:7.0 \
http://registry.lab.example.com/scaling > ~/scaling.yml #将部署的yaml导出至本地
[student@workstation ~]$ vi ~/scaling.yml
……
spec:
replicas: 3
selector:
app: scaling
deploymentconfig: scaling #修改副本数
……
[student@workstation ~]$ oc create -f ~/scaling.yml #以修改副本数后的yaml部署应用
2.3 监视部署
[student@workstation ~]$ watch -n 3 oc get builds
Every 3.0s: oc get builds Mon Jul 22 11:12:02 2019 NAME TYPE FROM STATUS STARTED DURATION
scaling-1 Source Git@0bdae71 Complete About a minute ago 1m0s
[student@workstation ~]$ oc get pods
NAME READY STATUS RESTARTS AGE
scaling-1-build 0/1 Completed 0 2m
scaling-1-ft249 1/1 Running 0 1m
scaling-1-gjvkp 1/1 Running 0 1m
scaling-1-mtrxr 1/1 Running 0 1m
2.4 暴露服务
[student@workstation ~]$ oc expose service scaling \
--hostname=scaling.apps.lab.example.com
2.5 web查看相关信息
浏览器访问https://master.lab.example.com，使用developer用户和redhat密码登陆。选择scaling项目。
2.6 测试负载均衡
[student@workstation ~]$ for i in {1..5};do curl -s \http://scaling.apps.lab.example.com | grep IP;done #多次请求
<br/> Server IP: 10.128.0.17
<br/> Server IP: 10.129.0.35
<br/> Server IP: 10.129.0.36
<br/> Server IP: 10.128.0.17
<br/> Server IP: 10.129.0.35
提示：浏览器可能无法严格检查均衡性，因为OpenShift route存在会话关联性(也称为粘性会话)。即来自同一个web浏览器的所有请求都将转到同一个pod。
2.7 扩容应用
[student@workstation ~]$ oc describe dc scaling | grep Replicas
Replicas: 3
Replicas: 3 current / 3 desired
[student@workstation ~]$ oc scale --replicas=5 dc scaling
[student@workstation ~]$ oc get pods -o wide
2.8 测试负载均衡
[student@workstation ~]$ for i in {1..5};do curl -s \http://scaling.apps.lab.example.com | grep IP;done #多次请求
<br/> Server IP: 10.128.0.17
<br/> Server IP: 10.128.0.18
<br/> Server IP: 10.129.0.35
<br/> Server IP: 10.129.0.36
<br/> Server IP: 10.129.0.37
三 pod调度控制
3.1 pod调度算法
pod调度程序确定新pod在OpenShift集群中的节点上的位置。该调度算法被设计为可高度配置和适应不同集群。OCP 3.9附带的默认配置通过使用node label、affinity rules，anti-affinity rules中的定义来支持zone和regions的调用。
在OCP以前的版本中，安装程序master节点标记为污点标记，表示不允许在master上部署pod。在新版的OCP 3.9中，在安装和升级过程中，master会自动标记为可调度的。使得可以通过deploy调度pod至maste节点。而不仅仅是作为master的组件运行。
默认节点selector是在安装和升级期间默认设置的。它被设置为node-role.kubernetes.io/compute=true，除非使用osm_default_node_selector的Ansible变量覆盖它。
在安装和升级期间，不管osm_default_node_selector配置如何，都会对库存文件中定义的主机执行以下自动标记。
compute节点配置non-master、non-dedicated的角色(默认情况下，具有region=infra标签的节点)，节点使用node-role.kubernetes.io/compute=true标记。
master节点被标记为node-role.kubernetes.io/master=true，从而分配master节点角色。
3.2 调度算法步骤
- 过滤节点
调度程序根据节点资源(如主机端口)的可用性筛选正在运行的节点列表，然后进一步根据节点selector和来自pod的资源请求筛选。最终的缩小是可运行pod的候选node列表。
pod可以定义与集群节点中的标签匹配的节点选择器，标签不匹配的节点视为不合格。
pod还可以为计算资源(如CPU、内存和存储)定义资源请求，没有足够的空闲计算机资源的节点视为不合格。
- 对过滤后的节点列表进行优先级排序
候选节点列表使用多个优先级标准进行评估，这些标准加起来就是权重，权重值较高的节点更适合运行pod。
其中有affinity（亲和规则）和anti-affinity（反亲和规则），pod亲和力较高的节点得分较高，而anti-affinity较高的节点权重低。
affinity的一个常见用法是：出于性能原因，将相关的pod安排得彼此亲和。例如，需要保持彼此同步的pod使用相同的网络栈。
anti-affinity的一个常见用法是：为了获得高可用性，将相关的pod安排的尽量分散。例如，避免将所有pod从同一个应用程序调度到同一个节点。
- 选择最合适的节点。
根据权重对候选列表进行排序，并选择权重最高的节点来承载pod。如果多个节点得分相同，则随机选择一个节点。
调度程序配置文件位于/etc/original/master/scheduler.json，其定义了一组predicates，用作过滤器或优先级函数。通过这种方式，可以将调度程序配置为支持不同的集群。
3.3 调度拓扑
对于大型数据中心，例如云提供商，一个常见的拓扑结构是将主机组织成regions和zones：
region：是一个地理区域内的一组主机，这保证了它们之间的内网高速连接；
zone：也称为可用区，是一组主机，它们可能一起失败，因为它们共享公共的关键基础设施组件，比如网络、存储或电源。
OpenShift pod调度器可支持根据region和zone标签在集群内调度，如：
- 从相同的RC创建的或从相同的DC创建的pod副本调度至具有相同region标签值的节点中运行。
- 副本Pod调位至具有不同zone标签的节点中运行。
实例图如下：
要实现上图中的样例拓扑，可以使用集群管理员通过以下命令oc label：
$ oc label node1 region=ZheJiang zone=Cloud1A --overwrite
$ oc label node node2 region=ZheJiang zone=Cloud1A --overwrite
$ oc label node node3 region=ZheJiang zone=Cloud2A --overwrite
$ oc label node node4 region=ZheJiang zone=Cloud2A --overwrite
$ oc label node node5 region=HuNan zone=Cloud1B --overwrite
$ oc label node node6 region=HuNan zone=Cloud1B --overwrite
$ oc label node node7 region=HuNan zone=Cloud2B --overwrite
$ oc label node node8 region=HuNan zone=Cloud2B --overwrite
提示：每个节点必须由其完全限定名(FQDN)标识，为了简洁，如上命令使用了简短的名称。
对区域标签的更改需要--overwrite选项，因为OCP 3.9高级安装方法默认情况下使用region=infra标签配置节点。
示例：要检查分配给节点的标签，可以使用oc get node命令和--show-labels选项。
$ oc get node node1.lab.example.com --show-labels
注意，一个节点可能有一些OpenShift分配的默认标签，包含kubernetes.io后缀键值的标签，此类标签不应由集群管理员人为更改，因为它们由调度程序在内部使用。
集群管理员还可以使用-L选项来确定单个标签的值。
示例：
$ oc get node node1.lab.example.com -L region
$ oc get node node1.lab.example.com -L region -L zone #支持oc get跟多个-L选项
3.4 UNSCHEDULABLE节点
有时候，集群管理员需要关闭节点进行维护，如节点可能需要硬件升级或内核安全更新。要在对OpenShift集群用户影响最小的情况下关闭节点，管理员应该遵循两个步骤。
将节点标记为不可调度，从而防止调度程序向节点分配新的pod。
$ oc adm manage-node --schedulable=false node2.lab.example.com
Drain节点，这将销毁在pod中运行的所有pod，并假设这些pod将通过DC在其他可用节点中会重新创建。
$ oc adm drain node2.lab.example.com
维护操作完成后，使用oc adm management -node命令将节点标记为可调度的。
$ oc adm manage-node --schedulable=true node2.lab.example.com
3.5 控制pod位置
有些应用程序可能需要在一组指定的node上运行。例如，某些节点为某些类型的工作负载提供硬件加速，或者集群管理员不希望将生产应用程序与开发应用程序混合使用。此类需求，都可以使用节点标签和节点选择器来实现。
node selector是pod定义的一部分，但建议更改dc，而不是pod级别的定义。要添加节点选择器，可使用oc edit命令或oc patch命令更改pod定义。
示例：配置myapp的dc，使其pods只在拥有env=qa标签的节点上运行。
$ oc patch dc myapp --patch '{"spec":{"template":{"nodeSelector":{"env":"qa"}}}}'
此更改将触发一个新的部署，并根据新的节点选择器调度新的pod。
如果集群管理员不希望让开发人员控制他们pod的节点选择器，那么应该在项目资源中配置一个默认的节点选择器。
3.5 管理默认项目
生产环境一个常见实践是指定一组节点来运行OCP的系统基础Pod，比如route和内部仓库。这些pod在默认项目中定义。
通常可通过以下两个步骤实现：
- 使用region=infra标签标记专用节点；
- 为缺省名称空间配置缺省节点选择器。
要配置项目的默认节点选择器，可使用openshift.io/node-selector键值向名称空间资源添加注释。可以使用oc edit或oc annotate命令。
$ oc annotate --overwrite namespace default \
openshift.io/node-selector='region=infra'
OCP 3.9 quick installer和advanced installer的Ansible playbook都支持Ansible变量，这些变量控制安装过程中分配给节点的标签，也控制分配给每个基础设施pod的节点选择器。
安装OCP子系统(如metrics子系统)的剧本还支持这些子系统节点选择器的变量。
四 控制Pod调度
4.1 前置准备
准备完整的OpenShift集群，参考《003.OpenShift网络》2.1。
4.2 本练习准备
[student@workstation ~]$ lab schedule-control setup
[student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com
4.3 查看region
[student@workstation ~]$ oc get nodes -L region
NAME STATUS ROLES AGE VERSION REGION
master.lab.example.com Ready master 2d v1.9.1+a0ce1bc657
node1.lab.example.com Ready compute 2d v1.9.1+a0ce1bc657 infra
node2.lab.example.com Ready compute 2d v1.9.1+a0ce1bc657 infra
4.4 创建project
[student@workstation ~]$ oc new-project schedule-control
4.5 创建应用
[student@workstation ~]$ oc new-app --name=hello \
--docker-image=registry.lab.example.com/openshift/hello-openshift
4.6 扩展应用
[student@workstation ~]$ oc scale dc hello --replicas=5
deploymentconfig "hello" scaled
[student@workstation ~]$ oc get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
hello-1-c5z2n 1/1 Running 0 7s 10.128.0.21 node1.lab.example.com
hello-1-hhvp7 1/1 Running 0 34s 10.129.0.38 node2.lab.example.com
hello-1-jqrkb 1/1 Running 0 7s 10.128.0.20 node1.lab.example.com
hello-1-tgmbr 1/1 Running 0 7s 10.129.0.39 node2.lab.example.com
hello-1-z2bn7 1/1 Running 0 7s 10.128.0.22 node1.lab.example.com
4.7 修改节点label
[student@workstation ~]$ oc label node node2.lab.example.com region=apps --overwrite=true
[student@workstation ~]$ oc get nodes -L region #确认修改
NAME STATUS ROLES AGE VERSION REGION
master.lab.example.com Ready master 2d v1.9.1+a0ce1bc657
node1.lab.example.com Ready compute 2d v1.9.1+a0ce1bc657 infra
node2.lab.example.com Ready compute 2d v1.9.1+a0ce1bc657 apps
4.8 导出dc
[student@workstation ~]$ oc get dc hello -o yaml > dc.yaml
4.9 修改node2调度策略
添加dc.yaml中的调度策略，使pod调度至apps标签的node。
[student@workstation ~]$ vi dc.yaml
……
template:
……
spec:
nodeSelector: #添加节点选择器
region: apps
……
4.10 应用更新
[student@workstation ~]$ oc apply -f dc.yaml
4.11 确认验证
[student@workstation ~]$ oc get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
hello-2-4c2gv 1/1 Running 0 40s 10.129.0.42 node2.lab.example.com
hello-2-6966b 1/1 Running 0 38s 10.129.0.43 node2.lab.example.com
hello-2-dcqbr 1/1 Running 0 36s 10.129.0.44 node2.lab.example.com
hello-2-dlf8k 1/1 Running 0 36s 10.129.0.45 node2.lab.example.com
hello-2-rnk4w 1/1 Running 0 40s 10.129.0.41 node2.lab.example.com
#验证是否触发了新的部署，并等待所有新的应用pod都准备好并运行。所有5个pod都应该调度至node2。
4.12 修改node1调度策略
[student@workstation ~]$ oc label node node1.lab.example.com region=apps --overwrite=true
[student@workstation ~]$ oc get node -L region
NAME STATUS ROLES AGE VERSION REGION
master.lab.example.com Ready master 2d v1.9.1+a0ce1bc657
node1.lab.example.com Ready compute 2d v1.9.1+a0ce1bc657 apps
node2.lab.example.com Ready compute 2d v1.9.1+a0ce1bc657 apps
4.13 终止node2
[student@workstation ~]$ oc adm manage-node --schedulable=false node2.lab.example.com
NAME STATUS ROLES AGE VERSION
node2.lab.example.com Ready,SchedulingDisabled compute 2d v1.9.1+a0ce1bc657
4.14 删除pod
删除node2的pod，并使用node1创建的pod替换。
[student@workstation ~]$ oc adm drain node2.lab.example.com --delete-local-data
4.15 查看pod
[student@workstation ~]$ oc get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
hello-2-bjsj4 1/1 Running 0 51s 10.128.0.25 node1.lab.example.com
hello-2-kmmmn 1/1 Running 0 50s 10.128.0.23 node1.lab.example.com
hello-2-n6wvj 1/1 Running 0 51s 10.128.0.24 node1.lab.example.com
hello-2-plr65 1/1 Running 0 50s 10.128.0.26 node1.lab.example.com
hello-2-xsz68 1/1 Running 0 51s 10.128.0.27 node1.lab.example.com
五 管理IS、image、Templates
5.1 image介绍
在OpenShift中，image是一个可部署的runtime模板，它包含运行单个容器的所有需求，还包括imag功能的元数据。image可以通过多种方式管理，如tag、import、pull和update。
image可以跨多个主机部署在多个容器中。开发人员可以使用Docker构建image，也可以使用OpenShift构建工具。
OpenShift实现了灵活的image管理机制。一个image名称实际上可以引用同一image的许多不同版本。唯一的image由它的sha256哈希引用，Docker不使用版本号。相反，它使用tag来管理image，例如v1、v2或默认的latest tag。
5.2 IS
IS包括由tags标识的任意数量的容器images。它是相关image的统一虚拟视图，类似于Docker image仓库。开发人员有许多与image和IS交互的方法。例如，当添加或修改新image时，build和deployment可以接收通知，并通过运行新build或新deployment做出相应的动作。
5.3 标记image
OCP提供了oc tag命令，它类似于docker tag命令，但是，它是对IS而不是image进行操作。
可以向image添加tag，以便更容易地确定它们包含什么。tag是指定image版本的标识符。
示例：将Apache web服务器2.4版本的映像，可将该image执行以下标记。
apache: 2.4
如果仓库包含Apache web服务器的最新版本，他们可以使用latest标签来表示这是仓库中可用的最新image。
apache:latest
oc tag命令用于标签image:
[user@demo ~]$ oc tag source destination
source：现有tag或图像流中的图像。
destination：标签在一个或多个IS中的最新image。
示例：将ruby image的现有latest标记修改为当前版本v2.0标识，
[user@demo ~]$ oc tag ruby:latest ruby:2.0
5.4 删除tag
若要从image中删除标记，可使用-d参数。
[user@demo ~]$ oc tag -d ruby:latest
可以使用不同类型的标签，默认行为使用permanent tag，即源文件发生更改，该tag也会及时指向image，与目标tag无关。
tracking tag指示在导入image期间导入目标tag的元数据。要确保目标tag在源tag更改时得到更新，需使用--alias=true标识。
[user@demo ~]$ oc tag --alias=true source destination
要重新导入tag，可使用--scheduled=true标识。
[user@demo ~]$ oc tag --scheduled=true source destination
要配置Docker始终从内部仓库中获取image，可使用--reference-policy=local标志。默认情况下，image指向本地仓库。从而实现在之后调用image的时候可以快速pull。
[user@demo ~]$ oc tag --reference-policy=local source destination
5.5 建议的tag形式
在管理tag时，开发人员应该考虑映像的生命周期，参考下表开发人员用来管理映像的可能的标记命名约定。
|
描述
|
示例
|
|
Revision
|
myimage:v2.0.1
|
|
Architecture
|
myimage:v2.0-x86_64
|
|
Base Image
|
myimage:v1.2-rhel7
|
|
Latest Image
|
myimage:latest
|
|
Latest Stable
|
Image myimage:stable
|
5.6 Templates介绍
模板描述一组对象，其中包含处理后生成对象列表的参数。可以处理模板来创建开发人员有权在项目中创建的任何内容，例如service、build、configuration和dc。
模板还可以定义一组标签，应用于它定义的每个对象。开发人员可以使用命令行界面或web控制台从模板创建对象列表。
5.7 Templates管理
开发人员可以用JSON或YAML格式编写模板，并使用命令行界面或web控制台导入它们。模板被保存到项目中，以供对该特定项目具有适当访问权限的任何用户重复使用。
示例：导入模板。
[user@demo ~]$ oc create -f filename
还可以在导入模板时分配标签，这意味着模板定义的所有对象都将被标记。
[user@demo ~]$ oc create -f filename -l name=mylabel
5.8 使用模板
OCP提供了许多默认的instant app和QuickStart模板，允许开发人员为不同的语言快速创建新的应用程序。为Rails (Ruby)、Django (Python)、Node.js、CakePHP (PHP)和Dancer (Perl)提供了模板。
要列出集群中的可用模板，请运行oc get templates命令。参数-n指定要使用的项目。
[user@demo ~]$ oc get templates -n openshift
开发人员还可以使用web控制台浏览模板，当您选择模板时，可以调整可用的参数来自定义模板定义的资源。
六 管理IS
6.1 前置准备
准备完整的OpenShift集群，参考《003.OpenShift网络》2.1。
6.2 本练习准备
[student@workstation ~]$ lab schedule-is setup
6.3 创建项目
[student@workstation ~]$ oc login -u developer -p redhat \
https://master.lab.example.com
[student@workstation ~]$ oc new-project schedule-is
6.4 创建应用
[student@workstation ~]$ oc new-app --name=phpmyadmin \
--docker-image=registry.lab.example.com/phpmyadmin/phpmyadmin:4.7
6.5 创建服务账户
[student@workstation ~]$ oc login -u admin -p redhat
[student@workstation ~]$ oc project schedule-is
[student@workstation ~]$ oc create serviceaccount phpmyadmin-account
6.6 授权特权运行
[student@workstation ~]$ oc adm policy add-scc-to-user anyuid \
-z phpmyadmin-account
6.7 更新pod
[student@workstation ~]$ oc login -u developer
[student@workstation ~]$ oc patch dc/phpmyadmin --patch \
'{"spec":{"template":{"spec":{"serviceAccountName": "phpmyadmin-account"}}}}'
更新负责管理phpmyadmin部署的dc资源，以便使用新创建的服务帐户。可以使用oc patch或oc edit命令。此命令可以从/home/student/DO280/labs/secure-review文件夹中的patch-dc.sh脚本中复制。
[student@workstation ~]$ oc get pods #确认验证
NAME READY STATUS RESTARTS AGE
phpmyadmin-2-vh29z 1/1 Running 0 3m
提示：name后的2表示这个pod是第二次部署，即进行过迭代。
6.8 更新内部仓库image
[student@workstation ~]$ cd /home/student/DO280/labs/schedule-is/
[student@workstation schedule-is]$ ls
phpmyadmin-latest.tar trust_internal_registry.sh
[student@workstation schedule-is]$ docker load -i phpmyadmin-latest.tar
#使用docker load命令加载新的image。
[student@workstation schedule-is]$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> 93d0d7db5ce2 13 months ago 166 MB
6.9 tag镜像
[student@workstation schedule-is]$ docker tag 93d0d7db5ce2 \
docker-registry-default.apps.lab.example.com/schedule-is/phpmyadmin:4.7
#打完标记进行推送。
6.10 登录docker仓库
结论：docker仓库会提示因为是自签名证书，因此判定为不安全的方式。
6.11 修改信任
本环境使用/home/student/DO280/labs/secure-review文件夹中的trust_internal_registry.sh脚本，配置docker仓库信任OpenShift内部仓库。
[student@workstation schedule-is]$ ./trust_internal_registry.sh
6.12 推送image
[student@workstation schedule-is]$ docker push \
docker-registry-default.apps.lab.example.com/schedule-is/phpmyadmin:4.7
6.13 确认更新
验证当源image更新后，是否能自动触发OpenShift进行pod更新。
[student@workstation schedule-is]$ oc get pods
NAME READY STATUS RESTARTS AGE
phpmyadmin-3-hnfjk 1/1 Running 0 23s
七 管理应用部署实验
7.1 前置准备
准备完整的OpenShift集群，参考《003.OpenShift网络》2.1。
7.2 本练习准备
[student@workstation ~]$ lab manage-review setup
7.3 确认region
[student@workstation ~]$ oc login -uadmin -predhat https://master.lab.example.com
[student@workstation ~]$ oc get nodes -L region
NAME STATUS ROLES AGE VERSION REGION
master.lab.example.com Ready master 2d v1.9.1+a0ce1bc657
node1.lab.example.com Ready compute 2d v1.9.1+a0ce1bc657 infra
node2.lab.example.com Ready compute 2d v1.9.1+a0ce1bc657 infra
7.4 修改region
[student@workstation ~]$ oc label node node1.lab.example.com region=services --overwrite=true
[student@workstation ~]$ oc label node node2.lab.example.com region=applications --overwrite=true
[student@workstation ~]$ oc get nodes -L region
NAME STATUS ROLES AGE VERSION REGION
master.lab.example.com Ready master 2d v1.9.1+a0ce1bc657
node1.lab.example.com Ready compute 2d v1.9.1+a0ce1bc657 services
node2.lab.example.com Ready compute 2d v1.9.1+a0ce1bc657 applications
7.5 创建项目
[student@workstation ~]$ oc new-project manage-review
7.6 创建应用
[student@workstation ~]$ oc new-app -i php:7.0 \
http://registry.lab.example.com/version
7.7 扩展应用
[student@workstation ~]$ oc scale dc version --replicas=3
[student@workstation ~]$ oc get pods -o wide #确认验证
NAME READY STATUS RESTARTS AGE IP NODE
version-1-9626w 1/1 Running 0 40s 10.129.0.55 node2.lab.example.com
version-1-build 0/1 Completed 0 1m 10.129.0.52 node2.lab.example.com
version-1-f6vj2 1/1 Running 0 40s 10.129.0.56 node2.lab.example.com
version-1-mrhk4 1/1 Running 0 45s 10.129.0.54 node2.lab.example.com
结论：应用程序pod并没有均分在两个集群node节点之间，因为每个节点属于不同的region，并且默认的OpenShift调度器配置打开了区域粘性。
7.8 调度pod
[student@workstation ~]$ oc export dc version -o yaml > version-dc.yml #导出yaml
spac
……
template:
metadata:
……
spec:
nodeSelector: #添加节点选择器
region: applications
……
7.9 迭代部署
[student@workstation ~]$ oc replace -f version-dc.yml #迭代
7.10 确认验证
[student@workstation ~]$ oc get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
version-1-build 0/1 Completed 0 15m 10.129.0.52 node2.lab.example.com
version-2-2bmqq 1/1 Running 0 58s 10.129.0.60 node2.lab.example.com
version-2-nz58r 1/1 Running 0 1m 10.129.0.59 node2.lab.example.com
version-2-rlj2h 1/1 Running 0 1m 10.129.0.58 node2.lab.example.com
验证是否启动了新的部署，并且在node2节点上运行了一组新的版本荚。等待所有三个新的应用程序荚都准备好并运行
7.11 修改region
[student@workstation ~]$ oc label node node1.lab.example.com region=applications --overwrite=true
[student@workstation ~]$ oc get nodes -L region #确认验证
NAME STATUS ROLES AGE VERSION REGION
master.lab.example.com Ready master 2d v1.9.1+a0ce1bc657
node1.lab.example.com Ready compute 2d v1.9.1+a0ce1bc657 applications
node2.lab.example.com Ready compute 2d v1.9.1+a0ce1bc657 applications
7.12 终止node2
[student@workstation ~]$ oc adm manage-node --schedulable=false node2.lab.example.com
NAME STATUS ROLES AGE VERSION
node2.lab.example.com Ready,SchedulingDisabled compute 2d v1.9.1+a0ce1bc657
7.13 删除pod
删除node2的pod，并使用node1创建的pod替换。
[student@workstation ~]$ oc adm drain node2.lab.example.com --delete-local-data
7.14 查看pod
[student@workstation ~]$ oc get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
version-2-d9fhp 1/1 Running 0 3m 10.128.0.34 node1.lab.example.com
version-2-jp5gr 1/1 Running 0 3m 10.128.0.35 node1.lab.example.com
version-2-z5lv5 1/1 Running 0 3m 10.128.0.33 node1.lab.example.com
7.15 暴露服务
[student@workstation ~]$ oc expose service version --hostname=version.apps.lab.example.com
[student@workstation ~]$ curl http://version.apps.lab.example.com #确认测试
<html>
<head>
<title>PHP Test</title>
</head>
<body>
<p>Version v1</p>
</body>
</html>
7.16 确认验证
[student@workstation ~]$ lab manage-review grade #环境脚本判断
7.17 还原环境
[student@workstation ~]$ oc adm manage-node --schedulable=true node2.lab.example.com
[student@workstation ~]$ oc label node node1.lab.example.com region=infra --overwrite=true
[student@workstation ~]$ oc label node node2.lab.example.com region=infra --overwrite=true
[student@workstation ~]$ oc get node -L region
NAME STATUS ROLES AGE VERSION REGION
master.lab.example.com Ready master 2d v1.9.1+a0ce1bc657
node1.lab.example.com Ready compute 2d v1.9.1+a0ce1bc657 infra
node2.lab.example.com Ready compute 2d v1.9.1+a0ce1bc657 infra
[student@workstation ~]$ oc delete project manage-review
007.OpenShift管理应用部署的更多相关文章
- 002.OpenShift安装与部署
一 前置条件说明 1.1 安装准备概述 Red Hat OpenShift容器平台是由Red Hat作为RPM包和容器映像两种类型存在.RPM包使用订阅管理器从标准Red Hat存储库(即Yum存储库 ...
- 009.OpenShift管理及监控
一 资源限制 1.1 pod资源限制 pod可以包括资源请求和资源限制: 资源请求 用于调度,并控制pod不能在计算资源少于指定数量的情况下运行.调度程序试图找到一个具有足够计算资源的节点来满足pod ...
- 使用tomcat manager 管理和部署项目
在部署tomcat项目的时候,除了把war文件直接拷贝到tomcat的webapp目录下,还有一种方法可以浏览器中管理和部署项目,那就是使用tomcat manager. 默认情况下,tomcat m ...
- VM Depot 新功能：直接通过 Windows Azure 管理门户部署虚拟机
发布于 2014-05-09 作者 陈 忠岳 想要尝试 VM Depot 上数以百计的各类开源虚拟机,却因为复杂的命令行操作而感到烦恼?微软开放技术想您所想,及时推出 VM Depot 最新功能 ...
- Mesos+Zookeeper+Marathon的Docker管理平台部署记录（2）- 负载均衡marathon-lb
之前介绍了Mesos+Zookeeper+Marathon的Docker管理平台部署记录(1)的操作,多余的废话不说了,下面接着说下在该集群环境下的负载均衡marathon-lb的部署过程: 默认情况 ...
- Mesos+Zookeeper+Marathon的Docker管理平台部署记录（1）
随着"互联网+"时代的业务增长.变化速度及大规模计算的需求,廉价的.高可扩展的分布式x86集群已成为标准解决方案,如Google已经在几千万台服务器上部署分布式系统.Docker及 ...
- 【Tomcat】使用tomcat manager 管理和部署项目，本地部署项目到服务器
在部署tomcat项目的时候,除了把war文件直接拷贝到tomcat的webapp目录下,还有一种方法可以浏览器中管理和部署项目,那就是使用tomcat manager. 默认情况下,tomcat m ...
- openshift 平台上部署 gitlab代码仓库服务
背景: 本文档将以在openshift 平台上部署 gitlab 服务来验证集群各个服务组件的可用性以及熟悉openshift的使用方法.服务部署方式可以多种多样,灵活部署.本篇以常见的镜像部署方式来 ...
- OPENSHIFT V3 免费部署 Java-Web
OpenShift是红帽的云开发平台即服务(PaaS).自由和开放源码的云计算平台使开发人员能够创建.测试和运行他们的应用程序,并且可以把它们部署到云中.Openshift广泛支持多种编程语言和框架, ...
随机推荐
- HTML开发实例-简单相亲网站开发（主体为table）
实现功能:简单的相亲网站: 清楚不常在,抓紧谈恋爱 我承诺 年满十八岁 单身 抱着严肃态度 寻找真诚的另一半 性别: 男 女 生日: --请选择年-- 2019 2020 2021 --请选择月-- ...
- python 比较常见的工具方法
下面是一些工作过程中比较常见的工具方法,但不代表最终答案.希望能对你有所帮助,如果您有更好更多的方法工具,欢迎推荐! 1. 按行读取带json字符串的文件 # -*- coding:utf-8 -*- ...
- 常用docker命令备忘录
查看镜像 docker images 查看运行中的容器 docker ps 删除镜像 docker rmi 容器id 直接删除所有镜像 docker rmi `docker images -q` 直接 ...
- Linux passwd 提权
利用条件,passwd 可写 ls -al /etc/passwd 利用方式: 生成密钥 openssl passwd -1 -salt test 123456 写入passwd echo 'tes ...
- Alpha冲刺 —— 5.2
这个作业属于哪个课程 软件工程 这个作业要求在哪里 团队作业第五次--Alpha冲刺 这个作业的目标 Alpha冲刺 作业正文 正文 github链接 项目地址 其他参考文献 无 一.会议内容 1.展 ...
- jchdl - GSL实例：FullAdder（使用HalfAdder实现）
https://mp.weixin.qq.com/s/5mcYAllizuxyr3QSNrotrw 全加器是能够计算低位进位的二进制加法电路.与半加器相比,全加器不只考虑本位计算结果是否有进位,也考虑 ...
- InnoSetup汉化版打包工具下载-附带脚本模板
InnoSetup汉化版打包工具下载地址: https://www.90pan.com/b1907264 脚本模板 ; 脚本用 Inno Setup 脚本向导 生成.; 查阅文档获取创建 INNO S ...
- Java实现 LeetCode 721 账户合并（并查集）
721. 账户合并 给定一个列表 accounts,每个元素 accounts[i] 是一个字符串列表,其中第一个元素 accounts[i][0] 是 名称 (name),其余元素是 emails ...
- Java实现 蓝桥杯 算法提高 周期字串
算法提高 周期字串 时间限制:1.0s 内存限制:256.0MB 问题描述 右右喜欢听故事,但是右右的妈妈总是讲一些"从前有座山,山里有座庙,庙里有个老和尚给小和尚讲故事,讲的什么呢?从前有 ...
- Java实现 蓝桥杯VIP 基础练习 芯片测试
问题描述 有n(2≤n≤20)块芯片,有好有坏,已知好芯片比坏芯片多. 每个芯片都能用来测试其他芯片.用好芯片测试其他芯片时,能正确给出被测试芯片是好还是坏.而用坏芯片测试其他芯片时,会随机给出好或是 ...