From 1579e3abe93470349bd127836419f1a855fc547d Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 23 Jun 2020 13:45:30 +0900 Subject: [PATCH 1/6] Update nodes.md for v1.17 --- .../ja/docs/concepts/architecture/nodes.md | 46 ++++++++++++------- 1 file changed, 30 insertions(+), 16 deletions(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index d5631319a7..88c3962085 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -43,7 +43,6 @@ kubectl describe node <ノード名> | ノードのCondition | 概要 | |----------------|-------------| -| `OutOfDisk` | 新しいPodを追加するために必要なディスク容量が足りない場合に`True`になります。それ以外のときは`False`です。 | | `Ready` | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 | | `MemoryPressure` | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 | | `PIDPressure` | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 | @@ -69,18 +68,9 @@ Ready conditionが`pod-eviction-timeout`に設定された時間を超えても` バージョン1.5よりも前のKubernetesでは、ノードコントローラーはAPIサーバーから到達不能なそれらのPodを[強制削除](/ja/docs/concepts/workloads/pods/pod/#podの強制削除)していました。しかしながら、1.5以降では、ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。 -バージョン1.12において、`TaintNodesByCondition`機能がBetaに昇格し、それによってノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成するようになりました。 -同様に、スケジューラーがPodを配置するノードを検討する際、ノードのtaintとPodのtolerationsを見るかわりにconditionを無視するようになりました。 +ノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成します。 -ユーザーは、古いスケジューリングモデルか、新しくてより柔軟なスケジューリングモデルのどちらかを選択できるようになりました。 -上記のtolerationがないPodは古いスケジュールモデルに従ってスケジュールされます。しかし、特定のノードのtaintを許容するPodについては、条件に合ったノードにスケジュールすることができます。 - -{{< caution >}} - -この機能を有効にすると、conditionが観測されてからtaintが作成されるまでの間にわずかな遅延が発生します。 -この遅延は通常1秒未満ですが、正常にスケジュールされているが、kubeletによって配置を拒否されたPodの数が増える可能性があります。 - -{{< /caution >}} +スケジューラーがPodをノードにアサインする際、ノードのtaintを考慮します。Podが許容するtaintは例外です。 ### CapacityとAllocatable {#capacity} @@ -91,7 +81,7 @@ allocatableブロックは、通常のPodによって消費されるノード上 CapacityとAllocatableについて深く知りたい場合は、ノード上でどのように[コンピュートリソースが予約されるか](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)を読みながら学ぶことができます。 -### Info +### Info {#info} カーネルのバージョン、Kubernetesのバージョン（kubeletおよびkube-proxyのバージョン）、（使用されている場合）Dockerのバージョン、OS名など、ノードに関する一般的な情報です。 この情報はノードからkubeletを通じて取得されます。 @@ -114,6 +104,7 @@ CapacityとAllocatableについて深く知りたい場合は、ノード上で ``` Kubernetesは内部的にNodeオブジェクトを作成し、 `metadata.name`フィールドに基づくヘルスチェックによってノードを検証します。ノードが有効な場合、つまり必要なサービスがすべて実行されている場合は、Podを実行する資格があります。それ以外の場合、該当ノードが有効になるまではいかなるクラスターの活動に対しても無視されます。 +Nodeオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 {{< note >}} Kubernetesは無効なノードのためにオブジェクトを保存し、それをチェックし続けます。 @@ -136,9 +127,19 @@ Kubernetesは無効なノードのためにオブジェクトを保存し、そ ノードが到達不能(例えば、ノードがダウンしているなどので理由で、ノードコントローラーがハートビートの受信を停止した場合)になると、ノードコントローラーは、NodeStatusのNodeReady conditionをConditionUnknownに変更する役割があります。その後も該当ノードが到達不能のままであった場合、Graceful Terminationを使って全てのPodを退役させます。デフォルトのタイムアウトは、ConditionUnknownの報告を開始するまで40秒、その後Podの追い出しを開始するまで5分に設定されています。 ノードコントローラーは、`--node-monitor-period`に設定された秒数ごとに各ノードの状態をチェックします。 -バージョン1.13よりも前のKubernetesにおいて、NodeStatusはノードからのハートビートでした。Kubernetes 1.13から、NodeLeaseがアルファ機能として導入されました（Feature Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)）。 +#### ハートビート +ハートビートは、Kubernetesノードから送信され、ノードが利用可能か判断するのに役立ちます。 +２つのハートビートがあります：`NodeStatus`の更新と[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}#lease-v1-coordination-k8s-io)です。 +各ノードは`kube-node-lease`という{{< glossary_tooltip term_id="namespace" text="namespace">}}に関連したLeaseオブジェクトを持ちます。 +Leaseは軽量なリソースで、クラスターのスケールに応じてノードのハートビートにおけるパフォーマンスを改善します。 + +kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担当します。 + +- kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。（到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです） +- Kubeletは10秒間隔（デフォルトの更新間隔）でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限としたエクスポネンシャル・バックオフでリトライします。 + +#### 信頼性 -NodeLeaseが有効になっている場合、各ノードは `kube-node-lease`というNamespaceに関連付けられた`Lease`オブジェクトを持ち、ノードによって定期的に更新されます。NodeStatusとNodeLeaseの両方がノードからのハートビートとして扱われます。NodeLeaseは頻繁に更新されますが、NodeStatusはノードからマスターへの変更があるか、または十分な時間が経過した場合にのみ報告されます（デフォルトは1分で、到達不能の場合のデフォルトタイムアウトである40秒よりも長いです）。NodeLeaseはNodeStatusよりもはるかに軽量であるため、スケーラビリティとパフォーマンスの両方の観点においてノードのハートビートのコストを下げます。 Kubernetes 1.4では、マスターに問題が発生した場合の対処方法を改善するように、ノードコントローラーのロジックをアップデートしています（マスターのネットワークに問題があるため） バージョン1.4以降、ノードコントローラーは、Podの退役について決定する際に、クラスター内のすべてのノードの状態を調べます。 @@ -201,6 +202,11 @@ DaemonSetコントローラーによって作成されたPodはKubernetesスケ これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンがマシンに属していることを前提としているためです。 {{< /note >}} +{{< caution >}} +`kubectl cordon`はノードに'unschedulable'としてマークします。それはロードバランサーのターゲットリストからノードを削除するという +サービスコントローラーの副次的な効果をもたらします。これにより、ロードバランサトラフィックの流入をcordonされたノードから効率的に除去する事ができます。 +{{< /caution >}} + ### ノードのキャパシティ ノードのキャパシティ（CPUの数とメモリの量）はNodeオブジェクトの一部です。 @@ -213,10 +219,18 @@ Kubernetesスケジューラーは、ノード上のすべてのPodに十分な Pod以外のプロセス用にリソースを明示的に予約したい場合は、このチュートリアルに従って[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)してください。 +## ノードのトポロジー + +{{< feature-state state="alpha" >}} +`TopologyManager`の[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、 +kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。 ## APIオブジェクト NodeはKubernetesのREST APIにおけるトップレベルのリソースです。APIオブジェクトに関する詳細は以下の記事にてご覧いただけます: [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). - +{{% capture whatsnext %}} +* [ノードコンポーネント](/ja/docs/concepts/overview/components/#ノードコンポーネント)について読む。 +* ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/) +{{% /capture %}} From 09e8662e3358e7276ea60a50995e228a0af3616e Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 23 Jun 2020 19:47:34 +0900 Subject: [PATCH 2/6] Update content/ja/docs/concepts/architecture/nodes.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/architecture/nodes.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 88c3962085..01893b2571 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -70,7 +70,7 @@ Ready conditionが`pod-eviction-timeout`に設定された時間を超えても` ノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成します。 -スケジューラーがPodをノードにアサインする際、ノードのtaintを考慮します。Podが許容するtaintは例外です。 +スケジューラーがPodをノードに割り当てる際、ノードのtaintを考慮します。Podが許容するtaintは例外です。 ### CapacityとAllocatable {#capacity} @@ -233,4 +233,3 @@ NodeはKubernetesのREST APIにおけるトップレベルのリソースです * [ノードコンポーネント](/ja/docs/concepts/overview/components/#ノードコンポーネント)について読む。 * ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/) {{% /capture %}} - From 2e163f0a7a4418e44f555d4215b6ef9ac94bcaa7 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 23 Jun 2020 19:47:54 +0900 Subject: [PATCH 3/6] Update content/ja/docs/concepts/architecture/nodes.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 01893b2571..319844e639 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -222,7 +222,7 @@ Pod以外のプロセス用にリソースを明示的に予約したい場合 ## ノードのトポロジー {{< feature-state state="alpha" >}} -`TopologyManager`の[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、 +`TopologyManager`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、 kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。 ## APIオブジェクト From 8b2e92af23e12ab177217b9f4e7e604cb84e1d78 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 23 Jun 2020 19:48:21 +0900 Subject: [PATCH 4/6] Update content/ja/docs/concepts/architecture/nodes.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 319844e639..1e4f7d1e1d 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -230,6 +230,6 @@ kubeletはリソースの割当を決定する際にトポロジーのヒント NodeはKubernetesのREST APIにおけるトップレベルのリソースです。APIオブジェクトに関する詳細は以下の記事にてご覧いただけます: [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). {{% capture whatsnext %}} -* [ノードコンポーネント](/ja/docs/concepts/overview/components/#ノードコンポーネント)について読む。 +* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について読む。 * ノードレベルのトポロジーについて読む: [ノードのトポロジー管理ポリシーを制御する](/docs/tasks/administer-cluster/topology-manager/) {{% /capture %}} From 125b3b36cb4a9d3cfa42e2e433825607c5b2ee37 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Tue, 23 Jun 2020 21:34:43 +0900 Subject: [PATCH 5/6] update components.md - add index --- content/ja/docs/concepts/overview/components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index 43e839d19c..c805565665 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -67,7 +67,7 @@ cloud-controller-managerを使用すると、クラウドベンダーのコー * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。 * ボリュームコントローラー：ボリュームを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてボリュームを調整したりします。 -## ノードコンポーネント +## ノードコンポーネント {#node-components} ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。 From 960f342effb7e83a4514a9d7a43d2bbdaf6112e9 Mon Sep 17 00:00:00 2001 From: hikkie3110 <3110hikaru326@gmail.com> Date: Wed, 24 Jun 2020 17:24:33 +0900 Subject: [PATCH 6/6] Update content/ja/docs/concepts/architecture/nodes.md Co-authored-by: Naoki Oketani --- content/ja/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 1e4f7d1e1d..f4c914e003 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -136,7 +136,7 @@ Leaseは軽量なリソースで、クラスターのスケールに応じてノ kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担当します。 - kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。（到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです） -- Kubeletは10秒間隔（デフォルトの更新間隔）でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限としたエクスポネンシャル・バックオフでリトライします。 +- kubeletは10秒間隔(デフォルトの更新間隔)でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限とした指数バックオフでリトライします。 #### 信頼性