cri o
1.31.2
CRI-O は、マイナー バージョン ( 1.xy ) に関して Kubernetes リリース サイクルに従います。 Kubernetes のパッチ リリース ( 1.xz ) は、CRI-O のパッチ リリース ( 1.xz ) とは同期していません。これは、CRI-O が必要な場合にのみパッチ リリースを提供するのに対し、パッチ リリースは毎月スケジュールされるためです。 Kubernetes リリースがサポート終了になった場合、対応する CRI-O バージョンも同様に考慮することができます。
これは、CRI-O が機能の卒業、非推奨、または削除に関して、Kubernetes n-2リリース バージョンのスキュー ポリシーにも従うことを意味します。これは、Kubernetes から独立した機能にも当てはまります。それでも、Kubernetes や cri-tools などの他のツールから独立した、サポートされているリリース ブランチへの機能のバックポートは依然として可能です。これにより、CRI-O は Kubernetes リリース サイクルから切り離され、新機能の実装に関して十分な柔軟性が得られます。バックポートされるすべての機能はコミュニティのケースバイケースで決定されますが、全体的な互換性マトリックスが侵害されるべきではありません。
詳細については、「Kubernetes バージョン スキュー ポリシー」を参照してください。
| CRI-O | Kubernetes | メンテナンス状況 |
|---|---|---|
main | masterブランチ | メインの Kubernetes リポジトリの機能が積極的に実装されています |
release-1.xブランチ ( v1.xy ) | release-1.xブランチ ( v1.xz ) | メンテナンスは手動で行われ、バグ修正のみがバックポートされます。 |
CRI-O のリリース ノートは手作業で作成されており、GitHub ページ Web サイトから継続的に取得できます。
CRI-O は、OCI 準拠のランタイムと Kubelet 間の統合パスを提供することを目的としています。具体的には、OCI 準拠のランタイムを使用して Kubelet Container Runtime Interface (CRI) を実装します。 CRI-O の範囲は CRI の範囲に関連付けられています。
大まかに言えば、CRI-O の範囲は次の機能に制限されることが予想されます。
CRI-O は、Kubernetes が Open Container Initiative (OCI) コンテナを直接起動して管理できるようにする Kubernetes Container Runtime Interface (CRI) の実装です。
計画では、OCI プロジェクトと最高のライブラリをさまざまな側面に使用する予定です。
現在、Kubernetes コミュニティで設計提案を通じて積極的に開発が行われています。質問や問題は、Kubernetes シグノード Slack チャネルで提起する必要があります。
CRI-O の方向性を説明するロードマップは、こちらでご覧いただけます。このプロジェクトは、機能ロードマップ GitHub プロジェクトの一環として、進行中のすべての取り組みを追跡しています。
CRI-O の CI は、GitHub アクションと OpenShift CI (Prow) に分割されています。 prow ジョブに使用される関連する仮想マシン イメージは、ジョブ内で定期的に構築されます。
ジョブは openshift/release リポジトリから維持され、特定のジョブに使用されるワークフローを定義します。実際のジョブ定義は、メイン ブランチの ci-operator/jobs/cri-o/cri-o/cri-o-cri-o-main-presubmits.yaml の下にある同じリポジトリと、 mainブランチの対応するファイルにあります。リリース分岐。これらのジョブの基本イメージ構成は、同じリポジトリの ci-operator/config/cri-o/cri-o にあります。
| 指示 | 説明 |
|---|---|
| クリオ(8) | OCI Kubernetesコンテナ・ランタイム・デーモン |
CRI-O (または他の CRI 互換ランタイム) と対話するコマンドライン ツールの例としては、Crictl や Podman があります。
| ファイル | 説明 |
|---|---|
| crio.conf(5) | CRI-O設定ファイル |
| ポリシー.json(5) | 署名検証ポリシー ファイル |
| レジストリ.conf(5) | レジストリ設定ファイル |
| ストレージ.conf(5) | ストレージ構成ファイル |
脆弱性を報告するためのセキュリティ プロセスは、SECURITY.md に説明されています。
コンテナの作成時に OCI フックを挿入するように CRI-O を構成できます。
CRI-Oを活用したインフラに関する運用や開発移管に役立つ情報を提供します。
非同期通信や長時間にわたるディスカッションについては、GitHub リポジトリのイシューとプル リクエストを使用してください。ここは、設計と実装について話し合うのに最適な場所です。
チャットコミュニケーションについては、Kubernetes Slack にチャンネルがあり、誰でも参加して開発についてチャットすることができます。
当社では、CRI-O に関連する厳選されたリンクのリストを管理しています。このプロジェクトに関してウェブ上で何か興味深いものを見つけましたか?すばらしいですね。お気軽に PR を開いてリストに追加してください。
CRI-Oインストールするには、インストール ガイドに従ってください。あるいは、ソースからCRI-Oを構築したい場合は、セットアップ ガイドを確認してください。
始める前に、CRI-O を起動する必要があります
local-up-cluster.shを使用して、 CRI-Oで Kubernetes のローカル バージョンを実行できます。
CGROUP_DRIVER=systemd
CONTAINER_RUNTIME=remote
CONTAINER_RUNTIME_ENDPOINT='unix:///var/run/crio/crio.sock'
./hack/local-up-cluster.sh CRI-O実行に関する詳細なガイダンスについては、チュートリアル ページをご覧ください。
CRI-O は、デフォルトで gRPC API を公開し、Kubernetes のコンテナ ランタイム インターフェイス (CRI) を実現します。これに加えて、CRI-O に関するさらなる実行時ステータス情報を取得するための追加の HTTP API が存在します。この API は安定しているとはみなされていないため、実稼働ユースケースではこれに依存すべきではないことに注意してください。
実行中の CRI-O インスタンスでは、curl のような HTTP 転送ツールを介して API にアクセスできます。
$ sudo curl -v --unix-socket /var/run/crio/crio.sock http://localhost/info | jq
{
"storage_driver": "btrfs",
"storage_root": "/var/lib/containers/storage",
"cgroup_driver": "systemd",
"default_id_mappings": { ... }
}現在、次の API エントリ ポイントがサポートされています。
| パス | コンテンツタイプ | 説明 |
|---|---|---|
/info | application/json | storage_driverやstorage_rootなど、ランタイムに関する一般情報。 |
/containers/:id | application/json | name 、 pid 、 imageの専用のコンテナ情報。 |
/config | application/toml | CRI-O によって使用される完全な TOML 構成 (デフォルトは/etc/crio/crio.conf )。 |
/pause/:id | application/json | 実行中のコンテナを一時停止します。 |
/unpause/:id | application/json | 一時停止したコンテナの一時停止を解除します。 |
/debug/goroutines | text/plain | goroutine スタックを出力します。 |
/debug/heap | text/plain | ヒープダンプを書き込みます。 |
サブコマンドcrio status使用すると、専用のコマンド ライン ツールで API にアクセスできます。専用のサブコマンドconfig 、 info 、 containers介してすべての API エンドポイントをサポートします。次に例を示します。
$ sudo crio status info
cgroup driver: systemd
storage driver: btrfs
storage root: /var/lib/containers/storage
default GID mappings (format <container>:<host>:<size>):
0:0:4294967295
default UID mappings (format <container>:<host>:<size>):
0:0:4294967295 CRI-O メトリック ガイドを参照してください。
CRI-O トレース ガイドを参照してください。
Container Runtime のいくつかの側面には、追加の説明が必要です。これらの詳細は専用ガイドにまとめられています。
何か問題がありますか?デバッグ ガイドには、デバッグに関するいくつかのヒントとコツが記載されています。
実稼働環境における CRI-O の採用者の不完全なリストは、ここで見つけることができます。ユーザーの方は、プルリクエストを送信して完成にご協力ください。
CRI-O の開発について話し合うために毎週会議が開催されます。誰でも参加できます。ミーティングに参加するための詳細は wiki にあります。
CRI-O がどのように管理されているかについて詳しくは、ガバナンス ファイルをご覧ください。
