OCP的安裝和更新

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 叢集涉及以下步驟：

1. bootstrap 機器啟動并開始托管 master 機器啟動所需的遠端資源。（如果自己配置基礎架構，則需要人工幹預）
2. master 機器從 bootstrap 機器擷取遠端資源并完成啟動。（如果自己配置基礎架構，則需要人工幹預）
3. master 機器使用 bootstrap 機器來組成 etcd 叢集。
4. bootstrap 機器使用新的 etcd 叢集啟動臨時 Kubernetes control plane。
5. 臨時 control plane 将生産環境的 control plane 排程到 master 機器。
6. 臨時 control plane 關機，并将控制權交給生産環境 control plane。
7. bootstrap 機器将 OpenShift Container Platform 元件注入生産環境 control plane。
8. 安裝程式關閉 bootstrap 機器。（如果自己配置基礎架構，則需要人工幹預）
9. control plane 設定 worker 節點。

10. 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 覆寫會使整個叢集處于不受支援狀态。在删除所有覆寫後，必須可以重制報告的問題方可獲得支援。