Merge pull request #33213 from t-inu/set-heading-id-1

[ja] Set heading IDs concepts/configuration/manage-resources-containers.md

Author: k8s-ci-robot

content/ja/docs/concepts/configuration/manage-resources-containers.md

@@ -17,7 +17,7 @@ Pod内のコンテナのリソース*要求*を指定すると、スケジュー
 
 <!-- body -->
 
-## 要求と制限
+## 要求と制限 {#requests-and-limits}
 
 Podが動作しているNodeに利用可能なリソースが十分にある場合、そのリソースの`要求`が指定するよりも多くのリソースをコンテナが使用することが許可されます
 ただし、コンテナはそのリソースの`制限`を超えて使用することはできません。
@@ -33,7 +33,7 @@ Podが動作しているNodeに利用可能なリソースが十分にある場
 コンテナが自身のメモリー制限を指定しているが、メモリー要求を指定していない場合、Kubernetesは制限に一致するメモリー要求を自動的に割り当てます。同様に、コンテナが自身のCPU制限を指定しているが、CPU要求を指定していない場合、Kubernetesは制限に一致するCPU要求を自動的に割り当てます。
 {{< /note >}}
 
-## リソースタイプ
+## リソースタイプ {#resource-types}
 
 *CPU*と*メモリー*はいずれも*リソースタイプ*です。リソースタイプには基本単位があります。
 CPUは計算処理を表し、[Kubernetes CPUs](#meaning-of-cpu)の単位で指定されます。
@@ -54,7 +54,7 @@ CPUとメモリーは、まとめて*コンピュートリソース*または単
 それらは[API resources](/ja/docs/concepts/overview/kubernetes-api/)とは異なります。
 Podや[Services](/ja/docs/concepts/services-networking/service/)などのAPIリソースは、Kubernetes APIサーバーを介して読み取りおよび変更できるオブジェクトです。
 
-## Podとコンテナのリソース要求と制限
+## Podとコンテナのリソース要求と制限 {#resource-requests-and-limits-of-pod-and-container}
 
 Podの各コンテナは、次の1つ以上を指定できます。
 
@@ -68,9 +68,9 @@ Podの各コンテナは、次の1つ以上を指定できます。
 要求と制限はそれぞれのコンテナでのみ指定できますが、このPodリソースの要求と制限の関係性について理解すると便利です。
 特定のリソースタイプの*Podリソース要求/制限*は、Pod内の各コンテナに対するそのタイプのリソース要求/制限の合計です。
 
-## Kubernetesにおけるリソースの単位
+## Kubernetesにおけるリソースの単位 {#resource-units-in-kubernetes}
 
-### CPUの意味
+### CPUの意味 {#meaning-of-cpu}
 
 CPUリソースの制限と要求は、*cpu*単位で測定されます。
 Kuberenetesにおける1つのCPUは、クラウドプロバイダーの**1 vCPU/コア**およびベアメタルのインテルプロセッサーの**1 ハイパースレッド**に相当します。
@@ -85,7 +85,7 @@ Kuberenetesにおける1つのCPUは、クラウドプロバイダーの**1 vCPU
 CPUは常に相対量としてではなく、絶対量として要求されます。
 0.1は、シングルコア、デュアルコア、あるいは48コアマシンのどのCPUに対してでも、同一の量を要求します。
 
-### メモリーの意味
+### メモリーの意味 {#meaning-of-memory}
 
 `メモリー`の制限と要求はバイト単位で測定されます。
 E、P、T、G、M、Kのいずれかのサフィックスを使用して、メモリーを整数または固定小数点数として表すことができます。
@@ -128,15 +128,15 @@ spec:
         cpu: "500m"
 ```
 
-## リソース要求を含むPodがどのようにスケジュールされるか
+## リソース要求を含むPodがどのようにスケジュールされるか {#how-pods-with-resource-requests-are-scheduled}
 
 Podを作成すると、KubernetesスケジューラーはPodを実行するNodeを選択します。
 各Nodeには、リソースタイプごとに最大容量があります。それは、Podに提供できるCPUとメモリの量です。
 スケジューラーは、リソースタイプごとに、スケジュールされたコンテナのリソース要求の合計がNodeの容量より少ないことを確認します。
 Node上の実際のメモリーまたはCPUリソースの使用率は非常に低いですが、容量チェックが失敗した場合、スケジューラーはNodeにPodを配置しないことに注意してください。
 これにより、例えば日々のリソース要求のピーク時など、リソース利用が増加したときに、Nodeのリソース不足から保護されます。
 
-## リソース制限のあるPodがどのように実行されるか
+## リソース制限のあるPodがどのように実行されるか {#how-pods-with-resource-limits-are-run}
 
 kubeletがPodのコンテナを開始すると、CPUとメモリーの制限がコンテナランタイムに渡されます。
 
@@ -166,13 +166,13 @@ Dockerを使用する場合:
 
 コンテナをスケジュールできないか、リソース制限が原因で強制終了されているかどうかを確認するには、[トラブルシューティング](#troubleshooting)のセクションを参照してください。
 
-### コンピュートリソースとメモリーリソースの使用量を監視する
+### コンピュートリソースとメモリーリソースの使用量を監視する {#monitoring-compute-memory-resource-usage}
 
 Podのリソース使用量は、Podのステータスの一部として報告されます。
 
 オプションの[監視ツール](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)がクラスターにおいて利用可能な場合、Podのリソース使用量は[メトリクスAPI](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api)から直接、もしくは監視ツールから取得できます。
 
-## ローカルのエフェメラルストレージ
+## ローカルのエフェメラルストレージ {#local-ephemeral-storage}
 
 <!-- feature gate LocalStorageCapacityIsolation -->
 {{< feature-state for_k8s_version="v1.10" state="beta" >}}
@@ -192,7 +192,7 @@ Nodeに障害が発生すると、そのエフェメラルストレージ内の
 
 ベータ版の機能として、Kubernetesでは、Podが消費するローカルのエフェメラルストレージの量を追跡、予約、制限することができます。
 
-### ローカルエフェメラルストレージの設定
+### ローカルエフェメラルストレージの設定 {#configurations-for-local-ephemeral-storage}
 
 Kubernetesは、Node上のローカルエフェメラルストレージを構成する2つの方法をサポートしています。
 {{< tabs name="local_storage_configurations" >}}
@@ -235,7 +235,7 @@ kubeletは、ローカルストレージの使用量を測定できます。
 kubeletは、`tmpfs`のemptyDirボリュームをローカルのエフェメラルストレージとしてではなく、コンテナメモリーとして追跡します。
 {{< /note >}}
 
-### ローカルのエフェメラルストレージの要求と制限設定
+### ローカルのエフェメラルストレージの要求と制限設定 {#setting-requests-and-limits-for-local-ephemeral-storage}
 
 ローカルのエフェメラルストレージを管理するためには _ephemeral-storage_ パラメーターを利用することができます。
 Podの各コンテナは、次の1つ以上を指定できます。
@@ -288,7 +288,7 @@ spec:
       emptyDir: {}
 ```
 
-### エフェメラルストレージを要求するPodのスケジュール方法
+### エフェメラルストレージを要求するPodのスケジュール方法 {#how-pods-with-ephemeral-storage-requests-are-scheduled}
 
 Podを作成すると、KubernetesスケジューラーはPodを実行するNodeを選択します。
 各Nodeには、Podに提供できるローカルのエフェメラルストレージの上限があります。
@@ -375,7 +375,7 @@ Kubernetesが使用しないようにする必要があります。
 {{% /tab %}}
 {{< /tabs >}}
 
-## 拡張リソース
+## 拡張リソース {#extended-resources}
 
 拡張リソースは`kubernetes.io`ドメインの外で完全に修飾されたリソース名です。
 これにより、クラスタオペレータはKubernetesに組み込まれていないリソースをアドバタイズし、ユーザはそれを利用することができるようになります。
@@ -384,16 +384,16 @@ Kubernetesが使用しないようにする必要があります。
 第一に、クラスタオペレーターは拡張リソースをアドバタイズする必要があります。
 第二に、ユーザーはPodで拡張リソースを要求する必要があります。
 
-### 拡張リソースの管理
+### 拡張リソースの管理 {#managing-extended-resources}
 
-#### Nodeレベルの拡張リソース
+#### Nodeレベルの拡張リソース {#node-level-extended-resources}
 
 Nodeレベルの拡張リソースはNodeに関連付けられています。
 
-##### デバイスプラグイン管理のリソース
+##### デバイスプラグイン管理のリソース {#device-plugin-managed-resources}
 各Nodeにデバイスプラグインで管理されているリソースをアドバタイズする方法については、[デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)を参照してください。
 
-##### その他のリソース
+##### その他のリソース {#other-resources}
 新しいNodeレベルの拡張リソースをアドバタイズするには、クラスタオペレータはAPIサーバに`PATCH`HTTPリクエストを送信し、クラスタ内のNodeの`status.capacity`に利用可能な量を指定します。
 この操作の後、ノードの`status.capacity`には新しいリソースが含まれます。
 `status.allocatable`フィールドは、kubeletによって非同期的に新しいリソースで自動的に更新されます。
@@ -416,7 +416,7 @@ JSON-Patchの操作パス値は、JSON-Pointerとして解釈されます。
 詳細については、[IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3)を参照してください。
 {{< /note >}}
 
-#### クラスターレベルの拡張リソース
+#### クラスターレベルの拡張リソース {#cluster-level-extended-resources}
 
 クラスターレベルの拡張リソースはノードに関連付けられていません。
 これらは通常、リソース消費とリソースクォータを処理するスケジューラー拡張機能によって管理されます。
@@ -449,7 +449,7 @@ JSON-Patchの操作パス値は、JSON-Pointerとして解釈されます。
 }
 ```
 
-### 拡張リソースの消費
+### 拡張リソースの消費 {#consuming-extended-resources}
 
 ユーザーは、CPUやメモリのようにPodのスペックで拡張されたリソースを消費できます。
 利用可能な量以上のリソースが同時にPodに割り当てられないように、スケジューラーがリソースアカウンティングを行います。
@@ -493,9 +493,9 @@ spec:
         example.com/foo: 1
 ```
 
-## トラブルシューティング
+## トラブルシューティング {#troubleshooting}
 
-### failedSchedulingイベントメッセージが表示され、Podが保留中になる
+### failedSchedulingイベントメッセージが表示され、Podが保留中になる {#my-pods-are-pending-with-event-message-failedscheduling}
 
 スケジューラーがPodが収容されるNodeを見つけられない場合、場所が見つかるまでPodはスケジュールされないままになります。
 スケジューラーがPodの場所を見つけられないたびに、次のようなイベントが生成されます。
@@ -562,7 +562,7 @@ Allocated resources:
 [リソースクォータ](/docs/concepts/policy/resource-quotas/)機能は、消費できるリソースの総量を制限するように設定することができます。
 名前空間と組み合わせて使用すると、1つのチームがすべてのリソースを占有するのを防ぐことができます。
 
-### コンテナが終了した
+### コンテナが終了した {#my-container-is-terminated}
 
 コンテナはリソース不足のため、終了する可能性があります。
 コンテナがリソース制限に達したために強制終了されているかどうかを確認するには、対象のPodで`kubectl describe pod`を呼び出します。