Kubernetesの進化の方向と改善点：Kubernetesはどうなる？

コンテナオーケストレーションのデファクトスタンダードとなったKubernetesは次にどのように進化するのか。進化とともに改善すべき点とは何か。

[David Gonzalez，Computer Weekly]

　急速に進化している「Kubernetes」は、次にどのような変化を見せるのだろうか。

サーバレスへと向かうKubernetes

　Kubernetesが向かう先には幾つかの根本的な変化がある。その一つはサーバレスへと向かう動きだ。この動きは既にAmazon Web Services（AWS）の「AWS Fargate」で起きている。AWS Fargateは「Amazon Elastic Container Service」「Amazon Elastic Kubernetes Service」と連携して機能するコンテナ向けサーバレスエンジンだ。現時点ではマシン数とそのサイズを開発者が指定する必要がある。こうした事前指定は間もなく不要になる。Kubernetesが必要なリソースを把握し、必要なタイミングでリソースをネゴシエートするようになるだろう。

関連記事

• いまさら聞けないコンテナ＆マイクロサービス
• GoogleのDocker管理ツール「Kubernetes」基礎の基礎
• Kubernetesによるコンテナストレージの管理
• DockerとKubernetesのさらに先へ拡大するコンテナエコシステム
• Kubernetesベースのディープラーニング環境「Nauta」

　その次のステップは負荷分散だ。開発者の制御が及ばないハードウェアで実行される負荷をKubernetesが管理するようになるだろう。こうしたこと全てによって、企業がクラウドを使う方法が根本的に変わる。これがさらに進むと、顧客がアプリケーションを起動するとAWSがハードウェアを自動的に適応させる。顧客はインフラについて考える必要がなくなる。Kubernetesでデプロイすると、運用効率と開発者のエクスペリエンスが大幅に向上することがサーバレスの主なメリットになる。

変更しなければならないKubernetesのセキュリティ

　セキュリティは大きな問題の一つだ。オンプレミスを中心に考えてきた顧客はセキュリティが厳密に管理されることを望んでいる。だが同等のセキュリティはコンテナでは実現できない。こうした昔ながらの考えを持つ顧客には異なるアプローチが必要だ。そうした顧客が慣れているセキュリティはKubernetesに組み込まれていない。

　セキュリティの管理をクラウドネイティブ環境の範囲から外すべきだと提案しているわけではない。クラウドネイティブの考え方とオンプレミスの考え方の中間を取る必要がある。つまり、イメージとプラクティスの検証済みのセットを用意する。これを利用して企業全体のセキュリティを標準化する。

　この標準化は社内で設計する次善のセキュリティプラクティスのセットだが、エンジニアリング部門の共感は得られないだろう。セキュリティエンジニアの多くはKubernetesを理解していない。コンテナ内で使うJavaのバージョンや既に備えができている脆弱（ぜいじゃく）性の数やその深刻度のようなものをKubernetesに適用するのがどれほど難しいかを理解していない。

コンプライアンス、しかも「as code」型のコンプライアンス

　これは予想というよりも夢だ。だが、これが実現するのを見てみたい。コンテナ化とKubernetesから業務上のメリットを引き出すには、企業独自のプロセスを変える必要がある。開発者はKubernetesを利用することで、リアルタイムの運用と継続的デリバリー（CD）のサポートが可能になる。だが変更諮問委員会を擁する銀行のような組織のプロセスはCDには向いていない。

　理想は、自動化された変更諮問委員会、つまりCompliance As Codeの実現だ。エンジニアがコードを作成しているときに、それがコンプライアンスに従っているかどうかやセキュリティが確保されているかどうかを確認する。こうした確認をリリースの数日前の土壇場で行うのではない。つまりセキュリティをプロセスの前半に移す。それが時間を短縮し、問題を減らすことにつながる。最終段階での緊張の多いチェックは毎日の定型業務になる恐れがあるためだ。

　現実の問題は、この種の変化を企業が受け入れるかどうかだ。多くの企業はこの種の変化に消極的だ。外部の専門家を招き、こうした変化を促すことが非常に重要になる。外部の専門家は変化の方向へと企業を導き、課題に対処するための全く新たな方法を企業が思い描くのを支援できる。

　オンラインバンキングサービスを例に取ると、銀行の取引明細書が画面に表示されるレイアウトさえ、預金通帳をハードコピーしたデジタル版にすぎないのは明らかだ。銀行がデジタル化を試みたとき銀行が最初にしたことは、銀行自体が既に知っていることをデジタル化することだった。その後、Revolutのような真のディスラプターが登場し、顧客にほとんど費用を負担させることなくユーザーインタフェースだけでなくオンラインバンキングの可能性についての全体的なエクスペリエンスの考え方を変えた。

　実際、これが企業ITに広がっている病である「コンウェイの法則」だ。つまり現在の通信チャネルを新たに考案するのではなく、そのチャネルを模倣するようにITシステムをモデル化している。

相互の糧となるKubernetesとデジタル変革

　変革を望む企業は、Kubernetesのような最新のツールで社内機能を構築することから始める。同時に自社が抱えるより大きな課題について社外専門家の協力を仰ぐ。デジタル変革プログラムを実施しているなら、デリバリーパイプラインを標準化する絶好の機会だ。「ベストプラクティス」としていることは本当のベストプラクティスなのか、それは認定を受けた国際的な専門家が設定したものか、それは「自社でしか機能しない」恣意（しい）的な規則を設定したものではないのかを確認する。セキュリティ制御に合格してもおらず、どのような標準にも準拠していない航空機を想像できるだろうか。そんなものはないだろう。だが、航空機が使うソフトウェアはこのような問題に苦しんでいるかもしれない。

　Kubernetesは単なるツールであることを忘れてはならない。企業がプロセスを変えなければツールは正しく機能しない。

標準化と承認印

　最後に指摘しておきたい点は、Kubernetesにもかなりの標準化が必要な点だ。機能の重複がKubernetesエコシステムをいら立たせ、問題になり始めている。多くのサードパーティーコンポーネントが同じ機能を実行するとしたら、企業は自社のニーズに最適なコンポーネントをどのように判断できるだろう。コンセンサスや公式の評価プロセスがなければ開発者は推測するしかなく、誤った推測を行いかねない。Kubernetesの標準化はまだ行われていない。だがコミュニティーにとっては標準化が真のメリットになる。

　企業がある種の承認印を押すことを期待している。Kubernetesのコンポーネントが目的に適しており、最低限のパフォーマンスと機能を実現することを認める承認印だ。これはオープンソースコミュニティーにとって大きなメリットになる。同じことがJavaに起きた。現在ではApache Software FoundationのソフトウェアかSpring Frameworkに価値があり、高品質だという評価が高い。標準化と品質マークは成熟のサインだ。Kubernetesもこの方向に進む必要があり、この方向に進む価値がある。

デビッド・ゴンザレス氏はNearFormでDevOpsのデリバリーアーキテクトを務めている。同氏はKubernetesにおけるGoogle Developer Expertで、JavaScript、マイクロサービス、DevOpsに関する書籍を3冊執筆している。CCT College Dublinで「Cloud and Distributed Systems」の非常勤講師も務めている。同氏の使命は企業のITプロセスと文化を変革し、技術を企業の負担ではなく成功要因にすることだ。