009.OpenShift管理及監控

来源:https://www.cnblogs.com/itzgr/archive/2020/06/22/13179348.html
-Advertisement-
Play Games

一 資源限制1.1 pod資源限制pod可以包括資源請求和資源限制:資源請求用於調度，並控制pod不能在計算資源少於指定數量的情況下運行。調度程式試圖找到一個具有足夠計算資源的節點來滿足pod請求。資源限制用於防止pod耗盡節點的所有計算資源，基於pod的節點配置Linux內核cgroups特性，以 ...


一 資源限制

1.1 pod資源限制

pod可以包括資源請求和資源限制:

  • 資源請求

用於調度，並控制pod不能在計算資源少於指定數量的情況下運行。調度程式試圖找到一個具有足夠計算資源的節點來滿足pod請求。

  • 資源限制

用於防止pod耗盡節點的所有計算資源，基於pod的節點配置Linux內核cgroups特性，以執行pod的資源限制。

儘管資源請求和資源限制是pod定義的一部分，但通常建議在dc中設置。OpenShift推薦的實踐規定，不應該單獨創建pod，而應該由dc創建。

1.2 應用配額

OCP可以執行跟蹤和限制兩種資源使用的配額:

對象的數量：Kubernetes資源的數量，如pod、service和route。

計算資源：物理或虛擬硬體資源的數量，如CPU、記憶體和存儲容量。

通過避免master的Etcd資料庫的無限制增長，對Kubernetes資源的數量設置配額有助於OpenShift master伺服器的穩定性。對Kubernetes資源設置配額還可以避免耗盡其他有限的軟體資源，比如服務的IP地址。

同樣，對計算資源的數量施加配額可以避免耗盡OpenShift集群中單個節點的計算能力。還避免了一個應用程式使用所有集群容量，從而影響共用集群的其他應用程式。

OpenShift通過使用ResourceQuota對象或簡單的quota來管理對象使用的配額及計算資源。

ResourceQuota對象指定項目的硬資源使用限制。配額的所有屬性都是可選的，這意味著任何不受配額限制的資源都可以無限制地使用。

註意：一個項目可以包含多個ResourceQuota對象，其效果是累積的，但是對於同一個項目，兩個不同的 ResourceQuota 不會試圖限制相同類型的對象或計算資源。

1.3 ResourceQuota限制資源

下表顯示 ResourceQuota 可以限制的主要對象和計算資源：

對象名 描述
pods 總計的pod數量
replicationcontrollers 總計的rc數量
services 總計的service數量
secrets 總計的secret數量

persistentvolumeclaims 		總計的pvc數量
cpu 所有容器的CPU使用總量
memory 所有容器的總記憶體使用
storage 所有容器的磁碟總使用量
Quota屬性可以跟蹤項目中所有pod的資源請求或資源限制。預設情況下，配額屬性跟蹤資源請求。要跟蹤資源限制，可以在計算資源名稱前面加上限制，例如limit.cpu。

示例一：使用YAML語法定義的ResourceQuota資源，它為對象計數和計算資源指定了配額：

  1 $ cat
  2 apiVersion: v1
  3 kind: ResourceQuota
  4 metadata:
  5   name: dev-quota
  6 spec:
  7   hard:
  8     services: "10"
  9     cpu: "1300m"
 10     memory: "1.5Gi"
 11 $ oc create -f dev-quota.yml

示例二：使用oc create quota命令創建：

  1 $ oc create quota dev-quota \
  2 --hard=services=10 \
  3 --hard=cpu=1300m \
  4 --hard=memory=1.5Gi
  5 $ oc get resourcequota				#列出可用的配額
  6 $ oc describe resourcequota NAME		#查看與配額中定義的任何與限制相關的統計信息
  7 $ oc delete resourcequota compute-quota		#按名稱刪除活動配額

提示：若oc describe resourcequota命令不帶參數，只顯示項目中所有resourcequota對象的累積限制集，而不顯示哪個對象定義了哪個限制。

當在項目中首次創建配額時，項目將限制創建任何可能超出配額約束的新資源的能力，然後重新計算資源使用情況。在創建配額和使用數據統計更新之後，項目接受新內容的創建。當創建新資源時，配額使用量立即增加。當一個資源被刪除時，在下一次對項目的 quota 統計數據進行全面重新計算時，配額使用將減少。

ResourceQuota 應用於整個項目，但許多 OpenShift 過程，例如 build 和 deployment，在項目中創建 pod，可能會失敗，因為啟動它們將超過項目 quota。

如果對項目的修改超過了對象數量的 quota，則伺服器將拒絕操作，並向用戶返回錯誤消息。但如果修改超出了計算資源的quota，則操作不會立即失敗。OpenShift 將重試該操作幾次，使管理員有機會增加配額或執行糾正操作，比如上線新節點，擴容節點資源。

註意：如果設置了計算資源的 quota，OpenShift 拒絕創建不指定該計算資源的資源請求或資源限制的pod。

1.3 應用限制範圍

LimitRange資源，也稱為limit，定義了計算資源請求的預設值、最小值和最大值，以及項目中定義的單個pod或單個容器的限制，pod的資源請求或限制是其容器的總和。

要理解limit rang和resource quota之間的區別，limit rang為單個pod定義了有效範圍和預設值，而resource quota僅為項目中所有pod的和定義了最高值。

通常可同時定義項目的限制和配額。

LimitRange資源還可以為image、is或pvc的存儲容量定義預設值、最小值和最大值。如果添加到項目中的資源不提供計算資源請求，那麼它將接受項目的limit ranges提供的預設值。如果新資源提供的計算資源請求或限制小於項目的limit range指定的最小值，則不創建該資源。同樣，如果新資源提供的計算資源請求或限制高於項目的limit range所指定的最大值，則不會創建該資源。

OpenShift 提供的大多數標準 S2I builder image 和 templabe 都沒有指定。要使用受配額限制的 template 和 builder，項目需要包含一個 limit range 對象，該對象為容器資源請求指定預設值。

如下為描述了一些可以由LimitRange對象指定的計算資源。

類型 資源名稱 描述

Container 		cpu 每個容器允許的最小和最大CPU。

Container 		memory 每個容器允許的最小和最大記憶體
Pod cpu 一個pod中所有容器允許的最小和最大CPU
Pod memory 一個pod中所有容器允許的最小和最大記憶體
Image storage 可以推送到內部倉庫的圖像的最大大小
PVC storage 一個pvc的容量的最小和最大容量

示例一：limit rang的yaml示例：

  1 $ cat dev-limits.yml
  2 apiVersion: "v1"
  3 kind: "LimitRange"
  4 metadata:
  5   name: "dev-limits"
  6 spec:
  7   limits:
  8     - type: "Pod"
  9       max:
 10         cpu: "2"
 11         memory: "1Gi"
 12       min:
 13         cpu: "200m"
 14         memory: "6Mi"
 15     - type: "Container"
 16       default:
 17         cpu: "1"
 18         memory: "512Mi"
 19 $ oc create -f dev-limits.yml
 20 $ oc describe limitranges NAME		#查看項目中強制執行的限制約束
 21 $ oc get limits				#查看項目中強制執行的限制約束
 22 $ oc delete limitranges name		#按名稱刪除活動的限制範圍

提示：OCP 3.9不支持使用oc create命令參數形式創建limit rang。

在項目中創建limit rang之後，將根據項目中的每個limit rang資源評估所有資源創建請求。如果新資源違反由任何limit rang設置的最小或最大約束，則拒絕該資源。如果新資源沒有聲明配置值，且約束支持預設值，則將預設值作為其使用值應用於新資源。

所有資源更新請求也將根據項目中的每個limit rang資源進行評估，如果更新後的資源違反了任何約束，則拒絕更新。

註意：避免將LimitRange設的過高，或ResourceQuota設的過低。違反LimitRange將阻止pod創建，並清晰保存。違反ResourceQuota將阻止pod被調度，狀態轉為pending。

1.4 多項目quota配額

ClusterResourceQuota資源是在集群級別創建的，創建方式類似持久捲，並指定應用於多個項目的資源約束。

可以通過以下兩種方式指定哪些項目受集群資源配額限制:

  • 使用openshift.io/requester標記，定義項目所有者，該所有者的所有項目均應用quota；
  • 使用selector，匹配該selector的項目將應用quota。

示例1：

  1 $ oc create clusterquota user-qa \
  2 --project-annotation-selector openshift.io/requester=qa \
  3 --hard pods=12 \
  4 --hard secrets=20			#為qa用戶擁有的所有項目創建集群資源配額
  5 $ oc create clusterquota env-qa \
  6 --project-label-selector environment=qa \
  7 --hard pods=10 \
  8 --hard services=5			#為所有具有environment=qa標簽的項目創建集群資源配額
  9 $ oc describe QUOTA NAME		#查看應用於當前項目的集群資源配額
 10 $ oc delete clusterquota NAME		#刪除集群資源配額

提示：不建議使用一個集群資源配額來匹配超過100個項目。這是為了避免較大的locking開銷。當創建或更新項目中的資源時，在搜索所有適用的資源配額時鎖定項目需要較大的資源消耗。

二 限制資源使用

2.1 前置準備

準備完整的OpenShift集群，參考《003.OpenShift網路》2.1。

2.2 本練習準備

  1 [student@workstation ~]$ lab monitor-limit setup

2.3 查看當前資源

  1 [student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com
  2 [student@workstation ~]$ oc describe node node1.lab.example.com | grep -A 4 Allocated
  3 [student@workstation ~]$ oc describe node node2.lab.example.com | grep -A 4 Allocated

clipboard

2.4 創建應用

  1 [student@workstation ~]$ oc new-project resources
  2 [student@workstation ~]$ oc new-app --name=hello \
  3 --docker-image=registry.lab.example.com/openshift/hello-openshift
  4 [student@workstation ~]$ oc get pod -o wide
  5 NAME            READY     STATUS    RESTARTS   AGE       IP            NODE
  6 hello-1-znk56   1/1       Running   0          24s       10.128.0.16   node1.lab.example.com

2.5 刪除應用

  1 [student@workstation ~]$ oc delete all -l app=hello

2.6 添加資源限制

作為集群管理員，向項目quota和limit range，以便為項目中的pod提供預設資源請求。

  1 [student@workstation ~]$ cd /home/student/DO280/labs/monitor-limit/
  2 [student@workstation monitor-limit]$ cat limits.yml		#創建limit range
  3 apiVersion: "v1"
  4 kind: "LimitRange"
  5 metadata:
  6   name: "project-limits"
  7 spec:
  8   limits:
  9     - type: "Container"
 10       default:
 11         cpu: "250m
 12 [student@workstation monitor-limit]$ oc create -f limits.yml	#創建limit range
 13 [student@workstation monitor-limit]$ oc describe limitrange	#查看limit range

clipboard

  1 [student@workstation monitor-limit]$ cat quota.yml		#創建配額
  2 apiVersion: v1
  3 kind: ResourceQuota
  4 metadata:
  5   name: project-quota
  6 spec:
  7   hard:
  8     cpu: "900m"
  9 [student@workstation monitor-limit]$ oc create -f quota.yml
 10 [student@workstation monitor-limit]$ oc describe quota		#確保創建了resource限制

clipboard

2.7 授權項目

  1 [student@workstation monitor-limit]$ oc adm policy add-role-to-user edit developer

2.8 驗證資源限制

  1 [student@workstation ~]$ oc login -u developer -p redhat https://master.lab.example.com
  2 [student@workstation ~]$ oc project resources			#選擇項目
  3 Already on project "resources" on server "https://master.lab.example.com:443".
  4 [student@workstation ~]$ oc get limits				#查看limit
  5 NAME             AGE
  6 project-limits   14m
  7 [student@workstation ~]$ oc delete limits project-limits	#驗證限制是否有效，但developer用戶不能刪除該限制
  8 Error from server (Forbidden): limitranges "project-limits" is forbidden: User "developer" cannot delete limitranges in the namespace "resources": User "developer" cannot delete limitranges in project "resources"
  9 [student@workstation ~]$ oc get quota
 10 NAME            AGE
 11 project-quota   15m

2.9 創建應用

  1 [student@workstation ~]$ oc new-app --name=hello \
  2 --docker-image=registry.lab.example.com/openshift/hello-openshift
  3 [student@workstation ~]$ oc get pod
  4 NAME            READY     STATUS    RESTARTS   AGE
  5 hello-1-t7tfn   1/1       Running   0          35s

2.10 查看quota

  1 [student@workstation ~]$ oc describe quota
  2 Name:       project-quota
  3 Namespace:  resources
  4 Resource    Used  Hard
  5 --------    ----  ----
  6 cpu         250m  900m

2.11 查看節點可用資源

  1 [student@workstation ~]$ oc login -u admin -p redhat \
  2 https://master.lab.example.com
  3 [student@workstation ~]$ oc get pod -o wide -n resources
  4 [student@workstation ~]$ oc describe node node1.lab.example.com | grep -A 4 Allocated
  5 [student@workstation ~]$ oc describe pod hello-1-t7tfn | grep -A2 Requests

clipboard

2.12 擴容應用

  1 [student@workstation ~]$ oc scale dc hello --replicas=2		#擴容應用
  2 [student@workstation ~]$ oc get pod				#查看擴容後的pod
  3 [student@workstation ~]$ oc describe quota			#查看擴容後的quota情況
  4 [student@workstation ~]$ oc scale dc hello --replicas=4		#繼續擴容至4個
  5 [student@workstation ~]$ oc get pod				#查看擴容的pod
  6 [student@workstation ~]$ oc describe dc hello | grep Replicas	#查看replaces情況

clipboard

結論：由於超過了配額規定，會提示控制器無法創建第四個pod。

2.13 添加配額請求

  1 [student@workstation ~]$ oc scale dc hello --replicas=1
  2 [student@workstation ~]$ oc get pod
  3 [student@workstation ~]$ oc set resources dc hello --requests=memory=256Mi	#設置資源請求
  4 [student@workstation ~]$ oc get pod
  5 [student@workstation ~]$ oc describe pod hello-2-4jvpw | grep -A 3 Requests
  6 [student@workstation ~]$ oc describe quota					#查看quota

clipboard

結論：由上可知從項目的配額角度來看，沒有什麼變化。

2.14 增大配額請求

  1 [student@workstation ~]$ oc set resources dc hello --requests=memory=8Gi	#將記憶體請求增大到超過node最大值
  2 [student@workstation ~]$ oc get pod						#查看pod
  3 [student@workstation ~]$ oc logs hello-3-deploy					#查看log
  4 [student@workstation ~]$ oc status

clipboard

結論：由於資源請求超過node最大值，最終顯示一個警告，說明由於記憶體不足，無法將pod調度到任何節點。

三 OCP升級

3.1 升級OPENSHIFT

當OCP的新版本發佈時，可以升級現有集群，以應用最新的增強功能和bug修複。這包括從以前的次要版本(如從3.7升級到3.9)升級，以及對次要版本(3.7)應用更新。

提示：OCP 3.9包含了Kubernetes 1.8和1.9的特性和補丁的合併。由於主要版本之間的核心架構變化，OpenShift Enterprise 2環境無法升級為OpenShift容器平臺3，必須需要重新安裝。

通常，主版本中不同子版本的node是向前和向後相容的。但是，運行不匹配的版本的時間不應超過升級整個集群所需的時間。此外，不支持使用quick installer將版本3.7升級到3.9。

3.2 升級方式

有兩種方法可以執行OpenShift容器平臺集群升級，一種為in-place升級(可以自動升級或手動升級)，也可以使用blue-green部署方法進行升級。

in-place升級：使用此方式，集群升級將在單個運行的集群中的所有主機上執行。首先升級master，然後升級node。在node升級開始之前，Pods被遷移到集群中的其他節點。這有助於減少用戶應用程式的停機時間。

註意：對於使用quick和高級安裝方法安裝的集群，可以使用自動in-place方式升級。

當使用高級安裝方法安裝集群時，您可以通過重用它們的庫存文件執行自動化或手動就地升級。

blue-green部署：blue-green部署是一種旨在減少停機時間同時升級環境的方法。在blue-green部署中，相同的環境與一個活動環境一起運行，而另一個環境則被更新。OpenShift升級方法標記了不可調度節點，並將pod調度到可用節點。升級成功後，節點將恢復到可調度狀態。

3.3 執行自動化集群升級

使用高級安裝方法，可以使用Ansible playbook自動化執行OpenShift集群升級過程。用於升級的劇本位於/usr/share/ansible/openshift-ansible/Playbooks/common/openshift-cluster/updates/中。該目錄包含一組用於升級集群的子目錄，例如v3_9。

註意：將集群升級到 OCP 3.9 前，集群必須已經升級到 3.7。集群升級一次不能跨越一個以上的次要版本，因此，如果集群的版本早於3.6，則必須先漸進地升級，例如從3.5升級到3.6，然後從3.6升級到3.7

要執行升級，可以使用ansible-playbook命令運行升級劇本，如使用v3_9 playbook將運行3.7版本的現有OpenShift集群升級到3.9版本。

自動升級主要執行以下任務:

  • 應用最新的配置更改；
  • 保存Etcd數據；
  • 將api從3.7更新到3.8，然後從3.8更新到3.9；
  • 如果存在，將預設路由器從3.7更新到3.9；
  • 如果存在，則將預設倉庫從3.7更新到3.9；
  • 更新預設is和Templates。

註意：在繼續升級之前，確保已經滿足了所有先決條件，否則可能導致升級失敗。

如果使用容器化的GlusterFS，節點將不會從pod中撤離，因為GlusterFS pod作為daemonset的一部分運行。要正確地升級運行容器化GlusterFS的集群，需要:

1：升級master伺服器、Etcd和基礎設施服務(route、內部倉庫、日誌記錄和metric)。

2：升級運行應用程式容器的節點。

3：一次升級一個運行GlusterFS的節點。

註意：在升級之前，使用oc adm diagnostics命令驗證集群的健康狀況。這確認節點處於ready狀態，運行預期的啟動版本，並且沒有診斷錯誤或警告。對於離線安裝，使用--network-pod-image='REGISTRY URL/ IMAGE參數指定要使用的image。

3.4 準備自動升級

下麵的過程展示瞭如何為自動升級準備環境，在執行升級之前，Red Hat建議檢查配置Inventory文件，以確保對Inventory文件進行了手動更新。如果配置沒有修改，則使用預設值覆蓋更改。

  1. 如果這是從OCP 3.7升級到3.9，手動禁用3.7存儲庫，併在每個master節點和node節點上啟用3.8和3.9存儲庫：
  1 [root@demo ~]# subscription-manager repos \
  2 --disable="rhel-7-server-ose-3.7-rpms" \
  3 --enable="rhel-7-server-ose-3.9-rpms" \
  4 --enable="rhel-7-server-ose-3.8-rpms" \
  5 --enable="rhel-7-server-rpms" \
  6 --enable="rhel-7-server-extras-rpms" \
  7 --enable="rhel-7-server-ansible-2.4-rpms" \
  8 --enable="rhel-7-fast-datapath-rpms"
  9 [root@demo ~]# yum clean all

  1. 確保在每個RHEL 7系統上都有最新版本的atom-openshift-utils包，它還更新openshift-ansible-*包。
  1 [root@demo ~]# yum update atomic-openshift-utils
  1. 在OpenShift容器平臺的以前版本中，安裝程式預設將master節點標記為不可調度，但是，從OCP 3.9開始，master節點必須標記為可調度的，這是在升級過程中自動完成的。

如果沒有設置預設的節點選擇器(如下配置)，它們將在升級過程中添加。則master節點也將被標記為master節點角色。所有其他節點都將標記為compute node角色。 

  1 openshift_node_labels="{'region':'infra', 'node-role.kubernetes.io/compute':'true'}
  1. 如果將openshift_disable_swap=false變數添加到的Ansible目錄中，或者在node上手動配置swap，那麼在運行升級之前禁用swap記憶體。

3.5 升級master節點和node節點

在滿足了先決條件(如準備工作)之後，則可以按照如下步驟進行升級：

  1. 在清單文件中設置openshift_deployment_type=openshift-enterprise變數。
  2. 如果使用自定義Docker倉庫，則必須顯式地將倉庫的地址指定為openshift_web_console_prefix和template_service_broker_prefix變數。這些值由Ansible在升級過程中使用。
  1 openshift_web_console_prefix=registry.demo.example.com/openshift3/ose-
  2 template_service_broker_prefix=registry.demo.example.com/openshift3/ose-

  1. 如果希望重啟service或重啟node，請在Inventory文件中設置openshift_rolling_restart_mode=system選項。如果未設置該選項，則預設值表明升級過程在master節點上執行service重啟，但不重啟系統。
  2. 可以通過運行一個Ansible Playbook (upgrade.yml)來更新環境中的所有節點，也可以通過使用單獨的Playbook分多個階段進行升級。
  3. 重新啟動所有主機，重啟之後，如果沒有部署任何額外的功能，可以驗證升級。

3.6 分階段升級集群

如果決定分多個階段升級環境，根據Ansible Playbook (upgrade_control_plan .yml)確定的第一個階段，升級以下組件:

  1. master節點；
  2. 運行master節點的節點services；
  3. Docker服務位於master節點和任何獨立Etcd主機上。

第二階段由upgrade_nodes.yml playbook，升級了以下組件。在運行此第二階段之前，必須已經升級了master節點。

  1. node節點的服務；
  2. 運行在獨立節點上的Docker服務。

兩個階段的升級過程允許通過指定自定義變數自定義升級的運行方式。例如，要升級總節點的50%，可以運行以下命令:

  1 [root@demo ~]# ansible-playbook \
  2 /usr/share/ansible/openshift-ansible/playbooks/common/openshift-cluster/upgrades/
  3 v3_9/upgrade_nodes.yml \
  4 -e openshift_upgrade_nodes_serial="50%"

若要在HA region一次升級兩個節點，請運行以下命令：

  1 [root@demo ~]# ansible-playbook \
  2 /usr/share/ansible/openshift-ansible/playbooks/common/openshift-cluster/upgrades/
  3 v3_9/upgrade_nodes.yml \
  4 -e openshift_upgrade_nodes_serial="2"
  5 -e openshift_upgrade_nodes_label="region=HA"

要指定每個更新批處理中允許有多少節點失敗，可使用openshift_upgrade_nodes_max_fail_percent選項。當故障百分比超過定義的值時，Ansible將中止升級。

使用openshift_upgrade_nodes_drain_timeout選項指定中止play前等待的時間。

示例：如下所示一次升級10個節點，以及如果20%以上的節點(兩個節點)失敗，以及終止play執行的等待時間。

  1 [root@demo ~]# ansible-playbook \
  2 /usr/share/ansible/openshift-ansible/playbooks/common/openshift-cluster/upgrades/
  3 v3_9/upgrade_nodes.yml \
  4 -e openshift_upgrade_nodes_serial=10 \
  5 -e openshift_upgrade_nodes_max_fail_percentage=20 \
  6 -e openshift_upgrade_nodes_drain_timeout=600

3.7 使用Ansible Hooks

可以通過hook為特定的操作執行定製的任務。hook允許通過定義在升級過程中特定點之前或之後執行的任務來擴展升級過程的預設行為。例如，可以在升級集群時驗證或更新自定義基礎設施組件。

提示：hook沒有任何錯誤處理機制，因此，hook中的任何錯誤都會中斷升級過程。需要修複hook並重新運行升級過程。

使用Inventory文件的[OSEv3:vars]部分來定義hook。每個hook必須指向一個.yaml文件，該文件定義了可能的任務。該文件是作為include語句的一部分集成的，該語句要求定義一組任務，而不是一個劇本。Red Hat建議使用絕對路徑來避免任何歧義。

以下hook可用於定製升級過程：

1. openshift_master_upgrade_pre_hook：hook在更新每個master節點之前運行。

2. openshift_master_upgrade_hook：hook在每個master節點升級之後、主服務或節點重新啟動之前運行。

3.openshift_master_upgrade_post_hook：hook在每個master節點升級並重啟服務或系統之後運行。

示例：在庫存文件中集成一個鉤子。

  1 [OSEv3:vars]
  2 openshift_master_upgrade_pre_hook=/usr/share/custom/pre_master.yml
  3 openshift_master_upgrade_hook=/usr/share/custom/master.yml
  4 openshift_master_upgrade_post_hook=/usr/share/custom/post_master.yml

如上示例，引入了一個pre_master.yml，包括了以下任務：

  1 ---
  2 - name: note the start of a master upgrade
  3 debug:
  4 msg: "Master upgrade of {{ inventory_hostname }} is about to start"
  5 - name: require an operator agree to start an upgrade pause:
  6 prompt: "Hit enter to start the master upgrade"

3.8 驗證升級

升級完成後，應該執行以下步驟以確保升級成功。

  1 [root@demo ~]# oc get nodes		#驗證node處於ready
  2 [root@demo ~]# oc get -n default dc/docker-registry -o json | grep \"image\"
  3 #驗證倉庫版本
  4 [root@demo ~]# oc get -n default dc/router -o json | grep \"image\
  5 #驗證image版本
  6 [root@demo ~]# oc adm diagnostics	#使用診斷工具

3.9 升級步驟彙總

  1. 確保在每個RHEL 7系統上都有atom-openshift-utils包的最新版本。
  2. 如果使用自定義Docker倉庫，可以選擇將倉庫的地址指定為openshift_web_console_prefix和template_service_broker_prefix變數。
  3. 禁用所有節點上的swap。
  4. 重新啟動所有主機，重啟之後，檢查升級。
  5. 可選地：檢查Inventory文件中的節點選擇器。
  6. 禁用3.7存儲庫，併在每個master主機和node節點主機上啟用3.8和3.9存儲庫。
  7. 通過使用合適的Ansible劇本集，使用單個或多個階段策略進行更新。
  8. 在清單文件中設置openshift_deployment_type=openshift-enterprise變數。

四 使用probes監視應用

4.1 OPENSHIFT探針介紹

OpenShift應用程式可能會因為臨時連接丟失、配置錯誤或應用程式錯誤等問題而異常。開發人員可以使用探針來監視他們的應用程式。探針是一種Kubernetes操作，它定期對正在運行的容器執行診斷。可以使用oc客戶端命令或OpenShift web控制台配置探針。

目前，可以使用兩種類型的探測:

  • Liveness探針

Liveness探針確定在容器中運行的應用程式是否處於健康狀態。如果Liveness探針返回檢測到一個不健康的狀態，OpenShift將殺死pod並試圖重新部署它。開發人員可以通過配置template.spec.container.livenessprobe來設置Liveness探針。

  • Readiness探針

Readiness探針確定容器是否準備好為請求服務，如果Readiness探針返回失敗狀態，OpenShift將從所有服務的端點刪除容器的IP地址。開發人員可以使用Readiness探針向OpenShift發出信號，即使容器正在運行，它也不應該從代理接收任何流量。開發人員可以通過配置template.spec.containers.readinessprobe來設置Readiness探針。

OpenShift為探測提供了許多超時選項，有五個選項控制支持如上兩個探針:

initialDelaySeconds：強制性的。確定容器啟動後，在開始探測之前要等待多長時間。

timeoutSeconds：強制性的確定等待探測完成所需的時間。如果超過這個時間，OpenShift容器平臺會認為探測失敗。

periodSeconds：可選的，指定檢查的頻率。

successThreshold：可選的，指定探測失敗後被認為成功的最小連續成功數。

failureThreshold：可選的，指定探測器成功後被認為失敗的最小連續故障。

4.2 檢查應用程式健康

Readiness和liveness probes可以通過三種方式檢查應用程式的健康狀況：

HTTP檢查：當使用HTTP檢查時，OpenShift使用一個webhook來確定容器的健康狀況。如果HTTP響應代碼在200到399之間，則認為檢查成功。

示例：演示如何使用HTTP檢查方法實現readiness probe 。

  1 ...
  2 readinessProbe:
  3   httpGet:
  4     path: /health			#檢測的URL
  5     port: 8080				#埠
  6   initialDelaySeconds: 15		#在容器啟動後多久才能檢查其健康狀況
  7   timeoutSeconds: 1			#要等多久探測器才能完成
  8 ...

4.3 容器執行檢查

當使用容器執行檢查時，kubelet agent在

您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • JDBC概述：什麼是JDBC？JDBC API與JDBC驅動
    一、什麼是JDBC JDBC（Java Data Base Connectivity,Java資料庫連接）是一種用於執行SQL語句的Java API，為多種關係資料庫提供統一訪問。 它由一組用Java語言編寫的類和介面組成。 有了JDBC，程式員只需用JDBC API寫一個程式，就可以訪問所有資料庫 ...
  • FileChannel按行讀取文件
    FileChannel是什麼 它是用於讀取、寫入、映射和操作文件的通道。除了熟悉的位元組通道讀取，寫入和關閉操作之外，此類還定義了以下特定於文件的操作： 可以以不影響通道當前位置的方式在文件中的絕對位置讀取或寫入位元組。 文件的區域可以直接映射到記憶體中。 對於大文件，這通常比調用通常的讀取或寫入方法要有 ...
  • .NET 5 嘗鮮 - 開源項目TerminalMACS WPF管理端支持.NET 5
    .NET 5 嘗鮮 - 開源項目TerminalMACS WPF管理端支持.NET 5 一個使用 Prism 作為模塊化框架、基於多個開源控制項庫作為UI控制項選擇、集成開源 UI 界面設計的 .NET 5 WPF 客戶端項目。 項目名稱：TerminalMACS WPF管理端 項目開源地址： Gith ...
  • 【asp.net core 系列】- 11 Service層的實現樣板
    0.前言 在《asp.net core 系列》之實戰系列中，我們在之前的篇幅中對項目有了一個大概的認知，也搭建了一個基礎的項目骨架。那麼就讓我們繼續完善這個骨架，讓它更加豐滿。這一篇，我將帶領小伙伴們一起實現用戶管理功能。 1. 數據表 一般情況下，我們會把用戶表和登錄信息表放在兩個表裡。為什麼會這 ...
  • C#多線程編程（一）進程與線程
    一、 進程 簡單來說，進程是對資源的抽象，是資源的容器，在傳統操作系統中，進程是資源分配的基本單位，而且是執行的基本單位，進程支持併發執行，因為每個進程有獨立的數據，獨立的堆棧空間。一個程式想要併發執行，開多個進程即可。 Q1：在單核下，進程之間如何同時執行？ 首先要區分兩個概念——併發和並行 併發 ...
  • Newtonsoft 六個超簡單又實用的特性，值得一試 【上篇】
    一：講故事 看完官方文檔，閱讀了一些 Newtonsoft 源碼，對它有了新的認識，先總結 六個超經典又實用的特性，同大家一起分享，廢話不多說，快來一起看看吧~~~ 二：特性分析 1. 代碼格式化 如果你直接使用 JsonConvert.SerializeObject的話，預設情況下所有的json是 ...
  • Dcoker如何搭建私有registry鏡像倉庫
    Docker如何搭建私有鏡像倉庫，如何訪問私有鏡像倉庫，與如何刪除私有鏡像倉庫鏡像 ...
  • 徹底解決Windows不能在本地電腦啟動Windows Firewall問題
    徹底解決Windows不能在本地電腦啟動Windows Firewall問題 問題描述 有些時候我們需要關閉Windows防火牆，但是控制面板中並沒有相應按鈕： Win+R後輸入services.msc，打開服務，發現防火牆也不能手動啟動，提示Windows不能在本地電腦啟動Windows Fi ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類