コンテナは、数年前から主にアプリケーション開発局面で浸透してきた。アプリケーション開発サイクルが年々短縮化されるなか、機能単位でアプリケーションを疎結合するマイクロサービスが注目されている。軽量かつポータビリティ性の高いコンテナはその実装基盤として最適であり、本番アプリケーションの実行基盤として利用が広がりつつある。
コンテナ管理ツールであるKubernetesはGoogleによって開発されたのち、CNCF（Cloud Native Computing Foundation）に寄贈され、今もコミュニティは拡大し続けているのに加え、大手クラウド事業者でのKubernetesサービス提供が充実してきた。Kubernetesはコンテナ管理ソフトウェアの事実上のスタンダードであり、これからのインフラ担当者にはKubernetesの知識が必須である。
またコンテナ上でアプリケーションを実行する際、インターネットなど外部のネットワークからコンテナへのアクセスが多く発生するだろう。そこで避けて通れないのが、Kubernetesのネットワークを理解することである。
そこで本稿ではKubernetesの概要を説明したうえで、Kubernetesをネットワーク的視点から紐解きつつ、実行例を紹介していきたい。
コンテナの特徴
コンテナは端的に言うと、Linuxベースのオペレーティングシステム（OS）を論理分割する技術であり、DockerやLXCなどが代表的である。アプリケーション実行基盤としてコンテナが高く評価される理由は、主に軽量性および高いポータビリティ性にある。
軽量性
コンテナは、Linux OS部分は共有したうえで、CPUやネットワークなどの各種リソースを名前空間という仕組みで論理分割することにより独立性を保つ。そのため、1つのコンテナ当たりのリソース消費を抑えることで、1台のサーバーで多数のコンテナを稼働させられるのに加え、一般的に数秒から数十秒といった非常に短い時間で起動できる。
高いポータビリティ性
コンテナ環境ではハードウェアが仮想化されているので、ユーザーがその違いを意識する必要がない。また、アプリケーションが必要とするモジュールなどをコンテナ内にまとめてパッケージ化できる。たとえばPCに導入したコンテナ環境で開発したコードを、実行に必要なモジュールとともにパッケージ化し、クラウド上のコンテナ環境にデプロイするだけで、実行環境を再現できる。
これらの特徴を利用して、マイクロサービスのアプリケーション機能単位でコンテナを作成していくと、コンテナ数が飛躍的に増大していく。そこで必要なのが、Kubernetesに代表されるコンテナ管理ツールである。
Kubernetesの概要
Kubernetesの動作原則は、ユーザーが「あるべき状態」を定義すると、状況をモニタリングしながらその状態を満たすよう自動管理することである。Kubernetesの多彩な機能のなかで、とくに重要なのが以下である。
・スケジューリング
ユーザーからのデプロイ指示（例：Webサーバーコンテナを3つ作る）に対して、どのホストにコンテナを配置するかを決めて、デプロイする。
・セルフヒーリング
ホスト障害などにより、デプロイ済みのコンテナが失われたことを検知すると、別のホストにコンテナを自動デプロイし、ユーザーがリクエストした数だけコンテナが存在する状態を再び満たす。
・オートスケーリング
コンテナの高負荷時には、自動的にコンテナを追加デプロイし、適切な水準まで負荷を低下させる。
Kubernetesの主なコンポーネントを図表1に示す。Kubernetesが管理する物理（または仮想）マシンのLinuxサーバーをNodeと呼び、それらの集合をClusterと呼ぶ。Node内で稼働するコンテナは、Podという集まりで管理される。さらに、Podには特徴を示す任意のラベルを付けて識別する（“web”など）。
Kubernetesのアーキテクチャ概要を図表2に示す。ユーザーのPodが動作するWorker Nodeと、Kubernetesを管理するためのコンポーネントが動くMaster Nodeで構成される。いずれも1つあるいは複数のNodeで構成する。
Master Nodeで稼働するapi-serverは、ユーザーからの指示をkubectlというコマンドもしくはGUI Dashboardなどから受け、各Worker Nodeで稼働するkubeletというエージェントに対して指示する。kubeletは当該Worker Node内で、必要な変更や情報収集を実行する。
Kubernetesの提供形態
マネージド・サービス
IBM Cloud Kubernetes Services（IKS）、Amazon Elastic Container Service for Kubernetes （Amazon EKS）、Kubernetes Engine （GKE）などがある。ポータル画面から簡単な操作で、すぐにKubernetes環境を構築できる。
この場合、クラウド事業者の管理下となるため、Master Nodeに対する変更や、Worker NodeのホストOSに対する操作などは、ユーザーが自由に実行できないのが一般的である。また、Kubernetesで利用するプラグインなどがあらかじめ決められていたり、料金プランに依存して機能が制限されている場合もある。
オンプレミス向けパッケージ
IBM Cloud Private、Google Kubernetes Engine on-Premなどがある。シンプルな操作で導入できるメリットに加えて、パッケージ独自の便利なツールがバンドルされている。マネージド・サービスと比較すると、プラグインの選択肢や構成の自由度はやや高い。
自前で構築
自身で必要なモジュールを個々にダウンロードおよびインストールして、Kubernetesを構成できる。自由度は高いが、構築時や運用時にKubernetesやLinuxコンテナなどに対する十分な知識が必要である。
クラウド事業者はマネージド・サービスおよびオンプレミス向けパッケージを提供し、互いのアプリケーションをシームレスに連携すると謳う場合が多いので、双方の連携を視野に入れて選定すべきである。
Kubernetesのネットワーク
KubernetesではPodはホスト外のネットワークに直接接続せず、サーバー内部の仮想ブリッジに接続する。そのため外部のネットワークと通信するには、IPマスカレード（またはPAT：Port Address Trans lation）を行う必要がある。
しかし前述したとおり、Podが他のホストへ移ることもあれば、同じ種類のPodの数が増えることもあり、PodのIPアドレスは非常に流動的である。そのため、IPマスカレードの変換ルールを静的に定義するのは現実的ではない。
そこでKubernetesでは、Podの実アドレスの変化に追随して、変換ルールを自動的に更新する仕組みを提供している。また同じ種類のPodが複数あれば、負荷分散を実行する。いわゆるロードバランサのような仕組みを備える。
このようにアプリケーションを外部へ公開するための仕組みをServiceと呼ぶ。Serviceには、以下のタイプがある（図表3）。
ClusterIP
すべての基本となるserviceであり、Cluster内部を起点とするアクセスに特化している。
NodePort
外部ネットワークからのアクセスを提供する。全Nodeに共通のポート番号をアサインする。クライアントは、Worker Nodeのネットワーク・インターフェースのIPアドレスにアクセスするので、Worker NodeのIPアドレスが不変であることが前提となる。
LoadBalancer
外部ネットワークからのアクセスを提供する。ExternalIPアドレスが、Worker NodeのIPアドレスとは別途にアサインされる。
ClusterIPとNodePortはどのようなKubernetes環境でも利用可能である。しかしLoadBalancerは別途、ExternalIPアドレスを自動アサインし、ClusterIPに転送するような仕組みが必要になる。マネージド・サービスの場合、このような仕組みを実装していることが多いが、その仕様はそれぞれ異なることに注意が必要である。
ClusterIPの動作をより詳細に示したのが、図表4である。左図で示すとおり、KubernetesユーザーはServiceを定義する際、公開用IPアドレス（optional）とPort番号、およびPodのラベルを指定する。一致するラベルをもつPod群が、通信の振り分け先となる。ユーザーはPodのラベルを指定するのみで、Podの実IPアドレスは意識しなくともよい。
これをKubernetesの具体的な内部処理で表したものが、図表4の右図である。Worker Node内のkube-proxyというエージェントが、Serviceの作成やPodの状態などに追随して、Linuxのネットワーク通信制御を行うiptablesのルールを動的に書き換える。これにより、ClusterIPに対する通信がどのWorker Nodeに着信しても、その時点のPodの正しいIPアドレス宛てに通信が振り分けられる。
なお複数NodeにまたがるPod間の通信については、Worker NodeのIPアドレスを用いてカプセル化するのが一般的である（オーバーレイ方式）。これによりPodの実IPアドレスを外部ネットワークに見せることなく、Pod間通信を実現できる。
Kubernetesの実行例
マネージド・サービスであるIBM Cloud Kubernetes Service（IKS）の実行例を紹介する。
1 Clusterの作成
IBM Cloudポータル画面を操作して、IKSのClusterを作成する。任意のデータセンター（今回はSydney04を使用）、Cluster名、Nodeのスペックや数などを選択すると、30分程度でデプロイが完了する。
Clusterが作成されたのち、ポータルの指示どおりに、自身のPCでkubectlコマンドを使うための環境を設定する。
次に、Cluster内のWorker Nodeを確認する。Nodeの数とIPアドレスが確認できる。IKSの場合、各Worker NodeにはデフォルトでPublic（Global）IPアドレスと、Private IPアドレスがそれぞれ1つアサインされる（図表5）。
2 PodのDeployment
例として、NginxをベースとしたPodをデプロイするため、web-svr-deploy ment.yamlファイルを作成する。web-svrというラベルをつけて、3つのnginx Podを作成する（図表6）。
3つのPodが起動していることを確認できる。また、Podの実IPアドレスとして、172.30で始まるCluster内部でのみ使われるアドレスがアサインされている（図表7）。
3 LoadBalancer Serviceの作成
先ほど作成したPodのラベルweb-svrをselectorに指定して、LoadBalancer Serviceとして公開する例を示す。
まず、web-svr-lb.yamlファイルを作成する（図表8）。
IKSの実装では、EXTERNAL-IPというGlobalアドレスが自動的に割り当てられ、Load Balancer PodがWorker Node上に自動生成される。そのため、この例ではhttp://130.XXX.XXX.210:80 にアクセスすると、web-svrラベルに該当する3つのPodのいずれかにトラフィックが割り振られる。
なお、Load Balancerを設定すると、NodePortも合わせてアサインされるので（上記の例では31874番）、Worker Nodeのネットワーク・インターフェースのIPアドレスの31874番ポートにアクセスしても、同じ結果が得られる。
4 Ingressの作成
アプリケーション公開オプションとして、http（s）通信限定にはなるが、Ingressと呼ばれる機能も利用可能である。IngressはApplication Load Balancer （ALB）とも呼ばれ、URLのpathに応じて適切なserviceにマッピングできる。
先ほど作成したLoadBalancerタイプのserviceを削除し、web-svr-clusterip.yamlでClusterIPタイプのserviceを新規作成する（図表9）。続いて、web-svr-ingress.yamlでIngressを作成する（図表10）。
IKSでは、Ingress （ALB）用にデフォルトでGlobal IPアドレスが確保されており、DNSレコードも自動で作成されている。そのため、クライアントはIngress定義に指定したhost名でhttp（s）アクセスが可能である。
以上本稿ではKubernetesの概要を説明したうえで、Kubernetes管理下のコンテナをネットワークに公開する仕組みおよび実行例を紹介した。
マネージド・サービスの提供が増え、Kubernetes環境は非常に手軽かつ迅速に利用できるようになった。アプリケーションの実行環境をオンプレミスやクラウドで自由に選択できるプラットフォームとして、今後もKubernetesの利用は加速していくだろう。本稿を通じて、Kubernetesをより身近に感じていただければ幸いである。
著者｜尾島 陽子氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
テクニカル・コンピテンシー ネットワーク
アドバイザリーITスペシャリスト
2003年、日本アイ・ビー・エム システムズ・エンジニアリングに入社。以来、ネットワークを中心とした技術支援に携わり、ネットワーク・セキュリティやSDNなどの設計や構築などの技術支援活動を行っている。
［IS magazine No.22（2019年1月）掲載］
