Kubernetes 最強活用術 Serviceとカスタムコントローラ

こんにちわ、あるいは、こんばんわ。IoTビジネス事業部プラットフォームサービス課のエンジニア曽我です。

Kubernetes 使ってますか？Kubernetes を利用するとアプリケーション（コンテナ）のデプロイや死活監視、スケーリングが簡単にできて便利？まだまだですね。Kubernetes の真の価値は Service リソースによるネットワーク設定の自動化にあります。ネットワーク機器の動的制御は技術ハードルが高く、オンプレミス環境での実現は困難を極めます。Service はクラスタ内のコンテナ間の連携を自動化するだけでなく、クラスタ外との接続点であるネットワークロードバランサの設定も自動化できます。

本記事では Kubernetes をサービスに活用し Kubernetes の価値を最大限利用する方法を IIJ IoT サービスの今年リリースされたデバイスリンク機能を例にご紹介します。

IoT さーびす？でばいすりんく？

まず IIJ IoT サービスとは、エンタープライズ向けの IoT プラットフォームです。インターネットから隔離されたプライベートなネットワーク上に LTE などを利用し IoT デバイスを配置することで外部の脅威からデバイスを守るとともに、IoT の実現に必要な様々なプラットフォーム機能を提供しています。

• https://www.iij.ad.jp/biz/iot/

セキュアな反面、ここで１つの不便が発生します。

プライベートネットワーク上に配置したデバイスに対して、ファームウェアアップデートなどのメンテナンスをしようとしても、その手段がありません。デバイスが物理的に近くにあればデバイスに線を繋ぎ、メンテナンスができます。では、デバイスが近くにない場合はどうでしょう？５分で終わるような作業の為に何時間もかけて現地に行くのはあまり現実的ではないですよね😅

この不便を解決するために IIJ IoT サービスにはデバイスコントロールという機能があります。Web 上のコントロールパネルから単発のコマンドを送信したり、HTTP のリクエストを送信したりするリモートメンテナンス用の機能です。しかし、リモートメンテナンスと聞いて皆さんが思い浮かべるのは SSH でデバイスに入り、コマンドを実行したり、ログファイルの中を眺めたりすることだと思います。手元のターミナルから踏み台などを意識せずに SSH コマンドで遠方のデバイスの中に直接入って作業できた方が便利ですよね？その願いを実現するのがデバイスリンクです。

デバイスリンクではインターネットからデバイスまでを繋ぐ TCP プロキシをオンデマンドに作成し、手元から直接デバイスへの接続を可能とする機能です。

大事なのは「オンデマンド」ということです。単純にインターネットからデバイスに対する恒久的な踏み台やプロキシを作成した場合、プライベートネットワーク上に配置した意味がありません。必要な時だけ作成し、不要になったら削除することで、セキュリティの安全性を保ちつつ利便性も向上させることができます。そしてこの「オンデマンド」の部分に Kubernetes が深く関わっています。

河岸を変えよう（本題に入ります）

善は急げ、私の好きな言葉です。早速、本題に入りましょう。Kubernetes を活用し、どうやってインターネットからデバイスまでのプロキシを動的に作ったり消したりしているのかご紹介します。

こちらがその全容です。

IIJ IoT サービスは社内で運用されている Kubernetes クラスタ（IKE）上に構築されています。マニフェストを通して、クラウド環境のように何でも動的に作ったり消したりできるのは Kubernetes の強みの一つです。順を追って説明します。

• IKE については こちら をご覧ください。

まずは、ユーザがコントロールパネルや Web API 経由でデバイスリンクの設定を作成し、有効化すると Kubernetes 上にマニフェストを投入します（1）。このマニフェストは Kubernetes 標準のマニフェストではなく CRD（Custom Resource Definition） によって定義された独自マニフェストです。この独自マニフェストが投入されるとカスタムコントローラが Kubernetes の Service と Deployment を作成します。

CRD 及びカスタムコントローラとは、Kubernetes を拡張できる機能の一つです。CRD は独自に定義したマニフェストを Kubernetes に覚えさせることができる機能であり、そのマニフェストを読んで何か処理をするのがカスタムコントローラです。Kubernetes はマニフェストの種類（API リソース）ごとにコントローラが存在します。Service であれば kube-proxy 、Pod であれば kubelet や kube-scheduler etc. このようなコントローラが協調することで Kubernetes が成り立っています。すなわち CRD 及びカスタムコントローラとは、Kubernetes ファミリーに新たな役割とその担当者を追加することです。これにより Kubernetes を自由に拡張できます。また Kubernetes という規格の上に乗るため、仕様が統一できることや高負荷に陥りがちな API サーバを持たずにシステムが構築できる点がメリットとして挙げられます。

• https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
• https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/

説明に戻ります。Service と Deployment によって、インターネットからの接続点（エンドポイント）となるロードバランサ（LB）の設定とプロキシ機能を持った Pod が出来上がります（2）。これでユーザは作成されたエンドポイントにアクセスするだけでデバイスまで到達できます（3）。なんということでしょう。匠（Kubernetes）の手によってあたかもデバイスが目の前にあるかのようです。TCP プロキシなので SSH だけでなく VNC やリモートデスクトップなどなど、お好きな方法でデバイスまでアクセスできます。また、デバイスリンクにはソースアドレスによる ACL も備わっており、第三者がアクセスできないようになっています（4）。

そして使い終わったら、コントロールパネルや Web API からデバイスリンクの設定を無効化すると、マニフェストが更新されカスタムコントローラによって Service と Pod が削除されます。デバイスリンクには有効期限の概念があり、設定した時間を過ぎても、自動で Service と Pod が削除されるので無効化し忘れても安心です。以上の設定は全て Kubernetes の上で統一的に管理されているので、複雑な仕組みはありません。管理すべき実体は最初に作った独自マニフェストただ一つになり、システム全体がシンプルになります。

おわりに

いかがでしたでしょうか？

Kubernetes を活用することでクラウド環境でしか出来なかった（出来るけど面倒な）ことが簡単に出来るようになります。IIJ IoT サービスでは今後も Kubernetes のメリットを活かした機能を開発していく予定です。またこの場で紹介できることを願っています。乞うご期待！！！