Kubernetes コンテナランタイムを Docker から Containerd にスムーズに切り替える方法

[[418144]]

先ほど、containerd の開発履歴と基本的な使用方法について学習しました。このセクションでは、Kubernetes クラスターのコンテナランタイムとして containerd を使用します。

先ほどインストールしたクラスターは、デフォルトでコンテナランタイムとして Docker を使用します。では、コンテナランタイムを Docker から containerd に切り替えるにはどうすればよいでしょうか?

メンテナンスノード

まず、切り替えるノードをメンテナンスモードとしてマークし、ノード上で実行されている Pod を強制的に削除します。これにより、切り替えプロセス中のアプリケーションの通常の動作への影響を最小限に抑えることができます。たとえば、最初にノード 1 を containerd に切り替えます。

まず、kubectl cordon コマンドを使用して、node1 ノードをスケジュール不可としてマークします。

 # ノード1をスケジュール不可としてマークする
➜ ~ kubectl コルドン ノード1
ノード/ノード1が封鎖されました
➜ ~ kubectl ノードを取得する
名前ステータス 役割 年齢 バージョン
マスター 準備完了マスター 85d v1.19.11
 node1 準備完了、スケジュール無効 <なし> 85d v1.19.11
 node2 準備完了 <なし> 85d v1.19.11

上記のコマンドを実行すると、node1 は SchedulingDisabled 状態に変わり、スケジュールできないことが示されます。この方法では、新しく作成された Pod は現在のノードにスケジュールされません。

次に、node1 ノードをメンテナンスし、kubectl のdrain コマンドを使用してノードをメンテナンスし、ノード上の Pod を削除します。

 # ノード1を維持し、ポッドを排除する
➜ ~ kubectl ドレイン node1 --ignore-daemonsets  
ノード/ノード1はすでに封鎖されています
警告: DaemonSet 管理の Pod を無視します: kube-system/kube-flannel-ds-mzdgl、kube-system/kube-proxy-vddh9、lens-metrics/node-exporter-2g4hr
ポッド「kiali-85c8cdd5b5-27cwv」を退去中 
ポッド「jenkins-587b78f5cd-9gvn8」を退去しています 
ポッド「argocd-application-controller-0」を削除しています 
 pod/argocd-application-controller-0 が削除されました
pod/kiali-85c8cdd5b5-27cwv が削除されました
pod/jenkins-587b78f5cd-9gvn8 が削除されました
ノード/ノード1が削除されました

上記のコマンドは、node1 上の Pod を強制的に削除します。 DaemonSet コントローラーによって管理される Pod を他のノードに追い出す必要がないため、これらの Pod を無視するためのパラメーター --ignore-daemonsets を追加しました。ノードが削除された後、ノードに対してメンテナンス操作を実行できます。コンテナランタイムの切り替えに加えて、これも実行できます。たとえば、ノード構成の変更やカーネルのアップグレードなどを行う必要がある場合は、まずノードを削除してからメンテナンスを実行できます。

containerdへの切り替え

次に、docker、containerd、kubelet を停止します。

 ➜ ~ systemctl kubelet を停止します
➜ ~ systemctl で docker を停止する
➜ ~ systemctl コンテナを停止します

インストールした Docker はデフォルトでバックエンドコンテナランタイムとして containerd を使用するため、containerd を別途インストールする必要はありません。もちろん、Docker と containerd を完全にアンインストールしてから再インストールすることもできます。ここでは、以前にインストールした containerd を直接使用することを選択します。

CRI は containerd にデフォルトで実装されていますが、プラグインとして構成されているためです。以前は、Docker に付属する containerd はデフォルトで CRI プラグインを無効にしていました (構成 disabled_plugins = ["cri"] を使用)。そのため、ここではデフォルトの構成ファイルを再生成して上書きします。

 ➜ ~ containerd 設定デフォルト> /etc/containerd/config.toml

上記の設定ファイルについてはすでに紹介しました。まず、デフォルトの一時停止イメージを国内アドレスに変更し、[plugins."io.containerd.grpc.v1.cri"] の下の sandbox_image を置き換えます。

 [プラグイン。 [[io.containerd.grpc.v1.cri] ]
  サンドボックスイメージ = "registry.aliyuncs.com/k8sxio/pause:3.2"  
  ......

イメージウェアハウスのアクセラレータアドレスも構成します。

 [プラグイン。 ["io.containerd.grpc.v1.cri" .レジストリ]
  [プラグイン。 ["io.containerd.grpc.v1.cri" .registry.mirrors]
    [プラグイン。 "io.containerd.grpc.v1.cri" .registry.mirrors. [[docker.io] ]
      エンドポイント = [ "https://bqr1dr1n.mirror.aliyuncs.com" ]
    [プラグイン。 "io.containerd.grpc.v1.cri" .registry.mirrors. [[ ... [ （
      エンドポイント = [ "https://registry.aliyuncs.com/k8sxio" ]

次に、kubelet 設定を変更し、コンテナランタイムを containerd に構成します。 /etc/sysconfig/kubelet ファイルを開き、いくつかの追加の kubelet 起動パラメータを追加できます。構成は次のとおりです。

 KUBELET_EXTRA_ARGS = "--container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock"

上記の構成では、2 つのパラメータを追加しました。 --container-runtime パラメータは、使用するコンテナランタイムを指定するために使用されます。オプションの値はdockerまたはremoteです。デフォルトはdockerです。ここでは containerd などのコンテナランタイムを使用しているため、リモート値として構成されます (つまり、docker 以外のコンテナランタイムはリモートとして指定する必要があります)。次に、2 番目のパラメータ --container-runtime-endpoint を使用して、リモートランタイムサービスのエンドポイントアドレスを指定します。 Linux システムでは、通常、UNIX ソケットが使用されます。たとえば、ここでは containerd に接続するためのソケットアドレス unix:///run/containerd/containerd.sock を指定します。

実際には、リモート CRI のイメージサービスアドレスを指定するには、--image-service-endpoint パラメータも構成する必要があります。指定されていない場合は、CRI がコンテナサービスとイメージサービスの両方を実装するため、--container-runtime-endpoint の値がデフォルトで使用されます。

設定が完了したら、containerd と kubelet を再起動します。

 ➜ ~ systemctlデーモンリロード
➜ ~ systemctl コンテナを再起動します
➜ ~ systemctl kubeletを再起動します

再起動が完了したら、ノードのステータスが正常かどうかを確認します。

 ➜ ~ kubectl ノードを取得 -o ワイド
名前ステータス 役割 年齢 バージョン 内部 IP 外部 IP OS イメージ カーネル バージョン コンテナ ランタイム
マスター準備完了マスター 85d v1.19.11 192.168.31.30 <なし> CentOS Linux 7 (Core) 3.10.0-1160.25.1.el7.x86_64 docker://19.3.9
 node1 Ready、SchedulingDisabled <なし> 85d v1.19.11 192.168.31.95 <なし> CentOS Linux 7 (Core) 3.10.0-1160.25.1.el7.x86_64 containerd://1.4.4
 node2 準備完了 <なし> 85d v1.19.11 192.168.31.215 <なし> CentOS Linux 7 (Core) 3.10.0-1160.25.1.el7.x86_64 docker://19.3.9

ノードを取得するときに、-o wide を追加して、ノードの詳細情報を表示します。上記の比較から、node1 のコンテナランタイムが containerd://1.4.4 に切り替わったことがわかります。

最後に、Pod リソースをスケジュールできるように、node1 をクラスターに再度追加します。

 ➜ ~ kubectl uncordon ノード1
ノード/ノード1が封鎖解除されました
➜ ~ kubectl ノードを取得する
名前ステータス 役割 年齢 バージョン
マスター 準備完了マスター 85d v1.19.11
 node1 準備完了 <なし> 85d v1.19.11
 node2 準備完了 <なし> 85d v1.19.11

同じ方法を使用して他のノードを処理し、クラスター全体をコンテナランタイム containerd に切り替えます。

クリクトル

これで、node1 で ctr コマンドを使用して containerd を管理し、k8s.io という追加の名前空間があることを確認できます。

 ➜ ~ クリック ns ls
名前ラベル
翻訳元
モビー

前述のように、Kubernetes クラスターのすべての containerd リソースは k8s.io 名前空間にありますが、docker リソースはデフォルトで moby にあります。もちろん、現在 moby にはデータはありませんが、k8s.io 名前空間には多くのイメージとコンテナリソースがあります。

 ➜ ~ ctr -n moby cls
コンテナイメージランタイム
➜ ~ ctr -n moby i ls
参照タイプ ダイジェストサイズプラットフォーム ラベル
➜ ~ ctr -n moby t ls
タスク PID ステータス
ctr -n k8s.io i ls -q
 docker.io/library/busybox:最新
docker.io/library/busybox@sha256:0f354ec1728d9ff32edcd7d1b8bbdfc798277ad36120dc3dc683be44524c8b60
 quay.io/coreos/flannel:v0.14.0
 quay.io/coreos/flannel@sha256:4a330b2f2e74046e493b2edc30d61fdebbdddaaedcb32d62736f25be8d3c64d5
 registry.aliyuncs.com/k8sxio/pause:3.2
 ......

もちろん、ctr コマンドを使用してイメージやコンテナリソースを直接管理することもできますが、使用中にこのツールが docker CLI ほど便利ではないことがはっきりとわかります。使いやすさと機能性を考慮すると、管理ツールとして crictl を使用することをお勧めします。 crictl は CRI 互換のコンテナランタイム用の CLI を提供します。これにより、CRI ランタイム開発者は Kubernetes コンポーネントを設定せずにランタイムをデバッグできます。

次に、crictl ツールを使用してコンテナランタイムの管理効率を向上させる方法について簡単に紹介します。

インストール

まず、crictl ツールをインストールする必要があります。 cri-tools のリリースページから対応するバイナリパッケージを直接ダウンロードし、解凍して PATH パスに配置します。

 ➜ ~ バージョン = "v1.22.0"  
 ➜ ~ wget https://github.com/kubernetes-sigs/cri-tools/releases/download/$VERSION/crictl-$VERSION-linux-amd64.tar.gz
 # 制限がある場合は、ダウンロードを高速化するために次のURLに置き換えることもできます
# wget https://download.fastgit.org/kubernetes-sigs/cri-tools/releases/download/$VERSION/crictl-$VERSION-linux-amd64.tar.gz
 ➜ ~ tar zxvf crictl-$VERSION-linux-amd64.tar.gz -C /usr/ local /bin
 ➜ ~ rm -f crictl-$VERSION-linux-amd64.tar.gz
 ➜ ~ crictl -v
 crictl バージョン v1.22.0

これは、crictl ツールが正常にインストールされたことを証明します。

使用法

crictl をインストールしたら、このツールの一般的な使用方法をいくつか学びましょう。

まず、デフォルトの設定ファイル（デフォルトでは /etc/crictl.yaml）を変更する必要があります。ファイル内のコンテナランタイムとイメージのエンドポイントアドレスを指定します。内容は以下のとおりです。

ランタイムエンドポイント: unix:///var/run/containerd/containerd.sock
イメージエンドポイント: unix:///var/run/containerd/containerd.sock
デバッグ: false  
プルイメージオン作成: false  
実行時のプルを無効にする: false

設定が完了したら、crictl コマンドを使用できます。

ポッドリストを取得

crictl pods コマンドを使用すると、以下に示すように、現在のノードで実行されている Pod のリストを取得できます。

 ➜ ~ crictlポッド
POD ID 作成 状態 名前名前空間 試行 実行時間
cb18081b33933 39 分前 準備完了 kube-flannel-ds-mzdgl kube-system 1 (デフォルト)
 95d6004c55902 40 分前 node-exporter-2g4hr lens-metrics 1 (デフォルト)が準備完了
cfae80b3209db 40 分前 kube-proxy-vddh9 kube-system 1 (デフォルト)が準備完了
99ac2583da87f 40 分前 準備完了 jenkins-587b78f5cd-dfzns kube-ops 0 (デフォルト)
 07ebdc51f1def 45 分前 NotReady node-exporter-2g4hr lens-metrics 0 (デフォルト)
 bec027b98f194 45 分前 NotReady kube-proxy-vddh9 kube-system 0 (デフォルト)
 b44b5ec385053 45 分前 NotReady kube-flannel-ds-mzdgl kube-system 0 (デフォルト)

--name パラメータを使用して特定の Pod を取得することもできます。

 ➜ ~crictl ポッド--name kube-flannel-ds-mzdgl  
 POD ID 作成 状態 名前名前空間 試行 実行時間
cb18081b33933 約 1時間前 準備完了 kube-flannel-ds-mzdgl kube-system 1 (デフォルト)

ラベル別にポッドリストをフィルタリングすることもできます。

 ➜ ~crictl pods --label app=flannel  
 POD ID 作成 状態 名前名前空間 試行 実行時間
cb18081b33933 約 1時間前 準備完了 kube-flannel-ds-mzdgl kube-system 1 (デフォルト)

ミラーリストを取得

すべてのイメージを取得するには、crictl images コマンドを使用します。

 ➜ ~ crictl 画像
画像タグ 画像IDサイズ 
 docker.io/jenkins/jenkins lts 3b4ec91827f28 303MB
 docker.io/library/busybox 最新 69593048aa3ac 771kB
 quay.io/coreos/flannel v0.14.0 8522d622299ca 21.1MB
 quay.io/prometheus/node-exporter v1.0.1 0e0218889c33b 13MB
 registry.aliyuncs.com/k8sxio/kube-proxy v1.19.11 732e0635ac9e0 49.3MB
 registry.aliyuncs.com/k8sxio/pause 3.2 80d28bedfe5de 300kB

コマンドの後に -v パラメータを追加して、イメージの詳細情報を表示することもできます。

 ➜ ~ crictl イメージ -v
 ID: sha256:3b4ec91827f28ed482b08f6e379c56ea2308967d10aa4f458442c922e0771f87
リポジトリタグ: docker.io/jenkins/jenkins:lts
リポジトリダイジェスト: docker.io/jenkins/jenkins@sha256:abcd55c9f19c85808124a4d82e3412719cd5c511c03ebd7d4210e9fa9e8f1029
サイズ: 302984002
ユーザー名: jenkins 
 
 ID: sha256:69593048aa3acfee0f75f20b77acb549de2472063053f6730c4091b53f2dfb02
リポジトリタグ: docker.io/library/busybox:latest
リポジトリダイジェスト: docker.io/library/busybox@sha256:0f354ec1728d9ff32edcd7d1b8bbdfc798277ad36120dc3dc683be44524c8b60
サイズ: 770886 
 
 ......

コンテナのリストを取得する

実行中のコンテナのリストを取得するには、crictl ps コマンドを使用します。

 ➜ ~ クリクトル ps
コンテナイメージ作成状態名試行ポッドID
 c8474738e4587 3b4ec91827f28 約1時間前 jenkins 0 を実行中 99ac2583da87f
 0f9c826f87ef8 8522d622299ca 約1時間前 kube-flannel 1 を実行中 cb18081b33933
 da444f718d37b 0e0218889c33b 約1時間前 node-exporter 1 95d6004c55902 を実行中
a484a8a69ea59 732e0635ac9e0 約1時間前 kube-proxy 1 を実行中 cfae80b3209db

crictl ps -h を通じて取得できる他のオプションパラメーターは多数あり、たとえば、最近作成された 2 つのコンテナーを表示するなどです。

 ➜ ~ crictl ps -n 2
コンテナイメージ作成状態名試行ポッドID
 c8474738e4587 3b4ec91827f28 約1時間前 jenkins 0 を実行中 99ac2583da87f
 0f9c826f87ef8 8522d622299ca 約1時間前 kube-flannel 1 を実行中 cb18081b33933

ステータスでフィルタリングするには -s オプションを使用します。

 ➜ ~ crictl ps -s 実行中
コンテナイメージ作成状態名試行ポッドID
 c8474738e4587 3b4ec91827f28 約1時間前 jenkins 0 を実行中 99ac2583da87f
 0f9c826f87ef8 8522d622299ca 約1時間前 kube-flannel 1 を実行中 cb18081b33933
 da444f718d37b 0e0218889c33b 約1時間前 node-exporter 1 95d6004c55902 を実行中
a484a8a69ea59 732e0635ac9e0 約1時間前 kube-proxy 1 を実行中 cfae80b3209db

コンテナ内でコマンドを実行する

crictl は exec に似たコマンドもサポートします。たとえば、コンテナ ID が c8474738e4587 のコンテナで date コマンドを実行するには、次のようにします。

 ➜~crictl exec -it c8474738e4587日付 
 2021年8月17日（火）08:23:02 AM UTC

コンテナログを出力する

コンテナのログ情報も取得できます。

 ➜ ~crictl ログ c8474738e4587
 ......
 2021-08-17 07:19:51.846+0000 [id=155] INFO hudson.model.AsyncPeriodicWork#lambda$doRun$0: 定期的なバックグラウンドビルド破棄を開始しました
2021-08-17 07:19:51.854+0000 [id=155] INFO hudson.model.AsyncPeriodicWork#lambda$doRun$0: 定期的なバックグラウンド ビルド ディスカーダーが終了しました。 6ミリ秒
2021-08-17 08:19:51.846+0000 [id=404] INFO hudson.model.AsyncPeriodicWork#lambda$doRun$0: 定期的なバックグラウンドビルド破棄を開始しました
2021-08-17 08:19:51.848+0000 [id=404] INFO hudson.model.AsyncPeriodicWork#lambda$doRun$0: 定期的なバックグラウンド ビルド ディスカーダーが終了しました。 1ミリ秒

kubectl logs と同様に、-f オプションを使用してログ出力を追跡することもできます。また、--tail N を使用して、最新の N 行のログの出力を指定することもできます。

リソース統計

コンテナリソースの使用状況を一覧表示するには、crictl stats コマンドを使用します。

 ➜ ~ crictl 統計
コンテナ CPU % MEM ディスク INODES
 0f9c826f87ef8 0.00 21.2MB 0B 17
 a484a8a69ea59 0.00 23.55MB 12.29kB 25
 c8474738e4587 0.08 413.2MB 3.338MB 12
 da444f718d37b 0.00 14.46MB 0B 16

さらに、次のようなイメージやコンテナに関連するいくつかの操作もサポートされています。

イメージをプルする: crictl pull
ポッドを実行: crictl runp
コンテナを実行します: crictl run
コンテナを起動します: crictl start
コンテナを削除します: crictl rm
イメージを削除します: crictl rmi
ポッドの削除: crictl rmp
コンテナを停止します: crictl stop
ポッドを停止する: crictl stoppod
......

詳細については、https://github.com/kubernetes-sigs/cri-tools を参照してください。

CLI の比較

先ほど、イメージ、コンテナ、ポッドは docker、ctr、crictl などのコマンドラインツールを使用して管理できることを学びました。次に、これらの一般的なコマンドの使用方法の違いを比較してみましょう。

ctr containers create コマンドで作成されたコンテナは静的コンテナのみであるため、ctr task start コマンドを使用してコンテナプロセスを開始する必要もあることに注意してください。もちろん、ctr run コマンドを直接使用してコンテナを作成して実行することもできます。コンテナ操作を入力するときは、Docker とは異なり、ctr task exec コマンドの後に --exec-id パラメータを指定する必要があります。この ID は一意であれば何でも構いません。なお、ctr にはコンテナを停止する機能はありません。コンテナを一時停止 (ctr task pause) または終了 (ctr task kill) することしかできません。

さらに、crictl pods は、Pod が配置されている名前空間やステータスなど、Pod の情報を一覧表示することに注意してください。 crictl ps はアプリケーションコンテナの情報を一覧表示しますが、docker ps は初期化コンテナ (一時停止コンテナ) とアプリケーションコンテナの情報を一覧表示します。初期化コンテナは各 Pod の起動時に作成され、通常は注目されないため、crictl の方が簡潔でわかりやすく使用できます。

ログ構成

共通コマンドのいくつかの違いに加えて、docker と containerd にはコンテナログと関連するパラメータ構成にもいくつかの違いがあります。

DockerをKubernetesコンテナランタイムとして使用する場合、コンテナログはDockerによってディスクに書き込まれ、/var/lib/docker/containers/のようなディレクトリに保存されます。 kubelet は、コンテナログディレクトリ内のコンテナログファイルを指すソフトリンクを /var/log/pods および /var/log/containers の下に作成します。対応するログ関連の構成は、以下に示すように、構成ファイルを通じて指定できます。

 {
 「ログドライバー」 : 「jsonファイル」 、
 「ログオプション」 : {
 「最大サイズ」 : 「100m」 、
 "最大ファイル数: " 10"
    }
 }

containerdをKubernetesコンテナランタイムとして使用すると、コンテナログはkubeletによってディスクに書き込まれ、/var/log/pods/に直接保存されます。ディレクトリを作成し、/var/log/containers ディレクトリ内のログファイルを指すソフトリンクを作成します。同様に、ログ構成は、以下に示すように、kubelet パラメータを通じて指定されます。

 --container-log-max-files=10 --container-log-max-size="100Mi"

したがって、ログを収集する場合、理論的には両方のソリューションに互換性があり、基本的に変更は必要ありません。

もちろん、これらの違いに加えて、イメージ構築プロセスは私たちが最も注意を払う必要があるものかもしれません。 containerd に切り替えた後は、docker.sock が使用できなくなるため、コンテナ内で docker コマンドを実行してイメージをビルドできなくなることに注意してください。そこで次に、docker.sock を使用せずにイメージをビルドするいくつかの方法を紹介する必要があります。

<<: クラウドネイティブに関する 3 つの質問: 避けられない過去と現在は何ですか?

>>: SaaS が適切に実行されているかどうかを知りたいですか?これら3種類の分析指標を理解しなければなりません！