Kubernetes を一緒に学ぶ: ワークロードのハイライト

容器

コンテナ:コンテナは、コンテナ イメージの実行状態です。これは標準のコンテナ ランタイム上で実行され、アプリケーションを基盤となるホスト機能から分離します。

コンテナ イメージ:コンテナ イメージは、アプリケーションの実行に必要なすべてのもの (コード、すべてのランタイム、アプリケーション、システム ライブラリ、およびいくつかの基本設定のデフォルト値) が含まれた、すぐに実行できるソフトウェア パッケージです。

コンテナ環境:コンテナ イメージに基づいて、ファイル システム、さまざまな環境変数、ホスト名、およびマウントされたさまざまなボリュームが組み合わさって、コンテナの実際の動作環境を構成します。

コンテナ ランタイム: Kubernetes 環境内のコンテナの実行とライフサイクルを管理し、コンテナ ランタイム インターフェース (CRI) を介して Kubernetes と対話します。

コンテナのライフサイクル中のコールバック:特定のランタイムは、PostStart (非同期) および PreStop (同期) コールバックをサポートします。

コンテナの更新とプル:コンテナ タグまたはサマリーを使用して更新するイメージ名を指定し、明確なプル ポリシー (IfNotPresent/Always) を使用することをお勧めします。イメージのプルを高速化するには、並列プルと事前プルを有効にすることを選択できます。同時に、資格情報を使用してプライベート リポジトリへのアクセスを保護する必要があります。

ポッド

Pod は、Kubernetes で作成および管理できる、展開可能な最小のコンピューティング ユニットです。

Pod 内のコンテナは、名前空間 (共有プロセス、ネットワーク、IPC、ホスト名) とファイル システム ボリュームを共有します。

Pod 内のコンテナは特権モードで実行され、通常はアクセスできないオペレーティング システム管理機能を使用できます。

通常、Pod を直接作成する必要はありません。代わりに、Deployment などのワークロード リソースを使用して Pod を作成する必要があります。

Pod の更新は「削除 - 再構築」パターンに従い、[*].image、activeDeadlineSeconds、および tolerations のみを更新できます。

ポッドのライフサイクル

Pod は 1 回限りのスケジュール ユニットです。再スケジュールと再開は、古いものを削除して新しいものを作成するという戦略に基づいています。

ポッドには、保留中、実行中、成功、失敗、不明の 5 つの状態があります。コンテナには、待機中、実行中、終了の 5 つの状態があります。

バージョン 1.29 では、コンテナの準備完了と Pod の準備完了をより詳細に区別するために、Pod Ready 状態が追加されました。

ポッド検出: StartupProbe (開始されているかどうか)、livenessProbe (稼働中かどうか)、ReadlinessProbe (準備完了かどうか)。

Pod は正常な停止をサポートします。 Pod を削除すると、まず Term 信号が送信され、Pod 内のサービスにリクエストの排出を開始するように促します。デフォルトでは、30 秒経過しても Pod が終了しない場合は、KILL 信号が送信され、Pod が強制的に強制終了します。

kubectl delete --force は強制削除をトリガーします。

PodGC コントローラーは予期しない Pod を自動的にリサイクルします。

init コンテナは、Pod 内のアプリケーション コンテナが起動する前に実行される特別なコンテナです。 Pod に複数の Init コンテナが指定されている場合は、ネットワークとデータ ボリュームが初期化された後、それらのコンテナが順番に 1 つずつ実行されます。

次の Init コンテナを実行する前に、各 Init コンテナが正常に実行されている必要があります。すべての Init コンテナの実行が終了すると、Kubernetes は Pod のアプリケーション コンテナを初期化し、通常どおり実行します。

Pod が再起動された場合、すべての Init コンテナを再実行する必要があります。 Init コンテナは再起動、再試行、または再実行される可能性があるため、Init コンテナ内のコードはべき等である必要があります。

Pod 内のリソース要求/制限の有効値 = max (init コンテナ内のリソース要求/制限の最大値とアプリケーション コンテナ内のリソース要求/制限の合計)。スケジュールと管理は、Pod の有効なリソース値に基づいて行われます。

サイドカー コンテナは、init コンテナの起動シーケンスに従う特別な常駐 init コンテナです。 Init コンテナを作成するときに、restartPolicy を Always に設定すると、サイドカー コンテナになります。これは Pod のライフサイクル全体を通じてアクティブであり、メイン コンテナとは独立して開始および停止できます。独立したライフサイクルを持ち、ライフサイクルを制御するためのプローブをサポートします。

一時コンテナは、トラブルシューティングなどのユーザーが開始した操作を完了するために、既存のポッド内で一時的に実行できます。コンテナがクラッシュしたか、コンテナ イメージにデバッグ ツールが含まれていないために kubectl exec が役に立たない場合、エフェメラル コンテナは対話型のトラブルシューティングに役立ちます。 kubectl debug は一時コンテナを使用して実装されており、distroless イメージのトラブルシューティングに非常に役立ちます。使用する場合、共有プロセス名前空間が必要であることに注意してください。

ノードのリソースが不足すると、Kubernetes はまずノード上で実行されている BestEffort Pod を削除し、次に Burstable Pod、最後に Guaranteed Pod を削除します。

保証されたポッド: ポッド内のすべてのコンテナにリソース要求と制限が設定されており、値は同じです。 Burstable Pod: Pod 内の少なくとも 1 つのコンテナーにリソース要求/制限が設定されています。 BestEffort Pod: Pod 内のどのコンテナにもリソース要求/制限が設定されていません。

障害予算 (PDB) は、予期しない Pod の終了を防ぐために、アプリケーションが許容できるレプリカの数 (必要なレプリカの数に相当) を指定します。

ローリング アップグレードを実行する場合、PDB に制限はありません。更新時の処理方法は、対応するワークロード リソースの仕様で構成されます。

PodDisruptionConditions は、Pod が終了した理由を示します。

Kubernetes では、実行中のコンテナに Pod フィールドと Container フィールドを公開する方法が 2 つあります。

• 環境変数としては、これが最もよく使われる
• 下向きAPIボリューム内のファイルとして

  Pod およびコンテナ フィールドを公開するこれら 2 つの方法は、総称して Downward API と呼ばれます。通常、springboot などの最新の開発フレームワークは、多くの Pod およびコンテナ情報を自動的に識別できます。詳細については各フレームワークを参照してください。最も一般的に使用されるアプリケーションは、ログ ファイル名の設定やレジストリへの登録に使用される Podname または IP アドレスを取得するための環境変数ソリューションです。これら 2 つの情報 (HOSTNAME と XXX_SERVICE_HOST) は通常デフォルトで使用可能であり、追加の挿入は必要ありません。必要に応じて他の情報も挿入する必要があります。

作業負荷

展開

デプロイメントは、Pod と ReplicaSet の宣言的な更新機能を提供します。

Deployment は、Pod と ReplicaSet の宣言的な更新機能を提供し、Pod の更新、ロールバック、スケーリング、その他の操作を含む Pod とサービスを自動的に管理できるようにします。

Deployment が更新されるたびに、新しい ReplicaSet が開始され、ReplicaSet によって対応する Pod がデプロイされます。

命名規則: Deployment の名前は .metadata.name で指定され、ReplicaSet の名前は .metadata.name-Pod-template-hash で構成されます。コードを確認すると、Pod 名は ReplicaSet 名にランダムな 5 文字が追加されたものであることがわかります。

デプロイメントの更新は、テンプレートのラベルやコンテナ イメージが更新されたときなど、デプロイメント ポッド テンプレート (.spec.template) が変更された場合にのみトリガーされます。

API バージョン apps/v1 では、デプロイメント ラベル セレクターは作成後に変更できず、 .spec.selector は .spec.template.metadata.labels と一致する必要があります。一致しない場合、リクエストは API によって拒否されます。

デプロイメントが更新され、再度更新されると、デプロイメントは更新用に新しいレプリカセットを作成し、スケールアップを開始します。以前にスケールアップされていたレプリカセットはスケールダウンされ、古いレプリカセット リストに追加され、スケールダウンが開始されます。

.spec.strategy.type==Recreate の場合、新しい Pod を作成する前に既存の Pod がすべて強制終了されます。 .spec.strategy.type==RollingUpdate の場合、Pod はローリング アップデート方式で更新されます。 maxUnavailable と maxSurge を指定して、ローリング更新プロセスを制御できます。デフォルト値は 25% です。

デプロイメントでは比例スケーリングがサポートされます。更新プロセスでデプロイメントに複数のレプリカセットがある場合、スケーリングは最新の RS 内のすべてのポッドではなく、現在の RS 内のポッドの数に比例します。

デプロイメントの更新前または更新中に、更新を一時停止し、さまざまな情報を変更し、実行を再開することができます。このとき、最新の修正アップデートが自動的に適用されます。

デフォルトでは、デプロイメントは最新の 10 個の ReplicaSet レコードを保持し、最新の 10 個の変更へのロールバックをサポートできます。すべての過去の YAML 変更を記録するには、git を使用することをお勧めします。

デプロイメントの状態には、「進行中」、「完了」、「失敗」の 3 つがあります。

デプロイメントは実際にはカナリア リリースをサポートしておらず、カナリア リリース機能を実装するには、デプロイメントの追加またはより高度な制御が必要です。

ステートフルセット

StatefulSet は、ステートフルアプリケーションを管理するために使用されるワークロード API オブジェクトです。一連の Pod のデプロイメントとスケーリングを管理し、これらの Pod に次のような永続的なストレージと永続的な識別子を提供できます。

• 安定した一意のネットワーク識別子
• 安定した永続的なストレージ
• 秩序正しく優雅な展開とスケーリング
• 順序付けられた自動ローリングアップデート

主な機能は次のとおりです。

序数: N 個のレプリカを持つ StatefulSet の場合、StatefulSet 内の各 Pod には、StatefulSet 内で一意の整数の序数が割り当てられます。デフォルトでは、ポッドには 0 から N-1 までの番号が付けられます。

ホスト ID: StatefulSet 内の各 Pod は、StatefulSet 名と Pod の序数に基づいて、$(StatefulSet 名)-$(序数) の形式でホスト名を派生します。

ネットワーク ID: $(podname).$(servicename).$(namespace).svc.cluster.local の形式で Pod のネットワーク ID を提供するヘッドレス サービスを作成する必要があります。

永続ストレージ: StatefulSet で定義された VolumeClaimTemplate の場合、各 Pod は PersistentVolumeClaim を受け取ります。 Pod または StatefulSet が削除されても、PersistentVolumeClaims に関連付けられている PersistentVolume は削除されないため、手動で削除する必要があります。

デプロイメント順序: N 個のレプリカを持つ StatefulSet の場合、Pod がデプロイされると、0..N-1 の順序で順番に作成されます。 Pod が削除される場合、N-1..0 の順序で逆の順序で削除されます。スケーリング操作が Pod に適用される前に、その前のすべての Pod が実行中かつ準備完了の状態である必要があります。 Pod が終了する前に、すべての後継 Pod を正常にシャットダウンする必要があります。

ローリング アップデート: StatefulSet コントローラーは、Pod が終了したのと同じ順序 (最高順序から最低順序へ) で StatefulSet 内の各 Pod を削除して再作成し、各 Pod を 1 つずつ更新します。

ローリング アップデートの例外処理:アップデート後に Pod テンプレート構成が実行できない状態または準備完了状態になった場合、StatefulSet はロールバックを停止して待機します。テンプレートを復元した後、StatefulSet は破損した Pod が準備完了になるまで待機し続けます (これは決して起こりません)。その時点で、StatefulSet が誤った構成で実行しようとしていた Pod を削除してから、StatefulSet が復元されたテンプレートを使用して Pod の再作成を開始する必要があります (既知の問題 kubernetes/issues/67250)。

volumeClaimTemplate からの PVC のデフォルト ポリシーでは、Pod が削除されても影響を受けず、残ります。

デーモンセット

DaemonSet は Deployment と非常に似ていますが、DaemonSet は Pod のコピーがすべての (または一部の) ノードで実行されることを保証します。ノードがクラスターに参加すると、そのノードにポッドが追加されます。ノードがクラスターから削除されると、これらのポッドもリサイクルされます。 DaemonSet を削除すると、作成されたすべての Pod が削除されます。

• DaemonSet は、監視やログ収集コンポーネントなどの運用および保守ツールの導入に適しています。
• DaemonSet は .spec.template.spec.nodeSelector および .spec.template.spec.affinity 制約に従い、ノード アフィニティを満たすノードにのみ Pod をデプロイします。指定しない場合は、DaemonSet コントローラーがすべてのノードに Pod を作成します。
• .spec.template.spec.affinity.nodeAffinity フィールドで指定されたノード アフィニティは、スケジューラによって適格なノードを評価するときに DaemonSet コントローラによって考慮されますが、作成された Pod 上の適格なノード名と一致するノード アフィニティに置き換えられます。
• DaemonSet コントローラーは、DaemonSet Pod に許容セットを自動的に追加し、正常でない、準備ができていない、到達できない、スケジュールできない、リソース使用量が低いノードなど、正常でないノードや Pod を受け入れる準備ができていないノードにスケジュールできるようにします。
• DaemonSet のデフォルトの更新戦略はローリング更新です。

仕事

ジョブは 1 つ以上のポッドを作成し、指定された数のポッドが正常に終了するまでポッドの実行を再試行し続けます。ポッドが正常に完了すると、ジョブは正常に完了したポッドの数を追跡します。数が指定された成功しきい値に達すると、タスク (つまりジョブ) は終了します。

• ジョブは 1 つ以上のポッドを作成し、指定された数のポッドが正常に終了するまでポッドの実行を再試行し続けます。ポッドが正常に完了すると、ジョブは正常に完了したポッドの数を追跡します。数が指定された成功しきい値に達すると、タスク (つまりジョブ) は終了します。
• ジョブを一時停止する操作により、ジョブが再開されるまで (新しいポッドが再度実行のためにスケジュールされるまで)、ジョブのすべてのアクティブなポッド (部分的に実行されている可能性あり) が削除されます。
• ジョブを削除すると、作成されたすべてのポッドがクリアされます。
• 通常、ラベルとセレクターはジョブ仕様では設定されず、RestartPolicy は Never または OnFailure にのみ設定できます。 spec.completions と spec.parallelism は、補完の数と並列処理の数を表します。デフォルト値は両方とも 1 であり、タスクに必要な完了数と並列処理数に応じて設定できます。
• コンテナの障害: Pod 内のコンテナの実行に失敗した場合、RestartPolicy=OnFailure のときにコンテナが再起動されます。 RestartPolicy=Never の場合、コンテナは再起動されず、Pod のステータスは直接 Failed に変更されます。
• ポッドの障害: ジョブは新しいポッドの実行を再スケジュールするため、プログラムはべき等性の問題を処理する必要があります。
• Pod 失敗バックオフ戦略: .spec.backoffLimit は、ジョブが失敗するまでの Pod 再試行回数を設定します。デフォルト値は 6 です。バックオフ再試行時間は、最大 6 分まで指数関数的に増加します (10 秒、20 秒、40 秒)。
• Pod 障害回数統計方法: 最初の方法は、Pod ステータスが Failed であるが、RestartPolicy=OnFailure でコンテナを再起動する Pod の場合、コンテナ障害回数も Pod 障害回数としてカウントされるというものです。失敗回数が .spec.backoffLimit を超えると、ジョブのステータスは失敗に設定されます。
• .spec.podFailurePolicy フィールドは、コンテナの終了コードと Pod ステータスに基づいて Pod の障害を処理できる Pod 障害ポリシーの構成をサポートします。
• ジョブが完了すると (成功か失敗かに関係なく)、新しいポッドは作成されませんが、既存のポッドも通常は削除されません。これらの Pod を保持しておくと、完了した Pod のログ出力を確認して、エラー、警告、その他の診断出力をチェックできます。ジョブが完了すると、ジョブ オブジェクトも保持されるため、そのステータスを検査できます。ジョブのステータスを確認した後、古いジョブを削除するかどうかはユーザーに任されます。
• 完了したジョブ (ステータスが完了または失敗) を自動的にクリーンアップする 1 つの方法は、TTL コントローラによって提供される TTL メカニズムを使用することです。ジョブの .spec.ttlSecondsAfterFinished フィールドを設定することで、コントローラーが完了したリソースをクリーンアップすることができます。
• ジョブの .spec.activeDeadlineSeconds に秒単位で値を設定できます。この値はジョブのライフサイクル全体に適用されます。ジョブがいくつのポッドを作成するかに関係なく、ジョブの実行時間が activeDeadlineSeconds 秒に達すると、実行中のすべてのポッドが終了し、ジョブのステータスがタイプ: Failed、理由: DeadlineExceeded に更新されます。

クローンジョブ

CronJob は、時間間隔に基づいて繰り返しスケジュールされるジョブを作成します。 CronJob は、バックアップ、レポート生成などのスケジュールされた操作を実行するために使用されます。CronJob オブジェクトは、Unix システムの crontab (cron テーブル) ファイル内の行のようなものです。これは Cron 形式で記述されており、指定されたスケジュール時間に定期的にジョブを実行します。

 # ┌───────────── 分钟(0 - 59) # │ ┌───────────── 小时(0 - 23) # │ │ ┌───────────── 月的某天(1 - 31) # │ │ │ ┌───────────── 月份(1 - 12) # │ │ │ │ ┌───────────── 周的某天(0 - 6)（周日到周六） # │ │ │ │ │ 或者是sun，mon，tue，web，thu，fri，sat # │ │ │ │ │ # │ │ │ │ │ # * * * * *

CronJob は、時間間隔の繰り返しスケジュールに基づいてジョブを作成します。このジョブは、ポッドの生成と実行のスケジュール設定を担当します。

CronJob は、バックアップ、レポート生成などのスケジュールされた操作を実行するために使用されます。CronJob オブジェクトは、Unix システムの crontab (cron テーブル) ファイル内の行のようなものです。これは Cron 形式 (毎日、毎月、毎週) で記述され、指定されたスケジュール時間に定期的にジョブを実行します。

CronJob はタイムゾーン設定をサポートしており、デフォルトのタイムゾーンはローカルタイムゾーンです。

CronJob の変更は、その後に作成されるジョブに対してのみ有効です。

サポートされている同時スケジューリング戦略は 3 つあります: {"Allow":"同時実行を許可する","Forbid":"許可しない","Replace":"スケジュールのオーバーライド"}、デフォルトは Allow です。

失敗したスケジュールをカウントするための開始時刻を示す spec.startingDeadlineSeconds を設定することをお勧めします。デフォルトでは、スケジュールが実行できなかった回数は、最後のスケジュール時刻からカウントされます (回数が 100 を超えると、スケジュールは実行されません)。

CronJob 仕様はジョブ テンプレートであり、他のコントローラーはテンプレートです。 Job コントローラーも CronJob コントローラーも、ラベルとセレクターを定義する必要はありません。コントローラーはそれらを自動的に追加し、一致を保証します。