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: "Kubernetes アーキテクチャー"
+weight: 30
+---
@@ -0,0 +1,238 @@
+---
+title: クラウドコントローラーマネージャーとそのコンセプト
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+クラウドコントローラマネージャー(CCM)のコンセプト(バイナリと混同しないでください)は、もともとクラウドベンダー固有のソースコードと、Kubernetesのコアソースコードを独立して進化させることが出来るように作られました。クラウドコントローラーマネージャーは、Kubernetesコントローラーマネージャー、APIサーバー、そしてスケジューラーのような他のマスターコンポーネントと並行して動きます。またKubernetesのアドオンとしても動かすことができ、その場合はKubernetes上で動きます。
+
+クラウドコントローラーマネージャーの設計は「プラグイン機構」をベースにしています。そうすることで、新しいクラウドプロバイダーがプラグインを使ってKubernetesと簡単に統合出来るようになります。新しいクラウドプロバイダーに向けてKubernetesのオンボーディングを行ったり、古いモデルを利用しているクラウドプロバイダーに、新しいCCMモデルに移行させるような計画があります。
+
+このドキュメントでは、クラウドコントローラーマネージャーの背景にあるコンセプトと、それに関連する機能の詳細について話します。
+
+これが、クラウドコントローラーマネージャーを除いた、Kubernetesクラスターのアーキテクチャ図です。
+
+![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png)
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## 設計
+
+上で示した図で分かるように、Kubernetesとクラウドプロバイダーはいくつかの異なるコンポーネントを通じて連携します:
+
+* Kubelet
+* Kubernetesコントローラーマネージャー
+* Kubernetes APIサーバー
+
+CCMは、前述した3つのコンポーネントのクラウド依存のロジックを統合し、クラウドとの単一の連携ポイントとなります。CCMを利用した新しいアーキテクチャは下記のようになります:
+
+![CCM Kube Arch](/images/docs/post-ccm-arch.png)
+
+## CCMのコンポーネント
+
+CCMは、Kubernetesコントローラーマネージャー(KCM)からいくつかの機能群を切り離し、別のプロセスとして動かします。具体的には、KCMに含まれるクラウド依存のコントローラーを分離します。KCMは、下記に示すクラウド依存のコントローラーループを持っています:
+
+ * ノードコントローラー
+ * ボリュームコントローラー
+ * ルートコントローラー
+ * サービスコントローラー
+
+バージョン1.9では、CCMは前述のリスト内の下記コントローラーを動かします:
+
+* ノードコントローラー
+* ルートコントローラー
+* サービスコントローラー
+
+{{< note >}}
+ボリュームコントローラーは、意図的にCCMの一部になっていません。複雑さと、ベンダー固有のボリュームロジックを抽象化するのに費やした労力を考え、CCMの一部に移行しないことが決定されました。
+{{< /note >}}
+
+CCMを使ったボリュームをサポートする元の計画は、プラガブルなボリュームをサポートするため、Flexボリュームを使うことでした。しかし、競合しているCSIとして知られている機能が、Flexを置き換える予定です。
+
+これらのダイナミクスを考慮し、我々はCSIが利用できるようになるまで、間を取った暫定措置を取ることにしました。
+
+## CCMの機能群
+
+CCMは、クラウドに依存しているKubernetesのコンポーネントから機能を継承しています。このセクションはそれらのコンポーネントをベースに構造化されています。
+
+### 1. Kubernetesコントローラーマネージャー
+
+CCMの大半の機能は、KCMから派生しています。前セクションで説明したとおり、CCMは下記のコントロールループを動かします:
+
+* ノードコントローラー
+* ルートコントローラー
+* サービスコントローラー
+
+#### ノードコントローラー
+
+ノードコントローラーは、クラウドプロバイダーからクラスター内で稼働しているノードの情報を取得し、初期化する責務を持ちます。ノードコントローラーは下記に示す機能を実行します:
+
+1. ノードをクラウド特有のゾーン/リージョンラベルで初期化する
+2. ノードをクラウド特有のインスタンス詳細情報(例、タイプ、サイズ)で初期化する
+3. ノードのネットワークアドレスとホスト名を取得する
+4. ノードが応答しなくなった場合、ノードがクラウドから削除されているかを確認する。クラウドからノードが削除されていた場合、KubernetesからNodeオブジェクトを削除する
+
+#### ルートコントローラー
+
+ルートコントローラーは、クラスタ内の異なるノード上で稼働しているコンテナが相互に通信出来るように、クラウド内のルートを適切に設定する責務を持ちます。ルートコントローラーはGoogle Compute Engineのクラスターのみに該当します。
+
+#### サービスコントローラー
+
+サービスコントローラーは、サービスの作成、更新、そして削除イベントの待ち受けに責務を持ちます。Kubernetes内のサービスの現在の状態を、クラウド上のロードバランサー(ELB、Google LB、またOracle Cloud Infrastructure LBなど)に反映するための設定を行います。更に、クラウドロードバランサーのバックエンドが最新の状態になっていることを保証します。
+
+### 2. Kubelet
+
+ノードコントローラーは、kubeletのクラウドに依存した機能も含んでいます。CCMの登場以前、kubeletはIPアドレス、リージョン/ゾーンラベル、そしてインスタンスタイプ情報のような、クラウド特有の情報を元にノードを初期化する責務を持っていました。CCMが登場したことで、この初期化操作がkubeletからCCMに移行されました。
+
+この新しいモデルでは、kubeletはクラウド特有の情報無しでノードを初期化します。しかし、新しく作成されたノードにtaintを付けて、CCMがクラウド特有の情報でノードを初期化するまで、コンテナがスケジュールされないようにします。その後、taintを削除します。
+
+## プラグイン機構
+
+クラウドコントローラーマネージャーは、Goのインターフェースを利用してクラウドの実装をプラグイン化出来るようにしています。具体的には、[こちら](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)で定義されているクラウドプロバイダーインターフェースを利用しています。
+
+上で強調した4つの共有コントローラーの実装、そしていくつかの共有クラウドプロバイダーインターフェースと一部の連携機能は、Kubernetesのコアにとどまります。クラウドプロバイダー特有の実装はコア機能外で構築され、コア機能内で定義されたインターフェースを実装します。
+
+プラグインを開発するためのさらなる情報は、[クラウドコントローラーマネージャーを開発する](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を参照してください。
+
+## 認可
+
+このセクションでは、CCMが操作を行うために様々なAPIオブジェクトに必要な権限を分類します。
+
+### ノードコントローラー
+
+ノードコントローラーはNodeオブジェクトのみに対して働きます。Nodeオブジェクトに対して、get、list、create、update、patch、watch、そしてdeleteの全権限が必要です。
+
+v1/Node:
+
+- Get
+- List
+- Create
+- Update
+- Patch
+- Watch
+- Delete
+
+### ルートコントローラー
+
+ルートコントローラーは、Nodeオブジェクトの作成を待ち受け、ルートを適切に設定します。Nodeオブジェクトについて、get権限が必要です。
+
+v1/Node:
+
+- Get
+
+### サービスコントローラー
+
+サービスコントローラーは、Serviceオブジェクトの作成、更新、削除イベントを待ち受け、その後、サービスのエンドポイントを適切に設定します。
+
+サービスにアクセスするため、list、watchの権限が必要です。サービスを更新するため、patch、updateの権限が必要です。
+
+サービスのエンドポイントを設定するため、create、list、get、watchそしてupdateの権限が必要です。
+
+v1/Service:
+
+- List
+- Get
+- Watch
+- Patch
+- Update
+
+### その他
+
+CCMコア機能の実装は、イベントのcreate権限と、セキュアな処理を保証するため、ServiceAccountのcreate権限が必要です。
+
+v1/Event:
+
+- Create
+- Patch
+- Update
+
+v1/ServiceAccount:
+
+- Create
+
+CCMのRBAC ClusterRoleはこのようになります:
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: cloud-controller-manager
+rules:
+- apiGroups:
+  - ""
+  resources:
+  - events
+  verbs:
+  - create
+  - patch
+  - update
+- apiGroups:
+  - ""
+  resources:
+  - nodes
+  verbs:
+  - '*'
+- apiGroups:
+  - ""
+  resources:
+  - nodes/status
+  verbs:
+  - patch
+- apiGroups:
+  - ""
+  resources:
+  - services
+  verbs:
+  - list
+  - patch
+  - update
+  - watch
+- apiGroups:
+  - ""
+  resources:
+  - serviceaccounts
+  verbs:
+  - create
+- apiGroups:
+  - ""
+  resources:
+  - persistentvolumes
+  verbs:
+  - get
+  - list
+  - update
+  - watch
+- apiGroups:
+  - ""
+  resources:
+  - endpoints
+  verbs:
+  - create
+  - get
+  - list
+  - watch
+  - update
+```
+
+## ベンダー実装
+
+下記のクラウドプロバイダーがCCMを実装しています:
+
+* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
+* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
+* [Azure](https://github.com/kubernetes/cloud-provider-azure)
+* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
+* [AWS](https://github.com/kubernetes/cloud-provider-aws)
+* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
+* [Linode](https://github.com/linode/linode-cloud-controller-manager)
+
+## クラスター管理
+
+CCMを設定、動かすための完全な手順は[こちら](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)で提供されています。
+
+{{% /capture %}}
@@ -0,0 +1,72 @@
+---
+title: マスターとノード間の通信
+content_template: templates/concept
+weight: 20
+---
+
+{{% capture overview %}}
+
+本ドキュメントでは、KubernetesにおけるMaster(実態はAPIサーバー)及びクラスター間のコミュニケーション経路についてまとめます。
+この文書の目的は、信頼できないネットワーク上（またはクラウドプロバイダ上の完全にパブリックなIP上）でクラスタを実行できるように、ユーザーがインストールをカスタマイズしてネットワーク構成を強化できるようにすることです。
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## クラスターからマスターへの通信
+
+クラスターからマスターへのすべての通信経路は、APIサーバーで終端します（他のマスターコンポーネントはどれもリモートサービスを公開するように設計されていません）。
+一般的には、1つ以上の形式のクライアント[認証](/docs/reference/access-authn-authz/authentication/)が有効になっている状態で、APIサーバーはセキュアなHTTPSポート（443）でリモート接続をlistenするように構成されています。
+特に[匿名のリクエスト](/docs/reference/access-authn-authz/authentication/#anonymous-requests)または[サービスアカウントトークン](/docs/reference/access-authn-authz/authentication/#service-account-tokens)が許可されている場合は、1つまたは複数の[認証](/docs/reference/access-authn-authz/authorization/)を有効にする必要があります。
+
+ノードには、有効なクライアント認証情報を使って安全にAPIサーバーに接続できるように、クラスターのパブリックなルート証明書をプロビジョニングする必要があります。
+たとえば、GKEのデフォルト設定では、kubeletに提供されるクライアント認証情報はクライアント証明書の形式です。
+kubeletのクライアント証明書を自動プロビジョニングする方法については、[kubelet TLSブートストラッピング](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)を参照してください。
+
+APIサーバーに接続したいPodは、サービスアカウントを利用することで接続を安全にすることができます。そうすることで、Podが作成されたときにKubernetesがパブリックなルート証明書と有効なBearer TokenをPodに自動的に挿入します。
+
+`kubernetes`サービスには（すべてのネームスペースで）、APIサーバー上のHTTPSエンドポイントに（kube-proxy経由で）リダイレクトされる仮想IPアドレスが設定されています。
+
+マスターコンポーネントは、セキュアなポートを介してクラスターAPIサーバーとも通信します。
+
+その結果、クラスター（ノードとそのノードで実行されているPod）からマスターへの接続はデフォルトで保護され、信頼できないネットワークやパブリックネットワークを介して実行できます。
+
+## マスターからクラスターへの通信
+
+マスター（APIサーバー）からクラスターへの通信には、2つの主要な通信経路があります。
+1つ目は、APIサーバーからクラスター内の各ノードで実行されるkubeletプロセスへの通信です。
+2つ目は、APIサーバーのプロキシ機能を介した、APIサーバーから任意のノード、Pod、またはサービスへのアクセスです。
+
+### APIサーバーからkubeletへの通信
+
+APIサーバーからkubeletへの接続は以下の目的で使用されます:
+
+  * Podのログを取得する
+  * 実行中のPodに（kubectlを通して）接続する
+  * kubeletのポート転送機能を提供する
+
+これらの接続は、kubeletのHTTPSエンドポイントで終了します。
+デフォルトでは、APIサーバーはkubeletが提供する証明書を検証しないため、接続は中間者攻撃を受けやすく、**安全でない**信頼できないネットワークやパブリックなネットワークを介して実行されることになります。
+
+この接続を検証するには、`--kubelet-certificate-authority`フラグを使用して、kubeletが提供する証明書を確認するために使用するルート証明書バンドルをAPIサーバーに提供します。
+
+それができない場合は、信頼できないネットワークやパブリックなネットワークを介した接続を回避するために、必要に応じてAPIサーバーとkubeletの間でSSHトンネリングを使用してください。
+
+最後に、kubeletのAPIを保護するために[kubeletの認証認可](/docs/admin/kubelet-authentication-authorization/)を有効にする必要があります。
+
+### APIサーバーからノード、Pod、サービスへの通信
+
+APIサーバーからノード、Pod、またはサービスへの接続はデフォルトで平文のHTTP接続になるため、認証も暗号化もされません。
+API URL内のノード、Pod、またはサービス名に`https:`を付けることで安全なHTTPS接続で実行できますが、HTTPSエンドポイントから提供される証明書を検証したりクライアントの資格情報を提供したりすることはありませんし、暗号化されているという完全性を保証するものでもありません。
+これらの接続を信頼できないネットワークや公衆ネットワークを介して実行するのは、現時点において安全ではありません。
+
+### SSHトンネル
+
+Kubernetesはマスターからクラスターへの通信経路を保護するためにSSHトンネルをサポートしています。
+この設定では、APIサーバーはクラスター内の各ノード（ポート22でlistenしているsshサーバーに接続）へのSSHトンネルを開始し、トンネルを介してkubelet、ノード、Pod、またはサービス宛てのすべてのトラフィックを渡します。
+このトンネルにより、ノードが実行されているネットワークの外部にトラフィックが公開されないようにします。
+
+SSHトンネルは現在非推奨なので、自分がしていることが分からない限り、使用しないでください。この通信チャネルに代わるものが設計されています。
+
+{{% /capture %}}
@@ -0,0 +1,222 @@
+---
+title: ノード
+content_template: templates/concept
+weight: 10
+---
+
+{{% capture overview %}}
+
+ノードは、以前には `ミニオン` としても知られていた、Kubernetesにおけるワーカーマシンです。1つのノードはクラスターの性質にもよりますが、1つのVMまたは物理的なマシンです。各ノードには[Pod](/docs/concepts/workloads/pods/pod/)を動かすために必要なサービスが含まれており、マスターコンポーネントによって管理されています。ノード上のサービスには[コンテナランタイム](/docs/concepts/overview/components/#node-components)、kubelet、kube-proxyが含まれています。詳細については、設計ドキュメントの[Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)セクションをご覧ください。
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## ノードのステータス
+
+ノードのステータスには以下のような情報が含まれます:
+
+* [Addresses](#addresses)
+* [Conditions](#condition)
+* [CapacityとAllocatable](#capacity)
+* [Info](#info)
+
+ノードのステータスや、ノードに関するその他の詳細は、下記のコマンドを使うことで表示できます:
+```shell
+kubectl describe node <ノード名>
+```
+各セクションについては、下記で説明します。
+
+### Addresses
+
+これらのフィールドの使い方は、お使いのクラウドプロバイダーやベアメタルの設定内容によって異なります。
+
+* HostName: ノードのカーネルによって伝えられたホスト名です。kubeletの`--hostname-override`パラメーターによって上書きすることができます。
+* ExternalIP: 通常は、外部にルーティング可能(クラスターの外からアクセス可能)なノードのIPアドレスです。
+* InternalIP: 通常は、クラスター内でのみルーティング可能なノードのIPアドレスです。
+
+
+### Conditions {#condition}
+
+`conditions`フィールドは全ての`Running`なノードのステータスを表します。例として、以下のような状態を含みます:
+
+| ノードのCondition | 概要 |
+|----------------|-------------|
+| `OutOfDisk`    | 新しいPodを追加するために必要なディスク容量が足りない場合に`True`になります。それ以外のときは`False`です。 |
+| `Ready`        | ノードの状態がHealthyでPodを配置可能な場合に`True`になります。ノードの状態に問題があり、Podが配置できない場合に`False`になります。ノードコントローラーが、`node-monitor-grace-period`で設定された時間内(デフォルトでは40秒)に該当ノードと疎通できない場合、`Unknown`になります。 |
+| `MemoryPressure`    | ノードのメモリが圧迫されているときに`True`になります。圧迫とは、メモリの空き容量が少ないことを指します。それ以外のときは`False`です。 |
+| `PIDPressure`    | プロセスが圧迫されているときに`True`になります。圧迫とは、プロセス数が多すぎることを指します。それ以外のときは`False`です。 |
+| `DiskPressure`    | ノードのディスク容量がが圧迫されているときに`True`になります。圧迫とは、ディスクの空き容量が少ないことを指します。それ以外のときは`False`です。 |
+| `NetworkUnavailable`    | ノードのネットワークが適切に設定されていない場合に`True`になります。それ以外のときは`False`です。 |
+
+ノードのConditionはJSONオブジェクトで表現されます。例えば、正常なノードの場合は以下のようなレスポンスが表示されます。
+
+```json
+"conditions": [
+  {
+    "type": "Ready",
+    "status": "True",
+    "reason": "KubeletReady",
+    "message": "kubelet is posting ready status",
+    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
+    "lastTransitionTime": "2019-06-05T11:41:27Z"
+  }
+]
+```
+
+Ready conditionが`pod-eviction-timeout`に設定された時間を超えても`Unknown`や`False`のままになっている場合、[kube-controller-manager](/docs/admin/kube-controller-manager/)に引数が渡され、該当ノード上にあるPodはノードコントローラーによって削除がスケジュールされます。デフォルトの退役のタイムアウトの時間は**5分**です。ノードが到達不能ないくつかの場合においては、APIサーバーが該当ノードのkubeletと疎通できない状態になっています。その場合、APIサーバーがkubeletと再び通信を確立するまでの間、Podの削除を行うことはできません。削除がスケジュールされるまでの間、削除対象のPodたちは切り離されたノードの上で稼働を続けることになります。
+
+バージョン1.5よりも前のKubernetesでは、ノードコントローラーはAPIサーバーから到達不能なそれらのPodを[強制削除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)していました。しかしながら、1.5以降では、ノードコントローラーはクラスター内でPodが停止するのを確認するまでは強制的に削除しないようになりました。到達不能なノード上で動いているPodは`Terminating`または`Unknown`のステータスになります。Kubernetesが基盤となるインフラストラクチャーを推定できない場合、クラスター管理者は手動でNodeオブジェクトを削除する必要があります。KubernetesからNodeオブジェクトを削除すると、そのノードで実行されているすべてのPodオブジェクトがAPIサーバーから削除され、それらの名前が解放されます。
+
+バージョン1.12において、`TaintNodesByCondition`機能がBetaに昇格し、それによってノードのライフサイクルコントローラーがconditionを表した[taint](/docs/concepts/configuration/taint-and-toleration/)を自動的に生成するようになりました。
+同様に、スケジューラーがPodを配置するノードを検討する際、ノードのtaintとPodのtolerationsを見るかわりにconditionを無視するようになりました。
+
+ユーザーは、古いスケジューリングモデルか、新しくてより柔軟なスケジューリングモデルのどちらかを選択できるようになりました。
+上記のtolerationがないPodは古いスケジュールモデルに従ってスケジュールされます。しかし、特定のノードのtaintを許容するPodについては、条件に合ったノードにスケジュールすることができます。
+
+{{< caution >}}
+
+この機能を有効にすると、conditionが観測されてからtaintが作成されるまでの間にわずかな遅延が発生します。
+この遅延は通常1秒未満ですが、正常にスケジュールされているが、kubeletによって配置を拒否されたPodの数が増える可能性があります。
+
+{{< /caution >}}
+
+### CapacityとAllocatable {#capacity}
+
+ノードで利用可能なリソース（CPU、メモリ、およびノードでスケジュールできる最大Pod数）について説明します。
+
+capacityブロック内のフィールドは、ノードが持っているリソースの合計量を示します。
+allocatableブロックは、通常のPodによって消費されるノード上のリソースの量を示します。
+
+CapacityとAllocatableについて深く知りたい場合は、ノード上でどのように[コンピュートリソースが予約されるか](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)を読みながら学ぶことができます。
+
+### Info
+
+カーネルのバージョン、Kubernetesのバージョン（kubeletおよびkube-proxyのバージョン）、（使用されている場合）Dockerのバージョン、OS名など、ノードに関する一般的な情報です。
+この情報はノードからkubeletを通じて取得されます。
+
+## 管理 {#management}
+
+[Pod](/docs/concepts/workloads/pods/pod/)や[Service](/docs/concepts/services-networking/service/)と違い、ノードは本質的にはKubernetesによって作成されません。GCPのようなクラウドプロバイダーによって外的に作成されるか、VMや物理マシンのプールに存在するものです。そのため、Kubernetesがノードを作成すると、そのノードを表すオブジェクトが作成されます。作成後、Kubernetesはそのノードが有効かどうかを確認します。 たとえば、次の内容からノードを作成しようとしたとします:
+
+```json
+{
+  "kind": "Node",
+  "apiVersion": "v1",
+  "metadata": {
+    "name": "10.240.79.157",
+    "labels": {
+      "name": "my-first-k8s-node"
+    }
+  }
+}
+```
+
+Kubernetesは内部的にNodeオブジェクトを作成し、 `metadata.name`フィールドに基づくヘルスチェックによってノードを検証します。ノードが有効な場合、つまり必要なサービスがすべて実行されている場合は、Podを実行する資格があります。それ以外の場合、該当ノードが有効になるまではいかなるクラスターの活動に対しても無視されます。
+
+{{< note >}}
+Kubernetesは無効なノードのためにオブジェクトを保存し、それをチェックし続けます。
+このプロセスを停止するには、Nodeオブジェクトを明示的に削除する必要があります。
+{{< /note >}}
+
+現在、Kubernetesのノードインターフェースと相互作用する3つのコンポーネントがあります。ノードコントローラー、kubelet、およびkubectlです。
+
+### ノードコントローラー
+
+ノードコントローラーは、ノードのさまざまな側面を管理するKubernetesのマスターコンポーネントです。
+
+ノードコントローラーは、ノードの存続期間中に複数の役割を果たします。1つ目は、ノードが登録されたときにCIDRブロックをノードに割り当てることです（CIDR割り当てがオンになっている場合）。
+
+2つ目は、ノードコントローラーの内部ノードリストをクラウドの利用可能なマシンのリストと一致させることです。
+クラウド環境で実行している場合、ノードに異常があると、ノードコントローラーはクラウドプロバイダーにそのNodeのVMがまだ使用可能かどうかを問い合わせます。
+使用可能でない場合、ノードコントローラーはノードのリストから該当ノードを削除します。
+
+3つ目は、ノードの状態を監視することです。
+ノードが到達不能(例えば、ノードがダウンしているなどので理由で、ノードコントローラーがハートビートの受信を停止した場合)になると、ノードコントローラーは、NodeStatusのNodeReady conditionをConditionUnknownに変更する役割があります。その後も該当ノードが到達不能のままであった場合、Graceful Terminationを使って全てのPodを退役させます。デフォルトのタイムアウトは、ConditionUnknownの報告を開始するまで40秒、その後Podの追い出しを開始するまで5分に設定されています。
+ノードコントローラーは、`--node-monitor-period`に設定された秒数ごとに各ノードの状態をチェックします。
+
+バージョン1.13よりも前のKubernetesにおいて、NodeStatusはノードからのハートビートでした。Kubernetes 1.13から、NodeLeaseがアルファ機能として導入されました（Feature Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)）。
+
+NodeLeaseが有効になっている場合、各ノードは `kube-node-lease`というNamespaceに関連付けられた`Lease`オブジェクトを持ち、ノードによって定期的に更新されます。NodeStatusとNodeLeaseの両方がノードからのハートビートとして扱われます。NodeLeaseは頻繁に更新されますが、NodeStatusはノードからマスターへの変更があるか、または十分な時間が経過した場合にのみ報告されます（デフォルトは1分で、到達不能の場合のデフォルトタイムアウトである40秒よりも長いです）。NodeLeaseはNodeStatusよりもはるかに軽量であるため、スケーラビリティとパフォーマンスの両方の観点においてノードのハートビートのコストを下げます。
+
+Kubernetes 1.4では、マスターに問題が発生した場合の対処方法を改善するように、ノードコントローラーのロジックをアップデートしています（マスターのネットワークに問題があるため）
+バージョン1.4以降、ノードコントローラーは、Podの退役について決定する際に、クラスター内のすべてのノードの状態を調べます。
+
+ほとんどの場合、排除の速度は1秒あたり`--node-eviction-rate`に設定された数値（デフォルトは秒間0.1）です。つまり、10秒間に1つ以上のPodをノードから追い出すことはありません。
+
+特定のアベイラビリティーゾーン内のノードのステータスが異常になると、ノード排除の挙動が変わります。ノードコントローラーは、ゾーン内のノードの何%が異常（NodeReady条件がConditionUnknownまたはConditionFalseである）であるかを同時に確認します。
+異常なノードの割合が少なくとも `--healthy-zone-threshold`に設定した値を下回る場合（デフォルトは0.55）であれば、退役率は低下します。クラスターが小さい場合（すなわち、 `--large-cluster-size-threshold`の設定値よりもノード数が少ない場合。デフォルトは50）、退役は停止し、そうでない場合、退役率は秒間で`--secondary-node-eviction-rate`の設定値（デフォルトは0.01）に減少します。
+これらのポリシーがアベイラビリティーゾーンごとに実装されているのは、1つのアベイラビリティーゾーンがマスターから分割される一方、他のアベイラビリティーゾーンは接続されたままになる可能性があるためです。
+クラスターが複数のクラウドプロバイダーのアベイラビリティーゾーンにまたがっていない場合、アベイラビリティーゾーンは1つだけです（クラスター全体）。
+
+ノードを複数のアベイラビリティゾーンに分散させる主な理由は、1つのゾーン全体が停止したときにワークロードを正常なゾーンに移動できることです。
+したがって、ゾーン内のすべてのノードが異常である場合、ノードコントローラーは通常のレート `--node-eviction-rate`で退役します。
+コーナーケースは、すべてのゾーンが完全にUnhealthyである（すなわち、クラスタ内にHealthyなノードがない）場合です。
+このような場合、ノードコントローラーはマスター接続に問題があると見なし、接続が回復するまですべての退役を停止します。
+
+Kubernetes 1.6以降では、ノードコントローラーは、Podがtaintを許容しない場合、 `NoExecute`のtaintを持つノード上で実行されているPodを排除する責務もあります。
+さらに、デフォルトで無効になっているアルファ機能として、ノードコントローラーはノードに到達できない、または準備ができていないなどのノードの問題に対応するtaintを追加する責務があります。
+`NoExecute`のtaint及び上述のアルファ機能に関する詳細は、[こちらのドキュメント](/docs/concepts/configuration/taint-and-toleration/)をご覧ください。
+
+バージョン1.8以降、ノードコントローラーに対してノードの状態を表すtaintを作成する責務を持たせることができます。これはバージョン1.8のアルファ機能です。
+
+### ノードの自己登録
+
+kubeletのフラグ `--register-node`がtrue（デフォルト）のとき、kubeletは自分自身をAPIサーバーに登録しようとします。これはほとんどのディストリビューションで使用されている推奨パターンです。
+
+自己登録については、kubeletは以下のオプションを伴って起動されます:
+
+  - `--kubeconfig` - 自分自身をAPIサーバーに対して認証するための資格情報へのパス
+  - `--cloud-provider` - 自身に関するメタデータを読むためにクラウドプロバイダーと会話する方法
+  - `--register-node` - 自身をAPIサーバーに自動的に登録
+  - `--register-with-taints` - 与えられたtaintのリストでノードを登録します (カンマ区切りの `<key>=<value>:<effect>`). `register-node`がfalseの場合、このオプションは機能しません
+  - `--node-ip` - ノードのIPアドレス
+  - `--node-labels` - ノードをクラスターに登録するときに追加するラベル（1.13以降の[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)によって適用されるラベルの制限を参照）
+  - `--node-status-update-frequency` - kubeletがノードのステータスをマスターにPOSTする頻度の指定
+
+[ノード認証モード](/docs/reference/access-authn-authz/node/)および[NodeRestriction許可プラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっている場合、kubeletは自分自身のノードリソースを作成/変更することのみ許可されています。
+
+#### 手動によるノード管理 {#manual-node-administration}
+
+クラスター管理者はNodeオブジェクトを作成および変更できます。
+
+管理者が手動でNodeオブジェクトを作成したい場合は、kubeletフラグ `--register-node = false`を設定してください。
+
+管理者は`--register-node`の設定に関係なくNodeリソースを変更することができます。
+変更には、ノードにラベルを設定し、それをunschedulableとしてマークすることが含まれます。
+
+ノード上のラベルは、スケジューリングを制御するためにPod上のノードセレクタと組み合わせて使用できます。
+例えば、Podをノードのサブセットでのみ実行する資格があるように制限します。
+
+ノードをunschedulableとしてマークすると、新しいPodがそのノードにスケジュールされるのを防ぎますが、ノード上の既存のPodには影響しません。
+これは、ノードの再起動などの前の準備ステップとして役立ちます。たとえば、ノードにスケジュール不可能のマークを付けるには、次のコマンドを実行します:
+
+```shell
+kubectl cordon $ノード名
+```
+
+{{< note >}}
+DaemonSetコントローラーによって作成されたPodはKubernetesスケジューラーをバイパスし、ノード上のunschedulable属性を考慮しません。
+これは、再起動の準備中にアプリケーションからアプリケーションが削除されている場合でも、デーモンがマシンに属していることを前提としているためです。
+{{< /note >}}
+
+### ノードのキャパシティ
+
+ノードのキャパシティ（CPUの数とメモリの量）はNodeオブジェクトの一部です。
+通常、ノードは自分自身を登録し、Nodeオブジェクトを作成するときにキャパシティを報告します。
+[手動によるノード管理](#manual-node-administration)を実行している場合は、ノードを追加するときにキャパシティを設定する必要があります。
+
+Kubernetesスケジューラーは、ノード上のすべてのPodに十分なリソースがあることを確認します。
+ノード上のコンテナが要求するリソースの合計がノードキャパシティ以下であることを確認します。
+これは、kubeletによって開始されたすべてのコンテナを含みますが、[コンテナランタイム](/docs/concepts/overview/components/#node-components)によって直接開始されたコンテナやコンテナの外で実行されているプロセスは含みません。
+
+Pod以外のプロセス用にリソースを明示的に予約したい場合は、このチュートリアルに従って[Systemデーモン用にリソースを予約](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)してください。
+
+
+## APIオブジェクト
+
+NodeはKubernetesのREST APIにおけるトップレベルのリソースです。APIオブジェクトに関する詳細は以下の記事にてご覧いただけます:
+[Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
+
+{{% /capture %}}
@@ -0,0 +1,42 @@
+---
+title: コントローラーマネージャーの指標
+content_template: templates/concept
+weight: 100
+---
+
+{{% capture overview %}}
+コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。
+
+{{% /capture %}}
+
+{{% capture body %}}
+## コントローラーマネージャーの指標とは何か
+
+コントローラーマネージャーの指標は、コントローラー内部のパフォーマンスについての重要で正確な情報と、クラウドコントローラーの状態についての情報を提供します。
+これらの指標にはgo_routineのカウントなどの一般的なGo言語ランタイムの指標と、etcdのリクエストレイテンシまたはCloudprovider（AWS、GCE、OpenStack）APIのレイテンシといったコントローラー固有の指標が含まれていて、クラスターの状態を測定するために利用できます。
+
+Kubernetes 1.7からGCE、AWS、Vsphere、OpenStackのストレージ操作の詳細なCloudproviderの指標が利用可能になりました。
+これらの指標は永続的ボリュームの操作状況を監視するために利用できます。
+
+たとえば、GCEの場合にはこれらの指標は次のように呼び出されます。
+
+```
+cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
+cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
+cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
+cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
+cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
+cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
+```
+
+
+
+## 設定
+
+クラスターではコントローラーマネージャーの指標はコントローラーマネージャーが実行されているホストの`http://localhost:10252/metrics`から取得可能です。
+
+この指標は[prometheusフォーマット](https://prometheus.io/docs/instrumenting/exposition_formats/)で出力され人間が読める形式になっています。
+
+本番環境ではこれらの指標を定期的に収集し、なんらかの時系列データベースで使用できるようにprometheusやその他の指標のスクレイパーを構成することが推奨されます。
+
+{{% /capture %}}
@@ -0,0 +1,370 @@
+---
+title: Node上へのPodのスケジューリング
+content_template: templates/concept
+weight: 30
+---
+
+
+{{% capture overview %}}
+
+[Pod](/docs/concepts/workloads/pods/pod/)が稼働する[Node](/docs/concepts/architecture/nodes/)を特定のものに指定したり、優先条件を指定して制限することができます。
+これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/docs/concepts/overview/working-with-objects/labels/)です。
+スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、
+SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## nodeSelector
+
+`nodeSelector`は、Nodeを選択するための、最も簡単で推奨されている手法です。
+`nodeSelector`はPodSpecのフィールドです。これはkey-valueペアのマップを特定します。
+あるノードでPodを稼働させるためには、そのノードがラベルとして指定されたkey-valueペアを保持している必要があります(複数のラベルを保持することも可能です)。
+最も一般的な使用方法は、1つのkey-valueペアを付与する方法です。
+
+以下に、`nodeSelector`の使用例を紹介します。
+
+### ステップ0: 前提条件
+
+この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](https://github.com/kubernetes/kubernetes#documentation)がされていることが前提となっています。
+
+### ステップ1: Nodeへのラベルの付与
+
+`kubectl get nodes`で、クラスターのノードの名前を取得してください。
+そして、ラベルを付与するNodeを選び、`kubectl label nodes <node-name> <label-key>=<label-value>`で選択したNodeにラベルを付与します。
+例えば、Nodeの名前が'kubernetes-foo-node-1.c.a-robinson.internal'、付与するラベルが'disktype=ssd'の場合、`kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`によってラベルが付与されます。
+
+`kubectl get nodes --show-labels`によって、ノードにラベルが付与されたかを確認することができます。
+また、`kubectl describe node "nodename"`から、そのNodeの全てのラベルを表示することもできます。
+
+### ステップ2: PodへのnodeSelectorフィールドの追加
+
+該当のPodのconfigファイルに、nodeSelectorのセクションを追加します:
+例として以下のconfigファイルを扱います:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+  labels:
+    env: test
+spec:
+  containers:
+  - name: nginx
+    image: nginx
+```
+
+nodeSelectorを以下のように追加します:
+
+{{< codenew file="pods/pod-nginx.yaml" >}}
+
+`kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`により、Podは先ほどラベルを付与したNodeへスケジュールされます。
+`kubectl get pods -o wide`で表示される"NODE"の列から、PodがデプロイされているNodeを確認することができます。
+
+## 補足: ビルトインNodeラベル
+
+明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にNodeへ付与されているものもあります。
+以下のようなラベルが該当します。
+
+* `kubernetes.io/hostname`
+* `failure-domain.beta.kubernetes.io/zone`
+* `failure-domain.beta.kubernetes.io/region`
+* `beta.kubernetes.io/instance-type`
+* `kubernetes.io/os`
+* `kubernetes.io/arch`
+
+{{< note >}}
+これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。
+例えば、`kubernetes.io/hostname`の値はNodeの名前と同じである環境もあれば、異なる環境もあります。
+{{< /note >}}
+
+
+## Nodeの隔離や制限
+Nodeにラベルを付与することで、Podは特定のNodeやNodeグループにスケジュールされます。
+これにより、特定のPodを、確かな隔離性や安全性、特性を持ったNodeで稼働させることができます。
+この目的でラベルを使用する際に、Node上のkubeletプロセスに上書きされないラベルキーを選択することが強く推奨されています。
+これは、安全性が損なわれたNodeがkubeletの認証情報をNodeのオブジェクトに設定したり、スケジューラーがそのようなNodeにデプロイすることを防ぎます。
+
+`NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。
+Nodeの隔離にラベルのプレフィックスを使用するためには、以下の３点を確認してください。
+
+1. NodeRestrictionを使用するため、Kubernetesのバージョンがv1.11以上であること。
+2. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が有効になっていること。
+3. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。
+例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。
+
+## Affinity と Anti-Affinity
+
+`nodeSelector`はPodの稼働を特定のラベルが付与されたNodeに制限する最も簡単な方法です。
+Affinity/Anti-Affinityでは、より柔軟な指定方法が提供されています。
+拡張機能は以下の通りです。
+
+1. 様々な指定方法がある ("AND条件"に限らない)
+2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができる
+3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができる
+
+Affinityは"Node Affinity"と"Inter-Pod Affinity/Anti-Affinity"の2種類から成ります。
+Node affinityは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Inter-Pod Affinity/Anti-Affinityは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。
+
+`nodeSelector`は問題なく使用することができますが、Node affinityは`nodeSelector`で指定できる条件を全て実現できるため、将来的には推奨されなくなります。
+
+### Node Affinity
+
+Node Affinityはα機能としてKubernetesのv1.2から導入されました。
+Node Affinityは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。
+
+現在は2種類のNode Affinityがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。
+前者はNodeにスケジュールされるPodが条件を満たすことが必須(`nodeSelector`に似ていますが、より柔軟に条件を指定できます)であり、後者は条件を指定できますが保証されるわけではなく、優先的に考慮されます。
+"IgnoredDuringExecution"の意味するところは、`nodeSelector`の機能と同様であり、Nodeのラベルが変更され、Podがその条件を満たさなくなった場合でも
+PodはそのNodeで稼働し続けるということです。
+将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNode Affinityに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。
+
+それぞれの使用例として、
+`requiredDuringSchedulingIgnoredDuringExecution` は、"インテルCPUを供えたNode上でPodを稼働させる"、
+`preferredDuringSchedulingIgnoredDuringExecution`は、"ゾーンXYZでPodの稼働を試みますが、実現不可能な場合には他の場所で稼働させる"
+といった方法が挙げられます。
+
+Node Affinityは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。
+
+Node Affinityを使用したPodの例を以下に示します:
+
+{{< codenew file="pods/pod-with-node-affinity.yaml" >}}
+
+このNode Affinityでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。
+加えて、キーが`another-node-label-key`、値が`another-node-label-value`のラベルが付与されたNodeが優先されます。
+
+この例ではオペレーター`In`が使われています。
+Node Affinityでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。
+`NotIn`と`DoesNotExist`はNode Anti-Affinity、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/docs/concepts/configuration/taint-and-toleration/)に使用します。
+
+`nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすNodeにスケジュールされます。
+
+`nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**いずれかの**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。
+
+`nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**全ての**`matchExpressions`を満たしたNodeへスケジュールされます。
+
+PodがスケジュールされたNodeのラベルを削除したり変更しても、Podは削除されません。
+言い換えると、AffinityはPodをスケジュールする際にのみ考慮されます。
+
+`preferredDuringSchedulingIgnoredDuringExecution`内の`weight`フィールドは、1から100の範囲で指定します。
+全ての必要条件(リソースやRequiredDuringScheduling Affinity等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。
+このスコアがNodeの他の優先機能のスコアと組み合わせれ、最も高いスコアを有したNodeが優先されます。
+
+### Inter-Pod Affinity/Anti-Affinity
+
+Inter-Pod AffinityとAnti-Affinityは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。
+このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(Anti-Affinityの場合は稼働させない)"という形式です。
+Yはnamespaceのリストで指定したLabelSelectorで表されます。
+Nodeと異なり、Podはnamespaceで区切られているため(それゆえPodのラベルも暗黙的にnamespaceで区切られます)、Podのラベルを指定するlabel selectorは、どのnamespaceにselectorを適用するかを指定する必要があります。
+概念的に、XはNodeや、ラック、クラウドプロバイダゾーン、クラウドプロバイダのリージョン等を表すトポロジードメインです。
+これらを表すためにシステムが使用するNode Labelのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。
+先述のセクション[補足: ビルトインNodeラベル](#interlude-built-in-node-labels)にてラベルの例が紹介されています。
+
+
+{{< note >}}
+Inter-Pod AffinityとAnti-Affinityは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。
+そのため、数百台以上のNodeから成るクラスターでは使用することを推奨されません。
+{{< /note >}}
+
+{{< note >}}
+Pod Anti-Affinityは、Nodeに必ずラベルが付与されている必要があります。
+例えば、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。
+それらが付与されていないNodeが存在する場合、意図しない挙動を示すことがあります。
+{{< /note >}}
+
+Node Affinityと同様に、Pod AffinityとPod Anti-Affinityにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。
+前述のNode Affinityのセクションを参照してください。
+`requiredDuringSchedulingIgnoredDuringExecution`を指定するAffinityの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。
+また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するAnti-Affinityの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。
+
+Inter-Pod Affinityは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Inter-Pod Anti-Affinityは、`podAntiAffinity`で指定します。
+
+#### Pod Affinityを使用したPodの例
+
+{{< codenew file="pods/pod-with-pod-affinity.yaml" >}}
+
+このPodのAffifnityは、Pod AffinityとPod Anti-Affinityを1つずつ定義しています。
+この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。
+Pod Affinityは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`failure-domain.beta.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、
+Node Nがキー`failure-domain.beta.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。
+Pod Anti-Affinityは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています
+(`topologyKey`が`failure-domain.beta.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。
+Pod AffinityとPod Anti-Affinityや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。
+
+Pod AffinityとPod Anti-Affinityで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。
+
+原則として、`topologyKey`には任意のラベルとキーが使用できます。
+しかし、パフォーマンスやセキュリティの観点から、以下の制約があります:
+
+1. Affinityと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`topologyKey`を指定しないことは許可されていません。
+2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。
+トポロジーをカスタマイズする場合には、アドミッションコントローラーを修正または無効化する必要があります。
+3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPod Anti-Affinityでは、`topologyKey`を指定しなかった場合、"全てのトポロジー"と解釈されます("全てのトポロジー"とは、ここでは`kubernetes.io/hostname`、`failure-domain.beta.kubernetes.io/zone`、`failure-domain.beta.kubernetes.io/region`を合わせたものを意味します)。
+4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができあます。
+
+`labelSelector`と`topologyKey`に加え、`labelSelector`が合致すべき`namespaces`のリストを特定することも可能です(これは`labelSelector`と`topologyKey`を定義することと同等です)。
+省略した場合や空の場合は、AffinityとAnti-Affinityが定義されたPodのnamespaceがデフォルトで設定されます。
+
+`requiredDuringSchedulingIgnoredDuringExecution`が指定されたAffinityとAnti-Affinityでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。 
+
+
+#### 実際的なユースケース
+
+Inter-Pod AffinityとAnti-Affinityは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用すると更に有用です。
+Workloadが、Node等の定義された同じトポロジーに共存させるよう、簡単に設定できます。
+
+
+##### 常に同じNodeで稼働させる場合
+
+３つのノードから成るクラスターでは、ウェブアプリケーションはredisのようにインメモリキャッシュを保持しています。
+このような場合、ウェブサーバーは可能な限りキャッシュと共存させることが望ましいです。
+
+ラベル`app=store`を付与した3つのレプリカから成るredisのdeploymentを記述したyamlファイルを示します。
+Deploymentには、1つのNodeにレプリカを共存させないために`PodAntiAffinity`を付与しています。
+
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: redis-cache
+spec:
+  selector:
+    matchLabels:
+      app: store
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        app: store
+    spec:
+      affinity:
+        podAntiAffinity:
+          requiredDuringSchedulingIgnoredDuringExecution:
+          - labelSelector:
+              matchExpressions:
+              - key: app
+                operator: In
+                values:
+                - store
+            topologyKey: "kubernetes.io/hostname"
+      containers:
+      - name: redis-server
+        image: redis:3.2-alpine
+```
+
+ウェブサーバーのDeploymentを記載した以下のyamlファイルには、`podAntiAffinity` と`podAffinity`が設定されています。
+全てのレプリカが`app=store`のラベルが付与されたPodと同じゾーンで稼働するよう、スケジューラーに設定されます。
+また、それぞれのウェブサーバーは1つのノードで稼働されないことも保証されます。
+
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: web-server
+spec:
+  selector:
+    matchLabels:
+      app: web-store
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        app: web-store
+    spec:
+      affinity:
+        podAntiAffinity:
+          requiredDuringSchedulingIgnoredDuringExecution:
+          - labelSelector:
+              matchExpressions:
+              - key: app
+                operator: In
+                values:
+                - web-store
+            topologyKey: "kubernetes.io/hostname"
+        podAffinity:
+          requiredDuringSchedulingIgnoredDuringExecution:
+          - labelSelector:
+              matchExpressions:
+              - key: app
+                operator: In
+                values:
+                - store
+            topologyKey: "kubernetes.io/hostname"
+      containers:
+      - name: web-app
+        image: nginx:1.12-alpine
+```
+
+上記2つのDeploymentが生成されると、3つのノードは以下のようになります。
+
+|       node-1         |       node-2        |       node-3       |
+|:--------------------:|:-------------------:|:------------------:|
+| *webserver-1*        |   *webserver-2*     |    *webserver-3*   |
+|  *cache-1*           |     *cache-2*       |     *cache-3*      |
+
+このように、3つの`web-server`は期待通り自動的にキャッシュと共存しています。
+
+```
+kubectl get pods -o wide
+```
+出力は以下のようになります:
+```
+NAME                           READY     STATUS    RESTARTS   AGE       IP           NODE
+redis-cache-1450370735-6dzlj   1/1       Running   0          8m        10.192.4.2   kube-node-3
+redis-cache-1450370735-j2j96   1/1       Running   0          8m        10.192.2.2   kube-node-1
+redis-cache-1450370735-z73mh   1/1       Running   0          8m        10.192.3.1   kube-node-2
+web-server-1287567482-5d4dz    1/1       Running   0          7m        10.192.2.3   kube-node-1
+web-server-1287567482-6f7v5    1/1       Running   0          7m        10.192.4.3   kube-node-3
+web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3.2   kube-node-2
+```
+
+##### 同じNodeに共存させない場合
+
+上記の例では `PodAntiAffinity`を`topologyKey: "kubernetes.io/hostname"`と合わせて指定することで、redisクラスター内の2つのインスタンスが同じホストにデプロイされない場合を扱いました。
+同様の方法で、Anti-Affinityを用いて高可用性を実現したStatefulSetの使用例は[ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)を参照してください。
+
+
+## nodeName
+
+`nodeName`はNodeの選択を制限する最も簡単な方法ですが、制約があることからあまり使用されません。
+`nodeName`はPodSpecのフィールドです。
+ここに値が設定されると、schedulerはそのPodを考慮しなくなり、その名前が付与されているNodeのkubeletはPodを稼働させようとします。
+そのため、PodSpecに`nodeName`が指定されると、上述のNodeの選択方法よりも優先されます。
+
+ `nodeName`を使用することによる制約は以下の通りです:
+
+-   その名前のNodeが存在しない場合、Podは起動されす、自動的に削除される場合があります。
+-   その名前のNodeにPodを稼働させるためのリソースがない場合、Podの起動は失敗し、理由はOutOfmemoryやOutOfcpuになります。
+-   クラウド上のNodeの名前は予期できず、変更される可能性があります。
+
+`nodeName`を指定したPodの設定ファイルの例を示します:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  containers:
+  - name: nginx
+    image: nginx
+  nodeName: kube-01
+```
+
+上記のPodはkube-01という名前のNodeで稼働します。
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+[Taints](/docs/concepts/configuration/taint-and-toleration/)を使うことで、NodeはPodを追い出すことができます。
+
+[Node Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)と
+[Inter-Pod Affinity/Anti-Affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
+には、Taintsの要点に関して様々な背景が紹介されています。
+
+{{% /capture %}}
@@ -0,0 +1,104 @@
+---
+title: 設定のベストプラクティス
+content_template: templates/concept
+weight: 10
+---
+
+{{% capture overview %}}
+このドキュメントでは、ユーザーガイド、入門マニュアル、および例を通して紹介されている設定のベストプラクティスを中心に説明します。
+
+このドキュメントは生ものです。このリストには載っていないが他の人に役立つかもしれない何かについて考えている場合、IssueまたはPRを遠慮なく作成してください。
+{{% /capture %}}
+
+{{% capture body %}}
+## 一般的な設定のTips
+- 構成を定義する際には、最新の安定したAPIバージョンを指定してください。
+
+- 設定ファイルは、クラスターに反映される前にバージョン管理システムに保存されるべきです。これによって、必要に応じて設定変更を迅速にロールバックできます。また、クラスターの再作成や復元時にも役立ちます。
+
+- JSONではなくYAMLを使って設定ファイルを書いてください。これらのフォーマットはほとんどすべてのシナリオで互換的に使用できますが、YAMLはよりユーザーフレンドリーになる傾向があります。
+
+- 意味がある場合は常に、関連オブジェクトを単一ファイルにグループ化します。多くの場合、1つのファイルの方が管理が簡単です。例として[guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml)ファイルを参照してください。
+
+- 多くの`kubectl`コマンドがディレクトリに対しても呼び出せることも覚えておきましょう。たとえば、設定ファイルのディレクトリで `kubectl apply`を呼び出すことができます。
+
+- 不必要にデフォルト値を指定しないでください。シンプルかつ最小限の設定のほうがエラーが発生しにくくなります。
+
+- よりよいイントロスペクションのために、オブジェクトの説明をアノテーションに入れましょう。
+
+
+## "真っ裸"のPod に対する ReplicaSet、Deployment、およびJob
+
+- 可能な限り、"真っ裸"のPod([ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)や[Deployment](/docs/concepts/workloads/controllers/deployment/)にバインドされていないPod)は使わないでください。Nodeに障害が発生した場合、これらのPodは再スケジュールされません。
+
+  明示的に[`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)を使いたいシーンを除いて、DeploymentはPodを直接作成するよりもほとんど常に望ましい方法です。Deploymentには、希望する数のPodが常に使用可能であることを確認するためにReplicaSetを作成したり、Podを置き換えるための戦略（RollingUpdateなど）を指定したりできます。[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)のほうが適切な場合もあるかもしれません。
+
+## Service
+
+- 対応するバックエンドワークロード（DeploymentまたはReplicaSet）の前、およびそれにアクセスする必要があるワークロードの前に[Service](/docs/concepts/services-networking/service/)を作成します。Kubernetesがコンテナを起動すると、コンテナ起動時に実行されていたすべてのServiceを指す環境変数が提供されます。たとえば、fooという名前のServiceが存在する場合、すべてのコンテナは初期環境で次の変数を取得します。
+
+  ```shell
+  FOO_SERVICE_HOST=<the host the Service is running on>
+  FOO_SERVICE_PORT=<the port the Service is running on>
+  ```
+
+  *これは順序付けの必要性を意味します* - `Pod`がアクセスしたい`Service`は`Pod`自身の前に作らなければならず、そうしないと環境変数は注入されません。DNSにはこの制限はありません。
+
+- （強くお勧めしますが）[クラスターアドオン](/docs/concepts/cluster-administration/addons/)の1つの選択肢はDNSサーバーです。DNSサーバーは、新しい`Service`についてKubernetes APIを監視し、それぞれに対して一連のDNSレコードを作成します。クラスタ全体でDNSが有効になっている場合は、すべての`Pod`が自動的に`Services`の名前解決を行えるはずです。
+
+- どうしても必要な場合以外は、Podに`hostPort`を指定しないでください。Podを`hostPort`にバインドすると、Podがスケジュールできる場所の数を制限します、それぞれの<`hostIP`、 `hostPort`、`protocol`>の組み合わせはユニークでなければならないからです。`hostIP`と`protocol`を明示的に指定しないと、Kubernetesはデフォルトの`hostIP`として`0.0.0.0`を、デフォルトの `protocol`として`TCP`を使います。
+
+  デバッグ目的でのみポートにアクセスする必要がある場合は、[apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)または[`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)を使用できます。
+
+  ノード上でPodのポートを明示的に公開する必要がある場合は、hostPortに頼る前に[NodePort](/docs/concepts/services-networking/service/#nodeport)の使用を検討してください。
+
+- `hostPort`の理由と同じくして、`hostNetwork`の使用はできるだけ避けてください。
+
+- `kube-proxy`のロードバランシングが不要な場合は、[headless Service](/docs/concepts/services-networking/service/#headless-
+services)（`ClusterIP`が`None`）を使用してServiceを簡単に検出できます。
+
+## ラベルの使用
+
+- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。
+
+セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。
+
+オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が_適用_されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。
+
+- デバッグ用にラベルを操作できます。Kubernetesコントローラー（ReplicaSetなど）とServiceはセレクターラベルを使用してPodとマッチするため、Podから関連ラベルを削除すると、コントローラーによって考慮されたり、Serviceによってトラフィックを処理されたりすることがなくなります。既存のPodのラベルを削除すると、そのコントローラーはその代わりに新しいPodを作成します。これは、「隔離」環境で以前の「ライブ」Podをデバッグするのに便利な方法です。対話的にラベルを削除または追加するには、[`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)を使います。
+
+## コンテナイメージ
+
+[imagePullPolicy](/docs/concepts/containers/images/#updating-images)とイメージのタグは、[kubelet](/docs/admin/kubelet/)が特定のイメージをpullしようとしたときに作用します。
+
+- `imagePullPolicy: IfNotPresent`: ローカルでイメージが見つからない場合にのみイメージをpullします。
+
+- `imagePullPolicy: Always`: Podの起動時に常にイメージをpullします。
+
+- `imagePullPolicy` のタグが省略されていて、利用してるイメージのタグが`:latest`の場合や省略されいてる場合、`Always`が適用されます。
+
+- `imagePullPolicy` のタグが省略されていて、利用してるイメージのタグはあるが`:latest`でない場合場合、`IfNotPresent`が適用されます。
+
+- `imagePullPolicy: Never`: 常にローカルでイメージを探そうとします。ない場合にもイメージはpullしません。
+
+{{< note >}}
+コンテナが常に同じバージョンのイメージを使用するようにするためには、そのコンテナイメージの[ダイジェスト](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)を指定することができます(例:`sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)。このダイジェストはイメージの特定のバージョンを一意に識別するため、ダイジェスト値を変更しない限り、Kubernetesによって更新されることはありません。
+{{< /note >}}
+
+{{< note >}}
+どのバージョンのイメージが実行されているのかを追跡するのが難しく、適切にロールバックするのが難しいため、本番環境でコンテナをデプロイするときは `：latest`タグを使用しないでください。
+{{< /note >}}
+
+{{< note >}}
+ベースイメージのプロバイダーのキャッシュセマンティクスにより、`imagePullPolicy：Always`もより効率的になります。たとえば、Dockerでは、イメージが既に存在する場合すべてのイメージレイヤーがキャッシュされ、イメージのダウンロードが不要であるため、pullが高速になります。
+{{< /note >}}
+
+## kubectlの使い方
+
+- `kubectl apply -f <directory>`を使いましょう。これを使うと、ディレクトリ内のすべての`.yaml`、`.yml`、および`.json`ファイルが`apply`に渡されます。
+
+- `get`や`delete`を行う際は、特定のオブジェクト名を指定するのではなくラベルセレクターを使いましょう。[ラベルセレクター](/docs/concepts/overview/working-with-objects/labels/#label-selectors)と[ラベルの効果的な使い方](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)のセクションを参照してください。
+
+{{% /capture %}}
+
+
@@ -0,0 +1,4 @@
+---
+title: Kubernetesを拡張する
+weight: 110
+---
@@ -0,0 +1,4 @@
+---
+title: Kubernetes APIの拡張
+weight: 20
+---
@@ -0,0 +1,32 @@
+---
+title: アグリゲーションレイヤーを使ったKubernetes APIの拡張
+content_template: templates/concept
+weight: 10
+---
+
+{{% capture overview %}}
+
+アグリゲーションレイヤーを使用すると、KubernetesのコアAPIで提供されている機能を超えて、追加のAPIでKubernetesを拡張できます。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## 概要
+
+アグリゲーションレイヤーを使用すると、クラスターにKubernetesスタイルのAPIを追加でインストールできます。これらは、[service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)や、[apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)のようなユーザーが作成したAPIなど、出来合いのもの、また既存のサードパーティソリューションに関わらず使い始めることができます。
+
+バージョン1.7において、アグリゲーションレイヤーは、kube-apiserverのプロセス内で動きます。拡張リソースが登録されるまでは、アグリゲーションレイヤーは何もしません。APIを登録するには、ユーザーはKubernetes APIで使われるURLのパスを"要求"した、APIServiceオブジェクトを追加しなければなりません。それを追加すると、アグリゲーションレイヤーはAPIパス（例、/apis/myextension.mycompany.io/v1/…）への全てのアクセスを、登録されたAPIServiceにプロキシします。
+
+通常、APIServiceは、クラスター上で動いているPod内の *extension-apiserver* で実装されます。このextension-apiserverは、追加されたリソースに対するアクティブな管理が必要な場合、通常、1つか複数のコントローラーとペアになっている必要があります。そのため、実際にapiserver-builderはextension-apiserverとコントローラーの両方のスケルトンを提供します。一例として、service-catalogがインストールされると、extension-apiserverと提供するサービスのコントローラーの両方を提供します。
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* アグリゲーターをあなたの環境で動かすには、まず[アグリゲーションレイヤーを設定](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)します
+* そして、アグリゲーションレイヤーと一緒に動作させるために[extension api-serverをセットアップ](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)します
+* また、[Custom Resource Definitionを使いKubernetes APIを拡張する](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)方法を学んで下さい
+
+{{% /capture %}}
+
@@ -0,0 +1,167 @@
+---
+title: Kubernetesクラスターの拡張
+content_template: templates/concept
+weight: 10
+---
+
+{{% capture overview %}}
+
+Kubernetesは柔軟な設定が可能で、高い拡張性を持っています。
+結果として、Kubernetesのプロジェクトソースコードをフォークしたり、パッチを当てて利用することは滅多にありません。
+
+このガイドは、Kubernetesクラスターをカスタマイズするための選択肢を記載します。
+管理しているKubernetesクラスターを、動作環境の要件にどのように適合させるべきかを理解したい{{< glossary_tooltip text="クラスター管理者" term_id="cluster-operator" >}}を対象にしています。
+将来の {{< glossary_tooltip text="プラットフォーム開発者" term_id="platform-developer" >}} 、またはKubernetesプロジェクトの{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}にとっても、どのような拡張のポイントやパターンが存在するのか、また、それぞれのトレードオフや制限事項を学ぶための導入として役立つでしょう。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## 概要
+
+カスタマイズのアプローチには大きく分けて、フラグ、ローカル設定ファイル、またはAPIリソースの変更のみを含んだ *コンフィグレーション* と、稼働しているプログラムまたはサービスも含んだ *エクステンション* があります。このドキュメントでは、主にエクステンションについて説明します。
+
+## コンフィグレーション
+
+*設定ファイル* と *フラグ* はオンラインドキュメントのリファレンスセクションの中の、各項目に記載されています:
+
+* [kubelet](/docs/admin/kubelet/)
+* [kube-apiserver](/docs/admin/kube-apiserver/)
+* [kube-controller-manager](/docs/admin/kube-controller-manager/)
+* [kube-scheduler](/docs/admin/kube-scheduler/)
+
+ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。
+
+[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。更に、安定版（stable）を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
+
+## エクステンション
+
+エクステンションはKubernetesを拡張し、深く統合されたソフトウェアの構成要素です。
+これは新しいタイプと、新しい種類のハードウェアをサポートするために利用されます。
+
+ほとんどのクラスター管理者は、ホスティングされている、またはディストリビューションとしてのKubernetesを使っているでしょう。
+結果として、ほとんどのKubernetesユーザーは既存のエクステンションを使えばよいため、新しいエクステンションを書く必要は無いと言えます。
+
+## エクステンションパターン
+
+Kubernetesは、クライアントのプログラムを書くことで自動化ができるようにデザインされています。
+Kubernetes APIに読み書きをするどのようなプログラムも、役に立つ自動化機能を提供することができます。
+*自動化機能* はクラスター上、またはクラスター外で実行できます。
+このドキュメントに後述のガイダンスに従うことで、高い可用性を持つ頑強な自動化機能を書くことができます。
+自動化機能は通常、ホスティングされているクラスター、マネージドな環境など、どのKubernetesクラスター上でも動きます。
+
+Kubernetes上でうまく動くクライアントプログラムを書くために、*コントローラー* パターンという明確なパターンがあります。
+コントローラーは通常、オブジェクトの `.spec` を読み取り、何らかの処理をして、オブジェクトの `.status` を更新します。
+
+コントローラーはKubernetesのクライアントです。Kubernetesがクライアントとして動き、外部のサービスを呼び出す場合、それは *Webhook* と呼ばれます。
+呼び出されるサービスは *Webhookバックエンド* と呼ばれます。コントローラーのように、Webhookも障害点を追加します。
+
+Webhookのモデルでは、Kubernetesは外部のサービスを呼び出します。
+*バイナリプラグイン* モデルでは、Kubernetesはバイナリ（プログラム）を実行します。
+バイナリプラグインはkubelet（例、[FlexVolumeプラグイン](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md)、[ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/)）、またkubectlで利用されています。
+
+下図は、それぞれの拡張ポイントが、Kubernetesのコントロールプレーンとどのように関わっているかを示しています。
+
+<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
+
+<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
+
+## 拡張ポイント
+
+この図は、Kubernetesにおける拡張ポイントを示しています。
+
+<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
+
+<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
+
+1.   ユーザーは頻繁に`kubectl`を使って、Kubernetes APIとやり取りをします。[Kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)は、kubectlのバイナリを拡張します。これは個別ユーザーのローカル環境のみに影響を及ぼすため、サイト全体にポリシーを強制することはできません。
+2.   APIサーバーは全てのリクエストを処理します。APIサーバーのいくつかの拡張ポイントは、リクエストを認可する、コンテキストに基づいてブロックする、リクエストを編集する、そして削除を処理することを可能にします。これらは[APIアクセスエクステンション](/docs/concepts/overview/extending#api-access-extensions)セクションに記載されています。
+3.   APIサーバーは様々な種類の *リソース* を扱います。`Pod`のような *ビルトインリソース* はKubernetesプロジェクトにより定義され、変更できません。ユーザーも、自身もしくは、他のプロジェクトで定義されたリソースを追加することができます。それは *カスタムリソース* と呼ばれ、[カスタムリソース](/docs/concepts/overview/extending#user-defined-types)セクションに記載されています。カスタムリソースは度々、APIアクセスエクステンションと一緒に使われます。
+4.   KubernetesのスケジューラーはPodをどのノードに配置するかを決定します。スケジューリングを拡張するには、いくつかの方法があります。それらは[スケジューラーエクステンション](/docs/concepts/overview/extending#scheduler-extensions)セクションに記載されています。
+5.   Kubernetesにおける多くの振る舞いは、APIサーバーのクライアントであるコントローラーと呼ばれるプログラムに実装されています。コントローラーは度々、カスタムリソースと共に使われます。
+6.   kubeletはサーバー上で実行され、Podが仮想サーバーのようにクラスターネットワーク上にIPを持った状態で起動することをサポートします。[ネットワークプラグイン](/docs/concepts/overview/extending#network-plugins)がPodのネットワーキングにおける異なる実装を適用することを可能にします。
+7.   kubeletはまた、コンテナのためにボリュームをマウント、アンマウントします。新しい種類のストレージは[ストレージプラグイン](/docs/concepts/overview/extending#storage-plugins)を通じてサポートされます。
+
+もしあなたがどこから始めるべきかわからない場合、このフローチャートが役立つでしょう。一部のソリューションは、いくつかの種類のエクステンションを含んでいることを留意してください。
+
+<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
+
+<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
+
+## APIエクステンション
+### ユーザー定義タイプ
+
+新しいコントローラー、アプリケーションの設定に関するオブジェクト、また宣言型APIを定義し、それらを`kubectl`のようなKubernetesのツールから管理したい場合、Kubernetesにカスタムリソースを追加することを検討して下さい。
+
+カスタムリソースはアプリケーション、ユーザー、監視データのデータストレージとしては使わないで下さい。
+
+カスタムリソースに関するさらなる情報は、[カスタムリソースコンセプトガイド](/docs/concepts/api-extension/custom-resources/)を参照して下さい。
+
+### 新しいAPIと自動化機能の連携
+
+カスタムリソースAPIと制御ループの組み合わせは[オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)と呼ばれています。オペレーターパターンは、通常ステートフルな特定のアプリケーションを管理するために利用されます。これらのカスタムAPIと制御ループは、ストレージ、またはポリシーのような他のリソースを管理するためにも利用されます。
+
+### ビルトインリソースの変更
+
+カスタムリソースを追加し、KubernetesAPIを拡張する場合、新たに追加されたリソースは常に新しいAPIグループに分類されます。既存のAPIグループを置き換えたり、変更することはできません。APIを追加することは直接、既存のAPI（例、Pod）の振る舞いに影響を与えることは無いですが、APIアクセスエクステンションの場合、その可能性があります。
+
+### APIアクセスエクステンション
+
+リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/reference/access-authn-authz/controlling-access/)を参照して下さい。
+
+これらの各ステップごとに拡張ポイントが用意されています。
+
+Kubdernetesはいくつかのビルトイン認証方式をサポートしています。それは認証プロキシの後ろに配置することも可能で、認可ヘッダーを通じて（Webhookの）検証のために外部サービスにトークンを送ることもできます。全てのこれらの方法は[認証ドキュメント](/docs/reference/access-authn-authz/authentication/)でカバーされています。
+
+### 認証
+
+[認証](/docs/reference/access-authn-authz/authentication/)は、全てのリクエストのヘッダーまたは証明書情報を、リクエストを投げたクライアントのユーザー名にマッピングします。
+
+Kubernetesはいくつかのビルトイン認証方式と、それらが要件に合わない場合、[認証Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)を提供します。
+
+### 認可
+
+[認可](/docs/reference/access-authn-authz/webhook/)は特定のユーザーがAPIリソースに対して、読み込み、書き込み、そしてその他の操作が可能かどうかを決定します。それはオブジェクト全体のレベルで機能し、任意のオブジェクトフィールドに基づいての区別は行いません。もしビルトインの認可機構が要件に合わない場合、[認可Webhook](/docs/reference/access-authn-authz/webhook/)が、ユーザー提供のコードを呼び出し認可の決定を行うことを可能にします。
+
+### 動的Admission Control
+
+リクエストが認可された後、もしそれが書き込み操作だった場合、リクエストは[Admission Control](/docs/reference/access-authn-authz/admission-controllers/)のステップを通ります。ビルトインのステップに加え、いくつかのエクステンションが存在します:
+
+*   [イメージポリシーWebhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)は、コンテナでどのイメージを実行することができるかを制限する
+*   任意のAdmission Controlの決定を行うには、一般的な[Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)が利用できる。Admission Webhookは作成、更新を拒絶できる
+
+## インフラストラクチャエクステンション
+
+### ストレージプラグイン
+
+[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)は、Kubeletがバイナリプラグインを呼び出してボリュームをマウントすることにより、ユーザーはビルトインのサポートなしでボリュームタイプをマウントすることを可能にします。
+
+### デバイスプラグイン
+
+[デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)を通じて、ノードが新たなノードのリソース（CPU、メモリなどのビルトインのものに加え）を見つけることを可能にします。
+
+### ネットワークプラグイン
+
+他のネットワークファブリックが[ネットワークプラグイン](/docs/admin/network-plugins/)を通じてサポートされます。
+
+### スケジューラーエクステンション
+
+スケジューラーは特別な種類のコントローラーで、Podを監視し、Podをノードに割り当てます。デフォルトのコントローラーを完全に置き換えることもできますが、他のKubernetesのコンポーネントの利用を継続する、または[複数のスケジューラー](/docs/tasks/administer-cluster/configure-multiple-schedulers/)を同時に動かすこともできます。
+
+これはかなりの大きな作業で、ほとんど全てのKubernetesユーザーはスケジューラーを変更する必要はありません。
+
+スケジューラは[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド（スケジューラーエクステンション）を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* [カスタムリソース](/docs/concepts/api-extension/custom-resources/)についてより深く学ぶ
+* [動的Admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)について学ぶ
+* インフラストラクチャエクステンションについてより深く学ぶ
+  * [ネットワークプラグイン](/docs/concepts/cluster-administration/network-plugins/)
+  * [デバイスプラグイン](/docs/concepts/cluster-administration/device-plugins/)
+* [kubectlプラグイン](/docs/tasks/extend-kubectl/kubectl-plugins/)について学ぶ
+* [オペレーターパターン](/docs/concepts/extend-kubernetes/operator/)について学ぶ
+
+{{% /capture %}}
@@ -0,0 +1,97 @@
+---
+title: オペレーターパターン
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+オペレーターはサードパーティのアプリケーション、コンポーネントを管理するためのリソースを活用する、Kubernetesへのソフトウェア拡張です。
+オペレーターは、特に[制御ループ](/docs/concepts/#kubernetes-control-plane)のようなKubernetesが持つ仕組みに準拠しています。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## モチベーション
+
+オペレーターパターンはサービス、またはサービス群を管理している運用担当者の主な目的をキャプチャすることが目標です。
+特定のアプリケーション、サービスの面倒を見ている運用担当者は、システムがどのように振る舞うべきか、どのようにデプロイをするか、何らかの問題があったときにどのように対応するかについて深い知識を持っています。
+
+Kubernetes上でワークロードを稼働させている人は、しばしば繰り返し可能なタスクを自動化することを好みます。
+オペレーターパターンは、Kubernetes自身が提供している機能を超えて、あなたがタスクを自動化するために、どのようにコードを書くかをキャプチャします。
+
+## Kubernetesにおけるオペレーター
+
+Kubernetesは自動化のために設計されています。追加の作業、設定無しに、Kubernetesのコア機能によって多数のビルトインされた自動化機能が提供されます。
+ワークロードのデプロイ及び稼働を自動化するためにKubernetesを使うことができます。 *更に* Kubernetesがそれをどのように行うかの自動化も可能です。
+
+Kubernetesの{{< glossary_tooltip text="コントローラー" term_id="controller" >}}コンセプトは、Kubernetesのソースコードを修正すること無く、クラスターの振る舞いを拡張することを可能にします。
+オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。
+
+## オペレーターの例 {#example}
+
+オペレーターを使い自動化できるいくつかのことは、下記のようなものがあります:
+
+* 必要に応じてアプリケーションをデプロイする
+* アプリケーションの状態のバックアップを取得、リストアする
+* アプリケーションコードの更新と同時に、例えばデータベーススキーマ、追加の設定修正など必要な変更の対応を行う
+* Kubernetes APIをサポートしていないアプリケーションに、サービスを公開してそれらを発見する
+* クラスターの回復力をテストするために、全て、または一部分の障害をシミュレートする
+* 内部のリーダー選出プロセス無しに、分散アプリケーションのリーダーを選択する
+
+オペレーターをもっと詳しく見るとどのように見えるでしょうか？より詳細な例を示します:
+
+1. クラスターに設定可能なSampleDBという名前のカスタムリソース
+2. オペレーターの、コントローラー部分を含むPodが実行されていることを保証するDeployment
+3. オペレーターのコードを含んだコンテナイメージ
+4. 設定されているSampleDBのリソースを見つけるために、コントロールプレーンに問い合わせるコントローラーのコード
+5. オペレーターのコアは、現実を、設定されているリソースにどのように合わせるかをAPIサーバーに伝えるコードです。
+   * もし新しいSampleDBを追加した場合、オペレーターは永続化データベースストレージを提供するためにPersistentVolumeClaimsをセットアップし、StatefulSetがSampleDBの起動と、初期設定を担うJobを走らせます
+   * もしそれを削除した場合、オペレーターはスナップショットを取り、StatefulSetとVolumeも合わせて削除されたことを確認します
+6. オペレーターは定期的なデータベースのバックアップも管理します。それぞれのSampleDBリソースについて、オペレーターはデータベースに接続可能な、バックアップを取得するPodをいつ作成するかを決定します。これらのPodはデータベース接続の詳細情報、クレデンシャルを保持するConfigMapとSecret、もしくはどちらかに依存するでしょう。
+7. オペレーターは、管理下のリソースの堅牢な自動化を提供することを目的としているため、補助的な追加コードが必要になるかもしれません。この例では、データベースが古いバージョンで動いているかどうかを確認するコードで、その場合、アップグレードを行うJobをあなたに代わり作成します。
+
+## オペレーターのデプロイ
+
+オペレーターをデプロイする最も一般的な方法は、Custom Resource Definitionとそれに関連するコントローラーをクラスターに追加することです。
+このコントローラーは通常、あなたがコンテナアプリケーションを動かすのと同じように、{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}外で動作します。
+
+例えば、コントローラーをDeploymentとしてクラスター内で動かすことができます。
+
+## オペレーターを利用する {#using-operators}
+
+一度オペレーターをデプロイすると、そのオペレーターを使って、それ自身が使うリソースの種類を追加、変更、または削除できます。
+上記の利用例に従ってオペレーターそのもののためのDeploymentをセットアップし、以下のようなコマンドを実行します:
+
+```shell
+kubectl get SampleDB                   # 設定したデータベースを発見します
+
+kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更します
+```
+
+これだけです！オペレーターが変更の適用だけでなく既存のサービスがうまく稼働し続けるように面倒を見てくれます。
+
+## 自分でオペレーターを書く {#writing-operator}
+
+必要な振る舞いを実装したオペレーターがエコシステム内に無い場合、自分で作成することができます。
+[次の項目](#what-s-next)で、自分でクラウドネイティブオペレーターを作るときに利用できるライブラリやツールのリンクを見つけることができます。
+
+オペレーター（すなわち、コントローラー）はどの言語/ランタイムでも実装でき、[Kubernetes APIのクライアント](/docs/reference/using-api/client-libraries/)として機能させることができます。
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)をより深く学びます
+* ユースケースに合わせた、既製のオペレーターを[OperatorHub.io](https://operatorhub.io/)から見つけます
+* 自前のオペレーターを書くために既存のツールを使います、例:
+  * [KUDO](https://kudo.dev/)（Kubernetes Universal Declarative Operator）を使います
+  * [kubebuilder](https://book.kubebuilder.io/)を使います
+  * [Metacontroller](https://metacontroller.app/)を自分で実装したWebHooksと一緒に使います
+  * [Operator Framework](https://github.com/operator-framework/getting-started)を使います
+* 自前のオペレーターを他のユーザーのために[公開](https://operatorhub.io/)します
+* オペレーターパターンを紹介している[CoreOSオリジナル記事](https://coreos.com/blog/introducing-operators.html)を読みます
+* Google Cloudが出したオペレーター作成のベストプラクティス[記事](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)を読みます
+
+{{% /capture %}}
@@ -1,6 +1,5 @@
 ---
-reviewers:
-title: Kubernetesコンポーネント
+title: Kubernetesのコンポーネント
 content_template: templates/concept
 weight: 20
 card: 
@@ -9,18 +8,18 @@ card:
 ---

 {{% capture overview %}}
-
-このページでは、Kubernetesクラスターの機能を提供するために必要になる様々なコンポーネントを説明します。（実行ファイル形式で提供される）
-
+このドキュメントでは、Kubernetesクラスターが機能するために必要となるさまざまなコンポーネントの概要を説明します。
 {{% /capture %}}

 {{% capture body %}}

 ## マスターコンポーネント

-マスターコンポーネントは、クラスターのコントロールプレーンです。マスターコンポーネントはクラスターに関する全体的な決定を行い（例えばスケジューリングなど）、クラスターのイベントを検知し、それらに応答します（例えば、レプリケーションコントローラーの'replicas'フィールドが充足されていない場合、新しいPodを立ち上げます）。
+マスターコンポーネントは、クラスターのコントロールプレーンを提供します。
+マスターコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replica`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="pod" term_id="pod">}} を起動する等)。

-マスターコンポーネントは、クラスター内のどのマシン上でも動かすことが出来ます。しかし、話を簡単にするために、環境構築を行うスクリプトは通常、全てのマスターコンポーネントを同じマシン上で稼働させ、ユーザーのコンテナはそのマシンでは稼働させません。複数マスターマシン構成の構築例は、[高可用性クラスターを構築する](/docs/admin/high-availability/)を確認してください。
+マスターコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのマスターコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。
+マルチマスター VMセットアップの例については、[高可用性クラスターの構築](/docs/admin/high-availability/) を参照してください。

 ### kube-apiserver

@@ -38,31 +37,32 @@ card:

 {{< glossary_definition term_id="kube-controller-manager" length="all" >}}

-コントローラーには下記のものがあります:
+コントローラーには以下が含まれます。

-  * ノードコントローラー: ノードがダウンした場合に、通知と応答を行います。
-  * レプリケーションコントローラー: それぞれのレプリケーションコントローラーオブジェクト内に、正しい数のポッドが存在しているかを管理します。
-  * エンドポイントコントローラー: エンドポイントを設定します。（これは、サービスとPodを結合するということです）
-  * サービスアカウント & トークンコントローラー: 新しい名前空間にデフォルトアカウントとAPIアクセストークンを作成します。
+  * ノードコントローラー：ノードがダウンした場合の通知と対応を担当します。
+  * レプリケーションコントローラー：システム内の全レプリケーションコントローラーオブジェクトについて、Podの数を正しく保つ役割を持ちます。
+  * エンドポイントコントローラー：エンドポイントオブジェクトを注入します(つまり、ServiceとPodを紐付けます)。
+  * サービスアカウントとトークンコントローラー：新規の名前空間に対して、デフォルトアカウントとAPIアクセストークンを作成します。

-### クラウドコントローラーマネージャー（cloud-controller-manager）
+### cloud-controller-manager

-[クラウドコントローラーマネージャー](/docs/tasks/administer-cluster/running-cloud-controller/)は、基盤となるクラウドサービスと連携するコントローラーを動かします。クラウドコントローラーマネージャーはKubernetes 1.6でリリースされたアルファの機能です。
+[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) は、基盤であるクラウドプロバイダーと対話するコントローラーを実行します。
+cloud-controller-managerバイナリは、Kubernetesリリース1.6で導入された機能です。

-クラウドコントローラーマネージャーは、クラウドサービス固有の制御ループのみを動かします。これらの制御ループは kube-controller-manager から無効にしなければなりません。無効にするには、kube-controller-managerの起動時に、`--cloud-provider`フラグに`external`を指定します。
+cloud-controller-managerは、クラウドプロバイダー固有のコントローラーループのみを実行します。これらのコントローラーループはkube-controller-managerで無効にする必要があります。 kube-controller-managerの起動時に `--cloud-provider` フラグを `external` に設定することで、コントローラーループを無効にできます。

-クラウドコントローラーマネージャーは、クラウドベンダー固有のコードと、Kubernetes本体のコードを独立して開発することを可能にします。以前のリリースでは、Kubernetes本体のコードがクラウドサービス固有のコードに機能的に依存していました。将来のリリースでは、クラウドベンダー固有のコードはクラウドベンダー自身が保持し、Kubernetesが稼働している時にクラウドコントローラーマネージャーに紐付けられるようになっていきます。
+cloud-controller-managerを使用すると、クラウドベンダーのコードとKubernetesコードを互いに独立して進化させることができます。以前のリリースでは、コアKubernetesコードは、機能的にクラウドプロバイダー固有のコードに依存していました。将来のリリースでは、クラウドベンダーに固有のコードはクラウドベンダー自身で管理し、Kubernetesの実行中にcloud-controller-managerにリンクする必要があります。

-以下のコントローラーがクラウドサービスとの依存関係を持っています:
+次のコントローラーには、クラウドプロバイダーへの依存関係があります。

-  * ノードコントローラー: クラウドから応答が無くなった後、ノードが削除されていないかを確認します。
-  * ルートコントローラー: クラウド基盤にルーティング情報を設定します。
-  * サービスコントローラー: クラウドサービス上のロードバランサーを作成、更新、削除します。
-  * ボリュームコントローラー: ボリュームを作成、アタッチ、マウント、またクラウドサービスと連携し、ボリュームを編成します。
+  * ノードコントローラー：ノードが応答を停止した後、クラウドで削除されたかどうかを判断するため、クラウドプロバイダーをチェックします。
+  * ルーティングコントローラー：基盤であるクラウドインフラでルーティングを設定します。
+  * サービスコントローラー：クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。
+  * ボリュームコントローラー：ボリュームを作成、アタッチ、マウントしたり、クラウドプロバイダーとやり取りしてボリュームを調整したりします。

 ## ノードコンポーネント

-ノードコンポーネントは全てのノード上で稼働し、稼働中Podの管理、Kubernetes実行環境を提供します。
+ノードコンポーネントはすべてのノードで実行され、稼働中のPodの管理やKubernetesの実行環境を提供します。

 ### kubelet

@@ -70,38 +70,43 @@ card:

 ### kube-proxy

-[kube-proxy](/docs/admin/kube-proxy/)は、ホスト上のネットワークルールを管理し、コネクションの転送を行うことで、Kubernetesサービスの抽象化を可能にします。
+{{< glossary_definition term_id="kube-proxy" length="all" >}}

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

-コンテナランタイムは、コンテナを稼働させる責務を持つソフトウェアです。
-Kubernetesはいくつかのランタイムをサポートしています: [Docker](http://www.docker.com)、[containerd](https://containerd.io)、[cri-o](https://cri-o.io/)、[rktlet](https://github.com/kubernetes-incubator/rktlet)、また[Kubernetes CRI (コンテナランタイムインターフェース)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)の実装があります。
+{{< glossary_definition term_id="container-runtime" length="all" >}}

 ## アドオン

-アドオンは、クラスターの機能群を実装したPodとサービスです。そのPodは、Deployment、レプリケーションコントローラーなどによって管理されるでしょう。名前空間に属するアドオンオブジェクトは、`kube-system`名前空間に作られます。
+アドオンはクラスター機能を実装するためにKubernetesリソース({{< glossary_tooltip term_id="daemonset" >}}、{{< glossary_tooltip term_id="deployment" >}}など)を使用します。
+アドオンはクラスターレベルの機能を提供しているため、アドオンのリソースで名前空間が必要なものは`kube-system`名前空間に属します。

-一部のアドオンを下記に示します。その他の利用可能なアドオンのリストは、[アドオン](/docs/concepts/cluster-administration/addons/)を確認してください。
+いくつかのアドオンについて以下で説明します。より多くの利用可能なアドオンのリストは、[アドオン](/docs/concepts/cluster-administration/addons/) をご覧ください。

 ### DNS

-厳密には他のアドオンは必須ではありませんが、多数の実例が依存しているため、全てのKubernetesクラスターは[クラスターDNS](/docs/concepts/services-networking/dns-pod-service/)を持つべきです。
+クラスターDNS以外のアドオンは必須ではありませんが、すべてのKubernetesクラスターは[クラスターDNS](/docs/concepts/services-networking/dns-pod-service/)を持つべきです。多くの使用例がクラスターDNSを前提としています。

-クラスターDNSはDNSサーバーで、あなたの環境で動いている他のDNSサーバーに加え、Kubernetesサービスで利用するDNSレコードも扱います。
+クラスターDNSは、環境内の他のDNSサーバーに加えて、KubernetesサービスのDNSレコードを提供するDNSサーバーです。
+
+Kubernetesによって開始されたコンテナは、DNS検索にこのDNSサーバーを自動的に含めます。

-Kubernetesから起動されたコンテナは、DNSの検索対象として、自動的にこのDNSサーバーを含めます。

 ### Web UI (ダッシュボード)

-[ダッシュボード](/docs/tasks/access-application-cluster/web-ui-dashboard/)は、汎用のKubernetesのクラスターを管理するためのWebベースのUIです。ユーザーはこれを用いて、クラスター上で稼働しているアプリケーション、またクラスターそのものの管理、トラブルシュートが可能です。
+[ダッシュボード](/docs/tasks/access-application-cluster/web-ui-dashboard/)は、Kubernetesクラスター用の汎用WebベースUIです。これによりユーザーはクラスターおよびクラスター内で実行されているアプリケーションについて、管理およびトラブルシューティングを行うことができます。

 ### コンテナリソース監視

-[コンテナリソース監視](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)は、コンテナに関する一般的な時系列のメトリクスをセントラルなデータベースに記録し、そのデータを閲覧するUIを提供します。
+[コンテナリソース監視](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)は、コンテナに関する一般的な時系列メトリックを中央データベースに記録します。また、そのデータを閲覧するためのUIを提供します。

-### クラスターレベルロギング
+### クラスターレベルログ

-[クラスターレベルロギング](/docs/concepts/cluster-administration/logging/)機構は、コンテナのログを、検索、閲覧のインターフェースを持ったセントラルなログ保管場所に保存します。
+[クラスターレベルログ](/docs/concepts/cluster-administration/logging/)メカニズムは、コンテナのログを、検索／参照インターフェイスを備えた中央ログストアに保存します。

 {{% /capture %}}
-
+{{% capture whatsnext %}}
+* [ノード](/docs/concepts/architecture/nodes/) について学ぶ
+* [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/) について学ぶ
+* etcdの公式 [ドキュメント](https://etcd.io/docs/) を読む
+{{% /capture %}}
@@ -0,0 +1,172 @@
+---
+title: Kubernetesオブジェクト管理
+content_template: templates/concept
+weight: 15
+---
+
+{{% capture overview %}}
+`kubectl`コマンドラインツールは、Kubernetesオブジェクトを作成、管理するためにいくつかの異なる方法をサポートしています。
+このドキュメントでは、それらの異なるアプローチごとの概要を提供します。
+Kubectlを使ったオブジェクト管理の詳細は、[Kubectl book](https://kubectl.docs.kubernetes.io)を参照してください。
+{{% /capture %}}
+
+{{% capture body %}}
+
+## 管理手法
+
+{{< warning >}}
+Kubernetesのオブジェクトは、いずれか一つの手法で管理してください。
+同じオブジェクトに対して、複数の手法を組み合わせた場合、未定義の挙動をもたらします。
+{{< /warning >}}
+
+| 管理手法                         | 何を対象にするか       | 推奨環境           | サポートライター     | 学習曲線       |
+|----------------------------------|------------------------|--------------------|----------------------|----------------|
+| 命令型コマンド                   | 現行のオブジェクト     | 開発用プロジェクト | 1+                   | 緩やか         |
+| 命令型オブジェクト設定           | 個々のファイル         | 本番用プロジェクト | 1                    | 中程度         |
+| 宣言型オブジェクト設定           | ファイルのディレクトリ | 本番用プロジェクト | 1+                   | 急             |
+
+## 命令型コマンド
+
+命令型コマンドを使う場合、ユーザーはクラスター内の現行のオブジェクトに対して処理を行います。
+ユーザーは`kubectl`コマンドに処理内容を引数、もしくはフラグで指定します。
+
+これはKubernetesの使い始め、またはクラスターに対して一度限りのタスクを行う際の最も簡単な手法です。
+なぜなら、この手法は現行のオブジェクトに対して直接操作ができ、以前の設定履歴は提供されないからです。
+
+### 例
+
+Deploymentオブジェクトを作成し、nginxコンテナの単一インスタンスを起動します:
+
+```sh
+kubectl run nginx --image nginx
+```
+
+同じことを異なる構文で行います:
+
+```sh
+kubectl create deployment nginx --image nginx
+```
+
+### トレードオフ
+
+オブジェクト設定手法に対する長所:
+
+- コマンドは簡潔、簡単に学ぶことができ、そして覚えやすいです
+- コマンドではクラスタの設定を変えるのに、わずか1ステップしか必要としません
+
+オブジェクト設定手法に対する短所:
+
+- コマンドは変更レビュープロセスと連携しません
+- コマンドは変更に伴う監査証跡を提供しません
+- コマンドは現行がどうなっているかという情報を除き、レコードのソースを提供しません
+- コマンドはオブジェクトを作成するためのテンプレートを提供しません
+
+## 命令型オブジェクト設定
+
+命令型オブジェクト設定では、kubectlコマンドに処理内容（create、replaceなど）、任意のフラグ、そして最低1つのファイル名を指定します。
+指定されたファイルは、YAMLまたはJSON形式でオブジェクトの全ての定義情報を含んでいなければいけません。
+
+オブジェクト定義の詳細は、[APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)を参照してください。
+
+{{< warning >}}
+命令型の`replace`コマンドは、既存の構成情報を新しく提供された設定に置き換え、設定ファイルに無いオブジェクトの全ての変更を削除します。
+このアプローチは、構成情報が設定ファイルとは無関係に更新されるリソースタイプでは使用しないでください。
+例えば、タイプが`LoadBalancer`のServiceオブジェクトにおける`externalIPs`フィールドは、設定ファイルとは無関係に、クラスターによって更新されます。
+{{< /warning >}}
+
+### 例
+
+設定ファイルに定義されたオブジェクトを作成します:
+
+```sh
+kubectl create -f nginx.yaml
+```
+
+設定ファイルに定義されたオブジェクトを削除します:
+
+```sh
+kubectl delete -f nginx.yaml -f redis.yaml
+```
+
+設定ファイルに定義された情報で、現行の設定を上書き更新します:
+
+```sh
+kubectl replace -f nginx.yaml
+```
+
+### トレードオフ
+
+命令型コマンド手法に対する長所:
+
+- オブジェクト設定をGitのような、ソースコード管理システムに格納することができます
+- オブジェクト設定の変更内容をプッシュする前にレビュー、監査証跡を残すようなプロセスと連携することができます
+- オブジェクト設定は新しいオブジェクトを作る際のテンプレートを提供します
+
+命令型コマンド手法に対する短所:
+
+- オブジェクト設定ではオブジェクトスキーマの基礎的な理解が必要です
+- オブジェクト設定ではYAMLファイルを書くという、追加のステップが必要です
+
+宣言型オブジェクト設定手法に対する長所:
+
+- 命令型オブジェクト設定の振る舞いは、よりシンプルで簡単に理解ができます
+- Kubernetesバージョン1.5においては、命令型オブジェクト設定の方がより成熟しています
+
+宣言型オブジェクト設定手法に対する短所:
+
+- 命令型オブジェクト設定は各ファイルごとに設定を書くには最も適していますが、ディレクトリには適していません
+- 現行オブジェクトの更新は設定ファイルに対して反映しなければなりません。反映されない場合、次の置き換え時に更新内容が失われてしまいます
+
+## 宣言型オブジェクト設定
+
+宣言型オブジェクト設定を利用する場合、ユーザーはローカルに置かれている設定ファイルを操作します。
+しかし、ユーザーは操作内容をファイルに記載しません。作成、更新、そして削除といった操作はオブジェクトごとに`kubectl`が検出します。
+この仕組みが、異なるオブジェクトごとに異なる操作をディレクトリに対して行うことを可能にしています。
+
+{{< note >}}
+宣言型オブジェクト設定は、他の人が行った変更が設定ファイルにマージされなかったとしても、それらの変更を保持します。
+これは、`replace`API操作のように、全てのオブジェクト設定を置き換えるわけではなく、`patch`API操作による、変更箇所のみの更新が可能にしています。
+{{< /note >}}
+
+### 例
+
+`config`ディレクトリ配下にある全てのオブジェクト設定ファイルを処理し、作成、または現行オブジェクトへのパッチを行います。
+まず、`diff`でどのような変更が行われるかを確認した後に適用します:
+
+```sh
+kubectl diff -f configs/
+kubectl apply -f configs/
+```
+
+再帰的にディレクトリを処理します:
+
+```sh
+kubectl diff -R -f configs/
+kubectl apply -R -f configs/
+```
+
+### トレードオフ
+
+命令型オブジェクト設定手法に対する長所:
+
+- 現行オブジェクトに直接行われた変更が、それらが設定ファイルに反映されていなかったとしても、保持されます
+- 宣言型オブジェクト設定は、ディレクトリごとの処理をより良くサポートしており、自動的にオブジェクトごとに操作のタイプ（作成、パッチ、削除）を検出します
+
+命令型オブジェクト設定手法に対する短所:
+
+- 宣言型オブジェクト設定は、デバッグ、そして想定外の結果が出たときに理解するのが困難です
+- 差分を利用した一部のみの更新は、複雑なマージ、パッチの操作が必要です
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+- [命令型コマンドを利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-command/)
+- [オブジェクト設定（命令型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [オブジェクト設定（宣言型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/declarative-config/)
+- [Kustomize（宣言型）を利用したKubernetesオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/kustomization/)
+- [Kubectlコマンドリファレンス](/docs/reference/generated/kubectl/kubectl-commands/)
+- [Kubectl Book](https://kubectl.docs.kubernetes.io)
+- [Kubernetes APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+
+{{% /capture %}}
@@ -0,0 +1,5 @@
+---
+title: "スケジューリング"
+weight: 90
+---
+
@@ -0,0 +1,118 @@
+---
+title: Kubernetesのスケジューラー
+content_template: templates/concept
+weight: 60
+---
+
+{{% capture overview %}}
+
+Kubernetesにおいて、_スケジューリング_ とは、{{< glossary_tooltip term_id="kubelet" >}}が{{< glossary_tooltip text="Pod" term_id="pod" >}}を稼働させるために{{< glossary_tooltip text="Node" term_id="node" >}}に割り当てることを意味します。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## スケジューリングの概要{#scheduling}
+
+スケジューラーは新規に作成されたPodで、Nodeに割り当てられていないものを監視します。スケジューラーは発見した各Podのために、稼働させるべき最適なNodeを見つけ出す責務を担っています。そのスケジューラーは下記で説明するスケジューリングの原理を考慮に入れて、NodeへのPodの割り当てを行います。
+
+Podが特定のNodeに割り当てられる理由を理解したい場合や、カスタムスケジューラーを自身で作ろうと考えている場合、このページはスケジューリングに関して学ぶのに役立ちます。
+
+## kube-scheduler
+
+[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)はKubernetesにおけるデフォルトのスケジューラーで、{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}の一部分として稼働します。  
+kube-schedulerは、もし希望するのであれば自分自身でスケジューリングのコンポーネントを実装でき、それを代わりに使用できるように設計されています。
+
+kube-schedulerは、新規に作成された各Podや他のスケジューリングされていないPodを稼働させるために最適なNodeを選択します。  
+しかし、Pod内の各コンテナにはそれぞれ異なるリソースの要件があり、各Pod自体にもそれぞれ異なる要件があります。そのため、既存のNodeは特定のスケジューリング要求によってフィルターされる必要があります。
+
+クラスター内でPodに対する割り当て要求を満たしたNodeは_割り当て可能_ なNodeと呼ばれます。  
+もし適切なNodeが一つもない場合、スケジューラーがNodeを割り当てることができるまで、そのPodはスケジュールされずに残ります。
+
+スケジューラーはPodに対する割り当て可能なNodeをみつけ、それらの割り当て可能なNodeにスコアをつけます。その中から最も高いスコアのNodeを選択し、Podに割り当てるためのいくつかの関数を実行します。  
+スケジューラーは_binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったNodeの情報を通知します。
+
+スケジューリングを決定する上で考慮が必要な要素としては、個別または複数のリソース要求や、ハードウェア/ソフトウェアのポリシー制約、affinityやanti-affinityの設定、データの局所性や、ワークロード間での干渉などが挙げられます。
+
+## kube-schedulerによるスケジューリング{#kube-scheduler-implementation}
+
+kube-schedulerは2ステップの操作によってPodに割り当てるNodeを選択します。
+
+1. フィルタリング
+
+2. スコアリング
+
+_フィルタリング_ ステップでは、Podに割り当て可能なNodeのセットを探します。例えばPodFitsResourcesフィルターは、Podのリソース要求を満たすのに十分なリソースをもつNodeがどれかをチェックします。このステップの後、候補のNodeのリストは、要求を満たすNodeを含みます。  
+たいてい、リストの要素は複数となります。もしこのリストが空の場合、そのPodはスケジュール可能な状態とはなりません。
+
+_スコアリング_ ステップでは、Podを割り当てるのに最も適したNodeを選択するために、スケジューラーはリストの中のNodeをランク付けします。  
+スケジューラーは、フィルタリングによって選ばれた各Nodeに対してスコアを付けます。このスコアはアクティブなスコア付けのルールに基づいています。
+
+最後に、kube-schedulerは最も高いランクのNodeに対してPodを割り当てます。もし同一のスコアのNodeが複数ある場合は、kube-schedulerがランダムに1つ選択します。
+
+### デフォルトのポリシーについて
+
+kube-schedulerは、デフォルトで用意されているスケジューリングポリシーのセットを持っています。
+
+### フィルタリング
+
+- `PodFitsHostPorts`: Nodeに、Podが要求するポートが利用可能かどうかをチェックします。  
+
+- `PodFitsHost`: Podがそのホスト名において特定のNodeを指定しているかをチェックします。
+
+- `PodFitsResources`: Nodeに、Podが要求するリソース(例: CPUとメモリー)が利用可能かどうかをチェックします。
+
+- `PodMatchNodeSelector`: PodのNodeSelectorが、Nodeのラベルにマッチするかどうかをチェックします。
+
+- `NoVolumeZoneConflict`: Podが要求するVolumeがNode上で利用可能かを、障害が発生しているゾーンを考慮して評価します。
+
+- `NoDiskConflict`: NodeのVolumeがPodの要求を満たし、すでにマウントされているかどうかを評価します。
+
+- `MaxCSIVolumeCount`: CSI Volumeをいくつ割り当てるべきか決定し、それが設定された上限を超えるかどうかを評価します。
+
+- `CheckNodeMemoryPressure`: もしNodeがメモリーの容量が逼迫している場合、また設定された例外がない場合はそのPodはそのNodeにスケジュールされません。
+
+- `CheckNodePIDPressure`: もしNodeのプロセスIDが枯渇しそうになっていた場合や、設定された例外がない場合はそのPodはそのNodeにスケジュールされません。
+
+- `CheckNodeDiskPressure`: もしNodeのストレージが逼迫している場合(ファイルシステムの残り容量がほぼない場合)や、設定された例外がない場合はそのPodはそのNodeにスケジュールされません。
+
+- `CheckNodeCondition`: Nodeは、ファイルシステムの空き容量が完全になくなった場合、ネットワークが利用不可な場合、kubeletがPodを稼働させる準備をできていない場合などに、その状況を通知できます。Nodeがこの状況下かつ設定された例外がない場合、Podは該当のNodeにスケジュールされません。
+
+- `PodToleratesNodeTaints`: PodのTolerationがNodeのTaintを許容できるかチェックします。
+
+- `CheckVolumeBinding`: Podが要求するVolumeの要求を満たすか評価します。これはPersistentVolumeClaimがバインドされているかに関わらず適用されます。
+
+### スコアリング
+
+- `SelectorSpreadPriority`:　同一のService、StatefulSetや、ReplicaSetに属するPodを複数のホストをまたいで稼働させます。
+
+- `InterPodAffinityPriority`: weightedPodAffinityTermの要素をイテレートして合計を計算したり、もし一致するPodAffinityTermがNodeに適合している場合は、"重み"を合計値に足したりします。:最も高い合計値を持つNode(複数もあり)が候補となります。
+
+- `LeastRequestedPriority`: 要求されたリソースがより低いNodeを優先するものです。言い換えると、Nodeに多くのPodが稼働しているほど、Podが使用するリソースが多くなり、その要求量が低いNodeが選択されます。
+
+- `MostRequestedPriority`: 要求されたリソースがより多いNodeを優先するものです。このポリシーは、ワークロードの全体セットを実行するために必要な最小数のNodeに対して、スケジュールされたPodを適合させます。　
+
+- `RequestedToCapacityRatioPriority`: デフォルトのリソーススコアリング関数を使用して、requestedToCapacityベースのResourceAllocationPriorityを作成します。
+
+- `BalancedResourceAllocation`: バランスのとれたリソース使用量になるようにNodeを選択します。
+
+- `NodePreferAvoidPodsPriority`: Nodeの`scheduler.alpha.kubernetes.io/preferAvoidPods`というアノテーションに基づいてNodeの優先順位づけをします。この設定により、2つの異なるPodが同じNode上で実行しないことを示唆できます。
+
+- `NodeAffinityPriority`: "PreferredDuringSchedulingIgnoredDuringExecution"の値によって示されたNode Affinityのスケジューリング性向に基づいてNodeの優先順位づけを行います。詳細は[NodeへのPodの割り当て](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/)にて確認できます。
+
+- `TaintTolerationPriority`: Node上における許容できないTaintsの数に基づいて、全てのNodeの優先順位リストを準備します。このポリシーでは優先順位リストを考慮してNodeのランクを調整します。
+
+- `ImageLocalityPriority`: すでにPodに対するコンテナイメージをローカルにキャッシュしているNodeを優先します。
+
+- `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodが既に実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。
+
+- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。
+
+- `EqualPriorityMap`: 全てのNodeに対して等しい重みを与えます。
+
+{{% /capture %}}
+{{% capture whatsnext %}}
+* [スケジューラーのパフォーマンスチューニング](/docs/concepts/scheduling/scheduler-perf-tuning/)を参照してください。
+* kube-schedulerの[リファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。
+* [複数のスケジューラーの設定](https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。
+{{% /capture %}}
@@ -1,5 +1,4 @@
 ---
-title: "Services, Load Balancing, and Networking"
+title: "Service、負荷分散とネットワーキング"
 weight: 60
 ---
-
@@ -0,0 +1,909 @@
+---
+title: Service
+feature:
+  title: サービスディスカバリーと負荷分散
+  description: >
+    Kubernetesでは、なじみのないサービスディスカバリーの機構を使用するためにユーザーがアプリケーションの修正をする必要はありません。KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセットに対する単一のDNS名を提供したり、それらのPodのセットに対する負荷分散が可能です。
+
+content_template: templates/concept
+weight: 10
+---
+
+
+{{% capture overview %}}
+
+{{< glossary_definition term_id="service" length="short" >}}
+
+Kubernetesでは、なじみのないサービスディスカバリーの機構を使用するためにユーザーがアプリケーションの修正をする必要はありません。  
+KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセットに対する単一のDNS名を提供したり、それらのPodのセットに対する負荷分散が可能です。
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Serviceを利用する動機
+
+{{< glossary_tooltip term_id="pod" text="Pod" >}}は停止が想定して設計されています。 Podが作成され、もしそれらが停止する時、Podは再作成されません。
+{{< glossary_tooltip term_id="deployment" >}}をアプリケーションを稼働させるために使用すると、Podを動的に作成・削除してくれます。
+
+各Podはそれ自身のIPアドレスを持ちます。しかしDeploymentでは、ある時点において同時に稼働しているPodのセットは、その後のある時点において稼働しているPodのセットとは異なる場合があります。
+
+この仕組みはある問題を引き起こします。もし、あるPodのセット(ここでは"バックエンド"と呼びます)がクラスター内で他のPodのセット(ここでは"フロントエンド"と呼びます)に対して機能を提供する場合、フロントエンドのPodがワークロードにおけるバックエンドを使用するために、バックエンドのPodのIPアドレスを探し出したり、記録し続けるためにはどうすればよいでしょうか?  
+
+ここで_Service_ について説明します。
+
+## Serviceリソース {#service-resource}
+
+Kubernetesにおいて、ServiceはPodの論理的なセットや、そのPodのセットにアクセスするためのポリシーを定義します(このパターンはよくマイクロサービスと呼ばることがあります)。  
+ServiceによってターゲットとされたPodのセットは、たいてい {{< glossary_tooltip text="セレクター" term_id="selector" >}} (セレクターなしのServiceを利用したい場合は[下記](#services-without-selectors)を参照してください)によって定義されます。  
+
+例えば、3つのレプリカが稼働しているステートレスな画像処理用のバックエンドを考えます。これらのレプリカは代替可能です。&mdash; フロントエンドはバックエンドが何であろうと気にしません。バックエンドのセットを構成する実際のPodのセットが変更された際、フロントエンドクライアントはその変更を気にしたり、バックエンドのPodのセットの情報を記録しておく必要はありません。
+
+Serviceによる抽象化は、クライアントからバックエンドのPodの管理する責務を分離することを可能にします。
+
+### クラウドネイティブのサービスディスカバリー
+
+アプリケーション内でサービスディスカバリーのためにKubernetes APIが使える場合、ユーザーはエンドポイントを{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}に問い合わせることができ、またService内のPodのセットが変更された時はいつでも更新されたエンドポイントの情報を取得できます。
+
+非ネイティブなアプリケーションのために、KubernetesはアプリケーションとバックエンドPodの間で、ネットワークポートやロードバランサーを配置する方法を提供します。 
+
+## Serviceの定義
+
+KubernetesのServiceはPodと同様にRESTのオブジェクトです。他のRESTオブジェクトと同様に、ユーザーはServiceの新しいインスタンスを作成するためにAPIサーバーに対してServiceの定義を`POST`できます。
+
+例えば、TCPで9376番ポートで待ち受けていて、`app=Myapp`というラベルをもつPodのセットがあるとします。
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: MyApp
+  ports:
+  - protocol: TCP
+    port: 80
+    targetPort: 9376
+```
+
+この定義では、"my-service"という名前のついた新しいServiceオブジェクトを作成します。これは`app=Myapp`ラベルのついた各Pod上でTCPの9376番ポートをターゲットとします。
+
+Kubernetesは、このServiceに対してIPアドレス("clusterIP"とも呼ばれます)を割り当てます。これはServiceのプロキシーによって使用されます(下記の[仮想IPとServiceプロキシー](#virtual-ips-and-service-proxies)を参照ください)。
+
+Serviceセレクターのコントローラーはセレクターに一致するPodを継続的にスキャンし、“my-service”という名前のEndpointオブジェクトに対して変更をPOSTします。
+
+{{< note >}}
+Serviceは`port`から`targetPort`へのマッピングを行います。デフォルトでは、利便性のために`targetPort`フィールドは`port`フィールドと同じ値で設定されます。
+{{< /note >}}
+
+Pod内のポートの定義は名前を設定でき、Serviceの`targetPort`属性にてその名前を参照できます。これは単一の設定名をもつService内で、複数の種類のPodが混合していたとしても有効で、異なるポート番号を介することによって利用可能な、同一のネットワークプロトコルを利用します。
+この仕組みはServiceをデプロイしたり、設定を追加する場合に多くの点でフレキシブルです。例えば、バックエンドソフトウェアにおいて、次のバージョンでPodが公開するポート番号を変更するときに、クライアントの変更なしに行えます。
+
+ServiceのデフォルトプロトコルはTCPです。また、他の[サポートされているプロトコル](#protocol-support)も利用可能です。
+
+多くのServiceが、1つ以上のポートを公開する必要があるように、Kubernetesは1つのServiceオブジェクトに対して複数のポートの定義をサポートしています。  
+各ポート定義は同一の`protocol`または異なる値を設定できます。
+
+### セレクターなしのService {#services-without-selectors}
+
+Serviceは多くの場合、KubernetesのPodに対するアクセスを抽象化しますが、他の種類のバックエンドも抽象化できます。
+例えば:
+
+  * プロダクション環境で外部のデータベースクラスターを利用したいが、テスト環境では、自身のクラスターが持つデータベースを利用したい場合
+  * Serviceを、異なるNamespace内のServiceや他のクラスターのServiceに向ける場合
+  * ワークロードをKubernetesに移行するとき、アプリケーションに対する処理をしながら、バックエンドの一部をKubernetesで実行する場合
+
+このような場合において、ユーザーはPodセレクター_なしで_ Serviceを定義できます。  
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  ports:
+  - protocol: TCP
+    port: 80
+    targetPort: 9376
+```
+
+このServiceはセレクターがないため、対応するEndpointオブジェクトは自動的に作成されません。  
+ユーザーはEndpointオブジェクトを手動で追加することにより、向き先のネットワークアドレスとポートを手動でマッピングできます。
+
+```yaml
+apiVersion: v1
+kind: Endpoints
+metadata:
+  name: my-service
+subsets:
+  - addresses:
+      - ip: 192.0.2.42
+    ports:
+      - port: 9376
+```
+
+{{< note >}}
+Endpointのipは、loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), や
+link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6)に設定することができません。
+
+{{< glossary_tooltip term_id="kube-proxy" >}}が仮想IPを最終的な到達先に設定することをサポートしていないため、Endpointのipアドレスは他のKubernetes ServiceのClusterIPにすることができません。
+{{< /note >}}
+
+セレクターなしのServiceへのアクセスは、セレクターをもっているServiceと同じようにふるまいます。上記の例では、トラフィックはYAMLファイル内で`192.0.2.42:9376` (TCP)で定義された単一のエンドポイントにルーティングされます。
+
+ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊なケースのServiceです。さらなる情報は、このドキュメントの後で紹介する[ExternalName](#externalname)を参照ください。
+
+## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies}
+
+Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。`kube-proxy`は[`ExternalName`](#externalname)タイプ以外の`Service`用に仮想IPを実装する責務があります。
+
+### なぜ、DNSラウンドロビンを使わないのでしょうか。
+
+ここで湧き上がる質問として、なぜKubernetesは内部のトラフィックをバックエンドへ転送するためにプロキシーに頼るのでしょうか。  
+他のアプローチはどうなのでしょうか。例えば、複数のAバリュー(もしくはIPv6用にAAAAバリューなど)をもつDNSレコードを設定し、ラウンドロビン方式で名前を解決することは可能でしょうか。
+
+Serviceにおいてプロキシーを使う理由はいくつかあります。
+
+ * DNSの実装がレコードのTTLをうまく扱わず、期限が切れた後も名前解決の結果をキャッシュするという長い歴史がある。
+ * いくつかのアプリケーションではDNSルックアップを1度だけ行い、その結果を無期限にキャッシュする。
+ * アプリケーションとライブラリーが適切なDNS名の再解決を行ったとしても、DNSレコード上の0もしくは低い値のTTLがDNSに負荷をかけることがあり、管理が難しい。
+
+### バージョン互換性
+
+Kubernetes v1.0から、[user-spaceプロキシーモード](#proxy-mode-userspace)を利用できるようになっています。  
+v1.1ではiptablesモードでのプロキシーを追加し、v1.2では、kube-proxyにおいてiptablesモードがデフォルトとなりました。  
+v1.8では、ipvsプロキシーモードが追加されました。
+
+### user-spaceプロキシーモード {#proxy-mode-userspace}
+
+このモードでは、kube-proxyはServiceやEndpointオブジェクトの追加・削除をチェックするために、Kubernetes Masterを監視します。  
+各Serviceは、ローカルのNode上でポート(ランダムに選ばれたもの)を公開します。この"プロキシーポート"に対するどのようなリクエストも、そのServiceのバックエンドPodのどれか1つにプロキシーされます(Endpointを介して通知されたPodに対して)。  
+kube-proxyは、どのバックエンドPodを使うかを決める際にServiceの`SessionAffinity`項目の設定を考慮に入れます。  
+
+最後に、user-spaceプロキシーはServiceの`clusterIP`(仮想IP)と`port`に対するトラフィックをキャプチャするiptablesルールをインストールします。  
+そのルールは、トラフィックをバックエンドPodにプロキシーするためのプロキシーポートにリダイレクトします。
+
+デフォルトでは、user-spaceモードにおけるkube-proxyはラウンドロビンアルゴリズムによってバックエンドPodを選択します。
+
+![user-spaceプロキシーのService概要ダイアグラム](/images/docs/services-userspace-overview.svg)
+
+### `iptables`プロキシーモード {#proxy-mode-iptables}
+
+このモードでは、kube-proxyはServiceやEndpointオブジェクトの追加・削除のチェックのためにKubernetesコントロールプレーンを監視します。  
+各Serviceでは、そのServiceの`clusterIP`と`port`に対するトラフィックをキャプチャするiptablesルールをインストールし、そのトラフィックをServiceのあるバックエンドのセットに対してリダイレクトします。  
+各Endpointオブジェクトは、バックエンドのPodを選択するiptablesルールをインストールします。  
+
+デフォルトでは、iptablesモードにおけるkube-proxyはバックエンドPodをランダムで選択します。  
+
+トラフィックのハンドリングのためにiptablesを使用すると、システムのオーバーヘッドが少なくなります。これは、トラフィックがLinuxのnetfilterによってuser-spaceとkernel-spaceを切り替える必要がないためです。  
+このアプローチは、オーバーヘッドが少ないことに加えて、より信頼できる方法でもあります。  
+
+kube-proxyがiptablesモードで稼働し、最初に選択されたPodが応答しない場合、そのコネクションは失敗します。  
+これはuser-spaceモードでの挙動と異なります: user-spaceモードにおいては、kube-proxyは最初のPodに対するコネクションが失敗したら、自動的に他のバックエンドPodに対して再接続を試みます。
+
+iptablesモードのkube-proxyが正常なバックエンドPodのみをリダイレクト対象とするために、Podの[ReadinessProbe](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を使用してバックエンドPodが正常に動作しているか確認できます。これは、ユーザーがkube-proxyを介して、コネクションに失敗したPodに対してトラフィックをリダイレクトするのを除外することを意味します。  
+
+![iptablesプロキシーのService概要ダイアグラム](/images/docs/services-iptables-overview.svg)
+
+### IPVSプロキシーモード {#proxy-mode-ipvs}
+
+{{< feature-state for_k8s_version="v1.11" state="stable" >}}
+
+`ipvs`モードにおいて、kube-proxyはServiceとEndpointオブジェクトを監視し、IPVSルールを作成するために`netlink`インターフェースを呼び出し、定期的にKubernetesのServiceとEndpointとIPVSルールを同期させます。  
+このコントロールループはIPVSのステータスが理想的な状態になることを保証します。  
+Serviceにアクセスするとき、IPVSはトラフィックをバックエンドのPodに向けます。
+
+IPVSプロキシーモードはiptablesモードと同様に、netfilterのフック関数に基づいています。ただし、基礎となるデータ構造としてハッシュテーブルを使っているのと、kernel-spaceで動作します。  
+これは、IPVSモードにおけるkube-proxyはiptablesモードに比べてより低いレイテンシーでトラフィックをリダイレクトし、プロキシーのルールを同期する際にはよりパフォーマンスがよいことを意味します。　　
+他のプロキシーモードと比較して、IPVSモードはより高いネットワークトラフィックのスループットをサポートしています。  
+
+IPVSはバックエンドPodに対するトラフィックのバランシングのために多くのオプションを下記のとおりに提供します。  
+
+- `rr`: ラウンドロビン
+- `lc`: 最低コネクション数(オープンされているコネクション数がもっとも小さいもの)
+- `dh`: 送信先IPによって割り当てられたハッシュ値をもとに割り当てる(Destination Hashing)
+- `sh`: 送信元IPによって割り当てられたハッシュ値をもとに割り当てる(Source Hashing)
+- `sed`: 見込み遅延が最小なもの
+- `nq`: キューなしスケジューリング
+
+{{< note >}}
+IPVSモードでkube-proxyを稼働させるためには、kube-proxyを稼働させる前にNode上でIPVSを有効にしなければなりません。
+
+kube-proxyはIPVSモードで起動する場合、IPVSカーネルモジュールが利用可能かどうかを確認します。  
+もしIPVSカーネルモジュールが見つからなかった場合、kube-proxyはiptablesモードで稼働するようにフォールバックされます。
+{{< /note >}}
+
+![IPVSプロキシーのService概要ダイアグラム](/images/docs/services-ipvs-overview.svg)
+
+このダイアグラムのプロキシーモデルにおいて、ServiceのIP:Portに対するトラフィックは、クライアントがKubernetesのServiceやPodについて何も知ることなく適切にバックエンドにプロキシーされています。
+
+特定のクライアントからのコネクションが、毎回同一のPodにリダイレクトされるようにするためには、`service.spec.sessionAffinity`を"ClientIP"にセットすることにより、クライアントのIPアドレスに基づいたSessionAffinityを選択することができます(デフォルトは"None")。
+また、`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`を適切に設定することにより、セッションのタイムアウト時間を設定できます(デフォルトではこの値は18,000で、3時間となります)。
+
+## 複数のポートを公開するService  
+
+いくつかのServiceにおいて、ユーザーは1つ以上のポートを公開する必要があります。Kubernetesは、Serviceオブジェクト上で複数のポートを定義するように設定できます。  
+Serviceで複数のポートを使用するとき、どのポートかを明確にするために、複数のポート全てに対して名前をつける必要があります。
+例えば:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: MyApp
+  ports:
+  - name: http
+    protocol: TCP
+    port: 80
+    targetPort: 9376
+  - name: https
+    protocol: TCP
+    port: 443
+    targetPort: 9377
+```
+
+{{< note >}}
+KubernetesのPod名と同様に、ポート名は小文字の英数字と`-`のみ含める必要があります。また、ポート名の最初と最後の文字は英数字である必要があります。
+
+例えば、`123-abc`や`web`という名前は有効で、`123_abc`や`-web`は無効です。
+{{< /note >}}
+
+## ユーザー所有のIPアドレスを選択する
+
+`Service`を作成するリクエストの一部として、ユーザー所有のclusterIPアドレスを指定することができます。  
+これを行うためには`.spec.clusterIP`フィールドにセットします。  
+使用例として、もしすでに再利用したいDNSエントリーが存在していた場合や、特定のIPアドレスを設定されたレガシーなシステムや、IPの再設定が難しい場合です。
+
+ユーザーが指定したIPアドレスは、そのAPIサーバーのために設定されている`service-cluster-ip-range`というCIDRレンジ内の有効なIPv4またはIPv6アドレスである必要があります。  
+もし無効なclusterIPアドレスの値を設定してServiceを作成した場合、問題があることを示すためにAPIサーバーはHTTPステータスコード422を返します。
+
+## サービスディスカバリー 
+
+Kubernetesは、Serviceオブジェクトを見つけ出すために2つの主要なモードをサポートしています。 - それは環境変数とDNSです。
+
+### 環境変数
+
+PodがNode上で稼働するとき、kubeletはアクティブな各Serviceに対して、環境変数のセットを追加します。
+これは[Docker links互換性](https://docs.docker.com/userguide/dockerlinks/)のある変数(
+[makeLinkVariables関数](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。
+
+例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`"redis-master"`というServiceは、下記のような環境変数を生成します。
+
+```shell
+REDIS_MASTER_SERVICE_HOST=10.0.0.11
+REDIS_MASTER_SERVICE_PORT=6379
+REDIS_MASTER_PORT=tcp://10.0.0.11:6379
+REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
+REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
+REDIS_MASTER_PORT_6379_TCP_PORT=6379
+REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
+```
+
+{{< note >}}
+Serviceにアクセスする必要のあるPodがあり、クライアントであるそのPodに対して環境変数を使ってポートとclusterIPを公開する場合、クライアントのPodが存在する*前に* Serviceを作成しなくてはなりません。  
+そうでない場合、クライアントのPodはそれらの環境変数を作成しません。  
+
+ServiceのclusterIPを発見するためにDNSのみを使う場合、このような問題を心配する必要はありません。
+{{< /note >}}
+
+### DNS
+
+ユーザーは[アドオン](/docs/concepts/cluster-administration/addons/)を使ってKubernetesクラスターにDNS Serviceをセットアップできます(常にセットアップすべきです)。
+
+CoreDNSなどのクラスター対応のDNSサーバーは新しいServiceや、各Service用のDNSレコードのセットのためにKubernetes APIを常に監視します。  
+もしクラスターを通してDNSが有効になっている場合、全てのPodはDNS名によって自動的にServiceに対する名前解決をするようにできるはずです。
+
+例えば、Kubernetesの`"my-ns"`というNamespace内で`"my-service"`というServiceがある場合、KubernetesコントロールプレーンとDNS Serviceが協調して動作し、`"my-service.my-ns"`というDNSレコードを作成します。  
+`"my-ns"`というNamespace内のPodは`my-service`という名前で簡単に名前解決できるはずです(`"my-service.my-ns"`でも動作します)。
+
+他のNamespace内でのPodは`my-service.my-ns`といった形で指定しなくてはなりません。これらのDNS名は、そのServiceのclusterIPに名前解決されます。
+
+Kubernetesは名前付きのポートに対するDNS SRV(Service)レコードもサポートしています。もし`"my-service.my-ns"`というServiceが`"http"`という名前のTCPポートを持っていた場合、IPアドレスと同様に、`"http"`のポート番号を探すために`_http._tcp.my-service.my-ns`というDNS SRVクエリを実行できます。
+
+KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一の方法です。  
+[DNS Pods と Service](/docs/concepts/services-networking/dns-pod-service/)にて`ExternalName`による名前解決に関するさらなる情報を確認できます。
+
+## Headless Service {#headless-service}
+
+場合によっては、負荷分散と単一のService IPは不要です。このケースにおいて、clusterIP(`.spec.clusterIP`)の値を`"None"`に設定することにより、"Headless"とよばれるServiceを作成できます。
+
+ユーザーは、Kubernetesの実装と紐づくことなく、他のサービスディスカバリーのメカニズムと連携するためにHeadless Serviceを使用できます。  
+例えば、ユーザーはこのAPI上でカスタム{{< glossary_tooltip term_id="operator-pattern" text="オペレーター" >}}を実装することができます。
+
+この`Service`においては、clusterIPは割り当てられず、kube-proxyはこのServiceをハンドリングしないのと、プラットフォームによって行われるはずの
+ロードバランシングやプロキシーとしての処理は行われません。DNSがどのように自動で設定されるかは、定義されたServiceが定義されたラベルセレクターを持っているかどうかに依存します。  
+
+### ラベルセレクターの利用
+
+ラベルセレクターを定義したHeadless Serviceにおいて、EndpointコントローラーはAPIにおいて`Endpoints`レコードを作成し、`Service`のバックエンドにある`Pod`へのIPを直接指し示すためにDNS設定を修正します。
+
+### ラベルセレクターなしの場合
+
+ラベルセレクターを定義しないHeadless Serviceにおいては、Endpoint コントローラーは`Endpoint`レコードを作成しません。  
+しかしDNSのシステムは下記の2つ両方を探索し、設定します。
+
+  * [`ExternalName`](#externalname)タイプのServiceに対するCNAMEレコード
+  * 他の全てのServiceタイプを含む、Service名を共有している全ての`Endpoint`レコード
+
+## Serviceの公開 (Serviceのタイプ) {#publishing-services-service-types}
+
+ユーザーのアプリケーションのいくつかの部分において(例えば、frontendsなど)、ユーザーのクラスターの外部にあるIPアドレス上でServiceを公開したい場合があります。
+
+Kubernetesの`ServiceTypes`によって、ユーザーがどのような種類のServiceを使いたいかを指定することが可能です。  
+デフォルトでは`ClusterIP`となります。
+
+`Type`項目の値と、そのふるまいは以下のようになります。
+
+   * `ClusterIP`: クラスター内部のIPでServiceを公開する。このタイプではServiceはクラスター内部からのみ疎通性があります。このタイプはデフォルトの`ServiceType`です。
+   * [`NodePort`](#nodeport): 各NodeのIPにて、静的なポート(`NodePort`)上でServiceを公開します。その`NodePort` のServiceが転送する先の`ClusterIP` Serviceが自動的に作成されます。`<NodeIP>:<NodePort>`にアクセスすることによって`NodePort` Serviceにアクセスできるようになります。  
+   * [`LoadBalancer`](#loadbalancer): クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開します。クラスター外部にあるロードバランサーが転送する先の`NodePort`と`ClusterIP` Serviceは自動的に作成されます。
+   * [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。
+
+     {{< note >}}
+     `ExternalName`タイプのServiceを利用するためには、CoreDNSのバージョン1.7以上が必要となります。
+     {{< /note >}}
+
+また、Serviceを公開するために[Ingress](/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。  
+Ingressは同一のIPアドレスにおいて、複数のServiceを公開するように、ユーザーの設定した転送ルールを1つのリソースにまとめることができます。
+
+### NodePort タイプ {#nodeport}
+
+もし`type`フィールドの値を`NodePort`に設定すると、Kubernetesコントロールプレーンは`--service-node-port-range`フラグによって指定されたレンジのポート(デフォルト: 30000-32767)を割り当てます。  
+各Nodeはそのポート(各Nodeで同じポート番号)への通信をServiceに転送します。  
+作成したServiceは、`.spec.ports[*].nodePort`フィールド内に割り当てられたポートを記述します。  
+
+もしポートへの通信を転送する特定のIPを指定したい場合、特定のIPブロックをkube-proxyの`--nodeport-address`フラグで指定できます。これはKubernetesv1.10からサポートされています。  
+このフラグは、コンマ区切りのIPブロックのリスト(例: 10.0.0./8, 192.0.2.0/25)を使用し、kube-proxyがこのNodeに対してローカルとみなすべきIPアドレスの範囲を指定します。  
+
+例えば、`--nodeport-addresses=127.0.0.0/8`というフラグによってkube-proxyを起動した時、kube-proxyはNodePort Serviceのためにループバックインターフェースのみ選択します。`--nodeport-addresses`のデフォルト値は空のリストになります。これはkube-proxyがNodePort Serviceに対して全てのネットワークインターフェースを利用可能とするべきということを意味します(これは以前のKubernetesのバージョンとの互換性があります)。  
+
+もしポート番号を指定したい場合、`nodePort`フィールドに値を指定できます。コントロールプレーンは指定したポートを割り当てるか、APIトランザクションが失敗したことを知らせるかのどちらかになります。  
+これは、ユーザーが自分自身で、ポート番号の衝突に関して気をつける必要があることを意味します。  
+また、ユーザーは有効なポート番号を指定する必要があり、NodePortの使用において、設定された範囲のポートを指定する必要があります。
+
+NodePortの使用は、Kubernetesによって完全にサポートされていないようなユーザー独自の負荷分散を設定をするための有効な方法や、1つ以上のNodeのIPを直接公開するための方法となりえます。
+
+注意点として、このServiceは`<NodeIP>:spec.ports[*].nodePort`と、`.spec.clusterIP:spec.ports[*].port`として疎通可能です。  
+(もしkube-proxyにおいて`--nodeport-addressses`が設定された場合、<NodeIP>はフィルターされたNodeIPとなります。)
+
+### LoadBalancer タイプ {#loadbalancer}
+
+外部のロードバランサーをサポートするクラウドプロバイダー上で、`type`フィールドに`LoadBalancer`を設定すると、Service用にロードバランサーがプロビジョニングされます。  
+実際のロードバランサーの作成は非同期で行われ、プロビジョンされたバランサーの情報は、Serviceの`.status.loadBalancer`フィールドに記述されます。  
+例えば:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: MyApp
+  ports:
+  - protocol: TCP
+    port: 80
+    targetPort: 9376
+  clusterIP: 10.0.171.239
+  loadBalancerIP: 78.11.24.19
+  type: LoadBalancer
+status:
+  loadBalancer:
+    ingress:
+    - ip: 146.148.47.155
+```
+
+外部のロードバランサーからのトラフィックはバックエンドのPodに直接転送されます。クラウドプロバイダーはどのようにそのリクエストをバランシングするかを決めます。  
+
+いくつかのクラウドプロバイダーにおいて、`loadBalancerIP`の設定をすることができます。このようなケースでは、そのロードバランサーはユーザーが指定した`loadBalancerIP`に対してロードバランサーを作成します。  
+もし`loadBalancerIP`フィールドの値が指定されていない場合、そのロードバランサーはエフェメラルなIPアドレスに対して作成されます。もしユーザーが`loadBalancerIP`を指定したが、使っているクラウドプロバイダーがその機能をサポートしていない場合、その`loadBalancerIP`フィールドに設定された値は無視されます。
+
+{{< note >}}
+もしSCTPを使っている場合、`LoadBalancer` タイプのServiceに関する[使用上の警告](#caveat-sctp-loadbalancer-service-type)を参照してください。
+{{< /note >}}
+
+{{< note >}}
+
+**Azure** において、もしユーザーが指定する`loadBalancerIP`を使用したい場合、最初に静的なパブリックIPアドレスのリソースを作成する必要があります。  
+このパブリックIPアドレスのリソースは、クラスター内で自動的に作成された他のリソースと同じグループに作られるべきです。  
+例: `MC_myResourceGroup_myAKSCluster_eastus`  
+
+割り当てられたIPアドレスをloadBalancerIPとして指定してください。クラウドプロバイダーの設定ファイルにおいてsecurityGroupNameを更新したことを確認してください。  
+`CreatingLoadBalancerFailed`というパーミッションの問題に対するトラブルシューティングの情報は、[Azure Kubernetes Service(AKS)のロードバランサーで静的IPアドレスを使用する](https://docs.microsoft.com/en-us/azure/aks/static-ip) や、[高度なネットワークを使用したAKSクラスターでのCreatingLoadBalancerFailed](https://github.com/Azure/AKS/issues/357)を参照してください。
+{{< /note >}}
+
+#### 内部のロードバランサー
+複雑な環境において、同一の(仮想)ネットワークアドレスブロック内のServiceからのトラフィックを転送する必要がでてきます。  
+
+Split-HorizonなDNS環境において、ユーザーは2つのServiceを外部と内部の両方からのトラフィックをエンドポイントに転送させる必要がでてきます。
+
+ユーザーは、Serviceに対して下記のアノテーションを1つ追加することでこれを実現できます。  
+追加するアノテーションは、ユーザーが使っているクラウドプロバイダーに依存しています。
+
+{{< tabs name="service_tabs" >}}
+{{% tab name="Default" %}}
+タブを選択してください。  
+{{% /tab %}}
+{{% tab name="GCP" %}}
+```yaml
+[...]
+metadata:
+    name: my-service
+    annotations:
+        cloud.google.com/load-balancer-type: "Internal"
+[...]
+```
+
+Kubernetes1.7.0から1.7.3のMasterに対しては、`cloud.google.com/load-balancer-type: "internal"`を使用します。  
+さらなる情報については、[docs](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing)を参照してください。  
+{{% /tab %}}
+{{% tab name="AWS" %}}
+```yaml
+[...]
+metadata:
+    name: my-service
+    annotations:
+        service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
+[...]
+```
+{{% /tab %}}
+{{% tab name="Azure" %}}
+```yaml
+[...]
+metadata:
+    name: my-service
+    annotations:
+        service.beta.kubernetes.io/azure-load-balancer-internal: "true"
+[...]
+```
+{{% /tab %}}
+{{% tab name="OpenStack" %}}
+```yaml
+[...]
+metadata:
+    name: my-service
+    annotations:
+        service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
+[...]
+```
+{{% /tab %}}
+{{% tab name="Baidu Cloud" %}}
+```yaml
+[...]
+metadata:
+    name: my-service
+    annotations:
+        service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
+[...]
+```
+{{% /tab %}}
+{{< /tabs >}}
+
+
+#### AWSにおけるTLSのサポート {#ssl-support-on-aws}
+
+AWS上で稼働しているクラスターにおいて、部分的なTLS/SSLのサポートをするには、`LoadBalancer` Serviceに対して3つのアノテーションを追加できます。
+
+```yaml
+metadata:
+  name: my-service
+  annotations:
+    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012
+```
+
+1つ目は、使用する証明書のARNです。これはIAMにアップロードされたサードパーティーが発行した証明書か、AWS Certificate Managerで作成された証明書になります。
+
+```yaml
+metadata:
+  name: my-service
+  annotations:
+    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: (https|http|ssl|tcp)
+```
+
+2つ目のアノテーションはPodが利用するプロトコルを指定するものです。HTTPSとSSLの場合、ELBはそのPodが証明書を使って暗号化されたコネクションを介して自分自身のPodを認証すると推測します。
+
+HTTPとHTTPSでは、レイヤー7でのプロキシーを選択します。ELBはユーザーとのコネクションを切断し、リクエストを転送するときにリクエストヘッダーをパースして、`X-Forwardef-For`ヘッダーにユーザーのIPを追加します(Podは接続相手のELBのIPアドレスのみ確認可能です)。
+
+TCPとSSLでは、レイヤー4でのプロキシーを選択します。ELBはヘッダーの値を変更せずにトラフィックを転送します。  
+
+いくつかのポートがセキュアに保護され、他のポートではセキュアでないような混合した環境において、下記のようにアノテーションを使うことができます。
+
+```yaml
+    metadata:
+      name: my-service
+      annotations:
+        service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
+        service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443,8443"
+```
+
+上記の例では、もしServiceが`80`、`443`、`8443`と3つのポートを含んでいる場合、`443`と`8443`はSSL証明書を使いますが、`80`では単純にHTTPでのプロキシーとなります。
+
+Kubernetes v1.9以降のバージョンからは、Serviceのリスナー用にHTTPSやSSLと[事前定義されたAWS SSLポリシー](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)を使用できます。
+どのポリシーが使用できるかを確認するために、`aws`コマンドラインツールを使用できます。
+
+```bash
+aws elb describe-load-balancer-policies --query 'PolicyDescriptions[].PolicyName'
+```
+
+ユーザーは"`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`"というアノテーションを使用することにより、複数のポリシーの中からどれか1つを指定できます。  
+例えば: 
+
+```yaml
+    metadata:
+      name: my-service
+      annotations:
+        service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: "ELBSecurityPolicy-TLS-1-2-2017-01"
+```
+
+#### AWS上でのPROXYプロトコルのサポート
+
+AWS上で稼働するクラスターで[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)のサポートを有効にするために、下記のServiceのアノテーションを使用できます。  
+
+```yaml
+    metadata:
+      name: my-service
+      annotations:
+        service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
+```
+
+Kubernetesバージョン1.3.0からは、このアノテーションを使用するとELBによってプロキシーされた全てのポートが対象になり、そしてそれ以外の場合は構成されません。
+
+#### AWS上でのELBのアクセスログ
+
+AWS上でのELB Service用のアクセスログを管理するためにはいくつかのアノテーションが使用できます。
+
+`service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`というアノテーションはアクセスログを有効にするかを設定できます。
+
+`service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`というアノテーションはアクセスログをパブリッシュするためのインターバル(分)を設定できます。  
+ユーザーはそのインターバルで5分もしくは60分で設定できます。
+
+`service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`というアノテーションはロードバランサーのアクセスログが保存されるAmazon S3のバケット名を設定できます。
+
+`service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`というアノテーションはユーザーが作成したAmazon S3バケットの論理的な階層を指定します。
+
+```yaml
+    metadata:
+      name: my-service
+      annotations:
+        service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true"
+        # ロードバランサーのアクセスログが有効かどうか。
+        service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "60"
+        # アクセスログをパブリッシュするためのインターバル(分)。ユーザーはそのインターバルで5分もしくは60分で設定できます。  
+        service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket"
+        # ロードバランサーのアクセスログが保存されるAmazon S3のバケット名。 
+        service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "my-bucket-prefix/prod"
+        # ユーザーが作成したAmazon S3バケットの論理的な階層。例えば: `my-bucket-prefix/prod`
+```
+
+#### AWSでの接続の中断
+
+古いタイプのELBでの接続の中断は、`service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`というアノテーションを`"true"`に設定することで管理できます。  
+`service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`というアノテーションで、インスタンスを登録解除するまえに既存の接続をオープンにし続けるための最大時間(秒)を指定できます。
+
+```yaml
+    metadata:
+      name: my-service
+      annotations:
+        service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled: "true"
+        service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout: "60"
+```
+
+#### 他のELBアノテーション
+
+古いタイプのELBを管理するためのアノテーションは他にもあり、下記で紹介します。  
+
+```yaml
+    metadata:
+      name: my-service
+      annotations:
+        service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60"
+        # ロードバランサーによってクローズされる前にアイドル状態(コネクションでデータは送信されない)になれる秒数
+
+        service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
+        # ゾーンを跨いだロードバランシングが有効かどうか
+
+        service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: "environment=prod,owner=devops"
+        # ELBにおいて追加タグとして保存されるキー・バリューのペアのコンマ区切りのリスト
+
+        service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: ""
+        # バックエンドへのトラフィックが正常になったと判断するために必要なヘルスチェックの連続成功数
+        # デフォルトでは2 この値は2から10の間で設定可能
+
+        service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"
+        # バックエンドへのトラフィックが異常になったと判断するために必要なヘルスチェックの連続失敗数
+        # デフォルトでは6 この値は2から10の間で設定可能
+
+        service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"
+        # 各インスタンスのヘルスチェックのおよそのインターバル(秒)
+        # デフォルトでは10 この値は5から300の間で設定可能
+
+        service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"
+        # ヘルスチェックが失敗したと判断されるレスポンスタイムのリミット(秒)
+        # この値はservice.beta.kubernetes.io/aws-load-balancer-healthcheck-intervalの値以下である必要があります。
+        # デフォルトでは5 この値は2から60の間で設定可能
+
+        service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
+        # ELBに追加される予定のセキュリティーグループのリスト
+```
+
+#### AWSでのNetwork Load Balancerのサポート [α版] {#aws-nlb-support}
+
+{{< warning >}}
+これはα版の機能で、プロダクション環境でのクラスターでの使用はまだ推奨しません。
+{{< /warning >}}
+
+Kubernetes v1.9.0から、ServiceとAWS Network Load Balancer(NLB)を組み合わせることができます。AWSでのネットワークロードバランサーを使用するためには、`service.beta.kubernetes.io/aws-load-balancer-type`というアノテーションの値を`nlb`に設定してください。
+
+```yaml
+    metadata:
+      name: my-service
+      annotations:
+        service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
+```
+
+{{< note >}}
+NLBは特定のインスタンスクラスでのみ稼働します。サポートされているインスタンスタイプを確認するためには、ELBに関する[AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)を参照してください。  
+{{< /note >}}
+
+古いタイプのElastic Load Balancersとは異なり、Network Load Balancers (NLBs)はクライアントのIPアドレスをNodeに転送します。  
+もしServiceの`.spec.externalTrafficPolicy`の値が`Cluster`に設定されていた場合、クライアントのIPアドレスは末端のPodに伝播しません。
+
+`.spec.externalTrafficPolicy`を`Local`に設定することにより、クライアントIPアドレスは末端のPodに伝播します。しかし、これにより、トラフィックの分配が不均等になります。  
+特定のLoadBalancer Serviceに紐づいたPodがないNodeでは、自動的に割り当てられた`.spec.healthCheckNodePort`に対するNLBのターゲットグループのヘルスチェックが失敗し、トラフィックを全く受信しません。
+
+均等なトラフィックの分配を実現するために、DaemonSetの使用や、同一のNodeに配備しないように[Podのanti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)を設定します。
+
+また、[内部のロードバランサー](/docs/concepts/services-networking/service/#internal-load-balancer)のアノテーションとNLB Serviceを使用できます。  
+
+NLBの背後にあるインスタンスに対してクライアントのトラフィックを転送するために、Nodeのセキュリティーグループは下記のようなIPルールに従って変更されます。
+
+| Rule | Protocol | Port(s) | IpRange(s) | IpRange Description |
+|------|----------|---------|------------|---------------------|
+| ヘルスチェック | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
+| クライアントのトラフィック | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
+| MTCによるサービスディスカバリー | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (デフォルト: `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |
+
+どのクライアントIPがNLBにアクセス可能かを制限するためには、`loadBalancerSourceRanges`を指定してください。  
+
+```yaml
+spec:
+  loadBalancerSourceRanges:
+  - "143.231.0.0/16"
+```
+
+{{< note >}}
+もし`.spec.loadBalancerSourceRanges`が設定されていない場合、KubernetesはNodeのセキュリティーグループに対して`0.0.0.0/0`からのトラフィックを許可します。  
+もしNodeがパブリックなIPアドレスを持っていた場合、NLBでないトラフィックも修正されたセキュリティーグループ内の全てのインスタンスにアクセス可能になってしまうので注意が必要です。
+
+{{< /note >}}
+
+### ExternalName タイプ {#externalname}
+
+ExternalNameタイプのServiceは、ServiceをDNS名とマッピングし、`my-service`や`cassandra`というような従来のラベルセレクターとはマッピングしません。  
+ユーザーはこれらのServiceにおいて`spec.externalName`フィールドの値を指定します。
+
+このServiceの定義では、例えば`prod`というNamespace内の`my-service`というServiceを`my.database.example.com`にマッピングします。
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+  namespace: prod
+spec:
+  type: ExternalName
+  externalName: my.database.example.com
+```
+{{< note >}}
+ExternalNameはIpv4のアドレスの文字列のみ受け付けますが、IPアドレスではなく、数字で構成されるDNS名として受け入れます。  
+IPv4アドレスに似ているExternalNamesはCoreDNSもしくはIngress-Nginxによって名前解決されず、これはExternalNameは正規のDNS名を指定することを目的としているためです。  
+IPアドレスをハードコードする場合、[Headless Service](#headless-service)の使用を検討してください。
+{{< /note >}}
+
+`my-service.prod.svc.cluster.local`というホストをルックアップするとき、クラスターのDNS Serviceは`CNAME`レコードと`my.database.example.com`という値を返します。  
+`my-service`へのアクセスは、他のServiceと同じ方法ですが、再接続する際はプロキシーや転送を介して行うよりも、DNSレベルで行われることが決定的に異なる点となります。  
+後にユーザーが使用しているデータベースをクラスター内に移行することになった後は、Podを起動させ、適切なラベルセレクターやEndpointを追加し、Serviceの`type`を変更します。
+
+{{< note >}}
+このセクションは、[Alen Komljen](https://akomljen.com/)による[Kubernetes Tips - Part1](https://akomljen.com/kubernetes-tips-part-1/)というブログポストを参考にしています。
+
+{{< /note >}}
+
+### External IPs
+
+もし1つ以上のクラスターNodeに転送するexternalIPが複数ある場合、Kubernetes Serviceは`externalIPs`に指定したIPで公開されます。  
+そのexternalIP(到達先のIPとして扱われます)のServiceのポートからトラフィックがクラスターに入って来る場合、ServiceのEndpointのどれか1つに対して転送されます。  
+`externalIPs`はKubernetesによって管理されず、それを管理する責任はクラスターの管理者にあります。
+
+Serviceのspecにおいて、`externalIPs`は他のどの`ServiceTypes`と併用して設定できます。  
+下記の例では、"`my-service`"は"`80.11.12.10:80`" (`externalIP:port`)のクライアントからアクセス可能です。
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: MyApp
+  ports:
+  - name: http
+    protocol: TCP
+    port: 80
+    targetPort: 9376
+  externalIPs:
+  - 80.11.12.10
+```
+
+## Serviceのデメリット
+
+仮想IP用にuserspaceモードのプロキシーを使用すると、小規模もしくは中規模のスケールでうまく稼働できますが、1000以上のServiceがあるようなとても大きなクラスターではうまくスケールしません。  
+これについては、[Serviceのデザインプロポーザル](http://issue.k8s.io/1107)にてさらなる詳細を確認できます。  
+
+userspaceモードのプロキシーの使用は、Serviceにアクセスするパケットの送信元IPアドレスが不明瞭になります。  
+これは、いくつかの種類のネットワークフィルタリング(ファイアウォールによるフィルタリング)を不可能にします。  
+iptablesプロキシーモードはクラスター内の送信元IPを不明瞭にはしませんが、依然としてロードバランサーやNodePortへ疎通するクライアントに影響があります。
+
+`Type`フィールドはネストされた機能としてデザインされています。 - 各レベルの値は前のレベルに対して追加します。  
+これは全てのクラウドプロバイダーにおいて厳密に要求されていません(例: Google Compute Engineは`LoadBalancer`を動作させるために`NodePort`を割り当てる必要はありませんが、AWSではその必要があります)が、現在のAPIでは要求しています。
+
+## 仮想IPの実装について {#the-gory-details-of-virtual-ips}
+
+これより前の情報は、ただServiceを使いたいという多くのユーザーにとっては有益かもしれません。しかし、その裏側では多くのことが行われており、理解する価値があります。
+
+### 衝突の回避
+
+Kubernetesの主要な哲学のうちの一つは、ユーザーは、ユーザー自身のアクションによるミスでないものによって、ユーザーのアクションが失敗するような状況に晒されるべきでないことです。  
+Serviceリソースの設計のでは、これはユーザーの指定したポートが衝突する可能性がある場合は、そのポートのServiceを作らないことを意味します。これは障害を分離することとなります。
+
+Serviceのポート番号を選択できるようにするために、我々はどの2つのServiceでもポートが衝突しないことを保証します。  
+Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てることで実現しています。  
+
+各Serviceが固有のIPを割り当てられるのを保証するために、内部のアロケーターは、Serviceを作成する前に、etcd内のグローバルの割り当てマップをアトミックに更新します。  
+そのマップオブジェクトはServiceのIPアドレスの割り当てのためにレジストリー内に存在しなくてはならず、そうでない場合は、Serviceの作成時にIPアドレスが割り当てられなかったことを示すエラーメッセージが表示されます。  
+
+コントロールプレーンにおいて、バックグラウンドのコントローラーはそのマップを作成する責務があります(インメモリーのロックが使われていた古いバージョンのKubernetesのマイグレーションも必要です)。
+また、Kubernetesは無効な割り当てがされているかをチェックすることと、現時点でどのServiceにも使用されていない割り当て済みIPアドレスのクリーンアップのためにコントローラーを使用します。
+
+### ServiceのIPアドレス {#ips-and-vips}
+
+実際に固定された向き先であるPodのIPアドレスとは異なり、ServiceのIPは実際には単一のホストによって応答されません。
+その代わり、kube-proxyは必要な時に透過的にリダイレクトされる_仮想_ IPアドレスを定義するため、iptables(Linuxのパケット処理ロジック)を使用します。  
+クライアントがVIPに接続する時、そのトラフィックは自動的に適切なEndpointに転送されます。
+Service用の環境変数とDNSは、Serviceの仮想IPアドレス(とポート)の面において、自動的に生成されます。  
+
+kube-proxyは3つの微妙に異なった動作をするプロキシーモード&mdash; userspace、iptablesとIPVS &mdash; をサポートしています。
+
+#### Userspace
+
+例として、上記で記述されている画像処理のアプリケーションを考えます。  
+バックエンドのServiceが作成されたとき、KubernetesのMasterは仮想IPを割り当てます。例えば10.0.0.1などです。  
+そのServiceのポートが1234で、そのServiceはクラスター内の全てのkube-proxyインスタンスによって監視されていると仮定します。  
+kube-proxyが新しいServiceを見つけた時、kube-proxyは新しいランダムポートをオープンし、その仮想IPアドレスの新しいポートにリダイレクトするようにiptablesを更新し、そのポート上で新しい接続を待ち受けを開始します。  
+
+クライアントがServiceの仮想IPアドレスに接続したとき、iptablesルールが有効になり、そのパケットをプロキシー自身のポートにリダイレクトします。  
+その"Service プロキシー"はバックエンドPodの対象を選択し、クライアントのトラフィックをバックエンドPodに転送します。
+
+これはServiceのオーナーは、衝突のリスクなしに、求めるどのようなポートも選択できることを意味します。
+クライアントは単純にそのIPとポートに対して接続すればよく、実際にどのPodにアクセスしているかを意識しません。
+
+#### iptables
+
+また画像処理のアプリケーションについて考えます。バックエンドServiceが作成された時、そのKubernetesコントロールプレーンは仮想IPアドレスを割り当てます。例えば10.0.0.1などです。  
+Serviceのポートが1234で、そのServiceがクラスター内のすべてのkube-proxyインスタンスによって監視されていると仮定します。  
+kube-proxyが新しいServiceを見つけた時、kube-proxyは仮想IPから各Serviceのルールにリダイレクトされるような、iptablesルールのセットをインストールします。
+Service毎のルールは、トラフィックをバックエンドにリダイレクト(Destination NATを使用)しているEndpoint毎のルールに対してリンクしています。
+
+クライアントがServiceの仮想IPアドレスに対して接続しているとき、そのiptablesルールが有効になります。  
+バックエンドのPodが選択され(SessionAffinityに基づくか、もしくはランダムで選択される)、パケットはバックエンドにリダイレクトされます。  
+userspaceモードのプロキシーとは異なり、パケットは決してuserspaceにコピーされず、kube-proxyは仮想IPのために稼働される必要はなく、またNodeでは変更されていないクライアントIPからトラフィックがきます。
+
+このように同じ基本的なフローは、NodePortまたはLoadBalancerを介してトラフィックがきた場合に、実行され、ただクライアントIPは変更されます。
+
+#### IPVS
+
+iptablesの処理は、大規模なクラスターの場合劇的に遅くなります。例としてはServiceが10,000ほどある場合です。
+IPVSは負荷分散のために設計され、カーネル内のハッシュテーブルに基づいています。そのためIPVSベースのkube-proxyによって、多数のServiceがある場合でも一貫して高パフォーマンスを実現できます。  
+次第に、IPVSベースのkube-proxyは負荷分散のアルゴリズムはさらに洗練されています(最小接続数、位置ベース、重み付け、永続性など)。
+
+## APIオブジェクト
+
+ServiceはKubernetesのREST APIにおいてトップレベルのリソースです。ユーザーはそのAPIオブジェクトに関して、[Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)でさらなる情報を確認できます。  
+
+## サポートされているプロトコル {#protocol-support}
+
+### TCP
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
+
+ユーザーはどの種類のServiceにおいてもTCPを利用できます。これはデフォルトのネットワークプロトコルです。
+
+### UDP
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
+
+ユーザーは多くのServiceにおいてUDPを利用できます。 type=LoadBalancerのServiceにおいては、UDPのサポートはこの機能を提供しているクラウドプロバイダーに依存しています。
+
+### HTTP
+
+{{< feature-state for_k8s_version="v1.1" state="stable" >}}
+
+もしクラウドプロバイダーがサポートしている場合、ServiceのEndpointに転送される外部のHTTP/HTTPSでのリバースプロキシーをセットアップするために、LoadBalancerモードでServiceを作成可能です。
+
+{{< note >}}
+ユーザーはまた、HTTP / HTTPS Serviceを公開するために、Serviceの代わりに{{< glossary_tooltip term_id="ingress" >}}を利用することもできます。
+{{< /note >}}
+
+### PROXY プロトコル
+
+{{< feature-state for_k8s_version="v1.1" state="stable" >}}
+
+もしクラウドプロバイダーがサポートしている場合(例: [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws))、Kubernetesクラスターの外部のロードバランサーを設定するためにLoadBalancerモードでServiceを利用できます。これは[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)がついた接続を転送します。
+
+ロードバランサーは、最初の一連のオクテットを送信します。
+下記のような例となります。
+
+```
+PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
+```
+クライアントからのデータのあとに追加されます。
+
+### SCTP
+
+{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+
+KubernetseはService、Endpoint、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というFeature Gateを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。
+
+そのFeature Gateが有効になった時、ユーザーはService、Endpoint、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。  
+Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。
+
+#### 警告 {#caveat-sctp-overview}
+
+##### マルチホームSCTPアソシエーションのサポート {#caveat-sctp-multihomed}
+
+{{< warning >}}
+マルチホームSCTPアソシエーションのサポートは、複数のインターフェースとPodのIPアドレスの割り当てをサポートできるCNIプラグインを要求します。
+
+マルチホームSCTPアソシエーションにおけるNATは、対応するカーネルモジュール内で特別なロジックを要求します。
+{{< /warning >}}
+
+##### type=LoadBalancer Service について {#caveat-sctp-loadbalancer-service-type}
+
+{{< warning >}}
+クラウドプロバイダーのロードバランサーの実装がプロトコルとしてSCTPをサポートしている場合は、`type` がLoadBalancerで` protocol`がSCTPの場合でのみサービスを作成できます。  
+そうでない場合、Serviceの作成要求はリジェクトされます。現時点でのクラウドのロードバランサーのプロバイダー(Azure、AWS、CloudStack、GCE、OpenStack)は全てSCTPのサポートをしていません。
+{{< /warning >}}
+
+##### Windows {#caveat-sctp-windows-os}
+
+{{< warning >}}
+SCTPはWindowsベースのNodeではサポートされていません。
+{{< /warning >}}
+
+##### Userspace kube-proxy {#caveat-sctp-kube-proxy-userspace}
+
+{{< warning >}}
+kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理をサポートしません。
+{{< /warning >}}
+
+## Future work
+
+将来的に、Serviceのプロキシーポリシーはシンプルなラウンドロビンのバランシングだけでなく、もっと細かな設定が可能になります。例えば、Masterによって選択されるものや、水平シャーディングされたりするようになります。  
+我々もまた、いくつかのServiceが"実際の"ロードバランサーを備えることを想定します。その場合、仮想IPは単純にパケットをそのロードバランサーに転送します。
+
+Kubernetesプロジェクトは、L7 (HTTP) Serviceへのサポートをもっと発展させようとしています。
+
+Kubernetesプロジェクトは、現在利用可能なClusterIP、NodePortやLoadBalancerタイプのServiceに対して、より柔軟なIngressのモードを追加する予定です。
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。
+* [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。
+
+{{% /capture %}}
@@ -0,0 +1,64 @@
+---
+title: CSI Volume Cloning
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
+このドキュメントではKubernetesで既存のCSIボリュームの複製についてのコンセプトを説明します。このページを読む前にあらかじめ[ボリューム](/docs/concepts/storage/volumes)についてよく理解していることが望ましいです。
+
+この機能を使用するにはVolumePVCDataSourceのフィーチャーゲートを有効にする必要があります。
+
+```
+--feature-gates=VolumePVCDataSource=true
+```
+
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## イントロダクション
+
+{{<glossary_tooltip text = "CSI" term_id = "csi">}}のボリューム複製機能は、ユーザーが{{<glossary_tooltip text = "ボリューム" term_id = "volume">}}の複製を作成することを示す`dataSource`フィールドで既存の{{<glossary_tooltip text = "PVC" term_id = "persistent-volume-claim">}}を指定するためのサポートを追加します。
+
+複製は既存のKubernetesボリュームの複製として定義され、標準のボリュームと同じように使用できます。唯一の違いは、プロビジョニング時に「新しい」空のボリュームを作成するのではなく、バックエンドデバイスが指定されたボリュームの正確な複製を作成することです。
+
+複製の実装は、Kubernetes APIの観点からは新しいPVCの作成時に既存のバインドされていないPVCをdataSourceとして指定する機能を追加するだけです。
+
+この機能を使用する場合、ユーザーは次のことに注意する必要があります:
+
+* 複製のサポート(`VolumePVCDataSource`)はCSIドライバーのみです。
+* 複製のサポートは動的プロビジョニングのみです。
+* CSIドライバーはボリューム複製機能を実装している場合としていない場合があります。
+* PVCは複製先のPVCと同じ名前空間に存在する場合にのみ複製できます（複製元と複製先は同じ名前空間になければなりません）。
+
+
+## プロビジョニング
+
+複製は同じ名前空間内の既存のPVCを参照するdataSourceを追加すること以外は他のPVCと同様にプロビジョニングされます。
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+    name: clone-of-pvc-1
+    namespace: myns
+spec:
+  capacity:
+    storage: 10Gi
+  dataSource:
+    kind: PersistentVolumeClaim
+    name: pvc-1
+```
+
+このyamlの作成結果は指定された複製元である`pvc-1`と全く同じデータを持つ`clone-of-pvc-1`という名前の新しいPVCです。
+
+## 使い方
+
+新しいPVCが使用可能になると、複製されたPVCは他のPVCと同じように利用されます。またこの時点で新しく作成されたPVCは独立したオブジェクトであることが期待されます。元のdataSource PVCを考慮せず個別に利用、複製、スナップショット、削除できます。これはまた複製元が新しく作成された複製にリンクされておらず、新しく作成された複製に影響を与えずに変更または削除できることを意味します。
+
+{{% /capture %}}