1.Deployment
展開が良くポッドが導入された問題を解決するために組織され、最大のアップグレードは私が進行ポッドの展開を見ることができるもので、アップグレードRCとして見ることができます。
次のように展開典型的な使用シナリオは次のとおりです。
- 対応するレプリカセット(進化のRC相当、kubernetes V1.2導入)とポッドのコピーを作成するプロセスを生成するために配備オブジェクトの作成
- アクションが完了しているビューの展開展開の状態を確認します(期待値かどうかポッドのコピー数)
- 更新プログラムの展開は、(イメージのアップグレードなど)新しいポッドを作成します
- もし展開の以前のバージョンへの展開ロールバックの現在の不安定性
- 設定項目の詳細PodTemplateSpecを変更して、展開後に再開する展開を一時停止し、新しいリリース
- 高負荷に対処するために展開を拡張
- リリースの成功の指標として見るの展開状況
- 必須ではありません古いバージョンのReplicaSetsをクリーンアップ
展開コマンドを作成します
-f {deployment_fileName} .yaml作成kubectl
ビューの展開に関する情報
kubectl GET展開
2.Horizontal Autoscaler
水平ポッドAutoscalerは、PODが自動拡張を横断し、RC、展開リソースがターゲット調整対象ポッドのコピー数かどうかを決定するために、すべてのターゲットポッドRC制御の負荷分析の変化を追跡することによって、オブジェクトに属する手段HPAと称しますこれは、HPAの原則の実現です。
HPAは、メトリックポッドをロードするには、現在2つの方法があります。
- CPUUtilizationPercentage
- このようなサービス要求などのアプリケーション定義メトリックは、秒以内(QPSまたはTPS)の数に対応するので
CPUUtilizationPercentage自体は、ターゲットポッドのすべてのコピーの平均CPU使用率です。Aポッド自身のCPU使用率ポッドは、CPU使用率の現在値を=÷リクエストのポッド
CPUUtilizationPercentage計算処理がポッドCPU使用率が1分間にわたって平均化された目標値がリクエストのポッドポッドに定義されていない場合、アセンブリHeapsterによるチェック(インストール)することができ、能力CPUUtilizationPercentageポッドの横方向膨張を達成するために使用することができません。アプリケーション定義のメトリックをサポートしようと最初からCPUUtilizationPercentage、Kubernetesバージョン1.2を使用することに加えて。
apiVersion:オートスケーリング/ v1の 種類:HorizontalPodAutoscaler メタデータ: 名前:フォー - apacheの 名前空間:デフォルト 仕様: maxReplicas:10 minReplicas:1 scaleTargetRef: 種類:配備 名:PHP - apacheの targetCPUUtilizationPercentage:90
上で定義したとおり、我々はときにこれらCPUUtilizationPercentageポッドコピートリガ、展開PHP-Apacheのポッドコピーのための自動動的拡張の90%以上を対象HPA制御を知ることができ、10の最大数、1の最小値は、直接以外でYAMLの定義ファイルと呼び出しがHPAのリソースオブジェクトを作成するコマンドを作成kubectl次のように、我々はまた、直接、コマンドラインを作成することができます
kubectlのオートスケール配備PHP-Apacheの--cpuパーセント= 90 --min = 1 --max = 10
3.StatefulSet
、RC、展開、仕事でkubernetesでは、DaemonSetはステートレスサービスのためのすべてのですが、現実には多くのサービスがあり、このようなMySQL Clusterの、ZKクラスタとして、ステートフルあり、これらのサービスは、共通して次のいくつかを持っています
- 各ノードは、固定アイデンティティIDを持っている、あなたはお互いに、IDを介してクラスタメンバーを発見し、通信することができます
- 比較的固定クラスタサイズは、改ざんません。
- クラスタ内の各ノードは、通常、永続ストレージに永続データステートフルです
- ディスクが破損している場合、クラスタ内のノードのいずれかが正常に機能しないことができ、クラスタ機能が損なわれ
あなたがコピーポッドの数を制御するRC /展開方法と、クラスタのような状態を達成するために持っているなら、私たちは、ポッドの名前はランダムに生成されるので、最初のポイントを達成することはできないでしょうIPのポッドは、実行時に決定されてもよく、私たちは事前に各ポッドの一意のIDを作成することができない、変更されます。。。この問題を解決するために、バージョンV1.5 StatefulSet導入開始kubernetesは、それの本質からのアップは、次のような特徴を持っている特別なバリアントRC /展開、と見ることができます。
- 各ポッド内StatefulSetが安定している、ユニークなネットワークIDは、クラスタの他のメンバーを見つけるために使用することができます
- ポッド開始と停止シーケンスStatefulSetコピー制御が制御され、n番目の操作ポッドは、ポッドは、前のn-1は、すでに実行して準備完了状態れます
- PV / PVCによって達成安定した永続ストレージ・ボリュームの使用中ポッドStatefulSetは、StatefulSetに関連付けられたデフォルトのストレージボリュームは削除されませんポッドを削除(データセキュリティのため)
保存された状態データを用いて束ねStatefulSet PVポッド容積に加えて、だけでなく、ヘッドレス・サービスに関連して使用、即ち各StatefulSetの定義がどのヘッドレスサービス、ヘッドレスサービス通常のサービスを区別するために宣言し、そうでないという点で、それが属しクラスタIPは、ヘッドレスサービスは、ドメイン名を解決するには、対応するサービスのすべてのポッドエンドポイントのリストを返す場合。別のインスタンスに基づいてStatefulSetヘッドレス・サービスは3カフカStatefulSetクラスタノード、対応するヘッドレス例えば、各ポッドStatefulSet制御のためにDNSドメイン名形式:. $(Podname)$(ヘッドレスサービス名)が作成されますサービス名は、StatefulSet名は-0.kafkaカフカ、カフカ-1.kafka、カフカ-2.kafkaは、これらのDNSドメイン名は設定で直接することができているカフカ、3ポッドDNSドメイン名の内部StatefulSetで、カフカです固定ファイル