Kubernetesアプリケーション品質管理を学ぶ

サービス品質管理

Kubernetesでは、Podはスケジューリングの最小単位です。そのため、リソースとスケジューリングに関連するすべての属性はPodオブジェクトのフィールドであり、CPUとメモリが最も重要です。以下の図をご覧ください。

 ---
 apiバージョン: v1
 種類: ポッド
メタデータ
名前: ポッド- デモ
仕様:
 コンテナ
- 名前: myweb
 画像: WordPress
 imagePullPolicy : IfNotPresent
 リソース：
 リクエスト:
 メモリ： 「128Mi」
 CPU ： 「250m」
 制限：
 メモリ： 「256Mi」
 CPU ： 「500m」

リソースセクションでは、リソースの制限について説明します。

注: Pod は複数のコンテナを定義でき、各リソース制限は独自のコンテナで構成されているため、Pod の合計構成リソースはすべてのコンテナの合計になります。

Kubernetesでは、CPUなどのリソースは「圧縮可能リソース」と呼ばれます。圧縮可能リソースとは、利用可能なリソースが不足した場合でも、Podが「飢餓状態」になるだけで終了しないリソースです。メモリなどのリソースは「非圧縮可能リソース」と呼ばれます。非圧縮可能リソースとは、リソースが不足した場合でも、PodがOutOfMemoryError（OOM）に遭遇するだけであるリソースです。

CPU設定の単位はCPU数です。例えば、CPU=1は、このPodのCPU制限が1CPUであることを意味します。1CPUコア、1vCPU、または1CPUハイパースレッディングのいずれになるかは、ホストマシンのCPU実装に依存します。Kubernetesは、Podが1CPUのキャパシティを利用できるようにするだけで済みます。

Kubernetesでは、CPU制限を小数で設定できます。例えば、上記で設定したCPU.limitsの値は500mで、これは500ミリCPU、つまり0.5CPUを意味します。つまり、PodにはCPUの半分の計算能力が割り当てられます。したがって、cpu=0.5と直接設定することもできますが、Kubernetesの内部的なCPU計算方法であるため、公式の推奨値は500mです。

Kubernetesでは、メモリリソースはバイト単位で測定され、バイトの値はEi、Pi、Ti、Gi、Mi、Kiで表されます。MiとMの違いに注意してください（1Mi = 1024 1024、1M = 1000 1000）。

Kubernetes では、Pod の CPU およびメモリリソースの制限は、実際にはリクエストと制限の 2 つのカテゴリに分かれています。

 仕様. コンテナ[]. リソース. 制限.CPU
 仕様. コンテナ[]. リソース. 制限. メモリ
仕様. コンテナ[]. リソース. リクエスト.CPU
 仕様. コンテナ[]. リソース. リクエスト. メモリ

両者の違いは次のとおりです。

スケジュール設定中、kube-scheduler はリクエストの値に基づいて計算します。
CGroups を設定すると、kubelet は値に応じて制限を設定します。

QoSモデル

Kubernetesは3つのQoSモデルをサポートしています。これらは、リクエストと制限の設定に基づいて分類されます。

保証

以下に示すように、ポッド内のすべてのコンテナに同一のリクエストと制限設定がある場合、ポッドは保証されているとみなされます。

 apiバージョン: v1
 種類: ポッド
メタデータ
名前: qos - デモ
名前空間: qos - 例
仕様:
 コンテナ
- 名前: qos - デモ- ctr
 画像: nginx
 リソース：
 制限：
 メモリ： 「200Mi」
 CPU ： 「700m」
 リクエスト:
 メモリ： 「200Mi」
 CPU ： 「700m」

ポッドが制限のみを設定し、リクエストを設定しない場合は、システムはデフォルトで制限に等しいリクエスト値を割り当て、保証済みとして分類されることに注意してください。

バースト可能

ポッドが保証基準を満たしていないものの、少なくとも1つのコンテンンターにリクエストが設定されている場合、そのポッドはバースト可能として分類されます。例：

 apiバージョン: v1
 種類: ポッド
メタデータ
名前: qos - デモ- 2
 名前空間: qos - 例
仕様:
 コンテナ
- 名前: qos - デモ- 2 - ctr
 画像: nginx
 リソース：
 限界
メモリ： 「200Mi」
 リクエスト:
 メモリ： 「100Mi」

ベストエフォート

このポッドにリクエスト値も制限値も設定されていない場合、その QoS カテゴリは BestEffort になります。

 apiバージョン: v1
 種類: ポッド
メタデータ
名前: qos - デモ- 3
 名前空間: qos - 例
仕様:
 コンテナ
- 名前: qos - デモ- 3 - ctr
 画像: nginx

QoS 割り当ての主なシナリオは、ホストリソースが不足し、kubelet がリソースのエビクションを実行する必要がある場合です。現在、Kubernetes で設定されているデフォルトのエビクションしきい値は次のとおりです。

 使用可能なメモリ< 100 Mi
 nodefs . 使用可能< 10 %
 nodefs.inodesFree < 5 %
 imagefs . 利用可能< 15 %

上記の条件は kubelet で設定できます。

 kubelet -- eviction - hard = imagefs.available < 10 % 、 memory.available < 500 Mi 、 nodefs.available < 5 % 、 nodefs.inodesFree < 5 % -- eviction - soft = imagefs.available < 30 % 、 nodefs.available < 10 % -- eviction - soft - grace - period = imagefs.available = 2 m 、 nodefs.available = 2 m -- eviction - max - pod - grace - period = 600

Kubernetes では、エビクションはソフトエビクションとハードエビクションの 2 つのモードに分かれています。

ソフトエビクションを使用すると、適切な待機時間を設定できます。例えば、上記のようにimagefs.available=2mと設定すると、Imagefsがしきい値を満たしていない場合にのみ、2分後にエビクションが実行されます。
ハードエビクションは、しきい値に達したときにエビクションを実行します。

ホストマシンのエビクションしきい値に達すると、MemoryPressure または DiskPressure 状態に移行し、新しい Pod がスケジュールされなくなります。エビクションが発生すると、kubelet は以下の順序で Pod を削除します。

BestEffort タイプの Pod。
Burstable カテゴリでは、リソース使用量がリクエストの Pod を超えたため、「飢餓」状態になっています。
Guaranteed カテゴリは、Guaranteed カテゴリの Pod がリソース使用量の制限を超えた場合、またはホストマシン自体がメモリ不足の場合にのみ、削除対象として選択されます。

CPUセット

cpuset はコンテナを特定の CPU コアにバインドし、CPU コンテキストの切り替えを減らします。

Pod は Guaranteed タイプである必要があります。
Pod の CPU リソース要求と制限を同じ値に設定するだけです。

 仕様:
 コンテナ
- 名前: nginx
 画像: nginx
 リソース：
 制限：
 メモリ： 「200Mi」
 CPU ： 「2」
 リクエスト:
 メモリ： 「200Mi」
 CPU ： 「2」

制限範囲

アプリケーションPodを構成する際、通常はサービス品質、つまりリクエストと制限を設定します。しかし、Podの数が多く、それらの多くが同じ制限のみを必要とする場合、一つ一つ制限を追加するのは面倒です。このような場合、LimitRangeを使用してグローバル制限を設定できます。Podのデプロイ時にリクエストと制限を指定した場合、指定された制限が有効になります。そうでない場合は、デフォルトの制限がPod全体に適用されます。

要約すると、LimitRange は次の機能を実現できます。

名前空間内の各ポッドまたはコンテナの最小および最大のリソース使用量を制限します。
名前空間内の各 PVC のリソース要求の範囲を制限します。
名前空間内のリソース要求の割合と要求の数を制限します。
リソースのデフォルトの制限を構成します。

一般的なシナリオは次のとおりです（「Kubernetes: The Definitive Guide」より）

クラスター内の各ノードには2GBのメモリが搭載されており、クラスター管理者は、どのPodも2GBを超えるメモリを要求することを望んでいません。これは、クラスター全体で2GBを超えるメモリ要求に対応できるノードがないためである。Podのメモリ構成が2GBを超える場合、そのPodはどのノードでも実行スケジュールが設定されない。これを防ぐため、クラスター管理者はシステム管理機能を設定し、Podが2GBを超えるメモリを要求できないようにしたいと考えている。
クラスターは同じ組織内の2つのチームによって共有されており、それぞれ本番環境と開発環境が稼働しています。本番環境は最大8GBのメモリを使用できますが、開発環境は最大512MBのメモリを使用できます。クラスター管理者は、2つの環境に異なる名前空間を作成し、それぞれに異なる制限を設定することで、この要件を満たすことを検討しています。
ユーザーがポッドを作成すると、使用されるリソースがマシンで利用可能な最大リソースよりわずかに少ない場合があります。残りのリソースは、他のタスクを実行するには不十分であるにもかかわらず、クラスター全体にとっては無駄になるという、厄介な状況にあります。そのため、クラスター管理者は、各ポッドがクラスターの平均リソース（CPUとメモリ）の少なくとも20%を使用するようにする必要があります。これにより、クラスターはよりリソース整合性の高いスケジューリングを提供し、リソースの無駄を削減できます。

1. まず、名前空間を作成します。

 apiバージョン: v1
 種類: 名前空間
メタデータ
名前: クーロップス

2. 名前空間の LimitRange を設定します。

 apiバージョン: v1
 種類: LimitRange
 メタデータ
名前: mylimit
 名前空間: coolops
 仕様:
 制限：
 - 最大:
 CPU ： 「1」
 メモリ： 1Gi
 分:
 CPU : 100 m
 メモリ: 10 Mi
 最大制限リクエスト比率:
 CPU : 3
 メモリ： 4
 タイプ: ポッド
- デフォルト：
 CPU : 300 m
 メモリ: 200 Mi
 デフォルトリクエスト:
 CPU : 200 m
 メモリ: 100 マイル
最大:
 CPU ： 「2」
 メモリ： 1Gi
 分:
 CPU : 100 m
 メモリ: 10 Mi
 最大制限リクエスト比率:
 CPU : 5
 メモリ： 4
 タイプ: コンテナ

パラメータの説明:

`max`: `type` が `Pod` の場合、ポッド内のすべてのコンテナリソースの Limit 値の合計の上限を表します。これは、ポッド全体のリソースの最大 Limit です。ポッド定義の Limit 値が `LimitRange` の値より大きい場合、ポッドの作成は失敗します。`type` が `Container` の場合も同様の意味になります。
min: type が Pod の場合、Pod 内の全コンテナのリソース要求の合計の下限を表します。つまり、全コンテナのリソース要求の合計が min の値を下回ることは許されません。そうでない場合、Pod は正常に作成されません。type が Container の場合も同様の意味になります。
maxLimitRequestRatio: タイプがPodの場合、Pod内のすべてのコンテナリソースリクエストにおける制限値とリクエスト値の比率の上限を表します。例えば、PodのCPU制限値が3でリクエスト値が0.5の場合、比率は6となり、Podの作成は失敗します。
`defaultrequest` と `defaultlimit` はデフォルト値です。これら 2 つの構成オプションは `type: Container` でのみ使用できます。

知らせ：
(1) コンテナに最大値が設定されている場合、ポッド内のコンテナにも制限値が設定されている必要があります。設定されていない場合は、デフォルトの制限値が使用されます。デフォルトの制限値も設定されていない場合、ポッドはコンテナの作成に失敗します。
(2) コンテナの最小値が設定されている場合、コンテナ作成時にリクエストの値を設定する必要があります。設定されていない場合は、デフォルトのリクエストが使用されます。デフォルトのリクエストが設定されていない場合は、コンテナの制限値がデフォルトとして使用されます。制限も設定されていない場合は、起動時にエラーが発生します。

上記で設定した LimitRange を作成します。

 $ kubectl apply -f 制限範囲.yaml
 limitrange / mylimit が作成されました
$ kubectl get limitrange - n Coolops
 名前の作成場所
マイリミット2022-08-02 T06 : 08 : 43Z
 $ kubectl は、 limitranges を記述します- n Coolops mylimit
 名前: mylimit
 名前空間: coolops
 タイプリソース最小最大デフォルトリクエストデフォルト制限最大制限/ リクエスト比率
---- -------- --- --- --------------- ------------ -----------------------
 ポッドCPU 100 m 1 - - 3
 ポッドメモリ10 Mi 1 Gi - - 4
 コンテナCPU 100 m 2 200 m 300 m 5
 コンテナメモリ10 Mi 1 Gi 100 Mi 200 Mi 4

3. 指定された範囲内でのリクエストと制限を許可するポッドを作成します。

 apiバージョン: v1
 種類: ポッド
メタデータ
名前: pod01
 名前空間: coolops
 仕様:
 コンテナ
- 名前: ポッド- 01
 画像: nginx
 imagePullPolicy : IfNotPresent
 リソース：
 リクエスト:
 CPU : 200 m
 メモリ: 30 マイル
制限：
 CPU : 300 m
 メモリ: 50 マイル

kubectl apply -f pod-01.yaml を使用して、Pod を正常に作成できます。

4. CPU 使用率が許可されたアクセス制限を超えるポッドを作成します。

 apiバージョン: v1
 種類: ポッド
メタデータ
名前: pod02
 名前空間: coolops
 仕様:
 コンテナ
- 名前: ポッド- 02
 画像: nginx
 imagePullPolicy : IfNotPresent
 リソース：
 リクエスト:
 CPU : 200 m
 メモリ: 30 マイル
制限：
 CPU : 2
 メモリ: 50 マイル

その後、作成しようとすると、次のエラーが発生します。

 # kubectl apply -f pod -02.yaml   
 サーバーからのエラー( 禁止): 「pod-02.yaml」の作成中にエラーが発生しました: ポッド「pod02」は禁止されています: [ ポッドあたりの最大CPU 使用量は1 ですが、 制限は2です。 ポッドあたりのCPU 最大制限とリクエストの比率は3 ですが、 指定された比率は10.000000 です。 コンテナあたりのCPU 最大制限とリクエストの比率は5 ですが、 指定された比率は10.000000 です]

5. 許容範囲を下回るポッドを作成します。

 apiバージョン: v1
 種類: ポッド
メタデータ
名前: pod03
 名前空間: coolops
 仕様:
 コンテナ
- 名前: ポッド- 03
 画像: nginx
 imagePullPolicy : IfNotPresent
 リソース：
 リクエスト:
 CPU : 200 m
 メモリ: 30 マイル
制限：
 CPU : 100 m
 メモリ: 10 Mi

すると次のエラーが報告されます。

 # kubectl apply -f pod - 03.yaml  
 ポッド「pod03」 は無効です。
 * 仕様. コンテナ[ 0 ] . リソース. リクエスト: 無効な値: 「200m」 : CPU 制限以下である必要があります
* 仕様. コンテナ[ 0 ] . リソース. リクエスト: 無効な値: 「30Mi」 : メモリ制限以下である必要があります

6. 定義されたリクエストや制限のないポッドを作成します。

 apiバージョン: v1
 種類: ポッド
メタデータ
名前: pod04
 名前空間: coolops
 仕様:
 コンテナ
- 名前: ポッド- 04
 画像: nginx
 imagePullPolicy : IfNotPresent
 リソース：
 リクエスト:
 CPU : 200 m
 メモリ: 200 Mi

Pod を作成すると、次のように制限が自動的に追加されていることがわかります。

 # kubectl describe ポッド- n coolops pod04
 ...
 制限:
 CPU : 300 m
 メモリ: 200 Mi
 リクエスト：
 CPU : 200 m
 メモリ: 200 Mi
 ...

上記では `requests` を指定しましたが、`LimitRange` によって `defaultLimits` が自動的に追加されました。何も追加しない、あるいは 1 つだけ追加することもできます。原理は同じです。ここで設定する `maxLimitRequestRatio` には注意が必要です。設定された比率は、ここで設定した値以下である必要があります。

前述のように、LimitRange は次のように PVC を制限することもできます。

 apiバージョン: v1
 種類: LimitRange
 メタデータ
名前: ストレージ制限
名前空間: coolops
 仕様:
 制限：
 - タイプ: PersistentVolumeClaim
 最大:
 ストレージ： 2 Gi
 分:
 ストレージ: 1 Gi

作成後は表示できます:

 kubectl describe limitranges - n クールオプスストレージ制限
名前: storagelimits
 名前空間: coolops
 タイプリソース最小最大デフォルトリクエストデフォルト制限最大制限/ リクエスト比率
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――                                    
 PersistentVolumeClaim ストレージ1 Gi 2 Gi - - -

テスト用に PVC を作成することもできます。原理は同じです。

サービス可用性管理

高可用性

本番環境レベルのアプリケーションでは、特殊なアプリケーション（バッチアプリケーションなど）を除き、アプリケーションの可用性を確保するために高可用性が維持されます。したがって、アプリケーションポッドを設計する際には、高可用性を考慮する必要があります。

最もシンプルなアプローチは複数のレプリカを作成することです。つまり、アプリケーションを作成する際に少なくとも2つのレプリカが必要になります。以下の例で `replicas` を 3 と指定すると、アプリケーションに3つのレプリカがあることを示します。

 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ
ラベル:
 アプリ: nginx
 名前: nginx - デプロイメント
仕様:
 進捗期限秒数: 600
 レプリカ： 3
 改訂履歴制限: 10
 セレクター:
 マッチラベル
アプリ: nginx
 戦略：
 ローリングアップデート:
 最大サージ： 25 ％
 最大利用不可: 25 %
 タイプ: ローリングアップデート
テンプレート：
 メタデータ
作成タイムスタンプ: null
 ラベル:
 アプリ: nginx
 仕様:
 コンテナ
- イメージ: nginx : 1.8
 imagePullPolicy : IfNotPresent
 名前: nginx
 リソース：
 リクエスト:
 CPU : 0.5
 メモリ: 500 MB
 制限：
 CPU : 0.5
 メモリ: 500 MB
 ポート:
 - コンテナポート: 80
 名前: http
 プロトコル: TCP

しかし、複数のインスタンスを構成するだけで十分なのでしょうか?

3 つのレプリカすべてが 1 つのサーバーにスケジュールされていて、そのサーバーが何らかの理由でダウンした場合、そのサーバー上のアプリケーションは使用できなくなりますか?

この問題を解決するには、同じアプリケーションに対してアンチアフィニティを設定する必要があります。つまり、同じアプリケーションのPodが同じホストにスケジュールされないようにする必要があります。上記のアプリケーションYAMLは以下のように変更されます。

 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ
ラベル:
 アプリ: nginx
 名前: nginx - デプロイメント
仕様:
 進捗期限秒数: 600
 レプリカ： 3
 改訂履歴制限: 10
 セレクター:
 マッチラベル
アプリ: nginx
 戦略：
 ローリングアップデート:
 最大サージ： 25 ％
 最大利用不可: 25 %
 タイプ: ローリングアップデート
テンプレート：
 メタデータ
作成タイムスタンプ: null
 ラベル:
 アプリ: nginx
 仕様:
 親和性
ポッドアンチアフィニティ
スケジュール中に必須、実行中に無視:
 - ラベルセレクター:
 一致表現:
 - キー: アプリ
演算子: In
 値：
 - nginx
 トポロジキー: kubernetes.io/ ホスト名
コンテナ
- イメージ: nginx : 1.8
 imagePullPolicy : IfNotPresent
 名前: nginx
 リソース：
 リクエスト:
 CPU : 0.5
 メモリ: 500 MB
 制限：
 CPU : 0.5
 メモリ: 500 MB
 ポート:
 - コンテナポート: 80
 名前: http
 プロトコル: TCP

これにより、同じタイプのアプリケーションが同じノードにスケジュールされないようになり、基本的な高可用性が実現されます。

可用性

ただし、アプリケーションの高可用性を単に確保するだけでは、アプリケーション自体が利用できない場合に異常が発生する可能性があります。

Kubernetes Deployment のデフォルトのアップデート戦略はローリングアップデートであることはご存じのとおりです。アップデート後に新しいアプリケーションが利用可能であることを確認するには、`readinessProbe` を使用する必要があります。これにより、古いバージョンを停止する前にアプリケーションが利用可能であることが保証されます。上記の YAML は次のように変更できます。

 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ
ラベル:
 アプリ: nginx
 名前: nginx - デプロイメント
仕様:
 進捗期限秒数: 600
 レプリカ： 3
 改訂履歴制限: 10
 セレクター:
 マッチラベル
アプリ: nginx
 戦略：
 ローリングアップデート:
 最大サージ： 25 ％
 最大利用不可: 25 %
 タイプ: ローリングアップデート
テンプレート：
 メタデータ
作成タイムスタンプ: null
 ラベル:
 アプリ: nginx
 仕様:
 親和性
ポッドアンチアフィニティ
スケジュール中に必須、実行中に無視:
 - ラベルセレクター:
 一致表現:
 - キー: アプリ
演算子: In
 値：
 - nginx
 トポロジキー: kubernetes.io/ ホスト名
コンテナ
- イメージ: nginx : 1.8
 imagePullPolicy : IfNotPresent
 名前: nginx
 リソース：
 リクエスト:
 CPU : 0.5
 メモリ: 500 MB
 制限：
 CPU : 0.5
 メモリ: 500 MB
 準備プローブ:
 失敗しきい値: 3
 httpGet :
 パス： /
 ポート: http
 スキーム: HTTP
 初期遅延秒数: 10
 期間秒数: 10
 成功しきい値: 1
 タイムアウト秒数: 3
 ポート:
 - コンテナポート: 80
 名前: http
 プロトコル: TCP

これにより、新しいバージョンにアクセスできる場合にのみ外部トラフィックが受信されるようになります。

しかし、アプリケーションの実行中にエラーが発生した場合はどうでしょうか？そこで、livenessProbe がアプリケーションの継続的な可用性を確保するために役立ちます。上記の YAML は次のように変更できます。

 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ
ラベル:
 アプリ: nginx
 名前: nginx - デプロイメント
仕様:
 進捗期限秒数: 600
 レプリカ： 3
 改訂履歴制限: 10
 セレクター:
 マッチラベル
アプリ: nginx
 戦略：
 ローリングアップデート:
 最大サージ： 25 ％
 最大利用不可: 25 %
 タイプ: ローリングアップデート
テンプレート：
 メタデータ
作成タイムスタンプ: null
 ラベル:
 アプリ: nginx
 仕様:
 親和性
ポッドアンチアフィニティ
スケジュール中に必須、実行中に無視:
 - ラベルセレクター:
 一致表現:
 - キー: アプリ
演算子: In
 値：
 - nginx
 トポロジキー: kubernetes.io/ ホスト名
コンテナ
- イメージ: nginx : 1.8
 imagePullPolicy : IfNotPresent
 名前: nginx
 リソース：
 リクエスト:
 CPU : 0.5
 メモリ: 500 MB
 制限：
 CPU : 0.5
 メモリ: 500 MB
 準備プローブ:
 失敗しきい値: 3
 httpGet :
 パス： /
 ポート: http
 スキーム: HTTP
 初期遅延秒数: 10
 期間秒数: 10
 成功しきい値: 1
 タイムアウト秒数: 3
 ライブネスプローブ
失敗しきい値: 3
 httpGet :
 パス： /
 ポート: http
 スキーム: HTTP
 初期遅延秒数: 20
 期間秒数: 10
 成功しきい値: 1
 タイムアウト秒数: 3
 ポート:
 - コンテナポート: 80
 名前: http
 プロトコル: TCP

前述のreadinessProbeとlivenessProbeは、アプリケーションの動作中にその可用性を確保するためのものです。では、アプリケーション終了時に安全な終了を確保するにはどうすればよいでしょうか？

安全な終了とは、終了ロジックと終了信号が正常に処理できることを意味し、正常な終了とも呼ばれます。

正常な終了には、次の 2 つの一般的な解決策があります。

アプリケーション自体は SIGTERM シグナルを処理できます。
preStop フックを設定し、フック内でコンテナを正常に停止する方法を指定します。

アプリケーションがSIGTERMシグナルを処理できるかどうかはさておき（処理できると仮定します）、私たちの目標は正常な終了を支援することです。Kubernetesでは、preStopフックを使用してこれを支援します。上記のYAMLを次のように修正します。

 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ
ラベル:
 アプリ: nginx
 名前: nginx - デプロイメント
仕様:
 進捗期限秒数: 600
 レプリカ： 3
 改訂履歴制限: 10
 セレクター:
 マッチラベル
アプリ: nginx
 戦略：
 ローリングアップデート:
 最大サージ： 25 ％
 最大利用不可: 25 %
 タイプ: ローリングアップデート
テンプレート：
 メタデータ
作成タイムスタンプ: null
 ラベル:
 アプリ: nginx
 仕様:
 親和性
ポッドアンチアフィニティ
スケジュール中に必須、実行中に無視:
 - ラベルセレクター:
 一致表現:
 - キー: アプリ
演算子: In
 値：
 - nginx
 トポロジキー: kubernetes.io/ ホスト名
コンテナ
- イメージ: nginx : 1.8
 imagePullPolicy : IfNotPresent
 名前: nginx
 ライフサイクル
プレストップ:
 実行:
 指示：
 - /bin/ sh
 - - c
 - 睡眠15
 リソース：
 リクエスト:
 CPU : 0.5
 メモリ: 500 MB
 制限：
 CPU : 0.5
 メモリ: 500 MB
 準備プローブ:
 失敗しきい値: 3
 httpGet :
 パス： /
 ポート: http
 スキーム: HTTP
 初期遅延秒数: 10
 期間秒数: 10
 成功しきい値: 1
 タイムアウト秒数: 3
 ライブネスプローブ
失敗しきい値: 3
 httpGet :
 パス： /
 ポート: http
 スキーム: HTTP
 初期遅延秒数: 20
 期間秒数: 10
 成功しきい値: 1
 タイムアウト秒数: 3
 ポート:
 - コンテナポート: 80
 名前: http
 プロトコル: TCP

もちろん、これはあくまで一例です。実際の設定は企業の状況に合わせて調整する必要があります。例えば、ZooKeeperやNacosなどのレジストリセンターをご利用の場合は、レジストリセンターからサービスを削除する必要があります。

PDB

上記の構成により、Kubernetes でアプリケーションをスムーズに実行できるようになりますが、カーネルのアップグレードやサーバーの再起動など、ノードのメンテナンスが必要になることは避けられません。

さらに、すべてのアプリケーションが複数のレプリカを持つことができるわけではありません。kubectl drain を使用する際に、1つまたは複数のアプリケーションが破壊されて使用不能になるのを防ぐため、Kubernetes は PodDisruptionBudget (PDB) コントローラーを導入し、クラスター内で実行中の Pod の数を制御します。

PDB では、ポッドの数は主に 2 つのパラメータによって制御されます。

minAvailable: 利用可能な Pod の最小数を表します。Pod クラスター内で実行されている Pod の最小数、または実行中の Pod の総数に対する割合を示します。
maxUnavailable: 使用できない Pod の最大数を表します。これは、Pod クラスター内で使用できない状態にある Pod の最大数、または Pod の合計数に対する使用できない Pod の割合を示します。

注意: minAvailable と maxUnavailable は相互に排他的であり、つまり、一度に使用できるのはそのうちの 1 つだけです。

`kubectl drain` コマンドが PodDisruptionBudget コントローラーをサポートするようになりました。`kubectl drain` 操作中、クラスター内のアプリケーション POD の数は PodDisruptionBudget コントローラーによって決定され、サービス中断や SLA の低下を招くことなくアプリケーション POD が破棄されます。`kubectl drain` 実行時、または Pod がアクティブにエスケープする場合、Kubernetes は以下の基準に基づいて判断を行います。

minAvailable の値は 5 に設定されています。操作を実行するには、アプリケーション POD クラスターに少なくとも 5 つの正常で使用可能な POD が必要です。
minAvailable 設定は 30% に設定されています。操作を実行するには、アプリケーション POD クラスターに少なくとも 30% の正常で使用可能な POD が必要です。
maxUnavailable 設定は 5 に設定されています。アプリケーション POD クラスター内に使用できない POD が最大 5 個ある場合にのみ、操作を実行できます。
maxUnavailable 設定は 30% に設定されています。アプリケーション POD クラスター内で使用できない POD が最大 30% の場合にのみ、操作を実行できます。

極端なケース、例えば「maxUnavailable」を0または100%に設定すると、「kubectl drain」操作は実行できなくなります。同様に、「minAvailable」を100%またはアプリケーションのPODクラスター内のレプリカの最大数に設定した場合も、「kubectl drain」操作は実行されません。

注: PodDisruptionBudget コントローラーを使用しても、ビジネス POD クラスターがあらゆる状況下で制約されることは保証されません。PodDisruptionBudget コントローラーは、kubectldrain コマンドの実行時など、POD が能動的に制約から逸脱した場合にのみ、ビジネスが中断されず、ビジネス SLA が低下しないことを保証します。

1. minAvailable を定義します。

 apiバージョン: ポリシー/ v1
 種類: PodDisruptionBudget
 メタデータ
名前: pdb - デモ
仕様:
 最小利用可能数: 2
 セレクター:
 マッチラベル
アプリ: nginx

2. maxUnavailable を定義します。

 apiバージョン: ポリシー/ v1
 種類: PodDisruptionBudget
 メタデータ
名前: pdb - デモ
仕様:
 最大利用不可: 1
 セレクター:
 マッチラベル
アプリ: nginx

ご覧のとおり、PDBはアプリケーションPodとラベルセレクター間の接続を確立します。その後、Podをアクティブに削除する際に、app:nginxで利用できないPodの最大数が1であることを保証します。レプリカが3つある場合、少なくとも2つのレプリカが正常に動作することが保証されます。

要約

上記はKubernetesにおけるアプリケーションの単純な可用性保証のみを提供しています。本番環境では、アプリケーションは自身だけでなく、上流および下流のアプリケーションにも接続されます。そのため、アプリケーションの安定性を高めるには、エンドツーエンドのアプリケーション可用性保証が不可欠です。

DUICUO