Dockerは通常、開発者によるコンテナの最初の紹介を提供します。 Kubernetesは、本番環境でのコンテナの実行に関する課題を解決するオーケストレーションプラットフォームです。 DockerコマンドがKubernetesの対応するコマンドにどのようにマッピングされるかを次に示します。
dockerは使用できません Kubernetesで実行されているコンテナとやり取りするためのCLI。 Kubernetesは、独自のコマンドラインインターフェースkubectlを提供します 、クラスターの管理に役立ちます。 kubectlの使用を開始するためのガイドをお読みください ツールに慣れていない場合。
dockerはありません コマンドはkubectlで同じ名前になります 。 Kubernetesは独自の方法で機能を公開します。ワークロード自体は根本的に異なります。Dockerは一度に1つのコンテナーで動作するように設計されていますが、Kubernetesでは複数のレプリカのオーケストレーションが可能です。
最初に理解すべき点は、用語の変化です。 Dockerは「コンテナー」を指し、Kubernetesは「ポッド」を使用します。ポッドは、単一のユニットとして管理される1つのコンテナまたは複数のレプリカを実行する場合があります。この詳細はさておき、Dockerに「コンテナ」が表示されている場合は、Kubernetesの「ポッド」について考える必要があります。この記事の残りの部分では、これらの用語は同じ意味で使用されます。
Dockerでは、docker ps -aを使用します マシン上のすべてのコンテナを表示します。
最も近いKubernetesに相当するものは、kubectl get podsです。 。
2つのコマンドからの出力はまったく異なります。 Dockerは、コンテナーが実行しているワークロードに関する詳細情報を表示します。
Kubernetesは、describe podを使用するときに画像とコマンドの詳細を提供します 指図。ポッドの名前を渡す必要があります。これにより、テーブルの代わりにリストを使用して、より詳細な情報が得られます。
Dockerを使用すると、docker execを使用して実行中のコンテナーでコマンドを実行できます。 。
Kubernetesに相当するものはexecとも呼ばれます 。 Dockerコンテナ名の代わりにKubernetesポッド名を使用します。コマンドの指定方法は少し異なります。ポッド名とは--で区切る必要があります。 シーケンス。
-itを使用できます Dockerと同じ方法でインタラクティブアクセスを取得するためのフラグ。これは--stdin --ttyの省略形です。 ポッド内でシェルを起動する場合は常に使用する必要があります。 bashなどのシェル名を指定します 、コマンドとして。
Kubectlはattachをサポートしています すでに実行されているコンテナ内のプロセスにアタッチする場合のコマンド。 docker attachと同様に機能します ただし、-itを渡す必要があります インタラクティブなアクセスが必要な場合はフラグを立てます。
Dockerでコンテナのログを表示するには、docker logsを使用します 指図。 -fを追加する スイッチはログを「追跡」するので、ログは端末に継続的にストリーミングされます。
Kubectlのlogs コマンドの構文は同じです。 Dockerがコンテナ名を受け入れるのと同じ方法でポッド名を指定します。
DockerとKubernetesはどちらも、標準出力と標準エラー（stdout）からログを収集します / stderr ）実行中のコンテナのストリーム。 Kubernetesは、Dockerとは異なる方法でコンテナの再起動を処理します。 Dockerでは、再起動されたコンテナーが既存のコンテナーにログを追加しますが、Kubernetesは実行ごとに新しいログを作成します。 --previousを追加すると、置き換えられたコンテナのログを取得できます logsへのフラグ コマンド。
Dockerコンテナーは、runで作成されます 指図。 nginxを開始する方法は次のとおりです Dockerを搭載したサーバー：
docker run -d --name nginx --restart=always -p 80:80 nginx
これにより、nginxを使用してコンテナが作成されます ベースイメージを作成し、自動的に再起動するように設定します。サーバーはデフォルトのHTTPポート80にバインドされています。
Kubernetesでは、クラスタにコンテナを追加するときに、より高いレベルの抽象化について考える必要があります。コンテナを実行する代わりに、デプロイメントを作成します ワークロードを表すには：
kubectl create deployment --image=nginx nginx
これにより、nginxが作成されます 展開。ポッドは自動的に開始されます。ポッド内には、ウェブサーバーを実行するコンテナがあります。
デプロイメントを作成しても、そのコンテナーはどのポートにもバインドされません。新しく作成されたサーバーにはまだアクセスできません。ポートは露出する必要があります サービス経由 。ポッドは一時的なものであり、複数の複製されたコンテナが含まれる場合があります。サービスはポッドの論理的なコレクションを定義し、IPアドレスやポートなどのネットワークリソースをポッドに割り当てることができます。
nginxを公開する ポート80に展開すると、サーバーにアクセスできるようになります。
kubectl expose deployment nginx --port=80 --name nginx-http
クラスタのデフォルトIPアドレスのポート80にアクセスしようとすると、nginxに移動するはずです。 サーバー。
Kubectlは、他のdocker runを直接サポートしていません ボリュームの作成やバインドマウントなどのオプション。永続ストレージを必要とするコンテナでは、kubectlを介してボリュームを手動で構成する必要があります コマンドまたはボリュームマニフェスト。
Dockerコンテナーは、docker rmを使用して削除されます コンテナのIDを使用したコマンド。
Kubernetesではコンテナを直接削除することはできません。代わりに、デプロイメントを使用します ポッドを作成しました。 kubectl delete deploymentを使用します コマンド、デプロイメントの名前を渡します。
Dockerを使用すると、停止できます コンテナを削除する代わりに。 Kubernetesはこのアクションのサポートを削除しました。デプロイメントを一時的に一時停止するための推奨される方法は、レプリカ数を0に減らすことです。ポッドが実行されていない場合、ワークロードは効果的に停止されます。
kubectl scale --replicas=0 deployment/my-deployment
デプロイを再開する準備ができたら、scaleを実行します もう一度コマンドします。新しいレプリカ数を1に設定します 以上。より多くのレプリカを使用すると、ワークロードの可用性を高めることができます。
DockerCLIとkubectlの間に直接の類似点はありません 。ほとんどのKubernetesコマンドの構文は、対応するDockerコマンドとは異なります。 DockerベースのワークフローをKubernetesに移行する前に、新しい用語とオプションを学ぶ必要があります。
多くの場合、kubectlはありません。 DockerCLI機能の代替。 Dockerの機能は、コンテナーの概念に重点を置いています。 Kubernetesはそれを採用し、大幅に拡張されたリソースエコシステムの中心に配置します。
コンテナが単独で取り扱われることはめったにありません。代わりに、デプロイメント、サービス、レプリカセットなどのリソースを操作する必要があります。これが、Dockerユーザーの観点からKubernetesにアプローチするときに、Kubernetesの学習が難しいように見える理由です。
Dockerの基礎に精通している場合でも、Kubernetesへの移行は比較的簡単です。主な違いは、Dockerがコンテナーと見なすものは、通常、Kubernetesでは集約された「ポッド」としてアクセスされることです。ポッドは、クラスター内のワークロードを表す「デプロイメント」によって作成されます。不明な点がある場合は、kubectlを参照してください。 Dockerコマンドに適切な一致を見つけるためのドキュメント。