2.1. OpenShift Container Platform 安裝概述
OpenShift Container Platform 安裝程序為您提供了靈活性。您可以使用安裝程序將集群部署到由安裝程序置備並由集群維護的基礎架構中，也可以將集群部署到您自己準備和維護的基礎架構中。
這兩種基本類型的 OpenShift Container Platform 集群通常稱為安裝程序置備的基礎架構集群和用戶置備的基礎架構集群。
兩種類型的集群都具有以下特徵：
• 默認提供無單點故障的高可用性基礎架構
• 管理員可以控制要應用的更新內容和更新的時間
兩種類型的集群都使用同一個安裝程序來部署。安裝程序生成的主要資產是用於 Bootstrap、master 和 worker 機器的 Ignition 配置文件。有了這三個配置和配置得當的基礎架構，就能啟動 OpenShift Container Platform 集群。
OpenShift Container Platform 安裝程序使用一組目標和依賴項來管理集群安裝。安裝程序具有一組必須實現的目標，並且每個目標都有一組依賴項。因為每個目標僅關注其自己的依賴項，所以安裝程序可以採取措施來並行實現多個目標。最終目標是正常運行的集群。通過滿足依賴項而不是運行命令，安裝程序能夠識別和使用現有的組件，而不必運行命令來再次創建它們。
下圖顯示了安裝目標和依賴項的子集：
圖 2.1. OpenShift Container Platform 安裝目標和依賴項
在安裝後，每一個集群機器都將使用 Red Hat Enterprise Linux CoreOS (RHCOS) 作為操作系統。RHCOS 是 Red Hat Enterprise Linux (RHEL) 的不可變容器主機版本，具有默認啟用 SELinux 的 RHEL 內核。它包括作為 Kubernetes 節點代理的 kubelet，以及為 Kubernetes 優化的 CRI-O 容器運行時。
OpenShift Container Platform 4.4 集群中的每一 control plane 機器都必須使用 RHCOS，其中包括一個關鍵的首次啟動置備工具，稱為 Ignition。這一工具讓集群能夠配置機器。操作系統更新作為嵌入在容器鏡像中的 Atomic OSTree 存儲庫交付，該鏡像由 Operator 在整個集群中推廣。實際的操作系統更改通過使用 rpm-ostree 在每臺機器上作為原子操作原位進行。通過結合使用這些技術，OpenShift Container Platform 可以像管理集群上的任何其他應用程序一樣管理操作系統，通過原位升級使整個平臺保持最新狀態。這些原位更新可以減輕運維團隊的負擔。
如果將 RHCOS 用作所有集群機器的操作系統，則集群將管理其組件和機器的所有方面，包括操作系統在內。因此，只有安裝程序和 Machine Config Operator 才能更改機器。安裝程序使用 Ignition 配置文件設置每臺機器的確切狀態，安裝後則由 Machine Config Operator 完成對機器的更多更改，例如應用新證書或密鑰等。
2.1.1. 適用的平臺
在 OpenShift Container Platform 4.4 中，您可以在以下平臺上安裝使用安裝程序置備的基礎架構集群：
• Amazon Web Services (AWS)
• Google Cloud Platform (GCP)
• Microsoft Azure
• Red Hat OpenStack Platform 版本 13 和 16
o 最新的 OpenShift Container Platform 版本支持最新的 RHOSP 長生命版本和中間版本。如需完整的 RHOSP 發行版本兼容性信息，請參閱 RHOSP 上的 OpenShift Container Platform 支持列表。
• Red Hat Virtualization (RHV)
對於所有這些集群，包括用來運行安裝過程的計算機在內的所有機器都必須可直接訪問互聯網，以便為平臺容器拉取鏡像並向紅帽提供 telemetry 數據。
在 OpenShift Container Platform 4.4 中，您可以在以下平臺上安裝使用用戶置備的基礎架構集群：
• AWS
• Azure
• GCP
• RHOSP
• VMware vSphere
• 裸機
在用戶置備的基礎架構上安裝，每臺機器都可擁有完整的互聯網訪問能力，您可以將集群放置在代理後面，也可以執行受限網絡安裝。在受限網絡安裝中，您可以下載安裝集群所需的鏡像（image），將它們放在鏡像 registry（mirror registry）中，然後使用那些數據安裝集群。雖然您需要訪問互聯網來為平臺容器拉取鏡像，但在 vSphere 或裸機基礎架構上進行受限網絡安裝，您的集群機器不需要直接訪問互聯網。
OpenShift Container Platform 4.x Tested Integrations 頁面中提供了有關針對不同平臺進行集成測試的詳細信息。
2.1.2. 安裝過程
當安裝 OpenShift Container Platform 集群時，從 Red Hat OpenShift Cluster Manager 站點上的相應的 Infrastructure Provider 頁面下載安裝程序。此網站管理以下內容：
• 帳戶的 REST API
• registry 令牌，這是用於獲取所需組件的 pull secret
• 集群註冊，它將集群身份信息與您的紅帽帳戶相關聯，以方便收集使用情況指標
在 OpenShift Container Platform 4.4 中，安裝程序是對一組資產執行一系列文件轉換的 Go 二進制文件。與安裝程序交互的方式因您的安裝類型而異。
• 對於具有安裝程序置備的基礎架構集群，您可以將基礎架構啟動和置備委派給安裝程序，而不是親自執行。安裝程序將創建支持集群所需的所有網絡、機器和操作系統。
• 如果親自為集群置備和管理基礎架構，則必須提供所有集群基礎架構和資源，包括 Bootstrap 機器、網絡、負載均衡、存儲和獨立的集群機器。您無法使用安裝程序置備的基礎架構集群所提供的高級機器管理和擴展功能。
安裝期間使用三組文件：名為 install-config.yaml 的安裝配置文件、Kubernetes 清單，以及您的機器類型適用的 Ignition 配置文件。
重要
安裝期間可以修改控制基礎 RHCOS 操作系統的 Kubernetes 和 Ignition 配置文件。但是，沒有可用的驗證機制來確認您對這些對象所做修改是適當的。如果修改了這些對象，集群可能會無法運行。由於存在這種風險，修改 Kubernetes 和 Ignition 配置文件不受支持，除非您遵循記錄的流程或在紅帽支持指示下操作。
安裝配置文件轉換為 Kubernetes 清單，然後清單嵌套到 Ignition 配置文件中。安裝程序使用這些 Ignition 配置文件來創建集群。
運行安裝程序時，所有配置文件會被修剪，因此請務必備份需要再次使用的所有配置文件。
重要
安裝之後，您無法修改在安裝過程中設置的參數，但可以修改一些集群屬性。
採用安裝程序置備的基礎架構的安裝過程
默認安裝類型為使用安裝程序置備的基礎架構。默認情況下，安裝程序充當安裝嚮導，提示您輸入它無法自行確定的值，併為其餘參數提供合理的默認值。您還可以自定義安裝過程來支持高級基礎架構場景。安裝程序將為集群置備底層基礎架構。
您可以安裝標準集群或自定義集群。對於標準集群，您要提供安裝集群所需的最低限度詳細信息。對於自定義集群，您可以指定有關平臺的更多詳細信息，如 control plane 使用的機器數量、集群部署的虛擬機的類型，或 Kubernetes 服務網絡的 CIDR 範圍。
若有可能，可以使用此功能來避免置備和維護集群基礎架構。在所有其他環境中，可以使用安裝程序來生成置備集群基礎架構所需的資產。
對於安裝程序置備的基礎架構的集群，OpenShift Container Platform 可以管理集群的所有方面，包括操作系統本身。每臺機器在啟動時使用的配置引用其加入的集群中託管的資源。此配置允許集群在應用更新時自行管理。
採用用戶置備的基礎架構的安裝過程
您還可以在自己提供的基礎架構上安裝 OpenShift Container Platform。您可以使用安裝程序來生成置備集群基礎架構所需的資產，再創建集群基礎架構，然後將集群部署到您提供的基礎架構中。
如果不使用安裝程序置備的基礎架構，您必須自己管理和維護集群資源，包括：
• 組成集群的 control plane 和計算機器
• 負載均衡器
• 集群網絡，包括 DNS 記錄和所需的子網
• 集群基礎架構和應用程序的存儲
如果您的集群使用用戶置備的基礎架構，則可以選擇將 RHEL worker 機器添加到集群中。
安裝過程詳細信息
由於在置備時集群中的每臺機器都需要集群的相關信息，因此 OpenShift Container Platform 在初始配置期間會使用臨時 Bootstrap 機器將所需的信息提供給持久 control plane。通過使用描述如何創建集群的 Ignition 配置文件進行啟動。Bootstrap 機器將創建組成 control plane 的 master 機器。然後，control plane 機器創建計算（compute）機器。下圖說明了這一過程：
圖 2.2. 創建 Bootstrap、master 和 worker 機器
集群機器初始化後，Bootstrap 機器將被銷燬。所有集群都使用 Bootstrap 過程來初始化集群，但若您自己置備集群的基礎架構，則必須手動完成許多步驟。
重要
安裝程序生成的 Ignition 配置文件中所含的證書會在 24 小時後過期。您必須完成集群安裝，並使集群以非降級狀態運行 24 小時，以確保完成第一次證書輪轉。
bootstrapp 集群涉及以下步驟：
- bootstrap 機器啟動並開始託管 master 機器啟動所需的遠程資源。（如果自己配置基礎架構，則需要人工干預）
- master 機器從 bootstrap 機器獲取遠程資源並完成啟動。（如果自己配置基礎架構，則需要人工干預）
- master 機器使用 bootstrap 機器來組成 etcd 集群。
- bootstrap 機器使用新的 etcd 集群啟動臨時 Kubernetes control plane。
- 臨時 control plane 將生產環境的 control plane 調度到 master 機器。
- 臨時 control plane 關機，並將控制權交給生產環境 control plane。
- bootstrap 機器將 OpenShift Container Platform 組件注入生產環境 control plane。
- 安裝程序關閉 bootstrap 機器。（如果自己配置基礎架構，則需要人工干預）
- control plane 設置 worker 節點。
- control plane 以一組 Operator 的形式安裝其他服務。
完成此 bootstrap 過程後，將生成一個全面運作的 OpenShift Container Platform 集群。然後，集群下載並配置日常運作所需的其餘組件，包括在受支持的環境中創建 worker 機器。
安裝過程詳細信息
安裝範圍
OpenShift Container Platform 安裝程序的作用範圍特意設計得比較狹窄。它旨在簡化操作並確保成功。安裝完成後，您可以完成更多的配置任務。
2.2. 關於 OPENSHIFT CONTAINER PLATFORM 更新服務
OpenShift Container Platform 更新服務是一種託管服務，為 OpenShift Container Platform 和 Red Hat Enterprise Linux CoreOS (RHCOS) 提供無線更新 (over-the air update)。它提供了一個組件 Operator 圖，其中包含各個頂點及連接它們的邊。圖中的邊顯示可以安全更新的版本，頂點是更新有效負載，用於指定託管集群組件的預期狀態。
集群中的 Cluster Version Operator (CVO) 會檢查 OpenShift Container Platform 更新服務，並根據當前組件版本和圖中的信息決定有效的更新和更新路徑。當您請求更新時，OpenShift Container Platform CVO 使用該更新的發行鏡像來升級您的集群。發行工件 (artifact) 作為容器鏡像託管在 Quay 中。
為了使 OpenShift Container Platform 更新服務僅提供兼容的更新，提供了一個版本驗證管道來驅動自動化。每個發行工件都會被驗證是否與支持的雲平臺和系統架構以及其他組件包兼容。在管道確認有適用的版本後，OpenShift Container Platform 更新服務會通知您可以進行更新。
重要
因為更新服務會顯示所有有效的更新，所以不能強制更新到一個更新服務沒有顯示的版本。
對於連續更新模式，會運行兩個控制器。一個控制器不斷更新有效負載清單，將它們應用於集群，並輸出受控 Operator 部署的狀態（可用、正在進行升級或失敗）。第二個控制器輪詢 OpenShift Container Platform 更新服務以確定更新是否可用。
重要
不支持將集群還原到以前的版本或執行回滾。僅支持升級到較新版本。
在升級過程中，Machine Config Operator (MCO) 會將新配置應用到集群機器。它將機器配置池中由 maxUnavailable 字段指定數量的節點保護起來，並將其標記為不可用。在默認情況下，這個值被設置為 1。然後，它會應用新配置並重啟機器。如果您將 Red Hat Enterprise Linux (RHEL) 機器用作 worker，MCO 不會在這些機器上更新 kubelet，因為您必須首先在這些機器上更新 OpenShift API。因為新版本的規格被應用到舊的 kubelet，所以 RHEL 機器無法返回 Ready 狀態。在機器可用前，您無法完成更新。但是，通過設置不可用節點的最大數量可以確保當不可用機器的數量沒有超過這個值時，正常的集群操作仍然可以繼續進行。
2.3. 支持非受管 OPERATOR 的策略
Operator 的 管理狀態 決定了一個 Operator 是否按設計積極管理集群中其相關組件的資源。如果 Operator 設置為 非受管（unmanaged） 狀態，它不會響應配置更改，也不會收到更新。
雖然它可以在非生產環境集群或調試過程中使用，但處於非受管狀態的 Operator 不被正式支持，集群管理員需要完全掌控各個組件的配置和升級。
可使用以下方法將 Operator 設置為非受管狀態：
• 獨立 Operator 配置
獨立 Operator 的配置中具有 managementState 參數。這可以通過不同的方法來訪問，具體取決於 Operator。例如，Cluster Logging Operator 通過修改它管理的自定義資源 (CR) 來達到此目的，而 Samples Operator 使用了集群範圍配置資源。
將 managementState 參數更改為 Unmanaged 意味著 Operator 不會主動管理它的資源，也不會執行與相關組件相關的操作。一些 Operator 可能不支持此管理狀態，因為它可能會損壞集群，需要手動恢復。
• 警告
將獨立 Operator 更改為非受管狀態會導致不支持該特定組件和功能。報告的問題必須在 受管（Managed） 狀態中可以重複出現才能繼續獲得支持。
• Cluster Version Operator (CVO) 覆蓋
可將 spec.overrides 參數添加到 CVO 配置中，以便管理員提供對組件的 CVO 行為覆蓋的列表。將一個組件的 spec.overrides[].unmanaged 參數設置為 true 會阻止集群升級並在設置 CVO 覆蓋後提醒管理員：
Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
警告
設置 CVO 覆蓋會使整個集群處於不受支持狀態。在刪除所有覆蓋後，必須可以重現報告的問題方可獲得支持。
