Merge upstream work for release-1.19

2021-05-26 10:16:04 +00:00
parent d0903bdfa0
commit c60df272cb
178 changed files with 6179 additions and 4158 deletions
@@ -17,12 +17,11 @@ card:
 <!-- overview -->

 このセクションではKubernetesをセットアップして動かすための複数のやり方について説明します。
+Kubernetesをインストールする際には、メンテナンスの容易さ、セキュリティ、制御、利用可能なリソース、クラスターの運用及び管理に必要な専門知識に基づいてインストレーションタイプを選んでください。

-各Kubernetesソリューションはそれぞれ、メンテナンス性、セキュリティ、管理、利用可能なリソース、クラスターの運用に専門知識が必要など、異なる要件があります。

-Kubernetesクラスタはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションを選ぶことも可能です。
+Kubernetesクラスタはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションもあります。

-簡潔に言えば、学習用としても、本番環境用としてもKubernetesクラスターを作成することができます。



@@ -30,25 +29,14 @@ Kubernetesクラスタはローカルマシン、クラウド、オンプレの

 ## 環境について学ぶ

-Kubernetesについて学んでいる場合、Dockerベースのソリューションを使いましょう。これらはKubernetesコミュニティにサポートされていたり、あるいはKubernetesクラスターをローカル環境にセットアップするエコシステムを持っていたりします。
+Kubernetesについて学んでいる場合、Kubernetesコミュニティにサポートされているツールや、Kubernetesクラスターをローカルマシンにセットアップするエコシステム内のツールを使いましょう。

-{{< table caption="Local machine solutions table that lists the tools supported by the community and the ecosystem to deploy Kubernetes." >}}
-
-|コミュニティ           |エコシステム     |
-| ------------       | --------     |
-| [Minikube](/ja/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
-| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
-|                     | [Minishift](https://docs.okd.io/latest/minishift/)|
-|                     | [MicroK8s](https://microk8s.io/)|
-|                     | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
-|                     | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
-|                     | [k3s](https://k3s.io)|


 ## 本番環境

 本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。

-[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、「[パートナー](https://kubernetes.io/ja/partners/#conformance)」を参照してください。
+[Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes)プロバイダーの一覧については、[Kubernetes パートナー](https://kubernetes.io/ja/partners/#conformance)を参照してください。


@@ -26,10 +26,10 @@ Kubernetesは下記の用途でPKIを必要とします：
 * APIサーバーがetcdと通信するためのクライアント証明書
 * controller managerがAPIサーバーと通信するためのクライアント証明書およびkubeconfig
 * スケジューラーがAPIサーバーと通信するためのクライアント証明書およびkubeconfig
-* [front-proxy][proxy]用のクライアント証明書およびサーバー証明書
+* [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)用のクライアント証明書およびサーバー証明書

 {{< note >}}
-`front-proxy`証明書は、[Kubernetes APIの拡張](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)をサポートするためにkube-proxyを実行する場合のみ必要です。
+`front-proxy`証明書は、[Kubernetes APIの拡張](/docs/tasks/extend-kubernetes/setup-extension-api-server/)をサポートするためにkube-proxyを実行する場合のみ必要です。
 {{< /note >}}

 さらに、etcdはクライアントおよびピア間の認証に相互TLS通信を実装しています。
@@ -52,7 +52,7 @@ kubeadmで証明書を生成したくない場合は、下記の方法のいず
 |------------------------|---------------------------|----------------------------------|
 | ca.crt,key             | kubernetes-ca             | Kubernetes全体の認証局　　　        |
 | etcd/ca.crt,key        | etcd-ca                   | etcd用　　　　　　　　　　　　　　   |
-| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy][proxy]用　　　 |
+| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)用　　　 |

 上記の認証局に加えて、サービスアカウント管理用に公開鍵/秘密鍵のペア(`sa.key`と`sa.pub`)を取得する事が必要です。

@@ -72,9 +72,9 @@ CAの秘密鍵をクラスターにコピーしたくない場合、自身で全
 | kube-apiserver-kubelet-client | kubernetes-ca             | system:masters | client                                 |                                             |
 | front-proxy-client            | kubernetes-front-proxy-ca |                | client                                 |                                             |

-[1]: クラスターに接続するIPおよびDNS名( [kubeadm][kubeadm]を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`)
+[1]: クラスターに接続するIPおよびDNS名( [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)を使用する場合と同様、ロードバランサーのIPおよびDNS名、`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`)

-`kind`は下記の[x509の鍵用途][usage]のタイプにマッピングされます:
+`kind`は下記の[x509の鍵用途](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage)のタイプにマッピングされます:

 | 種類   | 鍵の用途  　　　                                                                     |
 |--------|---------------------------------------------------------------------------------|
@@ -96,7 +96,8 @@ kubeadm利用者のみ：

 ### 証明書のパス

-証明書は推奨パスに配置するべきです([kubeadm][kubeadm]を使用する場合と同様)。パスは場所に関係なく与えられた引数で特定されます。
+証明書は推奨パスに配置するべきです([kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)を使用する場合と同様)。
+パスは場所に関係なく与えられた引数で特定されます。

 | デフォルトCN                   | 鍵の推奨パス        　　　　　　 | 証明書の推奨パス    　　　　　   | コマンド        | 鍵を指定する引数               | 証明書を指定する引数                          |
 |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
@@ -157,8 +158,5 @@ KUBECONFIG=<filename> kubectl config use-context default-system
 | controller-manager.conf | kube-controller-manager | `manifests/kube-controller-manager.yaml`のマニフェストファイルに追記する必要があります。 |
 | scheduler.conf          | kube-scheduler          | `manifests/kube-scheduler.yaml`のマニフェストファイルに追記する必要があります。          |

-[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage
-[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
-[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/


@@ -12,15 +12,12 @@ At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes.
 * No more than 300000 total containers
 * No more than 100 pods per node

-<br>
-
-{{< toc >}}

 ## 構築

 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`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
+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)).

 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.

@@ -80,7 +77,7 @@ On AWS, master node sizes are currently set at cluster startup time and do not c

 ### アドオンのリソース

-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](http://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)).
+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:

@@ -94,28 +91,26 @@ For example:
        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](http://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.
+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.

 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](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
-  * [kubedns, dnsmasq, and sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
-  * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
+  * [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](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
+  * [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](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
-  * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
+  * [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)

 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-compute-resources-container/#troubleshooting).
-
-In the [future](http://issue.k8s.io/13048), we anticipate to set all cluster addon resource limits based on cluster size, and to dynamically adjust them if you grow or shrink your cluster.
-We welcome PRs that implement those features.
+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).

 ### 少数のノードの起動の失敗を許容する

@@ -6,101 +6,57 @@ content_type: concept

 <!-- overview -->

-This page describes how to run a cluster in multiple zones.
-
+このページでは、複数のゾーンでクラスタを実行する方法について説明します。


 <!-- body -->

-## 始めに
+## はじめに

-Kubernetes 1.2 adds support for running a single cluster in multiple failure zones
-(GCE calls them simply "zones", AWS calls them "availability zones", here we'll refer to them as "zones").
-This is a lightweight version of a broader Cluster Federation feature (previously referred to by the affectionate
-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").
+Kubernetes 1.2より、複数のゾーンにおいて単一のクラスターを運用するサポートが追加されました(GCEでは単純に"ゾーン"、AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。
+これは、より範囲の広いCluster Federationの軽量バージョンです(以前は["Ubernetes"](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)の愛称で言及されていました)。
+完全なCluster Federationでは、異なるリージョンやクラウドプロバイダー(あるいはオンプレミスデータセンター)内の独立したKubernetesクラスターをまとめることが可能になります。しかしながら、多くのユーザーは単に1つのクラウドプロバイダーの複数のゾーンでより可用性の高いKubernetesクラスターを運用したいと考えており、バージョン1.2におけるマルチゾーンサポート(以前は"Ubernetes Lite"の愛称で使用されていました)ではこれが可能になります。

-Multizone support is deliberately limited: a single Kubernetes cluster can run
-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).
+マルチゾーンサポートは故意に限定されています: 1つのKubernetesクラスターは複数のゾーンで運用することができますが、同じリージョン(あるいはクラウドプロバイダー)のみです。現在はGCEとAWSのみが自動的にサポートされています(他のクラウドプロバイダーやベアメタル環境においても、単にノードやボリュームに追加する適切なラベルを用意して同様のサポートを追加することは容易ではありますが)。


 ## 機能性

-When nodes are started, the kubelet automatically adds labels to them with
-zone information.
+ノードが開始された時、kubeletは自動的にそれらにゾーン情報を付したラベルを追加します。

-Kubernetes will automatically spread the pods in a replication controller
-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.
+Kubernetesはレプリケーションコントローラーやサービス内のPodをシングルゾーンクラスターにおけるノードにデプロイします(障害の影響を減らすため)。マルチゾーンクラスターでは、このデプロイの挙動はゾーンを跨いで拡張されます(障害の影響を減らすため)(これは`SelectorSpreadPriority`によって可能になります)。これはベストエフォートな配置であり、つまりもしクラスターのゾーンが異種である(例:異なる数のノード、異なるタイプのノードや異なるPodのリソース要件)場合、これはゾーンを跨いだPodのデプロイを完璧に防ぐことができます。必要であれば、同種のゾーン(同一の数及びタイプのノード)を利用して不平等なデプロイの可能性を減らすことができます。

-When persistent volumes are created, the `PersistentVolumeLabel`
-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.
+永続ボリュームが作成されると、`PersistentVolumeLabel`アドミッションコントローラーがそれらにゾーンラベルを付与します。スケジューラーは`VolumeZonePredicate`を通じて与えられたボリュームを請求するPodがそのボリュームと同じゾーンにのみ配置されることを保証します、これはボリュームはゾーンを跨いでアタッチすることができないためです。

 ## 制限

-There are some important limitations of the multizone support:
+マルチゾーンサポートにはいくつか重要な制限があります:

-* We assume that the different zones are located close to each other in the
-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.
+* 異なるゾーンはネットワーク内においてお互いに近接して位置していることが想定されているため、いかなるzone-aware routingも行われません。特に、トラフィックはゾーンを跨いだサービスを通じて行き来するため(サービスをサポートするいくつかのPodがクライアントと同じゾーンに存在していても)、これは追加のレイテンシやコストを生むかもしれません。

-* Volume zone-affinity will only work with a `PersistentVolume`, and will not
-work if you directly specify an EBS volume in the pod spec (for example).
+* Volume zone-affinityは`PersistentVolume`と共に動作し、例えばPodのスペックにおいてEBSボリュームを直接指定しても動作しません。

-* Clusters cannot span clouds or regions (this functionality will require full
-federation support).
+* クラスターはクラウドやリージョンを跨げません(この機能はフルフェデレーションサポートが必要です)。

-* Although your nodes are in multiple zones, kube-up currently builds
-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.
+*ノードは複数のゾーンに存在しますが、kube-upは現在デフォルトではシングルマスターノードでビルドします。サービスは高可用性でありゾーンの障害に耐えることができますが、コントロールプレーンは単一のゾーンに配置されます。高可用性コントロールプレーンを必要とするユーザーは[高可用性](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)の説明を参照してください。

 ### ボリュームの制限
-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
-  pod affinity or anti-affinity policies.
+以下の制限は[topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode)に記載されています。

-* If the name of the StatefulSet contains dashes ("-"), volume zone spreading
-  may not provide a uniform distribution of storage across zones.
+* 動的なプロビジョニングを使用する際のStatefulSetボリュームゾーンのデプロイは、現在Podのアフィニティあるいはアンチアフィニティと互換性がありません。

-* When specifying multiple PVCs in a Deployment or Pod spec, the StorageClass
-  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
-  StatefulSet, which will ensure that all the volumes for a replica are
-  provisioned in the same zone.
+* StatefulSetの名前がダッシュ("-")を含む場合、ボリュームゾーンのデプロイはゾーンを跨いだストレージの均一な分配を提供しない可能性があります。
+
+* DeploymentやPodのスペックにおいて複数のPVCを指定すると、StorageClassは特定の1つのゾーンに割り当てる必要があります、あるいはPVは特定のゾーンに静的にプロビジョンされる必要があります。もう一つの解決方法として、StatefulSetを使用すると、レプリカに対する全てのボリュームが同じゾーンにプロビジョンされます。

 ## 全体の流れ

-We're now going to walk through setting up and using a multi-zone
-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`).
+GCEとAWSの両方にマルチゾーンのクラスターをセットアップし使用する手順について説明します。そのために、フルクラスターを用意し(`MULTIZONE=true`と指定する)、`kube-up`を再び実行して追加のゾーンにノードを追加します(`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:

@@ -114,21 +70,20 @@ AWS:
 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
-(but `MULTIZONE=true` has enabled multi-zone capabilities).
+このステップは通常と同様にクラスターを立ち上げ、1つのゾーンで動作しています(しかし、`MULTIZONE=true`によりマルチゾーン能力は有効になっています)。
+

 ### ノードはラベルが付与される

-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
-labels are `failure-domain.beta.kubernetes.io/region` for the region,
-and `failure-domain.beta.kubernetes.io/zone` for the zone:
+ノードを見てください。それらがゾーン情報と共にラベルされているのが分かります。
+それら全ては今のところ`us-central1-a` (GCE)あるいは`us-west-2a` (AWS)にあります。ラベルは`failure-domain.beta.kubernetes.io/region`がリージョンに、`failure-domain.beta.kubernetes.io/zone`はゾーンに付けられています:
+

 ```shell
 kubectl get nodes --show-labels
 ```

-The output is similar to this:
+結果は以下のようになります:

 ```shell
 NAME                     STATUS                     ROLES    AGE   VERSION          LABELS
@@ -140,11 +95,8 @@ kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0

 ### 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).
-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.
+それでは、現存のマスターを再利用し、現存のクラスターの異なるゾーン(us-central1-bかus-west-2b)にもう1つのノードのセットを追加しましょう。
+kube-upを再び実行します．しかし`KUBE_USE_EXISTING_MASTER=true`を指定することでkube-upは新しいマスターを作成せず、代わりに以前作成したものを再利用します。

 GCE:

@@ -152,22 +104,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
 ```

-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
 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
-in us-central1-b:
+ノードをもう1度見てください。更なる3つのノードがus-central1-bに起動し、タグ付けられているはずです:

 ```shell
 kubectl get nodes --show-labels
 ```

-The output is similar to this:
+結果は以下のようになります:

 ```shell
 NAME                     STATUS                     ROLES    AGE   VERSION           LABELS
@@ -182,7 +133,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
 kubectl apply -f - <<EOF
@@ -210,30 +161,28 @@ EOF
 ```

 {{< note >}}
-For version 1.3+ Kubernetes will distribute dynamic PV claims across
-the configured zones. For version 1.2, dynamic persistent volumes were
-always created in the zone of the cluster master
-(here us-central1-a / us-west-2a); that issue
+バージョン1.3以降のKubernetesは設定したゾーンを跨いでPVクレームを分配します。
+バージョン1.2では動的永続ボリュームは常にクラスターのマスターがあるゾーンに作成されます。
+(ここではus-central1-a / us-west-2a); このイシューは
 ([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
-was addressed in 1.3+.
+にバージョン1.3以降で記載されています。
 {{< /note >}}

-Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in.
+それでは、KubernetesがPVが作成されたゾーン及びリージョンを自動的にラベルしているか確認しましょう。

 ```shell
 kubectl get pv --show-labels
 ```

-The output is similar to this:
+結果は以下のようになります:

 ```shell
 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
 ```

-So now we will create a pod that uses the persistent volume claim.
-Because GCE PDs / AWS EBS volumes cannot be attached across zones,
-this means that this pod can only be created in the same zone as the volume:
+では永続ボリュームクレームを使用するPodを作成します。
+GCE PD / AWS EBSボリュームはゾーンを跨いでアタッチできないため、これはこのPodがボリュームと同じゾーンにのみ作成されることを意味します:

 ```yaml
 kubectl apply -f - <<EOF
@@ -255,8 +204,7 @@ spec:
 EOF
 ```

-Note that the pod was automatically created in the same zone as the volume, as
-cross-zone attachments are not generally permitted by cloud providers:
+一般的にゾーンを跨いだアタッチはクラウドプロバイダーによって許可されていないため、Podは自動的にボリュームと同じゾーンに作成されることに注意してください:

 ```shell
 kubectl describe pod mypod | grep Node
@@ -266,7 +214,7 @@ kubectl describe pod mypod | grep Node
 Node:        kubernetes-minion-9vlv/10.240.0.5
 ```

-And check node labels:
+ノードのラベルをチェックします:

 ```shell
 kubectl get node kubernetes-minion-9vlv --show-labels
@@ -279,8 +227,7 @@ kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/in

 ### Podがゾーンをまたがって配置される

-Pods in a replication controller or service are automatically spread
-across zones.  First, let's launch more nodes in a third zone:
+レプリケーションコントローラーやサービス内のPodは自動的にゾーンに跨いでデプロイされます。まず、3つ目のゾーンに更なるノードを立ち上げましょう:

 GCE:

@@ -294,19 +241,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
 ```

-Verify that you now have nodes in 3 zones:
+3つのゾーンにノードがあることを確認します:

 ```shell
 kubectl get nodes --show-labels
 ```

-Create the guestbook-go example, which includes an RC of size 3, running a simple web app:
+シンプルなWebアプリケーションを動作する、3つのRCを持つguestbook-goの例を作成します:

 ```shell
 find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
 ```

-The pods should be spread across all 3 zones:
+Podは3つの全てのゾーンにデプロイされているはずです:

 ```shell
 kubectl describe pod -l app=guestbook | grep Node
@@ -330,44 +277,43 @@ kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kuberne
 ```


-Load-balancers span all zones in a cluster; the guestbook-go example
-includes an example load-balanced service:
+ロードバランサーはクラスター内の全てのゾーンにデプロイされています; guestbook-goの例は負荷分散サービスのサンプルを含みます:

 ```shell
 kubectl describe service guestbook | grep LoadBalancer.Ingress
 ```

-The output is similar to this:
+結果は以下のようになります:

 ```shell
 LoadBalancer Ingress:   130.211.126.21
 ```

-Set the above IP:
+IPの上に設定します:

 ```shell
 export IP=130.211.126.21
 ```

-Explore with curl via IP:
+IPをcurlを通じて探索します:

 ```shell
 curl -s http://${IP}:3000/env | grep HOSTNAME
 ```

-The output is similar to this:
+結果は以下のようになります:

 ```shell
  "HOSTNAME": "guestbook-44sep",
 ```

-Again, explore multiple times:
+再び、複数回探索します:

 ```shell
 (for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done)  | sort | uniq
 ```

-The output is similar to this:
+結果は以下のようになります:

 ```shell
  "HOSTNAME": "guestbook-44sep",
@@ -375,11 +321,11 @@ The output is similar to this:
  "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:

@@ -397,4 +343,3 @@ KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b k
 KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
 ```

-
@@ -3,7 +3,6 @@ title: ノードのセットアップの検証
 weight: 30
 ---

-{{< toc >}}

 ## ノード適合テスト

@@ -26,7 +26,7 @@ MinikubeのサポートするKubernetesの機能:

 ## インストール

-[Minikubeのインストール](/ja/docs/tasks/tools/install-minikube/)を参照してください。
+ツールのインストールについて知りたい場合は、公式の[Get Started!](https://minikube.sigs.k8s.io/docs/start/)のガイドに従ってください。

 ## クイックスタート

@@ -50,7 +50,8 @@ MinikubeのサポートするKubernetesの機能:
   特定のKubernetesのバージョン、VM、コンテナランタイム上でクラスターを起動するための詳細は、[クラスターの起動](#starting-a-cluster)を参照してください。

 2. kubectlを使用してクラスターと対話できるようになります。詳細は[クラスターに触れてみよう](#interacting-with-your-cluster)を参照してください。
-単純なHTTPサーバーである`echoserver`という既存のイメージを使用して、Kubernetes Deploymentを作りましょう。そして`--port`を使用して8080番ポートで公開しましょう。
+
+   単純なHTTPサーバーである`echoserver`という既存のイメージを使用して、Kubernetes Deploymentを作りましょう。そして`--port`を使用して8080番ポートで公開しましょう。

   ```shell
   kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
@@ -69,6 +70,7 @@ MinikubeのサポートするKubernetesの機能:
   ```

   `--type=NodePort`オプションで、Serviceのタイプを指定します。
+
   出力はこのようになります:

   ```
@@ -78,6 +80,7 @@ MinikubeのサポートするKubernetesの機能:
 4. `hello-minikube`Podが起動開始されましたが、公開したService経由で接続する前にPodが起動完了になるまで待つ必要があります。

   Podが稼働しているか確認します:
+
   ```shell
   kubectl get pod
   ```
@@ -110,19 +113,19 @@ MinikubeのサポートするKubernetesの機能:
   Hostname: hello-minikube-7c77b68cff-8wdzq
   
   Pod Information:
-   	-no pod information available-
+    -no pod information available-
   
   Server values:
-   	server_version=nginx: 1.13.3 - lua: 10008
+    server_version=nginx: 1.13.3 - lua: 10008
   
   Request Information:
-   	client_address=172.17.0.1
-   	method=GET
-   	real path=/
-   	query=
-   	request_version=1.1
-   	request_scheme=http
-   	request_uri=http://192.168.99.100:8080/
+    client_address=172.17.0.1
+    method=GET
+    real path=/
+    query=
+    request_version=1.1
+    request_scheme=http
+    request_uri=http://192.168.99.100:8080/
   
   Request Headers:
   	accept=*/*
@@ -168,8 +171,8 @@ MinikubeのサポートするKubernetesの機能:
   出力はこのようになります:

   ```
-   Stopping local Kubernetes cluster...
   Stopping "minikube"...
+   "minikube" stopped.
   ```

   詳細は[クラスターの停止](#stopping-a-cluster)を参照ください。
@@ -222,24 +225,27 @@ minikube start --kubernetes-version {{< param "fullversion" >}}

 #### VMドライバーの指定

-もしVMドライバーを変更したい場合は、`--vm-driver=<enter_driver_name>`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。
+もしVMドライバーを変更したい場合は、`--driver=<enter_driver_name>`フラグを`minikube start`に設定してください。例えば、コマンドは以下のようになります。

 ```shell
-minikube start --vm-driver=<driver_name>
+minikube start --driver=<driver_name>
 ```

 Minikubeは以下のドライバーをサポートしています:
 {{< note >}}
-サポートされているドライバーとプラグインのインストールの詳細については[DRIVERS](https://git.k8s.io/minikube/docs/drivers.md)を参照してください。
+サポートされているドライバーとプラグインのインストールの詳細については[DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/)を参照してください。
 {{< /note >}}

-* virtualbox  
+* docker ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/docker/))
+* virtualbox ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/virtualbox/))
+* podman ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/podman/)) (実験的)
 * vmwarefusion
-* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver))
-* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver))
-* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
+* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/))
+* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/))
+* hyperv ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/))
 注意: 以下のIPは動的であり、変更される可能性があります。IPは`minikube ip`で取得することができます。
 * vmware ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) (VMware unified driver)
+* parallels ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/))
 * none (VMではなくホスト上でKubernetesコンポーネントを起動。このドライバーを使用するには{{< glossary_tooltip term_id="docker" >}}とLinux環境を必要とします)

 {{< caution >}}
@@ -372,7 +378,12 @@ Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡し
 このコマンドはMinikube仮想マシンをシャットダウンして削除します。データや状態は保存されません。

 ### minikubeのアップグレード {#upgrading-minikube}
-[minikubeのアップグレード](https://minikube.sigs.k8s.io/docs/start/macos/)を参照してください。
+macOSを使用し[Brew Package Manager](https://brew.sh/)がインストールされている場合、以下を実行します:
+
+```shell
+brew update
+brew upgrade minikube
+```

 ## クラスターに触れてみよう {#interacting-with-your-cluster}

@@ -383,9 +394,11 @@ Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡し

 Minikubeはこのコンテキストを自動的にデフォルトに設定しますが、将来的に設定を切り戻す場合には次のコマンドを実行してください:

-`kubectl config use-context minikube`,
+`kubectl config use-context minikube`

-もしくは各コマンドにコンテキストを次のように渡します: `kubectl get pods --context=minikube`
+もしくは各コマンドにコンテキストを次のように渡します:
+
+ `kubectl get pods --context=minikube`

 ### ダッシュボード

@@ -500,13 +513,13 @@ Minikubeの詳細については、[proposal](https://git.k8s.io/community/contr

 ## 追加リンク集

-* **目標と非目標**: Minikubeプロジェクトの目標と非目標については、[ロードマップ](https://git.k8s.io/minikube/docs/contributors/roadmap.md)を参照してください。
-* **開発ガイド**: プルリクエストを送る方法の概要については、[CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md)を参照してください。
-* **Minikubeのビルド**: Minikubeをソースからビルド/テストする方法については、[ビルドガイド](https://git.k8s.io/minikube/docs/contributors/build_guide.md)を参照してください。
-* **新しい依存性の追加**: Minikubeに新しい依存性を追加する方法については、[依存性追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)を参照してください。
-* **新しいアドオンの追加**: Minikubeに新しいアドオンを追加する方法については、[アドオン追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)を参照してください。
+* **目標と非目標**: Minikubeプロジェクトの目標と非目標については、[ロードマップ](https://minikube.sigs.k8s.io/docs/contrib/roadmap/)を参照してください。
+* **開発ガイド**: プルリクエストを送る方法の概要については、[コントリビュートする](https://minikube.sigs.k8s.io/docs/contrib/)を参照してください。
+* **Minikubeのビルド**: Minikubeをソースからビルド/テストする方法については、[ビルドガイド](https://minikube.sigs.k8s.io/docs/contrib/building/)を参照してください。
+* **新しい依存性の追加**: Minikubeに新しい依存性を追加する方法については、[依存性追加ガイド](https://minikube.sigs.k8s.io/docs/contrib/drivers/)を参照してください。
+* **新しいアドオンの追加**: Minikubeに新しいアドオンを追加する方法については、[アドオン追加ガイド](https://minikube.sigs.k8s.io/docs/contrib/addons/)を参照してください。
 * **MicroK8s**: 仮想マシンを実行したくないLinuxユーザーは代わりに[MicroK8s](https://microk8s.io/)を検討してみてください。

 ## コミュニティ

-コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の#minikubeチャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。
+コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の`#minikube`チャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。
@@ -18,8 +18,7 @@ Podのコンテナを実行するために、Kubernetesはコンテナランタ
 悪意のあるコンテナがこの脆弱性を利用してruncのバイナリを上書きし、
 コンテナホストシステム上で任意のコマンドを実行する可能性があります。

-この問題の更なる情報は以下のリンクを参照してください。
-[cve-2019-5736 : runc vulnerability](https://access.redhat.com/security/cve/cve-2019-5736)
+この問題の更なる情報は[CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736)を参照してください。
 {{< /caution >}}

 ### 適用性
@@ -60,34 +59,44 @@ kubeletを再起動しても問題は解決しないでしょう。
 ## Docker

 それぞれのマシンに対してDockerをインストールします。
-バージョン19.03.4が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。
+バージョン19.03.11が推奨されていますが、1.13.1、17.03、17.06、17.09、18.06、18.09についても動作が確認されています。
 Kubernetesのリリースノートにある、Dockerの動作確認済み最新バージョンについてもご確認ください。

 システムへDockerをインストールするには、次のコマンドを実行します。

 {{< tabs name="tab-cri-docker-installation" >}}
-{{< tab name="Ubuntu 16.04+" codelang="bash" >}}
-# Docker CEのインストール
+{{% tab name="Ubuntu 16.04+" %}}
+
+```shell
+# (Install Docker CE)
 ## リポジトリをセットアップ
 ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール
 apt-get update && apt-get install -y \
  apt-transport-https ca-certificates curl software-properties-common gnupg2
+```

-### Docker公式のGPG鍵を追加
+```shell
+# Docker公式のGPG鍵を追加:
 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
+```

-### Dockerのaptリポジトリを追加
+```shell
+# Dockerのaptレポジトリを追加:
 add-apt-repository \
  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) \
  stable"
+```

-## Docker CEのインストール
+```shell
+# Docker CEのインストール
 apt-get update && apt-get install -y \
-  containerd.io=1.2.10-3 \
-  docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \
-  docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs)
+containerd.io=1.2.13-2 \
+docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
+docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
+```

+```shell
 # デーモンをセットアップ
 cat > /etc/docker/daemon.json <<EOF
 {
@@ -99,33 +108,47 @@ cat > /etc/docker/daemon.json <<EOF
  "storage-driver": "overlay2"
 }
 EOF
+```

+```shell
 mkdir -p /etc/systemd/system/docker.service.d
+```

+```shell
 # dockerを再起動
 systemctl daemon-reload
 systemctl restart docker
-{{< /tab >}}
-{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
+```
+{{% /tab %}}
+{{% tab name="CentOS/RHEL 7.4+" %}}

-# Docker CEのインストール
+```shell
+# (Docker CEのインストール)
 ## リポジトリをセットアップ
 ### 必要なパッケージのインストール
 yum install -y yum-utils device-mapper-persistent-data lvm2
+```

-### Dockerリポジトリの追加
+```shell
+## Dockerリポジトリの追加
 yum-config-manager --add-repo \
  https://download.docker.com/linux/centos/docker-ce.repo
+```

+```shell
 ## Docker CEのインストール
 yum update -y && yum install -y \
-  containerd.io-1.2.10 \
-  docker-ce-19.03.4 \
-  docker-ce-cli-19.03.4
+  containerd.io-1.2.13 \
+  docker-ce-19.03.11 \
+  docker-ce-cli-19.03.11
+```

+```shell
 ## /etc/docker ディレクトリを作成
 mkdir /etc/docker
+```

+```shell
 # デーモンをセットアップ
 cat > /etc/docker/daemon.json <<EOF
 {
@@ -140,15 +163,26 @@ cat > /etc/docker/daemon.json <<EOF
  ]
 }
 EOF
+```

+```shell
 mkdir -p /etc/systemd/system/docker.service.d
+```

+```shell
 # dockerを再起動
 systemctl daemon-reload
 systemctl restart docker
-{{< /tab >}}
+```
+{{% /tab %}}
 {{< /tabs >}}

+ブート時にDockerサービスを開始させたい場合は、以下のコマンドを入力してください:
+
+```shell
+sudo systemctl enable docker
+```
+
 詳細については、[Dockerの公式インストールガイド](https://docs.docker.com/engine/installation/)を参照してください。

 ## CRI-O
@@ -179,54 +213,112 @@ sysctl --system
 ```

 {{< tabs name="tab-cri-cri-o-installation" >}}
-{{< tab name="Debian" codelang="bash" >}}
-# Debian Unstable/Sid
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add -
+{{% tab name="Debian" %}}

-# Debian Testing
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add -
+ CRI-Oを以下のOSにインストールするには、環境変数$OSを以下の表の適切なフィールドに設定します。

-# Debian 10
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add -
+| Operating system | $OS               |
+| ---------------- | ----------------- |
+| Debian Unstable  | `Debian_Unstable` |
+| Debian Testing   | `Debian_Testing`  |

-# Raspbian 10
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add -
+<br />
+そして、`$VERSION`にKubernetesのバージョンに合わせたCRI-Oのバージョンを設定します。例えば、CRI-O 1.18をインストールしたい場合は、`VERSION=1.18` を設定します。インストールを特定のリリースに固定することができます。バージョン 1.18.3をインストールするには、`VERSION=1.18:1.18.3` を設定します。
+<br />

-# CRI-Oのインストール
-sudo apt-get install cri-o-1.17
-{{< /tab >}}
+以下を実行します。
+```shell
+echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list

-{{< tab name="Ubuntu 18.04, 19.04 and 19.10" codelang="bash" >}}
-# リポジトリの設定
-. /etc/os-release
-sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add -
-sudo apt-get update
+curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add -
+curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add -

-# CRI-Oのインストール
-sudo apt-get install cri-o-1.17
-{{< /tab >}}
+apt-get update
+apt-get install cri-o cri-o-runc
+```

-{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
-# 必要なパッケージのインストール
-yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
+{{% /tab %}}

-# CRI-Oのインストール
-yum install --nogpgcheck -y cri-o
-{{< /tab >}}
+{{% tab name="Ubuntu" %}}

-{{< tab name="openSUSE Tumbleweed" codelang="bash" >}}
-sudo zypper install cri-o
-{{< /tab >}}
+ CRI-Oを以下のOSにインストールするには、環境変数$OSを以下の表の適切なフィールドに設定します。
+
+| Operating system | $OS               |
+| ---------------- | ----------------- |
+| Ubuntu 20.04     | `xUbuntu_20.04`   |
+| Ubuntu 19.10     | `xUbuntu_19.10`   |
+| Ubuntu 19.04     | `xUbuntu_19.04`   |
+| Ubuntu 18.04     | `xUbuntu_18.04`   |
+
+<br />
+次に、`$VERSION`をKubernetesのバージョンと一致するCRI-Oのバージョンに設定します。例えば、CRI-O 1.18をインストールしたい場合は、`VERSION=1.18` を設定します。インストールを特定のリリースに固定することができます。バージョン 1.18.3 をインストールするには、`VERSION=1.18:1.18.3` を設定します。
+<br />
+
+以下を実行します。
+```shell
+echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
+
+curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add -
+curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add -
+
+apt-get update
+apt-get install cri-o cri-o-runc
+```
+{{% /tab %}}
+
+{{% tab name="CentOS" %}}
+
+ CRI-Oを以下のOSにインストールするには、環境変数$OSを以下の表の適切なフィールドに設定します。
+
+| Operating system | $OS               |
+| ---------------- | ----------------- |
+| Centos 8         | `CentOS_8`        |
+| Centos 8 Stream  | `CentOS_8_Stream` |
+| Centos 7         | `CentOS_7`        |
+
+<br />
+次に、`$VERSION`をKubernetesのバージョンと一致するCRI-Oのバージョンに設定します。例えば、CRI-O 1.18 をインストールしたい場合は、`VERSION=1.18` を設定します。インストールを特定のリリースに固定することができます。バージョン 1.18.3 をインストールするには、`VERSION=1.18:1.18.3` を設定します。
+<br />
+
+以下を実行します。
+```shell
+curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
+curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
+yum install cri-o
+```
+
+{{% /tab %}}
+
+{{% tab name="openSUSE Tumbleweed" %}}
+
+```shell
+ sudo zypper install cri-o
+```
+{{% /tab %}}
+{{% tab name="Fedora" %}}
+
+$VERSIONには、Kubernetesのバージョンと一致するCRI-Oのバージョンを設定します。例えば、CRI-O 1.18をインストールしたい場合は、$VERSION=1.18を設定します。
+以下のコマンドで、利用可能なバージョンを見つけることができます。
+```shell
+dnf module list cri-o
+```
+CRI-OはFedoraの特定のリリースにピン留めすることをサポートしていません。
+
+以下を実行します。
+```shell
+dnf module enable cri-o:$VERSION
+dnf install cri-o
+```
+
+{{% /tab %}}
 {{< /tabs >}}

+
 ### CRI-Oの起動

-```
+```shell
 systemctl daemon-reload
 systemctl start crio
 ```
@@ -263,52 +355,76 @@ sysctl --system
 ### containerdのインストール

 {{< tabs name="tab-cri-containerd-installation" >}}
-{{< tab name="Ubuntu 16.04" codelang="bash" >}}
-# containerdのインストール
+{{% tab name="Ubuntu 16.04" %}}
+
+```shell
+# (containerdのインストール)
 ## リポジトリの設定
 ### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール
 apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
+```

-### Docker公式のGPG鍵を追加
+```shell
+## Docker公式のGPG鍵を追加
 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
+```

-### Dockerのaptリポジトリの追加
+```shell
+## Dockerのaptリポジトリの追加
 add-apt-repository \
    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
    $(lsb_release -cs) \
    stable"
+```

+```shell
 ## containerdのインストール
 apt-get update && apt-get install -y containerd.io
+```

+```shell
 # containerdの設定
 mkdir -p /etc/containerd
 containerd config default > /etc/containerd/config.toml
+```

+```shell
 # containerdの再起動
 systemctl restart containerd
-{{< /tab >}}
-{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
-# containerdのインストール
+```
+{{% /tab %}}
+{{% tab name="CentOS/RHEL 7.4+" %}}
+
+```shell
+# (containerdのインストール)
 ## リポジトリの設定
 ### 必要なパッケージのインストール
 yum install -y yum-utils device-mapper-persistent-data lvm2
+```

-### Dockerのリポジトリの追加
+```shell
+## Dockerのリポジトリの追加
 yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo
+```

+```shell
 ## containerdのインストール
 yum update -y && yum install -y containerd.io
+```

-# containerdの設定
+```shell
+## containerdの設定
 mkdir -p /etc/containerd
 containerd config default > /etc/containerd/config.toml
+```

+```shell
 # containerdの再起動
 systemctl restart containerd
-{{< /tab >}}
+```
+{{% /tab %}}
 {{< /tabs >}}

 ### systemd
@@ -7,7 +7,7 @@ content_type: concept

 [CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes.

-[CoreOS](http://coreos.com) templates for CloudStack are built [nightly](http://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.
+[CoreOS](https://coreos.com) templates for CloudStack are built [nightly](https://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](https://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.

 This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init.

@@ -27,7 +27,7 @@ kops is an automated provisioning system:

 * You must [install](https://github.com/kubernetes/kops#installing) `kops` on a 64-bit (AMD64 and Intel 64) device architecture.

-* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them.
+* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them. The IAM user will need [adequate permissions](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user).



@@ -140,7 +140,7 @@ you choose for organization reasons (e.g. you are allowed to create records unde
 but not under `example.com`).

 Let's assume you're using `dev.example.com` as your hosted zone.  You create that hosted zone using
-the [normal process](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
+the [normal process](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
 with a command such as `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`.

 You must then set up your NS records in the parent domain, so that records in the domain will resolve.  Here,
@@ -231,7 +231,7 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl
 ## {{% heading "whatsnext" %}}


-* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/).
 * Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options.
 * Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors)
 * Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues)
@@ -1,12 +1,12 @@
 ---
-title: kubeadmを使用したシングルコントロールプレーンクラスターの作成
+title: kubeadmを使用したクラスターの作成
 content_type: task
 weight: 30
 ---

 <!-- overview -->

-<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">`kubeadm`ツールは、ベストプラクティスに準拠した実用最小限のKubernetesクラスターをブートストラップする手助けをします。実際、`kubeadm`を使用すれば、[Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification)に通るクラスターをセットアップすることができます。`kubeadm`は、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)やクラスターのアップグレードなどのその他のクラスターのライフサイクルの機能もサポートします。
+<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">ベストプラクティスに準拠した実用最小限のKubernetesクラスターを作成します。実際、`kubeadm`を使用すれば、[Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification)に通るクラスターをセットアップすることができます。`kubeadm`は、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)やクラスターのアップグレードなどのその他のクラスターのライフサイクルの機能もサポートします。

 `kubeadm`ツールは、次のようなときに適しています。

@@ -41,7 +41,7 @@ kubeadmツールの全体の機能の状態は、一般利用可能(GA)です。

 ## 目的

-* シングルコントロールプレーンのKubernetesクラスターまたは[高可用性クラスター](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)をインストールする
+* シングルコントロールプレーンのKubernetesクラスターをインストールする
 * クラスター上にPodネットワークをインストールして、Podがお互いに通信できるようにする

 ## 手順
@@ -63,7 +63,7 @@ kubeadmツールの全体の機能の状態は、一般利用可能(GA)です。
 1. (推奨)シングルコントロールプレーンの`kubeadm`クラスターを高可用性クラスターにアップグレードする予定がある場合、`--control-plane-endpoint`を指定して、すべてのコントロールプレーンノードとエンドポイントを共有する必要があります。エンドポイントにはDNSネームやロードバランサーのIPアドレスが使用できます。
 1. Podネットワークアドオンを選んで、`kubeadm init`に引数を渡す必要があるかどうか確認してください。選んだサードパーティーのプロバイダーによっては、`--pod-network-cidr`をプロバイダー固有の値に設定する必要がある場合があります。詳しくは、[Podネットワークアドオンのインストール](#pod-network)を参照してください。
 1. (オプション)バージョン1.14から、`kubeadm`はよく知られたドメインソケットのパスリストを用いて、Linux上のコンテナランタイムの検出を試みます。異なるコンテナランタイムを使用する場合やプロビジョニングするノードに2つ以上のランタイムがインストールされている場合、`kubeadm init`に`--cri-socket`引数を指定してください。詳しくは、[ランタイムのインストール](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime)を読んでください。
-1. (オプション)明示的に指定しない限り、`kubeadm`はデフォルトゲートウェイに関連付けられたネットワークインターフェイスを使用して、この特定のコントロールプレーンノードのAPIサーバーのadvertise addressを設定します。異なるネットワークインターフェイスを使用するには、`kubeadm init`に`--apiserver-advertize-address=<ip-address>`引数を指定してください。IPv6アドレスを使用するIPv6 Kubernetesクラスターをデプロイするには、たとえば`--apiserver-advertise-address=fd00::101`のように、IPv6アドレスを指定する必要があります。
+1. (オプション)明示的に指定しない限り、`kubeadm`はデフォルトゲートウェイに関連付けられたネットワークインターフェイスを使用して、この特定のコントロールプレーンノードのAPIサーバーのadvertise addressを設定します。異なるネットワークインターフェイスを使用するには、`kubeadm init`に`--apiserver-advertise-address=<ip-address>`引数を指定してください。IPv6アドレスを使用するIPv6 Kubernetesクラスターをデプロイするには、たとえば`--apiserver-advertise-address=fd00::101`のように、IPv6アドレスを指定する必要があります。
 1. (オプション)`kubeadm init`を実行する前に`kubeadm config images pull`を実行して、gcr.ioコンテナイメージレジストリに接続できるかどうかを確認します。

 コントロールプレーンノードを初期化するには、次のコマンドを実行します。
@@ -76,7 +76,7 @@ kubeadm init <args>

 `--apiserver-advertise-address`は、この特定のコントロールプレーンノードのAPIサーバーへのadvertise addressを設定するために使えますが、`--control-plane-endpoint`は、すべてのコントロールプレーンノード共有のエンドポイントを設定するために使えます。

-`--control-plane-endpoint`はIPアドレスを受け付けますが、IPアドレスへマッピングされるDNSネームも使用できます。利用可能なソリューションをそうしたマッピングの観点から評価するには、ネットワーク管理者に相談してください。
+`--control-plane-endpoint`はIPアドレスと、IPアドレスへマッピングできるDNS名を使用できます。利用可能なソリューションをそうしたマッピングの観点から評価するには、ネットワーク管理者に相談してください。

 以下にマッピングの例を示します。

@@ -203,9 +203,14 @@ export KUBECONFIG=/etc/kubernetes/admin.conf

 {{< /caution >}}

-CNIを使用するKubernetes Podネットワークを提供する外部のプロジェクトがいくつかあります。一部のプロジェクトでは、[ネットワークポリシー](/docs/concepts/services-networking/networkpolicies/)もサポートしています。
+{{< note >}}
+現在、Calicoはkubeadmプロジェクトがe2eテストを実施している唯一のCNIプラグインです。
+もしCNIプラグインに関する問題を見つけた場合、kubeadmやkubernetesではなく、そのCNIプラグインの課題管理システムへ問題を報告してください。
+{{< /note >}}

-利用できる[ネットワークアドオンとネットワークポリシーアドオン](/docs/concepts/cluster-administration/addons/#networking-and-network-policy)のリストを確認してください。
+CNIを使用するKubernetes Podネットワークを提供する外部のプロジェクトがいくつかあります。一部のプロジェクトでは、[ネットワークポリシー](/ja/docs/concepts/services-networking/network-policies/)もサポートしています。
+
+[Kubernetesのネットワークモデル](/ja/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model)を実装したアドオンの一覧も確認してください。

 Podネットワークアドオンをインストールするには、コントロールプレーンノード上またはkubeconfigクレデンシャルを持っているノード上で、次のコマンドを実行します。

@@ -213,91 +218,7 @@ Podネットワークアドオンをインストールするには、コント
 kubectl apply -f <add-on.yaml>
 ```

-インストールできるPodネットワークは、クラスターごとに1つだけです。以下の手順で、いくつかのよく使われるPodネットワークプラグインをインストールできます。
-
-{{< tabs name="tabs-pod-install" >}}
-
-{{% tab name="Calico" %}}
-[Calico](https://docs.projectcalico.org/latest/introduction/)は、ネットワークとネットワークポリシーのプロバイダーです。Calicoは柔軟なさまざまなネットワークオプションをサポートするため、自分の状況に適した最も効果的なオプションを選択できます。たとえば、ネットワークのオーバーレイの有無や、BGPの有無が選べます。Calicoは、ホスト、Pod、(もしIstioとEnvoyを使っている場合)サービスメッシュレイヤー上のアプリケーションに対してネットワークポリシーを強制するために、同一のエンジンを使用しています。Calicoは、`amd64`、`arm64`、`ppc64le`を含む複数のアーキテクチャで動作します。
-
-デフォルトでは、Calicoは`192.168.0.0/16`をPodネットワークのCIDRとして使いますが、このCIDRはcalico.yamlファイルで設定できます。Calicoを正しく動作させるためには、これと同じCIDRを`--pod-network-cidr=192.168.0.0/16`フラグまたはkubeadmの設定を使って、`kubeadm init`コマンドに渡す必要があります。
-
-```shell
-kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml
-```
-
-{{% /tab %}}
-
-{{% tab name="Cilium" %}}
-Ciliumを正しく動作させるためには、`kubeadm init`に `--pod-network-cidr=10.217.0.0/16`を渡さなければなりません。
-
-Ciliumのデプロイは、次のコマンドを実行するだけでできます。
-
-```shell
-kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
-```
-
-すべてのCilium Podが`READY`とマークされたら、クラスターを使い始められます。
-
-```shell
-kubectl get pods -n kube-system --selector=k8s-app=cilium
-```
-
-出力は次のようになります。
-
-```
-NAME           READY   STATUS    RESTARTS   AGE
-cilium-drxkl   1/1     Running   0          18m
-```
-
-Ciliumはkube-proxyの代わりに利用することもできます。詳しくは[Kubernetes without kube-proxy](https://docs.cilium.io/en/stable/gettingstarted/kubeproxy-free)を読んでください。
-
-KubernetesでのCiliumの使い方に関するより詳しい情報は、[Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/)を参照してください。
-{{% /tab %}}
-
-{{% tab name="Contiv-VPP" %}}
-[Contiv-VPP](https://contivpp.io/)は、[FD.io VPP](https://fd.io/)をベースとするプログラマブルなCNF vSwitchを採用し、機能豊富で高性能なクラウドネイティブなネットワーキングとサービスを提供します。
-
-Contiv-VPPは、k8sサービスとネットワークポリシーを(VPP上の)ユーザースペースで実装しています。
-
-こちらのインストールガイドを参照してください: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md)
-{{% /tab %}}
-
-{{% tab name="Flannel" %}}
-`flannel`を正しく動作させるためには、`--pod-network-cidr=10.244.0.0/16`を`kubeadm init`に渡す必要があります。
-
-オーバーレイネットワークに参加しているすべてのホスト上で、ファイアウォールのルールが、UDPポート8285と8472のトラフィックを許可するように設定されていることを確認してください。この設定に関するより詳しい情報は、Flannelのトラブルシューティングガイドの[Firewall](https://coreos.com/flannel/docs/latest/troubleshooting.html#firewalls)のセクションを参照してください。
-
-Flannelは、Linux下の`amd64`、`arm`、`arm64`、`ppc64le`、`s390x`アーキテクチャ上で動作します。Windows(`amd64`)はv0.11.0でサポートされたとされていますが、使用方法はドキュメントに書かれていません。
-
-```shell
-kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.yml
-```
-
-`flannel`に関するより詳しい情報は、[GitHub上のCoreOSのflannelリポジトリ](https://github.com/coreos/flannel)を参照してください。
-{{% /tab %}}
-
-{{% tab name="Kube-router" %}}
-Kube-routerは、ノードへのPod CIDRの割り当てをkube-controller-managerに依存しています。そのため、`kubeadm init`時に`--pod-network-cidr`フラグを使用する必要があります。
-
-Kube-routerは、Podネットワーク、ネットワークポリシー、および高性能なIP Virtual Server(IPVS)/Linux Virtual Server(LVS)ベースのサービスプロキシーを提供します。
-
-Kube-routerを有効にしたKubernetesクラスターをセットアップするために`kubeadm`ツールを使用する方法については、公式の[セットアップガイド](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md)を参照してください。
-{{% /tab %}}
-
-{{% tab name="Weave Net" %}}
-Weave Netを使用してKubernetesクラスターをセットアップするより詳しい情報は、[アドオンを使用してKubernetesを統合する](https://www.weave.works/docs/net/latest/kube-addon/)を読んでください。
-
-Weave Netは、`amd64`、`arm`、`arm64`、`ppc64le`プラットフォームで追加の操作なしで動作します。Weave Netはデフォルトでharipinモードをセットします。このモードでは、Pod同士はPodIPを知らなくても、Service IPアドレス経由でアクセスできます。
-
-```shell
-kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
-```
-
-{{% /tab %}}
-
-{{< /tabs >}}
-
+インストールできるPodネットワークは、クラスターごとに1つだけです。

 Podネットワークがインストールされたら、`kubectl get pods --all-namespaces`の出力結果でCoreDNS Podが`Running`状態であることをチェックすることで、ネットワークが動作していることを確認できます。そして、一度CoreDNS Podが動作すれば、続けてノードを追加できます。

@@ -375,7 +296,7 @@ openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outfor
 ```

 {{< note >}}
-IPv6タプルを`<control-plane-host>:<control-plane-ip>`に指定するためには、IPv6アドレスをブラケットで囲みます。たとえば、`[fd00::101]:2073`のように書きます。
+IPv6タプルを`<control-plane-host>:<control-plane-port>`と指定するためには、IPv6アドレスを角括弧で囲みます。たとえば、`[fd00::101]:2073`のように書きます。
 {{< /note >}}

 出力は次のようになります。
@@ -407,7 +328,7 @@ kubectl --kubeconfig ./admin.conf get nodes
 {{< note >}}
 上の例では、rootユーザーに対するSSH接続が有効であることを仮定しています。もしそうでない場合は、`admin.conf`ファイルを誰か他のユーザーからアクセスできるようにコピーした上で、代わりにそのユーザーを使って`scp`してください。

-`admin.conf`ファイルはユーザーにクラスターに対する _特権ユーザー_ の権限を与えます。そのため、このファイルを使うのは控えめにしなければなりません。通常のユーザーには、一部の権限をホワイトリストに加えたユニークなクレデンシャルを生成することを推奨します。これには、`kubeadm alpha kubeconfig user --client-name <CN>`コマンドが使えます。このコマンドを実行すると、KubeConfigファイルがSTDOUTに出力されるので、ファイルに保存してユーザーに配布します。その後、`kubectl create (cluster)rolebinding`コマンドを使って権限をホワイトリストに加えます。
+`admin.conf`ファイルはユーザーにクラスターに対する _特権ユーザー_ の権限を与えます。そのため、このファイルを使うのは控えめにしなければなりません。通常のユーザーには、明示的に許可した権限を持つユニークなクレデンシャルを生成することを推奨します。これには、`kubeadm alpha kubeconfig user --client-name <CN>`コマンドが使えます。このコマンドを実行すると、KubeConfigファイルがSTDOUTに出力されるので、ファイルに保存してユーザーに配布します。その後、`kubectl create (cluster)rolebinding`コマンドを使って権限を付与します。
 {{< /note >}}

 ### (オプション)APIサーバーをlocalhostへプロキシする
@@ -433,10 +354,9 @@ kubectl --kubeconfig ./admin.conf proxy

 ```bash
 kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
-kubectl delete node <node name>
 ```

-その後、ノードが削除されたら、`kubeadm`のインストール状態をすべてリセットします。
+ノードが削除される前に、`kubeadm`によってインストールされた状態をリセットします。

 ```bash
 kubeadm reset
@@ -454,6 +374,11 @@ IPVS tablesをリセットしたい場合は、次のコマンドを実行する
 ipvsadm -C
 ```

+ノードを削除します。
+```bash
+kubectl delete node <node name>
+```
+
 クラスターのセットアップを最初から始めたいときは、`kubeadm init`や`kubeadm join`を適切な引数を付けて実行すればいいだけです。

 ### コントロールプレーンのクリーンアップ
@@ -469,7 +394,7 @@ ipvsadm -C
 * [Sonobuoy](https://github.com/heptio/sonobuoy)を使用してクラスターが適切に動作しているか検証する。
 * <a id="lifecycle" />`kubeadm`を使用したクラスターをアップグレードする方法について、[kubeadmクラスターをアップグレードする](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を読む。
 * `kubeadm`の高度な利用方法について[kubeadmリファレンスドキュメント](/docs/reference/setup-tools/kubeadm/kubeadm)で学ぶ。
-* Kubernetesの[コンセプト](/ja/docs/concepts/)や[`kubectl`](/docs/user-guide/kubectl-overview/)についてもっと学ぶ。
+* Kubernetesの[コンセプト](/ja/docs/concepts/)や[`kubectl`](/ja/docs/reference/kubectl/overview/)についてもっと学ぶ。
 * Podネットワークアドオンのより完全なリストを[クラスターのネットワーク](/docs/concepts/cluster-administration/networking/)で確認する。
 * <a id="other-addons" />ロギング、モニタリング、ネットワークポリシー、仮想化、Kubernetesクラスターの制御のためのツールなど、その他のアドオンについて、[アドオンのリスト](/docs/concepts/cluster-administration/addons/)で確認する。
 * クラスターイベントやPod内で実行中のアプリケーションから送られるログをクラスターがハンドリングする方法を設定する。関係する要素の概要を理解するために、[ロギングのアーキテクチャ](/docs/concepts/cluster-administration/logging/)を読んでください。
@@ -486,9 +411,9 @@ ipvsadm -C

 ## バージョン互換ポリシー {#version-skew-policy}

-バージョンvX.Yの`kubeadm`ツールは、バージョンvX.YまたはvX.(Y-1)のコントロールプレーンを持つクラスターをデプロイできます。また、`kubeadm` vX.Yは、kubeadmで構築された既存のvX.(Y-1)のクラスターをアップグレートできます。
+バージョンv{{< skew latestVersion >}}の`kubeadm`ツールは、バージョンv{{< skew latestVersion >}}またはv{{< skew prevMinorVersion >}}のコントロールプレーンを持つクラスターをデプロイできます。また、バージョンv{{< skew latestVersion >}}の`kubeadm`は、バージョンv{{< skew prevMinorVersion >}}のkubeadmで構築されたクラスターをアップグレートできます。

-未来を見ることはできないため、kubeadm CLI vX.YはvX.(Y+1)をデプロイすることはできません。
+未来を見ることはできないため、kubeadm CLI v{{< skew latestVersion >}}はv{{< skew nextMinorVersion >}}をデプロイできないかもしれません。

 例: `kubeadm` v1.8は、v1.7とv1.8のクラスターをデプロイでき、v1.7のkubeadmで構築されたクラスターをv1.8にアップグレートできます。

@@ -507,7 +432,7 @@ kubeletとコントロールプレーンの間や、他のKubernetesコンポー

 * 定期的に[etcdをバックアップ](https://coreos.com/etcd/docs/latest/admin_guide.html)する。kubeadmが設定するetcdのデータディレクトリは、コントロールプレーンノードの`/var/lib/etcd`にあります。

-* 複数のコントロールプレーンノードを使用する。[高可用性トポロジーのオプション](/docs/setup/production-environment/tools/kubeadm/ha-topology/)では、より高い可用性を提供するクラスターのトポロジーの選択について説明してます。
+* 複数のコントロールプレーンノードを使用する。[高可用性トポロジーのオプション](/ja/docs/setup/production-environment/tools/kubeadm/ha-topology/)では、[より高い可用性](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)を提供するクラスターのトポロジーの選択について説明してます。

 ### プラットフォームの互換性 {#multi-platform}

@@ -520,4 +445,3 @@ kubeadmのdeb/rpmパッケージおよびバイナリは、[multi-platform propo
 ## トラブルシューティング {#troubleshooting}

 kubeadmに関する問題が起きたときは、[トラブルシューティングドキュメント](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)を確認してください。
-
@@ -15,7 +15,10 @@ HAクラスターは次の方法で設定できます。

 HAクラスターをセットアップする前に、各トポロジーの利点と欠点について注意深く考慮する必要があります。

-
+{{< note >}}
+kubeadmは、etcdクラスターを静的にブートストラップします。
+詳細については、etcd[クラスタリングガイド](https://github.com/etcd-io/etcd/blob/release-3.4/Documentation/op-guide/clustering.md#static)をご覧ください。
+{{< /note >}}

 <!-- body -->

@@ -57,10 +57,10 @@ weight: 60

    - ロードバランサーは、apiserverポートで、全てのコントロールプレーンノードと通信できなければなりません。また、リスニングポートに対する流入トラフィックも許可されていなければなりません。

-    - [HAProxy](http://www.haproxy.org/)をロードバランサーとして使用することができます。
-
    - ロードバランサーのアドレスは、常にkubeadmの`ControlPlaneEndpoint`のアドレスと一致することを確認してください。

+    - 詳細は[Options for Software Load Balancing](https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing)をご覧ください。
+
 1.  ロードバランサーに、最初のコントロールプレーンノードを追加し、接続をテストする:

    ```sh
@@ -87,7 +87,7 @@ weight: 60

    {{< note >}}`kubeadm init`の`--config`フラグと`--certificate-key`フラグは混在させることはできないため、[kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)を使用する場合は`certificateKey`フィールドを適切な場所に追加する必要があります(`InitConfiguration`と`JoinConfiguration: controlPlane`の配下)。{{< /note >}}

-    {{< note >}}CalicoなどのいくつかのCNIネットワークプラグインは`192.168.0.0/16`のようなCIDRを必要としますが、Weaveなどは必要としません。[CNIネットワークドキュメント](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)を参照してください。PodにCIDRを設定するには、`ClusterConfiguration`の`networking`オブジェクトに`podSubnet: 192.168.0.0/16`フィールドを設定してください。{{< /note >}}
+    {{< note >}}いくつかのCNIネットワークプラグインはPodのIPのCIDRの指定など追加の設定を必要としますが、必要としないプラグインもあります。[CNIネットワークドキュメント](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)を参照してください。PodにCIDRを設定するには、`ClusterConfiguration`の`networking`オブジェクトに`podSubnet: 192.168.0.0/16`フィールドを設定してください。{{< /note >}}

    - このような出力がされます:

@@ -64,7 +64,7 @@ ComponentConfigの詳細については、[このセクション](#configure-kub

 ### `kubeadm init`実行時の流れ

-`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`.X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスタ内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。
+`kubeadm init`を実行した場合、kubeletの設定は`/var/lib/kubelet/config.yaml`に格納され、クラスターのConfigMapにもアップロードされます。ConfigMapは`kubelet-config-1.X`という名前で、`X`は初期化するKubernetesのマイナーバージョンを表します。またこの設定ファイルは、クラスタ内の全てのkubeletのために、クラスター全体設定の基準と共に`/etc/kubernetes/kubelet.conf`にも書き込まれます。この設定ファイルは、kubeletがAPIサーバと通信するためのクライアント証明書を指し示します。これは、[各kubeletにクラスターレベルの設定を配布](#propagating-cluster-level-configuration-to-each-kubelet)することの必要性を示しています。

 二つ目のパターンである、[インスタンス固有の設定内容を適用](#providing-instance-specific-configuration-details)するために、kubeadmは環境ファイルを`/var/lib/kubelet/kubeadm-flags.env`へ書き出します。このファイルは以下のように、kubelet起動時に渡されるフラグのリストを含んでいます。

@@ -99,7 +99,7 @@ kubeletが新たな設定を読み込むと、kubeadmは、KubeConfigファイ
 `kubeadm`には、systemdがどのようにkubeletを実行するかを指定した設定ファイルが同梱されています。
 kubeadm CLIコマンドは決してこのsystemdファイルには触れないことに注意してください。

-kubeadmの[DEBパッケージ](https://github.com/kubernetes/kubernetes/blob/master/build/debs/10-kubeadm.conf)または[RPMパッケージ](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/10-kubeadm.conf)によってインストールされたこの設定ファイルは、`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`に書き込まれ、systemdで使用されます。基本的な`kubelet.service`([RPM用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service)または、 [DEB用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service))を拡張します。
+kubeadmの[DEBパッケージ](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf)または[RPMパッケージ](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubeadm/10-kubeadm.conf)によってインストールされたこの設定ファイルは、`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf`に書き込まれ、systemdで使用されます。基本的な`kubelet.service`([RPM用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service)または、 [DEB用](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service))を拡張します。

 ```none
 [Service]
@@ -134,6 +134,5 @@ Kubernetesに同梱されるDEB、RPMのパッケージは以下の通りです
 | `kubeadm`    | `/usr/bin/kubeadm`CLIツールと、[kubelet用のsystemdファイル](#the-kubelet-drop-in-file-for-systemd)をインストールします。 |
 | `kubelet`    | kubeletバイナリを`/usr/bin`に、CNIバイナリを`/opt/cni/bin`にインストールします。 |
 | `kubectl`    | `/usr/bin/kubectl`バイナリをインストールします。 |
-| `kubernetes-cni` | 公式のCNIバイナリを`/opt/cni/bin`ディレクトリにインストールします。 |
 | `cri-tools` | `/usr/bin/crictl`バイナリを[cri-tools gitリポジトリ](https://github.com/kubernetes-incubator/cri-tools)からインストールします。 |

@@ -1,68 +1,48 @@
 ---
-title: Configuring your kubernetes cluster to self-host the control plane
+title: コントロールプレーンをセルフホストするようにkubernetesクラスターを構成する
 content_type: concept
 weight: 100
 ---

 <!-- overview -->

-### Self-hosting the Kubernetes control plane {#self-hosting}
+### コントロールプレーンのセルフホスティング {#self-hosting}

-kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control
-plane. This means that key components such as the API server, controller
-manager, and scheduler run as [DaemonSet pods](/ja/docs/concepts/workloads/controllers/daemonset/)
-configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/)
-configured in the kubelet via static files.
+kubeadmを使用すると、セルフホスト型のKubernetesコントロールプレーンを実験的に作成できます。これはAPIサーバー、コントローラーマネージャー、スケジューラーなどの主要コンポーネントは、静的ファイルを介してkubeletで構成された[static pods](/docs/tasks/configure-pod-container/static-pod/)ではなく、Kubernetes APIを介して構成された[DaemonSet pods](/ja/docs/concepts/workloads/controllers/daemonset/)として実行されることを意味します。

-To create a self-hosted cluster see the
-[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
+セルフホスト型クラスターを作成する場合は[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)を参照してください。



 <!-- body -->

-#### Caveats
+#### 警告

 {{< caution >}}
-This feature pivots your cluster into an unsupported state, rendering kubeadm unable
-to manage you cluster any longer. This includes `kubeadm upgrade`.
+この機能により、クラスターがサポートされていない状態になり、kubeadmがクラスターを管理できなくなります。これには`kubeadm upgrade`が含まれます。
 {{< /caution >}}

-1. Self-hosting in 1.8 and later has some important limitations. In particular, a
-  self-hosted cluster _cannot recover from a reboot of the control-plane node_
-  without manual intervention.
+1. 1.8以降のセルフホスティングには、いくつかの重要な制限があります。特に、セルフホスト型クラスターは、手動の介入なしにコントロールプレーンのNode再起動から回復することはできません。

-1. By default, self-hosted control plane Pods rely on credentials loaded from
-  [`hostPath`](/docs/concepts/storage/volumes/#hostpath)
-  volumes. Except for initial creation, these credentials are not managed by
-  kubeadm.
+1. デフォルトでは、セルフホスト型のコントロールプレーンのPodは、[`hostPath`](/docs/concepts/storage/volumes/#hostpath)ボリュームからロードされた資格情報に依存しています。最初の作成を除いて、これらの資格情報はkubeadmによって管理されません。

-1. The self-hosted portion of the control plane does not include etcd,
-  which still runs as a static Pod.
+1. コントロールプレーンのセルフホストされた部分にはetcdが含まれていませんが、etcdは静的Podとして実行されます。

-#### Process
+#### プロセス

-The self-hosting bootstrap process is documented in the [kubeadm design
-document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting).
+セルフホスティングのブートストラッププロセスは、[kubeadm design
+document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting)に記載されています。

-In summary, `kubeadm alpha selfhosting` works as follows:
+要約すると、`kubeadm alpha selfhosting`は次のように機能します。

-  1. Waits for this bootstrap static control plane to be running and
-    healthy. This is identical to the `kubeadm init` process without self-hosting.
+  1. 静的コントロールプレーンのブートストラップが起動し、正常になるのを待ちます。これは`kubeadm init`のセルフホスティングを使用しないプロセスと同じです。

-  1. Uses the static control plane Pod manifests to construct a set of
-    DaemonSet manifests that will run the self-hosted control plane.
-    It also modifies these manifests where necessary, for example adding new volumes
-    for secrets.
+  1. 静的コントロールプレーンのPodのマニフェストを使用して、セルフホスト型コントロールプレーンを実行する一連のDaemonSetのマニフェストを構築します。また、必要に応じてこれらのマニフェストを変更します。たとえば、シークレット用の新しいボリュームを追加します。

-  1. Creates DaemonSets in the `kube-system` namespace and waits for the
-     resulting Pods to be running.
+  1. `kube-system`のネームスペースにDaemonSetを作成し、Podの結果が起動されるのを待ちます。

-  1. Once self-hosted Pods are operational, their associated static Pods are deleted
-     and kubeadm moves on to install the next component. This triggers kubelet to
-     stop those static Pods.
+  1. セルフホスト型のPodが操作可能になると、関連する静的Podが削除され、kubeadmは次のコンポーネントのインストールに進みます。これによりkubeletがトリガーされて静的Podが停止します。

-  1. When the original static control plane stops, the new self-hosted control
-    plane is able to bind to listening ports and become active.
+  1. 元の静的なコントロールプレーンが停止すると、新しいセルフホスト型コントロールプレーンはリスニングポートにバインドしてアクティブになります。


@@ -29,7 +29,8 @@ when using kubeadm to set up a kubernetes cluster.
 * Three hosts that can talk to each other over ports 2379 and 2380. This
  document assumes these default ports. However, they are configurable through
  the kubeadm config file.
-* Each host must [have docker, kubelet, and kubeadm installed][toolbox].
+* Each host must [have docker, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
+* Each host should have access to the Kubernetes container image registry (`k8s.gcr.io`) or list/pull the required etcd image using `kubeadm config images list/pull`. This guide will setup etcd instances as [static pods](/docs/tasks/configure-pod-container/static-pod/) managed by a kubelet.
 * Some infrastructure to copy files between hosts. For example `ssh` and `scp`
  can satisfy this requirement.

@@ -6,68 +6,100 @@ weight: 20

 <!-- overview -->

-As with any program, you might run into an error installing or running kubeadm.
-This page lists some common failure scenarios and have provided steps that can help you understand and fix the problem.
+どのプログラムでもそうですが、kubeadmのインストールや実行でエラーが発生することがあります。このページでは、一般的な失敗例をいくつか挙げ、問題を理解して解決するための手順を示しています。

-If your problem is not listed below, please follow the following steps:
-
- If you think your problem is a bug with kubeadm:
-  - Go to [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) and search for existing issues.
-  - If no issue exists, please [open one](https://github.com/kubernetes/kubeadm/issues/new) and follow the issue template.
-
- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
-  relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
+本ページに問題が記載されていない場合は、以下の手順を行ってください:

+- 問題がkubeadmのバグによるものと思った場合:
+  - [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues)にアクセスして、既存のIssueを探してください。
+  - Issueがない場合は、テンプレートにしたがって[新しくIssueを立ててください](https://github.com/kubernetes/kubeadm/issues/new)。

+- kubeadmがどのように動作するかわからない場合は、[Slack](http://slack.k8s.io/)の#kubeadmチャンネルで質問するか、[StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes)で質問をあげてください。その際は、他の方が助けを出しやすいように`#kubernetes`や`#kubeadm`といったタグをつけてください。

 <!-- body -->

+## RBACがないため、v1.18ノードをv1.17クラスタに結合できない
+v1.18では、同名のノードが既に存在する場合にクラスタ内のノードに参加しないようにする機能を追加しました。これには、ブートストラップトークンユーザがNodeオブジェクトをGETできるようにRBACを追加する必要がありました。
+
+しかし、これによりv1.18の`kubeadm join`がkubeadm v1.17で作成したクラスタに参加できないという問題が発生します。
+
+この問題を回避するには、次の2つの方法があります。
+- kubeadm v1.18を用いて、コントロールプレーンノード上で`kubeadm init phase bootstrap-token`を実行します。
+これには、ブートストラップトークンの残りのパーミッションも同様に有効にすることに注意してください。
+
+- `kubectl apply -f ...`を使って以下のRBACを手動で適用します。
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: kubeadm:get-nodes
+rules:
+- apiGroups:
+  - ""
+  resources:
+  - nodes
+  verbs:
+  - get
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: kubeadm:get-nodes
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: kubeadm:get-nodes
+subjects:
+- apiGroup: rbac.authorization.k8s.io
+  kind: Group
+  name: system:bootstrappers:kubeadm:default-node-token
+```
+
 ## インストール中に`ebtables`もしくは他の似たような実行プログラムが見つからない

-If you see the following warnings while running `kubeadm init`
+`kubeadm init`の実行中に以下のような警告が表示された場合は、以降に記載するやり方を行ってください。

 ```sh
 [preflight] WARNING: ebtables not found in system path
 [preflight] WARNING: ethtool not found in system path
 ```

-Then you may be missing `ebtables`, `ethtool` or a similar executable on your node. You can install them with the following commands:
+このような場合、ノード上に`ebtables`, `ethtool`などの実行ファイルがない可能性があります。これらをインストールするには、以下のコマンドを実行します。

- For Ubuntu/Debian users, run `apt install ebtables ethtool`.
- For CentOS/Fedora users, run `yum install ebtables ethtool`.
+- Ubuntu/Debianユーザーは、`apt install ebtables ethtool`を実行してください。
+- CentOS/Fedoraユーザーは、`yum install ebtables ethtool`を実行してください。

 ## インストール中にkubeadmがコントロールプレーンを待ち続けて止まる

-If you notice that `kubeadm init` hangs after printing out the following line:
+以下のを出力した後に`kubeadm init`が止まる場合は、`kubeadm init`を実行してください:

 ```sh
 [apiclient] Created API client, waiting for the control plane to become ready
 ```

-This may be caused by a number of problems. The most common are:
+これはいくつかの問題が原因となっている可能性があります。最も一般的なのは:

- network connection problems. Check that your machine has full network connectivity before continuing.
- the default cgroup driver configuration for the kubelet differs from that used by Docker.
-  Check the system log file (e.g. `/var/log/message`) or examine the output from `journalctl -u kubelet`. If you see something like the following:
+- ネットワーク接続の問題が挙げられます。続行する前に、お使いのマシンがネットワークに完全に接続されていることを確認してください。
+- kubeletのデフォルトのcgroupドライバの設定がDockerで使用されているものとは異なっている場合も考えられます。
+  システムログファイル(例: `/var/log/message`)をチェックするか、`journalctl -u kubelet`の出力を調べてください:

  ```shell
  error: failed to run Kubelet: failed to create kubelet:
  misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"
  ```

-  There are two common ways to fix the cgroup driver problem:
+  以上のようなエラーが現れていた場合、cgroupドライバの問題を解決するには、以下の2つの方法があります:

- 1. Install Docker again following instructions
-  [here](/ja/docs/setup/independent/install-kubeadm/#installing-docker).
+ 1. [ここ](/ja/docs/setup/independent/install-kubeadm/#installing-docker)の指示に従ってDockerを再度インストールします。

- 1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to
-    [Configure cgroup driver used by kubelet on Master Node](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
+ 1. Dockerのcgroupドライバに合わせてkubeletの設定を手動で変更します。その際は、[マスターノード上でkubeletが使用するcgroupドライバを設定する](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)を参照してください。

- control plane Docker containers are crashlooping or hanging. You can check this by running `docker ps` and investigating each container by running `docker logs`.
+- control plane Dockerコンテナがクラッシュループしたり、ハングしたりしています。これは`docker ps`を実行し、`docker logs`を実行して各コンテナを調査することで確認できます。

 ## 管理コンテナを削除する時にkubeadmが止まる

-The following could happen if Docker halts and does not remove any Kubernetes-managed containers:
+Dockerが停止して、Kubernetesで管理されているコンテナを削除しないと、以下のようなことが起こる可能性があります:

 ```bash
 sudo kubeadm reset
@@ -78,95 +110,70 @@ sudo kubeadm reset
 (block)
 ```

-A possible solution is to restart the Docker service and then re-run `kubeadm reset`:
+考えられる解決策は、Dockerサービスを再起動してから`kubeadm reset`を再実行することです:

 ```bash
 sudo systemctl restart docker.service
 sudo kubeadm reset
 ```

-Inspecting the logs for docker may also be useful:
+dockerのログを調べるのも有効な場合があります:

 ```sh
-journalctl -ul docker
+journalctl -u docker
 ```

-## Podの状態が`RunContainerError`、`CrashLoopBackOff`、または`Error`
+## Podの状態が`RunContainerError`、`CrashLoopBackOff`、または`Error`となる

-Right after `kubeadm init` there should not be any pods in these states.
+`kubeadm init`の直後には、これらの状態ではPodは存在しないはずです。

- If there are pods in one of these states _right after_ `kubeadm init`, please open an
-  issue in the kubeadm repo. `coredns` (or `kube-dns`) should be in the `Pending` state
-  until you have deployed the network solution.
- If you see Pods in the `RunContainerError`, `CrashLoopBackOff` or `Error` state
-  after deploying the network solution and nothing happens to `coredns` (or `kube-dns`),
-  it's very likely that the Pod Network solution that you installed is somehow broken.
-  You might have to grant it more RBAC privileges or use a newer version. Please file
-  an issue in the Pod Network providers' issue tracker and get the issue triaged there.
- If you install a version of Docker older than 1.12.1, remove the `MountFlags=slave` option
-  when booting `dockerd` with `systemd` and restart `docker`. You can see the MountFlags in `/usr/lib/systemd/system/docker.service`.
-  MountFlags can interfere with volumes mounted by Kubernetes, and put the Pods in `CrashLoopBackOff` state.
-  The error happens when Kubernetes does not find `var/run/secrets/kubernetes.io/serviceaccount` files.
+- `kubeadm init`の _直後_ にこれらの状態のいずれかにPodがある場合は、kubeadmのリポジトリにIssueを立ててください。ネットワークソリューションをデプロイするまでは`coredns`(または`kube-dns`)は`Pending`状態でなければなりません。
+- ネットワークソリューションをデプロイしても`coredns`(または`kube-dns`)に何も起こらない場合にRunContainerError`、`CrashLoopBackOff`、`Error`の状態でPodが表示された場合は、インストールしたPodネットワークソリューションが壊れている可能性が高いです。より多くのRBACの特権を付与するか、新しいバージョンを使用する必要があるかもしれません。PodネットワークプロバイダのイシュートラッカーにIssueを出して、そこで問題をトリアージしてください。
+- 1.12.1よりも古いバージョンのDockerをインストールした場合は、`systemd`で`dockerd`を起動する際に`MountFlags=slave`オプションを削除して`docker`を再起動してください。マウントフラグは`/usr/lib/systemd/system/docker.service`で確認できます。MountFlagsはKubernetesがマウントしたボリュームに干渉し、Podsを`CrashLoopBackOff`状態にすることがあります。このエラーは、Kubernetesが`var/run/secrets/kubernetes.io/serviceaccount`ファイルを見つけられない場合に発生します。

 ## `coredns`(もしくは`kube-dns`)が`Pending`状態でスタックする

-This is **expected** and part of the design. kubeadm is network provider-agnostic, so the admin
-should [install the pod network solution](/docs/concepts/cluster-administration/addons/)
-of choice. You have to install a Pod Network
-before CoreDNS may be deployed fully. Hence the `Pending` state before the network is set up.
+kubeadmはネットワークプロバイダに依存しないため、管理者は選択した[Podネットワークソリューションをインストール](/docs/concepts/cluster-administration/addons/)をする必要があります。CoreDNSを完全にデプロイする前にPodネットワークをインストールする必要があります。したがって、ネットワークがセットアップされる前の `Pending`状態になります。

 ## `HostPort`サービスが動かない

-The `HostPort` and `HostIP` functionality is available depending on your Pod Network
-provider. Please contact the author of the Pod Network solution to find out whether
-`HostPort` and `HostIP` functionality are available.
+`HostPort`と`HostIP`の機能は、ご使用のPodネットワークプロバイダによって利用可能です。Podネットワークソリューションの作者に連絡して、`HostPort`と`HostIP`機能が利用可能かどうかを確認してください。

-Calico, Canal, and Flannel CNI providers are verified to support HostPort.
+Calico、Canal、FlannelのCNIプロバイダは、HostPortをサポートしていることが確認されています。

-For more information, see the [CNI portmap documentation](https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md).
+詳細については、[CNI portmap documentation] (https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md) を参照してください。

-If your network provider does not support the portmap CNI plugin, you may need to use the [NodePort feature of
-services](/ja/docs/concepts/services-networking/service/#nodeport) or use `HostNetwork=true`.
+ネットワークプロバイダが portmap CNI プラグインをサポートしていない場合は、[NodePortサービス](/ja/docs/concepts/services-networking/service/#nodeport)を使用するか、`HostNetwork=true`を使用してください。

 ## サービスIP経由でPodにアクセスすることができない

- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)
-  which allows pods to access themselves via their Service IP. This is an issue related to
-  [CNI](https://github.com/containernetworking/cni/issues/476). Please contact the network
-  add-on provider to get the latest status of their support for hairpin mode.
+- 多くのネットワークアドオンは、PodがサービスIPを介して自分自身にアクセスできるようにする[ヘアピンモード](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)を有効にしていません。これは[CNI](https://github.com/containernetworking/cni/issues/476)に関連する問題です。ヘアピンモードのサポート状況については、ネットワークアドオンプロバイダにお問い合わせください。

- If you are using VirtualBox (directly or via Vagrant), you will need to
-  ensure that `hostname -i` returns a routable IP address. By default the first
-  interface is connected to a non-routable host-only network. A work around
-  is to modify `/etc/hosts`, see this [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)
-  for an example.
+- VirtualBoxを使用している場合(直接またはVagrant経由)は、`hostname -i`がルーティング可能なIPアドレスを返すことを確認する必要があります。デフォルトでは、最初のインターフェースはルーティング可能でないホスト専用のネットワークに接続されています。これを回避するには`/etc/hosts`を修正する必要があります。例としてはこの[Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)を参照してください。

 ## TLS証明書のエラー

-The following error indicates a possible certificate mismatch.
+以下のエラーは、証明書の不一致の可能性を示しています。

 ```none
 # kubectl get pods
 Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
 ```

- Verify that the `$HOME/.kube/config` file contains a valid certificate, and
-  regenerate a certificate if necessary. The certificates in a kubeconfig file
-  are base64 encoded. The `base64 --decode` command can be used to decode the certificate
-  and `openssl x509 -text -noout` can be used for viewing the certificate information.
- Unset the `KUBECONFIG` environment variable using:
+- `HOME/.kube/config`ファイルに有効な証明書が含まれていることを確認し、必要に応じて証明書を再生成します。kubeconfigファイル内の証明書はbase64でエンコードされています。証明書をデコードするには`base64 --decode`コマンドを、証明書情報を表示するには`openssl x509 -text -noout`コマンドを用いてください。
+- 環境変数`KUBECONFIG`の設定を解除するには以下のコマンドを実行するか:

  ```sh
  unset KUBECONFIG
  ```

-  Or set it to the default `KUBECONFIG` location:
+  設定をデフォルトの`KUBECONFIG`の場所に設定します:

  ```sh
  export KUBECONFIG=/etc/kubernetes/admin.conf
  ```

- Another workaround is to overwrite the existing `kubeconfig` for the "admin" user:
+- もう一つの回避策は、既存の`kubeconfig`を"admin"ユーザに上書きすることです:

  ```sh
  mv  $HOME/.kube $HOME/.kube.bak
@@ -177,38 +184,38 @@ Unable to connect to the server: x509: certificate signed by unknown authority (

 ## Vagrant内でPodネットワークとしてflannelを使用する時のデフォルトNIC

-The following error might indicate that something was wrong in the pod network:
+以下のエラーは、Podネットワークに何か問題があったことを示している可能性を示しています:

 ```sh
 Error from server (NotFound): the server could not find the requested resource
 ```

- If you're using flannel as the pod network inside Vagrant, then you will have to specify the default interface name for flannel.
+- Vagrant内のPodネットワークとしてflannelを使用している場合は、flannelのデフォルトのインターフェース名を指定する必要があります。

-  Vagrant typically assigns two interfaces to all VMs. The first, for which all hosts are assigned the IP address `10.0.2.15`, is for external traffic that gets NATed.
+  Vagrantは通常、2つのインターフェースを全てのVMに割り当てます。1つ目は全てのホストにIPアドレス`10.0.2.15`が割り当てられており、NATされる外部トラフィックのためのものです。

-  This may lead to problems with flannel, which defaults to the first interface on a host. This leads to all hosts thinking they have the same public IP address. To prevent this, pass the `--iface eth1` flag to flannel so that the second interface is chosen.
+  これは、ホストの最初のインターフェイスをデフォルトにしているflannelの問題につながるかもしれません。これは、すべてのホストが同じパブリックIPアドレスを持っていると考えます。これを防ぐには、2番目のインターフェイスが選択されるように `--iface eth1`フラグをflannelに渡してください。

 ## 公開されていないIPがコンテナに使われている

-In some situations `kubectl logs` and `kubectl run` commands may return with the following errors in an otherwise functional cluster:
+状況によっては、`kubectl logs`や`kubectl run`コマンドが以下のようなエラーを返すことがあります:

 ```sh
 Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: dial tcp 10.19.0.41:10250: getsockopt: no route to host
 ```

- This may be due to Kubernetes using an IP that can not communicate with other IPs on the seemingly same subnet, possibly by policy of the machine provider.
- DigitalOcean assigns a public IP to `eth0` as well as a private one to be used internally as anchor for their floating IP feature, yet `kubelet` will pick the latter as the node's `InternalIP` instead of the public one.
+- これには、おそらくマシンプロバイダのポリシーによって、一見同じサブネット上の他のIPと通信できないIPをKubernetesが使用している可能性があります。
+- DigitalOceanはパブリックIPとプライベートIPを`eth0`に割り当てていますが、`kubelet`はパブリックIPではなく、ノードの`InternalIP`として後者を選択します。

-  Use `ip addr show` to check for this scenario instead of `ifconfig` because `ifconfig` will not display the offending alias IP address. Alternatively an API endpoint specific to DigitalOcean allows to query for the anchor IP from the droplet:
+  `ifconfig`ではエイリアスIPアドレスが表示されないため、`ifconfig`の代わりに`ip addr show`を使用してこのシナリオをチェックしてください。あるいは、DigitalOcean専用のAPIエンドポイントを使用して、ドロップレットからアンカーIPを取得することもできます:

  ```sh
  curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
  ```

-  The workaround is to tell `kubelet` which IP to use using `--node-ip`. When using DigitalOcean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this.
+  回避策としては、`--node-ip`を使ってどのIPを使うかを`kubelet`に伝えることです。DigitalOceanを使用する場合、オプションのプライベートネットワークを使用したい場合は、パブリックIP（`eth0`に割り当てられている）かプライベートIP（`eth1`に割り当てられている）のどちらかを指定します。これにはkubeadm `NodeRegistrationOptions`構造体の [`KubeletExtraArgs`セクション](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) が利用できます。

-  Then restart `kubelet`:
+  `kubelet`を再起動してください:

  ```sh
  systemctl daemon-reload
@@ -217,13 +224,12 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6

 ## `coredns`のPodが`CrashLoopBackOff`もしくは`Error`状態になる

-If you have nodes that are running SELinux with an older version of Docker you might experience a scenario
-where the `coredns` pods are not starting. To solve that you can try one of the following options:
+SELinuxを実行しているノードで古いバージョンのDockerを使用している場合、`coredns` Podが起動しないということが起きるかもしれません。この問題を解決するには、以下のオプションのいずれかを試してみてください:

- Upgrade to a [newer version of Docker](/ja/docs/setup/independent/install-kubeadm/#installing-docker).
+- [新しいDockerのバージョン](/ja/docs/setup/independent/install-kubeadm/#installing-docker)にアップグレードする。

- [Disable SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux).
- Modify the `coredns` deployment to set `allowPrivilegeEscalation` to `true`:
+- [SELinuxを無効化する](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux)。
+- `coredns`を変更して、`allowPrivilegeEscalation`を`true`に設定:

 ```bash
 kubectl -n kube-system get deployment coredns -o yaml | \
@@ -231,108 +237,84 @@ kubectl -n kube-system get deployment coredns -o yaml | \
  kubectl apply -f -
 ```

-Another cause for CoreDNS to have `CrashLoopBackOff` is when a CoreDNS Pod deployed in Kubernetes detects a loop. [A number of workarounds](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)
-are available to avoid Kubernetes trying to restart the CoreDNS Pod every time CoreDNS detects the loop and exits.
+CoreDNSに`CrashLoopBackOff`が発生する別の原因は、KubernetesにデプロイされたCoreDNS Podがループを検出したときに発生します。CoreDNSがループを検出して終了するたびに、KubernetesがCoreDNS Podを再起動しようとするのを避けるために、[いくつかの回避策](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)が用意されています。

 {{< warning >}}
-Disabling SELinux or setting `allowPrivilegeEscalation` to `true` can compromise
-the security of your cluster.
+SELinuxを無効にするか`allowPrivilegeEscalation`を`true`に設定すると、クラスタのセキュリティが損なわれる可能性があります。
 {{< /warning >}}

 ## etcdのpodが継続的に再起動する

-If you encounter the following error:
+以下のエラーが発生した場合は:

 ```
 rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\""
 ```

-this issue appears if you run CentOS 7 with Docker 1.13.1.84.
-This version of Docker can prevent the kubelet from executing into the etcd container.
+この問題は、CentOS 7をDocker 1.13.1.84で実行した場合に表示されます。このバージョンのDockerでは、kubeletがetcdコンテナに実行されないようにすることができます。

-To work around the issue, choose one of these options:
+この問題を回避するには、以下のいずれかのオプションを選択します:

- Roll back to an earlier version of Docker, such as 1.13.1-75
+- 1.13.1-75のような以前のバージョンのDockerにロールバックする
 ```
 yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
 ```

- Install one of the more recent recommended versions, such as 18.06:
+- 18.06のような最新の推奨バージョンをインストールする:
 ```bash
 sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
 yum install docker-ce-18.06.1.ce-3.el7.x86_64
 ```

-## Not possible to pass a comma separated list of values to arguments inside a `--component-extra-args` flag
+## コンマで区切られた値のリストを`--component-extra-args`フラグ内の引数に渡すことができない

-`kubeadm init` flags such as `--component-extra-args` allow you to pass custom arguments to a control-plane
-component like the kube-apiserver. However, this mechanism is limited due to the underlying type used for parsing
-the values (`mapStringString`).
+`-component-extra-args`のような`kubeadm init`フラグを使うと、kube-apiserverのようなコントロールプレーンコンポーネントにカスタム引数を渡すことができます。しかし、このメカニズムは値の解析に使われる基本的な型 (`mapStringString`) のために制限されています。

-If you decide to pass an argument that supports multiple, comma-separated values such as
-`--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"` this flag will fail with
-`flag: malformed pair, expect string=string`. This happens because the list of arguments for
-`--apiserver-extra-args` expects `key=value` pairs and in this case `NamespacesExists` is considered
-as a key that is missing a value.
+もし、`--apiserver-extra-args "enable-admission plugins=LimitRanger,NamespaceExists"`のようにカンマで区切られた複数の値をサポートする引数を渡した場合、このフラグは`flag: malformed pair, expect string=string`で失敗します。これは`--apiserver-extra-args`の引数リストが`key=value`のペアを期待しており、この場合`NamespacesExists`は値を欠いたキーとみなされるためです。

-Alternatively, you can try separating the `key=value` pairs like so:
-`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
-but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`.
+別の方法として、`key=value`のペアを以下のように分離してみることもできます:
+`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`しかし、この場合は、キー`enable-admission-plugins`は`NamespaceExists`の値しか持ちません。既知の回避策としては、kubeadm[設定ファイル](/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags)を使用することが挙げられます。

-A known workaround is to use the kubeadm [configuration file](/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags).
+## cloud-controller-managerによってノードが初期化される前にkube-proxyがスケジューリングされる

-## kube-proxy scheduled before node is initialized by cloud-controller-manager
+クラウドプロバイダのシナリオでは、クラウドコントローラマネージャがノードアドレスを初期化する前に、kube-proxyが新しいワーカーノードでスケジューリングされてしまうことがあります。これにより、kube-proxyがノードのIPアドレスを正しく拾えず、ロードバランサを管理するプロキシ機能に悪影響を及ぼします。

-In cloud provider scenarios, kube-proxy can end up being scheduled on new worker nodes before
-the cloud-controller-manager has initialized the node addresses. This causes kube-proxy to fail
-to pick up the node's IP address properly and has knock-on effects to the proxy function managing
-load balancers.
-
-The following error can be seen in kube-proxy Pods:
+kube-proxy Podsでは以下のようなエラーが発生します:
 ```
 server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: []
 proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP
 ```

-A known solution is to patch the kube-proxy DaemonSet to allow scheduling it on control-plane
-nodes regardless of their conditions, keeping it off of other nodes until their initial guarding
-conditions abate:
+既知の解決策は、初期のガード条件が緩和されるまで他のノードから離しておき、条件に関係なくコントロールプレーンノード上でスケジューリングできるように、キューブプロキシDaemonSetにパッチを当てることです:
+
 ```
 kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/master" } ] } } } }'
 ```

-The tracking issue for this problem is [here](https://github.com/kubernetes/kubeadm/issues/1027).
+Tこの問題のトラッキング問題は[こちら](https://github.com/kubernetes/kubeadm/issues/1027)。

-## The NodeRegistration.Taints field is omitted when marshalling kubeadm configuration
+## kubeadmの設定をマーシャリングする際、NodeRegistration.Taintsフィールドが省略される

-*Note: This [issue](https://github.com/kubernetes/kubeadm/issues/1358) only applies to tools that marshal kubeadm types (e.g. to a YAML configuration file). It will be fixed in kubeadm API v1beta2.*
+*注意: この[Issue](https://github.com/kubernetes/kubeadm/issues/1358)は、kubeadmタイプをマーシャルするツール(YAML設定ファイルなど)にのみ適用されます。これはkubeadm API v1beta2で修正される予定です。*

-By default, kubeadm applies the `node-role.kubernetes.io/master:NoSchedule` taint to control-plane nodes.
-If you prefer kubeadm to not taint the control-plane node, and set `InitConfiguration.NodeRegistration.Taints` to an empty slice,
-the field will be omitted when marshalling. When the field is omitted, kubeadm applies the default taint.
+デフォルトでは、kubeadmはコントロールプレーンノードに`node-role.kubernetes.io/master:NoSchedule`のテイントを適用します。kubeadmがコントロールプレーンノードに影響を与えないようにし、`InitConfiguration.NodeRegistration.Taints`を空のスライスに設定すると、マーシャリング時にこのフィールドは省略されます。フィールドが省略された場合、kubeadmはデフォルトのテイントを適用します。

-There are at least two workarounds:
+少なくとも2つの回避策があります:

-1. Use the `node-role.kubernetes.io/master:PreferNoSchedule` taint instead of an empty slice. [Pods will get scheduled on masters](/docs/concepts/configuration/taint-and-toleration/), unless other nodes have capacity.
+1. 空のスライスの代わりに`node-role.kubernetes.io/master:PreferNoSchedule`テイントを使用します。他のノードに容量がない限り、[Podsはマスター上でスケジュールされます](/docs/concepts/scheduling-eviction/taint-and-toleration/)。

-2. Remove the taint after kubeadm init exits:
+2. kubeadm init終了後のテイントの除去:
 ```bash
 kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-
 ```

-## `/usr` is mounted read-only on nodes {#usr-mounted-read-only}
+## ノード{#usr-mounted-read-only}に`/usr`が読み取り専用でマウントされる

-On Linux distributions such as Fedora CoreOS, the directory `/usr` is mounted as a read-only filesystem.
-For [flex-volume support](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md),
-Kubernetes components like the kubelet and kube-controller-manager use the default path of
-`/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`, yet the flex-volume directory _must be writeable_
-for the feature to work.
+Fedora CoreOSなどのLinuxディストリビューションでは、ディレクトリ`/usr`が読み取り専用のファイルシステムとしてマウントされます。 [flex-volumeサポート](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md)では、kubeletやkube-controller-managerのようなKubernetesコンポーネントはデフォルトで`/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`のパスを使用していますが、この機能を動作させるためにはflex-volumeディレクトリは _書き込み可能_ な状態でなければなりません。

-To workaround this issue you can configure the flex-volume directory using the kubeadm
-[configuration file](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2).
+この問題を回避するには、kubeadm[設定ファイル](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)を使用してflex-volumeディレクトリを設定します。

-On the primary control-plane Node (created using `kubeadm init`) pass the following
-file using `--config`:
+プライマリコントロールプレーンノード（`kubeadm init`で作成されたもの）上で、`--config`で以下のファイルを渡します:

 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta2
@@ -348,7 +330,7 @@ controllerManager:
    flex-volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
 ```

-On joining Nodes:
+ノードをジョインするには:

 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta2
@@ -358,5 +340,9 @@ nodeRegistration:
    volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/"
 ```

-Alternatively, you can modify `/etc/fstab` to make the `/usr` mount writeable, but please
-be advised that this is modifying a design principle of the Linux distribution.
+あるいは、`/usr`マウントを書き込み可能にするために `/etc/fstab`を変更することもできますが、これはLinuxディストリビューションの設計原理を変更していることに注意してください。
+
+## `kubeadm upgrade plan`が`context deadline exceeded`エラーメッセージを表示する
+このエラーメッセージは、外部etcdを実行している場合に`kubeadm`でKubernetesクラスタをアップグレードする際に表示されます。これは致命的なバグではなく、古いバージョンのkubeadmが外部etcdクラスタのバージョンチェックを行うために発生します。`kubeadm upgrade apply ...`で進めることができます。
+
+この問題はバージョン1.19で修正されます。
@@ -8,7 +8,7 @@ weight: 30

 This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray).

-Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
+Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:

 * a highly available cluster
 * composable attributes
@@ -21,7 +21,8 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in
  * openSUSE Leap 15
 * continuous integration tests

-To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).
+To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to
+[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).



@@ -50,7 +51,7 @@ Kubespray provides the following utilities to help provision your environment:

 ### (2/5) インベントリファイルの用意

-After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
+After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".

 ### (3/5) クラスタ作成の計画

@@ -68,7 +69,7 @@ Kubespray provides the ability to customize many aspects of the deployment:
  * {{< glossary_tooltip term_id="cri-o" >}}
 * Certificate generation methods

-Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
+Kubespray customizations can be made to a [variable file](https://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.

 ### (4/5) クラスタのデプロイ

@@ -110,7 +111,7 @@ When running the reset playbook, be sure not to accidentally target your product

 ## フィードバック

-* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/))
+* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](https://slack.k8s.io/))
 * [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)


@@ -20,9 +20,7 @@ AWS上でKubernetesクラスターを作成するには、AWSからアクセス

 * [Kubernetes Operations](https://github.com/kubernetes/kops) - プロダクショングレードなKubernetesのインストール、アップグレード、管理が可能です。AWS上のDebian、Ubuntu、CentOS、RHELをサポートしています。

-* [CoreOS Tectonic](https://coreos.com/tectonic/)はAWS上のContainer Linuxノードを含むKubernetesクラスターを作成できる、オープンソースの[Tectonic Installer](https://github.com/coreos/tectonic-installer)を含みます。
-
-* CoreOSから生まれ、Kubernetes IncubatorがメンテナンスしているCLIツール[kube-aws](https://github.com/kubernetes-incubator/kube-aws)は、[Container Linux](https://coreos.com/why/)ノードを使用したAWSツール(EC2、CloudFormation、Auto Scaling)によるKubernetesクラスターを作成および管理できます。
+* [kube-aws](https://github.com/kubernetes-incubator/kube-aws) EC2、CloudFormation、Auto Scalingを使用して、[Flatcar Linux](https://www.flatcar-linux.org/)ノードでKubernetesクラスターを作成および管理します。

 * [KubeOne](https://github.com/kubermatic/kubeone)は可用性の高いKubernetesクラスターを作成、アップグレード、管理するための、オープンソースのライフサイクル管理ツールです。

@@ -46,10 +44,10 @@ export PATH=<path/to/kubernetes-directory>/platforms/darwin/amd64:$PATH
 export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH
 ```

-ツールに関する最新のドキュメントページはこちらです: [kubectl manual](/docs/user-guide/kubectl/)
+ツールに関する最新のドキュメントページはこちらです: [kubectl manual](/docs/reference/kubectl/kubectl/)

 デフォルトでは、`kubectl`はクラスターの起動中に生成された`kubeconfig`ファイルをAPIに対する認証に使用します。
-詳細な情報は、[kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください。
+詳細な情報は、[kubeconfig files](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください。

 ### 例

@@ -61,7 +59,7 @@ export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH

 ## クラスターのスケーリング

-`kubectl`を使用したノードの追加および削除はサポートしていません。インストール中に作成された[Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html)内の'Desired'および'Max'プロパティを手動で調整することで、ノード数をスケールさせることができます。
+`kubectl`を使用したノードの追加および削除はサポートしていません。インストール中に作成された[Auto Scaling Group](https://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html)内の'Desired'および'Max'プロパティを手動で調整することで、ノード数をスケールさせることができます。

 ## クラスターの解体

@@ -77,12 +75,8 @@ cluster/kube-down.sh
 IaaS プロバイダー    | 構成管理     | OS            | ネットワーク  | ドキュメント                                  | 適合     | サポートレベル
 -------------------- | ------------ | ------------- | ------------  | --------------------------------------------- | ---------| ----------------------------
 AWS                  | kops         | Debian        | k8s (VPC)     | [docs](https://github.com/kubernetes/kops)    |          | Community ([@justinsb](https://github.com/justinsb))
-AWS                  | CoreOS       | CoreOS        | flannel       | [docs](/docs/getting-started-guides/aws)      |          | Community
-AWS                  | Juju         | Ubuntu        | flannel, calico, canal     | [docs](/docs/getting-started-guides/ubuntu)      | 100%     | Commercial, Community
+AWS                  | CoreOS       | CoreOS        | flannel     | -  |          | Community
+AWS                  | Juju         | Ubuntu        | flannel, calico, canal     | - | 100%     | Commercial, Community
 AWS                  | KubeOne         | Ubuntu, CoreOS, CentOS   | canal, weavenet     | [docs](https://github.com/kubermatic/kubeone)      | 100%    | Commercial, Community

-## 参考文献
-
-Kubernetesクラスターの利用と管理に関する詳細は、[Kubernetesドキュメント](/ja/docs/)を参照してください。
-

@@ -1,340 +0,0 @@
---
-title: CenturyLink Cloud上でKubernetesを動かす
---
-
-
-These scripts handle the creation, deletion and expansion of Kubernetes clusters on CenturyLink Cloud.
-
-You can accomplish all these tasks with a single command. We have made the Ansible playbooks used to perform these tasks available [here](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md).
-
-## ヘルプの検索
-
-If you run into any problems or want help with anything, we are here to help. Reach out to use via any of the following ways:
-
- Submit a github issue
- Send an email to Kubernetes AT ctl DOT io
- Visit [http://info.ctl.io/kubernetes](http://info.ctl.io/kubernetes)
-
-## 仮想マシンもしくは物理サーバーのクラスター、その選択
-
- We support Kubernetes clusters on both Virtual Machines or Physical Servers. If you want to use physical servers for the worker nodes (minions), simple use the --minion_type=bareMetal flag.
- For more information on physical servers, visit: [https://www.ctl.io/bare-metal/](https://www.ctl.io/bare-metal/)
- Physical serves are only available in the VA1 and GB3 data centers.
- VMs are available in all 13 of our public cloud locations
-
-## 必要条件
-
-The requirements to run this script are:
-
- A linux administrative host (tested on ubuntu and macOS)
- python 2 (tested on 2.7.11)
-  - pip (installed with python as of 2.7.9)
- git
- A CenturyLink Cloud account with rights to create new hosts
- An active VPN connection to the CenturyLink Cloud from your linux host
-
-## スクリプトのインストール
-
-After you have all the requirements met, please follow these instructions to install this script.
-
-1) Clone this repository and cd into it.
-
-```shell
-git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc
-```
-
-2) Install all requirements, including
-
-  * Ansible
-  * CenturyLink Cloud SDK
-  * Ansible Modules
-
-```shell
-sudo pip install -r ansible/requirements.txt
-```
-
-3) Create the credentials file from the template and use it to set your ENV variables
-
-```shell
-cp ansible/credentials.sh.template ansible/credentials.sh
-vi ansible/credentials.sh
-source ansible/credentials.sh
-
-```
-
-4) Grant your machine access to the CenturyLink Cloud network by using a VM inside the network or [ configuring a VPN connection to the CenturyLink Cloud network.](https://www.ctl.io/knowledge-base/network/how-to-configure-client-vpn/)
-
-
-#### スクリプトのインストールの例: Ububtu 14の手順
-
-If you use an ubuntu 14, for your convenience we have provided a step by step
-guide to install the requirements and install the script.
-
-```shell
-# system
-apt-get update
-apt-get install -y git python python-crypto
-curl -O https://bootstrap.pypa.io/get-pip.py
-python get-pip.py
-
-# installing this repository
-mkdir -p ~home/k8s-on-clc
-cd ~home/k8s-on-clc
-git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc.git
-cd adm-kubernetes-on-clc/
-pip install -r requirements.txt
-
-# getting started
-cd ansible
-cp credentials.sh.template credentials.sh; vi credentials.sh
-source credentials.sh
-```
-
-
-
-## クラスターの作成
-
-To create a new Kubernetes cluster, simply run the ```kube-up.sh``` script. A complete
-list of script options and some examples are listed below.
-
-```shell
-CLC_CLUSTER_NAME=[name of kubernetes cluster]
-cd ./adm-kubernetes-on-clc
-bash kube-up.sh -c="$CLC_CLUSTER_NAME"
-```
-
-It takes about 15 minutes to create the cluster. Once the script completes, it
-will output some commands that will help you setup kubectl on your machine to
-point to the new cluster.
-
-When the cluster creation is complete, the configuration files for it are stored
-locally on your administrative host, in the following directory
-
-```shell
-> CLC_CLUSTER_HOME=$HOME/.clc_kube/$CLC_CLUSTER_NAME/
-```
-
-
-#### クラスターの作成: スクリプトのオプション
-
-```shell
-Usage: kube-up.sh [OPTIONS]
-Create servers in the CenturyLinkCloud environment and initialize a Kubernetes cluster
-Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in
-order to access the CenturyLinkCloud API
-
-All options (both short and long form) require arguments, and must include "="
-between option name and option value.
-
-     -h (--help)                   display this help and exit
-     -c= (--clc_cluster_name=)     set the name of the cluster, as used in CLC group names
-     -t= (--minion_type=)          standard -> VM (default), bareMetal -> physical]
-     -d= (--datacenter=)           VA1 (default)
-     -m= (--minion_count=)         number of kubernetes minion nodes
-     -mem= (--vm_memory=)          number of GB ram for each minion
-     -cpu= (--vm_cpu=)             number of virtual cps for each minion node
-     -phyid= (--server_conf_id=)   physical server configuration id, one of
-                                      physical_server_20_core_conf_id
-                                      physical_server_12_core_conf_id
-                                      physical_server_4_core_conf_id (default)
-     -etcd_separate_cluster=yes    create a separate cluster of three etcd nodes,
-                                   otherwise run etcd on the master node
-```
-
-## クラスターの拡張
-
-To expand an existing Kubernetes cluster, run the ```add-kube-node.sh```
-script. A complete list of script options and some examples are listed [below](#cluster-expansion-script-options).
-This script must be run from the same host that created the cluster (or a host
-that has the cluster artifact files stored in ```~/.clc_kube/$cluster_name```).
-
-```shell
-cd ./adm-kubernetes-on-clc
-bash add-kube-node.sh -c="name_of_kubernetes_cluster" -m=2
-```
-
-#### クラスターの拡張: スクリプトのオプション
-
-```shell
-Usage: add-kube-node.sh [OPTIONS]
-Create servers in the CenturyLinkCloud environment and add to an
-existing CLC kubernetes cluster
-
-Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in
-order to access the CenturyLinkCloud API
-
-     -h (--help)                   display this help and exit
-     -c= (--clc_cluster_name=)     set the name of the cluster, as used in CLC group names
-     -m= (--minion_count=)         number of kubernetes minion nodes to add
-```
-
-## クラスターの削除
-
-There are two ways to delete an existing cluster:
-
-1) Use our python script:
-
-```shell
-python delete_cluster.py --cluster=clc_cluster_name --datacenter=DC1
-```
-
-2) Use the CenturyLink Cloud UI. To delete a cluster, log into the CenturyLink
-Cloud control portal and delete the parent server group that contains the
-Kubernetes Cluster. We hope to add a scripted option to do this soon.
-
-## 例
-
-Create a cluster with name of k8s_1, 1 master node and 3 worker minions (on physical machines), in VA1
-
-```shell
-bash kube-up.sh --clc_cluster_name=k8s_1 --minion_type=bareMetal --minion_count=3 --datacenter=VA1
-```
-
-Create a cluster with name of k8s_2, an ha etcd cluster on 3 VMs and 6 worker minions (on VMs), in VA1
-
-```shell
-bash kube-up.sh --clc_cluster_name=k8s_2 --minion_type=standard --minion_count=6 --datacenter=VA1 --etcd_separate_cluster=yes
-```
-
-Create a cluster with name of k8s_3, 1 master node, and 10 worker minions (on VMs) with higher mem/cpu, in UC1:
-
-```shell
-bash kube-up.sh --clc_cluster_name=k8s_3 --minion_type=standard --minion_count=10 --datacenter=VA1 -mem=6 -cpu=4
-```
-
-
-
-## クラスターの機能とアーキテクチャ
-
-We configure the Kubernetes cluster with the following features:
-
-* KubeDNS: DNS resolution and service discovery
-* Heapster/InfluxDB: For metric collection. Needed for Grafana and auto-scaling.
-* Grafana: Kubernetes/Docker metric dashboard
-* KubeUI: Simple web interface to view Kubernetes state
-* Kube Dashboard: New web interface to interact with your cluster
-
-We use the following to create the Kubernetes cluster:
-
-* Kubernetes 1.1.7
-* Ubuntu 14.04
-* Flannel 0.5.4
-* Docker 1.9.1-0~trusty
-* Etcd 2.2.2
-
-## 任意のアドオン
-
-* Logging: We offer an integrated centralized logging ELK platform so that all
-  Kubernetes and docker logs get sent to the ELK stack. To install the ELK stack
-  and configure Kubernetes to send logs to it, follow [the log
-  aggregation documentation](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/log_aggregration.md). Note: We don't install this by default as
-  the footprint isn't trivial.
-
-## クラスターの管理
-
-The most widely used tool for managing a Kubernetes cluster is the command-line
-utility ```kubectl```.  If you do not already have a copy of this binary on your
-administrative machine, you may run the script ```install_kubectl.sh``` which will
-download it and install it in ```/usr/bin/local```.
-
-The script requires that the environment variable ```CLC_CLUSTER_NAME``` be defined. ```install_kubectl.sh``` also writes a configuration file which will embed the necessary
-authentication certificates for the particular cluster.  The configuration file is
-written to the  ```${CLC_CLUSTER_HOME}/kube``` directory
-
-
-```shell
-export KUBECONFIG=${CLC_CLUSTER_HOME}/kube/config
-kubectl version
-kubectl cluster-info
-```
-
-### プログラムでクラスターへアクセス
-
-It's possible to use the locally stored client certificates to access the apiserver. For example, you may want to use any of the [Kubernetes API client libraries](/docs/reference/using-api/client-libraries/) to program against your Kubernetes cluster in the programming language of your choice.
-
-To demonstrate how to use these locally stored certificates, we provide the following example of using ```curl``` to communicate to the master apiserver via https:
-
-```shell
-curl \
-   --cacert ${CLC_CLUSTER_HOME}/pki/ca.crt  \
-   --key ${CLC_CLUSTER_HOME}/pki/kubecfg.key \
-   --cert ${CLC_CLUSTER_HOME}/pki/kubecfg.crt  https://${MASTER_IP}:6443
-```
-
-But please note, this *does not* work out of the box with the ```curl``` binary
-distributed with macOS.
-
-### ブラウザーを使ったクラスターへのアクセス
-
-We install [the kubernetes dashboard](/docs/tasks/web-ui-dashboard/). When you
-create a cluster, the script should output URLs for these interfaces like this:
-
-kubernetes-dashboard is running at ```https://${MASTER_IP}:6443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy```.
-
-Note on Authentication to the UIs:
-
-The cluster is set up to use basic authentication for the user _admin_.
-Hitting the url at ```https://${MASTER_IP}:6443``` will
-require accepting the self-signed certificate
-from the apiserver, and then presenting the admin
-password written to file at: ```> _${CLC_CLUSTER_HOME}/kube/admin_password.txt_```
-
-
-### 設定ファイル
-
-Various configuration files are written into the home directory *CLC_CLUSTER_HOME* under ```.clc_kube/${CLC_CLUSTER_NAME}``` in several subdirectories. You can use these files
-to access the cluster from machines other than where you created the cluster from.
-
-* ```config/```: Ansible variable files containing parameters describing the master and minion hosts
-* ```hosts/```: hosts files listing access information for the Ansible playbooks
-* ```kube/```: ```kubectl``` configuration files, and the basic-authentication password for admin access to the Kubernetes API
-* ```pki/```: public key infrastructure files enabling TLS communication in the cluster
-* ```ssh/```: SSH keys for root access to the hosts
-
-
-## ```kubectl``` usage examples
-
-There are a great many features of _kubectl_.  Here are a few examples
-
-List existing nodes, pods, services and more, in all namespaces, or in just one:
-
-```shell
-kubectl get nodes
-kubectl get --all-namespaces pods
-kubectl get --all-namespaces services
-kubectl get --namespace=kube-system replicationcontrollers
-```
-
-The Kubernetes API server exposes services on web URLs, which are protected by requiring
-client certificates.  If you run a kubectl proxy locally, ```kubectl``` will provide
-the necessary certificates and serve locally over http.
-
-```shell
-kubectl proxy -p 8001
-```
-
-Then, you can access urls like ```http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/``` without the need for client certificates in your browser.
-
-
-## どのKubernetesの機能がCenturyLink Cloud上で動かないのか
-
-These are the known items that don't work on CenturyLink cloud but do work on other cloud providers:
-
- At this time, there is no support services of the type [LoadBalancer](/docs/tasks/access-application-cluster/create-external-load-balancer/). We are actively working on this and hope to publish the changes sometime around April 2016.
-
- At this time, there is no support for persistent storage volumes provided by
-  CenturyLink Cloud. However, customers can bring their own persistent storage
-  offering. We ourselves use Gluster.
-
-
-## Ansibleのファイル
-
-If you want more information about our Ansible files, please [read this file](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md)
-
-## 参考文献
-
-Please see the [Kubernetes docs](/ja/docs/) for more details on administering
-and using a Kubernetes cluster.
-
-
-
@@ -67,7 +67,7 @@ cluster/kube-up.sh
 If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `<kubernetes>/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster.

 If you run into trouble, please see the section on [troubleshooting](/ja/docs/setup/production-environment/turnkey/gce/#troubleshooting), post to the
-[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting/#slack).
+[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on `#gke` Slack channel.

 The next few steps will show you:

@@ -80,7 +80,7 @@ The next few steps will show you:

 The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation.

-The [kubectl](/docs/user-guide/kubectl/) tool controls the Kubernetes cluster
+The [kubectl](/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster
 manager.  It lets you inspect your cluster resources, create, delete, and update
 components, and much more. You will use it to look at your new cluster and bring
 up example apps.
@@ -93,7 +93,7 @@ gcloud components install kubectl

 {{< note >}}
 The kubectl version bundled with `gcloud` may be older than the one
-downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/kubectl/install/)
+The [kubectl](/ja/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster
 document to see how you can set up the latest `kubectl` on your workstation.
 {{< /note >}}

@@ -107,7 +107,7 @@ Once `kubectl` is in your path, you can use it to look at your cluster. E.g., ru
 kubectl get --all-namespaces services
 ```

-should show a set of [services](/docs/user-guide/services) that look something like this:
+should show a set of [services](/docs/concepts/services-networking/service/) that look something like this:

 ```shell
 NAMESPACE     NAME          TYPE             CLUSTER_IP       EXTERNAL_IP       PORT(S)        AGE
@@ -117,7 +117,7 @@ kube-system   kube-ui       ClusterIP        10.0.0.3         <none>
 ...
 ```

-Similarly, you can take a look at the set of [pods](/docs/user-guide/pods) that were created during cluster startup.
+Similarly, you can take a look at the set of [pods](/ja/docs/concepts/workloads/pods/) that were created during cluster startup.
 You can do this via the

 ```shell
@@ -144,7 +144,7 @@ Some of the pods may take a few seconds to start up (during this time they'll sh

 ### いくつかの例の実行

-Then, see [a simple nginx example](/docs/user-guide/simple-nginx) to try out your new cluster.
+Then, see [a simple nginx example](/ja/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.

 For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/).  The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough.

@@ -215,10 +215,3 @@ IaaS Provider        | Config. Mgmt | OS     | Networking  | Docs
 -------------------- | ------------ | ------ | ----------  | ---------------------------------------------     | ---------| ----------------------------
 GCE                  | Saltstack    | Debian | GCE         | [docs](/ja/docs/setup/production-environment/turnkey/gce/)                                    |   | Project

-
-## 参考文献
-
-Please see the [Kubernetes docs](/ja/docs/) for more details on administering
-and using a Kubernetes cluster.
-
-
@@ -25,13 +25,9 @@ The following modules are available where you can deploy IBM Cloud Private by us

 ## AWS上でのIBM Cloud Private

-You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) by using either AWS CloudFormation or Terraform.
+You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) using Terraform.

-IBM Cloud Private has a Quick Start that automatically deploys IBM Cloud Private into a new virtual private cloud (VPC) on the AWS Cloud. A regular deployment takes about 60 minutes, and a high availability (HA) deployment takes about 75 minutes to complete. The Quick Start includes AWS CloudFormation templates and a deployment guide.
-
-This Quick Start is for users who want to explore application modernization and want to accelerate meeting their digital transformation goals, by using IBM Cloud Private and IBM tooling. The Quick Start helps users rapidly deploy a high availability (HA), production-grade, IBM Cloud Private reference architecture on AWS. For all of the details and the deployment guide, see the [IBM Cloud Private on AWS Quick Start](https://aws.amazon.com/quickstart/architecture/ibm-cloud-private/).
-
-IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_aws.md).
+IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws).

 ## Azure上でのIBM Cloud Private

@@ -64,4 +60,4 @@ You can install IBM Cloud Private on VMware with either Ubuntu or RHEL images. F

 The IBM Cloud Private Hosted service automatically deploys IBM Cloud Private Hosted on your VMware vCenter Server instances. This service brings the power of microservices and containers to your VMware environment on IBM Cloud. With this service, you can extend the same familiar VMware and IBM Cloud Private operational model and tools from on-premises into the IBM Cloud.

-For more information, see [IBM Cloud Private Hosted service](https://cloud.ibm.com/docs/services/vmwaresolutions/vmonic?topic=vmware-solutions-prod_overview#ibm-cloud-private-hosted).
+For more information, see [IBM Cloud Private Hosted service](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-icp_overview).
@@ -14,7 +14,7 @@ Windowsアプリケーションは、多くの組織で実行されているサ

 ## KubernetesのWindowsコンテナ

-KubernetesでWindowsコンテナのオーケストレーションを有効にする方法は、既存のLinuxクラスターにWindowsノードを含めるだけです。Kubernetesの[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)でWindowsコンテナをスケジュールすることは、Linuxベースのコンテナをスケジュールするのと同じくらいシンプルで簡単です。
+KubernetesでWindowsコンテナのオーケストレーションを有効にする方法は、既存のLinuxクラスターにWindowsノードを含めるだけです。Kubernetesの{{< glossary_tooltip text="Pod" term_id="pod" >}}でWindowsコンテナをスケジュールすることは、Linuxベースのコンテナをスケジュールするのと同じくらいシンプルで簡単です。

 Windowsコンテナを実行するには、Kubernetesクラスターに複数のオペレーティングシステムを含める必要があります。コントロールプレーンノードはLinux、ワーカーノードはワークロードのニーズに応じてWindowsまたはLinuxで実行します。Windows Server 2019は、サポートされている唯一のWindowsオペレーティングシステムであり、Windows (kubelet、[コンテナランタイム](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd)、kube-proxyを含む)で[Kubernetesノード](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)を有効にします。Windowsディストリビューションチャンネルの詳細については、[Microsoftのドキュメント](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19)を参照してください。

@@ -52,7 +52,7 @@ Windows Serverホストオペレーティングシステムには、[Windows Ser

 Kubernetesの主要な要素は、WindowsでもLinuxと同じように機能します。このセクションでは、主要なワークロードイネーブラーのいくつかと、それらがWindowsにどのようにマップされるかについて説明します。

-* [Pods](/ja/docs/concepts/workloads/pods/pod-overview/)
+* [Pods](/ja/docs/concepts/workloads/pods/)

    Podは、Kubernetesにおける最も基本的な構成要素です。人間が作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最もシンプルな単位です。WindowsとLinuxのコンテナを同じPodにデプロイすることはできません。Pod内のすべてのコンテナは、各ノードが特定のプラットフォームとアーキテクチャを表す単一のノードにスケジュールされます。次のPod機能、プロパティ、およびイベントがWindowsコンテナでサポートされています。:

@@ -96,7 +96,27 @@ Pod、Controller、Serviceは、KubernetesでWindowsワークロードを管理

 #### コンテナランタイム

-KubernetesのWindows Server 2019/1809ノードでは、Docker EE-basic 18.09が必要です。これは、kubeletに含まれているdockershimコードで動作します。CRI-ContainerDなどの追加のランタイムは、Kubernetesの以降のバージョンでサポートされる可能性があります。
+##### Docker EE
+
+{{< feature-state for_k8s_version="v1.14" state="stable" >}}
+
+Docker EE-basic 18.09+は、Kubernetesを実行しているWindows Server 2019 / 1809ノードに推奨されるコンテナランタイムです。kubeletに含まれるdockershimコードで動作します。
+
+##### CRI-ContainerD
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+ContainerDはLinux上のKubernetesで動作するOCI準拠のランタイムです。Kubernetes v1.18では、Windows上での{{< glossary_tooltip term_id="containerd" text="ContainerD" >}}のサポートが追加されています。Windows上でのContainerDの進捗状況は[enhancements#1001](https://github.com/kubernetes/enhancements/issues/1001)で確認できます。
+
+{{< caution >}}
+
+Kubernetes v1.18におけるWindows上でのContainerDは以下の既知の欠点があります:
+
+* ContainerDは公式リリースではWindowsをサポートしていません。すなわち、Kubernetesでのすべての開発はアクティブなContainerD開発ブランチに対して行われています。本番環境へのデプロイは常に、完全にテストされセキュリティ修正をサポートした公式リリースを利用するべきです。
+* ContainerDを利用した場合、Group Managed Service Accountsは実装されていません。詳細は[containerd/cri#1276](https://github.com/containerd/cri/issues/1276)を参照してください。
+
+{{< /caution >}}
+

 #### 永続ストレージ

@@ -404,7 +424,6 @@ Kubernetesクラスターのトラブルシューティングの主なヘルプ

        # kubelet.exeを登録
        # マイクロソフトは、mcr.microsoft.com/k8s/core/pause:1.2.0としてポーズインフラストラクチャコンテナをリリース
-        # 詳細については、「KubernetesにWindowsノードを追加するためのガイド」で「pause」を検索してください
        nssm install kubelet C:\k\kubelet.exe
        nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=mcr.microsoft.com/k8s/core/pause:1.2.0 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false  --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
        nssm set kubelet AppDirectory C:\k
@@ -516,7 +535,7 @@ Kubernetesクラスターのトラブルシューティングの主なヘルプ

    PauseイメージがOSバージョンと互換性があることを確認してください。[説明](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)では、OSとコンテナの両方がバージョン1803であると想定しています。それ以降のバージョンのWindowsを使用している場合は、Insiderビルドなどでは、それに応じてイメージを調整する必要があります。イメージについては、Microsoftの[Dockerレジストリ](https://hub.docker.com/u/microsoft/)を参照してください。いずれにしても、PauseイメージのDockerfileとサンプルサービスの両方で、イメージに:latestのタグが付けられていると想定しています。

-    Kubernetes v1.14以降、MicrosoftはPauseインフラストラクチャコンテナを`mcr.microsoft.com/k8s/core/pause:1.2.0`でリリースしています。詳細については、[KubernetesにWindowsノードを追加するためのガイド](../user-guide-windows-nodes)で「Pause」を検索してください。
+    Kubernetes v1.14以降、MicrosoftはPauseインフラストラクチャコンテナを`mcr.microsoft.com/k8s/core/pause:1.2.0`でリリースしています。

 1. DNS名前解決が正しく機能していない

@@ -539,7 +558,7 @@ Kubernetesクラスターのトラブルシューティングの主なヘルプ

    Kubernetes Podでは、インフラストラクチャまたは「pause」コンテナが最初に作成され、コンテナエンドポイントをホストします。インフラストラクチャやワーカーコンテナなど、同じPodに属するコンテナは、共通のネットワークネームスペースとエンドポイント（同じIPとポートスペース）を共有します。Pauseコンテナは、ネットワーク構成を失うことなくクラッシュまたは再起動するワーカーコンテナに対応するために必要です。

-    「pause」（インフラストラクチャ）イメージは、Microsoft Container Registry（MCR）でホストされています。`docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`を使用してアクセスできます。詳細については、[DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)をご覧ください。
+    「pause」（インフラストラクチャ）イメージは、Microsoft Container Registry（MCR）でホストされています。`docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`を使用してアクセスできます。詳細については、[DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)をご覧ください。

 ### さらなる調査

@@ -568,18 +587,16 @@ Kubernetesクラスターのトラブルシューティングの主なヘルプ

 ロードマップには多くの機能があります。高レベルの簡略リストを以下に示しますが、[ロードマッププロジェクト](https://github.com/orgs/kubernetes/projects/8)を見て、[貢献すること](https://github.com/kubernetes/community/blob/master/sig-windows/)によってWindowsサポートを改善することをお勧めします。

-### CRI-ContainerD

-{{< glossary_tooltip term_id="containerd" >}}は、最近{{< glossary_tooltip text="CNCF" term_id="cncf" >}}プロジェクトとして卒業した、もう1つのOCI準拠ランタイムです。現在Linuxでテストされていますが、1.3はWindowsとHyper-Vをサポートします。[[リファレンス](https://blog.docker.com/2019/02/containerd-graduates-within-the-cncf/)]
+### Hyper-V分離

-CRI-ContainerDインターフェイスは、Hyper-Vに基づいてサンドボックスを管理できるようになります。これにより、RuntimeClassを次のような新しいユースケースに実装できる基盤が提供されます:
+Hyper-V分離はKubernetesで以下のWindowsコンテナのユースケースを実現するために必要です。

 * Pod間のハイパーバイザーベースの分離により、セキュリティを強化
 * 下位互換性により、コンテナの再構築を必要とせずにノードで新しいWindows Serverバージョンを実行
 * Podの特定のCPU/NUMA設定
 * メモリの分離と予約

-### Hyper-V分離

 既存のHyper-V分離サポートは、v1.10の試験的な機能であり、上記のCRI-ContainerD機能とRuntimeClass機能を優先して将来廃止される予定です。現在の機能を使用してHyper-V分離コンテナを作成するには、kubeletのフィーチャーゲートを`HyperVContainer=true`で開始し、Podにアノテーション`experimental.windows.kubernetes.io/isolation-type=hyperv`を含める必要があります。実験的リリースでは、この機能はPodごとに1つのコンテナに制限されています。

@@ -609,7 +626,7 @@ spec:

 ### kubeadmとクラスターAPIを使用したデプロイ

-Kubeadmは、ユーザーがKubernetesクラスターをデプロイするための事実上の標準になりつつあります。kubeadmのWindowsノードのサポートは、将来のリリースで提供予定です。Windowsノードが適切にプロビジョニングされるように、クラスターAPIにも投資しています。
+Kubeadmは、ユーザーがKubernetesクラスターをデプロイするための事実上の標準になりつつあります。kubeadmのWindowsノードのサポートは進行中ですが、ガイドはすでに[ここ](/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)で利用可能です。Windowsノードが適切にプロビジョニングされるように、クラスターAPIにも投資しています。

 ### その他の主な機能
 * グループ管理サービスアカウントのベータサポート
@@ -19,7 +19,7 @@ Windowsアプリケーションは、多くの組織で実行されるサービ

 ## 始める前に

-* [Windows Serverを実行するマスターノードとワーカーノード](/ja/docs/setup/production-environment/windows/user-guide-windows-nodes/)を含むKubernetesクラスターを作成します
+* [Windows Serverを実行するマスターノードとワーカーノード](/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)を含むKubernetesクラスターを作成します
 * Kubernetes上にServiceとワークロードを作成してデプロイすることは、LinuxコンテナとWindowsコンテナ共に、ほぼ同じように動作することに注意してください。クラスターとのインタフェースとなる[Kubectlコマンド](/docs/reference/kubectl/overview/)も同じです。Windowsコンテナをすぐに体験できる例を以下セクションに用意しています。

 ## はじめに:Windowsコンテナのデプロイ
@@ -1,306 +0,0 @@
---
-title: Guide for adding Windows Nodes in Kubernetes
-content_type: concept
-weight: 70
---
-
-<!-- overview -->
-
-The Kubernetes platform can now be used to run both Linux and Windows containers. One or more Windows nodes can be registered to a cluster. This guide shows how to:
-
-* Register a Windows node to the cluster
-* Configure networking so pods on Linux and Windows can communicate
-
-
-
-<!-- body -->
-
-## Before you begin
-
-* Obtain a [Windows Server license](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) in order to configure the Windows node that hosts Windows containers. You can use your organization's licenses for the cluster, or acquire one from Microsoft, a reseller, or via the major cloud providers such as GCP, AWS, and Azure by provisioning a virtual machine running Windows Server through their marketplaces. A [time-limited trial](https://www.microsoft.com/en-us/cloud-platform/windows-server-trial) is also available.
-
-* Build a Linux-based Kubernetes cluster in which you have access to the control plane (some examples include [Creating a single control-plane cluster with kubeadm](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), [AKS Engine](/ja/docs/setup/production-environment/turnkey/azure/), [GCE](/ja/docs/setup/production-environment/turnkey/gce/), [AWS](/ja/docs/setup/production-environment/turnkey/aws/).
-
-## Getting Started: Adding a Windows Node to Your Cluster
-
-### Plan IP Addressing
-
-Kubernetes cluster management requires careful planning of your IP addresses so that you do not inadvertently cause network collision. This guide assumes that you are familiar with the [Kubernetes networking concepts](/docs/concepts/cluster-administration/networking/).
-
-In order to deploy your cluster you need the following address spaces:
-
-| Subnet / address range | Description | Default value |
-| --- | --- | --- |
-| Service Subnet | A non-routable, purely virtual subnet that is used by pods to uniformly access services without caring about the network topology. It is translated to/from routable address space by `kube-proxy` running on the nodes. | 10.96.0.0/12 |
-| Cluster Subnet | This is a global subnet that is used by all pods in the cluster. Each node is assigned a smaller /24 subnet from this for their pods to use. It must be large enough to accommodate all pods used in your cluster. To calculate *minimumsubnet* size: `(number of nodes) + (number of nodes * maximum pods per node that you configure)`. Example: for a 5 node cluster for 100 pods per node: `(5) + (5 * 100) = 505.` | 10.244.0.0/16 |
-| Kubernetes DNS Service IP | IP address of `kube-dns` service that is used for DNS resolution & cluster service discovery. | 10.96.0.10 |
-
-Review the networking options supported in 'Intro to Windows containers in Kubernetes: Supported Functionality: Networking' to determine how you need to allocate IP addresses for your cluster.
-
-### Components that run on Windows
-
-While the Kubernetes control plane runs on your Linux node(s), the following components are configured and run on your Windows node(s).
-
-1. kubelet
-2. kube-proxy
-3. kubectl (optional)
-4. Container runtime
-
-Get the latest binaries from [https://github.com/kubernetes/kubernetes/releases](https://github.com/kubernetes/kubernetes/releases), starting with v1.14 or later. The Windows-amd64 binaries for kubeadm, kubectl, kubelet, and kube-proxy can be found under the CHANGELOG link.
-
-### Networking Configuration
-
-Once you have a Linux-based Kubernetes master node you are ready to choose a networking solution. This guide illustrates using Flannel in VXLAN mode for simplicity.
-
-#### Configuring Flannel in VXLAN mode on the Linux controller
-
-1. Prepare Kubernetes master for Flannel
-
-    Some minor preparation is recommended on the Kubernetes master in our cluster. It is recommended to enable bridged IPv4 traffic to iptables chains when using Flannel. This can be done using the following command:
-
-    ```bash
-    sudo sysctl net.bridge.bridge-nf-call-iptables=1
-    ```
-
-1. Download & configure Flannel
-
-    Download the most recent Flannel manifest:
-
-    ```bash
-    wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
-    ```
-
-    There are two sections you should modify to enable the vxlan networking backend:
-
-    After applying the steps below, the `net-conf.json` section of `kube-flannel.yml` should look as follows:
-
-    ```json
-    net-conf.json: |
-        {
-          "Network": "10.244.0.0/16",
-          "Backend": {
-            "Type": "vxlan",
-            "VNI" : 4096,
-            "Port": 4789
-          }
-        }
-    ```
-
-    {{< note >}}The VNI must be set to 4096 and port 4789 for Flannel on Linux to interoperate with Flannel on Windows. Support for other VNIs is coming soon. See the [VXLAN documentation](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)
-    for an explanation of these fields.{{< /note >}}
-
-1. In the `net-conf.json` section of your `kube-flannel.yml`, double-check:
-    1. The cluster subnet (e.g. "10.244.0.0/16") is set as per your IP plan.
-      * VNI 4096 is set in the backend
-      * Port 4789 is set in the backend
-    1. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`.
-
-
-    Your `cni-conf.json` should look as follows:
-
-    ```json
-    cni-conf.json: |
-        {
-          "name": "vxlan0",
-          "plugins": [
-            {
-              "type": "flannel",
-              "delegate": {
-                "hairpinMode": true,
-                "isDefaultGateway": true
-              }
-            },
-            {
-              "type": "portmap",
-              "capabilities": {
-                "portMappings": true
-              }
-            }
-          ]
-        }
-    ```
-
-1. Apply the Flannel yaml and Validate
-
-    Let's apply the Flannel configuration:
-
-    ```bash
-    kubectl apply -f kube-flannel.yml
-    ```
-
-    After a few minutes, you should see all the pods as running if the Flannel pod network was deployed.
-
-    ```bash
-    kubectl get pods --all-namespaces
-    ```
-
-    The output looks like as follows:
-
-    ```
-    NAMESPACE     NAME                                      READY        STATUS    RESTARTS   AGE
-    kube-system   etcd-flannel-master                       1/1          Running   0          1m
-    kube-system   kube-apiserver-flannel-master             1/1          Running   0          1m
-    kube-system   kube-controller-manager-flannel-master    1/1          Running   0          1m
-    kube-system   kube-dns-86f4d74b45-hcx8x                 3/3          Running   0          12m
-    kube-system   kube-flannel-ds-54954                     1/1          Running   0          1m
-    kube-system   kube-proxy-Zjlxz                          1/1          Running   0          1m
-    kube-system   kube-scheduler-flannel-master             1/1          Running   0          1m
-    ```
-
-    Verify that the Flannel DaemonSet has the NodeSelector applied.
-
-    ```bash
-    kubectl get ds -n kube-system
-    ```
-
-    The output looks like as follows. The NodeSelector `beta.kubernetes.io/os=linux` is applied.
-
-    ```
-    NAME              DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                                               AGE
-    kube-flannel-ds   2         2         2       2            2           beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux   21d
-    kube-proxy        2         2         2       2            2           beta.kubernetes.io/os=linux                                 26d
-    ```
-
-#### Join Windows Worker
-
-In this section we'll cover configuring a Windows node from scratch to join a cluster on-prem. If your cluster is on a cloud you'll likely want to follow the cloud specific guides in the next section.
-
-#### Preparing a Windows Node
-
-{{< note >}}
-All code snippets in Windows sections are to be run in a PowerShell environment with elevated permissions (Admin).
-{{< /note >}}
-
-1. Install Docker (requires a system reboot)
-
-    Kubernetes uses [Docker](https://www.docker.com/) as its container engine, so we need to install it. You can follow the [official Docs instructions](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon#install-docker), the [Docker instructions](https://store.docker.com/editions/enterprise/docker-ee-server-windows), or try the following *recommended* steps:
-
-    ```PowerShell
-    Enable-WindowsOptionalFeature -FeatureName Containers
-    Restart-Computer -Force
-    Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
-    Install-Package -Name Docker -ProviderName DockerMsftProvider
-    ```
-
-    If you are behind a proxy, the following PowerShell environment variables must be defined:
-
-    ```PowerShell
-    [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
-    [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
-    ```
-
-    After reboot, you can verify that the docker service is ready with the command below.
-
-    ```PowerShell
-    docker version
-    ```
-
-    If you see error message like the following, you need to start the docker service manually.
-
-    ```
-    Client:
-     Version: 17.06.2-ee-11
-     API version: 1.30
-     Go version: go1.8.7
-     Git commit: 06fc007
-     Built: Thu May 17 06:14:39 2018
-     OS/Arch: windows / amd64
-    error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.30/version: open //./pipe/docker_engine: The system c
-    annot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to
-    connect. This error may also indicate that the docker daemon is not running.
-    ```
-
-    You can start the docker service manually like below.
-
-    ```PowerShell
-    Start-Service docker
-    ```
-
-    {{< note >}}
-    The "pause" (infrastructure) image is hosted on Microsoft Container Registry (MCR). You can access it using "docker pull mcr.microsoft.com/k8s/core/pause:1.2.0". The DOCKERFILE is available at https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat.
-    {{< /note >}}
-
-1. Prepare a Windows directory for Kubernetes
-
-    Create a "Kubernetes for Windows" directory to store Kubernetes binaries as well as any deployment scripts and config files.
-
-    ```PowerShell
-    mkdir c:\k
-    ```
-
-1. Copy Kubernetes certificate
-
-    Copy the Kubernetes certificate file `$HOME/.kube/config` [from the Linux controller](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/creating-a-linux-master#collect-cluster-information) to this new `C:\k` directory on your Windows node.
-
-    Tip: You can use tools such as [xcopy](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy), [WinSCP](https://winscp.net/eng/download.php), or this [PowerShell wrapper for WinSCP](https://www.powershellgallery.com/packages/WinSCP/5.13.2.0) to transfer the config file between nodes.
-
-1. Download Kubernetes binaries
-
-    To be able to run Kubernetes, you first need to download the `kubelet` and `kube-proxy` binaries. You download these from the Node Binaries links in the CHANGELOG.md file of the [latest releases](https://github.com/kubernetes/kubernetes/releases/). For example 'kubernetes-node-windows-amd64.tar.gz'. You may also optionally download `kubectl` to run on Windows which you can find under Client Binaries.
-
-    Use the [Expand-Archive](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.archive/expand-archive?view=powershell-6) PowerShell command to extract the archive and place the binaries into `C:\k`.
-
-#### Join the Windows node to the Flannel cluster
-
-The Flannel overlay deployment scripts and documentation are available in [this repository](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/overlay). The following steps are a simple walkthrough of the more comprehensive instructions available there.
-
-Download the [Flannel start.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1) script, the contents of which should be extracted to `C:\k`:
-
-```PowerShell
-cd c:\k
-[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
-wget https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/flannel/start.ps1 -o c:\k\start.ps1
-```
-
-{{< note >}}
-[start.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1) references [install.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/install.ps1), which downloads additional files such as the `flanneld` executable and the [Dockerfile for infrastructure pod](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/Dockerfile) and install those for you. For overlay networking mode, the [firewall](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/helper.psm1#L111) is opened for local UDP port 4789. There may be multiple powershell windows being opened/closed as well as a few seconds of network outage while the new external vSwitch for the pod network is being created the first time. Run the script using the arguments as specified below:
-{{< /note >}}
-
-```PowerShell
-cd c:\k
-.\start.ps1 -ManagementIP <Windows Node IP> `
-  -NetworkMode overlay `
-  -ClusterCIDR <Cluster CIDR> `
-  -ServiceCIDR <Service CIDR> `
-  -KubeDnsServiceIP <Kube-dns Service IP> `
-  -LogDir <Log directory>
-```
-
-| Parameter | Default Value | Notes |
-| --- | --- | --- |
-| -ManagementIP | N/A (required) | The IP address assigned to the Windows node. You can use `ipconfig` to find this. |
-| -NetworkMode | l2bridge | We're using `overlay` here |
-| -ClusterCIDR | 10.244.0.0/16 | Refer to your cluster IP plan |
-| -ServiceCIDR | 10.96.0.0/12 | Refer to your cluster IP plan |
-| -KubeDnsServiceIP | 10.96.0.10 | |
-| -InterfaceName | Ethernet | The name of the network interface of the Windows host. You can use <code>ipconfig</code> to find this. |
-| -LogDir | C:\k | The directory where kubelet and kube-proxy logs are redirected into their respective output files. |
-
-Now you can view the Windows nodes in your cluster by running the following:
-
-```bash
-kubectl get nodes
-```
-
-{{< note >}}
-You may want to configure your Windows node components like kubelet and kube-proxy to run as services. View the services and background processes section under [troubleshooting](#troubleshooting) for additional instructions. Once you are running the node components as services, collecting logs becomes an important part of troubleshooting. View the [gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) section of the contributing guide for further instructions.
-{{< /note >}}
-
-### Public Cloud Providers
-
-#### Azure
-
-AKS-Engine can deploy a complete, customizable Kubernetes cluster with both Linux & Windows nodes. There is a step-by-step walkthrough available in the [docs on GitHub](https://github.com/Azure/aks-engine/blob/master/docs/topics/windows.md).
-
-#### GCP
-
-Users can easily deploy a complete Kubernetes cluster on GCE following this step-by-step walkthrough on [GitHub](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/windows/README-GCE-Windows-kube-up.md)
-
-#### Deployment with kubeadm and cluster API
-
-Kubeadm is becoming the de facto standard for users to deploy a Kubernetes cluster. Windows node support in kubeadm will come in a future release. We are also making investments in cluster API to ensure Windows nodes are properly provisioned.
-
-### Next Steps
-
-Now that you've configured a Windows worker in your cluster to run Windows containers you may want to add one or more Linux nodes as well to run Linux containers. You are now ready to schedule Windows containers on your cluster.
-
@@ -12,14 +12,16 @@ weight: 30

 ## サポートされるバージョン {#supported-versions}

-Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメジャーバージョン、**y**はマイナーバージョン、**z**はパッチバージョンを指します。これは[セマンティック バージョニング](http://semver.org/)に従っています。詳細は、[Kubernetesのリリースバージョニング](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)を参照してください。
+Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメジャーバージョン、**y**はマイナーバージョン、**z**はパッチバージョンを指します。これは[セマンティック バージョニング](https://semver.org/)に従っています。詳細は、[Kubernetesのリリースバージョニング](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)を参照してください。

-Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています。
+Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}})。
+
+セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、これらのブランチから [定期的に](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence) 切り出され、必要に応じて追加の緊急リリースも行われます。
+
+ [リリースマネージャー](https://git.k8s.io/sig-release/release-managers.md)グループがこれを決定しています。

-セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、定期的または必要に応じてこれらのブランチから分岐されます。[パッチリリースチーム](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-team.md#release-timing)がこれを決定しています。パッチリリースチームは[リリースマネージャー](https://github.com/kubernetes/sig-release/blob/master/release-managers.md)の一部です。
 詳細は、[Kubernetesパッチリリース](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md)ページを参照してください。

-マイナーリリースは約3ヶ月ごとに行われるため、マイナーリリースのブランチはそれぞれ約9ヶ月保守されます。

 ## サポートされるバージョンの差異

@@ -29,8 +31,8 @@ Kubernetesプロジェクトでは、最新の3つのマイナーリリースに

 例:

-* 最新の`kube-apiserver`が**1.13**であるとします
-* ほかの`kube-apiserver`インスタンスは**1.13**および**1.12**がサポートされます
+* 最新の`kube-apiserver`が**{{< skew latestVersion >}}**であるとします
+* ほかの`kube-apiserver`インスタンスは**{{< skew latestVersion >}}**および**{{< skew prevMinorVersion >}}**がサポートされます

 ### kubelet

@@ -38,8 +40,8 @@ Kubernetesプロジェクトでは、最新の3つのマイナーリリースに

 例:

-* `kube-apiserver`が**1.13**であるとします
-* `kubelet`は**1.13**、**1.12**および**1.11**がサポートされます
+* `kube-apiserver`が**{{< skew latestVersion >}}**であるとします
+* `kubelet`は**{{< skew latestVersion >}}**、**{{< skew prevMinorVersion >}}**および**{{< skew oldestMinorVersion >}}**がサポートされます

 {{< note >}}
 HAクラスター内の`kube-apiserver`間にバージョンの差異がある場合、有効な`kubelet`のバージョンは少なくなります。
@@ -47,8 +49,8 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある

 例:

-* `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします
-* `kubelet`は**1.12**および**1.11**がサポートされます（**1.13**はバージョン**1.12**の`kube-apiserver`よりも新しくなるためサポートされません)
+* `kube-apiserver`インスタンスが**{{< skew latestVersion >}}**および**1.12**であるとします
+* `kubelet`は**{{< skew prevMinorVersion >}}**および**{{< skew oldestMinorVersion >}}**がサポートされます（**{{< skew latestVersion >}}**はバージョン**{{< skew prevMinorVersion >}}**の`kube-apiserver`よりも新しくなるためサポートされません)

 ### kube-controller-manager、kube-scheduler、およびcloud-controller-manager

@@ -56,8 +58,8 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある

 例:

-* `kube-apiserver`が**1.13**であるとします
-* `kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.13**および**1.12**がサポートされます
+* `kube-apiserver`が**{{< skew latestVersion >}}**であるとします
+* `kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**{{< skew latestVersion >}}**および**{{< skew prevMinorVersion >}}**がサポートされます

 {{< note >}}
 HAクラスター内の`kube-apiserver`間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかの`kube-apiserver`と通信する場合(たとえばロードバランサーを経由して)、コンポーネントの有効なバージョンは少なくなります。
@@ -65,8 +67,8 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異があり

 例:

-* `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします
-* いずれかの`kube-apiserver`インスタンスへ配信するロードバランサーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.12**がサポートされます(**1.13**はバージョン**1.12**の`kube-apiserver`よりも新しくなるためサポートされません)
+* `kube-apiserver`インスタンスが**{{< skew latestVersion >}}**および**{{< skew prevMinorVersion >}}**であるとします
+* いずれかの`kube-apiserver`インスタンスへ配信するロードバランサーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**{{< skew prevMinorVersion >}}**がサポートされます(**{{< skew latestVersion >}}**はバージョン**{{< skew prevMinorVersion >}}**の`kube-apiserver`よりも新しくなるためサポートされません)

 ### kubectl

@@ -74,8 +76,8 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異があり

 例:

-* `kube-apiserver`が**1.13**であるとします
-* `kubectl`は**1.14**、**1.13**および**1.12**がサポートされます
+* `kube-apiserver`が**{{< skew latestVersion >}}**であるとします
+* `kubectl`は**{{< skew nextMinorVersion >}}**、**{{< skew latestVersion >}}**および**{{< skew prevMinorVersion >}}**がサポートされます

 {{< note >}}
 HAクラスター内の`kube-apiserver`間にバージョンの差異がある場合、有効な`kubectl`バージョンは少なくなります。
@@ -83,26 +85,26 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある

 例:

-* `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします
-* `kubectl`は**1.13**および**1.12**がサポートされます(ほかのバージョンでは、ある`kube-apiserver`コンポーネントからマイナーバージョンが2つ以上離れる可能性があります)
+* `kube-apiserver`インスタンスが**{{< skew latestVersion >}}**および**{{< skew prevMinorVersion >}}**であるとします
+* `kubectl`は**{{< skew latestVersion >}}**および**{{< skew prevMinorVersion >}}**がサポートされます(ほかのバージョンでは、ある`kube-apiserver`コンポーネントからマイナーバージョンが2つ以上離れる可能性があります)

 ## サポートされるコンポーネントのアップグレード順序

-コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**1.n**から**1.(n+1)** へ移行するために、コンポーネントをアップグレードする順序を説明します。
+コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン**{{< skew prevMinorVersion >}}**から**{{< skew latestVersion >}}** へ移行するために、コンポーネントをアップグレードする順序を説明します。

 ### kube-apiserver

 前提条件:

-* シングルインスタンスのクラスターにおいて、既存の`kube-apiserver`インスタンスは**1.n**とします
-* HAクラスターにおいて、既存の`kube-apiserver`は**1.n**または**1.(n+1)** とします(最新と最古の間で、最大で1つのマイナーバージョンの差異となります)
-* サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**1.n**とします(必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります)
-* すべてのノードの`kubelet`インスタンスはバージョン**1.n**または**1.(n-1)** とします(必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります)
+* シングルインスタンスのクラスターにおいて、既存の`kube-apiserver`インスタンスは**{{< skew prevMinorVersion >}}**とします
+* HAクラスターにおいて、既存の`kube-apiserver`は**{{< skew prevMinorVersion >}}**または**{{< skew latestVersion >}}** とします(最新と最古の間で、最大で1つのマイナーバージョンの差異となります)
+* サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**{{< skew prevMinorVersion >}}**とします(必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります)
+* すべてのノードの`kubelet`インスタンスはバージョン**{{< skew prevMinorVersion >}}**または**{{< skew oldestMinorVersion >}}** とします(必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります)
 * 登録されたAdmission webhookは、新しい`kube-apiserver`インスタンスが送信するこれらのデータを扱うことができます:
-  * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.(n+1)** で追加されたRESTリソースの新しいバージョンを含んで更新されます(または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください)
-  * Webhookは送信されたRESTリソースの新しいバージョン、および**1.(n+1)** のバージョンで追加された新しいフィールドを扱うことができます
+  * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**{{< skew latestVersion >}}** で追加されたRESTリソースの新しいバージョンを含んで更新されます(または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください)
+  * Webhookは送信されたRESTリソースの新しいバージョン、および**{{< skew latestVersion >}}** のバージョンで追加された新しいフィールドを扱うことができます

-`kube-apiserver`を**1.(n+1)** にアップグレードしてください。
+`kube-apiserver`を**{{< skew latestVersion >}}** にアップグレードしてください。

 {{< note >}}
 [非推奨API](/docs/reference/using-api/deprecation-policy/)および[APIの変更ガイドライン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)のプロジェクトポリシーにおいては、シングルインスタンスの場合でも`kube-apiserver`のアップグレードの際にマイナーバージョンをスキップしてはなりません。
@@ -112,17 +114,17 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある

 前提条件:

-* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**1.(n+1)** であること(これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません)
+* これらのコンポーネントと通信する`kube-apiserver`インスタンスが**{{< skew latestVersion >}}** であること(これらのコントロールプレーンコンポーネントが、クラスター内の`kube-apiserver`インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべての`kube-apiserver`インスタンスをアップグレードしなければなりません)

-`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**1.(n+1)** にアップグレードしてください。
+`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`を**{{< skew latestVersion >}}** にアップグレードしてください。

 ### kubelet

 前提条件:

-* `kubelet`と通信する`kube-apiserver`が**1.(n+1)** であること
+* `kubelet`と通信する`kube-apiserver`が**{{< skew latestVersion >}}** であること

-必要に応じて、`kubelet`インスタンスを**1.(n+1)** にアップグレードしてください(**1.n**や**1.(n-1)** のままにすることもできます)。
+必要に応じて、`kubelet`インスタンスを**{{< skew latestVersion >}}** にアップグレードしてください(**{{< skew prevMinorVersion >}}**や**{{< skew oldestMinorVersion >}}** のままにすることもできます)。

 {{< warning >}}
 `kube-apiserver`と2つのマイナーバージョンの`kubelet`インスタンスを使用してクラスターを実行させることは推奨されません:
@@ -130,3 +132,18 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある
 * コントロールプレーンをアップグレードする前に、インスタンスを`kube-apiserver`の1つのマイナーバージョン内にアップグレードさせる必要があります
 * メンテナンスされている3つのマイナーリリースよりも古いバージョンの`kubelet`を実行する可能性が高まります
 {{</ warning >}}
+
+
+
+### kube-proxy
+
+* `kube-proxy`のマイナーバージョンはノード上の`kubelet`と同じマイナーバージョンでなければなりません
+* `kube-proxy`は`kube-apiserver`よりも新しいものであってはなりません
+* `kube-proxy`のマイナーバージョンは`kube-apiserver`のマイナーバージョンよりも2つ以上古いものでなければなりません
+
+例:
+
+`kube-proxy`のバージョンが**{{< skew oldestMinorVersion >}}**の場合:
+
+* `kubelet`のバージョンは**{{< skew oldestMinorVersion >}}**でなければなりません
+* `kube-apiserver`のバージョンは**{{< skew oldestMinorVersion >}}**と**{{< skew latestVersion >}}**の間でなければなりません