Ubuntu 18.04でKubeadmを使用してKubernetesクラスターを作成する方法

Kubernetesは、コンテナを大規模に管理するコンテナオーケストレーションシステムです。 Kubernetesは、運用環境でコンテナを実行した経験に基づいてGoogleが最初に開発したオープンソースであり、世界中のコミュニティによって積極的に開発されています。

[.note]＃Note:このチュートリアルでは、この記事の公開時点でサポートされている公式バージョンであるバージョン1.14のKubernetesを使用しています。 最新バージョンの最新情報については、Kubernetesの公式ドキュメントのcurrent release notesを参照してください。
＃

Kubeadmは、APIサーバー、コントローラーマネージャー、KubeDNSなどのKubernetesコンポーネントのインストールと構成を自動化します。 ただし、ユーザーの作成や、オペレーティングシステムレベルの依存関係とその構成のインストールは処理しません。 これらの予備タスクでは、AnsibleやSaltStackなどの構成管理ツールを使用できます。 これらのツールを使用すると、追加のクラスターを作成したり、既存のクラスターを再作成したりするのがはるかに簡単になり、エラーが発生しにくくなります。

このガイドでは、AnsibleとKubeadmを使用してゼロからKubernetesクラスターをセットアップし、コンテナー化されたNginxアプリケーションをデプロイします。

クラスターには、次の物理リソースが含まれます。

マスターノード（Kubernetesのnodeはサーバーを指します）は、クラスターの状態を管理する役割を果たします。 Etcdを実行し、ワークロードをワーカーノードにスケジュールするコンポーネント間でクラスターデータを格納します。

ワーカーノードは、workloadsが存在するサーバーです（つまり、 コンテナ化されたアプリケーションとサービス）が実行されます。 ワーカーは、スケジューリングが完了するとマスターがダウンしても、割り当てられたワークロードを引き続き実行します。 ワーカーを追加すると、クラスターの容量を増やすことができます。

このガイドを完了すると、クラスター内のサーバーにアプリケーションが消費するのに十分なCPUリソースとRAMリソースがあれば、コンテナー化されたアプリケーションを実行する準備が整います。 Webアプリケーション、データベース、デーモン、およびコマンドラインツールを含む、ほぼすべての従来のUnixアプリケーションをコンテナ化して、クラスター上で実行することができます。 クラスター自体は、各ノードで約300〜500MBのメモリと10％のCPUを消費します。

クラスターをセットアップしたら、WebサーバーNginxをクラスターにデプロイして、ワークロードが正しく実行されていることを確認します。

[[step-1 -—- setting-up-the-workspace-directory-and-ansible-inventory-file]] ==ステップ1—ワークスペースディレクトリとAnsibleインベントリファイルの設定

このセクションでは、ローカルマシン上にワークスペースとして機能するディレクトリを作成します。 Ansibleをローカルで設定して、リモートサーバーと通信し、コマンドを実行できるようにします。 それが完了したら、サーバーのIPアドレスや各サーバーが属するグループなどのインベントリ情報を含むhostsファイルを作成します。

3つのサーバーのうち、1つはIPがmaster_ipとして表示されるマスターになります。 他の2つのサーバーはワーカーであり、IPはworker_1_ipとworker_2_ipになります。

ローカルマシンのホームディレクトリに~/kube-clusterという名前のディレクトリを作成し、その中にcdを作成します。

このディレクトリは、残りのチュートリアルのワークスペースであり、すべてのAnsibleプレイブックが含まれます。 また、すべてのローカルコマンドを実行するディレクトリです。

nanoまたはお気に入りのテキストエディタを使用して、~/kube-cluster/hostsという名前のファイルを作成します。

次のテキストをファイルに追加します。これにより、クラスターの論理構造に関する情報が指定されます。

~/kube-cluster/hosts

Ansibleのinventory filesは、IPアドレス、リモートユーザー、コマンドを実行するための単一のユニットとしてターゲットとするサーバーのグループなどのサーバー情報を指定するために使用されることを思い出してください。 ~/kube-cluster/hostsがインベントリファイルになり、クラスターの論理構造を指定する2つのAnsibleグループ（mastersとworkers）を追加しました。

mastersグループには、マスターノードのIP（master_ip）を一覧表示し、Ansibleがrootユーザーとしてリモートコマンドを実行するように指定する「master」という名前のサーバーエントリがあります。

同様に、workersグループには、ワーカーサーバー用の2つのエントリ（worker_1_ipとworker_2_ip）があり、これらもansible_userをrootとして指定します。

ファイルの最後の行は、管理操作にリモートサーバーのPython 3インタープリターを使用するようAnsibleに指示しています。

テキストを追加したら、ファイルを保存して閉じます。

グループでサーバーインベントリを設定したら、オペレーティングシステムレベルの依存関係のインストールと構成設定の作成に移りましょう。

[[step-2 -—- creating-a-non-root-user-on-all-remote-servers]] ==ステップ2—すべてのリモートサーバーで非rootユーザーを作成する

このセクションでは、すべてのサーバーでsudo特権を持つ非rootユーザーを作成して、非特権ユーザーとして手動でSSHでログインできるようにします。 これは、たとえば、top/htopなどのコマンドでシステム情報を表示したり、実行中のコンテナーのリストを表示したり、rootが所有する構成ファイルを変更したりする場合に役立ちます。 これらの操作はクラスターのメンテナンス中に定期的に実行され、そのようなタスクに非rootユーザーを使用すると、重要なファイルを変更または削除したり、他の危険な操作を誤って実行したりするリスクが最小限に抑えられます。

ワークスペースに~/kube-cluster/initial.ymlという名前のファイルを作成します。

次に、次のplayをファイルに追加して、すべてのサーバーでsudo権限を持つ非rootユーザーを作成します。 Ansibleでのプレイとは、特定のサーバーとグループを対象とする実行されるステップの集まりです。 次のプレイは、非ルートsudoユーザーを作成します。

~/kube-cluster/initial.yml

このプレイブックの機能の内訳は次のとおりです。

テキストを追加したら、ファイルを保存して閉じます。

次に、ローカルで実行してプレイブックを実行します：

コマンドは2〜5分以内に完了します。 完了すると、次のような出力が表示されます。

準備が完了したら、Kubernetes固有の依存関係のインストールに進むことができます。

[[step-3 -—- installing-kubernetetes-39-dependencies]] ==ステップ3—Kubernetetesの依存関係をインストールする

このセクションでは、Kubernetesに必要なオペレーティングシステムレベルのパッケージをUbuntuのパッケージマネージャーでインストールします。 これらのパッケージは次のとおりです。

ワークスペースに~/kube-cluster/kube-dependencies.ymlという名前のファイルを作成します。

次の再生をファイルに追加して、これらのパッケージをサーバーにインストールします。

~/kube-cluster/kube-dependencies.yml

プレイブックの最初のプレイは次のことを行います。

2番目のプレイは、マスターノードにkubectlをインストールする単一のタスクで構成されます。

[.note]＃Note: Kubernetesのドキュメントでは、ご使用の環境に最新の安定版Kubernetesを使用することを推奨していますが、このチュートリアルでは特定のバージョンを使用しています。 これにより、Kubernetesは急速に変化し、最新バージョンがこのチュートリアルで機能しない可能性があるため、手順を正常に実行できるようになります。
＃

完了したら、ファイルを保存して閉じます。

次に、ローカルで実行してプレイブックを実行します：

完了すると、次のような出力が表示されます。

実行後、Docker、kubeadm、およびkubeletがすべてのリモートサーバーにインストールされます。 kubectlは必須コンポーネントではなく、クラスターコマンドの実行にのみ必要です。 マスターからのみkubectlコマンドを実行するため、このコンテキストではマスターノードにのみインストールするのが理にかなっています。 ただし、kubectlコマンドは、任意のワーカーノードから、またはクラスターを指すようにインストールおよび構成できる任意のマシンから実行できることに注意してください。

これで、すべてのシステム依存関係がインストールされました。 マスターノードをセットアップして、クラスターを初期化しましょう。

[[step-4 -—- setting-up-the-master-node]] ==ステップ4—マスターノードのセットアップ

このセクションでは、マスターノードを設定します。 ただし、クラスタには両方が含まれるため、プレイブックを作成する前に、PodsやPod Network Pluginsなどのいくつかの概念を説明する価値があります。

ポッドは、1つ以上のコンテナーを実行するアトミックユニットです。 これらのコンテナは、ファイルボリュームやネットワークインターフェイスなどのリソースを共有します。 ポッドはKubernetesのスケジューリングの基本単位です。ポッド内のすべてのコンテナーは、ポッドがスケジュールされている同じノードで実行されることが保証されています。

各ポッドには独自のIPアドレスがあり、1つのノード上のポッドは、ポッドのIPを使用して別のノード上のポッドにアクセスできる必要があります。 単一ノード上のコンテナは、ローカルインターフェイスを介して簡単に通信できます。 ただし、ポッド間の通信はより複雑であり、1つのノードのポッドから別のノードのポッドにトラフィックを透過的にルーティングできる個別のネットワークコンポーネントが必要です。

この機能は、ポッドネットワークプラグインによって提供されます。 このクラスターでは、安定したパフォーマンスの高いオプションであるFlannelを使用します。

ローカルマシンでmaster.ymlという名前のAnsibleプレイブックを作成します。

次の再生をファイルに追加して、クラスターを初期化し、Flannelをインストールします。

~/kube-cluster/master.yml

このプレイの内訳は次のとおりです。

完了したら、ファイルを保存して閉じます。

次を実行して、プレイブックをローカルで実行します。

完了すると、次のような出力が表示されます。

マスターノードのステータスを確認するには、次のコマンドを使用してSSHでマスターノードに接続します。

マスターノード内で、次を実行します。

次の出力が表示されます。

出力には、masterノードがすべての初期化タスクを完了し、Ready状態にあり、そこからワーカーノードの受け入れとAPIサーバーに送信されたタスクの実行を開始できることが示されます。 これで、ローカルマシンからワーカーを追加できます。

[[step-5 -—- setting-up-the-worker-nodes]] ==ステップ5—ワーカーノードの設定

クラスターにワーカーを追加するには、それぞれに対して単一のコマンドを実行する必要があります。 このコマンドには、マスターのAPIサーバーのIPアドレスとポート、セキュアトークンなどの必要なクラスター情報が含まれます。 セキュアトークンを渡すノードのみがクラスターに参加できます。

ワークスペースに戻り、workers.ymlという名前のプレイブックを作成します。

次のテキストをファイルに追加して、ワーカーをクラスターに追加します。

~/kube-cluster/workers.yml

プレイブックの機能は次のとおりです。

完了したら、ファイルを保存して閉じます。

ローカルで実行してプレイブックを実行します：

完了すると、次のような出力が表示されます。

ワーカーノードを追加すると、クラスターが完全にセットアップされて機能するようになり、ワーカーはワークロードを実行する準備が整います。 アプリケーションをスケジュールする前に、クラスターが意図したとおりに機能していることを確認しましょう。

[[step-6 -—- verifying-the-cluster]] ==ステップ6—クラスターの検証

ノードがダウンしているか、マスターとワーカー間のネットワーク接続が正しく機能していないため、セットアップ中にクラスターが失敗することがあります。 クラスターを検証し、ノードが正しく動作していることを確認しましょう。

マスターノードからクラスターの現在の状態をチェックして、ノードの準備ができていることを確認する必要があります。 マスターノードから切断した場合、次のコマンドを使用してSSHでマスターノードに戻すことができます。

次に、次のコマンドを実行して、クラスターのステータスを取得します。

次のような出力が表示されます。

すべてのノードのSTATUSの値がReadyである場合、それらはクラスターの一部であり、ワークロードを実行する準備ができていることを意味します。

ただし、一部のノードのSTATUSがNotReadyである場合は、ワーカーノードがまだセットアップを完了していない可能性があります。 kubectl get nodesを再実行し、新しい出力を検査する前に、約5〜10分待ちます。 いくつかのノードのステータスがまだNotReadyである場合は、前の手順でコマンドを確認して再実行する必要がある場合があります。

クラスターが正常に検証されたので、クラスターでサンプルのNginxアプリケーションをスケジュールしましょう。

[[step-7 -—- running-an-application-on-the-cluster]] ==ステップ7—クラスターでのアプリケーションの実行

これで、コンテナ化されたアプリケーションをクラスターにデプロイできます。 慣れるために、DeploymentsとServicesを使用してNginxをデプロイし、このアプリケーションをクラスターにデプロイする方法を確認しましょう。 Dockerイメージ名と関連するフラグ（portsやvolumesなど）を変更すれば、他のコンテナー化されたアプリケーションにも以下のコマンドを使用できます。

マスターノード内で、次のコマンドを実行して、nginxという名前のデプロイメントを作成します。

デプロイメントはKubernetesオブジェクトの一種で、クラスターの存続期間中にポッドがクラッシュした場合でも、定義されたテンプレートに基づいて、指定された数のポッドが常に実行されるようにします。 上記のデプロイでは、DockerレジストリのNginx Docker Imageから1つのコンテナを含むポッドが作成されます。

次に、次のコマンドを実行して、アプリを公開するnginxという名前のサービスを作成します。 これは、NodePortを介して行われます。これは、クラスターの各ノードで開かれている任意のポートを介してポッドにアクセスできるようにするスキームです。

サービスは、クラスター内部サービスを内部および外部の両方のクライアントに公開する別の種類のKubernetesオブジェクトです。 また、複数のポッドへのリクエストの負荷分散が可能で、Kubernetesの不可欠なコンポーネントであり、他のコンポーネントと頻繁にやり取りします。

次のコマンドを実行してください。

これにより、次のようなテキストが出力されます。

上記の出力の3行目から、Nginxが実行されているポートを取得できます。 Kubernetesは、30000より大きいランダムなポートを自動的に割り当てますが、ポートが別のサービスによってバインドされていないことを確認します。

すべてが機能していることをテストするには、ローカルマシンのブラウザからhttp://worker_1_ip:nginx_portまたはhttp://worker_2_ip:nginx_portにアクセスします。 Nginxの使い慣れたウェルカムページが表示されます。

Nginxアプリケーションを削除する場合は、最初にマスターノードからnginxサービスを削除します。

次を実行して、サービスが削除されたことを確認します。

次の出力が表示されます。

次に、デプロイメントを削除します。

以下を実行して、これが機能したことを確認します。

このガイドでは、KubeadmとAnsible for automationを使用してUbuntu 18.04にKubernetesクラスターを正常に設定しました。

クラスターがセットアップされたので、クラスターで何をすべきか疑問に思っている場合は、次のステップとして、クラスターに独自のアプリケーションとサービスを快適にデプロイすることです。 プロセスのガイドとなる詳細情報を含むリンクのリストを次に示します。

調べることができる他の重要な概念は、Volumes、Ingresses、およびSecretsです。これらはすべて、実稼働アプリケーションをデプロイするときに役立ちます。

Kubernetesには、提供する多くの機能と機能があります。 The Kubernetes Official Documentationは、概念について学び、タスク固有のガイドを見つけ、さまざまなオブジェクトのAPIリファレンスを検索するのに最適な場所です。