平台 讓您簡化創作 ，包括雲端服務供應商的基礎設施、虛擬化平台或裸機系統。為了創建一個真正基於雲端的平台，我們必須嚴格控制所使用的所有元素，從而提高複雜自動化流程的可靠性。
顯而易見的解決方案是使用 Red Hat Enterprise Linux CoreOS（Red Hat Enterprise Linux 的一個變體）和 CRI-O 作為標準，原因如下...
由於航行這個主題在解釋 Kubernetes 和容器的工作時非常適合尋找類比，所以讓我們試著用一個例子來談談 CoreOS 和 CRI-O 解決的業務問題 。 1803 年，馬克布魯內爾 (Marc Brunel) 受命生產 100 個索具組，以滿足不斷壯大的英國海軍的需求。索具組是一種用於將繩索連接到帆上的索具。直到 19 世紀初，這些砌塊都是手工製作的，但布魯內爾成功實現了生產自動化，並開始使用工具機生產標準化砌塊。這一過程的自動化意味著生成的塊本質上是相同的，如果損壞可以輕鬆更換，並且可以大量生產。
現在想像一下，如果 Brunel 必須為 20 種不同的船舶模型（Kubernetes 版本）和五個具有完全不同海流和風的不同行星（雲端提供者）完成這項工作。此外，從船長（管理集群運行的操作員）的角度來看，所有船舶（OpenShift 集群），無論在哪個行星上進行導航，都必須表現得相同。繼續用海事類比來說，船長根本不關心他們的船上使用什麼樣的索具組 (CRI-O) - 對他們來說最重要的是這些索具堅固可靠。
OpenShift 4 作為一個雲端平台，面臨著非常相似的業務挑戰。如果節點之一發生故障或擴展叢集時，必須在建立叢集時建立新節點。建立並初始化新節點時，必須相應配置關鍵主機元件（包括 CRI-O）。與其他生產一樣，必須在一開始就提供“原材料”。就船舶而言，原料是金屬和木材。但是，在建立用於在 OpenShift 4 叢集中部署容器的主機時，您需要將設定檔和提供 API 的伺服器作為輸入。然後，OpenShift 將在整個生命週期中提供所需的自動化水平，為最終用戶提供必要的產品支持，從而收回平台投資。
OpenShift 4 的創建方式是為所有主要雲端運算供應商、虛擬化平台甚至裸機系統提供在平台的整個生命週期（版本 4.X）中方便更新系統的能力。為此，必須在可互換元素的基礎上建立節點。當叢集需要新版本的 Kubernetes 時，它也會收到 CoreOS 上對應版本的 CRI-O。由於 CRI-O 版本直接與 Kubernetes 綁定，這極大地簡化了用於測試、故障排除或支援目的的任何排列。此外，這種方法還降低了最終用戶和紅帽的成本。
這是一種全新的 Kubernetes 叢集思考方式，為規劃一些非常有用且引人注目的新功能奠定了基礎。 CRI-O（容器運行時介面 - 開放容器計劃，縮寫為 CRI-OCI）已被證明是大規模創建與 OpenShift 配合使用所需的節點的最成功選擇。 CRI-O 將取代先前使用的 Docker 引擎，為 OpenShift 使用者提供服務 – 是的，你沒聽錯 – 一個無聊的容器引擎，專門為與 Kubernetes 一起使用而創建。
開放容器的世界
長期以來，世界一直朝著開放式容器的方向發展。無論是在 Kubernetes 中，還是在較低級別， 從而形成各層面的創新生態系。
一切都始於開放容器倡議的創建 。在工作的早期階段，容器規格已經形成 и 。這確保了這些工具可以使用單一標準 以及與它們合作的統一格式。後來添加了規格 ，讓用戶輕鬆分享 .
隨後，Kubernetes 社群為可插拔介面開發了一個單一標準，稱為 。因此，除了 Docker 之外，Kubernetes 用戶還能夠連接各種引擎來使用容器。
紅帽和Google的工程師看到了市場對能夠透過 CRI 協議接受 Kubelet 請求的容器引擎的需求，並引入了與上述 OCI 規範相容的容器。所以 。但請問，我們不是說這個材料會獻給CRI-O嗎？事實上確實如此，只是隨著發布 該專案更名為 CRI-O。
圖。 1。
CRI-O 和 CoreOS 的創新
隨著 OpenShift 4 平台的推出，它發生了變化 ，在平台中預設使用，並且 Docker 被 CRI-O 取代，為運行與 Kubernetes 並行開發的容器提供了一個經濟高效、穩定、簡單且無聊的環境。這極大地簡化了叢集支援和配置。容器引擎和主機的配置及其管理在 OpenShift 4 中變得自動化。
等等，這怎麼樣？
沒錯，隨著 OpenShift 4 的出現，不再需要連接到各個主機並安裝容器引擎、設定儲存、設定搜尋伺服器或設定網路。 OpenShift 4 平台經過徹底重新設計，可以使用 不僅涉及最終用戶應用程序，還涉及基本平台級操作，例如部署映像、配置系統或安裝更新。
Kubernetes 始終允許使用者透過定義所需狀態並使用 ，以確保實際狀態與目標狀態盡可能相符。這 從開發和營運的角度來看，這都帶來了巨大的機會。開發人員可以透過以下方式定義所需的狀態 以 YAML 或 JSON 檔案的形式傳遞給操作者，然後操作者就可以在生產環境中建立所需的應用實例，並且該實例的運作狀態將與指定的完全對應。
透過在平台中使用 Operator，OpenShift 4 將這種新範例（使用設定和實際狀態的概念）引入到 RHEL CoreOS 和 CRI-O 的管理中。配置和管理作業系統和容器引擎版本的任務是使用所謂的自動化 。 MCO 大大簡化了叢集管理員的工作，基本上實現了安裝最後階段以及後續安裝後操作（第二天操作）的自動化。所有這些都使 OpenShift 4 成為真正的雲端平台。我們稍後會討論這個問題。
運行容器
自從版本 3.7 處於技術預覽狀態以及版本 3.9 處於正式可用狀態（目前支援）以來，用戶有機會在 OpenShift 平台中使用 CRI-O 引擎。此外，紅帽大量使用 自版本 3.10 起在 OpenShift Online 中。所有這些使得 CRI-O 團隊在大型 Kubernetes 叢集上大規模啟動容器方面獲得了豐富的經驗。為了基本了解 Kubernetes 如何使用 CRI-O，讓我們看一下下圖，它展示了該架構的工作原理。
米。 2. 容器如何在 Kubernetes 叢集中運作
CRI-O 透過在初始化新節點以及發布 OpenShift 平台新版本時同步整個頂層，簡化了新容器主機的建立。整個平台的修訂允許事務性更新/回滾，還可以防止容器尾部核心、容器引擎、節點（Kubelet）和 Kubernetes Master 節點之間的依賴關係出現死鎖。透過集中管理所有平台元件，並進行控制和版本控制，從狀態A 到狀態B 始終有一條清晰的路徑。這簡化了更新過程，提高了安全性，改進了效能報告，並有助於降低更新和安裝新版本的成本。
展示替換元素的力量
如前所述，在 OpenShift 4 中使用 Machine Config Operator 管理容器主機和容器引擎提供了新的自動化水平，這在 Kubernetes 平台上以前是不可能實現的。為了示範新功能，我們將展示如何更改 crio.conf 檔案。為了避免被術語混淆，請嘗試專注於結果。
首先，讓我們建立所謂的容器執行時間配置 - Container Runtime Config。將其視為代表 CRI-O 配置的 Kubernetes 資源。實際上，它是 MachineConfig 的專門版本，MachineConfig 是作為 OpenShift 叢集的一部分部署到 RHEL CoreOS 電腦的任何配置。
建立這個名為 ContainerRuntimeConfig 的自訂資源是為了讓叢集管理員更輕鬆地設定 CRI-O。工具功能強大，只能應用於某些節點，取決於 MachineConfigPool 設定。將其視為具有相同目的的一組機器。
請注意我們要在 /etc/crio/crio.conf 檔案中更改的最後兩行。這兩行與 crio.conf 檔案中的行非常相似，它們是：
vi ContainerRuntimeConfig.yaml
結論：
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: set-log-and-pid
spec:
machineConfigPoolSelector:
matchLabels:
debug-crio: config-log-and-pid
containerRuntimeConfig:
pidsLimit: 2048
logLevel: debug
現在讓我們將此檔案推送到 Kubernetes 叢集並檢查它是否確實已建立。請注意，該操作與任何其他 Kubernetes 資源完全相同：
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
結論：
NAME AGE
set-log-and-pid 22h
在建立 ContainerRuntimeConfig 後，我們需要修改其中一個 MachineConfigPool，以向 Kubernetes 發出訊號，表示我們希望將此配置套用到叢集中的特定機器群組。在這種情況下，我們將更改主節點的 MachineConfigPool：
oc edit MachineConfigPool/master
結論（為了清晰起見，留下主要精華）：
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
此時，MCO 開始為叢集建立新的 crio.conf 檔案。此時，可以使用 Kubernetes API 查看完整的設定檔。請記住，ContainerRuntimeConfig 只是 MachineConfig 的專門版本，因此我們可以透過查看 MachineConfigs 中的相關行來查看結果：
oc get MachineConfigs | grep rendered
結論：
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
請注意，主節點的最終設定檔是比原始配置更新的版本。要查看它，請運行以下命令。順便說一句，我們注意到這可能是 Kubernetes 歷史上最好的俏皮話之一：
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
結論：
pids_limit = 2048
現在讓我們確保配置已套用至所有主節點。首先我們取得叢集中的節點列表：
oc get node | grep master
Output:
ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
現在讓我們看看安裝的檔案。您將看到該檔案已更新為我們在 ContainerRuntimeConfig 資源中指定的 pid 和 debug 指令的新值。優雅本身：
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
結論：
...
pids_limit = 2048
...
log_level = "debug"
...
對叢集的所有這些更改甚至都沒有運行 SSH。所有工作都是透過造訪Kuberentes主節點來完成的。也就是說，這些新參數僅在主節點上配置。工作節點沒有改變，這證明了 Kubernetes 方法的好處，即使用與容器主機和具有可互換元素的容器引擎相關的指定和實際狀態。
上面的範例展示了對具有三個生產節點的小型 OpenShift Container Platform 4 叢集或具有 3000 個節點的大型生產叢集進行變更的能力。無論如何，工作量都是相同的 - 而且非常小 - 只需配置 ContainerRuntimeConfig 文件，並更改 MachineConfigPool 中的一個標籤。您可以使用在整個生命週期中執行 Kubernetes 的任何版本的 OpenShift Container Platform 4.X 來執行此操作。
通常，科技公司發展得如此之快，以至於我們無法解釋為什麼我們為底層組件選擇某些技術。容器引擎歷來是使用者直接互動的元件。由於容器的流行自然是隨著容器引擎的出現而開始的，因此使用者經常對它們表現出興趣。這也是紅帽選擇CRI-O的另一個原因。容器正在不斷發展，現在的重點是編排，我們發現 CRI-O 在使用 OpenShift 4 時提供了最佳體驗。
來源： www.habr.com