File tree Expand file tree Collapse file tree 10 files changed +16
-16
lines changed
overview/working-with-objects
contribute/style/hugo-shortcodes
setup/production-environment Expand file tree Collapse file tree 10 files changed +16
-16
lines changed Original file line number Diff line number Diff line change @@ -35,7 +35,7 @@ kubeconfigファイルを使用すると、クラスター、ユーザー、名
35
35
36
36
## Context
37
37
38
- kubeconfigファイルの* context* 要素は、アクセスパラメーターを使いやすい名前でグループ化するために使われます。各contextは3つのパラメータ 、cluster、namespace、userを持ちます。デフォルトでは、` kubectl ` コマンドラインツールはクラスターとの通信に* current context* のパラメーターを使用します。
38
+ kubeconfigファイルの* context* 要素は、アクセスパラメーターを使いやすい名前でグループ化するために使われます。各contextは3つのパラメーター 、cluster、namespace、userを持ちます。デフォルトでは、` kubectl ` コマンドラインツールはクラスターとの通信に* current context* のパラメーターを使用します。
39
39
40
40
current contextを選択するには、以下のコマンドを使用します。
41
41
Original file line number Diff line number Diff line change @@ -167,7 +167,7 @@ partition
167
167
168
168
# ## LISTとWATCHによるフィルタリング
169
169
170
- LISTとWATCHオペレーションは、単一のクエリパラメータを使うことによって返されるオブジェクトのセットをフィルターするためのラベルセレクターを指定できます 。
170
+ LISTとWATCHオペレーションは、単一のクエリパラメーターを使うことによって返されるオブジェクトのセットをフィルターするためのラベルセレクターを指定できます 。
171
171
*集合ベース* と*等価ベース* のどちらの要件も許可されています(ここでは、URLクエリストリング内で出現します)。
172
172
173
173
* *等価ベース* での要件: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
Original file line number Diff line number Diff line change @@ -375,7 +375,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
375
375
### セキュリティポリシーとセキュリティコンテキストの違いは何ですか?
376
376
377
377
[ Security Context] ( /docs/tasks/configure-pod-container/security-context/ ) は実行時のコンテナやPodを設定するものです。
378
- Security ContextはPodのマニフェストの中でPodやコンテナの仕様の一部として定義され、コンテナランタイムへ渡されるパラメータを示します 。
378
+ Security ContextはPodのマニフェストの中でPodやコンテナの仕様の一部として定義され、コンテナランタイムへ渡されるパラメーターを示します 。
379
379
380
380
セキュリティポリシーはコントロールプレーンの機構で、Security Contextとそれ以外も含め、特定の設定を強制するものです。
381
381
2020年2月時点では、ネイティブにサポートされているポリシー強制の機構は[ Pod Security
Original file line number Diff line number Diff line change @@ -17,8 +17,8 @@ weight: 40
17
17
18
18
## バックグラウンド
19
19
20
- ボリュームの動的プロビジョニングの実装は` storage.k8s.io ` というAPIグループ内の` StorageClass ` というAPIオブジェクトに基づいています。クラスター管理者は` StorageClass ` オブジェクトを必要に応じていくつでも定義でき、各オブジェクトはボリュームをプロビジョンする* Volumeプラグイン* (別名* プロビジョナー* )と、プロビジョンされるときにプロビジョナーに渡されるパラメータを指定します 。
21
- クラスター管理者はクラスター内で複数の種類のストレージ(同一または異なるストレージシステム)を定義し、さらには公開でき、それらのストレージはパラメータのカスタムセットを持ちます 。この仕組みにおいて、エンドユーザーはストレージがどのようにプロビジョンされるか心配する必要がなく、それでいて複数のストレージオプションから選択できることを保証します。
20
+ ボリュームの動的プロビジョニングの実装は` storage.k8s.io ` というAPIグループ内の` StorageClass ` というAPIオブジェクトに基づいています。クラスター管理者は` StorageClass ` オブジェクトを必要に応じていくつでも定義でき、各オブジェクトはボリュームをプロビジョンする* Volumeプラグイン* (別名* プロビジョナー* )と、プロビジョンされるときにプロビジョナーに渡されるパラメーターを指定します 。
21
+ クラスター管理者はクラスター内で複数の種類のストレージ(同一または異なるストレージシステム)を定義し、さらには公開でき、それらのストレージはパラメーターのカスタムセットを持ちます 。この仕組みにおいて、エンドユーザーはストレージがどのようにプロビジョンされるか心配する必要がなく、それでいて複数のストレージオプションから選択できることを保証します。
22
22
23
23
StorageClassに関するさらなる情報は[ Storage Class] ( /docs/concepts/storage/storage-classes/ ) を参照ください。
24
24
Original file line number Diff line number Diff line change @@ -53,7 +53,7 @@ Kubernetesは古い容量の情報をもとにノードを選択する場合が
53
53
54
54
## ストレージ容量の追跡を有効にする {#enabling-storage-capacity-tracking}
55
55
56
- ストレージ容量の追跡は* アルファ機能* であり、` CSIStorageCapacity ` [ フィーチャーゲート] ( /ja/docs/reference/command-line-tools-reference/feature-gates/ ) と` storage.k8s.io/v1alpha1 ` {{< glossary_tooltip text="API group" term_id="api-group" >}}を有効にした場合にのみ、有効化されます。詳細については、` --feature-gates ` および` --runtime-config ` [ kube-apiserverパラメータ ] ( /docs/reference/command-line-tools-reference/kube-apiserver/ ) を参照してください。
56
+ ストレージ容量の追跡は* アルファ機能* であり、` CSIStorageCapacity ` [ フィーチャーゲート] ( /ja/docs/reference/command-line-tools-reference/feature-gates/ ) と` storage.k8s.io/v1alpha1 ` {{< glossary_tooltip text="API group" term_id="api-group" >}}を有効にした場合にのみ、有効化されます。詳細については、` --feature-gates ` および` --runtime-config ` [ kube-apiserverパラメーター ] ( /docs/reference/command-line-tools-reference/kube-apiserver/ ) を参照してください。
57
57
58
58
Kubernetesクラスターがこの機能をサポートしているか簡単に確認するには、以下のコマンドを実行して、CSIStorageCapacityオブジェクトを一覧表示します。
59
59
Original file line number Diff line number Diff line change @@ -49,7 +49,7 @@ deletionPolicyが`Delete`の場合、元となるストレージスナップシ
49
49
50
50
# # Parameters
51
51
52
- VolumeSnapshotClassは、そのクラスに属するVolumeSnapshotを指定するパラメータを持っています 。
53
- ` driver` に応じて様々なパラメータを使用できます 。
52
+ VolumeSnapshotClassは、そのクラスに属するVolumeSnapshotを指定するパラメーターを持っています 。
53
+ ` driver` に応じて様々なパラメーターを使用できます 。
54
54
55
55
Original file line number Diff line number Diff line change @@ -363,7 +363,7 @@ Deploymentのリビジョンは、Deploymentのロールアウトがトリガー
363
363
` ` `
364
364
365
365
{{< note > }}
366
- Deploymentコントローラーは、この悪い状態のロールアウトを自動的に停止し、新しいReplicaSetのスケールアップを止めます。これはユーザーが指定したローリングアップデートに関するパラメータ (特に` maxUnavailable` )に依存します。デフォルトではKubernetesがこの値を25%に設定します。
366
+ Deploymentコントローラーは、この悪い状態のロールアウトを自動的に停止し、新しいReplicaSetのスケールアップを止めます。これはユーザーが指定したローリングアップデートに関するパラメーター (特に` maxUnavailable` )に依存します。デフォルトではKubernetesがこの値を25%に設定します。
367
367
{{< /note > }}
368
368
369
369
* Deploymentの詳細情報を取得します。
@@ -803,7 +803,7 @@ echo $?
803
803
* リソースリミットのレンジ
804
804
* アプリケーションランタイムの設定の不備
805
805
806
- このような状況を検知する1つの方法として、Deploymentのリソース定義でデッドラインのパラメータを指定します ([` .spec.progressDeadlineSeconds` ](# progress-deadline-seconds))。`.spec.progressDeadlineSeconds`はDeploymentの更新が停止したことを示す前にDeploymentコントローラーが待つ秒数を示します。
806
+ このような状況を検知する1つの方法として、Deploymentのリソース定義でデッドラインのパラメーターを指定します ([` .spec.progressDeadlineSeconds` ](# progress-deadline-seconds))。`.spec.progressDeadlineSeconds`はDeploymentの更新が停止したことを示す前にDeploymentコントローラーが待つ秒数を示します。
807
807
808
808
以下の` kubectl` コマンドでリソース定義に` progressDeadlineSeconds` を設定します。これはDeploymentの更新が止まってから10分後に、コントローラーが失敗を通知させるためです。
809
809
@@ -899,7 +899,7 @@ Conditions:
899
899
Progressing True NewReplicaSetAvailable
900
900
` ` `
901
901
902
- ` Status=True` の` Type=Available` は、Deploymentが最小可用性の状態であることを意味します。最小可用性は、Deploymentの更新戦略において指定されているパラメータにより決定されます 。` Status=True` の` Type=Progressing` は、Deploymentのロールアウトの途中で、更新処理が進行中であるか、更新処理が完了し、必要な最小数のレプリカが利用可能であることを意味します(各TypeのReason項目を確認してください。このケースでは、` Reason=NewReplicaSetAvailable` はDeploymentの更新が完了したことを意味します)。
902
+ ` Status=True` の` Type=Available` は、Deploymentが最小可用性の状態であることを意味します。最小可用性は、Deploymentの更新戦略において指定されているパラメーターにより決定されます 。` Status=True` の` Type=Progressing` は、Deploymentのロールアウトの途中で、更新処理が進行中であるか、更新処理が完了し、必要な最小数のレプリカが利用可能であることを意味します(各TypeのReason項目を確認してください。このケースでは、` Reason=NewReplicaSetAvailable` はDeploymentの更新が完了したことを意味します)。
903
903
904
904
` kubectl rollout status` を実行してDeploymentが更新に失敗したかどうかを確認できます。` kubectl rollout status` はDeploymentが更新処理のデッドラインを超えたときに0以外の終了コードを返します。
905
905
Original file line number Diff line number Diff line change @@ -36,7 +36,7 @@ content_type: concept
36
36
### 機能の状態コード
37
37
38
38
表示されるKubernetesのバージョンのデフォルトはそのページのデフォルトまたはサイトのデフォルトです。
39
- ` for_k8s_version ` パラメータを渡すことにより 、機能の状態バージョンを変更することができます。
39
+ ` for_k8s_version ` パラメーターを渡すことにより 、機能の状態バージョンを変更することができます。
40
40
例えば:
41
41
42
42
```
Original file line number Diff line number Diff line change @@ -45,7 +45,7 @@ ComponentConfigの詳細については、[このセクション](#configure-kub
45
45
46
46
### インスタンス固有の設定内容を適用 {#providing-instance-specific-configuration-details}
47
47
48
- いくつかのホストでは、ハードウェア、オペレーティングシステム、ネットワーク、その他ホスト固有のパラメータの違いのため 、特定のkubeletの設定を必要とします。以下にいくつかの例を示します。
48
+ いくつかのホストでは、ハードウェア、オペレーティングシステム、ネットワーク、その他ホスト固有のパラメーターの違いのため 、特定のkubeletの設定を必要とします。以下にいくつかの例を示します。
49
49
50
50
- DNS解決ファイルへのパスは` --resolv-conf`フラグで指定することができますが、オペレーティングシステムや`systemd-resolved`を使用するかどうかによって異なる場合があります。このパスに誤りがある場合、そのNode上でのDNS解決は失敗します。
51
51
- クラウドプロバイダーを使用していない場合、Node APIオブジェクト`.metadata.name`はデフォルトでマシンのホスト名に設定されます。異なるNode名を指定する必要がある場合には、`--hostname-override`フラグによってこの挙動を書き換えることができます。
@@ -72,7 +72,7 @@ ComponentConfigの詳細については、[このセクション](#configure-kub
72
72
KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."
73
73
` ` `
74
74
75
- kubelet起動時に渡されるフラグに加えて、このファイルはcgroupドライバーや異なるCRIランタイムソケットを使用するかどうか(`--cri-socket`)といった動的なパラメータも含みます 。
75
+ kubelet起動時に渡されるフラグに加えて、このファイルはcgroupドライバーや異なるCRIランタイムソケットを使用するかどうか(`--cri-socket`)といった動的なパラメーターも含みます 。
76
76
77
77
これら二つのファイルがディスク上に格納されると、systemdを使用している場合、kubeadmは以下の二つのコマンドを実行します。
78
78
Original file line number Diff line number Diff line change @@ -221,7 +221,7 @@ Windowsには厳密な互換性ルールがあり、ホストOSのバージョ
221
221
222
222
Windowsには、Linuxのようなメモリ不足のプロセスキラーはありません。Windowsは常に全ユーザーモードのメモリ割り当てを仮想として扱い、ページファイルは必須です。正味の効果は、WindowsはLinuxのようなメモリ不足の状態にはならず、メモリ不足(OOM)終了の影響を受ける代わりにページをディスクに処理します。メモリが過剰にプロビジョニングされ、物理メモリのすべてが使い果たされると、ページングによってパフォーマンスが低下する可能性があります。
223
223
224
- 2ステップのプロセスで、メモリ使用量を妥当な範囲内に保つことが可能です。まず、kubeletパラメータ ` --kubelet-reserve ` や` --system-reserve ` を使用して、ノード(コンテナ外)でのメモリ使用量を明確にします。これにより、[ NodeAllocatable] ( /ja/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable ) )が削減されます。ワークロードをデプロイするときは、コンテナにリソース制限をかけます(制限のみを設定するか、制限が要求と等しくなければなりません)。これにより、NodeAllocatableも差し引かれ、ノードのリソースがフルな状態になるとSchedulerがPodを追加できなくなります。
224
+ 2ステップのプロセスで、メモリ使用量を妥当な範囲内に保つことが可能です。まず、kubeletパラメーター ` --kubelet-reserve ` や` --system-reserve ` を使用して、ノード(コンテナ外)でのメモリ使用量を明確にします。これにより、[ NodeAllocatable] ( /ja/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable ) )が削減されます。ワークロードをデプロイするときは、コンテナにリソース制限をかけます(制限のみを設定するか、制限が要求と等しくなければなりません)。これにより、NodeAllocatableも差し引かれ、ノードのリソースがフルな状態になるとSchedulerがPodを追加できなくなります。
225
225
226
226
過剰なプロビジョニングを回避するためのベストプラクティスは、Windows、Docker、およびKubernetesのプロセスに対応するために、最低2GBのメモリを予約したシステムでkubeletを構成することです。
227
227
@@ -481,7 +481,7 @@ Kubernetesクラスターのトラブルシューティングの主なヘルプ
481
481
482
482
1. コンテナのvNICとHNSエンドポイントが削除されています
483
483
484
- この問題は、`hostname-override`パラメータが [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)に渡されない場合に発生する可能性があります。これを解決するには、ユーザーは次のようにホスト名をkube-proxyに渡す必要があります。:
484
+ この問題は、`hostname-override`パラメーターが [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)に渡されない場合に発生する可能性があります。これを解決するには、ユーザーは次のようにホスト名をkube-proxyに渡す必要があります。:
485
485
486
486
```powershell
487
487
C:\k\kube-proxy.exe --hostname-override=$(hostname)
You can’t perform that action at this time.
0 commit comments