First Japanese l10n work for release-1.15. (#17693)

* traslate /docs/concepts/architecture/_index.md into Japanese (#15456) * tranaslated (#15458) * translate /ja/docs/reference/_index.md (#15624) * translate /ja/docs/reference/_index.md * Update content/ja/docs/reference/_index.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/_index.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/_index.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * patch reviews * Follow the dir structure of en in setup (#15590) * follow the dir structure of en in setup * delete unrelated files * wip removing ja * removeg ja * remove ja * Update content/ja/docs/setup/_index.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * review * numbered list * Update content/ja/docs/setup/_index.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/setup/_index.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Translate /docs/setup/turnkey/aws.md in Japanese (#15640) * Translate content/ja/docs/setup/turnkey/aws.md partially * Update content/ja/docs/setup/turnkey/aws.md ... Kubernetes cluster on AWS: AWS上でKubernetesクラスターを... https://github.com/kubernetes/website/pull/15640/files#r310338415 Co-Authored-By: Kohei Ota <kohei.ota@zozo.com> * Update content/ja/docs/setup/turnkey/aws.md (Kubernetes Operations) - replace English commas with Japanese one (、) - Management: 管理 Co-Authored-By: Kohei Ota <kohei.ota@zozo.com> * Update content/ja/docs/setup/turnkey/aws.md (kube-aws) - replace English commas - insert a Japanese comma Co-Authored-By: Kohei Ota <kohei.ota@zozo.com> * Update content/ja/docs/setup/turnkey/aws.md (kubectl) - 断定でなく選択を与えるニュアンス Co-Authored-By: Kohei Ota <kohei.ota@zozo.com> * Translate content/ja/docs/setup/turnkey/aws.md completely Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * fix translation https://github.com/kubernetes/website/pull/15640#discussion_r310418805 自身がsupportするのでなく、Kubernetes Operationsがsupportしている、というニュアンス Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * fix mistranslation https://github.com/kubernetes/website/pull/15640#discussion_r310419122 ここでのwithはusingに近い意味合いで Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * fix translation https://github.com/kubernetes/website/pull/15640#discussion_r310568505 ここでのthroughは通過や媒介という意味合いよりも、手段を表すと捉える Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Update content/ja/docs/setup/turnkey/aws.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/setup/production-environment/turnkey/aws.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Translate docs/tutorials/stateless-application/expose-external-ip-address.md in Japanese (#15672) * Copy from content/ja/docs/tutorials/stateless-application/ Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * update link to Japanese document Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Translate expose-external-ip-address in Japanese Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md やや不自然だった Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md s/ロードバランサ/ロードバランサー/ Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md s/サーバ/サーバー/ Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Revert "update link to Japanese document" This reverts commit 9237f63402b0e642600d1ea24c6b410f877c165e. https://github.com/kubernetes/website/pull/15672#discussion_r311327200 * remove a new line 段落としては同じ * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md https://github.com/kubernetes/website/pull/15672#discussion_r312317653 * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Translate concepts/architecture/nodes.md into Japanese (#15625) * Translate concepts/architecture/nodes.md into Japanese * update translation * fix translation * eviction * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: makocchi <makocchi@gmail.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: makocchi <makocchi@gmail.com> * plural * review * node * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * healthy * review * namespace * Translate tasks/run-application/force-delete-stateful-set-pod/ in Japanese (#15835) * ja-trans: tasks/run-application/force-delete-stateful-set-pod/ * Update content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md * Update content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md * Translate concepts/architecture/master-node-communication.md into Japanese (#15638) * translate master node communication * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * deprecated * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: Takuya Tokuda <cs.toku.mail@gmail.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: Takuya Tokuda <cs.toku.mail@gmail.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: Takuya Tokuda <cs.toku.mail@gmail.com> * Translate /docs/tasks/tools/install-kubectl.md in Japanese (#15678) * Copy from content/en/docs/tasks/tools/install-kubectl.md Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * fix link to install-kubectl Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Translate Headings and Subheadings Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * translate text of install-kubectl in Japanese Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Update content/ja/docs/tasks/tools/install-kubectl.md s/ユーザ/ユーザー/ Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/tools/install-kubectl.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update install-kubectl.md s/する:/してください:/g * Translate /docs/tutorials/configuration/configure-redis-using-configmap.md in Japanese (#15639) * translate redis example * add index * Update content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * review * Translate docs/concepts/configuration/overview.md in Japanese (#15627) * Translate docs/concepts/configuration/overview.md in Japanese * Update content/ja/docs/concepts/configuration/overview.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/ja/docs/concepts/configuration/overview.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/configuration/overview.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/configuration/overview.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/configuration/overview.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Fix terminology in Japanese translation (#15889) * cluster * cluster * node * cluster * Update content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html Co-Authored-By: Takuya Tokuda <cs.toku.mail@gmail.com> * sitemap and search (#15927) * Translate tasks/debug-application-cluster/debug-pod-replication-contr… (#15883) * Translate tasks/debug-application-cluster/debug-pod-replication-controller/ in Japanese * Update content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * fix missing parenthesis (#16044) ``` Error: Error building site: "/src/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md:106:10": unrecognized character in shortcode action: U+003E '>'. Note: Parameters with non-alphanumeric args must be quoted ``` * Translate tasks/configure-pod-container/configure-volume-storage/ in Japanese (#16058) * Translate tasks/configure-pod-container/configure-volume-storage/ in Japanese * Update content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Translate text of docs/setup/release/version-skew-policy.md in Japanese (#15903) * translate content/ja/docs/setup/release/version-skew-policy.md in Japanese * translate "version skew" https://github.com/kubernetes/website/pull/15903#issuecomment-524518826 バージョン間の差異となるタイトルは原文どおりに用語として残し、初回の文でskew=差異であることを明示する以降はskewを翻訳する * fix translation - 格助詞漏れ - more than 1...は1を含まないそれ以上の値であり、実質「2以上」となるので、そのように訳したほうが自然 * delete unnecessary sentences * update translation cf. 422f5b0e6a0c52f844cfae66cde01f47fca4cf4e * update translation componentsが当該バージョンをサポートするのでなく、kube-apiserverのバージョンの結果ほかのcomponentsが当該バージョンをサポート**される**イメージ * Translate concepts/architecture/cloud-controller/ into Japanese (#16099) * Translate concepts/architecture/cloud-controller/ into Japanese * Revise sentences based on suggestion by reviewers * Revise a sentence based on suggestion by a reviewer * Fix wording to distinguish Kubernetes related resources from others * fix a typo (#16121) * fix some wording on home (#16127) * Translate contribute / _index.md to Japanese (#16050) * translate contribute index into Japanese * modify some terms * modify according to style guide * use same terminology about contribute * Update content/ja/docs/contribute/_index.md Co-Authored-By: Takuya Tokuda <cs.toku.mail@gmail.com> * Translate concepts/overview/components and related glossaries in Japanase (#16034) * Translate concepts/overview/components and related glossaries in Japanese * Revise sentences based on suggestion by reviewers * Translate tasks/configure-pod-container/assign-memory-resource/ in Japanese (#16055) * copy from content/en/docs/tasks/configure-pod-container/assign-memory-resource to ja directory * translate tasks/configure-pod-container/assign-memory-resource/ in Japanese * Update content/ja/docs/tasks/configure-pod-container/_index.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/configure-pod-container/_index.md Co-Authored-By: inductor <kohei.ota@zozo.com> * fix translation %s/メモリ/メモリー/g * Translate tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/ in Japanese (#16183) * Translate concepts/configuration/assign-pod-node/ in Japanese (#16221) * issue 15552 * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * modification after a review * Translate docs/tasks/administer-cluster/developing-cloud-controller-manager in ja (#16088) * Translate docs/tasks/administer-cluster/developing-cloud-controller-manager/ in Japanese * Update content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Remove reviewers section * Modified wording to unified * Remove unnecessary brackets * Translate concepts/overview/working-with-objects/object-management/ into Japanese (#16400) * Translate concepts/overview/working-with-objects/object-management/ into Japanese * Refine some words based on review comments * Add a word to refine a sentence based on a review comment * Translate content/ja/docs/concepts/cluster-administration/controller-… (#16351) * Translate content/ja/docs/concepts/cluster-administration/controller-metrics in ja * Improved to format a text * Fix inconsistent spellings * Update content/ja/docs/concepts/cluster-administration/controller-metrics.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/cluster-administration/controller-metrics.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Translate concepts/extend-kubernetes/extend-cluster/ and related glossaries into Japanese (#16636) * Translate concepts/extend-kubernetes/extend-cluster/ and related glossaries into Japanese * Apply suggestions from code review by inductor Co-Authored-By: inductor <kohei.ota@zozo.com> * Update a translation for extension point * Apply suggestions from code review by sftim Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Apply suggestions from code review by sftim * Fix the translation for document * Apply a suggestion from code review by nasa9084 * Apply suggestions from code review by inductor and nasa9084 * fix: s/kubernetes/Kubernetes/ (#16057) * Translate reference/command-line-tools-reference/feature-gates in Japanese (#16554) * Translate docs/reference/command-line-tools-reference/feature-gates in ja * Fix inconsistent spellings * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * ポッド -> Pod * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * ポッドreadinessゲート -> Pod readiness gate * ポッド -> pod * Pods -> Pod * Fix typo: Kunbernetes -> Kubernetes * 機能ゲート -> フィーチャーゲート * リポジトリ -> リポジトリー * キー=値 -> key=value * Translate concepts/storage/volume-pvc-datasource in Japanese (#16775) * Translate concepts/storage/volume-pvc-datasource in Japanese * Remove original English contents(forgot to remove) * Container Storage Interface -> コンテナストレージインターフェイス * フューチャーゲート -> フィーチャーゲート * Improved a translate to more natural expression * Update content/ja/docs/reference/glossary/csi.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/reference/glossary/storage-class.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/reference/glossary/storage-class.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/reference/glossary/storage-class.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/reference/glossary/storage-class.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/reference/glossary/storage-class.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Improved a translate to more natural expression * Remove an unnecessary line break * Improved some translate words to natural sentence * Improved translate * Fix translate * Translate docs/reference/glossary/selector.md in Japanese (#17375) * Translate docs/reference/glossary/selector.md in Japanese * Translate title into Japanese Co-Authored-By: bells17 <bells171@gmail.com> * Translate tasks/configure-pod-container/share-process-namespace/ into Japanese (#16220) * Translate tasks/configure-pod-container/share-process-namespace/ into Japanese * reflect review * Translate tasks/access-application-cluster/connecting-frontend-backend/ into Japanese (#16270) * Translate tasks/access-application-cluster/connecting-frontend-backend/ into Japanese * reflect review * translate tooltip text Co-Authored-By: bells17 <bells171@gmail.com> * Translate concepts/extend-kubernetes/operator/ into Japanese (#16455) * Translate concepts/extend-kubernetes/operator/ into Japanese * Update the word operator into Japanese * Apply suggestions by inductor and oke-py from code review Co-Authored-By: inductor <kohei.ota@zozo.com> Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions by inductor from code review Co-Authored-By: inductor <kohei.ota@zozo.com> * Refine sentences under bullet points * Refine sentences in response to the review by makocchi-git * Translate concepts/extend-kubernetes/api-extension/apiserver-aggregation/ into Japanese (#16662) * Translate concepts/extend-kubernetes/api-extension/apiserver-aggregation/ into Japanese * Apply suggestions from code review by inductor Co-Authored-By: inductor <kohei.ota@zozo.com> * Apply suggestions from review by MasayaAoyama * Apply a suggestion from review by MasayaAoyama * assign inductor as sig-docs-ja approver (#17412) (#17517) * traslate /docs/concepts/architecture/_index.md into Japanese (#15456) * tranaslated (#15458) * translate /ja/docs/reference/_index.md (#15624) * translate /ja/docs/reference/_index.md * Update content/ja/docs/reference/_index.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/_index.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/_index.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * patch reviews * Follow the dir structure of en in setup (#15590) * follow the dir structure of en in setup * delete unrelated files * wip removing ja * removeg ja * remove ja * Update content/ja/docs/setup/_index.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * review * numbered list * Update content/ja/docs/setup/_index.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/setup/_index.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Translate /docs/setup/turnkey/aws.md in Japanese (#15640) * Translate content/ja/docs/setup/turnkey/aws.md partially * Update content/ja/docs/setup/turnkey/aws.md ... Kubernetes cluster on AWS: AWS上でKubernetesクラスターを... https://github.com/kubernetes/website/pull/15640/files#r310338415 Co-Authored-By: Kohei Ota <kohei.ota@zozo.com> * Update content/ja/docs/setup/turnkey/aws.md (Kubernetes Operations) - replace English commas with Japanese one (、) - Management: 管理 Co-Authored-By: Kohei Ota <kohei.ota@zozo.com> * Update content/ja/docs/setup/turnkey/aws.md (kube-aws) - replace English commas - insert a Japanese comma Co-Authored-By: Kohei Ota <kohei.ota@zozo.com> * Update content/ja/docs/setup/turnkey/aws.md (kubectl) - 断定でなく選択を与えるニュアンス Co-Authored-By: Kohei Ota <kohei.ota@zozo.com> * Translate content/ja/docs/setup/turnkey/aws.md completely Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * fix translation https://github.com/kubernetes/website/pull/15640#discussion_r310418805 自身がsupportするのでなく、Kubernetes Operationsがsupportしている、というニュアンス Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * fix mistranslation https://github.com/kubernetes/website/pull/15640#discussion_r310419122 ここでのwithはusingに近い意味合いで Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * fix translation https://github.com/kubernetes/website/pull/15640#discussion_r310568505 ここでのthroughは通過や媒介という意味合いよりも、手段を表すと捉える Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Update content/ja/docs/setup/turnkey/aws.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/setup/production-environment/turnkey/aws.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Translate docs/tutorials/stateless-application/expose-external-ip-address.md in Japanese (#15672) * Copy from content/ja/docs/tutorials/stateless-application/ Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * update link to Japanese document Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Translate expose-external-ip-address in Japanese Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md やや不自然だった Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md s/ロードバランサ/ロードバランサー/ Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md s/サーバ/サーバー/ Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Revert "update link to Japanese document" This reverts commit 9237f63402b0e642600d1ea24c6b410f877c165e. https://github.com/kubernetes/website/pull/15672#discussion_r311327200 * remove a new line 段落としては同じ * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md https://github.com/kubernetes/website/pull/15672#discussion_r312317653 * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tutorials/stateless-application/expose-external-ip-address.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Translate concepts/architecture/nodes.md into Japanese (#15625) * Translate concepts/architecture/nodes.md into Japanese * update translation * fix translation * eviction * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: makocchi <makocchi@gmail.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: makocchi <makocchi@gmail.com> * plural * review * node * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/nodes.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * healthy * review * namespace * Translate tasks/run-application/force-delete-stateful-set-pod/ in Japanese (#15835) * ja-trans: tasks/run-application/force-delete-stateful-set-pod/ * Update content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md * Update content/ja/docs/tasks/run-application/force-delete-stateful-set-pod.md * Translate concepts/architecture/master-node-communication.md into Japanese (#15638) * translate master node communication * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * deprecated * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: Takuya Tokuda <cs.toku.mail@gmail.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: Takuya Tokuda <cs.toku.mail@gmail.com> * Update content/ja/docs/concepts/architecture/master-node-communication.md Co-Authored-By: Takuya Tokuda <cs.toku.mail@gmail.com> * Translate /docs/tasks/tools/install-kubectl.md in Japanese (#15678) * Copy from content/en/docs/tasks/tools/install-kubectl.md Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * fix link to install-kubectl Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Translate Headings and Subheadings Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * translate text of install-kubectl in Japanese Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Update content/ja/docs/tasks/tools/install-kubectl.md s/ユーザ/ユーザー/ Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/tools/install-kubectl.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update install-kubectl.md s/する:/してください:/g * Translate /docs/tutorials/configuration/configure-redis-using-configmap.md in Japanese (#15639) * translate redis example * add index * Update content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * review * Translate docs/concepts/configuration/overview.md in Japanese (#15627) * Translate docs/concepts/configuration/overview.md in Japanese * Update content/ja/docs/concepts/configuration/overview.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/ja/docs/concepts/configuration/overview.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/configuration/overview.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/configuration/overview.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/configuration/overview.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Fix terminology in Japanese translation (#15889) * cluster * cluster * node * cluster * Update content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html Co-Authored-By: Takuya Tokuda <cs.toku.mail@gmail.com> * sitemap and search (#15927) * Translate tasks/debug-application-cluster/debug-pod-replication-contr… (#15883) * Translate tasks/debug-application-cluster/debug-pod-replication-controller/ in Japanese * Update content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * fix missing parenthesis (#16044) ``` Error: Error building site: "/src/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md:106:10": unrecognized character in shortcode action: U+003E '>'. Note: Parameters with non-alphanumeric args must be quoted ``` * Translate tasks/configure-pod-container/configure-volume-storage/ in Japanese (#16058) * Translate tasks/configure-pod-container/configure-volume-storage/ in Japanese * Update content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/configure-pod-container/configure-volume-storage.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Translate text of docs/setup/release/version-skew-policy.md in Japanese (#15903) * translate content/ja/docs/setup/release/version-skew-policy.md in Japanese * translate "version skew" https://github.com/kubernetes/website/pull/15903#issuecomment-524518826 バージョン間の差異となるタイトルは原文どおりに用語として残し、初回の文でskew=差異であることを明示する以降はskewを翻訳する * fix translation - 格助詞漏れ - more than 1...は1を含まないそれ以上の値であり、実質「2以上」となるので、そのように訳したほうが自然 * delete unnecessary sentences * update translation cf. 422f5b0e6a0c52f844cfae66cde01f47fca4cf4e * update translation componentsが当該バージョンをサポートするのでなく、kube-apiserverのバージョンの結果ほかのcomponentsが当該バージョンをサポート**される**イメージ * Translate concepts/architecture/cloud-controller/ into Japanese (#16099) * Translate concepts/architecture/cloud-controller/ into Japanese * Revise sentences based on suggestion by reviewers * Revise a sentence based on suggestion by a reviewer * Fix wording to distinguish Kubernetes related resources from others * fix a typo (#16121) * fix some wording on home (#16127) * Translate contribute / _index.md to Japanese (#16050) * translate contribute index into Japanese * modify some terms * modify according to style guide * use same terminology about contribute * Update content/ja/docs/contribute/_index.md Co-Authored-By: Takuya Tokuda <cs.toku.mail@gmail.com> * Translate concepts/overview/components and related glossaries in Japanase (#16034) * Translate concepts/overview/components and related glossaries in Japanese * Revise sentences based on suggestion by reviewers * Translate tasks/configure-pod-container/assign-memory-resource/ in Japanese (#16055) * copy from content/en/docs/tasks/configure-pod-container/assign-memory-resource to ja directory * translate tasks/configure-pod-container/assign-memory-resource/ in Japanese * Update content/ja/docs/tasks/configure-pod-container/_index.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/configure-pod-container/_index.md Co-Authored-By: inductor <kohei.ota@zozo.com> * fix translation %s/メモリ/メモリー/g * Translate tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/ in Japanese (#16183) * Translate concepts/configuration/assign-pod-node/ in Japanese (#16221) * issue 15552 * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/configuration/assign-pod-node.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * modification after a review * Translate docs/tasks/administer-cluster/developing-cloud-controller-manager in ja (#16088) * Translate docs/tasks/administer-cluster/developing-cloud-controller-manager/ in Japanese * Update content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Remove reviewers section * Modified wording to unified * Remove unnecessary brackets * Translate concepts/overview/working-with-objects/object-management/ into Japanese (#16400) * Translate concepts/overview/working-with-objects/object-management/ into Japanese * Refine some words based on review comments * Add a word to refine a sentence based on a review comment * Translate content/ja/docs/concepts/cluster-administration/controller-… (#16351) * Translate content/ja/docs/concepts/cluster-administration/controller-metrics in ja * Improved to format a text * Fix inconsistent spellings * Update content/ja/docs/concepts/cluster-administration/controller-metrics.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/cluster-administration/controller-metrics.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Translate concepts/extend-kubernetes/extend-cluster/ and related glossaries into Japanese (#16636) * Translate concepts/extend-kubernetes/extend-cluster/ and related glossaries into Japanese * Apply suggestions from code review by inductor Co-Authored-By: inductor <kohei.ota@zozo.com> * Update a translation for extension point * Apply suggestions from code review by sftim Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Apply suggestions from code review by sftim * Fix the translation for document * Apply a suggestion from code review by nasa9084 * Apply suggestions from code review by inductor and nasa9084 * fix: s/kubernetes/Kubernetes/ (#16057) * Translate reference/command-line-tools-reference/feature-gates in Japanese (#16554) * Translate docs/reference/command-line-tools-reference/feature-gates in ja * Fix inconsistent spellings * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: nasa9084 <nasa9084@users.noreply.github.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * ポッド -> Pod * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * ポッドreadinessゲート -> Pod readiness gate * ポッド -> pod * Pods -> Pod * Fix typo: Kunbernetes -> Kubernetes * 機能ゲート -> フィーチャーゲート * リポジトリ -> リポジトリー * キー=値 -> key=value * Translate concepts/storage/volume-pvc-datasource in Japanese (#16775) * Translate concepts/storage/volume-pvc-datasource in Japanese * Remove original English contents(forgot to remove) * Container Storage Interface -> コンテナストレージインターフェイス * フューチャーゲート -> フィーチャーゲート * Improved a translate to more natural expression * Update content/ja/docs/reference/glossary/csi.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/reference/glossary/storage-class.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/reference/glossary/storage-class.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/reference/glossary/storage-class.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/reference/glossary/storage-class.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/reference/glossary/storage-class.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Improved a translate to more natural expression * Remove an unnecessary line break * Improved some translate words to natural sentence * Improved translate * Fix translate * Translate docs/reference/glossary/selector.md in Japanese (#17375) * Translate docs/reference/glossary/selector.md in Japanese * Translate title into Japanese Co-Authored-By: bells17 <bells171@gmail.com> * Translate tasks/configure-pod-container/share-process-namespace/ into Japanese (#16220) * Translate tasks/configure-pod-container/share-process-namespace/ into Japanese * reflect review * Translate tasks/access-application-cluster/connecting-frontend-backend/ into Japanese (#16270) * Translate tasks/access-application-cluster/connecting-frontend-backend/ into Japanese * reflect review * translate tooltip text Co-Authored-By: bells17 <bells171@gmail.com> * Translate concepts/extend-kubernetes/operator/ into Japanese (#16455) * Translate concepts/extend-kubernetes/operator/ into Japanese * Update the word operator into Japanese * Apply suggestions by inductor and oke-py from code review Co-Authored-By: inductor <kohei.ota@zozo.com> Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions by inductor from code review Co-Authored-By: inductor <kohei.ota@zozo.com> * Refine sentences under bullet points * Refine sentences in response to the review by makocchi-git * Translate concepts/extend-kubernetes/api-extension/apiserver-aggregation/ into Japanese (#16662) * Translate concepts/extend-kubernetes/api-extension/apiserver-aggregation/ into Japanese * Apply suggestions from code review by inductor Co-Authored-By: inductor <kohei.ota@zozo.com> * Apply suggestions from review by MasayaAoyama * Apply a suggestion from review by MasayaAoyama * ja-trans: content/ja/case-studies/sos (#17338) * Add case-studies for SOS International(JP) * Add logo file * fixup! Add case-studies for SOS International(JP) * Update content/ja/case-studies/sos/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/sos/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/sos/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/sos/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * ja-trans:Translate concepts/services-networking/service/ into Japanese (#14917) (#16319) * ja-trans:Translate concepts/services-networking/service/ into Japanese (#14917) * ja-trans: Improve Japanese translation in concepts/services-networking/service/ (#14917) * ja-trans: Improve Japanese translation in concepts/services-networking/service/ (#14917) * ja-trans: Improve Japanese translation in concepts/services-networking/_index.md (#14917) * ja-trans: Improve Japanese translation in reference/glossary/namespace.md (#14917) * ja-trans: Improve Japanese translation in concepts/services-networking/service/ (#14917) * ja-trans: Improve Japanese translation in concepts/services-networking/service/ (#14917) * ja-trans: content/ja/case-studies/nordstrom (#16953) * Add case-studies for Nordstrom(JP) * fixup! Add case-studies for Nordstrom(JP) * Update content/ja/case-studies/nordstrom/index.html line 25 eコマースサイト->ECサイト技術運用->技術的な運用探して->模索して Co-Authored-By: inductor <kohei.ota@zozo.com> * mod some sentences * fixup! mod some sentences * Update content/ja/case-studies/nordstrom/index.html Line98 ・クラスター ->クラスタ・表現を修正 Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/nordstrom/index.html 向上->改善 Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/case-studies/nordstrom/index.html クラスタ -> クラスター Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * fixup! Update content/ja/case-studies/nordstrom/index.html * Translate docs/reference/glossary/node.md into Japanese (#17680) * Translate docs/reference/glossary/control-plane.md into Japanese (#17679) * Translate docs/reference/glossary/control-plane.md into Japanese * Update content/ja/docs/reference/glossary/control-plane.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/reference/glossary/control-plane.md Co-Authored-By: inductor <kohei.ota@zozo.com> * ja-trans: Translate concepts/scheduling/kube-scheduler/ in Japanese #17118 (#17586) * ja-trans:Translate concepts/scheduling/kube-scheduler/ into Japanese (#17118) * ja-trans: Improve Japanese translation in concepts/scheduling/kube-scheduler/ (#17118) * ja-trans: Improve Japanese translation in concepts/scheduling/kube-scheduler/ (#17118)
2019-11-20 14:25:19 -08:00
parent 8c88039129
commit 4532bd2bdb
141 changed files with 8780 additions and 1891 deletions
@@ -0,0 +1,4 @@
+---
+title: Production environment
+weight: 30
+---
@@ -0,0 +1,256 @@
+---
+title: CRIのインストール
+content_template: templates/concept
+weight: 10
+---
+{{% capture overview %}}
+{{< feature-state for_k8s_version="v1.6" state="stable" >}}
+Podのコンテナを実行するために、Kubernetesはコンテナランタイムを使用します。
+様々なランタイムのインストール手順は次のとおりです。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+
+{{< 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.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" >}}
+# Docker CEのインストール
+## リポジトリをセットアップ
+### aptパッケージインデックスを更新
+    apt-get update
+
+### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール
+    apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common
+
+### Docker公式のGPG鍵を追加
+    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
+
+### dockerのaptリポジトリを追加
+    add-apt-repository \
+    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
+    $(lsb_release -cs) \
+    stable"
+
+## docker ceのインストール
+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"],
+  "log-driver": "json-file",
+  "log-opts": {
+    "max-size": "100m"
+  },
+  "storage-driver": "overlay2"
+}
+EOF
+
+mkdir -p /etc/systemd/system/docker.service.d
+
+# dockerを再起動
+systemctl daemon-reload
+systemctl restart docker
+{{< /tab >}}
+{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
+
+# Docker CEのインストール
+## リポジトリをセットアップ
+### 必要なパッケージのインストール
+    yum install yum-utils device-mapper-persistent-data lvm2
+
+### dockerパッケージ用のyumリポジトリを追加
+yum-config-manager \
+    --add-repo \
+    https://download.docker.com/linux/centos/docker-ce.repo
+
+## docker ceのインストール
+yum update && yum install docker-ce-18.06.2.ce
+
+## /etc/docker ディレクトリを作成
+mkdir /etc/docker
+
+# デーモンをセットアップ
+cat > /etc/docker/daemon.json <<EOF
+{
+  "exec-opts": ["native.cgroupdriver=systemd"],
+  "log-driver": "json-file",
+  "log-opts": {
+    "max-size": "100m"
+  },
+  "storage-driver": "overlay2",
+  "storage-opts": [
+    "overlay2.override_kernel_check=true"
+  ]
+}
+EOF
+
+mkdir -p /etc/systemd/system/docker.service.d
+
+# dockerを再起動
+systemctl daemon-reload
+systemctl restart docker
+{{< /tab >}}
+{{< /tabs >}}
+
+詳細については、[Dockerの公式インストールガイド](https://docs.docker.com/engine/installation/)を参照してください。
+
+## CRI-O
+
+このセクションでは、CRIランタイムとして`CRI-O`を利用するために必要な手順について説明します。
+
+システムへCRI-Oをインストールするためには以下のコマンドを利用します:
+
+### 必要な設定の追加
+
+```shell
+modprobe overlay
+modprobe br_netfilter
+
+# 必要なカーネルパラメータの設定をします。これらの設定値は再起動後も永続化されます。
+cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
+net.bridge.bridge-nf-call-iptables  = 1
+net.ipv4.ip_forward                 = 1
+net.bridge.bridge-nf-call-ip6tables = 1
+EOF
+
+sysctl --system
+```
+
+{{< tabs name="tab-cri-cri-o-installation" >}}
+{{< tab name="Ubuntu 16.04" codelang="bash" >}}
+
+# 必要なパッケージをインストールし、リポジトリを追加
+apt-get update
+apt-get install software-properties-common
+
+add-apt-repository ppa:projectatomic/ppa
+apt-get update
+
+# CRI-Oをインストール
+apt-get install cri-o-1.11
+
+{{< /tab >}}
+{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
+
+# 必要なリポジトリを追加
+yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-311-candidate/x86_64/os/
+
+# CRI-Oをインストール
+yum install --nogpgcheck cri-o
+
+{{< /tab >}}
+{{< /tabs >}}
+
+### CRI-Oの起動
+
+```
+systemctl start crio
+```
+
+詳細については、[CRI-Oインストールガイド](https://github.com/kubernetes-sigs/cri-o#getting-started)を参照してください。
+
+## Containerd
+
+このセクションでは、CRIランタイムとして`containerd`を利用するために必要な手順について説明します。
+
+システムへContainerdをインストールするためには次のコマンドを実行します。
+
+### 必要な設定の追加
+
+```shell
+modprobe overlay
+modprobe br_netfilter
+
+# 必要なカーネルパラメータの設定をします。これらの設定値は再起動後も永続化されます。
+cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
+net.bridge.bridge-nf-call-iptables  = 1
+net.ipv4.ip_forward                 = 1
+net.bridge.bridge-nf-call-ip6tables = 1
+EOF
+
+sysctl --system
+```
+
+{{< tabs name="tab-cri-containerd-installation" >}}
+{{< tab name="Ubuntu 16.04+" codelang="bash" >}}
+apt-get install -y libseccomp2
+{{< /tab >}}
+{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
+yum install -y libseccomp
+{{< /tab >}}
+{{< /tabs >}}
+
+### containerdのインストール
+
+[Containerdは定期的にリリース](https://github.com/containerd/containerd/releases)されますが、以下に示すコマンドで利用している値は、この手順が作成された時点での最新のバージョンにしたがって書かれています。より新しいバージョンとダウンロードするファイルのハッシュ値については[こちら](https://storage.googleapis.com/cri-containerd-release)で確認するようにしてください。
+
+```shell
+# 必要な環境変数をexportします。
+export CONTAINERD_VERSION="1.1.2"
+export CONTAINERD_SHA256="d4ed54891e90a5d1a45e3e96464e2e8a4770cd380c21285ef5c9895c40549218"
+
+# containerdのtarボールをダウンロードします。
+wget https://storage.googleapis.com/cri-containerd-release/cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz
+
+# ハッシュ値をチェックします。
+echo "${CONTAINERD_SHA256} cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz" | sha256sum --check -
+
+# 解凍して展開します。
+tar --no-overwrite-dir -C / -xzf cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz
+
+# containerdを起動します。
+systemctl start containerd
+```
+
+## その他のCRIランタイム: frakti
+
+詳細については[Fraktiのクイックスタートガイド](https://github.com/kubernetes/frakti#quickstart)を参照してください。
+
+{{% /capture %}}
@@ -0,0 +1,4 @@
+---
+title: オンプレミスVM
+weight: 60
+---
@@ -0,0 +1,118 @@
+---
+title: Cloudstack
+content_template: templates/concept
+---
+
+{{% capture overview %}}
+
+[CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes.
+
+[CoreOS](http://coreos.com) templates for CloudStack are built [nightly](http://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.
+
+This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## 前提条件
+
+```shell
+sudo apt-get install -y python-pip libssl-dev
+sudo pip install cs
+sudo pip install sshpubkeys
+sudo apt-get install software-properties-common
+sudo apt-add-repository ppa:ansible/ansible
+sudo apt-get update
+sudo apt-get install ansible
+```
+
+On CloudStack server you also have to install libselinux-python :
+
+```shell
+yum install libselinux-python
+```
+
+[_cs_](https://github.com/exoscale/cs) is a python module for the CloudStack API.
+
+Set your CloudStack endpoint, API keys and HTTP method used.
+
+You can define them as environment variables: `CLOUDSTACK_ENDPOINT`, `CLOUDSTACK_KEY`, `CLOUDSTACK_SECRET` and `CLOUDSTACK_METHOD`.
+
+Or create a `~/.cloudstack.ini` file:
+
+```none
+[cloudstack]
+endpoint = <your cloudstack api endpoint>
+key = <your api access key>
+secret = <your api secret key>
+method = post
+```
+
+We need to use the http POST method to pass the _large_ userdata to the coreOS instances.
+
+### playbookのクローン
+
+```shell
+git clone https://github.com/apachecloudstack/k8s
+cd kubernetes-cloudstack
+```
+
+### Kubernetesクラスターの作成
+
+You simply need to run the playbook.
+
+```shell
+ansible-playbook k8s.yml
+```
+
+Some variables can be edited in the `k8s.yml` file.
+
+```none
+vars:
+  ssh_key: k8s
+  k8s_num_nodes: 2
+  k8s_security_group_name: k8s
+  k8s_node_prefix: k8s2
+  k8s_template: <templatename>
+  k8s_instance_type: <serviceofferingname>
+```
+
+This will start a Kubernetes master node and a number of compute nodes (by default 2).
+The `instance_type` and `template` are specific, edit them to specify your CloudStack cloud specific template and instance type (i.e. service offering).
+
+Check the tasks and templates in `roles/k8s` if you want to modify anything.
+
+Once the playbook as finished, it will print out the IP of the Kubernetes master:
+
+```none
+TASK: [k8s | debug msg='k8s master IP is {{ k8s_master.default_ip }}'] ********
+```
+
+SSH to it using the key that was created and using the _core_ user.
+
+```shell
+ssh -i ~/.ssh/id_rsa_k8s core@<master IP>
+```
+
+And you can list the machines in your cluster:
+
+```shell
+fleetctl list-machines
+```
+
+```none
+MACHINE        IP             METADATA
+a017c422...    <node #1 IP>   role=node
+ad13bf84...    <master IP>    role=master
+e9af8293...    <node #2 IP>   role=node
+```
+
+## サポートレベル
+
+
+IaaS Provider        | Config. Mgmt | OS     | Networking  | Docs                                              | Conforms | Support Level
+-------------------- | ------------ | ------ | ----------  | ---------------------------------------------     | ---------| ----------------------------
+CloudStack           | Ansible      | CoreOS | flannel     | [docs](/docs/setup/production-environment/on-premises-vm/cloudstack/)                             |          | Community ([@Guiques](https://github.com/ltupin/))
+
+{{% /capture %}}
@@ -0,0 +1,25 @@
+---
+title: DC/OS上のKubernetes
+content_template: templates/concept
+---
+
+{{% capture overview %}}
+
+Mesosphereは[DC/OS](https://mesosphere.com/product/)上にKubernetesを構築する為の簡単な選択肢を提供します。それは
+
+* 純粋なアップストリームのKubernetes
+* シングルクリッククラスター構築
+* デフォルトで高可用であり安全
+* Kubernetesが高速なデータプラットフォーム(例えばAkka、Cassandra、Kafka、Spark)と共に稼働
+
+です。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## 公式Mesosphereガイド
+
+DC/OS入門の正規のソースは[クイックスタートリポジトリ](https://github.com/mesosphere/dcos-kubernetes-quickstart)にあります。
+
+{{% /capture %}}
@@ -0,0 +1,68 @@
+---
+title: oVirt
+content_template: templates/concept
+---
+
+{{% capture overview %}}
+
+oVirt is a virtual datacenter manager that delivers powerful management of multiple virtual machines on multiple hosts. Using KVM and libvirt, oVirt can be installed on Fedora, CentOS, or Red Hat Enterprise Linux hosts to set up and manage your virtual data center.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## oVirtクラウドプロバイダーによる構築
+
+The oVirt cloud provider allows to easily discover and automatically add new VM instances as nodes to your Kubernetes cluster.
+At the moment there are no community-supported or pre-loaded VM images including Kubernetes but it is possible to [import] or [install] Project Atomic (or Fedora) in a VM to [generate a template]. Any other distribution that includes Kubernetes may work as well.
+
+It is mandatory to [install the ovirt-guest-agent] in the guests for the VM ip address and hostname to be reported to ovirt-engine and ultimately to Kubernetes.
+
+Once the Kubernetes template is available it is possible to start instantiating VMs that can be discovered by the cloud provider.
+
+[import]: https://ovedou.blogspot.it/2014/03/importing-glance-images-as-ovirt.html
+[install]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#create-virtual-machines
+[generate a template]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#using-templates
+[install the ovirt-guest-agent]: https://www.ovirt.org/documentation/how-to/guest-agent/install-the-guest-agent-in-fedora/
+
+## oVirtクラウドプロバイダーの使用
+
+The oVirt Cloud Provider requires access to the oVirt REST-API to gather the proper information, the required credential should be specified in the `ovirt-cloud.conf` file:
+
+```none
+[connection]
+uri = https://localhost:8443/ovirt-engine/api
+username = admin@internal
+password = admin
+```
+
+In the same file it is possible to specify (using the `filters` section) what search query to use to identify the VMs to be reported to Kubernetes:
+
+```none
+[filters]
+# Search query used to find nodes
+vms = tag=kubernetes
+```
+
+In the above example all the VMs tagged with the `kubernetes` label will be reported as nodes to Kubernetes.
+
+The `ovirt-cloud.conf` file then must be specified in kube-controller-manager:
+
+```shell
+kube-controller-manager ... --cloud-provider=ovirt --cloud-config=/path/to/ovirt-cloud.conf ...
+```
+
+## oVirtクラウドプロバイダーのスクリーンキャスト
+
+This short screencast demonstrates how the oVirt Cloud Provider can be used to dynamically add VMs to your Kubernetes cluster.
+
+[![Screencast](https://img.youtube.com/vi/JyyST4ZKne8/0.jpg)](https://www.youtube.com/watch?v=JyyST4ZKne8)
+
+## サポートレベル
+
+
+IaaS Provider        | Config. Mgmt | OS     | Networking  | Docs                                              | Conforms | Support Level
+-------------------- | ------------ | ------ | ----------  | ---------------------------------------------     | ---------| ----------------------------
+oVirt                |              |        |             | [docs](/docs/setup/production-environment/on-premises-vm/ovirt/)                                  |          | Community ([@simon3z](https://github.com/simon3z))
+
+{{% /capture %}}
@@ -0,0 +1,4 @@
+---
+title: Installing Kubernetes with deployment tools
+weight: 30
+---
@@ -0,0 +1,175 @@
+---
+title: kopsを使ったAWS上でのKubernetesのインストール
+content_template: templates/concept
+weight: 20
+---
+
+{{% capture overview %}}
+
+This quickstart shows you how to easily install a Kubernetes cluster on AWS.
+It uses a tool called [`kops`](https://github.com/kubernetes/kops).
+
+kops is an opinionated provisioning system:
+
+* Fully automated installation
+* Uses DNS to identify clusters
+* Self-healing: everything runs in Auto-Scaling Groups
+* Multiple OS support (Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - see the [images.md](https://github.com/kubernetes/kops/blob/master/docs/images.md)
+* High-Availability support - see the [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/high_availability.md)
+* Can directly provision, or generate terraform manifests - see the [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md)
+
+If your opinions differ from these you may prefer to build your own cluster using [kubeadm](/docs/admin/kubeadm/) as
+a building block.  kops builds on the kubeadm work.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## クラスタの作成
+
+### (1/5) kopsのインストール
+
+#### 要件
+
+You must have [kubectl](/docs/tasks/tools/install-kubectl/) installed in order for kops to work.
+
+#### インストール
+
+Download kops from the [releases page](https://github.com/kubernetes/kops/releases) (it is also easy to build from source):
+
+On macOS:
+
+```shell
+curl -OL https://github.com/kubernetes/kops/releases/download/1.10.0/kops-darwin-amd64
+chmod +x kops-darwin-amd64
+mv kops-darwin-amd64 /usr/local/bin/kops
+# you can also install using Homebrew
+brew update && brew install kops
+```
+
+On Linux:
+
+```shell
+wget https://github.com/kubernetes/kops/releases/download/1.10.0/kops-linux-amd64
+chmod +x kops-linux-amd64
+mv kops-linux-amd64 /usr/local/bin/kops
+```
+
+### (2/5) クラスタ用のroute53ドメインの作成
+
+kops uses DNS for discovery, both inside the cluster and so that you can reach the kubernetes API server
+from clients.
+
+kops has a strong opinion on the cluster name: it should be a valid DNS name.  By doing so you will
+no longer get your clusters confused, you can share clusters with your colleagues unambiguously,
+and you can reach them without relying on remembering an IP address.
+
+You can, and probably should, use subdomains to divide your clusters.  As our example we will use
+`useast1.dev.example.com`.  The API server endpoint will then be `api.useast1.dev.example.com`.
+
+A Route53 hosted zone can serve subdomains.  Your hosted zone could be `useast1.dev.example.com`,
+but also `dev.example.com` or even `example.com`.  kops works with any of these, so typically
+you choose for organization reasons (e.g. you are allowed to create records under `dev.example.com`,
+but not under `example.com`).
+
+Let's assume you're using `dev.example.com` as your hosted zone.  You create that hosted zone using
+the [normal process](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
+with a command such as `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`.
+
+You must then set up your NS records in the parent domain, so that records in the domain will resolve.  Here,
+you would create NS records in `example.com` for `dev`.  If it is a root domain name you would configure the NS
+records at your domain registrar (e.g. `example.com` would need to be configured where you bought `example.com`).
+
+This step is easy to mess up (it is the #1 cause of problems!)  You can double-check that
+your cluster is configured correctly if you have the dig tool by running:
+
+`dig NS dev.example.com`
+
+You should see the 4 NS records that Route53 assigned your hosted zone.
+
+### (3/5) クラスタの状態を保存するS3バケットの作成
+
+kops lets you manage your clusters even after installation.  To do this, it must keep track of the clusters
+that you have created, along with their configuration, the keys they are using etc.  This information is stored
+in an S3 bucket.  S3 permissions are used to control access to the bucket.
+
+Multiple clusters can use the same S3 bucket, and you can share an S3 bucket between your colleagues that
+administer the same clusters - this is much easier than passing around kubecfg files.  But anyone with access
+to the S3 bucket will have administrative access to all your clusters, so you don't want to share it beyond
+the operations team.
+
+So typically you have one S3 bucket for each ops team (and often the name will correspond
+to the name of the hosted zone above!)
+
+In our example, we chose `dev.example.com` as our hosted zone, so let's pick `clusters.dev.example.com` as
+the S3 bucket name.
+
+* Export `AWS_PROFILE` (if you need to select a profile for the AWS CLI to work)
+
+* Create the S3 bucket using `aws s3 mb s3://clusters.dev.example.com`
+
+* You can `export KOPS_STATE_STORE=s3://clusters.dev.example.com` and then kops will use this location by default.
+   We suggest putting this in your bash profile or similar.
+
+
+### (4/5) クラスタ設定の構築
+
+Run "kops create cluster" to create your cluster configuration:
+
+`kops create cluster --zones=us-east-1c useast1.dev.example.com`
+
+kops will create the configuration for your cluster.  Note that it _only_ creates the configuration, it does
+not actually create the cloud resources - you'll do that in the next step with a `kops update cluster`.  This
+give you an opportunity to review the configuration or change it.
+
+It prints commands you can use to explore further:
+
+* List your clusters with: `kops get cluster`
+* Edit this cluster with: `kops edit cluster useast1.dev.example.com`
+* Edit your node instance group: `kops edit ig --name=useast1.dev.example.com nodes`
+* Edit your master instance group: `kops edit ig --name=useast1.dev.example.com master-us-east-1c`
+
+If this is your first time using kops, do spend a few minutes to try those out!  An instance group is a
+set of instances, which will be registered as kubernetes nodes.  On AWS this is implemented via auto-scaling-groups.
+You can have several instance groups, for example if you wanted nodes that are a mix of spot and on-demand instances, or
+GPU and non-GPU instances.
+
+
+### (5/5) AWSにクラスタを作成
+
+Run "kops update cluster" to create your cluster in AWS:
+
+`kops update cluster useast1.dev.example.com --yes`
+
+That takes a few seconds to run, but then your cluster will likely take a few minutes to actually be ready.
+`kops update cluster` will be the tool you'll use whenever you change the configuration of your cluster; it
+applies the changes you have made to the configuration to your cluster - reconfiguring AWS or kubernetes as needed.
+
+For example, after you `kops edit ig nodes`, then `kops update cluster --yes` to apply your configuration, and
+sometimes you will also have to `kops rolling-update cluster` to roll out the configuration immediately.
+
+Without `--yes`, `kops update cluster` will show you a preview of what it is going to do.  This is handy
+for production clusters!
+
+### 他のアドオンの参照
+
+See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization &amp; control of your Kubernetes cluster.
+
+## クリーンアップ
+
+* To delete your cluster: `kops delete cluster useast1.dev.example.com --yes`
+
+## フィードバック
+
+* Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/)
+* [GitHub Issues](https://github.com/kubernetes/kops/issues)
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
+* Learn about `kops` [advanced usage](https://github.com/kubernetes/kops)
+* See the `kops` [docs](https://github.com/kubernetes/kops) section for tutorials, best practices and advanced configuration options.
+
+{{% /capture %}}
@@ -0,0 +1,101 @@
+---
+title: KRIBを使用してDigital Rebar Provision (DRP)と共にKubernetesをインストールする
+krib-version: 2.4
+author: Rob Hirschfeld (zehicle)
+weight: 20
+---
+
+## 概要
+
+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](/ja/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_.
+{{< /note >}}
+
+
+KRIB features:
+
+* zero-touch, self-configuring cluster without pre-configuration or inventory
+* very fast, no-ssh required automation
+* bare metal, on-premises focused platform
+* highly available cluster options (including splitting etcd from the controllers)
+* dynamic generation of a TLS infrastructure
+* composable attributes and automatic detection of hardware by profile
+* options for persistent, immutable and image-based deployments
+* support for Ubuntu 18.04, CentOS/RHEL 7, CoreOS, RancherOS and others
+
+## クラスターの作成
+
+Review [Digital Rebar documentation](https://provision.readthedocs.io/en/tip/README.html) for details about installing the platform.
+
+The Digital Rebar Provision Golang binary should be installed on a Linux-like system with 16 GB of RAM or larger (Packet.net Tiny and Rasberry Pi are also acceptable).
+
+### (1/5) サーバーの発見
+
+Following the [Digital Rebar installation](https://provision.readthedocs.io/en/tip/doc/quickstart.html), allow one or more servers to boot through the _Sledgehammer_ discovery process to register with the API. This will automatically install the Digital Rebar runner and to allow for next steps.
+
+### (2/5) KRIBと証明書プラグインのインストール
+
+Upload the KRIB Content bundle (or build from [source](https://github.com/digitalrebar/provision-content/tree/master/krib)) and the Cert Plugin for your DRP platform. Both are freely available via the [RackN UX](https://portal.rackn.io) or using the upload from catalog feature of the DRPCLI (shown below).
+
+```
+drpcli plugin_providers upload certs from catalog:certs-stable
+drpcli contents upload catalog:krib-stable
+```
+
+### (3/5) クラスター構築の開始
+
+{{< note >}}
+KRIB documentation is dynamically generated from the source and will be more up to date than this guide.
+{{< /note >}}
+
+Following the [KRIB documentation](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html), create a Profile for your cluster and assign your target servers into the cluster Profile. The Profile must set `krib\cluster-name` and `etcd\cluster-name` Params to be the name of the Profile. Cluster configuration choices can be made by adding additional Params to the Profile; however, safe defaults are provided for all Params.
+
+Once all target servers are assigned to the cluster Profile, start a KRIB installation Workflow by assigning one of the included Workflows to all cluster servers. For example, selecting `krib-live-cluster` will perform an immutable deployment into the Sledgehammer discovery operating system. You may use one of the pre-created read-only Workflows or choose to build your own custom variation.
+
+For basic installs, no further action is required. Advanced users may choose to assign the controllers, etcd servers or other configuration values in the relevant Params.
+
+### (4/5) クラスター構築を監視
+
+Digital Rebar Provision provides detailed logging and live updates during the installation process. Workflow events are available via a websocket connection or monitoring the Jobs list.
+
+During the installation, KRIB writes cluster configuration data back into the cluster Profile.
+
+### (5/5) クラスターへのアクセス
+
+The cluster is available for access via *kubectl* once the `krib/cluster-admin-conf` Param has been set. This Param contains the `kubeconfig` information necessary to access the cluster.
+
+For example, if you named the cluster Profile `krib` then the following commands would allow you to connect to the installed cluster from your local terminal.
+
+  ::
+
+    drpcli profiles get krib params krib/cluster-admin-conf > admin.conf
+    export KUBECONFIG=admin.conf
+    kubectl get nodes
+
+
+The installation continues after the `krib/cluster-admin-conf` is set to install the Kubernetes UI and Helm. You may interact with the cluster as soon as the `admin.conf` file is available.
+
+## クラスター操作
+
+KRIB provides additional Workflows to manage your cluster. Please see the [KRIB documentation](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html) for an updated list of advanced cluster operations.
+
+### クラスターのスケール
+
+You can add servers into your cluster by adding the cluster Profile to the server and running the appropriate Workflow.
+
+### クラスターのクリーンアップ(開発者向け)
+
+You can reset your cluster and wipe out all configuration and TLS certificates using the `krib-reset-cluster` Workflow on any of the servers in the cluster.
+
+{{< caution >}}
+When running the reset Workflow, be sure not to accidentally target your production cluster!
+{{< /caution >}}
+
+## フィードバック
+
+* Slack Channel: [#community](https://rackn.slack.com/messages/community/)
+* [GitHub Issues](https://github.com/digitalrebar/provision/issues)
@@ -0,0 +1,4 @@
+---
+title: "Bootstrapping clusters with kubeadm"
+weight: 10
+---
@@ -0,0 +1,78 @@
+---
+title: kubeadmを使ったコントロールプレーンの設定のカスタマイズ
+content_template: templates/concept
+weight: 40
+---
+
+{{% capture overview %}}
+
+{{< feature-state for_k8s_version="1.12" state="stable" >}}
+
+kubeadmの`ClusterConfiguration`オブジェクトはAPIServer、ControllerManager、およびSchedulerのようなコントロールプレーンの構成要素に渡されたデフォルトのフラグを上書きすることができる `extraArgs`の項目があります。
+その構成要素は次の項目で定義されています。
+
+- `apiServer`
+- `controllerManager`
+- `scheduler`
+
+`extraArgs` の項目は `キー: 値` のペアです。コントロールプレーンの構成要素のフラグを上書きするには:
+
+1.  設定内容に適切な項目を追加
+2.  フラグを追加して項目を上書き
+
+各設定項目のより詳細な情報は[APIリファレンスのページ](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#ClusterConfiguration)を参照してください。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## APIServerフラグ
+
+詳細は[kube-apiserverのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-apiserver/)を参照してください。
+
+Example usage:
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: ClusterConfiguration
+kubernetesVersion: v1.13.0
+apiServer:
+  extraArgs:
+    advertise-address: 192.168.0.103
+    anonymous-auth: "false"
+    enable-admission-plugins: AlwaysPullImages,DefaultStorageClass
+    audit-log-path: /home/johndoe/audit.log
+```
+
+## ControllerManagerフラグ
+
+詳細は[kube-controller-managerのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-controller-manager/)を参照してください。
+
+Example usage:
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: ClusterConfiguration
+kubernetesVersion: v1.13.0
+controllerManager:
+  extraArgs:
+    cluster-signing-key-file: /home/johndoe/keys/ca.key
+    bind-address: 0.0.0.0
+    deployment-controller-sync-period: "50"
+```
+
+## Schedulerフラグ
+
+詳細は[kube-schedulerのリファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。
+
+Example usage:
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: ClusterConfiguration
+kubernetesVersion: v1.13.0
+scheduler:
+  extraArgs:
+    address: 0.0.0.0
+    config: /home/johndoe/schedconfig.yaml
+    kubeconfig: /home/johndoe/kubeconfig.yaml
+```
+
+{{% /capture %}}
@@ -0,0 +1,680 @@
+---
+title: kubeadmを使用したシングルマスタークラスターの作成
+content_template: templates/task
+weight: 30
+---
+
+{{% capture overview %}}
+
+<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">**kubeadm** helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices.  With kubeadm, your cluster should pass [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). Kubeadm also supports other cluster
+lifecycle functions, such as upgrades, downgrade, and managing [bootstrap tokens](/ja/docs/reference/access-authn-authz/bootstrap-tokens/).
+
+Because you can install kubeadm on various types of machine (e.g. laptop, server,
+Raspberry Pi, etc.), it's well suited for integration with provisioning systems
+such as Terraform or Ansible.
+
+kubeadm's simplicity means it can serve a wide range of use cases:
+
+- New users can start with kubeadm to try Kubernetes out for the first time.
+- Users familiar with Kubernetes can spin up clusters with kubeadm and test their applications.
+- Larger projects can include kubeadm as a building block in a more complex system that can also include other installer tools.
+
+kubeadm is designed to be a simple way for new users to start trying
+Kubernetes out, possibly for the first time, a way for existing users to
+test their application on and stitch together a cluster easily, and also to be
+a building block in other ecosystem and/or installer tool with a larger
+scope.
+
+You can install _kubeadm_ very easily on operating systems that support
+installing deb or rpm packages. The responsible SIG for kubeadm,
+[SIG Cluster Lifecycle](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle), provides these packages pre-built for you,
+but you may also build them from source for other OSes.
+
+
+### kubeadmの成熟度
+
+| Area                      | Maturity Level |
+|---------------------------|--------------- |
+| Command line UX           | GA             |
+| Implementation            | GA             |
+| Config file API           | Beta           |
+| CoreDNS                   | GA             |
+| kubeadm alpha subcommands | Alpha          |
+| High availability         | Beta           |
+| DynamicKubeletConfig      | Alpha          |
+
+
+kubeadm's overall feature state is **GA**. Some sub-features, like the configuration
+file API are still under active development. The implementation of creating the cluster
+may change slightly as the tool evolves, but the overall implementation should be pretty stable.
+Any commands under `kubeadm alpha` are by definition, supported on an alpha level.
+
+
+### サポート期間
+
+Kubernetes releases are generally supported for nine months, and during that
+period a patch release may be issued from the release branch if a severe bug or
+security issue is found. Here are the latest Kubernetes releases and the support
+timeframe; which also applies to `kubeadm`.
+
+| Kubernetes version | Release month  | End-of-life-month |
+|--------------------|----------------|-------------------|
+| v1.6.x             | March 2017     | December 2017     |
+| v1.7.x             | June 2017      | March 2018        |
+| v1.8.x             | September 2017 | June 2018         |
+| v1.9.x             | December 2017  | September 2018    |
+| v1.10.x            | March 2018     | December 2018     |
+| v1.11.x            | June 2018      | March 2019        |
+| v1.12.x            | September 2018 | June 2019         |
+| v1.13.x            | December 2018  | September 2019    |
+| v1.14.x            | March 2019     | December 2019     |
+| v1.15.x            | June 2019      | March 2020        |
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+- One or more machines running a deb/rpm-compatible OS, for example Ubuntu or CentOS
+- 2 GB or more of RAM per machine. Any less leaves little room for your
+   apps.
+- 2 CPUs or more on the control-plane node
+- Full network connectivity among all machines in the cluster. A public or
+   private network is fine.
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## 目的
+
+* Install a single master Kubernetes cluster or [high availability cluster](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)
+* Install a Pod network on the cluster so that your Pods can
+  talk to each other
+
+## 説明
+
+### kubeadmのインストール
+
+See ["Installing kubeadm"](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
+
+{{< note >}}
+If you have already installed kubeadm, run `apt-get update &&
+apt-get upgrade` or `yum update` to get the latest version of kubeadm.
+
+When you upgrade, the kubelet restarts every few seconds as it waits in a crashloop for
+kubeadm to tell it what to do. This crashloop is expected and normal.
+After you initialize your master, the kubelet runs normally.
+{{< /note >}}
+
+### マスターの初期化
+
+The control-plane node is the machine where the control plane components run, including
+etcd (the cluster database) and the API server (which the kubectl CLI
+communicates with).
+
+1. Choose a pod network add-on, and verify whether it requires any arguments to
+be passed to kubeadm initialization. Depending on which
+third-party provider you choose, you might need to set the `--pod-network-cidr` to
+a provider-specific value. See [Installing a pod network add-on](#pod-network).
+1. (Optional) Since version 1.14, kubeadm will try to detect the container runtime on Linux
+by using a list of well known domain socket paths. To use different container runtime or
+if there are more than one installed on the provisioned node, specify the `--cri-socket`
+argument to `kubeadm init`. See [Installing runtime](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
+1. (Optional) Unless otherwise specified, kubeadm uses the network interface associated
+with the default gateway to advertise the master's IP. To use a different
+network interface, specify the `--apiserver-advertise-address=<ip-address>` argument
+to `kubeadm init`. To deploy an IPv6 Kubernetes cluster using IPv6 addressing, you
+must specify an IPv6 address, for example `--apiserver-advertise-address=fd00::101`
+1. (Optional) Run `kubeadm config images pull` prior to `kubeadm init` to verify
+connectivity to gcr.io registries.
+
+Now run:
+
+```bash
+kubeadm init <args>
+```
+
+### 詳細
+
+For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/ja/docs/reference/setup-tools/kubeadm/kubeadm/).
+
+For a complete list of configuration options, see the [configuration file documentation](/ja/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).
+
+To customize control plane components, including optional IPv6 assignment to liveness probe for control plane components and etcd server, provide extra arguments to each component as documented in [custom arguments](/ja/docs/admin/kubeadm#custom-args).
+
+To run `kubeadm init` again, you must first [tear down the cluster](#tear-down).
+
+If you join a node with a different architecture to your cluster, create a separate
+Deployment or DaemonSet for `kube-proxy` and `kube-dns` on the node. This is because the Docker images for these
+components do not currently support multi-architecture.
+
+`kubeadm init` first runs a series of prechecks to ensure that the machine
+is ready to run Kubernetes. These prechecks expose warnings and exit on errors. `kubeadm init`
+then downloads and installs the cluster control plane components. This may take several minutes.
+The output should look like:
+
+```none
+[init] Using Kubernetes version: vX.Y.Z
+[preflight] Running pre-flight checks
+[preflight] Pulling images required for setting up a Kubernetes cluster
+[preflight] This might take a minute or two, depending on the speed of your internet connection
+[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
+[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
+[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
+[kubelet-start] Activating the kubelet service
+[certs] Using certificateDir folder "/etc/kubernetes/pki"
+[certs] Generating "etcd/ca" certificate and key
+[certs] Generating "etcd/server" certificate and key
+[certs] etcd/server serving cert is signed for DNS names [kubeadm-master localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
+[certs] Generating "etcd/healthcheck-client" certificate and key
+[certs] Generating "etcd/peer" certificate and key
+[certs] etcd/peer serving cert is signed for DNS names [kubeadm-master localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
+[certs] Generating "apiserver-etcd-client" certificate and key
+[certs] Generating "ca" certificate and key
+[certs] Generating "apiserver" certificate and key
+[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]
+[certs] Generating "apiserver-kubelet-client" certificate and key
+[certs] Generating "front-proxy-ca" certificate and key
+[certs] Generating "front-proxy-client" certificate and key
+[certs] Generating "sa" key and public key
+[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
+[kubeconfig] Writing "admin.conf" kubeconfig file
+[kubeconfig] Writing "kubelet.conf" kubeconfig file
+[kubeconfig] Writing "controller-manager.conf" kubeconfig file
+[kubeconfig] Writing "scheduler.conf" kubeconfig file
+[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 the following as a regular user:
+
+  mkdir -p $HOME/.kube
+  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
+  sudo chown $(id -u):$(id -g) $HOME/.kube/config
+
+You should now deploy a pod network to the cluster.
+Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
+  /docs/concepts/cluster-administration/addons/
+
+You can now join any number of machines by running the following on each node
+as root:
+
+  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
+also part of the `kubeadm init` output:
+
+```bash
+mkdir -p $HOME/.kube
+sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
+sudo chown $(id -u):$(id -g) $HOME/.kube/config
+```
+
+Alternatively, if you are the `root` user, you can run:
+
+```bash
+export KUBECONFIG=/etc/kubernetes/admin.conf
+```
+
+Make a record of the `kubeadm join` command that `kubeadm init` outputs. You
+need this command to [join nodes to your cluster](#join-nodes).
+
+The token is used for mutual authentication between the control-plane node and the joining
+nodes. The token included here is secret. Keep it safe, because anyone with this
+token can add authenticated nodes to your cluster. These tokens can be listed,
+created, and deleted with the `kubeadm token` command. See the
+[kubeadm reference guide](/ja/docs/reference/setup-tools/kubeadm/kubeadm-token/).
+
+### Podネットワークアドオンのインストール {#pod-network}
+
+{{< caution >}}
+This section contains important information about installation and deployment order. Read it carefully before proceeding.
+{{< /caution >}}
+
+You must install a pod network add-on so that your pods can communicate with
+each other.
+
+**The network must be deployed before any applications. Also, CoreDNS will not start up before a network is installed.
+kubeadm only supports Container Network Interface (CNI) based networks (and does not support kubenet).**
+
+Several projects provide Kubernetes pod networks using CNI, some of which also
+support [Network Policy](/ja/docs/concepts/services-networking/networkpolicies/). See the [add-ons page](/ja/docs/concepts/cluster-administration/addons/) for a complete list of available network add-ons.
+- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
+- [CNI bridge](https://github.com/containernetworking/plugins/blob/master/plugins/main/bridge/README.md) and [local-ipam](https://github.com/containernetworking/plugins/blob/master/plugins/ipam/host-local/README.md) are the only supported IPv6 network plugins in Kubernetes version 1.9.
+
+Note that kubeadm sets up a more secure cluster by default and enforces use of [RBAC](/ja/docs/reference/access-authn-authz/rbac/).
+Make sure that your network manifest supports RBAC.
+
+Also, beware, that your Pod network must not overlap with any of the host networks as this can cause issues.
+If you find a collision between your network plugin’s preferred Pod network and some of your host networks, you should think of a suitable CIDR replacement and use that during `kubeadm init` with `--pod-network-cidr` and as a replacement in your network plugin’s YAML.
+
+You can install a pod network add-on with the following command:
+
+```bash
+kubectl apply -f <add-on.yaml>
+```
+
+You can install only one pod network per cluster.
+
+{{< tabs name="tabs-pod-install" >}}
+{{% tab name="Choose one..." %}}
+Please select one of the tabs to see installation instructions for the respective third-party Pod Network Provider.
+{{% /tab %}}
+
+{{% tab name="AWS VPC" %}}
+AWS VPC CNI provides native AWS VPC networking to Kubernetes clusters.
+
+For installation, please refer to the [AWS VPC CNI setup guide](https://github.com/aws/amazon-vpc-cni-k8s#setup).
+{{% /tab %}}
+
+{{% 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`, `arm64`, and `ppc64le` only.
+
+```shell
+kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml
+```
+
+{{% /tab %}}
+{{% tab name="Canal" %}}
+Canal uses Calico for policy and Flannel for networking. Refer to the Calico documentation for the [official getting started guide](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/flannel).
+
+For Canal to work correctly, `--pod-network-cidr=10.244.0.0/16` has to be passed to `kubeadm init`. Note that Canal works on `amd64` only.
+
+```shell
+kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml
+```
+
+{{% /tab %}}
+
+{{% tab name="Cilium" %}}
+For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/).
+
+For Cilium to work correctly, you must pass `--pod-network-cidr=10.217.0.0/16` to `kubeadm init`.
+
+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
+kubectl taint nodes <node-name> node-role.kubernetes.io/master:NoSchedule-
+```
+
+To deploy Cilium you just need to run:
+
+```shell
+kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/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
+```
+The output is similar to this:
+```
+NAME           READY   STATUS    RESTARTS   AGE
+cilium-drxkl   1/1     Running   0          18m
+```
+
+{{% /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 %}}
+
+{{% tab name="Flannel" %}}
+
+For `flannel` to work correctly, you must pass `--pod-network-cidr=10.244.0.0/16` to `kubeadm init`.
+
+Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
+to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
+please see [here](/ja/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
+
+Make sure that your firewall rules allow UDP ports 8285 and 8472 traffic for all hosts participating in the overlay network.
+see [here
+](https://coreos.com/flannel/docs/latest/troubleshooting.html#firewalls).
+
+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/62e44c867a2846fefb68bd5f178daf4da3095ccb/Documentation/kube-flannel.yml
+```
+
+For more information about `flannel`, see [the CoreOS flannel repository on GitHub
+](https://github.com/coreos/flannel).
+{{% /tab %}}
+
+{{% tab name="JuniperContrail/TungstenFabric" %}}
+Provides overlay SDN solution, delivering multicloud networking, hybrid cloud networking,
+simultaneous overlay-underlay support, network policy enforcement, network isolation,
+service chaining and flexible load balancing.
+
+There are multiple, flexible ways to install JuniperContrail/TungstenFabric CNI.
+
+Kindly refer to this quickstart: [TungstenFabric](https://tungstenfabric.github.io/website/)
+{{% /tab %}}
+
+{{% tab name="Kube-router" %}}
+Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
+to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
+please see [here](/ja/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
+
+Kube-router relies on kube-controller-manager to allocate pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag.
+
+Kube-router provides pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy.
+
+For information on setting up Kubernetes cluster with Kube-router using kubeadm, please see official [setup guide](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md).
+{{% /tab %}}
+
+{{% tab name="Romana" %}}
+Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
+to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
+please see [here](/ja/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
+
+The official Romana set-up guide is [here](https://github.com/romana/romana/tree/master/containerize#using-kubeadm).
+
+Romana works on `amd64` only.
+
+```shell
+kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containerize/specs/romana-kubeadm.yml
+```
+{{% /tab %}}
+
+{{% tab name="Weave Net" %}}
+Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
+to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
+please see [here](/ja/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
+
+The official Weave Net set-up guide is [here](https://www.weave.works/docs/net/latest/kube-addon/).
+
+Weave Net works on `amd64`, `arm`, `arm64` and `ppc64le` without any extra action required.
+Weave Net sets hairpin mode by default. This allows Pods to access themselves via their Service IP address
+if they don't know their PodIP.
+
+```shell
+kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
+```
+{{% /tab %}}
+
+{{< /tabs >}}
+
+
+Once a pod network has been installed, you can confirm that it is working by
+checking that the CoreDNS pod is Running in the output of `kubectl get pods --all-namespaces`.
+And once the CoreDNS pod is up and running, you can continue by joining your nodes.
+
+If your network is not working or CoreDNS is not in the Running state, checkout our [troubleshooting docs](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
+
+### コントロールプレーンノードの隔離
+
+By default, your cluster will not schedule pods on the control-plane node for security
+reasons. If you want to be able to schedule pods on the control-plane node, e.g. for a
+single-machine Kubernetes cluster for development, run:
+
+```bash
+kubectl taint nodes --all node-role.kubernetes.io/master-
+```
+
+With output looking something like:
+
+```
+node "test-01" untainted
+taint "node-role.kubernetes.io/master:" not found
+taint "node-role.kubernetes.io/master:" not found
+```
+
+This will remove the `node-role.kubernetes.io/master` taint from any nodes that
+have it, including the control-plane node, meaning that the scheduler will then be able
+to schedule pods everywhere.
+
+### ノードの追加 {#join-nodes}
+
+The nodes are where your workloads (containers and pods, etc) run. To add new nodes to your cluster do the following for each machine:
+
+* SSH to the machine
+* Become root (e.g. `sudo su -`)
+* Run the command that was output by `kubeadm init`. For example:
+
+``` bash
+kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>
+```
+
+If you do not have the token, you can get it by running the following command on the master node:
+
+``` bash
+kubeadm token list
+```
+
+The output is similar to this:
+
+``` console
+TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION            EXTRA GROUPS
+8ewj1p.9r9hcjoqgajrj4gi  23h  2018-06-12T02:51:28Z authentication,  The default bootstrap  system:
+                                                   signing          token generated by     bootstrappers:
+                                                                    'kubeadm init'.        kubeadm:
+                                                                                           default-node-token
+```
+
+By default, tokens expire after 24 hours. If you are joining a node to the cluster after the current token has expired,
+you can create a new token by running the following command on the master node:
+
+``` bash
+kubeadm token create
+```
+
+The output is similar to this:
+
+``` console
+5didvk.d09sbcov8ph2amjw
+```
+
+If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the following command chain on the master node:
+
+``` bash
+openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
+   openssl dgst -sha256 -hex | sed 's/^.* //'
+```
+
+The output is similar to this:
+
+``` console
+8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78
+```
+
+{{< note >}}
+To specify an IPv6 tuple for `<master-ip>:<master-port>`, IPv6 address must be enclosed in square brackets, for example: `[fd00::101]:2073`.
+{{< /note >}}
+
+The output should look something like:
+
+```
+[preflight] Running pre-flight checks
+
+... (log output of join workflow) ...
+
+Node join complete:
+* Certificate signing request sent to master and response
+  received.
+* Kubelet informed of new secure connection details.
+
+Run 'kubectl get nodes' on the master to see this machine join.
+```
+
+A few seconds later, you should notice this node in the output from `kubectl get
+nodes` when run on the master.
+
+### (任意) マスター以外のマシンからのクラスター操作
+
+In order to get a kubectl on some other computer (e.g. laptop) to talk to your
+cluster, you need to copy the administrator kubeconfig file from your master
+to your workstation like this:
+
+``` bash
+scp root@<master ip>:/etc/kubernetes/admin.conf .
+kubectl --kubeconfig ./admin.conf get nodes
+```
+
+{{< note >}}
+The example above assumes SSH access is enabled for root. If that is not the
+case, you can copy the `admin.conf` file to be accessible by some other user
+and `scp` using that other user instead.
+
+The `admin.conf` file gives the user _superuser_ privileges over the cluster.
+This file should be used sparingly. For normal users, it's recommended to
+generate an unique credential to which you whitelist privileges. You can do
+this with the `kubeadm alpha kubeconfig user --client-name <CN>`
+command. That command will print out a KubeConfig file to STDOUT which you
+should save to a file and distribute to your user. After that, whitelist
+privileges by using `kubectl create (cluster)rolebinding`.
+{{< /note >}}
+
+### (任意) APIサーバーをlocalhostへプロキシ
+
+If you want to connect to the API Server from outside the cluster you can use
+`kubectl proxy`:
+
+```bash
+scp root@<master ip>:/etc/kubernetes/admin.conf .
+kubectl --kubeconfig ./admin.conf proxy
+```
+
+You can now access the API Server locally at `http://localhost:8001/api/v1`
+
+## クラスターの削除 {#tear-down}
+
+To undo what kubeadm did, you should first [drain the
+node](/ja/docs/reference/generated/kubectl/kubectl-commands#drain) and make
+sure that the node is empty before shutting it down.
+
+Talking to the master with the appropriate credentials, run:
+
+```bash
+kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
+kubectl delete node <node name>
+```
+
+Then, on the node being removed, reset all kubeadm installed state:
+
+```bash
+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.
+
+More options and information about the
+[`kubeadm reset command`](/ja/docs/reference/setup-tools/kubeadm/kubeadm-reset/).
+
+## クラスターの維持 {#lifecycle}
+
+Instructions for maintaining kubeadm clusters (e.g. upgrades,downgrades, etc.) can be found [here.](/ja/docs/tasks/administer-cluster/kubeadm)
+
+## 他アドオンの参照 {#other-addons}
+
+See the [list of add-ons](/ja/docs/concepts/cluster-administration/addons/) to explore other add-ons,
+including tools for logging, monitoring, network policy, visualization &amp;
+control of your Kubernetes cluster.
+
+## 次の手順 {#whats-next}
+
+* Verify that your cluster is running properly with [Sonobuoy](https://github.com/heptio/sonobuoy)
+* Learn about kubeadm's advanced usage in the [kubeadm reference documentation](/ja/docs/reference/setup-tools/kubeadm/kubeadm)
+* Learn more about Kubernetes [concepts](/ja/docs/concepts/) and [`kubectl`](/ja/docs/user-guide/kubectl-overview/).
+* Configure log rotation. You can use **logrotate** for that. When using Docker, you can specify log rotation options for Docker daemon, for example `--log-driver=json-file --log-opt=max-size=10m --log-opt=max-file=5`. See [Configure and troubleshoot the Docker daemon](https://docs.docker.com/engine/admin/) for more details.
+
+## フィードバック {#feedback}
+
+* For bugs, visit [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)
+* For support, visit kubeadm Slack Channel:
+  [#kubeadm](https://kubernetes.slack.com/messages/kubeadm/)
+* General SIG Cluster Lifecycle Development Slack Channel:
+  [#sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/)
+* SIG Cluster Lifecycle [SIG information](#TODO)
+* SIG Cluster Lifecycle Mailing List:
+  [kubernetes-sig-cluster-lifecycle](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle)
+
+## バージョン互換ポリシー {#version-skew-policy}
+
+The kubeadm CLI tool of version vX.Y may deploy clusters with a control plane of version vX.Y or vX.(Y-1).
+kubeadm CLI vX.Y can also upgrade an existing kubeadm-created cluster of version vX.(Y-1).
+
+Due to that we can't see into the future, kubeadm CLI vX.Y may or may not be able to deploy vX.(Y+1) clusters.
+
+Example: kubeadm v1.8 can deploy both v1.7 and v1.8 clusters and upgrade v1.7 kubeadm-created clusters to
+v1.8.
+
+These resources provide more information on supported version skew between kubelets and the control plane, and other Kubernetes components:
+
+* Kubernetes [version and version-skew policy](/ja/docs/setup/release/version-skew-policy/)
+* Kubeadm-specific [installation guide](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
+
+## kubeadmは様々なプラットフォームで動く
+
+kubeadm deb/rpm packages and binaries are built for amd64, arm (32-bit), arm64, ppc64le, and s390x
+following the [multi-platform
+proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multi-platform.md).
+
+Multiplatform container images for the control plane and addons are also supported since v1.12.
+
+Only some of the network providers offer solutions for all platforms. Please consult the list of
+network providers above or the documentation from each provider to figure out whether the provider
+supports your chosen platform.
+
+## 制限事項 {#limitations}
+
+The cluster created here has a single control-plane node, with a single etcd database
+running on it. This means that if the control-plane node fails, your cluster may lose
+data and may need to be recreated from scratch.
+
+Workarounds:
+
+* Regularly [back up etcd](https://coreos.com/etcd/docs/latest/admin_guide.html). The
+  etcd data directory configured by kubeadm is at `/var/lib/etcd` on the control-plane node.
+
+* Use multiple control-plane nodes by completing the
+  [HA setup](/ja/docs/setup/independent/ha-topology) instead.
+
+## トラブルシューティング {#troubleshooting}
+
+If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
@@ -0,0 +1,69 @@
+---
+title: Options for Highly Available topology
+content_template: templates/concept
+weight: 50
+---
+
+{{% capture overview %}}
+
+This page explains the two options for configuring the topology of your highly available (HA) Kubernetes clusters.
+
+You can set up an HA cluster:
+
+- With stacked control plane nodes, where etcd nodes are colocated with control plane nodes
+- With external etcd nodes, where etcd runs on separate nodes from the control plane
+
+You should carefully consider the advantages and disadvantages of each topology before setting up an HA cluster.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Stacked etcd topology
+
+A stacked HA cluster is a [topology](https://en.wikipedia.org/wiki/Network_topology) where the distributed
+data storage cluster provided by etcd is stacked on top of the cluster formed by the nodes managed by
+kubeadm that run control plane components.
+
+Each control plane node runs an instance of the `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager`.
+The `kube-apiserver` is exposed to worker nodes using a load balancer.
+
+Each control plane node creates a local etcd member and this etcd member communicates only with
+the `kube-apiserver` of this node. The same applies to the local `kube-controller-manager`
+and `kube-scheduler` instances.
+
+This topology couples the control planes and etcd members on the same nodes. It is simpler to set up than a cluster
+with external etcd nodes, and simpler to manage for replication.
+
+However, a stacked cluster runs the risk of failed coupling. If one node goes down, both an etcd member and a control
+plane instance are lost, and redundancy is compromised. You can mitigate this risk by adding more control plane nodes.
+
+You should therefore run a minimum of three stacked control plane nodes for an HA cluster.
+
+This is the default topology in kubeadm. A local etcd member is created automatically
+on control plane nodes when using `kubeadm init` and `kubeadm join --control-plane`.
+
+![Stacked etcd topology](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg)
+
+## External etcd topology
+
+An HA cluster with external etcd is a [topology](https://en.wikipedia.org/wiki/Network_topology) where the distributed data storage cluster provided by etcd is external to the cluster formed by the nodes that run control plane components.
+
+Like the stacked etcd topology, each control plane node in an external etcd topology runs an instance of the `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager`. And the `kube-apiserver` is exposed to worker nodes using a load balancer. However, etcd members run on separate hosts, and each etcd host communicates with the `kube-apiserver` of each control plane node.
+
+This topology decouples the control plane and etcd member. It therefore provides an HA setup where
+losing a control plane instance or an etcd member has less impact and does not affect
+the cluster redundancy as much as the stacked HA topology.
+
+However, this topology requires twice the number of hosts as the stacked HA topology.
+A minimum of three hosts for control plane nodes and three hosts for etcd nodes are required for an HA cluster with this topology.
+
+![External etcd topology](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg)
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+- [Set up a highly available cluster with kubeadm](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)
+
+{{% /capture %}}
@@ -0,0 +1,302 @@
+---
+title: kubeadmを使用した高可用性クラスターの作成
+content_template: templates/task
+weight: 60
+---
+
+{{% capture overview %}}
+
+このページでは、kubeadmを使用して、高可用性クラスターを作成する、2つの異なるアプローチを説明します:
+
+- 積み重なったコントロールプレーンノードを使う方法。こちらのアプローチは、必要なインフラストラクチャーが少ないです。etcdのメンバーと、コントロールプレーンノードは同じ場所に置かれます。
+- 外部のetcdクラスターを使う方法。こちらのアプローチには、より多くのインフラストラクチャーが必要です。コントロールプレーンノードと、etcdのメンバーは分離されます。
+
+先へ進む前に、どちらのアプローチがアプリケーションの要件と、環境に適合するか、慎重に検討してください。[こちらの比較](/ja/docs/setup/independent/ha-topology/)が、それぞれの利点/欠点について概説しています。
+
+クラスターではKubernetesのバージョン1.12以降を使用する必要があります。また、kubeadmを使用した高可用性クラスターはまだ実験的な段階であり、将来のバージョンではもっとシンプルになることに注意してください。たとえば、クラスターのアップグレードに際し問題に遭遇するかもしれません。両方のアプローチを試し、kueadmの[issue tracker](https://github.com/kubernetes/kubeadm/issues/new)で我々にフィードバックを提供してくれることを推奨します。
+
+alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.13で削除されたことに留意してください。
+
+[高可用性クラスターのアップグレード](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-13)も参照してください。
+
+{{< caution >}}
+このページはクラウド上でクラスターを構築することには対応していません。ここで説明されているどちらのアプローチも、クラウド上で、LoadBalancerタイプのServiceオブジェクトや、動的なPersistentVolumeを利用して動かすことはできません。
+{{< /caution >}}
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+どちらの方法でも、以下のインフラストラクチャーが必要です:
+
+- master用に、[kubeadmの最小要件](/ja/docs/setup/independent/install-kubeadm/#before-you-begin)を満たす3台のマシン
+- worker用に、[kubeadmの最小要件](/ja/docs/setup/independent/install-kubeadm/#before-you-begin)を満たす3台のマシン
+- クラスター内のすべてのマシン間がフルにネットワーク接続可能であること(パブリック、もしくはプライベートネットワーク)
+- すべてのマシンにおいて、sudo権限
+- あるデバイスから、システム内のすべてのノードに対しSSH接続できること
+- `kubeadm`と`kubelet`がすべてのマシンにインストールされていること。 `kubectl`は任意です。
+
+外部etcdクラスターには、以下も必要です:
+
+- etcdメンバー用に、追加で3台のマシン
+
+{{< note >}}
+以下の例では、CalicoをPodネットワーキングプロバイダーとして使用します。別のネットワーキングプロバイダーを使用する場合、必要に応じてデフォルトの値を変更してください。
+{{< /note >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## 両手順における最初のステップ
+
+{{< note >}}
+コントロールプレーンや、etcdノードでのコマンドはすべてrootとして実行してください。
+{{< /note >}}
+
+- 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`フィールドを設定してください。
+
+### kube-apiserver用にロードバランサーを作成
+
+{{< note >}}
+ロードバランサーには多くの設定項目があります。以下の例は、一選択肢に過ぎません。あなたのクラスター要件には、異なった設定が必要かもしれません。
+{{< /note >}}
+
+1.  DNSで解決される名前で、kube-apiserver用ロードバランサーを作成する。
+    - クラウド環境では、コントロールプレーンノードをTCPフォワーディングロードバランサーの後ろに置かなければなりません。このロードバランサーはターゲットリストに含まれる、すべての健全なコントロールプレーンノードにトラフィックを分配します。apiserverへのヘルスチェックはkube-apiserverがリッスンするポート(デフォルト値: `:6443`)に対する、TCPチェックです。
+
+    - クラウド環境では、IPアドレスを直接使うことは推奨されません。
+
+    - ロードバランサーは、apiserverポートで、全てのコントロールプレーンノードと通信できなければなりません。また、リスニングポートに対する流入トラフィックも許可されていなければなりません。
+
+    - [HAProxy](http://www.haproxy.org/)をロードバランサーとして使用することができます。
+
+    - ロードバランサーのアドレスは、常にkubeadmの`ControlPlaneEndpoint`のアドレスと一致することを確認してください。
+
+1.  ロードバランサーに、最初のコントロールプレーンノードを追加し、接続をテストする:
+
+    ```sh
+    nc -v LOAD_BALANCER_IP PORT
+    ```
+
+    - apiserverはまだ動いていないので、接続の拒否は想定通りです。しかし、タイムアウトしたのであれば、ロードバランサーはコントロールプレーンノードと通信できなかったことを意味します。もし、タイムアウトが起きたら、コントロールプレーンノードと通信できるように、ロードバランサーを再設定してください。
+
+1.  残りのコントロールプレーンノードを、ロードバランサーのターゲットグループに追加します。
+
+### SSHの設定
+
+1台のマシンから全てのノードをコントロールしたいのであれば、SSHが必要です。
+
+1.  システム内の全ての他のノードにアクセスできるメインデバイスで、ssh-agentを有効にします
+
+    ```
+    eval $(ssh-agent)
+    ```
+
+1.  SSHの秘密鍵を、セッションに追加します:
+
+    ```
+    ssh-add ~/.ssh/path_to_private_key
+    ```
+
+1.  正常に接続できることを確認するために、ノード間でSSHします。
+
+    - ノードにSSHする際は、必ず`-A`フラグをつけます:
+
+        ```
+        ssh -A 10.0.0.7
+        ```
+
+    - ノードでsudoするときは、SSHフォワーディングが動くように、環境変数を引き継ぎます:
+
+        ```
+        sudo -E -s
+        ```
+
+## 積み重なったコントロールプレーンとetcdノード
+
+### 最初のコントロールプレーンノードの手順
+
+1.  最初のコントロールプレーンノードで、`kubeadm-config.yaml`という設定ファイルを作成します:
+
+        apiVersion: kubeadm.k8s.io/v1beta1
+        kind: ClusterConfiguration
+        kubernetesVersion: stable
+        apiServer:
+          certSANs:
+          - "LOAD_BALANCER_DNS"
+        controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
+
+    - `kubernetesVersion`には使用するKubernetesのバージョンを設定します。この例では`stable`を使用しています。
+    - `controlPlaneEndpoint` はロードバランサーのアドレスかDNSと、ポートに一致する必要があります。
+    - kubeadm、kubelet、kubectlとKubernetesのバージョンを一致させることが推奨されます。
+
+1.  ノードがきれいな状態であることを確認します:
+
+    ```sh
+    sudo kubeadm init --config=kubeadm-config.yaml
+    ```
+
+    このような出力がされます:
+
+    ```sh
+    ...
+    You can now join any number of machines by running the following on each node
+    as root:
+
+    kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash    sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f
+    ```
+
+1.  この出力をテキストファイルにコピーします。あとで、他のコントロールプレーンノードをクラスターに参加させる際に必要になります。
+
+1.  Weave CNIプラグインをapplyします:
+
+    ```sh
+    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
+    ```
+
+1.  以下のコマンドを入力し、コンポーネントのPodが起動するのを確認します:
+
+    ```sh
+    kubectl get pod -n kube-system -w
+    ```
+
+    - 最初のコントロールプレーンノードが初期化を完了してから、新しいノードを参加させることが推奨されます。
+
+1.  証明書ファイルを最初のコントロールプレーンノードから残りのノードにコピーします:
+
+    以下の例では、`CONTROL_PLANE_IPS`を他のコントロールプレーンノードのIPアドレスで置き換えます。
+    ```sh
+    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:
+        scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
+        scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
+        scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
+        scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
+        scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
+        scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
+        scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
+        scp /etc/kubernetes/admin.conf "${USER}"@$host:
+    done
+    ```
+
+{{< caution >}}
+上のリストにある証明書だけをコピーしてください。kubeadmが、参加するコントロールプレーンノード用に、残りの証明書と必要なSANの生成を行います。間違って全ての証明書をコピーしてしまったら、必要なSANがないため、追加ノードの作成は失敗するかもしれません。
+{{< /caution >}}
+
+### 残りのコントロールプレーンノードの手順
+
+1.  `scp`を使用する手順で作成したファイルを移動します:
+
+    ```sh
+    USER=ubuntu # 変更可能
+    mkdir -p /etc/kubernetes/pki/etcd
+    mv /home/${USER}/ca.crt /etc/kubernetes/pki/
+    mv /home/${USER}/ca.key /etc/kubernetes/pki/
+    mv /home/${USER}/sa.pub /etc/kubernetes/pki/
+    mv /home/${USER}/sa.key /etc/kubernetes/pki/
+    mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
+    mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
+    mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
+    mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
+    mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf
+    ```
+
+    この手順で、`/etc/kubernetes`フォルダーに必要な全てのファイルが書き込まれます。
+
+1.  `kubeadm init`を最初のノードで実行した際に取得したjoinコマンドを使って、このノードで`kubeadm join`を開始します。このようなコマンドになるはずです:
+
+    ```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`フラグが追加されています。このフラグは、コントロールプレーンノードのクラスターへの参加を自動化します。
+
+1.  以下のコマンドをタイプし、コンポーネントのPodが起動するのを確認します:
+
+    ```sh
+    kubectl get pod -n kube-system -w
+    ```
+
+1.  これらのステップを、残りのコントロールプレーンノードに対して繰り返します。
+
+## 外部のetcdノード
+
+### etcdクラスターの構築
+
+- [こちらの手順](/ja/docs/setup/independent/setup-ha-etcd-with-kubeadm/)にしたがって、etcdクラスターを構築してください。
+
+### 最初のコントロールプレーンノードの構築
+
+1.  以下のファイルをetcdクラスターのどれかのノードからこのノードへコピーしてください:
+
+    ```sh
+    export CONTROL_PLANE="ubuntu@10.0.0.7"
+    +scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
+    +scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
+    +scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
+    ```
+
+    - `CONTROL_PLANE`の値を、このマシンの`user@host`で置き換えます。
+
+1.  以下の内容で、`kubeadm-config.yaml`という名前の設定ファイルを作成します:
+
+        apiVersion: kubeadm.k8s.io/v1beta1
+        kind: ClusterConfiguration
+        kubernetesVersion: stable
+        apiServer:
+          certSANs:
+          - "LOAD_BALANCER_DNS"
+        controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
+        etcd:
+            external:
+                endpoints:
+                - https://ETCD_0_IP:2379
+                - https://ETCD_1_IP:2379
+                - https://ETCD_2_IP:2379
+                caFile: /etc/kubernetes/pki/etcd/ca.crt
+                certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
+                keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
+
+    - ここで、積み重なったetcdと外部etcdの違いは、kubeadmコンフィグの`etcd`に`external`フィールドを使用していることです。積み重なったetcdトポロジーの場合、これは自動で管理されます。
+
+    -  テンプレート内の以下の変数を、クラスターに合わせて適切な値に置き換えます:
+
+        - `LOAD_BALANCER_DNS`
+        - `LOAD_BALANCER_PORT`
+        - `ETCD_0_IP`
+        - `ETCD_1_IP`
+        - `ETCD_2_IP`
+
+1.  `kubeadm init --config kubeadm-config.yaml`をこのノードで実行します。
+
+1.  表示されたjoinコマンドを、あとで使うためにテキストファイルに書き込みます。
+
+1.  Weave CNIプラグインをapplyします:
+
+    ```sh
+    kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
+    ```
+
+### 残りのコントロールプレーンノードの手順
+
+残りのコントロールプレーンノードを参加させるために、[こちらの手順](#残りのコントロールプレーンノードの手順)に従います。ローカルetcdメンバーが作られないことを除いて、積み重なったetcdの構築と同じ手順です。
+
+まとめると:
+
+- 最初のコントロールプレーンノードが完全に初期化されているのを確認します。
+- 証明書を、最初のコントロールプレーンノードから他のコントロールプレーンノードへコピーします。
+- テキストファイルに保存したjoinコマンドに`--experimental-control-plane` フラグを加えたものを使って、それぞれのコントロールプレーンノードを参加させます。
+
+## コントロールプレーン起動後の共通タスク
+
+### Podネットワークのインストール
+
+Podネットワークをインストールするには、[こちらの手順に従ってください](/ja/docs/setup/independent/create-cluster-kubeadm/#pod-network)。master設定ファイルで提供したPod CIDRのどれかに一致することを確認します。
+
+### workerのインストール
+
+`kubeadm init`コマンドから返されたコマンドを利用して、workerノードをクラスターに参加させることが可能です。workerノードには、`--experimental-control-plane`フラグを追加する必要はありません。
+
+{{% /capture %}}
@@ -0,0 +1,281 @@
+---
+title: kubeadmのインストール
+content_template: templates/task
+weight: 20
+card:
+  name: setup
+  weight: 20
+  title: kubeadmセットアップツールのインストール
+---
+
+{{% capture overview %}}
+
+<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">This page shows how to install the `kubeadm` toolbox.
+For information how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+* One or more machines running one of:
+  - Ubuntu 16.04+
+  - Debian 9
+  - CentOS 7
+  - RHEL 7
+  - Fedora 25/26 (best-effort)
+  - HypriotOS v1.0.1+
+  - Container Linux (tested with 1800.6.0)
+* 2 GB or more of RAM per machine (any less will leave little room for your apps)
+* 2 CPUs or more
+* Full network connectivity between all machines in the cluster (public or private network is fine)
+* Unique hostname, MAC address, and product_uuid for every node. See [here](#MACアドレスとproduct_uuidが全てのノードでユニークであることの検証) for more details.
+* Certain ports are open on your machines. See [here](#必須ポートの確認) for more details.
+* Swap disabled. You **MUST** disable swap in order for the kubelet to work properly.
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## MACアドレスとproduct_uuidが全てのノードでユニークであることの検証
+
+* You can get the MAC address of the network interfaces using the command `ip link` or `ifconfig -a`
+* The product_uuid can be checked by using the command `sudo cat /sys/class/dmi/id/product_uuid`
+
+It is very likely that hardware devices will have unique addresses, although some virtual machines may have
+identical values. Kubernetes uses these values to uniquely identify the nodes in the cluster.
+If these values are not unique to each node, the installation process
+may [fail](https://github.com/kubernetes/kubeadm/issues/31).
+
+## ネットワークアダプタの確認
+
+If you have more than one network adapter, and your Kubernetes components are not reachable on the default
+route, we recommend you add IP route(s) so Kubernetes cluster addresses go via the appropriate adapter.
+
+## 必須ポートの確認
+
+### マスターノード
+
+| Protocol | Direction | Port Range | Purpose                 | Used By                   |
+|----------|-----------|------------|-------------------------|---------------------------|
+| TCP      | Inbound   | 6443*      | Kubernetes API server   | All                       |
+| TCP      | Inbound   | 2379-2380  | etcd server client API  | kube-apiserver, etcd      |
+| TCP      | Inbound   | 10250      | Kubelet API             | Self, Control plane       |
+| TCP      | Inbound   | 10251      | kube-scheduler          | Self                      |
+| TCP      | Inbound   | 10252      | kube-controller-manager | Self                      |
+
+### ワーカーノード
+
+| Protocol | Direction | Port Range  | Purpose               | Used By                 |
+|----------|-----------|-------------|-----------------------|-------------------------|
+| TCP      | Inbound   | 10250       | Kubelet API           | Self, Control plane     |
+| TCP      | Inbound   | 30000-32767 | NodePort Services**   | All                     |
+
+** Default port range for [NodePort Services](/docs/concepts/services-networking/service/).
+
+Any port numbers marked with * are overridable, so you will need to ensure any
+custom ports you provide are also open.
+
+Although etcd ports are included in control-plane nodes, you can also host your own
+etcd cluster externally or on custom ports.
+
+The pod network plugin you use (see below) may also require certain ports to be
+open. Since this differs with each pod network plugin, please see the
+documentation for the plugins about what port(s) those need.
+
+## ランタイムのインストール
+
+Since v1.6.0, Kubernetes has enabled the use of CRI, Container Runtime Interface, by default.
+
+Since v1.14.0, kubeadm will try to automatically detect the container runtime on Linux nodes
+by scanning through a list of well known domain sockets. The detectable runtimes and the
+socket paths, that are used, can be found in the table below.
+
+| Runtime    | Domain Socket                    |
+|------------|----------------------------------|
+| Docker     | /var/run/docker.sock             |
+| containerd | /run/containerd/containerd.sock  |
+| CRI-O      | /var/run/crio/crio.sock          |
+
+If both Docker and containerd are detected together, Docker takes precedence. This is
+needed, because Docker 18.09 ships with containerd and both are detectable.
+If any other two or more runtimes are detected, kubeadm will exit with an appropriate
+error message.
+
+On non-Linux nodes the container runtime used by default is Docker.
+
+If the container runtime of choice is Docker, it is used through the built-in
+`dockershim` CRI implementation inside of the `kubelet`.
+
+Other CRI-based runtimes include:
+
+- [containerd](https://github.com/containerd/cri) (CRI plugin built into containerd)
+- [cri-o](https://cri-o.io/)
+- [frakti](https://github.com/kubernetes/frakti)
+
+Refer to the [CRI installation instructions](/ja/docs/setup/cri) for more information.
+
+## kubeadm、kubelet、kubectlのインストール
+
+You will install these packages on all of your machines:
+
+* `kubeadm`: the command to bootstrap the cluster.
+
+* `kubelet`: the component that runs on all of the machines in your cluster
+    and does things like starting pods and containers.
+
+* `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 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
+server version. For example, kubelets running 1.7.0 should be fully compatible with a 1.8.0 API server,
+but not vice versa.
+
+For information about installing `kubectl`, see [Install and set up kubectl](/docs/tasks/tools/install-kubectl/).
+
+{{< warning >}}
+These instructions exclude all Kubernetes packages from any system upgrades.
+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, see:
+
+* Kubernetes [version and version-skew policy](/ja/docs/setup/release/version-skew-policy/)
+* Kubeadm-specific [version skew policy](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)
+
+{{< tabs name="k8s_install" >}}
+{{% tab name="Ubuntu, Debian or HypriotOS" %}}
+```bash
+apt-get update && apt-get install -y apt-transport-https curl
+curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
+cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
+deb https://apt.kubernetes.io/ kubernetes-xenial main
+EOF
+apt-get update
+apt-get install -y kubelet kubeadm kubectl
+apt-mark hold kubelet kubeadm kubectl
+```
+{{% /tab %}}
+{{% tab name="CentOS, RHEL or Fedora" %}}
+```bash
+cat <<EOF > /etc/yum.repos.d/kubernetes.repo
+[kubernetes]
+name=Kubernetes
+baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
+enabled=1
+gpgcheck=1
+repo_gpgcheck=1
+gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
+EOF
+
+# Set SELinux in permissive mode (effectively disabling it)
+setenforce 0
+sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
+
+yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
+
+systemctl enable --now kubelet
+```
+
+  **Note:**
+
+  - Setting SELinux in permissive mode by running `setenforce 0` and `sed ...` effectively disables it.
+    This is required to allow containers to access the host filesystem, which is needed by pod networks for example.
+    You have to do this until SELinux support is improved in the kubelet.
+  - Some users on RHEL/CentOS 7 have reported issues with traffic being routed incorrectly due to iptables being bypassed. You should ensure
+    `net.bridge.bridge-nf-call-iptables` is set to 1 in your `sysctl` config, e.g.
+
+    ```bash
+    cat <<EOF >  /etc/sysctl.d/k8s.conf
+    net.bridge.bridge-nf-call-ip6tables = 1
+    net.bridge.bridge-nf-call-iptables = 1
+    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):
+
+```bash
+CNI_VERSION="v0.7.5"
+mkdir -p /opt/cni/bin
+curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz
+```
+
+Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI))
+
+```bash
+CRICTL_VERSION="v1.12.0"
+mkdir -p /opt/bin
+curl -L "https://github.com/kubernetes-incubator/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz
+```
+
+Install `kubeadm`, `kubelet`, `kubectl` and add a `kubelet` systemd service:
+
+```bash
+RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
+
+mkdir -p /opt/bin
+cd /opt/bin
+curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
+chmod +x {kubeadm,kubelet,kubectl}
+
+curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/kubelet.service" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service
+mkdir -p /etc/systemd/system/kubelet.service.d
+curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
+```
+
+Enable and start `kubelet`:
+
+```bash
+systemctl enable --now kubelet
+```
+{{% /tab %}}
+{{< /tabs >}}
+
+
+The kubelet is now restarting every few seconds, as it waits in a crashloop for
+kubeadm to tell it what to do.
+
+## マスターノードのkubeletによって使用されるcgroupドライバの設定
+
+When using Docker, kubeadm will automatically detect the cgroup driver for the kubelet
+and set it in the `/var/lib/kubelet/kubeadm-flags.env` file during runtime.
+
+If you are using a different CRI, you have to modify the file
+`/etc/default/kubelet` with your `cgroup-driver` value, like so:
+
+```bash
+KUBELET_EXTRA_ARGS=--cgroup-driver=<value>
+```
+
+This file will be used by `kubeadm init` and `kubeadm join` to source extra
+user defined arguments for the kubelet.
+
+Please mind, that you **only** have to do that if the cgroup driver of your CRI
+is not `cgroupfs`, because that is the default value in the kubelet already.
+
+Restarting the kubelet is required:
+
+```bash
+systemctl daemon-reload
+systemctl restart kubelet
+```
+
+The automatic detection of cgroup driver for other container runtimes
+like CRI-O and containerd is work in progress.
+
+
+## トラブルシュート
+
+If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
+
+{{% capture whatsnext %}}
+
+* [Using kubeadm to Create a Cluster](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
+
+{{% /capture %}}
@@ -0,0 +1,200 @@
+---
+title: kubeadmを使用したクラスター内の各kubeletの設定
+content_template: templates/concept
+weight: 80
+---
+
+{{% capture overview %}}
+
+{{< feature-state for_k8s_version="1.11" state="stable" >}}
+
+The lifecycle of the kubeadm CLI tool is decoupled from the
+[kubelet](/docs/reference/command-line-tools-reference/kubelet), which is a daemon that runs
+on each node within the Kubernetes cluster. The kubeadm CLI tool is executed by the user when Kubernetes is
+initialized or upgraded, whereas the kubelet is always running in the background.
+
+Since the kubelet is a daemon, it needs to be maintained by some kind of a init
+system or service manager. When the kubelet is installed using DEBs or RPMs,
+systemd is configured to manage the kubelet. You can use a different service
+manager instead, but you need to configure it manually.
+
+Some kubelet configuration details need to be the same across all kubelets involved in the cluster, while
+other configuration aspects need to be set on a per-kubelet basis, to accommodate the different
+characteristics of a given machine, such as OS, storage, and networking. You can manage the configuration
+of your kubelets manually, but [kubeadm now provides a `KubeletConfiguration` API type for managing your
+kubelet configurations centrally](#configure-kubelets-using-kubeadm).
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Kubeletの設定パターン
+
+The following sections describe patterns to kubelet configuration that are simplified by
+using kubeadm, rather than managing the kubelet configuration for each Node manually.
+
+### 各kubeletにクラスターレベルの設定を配布
+
+You can provide the kubelet with default values to be used by `kubeadm init` and `kubeadm join`
+commands. Interesting examples include using a different CRI runtime or setting the default subnet
+used by services.
+
+If you want your services to use the subnet `10.96.0.0/12` as the default for services, you can pass
+the `--service-cidr` parameter to kubeadm:
+
+```bash
+kubeadm init --service-cidr 10.96.0.0/12
+```
+
+Virtual IPs for services are now allocated from this subnet. You also need to set the DNS address used
+by the kubelet, using the `--cluster-dns` flag. This setting needs to be the same for every kubelet
+on every manager and Node in the cluster. The kubelet provides a versioned, structured API object
+that can configure most parameters in the kubelet and push out this configuration to each running
+kubelet in the cluster. This object is called **the kubelet's ComponentConfig**.
+The ComponentConfig allows the user to specify flags such as the cluster DNS IP addresses expressed as
+a list of values to a camelCased key, illustrated by the following example:
+
+```yaml
+apiVersion: kubelet.config.k8s.io/v1beta1
+kind: KubeletConfiguration
+clusterDNS:
+- 10.96.0.10
+```
+
+For more details on the ComponentConfig have a look at [this section](#configure-kubelets-using-kubeadm).
+
+### インスタンス固有の設定内容を適用
+
+Some hosts require specific kubelet configurations, due to differences in hardware, operating system,
+networking, or other host-specific parameters. The following list provides a few examples.
+
+- The path to the DNS resolution file, as specified by the `--resolv-conf` kubelet
+  configuration flag, may differ among operating systems, or depending on whether you are using
+  `systemd-resolved`. If this path is wrong, DNS resolution will fail on the Node whose kubelet
+  is configured incorrectly.
+
+- The Node API object `.metadata.name` is set to the machine's hostname by default,
+  unless you are using a cloud provider. You can use the `--hostname-override` flag to override the
+  default behavior if you need to specify a Node name different from the machine's hostname.
+
+- Currently, the kubelet cannot automatically detects the cgroup driver used by the CRI runtime,
+  but the value of `--cgroup-driver` must match the cgroup driver used by the CRI runtime to ensure
+  the health of the kubelet.
+
+- Depending on the CRI runtime your cluster uses, you may need to specify different flags to the kubelet.
+  For instance, when using Docker, you need to specify flags such as `--network-plugin=cni`, but if you
+  are using an external runtime, you need to specify `--container-runtime=remote` and specify the CRI
+  endpoint using the `--container-runtime-path-endpoint=<path>`.
+
+You can specify these flags by configuring an individual kubelet's configuration in your service manager,
+such as systemd.
+
+## kubeadmを使用したkubeletの設定
+
+It is possible to configure the kubelet that kubeadm will start if a custom `KubeletConfiguration`
+API object is passed with a configuration file like so `kubeadm ... --config some-config-file.yaml`.
+
+By calling `kubeadm config print init-defaults --component-configs KubeletConfiguration` you can
+see all the default values for this structure.
+
+Also have a look at the [API reference for the
+kubelet ComponentConfig](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration)
+for more information on the individual fields.
+
+### `kubeadm init`実行時の流れ
+
+When you call `kubeadm init`, the kubelet configuration is marshalled to disk
+at `/var/lib/kubelet/config.yaml`, and also uploaded to a ConfigMap in the cluster. The ConfigMap
+is named `kubelet-config-1.X`, where `.X` is the minor version of the Kubernetes version you are
+initializing. A kubelet configuration file is also written to `/etc/kubernetes/kubelet.conf` with the
+baseline cluster-wide configuration for all kubelets in the cluster. This configuration file
+points to the client certificates that allow the kubelet to communicate with the API server. This
+addresses the need to
+[propagate cluster-level configuration to each kubelet](#propagating-cluster-level-configuration-to-each-kubelet).
+
+To address the second pattern of
+[providing instance-specific configuration details](#providing-instance-specific-configuration-details),
+kubeadm writes an environment file to `/var/lib/kubelet/kubeadm-flags.env`, which contains a list of
+flags to pass to the kubelet when it starts. The flags are presented in the file like this:
+
+```bash
+KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."
+```
+
+In addition to the flags used when starting the kubelet, the file also contains dynamic
+parameters such as the cgroup driver and whether to use a different CRI runtime socket
+(`--cri-socket`).
+
+After marshalling these two files to disk, kubeadm attempts to run the following two
+commands, if you are using systemd:
+
+```bash
+systemctl daemon-reload && systemctl restart kubelet
+```
+
+If the reload and restart are successful, the normal `kubeadm init` workflow continues.
+
+### `kubeadm join`実行時の流れ
+
+When you run `kubeadm join`, kubeadm uses the Bootstrap Token credential to perform
+a TLS bootstrap, which fetches the credential needed to download the
+`kubelet-config-1.X` ConfigMap and writes it to `/var/lib/kubelet/config.yaml`. The dynamic
+environment file is generated in exactly the same way as `kubeadm init`.
+
+Next, `kubeadm` runs the following two commands to load the new configuration into the kubelet:
+
+```bash
+systemctl daemon-reload && systemctl restart kubelet
+```
+
+After the kubelet loads the new configuration, kubeadm writes the
+`/etc/kubernetes/bootstrap-kubelet.conf` KubeConfig file, which contains a CA certificate and Bootstrap
+Token. These are used by the kubelet to perform the TLS Bootstrap and obtain a unique
+credential, which is stored in `/etc/kubernetes/kubelet.conf`. When this file is written, the kubelet
+has finished performing the TLS Bootstrap.
+
+##  kubelet用のsystemdファイル
+
+The configuration file installed by the kubeadm DEB or RPM package is written to
+`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` and is used by systemd.
+
+```none
+[Service]
+Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
+--kubeconfig=/etc/kubernetes/kubelet.conf"
+Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
+# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating
+the KUBELET_KUBEADM_ARGS variable dynamically
+EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
+# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably,
+#the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
+# KUBELET_EXTRA_ARGS should be sourced from this file.
+EnvironmentFile=-/etc/default/kubelet
+ExecStart=
+ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
+```
+
+This file specifies the default locations for all of the files managed by kubeadm for the kubelet.
+
+- The KubeConfig file to use for the TLS Bootstrap is `/etc/kubernetes/bootstrap-kubelet.conf`,
+  but it is only used if `/etc/kubernetes/kubelet.conf` does not exist.
+- The KubeConfig file with the unique kubelet identity is `/etc/kubernetes/kubelet.conf`.
+- 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/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バイナリとパッケージの内容
+
+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. |
+| `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 the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). |
+
+{{% /capture %}}
@@ -0,0 +1,68 @@
+---
+title: Configuring your kubernetes cluster to self-host the control plane
+content_template: templates/concept
+weight: 100
+---
+
+{{% capture overview %}}
+
+### Self-hosting the Kubernetes control plane {#self-hosting}
+
+As of 1.8, you can experimentally create a _self-hosted_ Kubernetes control
+plane. This means that key components such as the API server, controller
+manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
+configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/)
+configured in the kubelet via static files.
+
+To create a self-hosted cluster see the
+[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+#### Caveats
+
+{{< caution >}}
+This feature pivots your cluster into an unsupported state, rendering kubeadm unable
+to manage you cluster any longer. This includes `kubeadm upgrade`.
+{{< /caution >}}
+
+1. Self-hosting in 1.8 and later has some important limitations. In particular, a
+  self-hosted cluster _cannot recover from a reboot of the control-plane node_
+  without manual intervention.
+
+1. By default, self-hosted control plane Pods rely on credentials loaded from
+  [`hostPath`](/docs/concepts/storage/volumes/#hostpath)
+  volumes. Except for initial creation, these credentials are not managed by
+  kubeadm.
+
+1. The self-hosted portion of the control plane does not include etcd,
+  which still runs as a static Pod.
+
+#### Process
+
+The self-hosting bootstrap process is documented in the [kubeadm design
+document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting).
+
+In summary, `kubeadm alpha selfhosting` works as follows:
+
+  1. Waits for this bootstrap static control plane to be running and
+    healthy. This is identical to the `kubeadm init` process without self-hosting.
+
+  1. Uses the static control plane Pod manifests to construct a set of
+    DaemonSet manifests that will run the self-hosted control plane.
+    It also modifies these manifests where necessary, for example adding new volumes
+    for secrets.
+
+  1. Creates DaemonSets in the `kube-system` namespace and waits for the
+     resulting Pods to be running.
+
+  1. Once self-hosted Pods are operational, their associated static Pods are deleted
+     and kubeadm moves on to install the next component. This triggers kubelet to
+     stop those static Pods.
+
+  1. When the original static control plane stops, the new self-hosted control
+    plane is able to bind to listening ports and become active.
+
+{{% /capture %}}
@@ -0,0 +1,264 @@
+---
+title: kubeadmを使用した高可用性etcdクラスターの作成
+content_template: templates/task
+weight: 70
+---
+
+{{% capture overview %}}
+
+Kubeadm defaults to running a single member etcd cluster in a static pod managed
+by the kubelet on the control plane node. This is not a high availability setup
+as the etcd cluster contains only one member and cannot sustain any members
+becoming unavailable. This task walks through the process of creating a high
+availability etcd cluster of three members that can be used as an external etcd
+when using kubeadm to set up a kubernetes cluster.
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+* Three hosts that can talk to each other over ports 2379 and 2380. This
+  document assumes these default ports. However, they are configurable through
+  the kubeadm config file.
+* Each host must [have docker, kubelet, and kubeadm installed][toolbox].
+* Some infrastructure to copy files between hosts. For example `ssh` and `scp`
+  can satisfy this requirement.
+
+[toolbox]: /docs/setup/production-environment/tools/kubeadm/install-kubeadm/
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## クラスターの構築
+
+The general approach is to generate all certs on one node and only distribute
+the *necessary* files to the other nodes.
+
+{{< note >}}
+kubeadm contains all the necessary crytographic machinery to generate
+the certificates described below; no other cryptographic tooling is required for
+this example.
+{{< /note >}}
+
+
+1. Configure the kubelet to be a service manager for etcd.
+
+    Since etcd was created first, you must override the service priority by creating a new unit file
+    that has higher precedence than the kubeadm-provided kubelet unit file.
+
+    ```sh
+    cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
+    [Service]
+    ExecStart=
+    ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests
+    Restart=always
+    EOF
+
+    systemctl daemon-reload
+    systemctl restart kubelet
+    ```
+
+1. Create configuration files for kubeadm.
+
+    Generate one kubeadm configuration file for each host that will have an etcd
+    member running on it using the following script.
+
+    ```sh
+    # Update HOST0, HOST1, and HOST2 with the IPs or resolvable names of your hosts
+    export HOST0=10.0.0.6
+    export HOST1=10.0.0.7
+    export HOST2=10.0.0.8
+
+    # Create temp directories to store files that will end up on other hosts.
+    mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
+
+    ETCDHOSTS=(${HOST0} ${HOST1} ${HOST2})
+    NAMES=("infra0" "infra1" "infra2")
+
+    for i in "${!ETCDHOSTS[@]}"; do
+    HOST=${ETCDHOSTS[$i]}
+    NAME=${NAMES[$i]}
+    cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
+    apiVersion: "kubeadm.k8s.io/v1beta1"
+    kind: ClusterConfiguration
+    etcd:
+        local:
+            serverCertSANs:
+            - "${HOST}"
+            peerCertSANs:
+            - "${HOST}"
+            extraArgs:
+                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
+                listen-client-urls: https://${HOST}:2379
+                advertise-client-urls: https://${HOST}:2379
+                initial-advertise-peer-urls: https://${HOST}:2380
+    EOF
+    done
+    ```
+
+1. Generate the certificate authority
+
+    If you already have a CA then the only action that is copying the CA's `crt` and
+    `key` file to `/etc/kubernetes/pki/etcd/ca.crt` and
+    `/etc/kubernetes/pki/etcd/ca.key`. After those files have been copied,
+    proceed to the next step, "Create certificates for each member".
+
+    If you do not already have a CA then run this command on `$HOST0` (where you
+    generated the configuration files for kubeadm).
+
+    ```
+    kubeadm init phase certs etcd-ca
+    ```
+
+    This creates two files
+
+    - `/etc/kubernetes/pki/etcd/ca.crt`
+    - `/etc/kubernetes/pki/etcd/ca.key`
+
+1. Create certificates for each member
+
+    ```sh
+    kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
+    kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
+    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
+    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
+    cp -R /etc/kubernetes/pki /tmp/${HOST2}/
+    # cleanup non-reusable certificates
+    find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
+
+    kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
+    kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
+    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
+    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
+    cp -R /etc/kubernetes/pki /tmp/${HOST1}/
+    find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
+
+    kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
+    kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
+    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
+    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
+    # No need to move the certs because they are for HOST0
+
+    # clean up certs that should not be copied off this host
+    find /tmp/${HOST2} -name ca.key -type f -delete
+    find /tmp/${HOST1} -name ca.key -type f -delete
+    ```
+
+1. Copy certificates and kubeadm configs
+
+    The certificates have been generated and now they must be moved to their
+    respective hosts.
+
+     ```sh
+     USER=ubuntu
+     HOST=${HOST1}
+     scp -r /tmp/${HOST}/* ${USER}@${HOST}:
+     ssh ${USER}@${HOST}
+     USER@HOST $ sudo -Es
+     root@HOST $ chown -R root:root pki
+     root@HOST $ mv pki /etc/kubernetes/
+     ```
+
+1. Ensure all expected files exist
+
+    The complete list of required files on `$HOST0` is:
+
+    ```
+    /tmp/${HOST0}
+    └── kubeadmcfg.yaml
+    ---
+    /etc/kubernetes/pki
+    ├── apiserver-etcd-client.crt
+    ├── apiserver-etcd-client.key
+    └── etcd
+        ├── ca.crt
+        ├── ca.key
+        ├── healthcheck-client.crt
+        ├── healthcheck-client.key
+        ├── peer.crt
+        ├── peer.key
+        ├── server.crt
+        └── server.key
+    ```
+
+    On `$HOST1`:
+
+    ```
+    $HOME
+    └── kubeadmcfg.yaml
+    ---
+    /etc/kubernetes/pki
+    ├── apiserver-etcd-client.crt
+    ├── apiserver-etcd-client.key
+    └── etcd
+        ├── ca.crt
+        ├── healthcheck-client.crt
+        ├── healthcheck-client.key
+        ├── peer.crt
+        ├── peer.key
+        ├── server.crt
+        └── server.key
+    ```
+
+    On `$HOST2`
+
+    ```
+    $HOME
+    └── kubeadmcfg.yaml
+    ---
+    /etc/kubernetes/pki
+    ├── apiserver-etcd-client.crt
+    ├── apiserver-etcd-client.key
+    └── etcd
+        ├── ca.crt
+        ├── healthcheck-client.crt
+        ├── healthcheck-client.key
+        ├── peer.crt
+        ├── peer.key
+        ├── server.crt
+        └── server.key
+    ```
+
+1. Create the static pod manifests
+
+    Now that the certificates and configs are in place it's time to create the
+    manifests. On each host run the `kubeadm` command to generate a static manifest
+    for etcd.
+
+    ```sh
+    root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
+    root@HOST1 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
+    root@HOST2 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
+    ```
+
+1. Optional: Check the cluster health
+
+    ```sh
+    docker run --rm -it \
+    --net host \
+    -v /etc/kubernetes:/etc/kubernetes quay.io/coreos/etcd:${ETCD_TAG} etcdctl \
+    --cert-file /etc/kubernetes/pki/etcd/peer.crt \
+    --key-file /etc/kubernetes/pki/etcd/peer.key \
+    --ca-file /etc/kubernetes/pki/etcd/ca.crt \
+    --endpoints https://${HOST0}:2379 cluster-health
+    ...
+    cluster is healthy
+    ```
+    - Set `${ETCD_TAG}` to the version tag of your etcd image. For example `v3.2.24`.
+    - Set `${HOST0}`to the IP address of the host you are testing.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+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](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/).
+
+{{% /capture %}}
+
+
@@ -0,0 +1,321 @@
+---
+title: kubeadmのトラブルシューティング
+content_template: templates/concept
+weight: 90
+---
+
+{{% capture overview %}}
+
+As with any program, you might run into an error installing or running kubeadm.
+This page lists some common failure scenarios and have provided steps that can help you understand and fix the problem.
+
+If your problem is not listed below, please follow the following steps:
+
+- If you think your problem is a bug with kubeadm:
+  - Go to [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) and search for existing issues.
+  - If no issue exists, please [open one](https://github.com/kubernetes/kubeadm/issues/new) and follow the issue template.
+
+- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
+  relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## インストール中に`ebtables`もしくは他の似たような実行プログラムが見つからない
+
+If you see the following warnings while running `kubeadm init`
+
+```sh
+[preflight] WARNING: ebtables not found in system path
+[preflight] WARNING: ethtool not found in system path
+```
+
+Then you may be missing `ebtables`, `ethtool` or a similar executable on your node. You can install them with the following commands:
+
+- For Ubuntu/Debian users, run `apt install ebtables ethtool`.
+- For CentOS/Fedora users, run `yum install ebtables ethtool`.
+
+## インストール中にkubeadmがコントロールプレーンを待ち続けて止まる
+
+If you notice that `kubeadm init` hangs after printing out the following line:
+
+```sh
+[apiclient] Created API client, waiting for the control plane to become ready
+```
+
+This may be caused by a number of problems. The most common are:
+
+- network connection problems. Check that your machine has full network connectivity before continuing.
+- the default cgroup driver configuration for the kubelet differs from that used by Docker.
+  Check the system log file (e.g. `/var/log/message`) or examine the output from `journalctl -u kubelet`. If you see something like the following:
+
+  ```shell
+  error: failed to run Kubelet: failed to create kubelet:
+  misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"
+  ```
+
+  There are two common ways to fix the cgroup driver problem:
+
+ 1. Install Docker again following instructions
+  [here](/ja/docs/setup/independent/install-kubeadm/#installing-docker).
+
+ 1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to
+    [Configure cgroup driver used by kubelet on Master Node](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
+
+- control plane Docker containers are crashlooping or hanging. You can check this by running `docker ps` and investigating each container by running `docker logs`.
+
+## 管理コンテナを削除する時にkubeadmが止まる
+
+The following could happen if Docker halts and does not remove any Kubernetes-managed containers:
+
+```bash
+sudo kubeadm reset
+[preflight] Running pre-flight checks
+[reset] Stopping the kubelet service
+[reset] Unmounting mounted directories in "/var/lib/kubelet"
+[reset] Removing kubernetes-managed containers
+(block)
+```
+
+A possible solution is to restart the Docker service and then re-run `kubeadm reset`:
+
+```bash
+sudo systemctl restart docker.service
+sudo kubeadm reset
+```
+
+Inspecting the logs for docker may also be useful:
+
+```sh
+journalctl -ul docker
+```
+
+## Podの状態が`RunContainerError`、`CrashLoopBackOff`、または`Error`
+
+Right after `kubeadm init` there should not be any pods in these states.
+
+- If there are pods in one of these states _right after_ `kubeadm init`, please open an
+  issue in the kubeadm repo. `coredns` (or `kube-dns`) should be in the `Pending` state
+  until you have deployed the network solution.
+- If you see Pods in the `RunContainerError`, `CrashLoopBackOff` or `Error` state
+  after deploying the network solution and nothing happens to `coredns` (or `kube-dns`),
+  it's very likely that the Pod Network solution that you installed is somehow broken.
+  You might have to grant it more RBAC privileges or use a newer version. Please file
+  an issue in the Pod Network providers' issue tracker and get the issue triaged there.
+- If you install a version of Docker older than 1.12.1, remove the `MountFlags=slave` option
+  when booting `dockerd` with `systemd` and restart `docker`. You can see the MountFlags in `/usr/lib/systemd/system/docker.service`.
+  MountFlags can interfere with volumes mounted by Kubernetes, and put the Pods in `CrashLoopBackOff` state.
+  The error happens when Kubernetes does not find `var/run/secrets/kubernetes.io/serviceaccount` files.
+
+## `coredns`(もしくは`kube-dns`)が`Pending`状態でスタックする
+
+This is **expected** and part of the design. kubeadm is network provider-agnostic, so the admin
+should [install the pod network solution](/docs/concepts/cluster-administration/addons/)
+of choice. You have to install a Pod Network
+before CoreDNS may be deployed fully. Hence the `Pending` state before the network is set up.
+
+## `HostPort`サービスが動かない
+
+The `HostPort` and `HostIP` functionality is available depending on your Pod Network
+provider. Please contact the author of the Pod Network solution to find out whether
+`HostPort` and `HostIP` functionality are available.
+
+Calico, Canal, and Flannel CNI providers are verified to support HostPort.
+
+For more information, see the [CNI portmap documentation](https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md).
+
+If your network provider does not support the portmap CNI plugin, you may need to use the [NodePort feature of
+services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetwork=true`.
+
+## サービスIP経由でPodにアクセスすることができない
+
+- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)
+  which allows pods to access themselves via their Service IP. This is an issue related to
+  [CNI](https://github.com/containernetworking/cni/issues/476). Please contact the network
+  add-on provider to get the latest status of their support for hairpin mode.
+
+- If you are using VirtualBox (directly or via Vagrant), you will need to
+  ensure that `hostname -i` returns a routable IP address. By default the first
+  interface is connected to a non-routable host-only network. A work around
+  is to modify `/etc/hosts`, see this [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)
+  for an example.
+
+## TLS証明書のエラー
+
+The following error indicates a possible certificate mismatch.
+
+```none
+# kubectl get pods
+Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
+```
+
+- Verify that the `$HOME/.kube/config` file contains a valid certificate, and
+  regenerate a certificate if necessary. The certificates in a kubeconfig file
+  are base64 encoded. The `base64 -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
+  mv  $HOME/.kube $HOME/.kube.bak
+  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
+  sudo chown $(id -u):$(id -g) $HOME/.kube/config
+  ```
+
+## Vagrant内でPodネットワークとしてflannelを使用する時のデフォルトNIC
+
+The following error might indicate that something was wrong in the pod network:
+
+```sh
+Error from server (NotFound): the server could not find the requested resource
+```
+
+- If you're using flannel as the pod network inside Vagrant, then you will have to specify the default interface name for flannel.
+
+  Vagrant typically assigns two interfaces to all VMs. The first, for which all hosts are assigned the IP address `10.0.2.15`, is for external traffic that gets NATed.
+
+  This may lead to problems with flannel, which defaults to the first interface on a host. This leads to all hosts thinking they have the same public IP address. To prevent this, pass the `--iface eth1` flag to flannel so that the second interface is chosen.
+
+## 公開されていないIPがコンテナに使われている
+
+In some situations `kubectl logs` and `kubectl run` commands may return with the following errors in an otherwise functional cluster:
+
+```sh
+Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: dial tcp 10.19.0.41:10250: getsockopt: no route to host
+```
+
+- This may be due to Kubernetes using an IP that can not communicate with other IPs on the seemingly same subnet, possibly by policy of the machine provider.
+- Digital Ocean assigns a public IP to `eth0` as well as a private one to be used internally as anchor for their floating IP feature, yet `kubelet` will pick the latter as the node's `InternalIP` instead of the public one.
+
+  Use `ip addr show` to check for this scenario instead of `ifconfig` because `ifconfig` will not display the offending alias IP address. Alternatively an API endpoint specific to Digital Ocean allows to query for the anchor IP from the droplet:
+
+  ```sh
+  curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
+  ```
+
+  The workaround is to tell `kubelet` which IP to use using `--node-ip`. When using Digital Ocean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this.
+
+  Then restart `kubelet`:
+
+  ```sh
+  systemctl daemon-reload
+  systemctl restart kubelet
+  ```
+
+## `coredns`のPodが`CrashLoopBackOff`もしくは`Error`状態になる
+
+If you have nodes that are running SELinux with an older version of Docker you might experience a scenario
+where the `coredns` pods are not starting. To solve that you can try one of the following options:
+
+- Upgrade to a [newer version of Docker](/ja/docs/setup/independent/install-kubeadm/#installing-docker).
+
+- [Disable SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux).
+- Modify the `coredns` deployment to set `allowPrivilegeEscalation` to `true`:
+
+```bash
+kubectl -n kube-system get deployment coredns -o yaml | \
+  sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
+  kubectl apply -f -
+```
+
+Another cause for CoreDNS to have `CrashLoopBackOff` is when a CoreDNS Pod deployed in Kubernetes detects a loop. [A number of workarounds](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)
+are available to avoid Kubernetes trying to restart the CoreDNS Pod every time CoreDNS detects the loop and exits.
+
+{{< warning >}}
+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
+```
+
+## Not possible to pass a comma separated list of values to arguments inside a `--component-extra-args` flag
+
+`kubeadm init` flags such as `--component-extra-args` allow you to pass custom arguments to a control-plane
+component like the kube-apiserver. However, this mechanism is limited due to the underlying type used for parsing
+the values (`mapStringString`).
+
+If you decide to pass an argument that supports multiple, comma-separated values such as
+`--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"` this flag will fail with
+`flag: malformed pair, expect string=string`. This happens because the list of arguments for
+`--apiserver-extra-args` expects `key=value` pairs and in this case `NamespacesExists` is considered
+as a key that is missing a value.
+
+Alternatively, you can try separating the `key=value` pairs like so:
+`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
+but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`.
+
+A known workaround is to use the kubeadm [configuration file](/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags).
+
+## kube-proxy scheduled before node is initialized by cloud-controller-manager
+
+In cloud provider scenarios, kube-proxy can end up being scheduled on new worker nodes before
+the cloud-controller-manager has initialized the node addresses. This causes kube-proxy to fail
+to pick up the node's IP address properly and has knock-on effects to the proxy function managing
+load balancers.
+
+The following error can be seen in kube-proxy Pods:
+```
+server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: []
+proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP
+```
+
+A known solution is to patch the kube-proxy DaemonSet to allow scheduling it on control-plane
+nodes regardless of their conditions, keeping it off of other nodes until their initial guarding
+conditions abate:
+```
+kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/master" } ] } } } }'
+```
+
+The tracking issue for this problem is [here](https://github.com/kubernetes/kubeadm/issues/1027).
+
+## The NodeRegistration.Taints field is omitted when marshalling kubeadm configuration
+
+*Note: This [issue](https://github.com/kubernetes/kubeadm/issues/1358) only applies to tools that marshal kubeadm types (e.g. to a YAML configuration file). It will be fixed in kubeadm API v1beta2.*
+
+By default, kubeadm applies the `role.kubernetes.io/master:NoSchedule` taint to control-plane nodes.
+If you prefer kubeadm to not taint the control-plane node, and set `InitConfiguration.NodeRegistration.Taints` to an empty slice,
+the field will be omitted when marshalling. When the field is omitted, kubeadm applies the default taint.
+
+There are at least two workarounds:
+
+1. Use the `role.kubernetes.io/master:PreferNoSchedule` taint instead of an empty slice. [Pods will get scheduled on masters](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/), unless other nodes have capacity.
+
+2. Remove the taint after kubeadm init exits:
+```bash
+kubectl taint nodes NODE_NAME role.kubernetes.io/master:NoSchedule-
+```
+{{% /capture %}}
@@ -0,0 +1,121 @@
+---
+title: kubesprayを使ったオンプレミス/クラウドプロバイダへのKubernetesのインストール
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray).
+
+Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
+
+* a highly available cluster
+* composable attributes
+* support for most popular Linux distributions
+  * Container Linux by CoreOS
+  * Debian Jessie, Stretch, Wheezy
+  * Ubuntu 16.04, 18.04
+  * CentOS/RHEL 7
+  * Fedora/CentOS Atomic
+  * openSUSE Leap 42.3/Tumbleweed
+* continuous integration tests
+
+To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops).
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## クラスタの作成
+
+### (1/5) 下地の要件の確認
+
+Provision servers with the following [requirements](https://github.com/kubernetes-incubator/kubespray#requirements):
+
+* **Ansible v2.5 (or newer) and python-netaddr is installed on the machine that will run Ansible commands**
+* **Jinja 2.9 (or newer) is required to run the Ansible Playbooks**
+* The target servers must have **access to the Internet** in order to pull docker images
+* The target servers are configured to allow **IPv4 forwarding**
+* **Your ssh key must be copied** to all the servers part of your inventory
+* The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall
+* If kubespray is ran from non-root user account, correct privilege escalation method should be configured in the target servers. Then the `ansible_become` flag or command parameters `--become` or `-b` should be specified
+
+Kubespray provides the following utilities to help provision your environment:
+
+* [Terraform](https://www.terraform.io/) scripts for the following cloud providers:
+  * [AWS](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/aws)
+  * [OpenStack](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/openstack)
+
+### (2/5) インベントリファイルの用意
+
+After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
+
+### (3/5) クラスタ作成の計画
+
+Kubespray provides the ability to customize many aspects of the deployment:
+
+* Choice deployment mode: kubeadm or non-kubeadm
+* CNI (networking) plugins
+* DNS configuration
+* Choice of control plane: native/binary or containerized with docker or rkt
+* Component versions
+* Calico route reflectors
+* Component runtime options
+  * docker
+  * rkt
+  * cri-o
+* Certificate generation methods (**Vault being discontinued**)
+
+Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
+
+### (4/5) クラスタのデプロイ
+
+Next, deploy your cluster:
+
+Cluster deployment using [ansible-playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
+
+```shell
+ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \
+  --private-key=~/.ssh/private_key
+```
+
+Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/large-deployments.md) for best results.
+
+### (5/5) デプロイの確認
+
+Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators.
+
+## クラスタの操作
+
+Kubespray provides additional playbooks to manage your cluster: _scale_ and _upgrade_.
+
+### クラスタのスケール
+
+You can add worker nodes from your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#adding-nodes)".
+You can remove worker nodes from your cluster by running the remove-node playbook. For more information, see "[Remove nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#remove-nodes)".
+
+### クラスタのアップグレード
+
+You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/upgrades.md)".
+
+## クリーンアップ
+
+You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/reset.yml).
+
+{{< caution >}}
+When running the reset playbook, be sure not to accidentally target your production cluster!
+{{< /caution >}}
+
+## フィードバック
+
+* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/)
+* [GitHub Issues](https://github.com/kubernetes-incubator/kubespray/issues)
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md).
+
+{{% /capture %}}
@@ -0,0 +1,4 @@
+---
+title: Turnkey Cloud Solutions
+weight: 40
+---
@@ -0,0 +1,17 @@
+---
+title: Alibaba CloudでKubernetesを動かす
+---
+
+## Alibaba Cloud Container Service
+
+[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.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を使用する場合は、以下の手順に従って下さい。
+
+## 構築のカスタム
+
+[Alibaba Cloudプロバイダーが実装されたKubernetesのソースコード](https://github.com/AliyunContainerService/kubernetes)はオープンソースであり、GitHubから入手可能です。
+
+さらなる情報は英語の[Kubernetesのクイックデプロイメント - Alibaba CloudのVPC環境](https://www.alibabacloud.com/forum/read-830)および[中国語](https://yq.aliyun.com/articles/66474)をご覧下さい。
@@ -0,0 +1,87 @@
+---
+title: AWS EC2上でKubernetesを動かす
+content_template: templates/task
+---
+
+{{% capture overview %}}
+
+このページでは、AWS上でKubernetesクラスターをインストールする方法について説明します。
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+AWS上でKubernetesクラスターを作成するには、AWSからアクセスキーIDおよびシークレットアクセスキーを入手する必要があります。
+
+### サポートされているプロダクショングレードのツール
+
+* [conjure-up](/docs/getting-started-guides/ubuntu/)はUbuntu上でネイティブなAWSインテグレーションを用いてKubernetesクラスターを作成するオープンソースのインストーラーです。
+
+* [Kubernetes Operations](https://github.com/kubernetes/kops) - プロダクショングレードなKubernetesのインストール、アップグレード、管理が可能です。AWS上のDebian、Ubuntu、CentOS、RHELをサポートしています。
+
+* [CoreOS Tectonic](https://coreos.com/tectonic/)はAWS上のContainer Linuxノードを含むKubernetesクラスターを作成できる、オープンソースの[Tectonic Installer](https://github.com/coreos/tectonic-installer)を含みます。
+
+* CoreOSから生まれ、Kubernetes IncubatorがメンテナンスしているCLIツール[kube-aws](https://github.com/kubernetes-incubator/kube-aws)は、[Container Linux](https://coreos.com/why/)ノードを使用したAWSツール(EC2、CloudFormation、Auto Scaling)によるKubernetesクラスターを作成および管理できます。
+
+* [KubeOne](https://github.com/kubermatic/kubeone)は可用性の高いKubernetesクラスターを作成、アップグレード、管理するための、オープンソースのライフサイクル管理ツールです。
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## クラスターの始まり
+
+### コマンドライン管理ツール: kubectl
+
+クラスターの起動スクリプトによってワークステーション上に`kubernetes`ディレクトリが作成されます。もしくは、Kubernetesの最新リリースを[こちら](https://github.com/kubernetes/kubernetes/releases)からダウンロードすることも可能です。
+
+次に、kubectlにアクセスするために適切なバイナリフォルダーを`PATH`へ追加します:
+
+```shell
+# macOS
+export PATH=<path/to/kubernetes-directory>/platforms/darwin/amd64:$PATH
+
+# Linux
+export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH
+```
+
+ツールに関する最新のドキュメントページはこちらです: [kubectl manual](/docs/user-guide/kubectl/)
+
+デフォルトでは、`kubectl`はクラスターの起動中に生成された`kubeconfig`ファイルをAPIに対する認証に使用します。
+詳細な情報は、[kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください。
+
+### 例
+
+新しいクラスターを試すには、[簡単なnginxの例](/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。
+
+"Guestbook"アプリケーションは、Kubernetesを始めるもう一つのポピュラーな例です: [guestbookの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)
+
+より完全なアプリケーションについては、[examplesディレクトリ](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)を参照してください。
+
+## クラスターのスケーリング
+
+`kubectl`を使用したノードの追加および削除はサポートしていません。インストール中に作成された[Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html)内の'Desired'および'Max'プロパティを手動で調整することで、ノード数をスケールさせることができます。
+
+## クラスターの解体
+
+クラスターのプロビジョニングに使用した環境変数がexportされていることを確認してから、`kubernetes`ディレクトリ内で以下のスクリプトを実行してください:
+
+```shell
+cluster/kube-down.sh
+```
+
+## サポートレベル
+
+
+IaaS プロバイダー    | 構成管理     | OS            | ネットワーク  | ドキュメント                                  | 適合     | サポートレベル
+-------------------- | ------------ | ------------- | ------------  | --------------------------------------------- | ---------| ----------------------------
+AWS                  | kops         | Debian        | k8s (VPC)     | [docs](https://github.com/kubernetes/kops)    |          | Community ([@justinsb](https://github.com/justinsb))
+AWS                  | CoreOS       | CoreOS        | flannel       | [docs](/docs/getting-started-guides/aws)      |          | Community
+AWS                  | Juju         | Ubuntu        | flannel, calico, canal     | [docs](/docs/getting-started-guides/ubuntu)      | 100%     | Commercial, Community
+AWS                  | KubeOne         | Ubuntu, CoreOS, CentOS   | canal, weavenet     | [docs](https://github.com/kubermatic/kubeone)      | 100%    | Commercial, Community
+
+## 参考文献
+
+Kubernetesクラスターの利用と管理に関する詳細は、[Kubernetesドキュメント](/ja/docs/)を参照してください。
+
+{{% /capture %}}
@@ -0,0 +1,33 @@
+---
+title: Azure 上で Kubernetes を動かす
+---
+
+## Azure Kubernetes Service (AKS)
+
+[Azure Kubernetes Service](https://azure.microsoft.com/ja-jp/services/kubernetes-service/)は、Kubernetesクラスターのためのシンプルなデプロイ機能を提供します。
+
+Azure Kubernetes Serviceを利用してAzure上にKubernetesクラスターをデプロイする例:
+
+**[Microsoft Azure Kubernetes Service](https://docs.microsoft.com/ja-jp/azure/aks/intro-kubernetes)**
+
+## デプロイのカスタマイズ: AKS-Engine
+
+Azure Kubernetes Serviceのコア部分は**オープンソース**であり、コミュニティのためにGitHub上で公開され、利用およびコントリビュートすることができます: **[AKS-Engine](https://github.com/Azure/aks-engine)**。レガシーな [ACS-Engine](https://github.com/Azure/acs-engine) のコードベースはAKS-engineのために廃止となりました。
+
+AKS-Engineは、Azure Kubernetes Serviceが公式にサポートしている機能を超えてデプロイをカスタマイズしたい場合に適した選択肢です。
+既存の仮想ネットワークへのデプロイや、複数のagent poolを利用するなどのカスタマイズをすることができます。
+コミュニティによるAKS-Engineへのコントリビュートが、Azure Kubernetes Serviceに組み込まれる場合もあります。
+
+AKS-Engineへの入力は、Kubernetesクラスターを記述するapimodelのJSONファイルです。これはAzure Kubernetes Serviceを使用してクラスターを直接デプロイするために使用されるAzure Resource Manager (ARM) のテンプレート構文と似ています。
+処理結果はARMテンプレートとして出力され、ソース管理に組み込んだり、AzureにKubernetesクラスターをデプロイするために使うことができます。
+
+**[AKS-Engine Kubernetes Tutorial](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/README.md)** を参照して始めることができます。
+
+## Azure上でCoreOS Tectonicを動かす
+
+Azureで利用できるCoreOS Tectonic Installerは**オープンソース**であり、コミュニティのためにGitHub上で公開され、利用およびコントリビュートすることができます: **[Tectonic Installer](https://github.com/coreos/tectonic-installer)**.
+
+Tectonic Installerは、 [Hashicorp が提供する Terraform](https://www.terraform.io/docs/providers/azurerm/)のAzure Resource Manager(ARM)プロバイダーを用いてクラスターをカスタマイズしたい場合に適した選択肢です。
+これを利用することにより、Terraformと親和性の高いツールを使用してカスタマイズしたり連携したりすることができます。
+
+[Tectonic Installer for Azure Guide](https://coreos.com/tectonic/docs/latest/install/azure/azure-terraform.html)を参照して、すぐに始めることができます。
@@ -0,0 +1,340 @@
+---
+title: CenturyLink Cloud上でKubernetesを動かす
+---
+
+
+These scripts handle the creation, deletion and expansion of Kubernetes clusters on CenturyLink Cloud.
+
+You can accomplish all these tasks with a single command. We have made the Ansible playbooks used to perform these tasks available [here](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md).
+
+## ヘルプの検索
+
+If you run into any problems or want help with anything, we are here to help. Reach out to use via any of the following ways:
+
+- Submit a github issue
+- Send an email to Kubernetes AT ctl DOT io
+- Visit [http://info.ctl.io/kubernetes](http://info.ctl.io/kubernetes)
+
+## 仮想マシンもしくは物理サーバーのクラスター、その選択
+
+- We support Kubernetes clusters on both Virtual Machines or Physical Servers. If you want to use physical servers for the worker nodes (minions), simple use the --minion_type=bareMetal flag.
+- For more information on physical servers, visit: [https://www.ctl.io/bare-metal/](https://www.ctl.io/bare-metal/)
+- Physical serves are only available in the VA1 and GB3 data centers.
+- VMs are available in all 13 of our public cloud locations
+
+## 必要条件
+
+The requirements to run this script are:
+
+- A linux administrative host (tested on ubuntu and macOS)
+- python 2 (tested on 2.7.11)
+  - pip (installed with python as of 2.7.9)
+- git
+- A CenturyLink Cloud account with rights to create new hosts
+- An active VPN connection to the CenturyLink Cloud from your linux host
+
+## スクリプトのインストール
+
+After you have all the requirements met, please follow these instructions to install this script.
+
+1) Clone this repository and cd into it.
+
+```shell
+git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc
+```
+
+2) Install all requirements, including
+
+  * Ansible
+  * CenturyLink Cloud SDK
+  * Ansible Modules
+
+```shell
+sudo pip install -r ansible/requirements.txt
+```
+
+3) Create the credentials file from the template and use it to set your ENV variables
+
+```shell
+cp ansible/credentials.sh.template ansible/credentials.sh
+vi ansible/credentials.sh
+source ansible/credentials.sh
+
+```
+
+4) Grant your machine access to the CenturyLink Cloud network by using a VM inside the network or [ configuring a VPN connection to the CenturyLink Cloud network.](https://www.ctl.io/knowledge-base/network/how-to-configure-client-vpn/)
+
+
+#### スクリプトのインストールの例: Ububtu 14の手順
+
+If you use an ubuntu 14, for your convenience we have provided a step by step
+guide to install the requirements and install the script.
+
+```shell
+# system
+apt-get update
+apt-get install -y git python python-crypto
+curl -O https://bootstrap.pypa.io/get-pip.py
+python get-pip.py
+
+# installing this repository
+mkdir -p ~home/k8s-on-clc
+cd ~home/k8s-on-clc
+git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc.git
+cd adm-kubernetes-on-clc/
+pip install -r requirements.txt
+
+# getting started
+cd ansible
+cp credentials.sh.template credentials.sh; vi credentials.sh
+source credentials.sh
+```
+
+
+
+## クラスターの作成
+
+To create a new Kubernetes cluster, simply run the ```kube-up.sh``` script. A complete
+list of script options and some examples are listed below.
+
+```shell
+CLC_CLUSTER_NAME=[name of kubernetes cluster]
+cd ./adm-kubernetes-on-clc
+bash kube-up.sh -c="$CLC_CLUSTER_NAME"
+```
+
+It takes about 15 minutes to create the cluster. Once the script completes, it
+will output some commands that will help you setup kubectl on your machine to
+point to the new cluster.
+
+When the cluster creation is complete, the configuration files for it are stored
+locally on your administrative host, in the following directory
+
+```shell
+> CLC_CLUSTER_HOME=$HOME/.clc_kube/$CLC_CLUSTER_NAME/
+```
+
+
+#### クラスターの作成: スクリプトのオプション
+
+```shell
+Usage: kube-up.sh [OPTIONS]
+Create servers in the CenturyLinkCloud environment and initialize a Kubernetes cluster
+Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in
+order to access the CenturyLinkCloud API
+
+All options (both short and long form) require arguments, and must include "="
+between option name and option value.
+
+     -h (--help)                   display this help and exit
+     -c= (--clc_cluster_name=)     set the name of the cluster, as used in CLC group names
+     -t= (--minion_type=)          standard -> VM (default), bareMetal -> physical]
+     -d= (--datacenter=)           VA1 (default)
+     -m= (--minion_count=)         number of kubernetes minion nodes
+     -mem= (--vm_memory=)          number of GB ram for each minion
+     -cpu= (--vm_cpu=)             number of virtual cps for each minion node
+     -phyid= (--server_conf_id=)   physical server configuration id, one of
+                                      physical_server_20_core_conf_id
+                                      physical_server_12_core_conf_id
+                                      physical_server_4_core_conf_id (default)
+     -etcd_separate_cluster=yes    create a separate cluster of three etcd nodes,
+                                   otherwise run etcd on the master node
+```
+
+## クラスターの拡張
+
+To expand an existing Kubernetes cluster, run the ```add-kube-node.sh```
+script. A complete list of script options and some examples are listed [below](#cluster-expansion-script-options).
+This script must be run from the same host that created the cluster (or a host
+that has the cluster artifact files stored in ```~/.clc_kube/$cluster_name```).
+
+```shell
+cd ./adm-kubernetes-on-clc
+bash add-kube-node.sh -c="name_of_kubernetes_cluster" -m=2
+```
+
+#### クラスターの拡張: スクリプトのオプション
+
+```shell
+Usage: add-kube-node.sh [OPTIONS]
+Create servers in the CenturyLinkCloud environment and add to an
+existing CLC kubernetes cluster
+
+Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in
+order to access the CenturyLinkCloud API
+
+     -h (--help)                   display this help and exit
+     -c= (--clc_cluster_name=)     set the name of the cluster, as used in CLC group names
+     -m= (--minion_count=)         number of kubernetes minion nodes to add
+```
+
+## クラスターの削除
+
+There are two ways to delete an existing cluster:
+
+1) Use our python script:
+
+```shell
+python delete_cluster.py --cluster=clc_cluster_name --datacenter=DC1
+```
+
+2) Use the CenturyLink Cloud UI. To delete a cluster, log into the CenturyLink
+Cloud control portal and delete the parent server group that contains the
+Kubernetes Cluster. We hope to add a scripted option to do this soon.
+
+## 例
+
+Create a cluster with name of k8s_1, 1 master node and 3 worker minions (on physical machines), in VA1
+
+```shell
+bash kube-up.sh --clc_cluster_name=k8s_1 --minion_type=bareMetal --minion_count=3 --datacenter=VA1
+```
+
+Create a cluster with name of k8s_2, an ha etcd cluster on 3 VMs and 6 worker minions (on VMs), in VA1
+
+```shell
+bash kube-up.sh --clc_cluster_name=k8s_2 --minion_type=standard --minion_count=6 --datacenter=VA1 --etcd_separate_cluster=yes
+```
+
+Create a cluster with name of k8s_3, 1 master node, and 10 worker minions (on VMs) with higher mem/cpu, in UC1:
+
+```shell
+bash kube-up.sh --clc_cluster_name=k8s_3 --minion_type=standard --minion_count=10 --datacenter=VA1 -mem=6 -cpu=4
+```
+
+
+
+## クラスターの機能とアーキテクチャ
+
+We configure the Kubernetes cluster with the following features:
+
+* KubeDNS: DNS resolution and service discovery
+* Heapster/InfluxDB: For metric collection. Needed for Grafana and auto-scaling.
+* Grafana: Kubernetes/Docker metric dashboard
+* KubeUI: Simple web interface to view Kubernetes state
+* Kube Dashboard: New web interface to interact with your cluster
+
+We use the following to create the Kubernetes cluster:
+
+* Kubernetes 1.1.7
+* Ubuntu 14.04
+* Flannel 0.5.4
+* Docker 1.9.1-0~trusty
+* Etcd 2.2.2
+
+## 任意のアドオン
+
+* Logging: We offer an integrated centralized logging ELK platform so that all
+  Kubernetes and docker logs get sent to the ELK stack. To install the ELK stack
+  and configure Kubernetes to send logs to it, follow [the log
+  aggregation documentation](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/log_aggregration.md). Note: We don't install this by default as
+  the footprint isn't trivial.
+
+## クラスターの管理
+
+The most widely used tool for managing a Kubernetes cluster is the command-line
+utility ```kubectl```.  If you do not already have a copy of this binary on your
+administrative machine, you may run the script ```install_kubectl.sh``` which will
+download it and install it in ```/usr/bin/local```.
+
+The script requires that the environment variable ```CLC_CLUSTER_NAME``` be defined. ```install_kubectl.sh``` also writes a configuration file which will embed the necessary
+authentication certificates for the particular cluster.  The configuration file is
+written to the  ```${CLC_CLUSTER_HOME}/kube``` directory
+
+
+```shell
+export KUBECONFIG=${CLC_CLUSTER_HOME}/kube/config
+kubectl version
+kubectl cluster-info
+```
+
+### プログラムでクラスターへアクセス
+
+It's possible to use the locally stored client certificates to access the apiserver. For example, you may want to use any of the [Kubernetes API client libraries](/docs/reference/using-api/client-libraries/) to program against your Kubernetes cluster in the programming language of your choice.
+
+To demonstrate how to use these locally stored certificates, we provide the following example of using ```curl``` to communicate to the master apiserver via https:
+
+```shell
+curl \
+   --cacert ${CLC_CLUSTER_HOME}/pki/ca.crt  \
+   --key ${CLC_CLUSTER_HOME}/pki/kubecfg.key \
+   --cert ${CLC_CLUSTER_HOME}/pki/kubecfg.crt  https://${MASTER_IP}:6443
+```
+
+But please note, this *does not* work out of the box with the ```curl``` binary
+distributed with macOS.
+
+### ブラウザーを使ったクラスターへのアクセス
+
+We install [the kubernetes dashboard](/docs/tasks/web-ui-dashboard/). When you
+create a cluster, the script should output URLs for these interfaces like this:
+
+kubernetes-dashboard is running at ```https://${MASTER_IP}:6443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy```.
+
+Note on Authentication to the UIs:
+
+The cluster is set up to use basic authentication for the user _admin_.
+Hitting the url at ```https://${MASTER_IP}:6443``` will
+require accepting the self-signed certificate
+from the apiserver, and then presenting the admin
+password written to file at: ```> _${CLC_CLUSTER_HOME}/kube/admin_password.txt_```
+
+
+### 設定ファイル
+
+Various configuration files are written into the home directory *CLC_CLUSTER_HOME* under ```.clc_kube/${CLC_CLUSTER_NAME}``` in several subdirectories. You can use these files
+to access the cluster from machines other than where you created the cluster from.
+
+* ```config/```: Ansible variable files containing parameters describing the master and minion hosts
+* ```hosts/```: hosts files listing access information for the Ansible playbooks
+* ```kube/```: ```kubectl``` configuration files, and the basic-authentication password for admin access to the Kubernetes API
+* ```pki/```: public key infrastructure files enabling TLS communication in the cluster
+* ```ssh/```: SSH keys for root access to the hosts
+
+
+## ```kubectl``` usage examples
+
+There are a great many features of _kubectl_.  Here are a few examples
+
+List existing nodes, pods, services and more, in all namespaces, or in just one:
+
+```shell
+kubectl get nodes
+kubectl get --all-namespaces pods
+kubectl get --all-namespaces services
+kubectl get --namespace=kube-system replicationcontrollers
+```
+
+The Kubernetes API server exposes services on web URLs, which are protected by requiring
+client certificates.  If you run a kubectl proxy locally, ```kubectl``` will provide
+the necessary certificates and serve locally over http.
+
+```shell
+kubectl proxy -p 8001
+```
+
+Then, you can access urls like ```http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/``` without the need for client certificates in your browser.
+
+
+## どのKubernetesの機能がCenturyLink Cloud上で動かないのか
+
+These are the known items that don't work on CenturyLink cloud but do work on other cloud providers:
+
+- At this time, there is no support services of the type [LoadBalancer](/docs/tasks/access-application-cluster/create-external-load-balancer/). We are actively working on this and hope to publish the changes sometime around April 2016.
+
+- At this time, there is no support for persistent storage volumes provided by
+  CenturyLink Cloud. However, customers can bring their own persistent storage
+  offering. We ourselves use Gluster.
+
+
+## Ansibleのファイル
+
+If you want more information about our Ansible files, please [read this file](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md)
+
+## 参考文献
+
+Please see the [Kubernetes docs](/ja/docs/) for more details on administering
+and using a Kubernetes cluster.
+
+
+
@@ -0,0 +1,223 @@
+---
+title: Google Compute Engine上でKubernetesを動かす
+content_template: templates/task
+---
+
+{{% capture overview %}}
+
+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 %}}
+
+{{% capture prerequisites %}}
+
+If you want a simplified getting started experience and GUI for managing clusters, please consider trying [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) for hosted cluster installation and management.
+
+For an easy way to experiment with the Kubernetes development environment, click the button below
+to open a Google Cloud Shell with an auto-cloned copy of the Kubernetes source repo.
+
+[![Open in Cloud Shell](https://gstatic.com/cloudssh/images/open-btn.png)](https://console.cloud.google.com/cloudshell/open?git_repo=https://github.com/kubernetes/kubernetes&page=editor&open_in_editor=README.md)
+
+If you want to use custom binaries or pure open source Kubernetes, please continue with the instructions below.
+
+### 前提条件
+
+1. You need a Google Cloud Platform account with billing enabled. Visit the [Google Developers Console](https://console.cloud.google.com) for more details.
+1. Install `gcloud` as necessary. `gcloud` can be installed as a part of the [Google Cloud SDK](https://cloud.google.com/sdk/).
+1. Enable the [Compute Engine Instance Group Manager API](https://console.developers.google.com/apis/api/replicapool.googleapis.com/overview) in the [Google Cloud developers console](https://console.developers.google.com/apis/library).
+1. Make sure that gcloud is set to use the Google Cloud Platform project you want. You can check the current project using `gcloud config list project` and change it via `gcloud config set project <project-id>`.
+1. Make sure you have credentials for GCloud by running `gcloud auth login`.
+1. (Optional)  In order to make API calls against GCE, you must also run `gcloud auth application-default login`.
+1. Make sure you can start up a GCE VM from the command line.  At least make sure you can do the [Create an instance](https://cloud.google.com/compute/docs/instances/#startinstancegcloud) part of the GCE Quickstart.
+1. Make sure you can SSH into the VM without interactive prompts.  See the [Log in to the instance](https://cloud.google.com/compute/docs/instances/#sshing) part of the GCE Quickstart.
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## クラスターの起動
+
+You can install a client and start a cluster with either one of these commands (we list both in case only one is installed on your machine):
+
+
+```shell
+curl -sS https://get.k8s.io | bash
+```
+
+or
+
+```shell
+wget -q -O - https://get.k8s.io | bash
+```
+
+Once this command completes, you will have a master VM and four worker VMs, running as a Kubernetes cluster.
+
+By default, some containers will already be running on your cluster. Containers like `fluentd` provide [logging](/docs/concepts/cluster-administration/logging/), while `heapster` provides [monitoring](https://releases.k8s.io/master/cluster/addons/cluster-monitoring/README.md) services.
+
+The script run by the commands above creates a cluster with the name/prefix "kubernetes". It defines one specific cluster config, so you can't run it more than once.
+
+Alternately, you can download and install the latest Kubernetes release from [this page](https://github.com/kubernetes/kubernetes/releases), then run the `<kubernetes>/cluster/kube-up.sh` script to start the cluster:
+
+```shell
+cd kubernetes
+cluster/kube-up.sh
+```
+
+If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `<kubernetes>/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster.
+
+If you run into trouble, please see the section on [troubleshooting](/ja/docs/setup/production-environment/turnkey/gce/#troubleshooting), post to the
+[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting/#slack).
+
+The next few steps will show you:
+
+1. How to set up the command line client on your workstation to manage the cluster
+1. Examples of how to use the cluster
+1. How to delete the cluster
+1. How to start clusters with non-default options (like larger clusters)
+
+## ワークステーション上でのKubernetesコマンドラインツールのインストール
+
+The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation.
+
+The [kubectl](/docs/user-guide/kubectl/) tool controls the Kubernetes cluster
+manager.  It lets you inspect your cluster resources, create, delete, and update
+components, and much more. You will use it to look at your new cluster and bring
+up example apps.
+
+You can use `gcloud` to install the `kubectl` command-line tool on your workstation:
+
+```shell
+gcloud components install kubectl
+```
+
+{{< note >}}
+The kubectl version bundled with `gcloud` may be older than the one
+downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/kubectl/install/)
+document to see how you can set up the latest `kubectl` on your workstation.
+{{< /note >}}
+
+## クラスターの始まり
+
+### クラスターの様子を見る
+
+Once `kubectl` is in your path, you can use it to look at your cluster. E.g., running:
+
+```shell
+kubectl get --all-namespaces services
+```
+
+should show a set of [services](/docs/user-guide/services) that look something like this:
+
+```shell
+NAMESPACE     NAME          TYPE             CLUSTER_IP       EXTERNAL_IP       PORT(S)        AGE
+default       kubernetes    ClusterIP        10.0.0.1         <none>            443/TCP        1d
+kube-system   kube-dns      ClusterIP        10.0.0.2         <none>            53/TCP,53/UDP  1d
+kube-system   kube-ui       ClusterIP        10.0.0.3         <none>            80/TCP         1d
+...
+```
+
+Similarly, you can take a look at the set of [pods](/docs/user-guide/pods) that were created during cluster startup.
+You can do this via the
+
+```shell
+kubectl get --all-namespaces pods
+```
+
+command.
+
+You'll see a list of pods that looks something like this (the name specifics will be different):
+
+```shell
+NAMESPACE     NAME                                           READY     STATUS    RESTARTS   AGE
+kube-system   coredns-5f4fbb68df-mc8z8                       1/1       Running   0          15m
+kube-system   fluentd-cloud-logging-kubernetes-minion-63uo   1/1       Running   0          14m
+kube-system   fluentd-cloud-logging-kubernetes-minion-c1n9   1/1       Running   0          14m
+kube-system   fluentd-cloud-logging-kubernetes-minion-c4og   1/1       Running   0          14m
+kube-system   fluentd-cloud-logging-kubernetes-minion-ngua   1/1       Running   0          14m
+kube-system   kube-ui-v1-curt1                               1/1       Running   0          15m
+kube-system   monitoring-heapster-v5-ex4u3                   1/1       Running   1          15m
+kube-system   monitoring-influx-grafana-v1-piled             2/2       Running   0          15m
+```
+
+Some of the pods may take a few seconds to start up (during this time they'll show `Pending`), but check that they all show as `Running` after a short period.
+
+### いくつかの例の実行
+
+Then, see [a simple nginx example](/docs/user-guide/simple-nginx) to try out your new cluster.
+
+For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/).  The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough.
+
+## クラスターの解体
+
+To remove/delete/teardown the cluster, use the `kube-down.sh` script.
+
+```shell
+cd kubernetes
+cluster/kube-down.sh
+```
+
+Likewise, the `kube-up.sh` in the same directory will bring it back up. You do not need to rerun the `curl` or `wget` command: everything needed to setup the Kubernetes cluster is now on your workstation.
+
+## カスタマイズ
+
+The script above relies on Google Storage to stage the Kubernetes release. It
+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).
+
+## トラブルシューティング
+
+### プロジェクトの設定
+
+You need to have the Google Cloud Storage API, and the Google Cloud Storage
+JSON API enabled. It is activated by default for new projects. Otherwise, it
+can be done in the Google Cloud Console.  See the [Google Cloud Storage JSON
+API Overview](https://cloud.google.com/storage/docs/json_api/) for more
+details.
+
+Also ensure that-- as listed in the [Prerequisites section](#前提条件)-- you've enabled the `Compute Engine Instance Group Manager API`, and can start up a GCE VM from the command line as in the [GCE Quickstart](https://cloud.google.com/compute/docs/quickstart) instructions.
+
+### クラスター初期化のハング
+
+If the Kubernetes startup script hangs waiting for the API to be reachable, you can troubleshoot by SSHing into the master and node VMs and looking at logs such as `/var/log/startupscript.log`.
+
+**Once you fix the issue, you should run `kube-down.sh` to cleanup** after the partial cluster creation, before running `kube-up.sh` to try again.
+
+### SSH
+
+If you're having trouble SSHing into your instances, ensure the GCE firewall
+isn't blocking port 22 to your VMs.  By default, this should work but if you
+have edited firewall rules or created a new non-default network, you'll need to
+expose it: `gcloud compute firewall-rules create default-ssh --network=<network-name>
+--description "SSH allowed from anywhere" --allow tcp:22`
+
+Additionally, your GCE SSH key must either have no passcode or you need to be
+using `ssh-agent`.
+
+### ネットワーク
+
+The instances must be able to connect to each other using their private IP. The
+script uses the "default" network which should have a firewall rule called
+"default-allow-internal" which allows traffic on any port on the private IPs.
+If this rule is missing from the default network or if you change the network
+being used in `cluster/config-default.sh` create a new rule with the following
+field values:
+
+* Source Ranges: `10.0.0.0/8`
+* Allowed Protocols and Port: `tcp:1-65535;udp:1-65535;icmp`
+
+## サポートレベル
+
+
+IaaS Provider        | Config. Mgmt | OS     | Networking  | Docs                                              | Conforms | Support Level
+-------------------- | ------------ | ------ | ----------  | ---------------------------------------------     | ---------| ----------------------------
+GCE                  | Saltstack    | Debian | GCE         | [docs](/ja/docs/setup/production-environment/turnkey/gce/)                                    |   | Project
+
+
+## 参考文献
+
+Please see the [Kubernetes docs](/ja/docs/) for more details on administering
+and using a Kubernetes cluster.
+
+{{% /capture %}}
@@ -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,187 @@
+---
+title: Stackpoint.ioを利用して複数のクラウド上でKubernetesを動かす
+content_template: templates/concept
+---
+
+{{% capture overview %}}
+
+[StackPointCloud](https://stackpoint.io/) is the universal control plane for Kubernetes Anywhere. StackPointCloud allows you to deploy and manage a Kubernetes cluster to the cloud provider of your choice in 3 steps using a web-based interface.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## AWS
+
+To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secret Access Key from AWS.
+
+1. Choose a Provider
+
+    a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account.
+
+    b. Click **+ADD A CLUSTER NOW**.
+
+    c. Click to select Amazon Web Services (AWS).
+
+1. Configure Your Provider
+
+    a. Add your Access Key ID and a Secret Access Key from AWS. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair.
+
+    b. Click **SUBMIT** to submit the authorization information.
+
+1. Configure Your Cluster
+
+    Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
+
+1. Run the Cluster
+
+    You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
+
+    For information on using and managing a Kubernetes cluster on AWS, [consult the  Kubernetes documentation](/docs/getting-started-guides/aws/).
+
+
+## GCE
+
+To create a Kubernetes cluster on GCE, you will need the Service Account JSON Data from Google.
+
+1. Choose a Provider
+
+    a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account.
+
+    b. Click **+ADD A CLUSTER NOW**.
+
+    c. Click to select Google Compute Engine (GCE).
+
+1. Configure Your Provider
+
+    a. Add your Service Account JSON Data from Google. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair.
+
+    b. Click **SUBMIT** to submit the authorization information.
+
+1. Configure Your Cluster
+
+    Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
+
+1. Run the Cluster
+
+    You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
+
+    For information on using and managing a Kubernetes cluster on GCE, [consult the  Kubernetes documentation](/docs/getting-started-guides/gce/).
+
+
+## Google Kubernetes Engine
+
+To create a Kubernetes cluster on Google Kubernetes Engine, you will need the Service Account JSON Data from Google.
+
+1. Choose a Provider
+
+    a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account.
+
+    b. Click **+ADD A CLUSTER NOW**.
+
+    c. Click to select Google Kubernetes Engine.
+
+1. Configure Your Provider
+
+    a. Add your Service Account JSON Data from Google. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair.
+
+    b. Click **SUBMIT** to submit the authorization information.
+
+1. Configure Your Cluster
+
+    Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
+
+1. Run the Cluster
+
+    You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
+
+    For information on using and managing a Kubernetes cluster on Google Kubernetes Engine, consult [the official documentation](/ja/docs/home/).
+
+
+## DigitalOcean
+
+To create a Kubernetes cluster on DigitalOcean, you will need a DigitalOcean API Token.
+
+1. Choose a Provider
+
+    a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account.
+
+    b. Click **+ADD A CLUSTER NOW**.
+
+    c. Click to select DigitalOcean.
+
+1. Configure Your Provider
+
+    a. Add your DigitalOcean API Token. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair.
+
+    b. Click **SUBMIT** to submit the authorization information.
+
+1. Configure Your Cluster
+
+    Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
+
+1. Run the Cluster
+
+    You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
+
+    For information on using and managing a Kubernetes cluster on DigitalOcean, consult [the official documentation](/ja/docs/home/).
+
+
+## Microsoft Azure
+
+To create a Kubernetes cluster on Microsoft Azure, you will need an Azure Subscription ID, Username/Email, and Password.
+
+1. Choose a Provider
+
+    a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account.
+
+    b. Click **+ADD A CLUSTER NOW**.
+
+    c. Click to select Microsoft Azure.
+
+1. Configure Your Provider
+
+    a. Add your Azure Subscription ID, Username/Email, and Password. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair.
+
+    b. Click **SUBMIT** to submit the authorization information.
+
+1. Configure Your Cluster
+
+    Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
+
+1. Run the Cluster
+
+    You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
+
+    For information on using and managing a Kubernetes cluster on Azure, [consult the  Kubernetes documentation](/docs/getting-started-guides/azure/).
+
+
+## Packet
+
+To create a Kubernetes cluster on Packet, you will need a Packet API Key.
+
+1. Choose a Provider
+
+    a. Log in to [stackpoint.io](https://stackpoint.io) with a GitHub, Google, or Twitter account.
+
+    b. Click **+ADD A CLUSTER NOW**.
+
+    c. Click to select Packet.
+
+1. Configure Your Provider
+
+    a. Add your Packet API Key. Select your default StackPointCloud SSH keypair, or click **ADD SSH KEY** to add a new keypair.
+
+    b. Click **SUBMIT** to submit the authorization information.
+
+1. Configure Your Cluster
+
+    Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
+
+1. Run the Cluster
+
+    You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
+
+    For information on using and managing a Kubernetes cluster on Packet, consult [the official documentation](/ja/docs/home/).
+
+{{% /capture %}}
@@ -0,0 +1,4 @@
+---
+title: "Windows in Kubernetes"
+weight: 50
+---
@@ -0,0 +1,590 @@
+---
+reviewers:
+- michmike
+- patricklang
+title: Intro to Windows support in Kubernetes
+content_template: templates/concept
+weight: 65
+---
+
+{{% capture overview %}}
+
+Windows applications constitute a large portion of the services and applications that run in many organizations. [Windows containers](https://aka.ms/windowscontainers) provide a modern way to encapsulate processes and package dependencies, making it easier to use DevOps practices and follow cloud native patterns for Windows applications. Kubernetes has become the defacto standard container orchestrator, and the release of Kubernetes 1.14 includes production support for scheduling Windows containers on Windows nodes in a Kubernetes cluster, enabling a vast ecosystem of Windows applications to leverage the power of Kubernetes. Organizations with investments in Windows-based applications and Linux-based applications don't have to look for separate orchestrators to manage their workloads, leading to increased operational efficiencies across their deployments, regardless of operating system.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Windows containers in Kubernetes
+
+To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in [Pods](/ja/docs/concepts/workloads/pods/pod-overview/) on Kubernetes is as simple and easy as scheduling Linux-based containers.
+
+In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling [Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) on Windows (including kubelet, [container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), and kube-proxy). For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
+
+{{< note >}}
+The Kubernetes control plane, including the [master components](/ja/docs/concepts/overview/components/), continues to run on Linux. There are no plans to have a Windows-only Kubernetes cluster.
+{{< /note >}}
+
+{{< note >}}
+In this document, when we talk about Windows containers we mean Windows containers with process isolation. Windows containers with [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) is planned for a future release.
+{{< /note >}}
+
+## Supported Functionality and Limitations
+
+### Supported Functionality
+
+#### Compute
+
+From an API and kubectl perspective, Windows containers behave in much the same way as Linux-based containers. However, there are some notable differences in key functionality which are outlined in the limitation section.
+
+Let's start with the operating system version. Refer to the following table for Windows operating system support in Kubernetes. A single heterogeneous Kubernetes cluster can have both Windows and Linux worker nodes. Windows containers have to be scheduled on Windows nodes and Linux containers on Linux nodes.
+
+| Kubernetes version | Host OS version (Kubernetes Node) | | |
+| --- | --- | --- | --- |
+| | *Windows Server 1709* | *Windows Server 1803* | *Windows Server 1809/Windows Server 2019* |
+| *Kubernetes v1.14* | Not Supported | Not Supported| Supported for Windows Server containers Builds 17763.* with Docker EE-basic 18.09 |
+
+{{< note >}}
+We don't expect all Windows customers to update the operating system for their apps frequently. Upgrading your applications is what dictates and necessitates upgrading or introducing new nodes to the cluster. For the customers that chose to upgrade their operating system for containers running on Kubernetes, we will offer guidance and step-by-step instructions when we add support for a new operating system version. This guidance will include recommended upgrade procedures for upgrading user applications together with cluster nodes. Windows nodes adhere to Kubernetes [version-skew policy](/ja/docs/setup/release/version-skew-policy/) (node to control plane versioning) the same way as Linux nodes do today.
+{{< /note >}}
+{{< note >}}
+The Windows Server Host Operating System is subject to the [Windows Server ](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) licensing. The Windows Container images are subject to the [Supplemental License Terms for Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula).
+{{< /note >}}
+{{< note >}}
+Windows containers with process isolation have strict compatibility rules, [where the host OS version must match the container base image OS version](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility). Once we support Windows containers with Hyper-V isolation in Kubernetes, the limitation and compatibility rules will change.
+{{< /note >}}
+
+Key Kubernetes elements work the same way in Windows as they do in Linux. In this section, we talk about some of the key workload enablers and how they map to Windows.
+
+* [Pods](/ja/docs/concepts/workloads/pods/pod-overview/)
+
+    A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. The following Pod capabilities, properties and events are supported with Windows containers:
+
+  * Single or multiple containers per Pod with process isolation and volume sharing
+  * Pod status fields
+  * Readiness and Liveness probes
+  * postStart & preStop container lifecycle events
+  * ConfigMap, Secrets: as environment variables or volumes
+  * EmptyDir
+  * Named pipe host mounts
+  * Resource limits
+* [Controllers](/ja/docs/concepts/workloads/controllers/)
+
+    Kubernetes controllers handle the desired state of Pods. The following workload controllers are supported with Windows containers:
+
+  * ReplicaSet
+  * ReplicationController
+  * Deployments
+  * StatefulSets
+  * DaemonSet
+  * Job
+  * CronJob
+* [Services](/ja/docs/concepts/services-networking/service/)
+
+    A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them - sometimes called a micro-service. You can use services for cross-operating system connectivity. In Windows, services can utilize the following types, properties and capabilities:
+
+  * Service Environment variables
+  * NodePort
+  * ClusterIP
+  * LoadBalancer
+  * ExternalName
+  * Headless services
+
+Pods, Controllers and Services are critical elements to managing Windows workloads on Kubernetes. However, on their own they are not enough to enable the proper lifecycle management of Windows workloads in a dynamic cloud native environment. We added support for the following features:
+
+* Pod and container metrics
+* Horizontal Pod Autoscaler support
+* kubectl Exec
+* Resource Quotas
+* Scheduler preemption
+
+#### Container Runtime
+
+Docker EE-basic 18.09 is required on Windows Server 2019 / 1809 nodes for Kubernetes. This works with the dockershim code included in the kubelet. Additional runtimes such as CRI-ContainerD may be supported in later Kubernetes versions.
+
+#### Storage
+
+Kubernetes Volumes enable complex applications with data persistence and Pod volume sharing requirements to be deployed on Kubernetes. Kubernetes on Windows supports the following types of [volumes](/ja/docs/concepts/storage/volumes/):
+
+* FlexVolume out-of-tree plugin with [SMB and iSCSI](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows) support
+* [azureDisk](/ja/docs/concepts/storage/volumes/#azuredisk)
+* [azureFile](/ja/docs/concepts/storage/volumes/#azurefile)
+* [gcePersistentDisk](/ja/docs/concepts/storage/volumes/#gcepersistentdisk)
+
+#### Networking
+
+Networking for Windows containers is exposed through [CNI plugins](/ja/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Windows containers function similarly to virtual machines in regards to networking. Each container has a virtual network adapter (vNIC) which is connected to a Hyper-V virtual switch (vSwitch). The Host Networking Service (HNS) and the Host Compute Service (HCS) work together to create containers and attach container vNICs to networks. HCS is responsible for the management of containers whereas HNS is responsible for the management of networking resources such as:
+
+* Virtual networks (including creation of vSwitches)
+* Endpoints / vNICs
+* Namespaces
+* Policies (Packet encapsulations, Load-balancing rules, ACLs, NAT'ing rules, etc.)
+
+The following service spec types are supported:
+
+* NodePort
+* ClusterIP
+* LoadBalancer
+* ExternalName
+
+Windows supports five different networking drivers/modes: L2bridge, L2tunnel, Overlay, Transparent, and NAT. In a heterogeneous cluster with Windows and Linux worker nodes, you need to select a networking solution that is compatible on both Windows and Linux. The following out-of-tree plugins are supported on Windows, with recommendations on when to use each CNI:
+
+| Network Driver | Description | Container Packet Modifications | Network Plugins | Network Plugin Characteristics |
+| -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ |
+| L2bridge       | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. Inter-container traffic is bridged inside the container host. | MAC is rewritten to host MAC, IP remains the same. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel host-gateway uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires L2 adjacency between container hosts |
+| L2Tunnel | This is a special case of l2bridge, but only used on Azure. All packets are sent to the virtualization host where SDN policy is applied. | MAC rewritten, IP visible on the underlay network | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI allows integration of containers with Azure vNET, and allows them to leverage the set of capabilities that [Azure Virtual Network provides](https://azure.microsoft.com/en-us/services/virtual-network/). For example, securely connect to Azure services or use Azure NSGs. See [azure-cni for some examples](https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-cni-advanced-networking) |
+| Overlay (Overlay networking for Windows in Kubernetes is in *alpha* stage) | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header, inner packet remains the same. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags)  if you are restricted on IPs in your datacenter. This option may be used when the container hosts are not L2 adjacent but have L3 connectivity |
+| Transparent (special use case for [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)) | Requires an external vSwitch. Containers are attached to an external vSwitch which enables intra-pod communication via logical networks (logical switches and routers). | Packet is encapsulated either via [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) or [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) tunneling to reach pods which are not on the same host.  <br/> Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller. <br/> NAT is done for north-south communication. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Deploy via ansible](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib). Distributed ACLs can be applied via Kubernetes policies. IPAM support. Load-balancing can be achieved without kube-proxy. NATing is done without using iptables/netsh. |
+| NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness |
+
+As outlined above, the [Flannel](https://github.com/coreos/flannel) CNI [meta plugin](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel) is also supported on [Windows](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental) via the [VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) (**alpha support** ; delegates to win-overlay) and [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (stable support; delegates to win-bridge). This plugin supports delegating to one of the reference CNI plugins (win-overlay, win-bridge), to work in conjunction with Flannel daemon on Windows (Flanneld) for automatic node subnet lease assignment and HNS network creation. This plugin reads in its own configuration file (net-conf.json), and aggregates it with the environment variables from the FlannelD generated subnet.env file. It then delegates to one of the reference CNI plugins for network plumbing, and sends the correct configuration containing the node-assigned subnet to the IPAM plugin (e.g. host-local).
+
+For the node, pod, and service objects, the following network flows are supported for TCP/UDP traffic:
+
+* Pod -> Pod (IP)
+* Pod -> Pod (Name)
+* Pod -> Service (Cluster IP)
+* Pod -> Service (PQDN, but only if there are no ".")
+* Pod -> Service (FQDN)
+* Pod -> External (IP)
+* Pod -> External (DNS)
+* Node -> Pod
+* Pod -> Node
+
+The following IPAM options are supported on Windows:
+
+* [Host-local](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local)
+* HNS IPAM (Inbox platform IPAM, this is a fallback when no IPAM is set)
+* [Azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md) (for azure-cni only)
+
+### Limitations
+
+#### Control Plane
+
+Windows is only supported as a worker node in the Kubernetes architecture and component matrix. This means that a Kubernetes cluster must always include Linux master nodes, zero or more Linux worker nodes, and zero or more Windows worker nodes.
+
+#### Compute
+
+##### Resource management and process isolation
+
+ Linux cgroups are used as a pod boundary for resource controls in Linux. Containers are created within that boundary for network, process and file system isolation. The cgroups APIs can be used to gather cpu/io/memory stats. In contrast, Windows uses a Job object per container with a system namespace filter to contain all processes in a container and provide logical isolation from the host. There is no way to run a Windows container without the namespace filtering in place. This means that system privileges cannot be asserted in the context of the host, and thus privileged containers are not available on Windows. Containers cannot assume an identity from the host because the Security Account Manager (SAM) is separate.
+
+##### Operating System Restrictions
+
+Windows has strict compatibility rules, where the host OS version must match the container base image OS version. Only Windows containers with a container operating system of Windows Server 2019 are supported. Hyper-V isolation of containers, enabling some backward compatibility of Windows container image versions, is planned for a future release.
+
+##### Feature Restrictions
+
+* TerminationGracePeriod: not implemented
+* Single file mapping: to be implemented with CRI-ContainerD
+* Termination message: to be implemented with CRI-ContainerD
+* Privileged Containers: not currently supported in Windows containers
+* HugePages: not currently supported in Windows containers
+* The existing node problem detector is Linux-only and requires privileged containers. In general, we don't expect this to be used on Windows because privileged containers are not supported
+* Not all features of shared namespaces are supported (see API section for more details)
+
+##### Memory Reservations and Handling
+
+Windows does not have an out-of-memory process killer as Linux does. Windows always treats all user-mode memory allocations as virtual, and pagefiles are mandatory. The net effect is that Windows won't reach out of memory conditions the same way Linux does, and processes page to disk instead of being subject to out of memory (OOM) termination. If memory is over-provisioned and all physical memory is exhausted, then paging can slow down performance.
+
+Keeping memory usage within reasonable bounds is possible with a two-step process. First, use the kubelet parameters `--kubelet-reserve` and/or `--system-reserve` to account for memory usage on the node (outside of containers). This reduces [NodeAllocatable](/ja/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)). As you deploy workloads, use resource limits (must set only limits or limits must equal requests) on containers. This also subtracts from NodeAllocatable and prevents the scheduler from adding more pods once a node is full.
+
+A best practice to avoid over-provisioning is to configure the kubelet with a system reserved memory of at least 2GB to account for Windows, Docker, and Kubernetes processes.
+
+The behavior of the flags behave differently as described below:
+
+* `--kubelet-reserve`, `--system-reserve` , and `--eviction-hard` flags update Node Allocatable
+* Eviction by using `--enforce-node-allocable` is not implemented
+* Eviction by using `--eviction-hard` and `--eviction-soft` are not implemented
+* MemoryPressure Condition is not implemented
+* There are no OOM eviction actions taken by the kubelet
+* Kubelet running on the windows node does not have memory restrictions. `--kubelet-reserve` and `--system-reserve` do not set limits on kubelet or processes running on the host. This means kubelet or a process on the host could cause memory resource starvation outside the node-allocatable and scheduler
+
+#### Storage
+
+Windows has a layered filesystem driver to mount container layers and create a copy filesystem based on NTFS. All file paths in the container are resolved only within the context of that container.
+
+* Volume mounts can only target a directory in the container, and not an individual file
+* Volume mounts cannot project files or directories back to the host filesystem
+* Read-only filesystems are not supported because write access is always required for the Windows registry and SAM database. However, read-only volumes are supported
+* Volume user-masks and permissions are not available. Because the SAM is not shared between the host & container, there's no mapping between them. All permissions are resolved within the context of the container
+
+As a result, the following storage functionality is not supported on Windows nodes
+
+* Volume subpath mounts. Only the entire volume can be mounted in a Windows container.
+* Subpath volume mounting for Secrets
+* Host mount projection
+* DefaultMode (due to UID/GID dependency)
+* Read-only root filesystem. Mapped volumes still support readOnly
+* Block device mapping
+* Memory as the storage medium
+* CSI plugins which require privileged containers
+* File system features like uui/guid, per-user Linux filesystem permissions
+* NFS based storage/volume support
+* Expanding the mounted volume (resizefs)
+
+#### Networking
+
+Windows Container Networking differs in some important ways from Linux networking. The [Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) contains additional details and background.
+
+The Windows host networking networking service and virtual switch implement namespacing and can create virtual NICs as needed for a pod or container. However, many configurations such as DNS, routes, and metrics are stored in the Windows registry database rather than /etc/... files as they are on Linux. The Windows registry for the container is separate from that of the host, so concepts like mapping /etc/resolv.conf from the host into a container don't have the same effect they would on Linux. These must be configured using Windows APIs run in the context of that container. Therefore CNI implementations need to call the HNS instead of relying on file mappings to pass network details into the pod or container.
+
+The following networking functionality is not supported on Windows nodes
+
+* Host networking mode is not available for Windows pods
+* Local NodePort access from the node itself fails (works for other nodes or external clients)
+* Accessing service VIPs from nodes will be available with a future release of Windows Server
+* Overlay networking support in kube-proxy is an alpha release. In addition, it requires [KB4482887](https://support.microsoft.com/en-us/help/4482887/windows-10-update-kb4482887) to be installed on Windows Server 2019
+* Local Traffic Policy and DSR mode
+* Windows containers connected to l2bridge, l2tunnel, or overlay networks do not support communicating over the IPv6 stack. There is outstanding Windows platform work required to enable these network drivers to consume IPv6 addresses and subsequent Kubernetes work in kubelet, kube-proxy, and CNI plugins.
+* Outbound communication using the ICMP protocol via the win-overlay, win-bridge, and Azure-CNI plugin. Specifically, the Windows data plane ([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/)) doesn't support ICMP packet transpositions. This means:
+  * ICMP packets directed to destinations within the same network (e.g. pod to pod communication via ping) work as expected and without any limitations
+  * TCP/UDP packets work as expected and without any limitations
+  * ICMP packets directed to pass through a remote network (e.g. pod to external internet communication via ping) cannot be transposed and thus will not be routed back to their source
+  * Since TCP/UDP packets can still be transposed, one can substitute `ping <destination>` with `curl <destination>` to be able to debug connectivity to the outside world.
+
+These features were added in Kubernetes v1.15:
+
+* `kubectl port-forward`
+
+##### CNI Plugins
+
+* Windows reference network plugins win-bridge and win-overlay do not currently implement [CNI spec](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0 due to missing "CHECK" implementation.
+* The Flannel VXLAN CNI has the following limitations on Windows:
+
+1. Node-pod connectivity isn't possible by design. It's only possible for local pods with Flannel [PR 1096](https://github.com/coreos/flannel/pull/1096)
+2. We are restricted to using VNI 4096 and UDP port 4789. The VNI limitation is being worked on and will be overcome in a future release (open-source flannel changes). See the official [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) backend docs for more details on these parameters.
+
+##### DNS {#dns-limitations}
+
+* ClusterFirstWithHostNet is not supported for DNS. Windows treats all names with a '.' as a FQDN and skips PQDN resolution
+* On Linux, you have a DNS suffix list, which is used when trying to resolve PQDNs. On Windows, we only have 1 DNS suffix, which is the DNS suffix associated with that pod's namespace (mydns.svc.cluster.local for example). Windows can resolve FQDNs and services or names resolvable with just that suffix. For example, a pod spawned in the default namespace, will have the DNS suffix **default.svc.cluster.local**. On a Windows pod, you can resolve both **kubernetes.default.svc.cluster.local** and **kubernetes**, but not the in-betweens, like **kubernetes.default** or **kubernetes.default.svc**.
+
+##### Security
+
+Secrets are written in clear text on the node's volume (as compared to tmpfs/in-memory on linux). This means customers have to do two things
+
+1. Use file ACLs to secure the secrets file location
+2. Use volume-level encryption using [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)
+
+[RunAsUser ](/ja/docs/concepts/policy/pod-security-policy/#users-and-groups)is not currently supported on Windows. The workaround is to create local accounts before packaging the container. The RunAsUsername capability may be added in a future release.
+
+Linux specific pod security context privileges such as SELinux, AppArmor, Seccomp, Capabilities (POSIX Capabilities), and others are not supported.
+
+In addition, as mentioned already, privileged containers are not supported on Windows.
+
+#### API
+
+There are no differences in how most of the Kubernetes APIs work for Windows. The subtleties around what's different come down to differences in the OS and container runtime. In certain situations, some properties on workload APIs such as Pod or Container were designed with an assumption that they are implemented on Linux, failing to run on Windows.
+
+At a high level, these OS concepts are different:
+
+* Identity - Linux uses userID (UID) and groupID (GID) which are represented as integer types. User and group names are not canonical - they are just an alias in `/etc/groups` or `/etc/passwd` back to UID+GID. Windows uses a larger binary security identifier (SID) which is stored in the Windows Security Access Manager (SAM) database. This database is not shared between the host and containers, or between containers.
+* File permissions - Windows uses an access control list based on SIDs, rather than a bitmask of permissions and UID+GID
+* File paths - convention on Windows is to use `\` instead of `/`. The Go IO libraries typically accept both and just make it work, but when you're setting a path or command line that's interpreted inside a container, `\` may be needed.
+* Signals - Windows interactive apps handle termination differently, and can implement one or more of these:
+  * A UI thread handles well-defined messages including WM_CLOSE
+  * Console apps handle ctrl-c or ctrl-break using a Control Handler
+  * Services register a Service Control Handler function that can accept SERVICE_CONTROL_STOP control codes
+
+Exit Codes follow the same convention where 0 is success, nonzero is failure. The specific error codes may differ across Windows and Linux. However, exit codes passed from the Kubernetes components (kubelet, kube-proxy) are unchanged.
+
+##### V1.Container
+
+* V1.Container.ResourceRequirements.limits.cpu and V1.Container.ResourceRequirements.limits.memory - Windows doesn't use hard limits for CPU allocations. Instead, a share system is used. The existing fields based on millicores are scaled into relative shares that are followed by the Windows scheduler. [see: kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go), [see: resource controls in Microsoft docs](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/resource-controls)
+  * Huge pages are not implemented in the Windows container runtime, and are not available. They require [asserting a user privilege](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support) that's not configurable for containers.
+* V1.Container.ResourceRequirements.requests.cpu and V1.Container.ResourceRequirements.requests.memory - Requests are subtracted from node available resources, so they can be used to avoid overprovisioning a node. However, they cannot be used to guarantee resources in an overprovisioned node. They should be applied to all containers as a best practice if the operator wants to avoid overprovisioning entirely.
+* V1.Container.SecurityContext.allowPrivilegeEscalation - not possible on Windows, none of the capabilities are hooked up
+* V1.Container.SecurityContext.Capabilities - POSIX capabilities are not implemented on Windows
+* V1.Container.SecurityContext.privileged - Windows doesn't support privileged containers
+* V1.Container.SecurityContext.procMount - Windows doesn't have a /proc filesystem
+* V1.Container.SecurityContext.readOnlyRootFilesystem - not possible on Windows, write access is required for registry & system processes to run inside the container
+* V1.Container.SecurityContext.runAsGroup - not possible on Windows, no GID support
+* V1.Container.SecurityContext.runAsNonRoot - Windows does not have a root user. The closest equivalent is ContainerAdministrator which is an identity that doesn't exist on the node.
+* V1.Container.SecurityContext.runAsUser - not possible on Windows, no UID support as int.
+* V1.Container.SecurityContext.seLinuxOptions - not possible on Windows, no SELinux
+* V1.Container.terminationMessagePath - this has some limitations in that Windows doesn't support mapping single files. The default value is /dev/termination-log, which does work because it does not exist on Windows by default.
+
+##### V1.Pod
+
+* V1.Pod.hostIPC, v1.pod.hostpid - host namespace sharing is not possible on Windows
+* V1.Pod.hostNetwork - There is no Windows OS support to share the host network
+* V1.Pod.dnsPolicy - ClusterFirstWithHostNet - is not supported because Host Networking is not supported on Windows.
+* V1.Pod.podSecurityContext - see V1.PodSecurityContext below
+* V1.Pod.shareProcessNamespace - this is a beta feature, and depends on Linux namespaces which are not implemented on Windows. Windows cannot share process namespaces or the container's root filesystem. Only the network can be shared.
+* V1.Pod.terminationGracePeriodSeconds - this is not fully implemented in Docker on Windows, see: [reference](https://github.com/moby/moby/issues/25982). The behavior today is that the ENTRYPOINT process is sent CTRL_SHUTDOWN_EVENT, then Windows waits 5 seconds by default, and finally shuts down all processes using the normal Windows shutdown behavior. The 5 second default is actually in the Windows registry [inside the container](https://github.com/moby/moby/issues/25982#issuecomment-426441183), so it can be overridden when the container is built.
+* V1.Pod.volumeDevices - this is a beta feature, and is not implemented on Windows. Windows cannot attach raw block devices to pods.
+* V1.Pod.volumes - EmptyDir, Secret, ConfigMap, HostPath - all work and have tests in TestGrid
+  * V1.emptyDirVolumeSource - the Node default medium is disk on Windows. Memory is not supported, as Windows does not have a built-in RAM disk.
+* V1.VolumeMount.mountPropagation - mount propagation is not supported on Windows.
+
+##### V1.PodSecurityContext
+
+None of the PodSecurityContext fields work on Windows. They're listed here for reference.
+
+* V1.PodSecurityContext.SELinuxOptions - SELinux is not available on Windows
+* V1.PodSecurityContext.RunAsUser - provides a UID, not available on Windows
+* V1.PodSecurityContext.RunAsGroup - provides a GID, not available on Windows
+* V1.PodSecurityContext.RunAsNonRoot - Windows does not have a root user. The closest equivalent is ContainerAdministrator which is an identity that doesn't exist on the node.
+* V1.PodSecurityContext.SupplementalGroups - provides GID, not available on Windows
+* V1.PodSecurityContext.Sysctls - these are part of the Linux sysctl interface. There's no equivalent on Windows.
+
+## Getting Help and Troubleshooting {#troubleshooting}
+
+Your main source of help for troubleshooting your Kubernetes cluster should start with this [section](/ja/docs/tasks/debug-application-cluster/troubleshooting/). Some additional, Windows-specific troubleshooting help is included in this section. Logs are an important element of troubleshooting issues in Kubernetes. Make sure to include them any time you seek troubleshooting assistance from other contributors. Follow the instructions in the SIG-Windows [contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs).
+
+1. How do I know start.ps1 completed successfully?
+
+    You should see kubelet, kube-proxy, and (if you chose Flannel as your networking solution) flanneld host-agent processes running on your node, with running logs being displayed in separate PowerShell windows. In addition to this, your Windows node should be listed as "Ready" in your Kubernetes cluster.
+
+1. Can I configure the Kubernetes node processes to run in the background as services?
+
+    Kubelet and kube-proxy are already configured to run as native Windows Services, offering resiliency by re-starting the services automatically in the event of failure (for example a process crash). You have two options for configuring these node components as services.
+
+    1. As native Windows Services
+
+        Kubelet & kube-proxy can be run as native Windows Services using `sc.exe`.
+
+        ```powershell
+        # Create the services for kubelet and kube-proxy in two separate commands
+        sc.exe create <component_name> binPath= "<path_to_binary> --service <other_args>"
+
+        # Please note that if the arguments contain spaces, they must be escaped.
+        sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' <other_args>"
+
+        # Start the services
+        Start-Service kubelet
+        Start-Service kube-proxy
+
+        # Stop the service
+        Stop-Service kubelet (-Force)
+        Stop-Service kube-proxy (-Force)
+
+        # Query the service status
+        Get-Service kubelet
+        Get-Service kube-proxy
+        ```
+
+    1. Using nssm.exe
+
+        You can also always use alternative service managers like [nssm.exe](https://nssm.cc/) to run these processes (flanneld, kubelet & kube-proxy) in the background for you. You can use this [sample script](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1), leveraging nssm.exe to register kubelet, kube-proxy, and flanneld.exe to run as Windows services in the background.
+
+        ```powershell
+        register-svc.ps1 -NetworkMode <Network mode> -ManagementIP <Windows Node IP> -ClusterCIDR <Cluster subnet> -KubeDnsServiceIP <Kube-dns Service IP> -LogDir <Directory to place logs>
+
+        # NetworkMode      = The network mode l2bridge (flannel host-gw, also the default value) or overlay (flannel vxlan) chosen as a network solution
+        # ManagementIP     = The IP address assigned to the Windows node. You can use ipconfig to find this
+        # ClusterCIDR      = The cluster subnet range. (Default value 10.244.0.0/16)
+        # KubeDnsServiceIP = The Kubernetes DNS service IP (Default value 10.96.0.10)
+        # LogDir           = The directory where kubelet and kube-proxy logs are redirected into their respective output files (Default value C:\k)
+        ```
+
+        If the above referenced script is not suitable, you can manually configure nssm.exe using the following examples.
+        ```powershell
+        # Register flanneld.exe
+        nssm install flanneld C:\flannel\flanneld.exe
+        nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface=<ManagementIP> --ip-masq=1 --kube-subnet-mgr=1
+        nssm set flanneld AppEnvironmentExtra NODE_NAME=<hostname>
+        nssm set flanneld AppDirectory C:\flannel
+        nssm start flanneld
+
+        # Register kubelet.exe
+        # Microsoft releases the pause infrastructure container at mcr.microsoft.com/k8s/core/pause:1.2.0
+        # For more info search for "pause" in the "Guide for adding Windows Nodes in Kubernetes"
+        nssm install kubelet C:\k\kubelet.exe
+        nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=mcr.microsoft.com/k8s/core/pause:1.2.0 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false  --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
+        nssm set kubelet AppDirectory C:\k
+        nssm start kubelet
+
+        # Register kube-proxy.exe (l2bridge / host-gw)
+        nssm install kube-proxy C:\k\kube-proxy.exe
+        nssm set kube-proxy AppDirectory c:\k
+        nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=<hostname>--kubeconfig=c:\k\config --enable-dsr=false --log-dir=<log directory> --logtostderr=false
+        nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0
+        nssm set kube-proxy DependOnService kubelet
+        nssm start kube-proxy
+
+        # Register kube-proxy.exe (overlay / vxlan)
+        nssm install kube-proxy C:\k\kube-proxy.exe
+        nssm set kube-proxy AppDirectory c:\k
+        nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override=<hostname> --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip=<source-vip> --enable-dsr=false --log-dir=<log directory> --logtostderr=false
+        nssm set kube-proxy DependOnService kubelet
+        nssm start kube-proxy
+        ```
+
+
+        For initial troubleshooting, you can use the following flags in [nssm.exe](https://nssm.cc/) to redirect stdout and stderr to a output file:
+
+        ```powershell
+        nssm set <Service Name> AppStdout C:\k\mysvc.log
+        nssm set <Service Name> AppStderr C:\k\mysvc.log
+        ```
+
+        For additional details, see official [nssm usage](https://nssm.cc/usage) docs.
+
+1. My Windows Pods do not have network connectivity
+
+    If you are using virtual machines, ensure that MAC spoofing is enabled on all the VM network adapter(s).
+
+1. My Windows Pods cannot ping external resources
+
+    Windows Pods do not have outbound rules programmed for the ICMP protocol today. However, TCP/UDP is supported. When trying to demonstrate connectivity to resources outside of the cluster, please substitute `ping <IP>` with corresponding `curl <IP>` commands.
+
+    If you are still facing problems, most likely your network configuration in [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf) deserves some extra attention. You can always edit this static file. The configuration update will apply to any newly created Kubernetes resources.
+
+    One of the Kubernetes networking requirements (see [Kubernetes model](/ja/docs/concepts/cluster-administration/networking/)) is for cluster communication to occur without NAT internally. To honor this requirement, there is an [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20) for all the communication where we do not want outbound NAT to occur. However, this also means that you need to exclude the external IP you are trying to query from the ExceptionList. Only then will the traffic originating from your Windows pods be SNAT'ed correctly to receive a response from the outside world. In this regard, your ExceptionList in `cni.conf` should look as follows:
+
+    ```conf
+    "ExceptionList": [
+                    "10.244.0.0/16",  # Cluster subnet
+                    "10.96.0.0/12",   # Service subnet
+                    "10.127.130.0/24" # Management (host) subnet
+                ]
+    ```
+
+1. My Windows node cannot access NodePort service
+
+    Local NodePort access from the node itself fails. This is a known limitation. NodePort access works from other nodes or external clients.
+
+1. vNICs and HNS endpoints of containers are being deleted
+
+    This issue can be caused when the `hostname-override` parameter is not passed to [kube-proxy](/ja/docs/reference/command-line-tools-reference/kube-proxy/). To resolve it, users need to pass the hostname to kube-proxy as follows:
+
+    ```powershell
+    C:\k\kube-proxy.exe --hostname-override=$(hostname)
+    ```
+
+1. With flannel my nodes are having issues after rejoining a cluster
+
+    Whenever a previously deleted node is being re-joined to the cluster, flannelD tries to assign a new pod subnet to the node. Users should remove the old pod subnet configuration files in the following paths:
+
+    ```powershell
+    Remove-Item C:\k\SourceVip.json
+    Remove-Item C:\k\SourceVipRequest.json
+    ```
+
+1. After launching `start.ps1`, flanneld is stuck in "Waiting for the Network to be created"
+
+    There are numerous reports of this [issue which are being investigated](https://github.com/coreos/flannel/issues/1066); most likely it is a timing issue for when the management IP of the flannel network is set. A workaround is to simply relaunch start.ps1 or relaunch it manually as follows:
+
+    ```powershell
+    PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
+    PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1
+    ```
+
+1. My Windows Pods cannot launch because of missing `/run/flannel/subnet.env`
+
+    This indicates that Flannel didn't launch correctly. You can either try to restart flanneld.exe or you can copy the files over manually from `/run/flannel/subnet.env` on the Kubernetes master to` C:\run\flannel\subnet.env` on the Windows worker node and modify the `FLANNEL_SUBNET` row to a different number. For example, if node subnet 10.244.4.1/24 is desired:
+
+    ```env
+    FLANNEL_NETWORK=10.244.0.0/16
+    FLANNEL_SUBNET=10.244.4.1/24
+    FLANNEL_MTU=1500
+    FLANNEL_IPMASQ=true
+    ```
+
+1. My Windows node cannot access my services using the service IP
+
+    This is a known limitation of the current networking stack on Windows. Windows Pods are able to access the service IP however.
+
+1. No network adapter is found when starting kubelet
+
+    The Windows networking stack needs a virtual adapter for Kubernetes networking to work. If the following commands return no results (in an admin shell), virtual network creation — a necessary prerequisite for Kubelet to work — has failed:
+
+    ```powershell
+    Get-HnsNetwork | ? Name -ieq "cbr0"
+    Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
+    ```
+
+    Often it is worthwhile to modify the [InterfaceName](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/start.ps1#L6) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation.
+
+1. My Pods are stuck at "Container Creating" or restarting over and over
+
+    Check that your pause image is compatible with your OS version. The [instructions](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources) assume that both the OS and the containers are version 1803. If you have a later version of Windows, such as an Insider build, you need to adjust the images accordingly. Please refer to the Microsoft's [Docker repository](https://hub.docker.com/u/microsoft/) for images. Regardless, both the pause image Dockerfile and the sample service expect the image to be tagged as :latest.
+
+    Starting with Kubernetes v1.14, Microsoft releases the pause infrastructure container at `mcr.microsoft.com/k8s/core/pause:1.2.0`. For more information search for "pause" in the [Guide for adding Windows Nodes in Kubernetes](../user-guide-windows-nodes).
+
+1. DNS resolution is not properly working
+
+    Check the DNS limitations for Windows in this [section](#dns-limitations).
+
+1. `kubectl port-forward` fails with "unable to do port forwarding: wincat not found"
+
+    This was implemented in Kubernetes 1.15, and the pause infrastructure container `mcr.microsoft.com/k8s/core/pause:1.2.0`. Be sure to use these versions or newer ones.
+    If you would like to build your own pause infrastructure container, be sure to include [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)
+
+### Further investigation
+
+If these steps don't resolve your problem, you can get help running Windows containers on Windows nodes in Kubernetes through:
+
+* StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container) topic
+* Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io/)
+* Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows)
+
+## Reporting Issues and Feature Requests
+
+If you have what looks like a bug, or you would like to make a feature request, please use the [GitHub issue tracking system](https://github.com/kubernetes/kubernetes/issues). You can open issues on [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) and assign them to SIG-Windows. You should first search the list of issues in case it was reported previously and comment with your experience on the issue and add additional logs. SIG-Windows Slack is also a great avenue to get some initial support and troubleshooting ideas prior to creating a ticket.
+
+If filing a bug, please include detailed information about how to reproduce the problem, such as:
+
+* Kubernetes version: kubectl version
+* Environment details: Cloud provider, OS distro, networking choice and configuration, and Docker version
+* Detailed steps to reproduce the problem
+* [Relevant logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)
+* Tag the issue sig/windows by commenting on the issue with `/sig windows` to bring it to a SIG-Windows member's attention
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+We have a lot of features in our roadmap. An abbreviated high level list is included below, but we encourage you to view our [roadmap project](https://github.com/orgs/kubernetes/projects/8) and help us make Windows support better by [contributing](https://github.com/kubernetes/community/blob/master/sig-windows/).
+
+### CRI-ContainerD
+
+{{< glossary_tooltip term_id="containerd" >}} is another OCI-compliant runtime that recently graduated as a {{< glossary_tooltip text="CNCF" term_id="cncf" >}} project. It's currently tested on Linux, but 1.3 will bring support for Windows and Hyper-V. [[reference](https://blog.docker.com/2019/02/containerd-graduates-within-the-cncf/)]
+
+The CRI-ContainerD interface will be able to manage sandboxes based on Hyper-V. This provides a foundation where RuntimeClass could be implemented for new use cases including:
+
+* Hypervisor-based isolation between pods for additional security
+* Backwards compatibility allowing a node to run a newer Windows Server version without requiring containers to be rebuilt
+* Specific CPU/NUMA settings for a pod
+* Memory isolation and reservations
+
+### Hyper-V isolation
+
+The existing Hyper-V isolation support, an experimental feature as of v1.10, will be deprecated in the future in favor of the CRI-ContainerD and RuntimeClass features mentioned above. To use the current features and create a Hyper-V isolated container, the kubelet should be started with feature gates `HyperVContainer=true` and the Pod should include the annotation `experimental.windows.kubernetes.io/isolation-type=hyperv`. In the experiemental release, this feature is limited to 1 container per Pod.
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: iis
+spec:
+  selector:
+    matchLabels:
+      app: iis
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        app: iis
+      annotations:
+        experimental.windows.kubernetes.io/isolation-type: hyperv
+    spec:
+      containers:
+      - name: iis
+        image: microsoft/iis
+        ports:
+        - containerPort: 80
+```
+
+### Deployment with kubeadm and cluster API
+
+Kubeadm is becoming the de facto standard for users to deploy a Kubernetes cluster. Windows node support in kubeadm will come in a future release. We are also making investments in cluster API to ensure Windows nodes are properly provisioned.
+
+### A few other key features
+* Beta support for Group Managed Service Accounts
+* More CNIs
+* More Storage Plugins
+
+{{% /capture %}}
@@ -0,0 +1,140 @@
+---
+reviewers:
+- michmike
+- patricklang
+title: Guide for scheduling Windows containers in Kubernetes
+content_template: templates/concept
+weight: 75
+---
+
+{{% capture overview %}}
+
+Windows applications constitute a large portion of the services and applications that run in many organizations. This guide walks you through the steps to configure and deploy a Windows container in Kubernetes.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Objectives
+
+* Configure an example deployment to run Windows containers on the Windows node
+* (Optional) Configure an Active Directory Identity for your Pod using Group Managed Service Accounts (GMSA)
+
+## Before you begin
+
+* Create a Kubernetes cluster that includes a [master and a worker node running Windows Server](../user-guide-windows-nodes)
+* It is important to note that creating and deploying services and workloads on Kubernetes behaves in much the same way for Linux and Windows containers. [Kubectl commands](/docs/reference/kubectl/overview/) to interface with the cluster are identical. The example in the section below is provided simply to jumpstart your experience with Windows containers.
+
+## Getting Started: Deploying a Windows container
+
+To deploy a Windows container on Kubernetes, you must first create an example application. The example YAML file below creates a simple webserver application. Create a service spec named `win-webserver.yaml` with the contents below:
+
+```yaml
+    apiVersion: v1
+    kind: Service
+    metadata:
+      name: win-webserver
+      labels:
+        app: win-webserver
+    spec:
+      ports:
+      # the port that this service should serve on
+      - port: 80
+        targetPort: 80
+      selector:
+        app: win-webserver
+      type: NodePort
+    ---
+    apiVersion: extensions/v1beta1
+    kind: Deployment
+    metadata:
+      labels:
+        app: win-webserver
+      name: win-webserver
+    spec:
+      replicas: 2
+      template:
+        metadata:
+          labels:
+            app: win-webserver
+          name: win-webserver
+        spec:
+          containers:
+          - name: windowswebserver
+            image: mcr.microsoft.com/windows/servercore:ltsc2019
+            command:
+            - powershell.exe
+            - -command
+            - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ;  ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='<html><body><H1>Windows Container Web Server</H1>' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='<p>IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='</body></html>' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus)  } ; "
+          nodeSelector:
+            beta.kubernetes.io/os: windows
+```
+
+{{< note >}}
+Port mapping is also supported, but for simplicity in this example the container port 80 is exposed directly to the service.
+{{< /note >}}
+
+1. Check that all nodes are healthy:
+
+    ```bash
+    kubectl get nodes
+    ```
+
+1. Deploy the service and watch for pod updates:
+
+    ```bash
+    kubectl apply -f win-webserver.yaml
+    kubectl get pods -o wide -w
+    ```
+
+    When the service is deployed correctly both Pods are marked as Ready. To exit the watch command, press Ctrl+C.
+
+1. Check that the deployment succeeded. To verify:
+
+    * Two containers per pod on the Windows node, use `docker ps`
+    * Two pods listed from the Linux master, use `kubectl get pods`
+    * Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux master to check for a web server response
+    * Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node) using docker exec or kubectl exec
+    * Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`) from the Linux master and from individual pods
+    * Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/docs/concepts/services-networking/dns-pod-service/#services)
+    * Inbound connectivity, `curl` the NodePort from the Linux master or machines outside of the cluster
+    * Outbound connectivity, `curl` external IPs from inside the pod using kubectl exec
+
+{{< note >}}
+Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. Only Windows pods are able to access service IPs.
+{{< /note >}}
+
+## Managing Workload Identity with Group Managed Service Accounts
+
+Starting with Kubernetes v1.14, Windows container workloads can be configured to use Group Managed Service Accounts (GMSA). Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA. Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/).
+
+## Taints and Tolerations
+
+Users today need to use some combination of taints and node selectors in order to keep Linux and Windows workloads on their respective OS-specific nodes. This likely imposes a burden only on Windows users. The recommended approach is outlined below, with one of its main goals being that this approach should not break compatibility for existing Linux workloads.
+
+### Ensuring OS-specific workloads land on the appropriate container host
+
+Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations. All Kubernetes nodes today have the following default labels:
+
+* beta.kubernetes.io/os = [windows|linux]
+* beta.kubernetes.io/arch = [amd64|arm64|...]
+
+If a Pod specification does not specify a nodeSelector like `"beta.kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.
+
+However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. In those situations, you may be hesitant to make the configuration change to add nodeSelectors. The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only.
+
+For example:  `--register-with-taints='os=Win1809:NoSchedule'`
+
+By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector to choose Windows, and the appropriate matching toleration.
+
+```yaml
+nodeSelector:
+    "beta.kubernetes.io/os": windows
+tolerations:
+    - key: "os"
+      operator: "Equal"
+      value: "Win1809"
+      effect: "NoSchedule"
+```
+
+{{% /capture %}}
@@ -0,0 +1,273 @@
+---
+reviewers:
+- michmike
+- patricklang
+title: Guide for adding Windows Nodes in Kubernetes
+content_template: templates/concept
+weight: 70
+---
+
+{{% capture overview %}}
+
+The Kubernetes platform can now be used to run both Linux and Windows containers. One or more Windows nodes can be registered to a cluster. This guide shows how to:
+
+* Register a Windows node to the cluster
+* Configure networking so pods on Linux and Windows can communicate
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Before you begin
+
+* Obtain a [Windows Server license](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) in order to configure the Windows node that hosts Windows containers. You can use your organization's licenses for the cluster, or acquire one from Microsoft, a reseller, or via the major cloud providers such as GCP, AWS, and Azure by provisioning a virtual machine running Windows Server through their marketplaces. A [time-limited trial](https://www.microsoft.com/en-us/cloud-platform/windows-server-trial) is also available.
+
+* Build a Linux-based Kubernetes cluster in which you have access to the control plane (some examples include [Creating a single control-plane cluster with kubeadm](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), [AKS Engine](/ja/docs/setup/production-environment/turnkey/azure/), [GCE](/ja/docs/setup/production-environment/turnkey/gce/), [AWS](/ja/docs/setup/production-environment/turnkey/aws/).
+
+## Getting Started: Adding a Windows Node to Your Cluster
+
+### Plan IP Addressing
+
+Kubernetes cluster management requires careful planning of your IP addresses so that you do not inadvertently cause network collision. This guide assumes that you are familiar with the [Kubernetes networking concepts](/docs/concepts/cluster-administration/networking/).
+
+In order to deploy your cluster you need the following address spaces:
+
+| Subnet / address range | Description | Default value |
+| --- | --- | --- |
+| Service Subnet | A non-routable, purely virtual subnet that is used by pods to uniformly access services without caring about the network topology. It is translated to/from routable address space by `kube-proxy` running on the nodes. | 10.96.0.0/12 |
+| Cluster Subnet | This is a global subnet that is used by all pods in the cluster. Each node is assigned a smaller /24 subnet from this for their pods to use. It must be large enough to accommodate all pods used in your cluster. To calculate *minimumsubnet* size: `(number of nodes) + (number of nodes * maximum pods per node that you configure)`. Example: for a 5 node cluster for 100 pods per node: `(5) + (5 * 100) = 505.` | 10.244.0.0/16 |
+| Kubernetes DNS Service IP | IP address of `kube-dns` service that is used for DNS resolution & cluster service discovery. | 10.96.0.10 |
+
+Review the networking options supported in 'Intro to Windows containers in Kubernetes: Supported Functionality: Networking' to determine how you need to allocate IP addresses for your cluster.
+
+### Components that run on Windows
+
+While the Kubernetes control plane runs on your Linux node(s), the following components are configured and run on your Windows node(s).
+
+1. kubelet
+2. kube-proxy
+3. kubectl (optional)
+4. Container runtime
+
+Get the latest binaries from [https://github.com/kubernetes/kubernetes/releases](https://github.com/kubernetes/kubernetes/releases), starting with v1.14 or later. The Windows-amd64 binaries for kubeadm, kubectl, kubelet, and kube-proxy can be found under the CHANGELOG link.
+
+### Networking Configuration
+
+Once you have a Linux-based Kubernetes master node you are ready to choose a networking solution. This guide illustrates using Flannel in VXLAN mode for simplicity.
+
+#### Configuring Flannel in VXLAN mode on the Linux controller
+
+1. Prepare Kubernetes master for Flannel
+
+    Some minor preparation is recommended on the Kubernetes master in our cluster. It is recommended to enable bridged IPv4 traffic to iptables chains when using Flannel. This can be done using the following command:
+
+    ```bash
+    sudo sysctl net.bridge.bridge-nf-call-iptables=1
+    ```
+
+1. Download & configure Flannel
+
+    Download the most recent Flannel manifest:
+
+    ```bash
+    wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
+    ```
+
+    There are two sections you should modify to enable the vxlan networking backend:
+
+    After applying the steps below, the `net-conf.json` section of `kube-flannel.yml` should look as follows:
+
+    ```json
+    net-conf.json: |
+        {
+          "Network": "10.244.0.0/16",
+          "Backend": {
+            "Type": "vxlan",
+            "VNI" : 4096,
+            "Port": 4789
+          }
+        }
+    ```
+
+    {{< note >}}The VNI must be set to 4096 and port 4789 for Flannel on Linux to interoperate with Flannel on Windows. Support for other VNIs is coming soon. See the [VXLAN documentation](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)
+    for an explanation of these fields.{{< /note >}}
+
+1. In the `net-conf.json` section of your `kube-flannel.yml`, double-check:
+    1. The cluster subnet (e.g. "10.244.0.0/16") is set as per your IP plan.
+        * VNI 4096 is set in the backend
+        * Port 4789 is set in the backend
+    2. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`.
+
+
+    Your `cni-conf.json` should look as follows:
+
+    ```json
+    cni-conf.json: |
+        {
+          "name": "vxlan0",
+          "plugins": [
+            {
+              "type": "flannel",
+              "delegate": {
+                "hairpinMode": true,
+                "isDefaultGateway": true
+              }
+            },
+            {
+              "type": "portmap",
+              "capabilities": {
+                "portMappings": true
+              }
+            }
+          ]
+        }
+    ```
+
+1. Apply the Flannel yaml and Validate
+
+    Let's apply the Flannel configuration:
+
+    ```bash
+    kubectl apply -f kube-flannel.yml
+    ```
+
+    Next, since the Flannel pods are Linux-based, apply a NodeSelector patch, which can be found [here](https://github.com/Microsoft/SDN/blob/1d5c055bb195fecba07ad094d2d7c18c188f9d2d/Kubernetes/flannel/l2bridge/manifests/node-selector-patch.yml), to the Flannel DaemonSet pod:
+
+    ```bash
+    kubectl patch ds/kube-flannel-ds-amd64 --patch "$(cat node-selector-patch.yml)" -n=kube-system
+    ```
+
+    After a few minutes, you should see all the pods as running if the Flannel pod network was deployed.
+
+    ```bash
+    kubectl get pods --all-namespaces
+    ```
+
+    ![alt_text](../flannel-master-kubeclt-get-pods.png "flannel master kubectl get pods screen capture")
+
+    Verify that the Flannel DaemonSet has the NodeSelector applied.
+
+    ```bash
+    kubectl get ds -n kube-system
+    ```
+
+    ![alt_text](../flannel-master-kubectl-get-ds.png "flannel master kubectl get ds screen capture")
+
+#### Join Windows Worker
+
+In this section we'll cover configuring a Windows node from scratch to join a cluster on-prem. If your cluster is on a cloud you'll likely want to follow the cloud specific guides in the next section.
+
+#### Preparing a Windows Node
+{{< note >}}
+All code snippets in Windows sections are to be run in a PowerShell environment with elevated permissions (Admin).
+{{< /note >}}
+
+1. Install Docker (requires a system reboot)
+
+    Kubernetes uses [Docker](https://www.docker.com/) as its container engine, so we need to install it. You can follow the [official Docs instructions](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon#install-docker), the [Docker instructions](https://store.docker.com/editions/enterprise/docker-ee-server-windows), or try the following *recommended* steps:
+
+    ```PowerShell
+    Enable-WindowsOptionalFeature -FeatureName Containers
+    Restart-Computer -Force
+    Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
+    Install-Package -Name Docker -ProviderName DockerMsftProvider
+    ```
+
+    If you are behind a proxy, the following PowerShell environment variables must be defined:
+
+    ```PowerShell
+    [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
+    [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
+    ```
+
+    If after reboot you see the following error, you need to restart the docker service manually
+
+    ![alt_text](../windows-docker-error.png "windows docker error screen capture")
+
+    ```PowerShell
+    Start-Service docker
+    ```
+
+    {{< note >}}
+    The "pause" (infrastructure) image is hosted on Microsoft Container Registry (MCR). You can access it using "docker pull mcr.microsoft.com/k8s/core/pause:1.2.0". The DOCKERFILE is available at https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat.
+    {{< /note >}}
+
+1. Prepare a Windows directory for Kubernetes
+
+    Create a "Kubernetes for Windows" directory to store Kubernetes binaries as well as any deployment scripts and config files.
+
+    ```PowerShell
+    mkdir c:\k
+    ```
+
+1. Copy Kubernetes certificate
+
+    Copy the Kubernetes certificate file `$HOME/.kube/config` [from the Linux controller](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/creating-a-linux-master#collect-cluster-information) to this new `C:\k` directory on your Windows node.
+
+    Tip: You can use tools such as [xcopy](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy), [WinSCP](https://winscp.net/eng/download.php), or this [PowerShell wrapper for WinSCP](https://www.powershellgallery.com/packages/WinSCP/5.13.2.0) to transfer the config file between nodes.
+
+1. Download Kubernetes binaries
+
+    To be able to run Kubernetes, you first need to download the `kubelet` and `kube-proxy` binaries. You download these from the Node Binaries links in the CHANGELOG.md file of the [latest releases](https://github.com/kubernetes/kubernetes/releases/). For example 'kubernetes-node-windows-amd64.tar.gz'. You may also optionally download `kubectl` to run on Windows which you can find under Client Binaries.
+
+    Use the [Expand-Archive](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.archive/expand-archive?view=powershell-6) PowerShell command to extract the archive and place the binaries into `C:\k`.
+
+#### Join the Windows node to the Flannel cluster
+
+The Flannel overlay deployment scripts and documentation are available in [this repository](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/overlay). The following steps are a simple walkthrough of the more comprehensive instructions available there.
+
+Download the [Flannel start.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1) script, the contents of which should be extracted to `C:\k`:
+
+```PowerShell
+cd c:\k
+[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
+wget https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/flannel/start.ps1 -o c:\k\start.ps1
+```
+
+{{< note >}}
+[start.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1) references [install.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/install.ps1), which downloads additional files such as the `flanneld` executable and the [Dockerfile for infrastructure pod](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/Dockerfile) and install those for you. For overlay networking mode, the [firewall](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/helper.psm1#L111) is opened for local UDP port 4789. There may be multiple powershell windows being opened/closed as well as a few seconds of network outage while the new external vSwitch for the pod network is being created the first time. Run the script using the arguments as specified below:
+{{< /note >}}
+
+```PowerShell
+.\start.ps1 -ManagementIP <Windows Node IP> -NetworkMode overlay  -ClusterCIDR <Cluster CIDR> -ServiceCIDR <Service CIDR> -KubeDnsServiceIP <Kube-dns Service IP> -LogDir <Log directory>
+```
+
+| Parameter | Default Value | Notes |
+| --- | --- | --- |
+| -ManagementIP | N/A (required) | The IP address assigned to the Windows node. You can use `ipconfig` to find this. |
+| -NetworkMode | l2bridge | We're using `overlay` here |
+| -ClusterCIDR | 10.244.0.0/16 | Refer to your cluster IP plan |
+| -ServiceCIDR | 10.96.0.0/12 | Refer to your cluster IP plan |
+| -KubeDnsServiceIP | 10.96.0.10 | |
+| -InterfaceName | Ethernet | The name of the network interface of the Windows host. You can use <code>ipconfig</code> to find this. |
+| -LogDir | C:\k | The directory where kubelet and kube-proxy logs are redirected into their respective output files. |
+
+Now you can view the Windows nodes in your cluster by running the following:
+
+```bash
+kubectl get nodes
+```
+
+{{< note >}}
+You may want to configure your Windows node components like kubelet and kube-proxy to run as services. View the services and background processes section under [troubleshooting](#troubleshooting) for additional instructions. Once you are running the node components as services, collecting logs becomes an important part of troubleshooting. View the [gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) section of the contributing guide for further instructions.
+{{< /note >}}
+
+### Public Cloud Providers
+
+#### Azure
+
+AKS-Engine can deploy a complete, customizable Kubernetes cluster with both Linux & Windows nodes. There is a step-by-step walkthrough available in the [docs on GitHub](https://github.com/Azure/aks-engine/blob/master/docs/topics/windows.md).
+
+#### GCP
+
+Users can easily deploy a complete Kubernetes cluster on GCE following this step-by-step walkthrough on [GitHub](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/windows/README-GCE-Windows-kube-up.md)
+
+#### Deployment with kubeadm and cluster API
+
+Kubeadm is becoming the de facto standard for users to deploy a Kubernetes cluster. Windows node support in kubeadm will come in a future release. We are also making investments in cluster API to ensure Windows nodes are properly provisioned.
+
+### Next Steps
+
+Now that you've configured a Windows worker in your cluster to run Windows containers you may want to add one or more Linux nodes as well to run Linux containers. You are now ready to schedule Windows containers on your cluster.
+
+{{% /capture %}}