前編はこちら

前書き

Kubernetes (以下、k8s) を扱う前、インフラ初心者だった私の知識は「すごく便利なツールがあるらしい」程度だった。ふとしたキッカケで「k8sを利用したアプリ環境を作ってみないか」という話が先輩技師から降ってきたので、意気揚々とk8sを学ぼうとしたが、いざ触ってみると「k8sってなんだかややこしいな」と戸惑うほど初めての経験ばかりだった。

混乱したまま環境を構築する前に「そもそもk8sって何が嬉しいのか」を振り返ろうとし、少しずつつ咀嚼していくと ”k8sはコンテナで構成されるPodというものをうまく活用して、柔軟なアプリ環境を構築する素晴らしいツール” だと分かってきた。

しかし、よく考えてみると新たな疑問が目の前に現れる。
「Pod AからPod A-1, A-2, … と作ってくれるらしいけど、どこにあるか分からないPodにどうやってアクセスするんだ？」

Podはどこにいるのだろう？

k8sについて調べてみると、Podを活用することで柔軟なアプリ環境を構築することができるという嬉しさが分かったのだが、重要なことを忘れていた。k8sでは人間が宣言的設計、簡単に言うと ”こういうPod (Pod A) がN個欲しい” というレシピを書いて、そのレシピを元にk8sがPod A-1, A-2, … A-Nと言った具合にN個を作成してくれるという流れになっている。では、このPod A-1たちはどこに出来ているのだろう？そして、出来あがったPodにどうやってアクセスするのだろうか？

Node という貨物船

k8sが動くにはもちろんマシンが必要だ。加えて、この便利なPodを運用するためのマシンが必要なわけだから、これらをどうやって準備をしている（正確には、私達が準備する）のだろうか。Podの運用には必要な要素なわけだから、もう少し読み進めると何かそういったものがあるのだろうと調べてみると、”PodはNodeにデプロイされる”というような文面がある。冒頭の疑問を解決するには、まずNodeについて知らないといけないみたいだ。

Nodeは実際にアプリケーションが実行されるマシンを指し、物理マシンや仮想マシンで構成されるらしく、k8sがまとめて管理してくれる。現時点ではNodeはPodを大量に載せた貨物船のようなマシンという理解ができる。しかしながら、このNodeがただ複数存在するだけでは管理は非常にややこしいのではなかろうか。どのPod がどのNodeにあるかを人間が管理をするとなると、位置関係を把握するだけで1日が終わってしまう。

他にも挙げていけば、管理するに当たって面倒くさいんじゃないかと考えてしまうような状況はありそうだが、調べていくとk8sは

・アプリケーションのPodを搭載するWorker Node
・Worker Nodeたちを管理するMaster Node

という2種類のNodeを作ることで、管理部分と実働部分を分けて環境を作ってくれるようだ。具体的には、管理部分となるMaster Nodeでkube-schedulerやkube-controller-manager というコンポーネントが動作しており、アプリケーションのPodをどのWorker Nodeにいくつ配置するか、といったことを自動的に判断してくれている。そのため、私達は実際の現場であるWorker Nodeというマシンをあまり気にしなくてよく、指揮をk8sに渡せばMaster NodeがWorker Node達へ命令し、管理や運用をよしなにしてくれるわけだ！

と喜んだのは束の間、まだ問題が解決していなかった。「Podはどこにいるのか」という問題については、k8sのMaster Nodeが自動に管理してくれるので知ることはできるものの、「外部からPodへの接続や、Pod間での通信はどうやって行うのか」という問題は残されたままだった。とはいえ、Master NodeはPodを管理してくれるのだから、どこに接続すべきかという案内もできるのではないだろうか？と思いつつ読み進めていく。

Service という受付

Pod A-1, … はMaster Nodeの指揮で、いずれかのWorker Nodeに作られる。Master Nodeはアクセス量の増減に合わせてPodの数を調整したり、障害が起きたらPodを再生成したりなどの管理することで、柔軟で耐障害性がある環境の構築ができるようだ。一方で、Mater NodeがPodの調整を自動的にやってくれるということは、必ずしも固定されたPodがあるわけではなく、アクセスは確約されないんじゃなかろうか。やはり、現状で知っている範囲だと

・外部からアプリに接続したいときに、どのNodeのどのPodへとアクセスすればいいかがわからない。
・Pod同士で連携したい場合、例えばPod AとPod Bで連携したいときにPod A-1はどのPod Bにアクセスすればいい？そもそも、Pod BはどのNodeにいる？

といったように「どうやって通信を担保しているのか」についてはわかっていない。

こういった疑問を持っていると、k8sで準備されているServiceという概念にたどり着いた。k8sではPod という、これまでに比べて抽象的な手法でコンテナを利用しているのであるのに合わせ、宣言的設計で通信が定義できるようにされていた。ここまで来ると理解がしやすくなってきた。

Serviceでは

・Pod Aに搭載したコンテナを公開したいので、ユーザーからのアクセスはPod Aへとつなぐ受付を作ること
・Pod AはPod Bと連携させたいので、Pod A, B間の通信用に受付を作ること

といった具合の受付が作れるようになっていた。k8sは内部DNSのkube-dnsと、サービスディスカバリのServiceを利用して、DNSベースで名前解決を行ってくれる。 細かい話をすると、ServiceはNodePortやLoadBalancerのような区分があり、それぞれで役割分担をすることで上記のような宣言的設計を分類しているようだ。これらの受付を目的に応じて作ってしまえば、あとはk8sが頑張ってPod なり、外部からのアクセスなりをうまく案内してくれるようになるのだ！

まとめ

k8sって、なんだか専門用語が多くて混乱するなぁと思っていた。「そもそもk8sって何が嬉しいんだろう？今までと違う部分はなんだろう？」と立ち返って紐解いていくと、何がしたいのか、どうやって実現しようとしているのかというものが垣間見え、環境構築をするうえですべきことが分かってきた。

k8sはコンテナと呼ばれる仮想化技術を利用する過程で、宣言的設計というこれまでに比べると抽象的な手法を用いた構成になっている。今回、調べてきた Pod、Node、Service以外にも様々な概念は実際にあるのだが、最低限の運用をまず行うには、これらを使った環境を構築しなければいけない。実際の運用をするにあたっては、知るべきところは非常に多く、まだまだの段階だった。

しかし、闇雲にk8sを使おうとする前に、一度時間を取って目的から立ち返ってみるのは非常に良かった。よし、基本的な構成や思想が分かったし頑張って組み立ててみよう！　と意気込むのだが、再びk8sの海を彷徨ってしまうのは、次の機会に。

――――――――――――――――――――――――――――――――――

執筆者プロフィール：合屋 純
九州大学大学院理学府修士卒 大学院で物理学を専攻し、数値計算プログラムに触れたことをキッカケにエンジニアリングに興味を持つ。
現在はリアルグローブ・オートメーティッドにて、コンテナ関連技術や自動化ツールの導入業務に従事。

【ご案内】
ITシステム開発やITインフラ運用の効率化、高速化、品質向上、その他、情シス部門の働き方改革など、IT自動化導入がもたらすメリットは様々ございます。
IT業務の自動化にご興味・ご関心ございましたら、まずは一度、IT自動化の専門家リアルグローブ・オートメーティッド(RGA)にご相談ください！

お問合せは以下の窓口までお願いいたします。

【お問い合わせ窓口】
株式会社リアルグローブ・オートメーティッド
代表窓口：info@rg-automated.jp
URL：https://rg-automated.jp

（編集：馬塚勇介／校正：水谷裕一）