Rancher Desktopはデスクトップ上でKubernetesとコンテナの管理を行うことができるツールです。containerdやDockerを使ってコンテナーイメージのビルド、プッシュ、ダウンロード、実行できます。
K3sを使ってKubernetesクラスターの実行もデスクトップ上で可能になっています。
Visual Studio CodeのRemote DevelopmentやDocker拡張機能などの導入によって、Rancher Desktopを使ってコンテナベースでアプリケーション開発も可能になっています。
今回はRancher Desktopを使って、DockerとKubernetesに入門してみましょう。
コンテナーとはなにか
コンテナーはアプリケーションを実行するプラットフォーム技術の一つで、アプリケーションをコンテナで実行します。コンテナー技術は自動化といった分野と相性が良く、DevOps界隈やインフラ界隈などで注目されている技術です。
仮想マシンでアプリケーションを実行するのと比べて、仮想マシンのハイパーバイザー層といったようなオーバーヘッドが少ないため、仮想マシンよりも高速にアプリケーション実行が可能になります。コンテナー技術はイメージベースのプラットフォームであり、コンテナー環境をセットアップすればそれがラップトップであろうが、専用のベアメタルサーバーだろうが、クラウド上のインスタンスであろうが、どこでも同じようにアプリケーションを実行できる可搬性を備えています。
Dockerとはなにか
Dockerは前述のようなコンテナーをLinux上で実行するための機能を提供するソフトウェアの一つです。Dockerは、コンテナと呼ばれるホストと緩やかに分離された環境でアプリケーションをパッケージ化して実行する機能を提供します。Linuxカーネルの分離とセキュリティ機能を利用することで特定のホストで多数のコンテナーを素早く、同時に実行できます。
コンテナは軽量かつ、アプリケーションの実行に必要なものがコンテナーにすべて含まれているため、ホストに現在インストールされているソフトウェアやライブラリー、プログラミング環境などに依存することなく、コンテナーでアプリケーションを実行できます。
コンテナは簡単に他の人と共有することもでき、共有相手全員が同じ方法を用いて手元の環境で同じように動作する環境を再現できます。
Linux以外でDockerを利用する
これまで説明したように、Dockerを利用するにはLinuxが必要でした。 Linux以外でDockerを利用するには仮想マシンソフトウェアなどで仮想マシンを作成してLinuxを実行し、その中でDockerを動かす方法があります。
設定次第ではこのVM内のDockerを、手元のWindowsやmacOSにインストールしたDocker CLIからネイティブにDockerが動いているように操作することも可能ですが、設定はちょっと大変です。
WindowsやmacOSで簡単にDockerを動かすことができるようにするために提供されているソフトウェアがDocker Desktopです。macOSの場合はQEMU、Windowsの場合はHyper-VもしくはLinux 用 Windows サブシステム（WSL） 2ベースでDockerが動いています。
Linux以外でDockerを利用するためのツールとしては、これまでDocker Desktopが事実上の標準として使われていました。しかし、昨年2021年8月にDocker社がDocker Desktopの利用規約を方針変更し、従業員250人、年間収益1,000万ドルを超える企業での利用を商用利用と判断するように変更しました。
なお、先程の規模未満での利用、個人使用、教育、および非営利のオープンソースプロジェクトでは無料のままです。しかしこの発表を期に、Docker Desktopから他のソリューションへ切り替えを検討するユーザーが増えました。
いくつかある代替ソフトウェアの一つがRancher Desktopです。
Rancher Desktopの特徴
Rancher Desktopは冒頭で説明したように、デスクトップ上でKubernetesとコンテナの管理を行うことができるツールです。ランタイムとしてDockerを使うように設定変更すれば、これまでのようにWindowsやmacOS上でDockerを利用できますし、特定のバージョンのKubernetesを素早くローカル上で稼働させて、コンテナベースのアプリケーション開発やテスト、実行を可能とします。
次のような特徴があります。
- Windows/Mac/Linuxに対応
- すべてOSSで開発
- 内部コンポーネントもOSSで構成されている
- 無料で使える
- ContainerdもしくはDockerから選べる
- 軽量K3sを使ったKubernetesクラスタの稼働が可能
Rancher Desktopの構成
Rancher DesktopはmacOSとLinuxではQEMU上でコンポーネントが動作し、Windows版はWSL v2上で動作します。 これらを各種コマンドラインツールやGUIツールを使って管理します。必要なコマンドラインツールはRancher Desktopに同梱されるため、別途導入する必要はありません。
Rancher Desktopのインストール
システム要件は導入するバージョンで変わってくるため、以下をご覧ください。
ざっくりと説明すると、CPU 4コア、メモリー8GB以上のマシンでの利用をおすすめします。これ以下の環境でも設定を調整すると動作する可能性はありますが、アプリケーションの実行は厳しいかと思います。
Rancher DesktopとProxy
プロキシ利用が前提な環境（特に企業や学校での利用）では、追加で「Proxy環境下でRancher Desktopを使うための設定」が必要な場合があります。 OSや選択するランタイムによって設定方法が違うようなので、ご注意ください。
Proxyの設定をしても正常に動作しない場合はSlackで質問を投げるか、GitHubに類似するIssueがないか確認してからIssueを上げると良いかなと思います。参考までに見つけたブログ記事をご紹介します。
- https://qiita.com/yassan168/items/91b15b5edba8718d6196
- https://qiita.com/yuu-matsuo/items/4a9b007cc3da88055418
- https://zenn.dev/myonie/articles/f4387166ebfdd
Rancher Desktopの起動
インストール後、はじめて起動すると管理権限でのアクセスが必要といったようなメッセージが出ますので、管理ユーザーで認証をしてください。認証が通るとRancher Desktopがシステムコンテナを実行して、そのクライアントでDocker（もしくはcontainerd）やKubernetesが利用できるように設定されます。
ここから先は、コマンドを使ってDockerを利用します。macOSやLinuxでは端末（ターミナル）、Windowsの場合はWindows ターミナルもしくはPowerShell、コマンド プロンプトなどを使って操作してください。 以降、これらのことを端末と呼びます。ここからは端末でコマンド入力を中心に、Dockerを操作していきます。
Dockerイメージのダウンロード
Rancher Desktopの起動が終わったら、端末を起動してまずdocker infoと入力します。Serverとクライアントの情報が出力されたら、Dockerの準備はできています。次のように表示される場合は、まだDockerのサーバー側の準備ができていません。
% docker info Client: Context: default Debug Mode: false Plugins: buildx: Docker Buildx (Docker Inc., v0.8.2) compose: Docker Compose (Docker Inc., v2.6.1) Server: ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? errors pretty printing info
準備ができたらまずはイメージを検索してみましょう。Dockerはアプリケーションを実行するためのプラットフォームです。アプリケーションを実行するための環境を展開するためには適切なイメージを利用する必要があります。
例えば、アプリケーションがPHPで書かれているならPHPのオフィシャルイメージが適切ですし、Pythonで書かれているならPythonのイメージが適切です。オフィシャルイメージにはDebianベースのイメージと、Alpine Linuxベースのイメージが提供されている場合があります。イメージサイズはAlpine Linuxベースのイメージのほうが小さくなる傾向があります。ただし、Libcの互換性の問題から、アプリケーションの実行速度に影響があったり思ったように動作しない場合があるため、手放しで喜んでAlpine Linuxベースのイメージを使えばよいというわけではありません。
Dockerベースのイメージの場合、標準のイメージとイメージの名前に-slimがつくイメージが存在する場合があります。アプリケーションの実行に不要なものを削ぎ落としているイメージであり、slimバージョンのほうがイメージサイズは小さくなります。
DockerはコンテナでOSを動かすのが目的ではないため、できる限りイメージサイズの小さいイメージを選ぶと、後述のイメージをベースとしたカスタムイメージのビルドに要する時間も短縮できます。
% docker search debian NAME DESCRIPTION STARS OFFICIAL AUTOMATED ubuntu Ubuntu is a Debian-based Linux operating sys… 14692 [OK] debian Debian is a Linux distribution that's compos… 4393 [OK] neurodebian NeuroDebian provides neuroscience research s… 92 [OK] bitnami/debian-base-buildpack Debian base compilation image 2 [OK] treehouses/debian 2 ustclug/debian Official Debian Image with USTC Mirror 1 osrf/debian_armhf Debian Armhf Base Images 1 ...
途中で省略しましたが、複数のイメージが見つかります。docker searchでは様々なユーザーが作ったイメージが候補として見つかることがあります。コンテナイメージはセキュリティのことを考えると、オフィシャルのイメージをベースに動かしたいアプリケーションを取り込んだイメージをビルドして利用するのがおすすめの運用になりますので、次のようにオプションを指定してみてください。
先程よりもイメージの数を絞れたと思います。これらはすべてオフィシャルのイメージです。「debian」イメージの検索にUbuntuが出てくるのは、UbuntuがDebianベースのLinuxだからです。
% docker search debian --filter is-official=true NAME DESCRIPTION STARS OFFICIAL AUTOMATED ubuntu Ubuntu is a Debian-based Linux operating sys… 14692 [OK] debian Debian is a Linux distribution that's compos… 4393 [OK] neurodebian NeuroDebian provides neuroscience research s… 92 [OK]
さて、いよいよイメージのダウンロードをするわけですが、ここでも注意するポイントがあります。それはイメージのタグを指定するということです。
イメージのタグではOSイメージのメジャーバージョンやマイナーバージョン、ビルド違いのイメージなどのタグが用意されています（前述の-slimも同様です）。イメージのタグを指定せずに次のように実行した場合、最新のバージョンのイメージが手元にキャッシュされます。
% docker image pull debian
「latest = 最新だから良いのでは？」と思いがちですが、何度も説明しているようにDockerはアプリケーションを実行するためのプラットフォームです。目的のアプリケーションが動かなければだめなわけです。この記事を書いた時点では「latest = Debian 11 bullseye」を指していますが、数年後には別のバージョンに差し替わっているかもしれません。OS自体やライブラリーのバージョンが変化することで、アプリケーションが想定通り動かなくなるかもしれません。一般的にはタグを使ってイメージのディストリビューションのバージョンを指定するのが適切です。
% docker image pull debian:bullseye-slim
Dockerのデフォルト設定ではDocker Hubのイメージを検索対象とします。ランタイムによっては他のレジストリサーバーが設定されている場合があります。イメージタグはブラウザーで次にアクセスして検索すると確認できます。
もしくは、端末でつぎのように実行すると、目的のイメージにあるタグを確認できます。
% PK_NAME=debian
% curl -s https://registry.hub.docker.com/v1/repositories/${PK_NAME}/tags | sed "s/,/\n/g" | grep name | cut -d '"' -f 4
全てのタグが表示されるので、さらにgrepを使って絞り込むと良いでしょう。イメージによってはバージョンのほかコードネームでも検索できる場合があるので、Debian 11を示すbullseyeを指定するにはつぎのように実行します。
% curl -s https://registry.hub.docker.com/v1/repositories/${PK_NAME}/tags | sed "s/,/\n/g" | grep name | cut -d '"' -f 4 | grep "bullseye"
bullseye
bullseye-20190708
bullseye-20190708-slim
bullseye-20190812
bullseye-20190812-slim
...
bullseye-20220711
bullseye-20220711-slim
bullseye-20220801
bullseye-20220801-slim
bullseye-backports
bullseye-slim
よりアプリケーションの動作確認したイメージを明確にするなら、日付つきのイメージを使うと良いかもしれません。ちょっと試すだけであれば、Stableのslimバージョン（bullseye-slim）を選択しておけば間違いはないでしょう。 Debianのリリースバージョンとコードネームについてはつぎで確認できます。現在の最新安定版は「Debian 11 bullseye」です。その前の安定版は「Debian 10 buster」です。
アプリケーションを実行するために利用するコンテナイメージは、脆弱性やバグの修正を反映させるために適切なタイミングで新しいものに切り替える必要があります。
イメージによってはデイリービルドが存在しないイメージもあります。その場合は、より新しいイメージを選んでおけばよいでしょう。
Docker Hub以外のイメージレジストリーからコンテナイメージを取得（Pull）したい場合は、それらの配布ページに書かれているようにイメージ名の前にURLを追加すれば、Docker Hub以外から目的のイメージを取得できます。デフォルト設定の場合、以下の２つのコマンドは同じレジストリーからイメージを取得します。
% docker image pull debian:bullseye-slim % docker image pull dockerio/debian:bullseye-slim
しかし、イメージの取得元を明確にするという点で言えば、２つ目のように実行する方が適切です。
Dockerイメージを確認
クライアント上にあるイメージのキャッシュの一覧を表示するには、つぎのように実行します。Rancher Desktopの場合はシステムコンテナイメージも表示されます。
% docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE debian bullseye-20220801-slim e12dd81eada0 45 minutes ago 74.3MB debian bullseye-slim e12dd81eada0 45 minutes ago 74.3MB debian bullseye 585393df054a 45 minutes ago 118MB nginx latest fd2d3e51789e 13 days ago 135MB registry 2 45a1317536d5 13 days ago 22.5MB rancher/klipper-helm v0.7.3-build20220613 b524fed05410 7 weeks ago 228MB ...
Dockerコンテナの実行
ダウンロードしたイメージを使って、コンテナを実行してみましょう。 次のように実行します。
% docker container run -it debian:bullseye-slim bash
-iはインタラクティブモード、つまり対話型で開くかの指定です。デフォルトはfalseに設定されています。
-tはTTYを開くかどうかの指定です。これもデフォルトはfalseに設定されています。
今回はコンテナを実行してコンテナのシェルに入りたいので、それぞれ指定しています。 実行するとすぐコンテナのシェルに接続できるはずです。
% docker container run -it debian:bullseye-slim bash root@5b678bf8688e:/# root@5b678bf8688e:/# cat /etc/debian_version 11.4
もう一つ端末を開いて、次のコマンドを実行してみてください。すると、実行中のコンテナ一覧が表示されます。-aオプションを指定すると、クライアントに存在する作成済みコンテナが実行中の有無関わらずにすべて表示されます。
% docker container ls -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 5b678bf8688e debian:bullseye-slim "bash" 2 minutes ago Up 2 minutes angry_kilby ... 695a5bf6e09c k8s.gcr.io/pause:3.6 "/pause" 25 hours ago Exited (0) 22 hours ago k8s_POD_svclb-traefik-0fc9ccce-48bl9_kube-system_f927800a-af25-4535-a75d-98c1939a1938_2 e5db09983b06 registry:2 "/entrypoint.sh /etc…" 6 days ago Up 2 hours 0.0.0.0:5000->5000/tcp, :::5000->5000/tcp registry
コンテナ一つ一つには一意のIDと名前が割り当てられます。IMAGE列にはコンテナの作成に使われたイメージが、 COMMANDにはコンテナ実行時に実行したコマンドが、CREATEDにはコンテナ作成からどれくらいの時間が経過したか、STATUSは現在のコンテナの状況、PORTSにはコンテナを実行したときに 指定したポートが、NAMEにはコンテナの名前が表示されます。コンテナ名を指定せずにコンテナを実行した場合は、ランダムな名前がつけられます。
コンテナのシェルから抜けるには「logout」ではなく「exit」と入力します。
% docker container run -it debian:bullseye-slim bash root@5b678bf8688e:/# logout bash: logout: not login shell: use `exit' root@5b678bf8688e:/# exit exit %
Dockerコンテナの実行（応用編）
名前を指定してコンテナを作成
コンテナを実行する際に名前を指定しなかった場合はランダムな名前が適当に振られます。 コンテナに任意の名前をつけて実行することも可能です。
docker container run --name=名前 イメージ名 コマンド
実行例
% docker container run --name=hoge -it debian:bullseye-slim bash % docker container ls | grep debian:bullseye-slim e5b72e529045 debian:bullseye-slim "bash" 5 seconds ago Up 4 seconds ecstatic_villani #ランダム名 ac68d94b777f debian:bullseye-slim "bash" 4 minutes ago Up 4 minutes hoge #名前を指定
筆者的には名前を指定したほうが好みです。理由としては、コンテナの削除をするときにわざわざ名前の確認をする必要がなくなるからです。
シェルからコマンドを実行
次のように実行すると、コンテナ内で指定したコマンドを実行してその結果を標準出力します。 シェルに入って実行するほどのことでない場合はこの方法を使います。
docker container run イメージ名 /bin/bash -c "コマンド"
実行例
% docker container run -it debian:bullseye-slim /bin/bash -c "cat /etc/debian_version" 11.4 %
Debianの場合、ファイル /etc/debian_versionには現在のDebianのバージョンが書かれています。
これを実行した結果、コンテナの中のDebianのバージョンがわかったわけです。
実際の用途としては、APIサーバーをコンテナで実行してその結果を出力するみたいなときに使うようなときに使うのかなと思います。
コンテナの削除
コンテナの場合、処理が終わったら多くの場合コンテナを終了するのがほとんどです（後述の-dオプションを指定した場合は異なる）。 不要なコンテナは消してしまいましょう。
コンテナ名がわかっている場合は次のように実行すると、コンテナを削除できます。削除するコンテナは停止されている必要があります。
停止されていない場合はdocker container stopでコンテナを停止、コンテナ名がわからない場合はdocker container lsで確認してください。
削除前であれば、停止したコンテナは再開できます。
% docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e5b72e529045 debian:bullseye-slim "bash" About an hour ago Up About an hour ecstatic_villani ac68d94b777f debian:bullseye-slim "bash" 2 hours ago Up 2 hours hoge ... % docker container stop ecstatic_villani hoge (コンテナを停止) % docker container rm ecstatic_villani hoge (コンテナを削除)
なお、不要なコンテナが多数あって、全部指定するのが面倒であれば「停止済みのコンテナーをすべて削除」することもできます。 つぎのように実行してください。
% docker container rm $(docker container ls --filter status=exited -q)
Dockerとイメージ作成
Dockerはイメージベースでアプリケーションの実行環境（OSとライブラリー）をデプロイするものです。 イメージはコンテナレジストリで配布されています。コンテナレジストリはDocker HubやQuay.ioなどがあります（その他にも色々ありランタイムにデフォルト設定されています）。
ベースイメージに動かしたいアプリケーションを取り込み、独自のカスタムイメージを作って使うのが基本の利用スタイルになっています。
イメージを作る場合に守りたい「原則」は例えば次のようなものです。
- できる限り余計なものは入れない
- レイヤーという概念に注意する
- root権限が不要であればユーザー権限でアプリを実行する
レイヤーについて詳しくは、About storage driversをご覧ください。 とりあえず覚えておくことは、「DockerコンテナーやDockerfileで実行するコマンドごとにレイヤーが追加される」、「レイヤーにはデータが残るので、秘密情報をコンテナの中で処理しない（ファイルを消してもレイヤーにその情報が残る）」という点です。
実際にレイヤーからシークレット情報を抜き出す方法がNECさんのサイトのブログに書かれていましたので、興味があればご覧ください。diveというものを使っているようです。
Dockerとイメージ作成
Dockerでカスタマイズしたイメージをビルドするには、Dockerfileを使った方法が便利です。 Dockerfileを作成し、イメージ作成毎ディレクトリーを作成して必要なファイルを配置します。
このDockerfileには、FROMとADD、EXPOSEという命令が書かれています。 他の命令についてはDockerfile referenceに一覧があります。
FROMはこのイメージのベースとなるイメージを指定しています。アプリケーションはPHPベースなので、オフィシャルのPHPイメージを利用することにしました。 どのようなイメージがあるかはイメージの概要に書かれています。PHPイメージの場合、PHP CLIが使えるイメージ、Apache httpdがインストール済みのイメージ、PHP-FPM（FastCGI）が設定されているイメージ、Alpine LinuxベースのOSにPHPがインストールされたイメージなどが存在します。いくつかのOSバージョンの選択肢もあります。私がよく使うのは、DebianベースのApache httpdがセットアップ済みのイメージです。
FROM docker.io/php:7.4.30-apache-bullseye ADD index.php /var/www/html/ EXPOSE 80
ADDは書かれている処理からもわかるように、ファイルを似にの場所にコピーするための命令です。 EXPOSEはポートの紐付けをします。
Dockerfile自身及びDockerfileで追加するファイルは同じディレクトリーにおいておくほうが良いです。
うっかり色々なファイルが存在するディレクトリーでDockerfileを使ったdocker buildを実行すると大変なことになります。
index.php
<html>
<body>
<h1>index</h1>
<?php
echo("Hello World!");
?>
</body>
</html>
前の項で説明したDockerfileとindex.phpを同じ空のディレクトリーにおいてください。 そのディレクトリー上で次のコマンドを実行すると、独自のコンテナイメージを作成できます。
% ls Dockerfile index.php $ docker image build -t myphp .
ビルド中の出力例
% docker image build -t myphp . Sending build context to Docker daemon 3.072kB Step 1/3 : FROM docker.io/php:7.4.30-apache-bullseye 7.4.30-apache-bullseye: Pulling from library/php 60197a4c18d4: Already exists c70b8381cf88: Pull complete 15f3ec5d54b5: Pull complete dad5f9a74330: Pull complete 56f09025ca19: Pull complete 7d0ccca34338: Pull complete 2119cf4cc65e: Pull complete aadc3826eeed: Pull complete 56e72d660287: Pull complete bb2f331a1023: Pull complete 270328af282b: Pull complete 9c91d9d50cf0: Pull complete b71ad334b920: Pull complete Digest: sha256:8fccf5f8f6b458645031e7e91528fe94308eada08c70b9fe9795926a4f7c60dd Status: Downloaded newer image for php:7.4.30-apache-bullseye ---> 6e17013fe942 Step 2/3 : ADD index.php /var/www/html/ ---> 64cd59634cf3 Step 3/3 : EXPOSE 80 ---> Running in adc11aa685f3 Removing intermediate container adc11aa685f3 ---> a72dab5842bb Successfully built a72dab5842bb Successfully tagged myphp:latest
イメージの確認をしてみましょう。結果が出てくればイメージは問題なくできています。
% docker image ls | grep myphp myphp latest a72dab5842bb 47 seconds ago 421MB
作成したイメージでコンテナを作成してみましょう。
% docker container run -d -p 8080:80 -it myphp
次のように実行すると、CLIでアプリケーションにアクセスできます。 同じマシン上でブラウザでURLにアクセスすると、HTMLが整形された状態で表示されます。
% curl http://localhost:8080
<html>
<body>
<h1>index</h1>
Hello World! </body>
</html>
Dockerfileを使ったイメージ作成にはベストプラクティスが存在します。 Dockerの場合は次の通り公式の情報がドキュメントサイトに掲載されていますので、そちらを一読してください。
- https://docs.docker.com/develop/dev-best-practices/
- https://docs.docker.com/develop/develop-images/dockerfile_best-practices/
追加で注意する点としては次のようなものがあります。
- 最新として提供されているイメージが古い（脆弱性が残っている）場合があるので、その場合はベースOSの流儀にしたがって更新する。
一般的にはコンテナレジストリーに公開されているコンテナイメージの一番新しいビルドのイメージを使えば良いとされていますが、イメージの更新間隔はイメージのよってまちまちなので、Dockerfileの中でベースイメージのアップデートの処理を入れたほうが良いと思います。
例えば次のような感じです。RUN行に「apt-get -y upgrade」と書かれています。
FROM docker.io/ubuntu:22.04 # Runs as root: RUN apt-get update && apt-get -y upgrade && apt-get install -y python3 && rm -rf /var/lib/apt/lists/* # Switch to non-root user: RUN useradd --create-home appuser WORKDIR /home/appuser USER appuser ADD test.py /home/appuser/ # Runs as non-root user: ENTRYPOINT ["python3", "test.py"]
- ベースイメージに含まれるアプリケーションのモジュールをインストールする場合は、まずイメージの仕様を確認する。
例えば今回使ったPHPイメージには、Apacheモジュールを有効にするためのコマンドが用意されています。モジュールがないというメッセージだけで判断して「apt-getコマンド」などでモジュールパッケージをインストールしようとすると、サーバーとモジュールの依存関係の不整合になるので問題です。実際はモジュールパッケージがインストールされることはないのですが万が一の場合もあるので、うまくアプリケーションが動かない時は「説明書」をよく読みましょう。
Dockerをアプリケーション開発に使う
Visual Studio CodeにDocker拡張とRemote Development拡張をインストールしてRancher Desktopと組み合わせて使うと、 コンテナベースでアプリケーション開発ができるようになります。
詳細は次をご覧ください。
Rancher DesktopでKubernetesを動かす
Rancher DesktopでKubernetesが有効化されていれば、Rancher Desktopを起動するだけでKubernetesクラスタが利用可能になります。Docker Desktopにも簡単にKubernetesを動かすためのオプションはありますが、Rancher Desktopの場合はクラスタのバージョンを選択できます。またクラスター自体はk3sで動かすため、軽量なKubernetesクラスタとして動かせます。
- Kubernetesのバージョンは自由に選べます。Dockerだけを使いたいときはKubernetesをオフにすると、CPUやメモリー等の節約になります。
- ランタイムはcontainerdとDockerから選べます。
前述の開発用途でも使いたい場合は、Dockerを選択するようにします。
以上、今回はRancher Desktopのご紹介でした。
