Change:
Podのコンテナは準備完了ですが、少なくとも1つのカスタムのConditionが欠落しているか「False」の場合、kubeletはPodの[Condition](#pod-condition)を`ContainersReady`に設定します。 <ins> ### PodのネットワークのReadiness {#pod-has-network} {{< feature-state for_k8s_version="v1.25" state="alpha" >}} Podがノードにスケジュールされた後、kubeletによって承認され、任意のボリュームがマウントされる必要があります。これらのフェーズが完了すると、kubeletはコンテナランタイム({{< glossary_tooltip term_id="cri" >}}を使用)と連携して、ランタイムサンドボックスのセットアップとPodのネットワークを構成します。もし`PodHasNetworkCondition`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効になっている場合、kubeletは、Podがこの初期化の節目に到達したかどうかをPodの`status.conditions`フィールドにある`PodHasNetwork`状態を使用して報告します。 ネットワークが設定されたランタイムサンドボックスがPodにないことを検出すると、`PodHasNetwork`状態は、kubelet によって`False`に設定されます。これは、以下のシナリオで発生します: * Podのライフサイクルの初期で、kubeletがコンテナランタイムを使用してPodのサンドボックスのセットアップをまだ開始していないとき * Podのライフサイクルの後期で、Podのサンドボックスが以下のどちらかの原因で破壊された場合: * Podを退去させず、ノードが再起動する * コンテナランタイムの隔離に仮想マシンを使用している場合、Podサンドボックスの仮想マシンが再起動し、新しいサンドボックスと新しいコンテナネットワーク設定を作成する必要があります ランタイムプラグインによるサンドボックスの作成とPodのネットワーク設定が正常に完了すると、kubeletによって`PodHasNetwork`状態が`True`に設定されます。`PodHasNetwork`状態が`True`に設定された後、kubeletはコンテナイメージの取得とコンテナの作成を開始することができます。 initコンテナを持つPodの場合、initコンテナが正常に完了すると(ランタイムプラグインによるサンドボックスの作成とネットワーク設定が正常に行われた後に発生)、kubeletは`Initialized`状態を`True`に設定します。initコンテナがないPodの場合、サンドボックスの作成およびネットワーク設定が開始する前にkubeletは`Initialized`状態を`True`に設定します。 </ins> ## コンテナのProbe {#container-probes} <del> [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/reference/command-line-tools-reference/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります: </del> <ins> *Probe*は[kubelet](/docs/reference/command-line-tools-reference/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナ内でコードを実行するか、ネットワークリクエストします。 </ins> <del> * [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。 </del> <ins> ### チェックのメカニズム {#probe-check-methods} </ins> <del> * [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): PodのIPの特定のポートにTCPチェックを行います。 そのポートが空いていれば診断を成功とみなします。 </del> <ins> probeを使ってコンテナをチェックする4つの異なる方法があります。 各probeは、この4つの仕組みのうち1つを正確に定義する必要があります: `exec` : コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見なします。 `grpc` : [gRPC](https://grpc.io/)を使ってリモートプロシージャコールを実行します。 ターゲットは、[gRPC health checks](https://grpc.io/grpc/core/md_doc_health-checking.html)を実装する必要があります。 レスポンスの`status`が`SERVING`の場合に診断を成功と見なします。 gRPCはアルファ版の機能のため、`GRPCContainerProbe`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が 有効の場合のみ利用可能です。 </ins> <del> * [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): PodのIPの特定のポートとパスに対して、HTTP GETのリクエストを送信します。 </del> <ins> `httpGet` : PodのIPアドレスに対して、指定されたポートとパスでHTTP `GET`のリクエストを送信します。 </ins> レスポンスのステータスコードが200以上400未満の際に診断を成功とみなします。 <ins> `tcpSocket` : PodのIPアドレスに対して、指定されたポートでTCPチェックを行います。 そのポートが空いていれば診断を成功とみなします。 オープンしてすぐにリモートシステム(コンテナ)が接続を切断した場合、健全な状態としてカウントします。 ### Probeの結果 {#probe-outcome} </ins> 各Probe 次の3つのうちの一つの結果を持ちます: <del> * `Success`: コンテナの診断が成功しました。 * `Failure`: コンテナの診断が失敗しました。 * `Unknown`: コンテナの診断が失敗し、取れるアクションがありません。 </del> <ins> `Success` : コンテナの診断が成功しました。 `Failure` : コンテナの診断が失敗しました。 `Unknown` : コンテナの診断が失敗しました(何も実行する必要はなく、kubeletはさらにチェックを行います)。 ### Probeの種類 {#types-of-probe} </ins> <del> Kubeletは3種類のProbeを実行中のコンテナで行い、また反応することができます: </del> <ins> kubeletは3種類のProbeを実行中のコンテナで行い、また反応することができます: </ins> <del> * `livenessProbe`: コンテナが動いているかを示します。 livenessProbe に失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 コンテナにlivenessProbeが設定されていない場合、デフォルトの状態は`Success`です。 </del> <ins> `livenessProbe` : コンテナが動いているかを示します。 livenessProbeに失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 コンテナにlivenessProbeが設定されていない場合、デフォルトの状態は`Success`です。 </ins> <del> * `readinessProbe`: コンテナがリクエスト応答する準備ができているかを示します。 readinessProbeに失敗すると、エンドポイントコントローラーにより、ServiceからそのPodのIPアドレスが削除されます。 initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。 コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。 </del> <ins> `readinessProbe` : コンテナがリクエスト応答する準備ができているかを示します。 readinessProbeに失敗すると、エンドポイントコントローラーにより、ServiceからそのPodのIPアドレスが削除されます。 initial delay前のデフォルトのreadinessProbeの初期値は`Failure`です。 コンテナにreadinessProbeが設定されていない場合、デフォルトの状態は`Success`です。 </ins> <del> * `startupProbe`: コンテナ内のアプリケーションが起動したかどうかを示します。 startupProbeが設定された場合、完了するまでその他のすべてのProbeは無効になります。 startupProbeに失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 コンテナにstartupProbeが設定されていない場合、デフォルトの状態は`Success`です。 </del> <ins> `startupProbe` : コンテナ内のアプリケーションが起動したかどうかを示します。 startupProbeが設定された場合、完了するまでその他のすべてのProbeは無効になります。 startupProbeに失敗すると、kubeletはコンテナを殺します、そしてコンテナは[restart policy](#restart-policy)に従います。 コンテナにstartupProbeが設定されていない場合、デフォルトの状態は`Success`です。 </ins> livenessProbe、readinessProbeまたはstartupProbeを設定する方法の詳細については、[Liveness Probe、Readiness ProbeおよびStartup Probeを使用する](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。 <del> ### livenessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe} </del> <ins> #### livenessProbeをいつ使うべきか? {#when-should-you-use-a-liveness-probe} </ins> {{< feature-state for_k8s_version="v1.0" state="stable" >}} <del> コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができればlivenessProbeは不要です. </del> <ins> コンテナ自体に問題が発生した場合や状態が悪くなった際にクラッシュすることができればlivenessProbeは不要です。 </ins> この場合kubeletが自動でPodの`restartPolicy`に基づいたアクションを実行します。 Probeに失敗したときにコンテナを殺したり再起動させたりするには、livenessProbeを設定し`restartPolicy`をAlwaysまたはOnFailureにします。 <del> ### readinessProbeをいつ使うべきか? {#when-should-you-use-a-readiness-probe} </del> <ins> #### readinessProbeをいつ使うべきか? {#when-should-you-use-a-readiness-probe} </ins> {{< feature-state for_k8s_version="v1.0" state="stable" >}} Probeが成功したときにのみPodにトラフィックを送信したい場合は、readinessProbeを指定します。 <del> この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。コンテナが起動時に大きなデータ、構成ファイル、またはマイグレーションを読み込む必要がある場合は、readinessProbeを指定します。 </del> <ins> この場合readinessProbeはlivenessProbeと同じになる可能性がありますが、readinessProbeが存在するということは、Podがトラフィックを受けずに開始され、Probe成功が開始した後でトラフィックを受け始めることになります。 </ins> コンテナがメンテナンスのために停止できるようにするには、livenessProbeとは異なる、特定のエンドポイントを確認するreadinessProbeを指定することができます。 <ins> アプリがバックエンドサービスと厳密な依存関係にある場合、livenessProbeとreadinessProbeの両方を実装することができます。アプリ自体が健全であればlivenessProbeはパスしますが、readinessProbeはさらに、必要なバックエンドサービスが利用可能であるかどうかをチェックします。これにより、エラーメッセージでしか応答できないPodへのトラフィックの転送を避けることができます。 コンテナの起動中に大きなデータ、構成ファイル、またはマイグレーションを読み込む必要がある場合は、[startupProbe](#when-should-you-use-a-startup-probe)を使用できます。ただし、失敗したアプリと起動データを処理中のアプリの違いを検出したい場合は、readinessProbeを使用した方が良いかもしれません。 </ins> {{< note >}} Podが削除されたときにリクエストを来ないようにするためには必ずしもreadinessProbeが必要というわけではありません。Podの削除時にはreadinessProbeが存在するかどうかに関係なくPodは自動的に自身をunreadyにします。Pod内のコンテナが停止するのを待つ間Podはunreadyのままです。 {{< /note >}} <del> ### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe} </del> <ins> #### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe} </ins> <del> {{< feature-state for_k8s_version="v1.18" state="beta" >}} </del> <ins> {{< feature-state for_k8s_version="v1.20" state="stable" >}} </ins> startupProbeは、サービスの開始に時間がかかるコンテナを持つPodに役立ちます。livenessProbeの間隔を長く設定するのではなく、コンテナの起動時に別のProbeを構成して、livenessProbeの間隔よりも長い時間を許可できます。 <del> コンテナの起動時間が、`initialDelaySeconds + failureThreshold x periodSeconds`よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。`periodSeconds`のデフォルトは30秒です。次に、`failureThreshold`をlivenessProbeのデフォルト値を変更せずにコンテナが起動できるように、十分に高い値を設定します。これによりデッドロックを防ぐことができます。 </del> <ins> コンテナの起動時間が、`initialDelaySeconds + failureThreshold x periodSeconds`よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。`periodSeconds`のデフォルトは10秒です。次に、`failureThreshold`をlivenessProbeのデフォルト値を変更せずにコンテナが起動できるように、十分に高い値を設定します。これによりデッドロックを防ぐことができます。 </ins> ## Podの終了 {#pod-termination}

Discussion:
This is a Feature Request What would you like to be We need to update content/ja/docs/concepts/workloads/pods/pod- according to the English text, because it is outdated. Why is this needed content/ja/docs/concepts/workloads/pods/pod- is outdated. For example, there is no description of PodHasNetwork(alpha feature). Comments /language ja /assign
/triage accepted