一 REPLICATION CONTROLLERS
1.1 RC概述
RC確保pod指定數量的副本一直運行，如果pod被殺死或被管理員顯式洗掉，復制控制器將自動部署相應的pod，類似地，如果運行的pod數量超過所需的數量，它會根據需要洗掉pod，以匹配指定的副本計數， RC的定義主要包括:- 所需的副本數量
- 用于創建復制pod的pod定義
- 用于標識后續管理操作的selector
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專案，
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
1 [student@workstation ~]$ oc get pods -o wide
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 調度演算法步驟
- 過濾節點
- 對過濾后的節點串列進行優先級排序
- 選擇最合適的節點，
3.3 調度拓撲
對于大型資料中心，例如云提供商，一個常見的拓撲結構是將主機組織成regions和zones： region：是一個地理區域內的一組主機，這保證了它們之間的內網高速連接； zone：也稱為可用區，是一組主機，它們可能一起失敗，因為它們共享公共的關鍵基礎設施組件，比如網路、存盤或電源， OpenShift pod調度器可支持根據region和zone標簽在集群內調度，如：- 從相同的RC創建的或從相同的DC創建的pod副本調度至具有相同region標簽值的節點中運行，
- 副本Pod調位至具有不同zone標簽的節點中運行，
要實作上圖中的樣例拓撲，可以使用集群管理員通過以下命令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在默認專案中定義， 通常可通過以下兩個步驟實作：- 使用region=infra標簽標記專用節點；
- 為預設名稱空間配置預設節點選擇器，
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.05.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 destination5.5 建議的tag形式
在管理tag時，開發人員應該考慮映像的生命周期，參考下表開發人員用來管理映像的可能的標記命名約定，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=mylabel5.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倉庫
結論：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
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/49266.html
標籤：Linux