一 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專案。
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 排程演算法步驟
- 過濾節點
排程程式根據節點資源(如主機埠)的可用性篩選正在執行的節點列表，然後進一步根據節點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：
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標籤標記專用節點；
- 為預設名稱空間配置預設節點選擇器。
要配置專案的預設節點選擇器，可使用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時，開發人員應該考慮映像的生命週期，參考下表開發人員用來管理映像的可能的標記命名約定。
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倉庫
結論：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