[kubernetes]クバーネディスモード-予測範囲内の要件

5453 ワード

この文章は、「クバーネディスモード2020年のヴェルゲン・イフリアン、ローラン・フース知音、アン・スンギュ、倍の書満、979189909123」をもとに書かれています.

に質問


コンテナでアプリケーションを実行できる場合は、k 8 sは他のプログラミング言語で作成されたアプリケーションを管理することもできますが、言語によって異なります.
コンテナが最適な機能を実行するために必要なリソース量を予測することは困難であるため、開発者がテストを実行してから、サービスを実施するために必要なリソース量を知ることができます.
すべてのアプリケーションのプロパティを定義し、管理計画に渡すことがクラウドネイティブアプリケーションの基本的な前提です.
リソース要件に加えて、アプリケーションの実行時には、データストレージやアプリケーション設定などのプラットフォーム管理機能が必要です.

解決策


コンテナの運転時の要件を理解するには、2つの重要な理由があります.

  • すべてのランタイム依存性を定義し、リソース要件を計算すると、クバーネディスは、ハードウェアを最も効率的に使用するために、クラスタ内のコンテナのランタイム位置をインテリジェントに決定することができる.

  • ようりょうけいかく
    特定のサービス要件と合計サービス数に基づいて容量を異なる環境に計画し、クラスタ全体の要件を満たすために経済的で効率的な最適なホストプロファイルを作成できます.クラスタの管理を成功させるには、サービスリソースプロファイルと容量計画を長期的に連携させる必要があります.
  • ランタイム依存性

  • ファイルストレージ
  • hostPort
  • 設定プロファイル
  • この3つのプロジェクトは、典型的なランタイム依存性を有する.

    ファイルストレージ


    アプリケーション・ステータスを格納するファイル・ストレージ
    ファイルシステムは一時的で、コンテナが終了すると削除されます.クバーネディスは、コンテナの再起動時に削除されない多目的エントリーレベルのストレージです.
    最も単純なボリュームタイプは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です.環境固有の設定をコンテナに適用するより安全な方法を提供します.
    ストレージとポート番号はクラスタノードによって提供されますが、プロファイルと秘密オブジェクトの作成は簡単な管理タスクです.ストレージおよびポート番号依存性は、シードの所定の位置を制限し、プロファイルおよび秘密依存性は、シードの起動を阻止する可能性がある.
    このような依存性を持つコンテナ化アプリケーションを設計する際には、将来発生する可能性のあるランタイム制限を常に考慮する必要があります.