Adding button "Learn Kubernetes Basics"

Signed-off-by: Nguyen Hai Truong <nguyenhaitruonghp@gmail.com>
Merge pull request #24963 from sftim/20201109_fix_flow_control_metrics_merge_wrong_branch
2020-11-11 23:29:12 +07:00 · 2020-11-09 16:34:41 -08:00 · 2020-11-09 21:32:44 +00:00 · 2020-11-09 12:34:27 -08:00 · 2020-11-08 17:43:38 -08:00 · 2020-11-09 09:30:53 +08:00
67 changed files with 2153 additions and 745 deletions
@@ -120,10 +120,11 @@ aliases:
    - bells17
    # cstoku
    - inductor
+    - kakts
    - makocchi-git
    # MasayaAoyama
    - nasa9084
-    - oke-py
+    # oke-py
  sig-docs-ko-owners: # Admins for Korean content
    - ClaudiaJKang
    - gochist
@@ -76,8 +76,7 @@ The following resource types are supported:
 | `limits.memory` | Across all pods in a non-terminal state, the sum of memory limits cannot exceed this value. |
 | `requests.cpu` | Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value. |
 | `requests.memory` | Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value. |
-| `hugepages-<size>` | Across all pods in a non-terminal state, the number of
-huge page requests of the specified size cannot exceed this value. |
+| `hugepages-<size>` | Across all pods in a non-terminal state, the number of huge page requests of the specified size cannot exceed this value. |
 | `cpu` | Same as `requests.cpu` |
 | `memory` | Same as `requests.memory` |

@@ -237,7 +236,7 @@ one value. For example:
          - middle
 ```

-If the `operator` is `Exists` or `DoesNotExist`, the `values field must *NOT* be
+If the `operator` is `Exists` or `DoesNotExist`, the `values` field must *NOT* be
 specified.

 ### Resource Quota Per PriorityClass
@@ -91,7 +91,7 @@ To see which admission plugins are enabled:
 kube-apiserver -h | grep enable-admission-plugins
 ```

-In 1.18, they are:
+In the current version, the default ones are:

 ```shell
 NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota
@@ -45,8 +45,8 @@ kubectl create namespace qos-example

 For a Pod to be given a QoS class of Guaranteed:

-* Every Container in the Pod must have a memory limit and a memory request, and they must be the same.
-* Every Container in the Pod must have a CPU limit and a CPU request, and they must be the same.
+* Every Container, including init containers, in the Pod must have a memory limit and a memory request, and they must be the same.
+* Every Container, including init containers, in the Pod must have a CPU limit and a CPU request, and they must be the same.

 Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a
 memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU request, both equal to 700 milliCPU:
@@ -52,7 +52,7 @@ Kamu dapat menambahkan parameter `--previous` pada perintah `kubectl logs` untuk

 ![Node-level _logging_](/images/docs/user-guide/logging/logging-node-level.png)

-Semua hal yang ditulis oleh aplikasi dalam kontainer ke `stdout` dan `stderr` akan ditangani dan diarahkan ke suatu tempat oleh mesin atau _engine_ kontainer. Contohnya,mesin kontainer Docker akan mengarahkan kedua aliran tersebut ke [suatu _logging driver_](https://docs.docker.com/engine/admin/logging/overview), yang akan dikonfigurasi pada Kubernetes untuk menuliskan ke dalam file dalam format json.
+Semua hal yang ditulis oleh aplikasi dalam kontainer ke `stdout` dan `stderr` akan ditangani dan diarahkan ke suatu tempat oleh mesin atau _engine_ kontainer. Contohnya,mesin kontainer Docker akan mengarahkan kedua aliran tersebut ke [suatu _logging driver_](https://docs.docker.com/engine/admin/logging/overview), yang akan dikonfigurasi pada Kubernetes untuk menuliskan ke dalam berkas dalam format json.

 {{< note >}}
 _Logging driver_ json dari Docker memperlakukan tiap baris sebagai pesan yang terpisah. Saat menggunakan _logging driver_ Docker, tidak ada dukungan untuk menangani pesan _multi-line_. Kamu harus menangani pesan _multi-line_ pada level agen log atau yang lebih tinggi.
@@ -203,7 +203,7 @@ Misalnya sebuah Node N sedang dipertimbangkan untuk pemindahan Pod sehingga sebu
 *   Pod P dipertimbangkan untuk Node N.
 *   Pod Q sedang berjalan pada Node lain pada Zona yang sama dengan Node N.
 *   Pod P memiliki anti-afinitas yang berlaku pada seluruh Zona terhadap Pod Q (`topologyKey:
-    failure-domain.beta.kubernetes.io/zone`).
+    topology.kubernetes.io/zone`).
 *   Tidak ada kasus anti-afinitas lain antara Pod P dengan Pod-pod lainnya pada Zona tersebut.
 *   Untuk dapat menjadwalkan Pod P pada Node N, Pod Q dapat dipindahkan, tetapi
    Scheduler tidak melakukan pemindahan Pod antar Node. Jadi, Pod P akan
@@ -1,5 +1,5 @@
 ---
-title: Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi
+title: Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan Berkas Konfigurasi
 content_type: concept
 weight: 10
 ---
@@ -26,12 +26,12 @@ Konfigurasi objek secara deklaratif membutuhkan pemahaman yang baik
 tentang definisi dan konfigurasi objek-objek Kubernetes. Jika belum pernah, kamu disarankan untuk membaca terlebih dulu dokumen-dokumen berikut:

 - [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/id/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [Pengelolaan Objek Kubernetes Menggunakan Berkas Konfigurasi Imperatif](/id/docs/tasks/manage-kubernetes-objects/imperative-config/)

 Berikut adalah beberapa defnisi dari istilah-istilah yang digunakan
 dalam dokumen ini:

- *objek file konfigurasi / file konfigurasi*: Sebuah *file* yang
+- *objek berkas konfigurasi / berkas konfigurasi*: Sebuah *file* yang
 mendefinisikan konfigurasi untuk sebuah objek Kubernetes. Dokumen ini akan memperlihatkan cara menggunakan *file* konfigurasi dengan perintah `kubectl apply`. *File-file* konfigurasi biasanya disimpan di sebuah *source control* seperti Git.
 - *konfigurasi objek live / konfigurasi live*: nilai konfigurasi *live* dari sebuah objek, sebagaimana yang tersimpan di klaster Kubernetes. Nilai-nilai ini disimpan di *storage* klaster Kubernetes, biasanya etcd.
 - *writer konfigurasi deklaratif / writer deklaratif*: Seseorang atau sebuah komponen perangkat lunak yang membuat pembaruan ke objek *live*. *Live writer* yang disebut pada dokumen ini adalah *writer* yang membuat perubahan terhadap *file* konfigurasi objek dan menjalankan perintah `kubectl apply` untuk menulis perubahan-perubahan tersebut.
@@ -340,7 +340,7 @@ Perintah `kubectl apply --prune` masih dalam versi alpha dan perubahan-perubahan
 Kamu harus berhati-hati ketika menggunakan perintah ini agar kamu tidak menghapus objek-objek lain secara tak sengaja.
 {{< /warning >}}

-Sebagai alternatif dari `kubectl delete`, kamu bisa menggunakan `kubectl apply` untuk mengidentifikasi objek-objek yang hendak dihapus setelah file konfigurasi objek-objek tersebut dihapus dari direktori. Ketika dijalankan dengan argumen `--prune`, perintah `kubectl apply` akan melakukan *query* ke *API server* untuk mencari semua objek yang sesuai dengan himpunan label-label tertentu, dan berusaha untuk mencocokkan kofigurasi objek *live* yg diperoleh terhadap *file* konfigurasi objek. Jika sebuah objek cocok dengan *query* yang dilakukan, dan objek tersebut tidak memiliki *file* konfigurasi di direktori serta tidak memiliki anotasi `last-applied-configuration`, objek tersebut akan dihapus.
+Sebagai alternatif dari `kubectl delete`, kamu bisa menggunakan `kubectl apply` untuk mengidentifikasi objek-objek yang hendak dihapus setelah berkas konfigurasi objek-objek tersebut dihapus dari direktori. Ketika dijalankan dengan argumen `--prune`, perintah `kubectl apply` akan melakukan *query* ke *API server* untuk mencari semua objek yang sesuai dengan himpunan label-label tertentu, dan berusaha untuk mencocokkan kofigurasi objek *live* yg diperoleh terhadap *file* konfigurasi objek. Jika sebuah objek cocok dengan *query* yang dilakukan, dan objek tersebut tidak memiliki *file* konfigurasi di direktori serta tidak memiliki anotasi `last-applied-configuration`, objek tersebut akan dihapus.

 {{< comment >}}
 TODO(pwittrock): Kita perlu mengubah cara kerja perintah ini untuk mencegah pengguna menjalankan apply ke sub direktori secara tidak disengaja.
@@ -372,7 +372,7 @@ Ketika memperbarui konfigurasi *live* dari sebuah objek, `kubectl apply` melakuk

 ### Perhitungan penggabungan *patch*

-Perintah `kubectl apply` menulis konten dari file konfigurasi ke anotasi `kubectl.kubernetes.io/last-applied-configuration`. Ini digunakan untuk mengidentifikasi *field* apa saja yang telah dihapus dari *file* konfigurasi dan perlu dihapus dari konfigurasi *live*. Berikut adalah langkah-langkah yang digunakan untuk menghitung *field* apa saja yang harus dihapus atau diubah:
+Perintah `kubectl apply` menulis konten dari berkas konfigurasi ke anotasi `kubectl.kubernetes.io/last-applied-configuration`. Ini digunakan untuk mengidentifikasi *field* apa saja yang telah dihapus dari *file* konfigurasi dan perlu dihapus dari konfigurasi *live*. Berikut adalah langkah-langkah yang digunakan untuk menghitung *field* apa saja yang harus dihapus atau diubah:

 1. Hitung *field-field* yang perlu dihapus. Ini mencakup *field-field* yang ada di `last-applied-configuration` tapi tidak ada di *file* konfigurasi.
 2. Hitung *field-field* yang perlu ditambah atau diubah. Ini mencakup *field-field* yang ada di *file* konfigurasi yang nilainya tidak sama dengan konfigurasi *live*.
@@ -533,7 +533,7 @@ Perlakukan *list* sama dengan *field* primitif. Ganti atau hapus keseluruhan lis
 # nilai last-applied-configuration*
    args: ["a", "b"]

-# nilai file konfigurasi
+# nilai berkas konfigurasi
    args: ["a", "c"]

 # nilai konfigurasi live
@@ -563,7 +563,7 @@ Strategi penggabungan ini menggunakan *tag* khusus `patchMergeKey` pada tiap *fi
    - name: nginx-helper-b # key: nginx-helper-b; akan dipertahankan pada hasil akhir
      image: helper:1.3

-# nilai file konfigurasi
+# nilai berkas konfigurasi
    containers:
    - name: nginx
      image: nginx:1.10
@@ -625,7 +625,7 @@ TODO(pwittrock): *Uncomment* ini untuk versi 1.6

 *API server* mengisi *field* tertentu dengan nilai *default* pada konfigurasi *live* jika nilai *field-field* tersebut tidak dispesifikasikan ketika objek dibuat.

-Berikut adalah sebuah *file* konfigurasi untuk sebuah Deployment. File berikut tidak menspesifikasikan `strategy`:
+Berikut adalah sebuah *file* konfigurasi untuk sebuah Deployment. Berkas berikut tidak menspesifikasikan `strategy`:

 {{< codenew file="application/simple_deployment.yaml" >}}

@@ -700,7 +700,7 @@ spec:
        ports:
        - containerPort: 80

-# file konfigurasi
+# berkas konfigurasi
 spec:
  strategy:
    type: Recreate # nilai yang diperbarui
@@ -863,7 +863,7 @@ template:
 ## {{% heading "whatsnext" %}}

 - [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/id/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan Berkas Konfigurasi](/id/docs/tasks/manage-kubernetes-objects/imperative-config/)
 - [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl-commands/)
 - [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)

@@ -120,7 +120,7 @@ kubectl create --edit -f /tmp/srv.yaml
 ```

 1. Perintah `kubectl create service` membuat konfigurasi untuk objek Service dan menyimpannya di `/tmp/srv.yaml`.
-1. Perintah `kubectl create --edit` membuka file konfigurasi untuk diedit sebelum objek dibuat.
+1. Perintah `kubectl create --edit` membuka berkas konfigurasi untuk disunting sebelum objek dibuat.



@@ -112,7 +112,6 @@ class: training
    </center>
  </div>
  <div class="main-section landscape-section">
-    <iframe src="https://landscape.cncf.io/category=kubernetes-training-partner&format=logo-mode&grouping=category&embed=yes" frameborder="0" id="landscape" scrolling="no"></iframe>
-    <script src="https://landscape.cncf.io/iframeResizer.js"></script>
+    {{< cncf-landscape helpers=false category="kubernetes-training-partner" >}}
  </div>
 </div>
@@ -1,4 +1,3 @@
 ---
-linktitle: Kubernetesドキュメント
-title: ドキュメント
+title: ドキュメント 
 ---
@@ -6,12 +6,11 @@ weight: 10

 <!-- overview -->

-Kubernetesはコンテナを _Node_ 上で実行されるPodに配置することで、ワークロードを実行します。
+Kubernetesはコンテナを_Node_上で実行されるPodに配置することで、ワークロードを実行します。
 ノードはクラスターによりますが、1つのVMまたは物理的なマシンです。
 各ノードは{{< glossary_tooltip text="Pod" term_id="pod" >}}やそれを制御する{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}を実行するのに必要なサービスを含んでいます。

 通常、1つのクラスターで複数のノードを持ちます。学習用途やリソースの制限がある環境では、1ノードかもしれません。
-
 1つのノード上の[コンポーネント](/ja/docs/concepts/overview/components/#node-components)には、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}、{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}が含まれます。

 <!-- body -->
@@ -23,7 +22,7 @@ Kubernetesはコンテナを _Node_ 上で実行されるPodに配置するこ
 1. ノード上のkubeletが、コントロールプレーンに自己登録する。
 2. あなた、もしくは他のユーザーが手動でNodeオブジェクトを追加する。

-Nodeオブジェクトの作成、もしくはノード上のkubeketによる自己登録の後、コントロールプレーンはNodeオブジェクトが有効かチェックします。例えば、下記のjsonマニフェストでノードを作成してみましょう:
+Nodeオブジェクトの作成、もしくはノード上のkubeketによる自己登録の後、コントロールプレーンはNodeオブジェクトが有効かチェックします。例えば、下記のjsonマニフェストでノードを作成してみましょう。

 ```json
 {
@@ -73,9 +72,9 @@ kubeletのフラグ `--register-node`がtrue（デフォルト）のとき、kub
 管理者が手動でNodeオブジェクトを作成したい場合は、kubeletフラグ `--register-node = false`を設定してください。

 管理者は`--register-node`の設定に関係なくNodeオブジェクトを変更することができます。
-例えば、ノードにラベルを設定し、それをunschedulableとしてマークすることが含まれます。
+変更には、ノードにラベルを設定し、それをunschedulableとしてマークすることが含まれます。

-ノード上のラベルは、スケジューリングを制御するためにPod上のノードセレクターと組み合わせて使用できます。
+ノード上のラベルは、スケジューリングを制御するためにPod上のノードセレクタと組み合わせて使用できます。
 例えば、Podをノードのサブセットでのみ実行する資格があるように制限します。

 ノードをunschedulableとしてマークすると、新しいPodがそのノードにスケジュールされるのを防ぎますが、ノード上の既存のPodには影響しません。
@@ -125,7 +124,7 @@ kubectl describe node <ノード名をここに挿入>
 {{< table caption = "ノードのConditionと、各condition適用時の概要" >}}
 | ノードのCondition       | 概要 |
 |----------------------|-------------|
-| `Ready`              | ノードの状態が有効でPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 |
+| `Ready`              | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 |
 | `DiskPressure`       | ノードのディスク容量が圧迫されているときに`True`になります。圧迫とは、ディスクの空き容量が少ないことを指します。それ以外のときは`False`です。 |
 | `MemoryPressure`     | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 |
 | `PIDPressure`        | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 |
@@ -242,7 +241,7 @@ kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担
 このような場合、ノードコントローラーはマスター接続に問題があると見なし、接続が回復するまですべての退役を停止します。

 ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。
-さらに、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応する{{< glossary_tooltip text="taint" term_id="taint" >}}を追加する責務があります。これはスケジューラーが、問題のあるノードにPodを配置しない事を意味しています。
+さらに、デフォルトで無効になっているアルファ機能として、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応する{{< glossary_tooltip text="taint" term_id="taint" >}}を追加する責務があります。これはスケジューラーが、問題のあるノードにPodを配置しない事を意味しています。

 {{< caution >}}
 `kubectl cordon`はノードに'unschedulable'としてマークします。それはロードバランサーのターゲットリストからノードを削除するという
@@ -255,7 +254,8 @@ Nodeオブジェクトはノードのリソースキャパシティ（CPUの数
 [自己登録](#self-registration-of-nodes)したノードは、Nodeオブジェクトを作成するときにキャパシティを報告します。
 [手動によるノード管理](#manual-node-administration)を実行している場合は、ノードを追加するときにキャパシティを設定する必要があります。

-Kubernetes{{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}}は、ノード上のすべてのPodに十分なリソースがあることを確認します。スケジューラーは、ノード上のコンテナが要求するリソースの合計がノードキャパシティ以下であることを確認します。
+Kubernetes{{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}}は、ノード上のすべてのPodに十分なリソースがあることを確認します。
+ノード上のコンテナが要求するリソースの合計がノードキャパシティ以下であることを確認します。
 これは、kubeletによって管理されたすべてのコンテナを含みますが、コンテナランタイムによって直接開始されたコンテナやkubeletの制御外で実行されているプロセスは含みません。

 {{< note >}}
@@ -0,0 +1,327 @@
+---
+title: クラウドプロバイダー
+content_type: concept
+weight: 30
+---
+
+<!-- overview -->
+このページでは、特定のクラウドプロバイダーで実行されているKubernetesを管理する方法について説明します。
+
+<!-- body -->
+### kubeadm
+[kubeadm](/ja/docs/reference/setup-tools/kubeadm/kubeadm/)は、Kubernetesクラスターを作成する選択肢として人気があります。
+kubeadmには、クラウドプロバイダーの設定情報を指定する設定オプションがあります。
+例えば、典型的なインツリークラウドプロバイダーは、以下のようにkubeadmを使用して設定することができます。
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: InitConfiguration
+nodeRegistration:
+  kubeletExtraArgs:
+    cloud-provider: "openstack"
+    cloud-config: "/etc/kubernetes/cloud.conf"
+---
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: ClusterConfiguration
+kubernetesVersion: v1.13.0
+apiServer:
+  extraArgs:
+    cloud-provider: "openstack"
+    cloud-config: "/etc/kubernetes/cloud.conf"
+  extraVolumes:
+  - name: cloud
+    hostPath: "/etc/kubernetes/cloud.conf"
+    mountPath: "/etc/kubernetes/cloud.conf"
+controllerManager:
+  extraArgs:
+    cloud-provider: "openstack"
+    cloud-config: "/etc/kubernetes/cloud.conf"
+  extraVolumes:
+  - name: cloud
+    hostPath: "/etc/kubernetes/cloud.conf"
+    mountPath: "/etc/kubernetes/cloud.conf"
+```
+
+典型的なインツリークラウドプロバイダーは、通常、[kube-apiserver](/ja/docs/reference/command-line-tools-reference/kube-apiserver/)および[kube-controller-manager](ja//docs/reference/command-line-tools-reference/kube-controller-manager/)、[kubelet](/ja/docs/reference/command-line-tools-reference/kubelet/)のコマンドラインで指定される`--cloud-provider`と`--cloud-config`の両方が必要です。
+プロバイダーごとに`--cloud-config`で指定されるファイルの内容についても、以下に記載します。
+
+すべての外部クラウドプロバイダーについては、以下の見出しに列挙されている個々のリポジトリーの案内に従ってください。または[すべてのリポジトリーのリスト](https://github.com/kubernetes?q=cloud-provider-&type=&language=)もご覧ください。
+
+## AWS
+ここでは、Amazon Web ServicesでKubernetesを実行する際に使用できるすべての設定について説明します。
+
+この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme)リポジトリーを参照してください。
+
+### ノード名
+
+AWSクラウドプロバイダーは、AWSインスタンスのプライベートDNS名をKubernetesのNodeオブジェクトの名前として使用します。
+
+### ロードバランサー
+以下のようにアノテーションを設定することで、[外部ロードバランサー](/ja/docs/tasks/access-application-cluster/create-external-load-balancer/)をAWS上で特定の機能を利用するように構成できます。
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: example
+  namespace: kube-system
+  labels:
+    run: example
+  annotations:
+     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #replace this value
+     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
+spec:
+  type: LoadBalancer
+  ports:
+  - port: 443
+    targetPort: 5556
+    protocol: TCP
+  selector:
+    app: example
+```
+AWSのロードバランサーサービスには、_アノテーション_ を使ってさまざまな設定を適用することができます。以下では、AWS ELBでサポートされているアノテーションについて説明します。
+
+* `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`: アクセスログの送信間隔を指定するために使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`: アクセスログを有効または無効にするためにサービスで使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`: アクセスログ用のs3バケット名を指定するために使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: アクセスログ用のs3バケットのプレフィックスを指定するために使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: ELBに追加タグとして記録されるキーとバリューのペアのコンマ区切りリストとして指定するためにサービスで使用します。例えば、`"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`のように指定できます。
+* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: リスナーの背後にあるバックエンド(Pod)が使用するプロトコルを指定するためにサービスで使用します。`http`(デフォルト)または`https`を指定すると、接続を終端してヘッダーを解析するHTTPSリスナーが生成されます。`ssl`または`tcp`を指定すると、「生の」SSLリスナーが使われます。`http`を指定して`aws-load-balancer-ssl-cert`を使わない場合は、HTTPリスナーが使われます。
+* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: セキュアなリスナーを要求するためにサービスで使用します。値は有効な証明書のARNです。詳細は、[ELBリスナーの設定](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)を参照してください。CertARNは、IAMまたはCM証明書のARNで、例えば`arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`のようになります。
+* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: 接続ドレインを有効または無効にするためにサービスで使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: 接続ドレインのタイムアウトを指定するためにサービスで使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: アイドル接続タイムアウトを指定するためにサービスで使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: クロスゾーン負荷分散を有効または無効にするためにサービスで使用されます。
+* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 作成されたELBに追加するセキュリティーグループを指定するために使用します。これは、以前にELBに割り当てられた他のすべてのセキュリティーグループを置き換えます。ここで定義されたセキュリティーグループは、サービス間で共有してはいけません。
+* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: 作成されたELBに加える追加のセキュリティーグループを指定するためにサービスで使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-internal`: 内部ELBが必要であることを示すためにサービスで使用します。
+* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: ELB上でプロキシープロトコルを有効にするためにサービスで使用します。現在は、すべてのELBバックエンドでプロキシープロトコルを有効にすることを意味する`*`という値しか受け付けません。将来的には、特定のバックエンドでのみプロキシープロトコルを設定できるように調整できます。
+* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`: SSL/HTTPSリスナーを使用するポートのコンマ区切りリストを指定するためにサービスで使用します。デフォルトは`*`(すべて)です。
+
+AWSのアノテーションの情報は、[aws.go](https://github.com/kubernetes/legacy-cloud-providers/blob/master/aws/aws.go)のコメントから引用しています。
+
+## Azure
+
+この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-azure](https://github.com/kubernetes/cloud-provider-azure#readme)リポジトリーを参照してください。
+
+### ノード名
+
+Azureクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+Kubernetesノード名は、Azure VM名と一致しなければならないことに注意してください。
+
+## CloudStack
+
+この外部クラウドプロバイダーを利用したい場合、[apache/cloudstack-kubernetes-provider](https://github.com/apache/cloudstack-kubernetes-provider)リポジトリーを参照してください。
+
+### ノード名
+
+CloudStackクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+Kubernetesノード名は、CloudStack VM名と一致しなければならないことに注意してください。
+
+## GCE
+
+この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)リポジトリーを参照してください。
+
+### ノード名
+
+GCEクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+Kubernetesノード名の最初のセグメントは、GCEインスタンス名と一致しなければならないことに注意してください。例えば、`kubernetes-node-2.c.my-proj.internal`という名前のノードは、`kubernetes-node-2`という名前のインスタンスに対応していなければなりません。
+
+## HUAWEI CLOUD
+
+この外部クラウドプロバイダーを利用したい場合、[kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)リポジトリーを参照してください。
+
+### ノード名
+
+HUAWEI CLOUDプロバイダーは、ノードのプライベートIPアドレスをKubernetesノード名として使用します。
+ノードでkubeletを開始するときは、必ず`--hostname-override=<node private IP>`を指定してください。
+
+## OpenStack
+ここでは、OpenStackでKubernetesを実行する際に使用できるすべての設定について説明します。
+
+この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-openstack](https://github.com/kubernetes/cloud-provider-openstack#readme)リポジトリーを参照してください。
+
+### ノード名
+
+OpenStackクラウドプロバイダーは、インスタンス名(OpenStackのメタデータで決定されたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+インスタンス名は必ず、Kubernetesノード名は、CloudStack VM名と一致しなければならないことに注意してください。
+kubeletがNodeオブジェクトを正常に登録できるように、インスタンス名は有効なKubernetesノード名である必要があります。
+
+### サービス
+
+KubernetesのOpenStackクラウドプロバイダーの実装では、利用可能な場合、基盤となるクラウドからこれらのOpenStackのサービスの使用をサポートします。
+
+| サービス名                 | APIバージョン    | 必須か    |
+|--------------------------|----------------|----------|
+| Block Storage (Cinder)   | V1†, V2, V3    | No       |
+| Compute (Nova)           | V2             | No       |
+| Identity (Keystone)      | V2‡,  V3       | Yes      |
+| Load Balancing (Neutron) | V1§, V2        | No       |
+| Load Balancing (Octavia) | V2             | No       |
+
+† Block Storage V1 APIのサポートは非推奨ですが、Kubernetes 1.9ではBlock Storage V3 APIのサポートが追加されました。
+
+‡ Identity V2 APIのサポートは非推奨となり、将来のリリースでプロバイダーから削除される予定です。「Queens」のリリース時点で、OpenStackはIdentity V2 APIを公開しません。
+
+§ Load Balancing V1 APIのサポートは、Kubernetes 1.9で削除されました。
+
+サービスディスカバリーは、プロバイダー設定で提供される`auth-url`を使用して、OpenStack Identity(Keystone)が管理するサービスカタログを一覧表示することで実現されます。
+プロバイダーは、Keystone以外のOpenStackサービスが利用できなくなった場合には、機能を緩やかに低下させ、影響を受ける機能のサポートを放棄します。
+特定の機能は、基盤となるクラウドでNeutronが公開している拡張機能のリストに基づいて有効または無効にされます。
+
+### cloud.conf
+Kubernetesはcloud.confというファイルを介して、OpenStackとのやりとり方法を知っています。
+これは、KubernetesにOpenStack認証エンドポイントの認証情報と場所を提供するファイルです。
+ファイル内に以下の詳細を指定することで、cloud.confファイルを作成できます。
+
+#### 典型的な設定
+以下の設定例は、最も頻繁に設定が必要な値に関するものです。
+プロバイダーをOpenStackクラウドのKeystoneエンドポイントに指定し、そのエンドポイントでの認証方法の詳細を提供し、さらにロードバランサーを設定します。
+
+```yaml
+[Global]
+username=user
+password=pass
+auth-url=https://<keystone_ip>/identity/v3
+tenant-id=c869168a828847f39f7f06edd7305637
+domain-id=2a73b8f597c04551a0fdc8e95544be8a
+
+[LoadBalancer]
+subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a
+```
+
+##### グローバル
+これらのOpenStackプロバイダーの設定オプションは、グローバル設定に関連しており、`cloud.conf`ファイルの`[Global]`セクションに記述する必要があります。
+
+* `auth-url`(必死): 認証に使用するKeystone APIのURLです。OpenStackのコントロールパネルでは、Access and Security > API Access > Credentialsで確認できます。
+* `username`(必須): Keystoneに設定されている有効なユーザーのユーザー名を参照します。
+* `password`(必須): Keystoneで設定された有効なユーザーのパスワードを参照します。
+* `tenant-id`(必須): リソースを作成するプロジェクトのIDを指定するために使用します。
+* `tenant-name`(任意): リソースを作成するプロジェクトの名前を指定します。
+* `trust-id`(任意): 認証に使用するtrustの識別子を指定するために使用します。trustは、ユーザー(委託者)が他のユーザー(受託者)に役割を委譲したり、受託者が委託者になりすますことを許可したりする権限を表します。利用可能なtrustは、Keystone APIの`/v3/OS-TRUST/trusts`エンドポイントの下にあります。
+* `domain-id`(任意): ユーザーが所属するドメインのIDを指定するために使用します。
+* `domain-name`(任意): ユーザーが所属するドメイン名を指定するために使用します。
+* `region`(任意): マルチリージョンのOpenStackクラウド上で実行する際に使うリージョンの識別子を指定するために使用します。リージョンはOpenStackデプロイメントの一般的な区分です。リージョンには厳密な地理的な意味合いはありませんが、デプロイメントでは`us-east`のような地理的な名前をリージョンの識別子に使うことができます。利用可能なリージョンはKeystone APIの`/v3/regions`エンドポイントの下にあります。
+* `ca-file`(任意): カスタムCAファイルのパスを指定するために使用します。
+
+
+テナントをプロジェクトに変更するKeystone V3を使用している場合、`tenant-id`の値は自動的にAPIのプロジェクト構造体にマッピングされます。
+
+##### ロードバランサー
+これらのOpenStackプロバイダーの設定オプションは、ロードバランサー設定に関連しており、`cloud.conf`ファイルの`[LoadBalancer]`セクションに記述する必要があります。
+
+* `lb-version`(任意): 自動バージョン検出を上書きするために使用します。有効な値は`v1`または`v2`です。値が指定されていない場合、自動検出は基盤となるOpenStackクラウドが公開するサポートバージョンのうち、最も高いものを選択します。
+* `use-octavia`(任意): Octavia LBaaS V2サービスカタログエンドポイントを探して、利用するかどうかを決定するために使用します。有効な値は`true`または`false`です。`true`が指定され、Octaiva LBaaS V2エントリーが見つからなかった場合、プロバイダーはフォールバックして代わりにNeutron LBaaS V2エンドポイントを見つけようとします。デフォルト値は`false` です。
+* `subnet-id`(任意): ロードバランサーを作成したいサブネットのIDを指定します。Network > Networksにあります。サブネットを取得するには、それぞれのネットワークをクリックします。
+* `floating-network-id`(任意): 指定した場合、ロードバランサーのフローティングIPを作成します。
+* `lb-method`(任意): ロードバランサープールのメンバー間で負荷分散させるアルゴリズムを指定するために使用します。値には`ROUND_ROBIN`、`LEAST_CONNECTIONS`、`SOURCE_IP`を指定できます。何も指定しない場合のデフォルトの動作は`ROUND_ROBIN` です。
+* `lb-provider`(任意): ロードバランサーのプロバイダーを指定するために使用します。指定しない場合は、Neutronで設定されたデフォルトのプロバイダサービスが使用されます。
+* `create-monitor`(任意): Neutronロードバランサーのヘルスモニターを作成するかどうかを表します。有効な値は`true`と`false`で、デフォルト値は`false`です。`true`を指定した場合は、`monitor-delay`、`monitor-timeout`、`monitor-max-retries`も設定しなければなりません。
+* `monitor-delay`(任意): ロードバランサーのメンバーにプローブを送信するまでの時間です。有効な時間単位を指定してください。有効な時間単位は"ns"、"us"(または"μs")、"ms"、"s"、"m"、"h"です。
+* `monitor-timeout`(任意): モニタリングがタイムアウトする前にpingの応答を待つための最大の時間です。この値はdelay値よりも小さくする必要があります。有効な時間単位を指定してください。有効な時間単位は"ns"、"us"(または"μs")、"ms"、"s"、"m"、"h"です。
+* `monitor-max-retries`(任意): ロードバランサーメンバーのステータスをINACTIVEに変更する前に許容されるpingの失敗の数です。1から10の間の数値でなければなりません。
+* `manage-security-groups`(任意): ロードバランサーがセキュリティーグループのルールを自動的に管理するかどうかを決定します。有効な値は`true`と`false`で、デフォルト値は`false`です。`true`を指定した場合は、`node-security-group`も指定しなければなりません。
+* `node-security-group`(任意): 管理するセキュリティーグループのIDです。
+
+##### ブロックストレージ
+これらのOpenStackプロバイダーの設定オプションは、ブロックストレージ設定に関連しており、`cloud.conf`ファイルの`[BlockStorage]`セクションに記述する必要があります。
+
+* `bs-version`(任意): 自動バージョン検出を上書きするために使用します。有効な値は`v1`、`v2`、`v3`、`auto`です。`auto`が指定された場合、自動検出は基盤となるOpenStackクラウドが公開するサポートバージョンのうち、最も高いものを選択します。何も指定しない場合のデフォルト値は`auto`です。
+* `trust-device-path`(任意): ほとんどのシナリオでは、Cinderが提供するブロックデバイス名(例: `/dev/vda`)は信頼できません。このブール値はこの動作をトグルします。`true`に設定すると、Cinderが提供するブロックデバイス名を信頼することになります。デフォルト値の`false`は、シリアル番号と`/dev/disk/by-id`のマッピングに基づいてデバイスのパスを検出します。
+* `ignore-volume-az`(任意): Cinderボリュームをアタッチする際のアベイラビリティーゾーンの使用に影響を与えます。NovaとCinderのアベイラビリティーゾーンが異なる場合は、`true`に設定する必要があります。これは、Novaのアベイラビリティーゾーンが多くあるにも関わらず、Cinderのアベイラビリティーゾーンが1つしかない場合によく見られます。デフォルト値は以前のリリースで使用されていた動作を維持するために`false`になっていますが、将来的には変更される可能性があります。
+* `node-volume-attach-limit`(任意): ノードにアタッチできるボリュームの最大数で、デフォルトはCinderの256です。
+
+エンドポイントを区別するためにポートではなくパスを使用しているOpenStackデプロイメントにおいて、Kubernetesのバージョン1.8以下をデプロイする際、明示的に`bs-version`パラメーターの設定が必要な場合があります。パスベースのエンドポイントは`http://foo.bar/volume`の形式であり、ポートベースのエンドポイントは`http://foo.bar:xxx`の形式です。
+
+パスベースのエンドポイントを使う環境で、Kubernetesが古い自動検出ロジックを使用している場合、ボリュームの切り離しを試みると`BS API version autodetection failed.`というエラーが返されます。この問題を回避するには、クラウドプロバイダー設定に以下のように追記することで、Cinder APIバージョン2を強制的に使用することができます。
+
+```yaml
+[BlockStorage]
+bs-version=v2
+```
+
+##### メタデータ
+これらのOpenStackプロバイダーの設定オプションは、メタデータ設定に関連しており、`cloud.conf`ファイルの`[Metadata]`セクションに記述する必要があります。
+
+* `search-order`(任意): この設定のキーは、プロバイダーが実行するインスタンスに関連するメタデータの取得方法に影響します。デフォルト値の`configDrive,metadataService`について、プロバイダーは、コンフィグドライブが利用可能な場合は最初にインスタンスに関連するメタデータをそこから取得し、次にメタデータサービスから取得します。代替値は以下の通りです。
+  * `configDrive` - コンフィグドライブからのみ、インスタンスのメタデータを取得します。
+  * `metadataService` - メタデータサービスからのみ、インスタンスのメタデータを取得します。
+  * `metadataService,configDrive` - 最初にメタデータサービスからインスタンスのメタデータを取得し、次にコンフィグドライブから取得します。
+
+  コンフィグドライブ上のメタデータは時間の経過とともに陳腐化する可能性がありますが、メタデータサービスは常に最新の情報を提供するため、この動作を調整するのが望ましいです。しかし、すべてのOpenStackクラウドがコンフィグドライブとメタデータサービスの両方を提供しているわけではなく、どちらか一方しか利用できない場合もあるため、デフォルトでは両方をチェックするようになっています。
+
+##### ルート
+これらのOpenStackプロバイダーの設定オプションは、[kubenet](/ja/docs/concepts/cluster-administration/network-plugins/#kubenet)のKubernetesネットワークプラグインに関連しており、`cloud.conf`ファイルの`[Route]`セクションに記述する必要があります。
+
+
+* `router-id`(任意): 基盤となるクラウドのNeutronデプロイメントが`extraroutes`拡張機能をサポートしている場合は、`router-id`を使用してルートを追加するルーターを指定します。選択したルーターは、クラスターノードを含むプライベートネットワークにまたがっていなければなりません(通常、ノードネットワークは1つしかないので、この値はノードネットワークのデフォルトルーターになります)。この値は、OpenStackで[kubenet](/docs/concepts/cluster-administration/network-plugins/#kubenet)を使用するために必要です。
+
+## OVirt
+
+### ノード名
+
+OVirtクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+Kubernetesノード名は、VMのFQDN(`<vm><guest_info><fqdn>...</fqdn></guest_info></vm>`の下でOVirtによって報告されたもの)と一致しなければならないことに注意してください。
+
+## Photon
+
+### ノード名
+
+Photonクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+Kubernetesノード名はPhoton VM名と一致しなければならないことに注意してください(もしくは、`--cloud-config`で`overrideIP`がtrueに設定されている場合は、Kubernetesノード名はPhoton VMのIPアドレスと一致しなければなりません)。
+
+## vSphere
+
+{{< tabs name="vSphere cloud provider" >}}
+{{% tab name="vSphere 6.7U3以上" %}}
+vSphere 6.7U3以上のすべてのvSphereデプロイメントでは、[external vSphere cloud provider](https://github.com/kubernetes/cloud-provider-vsphere)と[vSphere CSI driver](https://github.com/kubernetes-sigs/vsphere-csi-driver)の使用を推奨します。クイックスタートガイドについては、[Deploying a Kubernetes Cluster on vSphere with CSI and CPI](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/kubernetes-on-vsphere-with-kubeadm.html)を参照してください。
+{{% /tab %}}
+{{% tab name="vSphere 6.7U3未満" %}}
+vSphere 6.7U3未満を実行している場合は、インツリーのvSphereクラウドプロバイダーを推奨します。クイックスタートガイドについては、[Running a Kubernetes Cluster on vSphere with kubeadm](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/k8s-vcp-on-vsphere-with-kubeadm.html)を参照してください。
+{{% /tab %}}
+{{< /tabs >}}
+
+vSphereクラウドプロバイダーの詳細なドキュメントについては、[vSphereクラウドプロバイダーのドキュメントサイト](https://cloud-provider-vsphere.sigs.k8s.io)を参照してください。
+
+## IBM Cloud Kubernetes Service
+
+### コンピュートノード
+IBM Cloud Kubernetes Serviceプロバイダーを使用することで、仮想ノードと物理ノード(ベアメタル)を混在させたクラスターを単一のゾーン、またはリージョン内の複数のゾーンにまたがって作成することができます。詳細については、[Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes)を参照してください。
+
+Kubernetes Nodeオブジェクトの名前は、IBM Cloud Kubernetes ServiceワーカーノードインスタンスのプライベートIPアドレスです。
+
+### ネットワーク
+IBM Cloud Kubernetes Serviceプロバイダーは、高品質なネットワークパフォーマンスとノードのネットワーク分離のためにVLANを提供します。カスタムファイアウォールやCalicoネットワークポリシーを設定して、クラスターにセキュリティーの追加レイヤーを加えたり、VPNを使用してクラスターをオンプレミスデータセンターに接続したりすることができます。詳細については、[Planning your cluster network setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters)を参照してください。
+
+アプリケーションをパブリックまたはクラスター内で公開するには、NodePort、LoadBalancer、Ingressサービスを利用できます。また、Ingressアプリケーションのロードバランサーをアノテーションでカスタマイズすることもできます。詳細については、[Choosing an app exposure service](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)を参照してください。
+
+### ストレージ
+IBM Cloud Kubernetes Serviceプロバイダーは、Kubernetesネイティブの永続ボリュームを活用して、ユーザーがファイル、ブロック、およびクラウドオブジェクトストレージをアプリケーションにマウントできるようにします。また、データの永続ストレージにDatabase as a Serviceやサードパーティーのアドオンを使用することもできます。詳しくは、[Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)を参照してください。
+
+## Baidu Cloud Container Engine
+
+### ノード名
+
+Baiduクラウドプロバイダーは、ノードのプライベートIPアドレス(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+Kubernetesノード名はBaidu VMのプライベートIPと一致しなければならないことに注意してください。
+
+## Tencent Kubernetes Engine
+
+この外部クラウドプロバイダーを利用したい場合、[TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)リポジトリーを参照してください。
+
+### ノード名
+
+Baiduクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。
+Kubernetesノード名はTencent VMのプライベートIPと一致しなければならないことに注意してください。
+
+## Alibaba Cloud Kubernetes
+
+この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-alibaba-cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)リポジトリーを参照してください。
+
+### ノード名
+
+Alibaba Cloudではノード名の書式は必要ありませんが、kubeletでは`--provider-id=${REGION_ID}.${INSTANCE_ID}`を追加する必要があります。パラメーター`${REGION_ID}`はKubernetesのリージョンのIDを、`${INSTANCE_ID}`はAlibaba ECS(Elastic Compute Service)のIDを表します。
+
+### ロードバランサー
+
+[アノテーション](https://www.alibabacloud.com/help/en/doc-detail/86531.htm)を設定することで、Alibaba Cloudの特定の機能を使用するように外部のロードバランサーを設定できます。
@@ -45,7 +45,7 @@ KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内の

 `Pod`に転送する`ノード`自体のポート(ホストポートと呼ばれる)を要求することは可能ですが、これは非常にニッチな操作です。このポート転送の実装方法も、コンテナランタイムの詳細部分です。`Pod`自体は、ホストポートの有無を認識しません。

-## Kubernetesネットワークモデルの実装方法 {#how-to-implement-the-kubernetes-networking-model}
+## Kubernetesネットワークモデルの実装方法

 このネットワークモデルを実装する方法はいくつかあります。このドキュメントは、こうした方法を網羅的にはカバーしませんが、いくつかの技術の紹介として、また出発点として役立つことを願っています。

@@ -84,7 +84,7 @@ CPUは常に相対量としてではなく、絶対量として要求されま
 ### メモリーの意味

 `メモリー`の制限と要求はバイト単位で測定されます。
-E、P、T、G、M、Kのいずれかのサフィックスを使用して、メモリーを整数または固定小数点数として表すことができます。
+E、P、T、G、M、Kのいずれかのサフィックスを使用して、メモリーを整数または固定小数点整数として表すことができます。
 また、Ei、Pi、Ti、Gi、Mi、Kiのような2の累乗の値を使用することもできます。
 たとえば、以下はほぼ同じ値を表しています。

@@ -104,9 +104,11 @@ metadata:
  name: frontend
 spec:
  containers:
-  - name: app
-    image: images.my-company.example/app:v4
+  - name: db
+    image: mysql
    env:
+    - name: MYSQL_ROOT_PASSWORD
+      value: "password"
    resources:
      requests:
        memory: "64Mi"
@@ -114,8 +116,8 @@ spec:
      limits:
        memory: "128Mi"
        cpu: "500m"
-  - name: log-aggregator
-    image: images.my-company.example/log-aggregator:v6
+  - name: wp
+    image: wordpress
    resources:
      requests:
        memory: "64Mi"
@@ -183,7 +185,7 @@ kubeletは、ローカルのエフェメラルストレージを使用して、P
 また、kubeletはこの種類のストレージを使用して、[Nodeレベルのコンテナログ](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)、コンテナイメージ、実行中のコンテナの書き込み可能なレイヤーを保持します。

 {{< caution >}}
-Nodeに障害が発生すると、そのエフェメラルストレージ内のデータが失われる可能性があります。
+Nodeに障害が発生すると、そのエフェメラルストレージ内のデータが失われる可能性があります。  
 アプリケーションは、ローカルのエフェメラルストレージにパフォーマンスのサービス品質保証(ディスクのIOPSなど)を期待することはできません。
 {{< /caution >}}

@@ -240,7 +242,7 @@ Podの各コンテナは、次の1つ以上を指定できます。
 * `spec.containers[].resources.requests.ephemeral-storage`

 `ephemeral-storage`の制限と要求はバイト単位で記します。
-ストレージは、次のいずれかの接尾辞を使用して、通常の整数または固定小数点数として表すことができます。
+ストレージは、次のいずれかの接尾辞を使用して、通常の整数または固定小数点整数として表すことができます。
 E、P、T、G、M、K。Ei、Pi、Ti、Gi、Mi、Kiの2のべき乗を使用することもできます。
 たとえば、以下はほぼ同じ値を表しています。

@@ -260,15 +262,18 @@ metadata:
  name: frontend
 spec:
  containers:
-  - name: app
-    image: images.my-company.example/app:v4
+  - name: db
+    image: mysql
+    env:
+    - name: MYSQL_ROOT_PASSWORD
+      value: "password"
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
-  - name: log-aggregator
-    image: images.my-company.example/log-aggregator:v6
+  - name: wp
+    image: wordpress
    resources:
      requests:
        ephemeral-storage: "2Gi"
@@ -295,7 +300,6 @@ kubeletがローカルのエフェメラルストレージをリソースとし
 Podが許可するよりも多くのエフェメラルストレージを使用している場合、kubeletはPodの排出をトリガーするシグナルを設定します。

 コンテナレベルの分離の場合、コンテナの書き込み可能なレイヤーとログ使用量がストレージの制限を超えると、kubeletはPodに排出のマークを付けます。
-
 Podレベルの分離の場合、kubeletはPod内のコンテナの制限を合計し、Podの全体的なストレージ制限を計算します。
 このケースでは、すべてのコンテナからのローカルのエフェメラルストレージの使用量とPodの`emptyDir`ボリュームの合計がPod全体のストレージ制限を超過する場合、
 kubeletはPodをまた排出対象としてマークします。
@@ -341,7 +345,7 @@ Kubernetesでは、`1048576`から始まるプロジェクトIDを使用しま
 Kubernetesが使用しないようにする必要があります。

 クォータはディレクトリスキャンよりも高速で正確です。
-ディレクトリがプロジェクトに割り当てられると、ディレクトリ配下に作成されたファイルはすべてそのプロジェクト内に作成され、カーネルはそのプロジェクト内のファイルによって使用されているブロックの数を追跡するだけです。
+ディレクトリがプロジェクトに割り当てられると、ディレクトリ配下に作成されたファイルはすべてそのプロジェクト内に作成され、カーネルはそのプロジェクト内のファイルによって使用されているブロックの数を追跡するだけです。  
 ファイルが作成されて削除されても、開いているファイルディスクリプタがあれば、スペースを消費し続けます。
 クォータトラッキングはそのスペースを正確に記録しますが、ディレクトリスキャンは削除されたファイルが使用するストレージを見落としてしまいます。

@@ -350,7 +354,7 @@ Kubernetesが使用しないようにする必要があります。
 * kubelet設定で、`LocalocalStorpactionCapactionIsolationFSQuotaMonitoring=true`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gate/)を有効にします。

 * ルートファイルシステム(またはオプションのランタイムファイルシステム))がプロジェクトクォータを有効にしていることを確認してください。
-  すべてのXFSファイルシステムはプロジェクトクォータをサポートしています。
+  すべてのXFSファイルシステムはプロジェクトクォータをサポートしています。  
  ext4ファイルシステムでは、ファイルシステムがマウントされていない間は、プロジェクトクォータ追跡機能を有効にする必要があります。
  ```bash
  # ext4の場合、/dev/block-deviceがマウントされていません
@@ -57,7 +57,7 @@ Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロッ
 Kubernetesは以下を提供します。

 * **サービスディスカバリーと負荷分散**  
-Kubernetesは、DNS名または独自のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるため、デプロイが安定します。
+Kubernetesは、DNS名または独自のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるたため、デプロイが安定します。
 * **ストレージ オーケストレーション**  
 Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したストレージシステムを自動でマウントすることができます。
 * **自動化されたロールアウトとロールバック**  
@@ -186,10 +186,10 @@ Pod間アフィニティは、PodSpecの`affinity`フィールド内に`podAffin

 このPodのアフィニティは、PodアフィニティとPodアンチアフィニティを1つずつ定義しています。
 この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。
-Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、
-Node Nがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。
+Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`topology.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、
+Node Nがキー`topology.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。
 Podアンチアフィニティは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています
-(`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。
+(`topologyKey`が`topology.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。
 PodアフィニティとPodアンチアフィニティや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。

 PodアフィニティとPodアンチアフィニティで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。
@@ -20,7 +20,7 @@ Serviceのすべてのネットワークエンドポイントが単一のEndpoin

 ## EndpointSliceリソース {#endpointslice-resource}

-Kubernetes内ではEndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。EndpointSliceコントローラーは、{{< glossary_tooltip text="セレクター" term_id="selector" >}}が指定されると、Kubernetes Serviceに対するEndpointSliceを自動的に作成します。これらのEndpointSliceにはServiceセレクターに一致する任意のPodへのリファレンスが含まれます。EndpointSliceはネットワークエンドポイントをユニークなServiceとPortの組み合わせでグループ化します。EndpointSliceオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
+Kubernetes内ではEndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。EndpointSliceコントローラーは、{{< glossary_tooltip text="セレクター" term_id="selector" >}}が指定されると、Kubernetes Serviceに対するEndpointSliceを自動的に作成します。これらのEndpointSliceにはServiceセレクターに一致する任意のPodへのリファレクンスが含まれます。EndpointSliceはネットワークエンドポイントをユニークなServiceとPortの組み合わせでグループ化します。EndpointSliceオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。

 一例として、以下に`example`というKubernetes Serviceに対するサンプルのEndpointSliceリソースを示します。

@@ -37,7 +37,7 @@ Ingressリソースが動作するためには、クラスターでIngressコン

 ## 複数のIngressコントローラーの使用 {#using-multiple-ingress-controllers}

-[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定します。
+[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers))クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定します。

 クラスを定義しない場合、クラウドプロバイダーはデフォルトのIngressコントローラーを使用する場合があります。

@@ -712,7 +712,7 @@ NLBの背後にあるインスタンスに対してクライアントのトラ
 |------|----------|---------|------------|---------------------|
 | ヘルスチェック | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
 | クライアントのトラフィック | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
-| MTUによるサービスディスカバリー | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |
+| MTCによるサービスディスカバリー | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |

 どのクライアントIPがNLBにアクセス可能かを制限するためには、`loadBalancerSourceRanges`を指定してください。

@@ -31,9 +31,8 @@ Deploymentによって作成されたReplicaSetを管理しないでください
 * ReplicaSetをロールアウトするために[Deploymentの作成](#creating-a-deployment)を行う: ReplicaSetはバックグラウンドでPodを作成します。Podの作成が完了したかどうかは、ロールアウトのステータスを確認してください。
 * DeploymentのPodTemplateSpecを更新することにより[Podの新しい状態を宣言する](#updating-a-deployment): 新しいReplicaSetが作成され、Deploymentは指定された頻度で古いReplicaSetから新しいReplicaSetへのPodの移行を管理します。新しいReplicaSetはDeploymentのリビジョンを更新します。
 * Deploymentの現在の状態が不安定な場合、[Deploymentのロールバック](#rolling-back-a-deployment)をする: ロールバックによる各更新作業は、Deploymentのリビジョンを更新します。
-* より多くの負荷をさばけるように、[Deploymentをスケールアップ](#scaling-a-deployment)する。
+* より多くの負荷をさばけるように、[Deploymentをスケールアップ](#scaling-a-deployment)する
 * PodTemplateSpecに対する複数の修正を適用するために[Deploymentを停止(Pause)し](#pausing-and-resuming-a-deployment)、それを再開して新しいロールアウトを開始します。
-* [Deploymentのステータス](#deployment-status) をロールアウトが失敗したサインとして利用する。
 * 今後必要としない[古いReplicaSetのクリーンアップ](#clean-up-policy)

 ## Deploymentの作成 {#creating-a-deployment}
@@ -83,7 +82,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください
  ```
  クラスターにてDeploymentを調査するとき、以下のフィールドが出力されます。
  * `NAME`は、クラスター内にあるDeploymentの名前一覧です。
-  * `READY`は、ユーザーが使用できるアプリケーションのレプリカの数です。使用可能な数/理想的な数の形式で表示されます。
+  * `READY`は、ユーザーが使用できるアプリケーションのレプリカの数です。
  * `UP-TO-DATE`は、理想的な状態を満たすためにアップデートが完了したレプリカの数です。
  * `AVAILABLE`は、ユーザーが利用可能なレプリカの数です。
  * `AGE`は、アプリケーションが稼働してからの時間です。
@@ -134,7 +133,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください
 {{< note >}}
 Deploymentに対して適切なセレクターとPodテンプレートのラベルを設定する必要があります(このケースでは`app: nginx`)。

-ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザーがラベルを重複させることを阻止しないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
+ラベルやセレクターを他のコントローラーと重複させないでください(他のDeploymentやStatefulSetを含む)。Kubernetesはユーザーがラベルを重複させることを止めないため、複数のコントローラーでセレクターの重複が発生すると、コントローラー間で衝突し予期せぬふるまいをすることになります。
 {{< /note >}}

 ### pod-template-hashラベル
@@ -147,7 +146,7 @@ Deploymentに対して適切なセレクターとPodテンプレートのラベ

 このラベルはDeploymentが管理するReplicaSetが重複しないことを保証します。このラベルはReplicaSetの`PodTemplate`をハッシュ化することにより生成され、生成されたハッシュ値はラベル値としてReplicaSetセレクター、Podテンプレートラベル、ReplicaSetが作成した全てのPodに対して追加されます。

-## Deploymentの更新 {#updating-a-deployment}
+## Deploymentの更新

 {{< note >}}
 Deploymentのロールアウトは、DeploymentのPodテンプレート(この場合`.spec.template`)が変更された場合にのみトリガーされます。例えばテンプレートのラベルもしくはコンテナーイメージが更新された場合です。Deploymentのスケールのような更新では、ロールアウトはトリガーされません。
@@ -590,11 +589,13 @@ Deploymentのローリングアップデートは、同時に複数のバージ
  ```

 * クラスター内で、解決できない新しいイメージに更新します。
+* You update to a new image which happens to be unresolvable from inside the cluster.
    ```shell
    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
    ```

    実行結果は以下のとおりです。
+    The output is similar to this:
    ```
    deployment.apps/nginx-deployment image updated
    ```
@@ -603,8 +604,7 @@ Deploymentのローリングアップデートは、同時に複数のバージ
    ```shell
    kubectl get rs
    ```
-
-    実行結果は以下のとおりです。
+      実行結果は以下のとおりです。
    ```
    NAME                          DESIRED   CURRENT   READY     AGE
    nginx-deployment-1989198191   5         5         0         9s
@@ -615,26 +615,24 @@ Deploymentのローリングアップデートは、同時に複数のバージ

 上記の例では、3つのレプリカが古いReplicaSetに追加され、2つのレプリカが新しいReplicaSetに追加されました。ロールアウトの処理では、新しいレプリカ数のPodが正常になったと仮定すると、最終的に新しいReplicaSetに全てのレプリカを移動させます。これを確認するためには以下のコマンドを実行して下さい。

-```shell
-kubectl get deploy
-```
-
-実行結果は以下のとおりです。
-```
-NAME                 DESIRED   CURRENT   UP-TO-DATE  AVAILABLE   AGE
-nginx-deployment     15        18        7           8           7m
-```
-ロールアウトのステータスでレプリカがどのように各ReplicaSetに追加されるか確認できます。
-```shell
-kubectl get rs
-```
-
-実行結果は以下のとおりです。
-```
-NAME                          DESIRED   CURRENT  READY     AGE
-nginx-deployment-1989198191   7         7        0         7m
-nginx-deployment-618515232    11        11       11        7m
-```
+    ```shell
+    kubectl get deploy
+    ```
+    実行結果は以下のとおりです。
+    ```
+    NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+    nginx-deployment     15        18        7            8           7m
+    ```
+  　ロールアウトのステータスでレプリカがどのように各ReplicaSetに追加されるか確認できます。
+    ```shell
+    kubectl get rs
+    ```
+    実行結果は以下のとおりです。
+    ```
+    NAME                          DESIRED   CURRENT   READY     AGE
+    nginx-deployment-1989198191   7         7         0         7m
+    nginx-deployment-618515232    11        11        11        7m
+    ```

 ## Deployment更新の一時停止と再開 {#pausing-and-resuming-a-deployment}

@@ -754,7 +752,7 @@ nginx-deployment-618515232    11        11       11        7m
    nginx-3926361531   3         3         3         28s
    ```
 {{< note >}}
-Deploymentの稼働を再開させない限り、一時停止したDeploymentをロールバックすることはできません。
+一時停止したDeploymentの稼働を再開させない限り、Deploymentをロールバックすることはできません。
 {{< /note >}}

 ## Deploymentのステータス {#deployment-status}
@@ -939,13 +937,13 @@ Deploymentが管理する古いReplicaSetをいくつ保持するかを指定す

 ## カナリアパターンによるデプロイ

-Deploymentを使って一部のユーザーやサーバーに対してリリースのロールアウトをしたい場合、[リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/#canary-deployments-カナリアデプロイ)に記載されているカナリアパターンに従って、リリース毎に1つずつ、複数のDeploymentを作成できます。
+Deploymentを使って一部のユーザーやサーバーに対してリリースのロールアウトをしたい場合、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)に記載されているカナリアパターンに従って、リリース毎に1つずつ、複数のDeploymentを作成できます。

 ## Deployment Specの記述

 他の全てのKubernetesの設定と同様に、Deploymentは`.apiVersion`、`.kind`や`.metadata`フィールドを必要とします。
-設定ファイルの利用に関する情報は[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。コンテナーの設定に関しては[リソースを管理するためのkubectlの使用](/ja/docs/concepts/overview/working-with-objects/object-management/)を参照してください。
-Deploymentオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
+設定ファイルの利用に関する情報は[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。コンテナーの設定に関しては[リソースを管理するためのkubectlの使用](/docs/concepts/overview/working-with-objects/object-management/)を参照してください。
+Deploymentオブジェクトの名前は、有効な[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。
 Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要とします。

 ### Podテンプレート
@@ -994,25 +992,25 @@ Deploymentのセレクターに一致するラベルを持つPodを直接作成

 `.spec.strategy.type==RollingUpdate`と指定されているとき、DeploymentはローリングアップデートによりPodを更新します。ローリングアップデートの処理をコントロールするために`maxUnavailable`と`maxSurge`を指定できます。

-##### Max Unavailable {#max-unavailable}
+##### maxUnavailable

 `.spec.strategy.rollingUpdate.maxUnavailable`はオプションのフィールドで、更新処理において利用不可となる最大のPod数を指定します。値は絶対値(例: 5)を指定するか、理想状態のPodのパーセンテージを指定します(例: 10%)。パーセンテージを指定した場合、絶対値は小数切り捨てされて計算されます。`.spec.strategy.rollingUpdate.maxSurge`が0に指定されている場合、この値を0にできません。デフォルトでは25%です。

 例えば、この値が30%と指定されているとき、ローリングアップデートが開始すると古いReplicaSetはすぐに理想状態の70%にスケールダウンされます。一度新しいPodが稼働できる状態になると、古いReplicaSetはさらにスケールダウンされ、続いて新しいReplicaSetがスケールアップされます。この間、利用可能なPodの総数は理想状態のPodの少なくとも70%以上になるように保証されます。

-##### Max Surge {#max-surge}
+##### maxSurge

 `.spec.strategy.rollingUpdate.maxSurge`はオプションのフィールドで、理想状態のPod数を超えて作成できる最大のPod数を指定します。値は絶対値(例: 5)を指定するか、理想状態のPodのパーセンテージを指定します(例: 10%)。パーセンテージを指定した場合、絶対値は小数切り上げで計算されます。`MaxUnavailable`が0に指定されている場合、この値を0にできません。デフォルトでは25%です。

 例えば、この値が30%と指定されているとき、ローリングアップデートが開始すると新しいReplicaSetはすぐに更新されます。このとき古いPodと新しいPodの総数は理想状態の130%を超えないように更新されます。一度古いPodが削除されると、新しいReplicaSetはさらにスケールアップされます。この間、利用可能なPodの総数は理想状態のPodに対して最大130%になるように保証されます。

-### Progress Deadline Seconds
+### progressDeadlineSeconds

 `.spec.progressDeadlineSeconds`はオプションのフィールドで、システムがDeploymentの[更新に失敗](#failed-deployment)したと判断するまでに待つ秒数を指定します。更新に失敗したと判断されたとき、リソースのステータスは`Type=Progressing`、`Status=False`かつ`Reason=ProgressDeadlineExceeded`となるのを確認できます。DeploymentコントローラーはDeploymentの更新のリトライし続けます。デフォルト値は600です。今後、自動的なロールバックが実装されたとき、更新失敗状態になるとすぐにDeploymentコントローラーがロールバックを行うようになります。

 この値が指定されているとき、`.spec.minReadySeconds`より大きい値を指定する必要があります。

-### Min Ready Seconds {#min-ready-seconds}
+### minReadySeconds {#min-ready-seconds}

 `.spec.minReadySeconds`はオプションのフィールドで、新しく作成されたPodが利用可能となるために、最低どれくらいの秒数コンテナーがクラッシュすることなく稼働し続ければよいかを指定するものです。デフォルトでは0です(Podは作成されるとすぐに利用可能と判断されます)。Podが利用可能と判断された場合についてさらに学ぶために[Container Probes](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照してください。

@@ -1022,7 +1020,7 @@ Deploymentのリビジョン履歴は、Deploymentが管理するReplicaSetに

 `.spec.revisionHistoryLimit`はオプションのフィールドで、ロールバック可能な古いReplicaSetの数を指定します。この古いReplicaSetは`etcd`内のリソースを消費し、`kubectl get rs`の出力結果を見にくくします。Deploymentの各リビジョンの設定はReplicaSetに保持されます。このため一度古いReplicaSetが削除されると、そのリビジョンのDeploymentにロールバックすることができなくなります。デフォルトでは10もの古いReplicaSetが保持されます。しかし、この値の最適値は新しいDeploymentの更新頻度と安定性に依存します。

-さらに詳しく言うと、この値を0にすると、0のレプリカを持つ古い全てのReplicaSetが削除されます。このケースでは、リビジョン履歴が完全に削除されているため新しいDeploymentのロールアウトを元に戻すことができません。
+さらに詳しく言うと、この値を0にすると、0のレプリカを持つ古い全てのReplicaSetが削除されます。このケースでは、リビジョン履歴が完全に削除されているため新しいDeploymentのロールアウトを完了することができません。

 ### paused

@@ -1,11 +1,28 @@
 ---
-title: 利用可能なドキュメントバージョン
-content_type: custom
-layout: supported-versions 
+title: Kubernetesドキュメントがサポートしているバージョン
+content_type: concept
 card:
  name: about
  weight: 10
-  title: 利用可能なドキュメントバージョン
+  title: ドキュメントがサポートしているバージョン
 ---

+<!-- overview -->
+
 本ウェブサイトには、現行版とその直前4バージョンのKubernetesドキュメントがあります。
+
+
+
+<!-- body -->
+
+## 現行版
+
+現在のバージョンは[{{< param "version" >}}](/)です。
+
+## 以前のバージョン
+
+{{< versions-other >}}
+
+
+
+
@@ -1,83 +0,0 @@
---
-title: Kubelet 認証/認可
---
-
-
-## 概要
-
-kubeletのHTTPSエンドポイントは、さまざまな感度のデータへのアクセスを提供するAPIを公開し、
-ノードとコンテナ内のさまざまなレベルの権限でタスクを実行できるようにします。
-
-このドキュメントでは、kubeletのHTTPSエンドポイントへのアクセスを認証および承認する方法について説明します。
-
-## Kubelet 認証
-
-デフォルトでは、他の構成済み認証方法によって拒否されないkubeletのHTTPSエンドポイントへのリクエストは
-匿名リクエストとして扱われ、ユーザー名は`system:anonymous`、
-グループは`system:unauthenticated`になります。
-
-匿名アクセスを無効にし、認証されていないリクエストに対して`401 Unauthorized`応答を送信するには：
-
-* `--anonymous-auth=false`フラグでkubeletを開始します。
-
-kubeletのHTTPSエンドポイントに対するX509クライアント証明書認証を有効にするには：
-
-* `--client-ca-file`フラグでkubeletを起動し、クライアント証明書を確認するためのCAバンドルを提供します。
-* `--kubelet-client-certificate`および`--kubelet-client-key`フラグを使用してapiserverを起動します。
-* 詳細については、[apiserver認証ドキュメント](/ja/docs/reference/access-authn-authz/authentication/#x509-client-certs)を参照してください。
-
-APIベアラートークン(サービスアカウントトークンを含む)を使用して、kubeletのHTTPSエンドポイントへの認証を行うには：
-
-* APIサーバーで`authentication.k8s.io/v1beta1`グループが有効になっていることを確認します。
-* `--authentication-token-webhook`および`--kubeconfig`フラグを使用してkubeletを開始します。
-* kubeletは、構成済みのAPIサーバーで `TokenReview` APIを呼び出して、ベアラートークンからユーザー情報を判別します。
-
-## Kubelet 承認
-
-認証に成功した要求(匿名要求を含む)はすべて許可されます。デフォルトの認可モードは、すべての要求を許可する`AlwaysAllow`です。
-
-kubelet APIへのアクセスを細分化するのは、次のような多くの理由が考えられます:
-
-* 匿名認証は有効になっていますが、匿名ユーザーがkubeletのAPIを呼び出す機能は制限する必要があります。
-* ベアラートークン認証は有効になっていますが、kubeletのAPIを呼び出す任意のAPIユーザー(サービスアカウントなど)の機能を制限する必要があります。
-* クライアント証明書の認証は有効になっていますが、構成されたCAによって署名されたクライアント証明書の一部のみがkubeletのAPIの使用を許可されている必要があります。
-
-kubeletのAPIへのアクセスを細分化するには、APIサーバーに承認を委任します:
-
-* APIサーバーで`authorization.k8s.io/v1beta1` APIグループが有効になっていることを確認します。
-* `--authorization-mode=Webhook`と`--kubeconfig`フラグでkubeletを開始します。
-* kubeletは、構成されたAPIサーバーで`SubjectAccessReview` APIを呼び出して、各リクエストが承認されているかどうかを判断します。
-
-kubeletは、apiserverと同じ[リクエスト属性](/docs/reference/access-authn-authz/authorization/#review-your-request-attributes)アプローチを使用してAPIリクエストを承認します。
-
-動詞は、受けとったリクエストのHTTP動詞から決定されます:
-
-HTTP動詞 | 要求 動詞
----------|---------------
-POST      | create
-GET, HEAD | get
-PUT       | update
-PATCH     | patch
-DELETE    | delete
-
-リソースとサブリソースは、受けとったリクエストのパスから決定されます:
-
-Kubelet API  | リソース | サブリソース
-------------|----------|------------
-/stats/\*     | nodes    | stats
-/metrics/\*   | nodes    | metrics
-/logs/\*      | nodes    | log
-/spec/\*      | nodes    | spec
-*all others* | nodes    | proxy
-
-名前空間とAPIグループの属性は常に空の文字列であり、
-リソース名は常にkubeletの`Node` APIオブジェクトの名前です。
-
-このモードで実行する場合は、apiserverに渡される`--kubelet-client-certificate`フラグと`--kubelet-client-key`
-フラグで識別されるユーザーが次の属性に対して許可されていることを確認します:
-
-* verb=\*, resource=nodes, subresource=proxy
-* verb=\*, resource=nodes, subresource=stats
-* verb=\*, resource=nodes, subresource=log
-* verb=\*, resource=nodes, subresource=spec
-* verb=\*, resource=nodes, subresource=metrics
@@ -2,7 +2,7 @@
 title: APIサーバー
 id: kube-apiserver
 date: 2018-04-12
-full_link: /docs/concepts/overview/components/#kube-apiserver
+full_link: /docs/reference/generated/kube-apiserver/
 short_description: >
  Kubernetes APIを提供するコントロールプレーンのコンポーネントです。

@@ -8,10 +8,16 @@ card:

 <!-- overview -->

-このページには、一般的によく使われる`kubectl`コマンドとフラグのリストが含まれています。
+[Kubectl概要](/ja/docs/reference/kubectl/overview/)と[JsonPathガイド](/docs/reference/kubectl/jsonpath)も合わせてご覧ください。
+
+このページは`kubectl`コマンドの概要です。
+
+

 <!-- body -->

+# kubectl - チートシート
+
 ## Kubectlコマンドの補完

 ### BASH
@@ -70,7 +76,7 @@ kubectl config set-context gce --user=cluster-admin --namespace=foo \
 kubectl config unset users.foo    # ユーザーfooを削除します
 ```

-## Kubectl Apply
+## Apply

 `apply`はKubernetesリソースを定義するファイルを通じてアプリケーションを管理します。`kubectl apply`を実行して、クラスター内のリソースを作成および更新します。これは、本番環境でKubernetesアプリケーションを管理する推奨方法です。
 詳しくは[Kubectl Book](https://kubectl.docs.kubernetes.io)をご覧ください。
@@ -208,6 +214,10 @@ kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'

 ## リソースのアップデート

+<<<<<<< HEAD
+=======
+
+>>>>>>> 8d357bf1e (finished translating cheartsheet.md)
 ```bash
 kubectl set image deployment/frontend www=image:v2               # frontend Deploymentのwwwコンテナイメージをv2にローリングアップデートします
 kubectl rollout history deployment/frontend                      # frontend Deploymentの改訂履歴を確認します
@@ -366,7 +376,6 @@ kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.
 kubectl get pods -A -o=custom-columns='DATA:metadata.*'
 ```

-kubectlに関するより多くのサンプルは[カスタムカラムのリファレンス](/ja/docs/reference/kubectl/overview/#custom-columns)を参照してください。

 ### Kubectlのログレベルとデバッグ
 kubectlのログレベルは、レベルを表す整数が後に続く`-v`または`--v`フラグで制御されます。一般的なKubernetesのログ記録規則と関連するログレベルについて、[こちら](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)で説明します。
@@ -387,10 +396,11 @@ kubectlのログレベルは、レベルを表す整数が後に続く`-v`また

 ## {{% heading "whatsnext" %}}

-* kubectlについてより深く学びたい方は[kubectl概要](/ja/docs/reference/kubectl/overview/)や[JsonPath](/docs/reference/kubectl/jsonpath)をご覧ください。
+
+* kubectlについてより深く学びたい方は[kubectl概要](/ja/docs/reference/kubectl/overview/)をご覧ください。

 * オプションについては[kubectl](/docs/reference/kubectl/kubectl/) optionsをご覧ください。
- 
+
 * また[kubectlの利用パターン](/docs/reference/kubectl/conventions/)では再利用可能なスクリプトでkubectlを利用する方法を学べます。

 * コミュニティ版[kubectlチートシート](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)もご覧ください。
@@ -6,14 +6,15 @@ content_type: concept

 <!-- overview -->

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


 <!-- body -->

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

-Kubernetes 1.2より、複数のゾーンにおいて単一のクラスターを運用するサポートが追加されました(GCEでは単純に"ゾーン"、AWSは"アベイラビリティゾーン"と呼びますが、ここでは"ゾーン"とします)。
+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"の愛称で使用されていました)ではこれが可能になります。

@@ -24,7 +25,7 @@ Kubernetes 1.2より、複数のゾーンにおいて単一のクラスターを

 ノードが開始された時、kubeletは自動的にそれらにゾーン情報を付したラベルを追加します。

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

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

@@ -76,7 +77,7 @@ curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZO
 ### ノードはラベルが付与される

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


 ```shell
@@ -87,10 +88,10 @@ kubectl get nodes --show-labels

 ```shell
 NAME                     STATUS                     ROLES    AGE   VERSION          LABELS
-kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
-kubernetes-minion-87j9   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
-kubernetes-minion-9vlv   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
+kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-1,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
+kubernetes-minion-87j9   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
+kubernetes-minion-9vlv   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
 ```

 ### 2つ目のゾーンにさらにノードを追加
@@ -122,13 +123,13 @@ kubectl get nodes --show-labels

 ```shell
 NAME                     STATUS                     ROLES    AGE   VERSION           LABELS
-kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
-kubernetes-minion-281d   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
-kubernetes-minion-87j9   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
-kubernetes-minion-9vlv   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-a12q   Ready                      <none>   17m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
-kubernetes-minion-pp2f   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
-kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
+kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-1,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
+kubernetes-minion-281d   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
+kubernetes-minion-87j9   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
+kubernetes-minion-9vlv   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-a12q   Ready                      <none>   17m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
+kubernetes-minion-pp2f   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
+kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
 ```

 ### ボリュームのアフィニティ
@@ -178,7 +179,7 @@ kubectl get pv --show-labels

 ```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
+pv-gce-mj4gm   5Gi        RWO           Retain           Bound     default/claim1   manual                    46s       topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a
 ```

 では永続ボリュームクレームを使用するPodを作成します。
@@ -222,7 +223,7 @@ kubectl get node kubernetes-minion-9vlv --show-labels

 ```shell
 NAME                     STATUS    AGE    VERSION          LABELS
-kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
 ```

 ### Podがゾーンをまたがって配置される
@@ -271,9 +272,9 @@ kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion

 ```shell
 NAME                     STATUS    ROLES    AGE    VERSION          LABELS
-kubernetes-minion-9vlv   Ready     <none>   34m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-281d   Ready     <none>   20m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
-kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
+kubernetes-minion-9vlv   Ready     <none>   34m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-281d   Ready     <none>   20m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
+kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
 ```


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

 ## インストール

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

 ## クイックスタート

@@ -130,7 +130,7 @@ yum install -y yum-utils device-mapper-persistent-data lvm2
 ```

 ```shell
-## Dockerリポジトリの追加
+### Dockerリポジトリの追加
 yum-config-manager --add-repo \
  https://download.docker.com/linux/centos/docker-ce.repo
 ```
@@ -215,107 +215,73 @@ sysctl --system
 {{< tabs name="tab-cri-cri-o-installation" >}}
 {{% tab name="Debian" %}}

- CRI-Oを以下のOSにインストールするには、環境変数$OSを以下の表の適切なフィールドに設定します。
-
-| Operating system | $OS               |
-| ---------------- | ----------------- |
-| Debian Unstable  | `Debian_Unstable` |
-| Debian Testing   | `Debian_Testing`  |
-
-<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
+# 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 %}}
-
-{{% tab name="Ubuntu" %}}
-
- 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
+# 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 -
+```
+```shell
+# 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 -
+```

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

-apt-get update
-apt-get install cri-o cri-o-runc
+それでは、CRI-Oをインストールします:
+```shell
+sudo apt-get install cri-o-1.17
 ```
 {{% /tab %}}

-{{% tab name="CentOS" %}}
+{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}}

- 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
+# パッケージレポジトリを設定する
+. /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
 ```

+```shell
+# CRI-Oのインストール
+sudo apt-get install cri-o-1.17
+```
+{{% /tab %}}
+
+{{% tab name="CentOS/RHEL 7.4+" %}}
+
+```shell
+# 必要なパッケージのインストール
+curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo
+curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo
+```
+
+```shell
+# CRI-Oのインストール
+yum install -y cri-o
+```
 {{% /tab %}}

 {{% tab name="openSUSE Tumbleweed" %}}

 ```shell
- sudo zypper install cri-o
+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
@@ -355,7 +321,7 @@ sysctl --system
 ### containerdのインストール

 {{< tabs name="tab-cri-containerd-installation" >}}
-{{% tab name="Ubuntu 16.04" %}}
+{{< tab name="Ubuntu 16.04" codelang="bash" >}}

 ```shell
 # (containerdのインストール)
@@ -369,7 +335,7 @@ apt-get update && apt-get install -y apt-transport-https ca-certificates curl so
 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
 ```

-```shell
+```
 ## Dockerのaptリポジトリの追加
 add-apt-repository \
    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
@@ -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](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.
+[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.

 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. The IAM user will need [adequate permissions](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user).
+* 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.



@@ -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](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
+the [normal process](http://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/reference/kubectl/overview/).
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/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">ベストプラクティスに準拠した実用最小限の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">`kubeadm`ツールは、ベストプラクティスに準拠した実用最小限の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クラスターをインストールする
+* シングルコントロールプレーンのKubernetesクラスターまたは[高可用性クラスター](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)をインストールする
 * クラスター上にPodネットワークをインストールして、Podがお互いに通信できるようにする

 ## 手順
@@ -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,14 +203,9 @@ export KUBECONFIG=/etc/kubernetes/admin.conf

 {{< /caution >}}

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

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

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

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

-インストールできるPodネットワークは、クラスターごとに1つだけです。
+インストールできる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ネットワークがインストールされたら、`kubectl get pods --all-namespaces`の出力結果でCoreDNS Podが`Running`状態であることをチェックすることで、ネットワークが動作していることを確認できます。そして、一度CoreDNS Podが動作すれば、続けてノードを追加できます。

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

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

 出力は次のようになります。
@@ -328,7 +407,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へプロキシする
@@ -354,9 +433,10 @@ 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
@@ -374,11 +454,6 @@ IPVS tablesをリセットしたい場合は、次のコマンドを実行する
 ipvsadm -C
 ```

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

 ### コントロールプレーンのクリーンアップ
@@ -394,7 +469,7 @@ kubectl delete node <node name>
 * [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`](/ja/docs/reference/kubectl/overview/)についてもっと学ぶ。
+* Kubernetesの[コンセプト](/ja/docs/concepts/)や[`kubectl`](/docs/user-guide/kubectl-overview/)についてもっと学ぶ。
 * Podネットワークアドオンのより完全なリストを[クラスターのネットワーク](/docs/concepts/cluster-administration/networking/)で確認する。
 * <a id="other-addons" />ロギング、モニタリング、ネットワークポリシー、仮想化、Kubernetesクラスターの制御のためのツールなど、その他のアドオンについて、[アドオンのリスト](/docs/concepts/cluster-administration/addons/)で確認する。
 * クラスターイベントやPod内で実行中のアプリケーションから送られるログをクラスターがハンドリングする方法を設定する。関係する要素の概要を理解するために、[ロギングのアーキテクチャ](/docs/concepts/cluster-administration/logging/)を読んでください。
@@ -411,9 +486,9 @@ kubectl delete node <node name>

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

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

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

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

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

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

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

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

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

 kubeadmに関する問題が起きたときは、[トラブルシューティングドキュメント](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)を確認してください。
+
@@ -15,10 +15,7 @@ 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,9 +57,9 @@ weight: 60

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

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

-    - 詳細は[Options for Software Load Balancing](https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing)をご覧ください。
+    - ロードバランサーのアドレスは、常にkubeadmの`ControlPlaneEndpoint`のアドレスと一致することを確認してください。

 1.  ロードバランサーに、最初のコントロールプレーンノードを追加し、接続をテストする:

@@ -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 >}}いくつかの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 >}}
+    {{< 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 >}}

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

@@ -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/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))を拡張します。
+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))を拡張します。

 ```none
 [Service]
@@ -134,5 +134,6 @@ 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,48 +1,68 @@
 ---
-title: コントロールプレーンをセルフホストするようにkubernetesクラスターを構成する
+title: Configuring your kubernetes cluster to self-host the control plane
 content_type: concept
 weight: 100
 ---

 <!-- overview -->

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

-kubeadmを使用すると、セルフホスト型のKubernetesコントロールプレーンを実験的に作成できます。これはAPIサーバー、コントローラーマネージャー、スケジューラーなどの主要コンポーネントは、静的ファイルを介してkubeletで構成された[static pods](/docs/tasks/configure-pod-container/static-pod/)ではなく、Kubernetes APIを介して構成された[DaemonSet pods](/ja/docs/concepts/workloads/controllers/daemonset/)として実行されることを意味します。
+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 alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting)を参照してください。
+To create a self-hosted cluster see the
+[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.



 <!-- body -->

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

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

-1. 1.8以降のセルフホスティングには、いくつかの重要な制限があります。特に、セルフホスト型クラスターは、手動の介入なしにコントロールプレーンのNode再起動から回復することはできません。
+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. デフォルトでは、セルフホスト型のコントロールプレーンのPodは、[`hostPath`](/docs/concepts/storage/volumes/#hostpath)ボリュームからロードされた資格情報に依存しています。最初の作成を除いて、これらの資格情報はkubeadmによって管理されません。
+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. コントロールプレーンのセルフホストされた部分にはetcdが含まれていませんが、etcdは静的Podとして実行されます。
+1. The self-hosted portion of the control plane does not include etcd,
+  which still runs as a static Pod.

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

-セルフホスティングのブートストラッププロセスは、[kubeadm design
-document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting)に記載されています。
+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 alpha selfhosting`は次のように機能します。
+In summary, `kubeadm alpha selfhosting` works as follows:

-  1. 静的コントロールプレーンのブートストラップが起動し、正常になるのを待ちます。これは`kubeadm init`のセルフホスティングを使用しないプロセスと同じです。
+  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. 静的コントロールプレーンのPodのマニフェストを使用して、セルフホスト型コントロールプレーンを実行する一連のDaemonSetのマニフェストを構築します。また、必要に応じてこれらのマニフェストを変更します。たとえば、シークレット用の新しいボリュームを追加します。
+  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. `kube-system`のネームスペースにDaemonSetを作成し、Podの結果が起動されるのを待ちます。
+  1. Creates DaemonSets in the `kube-system` namespace and waits for the
+     resulting Pods to be running.

-  1. セルフホスト型のPodが操作可能になると、関連する静的Podが削除され、kubeadmは次のコンポーネントのインストールに進みます。これによりkubeletがトリガーされて静的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. 元の静的なコントロールプレーンが停止すると、新しいセルフホスト型コントロールプレーンはリスニングポートにバインドしてアクティブになります。
+  1. When the original static control plane stops, the new self-hosted control
+    plane is able to bind to listening ports and become active.


@@ -29,8 +29,7 @@ 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](/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.
+* Each host must [have docker, kubelet, and kubeadm installed][toolbox].
 * Some infrastructure to copy files between hosts. For example `ssh` and `scp`
  can satisfy this requirement.

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

 <!-- overview -->

-どのプログラムでもそうですが、kubeadmのインストールや実行でエラーが発生することがあります。このページでは、一般的な失敗例をいくつか挙げ、問題を理解して解決するための手順を示しています。
+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.

-本ページに問題が記載されていない場合は、以下の手順を行ってください:
+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`もしくは他の似たような実行プログラムが見つからない

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

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

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

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

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

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

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

- ネットワーク接続の問題が挙げられます。続行する前に、お使いのマシンがネットワークに完全に接続されていることを確認してください。
- kubeletのデフォルトのcgroupドライバの設定がDockerで使用されているものとは異なっている場合も考えられます。
-  システムログファイル(例: `/var/log/message`)をチェックするか、`journalctl -u kubelet`の出力を調べてください:
+- 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:

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

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

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

- 1. Dockerのcgroupドライバに合わせてkubeletの設定を手動で変更します。その際は、[マスターノード上でkubeletが使用するcgroupドライバを設定する](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)を参照してください。
+ 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)

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

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

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

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

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

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

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

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

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

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

- `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`ファイルを見つけられない場合に発生します。
+- 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.

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

-kubeadmはネットワークプロバイダに依存しないため、管理者は選択した[Podネットワークソリューションをインストール](/docs/concepts/cluster-administration/addons/)をする必要があります。CoreDNSを完全にデプロイする前にPodネットワークをインストールする必要があります。したがって、ネットワークがセットアップされる前の `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.

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

-`HostPort`と`HostIP`の機能は、ご使用のPodネットワークプロバイダによって利用可能です。Podネットワークソリューションの作者に連絡して、`HostPort`と`HostIP`機能が利用可能かどうかを確認してください。
+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.

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

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

-ネットワークプロバイダが portmap CNI プラグインをサポートしていない場合は、[NodePortサービス](/ja/docs/concepts/services-networking/service/#nodeport)を使用するか、`HostNetwork=true`を使用してください。
+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`.

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

- 多くのネットワークアドオンは、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)に関連する問題です。ヘアピンモードのサポート状況については、ネットワークアドオンプロバイダにお問い合わせください。
+- 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.

- VirtualBoxを使用している場合(直接またはVagrant経由)は、`hostname -i`がルーティング可能なIPアドレスを返すことを確認する必要があります。デフォルトでは、最初のインターフェースはルーティング可能でないホスト専用のネットワークに接続されています。これを回避するには`/etc/hosts`を修正する必要があります。例としてはこの[Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)を参照してください。
+- 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.

 ## 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")
 ```

- `HOME/.kube/config`ファイルに有効な証明書が含まれていることを確認し、必要に応じて証明書を再生成します。kubeconfigファイル内の証明書はbase64でエンコードされています。証明書をデコードするには`base64 --decode`コマンドを、証明書情報を表示するには`openssl x509 -text -noout`コマンドを用いてください。
- 環境変数`KUBECONFIG`の設定を解除するには以下のコマンドを実行するか:
+- 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:

  ```sh
  unset KUBECONFIG
  ```

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

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

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

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

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

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

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

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

-  Vagrantは通常、2つのインターフェースを全てのVMに割り当てます。1つ目は全てのホストにIPアドレス`10.0.2.15`が割り当てられており、NATされる外部トラフィックのためのものです。
+  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.

-  これは、ホストの最初のインターフェイスをデフォルトにしているflannelの問題につながるかもしれません。これは、すべてのホストが同じパブリックIPアドレスを持っていると考えます。これを防ぐには、2番目のインターフェイスが選択されるように `--iface eth1`フラグをflannelに渡してください。
+  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.

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

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

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

- これには、おそらくマシンプロバイダのポリシーによって、一見同じサブネット上の他のIPと通信できないIPをKubernetesが使用している可能性があります。
- DigitalOceanはパブリックIPとプライベートIPを`eth0`に割り当てていますが、`kubelet`はパブリックIPではなく、ノードの`InternalIP`として後者を選択します。
+- 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.

-  `ifconfig`ではエイリアスIPアドレスが表示されないため、`ifconfig`の代わりに`ip addr show`を使用してこのシナリオをチェックしてください。あるいは、DigitalOcean専用のAPIエンドポイントを使用して、ドロップレットからアンカーIPを取得することもできます:
+  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:

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

-  回避策としては、`--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) が利用できます。
+  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.

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

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

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

-SELinuxを実行しているノードで古いバージョンのDockerを使用している場合、`coredns` Podが起動しないということが起きるかもしれません。この問題を解決するには、以下のオプションのいずれかを試してみてください:
+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:

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

- [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`に設定:
+- [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`:

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

-CoreDNSに`CrashLoopBackOff`が発生する別の原因は、KubernetesにデプロイされたCoreDNS Podがループを検出したときに発生します。CoreDNSがループを検出して終了するたびに、KubernetesがCoreDNS Podを再起動しようとするのを避けるために、[いくつかの回避策](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)が用意されています。
+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.

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

-この問題は、CentOS 7をDocker 1.13.1.84で実行した場合に表示されます。このバージョンのDockerでは、kubeletがetcdコンテナに実行されないようにすることができます。
+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.

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

- 1.13.1-75のような以前のバージョンのDockerにロールバックする
+- Roll back to an earlier version of Docker, such as 1.13.1-75
 ```
 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
 ```

- 18.06のような最新の推奨バージョンをインストールする:
+- Install one of the more recent recommended versions, such as 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
 ```

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

-`-component-extra-args`のような`kubeadm init`フラグを使うと、kube-apiserverのようなコントロールプレーンコンポーネントにカスタム引数を渡すことができます。しかし、このメカニズムは値の解析に使われる基本的な型 (`mapStringString`) のために制限されています。
+`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`).

-もし、`--apiserver-extra-args "enable-admission plugins=LimitRanger,NamespaceExists"`のようにカンマで区切られた複数の値をサポートする引数を渡した場合、このフラグは`flag: malformed pair, expect string=string`で失敗します。これは`--apiserver-extra-args`の引数リストが`key=value`のペアを期待しており、この場合`NamespacesExists`は値を欠いたキーとみなされるためです。
+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.

-別の方法として、`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)を使用することが挙げられます。
+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`.

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

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

-kube-proxy Podsでは以下のようなエラーが発生します:
+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:
 ```
 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
 ```

-既知の解決策は、初期のガード条件が緩和されるまで他のノードから離しておき、条件に関係なくコントロールプレーンノード上でスケジューリングできるように、キューブプロキシDaemonSetにパッチを当てることです:
-
+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:
 ```
 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" } ] } } } }'
 ```

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

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

-*注意: この[Issue](https://github.com/kubernetes/kubeadm/issues/1358)は、kubeadmタイプをマーシャルするツール(YAML設定ファイルなど)にのみ適用されます。これはkubeadm API v1beta2で修正される予定です。*
+*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.*

-デフォルトでは、kubeadmはコントロールプレーンノードに`node-role.kubernetes.io/master:NoSchedule`のテイントを適用します。kubeadmがコントロールプレーンノードに影響を与えないようにし、`InitConfiguration.NodeRegistration.Taints`を空のスライスに設定すると、マーシャリング時にこのフィールドは省略されます。フィールドが省略された場合、kubeadmはデフォルトのテイントを適用します。
+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.

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

-1. 空のスライスの代わりに`node-role.kubernetes.io/master:PreferNoSchedule`テイントを使用します。他のノードに容量がない限り、[Podsはマスター上でスケジュールされます](/docs/concepts/scheduling-eviction/taint-and-toleration/)。
+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.

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

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

-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ディレクトリは _書き込み可能_ な状態でなければなりません。
+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.

-この問題を回避するには、kubeadm[設定ファイル](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)を使用して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 init`で作成されたもの）上で、`--config`で以下のファイルを渡します:
+On the primary control-plane Node (created using `kubeadm init`) pass the following
+file using `--config`:

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

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

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

-あるいは、`/usr`マウントを書き込み可能にするために `/etc/fstab`を変更することもできますが、これはLinuxディストリビューションの設計原理を変更していることに注意してください。
-
-## `kubeadm upgrade plan`が`context deadline exceeded`エラーメッセージを表示する
-このエラーメッセージは、外部etcdを実行している場合に`kubeadm`でKubernetesクラスタをアップグレードする際に表示されます。これは致命的なバグではなく、古いバージョンのkubeadmが外部etcdクラスタのバージョンチェックを行うために発生します。`kubeadm upgrade apply ...`で進めることができます。
-
-この問題はバージョン1.19で修正されます。
+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.
@@ -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](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:
+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:

 * a highly available cluster
 * composable attributes
@@ -21,8 +21,7 @@ Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [i
  * 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/reference/setup-tools/kubeadm/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/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/).



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

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

-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)".
+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)".

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

@@ -69,7 +68,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](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.
+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.

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

@@ -111,7 +110,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](https://slack.k8s.io/))
+* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/))
 * [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)


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

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

-* [kube-aws](https://github.com/kubernetes-incubator/kube-aws) EC2、CloudFormation、Auto Scalingを使用して、[Flatcar Linux](https://www.flatcar-linux.org/)ノードでKubernetesクラスターを作成および管理します。
+* [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クラスターを作成および管理できます。

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

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

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

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

 ### 例

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

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

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

 ## クラスターの解体

@@ -75,8 +77,12 @@ 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     | -  |          | Community
-AWS                  | Juju         | Ubuntu        | flannel, calico, canal     | - | 100%     | Commercial, Community
+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                  | KubeOne         | Ubuntu, CoreOS, CentOS   | canal, weavenet     | [docs](https://github.com/kubermatic/kubeone)      | 100%    | Commercial, Community

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

@@ -0,0 +1,340 @@
+---
+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 `#gke` Slack channel.
+[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting/#slack).

 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/reference/kubectl/kubectl/) tool controls the Kubernetes cluster
+The [kubectl](/docs/user-guide/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
-The [kubectl](/ja/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster
+downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/kubectl/install/)
 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/concepts/services-networking/service/) that look something like this:
+should show a set of [services](/docs/user-guide/services) 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](/ja/docs/concepts/workloads/pods/) that were created during cluster startup.
+Similarly, you can take a look at the set of [pods](/docs/user-guide/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](/ja/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster.
+Then, see [a simple nginx example](/docs/user-guide/simple-nginx) 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,3 +215,10 @@ 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,9 +25,13 @@ 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) using Terraform.
+You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) by using either AWS CloudFormation or Terraform.

-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).
+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).

 ## Azure上でのIBM Cloud Private

@@ -60,4 +64,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/vmwaresolutions?topic=vmwaresolutions-icp_overview).
+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).
@@ -14,7 +14,7 @@ Windowsアプリケーションは、多くの組織で実行されているサ

 ## KubernetesのWindowsコンテナ

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

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

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

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

-##### 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 >}}
-
+KubernetesのWindows Server 2019/1809ノードでは、Docker EE-basic 18.09が必要です。これは、kubeletに含まれているdockershimコードで動作します。CRI-ContainerDなどの追加のランタイムは、Kubernetesの以降のバージョンでサポートされる可能性があります。

 #### 永続ストレージ

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

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

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

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

+### CRI-ContainerD

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

 * 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つのコンテナに制限されています。

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

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

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

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

 ## 始める前に

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

 ## はじめに:Windowsコンテナのデプロイ
@@ -0,0 +1,306 @@
+---
+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/windows-testing/blob/master/images/pause/Dockerfile.
+    {{< /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,16 +12,14 @@ weight: 30

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

-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のバージョンは**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プロジェクトでは、最新の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)グループがこれを決定しています。
+Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています。

+セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら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ヶ月保守されます。

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

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

 例:

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

 ### kubelet

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

 例:

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

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

 例:

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

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

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

 例:

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

 {{< note >}}
 HAクラスター内の`kube-apiserver`間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかの`kube-apiserver`と通信する場合(たとえばロードバランサーを経由して)、コンポーネントの有効なバージョンは少なくなります。
@@ -67,8 +65,8 @@ HAクラスター内の`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`よりも新しくなるためサポートされません)
+* `kube-apiserver`インスタンスが**1.13**および**1.12**であるとします
+* いずれかの`kube-apiserver`インスタンスへ配信するロードバランサーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.12**がサポートされます(**1.13**はバージョン**1.12**の`kube-apiserver`よりも新しくなるためサポートされません)

 ### kubectl

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

 例:

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

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

 例:

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

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

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

 ### kube-apiserver

 前提条件:

-* シングルインスタンスのクラスターにおいて、既存の`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つ以内のマイナーバージョンとなります)
+* シングルインスタンスのクラスターにおいて、既存の`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つ以内のマイナーバージョンとなります)
 * 登録されたAdmission webhookは、新しい`kube-apiserver`インスタンスが送信するこれらのデータを扱うことができます:
-  * `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**{{< skew latestVersion >}}** で追加されたRESTリソースの新しいバージョンを含んで更新されます(または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください)
-  * Webhookは送信されたRESTリソースの新しいバージョン、および**{{< skew latestVersion >}}** のバージョンで追加された新しいフィールドを扱うことができます
+  * `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)** のバージョンで追加された新しいフィールドを扱うことができます

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

 {{< 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`のアップグレードの際にマイナーバージョンをスキップしてはなりません。
@@ -114,17 +112,17 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある

 前提条件:

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

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

 ### kubelet

 前提条件:

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

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

 {{< warning >}}
 `kube-apiserver`と2つのマイナーバージョンの`kubelet`インスタンスを使用してクラスターを実行させることは推奨されません:
@@ -132,18 +130,3 @@ 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 >}}**の間でなければなりません
@@ -17,7 +17,7 @@ Kubernetesのコマンドラインツール`kubectl`を使用すると、Kuberne

 [Minikube](https://minikube.sigs.k8s.io/)は、Kubernetesをローカルで実行するツールです。MinikubeはシングルノードのKubernetesクラスターをパーソナルコンピューター上(Windows、macOS、Linux PCを含む)で実行することで、Kubernetesを試したり、日常的な開発作業のために利用できます。

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

 Minikubeが起動したら、[サンプルアプリケーションの実行](/ja/docs/tutorials/hello-minikube/)を試すことができます。

@@ -502,7 +502,7 @@ compinit

 ## {{% heading "whatsnext" %}}

-* [Minikubeをインストールする](https://minikube.sigs.k8s.io/docs/start/)
+* [Minikubeをインストールする](/ja/docs/tasks/tools/install-minikube/)
 * クラスターの作成に関する詳細を[スタートガイド](/ja/docs/setup/)で確認する
 * [アプリケーションを起動して公開する方法を学ぶ](/ja/docs/tasks/access-application-cluster/service-access-application-cluster/)
 * あなたが作成していないクラスターにアクセスする必要がある場合は、[クラスターアクセスドキュメントの共有](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください
@@ -0,0 +1,267 @@
+---
+title: Minikubeのインストール
+content_type: task
+weight: 20
+card:
+  name: tasks
+  weight: 10
+---
+
+<!-- overview -->
+
+このページでは[Minikube](/ja/docs/tutorials/hello-minikube)のインストール方法を説明し、コンピューターの仮想マシン上で単一ノードのKubernetesクラスターを実行します。
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< tabs name="minikube_before_you_begin" >}}
+{{% tab name="Linux" %}}
+Linuxで仮想化がサポートされているかどうかを確認するには、次のコマンドを実行して、出力が空でないことを確認します:
+```
+grep -E --color 'vmx|svm' /proc/cpuinfo
+```
+{{% /tab %}}
+
+{{% tab name="macOS" %}}
+仮想化がmacOSでサポートされているかどうかを確認するには、ターミナルで次のコマンドを実行します。
+```
+sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
+```
+出力に`VMX`が表示されている場合(色付けされているはずです)、VT-x機能がマシンで有効になっています。
+{{% /tab %}}
+
+{{% tab name="Windows" %}}
+Windows 8以降で仮想化がサポートされているかどうかを確認するには、Windowsターミナルまたはコマンドプロンプトで次のコマンドを実行します。
+```
+systeminfo
+```
+次の出力が表示される場合、仮想化はWindowsでサポートされています。
+```
+Hyper-V Requirements:     VM Monitor Mode Extensions: Yes
+                          Virtualization Enabled In Firmware: Yes
+                          Second Level Address Translation: Yes
+                          Data Execution Prevention Available: Yes
+```
+
+次の出力が表示される場合、システムにはすでにHypervisorがインストールされており、次の手順をスキップできます。
+```
+Hyper-V Requirements:     A hypervisor has been detected. Features required for Hyper-V will not be displayed.
+```
+
+
+{{% /tab %}}
+{{< /tabs >}}
+
+
+
+<!-- steps -->
+
+## minikubeのインストール
+
+{{< tabs name="tab_with_md" >}}
+{{% tab name="Linux" %}}
+
+### kubectlのインストール
+
+kubectlがインストールされていることを確認してください。
+[kubectlのインストールとセットアップ](/ja/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)の指示に従ってkubectlをインストールできます。
+
+### ハイパーバイザーのインストール
+
+ハイパーバイザーがまだインストールされていない場合は、これらのいずれかをインストールしてください:
+
+• [KVM](https://www.linux-kvm.org/)、ただしQEMUも使っているもの
+
+• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
+
+Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--driver=none`オプションもサポートしています。
+このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。
+
+Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッケージではなく`.deb`パッケージを使用してDockerをインストールしてください。snapパッケージはMinikubeでは機能しません。
+[Docker](https://www.docker.com/products/docker-desktop)から`.deb`パッケージをダウンロードできます。
+
+{{< caution >}}
+`none` VMドライバーは、セキュリティとデータ損失の問題を引き起こす可能性があります。
+`--driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。
+{{< /caution >}}
+
+MinikubeはDockerドライバーと似たような`vm-driver=podman`もサポートしています。Podmanを特権ユーザー権限(root user)で実行することは、コンテナがシステム上の利用可能な機能へ完全にアクセスするための最もよい方法です。
+
+{{< caution >}}
+`podman` ドライバーは、rootでコンテナを実行する必要があります。これは、通常のユーザーアカウントが、コンテナの実行に必要とされるすべてのOS機能への完全なアクセスを持っていないためです。
+{{< /caution >}}
+
+### パッケージを利用したMinikubeのインストール
+
+Minikubeの*Experimental*パッケージが利用可能です。
+GitHubのMinikubeの[リリース](https://github.com/kubernetes/minikube/releases)ページからLinux(AMD64)パッケージを見つけることができます。
+
+Linuxのディストリビューションのパッケージツールを使用して、適切なパッケージをインストールしてください。
+
+### 直接ダウンロードによるMinikubeのインストール
+
+パッケージ経由でインストールしない場合は、スタンドアロンバイナリをダウンロードして使用できます。
+
+```shell
+curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
+  && chmod +x minikube
+```
+
+Minikube実行可能バイナリをパスに追加する簡単な方法を次に示します:
+
+```shell
+sudo mkdir -p /usr/local/bin/
+sudo install minikube /usr/local/bin/
+```
+
+### Homebrewを利用したMinikubeのインストール
+
+別の選択肢として、Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)を利用してインストールできます。
+
+```shell
+brew install minikube
+```
+
+{{% /tab %}}
+{{% tab name="macOS" %}}
+### kubectlのインストール
+
+kubectlがインストールされていることを確認してください。
+[kubectlのインストールとセットアップ](/ja/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos)の指示に従ってkubectlをインストールできます。
+
+### ハイパーバイザーのインストール
+
+ハイパーバイザーがまだインストールされていない場合は、これらのいずれかをインストールしてください:
+
+• [HyperKit](https://github.com/moby/hyperkit)
+
+• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
+
+• [VMware Fusion](https://www.vmware.com/products/fusion)
+
+### Minikubeのインストール
+[Homebrew](https://brew.sh)を使うことでmacOSにMinikubeを簡単にインストールできます:
+
+```shell
+brew install minikube
+```
+
+スタンドアロンのバイナリをダウンロードして、macOSにインストールすることもできます:
+
+```shell
+curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
+  && chmod +x minikube
+```
+
+Minikube実行可能バイナリをパスに追加する簡単な方法を次に示します:
+
+```shell
+sudo mv minikube /usr/local/bin
+```
+
+{{% /tab %}}
+{{% tab name="Windows" %}}
+### kubectlのインストール
+
+kubectlがインストールされていることを確認してください。
+[kubectlのインストールとセットアップ](/ja/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)の指示に従ってkubectlをインストールできます。
+
+### ハイパーバイザーのインストール
+
+ハイパーバイザーがまだインストールされていない場合は、これらのいずれかをインストールしてください:
+
+• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
+
+• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
+
+{{< note >}}
+Hyper-Vは、Windows 10 Enterprise、Windows 10 Professional、Windows 10 Educationの3つのバージョンのWindows 10で実行できます。
+{{< /note >}}
+
+### Chocolateyを使用したMinikubeのインストール
+
+[Chocolatey](https://chocolatey.org/)を使うことでWindowsにMinikubeを簡単にインストールできます(管理者権限で実行する必要があります)。
+
+```shell
+choco install minikube
+```
+
+Minikubeのインストールが終わったら、現在のCLIのセッションを終了して再起動します。Minikubeは自動的にパスに追加されます。
+
+### インストーラーを使用したMinikubeのインストール
+
+[Windowsインストーラー](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)を使用してWindowsにMinikubeを手動でインストールするには、[`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe)をダウンロードしてインストーラーを実行します。
+
+### 直接ダウンロードによるMinikubeのインストール
+
+WindowsにMinikubeを手動でインストールするには、[`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)をダウンロードし、名前を`minikube.exe`に変更して、パスに追加します。
+
+{{% /tab %}}
+{{< /tabs >}}
+
+
+
+## インストールの確認
+
+ハイパーバイザーとMinikube両方のインストール成功を確認するため、以下のコマンドをローカルKubernetesクラスターを起動するために実行してください:
+
+{{< note >}}
+
+`minikube start`で`--driver`の設定をするため、次の`<driver_name>`の部分では、インストールしたハイパーバイザーの名前を小文字で入力してください。`--driver`値のすべてのリストは、[specifying the VM driver documentation](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)で確認できます。
+
+{{< /note >}}
+
+{{< caution >}}
+KVMを使用する場合、Debianおよび他の一部のシステムでのlibvirtのデフォルトのQEMU URIは`qemu:///session`であるのに対し、MinikubeのデフォルトのQEMU URIは`qemu:///system`であることに注意してください。これがあなたのシステムに当てはまる場合、`--kvm-qemu-uri qemu:///session`を`minikube start`に渡す必要があります。
+{{< /caution >}}
+
+```shell
+minikube start --driver=<driver_name>
+```
+
+`minikube start`が完了した場合、次のコマンドを実行してクラスターの状態を確認します。
+
+```shell
+minikube status
+```
+
+クラスターが起動していると、`minikube status`の出力はこのようになります。
+
+```
+host: Running
+kubelet: Running
+apiserver: Running
+kubeconfig: Configured
+```
+
+選択したハイパーバイザーでMinikubeが動作しているか確認した後は、そのままMinikubeを使い続けることもできます。また、クラスターを停止することもできます。クラスターを停止するためには、次を実行してください。
+
+```shell
+minikube stop
+```
+
+## ローカル状態のクリーンアップ {#cleanup-local-state}
+
+もし以前に　Minikubeをインストールしていたら、以下のコマンドを実行します。
+```shell
+minikube start
+```
+
+`minikube start`はエラーを返します。
+```shell
+machine does not exist
+```
+
+minikubeのローカル状態をクリアする必要があります:
+```shell
+minikube delete
+```
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [Minikubeを使ってローカルでKubernetesを実行する](/ja/docs/setup/learning-environment/minikube/)
+
@@ -18,7 +18,7 @@ card:
 このチュートリアルでは、[Minikube](/ja/docs/setup/learning-environment/minikube)とKatacodaを使用して、Kubernetes上でサンプルアプリケーションを動かす方法を紹介します。Katacodaはブラウザで無償のKubernetes環境を提供します。

 {{< note >}}
-[Minikubeをローカルにインストール](https://minikube.sigs.k8s.io/docs/start/)している場合もこのチュートリアルを進めることが可能です。
+[Minikubeをローカルにインストール](/ja/docs/tasks/tools/install-minikube/)している場合もこのチュートリアルを進めることが可能です。
 {{< /note >}}


@@ -29,7 +29,7 @@ weight: 10

            <div class="col-md-8">
                <h2>Kubernetes Pod</h2>
-                <p>モジュール<a href="/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/">2</a>でDeploymentを作成したときに、KubernetesはアプリケーションインスタンスをホストするためのPodを作成しました。Podは、1つ以上のアプリケーションコンテナ(Dockerなど)のグループとそれらのコンテナの共有リソースを表すKubernetesの抽象概念です。 Podには以下のものが含まれます:</p>
+                <p>モジュール<a href="/ja/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>でDeploymentを作成したときに、KubernetesはアプリケーションインスタンスをホストするためのPodを作成しました。Podは、1つ以上のアプリケーションコンテナ(Dockerやrktなど)のグループとそれらのコンテナの共有リソースを表すKubernetesの抽象概念です。 Podには以下のものが含まれます:</p>
                <ul>
                    <li>共有ストレージ(ボリューム)</li>
                    <li>ネットワーキング(クラスターに固有のIPアドレス)</li>
@@ -49,7 +49,7 @@ weight: 10
                </div>
                <div class="content__box content__box_fill">
                        <p><i>
-                            Podは1つ以上のアプリケーションコンテナ(Dockerなど)のグループであり、共有ストレージ(ボリューム)、IPアドレス、それらの実行方法に関する情報が含まれています。
+                            Podは1つ以上のアプリケーションコンテナ(Dockerやrktなど)のグループであり、共有ストレージ(ボリューム)、IPアドレス、それらの実行方法に関する情報が含まれています。
                        </i></p>
                </div>
            </div>
@@ -77,7 +77,7 @@ weight: 10
                <p>すべてのKubernetesノードでは少なくとも以下のものが動作します。</p>
                <ul>
                    <li>Kubelet: Kubernetesマスターとノード間の通信を担当するプロセス。マシン上で実行されているPodとコンテナを管理します。</li>
-                    <li>レジストリからコンテナイメージを取得し、コンテナを解凍し、アプリケーションを実行することを担当する、Dockerのようなコンテナランタイム。</li>
+                    <li>レジストリからコンテナイメージを取得し、コンテナを解凍し、アプリケーションを実行することを担当する、Docker、rktのようなコンテナランタイム。</li>
                </ul>

            </div>
@@ -12,7 +12,7 @@ spec:
            operator: In
            values:
            - S1
-        topologyKey: failure-domain.beta.kubernetes.io/zone
+        topologyKey: topology.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
@@ -268,7 +268,7 @@ spec:
 *   파드 P는 노드 N에 대해 고려된다.
 *   파드 Q는 노드 N과 동일한 영역의 다른 노드에서 실행 중이다.
 *   파드 P는 파드 Q(`topologyKey:
-    failure-domain.beta.kubernetes.io/zone`)와 영역(zone) 전체의 안티-어피니티를 갖는다.
+    topology.kubernetes.io/zone`)와 영역(zone) 전체의 안티-어피니티를 갖는다.
 *   영역에서 파드 P와 다른 파드 간의 안티-어피니티에 대한 다른 경우는
    없다.
 *   노드 N에서 파드 P를 스케줄링하기 위해, 파드 Q를 축출할 수 있지만, 스케줄러는
@@ -196,8 +196,8 @@ spec:
 `preferredDuringSchedulingIgnoredDuringExecution` 이다. 파드 어피니티 규칙에 의하면 키 "security" 와 값
 "S1"인 레이블이 있는 하나 이상의 이미 실행 중인 파드와 동일한 영역에 있는 경우에만 파드를 노드에 스케줄할 수 있다.
 (보다 정확하게는, 클러스터에 키 "security"와 값 "S1"인 레이블을 가지고 있는 실행 중인 파드가 있는 키
-`failure-domain.beta.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고,
-노드 N이 키 `failure-domain.beta.kubernetes.io/zone` 와
+`topology.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고,
+노드 N이 키 `topology.kubernetes.io/zone` 와
 일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.)
 파드 안티-어피니티 규칙에 의하면 파드는 키 "security"와 값 "S2"인 레이블을 가진 파드와
 동일한 영역의 노드에 스케줄되지 않는다.
@@ -12,7 +12,7 @@ spec:
            operator: In
            values:
            - S1
-        topologyKey: failure-domain.beta.kubernetes.io/zone
+        topologyKey: topology.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
@@ -23,7 +23,7 @@ spec:
              operator: In
              values:
              - S2
-          topologyKey: failure-domain.beta.kubernetes.io/zone
+          topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: k8s.gcr.io/pause:2.0
@@ -112,7 +112,6 @@ class: training
    </center>
  </div>
  <div class="main-section landscape-section">
-    <iframe src="https://landscape.cncf.io/category=kubernetes-training-partner&format=logo-mode&grouping=category&embed=yes" frameborder="0" id="landscape" scrolling="no"></iframe>
-    <script src="https://landscape.cncf.io/iframeResizer.js"></script>
+    {{< cncf-landscape helpers=false category="kubernetes-training-partner" >}}
  </div>
 </div>
@@ -112,7 +112,6 @@ class: training
    </center>
  </div>
  <div class="main-section landscape-section">
-    <iframe src="https://landscape.cncf.io/category=kubernetes-training-partner&format=logo-mode&grouping=category&embed=yes" frameborder="0" id="landscape" scrolling="no"></iframe>
-    <script src="https://landscape.cncf.io/iframeResizer.js"></script>
+    {{< cncf-landscape helpers=false category="kubernetes-training-partner" >}}
  </div>
 </div>
@@ -0,0 +1,116 @@
+---
+title: Học kiến thức cơ bản về Kubernetes
+linkTitle: Học kiến thức cơ bản về Kubernetes
+weight: 10
+card:
+  name: Các hướng dẫn
+  weight: 20
+  title: Hướng dẫn những điều cơ bản
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+  <link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+
+<div class="layout" id="top">
+
+  <main class="content">
+
+    <div class="row">
+      <div class="col-md-9">
+        <h2>Kiến thức cơ bản về Kubernetes</h2>
+        <p>Hướng dẫn này cung cấp những kiến thức cơ bản về một cụm Kubernetes. Mỗi mô-đun chứa một số thông tin cơ bản về các tính năng cũng như khái niệm chính của Kubernetes, đồng thời bao gồm một hướng dẫn tương tác trực tuyến. Các hướng dẫn tương tác này giúp bạn quản lý một cluster đơn giản và các ứng dụng được đóng gói của bạn.</p>
+        <p>Bằng các hướng dẫn tương tác, bạn có thể học cách:</p>
+        <ul>
+        <li>Triển khai một ứng dụng container trong một cluster.</li>
+        <li>Thay đổi quy mô triển khai.</li>
+        <li>Cập nhật ứng dụng container.</li>
+        <li>Debug ứng dụng container.</li>
+        </ul>
+        <p>Những hướng dẫn này dùng Katacoda để chạy một terminal ảo trên trình duyệt web của bạn chạy Minikube. Không cần phải cài đặt và cấu hình bất kỳ phần mềm nào; mỗi hướng dẫn tương tác chạy trực tiếp từ trình duyệt web của bạn.</p>
+      </div>
+    </div>
+
+    <br>
+
+    <div class="row">
+      <div class="col-md-9">
+        <h2>Kubernetes có thế làm những gì?</h2>
+        <p>Với các dịch vụ web hiện đại, người dùng mong muốn các ứng dụng luôn sẵn sàng hoạt động 24/7 và các lập trình viên muốn triển khai các phiên bản của ứng dụng đó nhiều lần trong ngày. Việc đóng gói ứng dụng vào container giúp giải quyết mục tiêu này, cho phép các ứng dụng được phát hành và cập nhật một cách dễ dàng, nhanh chóng mà không có downtime. Kubernetes giúp bạn đảm bảo các ứng dụng container chạy ở bất kì đâu và bất kì lúc nào bạn muốn, đồng thời giúp chúng tìm thấy các tài nguyên và công cụ cần thiết để chạy. Kubernetes là nền tảng mã nguồn mở, chạy được trong môi trường production, được thiết kế và phát triển bởi Google, kết hợp với những ý tưởng tốt nhất từ cộng đồng.</p>
+      </div>
+    </div>
+
+    <br>
+    
+    <div id="basics-modules" class="content__modules">
+      <h2>Những mô-đun Kubernetes cơ bản</h2>
+      <div class="row">
+        <div class="col-md-12">
+          <div class="row">
+            <div class="col-md-4">
+              <div class="thumbnail">
+                <a href="/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_01.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/"><h5>1. Tạo mới một cụm Kubernetes</h5></a>
+                </div>
+              </div>
+            </div>
+            <div class="col-md-4">
+              <div class="thumbnail">
+                <a href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_02.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/"><h5>2. Triển khai ứng dụng</h5></a>
+                </div>
+              </div>
+            </div>
+            <div class="col-md-4">
+              <div class="thumbnail">
+                <a href="/docs/tutorials/kubernetes-basics/explore/explore-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_03.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/docs/tutorials/kubernetes-basics/explore/explore-intro/"><h5>3. Khám phá ứng dụng</h5></a>
+                </div>
+              </div>
+            </div>
+          </div>
+        </div>
+        <div class="col-md-12">
+          <div class="row">
+            <div class="col-md-4">
+              <div class="thumbnail">
+                <a href="/docs/tutorials/kubernetes-basics/expose/expose-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_04.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/docs/tutorials/kubernetes-basics/expose/expose-intro/"><h5>4. Đưa ứng dụng ra public</h5></a>
+                </div>
+              </div>
+            </div>
+            <div class="col-md-4">
+              <div class="thumbnail">
+                <a href="/docs/tutorials/kubernetes-basics/scale/scale-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_05.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/docs/tutorials/kubernetes-basics/scale/scale-intro/"><h5>5. Scale ứng dụng</h5></a>
+                </div>
+              </div>
+            </div>
+            <div class="col-md-4">
+              <div class="thumbnail">
+                <a href="/docs/tutorials/kubernetes-basics/update/update-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_06.svg?v=1469803628347" alt=""></a>
+                <div class="caption">
+                  <a href="/docs/tutorials/kubernetes-basics/update/update-intro/"><h5>6. Cập nhật ứng dụng</h5></a>
+                </div>
+              </div>
+            </div>
+          </div>
+        </div>
+      </div>
+    </div>
+
+  </main>
+
+</div>
+
+</body>
+</html>
@@ -61,7 +61,7 @@ To use priority and preemption:

 Keep reading for more information about these steps.
 -->
-## 如果使用优先级和抢占
+## 如何使用优先级和抢占

 要使用优先级和抢占特性：

@@ -530,7 +530,7 @@ preempted. Here's an example:
 *   Pod P is being considered for Node N.
 *   Pod Q is running on another Node in the same Zone as Node N.
 *   Pod P has Zone-wide anti-affinity with Pod Q (`topologyKey:
-    failure-domain.beta.kubernetes.io/zone`).
+    topology.kubernetes.io/zone`).
 *   There are no other cases of anti-affinity between Pod P and other Pods in
    the Zone.
 *   In order to schedule Pod P on Node N, Pod Q can be preempted, but scheduler
@@ -540,7 +540,7 @@ preempted. Here's an example:
 * Pod P 正在考虑被调度到节点 N。
 * Pod Q 正运行在节点 N 所处区域（Zone）的另一个节点上。
 * Pod P 设置了区域范畴的与 Pod Q 的反亲和性
-  （`topologyKey: failure-domain.beta.kubernetes.io/zone`）。
+  （`topologyKey: topology.kubernetes.io/zone`）。
 * Pod P 与区域中的其他 Pod 之间都不存在反亲和性关系。
 * 为了将 P 调度到节点 N 上，Pod Q 可以被抢占，但是调度器不会执行跨节点的
  抢占操作。因此，Pod P 会被视为无法调度到节点 N 上执行。
@@ -30,7 +30,7 @@ Resource quotas are a tool for administrators to address this concern.
 A resource quota, defined by a `ResourceQuota` object, provides constraints that limit
 aggregate resource consumption per namespace.  It can limit the quantity of objects that can
 be created in a namespace by type, as well as the total amount of compute resources that may
-be consumed by resources in that project.
+be consumed by resources in that namespace.
 -->
 资源配额，通过 `ResourceQuota` 对象来定义，对每个命名空间的资源消耗总量提供限制。
 它可以限制命名空间中某种类型的对象的总数目上限，也可以限制命令空间中的 Pod 可以使用的计算资源的总上限。
@@ -43,9 +43,9 @@ Resource quotas work like this:
 <!--
 - Different teams work in different namespaces.  Currently this is voluntary, but
  support for making this mandatory via ACLs is planned.
- The administrator creates one `ResourceQuota` for each namespace.
+- The administrator creates one ResourceQuota for each namespace.
 - Users create resources (pods, services, etc.) in the namespace, and the quota system
-  tracks usage to ensure it does not exceed hard resource limits defined in a `ResourceQuota`.
+  tracks usage to ensure it does not exceed hard resource limits defined in a ResourceQuota.
 - If creating or updating a resource violates a quota constraint, the request will fail with HTTP
  status code `403 FORBIDDEN` with a message explaining the constraint that would have been violated.
 - If quota is enabled in a namespace for compute resources like `cpu` and `memory`, users must specify
@@ -55,9 +55,9 @@ Resource quotas work like this:
 -->
 - 不同的团队可以在不同的命名空间下工作，目前这是非约束性的，在未来的版本中可能会通过
  ACL (Access Control List 访问控制列表) 来实现强制性约束。
- 集群管理员可以为每个命名空间创建一个或多个资源配额对象。
+- 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。
 - 当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会
-  跟踪集群的资源使用情况，以确保使用的资源用量不超过资源配额中定义的硬性资源限额。
+  跟踪集群的资源使用情况，以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。
 - 如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN），
  并在消息中给出有可能违反的约束。
 - 如果命名空间下的计算资源 （如 `cpu` 和 `memory`）的配额被启用，则用户必须为
@@ -68,10 +68,10 @@ Resource quotas work like this:
  [演练](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)示例。

 <!--
-The name of a `ResourceQuota` object must be a valid
+The name of a ResourceQuota object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 -->
-ResourceQuota 对象的名称必须时合法的
+ResourceQuota 对象的名称必须是合法的
 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。

 <!--
@@ -103,19 +103,19 @@ Neither contention nor changes to quota will affect already created resources.
 ## Enabling Resource Quota

 Resource Quota support is enabled by default for many Kubernetes distributions.  It is
-enabled when the apiserver `-enable-admission-plugins=` flag has `ResourceQuota` as
+enabled when the API server `--enable-admission-plugins=` flag has `ResourceQuota` as
 one of its arguments.
 -->
 ## 启用资源配额

-资源配额的支持在很多 Kubernetes 版本中是默认开启的。当 apiserver `--enable-admission-plugins=`
+资源配额的支持在很多 Kubernetes 版本中是默认开启的。当 API 服务器的 `--enable-admission-plugins=`
 参数中包含 `ResourceQuota` 时，资源配额会被启用。

 <!--
 A resource quota is enforced in a particular namespace when there is a
-`ResourceQuota` in that namespace.
+ResourceQuota in that namespace.
 -->
-当命名空间中存在一个 `ResourceQuota` 对象时，对于该命名空间而言，资源配额就是开启的。
+当命名空间中存在一个 ResourceQuota 对象时，对于该命名空间而言，资源配额就是开启的。

 <!--
 ## Compute Resource Quota
@@ -140,6 +140,10 @@ The following resource types are supported:
 | `limits.memory` | Across all pods in a non-terminal state, the sum of memory limits cannot exceed this value. |
 | `requests.cpu` | Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value. |
 | `requests.memory` | Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value. |
+| `hugepages-<size>` | Across all pods in a non-terminal state, the number of
+huge page requests of the specified size cannot exceed this value. |
+| `cpu` | Same as `requests.cpu` |
+| `memory` | Same as `requests.memory` |
 -->
 | 资源名称 | 描述 |
 | --------------------- | --------------------------------------------- |
@@ -147,6 +151,9 @@ The following resource types are supported:
 | `limits.memory` | 所有非终止状态的 Pod，其内存限额总量不能超过该值。 |
 | `requests.cpu` | 所有非终止状态的 Pod，其 CPU 需求总量不能超过该值。 |
 | `requests.memory` | 所有非终止状态的 Pod，其内存需求总量不能超过该值。 |
+| `hugepages-<size>` | 对于所有非终止状态的 Pod，针对指定尺寸的巨页请求总数不能超过此值。 |
+| `cpu` | 与 `requests.cpu` 相同。 |
+| `memory` | 与 `requests.memory` 相同。 |

 <!--
 ### Resource Quota For Extended Resources
@@ -198,16 +205,16 @@ In addition, you can limit consumption of storage resources based on associated
 | Resource Name | Description |
 | --------------------- | --------------------------------------------------------- |
 | `requests.storage` | Across all persistent volume claims, the sum of storage requests cannot exceed this value. |
-| `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
-| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | Across all persistent volume claims associated with the storage-class-name, the sum of storage requests cannot exceed this value. |
+| `persistentvolumeclaims` | The total number of [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
+| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | Across all persistent volume claims associated with the `<storage-class-name>`, the sum of storage requests cannot exceed this value. |
 | `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | Across all persistent volume claims associated with the storage-class-name, the total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
 -->
 | 资源名称 | 描述 |
 | --------------------- | ----------------------------------------------------------- |
 | `requests.storage` | 所有 PVC，存储资源的需求总量不能超过该值。 |
-| `persistentvolumeclaims` | 在该命名空间中所允许的 [PVC](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 总量。 |
-| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | 在所有与 storage-class-name 相关的持久卷声明中，存储请求的总和不能超过该值。 |
-| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` |  在与 storage-class-name 相关的所有持久卷声明中，命名空间中可以存在的[持久卷申领](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)总数。 |
+| `persistentvolumeclaims` | 在该命名空间中所允许的 [PVC](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 总量。 |
+| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | 在所有与 `<storage-class-name>` 相关的持久卷申领中，存储请求的总和不能超过该值。 |
+| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` |  在与 storage-class-name 相关的所有持久卷申领中，命名空间中可以存在的[持久卷申领](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)总数。 |

 <!--
 For example, if an operator wants to quota storage with `gold` storage class separate from `bronze` storage class, the operator can
@@ -228,22 +235,29 @@ In release 1.8, quota support for local ephemeral storage is added as an alpha f
 | ------------------------------- |----------------------------------------------------------- |
 | `requests.ephemeral-storage` | Across all pods in the namespace, the sum of local ephemeral storage requests cannot exceed this value. |
 | `limits.ephemeral-storage` | Across all pods in the namespace, the sum of local ephemeral storage limits cannot exceed this value. |
+| `ephemeral-storage` | Same as `requests.ephemeral-storage`. |
 -->
 | 资源名称 | 描述 |
 | ------------------------------- |----------------------------------------------------------- |
 | `requests.ephemeral-storage` | 在命名空间的所有 Pod 中，本地临时存储请求的总和不能超过此值。 |
 | `limits.ephemeral-storage` | 在命名空间的所有 Pod 中，本地临时存储限制值的总和不能超过此值。 |
+| `ephemeral-storage` | 与 `requests.ephemeral-storage` 相同。 |

 <!--
 ## Object Count Quota

-The 1.9 release added support to quota all standard namespaced resource types using the following syntax:
+You can set quota for the total number of certain resources of all standard,
+namespaced resource types using the following syntax:
+
+* `count/<resource>.<group>` for resources from non-core groups
+* `count/<resource>` for resources from the core group
 -->
 ## 对象数量配额

-Kubernetes 1.9 版本增加了使用以下语法对所有标准的、命名空间域的资源类型进行配额设置的支持。
+你可以使用以下语法对所有标准的、命名空间域的资源类型进行配额设置：

-* `count/<resource>.<group>`
+* `count/<resource>.<group>`：用于非核心（core）组的资源
+* `count/<resource>`：用于核心组的资源

 <!--
 Here is an example set of resources users may want to put under object count quota:
@@ -260,33 +274,34 @@ Here is an example set of resources users may want to put under object count quo
 * `count/statefulsets.apps`
 * `count/jobs.batch`
 * `count/cronjobs.batch`
-* `count/deployments.extensions`

 <!--
-The 1.15 release added support for custom resources using the same syntax.
+The same syntax can be used for custom resources.
 For example, to create a quota on a `widgets` custom resource in the `example.com` API group, use `count/widgets.example.com`.
 -->
-Kubernetes 1.15 版本增加了对使用相同语法来约束自定义资源的支持。
+相同语法也可用于自定义资源。
 例如，要对 `example.com` API 组中的自定义资源 `widgets` 设置配额，请使用 `count/widgets.example.com`。

 <!--
 When using `count/*` resource quota, an object is charged against the quota if it exists in server storage.
 These types of quotas are useful to protect against exhaustion of storage resources.  For example, you may
-want to quota the number of secrets in a server given their large size.  Too many secrets in a cluster can
-actually prevent servers and controllers from starting!  You may choose to quota jobs to protect against
-a poorly configured cronjob creating too many jobs in a namespace causing a denial of service.
+want to limit the number of Secrets in a server given their large size. Too many Secrets in a cluster can
+actually prevent servers and controllers from starting. You can set a quota for Jobs to protect against
+a poorly configured CronJob. CronJobs that create too many Jobs in a namespace can lead to a denial of service.
 -->
 当使用 `count/*` 资源配额时，如果对象存在于服务器存储中，则会根据配额管理资源。
-这些类型的配额有助于防止存储资源耗尽。例如，用户可能想根据服务器的存储能力来对服务器中 Secret 的数量进行配额限制。集群中存在过多的 Secret 实际上会导致服务器和控制器无法启动！用户可以选择对 Job 进行配额管理，以防止配置不当的 CronJob 在某命名空间中创建太多作业而导致集群拒绝服务。
-
+这些类型的配额有助于防止存储资源耗尽。例如，用户可能想根据服务器的存储能力来对服务器中
+Secret 的数量进行配额限制。
+集群中存在过多的 Secret 实际上会导致服务器和控制器无法启动。
+用户可以选择对 Job 进行配额管理，以防止配置不当的 CronJob 在某命名空间中创建太多 Job 而导致集群拒绝服务。

 <!--
-Prior to the 1.9 release, it was possible to do generic object count quota on a limited set of resources.
+It is possible to do generic object count quota on a limited set of resources.
 In addition, it is possible to further constrain quota for particular resources by their type.

 The following types are supported:
 -->
-在 Kubernetes 1.9 版本之前，可以在有限的一组资源上实施一般性的对象数量配额。
+对有限的一组资源上实施一般性的对象数量配额也是可能的。
 此外，还可以进一步按资源的类型设置其配额。

 支持以下类型：
@@ -294,26 +309,26 @@ The following types are supported:
 <!--
 | Resource Name | Description |
 | ----------------------------|--------------------------------------------- |
-| `configmaps` | The total number of config maps that can exist in the namespace. |
-| `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
-| `pods` | The total number of pods in a non-terminal state that can exist in the namespace.  A pod is in a terminal state if `.status.phase in (Failed, Succeeded)` is true.  |
-| `replicationcontrollers` | The total number of replication controllers that can exist in the namespace. |
-| `resourcequotas` | The total number of [resource quotas](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) that can exist in the namespace. |
-| `services` | The total number of services that can exist in the namespace. |
-| `services.loadbalancers` | The total number of services of type load balancer that can exist in the namespace. |
-| `services.nodeports` | The total number of services of type node port that can exist in the namespace. |
-| `secrets` | The total number of secrets that can exist in the namespace. |
+| `configmaps` | The total number of ConfigMaps that can exist in the namespace. |
+| `persistentvolumeclaims` | The total number of [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
+| `pods` | The total number of Pods in a non-terminal state that can exist in the namespace.  A pod is in a terminal state if `.status.phase in (Failed, Succeeded)` is true.  |
+| `replicationcontrollers` | The total number of ReplicationControllers that can exist in the namespace. |
+| `resourcequotas` | The total number of ResourceQuotas that can exist in the namespace. |
+| `services` | The total number of Services that can exist in the namespace. |
+| `services.loadbalancers` | The total number of Services of type `LoadBalancer` that can exist in the namespace. |
+| `services.nodeports` | The total number of Services of type `NodePort` that can exist in the namespace. |
+| `secrets` | The total number of Secrets that can exist in the namespace. |
 -->
 | 资源名称 | 描述 |
 | ------------------------------- | ------------------------------------------------- |
 | `configmaps` | 在该命名空间中允许存在的 ConfigMap 总数上限。 |
-| `persistentvolumeclaims` | 在该命名空间中允许存在的 [PVC](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 的总数上限。 |
-| `pods` | 在该命名空间中允许存在的非终止状态的 pod 总数上限。Pod 终止状态等价于 Pod 的 `.status.phase in (Failed, Succeeded)` = true |
-| `replicationcontrollers` | 在该命名空间中允许存在的 RC 总数上限。 |
-| `resourcequotas` | 在该命名空间中允许存在的资源配额总数上限。 |
+| `persistentvolumeclaims` | 在该命名空间中允许存在的 [PVC](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 的总数上限。 |
+| `pods` | 在该命名空间中允许存在的非终止状态的 Pod 总数上限。Pod 终止状态等价于 Pod 的 `.status.phase in (Failed, Succeeded)` 为真。 |
+| `replicationcontrollers` | 在该命名空间中允许存在的 ReplicationController 总数上限。 |
+| `resourcequotas` | 在该命名空间中允许存在的 ResourceQuota 总数上限。 |
 | `services` | 在该命名空间中允许存在的 Service 总数上限。 |
-| `services.loadbalancers` | 在该命名空间中允许存在的 LoadBalancer 类型的服务总数上限。 |
-| `services.nodeports` | 在该命名空间中允许存在的 NodePort 类型的服务总数上限。 |
+| `services.loadbalancers` | 在该命名空间中允许存在的 LoadBalancer 类型的 Service 总数上限。 |
+| `services.nodeports` | 在该命名空间中允许存在的 NodePort 类型的 Service 总数上限。 |
 | `secrets` | 在该命名空间中允许存在的 Secret 总数上限。 |

 <!--
@@ -328,12 +343,12 @@ exhausts the cluster's supply of Pod IPs.
 <!--
 ## Quota Scopes

-Each quota can have an associated set of scopes.  A quota will only measure usage for a resource if it matches
+Each quota can have an associated set of `scopes`. A quota will only measure usage for a resource if it matches
 the intersection of enumerated scopes.
 -->
 ## 配额作用域   {#quota-scopes}

-每个配额都有一组相关的作用域（scope），配额只会对作用域内的资源生效。
+每个配额都有一组相关的 `scope`（作用域），配额只会对作用域内的资源生效。
 配额机制仅统计所列举的作用域的交集中的资源用量。

 <!--
@@ -350,6 +365,7 @@ Resources specified on the quota outside of the allowed set results in a validat
 | `NotTerminating` | Match pods where `.spec.activeDeadlineSeconds is nil` |
 | `BestEffort` | Match pods that have best effort quality of service. |
 | `NotBestEffort` | Match pods that do not have best effort quality of service. |
+| `PriorityClass` | Match pods that references the specified [priority class](/docs/concepts/configuration/pod-priority-preemption). |
 -->
 | 作用域 | 描述 |
 | ----- | ----------- |
@@ -357,30 +373,88 @@ Resources specified on the quota outside of the allowed set results in a validat
 | `NotTerminating` | 匹配所有 `spec.activeDeadlineSeconds` 是 nil 的 Pod。 |
 | `BestEffort` | 匹配所有 Qos 是 BestEffort 的 Pod。 |
 | `NotBestEffort` | 匹配所有 Qos 不是 BestEffort 的 Pod。 |
+| `PriorityClass` | 匹配所有引用了所指定的[优先级类](/zh/docs/concepts/configuration/pod-priority-preemption)的 Pods。 |

 <!--
-The `BestEffort` scope restricts a quota to tracking the following resource: `pods`
+The `BestEffort` scope restricts a quota to tracking the following resource:

-The `Terminating`, `NotTerminating`, and `NotBestEffort` scopes restrict a quota to tracking the following resources:
-->
-`BestEffort` 作用域限制配额跟踪以下资源：`pods`
-
-`Terminating`、`NotTerminating` 和 `NotBestEffort` 这三种作用域限制配额跟踪以下资源：
-
-* `cpu`
-* `limits.cpu`
-* `limits.memory`
-* `memory`
 * `pods`
+
+The `Terminating`, `NotTerminating`, `NotBestEffort` and `PriorityClass`
+scopes restrict a quota to tracking the following resources:
+-->
+`BestEffort` 作用域限制配额跟踪以下资源：
+
+* `pods`
+
+`Terminating`、`NotTerminating`、`NotBestEffort` 和 `PriorityClass` 这些作用域限制配额跟踪以下资源：
+
+* `pods`
+* `cpu`
+* `memory`
 * `requests.cpu`
 * `requests.memory`
+* `limits.cpu`
+* `limits.memory`
+
+<!--
+Note that you cannot specify both the `Terminating` and the `NotTerminating`
+scopes in the same quota, and you cannot specify both the `BestEffort` and
+`NotBestEffort` scopes in the same quota either.
+
+The `scopeSelector` supports the following values in the `operator` field:
+-->
+需要注意的是，你不可以在同一个配额对象中同时设置 `Terminating` 和 `NotTerminating`
+作用域，你也不可以在同一个配额中同时设置 `BestEffort` 和 `NotBestEffort`
+作用域。
+
+`scopeSelector` 支持在 `operator` 字段中使用以下值：
+
+* `In`
+* `NotIn`
+* `Exists`
+* `DoesNotExist`
+
+<!--
+When using one of the following values as the `scopeName` when defining the
+`scopeSelector`, the `operator` must be `Exists`. 
+-->
+定义 `scopeSelector` 时，如果使用以下值之一作为 `scopeName` 的值，则对应的
+`operator` 只能是 `Exists`。
+
+* `Terminating`
+* `NotTerminating`
+* `BestEffort`
+* `NotBestEffort`
+
+<!--
+If the `operator` is `In` or `NotIn`, the `values` field must have at least
+one value. For example:
+-->
+如果 `operator` 是 `In` 或 `NotIn` 之一，则 `values` 字段必须至少包含一个值。
+例如：
+
+```yaml
+  scopeSelector:
+    matchExpressions:
+      - scopeName: PriorityClass
+        operator: In
+        values:
+          - middle
+```
+
+<!--
+If the `operator` is `Exists` or `DoesNotExist`, the `values field must *NOT* be
+specified.
+-->
+如果 `operator` 为 `Exists` 或 `DoesNotExist`，则*不*可以设置 `values` 字段。

 <!--
 ### Resource Quota Per PriorityClass
 -->
 ### 基于优先级类（PriorityClass）来设置资源配额

-{{< feature-state for_k8s_version="1.12" state="beta" >}}
+{{< feature-state for_k8s_version="v1.17" state="stable" >}}

 <!--
 Pods can be created at a specific [priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority).
@@ -392,12 +466,30 @@ Pod 可以创建为特定的[优先级](/docs/concepts/configuration/pod-priorit

 <!--
 A quota is matched and consumed only if `scopeSelector` in the quota spec selects the pod.
-
-This example creates a quota object and matches it with pods at specific priorities. The example
-works as follows:
 -->
 仅当配额规范中的 `scopeSelector` 字段选择到某 Pod 时，配额机制才会匹配和计量 Pod 的资源消耗。

+<!--
+When quota is scoped for priority class using `scopeSelector` field, quota object is restricted to track only following resources:
+-->
+如果配额对象通过 `scopeSelector` 字段设置其作用域为优先级类，则配额对象只能
+跟踪以下资源：
+
+* `pods`
+* `cpu`
+* `memory`
+* `ephemeral-storage`
+* `limits.cpu`
+* `limits.memory`
+* `limits.ephemeral-storage`
+* `requests.cpu`
+* `requests.memory`
+* `requests.ephemeral-storage`
+
+<!--
+This example creates a quota object and matches it with pods at specific priorities. The example
+works as follows:
+-->
 本示例创建一个配额对象，并将其与具有特定优先级的 Pod 进行匹配。
 该示例的工作方式如下：

@@ -586,16 +678,6 @@ memory      0     20Gi
 pods        0     10
 ```

-<!--
-`scopeSelector` supports the following values in the `operator` field:
-->
-`scopeSelector` 在 `operator` 字段中支持以下值：
-
-* `In`
-* `NotIn`
-* `Exist`
-* `DoesNotExist`
-
 <!--
 ## Requests vs Limits

@@ -725,11 +807,11 @@ kubectl create namespace myspace
 ```

 ```shell
-kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace
+kubectl create quota test --hard=count/deployments.apps=2,count/replicasets.apps=4,count/pods=3,count/secrets=4 --namespace=myspace
 ```

 ```shell
-kubectl create deployment nginx --image=nginx --namespace=myspace
+kubectl create deployment nginx --image=nginx --namespace=myspace --replicas=2
 ```

 ```shell
@@ -741,37 +823,37 @@ Name:                         test
 Namespace:                    myspace
 Resource                      Used  Hard
 --------                      ----  ----
-count/deployments.extensions  1     2
+count/deployments.apps        1     2
 count/pods                    2     3
-count/replicasets.extensions  1     4
+count/replicasets.apps        1     4
 count/secrets                 1     4
 ```

 <!--
 ## Quota and Cluster Capacity

-`ResourceQuotas` are independent of the cluster capacity. They are
+ResourceQuotas are independent of the cluster capacity. They are
 expressed in absolute units.  So, if you add nodes to your cluster, this does *not*
 automatically give each namespace the ability to consume more resources.
 -->
 ## 配额和集群容量   {#quota-and-cluster-capacity}

-资源配额与集群资源总量是完全独立的。它们通过绝对的单位来配置。
+ResourceQuota 与集群资源总量是完全独立的。它们通过绝对的单位来配置。
 所以，为集群添加节点时，资源配额*不会*自动赋予每个命名空间消耗更多资源的能力。

 <!--
 Sometimes more complex policies may be desired, such as:

-  - Proportionally divide total cluster resources among several teams.
-  - Allow each tenant to grow resource usage as needed, but have a generous
-    limit to prevent accidental resource exhaustion.
-  - Detect demand from one namespace, add nodes, and increase quota.
+- Proportionally divide total cluster resources among several teams.
+- Allow each tenant to grow resource usage as needed, but have a generous
+  limit to prevent accidental resource exhaustion.
+- Detect demand from one namespace, add nodes, and increase quota.
 -->
 有时可能需要资源配额支持更复杂的策略，比如：

-  - 在几个团队中按比例划分总的集群资源。
-  - 允许每个租户根据需要增加资源使用量，但要有足够的限制以防止资源意外耗尽。
-  - 探测某个命名空间的需求，添加物理节点并扩大资源配额值。
+- 在几个团队中按比例划分总的集群资源。
+- 允许每个租户根据需要增加资源使用量，但要有足够的限制以防止资源意外耗尽。
+- 探测某个命名空间的需求，添加物理节点并扩大资源配额值。

 <!--
 Such policies could be implemented using `ResourceQuotas` as building blocks, by
@@ -790,7 +872,8 @@ restrictions around nodes: pods from several namespaces may run on the same node
 <!--
 ## Limit Priority Class consumption by default

-It may be desired that pods at a particular priority, eg. "cluster-services", should be allowed in a namespace, if and only if, a matching quota object exists.
+It may be desired that pods at a particular priority, eg. "cluster-services",
+should be allowed in a namespace, if and only if, a matching quota object exists.
 -->
 ## 默认情况下限制特定优先级的资源消耗

@@ -798,18 +881,19 @@ It may be desired that pods at a particular priority, eg. "cluster-services", sh
 （例如 "cluster-services"）的 Pod。

 <!--
-With this mechanism, operators will be able to restrict usage of certain high priority classes to a limited number of namespaces and not every namespace will be able to consume these priority classes by default.
+With this mechanism, operators will be able to restrict usage of certain high
+priority classes to a limited number of namespaces and not every namespace
+will be able to consume these priority classes by default.
 -->
 通过这种机制，操作人员能够将限制某些高优先级类仅出现在有限数量的命名空间中，
 而并非每个命名空间默认情况下都能够使用这些优先级类。

 <!--
-To enforce this, kube-apiserver flag `-admission-control-config-file` should be used to pass path to the following configuration file:
+To enforce this, kube-apiserver flag `-admission-control-config-file` should be
+used to pass path to the following configuration file:
 -->
 要实现此目的，应使用 kube-apiserver 标志 `--admission-control-config-file` 传递如下配置文件的路径：

-{{< tabs name="example1" >}}
-{{% tab name="apiserver.config.k8s.io/v1" %}}
 ```yaml
 apiVersion: apiserver.config.k8s.io/v1
 kind: AdmissionConfiguration
@@ -825,27 +909,6 @@ plugins:
        operator: In
        values: ["cluster-services"]
 ```
-{{% /tab %}}
-{{% tab name="apiserver.k8s.io/v1alpha1" %}}
-```yaml
-# 在 Kubernetes 1.17 中已不推荐使用，请使用 apiserver.config.k8s.io/v1
-apiVersion: apiserver.k8s.io/v1alpha1
-kind: AdmissionConfiguration
-plugins:
- name: "ResourceQuota"
-  configuration:
-    # 在 Kubernetes 1.17 中已不推荐使用，请使用 apiserver.config.k8s.io/v1, ResourceQuotaConfiguration
-    apiVersion: resourcequota.admission.k8s.io/v1beta1
-    kind: Configuration
-    limitedResources:
-    - resource: pods
-      matchScopes:
-      - scopeName: PriorityClass
-        operator: In
-        values: ["cluster-services"]
-```
-{{% /tab %}}
-{{< /tabs >}}

 <!--
 Now, "cluster-services" pods will be allowed in only those namespaces where a quota object with a matching `scopeSelector` is present.
@@ -864,25 +927,17 @@ For example:
        values: ["cluster-services"]
 ```

-<!--
-See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) and [Quota support for priority class design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md) for more information.
-->
-有关更多信息，请参见 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) 和
-[优先级类配额支持的设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)。
-
-<!--
-## Example
-
-See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/).
-->
-## 示例
-
-查看[如何使用资源配额的详细示例](/zh/docs/tasks/administer-cluster/quota-api-object/)。
-
 ## {{% heading "whatsnext" %}}

 <!--
 - See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information.
+- See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/).
+- Read [Quota support for priority class design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md).
+- See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)
 -->
 - 查看[资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)
+- 查看[如何使用资源配额的详细示例](/zh/docs/tasks/administer-cluster/quota-api-object/)。
+- 阅读[优先级类配额支持的设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)。
  了解更多信息。
+- 参阅[LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)
+
@@ -391,11 +391,11 @@ The affinity on this pod defines one pod affinity rule and one pod anti-affinity
 while the `podAntiAffinity` is `preferredDuringSchedulingIgnoredDuringExecution`. The
 pod affinity rule says that the pod can be scheduled onto a node only if that node is in the same zone
 as at least one already-running pod that has a label with key "security" and value "S1". (More precisely, the pod is eligible to run
-on node N if node N has a label with key `failure-domain.beta.kubernetes.io/zone` and some value V
-such that there is at least one node in the cluster with key `failure-domain.beta.kubernetes.io/zone` and
+on node N if node N has a label with key `topology.kubernetes.io/zone` and some value V
+such that there is at least one node in the cluster with key `topology.kubernetes.io/zone` and
 value V that is running a pod that has a label with key "security" and value "S1".) The pod anti-affinity
 rule says that the pod prefers not to be scheduled onto a node if that node is already running a pod with label
-having key "security" and value "S2". (If the `topologyKey` were `failure-domain.beta.kubernetes.io/zone` then
+having key "security" and value "S2". (If the `topologyKey` were `topology.kubernetes.io/zone` then
 it would mean that the pod cannot be scheduled onto a node if that node is in the same zone as a pod with
 label having key "security" and value "S2".) See the
 [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
@@ -403,7 +403,7 @@ for many more examples of pod affinity and anti-affinity, both the `requiredDuri
 flavor and the `preferredDuringSchedulingIgnoredDuringExecution` flavor.
 -->

-在这个 pod 的 affinity 配置定义了一条 pod 亲和规则和一条 pod 反亲和规则。在此示例中，`podAffinity` 配置为 `requiredDuringSchedulingIgnoredDuringExecution`，然而 `podAntiAffinity` 配置为 `preferredDuringSchedulingIgnoredDuringExecution`。pod 亲和规则表示，仅当节点和至少一个已运行且有键为“security”且值为“S1”的标签的 pod 处于同一区域时，才可以将该 pod 调度到节点上。（更确切的说，如果节点 N 具有带有键 `failure-domain.beta.kubernetes.io/zone` 和某个值 V 的标签，则 pod 有资格在节点 N 上运行，以便集群中至少有一个节点具有键 `failure-domain.beta.kubernetes.io/zone` 和值为 V 的节点正在运行具有键“security”和值“S1”的标签的 pod。）pod 反亲和规则表示，如果节点已经运行了一个具有键“security”和值“S2”的标签的 pod，则该 pod 不希望将其调度到该节点上。（如果 `topologyKey` 为 `failure-domain.beta.kubernetes.io/zone`，则意味着当节点和具有键“security”和值“S2”的标签的 pod 处于相同的区域，pod 不能被调度到该节点上。）查阅[设计文档](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)来获取更多 pod 亲和与反亲和的样例，包括 `requiredDuringSchedulingIgnoredDuringExecution`
+在这个 pod 的 affinity 配置定义了一条 pod 亲和规则和一条 pod 反亲和规则。在此示例中，`podAffinity` 配置为 `requiredDuringSchedulingIgnoredDuringExecution`，然而 `podAntiAffinity` 配置为 `preferredDuringSchedulingIgnoredDuringExecution`。pod 亲和规则表示，仅当节点和至少一个已运行且有键为“security”且值为“S1”的标签的 pod 处于同一区域时，才可以将该 pod 调度到节点上。（更确切的说，如果节点 N 具有带有键 `topology.kubernetes.io/zone` 和某个值 V 的标签，则 pod 有资格在节点 N 上运行，以便集群中至少有一个节点具有键 `topology.kubernetes.io/zone` 和值为 V 的节点正在运行具有键“security”和值“S1”的标签的 pod。）pod 反亲和规则表示，如果节点已经运行了一个具有键“security”和值“S2”的标签的 pod，则该 pod 不希望将其调度到该节点上。（如果 `topologyKey` 为 `topology.kubernetes.io/zone`，则意味着当节点和具有键“security”和值“S2”的标签的 pod 处于相同的区域，pod 不能被调度到该节点上。）查阅[设计文档](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)来获取更多 pod 亲和与反亲和的样例，包括 `requiredDuringSchedulingIgnoredDuringExecution`
 和 `preferredDuringSchedulingIgnoredDuringExecution` 两种配置。

 <!--
@@ -423,13 +423,13 @@ for performance and security reasons, there are some constraints on topologyKey:
 1. For affinity and for `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity,
 empty `topologyKey` is not allowed.
 2. For `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, the admission controller `LimitPodHardAntiAffinityTopology` was introduced to limit `topologyKey` to `kubernetes.io/hostname`. If you want to make it available for custom topologies, you may modify the admission controller, or simply disable it.
-3. For `preferredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, empty `topologyKey` is interpreted as "all topologies" ("all topologies" here is now limited to the combination of `kubernetes.io/hostname`, `failure-domain.beta.kubernetes.io/zone` and `failure-domain.beta.kubernetes.io/region`).
+3. For `preferredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, empty `topologyKey` is interpreted as "all topologies" ("all topologies" here is now limited to the combination of `kubernetes.io/hostname`, `topology.kubernetes.io/zone` and `topology.kubernetes.io/region`).
 4. Except for the above cases, the `topologyKey` can be any legal label-key.
 -->

 1. 对于亲和与 `requiredDuringSchedulingIgnoredDuringExecution` 要求的 pod 反亲和，`topologyKey` 不允许为空。
 2. 对于 `requiredDuringSchedulingIgnoredDuringExecution` 要求的 pod 反亲和，准入控制器 `LimitPodHardAntiAffinityTopology` 被引入来限制 `topologyKey` 不为 `kubernetes.io/hostname`。如果你想使它可用于自定义拓扑结构，你必须修改准入控制器或者禁用它。
-3. 对于 `preferredDuringSchedulingIgnoredDuringExecution` 要求的 pod 反亲和，空的 `topologyKey` 被解释为“所有拓扑结构”（这里的“所有拓扑结构”限制为 `kubernetes.io/hostname`，`failure-domain.beta.kubernetes.io/zone` 和 `failure-domain.beta.kubernetes.io/region` 的组合）。
+3. 对于 `preferredDuringSchedulingIgnoredDuringExecution` 要求的 pod 反亲和，空的 `topologyKey` 被解释为“所有拓扑结构”（这里的“所有拓扑结构”限制为 `kubernetes.io/hostname`，`topology.kubernetes.io/zone` 和 `topology.kubernetes.io/region` 的组合）。
 4. 除上述情况外，`topologyKey` 可以是任何合法的标签键。

 <!--
@@ -138,13 +138,13 @@ of the scheduler:
 <!-- 
 1. [Scheduling Policies](/docs/reference/scheduling/policies) allow you to
  configure _Predicates_ for filtering and _Priorities_ for scoring.
-1. [Scheduling Profiles](/docs/reference/scheduling/profiles) allow you to
+1. [Scheduling Profiles](/docs/reference/scheduling/config/#profiles) allow you to
  configure Plugins that implement different scheduling stages, including:
  `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You
  can also configure the kube-scheduler to run different profiles.
 -->
-1. [调度策略](/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_ 和打分的 _优先级(Priorities)_ 。
-2. [调度配置](/docs/reference/scheduling/profiles) 允许你配置实现不同调度阶段的插件，包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。你也可以配置 kube-scheduler 运行不同的配置文件。
+1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _谓词(Predicates)_ 和打分的 _优先级(Priorities)_ 。
+2. [调度配置](/zh/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件，包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。你也可以配置 kube-scheduler 运行不同的配置文件。


 ## {{% heading "whatsnext" %}}
@@ -156,7 +156,7 @@ of the scheduler:
 * Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
 * Learn about [configuring multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
 * Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
-* Learn about [Pod Overhead](/docs/concepts/configuration/pod-overhead/)
+* Learn about [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
 -->

 * 阅读关于 [调度器性能调优](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
@@ -164,5 +164,5 @@ of the scheduler:
 * 阅读关于 kube-scheduler 的 [参考文档](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
 * 了解关于 [配置多个调度器](/zh/docs/tasks/administer-cluster/configure-multiple-schedulers/) 的方式
 * 了解关于 [拓扑结构管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)
-* 了解关于 [Pod 额外开销](/zh/docs/concepts/configuration/pod-overhead/)
+* 了解关于 [Pod 额外开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)

@@ -229,15 +229,15 @@ This step brings up a cluster as normal, still running in a single zone

 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:
+labels are `topology.kubernetes.io/region` for the region,
+and `topology.kubernetes.io/zone` for the zone:
 -->
 ### 节点已被打标签

 查看节点，你会看到节点上已经有了区信息标签。
 目前这些节点都在 `us-central1-a` (GCE) 或 `us-west-2a` (AWS)。
-对于区域（Region），标签为 `failure-domain.beta.kubernetes.io/region`，
-对于区（Zone），标签为 `failure-domain.beta.kubernetes.io/zone`：
+对于区域（Region），标签为 `topology.kubernetes.io/region`，
+对于区（Zone），标签为 `topology.kubernetes.io/zone`：

 ```shell
 kubectl get nodes --show-labels
@@ -250,10 +250,10 @@ The output is similar to this:

 ```
 NAME                     STATUS                     ROLES    AGE   VERSION          LABELS
-kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
-kubernetes-minion-87j9   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
-kubernetes-minion-9vlv   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
+kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-1,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
+kubernetes-minion-87j9   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
+kubernetes-minion-9vlv   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
 ```
 <!--
 ### Add more nodes in a second zone
@@ -304,13 +304,13 @@ The output is similar to this:

 ```
 NAME                     STATUS                     ROLES    AGE   VERSION           LABELS
-kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
-kubernetes-minion-281d   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
-kubernetes-minion-87j9   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
-kubernetes-minion-9vlv   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-a12q   Ready                      <none>   17m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
-kubernetes-minion-pp2f   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
-kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
+kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-1,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
+kubernetes-minion-281d   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
+kubernetes-minion-87j9   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
+kubernetes-minion-9vlv   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-a12q   Ready                      <none>   17m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
+kubernetes-minion-pp2f   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
+kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
 ```

 <!--
@@ -379,7 +379,7 @@ The output is similar to this:

 ```
 NAME           CAPACITY   ACCESSMODES   RECLAIM POLICY   STATUS    CLAIM            STORAGECLASS    REASON    AGE       LABELS
-pv-gce-mj4gm   5Gi        RWO           Retain           Bound     default/claim1   manual                    46s       failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
+pv-gce-mj4gm   5Gi        RWO           Retain           Bound     default/claim1   manual                    46s       topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a
 ```

 <!--
@@ -435,7 +435,7 @@ kubectl get node kubernetes-minion-9vlv --show-labels

 ```
 NAME                     STATUS    AGE    VERSION          LABELS
-kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
 ```

 <!--
@@ -500,9 +500,9 @@ kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion

 ```
 NAME                     STATUS    ROLES    AGE    VERSION          LABELS
-kubernetes-minion-9vlv   Ready     <none>   34m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
-kubernetes-minion-281d   Ready     <none>   20m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
-kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
+kubernetes-minion-9vlv   Ready     <none>   34m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-281d   Ready     <none>   20m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
+kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,topology.kubernetes.io/region=us-central1,topology.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
 ```

 <!--
@@ -12,7 +12,7 @@ spec:
            operator: In
            values:
            - S1
-        topologyKey: failure-domain.beta.kubernetes.io/zone
+        topologyKey: topology.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
@@ -23,7 +23,7 @@ spec:
              operator: In
              values:
              - S2
-          topologyKey: failure-domain.beta.kubernetes.io/zone
+          topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: k8s.gcr.io/pause:2.0
@@ -281,7 +281,6 @@
 /docs/tasks/run-application/podpreset/     /docs/tasks/inject-data-application/podpreset/ 301
 /docs/tasks/run-application/update-api-object-kubectl-patch/    /docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/ 301
 /docs/tasks/stateful-sets/deleting-pods/     /docs/tasks/run-application/force-delete-stateful-set-pod/ 301
-/ja/docs/tasks/tools/install-minikube/     https://minikube.sigs.k8s.io/docs/start/ 302
 /docs/tasks/troubleshoot/debug-init-containers/     /docs/tasks/debug-application-cluster/debug-init-containers/ 301
 /docs/tasks/web-ui-dashboard/     /docs/tasks/access-application-cluster/web-ui-dashboard/ 301
Author	SHA1	Message	Date
Nguyen Hai Truong	5dc6252a52	Adding button "Learn Kubernetes Basics" Signed-off-by: Nguyen Hai Truong <nguyenhaitruonghp@gmail.com>	2020-11-11 23:29:12 +07:00
Kubernetes Prow Robot	e3109f5829	Merge pull request #24963 from sftim/20201109_fix_flow_control_metrics_merge_wrong_branch Revert pull request 24905	2020-11-09 16:34:41 -08:00
Tim Bannister	595850ca21	Revert pull request 24905 This reverts commit `a9a7249330`, reversing changes made to `6d72006c7e` - because these commits were applied to the wrong branch.	2020-11-09 21:32:44 +00:00
Kubernetes Prow Robot	a9a7249330	Merge pull request #24905 from adtac/apfsnake flow control metrics: switch to snake_case for labels	2020-11-09 12:34:27 -08:00
Kubernetes Prow Robot	6d72006c7e	Merge pull request #24942 from timyinshi/scheduler modify the chinese url	2020-11-08 17:43:38 -08:00
timyinshi	b97e1b44f8	modify the error url of scheduler Signed-off-by: timyinshi <shiguangyin@inspur.com>	2020-11-09 09:30:53 +08:00
Kubernetes Prow Robot	77f6a5cf0c	Merge pull request #24951 from Arhell/add-shortcode add shortcode to training page	2020-11-08 15:17:37 -08:00
Arhell	88091c32fd	add shortcode to training page	2020-11-09 00:37:05 +02:00
Kubernetes Prow Robot	358bc69dde	Merge pull request #24878 from ebriand/patch-5 Update default admission plugins for 1.19	2020-11-08 12:07:37 -08:00
Kubernetes Prow Robot	1db894c643	Merge pull request #24894 from tengqm/zh-sync-resource-quota [zh] Sync changes to docs/concepts/policy/resource-quotas.md	2020-11-08 12:05:37 -08:00
Kubernetes Prow Robot	5a01c122ab	Merge pull request #24939 from Arhell/fix-training update training page	2020-11-08 05:27:37 -08:00
Kubernetes Prow Robot	1d5ecc7af8	Merge pull request #24936 from ruiwen-zhao/qos Explicitly mention init containers in the QoS doc	2020-11-07 23:35:37 -08:00
Kubernetes Prow Robot	c56f45626e	Merge pull request #24934 from KoopaKing/patch-1 Fix formatting issue in Compute Resource Quota documentation	2020-11-07 21:13:37 -08:00
Kubernetes Prow Robot	ed5f42e51c	Merge pull request #24941 from timyinshi/pod-priority modify the error chinese word of how	2020-11-07 21:05:37 -08:00
Qiming Teng	4bf6c16cca	[zh] Sync changes to docs/concepts/policy/resource-quotas.md Also fixed a nit in English version.	2020-11-08 10:50:16 +08:00
Kubernetes Prow Robot	6bab17e19e	Merge pull request #24945 from okutasan/fix-typo-declarativeconfig fix typo file on declarative-config page	2020-11-07 02:57:36 -08:00
Kubernetes Prow Robot	52bc215c4c	Merge pull request #24944 from lanandra/lanandra_id_logging edit content/id/docs/concepts/cluster-administration/logging.md	2020-11-07 02:31:37 -08:00
okutasan	ea6cbc04a2	fix typo file on declarative-config page	2020-11-07 17:22:53 +07:00
lanandra	cd1ea0b666	edit content/id/docs/concepts/cluster-administration/logging.md change file to berkas at line 55	2020-11-07 17:19:15 +07:00
Kubernetes Prow Robot	95e8bc6341	Merge pull request #24943 from azemoning/fixtypo-imperativecommand fix typo on imperative-command page for Bahasa Indonesia	2020-11-07 01:53:37 -08:00
azemoning	d6106372b6	fix typo on imperative-command page	2020-11-07 16:21:16 +07:00
timyinshi	e34ca6b9d4	modify the chinese url Signed-off-by: timyinshi <shiguangyin@inspur.com>	2020-11-07 15:34:19 +08:00
timyinshi	bbe8f113bb	modify the error chinese word of how Signed-off-by: timyinshi <shiguangyin@inspur.com>	2020-11-07 15:15:53 +08:00
Kubernetes Prow Robot	abd6de3acf	Merge pull request #24924 from Arhell/upd-page add shortcode to training page	2020-11-06 19:51:37 -08:00
Arhell	685eceaf04	update training page	2020-11-07 02:31:45 +02:00
ruiwen-zhao	75456274f9	Explicitly mention init containers in the QoS doc	2020-11-06 19:19:38 +00:00
Chris Bowzer	975cf8c261	Fix formatting issue in Compute Resource Quota documentation	2020-11-06 10:52:47 -08:00
Adhityaa Chandrasekar	5ab1d974b5	flow control metrics: switch to snake_case for labels Signed-off-by: Adhityaa Chandrasekar <adtac@google.com>	2020-11-06 16:19:12 +00:00
Kubernetes Prow Robot	7716cd69d4	Merge pull request #24922 from nasa9084/update-sig-docs-ja-reviewers Update SIG-docs-ja reviewers	2020-11-06 07:10:51 -08:00
Arhell	5300d6d935	add shortcode to training page	2020-11-06 11:29:13 +02:00
nasa9084	fbc696808a	Update SIG-docs-ja reviewers	2020-11-06 15:25:54 +09:00
Kubernetes Prow Robot	7485a48ae6	Merge pull request #23142 from nishipy/issue23120 Translate concepts/cluster-administration/cloud-providers/ into Japanese	2020-11-05 21:20:50 -08:00
nishipy	20e450f515	Update content/ja/docs/concepts/cluster-administration/cloud-providers.md Co-authored-by: bells17 <bells171@gmail.com>	2020-11-06 13:16:50 +09:00
Kubernetes Prow Robot	4dc8145f28	Merge pull request #24887 from thockin/kep-1659-topology-trivial-non-english KEP 1659 topology: trivial non-English changes	2020-11-05 18:00:50 -08:00
Tim Hockin	7e7423a474	Make trivial non-en changes for KEP 1659 There are still some non-trivial changes that will need help. English was https://github.com/kubernetes/website/pull/24783	2020-11-05 16:54:01 -08:00
Eric Briand	cee9e620ca	Use different wording to not quote current version	2020-11-05 17:21:08 +01:00
Eric Briand	c869ef67a8	Update default admission plugins for 1.19	2020-11-04 09:56:20 +01:00
nishipy	0cc2b2a1df	Translate concepts/cluster-administration/cloud-providers/ into Japanese	2020-08-14 21:11:06 +09:00