Second Japanese l10n work for release-1.13 (#14465)

* Update k8s.io/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/ (#13153) * [ja] Translate Hello Minikube in tutorials (#13100) (#13161) * ja-trans: update supported-doc-versions.md (#13186) * [ja] Update /concepts/overview/what-is-kubernetes.md #13079 (#13187) * ja-trans: update expose-intro.html (#13215) * ja-trans: update expose-intro.html * ja-trans: fix broken links by linking to english pages * update deploy-intro.html (#13103) (#13208) * update deploy-intro.html (#13103) * Update content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html add /ja path Co-Authored-By: chidakiyo <chidakiyo@users.noreply.github.com> * [ja] Update /setup/release/building-from-source.md (#13095) (#13220) * ja-trans: update /ja/docs/setup/independent/control-plane-flags/ (#13228) * ja-trans: Update /setup/turnkey/azure.md (#13097) (#13224) * ja-trans: update /ja/docs/tutorials/kubernetes-basics/ (#13232) * ja-trans: update /ja/docs/tutorials/kubernetes-basics/ * ja-trans: translate card.title * ja-trans: update setup/minikube.md (#13091) (#13219) * [ja] Update content of setup/minikube.md, fixing the diff between 551489f 7b07d19. * [ja] Translate the content: content/ja/docs/setup/minikube.md (#13091) * Correct Katakana words, using long vowel words Co-Authored-By: yukinagae <yuki.nagae1130@gmail.com> * Fix typos Co-Authored-By: yukinagae <yuki.nagae1130@gmail.com> * Correct some changes, thanks for the FB Co-Authored-By: yukinagae <yuki.nagae1130@gmail.com> * ja-trans: Update k8s.io/ja/docs/setup/pick-right-solution/ (#13094) (#13328) * ja-trans: Update the content of setup/pick-right-solution.md, only fixing the diff between 551489f and 7b07d19. (Not yet translating the content at the moment to only make sure fixing the diff is ok. Next commit will be actually the translation stuff) * ja-trans: Translate /ja/docs/setup/pick-right-solution.md (#13094) * Update content/ja/docs/setup/pick-right-solution.md Correct small changes based on the feedback Co-Authored-By: yukinagae <yuki.nagae1130@gmail.com> * Better translation and refer the Japanese document link Co-Authored-By: yukinagae <yuki.nagae1130@gmail.com> * Correct Japanese anchors Co-Authored-By: yukinagae <yuki.nagae1130@gmail.com> * Correct translation mistakes Co-Authored-By: yukinagae <yuki.nagae1130@gmail.com> * ja: Translate /docs/home (#13366) * follow to the latest format * review * ja: fix some unnatural translation and formatting (#13367) * format * Update content/ja/docs/setup/certificates.md Co-Authored-By: inductor <kohei.ota@zozo.com> * ja-trans: Translate heading and subheading of docs/setup/version-skew-policy.md in Japanese (#13360) * copy content * remove reviewer block * Translate heading and subheading. * change translation * ja-trans: Translate heading and subheading of docs/setup/turnkey/icp.md in Japanese (#13359) * copy content * remove reviewer block * Translate heading and subheading. * ref. #13098 (#13358) * ref. #13096 (#13357) * ref. #13089 (#13353) * ref. #13087 (#13351) * ref. #13082 (#13348) * ref. #13085 (#13349) * ref. #13088 (#13352) * ref. #13090 (#13354) * ref. #13092 (#13355) * ref. #13093 (#13356) * ref. #13099 (#13361) * [ja] Translate the content: ja/docs/setup/independent/high-availability/ (#13364) * [ja] Translate the content: ja/docs/setup/independent/high-availability/ * remove redundant comma, words * Update content/ja/docs/setup/independent/high-availability.md 余分な文字を削除 Co-Authored-By: TSUDA-Kyosuke <tsuda@stmn.co.jp> * Update k8s.io/ja/docs/setup/cri/ (#13663) * fix content. * Update content/ja/docs/setup/cri.md Co-Authored-By: cstoku <cs.toku.mail@gmail.com> * Update cri.md * Update content/ja/docs/setup/cri.md Co-Authored-By: cstoku <cs.toku.mail@gmail.com> * Update content/ja/docs/setup/cri.md Co-Authored-By: cstoku <cs.toku.mail@gmail.com> * improve translation
2019-05-22 16:14:12 +02:00
parent 866b99cf72
commit bbf3a979d4
28 changed files with 998 additions and 506 deletions
@@ -2,6 +2,9 @@
 title: Kubernetesとは何か？
 content_template: templates/concept
 weight: 10
 card: 
  name: concepts
  weight: 10
 ---
 {{% capture overview %}}
@@ -1,11 +1,9 @@
 ---
 title: Kubernetesドキュメント
 layout: docsportal_home
 noedit: true
-cid: userJourneys
+cid: docsHome
-css: /css/style_user_journeys.css
+layout: docsportal_home
-js: /js/user-journeys/home.js, https://use.fontawesome.com/4bcc658a89.js
+class: gridPage
 display_browse_numbers: true
 linkTitle: "ホーム"
 main_menu: true
 weight: 10
@@ -16,4 +14,43 @@ menu:
    weight: 20
    post: >
      <p>チュートリアル、サンプルやドキュメントのリファレンスを使って Kubernetes の利用方法を学んでください。あなたは<a href="/editdocs/" data-auto-burger-exclude>ドキュメントへコントリビュートをする</a>こともできます!</p>
 overview: >
  Kubernetesは、自動デプロイ、スケーリング、およびコンテナ化されたアプリケーションの管理を行うための、オープンソースのコンテナオーケストレーションエンジンです。本オープンソースプロジェクトは、Cloud Native Computing Foundation (<a href="https://www.cncf.io/about">CNCF</a>).によって管理されています。
 cards:
 - name: concepts
  title: "基本を理解する"
  description: "Kubernetesに基本的なコンセプトについて学びます。"
  button: "コンセプトを学ぶ"
  button_path: "/ja/docs/concepts"
 - name: tutorials
  title: "Kubernetesを試用する"
  description: "チュートリアルに沿って、Kubernetesにアプリケーションをデプロイする方法を学びます。"
  button: "チュートリアルを見る"
  button_path: "/ja/docs/tutorials"
 - name: setup
  title: "クラスターを立ち上げる"
  description: "ご自身のリソースや要件に合わせたKubernetes環境を動かしてみましょう。"
  button: "Kubernetesをセットアップする"
  button_path: "/ja/docs/setup"
 - name: tasks
  title: "Kubernetesの使い方を学ぶ"
  description: "一般的な使い方と、それらを実行するための短い手順を調べます。"
  button: "View Tasks"
  button_path: "/ja/docs/tasks"
 - name: reference
  title: 参考情報を探す
  description: 用語、コマンドラインの構文、APIのリソースタイプ、およびセットアップツールのドキュメントを参照します。
  button: View Reference
  button_path: /ja/docs/reference
 - name: contribute
  title: ドキュメントに貢献する
  description: 本プロジェクトに不慣れな方でも、久しぶりの方も、どなたでも貢献することができます。
  button: ドキュメントに貢献する
  button_path: /ja/docs/contribute
 - name: download
  title: Kubernetesをダウンロードする
  description: Kubernetesをインストールする場合や最新バージョンにアップグレードする場合は、現在のリリースノートを参照してください。
 - name: about
  title: ドキュメントについて
  description: このWebサイトには、Kubernetesの現在および以前の4つのバージョンに関するドキュメントが含まれています。
 ---
@@ -1,6 +1,10 @@
 ---
 title: Kubernetesドキュメントがサポートしているバージョン
 content_template: templates/concept
 card:
  name: about
  weight: 10
  title: ドキュメントがサポートしているバージョン
 ---
 {{% capture overview %}}
@@ -14,7 +14,7 @@ This page explains the certificates that your cluster requires.
 {{% capture body %}}
-## あなたのクラスタではどのように証明書が使われているのか
+## クラスタではどのように証明書が使われているのか
 Kubernetes requires PKI for the following operations:
@@ -85,14 +85,15 @@ Certificates should be placed in a recommended path (as used by [kubeadm][kubead
 | Default CN                   | recommend key path           | recommended cert path       | command        | key argument                 | cert argument                             |
 |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
 | etcd-ca                      |                              | etcd/ca.crt                 | kube-apiserver |                              | --etcd-cafile                             |
-| etcd-client                  | apiserver-etcd-client.crt    | apiserver-etcd-client.crt   | kube-apiserver | --etcd-certfile              | --etcd-keyfile                            |
+| etcd-client                  | apiserver-etcd-client.key    | apiserver-etcd-client.crt   | kube-apiserver | --etcd-keyfile               | --etcd-certfile                           |
-| kubernetes-ca                |                              | ca.crt                      | kube-apiserver | --client-ca-file             |                                           |
+| kubernetes-ca                |                              | ca.crt                      | kube-apiserver |                              | --client-ca-file                          |
-| kube-apiserver               | apiserver.crt                | apiserver.key               | kube-apiserver | --tls-cert-file              | --tls-private-key                         |
+| kube-apiserver               | apiserver.key                | apiserver.crt               | kube-apiserver | --tls-private-key-file       | --tls-cert-file                           |
-| apiserver-kubelet-client     | apiserver-kubelet-client.crt |                             | kube-apiserver | --kubelet-client-certificate |                                           |
+| apiserver-kubelet-client     |                              | apiserver-kubelet-client.crt| kube-apiserver |                              | --kubelet-client-certificate              |
-| front-proxy-client           | front-proxy-client.key       | front-proxy-client.crt      | kube-apiserver | --proxy-client-cert-file     | --proxy-client-key-file                   |
+| front-proxy-ca               |                              | front-proxy-ca.crt          | kube-apiserver |                              | --requestheader-client-ca-file            |
 | front-proxy-client           | front-proxy-client.key       | front-proxy-client.crt      | kube-apiserver | --proxy-client-key-file      | --proxy-client-cert-file                  |
 |                              |                              |                             |                |                              |                                           |
 | etcd-ca                      |                              | etcd/ca.crt                 | etcd           |                              | --trusted-ca-file, --peer-trusted-ca-file |
-| kube-etcd                    |                              | etcd/server.crt             | etcd           |                              | --cert-file                               |
+| kube-etcd                    | etcd/server.key              | etcd/server.crt             | etcd           | --key-file                   | --cert-file                               |
 | kube-etcd-peer               | etcd/peer.key                | etcd/peer.crt               | etcd           | --peer-key-file              | --peer-cert-file                          |
 | etcd-ca                      |                              | etcd/ca.crt                 | etcdctl[2]     |                              | --cacert                                  |
 | kube-etcd-healthcheck-client | etcd/healthcheck-client.key  | etcd/healthcheck-client.crt | etcdctl[2]     | --key                        | --cert                                    |
@@ -106,10 +107,14 @@ You must manually configure these administrator account and service accounts:
 | filename                | credential name            | Default CN                     | O (in Subject) |
 |-------------------------|----------------------------|--------------------------------|----------------|
 | admin.conf              | default-admin              | kubernetes-admin               | system:masters |
-| kubelet.conf            | default-auth               | system:node:`<nodename>`        | system:nodes   |
+| kubelet.conf            | default-auth               | system:node:`<nodeName>` (see note) | system:nodes   |
 | controller-manager.conf | default-controller-manager | system:kube-controller-manager |                |
 | scheduler.conf          | default-manager            | system:kube-scheduler          |                |
 {{< note >}}
 The value of `<nodeName>` for `kubelet.conf` **must** match precisely the value of the node name provided by the kubelet as it registers with the apiserver. For further details, read the [Node Authorization](/docs/reference/access-authn-authz/node/).
 {{< /note >}}
 1. For each config, generate an x509 cert/key pair with the given CN and O.
 1. Run `kubectl` as follows for each config:
@@ -4,48 +4,83 @@ content_template: templates/concept
 weight: 100
 ---
 {{% capture overview %}}
-Kubernetesでは、v1.6.0からデフォルトでCRI(Container Runtime Interface)を利用できます。
+{{< feature-state for_k8s_version="v1.6" state="stable" >}}
-このページでは、様々なCRIのインストール方法について説明します。
+Podのコンテナを実行するために、Kubernetesはコンテナランタイムを使用します。
 様々なランタイムのインストール手順は次のとおりです。
 {{% /capture %}}
 {{% capture body %}}
-手順を進めるにあたっては、下記に示しているコマンドを、ご利用のOSのものに従ってrootユーザとして実行してください。
+
-環境によっては、それぞれのホストへSSHで接続した後に`sudo -i`を実行することで、rootユーザになることができる場合があります。
+{{< caution >}}
 コンテナ実行時にruncがシステムファイルディスクリプターを扱える脆弱性が見つかりました。
 悪意のあるコンテナがこの脆弱性を利用してruncのバイナリを上書きし、
 コンテナホストシステム上で任意のコマンドを実行する可能性があります。
 この問題の更なる情報は以下のリンクを参照してください。
 [cve-2019-5736 : runc vulnerability](https://access.redhat.com/security/cve/cve-2019-5736)
 {{< /caution >}}
 ### 適用性
 {{< note >}}
 このドキュメントはLinuxにCRIをインストールするユーザーの為に書かれています。
 他のオペレーティングシステムの場合、プラットフォーム固有のドキュメントを見つけてください。
 {{< /note >}}
 このガイドでは全てのコマンドを `root` で実行します。
 例として、コマンドに `sudo` を付けたり、 `root` になってそのユーザーでコマンドを実行します。
 ### Cgroupドライバー
 systemdがLinuxのディストリビューションのinitシステムとして選択されている場合、
 initプロセスが作成され、rootコントロールグループ(`cgroup`)を使い、cgroupマネージャーとして行動します。
 systemdはcgroupと密接に統合されており、プロセスごとにcgroupを割り当てます。
 `cgroupfs` を使うように、あなたのコンテナランライムとkubeletを設定することができます。
 systemdと一緒に `cgroupfs` を使用するということは、2つの異なるcgroupマネージャーがあることを意味します。
 コントロールグループはプロセスに割り当てられるリソースを制御するために使用されます。
 単一のcgroupマネージャーは、割り当てられているリソースのビューを単純化し、
 デフォルトでは使用可能なリソースと使用中のリソースについてより一貫性のあるビューになります。
 2つのマネージャーがある場合、それらのリソースについて2つのビューが得られます。
 kubeletとDockerに `cgroupfs` を使用し、ノード上で実行されている残りのプロセスに `systemd` を使用するように設定されたノードが、
 リソース圧迫下で不安定になる場合があります。
 あなたのコンテナランタイムとkubeletにcgroupドライバーとしてsystemdを使用するように設定を変更することはシステムを安定させました。
 以下のDocker設定の `native.cgroupdriver=systemd` オプションに注意してください。
 ## Docker
 それぞれのマシンに対してDockerをインストールします。
-バージョン18.06が推奨されていますが、1.11、1.12、1.13、17.03についても動作が確認されています。
+バージョン18.06.2が推奨されていますが、1.11、1.12、1.13、17.03、18.09についても動作が確認されています。
 Kubernetesのリリースノートにある、Dockerの動作確認済み最新バージョンについてもご確認ください。
 システムへDockerをインストールするには、次のコマンドを実行します。
 {{< tabs name="tab-cri-docker-installation" >}}
 {{< tab name="Ubuntu 16.04" codelang="bash" >}}
-# UbuntuのリポジトリからDockerをインストールする場合は次を実行します:
+# Docker CEのインストール
 ## リポジトリをセットアップ
 ### aptパッケージインデックスを更新
    apt-get update
 apt-get install -y docker.io
-# または、UbuntuやDebian向けのDockerのリポジトリからDocker CE 18.06をインストールする場合は、次を実行します:
+### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール
 ## 必要なパッケージをインストールします。
    apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common
-## GPGキーをダウンロードします。
+### Docker公式のGPG鍵を追加
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
-## dockerパッケージ用のaptリポジトリを追加します。
+### dockerのaptリポジトリを追加
    add-apt-repository \
    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
    $(lsb_release -cs) \
    stable"
-## dockerをインストールします。
+## docker ceのインストール
-apt-get update && apt-get install docker-ce=18.06.0~ce~3-0~ubuntu
+apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu
-# デーモンをセットアップします。
+# デーモンをセットアップ
 cat > /etc/docker/daemon.json <<EOF
 {
  "exec-opts": ["native.cgroupdriver=systemd"],
@@ -59,32 +94,29 @@ EOF
 mkdir -p /etc/systemd/system/docker.service.d
-# dockerを再起動します。
+# dockerを再起動
 systemctl daemon-reload
 systemctl restart docker
 {{< /tab >}}
 {{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
-# CentOSやRHELのリポジトリからDockerをインストールする場合は、次を実行します:
+# Docker CEのインストール
-yum install -y docker
+## リポジトリをセットアップ
-
+### 必要なパッケージのインストール
 # または、CentOS向けのDockerのリポジトリからDocker CE 18.06をインストールする場合は、次を実行します:
 ## 必要なパッケージをインストールします。
    yum install yum-utils device-mapper-persistent-data lvm2
-## dockerパッケージ用のyumリポジトリを追加します。
+### dockerパッケージ用のyumリポジトリを追加
 yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo
-## dockerをインストールします。
+## docker ceのインストール
-yum update && yum install docker-ce-18.06.1.ce
+yum update && yum install docker-ce-18.06.2.ce
-## /etc/docker ディレクトリを作成します。
+## /etc/docker ディレクトリを作成
 mkdir /etc/docker
-# デーモンをセットアップします。
+# デーモンをセットアップ
 cat > /etc/docker/daemon.json <<EOF
 {
  "exec-opts": ["native.cgroupdriver=systemd"],
@@ -101,7 +133,7 @@ EOF
 mkdir -p /etc/systemd/system/docker.service.d
-# dockerを再起動します。
+# dockerを再起動
 systemctl daemon-reload
 systemctl restart docker
 {{< /tab >}}
@@ -217,8 +249,8 @@ tar --no-overwrite-dir -C / -xzf cri-containerd-${CONTAINERD_VERSION}.linux-amd6
 systemctl start containerd
 ```
-## その他のCRIランタイム(rktletおよびfrakti)について
+## その他のCRIランタイム: frakti
-詳細については[Fraktiのクイックスタートガイド](https://github.com/kubernetes/frakti#quickstart)および[Rktletのクイックスタートガイド](https://github.com/kubernetes-incubator/rktlet/blob/master/docs/getting-started-guide.md)を参照してください。
+詳細については[Fraktiのクイックスタートガイド](https://github.com/kubernetes/frakti#quickstart)を参照してください。
 {{% /capture %}}
@@ -6,6 +6,8 @@ weight: 40
 {{% capture overview %}}
 {{< feature-state for_k8s_version="1.12" state="stable" >}}
 kubeadmの`ClusterConfiguration`オブジェクトはAPIServer、ControllerManager、およびSchedulerのようなコントロールプレーンの構成要素に渡されたデフォルトのフラグを上書きすることができる `extraArgs`の項目があります。
 その構成要素は次の項目で定義されています。
@@ -151,39 +151,56 @@ The output should look like:
 ```none
 [init] Using Kubernetes version: vX.Y.Z
 [preflight] Running pre-flight checks
-[kubeadm] WARNING: starting in 1.8, tokens expire after 24 hours by default (if you require a non-expiring token use --token-ttl 0)
+[preflight] Pulling images required for setting up a Kubernetes cluster
-[certificates] Generated ca certificate and key.
+[preflight] This might take a minute or two, depending on the speed of your internet connection
-[certificates] Generated apiserver certificate and key.
+[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
-[certificates] apiserver serving cert is signed for DNS names [kubeadm-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.138.0.4]
+[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
-[certificates] Generated apiserver-kubelet-client certificate and key.
+[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
-[certificates] Generated sa key and public key.
+[kubelet-start] Activating the kubelet service
-[certificates] Generated front-proxy-ca certificate and key.
+[certs] Using certificateDir folder "/etc/kubernetes/pki"
-[certificates] Generated front-proxy-client certificate and key.
+[certs] Generating "etcd/ca" certificate and key
-[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
+[certs] Generating "etcd/server" certificate and key
-[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
+[certs] etcd/server serving cert is signed for DNS names [kubeadm-master localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
-[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
+[certs] Generating "etcd/healthcheck-client" certificate and key
-[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
+[certs] Generating "etcd/peer" certificate and key
-[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"
+[certs] etcd/peer serving cert is signed for DNS names [kubeadm-master localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
-[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
+[certs] Generating "apiserver-etcd-client" certificate and key
-[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
+[certs] Generating "ca" certificate and key
-[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
+[certs] Generating "apiserver" certificate and key
-[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
+[certs] apiserver serving cert is signed for DNS names [kubeadm-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.138.0.4]
-[init] Waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
+[certs] Generating "apiserver-kubelet-client" certificate and key
-[init] This often takes around a minute; or longer if the control plane images have to be pulled.
+[certs] Generating "front-proxy-ca" certificate and key
-[apiclient] All control plane components are healthy after 39.511972 seconds
+[certs] Generating "front-proxy-client" certificate and key
-[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
+[certs] Generating "sa" key and public key
-[markmaster] Will mark node master as master by adding a label and a taint
+[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
-[markmaster] Master master tainted and labelled with key/value: node-role.kubernetes.io/master=""
+[kubeconfig] Writing "admin.conf" kubeconfig file
-[bootstraptoken] Using token: <token>
+[kubeconfig] Writing "kubelet.conf" kubeconfig file
-[bootstraptoken] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
+[kubeconfig] Writing "controller-manager.conf" kubeconfig file
-[bootstraptoken] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
+[kubeconfig] Writing "scheduler.conf" kubeconfig file
-[bootstraptoken] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
+[control-plane] Using manifest folder "/etc/kubernetes/manifests"
 [control-plane] Creating static Pod manifest for "kube-apiserver"
 [control-plane] Creating static Pod manifest for "kube-controller-manager"
 [control-plane] Creating static Pod manifest for "kube-scheduler"
 [etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
 [wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
 [apiclient] All control plane components are healthy after 31.501735 seconds
 [uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
 [kubelet] Creating a ConfigMap "kubelet-config-X.Y" in namespace kube-system with the configuration for the kubelets in the cluster
 [patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "kubeadm-master" as an annotation
 [mark-control-plane] Marking the node kubeadm-master as control-plane by adding the label "node-role.kubernetes.io/master=''"
 [mark-control-plane] Marking the node kubeadm-master as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
 [bootstrap-token] Using token: <token>
 [bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
 [bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
 [bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
 [bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
 [bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
 [addons] Applied essential addon: CoreDNS
 [addons] Applied essential addon: kube-proxy
 Your Kubernetes master has initialized successfully!
-To start using your cluster, you need to run (as a regular user):
+To start using your cluster, you need to run the following as a regular user:
  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
@@ -196,7 +213,7 @@ Run "kubectl apply -f [podnetwork].yaml" with one of the addon options listed at
 You can now join any number of machines by running the following on each node
 as root:
-  kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>
+  kubeadm join <master-ip>:<master-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>
 ```
 To make kubectl work for your non-root user, run these commands, which are
@@ -262,7 +279,7 @@ Please select one of the tabs to see installation instructions for the respectiv
 {{% tab name="Calico" %}}
 For more information about using Calico, see [Quickstart for Calico on Kubernetes](https://docs.projectcalico.org/latest/getting-started/kubernetes/), [Installing Calico for policy and networking](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/calico), and other related resources.
-For Calico to work correctly, you need to pass `--pod-network-cidr=192.168.0.0/16` to `kubeadm init` or update the `calico.yml` file to match your Pod network. Note that Calico works on `amd64` only.
+For Calico to work correctly, you need to pass `--pod-network-cidr=192.168.0.0/16` to `kubeadm init` or update the `calico.yml` file to match your Pod network. Note that Calico works on `amd64`, `arm64`, and `ppc64le` only.
 ```shell
 kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml
@@ -283,31 +300,30 @@ kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/
 {{% /tab %}}
 {{% tab name="Cilium" %}}
-For more information about using Cilium with Kubernetes, see [Quickstart for Cilium on Kubernetes](http://docs.cilium.io/en/v1.2/kubernetes/quickinstall/) and [Kubernetes Install guide for Cilium](http://docs.cilium.io/en/v1.2/kubernetes/install/).
+For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/).
 Passing `--pod-network-cidr` option to `kubeadm init` is not required, but highly recommended.
 These commands will deploy Cilium with its own etcd managed by etcd operator.
 _Note_: If you are running kubeadm in a single node please untaint it so that
 etcd-operator pods can be scheduled in the control-plane node.
 ```shell
-# Download required manifests from Cilium repository
+kubectl taint nodes <node-name> node-role.kubernetes.io/master:NoSchedule-
 wget https://github.com/cilium/cilium/archive/v1.2.0.zip
 unzip v1.2.0.zip
 cd cilium-1.2.0/examples/kubernetes/addons/etcd-operator
 # Generate and deploy etcd certificates
 export CLUSTER_DOMAIN=$(kubectl get ConfigMap --namespace kube-system coredns -o yaml | awk '/kubernetes/ {print $2}')
 tls/certs/gen-cert.sh $CLUSTER_DOMAIN
 tls/deploy-certs.sh
 # Label kube-dns with fixed identity label
 kubectl label -n kube-system pod $(kubectl -n kube-system get pods -l k8s-app=kube-dns -o jsonpath='{range .items[]}{.metadata.name}{" "}{end}') io.cilium.fixed-identity=kube-dns
 kubectl create -f ./
 # Wait several minutes for Cilium, coredns and etcd pods to converge to a working state
 ```
 To deploy Cilium you just need to run:
 ```shell
 kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.4/examples/kubernetes/1.13/cilium.yaml
 ```
 Once all Cilium pods are marked as `READY`, you start using your cluster.
 ```shell
 $ kubectl get pods -n kube-system --selector=k8s-app=cilium
 NAME           READY   STATUS    RESTARTS   AGE
 cilium-drxkl   1/1     Running   0          18m
 ```
 {{% /tab %}}
 {{% tab name="Flannel" %}}
@@ -318,10 +334,11 @@ Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net
 to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
 please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
-Note that `flannel` works on `amd64`, `arm`, `arm64` and `ppc64le`.
+Note that `flannel` works on `amd64`, `arm`, `arm64`, `ppc64le` and `s390x` under Linux.
 Windows (`amd64`) is claimed as supported in v0.11.0 but the usage is undocumented.
 ```shell
-kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
+kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml
 ```
 For more information about `flannel`, see [the CoreOS flannel repository on GitHub
@@ -379,6 +396,16 @@ There are multiple, flexible ways to install JuniperContrail/TungstenFabric CNI.
 Kindly refer to this quickstart: [TungstenFabric](https://tungstenfabric.github.io/website/)
 {{% /tab %}}
 {{% tab name="Contiv-VPP" %}}
 [Contiv-VPP](https://contivpp.io/) employs a programmable CNF vSwitch based on [FD.io VPP](https://fd.io/),
 offering feature-rich & high-performance cloud-native networking and services.
 It implements k8s services and network policies in the user space (on VPP).
 Please refer to this installation guide: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md)
 {{% /tab %}}
 {{< /tabs >}}
@@ -543,6 +570,18 @@ Then, on the node being removed, reset all kubeadm installed state:
 kubeadm reset
 ```
 The reset process does not reset or clean up iptables rules or IPVS tables. If you wish to reset iptables, you must do so manually:
 ```bash
 iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X
 ```
 If you want to reset the IPVS tables, you must run the following command:
 ```bash
 ipvsadm -C
 ```
 If you wish to start over simply run `kubeadm init` or `kubeadm join` with the
 appropriate arguments.
@@ -587,8 +626,10 @@ Due to that we can't see into the future, kubeadm CLI vX.Y may or may not be abl
 Example: kubeadm v1.8 can deploy both v1.7 and v1.8 clusters and upgrade v1.7 kubeadm-created clusters to
 v1.8.
-Please also check our [installation guide](/docs/setup/independent/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
+These resources provide more information on supported version skew between kubelets and the control plane, and other Kubernetes components:
-for more information on the version skew between kubelets and the control plane.
+
 * Kubernetes [version and version-skew policy](/docs/setup/version-skew-policy/)
 * Kubeadm-specific [installation guide](/docs/setup/independent/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
 ## kubeadmは様々なプラットフォームで動く
@@ -6,58 +6,42 @@ weight: 60
 {{% capture overview %}}
-This page explains two different approaches to setting up a highly available Kubernetes
+このページでは、kubeadmを使用して、高可用性クラスターを作成する、2つの異なるアプローチを説明します:
 cluster using kubeadm:
- With stacked control plane nodes. This approach requires less infrastructure. The etcd members
+- 積み重なったコントロールプレーンノードを使う方法。こちらのアプローチは、必要なインフラストラクチャーが少ないです。etcdのメンバーと、コントロールプレーンノードは同じ場所に置かれます。
-and control plane nodes are co-located.
+- 外部のetcdクラスターを使う方法。こちらのアプローチには、より多くのインフラストラクチャーが必要です。コントロールプレーンノードと、etcdのメンバーは分離されます。
 - With an external etcd cluster. This approach requires more infrastructure. The
 control plane nodes and etcd members are separated.
-Before proceeding, you should carefully consideer which approach best meets the needs of your applications
+先へ進む前に、どちらのアプローチがアプリケーションの要件と、環境に適合するか、慎重に検討してください。[こちらの比較](/docs/setup/independent/ha-topology/)が、それぞれの利点/欠点について概説しています。
 and environment. [This comparison topic](/docs/setup/independent/ha-topology/) outlines the advantages and disadvantages of each.
-Your clusters must run Kubernetes version 1.12 or later. You should also be aware that
+クラスターではKubernetesのバージョン1.12以降を使用する必要があります。また、kubeadmを使用した高可用性クラスターはまだ実験的な段階であり、将来のバージョンではもっとシンプルになることに注意してください。たとえば、クラスターのアップグレードに際し問題に遭遇するかもしれません。両方のアプローチを試し、kueadmの[issue tracker](https://github.com/kubernetes/kubeadm/issues/new)で我々にフィードバックを提供してくれることを推奨します。
 setting up HA clusters with kubeadm is still experimental and will be further simplified
 in future versions. You might encounter issues with upgrading your clusters, for example.
 We encourage you to try either approach, and provide us with feedback in the kubeadm
 [issue tracker](https://github.com/kubernetes/kubeadm/issues/new).
-Note that the alpha feature gate `HighAvailability` is deprecated in v1.12 and removed in v1.13.
+alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.13で削除されたことに留意してください。
-See also [The HA upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha).
+[高可用性クラスターのアップグレード](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-13)も参照してください。
 {{< caution >}}
-This page does not address running your cluster on a cloud provider. In a cloud
+このページはクラウド上でクラスターを構築することには対応していません。ここで説明されているどちらのアプローチも、クラウド上で、LoadBalancerタイプのServiceオブジェクトや、動的なPersistentVolumeを利用して動かすことはできません。
 environment, neither approach documented here works with Service objects of type
 LoadBalancer, or with dynamic PersistentVolumes.
 {{< /caution >}}
 {{% /capture %}}
 {{% capture prerequisites %}}
-For both methods you need this infrastructure:
+どちらの方法でも、以下のインフラストラクチャーが必要です:
- Three machines that meet [kubeadm's minimum
+- master用に、[kubeadmの最小要件](/ja/docs/setup/independent/install-kubeadm/#before-you-begin)を満たす3台のマシン
-  requirements](/docs/setup/independent/install-kubeadm/#before-you-begin) for
+- worker用に、[kubeadmの最小要件](/ja/docs/setup/independent/install-kubeadm/#before-you-begin)を満たす3台のマシン
-  the masters
+- クラスター内のすべてのマシン間がフルにネットワーク接続可能であること(パブリック、もしくはプライベートネットワーク)
- Three machines that meet [kubeadm's minimum
+- すべてのマシンにおいて、sudo権限
-  requirements](/docs/setup/independent/install-kubeadm/#before-you-begin) for
+- あるデバイスから、システム内のすべてのノードに対しSSH接続できること
-  the workers
+- `kubeadm`と`kubelet`がすべてのマシンにインストールされていること。 `kubectl`は任意です。
 - Full network connectivity between all machines in the cluster (public or
  private network)
 - sudo privileges on all machines
 - SSH access from one device to all nodes in the system
 - `kubeadm` and `kubelet` installed on all machines. `kubectl` is optional.
-For the external etcd cluster only, you also need:
+外部etcdクラスターには、以下も必要です:
- Three additional machines for etcd members
+- etcdメンバー用に、追加で3台のマシン
 {{< note >}}
-The following examples run Calico as the Pod networking provider. If you run another
+以下の例では、CalicoをPodネットワーキングプロバイダーとして使用します。別のネットワーキングプロバイダーを使用する場合、必要に応じてデフォルトの値を変更してください。
 networking provider, make sure to replace any default values as needed.
 {{< /note >}}
 {{% /capture %}}
@@ -67,83 +51,63 @@ networking provider, make sure to replace any default values as needed.
 ## 両手順における最初のステップ
 {{< note >}}
-**Note**: All commands on any control plane or etcd node should be
+コントロールプレーンや、etcdノードでのコマンドはすべてrootとして実行してください。
 run as root.
 {{< /note >}}
- Some CNI network plugins like Calico require a CIDR such as `192.168.0.0/16` and
+- CalicoなどのいくつかのCNIネットワークプラグインは`192.168.0.0/16`のようなCIDRを必要としますが、Weaveなどは必要としません。[CNIネットワークドキュメント](/ja/docs/setup/independent/create-cluster-kubeadm/#pod-network)を参照してください。PodにCIDRを設定するには、`ClusterConfiguration`の`networking`オブジェクトに`podSubnet: 192.168.0.0/16`フィールドを設定してください。
  some like Weave do not. See the see [the CNI network
  documentation](/docs/setup/independent/create-cluster-kubeadm/#pod-network).
  To add a pod CIDR set the `podSubnet: 192.168.0.0/16` field under
  the `networking` object of `ClusterConfiguration`.
 ### kube-apiserver用にロードバランサーを作成
 {{< note >}}
-There are many configurations for load balancers. The following example is only one
+ロードバランサーには多くの設定項目があります。以下の例は、一選択肢に過ぎません。あなたのクラスター要件には、異なった設定が必要かもしれません。
 option. Your cluster requirements may need a different configuration.
 {{< /note >}}
-1.  Create a kube-apiserver load balancer with a name that resolves to DNS.
+1.  DNSで解決される名前で、kube-apiserver用ロードバランサーを作成する。
    - クラウド環境では、コントロールプレーンノードをTCPフォワーディングロードバランサーの後ろに置かなければなりません。このロードバランサーはターゲットリストに含まれる、すべての健全なコントロールプレーンノードにトラフィックを分配します。apiserverへのヘルスチェックはkube-apiserverがリッスンするポート(デフォルト値: `:6443`)に対する、TCPチェックです。
-    - In a cloud environment you should place your control plane nodes behind a TCP
+    - クラウド環境では、IPアドレスを直接使うことは推奨されません。
      forwarding load balancer. This load balancer distributes traffic to all
      healthy control plane nodes in its target list. The health check for
      an apiserver is a TCP check on the port the kube-apiserver listens on
      (default value `:6443`).
-    - It is not recommended to use an IP address directly in a cloud environment.
+    - ロードバランサーは、apiserverポートで、全てのコントロールプレーンノードと通信できなければなりません。また、リスニングポートに対する流入トラフィックも許可されていなければなりません。
-    - The load balancer must be able to communicate with all control plane nodes
+    - [HAProxy](http://www.haproxy.org/)をロードバランサーとして使用することができます。
      on the apiserver port. It must also allow incoming traffic on its
      listening port.
-    - [HAProxy](http://www.haproxy.org/) can be used as a load balancer.
+    - ロードバランサーのアドレスは、常にkubeadmの`ControlPlaneEndpoint`のアドレスと一致することを確認してください。
-    - Make sure the address of the load balancer always matches
+1.  ロードバランサーに、最初のコントロールプレーンノードを追加し、接続をテストする:
      the address of kubeadm's `ControlPlaneEndpoint`.
 1.  Add the first control plane nodes to the load balancer and test the
    connection:
    ```sh
    nc -v LOAD_BALANCER_IP PORT
    ```
-    - A connection refused error is expected because the apiserver is not yet
+    - apiserverはまだ動いていないので、接続の拒否は想定通りです。しかし、タイムアウトしたのであれば、ロードバランサーはコントロールプレーンノードと通信できなかったことを意味します。もし、タイムアウトが起きたら、コントロールプレーンノードと通信できるように、ロードバランサーを再設定してください。
      running. A timeout, however, means the load balancer cannot communicate
      with the control plane node. If a timeout occurs, reconfigure the load
      balancer to communicate with the control plane node.
-1.  Add the remaining control plane nodes to the load balancer target group.
+1.  残りのコントロールプレーンノードを、ロードバランサーのターゲットグループに追加します。
 ### SSHの設定
-SSH is required if you want to control all nodes from a single machine.
+1台のマシンから全てのノードをコントロールしたいのであれば、SSHが必要です。
-1.  Enable ssh-agent on your main device that has access to all other nodes in
+1.  システム内の全ての他のノードにアクセスできるメインデバイスで、ssh-agentを有効にします
    the system:
    ```
    eval $(ssh-agent)
    ```
-1.  Add your SSH identity to the session:
+1.  SSHの秘密鍵を、セッションに追加します:
    ```
    ssh-add ~/.ssh/path_to_private_key
    ```
-1.  SSH between nodes to check that the connection is working correctly.
+1.  正常に接続できることを確認するために、ノード間でSSHします。
-    - When you SSH to any node, make sure to add the `-A` flag:
+    - ノードにSSHする際は、必ず`-A`フラグをつけます:
        ```
        ssh -A 10.0.0.7
        ```
-    - When using sudo on any node, make sure to preserve the environment so SSH
+    - ノードでsudoするときは、SSHフォワーディングが動くように、環境変数を引き継ぎます:
      forwarding works:
        ```
        sudo -E -s
@@ -153,7 +117,7 @@ SSH is required if you want to control all nodes from a single machine.
 ### 最初のコントロールプレーンノードの手順
-1.  On the first control plane node, create a configuration file called `kubeadm-config.yaml`:
+1.  最初のコントロールプレーンノードで、`kubeadm-config.yaml`という設定ファイルを作成します:
        apiVersion: kubeadm.k8s.io/v1beta1
        kind: ClusterConfiguration
@@ -163,18 +127,17 @@ SSH is required if you want to control all nodes from a single machine.
          - "LOAD_BALANCER_DNS"
        controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
-    - `kubernetesVersion` should be set to the Kubernetes version to use. This
+    - `kubernetesVersion`には使用するKubernetesのバージョンを設定します。この例では`stable`を使用しています。
-  example uses `stable`.
+    - `controlPlaneEndpoint` はロードバランサーのアドレスかDNSと、ポートに一致する必要があります。
-    - `controlPlaneEndpoint` should match the address or DNS and port of the load balancer.
+    - kubeadm、kubelet、kubectlとKubernetesのバージョンを一致させることが推奨されます。
    - It's recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match.
-1.  Make sure that the node is in a clean state:
+1.  ノードがきれいな状態であることを確認します:
    ```sh
    sudo kubeadm init --config=kubeadm-config.yaml
    ```
-    You should see something like:
+    このような出力がされます:
    ```sh
    ...
@@ -184,29 +147,27 @@ SSH is required if you want to control all nodes from a single machine.
    kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash    sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f
    ```
-1.  Copy this output to a text file. You will need it later to join other control plane nodes to the
+1.  この出力をテキストファイルにコピーします。あとで、他のコントロールプレーンノードをクラスターに参加させる際に必要になります。
    cluster.
-1.  Apply the Weave CNI plugin:
+1.  Weave CNIプラグインをapplyします:
    ```sh
    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
    ```
-1.  Type the following and watch the pods of the components get started:
+1.  以下のコマンドを入力し、コンポーネントのPodが起動するのを確認します:
    ```sh
    kubectl get pod -n kube-system -w
    ```
-    - It's recommended that you join new control plane nodes only after the first node has finished initializing.
+    - 最初のコントロールプレーンノードが初期化を完了してから、新しいノードを参加させることが推奨されます。
-1.  Copy the certificate files from the first control plane node to the rest:
+1.  証明書ファイルを最初のコントロールプレーンノードから残りのノードにコピーします:
-    In the following example, replace `CONTROL_PLANE_IPS` with the IP addresses of the
+    以下の例では、`CONTROL_PLANE_IPS`を他のコントロールプレーンノードのIPアドレスで置き換えます。
    other control plane nodes.
    ```sh
-    USER=ubuntu # customizable
+    USER=ubuntu # 変更可能
    CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
    for host in ${CONTROL_PLANE_IPS}; do
        scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
@@ -221,12 +182,16 @@ SSH is required if you want to control all nodes from a single machine.
    done
    ```
 {{< caution >}}
 上のリストにある証明書だけをコピーしてください。kubeadmが、参加するコントロールプレーンノード用に、残りの証明書と必要なSANの生成を行います。間違って全ての証明書をコピーしてしまったら、必要なSANがないため、追加ノードの作成は失敗するかもしれません。
 {{< /caution >}}
 ### 残りのコントロールプレーンノードの手順
-1.  Move the files created by the previous step where `scp` was used:
+1.  `scp`を使用する手順で作成したファイルを移動します:
    ```sh
-    USER=ubuntu # customizable
+    USER=ubuntu # 変更可能
    mkdir -p /etc/kubernetes/pki/etcd
    mv /home/${USER}/ca.crt /etc/kubernetes/pki/
    mv /home/${USER}/ca.key /etc/kubernetes/pki/
@@ -239,36 +204,32 @@ SSH is required if you want to control all nodes from a single machine.
    mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf
    ```
-    This process writes all the requested files in the `/etc/kubernetes` folder.
+    この手順で、`/etc/kubernetes`フォルダーに必要な全てのファイルが書き込まれます。
-1.  Start `kubeadm join` on this node using the join command that was previously given to you by `kubeadm init` on
+1.  `kubeadm init`を最初のノードで実行した際に取得したjoinコマンドを使って、このノードで`kubeadm join`を開始します。このようなコマンドになるはずです:
    the first node. It should look something like this:
    ```sh
    sudo kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f --experimental-control-plane
    ```
    - `--experimental-control-plane`フラグが追加されています。このフラグは、コントロールプレーンノードのクラスターへの参加を自動化します。
-    - Notice the addition of the `--experimental-control-plane` flag. This flag automates joining this
+1.  以下のコマンドをタイプし、コンポーネントのPodが起動するのを確認します:
    control plane node to the cluster.
 1.  Type the following and watch the pods of the components get started:
    ```sh
    kubectl get pod -n kube-system -w
    ```
-1.  Repeat these steps for the rest of the control plane nodes.
+1.  これらのステップを、残りのコントロールプレーンノードに対して繰り返します。
 ## 外部のetcdノード
 ### etcdクラスターの構築
- Follow [these instructions](/docs/setup/independent/setup-ha-etcd-with-kubeadm/)
+- [こちらの手順](/ja/docs/setup/independent/setup-ha-etcd-with-kubeadm/)にしたがって、etcdクラスターを構築してください。
  to set up the etcd cluster.
 ### 最初のコントロールプレーンノードの構築
-1.  Copy the following files from any node from the etcd cluster to this node:
+1.  以下のファイルをetcdクラスターのどれかのノードからこのノードへコピーしてください:
    ```sh
    export CONTROL_PLANE="ubuntu@10.0.0.7"
@@ -277,9 +238,9 @@ SSH is required if you want to control all nodes from a single machine.
    +scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
    ```
-    - Replace the value of `CONTROL_PLANE` with the `user@host` of this machine.
+    - `CONTROL_PLANE`の値を、このマシンの`user@host`で置き換えます。
-1.  Create a file called `kubeadm-config.yaml` with the following contents:
+1.  以下の内容で、`kubeadm-config.yaml`という名前の設定ファイルを作成します:
        apiVersion: kubeadm.k8s.io/v1beta1
        kind: ClusterConfiguration
@@ -298,9 +259,9 @@ SSH is required if you want to control all nodes from a single machine.
                certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
                keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
-    - The difference between stacked etcd and external etcd here is that we are using the `external` field for `etcd` in the kubeadm config. In the case of the stacked etcd topology this is managed automatically.
+    - ここで、積み重なったetcdと外部etcdの違いは、kubeadmコンフィグの`etcd`に`external`フィールドを使用していることです。積み重なったetcdトポロジーの場合、これは自動で管理されます。
-    -  Replace the following variables in the template with the appropriate values for your cluster:
+    -  テンプレート内の以下の変数を、クラスターに合わせて適切な値に置き換えます:
        - `LOAD_BALANCER_DNS`
        - `LOAD_BALANCER_PORT`
@@ -308,11 +269,11 @@ SSH is required if you want to control all nodes from a single machine.
        - `ETCD_1_IP`
        - `ETCD_2_IP`
-1.  Run `kubeadm init --config kubeadm-config.yaml` on this node.
+1.  `kubeadm init --config kubeadm-config.yaml`をこのノードで実行します。
-1.  Write the join command that is returned to a text file for later use.
+1.  表示されたjoinコマンドを、あとで使うためにテキストファイルに書き込みます。
-1.  Apply the Weave CNI plugin:
+1.  Weave CNIプラグインをapplyします:
    ```sh
    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
@@ -320,27 +281,22 @@ SSH is required if you want to control all nodes from a single machine.
 ### 残りのコントロールプレーンノードの手順
-To add the rest of the control plane nodes, follow [these instructions](#steps-for-the-rest-of-the-control-plane-nodes).
+残りのコントロールプレーンノードを参加させるために、[こちらの手順](#残りのコントロールプレーンノードの手順)に従います。ローカルetcdメンバーが作られないことを除いて、積み重なったetcdの構築と同じ手順です。
 The steps are the same as for the stacked etcd setup, with the exception that a local
 etcd member is not created.
-To summarize:
+まとめると:
- Make sure the first control plane node is fully initialized.
+- 最初のコントロールプレーンノードが完全に初期化されているのを確認します。
- Copy certificates between the first control plane node and the other control plane nodes.
+- 証明書を、最初のコントロールプレーンノードから他のコントロールプレーンノードへコピーします。
- Join each control plane node with the join command you saved to a text file, plus add the `--experimental-control-plane` flag.
+- テキストファイルに保存したjoinコマンドに`--experimental-control-plane` フラグを加えたものを使って、それぞれのコントロールプレーンノードを参加させます。
 ## コントロールプレーン起動後の共通タスク
 ### Podネットワークのインストール
-[Follow these instructions](/docs/setup/independent/create-cluster-kubeadm/#pod-network) to install
+Podネットワークをインストールするには、[こちらの手順に従ってください](/ja/docs/setup/independent/create-cluster-kubeadm/#pod-network)。master設定ファイルで提供したPod CIDRのどれかに一致することを確認します。
 the pod network. Make sure this corresponds to whichever pod CIDR you provided
 in the master configuration file.
-### ワーカーのインストール
+### workerのインストール
-Each worker node can now be joined to the cluster with the command returned from any of the
+`kubeadm init`コマンドから返されたコマンドを利用して、workerノードをクラスターに参加させることが可能です。workerノードには、`--experimental-control-plane`フラグを追加する必要はありません。
 `kubeadm init` commands. The flag `--experimental-control-plane` should not be added to worker nodes.
 {{% /capture %}}
@@ -2,6 +2,10 @@
 title: kubeadmのインストール
 content_template: templates/task
 weight: 20
 card:
  name: setup
  weight: 20
  title: kubeadmセットアップツールのインストール
 ---
 {{% capture overview %}}
@@ -90,7 +94,6 @@ Other CRI-based runtimes include:
 - [containerd](https://github.com/containerd/cri) (CRI plugin built into containerd)
 - [cri-o](https://github.com/kubernetes-incubator/cri-o)
 - [frakti](https://github.com/kubernetes/frakti)
 - [rkt](https://github.com/kubernetes-incubator/rktlet)
 Refer to the [CRI installation instructions](/docs/setup/cri) for more information.
@@ -106,7 +109,7 @@ You will install these packages on all of your machines:
 * `kubectl`: the command line util to talk to your cluster.
 kubeadm **will not** install or manage `kubelet` or `kubectl` for you, so you will
-need to ensure they match the version of the Kubernetes control panel you want
+need to ensure they match the version of the Kubernetes control plane you want
 kubeadm to install for you. If you do not, there is a risk of a version skew occurring that
 can lead to unexpected, buggy behaviour. However, _one_ minor version skew between the
 kubelet and the control plane is supported, but the kubelet version may never exceed the API
@@ -119,8 +122,10 @@ This is because kubeadm and Kubernetes require
 [special attention to upgrade](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11/).
 {{</ warning >}}
-For more information on version skews, please read our
+For more information on version skews, see:
-[version skew policy](/docs/setup/independent/create-cluster-kubeadm/#version-skew-policy).
+
 * Kubernetes [version and version-skew policy](/docs/setup/version-skew-policy/)
 * Kubeadm-specific [version skew policy](/docs/setup/independent/create-cluster-kubeadm/#version-skew-policy)
 {{< tabs name="k8s_install" >}}
 {{% tab name="Ubuntu, Debian or HypriotOS" %}}
@@ -154,7 +159,7 @@ sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
 yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
-systemctl enable kubelet && systemctl start kubelet
+systemctl enable --now kubelet
 ```
  **Note:**
@@ -172,6 +177,7 @@ systemctl enable kubelet && systemctl start kubelet
    EOF
    sysctl --system
    ```
  - Make sure that the `br_netfilter` module is loaded before this step. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `modprobe br_netfilter`.
 {{% /tab %}}
 {{% tab name="Container Linux" %}}
 Install CNI plugins (required for most pod network):
@@ -208,7 +214,7 @@ curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/bu
 Enable and start `kubelet`:
 ```bash
-systemctl enable kubelet && systemctl start kubelet
+systemctl enable --now kubelet
 ```
 {{% /tab %}}
 {{< /tabs >}}
@@ -182,7 +182,7 @@ This file specifies the default locations for all of the files managed by kubead
 - The file containing the kubelet's ComponentConfig is `/var/lib/kubelet/config.yaml`.
 - The dynamic environment file that contains `KUBELET_KUBEADM_ARGS` is sourced from `/var/lib/kubelet/kubeadm-flags.env`.
 - The file that can contain user-specified flag overrides with `KUBELET_EXTRA_ARGS` is sourced from
-  `/etc/default/kubelet` (for DEBs), or `/etc/systconfig/kubelet` (for RPMs). `KUBELET_EXTRA_ARGS`
+  `/etc/default/kubelet` (for DEBs), or `/etc/sysconfig/kubelet` (for RPMs). `KUBELET_EXTRA_ARGS`
  is last in the flag chain and has the highest priority in the event of conflicting settings.
 ## Kubernetesバイナリとパッケージの内容
@@ -191,10 +191,10 @@ The DEB and RPM packages shipped with the Kubernetes releases are:
 | Package name | Description |
 |--------------|-------------|
-| `kubeadm`    | Installs the `/usr/bin/kubeadm` CLI tool and [The kubelet drop-in file(#the-kubelet-drop-in-file-for-systemd) for the kubelet. |
+| `kubeadm`    | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. |
 | `kubelet`    | Installs the `/usr/bin/kubelet` binary. |
 | `kubectl`    | Installs the `/usr/bin/kubectl` binary. |
 | `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. |
-| `cri-tools` | Installs the `/usr/bin/crictl` binary from [https://github.com/kubernetes-incubator/cri-tools](https://github.com/kubernetes-incubator/cri-tools). |
+| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). |
 {{% /capture %}}
@@ -44,9 +44,8 @@ this example.
 1. Configure the kubelet to be a service manager for etcd.
-    Running etcd is simpler than running kubernetes so you must override the
+    Since etcd was created first, you must override the service priority by creating a new unit file
-    kubeadm-provided kubelet unit file by creating a new one with a higher
+    that has higher precedence than the kubeadm-provided kubelet unit file.
    precedence.
    ```sh
    cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
@@ -90,7 +89,7 @@ this example.
            peerCertSANs:
            - "${HOST}"
            extraArgs:
-                initial-cluster: infra0=https://${ETCDHOSTS[0]}:2380,infra1=https://${ETCDHOSTS[1]}:2380,infra2=https://${ETCDHOSTS[2]}:2380
+                initial-cluster: ${NAMES[0]}=https://${ETCDHOSTS[0]}:2380,${NAMES[1]}=https://${ETCDHOSTS[1]}:2380,${NAMES[2]}=https://${ETCDHOSTS[2]}:2380
                initial-cluster-state: new
                name: ${NAME}
                listen-peer-urls: https://${HOST}:2380
@@ -256,7 +255,7 @@ this example.
 {{% capture whatsnext %}}
-Once your have a working 3 member etcd cluster, you can continue setting up a
+Once you have a working 3 member etcd cluster, you can continue setting up a
 highly available control plane using the [external etcd method with
 kubeadm](/docs/setup/independent/high-availability/).
@@ -100,9 +100,8 @@ Right after `kubeadm init` there should not be any pods in these states.
  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 and nothing happens to the DNS server, it's very
+  it's very likely that the Pod Network solution that you installed is somehow broken. 
-  likely that the Pod Network solution that you installed is somehow broken. You
+  You might have to grant it more RBAC privileges or use a newer version. Please file
  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`.
@@ -155,6 +154,18 @@ Unable to connect to the server: x509: certificate signed by unknown authority (
  regenerate a certificate if necessary. The certificates in a kubeconfig file
  are base64 encoded. The `base64 -d` 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
  ```
  Or set it to the default `KUBECONFIG` location:
  ```sh
  export KUBECONFIG=/etc/kubernetes/admin.conf
  ```
 - Another workaround is to overwrite the existing `kubeconfig` for the "admin" user:
  ```sh
@@ -226,4 +237,28 @@ 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\""
 ```
 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:
 - 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
 ```
 - 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
 ```
 {{% /capture %}}
@@ -1,11 +1,11 @@
 ---
-title: Minikubを使用してローカル環境でKubernetesを動かす
+title: Minikubeを使用してローカル環境でKubernetesを動かす
 content_template: templates/concept
 ---
 {{% capture overview %}}
-Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a VM on your laptop for users looking to try out Kubernetes or develop with it day-to-day.
+Minikubeはローカル環境でKubernetesを簡単に実行するためのツールです。Kubernetesを試したり日々の開発への使用を検討するユーザー向けに、PC上のVM内でシングルノードのKubernetesクラスタを実行することができます。
 {{% /capture %}}
@@ -13,59 +13,79 @@ Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a
 ## Minikubeの機能
-* Minikube supports Kubernetes features such as:
+* MinikubeのサポートするKubernetesの機能:
  * DNS
  * NodePorts
-  * ConfigMaps and Secrets
+  * ConfigMapsとSecrets
-  * Dashboards
+  * ダッシュボード
-  * Container Runtime: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) and [containerd](https://github.com/containerd/containerd)
+  * コンテナランタイム: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o), [containerd](https://github.com/containerd/containerd)
-  * Enabling CNI (Container Network Interface)
+  * CNI (Container Network Interface) の有効化
  * Ingress
 ## インストール
-See [Installing Minikube](/docs/tasks/tools/install-minikube/).
+[Minikubeのインストール](/docs/tasks/tools/install-minikube/) を参照
 ## クイックスタート
-Here's a brief demo of Minikube usage.
+これはMinikubeの使い方の簡単なデモです。
-If you want to change the VM driver add the appropriate `--vm-driver=xxx` flag to `minikube start`. Minikube supports
+もしVMドライバを変更したい場合は、適切な `--vm-driver=xxx` フラグを `minikube start` に設定してください。Minikubeは以下のドライバをサポートしています。
 the following drivers:
 * virtualbox
 * vmwarefusion
 * kvm2 ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver))
 * kvm ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#kvm-driver))
 * hyperkit ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver))
-* xhyve ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver)) (deprecated)
+* xhyve ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver)) (非推奨)
-
+* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
-Note that the IP below is dynamic and can change. It can be retrieved with `minikube ip`.
+注意: 以下のIPは動的であり、変更される可能性があります。IPは `minikube ip` で取得することができます。
 * none (VMではなくホスト上でKubernetesコンポーネントを起動する。このドライバを使用するにはDocker ([docker install](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) とLinux環境を必要とします)
 ```shell
-$ minikube start
+minikube start
 ```
 ```
 Starting local Kubernetes cluster...
 Running pre-create checks...
 Creating machine...
 Starting local Kubernetes cluster...
-
+```
-$ kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080
+```shell
 kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080
 ```
 ```
 deployment.apps/hello-minikube created
-$ kubectl expose deployment hello-minikube --type=NodePort
+```
 service/hello-minikube exposed
 ```shell
 kubectl expose deployment hello-minikube --type=NodePort
 ```
 ```
 service/hello-minikube exposed
 ```
 ```
 # We have now launched an echoserver pod but we have to wait until the pod is up before curling/accessing it
 # via the exposed service.
 # To check whether the pod is up and running we can use the following:
-$ kubectl get pod
+kubectl get pod
 ```
 ```
 NAME                              READY     STATUS              RESTARTS   AGE
 hello-minikube-3383150820-vctvh   0/1       ContainerCreating   0          3s
 ```
 ```shell
 # We can see that the pod is still being created from the ContainerCreating status
-$ kubectl get pod
+kubectl get pod
 ```
 ```
 NAME                              READY     STATUS    RESTARTS   AGE
 hello-minikube-3383150820-vctvh   1/1       Running   0          13s
 ```
 ```shell
 # We can see that the pod is now Running and we will now be able to curl it:
-$ curl $(minikube service hello-minikube --url)
+curl $(minikube service hello-minikube --url)
-
+```
 ```
 Hostname: hello-minikube-7c77b68cff-8wdzq
@@ -91,13 +111,26 @@ Request Headers:
 Request Body:
 	-no body in request-
 ```
-
+```shell
-$ kubectl delete services hello-minikube
+kubectl delete services hello-minikube
 ```
 ```
 service "hello-minikube" deleted
-$ kubectl delete deployment hello-minikube
+```
 ```shell
 kubectl delete deployment hello-minikube
 ```
 ```
 deployment.extensions "hello-minikube" deleted
-$ minikube stop
+```
 ```shell
 minikube stop
 ```
 ```
 Stopping local Kubernetes cluster...
 Stopping "minikube"...
 ```
@@ -106,20 +139,22 @@ Stopping "minikube"...
 #### containerd
-To use [containerd](https://github.com/containerd/containerd) as the container runtime, run:
+[containerd](https://github.com/containerd/containerd) をコンテナランタイムとして使用するには以下を実行してください:
 ```bash
-$ minikube start \
+minikube start \
    --network-plugin=cni \
    --enable-default-cni \
    --container-runtime=containerd \
    --bootstrapper=kubeadm
 ```
-Or you can use the extended version:
+もしくは拡張バージョンを使用することもできます:
 ```bash
-$ minikube start \
+minikube start \
    --network-plugin=cni \
    --enable-default-cni \
    --extra-config=kubelet.container-runtime=remote \
    --extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \
    --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \
@@ -128,20 +163,22 @@ $ minikube start \
 #### CRI-O
-To use [CRI-O](https://github.com/kubernetes-incubator/cri-o) as the container runtime, run:
+[CRI-O](https://github.com/kubernetes-incubator/cri-o) をコンテナランタイムとして使用するには以下を実行してください:
 ```bash
-$ minikube start \
+minikube start \
    --network-plugin=cni \
    --enable-default-cni \
    --container-runtime=cri-o \
    --bootstrapper=kubeadm
 ```
-Or you can use the extended version:
+もしくは拡張バージョンを使用することもできます:
 ```bash
-$ minikube start \
+minikube start \
    --network-plugin=cni \
    --enable-default-cni \
    --extra-config=kubelet.container-runtime=remote \
    --extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \
    --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \
@@ -150,44 +187,44 @@ $ minikube start \
 #### rktコンテナエンジン
-To use [rkt](https://github.com/rkt/rkt) as the container runtime run:
+[rkt](https://github.com/rkt/rkt) をコンテナランタイムとして使用するには以下を実行してください:
 ```shell
-$ minikube start \
+minikube start \
    --network-plugin=cni \
    --enable-default-cni \
    --container-runtime=rkt
 ```
-This will use an alternative minikube ISO image containing both rkt, and Docker, and enable CNI networking.
+これはrktとDockerの両方を含んだ代替のMinikubeのISOイメージを使用し、CNIネットワークを有効にします。
 ### ドライバープラグイン
-See [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) for details on supported drivers and how to install
+サポートされているドライバとプラグインのインストールの詳細については [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) を参照してください。
 plugins, if required.
 ### Dockerデーモンの再利用によるローカルイメージの使用
-When using a single VM of Kubernetes, it's really handy to reuse the Minikube's built-in Docker daemon; as this means you don't have to build a docker registry on your host machine and push the image into it - you can just build inside the same docker daemon as minikube which speeds up local experiments. Just make sure you tag your Docker image with something other than 'latest' and use that tag while you pull the image. Otherwise, if you do not specify version of your image, it will be assumed as `:latest`, with pull image policy of `Always` correspondingly, which may eventually result in `ErrImagePull` as you may not have any versions of your Docker image out there in the default docker registry (usually DockerHub) yet.
+Kubernetesの単一のVMを使用する場合、Minikube組み込みのDockerデーモンの再利用がおすすめです。ホストマシン上にDockerレジストリを構築してイメージをプッシュする必要がなく、ローカルでの実験を加速させるMinikubeと同じDockerデーモンの中に構築することができます。ただDockerイメージに'latest'以外のタグを付け、そのタグを使用してイメージをプルしてください。イメージのバージョンを指定しなければ、`Always` のプルイメージポリシーにより `:latest` と仮定され、もしデフォルトのDockerレジストリ(通常はDockerHub)にどのバージョンのDockerイメージもまだ存在しない場合には、`ErrImagePull` になる恐れがあります。
-To be able to work with the docker daemon on your mac/linux host use the `docker-env command` in your shell:
+Mac/LinuxのホストでDockerデーモンを操作できるようにするには、shell内で `docker-env command` を使います:
 ```shell
 eval $(minikube docker-env)
 ```
-You should now be able to use docker on the command line on your host mac/linux machine talking to the docker daemon inside the minikube VM:
+これにより、MinikubeのVM内のDockerデーモンと通信しているホストのMac/LinuxマシンのコマンドラインでDockerを使用できるようになっているはずです。
 ```shell
 docker ps
 ```
-On Centos 7, docker may report the following error:
+CentOS 7では、Dockerが以下のエラーを出力することがあります:
 ```shell
 Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory
 ```
-The fix is to update /etc/sysconfig/docker to ensure that Minikube's environment changes are respected:
+修正方法としては、/etc/sysconfig/docker を更新してMinikube環境の変更が確実に反映されるようにすることです:
 ```shell
 < DOCKER_CERT_PATH=/etc/docker
@@ -197,32 +234,32 @@ The fix is to update /etc/sysconfig/docker to ensure that Minikube's environment
 > fi
 ```
-Remember to turn off the imagePullPolicy:Always, otherwise Kubernetes won't use images you built locally.
+imagePullPolicy:Alwaysをオフにすることを忘れないでください: さもなければKubernetesはローカルに構築したイメージを使用しません。
 ## クラスターの管理
 ### クラスターの起動
-The `minikube start` command can be used to start your cluster.
+`minikube start` コマンドはクラスターを起動することができます。
-This command creates and configures a Virtual Machine that runs a single-node Kubernetes cluster.
+このコマンドはシングルノードのKubernetesクラスターを実行する仮想マシンを作成・設定します。
-This command also configures your [kubectl](/docs/user-guide/kubectl-overview/) installation to communicate with this cluster.
+また、このクラスターと通信する [kubectl](/docs/user-guide/kubectl-overview/) のインストールも設定します。
-If you are behind a web proxy, you will need to pass this information to the `minikube start` command:
+もしWebプロキシーを通している場合、そのプロキシー情報を `minikube start` コマンドに渡す必要があります:
 ```shell
 https_proxy=<my proxy> minikube start --docker-env http_proxy=<my proxy> --docker-env https_proxy=<my proxy> --docker-env no_proxy=192.168.99.0/24
 ```
-Unfortunately just setting the environment variables will not work.
+残念なことに、ただ環境変数を設定するだけではうまく動作しません。
-Minikube will also create a "minikube" context, and set it to default in kubectl.
+Minikubeは "minikube" コンテキストも作成し、そのコンテキストをデフォルト設定としてkubectlに設定します。
-To switch back to this context later, run this command: `kubectl config use-context minikube`.
+あとでコンテキストを切り戻すには、このコマンドを実行してください: `kubectl config use-context minikube`
 #### Kubernetesバージョンの指定
-You can specify the specific version of Kubernetes for Minikube to use by
+`minikube start` コマンドに `--kubernetes-version` 文字列を追加することで、
-adding the `--kubernetes-version` string to the `minikube start` command. For
+MinikubeにKubernetesの特定のバージョンを指定することができます。
-example, to run version `v1.7.3`, you would run the following:
+例えば、`v1.7.3` のバージョンを実行するには以下を実行します:
 ```
 minikube start --kubernetes-version v1.7.3
@@ -230,16 +267,16 @@ minikube start --kubernetes-version v1.7.3
 ### Kubernetesの設定
-Minikube has a "configurator" feature that allows users to configure the Kubernetes components with arbitrary values.
+Minikubeにはユーザーが任意の値でKubenetesコンポーネントを設定することを可能にする "configurator" 機能があります。
-To use this feature, you can use the `--extra-config` flag on the `minikube start` command.
+この機能を使うには、`minikube start` コマンドに `--extra-config` フラグを使うことができます。
-This flag is repeated, so you can pass it several times with several different values to set multiple options.
+このフラグは繰り返されるので、複数のオプションを設定するためにいくつかの異なる値を使って何度も渡すことができます。
-This flag takes a string of the form `component.key=value`, where `component` is one of the strings from the below list, `key` is a value on the
+このフラグは `component.key=value` 形式の文字列を取ります。`component` は下記のリストの文字列の1つです。
-configuration struct and `value` is the value to set.
+`key`は設定構造体上の値で、 `value` は設定する値です。
-Valid keys can be found by examining the documentation for the Kubernetes `componentconfigs` for each component.
+各コンポーネントのKubernetes `componentconfigs` のドキュメントを調べることで有効なキーを見つけることができます。
-Here is the documentation for each supported configuration:
+サポートされている各設定のドキュメントは次のとおりです:
 * [kubelet](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)
 * [apiserver](https://godoc.org/k8s.io/kubernetes/cmd/kube-apiserver/app/options#ServerRunOptions)
@@ -250,37 +287,37 @@ Here is the documentation for each supported configuration:
 #### 例
-To change the `MaxPods` setting to 5 on the Kubelet, pass this flag: `--extra-config=kubelet.MaxPods=5`.
+Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡します: `--extra-config=kubelet.MaxPods=5`
-This feature also supports nested structs. To change the `LeaderElection.LeaderElect` setting to `true` on the scheduler, pass this flag: `--extra-config=scheduler.LeaderElection.LeaderElect=true`.
+この機能はネストした構造体もサポートします。スケジューラーの `LeaderElection.LeaderElect` を `true` に設定するには、このフラグを渡します: `--extra-config=scheduler.LeaderElection.LeaderElect=true`
-To set the `AuthorizationMode` on the `apiserver` to `RBAC`, you can use: `--extra-config=apiserver.authorization-mode=RBAC`.
+`apiserver` の `AuthorizationMode` を `RABC` に設定するには、このフラグを使います: `--extra-config=apiserver.authorization-mode=RBAC`.
 ### クラスターの停止
-The `minikube stop` command can be used to stop your cluster.
+`minikube stop` コマンドを使ってクラスターを停止することができます。
-This command shuts down the Minikube Virtual Machine, but preserves all cluster state and data.
+このコマンドはMinikube仮想マシンをシャットダウンしますが、すべてのクラスターの状態とデータを保存します。
-Starting the cluster again will restore it to it's previous state.
+クラスターを再起動すると、以前の状態に復元されます。
 ### クラスターの削除
-The `minikube delete` command can be used to delete your cluster.
+`minikube delete` コマンドを使ってクラスターを削除することができます。
-This command shuts down and deletes the Minikube Virtual Machine. No data or state is preserved.
+このコマンドはMinikube仮想マシンをシャットダウンして削除します。データや状態は保存されません。
 ## クラスターに触れてみよう
 ### Kubectl
-The `minikube start` command creates a [kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) called "minikube".
+`minikube start` コマンドは "minikube" という[kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-)を作成します。
-This context contains the configuration to communicate with your Minikube cluster.
+このコンテキストはMinikubeクラスターと通信するための設定が含まれています。
-Minikube sets this context to default automatically, but if you need to switch back to it in the future, run:
+Minikubeはこのコンテキストを自動的にデフォルトに設定しますが、将来的に設定を切り戻す場合には次のコマンドを実行してください:
 `kubectl config use-context minikube`,
-Or pass the context on each command like this: `kubectl get pods --context=minikube`.
+もしくは各コマンドにコンテキストを次のように渡します: `kubectl get pods --context=minikube`
 ### ダッシュボード
-To access the [Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/), run this command in a shell after starting Minikube to get the address:
+[Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/)にアクセスするには、Minikubeを起動してアドレスを取得した後、シェルでこのコマンドを実行してください:
 ```shell
 minikube dashboard
@@ -288,7 +325,7 @@ minikube dashboard
 ### サービス
-To access a service exposed via a node port, run this command in a shell after starting Minikube to get the address:
+ノードポート経由で公開されているサービスにアクセスするには、Minikubeを起動してアドレスを取得した後、シェルでこのコマンドを実行してください:
 ```shell
 minikube service [-n NAMESPACE] [--url] NAME
@@ -296,25 +333,25 @@ minikube service [-n NAMESPACE] [--url] NAME
 ## ネットワーク
-The Minikube VM is exposed to the host system via a host-only IP address, that can be obtained with the `minikube ip` command.
+MinikubeのVMは `minikube ip`コマンドで取得できるホストオンリーIPアドレスを介してホストシステムに公開されます。
-Any services of type `NodePort` can be accessed over that IP address, on the NodePort.
+NodePort上では、 `NodePort` タイプのどのサービスもそのIPアドレスを介してアクセスできます。
-To determine the NodePort for your service, you can use a `kubectl` command like this:
+サービスのNodePortを決定するには、`kubectl` コマンドを次のように使用します:
 `kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'`
 ## 永続化ボリューム
-Minikube supports [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) of type `hostPath`.
+Minikubeは `hostPath` タイプの[PersistentVolumes](/docs/concepts/storage/persistent-volumes/)をサポートします。
-These PersistentVolumes are mapped to a directory inside the Minikube VM.
+このPersistentVolumesはMinikubeのVM内のディレクトリーにマッピングされます。
-The Minikube VM boots into a tmpfs, so most directories will not be persisted across reboots (`minikube stop`).
+MinikubeのVMはtmpfsで起動するため、ほとんどのディレクトリーは再起動しても持続しません (`minikube stop`)。
-However, Minikube is configured to persist files stored under the following host directories:
+しかし、Minikubeは以下のホストディレクトリーに保存されているファイルを保持するように設定されています:
 * `/data`
 * `/var/lib/minikube`
 * `/var/lib/docker`
-Here is an example PersistentVolume config to persist data in the `/data` directory:
+以下は `/data` ディレクトリのデータを永続化するPersistentVolumeの設定例です:
 ```yaml
 apiVersion: v1
@@ -331,10 +368,10 @@ spec:
 ```
 ## ホストフォルダーのマウント
-Some drivers will mount a host folder within the VM so that you can easily share files between the VM and host.  These are not configurable at the moment and different for the driver and OS you are using.
+一部のドライバーはVM内にホストフォルダーをマウントするため、VMとホストの間でファイルを簡単に共有できます。これらは現時点では設定可能ではなく、使用しているドライバーとOSによって異なります。
 {{< note >}}
-Host folder sharing is not implemented in the KVM driver yet.
+ホストフォルダーの共有はKVMドライバーにはまだ実装されていません。
 {{< /note >}}
 | Driver | OS | HostFolder | VM |
@@ -347,62 +384,61 @@ Host folder sharing is not implemented in the KVM driver yet.
 ## プライベートコンテナレジストリ
-To access a private container registry, follow the steps on [this page](/docs/concepts/containers/images/).
+プライベートコンテナレジストリにアクセスするには、[このページ](/docs/concepts/containers/images/)の手順に従ってください。
-We recommend you use `ImagePullSecrets`, but if you would like to configure access on the Minikube VM you can place the `.dockercfg` in the `/home/docker` directory or the `config.json` in the `/home/docker/.docker` directory.
+`ImagePullSecrets` を使用することをおすすめしますが、MinikubeのVM内でアクセス設定したい場合には、`/home/docker` ディレクトリに `.dockercfg` を置くか、または `/home/docker/.docker` ディレクトリに `config.json` を置いてください。
 ## アドオン
-In order to have Minikube properly start or restart custom addons,
+カスタムアドオンを正しく起動または再起動させるには、
-place the addons you wish to be launched with Minikube in the `~/.minikube/addons`
+Minikubeで起動したいアドオンを `~/.minikube/addons` ディレクトリに置きます。
-directory. Addons in this folder will be moved to the Minikube VM and
+このフォルダ内のアドオンはMinikubeのVMに移動され、Minikubeが起動または再起動されるたびにアドオンが起動されます。
 launched each time Minikube is started or restarted.
 ## HTTPプロキシ経由のMinikube利用
-Minikube creates a Virtual Machine that includes Kubernetes and a Docker daemon.
+MinikubeはKubernetesとDockerデーモンを含む仮想マシンを作成します。
-When Kubernetes attempts to schedule containers using Docker, the Docker daemon may require external network access to pull containers.
+KubernetesがDockerを使用してコンテナをスケジュールしようとする際、Dockerデーモンはコンテナをプルするために外部ネットワークを必要とする場合があります。
-If you are behind an HTTP proxy, you may need to supply Docker with the proxy settings.
+HTTPプロキシーを通している場合には、プロキシー設定をDockerに提供する必要があります。
-To do this, pass the required environment variables as flags during `minikube start`.
+これを行うには、`minikube start` に必要な環境変数をフラグとして渡します。
-For example:
+例:
 ```shell
-$ minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \
+minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \
               --docker-env https_proxy=https://$YOURPROXY:PORT
 ```
-If your Virtual Machine address is 192.168.99.100, then chances are your proxy settings will prevent `kubectl` from directly reaching it.
+仮想マシンのアドレスが192.168.99.100の場合、プロキシーの設定により `kubectl` が直接アクセスできない可能性があります。
-To by-pass proxy configuration for this IP address, you should modify your no_proxy settings. You can do so with:
+このIPアドレスのプロキシー設定を迂回するには、以下のようにno_proxy設定を変更する必要があります。
 ```shell
-$ export no_proxy=$no_proxy,$(minikube ip)
+export no_proxy=$no_proxy,$(minikube ip)
 ```
 ## 既知の問題
-* Features that require a Cloud Provider will not work in Minikube. These include:
+* クラウドプロバイダーを必要とする機能はMinikubeでは動作しません
-  * LoadBalancers
+  * ロードバランサー
-* Features that require multiple nodes. These include:
+* 複数ノードを必要とする機能
-  * Advanced scheduling policies
+  * 高度なスケジューリングポリシー
 ## 設計
-Minikube uses [libmachine](https://github.com/docker/machine/tree/master/libmachine) for provisioning VMs, and [kubeadm](https://github.com/kubernetes/kubeadm) to provision a Kubernetes cluster.
+MinikubeはVMのプロビジョニングに[libmachine](https://github.com/docker/machine/tree/master/libmachine)を使用し、[kubeadm](https://github.com/kubernetes/kubeadm)をKubernetesクラスターのプロビジョニングに使用します。
-For more information about Minikube, see the [proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md).
+Minikubeの詳細については、[proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md)を参照してください。
 ## 追加リンク集
-* **Goals and Non-Goals**: For the goals and non-goals of the Minikube project, please see our [roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md).
+* **目標と非目標**: Minikubeプロジェクトの目標と非目標については、[ロードマップ](https://git.k8s.io/minikube/docs/contributors/roadmap.md)を参照してください。
-* **Development Guide**: See [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) for an overview of how to send pull requests.
+* **開発ガイド**: プルリクエストを送る方法の概要については、[CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md)を参照してください。
-* **Building Minikube**: For instructions on how to build/test Minikube from source, see the [build guide](https://git.k8s.io/minikube/docs/contributors/build_guide.md).
+* **Minikubeのビルド**: Minikubeをソースからビルド/テストする方法については、[ビルドガイド](https://git.k8s.io/minikube/docs/contributors/build_guide.md)を参照してください。
-* **Adding a New Dependency**: For instructions on how to add a new dependency to Minikube see the [adding dependencies guide](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md).
+* **新しい依存性の追加**: Minikubeに新しい依存性を追加する方法については、[依存性追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)を参照してください。
-* **Adding a New Addon**: For instruction on how to add a new addon for Minikube see the [adding an addon guide](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md).
+* **新しいアドオンの追加**: Minikubeに新しいアドオンを追加する方法については、[アドオン追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)を参照してください。
-* **Updating Kubernetes**: For instructions on how to update Kubernetes see the [updating Kubernetes guide](https://git.k8s.io/minikube/docs/contributors/updating_kubernetes.md).
+* **MicroK8s**: 仮想マシンを実行したくないLinuxユーザーは代わりに[MicroK8s](https://microk8s.io/)を検討してみてください。
 ## コミュニティ
-Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
+コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の#minikubeチャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。
 {{% /capture %}}
@@ -1,8 +1,17 @@
 ---
 title: 複数のゾーンで動かす
 weight: 90
 content_template: templates/concept
 ---
 {{% capture overview %}}
 This page describes how to run a cluster in multiple zones.
 {{% /capture %}}
 {{% capture body %}}
 ## 始めに
 Kubernetes 1.2 adds support for running a single cluster in multiple failure zones
@@ -23,8 +32,6 @@ add similar support for other clouds or even bare metal, by simply arranging
 for the appropriate labels to be added to nodes and volumes).
 {{< toc >}}
 ## 機能性
 When nodes are started, the kubelet automatically adds labels to them with
@@ -118,14 +125,17 @@ labels are `failure-domain.beta.kubernetes.io/region` for the region,
 and `failure-domain.beta.kubernetes.io/zone` for the zone:
 ```shell
-> kubectl get nodes --show-labels
+kubectl get nodes --show-labels
 ```
 The output is similar to this:
 ```shell
 NAME                     STATUS                     ROLES    AGE   VERSION          LABELS
-kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.12.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-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.12.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-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.12.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-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.12.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-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
 ```
 ### 2つ目のゾーンにさらにノードを追加
@@ -154,16 +164,20 @@ View the nodes again; 3 more nodes should have launched and be tagged
 in us-central1-b:
 ```shell
-> kubectl get nodes --show-labels
+kubectl get nodes --show-labels
 ```
 The output is similar to this:
 ```shell
 NAME                     STATUS                     ROLES    AGE   VERSION           LABELS
-kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.12.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-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.12.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-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.12.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-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.12.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-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.12.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-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.12.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-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.12.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-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
 ```
 ### ボリュームのアフィニティ
@@ -204,10 +218,15 @@ always created in the zone of the cluster master
 was addressed in 1.3+.
 {{< /note >}}
-Now lets validate that Kubernetes automatically labeled the zone & region the PV was created in.
+Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in.
 ```shell
 kubectl get pv --show-labels
 ```
 The output is similar to this:
 ```shell
 > kubectl get pv --show-labels
 NAME           CAPACITY   ACCESSMODES   RECLAIM POLICY   STATUS    CLAIM            STORAGECLASS    REASON    AGE       LABELS
 pv-gce-mj4gm   5Gi        RWO           Retain           Bound     default/claim1   manual                    46s       failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
 ```
@@ -240,9 +259,20 @@ Note that the pod was automatically created in the same zone as the volume, as
 cross-zone attachments are not generally permitted by cloud providers:
 ```shell
-> kubectl describe pod mypod | grep Node
+kubectl describe pod mypod | grep Node
 ```
 ```shell
 Node:        kubernetes-minion-9vlv/10.240.0.5
-> kubectl get node kubernetes-minion-9vlv --show-labels
+```
 And check node labels:
 ```shell
 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
 ```
@@ -279,16 +309,24 @@ find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl crea
 The pods should be spread across all 3 zones:
 ```shell
->  kubectl describe pod -l app=guestbook | grep Node
+kubectl describe pod -l app=guestbook | grep Node
 ```
 ```shell
 Node:        kubernetes-minion-9vlv/10.240.0.5
 Node:        kubernetes-minion-281d/10.240.0.8
 Node:        kubernetes-minion-olsh/10.240.0.11
 ```
- > kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels
+```shell
 kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels
 ```
 ```shell
 NAME                     STATUS    ROLES    AGE    VERSION          LABELS
-kubernetes-minion-9vlv   Ready     <none>   34m    v1.12.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-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.12.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-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.12.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-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
 ```
@@ -296,15 +334,42 @@ Load-balancers span all zones in a cluster; the guestbook-go example
 includes an example load-balanced service:
 ```shell
-> kubectl describe service guestbook | grep LoadBalancer.Ingress
+kubectl describe service guestbook | grep LoadBalancer.Ingress
 ```
 The output is similar to this:
 ```shell
 LoadBalancer Ingress:   130.211.126.21
 ```
-> ip=130.211.126.21
+Set the above IP:
-> curl -s http://${ip}:3000/env | grep HOSTNAME
+```shell
 export IP=130.211.126.21
 ```
 Explore with curl via IP:
 ```shell
 curl -s http://${IP}:3000/env | grep HOSTNAME
 ```
 The output is similar to this:
 ```shell
  "HOSTNAME": "guestbook-44sep",
 ```
-> (for i in `seq 20`; do curl -s http://${ip}:3000/env | grep HOSTNAME; done)  | sort | uniq
+Again, explore multiple times:
 ```shell
 (for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done)  | sort | uniq
 ```
 The output is similar to this:
 ```shell
  "HOSTNAME": "guestbook-44sep",
  "HOSTNAME": "guestbook-hum5n",
  "HOSTNAME": "guestbook-ppm40",
@@ -331,3 +396,5 @@ KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c k
 KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh
 KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
 ```
 {{% /capture %}}
@@ -8,7 +8,7 @@ author: Rob Hirschfeld (zehicle)
 This guide helps to install a Kubernetes cluster hosted on bare metal with [Digital Rebar Provision](https://github.com/digitalrebar/provision) using only its Content packages and *kubeadm*. 
-Digital Rebar Provision (DRP) is an integrated Golang DHCP, bare metal provisioning (PXE/iPXE) and workflow automation platform. While [DRP can be used to invoke](https://provision.readthedocs.io/en/tip/doc/integrations/ansible.html) [kubespray](../kubespray), it also offers a self-contained Kubernetes installation known as [KRIB (Kubernetes Rebar Integrated Bootstrap)](https://github.com/digitalrebar/provision-content/tree/master/krib).
+Digital Rebar Provision (DRP) is an integrated Golang DHCP, bare metal provisioning (PXE/iPXE) and workflow automation platform. While [DRP can be used to invoke](https://provision.readthedocs.io/en/tip/doc/integrations/ansible.html) [kubespray](/docs/setup/custom-cloud/kubespray), it also offers a self-contained Kubernetes installation known as [KRIB (Kubernetes Rebar Integrated Bootstrap)](https://github.com/digitalrebar/provision-content/tree/master/krib).
 {{< note >}}
 KRIB is not a _stand-alone_ installer: Digital Rebar templates drive a standard *[kubeadm](/docs/admin/kubeadm/)* configuration that manages the Kubernetes installation with the [Digital Rebar cluster pattern](https://provision.readthedocs.io/en/tip/doc/arch/cluster.html#rs-cluster-pattern) to elect leaders _without external supervision_.
@@ -92,4 +92,4 @@ When running the reset Workflow, be sure not to accidentally target your product
 ## フィードバック
 * Slack Channel: [#community](https://rackn.slack.com/messages/community/)
-* [GitHub Issues](https://github.com/digital/provision/issues)
+* [GitHub Issues](https://github.com/digitalrebar/provision/issues)
@@ -2,25 +2,36 @@
 title: 正しいソリューションの選択
 weight: 10
 content_template: templates/concept
 card:
  name: setup
  weight: 20
  anchors:
  - anchor: "#ホスティングを使ったソリューション"
    title: ホスティングを使ったソリューション
  - anchor: "#すぐに利用できるクラウドを使ったソリューション"
    title: すぐに利用できるクラウドを使ったソリューション
  - anchor: "#すぐに利用できるオンプレミスを使ったソリューション"
    title: すぐに利用できるオンプレミスを使ったソリューション
  - anchor: "#カスタムソリューション"
    title: カスタムソリューション
  - anchor: "#ローカルマシンを使ったソリューション"
    title: ローカルマシンを使ったソリューション
 ---
 {{% capture overview %}}
-Kubernetes can run on various platforms: from your laptop, to VMs on a cloud provider, to a rack of
+Kubernetesは様々なプラットフォームで動作することができます: PCから、クラウドプロバイダーのVM、ベアメタルサーバーのラックまで。
-bare metal servers. The effort required to set up a cluster varies from running a single command to
+クラスターをセットアップするために必要な作業は、単一のコマンドを実行することからカスタマイズされたクラスターを作り上げるまで異なります。このガイドを使用して、ニーズに合ったソリューションを選択してください。
 crafting your own customized cluster. Use this guide to choose a solution that fits your needs.
-If you just want to "kick the tires" on Kubernetes, use the [local Docker-based solutions](#local-machine-solutions).
+Kubernetesを少し試したいだけであれば、[ローカルマシンを使ったソリューション](#ローカルマシンを使ったソリューション)を使用してください。
-When you are ready to scale up to more machines and higher availability, a [hosted solution](#hosted-solutions) is the easiest to create and maintain.
+より多くのマシンと高い可用性にスケールアップする準備がある場合、[ホスティングを使ったソリューション](#ホスティングを使ったソリューション)で作成して保守するのが最も簡単です。
-[Turnkey cloud solutions](#turnkey-cloud-solutions) require only a few commands to create
+[すぐに利用できるクラウドを使ったソリューション](#すぐに利用できるクラウドを使ったソリューション)は様々なクラウドプロバイダーを作成してカバーするために必要なコマンドはわずかで済みます。[すぐに利用できるオンプレミスを使ったソリューション](#すぐに利用できるオンプレミスを使ったソリューション)には、プライベートネットワークのセキュリティと組み合わせたすぐに利用できるクラウドソリューションのシンプルさがあります。
 and cover a wide range of cloud providers. [On-Premises turnkey cloud solutions](#on-premises-turnkey-cloud-solutions) have the simplicity of the turnkey cloud solution combined with the security of your own private network.
-If you already have a way to configure hosting resources, use [kubeadm](/docs/setup/independent/create-cluster-kubeadm/) to easily bring up a cluster with a single command per machine.
+すでにホスティングサービスを設定する方法がある場合は、[kubeadm](/docs/setup/independent/create-cluster-kubeadm/)を使用して、マシン毎に単一のコマンドでクラスターを簡単に起動できます。
-[Custom solutions](#custom-solutions) vary from step-by-step instructions to general advice for setting up
+[カスタムソリューション](#カスタムソリューション)は段階的な手順からセットアップの一般的なアドバイスまで様々あります。
 a Kubernetes cluster from scratch.
 {{% /capture %}}
@@ -28,58 +39,73 @@ a Kubernetes cluster from scratch.
 ## ローカルマシンを使ったソリューション
-* [Minikube](/docs/setup/minikube/) is a method for creating a local, single-node Kubernetes cluster for development and testing. Setup is completely automated and doesn't require a cloud provider account.
+* [Minikube](/docs/setup/minikube/)は開発とテスト用にローカルの単一ノードのKubernetesクラスターを作成するための方法です。セットアップは完全に自動化されており、クラウドプロバイダーのアカウントは必要ありません。
-* [microk8s](https://microk8s.io/) provides a single command installation of the latest Kubernetes release on a local machine for development and testing. Setup is quick, fast (~30 sec) and supports many plugins including Istio with a single command.
+* [Docker Desktop](https://www.docker.com/products/docker-desktop)は
 MacまたはWindows環境に簡単にインストールできるアプリケーションで、
 単一ノードのKubernetesクラスターを使用して、
 数分でコーディングとコンテナへのデプロイを開始できます。
-* [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) can use VirtualBox on your machine to deploy Kubernetes to one or more VMs for development and test scenarios. Scales to full multi-node cluster.
+* [Minishift](https://docs.okd.io/latest/minishift/)は、ローカル開発およびテスト用にKubernetesエンタープライズプラットフォームのOpenShiftのコミュニティーバージョンをインストールします。Windows、MacOS、Linux用のオールインワンのVM (`minishift start`)を提供します。コンテナの起動は`oc cluster up`に基づいています (Linuxのみ)。[付属のアドオン](https://github.com/minishift/minishift-addons/tree/master/add-ons)をインストールすることもできます。
-* [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers) is a Terraform/Packer/BASH based Infrastructure as Code (IaC) scripts to create a seven node (1 Boot, 1 Master, 1 Management, 1 Proxy and 3 Workers) LXD cluster on  Linux Host.
+* [MicroK8s](https://microk8s.io/)は、開発とテスト用にローカルマシンに最新リリースのKubernetesを単一コマンドでのインストールを可能にします。セットアップは素早く、速く(〜30秒)て、lstioを含む多くのプラグインを単一コマンドでサポートします。
-* [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster) is a multi-node (while minikube is single-node) Kubernetes cluster which only requires a docker daemon. It uses docker-in-docker technique to spawn the Kubernetes cluster.
+* [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private)は、開発とテストシナリオ用に、ご自身のマシンでVirtualBoxを使って1つ以上のVMにKubernetesをデプロイすることができます。フルマルチノードのクラスターに拡張します。
-* [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/local/) supports a nine-instance deployment on localhost.
+* [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)は、Linuxホスト上に7ノード(1ブート、1マスター、1マネジメント、1プロキシー、3ワーカー)のLXDクラスターを作成するためのTerraform/Packer/BASHベースのInfrastructure as Code（IaC）のスクリプトです。
 * [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster)は、(Minikubeが単一ノードであることに対して)マルチノードのKubernetesクラスターで、Dockerデーモンのみが必要です。Kubernetesクラスターを生成するためにdocker-in-docker技術を使います。
 * [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/local/)は、ローカルホスト上の9インスタンスのデプロイをサポートします。
 ## ホスティングを使ったソリューション
-* [AppsCode.com](https://appscode.com/products/cloud-deployment/) provides managed Kubernetes clusters for various public clouds, including AWS and Google Cloud Platform.
+* [AppsCode.com](https://appscode.com/products/cloud-deployment/)は、AWSやGoogle Cloud Platformなどの様々なパブリッククラウド用のマネージドなKubernetesクラスターを提供します。
-* [APPUiO](https://appuio.ch) runs an OpenShift public cloud platform, supporting any Kubernetes workload. Additionally APPUiO offers Private Managed OpenShift Clusters, running on any public or private cloud.
+* [APPUiO](https://appuio.ch)は、OpenShiftのパブリッククラウドプラットフォームを実行し、あらゆるKubernetesワークロードをサポートします。さらにAPPUiOは、パブリッククラウドまたはプライベートクラウド上で動作するPrivate Managed OpenShift Clustersを提供します。
-* [Amazon Elastic Container Service for Kubernetes](https://aws.amazon.com/eks/) offers managed Kubernetes service.
+* [Amazon Elastic Container Service for Kubernetes](https://aws.amazon.com/eks/)は、マネージドなKubernetesサービスを提供します。
-* [Azure Kubernetes Service](https://azure.microsoft.com/services/container-service/) offers managed Kubernetes clusters.
+* [Azure Kubernetes Service](https://azure.microsoft.com/services/container-service/)は、マネージドなKubernetesクラスターを提供します。
-* [Giant Swarm](https://giantswarm.io/product/) offers managed Kubernetes clusters in their own datacenter, on-premises, or on public clouds.
+* [Containership Kubernetes Engine (CKE)](https://containership.io/containership-platform) GCP、Azure、AWS、Packet、DigitalOceanでの直感的なKubernetesクラスターのプロビジョニングと管理。シームレスなバージョンアップグレード、自動スケーリング、メトリック、ワークロードの作成など。
-* [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) offers managed Kubernetes clusters.
+* [DigitalOcean Kubernetes](https://www.digitalocean.com/products/kubernetes/)は、マネージドなKubernetesサービスを提供します。
-* [IBM Cloud Kubernetes Service](https://console.bluemix.net/docs/containers/container_index.html) offers managed Kubernetes clusters with isolation choice, operational tools, integrated security insight into images and containers, and integration with Watson, IoT, and data.
+* [Giant Swarm](https://giantswarm.io/product/)は、独自のデータセンター、オンプレミス、またはパブリッククラウド上にマネージドなKubernetesクラスターを提供します。
-* [Kubermatic](https://www.loodse.com) provides managed Kubernetes clusters for various public clouds, including AWS and Digital Ocean, as well as on-premises with OpenStack integration.
+* [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)は、マネージドなKubernetesクラスターを提供します。
-* [Kublr](https://kublr.com) offers enterprise-grade secure, scalable, highly reliable Kubernetes clusters on AWS, Azure, GCP, and on-premise. It includes out-of-the-box backup and disaster recovery, multi-cluster centralized logging and monitoring, and built-in alerting.
+* [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index)は、アイソレーションの選択、運用ツール、イメージとコンテナーへの統合されたセキュリティーのインサイト、およびWatson、IoT、データとの統合を備えたマネージドなKubernetesクラスターを提供します。
-* [Madcore.Ai](https://madcore.ai) is devops-focused CLI tool for deploying Kubernetes infrastructure in AWS. Master, auto-scaling group nodes with spot-instances, ingress-ssl-lego, Heapster, and Grafana.
+* [Kubermatic](https://www.loodse.com)は、AWSやDigital Oceanなどの様々なパブリッククラウド用のマネージドなKubernetesクラスターを提供するだけでなく、OpenStackと統合されたオンプレミスも提供します。
-* [OpenShift Dedicated](https://www.openshift.com/dedicated/) offers managed Kubernetes clusters powered by OpenShift.
+* [Kublr](https://kublr.com)は、AWS、Azure、GCP、およびオンプレミスで、エンタープライズ級の安全でスケーラブルで信頼性の高いKubernetesクラスターを提供します。すぐに使用可能なバックアップとディザスターリカバリ、集中管理されたマルチクラスターのログ記録とモニタリング、および組み込みのアラートが含まれます。
-* [OpenShift Online](https://www.openshift.com/features/) provides free hosted access for Kubernetes applications.
+* [KubeSail](https://kubesail.com)は、簡単にKubernetesを試すことができる近道です。
-* [Oracle Container Engine for Kubernetes](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengoverview.htm) is a fully-managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud.
+* [Madcore.Ai](https://madcore.ai)は、AWSにKubernetesインフラストラクチャーをデプロイするためのDevOpsにフォーカスしたCLIツールです。マスター、スポットインスタンスを使ったオートスケーリンググループのノード、ingress-ssl-lego、Heapster、およびGrafana。
-* [Platform9](https://platform9.com/products/kubernetes/) offers managed Kubernetes on-premises or on any public cloud, and provides 24/7 health monitoring and alerting. (Kube2go, a web-UI driven Kubernetes cluster deployment service Platform9 released, has been integrated to Platform9 Sandbox.)
+* [Nutanix Karbon](https://www.nutanix.com/products/karbon/)は、Kubernetesのプロビジョニング、運用、ライフサイクル管理を簡素化する、マルチクラスターで可用性の高いKubernetes管理および運用プラットフォームです。
-* [Stackpoint.io](https://stackpoint.io) provides Kubernetes infrastructure automation and management for multiple public clouds.
+* [OpenShift Dedicated](https://www.openshift.com/dedicated/)は、OpenShiftを搭載したマネージドなKubernetesクラスターを提供します。
-* [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/) offers managed Kubernetes as a service powered on our OpenStack public cloud. It includes lifecycle management, administration dashboards, monitoring, autoscaling and much more.
+* [OpenShift Online](https://www.openshift.com/features/)は、Kubernetesアプリケーションに無料のホストアクセスを提供します。
-* [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) is an enterprise Kubernetes-as-a-Service offering in the VMware Cloud Services portfolio that provides easy to use, secure by default, cost effective, SaaS-based Kubernetes clusters.
+* [Oracle Container Engine for Kubernetes](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengoverview.htm)は、コンテナ化されたアプリケーションをクラウドにデプロイするために使用できる、フルマネージドかつスケーラブルで可用性の高いサービスです。
 * [Platform9](https://platform9.com/products/kubernetes/)は、オンプレミスまたはパブリッククラウド上でマネージドなKubernetesを提供し、24時間365日のヘルスモニタリングとアラートを提供します。（Kube2goは、Web UIによって駆動されるKubernetesクラスターデプロイメントサービスであるPlatform9がリリースされ、Platform9 Sandboxに統合されました）
 * [Stackpoint.io](https://stackpoint.io)は、複数のパブリッククラウドに対してKubernetesインフラストラクチャーの自動化と管理を提供します。
 * [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/)は、OpenStackのパブリッククラウドを基盤とするサービスとしてマネージドなKubernetesを提供します。ライフサイクル管理、管理ダッシュボード、モニタリング、自動スケーリングなどが含まれます。
 * [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)は、VMware Cloud ServicesポートフォリオのエンタープライズのKubernetes-as-a-Serviceであり、使いやすく、デフォルトで安全、かつ費用対効果の高いSaaSベースのKubernetesクラスターを提供します。
 ## すぐに利用できるクラウドを使ったソリューション
-These solutions allow you to create Kubernetes clusters on a range of Cloud IaaS providers with only a
+これらのソリューションを使用すると、ほんの少しのコマンドで、様々なCloud IaaSプロバイダー上にKubernetesクラスターを作成できます。
-few commands. These solutions are actively developed and have active community support.
+これらのソリューションはアクティブに開発されており、またアクティブなコミュニティー支援を受けています。
 * [Agile Stacks](https://www.agilestacks.com/products/kubernetes)
 * [Alibaba Cloud](/docs/setup/turnkey/alibaba-cloud/)
@@ -88,108 +114,128 @@ few commands. These solutions are actively developed and have active community s
 * [Azure](/docs/setup/turnkey/azure/)
 * [CenturyLink Cloud](/docs/setup/turnkey/clc/)
 * [Conjure-up Kubernetes with Ubuntu on AWS, Azure, Google Cloud, Oracle Cloud](/docs/getting-started-guides/ubuntu/)
 * [Containership](https://containership.io/containership-platform)
 * [Docker Enterprise](https://www.docker.com/products/docker-enterprise)
 * [Gardener](https://gardener.cloud/)
 * [Giant Swarm](https://giantswarm.io)
 * [Google Compute Engine (GCE)](/docs/setup/turnkey/gce/)
 * [IBM Cloud](https://github.com/patrocinio/kubernetes-softlayer)
 * [Kontena Pharos](https://kontena.io/pharos/)
 * [Kubermatic](https://cloud.kubermatic.io)
 * [Kublr](https://kublr.com/)
 * [Madcore.Ai](https://madcore.ai/)
 * [Nirmata](https://nirmata.com/)
 * [Nutanix Karbon](https://www.nutanix.com/products/karbon/)
 * [Oracle Container Engine for K8s](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengprerequisites.htm)
 * [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service)
 * [Giant Swarm](https://giantswarm.io)
 * [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/)
 * [Stackpoint.io](/docs/setup/turnkey/stackpoint/)
 * [Supergiant.io](https://supergiant.io/)
 * [Tectonic by CoreOS](https://coreos.com/tectonic)
 * [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)
 * [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)
 ## すぐに利用できるオンプレミスを使ったソリューション
-These solutions allow you to create Kubernetes clusters on your internal, secure, cloud network with only a
+これらのソリューションは、内部の安全なクラウドネットワーク上にKubernetesクラスターをほんのわずかのコマンドで作成することを可能にします。
 few commands.
 * [Agile Stacks](https://www.agilestacks.com/products/kubernetes)
 * [APPUiO](https://appuio.ch)
 * [Docker Enterprise](https://www.docker.com/products/docker-enterprise)
 * [Giant Swarm](https://giantswarm.io)
 * [GKE On-Prem | Google Cloud](https://cloud.google.com/gke-on-prem/)
 * [IBM Cloud Private](https://www.ibm.com/cloud-computing/products/ibm-cloud-private/)
 * [Kontena Pharos](https://kontena.io/pharos/)
 * [Kubermatic](https://www.loodse.com)
-* [Kublr](https://kublr.com/)
+* [Kublr](www.kublr.com/kubernetes.io/setup-hosted-solution)
 * [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/)
 * [Nirmata](https://nirmata.com/)
 * [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) by [Red Hat](https://www.redhat.com)
 * [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service)
 * [Giant Swarm](https://giantswarm.io)
 * [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/)
 * [SUSE CaaS Platform](https://www.suse.com/products/caas-platform)
 * [SUSE Cloud Application Platform](https://www.suse.com/products/cloud-application-platform/)
 * [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)
 ## カスタムソリューション
-Kubernetes can run on a wide range of Cloud providers and bare-metal environments, and with many
+Kubernetesは、幅広いクラウドプロバイダーやベアメタル環境、
-base operating systems.
+そして多くの基本オペレーティングシステム上で実行できます。
-If you can find a guide below that matches your needs, use it. It may be a little out of date, but
+もし以下のガイドからニーズに合ったものを見つけることができたなら、それを使ってください。
-it will be easier than starting from scratch. If you do want to start from scratch, either because you
+少し古くなっているかもしれませんが最初から始めるよりも簡単です。特別な要件があるため、
-have special requirements, or just because you want to understand what is underneath a Kubernetes
+またはKubernetesクラスターの下にあるものを理解したいために最初から始める必要がある場合は、
-cluster, try the [Getting Started from Scratch](/docs/setup/release/building-from-source/) guide.
+[ゼロからのカスタムクラスターの作成](/ja/docs/setup/scratch/)を試してください。
 If you are interested in supporting Kubernetes on a new platform, see
 [Writing a Getting Started Guide](https://git.k8s.io/community/contributors/devel/writing-a-getting-started-guide.md).
 ### 全般
-If you already have a way to configure hosting resources, use
+ホスティングリソースを設定する方法がすでにある場合は、
-[kubeadm](/docs/setup/independent/create-cluster-kubeadm/) to easily bring up a cluster
+[kubeadm](/docs/setup/independent/create-cluster-kubeadm/)を使用して
-with a single command per machine.
+マシン毎に単一のコマンドでクラスターを起動します。
 ### クラウド
-These solutions are combinations of cloud providers and operating systems not covered by the above solutions.
+これらのソリューションは、上記のソリューションでカバーされていないクラウドプロバイダーとオペレーティングシステムの組み合わせです。
 * [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/)
 * [CoreOS on AWS or GCE](/docs/setup/custom-cloud/coreos/)
 * [Gardener](https://gardener.cloud/)
-* [Kublr](https://kublr.com/)
+* [Kublr](www.kublr.com/kubernetes.io/setup-hosted-solution)
 * [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/)
 * [Kubespray](/docs/setup/custom-cloud/kubespray/)
 * [Rancher Kubernetes Engine (RKE)](https://github.com/rancher/rke)
 * [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS)
 ### オンプレミスの仮想マシン
-* [CloudStack](/docs/setup/on-premises-vm/cloudstack/) (uses Ansible, CoreOS and flannel)
+* [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/)
-* [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) (uses Fedora and flannel)
+* [CloudStack](/docs/setup/on-premises-vm/cloudstack/) (Ansible、CoreOSとflannelを使用します)
 * [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) (Fedoraとflannelを使用します)
 * [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization/)
 * [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com)
 * [oVirt](/docs/setup/on-premises-vm/ovirt/)
-* [Vagrant](/docs/setup/custom-cloud/coreos/) (uses CoreOS and flannel)
+* [Vagrant](/docs/setup/custom-cloud/coreos/) (CoreOSとflannelを使用します)
-* [VMware](/docs/setup/custom-cloud/coreos/) (uses CoreOS and flannel)
+* [VMware](/docs/setup/custom-cloud/coreos/) (CoreOSとflannelを使用します)
 * [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS)
 * [VMware vSphere](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)
-* [VMware vSphere, OpenStack, or Bare Metal](/docs/getting-started-guides/ubuntu/) (uses Juju, Ubuntu and flannel)
+* [VMware vSphere, OpenStack, or Bare Metal](/docs/getting-started-guides/ubuntu/) (Juju、Ubuntuとflannelを使用します)
 ### ベアメタル
 * [CoreOS](/docs/setup/custom-cloud/coreos/)
 * [Digital Rebar](/docs/setup/on-premises-metal/krib/)
 * [Docker Enterprise](https://www.docker.com/products/docker-enterprise)
 * [Fedora (Single Node)](/docs/getting-started-guides/fedora/fedora_manual_config/)
 * [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)
 * [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/)
 * [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com)
 * [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS)
 ### 統合
-These solutions provide integration with third-party schedulers, resource managers, and/or lower level platforms.
+これらのソリューションは、サードパーティー製のスケジューラー、リソースマネージャー、および/または低レベルのプラットフォームとの統合を提供します。
 * [DCOS](/docs/setup/on-premises-vm/dcos/)
-  * Community Edition DCOS uses AWS
+  * Community Edition DCOSは、AWSを使用します
-  * Enterprise Edition DCOS supports cloud hosting, on-premises VMs, and bare metal
+  * Enterprise Edition DCOSは、クラウドホスティング、オンプレミスのVM、およびベアメタルをサポートします
 ## ソリューションの表
-Below is a table of all of the solutions listed above.
+以下は上記のソリューションすべての表です。
-IaaS Provider        | Config. Mgmt. | OS     | Networking  | Docs                                              | Support Level
+IaaS プロバイダー    | 構成管理     | OS     | ネットワーク| ドキュメント                                      | サポートレベル
 -------------------- | ------------ | ------ | ----------  | ---------------------------------------------     | ----------------------------
 any                  | any          | multi-support | any CNI | [docs](/docs/setup/independent/create-cluster-kubeadm/) | Project ([SIG-cluster-lifecycle](https://git.k8s.io/community/sig-cluster-lifecycle))
 Google Kubernetes Engine |              |        | GCE         | [docs](https://cloud.google.com/kubernetes-engine/docs/) | Commercial
 Docker Enterprise    | custom | [multi-support](https://success.docker.com/article/compatibility-matrix) | [multi-support](https://docs.docker.com/ee/ucp/kubernetes/install-cni-plugin/) | [docs](https://docs.docker.com/ee/) | Commercial
 IBM Cloud Private  | Ansible  | multi-support  | multi-support  | [docs](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html) | [Commercial](https://www.ibm.com/mysupport/s/topic/0TO500000001o0fGAA/ibm-cloud-private?language=en_US&productId=01t50000004X1PWAA0) and [Community](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/troubleshoot/support_types.html) |
 Red Hat OpenShift    | Ansible & CoreOS | RHEL & CoreOS   | [multi-support](https://docs.openshift.com/container-platform/3.11/architecture/networking/network_plugins.html) | [docs](https://docs.openshift.com/container-platform/3.11/welcome/index.html) | Commercial
 Stackpoint.io        |              | multi-support       | multi-support   | [docs](https://stackpoint.io/) | Commercial
 AppsCode.com         | Saltstack    | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial
 Madcore.Ai           | Jenkins DSL  | Ubuntu | flannel     | [docs](https://madcore.ai)                        | Community ([@madcore-ai](https://github.com/madcore-ai))
 Platform9        |              | multi-support | multi-support | [docs](https://platform9.com/managed-kubernetes/) | Commercial
 Kublr       | custom       | multi-support | multi-support | [docs](http://docs.kublr.com/) | Commercial
 Kubermatic       |              | multi-support | multi-support | [docs](http://docs.kubermatic.io/) | Commercial
-IBM Cloud Kubernetes Service |               | Ubuntu | IBM Cloud Networking + Calico | [docs](https://console.bluemix.net/docs/containers/) | Commercial
+IBM Cloud Kubernetes Service |               | Ubuntu | IBM Cloud Networking + Calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial
 Giant Swarm        |              | CoreOS | flannel and/or Calico | [docs](https://docs.giantswarm.io/) | Commercial
 GCE                  | Saltstack    | Debian | GCE         | [docs](/docs/setup/turnkey/gce/)                                    | Project
 Azure Kubernetes Service |              | Ubuntu | Azure       | [docs](https://docs.microsoft.com/en-us/azure/aks/)                    |  Commercial
@@ -223,31 +269,30 @@ any                  | RKE          | multi-support    | flannel or canal
 any                  | [Gardener Cluster-Operator](https://kubernetes.io/blog/2018/05/17/gardener/) | multi-support | multi-support | [docs](https://gardener.cloud) | [Project/Community](https://github.com/gardener) and [Commercial]( https://cloudplatform.sap.com/)
 Alibaba Cloud Container Service For Kubernetes | ROS        | CentOS | flannel/Terway       | [docs](https://www.aliyun.com/product/containerservice)                    |  Commercial
 Agile Stacks       | Terraform   | CoreOS | multi-support | [docs](https://www.agilestacks.com/products/kubernetes) | Commercial
-IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://console.bluemix.net/docs/containers/container_index.html) | Commercial
+IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial
 Digital Rebar        | kubeadm      | any    | metal       | [docs](/docs/setup/on-premises-metal/krib/)                                  | Community ([@digitalrebar](https://github.com/digitalrebar))
 VMware Cloud PKS     |              | Photon OS | Canal | [docs](https://docs.vmware.com/en/VMware-Kubernetes-Engine/index.html) | Commercial
 VMware Enterprise PKS     | BOSH       | Ubuntu | VMware NSX-T/flannel | [docs](https://docs.vmware.com/en/VMware-Enterprise-PKS/) | Commercial
 Mirantis Cloud Platform | Salt | Ubuntu | multi-support | [docs](https://docs.mirantis.com/mcp/) | Commercial
 {{< note >}}
-The above table is ordered by version test/used in nodes, followed by support level.
+上記の表はバージョンテスト/ノード内での使用順に並べられ、その後にサポートレベルが続きます。
 {{< /note >}}
 ### カラムの定義
-* **IaaS Provider** is the product or organization which provides the virtual or physical machines (nodes) that Kubernetes runs on.
+* **IaaSプロバイダー**は、Kubernetesが動作する仮想マシンまたは物理マシン（ノード）を提供する製品または組織です。
-* **OS** is the base operating system of the nodes.
+* **OS**は、ノードのベースのオペレーティングシステムです。
-* **Config. Mgmt.** is the configuration management system that helps install and maintain Kubernetes on the
+* **構成管理**は、ノードにKubernetesをインストール・保守するのに役立つ構成管理システムです。
-  nodes.
+* **ネットワーク**は、[ネットワークモデル](/docs/concepts/cluster-administration/networking/)を実装したものです。ネットワークタイプが、
-* **Networking** is what implements the [networking model](/docs/concepts/cluster-administration/networking/). Those with networking type
+  _none_ のものは、複数のノードをサポートしていない場合や、単一の物理ノードで複数のVMノードをサポートしている場合があります。
-  _none_ may not support more than a single node, or may support multiple VM nodes in a single physical node.
+* **適合**は、この設定で作成されたクラスターが、Kubernetes v1.0.0のAPIおよび基本機能をサポートするためのプロジェクトの適合性テストに合格したかどうかを示します。
-* **Conformance** indicates whether a cluster created with this configuration has passed the project's conformance
+* **サポートレベル**
-  tests for supporting the API and base features of Kubernetes v1.0.0.
+  * **プロジェクト**: Kubernetesのコミッターは通常この設定を使用しているため、ほとんどの場合Kubernetesの最新リリースで動作します。
-* **Support Levels**
+  * **商用**: 独自のサポート契約がある商用製品。
-  * **Project**: Kubernetes committers regularly use this configuration, so it usually works with the latest release
+  * **コミュニティー**: コミュニティーの貢献によって積極的にサポートされています。 Kubernetesの最近のリリースでは動作しない可能性があります。
-    of Kubernetes.
+  * **非アクティブ**: 積極的にメンテナンスされていません。初めてのKubernetesユーザーにはお勧めできません。削除される可能性があります。
-  * **Commercial**: A commercial offering with its own support arrangements.
+* **注意事項**には、使用されているKubernetesのバージョンなど、その他の関連情報があります。
  * **Community**: Actively supported by community contributions. May not work with recent releases of Kubernetes.
  * **Inactive**: Not actively maintained. Not recommended for first-time Kubernetes users, and may be removed.
 * **Notes** has other relevant information, such as the version of Kubernetes used.
 <!-- reference style links below here -->
 <!-- GCE conformance test result -->
@@ -1,14 +1,21 @@
 ---
-title: ソースからのビルド
+title: リリースのビルド
 content_template: templates/concept
 card:
  name: download
  weight: 20
  title: リリースのビルド
 ---
-
+{{% capture overview %}}
-あなたはソースからリリースをビルドすることもできますし、既にビルドされたリリースをダウンロードすることも可能です。もしあなたがKubernetesを開発する予定が無いのであれば、[リリースノート](/docs/setup/release/notes/)内の現在リリースされている既にビルドされたバージョンを使用することを推奨します。
+ソースコードからリリースをビルドすることもできますし、既にビルドされたリリースをダウンロードすることも可能です。Kubernetesを開発する予定が無いのであれば、[リリースノート](/docs/setup/release/notes/)内にて既にビルドされたバージョンを使用することを推奨します。
 Kubernetes のソースコードは[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)のリポジトリからダウンロードすることが可能です。
 {{% /capture %}}
 {{% capture body %}}
 ## ソースからのビルド
-もしあなたが単にソースからリリースをビルドするだけなのであれば、完全なGOの環境を準備する必要はなく、全てのビルドはDockerコンテナの中で行われます。
+単にソースからリリースをビルドするだけであれば、完全なGOの環境を準備する必要はなく、全てのビルドはDockerコンテナの中で行われます。
 リリースをビルドすることは簡単です。
@@ -19,3 +26,5 @@ make release
 ```
 リリース手段の詳細な情報はkubernetes/kubernetes内の[`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/)ディレクトリを参照して下さい。
 {{% /capture %}}
@@ -4,9 +4,9 @@ title: Alibaba CloudでKubernetesを動かす
 ## Alibaba Cloud Container Service
-[Alibaba Cloud Container Service](https://www.aliyun.com/product/containerservice)はAlibaba Cloud ECSインスタンスのクラスター上でDockerアプリケーションを起動して管理します。著名なオープンソースのコンテナオーケストレーターであるDocker SwarmおよびKubernetesをサポートしています。
+[Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service)はAlibaba Cloud ECSインスタンスのクラスター上でDockerアプリケーションを起動して管理します。著名なオープンソースのコンテナオーケストレーターであるDocker SwarmおよびKubernetesをサポートしています。
-クラスターの構築と管理を簡素化する為に、[Alibaba Cloud Container Serviceの為のKubernetesサポート](https://www.aliyun.com/solution/kubernetes/)を使用します。[Kubernetes walk-through](https://help.aliyun.com/document_detail/53751.html)に従ってすぐに始めることができ、中国語の[Alibaba CloudにおけるKubernetesサポートの為のチュートリアル](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)もあります。
+クラスターの構築と管理を簡素化する為に、[Alibaba Cloud Container Serviceの為のKubernetesサポート](https://www.alibabacloud.com/product/kubernetes)を使用します。[Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm)に従ってすぐに始めることができ、中国語の[Alibaba CloudにおけるKubernetesサポートの為のチュートリアル](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)もあります。 
 カスタムバイナリもしくはオープンソースKubernetesを使用する場合は、以下の手順に従って下さい。
@@ -10,18 +10,18 @@ Azure Kubernetes Serviceを利用してAzure上にKubernetesクラスターを
 **[Microsoft Azure Kubernetes Service](https://docs.microsoft.com/ja-jp/azure/aks/intro-kubernetes)**
-## デプロイのカスタマイズ: ACS-Engine
+## デプロイのカスタマイズ: AKS-Engine
-Azure Kubernetes Serviceのコア部分は**オープンソース**であり、コミュニティのためにGitHub上で公開され、利用およびコントリビュートすることができます: **[ACS-Engine](https://github.com/Azure/acs-engine)**.
+Azure Kubernetes Serviceのコア部分は**オープンソース**であり、コミュニティのためにGitHub上で公開され、利用およびコントリビュートすることができます: **[AKS-Engine](https://github.com/Azure/aks-engine)**。レガシーな [ACS-Engine](https://github.com/Azure/acs-engine) のコードベースはAKS-engineのために廃止となりました。
-ACS-Engineは、Azure Kubernetes Serviceが公式にサポートしている機能を超えてデプロイをカスタマイズしたい場合に適した選択肢です。
+AKS-Engineは、Azure Kubernetes Serviceが公式にサポートしている機能を超えてデプロイをカスタマイズしたい場合に適した選択肢です。
 既存の仮想ネットワークへのデプロイや、複数のagent poolを利用するなどのカスタマイズをすることができます。
-コミュニティによるACS-Engineへのコントリビュートが、Azure Kubernetes Serviceに組み込まれる場合もあります。
+コミュニティによるAKS-Engineへのコントリビュートが、Azure Kubernetes Serviceに組み込まれる場合もあります。
-ACS-Engineへの入力は、Azure Kubernetes Serviceを使用してクラスターを直接デプロイすることに利用されるARMテンプレートの構文に似ています。
+AKS-Engineへの入力は、Kubernetesクラスターを記述するapimodelのJSONファイルです。これはAzure Kubernetes Serviceを使用してクラスターを直接デプロイするために使用されるAzure Resource Manager (ARM) のテンプレート構文と似ています。
-処理結果はAzure Resource Managerテンプレートとして出力され、ソース管理に組み込んだり、AzureにKubernetesクラスターをデプロイするために使うことができます。
+処理結果はARMテンプレートとして出力され、ソース管理に組み込んだり、AzureにKubernetesクラスターをデプロイするために使うことができます。
-**[ACS-Engine Kubernetes Walkthrough](https://github.com/Azure/acs-engine/blob/master/docs/kubernetes.md)** を参照して、すぐに始めることができます。
+**[AKS-Engine Kubernetes Tutorial](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/README.md)** を参照して始めることができます。
 ## Azure上でCoreOS Tectonicを動かす
@@ -288,7 +288,7 @@ Various configuration files are written into the home directory *CLC_CLUSTER_HOM
 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
+* ```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
@@ -5,7 +5,7 @@ content_template: templates/task
 {{% capture overview %}}
-The example below creates a Kubernetes cluster with 4 worker node Virtual Machines and a master Virtual Machine (i.e. 5 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient).
+The example below creates a Kubernetes cluster with 3 worker node Virtual Machines and a master Virtual Machine (i.e. 4 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient).
 {{% /capture %}}
@@ -161,7 +161,7 @@ Likewise, the `kube-up.sh` in the same directory will bring it back up. You do n
 ## カスタマイズ
 The script above relies on Google Storage to stage the Kubernetes release. It
-then will start (by default) a single master VM along with 4 worker VMs.  You
+then will start (by default) a single master VM along with 3 worker VMs.  You
 can tweak some of these parameters by editing `kubernetes/cluster/gce/config-default.sh`
 You can view a transcript of a successful cluster creation
 [here](https://gist.github.com/satnam6502/fc689d1b46db9772adea).
@@ -0,0 +1,67 @@
 ---
 title: IBM Cloud Privateを使ってマルチクラウドでKubernetesを動かす
 ---
 IBM® Cloud Private is a turnkey cloud solution and an on-premises turnkey cloud solution. IBM Cloud Private delivers pure upstream Kubernetes with the typical management components that are required to run real enterprise workloads. These workloads include health management, log management, audit trails, and metering for tracking usage of workloads on the platform.
 IBM Cloud Private is available in a community edition and a fully supported enterprise edition. The community edition is available at no charge from [Docker Hub](https://hub.docker.com/r/ibmcom/icp-inception/). The enterprise edition supports high availability topologies and includes commercial support from IBM for Kubernetes and the IBM Cloud Private management platform. If you want to try IBM Cloud Private, you can use either the hosted trial, the tutorial, or the self-guided demo. You can also try the free community edition. For details, see [Get started with IBM Cloud Private](https://www.ibm.com/cloud/private/get-started).
 For more information, explore the following resources:
 * [IBM Cloud Private](https://www.ibm.com/cloud/private)
 * [Reference architecture for IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud)
 * [IBM Cloud Private documentation](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html)
 ## IBM Cloud PrivateとTerraform
 The following modules are available where you can deploy IBM Cloud Private by using Terraform:
 * AWS: [Deploy IBM Cloud Private to AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws)
 * Azure: [Deploy IBM Cloud Private to Azure](https://github.com/ibm-cloud-architecture/terraform-icp-azure)
 * IBM Cloud: [Deploy IBM Cloud Private cluster to IBM Cloud](https://github.com/ibm-cloud-architecture/terraform-icp-ibmcloud)
 * OpenStack: [Deploy IBM Cloud Private to OpenStack](https://github.com/ibm-cloud-architecture/terraform-icp-openstack)
 * Terraform module: [Deploy IBM Cloud Private on any supported infrastructure vendor](https://github.com/ibm-cloud-architecture/terraform-module-icp-deploy)
 * VMware: [Deploy IBM Cloud Private to VMware](https://github.com/ibm-cloud-architecture/terraform-icp-vmware)
 ## AWS上でのIBM Cloud Private
 You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) by using either AWS CloudFormation or Terraform.
 IBM Cloud Private has a Quick Start that automatically deploys IBM Cloud Private into a new virtual private cloud (VPC) on the AWS Cloud. A regular deployment takes about 60 minutes, and a high availability (HA) deployment takes about 75 minutes to complete. The Quick Start includes AWS CloudFormation templates and a deployment guide.
 This Quick Start is for users who want to explore application modernization and want to accelerate meeting their digital transformation goals, by using IBM Cloud Private and IBM tooling. The Quick Start helps users rapidly deploy a high availability (HA), production-grade, IBM Cloud Private reference architecture on AWS. For all of the details and the deployment guide, see the [IBM Cloud Private on AWS Quick Start](https://aws.amazon.com/quickstart/architecture/ibm-cloud-private/).
 IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_aws.md).
 ## Azure上でのIBM Cloud Private
 You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/supported_environments/azure_overview.html).
 ## Red Hat OpenShift上でのIBM Cloud Private
 You can deploy IBM certified software containers that are running on IBM Cloud Private onto Red Hat OpenShift.
 Integration capabilities:
 * Supports Linux® 64-bit platform in offline-only installation mode
 * Single-master configuration
 * Integrated IBM Cloud Private cluster management console and catalog
 * Integrated core platform services, such as monitoring, metering, and logging
 * IBM Cloud Private uses the OpenShift image registry
 For more information see, [IBM Cloud Private on OpenShift](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/supported_environments/openshift/overview.html).
 ## VirtualBox上でのIBM Cloud Private
 To install IBM Cloud Private to a VirtualBox environment, see [Installing IBM Cloud Private on VirtualBox](https://github.com/ibm-cloud-architecture/refarch-privatecloud-virtualbox).
 ## VMware上でのIBM Cloud Private
 You can install IBM Cloud Private on VMware with either Ubuntu or RHEL images. For details, see the following projects:
 * [Installing IBM Cloud Private with Ubuntu](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_prem_ubuntu.md)
 * [Installing IBM Cloud Private with Red Hat Enterprise](https://github.com/ibm-cloud-architecture/refarch-privatecloud/tree/master/icp-on-rhel)
 The IBM Cloud Private Hosted service automatically deploys IBM Cloud Private Hosted on your VMware vCenter Server instances. This service brings the power of microservices and containers to your VMware environment on IBM Cloud. With this service, you can extend the same familiar VMware and IBM Cloud Private operational model and tools from on-premises into the IBM Cloud.
 For more information, see [IBM Cloud Private Hosted service](https://cloud.ibm.com/docs/services/vmwaresolutions/vmonic?topic=vmware-solutions-prod_overview#ibm-cloud-private-hosted).
@@ -0,0 +1,141 @@
 ---
 title: Kubernetesバージョンとバージョンスキューサポートポリシー
 content_template: templates/concept
 weight: 70
 ---
 {{% capture overview %}}
 This document describes the maximum version skew supported between various Kubernetes components.
 Specific cluster deployment tools may place additional restrictions on version skew.
 {{% /capture %}}
 {{% capture body %}}
 ## サポートされるバージョン
 Kubernetes versions are expressed as **x.y.z**,
 where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](http://semver.org/) terminology.
 For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning).
 The Kubernetes project maintains release branches for the most recent three minor releases.
 Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility.
 Patch releases are cut from those branches at a regular cadence, or as needed.
 This decision is owned by the [patch release manager](https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/patch-release-manager/README.md#release-timing).
 The patch release manager is a member of the [release team for each release](https://github.com/kubernetes/sig-release/tree/master/releases/).
 Minor releases occur approximately every 3 months, so each minor release branch is maintained for approximately 9 months.
 ## サポートされるバージョンスキュー
 ### kube-apiserver
 In [highly-availabile (HA) clusters](https://kubernetes.io/docs/setup/independent/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version.
 Example:
 * newest `kube-apiserver` is at **1.13**
 * other `kube-apiserver` instances are supported at **1.13** and **1.12**
 ### kubelet
 `kubelet` must not be newer than `kube-apiserver`, and may be up to two minor versions older.
 Example:
 * `kube-apiserver` is at **1.13**
 * `kubelet` is supported at **1.13**, **1.12**, and **1.11**
 {{< note >}}
 If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kubelet` versions.
 {{</ note >}}
 Example:
 * `kube-apiserver` instances are at **1.13** and **1.12**
 * `kubelet` is supported at **1.12**, and **1.11** (**1.13** is not supported because that would be newer than the `kube-apiserver` instance at version **1.12**)
 ### kube-controller-manager、kube-scheduler、およびcloud-controller-manager
 `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` must not be newer than the `kube-apiserver` instances they communicate with. They are expected to match the `kube-apiserver` minor version, but may be up to one minor version older (to allow live upgrades).
 Example:
 * `kube-apiserver` is at **1.13**
 * `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **1.13** and **1.12**
 {{< note >}}
 If version skew exists between `kube-apiserver` instances in an HA cluster, and these components can communicate with any `kube-apiserver` instance in the cluster (for example, via a load balancer), this narrows the allowed versions of these components.
 {{< /note >}}
 Example:
 * `kube-apiserver` instances are at **1.13** and **1.12**
 * `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` communicate with a load balancer that can route to any `kube-apiserver` instance
 * `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **1.12** (**1.13** is not supported because that would be newer than the `kube-apiserver` instance at version **1.12**)
 ### kubectl
 `kubectl` is supported within one minor version (older or newer) of `kube-apiserver`.
 Example:
 * `kube-apiserver` is at **1.13**
 * `kubectl` is supported at **1.14**, **1.13**, and **1.12**
 {{< note >}}
 If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the supported `kubectl` versions.
 {{< /note >}}
 Example:
 * `kube-apiserver` instances are at **1.13** and **1.12**
 * `kubectl` is supported at **1.13** and **1.12** (other versions would be more than one minor version skewed from one of the `kube-apiserver` components)
 ## サポートされるコンポーネントのアップグレード順序
 The supported version skew between components has implications on the order in which components must be upgraded.
 This section describes the order in which components must be upgraded to transition an existing cluster from version **1.n** to version **1.(n+1)**.
 ### kube-apiserver
 Pre-requisites:
 * In a single-instance cluster, the existing `kube-apiserver` instance is **1.n**
 * In an HA cluster, all `kube-apiserver` instances are at **1.n** or **1.(n+1)** (this ensures maximum skew of 1 minor version between the oldest and newest `kube-apiserver` instance)
 * The `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` instances that communicate with this server are at version **1.n** (this ensures they are not newer than the existing API server version, and are within 1 minor version of the new API server version)
 * `kubelet` instances on all nodes are at version **1.n** or **1.(n-1)** (this ensures they are not newer than the existing API server version, and are within 2 minor versions of the new API server version)
 * Registered admission webhooks are able to handle the data the new `kube-apiserver` instance will send them:
  * `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` objects are updated to include any new versions of REST resources added in **1.(n+1)**
  * The webhooks are able to handle any new versions of REST resources that will be sent to them, and any new fields added to existing versions in **1.(n+1)**
 Upgrade `kube-apiserver` to **1.(n+1)**
 {{< note >}}
 Project policies for [API deprecation](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) and 
 [API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md) 
 require `kube-apiserver` to not skip minor versions when upgrading, even in single-instance clusters.
 {{< /note >}}
 ### kube-controller-manager、kube-scheduler、およびcloud-controller-manager
 Pre-requisites:
 * The `kube-apiserver` instances these components communicate with are at **1.(n+1)** (in HA clusters in which these control plane components can communicate with any `kube-apiserver` instance in the cluster, all `kube-apiserver` instances must be upgraded before upgrading these components)
 Upgrade `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` to **1.(n+1)**
 ### kubelet
 Pre-requisites:
 * The `kube-apiserver` instances the `kubelet` communicates with are at **1.(n+1)**
 Optionally upgrade `kubelet` instances to **1.(n+1)** (or they can be left at **1.n** or **1.(n-1)**)
 {{< warning >}}
 Running a cluster with `kubelet` instances that are persistently two minor versions behind `kube-apiserver` is not recommended:
 * they must be upgraded within one minor version of `kube-apiserver` before the control plane can be upgraded
 * it increases the likelihood of running `kubelet` versions older than the three maintained minor releases
 {{</ warning >}}
@@ -8,6 +8,9 @@ menu:
    weight: 10
    post: >
      <p>手を動かす準備はできていますか？本チュートリアルでは、Node.jsを使った簡単な"Hello World"を実行するKubernetesクラスタをビルドします。</p>
 card: 
  name: tutorials
  weight: 10
 ---
 {{% capture overview %}}
@@ -58,7 +61,7 @@ menu:
 3. Katacoda環境のみ：ターミナルペーン上部の+ボタンをクリックしてから **Select port to view on Host 1** をクリックしてください。
-4. Katacoda環境のみ：30000を入力し、**Display Port**をクリックしてください。 
+4. Katacoda環境のみ：`30000`を入力し、**Display Port**をクリックしてください。 
 ## Deploymentの作成
@@ -67,7 +70,7 @@ Kubernetesの[*Pod*](/docs/concepts/workloads/pods/pod/) は、コンテナの
 1. `kubectl create` コマンドを使用してPodを管理するDeploymentを作成してください。Podは提供されたDockerイメージを元にコンテナを実行します。
    ```shell
-    kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node --port=8080
+    kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
    ```
 2. Deploymentを確認します:
@@ -116,7 +119,7 @@ Kubernetesの[*Pod*](/docs/concepts/workloads/pods/pod/) は、コンテナの
 1. `kubectl expose` コマンドを使用してPodをインターネットに公開します:
    ```shell
-    kubectl expose deployment hello-node --type=LoadBalancer
+    kubectl expose deployment hello-node --type=LoadBalancer --port=8080
    ```
    `--type=LoadBalancer`フラグはServiceをクラスタ外部に公開したいことを示しています。
@@ -146,7 +149,7 @@ Kubernetesの[*Pod*](/docs/concepts/workloads/pods/pod/) は、コンテナの
 4. Katacoda環境のみ：ターミナル画面上部の+ボタンをクリックして **Select port to view on Host 1** をクリックしてください。
-5. Katacoda環境のみ：8080を入力し、**Display Port**をクリックしてください。 
+5. Katacoda環境のみ：`30369`(Service出力に表示されている`8080`の反対側のポートを参照)を入力し、クリックしてください。
    "Hello World"メッセージが表示されるアプリケーションのブラウザウィンドウが開きます。
@@ -2,6 +2,10 @@
 title: Kubernetesの基本を学ぶ
 linkTitle: Kubernetesの基本を学ぶ
 weight: 10
 card:
  name: tutorials
  weight: 20
  title: 基本のチュートリアル
 ---
 <!DOCTYPE html>
@@ -17,7 +21,7 @@ weight: 10
    <div class="row">
      <div class="col-md-9">
        <h2>Kubernetesの基本</h2>
-        <p>このチュートリアルでは、Kubernetesクラスタオーケストレーションシステムの基本について学びます。各モジュールには、Kubernetesの主な機能と概念に関する背景情報と、インタラクティブなオンラインチュートリアルが含まれています。これらの対話型チュートリアルでは、簡単なクラスタとその<a href="/ja/docs/concepts/overview/what-is-kubernetes/#why-containers">コンテナ化されたアプリケーション</a> を自分で管理できます。</p>
+        <p>このチュートリアルでは、Kubernetesクラスタオーケストレーションシステムの基本について学びます。各モジュールには、Kubernetesの主な機能と概念に関する背景情報と、インタラクティブなオンラインチュートリアルが含まれています。これらの対話型チュートリアルでは、簡単なクラスタとそのコンテナ化されたアプリケーションを自分で管理できます。</p>
        <p>この対話型のチュートリアルでは、以下のことを学ぶことができます:</p>
        <ul>
        <li>コンテナ化されたアプリケーションをクラスタにデプロイ</li>
@@ -34,7 +38,7 @@ weight: 10
    <div class="row">
      <div class="col-md-9">
        <h2>Kubernetesはどんなことができるの?</h2>
-        <p>モダンなWebサービスでは、ユーザはアプリケーションが24時間365日利用可能であることを期待しており、開発者はそれらのアプリケーションの新しいバージョンを1日に数回デプロイすることを期待しています。コンテナ化は、パッケージソフトウェアがこれらの目標を達成するのを助け、アプリケーションをダウンタイムなしで簡単かつ迅速にリリース、アップデートできるようにします。Kubernetesを使用すると、コンテナ化されたアプリケーションをいつでもどこでも好きなときに実行できるようになり、それらが機能するために必要なリソースとツールを見つけやすくなります。<a href="/ja/docs/concepts/overview/what-is-kubernetes/">Kubernetes</a>は、コンテナオーケストレーションにおけるGoogleのこれまでの経験と、コミュニティから得られた最善のアイデアを組み合わせて設計された、プロダクションレディなオープンソースプラットフォームです。</p>
+        <p>モダンなWebサービスでは、ユーザはアプリケーションが24時間365日利用可能であることを期待しており、開発者はそれらのアプリケーションの新しいバージョンを1日に数回デプロイすることを期待しています。コンテナ化は、パッケージソフトウェアがこれらの目標を達成するのを助け、アプリケーションをダウンタイムなしで簡単かつ迅速にリリース、アップデートできるようにします。Kubernetesを使用すると、コンテナ化されたアプリケーションをいつでもどこでも好きなときに実行できるようになり、それらが機能するために必要なリソースとツールを見つけやすくなります。Kubernetesは、コンテナオーケストレーションにおけるGoogleのこれまでの経験と、コミュニティから得られた最善のアイデアを組み合わせて設計された、プロダクションレディなオープンソースプラットフォームです。</p>
      </div>
    </div>
@@ -29,7 +29,7 @@ weight: 10
            <div class="col-md-8">
                <h3>Kubernetesクラスタ</h3>
                <p>
-                <b>Kubernetesは、単一のユニットとして機能するように接続された、可用性の高いコンピュータのクラスタをまとめあげます。</b>Kubernetesの抽象化により、コンテナ化されたアプリケーションを個々のマシンに特に結び付けることなくクラスタにデプロイできます。この新しいデプロイモデルを利用するには、アプリケーションを個々のホストから切り離す方法でアプリケーションをパッケージ化(つまり、コンテナ化)する必要があります。コンテナ化されたアプリケーションは、アプリケーションがホストに深く統合されたパッケージとして特定のマシンに直接インストールされていた従来のデプロイモデルよりも柔軟で、より迅速に利用可能です。<b>Kubernetesはより効率的な方法で、クラスタ全体のアプリケーションコンテナの配布とスケジューリングを自動化します。</b>Kubernetesは<a href="https://github.com/kubernetes/kubernetes">オープンソース</a>のプラットフォームであり、プロダクションレディです。
+                <b>Kubernetesは、単一のユニットとして機能するように接続された、可用性の高いコンピュータのクラスタをまとめあげます。</b>Kubernetesの抽象化により、コンテナ化されたアプリケーションを個々のマシンに特に結び付けることなくクラスタにデプロイできます。この新しいデプロイモデルを利用するには、アプリケーションを個々のホストから切り離す方法でアプリケーションをパッケージ化(つまり、コンテナ化)する必要があります。コンテナ化されたアプリケーションは、アプリケーションがホストに深く統合されたパッケージとして特定のマシンに直接インストールされていた従来のデプロイモデルよりも柔軟で、より迅速に利用可能です。<b>Kubernetesはより効率的な方法で、クラスタ全体のアプリケーションコンテナの配布とスケジューリングを自動化します。</b>Kubernetesはオープンソースのプラットフォームであり、プロダクションレディです。
                </p>
                <p>Kubernetesクラスタは以下の2種類のリソースで構成されています:
                    <ul>
@@ -72,7 +72,7 @@ weight: 10
        <div class="row">
            <div class="col-md-8">
                <p><b>マスターはクラスタの管理を担当します。</b>マスターは、アプリケーションのスケジューリング、望ましい状態の維持、アプリケーションのスケーリング、新しい更新のロールアウトなど、クラスタ内のすべての動作をまとめあげます。</p>
-                <p><b>Nodeは、Kubernetesクラスタのワーカーマシンとして機能するVMまたは物理マシンです。</b>各NodeにはKubeletがあり、これはNodeを管理し、Kubernetesマスターと通信するためのエージェントです。Nodeには<a href="https://www.docker.com/">Docker</a>や<a href="https://coreos.com/rkt/">rkt</a>などのコンテナ操作を処理するためのツールもあるはずです。プロダクションのトラフィックを処理するKubernetesクラスタには、最低3つのNodeが必要です。</p>
+                <p><b>Nodeは、Kubernetesクラスタのワーカーマシンとして機能するVMまたは物理マシンです。</b>各NodeにはKubeletがあり、これはNodeを管理し、Kubernetesマスターと通信するためのエージェントです。NodeにはDockerやrktなどのコンテナ操作を処理するためのツールもあるはずです。プロダクションのトラフィックを処理するKubernetesクラスタには、最低3つのNodeが必要です。</p>
            </div>
            <div class="col-md-4">
@@ -86,7 +86,7 @@ weight: 10
            <div class="col-md-8">
                <p>Kubernetesにアプリケーションをデプロイするときは、マスターにアプリケーションコンテナを起動するように指示します。マスターはコンテナがクラスタのNodeで実行されるようにスケジュールします。<b>Nodeは、マスターが公開しているKubernetes APIを使用してマスターと通信します。</b>エンドユーザーは、Kubernetes APIを直接使用して対話することもできます。</p>
-                <p>Kubernetesクラスタは、物理マシンまたは仮想マシンのどちらにも配置できます。Kubernetes開発を始めるために<a href="https://github.com/kubernetes/minikube">Minikube</a>を使うことができます。Minikubeは、ローカルマシン上にVMを作成し、1つのNodeのみを含む単純なクラスタをデプロイする軽量なKubernetes実装です。Minikubeは、Linux、macOS、およびWindowsシステムで利用可能です。Minikube CLIは、起動、停止、ステータス、削除など、クラスタを操作するための基本的なブートストラップ操作を提供します。ただし、このチュートリアルでは、Minikubeがプリインストールされた状態で提供されているオンラインのターミナルを使用します。</p>
+                <p>Kubernetesクラスタは、物理マシンまたは仮想マシンのどちらにも配置できます。Kubernetes開発を始めるためにMinikubeを使うことができます。Minikubeは、ローカルマシン上にVMを作成し、1つのNodeのみを含む単純なクラスタをデプロイする軽量なKubernetes実装です。Minikubeは、Linux、macOS、およびWindowsシステムで利用可能です。Minikube CLIは、起動、停止、ステータス、削除など、クラスタを操作するための基本的なブートストラップ操作を提供します。ただし、このチュートリアルでは、Minikubeがプリインストールされた状態で提供されているオンラインのターミナルを使用します。</p>
                <p>Kubernetesが何であるかがわかったので、オンラインチュートリアルに行き、最初のクラスタを動かしましょう！</p>
@@ -31,7 +31,7 @@ weight: 10
                実行中のKubernetesクラスタを入手すると、その上にコンテナ化アプリケーションをデプロイすることができます。そのためには、Kubernetesの<b>Deployment</b> の設定を作成します。DeploymentはKubernetesにあなたのアプリケーションのインスタンスを作成し、更新する方法を指示します。Deploymentを作成すると、Kubernetesマスターは指定されたアプリケーションインスタンスをクラスタ内の個々のNodeにスケジュールします。
                </p>
-                <p>アプリケーションインスタンスが作成されると、Kubernetes Deploymentコントローラーは、それらのインスタンスを継続的に監視します。インスタンスをホストしているNodeが停止、削除された場合、Deploymentコントローラーがそれを置き換えます。<b>これは、マシンの故障やメンテナンスに対処するためのセルフヒーリングの仕組みを提供しています。</b></p>
+                <p>アプリケーションインスタンスが作成されると、Kubernetes Deploymentコントローラーは、それらのインスタンスを継続的に監視します。インスタンスをホストしているNodeが停止、削除された場合、Deploymentコントローラーはそのインスタンスをクラスター内の別のノード上のインスタンスと置き換えます。<b>これは、マシンの故障やメンテナンスに対処するためのセルフヒーリングの仕組みを提供しています。</b></p>
                <p>オーケストレーションが入る前の世界では、インストールスクリプトを使用してアプリケーションを起動することはよくありましたが、マシン障害が発生した場合に復旧する事はできませんでした。アプリケーションのインスタンスを作成し、それらをNode間で実行し続けることで、Kubernetes Deploymentsはアプリケーションの管理に根本的に異なるアプローチを提供します。</p>
@@ -85,7 +85,7 @@ weight: 10
        <div class="row">
            <div class="col-md-8">
-                <p>最初のDeploymentには、Dockerコンテナにパッケージされた<a href="https://nodejs.org">Node.js</a>アプリケーションを使用します。Node.jsアプリケーションを作成してDockerコンテナをデプロイするには、<a href="/ja/docs/tutorials/hello-minikube/#create-your-node-js-application">Hello Minikubeチュートリアル</a>の指示に従ってください。</p>
+                <p>最初のDeploymentには、DockerコンテナにパッケージされたNode.jsアプリケーションを使用します。Node.jsアプリケーションを作成してDockerコンテナをデプロイするには、<a href="/ja/docs/tutorials/hello-minikube/">Hello Minikubeチュートリアル</a>の指示に従ってください。</p>
                <p>Deploymentが何であるかがわかったので、オンラインチュートリアルに行き、最初のアプリケーションをデプロイしましょう！</p>
@@ -28,9 +28,9 @@ weight: 10
 			<div class="col-md-8">
 			<h3>Kubernetes Serviceの概要</h3>
-			<p>Kubernetes Podの寿命は永続的ではありません。実際、<a href="/ja/docs/concepts/workloads/pods/pod-overview/">Pod</a>には<a href="/ja/docs/concepts/workloads/pods/pod-lifecycle/">ライフサイクル</a>があります。ワーカーのNodeが停止すると、そのNodeで実行されているPodも失われます。そうなると、<a href="/ja/docs/user-guide/replication-controller/#what-is-a-replicationcontroller">ReplicationController</a>は、新しいPodを作成してアプリケーションを実行し続けるために、クラスタを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスタ内の各Podは、同じNode上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。</p>
+			<p>Kubernetes Podの寿命は永続的ではありません。実際、<a href="/docs/concepts/workloads/pods/pod-overview/">Pod</a>には<a href="/docs/concepts/workloads/pods/pod-lifecycle/">ライフサイクル</a>があります。ワーカーのNodeが停止すると、そのNodeで実行されているPodも失われます。そうなると、<a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a>は、新しいPodを作成してアプリケーションを実行し続けるために、クラスタを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスタ内の各Podは、同じNode上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。</p>
-			<p>KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML<a href="/ja/docs/concepts/configuration/overview/#general-config-tips">(推奨)</a>またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、<i>LabelSelector</i>によって決定されます(なぜ仕様に<code>セレクタ</code>を含めずにServiceが必要になるのかについては下記を参照してください)。</p>
+			<p>KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML<a href="/docs/concepts/configuration/overview/#general-configuration-tips">(推奨)</a>またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、<i>LabelSelector</i>によって決定されます(なぜ仕様に<code>セレクタ</code>を含めずにServiceが必要になるのかについては下記を参照してください)。</p>
 			<p>各Podには固有のIPアドレスがありますが、それらのIPは、Serviceなしではクラスタの外部に公開されません。Serviceによって、アプリケーションはトラフィックを受信できるようになります。ServiceSpecで<code>type</code>を指定することで、Serviceをさまざまな方法で公開することができます。</p>
 			<ul>
@@ -39,7 +39,7 @@ weight: 10
 				<li><i>LoadBalancer</i> - 現在のクラウドに外部ロードバランサを作成し(サポートされている場合)、Serciceに固定の外部IPを割り当てます。これはNodePortのスーパーセットです。</li>
 				<li><i>ExternalName</i> - 仕様の<code>externalName</code>で指定した名前のCNAMEレコードを返すことによって、任意の名前を使ってServiceを公開します。プロキシは使用されません。このタイプはv1.7以上の<code>kube-dns</code>を必要とします。</li>
 			</ul>
-			<p>さまざまな種類のServiceに関する詳細情報は<a href="/ja/docs/tutorials/services/source-ip/">Using Source IP</a> tutorialにあります。<a href="/ja/docs/concepts/services-networking/connect-applications-service">アプリケーションとServiceの接続</a>も参照してください。</p>
+			<p>さまざまな種類のServiceに関する詳細情報は<a href="/docs/tutorials/services/source-ip/">Using Source IP</a> tutorialにあります。<a href="/docs/concepts/services-networking/connect-applications-service">アプリケーションとServiceの接続</a>も参照してください。</p>
 			<p>加えて、Serviceには、仕様に<code>selector</code>を定義しないというユースケースがいくつかあります。<code>selector</code>を指定せずに作成したServiceについて、対応するEndpointsオブジェクトは作成されません。これによって、ユーザーは手動でServiceを特定のエンドポイントにマッピングできます。セレクタがない可能性があるもう1つの可能性は、<code>type：ExternalName</code>を厳密に使用していることです。</p>
 			</div>
 			<div class="col-md-4">