KubeConにおけるアプリケーション管理の重要なポイント

**Alibaba Cloud** Container Platformの専門家であり、k8s Operatorプロジェクトの執筆者でもあるDeng Hongchao氏が、アプリケーション管理の重要な側面について分析しています。

*本ブログは英語版からの翻訳です。オリジナルは[こちら](https://www.alibabacloud.com/blog/new-highlights-of-application-management-at-kubecon-eu-2019_595082)からご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。*

コンテナサービスチーム著

ご存知のように、クラウドネイティブアーキテクチャの中心的なプロジェクトは、アプリケーションに焦点を当てたKubernetesです。より良いアプリケーションの展開とより効率的な開発は、チームや組織に目に見える利益をもたらし、クラウドネイティブ技術をより良く活用することができます。革命の勢いは、古い閉鎖的な社内システムを変化させるだけでなく、開発者のための新しいツールの出現を促進します。今回のKubeConでは、アプリケーション管理に関する新たな知見が数多く発表されましたが、その中で、私たちはどのようなアイデアや考え方を学ぶことができるのでしょうか。また、これらのアイデアは、どのような技術進化の傾向を示しているのでしょうか。


#設定変更とグレースケールのアップグレード
Kubernetes上にデプロイされたアプリケーションは、一般的にConfigMapに設定を保存し、それをPodのファイルシステムにマウントします。ConfigMapが変更されると、Podにマウントされたファイルのみが自動的に更新されます。この方法は、ホットアップデートを自動的に実行するアプリケーション(nginxなど)には問題ありません。しかし、ほとんどのアプリケーション開発者は、設定が変更され、ConfigMapに関連付けられたコンテナのグレースケールアップグレードが行われた後に、段階的なリリースを実行したいと考えています。

グレースケールアップグレードは、不変のインフラストラクチャの考え方を反映しつつ、ユーザーコードを簡素化し、セキュリティと安定性を向上させます。アプリケーションがデプロイされると、変更は行われません。アプリケーションをアップグレードする必要がある場合、開発者は新しいバージョンをデプロイし、新しいバージョンを検証し、古いバージョンを破棄するだけで済みます。検証に失敗しても、古いバージョンにロールバックするのも便利で簡単です。この考えに基づき、Pusherのエンジニアは、デプロイメントに関連付けられたConfigMap/Secretを自動的にリッスンし、設定が変更されたときにデプロイメントのアップグレードをトリガーするツール、Waveを開発しました。Waveのユニークな機能の1つは、Deployment PodTemplate内のConfigMap/Secretを自動的に検索し、保存されているすべてのデータのハッシュを計算し、計算されたハッシュをPodTemplate上のアノテーションとして保存することです。Waveはハッシュを再計算してPodTemplateのアノテーションを更新し、ハッシュが変更されるたびにDeploymentの更新をトリガーにします。偶然にも、オープンソースコミュニティは、同様の機能を持つ別の類似ツールであるReloaderも提供しています。さらに、Reloaderでは、どのConfigMaps/Secretsを監視するかを選択することができます。

###分析とコメント
グレースケールアップグレードを使用しないと、潜在的な問題を責められる可能性があります。アプリケーションイメージのアップグレードにしても、構成の変更にしても、新たな段階的なリリースと検証を忘れないようにしましょう。

さらに、不変のインフラストラクチャは、クラウドコンピューティングアプリケーションの構築に新たなトレンドをもたらします。この開発トレンドは、アーキテクチャをより安全で信頼性の高いものにするだけでなく、一般的なツールとの組み合わせも可能にし、クラウドネイティブコミュニティの利点をフルに活用し、従来のアプリケーションサービスを凌駕しています。例を挙げてみましょう。前述のWaveプロジェクトとIstioのルーティング機能を組み合わせることで、少ないトラフィック量でWebサイトの構成検証を実装することができます。

#サーバーサイド適用
Kubernetesは宣言型のリソース管理システムです。ユーザーはローカルで期待されるステータスを定義し、「kubectl apply」を使って、現在のクラスタのステータスで指定された部分を更新します。

本来のkubectl applyはクライアントをベースに実装されています。applyの場合、コントローラやアドミッション、ウェブフックなどのリソースを他の人も変更する可能性があるため、単純に1つのリソースの全体的な状態を置き換えることはできません。では、自分のリソースへの変更が他の人の変更を上書きしないようにするにはどうすればいいのでしょうか？これを実現するには、3-way merge を使用します。最後に適用された状態をPodアノテーションに格納し、次の適用操作の間に最新の状態、最後に適用された状態、指定された状態に基づいて3-way diff を行い、生成されたパッチをAPIServerに送信します。

しかし、このアプローチにはまだ問題があります。「適用」の本来の目的は、個人がどのリソースフィールドを管理するかを指定できるようにすることです。しかし、オリジナルの実装では、異なる個人がフィールドを改ざんすることを防ぐことも、競合が発生したときにユーザーに通知して競合を解決することもできません。例えば、私がCoreOSで仕事をしていた頃は、組み込みコントローラとユーザの両方がノードオブジェクトの一部の特殊なラベルを変更することがあり、クラスタの障害を修正するために手動での努力が必要になりました。

今日、私たちはついに解決策として、サーバ側での適用を実現しました。APIServer は diff と merge 操作を実行し、以前の問題の多くを解決します。さらに重要なことは、以前に使用されていた最後に適用されたアノテーションと比較して、サーバー側適用では、誰がどのリソースフィールドを管理するかを指定するために、ManagedFieldsと呼ばれる新しい宣言的なAPIが提供されます。競合が発生した場合、例えば kubectl とコントローラの両方が同じフィールドを変更した場合、管理者以外のリクエストに対してエラーが返され、問題を解決するためのプロンプトが提供されます。

###分析とコメント
もう kubectl の適用について心配する必要はありません。サーバーサイド適用がクライアントサイド適用に取って代わるのは時間の問題です。このように、異なるコンポーネントが同時に同じソースを変更する方が、より安全で信頼性の高いものになります。

また、システムの開発、特に宣言型APIの普及に伴い、ローカルロジックが減り、サーバーサイドロジックが増えていくでしょう。サーバーサイドロジックには多くの利点があります。kubectl のドライランや diff のような多くの操作は、サーバサイドでより簡単に実行できます。HTTP エンドポイントが提供されているので、他のツールへの "apply" 機能の組み込みが容易になります。複雑なロジックをサーバサイドで実装して公開することで、管理や制御が容易になり、安全で一貫性のある高品質なサービスを利用できるようになります。

#GitOps
今回のカンファレンスでは、シンポジウムチームもGitOpsのメリットを語りました。

1、GitOpsはチーム全体をより「民主的」にし、何でも書き込んで記録し、いつでもレビューできます。どんな変更もリリースするにはプルリクエストが必要です。それぞれの変更点を明確に見ることができ、レビューに参加し、コメントを提供することができます。変更や議論はすべてGitHubのようなツールに記録されます。変更や議論の履歴はいつでも見ることができます。これらの機能により、チームのコラボレーションがよりスムーズになり、よりプロフェッショナルなものになります。
2、GitOpsはリリースをより安全で安定したものにします。コードを自由に公開することはできなくなりました。その代わり、コードを公開するには、対応する担当者によるレビューが必要です。ロールバックが必要な場合は、古いバージョンがGitで利用できるようになります。履歴により、誰がどのタイミングでどのコードを公開したのかという情報が得られます。これにより、リリースプロセスがより専門的になり、リリース結果がより安定して信頼性の高いものになります。

###分析とコメント
GitOpsは単なる技術的なソリューションではありません。もっと重要なのは、GitHubのようなツールのバージョン、履歴、監査、パーミッションの機能を利用して、チームのコラボレーションやリリースをより専門的で標準的なものにすることです。

GitOpsが広く適用されれば、業界全体に大きな影響を与えるだろう。例えば、どの企業に採用された新人開発者でも、すぐにコードを公開し始めることができます。

GitOpsの「コードとしての構成」や「真実の源としてのGit」の考え方から学び、実践に応用していく価値はあると思います。

#自動のカナリアロールアウト
カナリアロールアウトとは、リリースプロセス中にトラフィックのごく一部を新しいバージョンにインポートし、「go live」の動作が正常かどうかを分析して検証することを指します。すべてが正常であれば、古いバージョンにトラフィックがなくなり破棄されるまで、トラフィックはさらに新しいバージョンに切り替えられます。Spinnakerのようなツールでは、手動での検証をパスする必要があることがわかっています。このプロセスを自動化されたツールを使用することで置き換えることができます。結局、成功率やp99のレイテンシをチェックするなど、機械的にチェック処理を行うことになります。

前述のアイデアをもとに、アマデウスとDatadogのエンジニアが、Kubernetes、Operator、Istio、Prometheusなどのツールを使ってカナリアのロールアウトを行う方法を共有しました。主な手順は、カナリアロールアウト全体をCRDに抽象化し、宣言型YAMLファイルを記述するというものです。作成されたYAMLファイルを受け取ると、Operatorは複雑なO&Mオペレーションを自動的に完了させます。主な手順は以下の通りです。


- サービスの新しいバージョンをデプロイします。
- Istio VirtualServiceの設定を変更し、トラフィックの一部を最初に新バージョンに切り替えます。
- 新バージョンのサービスの成功率と p99 応答時間が要件を満たしているかどうかを確認します。
- 要件を満たしている場合は、アプリケーション全体を新バージョンにアップグレードし、そうでない場合は旧バージョンにロールバックします。

Weaveはまた、自動化されたカナリアロールアウトツールであるFlaggerも開発しました。しかし、Flaggerは、トラフィックの一部を新バージョンに段階的に切り替えることができ、例えば、毎回トラフィックの5%を新バージョンに切り替え、すべてのトラフィックが新バージョンに切り替えられたときに、直接旧バージョンを壊すことができます。


###分析とコメント
カナリアロールアウトで多くの恩恵を受けることができます。カナリアロールアウトは、アプリケーション公開の成功率とシステムの安定性を向上させるのに役立ちます。カナリアロールアウトは、アプリケーション管理の重要な部分です。

また、クラウドネイティブ時代の複雑なO&Mの手順が簡素化され、標準化されます。CRDの抽象化は、これらの複雑な手順をいくつかの短いAPIに変換し、ユーザーに提供します。自動化されたO&MにOperatorを使用する場合、前述のような機能をKubernetes上に実装することができます。2つのトップレベルの標準プラットフォームであるIstioとKubernetesは、ユーザーが簡単に始められるように強力な基本機能を提供します。


#結論
この記事では、アプリケーション管理の新しいアプローチをいくつか取り上げ、それぞれのアプローチの詳細な解説をしてきました。また、設定ファイルが変更されたときに新しいアプリケーションのバージョンを公開する理由と方法についても触れました。クライアント側でkubectl applyを実行すると、リソースフィールドの改ざんを許してしまうなど、多くの問題が発生する可能性があります。これらの問題は、サーバーサイドで適用することで解決できます。
GitOpsは技術的な問題を解決するだけでなく、チームのコラボレーションやリリースをより専門的で標準的なものにします。Kubernetes、Operator、Istio、Prometheusなどのトップレベルの標準プラットフォームは、カナリアロールアウトのためのO&Mオペレーションを簡素化し、開発者の敷居を下げることができます。

かつては、他人が開発したアーキテクチャは優れているが、自分たちには利用できないということで、常にうらやましがられていました。今では、オープンソースプロジェクトや技術標準化により、すべての開発者がこれらの技術を利用できるように技術的な敷居が低くなっています。さらに、微妙な変化も起きています。セルフビルドの基本ソフトウェアは、より多くの企業（例えばTwitterなど）がクラウドネイティブのコミュニティに参加するようになってきています。オープンソースのエコシステムと技術標準を受け入れることは、インターネット企業にとって重要な機会であり、課題でもあります。クラウド移行の準備を万全にするためには、クラウドネイティブなアプリケーションとアーキテクチャを構築し、クラウドとオープンソース技術の力を活用する必要があります。

*アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
[アリババクラウドジャパン公式ページ](https://www.alibabacloud.com/ja)*