[kubernetes]クバーネディスモード-予測範囲内の要件
5453 ワード
この文章は、「クバーネディスモード2020年のヴェルゲン・イフリアン、ローラン・フース知音、アン・スンギュ、倍の書満、979189909123」をもとに書かれています.
コンテナでアプリケーションを実行できる場合は、k 8 sは他のプログラミング言語で作成されたアプリケーションを管理することもできますが、言語によって異なります.
コンテナが最適な機能を実行するために必要なリソース量を予測することは困難であるため、開発者がテストを実行してから、サービスを実施するために必要なリソース量を知ることができます.
すべてのアプリケーションのプロパティを定義し、管理計画に渡すことがクラウドネイティブアプリケーションの基本的な前提です.
リソース要件に加えて、アプリケーションの実行時には、データストレージやアプリケーション設定などのプラットフォーム管理機能が必要です.
コンテナの運転時の要件を理解するには、2つの重要な理由があります.
すべてのランタイム依存性を定義し、リソース要件を計算すると、クバーネディスは、ハードウェアを最も効率的に使用するために、クラスタ内のコンテナのランタイム位置をインテリジェントに決定することができる.
ようりょうけいかく
特定のサービス要件と合計サービス数に基づいて容量を異なる環境に計画し、クラスタ全体の要件を満たすために経済的で効率的な最適なホストプロファイルを作成できます.クラスタの管理を成功させるには、サービスリソースプロファイルと容量計画を長期的に連携させる必要があります.
ファイルストレージ hostPort 設定プロファイル この3つのプロジェクトは、典型的なランタイム依存性を有する.
アプリケーション・ステータスを格納するファイル・ストレージ
ファイルシステムは一時的で、コンテナが終了すると削除されます.クバーネディスは、コンテナの再起動時に削除されない多目的エントリーレベルのストレージです.
最も単純なボリュームタイプは
クラスタノードが提供するボリュームにシードを必要としない場合、シードはスケジュールされません.ボリュームは、実行時依存性の一例であり、シードの実行インフラストラクチャおよびシードのスケジューリング性に影響します.
ほとんどのアプリケーションでは、設定情報が必要です.クーバー社が推奨するソリューションはプロファイルです.アプリケーション設定には、環境変数による設定とファイルシステムによる設定が含まれます.
上記の2つの方法は、コンテナの実行時依存性(プロファイルマッピングによって命名された)を適用します.すべてのリクエストのプロファイルマッピングが作成されていない場合、コンテナはノードにスケジューリングできますが、起動しません.
ストレージとポート番号はクラスタノードによって提供されますが、プロファイルと秘密オブジェクトの作成は簡単な管理タスクです.ストレージおよびポート番号依存性は、シードの所定の位置を制限し、プロファイルおよび秘密依存性は、シードの起動を阻止する可能性がある.
このような依存性を持つコンテナ化アプリケーションを設計する際には、将来発生する可能性のあるランタイム制限を常に考慮する必要があります.
に質問
コンテナでアプリケーションを実行できる場合は、k 8 sは他のプログラミング言語で作成されたアプリケーションを管理することもできますが、言語によって異なります.
コンテナが最適な機能を実行するために必要なリソース量を予測することは困難であるため、開発者がテストを実行してから、サービスを実施するために必要なリソース量を知ることができます.
すべてのアプリケーションのプロパティを定義し、管理計画に渡すことがクラウドネイティブアプリケーションの基本的な前提です.
リソース要件に加えて、アプリケーションの実行時には、データストレージやアプリケーション設定などのプラットフォーム管理機能が必要です.
解決策
コンテナの運転時の要件を理解するには、2つの重要な理由があります.
すべてのランタイム依存性を定義し、リソース要件を計算すると、クバーネディスは、ハードウェアを最も効率的に使用するために、クラスタ内のコンテナのランタイム位置をインテリジェントに決定することができる.
ようりょうけいかく
特定のサービス要件と合計サービス数に基づいて容量を異なる環境に計画し、クラスタ全体の要件を満たすために経済的で効率的な最適なホストプロファイルを作成できます.クラスタの管理を成功させるには、サービスリソースプロファイルと容量計画を長期的に連携させる必要があります.
ランタイム依存性
ファイルストレージ
アプリケーション・ステータスを格納するファイル・ストレージ
ファイルシステムは一時的で、コンテナが終了すると削除されます.クバーネディスは、コンテナの再起動時に削除されない多目的エントリーレベルのストレージです.
最も単純なボリュームタイプは
emptyDir
で、種子が生きている間にのみ存在し、種子を除去すると、ボリュームとその内部の内容も削除されます.フィードを再起動した後も、ボリュームは他のタイプのストレージメカニズムをサポートするボリュームが必要です.# PersistentVolume의 의존성
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- images: nginx
name: nginx
volumeMounts:
- mountPath: "/webdata"
name: web-volume
volumes:
- name: web-volume
persistentVolumeClaim: # 이미 생성된 PVC에 연결하기 위한 의존성
claimName: nginx-webdata
スケジューラは、シード要求のボリュームタイプを決定します.これは、シードの実行場所に影響します.クラスタノードが提供するボリュームにシードを必要としない場合、シードはスケジュールされません.ボリュームは、実行時依存性の一例であり、シードの実行インフラストラクチャおよびシードのスケジューリング性に影響します.
hostPort
hostPort
によってコンテナポートがホストシステム上の特定のポートに露出すると、クバーネディスも同様の依存性を生じる.hostPort
は、クラスタ内で各ノードに対応するポートを保持し、各ノードが最大1つのシードしかスケジューリングできないことを制限します.ポートが競合するゲートでのみ、クバーネディスクラスタノードの数でパイドを拡張できます.設定
ほとんどのアプリケーションでは、設定情報が必要です.クーバー社が推奨するソリューションはプロファイルです.アプリケーション設定には、環境変数による設定とファイルシステムによる設定が含まれます.
上記の2つの方法は、コンテナの実行時依存性(プロファイルマッピングによって命名された)を適用します.すべてのリクエストのプロファイルマッピングが作成されていない場合、コンテナはノードにスケジューリングできますが、起動しません.
# 컨피그맵에 대한 의존성
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- images: nginx
name: nginx
env:
-name: PATTERN
valueFrom:
configMapKeyRef: # 컨피그맵의 의존성 생성
name: nginx-config
key: pattern
輪郭マップに似た概念はSecretです.環境固有の設定をコンテナに適用するより安全な方法を提供します.ストレージとポート番号はクラスタノードによって提供されますが、プロファイルと秘密オブジェクトの作成は簡単な管理タスクです.ストレージおよびポート番号依存性は、シードの所定の位置を制限し、プロファイルおよび秘密依存性は、シードの起動を阻止する可能性がある.
このような依存性を持つコンテナ化アプリケーションを設計する際には、将来発生する可能性のあるランタイム制限を常に考慮する必要があります.
Reference
この問題について([kubernetes]クバーネディスモード-予測範囲内の要件), 我々は、より多くの情報をここで見つけました https://velog.io/@miewone/kubernetes-쿠버네티스-패턴-예측-범위-내의-요구사항テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol