Kubernetes のベスト プラクティス。 小さなコンテナの作成

Kubernetes にデプロイする最初のステップは、アプリケーションをコンテナーに配置することです。 このシリーズでは、小さくて安全なコンテナー イメージを作成する方法を見ていきます。
Docker のおかげで、コンテナ イメージの作成がかつてないほど簡単になりました。 基本イメージを指定し、変更を追加して、コンテナーを作成します。

この手法は入門には最適ですが、デフォルトの基本イメージを使用すると、脆弱性がいっぱいの大きなイメージで安全でない作業が行われる可能性があります。

さらに、Docker のほとんどのイメージはベース イメージとして Debian または Ubuntu を使用しており、これにより優れた互換性と簡単なカスタマイズ (Docker ファイルに必要なコードはわずか 700 行) が提供されますが、ベース イメージによりコンテナに数百メガバイトの追加負荷が追加される可能性があります。 たとえば、Go の「hello-world」アプリケーションの単純な node.js ファイルは約 XNUMX メガバイトですが、実際のアプリケーションのサイズはわずか数メガバイトです。

したがって、この余分なワークロードはすべてデジタル スペースの無駄であり、セキュリティの脆弱性やバグの格好の隠れ場所になります。 それでは、コンテナ イメージのサイズを削減する XNUMX つの方法を見てみましょう。

XNUMX つ目は小さな基本イメージを使用する方法で、XNUMX つ目はビルダー パターンを使用する方法です。 おそらく、コンテナーのサイズを削減するには、より小さい基本イメージを使用するのが最も簡単な方法です。 おそらく、使用している言語またはスタックが提供するオリジナルのアプリケーション イメージは、デフォルトのイメージよりもはるかに小さいと考えられます。 node.js コンテナを見てみましょう。

Docker のデフォルトでは、node:8 の基本イメージ サイズは 670 MB ですが、node:8-alpine イメージのサイズはわずか 65 MB、つまり 10 分の XNUMX です。 より小さい Alpine 基本イメージを使用すると、コンテナーのサイズが大幅に縮小されます。 Alpine は小型軽量の Linux ディストリビューションであり、コンテナーを小さく保ちながら多くのアプリケーションと互換性があるため、Docker ユーザーの間で非常に人気があります。 標準の Docker の「node」イメージとは異なり、「node:alpine」は多くのサービス ファイルとプログラムを削除し、アプリケーションを実行するのに十分なものだけを残します。

より小さいベース イメージに移行するには、Dockerfile を更新して新しいベース イメージの操作を開始するだけです。

ここでは、古い onbuild イメージとは異なり、コードをコンテナーにコピーし、依存関係をインストールする必要があります。 新しい Dockerfile では、コンテナーは、node:alpine イメージで開始し、コード用のディレクトリを作成し、NPM パッケージ マネージャーを使用して依存関係をインストールし、最後に server.js を実行します。

このアップグレードにより、コンテナーのサイズが 10 分の XNUMX に小さくなります。 使用しているプログラミング言語またはスタックに基本イメージ縮小機能がない場合は、Alpine Linux を使用してください。 また、コンテナーの内容を完全に管理する機能も提供します。 小さな基本イメージを使用することは、小さなコンテナーを迅速に作成するための優れた方法です。 ただし、Builder パターンを使用すると、さらに大幅な削減を達成できます。

インタープリタ型言語では、ソース コードはまずインタプリタに渡され、次に直接実行されます。 コンパイル言語では、まずソース コードがコンパイル コードに変換されます。 ただし、コンパイルでは、コードの実行に実際には必要のないツールが使用されることがよくあります。 これは、これらのツールを最終コンテナから完全に削除できることを意味します。 これにはビルダーパターンを使用できます。

コードは最初のコンテナーで作成され、コンパイルされます。 コンパイルされたコードは、コードのコンパイルに必要なコンパイラーやツールを使用せずに、最終コンテナーにパッケージ化されます。 このプロセスを通じて Go アプリケーションを実行してみましょう。 まず、onbuild イメージから Alpine Linux に移行します。

新しい Dockerfile では、コンテナーは golang:alpine イメージから始まります。 次に、コード用のディレクトリを作成し、それをソース コードにコピーし、そのソース コードをビルドして、アプリケーションを実行します。 このコンテナは onbuild コンテナよりもはるかに小さいですが、実際には必要のないコンパイラやその他の Go ツールが含まれています。 それでは、コンパイルされたプログラムを抽出して、独自のコンテナーに入れてみましょう。

この Docker ファイルには奇妙な点があることに気づくかもしれません。このファイルには 4 つの FROM 行が含まれています。 最初の XNUMX 行のセクションは、このステージの名前に AS キーワードを使用していることを除いて、前の Dockerfile とまったく同じに見えます。 次のセクションには、新しいイメージを開始するための新しい FROM 行があり、golang:alpine イメージの代わりに Raw alpine をベース イメージとして使用します。

Raw Alpine Linux には SSL 証明書がインストールされていないため、HTTPS 経由のほとんどの API 呼び出しが失敗します。そのため、いくつかのルート CA 証明書をインストールしましょう。

ここからが楽しい部分です。コンパイルされたコードを最初のコンテナから 5 番目のコンテナにコピーするには、12 番目のセクションの 700 行目にある COPY コマンドを使用するだけです。 XNUMX つのアプリケーション ファイルのみがコピーされ、Go ユーティリティ ツールには影響しません。 新しいマルチステージ Docker ファイルに含まれるコンテナ イメージのサイズはわずか XNUMX メガバイトですが、元のコンテナ イメージのサイズは XNUMX メガバイトであり、これは大きな違いです。
したがって、小さなベース イメージとビルダー パターンを使用することは、多くの作業を行わずにはるかに小さなコンテナを作成するための優れた方法です。
アプリケーション スタックによっては、イメージとコンテナーのサイズを削減する追加の方法がある可能性がありますが、小さいコンテナーには本当に測定可能な利点があるのでしょうか? 小型コンテナーが非常に効果的である XNUMX つの領域 (パフォーマンスとセキュリティ) を見てみましょう。

パフォーマンスの向上を評価するには、コンテナーの作成、レジストリーへの挿入 (プッシュ)、そこからコンテナーの取得 (プル) のプロセスにかかる時間を考慮します。 小さいコンテナには、大きいコンテナよりも明らかな利点があることがわかります。

Docker はレイヤーをキャッシュするため、後続のビルドは非常に高速になります。 ただし、コンテナーの構築とテストに使用される CI システムの多くはレイヤーをキャッシュしないため、時間を大幅に節約できます。 ご覧のとおり、大きなコンテナーのビルド時間は、マシンの能力に応じて 34 ～ 54 秒ですが、コンテナーを使用する場合は、ビルダー パターンを使用すると 23 ～ 28 秒に短縮されます。 この種の作業では、生産性が 40 ～ 50% 向上します。 したがって、コードを何回ビルドしてテストするかを考えてください。

コンテナーが構築されたら、そのイメージをコンテナー レジストリにプッシュし (プッシュ コンテナー イメージ)、Kubernetes クラスターで使用できるようにする必要があります。 Google Container Registry を使用することをお勧めします。

Google Container Registry (GCR) を使用すると、生のストレージとネットワークの料金のみを支払い、追加のコンテナ管理料金はかかりません。 プライベートで安全、そして非常に高速です。 GCR は、プル操作を高速化するために多くのトリックを使用します。 ご覧のとおり、 go:onbuild を使用して Docker コンテナ イメージ コンテナを挿入するには、コンピュータのパフォーマンスに応じて 15 ～ 48 秒かかります。また、より小さいコンテナで同じ操作を行うと、生産性の低いマシンの場合は 14 ～ 16 秒かかります。動作速度のメリットが3倍になります。 より大きなマシンの場合、GCR は画像の共有データベースにグローバル キャッシュを使用するため、時間はほぼ同じになります。つまり、画像をロードする必要がまったくありません。 低電力コンピューターでは CPU がボトルネックになるため、小さなコンテナーを使用する利点は非常に大きくなります。

GCR を使用している場合は、ビルド システムの一部として Google Container Builder (GCB) を使用することを強くお勧めします。

ご覧のとおり、これを使用すると、生産的なマシンよりもビルド + プッシュ操作の時間を短縮し、はるかに優れた結果を達成できます。この場合、コンテナーをビルドしてホストに送信するプロセスがほぼ 2 倍速くなります。 さらに、毎日 120 分の無料ビルド時間を取得でき、ほとんどの場合、コンテナー構築のニーズをカバーできます。

次に、最も重要なパフォーマンス指標、つまりプル コンテナの取得またはダウンロードの速度が続きます。 また、プッシュ操作にかかる時間をあまり気にしない場合、プル プロセスの長さはシステム全体のパフォーマンスに重大な影響を与えます。 XNUMX つのノードからなるクラスターがあり、そのうちの XNUMX つに障害が発生したとします。 Google Kubernetes Engine などの管理システムを使用している場合、死んだノードは自動的に新しいノードに置き換えられます。 ただし、この新しいノードは完全に空になるため、動作を開始するにはすべてのコンテナをそのノードにドラッグする必要があります。 プル操作に十分な時間がかかる場合、クラスターはずっと低いパフォーマンスで実行されます。

これは、クラスターへの新しいノードの追加、ノードのアップグレード、またはデプロイメント用の新しいコンテナーへの切り替えなど、さまざまなケースで発生する可能性があります。 したがって、プル抽出時間を最小限に抑えることが重要な要素になります。 小さいコンテナのダウンロードが大きいコンテナよりもはるかに高速であることは否定できません。 Kubernetes クラスター内で複数のコンテナーを実行している場合は、時間を大幅に節約できる可能性があります。

この比較を見てください。マシンの能力に応じて、小さなコンテナーでのプル操作は、 go:onbuild を使用した同じ操作よりも 4 ～ 9 分の XNUMX の時間がかかります。 共有の小さなコンテナー ベース イメージを使用すると、新しい Kubernetes ノードをデプロイしてオンラインにするまでの時間と速度が大幅に短縮されます。

セキュリティの問題を見てみましょう。 小さなコンテナは攻撃対象領域が小さいため、大きなコンテナよりもはるかに安全であると考えられています。 本当か？ Google Container Registry の最も便利な機能の XNUMX つは、コンテナの脆弱性を自動的にスキャンする機能です。 数か月前、onbuild コンテナーとマルチステージ コンテナーの両方を作成したので、そこに脆弱性があるかどうかを確認してみましょう。

その結果は驚くべきもので、小さなコンテナでは中程度の脆弱性が 3 件のみ検出され、大きなコンテナでは重大な脆弱性が 16 件、その他の 376 件が見つかりました。 大きなコンテナの内容を見ると、ほとんどのセキュリティ問題はアプリケーションとは関係がなく、使用すらしていないプログラムに関連していることがわかります。 したがって、人々が大きな攻撃対象領域について話すとき、それはそれを意味します。

重要な点は明らかです。システムに実際のパフォーマンスとセキュリティ上の利点をもたらすため、小さなコンテナを構築する必要があります。

Kubernetes のベスト プラクティス。 名前空間を使用した Kubernetes の構成

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com