H5W3
当前位置:H5W3 > 其他技术问题 > 正文

007.OpenShiefc管理应用部署

一 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 创建应用

  1 [student@workstation ~]$ oc login -u developer -p redhat https://master.lab.example.com
  2 [student@workstation ~]$ oc new-project scaling
  3 [student@workstation ~]$ oc new-app -o yaml -i php:7.0 \
  4 http://registry.lab.example.com/scaling > ~/scaling.yml		#将部署的yaml导出至本地
  5 [student@workstation ~]$ vi ~/scaling.yml
  6 ……
  7   spec:
  8     replicas: 3
  9     selector:
 10       app: scaling
 11       deploymentconfig: scaling				#修改副本数
 12 ……
 13 [student@workstation ~]$ oc create -f ~/scaling.yml	#以修改副本数后的yaml部署应用
 

2.3 监视部署

  1 [student@workstation ~]$ watch -n 3 oc get builds
  2 Every 3.0s: oc get builds                                                                Mon Jul 22 11:12:02 2019
  3
  4 NAME        TYPE      FROM          STATUS     STARTED              DURATION
  5 scaling-1   Source    Git@0bdae71   Complete   About a minute ago   1m0s
  6 [student@workstation ~]$ oc get pods
  7 NAME              READY     STATUS      RESTARTS   AGE
  8 scaling-1-build   0/1       Completed   0          2m
  9 scaling-1-ft249   1/1       Running     0          1m
 10 scaling-1-gjvkp   1/1       Running     0          1m
 11 scaling-1-mtrxr   1/1       Running     0          1m
 

2.4 暴露服务

  1 [student@workstation ~]$ oc expose service scaling \
  2 --hostname=scaling.apps.lab.example.com
 

2.5 web查看相关信息

浏览器访问https://master.lab.example.com,使用developer用户和redhat密码登陆。选择scaling项目。
007.OpenShiefc管理应用部署
 
007.OpenShiefc管理应用部署

2.6 测试负载均衡

  1 [student@workstation ~]$ for i in {1..5};do curl -s \http://scaling.apps.lab.example.com | grep IP;done	#多次请求
  2  <br/> Server IP: 10.128.0.17
  3  <br/> Server IP: 10.129.0.35
  4  <br/> Server IP: 10.129.0.36
  5  <br/> Server IP: 10.128.0.17
  6  <br/> Server IP: 10.129.0.35
 
提示:浏览器可能无法严格检查均衡性,因为OpenShift route存在会话关联性(也称为粘性会话)。即来自同一个web浏览器的所有请求都将转到同一个pod。

2.7 扩容应用

  1 [student@workstation ~]$ oc describe dc scaling | grep Replicas
  2 Replicas:       3
  3         Replicas:       3 current / 3 desired
  4 [student@workstation ~]$ oc scale --replicas=5 dc scaling
 
007.OpenShiefc管理应用部署
  1 [student@workstation ~]$ oc get pods -o wide
007.OpenShiefc管理应用部署

2.8 测试负载均衡

  1 [student@workstation ~]$ for i in {1..5};do curl -s \http://scaling.apps.lab.example.com | grep IP;done	#多次请求
  2  <br/> Server IP: 10.128.0.17
  3  <br/> Server IP: 10.128.0.18
  4  <br/> Server IP: 10.129.0.35
  5  <br/> Server IP: 10.129.0.36
  6  <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标签的节点中运行。
    实例图如下:
    007.OpenShiefc管理应用部署
    要实现上图中的样例拓扑,可以使用集群管理员通过以下命令oc label:
      1 $ oc label node1 region=ZheJiang zone=Cloud1A --overwrite
      2 $ oc label node node2 region=ZheJiang zone=Cloud1A --overwrite
      3 $ oc label node node3 region=ZheJiang zone=Cloud2A --overwrite
      4 $ oc label node node4 region=ZheJiang zone=Cloud2A --overwrite
      5 $ oc label node node5 region=HuNan zone=Cloud1B --overwrite
      6 $ oc label node node6 region=HuNan zone=Cloud1B --overwrite
      7 $ oc label node node7 region=HuNan zone=Cloud2B --overwrite
      8 $ 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选项来确定单个标签的值。
    示例:
      1 $ oc get node node1.lab.example.com -L region
      2 $ oc get node node1.lab.example.com -L region -L zone	#支持oc get跟多个-L选项
     

    3.4 UNSCHEDULABLE节点

    有时候,集群管理员需要关闭节点进行维护,如节点可能需要硬件升级或内核安全更新。要在对OpenShift集群用户影响最小的情况下关闭节点,管理员应该遵循两个步骤。
    将节点标记为不可调度,从而防止调度程序向节点分配新的pod。
      1 $ oc adm manage-node --schedulable=false node2.lab.example.com
    Drain节点,这将销毁在pod中运行的所有pod,并假设这些pod将通过DC在其他可用节点中会重新创建。
      1 $ oc adm drain node2.lab.example.com
    维护操作完成后,使用oc adm management -node命令将节点标记为可调度的。
      1 $ 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标签的节点上运行。
      1 $ oc patch dc myapp --patch '{"spec":{"template":{"nodeSelector":{"env":"qa"}}}}'
    此更改将触发一个新的部署,并根据新的节点选择器调度新的pod。
    如果集群管理员不希望让开发人员控制他们pod的节点选择器,那么应该在项目资源中配置一个默认的节点选择器。

    3.5 管理默认项目

    生产环境一个常见实践是指定一组节点来运行OCP的系统基础Pod,比如route和内部仓库。这些pod在默认项目中定义。
    通常可通过以下两个步骤实现:
    1. 使用region=infra标签标记专用节点;
    2. 为缺省名称空间配置缺省节点选择器。
    要配置项目的默认节点选择器,可使用openshift.io/node-selector键值向名称空间资源添加注释。可以使用oc edit或oc annotate命令。
      1 $ oc annotate --overwrite namespace default \
      2 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 本练习准备

      1 [student@workstation ~]$ lab schedule-control setup
      2 [student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com
     

    4.3 查看region

      1 [student@workstation ~]$ oc get nodes -L region
      2 NAME                     STATUS    ROLES     AGE       VERSION             REGION
      3 master.lab.example.com   Ready     master    2d        v1.9.1+a0ce1bc657
      4 node1.lab.example.com    Ready     compute   2d        v1.9.1+a0ce1bc657   infra
      5 node2.lab.example.com    Ready     compute   2d        v1.9.1+a0ce1bc657   infra
     

    4.4 创建project

      1 [student@workstation ~]$ oc new-project schedule-control

    4.5 创建应用

      1 [student@workstation ~]$ oc new-app --name=hello \
      2 --docker-image=registry.lab.example.com/openshift/hello-openshift
     

    4.6 扩展应用

      1 [student@workstation ~]$ oc scale dc hello --replicas=5
      2 deploymentconfig "hello" scaled
      3 [student@workstation ~]$ oc get pod -o wide
      4 NAME            READY     STATUS    RESTARTS   AGE       IP            NODE
      5 hello-1-c5z2n   1/1       Running   0          7s        10.128.0.21   node1.lab.example.com
      6 hello-1-hhvp7   1/1       Running   0          34s       10.129.0.38   node2.lab.example.com
      7 hello-1-jqrkb   1/1       Running   0          7s        10.128.0.20   node1.lab.example.com
      8 hello-1-tgmbr   1/1       Running   0          7s        10.129.0.39   node2.lab.example.com
      9 hello-1-z2bn7   1/1       Running   0          7s        10.128.0.22   node1.lab.example.com
     

    4.7 修改节点label

      1 [student@workstation ~]$ oc label node node2.lab.example.com region=apps --overwrite=true
      2 [student@workstation ~]$ oc get nodes -L region		#确认修改
      3 NAME                     STATUS    ROLES     AGE       VERSION             REGION
      4 master.lab.example.com   Ready     master    2d        v1.9.1+a0ce1bc657
      5 node1.lab.example.com    Ready     compute   2d        v1.9.1+a0ce1bc657   infra
      6 node2.lab.example.com    Ready     compute   2d        v1.9.1+a0ce1bc657   apps
     

    4.8 导出dc

      1 [student@workstation ~]$ oc get dc hello -o yaml > dc.yaml

    4.9 修改node2调度策略

    添加dc.yaml中的调度策略,使pod调度至apps标签的node。
      1 [student@workstation ~]$ vi dc.yaml
      2 ……
      3   template:
      4 ……
      5     spec:
      6       nodeSelector:		#添加节点选择器
      7         region: apps
      8 ……
     

    4.10 应用更新

      1 [student@workstation ~]$ oc apply -f dc.yaml

    4.11 确认验证

      1 [student@workstation ~]$ oc get pod -o wide
      2 NAME            READY     STATUS    RESTARTS   AGE       IP            NODE
      3 hello-2-4c2gv   1/1       Running   0          40s       10.129.0.42   node2.lab.example.com
      4 hello-2-6966b   1/1       Running   0          38s       10.129.0.43   node2.lab.example.com
      5 hello-2-dcqbr   1/1       Running   0          36s       10.129.0.44   node2.lab.example.com
      6 hello-2-dlf8k   1/1       Running   0          36s       10.129.0.45   node2.lab.example.com
      7 hello-2-rnk4w   1/1       Running   0          40s       10.129.0.41   node2.lab.example.com
     
    #验证是否触发了新的部署,并等待所有新的应用pod都准备好并运行。所有5个pod都应该调度至node2。

    4.12 修改node1调度策略

      1 [student@workstation ~]$ oc label node node1.lab.example.com region=apps --overwrite=true
      2 [student@workstation ~]$ oc get node -L region
      3 NAME                     STATUS    ROLES     AGE       VERSION             REGION
      4 master.lab.example.com   Ready     master    2d        v1.9.1+a0ce1bc657
      5 node1.lab.example.com    Ready     compute   2d        v1.9.1+a0ce1bc657   apps
      6 node2.lab.example.com    Ready     compute   2d        v1.9.1+a0ce1bc657   apps
     

    4.13 终止node2

      1 [student@workstation ~]$ oc adm manage-node --schedulable=false node2.lab.example.com
      2 NAME                    STATUS                     ROLES     AGE       VERSION
      3 node2.lab.example.com   Ready,SchedulingDisabled   compute   2d        v1.9.1+a0ce1bc657
     

    4.14 删除pod

    删除node2的pod,并使用node1创建的pod替换。
      1 [student@workstation ~]$ oc adm drain node2.lab.example.com --delete-local-data

    4.15 查看pod

      1 [student@workstation ~]$ oc get pods -o wide
      2 NAME            READY     STATUS    RESTARTS   AGE       IP            NODE
      3 hello-2-bjsj4   1/1       Running   0          51s       10.128.0.25   node1.lab.example.com
      4 hello-2-kmmmn   1/1       Running   0          50s       10.128.0.23   node1.lab.example.com
      5 hello-2-n6wvj   1/1       Running   0          51s       10.128.0.24   node1.lab.example.com
      6 hello-2-plr65   1/1       Running   0          50s       10.128.0.26   node1.lab.example.com
      7 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 本练习准备

      1 [student@workstation ~]$ lab schedule-is setup

    6.3 创建项目

      1 [student@workstation ~]$ oc login -u developer -p redhat \
      2 https://master.lab.example.com
      3 [student@workstation ~]$ oc new-project schedule-is
     

    6.4 创建应用

      1 [student@workstation ~]$ oc new-app --name=phpmyadmin \
      2 --docker-image=registry.lab.example.com/phpmyadmin/phpmyadmin:4.7
     

    6.5 创建服务账户

      1 [student@workstation ~]$ oc login -u admin -p redhat
      2 [student@workstation ~]$ oc project schedule-is
      3 [student@workstation ~]$ oc create serviceaccount phpmyadmin-account
     

    6.6 授权特权运行

      1 [student@workstation ~]$ oc adm policy add-scc-to-user anyuid \
      2 -z phpmyadmin-account
     

    6.7 更新pod

      1 [student@workstation ~]$ oc login -u developer
      2 [student@workstation ~]$ oc patch dc/phpmyadmin --patch \
      3 '{"spec":{"template":{"spec":{"serviceAccountName": "phpmyadmin-account"}}}}'
     
    更新负责管理phpmyadmin部署的dc资源,以便使用新创建的服务帐户。可以使用oc patch或oc edit命令。此命令可以从/home/student/DO280/labs/secure-review文件夹中的patch-dc.sh脚本中复制。
      1 [student@workstation ~]$ oc get pods		#确认验证
      2 NAME                 READY     STATUS    RESTARTS   AGE
      3 phpmyadmin-2-vh29z   1/1       Running   0          3m
     
    提示:name后的2表示这个pod是第二次部署,即进行过迭代。

    6.8 更新内部仓库image

      1 [student@workstation ~]$ cd /home/student/DO280/labs/schedule-is/
      2 [student@workstation schedule-is]$ ls
      3 phpmyadmin-latest.tar  trust_internal_registry.sh
      4 [student@workstation schedule-is]$ docker load -i phpmyadmin-latest.tar
      5 #使用docker load命令加载新的image。
      6 [student@workstation schedule-is]$ docker images
      7 REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
      8 <none>              <none>              93d0d7db5ce2        13 months ago       166 MB
     

    6.9 tag镜像

      1 [student@workstation schedule-is]$ docker tag 93d0d7db5ce2 \
      2 docker-registry-default.apps.lab.example.com/schedule-is/phpmyadmin:4.7
      3 #打完标记进行推送。
     

    6.10 登录docker仓库

    007.OpenShiefc管理应用部署
    结论:docker仓库会提示因为是自签名证书,因此判定为不安全的方式。

    6.11 修改信任

    本环境使用/home/student/DO280/labs/secure-review文件夹中的trust_internal_registry.sh脚本,配置docker仓库信任OpenShift内部仓库。
      1 [student@workstation schedule-is]$ ./trust_internal_registry.sh

    6.12 推送image

      1 [student@workstation schedule-is]$ docker push \
      2 docker-registry-default.apps.lab.example.com/schedule-is/phpmyadmin:4.7
     

    6.13 确认更新

    验证当源image更新后,是否能自动触发OpenShift进行pod更新。
      1 [student@workstation schedule-is]$ oc get pods
      2 NAME                 READY     STATUS    RESTARTS   AGE
      3 phpmyadmin-3-hnfjk   1/1       Running   0          23s
     

    七 管理应用部署实验

    7.1 前置准备

    准备完整的OpenShift集群,参考《003.OpenShift网络》2.1。

    7.2 本练习准备

      1 [student@workstation ~]$ lab manage-review setup

    7.3 确认region

      1 [student@workstation ~]$ oc login -uadmin -predhat https://master.lab.example.com
      2 [student@workstation ~]$ oc get nodes -L region
      3 NAME                     STATUS    ROLES     AGE       VERSION             REGION
      4 master.lab.example.com   Ready     master    2d        v1.9.1+a0ce1bc657
      5 node1.lab.example.com    Ready     compute   2d        v1.9.1+a0ce1bc657   infra
      6 node2.lab.example.com    Ready     compute   2d        v1.9.1+a0ce1bc657   infra
     

    7.4 修改region

      1 [student@workstation ~]$ oc label node node1.lab.example.com region=services --overwrite=true
      2 [student@workstation ~]$ oc label node node2.lab.example.com region=applications --overwrite=true
      3 [student@workstation ~]$ oc get nodes -L region
      4 NAME                     STATUS    ROLES     AGE       VERSION             REGION
      5 master.lab.example.com   Ready     master    2d        v1.9.1+a0ce1bc657
      6 node1.lab.example.com    Ready     compute   2d        v1.9.1+a0ce1bc657   services
      7 node2.lab.example.com    Ready     compute   2d        v1.9.1+a0ce1bc657   applications
     

    7.5 创建项目

      1 [student@workstation ~]$ oc new-project manage-review

    7.6 创建应用

      1 [student@workstation ~]$ oc new-app -i php:7.0 \
      2 http://registry.lab.example.com/version
     

    7.7 扩展应用

      1 [student@workstation ~]$ oc scale dc version --replicas=3
      2 [student@workstation ~]$ oc get pods -o wide		#确认验证
      3 NAME              READY     STATUS      RESTARTS   AGE       IP            NODE
      4 version-1-9626w   1/1       Running     0          40s       10.129.0.55   node2.lab.example.com
      5 version-1-build   0/1       Completed   0          1m        10.129.0.52   node2.lab.example.com
      6 version-1-f6vj2   1/1       Running     0          40s       10.129.0.56   node2.lab.example.com
      7 version-1-mrhk4   1/1       Running     0          45s       10.129.0.54   node2.lab.example.com
     
    结论:应用程序pod并没有均分在两个集群node节点之间,因为每个节点属于不同的region,并且默认的OpenShift调度器配置打开了区域粘性。

    7.8 调度pod

      1 [student@workstation ~]$ oc export dc version -o yaml > version-dc.yml	#导出yaml
      2 spac
      3 ……
      4   template:
      5     metadata:
      6 ……
      7     spec:
      8       nodeSelector:		#添加节点选择器
      9         region: applications
     10 ……
     

    7.9 迭代部署

      1 [student@workstation ~]$ oc replace -f version-dc.yml	#迭代

    7.10 确认验证

      1 [student@workstation ~]$ oc get pod -o wide
      2 NAME              READY     STATUS      RESTARTS   AGE       IP            NODE
      3 version-1-build   0/1       Completed   0          15m       10.129.0.52   node2.lab.example.com
      4 version-2-2bmqq   1/1       Running     0          58s       10.129.0.60   node2.lab.example.com
      5 version-2-nz58r   1/1       Running     0          1m        10.129.0.59   node2.lab.example.com
      6 version-2-rlj2h   1/1       Running     0          1m        10.129.0.58   node2.lab.example.com
     
    验证是否启动了新的部署,并且在node2节点上运行了一组新的版本荚。等待所有三个新的应用程序荚都准备好并运行

    7.11 修改region

      1 [student@workstation ~]$ oc label node node1.lab.example.com region=applications --overwrite=true
      2 [student@workstation ~]$ oc get nodes -L region		#确认验证
      3 NAME                     STATUS    ROLES     AGE       VERSION             REGION
      4 master.lab.example.com   Ready     master    2d        v1.9.1+a0ce1bc657
      5 node1.lab.example.com    Ready     compute   2d        v1.9.1+a0ce1bc657   applications
      6 node2.lab.example.com    Ready     compute   2d        v1.9.1+a0ce1bc657   applications
     

    7.12 终止node2

      1 [student@workstation ~]$ oc adm manage-node --schedulable=false node2.lab.example.com
      2 NAME                    STATUS                     ROLES     AGE       VERSION
      3 node2.lab.example.com   Ready,SchedulingDisabled   compute   2d        v1.9.1+a0ce1bc657
     

    7.13 删除pod

    删除node2的pod,并使用node1创建的pod替换。
      1 [student@workstation ~]$ oc adm drain node2.lab.example.com --delete-local-data

    7.14 查看pod

      1 [student@workstation ~]$ oc get pods -o wide
      2 NAME              READY     STATUS    RESTARTS   AGE       IP            NODE
      3 version-2-d9fhp   1/1       Running   0          3m        10.128.0.34   node1.lab.example.com
      4 version-2-jp5gr   1/1       Running   0          3m        10.128.0.35   node1.lab.example.com
      5 version-2-z5lv5   1/1       Running   0          3m        10.128.0.33   node1.lab.example.com
     

    7.15 暴露服务

      1 [student@workstation ~]$ oc expose service version --hostname=version.apps.lab.example.com
      2 [student@workstation ~]$ curl http://version.apps.lab.example.com	#确认测试
      3 <html>
      4  <head>
      5   <title>PHP Test</title>
      6  </head>
      7  <body>
      8  <p>Version v1</p>
      9  </body>
     10 </html>
     

    7.16 确认验证

      1 [student@workstation ~]$ lab manage-review grade	#环境脚本判断

    7.17 还原环境

      1 [student@workstation ~]$ oc adm manage-node --schedulable=true node2.lab.example.com
      2 [student@workstation ~]$ oc label node node1.lab.example.com region=infra --overwrite=true
      3 [student@workstation ~]$ oc label node node2.lab.example.com region=infra --overwrite=true
      4 [student@workstation ~]$ oc get node -L region
      5 NAME                     STATUS    ROLES     AGE       VERSION             REGION
      6 master.lab.example.com   Ready     master    2d        v1.9.1+a0ce1bc657
      7 node1.lab.example.com    Ready     compute   2d        v1.9.1+a0ce1bc657   infra
      8 node2.lab.example.com    Ready     compute   2d        v1.9.1+a0ce1bc657   infra
      9 [student@workstation ~]$ oc delete project manage-review
     

    未经允许不得转载:H5W3 » 007.OpenShiefc管理应用部署

    赞 (0)

    评论 0

    • 昵称 (必填)
    • 邮箱 (必填)
    • 网址