青山氏が語った、「クラウドネイティブ」がやがて「Kubernetesネイティブ」へ進む理由：仮想マシン時代とクラウドネイティブ時代の違い（2/2 ページ）

青山真也氏は2020年5月20日、Forkwell主催のオンラインミートアップで、仮想マシン時代の開発とKubernetesによるクラウドネイティブな開発のこれからについて話した。この講演を要約してお届けする。

[三木泉，＠IT]

Kubernetesで、アプリケーション実行のベストプラクティスをコード化

　従来のChefやAnsible、Terraformといった構築自動化ツールでも、コードによる自動化は行われてきた。こうしたツールでも宣言的な記述はできるものの、構築スクリプト的であり、インフラが焦点となるコードは複雑になりがちだ。

　一方Kubernetesのコード化は、アプリケーションをどう動かすかに焦点を当てており、安定的に動かすためのベストプラクティスを適用できる。

　例えば図のように、どのアプリケーションを動かすかを定義して、環境変数などで環境を切り分けられる設定が書ける。他にもヘルスチェックやリソースの割り当て、アプリケーション実行時のライフサイクルに関する設定などが、宣言的なコードとして記述できるようになっている。アプリケーション実行のためのコード化を行っていると言える。

　また、Kubernetesでは、コンテナ停止処理の作法などに従う必要がある。こうした作法に従っていくことで、アプリケーション開発のベストプラクティスのレールに、ある程度乗れるようになる。

Kubernetesによるインフラレイヤーの抽象化

　Kubernetesでは、インフラレイヤーを抽象化できるため、開発者でもインフラを使いやすくなる。

　仮想マシンの世界では、ロードバランサとの連携はスクリプトや手動管理で実施していた。IPアドレス管理も仮想マシンごとに把握、管理し、AnsibleやChefなどで構成管理を実行していた。

　Kubernetesでは、コンテナのIPアドレスは一切管理しない。ラベルが付与され、これを使って管理を行う。ロードバランサとの連携もラベルを使って指定し、コンテナやノードの追加時には、自動的にメンバーが更新される。

　Kubernetesでは、ロードバランサのIPアドレスもサービスの名前で解決する。内部の通信は、「サービスディスカバリ」を通じ、名前を使って自動設定する。グローバルIPアドレスについても自動的に払い出されたIPアドレスを、ExternalDNSを使うことで外部DNSに自動登録することで、意識しないようにすることも可能だ。さらにCert-Managerで、証明書の自動発行／更新を任せることもできる。

Kubernetesのコアコンセプトは、「あるべき状態に収束する仕組み」

　Kubernetesのコアコンセプトは、理想の状態を維持する仕組みにある。これは「Reconciliation Loop」と呼ばれている。

　Kubernetesでは、さまざまなControllerが動作している。これらのControllerは常時、現状を確認し、理想と現実の差分を計算し、差分に対する処理を実施するループ処理を実行する。これにより、何か問題が発生しても、自動修復が行われるようになっている。

　例えばReplicaSet Controllerは、指定されたレプリカ数でPodを維持し続ける役割を果たす。3つのレプリカが指定されているのに、2つしか起動していなければControllerが1つ作成することで、指定された状態に戻す処理を行う。

　Kubernetesでは「Controllerを使って、運用ロジックをコード化（プログラマブル化）できる」と表現できる。私がオーケストレーターとしてのKubernetesに未来を感じる部分はここにある。

Kubernetesによる運用自動化の対象は広がり続ける

　Kubernetesによる運用自動化は、従来の手法に比べてさまざまなメリットがある。またその対象は将来にわたって大きく広がっていくことになる。

一般的な運用自動化ロジック

　Kubernetesでは、属人化しがちなスクリプトを汎用的なControllerに変え、Kubernetesの拡張機能としてオープンソースのエコシステムで共有できる。これにより、点在していた知識を集約し、誰もが使えるような形に発展させられる。

　このような例としては、特定のリポジトリのマニフェストをKubernetesに適用するArgoCD、払い出されたロードバランサのIPアドレスをDNSに登録するExternalDNS、コンテナのリソースの使用率から自動的にリソース割り当てを変えるVerticalPodAutoscalerなどがある。

ステートフルなミドルウェアの運用

　「Operator」とも呼ばれる、ステートフルなミドルウェアを運用するControllerが生まれている。Message Queueやキーバリューストア（KVS）に関しては、これによる運用自動化が、近いうちに現実的なものになると思っている。

　ただし、データベースについては、安心して使えるようになるのがある程度先になるのではないかと考えている。Podのライフサイクルを考えると、現在主流なデータベースに適用するのは容易ではない。また、クラスタ間でのデータベース移行への対応は困難だ。

外部システムの制御・運用

　クラウド上でKubernetesを使う場合、Kubernetes内のリソースに関してはControllerの仕組みを使って一貫した自動化が図れる。だが、クラウド上の外部リソースを扱うには、現状ではTerraformなどを併用しなければならない。

　ところが、Terraformのようなツールは、既に述べたように構築ツール的であり、実行していないときに適切な状態かどうか判別できない。また、KubernetesとTerraformの両方を管理しなければならないということにもなる。データベースに対する認証情報などについても、何らかの方法でKubernetesに伝える必要がある。

　クラウド上の外部リソースを含めて、Kubernetesに運用を任せられればメリットは大きい。

　例えばGoogle Cloud Platform（GCP）では最近、「ConfigConnector」というものが登場している。ConfigConnectorでは、例えば「Database Resource」というメタ的なリソースを作ると、Kubernetes内のConfigConnector Controllerが、GCP上のデータベースを自動的に構築する。こうした動きが広がれば、パブリッククラウドの多様なリソースを、Kubernetesから統合的に運用できるようになる。

　それでも、DockerfileやTerraformを併用する必要性はまだ残っている。

　Dockerfileについては、Cloud Native Build Packの成熟によって不要になり、ソースコードだけで済む世界が来ると考えられる。また、Terraformに残される仕事は、IPアドレスの確保やクラスタの初期構築くらいだが、これも前述のExternalDNSやCert Managerの活用によってIPアドレスを考えずに済むようになり、クラスタ運用自体はマネージドサービスに任せられるようになってきているので、役割が減ってくると考えられる。

　これまで述べてきたような動きが今後進展することで、5年後、オンプレミス環境ではデータベース以外がKubernetesで稼働できる状態になり、パブリッククラウドではKubernetes上で全てが管理できる状態になると想定している。

　つまり、やがて全てが「Kubernetes-native」になることが考えられる。