Containerd の使い方を 1 つの記事で解説

Containerd の使い方を 1 つの記事で解説

[[417270]]

Containerd を学習する前に、Docker の開発履歴を簡単に確認する必要があります。これは、Docker には非常に多くのコンポーネントが関係しているためです。 libcontainer、runc、containerd、CRI、OCI など、よく耳にするけれど、何に使われるのか分からないものがたくさんあります。

ドッカー

Docker バージョン 1.11 以降では、Docker コンテナの操作は、Docker Daemon を介して単純に起動されるのではなく、containerd や runc などの複数のコンポーネントを統合して完了するようになりました。 Docker Daemon モジュールは継続的にリファクタリングされていますが、基本的な機能と位置付けはあまり変わっていません。それは常に CS アーキテクチャでした。デーモンは、Docker クライアントと対話し、Docker イメージとコンテナを管理する役割を担います。現在のアーキテクチャでは、containerd コンポーネントがクラスター ノード上のコンテナーのライフサイクル管理を担当し、Docker デーモンに gRPC インターフェイスを提供します。

Docker アーキテクチャ

コンテナを作成したい場合、Docker Daemon はコンテナを直接作成することはできません。代わりに、containerd にコンテナの作成を要求します。 containerd はリクエストを受け取った後、コンテナを直接操作するのではなく、containerd-shim というプロセスを作成してコンテナを操作します。コンテナ プロセスには、ステータスを収集したり、stdin やその他の fd を開いたままにしたりするために親プロセスが必要であることを指定します。親プロセスが containerd の場合、containerd がハングアップすると、ホスト マシン全体のすべてのコンテナを終了する必要があります。 containerd-shim を導入することでこの問題を回避できます。

次に、コンテナを作成するには、いくつかの名前空間と cgroup を構成し、ルート ファイル システムをマウントするなどの操作を行う必要があります。これらの操作には、実は OCI (Open Container Standard) という標準仕様があり、runc はそのリファレンス実装です (Docker は libcontainer を寄贈せざるを得なくなり、runc に名前が変更されました)。この標準は、実際には、コンテナ イメージの構造と、作成、開始、停止、削除などのコマンドなど、コンテナが受信する必要がある操作指示を主に指定するドキュメントです。 runc は、この OCI ドキュメントに従って仕様に準拠したコンテナを作成できます。これは標準なので、他の OCI 実装も存在するはずです。たとえば、Kata や gVisor など、これらのコンテナ ランタイムはすべて OCI 標準に準拠しています。

したがって、コンテナの実際の起動は、containerd-shim が runc を呼び出してコンテナを起動することによって行われます。 runc はコンテナを起動した後、直接終了します。 Containerd-shim はコンテナ プロセスの親プロセスとなり、コンテナ プロセスのステータスを収集して containerd に報告し、コンテナ内の pid 1 のプロセスが終了した後にコンテナ内の子プロセスを引き継いでクリーンアップを行い、ゾンビ プロセスが発生しないようにします。

Docker は現在 Swarm に取り組んでおり、PaaS 市場に参入したいと考えていたため、すべてのコンテナ操作を containerd に移行しました。このアーキテクチャ分割により、Docker Daemon が上位レベルのカプセル化とオーケストレーションを担当するようになりました。もちろん、ご存知のとおり、Swarm は Kubernetes の前では惨めな失敗でした。その後、Docker は containerd プロジェクトを CNCF Foundation に寄贈しました。これが現在の Docker アーキテクチャでもあります。

クリ

Kubernetes が CRI コンテナ ランタイム インターフェイスを提供することはわかっていますが、この CRI とは一体何でしょうか?これは実際には Docker の開発と密接に関係しています。

Kubernetes の初期の頃は、Docker が非常に人気があったため、Kubernetes は当然最初に Docker をサポートすることを選択し、ハードコードされた方法で Docker API を直接呼び出しました。その後、Docker の継続的な開発と Google の優位性により、さらに多くのコンテナ ランタイムが登場しました。より合理化されたコンテナ ランタイムをサポートするために、Kubernetes、Google、Red Hat は共同で CRI 標準を立ち上げ、Kubernetes プラットフォームを特定のコンテナ ランタイムから切り離しました (もちろん、主な目的は Docker を排除することです)。

CRI (Container Runtime Interface) は、基本的に、コンテナ ランタイムと対話するために Kubernetes によって定義された一連のインターフェイスであるため、この一連のインターフェイスを実装するすべてのコンテナ ランタイムを Kubernetes プラットフォームに接続できます。ただし、Kubernetes が CRI 標準を開始した当時は、現在のような支配的な地位を持っていなかったので、一部のコンテナ ランタイムでは CRI インターフェース自体が実装されていない可能性があります。そのため、シムが作成されました。シムの役割は、さまざまなコンテナ ランタイムのインターフェースを Kubernetes の CRI インターフェースに適合させるアダプターとして機能することです。 Dockershim は、CRI インターフェース上で Kubernetes を Docker に接続する shim 実装です。

クリシム

Kubelet は、gRPC フレームワークを介してコンテナ ランタイムまたは shim と通信します。その際、kubelet がクライアントとなり、CRI shim (またはコンテナ ランタイム自体) がサーバーとなります。

CRI (https://github.com/kubernetes/kubernetes/blob/release-1.5/pkg/kubelet/api/v1alpha1/runtime/api.proto) で定義されている API には、主に ImageService と RuntimeService という 2 つの gRPC サービスが含まれています。 ImageService サービスは主にイメージのプル、イメージの表示と削除などに使用され、RuntimeService は Pod とコンテナのライフサイクルの管理、コンテナと対話するための呼び出し (exec/attach/port-forward) やその他の操作に使用されます。これら 2 つのサービスのソケットは、kubelet のフラグ --container-runtime-endpoint と --image-service-endpoint を通じて構成できます。

クベレット クリ

ただし、ここでも例外があります。それは Docker です。当時の Docker の地位の高さから、Kubernetes は kubelet に dockershim を直接組み込んでいたため、Docker のようなコンテナ ランタイムを使用している場合は、構成アダプターを別途インストールする必要はありません。もちろん、この動きは Docker を麻痺させたようにも思えます。

ドッカーシム

ここで Docker を使用する場合、Kubernetes で Pod を作成すると、まず kubelet が CRI インターフェースを介して dockershim を呼び出して、コンテナの作成を要求します。 Kubelet は単純な CRI クライアントと見なすことができ、dockershim はリクエストを受信するサーバーですが、どちらも kubelet に組み込まれています。

dockershim はリクエストを受信すると、それを Docker Daemon が認識できるリクエストに変換し、Docker Daemon に送信してコンテナの作成を要求します。リクエストが Docker デーモンに到達した後、Docker がコンテナを作成し、containerd を呼び出し、次に containerd-shim プロセスを作成し、プロセスを通じて runc を呼び出して実際にコンテナを作成するというプロセスが続きます。

実際、注意深く観察すると、Docker を使用する場合、呼び出しチェーンが比較的長くなることが簡単にわかります。実際、containerd は実際のコンテナ関連の操作には十分です。 Docker は複雑すぎて扱いにくいです。もちろん、Docker が人気である大きな理由は、ユーザーフレンドリーな機能を多数提供していることですが、Kubernetes ではコンテナがすべてインターフェースを介して操作されるため、これらの機能はまったく必要ありません。そのため、コンテナ ランタイムを containerd に切り替えるのは自然なことです。

containerdへの切り替え

containerd に切り替えると仲介者が不要になり、以前と同じ操作エクスペリエンスが提供されますが、コンテナはコンテナ ランタイムを使用して直接スケジュールされるため、Docker からは見えなくなります。したがって、これらのコンテナを検査するために以前使用していた Docker ツールは機能しなくなります。

コンテナ情報を取得するために、docker ps コマンドまたは docker inspect コマンドを使用することはできなくなりました。コンテナを一覧表示できないため、ログを取得したり、コンテナを停止したり、docker exec 経由でコンテナ内でコマンドを実行したりすることはできません。

もちろん、イメージをダウンロードしたり、docker build コマンドでイメージをビルドしたりすることはできますが、Docker でビルドおよびダウンロードされたイメージは、コンテナ ランタイムと Kubernetes には表示されません。 Kubernetes で使用するには、イメージをイメージ リポジトリにプッシュする必要があります。

上図からわかるように、containerd 1.0 では、CRI の適応は別の CRI-Containerd プロセスを通じて完了します。これは、containerd が当初は他のシステム (swarm など) に適合されていたため、CRI が直接実装されていなかったためです。そこで、このドッキング作業はCRI-Containerd shimに引き継がれました。

その後、containerd 1.1 では、CRI-Containerd シムが削除され、適応ロジックがプラグインとして containerd メイン プロセスに直接統合されました。今では、このような呼び出しはより簡潔になっています。

コンテナド cri

同時に、Kubernetes コミュニティは、CRI および OCI 仕様と直接互換性のある、Kubernetes 専用の CRI ランタイムである CRI-O も開発しました。

クリオ

このソリューションと containerd ソリューションは、デフォルトの dockershim ソリューションよりも明らかにはるかにシンプルです。ただし、ほとんどのユーザーは Docker の使用に慣れているため、依然として dockershim ソリューションの使用を好みます。

ただし、CRI ソリューションの開発と、他のコンテナー ランタイムによる CRI のサポートがますます充実するにつれて、Kubernetes コミュニティは 2020 年 7 月に dockershim ソリューションの削除を開始しました: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim。現在の削除計画は、バージョン 1.20 の kubelet に組み込まれている dockershim コードを分離し、組み込みの dockershim をメンテナンス モードとしてマークすることです。もちろん、この時点でも dockershim は使用できます。目標は、バージョン 1.23/1.24 で dockershim なしのバージョンをリリースすることです (コードはまだ存在しますが、デフォルトですぐに使用できる docker をサポートするには、kubelet を自分でビルドする必要があり、組み込みの dockershim コードは一定の猶予期間後に kubelet から削除されます)。

これは、Kubernetes が Docker をサポートしなくなったことを意味しますか?もちろん違います。これは組み込みの dockershim 関数のみを非推奨にします。 Docker とその他のコンテナ ランタイムは同等に扱われ、組み込みサポートは個別に扱われません。引き続き Docker などのコンテナ ランタイムを直接使用したい場合はどうすればよいでしょうか? dockershim 関数は、containerd 1.0 で提供される CRI-Containerd に類似した cri-dockerd として抽出して独立して保守できます。もちろん、別の方法としては、Docker 公式コミュニティが CRI インターフェースを Dockerd に組み込んで実装する方法があります。

ただし、Dockerd も Containerd を直接呼び出すことがわかっており、CRI はバージョン 1.1 以降で containerd に実装されているため、Docker が CRI を別途実装する必要はありません。 Kubernetes に Docker の組み込みサポートがなくなった場合、最善の方法は、もちろん、実稼働環境にも導入されているコンテナ ランタイムである Containerd を直接使用することです。次に、Containerd の使い方を学びましょう。

コンテナ

containerd は長い間 Docker Engine に含まれていましたが、現在では、よりオープンで安定したコンテナ運用インフラストラクチャを提供することを目標に、containerd は独立したオープンソース プロジェクトとして Docker Engine から分離されました。分離された containerd にはさらに多くの機能があり、コンテナのランタイム管理全体のニーズをすべてカバーし、より強力なサポートを提供します。

Containerd は、シンプルさ、堅牢性、移植性を重視した業界標準のコンテナ ランタイムです。 Containerd は次のタスクを担当します。

  • コンテナのライフサイクルを管理する（コンテナの作成から破棄まで）
  • コンテナイメージのプル/プッシュ
  • ストレージ管理（画像やコンテナデータのストレージを管理）
  • runc を呼び出してコンテナを実行します (runc などのコンテナ ランタイムと対話します)
  • コンテナのネットワークインターフェースとネットワークの管理

建築

Linux および Windows のデーモンとして利用可能な containerd は、イメージの転送と保存からコンテナの実行と監視、基盤となるストレージ、ネットワーク接続など、ホスト システム上のコンテナのライフサイクル全体を管理します。

コンテナアーキテクチャ

上図はcontainerdが公式に提供しているアーキテクチャ図です。 containerdもC/Sアーキテクチャを採用していることがわかります。サーバーは、UNIX ドメイン ソケットを通じて低レベルの gRPC API インターフェースを公開します。クライアントはこれらの API を通じてノード上のコンテナを管理します。各 containerd は 1 台のマシンのみを担当します。イメージのプル、コンテナ操作（開始、停止など）、ネットワーク、ストレージはすべて containerd によって完了します。 Runc はコンテナの実行を担当します。実際、OCI 仕様に準拠するコンテナであればどれでもサポートできます。

分離を実現するために、containerd はシステムをさまざまなコンポーネントに分割します。各コンポーネントは、1 つ以上のモジュール (コア部分) によって完成されます。各タイプのモジュールはプラグインの形で Containerd に統合されており、プラグインは相互に依存しています。たとえば、上図の長い破線のボックスはそれぞれ、サービス プラグイン、メタデータ プラグイン、GC プラグイン、ランタイム プラグインなどのプラグインの種類を表し、サービス プラグインはメタデータ プラグイン、GC プラグイン、ランタイム プラグインに依存しています。それぞれの小さなボックスは、細分化されたプラグインを表します。たとえば、メタデータ プラグインは、コンテナー プラグイン、コンテンツ プラグインなどに依存します。例えば：

  • コンテンツ プラグイン: 画像内のアドレス指定可能なコンテンツへのアクセスを提供します。すべての不変のコンテンツはここに保存されます。
  • スナップショット プラグイン: コンテナ イメージのファイル システム スナップショットを管理するために使用されます。イメージ内の各レイヤーは、Docker の graphdriver と同様に、ファイル システム スナップショットに解凍されます。

一般に、containerd はストレージ、メタデータ、ランタイムの 3 つの主要部分に分けられます。

コンテナアーキテクチャ 2

インストール

ここで使用しているシステムは Linux Mint 20.2 です。まず、seccomp の依存関係をインストールする必要があります。

  1.  ➜ ~ apt-getアップデート 
  2.  ➜ ~ apt-get install libseccomp2 -y

containerd は runc を呼び出す必要があるため、最初に runc もインストールする必要があります。ただし、containerd は関連する依存関係を含む圧縮パッケージ cri-containerd-cni-${VERSION}.${OS}-${ARCH}.tar.gz を提供しており、これを直接インストールに使用できます。まず、リリース ページから圧縮パッケージの最新バージョン (現在はバージョン 1.5.5) をダウンロードします。

  1.  ➜ ~ wget https://github.com/containerd/containerd/releases/download/v1.5.5/cri-containerd-cni-1.5.5-linux-amd64.tar.gz
  2.  # 制限がある場合は、ダウンロードを高速化するために次のURLに置き換えることもできます
  3. # wget https://download.fastgit.org/containerd/containerd/releases/download/v1.5.5/cri-containerd-cni-1.5.5-linux-amd64.tar.gz

tar の -t オプションを使用すると、圧縮されたパッケージに含まれるファイルを直接確認できます。

  1.  ➜ ~ tar -tf cri-containerd-cni-1.4.3-linux-amd64.tar.gz
  2. 等/
  3. など/cni/
  4. ディレクトリ
  5. etc/cni/net.d/10-containerd-net.conflist
  6.  .yaml ファイル
  7. システム
  8. システム
  9. etc/systemd/システム/containerd.service
  10. ユーザー/
  11.  usr/ローカル/
  12.  usr/ローカル/bin/
  13.  usr/ローカル/bin/containerd-shim-runc-v2
  14.  usr/ローカル/bin/ctr
  15.  usr/ローカル/bin/containerd-shim
  16.  usr/ローカル/bin/containerd-shim-runc-v1
  17.  usr/ローカル/bin/crictl
  18.  usr/ローカル/bin/critest
  19.  usr/ローカル/bin/containerd
  20.  usr/ローカル/sbin/
  21.  usr/ローカル/sbin/runc
  22. オプション/
  23. オプション/CNI/
  24.  opt/cni/bin/
  25.  opt/cni/bin/vlan
  26.  opt/cni/bin/host-ローカル 
  27.  opt/cni/bin/フランネル
  28. opt/cni/bin/ブリッジ
  29. opt/cni/bin/ホストデバイス
  30. opt/cni/bin/チューニング
  31. opt/cni/bin/ファイアウォール
  32. opt/cni/bin/帯域幅
  33. opt/cni/bin/ipvlan
  34. オプション/cni/bin/sbr
  35. オプション/cni/bin/dhcp
  36.  opt/cni/bin/ポートマップ
  37. opt/cni/bin/ptp
  38.  opt/cni/bin/静的 
  39.  opt/cni/bin/macvlan
  40.  opt/cni/bin/ループバック
  41. opt/コンテナd/
  42.  opt/コンテナd/クラスタ/
  43.  opt/containerd/クラスタ/バージョン
  44. opt/コンテナd/クラスタ/gce/
  45.  opt/containerd/cluster/gce/cni.テンプレート
  46. opt/containerd/cluster/gce/configure.sh
  47.  opt/containerd/cluster/gce/cloud-init/
  48.  opt/containerd/cluster/gce/cloud-init/master.yaml
  49.  opt/containerd/cluster/gce/cloud-init/node.yaml
  50.  opt/コンテナ/クラスタ/gce/env

圧縮パッケージをシステムのさまざまなディレクトリに直接解凍します。

  1.  ➜ ~ tar -C / -xzf cri-containerd-cni-1.5.5-linux-amd64.tar.gz

もちろん、~/.bashrc ファイルの PATH 環境変数に /usr/local/bin と /usr/local/sbin を追加することを忘れないでください。

  1. エクスポート PATH=$PATH:/usr/ローカル/bin:/usr/ローカル/sbin

次に、次のコマンドを実行して、すぐに有効にします。

  1.  ➜ ~ ソース ~/.bashrc

containerd のデフォルトの設定ファイルは /etc/containerd/config.toml です。次のコマンドを実行すると、デフォルト構成を生成できます。

  1.  ➜ ~ /etc/containerd ディレクトリに移動します
  2. ➜ ~ containerd 設定デフォルト> /etc/containerd/config.toml

上記でダウンロードした containerd 圧縮パッケージには etc/systemd/system/containerd.service ファイルが含まれているため、systemd を使用して containerd をデーモン プロセスとして実行するように構成できます。内容は以下のとおりです。

  1.  ➜ ~ cat /etc/systemd/system/containerd.service
  2.  [ユニット]
  3. 説明=containerd コンテナランタイム
  4. ドキュメント=https://containerd.io
  5.  =network.target local -fs.targetの後
  6.  
  7.  [サービス]
  8.  ExecStartPre=-/sbin/modprobe オーバーレイ
  9. ExecStart=/usr/ローカル/bin/containerd 
  10.  
  11. タイプ=通知
  12. 委任=はい
  13. キルモード=プロセス
  14. 再起動=常に
  15. 再起動秒数=5
  16.  # 制限値がゼロでない場合、会計オーバーヘッドによりパフォーマンスの問題が発生します
  17. #カーネル内。コンテナローカルアカウンティングを行うには、 cgroups を使用することをお勧めします。
  18.  LimitNPROC=無限大
  19. LimitCORE=無限大
  20. 制限NOFILE=1048576
  21.  # systemd バージョンがサポートしていない場合は、TasksMax をコメント化します。
  22.  # このバージョンをサポートするのはsystemd 226以上のみです。
  23. タスク最大=無限
  24. OOMScoreAdjust=-999 
  25.  
  26.  [インストール]
  27.  WantedBy =マルチユーザー.ターゲット

ここでは 2 つの重要なパラメーターがあります。

委任: このオプションにより、containerd とランタイムは、作成するコンテナの cgroup を管理できるようになります。このオプションが設定されていない場合、systemd はプロセスを独自の cgroup に移動し、containerd はコンテナのリソース使用量を正しく取得できなくなります。

KillMode: このオプションは、containerd プロセスを強制終了する方法を処理するために使用されます。デフォルトでは、systemd はプロセスの cgroup 内の containerd のすべての子プロセスを検索して終了します。 KillMode フィールドは次の値に設定できます。

  • コントロールグループ（デフォルト値）：現在のコントロールグループ内のすべての子プロセスが強制終了されます
  • プロセス: メインプロセスのみを強制終了する
  • 混合: メインプロセスはSIGTERMシグナルを受信し、子プロセスはSIGKILLシグナルを受信します。
  • なし: プロセスは終了されず、サービスの停止コマンドのみが実行されます。

containerd をアップグレードまたは再起動するときに既存のコンテナが強制終了されないようにするには、KillMode 値を process に設定する必要があります。

次のコマンドを実行して、containerd を起動できます。

  1.  ➜ ~ systemctl コンテナを有効にする--now  

起動が完了したら、たとえば containerd のローカル CLI ツール ctr を使用してバージョンを確認できます。

ctr バージョン

構成

まず、上記で生成されたデフォルトの設定ファイル /etc/containerd/config.toml を見てみましょう。

  1. 無効なプラグイン = []
  2. インポート = []
  3. スコア = 0
  4. プラグインディレクトリ = ""  
  5. 必要なプラグイン = []
  6. ルート = "/var/lib/containerd"  
  7. 状態 = "/run/containerd"  
  8. バージョン = 2 
  9.  
  10.  [cグループ]
  11.   パス = ""   
  12.  
  13.  [デバッグ]
  14.   アドレス = ""  
  15.   フォーマット = ""  
  16.   識別子 = 0
  17. レベル= ""  
  18.   ユーザID = 0 
  19.  
  20.  [grpc]
  21.   アドレス = "/run/containerd/containerd.sock"  
  22.   識別子 = 0
  23.   最大受信メッセージサイズ = 16777216
  24.   最大送信メッセージサイズ = 16777216
  25.   tcp_address = ""  
  26.   tcp_tls_cert = ""  
  27.   tcp_tls_key = ""  
  28.   ユーザID = 0 
  29.  
  30.  [メトリクス]
  31.   アドレス = ""  
  32.   grpc_histogram =偽  
  33.  
  34.  [プラグイン] 
  35.  
  36.   [プラグイン。 ["io.containerd.gc.v1.スケジューラ" ]
  37.     削除しきい値 = 0
  38.     突然変異閾値 = 100
  39.     一時停止しきい値 = 0.02
  40.     スケジュール遅延 = "0秒"  
  41.     起動遅延 = "100ms"   
  42.  
  43.   [プラグイン。 [[io.containerd.grpc.v1.cri] ]
  44.     無効_apparmor = false  
  45.     無効_cgroup =偽 
  46.     無効にする_hugetlb_controller = true  
  47.     proc_mount を無効にする = false  
  48.     無効_tcp_service = true  
  49.     enable_selinux =偽 
  50.     enable_tls_streaming =偽 
  51.     ignore_image_defined_volumes = false  
  52.     最大同時ダウンロード数 = 3
  53.     最大コンテナログ行サイズ = 16384
  54.     netns_mounts_under_state_dir =偽 
  55.     restrict_oom_score_adj =偽 
  56.     サンドボックスイメージ = "k8s.gcr.io/pause:3.5"  
  57.     selinux_category_range = 1024
  58.     統計収集期間 = 10
  59.     stream_idle_timeout = "4時間0分0秒"  
  60.     ストリームサーバーのアドレス = "127.0.0.1"  
  61.     ストリームサーバーポート = "0"  
  62.     systemd_cgroup =偽 
  63.     tolerate_missing_hugetlb_controller = true  
  64.     seccomp_profile の設定を解除 = ""   
  65.  
  66.     [プラグイン。 ["io.containerd.grpc.v1.cri" .cni]
  67.       bin_dir = "/opt/cni/bin"  
  68.       conf_dir = "/etc/cni/net.d"  
  69.       conf_template = ""  
  70.       最大会議数 = 1 
  71.  
  72.     [プラグイン。 ["io.containerd.grpc.v1.cri" .containerd]
  73.       default_runtime_name = "runc"  
  74.       スナップショット注釈を無効にする = true  
  75.       パックされていないレイヤーを破棄 = false  
  76.       ピボットなし =偽 
  77.       スナップショット = "overlayfs"   
  78.  
  79.       [プラグイン。 ["io.containerd.grpc.v1.cri" .containerd.default_runtime]
  80.         ベースランタイムスペック = ""  
  81.         コンテナ注釈 = []
  82.         ポッド注釈 = []
  83.         ホストデバイスなしの特権 = false  
  84.         ランタイムエンジン = ""  
  85.         ランタイムルート = ""  
  86.         ランタイムタイプ = ""   
  87.  
  88.         [プラグイン。 ["io.containerd.grpc.v1.cri" .containerd.default_runtime.options] 
  89.  
  90.       [プラグイン。 ["io.containerd.grpc.v1.cri" .containerd.runtimes] 
  91.  
  92.         [プラグイン。 「io.containerd.grpc.v1.cri」 .containerd.runtimes.runc]
  93.           ベースランタイムスペック = ""  
  94.           コンテナ注釈 = []
  95.           ポッド注釈 = []
  96.           ホストデバイスなしの特権 = false  
  97.           ランタイムエンジン = ""  
  98.           ランタイムルート = ""  
  99.           runtime_type = "io.containerd.runc.v2"   
  100.  
  101.           [プラグイン。 「io.containerd.grpc.v1.cri」 .containerd.runtimes.runc.options]
  102.             バイナリ名 = ""  
  103.             CriuImagePath = ""  
  104.             クリウパス = ""  
  105.             CriuWorkPath = ""  
  106.             イオギッド = 0
  107.             IoUid = 0
  108.             NoNewKeyring = false  
  109.             NoPivotRoot =偽 
  110.             ルート = ""  
  111.             ShimCグループ = ""  
  112.             SystemdCgroup =偽  
  113.  
  114.       [プラグイン。 ["io.containerd.grpc.v1.cri" .containerd.untrusted_workload_runtime]
  115.         ベースランタイムスペック = ""  
  116.         コンテナ注釈 = []
  117.         ポッド注釈 = []
  118.         ホストデバイスなしの特権 = false  
  119.         ランタイムエンジン = ""  
  120.         ランタイムルート = ""  
  121.         ランタイムタイプ = ""   
  122.  
  123.         [プラグイン。 ["io.containerd.grpc.v1.cri" .containerd.untrusted_workload_runtime.options] 
  124.  
  125.     [プラグイン。 「io.containerd.grpc.v1.cri」 .image_decryption]
  126.       key_model = "ノード"   
  127.  
  128.     [プラグイン。 ["io.containerd.grpc.v1.cri" .レジストリ]
  129.       config_path = ""   
  130.  
  131.       [プラグイン。 ["io.containerd.grpc.v1.cri" .registry.auths] 
  132.  
  133.       [プラグイン。 ["io.containerd.grpc.v1.cri" .registry.configs] 
  134.  
  135.       [プラグイン。 ["io.containerd.grpc.v1.cri" .registry.headers] 
  136.  
  137.       [プラグイン。 ["io.containerd.grpc.v1.cri" .registry.mirrors] 
  138.  
  139.     [プラグイン。 ["io.containerd.grpc.v1.cri" .x509_key_pair_streaming]
  140.       tls_cert_file = ""  
  141.       tls_key_file = ""   
  142.  
  143.   [プラグイン。 ["io.containerd.internal.v1.opt" ]
  144.     パス = "/opt/containerd"   
  145.  
  146.   [プラグイン。 「io.containerd.internal.v1.再起動」 ]
  147.     間隔 = "10秒"   
  148.  
  149.   [プラグイン。 ["io.containerd.metadata.v1.bolt" ]
  150.     content_sharing_policy = "共有"   
  151.  
  152.   [プラグイン。 ["io.containerd.monitor.v1.cgroups" ]
  153.     no_prometheus =偽  
  154.  
  155.   [プラグイン。 ["io.containerd.runtime.v1.linux" ]
  156.     no_shim =偽 
  157.     ランタイム = "runc"  
  158.     ランタイムルート = ""  
  159.     shim = "コンテナd-shim"  
  160.     shim_debug =偽  
  161.  
  162.   [プラグイン。 ["io.containerd.runtime.v2.task" ]
  163.     プラットフォーム = [ "linux/amd64" ] 
  164.  
  165.   [プラグイン。 ["io.containerd.service.v1.diff-service" ]
  166. デフォルト= [ "ウォーキング" ] 
  167.  
  168.   [プラグイン。 「io.containerd.snapshotter.v1.aufs」 ]
  169.     ルートパス = ""   
  170.  
  171.   [プラグイン。 ["io.containerd.snapshotter.v1.btrfs" ]
  172.     ルートパス = ""   
  173.  
  174.   [プラグイン。 ["io.containerd.snapshotter.v1.devmapper" ]
  175.     非同期削除 =偽 
  176.     ベース画像サイズ = ""  
  177.     プール名 = ""  
  178.     ルートパス = ""   
  179.  
  180.   [プラグイン。 ["io.containerd.snapshotter.v1.native" ]
  181.     ルートパス = ""   
  182.  
  183.   [プラグイン。 ["io.containerd.snapshotter.v1.overlayfs" ]
  184.     ルートパス = ""   
  185.  
  186.   [プラグイン。 ["io.containerd.snapshotter.v1.zfs" ]
  187.     ルートパス = ""   
  188.  
  189.  [プロキシプラグイン] 
  190.  
  191.  [ストリームプロセッサ] 
  192.  
  193.   [stream_processors. ["io.containerd.ocicrypt.decoder.v1.tar" ]
  194.     accepts = [ "application/vnd.oci.image.layer.v1.tar+encrypted" ]
  195.     args = [ "--decryption-keys-path" , "/etc/containerd/ocicrypt/keys" ]
  196.     env = [ "OCICRYPT_KEYPROVIDER_CONFIG=/etc/containerd/ocicrypt/ocicrypt_keyprovider.conf" ]
  197.     パス = "ctd-decoder"  
  198. 戻り値= "application/vnd.oci.image.layer.v1.tar"   
  199.  
  200.   [stream_processors. ["io.containerd.ocicrypt.decoder.v1.tar.gzip" ]
  201.     accepts = [ "application/vnd.oci.image.layer.v1.tar+gzip+encrypted" ]
  202.     args = [ "--decryption-keys-path" , "/etc/containerd/ocicrypt/keys" ]
  203.     env = [ "OCICRYPT_KEYPROVIDER_CONFIG=/etc/containerd/ocicrypt/ocicrypt_keyprovider.conf" ]
  204.     パス = "ctd-decoder"  
  205. 戻り値= "application/vnd.oci.image.layer.v1.tar+gzip"   
  206.  
  207.  [タイムアウト]
  208.  "io.containerd.timeout.shim.cleanup" = "5秒"  
  209.  "io.containerd.timeout.shim.load" = "5秒"  
  210.  "io.containerd.timeout.shim.shutdown" = "3秒"  
  211.  "io.containerd.timeout.task.state" = "2s"   
  212.  
  213.  [ttrpc]
  214.   アドレス = ""  
  215.   識別子 = 0
  216.   ユーザID = 0

この設定ファイルは非常に複雑です。プラグインの設定に集中できます。よく見ると、各トップレベルの構成ブロックの名前が plugins."io.containerd.xxx.vx.xxx" であることがわかります。各トップレベルの構成ブロックはプラグインを表します。io.containerd.xxx.vx はプラグインのタイプを表し、vx の後の xxx はプラグインの ID を表します。 ctr を通じてプラグインのリストを表示できます:

  1.  ➜ ~ ctrプラグインls
  2.  ctr プラグイン ls
  3. タイプ ID プラットフォーム ステータス
  4. io.containerd.content.v1 コンテンツ OK
  5.  io.containerd.snapshotter.v1 aufs linux/amd64 正常
  6. io.containerd.snapshotter.v1 btrfs linux/amd64 スキップ
  7. io.containerd.snapshotter.v1 devmapper linux/amd64 エラー
  8. io.containerd.snapshotter.v1 ネイティブ Linux/amd64 正常
  9. io.containerd.snapshotter.v1 overlayfs linux/amd64 正常
  10. io.containerd.snapshotter.v1 zfs linux/amd64 スキップ
  11. io.containerd.metadata.v1 ボルト OK
  12.  io.containerd.differ.v1 は Linux/amd64 で正常に動作します
  13. io.containerd.gc.v1 スケジューラ OK
  14.  io.containerd.service.v1 イントロスペクションサービス OK
  15.  io.containerd.service.v1 コンテナサービス -ok
  16.  io.containerd.service.v1 コンテンツサービス OK
  17.  io.containerd.service.v1 差分サービス -ok
  18.  io.containerd.service.v1 イメージサービス OK
  19.  io.containerd.service.v1 リースサービス OK
  20.  io.containerd.service.v1 名前空間サービス - OK
  21.  io.containerd.service.v1 スナップショットサービス OK
  22.  io.containerd.runtime.v1 linux linux/amd64 正常
  23. io.containerd.runtime.v2 タスク linux/amd64 正常
  24. io.containerd.monitor.v1 cgroups linux/amd64 正常
  25. io.containerd.service.v1 タスクサービス OK
  26.  io.containerd.internal.v1 再起動OK
  27.  io.containerd.grpc.v1 コンテナ OK
  28.  io.containerd.grpc.v1 コンテンツOK
  29.  io.containerd.grpc.v1 差分 -ok
  30.  io.containerd.grpc.v1 イベント-OK
  31.  io.containerd.grpc.v1 ヘルスチェック OK
  32.  io.containerd.grpc.v1 イメージ-OK
  33.  io.containerd.grpc.v1 リース OK
  34.  io.containerd.grpc.v1 名前空間は正常
  35. io.containerd.internal.v1 オプトイン OK
  36.  io.containerd.grpc.v1 スナップショット-OK
  37.  io.containerd.grpc.v1 タスク-OK
  38.  io.containerd.grpc.v1 バージョン OK
  39.  io.containerd.grpc.v1 cri linux/amd64 は正常です

最上位の構成ブロックの下のサブ構成ブロックは、プラグインのさまざまな構成を表します。たとえば、cri プラグインは containerd、cni、およびレジストリ構成に分かれており、containerd はさまざまなランタイムとデフォルトのランタイムで構成できます。たとえば、ミラーのアクセラレータを構成する場合は、cri 構成ブロックの下の registry 構成ブロックで registry.mirrors を構成する必要があります。

  1.  [プラグイン。 ["io.containerd.grpc.v1.cri" .レジストリ]
  2.   [プラグイン。 ["io.containerd.grpc.v1.cri" .registry.mirrors]
  3.     [プラグイン。 "io.containerd.grpc.v1.cri" .registry.mirrors. [[docker.io] ]
  4.       エンドポイント = [ "https://bqr1dr1n.mirror.aliyuncs.com" ]
  5.     [プラグイン。 "io.containerd.grpc.v1.cri" .registry.mirrors. [[ ... [ （
  6.       エンドポイント = [ "https://registry.aliyuncs.com/k8sxio" ]
  • registry.mirrors."xxx": は、構成する必要があるミラー リポジトリを示します。たとえば、registry.mirrors."docker.io" は、docker.io のミラーを構成することを示します。
  • エンドポイント: 提供されるミラー アクセラレーション サービスを示します。たとえば、Alibaba Cloud ミラー サービスを docker.io のミラーとして登録できます。

さらに、デフォルト構成には 2 つのストレージ構成パスがあります。

  1. ルート = "/var/lib/containerd"  
  2. 状態 = "/run/containerd"  

ルートは、スナップショット、コンテンツ、メタデータ、さまざまなプラグインのデータなどの永続データを保存するために使用されます。各プラグインには独自のディレクトリがあります。 Containerd 自体はデータを保存しません。すべての機能は、ロードされたプラグインから提供されます。

もう一方の状態は、ソケット、PID、マウント ポイント、実行時のステータス、永続化する必要のないプラグイン データなど、実行時に一時データを保存するために使用されます。

使用

Docker CLI ツールは、ユーザー エクスペリエンスを向上させるために必要な機能を提供していることがわかっています。 Containerd は、対応する CLI ツール ctr も提供します。ただし、ctr の機能は Docker ほど充実しているわけではありませんが、イメージとコンテナの基本的な機能は備えています。次にctrの使い方について簡単に紹介します。

ヘルプ

関連するすべての操作コマンドの使用方法を取得するには、ctr コマンドを入力するだけです。

  1.  ➜ ~ クリック
  2. 名前：
  3.    クリック -
  4.         __
  5.   _____/ /______
  6.  / ___/ __/ ___/
  7.  / /__/ /_/ /
  8.  ____/\__/_/ 
  9.  
  10. コンテナCLI 
  11.  
  12.  
  13. 使用法：
  14.    ctr [グローバルオプション] コマンド [コマンド オプション] [引数...] 
  15.  
  16. バージョン:
  17.    バージョン1.5.5 
  18.  
  19. 説明： 
  20.  
  21.  ctrは、対話するためのサポートされていないデバッグおよび管理クライアントです。
  22.  containerd デーモンを使用します。サポートされていないため、コマンドは、
  23. オプションや操作は下位互換性が保証されていないか、  
  24.  containerd プロジェクトのリリースごとに安定しています。 
  25.  
  26. コマンド:
  27.    プラグイン、プラグインはコンテナプラグインに関する情報を提供します
  28.    version クライアントとサーバーのバージョンを出力します
  29.    コンテナ、c、コンテナ コンテナの管理
  30.    コンテンツ コンテンツ管理
  31.    イベント、イベント表示コンテナイベント
  32.    画像、画像、私は画像を管理する
  33.    リース リースの管理
  34.    名前空間、名前空間、ns 名前空間の管理
  35.    pprof は、 containerd用のgolang pprof 出力を提供します。
  36.    コンテナを実行する
  37.    スナップショット、スナップショットの管理
  38.    タスク、t、タスク管理タスク
  39.    インストール 新しいパッケージをインストールする
  40.    oci OCI ツール
  41.    シムと直接やりとりする
  42.    help, hコマンドのリストまたは1つのコマンドのヘルプを表示します
  43.  
  44. グローバルオプション:
  45.  --debug ログにデバッグ出力を有効にする 
  46.  --address value、-a value containerd の GRPC サーバーのアドレス (デフォルト: "/run/containerd/containerd.sock") [$CONTAINERD_ADDRESS]  
  47.  --timeout value ctr コマンドの合計タイムアウト (デフォルト: 0 秒)  
  48.  --connect-timeout value containerd への接続のタイムアウト (デフォルト: 0 秒)  
  49.  --namespace value、-n value コマンドで使用する名前空間 (デフォルト: "default") [$CONTAINERD_NAMESPACE]  
  50.  --help, -h ヘルプを表示 
  51.  --version, -v バージョンを印刷する 

ミラー操作

画像をプルする

画像のプルは、ctr image pull を使用して実行できます。たとえば、Docker Hub の公式イメージ nginx:alpine をプルします。イメージ アドレスは docker.io ホスト アドレスとともに追加する必要があることに注意してください。

  1.  ➜ ~ ctr イメージをプル docker.io/library/nginx:alpine
  2.  docker.io/library/nginx:alpine: 解決済み |++++++++++++++++++++++++++++++++++++++++++++|
  3. インデックス-sha256:bead42240255ae1485653a956ef41c9e458eb077fcb6dc664cbc3aa9701a05ce: 存在します |++++++++++++++++++++++++++++++++++++++++|
  4.  manifest-sha256:ce6ca11a3fa7e0e6b44813901e3289212fc2f327ee8b1366176666e8fb470f24: 完了 |++++++++++++++++++++++++++++++++++++++++|
  5. レイヤー-sha256:9a6ac07b84eb50935293bb185d0a8696d03247f74fd7d43ea6161dc0f293f81f: 完了 |++++++++++++++++++++++++++++++++++++++++++|
  6. レイヤー-sha256:e82f830de071ebcda58148003698f32205b7970b01c58a197ac60d6bb79241b0: 完了 |++++++++++++++++++++++++++++++++++++++++|
  7. レイヤー-sha256:d7c9fa7589ae28cd3306b204d5dd9a539612593e35df70f7a1d69ff7548e74cf: 完了 |++++++++++++++++++++++++++++++++++++++++|
  8. レイヤー-sha256:bf2b3ee132db5b4c65432e53aca69da4e609c6cb154e0d0e14b2b02259e9c1e3: 完了 |++++++++++++++++++++++++++++++++++++++++++++|
  9.  config-sha256:7ce0143dee376bfd2937b499a46fb110bda3c629c195b84b1cf6e19be1a9e23b: 完了 |++++++++++++++++++++++++++++++++++++++++|
  10. レイヤー-sha256:3c1eaf69ff492177c34bdbf1735b6f2e5400e417f8f11b98b0da878f4ecad5fb: 完了 |++++++++++++++++++++++++++++++++++++++++++|
  11. レイヤー-sha256:29291e31a76a7e560b9b7ad3cada56e8c18d50a96cca8a2573e4f4689d7aca77: 完了 |++++++++++++++++++++++++++++++++++++|
  12. 経過時間: 11.9秒 合計: 8.7 Mi (748.1 KiB/s)
  13.  linux/amd64 sha256:bead42240255ae1485653a956ef41c9e458eb077fcb6dc664cbc3aa9701a05ce を解凍しています...
  14. 完了: 410.86624 ミリ秒

--platform オプションを使用して、対応するプラットフォームのイメージを指定することもできます。もちろん、画像をプッシュするための対応するコマンド、ctr image push もあります。プライベートイメージの場合は、プッシュ時に --user を使用してリポジトリのユーザー名とパスワードをカスタマイズできます。

ローカルイメージを一覧表示する

  1. ➜ ~ ctr 画像 ls
  2. 参照タイプ ダイジェストサイズプラットフォーム ラベル
  3. docker.io/library/nginx:alpine application/vnd.docker.distribution.manifest.list.v2+json sha256:bead42240255ae1485653a956ef41c9e458eb077fcb6dc664cbc3aa9701a05ce 9.5 MiB linux/386、linux/amd64、linux/arm/v6、linux/arm/v7、linux/arm64/v8、linux/ppc64le、linux/s390x -
  4.  ➜ ~ ctr イメージ ls -q
  5.  docker.io/library/nginx:alpine

イメージ名のみを印刷するには、-q (--quiet) オプションを使用します。

ローカル画像の確認

  1. ➜ ~ ctr画像チェック 
  2.  REF タイプ ダイジェスト ステータスサイズ未パック
  3. docker.io/library/nginx:alpine application/vnd.docker.distribution.manifest.list.v2+json sha256:bead42240255ae1485653a956ef41c9e458eb077fcb6dc664cbc3aa9701a05ce 完了 (7/7) 9.5 MiB/9.5 MiB真 

主にステータスを確認します。完全とは、画像が完全に利用可能であることを意味します。

再ラベル

同様に、指定した画像に再度タグを付けることもできます。

  1.  ➜ ~ ctr イメージタグ docker.io/library/nginx:alpine harbor.k8s。ローカル/course/nginx:alpine
  2. ハーバー.k8s。ローカル/course/nginx:alpine
  3.  ➜ ~ ctr イメージ ls -q
  4.  docker.io/library/nginx:alpine
  5. ハーバー.k8s。ローカル/course/nginx:alpine

画像の削除

不要な画像は、ctr image rm を使用して削除することもできます。

  1.  ➜ ~ ctr イメージ rm harbor.k8s.ローカル/course/nginx:alpine
  2. ハーバー.k8s。ローカル/course/nginx:alpine
  3.  ➜ ~ ctr イメージ ls -q
  4.  docker.io/library/nginx:alpine

イメージと関連するすべてのリソースを同期的に削除するには、--sync オプションを追加します。

イメージをホストディレクトリにマウントする

  1. ➜ ~ ctr イメージマウント docker.io/library/nginx:alpine /mnt
  2.  sha256:c3554b2d61e3c1cffcaba4b4fa7651c644a3354efaafa2f22cb53542f6c600dc
  3.  /分
  4. ➜ ~ ツリー -L 1 /mnt
  5.  /分
  6. ├──ビン
  7. ├── 開発
  8. ├── docker-entrypoint.d
  9.  §── docker-entrypoint.sh
  10.  ├──など
  11. ├── ホーム
  12. ├── リブ
  13. ├── メディア
  14. ├── mnt
  15.  ├── オプション
  16. ├── プロセス
  17. ├── ルート
  18. ├── 走る
  19. ├── スビン
  20. ├── srv
  21.  ├── システム
  22. ├── 一時
  23. ├── ユーザー
  24. └── ヴァール
  25.  
  26.  18 ディレクトリ、1 ファイル

ホストディレクトリからイメージをアンマウントする

  1. ➜ ~ ctr イメージのアンマウント /mnt
  2.  /分

画像を圧縮パッケージとしてエクスポートする

  1. ➜ ~ ctr イメージエクスポート nginx.tar.gz docker.io/library/nginx:alpine

圧縮パッケージから画像をインポートする

  1. ➜ ~ ctr イメージのインポート nginx.tar.gz

コンテナオペレーション

コンテナ関連の操作は、ctr コンテナを通じて取得できます。

コンテナを作成する

  1. ➜ ~ ctr コンテナを作成docker.io/library/nginx:alpine nginx

コンテナの一覧

  1. ➜ ~ ctr コンテナ ls
  2. コンテナイメージランタイム
  3. nginx docker.io/library/nginx:alpine io.containerd.runc.v2

リストの内容を簡略化するために -q オプションを追加することもできます。

  1.  ➜ ~ ctr コンテナ ls -q
  2.  nginx

コンテナの詳細な構成を表示する

docker inspect 関数に似ています。

  1.  ➜ ~ ctr コンテナ情報 nginx
  2.  {
  3.  「ID」 : 「nginx」 、
  4.  「ラベル」 : {
  5.  "io.containerd.image.config.stop-signal" : "SIGQUIT"  
  6.     },
  7.  「イメージ」 : 「docker.io/library/nginx:alpine」 、
  8.  「ランタイム」 : {
  9.  「名前」 : 「io.containerd.runc.v2」 、
  10.  「オプション」 : {
  11.  "type_url" : "containerd.runc.v1.オプション"  
  12.         }
  13.     },
  14.  「スナップショットキー」 : 「nginx」 、
  15.  「スナップショット」 : 「overlayfs」 、
  16.  「作成日時」 : 「2021-08-12T08:23:13.792871558Z」 、
  17.  「更新日時」 : 「2021-08-12T08:23:13.792871558Z」 、
  18.  「拡張機能」 : null 、
  19.  「スペック」 :{
  20.  ......

コンテナの削除

  1. ➜ ~ ctr コンテナ rm nginx
  2.  ➜ ~ ctr コンテナ ls
  3. コンテナイメージランタイム

rm サブコマンドを使用するだけでなく、delete または del を使用してコンテナーを削除することもできます。

タスク

上記の container create コマンドで作成したコンテナは実行状態ではなく、単なる静的コンテナです。コンテナ オブジェクトには、コンテナを実行するために必要なリソースと関連する構成データのみが含まれており、名前空間、rootfs、コンテナ構成は正常に初期化されているが、ユーザー プロセスはまだ開始されていないことを示します。

コンテナの実際の操作はタスクによって実現されます。タスクは、コンテナのネットワーク カードをセットアップし、コンテナを監視するツールを構成できます。

タスク関連の操作は ctr タスクを通じて取得できます。次のように、タスクを通じてコン​​テナーを起動します。

  1.  ➜ ~ ctr タスク開始 -d nginx
  2.  /docker-entrypoint.sh: /docker-entrypoint.d/は 空ではありません。構成を実行しようとします
  3. /docker-entrypoint.sh: /docker-entrypoint.d/内のシェル スクリプトを検索しています

コンテナを起動した後、task ls を使用して実行中のコンテナを表示できます。

  1.  ➜ ~ ctr タスク ls
  2. タスク PID ステータス
  3. nginx 3630 実行中

exec コマンドを使用して操作用のコンテナに入ることもできます。

  1.  ➜ ~ ctr タスク実行  --exec-id 0 -t nginx sh  
  2.  / #

ただし、ここで --exec-id パラメータを指定する必要があることに注意してください。このIDは、ユニークである限り、好きなように書くことができます。

コンテナを一時停止し、Dockerの一時停止と同様の機能：

  1.  ➜〜CTRタスクの一時停止nginx

一時停止後、コンテナのステータスは PAUSED になります。

  1.  ➜〜ctrタスクls
  2. タスク PID ステータス
  3. Nginx 3630は一時停止しました

resumeコマンドを使用して、コンテナを復元することもできます。

  1.  ➜〜CTRタスクはnginxを再開します
  2. ➜〜ctrタスクls
  3. タスク PID ステータス
  4. Nginx 3630ランニング

ただし、CTRには停止容器の機能がなく、コンテナを一時停止または殺すことしかできないことに注意する必要があります。コンテナを殺すには、タスクキルコマンドを使用できます。

  1.  ➜〜ctrタスクはnginxを殺します
  2. ➜〜ctrタスクls
  3. タスク PID ステータス
  4. Nginx 3630が停止しました

コンテナを強制終了すると、コンテナのステータスが STOPPED に変わったことがわかります。 task rm コマンドを使用してタスクを削除することもできます。

  1.  ➜〜ctrタスクrm nginx
  2.  ➜〜ctrタスクls
  3. タスク PID ステータス

さらに、コンテナの cgroup 関連の情報も取得できます。タスク メトリック コマンドを使用して、コンテナのメモリ、CPU、PID の制限と使用量を取得できます。

  1.  ＃コンテナを再起動します
  2. ➜〜ctrタスクメトリックnginx
  3.  ID タイムスタンプ 
  4.  Nginx 2021-08-12 08：50：46.952769941 +0000 UTC 
  5.  
  6. メトリック値
  7. Memory.usage_in_bytes 8855552
  8. メモリ制限バイト数 9223372036854771712
  9.  memory.stat.cache 0
  10.  CPUACCT.USAGE 22467106
  11.  CPUACCT.USAGE_PERCPU [2962708 860891 1163413 1915748 1058868 2888139 6159277 5458062]
  12. ピド。現在9
  13.  pids.limit 0

Task PSコマンドを使用して、ホスト内のコンテナ内のすべてのプロセスのPIDを表示することもできます。

  1.  ➜〜ctrタスクps nginx
  2.  PID情報
  3. 3984-
  4.  4029-
  5.  4030-
  6.  4031-
  7.  4032-
  8.  4033-
  9.  4034-
  10.  4035-
  11.  4036-
  12.  ➜〜ctrタスクls
  13. タスク PID ステータス
  14. nginx 3984ランニング

最初のPID 3984は、コンテナ内のプロセス1です。

名前空間

さらに、containredは、名前空間の表示など、名前空間の概念もサポートしています。

  1.  ➜ ~ クリック ns ls
  2. 名前ラベル
  3. デフォルト 

指定されていない場合、CTRはデフォルトでデフォルトのスペースを使用します。 NS Createコマンドを使用して、名前空間を作成することもできます。

  1.  ➜〜ctr nsテストを作成します
  2. ➜ ~ クリック ns ls
  3. 名前ラベル
  4. デフォルト 
  5. テスト

削除またはRMを使用して名前空間を削除します。

  1.  ➜〜CTR NS RMテスト
  2. テスト
  3. ➜ ~ クリック ns ls
  4. 名前ラベル
  5. デフォルト 

名前空間を使用すると、リソースを操作するときに名前空間を指定できます。たとえば、テスト名空間のミラーを表示します。操作コマンドの後に-nテストオプションを追加できます。

  1.  ➜〜ctr -nテスト画像ls
  2. 参照タイプ ダイジェストサイズプラットフォーム ラベル

Dockerは実際にはデフォルトで呼び出されるContainredであることがわかっています。実際、Dockerが使用するContainerdの下の名前空間はデフォルトではデフォルトではなく、Dockerを使用してコンテナを起動する場合、CTR -N Mobyを使用して以下のコンテナを見つけることもできます。

  1.  ➜〜ctr -n Moby Container ls

同様に、Kubernetesで使用されるContainerdのデフォルトの名前空間はK8s.ioであるため、Ctr -N K8s.ioを使用してKubernetesで作成されたコンテナを表示できます。 Kubernetesクラスターのコンテナランタイムを後でContainerdに切り替える方法を紹介します。

<<:  ガートナー、2021年グローバルパブリッククラウドマジッククアドラントレポートを発表：マシュー効果が強調される

>>:  クラウドネイティブセキュリティのための5つのヒント

推薦する

インターネットマーケティングを学ぶ方法（パート2）

インターネットマーケティングを学ぶ方法（パート2）前回の記事「インターネット マーケティングの学習は...

SEO アクセラレータが Web ページの検索ランキングを加速する方法

最初のは興味深い新しいウェブサイトの所有者は皆、興味深い事実を発見しました。それは、訪問者数が数十人...

分散システムの線形化可能性のテスト

最近、とてもよく書かれた記事を見ました。著者のアニッシュさんの同意を得て、中国語に翻訳することにしま...

神話の打破: 産業用 IoT (IIOT) におけるクラウドとエッジ

多くの人にとって、クラウドは産業用モノのインターネット (IIoT) のバックボーンとなっています。...

WeChatストアは疑似ゼロ閾値であると非難され、セルフメディアが最も恩恵を受ける

【Ebrun News】WeChatストアが昨日正式に発表され、WeChatでのストア開設の「基準ゼ...

ヤフーの変革を踏まえて、在宅勤務のプログラマーの長所と短所について簡単に議論する

在宅勤務に関する情報に私たちが初めて注目したのは、ヤフーの新CEOであるメイヤー氏が、在宅勤務を今後...

ハイブリッドマルチクラウドとハイパーコンバージドインフラストラクチャの人気が高まる

ハイパーコンバージド インフラストラクチャ (HCI) が、組織が簡単に拡張してデータをより細かく制...

無料URL短縮サービスBitlyが1500万ドルを調達

URL短縮サービスプロバイダーのBitlyは今年5月に2000万ドルの資金調達を計画していたが、まだ...

Meilishuo によるウォーターフォール フロー ウェブサイトの画像最適化の詳細を垣間見る

人間は視覚に敏感な動物であり、単調なテキストよりも画像を好むことが多いと言われています。インターネッ...

WordPressブログを最適化する3つのステップを教えます

WordPress は近年非常に人気があります。オープン性、豊富なテンプレート、プラグイン拡張のサポ...

共同購入のために戦ったが、利益を得ることができなかった第二世代の富裕層は、固執すべきか、断絶すべきか、それとも変革すべきか？

共同購入の「裕福な第二世代」とは、大規模なウェブサイトに依存して成長してきた共同購入ビジネスを指しま...

ソフトコンテンツマーケティング: 高品質のメディアと低品質のメディアをどのように区別するか?

ソフトテキストマーケティングのプロセスにおいて、最も重要なのは原稿プランニングとメディアプランニング...

入札アカウントで重複キーワードを処理する方法

入札アカウントでのキーワードの重複は、すべての入札担当者が遭遇する一般的な問題です。この問題に対する...

アリババのAI研究成果がトップ国際会議ICML2020に選出、AI推論速度が3倍に向上

先日、世界最高峰の人工知能カンファレンス「ICML 2020」において、発表された論文の結果が発表さ...

Baidu の青大根アルゴリズムが売買リンクを識別する方法の分析

ウェブマスターなら誰でも、Baiduが2013年2月20日に「Green Radish」という最新の...