Google によるコンテナ使用に関する 7 つのベスト プラクティス

ノート。 翻訳。: 元の記事の著者は、Google Cloud ソリューション アーキテクトの Théo Chamley です。 Google Cloud ブログへのこの投稿では、彼は自社のより詳細なガイドの概要を提供しています。コンテナの運用に関するベストプラクティス」 その中で、Google の専門家は、Google Kubernetes Engine の使用などのコンテキストでコンテナを運用するためのベスト プラクティスを収集し、セキュリティから監視、ロギングまで幅広いトピックに触れています。 では、Google によると、最も重要なコンテナの実践とは何でしょうか?

Kubernetesエンジン (コンテナ化されたアプリケーションを Google Cloud 上で実行するための Kubernetes ベースのサービス - 約。 翻訳) これは、スケーリングが必要なワークロードを実行するための最良の方法の XNUMX つです。 Kubernetes コンテナ化されている場合、ほとんどのアプリケーションがスムーズに機能することが保証されます。 ただし、アプリケーションを管理しやすくし、Kubernetes を最大限に活用したい場合は、ベスト プラクティスに従う必要があります。 これらにより、アプリケーションの操作、監視、デバッグが簡素化され、セキュリティも強化されます。

この記事では、Kubernetes 上でコンテナを効果的に実行するために知っておくべきことと実行すべきことのリストを説明します。 さらに詳しく知りたい方は資料をお読みください。 コンテナの運用に関するベストプラクティス、また私たちのことにも注目してください 以前の投稿 コンテナの組み立てについて。

1. ネイティブコンテナロギングメカニズムを使用する

アプリケーションが Kubernetes クラスター上で実行されている場合、ログはあまり必要ありません。 集中ログ システムは、使用しているクラスターにすでに組み込まれている可能性があります。 Kubernetes Engine を使用する場合、これが責任を負います Stackdriverのログ. (ノート。 翻訳。: また、独自の Kubernetes インストールを使用している場合は、オープンソース ソリューションを詳しく検討することをお勧めします。 ログハウス.) 生活をシンプルにして、ネイティブのコンテナ ロギング メカニズムを使用してください。 ログを stdout および stderr に書き込みます。ログは自動的に受信され、保存され、インデックスが作成されます。

必要に応じて、ログを次の場所に書き込むこともできます。 JSON形式。 このアプローチにより、メタデータを簡単に追加できるようになります。 また、Stackdriver Logging は、このメタデータを使用してログを検索できるようになります。

2. コンテナがステートレスで不変であることを確認する

Kubernetes クラスターでコンテナーが正しく機能するには、コンテナーがステートレスで不変である必要があります。 これらの条件が満たされると、Kubernetes はその仕事を実行し、必要なときに必要な場所でアプリケーション エンティティを作成および破棄できるようになります。

ステートレス これは、あらゆる状態 (あらゆる種類の永続データ) がコンテナの外部に保存されることを意味します。 このために、ニーズに応じて、さまざまなタイプの外部ストレージを使用できます。 Cloud Storage, 永続ディスク, Redisの, クラウドSQL または他の管理されたデータベース。 (ノート。 翻訳。: これについて詳しくは、記事「Operators for Kubernetes: ステートフル アプリケーションを実行する方法。「）

不変 これは、コンテナが存続期間中に変更されないことを意味します。更新、パッチ、構成の変更はありません。 アプリケーション コードを更新するか、パッチを適用する必要がある場合は、新しいイメージを作成してデプロイします。 コンテナ構成 (リスニング ポート、ランタイム環境オプションなど) を外部に移動することをお勧めします。 シークレット и ConfigMap。 新しいコンテナー イメージを構築することなく更新できます。 イメージアセンブリを使用してパイプラインを簡単に作成するには、次を使用できます。 クラウドビルド. (ノート。 翻訳。: これらの目的のためにオープンソース ツールを使用します ダップ.)

ポッドに構成としてマウントされた ConfigMap を使用して Kubernetes のデプロイメント構成を更新する例

3. 特権コンテナを避ける

サーバー上で root としてアプリケーションを実行することはありませんよね? 攻撃者がアプリケーションに侵入すると、root アクセス権が取得されます。 特権コンテナを実行しない場合にも同じ考慮事項が当てはまります。 ホスト上の設定を変更する必要がある場合は、コンテナーに固有の設定を与えることができます。 機能 オプションを使用して securityContext Kubernetesで。 変更する必要がある場合 sysctls、Kubernetes には 別の要約 このために。 一般に、最大限に活用するように努めてください。 初期化- およびサイドカー コンテナも同様の特権操作を実行します。 内部トラフィックまたは外部トラフィックのいずれかにアクセスできる必要はありません。

クラスターを管理する場合は、次を使用できます。 ポッドセキュリティポリシー 特権コンテナの使用制限について。

4. root として実行しないようにする

特権コンテナについてはすでに説明しましたが、これに加えて、コンテナ内でアプリケーションを root として実行しないとさらに良くなります。 攻撃者が、コードの実行を許可する root 権限を持つアプリケーションでリモートの脆弱性を見つけた場合、その後、まだ未知の脆弱性を通じてコン​​テナから離れることができ、ホスト上で root を取得します。

これを回避する最善の方法は、最初から root として何も実行しないことです。 これを行うには、ディレクティブを使用できます USER в Dockerfile または runAsUser Kubernetesで。 クラスター管理者は、次を使用して強制動作を構成することもできます。 ポッドセキュリティポリシー.

5. アプリケーションを監視しやすくする

ロギングと同様に、監視もアプリケーション管理の不可欠な部分です。 Kubernetes コミュニティで人気のある監視ソリューションは次のとおりです。 プロメテウス - 監視が必要なポッドとサービスを自動的に検出するシステム。 (ノート。 翻訳。: こちらもご覧ください 詳細レポート Prometheus と Kubernetes を使用した監視のトピックについて。) スタックドライバー Kubernetes クラスターを監視でき、アプリケーション監視用に独自のバージョンの Prometheus が含まれています。

Stackdriver の Kubernetes ダッシュボード

Prometheus は、アプリケーションがメトリクスを HTTP エンドポイントに転送することを期待します。 これで利用可能 Prometheus クライアント ライブラリ。 同じ形式は次のような他のツールでも使用されます。 国勢調査を開く и イスティオ.

6. アプリの健全性ステータスを利用可能にする

運用環境でのアプリケーション管理は、その状態をシステム全体に伝達する機能によって支援されます。 アプリケーションは実行されていますか? 大丈夫ですか？ トラフィックを受信する準備はできていますか? 彼の様子はどうですか？ この問題を解決する最も一般的な方法は、ヘルスチェックを実装することです。 （健康診断）。 Kubernetes には XNUMX つのタイプがあります。 liveness プローブと readiness プローブ.

liveness プローブの場合 （活力チェック） アプリケーションが機能し、基本的な依存関係が満たされている場合、アプリケーションには「200 OK」応答を返す HTTP エンドポイントが必要です。 Readiness Probe の場合 (サービス準備状況チェック) アプリケーションは、アプリケーションが正常な状態にあり、初期化手順が完了しており、有効なリクエストによってエラーが発生しない場合に、「200 OK」応答を返す別の HTTP エンドポイントを備えている必要があります。 Kubernetes は、これらのチェックに従ってアプリケーションの準備ができている場合にのみ、トラフィックをコンテナにルーティングします。 liveness 状態と readiness 状態に違いがない場合、XNUMX つのエンドポイントをマージできます。

これについて詳しくは、Google の開発者擁護者である Sandeep Dinesh 氏の関連記事をご覧ください。Kubernetes のベスト プラクティス: readiness プローブと liveness プローブを使用したヘルスチェックのセットアップ'。

7. イメージのバージョンを慎重に選択してください

ほとんどのパブリックおよびプライベート イメージでは、次で説明されているものと同様のタグ付けシステムが使用されています。 コンテナを構築するためのベスト プラクティス。 画像が次のシステムを使用している場合 セマンティックバージョニング、タグ付けの詳細を考慮する必要があります。 たとえば、タグ latest イメージからイメージへ頻繁に移動する可能性があるため、予測可能で再現可能なビルドとインストールが必要な場合には信頼できません。

タグを使用できます X.Y.Z (ほとんどの場合、変更されていません) ただし、この場合は、イメージに対するすべてのパッチと更新を追跡してください。 使用している画像にタグが付いている場合 X.Y、これは黄金の中庸に適したオプションです。 これを選択すると、パッチが自動的に受信され、同時にアプリケーションの安定バージョンに依存することになります。

翻訳者からの追伸

私たちのブログもお読みください:

• «コンテナ、クラウドネイティブ、Kubernetes に関する新しい CNCF 統計";
• «コンテナベースのアプリケーションを設計するための 7 つの原則";
• «Kubernetes ハッキングの被害者にならない (被害者にならない) 11 の方法";
• «小規模プロジェクトにおける Kubernetes の経験» (レビューとビデオレポート);
• «モニタリングとKubernetes» (レビューとビデオレポート);
• «dapp を使用して CI/CD 用の Docker イメージを迅速かつ便利に構築します» (レビューとビデオレポート);
• «Docker を使用した継続的デリバリーの実践» (レビューとビデオレポート);
• «2018 年、マイクロサービスの狂気は終焉'。

出所： habr.com