whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Translated multiple-zones.md

Browse Source
This commit is contained in:
Shuzo Kato
2020-09-13 22:00:59 +09:00
committed by inductor
parent 7a6f50df4d
commit 890c212101
1 changed files with 55 additions and 108 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ja/docs/setup/best-practices/multiple-zones.md
+55 -108
View File
@@ -14,93 +14,50 @@ This page describes how to run a cluster in multiple zones.
## 始めに ## 始めに
Kubernetes 1.2 adds support for running a single cluster in multiple failure zones Kubernetes 1.2は複数のゾーンにおいて単一のクラスターを運用するサポートを追加しました(GCEでは単純に"ゾーン"，AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。
(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones"). これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。
This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate 完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に１つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。
nickname ["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)).
Full Cluster Federation allows combining separate
Kubernetes clusters running in different regions or cloud providers
(or on-premises data centers). However, many
users simply want to run a more available Kubernetes cluster in multiple zones
of their single cloud provider, and this is what the multizone support in 1.2 allows
(this previously went by the nickname "Ubernetes Lite").
Multizone support is deliberately limited: a single Kubernetes cluster can run マルチゾーンサポートは故意に限定されています: １つのKubernetesクラスターは複数のゾーンで運用することができますが、同じリージョン(あるいはクラウドプロバイダー)のみです。現在はGCEとAWSのみが自動的にサポートされています(他のクラウドプロバイダーやベアメタル環境においても、単にノードやボリュームに追加する適切なラベルを用意して同様のサポートを追加することは容易ではありますが)。
in multiple zones, but only within the same region (and cloud provider). Only
GCE and AWS are currently supported automatically (though it is easy to
add similar support for other clouds or even bare metal, by simply arranging
for the appropriate labels to be added to nodes and volumes).
## 機能性 ## 機能性
When nodes are started, the kubelet automatically adds labels to them with ノードが開始された時、kubeletは自動的にそれらにゾーン情報を付したラベルを追加します。
zone information.
Kubernetes will automatically spread the pods in a replication controller Kubernetesはレプリケーションコントローラーやサービス内のPodをシングルゾーンクラスターにおけるノードにデプロイします(障害の影響を減らすため)。マルチゾーンクラスターでは、このデプロイの挙動はゾーンを跨いで拡張されます(障害の影響を減らすため)(これは`SelectorSpreadPriority`によって可能になります)。これはベストエフォートな配置であり、つまりもしクラスターのゾーンが異種である(例:異なる数のノード，異なるタイプのノードや異なるPodのリソース要件)場合、これはゾーンを跨いだPodのデプロイを完璧に防ぐことができます。必要であれば、同種のゾーン(同一の数及びタイプのノード)を利用して不平等なデプロイの可能性を減らすことができます。
or service across nodes in a single-zone cluster (to reduce the impact of
failures.) With multiple-zone clusters, this spreading behavior is
extended across zones (to reduce the impact of zone failures.) (This is
achieved via `SelectorSpreadPriority`). This is a best-effort
placement, and so if the zones in your cluster are heterogeneous
(e.g. different numbers of nodes, different types of nodes, or
different pod resource requirements), this might prevent perfectly
even spreading of your pods across zones. If desired, you can use
homogeneous zones (same number and types of nodes) to reduce the
probability of unequal spreading.
When persistent volumes are created, the `PersistentVolumeLabel` 永続ボリュームが作成されると、`PersistentVolumeLabel`アドミッションコントローラーがそれらにゾーンラベルを付与します。スケジューラーは`VolumeZonePredicate`を通じて与えられたボリュームを請求するPodがそのボリュームと同じゾーンにのみ配置されることを保証します、これはボリュームはゾーンを跨いでアタッチすることができないためです。
admission controller automatically adds zone labels to them. The scheduler (via the
`VolumeZonePredicate` predicate) will then ensure that pods that claim a
given volume are only placed into the same zone as that volume, as volumes
cannot be attached across zones.
## 制限 ## 制限
There are some important limitations of the multizone support: マルチゾーンサポートにはいくつか重要な制限があります:
* We assume that the different zones are located close to each other in the * 異なるゾーンはネットワーク内においてお互いに近接して位置していることが想定されているため、いかなるzone-aware routingも行われません。特に、トラフィックはゾーンを跨いだサービスを通じて行き来するため(サービスをサポートするいくつかのPodがクライアントと同じゾーンに存在していても)、これは追加のレイテンシやコストを生むかもしれません。
network, so we don't perform any zone-aware routing. In particular, traffic
that goes via services might cross zones (even if some pods backing that service
exist in the same zone as the client), and this may incur additional latency and cost.
* Volume zone-affinity will only work with a `PersistentVolume`, and will not * Volume zone-affinityは`PersistentVolume`と共に動作し、例えばPodのスペックにおいてEBSボリュームを直接指定しても動作しません。
work if you directly specify an EBS volume in the pod spec (for example).
* Clusters cannot span clouds or regions (this functionality will require full * クラスターはクラウドやリージョンを跨げません(この機能はフルフェデレーションサポートが必要です)。
federation support).
* Although your nodes are in multiple zones, kube-up currently builds *ノードは複数のゾーンに存在しますが、kube-upは現在デフォルトではシングルマスターノードでビルドします。サービスは高可用性でありゾーンの障害に耐えることができますが、コントロールプレーンは単一のゾーンに位置します。高可用性コントロールプレーンを必要とするユーザーは[高可用性](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)の説明を参照してください。
a single master node by default. While services are highly
available and can tolerate the loss of a zone, the control plane is
located in a single zone. Users that want a highly available control
plane should follow the [high availability](/docs/admin/high-availability) instructions.
### ボリュームの制限 ### ボリュームの制限
The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode).
* StatefulSet volume zone spreading when using dynamic provisioning is currently not compatible with 以下の制限は[topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode)に記載されています。
pod affinity or anti-affinity policies.
* If the name of the StatefulSet contains dashes ("-"), volume zone spreading * 動的なプロビジョニングを使用する際のStatefulSetボリュームゾーンのデプロイは、現在Podのアフィニティあるいはアンチアフィニティと互換性がありません。
may not provide a uniform distribution of storage across zones.
* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass * StatefulSetの名前がダッシュ("-")を含む場合、ボリュームゾーンのデプロイはゾーンを跨いだストレージの均一な分配を提供ない可能性があります。
needs to be configured for a specific single zone, or the PVs need to be
statically provisioned in a specific zone. Another workaround is to use a * DeploymentやPodのスペックにおいて複数のPVCを指定すると、StorageClassは特定の１つのゾーンに割り当てる必要があります、あるいはPVは特定のゾーンに静的にプロビジョンされる必要があります。もう一つの解決方法として、StatefulSetを使用すると、レプリカに対する全てのボリュームが同じゾーンにプロビジョンされます。
StatefulSet, which will ensure that all the volumes for a replica are
provisioned in the same zone.
## 全体の流れ ## 全体の流れ
We're now going to walk through setting up and using a multi-zone GCEとAWSの両方にマルチゾーンのクラスターをセットアップし使用する手順について説明します。そのために、フルクラスターを用意し(`MULTIZONE=true`と指定する)、`kube-up`を再び実行して追加のゾーンにノードを追加します(`KUBE_USE_EXISTING_MASTER=true`と指定する)。
cluster on both GCE & AWS. To do so, you bring up a full cluster
(specifying `MULTIZONE=true`), and then you add nodes in additional zones
by running `kube-up` again (specifying `KUBE_USE_EXISTING_MASTER=true`).
### クラスターの立ち上げ ### クラスターの立ち上げ
Create the cluster as normal, but pass MULTIZONE to tell the cluster to manage multiple zones; creating nodes in us-central1-a. 通常と同様にクラスターを作成します、しかし複数のゾーンを管理するためにMULTIZONEをクラスターに設定します。ノードをus-central1-aに作成します。
GCE: GCE:
@@ -114,21 +71,20 @@ AWS:
curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash
``` ```
This step brings up a cluster as normal, still running in a single zone このステップは通常と同様にクラスターを立ち上げ、１つのゾーンで動作しています(しかし、`MULTIZONE=true`によりマルチゾーン能力は有効になっています)。
(but `MULTIZONE=true` has enabled multi-zone capabilities).
### ノードはラベルが付与される ### ノードはラベルが付与される
View the nodes; you can see that they are labeled with zone information. ノードを見てください。それらがゾーン情報と共にラベルされているのが分かります。
They are all in `us-central1-a` (GCE) or `us-west-2a` (AWS) so far. The それら全ては今のところ`us-central1-a` (GCE)あるいは`us-west-2a` (AWS)にあります。ラベルは`failure-domain.beta.kubernetes.io/region`がリージョンに、`failure-domain.beta.kubernetes.io/zone`はゾーンに付けられています:
labels are `failure-domain.beta.kubernetes.io/region` for the region,
and `failure-domain.beta.kubernetes.io/zone` for the zone:
```shell ```shell
kubectl get nodes --show-labels kubectl get nodes --show-labels
``` ```
The output is similar to this: 結果は以下のようになります:
```shell ```shell
NAME STATUS ROLES AGE VERSION LABELS NAME STATUS ROLES AGE VERSION LABELS
@@ -140,11 +96,8 @@ kubernetes-minion-a12q Ready <none> 6m v1.13.0
### 2つ目のゾーンにさらにノードを追加 ### 2つ目のゾーンにさらにノードを追加
Let's add another set of nodes to the existing cluster, reusing the それでは、現存のマスターを再利用して現存のクラスターにもう１つのノードのセットを追加しましょう。
existing master, running in a different zone (us-central1-b or us-west-2b). kube-upを再び実行します．しかし`KUBE_USE_EXISTING_MASTER=true`を指定することでkube-upは新しいマスターを作成せず、代わりに以前作成したものを再利用します。
We run kube-up again, but by specifying `KUBE_USE_EXISTING_MASTER=true`
kube-up will not create a new master, but will reuse one that was previously
created instead.
GCE: GCE:
@@ -152,22 +105,21 @@ GCE:
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh
``` ```
On AWS we also need to specify the network CIDR for the additional
subnet, along with the master internal IP address: AWSではマスターの内部IPアドレスに加えて追加のサブネット用のネットワークCIDRを指定する必要があります:
```shell ```shell
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
``` ```
View the nodes again; 3 more nodes should have launched and be tagged ノードをもう１度見てください。更なる3つのノードがus-central1-bに起動し、タグ付けられているはずです:
in us-central1-b:
```shell ```shell
kubectl get nodes --show-labels kubectl get nodes --show-labels
``` ```
The output is similar to this: 結果は以下のようになります:
```shell ```shell
NAME STATUS ROLES AGE VERSION LABELS NAME STATUS ROLES AGE VERSION LABELS
@@ -182,7 +134,7 @@ kubernetes-minion-wf8i Ready <none> 2m v1.13.0
### ボリュームのアフィニティ ### ボリュームのアフィニティ
Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity): 動的ボリュームを使用してボリュームを作成します(PersistentVolumeのみがゾーンアフィニティに対してサポートされています):
```bash ```bash
kubectl apply -f - <<EOF kubectl apply -f - <<EOF
@@ -210,30 +162,28 @@ EOF
``` ```
{{< note >}} {{< note >}}
For version 1.3+ Kubernetes will distribute dynamic PV claims across バージョン1.3以降のKubernetesは設定したゾーンを跨いでPVクレームを分配します。
the configured zones. For version 1.2, dynamic persistent volumes were バージョン1.2では動的永続ボリュームは常にクラスターのマスターがあるゾーンに作成されます。
always created in the zone of the cluster master (ここではus-central1-a / us-west-2a); このイシューは
(here us-central1-a / us-west-2a); that issue
([#23330](https://github.com/kubernetes/kubernetes/issues/23330)) ([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
was addressed in 1.3+. にバージョン1.3以降で記載されています。
{{< /note >}} {{< /note >}}
Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in. それでは、KubernetesがPVが作成されたゾーン及びリージョンを自動的にラベルしているか確認しましょう。
```shell ```shell
kubectl get pv --show-labels kubectl get pv --show-labels
``` ```
The output is similar to this: 結果は以下のようになります:
```shell ```shell
NAME CAPACITY ACCESSMODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE LABELS NAME CAPACITY ACCESSMODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE LABELS
pv-gce-mj4gm 5Gi RWO Retain Bound default/claim1 manual 46s failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a pv-gce-mj4gm 5Gi RWO Retain Bound default/claim1 manual 46s failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
``` ```
So now we will create a pod that uses the persistent volume claim. では永続ボリュームクレームを使用するPodを作成します。
Because GCE PDs / AWS EBS volumes cannot be attached across zones, GCE PD / AWS EBSボリュームはゾーンを跨いでアタッチできないため、これはこのPodがボリュームと同じゾーンにのみ作成されることを意味します:
this means that this pod can only be created in the same zone as the volume:
```yaml ```yaml
kubectl apply -f - <<EOF kubectl apply -f - <<EOF
@@ -255,8 +205,7 @@ spec:
EOF EOF
``` ```
Note that the pod was automatically created in the same zone as the volume, as 一般的にゾーンを跨いだアタッチはクラウドプロバイダーによって許可されていないため、Podは自動的にボリュームと同じゾーンに作成されることに注意してください:
cross-zone attachments are not generally permitted by cloud providers:
```shell ```shell
kubectl describe pod mypod | grep Node kubectl describe pod mypod | grep Node
@@ -266,7 +215,7 @@ kubectl describe pod mypod | grep Node
Node: kubernetes-minion-9vlv/10.240.0.5 Node: kubernetes-minion-9vlv/10.240.0.5
``` ```
And check node labels: ノードのラベルをチェックします:
```shell ```shell
kubectl get node kubernetes-minion-9vlv --show-labels kubectl get node kubernetes-minion-9vlv --show-labels
@@ -279,8 +228,7 @@ kubernetes-minion-9vlv Ready 22m v1.6.0+fff5156 beta.kubernetes.io/in
### Podがゾーンをまたがって配置される ### Podがゾーンをまたがって配置される
Pods in a replication controller or service are automatically spread レプリケーションコントローラーやサービス内のPodは自動的にゾーンに跨いでデプロイされます。まず、３つ目のゾーンに更なるノードを立ち上げましょう:
across zones. First, let's launch more nodes in a third zone:
GCE: GCE:
@@ -294,19 +242,19 @@ AWS:
KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
``` ```
Verify that you now have nodes in 3 zones: ３つのゾーンにノードがあることを確認します:
```shell ```shell
kubectl get nodes --show-labels kubectl get nodes --show-labels
``` ```
Create the guestbook-go example, which includes an RC of size 3, running a simple web app: シンプルなWebアプリケーションを動作する、３つのRCを持つguestbook-goの例を作成します:
```shell ```shell
find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {} find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
``` ```
The pods should be spread across all 3 zones: Podは３つの全てのゾーンにデプロイされているはずです:
```shell ```shell
kubectl describe pod -l app=guestbook | grep Node kubectl describe pod -l app=guestbook | grep Node
@@ -330,44 +278,43 @@ kubernetes-minion-olsh Ready <none> 3m v1.13.0 beta.kuberne
``` ```
Load-balancers span all zones in a cluster; the guestbook-go example ロードバランサーはクラスター内の全てのゾーンにデプロイされています; guestbook-goの例は負荷分散サービスのサンプルを含みます:
includes an example load-balanced service:
```shell ```shell
kubectl describe service guestbook | grep LoadBalancer.Ingress kubectl describe service guestbook | grep LoadBalancer.Ingress
``` ```
The output is similar to this: 結果は以下のようになります:
```shell ```shell
LoadBalancer Ingress: 130.211.126.21 LoadBalancer Ingress: 130.211.126.21
``` ```
Set the above IP: IPの上に設定します:
```shell ```shell
export IP=130.211.126.21 export IP=130.211.126.21
``` ```
Explore with curl via IP: IPをcurlを通じて探索します:
```shell ```shell
curl -s http://${IP}:3000/env | grep HOSTNAME curl -s http://${IP}:3000/env | grep HOSTNAME
``` ```
The output is similar to this: 結果は以下のようになります:
```shell ```shell
"HOSTNAME": "guestbook-44sep", "HOSTNAME": "guestbook-44sep",
``` ```
Again, explore multiple times: 再び、複数回探索します:
```shell ```shell
(for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done) | sort | uniq (for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done) | sort | uniq
``` ```
The output is similar to this: 結果は以下のようになります:
```shell ```shell
"HOSTNAME": "guestbook-44sep", "HOSTNAME": "guestbook-44sep",
@@ -375,11 +322,11 @@ The output is similar to this:
"HOSTNAME": "guestbook-ppm40", "HOSTNAME": "guestbook-ppm40",
``` ```
The load balancer correctly targets all the pods, even though they are in multiple zones. ロードバランサーは、たとえPodが複数のゾーンに存在していても、全てのPodをターゲットします。
### クラスターの停止 ### クラスターの停止
When you're done, clean up: 終了したら、クリーンアップします:
GCE: GCE: