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)
This commit is contained in:
inductor
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
8c88039129
commit
4532bd2bdb
@@ -0,0 +1,106 @@
|
||||
---
|
||||
title: Nordstrom ケーススタディ
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
---
|
||||
|
||||
<div class="banner1" style="background-image: url('/images/CaseStudy_nordstrom_banner1.jpg')">
|
||||
<h1> ケーススタディ:<img src="/images/nordstrom_logo.png" class="header_logo" style="margin-bottom:-1.5% !important;width:20% !important;"><br> <div class="subhead">厳しい小売環境下で数百万ドルのコスト削減を実現
|
||||
|
||||
|
||||
</div></h1>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="details">
|
||||
企業名 <b>Nordstrom</b> 所在地 <b>シアトル、ワシントン</b> 業界 <b>小売り</b>
|
||||
</div>
|
||||
|
||||
<hr>
|
||||
<section class="section1">
|
||||
<div class="cols">
|
||||
<div class="col1">
|
||||
<h2>課題</h2>
|
||||
NordstromはECサイトのNordstrom.comを含む技術的な運用の効率と速度を向上させたいと考えていました。同時に、Nordstrom Technologyでは技術的な運用コストを抑える方法を模索していました。
|
||||
<br>
|
||||
<h2>解決策</h2>
|
||||
4年前にDevOpsを採用し、CI/CD(継続的インテグレーション/継続的デプロイ)プロジェクトを開始した後、同社はデプロイ時間を3か月から30分に短縮しました。ですが、環境間でさらに高速化するために、<a href="http://kubernetes.io/">Kubernetes</a>でオーケストレーションされたDockerコンテナを採用しました。
|
||||
<br>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="col2">
|
||||
|
||||
<h2>影響</h2>
|
||||
Kubernetesを使用するNordstrom Technologyの開発者はより迅速にデプロイし、「アプリケーションを書くことだけに集中できる」と、NordstromのKubernetesエンタープライズプラットフォーム構築チームのシニアエンジニアであるDhawal Patel氏は言います。チームはOpsの効率を向上させ、ワークロードに応じてCPU使用率を5倍から12倍改善しました。「私たちは何千もの仮想マシンを実行していますが、これらのリソースをすべて効率的に使用できているわけではありません。」とPatel氏は語ります。「Kubernetes を採用することで、クラスターの効率化に挑戦することなく以前の10倍効率化できています。」
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner2">
|
||||
<div class="banner2text">
|
||||
私たちは常にテクノロジーを通じて最適化してより大きな価値を提供する方法を探しています。Kubernetesを用いて私たちは開発効率と運用効率という2つの効率を示します。これは双方にとって好都合です。
|
||||
<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>-Nordstrom社シニアエンジニア Dhawal Patel</span>
|
||||
</div>
|
||||
</div>
|
||||
<section class="section2">
|
||||
<div class="fullcol">
|
||||
5年前にDhawal Patelが小売業者のウェブサイトのアプリケーション開発者として<a href="http://shop.nordstrom.com/">Nordstrom</a>に入社したとき、彼は開発サイクルをスピードアップする機会があることに気づきました。
|
||||
<br><br>
|
||||
DevOpsの初期の頃、Nordstrom Technologyは従来のサイロチームと機能モデルを引き続き採用していました。「開発者として、コードの記述やビジネスへの価値の追加よりも環境の修正に多くの時間を費やしました。」とPatel氏は言います。「私はそれについて情熱的だったので、修正する機会を与えられました。」
|
||||
<br><br>
|
||||
同社はまた、より早く行動することに熱心であり、2013年に最初の継続的インテグレーション/継続的デプロイ(CI/CD)プロジェクトを開始しました。このプロジェクトはNordstromのクラウドネイティブへの旅の第一歩でした。
|
||||
<br><br>
|
||||
開発チームと運用チームのメンバーは社内のオンプレミスサーバーを使ってCI/CDパイプラインを構築しました。チームは<a href="https://www.chef.io/chef/">Chef</a>を選択し、仮想IPの作成、サーバー、および負荷分散を自動化したクックブックを作成しました。「プロジェクトの完了後、デプロイにかかる時間は3か月から30分になりました。」とPatal氏は言います。「開発環境、テスト環境、ステージング環境、本番環境という複数環境があったため、各環境でChefクックブックを流すのに30分かかりました。その時点で大きな成果でした。」
|
||||
<br><br>しかし、新しい環境はまだ立ち上がるのに時間がかかりすぎていたため、次のステップはクラウドでの作業でした。現在、Nordstrom Technologyはエンタープライズプラットフォームを構築しており、同社の1,500名の開発者はKubernetesでオーケストレーションされたDockerコンテナとして動作するアプリケーションをクラウド上にデプロイできるようになりました。
|
||||
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner3" style="background-image: url('/images/CaseStudy_nordstrom_banner3.jpg')">
|
||||
<div class="banner3text">
|
||||
「私たちはKubernetesに人気が出ることに賭けました。コミュニティのサポートとプロジェクトの速度の初期の指標に基づいて、Kubernetesを中心にシステムを再構築しました。」
|
||||
</div>
|
||||
</div>
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
|
||||
「オンプレミスで仮想マシン(VM)を取得するのに数週間かかったため、クラウドはリソースへの高速なアクセスを提供しました。」とPatal氏は言います。「しかし、今ではたった5分で同じことができます。」
|
||||
<br><br>
|
||||
Nordstromがクラスター上のコンテナのスケジューリングに初めて進出したのはCoreOS fleetベースの自社開発のシステムでした。彼らは、Kubernetesに切り替えるときに、Kubernetes 1.0がリリースされるまでそのシステムでいくつかのPoCプロジェクトを始めました。「コミュニティのサポートとプロジェクトの速度の初期の指標に基づき、Kubernetesの人気が出るだろうと確信したため、Kubernetesを中心にシステムを再構築しました。」とNordstromのKubernetesチームのシニアマネージャーMarius Grigoriuは述べます。
|
||||
Kubernetesは多くの場合、マイクロサービスのプラットフォームと考えられていますが、NordstromにおいてKubernetesで始動した最初の重要なプロダクションの役割を担うアプリケーションはJiraでした。「最初のアプリケーションとして期待していた理想的なマイクロサービスではありませんでした。」とPatal氏は認めます。「しかし、それに取り組んでいたチームは本当にDockerとKubernetesに情熱を傾けており、実際に使いたいと考えていました。彼らは自社運用のアプリケーションをオンプレミスで実行しており、それをKubernetesに移行したいと考えていました。」
|
||||
<br><br>
|
||||
参加したチームにとってメリットはすぐに現れました。「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner4" style="background-image: url('/images/CaseStudy_nordstrom_banner4.jpg')">
|
||||
<div class="banner4text">
|
||||
「Kubernetesクラスターを使っているチームは心配する問題が少ないという事実を気に入っていました。インフラストラクチャーやオペレーティングシステムを管理する必要はありませんでした。」とGrigoriu氏は言います。「初期の導入者は、Kubernetesの宣言的な性質を好んでいます。彼らは対処しなければならなかった領域が減少したことを好んでます。」
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section5">
|
||||
<div class="fullcol">
|
||||
これらの初期の導入者をサポートするため、Patelのチームはクラスターの成長とプロダクションレベルのサービスの構築を開始しました。「私たちは監視のための<a href="https://prometheus.io/">Prometheus</a>と<a href="https://grafana.com/">Grafana</a>フロントエンドを組み合わせました。また、<a href="http://www.fluentd.org/">Fluentd</a>を使用してログを<a href="https://www.elastic.co/">Elasticsearch</a>にプッシュしたため、ログの集約が可能になりました。」とPatel氏は語ります。チームはまたCNCFプロジェクトを含む多数のオープンソースコンポーネントを追加し、Kubernetes、Terraformおよびkube2iamに貢献しました。
|
||||
<br><br>
|
||||
現在、Nordstrom TechnologyにはKubernetesを使っている開発チームは60以上あり、成功事例が出てくるにつれて、より多くのチームが参加するようになりました。「これを試してみようと思った最初の顧客基盤は次のユーザに勧め始めています。」Patel氏は言います。「初期の導入者の1人はDockerコンテナを使用しており、本番環境での実行方法がわかりませんでした。私たちは彼と一緒に座って、15分以内に本番環境に展開しました。彼はそれが素晴らしいと思い、彼の組織のより多くの人々が加わり始めました。」
|
||||
<br><br>
|
||||
Nordstrom Technologyの場合、クラウドネイティブへの移行によって、開発と運用の効率が大幅に向上しています。Kubernetesを利用する開発者はより迅速にデプロイでき、アプリケーションの価値の構築に専念できます。こうしたノウハウを取り入れるために、1つのチームにおいてクラウド上に仮想マシンを構築し、マージからデプロイまでに25分かかるところからスタートしました。Kubernetesへの切り替えにより、プロセスが5倍高速化され、マージからデプロイまでの時間が5分に改善しました。
|
||||
</div>
|
||||
|
||||
<div class="banner5">
|
||||
<div class="banner5text">
|
||||
「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="fullcol">
|
||||
スピードは素晴らしく、簡単に実証できますが、より大きな影響はおそらくその運用効率にあります。「AWSで何千ものVMを実行する場合、全体的な平均CPU使用率は約4%です。」とPatel氏は言います。「Kubernetesを使用することで、クラスタの効率化を図ることもなく、現在のCPU使用率は40%、つまり10倍になりました。直接クラウドに移行した場合には2600台以上のVMになるところが、同数の顧客用Podで済むようになりました。これらのPodを40台のVMで実行しているため、運用上のオーバーヘッドが大幅に削減されました。」
|
||||
<br><br>
|
||||
Nordstrom TechnologyはオンプレミスのベアメタルでKubernetesを実行することも検討しています。Patel氏は言います。「オンプレミスのKubernetesクラスターを構築できれば、クラウドの力を活用してオンプレミスでリソースを迅速にプロビジョニングできます。次に、開発者にとってのインターフェースはKubernetesです。Kubernetesのみと連携しているため、自社のサービスがオンプレミスにデプロイされていることに気付かないこともあります。」
|
||||
そのため、Patel氏はKubernetesのマルチクラスター機能の開発に熱心に取り組んでいます。「クラスターフェデレーションにより、オンプレミスをプライマリクラスターとして、クラウドをセカンダリバースト可能なクラスターとして使用できます。」と彼は言います。「つまり、アニバーサリーセールやブラックフライデーセールがあり、さらにコンテナが必要な場合は、クラウドにアクセスできます。」
|
||||
<br><br>
|
||||
この種の可能性とGrigoriuとPatelのチームがKubernetesを使用してすでに提供しているという反響が、Nordstromをそもそもクラウドネイティブジャーニーに導いた理由です。「現在の小売環境は、可能な限り即応性と柔軟性を高めようとしています。」とGrigoriu氏は言います。「Kubernetesにより、開発側と運用側の両方にとってバランスよく効率化されます。これは双方にとって好都合です。」
|
||||
|
||||
</div>
|
||||
</section>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 7.2 KiB |
@@ -0,0 +1,110 @@
|
||||
---
|
||||
title: SOS International ケーススタディ
|
||||
linkTitle: SOS International
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
logo: sos_featured_logo.png
|
||||
---
|
||||
|
||||
|
||||
<div class="banner1" style="background-image: url('/images/CaseStudy_sos_banner1.jpg')">
|
||||
<h1>ケーススタディ:<img src="/images/sos_logo.png" class="header_logo" style="width:20%;margin-bottom:-1.2%"><br> <div class="subhead" style="margin-top:1%">SOS International: Kubernetesを使ってコネクテッドな世界での緊急支援を提供
|
||||
|
||||
</div></h1>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="details">
|
||||
企業名 <b>SOS International</b> 所在地 <b>フレゼレクスベア、デンマーク
|
||||
</b> 業界 <b>医療および旅行支援</b>
|
||||
</div>
|
||||
|
||||
<hr>
|
||||
<section class="section1">
|
||||
<div class="cols">
|
||||
<div class="col1" style="width:100%"">
|
||||
<h2>課題</h2>
|
||||
SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。近年、同社のビジネス戦略では、デジタル分野での開発をさらに強化する必要がありましたが、ITシステムに関しては
|
||||
3つの従来のモノリス(Java, .NET, およびIBMのAS/400)とウォーターフォールアプローチにおいて「SOSには非常に断片化された遺産があります。」とエンタープライズアーキテクチャー責任者のMartin Ahrentsen氏は言います。「新しいテクノロジーと新しい働き方の両方を導入することを余儀なくされているので、市場投入までの時間を短縮して効率を高めることができました。それははるかに機敏なアプローチであり、私たちにはそれをビジネスに提供するのに役立つプラットフォームが必要でした。」
|
||||
|
||||
|
||||
<br><br>
|
||||
<h2>ソリューション</h2>
|
||||
標準システムの模索に失敗した後、同社はプラットフォームアプローチを採用し、Kubernetesとコンテナテクノロジーを包含するソリューションを探すことにしました。<a href="https://www.openshift.com/">RedHat OpenShift</a>はSOSの断片化されたシステムに最適であることが証明されました。「私たちはコード言語とその他の両方を使用する多くの異なる技術を持っていますが、それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社の3つのモノリスのうち、「この最先端のテクノロジーを2つ(.NETとJava)に提供できます。」このプラットフォームは2018年春に公開されました。現在、マイクロサービスアーキテクチャーに基づく6つの未開発プロジェクトが進行中であり、さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。
|
||||
<br><br>
|
||||
<h2>影響</h2>
|
||||
Kubernetesによって「市場投入までの時間、アジリティ、および変更と新しいテクノロジーに適応する能力の向上を実現しました。」とAhrentsen氏は語ります。「ソフトウェアのリリース準備ができてからリリースできるまでの時間が大幅に改善されました。」SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」と彼は言います。さらに、クラウドネイティブのコミュニティの一員であることは、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しいテクノロジーを使いたいと思っています」とAhrentsen氏は言います。「新しいテクノロジーを提供したという理由でITプロフェッショナルが我が社を選んでいたことが新人研修の時にわかりました。」
|
||||
</div>
|
||||
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner2">
|
||||
<div class="banner2text">
|
||||
「クラウドネイティブソフトウェアとテクノロジーが現在推進している変化の速度は驚くべきものであり、それをフォローして採用することは私たちにとって非常に重要です。Kubernetesとクラウドネイティブが提供する驚くべき技術はデジタルの未来に向けてSOSに変化をもたらしました。
|
||||
<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャー責任者 Martin Ahrentsen</span>
|
||||
</div>
|
||||
</div>
|
||||
<section class="section2">
|
||||
<div class="fullcol">
|
||||
<h2>SOS Internationalは60年にわたり、北欧諸国の顧客に信頼性の高い緊急医療および旅行支援を提供してきました。</h2>
|
||||
SOSのオペレータは年間100万件の案件を扱い、100万件以上の電話を処理しています。しかし、過去4年間で同社のビジネス戦略にデジタル空間でのますます激しい開発が必要になりました。<br><br>
|
||||
ITシステムに関していえば、会社のデータセンターで稼働する3つの伝統的なモノリスとウォーターフォールアプローチにおいて「SOSは非常に断片化された資産があります。」とエンタープライズアーキテクチャー責任者のMartin Ahrentsen氏は言います。「市場投入までの時間を短縮し、効率を高めるために新しいテクノロジーと新しい働き方の両方を導入する必要がありました。それははるかに機敏なアプローチであり、それをビジネスに提供するために役立つプラットフォームが必要でした。」
|
||||
<br><br>
|
||||
Ahrentsen氏と彼のチームは長い間SOSで機能する標準のソリューションを探していました。「私たちのような支援会社はそれほど多くないので、それにふさわしい標準システムを入手することはできません。完全に一致するものがないのです。」と彼は言います。「標準システムを採用したとしても、あまりにもひねりすぎて、もはや標準ではないものになるでしょう。そのため、新しいデジタルシステムとコアシステムを構築するために使用できるいくつかの共通コンポーネントを備えたテクノロジープラットフォームを見つけることにしました。」
|
||||
|
||||
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner3" style="background-image: url('/images/CaseStudy_sos_banner3.jpg')">
|
||||
<div class="banner3text">
|
||||
「私たちは新しいデジタルサービスを提供しなければなりませんが、古いものも移行する必要があります。そして、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換する必要があります。このテクノロジーを選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」
|
||||
|
||||
<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャー責任者 Martin Ahrentsen</span>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
Kubernetesができることを理解すると、Ahrentsen氏はすぐにビジネスニーズを満たすことができるプラットフォームに目を向けました。同社はDockerコンテナとKubernetesを組み込んだRed HatのOpenShift Container Platformを採用しました。また、RedHat Hyperconverged Infrastructureや一部のミッドウェアコンポーネントなど、すべてオープンソースコミュニティで提供されている技術スタックも利用することを決めました。<br><br>
|
||||
|
||||
テクノロジーやアジリティの適合性、法的要件、およびコンピテンシーという同社の基準に基づくと、OpenShiftソリューションはSOSの断片化されたシステムに完全に適合するように思われました。「私たちはコード言語とそれ以外の両方を使用する多くの異なる技術を持っています。それらはすべて新しいプラットフォーム上のリソースを使用できます。」とAhrentsen氏は言います。同社の3つのモノリスのうち、「この最先端のテクノロジーを2つ(.NETとJava)に提供できます。」<br><br>
|
||||
|
||||
プラットフォームは2018年春に公開されました。マイクロサービスアーキテクチャーに基づく6つの未開発のプロジェクトが最初に開始されました。さらに、同社のJavaアプリケーションはすべて「リフト&シフト」移行を行っています。最初に稼働しているKubernetesベースのプロジェクトの一つがRemote Medical Treatmentです。これは顧客が音声、チャット、ビデオを介してSOSアラームセンターに連絡できるソリューションです。「完全なCI/CDパイプラインと最新のマイクロサービスアーキテクチャーをすべて2つのOpenShiftクラスターセットアップで実行することに焦点を当てて、非常に短時間で開発できました。」とAhrentsen氏は言います。北欧諸国へのレスキュートラックの派遣に使用されるOnsite、および、レッカー車の追跡を可能にするFollow Your Truckも展開されています。
|
||||
</div>
|
||||
</section>
|
||||
<div class="banner4" style="background-image: url('/images/CaseStudy_sos_banner4.jpg');width:100%">
|
||||
<div class="banner4text">
|
||||
「新しいテクノロジーを提供したという理由でITプロフェッショナルが我が社を選んでいたことが新人研修の時にわかりました。」
|
||||
<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャー責任者 Martin Ahrentsen</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section5" style="padding:0px !important">
|
||||
<div class="fullcol">
|
||||
プラットフォームがまだオンプレミスで稼働しているのは、保険業界のSOSの顧客の一部は同社がデータを処理しているためまだクラウド戦略を持っていないためです。KubernetesはSOSがデータセンターで開始し、ビジネスの準備ができたらクラウドに移行できるようにします。「今後3～5年にわたって、彼らすべてが戦略を持ち、そして、データを取り出してクラウドに移行できるでしょう。」とAhrentsen氏は言います。機密データと非機密データのハイブリッドクラウド設定に移行する可能性もあります。<br><br>
|
||||
|
||||
SOSの技術は確かに過渡期にあります。「新しいデジタルサービスを提供する必要がありますが、古いものも移行する必要があり、コアシステムをこのプラットフォーム上に構築された新しいシステムに変換しなければなりません。」とAhrentsen氏は言います。「このテクノロジーを選んだ理由の1つは古いデジタルサービスを変更しながら新しいサービスを構築できるからです。」<br><br>
|
||||
|
||||
しかし、Kubernetesはすでに市場投入までの時間を短縮しており、そのことは、新興プロジェクトがいかに迅速に開発され、リリースされたかにも表れています。「ソフトウェアのリリース準備ができてからリリース可能になるまでの時間は劇的に改善されました。」とAhrentsen氏は言います。<br><br>
|
||||
|
||||
さらに、クラウドネイティブのコミュニティの一員であることは、エンジニア、オペレーター、アーキテクトの数を今年60から100に増やすという目標を追求するうえで、同社が人材を引き付けるのに役立ちました。「彼らはクールで新しいテクノロジーを使いたいと思っています。」とAhrentsenは言います。「新しいテクノロジーを提供したという理由でITプロフェッショナルが我が社を選んでいたことが新人研修の時にわかりました。」
|
||||
|
||||
</div>
|
||||
|
||||
<div class="banner5" >
|
||||
<div class="banner5text">
|
||||
「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」
|
||||
<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- SOS International エンタープライズアーキテクチャー責任者 Martin Ahrentsen</span></div>
|
||||
</div>
|
||||
|
||||
<div class="fullcol">
|
||||
SOS Internationalの考え方も劇的に変わりました。「自動化、CI/CDパイプラインの作成を容易にするKubernetesとスクリプトへの簡単なアクセスがあるので、この完全自動化の方法に至る所で多くの内部的な関心が生まれています。旅を始めるために非常に良い気候を作り出しています。」<br><br>
|
||||
|
||||
SOSにおけるこの旅では、デジタル化と最適化がキーワードです。「ITがこれを実現するには改善する必要がありますが、それはKubernetesとプラットフォームの使用方法だけではありません。」とAhrentsen氏は言います。「これは自動化、そしてその後の機械学習やその他進行中の興味深い技術の準備が整ったシステムを構築する方法でもあります。」<br><br>
|
||||
|
||||
代表例：自動車へのIoTの導入。欧州委員会は現在、すべての新車にeCallを装備することを義務づけています。eCallは重大な交通事故が発生した場合に位置やその他データを送信します。SOSはこのサービスをスマート自動支援として提供しています。「電話を受けて、緊急対応チームを派遣する必要があるかどうか、またはそれほど大きな影響がないどうかを確認します。」とAhrentsen氏は言います。「すべてが接続され、データを送信する未来の世界は、新しい市場機会という点で私たちにとって大きな可能性を生み出します。しかし、それはまたITプラットフォームと私たちが提供すべきものに大きな需要をもたらすでしょう。」<br><br>
|
||||
|
||||
Ahrentsen氏はSOSが技術の選択を行ってきたことを考えると、この課題に十分対応できると感じています。「クラウドネイティブソフトウェアとテクノロジーが現在推進している変化の速度は驚くべきものであり、それに追従して採用することは私たちにとって非常に重要です。」と彼は言います。「Kubernetesとクラウドネイティブが提供する驚くべきテクノロジーは、デジタルの未来に向けてSOSに変化をもたらし始めました。」
|
||||
</div>
|
||||
</section>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 6.5 KiB |
@@ -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クラスターのアーキテクチャ図です。
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 設計
|
||||
|
||||
上で示した図で分かるように、Kubernetesとクラウドプロバイダーはいくつかの異なるコンポーネントを通じて連携します:
|
||||
|
||||
* Kubelet
|
||||
* Kubernetesコントローラーマネージャー
|
||||
* Kubernetes APIサーバー
|
||||
|
||||
CCMは、前述した3つのコンポーネントのクラウド依存のロジックを統合し、クラウドとの単一の連携ポイントとなります。CCMを利用した新しいアーキテクチャは下記のようになります:
|
||||
|
||||
|
||||
|
||||
## 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つのレプリカが稼働しているステートレスな画像処理用のバックエンドを考えます。これらのレプリカは代替可能です。— フロントエンドはバックエンドが何であろうと気にしません。バックエンドのセットを構成する実際の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を選択します。
|
||||
|
||||
|
||||
|
||||
### `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に対してトラフィックをリダイレクトするのを除外することを意味します。
|
||||
|
||||
|
||||
|
||||
### 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 >}}
|
||||
|
||||
|
||||
|
||||
このダイアグラムのプロキシーモデルにおいて、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つの微妙に異なった動作をするプロキシーモード— userspace、iptablesとIPVS — をサポートしています。
|
||||
|
||||
#### 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 %}}
|
||||
@@ -8,52 +8,56 @@ weight: 80
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
あなたがKubernetesのドキュメンテーションやWebサイトに貢献するのを手伝いたいのであれば、私たちはあなたの貢献を嬉しく思います！プロジェクトに関わって日が浅いのか、それとも長きに渡って関わっているのか、開発者、エンドユーザ、または誤植に耐えられない人かどうかに関係なく、誰でも貢献できます。
|
||||
ドキュメントやウェブサイトに貢献したい方、ご協力お待ちしています。
|
||||
はじめての方、久しぶりの方、開発者でもエンドユーザでも、はたまたタイポを見逃せない方でもどなたでも貢献可能です。
|
||||
|
||||
Kubernetesコミュニティに参加する、または私たちについて学ぶためのより多くの方法については、[Kubernetesコミュニティサイト](/community/)をご覧ください。Kubernetesドキュメントのスタイルガイドについては、[スタイルガイド](/docs/contribute/style/style-guide/)を参照してください。
|
||||
ドキュメントのスタイルガイドについては[こちら](/docs/contribute/style/style-guide/)。
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 寄稿者のタイプ
|
||||
## コントリビューターの種類
|
||||
|
||||
- [CLAに署名](/docs/contribute/start#sign-the-cla)し、プロジェクトにいくらかの時間と努力を費やしたKubernetes組織の*メンバー*。メンバーシップの具体的な基準については、[コミュニティメンバーシップ](https://github.com/kubernetes/community/blob/master/community-membership.md)を参照してください。
|
||||
- SIG Docs*レビューワー*は、ドキュメントのプルリクエストのレビューに関心を示し、SIG Docs承認者によってGithubリポジトリの適切なGithubグループと`OWNERS`ファイルに追加されたKubernetes組織のメンバーです。
|
||||
- SIG Docs*承認者*は、プロジェクトに対する継続的なコミットメントを示している優秀なメンバーです。承認者はKubernetes組織に代わってプルリクエストをマージし、コンテンツを公開できます。承認者は、より大きなKubernetesコミュニティのSIG Docsを代表することもできます。リリースの調整など、SIG Docs承認者の任務の中には、かなりの時間を要するものがあります。
|
||||
- _メンバー_ は、すでに [CLA に署名](/docs/contribute/start#sign-the-cla)しており、本プロジェクトに何度も貢献している方です。
|
||||
[Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md)を読んで、会員規約をご確認ください。
|
||||
- _レビュアー_ は、ドキュメントのPRレビューへ関心を示しており、承認者によりすでにGitHubグループ、およびGitHubレポジトリーの`OWNERS`ファイルに追加されているメンバーです。
|
||||
- _承認者_ は、本プロジェクトに継続してコミットできているメンバーです。Kubernetes organizationを代表して、PRをマージしたり、コンテンツを公開することができます。
|
||||
また、Kubernetes コミュニティにおいて、SIG Docsを代表することもできますが、リリースの調整などのように、相応の時間をコミットすることも求められます。
|
||||
|
||||
## 貢献する方法
|
||||
## ドキュメントへの貢献方法
|
||||
|
||||
このリストは、誰でもできること、Kubernetes組織のメンバーができること、そしてより高いレベルのアクセスとSIG Docsプロセスへの精通を必要とすることに分けられます。時間をかけて一貫して貢献することで、すでに行われた作業や組織上の決定について理解するのに役立ちます。
|
||||
以下に挙げたものは、どなたでも可能なこと、Kubernetes organizationメンバーであれば可能なこと、SIG Docsのプロセスにアクセスでき、かつ慣れていないとできないことにわかれています。
|
||||
継続的に貢献していけば、ノウハウや組織的決断を理解する手助けとなるでしょう。
|
||||
|
||||
これはKubernetesのドキュメントに貢献できる方法の網羅的なリストではありませんが、始めるのに役立ちます。
|
||||
これがKubernetesドキュメントへ貢献する方法の全てではないですが、手始めには良いでしょう。
|
||||
|
||||
- [全ての人](/docs/contribute/start/)
|
||||
- 対処可能なバグのファイル
|
||||
- [どなたでも](/docs/contribute/start/)
|
||||
- issue を作成する
|
||||
- [メンバー](/docs/contribute/start/)
|
||||
- 既存のドキュメントの改善
|
||||
- [Slack](http://slack.k8s.io/)または[SIG docsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)で改善のためのアイデアを発案
|
||||
- ドキュメントのアクセシビリティの向上
|
||||
- PRに拘束力のないフィードバックの提供
|
||||
- ブログ記事やケーススタディの執筆・投稿
|
||||
- [レビューワー](/docs/contribute/intermediate/)
|
||||
- 新機能のドキュメンテーション
|
||||
- 問題のトリアージと分類
|
||||
- PRの確認
|
||||
- ダイアグラム、グラフィックアセット、および埋め込み可能なスクリーンキャスト/ビデオの作成
|
||||
- ローカライゼーション
|
||||
- ドキュメントの代表として他のリポジトリに貢献する
|
||||
- コード内のユーザー向け文字列を編集する
|
||||
- Godoc、コードのコメントを改善する
|
||||
- 既存のドキュメントを改善する
|
||||
- 改善のアイデアを[Slack](http://slack.k8s.io/)もしくは[SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)に投げる
|
||||
- ドキュメントのアクセシビリティを改善する
|
||||
- PRにフィードバックをする
|
||||
- 事例やブロクを書く
|
||||
- [レビュアー](/docs/contribute/intermediate/)
|
||||
- 新機能のドキュメントを作成する
|
||||
- issueの選別、分類をする
|
||||
- PRをレビューする
|
||||
- 図表や、グラフィック資産、埋め込み可能な動画などを作成する
|
||||
- 多言語対応
|
||||
- ドキュメントの代表者として別のレポジトリに貢献する
|
||||
- コード内にある、ユーザが使う文字列を編集する
|
||||
- コードのコメントやGodocを改善する
|
||||
- [承認者](/docs/contribute/advanced/)
|
||||
- PRを承認およびマージして寄稿者コンテンツを公開
|
||||
- ドキュメント代表としてKubernetesリリースチームに参加する
|
||||
- スタイルガイドに改善を提案する
|
||||
- docsテストの改善を提案する
|
||||
- KubernetesのWebサイトまたはその他のツールの改良を提案する
|
||||
- PRを承認、マージすることでコントリビューターが作成したコンテンツを公開する
|
||||
- Kubernetesのリリースチームに、ドキュメントを代表して参加する
|
||||
- スタイルガイドの改善を提案する
|
||||
- ドキュメントテストの改善を提案する
|
||||
- Kubernetesのウェブサイトやその他ツールの改善を提案する
|
||||
|
||||
|
||||
## 貢献するその他の方法
|
||||
## その他の貢献方法
|
||||
|
||||
- TwitterやStack Overflowなどのオンラインフォーラムを通じてKubernetesコミュニティに貢献したり、ローカルのミートアップやKubernetesイベントについて学ぶには、[Kubernetesコミュニティサイト](/community/)にアクセスしてください。
|
||||
- 機能の開発に貢献するには、[コントリビューターチートシート](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)を読んで始めてください。
|
||||
- TwitterやStack Overflowといったオンラインフォーラムを通してKubernetesコミュニティに貢献したい方、または各地のミートアップやイベントについて知りたい方は[Kubernetes community site](/community/)へ。
|
||||
- 機能開発に貢献したい方は、まずはじめに[Kubernetesコントリビューターチートシート](https://github.com/kubernetes/community/blob/master/contributors/guide/contributor-cheatsheet/README-ja.md)を読んでください。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -25,7 +25,7 @@ cards:
|
||||
button_path: "/docs/concepts"
|
||||
- name: tutorials
|
||||
title: "Kubernetesを試す"
|
||||
description: "Kubernetesにどのようにアプリケーションを展開するかを、チュートリアルから学びます。"
|
||||
description: "チュートリアルに沿って、Kubernetesにアプリケーションをデプロイする方法を学びます。"
|
||||
button: "チュートリアルを見る"
|
||||
button_path: "/docs/tutorials"
|
||||
- name: setup
|
||||
@@ -52,6 +52,6 @@ cards:
|
||||
title: "Kubernetesをダウンロードする"
|
||||
description: "もしKubernetesをインストールする、また最新バージョンにアップグレードする場合、最新のリリースノートを参照してください。"
|
||||
- name: about
|
||||
title: "ドキュメントについて"
|
||||
description: "このサイトは、Kubernetesの最新バージョンと過去４世代のドキュメントを含んでいます。"
|
||||
title: ドキュメントについて
|
||||
description: このWebサイトには、Kubernetesの最新バージョンと過去4世代のドキュメントが含まれています。
|
||||
---
|
||||
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: リファレンス
|
||||
linkTitle: "Reference"
|
||||
main_menu: true
|
||||
weight: 70
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
本セクションには、Kubernetesのドキュメントのリファレンスが含まれています。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## API Reference
|
||||
|
||||
* [Kubernetes API概要](/docs/reference/using-api/api-overview/) - Kubernetes APIの概要です。
|
||||
* Kubernetes APIバージョン
|
||||
* [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
|
||||
* [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
|
||||
* [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
|
||||
* [1.12](/docs/reference/generated/kubernetes-api/v1.12/)
|
||||
* [1.11](/docs/reference/generated/kubernetes-api/v1.11/)
|
||||
|
||||
## APIクライアントライブラリー
|
||||
|
||||
プログラミング言語からKubernetesのAPIを呼ぶためには、[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使うことができます。公式にサポートしているクライアントライブラリー:
|
||||
|
||||
- [Kubernetes Go client library](https://github.com/kubernetes/client-go/)
|
||||
- [Kubernetes Python client library](https://github.com/kubernetes-client/python)
|
||||
- [Kubernetes Java client library](https://github.com/kubernetes-client/java)
|
||||
- [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript)
|
||||
|
||||
## CLIリファレンス
|
||||
|
||||
* [kubectl](/docs/user-guide/kubectl-overview) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。
|
||||
* [JSONPath](/docs/user-guide/jsonpath/) - kubectlで[JSONPath記法](http://goessner.net/articles/JsonPath/)を使うための構文ガイドです。
|
||||
* [kubeadm](/docs/admin/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。
|
||||
* [kubefed](/docs/admin/kubefed/) - 連合型クラスターを管理するのに役立つCLIツールです。
|
||||
|
||||
## 設定リファレンス
|
||||
|
||||
* [kubelet](/docs/admin/kubelet/) - 各ノード上で動作する最も重要なノードエージェントです。kubeletは一通りのPodSpecを受け取り、コンテナーが実行中で正常であることを確認します。
|
||||
* [kube-apiserver](/docs/admin/kube-apiserver/) - Pod、Service、Replication Controller等、APIオブジェクトのデータを検証・設定するREST APIサーバーです。
|
||||
* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Kubernetesに同梱された、コアのコントロールループを埋め込むデーモンです。
|
||||
* [kube-proxy](/docs/admin/kube-proxy/) - 単純なTCP/UDPストリームのフォワーディングや、一連のバックエンド間でTCP/UDPのラウンドロビンでのフォワーディングを実行できます。
|
||||
* [kube-scheduler](/docs/admin/kube-scheduler/) - 可用性、パフォーマンス、およびキャパシティを管理するスケジューラーです。
|
||||
* [federation-apiserver](/docs/admin/federation-apiserver/) - 連合クラスターのためのAPIサーバーです。
|
||||
* [federation-controller-manager](/docs/admin/federation-controller-manager/) - 連合Kubernetesクラスターに同梱された、コアのコントロールループを埋め込むデーモンです。
|
||||
|
||||
## 設計のドキュメント
|
||||
|
||||
Kubernetesの機能に関する設計ドキュメントのアーカイブです。[Kubernetesアーキテクチャ](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) と[Kubernetesデザイン概要](https://git.k8s.io/community/contributors/design-proposals)から読み始めると良いでしょう。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,308 @@
|
||||
---
|
||||
title: フィーチャーゲート
|
||||
weight: 10
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
このページでは管理者がそれぞれのKubernetesコンポーネントで指定できるさまざまなフィーチャーゲートの概要について説明しています。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 概要
|
||||
|
||||
フィーチャーゲートはアルファ機能または実験的機能を記述するkey=valueのペアのセットです。
|
||||
|
||||
管理者は各コンポーネントで`--feature-gates`コマンドラインフラグを使用することで機能をオンまたはオフにできます。各コンポーネントはそれぞれのコンポーネント固有のフィーチャーゲートの設定をサポートします。
|
||||
すべてのコンポーネントのフィーチャーゲートの全リストを表示するには`-h`フラグを使用します。
|
||||
kubeletなどのコンポーネントにフィーチャーゲートを設定するには以下のようにリストの機能ペアを`--feature-gates`フラグを使用して割り当てます。
|
||||
|
||||
```shell
|
||||
--feature-gates="...,DynamicKubeletConfig=true"
|
||||
```
|
||||
|
||||
次の表は各Kubernetesコンポーネントに設定できるフィーチャーゲートの概要です。
|
||||
|
||||
- 「導入開始バージョン」列は機能が導入されたとき、またはリリース段階が変更されたときのKubernetesリリースバージョンとなります。
|
||||
- 「最終利用可能バージョン」列は空ではない場合はフィーチャーゲートを使用できる最後のKubernetesリリースバージョンとなります。
|
||||
|
||||
| 機能名 | デフォルト値 | ステージ | 導入開始バージョン | 最終利用可能バージョン |
|
||||
|---------|---------|-------|-------|-------|
|
||||
| `Accelerators` | `false` | Alpha | 1.6 | 1.10 |
|
||||
| `AdvancedAuditing` | `false` | Alpha | 1.7 | 1.7 |
|
||||
| `AdvancedAuditing` | `true` | Beta | 1.8 | 1.11 |
|
||||
| `AdvancedAuditing` | `true` | GA | 1.12 | - |
|
||||
| `AffinityInAnnotations` | `false` | Alpha | 1.6 | 1.7 |
|
||||
| `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 |
|
||||
| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - |
|
||||
| `APIListChunking` | `false` | Alpha | 1.8 | 1.8 |
|
||||
| `APIListChunking` | `true` | Beta | 1.9 | |
|
||||
| `APIResponseCompression` | `false` | Alpha | 1.7 | |
|
||||
| `AppArmor` | `true` | Beta | 1.4 | |
|
||||
| `AttachVolumeLimit` | `true` | Alpha | 1.11 | 1.11 |
|
||||
| `AttachVolumeLimit` | `true` | Beta | 1.12 | |
|
||||
| `BlockVolume` | `false` | Alpha | 1.9 | |
|
||||
| `BlockVolume` | `true` | Beta | 1.13 | - |
|
||||
| `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | |
|
||||
| `CPUManager` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `CPUManager` | `true` | Beta | 1.10 | |
|
||||
| `CRIContainerLogRotation` | `false` | Alpha | 1.10 | 1.10 |
|
||||
| `CRIContainerLogRotation` | `true` | Beta| 1.11 | |
|
||||
| `CSIBlockVolume` | `false` | Alpha | 1.11 | 1.13 |
|
||||
| `CSIBlockVolume` | `true` | Beta | 1.14 | |
|
||||
| `CSIDriverRegistry` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `CSIDriverRegistry` | `true` | Beta | 1.14 | |
|
||||
| `CSIInlineVolume` | `false` | Alpha | 1.15 | - |
|
||||
| `CSIMigration` | `false` | Alpha | 1.14 | |
|
||||
| `CSIMigrationAWS` | `false` | Alpha | 1.14 | |
|
||||
| `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | |
|
||||
| `CSIMigrationAzureFile` | `false` | Alpha | 1.15 | |
|
||||
| `CSIMigrationGCE` | `false` | Alpha | 1.14 | |
|
||||
| `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | |
|
||||
| `CSINodeInfo` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `CSINodeInfo` | `true` | Beta | 1.14 | |
|
||||
| `CSIPersistentVolume` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `CSIPersistentVolume` | `true` | Beta | 1.10 | 1.12 |
|
||||
| `CSIPersistentVolume` | `true` | GA | 1.13 | - |
|
||||
| `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
|
||||
| `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 |
|
||||
| `CustomPodDNS` | `true` | GA | 1.14 | - |
|
||||
| `CustomResourcePublishOpenAPI` | `false` | Alpha| 1.14 | 1.14 |
|
||||
| `CustomResourcePublishOpenAPI` | `true` | Beta| 1.15 | |
|
||||
| `CustomResourceSubresources` | `false` | Alpha | 1.10 | 1.11 |
|
||||
| `CustomResourceSubresources` | `true` | Beta | 1.11 | - |
|
||||
| `CustomResourceValidation` | `false` | Alpha | 1.8 | 1.8 |
|
||||
| `CustomResourceValidation` | `true` | Beta | 1.9 | |
|
||||
| `CustomResourceWebhookConversion` | `false` | Alpha | 1.13 | 1.14 |
|
||||
| `CustomResourceWebhookConversion` | `true` | Beta | 1.15 | |
|
||||
| `DebugContainers` | `false` | Alpha | 1.10 | |
|
||||
| `DevicePlugins` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `DevicePlugins` | `true` | Beta | 1.10 | |
|
||||
| `DryRun` | `true` | Beta | 1.13 | |
|
||||
| `DynamicAuditing` | `false` | Alpha | 1.13 | |
|
||||
| `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 |
|
||||
| `DynamicKubeletConfig` | `true` | Beta | 1.11 | |
|
||||
| `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
|
||||
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | |
|
||||
| `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | |
|
||||
| `ExpandCSIVolumes` | `false` | Alpha | 1.14 | |
|
||||
| `ExpandInUsePersistentVolumes` | `false` | Alpha | 1.11 | 1.14 |
|
||||
| `ExpandInUsePersistentVolumes` | `true` | Beta | 1.15 | |
|
||||
| `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 |
|
||||
| `ExpandPersistentVolumes` | `true` | Beta | 1.11 | |
|
||||
| `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | |
|
||||
| `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | |
|
||||
| `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | 1.12 |
|
||||
| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
|
||||
| `HugePages` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `HugePages` | `true` | Beta| 1.10 | 1.13 |
|
||||
| `HugePages` | `true` | GA | 1.14 | |
|
||||
| `HyperVContainer` | `false` | Alpha | 1.10 | |
|
||||
| `Initializers` | `false` | Alpha | 1.7 | 1.13 |
|
||||
| `Initializers` | - | Deprecated | 1.14 | |
|
||||
| `KubeletConfigFile` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `KubeletPluginsWatcher` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `KubeletPluginsWatcher` | `true` | Beta | 1.12 | 1.12 |
|
||||
| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - |
|
||||
| `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
|
||||
| `KubeletPodResources` | `true` | Beta | 1.15 | |
|
||||
| `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 |
|
||||
| `LocalStorageCapacityIsolation` | `true` | Beta| 1.10 | |
|
||||
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha| 1.15 | |
|
||||
| `MountContainers` | `false` | Alpha | 1.9 | |
|
||||
| `MountPropagation` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `MountPropagation` | `true` | Beta | 1.10 | 1.11 |
|
||||
| `MountPropagation` | `true` | GA | 1.12 | |
|
||||
| `NodeLease` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `NodeLease` | `true` | Beta | 1.14 | |
|
||||
| `NonPreemptingPriority` | `false` | Alpha | 1.15 | |
|
||||
| `PersistentLocalVolumes` | `false` | Alpha | 1.7 | 1.9 |
|
||||
| `PersistentLocalVolumes` | `true` | Beta | 1.10 | 1.13 |
|
||||
| `PersistentLocalVolumes` | `true` | GA | 1.14 | |
|
||||
| `PodPriority` | `false` | Alpha | 1.8 | 1.10 |
|
||||
| `PodPriority` | `true` | Beta | 1.11 | 1.13 |
|
||||
| `PodPriority` | `true` | GA | 1.14 | |
|
||||
| `PodReadinessGates` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `PodReadinessGates` | `true` | Beta | 1.12 | 1.13 |
|
||||
| `PodReadinessGates` | `true` | GA | 1.14 | - |
|
||||
| `PodShareProcessNamespace` | `false` | Alpha | 1.10 | |
|
||||
| `PodShareProcessNamespace` | `true` | Beta | 1.12 | |
|
||||
| `ProcMountType` | `false` | Alpha | 1.12 | |
|
||||
| `PVCProtection` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `RemainingItemCount` | `false` | Alpha | 1.15 | |
|
||||
| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | |
|
||||
| `RequestManagement` | `false` | Alpha | 1.15 | |
|
||||
| `ResourceQuotaScopeSelectors` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `ResourceQuotaScopeSelectors` | `true` | Beta | 1.12 | |
|
||||
| `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | |
|
||||
| `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |
|
||||
| `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | |
|
||||
| `RunAsGroup` | `true` | Beta | 1.14 | |
|
||||
| `RuntimeClass` | `true` | Beta | 1.14 | |
|
||||
| `SCTPSupport` | `false` | Alpha | 1.12 | |
|
||||
| `ServerSideApply` | `false` | Alpha | 1.14 | |
|
||||
| `ServiceLoadBalancerFinalizer` | `false` | Alpha | 1.15 | |
|
||||
| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
|
||||
| `StorageObjectInUseProtection` | `true` | Beta | 1.10 | 1.10 |
|
||||
| `StorageObjectInUseProtection` | `true` | GA | 1.11 | |
|
||||
| `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
|
||||
| `StorageVersionHash` | `true` | Beta | 1.15 | |
|
||||
| `StreamingProxyRedirects` | `true` | Beta | 1.5 | |
|
||||
| `SupportIPVSProxyMode` | `false` | Alpha | 1.8 | 1.8 |
|
||||
| `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 |
|
||||
| `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 |
|
||||
| `SupportIPVSProxyMode` | `true` | GA | 1.11 | |
|
||||
| `SupportNodePidsLimit` | `false` | Alpha | 1.14 | 1.14 |
|
||||
| `SupportNodePidsLimit` | `true` | Beta | 1.15 | |
|
||||
| `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 |
|
||||
| `SupportPodPidsLimit` | `true` | Beta | 1.14 | |
|
||||
| `Sysctls` | `true` | Beta | 1.11 | |
|
||||
| `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 |
|
||||
| `TaintBasedEvictions` | `true` | Beta | 1.13 | |
|
||||
| `TaintNodesByCondition` | `false` | Alpha | 1.8 | 1.11 |
|
||||
| `TaintNodesByCondition` | `true` | Beta | 1.12 | |
|
||||
| `TokenRequest` | `false` | Alpha | 1.10 | 1.11 |
|
||||
| `TokenRequest` | `true` | Beta | 1.12 | |
|
||||
| `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `TokenRequestProjection` | `true` | Beta | 1.12 | |
|
||||
| `TTLAfterFinished` | `false` | Alpha | 1.12 | |
|
||||
| `VolumePVCDataSource` | `false` | Alpha | 1.15 | |
|
||||
| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
|
||||
| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
|
||||
| `VolumeScheduling` | `true` | GA | 1.13 | |
|
||||
| `VolumeSubpathEnvExpansion` | `false` | Alpha | 1.14 | 1.14 |
|
||||
| `VolumeSubpathEnvExpansion` | `true` | Beta | 1.15 | |
|
||||
| `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | - |
|
||||
| `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | |
|
||||
| `WatchBookmark` | `false` | Alpha | 1.15 | |
|
||||
| `WindowsGMSA` | `false` | Alpha | 1.14 | |
|
||||
|
||||
## 機能を使用する
|
||||
|
||||
### 機能ステージ
|
||||
|
||||
機能には *Alpha* 、 *Beta* 、 *GA* の段階があります。
|
||||
*Alpha* 機能とは：
|
||||
|
||||
* デフォルトでは無効になっています。
|
||||
* バグがあるかもしれません。機能を有効にするとバグが発生する可能性があります。
|
||||
* 機能のサポートは予告無しにいつでも削除される場合があります。
|
||||
* APIは今後のソフトウェアリリースで予告なく互換性の無い変更が行われる場合があります。
|
||||
* バグが発生するリスクが高く長期的なサポートはないため、短期間のテストクラスターでのみ使用することをお勧めします。
|
||||
|
||||
*Beta* 機能とは：
|
||||
|
||||
* デフォルトで有効になっています。
|
||||
* この機能は十分にテストされていて、有効にすることは安全と考えられます。
|
||||
* 詳細は変更される可能性がありますが、機能全体のサポートは削除されません。
|
||||
* オブジェクトのスキーマやセマンティックは、その後のベータ版または安定版リリースで互換性の無い変更が行われる場合があります。互換性の無い変更が行われた場合には次のバージョンへの移行手順を提供します。これにはAPIオブジェクトの削除、編集、および再作成が必要になる場合があります。バージョンアップにはいくつかの対応が必要な場合があります。これには機能に依存するアプリケーションのダウンタイムが発生する場合があります。
|
||||
* 今後のリリースで互換性の無い変更が行われる可能性があるため、ビジネスクリティカルでない使用のみが推奨されます。個別にアップグレードできる複数のクラスターがある場合はこの制限を緩和できる場合があります。
|
||||
|
||||
{{< note >}}
|
||||
*ベータ版* の機能を試してフィードバックをお寄せください！
|
||||
GAになってからさらなる変更を加えることは現実的ではない場合があります。
|
||||
{{< /note >}}
|
||||
|
||||
*GA* 機能とは(*GA* 機能は *安定版* 機能とも呼ばれます):
|
||||
|
||||
* フィーチャーゲートの設定は不要になります。
|
||||
* 機能の安定版は後続バージョンでリリースされたソフトウェアで使用されます。
|
||||
|
||||
### フィーチャーゲート
|
||||
|
||||
各フィーチャーゲートは特定の機能を有効/無効にするように設計されています。
|
||||
|
||||
- `Accelerators`: DockerでのNvidia GPUのサポートを有効にします。
|
||||
- `AdvancedAuditing`: [高度な監査機能](/docs/tasks/debug-application-cluster/audit/#advanced-audit)を有効にします。
|
||||
- `AffinityInAnnotations`(*非推奨*): [Podのアフィニティまたはアンチアフィニティ](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)を有効にします。
|
||||
- `AllowExtTrafficLocalEndpoints`: サービスが外部へのリクエストをノードのローカルエンドポイントにルーティングできるようにします。
|
||||
- `APIListChunking`: APIクライアントがAPIサーバーからチャンク単位で（`LIST`や`GET`の）リソースを取得できるようにします。
|
||||
- `APIResponseCompression`:`LIST`や`GET`リクエストのAPIレスポンスを圧縮します。
|
||||
- `AppArmor`: Dockerを使用する場合にLinuxノードでAppArmorによる強制アクセスコントロールを有効にします。詳細は[AppArmorチュートリアル](/docs/tutorials/clusters/apparmor/)で確認できます。
|
||||
- `AttachVolumeLimit`: ボリュームプラグインを有効にすることでノードにアタッチできるボリューム数の制限を設定できます。
|
||||
- `BlockVolume`: PodでRawブロックデバイスの定義と使用を有効にします。詳細は[Rawブロックボリュームのサポート](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)で確認できます。
|
||||
- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjectionによって構成される計画ボリュームを使用するにはServiceAccountボリュームを移行します。詳細は[Service Account Token Volumes](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)で確認できます。
|
||||
- `CPUManager`: コンテナレベルのCPUアフィニティサポートを有効します。[CPUマネジメントポリシー](/docs/tasks/administer-cluster/cpu-management-policies/)を見てください。
|
||||
- `CRIContainerLogRotation`: criコンテナランタイムのコンテナログローテーションを有効にします。
|
||||
- `CSIBlockVolume`: 外部CSIボリュームドライバーを有効にしてブロックストレージをサポートします。詳細は[`csi`Rawブロックボリュームのサポート](/docs/concepts/storage/volumes/#csi-raw-block-volume-support)で確認できます。
|
||||
- `CSIDriverRegistry`: csi.storage.k8s.ioのCSIDriver APIオブジェクトに関連するすべてのロジックを有効にします。
|
||||
- `CSIInlineVolume`: PodのCSIインラインボリュームサポートを有効にします。
|
||||
- `CSIMigration`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のプラグインから対応した事前インストール済みのCSIプラグインにルーティングします。
|
||||
- `CSIMigrationAWS`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAWS-EBSプラグインからEBS CSIプラグインにルーティングします。
|
||||
- `CSIMigrationAzureDisk`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-DiskプラグインからAzure Disk CSIプラグインにルーティングします。
|
||||
- `CSIMigrationAzureFile`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のAzure-FileプラグインからAzure File CSIプラグインにルーティングします。
|
||||
- `CSIMigrationGCE`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のGCE-PDプラグインからPD CSIプラグインにルーティングします。
|
||||
- `CSIMigrationOpenStack`: シムと変換ロジックを有効にしてボリューム操作をKubernetesリポジトリー内のCinderプラグインからCinder CSIプラグインにルーティングします。
|
||||
- `CSINodeInfo`: csi.storage.k8s.ioのCSINodeInfo APIオブジェクトに関連するすべてのロジックを有効にします。
|
||||
- `CSIPersistentVolume`: [CSI(Container Storage Interface)]((https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md))互換のボリュームプラグインを通してプロビジョニングされたボリュームの検出とマウントを有効にします。
|
||||
詳細については[`csi`ボリュームタイプ](/docs/concepts/storage/volumes/#csi)ドキュメントを確認してください。
|
||||
- `CustomCPUCFSQuotaPeriod`: ノードがCPUCFSQuotaPeriodを変更できるようにします。
|
||||
- `CustomPodDNS`: `dnsConfig`プロパティを使用したPodのDNS設定のカスタマイズを有効にします。詳細は[PodのDNS構成](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)で確認できます。
|
||||
- `CustomResourcePublishOpenAPI`: CRDのOpenAPI仕様での公開を有効にします。
|
||||
- `CustomResourceSubresources`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースの`/status`および`/scale`サブリソースを有効にします。
|
||||
- `CustomResourceValidation`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのスキーマによる検証を有効にする。
|
||||
- `CustomResourceWebhookConversion`: [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/)から作成されたリソースのWebhookベースの変換を有効にします。
|
||||
- `DebugContainers`: Podのネームスペースで「デバッグ」コンテナを実行できるようにして実行中のPodのトラブルシューティングを行います。
|
||||
- `DevicePlugins`: [device-plugins](/docs/concepts/cluster-administration/device-plugins/)によるノードでのリソースプロビジョニングを有効にします。
|
||||
- `DryRun`: サーバーサイドでの[dry run](/docs/reference/using-api/api-concepts/#dry-run)リクエストを有効にします。
|
||||
- `DynamicAuditing`: [動的監査](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)を有効にします。
|
||||
- `DynamicKubeletConfig`: kubeletの動的構成を有効にします。[kubeletの再設定](/docs/tasks/administer-cluster/reconfigure-kubelet/)を参照してください。
|
||||
- `DynamicProvisioningScheduling`: デフォルトのスケジューラーを拡張してボリュームトポロジーを認識しPVプロビジョニングを処理します。この機能は、v1.12の`VolumeScheduling`機能に完全に置き換えられました。
|
||||
- `DynamicVolumeProvisioning`(*非推奨*): Podへの永続ボリュームの[動的プロビジョニング](/docs/concepts/storage/dynamic-provisioning/)を有効にします。
|
||||
- `EnableEquivalenceClassCache`: Podをスケジュールするときにスケジューラーがノードの同等をキャッシュできるようにします。
|
||||
- `ExpandInUsePersistentVolumes`: 使用中のPVCのボリューム拡張を有効にします。[使用中のPersistentVolumeClaimのサイズ変更](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)を参照してください。
|
||||
- `ExpandPersistentVolumes`: 永続ボリュームの拡張を有効にします。[永続ボリューム要求の拡張](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)を参照してください。
|
||||
- `ExperimentalCriticalPodAnnotation`: [スケジューリングが保証されるよう](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)に特定のpodへの *クリティカル* の注釈を加える設定を有効にします。
|
||||
- `ExperimentalHostUserNamespaceDefaultingGate`: ホストするデフォルトのユーザー名前空間を有効にします。これは他のホストの名前空間やホストのマウントを使用しているコンテナ、特権を持つコンテナ、または名前空間のない特定の機能（たとえば`MKNODE`、`SYS_MODULE`など）を使用しているコンテナ用です。これはDockerデーモンでユーザー名前空間の再マッピングが有効になっている場合にのみ有効にすべきです。
|
||||
- `GCERegionalPersistentDisk`: GCEでリージョナルPD機能を有効にします。
|
||||
- `HugePages`: 事前に割り当てられた[huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/)の割り当てと消費を有効にします。
|
||||
- `HyperVContainer`: Windowsコンテナの[Hyper-Vによる分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)を有効にします。
|
||||
- `KubeletConfigFile`: 設定ファイルを使用して指定されたファイルからのkubelet設定の読み込みを有効にします。詳細は[設定ファイルによるkubeletパラメーターの設定](/docs/tasks/administer-cluster/kubelet-config-file/)で確認できます。
|
||||
- `KubeletPluginsWatcher`: 調査ベースのプラグイン監視ユーティリティを有効にしてkubeletが[CSIボリュームドライバー](/docs/concepts/storage/volumes/#csi)などのプラグインを検出できるようにします。
|
||||
- `KubeletPodResources`: kubeletのpodのリソースgrpcエンドポイントを有効にします。詳細は[デバイスモニタリングのサポート](https://git.k8s.io/community/keps/sig-node/compute-device-assignment.md)で確認できます。
|
||||
- `LocalStorageCapacityIsolation`: [ローカルの一時ストレージ](/docs/concepts/configuration/manage-compute-resources-container/)の消費を有効にして、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)の`sizeLimit`プロパティも有効にします。
|
||||
- `LocalStorageCapacityIsolationFSQuotaMonitoring`: `LocalStorageCapacityIsolation`が[ローカルの一時ストレージ](/docs/concepts/configuration/manage-compute-resources-container/)で有効になっていて、[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)のbacking filesystemがプロジェクトクォータをサポートし有効になっている場合、プロジェクトクォータを使用して、パフォーマンスと精度を向上させるために、ファイルシステムへのアクセスではなく[emptyDirボリューム](/docs/concepts/storage/volumes/#emptydir)ストレージ消費を監視します。
|
||||
- `MountContainers`: ホスト上のユーティリティコンテナをボリュームマウンターとして使用できるようにします。
|
||||
- `MountPropagation`: あるコンテナによってマウントされたボリュームを他のコンテナまたはpodに共有できるようにします。詳細は[マウントの伝播](/docs/concepts/storage/volumes/#mount-propagation)で確認できます。
|
||||
- `NodeLease`: 新しいLease APIを有効にしてノードヘルスシグナルとして使用できるノードのハートビートをレポートします。
|
||||
- `NonPreemptingPriority`: PriorityClassとPodのNonPreemptingオプションを有効にします。
|
||||
- `PersistentLocalVolumes`: Podで`local`ボリュームタイプの使用を有効にします。`local`ボリュームを要求する場合、podアフィニティを指定する必要があります。
|
||||
- `PodPriority`: [優先度](/docs/concepts/configuration/pod-priority-preemption/)に基づいてPodの再スケジューリングとプリエンプションを有効にします。
|
||||
- `PodReadinessGates`: Podのreadinessの評価を拡張するために`PodReadinessGate`フィールドの設定を有効にします。詳細は[Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)で確認できます。
|
||||
- `ProcMountType`: コンテナのProcMountTypeの制御を有効にします。
|
||||
- `PVCProtection`: 永続ボリューム要求（PVC）がPodでまだ使用されているときに削除されないようにします。詳細は[ここ](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
|
||||
- `ResourceLimitsPriorityFunction`: 入力したPodのCPU制限とメモリ制限の少なくとも1つを満たすノードに対して最低スコアを1に割り当てるスケジューラー優先機能を有効にします。その目的は同じスコアを持つノード間の関係を断つことです。
|
||||
- `RequestManagement`: 各サーバーで優先順位付けと公平性を備えたリクエストの並行性の管理機能を有効にしました。
|
||||
- `ResourceQuotaScopeSelectors`: リソース割当のスコープセレクターを有効にします。
|
||||
- `RotateKubeletClientCertificate`: kubeletでクライアントTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
|
||||
- `RotateKubeletServerCertificate`: kubeletでサーバーTLS証明書のローテーションを有効にします。詳細は[kubeletの設定](/docs/tasks/administer-cluster/storage-object-in-use-protection/)で確認できます。
|
||||
- `RunAsGroup`: コンテナの初期化プロセスで設定されたプライマリグループIDの制御を有効にします。
|
||||
- `RuntimeClass`: コンテナのランタイム構成を選択するには[RuntimeClass](/docs/concepts/containers/runtime-class/)機能を有効にします。
|
||||
- `ScheduleDaemonSetPods`: DaemonSetのPodをDaemonSetコントローラーではなく、デフォルトのスケジューラーによってスケジュールされるようにします。
|
||||
- `SCTPSupport`: `Service`、`Endpoint`、`NetworkPolicy`、`Pod`の定義で`protocol`の値としてSCTPを使用できるようにします
|
||||
- `ServerSideApply`: APIサーバーで[サーバーサイドApply(SSA)](/docs/reference/using-api/api-concepts/#server-side-apply)のパスを有効にします。
|
||||
- `ServiceLoadBalancerFinalizer`: サービスロードバランサーのファイナライザー保護を有効にします。
|
||||
- `ServiceNodeExclusion`: クラウドプロバイダーによって作成されたロードバランサーからのノードの除外を有効にします。"`alpha.service-controller.kubernetes.io/exclude-balancer`"キーでラベル付けされている場合ノードは除外の対象となります。
|
||||
- `StorageObjectInUseProtection`: PersistentVolumeまたはPersistentVolumeClaimオブジェクトがまだ使用されている場合、それらの削除を延期します。
|
||||
- `StorageVersionHash`: apiserversがディスカバリーでストレージのバージョンハッシュを公開できるようにします。
|
||||
- `StreamingProxyRedirects`: ストリーミングリクエストのバックエンド(kubelet)からのリダイレクトをインターセプト（およびフォロー）するようAPIサーバーに指示します。ストリーミングリクエストの例には`exec`、`attach`、`port-forward`リクエストが含まれます。
|
||||
- `SupportIPVSProxyMode`: IPVSを使用したクラスター内サービスの負荷分散の提供を有効にします。詳細は[サービスプロキシ](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)で確認できます。
|
||||
- `SupportPodPidsLimit`: PodのPID制限のサポートを有効にします。
|
||||
- `Sysctls`: 各podに設定できる名前空間付きのカーネルパラメーター(sysctl)のサポートを有効にします。詳細は[sysctls](/docs/tasks/administer-cluster/sysctl-cluster/)で確認できます。
|
||||
- `TaintBasedEvictions`: ノードの汚染とpodの許容に基づいてノードからpodを排除できるようにします。。詳細は[汚染と許容](/docs/concepts/configuration/taint-and-toleration/)で確認できます。
|
||||
- `TaintNodesByCondition`: [ノードの条件](/docs/concepts/architecture/nodes/#condition)に基づいてノードの自動汚染を有効にします。
|
||||
- `TokenRequest`: サービスアカウントリソースで`TokenRequest`エンドポイントを有効にします。
|
||||
- `TokenRequestProjection`: [投影ボリューム](/docs/concepts/storage/volumes/#projected)を使用したpodへのサービスアカウントのトークンの注入を有効にします。
|
||||
- `TTLAfterFinished`: [TTLコントローラー](/docs/concepts/workloads/controllers/ttlafterfinished/)が実行終了後にリソースをクリーンアップできるようにします。
|
||||
- `VolumePVCDataSource`: 既存のPVCをデータソースとして指定するサポートを有効にします。
|
||||
- `VolumeScheduling`: ボリュームトポロジー対応のスケジューリングを有効にし、PersistentVolumeClaim（PVC）バインディングにスケジューリングの決定を認識させます。また`PersistentLocalVolumes`フィーチャーゲートと一緒に使用すると[`local`](/docs/concepts/storage/volumes/#local)ボリュームタイプの使用が可能になります。
|
||||
- `VolumeSnapshotDataSource`: ボリュームスナップショットのデータソースサポートを有効にします。
|
||||
- `VolumeSubpathEnvExpansion`: 環境変数を`subPath`に展開するための`subPathExpr`フィールドを有効にします。
|
||||
- `WatchBookmark`: ブックマークイベントの監視サポートを有効にします。
|
||||
- `WindowsGMSA`: GMSA資格仕様をpodからコンテナランタイムに渡せるようにします。
|
||||
|
||||
{{% /capture %}}
|
||||
+18
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: クラスター管理者
|
||||
id: cluster-operator
|
||||
date: 2018-04-12
|
||||
full_link:
|
||||
short_description: >
|
||||
クラスターを設定、管理そして、監視する人
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- user-type
|
||||
---
|
||||
クラスターを設定、管理そして、監視する人
|
||||
|
||||
<!--more-->
|
||||
|
||||
クラスターを稼働させ続けることを主な責務としており、定期的なメンテナンス作業やアップグレード作業も含まれることもあります。<br>
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: コンテナランタイム
|
||||
id: container-runtime
|
||||
date: 2019-06-05
|
||||
full_link: /docs/reference/generated/container-runtime
|
||||
short_description: >
|
||||
コンテナランタイムは、コンテナの実行を担当するソフトウェアです。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- workload
|
||||
---
|
||||
コンテナランタイムは、コンテナの実行を担当するソフトウェアです。
|
||||
|
||||
<!--more-->
|
||||
|
||||
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 (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)
|
||||
実装。
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: コンテナ
|
||||
id: container
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
|
||||
short_description: >
|
||||
軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージ
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- workload
|
||||
---
|
||||
軽量でポータブルなソフトウェアとそのすべての依存関係が含まれている実行可能なイメージ
|
||||
|
||||
<!--more-->
|
||||
|
||||
コンテナはアプリケーションから基盤となるホストインフラストラクチャを分離させ、さまざまなクラウドまたはOS環境での展開を容易にし、スケーリングを容易にします。
|
||||
|
||||
+18
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: コントリビューター
|
||||
id: contributor
|
||||
date: 2018-04-12
|
||||
full_link:
|
||||
short_description: >
|
||||
Kubernetesプロジェクトやコミュニティのために、コード、ドキュメント、またはその他の作業に自身の時間を使って貢献している人々
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- community
|
||||
---
|
||||
Kubernetesプロジェクトやコミュニティのために、コード、ドキュメント、その他に自身の時間を使って貢献している人々
|
||||
|
||||
<!--more-->
|
||||
|
||||
貢献はPull Request（PRs）、Issue、フィードバック、{{< glossary_tooltip text="special interest groups (SIG)" term_id="sig" >}}への参加、またはコミュニティイベントの開催が含まれます。
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: コントロールプレーン
|
||||
id: control-plane
|
||||
date: 2019-05-12
|
||||
full_link:
|
||||
short_description: >
|
||||
コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェイスを公開するコンテナオーケストレーションレイヤーです。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェイスを公開するコンテナオーケストレーションレイヤーです。
|
||||
@@ -11,9 +11,8 @@ tags:
|
||||
- architecture
|
||||
- fundamental
|
||||
---
|
||||
クラスターの状態を{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}}から取得、見張る制御ループで、現在の状態を望ましい状態に移行するように更新します。
|
||||
クラスターの状態を{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}}から取得して監視する制御ループで、現在の状態を望ましい状態に移行するように更新します。
|
||||
|
||||
<!--more-->
|
||||
|
||||
今日、Kubernetesで提供されるコントローラーの例として、レプリケーションコントローラー、エンドポイントコントローラー、名前空間コントローラー、またサービスアカウントコントローラーがあります。
|
||||
|
||||
現在Kubernetesに同梱されているコントローラーの例には、レプリケーションコントローラー、エンドポイントコントローラー、名前空間コントローラー、およびサービスアカウントコントローラーがあります。
|
||||
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: コンテナストレージインターフェイス(CSI)
|
||||
id: csi
|
||||
date: 2018-06-25
|
||||
full_link: /docs/concepts/storage/volumes/#csi
|
||||
short_description: >
|
||||
コンテナストレージインターフェイス(CSI)はストレージシステムをコンテナに公開するための標準インターフェイスを定義します。
|
||||
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- storage
|
||||
---
|
||||
コンテナストレージインターフェイス(CSI)はストレージシステムをコンテナに公開するための標準インターフェイスを定義します。
|
||||
|
||||
<!--more-->
|
||||
|
||||
CSIはベンダーがKubernetesリポジトリにコードを追加することなく(Kubernetesリポジトリツリー外のプラグインとして)独自のストレージプラグインを作成することを可能にします。CSIドライバをストレージプロバイダから利用するには、はじめに[クラスタにCSIプラグインをデプロイする](https://kubernetes-csi.github.io/docs/deploying.html)必要があります。その後のCSIドライバーを使用するための{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}を作成することができます。
|
||||
|
||||
* [KubernetesにおけるCSIのドキュメント](/docs/concepts/storage/volumes/#csi)
|
||||
* [利用可能なCSIドライバの一覧](https://kubernetes-csi.github.io/docs/drivers.html)
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: DaemonSet
|
||||
id: daemonset
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/daemonset
|
||||
short_description: >
|
||||
Podのコピーがクラスター内の一連のNodeに渡って実行されることを保証します。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
- workload
|
||||
---
|
||||
{{< glossary_tooltip text="Pod" term_id="pod" >}}のコピーが{{< glossary_tooltip text="クラスター" term_id="cluster" >}}内の一連のNodeに渡って実行されることを保証します。
|
||||
|
||||
<!--more-->
|
||||
|
||||
通常{{< glossary_tooltip term_id="node" >}}で実行する必要があるログコレクターや監視エージェントなどのシステムデーモンをデプロイするために使用します。
|
||||
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Deployment
|
||||
id: deployment
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/deployment/
|
||||
short_description: >
|
||||
複製されたアプリケーションを管理するAPIオブジェクト。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
- workload
|
||||
---
|
||||
複製されたアプリケーションを管理するAPIオブジェクト。
|
||||
|
||||
<!--more-->
|
||||
|
||||
各レプリカは{{< glossary_tooltip term_id="pod" >}}で表され、ポッドはクラスターのノード間で分散されます。
|
||||
@@ -13,7 +13,8 @@ tags:
|
||||
---
|
||||
一貫性、高可用性を持ったキーバリューストアで、Kubernetesの全てのクラスター情報の保存場所として利用されています。
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
あなたのKubernetesクラスター情報を守るため、etcdのデータのバックアッププランを持っておいて下さい。etcdに関するより詳細な情報は、[etcdドキュメント](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)を確認してください。
|
||||
etcdをKubernetesのデータストアとして使用する場合、必ずデータの[バックアップ](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)プランを作成して下さい。
|
||||
|
||||
公式[ドキュメント](https://etcd.io/docs/)でetcdに関する詳細な情報を見つけることができます。
|
||||
|
||||
Executable
+12
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: Standardized Glossary
|
||||
layout: glossary
|
||||
noedit: true
|
||||
default_active_tag: fundamental
|
||||
weight: 5
|
||||
card:
|
||||
name: reference
|
||||
weight: 10
|
||||
title: Glossary
|
||||
---
|
||||
|
||||
@@ -16,4 +16,3 @@ tags:
|
||||
<!--more-->
|
||||
|
||||
このコンポーネントは、水平スケールするように設計されています。つまり追加でインスタンスを足すことでスケール可能です。さらなる情報は、[高可用性クラスターを構築する](/docs/admin/high-availability/)を確認してください。
|
||||
|
||||
|
||||
@@ -4,16 +4,15 @@ id: kube-controller-manager
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kube-controller-manager/
|
||||
short_description: >
|
||||
マスター上で動く、コントローラー群を動かすコンポーネントです。
|
||||
マスター上に存在し、コントローラーを実行するコンポーネントです。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
- fundamental
|
||||
---
|
||||
マスター上で動く、{{< glossary_tooltip text="controllers" term_id="controller" >}}を動かすコンポーネントです。
|
||||
マスター上に存在し、{{< glossary_tooltip text="controllers" term_id="controller" >}}を実行するコンポーネントです。
|
||||
|
||||
<!--more-->
|
||||
|
||||
論理的には、各{{< glossary_tooltip text="controller" term_id="controller" >}}は、それぞれ別のプロセスですが、複雑になるのを避けるため、一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動きます。
|
||||
|
||||
論理的には、各{{< glossary_tooltip text="controller" term_id="controller" >}}は個別のプロセスですが、複雑になるのを避けるために一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動きます。
|
||||
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: kube-proxy
|
||||
id: kube-proxy
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/command-line-tools-reference/kube-proxy/
|
||||
short_description: >
|
||||
`kube-proxy`はクラスター内の各Nodeで動作しているネットワークプロキシです。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- networking
|
||||
---
|
||||
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) はクラスター内の各Nodeで動作しているネットワークプロキシで、Kubernetesの{{< glossary_tooltip term_id="service">}}コンセプトの一部を実装しています。
|
||||
|
||||
<!--more-->
|
||||
|
||||
kube-proxyは、Nodeのネットワークルールをメンテナンスします。これらのネットワークルールにより、クラスターの内部または外部のネットワークセッションからPodへのネットワーク通信が可能になります。
|
||||
|
||||
kube-proxyは、オペレーティングシステムにパケットフィルタリング層があり、かつ使用可能な場合、パケットフィルタリング層を使用します。それ以外の場合は自身でトラフィックを転送します。
|
||||
@@ -4,15 +4,14 @@ id: kube-scheduler
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kube-scheduler/
|
||||
short_description: >
|
||||
マスター上で動くコンポーネントで、まだノードに紐付けられていない新規に作成されたPodを見張り、稼働させるべきノードを選択します。
|
||||
マスター上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
---
|
||||
マスター上で動くコンポーネントで、まだノードに紐付けられていない新規に作成されたPodを見張り、稼働させるべきノードを選択します。
|
||||
マスター上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。
|
||||
|
||||
<!--more-->
|
||||
|
||||
スケジューリングで考慮される要因は個別、集合的なものを含んでおり、ハードウェア/ソフトウェア/ポリシーの制約、アフィニティ、アンチアフィニティ設定、データの保存位置関係、稼働しているワークロードごとの干渉と処理完了期限があります。
|
||||
|
||||
スケジューリング決定で考慮される要素には、個々および集団のリソース要件、ハードウェア/ソフトウェア/ポリシーの制約、アフィニティおよびアンチアフィニティの指定、データの局所性、ワークロード間の干渉と有効期限が含まれます。
|
||||
|
||||
@@ -4,16 +4,15 @@ id: kubelet
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kubelet
|
||||
short_description: >
|
||||
クラスター内の各ノードで稼働するエージェントです。コンテナがPod内で稼働していることを保証します。
|
||||
クラスター内の各ノードで実行されるエージェントです。各コンテナがPodで実行されていることを保証します。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
---
|
||||
クラスター内の各ノードで稼働するエージェントです。コンテナがPod内で稼働していることを保証します。
|
||||
クラスター内の各ノードで実行されるエージェントです。各コンテナがPodで実行されていることを保証します。
|
||||
|
||||
<!--more-->
|
||||
|
||||
Kubeletは、様々な機構から提供されるPodSpecs情報を受け取り、それらのPodSpecs情報に記述されているコンテナが正常に稼働していることを保証します。Kubeletは、Kubernetes外で作成されたコンテナは管理しません。
|
||||
<!--more-->
|
||||
|
||||
kubeletは、さまざまなメカニズムを通じて提供されるPodSpecのセットを取得し、それらのPodSpecに記述されているコンテナが正常に実行されている状態に保ちます。kubeletは、Kubernetesが作成したものではないコンテナは管理しません。
|
||||
|
||||
Executable
+18
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: メンバー
|
||||
id: member
|
||||
date: 2018-04-12
|
||||
full_link:
|
||||
short_description: >
|
||||
K8sコミュニティの継続的かつアクティブなコントリビューター
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- community
|
||||
---
|
||||
K8sコミュニティの継続的かつアクティブな{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}
|
||||
|
||||
<!--more-->
|
||||
|
||||
メンバーはイシューとPRをアサインすることができ、GitHub teamを通じて{{< glossary_tooltip text="special interest groups (SIGs)" term_id="sig" >}}に参加することが可能です。メンバーのPRではPre-submitテストが自動で走ります。メンバーは、アクティブなコントリビューターとしてコミュニティに居続けることを期待されています。
|
||||
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Namespace
|
||||
id: namespace
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/overview/working-with-objects/namespaces
|
||||
short_description: >
|
||||
同一の物理クラスター上で複数の仮想クラスターをサポートするために使われる抽象概念です。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
同一の物理{{< glossary_tooltip text="クラスター" term_id="cluster" >}}上で複数の仮想クラスターをサポートするために使われる抽象概念です。
|
||||
|
||||
<!--more-->
|
||||
|
||||
Namespaceはクラスター内のオブジェクトをまとめたり、クラスターのリソースを分離するための方法を提供します。
|
||||
リソース名は、Namespace内で一意である必要がありますが、Namespaceをまたいだ場合はその必要はないです。
|
||||
|
||||
Executable
+17
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: ノード
|
||||
id: node
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/architecture/nodes/
|
||||
short_description: >
|
||||
ノードはKubernetesのワーカーマシンです。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
ノードはKubernetesのワーカーマシンです。
|
||||
|
||||
<!--more-->
|
||||
|
||||
ワーカーノードは、クラスターに応じてVMまたは物理マシンの場合があります。{{< glossary_tooltip text="Pod" term_id="pod" >}}の実行に必要なローカルデーモンまたはサービスがあり、コントロールプレーンによって管理されます。ノード上のデーモンには、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}、および{{< glossary_tooltip term_id="docker" >}}などの{{< glossary_tooltip text="CRI" term_id="cri" >}}を実装するコンテナランタイムが含まれます。
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: 永続ボリューム要求
|
||||
id: persistent-volume-claim
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/storage/persistent-volumes/
|
||||
short_description: >
|
||||
コンテナ内でボリュームとしてマウントするためにPersistentVolume内で定義されたストレージリソースを要求します。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- storage
|
||||
---
|
||||
コンテナ内でボリュームとしてマウントするためにPersistentVolume内で定義されたストレージリソースを要求します。
|
||||
|
||||
<!--more-->
|
||||
|
||||
ストレージサイズ、ストレージへのアクセス制御（読み取り専用、読み取り/書き込み、排他的）、および再利用方法（保持、リサイクル、削除）を指定します。ストレージ自体の詳細はPersistentVolumeの仕様にあります。
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: 永続ボリューム
|
||||
id: persistent-volume
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/storage/persistent-volumes/
|
||||
short_description: >
|
||||
クラスター内のストレージの一部を表すAPIオブジェクトです。通常利用可能で、個々のPodのライフサイクルの先にあるプラグイン形式のリソースです。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- storage
|
||||
---
|
||||
クラスター内のストレージの一部を表すAPIオブジェクトです。通常利用可能で、個々の{{< glossary_tooltip text="Pod" term_id="pod" >}}のライフサイクルの先にあるプラグイン形式のリソースです。
|
||||
|
||||
<!--more-->
|
||||
|
||||
PersistentVolume(PV)はストレージの利用方法からストレージの提供方法の詳細を抽象化するAPIを提供します。
|
||||
PVはストレージを事前に作成できるシナリオで直接使用されます（静的プロビジョニング）。
|
||||
オンデマンドストレージ（動的プロビジョニング）を必要とするシナリオでは、代わりにPersistentVolumeClaims(PVC)が使用されます。
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: プラットフォーム開発者
|
||||
id: platform-developer
|
||||
date: 2018-04-12
|
||||
full_link:
|
||||
short_description: >
|
||||
自身のプロジェクトの要件に合わせ、Kubernetesプラットフォームをカスタマイズする人
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- user-type
|
||||
---
|
||||
自身のプロジェクトの要件に合わせ、Kubernetesプラットフォームをカスタマイズする人
|
||||
|
||||
<!--more-->
|
||||
|
||||
プラットフォーム開発者は、特に自身のアプリケーションのために、例えば[カスタムリソース](/docs/concepts/api-extension/custom-resources/)や[集約レイヤーを使ったKubernetes APIの拡張](/docs/concepts/api-extension/apiserver-aggregation/)を用いて、Kubernetesに機能を追加ことがあるかもしれません。一部のプラットフォーム開発者はまた{{< glossary_tooltip text="コントリビューター" term_id="contributor" >}}として、エクステンションを開発しKubernetesのコミュニティに貢献しています。他の方々は、クローズドソースな商用もしくは、サイト固有なエクステンションを開発しています。
|
||||
Executable
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Pod
|
||||
id: pod
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/pods/pod-overview/
|
||||
short_description: >
|
||||
一番小さく一番シンプルな Kubernetes のオブジェクト。Pod とはクラスターで動作しているいくつかのコンテナのまとまりです。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
---
|
||||
一番小さく一番シンプルなKubernetesのオブジェクト。Podとはクラスターで動作しているいくつかの{{< glossary_tooltip text="コンテナ" term_id="container" >}}のまとまりです。
|
||||
|
||||
<!--more-->
|
||||
|
||||
通常、Pod は一つの主コンテナを実行するように設定されます。ロギングなどの補足機能を付加する、取り外し可能なサイドカーコンテナを実行することもできます。Pod は通常 {{< glossary_tooltip term_id="deployment" >}} によって管理されます。
|
||||
|
||||
+17
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: セレクター
|
||||
id: selector
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/overview/working-with-objects/labels/
|
||||
short_description: >
|
||||
ユーザーはラベルに基づいてリソースのリストをフィルタリングできます。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
ユーザーはラベルに基づいてリソースのリストをフィルタリングできます。
|
||||
|
||||
<!--more-->
|
||||
|
||||
セレクターは、リソースのリストを照会して{{< glossary_tooltip text="ラベル" term_id="label" >}}でフィルターするときに適用されます。
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Service
|
||||
id: service
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/services-networking/service/
|
||||
short_description: >
|
||||
Podの集合で実行されているアプリケーションをネットワークサービスとして公開する方法。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
---
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}}の集合で実行されているアプリケーションをネットワークサービスとして公開する抽象的な方法。
|
||||
|
||||
<!--more-->
|
||||
|
||||
Serviceが対象とするPodの集合は、(通常){{< glossary_tooltip text="セレクター" term_id="selector" >}}によって決定されます。
|
||||
Podを追加または削除するとセレクターにマッチしているPodの集合は変更されます。
|
||||
Serviceは、ネットワークトラフィックが現在そのワークロードを処理するPodの集合に向かうことを保証します。
|
||||
Executable
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: SIG (special interest group)
|
||||
id: sig
|
||||
date: 2018-04-12
|
||||
full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-sig-list
|
||||
short_description: >
|
||||
大規模なKubernetesオープンソースプロジェクトにおいて、開発中の部分または側面を集合的に管理するコミュニティのメンバー
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- community
|
||||
---
|
||||
大規模なKubernetesオープンソースプロジェクトにおいて、開発中の部分または側面を集合的に管理する{{< glossary_tooltip text="コミュニティメンバー" term_id="member" >}}
|
||||
|
||||
<!--more-->
|
||||
|
||||
SIGのメンバーは、アーキテクチャ、API machinery、ドキュメンテーションといった、特定のエリアの改善に共通の関心をもっています。
|
||||
SIGは[SIGガバナンス](https://github.com/kubernetes/community/blob/master/sig-governance.md)ガイドラインに準拠していなければなりませんが、独自の貢献ポリシーやコミュニケーションのチャンネルを持つことが可能です。
|
||||
|
||||
さらなる情報は[コミュニティ (kubernetes/community)](https://github.com/kubernetes/community)リポジトリと[SIGとワーキンググループ](https://github.com/kubernetes/community/blob/master/sig-list.md)を参照して下さい。
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: StorageClass
|
||||
id: storageclass
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/storage/storage-classes
|
||||
short_description: >
|
||||
StorageClassは管理者が利用可能なさまざまなストレージタイプを記述する方法を提供します。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- storage
|
||||
---
|
||||
StorageClassは管理者が利用可能なさまざまなストレージタイプを記述する方法を提供します。
|
||||
|
||||
<!--more-->
|
||||
|
||||
StorageClassはサービス品質レベル、バックアップポリシー、クラスター管理者が決定した任意のポリシーにマッピングできます。
|
||||
各StorageClassには`provisioner`、` parameters`、`reclaimPolicy`フィールドが含まれています。これらは、対象のStorageClassの{{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}を動的プロビジョニングする必要がある場合に使用されます。ユーザーはStorageClassオブジェクトの名前を使用して特定のStorageClassを要求できます。
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: ボリューム
|
||||
id: volume
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/storage/volumes/
|
||||
short_description: >
|
||||
ポッド内のコンテナからアクセス可能なデータを含むディレクトリ。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
---
|
||||
{{< glossary_tooltip text="ポッド" term_id="pod" >}}内のコンテナからアクセス可能なデータを含むディレクトリ。
|
||||
|
||||
<!--more-->
|
||||
|
||||
Kubernetesボリュームはボリュームを含む{{< glossary_tooltip text="ポッド" term_id="pod" >}}が存在する限り有効です。そのためボリュームは{{< glossary_tooltip text="ポッド" term_id="pod" >}}内で実行されるすべての{{< glossary_tooltip text="コンテナ" term_id="container" >}}よりも長持ちし、{{< glossary_tooltip text="コンテナ" term_id="container" >}}の再起動後もデータは保持されます。
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
layout: search
|
||||
title: 検索結果
|
||||
---
|
||||
|
||||
@@ -1,78 +1,106 @@
|
||||
---
|
||||
no_issue: true
|
||||
title: セットアップ
|
||||
title: はじめに
|
||||
main_menu: true
|
||||
weight: 30
|
||||
weight: 20
|
||||
content_template: templates/concept
|
||||
card:
|
||||
name: setup
|
||||
weight: 20
|
||||
anchors:
|
||||
- anchor: "#learning-environment"
|
||||
title: 環境について学ぶ
|
||||
- anchor: "#production-environment"
|
||||
title: 本番環境
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
このページを使い、自分のニーズに最も適したソリューションを見つけてください。
|
||||
このセクションではKubernetesをセットアップして動かすための複数のやり方について説明します。
|
||||
|
||||
Kubernetesをどこで実行するかは、利用可能なリソースと必要な柔軟性によって異なります。ノートPCからクラウドプロバイダのVM、ベアメタルのラックまで、ほぼどのような場所でもKubernetesを実行できます。単一のコマンドを実行して完全に管理された
|
||||
を設定したり、ベアメタルで独自にカスタマイズしたクラスタを作成したりすることもできます。
|
||||
各Kubernetesソリューションはそれぞれ、メンテナンス性、セキュリティ、管理、利用可能なリソース、クラスターの運用に専門知識が必要など、異なる要件があります。
|
||||
|
||||
Kubernetesクラスタはローカルマシン、クラウド、オンプレのデータセンターにデプロイすることもできますし、マネージドのKubernetesクラスターを選択することもできます。複数のクラウドプロバイダーやベアメタルの環境に跨ったカスタムソリューションを選ぶことも可能です。
|
||||
|
||||
簡潔に言えば、学習用としても、本番環境用としてもKubernetesクラスターを作成することができます。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## ローカルマシンソリューション
|
||||
## 環境について学ぶ
|
||||
|
||||
ローカルマシンソリューションは、Kubernetesを使い始めるための簡単な方法です。クラウドリソースと、割当量の消費を気にせずにKubernetesクラスタを作成してテストできます。
|
||||
Kubernetesについて学んでいる場合、Dockerベースのソリューションを使いましょう。これらはKubernetesコミュニティにサポートされていたり、あるいはKubernetesクラスターをローカル環境にセットアップするエコシステムを持っていたりします。
|
||||
|
||||
もし以下のようなことを実現したいのであれば、ローカルマシンソリューションを選ぶべきです:
|
||||
{{< table caption="Local machine solutions table that lists the tools supported by the community and the ecosystem to deploy Kubernetes." >}}
|
||||
|
||||
* Kubernetesの検証や勉強
|
||||
* ローカルでのクラスタの開発やテスト
|
||||
|コミュニティ |エコシステム |
|
||||
| ------------ | -------- |
|
||||
| [Minikube](/ja/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
|
||||
| [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
|
||||
| [Kubernetes IN Docker](https://github.com/kubernetes-sigs/kind) | [Minishift](https://docs.okd.io/latest/minishift/)|
|
||||
| | [MicroK8s](https://microk8s.io/)|
|
||||
| | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
|
||||
| | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
|
||||
| | [k3s](https://k3s.io)|
|
||||
| | [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/)|
|
||||
|
||||
[ローカルマシンソリューション](/docs/setup/pick-right-solution/#local-machine-solutions)を選ぶ
|
||||
|
||||
## ホスト型ソリューション
|
||||
## 本番環境
|
||||
|
||||
ホスト型ソリューションは、Kubernetesクラスタを作成および管理するためには便利な方法です。自身で管理せずとも、ホスティングプロバイダがクラスタを管理、運用します。
|
||||
本番環境用のソリューションを評価する際には、Kubernetesクラスター(または抽象レイヤ)の運用においてどの部分を自分で管理し、どの部分をプロバイダーに任せるのかを考慮してください。
|
||||
|
||||
もし以下のようなことを実現したいのであれば、ホスト型ソリューションを選ぶべきです:
|
||||
Kubernetesクラスタにおける抽象レイヤには {{< glossary_tooltip text="アプリケーション" term_id="applications" >}}、 {{< glossary_tooltip text="データプレーン" term_id="data-plane" >}}、 {{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}、 {{< glossary_tooltip text="クラスターインフラ" term_id="cluster-infrastructure" >}}、 {{< glossary_tooltip text="そして、クラスター運用" term_id="cluster-operations" >}}があります。
|
||||
|
||||
* 完全に管理されたソリューションが欲しい
|
||||
* アプリケーションやサービスの開発に集中したい
|
||||
* 専用のSite Reliability Engineering (SRE)チームはないが、高可用性を求めている
|
||||
* クラスタをホストしたり、監視したりするためのリソースがない
|
||||
次の図は、Kubernetesクラスターの抽象レイヤ一覧と、それぞれの抽象レイヤを自分で管理するのか、プロバイダによって管理されているのかを示しています。
|
||||
|
||||
[ホスト型ソリューション](/docs/setup/pick-right-solution/#hosted-solutions)を選ぶ
|
||||
本番環境のソリューション
|
||||
|
||||
## ターンキークラウドソリューション
|
||||
{{< table caption="Production environment solutions table lists the providers and the solutions." >}}
|
||||
次の表は、各プロバイダーとそれらが提供するソリューションを一覧にしたものです。
|
||||
|
||||
このソリューションを使用すると、わずかなコマンドでKubernetesクラスタが作成できます。また、積極的に開発されており、積極的なコミュニティサポートを受けています。さまざまなCloud IaaSプロバイダでホストすることもできますが、努力と引き換えに、より多くの自由と柔軟性を提供します。
|
||||
|
||||
もし以下のようなことを実現したいのであれば、ターンキークラウドソリューションを選ぶべきです:
|
||||
|
||||
* ホスト型ソリューションが許可する以上に、クラスタをもっと制御したい
|
||||
* より多くのオペレーションの所有権を引き受けたい
|
||||
|
||||
[ターンキークラウドソリューション](/docs/setup/pick-right-solution/#turnkey-cloud-solutions)を選ぶ
|
||||
|
||||
## ターンキーオンプレミスソリューション
|
||||
|
||||
このソリューションを使用すると、内部の安全なクラウドネットワーク上に、少ないコマンドでKubernetesクラスタを作成できます。
|
||||
|
||||
もし以下のようなことを実現したいのであれば、ターンキーオンプレミスソリューションを選ぶべきです:
|
||||
|
||||
* プライベートクラウド内にクラスタを配置したい
|
||||
* 専用のSREチームがいる
|
||||
* クラスタをホストし、監視するためのリソースを持っている
|
||||
|
||||
[ターンキーオンプレミスソリューション](/docs/setup/pick-right-solution/#on-premises-turnkey-cloud-solutions)を選ぶ
|
||||
|
||||
## カスタムソリューション
|
||||
|
||||
カスタムソリューションは、クラスタに対して最も自由度が高いですが、専門知識が最も必要になります。このソリューションは、数多くのオペレーティングシステム上のベアメタルからクラウドプロバイダまで、多岐にわたります。
|
||||
|
||||
[カスタムソリューション](/docs/setup/pick-right-solution/#custom-solutions)を選ぶ
|
||||
|プロバイダー | マネージド | 即時利用可能 | オンプレDC | カスタム(クラウド) | カスタム(オンプレVM)| カスタム(ベアメタル) |
|
||||
| --------- | ------ | ------ | ------ | ------ | ------ | ----- |
|
||||
| [Agile Stacks](https://www.agilestacks.com/products/kubernetes)| | ✔ | ✔ | | |
|
||||
| [Alibaba Cloud](https://www.alibabacloud.com/product/kubernetes)| | ✔ | | | |
|
||||
| [Amazon](https://aws.amazon.com) | [Amazon EKS](https://aws.amazon.com/eks/) |[Amazon EC2](https://aws.amazon.com/ec2/) | | | |
|
||||
| [AppsCode](https://appscode.com/products/pharmer/) | ✔ | | | | |
|
||||
| [APPUiO](https://appuio.ch/) | ✔ | ✔ | ✔ | | | |
|
||||
| [CenturyLink Cloud](https://www.ctl.io/) | | ✔ | | | |
|
||||
| [Cisco Container Platform](https://cisco.com/go/containers) | | | ✔ | | |
|
||||
| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | ✔ |✔ |
|
||||
| [CloudStack](https://cloudstack.apache.org/) | | | | | ✔|
|
||||
| [Canonical](https://www.ubuntu.com/kubernetes/docs/quickstart) | | ✔ | | ✔ |✔ | ✔
|
||||
| [Containership](https://containership.io/containership-platform) | ✔ |✔ | | | |
|
||||
| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔
|
||||
| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | |
|
||||
| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔
|
||||
| [Fedora (Multi Node)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | | | | ✔ | ✔
|
||||
| [Fedora (Single Node)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/) | | | | | | ✔
|
||||
| [Gardener](https://gardener.cloud/) | |✔ | | ✔ | |
|
||||
| [Giant Swarm](https://giantswarm.io/) | ✔ | ✔ | ✔ | |
|
||||
| [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | |
|
||||
| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
|
||||
| [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | |
|
||||
| [Kubermatic](https://www.loodse.com/) | ✔ | ✔ | ✔ | | |
|
||||
| [KubeSail](https://kubesail.com/) | ✔ | | | | |
|
||||
| [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ |
|
||||
| [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ |
|
||||
| [Microsoft Azure](https://azure.microsoft.com) | [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/) | | | | |
|
||||
| [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) | | | ✔ | | |
|
||||
| [Nirmata](https://www.nirmata.com/) | | ✔ | ✔ | | |
|
||||
| [Nutanix](https://www.nutanix.com/en) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | | | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization) |
|
||||
| [OpenShift](https://www.openshift.com) |[OpenShift Dedicated](https://www.openshift.com/products/dedicated/) and [OpenShift Online](https://www.openshift.com/products/online/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) |[OpenShift Container Platform](https://www.openshift.com/products/container-platform/)
|
||||
| [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | ✔ | ✔ | | | |
|
||||
| [oVirt](https://www.ovirt.org/) | | | | | ✔ |
|
||||
| [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | | |
|
||||
| [Platform9](https://platform9.com/) | ✔ | ✔ | ✔ | | ✔ |✔
|
||||
| [Rancher](https://rancher.com/) | | [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/) | | [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) | | [k3s](https://k3s.io/)
|
||||
| [StackPoint](https://stackpoint.io/) | ✔ | ✔ | | | |
|
||||
| [Supergiant](https://supergiant.io/) | |✔ | | | |
|
||||
| [SUSE](https://www.suse.com/) | | ✔ | | | |
|
||||
| [SysEleven](https://www.syseleven.io/) | ✔ | | | | |
|
||||
| [VEXXHOST](https://vexxhost.com/) | ✔ | ✔ | | | |
|
||||
| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
ソリューションの完全なリストを見るには、[正しいソリューションの選択](/docs/setup/pick-right-solution/) に進んでください。
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: ベストプラクティス
|
||||
weight: 40
|
||||
---
|
||||
+9
-8
@@ -1,6 +1,7 @@
|
||||
---
|
||||
title: PKI証明書とその要件
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
@@ -61,8 +62,8 @@ Required certificates:
|
||||
|
||||
| Default CN | Parent CA | O (in Subject) | kind | hosts (SAN) |
|
||||
|-------------------------------|---------------------------|----------------|----------------------------------------|---------------------------------------------|
|
||||
| kube-etcd | etcd-ca | | server, client [<sup>1</sup>][etcdbug] | `localhost`, `127.0.0.1` |
|
||||
| kube-etcd-peer | etcd-ca | | server, client | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
|
||||
| kube-etcd | etcd-ca | | server, client | `localhost`, `127.0.0.1` |
|
||||
| kube-etcd-peer | etcd-ca | | server, client | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
|
||||
| kube-etcd-healthcheck-client | etcd-ca | | client | |
|
||||
| kube-apiserver-etcd-client | etcd-ca | system:masters | client | |
|
||||
| kube-apiserver | kubernetes-ca | | server | `<hostname>`, `<Host_IP>`, `<advertise_IP>`, `[1]` |
|
||||
@@ -82,17 +83,17 @@ where `kind` maps to one or more of the [x509 key usage][usage] types:
|
||||
|
||||
Certificates should be placed in a recommended path (as used by [kubeadm][kubeadm]). Paths should be specified using the given argument regardless of location.
|
||||
|
||||
| Default CN | recommend key path | recommended cert path | command | key argument | cert argument |
|
||||
| Default CN | recommended key path | recommended cert path | command | key argument | cert argument |
|
||||
|------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
|
||||
| etcd-ca | | etcd/ca.crt | kube-apiserver | | --etcd-cafile |
|
||||
| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile |
|
||||
| etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile |
|
||||
| kubernetes-ca | | ca.crt | kube-apiserver | | --client-ca-file |
|
||||
| kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file |
|
||||
| kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file |
|
||||
| apiserver-kubelet-client | | apiserver-kubelet-client.crt| kube-apiserver | | --kubelet-client-certificate |
|
||||
| front-proxy-ca | | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file |
|
||||
| apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt| kube-apiserver | | --kubelet-client-certificate |
|
||||
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file |
|
||||
| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file |
|
||||
| | | | | | |
|
||||
| etcd-ca | | etcd/ca.crt | etcd | | --trusted-ca-file, --peer-trusted-ca-file |
|
||||
| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | --trusted-ca-file, --peer-trusted-ca-file |
|
||||
| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file |
|
||||
| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file |
|
||||
| etcd-ca | | etcd/ca.crt | etcdctl[2] | | --cacert |
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 大規模クラスタの構築
|
||||
weight: 80
|
||||
weight: 20
|
||||
---
|
||||
|
||||
## サポート
|
||||
+5
-5
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 複数のゾーンで動かす
|
||||
weight: 90
|
||||
weight: 10
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
@@ -185,10 +185,10 @@ kubernetes-minion-wf8i Ready <none> 2m v1.13.0
|
||||
Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
|
||||
|
||||
```json
|
||||
kubectl create -f - <<EOF
|
||||
kubectl apply -f - <<EOF
|
||||
{
|
||||
"kind": "PersistentVolumeClaim",
|
||||
"apiVersion": "v1",
|
||||
"kind": "PersistentVolumeClaim",
|
||||
"metadata": {
|
||||
"name": "claim1",
|
||||
"annotations": {
|
||||
@@ -236,9 +236,9 @@ Because GCE PDs / AWS EBS volumes cannot be attached across zones,
|
||||
this means that this pod can only be created in the same zone as the volume:
|
||||
|
||||
```yaml
|
||||
kubectl create -f - <<EOF
|
||||
kind: Pod
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: mypod
|
||||
spec:
|
||||
+1
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: ノードのセットアップの検証
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: カスタムクラウドソリューション
|
||||
weight: 50
|
||||
---
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
title: AWSまたはGCE上のCoreOS
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
There are multiple guides on running Kubernetes with [CoreOS](https://coreos.com/kubernetes/docs/latest/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 公式CoreOSガイド
|
||||
|
||||
These guides are maintained by CoreOS and deploy Kubernetes the "CoreOS Way" with full TLS, the DNS add-on, and more. These guides pass Kubernetes conformance testing and we encourage you to [test this yourself](https://coreos.com/kubernetes/docs/latest/conformance-tests.html).
|
||||
|
||||
* [**AWS Multi-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html)
|
||||
|
||||
Guide and CLI tool for setting up a multi-node cluster on AWS.
|
||||
CloudFormation is used to set up a master and multiple workers in auto-scaling groups.
|
||||
|
||||
* [**Bare Metal Multi-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-baremetal.html#automated-provisioning)
|
||||
|
||||
Guide and HTTP/API service for PXE booting and provisioning a multi-node cluster on bare metal.
|
||||
[Ignition](https://coreos.com/ignition/docs/latest/) is used to provision a master and multiple workers on the first boot from disk.
|
||||
|
||||
* [**Vagrant Multi-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant.html)
|
||||
|
||||
Guide to setting up a multi-node cluster on Vagrant.
|
||||
The deployer can independently configure the number of etcd nodes, master nodes, and worker nodes to bring up a fully HA control plane.
|
||||
|
||||
* [**Vagrant Single-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant-single.html)
|
||||
|
||||
The quickest way to set up a Kubernetes development environment locally.
|
||||
As easy as `git clone`, `vagrant up` and configuring `kubectl`.
|
||||
|
||||
* [**Full Step by Step Guide**](https://coreos.com/kubernetes/docs/latest/getting-started.html)
|
||||
|
||||
A generic guide to setting up an HA cluster on any cloud or bare metal, with full TLS.
|
||||
Repeat the master or worker steps to configure more machines of that role.
|
||||
|
||||
## コミュニティガイド
|
||||
|
||||
These guides are maintained by community members, cover specific platforms and use cases, and experiment with different ways of configuring Kubernetes on CoreOS.
|
||||
|
||||
* [**Easy Multi-node Cluster on Google Compute Engine**](https://github.com/rimusz/coreos-multi-node-k8s-gce/blob/master/README.md)
|
||||
|
||||
Scripted installation of a single master, multi-worker cluster on GCE.
|
||||
Kubernetes components are managed by [fleet](https://github.com/coreos/fleet).
|
||||
|
||||
* [**Multi-node cluster using cloud-config and Weave on Vagrant**](https://github.com/errordeveloper/weave-demos/blob/master/poseidon/README.md)
|
||||
|
||||
Configure a Vagrant-based cluster of 3 machines with networking provided by Weave.
|
||||
|
||||
* [**Multi-node cluster using cloud-config and Vagrant**](https://github.com/pires/kubernetes-vagrant-coreos-cluster/blob/master/README.md)
|
||||
|
||||
Configure a single master, multi-worker cluster locally, running on your choice of hypervisor: VirtualBox, Parallels, or VMware
|
||||
|
||||
* [**Single-node cluster using a small macOS App**](https://github.com/rimusz/kube-solo-osx/blob/master/README.md)
|
||||
|
||||
Guide to running a solo cluster (master + worker) controlled by an macOS menubar application.
|
||||
Uses xhyve + CoreOS under the hood.
|
||||
|
||||
* [**Multi-node cluster with Vagrant and fleet units using a small macOS App**](https://github.com/rimusz/coreos-osx-gui-kubernetes-cluster/blob/master/README.md)
|
||||
|
||||
Guide to running a single master, multi-worker cluster controlled by an macOS menubar application.
|
||||
Uses Vagrant under the hood.
|
||||
|
||||
* [**Multi-node cluster using cloud-config, CoreOS and VMware ESXi**](https://github.com/xavierbaude/VMware-coreos-multi-nodes-Kubernetes)
|
||||
|
||||
Configure a single master, single worker cluster on VMware ESXi.
|
||||
|
||||
* [**Single/Multi-node cluster using cloud-config, CoreOS and Foreman**](https://github.com/johscheuer/theforeman-coreos-kubernetes)
|
||||
|
||||
Configure a standalone Kubernetes or a Kubernetes cluster with [Foreman](https://theforeman.org).
|
||||
|
||||
## サポートレベル
|
||||
|
||||
|
||||
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
|
||||
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
|
||||
GCE | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos) | | Community ([@pires](https://github.com/pires))
|
||||
Vagrant | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos) | | Community ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles))
|
||||
|
||||
For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
title: "kubeadmによるClusterのブートストラッピング"
|
||||
weight: 30
|
||||
---
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: 環境について学ぶ
|
||||
weight: 20
|
||||
---
|
||||
@@ -1,305 +0,0 @@
|
||||
---
|
||||
title: 正しいソリューションの選択
|
||||
weight: 10
|
||||
content_template: templates/concept
|
||||
card:
|
||||
name: setup
|
||||
weight: 20
|
||||
anchors:
|
||||
- anchor: "#ホスティングを使ったソリューション"
|
||||
title: ホスティングを使ったソリューション
|
||||
- anchor: "#すぐに利用できるクラウドを使ったソリューション"
|
||||
title: すぐに利用できるクラウドを使ったソリューション
|
||||
- anchor: "#すぐに利用できるオンプレミスを使ったソリューション"
|
||||
title: すぐに利用できるオンプレミスを使ったソリューション
|
||||
- anchor: "#カスタムソリューション"
|
||||
title: カスタムソリューション
|
||||
- anchor: "#ローカルマシンを使ったソリューション"
|
||||
title: ローカルマシンを使ったソリューション
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Kubernetesは様々なプラットフォームで動作することができます: PCから、クラウドプロバイダーのVM、ベアメタルサーバーのラックまで。
|
||||
クラスターをセットアップするために必要な作業は、単一のコマンドを実行することからカスタマイズされたクラスターを作り上げるまで異なります。このガイドを使用して、ニーズに合ったソリューションを選択してください。
|
||||
|
||||
Kubernetesを少し試したいだけであれば、[ローカルマシンを使ったソリューション](#ローカルマシンを使ったソリューション)を使用してください。
|
||||
|
||||
より多くのマシンと高い可用性にスケールアップする準備がある場合、[ホスティングを使ったソリューション](#ホスティングを使ったソリューション)で作成して保守するのが最も簡単です。
|
||||
|
||||
[すぐに利用できるクラウドを使ったソリューション](#すぐに利用できるクラウドを使ったソリューション)は様々なクラウドプロバイダーを作成してカバーするために必要なコマンドはわずかで済みます。[すぐに利用できるオンプレミスを使ったソリューション](#すぐに利用できるオンプレミスを使ったソリューション)には、プライベートネットワークのセキュリティと組み合わせたすぐに利用できるクラウドソリューションのシンプルさがあります。
|
||||
|
||||
すでにホスティングサービスを設定する方法がある場合は、[kubeadm](/docs/setup/independent/create-cluster-kubeadm/)を使用して、マシン毎に単一のコマンドでクラスターを簡単に起動できます。
|
||||
|
||||
[カスタムソリューション](#カスタムソリューション)は段階的な手順からセットアップの一般的なアドバイスまで様々あります。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## ローカルマシンを使ったソリューション
|
||||
|
||||
* [Minikube](/docs/setup/minikube/)は開発とテスト用にローカルの単一ノードのKubernetesクラスターを作成するための方法です。セットアップは完全に自動化されており、クラウドプロバイダーのアカウントは必要ありません。
|
||||
|
||||
* [Docker Desktop](https://www.docker.com/products/docker-desktop)は
|
||||
MacまたはWindows環境に簡単にインストールできるアプリケーションで、
|
||||
単一ノードのKubernetesクラスターを使用して、
|
||||
数分でコーディングとコンテナへのデプロイを開始できます。
|
||||
|
||||
* [Minishift](https://docs.okd.io/latest/minishift/)は、ローカル開発およびテスト用にKubernetesエンタープライズプラットフォームのOpenShiftのコミュニティーバージョンをインストールします。Windows、MacOS、Linux用のオールインワンのVM (`minishift start`)を提供します。コンテナの起動は`oc cluster up`に基づいています (Linuxのみ)。[付属のアドオン](https://github.com/minishift/minishift-addons/tree/master/add-ons)をインストールすることもできます。
|
||||
|
||||
* [MicroK8s](https://microk8s.io/)は、開発とテスト用にローカルマシンに最新リリースのKubernetesを単一コマンドでのインストールを可能にします。セットアップは素早く、速く(〜30秒)て、lstioを含む多くのプラグインを単一コマンドでサポートします。
|
||||
|
||||
* [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private)は、開発とテストシナリオ用に、ご自身のマシンでVirtualBoxを使って1つ以上のVMにKubernetesをデプロイすることができます。フルマルチノードのクラスターに拡張します。
|
||||
|
||||
* [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)は、Linuxホスト上に7ノード(1ブート、1マスター、1マネジメント、1プロキシー、3ワーカー)のLXDクラスターを作成するためのTerraform/Packer/BASHベースのInfrastructure as Code（IaC）のスクリプトです。
|
||||
|
||||
* [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster)は、(Minikubeが単一ノードであることに対して)マルチノードのKubernetesクラスターで、Dockerデーモンのみが必要です。Kubernetesクラスターを生成するためにdocker-in-docker技術を使います。
|
||||
|
||||
* [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/local/)は、ローカルホスト上の9インスタンスのデプロイをサポートします。
|
||||
|
||||
## ホスティングを使ったソリューション
|
||||
|
||||
* [AppsCode.com](https://appscode.com/products/cloud-deployment/)は、AWSやGoogle Cloud Platformなどの様々なパブリッククラウド用のマネージドなKubernetesクラスターを提供します。
|
||||
|
||||
* [APPUiO](https://appuio.ch)は、OpenShiftのパブリッククラウドプラットフォームを実行し、あらゆるKubernetesワークロードをサポートします。さらにAPPUiOは、パブリッククラウドまたはプライベートクラウド上で動作するPrivate Managed OpenShift Clustersを提供します。
|
||||
|
||||
* [Amazon Elastic Container Service for Kubernetes](https://aws.amazon.com/eks/)は、マネージドなKubernetesサービスを提供します。
|
||||
|
||||
* [Azure Kubernetes Service](https://azure.microsoft.com/services/container-service/)は、マネージドなKubernetesクラスターを提供します。
|
||||
|
||||
* [Containership Kubernetes Engine (CKE)](https://containership.io/containership-platform) GCP、Azure、AWS、Packet、DigitalOceanでの直感的なKubernetesクラスターのプロビジョニングと管理。シームレスなバージョンアップグレード、自動スケーリング、メトリック、ワークロードの作成など。
|
||||
|
||||
* [DigitalOcean Kubernetes](https://www.digitalocean.com/products/kubernetes/)は、マネージドなKubernetesサービスを提供します。
|
||||
|
||||
* [Giant Swarm](https://giantswarm.io/product/)は、独自のデータセンター、オンプレミス、またはパブリッククラウド上にマネージドなKubernetesクラスターを提供します。
|
||||
|
||||
* [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)は、マネージドなKubernetesクラスターを提供します。
|
||||
|
||||
* [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index)は、アイソレーションの選択、運用ツール、イメージとコンテナーへの統合されたセキュリティーのインサイト、およびWatson、IoT、データとの統合を備えたマネージドなKubernetesクラスターを提供します。
|
||||
|
||||
* [Kubermatic](https://www.loodse.com)は、AWSやDigital Oceanなどの様々なパブリッククラウド用のマネージドなKubernetesクラスターを提供するだけでなく、OpenStackと統合されたオンプレミスも提供します。
|
||||
|
||||
* [Kublr](https://kublr.com)は、AWS、Azure、GCP、およびオンプレミスで、エンタープライズ級の安全でスケーラブルで信頼性の高いKubernetesクラスターを提供します。すぐに使用可能なバックアップとディザスターリカバリ、集中管理されたマルチクラスターのログ記録とモニタリング、および組み込みのアラートが含まれます。
|
||||
|
||||
* [KubeSail](https://kubesail.com)は、簡単にKubernetesを試すことができる近道です。
|
||||
|
||||
* [Madcore.Ai](https://madcore.ai)は、AWSにKubernetesインフラストラクチャーをデプロイするためのDevOpsにフォーカスしたCLIツールです。マスター、スポットインスタンスを使ったオートスケーリンググループのノード、ingress-ssl-lego、Heapster、およびGrafana。
|
||||
|
||||
* [Nutanix Karbon](https://www.nutanix.com/products/karbon/)は、Kubernetesのプロビジョニング、運用、ライフサイクル管理を簡素化する、マルチクラスターで可用性の高いKubernetes管理および運用プラットフォームです。
|
||||
|
||||
* [OpenShift Dedicated](https://www.openshift.com/dedicated/)は、OpenShiftを搭載したマネージドなKubernetesクラスターを提供します。
|
||||
|
||||
* [OpenShift Online](https://www.openshift.com/features/)は、Kubernetesアプリケーションに無料のホストアクセスを提供します。
|
||||
|
||||
* [Oracle Container Engine for Kubernetes](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengoverview.htm)は、コンテナ化されたアプリケーションをクラウドにデプロイするために使用できる、フルマネージドかつスケーラブルで可用性の高いサービスです。
|
||||
|
||||
* [Platform9](https://platform9.com/products/kubernetes/)は、オンプレミスまたはパブリッククラウド上でマネージドなKubernetesを提供し、24時間365日のヘルスモニタリングとアラートを提供します。（Kube2goは、Web UIによって駆動されるKubernetesクラスターデプロイメントサービスであるPlatform9がリリースされ、Platform9 Sandboxに統合されました）
|
||||
|
||||
* [Stackpoint.io](https://stackpoint.io)は、複数のパブリッククラウドに対してKubernetesインフラストラクチャーの自動化と管理を提供します。
|
||||
|
||||
* [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/)は、OpenStackのパブリッククラウドを基盤とするサービスとしてマネージドなKubernetesを提供します。ライフサイクル管理、管理ダッシュボード、モニタリング、自動スケーリングなどが含まれます。
|
||||
|
||||
* [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)は、VMware Cloud ServicesポートフォリオのエンタープライズのKubernetes-as-a-Serviceであり、使いやすく、デフォルトで安全、かつ費用対効果の高いSaaSベースのKubernetesクラスターを提供します。
|
||||
|
||||
## すぐに利用できるクラウドを使ったソリューション
|
||||
|
||||
これらのソリューションを使用すると、ほんの少しのコマンドで、様々なCloud IaaSプロバイダー上にKubernetesクラスターを作成できます。
|
||||
これらのソリューションはアクティブに開発されており、またアクティブなコミュニティー支援を受けています。
|
||||
|
||||
* [Agile Stacks](https://www.agilestacks.com/products/kubernetes)
|
||||
* [Alibaba Cloud](/docs/setup/turnkey/alibaba-cloud/)
|
||||
* [APPUiO](https://appuio.ch)
|
||||
* [AWS](/docs/setup/turnkey/aws/)
|
||||
* [Azure](/docs/setup/turnkey/azure/)
|
||||
* [CenturyLink Cloud](/docs/setup/turnkey/clc/)
|
||||
* [Conjure-up Kubernetes with Ubuntu on AWS, Azure, Google Cloud, Oracle Cloud](/docs/getting-started-guides/ubuntu/)
|
||||
* [Containership](https://containership.io/containership-platform)
|
||||
* [Docker Enterprise](https://www.docker.com/products/docker-enterprise)
|
||||
* [Gardener](https://gardener.cloud/)
|
||||
* [Giant Swarm](https://giantswarm.io)
|
||||
* [Google Compute Engine (GCE)](/docs/setup/turnkey/gce/)
|
||||
* [IBM Cloud](https://github.com/patrocinio/kubernetes-softlayer)
|
||||
* [Kontena Pharos](https://kontena.io/pharos/)
|
||||
* [Kubermatic](https://cloud.kubermatic.io)
|
||||
* [Kublr](https://kublr.com/)
|
||||
* [Madcore.Ai](https://madcore.ai/)
|
||||
* [Nirmata](https://nirmata.com/)
|
||||
* [Nutanix Karbon](https://www.nutanix.com/products/karbon/)
|
||||
* [Oracle Container Engine for K8s](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengprerequisites.htm)
|
||||
* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service)
|
||||
* [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/)
|
||||
* [Stackpoint.io](/docs/setup/turnkey/stackpoint/)
|
||||
* [Supergiant.io](https://supergiant.io/)
|
||||
* [Tectonic by CoreOS](https://coreos.com/tectonic)
|
||||
* [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)
|
||||
* [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)
|
||||
|
||||
## すぐに利用できるオンプレミスを使ったソリューション
|
||||
これらのソリューションは、内部の安全なクラウドネットワーク上にKubernetesクラスターをほんのわずかのコマンドで作成することを可能にします。
|
||||
|
||||
* [Agile Stacks](https://www.agilestacks.com/products/kubernetes)
|
||||
* [APPUiO](https://appuio.ch)
|
||||
* [Docker Enterprise](https://www.docker.com/products/docker-enterprise)
|
||||
* [Giant Swarm](https://giantswarm.io)
|
||||
* [GKE On-Prem | Google Cloud](https://cloud.google.com/gke-on-prem/)
|
||||
* [IBM Cloud Private](https://www.ibm.com/cloud-computing/products/ibm-cloud-private/)
|
||||
* [Kontena Pharos](https://kontena.io/pharos/)
|
||||
* [Kubermatic](https://www.loodse.com)
|
||||
* [Kublr](www.kublr.com/kubernetes.io/setup-hosted-solution)
|
||||
* [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/)
|
||||
* [Nirmata](https://nirmata.com/)
|
||||
* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) by [Red Hat](https://www.redhat.com)
|
||||
* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service)
|
||||
* [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/)
|
||||
* [SUSE CaaS Platform](https://www.suse.com/products/caas-platform)
|
||||
* [SUSE Cloud Application Platform](https://www.suse.com/products/cloud-application-platform/)
|
||||
* [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)
|
||||
|
||||
## カスタムソリューション
|
||||
|
||||
Kubernetesは、幅広いクラウドプロバイダーやベアメタル環境、
|
||||
そして多くの基本オペレーティングシステム上で実行できます。
|
||||
|
||||
もし以下のガイドからニーズに合ったものを見つけることができたなら、それを使ってください。
|
||||
少し古くなっているかもしれませんが最初から始めるよりも簡単です。特別な要件があるため、
|
||||
またはKubernetesクラスターの下にあるものを理解したいために最初から始める必要がある場合は、
|
||||
[ゼロからのカスタムクラスターの作成](/ja/docs/setup/scratch/)を試してください。
|
||||
|
||||
### 全般
|
||||
|
||||
ホスティングリソースを設定する方法がすでにある場合は、
|
||||
[kubeadm](/docs/setup/independent/create-cluster-kubeadm/)を使用して
|
||||
マシン毎に単一のコマンドでクラスターを起動します。
|
||||
|
||||
### クラウド
|
||||
|
||||
これらのソリューションは、上記のソリューションでカバーされていないクラウドプロバイダーとオペレーティングシステムの組み合わせです。
|
||||
|
||||
* [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/)
|
||||
* [CoreOS on AWS or GCE](/docs/setup/custom-cloud/coreos/)
|
||||
* [Gardener](https://gardener.cloud/)
|
||||
* [Kublr](www.kublr.com/kubernetes.io/setup-hosted-solution)
|
||||
* [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/)
|
||||
* [Kubespray](/docs/setup/custom-cloud/kubespray/)
|
||||
* [Rancher Kubernetes Engine (RKE)](https://github.com/rancher/rke)
|
||||
* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS)
|
||||
|
||||
### オンプレミスの仮想マシン
|
||||
|
||||
* [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/)
|
||||
* [CloudStack](/docs/setup/on-premises-vm/cloudstack/) (Ansible、CoreOSとflannelを使用します)
|
||||
* [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) (Fedoraとflannelを使用します)
|
||||
* [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization/)
|
||||
* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com)
|
||||
* [oVirt](/docs/setup/on-premises-vm/ovirt/)
|
||||
* [Vagrant](/docs/setup/custom-cloud/coreos/) (CoreOSとflannelを使用します)
|
||||
* [VMware](/docs/setup/custom-cloud/coreos/) (CoreOSとflannelを使用します)
|
||||
* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS)
|
||||
* [VMware vSphere](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)
|
||||
* [VMware vSphere, OpenStack, or Bare Metal](/docs/getting-started-guides/ubuntu/) (Juju、Ubuntuとflannelを使用します)
|
||||
|
||||
### ベアメタル
|
||||
|
||||
* [CoreOS](/docs/setup/custom-cloud/coreos/)
|
||||
* [Digital Rebar](/docs/setup/on-premises-metal/krib/)
|
||||
* [Docker Enterprise](https://www.docker.com/products/docker-enterprise)
|
||||
* [Fedora (Single Node)](/docs/getting-started-guides/fedora/fedora_manual_config/)
|
||||
* [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)
|
||||
* [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/)
|
||||
* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com)
|
||||
* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS)
|
||||
|
||||
### 統合
|
||||
|
||||
これらのソリューションは、サードパーティー製のスケジューラー、リソースマネージャー、および/または低レベルのプラットフォームとの統合を提供します。
|
||||
|
||||
* [DCOS](/docs/setup/on-premises-vm/dcos/)
|
||||
* Community Edition DCOSは、AWSを使用します
|
||||
* Enterprise Edition DCOSは、クラウドホスティング、オンプレミスのVM、およびベアメタルをサポートします
|
||||
|
||||
## ソリューションの表
|
||||
|
||||
以下は上記のソリューションすべての表です。
|
||||
|
||||
IaaS プロバイダー | 構成管理 | OS | ネットワーク| ドキュメント | サポートレベル
|
||||
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ----------------------------
|
||||
any | any | multi-support | any CNI | [docs](/docs/setup/independent/create-cluster-kubeadm/) | Project ([SIG-cluster-lifecycle](https://git.k8s.io/community/sig-cluster-lifecycle))
|
||||
Google Kubernetes Engine | | | GCE | [docs](https://cloud.google.com/kubernetes-engine/docs/) | Commercial
|
||||
Docker Enterprise | custom | [multi-support](https://success.docker.com/article/compatibility-matrix) | [multi-support](https://docs.docker.com/ee/ucp/kubernetes/install-cni-plugin/) | [docs](https://docs.docker.com/ee/) | Commercial
|
||||
IBM Cloud Private | Ansible | multi-support | multi-support | [docs](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html) | [Commercial](https://www.ibm.com/mysupport/s/topic/0TO500000001o0fGAA/ibm-cloud-private?language=en_US&productId=01t50000004X1PWAA0) and [Community](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/troubleshoot/support_types.html) |
|
||||
Red Hat OpenShift | Ansible & CoreOS | RHEL & CoreOS | [multi-support](https://docs.openshift.com/container-platform/3.11/architecture/networking/network_plugins.html) | [docs](https://docs.openshift.com/container-platform/3.11/welcome/index.html) | Commercial
|
||||
Stackpoint.io | | multi-support | multi-support | [docs](https://stackpoint.io/) | Commercial
|
||||
AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial
|
||||
Madcore.Ai | Jenkins DSL | Ubuntu | flannel | [docs](https://madcore.ai) | Community ([@madcore-ai](https://github.com/madcore-ai))
|
||||
Platform9 | | multi-support | multi-support | [docs](https://platform9.com/managed-kubernetes/) | Commercial
|
||||
Kublr | custom | multi-support | multi-support | [docs](http://docs.kublr.com/) | Commercial
|
||||
Kubermatic | | multi-support | multi-support | [docs](http://docs.kubermatic.io/) | Commercial
|
||||
IBM Cloud Kubernetes Service | | Ubuntu | IBM Cloud Networking + Calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial
|
||||
Giant Swarm | | CoreOS | flannel and/or Calico | [docs](https://docs.giantswarm.io/) | Commercial
|
||||
GCE | Saltstack | Debian | GCE | [docs](/docs/setup/turnkey/gce/) | Project
|
||||
Azure Kubernetes Service | | Ubuntu | Azure | [docs](https://docs.microsoft.com/en-us/azure/aks/) | Commercial
|
||||
Azure (IaaS) | | Ubuntu | Azure | [docs](/docs/setup/turnkey/azure/) | [Community (Microsoft)](https://github.com/Azure/acs-engine)
|
||||
Bare-metal | custom | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config/) | Project
|
||||
Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
DCOS | Marathon | CoreOS/Alpine | custom | [docs](/docs/getting-started-guides/dcos/) | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md))
|
||||
AWS | CoreOS | CoreOS | flannel | [docs](/docs/setup/turnkey/aws/) | Community
|
||||
GCE | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires))
|
||||
Vagrant | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles))
|
||||
CloudStack | Ansible | CoreOS | flannel | [docs](/docs/getting-started-guides/cloudstack/) | Community ([@sebgoa](https://github.com/sebgoa))
|
||||
VMware vSphere | any | multi-support | multi-support | [docs](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/) | [Community](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/contactus.html)
|
||||
Bare-metal | custom | CentOS | flannel | [docs](/docs/getting-started-guides/centos/centos_manual_config/) | Community ([@coolsvap](https://github.com/coolsvap))
|
||||
lxd | Juju | Ubuntu | flannel/canal | [docs](/docs/getting-started-guides/ubuntu/local/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
AWS | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
Azure | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
GCE | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
Oracle Cloud | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
Rackspace | custom | CoreOS | flannel/calico/canal | [docs](https://developer.rackspace.com/docs/rkaas/latest/) | [Commercial](https://www.rackspace.com/managed-kubernetes)
|
||||
VMware vSphere | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
Bare Metal | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
AWS | Saltstack | Debian | AWS | [docs](/docs/setup/turnkey/aws/) | Community ([@justinsb](https://github.com/justinsb))
|
||||
AWS | kops | Debian | AWS | [docs](https://github.com/kubernetes/kops/) | Community ([@justinsb](https://github.com/justinsb))
|
||||
Bare-metal | custom | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu/) | Community ([@resouer](https://github.com/resouer), [@WIZARD-CXY](https://github.com/WIZARD-CXY))
|
||||
oVirt | | | | [docs](/docs/setup/on-premises-vm/ovirt/) | Community ([@simon3z](https://github.com/simon3z))
|
||||
any | any | any | any | [docs](/docs/setup/release/building-from-source/) | Community ([@erictune](https://github.com/erictune))
|
||||
any | any | any | any | [docs](http://docs.projectcalico.org/v2.2/getting-started/kubernetes/installation/) | Commercial and Community
|
||||
any | RKE | multi-support | flannel or canal | [docs](https://rancher.com/docs/rancher/v2.x/en/quick-start-guide/) | [Commercial](https://rancher.com/what-is-rancher/overview/) and [Community](https://github.com/rancher/rancher)
|
||||
any | [Gardener Cluster-Operator](https://kubernetes.io/blog/2018/05/17/gardener/) | multi-support | multi-support | [docs](https://gardener.cloud) | [Project/Community](https://github.com/gardener) and [Commercial]( https://cloudplatform.sap.com/)
|
||||
Alibaba Cloud Container Service For Kubernetes | ROS | CentOS | flannel/Terway | [docs](https://www.aliyun.com/product/containerservice) | Commercial
|
||||
Agile Stacks | Terraform | CoreOS | multi-support | [docs](https://www.agilestacks.com/products/kubernetes) | Commercial
|
||||
IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial
|
||||
Digital Rebar | kubeadm | any | metal | [docs](/docs/setup/on-premises-metal/krib/) | Community ([@digitalrebar](https://github.com/digitalrebar))
|
||||
VMware Cloud PKS | | Photon OS | Canal | [docs](https://docs.vmware.com/en/VMware-Kubernetes-Engine/index.html) | Commercial
|
||||
VMware Enterprise PKS | BOSH | Ubuntu | VMware NSX-T/flannel | [docs](https://docs.vmware.com/en/VMware-Enterprise-PKS/) | Commercial
|
||||
Mirantis Cloud Platform | Salt | Ubuntu | multi-support | [docs](https://docs.mirantis.com/mcp/) | Commercial
|
||||
|
||||
{{< note >}}
|
||||
上記の表はバージョンテスト/ノード内での使用順に並べられ、その後にサポートレベルが続きます。
|
||||
{{< /note >}}
|
||||
|
||||
### カラムの定義
|
||||
|
||||
* **IaaSプロバイダー**は、Kubernetesが動作する仮想マシンまたは物理マシン（ノード）を提供する製品または組織です。
|
||||
* **OS**は、ノードのベースのオペレーティングシステムです。
|
||||
* **構成管理**は、ノードにKubernetesをインストール・保守するのに役立つ構成管理システムです。
|
||||
* **ネットワーク**は、[ネットワークモデル](/docs/concepts/cluster-administration/networking/)を実装したものです。ネットワークタイプが、
|
||||
_none_ のものは、複数のノードをサポートしていない場合や、単一の物理ノードで複数のVMノードをサポートしている場合があります。
|
||||
* **適合**は、この設定で作成されたクラスターが、Kubernetes v1.0.0のAPIおよび基本機能をサポートするためのプロジェクトの適合性テストに合格したかどうかを示します。
|
||||
* **サポートレベル**
|
||||
* **プロジェクト**: Kubernetesのコミッターは通常この設定を使用しているため、ほとんどの場合Kubernetesの最新リリースで動作します。
|
||||
* **商用**: 独自のサポート契約がある商用製品。
|
||||
* **コミュニティー**: コミュニティーの貢献によって積極的にサポートされています。 Kubernetesの最近のリリースでは動作しない可能性があります。
|
||||
* **非アクティブ**: 積極的にメンテナンスされていません。初めてのKubernetesユーザーにはお勧めできません。削除される可能性があります。
|
||||
* **注意事項**には、使用されているKubernetesのバージョンなど、その他の関連情報があります。
|
||||
|
||||
<!-- reference style links below here -->
|
||||
<!-- GCE conformance test result -->
|
||||
[1]: https://gist.github.com/erictune/4cabc010906afbcc5061
|
||||
<!-- Vagrant conformance test result -->
|
||||
[2]: https://gist.github.com/derekwaynecarr/505e56036cdf010bf6b6
|
||||
<!-- Google Kubernetes Engine conformance test result -->
|
||||
[3]: https://gist.github.com/erictune/2f39b22f72565365e59b
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: Production environment
|
||||
weight: 30
|
||||
---
|
||||
+1
-1
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: CRIのインストール
|
||||
content_template: templates/concept
|
||||
weight: 100
|
||||
weight: 10
|
||||
---
|
||||
{{% capture overview %}}
|
||||
{{< feature-state for_k8s_version="v1.6" state="stable" >}}
|
||||
+2
-4
@@ -26,7 +26,7 @@ sudo apt-add-repository ppa:ansible/ansible
|
||||
sudo apt-get update
|
||||
sudo apt-get install ansible
|
||||
```
|
||||
|
||||
|
||||
On CloudStack server you also have to install libselinux-python :
|
||||
|
||||
```shell
|
||||
@@ -113,8 +113,6 @@ e9af8293... <node #2 IP> role=node
|
||||
|
||||
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
|
||||
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
|
||||
CloudStack | Ansible | CoreOS | flannel | [docs](/docs/setup/on-premises-vm/cloudstack/) | | Community ([@Guiques](https://github.com/ltupin/))
|
||||
|
||||
For support level information on all solutions, see the [Table of solutions](/docs/setup/pick-right-solution/#table-of-solutions) chart.
|
||||
CloudStack | Ansible | CoreOS | flannel | [docs](/docs/setup/production-environment/on-premises-vm/cloudstack/) | | Community ([@Guiques](https://github.com/ltupin/))
|
||||
|
||||
{{% /capture %}}
|
||||
+1
-3
@@ -63,8 +63,6 @@ This short screencast demonstrates how the oVirt Cloud Provider can be used to d
|
||||
|
||||
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
|
||||
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
|
||||
oVirt | | | | [docs](/docs/setup/on-premises-vm/ovirt/) | | Community ([@simon3z](https://github.com/simon3z))
|
||||
|
||||
For support level information on all solutions, see the [Table of solutions](/docs/setup/pick-right-solution/#table-of-solutions) chart.
|
||||
oVirt | | | | [docs](/docs/setup/production-environment/on-premises-vm/ovirt/) | | Community ([@simon3z](https://github.com/simon3z))
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: Installing Kubernetes with deployment tools
|
||||
weight: 30
|
||||
---
|
||||
+1
@@ -1,6 +1,7 @@
|
||||
---
|
||||
title: kopsを使ったAWS上でのKubernetesのインストール
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
+11
-5
@@ -2,13 +2,14 @@
|
||||
title: KRIBを使用してDigital Rebar Provision (DRP)と共にKubernetesをインストールする
|
||||
krib-version: 2.4
|
||||
author: Rob Hirschfeld (zehicle)
|
||||
weight: 20
|
||||
---
|
||||
|
||||
## 概要
|
||||
|
||||
This guide helps to install a Kubernetes cluster hosted on bare metal with [Digital Rebar Provision](https://github.com/digitalrebar/provision) using only its Content packages and *kubeadm*.
|
||||
This guide helps to install a Kubernetes cluster hosted on bare metal with [Digital Rebar Provision](https://github.com/digitalrebar/provision) using only its Content packages and *kubeadm*.
|
||||
|
||||
Digital Rebar Provision (DRP) is an integrated Golang DHCP, bare metal provisioning (PXE/iPXE) and workflow automation platform. While [DRP can be used to invoke](https://provision.readthedocs.io/en/tip/doc/integrations/ansible.html) [kubespray](/docs/setup/custom-cloud/kubespray), it also offers a self-contained Kubernetes installation known as [KRIB (Kubernetes Rebar Integrated Bootstrap)](https://github.com/digitalrebar/provision-content/tree/master/krib).
|
||||
Digital Rebar Provision (DRP) is an integrated Golang DHCP, bare metal provisioning (PXE/iPXE) and workflow automation platform. While [DRP can be used to invoke](https://provision.readthedocs.io/en/tip/doc/integrations/ansible.html) [kubespray](/ja/docs/setup/custom-cloud/kubespray), it also offers a self-contained Kubernetes installation known as [KRIB (Kubernetes Rebar Integrated Bootstrap)](https://github.com/digitalrebar/provision-content/tree/master/krib).
|
||||
|
||||
{{< note >}}
|
||||
KRIB is not a _stand-alone_ installer: Digital Rebar templates drive a standard *[kubeadm](/docs/admin/kubeadm/)* configuration that manages the Kubernetes installation with the [Digital Rebar cluster pattern](https://provision.readthedocs.io/en/tip/doc/arch/cluster.html#rs-cluster-pattern) to elect leaders _without external supervision_.
|
||||
@@ -24,7 +25,7 @@ KRIB features:
|
||||
* dynamic generation of a TLS infrastructure
|
||||
* composable attributes and automatic detection of hardware by profile
|
||||
* options for persistent, immutable and image-based deployments
|
||||
* support for Ubuntu 18.04, CentOS/RHEL 7 and others
|
||||
* support for Ubuntu 18.04, CentOS/RHEL 7, CoreOS, RancherOS and others
|
||||
|
||||
## クラスターの作成
|
||||
|
||||
@@ -38,7 +39,12 @@ Following the [Digital Rebar installation](https://provision.readthedocs.io/en/t
|
||||
|
||||
### (2/5) KRIBと証明書プラグインのインストール
|
||||
|
||||
Upload the KRIB Content bundle (or build from [source](https://github.com/digitalrebar/provision-content/tree/master/krib)) and the Cert Plugin for your DRP platform (e.g.: [amd64 Linux v2.4.0](https://s3-us-west-2.amazonaws.com/rebar-catalog/certs/v2.4.0-0-02301d35f9f664d6c81d904c92a9c81d3fd41d2c/amd64/linux/certs)). Both are freely available via the [RackN UX](https://portal.rackn.io).
|
||||
Upload the KRIB Content bundle (or build from [source](https://github.com/digitalrebar/provision-content/tree/master/krib)) and the Cert Plugin for your DRP platform. Both are freely available via the [RackN UX](https://portal.rackn.io) or using the upload from catalog feature of the DRPCLI (shown below).
|
||||
|
||||
```
|
||||
drpcli plugin_providers upload certs from catalog:certs-stable
|
||||
drpcli contents upload catalog:krib-stable
|
||||
```
|
||||
|
||||
### (3/5) クラスター構築の開始
|
||||
|
||||
@@ -60,7 +66,7 @@ During the installation, KRIB writes cluster configuration data back into the cl
|
||||
|
||||
### (5/5) クラスターへのアクセス
|
||||
|
||||
The cluster is available for access via *kubectl* once the `krib/cluster-admin-conf` Param has been set. This Param contains the `kubeconfig` information necessary to access the cluster.
|
||||
The cluster is available for access via *kubectl* once the `krib/cluster-admin-conf` Param has been set. This Param contains the `kubeconfig` information necessary to access the cluster.
|
||||
|
||||
For example, if you named the cluster Profile `krib` then the following commands would allow you to connect to the installed cluster from your local terminal.
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Bootstrapping clusters with kubeadm"
|
||||
weight: 10
|
||||
---
|
||||
+5
-11
@@ -32,15 +32,13 @@ kubeadmの`ClusterConfiguration`オブジェクトはAPIServer、ControllerManag
|
||||
|
||||
Example usage:
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta1
|
||||
apiVersion: kubeadm.k8s.io/v1beta2
|
||||
kind: ClusterConfiguration
|
||||
kubernetesVersion: v1.13.0
|
||||
metadata:
|
||||
name: 1.13-sample
|
||||
apiServer:
|
||||
extraArgs:
|
||||
advertise-address: 192.168.0.103
|
||||
anonymous-auth: false
|
||||
anonymous-auth: "false"
|
||||
enable-admission-plugins: AlwaysPullImages,DefaultStorageClass
|
||||
audit-log-path: /home/johndoe/audit.log
|
||||
```
|
||||
@@ -51,16 +49,14 @@ apiServer:
|
||||
|
||||
Example usage:
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta1
|
||||
apiVersion: kubeadm.k8s.io/v1beta2
|
||||
kind: ClusterConfiguration
|
||||
kubernetesVersion: v1.13.0
|
||||
metadata:
|
||||
name: 1.13-sample
|
||||
controllerManager:
|
||||
extraArgs:
|
||||
cluster-signing-key-file: /home/johndoe/keys/ca.key
|
||||
bind-address: 0.0.0.0
|
||||
deployment-controller-sync-period: 50
|
||||
deployment-controller-sync-period: "50"
|
||||
```
|
||||
|
||||
## Schedulerフラグ
|
||||
@@ -69,11 +65,9 @@ controllerManager:
|
||||
|
||||
Example usage:
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1beta1
|
||||
apiVersion: kubeadm.k8s.io/v1beta2
|
||||
kind: ClusterConfiguration
|
||||
kubernetesVersion: v1.13.0
|
||||
metadata:
|
||||
name: 1.13-sample
|
||||
scheduler:
|
||||
extraArgs:
|
||||
address: 0.0.0.0
|
||||
+104
-85
@@ -6,11 +6,11 @@ weight: 30
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<img src="https://raw.githubusercontent.com/cncf/artwork/master/projects/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">**kubeadm** helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. With kubeadm, your cluster should pass [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). Kubeadm also supports other cluster
|
||||
lifecycle functions, such as upgrades, downgrade, and managing [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/).
|
||||
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">**kubeadm** helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. With kubeadm, your cluster should pass [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). Kubeadm also supports other cluster
|
||||
lifecycle functions, such as upgrades, downgrade, and managing [bootstrap tokens](/ja/docs/reference/access-authn-authz/bootstrap-tokens/).
|
||||
|
||||
Because you can install kubeadm on various types of machine (e.g. laptop, server,
|
||||
Raspberry Pi, etc.), it's well suited for integration with provisioning systems
|
||||
Because you can install kubeadm on various types of machine (e.g. laptop, server,
|
||||
Raspberry Pi, etc.), it's well suited for integration with provisioning systems
|
||||
such as Terraform or Ansible.
|
||||
|
||||
kubeadm's simplicity means it can serve a wide range of use cases:
|
||||
@@ -37,12 +37,11 @@ but you may also build them from source for other OSes.
|
||||
|---------------------------|--------------- |
|
||||
| Command line UX | GA |
|
||||
| Implementation | GA |
|
||||
| Config file API | beta |
|
||||
| Config file API | Beta |
|
||||
| CoreDNS | GA |
|
||||
| kubeadm alpha subcommands | alpha |
|
||||
| High availability | alpha |
|
||||
| DynamicKubeletConfig | alpha |
|
||||
| Self-hosting | alpha |
|
||||
| kubeadm alpha subcommands | Alpha |
|
||||
| High availability | Beta |
|
||||
| DynamicKubeletConfig | Alpha |
|
||||
|
||||
|
||||
kubeadm's overall feature state is **GA**. Some sub-features, like the configuration
|
||||
@@ -68,6 +67,8 @@ timeframe; which also applies to `kubeadm`.
|
||||
| v1.11.x | June 2018 | March 2019 |
|
||||
| v1.12.x | September 2018 | June 2019 |
|
||||
| v1.13.x | December 2018 | September 2019 |
|
||||
| v1.14.x | March 2019 | December 2019 |
|
||||
| v1.15.x | June 2019 | March 2020 |
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -76,17 +77,17 @@ timeframe; which also applies to `kubeadm`.
|
||||
- One or more machines running a deb/rpm-compatible OS, for example Ubuntu or CentOS
|
||||
- 2 GB or more of RAM per machine. Any less leaves little room for your
|
||||
apps.
|
||||
- 2 CPUs or more on the master
|
||||
- 2 CPUs or more on the control-plane node
|
||||
- Full network connectivity among all machines in the cluster. A public or
|
||||
private network is fine.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 目的
|
||||
|
||||
* Install a single master Kubernetes cluster or [high availability cluster](/docs/setup/independent/high-availability/)
|
||||
* Install a single master Kubernetes cluster or [high availability cluster](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)
|
||||
* Install a Pod network on the cluster so that your Pods can
|
||||
talk to each other
|
||||
|
||||
@@ -94,48 +95,52 @@ timeframe; which also applies to `kubeadm`.
|
||||
|
||||
### kubeadmのインストール
|
||||
|
||||
See ["Installing kubeadm"](/docs/setup/independent/install-kubeadm/).
|
||||
See ["Installing kubeadm"](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
|
||||
|
||||
{{< note >}}
|
||||
If you have already installed kubeadm, run `apt-get update &&
|
||||
apt-get upgrade` or `yum update` to get the latest version of kubeadm.
|
||||
|
||||
When you upgrade, the kubelet restarts every few seconds as it waits in a crashloop for
|
||||
kubeadm to tell it what to do. This crashloop is expected and normal.
|
||||
kubeadm to tell it what to do. This crashloop is expected and normal.
|
||||
After you initialize your master, the kubelet runs normally.
|
||||
{{< /note >}}
|
||||
|
||||
### マスターの初期化
|
||||
|
||||
The master is the machine where the control plane components run, including
|
||||
The control-plane node is the machine where the control plane components run, including
|
||||
etcd (the cluster database) and the API server (which the kubectl CLI
|
||||
communicates with).
|
||||
|
||||
1. Choose a pod network add-on, and verify whether it requires any arguments to
|
||||
1. Choose a pod network add-on, and verify whether it requires any arguments to
|
||||
be passed to kubeadm initialization. Depending on which
|
||||
third-party provider you choose, you might need to set the `--pod-network-cidr` to
|
||||
a provider-specific value. See [Installing a pod network add-on](#pod-network).
|
||||
1. (Optional) Unless otherwise specified, kubeadm uses the network interface associated
|
||||
with the default gateway to advertise the master's IP. To use a different
|
||||
network interface, specify the `--apiserver-advertise-address=<ip-address>` argument
|
||||
to `kubeadm init`. To deploy an IPv6 Kubernetes cluster using IPv6 addressing, you
|
||||
1. (Optional) Since version 1.14, kubeadm will try to detect the container runtime on Linux
|
||||
by using a list of well known domain socket paths. To use different container runtime or
|
||||
if there are more than one installed on the provisioned node, specify the `--cri-socket`
|
||||
argument to `kubeadm init`. See [Installing runtime](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
|
||||
1. (Optional) Unless otherwise specified, kubeadm uses the network interface associated
|
||||
with the default gateway to advertise the master's IP. To use a different
|
||||
network interface, specify the `--apiserver-advertise-address=<ip-address>` argument
|
||||
to `kubeadm init`. To deploy an IPv6 Kubernetes cluster using IPv6 addressing, you
|
||||
must specify an IPv6 address, for example `--apiserver-advertise-address=fd00::101`
|
||||
1. (Optional) Run `kubeadm config images pull` prior to `kubeadm init` to verify
|
||||
connectivity to gcr.io registries.
|
||||
1. (Optional) Run `kubeadm config images pull` prior to `kubeadm init` to verify
|
||||
connectivity to gcr.io registries.
|
||||
|
||||
Now run:
|
||||
|
||||
```bash
|
||||
kubeadm init <args>
|
||||
kubeadm init <args>
|
||||
```
|
||||
|
||||
### 詳細
|
||||
|
||||
For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm/).
|
||||
For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/ja/docs/reference/setup-tools/kubeadm/kubeadm/).
|
||||
|
||||
For a complete list of configuration options, see the [configuration file documentation](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).
|
||||
For a complete list of configuration options, see the [configuration file documentation](/ja/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).
|
||||
|
||||
To customize control plane components, including optional IPv6 assignment to liveness probe for control plane components and etcd server, provide extra arguments to each component as documented in [custom arguments](/docs/admin/kubeadm#custom-args).
|
||||
To customize control plane components, including optional IPv6 assignment to liveness probe for control plane components and etcd server, provide extra arguments to each component as documented in [custom arguments](/ja/docs/admin/kubeadm#custom-args).
|
||||
|
||||
To run `kubeadm init` again, you must first [tear down the cluster](#tear-down).
|
||||
|
||||
@@ -145,7 +150,7 @@ components do not currently support multi-architecture.
|
||||
|
||||
`kubeadm init` first runs a series of prechecks to ensure that the machine
|
||||
is ready to run Kubernetes. These prechecks expose warnings and exit on errors. `kubeadm init`
|
||||
then downloads and installs the cluster control plane components. This may take several minutes.
|
||||
then downloads and installs the cluster control plane components. This may take several minutes.
|
||||
The output should look like:
|
||||
|
||||
```none
|
||||
@@ -207,8 +212,8 @@ To start using your cluster, you need to run the following as a regular user:
|
||||
sudo chown $(id -u):$(id -g) $HOME/.kube/config
|
||||
|
||||
You should now deploy a pod network to the cluster.
|
||||
Run "kubectl apply -f [podnetwork].yaml" with one of the addon options listed at:
|
||||
/docs/admin/addons/
|
||||
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
|
||||
/docs/concepts/cluster-administration/addons/
|
||||
|
||||
You can now join any number of machines by running the following on each node
|
||||
as root:
|
||||
@@ -234,11 +239,11 @@ export KUBECONFIG=/etc/kubernetes/admin.conf
|
||||
Make a record of the `kubeadm join` command that `kubeadm init` outputs. You
|
||||
need this command to [join nodes to your cluster](#join-nodes).
|
||||
|
||||
The token is used for mutual authentication between the master and the joining
|
||||
nodes. The token included here is secret. Keep it safe, because anyone with this
|
||||
The token is used for mutual authentication between the control-plane node and the joining
|
||||
nodes. The token included here is secret. Keep it safe, because anyone with this
|
||||
token can add authenticated nodes to your cluster. These tokens can be listed,
|
||||
created, and deleted with the `kubeadm token` command. See the
|
||||
[kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm-token/).
|
||||
[kubeadm reference guide](/ja/docs/reference/setup-tools/kubeadm/kubeadm-token/).
|
||||
|
||||
### Podネットワークアドオンのインストール {#pod-network}
|
||||
|
||||
@@ -253,11 +258,11 @@ each other.
|
||||
kubeadm only supports Container Network Interface (CNI) based networks (and does not support kubenet).**
|
||||
|
||||
Several projects provide Kubernetes pod networks using CNI, some of which also
|
||||
support [Network Policy](/docs/concepts/services-networking/networkpolicies/). See the [add-ons page](/docs/concepts/cluster-administration/addons/) for a complete list of available network add-ons.
|
||||
- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
|
||||
support [Network Policy](/ja/docs/concepts/services-networking/networkpolicies/). See the [add-ons page](/ja/docs/concepts/cluster-administration/addons/) for a complete list of available network add-ons.
|
||||
- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
|
||||
- [CNI bridge](https://github.com/containernetworking/plugins/blob/master/plugins/main/bridge/README.md) and [local-ipam](https://github.com/containernetworking/plugins/blob/master/plugins/ipam/host-local/README.md) are the only supported IPv6 network plugins in Kubernetes version 1.9.
|
||||
|
||||
Note that kubeadm sets up a more secure cluster by default and enforces use of [RBAC](/docs/reference/access-authn-authz/rbac/).
|
||||
Note that kubeadm sets up a more secure cluster by default and enforces use of [RBAC](/ja/docs/reference/access-authn-authz/rbac/).
|
||||
Make sure that your network manifest supports RBAC.
|
||||
|
||||
Also, beware, that your Pod network must not overlap with any of the host networks as this can cause issues.
|
||||
@@ -276,6 +281,12 @@ You can install only one pod network per cluster.
|
||||
Please select one of the tabs to see installation instructions for the respective third-party Pod Network Provider.
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="AWS VPC" %}}
|
||||
AWS VPC CNI provides native AWS VPC networking to Kubernetes clusters.
|
||||
|
||||
For installation, please refer to the [AWS VPC CNI setup guide](https://github.com/aws/amazon-vpc-cni-k8s#setup).
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Calico" %}}
|
||||
For more information about using Calico, see [Quickstart for Calico on Kubernetes](https://docs.projectcalico.org/latest/getting-started/kubernetes/), [Installing Calico for policy and networking](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/calico), and other related resources.
|
||||
|
||||
@@ -300,6 +311,8 @@ kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml
|
||||
{{% tab name="Cilium" %}}
|
||||
For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/).
|
||||
|
||||
For Cilium to work correctly, you must pass `--pod-network-cidr=10.217.0.0/16` to `kubeadm init`.
|
||||
|
||||
These commands will deploy Cilium with its own etcd managed by etcd operator.
|
||||
|
||||
_Note_: If you are running kubeadm in a single node please untaint it so that
|
||||
@@ -312,41 +325,68 @@ kubectl taint nodes <node-name> node-role.kubernetes.io/master:NoSchedule-
|
||||
To deploy Cilium you just need to run:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.4/examples/kubernetes/1.13/cilium.yaml
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium.yaml
|
||||
```
|
||||
|
||||
Once all Cilium pods are marked as `READY`, you start using your cluster.
|
||||
|
||||
```shell
|
||||
$ kubectl get pods -n kube-system --selector=k8s-app=cilium
|
||||
kubectl get pods -n kube-system --selector=k8s-app=cilium
|
||||
```
|
||||
The output is similar to this:
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cilium-drxkl 1/1 Running 0 18m
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Contiv-VPP" %}}
|
||||
[Contiv-VPP](https://contivpp.io/) employs a programmable CNF vSwitch based on [FD.io VPP](https://fd.io/),
|
||||
offering feature-rich & high-performance cloud-native networking and services.
|
||||
|
||||
It implements k8s services and network policies in the user space (on VPP).
|
||||
|
||||
Please refer to this installation guide: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md)
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Flannel" %}}
|
||||
|
||||
For `flannel` to work correctly, you must pass `--pod-network-cidr=10.244.0.0/16` to `kubeadm init`.
|
||||
|
||||
Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
|
||||
to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
|
||||
please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
please see [here](/ja/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
|
||||
Make sure that your firewall rules allow UDP ports 8285 and 8472 traffic for all hosts participating in the overlay network.
|
||||
see [here
|
||||
](https://coreos.com/flannel/docs/latest/troubleshooting.html#firewalls).
|
||||
|
||||
Note that `flannel` works on `amd64`, `arm`, `arm64`, `ppc64le` and `s390x` under Linux.
|
||||
Windows (`amd64`) is claimed as supported in v0.11.0 but the usage is undocumented.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml
|
||||
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/62e44c867a2846fefb68bd5f178daf4da3095ccb/Documentation/kube-flannel.yml
|
||||
```
|
||||
|
||||
For more information about `flannel`, see [the CoreOS flannel repository on GitHub
|
||||
](https://github.com/coreos/flannel).
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="JuniperContrail/TungstenFabric" %}}
|
||||
Provides overlay SDN solution, delivering multicloud networking, hybrid cloud networking,
|
||||
simultaneous overlay-underlay support, network policy enforcement, network isolation,
|
||||
service chaining and flexible load balancing.
|
||||
|
||||
There are multiple, flexible ways to install JuniperContrail/TungstenFabric CNI.
|
||||
|
||||
Kindly refer to this quickstart: [TungstenFabric](https://tungstenfabric.github.io/website/)
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Kube-router" %}}
|
||||
Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
|
||||
to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
|
||||
please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
please see [here](/ja/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
|
||||
Kube-router relies on kube-controller-manager to allocate pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag.
|
||||
|
||||
@@ -358,7 +398,7 @@ For information on setting up Kubernetes cluster with Kube-router using kubeadm,
|
||||
{{% tab name="Romana" %}}
|
||||
Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
|
||||
to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
|
||||
please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
please see [here](/ja/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
|
||||
The official Romana set-up guide is [here](https://github.com/romana/romana/tree/master/containerize#using-kubeadm).
|
||||
|
||||
@@ -372,7 +412,7 @@ kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containe
|
||||
{{% tab name="Weave Net" %}}
|
||||
Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
|
||||
to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
|
||||
please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
please see [here](/ja/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
|
||||
The official Weave Net set-up guide is [here](https://www.weave.works/docs/net/latest/kube-addon/).
|
||||
|
||||
@@ -385,25 +425,6 @@ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl versio
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="JuniperContrail/TungstenFabric" %}}
|
||||
Provides overlay SDN solution, delivering multicloud networking, hybrid cloud networking,
|
||||
simultaneous overlay-underlay support, network policy enforcement, network isolation,
|
||||
service chaining and flexible load balancing.
|
||||
|
||||
There are multiple, flexible ways to install JuniperContrail/TungstenFabric CNI.
|
||||
|
||||
Kindly refer to this quickstart: [TungstenFabric](https://tungstenfabric.github.io/website/)
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Contiv-VPP" %}}
|
||||
[Contiv-VPP](https://contivpp.io/) employs a programmable CNF vSwitch based on [FD.io VPP](https://fd.io/),
|
||||
offering feature-rich & high-performance cloud-native networking and services.
|
||||
|
||||
It implements k8s services and network policies in the user space (on VPP).
|
||||
|
||||
Please refer to this installation guide: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md)
|
||||
{{% /tab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
@@ -411,13 +432,12 @@ Once a pod network has been installed, you can confirm that it is working by
|
||||
checking that the CoreDNS pod is Running in the output of `kubectl get pods --all-namespaces`.
|
||||
And once the CoreDNS pod is up and running, you can continue by joining your nodes.
|
||||
|
||||
If your network is not working or CoreDNS is not in the Running state, check
|
||||
out our [troubleshooting docs](/docs/setup/independent/troubleshooting-kubeadm/).
|
||||
If your network is not working or CoreDNS is not in the Running state, checkout our [troubleshooting docs](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
|
||||
|
||||
### コントロールプレーンノードの隔離
|
||||
|
||||
By default, your cluster will not schedule pods on the master for security
|
||||
reasons. If you want to be able to schedule pods on the master, e.g. for a
|
||||
By default, your cluster will not schedule pods on the control-plane node for security
|
||||
reasons. If you want to be able to schedule pods on the control-plane node, e.g. for a
|
||||
single-machine Kubernetes cluster for development, run:
|
||||
|
||||
```bash
|
||||
@@ -433,7 +453,7 @@ taint "node-role.kubernetes.io/master:" not found
|
||||
```
|
||||
|
||||
This will remove the `node-role.kubernetes.io/master` taint from any nodes that
|
||||
have it, including the master node, meaning that the scheduler will then be able
|
||||
have it, including the control-plane node, meaning that the scheduler will then be able
|
||||
to schedule pods everywhere.
|
||||
|
||||
### ノードの追加 {#join-nodes}
|
||||
@@ -552,7 +572,7 @@ You can now access the API Server locally at `http://localhost:8001/api/v1`
|
||||
## クラスターの削除 {#tear-down}
|
||||
|
||||
To undo what kubeadm did, you should first [drain the
|
||||
node](/docs/reference/generated/kubectl/kubectl-commands#drain) and make
|
||||
node](/ja/docs/reference/generated/kubectl/kubectl-commands#drain) and make
|
||||
sure that the node is empty before shutting it down.
|
||||
|
||||
Talking to the master with the appropriate credentials, run:
|
||||
@@ -584,23 +604,23 @@ If you wish to start over simply run `kubeadm init` or `kubeadm join` with the
|
||||
appropriate arguments.
|
||||
|
||||
More options and information about the
|
||||
[`kubeadm reset command`](/docs/reference/setup-tools/kubeadm/kubeadm-reset/).
|
||||
[`kubeadm reset command`](/ja/docs/reference/setup-tools/kubeadm/kubeadm-reset/).
|
||||
|
||||
## クラスターの維持 {#lifecycle}
|
||||
|
||||
Instructions for maintaining kubeadm clusters (e.g. upgrades,downgrades, etc.) can be found [here.](/docs/tasks/administer-cluster/kubeadm)
|
||||
Instructions for maintaining kubeadm clusters (e.g. upgrades,downgrades, etc.) can be found [here.](/ja/docs/tasks/administer-cluster/kubeadm)
|
||||
|
||||
## 他アドオンの参照 {#other-addons}
|
||||
|
||||
See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons,
|
||||
See the [list of add-ons](/ja/docs/concepts/cluster-administration/addons/) to explore other add-ons,
|
||||
including tools for logging, monitoring, network policy, visualization &
|
||||
control of your Kubernetes cluster.
|
||||
|
||||
## 次の手順 {#whats-next}
|
||||
|
||||
* Verify that your cluster is running properly with [Sonobuoy](https://github.com/heptio/sonobuoy)
|
||||
* Learn about kubeadm's advanced usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm)
|
||||
* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
|
||||
* Learn about kubeadm's advanced usage in the [kubeadm reference documentation](/ja/docs/reference/setup-tools/kubeadm/kubeadm)
|
||||
* Learn more about Kubernetes [concepts](/ja/docs/concepts/) and [`kubectl`](/ja/docs/user-guide/kubectl-overview/).
|
||||
* Configure log rotation. You can use **logrotate** for that. When using Docker, you can specify log rotation options for Docker daemon, for example `--log-driver=json-file --log-opt=max-size=10m --log-opt=max-file=5`. See [Configure and troubleshoot the Docker daemon](https://docs.docker.com/engine/admin/) for more details.
|
||||
|
||||
## フィードバック {#feedback}
|
||||
@@ -626,8 +646,8 @@ v1.8.
|
||||
|
||||
These resources provide more information on supported version skew between kubelets and the control plane, and other Kubernetes components:
|
||||
|
||||
* Kubernetes [version and version-skew policy](/docs/setup/version-skew-policy/)
|
||||
* Kubeadm-specific [installation guide](/docs/setup/independent/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
|
||||
* Kubernetes [version and version-skew policy](/ja/docs/setup/release/version-skew-policy/)
|
||||
* Kubeadm-specific [installation guide](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
|
||||
|
||||
## kubeadmは様々なプラットフォームで動く
|
||||
|
||||
@@ -643,19 +663,18 @@ supports your chosen platform.
|
||||
|
||||
## 制限事項 {#limitations}
|
||||
|
||||
Please note: kubeadm is a work in progress and these limitations will be
|
||||
addressed in due course.
|
||||
The cluster created here has a single control-plane node, with a single etcd database
|
||||
running on it. This means that if the control-plane node fails, your cluster may lose
|
||||
data and may need to be recreated from scratch.
|
||||
|
||||
1. The cluster created here has a single master, with a single etcd database
|
||||
running on it. This means that if the master fails, your cluster may lose
|
||||
data and may need to be recreated from scratch. Adding HA support
|
||||
(multiple etcd servers, multiple API servers, etc) to kubeadm is
|
||||
still a work-in-progress.
|
||||
Workarounds:
|
||||
|
||||
Workaround: regularly
|
||||
[back up etcd](https://coreos.com/etcd/docs/latest/admin_guide.html). The
|
||||
etcd data directory configured by kubeadm is at `/var/lib/etcd` on the master.
|
||||
* Regularly [back up etcd](https://coreos.com/etcd/docs/latest/admin_guide.html). The
|
||||
etcd data directory configured by kubeadm is at `/var/lib/etcd` on the control-plane node.
|
||||
|
||||
* Use multiple control-plane nodes by completing the
|
||||
[HA setup](/ja/docs/setup/independent/ha-topology) instead.
|
||||
|
||||
## トラブルシューティング {#troubleshooting}
|
||||
|
||||
If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/independent/troubleshooting-kubeadm/).
|
||||
If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
|
||||
+6
-6
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Options for Highly Available Topology
|
||||
title: Options for Highly Available topology
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
@@ -28,11 +28,11 @@ kubeadm that run control plane components.
|
||||
Each control plane node runs an instance of the `kube-apiserver`, `kube-scheduler`, and `kube-controller-manager`.
|
||||
The `kube-apiserver` is exposed to worker nodes using a load balancer.
|
||||
|
||||
Each control plane node creates a local etcd member and this etcd member communicate only with
|
||||
Each control plane node creates a local etcd member and this etcd member communicates only with
|
||||
the `kube-apiserver` of this node. The same applies to the local `kube-controller-manager`
|
||||
and `kube-scheduler` instances.
|
||||
|
||||
This topology couples the control planes and etcd members on the same nodes. It is simpler to set up than a cluster
|
||||
This topology couples the control planes and etcd members on the same nodes. It is simpler to set up than a cluster
|
||||
with external etcd nodes, and simpler to manage for replication.
|
||||
|
||||
However, a stacked cluster runs the risk of failed coupling. If one node goes down, both an etcd member and a control
|
||||
@@ -41,7 +41,7 @@ plane instance are lost, and redundancy is compromised. You can mitigate this ri
|
||||
You should therefore run a minimum of three stacked control plane nodes for an HA cluster.
|
||||
|
||||
This is the default topology in kubeadm. A local etcd member is created automatically
|
||||
on control plane nodes when using `kubeadm init` and `kubeadm join --experimental-control-plane`.
|
||||
on control plane nodes when using `kubeadm init` and `kubeadm join --control-plane`.
|
||||
|
||||
|
||||
|
||||
@@ -64,6 +64,6 @@ A minimum of three hosts for control plane nodes and three hosts for etcd nodes
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
- [Set up a highly available cluster with kubeadm](/docs/setup/independent/high-availability/)
|
||||
- [Set up a highly available cluster with kubeadm](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/)
|
||||
|
||||
{{% /capture %}}
|
||||
{{% /capture %}}
|
||||
+4
-4
@@ -11,7 +11,7 @@ weight: 60
|
||||
- 積み重なったコントロールプレーンノードを使う方法。こちらのアプローチは、必要なインフラストラクチャーが少ないです。etcdのメンバーと、コントロールプレーンノードは同じ場所に置かれます。
|
||||
- 外部のetcdクラスターを使う方法。こちらのアプローチには、より多くのインフラストラクチャーが必要です。コントロールプレーンノードと、etcdのメンバーは分離されます。
|
||||
|
||||
先へ進む前に、どちらのアプローチがアプリケーションの要件と、環境に適合するか、慎重に検討してください。[こちらの比較](/docs/setup/independent/ha-topology/)が、それぞれの利点/欠点について概説しています。
|
||||
先へ進む前に、どちらのアプローチがアプリケーションの要件と、環境に適合するか、慎重に検討してください。[こちらの比較](/ja/docs/setup/independent/ha-topology/)が、それぞれの利点/欠点について概説しています。
|
||||
|
||||
クラスターではKubernetesのバージョン1.12以降を使用する必要があります。また、kubeadmを使用した高可用性クラスターはまだ実験的な段階であり、将来のバージョンではもっとシンプルになることに注意してください。たとえば、クラスターのアップグレードに際し問題に遭遇するかもしれません。両方のアプローチを試し、kueadmの[issue tracker](https://github.com/kubernetes/kubeadm/issues/new)で我々にフィードバックを提供してくれることを推奨します。
|
||||
|
||||
@@ -136,14 +136,14 @@ alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.
|
||||
```sh
|
||||
sudo kubeadm init --config=kubeadm-config.yaml
|
||||
```
|
||||
|
||||
|
||||
このような出力がされます:
|
||||
|
||||
|
||||
```sh
|
||||
...
|
||||
You can now join any number of machines by running the following on each node
|
||||
as root:
|
||||
|
||||
|
||||
kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f
|
||||
```
|
||||
|
||||
+35
-13
@@ -10,9 +10,8 @@ card:
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<img src="https://raw.githubusercontent.com/cncf/artwork/master/projects/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">This page shows how to install the `kubeadm` toolbox.
|
||||
For information how to create a cluster with kubeadm once you have performed this installation process,
|
||||
see the [Using kubeadm to Create a Cluster](/docs/setup/independent/create-cluster-kubeadm/) page.
|
||||
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">This page shows how to install the `kubeadm` toolbox.
|
||||
For information how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -76,7 +75,7 @@ route, we recommend you add IP route(s) so Kubernetes cluster addresses go via t
|
||||
Any port numbers marked with * are overridable, so you will need to ensure any
|
||||
custom ports you provide are also open.
|
||||
|
||||
Although etcd ports are included in master nodes, you can also host your own
|
||||
Although etcd ports are included in control-plane nodes, you can also host your own
|
||||
etcd cluster externally or on custom ports.
|
||||
|
||||
The pod network plugin you use (see below) may also require certain ports to be
|
||||
@@ -86,7 +85,25 @@ documentation for the plugins about what port(s) those need.
|
||||
## ランタイムのインストール
|
||||
|
||||
Since v1.6.0, Kubernetes has enabled the use of CRI, Container Runtime Interface, by default.
|
||||
The container runtime used by default is Docker, which is enabled through the built-in
|
||||
|
||||
Since v1.14.0, kubeadm will try to automatically detect the container runtime on Linux nodes
|
||||
by scanning through a list of well known domain sockets. The detectable runtimes and the
|
||||
socket paths, that are used, can be found in the table below.
|
||||
|
||||
| Runtime | Domain Socket |
|
||||
|------------|----------------------------------|
|
||||
| Docker | /var/run/docker.sock |
|
||||
| containerd | /run/containerd/containerd.sock |
|
||||
| CRI-O | /var/run/crio/crio.sock |
|
||||
|
||||
If both Docker and containerd are detected together, Docker takes precedence. This is
|
||||
needed, because Docker 18.09 ships with containerd and both are detectable.
|
||||
If any other two or more runtimes are detected, kubeadm will exit with an appropriate
|
||||
error message.
|
||||
|
||||
On non-Linux nodes the container runtime used by default is Docker.
|
||||
|
||||
If the container runtime of choice is Docker, it is used through the built-in
|
||||
`dockershim` CRI implementation inside of the `kubelet`.
|
||||
|
||||
Other CRI-based runtimes include:
|
||||
@@ -95,7 +112,7 @@ Other CRI-based runtimes include:
|
||||
- [cri-o](https://cri-o.io/)
|
||||
- [frakti](https://github.com/kubernetes/frakti)
|
||||
|
||||
Refer to the [CRI installation instructions](/docs/setup/cri) for more information.
|
||||
Refer to the [CRI installation instructions](/ja/docs/setup/cri) for more information.
|
||||
|
||||
## kubeadm、kubelet、kubectlのインストール
|
||||
|
||||
@@ -116,6 +133,8 @@ kubelet and the control plane is supported, but the kubelet version may never ex
|
||||
server version. For example, kubelets running 1.7.0 should be fully compatible with a 1.8.0 API server,
|
||||
but not vice versa.
|
||||
|
||||
For information about installing `kubectl`, see [Install and set up kubectl](/docs/tasks/tools/install-kubectl/).
|
||||
|
||||
{{< warning >}}
|
||||
These instructions exclude all Kubernetes packages from any system upgrades.
|
||||
This is because kubeadm and Kubernetes require
|
||||
@@ -124,8 +143,8 @@ This is because kubeadm and Kubernetes require
|
||||
|
||||
For more information on version skews, see:
|
||||
|
||||
* Kubernetes [version and version-skew policy](/docs/setup/version-skew-policy/)
|
||||
* Kubeadm-specific [version skew policy](/docs/setup/independent/create-cluster-kubeadm/#version-skew-policy)
|
||||
* Kubernetes [version and version-skew policy](/ja/docs/setup/release/version-skew-policy/)
|
||||
* Kubeadm-specific [version skew policy](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)
|
||||
|
||||
{{< tabs name="k8s_install" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
@@ -150,7 +169,6 @@ enabled=1
|
||||
gpgcheck=1
|
||||
repo_gpgcheck=1
|
||||
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
|
||||
exclude=kube*
|
||||
EOF
|
||||
|
||||
# Set SELinux in permissive mode (effectively disabling it)
|
||||
@@ -183,7 +201,7 @@ systemctl enable --now kubelet
|
||||
Install CNI plugins (required for most pod network):
|
||||
|
||||
```bash
|
||||
CNI_VERSION="v0.6.0"
|
||||
CNI_VERSION="v0.7.5"
|
||||
mkdir -p /opt/cni/bin
|
||||
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz
|
||||
```
|
||||
@@ -191,7 +209,7 @@ curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_
|
||||
Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI))
|
||||
|
||||
```bash
|
||||
CRICTL_VERSION="v1.11.1"
|
||||
CRICTL_VERSION="v1.12.0"
|
||||
mkdir -p /opt/bin
|
||||
curl -L "https://github.com/kubernetes-incubator/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz
|
||||
```
|
||||
@@ -248,12 +266,16 @@ systemctl daemon-reload
|
||||
systemctl restart kubelet
|
||||
```
|
||||
|
||||
The automatic detection of cgroup driver for other container runtimes
|
||||
like CRI-O and containerd is work in progress.
|
||||
|
||||
|
||||
## トラブルシュート
|
||||
|
||||
If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/independent/troubleshooting-kubeadm/).
|
||||
If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/).
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Using kubeadm to Create a Cluster](/docs/setup/independent/create-cluster-kubeadm/)
|
||||
* [Using kubeadm to Create a Cluster](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
|
||||
|
||||
{{% /capture %}}
|
||||
+2
-2
@@ -94,7 +94,7 @@ such as systemd.
|
||||
It is possible to configure the kubelet that kubeadm will start if a custom `KubeletConfiguration`
|
||||
API object is passed with a configuration file like so `kubeadm ... --config some-config-file.yaml`.
|
||||
|
||||
By calling `kubeadm config print-default --api-objects KubeletConfiguration` you can
|
||||
By calling `kubeadm config print init-defaults --component-configs KubeletConfiguration` you can
|
||||
see all the default values for this structure.
|
||||
|
||||
Also have a look at the [API reference for the
|
||||
@@ -136,7 +136,7 @@ If the reload and restart are successful, the normal `kubeadm init` workflow con
|
||||
|
||||
### `kubeadm join`実行時の流れ
|
||||
|
||||
When you run `kubeadm join`, kubeadm uses the Bootstrap Token credential perform
|
||||
When you run `kubeadm join`, kubeadm uses the Bootstrap Token credential to perform
|
||||
a TLS bootstrap, which fetches the credential needed to download the
|
||||
`kubelet-config-1.X` ConfigMap and writes it to `/var/lib/kubelet/config.yaml`. The dynamic
|
||||
environment file is generated in exactly the same way as `kubeadm init`.
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: Configuring your kubernetes cluster to self-host the control plane
|
||||
content_template: templates/concept
|
||||
weight: 100
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
### Self-hosting the Kubernetes control plane {#self-hosting}
|
||||
|
||||
As of 1.8, you can experimentally create a _self-hosted_ Kubernetes control
|
||||
plane. This means that key components such as the API server, controller
|
||||
manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
|
||||
configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/)
|
||||
configured in the kubelet via static files.
|
||||
|
||||
To create a self-hosted cluster see the
|
||||
[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
#### Caveats
|
||||
|
||||
{{< caution >}}
|
||||
This feature pivots your cluster into an unsupported state, rendering kubeadm unable
|
||||
to manage you cluster any longer. This includes `kubeadm upgrade`.
|
||||
{{< /caution >}}
|
||||
|
||||
1. Self-hosting in 1.8 and later has some important limitations. In particular, a
|
||||
self-hosted cluster _cannot recover from a reboot of the control-plane node_
|
||||
without manual intervention.
|
||||
|
||||
1. By default, self-hosted control plane Pods rely on credentials loaded from
|
||||
[`hostPath`](/docs/concepts/storage/volumes/#hostpath)
|
||||
volumes. Except for initial creation, these credentials are not managed by
|
||||
kubeadm.
|
||||
|
||||
1. The self-hosted portion of the control plane does not include etcd,
|
||||
which still runs as a static Pod.
|
||||
|
||||
#### Process
|
||||
|
||||
The self-hosting bootstrap process is documented in the [kubeadm design
|
||||
document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting).
|
||||
|
||||
In summary, `kubeadm alpha selfhosting` works as follows:
|
||||
|
||||
1. Waits for this bootstrap static control plane to be running and
|
||||
healthy. This is identical to the `kubeadm init` process without self-hosting.
|
||||
|
||||
1. Uses the static control plane Pod manifests to construct a set of
|
||||
DaemonSet manifests that will run the self-hosted control plane.
|
||||
It also modifies these manifests where necessary, for example adding new volumes
|
||||
for secrets.
|
||||
|
||||
1. Creates DaemonSets in the `kube-system` namespace and waits for the
|
||||
resulting Pods to be running.
|
||||
|
||||
1. Once self-hosted Pods are operational, their associated static Pods are deleted
|
||||
and kubeadm moves on to install the next component. This triggers kubelet to
|
||||
stop those static Pods.
|
||||
|
||||
1. When the original static control plane stops, the new self-hosted control
|
||||
plane is able to bind to listening ports and become active.
|
||||
|
||||
{{% /capture %}}
|
||||
+2
-2
@@ -24,7 +24,7 @@ when using kubeadm to set up a kubernetes cluster.
|
||||
* Some infrastructure to copy files between hosts. For example `ssh` and `scp`
|
||||
can satisfy this requirement.
|
||||
|
||||
[toolbox]: /docs/setup/independent/install-kubeadm/
|
||||
[toolbox]: /docs/setup/production-environment/tools/kubeadm/install-kubeadm/
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -257,7 +257,7 @@ this example.
|
||||
|
||||
Once you have a working 3 member etcd cluster, you can continue setting up a
|
||||
highly available control plane using the [external etcd method with
|
||||
kubeadm](/docs/setup/independent/high-availability/).
|
||||
kubeadm](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
+63
-6
@@ -58,10 +58,10 @@ This may be caused by a number of problems. The most common are:
|
||||
There are two common ways to fix the cgroup driver problem:
|
||||
|
||||
1. Install Docker again following instructions
|
||||
[here](/docs/setup/independent/install-kubeadm/#installing-docker).
|
||||
[here](/ja/docs/setup/independent/install-kubeadm/#installing-docker).
|
||||
|
||||
1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to
|
||||
[Configure cgroup driver used by kubelet on Master Node](/docs/setup/independent/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
|
||||
for detailed instructions.
|
||||
[Configure cgroup driver used by kubelet on Master Node](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
|
||||
|
||||
- control plane Docker containers are crashlooping or hanging. You can check this by running `docker ps` and investigating each container by running `docker logs`.
|
||||
|
||||
@@ -100,7 +100,7 @@ Right after `kubeadm init` there should not be any pods in these states.
|
||||
until you have deployed the network solution.
|
||||
- If you see Pods in the `RunContainerError`, `CrashLoopBackOff` or `Error` state
|
||||
after deploying the network solution and nothing happens to `coredns` (or `kube-dns`),
|
||||
it's very likely that the Pod Network solution that you installed is somehow broken.
|
||||
it's very likely that the Pod Network solution that you installed is somehow broken.
|
||||
You might have to grant it more RBAC privileges or use a newer version. Please file
|
||||
an issue in the Pod Network providers' issue tracker and get the issue triaged there.
|
||||
- If you install a version of Docker older than 1.12.1, remove the `MountFlags=slave` option
|
||||
@@ -113,7 +113,7 @@ Right after `kubeadm init` there should not be any pods in these states.
|
||||
This is **expected** and part of the design. kubeadm is network provider-agnostic, so the admin
|
||||
should [install the pod network solution](/docs/concepts/cluster-administration/addons/)
|
||||
of choice. You have to install a Pod Network
|
||||
before CoreDNS may deployed fully. Hence the `Pending` state before the network is set up.
|
||||
before CoreDNS may be deployed fully. Hence the `Pending` state before the network is set up.
|
||||
|
||||
## `HostPort`サービスが動かない
|
||||
|
||||
@@ -219,7 +219,8 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6
|
||||
If you have nodes that are running SELinux with an older version of Docker you might experience a scenario
|
||||
where the `coredns` pods are not starting. To solve that you can try one of the following options:
|
||||
|
||||
- Upgrade to a [newer version of Docker](/docs/setup/independent/install-kubeadm/#installing-docker).
|
||||
- Upgrade to a [newer version of Docker](/ja/docs/setup/independent/install-kubeadm/#installing-docker).
|
||||
|
||||
- [Disable SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux).
|
||||
- Modify the `coredns` deployment to set `allowPrivilegeEscalation` to `true`:
|
||||
|
||||
@@ -261,4 +262,60 @@ sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/dock
|
||||
yum install docker-ce-18.06.1.ce-3.el7.x86_64
|
||||
```
|
||||
|
||||
## Not possible to pass a comma separated list of values to arguments inside a `--component-extra-args` flag
|
||||
|
||||
`kubeadm init` flags such as `--component-extra-args` allow you to pass custom arguments to a control-plane
|
||||
component like the kube-apiserver. However, this mechanism is limited due to the underlying type used for parsing
|
||||
the values (`mapStringString`).
|
||||
|
||||
If you decide to pass an argument that supports multiple, comma-separated values such as
|
||||
`--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"` this flag will fail with
|
||||
`flag: malformed pair, expect string=string`. This happens because the list of arguments for
|
||||
`--apiserver-extra-args` expects `key=value` pairs and in this case `NamespacesExists` is considered
|
||||
as a key that is missing a value.
|
||||
|
||||
Alternatively, you can try separating the `key=value` pairs like so:
|
||||
`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
|
||||
but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`.
|
||||
|
||||
A known workaround is to use the kubeadm [configuration file](/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags).
|
||||
|
||||
## kube-proxy scheduled before node is initialized by cloud-controller-manager
|
||||
|
||||
In cloud provider scenarios, kube-proxy can end up being scheduled on new worker nodes before
|
||||
the cloud-controller-manager has initialized the node addresses. This causes kube-proxy to fail
|
||||
to pick up the node's IP address properly and has knock-on effects to the proxy function managing
|
||||
load balancers.
|
||||
|
||||
The following error can be seen in kube-proxy Pods:
|
||||
```
|
||||
server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: []
|
||||
proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP
|
||||
```
|
||||
|
||||
A known solution is to patch the kube-proxy DaemonSet to allow scheduling it on control-plane
|
||||
nodes regardless of their conditions, keeping it off of other nodes until their initial guarding
|
||||
conditions abate:
|
||||
```
|
||||
kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/master" } ] } } } }'
|
||||
```
|
||||
|
||||
The tracking issue for this problem is [here](https://github.com/kubernetes/kubeadm/issues/1027).
|
||||
|
||||
## The NodeRegistration.Taints field is omitted when marshalling kubeadm configuration
|
||||
|
||||
*Note: This [issue](https://github.com/kubernetes/kubeadm/issues/1358) only applies to tools that marshal kubeadm types (e.g. to a YAML configuration file). It will be fixed in kubeadm API v1beta2.*
|
||||
|
||||
By default, kubeadm applies the `role.kubernetes.io/master:NoSchedule` taint to control-plane nodes.
|
||||
If you prefer kubeadm to not taint the control-plane node, and set `InitConfiguration.NodeRegistration.Taints` to an empty slice,
|
||||
the field will be omitted when marshalling. When the field is omitted, kubeadm applies the default taint.
|
||||
|
||||
There are at least two workarounds:
|
||||
|
||||
1. Use the `role.kubernetes.io/master:PreferNoSchedule` taint instead of an empty slice. [Pods will get scheduled on masters](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/), unless other nodes have capacity.
|
||||
|
||||
2. Remove the taint after kubeadm init exits:
|
||||
```bash
|
||||
kubectl taint nodes NODE_NAME role.kubernetes.io/master:NoSchedule-
|
||||
```
|
||||
{{% /capture %}}
|
||||
+2
-1
@@ -1,6 +1,7 @@
|
||||
---
|
||||
title: kubesprayを使ったオンプレミス/クラウドプロバイダへのKubernetesのインストール
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
@@ -75,7 +76,7 @@ Next, deploy your cluster:
|
||||
Cluster deployment using [ansible-playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
|
||||
|
||||
```shell
|
||||
ansible-playbook -i your/inventory/hosts.ini cluster.yml -b -v \
|
||||
ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \
|
||||
--private-key=~/.ssh/private_key
|
||||
```
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: Turnkey Cloud Solutions
|
||||
weight: 40
|
||||
---
|
||||
+1
-1
@@ -6,7 +6,7 @@ title: Alibaba CloudでKubernetesを動かす
|
||||
|
||||
[Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service)はAlibaba Cloud ECSインスタンスのクラスター上でDockerアプリケーションを起動して管理します。著名なオープンソースのコンテナオーケストレーターであるDocker SwarmおよびKubernetesをサポートしています。
|
||||
|
||||
クラスターの構築と管理を簡素化する為に、[Alibaba Cloud Container Serviceの為のKubernetesサポート](https://www.alibabacloud.com/product/kubernetes)を使用します。[Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm)に従ってすぐに始めることができ、中国語の[Alibaba CloudにおけるKubernetesサポートの為のチュートリアル](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)もあります。
|
||||
クラスターの構築と管理を簡素化する為に、[Alibaba Cloud Container Serviceの為のKubernetesサポート](https://www.alibabacloud.com/product/kubernetes)を使用します。[Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm)に従ってすぐに始めることができ、中国語の[Alibaba CloudにおけるKubernetesサポートの為のチュートリアル](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)もあります。
|
||||
|
||||
カスタムバイナリもしくはオープンソースKubernetesを使用する場合は、以下の手順に従って下さい。
|
||||
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
title: AWS EC2上でKubernetesを動かす
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
このページでは、AWS上でKubernetesクラスターをインストールする方法について説明します。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
AWS上でKubernetesクラスターを作成するには、AWSからアクセスキーIDおよびシークレットアクセスキーを入手する必要があります。
|
||||
|
||||
### サポートされているプロダクショングレードのツール
|
||||
|
||||
* [conjure-up](/docs/getting-started-guides/ubuntu/)はUbuntu上でネイティブなAWSインテグレーションを用いてKubernetesクラスターを作成するオープンソースのインストーラーです。
|
||||
|
||||
* [Kubernetes Operations](https://github.com/kubernetes/kops) - プロダクショングレードなKubernetesのインストール、アップグレード、管理が可能です。AWS上のDebian、Ubuntu、CentOS、RHELをサポートしています。
|
||||
|
||||
* [CoreOS Tectonic](https://coreos.com/tectonic/)はAWS上のContainer Linuxノードを含むKubernetesクラスターを作成できる、オープンソースの[Tectonic Installer](https://github.com/coreos/tectonic-installer)を含みます。
|
||||
|
||||
* CoreOSから生まれ、Kubernetes IncubatorがメンテナンスしているCLIツール[kube-aws](https://github.com/kubernetes-incubator/kube-aws)は、[Container Linux](https://coreos.com/why/)ノードを使用したAWSツール(EC2、CloudFormation、Auto Scaling)によるKubernetesクラスターを作成および管理できます。
|
||||
|
||||
* [KubeOne](https://github.com/kubermatic/kubeone)は可用性の高いKubernetesクラスターを作成、アップグレード、管理するための、オープンソースのライフサイクル管理ツールです。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## クラスターの始まり
|
||||
|
||||
### コマンドライン管理ツール: kubectl
|
||||
|
||||
クラスターの起動スクリプトによってワークステーション上に`kubernetes`ディレクトリが作成されます。もしくは、Kubernetesの最新リリースを[こちら](https://github.com/kubernetes/kubernetes/releases)からダウンロードすることも可能です。
|
||||
|
||||
次に、kubectlにアクセスするために適切なバイナリフォルダーを`PATH`へ追加します:
|
||||
|
||||
```shell
|
||||
# macOS
|
||||
export PATH=<path/to/kubernetes-directory>/platforms/darwin/amd64:$PATH
|
||||
|
||||
# Linux
|
||||
export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH
|
||||
```
|
||||
|
||||
ツールに関する最新のドキュメントページはこちらです: [kubectl manual](/docs/user-guide/kubectl/)
|
||||
|
||||
デフォルトでは、`kubectl`はクラスターの起動中に生成された`kubeconfig`ファイルをAPIに対する認証に使用します。
|
||||
詳細な情報は、[kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)を参照してください。
|
||||
|
||||
### 例
|
||||
|
||||
新しいクラスターを試すには、[簡単なnginxの例](/docs/tasks/run-application/run-stateless-application-deployment/)を参照してください。
|
||||
|
||||
"Guestbook"アプリケーションは、Kubernetesを始めるもう一つのポピュラーな例です: [guestbookの例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)
|
||||
|
||||
より完全なアプリケーションについては、[examplesディレクトリ](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)を参照してください。
|
||||
|
||||
## クラスターのスケーリング
|
||||
|
||||
`kubectl`を使用したノードの追加および削除はサポートしていません。インストール中に作成された[Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html)内の'Desired'および'Max'プロパティを手動で調整することで、ノード数をスケールさせることができます。
|
||||
|
||||
## クラスターの解体
|
||||
|
||||
クラスターのプロビジョニングに使用した環境変数がexportされていることを確認してから、`kubernetes`ディレクトリ内で以下のスクリプトを実行してください:
|
||||
|
||||
```shell
|
||||
cluster/kube-down.sh
|
||||
```
|
||||
|
||||
## サポートレベル
|
||||
|
||||
|
||||
IaaS プロバイダー | 構成管理 | OS | ネットワーク | ドキュメント | 適合 | サポートレベル
|
||||
-------------------- | ------------ | ------------- | ------------ | --------------------------------------------- | ---------| ----------------------------
|
||||
AWS | kops | Debian | k8s (VPC) | [docs](https://github.com/kubernetes/kops) | | Community ([@justinsb](https://github.com/justinsb))
|
||||
AWS | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/aws) | | Community
|
||||
AWS | Juju | Ubuntu | flannel, calico, canal | [docs](/docs/getting-started-guides/ubuntu) | 100% | Commercial, Community
|
||||
AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weavenet | [docs](https://github.com/kubermatic/kubeone) | 100% | Commercial, Community
|
||||
|
||||
## 参考文献
|
||||
|
||||
Kubernetesクラスターの利用と管理に関する詳細は、[Kubernetesドキュメント](/ja/docs/)を参照してください。
|
||||
|
||||
{{% /capture %}}
|
||||
+11
-13
@@ -2,7 +2,6 @@
|
||||
title: CenturyLink Cloud上でKubernetesを動かす
|
||||
---
|
||||
|
||||
{: toc}
|
||||
|
||||
These scripts handle the creation, deletion and expansion of Kubernetes clusters on CenturyLink Cloud.
|
||||
|
||||
@@ -238,12 +237,11 @@ utility ```kubectl```. If you do not already have a copy of this binary on your
|
||||
administrative machine, you may run the script ```install_kubectl.sh``` which will
|
||||
download it and install it in ```/usr/bin/local```.
|
||||
|
||||
The script requires that the environment variable ```CLC_CLUSTER_NAME``` be defined
|
||||
|
||||
```install_kubectl.sh``` also writes a configuration file which will embed the necessary
|
||||
The script requires that the environment variable ```CLC_CLUSTER_NAME``` be defined. ```install_kubectl.sh``` also writes a configuration file which will embed the necessary
|
||||
authentication certificates for the particular cluster. The configuration file is
|
||||
written to the ```${CLC_CLUSTER_HOME}/kube``` directory
|
||||
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=${CLC_CLUSTER_HOME}/kube/config
|
||||
kubectl version
|
||||
@@ -252,7 +250,7 @@ kubectl cluster-info
|
||||
|
||||
### プログラムでクラスターへアクセス
|
||||
|
||||
It's possible to use the locally stored client certificates to access the apiserver. For example, you may want to use any of the [Kubernetes API client libraries](/docs/reference/using-api/client-libraries/) to program against your Kubernetes cluster in the programming language of your choice.
|
||||
It's possible to use the locally stored client certificates to access the apiserver. For example, you may want to use any of the [Kubernetes API client libraries](/docs/reference/using-api/client-libraries/) to program against your Kubernetes cluster in the programming language of your choice.
|
||||
|
||||
To demonstrate how to use these locally stored certificates, we provide the following example of using ```curl``` to communicate to the master apiserver via https:
|
||||
|
||||
@@ -273,18 +271,18 @@ create a cluster, the script should output URLs for these interfaces like this:
|
||||
|
||||
kubernetes-dashboard is running at ```https://${MASTER_IP}:6443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy```.
|
||||
|
||||
Note on Authentication to the UIs: The cluster is set up to use basic
|
||||
authentication for the user _admin_. Hitting the url at
|
||||
```https://${MASTER_IP}:6443``` will require accepting the self-signed certificate
|
||||
from the apiserver, and then presenting the admin password written to file at:
|
||||
Note on Authentication to the UIs:
|
||||
|
||||
```> _${CLC_CLUSTER_HOME}/kube/admin_password.txt_```
|
||||
The cluster is set up to use basic authentication for the user _admin_.
|
||||
Hitting the url at ```https://${MASTER_IP}:6443``` will
|
||||
require accepting the self-signed certificate
|
||||
from the apiserver, and then presenting the admin
|
||||
password written to file at: ```> _${CLC_CLUSTER_HOME}/kube/admin_password.txt_```
|
||||
|
||||
|
||||
### 設定ファイル
|
||||
|
||||
Various configuration files are written into the home directory *CLC_CLUSTER_HOME* under
|
||||
```.clc_kube/${CLC_CLUSTER_NAME}``` in several subdirectories. You can use these files
|
||||
Various configuration files are written into the home directory *CLC_CLUSTER_HOME* under ```.clc_kube/${CLC_CLUSTER_NAME}``` in several subdirectories. You can use these files
|
||||
to access the cluster from machines other than where you created the cluster from.
|
||||
|
||||
* ```config/```: Ansible variable files containing parameters describing the master and minion hosts
|
||||
@@ -335,7 +333,7 @@ If you want more information about our Ansible files, please [read this file](ht
|
||||
|
||||
## 参考文献
|
||||
|
||||
Please see the [Kubernetes docs](/docs/) for more details on administering
|
||||
Please see the [Kubernetes docs](/ja/docs/) for more details on administering
|
||||
and using a Kubernetes cluster.
|
||||
|
||||
|
||||
+3
-4
@@ -65,7 +65,7 @@ cluster/kube-up.sh
|
||||
|
||||
If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `<kubernetes>/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster.
|
||||
|
||||
If you run into trouble, please see the section on [troubleshooting](/docs/setup/turnkey/gce/#troubleshooting), post to the
|
||||
If you run into trouble, please see the section on [troubleshooting](/ja/docs/setup/production-environment/turnkey/gce/#troubleshooting), post to the
|
||||
[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting/#slack).
|
||||
|
||||
The next few steps will show you:
|
||||
@@ -212,13 +212,12 @@ field values:
|
||||
|
||||
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
|
||||
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
|
||||
GCE | Saltstack | Debian | GCE | [docs](/docs/setup/turnkey/gce/) | | Project
|
||||
GCE | Saltstack | Debian | GCE | [docs](/ja/docs/setup/production-environment/turnkey/gce/) | | Project
|
||||
|
||||
For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart.
|
||||
|
||||
## 参考文献
|
||||
|
||||
Please see the [Kubernetes docs](/docs/) for more details on administering
|
||||
Please see the [Kubernetes docs](/ja/docs/) for more details on administering
|
||||
and using a Kubernetes cluster.
|
||||
|
||||
{{% /capture %}}
|
||||
+9
-9
@@ -31,7 +31,7 @@ To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secr
|
||||
|
||||
1. Configure Your Cluster
|
||||
|
||||
Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
|
||||
Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
|
||||
|
||||
1. Run the Cluster
|
||||
|
||||
@@ -60,7 +60,7 @@ To create a Kubernetes cluster on GCE, you will need the Service Account JSON Da
|
||||
|
||||
1. Configure Your Cluster
|
||||
|
||||
Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
|
||||
Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
|
||||
|
||||
1. Run the Cluster
|
||||
|
||||
@@ -89,13 +89,13 @@ To create a Kubernetes cluster on Google Kubernetes Engine, you will need the Se
|
||||
|
||||
1. Configure Your Cluster
|
||||
|
||||
Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
|
||||
Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
|
||||
|
||||
1. Run the Cluster
|
||||
|
||||
You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
|
||||
|
||||
For information on using and managing a Kubernetes cluster on Google Kubernetes Engine, consult [the official documentation](/docs/home/).
|
||||
For information on using and managing a Kubernetes cluster on Google Kubernetes Engine, consult [the official documentation](/ja/docs/home/).
|
||||
|
||||
|
||||
## DigitalOcean
|
||||
@@ -118,13 +118,13 @@ To create a Kubernetes cluster on DigitalOcean, you will need a DigitalOcean API
|
||||
|
||||
1. Configure Your Cluster
|
||||
|
||||
Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
|
||||
Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
|
||||
|
||||
1. Run the Cluster
|
||||
|
||||
You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
|
||||
|
||||
For information on using and managing a Kubernetes cluster on DigitalOcean, consult [the official documentation](/docs/home/).
|
||||
For information on using and managing a Kubernetes cluster on DigitalOcean, consult [the official documentation](/ja/docs/home/).
|
||||
|
||||
|
||||
## Microsoft Azure
|
||||
@@ -147,7 +147,7 @@ To create a Kubernetes cluster on Microsoft Azure, you will need an Azure Subscr
|
||||
|
||||
1. Configure Your Cluster
|
||||
|
||||
Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
|
||||
Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
|
||||
|
||||
1. Run the Cluster
|
||||
|
||||
@@ -176,12 +176,12 @@ To create a Kubernetes cluster on Packet, you will need a Packet API Key.
|
||||
|
||||
1. Configure Your Cluster
|
||||
|
||||
Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
|
||||
Choose any extra options you may want to include with your cluster, then click **SUBMIT** to create the cluster.
|
||||
|
||||
1. Run the Cluster
|
||||
|
||||
You can monitor the status of your cluster and suspend or delete it from [your stackpoint.io dashboard](https://stackpoint.io/#/clusters).
|
||||
|
||||
For information on using and managing a Kubernetes cluster on Packet, consult [the official documentation](/docs/home/).
|
||||
For information on using and managing a Kubernetes cluster on Packet, consult [the official documentation](/ja/docs/home/).
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: "Windows in Kubernetes"
|
||||
weight: 50
|
||||
---
|
||||
BIN
Binary file not shown.
|
After Width: | Height: | Size: 109 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 25 KiB |
@@ -0,0 +1,590 @@
|
||||
---
|
||||
reviewers:
|
||||
- michmike
|
||||
- patricklang
|
||||
title: Intro to Windows support in Kubernetes
|
||||
content_template: templates/concept
|
||||
weight: 65
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Windows applications constitute a large portion of the services and applications that run in many organizations. [Windows containers](https://aka.ms/windowscontainers) provide a modern way to encapsulate processes and package dependencies, making it easier to use DevOps practices and follow cloud native patterns for Windows applications. Kubernetes has become the defacto standard container orchestrator, and the release of Kubernetes 1.14 includes production support for scheduling Windows containers on Windows nodes in a Kubernetes cluster, enabling a vast ecosystem of Windows applications to leverage the power of Kubernetes. Organizations with investments in Windows-based applications and Linux-based applications don't have to look for separate orchestrators to manage their workloads, leading to increased operational efficiencies across their deployments, regardless of operating system.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Windows containers in Kubernetes
|
||||
|
||||
To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in [Pods](/ja/docs/concepts/workloads/pods/pod-overview/) on Kubernetes is as simple and easy as scheduling Linux-based containers.
|
||||
|
||||
In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling [Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) on Windows (including kubelet, [container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), and kube-proxy). For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
|
||||
|
||||
{{< note >}}
|
||||
The Kubernetes control plane, including the [master components](/ja/docs/concepts/overview/components/), continues to run on Linux. There are no plans to have a Windows-only Kubernetes cluster.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
In this document, when we talk about Windows containers we mean Windows containers with process isolation. Windows containers with [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) is planned for a future release.
|
||||
{{< /note >}}
|
||||
|
||||
## Supported Functionality and Limitations
|
||||
|
||||
### Supported Functionality
|
||||
|
||||
#### Compute
|
||||
|
||||
From an API and kubectl perspective, Windows containers behave in much the same way as Linux-based containers. However, there are some notable differences in key functionality which are outlined in the limitation section.
|
||||
|
||||
Let's start with the operating system version. Refer to the following table for Windows operating system support in Kubernetes. A single heterogeneous Kubernetes cluster can have both Windows and Linux worker nodes. Windows containers have to be scheduled on Windows nodes and Linux containers on Linux nodes.
|
||||
|
||||
| Kubernetes version | Host OS version (Kubernetes Node) | | |
|
||||
| --- | --- | --- | --- |
|
||||
| | *Windows Server 1709* | *Windows Server 1803* | *Windows Server 1809/Windows Server 2019* |
|
||||
| *Kubernetes v1.14* | Not Supported | Not Supported| Supported for Windows Server containers Builds 17763.* with Docker EE-basic 18.09 |
|
||||
|
||||
{{< note >}}
|
||||
We don't expect all Windows customers to update the operating system for their apps frequently. Upgrading your applications is what dictates and necessitates upgrading or introducing new nodes to the cluster. For the customers that chose to upgrade their operating system for containers running on Kubernetes, we will offer guidance and step-by-step instructions when we add support for a new operating system version. This guidance will include recommended upgrade procedures for upgrading user applications together with cluster nodes. Windows nodes adhere to Kubernetes [version-skew policy](/ja/docs/setup/release/version-skew-policy/) (node to control plane versioning) the same way as Linux nodes do today.
|
||||
{{< /note >}}
|
||||
{{< note >}}
|
||||
The Windows Server Host Operating System is subject to the [Windows Server ](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) licensing. The Windows Container images are subject to the [Supplemental License Terms for Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula).
|
||||
{{< /note >}}
|
||||
{{< note >}}
|
||||
Windows containers with process isolation have strict compatibility rules, [where the host OS version must match the container base image OS version](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility). Once we support Windows containers with Hyper-V isolation in Kubernetes, the limitation and compatibility rules will change.
|
||||
{{< /note >}}
|
||||
|
||||
Key Kubernetes elements work the same way in Windows as they do in Linux. In this section, we talk about some of the key workload enablers and how they map to Windows.
|
||||
|
||||
* [Pods](/ja/docs/concepts/workloads/pods/pod-overview/)
|
||||
|
||||
A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. The following Pod capabilities, properties and events are supported with Windows containers:
|
||||
|
||||
* Single or multiple containers per Pod with process isolation and volume sharing
|
||||
* Pod status fields
|
||||
* Readiness and Liveness probes
|
||||
* postStart & preStop container lifecycle events
|
||||
* ConfigMap, Secrets: as environment variables or volumes
|
||||
* EmptyDir
|
||||
* Named pipe host mounts
|
||||
* Resource limits
|
||||
* [Controllers](/ja/docs/concepts/workloads/controllers/)
|
||||
|
||||
Kubernetes controllers handle the desired state of Pods. The following workload controllers are supported with Windows containers:
|
||||
|
||||
* ReplicaSet
|
||||
* ReplicationController
|
||||
* Deployments
|
||||
* StatefulSets
|
||||
* DaemonSet
|
||||
* Job
|
||||
* CronJob
|
||||
* [Services](/ja/docs/concepts/services-networking/service/)
|
||||
|
||||
A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them - sometimes called a micro-service. You can use services for cross-operating system connectivity. In Windows, services can utilize the following types, properties and capabilities:
|
||||
|
||||
* Service Environment variables
|
||||
* NodePort
|
||||
* ClusterIP
|
||||
* LoadBalancer
|
||||
* ExternalName
|
||||
* Headless services
|
||||
|
||||
Pods, Controllers and Services are critical elements to managing Windows workloads on Kubernetes. However, on their own they are not enough to enable the proper lifecycle management of Windows workloads in a dynamic cloud native environment. We added support for the following features:
|
||||
|
||||
* Pod and container metrics
|
||||
* Horizontal Pod Autoscaler support
|
||||
* kubectl Exec
|
||||
* Resource Quotas
|
||||
* Scheduler preemption
|
||||
|
||||
#### Container Runtime
|
||||
|
||||
Docker EE-basic 18.09 is required on Windows Server 2019 / 1809 nodes for Kubernetes. This works with the dockershim code included in the kubelet. Additional runtimes such as CRI-ContainerD may be supported in later Kubernetes versions.
|
||||
|
||||
#### Storage
|
||||
|
||||
Kubernetes Volumes enable complex applications with data persistence and Pod volume sharing requirements to be deployed on Kubernetes. Kubernetes on Windows supports the following types of [volumes](/ja/docs/concepts/storage/volumes/):
|
||||
|
||||
* FlexVolume out-of-tree plugin with [SMB and iSCSI](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows) support
|
||||
* [azureDisk](/ja/docs/concepts/storage/volumes/#azuredisk)
|
||||
* [azureFile](/ja/docs/concepts/storage/volumes/#azurefile)
|
||||
* [gcePersistentDisk](/ja/docs/concepts/storage/volumes/#gcepersistentdisk)
|
||||
|
||||
#### Networking
|
||||
|
||||
Networking for Windows containers is exposed through [CNI plugins](/ja/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Windows containers function similarly to virtual machines in regards to networking. Each container has a virtual network adapter (vNIC) which is connected to a Hyper-V virtual switch (vSwitch). The Host Networking Service (HNS) and the Host Compute Service (HCS) work together to create containers and attach container vNICs to networks. HCS is responsible for the management of containers whereas HNS is responsible for the management of networking resources such as:
|
||||
|
||||
* Virtual networks (including creation of vSwitches)
|
||||
* Endpoints / vNICs
|
||||
* Namespaces
|
||||
* Policies (Packet encapsulations, Load-balancing rules, ACLs, NAT'ing rules, etc.)
|
||||
|
||||
The following service spec types are supported:
|
||||
|
||||
* NodePort
|
||||
* ClusterIP
|
||||
* LoadBalancer
|
||||
* ExternalName
|
||||
|
||||
Windows supports five different networking drivers/modes: L2bridge, L2tunnel, Overlay, Transparent, and NAT. In a heterogeneous cluster with Windows and Linux worker nodes, you need to select a networking solution that is compatible on both Windows and Linux. The following out-of-tree plugins are supported on Windows, with recommendations on when to use each CNI:
|
||||
|
||||
| Network Driver | Description | Container Packet Modifications | Network Plugins | Network Plugin Characteristics |
|
||||
| -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ |
|
||||
| L2bridge | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. Inter-container traffic is bridged inside the container host. | MAC is rewritten to host MAC, IP remains the same. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel host-gateway uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires L2 adjacency between container hosts |
|
||||
| L2Tunnel | This is a special case of l2bridge, but only used on Azure. All packets are sent to the virtualization host where SDN policy is applied. | MAC rewritten, IP visible on the underlay network | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI allows integration of containers with Azure vNET, and allows them to leverage the set of capabilities that [Azure Virtual Network provides](https://azure.microsoft.com/en-us/services/virtual-network/). For example, securely connect to Azure services or use Azure NSGs. See [azure-cni for some examples](https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-cni-advanced-networking) |
|
||||
| Overlay (Overlay networking for Windows in Kubernetes is in *alpha* stage) | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header, inner packet remains the same. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags) if you are restricted on IPs in your datacenter. This option may be used when the container hosts are not L2 adjacent but have L3 connectivity |
|
||||
| Transparent (special use case for [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)) | Requires an external vSwitch. Containers are attached to an external vSwitch which enables intra-pod communication via logical networks (logical switches and routers). | Packet is encapsulated either via [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) or [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) tunneling to reach pods which are not on the same host. <br/> Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller. <br/> NAT is done for north-south communication. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Deploy via ansible](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib). Distributed ACLs can be applied via Kubernetes policies. IPAM support. Load-balancing can be achieved without kube-proxy. NATing is done without using iptables/netsh. |
|
||||
| NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness |
|
||||
|
||||
As outlined above, the [Flannel](https://github.com/coreos/flannel) CNI [meta plugin](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel) is also supported on [Windows](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental) via the [VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) (**alpha support** ; delegates to win-overlay) and [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (stable support; delegates to win-bridge). This plugin supports delegating to one of the reference CNI plugins (win-overlay, win-bridge), to work in conjunction with Flannel daemon on Windows (Flanneld) for automatic node subnet lease assignment and HNS network creation. This plugin reads in its own configuration file (net-conf.json), and aggregates it with the environment variables from the FlannelD generated subnet.env file. It then delegates to one of the reference CNI plugins for network plumbing, and sends the correct configuration containing the node-assigned subnet to the IPAM plugin (e.g. host-local).
|
||||
|
||||
For the node, pod, and service objects, the following network flows are supported for TCP/UDP traffic:
|
||||
|
||||
* Pod -> Pod (IP)
|
||||
* Pod -> Pod (Name)
|
||||
* Pod -> Service (Cluster IP)
|
||||
* Pod -> Service (PQDN, but only if there are no ".")
|
||||
* Pod -> Service (FQDN)
|
||||
* Pod -> External (IP)
|
||||
* Pod -> External (DNS)
|
||||
* Node -> Pod
|
||||
* Pod -> Node
|
||||
|
||||
The following IPAM options are supported on Windows:
|
||||
|
||||
* [Host-local](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local)
|
||||
* HNS IPAM (Inbox platform IPAM, this is a fallback when no IPAM is set)
|
||||
* [Azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md) (for azure-cni only)
|
||||
|
||||
### Limitations
|
||||
|
||||
#### Control Plane
|
||||
|
||||
Windows is only supported as a worker node in the Kubernetes architecture and component matrix. This means that a Kubernetes cluster must always include Linux master nodes, zero or more Linux worker nodes, and zero or more Windows worker nodes.
|
||||
|
||||
#### Compute
|
||||
|
||||
##### Resource management and process isolation
|
||||
|
||||
Linux cgroups are used as a pod boundary for resource controls in Linux. Containers are created within that boundary for network, process and file system isolation. The cgroups APIs can be used to gather cpu/io/memory stats. In contrast, Windows uses a Job object per container with a system namespace filter to contain all processes in a container and provide logical isolation from the host. There is no way to run a Windows container without the namespace filtering in place. This means that system privileges cannot be asserted in the context of the host, and thus privileged containers are not available on Windows. Containers cannot assume an identity from the host because the Security Account Manager (SAM) is separate.
|
||||
|
||||
##### Operating System Restrictions
|
||||
|
||||
Windows has strict compatibility rules, where the host OS version must match the container base image OS version. Only Windows containers with a container operating system of Windows Server 2019 are supported. Hyper-V isolation of containers, enabling some backward compatibility of Windows container image versions, is planned for a future release.
|
||||
|
||||
##### Feature Restrictions
|
||||
|
||||
* TerminationGracePeriod: not implemented
|
||||
* Single file mapping: to be implemented with CRI-ContainerD
|
||||
* Termination message: to be implemented with CRI-ContainerD
|
||||
* Privileged Containers: not currently supported in Windows containers
|
||||
* HugePages: not currently supported in Windows containers
|
||||
* The existing node problem detector is Linux-only and requires privileged containers. In general, we don't expect this to be used on Windows because privileged containers are not supported
|
||||
* Not all features of shared namespaces are supported (see API section for more details)
|
||||
|
||||
##### Memory Reservations and Handling
|
||||
|
||||
Windows does not have an out-of-memory process killer as Linux does. Windows always treats all user-mode memory allocations as virtual, and pagefiles are mandatory. The net effect is that Windows won't reach out of memory conditions the same way Linux does, and processes page to disk instead of being subject to out of memory (OOM) termination. If memory is over-provisioned and all physical memory is exhausted, then paging can slow down performance.
|
||||
|
||||
Keeping memory usage within reasonable bounds is possible with a two-step process. First, use the kubelet parameters `--kubelet-reserve` and/or `--system-reserve` to account for memory usage on the node (outside of containers). This reduces [NodeAllocatable](/ja/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)). As you deploy workloads, use resource limits (must set only limits or limits must equal requests) on containers. This also subtracts from NodeAllocatable and prevents the scheduler from adding more pods once a node is full.
|
||||
|
||||
A best practice to avoid over-provisioning is to configure the kubelet with a system reserved memory of at least 2GB to account for Windows, Docker, and Kubernetes processes.
|
||||
|
||||
The behavior of the flags behave differently as described below:
|
||||
|
||||
* `--kubelet-reserve`, `--system-reserve` , and `--eviction-hard` flags update Node Allocatable
|
||||
* Eviction by using `--enforce-node-allocable` is not implemented
|
||||
* Eviction by using `--eviction-hard` and `--eviction-soft` are not implemented
|
||||
* MemoryPressure Condition is not implemented
|
||||
* There are no OOM eviction actions taken by the kubelet
|
||||
* Kubelet running on the windows node does not have memory restrictions. `--kubelet-reserve` and `--system-reserve` do not set limits on kubelet or processes running on the host. This means kubelet or a process on the host could cause memory resource starvation outside the node-allocatable and scheduler
|
||||
|
||||
#### Storage
|
||||
|
||||
Windows has a layered filesystem driver to mount container layers and create a copy filesystem based on NTFS. All file paths in the container are resolved only within the context of that container.
|
||||
|
||||
* Volume mounts can only target a directory in the container, and not an individual file
|
||||
* Volume mounts cannot project files or directories back to the host filesystem
|
||||
* Read-only filesystems are not supported because write access is always required for the Windows registry and SAM database. However, read-only volumes are supported
|
||||
* Volume user-masks and permissions are not available. Because the SAM is not shared between the host & container, there's no mapping between them. All permissions are resolved within the context of the container
|
||||
|
||||
As a result, the following storage functionality is not supported on Windows nodes
|
||||
|
||||
* Volume subpath mounts. Only the entire volume can be mounted in a Windows container.
|
||||
* Subpath volume mounting for Secrets
|
||||
* Host mount projection
|
||||
* DefaultMode (due to UID/GID dependency)
|
||||
* Read-only root filesystem. Mapped volumes still support readOnly
|
||||
* Block device mapping
|
||||
* Memory as the storage medium
|
||||
* CSI plugins which require privileged containers
|
||||
* File system features like uui/guid, per-user Linux filesystem permissions
|
||||
* NFS based storage/volume support
|
||||
* Expanding the mounted volume (resizefs)
|
||||
|
||||
#### Networking
|
||||
|
||||
Windows Container Networking differs in some important ways from Linux networking. The [Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) contains additional details and background.
|
||||
|
||||
The Windows host networking networking service and virtual switch implement namespacing and can create virtual NICs as needed for a pod or container. However, many configurations such as DNS, routes, and metrics are stored in the Windows registry database rather than /etc/... files as they are on Linux. The Windows registry for the container is separate from that of the host, so concepts like mapping /etc/resolv.conf from the host into a container don't have the same effect they would on Linux. These must be configured using Windows APIs run in the context of that container. Therefore CNI implementations need to call the HNS instead of relying on file mappings to pass network details into the pod or container.
|
||||
|
||||
The following networking functionality is not supported on Windows nodes
|
||||
|
||||
* Host networking mode is not available for Windows pods
|
||||
* Local NodePort access from the node itself fails (works for other nodes or external clients)
|
||||
* Accessing service VIPs from nodes will be available with a future release of Windows Server
|
||||
* Overlay networking support in kube-proxy is an alpha release. In addition, it requires [KB4482887](https://support.microsoft.com/en-us/help/4482887/windows-10-update-kb4482887) to be installed on Windows Server 2019
|
||||
* Local Traffic Policy and DSR mode
|
||||
* Windows containers connected to l2bridge, l2tunnel, or overlay networks do not support communicating over the IPv6 stack. There is outstanding Windows platform work required to enable these network drivers to consume IPv6 addresses and subsequent Kubernetes work in kubelet, kube-proxy, and CNI plugins.
|
||||
* Outbound communication using the ICMP protocol via the win-overlay, win-bridge, and Azure-CNI plugin. Specifically, the Windows data plane ([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/)) doesn't support ICMP packet transpositions. This means:
|
||||
* ICMP packets directed to destinations within the same network (e.g. pod to pod communication via ping) work as expected and without any limitations
|
||||
* TCP/UDP packets work as expected and without any limitations
|
||||
* ICMP packets directed to pass through a remote network (e.g. pod to external internet communication via ping) cannot be transposed and thus will not be routed back to their source
|
||||
* Since TCP/UDP packets can still be transposed, one can substitute `ping <destination>` with `curl <destination>` to be able to debug connectivity to the outside world.
|
||||
|
||||
These features were added in Kubernetes v1.15:
|
||||
|
||||
* `kubectl port-forward`
|
||||
|
||||
##### CNI Plugins
|
||||
|
||||
* Windows reference network plugins win-bridge and win-overlay do not currently implement [CNI spec](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0 due to missing "CHECK" implementation.
|
||||
* The Flannel VXLAN CNI has the following limitations on Windows:
|
||||
|
||||
1. Node-pod connectivity isn't possible by design. It's only possible for local pods with Flannel [PR 1096](https://github.com/coreos/flannel/pull/1096)
|
||||
2. We are restricted to using VNI 4096 and UDP port 4789. The VNI limitation is being worked on and will be overcome in a future release (open-source flannel changes). See the official [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) backend docs for more details on these parameters.
|
||||
|
||||
##### DNS {#dns-limitations}
|
||||
|
||||
* ClusterFirstWithHostNet is not supported for DNS. Windows treats all names with a '.' as a FQDN and skips PQDN resolution
|
||||
* On Linux, you have a DNS suffix list, which is used when trying to resolve PQDNs. On Windows, we only have 1 DNS suffix, which is the DNS suffix associated with that pod's namespace (mydns.svc.cluster.local for example). Windows can resolve FQDNs and services or names resolvable with just that suffix. For example, a pod spawned in the default namespace, will have the DNS suffix **default.svc.cluster.local**. On a Windows pod, you can resolve both **kubernetes.default.svc.cluster.local** and **kubernetes**, but not the in-betweens, like **kubernetes.default** or **kubernetes.default.svc**.
|
||||
|
||||
##### Security
|
||||
|
||||
Secrets are written in clear text on the node's volume (as compared to tmpfs/in-memory on linux). This means customers have to do two things
|
||||
|
||||
1. Use file ACLs to secure the secrets file location
|
||||
2. Use volume-level encryption using [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)
|
||||
|
||||
[RunAsUser ](/ja/docs/concepts/policy/pod-security-policy/#users-and-groups)is not currently supported on Windows. The workaround is to create local accounts before packaging the container. The RunAsUsername capability may be added in a future release.
|
||||
|
||||
Linux specific pod security context privileges such as SELinux, AppArmor, Seccomp, Capabilities (POSIX Capabilities), and others are not supported.
|
||||
|
||||
In addition, as mentioned already, privileged containers are not supported on Windows.
|
||||
|
||||
#### API
|
||||
|
||||
There are no differences in how most of the Kubernetes APIs work for Windows. The subtleties around what's different come down to differences in the OS and container runtime. In certain situations, some properties on workload APIs such as Pod or Container were designed with an assumption that they are implemented on Linux, failing to run on Windows.
|
||||
|
||||
At a high level, these OS concepts are different:
|
||||
|
||||
* Identity - Linux uses userID (UID) and groupID (GID) which are represented as integer types. User and group names are not canonical - they are just an alias in `/etc/groups` or `/etc/passwd` back to UID+GID. Windows uses a larger binary security identifier (SID) which is stored in the Windows Security Access Manager (SAM) database. This database is not shared between the host and containers, or between containers.
|
||||
* File permissions - Windows uses an access control list based on SIDs, rather than a bitmask of permissions and UID+GID
|
||||
* File paths - convention on Windows is to use `\` instead of `/`. The Go IO libraries typically accept both and just make it work, but when you're setting a path or command line that's interpreted inside a container, `\` may be needed.
|
||||
* Signals - Windows interactive apps handle termination differently, and can implement one or more of these:
|
||||
* A UI thread handles well-defined messages including WM_CLOSE
|
||||
* Console apps handle ctrl-c or ctrl-break using a Control Handler
|
||||
* Services register a Service Control Handler function that can accept SERVICE_CONTROL_STOP control codes
|
||||
|
||||
Exit Codes follow the same convention where 0 is success, nonzero is failure. The specific error codes may differ across Windows and Linux. However, exit codes passed from the Kubernetes components (kubelet, kube-proxy) are unchanged.
|
||||
|
||||
##### V1.Container
|
||||
|
||||
* V1.Container.ResourceRequirements.limits.cpu and V1.Container.ResourceRequirements.limits.memory - Windows doesn't use hard limits for CPU allocations. Instead, a share system is used. The existing fields based on millicores are scaled into relative shares that are followed by the Windows scheduler. [see: kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go), [see: resource controls in Microsoft docs](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/resource-controls)
|
||||
* Huge pages are not implemented in the Windows container runtime, and are not available. They require [asserting a user privilege](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support) that's not configurable for containers.
|
||||
* V1.Container.ResourceRequirements.requests.cpu and V1.Container.ResourceRequirements.requests.memory - Requests are subtracted from node available resources, so they can be used to avoid overprovisioning a node. However, they cannot be used to guarantee resources in an overprovisioned node. They should be applied to all containers as a best practice if the operator wants to avoid overprovisioning entirely.
|
||||
* V1.Container.SecurityContext.allowPrivilegeEscalation - not possible on Windows, none of the capabilities are hooked up
|
||||
* V1.Container.SecurityContext.Capabilities - POSIX capabilities are not implemented on Windows
|
||||
* V1.Container.SecurityContext.privileged - Windows doesn't support privileged containers
|
||||
* V1.Container.SecurityContext.procMount - Windows doesn't have a /proc filesystem
|
||||
* V1.Container.SecurityContext.readOnlyRootFilesystem - not possible on Windows, write access is required for registry & system processes to run inside the container
|
||||
* V1.Container.SecurityContext.runAsGroup - not possible on Windows, no GID support
|
||||
* V1.Container.SecurityContext.runAsNonRoot - Windows does not have a root user. The closest equivalent is ContainerAdministrator which is an identity that doesn't exist on the node.
|
||||
* V1.Container.SecurityContext.runAsUser - not possible on Windows, no UID support as int.
|
||||
* V1.Container.SecurityContext.seLinuxOptions - not possible on Windows, no SELinux
|
||||
* V1.Container.terminationMessagePath - this has some limitations in that Windows doesn't support mapping single files. The default value is /dev/termination-log, which does work because it does not exist on Windows by default.
|
||||
|
||||
##### V1.Pod
|
||||
|
||||
* V1.Pod.hostIPC, v1.pod.hostpid - host namespace sharing is not possible on Windows
|
||||
* V1.Pod.hostNetwork - There is no Windows OS support to share the host network
|
||||
* V1.Pod.dnsPolicy - ClusterFirstWithHostNet - is not supported because Host Networking is not supported on Windows.
|
||||
* V1.Pod.podSecurityContext - see V1.PodSecurityContext below
|
||||
* V1.Pod.shareProcessNamespace - this is a beta feature, and depends on Linux namespaces which are not implemented on Windows. Windows cannot share process namespaces or the container's root filesystem. Only the network can be shared.
|
||||
* V1.Pod.terminationGracePeriodSeconds - this is not fully implemented in Docker on Windows, see: [reference](https://github.com/moby/moby/issues/25982). The behavior today is that the ENTRYPOINT process is sent CTRL_SHUTDOWN_EVENT, then Windows waits 5 seconds by default, and finally shuts down all processes using the normal Windows shutdown behavior. The 5 second default is actually in the Windows registry [inside the container](https://github.com/moby/moby/issues/25982#issuecomment-426441183), so it can be overridden when the container is built.
|
||||
* V1.Pod.volumeDevices - this is a beta feature, and is not implemented on Windows. Windows cannot attach raw block devices to pods.
|
||||
* V1.Pod.volumes - EmptyDir, Secret, ConfigMap, HostPath - all work and have tests in TestGrid
|
||||
* V1.emptyDirVolumeSource - the Node default medium is disk on Windows. Memory is not supported, as Windows does not have a built-in RAM disk.
|
||||
* V1.VolumeMount.mountPropagation - mount propagation is not supported on Windows.
|
||||
|
||||
##### V1.PodSecurityContext
|
||||
|
||||
None of the PodSecurityContext fields work on Windows. They're listed here for reference.
|
||||
|
||||
* V1.PodSecurityContext.SELinuxOptions - SELinux is not available on Windows
|
||||
* V1.PodSecurityContext.RunAsUser - provides a UID, not available on Windows
|
||||
* V1.PodSecurityContext.RunAsGroup - provides a GID, not available on Windows
|
||||
* V1.PodSecurityContext.RunAsNonRoot - Windows does not have a root user. The closest equivalent is ContainerAdministrator which is an identity that doesn't exist on the node.
|
||||
* V1.PodSecurityContext.SupplementalGroups - provides GID, not available on Windows
|
||||
* V1.PodSecurityContext.Sysctls - these are part of the Linux sysctl interface. There's no equivalent on Windows.
|
||||
|
||||
## Getting Help and Troubleshooting {#troubleshooting}
|
||||
|
||||
Your main source of help for troubleshooting your Kubernetes cluster should start with this [section](/ja/docs/tasks/debug-application-cluster/troubleshooting/). Some additional, Windows-specific troubleshooting help is included in this section. Logs are an important element of troubleshooting issues in Kubernetes. Make sure to include them any time you seek troubleshooting assistance from other contributors. Follow the instructions in the SIG-Windows [contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs).
|
||||
|
||||
1. How do I know start.ps1 completed successfully?
|
||||
|
||||
You should see kubelet, kube-proxy, and (if you chose Flannel as your networking solution) flanneld host-agent processes running on your node, with running logs being displayed in separate PowerShell windows. In addition to this, your Windows node should be listed as "Ready" in your Kubernetes cluster.
|
||||
|
||||
1. Can I configure the Kubernetes node processes to run in the background as services?
|
||||
|
||||
Kubelet and kube-proxy are already configured to run as native Windows Services, offering resiliency by re-starting the services automatically in the event of failure (for example a process crash). You have two options for configuring these node components as services.
|
||||
|
||||
1. As native Windows Services
|
||||
|
||||
Kubelet & kube-proxy can be run as native Windows Services using `sc.exe`.
|
||||
|
||||
```powershell
|
||||
# Create the services for kubelet and kube-proxy in two separate commands
|
||||
sc.exe create <component_name> binPath= "<path_to_binary> --service <other_args>"
|
||||
|
||||
# Please note that if the arguments contain spaces, they must be escaped.
|
||||
sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' <other_args>"
|
||||
|
||||
# Start the services
|
||||
Start-Service kubelet
|
||||
Start-Service kube-proxy
|
||||
|
||||
# Stop the service
|
||||
Stop-Service kubelet (-Force)
|
||||
Stop-Service kube-proxy (-Force)
|
||||
|
||||
# Query the service status
|
||||
Get-Service kubelet
|
||||
Get-Service kube-proxy
|
||||
```
|
||||
|
||||
1. Using nssm.exe
|
||||
|
||||
You can also always use alternative service managers like [nssm.exe](https://nssm.cc/) to run these processes (flanneld, kubelet & kube-proxy) in the background for you. You can use this [sample script](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1), leveraging nssm.exe to register kubelet, kube-proxy, and flanneld.exe to run as Windows services in the background.
|
||||
|
||||
```powershell
|
||||
register-svc.ps1 -NetworkMode <Network mode> -ManagementIP <Windows Node IP> -ClusterCIDR <Cluster subnet> -KubeDnsServiceIP <Kube-dns Service IP> -LogDir <Directory to place logs>
|
||||
|
||||
# NetworkMode = The network mode l2bridge (flannel host-gw, also the default value) or overlay (flannel vxlan) chosen as a network solution
|
||||
# ManagementIP = The IP address assigned to the Windows node. You can use ipconfig to find this
|
||||
# ClusterCIDR = The cluster subnet range. (Default value 10.244.0.0/16)
|
||||
# KubeDnsServiceIP = The Kubernetes DNS service IP (Default value 10.96.0.10)
|
||||
# LogDir = The directory where kubelet and kube-proxy logs are redirected into their respective output files (Default value C:\k)
|
||||
```
|
||||
|
||||
If the above referenced script is not suitable, you can manually configure nssm.exe using the following examples.
|
||||
```powershell
|
||||
# Register flanneld.exe
|
||||
nssm install flanneld C:\flannel\flanneld.exe
|
||||
nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface=<ManagementIP> --ip-masq=1 --kube-subnet-mgr=1
|
||||
nssm set flanneld AppEnvironmentExtra NODE_NAME=<hostname>
|
||||
nssm set flanneld AppDirectory C:\flannel
|
||||
nssm start flanneld
|
||||
|
||||
# Register kubelet.exe
|
||||
# Microsoft releases the pause infrastructure container at mcr.microsoft.com/k8s/core/pause:1.2.0
|
||||
# For more info search for "pause" in the "Guide for adding Windows Nodes in Kubernetes"
|
||||
nssm install kubelet C:\k\kubelet.exe
|
||||
nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=mcr.microsoft.com/k8s/core/pause:1.2.0 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
|
||||
nssm set kubelet AppDirectory C:\k
|
||||
nssm start kubelet
|
||||
|
||||
# Register kube-proxy.exe (l2bridge / host-gw)
|
||||
nssm install kube-proxy C:\k\kube-proxy.exe
|
||||
nssm set kube-proxy AppDirectory c:\k
|
||||
nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=<hostname>--kubeconfig=c:\k\config --enable-dsr=false --log-dir=<log directory> --logtostderr=false
|
||||
nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0
|
||||
nssm set kube-proxy DependOnService kubelet
|
||||
nssm start kube-proxy
|
||||
|
||||
# Register kube-proxy.exe (overlay / vxlan)
|
||||
nssm install kube-proxy C:\k\kube-proxy.exe
|
||||
nssm set kube-proxy AppDirectory c:\k
|
||||
nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override=<hostname> --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip=<source-vip> --enable-dsr=false --log-dir=<log directory> --logtostderr=false
|
||||
nssm set kube-proxy DependOnService kubelet
|
||||
nssm start kube-proxy
|
||||
```
|
||||
|
||||
|
||||
For initial troubleshooting, you can use the following flags in [nssm.exe](https://nssm.cc/) to redirect stdout and stderr to a output file:
|
||||
|
||||
```powershell
|
||||
nssm set <Service Name> AppStdout C:\k\mysvc.log
|
||||
nssm set <Service Name> AppStderr C:\k\mysvc.log
|
||||
```
|
||||
|
||||
For additional details, see official [nssm usage](https://nssm.cc/usage) docs.
|
||||
|
||||
1. My Windows Pods do not have network connectivity
|
||||
|
||||
If you are using virtual machines, ensure that MAC spoofing is enabled on all the VM network adapter(s).
|
||||
|
||||
1. My Windows Pods cannot ping external resources
|
||||
|
||||
Windows Pods do not have outbound rules programmed for the ICMP protocol today. However, TCP/UDP is supported. When trying to demonstrate connectivity to resources outside of the cluster, please substitute `ping <IP>` with corresponding `curl <IP>` commands.
|
||||
|
||||
If you are still facing problems, most likely your network configuration in [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf) deserves some extra attention. You can always edit this static file. The configuration update will apply to any newly created Kubernetes resources.
|
||||
|
||||
One of the Kubernetes networking requirements (see [Kubernetes model](/ja/docs/concepts/cluster-administration/networking/)) is for cluster communication to occur without NAT internally. To honor this requirement, there is an [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20) for all the communication where we do not want outbound NAT to occur. However, this also means that you need to exclude the external IP you are trying to query from the ExceptionList. Only then will the traffic originating from your Windows pods be SNAT'ed correctly to receive a response from the outside world. In this regard, your ExceptionList in `cni.conf` should look as follows:
|
||||
|
||||
```conf
|
||||
"ExceptionList": [
|
||||
"10.244.0.0/16", # Cluster subnet
|
||||
"10.96.0.0/12", # Service subnet
|
||||
"10.127.130.0/24" # Management (host) subnet
|
||||
]
|
||||
```
|
||||
|
||||
1. My Windows node cannot access NodePort service
|
||||
|
||||
Local NodePort access from the node itself fails. This is a known limitation. NodePort access works from other nodes or external clients.
|
||||
|
||||
1. vNICs and HNS endpoints of containers are being deleted
|
||||
|
||||
This issue can be caused when the `hostname-override` parameter is not passed to [kube-proxy](/ja/docs/reference/command-line-tools-reference/kube-proxy/). To resolve it, users need to pass the hostname to kube-proxy as follows:
|
||||
|
||||
```powershell
|
||||
C:\k\kube-proxy.exe --hostname-override=$(hostname)
|
||||
```
|
||||
|
||||
1. With flannel my nodes are having issues after rejoining a cluster
|
||||
|
||||
Whenever a previously deleted node is being re-joined to the cluster, flannelD tries to assign a new pod subnet to the node. Users should remove the old pod subnet configuration files in the following paths:
|
||||
|
||||
```powershell
|
||||
Remove-Item C:\k\SourceVip.json
|
||||
Remove-Item C:\k\SourceVipRequest.json
|
||||
```
|
||||
|
||||
1. After launching `start.ps1`, flanneld is stuck in "Waiting for the Network to be created"
|
||||
|
||||
There are numerous reports of this [issue which are being investigated](https://github.com/coreos/flannel/issues/1066); most likely it is a timing issue for when the management IP of the flannel network is set. A workaround is to simply relaunch start.ps1 or relaunch it manually as follows:
|
||||
|
||||
```powershell
|
||||
PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
|
||||
PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1
|
||||
```
|
||||
|
||||
1. My Windows Pods cannot launch because of missing `/run/flannel/subnet.env`
|
||||
|
||||
This indicates that Flannel didn't launch correctly. You can either try to restart flanneld.exe or you can copy the files over manually from `/run/flannel/subnet.env` on the Kubernetes master to` C:\run\flannel\subnet.env` on the Windows worker node and modify the `FLANNEL_SUBNET` row to a different number. For example, if node subnet 10.244.4.1/24 is desired:
|
||||
|
||||
```env
|
||||
FLANNEL_NETWORK=10.244.0.0/16
|
||||
FLANNEL_SUBNET=10.244.4.1/24
|
||||
FLANNEL_MTU=1500
|
||||
FLANNEL_IPMASQ=true
|
||||
```
|
||||
|
||||
1. My Windows node cannot access my services using the service IP
|
||||
|
||||
This is a known limitation of the current networking stack on Windows. Windows Pods are able to access the service IP however.
|
||||
|
||||
1. No network adapter is found when starting kubelet
|
||||
|
||||
The Windows networking stack needs a virtual adapter for Kubernetes networking to work. If the following commands return no results (in an admin shell), virtual network creation — a necessary prerequisite for Kubelet to work — has failed:
|
||||
|
||||
```powershell
|
||||
Get-HnsNetwork | ? Name -ieq "cbr0"
|
||||
Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
|
||||
```
|
||||
|
||||
Often it is worthwhile to modify the [InterfaceName](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/start.ps1#L6) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation.
|
||||
|
||||
1. My Pods are stuck at "Container Creating" or restarting over and over
|
||||
|
||||
Check that your pause image is compatible with your OS version. The [instructions](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources) assume that both the OS and the containers are version 1803. If you have a later version of Windows, such as an Insider build, you need to adjust the images accordingly. Please refer to the Microsoft's [Docker repository](https://hub.docker.com/u/microsoft/) for images. Regardless, both the pause image Dockerfile and the sample service expect the image to be tagged as :latest.
|
||||
|
||||
Starting with Kubernetes v1.14, Microsoft releases the pause infrastructure container at `mcr.microsoft.com/k8s/core/pause:1.2.0`. For more information search for "pause" in the [Guide for adding Windows Nodes in Kubernetes](../user-guide-windows-nodes).
|
||||
|
||||
1. DNS resolution is not properly working
|
||||
|
||||
Check the DNS limitations for Windows in this [section](#dns-limitations).
|
||||
|
||||
1. `kubectl port-forward` fails with "unable to do port forwarding: wincat not found"
|
||||
|
||||
This was implemented in Kubernetes 1.15, and the pause infrastructure container `mcr.microsoft.com/k8s/core/pause:1.2.0`. Be sure to use these versions or newer ones.
|
||||
If you would like to build your own pause infrastructure container, be sure to include [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)
|
||||
|
||||
### Further investigation
|
||||
|
||||
If these steps don't resolve your problem, you can get help running Windows containers on Windows nodes in Kubernetes through:
|
||||
|
||||
* StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container) topic
|
||||
* Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io/)
|
||||
* Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows)
|
||||
|
||||
## Reporting Issues and Feature Requests
|
||||
|
||||
If you have what looks like a bug, or you would like to make a feature request, please use the [GitHub issue tracking system](https://github.com/kubernetes/kubernetes/issues). You can open issues on [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) and assign them to SIG-Windows. You should first search the list of issues in case it was reported previously and comment with your experience on the issue and add additional logs. SIG-Windows Slack is also a great avenue to get some initial support and troubleshooting ideas prior to creating a ticket.
|
||||
|
||||
If filing a bug, please include detailed information about how to reproduce the problem, such as:
|
||||
|
||||
* Kubernetes version: kubectl version
|
||||
* Environment details: Cloud provider, OS distro, networking choice and configuration, and Docker version
|
||||
* Detailed steps to reproduce the problem
|
||||
* [Relevant logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)
|
||||
* Tag the issue sig/windows by commenting on the issue with `/sig windows` to bring it to a SIG-Windows member's attention
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
We have a lot of features in our roadmap. An abbreviated high level list is included below, but we encourage you to view our [roadmap project](https://github.com/orgs/kubernetes/projects/8) and help us make Windows support better by [contributing](https://github.com/kubernetes/community/blob/master/sig-windows/).
|
||||
|
||||
### CRI-ContainerD
|
||||
|
||||
{{< glossary_tooltip term_id="containerd" >}} is another OCI-compliant runtime that recently graduated as a {{< glossary_tooltip text="CNCF" term_id="cncf" >}} project. It's currently tested on Linux, but 1.3 will bring support for Windows and Hyper-V. [[reference](https://blog.docker.com/2019/02/containerd-graduates-within-the-cncf/)]
|
||||
|
||||
The CRI-ContainerD interface will be able to manage sandboxes based on Hyper-V. This provides a foundation where RuntimeClass could be implemented for new use cases including:
|
||||
|
||||
* Hypervisor-based isolation between pods for additional security
|
||||
* Backwards compatibility allowing a node to run a newer Windows Server version without requiring containers to be rebuilt
|
||||
* Specific CPU/NUMA settings for a pod
|
||||
* Memory isolation and reservations
|
||||
|
||||
### Hyper-V isolation
|
||||
|
||||
The existing Hyper-V isolation support, an experimental feature as of v1.10, will be deprecated in the future in favor of the CRI-ContainerD and RuntimeClass features mentioned above. To use the current features and create a Hyper-V isolated container, the kubelet should be started with feature gates `HyperVContainer=true` and the Pod should include the annotation `experimental.windows.kubernetes.io/isolation-type=hyperv`. In the experiemental release, this feature is limited to 1 container per Pod.
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: iis
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: iis
|
||||
replicas: 3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: iis
|
||||
annotations:
|
||||
experimental.windows.kubernetes.io/isolation-type: hyperv
|
||||
spec:
|
||||
containers:
|
||||
- name: iis
|
||||
image: microsoft/iis
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
### Deployment with kubeadm and cluster API
|
||||
|
||||
Kubeadm is becoming the de facto standard for users to deploy a Kubernetes cluster. Windows node support in kubeadm will come in a future release. We are also making investments in cluster API to ensure Windows nodes are properly provisioned.
|
||||
|
||||
### A few other key features
|
||||
* Beta support for Group Managed Service Accounts
|
||||
* More CNIs
|
||||
* More Storage Plugins
|
||||
|
||||
{{% /capture %}}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user