k3s でクラスタ (Master 1台/Worker 2台) を構築してみた

こんにちは。サイオステクノロジー OSS サポート担当 Y です。

今回は、最近話題の k3s で 3台構成 (Master 1台/Worker 2台) のクラスタを構築してみました。(※以下の内容は CentOS 7.6/k3s v0.2.0 にて検証しています。)

■はじめに

今回は、Rancher Labs が開発した k3s にて、以下の様な Master 1台/Worker 2台のクラスタを構築してみました。

[ホスト名及び IP アドレス]

なお、こちらの記事でシングルノード構成の k3s サーバを構築しているため、興味がある方はそちらもご参照下さい。

■k3s のインストール

まずは各ノードでのインストールですが、k3s はシングルバイナリで提供されているため、それぞれのノードでそのバイナリをダウンロードするだけです。

[Master]

[Worker 1]

[Worker 2]

■Master 起動

まずは、ダウンロードしたバイナリを使って k3s の Master を起動します。

最初に、こちらの記事で発生したエラーを回避するため、/etc/hosts に自分自身のホスト名を記載します。

加えて、/etc/hosts で各ノードの名前解決も実施できるように設定しておきます。

[Master]

上記設定実施後、以下のコマンドを実行し Master を起動します。

[Master]

上記コマンドを実行後、k3s kubectl node コマンドで Master ノードの STATUS が Ready になってりいることを確認します。

[Master]

これで Master の起動は完了です。

■Worker 起動 (Master へ接続)

次に、k3s の Worker を起動 (及び Master へ接続) します。

始めに、Worker ノードでもこちらの記事で発生したエラーを回避するため、/etc/hosts に自分自身のホスト名を記載しつつ、各ノードの名前解決も実施できるように設定しておきます。

[Worker 1]

[Worker 2]

次に Master に接続するための token を確認します。この token の情報は Master の /var/lib/rancher/k3s/server/node-token で確認することが可能です。

[Master]

そして、Quick start の記載を参考に、上記 token を指定しつつ、以下の様なコマンドを実行します。

[Worker 1]

しかし、上記の様なエラーになってしまいました。

“failed to get CA certs” となっていますが、メッセージの後半に “no route to host” と出力されているため、そもそも Master との通信が確立できていないようにも見えます。

ドキュメントを調べてみたところ、Open ports / Network security に k3s が利用する port の情報が記載されていました。恐らく、OS 側の firewalld で Master – Worker 間の通信が弾かれてしまっていると思われます。

そのため、上記のドキュメントの記載に従い Master の firewalld にて TCP/6443 と UDP/8472 宛のパケットを許可する設定を実施します。(※今回は単純な検証であるため、ざっくりと TCP/6443 及び UDP/8472 を空けていますが、実際には各環境のセキュリティ要件に合わせた設定を実施する必要があるのでご注意下さい)

[Master]

また、UDP/8472 を利用した通信についてはノード間での通信に利用される旨の記載があるため、各 Worker でも UDP/8472 宛のパケットを許可する設定を実施します。

[Worker 1]

[Worker 2]

それでは、改めて Worker 1 で k3s を起動してみます。

Worker 1 での k3s コマンド実行後に Master で k3s kubectl get node を実行すると、起動した Worker 1 (k3s-node-1.example.com) が接続されていることが確認できました。

[Master]

同様に Worker 2 の k3s も起動 (Master に接続) してみます。

Worker 2 起動後に Master で k3s kubectl get node を実行すると、Worker 2 (k3s-node-2.example.com) も接続されていることが確認できました。

正直なところ、いくつか Error や Failed のメッセージが出力されていて気になるのですが、とりあえず Master に接続 (Master が各 Worker を認識) できている様なので、今回はこのまま動作検証を続行します。

■動作検証 (Pod のデプロイ)

最後に、構築した k3s クラスタ上にコンテナ (Pod) をデプロイしてみます。

前回の記事で利用したものと同じマニフェスト (YAML ファイル) を作成し、k3s kubectl apply コマンドで適用します。

[Master]

[Master]

マニフェストの詳細は割愛しますが、大雑把に説明すると以下の様な設定を実施しています。

・NGINX コンテナ (Pod) を 3つデプロイ。
・k3s をインストールした仮想サーバの 30080番 port 宛の通信を、いずれかの NGINX コンテナの 80番 port に転送。

また、どの NGINX コンテナ (Pod) からのレスポンスであるかを判断できるように、Pod 名をレスポンス (index.html) に含めるようにしています。

デプロイが完了すると、各リソースの状態が以下の様になると思います。

[Master]

それでは、実際に k3s をインストールした仮想サーバの 30080番 port 宛てに HTTP リクエストを投げてみます。

[Master]

すると、上記の様なエラーが返ってきてしまいました。

何回かリクエストを実行してみると、”エラーになる場合” と “正常にレスポンスが返ってくる場合” の 2通りの動作をしているようです。

[Master 宛てのリクエスト実行]

また、各ノードに対してリクエストを実行してみると、同じ様に “エラーになる場合” と”正常にレスポンスが返ってくる場合” があるようですが、各ノード毎に “正常にレスポンスが返ってきている Pod 名が異なっている” 様に見受けられます。

[Worker 1 宛てのリクエスト実行]

[Worker 2 宛てのリクエスト実行]

まとめてみると、リクエスト送信先のノードと正常にレスポンスが返ってくる Pod の組み合わせは以下の様な感じになっています。

これについて、各 Pod がデプロイされているノードを調べてみると以下の様になっていました。

[Master]

どうやら、NodePort (30080 port) 宛てのリクエストについて、”リクエストを受信したノード上にある Pod にリクエストが割り振られた場合” には正常にレスポンスが返ってきており、”リクエストを受信したノード以外のノードにある Pod にリクエストが割り振られた場合” は正常にレスポンスを得られていないようです。

調べてみると、こちらのドキュメントに記載があるように、Kubernetes での NodePort を利用した通信では、リクエストを受信したノード (例: k3s-node-1.example.com) と異なるノード (例: k3s-node-2.example.com) 上にある Pod にリクエストを割り振る場合、デフォルトではノード間で通信 (パケット転送) を行う仕組みになっているようです。

これらの情報を鑑みると、各ノード間での通信 (パケット転送) に何等かの問題が発生している可能性がありそうです。

そのため、リクエストをループ処理で実行しながら iptables -nvL コマンドの出力を眺めてみたところ、以下の様に FORWARD チェインの REJECT (下から 3行目のルール) に合致したパケット数が増加していました。

[Master]

上記より、FORWARD チェインにてノード間の通信 (パケットの転送) が REJECT されてしまっている可能性がありそうです。

そのため、各ノードで以下の様なコマンドを実行し LAN 内でのパケット転送を許可してみました。(※今回は単純な検証であるため、ざっくりと LAN 内でのパケット転送を全て許可していますが、実際には各環境のセキュリティ要件に合わせた設定を実施する必要があるのでご注意下さい)

[Master]

[Worker 1]

[Worker 2]

すると、各ノード (Master/Worker 1/Worker 2) 宛てのリクエストに対して、3つの Pod にリクエストが割り振られつつ、全ての Pod から正常にレスポンスを受け取ることができるようになりました。

[Master 宛てのリクエスト実行]

[Worker 1 宛てのリクエスト実行]

[Worker 2 宛てのリクエスト実行]

■まとめ

今回は、最近話題の k3s のクラスタを構築してみました。

途中何回か躓いた部分はあったのですが、どうにか 3台構成のクラスタを構築して基本的な動作 (Pod のデプロイとリクエストの処理) を検証することができました。

まだリリースされて日が浅い OSS ですが、軽量な Kubernetes として興味深い製品であるため、今後も機会があれば検証を実施してみようと思います。

>> 雑誌等の執筆依頼を受付しております。
   ご希望の方はお気軽にお問い合わせください!

ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。