3 Kubernetesパターンによるクラウドネイティブアプリケーション

現代のクラウドネイティブアプリケーションは、スケーラブルで弾力性があり、信頼性が高く、予測可能であるように設計されています。これらの特性を達成するために、特定の原則がKubernetesでアプリケーションを実行する際の管理者やアーキテクトを指導するのに役立ちます。

この記事では、Kubernetes上でクラウドネイティブアプリケーションを実行する際に考慮すべき3つの重要なパターンについて説明します。この投稿の終わりには、K8sクラスター内で実行されるコンテナ化されたアプリケーションを設計する際に探すべきものについて良い理解が得られるはずです。

基盤パターン

基盤パターンは、Kubernetesクラスターでコンテナベースのアプリケーションを実行するための基本であり、クラウドネイティブと見なされるためのものです。

基盤パターンで作業する際に注目すべき五つの領域があります：

• 予測可能な需要
• 宣言的デプロイ
• ヘルスプローブ
• 管理されたライフサイクル
• 自動配置

これらの概念は、このパターンでKubernetes上でアプリケーションを実行するために理解する必要があるほとんどをカバーしています。

予測可能な需要

アプリケーションのリソースとランタイムの依存関係を理解することは、Kubernetes上でアプリケーションを実行するための鍵です。アプリケーションの需要を予測するために知っておくべきことは：

• ランタイムの依存関係（例：永続ボリュームまたはConfigMap）
• アプリケーションリソースプロファイルは、圧縮可能リソース（CPU）と圧縮不可能リソース（メモリ）の設定をカバーしています

宣言的デプロイ

アプリケーションのデプロイを自動化することは、Kubernetes上でクラウドネイティブアプリを実行するためのもう一つの重要な部分です。この原則は、ポッドとレプリカセットに対する宣言的な更新を提供するデプロイメントワークロードの使用によってのみ可能です。同様に、デプロイメントが正しく機能するためには、コンテナ化されたアプリケーションが良いクラウドネイティブ市民であることが期待されます。

デプロイメントの中心には、予測可能にポッドのセットを開始および停止する能力があります。これが期待通りに機能するためには、コンテナ自体が通常sigtermなどのライフサイクルイベントをリッスンし、尊重し、また、正常に起動したかどうかを示すヘルスチェックエンドポイントを提供する必要があります。

ヘルスプローブ

クラウドネイティブKubernetesアプリケーションは、観測可能でなければなりません。ヘルスプローブの概念は、実行中のアプリケーションがクラスターにその状態をどのように伝えるべきかに焦点を当てています。プロセスヘルスチェック、ライフネスプローブ、およびレディネスプローブの組み合わせを使用すると、アプリケーションが健康であるか、トラフィックを制御する方法をすぐに判断できます。

ライフネスプローブが失敗した場合、コンテナは完全に終了しますが、レディネスプローブの失敗の場合、コンテナはサービスから削除されます。

管理されたライフサイクル

K8sで実行されるコンテナベースのアプリケーションは、クラスターによって発生する特定のライフサイクルイベントに反応できる必要があります。sigtermやsigkill（30秒後に強制終了）、poststartおよびprestopフックのようなプロセスシグナルを利用する方法を理解することが重要です。

• Poststartフックは、コンテナが作成されるときに実行されるブロッキングコールです。ポッドの状態はpoststartフックが完了するまで保留され、poststartフックが失敗すると、コンテナプロセスが終了します。
• Prestopは、終了前にコンテナに送信されるブロッキングコールであり、クラスターによって発生するイベントに基づいてコンテナを優雅にシャットダウンするのに特に役立ちます。

自動配置

Kubernetesノード上でコンテナベースのアプリケーションがどのように分散されるかを理解することは、パフォーマンス、信頼性、および自動化の鍵です。スケジューラの仕事は、APIサーバーから新たに作成されたポッド定義を取得し、ノードに割り当てることです。しかし、それは単純なことではなく、ノードの容量がコンテナリソースプロファイルに基づいてポッド配置を許可することを確認する必要があります。

自動配置に関して考慮すべきことは：

• 利用可能なノードリソース
• コンテナリソースの需要
• 配置ポリシー
• ノードアフィニティ、ポッドアフィニティ、およびアンチアフィニティ
• 汚染と耐性

行動パターン

行動パターンの概念は、ポッド管理のプリミティブとその動作に焦点を当てています。ユースケースに応じて、クラスター内のポッドでアプリケーションをどのように実行するかを知ることが非常に重要です。

たとえば、アプリケーションをベアポッドで実行するか、クラスター内のすべてのノードで単一のポッドを実行するデーモンセットとして実行できます。

行動パターンで取り上げられる概念は：

• バッチジョブ
• 定期ジョブ
• デーモンサービス
• ステートフルサービス
• 自己認識

バッチジョブ

これは、短命のポッドを信頼性高く完了するまで実行するために使用されます。長時間実行されるポッドを望まない場合、単に完了するタスクを実行し、ポッドを終了させたい場合に特に便利です。他のポッドプリミティブとは異なり、バッチジョブは完了した後にポッドを再起動しません。

定期ジョブ

これは、イベントによってトリガーされるか、特定の時間にトリガーされる作業単位を実行するために使用されます。定期的なジョブは、cronjobプリミティブを使用してデプロイされ、cronjobをUnixのcrontabの1行のように考えることができます。KubernetesのcronjobとUnixのcronの違いは、Kubernetesのcronjobが高可用で、時間ベースとイベントベースの実行の両方を許可することです。このアプローチは、アプリケーションがファイル転送や他のサービスのポーリングなどの特定のタスクを実行する必要があるときに便利です。

デーモンサービス

一般に、デーモンは相互作用なしにプロセスとして実行されるプログラムです。Kubernetesは分散システムであり、それ上で実行されるアプリケーションも本質的に分散しているため、デーモンセットは、クラスター内での洞察を提供したり、実行中のアプリケーションに関する情報を提供したりするために使用できます。たとえば、すべてのノードでfluentdデーモンセットを実行してクラスターのログを収集します。

ステートフルサービス

この概念は、ステートレスでないアプリケーションに適用されます。典型的な12ファクターアプリケーションでは、アプリケーションは終了し、問題が発生した場合に再起動されることが期待されますが、ステートフルアプリケーションはその逆です。これは、状態を保存する必要があるアプリケーションに主に適用されます。ステートフルセットワークロードを使用することで、永続的なアイデンティティ、ネットワーキング、ストレージ、および順序性を制御でき、アプリケーションのスケールアップおよびスケールダウンに影響を与えます。

自己認識

Kubernetesで実行されるアプリケーションが自分自身についての特定の情報を知る必要がある場合があります。これが自己認識の概念が解決するもので、ダウンワードAPIを使用します。これは、Kubernetesで実行されるアプリケーションに対して簡単な方法で自己調査およびメタデータの注入を提供します。ダウンワードAPIは、ポッドに関するメタデータをコンテナやクラスターに環境変数（例：POD_IP）やファイルを介して渡すことを許可します。

アプリケーションが自分の周囲を意識する能力は、Kubernetesが本質的に分散していることを考えると強力です。

構造的パターン

このパターンは、Kubernetes上で分散クラウドネイティブアプリケーションを実行する際に理解すべき最も重要なパターンの一つです。構造的パターンの主な目的は、異なるユースケースを解決するためにポッド内のコンテナをどのように整理するかを理解することです。

このパターンの核心は、単一責任モデルに基づいており、コンテナは一つのタスクのみを実行すべきです。もし一つ以上のタスクを実行する必要がある場合は、第二のコンテナがその二つ目のタスクを実行するべきです。

このパターンを実装するためには、ユースケースに応じて注目すべき四つの領域があります：

• Initコンテナ
• サイドカー
• アダプター
• アンバサダー

Initコンテナ

初期化に関連するタスクをアプリケーションの起動から分離することがInitコンテナの主な焦点です。たとえば、アプリケーションを開始する前にデータベーススキーマのセットアップを実行する能力です。

この概念は、単一のポッド内で二つのセットのコンテナ（Initコンテナとアプリケーションコンテナ）を実行することを可能にします。唯一の違いは、アプリケーションコンテナが並行して実行され、Initコンテナが順次実行されることです。この利点は、アプリケーションが起動する前に初期化が成功裏に完了したことを確認できることです。

Initコンテナには、レディネスチェックがないことも重要です。

サイドカー

Initコンテナがアプリケーションコンテナの起動時にのみ初期化を行うのに対し、サイドカーコンテナは、既存のコンテナの機能を変更せずに拡張することを可能にします。このパターンは、Kubernetesのような分散システムで、単一目的のコンテナが密接に協力することを許可します。

この概念の例は、httpサーバーと別のコンテナがファイルを取得するポッドです。httpコンテナが提供しているファイルをs3、ストレージバケット、またはgitから引き下ろします。httpコンテナの動作は、他のコンテナによって強化されます。

アダプター

これは、上記のサイドカーのバリエーションであり、アプリケーションポッド内で実行されるすべてのコンテナを統一された方法で露出させる必要がある場合に使用されます。

たとえば、アプリケーションとして連携する二つのコンテナと、最後のコンテナ、アダプターがあり、二つのアプリケーションコンテナのログを第三者ツールが消費できるように統一された方法で解析およびフォーマットします。主要なコンテナは二つの異なる言語で記述されることがありますが、そのログは他のツールが理解できる同じ方法で提示されます。

アンバサダー

これは、サイドカーの概念の別のバリエーションです。ポッド内で実行されているコンテナ化されたアプリケーションが、ポッドの外にある外部サービスと通信する必要がある場合があります。これがアンバサダーの概念が登場するところです。これはプロキシとして機能し、主なアプリケーションコンテナが外部サービスに直接接続する責任を取り除きます。

たとえば、アプリケーションが外部データストアやキャッシュをクエリしなければならない状況です。この場合、リクエストは主なアプリケーションコンテナに届き、その後、アンバサダーコンテナがリクエストを外部ソースに転送します。

有用なKubernetesパターン

上記で述べたパターンと考慮事項は、Kubernetesで分散クラウドネイティブアプリケーションを設計および実行する際に、スケーラビリティ、弾力性、信頼性、予測可能性を達成するために考慮すべき良いパターンです。

追加リソース

Kubernetesに関する詳細は、これらのリソースを探索してください：

• Kubernetesガイド、20以上の記事とチュートリアル
• BMC DevOpsブログ
• サーバーレスパーティにKubernetesを持ち込む
• eBayがKubernetesとリプラットフォームプログラムでITを再発明する方法

Kubernetesガイド

1. Kubernetes (K8s)とは？Kubernetes基本チュートリアル
2. Kubernetesのベストプラクティスによるクラスタの効率向上
3. ベストプラクティス：Kubernetes用にアプリケーションを設計する方法
4. Kubernetes Pods：イントロダクション
5. Kubernetes ReplicaSets：簡単な紹介
6. Kubernetes Deploymentsの完全な説明
7. Kubernetes DaemonSetsの使用と管理
8. Kubernetesサービスの仕組み
9. Kubernetes Port、TargetPort、NodePortの使用
10. KubernetesでのConfigMapの作成と使用
11. Kubernetes Secretsの紹介
12. Kubernetesネットワーキングの基本
13. Kubernetes Ingressの説明
14. Kubernetes Helm Chartsの紹介
15. Kubernetes Operatorパターンとは？
16. KubernetesでのStatefulSetとしてのPostgreSQLのデプロイ
17. Kubernetesカスタムリソース定義（CRDs）の説明
18. 3 Kubernetesパターンによるクラウドネイティブアプリケーション
19. Kubernetesコンピュートリソースの説明
20. DevOpsパイプラインのためのKubernetesセキュリティ
21. KubernetesとSpinnakerを使用した継続的デリバリー
22. Kubernetesマルチクラスター：使用方法と理由
23. Kubernetesモニタリング：包括的なガイド
24. Kubernetes vs Docker：簡単な比較
25. Kubernetes vs Docker Swarm：コンテナオーケストレーションツールの比較
26. Kubernetes vs OpenShift：違いは何ですか？
27. Kubernetes認定：どのようにして認定を取得するか

これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を表すものではありません。