ベストプラクティス：Kubernetes向けのアプリケーションを設計する方法

ポイント: Kubernetes上でアプリケーションを設計するためのベストプラクティスには、アプリをコンテナ化し、Helmを使用してデプロイし、ライフネスプローブとレディネスプローブを使用してヘルスチェックを実装することが含まれます。12ファクターアプリケーションメソドロジーに従うことで、クラウドネイティブの互換性が向上し、Kubernetesオペレーターを活用することで管理タスクが自動化されます。

アプリケーションはコンテナイメージとしてパッケージ化する必要があります。
アプリケーションを効果的にデプロイするためにHelmを利用します。
アプリケーションのヘルスチェックのためにライフネスプローブとレディネスプローブを実装します。

Kubernetes向けの本番環境に適したアプリケーションを設計することは簡単ではありませんが、アプリケーションが本番環境に必要なすべての要件を満たすためのガイドラインやベストプラクティスが利用可能です。

マイクロサービスパターンは、アプリケーションの構築方法の進化に役立ちました。この変化のため、アプリケーションを実行できるプラットフォームは開発中に考慮する必要があります。実際、Kubernetes自体は非常に人気のあるコンテナオーケストレーションプラットフォームであり、アプリケーションの構築とデプロイの方法を根本的に変えました。したがって、アプリケーションをKubernetes上で実行する前に考慮すべきいくつかのヒントを以下に示します。

アプリケーションはコンテナイメージでなければなりません

K8sはコンテナオーケストレーションエンジンであるため、アプリケーションはK8sクラスターで実行されるためにコンテナイメージにパッケージ化される必要があります。これはマイクロサービスを構築するための最も基本的な要件の一つであり、Kubernetesがプラットフォームとして機能する方法に直接関係しています。

理想的には、アプリケーションイメージは安全なストレージのためにプライベートリポジトリに保管すべきです。たとえば、Dockerイメージを構築し、そのイメージをプライベートDockerリポジトリにプッシュし、Kubernetesがそのイメージをプルできるようにします。

デフォルトでは、Kubernetesは以下のコンテナランタイムをサポートしています：

使用するランタイムごとにベストプラクティスに従ってください。Dockerのためのものはこちらで見つけることができます。

Helmはあなたの友人

もしHelmチャートを使用したことがないなら、あなたは損をしています。HelmはKubernetesに本番グレードのアプリケーションをデプロイするためのデファクトスタンダードです。Helmを使うことで、アプリケーションをチャートで説明できるようになり、バージョン管理、公開、共有、その他の便利なことができるようになります。これは、簡単に言えばKubernetesのyumまたはapt-getです。

典型的なHelmチャートは以下のようなツリーになります：

    YOUR-CHART-NAME/
 |
 |- .helmignore        [Files to ignore]
 |
 |- Chart.yaml         [Data about the chart. E.g Version etc] 
 |
 |- values.yaml        [This is the variable file.] 
 |
 |- charts/            [Specify other needed charts]
 |
 |- templates/         [This hold all the manifests for the application. E.g yaml files]

注意：kubectlのようなCLIツールは、開発中またはデバッグ用にのみ使用されるべきであり、決して本番環境へのデプロイには使用しないでください。

ライフネスとレディネスプローブを使用する

不健康なアプリケーションは収益の損失を招く可能性があります。幸いなことに、Kubernetesはアプリケーションの健康（または失敗）をチェックするための2つの重要な概念を提供します：

ライフネスプローブ。これは、プローブが失敗した場合にアプリケーションが実行されているコンテナをkubeletに終了させるように指示します。
レディネスプローブ。これは、プローブが失敗した場合に、アプリケーションの前面にあるサービスロードバランサーがこのアプリケーションにトラフィックをルーティングしないようにkubeletに指示します。

マニフェストにライフネスプローブとレディネスプローブを使用することは、クラスター内でアプリケーションが起動する前後の健康状態を制御し、知るための優れた方法です。一度アプリケーションがプローブに合格すると、サービスはアプリケーションにトラフィックを送信します。

12ファクター、まだなら

アプリケーションをKubernetesクラスターにデプロイすることは素晴らしいことですが、アプリケーションがクラウドネイティブに構築されていない場合、Kubernetesとうまく連携できない可能性があります。良い指針は12ファクターアプリケーションメソドロジーに従うことです。

12ファクターに従うことのいくつかの利点：

スケーリングは簡単で、ツールやアーキテクチャに対する変更が限られています。
開発、ステージング、本番環境はできるだけ近接しており、構成ファイルにハードコーディングされた設定値がありません。
サービスがOSとのクリーンな契約を持っていることを確認します。（つまり、どのOSで実行されているかは関係ありません。）
サービスはパブリックまたはプライベートクラウドに簡単にデプロイできます。

オペレーターはあなたの専門知識を活用します

Kubernetesが非常に強力な理由の一つは？それは、それを拡張できるということです。言い換えれば、アプリケーションのドメイン知識を適用して、自分のカスタムコントローラーとカスタムリソースをKubernetesで作成することができ、アプリケーションがどのように機能するべきかを理解し、必要なときに特定のタスクを実行します。これがKubernetesのオペレーターパターンのためのものです。

K8s向けにアプリケーションを設計することの一部は、アプリケーションがどのような自動化を必要とするかを知るための計画を十分に行い、これらの自動化タスクにK8sオペレーターを活用できるかどうかを判断することです。オペレーターは、状態を持つアプリケーションに必要な場合、一時的な管理タスクを実行するために特に役立ちます。たとえば、アプリケーションの状態のバックアップと復元を行うことです。このシナリオでは、Kubernetesはこのタスクをデフォルトで実行する方法を知らないため、カスタムコントローラーとカスタムリソースを作成する必要があります。

Kubernetes向けにアプリケーションを設計することは簡単ではありませんが、これらのベストプラクティスに従うことで、K8sクラスターで実行される適切に設計されたアプリケーションを持つことができます。これらのアプリケーションのヒントから始めて、アーキテクチャプロセスを継続的に改善していきましょう。

追加リソース

Kubernetesに関する詳細は、以下のリソースをチェックしてください：

Kubernetesガイド、20以上のアーティクルとチュートリアルを提供
BMC DevOpsブログ
サーバーレスパーティにKubernetesを持ち込む

DevOpsガイド

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

ワークフローオーケストレーション

メインフレーム簡素化

人気の目的地

ベストプラクティス：Kubernetes向けのアプリケーションを設計する方法

アプリケーションはコンテナイメージでなければなりません

Helmはあなたの友人

ライフネスとレディネスプローブを使用する

12ファクター、まだなら

オペレーターはあなたの専門知識を活用します

追加リソース

DevOpsガイド

最新のメインフレーム開発ツールを試す

ITOps・DevOpsの関連記事

The Briefを購読する

ありがとう

ご要望またはご協力できることがございましたらお気軽にお問い合わせください

セールス & お見積り

ヘルプ & サポート

人気の目的地

ベストプラクティス：Kubernetes向けのアプリケーションを設計する方法

アプリケーションはコンテナイメージでなければなりません

Helmはあなたの友人

ライフネスとレディネスプローブを使用する

12ファクター、まだなら

オペレーターはあなたの専門知識を活用します

追加リソース

DevOpsガイド

ITOps・DevOpsの関連記事

The Briefを購読する

ありがとう