一 REPLICATION CONTROLLERS 1.1 RC概述 RC確保pod指定數量的副本一直運行。如果pod被殺死或被管理員顯式刪除，複製控制器將自動部署相應的pod。類似地，如果運行的pod數量超過所需的數量，它會根據需要刪除pod，以匹配指定的副本計數。 RC的定義主要包括: 所需的副 ...
一 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
