クラウドネイティブテクノロジーのオープンクラススタディノート：共有ストレージの原則、ヘルスチェック、監視、ログ

7つの共有ストレージの原則

1.ボリュームの概要

1）、ポッドボリューム

まず、ポッドボリュームの使用シナリオを見てください。

• シナリオ1：ポッド内のコンテナーが実行時に異常終了し、kubeletによって再度プルアップされた場合、前のコンテナーによって生成された重要なデータが失われないようにするにはどうすればよいですか？
• シナリオ2：同じポッド内の複数のコンテナーがデータを共有したい場合はどうすればよいですか？

上記の2つのシナリオは、ボリュームを使用して実際に解決できます。次に、ポッドボリュームの一般的なタイプを見てみましょう。

• ローカルストレージ、emptydir / hostpathが一般的に使用されます
• ネットワークストレージ：ネットワークストレージには現在2つの実装方法があります。1つはツリー内です。その実装のコードはK8sコードリポジトリに配置されます。K8sはより多くのストレージタイプをサポートするため、この方法はK8sにより多くのサポートを提供します。それ自体の開発には大きな負担がかかります。2番目の実装方法はツリー外です。その実装は、実際には、抽象インターフェイスを介してK8自体を分離し、K8コードウェアハウスからさまざまなストレージドライバーを実装します。中程度のストリッピング
• 投影されたボリューム：実際には、コンテナー内のボリュームの形式でシークレット/ configmapなどの構成情報をマウントし、コンテナー内のプログラムがPOSIXインターフェースを介して構成データにアクセスできるようにします。
• PVとPVC

2）、PV

ポッドボリュームがすでに存在するのに、なぜPVを再度導入する必要があるのでしょうか。ポッドで宣言されたボリュームのライフサイクルは、ポッドのライフサイクルと同じです。次のようないくつかの一般的なシナリオがあります。

• シナリオ1：ポッドの再構築と破棄。たとえば、Deploymentによって管理されるポッドは、イメージのアップグレードプロセス中に新しいポッドを生成し、古いポッドを削除します。新しいポッドと古いポッドの間でデータを再利用するにはどうすればよいですか。
• シナリオ2：ホストがダウンしている場合、上記のポッドを移行する必要があります。この時点で、StatefulSetによって管理されるポッドは、ボリューム移行のセマンティクスを実際に実現しています。現時点では、ポッドボリュームを使用することは明らかに不可能です
• シナリオ3：複数のポッド間でデータを共有するかどうかを宣言するにはどうすればよいですか？同じポッド内の複数のコンテナがデータを共有したい場合は、ポッドボリュームを使用して解決できます。複数のポッドがデータを共有したい場合、ポッドボリュームがこのセマンティクスを表現することは困難です。
• シナリオ4：スナップショットやサイズ変更などのデータボリュームを拡張する場合、どのように行う必要がありますか？

上記のシナリオでは、ポッドボリュームを介してその再利用/共有セマンティクスを正確に表現することは困難であり、拡張することも困難です。そのため、K8sは永続ボリュームの概念を導入しています。これは、ストレージとコンピューティングを分離し、さまざまなコンポーネントを介してストレージリソースとコンピューティングリソースを管理し、ポッドとボリューム間のライフサイクル関係を切り離すことができます。このように、ポッドが削除されても、ポッドで使用されていたPVは引き続き存在し、新しく作成されたポッドで再利用できます。

3）、PVC

ユーザーがPVを使用する場合、実際にはPVCを使用しますが、なぜPVを使用してPVCを設計するのですか？主な理由は、K8sユーザーがストレージを使用する方法を簡素化し、職務の分離を実現することです。通常、ユーザーがストレージを使用する場合、必要なストレージサイズとアクセスモードを宣言するだけで済みます

アクセスモードとは何ですか？実際、使用したいストレージを複数のノードで共有することはできますか、それとも単一のノードからのみアクセスできますか（ポッドレベルではなくノードレベルであることに注意してください）。読み取り専用または読み取り/書き込みアクセス？ユーザーはこれらのことだけを気にする必要があり、ストレージに関連する実装の詳細は気にする必要はありません

PVCとPVの概念により、ユーザー要件と実装の詳細は分離され、ユーザーはPVCを介してストレージ要件を宣言するだけで済みます。PVには、運用、保守、管理を統合するためのクラスター管理者とストレージ関連チームがあります。このようにして、ユーザーがストレージを使用する方法が簡素化されます。

PVはクラスター管理者によって管理および制御されるため、PVオブジェクトがどのように生成されるかを見てみましょう。

4）、静的ボリュームプロビジョニング

静的プロビジョニング（静的プロビジョニング）：クラスター管理者は、このクラスター内のユーザーがストレージをどのように使用するかを事前に計画します。ストレージを事前に割り当てます。つまり、PVを事前に作成します。その後、ユーザーは独自のストレージ要件を送信します（これもPVC）、K8の内部コンポーネントは、PVCとPVをバインドするのに役立ちます。ユーザーがポッドを介してストレージを使用すると、対応するPVがPVCを介して検出され、使用できます。

静的生成方法の欠点は何ですか？クラスター管理者は最初に事前割り当てを行う必要があり、事前割り当ては実際にはユーザーの実際のニーズを予測するのが難しいことがわかります。簡単な例を挙げると、ユーザーが20Gを必要としているが、クラスター管理者が80G、100Gを持っているが、20Gを持っていない場合、ユーザーの実際のニーズを満たすことは困難であり、リソースの浪費も引き起こします。

5）、動的ボリュームプロビジョニング

動的供給：つまり、クラスター管理者はPVを事前に割り当てず、テンプレートファイルを作成しました。このテンプレートファイルは、特定のタイプのストレージ（ブロックストレージ、ファイルストレージなど）に必要なパラメーターを作成するために使用されます。パラメータは次のとおりです。ユーザーが気にしない場合は、ストレージ自体に関連するパラメータを実装します。ユーザーは、PVCファイルである独自のストレージ要件を送信し、PVCで使用されるストレージテンプレート（StorageClass）を指定するだけで済みます。

K8sクラスターの管理コンポーネントと制御コンポーネントは、PVCとStorageClassの情報ダイナミクスを組み合わせて、ユーザーが必要とするストレージ（PV）を生成します。PVCとPVがバインドされた後、ポッドはPVを使用できます。StorageClass構​​成を介してストレージに必要なストレージテンプレートを生成し、ユーザーのニーズに基づいてPVオブジェクトを動的に作成して、オンデマンド配布を実現します。これにより、ユーザーの困難を増すことなく、クラスター管理者の運用および保守作業が解放されます。

2.ユースケースの解釈

1）、ポッドボリュームの使用

pod yamlファイルのVolumesフィールドで、ボリュームの名前とボリュームのタイプを宣言します。宣言された2つのボリューム。1つはemptyDirを使用し、もう1つはhostPathを使用します。どちらもローカルボリュームです。

このボリュームはコンテナでどのように使用する必要がありますか？実際にはvolumeMountsフィールドを渡すことができます。volumeMountsフィールドで指定された名前は実際に使用するボリュームであり、mountPathはコンテナー内のマウントパスです。

subPathもありますが、subPathとは何ですか？最初に見てみましょう。両方のコンテナが同じボリューム、つまりキャッシュボリュームを指定しています。次に、複数のコンテナーが同じボリュームを共有する場合、データを分離するために、subPathを使用してこの操作を完了することができます。ボリューム内に2つのサブディレクトリが作成され、コンテナ1によってキャッシュに書き込まれたデータは実際にはサブディレクトリcache1に書き込まれ、コンテナ2によってキャッシュに書き込まれたディレクトリは最終的にこのボリュームのサブディレクトリの下のcache2に分類されます。

readOnlyフィールドもあります。ReadOnlyは実際には読み取り専用マウントを意味します。このマウントの場合、実際にはマウントポイントの下にデータを書き込む方法はありません。

さらに、emptyDirとhostPathはどちらもローカルストレージですが、両者の微妙な違いは何ですか？emptyDirは、実際にはポッド作成プロセス中に一時的に作成されるディレクトリです。このディレクトリは、ポッドが削除されると削除され、その中のデータは空になります。hostPathは、名前が示すように、実際にはホスト上のパスです。ポッドで削除されたマシンその後、このディレクトリはまだ存在し、そのデータは失われません。これは2つの微妙な違いです

2）静的PVの使用

静的PVは、最初に管理者によって作成されます。ここでは、管理者は、例として、AlibabaCloudファイルストレージであるNASを使用します。最初にAlibabaCloudのファイルストレージコンソールでNASストレージを作成し、次にPVオブジェクトにNASストレージの関連情報を入力する必要があります。このPVオブジェクトが事前に作成された後、ユーザーはPVCを介してストレージ要件を宣言できます。次に、ポッドの作成に進みます。ポッドを作成したり、今説明したフィールドを介して特定のコンテナの特定のマウントポイントの下にストレージをマウントしたりするには

作成したばかりのAlibabaCloud NASファイルストレージに対応するPVには、より重要なフィールドがあります。容量は、作成されたストレージのサイズ、accessModes、および作成されたストレージのアクセスモードです。

次に、ReclaimPolicy（PVリサイクルポリシー）があります。このストレージが使用された後、ユーザーポッドとPVCが削除された後、このPVを削除または保持する必要がありますか？

次に、ユーザーがPVオブジェクトをどのように使用するかを見てみましょう。ユーザーがストレージを使用する場合、最初にPVCオブジェクトを作成する必要があります。PVCオブジェクトでは、ストレージ要件を指定するだけでよく、ストレージ自体の特定の実装の詳細は気にしません。ストレージ要件は何ですか？1つ目は必要なサイズであるresources.requests.storageです。2つ目はそのアクセスメソッド、つまりこのストレージを必要とするアクセスメソッドです。ここではReadWriteManyとして宣言されており、マルチノードの読み取りおよび書き込みアクセスもサポートしています。 、これもファイルストレージの典型的な機能です

上の図の左側に、次のステートメントがあります。そのサイズとアクセスモードは、実際には、作成したばかりの静的に作成されたPVと一致します。この場合、ユーザーがPVCを送信すると、K8sクラスターに関連するコンポーネントがPVのPVCをバインドします。後で、ユーザーがポッドyamlを送信すると、ボリュームにPVCステートメントを記述できます。PVCステートメントでは、claimNameを使用して使用するPVCを宣言できます。このとき、マウント方法は実際には前の方法と同じです。yamlが送信されると、PVCによってバインドされたPVを見つけて、そのストレージを使用できます。これは、静的プロビジョニングからポッドでの使用までのプロセスです。

3）、動的PVの使用

このテンプレートファイルはStorageClassと呼ばれます。StorageClassでは、重要な情報を入力する必要があります。最初はプロビジョナーです。プロビジョナーは、PVと対応するストレージを作成するときに実際に意味し、ストレージプラグインを使用して作成する必要があります。

これらのパラメーターは、K8を介してストレージを作成するときに指定する必要があるいくつかの詳細なパラメーターです。これらのパラメーターについては、ここではregionld、zoneld、fsType、およびそのタイプのように、ユーザーが気にする必要はありません。ReclaimPolicyは動的に作成されたPVです。ユーザーが使用を終了し、ポッドとPVCが削除された場合、このPVをどのように処理する必要がありますか？ここで記述しているのはdeleteです。つまり、ユーザーのポッドとPVCが削除済み、このPVも削除されます

次に、見てみましょう。クラスター管理者がStorageClassを送信した後、つまり、PVを作成するためのテンプレートを送信した後、ユーザーはそれをどのように使用しますか？まず、PVCファイルを作成する必要があります。

PVCファイルに保存されているサイズとアクセスモードは変更されていません。次に、StorageClassNameという新しいフィールドを追加する必要があります。これは、PVを動的に作成するためのテンプレートファイルの名前を指定することを意味します。StorageClassNameには、上記で宣言したcsi-diskが入力されます。

PVCを送信した後、K8sクラスター内の関連コンポーネントはPVCと対応するStorageClassに従ってこのPVを動的に生成し、PVCをバインドします。次に、ユーザーが独自のyamlを送信すると、使用法と次のプロセスは以前と同じになります。静的な使用方法は同じです。PVCを介して動的に作成したPVを見つけ、対応するコンテナにマウントして使用します。

4）PVスペックの重要な分野の分析

容量：ストレージオブジェクトのサイズ

AccessModesがこのPVを使用する方法。次の3つの方法で使用できます。

• 1つは、単一ノードの読み取りおよび書き込みアクセスです。
• 2つ目は、複数のノードによる読み取り専用アクセスです。これは、データを共有するための一般的な方法です。
• 3番目のタイプは、複数ノードでの読み取りおよび書き込みアクセスです。

ユーザーがPVCを送信するとき、2つの最も重要なフィールド：CapacityとAccessModes。PVCを送信した後、K8sクラスター内の関連コンポーネントはどのようにして適切なPVを見つけますか？最初に、PV用に確立されたAccessModesインデックスを介してユーザーのPVCのAccessModes要件を満たすことができるすべてのPVリストを検索し、次に、PVCのCapacity、StorageClassName、およびLabelSelectorに従ってPVをさらにフィルタリングします。条件を満たす複数のPV、PVを選択します。サイズが最小でアクセスモードが最も短いPV、つまり最小の適合原理

ReclaimPolicy：ユーザー側のPVのPVCが削除された後、PVはどのように処理されるべきですか？2つの一般的な方法があります

• 最初の方法は削除です。つまり、PVCが削除された後、PVも削除されます。
• 保持する2番目の方法は保持することです。保持後、後者のPVは管理者が手動で処理する必要があります。

StorageClassName：動的プロビジョニング中に指定する必要があるフィールド。つまり、PVの生成に使用するテンプレートファイルを指定する必要があります。

NodeAffinity：言い換えると、作成されるPVは、マウントして使用できるノードによって制限されます。次に、NodeAffinityを使用してノードの制限を宣言します。実際、PVを使用するポッドのスケジューリングには制限があります。つまり、PVを使用する前に、PVにアクセスできるこれらのノードにポッドをスケジュールする必要があります。

5）PVステータスの循環

まず、PVオブジェクトが作成された後、それは短い保留状態になります。実際のPVが作成された後、それは使用可能な状態になります。

使用可能な状態とは、使用可能な状態を意味します。ユーザーがPVCを送信すると、K8s関連のコンポーネントがバインドされます（つまり、対応するPVが見つかります）。この時点で、PVとPVCが結合され、両方がバインドされたステータス。ユーザーがPVCの使用を終了して削除すると、PVは解放された状態になりますが、削除または保持する必要がありますか？これはReclaimPolicyに依存します

特別な説明が必要な点が1つあります。PVがすでにリリース状態にある場合、PVを直接使用可能な状態に戻す方法はありません。つまり、次に新しいPVCにバインドすることはできません。

リリースされたPVを再利用したい場合、この時点で通常何をすべきでしょうか？最初の方法：新しいPVオブジェクトを作成し、以前にリリースされたPVの関連フィールド情報を新しいPVオブジェクトに入力できます。この場合、このPVは新しいPVCと組み合わせることができます。2番目はAfterにあります。ポッドを削除する場合は、PVCオブジェクトを削除しないでください。このようにして、PVにバインドされたPVCが引き続き存在します。次にポッドを使用するときに、PVCを介して直接再利用できます。K8sでStatefulSetによって管理されるストレージを使用したポッドの移行は次のようになります

8.可観測性：アプリケーションは正常ですか？

1.需要の源

2、活力与準備

1）、最初に活気と準備に精通している

レディネスプローブはレディプローブとも呼ばれ、ポッドがレディ状態にあるかどうかを判断するために使用されます。ポッドが準備完了状態にある場合、対応するサービスを外部に提供できます。つまり、アクセス層のトラフィックが対応するポッドに到達する可能性があります。ポッドが準備完了状態にない場合、アクセスレイヤーは対応するトラフィックをポッドから削除します

次の図は、実際には準備の例です。

ポッドポインタが障害状態にあると判断した場合、アクセスレイヤのトラフィックは現在のポッドに到達しません。

このポッドの状態がFAILの状態から成功の状態に変わると、このポッドは本当にこのトラフィックを運ぶことができます。

活性ポインターは類似しており、ポッドが生きているかどうかを判断するために使用されるサバイバルプローブです。

ポッドが実行不可能な状態にある場合、上位レベルの判断メカニズムによって、ポッドを再レイズする必要があるかどうかが判断されます。次に、上位層によって構成された再起動戦略が常に再起動である場合、ポッドはこの時点で直接プルアップされます

2）使い方

活性ポインターと準備ポインターは、3つの異なる検出方法をサポートします。

• httpGet：http Getリクエストを送信することで判断されます。リターンコードが200〜399のステータスコードの場合、アプリケーションが正常であることを示します。
• Exec：コンテナ内でコマンドを実行することにより、現在のサービスが正常かどうかを判断します。コマンドラインの戻り結果が0の場合、コンテナが正常であることを示します。
• tcpSocket：TCPヘルスチェックは、コンテナーのIPとポートを検出することによって実行されます。TCP接続が正常に確立できる場合、現在のコンテナーは正常であると識別されます。

検出結果に関しては、主に3つのタイプがあります。

• 1つ目は成功です。ステータスが成功の場合、コンテナがヘルスチェックに合格したことを意味します。つまり、LivenessプローブまたはReadinessプローブは正常な状態です。
• 2つ目は失敗です。失敗とは、コンテナがヘルスチェックに合格しなかったことを意味します。ヘルスチェックに合格しなかった場合、この時点で対応するプロセスが実行されます。準備を処理する1つの方法は、サービスを介することです。サービスレイヤーはReadinessのポッドによって削除されず、Livenessはポッドを再度プルアップまたは削除します
• 3番目の状態は不明です。不明は、現在の実行メカニズムが完全な実行を実行していないことを意味します。同様のタイムアウトまたは一部のスクリプトが時間内に戻らなかったことが原因である可能性があります。その後、準備プローブまたは活性プローブはこれで何もしません。時間。操作は次のメカニズムがチェックされるのを待ちます

3 、、ポッドプローブの仕様

1）exec

上の図に示すように、これは、exec診断で構成されたLivenessプローブです。次に、コマンドフィールドを設定します。このコマンドフィールドでは、特定のファイルを使用して現在のLivenessプローブのステータスを判別します。このファイルで返される結果が0の場合、またはコマンドが0を返す場合、ポッドは次のようになります。この時点で健康な状態にあります

2）httpGet

httpGetのフィールドの1つはパス、2つ目はポート、3つ目はヘッダーです。この場所では、ヘッダーヘッダーなどのメカニズムを使用して正常性を判断する必要がある場合があります。このヘッダーを構成する必要があります。通常の状況では、正常性とポートのみを渡す必要があります。

3）tcpSocket

tcpSocketは、この例のように、検出ポートを設定するだけで済みます。ポート8080が使用されます。8080ポートのtcp接続接続が正常に確立されると、tecSocketプローブはそれを正常な状態と見なします。

4）さらに、グローバルパラメータである次の5つのパラメータがあります

• 最初のパラメータはinitialDelaySecondsと呼ばれ、ポッドのチェックが遅れる時間を示します。たとえば、Javaアプリケーションがある場合、起動に時間がかかることがあります。したがって、初期段階では、検出できない期間が存在する可能性があり、この時間は予測可能であるため、initialDelaySecondsを設定する必要がある場合があります。

• 秒はperiodSecondsで、検出の時間間隔を表します。通常のデフォルト値は10秒です。

• 3番目のフィールドはtimeoutSecondsで、検出タイムアウト期間を表します。タイムアウト期間内に検出が成功しなかった場合、失敗状態と見なされます。

• 4番目はsuccessThresholdです。つまり、ポッドが検出の成功を再度検出できなかった場合、必要なしきい値の回数はデフォルトで1回です。これは、元のしきい値が失敗したことを意味し、次の検出は今回成功します。ポッドがプローブ状態が正常な状態にあること

• 最後のパラメータはfailureThresholdで、検出失敗の再試行回数を表します。デフォルト値は3です。これは、正常な状態から3回連続して検出が失敗した場合、ポッドの現在の状態が1であると判断されることを意味します。失敗国家

4）、活気と準備の概要

3.問題の診断

これは実際にはポッドのライフサイクルです。最初は保留状態ですが、実行中などに切り替わったり、不明に切り替わったり、失敗に切り替わったりすることもあります。その後、実行が一定期間実行されると、成功または失敗などに切り替わり、不明な状態で表示されると、何らかの状態の復元により、実行に復元されるか、成功または失敗する場合があります。

実際、K8s全体の状態は、ステートマシンと同様のメカニズムに基づいて変換され、異なる状態間の変換は、表現用のステータスや条件などのフィールドを持つ対応するK8sオブジェクトに残されます。

9.可観測性：監視とロギング

1.モニタリング

1）、監視タイプ

2）Kubernetesのモニタリングの進化

初期の頃、つまり、1.10より前のK8sバージョン。誰もがHeapsterのようなコンポーネントを使用してコレクションを監視します。Heapsterの設計原理は実際には比較的単純です。

まず、各Kubernetesにパッケージ化されたcadvisorがあります。このcadvisorは、データ収集を担当するコンポーネントです。cadvisorがデータ収集を完了すると、Kubernetesはcadvisorによって収集されたデータをラップし、対応するAPIに公開します。初期の頃は、実際には3つの異なるAPIがありました。

• 1つ目はサマリーインターフェイスです
• 2つ目はkubeletインターフェースです
• 3番目はPrometheusインターフェースです

これらの3つのインターフェイスの場合、対応するデータソースは実際にはcadvisorですが、データ形式は異なります。Heapsterでは、実際にはサマリーインターフェイスとkubeletの2つのデータ収集インターフェイスをサポートしています。Heapsterは定期的に各ノードに移動してデータをプルし、独自のメモリに集約してから、対応するサービスを上位レベルのコンシューマーに公開します。ダッシュボードやHPA-Controllerと同様に、K8でより一般的なコンシューマーは、サービスを呼び出して対応するモニタリングデータを取得し、対応するエラスティックスケーリングとモニタリングデータの表示を実現します。

上の写真はHeapster内のアーキテクチャです。いくつかの部分に分かれており、最初の部分はコア部分であり、次に上位層にはこのAPIが標準のhttpまたはhttpsで公開されています。次に、中央にソース部分があり、ソース部分は収集されたデータによって公開されるさまざまなインターフェイスと同等であり、プロセッサ部分はデータ変換とデータ集約のための部分です。最後に、シンク部分があります。シンク部分はオフラインでデータを処理します。これは初期のHeapsterアプリケーションのアーキテクチャです。後の期間に、K8sはこの監視インターフェースを標準化し、徐々にHeapsterを調整し、それをメトリクスサーバーに変換しました。

現在の0.3.1バージョンのmetrics-serverは、上の図に示すように大まかな構造を持っています。これは非常に単純です。コア層、中間ソース層、および単純なAPI層があり、API登録の追加層があります。 。このレイヤーの機能は、対応するデータインターフェースをK8のAPIサーバーに登録できることです。将来的には、顧客はこのAPIレイヤーを介してメトリックサーバーにアクセスする必要はありませんが、このAPI登録レイヤーを使用してAPIサーバーを介したAPI。登録レイヤー、次にメトリックサーバーへ。この場合、実際のデータコンシューマーが認識する可能性があるのは、メトリックサーバーではなく、そのようなAPIの特定の実装であり、この実装はメトリックサーバーです。これはメトリクスサーバーの最大の変更点です

2.ログ

どのロケーションログコレクションが収集されるかから、次の3つのタイプをサポートする必要があります。

• 1つ目はホストファイルです。このシナリオはより一般的です。私のコンテナでは、ログファイルは同様のボリュームを介してホストに書き込まれます。ログは、ホストのログローテーション戦略によってローテーションされ、ホスト上のエージェントによって収集されます

• 2つ目は、コンテナにログファイルがあることです。この一般的な方法を処理するにはどうすればよいですか？より一般的な方法は、Sidecarのストリーミングコンテナを介してstdoutに転送し、stdoutを介して対応するログファイルに書き込むことです。ローカルログをローテーションし、外部エージェントによって収集されます

• 3つ目は、stdoutに直接書き込むことです。これは、比較的一般的な戦略です。1つ目は、このエージェントを直接使用してリモートに収集することです。2つ目は、いくつかのslsなどの標準APIを介してリモートに直接収集します。

コースアドレス：https：//edu.aliyun.com/roadmap/cloudnative？spm = 5176.11399608.aliyun-edu-index-014.4.dc2c4679O3eIId＃suit