コンテナーからコンベアへ: CRI-O が OpenShift Container Platform 4 のデフォルトになりました

プラットフォーム Red Hat OpenShift コンテナ プラットフォーム 4 作成を効率化できます コンテナをデプロイするためのホストこれには、クラウド サービス プロバイダーのインフラストラクチャ、仮想化プラットフォーム、またはベアメタル システムが含まれます。 真のクラウドベースのプラットフォームを作成するには、使用されるすべての要素を厳密に制御し、複雑な自動化プロセスの信頼性を高める必要がありました。

明らかな解決策は、Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux のバリアント) と CRI-O を標準として使用することでした。その理由は次のとおりです...

セーリングのトピックは、Kubernetes とコンテナーの動作を説明するときに類似点を見つけるのに非常に適したトピックなので、例を使用して、CoreOS と CRI-O が解決するビジネス上の問題について話してみましょう。 ブルネルのリギングブロック製造のための発明。 1803 年、マーク ブルネルは、成長する英国海軍のニーズに応えて 100 個の艤装ブロックを製造する任務を与えられました。 リギングブロックは、帆にロープを取り付けるために使用される索具の一種です。 19 世紀初頭まで、これらのブロックは手作業で作られていましたが、ブルネルは生産を自動化することに成功し、工作機械を使用して標準化されたブロックを生産し始めました。 このプロセスの自動化は、結果として得られるブロックが本質的に同一であり、壊れた場合に簡単に交換でき、大量に生産できることを意味しました。

ここで、ブルネルが 20 の異なる船モデル (Kubernetes バージョン) と、まったく異なる海流と風を持つ XNUMX つの異なる惑星 (クラウド プロバイダー) に対してこの作業を実行しなければならなかった場合を想像してください。 また、航行が行われる惑星に関係なく、船長（クラスターの運用を管理するオペレーター）の観点からは、すべての船（OpenShiftクラスター）が同じ動作をすることが求められました。 海洋の例えを続けると、船長は自分の船でどのような種類の艤装ブロック (CRI-O) が使用されているかをまったく気にしません。彼らにとって重要なことは、これらのブロックが強力で信頼性があるということです。

OpenShift 4 は、クラウド プラットフォームとして、非常に似たビジネス上の課題に直面しています。 クラスターの作成時、いずれかのノードで障害が発生した場合、またはクラスターのスケーリング時に、新しいノードを作成する必要があります。 新しいノードを作成して初期化するときは、CRI-O などの重要なホスト コンポーネントをそれに応じて構成する必要があります。 他の制作と同様に、最初に「原材料」を供給する必要があります。 船舶の場合、原材料は金属と木材です。 ただし、OpenShift 4 クラスターにコンテナーをデプロイするためのホストを作成する場合は、設定ファイルと API が提供するサーバーを入力として使用する必要があります。 OpenShift は、ライフサイクル全体を通じて必要なレベルの自動化を提供し、必要な製品サポートをエンドユーザーに提供して、プラットフォームへの投資を回収します。

OpenShift 4 は、すべての主要なクラウド コンピューティング プロバイダー、仮想化プラットフォーム、さらにはベア メタル システムに対して、プラットフォーム (バージョン 4.X) のライフサイクル全体を通じてシステムを簡単に更新できる機能を提供するように作成されました。 これを行うには、交換可能な要素に基づいてノードを作成する必要があります。 クラスターが新しいバージョンの Kubernetes を必要とする場合、クラスターは CoreOS 上の対応するバージョンの CRI-O も受け取ります。 CRI-O バージョンは Kubernetes に直接関連付けられているため、テスト、トラブルシューティング、またはサポートの目的での変更が大幅に簡素化されます。 さらに、このアプローチにより、エンドユーザーと Red Hat のコストが削減されます。

これは、Kubernetes クラスターに関する根本的に新しい考え方であり、非常に便利で魅力的な新機能を計画するための基礎を築きます。 CRI-O (Container Runtime Interface - Open Container Initiative、略称 CRI-OCI) は、OpenShift と連携するために必要なノードを大量に作成する場合に最も成功した選択肢であることが判明しました。 CRI-O は、以前に使用されていた Docker エンジンを置き換え、OpenShift ユーザーに提供します 経済的、安定、シンプル、退屈 – はい、そうです。Kubernetes で作業するために特別に作成された退屈なコンテナ エンジンです。

オープンコンテナの世界

世界は長い間、オープンコンテナに向かって進んできました。 Kubernetes であろうと下位レベルであろうと、 コンテナ規格の開発 その結果、あらゆるレベルでイノベーションのエコシステムが生まれます。

すべては Open Containers Initiative の創設から始まりました 6月の年に2015。 この作業の初期段階で、コンテナの仕様が作成されました。 画像 и 実行時環境。 これにより、ツールが単一の標準を使用できるようになりました。 コンテナイメージ そしてそれらを扱うための統一フォーマット。 仕様は後から追加されました 分布、ユーザーが簡単に共有できるようにします コンテナイメージ.

その後、Kubernetes コミュニティは、と呼ばれるプラグイン可能なインターフェイスの単一標準を開発しました。 コンテナ ランタイム インターフェイス (CRI)。 このおかげで、Kubernetes ユーザーは、Docker に加えて、さまざまなエンジンを接続してコンテナーを操作できるようになりました。

Red Hat と Google のエンジニアは、CRI プロトコル経由で Kubelet リクエストを受け入れることができるコンテナ エンジンに対する市場のニーズを認識し、前述の OCI 仕様と互換性のあるコンテナを導入しました。 それで OCID登場。 でもすみません、この資料は CRI-O に捧げると言いませんでしたか? 実はそうなんです、リリースされただけで バージョン1.0 プロジェクトの名前は CRI-O に変更されました。

図。 1。

CRI-O と CoreOS によるイノベーション

OpenShift 4 プラットフォームのリリースにより、変更されました。 コンテナエンジンはプラットフォームでデフォルトで使用され、Docker は CRI-O に置き換えられ、Kubernetes と並行して開発するコンテナーを実行するための、コスト効率が高く、安定した、シンプルで退屈な環境を提供しました。 これにより、クラスターのサポートと構成が大幅に簡素化されます。 コンテナ エンジンとホストの設定とその管理は、OpenShift 4 内で自動化されます。

ちょっと待って、これはどうですか？

そうです、OpenShift 4 の登場により、個々のホストに接続してコンテナ エンジンをインストールしたり、ストレージを構成したり、検索サーバーを構成したり、ネットワークを構成したりする必要がなくなりました。 OpenShift 4 プラットフォームは、 オペレーターフレームワーク これは、エンドユーザー アプリケーションの観点だけでなく、イメージの展開、システムの構成、更新のインストールなどの基本的なプラットフォーム レベルの操作の観点からも同様です。

Kubernetes では常に、ユーザーが望ましい状態を定義し、 コントローラー、実際の状態がターゲットの状態と可能な限り一致するようにします。 これ 目標状態と実際の状態のアプローチ 開発と運用の両方の観点から大きなチャンスが生まれます。 開発者は次のようにして必要な状態を定義できます。 それを渡す YAML または JSON ファイルの形式でオペレーターに送信すると、オペレーターは実稼働環境で必要なアプリケーション インスタンスを作成でき、このインスタンスの動作状態は指定されたものに完全に対応します。

OpenShift 4 は、プラットフォームで Operator を使用することにより、この新しいパラダイム (セット状態と実際の状態の概念を使用) を RHEL CoreOS および CRI-O の管理にもたらします。 オペレーティング システムとコンテナ エンジンのバージョンを構成および管理するタスクは、いわゆる マシン構成オペレーター (MCO)。 MCO はクラスター管理者の作業を大幅に簡素化し、基本的にインストールの最終段階とその後のインストール後の操作 (4 日目の操作) を自動化します。 これらすべてにより、OpenShift XNUMX は真のクラウド プラットフォームになります。 これについては少し後で説明します。

コンテナの実行

ユーザーは、Tech Preview ステータスのバージョン 3.7 以降、および一般利用可能ステータス (現在サポートされている) のバージョン 3.9 以降、OpenShift プラットフォームで CRI-O エンジンを使用する機会がありました。 さらに、Red Hat は 実稼働ワークロードを実行するための CRI-O バージョン 3.10 以降の OpenShift Online。 これらすべてにより、CRI-O に取り組んでいるチームは、大規模な Kubernetes クラスターでのコンテナーの大量起動に関する広範な経験を得ることができました。 Kubernetes が CRI-O をどのように使用するかを基本的に理解するために、アーキテクチャがどのように機能するかを示す次の図を見てみましょう。

米。 2. Kubernetes クラスター内でコンテナーがどのように動作するか

CRI-O は、新しいノードの初期化時と OpenShift プラットフォームの新しいバージョンのリリース時にトップレベル全体を同期することにより、新しいコンテナー ホストの作成を簡素化します。 プラットフォーム全体の改訂により、トランザクションの更新/ロールバックが可能になり、コンテナ テール コア、コンテナ エンジン、ノード (Kubelet)、および Kubernetes マスター ノード間の依存関係におけるデッドロックも防止されます。 すべてのプラットフォーム コンポーネントを制御とバージョン管理で集中管理することにより、状態 A から状態 B への明確なパスが常に存在します。これにより、更新プロセスが簡素化され、セキュリティが向上し、パフォーマンス レポートが改善され、更新と新しいバージョンのインストールのコストが削減されます。 。

交換要素の威力を実証

前述したように、Machine Config Operator を使用して OpenShift 4 のコンテナーホストとコンテナーエンジンを管理すると、Kubernetes プラットフォームでは以前は不可能だった新しいレベルの自動化が実現します。 新しい機能をデモンストレーションするために、crio.conf ファイルに変更を加える方法を示します。 用語による混乱を避けるために、結果に焦点を当てるようにしてください。

まず、いわゆるコンテナ ランタイム構成、Container Runtime Config を作成しましょう。 これは、CRI-O の構成を表す Kubernetes リソースと考えてください。 実際には、これは MachineConfig と呼ばれるものの特殊バージョンであり、OpenShift クラスターの一部として RHEL CoreOS マシンにデプロイされる構成です。

ContainerRuntimeConfig と呼ばれるこのカスタム リソースは、クラスター管理者が CRI-O を構成しやすくするために作成されました。 このツールは非常に強力であるため、MachineConfigPool 設定に応じて特定のノードにのみ適用できます。 同じ目的を果たすマシンのグループとして考えてください。

/etc/crio/crio.conf ファイル内で変更する最後の XNUMX 行に注目してください。 これら XNUMX つの行は 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 の XNUMX つを変更して、この構成をクラスター内の特定のマシン グループに適用することを 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 の歴史の中で最高のワンライナーの XNUMX つです。

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 方法論の利点を示しています。

上記の例は、4 つの本番ノードを備えた小規模な OpenShift Container Platform 3000 クラスター、または 4 ノードを備えた巨大な本番クラスターに変更を加える機能を示しています。 いずれの場合も、作業量は同じで非常に少なく、ContainerRuntimeConfig ファイルを構成し、MachineConfigPool 内の XNUMX つのラベルを変更するだけです。 また、これは、ライフサイクル全体を通じて Kubernetes を実行する OpenShift Container Platform XNUMX.X のどのバージョンでも行うことができます。

多くの場合、テクノロジー企業はあまりに急速に進化するため、基盤となるコンポーネントに特定のテクノロジーを選択する理由を説明できなくなります。 コンテナ エンジンは歴史的に、ユーザーが直接操作するコンポーネントでした。 コンテナの人気はコンテナ エンジンの出現とともに自然に始まったため、ユーザーはコンテナに興味を示すことがよくあります。 これが、Red Hat が CRI-O を選択したもう 4 つの理由です。 コンテナは現在オーケストレーションに重点を置いて進化しており、OpenShift XNUMX を使用する場合は CRI-O が最高のエクスペリエンスを提供することがわかりました。

出所： habr.com