From 61b6871ed4af7cf62ba5471f48f043f949818ecc Mon Sep 17 00:00:00 2001 From: Atsushi Nukariya Date: Fri, 12 Nov 2021 11:09:20 +0900 Subject: [PATCH 1/7] [ja] Translate setup/best-practices/cluster-large/ into Japanese --- .../setup/best-practices/cluster-large.md | 137 +++++++----------- 1 file changed, 56 insertions(+), 81 deletions(-) diff --git a/content/ja/docs/setup/best-practices/cluster-large.md b/content/ja/docs/setup/best-practices/cluster-large.md index 5a1f45b662..a6905e6886 100644 --- a/content/ja/docs/setup/best-practices/cluster-large.md +++ b/content/ja/docs/setup/best-practices/cluster-large.md @@ -1,123 +1,98 @@ --- -title: 大規模クラスタの構築 +title: 大規模クラスターの構築 weight: 20 --- -## サポート -At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes. More specifically, we support configurations that meet *all* of the following criteria: +クラスターはKubernetesのエージェントが動作する（物理もしくは仮想の） {{< glossary_tooltip text="nodes" term_id="node" >}} の集合で、{{< glossary_tooltip text="control plane" term_id="control-plane" >}} によって管理されます。 +Kubernetes {{< param "version" >}} では、最大5000ノードから構成されるクラスターをサポートします。 +具体的には、Kubernetesは次の基準を *全て* 満たす構成に対して適用できるように設計されています。 -* No more than 110 pods per node -* No more than 5000 nodes -* No more than 150000 total pods -* No more than 300000 total containers +* 1ノードにつきPodが110個以上存在しない +* 5000ノード以上存在しない +* Podの総数が150000個以上存在しない +* コンテナの総数が300000個以上存在しない + +ノードを追加したり削除したりすることによって、クラスターをスケールできます。 +これを行う方法は、クラスターがどのようにデプロイされたかに依存します。 -## 構築 +## クラウドプロバイダのリソースクォータ {#クォータの問題} -A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane). +クラウドプロバイダのクォータの問題に遭遇することを避けるため、多数のノードを使ったクラスターを作成するときには次のようなことを考慮してください。 -Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)). +* 次のようなクラウドリソースの増加をリクエストする + * コンピュータインスタンス + * CPU + * ストレージボリューム + * 使用中のIPアドレス + * パケットフィルタリングのルールセット + * ロードバランサの数 + * ネットワークサブネット + * ログストリーム +* クラウドプロバイダによる新しいインスタンスの作成に対するレート制限のため、バッチで新しいノードを立ち上げるようなクラスターのスケーリング操作を通すためには、バッチ間ですこし休止を入れます。 -Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up. -When setting up a large Kubernetes cluster, the following issues must be considered. +## コントロールプレーンのコンポーネント -### クォータの問題 +大きなクラスターでは、十分な計算とその他のリソースを持ったコントロールプレーンが必要になります。 -To avoid running into cloud provider quota issues, when creating a cluster with many nodes, consider: +特に故障ゾーンあたり1つまたは2つのコントロールプレーンインスタンスを動かす場合、最初に垂直方向にインスタンスをスケーリングさせ、垂直方向のスケーリングの効果が低下するポイントに達したら水平方向にスケーリングさせます。 -* Increase the quota for things like CPU, IPs, etc. - * In [GCE, for example,](https://cloud.google.com/compute/docs/resource-quotas) you'll want to increase the quota for: - * CPUs - * VM instances - * Total persistent disk reserved - * In-use IP addresses - * Firewall Rules - * Forwarding rules - * Routes - * Target pools -* Gating the setup script so that it brings up new node VMs in smaller batches with waits in between, because some cloud providers rate limit the creation of VMs. +フォールトトレランスを備えるために、1つの故障ゾーンに対して最低1インスタンスを動かすべきです。 +Kubernetesノードは、同一故障ゾーン内のコントロールプレーンエンドポイントに対して自動的にトラフィックが向かないようにします。 +しかし、クラウドプロバイダはこれを実現するための独自の機構を持っているかもしれません。 -### Etcdのストレージ +例えばマネージドなロードバランサを使うと、故障ゾーン _A_ にあるkubeletやPodから発生したトラフィックを、同じく故障ゾーン _A_ にあるコントロールプレーンホストに対してのみ送るように設定します。もし1つのコントロールプレーンホストまたは故障ゾーン _A_ のエンドポイントがオフラインになった場合、ゾーン _A_ にあるノードについてすべてのコントロールプレーンのトラフィックはゾーンを跨いで送信されます。それぞれのゾーンで複数のコントロールプレーンホストを動作させることは、結果としてほとんどありません。 -To improve performance of large clusters, we store events in a separate dedicated etcd instance. -When creating a cluster, existing salt scripts: +## etcdストレージ -* start and configure additional etcd instance -* configure api-server to use it for storing events +大きなクラスターの性能を向上させるために、他の専用のetcdインスタンスにイベントオブジェクトを保存できます。 -### マスターのサイズと構成要素 +クラスターを作るときに、（カスタムツールを使って）以下のようなことができます。 -On GCE/Google Kubernetes Engine, and AWS, `kube-up` automatically configures the proper VM size for your master depending on the number of nodes -in your cluster. On other providers, you will need to configure it manually. For reference, the sizes we use on GCE are +* 追加のetcdインスタンスを起動または設定する +* イベントを保存するために {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} を設定する -* 1-5 nodes: n1-standard-1 -* 6-10 nodes: n1-standard-2 -* 11-100 nodes: n1-standard-4 -* 101-250 nodes: n1-standard-8 -* 251-500 nodes: n1-standard-16 -* more than 500 nodes: n1-standard-32 +大きなクラスターのためにetcdを設定・管理する詳細については、[Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) または [kubeadmを使用した高可用性etcdクラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) を見てください。 -And the sizes we use on AWS are -* 1-5 nodes: m3.medium -* 6-10 nodes: m3.large -* 11-100 nodes: m3.xlarge -* 101-250 nodes: m3.2xlarge -* 251-500 nodes: c4.4xlarge -* more than 500 nodes: c4.8xlarge +## アドオンのリソース -{{< note >}} -On Google Kubernetes Engine, the size of the master node adjusts automatically based on the size of your cluster. For more information, see [this blog post](https://cloudplatform.googleblog.com/2017/11/Cutting-Cluster-Management-Fees-on-Google-Kubernetes-Engine.html). +Kubernetesの [リソース制限](/docs/concepts/configuration/manage-resources-containers/) は、メモリリークの影響やPodやコンテナが他のコンポーネントに与える他の影響を最小化することに役立ちます。 +これらのリソース制限は、アプリケーションのワークロードに適用するのと同様に、{{< glossary_tooltip text="addon" term_id="addons" >}} のリソースにも適用されます。 -On AWS, master node sizes are currently set at cluster startup time and do not change, even if you later scale your cluster up or down by manually removing or adding nodes or using a cluster autoscaler. -{{< /note >}} - -### アドオンのリソース - -To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](https://pr.k8s.io/10653/files) and [#10778](https://pr.k8s.io/10778/files)). - -For example: +例えば、ロギングコンポーネントに対してCPUやメモリ制限を設定できます。 ```yaml + ... containers: - name: fluentd-cloud-logging - image: k8s.gcr.io/fluentd-gcp:1.16 + image: fluent/fluentd-kubernetes-daemonset:v1 resources: limits: cpu: 100m memory: 200Mi ``` -Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](https://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits. +アドオンのデフォルト制限は、アドオンを小～中規模のKubernetesクラスターで動作させたときの経験から得られたデータに基づきます。 +大規模のクラスターで動作させる場合は、アドオンはデフォルト制限よりも多くのリソースを消費することが多いです。 +これらの値を調整せずに大規模のクラスターをデプロイした場合、メモリ制限に達し続けるため、アドオンが継続的に停止されるかもしれません。 +あるいは、CPUのタイムスライス制限により性能がでない状態で動作するかもしれません。 -To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following: +クラスターのアドオンのリソース制限に遭遇しないために、多くのノードで構成されるクラスターを構築する場合は次のことを考慮します。 -* Scale memory and CPU limits for each of the following addons, if used, as you scale up the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster): - * [InfluxDB and Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) - * [kubedns, dnsmasq, and sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in) - * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml) -* Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits): - * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml) -* Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well): - * [FluentD with ElasticSearch Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) - * [FluentD with GCP Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) +* いくつかのアドオンは垂直方向にスケールします - クラスターに1つのレプリカ、もしくは故障ゾーン全体にサービングされるものがあります。このようなアドオンでは、クラスターをスケールアウトしたときにリクエストと制限を増やす必要があります。 +* 数多くのアドオンは、水平方向にスケールします - より多くのPod数を動作させることで性能を向上できます - ただし、とても大きなクラスターではCPUやメモリの制限も少し引き上げる必要があるかもしれません。VerticalPodAutoscalerは、提案されたリクエストや制限の数値を提供する `_recommender_` モードで動作可能です。 +* いくつかのアドオンは {< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} によって制御され、1ノードに1つ複製される形で動作します: 例えばノードレベルのログアグリゲーターです。水平方向にスケールするアドオンの場合と同様に、CPUやメモリ制限を少し引き上げる必要があるかもしれません。 -Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185) -and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running -out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details). -For directions on how to detect if addon containers are hitting resource limits, see the -[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting). +## {{% heading "whatsnext" %}} -### 少数のノードの起動の失敗を許容する +`VerticalPodAutoscaler` は、リソースのリクエストやポッドの制限についての管理を手助けするためにクラスターへデプロイ可能なカスタムリソースです。 +`VerticalPodAutoscaler` やクラスターで致命的なアドオンを含むクラスターコンポーネントをスケールする方法についてさらに知りたい場合は [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) をご覧ください。 -For various reasons (see [#18969](https://github.com/kubernetes/kubernetes/issues/18969) for more details) running -`kube-up.sh` with a very large `NUM_NODES` may fail due to a very small number of nodes not coming up properly. -Currently you have two choices: restart the cluster (`kube-down.sh` and then `kube-up.sh` again), or before -running `kube-up.sh` set the environment variable `ALLOWED_NOTREADY_NODES` to whatever value you feel comfortable -with. This will allow `kube-up.sh` to succeed with fewer than `NUM_NODES` coming up. Depending on the -reason for the failure, those additional nodes may join later or the cluster may remain at a size of -`NUM_NODES - ALLOWED_NOTREADY_NODES`. +[cluster autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme) は、クラスターで要求されるリソース水準を満たす正確なノード数で動作できるよう、いくつかのクラウドプロバイダと統合されています。 + +[addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme) は、クラスターのスケールが変化したときにアドオンの自動的なリサイズをお手伝いします。 From a64b2c1b3f4d5d80d6ae1026a983e620d1439ecf Mon Sep 17 00:00:00 2001 From: Atsushi Nukariya Date: Tue, 30 Nov 2021 08:12:46 +0900 Subject: [PATCH 2/7] Address review's comment --- content/ja/docs/setup/best-practices/cluster-large.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/setup/best-practices/cluster-large.md b/content/ja/docs/setup/best-practices/cluster-large.md index a6905e6886..045fdd018d 100644 --- a/content/ja/docs/setup/best-practices/cluster-large.md +++ b/content/ja/docs/setup/best-practices/cluster-large.md @@ -4,7 +4,7 @@ weight: 20 --- -クラスターはKubernetesのエージェントが動作する（物理もしくは仮想の） {{< glossary_tooltip text="nodes" term_id="node" >}} の集合で、{{< glossary_tooltip text="control plane" term_id="control-plane" >}} によって管理されます。 +クラスターはKubernetesのエージェントが動作する（物理もしくは仮想の） {{< glossary_tooltip text="ノード" term_id="node" >}} の集合で、{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}} によって管理されます。 Kubernetes {{< param "version" >}} では、最大5000ノードから構成されるクラスターをサポートします。 具体的には、Kubernetesは次の基準を *全て* 満たす構成に対して適用できるように設計されています。 @@ -53,15 +53,15 @@ Kubernetesノードは、同一故障ゾーン内のコントロールプレー クラスターを作るときに、（カスタムツールを使って）以下のようなことができます。 * 追加のetcdインスタンスを起動または設定する -* イベントを保存するために {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} を設定する +* イベントを保存するために {{< glossary_tooltip term_id="kube-apiserver" text="APIサーバ" >}} を設定する 大きなクラスターのためにetcdを設定・管理する詳細については、[Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) または [kubeadmを使用した高可用性etcdクラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) を見てください。 ## アドオンのリソース -Kubernetesの [リソース制限](/docs/concepts/configuration/manage-resources-containers/) は、メモリリークの影響やPodやコンテナが他のコンポーネントに与える他の影響を最小化することに役立ちます。 -これらのリソース制限は、アプリケーションのワークロードに適用するのと同様に、{{< glossary_tooltip text="addon" term_id="addons" >}} のリソースにも適用されます。 +Kubernetesの [リソース制限](/ja/docs/concepts/configuration/manage-resources-containers/) は、メモリリークの影響やPodやコンテナが他のコンポーネントに与える他の影響を最小化することに役立ちます。 +これらのリソース制限は、アプリケーションのワークロードに適用するのと同様に、{{< glossary_tooltip text="アドオン" term_id="addons" >}} のリソースにも適用されます。 例えば、ロギングコンポーネントに対してCPUやメモリ制限を設定できます。 @@ -90,7 +90,7 @@ Kubernetesの [リソース制限](/docs/concepts/configuration/manage-resources ## {{% heading "whatsnext" %}} -`VerticalPodAutoscaler` は、リソースのリクエストやポッドの制限についての管理を手助けするためにクラスターへデプロイ可能なカスタムリソースです。 +`VerticalPodAutoscaler` は、リソースのリクエストやPodの制限についての管理を手助けするためにクラスターへデプロイ可能なカスタムリソースです。 `VerticalPodAutoscaler` やクラスターで致命的なアドオンを含むクラスターコンポーネントをスケールする方法についてさらに知りたい場合は [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) をご覧ください。 [cluster autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme) は、クラスターで要求されるリソース水準を満たす正確なノード数で動作できるよう、いくつかのクラウドプロバイダと統合されています。 From d2c1939fce431121663153722c5389937f96708b Mon Sep 17 00:00:00 2001 From: Atsushi Nukariya Date: Sat, 4 Dec 2021 10:09:16 +0900 Subject: [PATCH 3/7] Apply suggestions from code review Co-authored-by: nasa9084 --- .../setup/best-practices/cluster-large.md | 32 +++++++++---------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/content/ja/docs/setup/best-practices/cluster-large.md b/content/ja/docs/setup/best-practices/cluster-large.md index 045fdd018d..68713bf27c 100644 --- a/content/ja/docs/setup/best-practices/cluster-large.md +++ b/content/ja/docs/setup/best-practices/cluster-large.md @@ -4,7 +4,7 @@ weight: 20 --- -クラスターはKubernetesのエージェントが動作する（物理もしくは仮想の） {{< glossary_tooltip text="ノード" term_id="node" >}} の集合で、{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}} によって管理されます。 +クラスターはKubernetesのエージェントが動作する(物理もしくは仮想の){{< glossary_tooltip text="ノード" term_id="node" >}}の集合で、{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}によって管理されます。 Kubernetes {{< param "version" >}} では、最大5000ノードから構成されるクラスターをサポートします。 具体的には、Kubernetesは次の基準を *全て* 満たす構成に対して適用できるように設計されています。 @@ -17,9 +17,9 @@ Kubernetes {{< param "version" >}} では、最大5000ノードから構成さ これを行う方法は、クラスターがどのようにデプロイされたかに依存します。 -## クラウドプロバイダのリソースクォータ {#クォータの問題} +## クラウドプロバイダーのリソースクォータ {#クォータの問題} -クラウドプロバイダのクォータの問題に遭遇することを避けるため、多数のノードを使ったクラスターを作成するときには次のようなことを考慮してください。 +クラウドプロバイダのクォーターの問題に遭遇することを避けるため、多数のノードを使ったクラスターを作成するときには次のようなことを考慮してください。 * 次のようなクラウドリソースの増加をリクエストする * コンピュータインスタンス @@ -27,10 +27,10 @@ Kubernetes {{< param "version" >}} では、最大5000ノードから構成さ * ストレージボリューム * 使用中のIPアドレス * パケットフィルタリングのルールセット - * ロードバランサの数 + * ロードバランサーの数 * ネットワークサブネット * ログストリーム -* クラウドプロバイダによる新しいインスタンスの作成に対するレート制限のため、バッチで新しいノードを立ち上げるようなクラスターのスケーリング操作を通すためには、バッチ間ですこし休止を入れます。 +* クラウドプロバイダーによる新しいインスタンスの作成に対するレート制限のため、バッチで新しいノードを立ち上げるようなクラスターのスケーリング操作を通すためには、バッチ間ですこし休止を入れます。 ## コントロールプレーンのコンポーネント @@ -41,27 +41,27 @@ Kubernetes {{< param "version" >}} では、最大5000ノードから構成さ フォールトトレランスを備えるために、1つの故障ゾーンに対して最低1インスタンスを動かすべきです。 Kubernetesノードは、同一故障ゾーン内のコントロールプレーンエンドポイントに対して自動的にトラフィックが向かないようにします。 -しかし、クラウドプロバイダはこれを実現するための独自の機構を持っているかもしれません。 +しかし、クラウドプロバイダーはこれを実現するための独自の機構を持っているかもしれません。 -例えばマネージドなロードバランサを使うと、故障ゾーン _A_ にあるkubeletやPodから発生したトラフィックを、同じく故障ゾーン _A_ にあるコントロールプレーンホストに対してのみ送るように設定します。もし1つのコントロールプレーンホストまたは故障ゾーン _A_ のエンドポイントがオフラインになった場合、ゾーン _A_ にあるノードについてすべてのコントロールプレーンのトラフィックはゾーンを跨いで送信されます。それぞれのゾーンで複数のコントロールプレーンホストを動作させることは、結果としてほとんどありません。 +例えばマネージドなロードバランサーを使うと、故障ゾーン _A_ にあるkubeletやPodから発生したトラフィックを、同じく故障ゾーン _A_ にあるコントロールプレーンホストに対してのみ送るように設定します。もし1つのコントロールプレーンホストまたは故障ゾーン _A_ のエンドポイントがオフラインになった場合、ゾーン _A_ にあるノードについてすべてのコントロールプレーンのトラフィックはゾーンを跨いで送信されます。それぞれのゾーンで複数のコントロールプレーンホストを動作させることは、結果としてほとんどありません。 ## etcdストレージ 大きなクラスターの性能を向上させるために、他の専用のetcdインスタンスにイベントオブジェクトを保存できます。 -クラスターを作るときに、（カスタムツールを使って）以下のようなことができます。 +クラスターを作るときに、(カスタムツールを使って)以下のようなことができます。 * 追加のetcdインスタンスを起動または設定する -* イベントを保存するために {{< glossary_tooltip term_id="kube-apiserver" text="APIサーバ" >}} を設定する +* イベントを保存するために{{< glossary_tooltip term_id="kube-apiserver" text="APIサーバ" >}}を設定する -大きなクラスターのためにetcdを設定・管理する詳細については、[Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) または [kubeadmを使用した高可用性etcdクラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) を見てください。 +大きなクラスターのためにetcdを設定・管理する詳細については、[Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/)または[kubeadmを使用した高可用性etcdクラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)を見てください。 ## アドオンのリソース -Kubernetesの [リソース制限](/ja/docs/concepts/configuration/manage-resources-containers/) は、メモリリークの影響やPodやコンテナが他のコンポーネントに与える他の影響を最小化することに役立ちます。 -これらのリソース制限は、アプリケーションのワークロードに適用するのと同様に、{{< glossary_tooltip text="アドオン" term_id="addons" >}} のリソースにも適用されます。 +Kubernetesの[リソース制限](/ja/docs/concepts/configuration/manage-resources-containers/)は、メモリリークの影響やPodやコンテナが他のコンポーネントに与える他の影響を最小化することに役立ちます。 +これらのリソース制限は、アプリケーションのワークロードに適用するのと同様に、{{< glossary_tooltip text="アドオン" term_id="addons" >}}のリソースにも適用されます。 例えば、ロギングコンポーネントに対してCPUやメモリ制限を設定できます。 @@ -78,7 +78,7 @@ Kubernetesの [リソース制限](/ja/docs/concepts/configuration/manage-resour アドオンのデフォルト制限は、アドオンを小～中規模のKubernetesクラスターで動作させたときの経験から得られたデータに基づきます。 大規模のクラスターで動作させる場合は、アドオンはデフォルト制限よりも多くのリソースを消費することが多いです。 -これらの値を調整せずに大規模のクラスターをデプロイした場合、メモリ制限に達し続けるため、アドオンが継続的に停止されるかもしれません。 +これらの値を調整せずに大規模のクラスターをデプロイした場合、メモリー制限に達し続けるため、アドオンが継続的に停止されるかもしれません。 あるいは、CPUのタイムスライス制限により性能がでない状態で動作するかもしれません。 クラスターのアドオンのリソース制限に遭遇しないために、多くのノードで構成されるクラスターを構築する場合は次のことを考慮します。 @@ -91,8 +91,8 @@ Kubernetesの [リソース制限](/ja/docs/concepts/configuration/manage-resour ## {{% heading "whatsnext" %}} `VerticalPodAutoscaler` は、リソースのリクエストやPodの制限についての管理を手助けするためにクラスターへデプロイ可能なカスタムリソースです。 -`VerticalPodAutoscaler` やクラスターで致命的なアドオンを含むクラスターコンポーネントをスケールする方法についてさらに知りたい場合は [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) をご覧ください。 +`VerticalPodAutoscaler` やクラスターで致命的なアドオンを含むクラスターコンポーネントをスケールする方法についてさらに知りたい場合は[Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme)をご覧ください。 -[cluster autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme) は、クラスターで要求されるリソース水準を満たす正確なノード数で動作できるよう、いくつかのクラウドプロバイダと統合されています。 +[cluster autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)は、クラスターで要求されるリソース水準を満たす正確なノード数で動作できるよう、いくつかのクラウドプロバイダーと統合されています。 -[addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme) は、クラスターのスケールが変化したときにアドオンの自動的なリサイズをお手伝いします。 +[addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)は、クラスターのスケールが変化したときにアドオンの自動的なリサイズをお手伝いします。 From b1c4618fbd24291cda0622ea9fd0d6e502208862 Mon Sep 17 00:00:00 2001 From: Atsushi Nukariya Date: Mon, 6 Dec 2021 07:03:41 +0900 Subject: [PATCH 4/7] Address review's comment --- content/ja/docs/setup/best-practices/cluster-large.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/best-practices/cluster-large.md b/content/ja/docs/setup/best-practices/cluster-large.md index 68713bf27c..4ba9739e50 100644 --- a/content/ja/docs/setup/best-practices/cluster-large.md +++ b/content/ja/docs/setup/best-practices/cluster-large.md @@ -37,7 +37,7 @@ Kubernetes {{< param "version" >}} では、最大5000ノードから構成さ 大きなクラスターでは、十分な計算とその他のリソースを持ったコントロールプレーンが必要になります。 -特に故障ゾーンあたり1つまたは2つのコントロールプレーンインスタンスを動かす場合、最初に垂直方向にインスタンスをスケーリングさせ、垂直方向のスケーリングの効果が低下するポイントに達したら水平方向にスケーリングさせます。 +特に故障ゾーンあたり1つまたは2つのコントロールプレーンインスタンスを動かす場合、最初に垂直方向にインスタンスをスケールし、垂直方向のスケーリングの効果が低下するポイントに達したら水平方向にスケールします。 フォールトトレランスを備えるために、1つの故障ゾーンに対して最低1インスタンスを動かすべきです。 Kubernetesノードは、同一故障ゾーン内のコントロールプレーンエンドポイントに対して自動的にトラフィックが向かないようにします。 From 74cf4ccb139a5c5d68ea3040119ef2520c74de39 Mon Sep 17 00:00:00 2001 From: Atsushi Nukariya Date: Mon, 6 Dec 2021 07:05:33 +0900 Subject: [PATCH 5/7] Apply suggestions from code review Co-authored-by: nasa9084 --- content/ja/docs/setup/best-practices/cluster-large.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/setup/best-practices/cluster-large.md b/content/ja/docs/setup/best-practices/cluster-large.md index 4ba9739e50..8c2626ba3b 100644 --- a/content/ja/docs/setup/best-practices/cluster-large.md +++ b/content/ja/docs/setup/best-practices/cluster-large.md @@ -19,10 +19,10 @@ Kubernetes {{< param "version" >}} では、最大5000ノードから構成さ ## クラウドプロバイダーのリソースクォータ {#クォータの問題} -クラウドプロバイダのクォーターの問題に遭遇することを避けるため、多数のノードを使ったクラスターを作成するときには次のようなことを考慮してください。 +クラウドプロバイダーのクォーターの問題に遭遇することを避けるため、多数のノードを使ったクラスターを作成するときには次のようなことを考慮してください。 * 次のようなクラウドリソースの増加をリクエストする - * コンピュータインスタンス + * コンピューターインスタンス * CPU * ストレージボリューム * 使用中のIPアドレス From 1eabc66c8fb1933f41e64d430314f3edc61c925a Mon Sep 17 00:00:00 2001 From: Atsushi Nukariya Date: Mon, 6 Dec 2021 17:03:26 +0900 Subject: [PATCH 6/7] Update content/ja/docs/setup/best-practices/cluster-large.md Co-authored-by: nasa9084 --- content/ja/docs/setup/best-practices/cluster-large.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/best-practices/cluster-large.md b/content/ja/docs/setup/best-practices/cluster-large.md index 8c2626ba3b..e1c545bd22 100644 --- a/content/ja/docs/setup/best-practices/cluster-large.md +++ b/content/ja/docs/setup/best-practices/cluster-large.md @@ -19,7 +19,7 @@ Kubernetes {{< param "version" >}} では、最大5000ノードから構成さ ## クラウドプロバイダーのリソースクォータ {#クォータの問題} -クラウドプロバイダーのクォーターの問題に遭遇することを避けるため、多数のノードを使ったクラスターを作成するときには次のようなことを考慮してください。 +クラウドプロバイダーのクォータの問題に遭遇することを避けるため、多数のノードを使ったクラスターを作成するときには次のようなことを考慮してください。 * 次のようなクラウドリソースの増加をリクエストする * コンピューターインスタンス From 42917dcd5be5dd5bb255846aa65630324b27edec Mon Sep 17 00:00:00 2001 From: Atsushi Nukariya Date: Tue, 7 Dec 2021 06:26:35 +0900 Subject: [PATCH 7/7] Update content/ja/docs/setup/best-practices/cluster-large.md Co-authored-by: nasa9084 --- content/ja/docs/setup/best-practices/cluster-large.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/setup/best-practices/cluster-large.md b/content/ja/docs/setup/best-practices/cluster-large.md index e1c545bd22..4f99e1b551 100644 --- a/content/ja/docs/setup/best-practices/cluster-large.md +++ b/content/ja/docs/setup/best-practices/cluster-large.md @@ -85,7 +85,7 @@ Kubernetesの[リソース制限](/ja/docs/concepts/configuration/manage-resourc * いくつかのアドオンは垂直方向にスケールします - クラスターに1つのレプリカ、もしくは故障ゾーン全体にサービングされるものがあります。このようなアドオンでは、クラスターをスケールアウトしたときにリクエストと制限を増やす必要があります。 * 数多くのアドオンは、水平方向にスケールします - より多くのPod数を動作させることで性能を向上できます - ただし、とても大きなクラスターではCPUやメモリの制限も少し引き上げる必要があるかもしれません。VerticalPodAutoscalerは、提案されたリクエストや制限の数値を提供する `_recommender_` モードで動作可能です。 -* いくつかのアドオンは {< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} によって制御され、1ノードに1つ複製される形で動作します: 例えばノードレベルのログアグリゲーターです。水平方向にスケールするアドオンの場合と同様に、CPUやメモリ制限を少し引き上げる必要があるかもしれません。 +* いくつかのアドオンは{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}によって制御され、1ノードに1つ複製される形で動作します: 例えばノードレベルのログアグリゲーターです。水平方向にスケールするアドオンの場合と同様に、CPUやメモリ制限を少し引き上げる必要があるかもしれません。 ## {{% heading "whatsnext" %}}