diff --git a/Makefile b/Makefile index be53b5eac9..20691ff76b 100644 --- a/Makefile +++ b/Makefile @@ -4,7 +4,7 @@ NETLIFY_FUNC = $(NODE_BIN)/netlify-lambda # The CONTAINER_ENGINE variable is used for specifying the container engine. By default 'docker' is used # but this can be overridden when calling make, e.g. -# CONTAINER_ENGINE=podman make container-image +# CONTAINER_ENGINE=podman make container-image CONTAINER_ENGINE ?= docker CONTAINER_IMAGE = kubernetes-hugo CONTAINER_RUN = $(CONTAINER_ENGINE) run --rm --interactive --tty --volume $(CURDIR):/src @@ -17,12 +17,15 @@ CCEND=\033[0m help: ## Show this help. @awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST) +module-check: + @git submodule status --recursive | awk '/^[+-]/ {printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2}' 1>&2 + all: build ## Build site with production settings and put deliverables in ./public -build: ## Build site with production settings and put deliverables in ./public +build: module-check ## Build site with production settings and put deliverables in ./public hugo --minify -build-preview: ## Build site with drafts and future posts enabled +build-preview: module-check ## Build site with drafts and future posts enabled hugo --buildDrafts --buildFuture deploy-preview: ## Deploy preview site via netlify @@ -39,7 +42,7 @@ production-build: build check-headers-file ## Build the production site and ensu non-production-build: ## Build the non-production site, which adds noindex headers to prevent indexing hugo --enableGitInfo -serve: ## Boot the development server. +serve: module-check ## Boot the development server. hugo server --buildFuture docker-image: @@ -60,10 +63,10 @@ container-image: --tag $(CONTAINER_IMAGE) \ --build-arg HUGO_VERSION=$(HUGO_VERSION) -container-build: +container-build: module-check $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo -container-serve: +container-serve: module-check $(CONTAINER_RUN) --mount type=tmpfs,destination=/src/resources,tmpfs-mode=0755 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 test-examples: @@ -81,4 +84,3 @@ docker-internal-linkcheck: container-internal-linkcheck: link-checker-image-pull $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture $(CONTAINER_ENGINE) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest - diff --git a/README-de.md b/README-de.md index 76087f403e..bf647d828f 100644 --- a/README-de.md +++ b/README-de.md @@ -15,7 +15,7 @@ Weitere Informationen zum Beitrag zur Kubernetes-Dokumentation finden Sie unter: * [Mitwirkung beginnen](https://kubernetes.io/docs/contribute/start/) * [Ihre Dokumentationsänderungen bereitstellen](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) -* [Seitenvorlagen verwenden](http://kubernetes.io/docs/contribute/style/page-templates/) +* [Seitenvorlagen verwenden](http://kubernetes.io/docs/contribute/style/page-content-types/) * [Dokumentationsstil-Handbuch](http://kubernetes.io/docs/contribute/style/style-guide/) * [Übersetzung der Kubernetes-Dokumentation](https://kubernetes.io/docs/contribute/localization/) diff --git a/README-es.md b/README-es.md index fe71a0fc40..ba2f13a80f 100644 --- a/README-es.md +++ b/README-es.md @@ -18,7 +18,7 @@ Para obtener más información sobre cómo contribuir a la documentación de Kub * [Empezando a contribuir](https://kubernetes.io/docs/contribute/start/) * [Visualizando sus cambios en su entorno local](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) -* [Utilizando las plantillas de las páginas](http://kubernetes.io/docs/contribute/style/page-templates/) +* [Utilizando las plantillas de las páginas](http://kubernetes.io/docs/contribute/style/page-content-types/) * [Guía de estilo de la documentación](http://kubernetes.io/docs/contribute/style/style-guide/) * [Traduciendo la documentación de Kubernetes](https://kubernetes.io/docs/contribute/localization/) diff --git a/README-fr.md b/README-fr.md index 37350a5b81..b493ea60f0 100644 --- a/README-fr.md +++ b/README-fr.md @@ -23,7 +23,7 @@ Pour plus d'informations sur la contribution à la documentation Kubernetes, voi * [Commencez à contribuer](https://kubernetes.io/docs/contribute/start/) * [Apperçu des modifications apportées à votre documentation](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) -* [Utilisation des modèles de page](http://kubernetes.io/docs/contribute/style/page-templates/) +* [Utilisation des modèles de page](https://kubernetes.io/docs/contribute/style/page-content-types/) * [Documentation Style Guide](http://kubernetes.io/docs/contribute/style/style-guide/) * [Traduction de la documentation Kubernetes](https://kubernetes.io/docs/contribute/localization/) diff --git a/README-ja.md b/README-ja.md index 2c69491e2f..3bc4fcd27a 100644 --- a/README-ja.md +++ b/README-ja.md @@ -3,7 +3,31 @@ [![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) -ようこそ！このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！ +このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！ + +## Hugoを使ってローカル環境でWebサイトを動かす + +Hugoのインストール方法については[Hugoの公式ドキュメント](https://gohugo.io/getting-started/installing/)をご覧ください。このとき、[`netlify.toml`](netlify.toml#L10)ファイルに記述されている`HUGO_VERSION`と同じバージョンをインストールするようにしてください。 + +Hugoがインストールできたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます: + +```bash +git clone https://github.com/kubernetes/website.git +cd website +git submodule update --init --recursive +hugo server --buildFuture +``` + +これで、Hugoのサーバーが1313番ポートを使って開始します。お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。 + +## SIG Docsに参加する + +[コミュニティのページ](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)をご覧になることで、SIG Docs Kubernetesコミュニティとの関わり方を学ぶことができます。 + +本プロジェクトのメンテナーには以下の方法で連絡することができます: + +- [Slack](https://kubernetes.slack.com/messages/kubernetes-docs-ja) +- [メーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) ## ドキュメントに貢献する @@ -12,63 +36,31 @@ GitHubの画面右上にある**Fork**ボタンをクリックすると、お使 Pull Requestが作成されると、レビュー担当者が責任を持って明確かつ実用的なフィードバックを返します。 Pull Requestの所有者は作成者であるため、**ご自身で作成したPull Requestを編集し、フィードバックに対応するのはご自身の役目です。** また、状況によっては2人以上のレビュアーからフィードバックが返されたり、アサインされていないレビュー担当者からのフィードバックが来ることがある点もご注意ください。 -さらに、特定のケースにおいては、レビュー担当者が[Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers)に対してレビューを依頼することもあります。 +さらに、特定のケースにおいては、レビュー担当者がKubernetesの技術的なレビュアーに対してレビューを依頼することもあります。 レビュー担当者はタイムリーにフィードバックを提供するために最善を尽くしますが、応答時間は状況に応じて異なる場合があります。 Kubernetesのドキュメントへの貢献に関する詳細については以下のページをご覧ください: -* [貢献のはじめ方](https://kubernetes.io/docs/contribute/start/) -* [ドキュメントの変更をステージする](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) -* [ページテンプレートの使い方](http://kubernetes.io/docs/contribute/style/page-templates/) -* [ドキュメントのスタイルガイド](http://kubernetes.io/docs/contribute/style/style-guide/) +* [Kubernetesのドキュメントへの貢献](https://kubernetes.io/ja/docs/contribute/) +* [ページコンテントタイプ](https://kubernetes.io/docs/contribute/style/page-content-types/) +* [ドキュメントのスタイルガイド](https://kubernetes.io/docs/contribute/style/style-guide/) * [Kubernetesドキュメントの翻訳方法](https://kubernetes.io/docs/contribute/localization/) -## Dockerを使ってローカル環境でWebサイトを動かす +## 翻訳された`README.md`一覧 -ローカル環境で本ページを動かすのに推奨される方法は、静的サイトジェネレータの[Hugo](https://gohugo.io)を動かすのに特化した[Docker](https://docker.com)イメージを使うことです。 - -> Windows上で環境を作る場合は[Chocolatey](https://chocolatey.org)を使ってインストール可能な追加のツールが必要になります。 `choco install make` - -> Dockerを使わずに環境を構築したい場合は、[Hugoをローカル環境で動かす](#hugoをローカル環境で動かす)をご覧ください。 - -既に[Dockerが動いている環境](https://www.docker.com/get-started)であれば、以下のコマンドを使って`kubernetes-hugo`イメージをローカルでビルドします: - -```bash -make docker-image -``` - -イメージが作成されたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます: - -```bash -make docker-serve -``` - -お使いのブラウザにて http://localhost:1313 にアクセスすることでWebサイトが開きます。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。 - -## Hugoをローカル環境で動かす - -Hugoのインストール方法については[Hugoの公式ドキュメント](https://gohugo.io/getting-started/installing/)をご覧ください。このとき、[`netlify.toml`](netlify.toml#L9)ファイルに記述されている`HUGO_VERSION`と同じバージョンをインストールするようにしてください。 - -Hugoがインストールできたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます: - -```bash -make serve -``` - -これで、Hugoのサーバーが1313番ポートを使って開始します。 お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。 - -## コミュニティ内での議論、貢献、サポートなどについて - -[コミュニティのページ](http://kubernetes.io/community/)をご覧になることで、Kubernetesコミュニティとの関わり方を学ぶことができます。 - -本プロジェクトのメンテナーには以下の方法で連絡することができます: - -- [Slack](https://kubernetes.slack.com/messages/kubernetes-docs-ja) -- [メーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) +| Language | Language | +|---|---| +|[中国語](README-zh.md)|[韓国語](README-ko.md)| +|[フランス語](README-fr.md)|[ポーランド語](README-pl.md)| +|[ドイツ語](README-de.md)|[ポルトガル語](README-pt.md)| +|[ヒンディー語](README-hi.md)|[ロシア語](README-ru.md)| +|[インドネシア語](README-id.md)|[スペイン語](README-es.md)| +|[イタリア語](README-it.md)|[ウクライナ語](README-uk.md)| +|[日本語](README-ja.md)|[ベトナム語](README-vi.md)| ### 行動規範 -Kubernetesコミュニティへの参加については、[Kubernetesの行動規範](code-of-conduct.md)によって管理されています。 +Kubernetesコミュニティへの参加については、[CNCFの行動規範](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)によって管理されています。 ## ありがとうございます！ diff --git a/README.md b/README.md index 7ef8f8d2dd..4c631b0dc8 100644 --- a/README.md +++ b/README.md @@ -41,7 +41,7 @@ Furthermore, in some cases, one of your reviewers might ask for a technical revi For more information about contributing to the Kubernetes documentation, see: * [Contribute to Kubernetes docs](https://kubernetes.io/docs/contribute/) -* [Using Page Templates](https://kubernetes.io/docs/contribute/style/page-templates/) +* [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/) * [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/) * [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/) diff --git a/assets/scss/_base.scss b/assets/scss/_base.scss index ddfee42444..fab7dd4e7e 100644 --- a/assets/scss/_base.scss +++ b/assets/scss/_base.scss @@ -65,8 +65,8 @@ footer { .button { display: inline-block; border-radius: 6px; - padding: 0 20px; - line-height: 40px; + padding: 6px 20px; + line-height: 1.3rem; color: white; background-color: $blue; text-decoration: none; diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss index 52364b0a8a..f02d6d908b 100644 --- a/assets/scss/_custom.scss +++ b/assets/scss/_custom.scss @@ -299,12 +299,19 @@ blockquote { } } +.td-sidebar-nav { + & > .td-sidebar-nav__section { + padding-top: .5rem; + padding-left: 1.5rem; + } +} + .td-sidebar__inner { form.td-sidebar__search { button.td-sidebar__toggle { &:hover { - color: $white; + color: #000000; } color: $blue; diff --git a/config.toml b/config.toml index 34aa9d756d..d719b7854e 100644 --- a/config.toml +++ b/config.toml @@ -238,7 +238,7 @@ no = 'Sorry to hear that. Please - -## Overview - -To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state. - -Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster: - -* The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/). -* Each individual non-master node in your cluster runs two processes: - * **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master. - * **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node. - -## Kubernetes objects - -Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) for more details. - -The basic Kubernetes objects include: - -* [Pod](/docs/concepts/workloads/pods/pod-overview/) -* [Service](/docs/concepts/services-networking/service/) -* [Volume](/docs/concepts/storage/volumes/) -* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/) - -Kubernetes also contains higher-level abstractions that rely on [controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include: - -* [Deployment](/docs/concepts/workloads/controllers/deployment/) -* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) -* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) -* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) -* [Job](/docs/concepts/workloads/controllers/job/) - -## Kubernetes Control Plane - -The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided. - -For example, when you use the Kubernetes API to create a Deployment, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state. - -### Kubernetes Master - -The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master. - -> The "master" refers to a collection of processes managing the cluster state. Typically all these processes run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy. - -### Kubernetes Nodes - -The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly. - - - - -## {{% heading "whatsnext" %}} - - -If you would like to write a concept page, see -[Page Content Types](/docs/home/contribute/style/page-content-types/#concept) -for information about the concept page types. - - diff --git a/content/en/docs/concepts/architecture/_index.md b/content/en/docs/concepts/architecture/_index.md index 3a17d1b08e..61fb48e714 100755 --- a/content/en/docs/concepts/architecture/_index.md +++ b/content/en/docs/concepts/architecture/_index.md @@ -1,5 +1,7 @@ --- title: "Cluster Architecture" weight: 30 +description: > + The architectural concepts behind Kubernetes. --- diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md old mode 100755 new mode 100644 index 72af40feec..7ce7126d9d --- a/content/en/docs/concepts/cluster-administration/_index.md +++ b/content/en/docs/concepts/cluster-administration/_index.md @@ -1,5 +1,74 @@ --- -title: "Cluster Administration" +title: Cluster Administration +reviewers: +- davidopp +- lavalamp weight: 100 +content_type: concept +description: > + Lower-level detail relevant to creating or administering a Kubernetes cluster. --- + +The cluster administration overview is for anyone creating or administering a Kubernetes cluster. +It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/). + + + +## Planning a cluster + +See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*. + + {{< note >}} + Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes. + {{< /note >}} + +Before choosing a guide, here are some considerations: + + - Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs. + - Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**? + - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters. + - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best. + - Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**? + - Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the + latter, choose an actively-developed distro. Some distros only use binary releases, but + offer a greater variety of choices. + - Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster. + + +## Managing a cluster + +* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster. + +* Learn how to [manage nodes](/docs/concepts/nodes/node/). + +* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters. + +## Securing a cluster + +* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains. + +* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node. + +* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts. + +* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options. + +* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled. + +* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization. + +* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters . + +* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs. + +### Securing the kubelet + * [Master-Node communication](/docs/concepts/architecture/master-node-communication/) + * [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) + * [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/) + +## Optional Cluster Services + +* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service. + +* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it. diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md index 4f49e7bc42..8526ac830e 100644 --- a/content/en/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/en/docs/concepts/cluster-administration/cloud-providers.md @@ -99,7 +99,7 @@ Different settings can be applied to a load balancer service in AWS using _annot * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout. * `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout. * `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: Used on the service to enable or disable cross-zone load balancing. -* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB. +* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB. Security groups defined here should not be shared between services. * `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: Used on the service to specify additional security groups to be added to ELB created * `service.beta.kubernetes.io/aws-load-balancer-internal`: Used on the service to indicate that we want an internal ELB. * `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: Used on the service to enable the proxy protocol on an ELB. Right now we only accept the value `*` which means enabling the proxy protocol on all ELB backends. In the future we could adjust this to allow setting the proxy protocol only on certain backends. @@ -433,4 +433,4 @@ Alibaba Cloud does not require the format of node name, but the kubelet needs to ### Load Balancers -You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) . \ No newline at end of file +You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) . diff --git a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md deleted file mode 100644 index fc2f55fbcd..0000000000 --- a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -reviewers: -- davidopp -- lavalamp -title: Cluster Administration Overview -content_type: concept -weight: 10 ---- - - -The cluster administration overview is for anyone creating or administering a Kubernetes cluster. -It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/). - - - -## Planning a cluster - -See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*. - -Before choosing a guide, here are some considerations: - - - Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs. - - Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**? - - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters. - - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best. - - Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**? - - Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the - latter, choose an actively-developed distro. Some distros only use binary releases, but - offer a greater variety of choices. - - Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster. - -Note: Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes. - -## Managing a cluster - -* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster. - -* Learn how to [manage nodes](/docs/concepts/nodes/node/). - -* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters. - -## Securing a cluster - -* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains. - -* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node. - -* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts. - -* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options. - -* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled. - -* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization. - -* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters . - -* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs. - -### Securing the kubelet - * [Master-Node communication](/docs/concepts/architecture/master-node-communication/) - * [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - * [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/) - -## Optional Cluster Services - -* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service. - -* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it. - - - - diff --git a/content/en/docs/concepts/configuration/_index.md b/content/en/docs/concepts/configuration/_index.md index 1635c2a5bf..2ed10d601d 100755 --- a/content/en/docs/concepts/configuration/_index.md +++ b/content/en/docs/concepts/configuration/_index.md @@ -1,5 +1,7 @@ --- title: "Configuration" weight: 80 +description: > + Resources that Kubernetes provides for configuring Pods. --- diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md index 9d9a80a9b3..f4f7f6ab3a 100644 --- a/content/en/docs/concepts/configuration/configmap.md +++ b/content/en/docs/concepts/configuration/configmap.md @@ -60,7 +60,7 @@ metadata: name: game-demo data: # property-like keys; each key maps to a simple value - player_initial_lives: 3 + player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" # # file-like keys @@ -131,7 +131,7 @@ spec: A ConfigMap doesn't differentiate between single line property values and multi-line file-like values. -What matters how Pods and other objects consume those values. +What matters is how Pods and other objects consume those values. For this example, defining a volume and mounting it inside the `demo` container as `/config` creates four files: @@ -168,7 +168,7 @@ ConfigMaps can hold data that other parts of the system should use for configura To consume a ConfigMap in a volume in a Pod: 1. Create a config map or use an existing one. Multiple Pods can reference the same config map. -1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].configmap.localObjectReference` field set to reference your ConfigMap object. +1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].configMap.name` field set to reference your ConfigMap object. 1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the config map. Specify `.spec.containers[].volumeMounts[].readOnly = true` and `.spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the config map to appear. 1. Modify your image or command line so that the program looks for files in that directory. Each key in the config map `data` map becomes the filename under `mountPath`. diff --git a/content/en/docs/concepts/configuration/overview.md b/content/en/docs/concepts/configuration/overview.md index 332bdebe28..744034f8ea 100644 --- a/content/en/docs/concepts/configuration/overview.md +++ b/content/en/docs/concepts/configuration/overview.md @@ -103,7 +103,7 @@ The caching semantics of the underlying image provider make even `imagePullPolic - Use label selectors for `get` and `delete` operations instead of specific object names. See the sections on [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively). -- Use `kubectl run` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example. +- Use `kubectl create deployment` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example. diff --git a/content/en/docs/concepts/containers/_index.md b/content/en/docs/concepts/containers/_index.md old mode 100755 new mode 100644 index ad442f3ab3..091cea881b --- a/content/en/docs/concepts/containers/_index.md +++ b/content/en/docs/concepts/containers/_index.md @@ -1,5 +1,44 @@ --- -title: "Containers" +title: Containers weight: 40 +description: Technology for packaging an application along with its runtime dependencies. +reviewers: +- erictune +- thockin +content_type: concept --- + + +Each container that you run is repeatable; the standardization from having +dependencies included means that you get the same behavior wherever you +run it. + +Containers decouple applications from underlying host infrastructure. +This makes deployment easier in different cloud or OS environments. + + + + + + +## Container images +A [container image](/docs/concepts/containers/images/) is a ready-to-run +software package, containing everything needed to run an application: +the code and any runtime it requires, application and system libraries, +and default values for any essential settings. + +By design, a container is immutable: you cannot change the code of a +container that is already running. If you have a containerized application +and want to make changes, you need to build a new container that includes +the change, then recreate the container to start from the updated image. + +## Container runtimes + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +## {{% heading "whatsnext" %}} + +* Read about [container images](/docs/concepts/containers/images/) +* Read about [Pods](/docs/concepts/workloads/pods/) + diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md index b271c36d02..496387a43a 100644 --- a/content/en/docs/concepts/containers/images.md +++ b/content/en/docs/concepts/containers/images.md @@ -10,7 +10,7 @@ weight: 10 A container image represents binary data that encapsulates an application and all its -software depencies. Container images are executable software bundles that can run +software dependencies. Container images are executable software bundles that can run standalone and that make very well defined assumptions about their runtime environment. You typically create a container image of your application and push it to a registry @@ -61,6 +61,8 @@ you can do one of the following: - omit the `imagePullPolicy` and the tag for the image to use. - enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller. +When `imagePullPolicy` is defined without a specific value, it is also set to `Always`. + ## Multi-architecture Images with Manifests As well as providing binary images, a container registry can also server a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using. @@ -89,7 +91,7 @@ These options are explaind in more detail below. ### Configuring Nodes to authenticate to a Private Registry If you run Docker on your nodes, you can configure the Docker container -runtuime to authenticate to a private container registry. +runtime to authenticate to a private container registry. This approach is suitable if you can control node configuration. diff --git a/content/en/docs/concepts/containers/overview.md b/content/en/docs/concepts/containers/overview.md deleted file mode 100644 index 1d996b8b93..0000000000 --- a/content/en/docs/concepts/containers/overview.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -reviewers: -- erictune -- thockin -title: Containers overview -content_type: concept -weight: 1 ---- - - - -Containers are a technology for packaging the (compiled) code for an -application along with the dependencies it needs at run time. Each -container that you run is repeatable; the standardization from having -dependencies included means that you get the same behavior wherever you -run it. - -Containers decouple applications from underlying host infrastructure. -This makes deployment easier in different cloud or OS environments. - - - - - - -## Container images -A [container image](/docs/concepts/containers/images/) is a ready-to-run -software package, containing everything needed to run an application: -the code and any runtime it requires, application and system libraries, -and default values for any essential settings. - -By design, a container is immutable: you cannot change the code of a -container that is already running. If you have a containerized application -and want to make changes, you need to build a new container that includes -the change, then recreate the container to start from the updated image. - -## Container runtimes - -{{< glossary_definition term_id="container-runtime" length="all" >}} - - -## {{% heading "whatsnext" %}} - -* Read about [container images](/docs/concepts/containers/images/) -* Read about [Pods](/docs/concepts/workloads/pods/) - diff --git a/content/en/docs/concepts/extend-kubernetes/_index.md b/content/en/docs/concepts/extend-kubernetes/_index.md index 93d955441d..934861904f 100644 --- a/content/en/docs/concepts/extend-kubernetes/_index.md +++ b/content/en/docs/concepts/extend-kubernetes/_index.md @@ -1,4 +1,212 @@ --- title: Extending Kubernetes weight: 110 +description: Different ways to change the behavior of your Kubernetes cluster. +reviewers: +- erictune +- lavalamp +- cheftako +- chenopis +content_type: concept --- + + + +Kubernetes is highly configurable and extensible. As a result, +there is rarely a need to fork or submit patches to the Kubernetes +project code. + +This guide describes the options for customizing a Kubernetes +cluster. It is aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to +understand how to adapt their Kubernetes cluster to the needs of +their work environment. Developers who are prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also find it +useful as an introduction to what extension points and patterns +exist, and their trade-offs and limitations. + + + + + + +## Overview + +Customization approaches can be broadly divided into *configuration*, which only involves changing flags, local configuration files, or API resources; and *extensions*, which involve running additional programs or services. This document is primarily about extensions. + +## Configuration + +*Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary: + +* [kubelet](/docs/admin/kubelet/) +* [kube-apiserver](/docs/admin/kube-apiserver/) +* [kube-controller-manager](/docs/admin/kube-controller-manager/) +* [kube-scheduler](/docs/admin/kube-scheduler/). + +Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options. + +*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable. + +## Extensions + +Extensions are software components that extend and deeply integrate with Kubernetes. +They adapt it to support new types and new kinds of hardware. + +Most cluster administrators will use a hosted or distribution +instance of Kubernetes. As a result, most Kubernetes users will not need to +install extensions and fewer will need to author new ones. + +## Extension Patterns + +Kubernetes is designed to be automated by writing client programs. Any +program that reads and/or writes to the Kubernetes API can provide useful +automation. *Automation* can run on the cluster or off it. By following +the guidance in this doc you can write highly available and robust automation. +Automation generally works with any Kubernetes cluster, including hosted +clusters and managed installations. + +There is a specific pattern for writing client programs that work well with +Kubernetes called the *Controller* pattern. Controllers typically read an +object's `.spec`, possibly do things, and then update the object's `.status`. + +A controller is a client of Kubernetes. When Kubernetes is the client and +calls out to a remote service, it is called a *Webhook*. The remote service +is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of +failure. + +In the webhook model, Kubernetes makes a network request to a remote service. +In the *Binary Plugin* model, Kubernetes executes a binary (program). +Binary plugins are used by the kubelet (e.g. [Flex Volume +Plugins](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) +and [Network +Plugins](/docs/concepts/cluster-administration/network-plugins/)) +and by kubectl. + +Below is a diagram showing how the extension points interact with the +Kubernetes control plane. + + + + + + +## Extension Points + +This diagram shows the extension points in a Kubernetes system. + + + + + +1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies. +2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/overview/extending#api-access-extensions) section. +3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/overview/extending#user-defined-types) section. Custom Resources are often used with API Access Extensions. +4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section. +5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources. +6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/overview/extending#network-plugins) allow for different implementations of pod networking. +7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/overview/extending#storage-plugins). + +If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions. + + + + + + +## API Extensions +### User-Defined Types + +Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`. + +Do not use a Custom Resource as data storage for application, user, or monitoring data. + +For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/api-extension/custom-resources/). + + +### Combining New APIs with Automation + +The combination of a custom resource API and a control loop is called the [Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies. + +### Changing Built-in Resources + +When you extend the Kubernetes API by adding custom resources, the added resources always fall into a new API Groups. You cannot replace or change existing API groups. +Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API Access Extensions do. + + +### API Access Extensions + +When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow. + +Each of these steps offers extension points. + +Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/). + +### Authentication + +[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request. + +Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs. + + +### Authorization + +[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It just works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision. + + +### Dynamic Admission Control + +After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. In addition to the built-in steps, there are several extensions: + +* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers. +* To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates. + +## Infrastructure Extensions + + +### Storage Plugins + +[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md +) allow users to mount volume types without built-in support by having the +Kubelet call a Binary Plugin to mount the volume. + + +### Device Plugins + +Device plugins allow a node to discover new Node resources (in addition to the +builtin ones like cpu and memory) via a [Device +Plugin](/docs/concepts/cluster-administration/device-plugins/). + + +### Network Plugins + +Different networking fabrics can be supported via node-level [Network Plugins](/docs/admin/network-plugins/). + +### Scheduler Extensions + +The scheduler is a special type of controller that watches pods, and assigns +pods to nodes. The default scheduler can be replaced entirely, while +continuing to use other Kubernetes components, or [multiple +schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/) +can run at the same time. + +This is a significant undertaking, and almost all Kubernetes users find they +do not need to modify the scheduler. + +The scheduler also supports a +[webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md) +that permits a webhook backend (scheduler extension) to filter and prioritize +the nodes chosen for a pod. + + + + +## {{% heading "whatsnext" %}} + + +* Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/) +* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/) +* Learn more about Infrastructure extensions + * [Network Plugins](/docs/concepts/cluster-administration/network-plugins/) + * [Device Plugins](/docs/concepts/cluster-administration/device-plugins/) +* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) +* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/) + + diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index f2ca2e2435..bd7d27305e 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -178,7 +178,7 @@ Aggregated APIs offer more advanced API features and customization of other feat | Feature | Description | CRDs | Aggregated API | | ------- | ----------- | ---- | -------------- | -| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/extend-api-custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks | +| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks | | Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes | | Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | Yes | | Custom Storage | If you need storage with a different performance mode (for example, a time-series database instead of key-value store) or isolation for security (for example, encryption of sensitive information, etc.) | No | Yes | diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index d27dddd384..c8388478f5 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -223,7 +223,7 @@ Here are some examples of device plugin implementations: * The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin) * The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin) * The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin) -* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices +* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) for Xilinx FPGA devices ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md index 7914b1cab5..bc06bd4ab0 100644 --- a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md @@ -50,7 +50,7 @@ Extensions are software components that extend and deeply integrate with Kuberne They adapt it to support new types and new kinds of hardware. Most cluster administrators will use a hosted or distribution -instance of Kubernetes. As a result, most Kubernetes users will need to +instance of Kubernetes. As a result, most Kubernetes users will not need to install extensions and fewer will need to author new ones. ## Extension Patterns diff --git a/content/en/docs/concepts/overview/_index.md b/content/en/docs/concepts/overview/_index.md index ec86980c4b..a52c470446 100755 --- a/content/en/docs/concepts/overview/_index.md +++ b/content/en/docs/concepts/overview/_index.md @@ -1,4 +1,5 @@ --- title: "Overview" weight: 20 ---- \ No newline at end of file +description: Get a high-level outline of Kubernetes and the components it is built from. +--- diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md index f83f00683e..53e6b84c16 100644 --- a/content/en/docs/concepts/overview/components.md +++ b/content/en/docs/concepts/overview/components.md @@ -3,6 +3,9 @@ reviewers: - lavalamp title: Kubernetes Components content_type: concept +description: > + A Kubernetes cluster consists of the components that represent the control plane + and a set of machines called nodes. weight: 20 card: name: concepts diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md index dd69fb6ccb..b3b6960358 100644 --- a/content/en/docs/concepts/overview/kubernetes-api.md +++ b/content/en/docs/concepts/overview/kubernetes-api.md @@ -4,6 +4,9 @@ reviewers: title: The Kubernetes API content_type: concept weight: 30 +description: > + The Kubernetes API lets you query and manipulate the state of objects in Kubernetes. + The core of Kubernetes' control plane is the API server and the HTTP API that it exposes. Users, the different parts of your cluster, and external components all communicate with one another through the API server. card: name: concepts weight: 30 diff --git a/content/en/docs/concepts/overview/what-is-kubernetes.md b/content/en/docs/concepts/overview/what-is-kubernetes.md index 5b30c8e66e..5060b6f287 100644 --- a/content/en/docs/concepts/overview/what-is-kubernetes.md +++ b/content/en/docs/concepts/overview/what-is-kubernetes.md @@ -74,7 +74,7 @@ Kubernetes lets you store and manage sensitive information, such as passwords, O ## What Kubernetes is not -Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, logging, and monitoring. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important. +Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, and lets users integrate their logging, monitoring, and alerting solutions. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important. Kubernetes: diff --git a/content/en/docs/concepts/overview/working-with-objects/_index.md b/content/en/docs/concepts/overview/working-with-objects/_index.md index 8661349a3f..f872c20697 100755 --- a/content/en/docs/concepts/overview/working-with-objects/_index.md +++ b/content/en/docs/concepts/overview/working-with-objects/_index.md @@ -1,5 +1,7 @@ --- title: "Working with Kubernetes Objects" weight: 40 +description: > + Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. + Learn about the Kubernetes object model and how to work with these objects. --- - diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md index 5e3acc5123..07e7dac726 100644 --- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md @@ -43,6 +43,10 @@ resources within the same namespace. Creation and deletion of namespaces are described in the [Admin Guide documentation for namespaces](/docs/admin/namespaces). +{{< note >}} + Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces. +{{< /note >}} + ### Viewing namespaces You can list the current namespaces in a cluster using: diff --git a/content/en/docs/concepts/overview/working-with-objects/object-management.md b/content/en/docs/concepts/overview/working-with-objects/object-management.md index 97f57ff275..7cb65b5497 100644 --- a/content/en/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/en/docs/concepts/overview/working-with-objects/object-management.md @@ -40,12 +40,6 @@ objects, it provides no history of previous configurations. Run an instance of the nginx container by creating a Deployment object: -```sh -kubectl run nginx --image nginx -``` - -Do the same thing using a different syntax: - ```sh kubectl create deployment nginx --image nginx ``` diff --git a/content/en/docs/concepts/policy/_index.md b/content/en/docs/concepts/policy/_index.md index 41d91de546..d2b42bc4cd 100755 --- a/content/en/docs/concepts/policy/_index.md +++ b/content/en/docs/concepts/policy/_index.md @@ -1,5 +1,6 @@ --- title: "Policies" weight: 90 +description: > + Policies you can configure that apply to groups of resources. --- - diff --git a/content/en/docs/concepts/scheduling-eviction/_index.md b/content/en/docs/concepts/scheduling-eviction/_index.md index a30a80a451..3a2bf9359f 100644 --- a/content/en/docs/concepts/scheduling-eviction/_index.md +++ b/content/en/docs/concepts/scheduling-eviction/_index.md @@ -1,5 +1,8 @@ --- title: "Scheduling and Eviction" weight: 90 +description: > + In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes so that the kubelet can run them. + Eviction is the process of proactively failing one or more Pods on resource-starved Nodes. --- diff --git a/content/en/docs/concepts/security/_index.md b/content/en/docs/concepts/security/_index.md index aecc16eee7..3dfb62fe48 100644 --- a/content/en/docs/concepts/security/_index.md +++ b/content/en/docs/concepts/security/_index.md @@ -1,4 +1,6 @@ --- title: "Security" weight: 81 +description: > + Concepts for keeping your cloud-native workload secure. --- diff --git a/content/en/docs/concepts/services-networking/_index.md b/content/en/docs/concepts/services-networking/_index.md index eea2c65b33..2e7d91427e 100755 --- a/content/en/docs/concepts/services-networking/_index.md +++ b/content/en/docs/concepts/services-networking/_index.md @@ -1,5 +1,12 @@ --- title: "Services, Load Balancing, and Networking" weight: 60 +description: > + Concepts and resources behind networking in Kubernetes. --- +Kubernetes networking addresses four concerns: +- Containers within a Pod use networking to communicate via loopback. +- Cluster networking provides communication between different Pods. +- The Service resource lets you expose an application running in Pods to be reachable from outside your cluster. +- You can also use Services to publish services only for consumption inside your cluster. diff --git a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index d4218f38f6..8eee03bf9b 100644 --- a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -23,7 +23,7 @@ Modification not using HostAliases is not suggested because the file is managed Start an Nginx Pod which is assigned a Pod IP: ```shell -kubectl run nginx --image nginx --generator=run-pod/v1 +kubectl run nginx --image nginx ``` ``` @@ -64,14 +64,14 @@ By default, the `hosts` file only includes IPv4 and IPv6 boilerplates like ## Adding additional entries with hostAliases In addition to the default boilerplate, you can add additional entries to the -`hosts` file. +`hosts` file. For example: to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`, `bar.remote` to `10.1.2.3`, you can configure HostAliases for a Pod under `.spec.hostAliases`: {{< codenew file="service/networking/hostaliases-pod.yaml" >}} -Yoyu can start a Pod with that configuration by running: +You can start a Pod with that configuration by running: ```shell kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml diff --git a/content/en/docs/concepts/storage/_index.md b/content/en/docs/concepts/storage/_index.md index 7e0dd19b12..a6aeac7734 100755 --- a/content/en/docs/concepts/storage/_index.md +++ b/content/en/docs/concepts/storage/_index.md @@ -1,5 +1,7 @@ --- title: "Storage" weight: 70 +description: > + Ways to provide both long-term and temporary storage to Pods in your cluster. --- diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index d6b3a9e332..a16baf46b4 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -41,7 +41,7 @@ be updated once they are created. Administrators can specify a default StorageClass just for PVCs that don't request any particular class to bind to: see the -[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#class-1) +[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) for details. ```yaml diff --git a/content/en/docs/concepts/storage/volume-snapshot-classes.md b/content/en/docs/concepts/storage/volume-snapshot-classes.md index f50db19520..f3b7025270 100644 --- a/content/en/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/en/docs/concepts/storage/volume-snapshot-classes.md @@ -13,7 +13,7 @@ weight: 30 -This document describes the concept of `VolumeSnapshotClass` in Kubernetes. Familiarity +This document describes the concept of VolumeSnapshotClass in Kubernetes. Familiarity with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and [storage classes](/docs/concepts/storage/storage-classes) is suggested. @@ -24,30 +24,43 @@ with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and ## Introduction -Just like `StorageClass` provides a way for administrators to describe the "classes" -of storage they offer when provisioning a volume, `VolumeSnapshotClass` provides a +Just like StorageClass provides a way for administrators to describe the "classes" +of storage they offer when provisioning a volume, VolumeSnapshotClass provides a way to describe the "classes" of storage when provisioning a volume snapshot. ## The VolumeSnapshotClass Resource -Each `VolumeSnapshotClass` contains the fields `driver`, `deletionPolicy`, and `parameters`, -which are used when a `VolumeSnapshot` belonging to the class needs to be +Each VolumeSnapshotClass contains the fields `driver`, `deletionPolicy`, and `parameters`, +which are used when a VolumeSnapshot belonging to the class needs to be dynamically provisioned. -The name of a `VolumeSnapshotClass` object is significant, and is how users can +The name of a VolumeSnapshotClass object is significant, and is how users can request a particular class. Administrators set the name and other parameters -of a class when first creating `VolumeSnapshotClass` objects, and the objects cannot +of a class when first creating VolumeSnapshotClass objects, and the objects cannot be updated once they are created. -Administrators can specify a default `VolumeSnapshotClass` just for VolumeSnapshots -that don't request any particular class to bind to. - ```yaml apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshotClass metadata: name: csi-hostpath-snapclass -driver: hostpath.csi.k8s.io +driver: hostpath.csi.k8s.io +deletionPolicy: Delete +parameters: +``` + +Administrators can specify a default VolumeSnapshotClass for VolumeSnapshots +that don't request any particular class to bind to by adding the +`snapshot.storage.kubernetes.io/is-default-class: "true"` annotation: + +```yaml +apiVersion: snapshot.storage.k8s.io/v1beta1 +kind: VolumeSnapshotClass +metadata: + name: csi-hostpath-snapclass + annotations: + snapshot.storage.kubernetes.io/is-default-class: "true" +driver: hostpath.csi.k8s.io deletionPolicy: Delete parameters: ``` @@ -59,9 +72,9 @@ used for provisioning VolumeSnapshots. This field must be specified. ### DeletionPolicy -Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a `VolumeSnapshotContent` when the `VolumeSnapshot` object it is bound to is to be deleted. The deletionPolicy of a volume snapshot can either be `Retain` or `Delete`. This field must be specified. +Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a VolumeSnapshotContent when the VolumeSnapshot object it is bound to is to be deleted. The deletionPolicy of a volume snapshot can either be `Retain` or `Delete`. This field must be specified. -If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the `VolumeSnapshotContent` object. If the deletionPolicy is `Retain`, then both the underlying snapshot and `VolumeSnapshotContent` remain. +If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the VolumeSnapshotContent object. If the deletionPolicy is `Retain`, then both the underlying snapshot and VolumeSnapshotContent remain. ## Parameters diff --git a/content/en/docs/concepts/workloads/_index.md b/content/en/docs/concepts/workloads/_index.md index ca394ebd00..1aac095cb5 100644 --- a/content/en/docs/concepts/workloads/_index.md +++ b/content/en/docs/concepts/workloads/_index.md @@ -1,5 +1,7 @@ --- title: "Workloads" weight: 50 +description: > + Understand Pods, the smallest deployable compute object in Kubernetes, and the higher-level abstractions that help you to run them. --- diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 6287c0d98e..6b117cdc44 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -861,7 +861,12 @@ The output is similar to this: ``` Waiting for rollout to finish: 2 of 3 updated replicas are available... deployment.apps/nginx-deployment successfully rolled out -$ echo $? +``` +and the exit status from `kubectl rollout` is 0 (success): +```shell +echo $? +``` +``` 0 ``` @@ -1003,7 +1008,12 @@ The output is similar to this: ``` Waiting for rollout to finish: 2 out of 3 new replicas have been updated... error: deployment "nginx" exceeded its progress deadline -$ echo $? +``` +and the exit status from `kubectl rollout` is 1 (indicating an error): +```shell +echo $? +``` +``` 1 ``` diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index 45fa66bd3d..a55759c300 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -218,9 +218,6 @@ exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The back-off count is reset if no new failed Pods appear before the Job's next status check. -{{< note >}} -Issue [#54870](https://github.com/kubernetes/kubernetes/issues/54870) still exists for versions of Kubernetes prior to version 1.12 -{{< /note >}} {{< note >}} If your job has `restartPolicy = "OnFailure"`, keep in mind that your container running the Job will be terminated once the job backoff limit has been reached. This can make debugging the Job's executable more difficult. We suggest setting diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index 60973c46a8..d72265faf5 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -77,7 +77,7 @@ A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prob performed periodically by the [kubelet](/docs/admin/kubelet/) on a Container. To perform a diagnostic, the kubelet calls a -[Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implemented by +[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by the Container. There are three types of handlers: * [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): @@ -281,7 +281,7 @@ once bound to a node, a Pod will never be rebound to another node. In general, Pods remain until a human or {{< glossary_tooltip term_id="controller" text="controller" >}} process explicitly removes them. -The control plane cleans up terminated Pods (with a phase of `Succeeded` or +The control plane cleans up terminated Pods (with a phase of `Succeeded` or `Failed`), when the number of Pods exceeds the configured threshold (determined by `terminated-pod-gc-threshold` in the kube-controller-manager). This avoids a resource leak as Pods are created and terminated over time. @@ -407,4 +407,3 @@ spec: - diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md index 9cf6a65883..594816a2b5 100644 --- a/content/en/docs/contribute/advanced.md +++ b/content/en/docs/contribute/advanced.md @@ -39,6 +39,7 @@ The PR wrangler’s duties include: - Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging. - Assign `/lgtm` and `/approve` labels to PRs that can be merged. - Merge PRs when they are ready, or close PRs that shouldn’t be accepted. + - Consider accepting accurate technical content even if the content meets only some of the docs' [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns. - Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata. ### Helpful GitHub queries for wranglers diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md index 05a576a74b..5b2642dd39 100644 --- a/content/en/docs/contribute/new-content/open-a-pr.md +++ b/content/en/docs/contribute/new-content/open-a-pr.md @@ -217,21 +217,37 @@ When you are ready to submit a pull request, commit your changes. It's a good idea to preview your changes locally before pushing them or opening a pull request. A preview lets you catch build errors or markdown formatting problems. -You can either build the website's docker image or run Hugo locally. Building the docker image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging. +You can either build the website's container image or run Hugo locally. Building the container image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging. {{< tabs name="tab_with_hugo" >}} {{% tab name="Hugo in a container" %}} +{{< note >}} +The commands below use Docker as default container engine. Set the `CONTAINER_ENGINE` environment variable to override this behaviour. +{{< /note >}} + 1. Build the image locally: ```bash - make docker-image + # Use docker (default) + make container-image + + ### OR ### + + # Use podman + CONTAINER_ENGINE=podman make container-image ``` 2. After building the `kubernetes-hugo` image locally, build and serve the site: ```bash - make docker-serve + # Use docker (default) + make container-serve + + ### OR ### + + # Use podman + CONTAINER_ENGINE=podman make container-serve ``` 3. In a web browser, navigate to `https://localhost:1313`. Hugo watches the diff --git a/content/en/docs/contribute/participate/_index.md b/content/en/docs/contribute/participate/_index.md new file mode 100644 index 0000000000..a99eaf464e --- /dev/null +++ b/content/en/docs/contribute/participate/_index.md @@ -0,0 +1,119 @@ +--- +title: Participating in SIG Docs +content_type: concept +weight: 60 +card: + name: contribute + weight: 60 +--- + + + +SIG Docs is one of the +[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md) +within the Kubernetes project, focused on writing, updating, and maintaining +the documentation for Kubernetes as a whole. See +[SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs) +for more information about the SIG. + +SIG Docs welcomes content and reviews from all contributors. Anyone can open a +pull request (PR), and anyone is welcome to file issues about content or comment +on pull requests in progress. + +You can also become a [member](/docs/contribute/participating/roles-and-responsibilities/#members), +[reviewer](/docs/contribute/participating/roles-and-responsibilities/#reviewers), or [approver](/docs/contribute/participating/roles-and-responsibilities/#approvers). These roles require greater +access and entail certain responsibilities for approving and committing changes. +See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) +for more information on how membership works within the Kubernetes community. + +The rest of this document outlines some unique ways these roles function within +SIG Docs, which is responsible for maintaining one of the most public-facing +aspects of Kubernetes -- the Kubernetes website and documentation. + + + + + +## SIG Docs chairperson + +Each SIG, including SIG Docs, selects one or more SIG members to act as +chairpersons. These are points of contact between SIG Docs and other parts of +the Kubernetes organization. They require extensive knowledge of the structure +of the Kubernetes project as a whole and how SIG Docs works within it. See +[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) +for the current list of chairpersons. + +## SIG Docs teams and automation + +Automation in SIG Docs relies on two different mechanisms: +GitHub teams and OWNERS files. + +### GitHub teams + +There are two categories of SIG Docs [teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) on GitHub: + +- `@sig-docs-{language}-owners` are approvers and leads +- `@sig-docs-{language}-reviewers` are reviewers + +Each can be referenced with their `@name` in GitHub comments to communicate with +everyone in that group. + +Sometimes Prow and GitHub teams overlap without matching exactly. For assignment of issues, pull requests, and to support PR approvals, +the automation uses information from `OWNERS` files. + +### OWNERS files and front-matter + +The Kubernetes project uses an automation tool called prow for automation +related to GitHub issues and pull requests. The +[Kubernetes website repository](https://github.com/kubernetes/website) uses +two [prow plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plugins): + +- blunderbuss +- approve + +These two plugins use the +[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and +[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) +files in the top level of the `kubernetes/website` GitHub repository to control +how prow works within the repository. + +An OWNERS file contains a list of people who are SIG Docs reviewers and +approvers. OWNERS files can also exist in subdirectories, and can override who +can act as a reviewer or approver of files in that subdirectory and its +descendants. For more information about OWNERS files in general, see +[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). + +In addition, an individual Markdown file can list reviewers and approvers in its +front-matter, either by listing individual GitHub usernames or GitHub groups. + +The combination of OWNERS files and front-matter in Markdown files determines +the advice PR owners get from automated systems about who to ask for technical +and editorial review of their PR. + +## How merging works + +When a pull request is merged to the branch used to publish content, that content is published to http://kubernetes.io. To ensure that +the quality of our published content is high, we limit merging pull requests to +SIG Docs approvers. Here's how it works. + +- When a pull request has both the `lgtm` and `approve` labels, has no `hold` + labels, and all tests are passing, the pull request merges automatically. +- Kubernetes organization members and SIG Docs approvers can add comments to + prevent automatic merging of a given pull request (by adding a `/hold` comment + or withholding a `/lgtm` comment). +- Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment. +- Only SIG Docs approvers can merge a pull request + by adding an `/approve` comment. Some approvers also perform additional + specific roles, such as [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) or + [SIG Docs chairperson](#sig-docs-chairperson). + + + +## {{% heading "whatsnext" %}} + + +For more information about contributing to the Kubernetes documentation, see: + +- [Contributing new content](/docs/contribute/overview/) +- [Reviewing content](/docs/contribute/review/reviewing-prs) +- [Documentation style guide](/docs/contribute/style/) diff --git a/content/en/docs/contribute/participate/roles-and-responsibilties.md b/content/en/docs/contribute/participate/roles-and-responsibilties.md new file mode 100644 index 0000000000..b01beec352 --- /dev/null +++ b/content/en/docs/contribute/participate/roles-and-responsibilties.md @@ -0,0 +1,191 @@ +--- +title: Roles and responsibilities +content_type: concept +weight: 10 +--- + + + +Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow, you can apply for different levels of membership in the community. +These roles allow you to take on more responsibility within the community. +Each role requires more time and commitment. The roles are: + +- Anyone: regular contributors to the Kubernetes documentation +- Members: can assign and triage issues and provide non-binding review on pull requests +- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality +- Approvers: can lead reviews on documentation and merge changes + + + +## Anyone + +Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors! + +Anyone can: + +- Open an issue in any [Kubernetes](https://github.com/kubernetes/) repository, including [`kubernetes/website`](https://github.com/kubernetes/website) +- Give non-binding feedback on a pull request +- Contribute to a localization +- Suggest improvements on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + +After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also: + +- Open a pull request to improve existing content, add new content, or write a blog post or case study +- Create diagrams, graphics assets, and embeddable screencasts and videos + +For more information, see [contributing new content](/docs/contribute/new-content/). + +## Members + +A member is someone who has submitted multiple pull requests to `kubernetes/website`. Members are a part of the [Kubernetes GitHub organization](https://github.com/kubernetes). + +Members can: + +- Do everything listed under [Anyone](#anyone) +- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request + + {{< note >}} + Using `/lgtm` triggers automation. If you want to provide non-binding approval, simply commenting "LGTM" works too! + {{< /note >}} +- Use the `/hold` comment to block merging for a pull request +- Use the `/assign` comment to assign a reviewer to a pull request +- Provide non-binding review on pull requests +- Use automation to triage and categorize issues +- Document new features + +### Becoming a member + +After submitting at least 5 substantial pull requests and meeting the other [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member): + +1. Find two [reviewers](#reviewers) or [approvers](#approvers) to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your membership. + + Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the + [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + + {{< note >}} + Don't send a direct email or Slack direct message to an individual + SIG Docs member. You must request sponsorship before submitting your application. + {{< /note >}} + +2. Open a GitHub issue in the [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the **Organization Membership Request** issue template. + +3. Let your sponsors know about the GitHub issue. You can either: + - Mention their GitHub username in an issue (`@`) + - Send them the issue link using Slack or email. + + Sponsors will approve your request with a `+1` vote. Once your sponsors approve the request, a Kubernetes GitHub admin adds you as a member. Congratulations! + + If your membership request is not accepted you will receive feedback. After addressing the feedback, apply again. + +4. Accept the invitation to the Kubernetes GitHub organization in your email account. + + {{< note >}} + GitHub sends the invitation to the default email address in your account. + {{< /note >}} + +## Reviewers + +Reviewers are responsible for reviewing open pull requests. Unlike member feedback, you must address reviewer feedback. Reviewers are members of the [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub team. + +Reviewers can: + +- Do everything listed under [Anyone](#anyone) and [Members](#members) +- Review pull requests and provide binding feedback + + {{< note >}} + To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ". + {{< /note >}} + +- Edit user-facing strings in code +- Improve code comments + +You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area. + +### Assigning reviewers to pull requests + +Automation assigns reviewers to all pull requests. You can request a +review from a specific person by commenting: `/assign +[@_github_handle]`. + +If the assigned reviewer has not commented on the PR, another reviewer can step in. You can also assign technical reviewers as needed. + +### Using `/lgtm` + +LGTM stands for "Looks good to me" and indicates that a pull request is technically accurate and ready to merge. All PRs need a `/lgtm` comment from a reviewer and a `/approve` comment from an approver to merge. + +A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label. + +### Becoming a reviewer + +When you meet the +[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), you can become a SIG Docs reviewer. Reviewers in other SIGs must apply separately for reviewer status in SIG Docs. + +To apply: + +1. Open a pull request that adds your GitHub user name to a section of the +[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file +in the `kubernetes/website` repository. + + {{ note }} + If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`. + {{ /note }} + +2. Assign the PR to one or more SIG-Docs approvers (user names listed under `sig-docs-{language}-owners`). + +If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. + +## Approvers + +Approvers review and approve pull requests for merging. Approvers are members of the +[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub teams. + +Approvers can do the following: + +- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers) +- Publish contributor content by approving and merging pull requests using the `/approve` comment +- Propose improvements to the style guide +- Propose improvements to docs tests +- Propose improvements to the Kubernetes website or other tooling + +If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on a change that doesn't need additional technical review. + + +### Approving pull requests + +Approvers and SIG Docs leads are the only ones who can merge pull requests into the website repository. This comes with certain responsibilities. + +- Approvers can use the `/approve` command, which merges PRs into the repo. + + {{< warning >}} + A careless merge can break the site, so be sure that when you merge something, you mean it. + {{< /warning >}} + +- Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content). + + If you ever have a question, or you're not sure about something, feel free to call for additional review. + +- Verify that Netlify tests pass before you `/approve` a PR. + + Netlify tests must pass before approving + +- Visit the Netlify page preview for a PR to make sure things look good before approving. + +- Participate in the [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this +rotation. See [Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) +for more details. + +### Becoming an approver + +When you meet the [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), you can become a SIG Docs approver. Approvers in other SIGs must apply separately for approver status in SIG Docs. + +To apply: + +1. Open a pull request adding yourself to a section of the [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file in the `kubernetes/website` repository. + + {{ note }} + If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`. + {{ /note }} + +2. Assign the PR to one or more current SIG Docs approvers. + +If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. \ No newline at end of file diff --git a/content/en/docs/contribute/participating.md b/content/en/docs/contribute/participating.md deleted file mode 100644 index 681c53f994..0000000000 --- a/content/en/docs/contribute/participating.md +++ /dev/null @@ -1,316 +0,0 @@ ---- -title: Participating in SIG Docs -content_type: concept -weight: 60 -card: - name: contribute - weight: 60 ---- - - - -SIG Docs is one of the -[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md) -within the Kubernetes project, focused on writing, updating, and maintaining -the documentation for Kubernetes as a whole. See -[SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs) -for more information about the SIG. - -SIG Docs welcomes content and reviews from all contributors. Anyone can open a -pull request (PR), and anyone is welcome to file issues about content or comment -on pull requests in progress. - -You can also become a [member](#members), -[reviewer](#reviewers), or [approver](#approvers). These roles require greater -access and entail certain responsibilities for approving and committing changes. -See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) -for more information on how membership works within the Kubernetes community. - -The rest of this document outlines some unique ways these roles function within -SIG Docs, which is responsible for maintaining one of the most public-facing -aspects of Kubernetes -- the Kubernetes website and documentation. - - - - - -## Roles and responsibilities - -- **Anyone** can contribute to Kubernetes documentation. To contribute, you must [sign the CLA](/docs/contribute/new-content/overview/#sign-the-cla) and have a GitHub account. -- **Members** of the Kubernetes organization are contributors who have spent time and effort on the Kubernetes project, usually by opening pull requests with accepted changes. See [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md) for membership criteria. -- A SIG Docs **Reviewer** is a member of the Kubernetes organization who has - expressed interest in reviewing documentation pull requests, and has been - added to the appropriate GitHub group and `OWNERS` files in the GitHub - repository by a SIG Docs Approver. -- A SIG Docs **Approver** is a member in good standing who has shown a continued - commitment to the project. An approver can merge pull requests - and publish content on behalf of the Kubernetes organization. - Approvers can also represent SIG Docs in the larger Kubernetes community. - Some duties of a SIG Docs approver, such as coordinating a release, - require a significant time commitment. - -## Anyone - -Anyone can do the following: - -- Open a GitHub issue against any part of Kubernetes, including documentation. -- Provide non-binding feedback on a pull request. -- Help to localize existing content -- Bring up ideas for improvement on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). -- Use the `/lgtm` Prow command (short for "looks good to me") to recommend the changes in a pull request for merging. - {{< note >}} - If you are not a member of the Kubernetes organization, using `/lgtm` has no effect on automated systems. - {{< /note >}} - -After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also: -- Open a pull request to improve existing content, add new content, or write a blog post or case study. - -## Members - -Members are contributors to the Kubernetes project who meet the [membership criteria](https://github.com/kubernetes/community/blob/master/community-membership.md#member). SIG Docs welcomes contributions from all members of the Kubernetes community, -and frequently requests reviews from members of other SIGs for technical accuracy. - -Any member of the [Kubernetes organization](https://github.com/kubernetes) can do the following: - -- Everything listed under [Anyone](#anyone) -- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request. -- Use the `/hold` command to prevent a pull request from being merged, if the pull request already has the LGTM and approve labels. -- Use the `/assign` comment to assign a reviewer to a pull request. - -### Becoming a member - -After you have successfully submitted at least 5 substantive pull requests, you -can request [membership](https://github.com/kubernetes/community/blob/master/community-membership.md#member) -in the Kubernetes organization. Follow these steps: - -1. Find two reviewers or approvers to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) - your membership. - - Ask for sponsorship in the [#sig-docs channel on the - Kubernetes Slack instance](https://kubernetes.slack.com) or on the - [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). - - {{< note >}} - Don't send a direct email or Slack direct message to an individual - SIG Docs member. - {{< /note >}} - -2. Open a GitHub issue in the `kubernetes/org` repository to request membership. - Fill out the template using the guidelines at - [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md). - -3. Let your sponsors know about the GitHub issue, either by at-mentioning them - in the GitHub issue (adding a comment with `@`) or by sending them the link directly, - so that they can add a `+1` vote. - -4. When your membership is approved, the github admin team member assigned to your request updates the - GitHub issue to show approval and then closes the GitHub issue. - Congratulations, you are now a member! - -If your membership request is not accepted, the -membership committee provides information or steps to take before applying -again. - -## Reviewers - -Reviewers are members of the -[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -GitHub group. Reviewers review documentation pull requests and provide feedback on proposed -changes. Reviewers can: - -- Do everything listed under [Anyone](#anyone) and [Members](#members) -- Document new features -- Triage and categorize issues -- Review pull requests and provide binding feedback -- Create diagrams, graphics assets, and embeddable screencasts and videos -- Edit user-facing strings in code -- Improve code comments - -### Assigning reviewers to pull requests - -Automation assigns reviewers to all pull requests. You can request a -review from a specific reviewer with a comment on the pull request: `/assign -[@_github_handle]`. To indicate that a pull request is technically accurate and -requires no further changes, a reviewer adds a `/lgtm` comment to the pull -request. - -If the assigned reviewer has not yet reviewed the content, another reviewer can -step in. In addition, you can assign technical reviewers and wait for them to -provide a `/lgtm` comment. - -For a trivial change or one that needs no technical review, SIG Docs -[approvers](#approvers) can provide the `/lgtm` as well. - -An `/approve` comment from a reviewer is ignored by automation. - -### Becoming a reviewer - -When you meet the -[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), -you can become a SIG Docs reviewer. Reviewers in other SIGs must apply -separately for reviewer status in SIG Docs. - -To apply, open a pull request to add yourself to the `reviewers` section of the -[top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS) -in the `kubernetes/website` repository. Assign the PR to one or more current SIG -Docs approvers. - -If your pull request is approved, you are now a SIG Docs reviewer. -[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) -will assign and suggest you as a reviewer on new pull requests. - -If you are approved, request that a current SIG Docs approver add you to the -[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -GitHub group. Only members of the `kubernetes-website-admins` GitHub group can -add new members to a GitHub group. - -## Approvers - -Approvers are members of the -[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) -GitHub group. See [SIG Docs teams and automation](#sig-docs-teams-and-automation) for details. - -Approvers can do the following: - -- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers) -- Publish contributor content by approving and merging pull requests using the `/approve` comment. - If someone who is not an approver leaves the approval comment, automation ignores it. -- Participate in a Kubernetes release team as a docs representative -- Propose improvements to the style guide -- Propose improvements to docs tests -- Propose improvements to the Kubernetes website or other tooling - -If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`, -the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on -a change that doesn't need additional technical review. - -### Becoming an approver - -When you meet the -[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), -you can become a SIG Docs approver. Approvers in other SIGs must apply -separately for approver status in SIG Docs. - -To apply, open a pull request to add yourself to the `approvers` section of the -[top-level OWNERS file](https://github.com/kubernetes/website/blob/master/OWNERS) -in the `kubernetes/website` repository. Assign the PR to one or more current SIG -Docs approvers. - -If your pull request is approved, you are now a SIG Docs approver. -[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) -will assign and suggest you as a reviewer on new pull requests. - -If you are approved, request that a current SIG Docs approver add you to the -[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) -GitHub group. Only members of the `kubernetes-website-admins` GitHub group can -add new members to a GitHub group. - -### Approver responsibilities - -Approvers improve the documentation by reviewing and merging pull requests into the website repository. Because this role carries additional privileges, approvers have additional responsibilities: - -- Approvers can use the `/approve` command, which merges PRs into the repo. - - A careless merge can break the site, so be sure that when you merge something, you mean it. - -- Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content). - - If you ever have a question, or you're not sure about something, feel free to call for additional review. - -- Verify that Netlify tests pass before you `/approve` a PR. - - Netlify tests must pass before approving - -- Visit the Netlify page preview for a PR to make sure things look good before approving. - -- Participate in the [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this -rotation. See [Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) -for more details. - -## SIG Docs chairperson - -Each SIG, including SIG Docs, selects one or more SIG members to act as -chairpersons. These are points of contact between SIG Docs and other parts of -the Kubernetes organization. They require extensive knowledge of the structure -of the Kubernetes project as a whole and how SIG Docs works within it. See -[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) -for the current list of chairpersons. - -## SIG Docs teams and automation - -Automation in SIG Docs relies on two different mechanisms for automation: -GitHub groups and OWNERS files. - -### GitHub groups - -The SIG Docs group defines two teams on GitHub: - - - [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) - - [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) - -Each can be referenced with their `@name` in GitHub comments to communicate with -everyone in that group. - -These teams overlap, but do not exactly match, the groups used by the automation -tooling. For assignment of issues, pull requests, and to support PR approvals, -the automation uses information from OWNERS files. - -### OWNERS files and front-matter - -The Kubernetes project uses an automation tool called prow for automation -related to GitHub issues and pull requests. The -[Kubernetes website repository](https://github.com/kubernetes/website) uses -two [prow plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plugins): - -- blunderbuss -- approve - -These two plugins use the -[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and -[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) -files in the top level of the `kubernetes/website` GitHub repository to control -how prow works within the repository. - -An OWNERS file contains a list of people who are SIG Docs reviewers and -approvers. OWNERS files can also exist in subdirectories, and can override who -can act as a reviewer or approver of files in that subdirectory and its -descendents. For more information about OWNERS files in general, see -[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). - -In addition, an individual Markdown file can list reviewers and approvers in its -front-matter, either by listing individual GitHub usernames or GitHub groups. - -The combination of OWNERS files and front-matter in Markdown files determines -the advice PR owners get from automated systems about who to ask for technical -and editorial review of their PR. - -## How merging works - -When a pull request is merged to the branch used to publish content (currently -`master`), that content is published and available to the world. To ensure that -the quality of our published content is high, we limit merging pull requests to -SIG Docs approvers. Here's how it works. - -- When a pull request has both the `lgtm` and `approve` labels, has no `hold` - labels, and all tests are passing, the pull request merges automatically. -- Kubernetes organization members and SIG Docs approvers can add comments to - prevent automatic merging of a given pull request (by adding a `/hold` comment - or withholding a `/lgtm` comment). -- Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment. -- Only SIG Docs approvers can merge a pull request - by adding an `/approve` comment. Some approvers also perform additional - specific roles, such as [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) or - [SIG Docs chairperson](#sig-docs-chairperson). - - - -## {{% heading "whatsnext" %}} - - -For more information about contributing to the Kubernetes documentation, see: - -- [Contributing new content](/docs/contribute/overview/) -- [Reviewing content](/docs/contribute/review/reviewing-prs) -- [Documentation style guide](/docs/contribute/style/) - - diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md index 12d00ae01a..e4a6d703ad 100644 --- a/content/en/docs/contribute/style/hugo-shortcodes/index.md +++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md @@ -240,8 +240,8 @@ Renders to: ## {{% heading "whatsnext" %}} * Learn about [Hugo](https://gohugo.io/). -* Learn about [writing a new topic](/docs/home/contribute/style/write-new-topic/). -* Learn about [page content types](/docs/home/contribute/style/page-content-types/). -* Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/) -* Learn about [creating a pull request](/docs/home/contribute/create-pull-request/). +* Learn about [writing a new topic](/docs/contribute/style/write-new-topic/). +* Learn about [page content types](/docs/contribute/style/page-content-types/). +* Learn about [creating a pull request](/docs/contribute/new-content/new-content/). +* Learn about [advanced contributing](/docs/contribute/advanced/). diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md index 78ddd4a787..55aa30d66c 100644 --- a/content/en/docs/contribute/style/style-guide.md +++ b/content/en/docs/contribute/style/style-guide.md @@ -121,7 +121,7 @@ document, use the backtick (`` ` ``). {{< table caption = "Do and Don't - Use code style for inline code and commands" >}} Do | Don't :--| :----- -The `kubectl run`command creates a Deployment. | The "kubectl run" command creates a Deployment. +The `kubectl run`command creates a Pod. | The "kubectl run" command creates a Pod. For declarative management, use `kubectl apply`. | For declarative management, use "kubectl apply". Enclose code samples with triple backticks. (\`\`\`)| Enclose code samples with any other syntax. Use single backticks to enclose inline code. For example, `var example = true`. | Use two asterisks (`**`) or an underscore (`_`) to enclose inline code. For example, **var example = true**. @@ -496,7 +496,7 @@ Do | Don't :--| :----- You can explore the API using a browser. | The API can be explored using a browser. The YAML file specifies the replica count. | The replica count is specified in the YAML file. -{{< /table >}} +{{< /table >}} Exception: Use passive voice if active voice leads to an awkward construction. @@ -511,7 +511,7 @@ Do | Don't To create a ReplicaSet, ... | In order to create a ReplicaSet, ... See the configuration file. | Please see the configuration file. View the Pods. | With this next command, we'll view the Pods. -{{< /table >}} +{{< /table >}} ### Address the reader as "you" @@ -520,7 +520,7 @@ Do | Don't :--| :----- You can create a Deployment by ... | We'll create a Deployment by ... In the preceding output, you can see... | In the preceding output, we can see ... -{{< /table >}} +{{< /table >}} ### Avoid Latin phrases @@ -532,7 +532,7 @@ Do | Don't :--| :----- For example, ... | e.g., ... That is, ...| i.e., ... -{{< /table >}} +{{< /table >}} Exception: Use "etc." for et cetera. @@ -550,7 +550,7 @@ Do | Don't Version 1.4 includes ... | In version 1.4, we have added ... Kubernetes provides a new feature for ... | We provide a new feature ... This page teaches you how to use Pods. | In this page, we are going to learn about Pods. -{{< /table >}} +{{< /table >}} ### Avoid jargon and idioms @@ -562,7 +562,7 @@ Do | Don't :--| :----- Internally, ... | Under the hood, ... Create a new cluster. | Turn up a new cluster. -{{< /table >}} +{{< /table >}} ### Avoid statements about the future @@ -581,7 +581,7 @@ Do | Don't :--| :----- In version 1.4, ... | In the current version, ... The Federation feature provides ... | The new Federation feature provides ... -{{< /table >}} +{{< /table >}} diff --git a/content/en/docs/home/_index.md b/content/en/docs/home/_index.md index b4f9a2ee66..8864e4781a 100644 --- a/content/en/docs/home/_index.md +++ b/content/en/docs/home/_index.md @@ -59,6 +59,8 @@ cards: - name: release-notes title: Release Notes description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes. + button: "Download Kubernetes" + button_path: "/docs/setup/release/notes" - name: about title: About the documentation description: This website contains documentation for the current and previous 4 versions of Kubernetes. diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index e0f5ea0f43..874bcbeb1c 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -99,7 +99,9 @@ NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority ## What does each admission controller do? -### AlwaysAdmit {#alwaysadmit} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} +### AlwaysAdmit {#alwaysadmit} + +{{< feature-state for_k8s_version="v1.13" state="deprecated" >}} This admission controller allows all pods into the cluster. It is deprecated because its behavior is the same as if there were no admission controller at all. @@ -113,7 +115,9 @@ scheduled onto the right node), without any authorization check against the imag is enabled, images are always pulled prior to starting containers, which means valid credentials are required. -### AlwaysDeny {#alwaysdeny} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} +### AlwaysDeny {#alwaysdeny} + +{{< feature-state for_k8s_version="v1.13" state="deprecated" >}} Rejects all requests. AlwaysDeny is DEPRECATED as no real meaning. @@ -164,7 +168,9 @@ if the pods don't already have toleration for taints `node.kubernetes.io/not-ready:NoExecute` or `node.alpha.kubernetes.io/unreachable:NoExecute`. -### DenyExecOnPrivileged {#denyexeconprivileged} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} +### DenyExecOnPrivileged {#denyexeconprivileged} + +{{< feature-state for_k8s_version="v1.13" state="deprecated" >}} This admission controller will intercept all requests to exec a command in a pod if that pod has a privileged container. @@ -175,7 +181,9 @@ Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypol which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods is recommended instead. -### DenyEscalatingExec {#denyescalatingexec} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} +### DenyEscalatingExec {#denyescalatingexec} + +{{< feature-state for_k8s_version="v1.13" state="deprecated" >}} This admission controller will deny exec and attach commands to pods that run with escalated privileges that allow host access. This includes pods that run as privileged, have access to the host IPC namespace, and @@ -187,7 +195,9 @@ Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypol which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods is recommended instead. -### EventRateLimit {#eventratelimit} {{< feature-state for_k8s_version="v1.13" state="alpha" >}} +### EventRateLimit {#eventratelimit} + +{{< feature-state for_k8s_version="v1.13" state="alpha" >}} This admission controller mitigates the problem where the API server gets flooded by event requests. The cluster admin can specify event rate limits by: @@ -446,7 +456,9 @@ applies a 0.1 CPU requirement to all Pods in the `default` namespace. See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details. -### MutatingAdmissionWebhook {#mutatingadmissionwebhook} {{< feature-state for_k8s_version="v1.13" state="beta" >}} +### MutatingAdmissionWebhook {#mutatingadmissionwebhook} + +{{< feature-state for_k8s_version="v1.13" state="beta" >}} This admission controller calls any mutating webhooks which match the request. Matching webhooks are called in serial; each one may modify the object if it desires. @@ -537,7 +549,9 @@ This admission controller also protects the access to `metadata.ownerReferences[ of an object, so that only users with "update" permission to the `finalizers` subresource of the referenced *owner* can change it. -### PersistentVolumeLabel {#persistentvolumelabel} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} +### PersistentVolumeLabel {#persistentvolumelabel} + +{{< feature-state for_k8s_version="v1.13" state="deprecated" >}} This admission controller automatically attaches region or zone labels to PersistentVolumes as defined by the cloud provider (for example, GCE or AWS). @@ -708,7 +722,9 @@ objects in your Kubernetes deployment, you MUST use this admission controller to See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details. -### RuntimeClass {#runtimeclass} {{< feature-state for_k8s_version="v1.16" state="alpha" >}} +### RuntimeClass {#runtimeclass} + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} For [RuntimeClass](/docs/concepts/containers/runtime-class/) definitions which describe an overhead associated with running a pod, this admission controller will set the pod.Spec.Overhead field accordingly. @@ -729,11 +745,15 @@ We strongly recommend using this admission controller if you intend to make use The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information. -### TaintNodesByCondition {#taintnodesbycondition} {{< feature-state for_k8s_version="v1.12" state="beta" >}} +### TaintNodesByCondition {#taintnodesbycondition} + +{{< feature-state for_k8s_version="v1.12" state="beta" >}} This admission controller {{< glossary_tooltip text="taints" term_id="taint" >}} newly created Nodes as `NotReady` and `NoSchedule`. That tainting avoids a race condition that could cause Pods to be scheduled on new Nodes before their taints were updated to accurately reflect their reported conditions. -### ValidatingAdmissionWebhook {#validatingadmissionwebhook} {{< feature-state for_k8s_version="v1.13" state="beta" >}} +### ValidatingAdmissionWebhook {#validatingadmissionwebhook} + +{{< feature-state for_k8s_version="v1.13" state="beta" >}} This admission controller calls any validating webhooks which match the request. Matching webhooks are called in parallel; if any of them rejects the request, the request @@ -773,6 +793,4 @@ phase, and therefore is the last admission controller to run. in the mutating phase. For earlier versions, there was no concept of validating versus mutating and the -admission controllers ran in the exact order specified. - - +admission controllers ran in the exact order specified. \ No newline at end of file diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index 66119cf7b0..8f16a0801e 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -26,6 +26,8 @@ even a file with a list of usernames and passwords. In this regard, _Kubernetes does not have objects which represent normal user accounts._ Normal users cannot be added to a cluster through an API call. +Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this. + In contrast, service accounts are users managed by the Kubernetes API. They are bound to specific namespaces, and created automatically by the API server or manually through API calls. Service accounts are tied to a set of credentials diff --git a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md index fea62e545e..576cde3d88 100644 --- a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md +++ b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md @@ -48,7 +48,7 @@ The CertificateSigningRequest `status.certificate` field is empty until the sign Once the `status.certificate` field has been populated, the request has been completed and clients can now fetch the signed certificate PEM data from the CertificateSigningRequest resource. -Signers can instead deny certificate signing if the approval conditions are not met. +The signers can instead deny certificate signing if the approval conditions are not met. In order to reduce the number of old CertificateSigningRequest resources left in a cluster, a garbage collection controller runs periodically. The garbage collection removes CertificateSigningRequests that have not changed @@ -67,10 +67,10 @@ This includes: 1. **Permitted subjects**: any restrictions on and behavior when a disallowed subject is requested. 1. **Permitted x509 extensions**: including IP subjectAltNames, DNS subjectAltNames, Email subjectAltNames, URI subjectAltNames etc, and behavior when a disallowed extension is requested. 1. **Permitted key usages / extended key usages**: any restrictions on and behavior when usages different than the signer-determined usages are specified in the CSR. -1. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR object etc and behavior if an expiration different than the signer-determined expiration is specified in the CSR. +1. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR object etc and the behavior when an expiration is different than the signer-determined expiration that is specified in the CSR. 1. **CA bit allowed/disallowed**: and behavior if a CSR contains a request a for a CA certificate when the signer does not permit it. -Commonly, the `status.certificate` field contains a single PEM-encoded X.509 certificate once the CSR is approved and the certificate is issued. Some signers store multiple certificates into the `status.certificate` field. In that case, the documentation for the signer should specify the meaning of additional certificates; for example, this might be certificate plus intermediates to be presented during TLS handshakes. +Commonly, the `status.certificate` field contains a single PEM-encoded X.509 certificate once the CSR is approved and the certificate is issued. Some signers store multiple certificates into the `status.certificate` field. In that case, the documentation for the signer should specify the meaning of additional certificates; for example, this might be the certificate plus intermediates to be presented during TLS handshakes. ### Kubernetes signers @@ -88,19 +88,18 @@ Kubernetes provides built-in signers that each have a well-known `signerName`: 1. `kubernetes.io/kube-apiserver-client-kubelet`: signs client certificates that will be honored as client-certs by the kube-apiserver. May be auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}. - 1. Trust distribution: signed certificates must be honored as client-certificates by the kube-apiserver. The CA bundle + 1. Trust distribution: signed certificates must be honored as client-certificates by the kube-apiserver. The CA bundle is not distributed by any other means. 1. Permitted subjects - organizations are exactly `[]string{"system:nodes"}`, common name starts with `"system:node:"` - 1. Permitted x509 extensions - honors key usage extensions, forbids subjectAltName extensions, drops other extensions. + 1. Permitted x509 extensions - honors key usage extensions, forbids subjectAltName extensions and drops other extensions. 1. Permitted key usages - exactly `[]string{"key encipherment", "digital signature", "client auth"}` - 1. Expiration/certificate lifetime - minimum of CSR signer or request. Sanity of the time is the concern of the signer. + 1. Expiration/certificate lifetime - minimum of CSR signer or request. The signer is responsible for checking that the certificate lifetime is valid and permissible. 1. CA bit allowed/disallowed - not allowed. 1. `kubernetes.io/kubelet-serving`: signs serving certificates that are honored as a valid kubelet serving certificate by the kube-apiserver, but has no other guarantees. Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}. - 1. Trust distribution: signed certificates must be honored by the kube-apiserver as valid to terminate connections to a kubelet. - The CA bundle is not distributed by any other means. + 1. Trust distribution: signed certificates must be honored by the kube-apiserver as valid to terminate connections to a kubelet. The CA bundle is not distributed by any other means. 1. Permitted subjects - organizations are exactly `[]string{"system:nodes"}`, common name starts with `"system:node:"` 1. Permitted x509 extensions - honors key usage and DNSName/IPAddress subjectAltName extensions, forbids EmailAddress and URI subjectAltName extensions, drops other extensions. At least one DNS or IP subjectAltName must be present. 1. Permitted key usages - exactly `[]string{"key encipherment", "digital signature", "server auth"}` @@ -108,13 +107,13 @@ Kubernetes provides built-in signers that each have a well-known `signerName`: 1. CA bit allowed/disallowed - not allowed. 1. `kubernetes.io/legacy-unknown`: has no guarantees for trust at all. Some distributions may honor these as client - certs, but that behavior is not standard Kubernetes behavior. + certs, but that behavior is non-standard Kubernetes behavior. Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}. 1. Trust distribution: None. There is no standard trust or distribution for this signer in a Kubernetes cluster. 1. Permitted subjects - any 1. Permitted x509 extensions - honors subjectAltName and key usage extensions and discards other extensions. 1. Permitted key usages - any - 1. Expiration/certificate lifetime - minimum of CSR signer or request. Sanity of the time is the concern of the signer. + 1. Expiration/certificate lifetime - minimum of CSR signer or request. The signer is responsible for checking that the certificate lifetime is valid and permissible. 1. CA bit allowed/disallowed - not allowed. {{< note >}} @@ -226,6 +225,101 @@ rules: - sign ``` +## Normal User + +There are a few steps are required in order to get normal user to be able to authenticate and invoke API. First, this user must have certificate issued by the Kubernetes Cluster, and then present that Certificate into the API call as the Certificate Header, or through the kubectl. + +### Create Private Key + +The following scripts show how to generate PKI private key and CSR. It is important to set CN and O attribute of the CSR. CN is the name of the user and O is the group that this user will belong to. You can refer to [RBAC](/docs/reference/access-authn-authz/rbac/) for standard groups. + +``` +openssl genrsa -out john.key 2048 +openssl req -new -key john.key -out john.csr +``` + +### Create Certificate Request Kubernetes Object + +Create a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the CertificateSigningRequest. + +``` +cat < pod.yaml +kubectl run nginx --image=nginx # Run pod nginx and write its spec into a file called pod.yaml +--dry-run=client -o yaml > pod.yaml kubectl attach my-pod -i # Attach to Running Container kubectl port-forward my-pod 5000:6000 # Listen on port 5000 on the local machine and forward to port 6000 on my-pod diff --git a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md index 513bd77def..af0ba73b90 100644 --- a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -76,9 +76,6 @@ kubectl run [-i] [--tty] --attach --image= Unlike `docker run ...`, if you specify `--attach`, then you attach `stdin`, `stdout` and `stderr`. You cannot control which streams are attached (`docker -a ...`). To detach from the container, you can type the escape sequence Ctrl+P followed by Ctrl+Q. -Because the kubectl run command starts a Deployment for the container, the Deployment restarts if you terminate the attached process by using Ctrl+C, unlike `docker run -it`. -To destroy the Deployment and its pods you need to run `kubectl delete deployment `. - ## docker ps To list what is currently running, see [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get). @@ -191,7 +188,7 @@ docker exec -ti 55c103fa1296 /bin/sh kubectl: ```shell -kubectl exec -ti nginx-app-5jyvm -- /bin/sh +kubectl exec -ti nginx-app-5jyvm -- /bin/sh # exit ``` diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md index abceaf5f70..d83fb98436 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md @@ -59,7 +59,7 @@ kubeadm join phase kubelet-start --help ``` Similar to the [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases) -command, `kubadm join phase` allows you to skip a list of phases using the `--skip-phases` flag. +command, `kubeadm join phase` allows you to skip a list of phases using the `--skip-phases` flag. For example: diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index 575ac4ba5e..77e7bb577a 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -374,16 +374,19 @@ systemctl restart containerd ## Set up the repository ### Install required packages yum install -y yum-utils device-mapper-persistent-data lvm2 +``` ```shell ## Add docker repository yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +``` ```shell ## Install containerd yum update -y && yum install -y containerd.io +``` ```shell ## Configure containerd diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index ace94edad2..1afd13c4e7 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -118,7 +118,7 @@ While `--apiserver-advertise-address` can be used to set the advertise address f control-plane node's API server, `--control-plane-endpoint` can be used to set the shared endpoint for all control-plane nodes. -`--control-plane-endpoint` allows IP addresses but also DNS names that can map to IP addresses. +`--control-plane-endpoint` allows both IP addresses and DNS names that can map to IP addresses. Please contact your network administrator to evaluate possible solutions with respect to such mapping. Here is an example mapping: @@ -531,10 +531,9 @@ Talking to the control-plane node with the appropriate credentials, run: ```bash kubectl drain --delete-local-data --force --ignore-daemonsets -kubectl delete node ``` -Then, on the node being removed, reset all `kubeadm` installed state: +Before removing the node, reset the state installed by `kubeadm`: ```bash kubeadm reset @@ -552,6 +551,11 @@ If you want to reset the IPVS tables, you must run the following command: ipvsadm -C ``` +Now remove the node: +```bash +kubectl delete node +``` + If you wish to start over simply run `kubeadm init` or `kubeadm join` with the appropriate arguments. diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index e06918d7b8..c3e5f57c1c 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -191,7 +191,7 @@ sudo apt-mark hold kubelet kubeadm kubectl {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} ```bash -cat < /etc/yum.repos.d/kubernetes.repo +cat < /etc/systemd/system/kubelet.service -mkdir -p /etc/systemd/system/kubelet.service.d -curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf +curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service +sudo mkdir -p /etc/systemd/system/kubelet.service.d +curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ``` Enable and start `kubelet`: diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md index 8dfcb250ce..af4eb4a101 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md @@ -173,7 +173,7 @@ Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml" the KUBELET_KUBEADM_ARGS variable dynamically EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env # This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, -#the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. +# the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. # KUBELET_EXTRA_ARGS should be sourced from this file. EnvironmentFile=-/etc/default/kubelet ExecStart= @@ -198,9 +198,8 @@ The DEB and RPM packages shipped with the Kubernetes releases are: | Package name | Description | |--------------|-------------| | `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. | -| `kubelet` | Installs the `/usr/bin/kubelet` binary. | +| `kubelet` | Installs the kubelet binary in `/usr/bin` and CNI binaries in `/opt/cni/bin`. | | `kubectl` | Installs the `/usr/bin/kubectl` binary. | -| `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. | | `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). | diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md index 07c0b3c574..64ad3f4b1a 100644 --- a/content/en/docs/setup/production-environment/tools/kubespray.md +++ b/content/en/docs/setup/production-environment/tools/kubespray.md @@ -35,7 +35,7 @@ Provision servers with the following [requirements](https://github.com/kubernete * **Ansible v2.7.8 and python-netaddr is installed on the machine that will run Ansible commands** * **Jinja 2.9 (or newer) is required to run the Ansible Playbooks** -* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/downloads.md#offline-environment)) +* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)) * The target servers are configured to allow **IPv4 forwarding** * **Your ssh key must be copied** to all the servers part of your inventory * The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall diff --git a/content/en/docs/setup/production-environment/turnkey/aws.md b/content/en/docs/setup/production-environment/turnkey/aws.md index 92dd18075c..cbfccd7a56 100644 --- a/content/en/docs/setup/production-environment/turnkey/aws.md +++ b/content/en/docs/setup/production-environment/turnkey/aws.md @@ -23,9 +23,7 @@ To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secr * [Kubernetes Operations](https://github.com/kubernetes/kops) - Production Grade K8s Installation, Upgrades, and Management. Supports running Debian, Ubuntu, CentOS, and RHEL in AWS. -* [CoreOS Tectonic](https://coreos.com/tectonic/) includes the open-source [Tectonic Installer](https://github.com/coreos/tectonic-installer) that creates Kubernetes clusters with Container Linux nodes on AWS. - -* CoreOS originated and the Kubernetes Incubator maintains [a CLI tool, kube-aws](https://github.com/kubernetes-incubator/kube-aws), that creates and manages Kubernetes clusters with [Container Linux](https://coreos.com/why/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling. +* [kube-aws](https://github.com/kubernetes-incubator/kube-aws), creates and manages Kubernetes clusters with [Flatcar Linux](https://www.flatcar-linux.org/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling. * [KubeOne](https://github.com/kubermatic/kubeone) is an open source cluster lifecycle management tool that creates, upgrades and manages Kubernetes Highly-Available clusters. diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md index 7a37fdc20b..6d7c1cced2 100644 --- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -101,12 +101,12 @@ If needed, you can expand the **Advanced options** section where you can specify Example: -```conf -release=1.0 -tier=frontend -environment=pod -track=stable -``` + ```conf + release=1.0 + tier=frontend + environment=pod + track=stable + ``` - **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/). They let you partition resources into logically named groups. diff --git a/content/en/docs/tasks/administer-cluster/change-default-storage-class.md b/content/en/docs/tasks/administer-cluster/change-default-storage-class.md index 453cfef221..9c08a2a4ad 100644 --- a/content/en/docs/tasks/administer-cluster/change-default-storage-class.md +++ b/content/en/docs/tasks/administer-cluster/change-default-storage-class.md @@ -24,7 +24,7 @@ Depending on the installation method, your Kubernetes cluster may be deployed wi an existing StorageClass that is marked as default. This default StorageClass is then used to dynamically provision storage for PersistentVolumeClaims that do not require any specific storage class. See -[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#class-1) +[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) for details. The pre-installed default StorageClass may not fit well with your expected workload; diff --git a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md index 1b29abf17c..5ffc40781a 100644 --- a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md +++ b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md @@ -36,7 +36,7 @@ By default, the kubelet uses [CFS quota](https://en.wikipedia.org/wiki/Completel to enforce pod CPU limits.  When the node runs many CPU-bound pods, the workload can move to different CPU cores depending on whether the pod is throttled and which CPU cores are available at -scheduling time.  Many workloads are not sensitive to this migration and thus +scheduling time. Many workloads are not sensitive to this migration and thus work fine without any intervention. However, in workloads where CPU cache affinity and scheduling latency diff --git a/content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md similarity index 100% rename from content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md rename to content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md diff --git a/content/en/docs/tasks/administer-cluster/namespaces.md b/content/en/docs/tasks/administer-cluster/namespaces.md index a60bbb63a6..1b47b14188 100644 --- a/content/en/docs/tasks/administer-cluster/namespaces.md +++ b/content/en/docs/tasks/administer-cluster/namespaces.md @@ -82,6 +82,10 @@ See the [design doc](https://git.k8s.io/community/contributors/design-proposals/ ## Creating a new namespace +{{< note >}} + Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces. +{{< /note >}} + 1. Create a new YAML file called `my-namespace.yaml` with the contents: ```yaml diff --git a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md index d6aea240c1..60af560e30 100644 --- a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md @@ -57,7 +57,8 @@ The following sysctls are supported in the _safe_ set: - `kernel.shm_rmid_forced`, - `net.ipv4.ip_local_port_range`, -- `net.ipv4.tcp_syncookies`. +- `net.ipv4.tcp_syncookies`, +- `net.ipv4.ping_group_range` (since Kubernetes 1.18). {{< note >}} The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower. diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index ed5aa24044..1630708182 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -332,7 +332,7 @@ to 1 second. Minimum value is 1. * `successThreshold`: Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness. Minimum value is 1. -* `failureThreshold`: When a Pod starts and the probe fails, Kubernetes will +* `failureThreshold`: When a probe fails, Kubernetes will try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready. Defaults to 3. Minimum value is 1. diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md index eaaabb9e94..2486e520e1 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/en/docs/tasks/configure-pod-container/configure-service-account.md @@ -323,7 +323,7 @@ The application is responsible for reloading the token when it rotates. Periodic {{< feature-state for_k8s_version="v1.18" state="alpha" >}} The Service Account Issuer Discovery feature is enabled by enabling the -`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature) +`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature-gates) and then enabling the Service Account Token Projection feature as described [above](#service-account-token-volume-projection). diff --git a/content/en/docs/tasks/debug-application-cluster/falco.md b/content/en/docs/tasks/debug-application-cluster/falco.md index f5f67406a9..2b6eb9323d 100644 --- a/content/en/docs/tasks/debug-application-cluster/falco.md +++ b/content/en/docs/tasks/debug-application-cluster/falco.md @@ -116,6 +116,6 @@ For further details, see [Kubernetes Audit Events][falco_ka_docs] in the Falco d [falco_k8s_audit_rules]: https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml [falco_ka_docs]: https://falco.org/docs/event-sources/kubernetes-audit [falco_installation]: https://falco.org/docs/installation -[falco_helm_chart]: https://github.com/helm/charts/tree/master/stable/falco +[falco_helm_chart]: https://github.com/falcosecurity/charts/tree/master/falco diff --git a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md similarity index 99% rename from content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md rename to content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md index e4b58b70e3..4afbee21c8 100644 --- a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md +++ b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md @@ -4,6 +4,7 @@ reviewers: - madhusudancs title: Configure Multiple Schedulers content_type: task +weight: 20 --- diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md index 6dc61f8d4f..f84744cdd7 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -181,7 +181,8 @@ are preserved as annotations when working with `autoscaling/v1`. When you create a HorizontalPodAutoscaler API object, make sure the name specified is a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). More details about the API object can be found at -[HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object). +[HorizontalPodAutoscaler Object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling). + ## Support for Horizontal Pod Autoscaler in kubectl diff --git a/content/en/docs/tutorials/_index.md b/content/en/docs/tutorials/_index.md index 5551e5a8ea..0deadcd945 100644 --- a/content/en/docs/tutorials/_index.md +++ b/content/en/docs/tutorials/_index.md @@ -70,7 +70,7 @@ Before walking through each tutorial, you may want to bookmark the If you would like to write a tutorial, see -[Content Page Types](/docs/home/contribute/style/page-content-types/) +[Content Page Types](/docs/contribute/style/page-content-types/) for information about the tutorial page type. diff --git a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md index 37f6f9e014..7555a58201 100644 --- a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -93,7 +93,7 @@ Use `kubectl exec` to enter the pod and run the `redis-cli` tool to verify that the configuration was correctly applied: ```shell -kubectl exec -it redis redis-cli +kubectl exec -it redis -- redis-cli 127.0.0.1:6379> CONFIG GET maxmemory 1) "maxmemory" 2) "2097152" diff --git a/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html index 943ef01e0f..86e3621a28 100644 --- a/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -40,7 +40,7 @@ weight: 10
-

You can create from the start a Deployment with multiple instances using the --replicas parameter for the kubectl run command

+

You can create from the start a Deployment with multiple instances using the --replicas parameter for the kubectl create deployment command

diff --git a/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index d43d9b736f..d22d7df5ca 100644 --- a/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -190,8 +190,8 @@ Now you can verify that all objects exist. The response should be like this: ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - wordpress ClusterIP 10.0.0.89 80:32406/TCP 4m + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + wordpress LoadBalancer 10.0.0.89 80:32406/TCP 4m ``` {{< note >}} diff --git a/content/es/docs/concepts/architecture/cloud-controller.md b/content/es/docs/concepts/architecture/cloud-controller.md index 4de5b4418a..b166ca0e80 100644 --- a/content/es/docs/concepts/architecture/cloud-controller.md +++ b/content/es/docs/concepts/architecture/cloud-controller.md @@ -6,13 +6,13 @@ weight: 30 -El concepto del Cloud Controller Manager (CCM) (no confundir con el ejecutable) fue creado originalmente para permitir que Kubernetes y el código específico de proveedores de servicios en la nube evolucionasen de forma independiente. El Cloud Controller Manager se ejecuta a la par con otros componentes maestros como el Kubernetes Controller Manager, el API Server y el planificador. También puede ejecutarse como un extra, en cuyo caso se ejecuta por encima de Kubernetes. +El concepto del Cloud Controller Manager (CCM) (no confundir con el ejecutable) fue creado originalmente para permitir que Kubernetes y el código específico de proveedores de servicios en la nube evolucionen de forma independiente. El Cloud Controller Manager se ejecuta a la par con otros componentes maestros como el Kubernetes Controller Manager, el API Server y el planificador. También puede ejecutarse como un extra, en cuyo caso se ejecuta por encima de Kubernetes. -El diseño del Cloud Controller Manager está basado en un sistema de plugins, lo que permite a nuevos proveedores de servicios integrarse de forma fácil con Kubernetes. Se está trabajando en incorporar nuevos proveedores de servicios y para migrar los existentes del viejo modelo al nuevo CCM. +El diseño del Cloud Controller Manager está basado en un sistema de plugins, lo que permite a nuevos proveedores de servicios integrarse de forma fácil con Kubernetes. Se está trabajando en implementar nuevos proveedores de servicios y para migrar los existentes del antiguo modelo al nuevo CCM. -Este documento describe los conceptos tras el Cloud Controller Manager y da detalles sobre sus funciones asociadas. +Este documento describe los conceptos tras el Cloud Controller Manager y detalla sus funciones asociadas. -En la siguiente imagen, se puede ver la arquitectura de un cluster de Kubernetes que no utiliza el Cloud Controller Manager: +En la siguiente imagen, se puede visualizar la arquitectura de un cluster de Kubernetes que no utiliza el Cloud Controller Manager: ![Arquitectura previa a CCM](/images/docs/pre-ccm-arch.png) @@ -235,4 +235,3 @@ Los siguientes proveedores de servicios en la nube han implementado CCMs: Instrucciones para configurar y ejecutar el CCM pueden encontrarse [aquí](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager). - diff --git a/content/es/docs/concepts/architecture/nodes.md b/content/es/docs/concepts/architecture/nodes.md index 34b0303082..d2313849ef 100644 --- a/content/es/docs/concepts/architecture/nodes.md +++ b/content/es/docs/concepts/architecture/nodes.md @@ -111,7 +111,7 @@ El controlador juega múltiples papeles en la vida de un nodo. El primero es asi El segundo es mantener actualizada la lista interna del controlador con la lista de máquinas disponibles a través del proveedor de servicios en la nube. Cuando Kubernetes se ejecuta en la nube, si un nodo deja de responder, el controlador del nodo preguntará al proveedor si la máquina virtual de dicho nodo continúa estando disponible. Si no lo está, el controlador borrará dicho nodo de su lista interna. -El tercero es el de monitorizar la salud de los nodos. El controlador de nodos es el responsable de actualizar la condición `NodeReady` del campo `NodeStatus` a `ConditionUnknown` cuando un nodo deja de estar accesible (por ejemplo, si deja de recibir señales de vida del nodo indicando que está disponible, conocidas como latidos o `hearbeats` en inglés) y, también es responsable de posteriormente desalojar todos los pods del nodo si este continúa estando inalcanzable. Por defecto, cuando un nodo deja de responder, el controlador sigue re-intentando contactar con el nodo durante 40 segundos antes de marcar el nodo con `ConditionUnknown` y, si el nodo no se recupera de ese estado pasados 5 minutos, empezará a drenar los pods del nodo para desplegarlos en otro nodo que esté disponible. El controlador comprueba el estado de cada nodo cada `--node-monitor-period` segundos. +El tercero es el de monitorizar la salud de los nodos. El controlador de nodos es el responsable de actualizar la condición `NodeReady` del campo `NodeStatus` a `ConditionUnknown` cuando un nodo deja de estar accesible (por ejemplo, si deja de recibir señales de vida del nodo indicando que está disponible, conocidas como latidos o `hearbeats` en inglés) y, también es responsable de posteriormente desalojar todos los pods del nodo si este continúa estando inalcanzable. Por defecto, cuando un nodo deja de responder, el controlador sigue reintentando contactar con el nodo durante 40 segundos antes de marcar el nodo con `ConditionUnknown` y, si el nodo no se recupera de ese estado pasados 5 minutos, empezará a drenar los pods del nodo para desplegarlos en otro nodo que esté disponible. El controlador comprueba el estado de cada nodo cada `--node-monitor-period` segundos. En versiones de Kubernetes previas a 1.13, `NodeStatus` es el `heartbeat` del nodo. Empezando con 1.13 la funcionalidad de `node lease` se introduce como alfa (`NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)). Cuando la funcionalidad está habilitada, cada nodo tiene un objeto `Lease` asociado en el namespace `kube-node-lease` que se renueva periódicamente y ambos, el `NodeStatus` y el `Lease` son considerados como `hearbeats` del nodo. `Node leases` se renuevan con frecuencia, mientras que `NodeStatus` se transmite desde el nodo al máster únicamente si hay cambios o si ha pasado cierto tiempo (por defecto, 1 minuto, que es más que la cuenta atrás por defecto de 40 segundos que marca un nodo como inalcanzable). Al ser los `node lease` más ligeros que `NodeStatus`, los `hearbeats` resultan más económicos desde las perspectivas de escalabilidad y de rendimiento. @@ -123,7 +123,7 @@ En la mayoría de los casos, el controlador de nodos limita el ritmo de desalojo El comportamiento de desalojo de nodos cambia cuando un nodo en una zona de disponibilidad tiene problemas. El controlador de nodos comprobará qué porcentaje de nodos en la zona no se encuentran en buen estado (es decir, que su condición `NodeReady` tiene un valor `ConditionUnknown` o `ConditionFalse`) al mismo tiempo. Si la fracción de nodos con problemas es de al menos `--unhealthy-zone-threshold` (0.55 por defecto) entonces se reduce el ratio de desalojos: si el clúster es pequeño (por ejemplo, tiene menos o los mismos nodos que `--large-cluster-size-threshold` - 50 por defecto) entonces los desalojos se paran. Sino, el ratio se reduce a `--secondary-node-eviction-rate` (0.01 por defecto) por segundo. La razón por la que estas políticas se implementan por zonas de disponibilidad es debido a que una zona puede quedarse aislada del nodo máster mientras que las demás continúan conectadas. Si un clúster no comprende más de una zona, todo el clúster se considera una única zona. La razón principal por la que se distribuyen nodos entre varias zonas de disponibilidad es para que el volumen de trabajo se transfiera a aquellas zonas que se encuentren en buen estado cuando una de las zonas se caiga. -Por consiguiente, si todos los nodos de una zona se encuentran en mal estado, el nodo controlador desaloja al ritmo normal `--node-eviction-rate`. En el caso extremo de que todas las zonas se encuentran en mal estado (es decir, no responda ningún nodo del clúster), el controlador de nodos asume que hay algún tipo de problema con la conectividad del nodo máster y paraliza todos los desalojos hasta que se re-establece la conectividad. +Por consiguiente, si todos los nodos de una zona se encuentran en mal estado, el nodo controlador desaloja al ritmo normal `--node-eviction-rate`. En el caso extremo de que todas las zonas se encuentran en mal estado (es decir, no responda ningún nodo del clúster), el controlador de nodos asume que hay algún tipo de problema con la conectividad del nodo máster y paraliza todos los desalojos hasta que se restablezca la conectividad. Desde la versión 1.6 de Kubernetes el controlador de nodos también es el responsable de desalojar pods que están ejecutándose en nodos con `NoExecute` taints, cuando los pods no permiten dichos taints. De forma adicional, como una funcionalidad alfa que permanece deshabilitada por defecto, el `NodeController` es responsable de añadir taints que se corresponden con problemas en los nodos del tipo nodo inalcanzable o nodo no preparado. En [esta sección de la documentación](/docs/concepts/configuration/taint-and-toleration/) hay más detalles acerca de los taints `NoExecute` y de la funcionalidad alfa. diff --git a/content/es/docs/concepts/overview/what-is-kubernetes.md b/content/es/docs/concepts/overview/what-is-kubernetes.md index 0c53e120c3..4b2d829b1b 100644 --- a/content/es/docs/concepts/overview/what-is-kubernetes.md +++ b/content/es/docs/concepts/overview/what-is-kubernetes.md @@ -49,7 +49,7 @@ una plataforma: para poder construir un ecosistema de componentes y herramientas más fácil el desplegar, escalar y administrar aplicaciones. Las etiquetas, o [Labels](/es/docs/concepts/overview/working-with-objects/labels/), le -permiten a los usuarios organizar sus recursos como deseen. Las anotaciones , o [Annotations](/es/docs/concepts/overview/working-with-objects/annotations/), les permiten asignar información arbitraria a un recurso para +permiten a los usuarios organizar sus recursos como deseen. Las anotaciones, o [Annotations](/es/docs/concepts/overview/working-with-objects/annotations/), les permiten asignar información arbitraria a un recurso para facilitar sus flujos de trabajo y hacer más fácil a las herramientas administrativas inspeccionar el estado. Además, el [Plano de Control](/docs/concepts/overview/components/) de Kubernetes usa las mismas @@ -127,7 +127,7 @@ En resumen, los beneficios de usar contenedores incluyen: * **Ágil creación y despliegue de aplicaciones**: Mayor facilidad y eficiencia al crear imágenes de contenedor en vez de máquinas virtuales -* **Desarrollo, integración y despliegue continuos**: +* **Desarrollo, integración y despliegue continuo**: Permite que la imagen de contenedor se construya y despliegue de forma frecuente y confiable, facilitando los rollbacks pues la imagen es inmutable * **Separación de tareas entre Dev y Ops**: diff --git a/content/es/docs/concepts/workloads/controllers/deployment.md b/content/es/docs/concepts/workloads/controllers/deployment.md new file mode 100644 index 0000000000..2b276f2b1d --- /dev/null +++ b/content/es/docs/concepts/workloads/controllers/deployment.md @@ -0,0 +1,1110 @@ +--- +title: Deployment +feature: + title: Despliegues y _rollback_ automáticos + description: > + Kubernetes despliega los cambios a tu aplicación o su configuración de forma progresiva mientras monitoriza la salud de la aplicación para asegurarse que no elimina todas tus instancias al mismo tiempo. Si algo sale mal, Kubernetes revertirá el cambio por ti. Aprovéchate del creciente ecosistema de soluciones de despliegue. + +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +Un controlador de _Deployment_ proporciona actualizaciones declarativas para los [Pods](/docs/concepts/workloads/pods/pod/) y los +[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/). + +Cuando describes el _estado deseado_ en un objeto Deployment, el controlador del Deployment se encarga de cambiar el estado actual al estado deseado de forma controlada. +Puedes definir Deployments para crear nuevos ReplicaSets, o eliminar Deployments existentes y adoptar todos sus recursos con nuevos Deployments. + +{{< note >}} +No deberías gestionar directamente los ReplicaSets que pertenecen a un Deployment. +Todos los casos de uso deberían cubrirse manipulando el objeto Deployment. +Considera la posibilidad de abrir un incidente en el repositorio principal de Kubernetes si tu caso de uso no está soportado por el motivo que sea. +{{< /note >}} + +{{% /capture %}} + + +{{% capture body %}} + +## Casos de uso + +A continuación se presentan los casos de uso típicos de los Deployments: + +* [Crear un Deployment para desplegar un ReplicaSet](#creating-a-deployment). El ReplicaSet crea los Pods en segundo plano. Comprueba el estado del despliegue para comprobar si es satisfactorio o no. +* [Declarar el nuevo estado de los Pods](#updating-a-deployment) actualizando el PodTemplateSpec del Deployment. Ello crea un nuevo ReplicaSet y el Deployment gestiona el cambio de los Pods del viejo ReplicaSet al nuevo de forma controlada. Cada nuevo ReplicaSet actualiza la revisión del Deployment. +* [Retroceder a una revisión anterior del Deployment](#rolling-back-a-deployment) si el estado actual de un Deployment no es estable. Cada retroceso actualiza la revisión del Deployment. +* [Escalar horizontalmente el Deployment para soportar más carga](#scaling-a-deployment). +* [Pausar el Deployment](#pausing-and-resuming-a-deployment) para aplicar múltiples arreglos a su PodTemplateSpec y, a continuación, reanúdalo para que comience un nuevo despliegue. +* [Usar el estado del Deployment](#deployment-status) como un indicador de que el despliegue se ha atascado. +* [Limpiar los viejos ReplicaSets](#clean-up-policy) que no necesites más. + +## Crear un Deployment + +El siguiente ejemplo de un Deployment crea un ReplicaSet para arrancar tres Pods con `nginx`: + +{{< codenew file="controllers/nginx-deployment.yaml" >}} + +En este ejemplo: + +* Se crea un Deployment denominado `nginx-deployment`, indicado a través del campo `.metadata.name`. +* El Deployment crea tres Pods replicados, indicado a través del campo `replicas`. +* El campo `selector` define cómo el Deployment identifica los Pods que debe gestionar. + En este caso, simplemente seleccionas una etiqueta que se define en la plantilla Pod (`app: nginx`). + Sin embargo, es posible definir reglas de selección más sofisticadas, + siempre que la plantilla Pod misma satisfaga la regla. + + {{< note >}} + `matchLabels` es un mapa de entradas {clave,valor}. Una entrada simple {clave,valor} en el mapa `matchLabels` + es equivalente a un elemento de `matchExpressions` cuyo campo sea la "clave", el operador sea "In", + y la matriz de valores contenga únicamente un "valor". Todos los requisitos se concatenan con AND. + {{< /note >}} + +* El campo `template` contiene los siguientes sub-campos: + * Los Pods se etiquetan como `app: nginx` usando el campo `labels`. + * La especificación de la plantilla Pod, o el campo `.template.spec`, indica + que los Pods ejecutan un contenedor, `nginx`, que utiliza la versión 1.7.9 de la imagen de `nginx` de + [Docker Hub](https://hub.docker.com/). + * Crea un contenedor y lo llamar `nginx` usando el campo `name`. + * Ejecuta la imagen `nginx` en su versión `1.7.9`. + * Abre el puerto `80` para que el contenedor pueda enviar y recibir tráfico. + +Para crear este Deployment, ejecuta el siguiente comando: + +```shell +kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml +``` + +{{< note >}} +Debes indicar el parámetro `--record` para registrar el comando ejecutado en la anotación de recurso `kubernetes.io/change-cause`. +Esto es útil para futuras introspecciones, por ejemplo para comprobar qué comando se ha ejecutado en cada revisión del Deployment. +{{< /note >}} + +A continuación, ejecuta el comando `kubectl get deployments`. La salida debe ser parecida a la siguiente: + +```shell +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 3 0 0 0 1s +``` + +Cuando inspeccionas los Deployments de tu clúster, se muestran los siguientes campos: + +* `NAME` enumera los nombre de los Deployments del clúster. +* `DESIRED` muestra el número deseado de _réplicas_ de la aplicación, que se define + cuando se crea el Deployment. Esto se conoce como el _estado deseado_. +* `CURRENT` muestra cuántas réplicas se están ejecutando actualment. +* `UP-TO-DATE` muestra el número de réplicas que se ha actualizado para alcanzar el estado deseado. +* `AVAILABLE` muestra cuántas réplicas de la aplicación están disponibles para los usuarios. +* `AGE` muestra la cantidad de tiempo que la aplicación lleva ejecutándose. + +Nótese cómo los valores de cada campo corresponden a los valores de la especificación del Deployment: + +* El número de réplicas deseadas es 3 de acuerdo con el campo `.spec.replicas`. +* El número de réplicas actuales es 0 de acuerdo con el campo `.status.replicas`. +* El número de réplicas actualizadas es 0 de acuerdo con el campo `.status.updatedReplicas`. +* El número de réplicas disponibles es 0 de acuerdo con el campo `.status.availableReplicas`. + +Para ver el estado del Deployment, ejecuta el comando `kubectl rollout status deployment.v1.apps/nginx-deployment`. Este comando devuelve el siguiente resultado: + +```shell +Waiting for rollout to finish: 2 out of 3 new replicas have been updated... +deployment.apps/nginx-deployment successfully rolled out +``` + +Ejecuta de nuevo el comando `kubectl get deployments` unos segundos más tarde: + +```shell +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 3 3 3 3 18s +``` + +Fíjate que el Deployment ha creado todas las tres réplicas, y que todas las réplicas están actualizadas (contienen +la última plantilla Pod) y están disponibles (el estado del Pod tiene el valor Ready al menos para el campo `.spec.minReadySeconds` del Deployment). + +Para ver el ReplicaSet (`rs`) creado por el Deployment, ejecuta el comando `kubectl get rs`: + +```shell +NAME DESIRED CURRENT READY AGE +nginx-deployment-75675f5897 3 3 3 18s +``` + +Fíjate que el nombre del ReplicaSet siempre se formatea con el patrón `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. La cadena aleatoria se +genera de forma aleatoria y usa el pod-template-hash como semilla. + +Para ver las etiquetas generadas automáticamente en cada pod, ejecuta el comando `kubectl get pods --show-labels`. Se devuelve la siguiente salida: + +```shell +NAME READY STATUS RESTARTS AGE LABELS +nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 +nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 +nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 +``` + +El ReplicaSet creado garantiza que hay tres Pods de `nginx` ejecutándose en todo momento. + +{{< note >}} +En un Deployment, debes especificar un selector apropiado y etiquetas de plantilla Pod (en este caso, +`app: nginx`). No entremezcles etiquetas o selectores con otros controladores (incluyendo otros Deployments y StatefulSets). +Kubernetes no te impide que lo hagas, pero en el caso de que múltiples controladores tengan selectores mezclados, dichos controladores pueden entrar en conflicto y provocar resultados inesperados. +{{< /note >}} + +### Etiqueta pod-template-hash + +{{< note >}} +No cambies esta etiqueta. +{{< /note >}} + +La etiqueta `pod-template-hash` es añadida por el controlador del Deployment a cada ReplicaSet que el Deployment crea o adopta. + +Esta etiqueta garantiza que todos los hijos ReplicaSets de un Deployment no se entremezclan. Se genera mediante una función hash aplicada al `PodTemplate` del ReplicaSet +y usando el resultado de la función hash como el valor de la etiqueta que se añade al selector del ReplicaSet, en las etiquetas de la plantilla Pod, +y en cualquier Pod existente que el ReplicaSet tenga. + +## Actualizar un Deployment + +{{< note >}} +El lanzamiento de un Deployment se activa si y sólo si la plantilla Pod del Deployment (esto es, `.spec.template`) +se cambia, por ejemplo si se actualiza las etiquetas o las imágenes de contenedor de la plantilla. +Otras actualizaciones, como el escalado del Deployment, no conllevan un lanzamiento de despliegue. +{{< /note >}} + +Asumiendo que ahora quieres actualizar los Pods nginx para que usen la imagen `nginx:1.9.1` +en vez de la imagen `nginx:1.7.9`. + +```shell +kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 +``` +``` +image updated +``` + +De forma alternativa, puedes `editar` el Deployment y cambiar el valor del campo `.spec.template.spec.containers[0].image` de `nginx:1.7.9` a `nginx:1.9.1`: + +```shell +kubectl edit deployment.v1.apps/nginx-deployment +``` +``` +deployment.apps/nginx-deployment edited +``` + +Para ver el estado del despliegue, ejecuta: + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +``` +Waiting for rollout to finish: 2 out of 3 new replicas have been updated... +deployment.apps/nginx-deployment successfully rolled out +``` + +Cuando el despliegue funciona, puede que quieras `obtener` el Deployment: + +```shell +kubectl get deployments +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 3 3 3 3 36s +``` + +El número de réplicas actualizadas indica que el Deployment ha actualizado las réplicas según la última configuración. +Las réplicas actuales indican el total de réplicas que gestiona este Deployment, y las réplicas disponibles indican +el número de réplicas actuales que están disponibles. + +Puedes ejecutar el comando `kubectl get rs` para ver que el Deployment actualizó los Pods creando un nuevo ReplicaSet y escalándolo +hasta las 3 réplicas, así como escalando el viejo ReplicaSet a 0 réplicas. + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-deployment-1564180365 3 3 3 6s +nginx-deployment-2035384211 0 0 0 36s +``` + +Si ejecutas el comando `get pods` deberías ver los nuevos Pods: + +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +nginx-deployment-1564180365-khku8 1/1 Running 0 14s +nginx-deployment-1564180365-nacti 1/1 Running 0 14s +nginx-deployment-1564180365-z9gth 1/1 Running 0 14s +``` + +La próxima vez que quieras actualizar estos Pods, sólo necesitas actualizar la plantilla Pod del Deployment otra vez. + +El Deployment permite garantizar que sólo un número determinado de Pods puede eliminarse mientras se están actualizando. +Por defecto, garantiza que al menos el 25% menos del número deseado de Pods se está ejecutando (máx. 25% no disponible). + +El Deployment tmabién permite garantizar que sólo un número determinado de Pods puede crearse por encima del número deseado de +Pods. Por defecto, garantiza que al menos el 25% más del número deseado de Pods se está ejecutando (máx. 25% de aumento). + +Por ejemplo, si miras detenidamente el Deployment de arriba, verás que primero creó un Pod, +luego eliminó algunos viejos Pods y creó otros nuevos. No elimina los viejos Pods hasta que un número suficiente de +nuevos Pods han arrancado, y no crea nuevos Pods hasta que un número suficiente de viejos Pods se han eliminado. +De esta forma, asegura que el número de Pods disponibles siempre es al menos 2, y el número de Pods totales es cómo máximo 4. + +```shell +kubectl describe deployments +``` +``` +Name: nginx-deployment +Namespace: default +CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000 +Labels: app=nginx +Annotations: deployment.kubernetes.io/revision=2 +Selector: app=nginx +Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable +StrategyType: RollingUpdate +MinReadySeconds: 0 +RollingUpdateStrategy: 25% max unavailable, 25% max surge +Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + Environment: + Mounts: + Volumes: +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable +OldReplicaSets: +NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created) +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-2035384211 to 3 + Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1 + Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2 + Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2 + Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1 + Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3 + Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0 +``` + +Aquí puedes ver que cuando creaste por primera vez el Deployment, este creó un ReplicaSet (nginx-deployment-2035384211) +y lo escaló a 3 réplicas directamente. Cuando actualizaste el Deployment, creó un nuevo ReplicaSet +(nginx-deployment-1564180365) y lo escaló a 1 y entonces escaló el viejo ReplicaSet a 2, de forma que al menos +hubiera 2 Pods disponibles y como mucho 4 Pods en total en todo momento. Entonces, continuó escalando +el nuevo y el viejo ReplicaSet con la misma estrategia de actualización continua. Finalmente, el nuevo ReplicaSet acaba con 3 réplicas +disponibles, y el viejo ReplicaSet se escala a 0. + +### Sobrescritura (o sea, múltiples actualizaciones a la vez) + +Cada vez que el controlador del Deployment observa un nuevo objeto de despliegue, se crea un ReplicaSet para arrancar +los Pods deseados si es que no existe otro ReplicaSet haciéndolo. Los ReplicaSet existentes que controlan los Pods cuyas etiquetas +coinciden con el valor del campo `.spec.selector`, pero cuya plantilla no coincide con el valor del campo `.spec.template` se reducen. Al final, +el nuevo ReplicaSet se escala hasta el valor del campo `.spec.replicas` y todos los viejos ReplicaSets se escalan a 0. + +Si actualizas un Deployment mientras otro despliegue está en curso, el Deployment creará un nuevo ReplicaSet +como consecuencia de la actualización y comenzará a escalarlo, y sobrescribirá al ReplicaSet que estaba escalando anteriormente + -- lo añadirá a su lista de viejos ReplicaSets y comenzará a reducirlos. + +Por ejemplo, supongamos que creamos un Deployment para crear 5 réplicas de `nginx:1.7.9`, +pero entonces actualizamos el Deployment para crear 5 réplicas de `nginx:1.9.1` cuando sólo se ha creado 3 +réplicas de `nginx:1.7.9`. En este caso, el Deployment comenzará automáticamente a matar los 3 Pods de `nginx:1.7.9` +que había creado, y empezará a crear los Pods de `nginx:1.9.1`. Es decir, no esperará a que se creen las 5 réplicas de `nginx:1.7.9` +antes de aplicar la nueva configuración. + +### Actualizaciones del selector de etiquetas + +No se recomienda hacer cambios al selector del etiquetas y, por ello, se aconseja encarecidamente planificar el valor de dichos selectores por adelantado. +En cualquier caso, si necesitas cambiar un selector de etiquetas, hazlo con mucho cuidado y asegúrate que entiendes todas sus implicaciones. + +{{< note >}} +En la versión `apps/v1` de la API, el selector de etiquetas del Deployment es inmutable una vez se ha creado. +{{< /note >}} + +* Las adiciones posteriores al selector obligan también a actualizar las etiquetas de la plantilla Pod en la especificación del Deployment con los nuevos valores, +ya que de lo contrario se devolvería un error. Este cambio no es de superposición, es decir, que el nuevo selector +no selecciona los ReplicaSets y Pods creados con el viejo selector, lo que provoca que todos los viejos ReplicaSets se marquen como huérfanos y +la creación de un nuevo ReplicaSet. +* Las actualizaciones de selector -- esto es, cambiar el valor actual en una clave de selector -- provocan el mismo comportamiento que las adiciones. +* Las eliminaciones de selector -- esto es, eliminar una clave actual del selector del Deployment -- no necesitan de cambios en las etiquetas de la plantilla Pod. +No se marca ningún ReplicaSet existente como huérfano, y no se crea ningún ReplicaSet nuevo, pero debe tenerse en cuenta que +la etiqueta eliminada todavía existe en los Pods y ReplicaSets que se están ejecutando. + +## Revertir un Deployment + +En ocasiones necesitas revertir un Deployment; por ejemplo, cuando el Deployment no es estable, como cuando no para de reiniciarse. +Por defecto, toda la historia de despliegue del Deployment se mantiene en el sistema de forma que puedes revertir en cualquier momento +(se puede modificar este comportamiento cambiando el límite de la historia de revisiones de modificaciones). + +{{< note >}} +Cuando se lanza el despligue de un Deployment, se crea una nueva revisión. Esto quiere decir que +la nueva revisión se crea si y sólo si la plantilla Pod del Deployment (`.spec.template`) se cambia; +por ejemplo, si cambias las etiquetas o la imagen del contenedor de la plantilla. +Otras actualizaciones, como escalar el Deployment, +no generan una nueva revisión del Deployment, para poder facilitar el escalado manual simultáneo - o auto-escalado. +Esto significa que cuando reviertes a una versión anterior, sólo la parte de la plantilla Pod del Deployment se revierte. +{{< /note >}} + +Vamos a suponer que hemos cometido un error al actualizar el Deployment, poniendo como nombre de imagen `nginx:1.91` en vez de `nginx:1.9.1`: + +```shell +kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true +``` +``` +deployment.apps/nginx-deployment image updated +``` + +El despliegue se atasca y no progresa. + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +``` +Waiting for rollout to finish: 1 out of 3 new replicas have been updated... +``` + +Presiona Ctrl-C para detener la monitorización del despliegue de arriba. Para obtener más información sobre despliegues atascados, +[lee más aquí](#deployment-status). + +Verás que el número de réplicas viejas (nginx-deployment-1564180365 y nginx-deployment-2035384211) es 2, y el número de nuevas réplicas (nginx-deployment-3066724191) es 1. + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-deployment-1564180365 3 3 3 25s +nginx-deployment-2035384211 0 0 0 36s +nginx-deployment-3066724191 1 1 0 6s +``` + +Echando un vistazo a los Pods creados, verás que uno de los Pods creados por el nuevo ReplicaSet está atascado en un bucle intentando bajar la imagen: + +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +nginx-deployment-1564180365-70iae 1/1 Running 0 25s +nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s +nginx-deployment-1564180365-hysrc 1/1 Running 0 25s +nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s +``` + +{{< note >}} +El controlador del Deployment parará el despliegue erróneo de forma automática, y detendrá el escalado del nuevo +ReplicaSet. Esto depende de los parámetros del rollingUpdate (`maxUnavailable` específicamente) que hayas configurado. +Kubernetes por defecto establece el valor en el 25%. +{{< /note >}} + +```shell +kubectl describe deployment +``` +``` +Name: nginx-deployment +Namespace: default +CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700 +Labels: app=nginx +Selector: app=nginx +Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable +StrategyType: RollingUpdate +MinReadySeconds: 0 +RollingUpdateStrategy: 25% max unavailable, 25% max surge +Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.91 + Port: 80/TCP + Host Port: 0/TCP + Environment: + Mounts: + Volumes: +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated +OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created) +NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created) +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 1 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1 +``` + +Para arreglar este problema, necesitas volver a una revisión previa del Deployment que sea estable. + +### Comprobar la Historia de Despliegues de un Deployment + +Primero, comprobemos las revisiones de este despliegue: + +```shell +kubectl rollout history deployment.v1.apps/nginx-deployment +``` +``` +deployments "nginx-deployment" +REVISION CHANGE-CAUSE +1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true +2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true +3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true +``` +En el momento de la creación, el mensaje en `CHANGE-CAUSE` se copia de la anotación `kubernetes.io/change-cause` del Deployment a sus revisiones. Podrías indicar el mensaje `CHANGE-CAUSE`: + +* Anotando el Deployment con el comando `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"` +* Añadiendo el parámetro `--record` para registrar el comando `kubectl` que está haciendo cambios en el recurso. +* Manualmente editando el manifiesto del recursos. + +Para ver más detalles de cada revisión, ejecuta: + +```shell +kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2 +``` +``` +deployments "nginx-deployment" revision 2 + Labels: app=nginx + pod-template-hash=1159050644 + Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + QoS Tier: + cpu: BestEffort + memory: BestEffort + Environment Variables: + No volumes. +``` + +### Retroceder a una Revisión Previa + +Ahora has decidido que quieres deshacer el despliegue actual y retrocederlo a la revisión previa: + +```shell +kubectl rollout undo deployment.v1.apps/nginx-deployment +``` +``` +deployment.apps/nginx-deployment +``` + +Alternativamente, puedes retroceder a una revisión específica con el parámetro `--to-revision`: + +```shell +kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2 +``` +``` +deployment.apps/nginx-deployment +``` + +Para más detalles acerca de los comandos relacionados con las revisiones de un Deployment, echa un vistazo a [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout). + +El Deployment se ha revertido ahora a una revisión previa estable. Como se puede comprobar, el controlador del Deployment genera un evento `DeploymentRollback` +al retroceder a la revisión 2. + +```shell +kubectl get deployment nginx-deployment +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 3 3 3 3 30m +``` + +```shell +kubectl describe deployment nginx-deployment +``` +``` +Name: nginx-deployment +Namespace: default +CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500 +Labels: app=nginx +Annotations: deployment.kubernetes.io/revision=4 + kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true +Selector: app=nginx +Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable +StrategyType: RollingUpdate +MinReadySeconds: 0 +RollingUpdateStrategy: 25% max unavailable, 25% max surge +Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.9.1 + Port: 80/TCP + Host Port: 0/TCP + Environment: + Mounts: + Volumes: +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable +OldReplicaSets: +NewReplicaSet: nginx-deployment-c4747d96c (3/3 replicas created) +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set nginx-deployment-75675f5897 to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 0 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-595696685f to 1 + Normal DeploymentRollback 15s deployment-controller Rolled back deployment "nginx-deployment" to revision 2 + Normal ScalingReplicaSet 15s deployment-controller Scaled down replica set nginx-deployment-595696685f to 0 +``` + +## Escalar un Deployment + +Puedes escalar un Deployment usando el siguiente comando: + +```shell +kubectl scale deployment.v1.apps/nginx-deployment --replicas=10 +``` +``` +deployment.apps/nginx-deployment scaled +``` + +Asumiendo que se ha habilitado el [escalado horizontal de pod](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) +en tu clúster, puedes configurar un auto-escalado para tu Deployment y elegir el mínimo y máximo número de Pods +que quieres ejecutar en base al uso de CPU de tus Pods actuales. + +```shell +kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80 +``` +``` +deployment.apps/nginx-deployment scaled +``` + +### Escalado proporcional + +La actualización continua de los Deployments permite la ejecución de múltiples versiones de una aplicación al mismo tiempo. +Cuando tú o un auto-escalado escala un Deployment con actualización continua que está en medio de otro despliegue (bien en curso o pausado), +entonces el controlador del Deployment balanceará las réplicas adicionales de los ReplicaSets activos (ReplicaSets con Pods) +para así poder mitigar el riesgo. Esto se conoce como *escalado proporcional*. + +Por ejemplo, imagina que estás ejecutando un Deployment con 10 réplicas, donde [maxSurge](#max-surge)=3, y [maxUnavailable](#max-unavailable)=2. + +```shell +kubectl get deploy +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 10 10 10 10 50s +``` + +Si actualizas a una nueva imagen que no puede descargarse desde el clúster: + +```shell +kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag +``` +``` +deployment.apps/nginx-deployment image updated +``` + +La actualización de la imagen arranca un nuevo despliegue con el ReplicaSet nginx-deployment-1989198191, +pero se bloquea debido al requisito `maxUnavailable` indicado arriba: + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-deployment-1989198191 5 5 0 9s +nginx-deployment-618515232 8 8 8 1m +``` + +Y entonces se origina una nueva petición de escalado para el Deployment. El auto-escalado incrementa las réplicas del Deployment +a 15. El controlador del Deployment necesita ahora decidir dónde añadir esas nuevas 5 réplicas. +Si no estuvieras usando el escalado proporcional, las 5 se añadirían al nuevo ReplicaSet. Pero con el escalado proporcional, +las réplicas adicionales se distribuyen entre todos los ReplicaSets. Las partes más grandes van a los ReplicaSets +con el mayor número de réplicas y las partes más pequeñas van a los ReplicaSets con menos réplicas. Cualquier resto sobrante se añade +al ReplicaSet con mayor número de réplicas. Aquellos ReplicaSets con 0 réplicas no se escalan. + +En nuestro ejemplo anterior, se añadirán 3 réplicas al viejo ReplicaSet y 2 réplicas al nuevo ReplicaSet. +EL proceso de despliegue debería al final mover todas las réplicas al nuevo ReplicaSet, siempre que las nuevas +réplicas arranquen positivamente. + +```shell +kubectl get deploy +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 15 18 7 8 7m +``` + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-deployment-1989198191 7 7 0 7m +nginx-deployment-618515232 11 11 11 7m +``` + +## Pausar y Reanudar un Deployment + +Puedes pausar un Deployment antes de arrancar una o más modificaciones y luego reanudarlo. Esto te permite aplicar múltiples arreglos +entre la pausa y la reanudación sin necesidad de arrancar despliegues innecesarios. + +Por ejemplo, con un Deployment que acaba de crearse: + +```shell +kubectl get deploy +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx 3 3 3 3 1m +``` +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-2142116321 3 3 3 1m +``` + +Lo pausamos ejecutando el siguiente comando: + +```shell +kubectl rollout pause deployment.v1.apps/nginx-deployment +``` +``` +deployment.apps/nginx-deployment paused +``` + +Y luego actualizamos la imagen del Deployment: + +```shell +kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 +``` +``` +deployment.apps/nginx-deployment image updated +``` + +Nótese que no se arranca ningún despliegue nuevo: + +```shell +kubectl rollout history deployment.v1.apps/nginx-deployment +``` +``` +deployments "nginx" +REVISION CHANGE-CAUSE +1 +``` + +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-2142116321 3 3 3 2m +``` + +Puedes realizar tantas modificaciones como quieras, por ejemplo, para actualizar los recursos a utilizar: + +```shell +kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi +``` +``` +deployment.apps/nginx-deployment resource requirements updated +``` + +El estado inicial del Deployment anterior a la pausa continuará su función, pero las nuevas modificaciones +del Deployment no tendrán efecto ya que el Deployment está pausado. + +Al final, reanuda el Deployment y observa cómo se genera un nuevo ReplicaSet con todos los cambios: + +```shell +kubectl rollout resume deployment.v1.apps/nginx-deployment +``` + +``` +deployment.apps/nginx-deployment resumed +``` + +```shell +kubectl get rs -w +``` + +``` +NAME DESIRED CURRENT READY AGE +nginx-2142116321 2 2 2 2m +nginx-3926361531 2 2 0 6s +nginx-3926361531 2 2 1 18s +nginx-2142116321 1 2 2 2m +nginx-2142116321 1 2 2 2m +nginx-3926361531 3 2 1 18s +nginx-3926361531 3 2 1 18s +nginx-2142116321 1 1 1 2m +nginx-3926361531 3 3 1 18s +nginx-3926361531 3 3 2 19s +nginx-2142116321 0 1 1 2m +nginx-2142116321 0 1 1 2m +nginx-2142116321 0 0 0 2m +nginx-3926361531 3 3 3 20s + +``` +```shell +kubectl get rs +``` +``` +NAME DESIRED CURRENT READY AGE +nginx-2142116321 0 0 0 2m +nginx-3926361531 3 3 3 28s +``` + +{{< note >}} +No se puede revertir un Deployment pausado hasta que se vuelve a reanudar. +{{< /note >}} + +## Estado del Deployment + +Un Deployment pasa por varios estados a lo largo de su ciclo de vida. Así, puede estar [progresando](#progressing-deployment) mientras +se despliega un nuevo ReplicaSet, puede estar [completo](#complete-deployment), o puede quedar en estado [fallido](#failed-deployment). + +### Progresar un Deployment + +Kubernetes marca un Deployment como _progresando_ cuando se realiza cualquiera de las siguientes tareas: + +* El Deployment crea un nuevo ReplicaSet. +* El Deployment está escalando su ReplicaSet más nuevo. +* El Deployment está reduciendo su(s) ReplicaSet(s) más antiguo(s). +* Hay nuevos Pods disponibles y listos (listo por lo menos [MinReadySeconds](#min-ready-seconds)). + +Puedes monitorizar el progreso de un Deployment usando el comando `kubectl rollout status`. + +### Completar un Deployment + +Kubernetes marca un Deployment como _completado_ cuando presenta las siguientes características: + +* Todas las réplicas asociadas con el Deployment han sido actualizadas a la última versión indicada, lo cual quiere decir +que todas las actualizaciones se han completado. +* Todas las réplicas asociadas con el Deployment están disponibles. +* No están ejecutándose viejas réplicas del Deployment. + +Puedes comprobar si un Deployment se ha completado usando el comando `kubectl rollout status`. Si el despliegue se ha completado +de forma satisfactoria, el comando `kubectl rollout status` devuelve un código 0 de salida. + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +``` +Waiting for rollout to finish: 2 of 3 updated replicas are available... +deployment.apps/nginx-deployment successfully rolled out +$ echo $? +0 +``` + +### Deployment fallido + +Tu Deployment puede quedarse bloqueado intentando desplegar su nuevo ReplicaSet sin nunca completarse. Esto puede ocurrir +debido a algunos de los factores siguientes: + +* Cuota insuficiente +* Fallos en la prueba de estar listo +* Errores en la descarga de imágenes +* Permisos insuficientes +* Rangos de límites de recursos +* Mala configuración del motor de ejecución de la aplicación + +Una forma de detectar este tipo de situación es especificar un parámetro de vencimiento en la especificación de tu Deployment: +([`.spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `.spec.progressDeadlineSeconds` denota el número +de segundos que el controlador del Deployment debe esperar antes de indicar (en el estado del Deployment) que el +Deployment no avanza. + +El siguiente comando `kubectl` configura el campo `progressDeadlineSeconds` para forzar al controlador a +informar de la falta de avance de un Deployment después de 10 minutos: + +```shell +kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' +``` +``` +deployment.apps/nginx-deployment patched +``` +Una vez que se ha excedido el vencimiento, el controlador del Deployment añade una DeploymentCondition +con los siguientes atributos al campo `.status.conditions` del Deployment: + +* Type=Progressing +* Status=False +* Reason=ProgressDeadlineExceeded + +Ver las [convenciones de la API de Kubernetes](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) para más información acerca de las condiciones de estado. + +{{< note >}} +Kubernetes no emprenderá ninguna acción ante un Deployment parado que no sea la de reportar el estado mediante +`Reason=ProgressDeadlineExceeded`. Los orquestradores de alto nivel pueden aprovecharse y actuar consecuentemente, por ejemplo, +retrocediendo el Deployment a su versión previa. +{{< /note >}} + +{{< note >}} +Si pausas un Deployment, Kubernetes no comprueba el avance en base al vencimiento indicado. Así, es posible pausar +de forma segura un Deployment en medio de un despliegue y reanudarlo sin que se arranque el estado de exceso de vencimiento. +{{< /note >}} + +Puede que notes errores transitorios en tus Deployments, bien debido a un tiempo de vencimiento muy pequeño que hayas configurado +o bien a cualquier otro tipo de error que puede considerarse como transitorio. Por ejemplo, +supongamos que no tienes suficiente cuota. Si describes el Deployment, te darás cuenta de la sección siguiente: + +```shell +kubectl describe deployment nginx-deployment +``` +``` +<...> +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated + ReplicaFailure True FailedCreate +<...> +``` + +Si ejecutas el comando `kubectl get deployment nginx-deployment -o yaml`, el estado del Deployment puede parecerse a: + +``` +status: + availableReplicas: 2 + conditions: + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: Replica set "nginx-deployment-4262182780" is progressing. + reason: ReplicaSetUpdated + status: "True" + type: Progressing + - lastTransitionTime: 2016-10-04T12:25:42Z + lastUpdateTime: 2016-10-04T12:25:42Z + message: Deployment has minimum availability. + reason: MinimumReplicasAvailable + status: "True" + type: Available + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota: + object-counts, requested: pods=1, used: pods=3, limited: pods=2' + reason: FailedCreate + status: "True" + type: ReplicaFailure + observedGeneration: 3 + replicas: 2 + unavailableReplicas: 2 +``` + +Al final, una vez que se supera el vencimiento del progreso del Deployment, Kubernetes actualiza el estado +y la razón de el estado de progreso: + +``` +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing False ProgressDeadlineExceeded + ReplicaFailure True FailedCreate +``` + +Puedes solucionar un problema de cuota insuficiente simplemente reduciendo el número de réplicas de tu Deployment, reduciendo +otros controladores que puedas estar ejecutando, o incrementando la cuota en tu espacio de nombres. Si una vez satisfechas las condiciones de tu cuota, +el controlador del Deployment completa el despliegue, entonces verás que el estado del Deployment se actualiza al estado satisfactorio (`Status=True` y `Reason=NewReplicaSetAvailable`). + +``` +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable +``` + +`Type=Available` con `Status=True` significa que tu Deployment tiene disponibilidad mínima. La disponibilidad mínima se prescribe +mediante los parámetros indicados en la estrategia de despligue. `Type=Progressing` con `Status=True` significa que tu Deployment +está bien en medio de un despliegue y está progresando o bien que se ha completado de forma satisfactoria y el número mínimo +requerido de nuevas réplicas ya está disponible (ver la Razón del estado para cada caso particular - en nuestro caso +`Reason=NewReplicaSetAvailable` significa que el Deployment se ha completado). + +Puedes comprobar si un Deployment ha fallado en su progreso usando el comando `kubectl rollout status`. `kubectl rollout status` +devuelve un código de salida distinto de 0 si el Deployment ha excedido su tiempo de vencimiento. + +```shell +kubectl rollout status deployment.v1.apps/nginx-deployment +``` +``` +Waiting for rollout to finish: 2 out of 3 new replicas have been updated... +error: deployment "nginx" exceeded its progress deadline +$ echo $? +1 +``` + +### Actuar ante un despliegue fallido + +Todas las acciones que aplican a un Deployment completado también aplican a un Deployment fallido. Puedes escalarlo/reducirlo, retrocederlo +a una revisión previa, o incluso pausarlo si necesitas realizar múltiples cambios a la plantilla Pod del Deployment. + +## Regla de Limpieza + +Puedes configurar el campo `.spec.revisionHistoryLimit` de un Deployment para especificar cuántos ReplicaSets viejos quieres conservar +para este Deployment. El resto será eliminado en segundo plano. Por defecto, es 10. + +{{< note >}} +Poner este campo de forma explícita a 0 resulta en la limpieza de toda la historia de tu Deployment, +por lo que tu Deployment no podrá retroceder a revisiones previas. +{{< /note >}} + +## Casos de Uso + +### Despligue Canary + +Si quieres desplegar nuevas versiones a un sub-conjunto de usuarios o servidores usando el Deployment, +puedes hacerlo creando múltiples Deployments, uno para cada versión nueva, siguiendo el patrón canary descrito en +[gestionar recursos](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments). + +## Escribir una especificación de Deployment + +Al igual que con el resto de configuraciones de Kubernetes, un Deployment requiere los campos `apiVersion`, `kind`, y `metadata`. +Para información general acerca de cómo trabajar con ficheros de configuración, ver los documentos acerca de [desplegar aplicaciones](/docs/tutorials/stateless-application/run-stateless-application-deployment/), +configurar contenedores, y [usar kubectl para gestionar recursos](/docs/concepts/overview/object-management-kubectl/overview/). + +Un Deployment también necesita una [sección `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Plantilla Pod + +Tanto `.spec.template` como `.spec.selector` sin campos obligatorios dentro de `.spec`. + +El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [Pod](/docs/concepts/workloads/pods/pod/), +excepto por el hecho de que está anidado y no tiene `apiVersion` ni `kind`. + +Junto con los campos obligatorios de un Pod, una plantilla Pod de un Deployment debe indicar las etiquetas +y las reglas de reinicio apropiadas. Para el caso de las etiquetas, asegúrate que no se entremezclan con otros controladores. Ver [selector](#selector)). + +Únicamente se permite una [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) igual a `Always`, +que es el valor por defecto si no se indica. + +### Réplicas + +`.spec.replicas` es un campo opcional que indica el número de Pods deseados. Su valor por defecto es 1. + +### Selector + +`.spec.selector` es un campo opcional que indica un [selector de etiquetas](/docs/concepts/overview/working-with-objects/labels/) +para los Pods objetivo del deployment. + +`.spec.selector` debe coincidir con `.spec.template.metadata.labels`, o será descartado por la API. + +A partir de la versión `apps/v1` de la API, `.spec.selector` y `.metadata.labels` no toman como valor por defecto el valor de `.spec.template.metadata.labels` si no se indica. +Por ello, debe especificarse de forma explícita. Además hay que mencionar que `.spec.selector` es inmutable tras la creación del Deployment en `apps/v1`. + +Un Deployment puede finalizar aquellos Pods cuyas etiquetas coincidan con el selector si su plantilla es diferente +de `.spec.template` o si el número total de dichos Pods excede `.spec.replicas`. Arranca nuevos +Pods con `.spec.template` si el número de Pods es menor que el número deseado. + +{{< note >}} +No deberías crear otros Pods cuyas etiquetas coincidan con este selector, ni directamente creando +otro Deployment, ni creando otro controlador como un ReplicaSet o un ReplicationController. Si lo haces, +el primer Deployment pensará que también creó esos otros Pods. Kubernetes no te impide hacerlo. +{{< /note >}} + +Si tienes múltiples controladores que entremezclan sus selectores, dichos controladores competirán entre ellos +y no se comportarán de forma correcta. + +### Estrategia + +`.spec.strategy` especifica la estrategia usada para remplazar los Pods viejos con los nuevos. +`.spec.strategy.type` puede tener el valor "Recreate" o "RollingUpdate". "RollingUpdate" el valor predeterminado. + +#### Despliegue mediante recreación + +Todos los Pods actuales se eliminan antes de que los nuevos se creen cuando `.spec.strategy.type==Recreate`. + +#### Despliegue mediante actualización continua + +El Deployment actualiza los Pods en modo de [actualización continua](/docs/tasks/run-application/rolling-update-replication-controller/) +cuando `.spec.strategy.type==RollingUpdate`. Puedes configurar los valores de `maxUnavailable` y `maxSurge` +para controlar el proceso de actualización continua. + +##### Número máximo de pods no disponibles + +`.spec.strategy.rollingUpdate.maxUnavailable` es un campo opcional que indica el número máximo +de Pods que pueden no estar disponibles durante el proceso de actualización. El valor puede ser un número absoluto (por ejemplo, 5) +o un porcentaje de los Pods deseados (por ejemplo, 10%). El número absoluto se calcula a partir del porcentaje +con redondeo a la baja. El valor no puede ser 0 si `.spec.strategy.rollingUpdate.maxSurge` es 0. El valor predeterminado es 25%. + +Por ejemplo, cuando este valor es 30%, el ReplicaSet viejo puede escalarse al 70% de los +Pods deseados de forma inmediata tras comenzar el proceso de actualización. Una vez que los Pods están listos, +el ReplicaSet viejo puede reducirse aún mas, seguido de un escalado del nuevo ReplicaSet, +asegurándose que el número total de Pods disponibles en todo momento durante la actualización +es de al menos el 70% de los Pods deseados. + +##### Número máximo de pods por encima del número deseado + +`.spec.strategy.rollingUpdate.maxSurge` es un campo opcional que indica el número máximo de Pods +que puede crearse por encima del número deseado de Pods. El valor puede ser un número absoluto (por ejemplo, 5) +o un porcentaje de los Pods deseados (por ejemplo, 10%). El valor no puede ser 0 si `MaxUnavailable` es 0. +El número absoluto se calcula a partir del porcentaje con redondeo al alza. El valor predeterminado es 25%. + +Por ejemplo, cuando este valor es 30%, el nuevo ReplicaSet puede escalarse inmediatamente cuando +comienza la actualización continua, de forma que el número total de Pods viejos y nuevos no +excede el 130% de los Pods deseados. Una vez que los viejos Pods se han eliminado, el nuevo ReplicaSet +puede seguir escalándose, asegurándose que el número total de Pods ejecutándose en todo momento +durante la actualización es como mucho del 130% de los Pods deseados. + +### Segundos para vencimiento del progreso + +`.spec.progressDeadlineSeconds` es un campo opcional que indica el número de segundos que quieres +esperar a que tu Deployment avance antes de que el sistema reporte que dicho Deployment +[ha fallado en su avance](#failed-deployment) - expresado como un estado con `Type=Progressing`, `Status=False`. +y `Reason=ProgressDeadlineExceeded` en el recurso. El controlador del Deployment seguirá intentando +el despliegue. En el futuro, una vez que se implemente el retroceso automático, el controlador del Deployment +retrocederá el despliegue en cuanto detecte ese estado. + +Si se especifica, este campo debe ser mayor que `.spec.minReadySeconds`. + +### Tiempo mínimo para considerar el Pod disponible + +`.spec.minReadySeconds` es un campo opcional que indica el número mínimo de segundos en que +un Pod recién creado debería estar listo sin que falle ninguno de sus contenedores, para que se considere disponible. +Por defecto su valor es 0 (el Pod se considera disponible en el momento que está listo). Para aprender más acerca de +cuándo un Pod se considera que está listo, ver las [pruebas de contenedor](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). + +### Vuelta atrás + +El campo `.spec.rollbackTo` se ha quitado de las versiones `extensions/v1beta1` y `apps/v1beta1` de la API, y ya no se permite en las versiones de la API a partir de `apps/v1beta2`. +En su caso, se debería usar `kubectl rollout undo`, tal y como se explicó en [Retroceder a una Revisión Previa](#rolling-back-to-a-previous-revision). + +### Límite del histórico de revisiones + +La historia de revisiones de un Deployment se almacena en los ReplicaSets que este controla. + +`.spec.revisionHistoryLimit` es un campo opcional que indica el número de ReplicaSets viejos a retener +para permitir los retrocesos. Estos ReplicaSets viejos consumen recursos en `etcd` y rebosan la salida de `kubectl get rs`. +La configuración de cada revisión de Deployment se almacena en sus ReplicaSets; +por lo tanto, una vez que se elimina el ReplicaSet viejo, se pierde la posibilidad de retroceder a dicha revisión del Deployment. +Por defecto, se retienen hasta 10 ReplicaSets viejos; pero su valor ideal depende de la frecuencia y la estabilidad de los nuevos Deployments. + +De forma más específica, si ponemos este campo a cero quiere decir que todos los ReplicaSets viejos con 0 réplicas se limpiarán. +En este caso, el nuevo despliegue del Deployment no se puede deshacer, ya que su historia de revisiones se habrá limpiado. + +### Pausa + +`.spec.paused` es un campo booleano opcional para pausar y reanudar un Deployment. La única diferencia entre +un Deployment pausado y otro que no lo está es que cualquier cambio al PodTemplateSpec del Deployment pausado +no generará nuevos despliegues mientras esté pausado. Un Deployment se pausa de forma predeterminada cuando se crea. + +## Alternativa a los Deployments + +### kubectl rolling update + +[`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) actualiza los Pods y los ReplicationControllers +de forma similar. Pero se recomienda el uso de Deployments porque se declaran del lado del servidor, y proporcionan características adicionales +como la posibilidad de retroceder a revisiones anteriores incluso después de haber terminado una actualización continua. + +{{% /capture %}} diff --git a/content/es/docs/concepts/workloads/controllers/garbage-collection.md b/content/es/docs/concepts/workloads/controllers/garbage-collection.md new file mode 100644 index 0000000000..5e93f00d9b --- /dev/null +++ b/content/es/docs/concepts/workloads/controllers/garbage-collection.md @@ -0,0 +1,183 @@ +--- +title: Recolección de Basura +content_template: templates/concept +weight: 60 +--- + +{{% capture overview %}} + +El papel del recolector de basura de Kubernetes es el de eliminar determinados objetos +que en algún momento tuvieron un propietario, pero que ahora ya no. + +{{% /capture %}} + + +{{% capture body %}}referencias de propietario + +## Propietarios y subordinados + +Algunos objetos de Kubernetes son propietarios de otros objetos. Por ejemplo, un ReplicaSet +es el propietario de un conjunto de Pods. Los objetos que se poseen se denominan *subordinados* del +objeto propietario. Cada objeto subordinado tiene un campo `metadata.ownerReferences` +que apunta al objeto propietario. + +En ocasiones, Kubernetes pone el valor del campo `ownerReference` automáticamente. + Por ejemplo, cuando creas un ReplicaSet, Kubernetes automáticamente pone el valor del campo +`ownerReference` de cada Pod en el ReplicaSet. A partir de la versión 1.8, Kubernetes +automáticamente pone el valor de `ownerReference` para los objetos creados o adoptados +por un ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job +y CronJob. + +También puedes configurar las relaciones entre los propietarios y sus subordinados +de forma manual indicando el valor del campo `ownerReference`. + +Aquí se muestra un archivo de configuración para un ReplicaSet que tiene tres Pods: + +{{< codenew file="controllers/replicaset.yaml" >}} + +Si se crea el ReplicaSet y entonces se muestra los metadatos del Pod, se puede +observar el campo OwnerReferences: + +```shell +kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml +kubectl get pods --output=yaml +``` + +La salida muestra que el propietario del Pod es el ReplicaSet denominado `my-repset`: + +```shell +apiVersion: v1 +kind: Pod +metadata: + ... + ownerReferences: + - apiVersion: apps/v1 + controller: true + blockOwnerDeletion: true + kind: ReplicaSet + name: my-repset + uid: d9607e19-f88f-11e6-a518-42010a800195 + ... +``` + +{{< note >}} +No se recomienda el uso de OwnerReferences entre Namespaces por diseño. Esto quiere decir que: +1) Los subordinados dentro del ámbito de Namespaces sólo pueden definir propietarios en ese mismo Namespace, +y propietarios dentro del ámbito de clúster. +2) Los subordinados dentro del ámbito del clúster sólo pueden definir propietarios dentro del ámbito del clúster, pero no +propietarios dentro del ámbito de Namespaces. +{{< /note >}} + +## Controlar cómo el recolector de basura elimina los subordinados + +Cuando eliminas un objeto, puedes indicar si sus subordinados deben eliminarse también +de forma automática. Eliminar los subordinados automáticamente se denomina *borrado en cascada*. +Hay dos modos de *borrado en cascada*: *en segundo plano* y *en primer plano*. + +Si eliminas un objeto sin borrar sus subordinados de forma automática, +dichos subordinados se convierten en *huérfanos*. + +### Borrado en cascada en primer plano + +En el *borrado en cascada en primer plano*, el objeto raíz primero entra en un estado +llamado "deletion in progress". En este estado "deletion in progress", +se cumplen las siguientes premisas: + + * El objeto todavía es visible a través de la API REST + * Se pone el valor del campo `deletionTimestamp` del objeto + * El campo `metadata.finalizers` del objeto contiene el valor "foregroundDeletion". + +Una vez que se pone el estado "deletion in progress", el recolector de basura elimina +los subordinados del objeto. Una vez que el recolector de basura ha eliminado todos +los subordinados "bloqueantes" (los objetos con `ownerReference.blockOwnerDeletion=true`), elimina +el objeto propietario. + +Cabe mencionar que usando "foregroundDeletion", sólo los subordinados con valor en +`ownerReference.blockOwnerDeletion` bloquean la eliminación del objeto propietario. +A partir de la versión 1.7, Kubernetes añadió un [controlador de admisión](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement) +que controla el acceso de usuario cuando se intenta poner el campo `blockOwnerDeletion` a true +con base a los permisos de borrado del objeto propietario, de forma que aquellos subordinados no autorizados +no puedan retrasar la eliminación del objeto propietario. + +Si un controlador (como un Deployment o un ReplicaSet) establece el valor del campo `ownerReferences` de un objeto, +se pone blockOwnerDeletion automáticamente y no se necesita modificar de forma manual este campo. + +### Borrado en cascada en segundo plano + +En el *borrado en cascada en segundo plano*, Kubernetes elimina el objeto propietario +inmediatamente y es el recolector de basura quien se encarga de eliminar los subordinados en segundo plano. + +### Configurar la regla de borrado en cascada + +Para controlar la regla de borrado en cascada, configura el campo `propagationPolicy` +del parámetro `deleteOptions` cuando elimines un objeto. Los valores posibles incluyen "Orphan", +"Foreground", o "Background". + +Antes de la versión 1.9 de Kubernetes, la regla predeterminada del recolector de basura para la mayoría de controladores era `orphan`. +Esto incluía al ReplicationController, ReplicaSet, StatefulSet, DaemonSet, y al Deployment. +Para los tipos dentro de las versiones de grupo `extensions/v1beta1`, `apps/v1beta1`, y `apps/v1beta2`, a menos que +se indique de otra manera, los objetos subordinados se quedan huérfanos por defecto. +En Kubernetes 1.9, para todos los tipos de la versión de grupo `apps/v1`, los objetos subordinados se eliminan por defecto. + +Aquí se muestra un ejemplo que elimina los subordinados en segundo plano: + +```shell +kubectl proxy --port=8080 +curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ +-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \ +-H "Content-Type: application/json" +``` + +Aquí se muestra un ejemplo que elimina los subordinados en primer plano: + +```shell +kubectl proxy --port=8080 +curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ +-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ +-H "Content-Type: application/json" +``` + +Aquí se muestra un ejemplo de subordinados huérfanos: + +```shell +kubectl proxy --port=8080 +curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ +-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ +-H "Content-Type: application/json" +``` + +kubectl también permite el borrado en cascada. +Para eliminar los subordinados automáticamente, utiliza el parámetro `--cascade` a true. + Usa false para subordinados huérfanos. Por defecto, el valor de `--cascade` +es true. + +Aquí se muestra un ejemplo de huérfanos de subordinados de un ReplicaSet: + +```shell +kubectl delete replicaset my-repset --cascade=false +``` + +### Nota adicional sobre los Deployments + +Antes de la versión 1.7, cuando se usaba el borrado en cascada con Deployments se *debía* usar `propagationPolicy: Foreground` +para eliminar no sólo los ReplicaSets creados, sino también sus Pods correspondientes. Si este tipo de _propagationPolicy_ +no se usa, solo se elimina los ReplicaSets, y los Pods se quedan huérfanos. +Ver [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613) para más información. + +## Problemas conocidos + +Seguimiento en [#26120](https://github.com/kubernetes/kubernetes/issues/26120) + +{{% /capture %}} + + +{{% capture whatsnext %}} + +[Documento de Diseño 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md) + +[Documento de Diseño 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md) + +{{% /capture %}} + + + diff --git a/content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md new file mode 100644 index 0000000000..480999af1d --- /dev/null +++ b/content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md @@ -0,0 +1,457 @@ +--- +title: Jobs - Ejecución hasta el final +content_template: templates/concept +feature: + title: Ejecución en lotes + description: > + Además de los servicios, Kubernetes puede gestionar tus trabajos por lotes y CI, sustituyendo los contenedores que fallen, si así se desea. +weight: 70 +--- + +{{% capture overview %}} + +Un Job crea uno o más Pods y se asegura de que un número específico de ellos termina de forma satisfactoria. +Conforme los pods terminan satisfactoriamente, el Job realiza el seguimiento de las ejecuciones satisfactorias. +Cuando se alcanza un número específico de ejecuciones satisfactorias, la tarea (esto es, el Job) se completa. +Al eliminar un Job se eliminan los Pods que haya creado. + +Un caso simple de uso es crear un objeto Job para que se ejecute un Pod de manera fiable hasta el final. +El objeto Job arrancará un nuevo Pod si el primer Pod falla o se elimina (por ejemplo +como consecuencia de un fallo de hardware o un reinicio en un nodo). + +También se puede usar un Job para ejecutar múltiples Pods en paralelo. + +{{% /capture %}} + + +{{% capture body %}} + +## Ejecutar un Job de ejemplo + +Aquí se muestra un ejemplo de configuración de Job. Este ejemplo calcula los primeros 2000 decimales de π y los imprime por pantalla. +Tarda unos 10s en completarse. + +{{< codenew file="controllers/job.yaml" >}} + +Puedes ejecutar el ejemplo con este comando: + +```shell +kubectl apply -f https://k8s.io/examples/controllers/job.yaml +``` +``` +job "pi" created +``` + +Comprueba el estado del Job con `kubectl`: + +```shell +kubectl describe jobs/pi +``` +``` +Name: pi +Namespace: default +Selector: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495 +Labels: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495 + job-name=pi +Annotations: +Parallelism: 1 +Completions: 1 +Start Time: Tue, 07 Jun 2016 10:56:16 +0200 +Pods Statuses: 0 Running / 1 Succeeded / 0 Failed +Pod Template: + Labels: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495 + job-name=pi + Containers: + pi: + Image: perl + Port: + Command: + perl + -Mbignum=bpi + -wle + print bpi(2000) + Environment: + Mounts: + Volumes: +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {job-controller } Normal SuccessfulCreate Created pod: pi-dtn4q +``` + +Para ver los Pods de un Job que se han completado, usa `kubectl get pods`. + +Para listar todos los Pods que pertenecen a un Job de forma que sea legible, puedes usar un comando como: + +```shell +pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') +echo $pods +``` +``` +pi-aiw0a +``` + +En este caso, el selector es el mismo que el selector del Job. La opción `--output=jsonpath` indica un expresión +que simplemente obtiene el nombre de cada Pod en la lista devuelta. + +Mira la salida estándar de uno de los Pods: + +```shell +$ kubectl logs $pods +3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 +``` + +## Escribir una especificación de Job + +Como con el resto de configuraciones de Kubernetes, un Job necesita los campos `apiVersion`, `kind`, y `metadata`. + +Un Job también necesita la [sección `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Plantilla Pod + +El campo `.spec.template` es el único campo obligatorio de `.spec`. + +El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [pod](/docs/user-guide/pods), +excepto por el hecho de que está anidado y no tiene el campo `apiVersion` o `kind`. + +Además de los campos olbigatorios de un Pod, una plantilla Pod de un Job debe indicar las etiquetas apropiadas +(ver [selector de pod](#pod-selector)) y una regla de reinicio apropiada. + +Sólo se permite los valores `Never` o `OnFailure` para [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy). + +### Selector de Pod + +El campo `.spec.selector` es opcional. En la práctica mayoría de los casos no deberías configurarlo. +Mira la sección sobre [configurar tu propio selector de pod](#specifying-your-own-pod-selector). + + +### Jobs en paralelo + +Hay tres tipos principales de tarea aptos para ejecutarse como un Job: + +1. Jobs no paralelos + - normalmente, sólo se arranca un Pod, a menos que el Pod falle. + - el Job se completa tan pronto como su Pod termine de forma satisfactoria. +1. Jobs en paralelo con un *cupo fijo de terminación*: + - se configura un valor positivo distinto de cero para el campo `.spec.completions`. + - el Job representa la tarea en general, y se completa cuando hay una ejecución satisfactoria de un Pod por cada valor dentro del rango de 1 a `.spec.completions`. + - **no implementado todavía:** A cada Pod se le pasa un índice diferenente dentro del rango de 1 a `.spec.completions`. +1. Jobs en paralelo con una *cola de trabajo*: + - no se especifica el campo `.spec.completions`, por defecto `.spec.parallelism`. + - los Pods deben coordinarse entre ellos mismos o a través de un servicio externo que determine quién debe trabajar en qué. + Por ejemplo, un Pod podría ir a buscar un lote de hasta N ítems de una cola de trabajo. + - cada Pod es capaz de forma independiente de determinar si sus compañeros han terminado o no, y como consecuencia el Job entero ha terminado. + - cuando _cualquier_ Pod del Job termina con éxito, no se crean nuevos Pods. + - una vez que al menos uno de los Pods ha terminado con éxito y todos los Pods han terminado, entonces el Job termina con éxito. + - una vez que cualquier Pod ha terminado con éxito, ningún otro Pod debería continuar trabajando en la misma tarea o escribiendo ningún resultado. Todos ellos deberían estar en proceso de terminarse. + +En un Job _no paralelo_, no debes indicar el valor de `.spec.completions` ni `.spec.parallelism`. Cuando ambos se dejan + sin valor, ambos se predeterminan a 1. + +En un Job con _cupo fijo de terminación_, deberías poner el valor de `.spec.completions` al número de terminaciones que se necesiten. +Puedes dar un valor a `.spec.parallelism`, o dejarlo sin valor, en cuyo caso se predetermina a 1. + +En un Job con _cola de trabajo_, no debes indicar el valor de `.spec.completions`, y poner el valor de `.spec.parallelism` a +un entero no negativo. + +Para más información acerca de cómo usar los distintos tipos de Job, ver la sección de [patrones de job](#job-patterns). + + +#### Controlar el paralelismo + +El paralelismo solicitado (`.spec.parallelism`) puede usar cualquier valor no negativo. +Si no se indica, se predeterminad a 1. +Si se indica como 0, entonces el Job se pausa de forma efectiva hasta que se incremente. + +El paralelismo actual (número de pods ejecutándose en cada momento) puede que sea mayor o menor que el solicitado, +por los siguientes motivos: + +- Para los Jobs con _cupo fijo de terminaciones_, el número actual de pods ejecutándose en paralelo no excede el número de terminaciones pendientes. + Los valores superiores de `.spec.parallelism` se ignoran. +- Para los Jobs con _cola de trabajo_, no se arranca nuevos Pods después de que cualquier Pod se haya completado -- sin embargo, se permite que se completen los Pods pendientes. +- Cuando el controlador no ha tenido tiempo para reaccionar. +- Cuando el controlador no pudo crear los Pods por el motivo que fuera (falta de `ResourceQuota`, falta de permisos, etc.), + entonces puede que haya menos pods que los solicitados. +- El controlador puede que regule la creación de nuevos Pods debido al excesivo número de fallos anteriores en el mismo Job. +- Cuando un Pod se para de forma controlada, lleva tiempo pararlo. + +## Gestionar Fallos de Pod y Contenedor + +Un contenedor de un Pod puede fallar por cualquier motivo, como porque el proceso que se estaba ejecutando termina con un código de salida distinto de cero, +o porque se mató el contenedor por exceder un límite de memoria, etc. Si esto ocurre, y se tiene +`.spec.template.spec.restartPolicy = "OnFailure"`, entonces el Pod permance en el nodo, +pero el contenedor se vuelve a ejecutar. Por lo tanto, tu aplicación debe poder gestionar el caso en que se reinicia de forma local, +o bien especificar `.spec.template.spec.restartPolicy = "Never"`. +Ver el [ciclo de vida de un pod](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) para más información sobre `restartPolicy`. + +Un Pod entero puede también fallar por cualquier motivo, como cuando se expulsa al Pod del nodo +(porque el nodo se actualiza, reinicia, elimina, etc.), o si un contenedor del Pod falla +cuando `.spec.template.spec.restartPolicy = "Never"`. Cuando un Pod falla, entonces el controlador del Job +arranca un nuevo Pod. Esto quiere decir que tu aplicación debe ser capaz de gestionar el caso en que se reinicia en un nuevo pod. +En particular, debe ser capaz de gestionar los ficheros temporales, los bloqueos, los resultados incompletos, y cualquier otra dependencia +de ejecuciones previas. + +Nótese que incluso si se configura `.spec.parallelism = 1` y `.spec.completions = 1` y +`.spec.template.spec.restartPolicy = "Never"`, el mismo programa puede arrancarse dos veces. + +Si se especifica `.spec.parallelism` y `.spec.completions` con valores mayores que 1, +entonces puede que haya múltiples pods ejecutándose a la vez. Por ello, tus pods deben tolerar la concurrencia. + +### Regla de retroceso de Pod por fallo + +Hay situaciones en que quieres que el Job falle después de intentar ejecutarlo unas cuantas veces debido +a un error lógico en la configuración, etc. +Para hacerlo, pon el valor de `.spec.backoffLimit` al número de reintentos que quieres +antes de considerar el Job como fallido. El límite de retroceso se predetermina a 6. +Los Pods fallidos asociados al Job son recreados por el controlador del Job con un +retroceso exponencial (10s, 20s, 40s ...) limitado a seis minutos. El contador +de retroceso se resetea si no aparecen Pods fallidos antes del siguiente chequeo de estado del Job. + +{{< note >}} +El problema [#54870](https://github.com/kubernetes/kubernetes/issues/54870) todavía existe en las versiones de Kubernetes anteriores a la versión 1.12 +{{< /note >}} + +## Terminación y Limpieza de un Job + +Cuando un Job se completa, ya no se crea ningún Pod, pero tampoco se elimina los Pods. Guardarlos permite +ver todavía los logs de los pods acabados para comprobar errores, avisos, o cualquier otro resultado de diagnóstico. +El objeto job también se conserva una vez que se ha completado para que se pueda ver su estado. Es decisión del usuario si elimina +los viejos jobs después de comprobar su estado. Eliminar el job con el comando `kubectl` (ej. `kubectl delete jobs/pi` o `kubectl delete -f ./job.yaml`). +Cuando eliminas un job usando el comando `kubectl`, todos los pods que creó se eliminan también. + +Por defecto, un Job se ejecutará de forma ininterrumpida a menos que uno de los Pods falle, en cuyo caso el Job se fija en el valor de +`.spec.backoffLimit` descrito arriba. Otra forma de acabar un Job es poniéndole un vencimiento activo. +Haz esto poniendo el valor del campo `.spec.activeDeadlineSeconds` del Job a un número de segundos. + +El campo `activeDeadlineSeconds` se aplica a la duración del job, independientemente de cuántos Pods se hayan creado. +Una vez que el Job alcanza `activeDeadlineSeconds`, se terminan todos sus Pods y el estado del Job se pone como `type: Failed` con `reason: DeadlineExceeded`. + +Fíjate que el campo `.spec.activeDeadlineSeconds` de un Job tiene precedencia sobre el campo `.spec.backoffLimit`. +Por lo tanto, un Job que está reintentando uno o más Pods fallidos no desplegará nuevos Pods una vez que alcance el límite de tiempo especificado por `activeDeadlineSeconds`, +incluso si todavía no se ha alcanzado el `backoffLimit`. + +Ejemplo: + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-timeout +spec: + backoffLimit: 5 + activeDeadlineSeconds: 100 + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Fíjate que tanto la especificación del Job como la [especificación de la plantilla Pod](/docs/concepts/workloads/pods/init-containers/#detailed-behavior) +dentro del Job tienen un campo `activeDeadlineSeconds`. Asegúrate que pones el valor de este campo de forma adecuada. + +## Limpiar los Jobs terminados automáticamente + +Normalmente, los Jobs que han terminado ya no se necesitan en el sistema. Conservarlos sólo añade +más presión al servidor API. Si dichos Jobs no se gestionan de forma directa por un controlador de más alto nivel, +como los [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), los Jobs pueden +limpiarse por medio de CronJobs en base a la regla de limpieza basada en capacidad que se haya especificado. + +### Mecanismo TTL para Jobs terminados + +{{< feature-state for_k8s_version="v1.12" state="alpha" >}} + +Otra forma de limpiar los Jobs terminados (bien `Complete` o `Failed`) +de forma automática es usando un mecanismo TTL proporcionado por un +[controlador TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) de recursos finalizados, +indicando el valor `.spec.ttlSecondsAfterFinished` del Job. + +Cuando el controlador TTL limpia el Job, lo eliminará en cascada, +esto es, eliminará sus objetos subordinados, como Pods, junto con el Job. Nótese +que cuando se elimina el Job, sus garantías de ciclo de vida, como los finalizadores, +se tendrán en cuenta. + +Por ejemplo: + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-ttl +spec: + ttlSecondsAfterFinished: 100 + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Aquí el Job `pi-with-ttl` será candidato a ser automáticamente eliminado, `100` +segundos después de que termine. + +Si el campo se pone a `0`, el Job será candidato a ser automáticamente eliminado +inmediatamente después de haber terminado. Si no se pone valor al campo, este Job no será eliminado +por el controlador TTL una vez concluya. + +Nótese que este mecanismo TTL está todavía en alpha, a través de la característica denominada `TTLAfterFinished`. +Para más información, ver la documentación del [controlador TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) para +recursos terminados. + +## Patrones de Job + +El objeto Job puede usarse para dar soporte a la ejecución fiable de Pods en paralelo. El objeto Job +no se diseñó para dar soporte a procesos paralelos estrechamente comunicados, como los que comúnmente +se encuentran en la computación científica. Eso sí, permite el proceso paralelo de un conjunto de *ítems de trabajo* independientes, pero relacionados entre sí. +Estos pueden ser correos a enviar, marcos a renderizar, archivos a codificar, rangos de claves en una base de datos NoSQL a escanear, y demás. + +En un sistema complejo, puede haber múltiples diferentes conjuntos de ítems de trabajo. Aquí sólo se está +considerando un conjunto de ítems de trabajo que el usuario quiere gestionar de forma conjunta — un *proceso por lotes*. + +Hay varios patrones diferentes para computación en paralelo, cada uno con sus fortalezas y sus debilidades. +Los sacrificios a tener en cuenta son: + +- Un objeto Job para cada ítem de trabajo vs. un objeto Job simple para todos los ítems de trabajo. El último es mejor + para grandes números de ítems de trabajo. El primero añade sobrecarga para el usuario y para el sistema + al tener que gestionar grandes números de objetos Job. +- El número de pods creados es igual al número de ítems de trabajo vs. cada Pod puede procesar múltiplese ítems de trabajo. + El primero típicamente requiere menos modificaciones al código existente y a los contenedores. + El último es mejor cuanto mayor sea el número de ítems de trabajo, por las mismas razones que antes.. +- Varios enfoques usan una cola de trabajo. Ello requiere ejecutar un servicio de colas, + y modificaciones a las aplicaciones o contenedores existentes para que hagan uso de la cola de trabajo. + Otras estrategias son más fáciles de adaptar a una aplicación ya usando contenedores. + + +Los sacrificios a tener en cuenta se indican a continuación, donde las columnas 2 a 4 representan los sacrificios de arriba. +Los nombres de los patrones son también enlaces a ejemplos e información más detallada. + +| Patrón | Objeto Job simple | ¿Menos pods que ítems de trabajo? | ¿No modificar la aplicación? | ¿Funciona en Kube 1.1? | +| -------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:| +| [Extensión de la Plantilla Job](/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ | +| [Cola con Pod por Ítem de Trabajo](/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | a veces | ✓ | +| [Cola con Cuenta Variable de Pods](/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ | +| Job simple con Asignación Estática de Trabajo | ✓ | | ✓ | | + +Cuando se especifican terminaciones con `.spec.completions`, cada Pod creado por el controlado del Job +tiene un [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)idéntico. +Esto significa que todos los pods de una tarea tendrán la misma línea de comandos y la +misma imagne, los mismo volúmenes, y (casi) las mismas variables de entorno. +Estos patrones otorgan diferentes formas de organizar los pods para que trabajen en cosas distintas. + +Esta tabla muestra la configuración necesaria para `.spec.parallelism` y `.spec.completions` para cada uno de los patrones. +Aquí, `T` es el número de ítems de trabajo. + +| Patrón | `.spec.completions` | `.spec.parallelism` | +| -------------------------------------------------------------------- |:-------------------:|:--------------------:| +| [Extensión de la Plantilla Job](/docs/tasks/job/parallel-processing-expansion/) | 1 | debería ser 1 | +| [Cola con Pod por Ítem de Trabajo](/docs/tasks/job/coarse-parallel-processing-work-queue/) | T | cualquiera | +| [Cola con Cuenta Variable de Pods](/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | cualquiera | +| Job simple con Asignación Estática de Trabajo | T | cualquiera | + + +## Uso Avanzado + +### Especificar tu propio selector de pod + +Normalmente, cuando creas un objeto Job, no especificas el campo `.spec.selector`. +La lógica por defecto del sistema añade este campo cuando se crea el Job. +Se elige un valor de selector que no se entremezcle con otras tareas. + +Sin embargo, en algunos casos, puede que necesites sobreescribir este selector que se configura de forma automática. +Para ello, puedes indicar el valor de `.spec.selector` en el Job. + +Pero ten mucho cuidado cuando lo hagas. Si configuras un selector de etiquta que no + es único para los pods de ese Job, y que selecciona Pods que no tienen que ver, + entonces estos últimos pueden ser eliminados, o este Job puede contar los otros + Pods para terminarse, o uno o ambos Jobs pueden negarse a crear Pods o ejecutarse hasta el final. + Si se elige un selector que no es único, entonces otros controladores (ej. ReplicationController) + y sus Pods puede comportarse de forma impredecibles también. Kubernetes no te impide cometer un error + especificando el `.spec.selector`. + +Aquí se muestra un ejemplo de un caso en que puede que necesites usar esta característica. + +Digamos que el Job `viejo` todavía está ejeuctándose. Quieres que los Pods existentes +sigan corriendo, pero quieres que el resto de los Pods que se creen +usen una plantilla pod diferente y que el Job tenga un nombre nuevo. +Como no puedes modificar el Job porque esos campos no son modificables, eliminas el Job `old`, + pero _dejas sus pods ejecutándose_ mediante el comando `kubectl delete jobs/old --cascade=false`. +Antes de eliminarlo, apúntate el selector actual que está usando: + +``` +kind: Job +metadata: + name: viejo + ... +spec: + selector: + matchLabels: + job-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +Entonces, creas un nuevo Job con el nombre `nuevo` y le configuras explícitamente el mismo selector. +Puesto que los Pods existentes tienen la etiqueta `job-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`, +son controlados por el Job `nuevo` igualmente. + +Necesitas configurar `manualSelector: true` en el nuevo Job, ya qye no estás usando + el selector que normalmente se genera de forma automática por el sistema. + +``` +kind: Job +metadata: + name: nuevo + ... +spec: + manualSelector: true + selector: + matchLabels: + job-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +El mismo Job nuevo tendrá un uid distinto a `a8f3d00d-c6d2-11e5-9f87-42010af00002`. +Poniendo `manualSelector: true` le dice al sistema que sabes lo que estás haciendo + y que te permita hacer este desajuste. + +## Alternativas + +### Pods simples + +Cuando el nodo donde un Pod simple se estaba ejecutando se reinicia o falla, dicho pod se termina +y no será reinicado. Sin embargo, un Job creará nuevos Pods para sustituir a los que se han terminando. +Por esta razón, se recomienda que se use un Job en vez de un Pod simple, incluso si tu aplicación +sólo necesita un único Pod. + +### Replication Controller + +Los Jobs son complementarios a los [Replication Controllers](/docs/user-guide/replication-controller). +Un Replication Controller gestiona aquellos Pods que se espera que no terminen (ej. servidores web), y un Job +gestiona aquellos Pods que se espera que terminen (ej. tareas por lotes). + +Como se discutió en el [Ciclo de vida de un Pod](/docs/concepts/workloads/pods/pod-lifecycle/), un `Job` *sólo* es apropiado +para aquellos pods con `RestartPolicy` igual a `OnFailure` o `Never`. +(Nota: Si `RestartPolicy` no se pone, el valor predeterminado es `Always`.) + +### Job simple arranca que arranca un controlador de Pod + +Otro patrón es aquel donde un Job simple crea un Pod que, a su vez, crea otros Pods, actuando como una especie +de controlador personalizado para esos Pods. Esto da la máxima flexibilidad, pero puede que +cueste un poco más de entender y ofrece menos integración con Kubernetes. + +Un ejemplo de este patrón sería un Job que arranca un Pod que ejecuta una secuencia de comandos que, a su vez, +arranca un controlador maestro de Spark (ver el [ejemplo de spark](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)), +ejecuta un manejador de spark, y a continuación lo limpia todo. + +Una ventaja de este enfoque es que el proceso general obtiene la garantía del objeto Job, +además del control completo de los Pods que se crean y cómo se les asigna trabajo. + +## Cron Jobs {#cron-jobs} + +Puedes utilizar un [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) para crear un Job que se ejecute en una hora/fecha determinadas, de forma similar +a la herramienta `cron` de Unix. + +{{% /capture %}} diff --git a/content/es/docs/concepts/workloads/controllers/replicaset.md b/content/es/docs/concepts/workloads/controllers/replicaset.md new file mode 100644 index 0000000000..a8a92c7860 --- /dev/null +++ b/content/es/docs/concepts/workloads/controllers/replicaset.md @@ -0,0 +1,370 @@ +--- +title: ReplicaSet +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +El objeto de un ReplicaSet es el de mantener un conjunto estable de réplicas de Pods ejecutándose +en todo momento. Así, se usa en numerosas ocasiones para garantizar la disponibilidad de un +número específico de Pods idénticos. + + +{{% /capture %}} + +{{% capture body %}} + +## Cómo funciona un ReplicaSet + +Un ReplicaSet se define con campos, incluyendo un selector que indica cómo identificar a los Pods que puede adquirir, +un número de réplicas indicando cuántos Pods debería gestionar, y una plantilla pod especificando los datos de los nuevos Pods +que debería crear para conseguir el número de réplicas esperado. Un ReplicaSet alcanza entonces su propósito + mediante la creación y eliminación de los Pods que sea necesario para alcanzar el número esperado. + Cuando un ReplicaSet necesita crear nuevos Pods, utiliza su plantilla Pod. + +El enlace que un ReplicaSet tiene hacia sus Pods es a través del campo del Pod denominado [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents), +el cual indica qué recurso es el propietario del objeto actual. Todos los Pods adquiridos por un ReplicaSet tienen su propia +información de identificación del ReplicaSet en su campo ownerReferences. Y es a través de este enlace +cómo el ReplicaSet conoce el estado de los Pods que está gestionando y actúa en consecuencia. + +Un ReplicaSet identifica los nuevos Pods a adquirir usando su selector. Si hay un Pod que no tiene OwnerReference +o donde OwnerReference no es un controlador, pero coincide con el selector del ReplicaSet, +este será inmediatamente adquirido por dicho ReplicaSet. + +## Cuándo usar un ReplicaSet + +Un ReplicaSet garantiza que un número específico de réplicas de un pod se está ejeuctando en todo momento. +Sin embargo, un Deployment es un concepto de más alto nivel que gestiona ReplicaSets y +proporciona actualizaciones de forma declarativa de los Pods junto con muchas otras características útiles. +Por lo tanto, se recomienda el uso de Deployments en vez del uso directo de ReplicaSets, a no ser +que se necesite una orquestración personalizada de actualización o no se necesite las actualizaciones en absoluto. + +En realidad, esto quiere decir que puede que nunca necesites manipular los objetos ReplicaSet: +en vez de ello, usa un Deployment, y define tu aplicación en la sección spec. + +## Ejemplo + +{{< codenew file="controllers/frontend.yaml" >}} + +Si guardas este manifiesto en un archivo llamado `frontend.yaml` y lo lanzas en un clúster de Kubernetes, + se creará el ReplicaSet definido y los Pods que maneja. + +```shell +kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml +``` + +Puedes ver los ReplicaSets actuales desplegados: +```shell +kubectl get rs +``` + +Y ver el frontend que has creado: +```shell +NAME DESIRED CURRENT READY AGE +frontend 3 3 3 6s +``` + +También puedes comprobar el estado del replicaset: +```shell +kubectl describe rs/frontend +``` + +Y verás una salida parecida a la siguiente: +```shell +Name: frontend +Namespace: default +Selector: tier=frontend,tier in (frontend) +Labels: app=guestbook + tier=frontend +Annotations: +Replicas: 3 current / 3 desired +Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed +Pod Template: + Labels: app=guestbook + tier=frontend + Containers: + php-redis: + Image: gcr.io/google_samples/gb-frontend:v3 + Port: 80/TCP + Requests: + cpu: 100m + memory: 100Mi + Environment: + GET_HOSTS_FROM: dns + Mounts: + Volumes: +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy + 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l +``` + +Y por último, puedes comprobar los Pods que ha arrancado: +```shell +kubectl get Pods +``` + +Deberías ver la información de cada Pod similar a: +```shell +NAME READY STATUS RESTARTS AGE +frontend-9si5l 1/1 Running 0 1m +frontend-dnjpy 1/1 Running 0 1m +frontend-qhloh 1/1 Running 0 1m +``` + +También puedes verificar que la referencia de propietario de dichos pods está puesta al ReplicaSet frontend. +Para ello, obtén el yaml de uno de los Pods ejecutándose: +```shell +kubectl get pods frontend-9si5l -o yaml +``` + +La salida será parecida a esta, donde la información sobre el ReplicaSet aparece en el campo ownerReferences de los metadatos: +```shell +apiVersion: v1 +kind: Pod +metadata: + creationTimestamp: 2019-01-31T17:20:41Z + generateName: frontend- + labels: + tier: frontend + name: frontend-9si5l + namespace: default + ownerReferences: + - apiVersion: extensions/v1beta1 + blockOwnerDeletion: true + controller: true + kind: ReplicaSet + name: frontend + uid: 892a2330-257c-11e9-aecd-025000000001 +... +``` + +## Adquisiciones de Pods fuera de la plantilla + +Aunque puedes crear Pods simples sin problemas, se recomienda encarecidamente asegurarse de que dichos Pods no tienen +etiquetas que puedan coincidir con el selector de alguno de tus ReplicaSets. +La razón de esta recomendación es que un ReplicaSet no se limita a poseer los Pods +especificados en su plantilla -- sino que puede adquirir otros Pods como se explicó en secciones anteriores. + +Toma el ejemplo anterior del ReplicaSet frontend, y los Pods especificados en el siguiente manifiesto: + +{{< codenew file="pods/pod-rs.yaml" >}} + +Como estos Pods no tienen un Controlador (o cualquier otro objeto) como referencia de propietario +y como además su selector coincide con el del ReplicaSet frontend, este último los terminará adquiriendo de forma inmediata. + +Supón que creas los Pods después de que el ReplicaSet frontend haya desplegado los suyos +para satisfacer su requisito de cuenta de réplicas: + +```shell +kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml +``` + +Los nuevos Pods serán adquiridos por el ReplicaSet, e inmediatamente terminados ya que + el ReplicaSet estaría por encima del número deseado. + +Obtener los Pods: +```shell +kubectl get Pods +``` + +La salida muestra que los nuevos Pods se han terminado, o están en el proceso de terminarse: +```shell +NAME READY STATUS RESTARTS AGE +frontend-9si5l 1/1 Running 0 1m +frontend-dnjpy 1/1 Running 0 1m +frontend-qhloh 1/1 Running 0 1m +pod2 0/1 Terminating 0 4s +``` + +Si creas primero los Pods: +```shell +kubectl apply -f http://k8s.io/examples/pods/pod-rs.yaml +``` + +Y entonces creas el ReplicaSet: +```shell +kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml +``` + +Verás que el ReplicaSet ha adquirido dichos Pods y simplemente ha creado tantos nuevos +como necesarios para cumplir con su especificación hasta que el número de +sus nuevos Pods y los originales coincidan con la cuenta deseado. Al obtener los Pods: +```shell +kubectl get Pods +``` + +Veremos su salida: +```shell +NAME READY STATUS RESTARTS AGE +frontend-pxj4r 1/1 Running 0 5s +pod1 1/1 Running 0 13s +pod2 1/1 Running 0 13s +``` + +De esta forma, un ReplicaSet puede poseer un conjunto no homogéneo de Pods + +## Escribir un manifiesto de ReplicaSet + +Al igual que con el esto de los objeto de la API de Kubernetes, un ReplicaSet necesita los campos +`apiVersion`, `kind`, y `metadata`. Para los ReplicaSets, el tipo es siempre ReplicaSet. +En la versión 1.9 de Kubernetes, la versión `apps/v1` de la API en un tipo ReplicaSet es la versión actual y está habilitada por defecto. +La versión `apps/v1beta2` de la API se ha desaprobado. +Consulta las primeras líneas del ejemplo `frontend.yaml` como guía. + +Un ReplicaSet también necesita una [sección `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Plantilla Pod + +El campo `.spec.template` es una [plantilla pod](/docs/concepts/workloads/Pods/pod-overview/#pod-templates) que es + también necesita obligatoriamente tener etiquetas definidas. En nuestro ejemplo `frontend.yaml` teníamos una etiqueta: `tier: frontend`. +Lleva cuidado de que no se entremezcle con los selectores de otros controladores, no sea que traten de adquirir este Pod. + +Para el campo de [regla de reinicio](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy) de la plantilla, +`.spec.template.spec.restartPolicy`, el único valor permitido es `Always`, que es el valor predeterminado. + +### Selector de Pod + +El campo `.spec.selector` es un [selector de etiqueta](/docs/concepts/overview/working-with-objects/labels/). +Como se explicó [anteriormente](#how-a-replicaset-works), estas son las etiquetas que se usan para + identificar los Pods potenciales a adquirir. En nuestro ejemplo `frontend.yaml`, el selector era: +```shell +matchLabels: + tier: frontend +``` + +El el ReplicaSet, `.spec.template.metadata.labels` debe coincidir con `spec.selector`, o será + rechazado por la API. + +{{< note >}} +Cuando 2 ReplicaSets especifican el mismo campo `.spec.selector`, pero los campos +`.spec.template.metadata.labels` y `.spec.template.spec` diferentes, cada ReplicaSet +ignora los Pods creados por el otro ReplicaSet. +{{< /note >}} + +### Réplicas + +Puedes configurar cuántos Pods deberían ejecutarse de forma concurrente indicando el campo `.spec.replicas`. +El ReplicaSet creará/eliminará sus Pods para alcanzar este número. + +Si no indicas el valor del campo `.spec.replicas`, entonces por defecto se inicializa a 1. + +## Trabajar con ReplicaSets + +### Eliminar un ReplicaSet y sus Pods + +Para eliminar un ReplicaSet y todos sus Pods, utiliza el comando [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). +El [Recolector de basura](/docs/concepts/workloads/controllers/garbage-collection/) eliminará automáticamente + todos los Pods subordinados por defecto. + +Cuando se usa la API REST o la librería `client-go`, se debe poner el valor de `propagationPolicy` a `Background` o +`Foreground` en la opción -d. +Por ejemplo: +```shell +kubectl proxy --port=8080 +curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ +> -H "Content-Type: application/json" +``` + +### Eliminar sólo un ReplicaSet + +Se puede eliminar un ReplicaSet sin afectar a ninguno de sus Pods usando el comando [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) con la opción `--cascade=false`. +Cuando se usa la API REST o la librería `client-go`, se debe poner `propagationPolicy` a `Orphan`. +Por ejemplo: +```shell +kubectl proxy --port=8080 +curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \ +> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ +> -H "Content-Type: application/json" +``` + +Una vez que se ha eliminado el original, se puede crear un nuevo ReplicaSet para sustituirlo. +Mientras el viejo y el nuevo `.spec.selector` sean el mismo, el nuevo adoptará a los viejos Pods. +Sin embargo, no se esforzará en conseguir que los Pods existentes coincidan con una plantilla pod nueva, diferente. +Para actualizar dichos Pods a la nueva especificación de forma controlada, +usa una [actualización en línea](#rolling-updates). + +### Aislar Pods de un ReplicaSet + +Es posible aislar Pods de un ReplicaSet cambiando sus etiquetas. Esta técnica puede usarse +para eliminar Pods de un servicio para poder depurar, recuperar datos, etc. Los Pods +que se eliminar de esta forma serán sustituidos de forma automática (siempre que el +número de réplicas no haya cambiado). + +### Escalar un ReplicaSet + +Se puede aumentar o reducir fácilmente un ReplicaSet simplemente actualizando el campo `.spec.replicas`. +El controlador del ReplicaSet se asegura de que el número deseado de Pods con un selector +de etiquetas coincidente está disponible y operacional. + +### ReplicaSet como blanco de un Horizontal Pod Autoscaler + +Un ReplicaSet puede también ser el blanco de un +[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/). Esto es, +un ReplicaSet puede auto-escalarse mediante un HPA. Aquí se muestra un ejemplo de HPA dirigido +al ReplicaSet que creamos en el ejemplo anterior. + +{{< codenew file="controllers/hpa-rs.yaml" >}} + +Si guardas este manifiesto en un archivo `hpa-rs.yaml` y lo lanzas contra el clúster de Kubernetes, +debería crear el HPA definido que auto-escala el ReplicaSet destino dependiendo del uso +de CPU de los Pods replicados. + +```shell +kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml +``` + +Alternativamente, puedes usar el comando `kubectl autoscale` para conseguir el mismo objetivo +(¡y mucho más fácil!) + +```shell +kubectl autoscale rs frontend --max=10 +``` + +## Alternativas al ReplicaSet + +### Deployment (recomendado) + +Un[`Deployment`](/docs/concepts/workloads/controllers/deployment/) es un objeto que puede poseer ReplicaSets +y actualizar a estos y a sus Pods mediante actualizaciones en línea declarativas en el servidor. +Aunque que los ReplicaSets puede usarse independientemente, hoy en día se usan principalmente a través de los Deployments +como el mecanismo para orquestrar la creación, eliminación y actualización de los Pods. +Cuando usas Deployments no tienes que preocuparte de gestionar los ReplicaSets que crean. +Los Deployments poseen y gestionan sus ReplicaSets. +Por tanto, se recomienda que se use Deployments cuando se quiera ReplicaSets. + +### Pods simples + +A diferencia del caso en que un usuario creaba Pods de forma directa, un ReplicaSet sustituye los Pods que se eliminan +o se terminan por la razón que sea, como en el caso de un fallo de un nodo o +una intervención disruptiva de mantenimiento, como una actualización de kernel. +Por esta razón, se recomienda que se use un ReplicaSet incluso cuando la aplicación +sólo necesita un único Pod. Entiéndelo de forma similar a un proceso supervisor, +donde se supervisa múltiples Pods entre múltiples nodos en vez de procesos individuales +en un único nodo. Un ReplicaSet delega los reinicios del contenedor local a algún agente +del nodo (por ejemplo, Kubelet o Docker). + +### Job + +Usa un [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) en vez de un ReplicaSet para + aquellos Pods que se esperan que terminen por ellos mismos (esto es, trabajos por lotes). + +### DaemonSet + +Usa un [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) en vez de un ReplicaSet para aquellos + Pods que proporcionan funcionalidad a nivel de servidor, como monitorización de servidor o + logging de servidor. Estos Pods tienen un ciclo de vida asociado al del servidor mismo: + el Pod necesita ejecutarse en el servidor antes de que los otros Pods comiencen, y es seguro + que terminen cuando el servidor esté listo para ser reiniciado/apagado. + +### ReplicationController +Los ReplicaSets son los sucesores de los [_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/). +Los dos sirven al mismo propósito, y se comportan de forma similar, excepto porque un ReplicationController +no soporta los requisitos del selector basado en conjunto, como se describe en la [guía de usuario de etiquetas](/docs/concepts/overview/working-with-objects/labels/#label-selectors). +Por ello, se prefiere los ReplicaSets a los ReplicationControllers. + +{{% /capture %}} diff --git a/content/es/examples/controllers/frontend.yaml b/content/es/examples/controllers/frontend.yaml new file mode 100644 index 0000000000..4a10c52a7d --- /dev/null +++ b/content/es/examples/controllers/frontend.yaml @@ -0,0 +1,21 @@ +apiVersion: apps/v1 +kind: ReplicaSet +metadata: + name: frontend + labels: + app: guestbook + tier: frontend +spec: + # modifica las réplicas según tu caso de uso + replicas: 3 + selector: + matchLabels: + tier: frontend + template: + metadata: + labels: + tier: frontend + spec: + containers: + - name: php-redis + image: gcr.io/google_samples/gb-frontend:v3 diff --git a/content/es/examples/controllers/hpa-rs.yaml b/content/es/examples/controllers/hpa-rs.yaml new file mode 100644 index 0000000000..a8388530dc --- /dev/null +++ b/content/es/examples/controllers/hpa-rs.yaml @@ -0,0 +1,11 @@ +apiVersion: autoscaling/v1 +kind: HorizontalPodAutoscaler +metadata: + name: frontend-scaler +spec: + scaleTargetRef: + kind: ReplicaSet + name: frontend + minReplicas: 3 + maxReplicas: 10 + targetCPUUtilizationPercentage: 50 diff --git a/content/es/examples/controllers/job.yaml b/content/es/examples/controllers/job.yaml new file mode 100644 index 0000000000..b448f2eb81 --- /dev/null +++ b/content/es/examples/controllers/job.yaml @@ -0,0 +1,14 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: pi +spec: + template: + spec: + containers: + - name: pi + image: perl + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never + backoffLimit: 4 + diff --git a/content/es/examples/controllers/nginx-deployment.yaml b/content/es/examples/controllers/nginx-deployment.yaml new file mode 100644 index 0000000000..f7f95deebb --- /dev/null +++ b/content/es/examples/controllers/nginx-deployment.yaml @@ -0,0 +1,21 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + replicas: 3 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 diff --git a/content/es/examples/controllers/replicaset.yaml b/content/es/examples/controllers/replicaset.yaml new file mode 100644 index 0000000000..e5dfdf6c43 --- /dev/null +++ b/content/es/examples/controllers/replicaset.yaml @@ -0,0 +1,17 @@ +apiVersion: apps/v1 +kind: ReplicaSet +metadata: + name: my-repset +spec: + replicas: 3 + selector: + matchLabels: + pod-is-for: garbage-collection-example + template: + metadata: + labels: + pod-is-for: garbage-collection-example + spec: + containers: + - name: nginx + image: nginx diff --git a/content/es/examples/pods/pod-rs.yaml b/content/es/examples/pods/pod-rs.yaml new file mode 100644 index 0000000000..df7b390597 --- /dev/null +++ b/content/es/examples/pods/pod-rs.yaml @@ -0,0 +1,23 @@ +apiVersion: v1 +kind: Pod +metadata: + name: pod1 + labels: + tier: frontend +spec: + containers: + - name: hello1 + image: gcr.io/google-samples/hello-app:2.0 + +--- + +apiVersion: v1 +kind: Pod +metadata: + name: pod2 + labels: + tier: frontend +spec: + containers: + - name: hello2 + image: gcr.io/google-samples/hello-app:1.0 diff --git a/content/fr/_index.html b/content/fr/_index.html index 89a66f48b6..3b659534e8 100644 --- a/content/fr/_index.html +++ b/content/fr/_index.html @@ -3,9 +3,6 @@ title: "Solution professionnelle d’orchestration de conteneurs" abstract: "Déploiement, mise à l'échelle et gestion automatisée des conteneurs" cid: home --- -{{< announcement >}} - -{{< deprecationwarning >}} {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} diff --git a/content/fr/docs/concepts/overview/working-with-objects/namespaces.md b/content/fr/docs/concepts/overview/working-with-objects/namespaces.md new file mode 100644 index 0000000000..90229676b0 --- /dev/null +++ b/content/fr/docs/concepts/overview/working-with-objects/namespaces.md @@ -0,0 +1,111 @@ +--- +title: Namespaces +content_type: concept +weight: 30 +--- + + + +Kubernetes prend en charge plusieurs clusters virtuels presents sur le même cluster physique. +Ces clusters virtuels sont appelés namespaces (espaces de noms en français). + + + +## Quand utiliser plusieurs namespaces + +Les namespaces sont destinés à être utilisés dans les environnements ayant de nombreux utilisateurs répartis en plusieurs équipes ou projets. Pour les clusters de quelques dizaines d'utilisateurs, vous n'avez pas +besoin d'utiliser de namespaces. Commencez à utiliser des namespaces lorsque vous avez +besoin des fonctionnalités qu'ils fournissent. + +Les namespaces sont des groupes de noms. Ils fournissent un modèle d'isolation de nommage des ressources. Les noms des ressources doivent être uniques dans un namespace, +mais pas dans l'ensemble des namespaces. Les namespaces ne peuvent pas être imbriqués les uns dans les autres et chaque ressource Kubernetes ne peut se trouver que dans un seul namespace. + +Les namespaces sont un moyen de répartir les ressources d'un cluster entre plusieurs utilisateurs (via [quota de ressources](/docs/concepts/policy/resource-quotas/)). + +Dans les futures versions de Kubernetes, les objets du même namespace auront les mêmes +stratégies de contrôle d'accès par défaut. + +Il n'est pas nécessaire d'utiliser plusieurs namespaces juste pour séparer des ressources légèrement différentes, telles que les versions du même logiciel: utiliser les [labels](/docs/user-guide/labels) pour distinguer les +ressources dans le même namespace. + +## Utilisation des namespaces + +La création et la suppression des namespaces sont décrites dans la [Documentation du guide d'administration pour les namespaces](/docs/admin/namespaces). + +{{< note >}} +Évitez de créer des namespaces avec le préfixe `kube-`, car il est réservé aux namespaces système de Kubernetes. +{{< /note >}} + +### Affichage des namespaces + +Dans un cluster vous pouvez lister les namespaces actuels à l'aide de: + +```shell +kubectl get namespace +``` + +``` +NAME STATUS AGE +default Active 1d +kube-node-lease Active 1d +kube-public Active 1d +kube-system Active 1d +``` + +Kubernetes démarre avec quatre namespaces initiaux: + +- `default` Le namespace par défaut pour les objets sans autre namespace +- `kube-system` Le namespace pour les objets créés par Kubernetes lui-même +- `kube-public` Ce namespace est créé automatiquement et est visible par tous les utilisateurs (y compris ceux qui ne sont pas authentifiés). Ce namespace est principalement réservé à l'utilisation du cluster, au cas où certaines ressources devraient être disponibles publiquement dans l'ensemble du cluster. L'aspect public de ce namespace n'est qu'une convention, pas une exigence. +- `kube-node-lease` Ce namespace contient les objets de bail associés à chaque nœud, ce qui améliore les performances des pulsations du nœud à mesure que le cluster évolue. + +### Définition du namespaces pour une requête + +Pour définir le namespace pour une requête en cours, utilisez l'indicateur `--namespace`. + +Par exemple: + +```shell +kubectl run nginx --image=nginx --namespace= +kubectl get pods --namespace= +``` + +### Spécifier un namespace + +Vous pouvez enregistrer de manière permanente le namespace à utiliser pour toutes les commandes kubectl à suivre. + +```shell +kubectl config set-context --current --namespace= +# Validez-le +kubectl config view --minify | grep namespace: +``` + +## Namespaces et DNS + +Lorsque vous créez un [Service](/fr/docs/concepts/services-networking/service/), il crée une [entrée DNS](/fr/docs/concepts/services-networking/dns-pod-service/) correspondante. +Cette entrée est de la forme `..svc.cluster.local`, ce qui signifie +que si un conteneur utilise simplement ``, il résoudra le service qui +est local à un namespace. Ceci est utile pour utiliser la même configuration pour +plusieurs namespaces tels que le Développement, la Qualification et la Production. Si vous voulez naviguer +entre plusieurs namespaces, vous devez utiliser le nom de domaine complet (FQDN ou nom de domaine complet en français). + +## Tous les objets ne se trouvent pas dans un namespace + +La plupart des ressources Kubernetes (par exemple, pods, services, contrôleurs de réplication et autres) sont +dans des namespaces. Cependant, les ressources de type namespace ne sont pas elles-mêmes dans un namespace. +Et les ressources de bas niveau, telles que les [noeuds](/docs/admin/node) et les volumes persistants, ne se trouvent dans aucun namespace. + +Pour voir quelles ressources Kubernetes sont et ne sont pas dans un namespace: + +```shell +# Dans un namespace +kubectl api-resources --namespaced=true + +# Pas dans un namespace +kubectl api-resources --namespaced=false +``` + +## {{% heading "whatsnext" %}} + +- En savoir plus sur [créer un nouveau namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace). +- En savoir plus sur [suppression d'un namespace](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace). diff --git a/content/fr/docs/reference/glossary/addons.md b/content/fr/docs/reference/glossary/addons.md new file mode 100644 index 0000000000..1911696b3f --- /dev/null +++ b/content/fr/docs/reference/glossary/addons.md @@ -0,0 +1,16 @@ +--- +title: Add-ons +id: addons +date: 2019-12-15 +full_link: /docs/concepts/cluster-administration/addons/ +short_description: > + Ressources qui étendent les fonctionnalités de Kubernetes. + +aka: +tags: +- tool +--- + Ressources qui étendent les fonctionnalités de Kubernetes. + + +[Installer des addons](/docs/concepts/cluster-administration/addons/) explique l'utilisation des modules complémentaires avec votre cluster et répertorie certains modules complémentaires populaires. diff --git a/content/fr/docs/reference/glossary/uid.md b/content/fr/docs/reference/glossary/uid.md new file mode 100644 index 0000000000..80f73c9c5c --- /dev/null +++ b/content/fr/docs/reference/glossary/uid.md @@ -0,0 +1,17 @@ +--- +title: UID +id: uid +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/names +short_description: > + Chaîne de caractères générée par les systèmes Kubernetes pour identifier de manière unique les objets. + +aka: +tags: +- fundamental +--- + Chaîne de caractères générée par les systèmes Kubernetes pour identifier de manière unique les objets. + + + +Chaque objet créé pendant toute la durée de vie d'un cluster Kubernetes possède un UID distinct. Il vise à distinguer les occurrences historiques d'entités similaires. \ No newline at end of file diff --git a/content/fr/docs/reference/glossary/volume.md b/content/fr/docs/reference/glossary/volume.md new file mode 100644 index 0000000000..deeca963b6 --- /dev/null +++ b/content/fr/docs/reference/glossary/volume.md @@ -0,0 +1,20 @@ +--- +title: Volume +id: volume +date: 2018-04-12 +full_link: /fr/docs/concepts/storage/volumes/ +short_description: > + Un répertoire contenant des données, accessible aux conteneurs d'un pod. + +aka: +tags: +- core-object +- fundamental +--- + Un répertoire contenant des données, accessible aux {{< glossary_tooltip text="conteneurs" term_id="container" >}} d'un {{< glossary_tooltip term_id="pod" >}}. + + + +Un volume Kubernetes vit aussi longtemps que le pod qui le contient. Par conséquent, un volume survit à tous les conteneurs qui s'exécutent dans le pod, et les données contenues dans le volume sont préservées lors des redémarrages du conteneur. + +Voir [stockage](/fr/docs/concepts/storage/) pour plus d'informations. \ No newline at end of file diff --git a/content/fr/docs/reference/glossary/workload.md b/content/fr/docs/reference/glossary/workload.md new file mode 100644 index 0000000000..8b3a0fd3c3 --- /dev/null +++ b/content/fr/docs/reference/glossary/workload.md @@ -0,0 +1,22 @@ +--- +title: Workload +id: workloads +date: 2019-02-13 +full_link: /fr/docs/concepts/workloads/ +short_description: > + Une charge de travail (workload) est une application exécutée sur Kubernetes. + +aka: +tags: +- fundamental +--- + Une charge de travail (workload) est une application exécutée sur Kubernetes. + + + +Divers objets de base qui représentent différents types ou parties d'une charge de travail +incluent les objets DaemonSet, Deployment, Job, ReplicaSet et StatefulSet. + +Par exemple, une charge de travail constituée d'un serveur Web et d'une base de données peut exécuter la +base de données dans un {{< glossary_tooltip term_id="StatefulSet" >}} et le serveur web +dans un {{< glossary_tooltip term_id="Deployment" >}}. diff --git a/content/fr/docs/setup/independent/kubelet-integration.md b/content/fr/docs/setup/independent/kubelet-integration.md index 18ea57310b..05f4839c05 100644 --- a/content/fr/docs/setup/independent/kubelet-integration.md +++ b/content/fr/docs/setup/independent/kubelet-integration.md @@ -174,7 +174,7 @@ Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml" the KUBELET_KUBEADM_ARGS variable dynamically EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env # This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, -#the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. +# the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. # KUBELET_EXTRA_ARGS should be sourced from this file. EnvironmentFile=-/etc/default/kubelet ExecStart= diff --git a/content/fr/docs/setup/learning-environment/minikube.md b/content/fr/docs/setup/learning-environment/minikube.md index 77ddde7f4d..77be61831f 100644 --- a/content/fr/docs/setup/learning-environment/minikube.md +++ b/content/fr/docs/setup/learning-environment/minikube.md @@ -235,16 +235,16 @@ minikube start --vm-driver= Minikube prend en charge les pilotes suivants: {{< note >}} -Voir [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) pour plus de détails sur les pilotes pris en charge et comment installer les plugins. +Voir [DRIVERS](https://minikube.sigs.k8s.io/docs/drivers/) pour plus de détails sur les pilotes pris en charge et comment installer les plugins. {{< /note >}} * virtualbox * vmwarefusion -* kvm2 ([installation du pilote](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver)) -* hyperkit ([installation du pilote](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver)) -* hyperv ([installation du pilote](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) +* kvm2 ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver)) +* hyperkit ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver)) +* hyperv ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#hyperv-driver)) Notez que l'adresse IP ci-dessous est dynamique et peut changer. Il peut être récupéré avec `minikube ip`. -* vmware ([installation du pilote](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver) +* vmware ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#vmware-unified-driver)) (VMware unified driver) * none (Exécute les composants Kubernetes sur l’hôte et non sur une machine virtuelle. Il n'est pas recommandé d'exécuter le pilote none sur des postes de travail personnels. L'utilisation de ce pilote nécessite Docker ([docker installer](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) et un environnement Linux) #### Démarrage d'un cluster sur des exécutions de conteneur alternatives diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md new file mode 100644 index 0000000000..5d8df1af62 --- /dev/null +++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md @@ -0,0 +1,283 @@ +--- +title: Configurer les comptes de service pour les pods +content_template: templates/task +weight: 90 +--- + +{{% capture overview %}} +Un ServiceAccount (compte de service) fournit une identité pour les processus qui s'exécutent dans un Pod. + +*Ceci est une introduction aux comptes de service pour les utilisateurs. Voir aussi +[Guide de l'administrateur du cluster des comptes de service](/docs/reference/access-authn-authz/service-accounts-admin/).* + +{{< note >}} +Ce document décrit le comportement des comptes de service dans un cluster mis en place conformément aux recommandations du projet Kubernetes. L'administrateur de votre cluster a peut-être personnalisé le comportement dans votre cluster, dans ce cas cette documentation pourrait être non applicable. +{{< /note >}} + +Lorsque vous (un humain) accédez au cluster (par exemple, en utilisant `kubectl`), vous êtes +authentifié par l'apiserver en tant que compte d'utilisateur particulier (actuellement, il s'agit +généralement de l'utilisateur `admin`, à moins que votre administrateur de cluster n'ait personnalisé votre cluster). Les processus dans les conteneurs dans les Pods peuvent également contacter l'apiserver. Dans ce cas, ils sont authentifiés en tant que compte de service particulier (par exemple, `default`). + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + +## Utiliser le compte de service par défaut pour accéder au API server. + +Si vous obtenez le raw json ou yaml pour un Pod que vous avez créé (par exemple, `kubectl get pods/ -o yaml`), vous pouvez voir que le champ `spec.serviceAccountName` a été [automatiquement assigné](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). + +Vous pouvez accéder à l'API depuis l'intérieur d'un Pod en utilisant les identifiants de compte de service montés automatiquement, comme décrit dans [Accès au cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). +Les permissions API du compte de service dépendent du [plugin d'autorisation et de la politique](/docs/reference/access-authn-authz/authorization/#authorization-modules) en usage. + +Dans la version 1.6+, vous pouvez choisir de ne pas utiliser le montage automatique des identifiants API pour un compte de service en définissant `automountServiceAccountToken: false` sur le compte de service : + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + name: build-robot +automountServiceAccountToken: false +... +``` + +Dans la version 1.6+, vous pouvez également choisir de ne pas monter automatiquement les identifiants API pour un Pod particulier : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + serviceAccountName: build-robot + automountServiceAccountToken: false + ... +``` + +La spéc de Pod a prépondérance par rapport au compte de service si les deux spécifient la valeur `automountServiceAccountToken`. + +## Utiliser plusieurs comptes de services. + +Chaque Namespace possède une ressource ServiceAccount par défaut appelée `default`. +Vous pouvez lister cette ressource et toutes les autres ressources de ServiceAccount dans le Namespace avec cette commande : + +```shell +kubectl get serviceAccounts +``` +La sortie est comme la suivante : + +``` +NAME SECRETS AGE +default 1 1d +``` + +Vous pouvez créer des objets ServiceAccount supplémentaires comme ceci : + +```shell +kubectl apply -f - < +Annotations: kubernetes.io/service-account.name=build-robot + kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da + +Type: kubernetes.io/service-account-token + +Data +==== +ca.crt: 1338 bytes +namespace: 7 bytes +token: ... +``` + +{{< note >}} +Le contenu de `token` est éludé ici. +{{< /note >}} + +## Ajouter ImagePullSecrets à un compte de service + +Tout d'abord, créez un imagePullSecret, comme décrit [ici](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). +Puis, vérifiez qu'il a été créé. Par exemple : + +```shell +kubectl get secrets myregistrykey +``` + +La sortie est comme la suivante : + +``` +NAME TYPE DATA AGE +myregistrykey   kubernetes.io/.dockerconfigjson   1       1d +``` + +Ensuite, modifiez le compte de service par défaut du Namespace pour utiliser ce Secret comme un `imagePullSecret`. + +```shell +kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' +``` + +La version interactive nécessite un traitement manuel : + +```shell +kubectl get serviceaccounts default -o yaml > ./sa.yaml +``` + +La sortie du fichier `sa.yaml` est similaire à celle-ci : + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + resourceVersion: "243024" + selfLink: /api/v1/namespaces/default/serviceaccounts/default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +``` + +En utilisant l'éditeur de votre choix (par exemple `vi`), ouvrez le fichier `sa.yaml`, supprimez la ligne avec la clé `resourceVersion`, ajoutez les lignes avec `imagePullSecrets:` et sauvegardez. + +La sortie du fichier `sa.yaml` est similaire à celle-ci : + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + selfLink: /api/v1/namespaces/default/serviceaccounts/default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +imagePullSecrets: +- name: myregistrykey +``` + +Enfin, remplacez le compte de service par le nouveau fichier `sa.yaml` mis à jour. + +```shell +kubectl replace serviceaccount default -f ./sa.yaml +``` + +Maintenant, tous les nouveaux Pods créés dans le Namespace courant auront ceci ajouté à leurs spécifications : + +```yaml +spec: + imagePullSecrets: + - name: myregistrykey +``` + +## Projection du volume des tokens de compte de service + +{{< feature-state for_k8s_version="v1.12" state="beta" >}} + +{{< note >}} +Ce ServiceAccountTokenVolumeProjection est __beta__ en 1.12 et +activé en passant tous les paramètres suivants au serveur API : + +* `--service-account-issuer` +* `--service-account-signing-key-file` +* `--service-account-api-audiences` + +{{< /note >}} + +Kubelet peut également projeter un token de compte de service dans un Pod. Vous pouvez spécifier les propriétés souhaitées du token, telles que l'audience et la durée de validité. +Ces propriétés ne sont pas configurables sur le compte de service par défaut. Le token de compte de service devient également invalide par l'API lorsque le Pod ou le ServiceAccount est supprimé + +Ce comportement est configuré sur un PodSpec utilisant un type de ProjectedVolume appelé +[ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Pour fournir un +Pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec : + +{{< codenew file="pods/pod-projected-svc-token.yaml" >}} + +Créez le Pod + +```shell +kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml +``` + +Kubelet demandera et stockera le token a la place du Pod, rendra le token disponible pour le Pod à un chemin d'accès configurable, et rafraîchissez le token à l'approche de son expiration. Kubelet fait tourner le token de manière proactive s'il est plus vieux que 80% de son TTL total, ou si le token est plus vieux que 24 heures. + +L'application est responsable du rechargement du token lorsque celui ci est renouvelé. Un rechargement périodique (par ex. toutes les 5 minutes) est suffisant pour la plupart des cas d'utilisation. + +{{% /capture %}} diff --git a/content/fr/docs/tutorials/hello-minikube.md b/content/fr/docs/tutorials/hello-minikube.md index 724919d0e6..a934464b77 100644 --- a/content/fr/docs/tutorials/hello-minikube.md +++ b/content/fr/docs/tutorials/hello-minikube.md @@ -78,7 +78,7 @@ Les déploiements sont le moyen recommandé pour gérer la création et la mise Pod utilise un conteneur basé sur l'image Docker fournie. ```shell - kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node + kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4 ``` 2. Affichez le déploiement : diff --git a/content/fr/examples/pods/pod-projected-svc-token.yaml b/content/fr/examples/pods/pod-projected-svc-token.yaml new file mode 100644 index 0000000000..985073c8d3 --- /dev/null +++ b/content/fr/examples/pods/pod-projected-svc-token.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /var/run/secrets/tokens + name: vault-token + serviceAccountName: build-robot + volumes: + - name: vault-token + projected: + sources: + - serviceAccountToken: + path: vault-token + expirationSeconds: 7200 + audience: vault diff --git a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 014a40171e..3bde2909ca 100644 --- a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -221,7 +221,7 @@ Berikut beberapa contoh implementasi _plugin_ perangkat: * [Plugin perangkat RDMA](https://github.com/hustcat/k8s-rdma-device-plugin) * [Plugin perangkat Solarflare](https://github.com/vikaschoudhary16/sfc-device-plugin) * [Plugin perangkat SR-IOV Network](https://github.com/intel/sriov-network-device-plugin) -* [Plugin perangkat Xilinx FPGA](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) untuk perangkat Xilinx FPGA +* [Plugin perangkat Xilinx FPGA](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) untuk perangkat Xilinx FPGA ## {{% heading "whatsnext" %}} diff --git a/content/id/docs/concepts/storage/storage-classes.md b/content/id/docs/concepts/storage/storage-classes.md index 6de85830e8..9e0a5b1664 100644 --- a/content/id/docs/concepts/storage/storage-classes.md +++ b/content/id/docs/concepts/storage/storage-classes.md @@ -40,7 +40,7 @@ dan objek yang sudah dibuat tidak dapat diubah lagi definisinya. Administrator dapat memberikan spesifikasi StorageClass _default_ bagi PVC yang tidak membutuhkan kelas tertentu untuk dapat melakukan mekanisme _bind_: -kamu dapat membaca [bagian `PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#class-1) +kamu dapat membaca [bagian `PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) untuk penjelasan lebih lanjut. ```yaml diff --git a/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md new file mode 100644 index 0000000000..e723edee9c --- /dev/null +++ b/content/id/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -0,0 +1,290 @@ +--- +title: Batasan Persebaran Topologi Pod +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +Kamu dapat menggunakan batasan perseberan topologi (_topology spread constraints_) +untuk mengatur bagaimana {{< glossary_tooltip text="Pod" term_id="Pod" >}} akan disebarkan +pada klaster yang ditetapkan sebagai _failure-domains_, seperti wilayah, zona, Node dan domain +topologi yang ditentukan oleh pengguna. Ini akan membantu untuk mencapai ketersediaan yang tinggi +dan juga penggunaan sumber daya yang efisien. + +{{% /capture %}} + +{{% capture body %}} + +## Persyaratan + +### Mengaktifkan Gerbang Fitur + +[Gerbang fitur (_feature gate_)](/docs/reference/command-line-tools-reference/feature-gates/) +`EvenPodsSpread` harus diaktifkan untuk +{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} **dan** +{{< glossary_tooltip text="penjadwal (_scheduler_)" term_id="kube-scheduler" >}}. + +### Label Node + +Batasan persebaran topologi bergantung dengan label pada Node untuk menentukan +domain topologi yang memenuhi untuk semua Node. Misalnya saja, sebuah Node bisa memiliki +label sebagai berikut: `node=node1,zone=us-east-1a,region=us-east-1` + +Misalkan kamu memiliki klaster dengan 4 Node dengan label sebagai berikut: + +``` +NAME STATUS ROLES AGE VERSION LABELS +node1 Ready 4m26s v1.16.0 node=node1,zone=zoneA +node2 Ready 3m58s v1.16.0 node=node2,zone=zoneA +node3 Ready 3m17s v1.16.0 node=node3,zone=zoneB +node4 Ready 2m43s v1.16.0 node=node4,zone=zoneB +``` + +Maka klaster tersebut secara logika akan dilihat sebagai berikut: + +``` ++---------------+---------------+ +| zoneA | zoneB | ++-------+-------+-------+-------+ +| node1 | node2 | node3 | node4 | ++-------+-------+-------+-------+ +``` + +Tanpa harus memberi label secara manual, kamu dapat menggunakan [label ternama] +(/docs/reference/kubernetes-api/labels-annotations-taints/) yang terbuat dan terkumpulkan +secara otomatis pada kebanyakan klaster. + +## Batasan Persebaran untuk Pod + +### API + +_Field_ `pod.spec.topologySpreadConstraints` diperkenalkan pada versi 1.16 sebagai berikut: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + topologySpreadConstraints: + - maxSkew: + topologyKey: + whenUnsatisfiable: + labelSelector: +``` + +Kamu dapat mendefinisikan satu atau lebih `topologySpreadConstraint` untuk menginstruksikan +kube-scheduler mengenai cara peletakan tiap Pod baru dengan menggunakan kondisi Pod yang +sudah ada dalam klaster kamu. _Field_ yang ada adalah: + +- **maxSkew** menentukan batasan yang menandakan Pod tidak tersebar secara merata. +Ini merupakan nilai maksimal dari selisih jumlah Pod yang sama untuk setiap 2 domain topologi +yang sama. Nilai ini harus lebih dari 0. +- **topologyKey** adalah kunci dari label Node. Jika terdapat dua Node memiliki label dengan +kunci ini dan memiliki nilai yang identik untuk label tersebut, maka penjadwal akan menganggap +kedua Noode dalam topologi yang sama. Penjadwal akan mencoba untuk menyeimbangkan jumlah Pod +dalam setiap domain topologi. +- **whenUnsatisfiable** mengindikasikan cara menangani Pod yang tidak memenuhi batasan persebaran: + - `DoNotSchedule` (_default_) memberitahukan penjadwal untuk tidak menjadwalkan Pod tersebut. + - `ScheduleAnyway` memberitahukan penjadwal untuk tetap menjadwalkan Pod namun tetap menjaga ketidakseimbangan Node sekecil mungkin. +- **labelSelector** digunakan untuk mencari Pod yang sesuai. Pod dengan label yang sama dengan ini akan dihitung untuk menentukan jumlah Pod dalam domain topologi yang sesuai. Silakan baca [Label dan Selector](/id/docs/concepts/overview/working-with-objects/labels/#selektor-label) untuk lebih detailnya. + +Kamu juga bisa membaca lebih detail mengenai _field_ ini dengan menjalankan perintah +`kubectl explain Pod.spec.topologySpreadConstraints`. + +### Contoh: Satu TopologySpreadConstraint + +Misalkan kamu memiliki klaster dengan 4 Node dimana 3 Pod berlabel `foo:bar` terdapat pada node1, +node2 dan node3 (`P` merepresentasikan Pod): + +``` ++---------------+---------------+ +| zoneA | zoneB | ++-------+-------+-------+-------+ +| node1 | node2 | node3 | node4 | ++-------+-------+-------+-------+ +| P | P | P | | ++-------+-------+-------+-------+ +``` + +Jika kita ingin Pod baru akan disebar secara merata berdasarkan Pod yang telah ada pada semua zona, +maka _spec_ bernilai sebagai berikut: + +{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}} + +`topologyKey: zone` berarti persebaran merata hanya akan digunakan pada Node dengan pasangan label +"zone: ". `whenUnsatisfiable: DoNotSchedule` memberitahukan penjadwal untuk membiarkan +tetap ditunda jika Pod yang baru tidak memenuhi batasan yang diterapkan. + +Jika penjadwal menempatkan Pod baru pada "zoneA", persebaran Pod akan menjadi [3, 1], menjadikan +ketidakseimbangan menjadi bernilai 2 (3 - 1), yang mana akan melanggar batasan `maxSkew: 1`. +Dalam contoh ini, Pod baru hanya dapat ditempatkan pada "zoneB": + +``` ++---------------+---------------+ +---------------+---------------+ +| zoneA | zoneB | | zoneA | zoneB | ++-------+-------+-------+-------+ +-------+-------+-------+-------+ +| node1 | node2 | node3 | node4 | OR | node1 | node2 | node3 | node4 | ++-------+-------+-------+-------+ +-------+-------+-------+-------+ +| P | P | P | P | | P | P | P P | | ++-------+-------+-------+-------+ +-------+-------+-------+-------+ +``` + +Kamu dapat mengatur spesifikasi Pod untuk memenuhi beberapa persyaratan berikut: + +- Ubah nilai `maxSkew` menjadi lebih besar, misal "2", sehingga Pod baru dapat ditempatkan pada "zoneA". +- Ubah nilai `topologyKey` menjadi "node" agar Pod disebarkan secara merata pada semua Node, bukan zona. Pada contoh di atas, jika `maxSkew` tetap bernilai "1", maka Pod baru hanya akan ditempatkan pada "node4". +- Ubah nilai `whenUnsatisfiable: DoNotSchedule` menjadi `whenUnsatisfiable: ScheduleAnyway` untuk +menjamin agar semua Pod baru akan tetap dijadwalkan (misalkan saja API penjadwalan lain tetap +terpenuhi). Namun, ini lebih suka ditempatkan pada domain topologi yang memiliki lebih sedikit +Pod yang sesuai. (Harap diperhatikan bahwa preferensi ini digabungkan bersama dengan prioritas +penjadwalan internal yang lain, seperti rasio penggunaan sumber daya, dan lain sebagainya.) + +### Contoh: Beberapa TopologySpreadConstraint + +Ini dibuat berdasarkan contoh sebelumnya. Misalkan kamu memiliki klaster dengan 4 Node dengan +3 Pod berlabel `foo:bar` yang ditempatkan pada node1, node2 dan node3. (`P` merepresentasikan Pod): + +``` ++---------------+---------------+ +| zoneA | zoneB | ++-------+-------+-------+-------+ +| node1 | node2 | node3 | node4 | ++-------+-------+-------+-------+ +| P | P | P | | ++-------+-------+-------+-------+ +``` + +Kamu dapat menggunakan 2 TopologySpreadConstraint untuk mengatur persebaran Pod pada zona dan Node: + +{{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}} + +Dalam contoh ini, untuk memenuhi batasan pertama, Pod yang baru hanya akan ditempatkan pada "zoneB", +sedangkan untuk batasan kedua, Pod yang baru hanya akan ditempatkan pada "node4". Maka hasil dari +2 batasan ini akan digunakan (_AND_), sehingga opsi untuk menempatkan Pod hanya pada "node4". + +Beberapa batasan dapat berujung pada konflik. Misalnya saja kamu memiliki klaster dengan 3 Node +pada 2 zona berbeda: + +``` ++---------------+-------+ +| zoneA | zoneB | ++-------+-------+-------+ +| node1 | node2 | node3 | ++-------+-------+-------+ +| P P | P | P P | ++-------+-------+-------+ +``` + +Jika kamu menerapkan "two-constraints.yaml" pada klaster ini, kamu akan mendapatkan "mypod" tetap +dalam kondisi `Pending`. Ini dikarenakan oleh: untuk memenuhi batasan pertama, "mypod" hanya dapat +ditempatkan pada "zoneB", sedangkan untuk batasan kedua, "mypod" hanya dapat ditempatkan pada +"node2". Tidak ada hasil penggabungan dari "zoneB" dan "node2". + +Untuk mengatasi situasi ini, kamu bisa menambahkan nilai `maxSkew` atau mengubah salah satu dari +batasan untuk menggunakan `whenUnsatisfiable: ScheduleAnyway`. + +### Konvensi + +Ada beberapa konvensi implisit yang perlu diperhatikan di sini: + +- Hanya Pod dengan Namespace yang sama dengan Pod baru yang bisa menjadi kandidat yang cocok. + +- Node tanpa memiliki `topologySpreadConstraints[*].topologyKey` akan dilewatkan. Ini berarti: + 1. Pod yang ditempatkan pada Node tersebut tidak berpengaruh pada perhitungan `maxSkew`. Dalam contoh di atas, misalkan "node1" tidak memiliki label "zone", maka kedua Pod tidak diperhitungkan dan menyebabkan Pod yang baru akan dijadwalkan masuk ke "zoneA". + 2. Pod yang baru tidak memiliki kesempatan untuk dijadwalkan ke Node tersebut, pada contoh di atas, misalkan terdapat "node5" dengan label `{zone-typo: zoneC}` bergabung dalam klaster, Node ini akan dilewatkan karena tidak memiliki label dengan kunci "zone". + +- Harap diperhatikan mengenai hal yang terjadi jika nilai `topologySpreadConstraints[*].labelSelector` pada Pod yang baru tidak sesuai dengan labelnya. +Pada contoh di atas, jika kita menghapus label pada Pod yang baru, maka Pod akan tetap ditempatkan +pada "zoneB" karena batasan yang ada masih terpenuhi. Namun, setelah ditempatkan, nilai +ketidakseimbangan pada klaster masih tetap tidak berubah, zoneA tetap memiliki 2 Pod dengan label +{foo:bar} dan zoneB memiliki 1 Pod dengan label {foo:bar}. Jadi jika ini tidak yang kamu harapkan, +kami menyarankan nilai dari `topologySpreadConstraints[*].labelSelector` disamakan dengan labelnya. + +- Jika Pod yang baru memiliki `spec.nodeSelector` atau `spec.affinity.nodeAffinity`, Node yang tidak +sesuai dengan nilai tersebut akan dilewatkan. + + Misalkan kamu memiliki klaster dengan 5 Node dari zoneA sampai zoneC: + + ``` + +---------------+---------------+-------+ + | zoneA | zoneB | zoneC | + +-------+-------+-------+-------+-------+ + | node1 | node2 | node3 | node4 | node5 | + +-------+-------+-------+-------+-------+ + | P | P | P | | | + +-------+-------+-------+-------+-------+ + ``` + + dan kamu mengetahui bahwa "zoneC" harus tidak diperhitungkan. Dalam kasus ini, kamu dapat membuat + berkas yaml seperti di bawah, jadi "mypod" akan ditempatkan pada "zoneB", bukan "zoneC". + Demikian juga `spec.nodeSelector` akan digunakan. + + {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}} + +### Batasan _default_ pada tingkat klaster + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +Ini memungkinkan untuk mengatur batasan persebaran topologi bawaan untuk klaster. +Batasan persebaran topologi bawaan akan digunakan pada Pod jika dan hanya jika: + +- Hal ini tidak mendefinisikan batasan apapun pada `.spec.topologySpreadConstraints`. +- Hal ini milik sebuah Service, ReplicationController, ReplicaSet atau StatefulSet. + +Batasan bawaan akan diatur sebagai bagian dari argumen pada _plugin_ `PodTopologySpread` +di dalam sebuah [profil penjadwalan](/docs/reference/scheduling/profiles). +Batasan dispesifikasikan dengan [API yang sama dengan di atas](#api), kecuali bagian `labelSelector` +harus kosong. _selector_ akan dihitung dari Service, ReplicationController, ReplicaSet atau +StatefulSet yang dimiliki oleh Pod tersebut. + +Sebuah contoh konfigurasi sebagai berikut: + + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1alpha2 +kind: KubeSchedulerConfiguration + +profiles: + pluginConfig: + - name: PodTopologySpread + args: + defaultConstraints: + - maxSkew: 1 + topologyKey: failure-domain.beta.kubernetes.io/zone + whenUnsatisfiable: ScheduleAnyway +``` + +{{< note >}} +Nilai yang dihasilkan oleh batasan penjadwalan bawaan mungkin akan konflik dengan +nilai yang dihasilkan oleh +[`DefaultPodTopologySpread` plugin](/docs/reference/scheduling/profiles/#scheduling-plugins). +Direkomendasikan untuk kamu menonaktifkan _plugin_ ini dalam profil penjadwalan ketika +menggunakan batasan _default_ untuk `PodTopologySpread`. +{{< /note >}} + +## Perbandingan dengan PodAffinity/PodAntiAffinity + +Di Kubernetes, arahan yang terkait dengan "Afinitas" mengontrol bagaimana Pod dijadwalkan - +lebih terkumpul atau lebih tersebar. + +- Untuk `PodAffinity`, kamu dapat mencoba mengumpulkan beberapa Pod ke dalam suatu +domain topologi yang memenuhi syarat. +- Untuk `PodAntiAffinity`, hanya satu Pod yang dalam dijadwalkan pada sebuah domain topologi. + +Fitur "EvenPodsSpread" memberikan opsi fleksibilas untuk mendistribusikan Pod secara merata +pada domain topologi yang berbeda, untuk meraih ketersediaan yang tinggi atau menghemat biaya. +Ini juga dapat membantu saat perbaruan bergilir dan menaikan jumlah replika dengan lancar. +Silakan baca [motivasi](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-even-pods-spreading.md#motivation) untuk lebih detail. + +## Limitasi yang diketahui + +Pada versi 1.18, dimana fitur ini masih Beta, beberapa limitasi yang sudah diketahui: + +- Pengurangan jumlah Deployment akan membuat ketidakseimbangan pada persebaran Pod. +- Pod yang cocok pada _tainted_ Node akan dihargai. Lihat [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921) + +{{% /capture %}} diff --git a/content/id/docs/reference/access-authn-authz/rbac.md b/content/id/docs/reference/access-authn-authz/rbac.md new file mode 100644 index 0000000000..27d060329f --- /dev/null +++ b/content/id/docs/reference/access-authn-authz/rbac.md @@ -0,0 +1,1195 @@ +--- +title: Menggunakan Otorisasi RBAC +content_template: templates/concept +aliases: [../../../rbac/] +weight: 70 +--- + +{{% capture overview %}} +Kontrol akses berbasis peran (RBAC) adalah metode pengaturan akses ke sumber daya komputer +atau jaringan berdasarkan peran pengguna individu dalam organisasi kamu. +{{% /capture %}} + +{{% capture body %}} +Otorisasi RBAC menggunakan `rbac.authorization.k8s.io` kelompok API untuk mengendalikan keputusan +otorisasi, memungkinkan kamu untuk mengkonfigurasi kebijakan secara dinamis melalui API Kubernetes. + +Untuk mengaktifkan RBAC, jalankan Kubernetes dengan _flag_ `--authorization-mode` atur +dengan daftar yang dipisahkan koma dengan menyertakan `RBAC`; +sebagai contoh: +```shell +kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options +``` + +## Objek API {#api-overview} + +API RBAC mendeklarasikan empat jenis objek Kubernetes: Role, ClusterRole, +RoleBinding and ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain. + +{{< caution >}} +Objek-objek ini, dengan disengaja, memaksakan pembatasan akses. Jika kamu melakukan perubahan +ke klaster saat kamu belajar, lihat +[pencegahan eskalasi hak istimewa dan _bootstrap_](#privilege-eskalasi-pencegahan-dan-bootstrap) +untuk memahami bagaimana pembatasan tersebut dapat mencegah kamu melakukan beberapa perubahan. +{{< /caution >}} + +### Role dan ClusterRole + +Sebuah RBAC Role atau ClusterRole berisi aturan yang mewakili sekumpulan izin. +Izin bersifat aditif (tidak ada aturan "tolak"). + +Sebuah Role selalu mengatur izin dalam Namespace tertentu; +ketika kamu membuat Role, kamu harus menentukan Namespace tempat Role tersebut berada. + +ClusterRole, sebaliknya, adalah sumber daya tanpa Namespace. Sumber daya tersebut memiliki nama yang berbeda (Role +dan ClusterRole) karena objek Kubernetes selalu harus menggunakan Namespace atau tanpa Namespace; +tidak mungkin keduanya. + +ClusterRole memiliki beberapa kegunaan. Kamu bisa menggunakan ClusterRole untuk: + +1. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam sebuah Namespace atau lebih +1. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam seluruh Namespace +1. mendefinisikan izin pada sumber daya yang dicakup klaster + +Jika kamu ingin mendefinisikan sebuah peran dalam Namespace, gunakan Role; jika kamu ingin mendefinisikan +peran di level klaster, gunakan ClusterRole. + +#### Contoh Role + +Berikut adalah contoh Role dalam Namespace bawaan yang dapat digunakan +untuk memberikan akses baca pada Pod: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + Namespace: default + name: pod-reader +rules: +- apiGroups: [""] # "" mengindikasikan core API group + resources: ["pods"] + verbs: ["get", "watch", "list"] +``` + +#### Contoh ClusterRole + +ClusterRole dapat digunakan untuk memberikan izin yang sama dengan Role. +Karena ClusterRole memiliki lingkup-klaster, kamu juga dapat menggunakannya untuk memberikan akses ke: + +* sumber daya lingkup-klaster (seperti Nodes) +* berbagai _endpoint_ non-sumber daya (seperti `/healthz`) +* sumber daya Namespace (seperti Pod), di semua Namespace + Sebagai contoh: kamu bisa menggunakan ClusterRole untuk memungkinkan pengguna tertentu untuk menjalankan +`kubectl get pods --all-namespaces`. + +Berikut adalah contoh ClusterRole yang dapat digunakan untuk memberikan akses baca pada +Secret di Namespace tertentu, atau di semua Namespace (tergantung bagaimana itu [terikat](#rolebinding-dan-clusterrolebinding)): + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + # "namespace" dihilangkan karena ClusterRole tidak menggunakan Namespace + name: secret-reader +rules: +- apiGroups: [""] + # +  # di tingkat HTTP, nama sumber daya untuk mengakses objek Secret +  # adalah "secrets" + resources: ["secrets"] + verbs: ["get", "watch", "list"] +``` + +Nama objek Role dan ClusterRole harus menggunakan [nama _path segment_](/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid. + +### RoleBinding dan ClusterRoleBinding + +Sebuah RoleBinding memberikan izin yang ditentukan dalam sebuah Role kepada pengguna atau sekelompok pengguna. +Ini menyimpan daftar subjek (pengguna, grup, atau ServiceAccount), dan referensi ke +Role yang diberikan. +RoleBinding memberikan izin dalam Namespace tertentu sedangkan ClusterRoleBinding +memberikan akses tersebut pada lingkup klaster. + +RoleBinding dapat merujuk Role apa pun di Namespace yang sama. Atau, RoleBinding +dapat mereferensikan ClusterRole dan memasangkan ClusterRole tersebut ke Namespace dari RoleBinding. +Jika kamu ingin memasangkan ClusterRole ke semua Namespace di klaster kamu, kamu dapat menggunakan +ClusterRoleBinding. + +Nama objek RoleBinding atau ClusterRoleBinding harus valid menggunakan +[nama _path segment_](/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid. + +#### Contoh RoleBinding + +Berikut adalah contoh dari RoleBinding yang memberikan Role "pod-reader" kepada pengguna "jane" +pada Namespace bawaan. +Ini memungkinkan "jane" untuk membaca Pod di Namespace bawaan. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# Role binding memungkinkan "jane" untuk membaca Pod di Namespace bawaan +# Kamu harus sudah memiliki Role bernama "pod-reader" di Namespace tersebut. +kind: RoleBinding +metadata: + name: read-pods + namespace: default +subjects: +# Kamu bisa mencantumkan lebih dari satu "subjek" +- kind: User + name: jane # "name" peka huruf besar-kecil + apiGroup: rbac.authorization.k8s.io +roleRef: + # "roleRef" menentukan pengikatan ke Role / ClusterRole + kind: Role # ini harus Role atau ClusterRole + name: pod-reader # ini harus sesuai dengan nama Role atau ClusterRole yang ingin kamu gunakan + apiGroup: rbac.authorization.k8s.io +``` + +RoleBinding juga bisa mereferensikan ClusterRole untuk memberikan izin yang didefinisikan di dalam +ClusterRole ke sumber daya di dalam Namespace RoleBinding. Referensi semacam ini +memungkinkan kamu menentukan sekumpulan Role yang umum di seluruh klaster kamu, lalu menggunakannya kembali di dalam +beberapa Namespace. + +Sebagai contoh, meskipun RoleBinding berikut merujuk ke ClusterRole, +"dave" (subjek, peka huruf besar-kecil) hanya akan dapat membaca Secret di dalam Namespace "development", +karena Namespace RoleBinding (di dalam metadata-nya) adalah "development". + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# role binding memungkinkan "dave" untuk membaca Secret di Namespace "development". +# Kamu sudah harus memiliki ClusterRole bernama "secret-reader". +kind: RoleBinding +metadata: + name: read-secrets + # + # Namespace dari RoleBinding menentukan dimana izin akan diberikan. + # Ini hanya memberikan izin di dalam Namespace "development". + namespace: development +subjects: +- kind: User + name: dave # Nama peka huruf besar-kecil + apiGroup: rbac.authorization.k8s.io +roleRef: + kind: ClusterRole + name: secret-reader + apiGroup: rbac.authorization.k8s.io +``` + +#### Contoh ClusterRoleBinding + +Untuk memberikan izin di seluruh klaster, kamu dapat menggunakan ClusterRoleBinding. +ClusterRoleBinding berikut memungkinkan seluruh pengguna di dalam kelompok "manager" untuk +membaca Secret di berbagai Namespace. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# Cluster role binding ini memungkinkan siapapun di dalam kelompok "manager" untuk membaca Secret di berbagai Namespace. +kind: ClusterRoleBinding +metadata: + name: read-secrets-global +subjects: +- kind: Group + name: manager # Nama peka huruf besar-kecil + apiGroup: rbac.authorization.k8s.io +roleRef: + kind: ClusterRole + name: secret-reader + apiGroup: rbac.authorization.k8s.io +``` +Setelah kamu membuat sebuat ikatan, kamu tidak dapat mengganti Role atau ClusterRole dirujuk. +Jika kamu mencoba mengganti sebuah ikatan `roleRef`, kamu mendapatkan kesalahan validasi. Jika kamu +tidak ingin mengganti `roleRef` untuk sebuah ikatan, kamu harus menghapus objek ikatan tersebut dan membuat +sebuah pengganti. + +Ada dua alasan untuk pembatasan tersebut: + +1. Membuat `roleRef` tidak dapat diubah memungkinkan seseorang untuk melakukan `update` pada objek ikatan yang ada, +sehingga mereka dapat mengelola daftar subyek, tanpa bisa berubah +Role yang diberikan kepada subyek tersebut. + +1. Ikatan pada Role yang berbeda adalah ikatan yang berbeda secara fundamental. +Mengharuskan sebuah ikatan untuk dihapus/diciptakan kembali untuk dalam upaya mengubah `roleRef` akan +memastikan daftar lengkap subyek dalam ikatan akan diberikan diberikan +Role baru (sebagai langkah untuk mencegah modifikasi secara tidak sengaja hanya pada roleRef +tanpa memverifikasi semua subyek yang seharusnya diberikan izin pada Role baru). + +Utilitas baris perintah `kubectl auth reconcile` membuat atau memperbaharui berkas manifes yang mengandung objek RBAC, +dan menangani penghapusan dan pembuatan objek ikatan jika dibutuhkan untuk mengganti Role yang dirujuk. +Lihat [penggunaan perintah dan contoh](#kubectl-auth-reconcile) untuk informasi tambahan. + +### Mengacu pada sumber daya + +Pada API Kubernetes, sebagian besar sumber daya diwakili dan diakses menggunakan representasi +nama objek, seperti `pods` untuk Pod. RBAC mengacu pada sumber daya yang menggunakan nama yang persis sama +dengan yang muncul di URL untuk berbagai _endpoint_ API yang relevan. +Beberapa Kubernetes APIs melibatkan +_subresource_, seperti catatan untuk Pod. Permintaan untuk catatan Pod terlihat seperti: + +```http +GET /api/v1/namespaces/{namespace}/pods/{name}/log +``` + +Dalam hal ini, `pods` adalah sumber daya Namespace untuk sumber daya Pod, dan `log` adalah sebuah +sub-sumber daya `pods`. Untuk mewakili ini dalam sebuah Role RBAC, gunakan garis miring (`/`) untuk +membatasi sumber daya dan sub-sumber daya. Untuk memungkinkan subjek membaca `pods` dan +juga mengakses sub-sumber daya `log` untuk masing-masing Pod tersebut, kamu dapat menulis: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: pod-and-pod-logs-reader +rules: +- apiGroups: [""] + resources: ["pods", "pods/log"] + verbs: ["get", "list"] +``` + +Kamu juga dapat merujuk ke sumber daya dengan nama untuk permintaan tertentu melalui daftar `resourceNames`. +Ketika nama dicantumkan, permintaan dapat dibatasi untuk setiap objek sumber daya. +Berikut adalah contoh yang membatasi subjeknya hanya untuk melakukan `get` atau` update` pada sebuah +ConfigMap bernama `my-configmap`: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: configmap-updater +rules: +- apiGroups: [""] + # + # pada level HTTP, nama sumber daya untuk mengakses objek ConfigMap + # adalah "configmaps" + resources: ["configmaps"] + resourceNames: ["my-configmap"] + verbs: ["update", "get"] +``` + +{{< note >}} +Kamu tidak dapat membatasi permintaan `create` atau` deletecollection` dengan nama sumber daya. Untuk `create`, +Keterbatasan ini dikarenakan nama objek yang tidak dikenal pada waktu otorisasi. +{{< /note >}} + +### Agregat ClusterRole + +Kamu dapat mengumpulkan beberapa ClusterRole menjadi satu ClusterRole gabungan. +_Controller_, yang berjalan sebagai bagian dari _control plane_ klaster, mengamati objek ClusterRole +dengan `aggregationRule`. `AggregationRule` mendefinisikan label +Selector yang digunakan oleh _Controller_ untuk mencocokkan objek ClusterRole lain +yang harus digabungkan ke dalam `rules`. + +Berikut adalah contoh ClusterRole agregat: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: monitoring +aggregationRule: + clusterRoleSelectors: + - matchLabels: + rbac.example.com/aggregate-to-monitoring: "true" +rules: [] # _Control plane_ secara otomatis mengisi rules +``` + +Jika kamu membuat ClusterRole baru yang cocok dengan _selector_ label dari ClusterRole agregat yang ada, +perubahan itu memicu penambahan aturan baru ke dalam ClusterRole agregat. +Berikut adalah contoh yang menambahkan aturan ke "monitoring" ClusterRole, dengan membuat sebuah +ClusterRole lain berlabel `rbac.example.com/aggregate-to-monitoring: true`. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: monitoring-endpoints + labels: + rbac.example.com/aggregate-to-monitoring: "true" +# ketika kamu membuat ClusterRole "monitoring-endpoints", +# aturan di bawah ini akan ditambahkan ke ClusterRole "monitoring". +rules: +- apiGroups: [""] + resources: ["services", "endpoints", "pods"] + verbs: ["get", "list", "watch"] +``` + +[Role bawaan pengguna](#role-dan-role-binding-bawaan) menggunakan agregasi ClusterRole. Ini memungkinkan kamu, +sebagai administrator klaster, menambahkan aturan untuk sumber daya kustom, seperti yang dilayani oleh CustomResourceDefinition +atau _aggregated_ server API, untuk memperluas Role bawaan. + +Sebagai contoh: ClusterRole berikut mengizinkan Role bawaan "admin" dan "edit" mengelola sumber daya kustom +bernama CronTab, sedangkan Role "view" hanya dapat melakukan tindakan membaca sumber daya CronTab. +Kamu dapat mengasumsikan bahwa objek CronTab dinamai `"crontab"` dalam URL yang terlihat oleh server API. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: aggregate-cron-tabs-edit + labels: + # Tambahkan izin berikut ke Role bawaan "admin" and "edit". + rbac.authorization.k8s.io/aggregate-to-admin: "true" + rbac.authorization.k8s.io/aggregate-to-edit: "true" +rules: +- apiGroups: ["stable.example.com"] + resources: ["crontabs"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +--- +kind: ClusterRole +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: aggregate-cron-tabs-view + labels: + # Tambahkan izin berikut ke Role bawaan "view" + rbac.authorization.k8s.io/aggregate-to-view: "true" +rules: +- apiGroups: ["stable.example.com"] + resources: ["crontabs"] + verbs: ["get", "list", "watch"] +``` + +#### Contoh Role + +Contoh berikut adalah potongan dari objek Role atau ClusterRole, yang hanya menampilkan +bagian `rules`. + +Mengizinkan pembacaan sumber daya `"pods`` pada kumpulan API inti: + +```yaml +rules: +- apiGroups: [""] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Pod + # adalah "pods" + resources: ["pods"] + verbs: ["get", "list", "watch"] +``` + +Mengizinkan pembacaan/penulisan Deployment (pada tingkat HTTP: objek dengan `"deployments"` +di bagian sumber daya dari URL) pada masing-masing kumpulan API `"extensions"` dan `"apps"`: + +```yaml +rules: +- apiGroups: ["extensions", "apps"] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Deployment + # adalah "deployments" + resources: ["deployments"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +``` + +Mengizinkan pembacaan pada Pods pada kumpulan API inti, dan juga serta pembacaan atau penulisan Job +di kumpulan API `"batch"` atau `"extensions"`: + +```yaml +rules: +- apiGroups: [""] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Pod + # adalah "pods" + resources: ["pods"] + verbs: ["get", "list", "watch"] +- apiGroups: ["batch", "extensions"] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Job + # adalah "jobs" + resources: ["jobs"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +``` + +Mengizinkan pembacaan ConfigMap bernama "my-config" (harus terikat dengan +RoleBinding untuk membatasi pada sebuah ConfigMap di sebuah Namespace): + +```yaml +rules: +- apiGroups: [""] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek ConfigMap + # adalah "configmaps" + resources: ["configmaps"] + resourceNames: ["my-config"] + verbs: ["get"] +``` + +Mengizinkan pembacaan sumber daya `"nodes"` pada kumpulan API inti (karena sebuah node +ada pada lingkup-klaster, ini harus berupa ClusterRole yang terikat dengan ClusterRoleBinding +agar efektif): + +```yaml +rules: +- apiGroups: [""] + # + # pada tingkat HTTP, nama dari sumber daya untuk mengakses objek Node + # adalah "nodes" + resources: ["nodes"] + verbs: ["get", "list", "watch"] +``` + +Mengizinkan permintaan GET dan POST kepada _endpoint_ non-sumber daya `/healthz` dan seluruh _subpath_ +(harus berada di dalam ClusterRole yang terikat dengan ClusterRoleBinding agar efektif): + +```yaml +rules: +- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match + verbs: ["get", "post"] +``` + +### Mengacu Pada Subjek + +RoleBinding atau ClusterRoleBinding mengikat sebuah Role ke subjek. +Subjek dapat berupa kelompok, pengguna atau ServiceAccount. + +Kubernetes merepresentasikan _username_ sebagai string. +Ini bisa berupa: nama sederhana, seperti "alice"; email, seperti "bob@example.com"; +atau ID pengguna numerik yang direpresentasikan sebagai string. Terserah kamu sebagai administrator klaster +untuk mengkonfigurasi [modul otentikasi](/docs/reference/access-authn-authz/authentication/) +sehingga otentikasi menghasilkan _username_ dalam format yang kamu inginkan. + +{{< caution >}} +Awalan `system:` direservasi untuk sistem Kubernetes, jadi kamu harus memastikan +bahwa kamu tidak memiliki pengguna atau grup dengan nama yang dimulai dengan `system:` secara tidak sengaja. +Selain awalan khusus ini, sistem otorisasi RBAC tidak memerlukan format apa pun +untuk nama pengguna. +{{< /caution >}} + +Di Kubernetes, modul otentikasi menyediakan informasi grup. +Grup, seperti halnya pengguna, direpresentasikan sebagai string, dan string tersebut tidak memiliki format tertentu, +selain awalan `system:` yang sudah direservasi. + +[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`. + +{{< note >}} +- `system:serviceaccount:` (tunggal) adalah awalan untuk ServiceAccount _username_. +- `system:serviceaccounts:` (jamak) adalah awalan untuk ServiceAccount grup. +{{< /note >}} + +#### Contoh RoleBinding {#role-binding-examples} + +Contoh-contoh berikut ini hanya potongan RoleBinding yang hanya memperlihatkan +bagian `subjects`. + +Untuk pengguna bernama `alice@example.com`: + +```yaml +subjects: +- kind: User + name: "alice@example.com" + apiGroup: rbac.authorization.k8s.io +``` + +Untuk grup bernama `frontend-admins`: + +```yaml +subjects: +- kind: Group + name: "frontend-admins" + apiGroup: rbac.authorization.k8s.io +``` + +Untuk ServiceAccount bawaan di Namespace "kube-system": + +```yaml +subjects: +- kind: ServiceAccount + name: default + namespace: kube-system +``` + +Untuk seluruh ServiceAccount di Namespace qa: + +```yaml +subjects: +- kind: Group + name: system:serviceaccounts:qa + apiGroup: rbac.authorization.k8s.io +``` + +Untuk seluruh ServiceAccount di Namespace apapun: + +```yaml +subjects: +- kind: Group + name: system:serviceaccounts + apiGroup: rbac.authorization.k8s.io +``` + +Untuk seluruh pengguna yang terotentikasi: + +```yaml +subjects: +- kind: Group + name: system:authenticated + apiGroup: rbac.authorization.k8s.io +``` + +Untuk seluruh pengguna yang tidak terotentikasi: + +```yaml +subjects: +- kind: Group + name: system:unauthenticated + apiGroup: rbac.authorization.k8s.io +``` + +Untuk seluruh pengguna: + +```yaml +subjects: +- kind: Group + name: system:authenticated + apiGroup: rbac.authorization.k8s.io +- kind: Group + name: system:unauthenticated + apiGroup: rbac.authorization.k8s.io +``` + +## Role dan RoleBinding Bawaan + +API membuat satu set objek ClusterRole dan ClusterRoleBinding bawaan. +Sebagian besar dari objek berawalan `system:`, menunjukkan bahwa sumber daya tersebut +secara langsung dikelolah oleh _control plane_ klaster. Seluruh ClusterRole dan ClusterRoleBinding dilabeli dengan +`kubernetes.io/bootstrapping=rbac-defaults`. + +{{< caution >}} +Berhati-hatilah saat memodifikasi CLusterRole dan ClusterRoleBinding dengan nama yang +memiliki awalan `system:`. +Modifikasi sumber daya ini dapat mengakibatkan klaster yang malfungsi. +{{< /caution >}} + +### Rekonsiliasi Otomatis + +Pada setiap _start-up-_, server API memperbaharui ClusterRole bawaan dengan berbagai izin yang hilang, +dan memperbaharui ikatan ClusterRole bawaan dengan subjek yang hilang. +Ini memungkinkan klaster untuk memperbaiki modifikasi yang tidak disengaja, dan membantu menjaga Role +dan RoleBinding selalu terkini karena izin dan subjek berubah pada rilis terbaru Kubernetes. + +Untuk menon-aktifkan rekonsiliasi ini, setel anotasi `rbac.authorization.kubernetes.io/autoupdate` +pada ClusterRole bawaan atau RoleBinding bawaan menjadi `false`. +Ingat bahwa hilangnya izin dan subjek bawaan dapat mengakibatkan klaster tidak berfungsi. + +Rekonsiliasi otomatis diaktifkan secara bawaan jika otorizer RBAC aktif. + +### Role API discovery {#discovery-roles} + +RoleBinding bawaan memberi otorisasi kepada pengguna yang tidak terotentikasi untuk membaca informasi API yang dianggap aman +untuk diakses publik (termasuk CustomResourceDefinitions). Untuk menonaktifkan akses anonim, tambahkan `--anonymous-auth=false` ke konfigurasi server API. + +Untuk melihat konfigurasi Role ini melalui `kubectl` jalankan perintah: + +```shell +kubectl get clusterroles system:discovery -o yaml +``` + +{{< note >}} +Jika kamu mengubah ClusterRole tersebut, perubahan kamu akan ditimpa pada penyalaan ulang server API melalui +[rekonsiliasi-otomatis](#auto-reconciliation). Untuk menghindari penulisan ulang tersebut, hindari mengubah Role secara manual, +atau nonaktifkan rekonsiliasi otomatis +{{< /note >}} + + + + + + + + + + + + + + + + + + + + + + + + +
Kubernetes RBAC API discovery roles
ClusterRole BawaanClusterRoleBinding BawaanDeskripsi
system:basic-usersystem:authenticated groupMengizinkan pengguna hanya dengan akses baca untuk mengakses informasi dasar tentang diri mereka sendiri. Sebelum v1.14, Role ini juga terikat pada system:unauthenticated secara bawaan.
system:discoverysystem:authenticated groupMengizinkan akses baca pada berbagai _API discovery endpoint_ yang dibutuhkan untuk menemukan dan melakukan negosiasi pada tingkat API. Sebelum v1.14, Role ini juga terikat pada system:unauthenticated secara bawaan.
system:public-info-viewersystem:authenticated and system:unauthenticated groupsMengizinkan akses baca pada informasi yang tidak sensitif tentang klaster. Diperkenalkan pada Kubernetes v1.14.
+ +### Role Pengguna + +Beberapa ClusterRole bawaan tidak diawali dengan `system:`. Ini dimaksudkan untuk Role pengguna. +Ini termasuk Role super-user (`cluster-admin`), Role yang dimaksudkan untuk diberikan akses seluruh klaster dengan +menggunakan ClusterRoleBinding, dan Role yang dimaksudkan untuk diberikan pada Namespace tertentu +dengan menggunakan RoleBinding (`admin`, `edit`, `view`). + +ClusterRole menggunakan [aggregasi ClusterRole](#aggregated-clusterroles) untuk mengizinkan admin untuk memasukan peraturan untuk sumber daya khusus pada ClusterRole ini. Untuk menambahkan aturan kepada Role `admin`, `edit`, atau `view`, buat sebuah CLusterRole +dengan satu atau lebih label berikut: + +```yaml +metadata: + labels: + rbac.authorization.k8s.io/aggregate-to-admin: "true" + rbac.authorization.k8s.io/aggregate-to-edit: "true" + rbac.authorization.k8s.io/aggregate-to-view: "true" +``` + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ClusterRole BawaanClusterRoleBinding BawaanDeskripsi
cluster-adminsystem:masters groupMengizinkan akses super-user access untuk melakukan berbagai aksi pada berbagai sumber daya. +Ketika digunakan pada ClusterRoleBinding, ini memberikan kendali penuh terhadap seluruh sumber daya pada klaster dan seluruh Namespace. +Ketika digunakan pada RoleBinding, ini memberikan kendali penuh terhadap setiap sumber daya pada Namespace RoleBinding, termasuk Namespace itu sendiri.
adminNonemengizinkan akses admin, yang dimaksudkan untuk diberikan dalam sebuah Namespace menggunakan RoleBinding. +Jika digunakan dalam RoleBinding, ini memungkikan akses baca/tulis ke sebagian besar sumber daya di sebuah Namespace, +termasuk kemampuan untuk membuat Role dan RoleBinding dalam Namespace. +Role ini tidak memungkinkan akses tulis pada kuota sumber daya atau ke Namespace itu sendiri.
editNoneMengizinkan akses baca/tulis pada seluruh objek dalam Namespace. + +Role ini tidak memungkinkan untuk melihat dan merubah Role dan RoleBinding. +Namun, Role ini memungkinkan untuk mengakses Secret dan menjalankan Pod seperti ServiceAccount dalam Namespace, +sehingga dapat digunakan untuk mendapatkan tingkat akses API dari setiap ServiceAccount di Namespace. +
viewNoneMengizinkan akses baca untuk melihat hampir seluruh objek dalam Namespace. + +Ini tidak memungkinkan untuk melihat Role dan RoleBinding. + +Role ini tidak memungkikan melihat Secret, karena pembacaan konten Secret memungkinkan +akses ke kredensial ServiceAccount dalam Namespace, yang akan memungkinkan akses API sebagai +ServiceAccount apapun di Namespace (bentuk eskalasi hak istimewa). +
+ +### Core component roles + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Default ClusterRoleDefault ClusterRoleBindingDescription
system:kube-schedulersystem:kube-scheduler userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} component.
system:volume-schedulersystem:kube-scheduler userAllows access to the volume resources required by the kube-scheduler component.
system:kube-controller-managersystem:kube-controller-manager userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} component. +The permissions required by individual controllers are detailed in the controller roles.
system:nodeNoneAllows access to resources required by the kubelet, including read access to all secrets, and write access to all pod status objects. + +You should use the Node authorizer and NodeRestriction admission plugin instead of the system:node role, and allow granting API access to kubelets based on the Pods scheduled to run on them. + +The system:node role only exists for compatibility with Kubernetes clusters upgraded from versions prior to v1.8. +
system:node-proxiersystem:kube-proxy userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.
+ +### Other component roles + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Default ClusterRoleDefault ClusterRoleBindingDescription
system:auth-delegatorNoneAllows delegated authentication and authorization checks. +This is commonly used by add-on API servers for unified authentication and authorization.
system:heapsterNoneRole for the Heapster component (deprecated).
system:kube-aggregatorNoneRole for the kube-aggregator component.
system:kube-dnskube-dns service account in the kube-system namespaceRole for the kube-dns component.
system:kubelet-api-adminNoneAllows full access to the kubelet API.
system:node-bootstrapperNoneAllows access to the resources required to perform +kubelet TLS bootstrapping.
system:node-problem-detectorNoneRole for the node-problem-detector component.
system:persistent-volume-provisionerNoneAllows access to the resources required by most dynamic volume provisioners.
+ +### Roles for built-in controllers {#controller-roles} + +The Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} runs +{{< glossary_tooltip term_id="controller" text="controllers" >}} that are built in to the Kubernetes +control plane. +When invoked with `--use-service-account-credentials`, kube-controller-manager starts each controller +using a separate service account. +Corresponding roles exist for each built-in controller, prefixed with `system:controller:`. +If the controller manager is not started with `--use-service-account-credentials`, it runs all control loops +using its own credential, which must be granted all the relevant roles. +These roles include: + +* `system:controller:attachdetach-controller` +* `system:controller:certificate-controller` +* `system:controller:clusterrole-aggregation-controller` +* `system:controller:cronjob-controller` +* `system:controller:daemon-set-controller` +* `system:controller:deployment-controller` +* `system:controller:disruption-controller` +* `system:controller:endpoint-controller` +* `system:controller:expand-controller` +* `system:controller:generic-garbage-collector` +* `system:controller:horizontal-pod-autoscaler` +* `system:controller:job-controller` +* `system:controller:namespace-controller` +* `system:controller:node-controller` +* `system:controller:persistent-volume-binder` +* `system:controller:pod-garbage-collector` +* `system:controller:pv-protection-controller` +* `system:controller:pvc-protection-controller` +* `system:controller:replicaset-controller` +* `system:controller:replication-controller` +* `system:controller:resourcequota-controller` +* `system:controller:root-ca-cert-publisher` +* `system:controller:route-controller` +* `system:controller:service-account-controller` +* `system:controller:service-controller` +* `system:controller:statefulset-controller` +* `system:controller:ttl-controller` + +## Privilege escalation prevention and bootstrapping + +The RBAC API prevents users from escalating privileges by editing roles or role bindings. +Because this is enforced at the API level, it applies even when the RBAC authorizer is not in use. + +### Restrictions on role creation or update + +You can only create/update a role if at least one of the following things is true: + +1. You already have all the permissions contained in the role, at the same scope as the object being modified +(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role). +2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group. + +For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRole +containing that permission. To allow a user to create/update roles: + +1. Grant them a role that allows them to create/update Role or ClusterRole objects, as desired. +2. Grant them permission to include specific permissions in the roles they create/update: + * implicitly, by giving them those permissions (if they attempt to create or modify a Role or ClusterRole with permissions they themselves have not been granted, the API request will be forbidden) + * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group + +### Restrictions on role binding creation or update + +You can only create/update a role binding if you already have all the permissions contained in the referenced role +(at the same scope as the role binding) *or* if you have been authorized to perform the `bind` verb on the referenced role. +For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRoleBinding +to a role that grants that permission. To allow a user to create/update role bindings: + +1. Grant them a role that allows them to create/update RoleBinding or ClusterRoleBinding objects, as desired. +2. Grant them permissions needed to bind a particular role: + * implicitly, by giving them the permissions contained in the role. + * explicitly, by giving them permission to perform the `bind` verb on the particular Role (or ClusterRole). + +For example, this ClusterRole and RoleBinding would allow `user-1` to grant other users the `admin`, `edit`, and `view` roles in the namespace `user-1-namespace`: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: role-grantor +rules: +- apiGroups: ["rbac.authorization.k8s.io"] + resources: ["rolebindings"] + verbs: ["create"] +- apiGroups: ["rbac.authorization.k8s.io"] + resources: ["clusterroles"] + verbs: ["bind"] + resourceNames: ["admin","edit","view"] +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: role-grantor-binding + namespace: user-1-namespace +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: role-grantor +subjects: +- apiGroup: rbac.authorization.k8s.io + kind: User + name: user-1 +``` + +When bootstrapping the first roles and role bindings, it is necessary for the initial user to grant permissions they do not yet have. +To bootstrap initial roles and role bindings: + +* Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings. +* If your API server runs with the insecure port enabled (`--insecure-port`), you can also make API calls via that port, which does not enforce authentication or authorization. + +## Command-line utilities + +### `kubectl create role` + +Creates a Role object defining permissions within a single namespace. Examples: + +* Create a Role named "pod-reader" that allows users to perform `get`, `watch` and `list` on pods: + + ```shell + kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods + ``` + +* Create a Role named "pod-reader" with resourceNames specified: + + ```shell + kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod + ``` + +* Create a Role named "foo" with apiGroups specified: + + ```shell + kubectl create role foo --verb=get,list,watch --resource=replicasets.apps + ``` + +* Create a Role named "foo" with subresource permissions: + + ```shell + kubectl create role foo --verb=get,list,watch --resource=pods,pods/status + ``` + +* Create a Role named "my-component-lease-holder" with permissions to get/update a resource with a specific name: + + ```shell + kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component + ``` + +### `kubectl create clusterrole` + +Creates a ClusterRole. Examples: + +* Create a ClusterRole named "pod-reader" that allows user to perform `get`, `watch` and `list` on pods: + + ```shell + kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods + ``` + +* Create a ClusterRole named "pod-reader" with resourceNames specified: + + ```shell + kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod + ``` + +* Create a ClusterRole named "foo" with apiGroups specified: + + ```shell + kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps + ``` + +* Create a ClusterRole named "foo" with subresource permissions: + + ```shell + kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status + ``` + +* Create a ClusterRole named "foo" with nonResourceURL specified: + + ```shell + kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* + ``` + +* Create a ClusterRole named "monitoring" with an aggregationRule specified: + + ```shell + kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" + ``` + +### `kubectl create rolebinding` + +Grants a Role or ClusterRole within a specific namespace. Examples: + +* Within the namespace "acme", grant the permissions in the "admin" ClusterRole to a user named "bob": + + ```shell + kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme + ``` + +* Within the namespace "acme", grant the permissions in the "view" ClusterRole to the service account in the namespace "acme" named "myapp": + + ```shell + kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme + ``` + +* Within the namespace "acme", grant the permissions in the "view" ClusterRole to a service account in the namespace "myappnamespace" named "myapp": + + ```shell + kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme + ``` + +### `kubectl create clusterrolebinding` + +Grants a ClusterRole across the entire cluster (all namespaces). Examples: + +* Across the entire cluster, grant the permissions in the "cluster-admin" ClusterRole to a user named "root": + + ```shell + kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root + ``` + +* Across the entire cluster, grant the permissions in the "system:node-proxier" ClusterRole to a user named "system:kube-proxy": + + ```shell + kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy + ``` + +* Across the entire cluster, grant the permissions in the "view" ClusterRole to a service account named "myapp" in the namespace "acme": + + ```shell + kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp + ``` + +### `kubectl auth reconcile` {#kubectl-auth-reconcile} + +Creates or updates `rbac.authorization.k8s.io/v1` API objects from a manifest file. + +Missing objects are created, and the containing namespace is created for namespaced objects, if required. + +Existing roles are updated to include the permissions in the input objects, +and remove extra permissions if `--remove-extra-permissions` is specified. + +Existing bindings are updated to include the subjects in the input objects, +and remove extra subjects if `--remove-extra-subjects` is specified. + +Examples: + +* Test applying a manifest file of RBAC objects, displaying changes that would be made: + + ``` + kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client + ``` + +* Apply a manifest file of RBAC objects, preserving any extra permissions (in roles) and any extra subjects (in bindings): + + ```shell + kubectl auth reconcile -f my-rbac-rules.yaml + ``` + +* Apply a manifest file of RBAC objects, removing any extra permissions (in roles) and any extra subjects (in bindings): + + ```shell + kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions + ``` + +## ServiceAccount permissions {#service-account-permissions} + +Default RBAC policies grant scoped permissions to control-plane components, nodes, +and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace +(beyond discovery permissions given to all authenticated users). + +This allows you to grant particular roles to particular ServiceAccounts as needed. +Fine-grained role bindings provide greater security, but require more effort to administrate. +Broader grants can give unnecessary (and potentially escalating) API access to +ServiceAccounts, but are easier to administrate. + +In order from most secure to least secure, the approaches are: + +1. Grant a role to an application-specific service account (best practice) + + This requires the application to specify a `serviceAccountName` in its pod spec, + and for the service account to be created (via the API, application manifest, `kubectl create serviceaccount`, etc.). + + For example, grant read-only permission within "my-namespace" to the "my-sa" service account: + + ```shell + kubectl create rolebinding my-sa-view \ + --clusterrole=view \ + --serviceaccount=my-namespace:my-sa \ + --namespace=my-namespace + ``` + +2. Grant a role to the "default" service account in a namespace + + If an application does not specify a `serviceAccountName`, it uses the "default" service account. + + {{< note >}} + Permissions given to the "default" service account are available to any pod + in the namespace that does not specify a `serviceAccountName`. + {{< /note >}} + + For example, grant read-only permission within "my-namespace" to the "default" service account: + + ```shell + kubectl create rolebinding default-view \ + --clusterrole=view \ + --serviceaccount=my-namespace:default \ + --namespace=my-namespace + ``` + + Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the + "default" service account in the `kube-system` namespace. + To allow those add-ons to run with super-user access, grant cluster-admin + permissions to the "default" service account in the `kube-system` namespace. + + {{< caution >}} + Enabling this means the `kube-system` namespace contains Secrets + that grant super-user access to your cluster's API. + {{< /caution >}} + + ```shell + kubectl create clusterrolebinding add-on-cluster-admin \ + --clusterrole=cluster-admin \ + --serviceaccount=kube-system:default + ``` + +3. Grant a role to all service accounts in a namespace + + If you want all applications in a namespace to have a role, no matter what service account they use, + you can grant a role to the service account group for that namespace. + + For example, grant read-only permission within "my-namespace" to all service accounts in that namespace: + + ```shell + kubectl create rolebinding serviceaccounts-view \ + --clusterrole=view \ + --group=system:serviceaccounts:my-namespace \ + --namespace=my-namespace + ``` + +4. Grant a limited role to all service accounts cluster-wide (discouraged) + + If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts. + + For example, grant read-only permission across all namespaces to all service accounts in the cluster: + + ```shell + kubectl create clusterrolebinding serviceaccounts-view \ + --clusterrole=view \ + --group=system:serviceaccounts + ``` + +5. Grant super-user access to all service accounts cluster-wide (strongly discouraged) + + If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts. + + {{< warning >}} + This allows any application full access to your cluster, and also grants + any user with read access to Secrets (or the ability to create any pod) + full access to your cluster. + {{< /warning >}} + + ```shell + kubectl create clusterrolebinding serviceaccounts-cluster-admin \ + --clusterrole=cluster-admin \ + --group=system:serviceaccounts + ``` + +## Upgrading from ABAC + +Clusters that originally ran older Kubernetes versions often used +permissive ABAC policies, including granting full API access to all +service accounts. + +Default RBAC policies grant scoped permissions to control-plane components, nodes, +and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace +(beyond discovery permissions given to all authenticated users). + +While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions. +Here are two approaches for managing this transition: + +### Parallel authorizers + +Run both the RBAC and ABAC authorizers, and specify a policy file that contains +the [legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format): + +``` +--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json +``` + +To explain that first command line option in detail: if earlier authorizers, such as Node, +deny a request, then the the RBAC authorizer attempts to authorize the API request. If RBAC +also denies that API request, the ABAC authorizer is then run. This means that any request +allowed by *either* the RBAC or ABAC policies is allowed. + +When the kube-apiserver is run with a log level of 5 or higher for the RBAC component +(`--vmodule=rbac*=5` or `--v=5`), you can see RBAC denials in the API server log +(prefixed with `RBAC`). +You can use that information to determine which roles need to be granted to which users, groups, or service accounts. + +Once you have [granted roles to service accounts](#service-account-permissions) and workloads +are running with no RBAC denial messages in the server logs, you can remove the ABAC authorizer. + +### Permissive RBAC permissions + +You can replicate a permissive ABAC policy using RBAC role bindings. + +{{< warning >}} +The following policy allows **ALL** service accounts to act as cluster administrators. +Any application running in a container receives service account credentials automatically, +and could perform any action against the API, including viewing secrets and modifying permissions. +This is not a recommended policy. + +```shell +kubectl create clusterrolebinding permissive-binding \ + --clusterrole=cluster-admin \ + --user=admin \ + --user=kubelet \ + --group=system:serviceaccounts +``` +{{< /warning >}} + +After you have transitioned to use RBAC, you should adjust the access controls +for your cluster to ensure that these meet your information security needs. + +{{% /capture %}} diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md new file mode 100644 index 0000000000..c0a9721d81 --- /dev/null +++ b/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -0,0 +1,307 @@ +--- +title: Menginstal kubeadm +content_type: task +weight: 10 +card: + name: setup + weight: 20 + title: Menginstal alat persiapan kubeadm +--- + + + +Laman ini menunjukkan cara untuk menginstal `kubeadm`. +Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/). + + + +## {{% heading "prerequisites" %}} + + +* Satu mesin atau lebih yang menjalankan: + - Ubuntu 16.04+ + - Debian 9+ + - CentOS 7 + - Red Hat Enterprise Linux (RHEL) 7 + - Fedora 25+ + - HypriotOS v1.0.1+ + - Container Linux (teruji pada versi 1800.6.0) +* 2 GB RAM atau lebih per mesin (kurang dari nilai tersebut akan menyisakan sedikit ruang untuk + aplikasi-aplikasimu) +* 2 CPU atau lebih +* Koneksi internet pada seluruh mesin pada klaster (kamu dapat menggunakan internet + publik ataupun pribadi) +* _Hostname_ yang unik, alamat MAC, dan product_uuid untuk setiap Node. Lihat [di sini](#memastikan-alamat-mac) untuk detail lebih lanjut. +* Porta tertentu pada mesin. Lihat [di sini](#memeriksa-porta-yang-dibutuhkan) untuk detail lebih lanjut. +* _Swap_ dinonaktifkan. Kamu **HARUS** menonaktifkan _swap_ agar kubelet dapat berfungsi dengan baik. + + + + + +## Memastikan alamat MAC dan product_uuid yang unik untuk setiap Node {#memastikan-alamat-mac} + +* Kamu bisa mendapatkan alamat MAC dari antarmuka jaringan menggunakan perintah `ip link` atau `ifconfig -a` +* product_uuid didapatkan dengan perintah `sudo cat /sys/class/dmi/id/product_uuid` + +Sangat memungkinkan bagi perangkat keras untuk memiliki alamat yang unik, namun beberapa mesin virtual bisa memiliki +nilai yang identik. Kubernetes menggunakan nilai-nilai tersebut untuk mengidentifikasi Node-Node secara unik pada klaster. +Jika nilai-nilai tersebut tidak unik pada tiap Node, proses instalasi +bisa saja [gagal](https://github.com/kubernetes/kubeadm/issues/31). + +## Memeriksa adaptor jaringan + +Jika kamu memiliki lebih dari satu adaptor jaringan, dan komponen Kubernetes tidak dapat dijangkau melalui rute bawaan (_default route_), +kami merekomendasikan kamu untuk menambahkan rute IP sehingga alamat-alamat klaster Kubernetes melewati adaptor yang tepat. + +## Membuat iptables melihat _bridged traffic_ + +Agar iptables pada Node Linux dapat melihat _bridged traffic_ dengan benar, kamu harus memastikan `net.bridge.bridge-nf-call-iptables` bernilai 1 pada pengaturan `sysctl`, misalnya. + +```bash +cat <}}. + +{{< tabs name="container_runtime" >}} +{{% tab name="Linux nodes" %}} + +Secara bawaan, Kubernetes menggunakan +{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI) +sebagai perantara dengan _runtime_ Container pilihanmu. + +Jika kamu tidak menentukan _runtime_, kubeadm secara otomatis mencoba untuk mendeteksi +_runtime_ Container yang terinstal dengan memindai sekumpulan soket domain Unix yang umum digunakan. +Tabel berikut menunjukkan _runtime_ Container dan lokasi soketnya: + +{{< table caption = "_Runtime_ Container dan lokasi soketnya" >}} +| _Runtime_ | Lokasi domain soket Unix | +|------------|-----------------------------------| +| Docker | `/var/run/docker.sock` | +| containerd | `/run/containerd/containerd.sock` | +| CRI-O | `/var/run/crio/crio.sock` | +{{< /table >}} + +
+Jika ditemukan Docker dan containerd secara bersamaan, Docker akan terpilih. Hal ini diperlukan +karena Docker 18.09 dirilis dengan containerd dan keduanya dapat ditemukan meskipun kamu +hanya menginstal Docker. +Jika ditemukan selain dari kedua _runtime_ Container tersebut, kubeadm akan berhenti dengan kegagalan. + +Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya. + +Lihat [_runtime_ Container](/docs/setup/production-environment/container-runtimes/) +untuk informasi lebih lanjut. +{{% /tab %}} +{{% tab name="sistem operasi lainnya" %}} +Secara bawaan, kubeadm menggunakan {{< glossary_tooltip term_id="docker" >}} sebagai _runtime_ Container. +Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya. + +Lihat [_runtime_ Container](/docs/setup/production-environment/container-runtimes/) +untuk informasi lebih lanjut. +{{% /tab %}} +{{< /tabs >}} + + +## Menginstal kubeadm, kubelet, dan kubectl + +Kamu akan menginstal _package_ berikut pada semua mesinmu: + +* `kubeadm`: alat untuk mem-_bootstrap_ klaster. + +* `kubelet`: komponen yang berjalan pada seluruh mesin pada klaster + dan memiliki tugas seperti menjalankan Pod dan Container. + +* `kubectl`: alat untuk berinteraksi dengan klastermu. + +Alat kubeadm **tidak akan** menginstal atau mengelola `kubelet` ataupun `kubectl` untukmu, jadi kamu harus memastikan +keduanya memiliki versi yang cocok dengan _control plane_ Kubernetes yang akan kamu instal +dengan kubeadm. Jika tidak, ada risiko _version skew_ yang dapat terjadi dan +dapat berujung pada perangai yang bermasalah dan tidak terduga. Namun, _satu_ _version skew_ minor antara +kubelet dan _control plane_ masih diperbolehkan, tetapi versi kubelet tidak boleh melebihi versi API +Server. Sebagai contoh, kubelet yang berjalan pada versi 1.7.0 akan kompatibel dengan API Server versi 1.8.0, tetapi tidak sebaliknya. + +Untuk informasi mengenai instalasi `kubectl`, lihat [Menginstal dan mengatur kubectl](/id/docs/tasks/tools/install-kubectl/). + +{{< warning >}} +Instruksi ini membuat seluruh _package_ Kubernetes keluar dari _system upgrade_. +Hal ini karena kubeadm dan Kubernetes membutuhkan +[perhatian khusus untuk pembaharuan](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). +{{}} + +Untuk informasi lebih lanjut mengenai _version skew_, lihat: + +* [Kebijakan _version-skew_ dan versi Kubernetes](/docs/setup/release/version-skew-policy/) +* [Kebijakan _version skew_](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) yang spesifik untuk kubeadm + +{{< tabs name="k8s_install" >}} +{{% tab name="Ubuntu, Debian atau HypriotOS" %}} +```bash +sudo apt-get update && sudo apt-get install -y apt-transport-https curl +curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - +cat < /etc/yum.repos.d/kubernetes.repo +[kubernetes] +name=Kubernetes +baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch +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=kubelet kubeadm kubectl +EOF + +# Mengatur SELinux menjadi permissive mode (menonaktifkannya secara efektif) +setenforce 0 +sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config + +yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes + +systemctl enable --now kubelet +``` + + **Catatan:** + + - Mengatur SELinux menjadi _permissive mode_ dengan menjalankan `setenforce 0` dan `sed ...` menonaktifkannya secara efektif. + Hal ini diperlukan untuk mengizinkan Container untuk mengakses _filesystem_ hos, yang dibutuhkan untuk jaringan Pod sebagai contoh. + Kamu harus melakukan ini sampai dukungan SELinux ditingkatkan pada kubelet. + + - Kamu dapat membiarkan SELinux aktif jika kamu mengetahui cara mengonfigurasinya, tetapi hal tersebut mungkin membutuhkan pengaturan yang tidak didukung oleh kubeadm. + +{{% /tab %}} +{{% tab name="Container Linux" %}} +Menginstal _plugin_ CNI (dibutuhkan untuk kebanyakan jaringan Pod): + +```bash +CNI_VERSION="v0.8.2" +mkdir -p /opt/cni/bin +curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz +``` + +Menginstal crictl (dibutuhkan untuk kubeadm / Kubelet Container Runtime Interface (CRI)) + +```bash +CRICTL_VERSION="v1.17.0" +mkdir -p /opt/bin +curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz +``` + +Menginstal `kubeadm`, `kubelet`, `kubectl` dan menambahkan _systemd service_ `kubelet`: + +```bash +RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)" + +mkdir -p /opt/bin +cd /opt/bin +curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl} +chmod +x {kubeadm,kubelet,kubectl} + +RELEASE_VERSION="v0.2.7" +curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service +mkdir -p /etc/systemd/system/kubelet.service.d +curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf +``` + +Mengaktifkan dan menjalankan `kubelet`: + +```bash +systemctl enable --now kubelet +``` +{{% /tab %}} +{{< /tabs >}} + + +Sekarang kubelet akan melakukan _restart_ setiap beberapa detik, sambil menunggu dalam kondisi _crashloop_ sampai kubeadm memberikan instruksi yang harus dilakukan. + +## Mengonfigurasi _driver_ cgroup yang digunakan oleh kubelet pada Node _control-plane_ + +Ketika menggunakan Docker, kubeadm akan mendeteksi secara otomatis _driver_ cgroup untuk kubelet +dan mengaturnya pada berkas `/var/lib/kubelet/config.yaml` pada saat _runtime_. + +Jika kamu menggunakan CRI yang berbeda, kamu harus memodifikasi berkasnya dengan nilai `cgroupDriver` yang kamu gunakan, seperti berikut: + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +cgroupDriver: +``` + +Harap diperhatikan, kamu **hanya** perlu melakukannya jika _driver_ cgroup dari CRI pilihanmu +bukanlah `cgroupfs`, karena nilai tersebut merupakan nilai bawaan yang digunakan oleh kubelet. + +{{< note >}} +Karena opsi `--cgroup-driver` sudah dihilangkan pada kubelet, jika kamu memilikinya pada `/var/lib/kubelet/kubeadm-flags.env` +atau `/etc/default/kubelet`(`/etc/sysconfig/kubelet` untuk RPM), silakan hapus dan gunakan KubeletConfiguration +(secara bawaan disimpan di `/var/lib/kubelet/config.yaml`). +{{< /note >}} + +Kamu harus melakukan _restart_ pada kubelet: + +```bash +systemctl daemon-reload +systemctl restart kubelet +``` + +Deteksi _driver_ cgroup secara otomatis untuk _runtime_ Container lainnya +seperti CRI-O dan containerd masih dalam proses pengembangan. + + +## Penyelesaian masalah + +Jika kamu menemui kesulitan dengan kubeadm, silakan merujuk pada [dokumen penyelesaian masalah](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/). + +## {{% heading "whatsnext" %}} + + +* [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) diff --git a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md new file mode 100644 index 0000000000..0d306a559a --- /dev/null +++ b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -0,0 +1,196 @@ +--- +title: Membuat Load Balancer Eksternal +content_template: templates/task +weight: 80 +--- + + +{{% capture overview %}} + +Laman ini menjelaskan bagaimana membuat _Load Balancer_ Eksternal. + +{{< note >}} +Fitur ini hanya tersedia untuk penyedia cloud atau lingkungan yang mendukung _load balancer_ eksternal. +{{< /note >}} + +Ketika membuat Service, kamu mempunyai opsi untuk tersambung dengan jaringan cloud _load balancer_ secara otomatis. +Hal ini menyediakan akses eksternal alamat IP yang dapat mengirim lalu lintas melalui porta yang tepat pada klaster Node kamu +_asalkan klaster kamu beroperasi pada lingkungan yang mendukung dan terkonfigurasi dengan paket penyedia cloud load balancer yang benar_. + +Untuk informasi mengenai penyediaan dan penggunaan sumber daya Ingress yang dapat memberikan +servis URL yang dapat dijangkau secara eksternal, penyeimbang beban lalu lintas, terminasi SSL, dll., +silahkan cek dokumentasi [Ingress](/docs/concepts/services-networking/ingress/) + +{{% /capture %}} + +{{% capture prerequisites %}} + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + +## Berkas konfigurasi + +Untuk membuat _load balancer_ eksternal, tambahkan baris di bawah ini ke +[berkas konfigurasi Service](/docs/concepts/services-networking/service/#loadbalancer) kamu: + +```yaml + type: LoadBalancer +``` + +Berkas konfigurasi kamu mungkin terlihat seperti ini: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: example-service +spec: + selector: + app: example + ports: + - port: 8765 + targetPort: 9376 + type: LoadBalancer +``` + +## Menggunakan kubectl + +Kamu dapat membuat Service dengan perintah `kubectl expose` dan +_flag_ `--type=LoadBalancer`: + +```bash +kubectl expose rc example --port=8765 --target-port=9376 \ + --name=example-service --type=LoadBalancer +``` + +Perintah ini membuat Service baru dengan menggunakan pemilih yang sama dengan +sumber daya yang dirujuk (dalam hal contoh di atas, ReplicationController bernama `example`). + +Untuk informasi lebih lanjut, termasuk opsi _flag_, mengacu kepada +[referensi `kubectl expose`](/docs/reference/generated/kubectl/kubectl-commands/#expose). + +## Menemukan alamat IP kamu + +Kamu dapat menemukan alamat IP yang telah dibuat untuk Service kamu dengan mendapatkan +informasi Service melalui `kubectl`: + +```bash +kubectl describe services example-service +``` + +yang seharusnya menghasilkan keluaran seperti ini: + +```bash + Name: example-service + Namespace: default + Labels: + Annotations: + Selector: app=example + Type: LoadBalancer + IP: 10.67.252.103 + LoadBalancer Ingress: 192.0.2.89 + Port: 80/TCP + NodePort: 32445/TCP + Endpoints: 10.64.0.4:80,10.64.1.5:80,10.64.2.4:80 + Session Affinity: None + Events: +``` + +Alamat IP tercantum di sebelah `LoadBalancer Ingress`. + +{{< note >}} +Jika kamu menjalankan Service dari Minikube, kamu dapat menemukan alamat IP dan porta yang ditetapkan dengan: +{{< /note >}} + +```bash +minikube service example-service --url +``` + +## Preservasi IP sumber klien + +Implementasi dari fitur ini menyebabkan sumber IP yang terlihat pada Container +target *bukan sebagai sumber IP asli* dari klien. Untuk mengaktifkan +preservasi IP klien, bidang berikut dapat dikonfigurasikan di dalam +spek Service (mendukung lingkungan GCE/Google Kubernetes Engine): + +* `service.spec.externalTrafficPolicy` - menunjukkan jika Service menginginkan rute lalu lintas +eksternal ke titik akhir _node-local_ atau _cluster-wide_. Terdapat dua opsi yang tersedia: +`Cluster` (bawaan) dan `Local`. `Cluster` mengaburkan sumber IP klien dan mungkin menyebabkan +hop kedua ke Node berbeda, namun harus mempunyai penyebaran beban (_load-spreading_) yang baik secara keseluruhan. +`Local` mempreservasi sumber IP client dan menghindari hop kedua `LoadBalancer` dan Service dengan tipe `NodePort`, namun +resiko berpotensi penyebaran lalu lintas yang tidak merata. +* `service.spec.healthCheckNodePort` - menentukan pemeriksaan kesehatan porta dari sebuah Node (angka porta numerik) untuk Service. +Jika `healthCheckNodePort` tidak ditentukan, pengendali Service mengalokasi +porta dari rentang `NodePort` dari klaster kamu. Kamu dapat mengonfigurasi +rentangan tersebut dari pengaturan opsi barisan perintah API server, +`--service-node-port-range`. Hal itu menggunakan nilai `healthCheckNodePort` pengguna spesifik +jika ditentukan oleh klien. Hal itu dapat berefek hanya ketika `type` diset ke `LoadBalancer` dan +`externalTrafficPolicy` diset ke `Local`. + +Pengaturan `externalTrafficPolicy` ke `Local` pada berkas konfigurasi Service mengaktifkan +fitur ini. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: example-service +spec: + selector: + app: example + ports: + - port: 8765 + targetPort: 9376 + externalTrafficPolicy: Local + type: LoadBalancer +``` + +## Pengumpul Sampah (Garbage Collector) Load Balancer + +{{< feature-state for_k8s_version="v1.17" state="stable" >}} + +Pada kasus biasa, sumber daya _load balancer_ yang berkorelasi pada penyedia cloud perlu +dibersihkan segera setelah Service bertipe _LoadBalancer_ dihapus. Namun perlu diketahui +bahwa terdapat kasus tepi dimana sumber daya cloud yatim piatu (_orphaned_) setelah +Service yang berkaitan dihapus. _Finalizer Protection_ untuk Service _LoadBalancer_ +diperkenalkan untuk mencegah hal ini terjadi. Dengan menggunakan _finalizers_, sebuah sumber daya Service +tidak akan pernah dihapus hingga sumber daya _load balancer_ yang berkorelasi juga dihapus. + +Secara khusus, jika Service mempunyai `type LoadBalancer`, pengendali Service akan melekatkan +_finalizer_ bernama `service.kubernetes.io/load-balancer-cleanup`. +_Finalizer_ hanya akan dihapus setelah sumber daya _load balancer_ dibersihkan. +Hal ini mencegah sumber daya _load balancer_ yang teruntai bahkan setelah kasus tepi seperti +pengendali Service berhenti. + +## Penyedia Load Balancer Eksternal + +Penting untuk dicatat bahwa jalur data untuk fungsionalitas ini disediakan oleh _load balancer_ eksternal ke klaster Kubernetes. + +Ketika Service `type` diset `LoadBalancer`, Kubernetes menyediakan fungsionalitas yang ekuivalen dengan `type` sebanding `ClusterIP` +ke berbagai Pod di dalam klaster dan mengekstensinya dengan pemrograman (eksternal dari Kubernetes) _load balancer_ dengan entri pada Pod +Kubernetes. Pengendali Service Kubernetes mengotomasi pembuatan _load balancer_ eksternal, cek kesehatan (jika dibutuhkan), +dinding api (_firewall_) (jika dibutuhkan), dan mengambil IP eksternal yang dialokasikan oleh penyedia cloud dan mengisinya pada objek Service. + +## Peringatan dan and Limitasi ketika preservasi sumber IP + +_Load balancers_ GCE/AWS tidak menyediakan bobot pada kolam targetnya (target pools). Hal ini bukan merupakan isu dengan aturan kube-proxy +_Load balancer_ lama yang akan menyeimbangkan semua titik akhir dengan benar. + +Dengan fungsionalitas yang baru, lalu lintas eksternal tidak menyeimbangkan beban secara merata pada seluruh Pod, namun +sebaliknya menyeimbangkan secara merata pada level Node (karena GCE/AWS dan implementasi _load balancer_ eksternal lainnya tidak mempunyai +kemampuan untuk menentukan bobot setiap Node, mereka menyeimbangkan secara merata pada semua Node target, mengabaikan jumlah +Pod pada tiap Node). + + +Namun demikian, kita dapat menyatakan bahwa NumServicePods << NumNodes atau NumServicePods >> NumNodes, distribusi yang cukup mendekati +sama akan terlihat, meski tanpa bobot. + +Sekali _load balancer_ eksternal menyediakan bobot, fungsionalitas ini dapat ditambahkan pada jalur pemrograman _load balancer_. +*Pekerjaan Masa Depan: Tidak adanya dukungan untuk bobot yang disediakan untuk rilis 1.4, namun dapat ditambahkan di masa mendatang* + +Pod internal ke lalu lintas Pod harus berperilaku sama seperti Service ClusterIP, dengan probabilitas yang sama pada seluruh Pod. + +{{% /capture %}} diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md new file mode 100644 index 0000000000..73c0946b8f --- /dev/null +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -0,0 +1,333 @@ +--- +title: Mengatur ServiceAccount untuk Pod +content_type: task +weight: 90 +--- + + +ServiceAccount menyediakan identitas untuk proses yang sedang berjalan dalam sebuah Pod. + +{{< note >}} +Dokumen ini digunakan sebagai pengenalan untuk pengguna terhadap ServiceAccount dan menjelaskan bagaimana perilaku ServiceAccount dalam konfigurasi klaster seperti yang direkomendasikan Kubernetes. Pengubahan perilaku yang bisa saja dilakukan administrator klaster terhadap klaster tidak menjadi bagian pembahasan dokumentasi ini. +{{< /note >}} + +Ketika kamu mengakses klaster (contohnya menggunakan `kubectl`), kamu terautentikasi oleh apiserver sebagai sebuah akun pengguna (untuk sekarang umumnya sebagai `admin`, kecuali jika administrator klustermu telah melakukan pengubahan). Berbagai proses yang ada di dalam kontainer dalam Pod juga dapat mengontak apiserver. Ketika itu terjadi, mereka akan diautentikasi sebagai sebuah ServiceAccount (contohnya sebagai `default`). + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## Menggunakan Default ServiceAccount untuk Mengakses API server. + +Ketika kamu membuat sebuah Pod, jika kamu tidak menentukan sebuah ServiceAccount, maka ia akan otomatis ditetapkan sebagai ServiceAccount`default` di Namespace yang sama. Jika kamu mendapatkan json atau yaml mentah untuk sebuah Pod yang telah kamu buat (contohnya menggunakan `kubectl get pods/ -o yaml`), kamu akan melihat _field_ `spec.serviceAccountName` yang telah secara [otomatis ditentukan](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). + +Kamu dapat mengakses API dari dalam Pod menggunakan kredensial ServiceAccount yang ditambahkan secara otomatis seperti yang dijelaskan dalam [Mengakses Klaster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). +Hak akses API dari ServiceAccount menyesuaikan dengan [kebijakan dan plugin otorisasi](/docs/reference/access-authn-authz/authorization/#authorization-modules) yang sedang digunakan. + +Di versi 1.6+, kamu dapat tidak memilih _automounting_ kredensial API dari sebuah ServiceAccount dengan mengatur `automountServiceAccountToken: false` pada ServiceAccount: + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + name: build-robot +automountServiceAccountToken: false +... +``` + +Di versi 1.6+, kamu juga dapat tidak memilih _automounting_ kredensial API dari suatu Pod tertentu: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + serviceAccountName: build-robot + automountServiceAccountToken: false + ... +``` + +Pengaturan dari spesifikasi Pod didahulukan dibanding ServiceAccount jika keduanya menentukan nilai dari `automountServiceAccountToken`. + +## Menggunakan Beberapa ServiceAccount. + +Setiap Namespace memiliki sumber daya ServiceAccount standar `default`. +Kamu dapat melihatnya dan sumber daya serviceAccount lainnya di Namespace tersebut dengan perintah: + +```shell +kubectl get serviceaccounts +``` +Keluarannya akan serupa dengan: + +``` +NAME SECRETS AGE +default 1 1d +``` + +Kamu dapat membuat objek ServiceAccount tambahan seperti ini: + +```shell +kubectl apply -f - < +Annotations: kubernetes.io/service-account.name=build-robot + kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da + +Type: kubernetes.io/service-account-token + +Data +==== +ca.crt: 1338 bytes +namespace: 7 bytes +token: ... +``` + +{{< note >}} +Isi dari `token` tidak dirinci di sini. +{{< /note >}} + +## Menambahkan ImagePullSecret ke ServiceAccount. + +### Membuat imagePullSecret + +- Membuat sebuah imagePullSecret, seperti yang dijelaskan pada [Menentukan ImagePullSecret pada Pod](/id/docs/concepts/containers/images/#tentukan-imagepullsecrets-pada-sebuah-pod). + + ```shell + kubectl create secret docker-registry myregistrykey --docker-server=DUMMY_SERVER \ + --docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \ + --docker-email=DUMMY_DOCKER_EMAIL + ``` + +- Memastikan bahwa Secret telah terbuat. + ```shell + kubectl get secrets myregistrykey + ``` + + Keluarannya akan serupa dengan: + + ``` + NAME TYPE DATA AGE + myregistrykey   kubernetes.io/.dockerconfigjson   1       1d + ``` + +### Menambahkan imagePullSecret ke ServiceAccount + +Selanjutnya, modifikasi ServiceAccount standar dari Namespace untuk menggunakan Secret ini sebagai imagePullSecret. + + +```shell +kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' +``` + +Sebagai gantinya kamu dapat menggunakan `kubectl edit`, atau melakukan pengubahan secara manual manifes YAML seperti di bawah ini: + +```shell +kubectl get serviceaccounts default -o yaml > ./sa.yaml +``` + +Keluaran dari berkas `sa.yaml` akan serupa dengan: + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + resourceVersion: "243024" + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +``` + +Menggunakan _editor_ pilihanmu (misalnya `vi`), buka berkas `sa.yaml`, hapus baris dengan key `resourceVersion`, tambahkan baris dengan `imagePullSecrets:` dan simpan. + +Keluaran dari berkas `sa.yaml` akan serupa dengan: + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +imagePullSecrets: +- name: myregistrykey +``` + +Terakhir ganti serviceaccount dengan berkas `sa.yaml` yang telah diperbarui. + +```shell +kubectl replace serviceaccount default -f ./sa.yaml +``` + +### Memverifikasi imagePullSecrets sudah ditambahkan ke spesifikasi Pod + +Ketika Pod baru dibuat dalam Namespace yang sedang aktif dan menggunakan ServiceAccount, Pod baru akan memiliki _field_ `spec.imagePullSecrets` yang ditentukan secara otomatis: + +```shell +kubectl run nginx --image=nginx --restart=Never +kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}' +``` + +Keluarannya adalah: + +``` +myregistrykey +``` + + + +## ServiceAccountTokenVolumeProjection + +{{< feature-state for_k8s_version="v1.12" state="beta" >}} + +{{< note >}} +ServiceAccountTokenVolumeProjection masih dalam tahap __beta__ untuk versi 1.12 dan diaktifkan dengan memberikan _flag_ berikut ini ke API server: + +* `--service-account-issuer` +* `--service-account-signing-key-file` +* `--service-account-api-audiences` + +{{< /note >}} + +Kubelet juga dapat memproyeksikan _token_ ServiceAccount ke Pod. Kamu dapat menentukan properti yang diinginkan dari _token_ seperti target pengguna dan durasi validitas. Properti tersebut tidak dapat diubah pada _token_ ServiceAccount standar. _Token_ ServiceAccount juga akan menjadi tidak valid terhadap API ketika Pod atau ServiceAccount dihapus. + +Perilaku ini diatur pada PodSpec menggunakan tipe ProjectedVolume yaitu [ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Untuk memungkinkan Pod dengan _token_ dengan pengguna bertipe _"vault"_ dan durasi validitas selama dua jam, kamu harus mengubah bagian ini pada PodSpec: + +{{< codenew file="pods/pod-projected-svc-token.yaml" >}} + +Buat Pod: + +```shell +kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml +``` + +_Token_ yang mewakili Pod akan diminta dan disimpan kubelet, lalu kubelet akan membuat _token_ yang dapat diakses oleh Pod pada _file path_ yang ditentukan, dan melakukan _refresh_ _token_ ketika telah mendekati waktu berakhir. _Token_ akan diganti oleh kubelet jika _token_ telah melewati 80% dari total TTL, atau jika _token_ telah melebihi waktu 24 jam. + +Aplikasi bertanggung jawab untuk memuat ulang _token_ ketika terjadi penggantian. Pemuatan ulang teratur (misalnya sekali setiap 5 menit) cukup untuk mencakup kebanyakan kasus. + +## ServiceAccountIssuerDiscovery + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +Fitur ServiceAccountIssuerDiscovery diaktifkan dengan mengaktifkan [gerbang fitur](/docs/reference/command-line-tools-reference/feature-gate) `ServiceAccountIssuerDiscovery` dan mengaktifkan fitur _Service Account Token Volume Projection_ seperti yang telah dijelaskan [di atas](#service-account-token-volume-projection). + +{{< note >}} +URL _issuer_ harus sesuai dengan _[OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html)_. Pada implementasinya, hal ini berarti URL harus menggunakan skema `https` dan harus menyediakan konfigurasi penyedia OpenID pada `{service-account-issuer}/.well-known/openid-configuration`. + +Jika URL tidak sesuai dengan aturan, _endpoint_ `ServiceAccountIssuerDiscovery` tidak akan didaftarkan meskipun fitur telah diaktifkan. +{{< /note >}} + +Fitur _Service Account Issuer Discovery_ memungkinkan federasi dari berbagai _token_ ServiceAccount Kubernetes yang dibuat oleh sebuah klaster (penyedia identitas) dan sistem eksternal. + +Ketika diaktifkan, server API Kubernetes menyediakan dokumen OpenID Provider Configuration pada `/.well-known/openid-configuration` dan JSON Web Key Set (JWKS) terkait pada `/openid/v1/jwks`. OpenID Provider Configuration terkadang disebut juga dengan sebutan _discovery document_. + +Ketika diaktifkan, klaster juga dikonfigurasi dengan RBAC ClusterRole standar yaitu `system:service-account-issuer-discovery`. _Role binding_ tidak disediakan secara _default_. Administrator dimungkinkan untuk, sebagai contoh, menentukan apakah peran akan disematkan ke `system:authenticated` atau `system:unauthenticated` tergantung terhadap kebutuhan keamanan dan sistem eksternal yang direncakanan untuk diintegrasikan. + +{{< note >}} +Respons yang disediakan pada `/.well-known/openid-configuration` dan`/openid/v1/jwks` dirancang untuk kompatibel dengan OIDC, tetapi tidak sepenuhnya sesuai dengan ketentuan OIDC. Dokumen tersebut hanya berisi parameter yang dibutuhkan untuk melakukan validasi terhadap _token_ ServiceAccount Kubernetes. +{{< /note >}} + +Respons JWKS memuat kunci publik yang dapat digunakan oleh sistem eksternal untuk melakukan validasi _token_ ServiceAccount Kubernetes. Awalnya sistem eksternal akan mengkueri OpenID Provider Configuration, dan selanjutnya dapat menggunakan _field_ `jwks_uri` pada respons kueri untuk mendapatkan JWKS. + +Pada banyak kasus, server API Kubernetes tidak tersedia di internet publik, namun _endpoint_ publik yang menyediakan respons hasil _cache_ dari server API dapat dibuat menjadi tersedia oleh pengguna atau penyedia servis. Pada kasus ini, dimungkinkan untuk mengganti `jwks_uri` pada OpenID Provider Configuration untuk diarahkan ke _endpoint_ publik sebagai ganti alamat server API dengan memberikan _flag_ `--service-account-jwks-uri` ke API server. serupa dengan URL _issuer_, URI JWKS diharuskan untuk menggunakan skema `https`. + + +## {{% heading "whatsnext" %}} + + +Lihat juga: + +- [Panduan Admin Kluster mengenai ServiceAccount](/docs/reference/access-authn-authz/service-accounts-admin/) +- [ServiceAccount Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md) +- [OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html) + + diff --git a/content/id/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/id/docs/tasks/configure-pod-container/pull-image-private-registry.md new file mode 100644 index 0000000000..2158afcf35 --- /dev/null +++ b/content/id/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -0,0 +1,212 @@ +--- +title: Menarik Image dari Register Pribadi +content_type: task +weight: 100 +--- + + + +Laman ini menunjukkan cara membuat Pod dengan menggunakan Secret untuk menarik _image_ dari sebuah +register atau repositori pribadi untuk Docker. + + +## {{% heading "prerequisites" %}} + + +* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +* Untuk melakukan latihan ini, kamu memerlukan sebuah +[nama pengguna (ID) Docker](https://docs.docker.com/docker-id/) dan kata sandi (_password_). + + + + +## Masuk (_login_) ke Docker {#masuk-ke-docker} + +Pada laptop kamu, kamu harus melakukan autentikasi dengan register untuk menarik _image_ pribadi: + +```shell +docker login +``` + +Ketika diminta, masukkan nama pengguna dan kata sandi Docker kamu. + +Proses _login_ membuat atau memperbarui berkas `config.json` yang menyimpan sebuah _token_ otorisasi. + +Lihatlah berkas `config.json`: + + +```shell +cat ~/.docker/config.json +``` + +Keluaran berisi bagian yang serupa dengan ini: + +```json +{ + "auths": { + "https://index.docker.io/v1/": { + "auth": "c3R...zE2" + } + } +} +``` + +{{< note >}} +Jika kamu menggunakan tempat penyimpanan kredensial (_credential_) untuk Docker, maka kamu tidak akan melihat entri `auth` tetapi entri `credsStore` dengan nama tempat penyimpanan sebagai nilainya. +{{< /note >}} + +## Membuat Secret berdasarkan kredensial Docker yang sudah ada {#register-secret-kredensial-yang-ada} + +Klaster Kubernetes menggunakan Secret dari tipe `docker-registry` untuk melakukan autentikasi dengan +register Container untuk menarik _image_ pribadi. + +Jika kamu sudah menjalankan `docker login`, kamu dapat menyalin kredensial itu ke Kubernetes: + +```shell +kubectl create secret generic regcred \ + --from-file=.dockerconfigjson= \ + --type=kubernetes.io/dockerconfigjson +``` + +Jika kamu memerlukan lebih banyak kontrol (misalnya, untuk mengatur Namespace atau label baru pada Secret) +maka kamu dapat menyesuaikan Secret tersebut sebelum menyimpannya. +Pastikan untuk: + + +- Mengatur nama dari pokok (_item_) data menjadi `.dockerconfigjson` +- Melakukan enkode secara _base64_ dari Dockerfile (berkas Docker) dan memindahkan urutan huruf (_string_) tersebut, secara tidak terputus sebagai nilai untuk bidang `data[".dockerconfigjson"]` +- Mengatur `type` menjadi `kubernetes.io/dockerconfigjson` + +Sebagai contoh: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: myregistrykey + namespace: awesomeapps +data: + .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== +type: kubernetes.io/dockerconfigjson +``` + +Jika kamu mendapat pesan kesalahan `error: no objects passed to create`, ini berarti pengkodean _base64_ dari urutan huruf tersebut tidak valid. +Jika kamu mendapat pesan kesalahan seperti `Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`, ini berarti +enkode _base64_ dari urutan huruf dalam data tersebut sukses didekodekan, tetapi tidak bisa diuraikan menjadi berkas `.docker/config.json`. + +## Membuat Secret dengan memberikan kredensial pada baris perintah + +Buatlah Secret ini, dan berilah nama `regcred`: + +```shell +kubectl create secret docker-registry regcred --docker-server= --docker-username= --docker-password= --docker-email= +``` + +dimana: + +* `` merupakan FQDN dari register privat Docker kamu. (https://index.docker.io/v1/ untuk DockerHub) +* `` adalah nama pengguna Docker kamu. +* `` adalah kata sandi Docker kamu. +* `` adalah alamat email Docker kamu. + +Kamu telah berhasil mengatur kredensial untuk Docker kamu pada klaster sebagai sebuah Secret yang dipanggil dengan nama `regcred`. + +{{< note >}} + +Mengetik Secret pada baris perintah dapat menyimpannya dalam riwayat (_history_) dari _shell_ kamu tanpa perlindungan, dan +Secret tersebut mungkin juga terlihat oleh pengguna lain dalam PC kamu selama perintah `kubectl` sedang berjalan. +{{< /note >}} + + +## Menginspeksi Secret `regcred` {#menginspeksi-secret-regcred} + +Untuk memahami isi Secret `regcred` yang baru saja kamu buat, mulailah dengan melihat Secret dalam format YAML: + +```shell +kubectl get secret regcred --output=yaml +``` +Keluarannya akan seperti ini: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + ... + name: regcred + ... +data: + .dockerconfigjson: eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0= +type: kubernetes.io/dockerconfigjson +``` + +Nilai dari bidang `.dockerconfigjson` merupakan representasi dalam _base64_ dari kredensial Docker kamu. + +Untuk memahami apa yang ada dalam bidang `.dockerconfigjson`, ubahlah data Secret menjadi format yang bisa terbaca: + +```shell +kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode +``` + +Keluarannya akan seperti ini: + +```json +{"auths":{"your.private.registry.example.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}} +``` + +Untuk memahami apa yang ada dalam bidang `auth`, ubahlah data Secret menjadi format yang bisa terbaca: + +```shell +echo "c3R...zE2" | base64 --decode +``` + +Keluarannya, nama pengguna dan kata sandi yang digabungkan dengan tanda `:`, seperti dibawah ini: + +```none +janedoe:xxxxxxxxxxx +``` + +Perhatikan bahwa data Secret berisi token otorisasi yang serupa dengan berkas `~/.docker/config.json` lokal kamu. + +Kamu telah berhasil menetapkan kredensial Docker kamu sebagai sebuah Secret yang dipanggil dengan `regcred` pada klaster. + + +## Membuat Pod yang menggunakan Secret kamu + + +Berikut ini adalah berkas konfigurasi untuk Pod yang memerlukan akses ke kredensial Docker kamu pada `regcred`: + +{{< codenew file="pods/private-reg-pod.yaml" >}} + +Unduh berkas diatas: + +```shell +wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml +``` + +Dalam berkas `my-private-reg-pod.yaml`, ubah `` dengan tautan ke _image_ dalam register pribadi seperti ini: + +```none +your.private.registry.example.com/janedoe/jdoe-private:v1 +``` + +Untuk menarik _image_ dari register pribadi, Kubernetes memerlukan kredensial. +Bidang `imagePullSecrets` dalam berkas konfigurasi menentukan bahwa Kubernetes harus mendapatkan kredensial dari Secret yang bernama `regcred`. + +Buatlah Pod yang menggunakan Secret kamu, dan verifikasi bahwa Pod tersebut berjalan: + +```shell +kubectl apply -f my-private-reg-pod.yaml +kubectl get pod private-reg +``` + + +## {{% heading "whatsnext" %}} + + +* Pelajari lebih lanjut tentang [Secret](/id/docs/concepts/configuration/secret/). +* Pelajari lebih lanjut tentang [menggunakan register pribadi](/id/docs/concepts/containers/images/#menggunakan-register-privat). +* Pelajari lebih lanjut tentang [menambahkan Secret untuk menarik _image_ ke dalam sebuah akun service](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account). +* Lihatlah [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-). +* Lihatlah [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core). +* Lihatlah bidang `imagePullSecrets` dari [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core). diff --git a/content/id/docs/tasks/run-application/horizontal-pod-autoscaler.md b/content/id/docs/tasks/run-application/horizontal-pod-autoscaler.md new file mode 100644 index 0000000000..badc7a058d --- /dev/null +++ b/content/id/docs/tasks/run-application/horizontal-pod-autoscaler.md @@ -0,0 +1,452 @@ +--- +title: HorizontalPodAutoscaler +feature: + title: Horizontal scaling + description: > + Scale up dan scale down aplikasimu dengan sebuah perintah yang serderhana, dengan UI, atau otomatis bersadarkan penggunaan CPU. +content_template: templates/concept +weight: 90 +--- + +{{% capture overview %}} + +HorizontalPodAutoscaler secara otomatis akan memperbanyak jumlah Pod di dalam ReplicationController, Deployment, +ReplicaSet ataupun StatefulSet berdasarkan hasil observasi penggunaan CPU(atau, dengan +[metrik khusus](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md), pada beberapa aplikasi yang menyediakan metrik). +Perlu dicatat bahwa HorizontalPodAutoscale tidak dapat diterapkan pada objek yang tidak dapat diperbanyak, seperti DeamonSets. + +HorizontalPodAutoscaler diimplementasikan sebagai Kubernetes API *resource* dan sebuah _controller_. +*Resource* tersebut akan menentukan perilaku dari _controller_-nya. +Kontroler akan mengubah jumlah replika pada ReplicationController atau pada Deployment untuk menyesuaikan dengan hasil observasi rata-rata +penggunaan CPU sesuai dengan yang ditentukan oleh pengguna. + +{{% /capture %}} + + +{{% capture body %}} + +## Bagaimana cara kerja HorizontalPodAutoscaler? + +![Diagram HorizontalPodAutoscaler](/images/docs/horizontal-pod-autoscaler.svg) + +HorizontalPodAutoscaler diimplementasikan sebagai sebuah _loop_ kontrol, yang secara +berkala dikontrol oleh *flag* `--horizontal-pod-autoscaler-sync-period` pada _controller manager_ +(dengan nilai bawaan 15 detik). + +Dalam setiap periode, _controller manager_ melakukan kueri penggunaan sumber daya dan membandingkan +dengan metrik yang dispesifikasikan pada HorizontalPodAutoscaler. _Controller manager_ mendapat +metrik dari sumber daya metrik API (untuk metrik per Pod) atau dari API metrik khusus (untuk semua metrik lainnya). + +* Untuk metrik per Pod (seperti CPU), _controller_ mengambil metrik dari sumber daya metrik API + untuk setiap Pod yang ditargetkan oleh HorizontalPodAutoscaler. Kemudian, jika nilai target penggunaan ditentukan, + maka _controller_ akan menghitung nilai penggunaan sebagai persentasi dari pengguaan sumber daya dari Container + pada masing-masing Pod. Jika target nilai mentah (*raw value*) ditentukan, maka nilai metrik mentah (*raw metric*) + akan digunakan secara langsung. _Controller_ kemudian mengambil nilai rata-rata penggunaan atau nilai mentah (tergantung + dengan tipe target yang ditentukan) dari semua Pod yang ditargetkan dan menghasilkan perbandingan yang + digunakan untuk menentukan jumlah replika yang akan diperbanyak. + + Perlu dicatat bahwa jika beberapa Container pada Pod tidak memiliki nilai *resource request*, penggunaan CPU + pada Pod tersebut tidak akan ditentukan dan *autoscaler* tidak akan melakukan tindakan apapun untuk metrik tersebut. + Perhatikan pada bagian [detail algoritma](#detail-algoritma) di bawah ini untuk informasi lebih lanjut mengenai + cara kerja algoritma *autoscale*. + +* Untuk metrik khusus per Pod, _controller_ bekerja sama seperti sumber daya metrik per Pod, + kecuali Pod bekerja dengan nilai mentah, bukan dengan nilai utilisasi (*utilization values*). + +* Untuk objek metrik dan metrik eksternal, sebuah metrik diambil, dimana metrik tersebut menggambarkan + objek tersebut. Metrik ini dibandingkan dengan nilai target untuk menghasilkan perbandingan seperti di atas. + Pada API `autoscaling/v2beta2`, nilai perbandingan dapat secara opsional dibagi dengan jumlah Pod + sebelum perbandingan dibuat. + +Pada normalnya, HorizontalPodAutoscaler mengambil metrik dari serangkaian API yang sudah diagregat +(`custom.metric.k8s.io`, dan `external.metrics.k8s.io`). API `metrics.k8s.io` biasanya disediakan oleh +*metric-server*, dimana *metric-server* dijalankan secara terpisah. Perhatikan +[*metrics-server*](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server) sebagai petunjuk. +HorizontalPodAutoscaler juga mengambil metrik dari Heapster secara langsung. + +{{< note >}} +{{< feature-state state="deprecated" for_k8s_version="v1.11" >}} +Pengambian metrik dari Heapster tidak didukung lagi pada Kubernetes versi 1.11. +{{< /note >}} + +Perhatikan [Dukungan untuk API metrik](#dukungan-untuk-api-metrik) untuk lebih detail. + +*Autoscaler* mengkases _controller_ yang dapat diperbanyak (seperti ReplicationController, Deployment, dan ReplicaSet) +dengan menggunakan *scale sub-resource*. Untuk lebih detail mengenai *scale sub-resource* dapat ditemukan +[di sini](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource). + +### Detail Algoritma + +Dari sudut pandang paling sederhana, _controller_ HorizontalPodAutoscaler mengoperasikan +perbandingan metrik yang diinginkan dengan kedaan metrik sekarang. + +``` +desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )] +``` + +Sebagai contoh, jika nilai metrik sekarang adalah `200m` dan nilai metrik yang +diinginkan adalah `100m`, jumlah replika akan ditambah dua kali lipat, +karena `200.0 / 100.0 == 2.0`. Jika nilai metrik sekarang adalah `50m`, +maka jumlah replika akan dikurangi setengah, karena `50.0 / 100.0 == 0.5`. +Kita tetap memperbanyak replika (_scale_) jika nilai perbandingan mendekati 1.0 (dalam toleransi yang +dapat dikonfigurasi secata global, dari *flag* `--horizontal-pod-autoscaler-tolerance` +dengan nilai bawaan 0.1. + +Ketika `targetAverageValue` (nilai target rata-rata) atau `targetAverageUtilization` +(target penggunaan rata-rata) ditentukan, `currentMetricValue` (nilai metrik sekaraang) +dihitung dengan mengambil rata-rata dari metrik dari semua Pod yang ditargetkan oleh +HorizontalPodAutoscaler. Sebelum mengecek toleransi dan menentukan nilai akhir, +kita mengambil kesiapan Pod dan metrik yang hilang sebagai pertimbangan. + +Semua Pod yang memiliki waktu penghapusan (Pod dalam proses penutupan) +dan semua Pod yang mengalami kegagalan akan dibuang. + +Jika ada metrik yang hilang dari Pod, maka Pod akan dievaluasi nanti. +Pod dengan nilai metrik yang hilang akan digunakan untuk menyesuaikan +jumlah akhir Pod yang akan diperbanyak atau dikurangi. + +Ketika _scaling_ dilakukan karena CPU, jika terdapat Pod yang akan siap (dengan kata lain +Pod tersebut sedang dalam tahap inisialisasi) *atau* metrik terakhir dari Pod +adalah metrik sebelum Pod dalam keadaan siap, maka Pod tersebut juga +akan dievaluasi nantinya. + +Akibat keterbatasan teknis, _controller_ HorizontalPodAutoscaler tidak dapat +menentukan dengan tepat kapan pertama kali Pod akan dalam keadaan siap +ketika menentukan apakah metrik CPU tertentu perlu dibuang. Sebaliknya, +HorizontalPodAutoscaler mempertimbangkan sebuah Pod "tidak dalam keadaan siap" +jika Pod tersebut dalam keadaan tidak siap dan dalam transisi ke status tidak +siap dalam waktu singkat, rentang waktu dapat dikonfigurasi, sejak Pod tersebut dijalankan. +Rentang waktu tersebut dapat dikonfigurasi dengan *flag* `--horizontal-pod-autoscaler-initial-readiness-delay` +dan waktu bawaannya adalah 30 detik. Ketika suatu Pod sudah dalam keadaan siap, +Pod tersebut mempertimbangkan untuk siap menjadi yang pertama jika itu terjadi dalam +waktu yang lebih lama, rentang waktu dapat dikonfigurasi, sejak Pod tersebut dijalankan. +Rentang waktu tersebut dapat dikonfigurasi dengan *flag* `--horizontal-pod-autoscaler-cpu-initialization-period` +dan nilai bawaannya adalah 5 menit. + +Skala perbandingan dasar `currentMetricValue / desiredMetricValue` +dihitung menggunakan Pod yang tersisa yang belum disisihkan atau dibuang dari +kondisi di atas. + +Jika terdapat metrik yang hilang, kita menghitung ulang rata-rata dengan lebih +konservatif, dengan asumsi Pod mengkonsumsi 100% dari nilai yang diharapkan +jika jumlahnya dikurangi (*scale down*) dan 0% jika jumlahnya diperbanyak (*scale up*). +Ini akan mengurangi besarnya kemungkinan untuk *scale*. + +Selanjutnya, jika terdapat Pod dalam keadaan tidak siap, dan kita akan +memperbanyak replikas (*scale up*) tanpa memperhitungkan metrik yang hilang atau Pod yang tidak dalam +keadaan siap, kita secara konservatif mengasumsikan Pod yang tidak dalam keadaan siap +mengkonsumsi 0% dari metrik yang diharapkan, akhirnya meredam jumlah replika yang diperbanyak (*scale up*). + +Seteleh memperhitungkan Pod yang tidak dalam keadaan siap dan metrik yang hilang, +kita menghitung ulang menggunakan perbandingan. Jika perbandingan yang baru membalikkan +arah *scale*-nya atau masih di dalam toleransi, kita akan melakukan *scale* dengan tepat. Jika tidak, +kita menggunakan perbandingan yang baru untuk memperbanyak atau mengurangi jumlah replika. + +Perlu dicatat bahwa nilai asli untuk rata-rata penggunaan dilaporkan kembali melalui +status HorizontalPodAutoscaler, tanpa memperhitungkan Pod yang tidak dalam keadaan siap atau +metrik yang hilang, bahkan ketika perbandingan yang baru digunakan. + +Jika beberapa metrik ditentukan pada sebuah HorizontalPodAutoscaler, perhitungan +dilakukan untuk setiap metrik dan nilai replika terbesar yang diharapkan akan dipilih. +Jika terdapat metrik yang tidak dapat diubah menjadi jumlah replika yang diharapkan +(contohnya terdapat kesalahan ketika mengambil metrik dari API metrik) dan pengurangan replika +disarankan dari metrik yang dapat diambil, maka *scaling* akan diabaikan. Ini berarti +HorizontalPodAutoscaler masih mampu untuk memperbanyak replika jika satu atau lebih metrik +memberikan sebuah `desiredReplicas` lebih besar dari nilai yang sekarang. + +Pada akhirnya, sebelum HorizontalPodAutoscaler memperbanyak target, rekomendasi *scaling* akan +dicatat. _Controller_ mempertimbangkan semua rekomendasi dalam rentang waktu yang dapat +dikonfigurasi untuk memilih rekomendasi tertinggi. Nilai ini dapat dikonfigurasi menggunakan +*flag* `--horizontal-pod-autoscaler-downscale-stabilization`, dengan nilai bawaan +5 menit. Ini berarti pengurangan replika akan terjadi secara bertahap, untuk mengurangi dampak dari +perubahan nilai metrik yang cepat. + +## Objek API + +HorizontalPodAutoscaler adalah sebuah API dalam grup `autoscaling` pada Kubernetes. +Versi stabil, yang hanya mendukung untuk *autoscale* CPU, dapat ditemukan pada versi +API `autoscaling/v1`. + +Versi *beta*, yang mendukung untuk *scaling* berdasarkan memori dan metrik khusus, +dapat ditemukan pada `autoscaling/v2beta2`. *Field* yang baru diperkenalkan pada +`autoscaling/v2beta2` adalah *preserved* sebagai anotasi ketika menggunakan `autoscaling/v1`. + +Ketika kamu membuat sebuah HorizontalPodAutoscaler, pastikan nama yang ditentukan adalah valid +[nama subdomain DNS](/docs/concepts/overview/working-with-objects/names#nama). +Untuk lebih detail tentang objek API ini dapat ditemukan di +[Objek HorizontalPodAutoscaler](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object). + +## Dukungan untuk HorizontalPodAutoscaler pada kubectl + +Seperti sumber daya API lainnya, HorizontalPodAutoscaler didukung secara bawaan oleh `kubectl`. +Kita dapat membuat *autoscaler* yang baru dengan menggunakan perintah `kubectl create`. +Kita dapat melihat daftar *autoscaler* dengan perintah `kubectl get hpa` dan melihat deskripsi +detailnya dengan perintah `kubectl describe hpa`. Akhirnya, kita dapat menghapus *autoscaler* +meggunakan perintah `kubectl delete hpa`. + +Sebagai tambahan, terdapat sebuah perintah khusus `kubectl autoscaler` untuk mempermudah pembuatan +HorizontalPodAutoscaler. Sebagai contoh, mengeksekusi +`kubectl autoscaler rs foo --min=2 --max=5 --cpu-percent=80` akan membuat sebuah *autoscaler* untuk +ReplicaSet *foo*, dengan target pengguaan CPU `80%` dan jumlah replika antara 2 sampai dengan 5. +Dokumentasi lebih detail tentang `kubectl autoscaler` dapat ditemukan di +[sini](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). + +## Autoscaling ketika Rolling Update + +Saat ini, dimungkinkan untuk melakukan *rolling update* menggunakan objek Deployment, yang akan +mengatur ReplicaSet untuk kamu. HorizontalPodAutoscaler hanya mendukung pendekatan terakhir: +HorizontalPodAutoscaler terikat dengan objek Deployment, yang mengatur seberapa besar dari objek Deployment tersebut, +dan Deployment bertugas untuk mengatur besar dari ReplicaSet. + +HorizontalPodAutoscaler tidak bekerja dengan *rolling update* yang menggunakan manipulasi +pada ReplicationContoller secara langsung, dengan kata lain kamu tidak bisa mengikat +HorizontalPodAutoscaler dengan ReplicationController dan melakukan *rolling update*. +Alasan HorizontalPodAutoscaler tidak bekerja ketika *rolling update* membuat ReplicationController +yang baru adalah HorizontalPodAutoscaler tidak akan terikat dengan ReplicationController yang baru tersebut. + +## Dukungan untuk *Cooldown* / Penundaan + +Ketika mengolah *scaleing* dari sebuah grup replika menggunakan HorizonalPodAutoscaler, +jumlah replika dimungkinkan tetap berubah secara sering disebabkan oleh perubahan dinamis +dari metrik yang dievaluasi. Hal ini sering disebut dengan *thrashing*. + +Mulai dari versi 1.6, operator klaster dapat mengatasi masalah ini dengan mengatur +konfigurasi HorizontalPodAutoscaler global sebagai *flag* `kube-controller-manager`. + +Mulai dari versi 1.12, sebuah algoritma pembaruan baru menghilangkan kebutuhan terhadap +penundaan memperbanyak replika (*upscale*). + +- `--horizontal-pod-autoscaler-downscale-stabilization`: Nilai untuk opsi ini adalah + sebuah durasi yang menentukan berapa lama *autoscaler* menunggu sebelum operasi + pengurangan replika (*downscale*) yang lain dilakukan seteleh operasi sekarang selesai. Nilai bawaannya + adalah 5 menit (`5m0s`). + +{{< note >}} +Ketika mengubah nilai paramater ini, sebuah operator klaster sadar akan kemungkinan +konsekuensi. Jika waktu penundaan diset terlalu lama, kemungkinan akan membuat +HorizontalPodAutoscaler tidak responsif terharap perubahan beban kerja. Namun, jika +waktu penundaan diset terlalu cepat, kemungkinan replikasi akan *trashing* seperti +biasanya. +{{< /note >}} + +## Dukungan untuk Beberapa Metrik + +Kubernetes versi 1.6 menambah dukungan untuk *scaling* berdasarkan beberapa metrik. +Kamu dapat menggunakan API versi `autoscaling/v2beta2` untuk menentukan beberapa metrik +yang akan digunakan HorizontalPodAutoscaler untuk menambah atau mengurangi jumlah replika. +Kemudian, _controller_ HorizontalPodAutoscaler akan mengevaluasi setiap metrik dan menyarankan jenis +*scaling* yang baru berdasarkan metrik tersebut. Jumlah replika terbanyak akan digunakan untuk *scale* +yang baru. + +## Dukungan untuk Metrik Khusus + +{{< note >}} +Kubernetes versi 1.2 menambah dukungan *alpha* untuk melakukan *scaling* berdasarkan metrik +yang spesifik dengan aplikasi menggunakan anotasi khusus. Dukungan untuk anotasi ini +dihilangkan pada Kubernetes versi 1.6 untuk mendukung API *autoscaling* yang baru. Selama +cara lama untuk mendapatkan metrik khusus masih tersedia, metrik ini tidak akan tersedia untuk +digunakan oleh HorizontalPodAutoscaler dan anotasi sebelumnya untuk menentukan metrik khusus untuk +*scaling* tidak lagi digunakan oleh _controller_ HorizontalPodAutscaler. +{{< /note >}} + +Kubernetes versi 1.6 menambah dukungan untuk menggunakan metrik khusus pada HorizontalPodAutoscaler. +Kamu dapat menambahkan metrik khusus untuk HorizontalPodAutoscaler pada API versi `autoscaling/v2beta2`. +Kubernetes kemudian memanggil API metrik khusu untuk mengambil nilai dari metrik khusus. + +@girikuncoro +girikuncoro 4 days ago Contributor + +typo +Suggested change +Kubernetes kemudian memanggil API metrik khusu untuk mengambil nilai dari metrik khusus. +Kubernetes kemudian memanggil API metrik khusus untuk mengambil nilai dari metrik khusus. +@ecojuntak + +Lihat [Dukungan untuk API metrik](#dukungan-untuk-api-metrik) untuk kubutuhannya. + +## Dukungan untuk API metrik + +Secara standar, _controller_ HorizontalPodAutoscaler mengambil metrik dari beberapa API. Untuk dapat +mengakses API ini, administrator klaster harus memastikan bahwa: + +* [API Later Pengumpulan](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) diaktifkan. + +* API berikut ini terdaftar: + + * Untuk metrik sumber daya, ini adalah API `metrics.k8s.io`, pada umumnya disediakan oleh + [metrics-server](https://github.com/kubernetes-incubator/metrics-server). API tersebut dapat + diaktifkan sebagai *addon* atau tambahan pada klaster. + + * Untuk metrik khusus, ini adalah API `custom.metrics.k8s.io`. API ini disediakan oleh API + adaptor server yang disediakan oleh vendor yang memberi solusi untuk metrik. Cek dengan + *pipeline* metrikmu atau [daftar solusi yang sudah diketahui](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api). Jika kamu ingin membuat sendiri, perhatikan + [*boilerplate* berikut](https://github.com/kubernetes-incubator/custom-metrics-apiserver) untuk memulai. + + * Untuk metrik eksternal, ini adalah API `external.metrics.k8s.io`. API ini mungkin disediakan oleh penyedia + metrik khusus diatas. + +* Nilai dari `--horizontal-pod-autoscaler-use-rest-clients` adalah `true` atau tidak ada. Ubah nilai tersebut menjadi + `false` untuk mengubah ke *autoscaling* berdasarkan Heapster, dimana ini sudah tidak didukung lagi. + +Untuk informasi lebih lanjut mengenai metrik-metrik ini dan bagaimana perbedaan setiap metrik, perhatikan proposal +desain untuk [HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md), +[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md) +dan [external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md). + +Untuk contoh bagaimana menggunakan metrik-metrik ini, perhatikan [panduan penggunaan metrik khusus](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics) +dan [panduan penggunaan metrik eksternal](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects). + +## Dukungan untuk Perilaku *Scaling* yang dapat Dikonfigurasi + +Mulai dari versi [v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md), API `v2beta2` mengizinkan perilaku *scaling* dapat +dikonfigurasi melalui *field* `behavior` pada HorizontalPodAutoscaler. Perilaku *scaling up* dan *scaling down* +ditentukan terpisah pada *field* `slaceUp` dan *field* `scaleDown`, dibawah dari *field* `behavior`. +Sebuah stabilisator dapat ditentukan untuk kedua arah *scale* untuk mencegah perubahan replika yang terlalu +berbeda pada target *scaling*. Menentukan *scaling policies* akan mengontrol perubahan replika +ketika *scaling*. + +### Scaling Policies + +Satu atau lebih *scaling policies* dapat ditentukan pada *field* `behavior`. Ketika beberapa +*policies* ditentukan, *policy* yang mengizinkan *scale* terbesar akan dipilih secara *default*. +Contoh berikut menunjukkan perilaku ketika mengurangi replika: + +```yaml +behavior: + scaleDown: + policies: + - type: Pods + value: 4 + periodSeconds: 60 + - type: Percent + value: 10 + periodSeconds: 60 +``` + +Ketika jumlah Pod lebih besar dari 40, *policy* kedua akan digunakan untuk *scaling down*. +Misalnya, jika terdapat 80 replika dan target sudah di *scale down* ke 10 replika, 8 replika +akan dikurangi pada tahapan pertama. Pada iterasi berikutnya, ketika jumlah replika adalah 72, +10% dari Pod adalah 7.2 tetapi akan dibulatkan menjadi 8. Dalam setiap iterasi pada _controller_ +*autoscaler* jumlah Pod yang akan diubah akan dihitung ulang berdarkan jumlah replika sekarang. +Ketika jumlah replika dibawah 40, *policy* pertama (Pods) akan digunakan dan 4 replika akan dikurangi +dalam satu waktu. + +`periodSeconds` menunjukkan berapa lama waktu pada iterasi terkhir untuk menunjukkan *policy* +mana yang akan digunakan. *Policy* pertama mengizinkan maksimal 4 replika di *scale down* +dalam satu menit. *Policy* kedua mengixinkan maksimal 10% dari total replika sekarang di +*scale down* dalam satu menit. + +Pemilihan *policy* dapat diubah dengan menentukannya pada *field* `selectPolicy` untuk sebuah +arah *scale* (baik *scale up* ataupun *scale down*). Dengan menentukan nilai `Min`, +HorizontalPodAutoscaler akan memilih *policy* yang mengizinkan pergantian replika paling sedikit. +Dengan menuntukan nilai `Disable`, akan menghentikan *scaling* pada arah *scale* tersebut. + +### Jendela Stabilisasi + +Jendela stabilisasi digunakan untuk membatasi perubahan replika yang terlalu drastis ketika +metrik yang digunakan untuk *scaling* tetap berubah-ubah. Jendela stabilisasi digunakan oleh +algoritma *autoscaling* untuk memperhitungkan jumlah replika yang diharapkan dari *scaling* +sebelumnya untuk mencengah *scaling. Berikut adalah contoh penggunaan jendela stabilisasi +pada `scaleDown`. +```yaml +scaleDown: + stabilizationWindowSeconds: 300 +``` +Ketika metrik menandakan bahwa replika pada target akan dikurangi, algoritma akan memperhatikan +jumlah replika yang diharapkan sebelumnya dan menggunakan nilai terbesar dari interval +yang ditentukan. Pada contoh diatas, semua jumlah replika yang diharapkan pada 5 menit +yang lalu akan dipertimbangkan. +### Perilaku Standar +Untuk menggunakan *scaling* khusus, tidak semua *field* perlu ditentukan. Hanta nilai yang +perlu diubah saja yang ditentukan. Nilai khusus ini akan digabungkan dengan nilai standar. +Berikut adalah nilai standar perilaku pada algoritma yang digunakan HorizontalPodAutoscaler. + +```yaml +behavior: + scaleDown: + stabilizationWindowSeconds: 300 + policies: + - type: Percent + value: 100 + periodSeconds: 15 + scaleUp: + stabilizationWindowSeconds: 0 + policies: + - type: Percent + value: 100 + periodSeconds: 15 + - type: Pods + value: 4 + periodSeconds: 15 + selectPolicy: Max +``` + +Untuk `scaleDown`, nilai dari jendela stabilisasi adalah 300 detik (atau nilai dari +*flag* `--horizontal-pod-autoscaler-downscale-stabilization` jika ditentukan). Hanya terdapat +satu *policy*, yaitu mengizinkan menghapus 100% dari replika yang berjalan, +artinya target replikasi di *scale* ke jumlah replika minimum. Untuk `scaleUp`, tidak terdapat +jendela stabilisasi. Jika metrik menunjukkan bahwa replika pada target perlu diperbanyak, maka replika akan +diperbanyak di secara langsung. Untuk `scaleUp` terdapat dua *policy*, yaitu empat Pod atau 100% dari +replika yang berjalan akan ditambahkan setiap 15 detik sampai HorizontalPodAutoscaler +dalam keadaan stabil. + +### Contoh: Mengubah Jendela Stabiliasi pada *field* scaleDown + +Untuk membuat jendela stabilisai untuk pengurangan replika selama satu menit, perilaku +berikut ditambahkan pada HorizontalPodAutoscaler. + +```yaml +behavior: + scaleDown: + stabilizationWindowSeconds: 60 +``` + +### Contoh: Membatasi nilai *scale down* + +Untuk membatasi total berapa Pod yang akan dihapus, 10% setiap menut, perilaku +berikut ditambahkan pada HorizontalPodAutoscaler. + +```yaml +behavior: + scaleDown: + policies: + - type: Percent + value: 10 + periodSeconds: 60 +``` + +Untuk mengizinkan penghapusan 5 Pod terakhir, *policy* lain dapat ditambahkan. + +```yaml +behavior: + scaleDown: + policies: + - type: Percent + value: 10 + periodSeconds: 60 + - type: Pods + value: 5 + periodSeconds: 60 + selectPolicy: Max +``` + +### Contoh: menonakfitkan *scale down* + +Nilai `Disable` pada `selectPolicy` akan menonaktifkan *scaling* pada arah yang +ditentukan. Untuk mencegah pengurangan replika dapat menggunakan *policy* berikut. + +```yaml +behavior: + scaleDown: + selectPolicy: Disabled +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + +* Dokumentasi desain [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md). +* Perintah kubectl autoscale [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). +* Contoh penggunaan [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). + +{{% /capture %}} diff --git a/content/id/examples/pods/pod-projected-svc-token.yaml b/content/id/examples/pods/pod-projected-svc-token.yaml new file mode 100644 index 0000000000..985073c8d3 --- /dev/null +++ b/content/id/examples/pods/pod-projected-svc-token.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /var/run/secrets/tokens + name: vault-token + serviceAccountName: build-robot + volumes: + - name: vault-token + projected: + sources: + - serviceAccountToken: + path: vault-token + expirationSeconds: 7200 + audience: vault diff --git a/content/id/examples/pods/private-reg-pod.yaml b/content/id/examples/pods/private-reg-pod.yaml new file mode 100644 index 0000000000..594e47a7c5 --- /dev/null +++ b/content/id/examples/pods/private-reg-pod.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: private-reg +spec: + containers: + - name: private-reg-container + image: + imagePullSecrets: + - name: regcred + diff --git a/content/id/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml b/content/id/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml new file mode 100644 index 0000000000..98823f9d86 --- /dev/null +++ b/content/id/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml @@ -0,0 +1,26 @@ +kind: Pod +apiVersion: v1 +metadata: + name: mypod + labels: + foo: bar +spec: + topologySpreadConstraints: + - maxSkew: 1 + topologyKey: zone + whenUnsatisfiable: DoNotSchedule + labelSelector: + matchLabels: + foo: bar + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: zone + operator: NotIn + values: + - zoneC + containers: + - name: pause + image: k8s.gcr.io/pause:3.1 \ No newline at end of file diff --git a/content/id/examples/pods/topology-spread-constraints/one-constraint.yaml b/content/id/examples/pods/topology-spread-constraints/one-constraint.yaml new file mode 100644 index 0000000000..a0a41188ec --- /dev/null +++ b/content/id/examples/pods/topology-spread-constraints/one-constraint.yaml @@ -0,0 +1,17 @@ +kind: Pod +apiVersion: v1 +metadata: + name: mypod + labels: + foo: bar +spec: + topologySpreadConstraints: + - maxSkew: 1 + topologyKey: zone + whenUnsatisfiable: DoNotSchedule + labelSelector: + matchLabels: + foo: bar + containers: + - name: pause + image: k8s.gcr.io/pause:3.1 \ No newline at end of file diff --git a/content/id/examples/pods/topology-spread-constraints/two-constraints.yaml b/content/id/examples/pods/topology-spread-constraints/two-constraints.yaml new file mode 100644 index 0000000000..aa142b7abb --- /dev/null +++ b/content/id/examples/pods/topology-spread-constraints/two-constraints.yaml @@ -0,0 +1,23 @@ +kind: Pod +apiVersion: v1 +metadata: + name: mypod + labels: + foo: bar +spec: + topologySpreadConstraints: + - maxSkew: 1 + topologyKey: zone + whenUnsatisfiable: DoNotSchedule + labelSelector: + matchLabels: + foo: bar + - maxSkew: 1 + topologyKey: node + whenUnsatisfiable: DoNotSchedule + labelSelector: + matchLabels: + foo: bar + containers: + - name: pause + image: k8s.gcr.io/pause:3.1 \ No newline at end of file diff --git a/content/it/docs/concepts/architecture/controller.md b/content/it/docs/concepts/architecture/controller.md new file mode 100644 index 0000000000..f8402fb161 --- /dev/null +++ b/content/it/docs/concepts/architecture/controller.md @@ -0,0 +1,90 @@ +--- +title: Controller +content_template: concept +weight: 30 +--- + + + +Nella robotica e nell'automazione, un _circuito di controllo_ (_control loop_) è un un'iterazione senza soluzione di continuità che regola lo stato di un sistema. + +Ecco un esempio di un circuito di controllo: il termostato di una stanza. + +Quando viene impostata la temperatura, si definisce attraverso il termostato lo *stato desiderato*. L'attuale temperatura nella stanza è invece lo *stato corrente*. Il termostato agisce per portare lo stato corrente il più vicino possibile allo stato desiderato accendendo e spegnendo le apparecchiature. + +{{< glossary_definition term_id="controller" length="short" >}} + + + +## Il modello del controller + +Un _controller_ monitora almeno una tipo di risorsa registrata in Kubernetes. +Questi [oggetti](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) hanno una proprietà chiamata *spec* (specifica) che rappresenta lo stato desiderato. Il o i *controller* per quella risorsa sono responsabili di mantenere lo stato corrente il più simile possibile rispetto allo stato desiderato. + +Il _controller_ potrebbe eseguire l'azione relativa alla risorsa in questione da sé; più comunemente, in Kubernetes, un _controller_ invia messaggi all'{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} che a sua volta li rende disponibili ad altri componenti nel cluster. Di seguito troverete esempi per questo scenario. + +{{< comment >}} +Alcuni controller nativi, come ad esempio l'_endpoints_ controller, agiscono su oggetti che non hanno una specifica. Per semplicità, questa pagina non entra in quel dettaglio. +{{< /comment >}} + +### Controllo attraverso l'API server + +Il {{< glossary_tooltip term_id="job" >}} _controller_ è un esempio di un _controller_ nativo in Kubernetes. I _controller_ nativi gestiscono lo stato interagendo con l'API server presente nel cluster. + +Il Job è una risorsa di Kubernetes che lancia uno o più {{< glossary_tooltip term_id="pod" text="Pod" >}} per eseguire un lavoro (task) e poi fermarsi. + +(Una volta che è stato [schedulato](/docs/concepts/scheduling-eviction/), un oggetto _Pod_ diventa parte dello stato desisderato di un dato _kubelet_). + +Quando il Job _controller_ vede un nuovo lavoro da svolgere si assicura che, da qualche parte nel cluster, i _kubelet_ anche sparsi su più nodi eseguano il numero corretto di _Pod_ necessari per eseguire il lavoro richiesto. Il Job _controller_ non esegue direttamente alcun _Pod_ o _container_ bensì chiede all'API server di creare o rimuovere i _Pod_. Altri componenti appartenenti al {{< glossary_tooltip text="control plane" term_id="control-plane" >}} reagiscono in base alle nuove informazioni (ci sono nuovi _Pod_ da creare e gestire) e cooperano al completamento del job. + +Dopo che un nuovo Job è stato creato, lo stato desiderato per quel Job è il suo completamento. Il Job _controller_ fa sì che lo stato corrente per quel Job sia il più vicino possibile allo stato desiderato: creare _Pod_ che eseguano il lavoro che deve essere effettuato attraverso il Job, così che il Job sia prossimo al completamento. + +I _controller_ aggiornano anche gli oggetti che hanno configurato. Ad esempio: una volta che il lavoro relativo ad un dato Job è stato completato, il Job _controller_ aggiorna l'oggetto Job segnandolo come `Finished`. + +(Questo è simile allo scenario del termostato che spegne un certo led per indicare che ora la stanza ha raggiungo la temperatura impostata) + +### Controllo diretto + +A differenza del Job, alcuni _controller_ devono eseguire delle modifiche a parti esterne al cluster. + +Per esempio, se viene usato un circuito di controllo per assicurare che ci sia un numero sufficiente di {{< glossary_tooltip text="Nodi" term_id="node" >}} nel cluster, allora il _controller_ ha bisogno che qualcosa al di fuori del cluster configuri i nuovi _Nodi_ quando sarà necessario. + +I _controller_ che interagiscono con un sistema esterno trovano il loro stato desiderato attraverso l'API server, quindi comunicano direttamente con un sistema esterno per portare il loro stato corrente più in linea possibile con lo stato desiderato + +(In realtà c'è un _controller_ che scala orizzontalmente i nodi nel cluster. Vedi [Cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)). + +## Stato desiderato versus corrente {#desiderato-vs-corrente} + +Kubernetes ha una visione *cloud-native* dei sistemi, ed è in grado di gestire continue modifiche. + +Il cluster viene modificato continuamente durante la sua attività ed il _circuito di controllo_ è in grado di risolvere automaticamente i possibili guasti. + +Fino a che i _controller_ del cluster sono in funzione ed in grado di apportare le dovute modifiche, non è rilevante che lo stato complessivo del cluster sia o meno stabile. + +## Progettazione + +Come cardine della sua progettazione, Kubernetes usa vari _controller_ ognuno dei quali è responsabile per un particolare aspetto dello stato del cluster. Più comunemente, un dato _circuito di controllo_ (_controller_) usa un tipo di risorsa per il suo stato desiderato, ed utilizza anche risorse di altro tipo per raggiungere questo stato desiderato. Per esempio il Job _controller_ tiene traccia degli oggetti di tipo _Job_ (per scoprire nuove attività da eseguire) e degli oggetti di tipo _Pod_ (questi ultimi usati per eseguire i _Job_, e quindi per controllare quando il loro lavoro è terminato). In questo caso, qualcos'altro crea i _Job_, mentre il _Job_ _controller_ crea i _Pod_. + +È utile avere semplici _controller_ piuttosto che un unico, monolitico, _circuito di controllo_. I _controller_ possono guastarsi, quindi Kubernetes è stato disegnato per gestire questa eventualità. + +{{< note >}} +Ci possono essere diversi _controller_ che creato o aggiornano lo stesso tipo di oggetti. Dietro le quinte, i _controller_ di Kubernetes si preoccupano esclusivamente delle risorse (di altro tipo) collegate alla risorsa primaria da essi controllata. + +Per esempio, si possono avere _Deployment_ e _Job_; entrambe creano _Pod_. Il Job _controller_ non distrugge i _Pod_ creati da un _Deployment_, perché ci sono informazioni (*{{< glossary_tooltip term_id="label" text="labels" >}}*) che vengono usate dal _controller_ per distinguere i _Pod_. +{{< /note >}} + +## I modi per eseguire i _controller_ {#eseguire-controller} + +Kubernetes annovera un insieme di _controller_ nativi che sono in esecuzione all'interno del {{< glossary_tooltip term_id="kube-controller-manager" >}}. Questi _controller_ nativi forniscono importanti funzionalità di base. + +Il Deployment _controller_ ed il Job _controller_ sono esempi di _controller_ che vengono forniti direttamente da Kubernetes stesso (ovvero _controller_ "nativi"). +Kubernetes consente di eseguire un _piano di controllo_(_control plane_) resiliente, di modo che se un dei _controller_ nativi dovesse fallire, un'altra parte del piano di controllo si occuperà di eseguire quel lavoro. + +Al fine di estendere Kubernetes, si possono avere _controller_ in esecuzione al di fuori del piano di controllo. Oppure, se si desidera, è possibile scriversi un nuovo _controller_. È possibile eseguire il proprio controller come una serie di _Pod_, oppure esternamente rispetto a Kubernetes. Quale sia la soluzione migliore, dipende dalla responsabilità di un dato controller. + +## {{% heading "whatsnext" %}} +* Leggi in merito [Kubernetes control plane](/docs/concepts/#kubernetes-control-plane) +* Scopri alcune delle basi degli [oggetti di Kubernetes](/docs/concepts/#kubernetes-objects) +* Per saperne di più riguardo alle [API di Kubernetes](/docs/concepts/overview/kubernetes-api/) +* Se vuoi creare un tuo _controller_, guarda [i modelli per l'estensibilità](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Estendere Kubernetes. + diff --git a/content/it/docs/reference/glossary/controller.md b/content/it/docs/reference/glossary/controller.md new file mode 100755 index 0000000000..df5a7cfb94 --- /dev/null +++ b/content/it/docs/reference/glossary/controller.md @@ -0,0 +1,21 @@ +--- +title: Controller +id: controller +date: 2018-04-12 +full_link: /docs/concepts/architecture/controller/ +short_description: > + Un software che implementa un circuito di controllo che osserva lo stato condiviso del cluster attraverso l'API server e apporta le modifiche necessarie per portate lo stato corrente verso lo stato desiderato. + +aka: +tags: +- architecture +- fundamental +--- +In Kubernetes, i _controller_ sono circuiti di controllo che osservano lo stato del {{< glossary_tooltip term_id="cluster" text="cluster">}}, e apportano o richiedono modifiche quando necessario. Ogni _controller_ prova a portare lo stato corrente del cluster verso lo stato desiderato. + + + +I _controller_ osservano lo stato condiviso del cluster attraverso il {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} (che è parte del {{< glossary_tooltip term_id="control-plane" >}}). + +Alcuni _controller_ vengono eseguiti all'interno del _piano di controllo_ (_control plane_), e forniscono circuiti di controllo che sono parte dell'operatività base di Kubernetes. Ad esempio: il _deployment_ _controller_, il _daemonset_ _controller_, il _namespace_ _controller_, ed il _persistent volume_ +_controller_ (e altri) vengono tutti eseguiti all'interno del {{< glossary_tooltip term_id="kube-controller-manager" >}}. diff --git a/content/it/docs/reference/glossary/job.md b/content/it/docs/reference/glossary/job.md new file mode 100755 index 0000000000..6d3f8ef3af --- /dev/null +++ b/content/it/docs/reference/glossary/job.md @@ -0,0 +1,20 @@ +--- +title: Job +id: job +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion +short_description: > + Uno o più lavori (task) che vengono eseguiti fino al loro completamento. + +aka: +tags: +- fundamental +- core-object +- workload +--- + Uno o più lavori (task) che vengono eseguiti fino al loro completamento. + + + +Crea uno o più oggetti di tipo {{< glossary_tooltip term_id="pod" >}} ed assicura che un numero preciso di questi venga completato con successo. Quando i _Pod_ vengono eseguiti con successo, il _Job_ tiene traccia della completamento andato a buon fine. + diff --git a/content/it/docs/reference/glossary/node.md b/content/it/docs/reference/glossary/node.md index 25bd25f3d0..3bc3df62bf 100755 --- a/content/it/docs/reference/glossary/node.md +++ b/content/it/docs/reference/glossary/node.md @@ -16,4 +16,4 @@ tags: Un worker node può essere una VM o una macchina fisica, in base al cluster. Possiede daemon locali o servizi ncessari a eseguire {{< glossary_tooltip text="Pods" term_id="pod" >}} e viene gestito dalla control plane. I deamon i un node includono {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}, e un container runtiome che implementa {{< glossary_tooltip text="CRI" term_id="cri" >}} come ad esempio {{< glossary_tooltip term_id="docker" >}}. -Nelle prime versioni di Kubernetes, i Node venivano chiamati "Minions". \ No newline at end of file +Nelle prime versioni di Kubernetes, i Node venivano chiamati "Minion". diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index a6d1d8f17d..e23ab9312f 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -894,7 +894,7 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -KubernetseはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というFeature Gateを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。 +KubernetesはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というFeature Gateを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。 そのFeature Gateが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。 Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。 diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md index edf95ce712..4aa6d44ecb 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md @@ -167,7 +167,7 @@ Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml" the KUBELET_KUBEADM_ARGS variable dynamically EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env # This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, -#the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. +# the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. # KUBELET_EXTRA_ARGS should be sourced from this file. EnvironmentFile=-/etc/default/kubelet ExecStart= @@ -192,9 +192,8 @@ The DEB and RPM packages shipped with the Kubernetes releases are: | Package name | Description | |--------------|-------------| | `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. | -| `kubelet` | Installs the `/usr/bin/kubelet` binary. | +| `kubelet` | Installs the kubelet binary in `/usr/bin` and CNI binaries in `/opt/cni/bin`. | | `kubectl` | Installs the `/usr/bin/kubectl` binary. | -| `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. | | `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). | diff --git a/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md index d09929b9ee..0e2b699e89 100644 --- a/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/ja/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -89,7 +89,7 @@ pod/redis 1/1 Running 0 52s `kubectl exec`を使ってPodに入り、`redis-cli`ツールを実行して設定が正しく適用されたことを確認してください: ```shell -kubectl exec -it redis redis-cli +kubectl exec -it redis -- redis-cli 127.0.0.1:6379> CONFIG GET maxmemory 1) "maxmemory" 2) "2097152" diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md index 30424ead72..34bc413e74 100644 --- a/content/ko/docs/concepts/_index.md +++ b/content/ko/docs/concepts/_index.md @@ -33,15 +33,15 @@ weight: 40 * [파드](/ko/docs/concepts/workloads/pods/pod-overview/) * [서비스](/ko/docs/concepts/services-networking/service/) * [볼륨](/ko/docs/concepts/storage/volumes/) -* [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) +* [네임스페이스(Namespace)](/ko/docs/concepts/overview/working-with-objects/namespaces/) 또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다. -* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) -* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/) -* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/) -* [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/) -* [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/) +* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/) +* [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/) +* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/) +* [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/) +* [잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/) ## 쿠버네티스 컨트롤 플레인 @@ -66,7 +66,6 @@ weight: 40 개념 페이지를 작성하기를 원하면, -개념 페이지 유형과 개념 템플릿에 대한 정보가 있는 -[페이지 템플릿 사용하기](/docs/home/contribute/page-templates/)를 참조한다. - +개념 페이지 유형에 대한 정보가 있는 +[페이지 컨텐츠 유형](/docs/contribute/style/page-content-types/#concept)을 참조한다. diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index 12b1d714e8..b3806591c2 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -19,7 +19,6 @@ weight: 40 - ## 디자인 @@ -31,6 +30,7 @@ weight: 40 프로세스에 여러 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 구현한다. + {{< note >}} 또한 사용자는 클라우드 컨트롤러 매니저를 컨트롤 플레인의 일부가 아닌 쿠버네티스 {{< glossary_tooltip text="애드온" term_id="addons" >}}으로 diff --git a/content/ko/docs/concepts/architecture/control-plane-node-communication.md b/content/ko/docs/concepts/architecture/control-plane-node-communication.md index 819ee0c384..62fd283b2f 100644 --- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md @@ -15,7 +15,7 @@ aliases: ## 노드에서 컨트롤 플레인으로의 통신 -노드에서 컨트롤 플레인까지의 모든 통신 경로는 API 서버에서 종료된다(다른 마스터 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). 일반적인 배포에서 API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(443)에서 원격 연결을 수신하도록 구성된다. +쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다(다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다. 특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다. 노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다. @@ -28,9 +28,11 @@ API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증 결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한 기본 작동 모드는 기본적으로 보호되며 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있다. ## 컨트롤 플레인에서 노드로의 통신 + 컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다. 첫 번째는 API 서버에서 클러스터의 각 노드에서 실행되는 kubelet 프로세스이다. 두 번째는 API 서버의 프록시 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 이르는 것이다. ### API 서버에서 kubelet으로의 통신 + API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다. * 파드에 대한 로그를 가져온다. @@ -58,9 +60,10 @@ API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 SSH 터널은 현재 더 이상 사용되지 않으므로 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다. ### Konnectivity 서비스 + {{< feature-state for_k8s_version="v1.18" state="beta" >}} -SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 연결을 유지한다. -그런 다음 컨트롤 플레인에서 노드로의 모든 트래픽은 이 연결을 통과한다. +SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다. +Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다. -클러스터에서 설정하는 방법에 대해서는 [Konnectivity 서비스 설정](/docs/tasks/setup-konnectivity/)을 참조한다. +[Konnectivity 서비스 태스크](/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다. diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md index 6688a969d7..7782d27855 100644 --- a/content/ko/docs/concepts/architecture/controller.md +++ b/content/ko/docs/concepts/architecture/controller.md @@ -48,7 +48,7 @@ weight: 30 내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와 상호 작용하며 상태를 관리한다. -잡은 단일 {{< glossary_tooltip term_id="pod" >}} 또는 여러 파드를 실행하고, +잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고, 작업을 수행한 다음 중지하는 쿠버네티스 리소스 이다. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 197ae71422..e4f5c9564e 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -31,7 +31,8 @@ weight: 10 1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록 2. 사용자 또는 다른 사용자가 노드 오브젝트를 수동으로 추가 -노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후 컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다. +노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후 +컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다. 예를 들어 다음 JSON 매니페스트에서 노드를 만들려는 경우이다. ```json @@ -61,7 +62,8 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록 노드 오브젝트를 명시적으로 삭제해야한다. {{< /note >}} -노드 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +노드 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. ### 노드에 대한 자체-등록 @@ -73,7 +75,9 @@ kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API - `--kubeconfig` - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로. - `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게 {{< glossary_tooltip text="클라우드 제공자" term_id="cloud-provider" >}}와 소통할지에 대한 방법. - `--register-node` - 자동으로 API 서버에 등록. - - `--register-with-taints` - 주어진 taint 리스트 (콤마로 분리된 `=:`)를 가진 노드 등록. `register-node`가 거짓이면 동작 안함. + - `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}} 리스트(콤마로 분리된 `=:`)를 가진 노드 등록. + + `register-node`가 거짓이면 동작 안 함. - `--node-ip` - 노드의 IP 주소. - `--node-labels` - 클러스터에 노드를 등록할 때 추가 할 {{< glossary_tooltip text="레이블" term_id="label" >}}([NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)에 의해 적용되는 레이블 제한 사항 참고). - `--node-status-update-frequency` - 얼마나 자주 kubelet이 마스터에 노드 상태를 게시할 지 정의. @@ -188,6 +192,9 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳 스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다. 또한 파드는 노드의 테인트를 극복(tolerate)할 수 있는 톨러레이션(toleration)을 가질 수 있다. +자세한 내용은 +[컨디션별 노드 테인트하기](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/#컨디션별-노드-테인트하기)를 참조한다. + ### 용량과 할당가능 {#capacity} 노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 @@ -201,7 +208,7 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳 [컴퓨팅 리소스 예약](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)하는 방법을 배우는 동안 용량 및 할당가능 리소스에 대해 자세히 읽어보자. -### 정보 {#info} +### 정보 커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은노드에 대한 일반적인 정보를 보여준다. 이 정보는 Kubelet에 의해 노드로부터 수집된다. @@ -285,6 +292,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 추가한다. 이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다. + {{< caution >}} `kubectl cordon` 은 노드를 'unschedulable'로 표기하는데, 이는 서비스 컨트롤러가 이전에 자격 있는 로드밸런서 노드 대상 목록에서 해당 노드를 제거하기에 @@ -318,7 +326,6 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 `TopologyManager` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다. - 자세한 내용은 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다. @@ -331,4 +338,3 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 섹션을 읽어본다. * [테인트와 톨러레이션](/ko/docs/concepts/configuration/taint-and-toleration/)을 읽어본다. * [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 읽어본다. - diff --git a/content/ko/docs/concepts/cluster-administration/cloud-providers.md b/content/ko/docs/concepts/cluster-administration/cloud-providers.md index 30dc7b230e..91e1a4e7ac 100644 --- a/content/ko/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/ko/docs/concepts/cluster-administration/cloud-providers.md @@ -134,13 +134,13 @@ CloudStack 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이 GCE 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다. 참고로 쿠버네티스 노드 이름의 첫 번째 세그먼트는 GCE 인스턴스 이름과 일치해야 한다(예: `kubernetes-node-2.c.my-proj.internal` 이름이 지정된 노드는 `kubernetes-node-2` 이름이 지정된 인스턴스에 해당해야 함). -## HUAWEI 클라우드 +## HUAWEI CLOUD 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)이다. ### 노드 이름 -HUAWEI 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 프라이빗 IP 주소가 필요하다. +HUAWEI CLOUD 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 프라이빗 IP 주소가 필요하다. 노드에서 kubelet을 시작할 때 반드시 `--hostname-override=` 를 사용한다. ## OpenStack @@ -415,6 +415,7 @@ Baidu 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으 참고로 쿠버네티스 노드 이름은 Baidu VM 프라이빗 IP와 일치해야 한다. ## Tencent 쿠버네티스 엔진 + 이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)이다. ### 노드 이름 diff --git a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md index a6907ad44c..d749710484 100644 --- a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -78,7 +78,6 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대 - ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/cluster-administration/manage-deployment.md b/content/ko/docs/concepts/cluster-administration/manage-deployment.md index 6bed969e90..c2835e78cb 100644 --- a/content/ko/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/ko/docs/concepts/cluster-administration/manage-deployment.md @@ -400,7 +400,7 @@ rm /tmp/nginx.yaml `kubectl patch` 를 사용하여 API 오브젝트를 인플레이스 업데이트할 수 있다. 이 명령은 JSON 패치, JSON 병합 패치 그리고 전략적 병합 패치를 지원한다. -[kubectl patch를 사용한 인플레이스 API 오브젝트 업데이트](/docs/tasks/run-application/update-api-object-kubectl-patch/)와 +[kubectl patch를 사용한 인플레이스 API 오브젝트 업데이트](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)와 [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch)를 참조한다. diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index 8e5eb3bed1..f61add3919 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -43,7 +43,7 @@ API [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-ob 컨피그맵의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. -## 컨피그맵과 파드(Pod) +## 컨피그맵과 파드 컨피그맵을 참조하는 파드 `spec` 을 작성하고 컨피그맵의 데이터를 기반으로 해당 파드의 컨테이너를 구성할 수 있다. 파드와 컨피그맵은 @@ -157,7 +157,91 @@ spec: 사용할 수도 있다. {{< /note >}} +## 컨피그맵 사용하기 +컨피그맵은 데이터 볼륨으로 마운트할 수 있다. 컨피그맵은 파드에 직접적으로 +노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어, +컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다. + +### 파드에서 컨피그맵을 파일로 사용하기 + +파드의 볼륨에서 컨피그맵을 사용하려면 다음을 수행한다. + +1. 컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을 참조할 수 있다. +1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은 원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configmap.localObjectReference` 필드를 설정한다. +1. 컨피그맵이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. `.spec.containers[].volumeMounts[].readOnly = true` 를 설정하고 컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다. +1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 컨피그맵의 `data` 맵 각 키는 `mountPath` 아래의 파일 이름이 된다. + +다음은 볼륨에 컨피그맵을 마운트하는 파드의 예시이다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + configmap: + name: myconfigmap +``` + +사용하려는 각 컨피그맵은 `.spec.volumes` 에서 참조해야 한다. + +파드에 여러 컨테이너가 있는 경우 각 컨테이너에는 자체 `volumeMounts` 블록이 필요하지만, +컨피그맵은 각 컨피그맵 당 하나의 `.spec.volumes` 만 필요하다. + +#### 마운트된 컨피그맵이 자동으로 업데이트 + +현재 볼륨에서 사용된 컨피그맵이 업데이트되면, 프로젝션된 키도 마찬가지로 업데이트된다. +kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최신 상태인지 확인한다. +그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다. +캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의 +`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다. + +컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접 +모든 요청을 리디렉션할 수 있다. +따라서 컨피그맵이 업데이트되는 순간부터 새 키가 파드에 업데이트되는 순간까지의 +총 지연시간은 kubelet 동기화 기간 + 캐시 전파 지연만큼 길 수 있다. 여기서 캐시 +전파 지연은 선택한 캐시 유형에 따라 달라질 수 있다(전파 +지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함). + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +쿠버네티스 알파 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은 개별 시크릿과 +컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 컨피그맵을 광범위하게 +사용하는 클러스터(최소 수만 개의 고유한 컨피그맵이 파드에 마운트)의 경우 +데이터 변경을 방지하면 다음과 같은 이점이 있다. + +- 애플리케이션 중단을 일으킬 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호 +- immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴 + +이 기능을 사용하려면 `ImmutableEmphemeralVolumes` +[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고 +시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다. +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + ... +data: + ... +immutable: true +``` + +{{< note >}} +컨피그맵 또는 시크릿을 immutable로 표시하면, 이 변경 사항을 되돌리거나 +`data` 필드 내용을 변경할 수 _없다_. 컨피그맵만 삭제하고 다시 작성할 수 있다. +기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을 유지하며, 이러한 파드를 다시 작성하는 +것을 권장한다. +{{< /note >}} ## {{% heading "whatsnext" %}} @@ -167,4 +251,3 @@ spec: * 코드를 구성에서 분리하려는 동기를 이해하려면 [Twelve-Factor 앱](https://12factor.net/ko/)을 읽어본다. - diff --git a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index 0e50a842bb..483e664e24 100644 --- a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -99,7 +99,7 @@ kubectl config view `KUBECONFIG` 환경 변수 설정의 예로, [KUBECONFIG 환경 변수 설정](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#kubeconfig-환경-변수-설정)를 참조한다. - 그렇지 않다면, 병합하지 않고 기본 kubecofig 파일인 `$HOME/.kube/config`를 사용한다. + 그렇지 않다면, 병합하지 않고 기본 kubeconfig 파일인 `$HOME/.kube/config`를 사용한다. 1. 이 체인에서 첫 번째를 기반으로 사용할 컨텍스트를 결정한다. diff --git a/content/ko/docs/concepts/configuration/pod-overhead.md b/content/ko/docs/concepts/configuration/pod-overhead.md index cafd3a921d..3dd850067c 100644 --- a/content/ko/docs/concepts/configuration/pod-overhead.md +++ b/content/ko/docs/concepts/configuration/pod-overhead.md @@ -8,6 +8,7 @@ weight: 20 {{< feature-state for_k8s_version="v1.18" state="beta" >}} + 노드 위에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다. 이러한 리소스는 파드 내의 컨테이너들을 구동하기 위한 리소스 이외에 추가적으로 필요한 것이다. _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해 diff --git a/content/ko/docs/concepts/containers/container-environment.md b/content/ko/docs/concepts/containers/container-environment.md index 95671af60d..799306a9ff 100644 --- a/content/ko/docs/concepts/containers/container-environment.md +++ b/content/ko/docs/concepts/containers/container-environment.md @@ -56,6 +56,7 @@ FOO_SERVICE_PORT=<서비스가 동작 중인 포트> * [컨테이너 라이프사이클 훅(hooks)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기. -* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실제 경험 얻기. +* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) + 실제 경험 얻기. diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index afc9a3076a..f03847c38c 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -63,6 +63,7 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전 - Oracle 클라우드 인프라스트럭처 레지스트리(OCIR) 사용 - IAM 역할과 정책을 사용하여 OCIR 저장소에 접근을 제어함 - Azure 컨테이너 레지스트리(ACR) 사용 + - IAM 역할과 정책을 사용하여 ACR 저장소에 접근을 제어함 - IBM 클라우드 컨테이너 레지스트리 사용 - IAM 역할 및 정책을 사용하여 IBM 클라우드 컨테이너 레지스트리에 대한 접근 권한 부여 - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 @@ -127,13 +128,19 @@ kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다 - `aws_credentials.go:116] Got ECR credentials from ECR API for .dkr.ecr..amazonaws.com` ### Azure 컨테이너 레지스트리(ACR) 사용 -[Azure 컨테이너 레지스트리](https://azure.microsoft.com/en-us/services/container-registry/)를 사용하는 경우 -관리자 역할의 사용자나 서비스 주체(principal) 중 하나를 사용하여 인증할 수 있다. +쿠버네티스는 Azure 쿠버네티스 서비스(AKS)를 사용할 때 +[Azure 컨테이너 레지스트리(ACR)](https://azure.microsoft.com/ko-kr/services/container-registry/)를 +기본적으로 지원한다. + +AKS 클러스터 서비스 주체(principal)는 ACR 인스턴스에서 `ArcPull` 권한이 있어야 한다. 구성에 대한 +지침은 [Azure 쿠버네티스 서비스에서 Azure 컨테이너 레지스트리로 인증](https://docs.microsoft.com/ko-kr/azure/aks/cluster-container-registry-integration)을 참조한다. 그런 다음, 전체 ACR 이미지 이름(예: `my_registry.azurecr.io/image:tag`)을 사용한다. + +ACR 관리자 또는 서비스 주체를 사용해서 인증할 수도 있다. 어느 경우라도, 인증은 표준 Docker 인증을 통해서 수행된다. 이러한 지침은 [azure-cli](https://github.com/azure/azure-cli) 명령줄 도구 사용을 가정한다. 우선 레지스트리를 생성하고 자격 증명을 만들어야한다. 이에 대한 전체 문서는 -[Azure 컨테이너 레지스트리 문서](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli)에서 찾을 수 있다. +[Azure 컨테이너 레지스트리 문서](https://docs.microsoft.com/ko-kr/azure/container-registry/container-registry-get-started-azure-cli)에서 찾을 수 있다. 컨테이너 레지스트리를 생성하고 나면, 다음의 자격 증명을 사용하여 로그인한다. @@ -367,4 +374,3 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다. 다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다. Kubelet은 모든`imagePullSecrets` 파일을 하나의 가상`.docker / config.json` 파일로 병합한다. - diff --git a/content/ko/docs/concepts/containers/overview.md b/content/ko/docs/concepts/containers/overview.md index 7ad30f5749..9fc833a4ca 100644 --- a/content/ko/docs/concepts/containers/overview.md +++ b/content/ko/docs/concepts/containers/overview.md @@ -31,7 +31,6 @@ weight: 10 애플리케이션을 변경하려는 경우, 변경사항을 포함하여 만든 새로운 이미지를 통해 컨테이너를 다시 생성해야 한다. - ## 컨테이너 런타임 {{< glossary_definition term_id="container-runtime" length="all" >}} diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index 8af3bda7a8..54500e7ad8 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -1,5 +1,5 @@ --- -title: 런타임 클래스 +title: 런타임클래스(RuntimeClass) content_type: concept weight: 20 --- @@ -8,7 +8,7 @@ weight: 20 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -이 페이지는 런타임 클래스(RuntimeClass) 리소스와 런타임 선택 메커니즘에 대해서 설명한다. +이 페이지는 런타임클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다. 런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임 구성은 파드의 컨테이너를 실행하는데 사용된다. @@ -20,69 +20,69 @@ weight: 20 ## 동기 -서로 다른 파드간에 런타임 클래스를 설정하여 +서로 다른 파드간에 런타임클래스를 설정하여 성능대 보안의 균형을 유지할 수 있다. 예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우, 하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다. 그러면 몇가지 추가적인 오버헤드는 있지만 대체 런타임을 추가 분리하는 유익이 있다. -또한 런타임 클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른 +또한 런타임클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른 여러 파드를 실행할 수 있다. ## 셋업 -RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다. -특징 게이트 활성화에 대한 설명은 [특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 -참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다. +런타임클래스 기능 게이트가 활성화(기본값)된 것을 확인한다. +기능 게이트 활성화에 대한 설명은 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 +참고한다. `RuntimeClass` 기능 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다. 1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서) -2. 상응하는 런타임 클래스 리소스 생성 +2. 상응하는 런타임클래스 리소스 생성 ### 1. CRI 구현을 노드에 설정 -런타임 클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다. +런타임클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다. 사용자의 CRI 구현에 따른 설정 방법은 연관된 문서를 통해서 확인한다([아래](#cri-configuration)). {{< note >}} -런타임 클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정 +런타임클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정 (모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄](#스케줄)을 참고한다. {{< /note >}} -해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다. +해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임클래스에 의해서 참조된다. 런타임 핸들러는 유효한 DNS 1123 서브도메인(알파-숫자 + `-`와 `.`문자)을 가져야 한다. -### 2. 상응하는 런타임 클래스 리소스 생성 +### 2. 상응하는 런타임클래스 리소스 생성 1단계에서 셋업 한 설정은 연관된 `handler` 이름을 가져야 하며, 이를 통해서 설정을 식별할 수 있다. -각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 상응하는 런타임 클래스 오브젝트를 생성한다. +각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 상응하는 런타임클래스 오브젝트를 생성한다. -현재 런타임 클래스 리소스는 런타임 클래스 이름(`metadata.name`)과 런타임 핸들러 +현재 런타임클래스 리소스는 런타임클래스 이름(`metadata.name`)과 런타임 핸들러 (`handler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다. ```yaml -apiVersion: node.k8s.io/v1beta1 # 런타임 클래스는 node.k8s.io API 그룹에 정의되어 있음 +apiVersion: node.k8s.io/v1beta1 # 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음 kind: RuntimeClass metadata: - name: myclass # 런타임 클래스는 해당 이름을 통해서 참조됨 - # 런타임 클래스는 네임스페이스가 없는 리소스임 + name: myclass # 런타임클래스는 해당 이름을 통해서 참조됨 + # 런타임클래스는 네임스페이스가 없는 리소스임 handler: myconfiguration # 상응하는 CRI 설정의 이름임 ``` -런타임 클래스 오브젝트의 이름은 유효한 +런타임클래스 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)어이야 한다. {{< note >}} -런타임 클래스 쓰기 작업(create/update/patch/delete)은 +런타임클래스 쓰기 작업(create/update/patch/delete)은 클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다. 더 자세한 정보는 [권한 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다. {{< /note >}} ## 사용 -클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에 +클러스터를 위해서 런타임클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에 `runtimeClassName`를 명시한다. 예를 들면 다음과 같다. ```yaml @@ -95,14 +95,14 @@ spec: # ... ``` -이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. -만약 지명된 런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 +이것은 Kubelet이 지명된 런타임클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. +만약 지명된 런타임클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 `Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)로 들어간다. 에러 메시지에 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 확인한다. 만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용되며, -런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다. +런타임클래스 기능이 비활성화되었을 때와 동일하게 동작한다. ### CRI 구성 {#cri-configuration} @@ -143,24 +143,26 @@ https://github.com/containerd/cri/blob/master/docs/config.md {{< feature-state for_k8s_version="v1.16" state="beta" >}} -쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터 지원을 포함한다. -이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 노드로 스케줄된다는 것을 보장할 수 있다. -이 스케줄링 기능을 사용하려면, [런타임 클래스 어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본 값)해야 한다. +쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터 +지원을 포함한다. 이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 +노드로 스케줄된다는 것을 보장할 수 있다. 이 스케줄링 기능을 사용하려면, +[런타임 클래스 어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본값)해야 한다. -파드가 지정된 런타임 클래스를 지원하는 노드에 안착한다는 것을 보장하려면, +파드가 지정된 런타임클래스를 지원하는 노드에 안착한다는 것을 보장하려면, 해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다. 런타임 클래스의 nodeSelector는 파드의 nodeSelector와 어드미션 시 병합되어서, 실질적으로 -각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우, 파드는 거부된다. +각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우, +파드는 거부된다. -지원되는 노드가 테인트(taint)되어서 다른 런타임 클래스 파드가 노드에서 구동되는 것을 막고 있다면, -`tolerations`를 런타임 클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시 +지원되는 노드가 테인트(taint)되어서 다른 런타임클래스 파드가 노드에서 구동되는 것을 막고 있다면, +`tolerations`를 런타임클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시 해당 톨러레이션(toleration)이 파드의 톨러레이션과 병합되어, 실질적으로 각각에 의해 선택된 노드의 합집합을 취한다. 노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면 [노드에 파드 할당](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)을 참고한다. -[런타임 클래스 어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass +[런타임클래스 어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass ### 파드 오버헤드 @@ -171,7 +173,6 @@ https://github.com/containerd/cri/blob/master/docs/config.md PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 시켜야 한다. (기본으로 활성화 되어 있다.) - 파드 오버헤드는 런타임 클래스에서 `overhead` 필드를 통해 정의된다. 이 필드를 사용하면, 해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가 쿠버네티스 내에서 처리된다는 것을 보장할 수 있다. @@ -180,8 +181,8 @@ PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/c ## {{% heading "whatsnext" %}} -- [런타임 클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) -- [런타임 클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) +- [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) +- [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) - [파드 오버헤드](/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기 - [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index 3b0b42dfcc..53d925f891 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -35,9 +35,8 @@ extention API server가 레이턴시 요구 사항을 달성할 수 없는 경 ## {{% heading "whatsnext" %}} -* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/). -* 다음에, [extension api-server를 구성해서](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 애그리게이션 레이어와 연계한다. -* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)를 배워본다. +* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/extend-kubernetes/configure-aggregation-layer/). +* 다음에, [확장 API 서버를 구성해서](/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다. +* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다. * [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)의 사양을 읽어본다. - diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 9e9f3e9e29..0d7c08a9a4 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -175,15 +175,15 @@ CRD는 애그리게이트 API보다 생성하기가 쉽다. | 기능 | 설명 | CRD | 애그리게이트 API | | ------- | ----------- | ---- | -------------- | -| 유효성 검사 | 사용자가 오류를 방지하고 클라이언트와 독립적으로 API를 발전시킬 수 있도록 도와준다. 이러한 기능은 동시에 많은 클라이언트를 모두 업데이트할 수 없는 경우에 아주 유용하다. | 예. [OpenAPI v3.0 유효성 검사](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)를 사용하여 CRD에서 대부분의 유효성 검사를 지정할 수 있다. [웹훅 유효성 검사](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)를 추가해서 다른 모든 유효성 검사를 지원한다. | 예, 임의의 유효성 검사를 지원한다. | -| 기본 설정 | 위를 참고하자. | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)의 `default` 키워드(1.17에서 GA) 또는 [웹훅 변형(mutating)](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)(이전 오브젝트의 etcd에서 읽을 때는 실행되지 않음)을 통해 지원한다. | 예 | -| 다중 버전 관리 | 두 가지 API 버전을 통해 동일한 오브젝트를 제공할 수 있다. 필드 이름 바꾸기와 같은 API 변경을 쉽게 할 수 있다. 클라이언트 버전을 제어하는 ​​경우는 덜 중요하다. | [예](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | 예 | +| 유효성 검사 | 사용자가 오류를 방지하고 클라이언트와 독립적으로 API를 발전시킬 수 있도록 도와준다. 이러한 기능은 동시에 많은 클라이언트를 모두 업데이트할 수 없는 경우에 아주 유용하다. | 예. [OpenAPI v3.0 유효성 검사](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation)를 사용하여 CRD에서 대부분의 유효성 검사를 지정할 수 있다. [웹훅 유효성 검사](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)를 추가해서 다른 모든 유효성 검사를 지원한다. | 예, 임의의 유효성 검사를 지원한다. | +| 기본 설정 | 위를 참고하자. | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)의 `default` 키워드(1.17에서 GA) 또는 [웹훅 변형(mutating)](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)(이전 오브젝트의 etcd에서 읽을 때는 실행되지 않음)을 통해 지원한다. | 예 | +| 다중 버전 관리 | 두 가지 API 버전을 통해 동일한 오브젝트를 제공할 수 있다. 필드 이름 바꾸기와 같은 API 변경을 쉽게 할 수 있다. 클라이언트 버전을 제어하는 ​​경우는 덜 중요하다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | 예 | | 사용자 정의 스토리지 | 다른 성능 모드(예를 들어, 키-값 저장소 대신 시계열 데이터베이스)나 보안에 대한 격리(예를 들어, 암호화된 시크릿이나 다른 암호화) 기능을 가진 스토리지가 필요한 경우 | 아니오 | 예 | | 사용자 정의 비즈니스 로직 | 오브젝트를 생성, 읽기, 업데이트 또는 삭제를 할 때 임의의 점검 또는 조치를 수행한다. | 예, [웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용한다. | 예 | -| 서브리소스 크기 조정 | HorizontalPodAutoscaler 및 PodDisruptionBudget과 같은 시스템이 새로운 리소스와 상호 작용할 수 있다. | [예](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | 예 | -| 서브리소스 상태 | 사용자가 스펙 섹션을 작성하고 컨트롤러가 상태 섹션을 작성하는 세분화된 접근 제어를 허용한다. 커스텀 리소스 데이터 변형 시 오브젝트 생성을 증가시킨다(리소스에서 별도의 스펙과 상태 섹션 필요). | [예](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | 예 | +| 서브리소스 크기 조정 | HorizontalPodAutoscaler 및 PodDisruptionBudget과 같은 시스템이 새로운 리소스와 상호 작용할 수 있다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | 예 | +| 서브리소스 상태 | 사용자가 스펙 섹션을 작성하고 컨트롤러가 상태 섹션을 작성하는 세분화된 접근 제어를 허용한다. 커스텀 리소스 데이터 변형 시 오브젝트 생성을 증가시킨다(리소스에서 별도의 스펙과 상태 섹션 필요). | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource) | 예 | | 기타 서브리소스 | "logs" 또는 "exec"과 같은 CRUD 이외의 작업을 추가한다. | 아니오 | 예 | -| strategic-merge-patch | 새로운 엔드포인트는 `Content-Type: application/strategic-merge-patch+json` 형식의 PATCH를 지원한다. 로컬 및 서버 양쪽에서 수정할 수도 있는 오브젝트를 업데이트하는 데 유용하다. 자세한 내용은 ["kubectl 패치를 사용한 API 오브젝트 업데이트"](/docs/tasks/run-application/update-api-object-kubectl-patch/)를 참고한다. | 아니오 | 예 | +| strategic-merge-patch | 새로운 엔드포인트는 `Content-Type: application/strategic-merge-patch+json` 형식의 PATCH를 지원한다. 로컬 및 서버 양쪽에서 수정할 수도 있는 오브젝트를 업데이트하는 데 유용하다. 자세한 내용은 ["kubectl 패치를 사용한 API 오브젝트 업데이트"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)를 참고한다. | 아니오 | 예 | | 프로토콜 버퍼 | 새로운 리소스는 프로토콜 버퍼를 사용하려는 클라이언트를 지원한다. | 아니오 | 예 | | OpenAPI 스키마 | 서버에서 동적으로 가져올 수 있는 타입에 대한 OpenAPI(스웨거(swagger)) 스키마가 있는가? 허용된 필드만 설정하여 맞춤법이 틀린 필드 이름으로부터 사용자를 보호하는가? 타입이 적용되는가(즉, `string` 필드에 `int`를 넣지 않는가?) | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)를 기반으로 하는 스키마(1.16에서 GA) | 예 | @@ -250,6 +250,5 @@ CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부 * [애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)하는 방법에 대해 배우기. -* [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기. - +* [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기. diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index d75601de9f..553ab99cf0 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -158,7 +158,7 @@ kubelet 인스턴스에 자신을 다시 등록할 것으로 기대된다. 현 장치 플러그인에서 제공하는 리소스를 모니터링하려면, 모니터링 에이전트가 노드에서 사용 중인 장치 셋을 검색하고 메트릭과 연관될 컨테이너를 설명하는 메타데이터를 얻을 수 있어야 한다. 장치 모니터링 에이전트에 의해 노출된 -[프로메테우스(Prometheus)](https://prometheus.io/) 지표는 +[프로메테우스](https://prometheus.io/) 지표는 [쿠버네티스 Instrumentation 가이드라인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md)을 따라 `pod`, `namespace` 및 `container` 프로메테우스 레이블을 사용하여 컨테이너를 식별해야 한다. @@ -222,7 +222,7 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi. * [RDMA 장치 플러그인](https://github.com/hustcat/k8s-rdma-device-plugin) * [Solarflare 장치 플러그인](https://github.com/vikaschoudhary16/sfc-device-plugin) * [SR-IOV 네트워크 장치 플러그인](https://github.com/intel/sriov-network-device-plugin) -* Xilinx FPGA 장치용 [Xilinx FPGA 장치 플러그인](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) +* Xilinx FPGA 장치용 [Xilinx FPGA 장치 플러그인](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 3d4a8b8370..8d0efc2212 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -56,6 +56,8 @@ card: ### cloud-controller-manager +{{< glossary_definition term_id="cloud-controller-manager" length="short" >}} + cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다. 자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우 클러스터에는 클라우드 컨트롤러 매니저가 없다. diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index aa5d4a043d..d1d1e3d499 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -9,17 +9,15 @@ card: -전체 API 관례는 [API conventions doc](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)에 기술되어 있다. +쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 핵심은 +{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}이다. API 서버는 +최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할 +수 있도록 HTTP API를 제공한다. -API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/docs/reference)에 기술되어 있다. +쿠버네티스 API를 사용하면 쿠버네티스 API 오브젝트(예: +파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의하고 조작할 수 있다. -API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/reference/access-authn-authz/controlling-access/)에서 논의되었다. - -쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. [kubectl](/ko/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다. - -쿠버네티스는 또한 API 리소스에 대해 직렬화된 상태를 (현재는 [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)에) 저장한다. - -쿠버네티스 자체는 여러 컴포넌트로 나뉘어져서 각각의 API를 통해 상호작용한다. +API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/ko/docs/reference)에 기술되어 있다. @@ -28,54 +26,77 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc ## API 변경 -경험에 따르면, 성공적인 시스템은 새로운 유스케이스의 등장과 기존 유스케이스의 변경에 맞춰 성장하고 변경될 필요가 있다. 그래서, 쿠버네티스 API가 지속적으로 변경되고 성장하기를 바란다. 그러나, 일정 기간 동안은 현재의 클라이언트와의 호환성을 깨지 않으려고 한다. 일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다. 리소스나 필드를 없애는 일은 다음의 [API deprecation policy](/docs/reference/using-api/deprecation-policy/)를 따른다. +새로운 유스케이스가 등장하거나 기존 시스템이 변경됨에 따라 성공적인 시스템은 성장하고 변경될 필요가 있다. +따라서, 쿠버네티스는 쿠버네티스 API를 지속적으로 변경하고 성장시킬 수 있는 디자인 기능을 가지고 있다. +쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 중단하지 _않고_, +다른 프로젝트가 적응할 수 있도록 오랫동안 호환성을 유지하는 것을 목표로 한다. -호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은 [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)에 있다. +일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다. +리소스나 필드를 없애는 일은 다음의 +[API 사용 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따른다. -## OpenAPI 및 Swagger 정의 +호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은 +[API 변경](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)을 참고한다. + +## OpenAPI 명세 {#api-specification} 완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다. -쿠버네티스 1.10부터, OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다. -요청 형식은 HTTP 헤더에 명시해서 설정할 수 있다. +OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다. +다음과 같은 요청 헤더를 사용해서 응답 형식을 요청할 수 있다. -헤더 | 가능한 값 ------- | --------- -Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (기본 content-type은 `*/*`에 대해 `application/json`이거나 이 헤더를 전달하지 않음) -Accept-Encoding | `gzip` (이 헤더를 전달하지 않아도 됨) - -1.14 이전 버전에서 형식이 구분된 엔드포인트(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)는 OpenAPI 스펙을 다른 포맷으로 제공한다. -이러한 엔드포인트는 사용이 중단되었으며, 쿠버네티스 1.14에서 제거되었다. - -**OpenAPI 규격을 조회하는 예제** - -1.10 이전 | 쿠버네티스 1.10 이상 ------------ | ----------------------------- -GET /swagger.json | GET /openapi/v2 **Accept**: application/json -GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf -GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
HeaderPossible valuesNotes
Accept-Encodinggzipnot supplying this header is also acceptable
Acceptapplication/com.github.proto-openapi.spec.v2@v1.0+protobufmainly for intra-cluster use
application/jsondefault
*serves application/json
Valid request header values for OpenAPI v2 queries
쿠버네티스는 주로 클러스터 내부 통신용 API를 위해 대안적인 Protobuf에 기반한 직렬화 형식을 구현한다. 해당 API는 [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 문서와 IDL 파일에 문서화되어 있고 각각의 스키마를 담고 있는 IDL 파일은 API 오브젝트를 정의하는 Go 패키지에 들어있다. -1.14 이전 버전에서 쿠버네티스 apiserver는 `/swaggerapi`에서 [Swagger v1.2](http://swagger.io/) -쿠버네티스 API 스펙을 검색하는데 사용할 수 있는 API도 제공한다. -이러한 엔드포인트는 사용이 중단되었으며, 쿠버네티스 1.14에서 제거되었다. - ## API 버전 규칙 필드를 없애거나 리소스 표현을 재구성하기 쉽도록, 쿠버네티스는 `/api/v1`이나 `/apis/extensions/v1beta1`과 같이 각각 다른 API 경로에서 복수의 API 버전을 지원한다. -리소스나 필드 수준보다는 API 수준에서 버전을 선택했는데, API가 명료하고, 시스템 리소스와 행위 관점에서 일관성있으며, 더 이상 사용되지 않는 API나 실험적인 API에 접근을 제어할 수 있도록 하기 위함이다. 스키마 변경에 대해서 JSON과 Protobuf 직렬화 스키마 모두 동일한 가이드라인을 따른다. 다음에 이어지는 설명 모두는 이 두 가지 형식에 모두 해당한다. +버전 관리는 API가 시스템 리소스와 동작에 대해 명확하고 일관된 보기를 +제공하고 수명 종료(end-of-life)와 실험적인 API에 대한 접근을 제어할 수 있도록 +리소스 또는 필드 수준이 아닌 API 수준에서 수행된다. -API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관되어 있음을 알아두자. -[API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 -API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다. +JSON과 Protobuf 직렬화 스키마는 스키마 변경에 대한 동일한 지침을 따르며 아래의 모든 설명은 두 형식을 모두 포함한다. +참고로 API 버전 관리와 소프트웨어 버전 관리는 간접적으로만 연관이 있다. +[쿠버네티스 릴리스 버전 관리](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) +제안은 API 버전 관리와 소프트웨어 버전 관리 사이의 관계를 설명한다. -API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. -각각의 수준에 대한 조건은 [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 상세히 다룬다. 요약하자면 다음과 같다. +API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. 각각의 수준에 대한 조건은 +[API 변경](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 +상세히 다룬다. 요약하자면 다음과 같다. - 알파(Alpha) 수준: - 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`) @@ -102,32 +123,35 @@ API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르 쿠버네티스 API를 보다 쉽게 확장하기 위해서, [*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)을 구현했다. API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다. -현재 다양한 API 그룹이 사용되고 있다. +클러스터에 다양한 API 그룹이 있다. -1. *핵심* 그룹 또는 *레거시 그룹* 이라고 하는 그룹은 REST 경로 `/api/v1`에서 `apiVersion: v1`을 사용한다. +1. *레거시* 그룹이라고도 하는 *핵심* 그룹은 REST 경로인 `/api/v1/` 에 있고, `apiVersion: v1`을 사용한다. 1. 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다 - (예: `apiVersion: batch/v1`). 지원되는 API 그룹 전체의 목록은 [Kubernetes API reference](/docs/reference/)에서 확인할 수 있다. + (예: `apiVersion: batch/v1`). 사용 가능한 API 그룹의 전체의 목록은 + [쿠버네티스 API 참조](/ko/docs/reference/)에 있다. -[Custom resources](/docs/concepts/api-extension/custom-resources/)로 API를 확장하는 경우에는 두 종류의 경로가 지원된다. +[사용자 지정 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)로 API를 확장하는 두 가지 방법이 있다. -1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)은 아주 기본적인 - CRUD 요구를 갖는 사용자에게 적합하다. -1. 쿠버네티스 API 의미론의 전체 셋을 가지고, 사용자만의 apiserver를 만들고자하는 사용자는 - [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)를 사용해서 클라이언트 입장에서 매끄럽게 동작하도록 - 만들 수 있다. +1. [커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)은 + API 서버가 선택한 리소스 API를 제공하는 방법을 선언적으로 정의할 수 있다. +1. 또한, [자신의 확장 API 서버 구현](/docs/tasks/extend-kubernetes/setup-extension-api-server/)과 + [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)를 + 사용해서 클라이언트를 원활하게 만들 수 있다. ## API 그룹 활성화 또는 비활성화하기 -특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. 이들은 apiserver에서 `--runtime-config`를 설정해서 활성화하거나 -비활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어서 batch/v1을 비활성화 시키려면 -`--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화 시키려면 `--runtime-config=batch/v2alpha1`을 -설정한다. 이 플래그는 apiserver의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다. +특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. kube-apiserver에서 커맨드 라인 옵션으로 `--runtime-config` 를 +설정해서 활성화하거나 비활성화할 수 있다. -{{< note >}}그룹이나 리소스를 활성화 또는 비활성화 시키기 위해서는 apiserver와 controller-manager를 재시작해서 -`--runtime-config` 변경을 반영시켜야 한다. {{< /note >}} +`--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어서 batch/v1을 비활성화시키려면, +`--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화시키려면, `--runtime-config=batch/v2alpha1`을 +설정한다. 이 플래그는 API 서버의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다. + +{{< note >}}그룹이나 리소스를 활성화 또는 비활성화하려면 kube-apiserver와 +controller-manager를 재시작해서 `--runtime-config` 변경 사항을 반영해야 한다. {{< /note >}} ## extensions/v1beta1 그룹 내 특정 리소스 활성화하기 @@ -137,4 +161,19 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명 {{< note >}}개별 리소스의 활성화/비활성화는 레거시 문제로 `extensions/v1beta1` API 그룹에서만 지원된다. {{< /note >}} +## 지속성 +쿠버네티스는 API 리소스에 대한 직렬화된 상태를 {{< glossary_tooltip term_id="etcd" >}}에 +기록하고 저장한다. + + +## {{% heading "whatsnext" %}} + +[API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)는 클러스터가 +API 접근에 대한 인증과 권한을 관리하는 방법을 설명한다. + +전체 API 규약은 +[API 규약](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions) +문서에 설명되어 있다. + +API 엔드포인트, 리소스 타입과 샘플은 [API 참조](/docs/reference/kubernetes-api/)에 설명되어 있다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md index be7db19bb5..c9125cbe3d 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md @@ -8,7 +8,8 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝 공통 레이블 셋은 모든 도구들이 이해할 수 있는 공통의 방식으로 오브젝트를 식별하고 도구들이 상호 운용적으로 작동할 수 있도록 한다. -권장 레이블은 지원 도구 외에도 쿼리하는 방식으로 애플리케이션을 식별하게 한다. +권장 레이블은 지원 도구 외에도 쿼리하는 방식으로 +애플리케이션을 식별하게 한다. @@ -18,17 +19,18 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝 애플리케이션에 포함된 정의는 유연하다. {{< note >}} -메타데이터들은 권장하는 레이블이다. 애플리케이션을 보다 쉽게 관리할 수 있지만 코어 도구에는 필요하지 않다. +메타데이터들은 권장하는 레이블이다. 애플리케이션을 보다 쉽게 관리할 수 있지만 +코어 도구에는 필요하지 않다. {{< /note >}} 공유 레이블과 주석에는 공통 접두사인 `app.kubernetes.io` 가 있다. 접두사가 없는 레이블은 사용자가 개인적으로 사용할 수 있다. 공유 접두사는 공유 레이블이 사용자 정의 레이블을 방해하지 않도록 한다. - ## 레이블 -레이블을 최대한 활용하려면 모든 리소스 오브젝트에 적용해야 한다. +레이블을 최대한 활용하려면 모든 리소스 오브젝트에 +적용해야 한다. | Key | Description | Example | Type | | ----------------------------------- | --------------------- | -------- | ---- | @@ -56,8 +58,9 @@ metadata: ## 애플리케이션과 애플리케이션 인스턴스 -애플리케이션은 때에 따라 쿠버네티스 클러스터의 동일한 네임스페이스에 한번 또는 그 이상 설치할 수 있다. -예를 들어 워드프레스는 다른 워드프레스가 설치되어있는 웹사이트에 한번 한번 또는 그 이상 설치할 수 있다. +애플리케이션은 때에 따라 쿠버네티스 클러스터의 동일한 네임스페이스에 +한번 또는 그 이상 설치할 수 있다. 예를 들어 워드프레스는 다른 워드프레스가 +설치되어있는 웹사이트에 한번 한번 또는 그 이상 설치할 수 있다. 애플리케이션의 이름과 인스턴스 이름은 별도로 기록된다. 예를 들어 워드프레스는 `app.kubernetes.io/name` 에 `wordpress` 를 가지며 인스턴스 이름으로는 @@ -97,7 +100,8 @@ metadata: ### 데이터베이스가 있는 웹 애플리케이션 -Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을 설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다. +Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을 +설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다. 다음 식별자는 이 애플리케이션을 배포하는데 사용하는 오브젝트의 시작을 보여준다. WordPress를 배포하는데 다음과 같이 `Deployment` 로 시작한다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md index 06326befa8..9a343ca5c5 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md @@ -16,12 +16,7 @@ kubectl get pods --field-selector status.phase=Running ``` {{< note >}} -필드 셀렉터는 본질적으로 리소스 *필터* 이다. 기본적으로 적용되는 셀렉터나 필드는 없으며, 이는 명시된 종류의 모든 리소스가 선택된다는 것을 의미한다. 따라서 다음의 `kubectl` 쿼리들은 동일하다. - -```shell -kubectl get pods -kubectl get pods --field-selector "" -``` +필드 셀렉터는 본질적으로 리소스 *필터* 이다. 기본적으로 적용되는 셀렉터나 필드는 없으며, 이는 명시된 종류의 모든 리소스가 선택된다는 것을 의미한다. 여기에 따라오는 `kubectl` 쿼리인 `kubectl get pods` 와 `kubectl get pods --field-selector ""` 는 동일하다. {{< /note >}} ## 사용 가능한 필드 @@ -53,7 +48,7 @@ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Alway ## 여러 개의 리소스 종류 -필드 셀렉터를 여러 개의 리소스 종류에 걸쳐 사용할 수 있다. 다음의 `kubectl` 커맨드는 `default` 네임스페이스에 속해있지 않은 모든 스테이트풀 셋과 서비스를 선택한다. +필드 셀렉터를 여러 개의 리소스 종류에 걸쳐 사용할 수 있다. 다음의 `kubectl` 커맨드는 `default` 네임스페이스에 속해있지 않은 모든 스테이트풀셋(StatefulSet)과 서비스를 선택한다. ```shell kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default diff --git a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 1fe7183c29..73fa4ff4d0 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -44,7 +44,8 @@ spec에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어 spec에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 -어떤 문제로 인해 멈춘다면(상태 변화 발생), 쿠버네티스 시스템은 보정(이 경우에는 대체 인스턴스를 시작하여)을 통해 +어떤 문제로 인해 멈춘다면(상태 변화 발생), 쿠버네티스 시스템은 보정(이 +경우에는 대체 인스턴스를 시작하여)을 통해 spec과 status간의 차이에 대응한다. 오브젝트 명세, 상태, 그리고 메타데이터에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다. @@ -91,6 +92,5 @@ deployment.apps/nginx-deployment created ## {{% heading "whatsnext" %}} * API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다. -* [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. +* [파드](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다. - diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index fe8b0ce8fb..e06daff929 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -83,7 +83,8 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의 레이블 셀렉터는 쉼표로 구분된 다양한 _요구사항_ 에 따라 만들 수 있다. 다양한 요구사항이 있는 경우 쉼표 기호가 AND(`&&`) 연산자로 구분되는 역할을 하도록 해야 한다. 비어있거나 지정되지 않은 셀렉터는 상황에 따라 달라진다. -셀렉터를 사용하는 API 유형은 유효성과 의미를 문서화해야 한다. +셀렉터를 사용하는 API 유형은 유효성과 의미를 +문서화해야 한다. {{< note >}} 레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/names.md b/content/ko/docs/concepts/overview/working-with-objects/names.md index 0cb3e7656a..891ad4d07a 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/names.md +++ b/content/ko/docs/concepts/overview/working-with-objects/names.md @@ -15,7 +15,6 @@ weight: 20 - ## 이름 {#names} diff --git a/content/ko/docs/concepts/overview/working-with-objects/object-management.md b/content/ko/docs/concepts/overview/working-with-objects/object-management.md index 550cbe951c..9b59aae529 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/ko/docs/concepts/overview/working-with-objects/object-management.md @@ -127,7 +127,6 @@ kubectl replace -f nginx.yaml - 명령형 오브젝트 구성은 디렉토리가 아닌, 파일에 대해 가장 효과가 있다. - 활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다. - ## 선언형 오브젝트 구성 선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트 @@ -178,6 +177,7 @@ kubectl apply -R -f configs/ ## {{% heading "whatsnext" %}} + - [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/) - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/) - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) @@ -186,6 +186,4 @@ kubectl apply -R -f configs/ - [Kubectl 서적](https://kubectl.docs.kubernetes.io) - [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) -{{< comment >}} -{{< /comment >}} diff --git a/content/ko/docs/concepts/policy/limit-range.md b/content/ko/docs/concepts/policy/limit-range.md index e2bd0a10d3..ee30ec6437 100644 --- a/content/ko/docs/concepts/policy/limit-range.md +++ b/content/ko/docs/concepts/policy/limit-range.md @@ -24,11 +24,13 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. ## 리밋레인지 활성화 -많은 쿠버네티스 배포판에 리밋레인지 지원이 기본적으로 활성화되어 있다. apiserver `--enable-admission-plugins=` 플래그의 인수 중 하나로 `LimitRanger` 어드미션 컨트롤러가 있는 경우 활성화된다. +쿠버네티스 1.10 버전부터 리밋레인지 지원이 기본적으로 활성화되었다. -해당 네임스페이스에 리밋레인지 오브젝트가 있는 경우 특정 네임스페이스에 리밋레인지가 지정된다. +해당 네임스페이스에 리밋레인지 오브젝트가 있는 경우 +특정 네임스페이스에 리밋레인지가 지정된다. -리밋레인지 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야한다. +리밋레인지 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. ### 리밋 레인지 개요 @@ -36,7 +38,8 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. - 사용자는 네임스페이스에서 파드, 컨테이너 및 퍼시스턴트볼륨클레임과 같은 리소스를 생성한다. - `LimitRanger` 어드미션 컨트롤러는 컴퓨팅 리소스 요청 사항을 설정하지 않은 모든 파드와 컨테이너에 대한 기본값과 제한을 지정하고 네임스페이스의 리밋레인지에 정의된 리소스의 최소, 최대 및 비율을 초과하지 않도록 사용량을 추적한다. - 리밋레인지 제약 조건을 위반하는 리소스(파드, 컨테이너, 퍼시스턴트볼륨클레임)를 생성하거나 업데이트하는 경우 HTTP 상태 코드 `403 FORBIDDEN` 및 위반된 제약 조건을 설명하는 메시지와 함께 API 서버에 대한 요청이 실패한다. -- `cpu`, `memory`와 같은 컴퓨팅 리소스의 네임스페이스에서 리밋레인지가 활성화된 경우 사용자는 해당 값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 시스템에서 파드 생성이 거부될 수 있다. +- `cpu`, `memory`와 같은 컴퓨팅 리소스의 네임스페이스에서 리밋레인지가 활성화된 경우 사용자는 해당 값에 + 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 시스템에서 파드 생성이 거부될 수 있다. - 리밋레인지 유효성 검사는 파드 실행 단계가 아닌 파드 어드미션 단계에서만 발생한다. 리밋 레인지를 사용하여 생성할 수 있는 정책의 예는 다음과 같다. @@ -66,4 +69,3 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. - [네임스페이스당 할당량을 설정하는 자세한 예시](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/). - diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index 57a115fc69..de6ab7a25d 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -31,7 +31,7 @@ _Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 | 호스트 네트워킹과 포트의 사용 | [`hostNetwork`, `hostPorts`](#호스트-네임스페이스) | | 볼륨 유형의 사용 | [`volumes`](#볼륨-및-파일시스템) | | 호스트 파일시스템의 사용 | [`allowedHostPaths`](#볼륨-및-파일시스템) | -| FlexVolume 드라이버의 화이트리스트 | [`allowedFlexVolumes`](#flexvolume-드라이버) | +| 특정 FlexVolume 드라이버의 허용 | [`allowedFlexVolumes`](#flexvolume-드라이버) | | 파드 볼륨을 소유한 FSGroup 할당 | [`fsGroup`](#볼륨-및-파일시스템) | | 읽기 전용 루트 파일시스템 사용 필요 | [`readOnlyRootFilesystem`](#볼륨-및-파일시스템) | | 컨테이너의 사용자 및 그룹 ID | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#사용자-및-그룹) | @@ -398,13 +398,13 @@ podsecuritypolicy "example" deleted 동일한 노드에 있는 다른 파드의 네트워크 활동을 스누핑(snoop)하는 데 사용할 수 있다. -**HostPorts** - 호스트 네트워크 네임스페이스에 허용되는 포트 범위의 화이트리스트(whitelist)를 +**HostPorts** - 호스트 네트워크 네임스페이스에 허용되는 포트 범위의 목록을 제공한다. `min`과 `max`를 포함하여 `HostPortRange`의 목록으로 정의된다. 기본값은 허용하는 호스트 포트 없음(no allowed host ports)이다. ### 볼륨 및 파일시스템 -**Volumes** - 허용되는 볼륨 유형의 화이트리스트를 제공한다. 허용 가능한 값은 +**Volumes** - 허용되는 볼륨 유형의 목록을 제공한다. 허용 가능한 값은 볼륨을 생성할 때 정의된 볼륨 소스에 따른다. 볼륨 유형의 전체 목록은 [볼륨 유형들](/ko/docs/concepts/storage/volumes/#볼륨-유형들)에서 참고한다. 또한 `*`를 사용하여 모든 볼륨 유형을 @@ -435,7 +435,7 @@ podsecuritypolicy "example" deleted 유효성을 검사한다. - *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `fsGroup` ID의 지정도 허용한다. -**AllowedHostPaths** - hostPath 볼륨에서 사용할 수 있는 호스트 경로의 화이트리스트를 +**AllowedHostPaths** - hostPath 볼륨에서 사용할 수 있는 호스트 경로의 목록을 지정한다. 빈 목록은 사용되는 호스트 경로에 제한이 없음을 의미한다. 이는 단일 `pathPrefix` 필드가 있는 오브젝트 목록으로 정의되며, hostPath 볼륨은 허용된 접두사로 시작하는 경로를 마운트할 수 있으며 `readOnly` 필드는 @@ -466,7 +466,7 @@ allowedHostPaths: ### FlexVolume 드라이버 -flexvolume에서 사용할 수 있는 FlexVolume 드라이버의 화이트리스트를 지정한다. +flexvolume에서 사용할 수 있는 FlexVolume 드라이버의 목록을 지정한다. 빈 목록 또는 nil은 드라이버에 제한이 없음을 의미한다. [`volumes`](#볼륨-및-파일시스템) 필드에 `flexVolume` 볼륨 유형이 포함되어 있는지 확인한다. 그렇지 않으면 FlexVolume 드라이버가 허용되지 않는다. @@ -552,7 +552,7 @@ spec: 다음 필드는 대문자로 표기된 기능 이름 목록을 `CAP_` 접두사 없이 가져온다. -**AllowedCapabilities** - 컨테이너에 추가될 수 있는 기능의 화이트리스트를 +**AllowedCapabilities** - 컨테이너에 추가될 수 있는 기능의 목록을 제공한다. 기본적인 기능 셋은 암시적으로 허용된다. 비어있는 셋은 기본 셋을 넘어서는 추가 기능이 추가되지 않는 것을 의미한다. `*`는 모든 기능을 허용하는 데 사용할 수 있다. @@ -576,7 +576,7 @@ spec: ### AllowedProcMountTypes -`allowedProcMountTypes`는 허용된 ProcMountTypes의 화이트리스트이다. +`allowedProcMountTypes`는 허용된 ProcMountTypes의 목록이다. 비어 있거나 nil은 `DefaultProcMountType`만 사용할 수 있음을 나타낸다. `DefaultProcMount`는 /proc의 읽기 전용 및 마스킹(masking)된 경로에 컨테이너 런타임 @@ -637,4 +637,3 @@ spec: API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다. - diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index 4aec897572..7c7a6f64a8 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -56,7 +56,8 @@ weight: 10 API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로 `ResourceQuota`가 있는 경우 활성화된다. -해당 네임스페이스에 `ResourceQuota`가 있는 경우 특정 네임스페이스에 리소스 쿼터가 적용된다. +해당 네임스페이스에 `ResourceQuota`가 있는 경우 특정 네임스페이스에 +리소스 쿼터가 적용된다. ## 컴퓨트 리소스 쿼터 @@ -160,9 +161,10 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. | `services.nodeports` | 네임스페이스에 존재할 수 있는 노드 포트 유형의 총 서비스 수 | | `secrets` | 네임스페이스에 존재할 수 있는 총 시크릿 수 | -예를 들어, `pods` 쿼터는 터미널이 아닌 단일 네임스페이스에서 생성된 `pods` 수를 계산하고 최대값을 적용한다. -사용자가 작은 파드를 많이 생성하여 클러스터의 파드 IP 공급이 고갈되는 경우를 피하기 위해 -네임스페이스에 `pods` 쿼터를 설정할 수 있다. +예를 들어, `pods` 쿼터는 터미널이 아닌 단일 네임스페이스에서 생성된 `pods` 수를 +계산하고 최댓값을 적용한다. 사용자가 작은 파드를 많이 생성하여 클러스터의 파드 IP +공급이 고갈되는 경우를 피하기 위해 네임스페이스에 +`pods` 쿼터를 설정할 수 있다. ## 쿼터 범위 @@ -599,4 +601,3 @@ plugins: 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고하길 바란다. - diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index a56dece692..4694533315 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -151,7 +151,7 @@ spec: 예시에서 연산자 `In` 이 사용되고 있는 것을 볼 수 있다. 새로운 노드 어피니티 구문은 다음의 연산자들을 지원한다. `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. `NotIn` 과 `DoesNotExist` 를 사용해서 안티-어피니티를 수행하거나, -특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/docs/concepts/configuration/taint-and-toleration/)를 설정할 수 있다. +특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 설정할 수 있다. `nodeSelector` 와 `nodeAffinity` 를 모두 지정한다면 파드가 후보 노드에 스케줄 되기 위해서는 *둘 다* 반드시 만족해야 한다. @@ -206,13 +206,11 @@ spec: `preferredDuringSchedulingIgnoredDuringExecution` 이다. 파드 어피니티 규칙에 의하면 키 "security" 와 값 "S1"인 레이블이 있는 하나 이상의 이미 실행 중인 파드와 동일한 영역에 있는 경우에만 파드를 노드에 스케줄할 수 있다. (보다 정확하게는, 클러스터에 키 "security"와 값 "S1"인 레이블을 가지고 있는 실행 중인 파드가 있는 키 -`failure-domain.beta.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고, 노드 N이 키 -`failure-domain.beta.kubernetes.io/zone` 와 일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.) -파드 안티-어피니티 규칙에 의하면 노드가 이미 키 "security"와 값 "S2"인 레이블을 가진 파드를 -실행하고 있는 파드는 노드에 스케줄되는 것을 선호하지 않는다. -(만약 `topologyKey` 가 `failure-domain.beta.kubernetes.io/zone` 라면 노드가 키 -"security"와 값 "S2"를 레이블로 가진 파드와 -동일한 영역에 있는 경우, 노드에 파드를 예약할 수 없음을 의미한다.) +`failure-domain.beta.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고, +노드 N이 키 `failure-domain.beta.kubernetes.io/zone` 와 +일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.) +파드 안티-어피니티 규칙에 의하면 파드는 키 "security"와 값 "S2"인 레이블을 가진 파드와 +동일한 영역의 노드에 스케줄되지 않는다. [디자인 문서](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)를 통해 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 의 파드 어피니티와 안티-어피니티에 대한 많은 예시를 맛볼 수 있다. @@ -222,10 +220,11 @@ spec: 원칙적으로, `topologyKey` 는 적법한 어느 레이블-키도 될 수 있다. 하지만, 성능과 보안상의 이유로 topologyKey에는 몇 가지 제약조건이 있다. -1. 어피니티와 `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 대해 -`topologyKey` 가 비어있는 것을 허용하지 않는다. -2. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를에 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 간단히 이를 비활성화 할 수 있다. -3. `preferredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 `topologyKey` 가 비어있는 것을 허용하지 않는다. +1. 파드 어피니티에서 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는 +`topologyKey` 의 빈 값을 허용하지 않는다. +2. 파드 안티-어피니티에서도 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는 +`topologyKey` 의 빈 값을 허용하지 않는다. +3. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 아니면 간단히 이를 비활성화해야 한다. 4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다. `labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를 @@ -388,7 +387,7 @@ spec: ## {{% heading "whatsnext" %}} -[테인트](/docs/concepts/configuration/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아내게* 할 수 있다. +[테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아낼* 수 있다. [노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)와 [파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서에는 @@ -397,5 +396,3 @@ spec: 파드가 노드에 할당되면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다. [토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는 노드 수준의 리소스 할당 결정에 참여할 수 있다. - - diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 54373e2e2c..576d966a9b 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -89,10 +89,10 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 ## {{% heading "whatsnext" %}} -* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling/scheduler-perf-tuning/)에 대해 읽기 +* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기 * [멀티 스케줄러 구성하기](/docs/tasks/administer-cluster/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 -* [파드 오버헤드](/docs/concepts/configuration/pod-overhead/)에 대해 배우기 +* [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/)에 대해 배우기 diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 52db313635..b564eda5fb 100644 --- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -8,8 +8,8 @@ weight: 70 {{< feature-state for_k8s_version="1.14" state="beta" >}} -[kube-scheduler](/ko/docs/concepts/scheduling/kube-scheduler/#kube-scheduler) -는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의 +[kube-scheduler](/ko/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler)는 +쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의 노드에 파드를 배치하는 역할을 한다. 파드의 스케줄링 요건을 충족하는 @@ -19,7 +19,7 @@ weight: 70 높은 점수를 가진 노드를 선택한다. 이후 스케줄러는 _바인딩_ 이라는 프로세스로 API 서버에 해당 결정을 통지한다. -본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝 +본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝 최적화에 대해 설명한다. @@ -45,7 +45,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해 값을 변경하려면, kube-scheduler 구성 파일(이 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 일 수 있다)을 편집한 다음 스케줄러를 재시작 한다. -이를 변경한 후에 다음을 실행해서 +이를 변경한 후에 다음을 실행해서 ```bash kubectl get componentstatuses ``` @@ -68,7 +68,7 @@ scheduler Healthy ok 정수 값(숫자)로 변환 한다. 스케줄링 중에 kube-scheduler가 구성된 비율을 초과 할만큼 충분히 실행 가능한 노드를 식별한 경우, kube-scheduler는 더 실행 가능한 노드를 찾는 검색을 중지하고 -[스코어링 단계](/ko/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation)를 진행한다. +[스코어링 단계](/ko/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)를 진행한다. [스케줄러가 노드 탐색을 반복(iterate)하는 방법](#스케줄러가-노드-탐색을-반복-iterate-하는-방법) 은 이 프로세스를 자세히 설명한다. @@ -101,14 +101,15 @@ algorithmSource: percentageOfNodesToScore: 50 ``` + ### percentageOfNodesToScore 튜닝 -`percentageOfNodesToScore`는 1과 100 사이의 값이어야하며 -기본 값은 클러스터 크기에 따라 계산된다. 또한 50 노드로 하드 코딩된 -최소 값도 있다. +`percentageOfNodesToScore`는 1과 100 사이의 값이어야 하며 +기본값은 클러스터 크기에 따라 계산된다. 또한 50 노드로 하드 코딩된 +최솟값도 있다. -{{< note >}} 클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히 -모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한 +{{< note >}} 클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히 +모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한 노드의 수가 충분하지 않기 때문이다. 규모가 작은 클러스터에서는 `percentageOfNodesToScore` 에 낮은 값을 설정하면, @@ -119,10 +120,10 @@ percentageOfNodesToScore: 50 성능이 크게 향상되지 않는다. {{< /note >}} -이 값을 세팅할 때 중요하고 자세한 사항은, 클러스터에서 +이 값을 세팅할 때 중요하고 자세한 사항은, 클러스터에서 적은 수의 노드에 대해서만 적합성을 확인하면, 주어진 파드에 대해서 -일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데 -가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지 +일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데 +가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지 않을 수 있다. 이것은 파드의 이상적인 배치보다 낮은 결과를 초래할 것이다. `percentageOfNodesToScore` 를 매우 낮게 설정해서 kube-scheduler가 @@ -133,19 +134,19 @@ percentageOfNodesToScore: 50 ## 스케줄러가 노드 탐색을 반복(iterate)하는 방법 -이 섹션은 이 특징의 상세한 내부 방식을 이해하고 싶은 사람들을 +이 섹션은 이 특징의 상세한 내부 방식을 이해하고 싶은 사람들을 위해 작성되었다. -클러스터의 모든 노드가 파드 실행 대상으로 고려되어 공정한 기회를 +클러스터의 모든 노드가 파드 실행 대상으로 고려되어 공정한 기회를 가지도록, 스케줄러는 라운드 로빈(round robin) 방식으로 모든 노드에 대해서 탐색을 -반복한다. 모든 노드가 배열에 나열되어 있다고 생각해보자. 스케줄러는 배열의 -시작부터 시작하여 `percentageOfNodesToScore`에 명시된 충분한 수의 노드를 -찾을 때까지 적합성을 확인한다. 그 다음 파드에 대해서는, 스케줄러가 -이전 파드를 위한 노드 적합성 확인이 마무리된 지점인 노드 배열의 마지막 +반복한다. 모든 노드가 배열에 나열되어 있다고 생각해보자. 스케줄러는 배열의 +시작부터 시작하여 `percentageOfNodesToScore`에 명시된 충분한 수의 노드를 +찾을 때까지 적합성을 확인한다. 그 다음 파드에 대해서는, 스케줄러가 +이전 파드를 위한 노드 적합성 확인이 마무리된 지점인 노드 배열의 마지막 포인트부터 확인을 재개한다. -만약 노드들이 다중의 영역(zone)에 있다면, 다른 영역에 있는 노드들이 적합성 -확인의 대상이 되도록 스케줄러는 다양한 영역에 있는 노드에 대해서 +만약 노드들이 다중의 영역(zone)에 있다면, 다른 영역에 있는 노드들이 적합성 +확인의 대상이 되도록 스케줄러는 다양한 영역에 있는 노드에 대해서 탐색을 반복한다. 예제로, 2개의 영역에 있는 6개의 노드를 생각해보자. ``` @@ -160,5 +161,3 @@ percentageOfNodesToScore: 50 ``` 모든 노드를 검토한 후, 노드 1로 돌아간다. - - diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md index 0d0a192ddd..2100a6de10 100644 --- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -6,16 +6,17 @@ weight: 40 -[여기](/ko/docs/concepts/configuration/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)에 설명된 노드 어피니티는 -노드 셋을 *끌어들이는* (기본 설정 또는 어려운 요구 사항) -*파드* 속성이다. 테인트는 그 반대로, *노드* 가 파드 셋을 -*제외* 할 수 있다. +[_노드 어피니티_](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)는 +{{< glossary_tooltip text="노드" term_id="node" >}} 셋을 +(기본 설정 또는 어려운 요구 사항으로) *끌어들이는* {{< glossary_tooltip text="파드" term_id="pod" >}}의 속성이다. +_테인트_ 는 그 반대로, 노드가 파드 셋을 제외할 수 있다. + +_톨러레이션_ 은 파드에 적용되며, 파드를 일치하는 테인트가 있는 노드에 +스케줄되게 하지만 필수는 아니다. 테인트와 톨러레이션은 함께 작동하여 파드가 부적절한 노드에 스케줄되지 않게 한다. 하나 이상의 테인트가 노드에 적용된다. 이것은 노드가 테인트를 용인하지 않는 파드를 수용해서는 안 되는 것을 나타낸다. -톨러레이션은 파드에 적용되며, 파드를 일치하는 테인트가 있는 노드에 스케줄되게 -하지만 필수는 아니다. @@ -61,13 +62,13 @@ tolerations: {{< codenew file="pods/pod-with-toleration.yaml" >}} +지정하지 않으면 `operator` 의 기본값은 `Equal` 이다. + 톨러레이션은 키가 동일하고 이펙트가 동일한 경우, 테인트와 "일치"한다. 그리고 다음의 경우에도 마찬가지다. * `operator` 가 `Exists` 인 경우(이 경우 `value` 를 지정하지 않아야 함), 또는 * `operator` 는 `Equal` 이고 `value` 는 `value` 로 같다. -지정하지 않으면 `operator` 의 기본값은 `Equal` 이다. - {{< note >}} 두 가지 특별한 경우가 있다. @@ -198,8 +199,7 @@ tolerations: * `tolerationSeconds` 가 지정된 테인트를 용인하는 파드는 지정된 시간 동안 바인딩된 상태로 유지된다. -덧붙여, 쿠버네티스 1.6 버전에서는 노드 문제를 나타내는 알파 지원이 -도입되었다. 다시 말해, 특정 조건이 참일 때 노드 컨트롤러는 자동으로 +노드 컨트롤러는 특정 조건이 참일 때 자동으로 노드를 테인트시킨다. 다음은 빌트인 테인트이다. * `node.kubernetes.io/not-ready`: 노드가 준비되지 않았다. 이는 NodeCondition @@ -221,10 +221,9 @@ tolerations: 관련 테인트를 제거할 수 있다. {{< note >}} -노드 문제로 인해 파드 축출의 기존 [비율 제한](/ko/docs/concepts/architecture/nodes/) -동작을 유지하기 위해, 시스템은 실제로 테인트를 비율-제한 방식으로 -추가한다. 이는 마스터가 노드에서 분할되는 등의 시나리오에서 -대규모 파드 축출을 방지한다. +콘트롤 플레인은 노드에 새 테인트를 추가하는 비율을 제한한다. +이 비율-제한은 많은 노드가 동시에 도달할 수 없을 때(예를 들어, 네트워크 중단으로) +트리거될 축출 개수를 관리한다. {{< /note >}} 이 기능을 `tolerationSeconds` 와 함께 사용하면, 파드에서 @@ -243,20 +242,15 @@ tolerations: tolerationSeconds: 6000 ``` -쿠버네티스는 사용자가 제공한 파드 구성에 이미 추가된 -`node.kubernetes.io/not-ready` 에 대한 톨러레이션이 없는 경우 -`tolerationSeconds=300` 으로 `node.kubernetes.io/not-ready` 에 대한 -톨러레이션을 자동으로 추가한다. -마찬가지로 사용자가 제공한 파드 구성에 이미 추가된 -`node.kubernetes.io/unreachable` 에 대한 톨러레이션이 없는 경우 -`tolerationSeconds=300` 으로 `node.kubernetes.io/unreachable` 에 대한 +{{< note >}} +쿠버네티스는 사용자나 컨트롤러에서 명시적으로 설정하지 않았다면, 자동으로 +`node.kubernetes.io/not-ready` 와 `node.kubernetes.io/unreachable` 에 대해 +`tolerationSeconds=300` 으로 톨러레이션을 추가한다. -자동으로 추가된 이 톨러레이션은 이러한 문제 중 하나가 -감지된 후 5분 동안 바인딩 상태로 남아있는 기본 파드 -동작이 유지되도록 한다. -[DefaultTolerationSecondsadmission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds) -어드미션 컨트롤러에 의해 두 개의 기본 톨러레이션이 추가된다. +자동으로 추가된 이 톨러레이션은 이러한 문제 중 하나가 감지된 후 5분 동안 +파드가 노드에 바인딩된 상태를 유지함을 의미한다. +{{< /note >}} [데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/) 파드는 `tolerationSeconds` 가 없는 다음 테인트에 대해 `NoExecute` 톨러레이션를 가지고 생성된다. @@ -273,8 +267,7 @@ tolerations: 마찬가지로 스케줄러는 노드 컨디션을 확인하지 않는다. 대신 스케줄러는 테인트를 확인한다. 이렇게 하면 노드 컨디션이 노드에 스케줄된 내용에 영향을 미치지 않는다. 사용자는 적절한 파드 톨러레이션을 추가하여 노드의 일부 문제(노드 컨디션으로 표시)를 무시하도록 선택할 수 있다. 쿠버네티스 1.8 버전부터 데몬셋 컨트롤러는 다음의 `NoSchedule` 톨러레이션을 -모든 데몬에 자동으로 추가하여, 데몬셋이 중단되는 것을 -방지한다. +모든 데몬에 자동으로 추가하여, 데몬셋이 중단되는 것을 방지한다. * `node.kubernetes.io/memory-pressure` * `node.kubernetes.io/disk-pressure` @@ -284,3 +277,9 @@ tolerations: 이러한 톨러레이션을 추가하면 이전 버전과의 호환성이 보장된다. 데몬셋에 임의의 톨러레이션을 추가할 수도 있다. + + +## {{% heading "whatsnext" %}} + +* [리소스 부족 다루기](/docs/tasks/administer-cluster/out-of-resource/)와 어떻게 구성하는지에 대해 알아보기 +* [파드 우선순위](/ko/docs/concepts/configuration/pod-priority-preemption/)에 대해 알아보기 diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index f988d1d5d9..b64f946acc 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -7,13 +7,13 @@ weight: 1 {{< toc >}} -쿠버네티스 보안(일반적인 보안)은 관련된 많은 부분이 상호작용하는 -방대한 주제다. 오늘날에는 웹 애플리케이션의 실행을 돕는 -수많은 시스템에 오픈소스 소프트웨어가 통합되어 있으며, -전체적인 보안에 대하여 생각할 수 있는 방법에 대한 통찰력을 도울 수 있는 -몇 가지 중요한 개념이 있다. 이 가이드는 클라우드 네이티브 보안과 관련된 -몇 가지 일반적인 개념에 대한 멘탈 모델(mental model)을 정의한다. 멘탈 모델은 완전히 임의적이며 -소프트웨어 스택을 보호할 위치를 생각하는데 도움이되는 경우에만 사용해야 +쿠버네티스 보안(일반적인 보안)은 관련된 많은 부분이 상호작용하는 +방대한 주제다. 오늘날에는 웹 애플리케이션의 실행을 돕는 +수많은 시스템에 오픈소스 소프트웨어가 통합되어 있으며, +전체적인 보안에 대하여 생각할 수 있는 방법에 대한 통찰력을 도울 수 있는 +몇 가지 중요한 개념이 있다. 이 가이드는 클라우드 네이티브 보안과 관련된 +몇 가지 일반적인 개념에 대한 멘탈 모델(mental model)을 정의한다. 멘탈 모델은 완전히 임의적이며 +소프트웨어 스택을 보호할 위치를 생각하는데 도움이되는 경우에만 사용해야 한다. @@ -22,8 +22,8 @@ weight: 1 ## 클라우드 네이티브 보안의 4C 계층적인 보안에 대해서 어떻게 생각할 수 있는지 이해하는 데 도움이 될 수 있는 다이어그램부터 살펴보자. {{< note >}} -이 계층화된 접근 방식은 보안에 대한 [심층 방어](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) -접근 방식을 강화하며, 소프트웨어 시스템의 보안을 위한 모범 사례로 +이 계층화된 접근 방식은 보안에 대한 [심층 방어](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) +접근 방식을 강화하며, 소프트웨어 시스템의 보안을 위한 모범 사례로 널리 알려져 있다. 4C는 클라우드(Cloud), 클러스터(Clusters), 컨테이너(Containers) 및 코드(Code)이다. {{< /note >}} @@ -31,23 +31,23 @@ weight: 1 위 그림에서 볼 수 있듯이, -4C는 각각의 사각형의 보안에 따라 다르다. 코드 -수준의 보안만 처리하여 클라우드, 컨테이너 및 코드의 열악한 보안 표준으로부터 -보호하는 것은 거의 불가능하다. 그러나 이런 영역들의 보안이 적절하게 -처리되고, 코드에 보안을 추가한다면 이미 강력한 기반이 더욱 +4C는 각각의 사각형의 보안에 따라 다르다. 코드 +수준의 보안만 처리하여 클라우드, 컨테이너 및 코드의 열악한 보안 표준으로부터 +보호하는 것은 거의 불가능하다. 그러나 이런 영역들의 보안이 적절하게 +처리되고, 코드에 보안을 추가한다면 이미 강력한 기반이 더욱 강화될 것이다. 이러한 관심 분야는 아래에서 더 자세히 설명한다. ## 클라우드 여러 면에서 클라우드(또는 공동 위치 서버, 또는 기업의 데이터 센터)는 쿠버네티스 클러스터 구성을 위한 [신뢰 컴퓨팅 기반(trusted computing base)](https://en.wikipedia.org/wiki/Trusted_computing_base) -이다. 이러한 구성 요소 자체가 취약하거나(또는 취약한 방법으로 구성된) -경우 이 기반 위에서 구축된 모든 구성 요소의 보안을 -실제로 보장할 방법이 없다. 각 클라우드 공급자는 그들의 환경에서 워크로드를 -안전하게 실행하는 방법에 대해 고객에게 광범위한 보안 권장 사항을 -제공한다. 모든 클라우드 공급자와 워크로드는 다르기 때문에 -클라우드 보안에 대한 권장 사항을 제공하는 것은 이 가이드의 범위를 벗어난다. 다음은 -알려진 클라우드 공급자의 보안 문서의 일부와 +이다. 이러한 구성 요소 자체가 취약하거나(또는 취약한 방법으로 구성된) +경우 이 기반 위에서 구축된 모든 구성 요소의 보안을 +실제로 보장할 방법이 없다. 각 클라우드 공급자는 그들의 환경에서 워크로드를 +안전하게 실행하는 방법에 대해 고객에게 광범위한 보안 권장 사항을 +제공한다. 모든 클라우드 공급자와 워크로드는 다르기 때문에 +클라우드 보안에 대한 권장 사항을 제공하는 것은 이 가이드의 범위를 벗어난다. 다음은 +알려진 클라우드 공급자의 보안 문서의 일부와 쿠버네티스 클러스터를 구성하기 위한 인프라 보안에 대한 일반적인 지침을 제공한다. @@ -65,7 +65,7 @@ Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security VMWare VSphere | https://www.vmware.com/security/hardening-guides.html | -자체 하드웨어나 다른 클라우드 공급자를 사용하는 경우 보안에 대한 +자체 하드웨어나 다른 클라우드 공급자를 사용하는 경우 보안에 대한 모범 사례는 해당 문서를 참조한다. ### 일반적인 인프라 지침 표 @@ -73,32 +73,33 @@ VMWare VSphere | https://www.vmware.com/security/hardening-guides.html | 쿠버네티스 인프라에서 고려할 영역 | 추천 | --------------------------------------------- | ------------ | API 서버에 대한 네트워크 접근(마스터) | 이상적으로는 인터넷에서 쿠버네티스 마스터에 대한 모든 접근을 공개적으로 허용하지 않으며 클러스터를 관리하는데 필요한 IP 주소 집합으로 제한된 네트워크 접근 제어 목록(ACL)에 의해 제어되어야 한다. | -노드에 대한 네트워크 접근(워커 서버) | 노드는 마스터의 지정된 포트 연결_만_ 허용하고(네트워크 접근 제어 목록의 사용), NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 구성해야 한다. 가능한 노드가 공용 인터넷에 완전히 노출되어서는 안된다. +노드에 대한 네트워크 접근(워커 서버) | 노드는 마스터의 지정된 포트 연결_만_ 허용하고(네트워크 접근 제어 목록의 사용), NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 구성해야 한다. 가능한 노드가 공용 인터넷에 완전히 노출되어서는 안된다. 클라우드 공급자 API에 대한 쿠버네티스 접근 | 각 클라우드 공급자는 쿠버네티스 마스터 및 노드에 서로 다른 권한을 부여해야 함으로써, 이런 권장 사항이 더 일반적이다. 관리해야 하는 리소스에 대한 [최소 권한의 원칙](https://en.wikipedia.org/wiki/Principle_of_least_privilege)을 따르는 클라우드 공급자의 접근 권한을 클러스터에 구성하는 것이 가장 좋다. AWS의 Kops에 대한 예제: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles etcd에 대한 접근 | etcd (쿠버네티스의 데이터저장소)에 대한 접근은 마스터로만 제한되어야 한다. 구성에 따라 TLS를 통해 etcd를 사용해야 한다. 자세한 정보: https://github.com/etcd-io/etcd/tree/master/Documentation#security etcd 암호화 | 가능한 모든 드라이브를 유휴 상태에서 암호화 하는 것이 좋은 방법이지만, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 디스크의 암호화는 유휴 상태에서 암호화 되어야 한다. ## 클러스터 -이 섹션에서는 쿠버네티스의 워크로드 +이 섹션에서는 쿠버네티스의 워크로드 보안을 위한 링크를 제공한다. 쿠버네티스 보안에 영향을 미치는 다음 두 가지 영역이 있다. * 클러스터를 구성하는 설정 가능한 컴포넌트의 보안 * 클러스터에서 실행되는 컴포넌트의 보안 + ### 클러스터_의_ 컴포넌트 -우발적이거나 악의적인 접근으로부터 클러스터를 보호하고, -모범 사례에 대한 정보를 채택하기 위해서는 +우발적이거나 악의적인 접근으로부터 클러스터를 보호하고, +모범 사례에 대한 정보를 채택하기 위해서는 [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)에 대한 조언을 읽고 따른다. ### 클러스터 _내_ 컴포넌트(애플리케이션) -애플리케이션의 공격 영역에 따라, 보안의 특정 측면에 -중점을 둘 수 있다. 예를 들어, 다른 리소스 체인에 중요한 서비스(서비스 A)와 -리소스 소진 공격에 취약한 별도의 작업 부하(서비스 B)를 실행하는 경우, -리소스 제한을 설정하지 않은 서비스 B에 의해 -서비스 A 또한 손상시킬 위험이 있다. 다음은 쿠버네티스에서 +애플리케이션의 공격 영역에 따라, 보안의 특정 측면에 +중점을 둘 수 있다. 예를 들어, 다른 리소스 체인에 중요한 서비스(서비스 A)와 +리소스 소진 공격에 취약한 별도의 작업 부하(서비스 B)를 실행하는 경우, +리소스 제한을 설정하지 않은 서비스 B에 의해 +서비스 A 또한 손상시킬 위험이 있다. 다음은 쿠버네티스에서 실행 중인 워크로드를 보호할 때 고려해야 할 사항에 대한 링크 표이다. 워크로드 보안에서 고려할 영역 | 추천 | @@ -115,9 +116,9 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r ## 컨테이너 -쿠버네티스에서 소프트웨어를 실행하려면, 소프트웨어는 컨테이너에 있어야 한다. 이로 인해, -쿠버네티스의 원시적인 워크로드 보안으로부터 이점을 얻기 위해서 -반드시 고려해야 할 보안 사항이 있다. 컨테이너 보안 +쿠버네티스에서 소프트웨어를 실행하려면, 소프트웨어는 컨테이너에 있어야 한다. 이로 인해, +쿠버네티스의 원시적인 워크로드 보안으로부터 이점을 얻기 위해서 +반드시 고려해야 할 보안 사항이 있다. 컨테이너 보안 또한 이 가이드의 범위를 벗어나지만, 해당 주제에 대한 추가적인 설명을 위하여 일반 권장사항 및 링크 표를 아래에 제공한다. @@ -129,9 +130,9 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r ## 코드 -마지막으로 애플리케이션의 코드 수준으로 내려가면, 가장 많은 제어를 할 수 있는 -주요 공격 영역 중 하나이다. 이런 코드 수준은 쿠버네티스의 범위 -밖이지만 몇가지 권장사항이 있다. +마지막으로 애플리케이션의 코드 수준으로 내려가면, 가장 많은 제어를 할 수 있는 +주요 공격 영역 중 하나이다. 이런 코드 수준은 쿠버네티스의 범위 +밖이지만 몇 가지 권장사항이 있다. ### 일반적인 코드 보안 지침표 @@ -146,8 +147,8 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 클라이 ## 강력한(robust) 자동화 -위에서 언급한 대부분의 제안사항은 실제로 일련의 보안 검사의 일부로 코드를 -전달하는 파이프라인에 의해 자동화 될 수 있다. 소프트웨어 전달을 위한 +위에서 언급한 대부분의 제안사항은 실제로 일련의 보안 검사의 일부로 코드를 +전달하는 파이프라인에 의해 자동화 될 수 있다. 소프트웨어 전달을 위한 "지속적인 해킹(Continuous Hacking)"에 대한 접근 방식에 대해 알아 보려면, 자세한 설명을 제공하는 [이 기사](https://thenewstack.io/beyond-ci-cd-how-continuous-hacking-of-docker-containers-and-pipeline-driven-security-keeps-ygrene-secure/)를 참고한다. @@ -159,4 +160,3 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 클라이 * 컨트롤 플레인에 대한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) 알아보기 * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) 알아보기 * [쿠버네티스 시크릿](/docs/concepts/configuration/secret/)에 대해 알아보기 - diff --git a/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index bc5560b5ba..ad5b1f9bbb 100644 --- a/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -54,16 +54,15 @@ fe00::2 ip6-allrouters 10.200.0.4 nginx ``` -기본적으로, `hosts` 파일은 `localhost`와 자기 자신의 호스트네임과 같은 IPv4와 IPv6 +기본적으로, `hosts` 파일은 `localhost`와 자기 자신의 호스트네임과 같은 IPv4와 IPv6 상용구들만 포함하고 있다. ## HostAliases를 사용하여 추가 항목들 추가하기 -기본 상용구 이외에, `foo.local`, `bar.local`이 `127.0.0.1`로, `foo.remote`, -`bar.remote`가 `10.1.2.3`로 해석될 수 있도록 추가 항목들을 `hosts` 파일에 추가할 수 있으며, -이는 `.spec.hostAliases` 항목에서 정의하여 -파드에 HostAliases를 추가하면 가능하다. - +기본 상용구 이외에, `foo.local`, `bar.local`이 `127.0.0.1`로, +`foo.remote`, `bar.remote`가 `10.1.2.3`로 해석될 수 있도록 +추가 항목들을 `hosts` 파일에 추가할 수 있으며, +이는 `.spec.hostAliases` 항목에서 정의하여 파드에 HostAliases를 추가하면 가능하다. {{< codenew file="service/networking/hostaliases-pod.yaml" >}} @@ -113,14 +112,12 @@ fe00::2 ip6-allrouters ## 왜 Kubelet이 호스트 파일을 관리하는가? -컨테이너가 이미 시작되고 난 후 Docker가 파일을 [수정](https://github.com/moby/moby/issues/17190) -하는 것을 방지하기 위해 Kubelet은 파드의 각 컨테이너의 `hosts` 파일을 -[관리](https://github.com/kubernetes/kubernetes/issues/14633) -한다. +컨테이너가 이미 시작되고 난 후 도커가 파일을 +[수정](https://github.com/moby/moby/issues/17190)하는 것을 방지하기 위해 +Kubelet은 파드의 각 컨테이너의 `hosts` 파일을 +[관리](https://github.com/kubernetes/kubernetes/issues/14633)한다. -호스트 파일이 관리된다는 특성으로 인해, 컨테이너 재시작이나 파드 리스케줄 이벤트로 +호스트 파일이 관리된다는 특성으로 인해, 컨테이너 재시작이나 파드 리스케줄 이벤트로 `hosts` 파일이 Kubelet에 의해 다시 마운트될 때마다 사용자가 작성한 모든 내용이 -덮어쓰여진다. 따라서, 호스트 파일의 내용을 +덮어 쓰인다. 따라서, 호스트 파일의 내용을 직접 바꾸는 것은 권장하지 않는다. - - diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index 4649577399..eda8ab3d68 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -73,7 +73,7 @@ service/my-nginx exposed 이 사양은 `run: my-nginx` 레이블이 부착된 모든 파드에 TCP 포트 80을 대상으로 하는 서비스를 만들고 추상화된 서비스 포트에 노출시킨다 -(`targetPort` 는 컨테이너가 트래픽을 수신하는 포트, `port` 는 +(`targetPort` 는 컨테이너가 트래픽을 수신하는 포트, `port` 는 추상화된 서비스 포트로 다른 파드들이 서비스에 접속하기위해 사용하는 모든 포트일 수 있다). [서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)의 @@ -390,8 +390,8 @@ kubectl edit svc my-nginx kubectl get svc my-nginx ``` ``` -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -my-nginx ClusterIP 10.0.162.149 162.222.184.144 80/TCP,81/TCP,82/TCP 21s +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s ``` ``` curl https:// -k diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 7550473fc2..46ac05bf8e 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -3,9 +3,6 @@ title: 서비스 및 파드용 DNS content_type: concept weight: 20 --- - - - 이 페이지는 쿠버네티스의 DNS 지원에 대한 개요를 설명한다. @@ -14,26 +11,26 @@ weight: 20 ## 소개 -쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며, -개별 컨테이너들이 DNS 네임을 해석할 때 +쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며, +개별 컨테이너들이 DNS 네임을 해석할 때 DNS 서비스의 IP를 사용하도록 kubelets를 구성한다. ### DNS 네임이 할당되는 것들 -클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다. -기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와 -클러스터의 기본 도메인을 포함한다. +클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다. +기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와 +클러스터의 기본 도메인을 포함한다. 이 예시는 다음과 같다. -쿠버네티스 네임스페이스 `bar`에 `foo`라는 서비스가 있다. 네임스페이스 `bar`에서 running 상태인 파드는 -단순하게 `foo`를 조회하는 DNS 쿼리를 통해서 서비스 `foo`를 찾을 수 있다. -네임스페이스 `quux`에서 실행 중인 파드는 +쿠버네티스 네임스페이스 `bar`에 `foo`라는 서비스가 있다. 네임스페이스 `bar`에서 running 상태인 파드는 +단순하게 `foo`를 조회하는 DNS 쿼리를 통해서 서비스 `foo`를 찾을 수 있다. +네임스페이스 `quux`에서 실행 중인 파드는 `foo.bar`를 조회하는 DNS 쿼리를 통해서 이 서비스를 찾을 수 있다. -다음 절에서는 쿠버네티스 DNS에서 지원하는 레코드 유형과 레이아웃을 자세히 설명한다. -이 외에 동작하는 레이아웃, 네임 또는 쿼리는 구현 세부 정보로 간주하며 경고 없이 변경될 수 있다. +다음 절에서는 쿠버네티스 DNS에서 지원하는 레코드 유형과 레이아웃을 자세히 설명한다. +이 외에 동작하는 레이아웃, 네임 또는 쿼리는 구현 세부 정보로 간주하며 +경고 없이 변경될 수 있다. 최신 업데이트에 대한 자세한 설명은 다음 링크를 통해 참조할 수 있다. - [쿠버네티스 DNS 기반 서비스 디스커버리](https://github.com/kubernetes/dns/blob/master/docs/specification.md). ## 서비스 @@ -41,43 +38,50 @@ DNS 서비스의 IP를 사용하도록 kubelets를 구성한다. ### A/AAAA 레코드 "노멀"(헤드리스가 아닌) 서비스는 서비스 IP 계열에 따라 -`my-svc.my-namespace.svc.cluster-domain.example` +`my-svc.my-namespace.svc.cluster-domain.example` 형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 이는 서비스의 클러스터 IP로 해석된다. "헤드리스"(클러스터 IP가 없는) 서비스 또한 서비스 IP 계열에 따라 -`my-svc.my-namespace.svc.cluster-domain.example` -형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. -노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다. +`my-svc.my-namespace.svc.cluster-domain.example` +형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. +노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다. 클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을 통해 선택할 수 있다. ### SRV 레코드 -SRV 레코드는 노멀 서비스 또는 -[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에 -속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다. +SRV 레코드는 노멀 서비스 또는 +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에 +속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다. `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`. -정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다. +정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다. `my-svc.my-namespace.svc.cluster-domain.example`. -헤드리스 서비스의 경우, 서비스를 지원하는 각 파드에 대해 하나씩 복수 응답으로 해석되며 이 응답은 파드의 -포트 번호와 도메인 이름을 포함한다. +헤드리스 서비스의 경우, 서비스를 지원하는 각 파드에 대해 하나씩 복수 응답으로 해석되며 이 응답은 파드의 +포트 번호와 도메인 이름을 포함한다. `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`. ## 파드 +### A/AAAA 레코드 + +디플로이먼트나 데몬셋으로 생성되는 파드는 다음과 같은 +DNS 주소를 갖게 된다. + +`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.` + ### 파드의 hostname 및 subdomain 필드 파드가 생성되면 hostname은 해당 파드의 `metadata.name` 값이 된다. -파드 스펙(Pod spec)에는 선택적 필드인 `hostname`이 있다. -이 필드는 파드의 호스트네임을 지정할 수 있다. -`hostname` 필드가 지정되면, 파드의 이름보다 파드의 호스트네임이 우선시된다. +파드 스펙(Pod spec)에는 선택적 필드인 `hostname`이 있다. +이 필드는 파드의 호스트네임을 지정할 수 있다. +`hostname` 필드가 지정되면, 파드의 이름보다 파드의 호스트네임이 우선시된다. 예를 들어 `hostname` 필드가 "`my-host`"로 설정된 파드는 호스트네임이 "`my-host`"로 설정된다. -또한, 파드 스펙에는 선택적 필드인 `subdomain`이 있다. 이 필드는 서브도메인을 지정할 수 있다. -예를 들어 "`my-namespace`" 네임스페이스에서, `hostname` 필드가 "`foo`"로 설정되고, -`subdomain` 필드가 "`bar`"로 설정된 파드는 전체 주소 도메인 네임(FQDN)을 가지게 된다. +또한, 파드 스펙에는 선택적 필드인 `subdomain`이 있다. 이 필드는 서브도메인을 지정할 수 있다. +예를 들어 "`my-namespace`" 네임스페이스에서, `hostname` 필드가 "`foo`"로 설정되고, +`subdomain` 필드가 "`bar`"로 설정된 파드는 전체 주소 도메인 네임(FQDN)을 가지게 된다. "`foo.bar.my-namespace.svc.cluster-domain.example`". 예시: @@ -129,59 +133,58 @@ spec: name: busybox ``` -파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면, +파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면, 클러스터의 DNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다. -예를 들어 호스트네임이 "`busybox-1`"이고, -서브도메인이 "`default-subdomain`"이고, -같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면, -파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다. +예를 들어 호스트네임이 "`busybox-1`"이고, +서브도메인이 "`default-subdomain`"이고, +같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면, +파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다. "`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". -DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다. +DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다. "`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다. -엔드포인트 객체는 `hostname` 필드를 임의의 엔드포인트 IP 주소로 지정할 수 있다. +엔드포인트 객체는 `hostname` 필드를 +임의의 엔드포인트 IP 주소로 지정할 수 있다. {{< note >}} -A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에 -파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다. -`hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의 -A 또는 AAAA 레코드만 생성할 수 있다. -(`default-subdomain.my-namespace.svc.cluster-domain.example`) -또한 레코드를 가지기 위해서는 파드가 준비되어야 한다. -그렇지 않은 경우, 서비스에서 `publishNotReadyAddresses=True`가 활성화된다. +A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에 +파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다. +`hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의 +A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespace.svc.cluster-domain.example`) +또한 서비스에서 `publishNotReadyAddresses=True` 를 설정하지 않았다면, 파드가 준비 상태가 되어야 레코드를 가질 수 있다. {{< /note >}} ### 파드의 DNS 정책 -DNS 정책은 파드별로 설정할 수 있다. 현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다. +DNS 정책은 파드별로 설정할 수 있다. +현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다. 이 정책들은 파드 스펙의 `dnsPolicy` 필드에서 지정할 수 있다. -- "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다. - 자세한 내용은 - [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) - 에서 확인할 수 있다. -- "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과 - 일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다. - 클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다. - 그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은 - [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods) - 에서 확인할 수 있다. -- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 +- "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다. + 자세한 내용은 + [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)에서 + 확인할 수 있다. +- "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과 + 일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다. + 클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다. + 그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은 + [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)에서 + 확인할 수 있다. +- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다. -- "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다. +- "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다. 모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다. - 아래 절인 - [파드의 DNS 설정](#pod-dns-config) - 에서 자세한 내용을 확인할 수 있다. + 아래 절인 [파드의 DNS 설정](#pod-dns-config)에서 + 자세한 내용을 확인할 수 있다. {{< note >}} -"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면 +"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면 “ClusterFirst”가 기본값으로 사용된다. {{< /note >}} -아래 예시는 `hostNetwork`필드가 `true`로 설정되어 있어서 -DNS 정책이 "`ClusterFirstWithHostNet`"으로 설정된 파드를 보여준다. +아래 예시는 `hostNetwork`필드가 `true`로 설정되어 있어서 +DNS 정책이 "`ClusterFirstWithHostNet`"으로 설정된 파드를 보여준다. ```yaml apiVersion: v1 @@ -206,30 +209,33 @@ spec: 사용자들은 파드의 DNS 설정을 통해서 직접 파드의 DNS를 세팅할 수 있다. -`dnsConfig` 필드는 선택적이고, `dnsPolicy` 세팅과 함께 동작한다. -이때, 파드의 `dnsPolicy`의 값이 "`None`"으로 설정되어 있어야 `dnsConfig` 필드를 지정할 수 있다. +`dnsConfig` 필드는 선택적이고, `dnsPolicy` 세팅과 함께 동작한다. +이때, 파드의 `dnsPolicy`의 값이 "`None`"으로 설정되어 있어야 +`dnsConfig` 필드를 지정할 수 있다. 사용자는 `dnsConfig` 필드에서 다음과 같은 속성들을 지정할 수 있다. -- `nameservers`: 파드의 DNS 서버가 사용할 IP 주소들의 목록이다. - 파드의 `dnsPolicy`가 "`None`" 으로 설정된 경우에는 - 적어도 하나의 IP 주소가 포함되어야 하며, +- `nameservers`: 파드의 DNS 서버가 사용할 IP 주소들의 목록이다. + 파드의 `dnsPolicy`가 "`None`" 으로 설정된 경우에는 + 적어도 하나의 IP 주소가 포함되어야 하며, 그렇지 않으면 이 속성은 생략할 수 있다. - `nameservers`에 나열된 서버는 지정된 DNS 정책을 통해 생성된 기본 네임 서버와 합쳐지며 중복되는 주소는 제거된다. -- `searches`: 파드의 호스트네임을 찾기 위한 DNS 검색 도메인의 목록이다. - 이 속성은 생략이 가능하며, - 값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다. - 병합 시 중복되는 도메인은 제거되며, 쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다. -- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다. - 이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다. - 이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며, + `nameservers`에 나열된 서버는 지정된 DNS 정책을 통해 생성된 기본 네임 서버와 합쳐지며 + 중복되는 주소는 제거된다. +- `searches`: 파드의 호스트네임을 찾기 위한 DNS 검색 도메인의 목록이다. + 이 속성은 생략이 가능하며, + 값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다. + 병합 시 중복되는 도메인은 제거되며, + 쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다. +- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다. + 이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다. + 이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며, 병합 시 중복되는 항목은 제거된다. - + 다음은 커스텀 DNS 세팅을 한 파드의 예시이다. {{< codenew file="service/networking/custom-dns.yaml" >}} -위에서 파드가 생성되면, +위에서 파드가 생성되면, 컨테이너 `test`의 `/etc/resolv.conf` 파일에는 다음과 같은 내용이 추가된다. ``` @@ -243,9 +249,7 @@ IPv6 셋업을 위해서 검색 경로와 네임 서버 셋업은 다음과 같 ```shell kubectl exec -it dns-example -- cat /etc/resolv.conf ``` - 출력은 다음과 같은 형식일 것이다. - ```shell nameserver fd00:79:30::a search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example @@ -267,9 +271,5 @@ options ndots:5 ## {{% heading "whatsnext" %}} -DNS 구성 관리에 대한 지침은 -[DNS 서비스 구성](/docs/tasks/administer-cluster/dns-custom-nameservers/) -에서 확인 할 수 있다. - - - +DNS 구성 관리에 대한 지침은 +[DNS 서비스 구성](/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 확인할 수 있다. diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index 11390c04d5..a94aaad2d1 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -47,7 +47,7 @@ IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요 * `--feature-gates="IPv6DualStack=true"` * `--cluster-cidr=,` * `--service-cluster-ip-range=,` - * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64이다. + * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다. * kubelet: * `--feature-gates="IPv6DualStack=true"` * kube-proxy: diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index 2a2ffc45bf..d07b03ea5d 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -152,7 +152,7 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그 필요한 새 엔드포인트로 채운다. 3. 추가할 새 엔드포인트가 여전히 남아있으면, 이전에 변경되지 않은 슬라이스에 엔드포인트를 맞추거나 새로운 것을 생성한다. - + 중요한 것은, 세 번째 단계는 엔드포인트슬라이스를 완벽하게 전부 배포하는 것보다 엔드포인트슬라이스 업데이트 제한을 우선시한다. 예를 들어, 추가할 새 엔드포인트가 10개이고 각각 5개의 공간을 사용할 수 있는 엔드포인트 공간이 있는 2개의 @@ -161,7 +161,7 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그 엔드포인트슬라이스를 생성하는 것이 여러 엔드포인트슬라이스를 업데이트하는 것 보다 더 선호된다. 각 노드에서 kube-proxy를 실행하고 엔드포인트슬라이스를 관찰하면, -엔드포인트슬라이스에 대한 모든 변경 사항이 클러스터의 모든 노드로 전송되기 +엔드포인트슬라이스에 대한 모든 변경 사항이 클러스터의 모든 노드로 전송되기 때문에 상대적으로 비용이 많이 소요된다. 이 방법은 여러 엔드포인트슬라이스가 가득 차지 않은 결과가 발생할지라도, 모든 노드에 전송해야 하는 변경 횟수를 의도적으로 제한하기 위한 것이다. @@ -179,6 +179,5 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그 * [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices) -* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 를 읽는다. - +* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기 diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index 4600c32bcf..85aebe74af 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -9,12 +9,13 @@ weight: 40 인그레스 리소스가 작동하려면, 클러스터는 실행 중인 인그레스 컨트롤러가 반드시 필요하다. -kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는 클러스터와 함께 자동으로 실행되지 않는다. +kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는 +클러스터와 함께 자동으로 실행되지 않는다. 클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다. 프로젝트로써 쿠버네티스는 현재 [GCE](https://git.k8s.io/ingress-gce/README.md) 와 [nginx](https://git.k8s.io/ingress-nginx/README.md) 컨트롤러를 지원하고 유지한다. - + @@ -22,31 +23,42 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 ## 추가 컨트롤러 * [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview). -* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의 - [커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는 +* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의 + [커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는 [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다. -* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](http://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다. +* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](http://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다. * [AWS ALB 인그레스 컨트롤러](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)는 [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)를 사용하여 인그레스를 활성화한다. -* [Contour](https://projectcontour.io/)는 VMware에서 제공하고 지원하는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다. +* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로 + VMware에서 제공하고 지원한다. * Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다. -* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨트롤러](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한 [지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다. +* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨트롤러](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한 + [지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다. * [Gloo](https://gloo.solo.io)는 [solo.io](https://www.solo.io)의 엔터프라이즈 지원과 함께 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 오픈 소스 인그레스 컨트롤러다. * [HAProxy 인그레스](https://haproxy-ingress.github.io)는 HAProxy를 위한 고도로 커스터마이징 가능한 커뮤니티 주도형 인그레스 컨트롤러다. * [HAProxy Technologies](https://www.haproxy.com/)는 [쿠버네티스를 위한 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress)를 지원하고 유지 보수한다. [공식 문서](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)를 통해 확인할 수 있다. -* [Istio](https://istio.io/)는 인그레스 컨트롤러 기반으로 - [인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/). -* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한 [커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는 [상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다. -* [NGINX, Inc.](https://www.nginx.com/) 는 [쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다. -* 쿠버네티스 인그레스와 같이 사용 사례를 포함하는 서비스 구성을 위한 [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다. -* [Traefik](https://github.com/containous/traefik)은 완벽한 기능([암호화](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로, [Containous](https://containo.us/services)에서 상업적인 지원을 제공한다. +* [Istio](https://istio.io/)는 인그레스 컨트롤러 기반으로 + [인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/). +* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한 + [커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는 + [상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다. +* [NGINX, Inc.](https://www.nginx.com/)는 + [쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다. +* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 쿠버네티스 인그레스와 같은 유스케이스를 포함하는 서비스 구성을 위한 HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다. +* [Traefik](https://github.com/containous/traefik)은 + 모든 기능([Let's Encrypt](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로, + [Containous](https://containo.us/services)에서 상업적인 지원을 제공한다. ## 여러 인그레스 컨트롤러 사용 -하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다. 인그레스를 생성할 때, 클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우 어떤 인그레스 컨트롤러를 사용해야하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 어노테이션을 각각의 인그레스에 달아야 한다. +하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다. +인그레스를 생성할 때, 클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우 +어떤 인그레스 컨트롤러를 사용해야 하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) +어노테이션을 각각의 인그레스에 달아야 한다. 만약 클래스를 정의하지 않으면, 클라우드 제공자는 기본 인그레스 컨트롤러를 사용할 수 있다. -이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야하지만, 다양한 인그레스 컨트롤러는 약간 다르게 작동한다. +이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야 하지만, +다양한 인그레스 컨트롤러는 약간 다르게 작동한다. {{< note >}} 인그레스 컨트롤러의 설명서를 검토하여 선택 시 주의 사항을 이해해야한다. @@ -58,6 +70,4 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기. -* [NGINX 컨트롤러로 Minikube에서 Ingress를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube). - - +* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube). diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 968274bc1c..19982fd447 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -1,5 +1,5 @@ --- -title: 인그레스 +title: 인그레스(Ingress) content_type: concept weight: 40 --- @@ -15,11 +15,11 @@ weight: 40 이 가이드는 용어의 명확성을 위해 다음과 같이 정의한다. -노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신. -클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다. -에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다. -클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. -서비스(Service): {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다. +* 노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신. +* 클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다. +* 에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다. +* 클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. +* 서비스: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다. ## 인그레스란? @@ -134,8 +134,7 @@ spec: 요청은 _p_ 경로에 일치한다. {{< note >}} - 경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: - `/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다). + 경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다). {{< /note >}} #### 다중 일치 @@ -216,7 +215,7 @@ NAME HOSTS ADDRESS PORTS AGE test-ingress * 203.0.113.123 80 59s ``` -여기서 `203.0.113.123` 는 인그레스 컨트롤러가 인그레스를 충족시키기 위해 +여기서 `203.0.113.123` 는 인그레스 컨트롤러가 인그레스를 충족시키기 위해 할당한 IP 이다. {{< note >}} diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index 55fde3a3be..f10552c703 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -9,28 +9,28 @@ weight: 50 네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다. -`NetworkPolicy` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다. +`네트워크폴리시(NetworkPolicy)` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다. ## 전제 조건 -네트워크 정책은 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 NetworkPolicy를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 NetworkPolicy 리소스를 생성해도 아무런 효과가 없기 때문이다. +네트워크 정책은 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 네트워크폴리시를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 네트워크폴리시 리소스를 생성해도 아무런 효과가 없기 때문이다. ## 격리 및 격리되지 않은 파드 기본적으로, 파드는 격리되지 않는다. 이들은 모든 소스에서 오는 트래픽을 받아들인다. -파드는 파드를 선택한 NetworkPolicy에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 NetworkPolicy가 있으면 해당 파드는 NetworkPolicy에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 NetworkPolicy에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.) +파드는 파드를 선택한 네트워크폴리시에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 네트워크폴리시가 있으면 해당 파드는 네트워크폴리시에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 네트워크폴리시에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.) 네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다. -## NetworkPolicy 리소스 {#networkpolicy-resource} +## 네트워크폴리시 리소스 {#networkpolicy-resource} -리소스에 대한 전체 정의에 대한 참조는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다. +리소스에 대한 전체 정의에 대한 참조는 [네트워크폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다. -NetworkPolicy 의 예시는 다음과 같다. +네트워크폴리시 의 예시는 다음과 같다. ```yaml apiVersion: networking.k8s.io/v1 @@ -73,23 +73,23 @@ spec: 선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다. {{< /note >}} -__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 NetworkPolicy 에는 +__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 네트워크폴리시 에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 구성 파일 작업에 대한 일반적인 정보는 [컨피그 맵을 사용해서 컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), 그리고 [오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management) 를 본다. -__spec__: NetworkPolicy [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다. +__spec__: 네트워크폴리시 [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다. -__podSelector__: 각 NetworkPolicy 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다. +__podSelector__: 각 네트워크폴리시에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다. -__policyTypes__: 각 NetworkPolicy 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다. +__policyTypes__: 각 네트워크폴리시에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 네트워크폴리시에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, 네트워크폴리시에 `Egress` 가 있으면 이그레스 규칙이 설정된다. -__ingress__: 각 NetworkPolicy 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다. +__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다. -__egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다. +__egress__: 각 네트워크폴리시에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다. -따라서 예시의 NetworkPolicy는 다음과 같이 동작한다. +따라서 예시의 네트워크폴리시는 다음과 같이 동작한다. 1. 인그레스 및 이그레스 트래픽에 대해 "default" 네임스페이스에서 "role=db"인 파드를 격리한다(아직 격리되지 않은 경우). 2. (인그레스 규칙)은 "role=db" 레이블을 사용하는 "default" 네임스페이스의 모든 파드에 대해서 TCP 포트 6397로의 연결을 허용한다. 인그레스을 허용 할 대상은 다음과 같다. @@ -105,7 +105,7 @@ __egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포 `ingress` `from` 부분 또는 `egress` `to` 부분에 지정할 수 있는 네 종류의 셀렉터가 있다. -__podSelector__: NetworkPolicy 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다. +__podSelector__: 네트워크폴리시를 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다. __namespaceSelector__: 모든 파드가 인그레스 소스 또는 이그레스를 대상으로 허용되어야 하는 특정 네임스페이스를 선택한다. @@ -146,15 +146,15 @@ __namespaceSelector__ *와* __podSelector__: `namespaceSelector` 와 `podSelecto __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP CIDR 범위를 선택한다. 파드 IP는 임시적이고 예측할 수 없기에 클러스터 외부 IP이어야 한다. 클러스터 인그레스 및 이그레스 매커니즘은 종종 패킷의 소스 또는 대상 IP의 재작성을 -필요로 한다. 이러한 상황이 발생하는 경우, NetworkPolicy의 처리 전 또는 후에 +필요로 한다. 이러한 상황이 발생하는 경우, 네트워크폴리시의 처리 전 또는 후에 발생한 것인지 정의되지 않으며, 네트워크 플러그인, 클라우드 공급자, `서비스` 구현 등의 조합에 따라 동작이 다를 수 있다. -인그레스 사례에서의 의미는 실제 원본 소스 IP를 기준으로 들어오는 패킷을 -필터링할 수 있는 반면에 다른 경우에는 NetworkPolicy가 작동하는 +인그레스 사례에서의 의미는 실제 원본 소스 IP를 기준으로 들어오는 패킷을 +필터링할 수 있는 반면에 다른 경우에는 네트워크폴리시가 작동하는 "소스 IP"는 `LoadBalancer` 또는 파드가 속한 노드 등의 IP일 수 있다. -이그레스의 경우 파드에서 클러스터 외부 IP로 다시 작성된 `서비스` IP로의 연결은 +이그레스의 경우 파드에서 클러스터 외부 IP로 다시 작성된 `서비스` IP로의 연결은 `ipBlock` 기반의 정책의 적용을 받거나 받지 않을 수 있다는 것을 의미한다. ## 기본 정책 @@ -164,11 +164,11 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C ### 기본적으로 모든 인그레스 트래픽 거부 -모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다. +모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다. {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} -이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다. +이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다. ### 기본적으로 모든 인그레스 트래픽 허용 @@ -178,11 +178,11 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C ### 기본적으로 모든 이그레스 트래픽 거부 -모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다. +모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다. {{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} -이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은 +이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은 기본 인그레스 격리 정책을 변경하지 않는다. ### 기본적으로 모든 이그레스 트래픽 허용 @@ -193,21 +193,21 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C ### 기본적으로 모든 인그레스와 모든 이그레스 트래픽 거부 -해당 네임스페이스에 아래의 NetworkPolicy를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다. +해당 네임스페이스에 아래의 네트워크폴리시를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다. {{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} -이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다. +이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다. ## SCTP 지원 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} 이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. -기능 게이트가 활셩화 되면, NetworkPolicy의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. +기능 게이트가 활셩화 되면, 네트워크폴리시의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. {{< note >}} -SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다. +SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다. {{< /note >}} @@ -218,6 +218,4 @@ SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI" - 자세한 설명과 추가 예시는 [네트워크 정책 선언](/docs/tasks/administer-cluster/declare-network-policy/)을 본다. -- NetworkPolicy 리소스에서 사용되는 일반적인 시나리오는 [레시피](https://github.com/ahmetb/kubernetes-network-policy-recipes)를 본다. - - +- 네트워크폴리시 리소스에서 사용되는 일반적인 시나리오는 [레시피](https://github.com/ahmetb/kubernetes-network-policy-recipes)를 본다. diff --git a/content/ko/docs/concepts/services-networking/service-topology.md b/content/ko/docs/concepts/services-networking/service-topology.md index da419f76e4..567b998791 100644 --- a/content/ko/docs/concepts/services-networking/service-topology.md +++ b/content/ko/docs/concepts/services-networking/service-topology.md @@ -194,7 +194,7 @@ spec: ## {{% heading "whatsnext" %}} -* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽는다. -* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽는다. +* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽어보기. +* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기. diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index e1e0d28c7c..51845e9496 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -10,8 +10,6 @@ weight: 10 --- - - {{< glossary_definition term_id="service" length="short" >}} @@ -242,7 +240,8 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을 추가와 제거를 감시한다. 각 서비스는 로컬 노드에서 포트(임의로 선택됨)를 연다. 이 "프록시 포트"에 대한 모든 연결은 (엔드포인트를 통해 보고된대로) 서비스의 백엔드 파드 중 하나로 -프록시된다. kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의 +프록시된다. +kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의 `SessionAffinity` 설정을 고려한다. 마지막으로, 유저-스페이스 프록시는 서비스의 @@ -497,15 +496,15 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하 서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는 `NodePort`와 `ClusterIP` 서비스가 자동으로 생성된다. * [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여, 서비스를 - `externalName` 필드의 컨텐츠 (예:`foo.bar.example.com`)에 - 맵핑한다. 어떤 종류의 프록시도 설정되어 있지 않다. + `externalName` 필드의 콘텐츠 (예:`foo.bar.example.com`)에 + 매핑한다. + 어떤 종류의 프록시도 설정되어 있지 않다. {{< note >}} `ExternalName` 유형을 사용하려면 kube-dns 버전 1.7 또는 CoreDNS 버전 1.7 이상이 필요하다. {{< /note >}} [인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다. - ### NodePort 유형 {#nodeport} `type` 필드를 `NodePort`로 설정하면, 쿠버네티스 컨트롤 플레인은 @@ -686,7 +685,7 @@ metadata: ```yaml [...] metadata: - annotations: + annotations: service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx [...] ``` @@ -1234,5 +1233,3 @@ kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지 * [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기 * [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기 - - diff --git a/content/ko/docs/concepts/storage/dynamic-provisioning.md b/content/ko/docs/concepts/storage/dynamic-provisioning.md index bf0b257dbf..87ce9c9d27 100644 --- a/content/ko/docs/concepts/storage/dynamic-provisioning.md +++ b/content/ko/docs/concepts/storage/dynamic-provisioning.md @@ -29,19 +29,19 @@ API 오브젝트를 기반으로 한다. 클러스터 관리자는 볼륨을 프 클러스터 관리자는 클러스터 내에서 사용자 정의 파라미터 집합을 사용해서 여러 가지 유형의 스토리지 (같거나 다른 스토리지 시스템들)를 정의하고 노출시킬 수 있다. 또한 이 디자인을 통해 최종 사용자는 -스토리지 프로비전 방식의 복잡성과 뉘앙스에 대해 걱정할 필요가 없다. 하지만, +스토리지 프로비전 방식의 복잡성과 뉘앙스에 대해 걱정할 필요가 없다. 하지만, 여전히 여러 스토리지 옵션들을 선택할 수 있다. -스토리지 클래스에 대한 자세한 정보는 -[여기](/docs/concepts/storage/storage-classes/)에서 찾을 수 있다. +스토리지 클래스에 대한 자세한 정보는 +[여기](/ko/docs/concepts/storage/storage-classes/)에서 찾을 수 있다. ## 동적 프로비저닝 활성화하기 -동적 프로비저닝을 활성화하려면 클러스터 관리자가 사용자를 위해 하나 이상의 StorageClass +동적 프로비저닝을 활성화하려면 클러스터 관리자가 사용자를 위해 하나 이상의 스토리지클래스(StorageClass) 오브젝트를 사전 생성해야 한다. -StorageClass 오브젝트는 동적 프로비저닝이 호출될 때 사용할 프로비저너와 +스토리지클래스 오브젝트는 동적 프로비저닝이 호출될 때 사용할 프로비저너와 해당 프로비저너에게 전달할 파라미터를 정의한다. -StorageClass 오브젝트의 이름은 유효한 +스토리지클래스 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 다음 매니페스트는 표준 디스크와 같은 퍼시스턴트 디스크를 프로비전하는 @@ -117,7 +117,7 @@ spec: 작성하면, `DefaultStorageClass` 어드미션 컨트롤러가 디폴트 스토리지 클래스를 가리키는 `storageClassName` 필드를 자동으로 추가한다. -클러스터에는 최대 하나의 *default* 스토리지 클래스가 있을 수 있다. 그렇지 않은 경우 +클러스터에는 최대 하나의 *default* 스토리지 클래스가 있을 수 있다. 그렇지 않은 경우 `storageClassName` 을 명시적으로 지정하지 않은 `PersistentVolumeClaim` 을 생성할 수 없다. @@ -125,7 +125,6 @@ spec: [다중 영역](/ko/docs/setup/best-practices/multiple-zones/) 클러스터에서 파드는 한 지역 내 여러 영역에 걸쳐 분산될 수 있다. 파드가 예약된 영역에서 단일 영역 스토리지 백엔드를 -프로비전 해야 한다. [볼륨 바인딩 모드](/docs/concepts/storage/storage-classes/#volume-binding-mode)를 +프로비전해야 한다. [볼륨 바인딩 모드](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)를 설정해서 수행할 수 있다. - diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 397041842b..c345a472fe 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -22,7 +22,7 @@ weight: 20 스토리지 관리는 컴퓨트 인스턴스 관리와는 별개의 문제다. 퍼시스턴트볼륨 서브시스템은 사용자 및 관리자에게 스토리지 사용 방법에서부터 스토리지가 제공되는 방법에 대한 세부 사항을 추상화하는 API를 제공한다. 이를 위해 퍼시스턴트볼륨 및 퍼시스턴트볼륨클레임이라는 두 가지 새로운 API 리소스를 소개한다. -_퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리지 클래스](/docs/concepts/storage/storage-classes/)를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와는 별개의 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다. +_퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리지 클래스](/ko/docs/concepts/storage/storage-classes/)를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와는 별개의 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다. _퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: 한 번 읽기/쓰기 또는 여러 번 읽기 전용으로 마운트 할 수 있음). @@ -47,7 +47,7 @@ PV를 프로비저닝 할 수 있는 두 가지 방법이 있다: 정적(static) 관리자가 생성한 정적 PV가 사용자의 퍼시스턴트볼륨클레임과 일치하지 않으면 클러스터는 PVC를 위해 특별히 볼륨을 동적으로 프로비저닝 하려고 시도할 수 있다. 이 프로비저닝은 스토리지클래스를 기반으로 한다. PVC는 -[스토리지 클래스](/docs/concepts/storage/storage-classes/)를 +[스토리지 클래스](/ko/docs/concepts/storage/storage-classes/)를 요청해야 하며 관리자는 동적 프로비저닝이 발생하도록 해당 클래스를 생성하고 구성해야 한다. `""` 클래스를 요청하는 클레임은 동적 프로비저닝을 효과적으로 비활성화한다. @@ -244,7 +244,7 @@ FlexVolume의 크기 조정은 기본 드라이버가 크기 조정을 지원하 {{< /note >}} {{< note >}} -EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터(quota)가 있다. +EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터가 있다. {{< /note >}} @@ -376,7 +376,7 @@ CLI에서 접근 모드는 다음과 같이 약어로 표시된다. ### 클래스 PV는 `storageClassName` 속성을 -[스토리지클래스](/docs/concepts/storage/storage-classes/)의 +[스토리지클래스](/ko/docs/concepts/storage/storage-classes/)의 이름으로 설정하여 지정하는 클래스를 가질 수 있다. 특정 클래스의 PV는 해당 클래스를 요청하는 PVC에만 바인딩될 수 있다. `storageClassName`이 없는 PV에는 클래스가 없으며 특정 클래스를 요청하지 않는 PVC에만 @@ -449,8 +449,7 @@ CLI는 PV에 바인딩된 PVC의 이름을 표시한다. 각 PVC에는 스펙과 상태(클레임의 명세와 상태)가 포함된다. 퍼시스턴트볼륨클레임 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 -한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. ```yaml apiVersion: v1 @@ -496,7 +495,7 @@ spec: ### 클래스 클레임은 `storageClassName` 속성을 사용하여 -[스토리지클래스](/docs/concepts/storage/storage-classes/)의 이름을 지정하여 +[스토리지클래스](/ko/docs/concepts/storage/storage-classes/)의 이름을 지정하여 특정 클래스를 요청할 수 있다. 요청된 클래스의 PV(PVC와 동일한 `storageClassName`을 갖는 PV)만 PVC에 바인딩될 수 있다. @@ -747,7 +746,7 @@ spec: * [퍼시스턴트볼륨 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)에 대해 자세히 알아보기 * [퍼시스턴트볼륨클레임 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim)에 대해 자세히 알아보기 -* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽기 +* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽어보기 ### 참고 @@ -755,4 +754,3 @@ spec: * [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) * [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) * [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core) - diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index e73d886ef7..13b4f49175 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -162,8 +162,8 @@ CSI | 1.14 (alpha), 1.16 (beta) 클러스터 관리자는 `WaitForFirstConsumer` 모드를 지정해서 이 문제를 해결할 수 있는데 이 모드는 퍼시스턴트볼륨클레임을 사용하는 파드가 생성될 때까지 퍼시스턴트볼륨의 바인딩과 프로비저닝을 지연시킨다. 퍼시스턴트볼륨은 파드의 스케줄링 제약 조건에 의해 지정된 토폴로지에 -따라 선택되거나 프로비전된다. 여기에는 [리소스 -요구 사항](/docs/concepts/configuration/manage-compute-resources-container/), +따라 선택되거나 프로비전된다. 여기에는 +[리소스 요구 사항](/ko/docs/concepts/configuration/manage-resources-containers/), [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector), [파드 어피니티(affinity)와 안티-어피니티(anti-affinity)](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) @@ -816,4 +816,3 @@ volumeBindingMode: WaitForFirstConsumer 적절한 퍼시스턴트볼륨을 선택할 때 파드의 모든 스케줄링 제약 조건을 고려할 수 있다. - diff --git a/content/ko/docs/concepts/storage/volume-pvc-datasource.md b/content/ko/docs/concepts/storage/volume-pvc-datasource.md index 8b8e1b484f..e6ff2caa38 100644 --- a/content/ko/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ko/docs/concepts/storage/volume-pvc-datasource.md @@ -6,8 +6,7 @@ weight: 30 -이 문서에서는 쿠버네티스의 기존 CSI 볼륨 복제의 개념을 설명한다. [볼륨] -(/ko/docs/concepts/storage/volumes)을 숙지하는 것을 추천한다. +이 문서에서는 쿠버네티스의 기존 CSI 볼륨 복제의 개념을 설명한다. [볼륨](/ko/docs/concepts/storage/volumes)을 숙지하는 것을 추천한다. diff --git a/content/ko/docs/concepts/storage/volume-snapshot-classes.md b/content/ko/docs/concepts/storage/volume-snapshot-classes.md index 801ff624bb..cc31fae666 100644 --- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md @@ -7,8 +7,8 @@ weight: 30 이 문서는 쿠버네티스의 `VolumeSnapshotClass` 개요를 설명한다. -[볼륨 스냅샷](/docs/concepts/storage/volume-snapshots/)과 -[스토리지 클래스](/docs/concepts/storage/storage-classes)의 숙지를 추천한다. +[볼륨 스냅샷](/ko/docs/concepts/storage/volume-snapshots/)과 +[스토리지 클래스](/ko/docs/concepts/storage/storage-classes)의 숙지를 추천한다. @@ -32,7 +32,7 @@ weight: 30 처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하고, 오브젝트가 생성된 이후에는 업데이트할 수 없다. -관리자는 특정 클래스의 바인딩을 요청하지 않는 VolumeSnapshots에만 +관리자는 특정 클래스의 바인딩을 요청하지 않는 볼륨스냅샷에만 기본 `VolumeSnapshotClass` 를 지정할 수 있다. ```yaml @@ -40,14 +40,14 @@ apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshotClass metadata: name: csi-hostpath-snapclass -driver: hostpath.csi.k8s.io +driver: hostpath.csi.k8s.io deletionPolicy: Delete parameters: ``` ### 드라이버 -볼륨 스냅샷 클래스에는 VolumeSnapshots의 프로비저닝에 사용되는 CSI 볼륨 플러그인을 +볼륨 스냅샷 클래스에는 볼륨스냅샷의 프로비저닝에 사용되는 CSI 볼륨 플러그인을 결정하는 드라이버를 가지고 있다. 이 필드는 반드시 지정해야한다. ### 삭제정책(DeletionPolicy) @@ -61,5 +61,3 @@ parameters: 볼륨 스냅샷 클래스에는 볼륨 스냅샷 클래스에 속하는 볼륨 스냅샷을 설명하는 파라미터를 가지고 있다. `driver` 에 따라 다른 파라미터를 사용할 수 있다. - - diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index d2d85909e1..997f3d6fee 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -41,8 +41,7 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및 스냅샷을 프로비저닝할 수 있는 방법에는 사전 프로비저닝 혹은 동적 프로비저닝의 두 가지가 있다: . #### 사전 프로비전 {#static} -클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. -이것은 쿠버네티스 API에 있고 사용 가능하다. +클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. 이것은 쿠버네티스 API에 있고 사용 가능하다. #### 동적 사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로 가져오도록 요청할 수 있다. [볼륨스냅샷클래스](/docs/concepts/storage/volume-snapshot-classes/)는 스냅샷 사용 시 스토리지 제공자의 특정 파라미터를 명세한다. diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index a5a3e8aa23..b8ff826d67 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -451,15 +451,13 @@ spec: ``` #### 지역(Regional) 퍼시스턴트 디스크 -{{< feature-state for_k8s_version="v1.10" state="beta" >}} - [지역(Regional) 퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks/#repds) 기능을 사용하면 동일한 영역 내의 두 영역에서 사용할 수 있는 퍼시스턴트 디스크를 생성할 수 있다. 이 기능을 사용하려면 볼륨을 퍼시스턴트볼륨으로 프로비저닝 해야 한다. 파드에서 직접 볼륨을 참조하는 것은 지원되지 않는다. #### 지역(Regional) PD 퍼시스턴트볼륨을 수동으로 프로비저닝하기 -[GCE PD 용 StorageClass](/docs/concepts/storage/storage-classes/#gce) 를 사용해서 동적 프로비저닝이 가능하다. +[GCE PD용 스토리지클래스](/ko/docs/concepts/storage/storage-classes/#gce-pd)를 사용해서 동적 프로비저닝이 가능하다. PersistentVolume을 생성하기 전에 PD를 생성해야만 한다. ```shell -gcloud beta compute disks create --size=500GB my-data-disk +gcloud compute disks create --size=500GB my-data-disk --region us-central1 --replica-zones us-central1-a,us-central1-b ``` @@ -470,8 +468,6 @@ apiVersion: v1 kind: PersistentVolume metadata: name: test-volume - labels: - failure-domain.beta.kubernetes.io/zone: us-central1-a__us-central1-b spec: capacity: storage: 400Gi @@ -480,6 +476,15 @@ spec: gcePersistentDisk: pdName: my-data-disk fsType: ext4 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + - key: failure-domain.beta.kubernetes.io/zone + operator: In + values: + - us-central1-a + - us-central1-b ``` #### CSI 마이그레이션 @@ -574,12 +579,13 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드간에 데 다음과 같은 이유로 이 유형의 볼륨 사용시 주의해야 한다. * 동일한 구성(파드템플릿으로 생성한 것과 같은)을 - 가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있음 + 가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있다. * 쿠버네티스가 계획한 대로 리소스 인식 스케줄링을 추가하면 `hostPath` 에서 - 사용되는 리소스를 설명할 수 없음 -* 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다. 프로세스를 - [특권 컨테이너](/docs/user-guide/security-context) 에서 루트로 실행하거나 - `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 함 + 사용되는 리소스를 설명할 수 없다. +* 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다. + 프로세스를 [특권을 가진(privileged) 컨테이너](/docs/user-guide/security-context)에서 + 루트로 실행하거나 + `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 한다. #### 파드 예시 @@ -714,7 +720,7 @@ spec: 로컬 볼륨을 사용할 때는 `volumeBindingMode` 가 `WaitForFirstConsumer` 로 설정된 스토리지클래스(StorageClass)를 생성하는 것을 권장한다. -[예시](/docs/concepts/storage/storage-classes/#local)를 본다. 볼륨 바인딩을 지연시키는 것은 +[예시](/ko/docs/concepts/storage/storage-classes/#local)를 본다. 볼륨 바인딩을 지연시키는 것은 퍼시스턴트볼륨클래임 바인딩 결정도 노드 리소스 요구사항, 노드 셀렉터, 파드 어피니티 그리고 파드 안티 어피니티와 같이 파드가 가질 수 있는 다른 노드 제약 조건으로 평가되도록 만든다. @@ -1473,4 +1479,3 @@ sudo systemctl restart docker ## {{% heading "whatsnext" %}} * [퍼시스턴트 볼륨과 함께 워드프레스와 MySQL 배포하기](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)의 예시를 따른다. - diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index fa005e77a1..44590ccdfc 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -10,19 +10,20 @@ weight: 80 _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text="잡" >}}을 만든다. -하나의 크론잡 객체는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://en.wikipedia.org/wiki/Cron)형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. - +하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. +크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. {{< caution >}} 모든 **크론잡** `일정:` 시간은 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}의 시간대를 기준으로 한다. 컨트롤 플레인이 파드 또는 베어 컨테이너에서 kube-controller-manager를 실행하는 경우, -kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트롤러가 사용하는 시간대로 결정한다. +kube-controller-manager 컨테이너에 설정된 시간대는 +크론잡 컨트롤러가 사용하는 시간대로 결정한다. {{< /caution >}} -크론잡 리소스에 대한 매니페스트를 생성할때에는 제공하는 이름이 -유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +크론잡 리소스에 대한 매니페스트를 생성할 때에는 제공하는 이름이 +유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 이름은 52자 이하여야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에 11자를 자동으로 추가하고, 작업 이름의 최대 길이는 63자라는 제약 조건이 있기 때문이다. @@ -37,7 +38,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트 작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을 스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다. -### 예제 +### 예시 이 크론잡 매니페스트 예제는 현재 시간과 hello 메시지를 1분마다 출력한다. @@ -46,17 +47,17 @@ kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트 ([크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)는 이 예시를 더 자세히 설명한다.) -## 크론 잡의 한계 {#cron-job-limitations} +## 크론잡의 한계 {#cron-job-limitations} -크론 잡은 일정의 실행시간 마다 _약_ 한 번의 잡을 생성한다. "약" 이라고 하는 이유는 +크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는 특정 환경에서는 두 개의 잡이 만들어지거나, 잡이 생성되지 않기도 하기 때문이다. 보통 이렇게 하지 -않도록 해야겠지만, 완벽히 그럴 수 는 없다. 따라서 잡은 _멱등원_ 이 된다. +않도록 해야겠지만, 완벽히 그럴 수는 없다. 따라서 잡은 _멱등원_ 이 된다. 만약 `startingDeadlineSeconds` 가 큰 값으로 설정되거나, 설정되지 않고(디폴트 값), -`concurrencyPolicy` 가 `Allow`로 설정될 경우, 잡은 항상 적어도 한 번은 +`concurrencyPolicy` 가 `Allow` 로 설정될 경우, 잡은 항상 적어도 한 번은 실행될 것이다. -모든 크론 잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다. +모든 크론잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다. ```` Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. @@ -64,17 +65,17 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). 중요한 것은 만약 `startingDeadlineSeconds` 필드가 설정이 되면(`nil` 이 아닌 값으로), 컨트롤러는 마지막 일정부터 지금까지 대신 `startingDeadlineSeconds` 값에서 몇 개의 잡이 누락되었는지 카운팅한다. 예를 들면, `startingDeadlineSeconds` 가 `200` 이면, 컨트롤러는 최근 200초 내 몇 개의 잡이 누락되었는지 카운팅한다. -크론잡은 정해진 일정에 잡 실행을 실패하면 놓쳤다고 카운팅된다. 예를 들면, `concurrencyPolicy` 가 `Forbid` 로 설정되었고, 크론 잡이 이전 일정이 스케줄되어 여전히 시도하고 있을 때, 그 때 누락되었다고 판단한다. +크론잡은 정해진 일정에 잡 실행을 실패하면 놓쳤다고 카운팅된다. 예를 들면, `concurrencyPolicy` 가 `Forbid` 로 설정되었고, 크론잡이 이전 일정이 스케줄되어 여전히 시도하고 있을 때, 그 때 누락되었다고 판단한다. 즉, 크론잡이 `08:30:00` 에 시작하여 매 분마다 새로운 잡을 실행하도록 설정이 되었고, -`startingDeadlineSeconds` 값이 설정되어 있지 않는다고 가정해보자. 만약 크론 잡 컨트롤러가 +`startingDeadlineSeconds` 값이 설정되어 있지 않는다고 가정해보자. 만약 크론잡 컨트롤러가 `08:29:00` 부터 `10:21:00` 까지 고장이 나면, 일정을 놓친 작업 수가 100개를 초과하여 잡이 실행되지 않을 것이다. -이 개념을 더 자세히 설명하자면, 크론 잡이 `08:30:00` 부터 매 분 실행되는 일정으로 설정되고, -`startingDeadlineSeconds` 이 200이라고 가정한다. 크론 잡 컨트롤러가 -전의 예시와 같이 고장났다고 하면 (`08:29:00` 부터 `10:21:00` 까지), 잡은 10:22:00 부터 시작될 것이다. 이 경우, 컨트롤러가 마지막 일정부터 지금까지가 아니라, 최근 200초 안에 얼마나 놓쳤는지 체크하기 때문이다. (여기서는 3번 놓쳤다고 체크함) +이 개념을 더 자세히 설명하자면, 크론잡이 `08:30:00` 부터 매 분 실행되는 일정으로 설정되고, +`startingDeadlineSeconds` 이 200이라고 가정한다. 크론잡 컨트롤러가 +전의 예시와 같이 고장났다고 하면 (`08:29:00` 부터 `10:21:00` 까지), 잡은 10:22:00 부터 시작될 것이다. 이 경우, 컨트롤러가 마지막 일정부터 지금까지가 아니라, 최근 200초 안에 얼마나 놓쳤는지 체크하기 때문이다. (여기서는 3번 놓쳤다고 체크함) -크론 잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고, +크론잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고, 잡은 그 잡이 대표하는 파드 관리에 책임이 있다. @@ -83,7 +84,5 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). [크론 표현 포맷](https://ko.wikipedia.org/wiki/Cron)은 크론잡 `schedule` 필드의 포맷을 문서화 한다. -크론 잡 생성과 작업에 대한 지침과 크론잡 매니페스트의 -예는 [크론 잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다. - - +크론잡 생성과 작업에 대한 지침과 크론잡 매니페스트의 +예는 [크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다. diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index 83f3c428a3..5917eb288d 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -6,18 +6,18 @@ weight: 50 -_데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면 -파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로 +_데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면 +파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로 수집된다. 데몬셋을 삭제하면 데몬셋이 생성한 파드들이 정리된다. 데몬셋의 일부 대표적인 용도는 다음과 같다. -- 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행. -- 모든 노드에서 `fluentd` 또는 `filebeat` 와 같은 로그 수집 데몬의 실행. -- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 또는 [Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)와 같은 노드 모니터링 데몬의 실행. +- 모든 노드에서 클러스터 스토리지 데몬 실행 +- 모든 노드에서 로그 수집 데몬 실행 +- 모든 노드에서 노드 모니터링 데몬 실행 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다. -더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, +더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다. @@ -42,11 +42,12 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### 필수 필드 다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. -일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), +일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/user-guide/deploying-applications/), [컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다. 데몬셋 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. + 데몬셋에는 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 섹션도 필요하다. ### 파드 템플릿 @@ -55,7 +56,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml `.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확히 같은 스키마를 가진다. -데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야 +데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야 한다([파드 셀렉터](#파드-셀렉터)를 본다). 데몬셋의 파드 템플릿의 [`RestartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)는 `Always` 를 가져야 하며, @@ -63,7 +64,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### 파드 셀렉터 -`.spec.selector` 필드는 파드 셀렉터이다. 이것은 +`.spec.selector` 필드는 파드 셀렉터이다. 이것은 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)의 `.spec.selector` 와 같은 동작을 한다. 쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다. @@ -82,18 +83,18 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml 만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다. -또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로 -레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋 -{{< glossary_tooltip term_id="controller" >}} 는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을 -막지 못한다. 사용자가 이와 같은 일을 하게되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을 +또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로 +레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋 +{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을 +막지 못한다. 사용자가 이와 같은 일을 하게 되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을 수동으로 생성하는 것이다. ### 오직 일부 노드에서만 파드 실행 -만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는 -[노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와 -일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면 -데몬셋 컨트롤러는 [노트 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다. +만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는 +[노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와 +일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면 +데몬셋 컨트롤러는 [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다. 만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다. ## 데몬 파드가 스케줄 되는 방법 @@ -102,24 +103,24 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml {{< feature-state state="stable" for-kubernetes-version="1.17" >}} -데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로 -쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나 +데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로 +쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나 데몬셋 파드는 데몬셋 컨트롤러에 의해 생성되고 스케줄된다. 이에 대한 이슈를 소개한다. * 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다. 그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다. 이것은 사용자에게 혼란을 준다. - * [파드 선점](/docs/concepts/configuration/pod-priority-preemption/) - 은 기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는 + * [파드 선점](/ko/docs/concepts/configuration/pod-priority-preemption/)은 + 기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는 파드 우선순위와 선점을 고려하지 않고 스케줄 한다. -`ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신 -`NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본 -스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본 -스케줄러를 사용해서 대상 호스트에 파드를 바인딩 한다. 만약 데몬셋 파드에 -이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는 -데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며, +`ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신 +`NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본 +스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본 +스케줄러를 사용해서 대상 호스트에 파드를 바인딩한다. 만약 데몬셋 파드에 +이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는 +데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며, 데몬셋의 `spec.template` 은 변경되지 않는다. ```yaml @@ -133,29 +134,25 @@ nodeAffinity: - target-host-name ``` -또한, 데몬셋 파드에 `node.kubernetes.io/unschedulable:NoSchedule` 이 톨러레이션(toleration)으로 -자동으로 추가된다. 기본 스케줄러는 데몬셋 파드를 +또한, 데몬셋 파드에 `node.kubernetes.io/unschedulable:NoSchedule` 이 톨러레이션(toleration)으로 +자동으로 추가된다. 기본 스케줄러는 데몬셋 파드를 스케줄링시 `unschedulable` 노드를 무시한다. - ### 테인트(taints)와 톨러레이션(tolerations) -데몬 파드는 -[테인트와 톨러레이션](/docs/concepts/configuration/taint-and-toleration)을 존중하지만, -다음과 같이 관련 기능에 따라 자동적으로 데몬셋 파드에 +데몬 파드는 +[테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 존중하지만, +다음과 같이 관련 기능에 따라 자동적으로 데몬셋 파드에 톨러레이션을 추가한다. -| 톨러레이션 키 | 영향 | 버전 | 설명 | +| 톨러레이션 키 | 영향 | 버전 | 설명 | | ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ | -| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | -| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | -| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | -| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | -| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. | -| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. | - - - +| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | +| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | +| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. | +| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. | ## 데몬 파드와 통신 @@ -164,7 +161,7 @@ nodeAffinity: - **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록 구성되어있다. 그들은 클라이언트들을 가지지 않는다. - **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다. -- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고, +- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고, 그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를 검색한다. - **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서 @@ -172,58 +169,56 @@ nodeAffinity: ## 데몬셋 업데이트 -만약 노드 레이블이 변경되면, 데몬셋은 새로 일치하는 노드에 즉시 파드를 추가하고, 새로 +만약 노드 레이블이 변경되면, 데몬셋은 새로 일치하는 노드에 즉시 파드를 추가하고, 새로 일치하지 않는 노드에서 파드를 삭제한다. -사용자는 데몬셋이 생성하는 파드를 수정할 수 있다. 그러나 파드는 모든 -필드가 업데이트 되는 것을 허용하지 않는다. 또한 데몬셋 컨트롤러는 +사용자는 데몬셋이 생성하는 파드를 수정할 수 있다. 그러나 파드는 모든 +필드가 업데이트 되는 것을 허용하지 않는다. 또한 데몬셋 컨트롤러는 다음에 노드(동일한 이름으로)가 생성될 때 원본 템플릿을 사용한다. -사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=false` 를 명시하면 -파드는 노드에 남게 된다. 이후에 동일한 셀렉터로 새 데몬셋을 생성하면, -새 데몬셋은 기존 파드를 채택한다. 만약 파드를 교체해야 하는 경우 데몬셋은 +사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=false` 를 명시하면 +파드는 노드에 남게 된다. 이후에 동일한 셀렉터로 새 데몬셋을 생성하면, +새 데몬셋은 기존 파드를 채택한다. 만약 파드를 교체해야 하는 경우 데몬셋은 `updateStrategy` 에 따라 파드를 교체한다. -사용자는 데몬셋에서 [롤링 업데이트를 수행](/docs/tasks/manage-daemon/update-daemon-set/) 할 수 있다. +사용자는 데몬셋에서 [롤링 업데이트를 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)할 수 있다. ## 데몬셋의 대안 ### 초기화 스크립트 데몬 프로세스를 직접 노드에서 시작해서 실행하는 것도 당연히 가능하다. -(예: `init`, `upstartd` 또는 `systemd` 를 사용). 이 방법도 문제는 전혀 없다. 그러나 데몬셋을 통해 데몬 +(예: `init`, `upstartd` 또는 `systemd` 를 사용). 이 방법도 문제는 전혀 없다. 그러나 데몬셋을 통해 데몬 프로세스를 실행하면 몇 가지 이점 있다. - 애플리케이션과 동일한 방법으로 데몬을 모니터링하고 로그 관리를 할 수 있다. - 데몬 및 애플리케이션과 동일한 구성 언어와 도구(예: 파드 템플릿, `kubectl`). -- 리소스 제한이 있는 컨테이너에서 데몬을 실행하면 앱 컨테이너에서 +- 리소스 제한이 있는 컨테이너에서 데몬을 실행하면 앱 컨테이너에서 데몬간의 격리를 증가시킨다. 그러나 이것은 파드가 아닌 컨테이너에서 데몬을 실행해서 이루어진다 (예: 도커에서 직접적으로 시작). ### 베어(Bare) 파드 -직접적으로 파드를 실행할 특정한 노드를 명시해서 파드를 생성할 수 있다. 그러나 +직접적으로 파드를 실행할 특정한 노드를 명시해서 파드를 생성할 수 있다. 그러나 데몬셋은 노드 장애 또는 커널 업그레이드와 같이 변경사항이 많은 노드 유지보수의 경우를 비롯하여 -어떠한 이유로든 삭제되거나 종료된 파드를 교체한다. 따라서 개별 파드를 +어떠한 이유로든 삭제되거나 종료된 파드를 교체한다. 따라서 개별 파드를 생성하는 것보다는 데몬 셋을 사용해야 한다. ### 스태틱(static) 파드 -Kubelet이 감시하는 특정 디렉토리에 파일을 작성하는 파드를 생성할 수 있다. 이것을 -[스태틱 파드](/docs/tasks/configure-pod-container/static-pod/)라고 부른다. -데몬셋과는 다르게 스태틱 파드는 kubectl -또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다. 스태틱 파드는 API 서버에 의존하지 -않기 때문에 클러스터 부트스트랩(bootstraping)하는 경우에 유용하다. 또한 스태틱 파드는 향후에 사용 중단(deprecated)될 수 있다. +Kubelet이 감시하는 특정 디렉토리에 파일을 작성하는 파드를 생성할 수 있다. 이것을 +[스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)라고 부른다. +데몬셋과는 다르게 스태틱 파드는 kubectl +또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다. 스태틱 파드는 API 서버에 의존하지 +않기 때문에 클러스터 부트스트랩(bootstraping)하는 경우에 유용하다. 또한 스태틱 파드는 향후에 사용 중단될 수 있다. ### 디플로이먼트 -데몬셋은 파드를 생성한다는 점에서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 유사하고, -해당 파드에서는 프로세스가 종료되지 않을 것으로 +데몬셋은 파드를 생성한다는 점에서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 유사하고, +해당 파드에서는 프로세스가 종료되지 않을 것으로 예상한다(예: 웹 서버). -파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고, -업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의 -디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고, +파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고, +업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의 +디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고, 다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다. - - diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 96f41dc186..269d72f510 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -1,4 +1,6 @@ --- + + title: 디플로이먼트 feature: title: 자동화된 롤아웃과 롤백 @@ -11,7 +13,7 @@ weight: 30 -_디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 +_디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)에 대한 선언적 업데이트를 제공한다. 디플로이먼트에서 _의도하는 상태_ 를 설명하고, 디플로이먼트 {{< glossary_tooltip term_id="controller" >}} 는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다. @@ -53,16 +55,16 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 보다 정교한 선택 규칙의 적용이 가능하다. {{< note >}} - `.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된 - 단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, 키 필드는 "key"에 그리고 연산자는 "In"에 대응되며 + `.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된 + 단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, 키 필드는 "key"에 그리고 연산자는 "In"에 대응되며 값 배열은 "value"만 포함한다. 매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다. {{< /note >}} * `template` 필드에는 다음 하위 필드가 포함되어있다. * 파드는 `.metadata.labels` 필드를 사용해서 `app: nginx` 라는 레이블을 붙인다. - * 파드 템플릿의 사양 또는 `.template.spec` 필드는 - 파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.14.2 버전 이미지를 실행하는 + * 파드 템플릿의 사양 또는 `.template.spec` 필드는 + 파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.14.2 버전 이미지를 실행하는 `nginx` 컨테이너 1개를 실행하는 것을 나타낸다. * 컨테이너 1개를 생성하고, `.spec.template.spec.containers[0].name` 필드를 사용해서 `nginx` 이름을 붙인다. @@ -72,7 +74,6 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 1. 다음 명령어를 실행해서 디플로이먼트를 생성한다. - ```shell kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml ``` @@ -84,7 +85,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다. - + 만약 디플로이먼트가 여전히 생성 중이면, 다음과 유사하게 출력된다. ```shell NAME READY UP-TO-DATE AVAILABLE AGE @@ -145,7 +146,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 디플로이먼트에는 파드 템플릿 레이블과 적절한 셀렉터를 반드시 명시해야 한다 (이 예시에서는 `app: nginx`). -레이블 또는 셀렉터는 다른 컨트롤러(다른 디플로이먼트와 스테이트풀 셋 포함)와 겹치지 않아야 한다. 쿠버네티스는 겹치는 것을 막지 않으며, 만약 다중 컨트롤러가 겹치는 셀렉터를 가지는 경우 해당 컨트롤러의 충돌 또는 예기치 않은 동작을 야기할 수 있다. +레이블 또는 셀렉터는 다른 컨트롤러(다른 디플로이먼트와 스테이트풀셋(StatefulSet) 포함)와 겹치지 않아야 한다. 쿠버네티스는 겹치는 것을 막지 않으며, 만약 다중 컨트롤러가 겹치는 셀렉터를 가지는 경우 해당 컨트롤러의 충돌 또는 예기치 않은 동작을 야기할 수 있다. {{< /note >}} ### Pod-template-hash 레이블 @@ -156,13 +157,13 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml `pod-template-hash` 레이블은 디플로이먼트 컨트롤러에 의해서 디플로이먼트가 생성 또는 채택한 모든 레플리카셋에 추가된다. -이 레이블은 디플로이먼트의 자식 레플리카셋이 겹치지 않도록 보장한다. 레플리카셋의 `PodTemplate` 을 해싱하고, 해시 결과를 레플리카셋 셀렉터, +이 레이블은 디플로이먼트의 자식 레플리카셋이 겹치지 않도록 보장한다. 레플리카셋의 `PodTemplate` 을 해싱하고, 해시 결과를 레플리카셋 셀렉터, 파드 템플릿 레이블 및 레플리카셋 이 가질 수 있는 기존의 모든 파드에 레이블 값으로 추가해서 사용하도록 생성한다. ## 디플로이먼트 업데이트 {{< note >}} -디플로이먼트의 파드 템플릿(즉, `.spec.template`)이 변경된 경우에만 디플로이먼트의 롤아웃이 트리거(trigger) 된다. +디플로이먼트의 파드 템플릿(즉, `.spec.template`)이 변경된 경우에만 디플로이먼트의 롤아웃이 트리거(trigger) 된다. 예를 들면 템플릿의 레이블이나 컨테이너 이미지가 업데이트된 경우이다. 디플로이먼트의 스케일링과 같은 다른 업데이트는 롤아웃을 트리거하지 말아야 한다. {{< /note >}} @@ -219,7 +220,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml nginx-deployment 3/3 3 3 36s ``` -* `kubectl get rs` 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고, +* `kubectl get rs` 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고, 새 레플리카셋을 최대 3개의 레플리카로 스케일 업, 이전 레플리카셋을 0개의 레플리카로 스케일 다운한다. ```shell @@ -255,8 +256,8 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다. 기본적으로, 의도한 파드의 수 기준 최대 125%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지). - 예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음 - 이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, + 예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음 + 이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, 충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다. 이것은 최소 2개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다. @@ -264,7 +265,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml ```shell kubectl describe deployments ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` Name: nginx-deployment Namespace: default @@ -303,48 +304,48 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3 Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0 ``` - 처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성해서 + 처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성해서 3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다. - 디플로이먼트를 업데이트할 때 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 + 디플로이먼트를 업데이트할 때 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 이전 레플리카셋을 2개로 스케일 다운해서, 최소 2개의 파드를 사용할 수 있고 최대 4개의 파드가 항상 생성되어 있도록 하였다. 이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다. 마지막으로 새로운 레플리카셋에 3개의 사용 가능한 레플리카가 구성되며, 이전 레플리카셋은 0개로 스케일 다운된다. ### 롤오버(일명 인-플라이트 다중 업데이트) -디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이 -의도한 파드를 생성하고 띄우는 것을 주시한다. 만약 디플로이먼트가 업데이트되면, 기존 레플리카셋에서 +디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이 +의도한 파드를 생성하고 띄우는 것을 주시한다. 만약 디플로이먼트가 업데이트되면, 기존 레플리카셋에서 `.spec.selector` 레이블과 일치하는 파드를 컨트롤 하지만, 템플릿과 `.spec.template` 이 불일치하면 스케일 다운이 된다. 결국 새로운 레플리카셋은 `.spec.replicas` 로 스케일되고, 모든 기존 레플리카 셋은 0개로 스케일된다. -만약 기존 롤아웃이 진행되는 중에 디플로이먼트를 업데이트하는 경우 디플로이먼트가 업데이트에 따라 새 레플리카셋을 생성하고, +만약 기존 롤아웃이 진행되는 중에 디플로이먼트를 업데이트하는 경우 디플로이먼트가 업데이트에 따라 새 레플리카셋을 생성하고, 스케일 업하기 시작한다. 그리고 이전에 스케일 업 하던 레플리카셋에 롤오버 한다. --이것은 기존 레플리카셋 목록에 추가하고 스케일 다운을 할 것이다. 예를 들어 디플로이먼트로 `nginx:1.14.2` 레플리카를 5개 생성을 한다. -하지만 `nginx:1.14.2` 레플리카 3개가 생성되었을 때 디플로이먼트를 업데이트해서 `nginx:1.16.1` -레플리카 5개를 생성성하도록 업데이트를 한다고 가정한다. 이 경우 디플로이먼트는 즉시 생성된 3개의 -`nginx:1.14.2` 파드 3개를 죽이기 시작하고 `nginx:1.16.1` 파드를 생성하기 시작한다. -이것은 과정이 변경되기 전 `nginx:1.14.2` 레플리카 5개가 +하지만 `nginx:1.14.2` 레플리카 3개가 생성되었을 때 디플로이먼트를 업데이트해서 `nginx:1.16.1` +레플리카 5개를 생성성하도록 업데이트를 한다고 가정한다. 이 경우 디플로이먼트는 즉시 생성된 3개의 +`nginx:1.14.2` 파드 3개를 죽이기 시작하고 `nginx:1.16.1` 파드를 생성하기 시작한다. +이것은 과정이 변경되기 전 `nginx:1.14.2` 레플리카 5개가 생성되는 것을 기다리지 않는다. ### 레이블 셀렉터 업데이트 일반적으로 레이블 셀렉터를 업데이트 하는 것을 권장하지 않으며 셀렉터를 미리 계획하는 것을 권장한다. -어떤 경우든 레이블 셀렉터의 업데이트를 해야하는 경우 매우 주의하고, +어떤 경우든 레이블 셀렉터의 업데이트를 해야하는 경우 매우 주의하고, 모든 영향을 파악했는지 확인해야 한다. {{< note >}} API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 이후에는 변경할 수 없다. {{< /note >}} -* 셀렉터 추가 시 디플로이먼트의 사양에 있는 파드 템플릿 레이블도 새 레이블로 업데이트 해야한다. -그렇지 않으면 유효성 검사 오류가 반환된다. 이 변경은 겹치지 않는 변경으로 새 셀렉터가 -이전 셀렉터로 만든 레플리카셋과 파드를 선택하지 않게 되고, 그 결과로 모든 기존 레플리카셋은 고아가 되며, +* 셀렉터 추가 시 디플로이먼트의 사양에 있는 파드 템플릿 레이블도 새 레이블로 업데이트 해야한다. +그렇지 않으면 유효성 검사 오류가 반환된다. 이 변경은 겹치지 않는 변경으로 새 셀렉터가 +이전 셀렉터로 만든 레플리카셋과 파드를 선택하지 않게 되고, 그 결과로 모든 기존 레플리카셋은 고아가 되며, 새로운 레플리카셋을 생성하게 된다. * 셀렉터 업데이트는 기존 셀렉터 키 값을 변경하며, 결과적으로 추가와 동일한 동작을 한다. * 셀렉터 삭제는 디플로이먼트 셀렉터의 기존 키를 삭제하며 파드 템플릿 레이블의 변경을 필요로 하지 않는다. -기존 레플리카셋은 고아가 아니고, 새 레플리카셋은 생성되지 않는다. +기존 레플리카셋은 고아가 아니고, 새 레플리카셋은 생성되지 않는다. 그러나 제거된 레이블은 기존 파드와 레플리카셋에 여전히 존재한다는 점을 참고해야 한다. ## 디플로이먼트 롤백 @@ -354,11 +355,11 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 (이 사항은 수정 기록에 대한 상한 수정을 통해서 변경할 수 있다). {{< note >}} -디플로이먼트의 수정 버전은 디플로이먼트 롤아웃시 생성된다. 이는 디플로이먼트 파드 템플릿 -(`.spec.template`)이 변경되는 경우에만 새로운 수정 버전이 생성된다는 것을 의미한다. +디플로이먼트의 수정 버전은 디플로이먼트 롤아웃시 생성된다. 이는 디플로이먼트 파드 템플릿 +(`.spec.template`)이 변경되는 경우에만 새로운 수정 버전이 생성된다는 것을 의미한다. 예를 들어 템플릿의 레이블 또는 컨테이너 이미지를 업데이트 하는 경우. 디플로이먼트의 스케일링과 같은 다른 업데이트시 디플로이먼트 수정 버전은 생성되지 않으며 수동-스케일링 또는 자동-스케일링을 동시에 수행할 수 있다. -이는 이전 수정 버전으로 롤백을 하는 경우에 디플로이먼트 파드 템플릿 부분만 +이는 이전 수정 버전으로 롤백을 하는 경우에 디플로이먼트 파드 템플릿 부분만 롤백된다는 것을 의미한다. {{< /note >}} @@ -385,7 +386,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 Waiting for rollout to finish: 1 out of 3 new replicas have been updated... ``` -* Ctrl-C 를 눌러 위의 롤아웃 상태 보기를 중지한다. 고착된 롤아웃 상태에 대한 자세한 정보는 [이 것을 더 읽어본다](#디플로이먼트-상태). +* Ctrl-C 를 눌러 위의 롤아웃 상태 보기를 중지한다. 고착된 롤아웃 상태에 대한 자세한 정보는 [이 것을 더 읽어본다](#디플로이먼트-상태). * 이전 레플리카는 2개(`nginx-deployment-1564180365` 과 `nginx-deployment-2035384211`), 새 레플리카는 1개(nginx-deployment-3066724191)임을 알 수 있다. @@ -425,7 +426,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl describe deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` Name: nginx-deployment Namespace: default @@ -476,7 +477,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 ```shell kubectl rollout history deployment.v1.apps/nginx-deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` deployments "nginx-deployment" REVISION CHANGE-CAUSE @@ -496,7 +497,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2 ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` deployments "nginx-deployment" revision 2 Labels: app=nginx @@ -521,7 +522,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl rollout undo deployment.v1.apps/nginx-deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` deployment.apps/nginx-deployment rolled back ``` @@ -531,14 +532,14 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2 ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` deployment.apps/nginx-deployment rolled back ``` 롤아웃 관련 명령에 대한 자세한 내용은 [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)을 참조한다. - 이제 디플로이먼트가 이전 안정 수정 버전으로 롤백 된다. 버전 2로 롤백하기 위해 `DeploymentRollback` 이벤트가 + 이제 디플로이먼트가 이전 안정 수정 버전으로 롤백 된다. 버전 2로 롤백하기 위해 `DeploymentRollback` 이벤트가 디플로이먼트 컨트롤러에서 생성되는 것을 볼 수 있다. 2. 만약 롤백에 성공하고, 디플로이먼트가 예상대로 실행되는지 확인하려면 다음을 실행한다. @@ -546,7 +547,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl get deployment nginx-deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 30m @@ -555,7 +556,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 ```shell kubectl describe deployment nginx-deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` Name: nginx-deployment Namespace: default @@ -613,7 +614,7 @@ deployment.apps/nginx-deployment scaled ``` 가령 클러스터에서 [horizontal Pod autoscaling](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)를 설정 -한 경우 디플로이먼트에 대한 오토스케일러를 설정할 수 있다. 그리고 기존 파드의 CPU 사용률을 기준으로 +한 경우 디플로이먼트에 대한 오토스케일러를 설정할 수 있다. 그리고 기존 파드의 CPU 사용률을 기준으로 실행할 최소 파드 및 최대 파드의 수를 선택할 수 있다. ```shell @@ -627,7 +628,7 @@ deployment.apps/nginx-deployment scaled ### 비례적 스케일링(Proportional Scaling) 디플로이먼트 롤링업데이트는 여러 버전의 애플리케이션을 동시에 실행할 수 있도록 지원한다. -사용자 또는 오토스케일러가 롤아웃 중에 있는 디플로이먼트 롤링 업데이트를 스케일링 하는 경우(진행중 또는 일시 중지 중), +사용자 또는 오토스케일러가 롤아웃 중에 있는 디플로이먼트 롤링 업데이트를 스케일링 하는 경우(진행중 또는 일시 중지 중), 디플로이먼트 컨트롤러는 위험을 줄이기 위해 기존 활성화된 레플리카셋(파드와 레플리카셋)의 추가 레플리카의 균형을 조절 한다. 이것을 *proportional scaling* 라 부른다. @@ -654,7 +655,7 @@ deployment.apps/nginx-deployment scaled deployment.apps/nginx-deployment image updated ``` -* 이미지 업데이트는 레플리카셋 nginx-deployment-1989198191 으로 새로운 롤 아웃이 시작하지만, +* 이미지 업데이트는 레플리카셋 nginx-deployment-1989198191 으로 새로운 롤 아웃이 시작하지만, 위에서 언급한 `maxUnavailable` 의 요구 사항으로 인해 차단된다. 롤아웃 상태를 확인한다. ```shell kubectl get rs @@ -674,14 +675,14 @@ deployment.apps/nginx-deployment scaled 남은 것들은 대부분의 레플리카가 있는 레플리카셋에 추가된다. 0개의 레플리카가 있는 레플리카셋은 스케일 업 되지 않는다. 위의 예시에서 기존 레플리카셋에 3개의 레플리카가 추가되고, 2개의 레플리카는 새 레플리카에 추가된다. -결국 롤아웃 프로세스는 새 레플리카가 정상이라고 가정하면 모든 레플리카를 새 레플리카셋으로 이동시킨다. +결국 롤아웃 프로세스는 새 레플리카가 정상이라고 가정하면 모든 레플리카를 새 레플리카셋으로 이동시킨다. 이를 확인하려면 다음을 실행한다. ```shell kubectl get deploy ``` -이와 유사하게 출력된다. +이와 유사하게 출력된다. ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 15 18 7 8 7m @@ -845,7 +846,7 @@ nginx-deployment-618515232 11 11 11 7m 쿠버네티스는 다음과 같은 특성을 가지게 되면 디플로이먼트를 _완료_ 로 표시한다. -* 디플로이먼트과 관련된 모든 레플리카가 지정된 최신 버전으로 업데이트 되었을 때. +* 디플로이먼트과 관련된 모든 레플리카가 지정된 최신 버전으로 업데이트 되었을 때. 즉, 요청한 모든 업데이트가 완료되었을 때. * 디플로이먼트와 관련한 모든 레플리카를 사용할 수 있을 때. * 디플로이먼트에 대해 이전 복제본이 실행되고 있지 않을 때. @@ -877,11 +878,11 @@ $ echo $? * 애플리케이션 런타임의 잘못된 구성 이 조건을 찾을 수 있는 한 가지 방법은 디플로이먼트 스펙에서 데드라인 파라미터를 지정하는 것이다 -([`.spec.progressDeadlineSeconds`](#진행-기한-시간-초)). `.spec.progressDeadlineSeconds` 는 -(디플로이먼트 상태에서) 디플로이먼트의 진행이 정지되었음을 나타내는 디플로이먼트 컨트롤러가 +([`.spec.progressDeadlineSeconds`](#진행-기한-시간-초)). `.spec.progressDeadlineSeconds` 는 +(디플로이먼트 상태에서) 디플로이먼트의 진행이 정지되었음을 나타내는 디플로이먼트 컨트롤러가 대기하는 시간(초)를 나타낸다. -다음 `kubectl` 명령어로 `progressDeadlineSeconds` 를 설정해서 컨트롤러가 +다음 `kubectl` 명령어로 `progressDeadlineSeconds` 를 설정해서 컨트롤러가 10분 후 디플로이먼트에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다. ```shell @@ -891,7 +892,7 @@ kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadline ``` deployment.apps/nginx-deployment patched ``` -만약 데드라인을 넘어서면 디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions` 속성에 다음의 +만약 데드라인을 넘어서면 디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions` 속성에 다음의 디플로이먼트 컨디션(DeploymentCondition)을 추가한다. * Type=Progressing @@ -901,14 +902,14 @@ deployment.apps/nginx-deployment patched 컨디션 상태에 대한 자세한 내용은 [쿠버네티스 API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties)을 참고한다. {{< note >}} -쿠버네티스는 `Reason=ProgressDeadlineExceeded` 과 같은 상태 조건을 -보고하는 것 이외에 정지된 디플로이먼트에 대해 조치를 취하지 않는다. 더 높은 수준의 오케스트레이터는 이를 활용할 수 있으며, +쿠버네티스는 `Reason=ProgressDeadlineExceeded` 과 같은 상태 조건을 +보고하는 것 이외에 정지된 디플로이먼트에 대해 조치를 취하지 않는다. 더 높은 수준의 오케스트레이터는 이를 활용할 수 있으며, 예를 들어 디플로이먼트를 이전 버전으로 롤백할 수 있다. {{< /note >}} {{< note >}} 만약 디플로이먼트를 일시 중지하면 쿠버네티스는 지정된 데드라인과 비교하여 진행 상황을 확인하지 않는다. -롤아웃 중에 디플로이먼트를 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고 +롤아웃 중에 디플로이먼트를 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고 재개할 수 있다. {{< /note >}} @@ -961,7 +962,7 @@ status: unavailableReplicas: 2 ``` -결국, 디플로이먼트 진행 데드라인을 넘어서면, 쿠버네티스는 진행 컨디션의 +결국, 디플로이먼트 진행 데드라인을 넘어서면, 쿠버네티스는 진행 컨디션의 상태와 이유를 업데이트한다. ``` @@ -973,9 +974,9 @@ Conditions: ReplicaFailure True FailedCreate ``` -디플로이먼트를 스케일 다운하거나, 실행 중인 다른 컨트롤러를 스케일 다운하거나, +디플로이먼트를 스케일 다운하거나, 실행 중인 다른 컨트롤러를 스케일 다운하거나, 네임스페이스에서 할당량을 늘려서 할당량이 부족한 문제를 해결할 수 있다. -만약 할당량 컨디션과 디플로이먼트 롤아웃이 완료되어 디플로이먼트 컨트롤러를 만족한다면 +만약 할당량 컨디션과 디플로이먼트 롤아웃이 완료되어 디플로이먼트 컨트롤러를 만족한다면 성공한 컨디션의 디플로이먼트 상태가 업데이트를 볼 수 있다(`Status=True` 와 `Reason=NewReplicaSetAvailable`). ``` @@ -987,9 +988,9 @@ Conditions: ``` `Type=Available` 과 `Status=True` 는 디플로이먼트가 최소한의 가용성을 가지고 있는 것을 의미한다. -최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다. `Type=Progressing` 과 `Status=True` 는 디플로이먼트가 +최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다. `Type=Progressing` 과 `Status=True` 는 디플로이먼트가 롤아웃 도중에 진행 중 이거나, 성공적으로 완료되었으며, 진행 중 최소한으로 필요한 새로운 레플리카를 이용 가능하다는 것이다. -(자세한 내용은 특정 조건의 이유를 참조한다. +(자세한 내용은 특정 조건의 이유를 참조한다. 이 경우 `Reason=NewReplicaSetAvailable` 는 배포가 완료되었음을 의미한다.) `kubectl rollout status` 를 사용해서 디플로이먼트의 진행이 실패되었는지 확인할 수 있다. @@ -1013,7 +1014,7 @@ $ echo $? ## 정책 초기화 -디플로이먼트의 `.spec.revisionHistoryLimit` 필드를 설정해서 +디플로이먼트의 `.spec.revisionHistoryLimit` 필드를 설정해서 디플로이먼트에서 유지해야 하는 이전 레플리카셋의 수를 명시할 수 있다. 나머지는 백그라운드에서 가비지-수집이 진행된다. 기본적으로 10으로 되어있다. @@ -1024,14 +1025,14 @@ $ echo $? ## 카나리 디플로이먼트 -만약 디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리즈를 롤아웃 하기 위해서는 -[리소스 관리](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)에 +만약 디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리즈를 롤아웃 하기 위해서는 +[리소스 관리](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)에 설명된 카나리 패던에 따라 각 릴리스 마다 하나씩 여러 디플로이먼트를 생성할 수 있다. ## 디플로이먼트 사양 작성 다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `.apiVersion`, `.kind` 그리고 `.metadata` 필드가 필요하다. -설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/), +설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/), 컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다. 디플로이먼트 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. @@ -1048,7 +1049,7 @@ $ echo $? 파드에 필요한 필드 외에 디플로이먼트 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 명시해야 한다. 레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야한다. 자세한 것은 [셀렉터](#셀렉터)를 참조한다. -[`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 에는 오직 `Always` 만 허용되고, +[`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 에는 오직 `Always` 만 허용되고, 명시되지 않으면 기본값이 된다. ### 레플리카 @@ -1057,15 +1058,14 @@ $ echo $? ### 셀렉터 -`.spec.selector` 는 디플로이먼트의 대상이 되는 파드에 대해 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 +`.spec.selector` 는 디플로이먼트의 대상이 되는 파드에 대해 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 지정하는 필수 필드이다. `.spec.selector` 는 `.spec.template.metadata.labels` 과 일치해야 하며, 그렇지 않으면 API에 의해 거부된다. API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설정되지 않으면 `.spec.template.metadata.labels` 은 기본 설정되지 않는다. 그래서 이것들은 명시적으로 설정되어야 한다. 또한 `apps/v1` 에서는 디플로이먼트를 생성한 후에는 `.spec.selector` 이 변경되지 않는 점을 참고한다. - -디플로이먼트는 템플릿의 `.spec.template` 와 다르거나 파드의 수가 `.spec.replicas` 를 초과할 경우 +디플로이먼트는 템플릿의 `.spec.template` 와 다르거나 파드의 수가 `.spec.replicas` 를 초과할 경우 셀렉터와 일치하는 레이블을 가진 파드를 종료할 수 있다. 파드의 수가 의도한 수량보다 적을 경우 `.spec.template` 에 맞는 새 파드를 띄운다. @@ -1075,7 +1075,7 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 쿠버네티스는 이 일을 막지 않는다. {{< /note >}} -만약 셀렉터가 겹치는 컨트롤러가 어러 개 있는 경우, 컨트롤러는 서로 싸우고 +만약 셀렉터가 겹치는 컨트롤러가 어러 개 있는 경우, 컨트롤러는 서로 싸우고 올바르게 작동하지 않는다. ### 전략 @@ -1099,8 +1099,8 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 #### 디플로이먼트 롤링 업데이트 -디플로이먼트는 `.spec.strategy.type==RollingUpdate` 이면 파드를 롤링 업데이트 -방식으로 업데이트 한다. `maxUnavailable` 와 `maxSurge` 를 명시해서 +디플로이먼트는 `.spec.strategy.type==RollingUpdate` 이면 파드를 롤링 업데이트 +방식으로 업데이트 한다. `maxUnavailable` 와 `maxSurge` 를 명시해서 롤링 업데이트 프로세스를 제어할 수 있다. ##### 최대 불가(Max Unavailable) @@ -1110,9 +1110,10 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 절대 값은 반올림해서 백분율로 계산한다. 만약 `.spec.strategy.rollingUpdate.maxSurge` 가 0이면 값이 0이 될 수 없다. 기본 값은 25% 이다. -예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 즉각 이전 레플리카셋의 크기를 -의도한 파드 중 70%를 스케일 다운할 수 있다. 새 파드가 준비되면 기존 레플리카셋을 스케일 다운할 수 있으며, -업데이트 중에 항상 사용가능한 전체 파드의 수는 의도한 파드의 수의 70%이상이 되도록 새 레플리카셋을 스케일을 업 할수 있다. +예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 즉각 이전 레플리카셋의 크기를 +의도한 파드 중 70%를 스케일 다운할 수 있다. 새 파드가 준비되면 기존 레플리카셋을 스케일 다운할 수 있으며, +업데이트 중에 항상 사용 가능한 전체 파드의 수는 +의도한 파드의 수의 70% 이상이 되도록 새 레플리카셋을 스케일 업할 수 있다. ##### 최대 서지(Max Surge) @@ -1121,18 +1122,18 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 `MaxUnavailable` 값이 0이면 이 값은 0이 될 수 없다. 절대 값은 반올림해서 백분율로 계산한다. 기본 값은 25% 이다. -예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 새 레플리카셋의 크기를 즉시 조정해서 +예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 새 레플리카셋의 크기를 즉시 조정해서 기존 및 새 파드의 전체 갯수를 의도한 파드의 130%를 넘지 않도록 한다. -기존 파드가 죽으면 새로운 래플리카셋은 스케일 업할 수 있으며, +기존 파드가 죽으면 새로운 래플리카셋은 스케일 업할 수 있으며, 업데이트하는 동안 항상 실행하는 총 파드의 수는 최대 의도한 파드의 수의 130%가 되도록 보장한다. ### 진행 기한 시간(초) -`.spec.progressDeadlineSeconds` 는 디플로어먼트가 표면적으로 `Type=Progressing`, `Status=False`의 -상태 그리고 리소스가 `Reason=ProgressDeadlineExceeded` 상태로 [진행 실패](#디플로이먼트-실패)를 보고하기 전에 +`.spec.progressDeadlineSeconds` 는 디플로어먼트가 표면적으로 `Type=Progressing`, `Status=False`의 +상태 그리고 리소스가 `Reason=ProgressDeadlineExceeded` 상태로 [진행 실패](#디플로이먼트-실패)를 보고하기 전에 디플로이먼트가 진행되는 것을 대기시키는 시간(초)를 명시하는 선택적 필드이다. 디플로이먼트 컨트롤러는 디플로이먼트를 계속 재시도 한다. 기본값은 600(초)이다. -미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤러는 상태를 관찰하고, +미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤러는 상태를 관찰하고, 그 즉시 디플로이먼트를 롤백할 것이다. 만약 명시된다면 이 필드는 `.spec.minReadySeconds` 보다 커야 한다. @@ -1153,7 +1154,7 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 디플로이먼트의 수정 버전 기록은 자신이 컨트롤하는 레플리카셋에 저장된다. `.spec.revisionHistoryLimit` 은 롤백을 허용하기 위해 보존할 이전 레플리카셋의 수를 지정하는 선택적 필드이다. -이 이전 레플리카셋은 `etcd` 의 리소스를 소비하고, `kubectl get rs` 의 결과를 가득차게 만든다. 각 디플로이먼트의 구성은 디플로이먼트의 레플리카셋에 저장된다. 이전 레플리카셋이 삭제되면 해당 디플로이먼트 수정 버전으로 롤백할 수 있는 기능이 사라진다. 기본적으로 10개의 기존 레플리카셋이 유지되지만 이상적인 값은 새로운 디플로이먼트의 빈도와 안정성에 따라 달라진다. +이 이전 레플리카셋은 `etcd` 의 리소스를 소비하고, `kubectl get rs` 의 결과를 가득차게 만든다. 각 디플로이먼트의 구성은 디플로이먼트의 레플리카셋에 저장된다. 이전 레플리카셋이 삭제되면 해당 디플로이먼트 수정 버전으로 롤백할 수 있는 기능이 사라진다. 기본적으로 10개의 기존 레플리카셋이 유지되지만 이상적인 값은 새로운 디플로이먼트의 빈도와 안정성에 따라 달라진다. 더욱 구체적으로 이 필드를 0으로 설정하면 레플리카가 0이 되며 이전 레플리카셋이 정리된다. 이 경우, 새로운 디플로이먼트 롤아웃을 취소할 수 없다. 새로운 디플로이먼트 롤아웃은 수정 버전 이력이 정리되기 때문이다. @@ -1161,8 +1162,6 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 ### 일시 정지 `.spec.paused` 는 디플로이먼트를 일시 중지나 재개하기 위한 선택적 부울 필드이다. -일시 중지 된 디플로이먼트와 일시 중지 되지 않은 디플로이먼트 사이의 유일한 차이점은 +일시 중지 된 디플로이먼트와 일시 중지 되지 않은 디플로이먼트 사이의 유일한 차이점은 일시 중지된 디플로이먼트는 PodTemplateSpec에 대한 변경 사항이 일시중지 된 경우 새 롤아웃을 트리거 하지 않는다. 디플로이먼트는 생성시 기본적으로 일시 중지되지 않는다. - - diff --git a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md index f819614a6c..4f4762fe9d 100644 --- a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md @@ -22,7 +22,7 @@ weight: 60 필드를 가지고 있다. 때때로, 쿠버네티스는 `ownerReference` 값을 자동적으로 설정한다. -예를 들어 레플리카셋을 만들 때 쿠버네티스는 레플리카셋에 있는 각 파드의 +예를 들어 레플리카셋을 만들 때 쿠버네티스는 레플리카셋에 있는 각 파드의 `ownerReference` 필드를 자동으로 설정한다. 1.8 에서는 쿠버네티스가 레플리케이션컨트롤러, 레플리카셋, 스테이트풀셋, 데몬셋, 디플로이먼트, 잡 그리고 크론잡에 의해서 생성되거나 차용된 오브젝트의 `ownerReference` 값을 @@ -35,7 +35,7 @@ weight: 60 {{< codenew file="controllers/replicaset.yaml" >}} -레플리카셋을 생성하고 파드의 메타데이터를 본다면, +레플리카셋을 생성하고 파드의 메타데이터를 본다면, OwnerReferences 필드를 찾을 수 있다. ```shell @@ -72,7 +72,7 @@ metadata: 오브젝트를 삭제할 때, 오브젝트의 종속 항목을 자동으로 삭제하는지의 여부를 지정할 수 있다. 종속 항목을 자동으로 삭제하는 것을 *캐스케이딩(cascading) -삭제* 라고 한다. *캐스케이딩 삭제* 에는 *백그라운드* 와 *포어그라운드* 2가지 모드가 있다. +삭제* 라고 한다. *캐스케이딩 삭제* 에는 *백그라운드* 와 *포어그라운드* 2가지 모드가 있다. 만약 종속 항목을 자동으로 삭제하지 않고 오브젝트를 삭제한다면, 종속 항목은 *분리됨(orphaned)* 이라고 한다. @@ -147,8 +147,8 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep ``` kubectl도 캐스케이딩 삭제를 지원한다. -kubectl을 사용해서 종속 항목을 자동으로 삭제하려면 `--cascade` 를 true로 설정한다. 종속 항목을 -분리하기 위해서는 `--cascase` 를 false로 설정한다. `--cascade` 의 기본값은 +kubectl을 사용해서 종속 항목을 자동으로 삭제하려면 `--cascade` 를 true로 설정한다. 종속 항목을 +분리하기 위해서는 `--cascade` 를 false로 설정한다. `--cascade` 의 기본값은 true 이다. 여기에 레플리카셋의 종속 항목을 분리로 만드는 예시가 있다. @@ -181,3 +181,4 @@ kubectl delete replicaset my-repset --cascade=false + diff --git a/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md index 4d6e93ded5..f203befbad 100644 --- a/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md +++ b/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md @@ -111,7 +111,7 @@ kubectl logs $pods ## 잡 사양 작성하기 다른 쿠버네티스의 설정과 마찬가지로 잡에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. -잡의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +잡의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 잡에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다. @@ -175,8 +175,8 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 - _고정적인 완료 횟수(fixed completion count)_ 잡의 경우, 병렬로 실행 중인 파드의 수는 남은 완료 수를 초과하지 않는다. `.spec.parallelism` 의 더 큰 값은 사실상 무시된다. - _작업 큐_ 잡은 파드가 성공한 이후에 새로운 파드가 시작되지 않는다. 그러나 나머지 파드는 완료될 수 있다. -- 만약 잡 {{< glossary_tooltip term_id="controller" >}} 가 반응할 시간이 없는 경우 -- 만약 잡 컨트롤러가 어떤 이유(`리소스 쿼터` 의 부족, 권한 부족 등)로든 파드 생성에 실패한 경우, +- 만약 잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 가 반응할 시간이 없는 경우 +- 만약 잡 컨트롤러가 어떤 이유(`ResourceQuota` 의 부족, 권한 부족 등)로든 파드 생성에 실패한 경우, 요청한 것보다 적은 수의 파드가 있을 수 있다. - 잡 컨트롤러는 동일한 잡에서 과도하게 실패한 이전 파드들로 인해 새로운 파드의 생성을 조절할 수 있다. - 파드가 정상적으로(gracefully) 종료되면, 중지하는데 시간이 소요된다. @@ -327,7 +327,7 @@ spec: 여기에는 전송할 이메일들, 렌더링할 프레임, 코드 변환이 필요한 파일, NoSQL 데이터베이스에서의 키 범위 스캔 등이 있다. -복잡한 시스템에는 여러개의 다른 작업 항목 집합이 있을 수 있다. 여기서는 사용자와 +복잡한 시스템에는 여러 개의 다른 작업 항목 집합이 있을 수 있다. 여기서는 사용자와 함께 관리하려는 하나의 작업 항목 집합 — *배치 잡* 을 고려하고 있다. 병렬 계산에는 몇몇 다른 패턴이 있으며 각각의 장단점이 있다. @@ -471,8 +471,6 @@ spec: 이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도, 파드 생성과 작업 할당 방법을 완전히 제어하고 유지한다는 것이다. -## 크론 잡 {#cron-jobs} - -[`크론잡`](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 사용해서 Unix 도구인 `cron`과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다. - +## 크론잡 {#cron-jobs} +[`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 사용해서 Unix 도구인 `cron`과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다. diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index 16146a45b6..7f78c8d6f0 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -13,10 +13,10 @@ weight: 20 {{< note >}} -[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다. +[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/)을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/)가 현재 권장하는 레플리케이션 설정 방법이다. {{< /note >}} -_레플리케이션 컨트롤러_ 는 언제든지 지정된 수의 파드 레플리카가 +_레플리케이션컨트롤러_ 는 언제든지 지정된 수의 파드 레플리카가 실행 중임을 보장한다. 다시 말하면, 레플리케이션 컨트롤러는 파드 또는 동일 종류의 파드의 셋이 항상 기동되고 사용 가능한지 확인한다. @@ -105,8 +105,8 @@ echo $pods nginx-3ntk0 nginx-4ok8v nginx-qrm3m ``` -여기서 셀렉터는 레플리케이션 컨트롤러(`kubectl describe` 의 출력에서 보인)의 셀렉터와 같고, -다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 옵션은 +여기서 셀렉터는 레플리케이션컨트롤러(`kubectl describe` 의 출력에서 보인)의 셀렉터와 같고, +다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 옵션은 반환된 목록의 각 파드에서 이름을 가져오는 표현식을 지정한다. @@ -123,7 +123,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m `.spec.template` 는 오직 `.spec` 필드에서 요구되는 것이다. -`.spec.template` 는 [파드(Pod) 개요](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다. +`.spec.template` 는 [파드 개요](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다. 파드에 필요한 필드 외에도 레플리케이션 컨트롤러의 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 지정해야 한다. 레이블의 경우 다른 컨트롤러와 중첩되지 않도록 하라. [파드 셀렉터](#파드-셀렉터)를 참조하라. @@ -223,12 +223,12 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 예를 들어, 서비스는 `tier in (frontend), environment in (prod)` 이 있는 모든 파드를 대상으로 할 수 있다. 이제 이 계층을 구성하는 10 개의 복제된 파드가 있다고 가정해 보자. 하지만 이 구성 요소의 새로운 버전을 '카나리' 하기를 원한다. 대량의 레플리카에 대해 `replicas` 를 9로 설정하고 `tier=frontend, environment=prod, track=stable` 레이블을 설정한 레플리케이션 컨트롤러와, 카나리에 `replicas` 가 1로 설정된 다른 레플리케이션 컨트롤러에 `tier=frontend, environment=prod, track=canary` 라는 레이블을 설정할 수 있다. 이제 이 서비스는 카나리와 카나리 이외의 파드 모두를 포함한다. 그러나 레플리케이션 컨트롤러를 별도로 조작하여 테스트하고 결과를 모니터링하는 등의 작업이 혼란스러울 수 있다. -### 서비스와 레플리케이션 컨트롤러 사용 +### 서비스와 레플리케이션컨트롤러 사용 -하나의 서비스 뒤에 여러 개의 레플리케이션 컨트롤러가 있을 수 있다. 예를 들어 일부 트래픽은 이전 버전으로 이동하고 일부는 새 버전으로 이동한다. +하나의 서비스 뒤에 여러 개의 레플리케이션컨트롤러가 있을 수 있다. +예를 들어 일부 트래픽은 이전 버전으로 이동하고 일부는 새 버전으로 이동한다. -레플리케이션 컨트롤러는 자체적으로 종료되지 않지만 서비스만큼 오래 지속될 것으로 기대되지는 않는다. 서비스는 여러 레플리케이션 컨트롤러에 의해 제어되는 파드로 구성될 수 있으며 서비스 라이프사이클 동안 (예를 들어 서비스를 실행하는 파드 업데이트 수행을 위해) -많은 레플리케이션 컨트롤러가 생성 및 제거될 것으로 예상된다. 서비스 자체와 클라이언트 모두 파드를 유지하는 레플리케이션 컨트롤러를 의식하지 않는 상태로 남아 있어야 한다. +레플리케이션컨트롤러는 자체적으로 종료되지 않지만, 서비스만큼 오래 지속될 것으로 기대되지는 않는다. 서비스는 여러 레플리케이션컨트롤러에 의해 제어되는 파드로 구성될 수 있으며, 서비스 라이프사이클 동안(예를 들어, 서비스를 실행하는 파드 업데이트 수행을 위해) 많은 레플리케이션컨트롤러가 생성 및 제거될 것으로 예상된다. 서비스 자체와 클라이언트 모두 파드를 유지하는 레플리케이션컨트롤러를 의식하지 않는 상태로 남아 있어야 한다. ## 레플리케이션을 위한 프로그램 작성 @@ -280,6 +280,4 @@ API 오브젝트에 대한 더 자세한 것은 ## 더 자세한 정보는 -[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라. - - +[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/)를 참고한다. diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index 1779ea4f92..39836fd7a1 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -24,24 +24,25 @@ weight: 40 * 순차적인, 자동 롤링 업데이트. 위의 안정은 파드의 (재)스케줄링 전반에 걸친 지속성과 같은 의미이다. -만약 애플리케이션이 안정적인 식별자 또는 순차적인 배포, -삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카 셋을 +만약 애플리케이션이 안정적인 식별자 또는 순차적인 배포, +삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카 셋을 제공하는 워크로드 오브젝트를 사용해서 애플리케이션을 배포해야 한다. -[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) 또는 +[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) 또는 [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)과 같은 컨트롤러가 스테이트리스 요구에 더 적합할 수 있다. ## 제한사항 * 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다. -* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다. +* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다. * 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다. * 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다. -* [롤링 업데이트](#롤링-업데이트)와 기본 +* [롤링 업데이트](#롤링-업데이트)와 기본 [파드 매니지먼트 폴리시](#파드-매니지먼트-폴리시) (`OrderedReady`)를 함께 사용시 [복구를 위한 수동 개입](#강제-롤백)이 필요한 파손 상태로 빠질 수 있다. ## 구성 요소 + 아래의 예시에서는 스테이트풀셋의 구성요소를 보여 준다. ```yaml @@ -100,9 +101,9 @@ spec: * 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다. * 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다. * volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다. -스테이트풀셋 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +스테이트풀셋 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. ## 파드 셀렉터 @@ -110,9 +111,9 @@ spec: ## 파드 신원 -스테이트풀셋 파드는 순서, 안정적인 네트워크 신원 그리고 -안정적인 스토리지로 구성되는 고유한 신원을 가진다. 신원은 -파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다. +스테이트풀셋 파드는 순서, 안정적인 네트워크 신원 +그리고 안정적인 스토리지로 구성되는 고유한 신원을 가진다. +신원은 파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다. ### 순서 색인 @@ -121,23 +122,23 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 ### 안정적인 네트워크 신원 -스테이트풀셋의 각 파드는 스테이트풀셋의 이름과 파드의 순번에서 -호스트 이름을 얻는다. 호스트 이름을 구성하는 패턴은 -`$(statefulset name)-$(ordinal)` 이다. 위의 예시에서 생성된 3개 파드의 이름은 +스테이트풀셋의 각 파드는 스테이트풀셋의 이름과 파드의 순번에서 +호스트 이름을 얻는다. 호스트 이름을 구성하는 패턴은 +`$(statefulset name)-$(ordinal)` 이다. 위의 예시에서 생성된 3개 파드의 이름은 `web-0,web-1,web-2` 이다. -스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해 +스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 사용할 수 있다. -이 서비스가 관리하는 도메인은 `$(service name).$(namespace).svc.cluster.local` 의 형식을 가지며, +이 서비스가 관리하는 도메인은 `$(service name).$(namespace).svc.cluster.local` 의 형식을 가지며, 여기서 "cluster.local"은 클러스터 도메인이다. -각 파드는 생성되면 `$(podname).$(governing service domain)` 형식을 가지고 -일치되는 DNS 서브도메인을 가지며, 여기서 governing service는 +각 파드는 생성되면 `$(podname).$(governing service domain)` 형식을 가지고 +일치되는 DNS 서브도메인을 가지며, 여기서 거버닝 서비스(governing service)는 스테이트풀셋의 `serviceName` 필드에 의해 정의된다. [제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는 -파드의 네트워크 신원을 책임지는 +파드의 네트워크 신원을 책임지는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 생성할 책임이 있다. -여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고, +여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고, 그 선택이 스테이트풀셋 파드의 DNS이름에 어떻게 영향을 주는지에 대한 약간의 예시가 있다. 클러스터 도메인 | 서비스 (ns/이름) | 스테이트풀셋 (ns/이름) | 스테이트풀셋 도메인 | 파드 DNS | 파드 호스트 이름 | @@ -147,26 +148,26 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | {{< note >}} -클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/)가 +클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/)가 아니라면 `cluster.local`로 설정된다. {{< /note >}} ### 안정된 스토리지 -쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 -생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와 -1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게된다. 만약 스토리지 클래스가 -명시되지 않은 경우 기본 스토리지 클래스를 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이되면 +쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 +생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와 +1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가 +명시되지 않은 경우, 기본 스토리지 클래스가 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이 되면 파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다. -참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은 +참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은 파드 또는 스테이트풀셋이 삭제되더라도 삭제되지 않는다. 이것은 반드시 수동으로 해야한다. ### 파드 이름 레이블 스테이트풀셋 {{< glossary_tooltip term_id="controller" >}} -가 파드를 생성할 때 파드 이름으로 `statefulset.kubernetes.io/pod-name` -레이블이 추가된다. 이 레이블로 스테이트풀셋의 특정 파드에 서비스를 +가 파드를 생성할 때 파드 이름으로 `statefulset.kubernetes.io/pod-name` +레이블이 추가된다. 이 레이블로 스테이트풀셋의 특정 파드에 서비스를 연결할 수 있다. ## 디플로이먼트와 스케일링 보증 @@ -178,87 +179,87 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다. -위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가 -배포된다. web-1은 web-0이 -[Running 및 Ready](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 상태가 되기 전에는 배포되지 않으며, -web-2 도 web-1이 Running 및 Ready 상태가 되기 전에는 배포되지 않는다. 만약 web-1이 Running 및 Ready 상태가 된 이후, -web-2가 시작되기 전에 web-0이 실패하게 된다면, web-2는 web-0이 성공적으로 재시작이되고, +위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가 +배포된다. web-1은 web-0이 +[Running 및 Ready](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 상태가 되기 전에는 배포되지 않으며, +web-2 도 web-1이 Running 및 Ready 상태가 되기 전에는 배포되지 않는다. 만약 web-1이 Running 및 Ready 상태가 된 이후, +web-2가 시작되기 전에 web-0이 실패하게 된다면, web-2는 web-0이 성공적으로 재시작이되고, Running 및 Ready 상태가 되기 전까지 시작되지 않는다. -만약 사용자가 배포된 예제의 스테이트풀셋을 `replicas=1` 으로 패치해서 -스케일한 경우 web-2가 먼저 종료된다. web-1은 web-2가 완전히 종료 및 삭제되기 -전까지 정지되지 않는다. 만약 web-2의 종료 및 완전히 중지되고, web-1이 종료되기 전에 -web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 +만약 사용자가 배포된 예제의 스테이트풀셋을 `replicas=1` 으로 패치해서 +스케일한 경우 web-2가 먼저 종료된다. web-1은 web-2가 완전히 종료 및 삭제되기 +전까지 정지되지 않는다. 만약 web-2의 종료 및 완전히 중지되고, web-1이 종료되기 전에 +web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 되기 전까지 종료되지 않는다. ### 파드 관리 정책 -쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.podManagementPolicy` 필드를 +쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.podManagementPolicy` 필드를 통해 고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다. #### OrderedReady 파드 관리 -`OrderedReady` 파드 관리는 스테이트풀셋의 기본이다. +`OrderedReady` 파드 관리는 스테이트풀셋의 기본이다. 이것은 [위에서](#디플로이먼트와-스케일-보증) 설명한 행위를 구현한다. #### 병렬 파드 관리 -`병렬` 파드 관리는 스테이트풀셋 컨트롤러에게 모든 파드를 -병렬로 실행 또는 종료하게 한다. 그리고 다른 파드의 실행이나 +`병렬` 파드 관리는 스테이트풀셋 컨트롤러에게 모든 파드를 +병렬로 실행 또는 종료하게 한다. 그리고 다른 파드의 실행이나 종료에 앞서 파드가 Running 및 Ready 상태가 되거나 완전히 종료되기를 기다리지 않는다. -이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을 +이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을 받지 않는다. ## 업데이트 전략 -쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의 -파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를 +쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의 +파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를 구성하거나 비활성화 할 수 있다. ### 삭제 시(On Delete) -`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의 -`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는 -스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의 +`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의 +`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는 +스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의 `.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다. ### 롤링 업데이트 -`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를 -구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면 -스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이 -순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지), -각 파드의 업데이트는 한번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될 +`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를 +구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면 +스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이 +순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지), +각 파드의 업데이트는 한 번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될 때까지 기다린다. #### 파티션(Partition) -`롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition` -를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가 +`롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition` +를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가 업데이트 될 때 부여된 수가 파티션보다 크거나 같은 모든 파드가 업데이트 된다. -파티션보다 작은 수를 가진 모든 파드는 업데이트 되지 않으며, +파티션보다 작은 수를 가진 모든 파드는 업데이트 되지 않으며, 삭제 된 경우라도 이전 버전에서 재생성된다. -만약 스테이트풀셋의 `.spec.updateStrategy.rollingUpdate.partition` 이 +만약 스테이트풀셋의 `.spec.updateStrategy.rollingUpdate.partition` 이 `.spec.replicas` 보다 큰 경우 `.spec.template` 의 업데이트는 해당 파드에 전달하지 않는다. -대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나, +대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나, 카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다. #### 강제 롤백 -기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과 -함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우 +기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과 +함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우 직접 수동으로 복구를 해야하는 고장난 상태가 될 수 있다. -만약 파드 템플릿을 Running 및 Ready 상태가 되지 않는 구성으로 업데이트하는 -경우(예시: 잘못된 바이너리 또는 애플리케이션-레벨 구성 오류로 인한) +만약 파드 템플릿을 Running 및 Ready 상태가 되지 않는 구성으로 업데이트하는 +경우(예시: 잘못된 바이너리 또는 애플리케이션-레벨 구성 오류로 인한) 스테이트풀셋은 롤아웃을 중지하고 기다린다. 이 상태에서는 파드 템플릿을 올바른 구성으로 되돌리는 것으로 충분하지 않다. -[알려진 이슈](https://github.com/kubernetes/kubernetes/issues/67250)로 -인해 스테이트풀셋은 손상된 파드가 준비(절대 되지 않음)될 때까지 기다리며 -작동하는 구성으로 되돌아가는 시도를 하기 +[알려진 이슈](https://github.com/kubernetes/kubernetes/issues/67250)로 +인해 스테이트풀셋은 손상된 파드가 준비(절대 되지 않음)될 때까지 기다리며 +작동하는 구성으로 되돌아가는 시도를 하기 전까지 기다린다. -템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로 +템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로 실행하려고 시도한 모든 파드를 삭제해야 한다. 그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다. @@ -269,6 +270,3 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 * [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다. * [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다. * [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다. - - - diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md index c095dd31c5..de92b4f3ea 100644 --- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -14,8 +14,9 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를 처리하도록 확장될 수 있다. -알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 kube-apiserver 와 kube-controller-manager 와 함께 -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 로 `TTLAfterFinished` 를 활성화 할 수 있다. +알파(Alpha) 고지 사항: 이 기능은 현재 알파이고, +kube-apiserver와 kube-controller-manager와 함께 +[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)로 `TTLAfterFinished` 를 활성화할 수 있다. @@ -66,13 +67,13 @@ TTL 기간은, 예를 들어 잡의 `.spec.ttlSecondsAfterFinished` 필드는 ### 시간 차이(Skew) TTL 컨트롤러는 쿠버네티스 리소스에 -저장된 타임스탬프를 사용해서 TTL의 만료 여부를 결정하기 때문에, 이 기능은 클러스터 간의 +저장된 타임스탬프를 사용해서 TTL의 만료 여부를 결정하기 때문에, 이 기능은 클러스터 간의 시간 차이에 민감하며, 시간 차이에 의해서 TTL 컨트롤러가 잘못된 시간에 리소스 오브젝트를 정리하게 될 수 있다. 쿠버네티스에서는 시간 차이를 피하기 위해 모든 노드 ([#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)를 본다) -에서 NTP를 실행해야 한다. 시계가 항상 정확한 것은 아니지만, 그 차이는 +에서 NTP를 실행해야 한다. 시계가 항상 정확한 것은 아니지만, 그 차이는 아주 작아야 한다. 0이 아닌 TTL을 설정할때는 이 위험에 대해 유의해야 한다. @@ -83,5 +84,3 @@ TTL 컨트롤러는 쿠버네티스 리소스에 [자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리) [디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) - - diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index bd2f2023af..0e46b4bf5e 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -9,7 +9,7 @@ weight: 60 파드에서 발생하는 장애 유형을 이해하기 원하는 애플리케이션 소유자를 위한 것이다. -또한 클러스터의 업그레이드와 오토스케일링과 같은 +또한 클러스터의 업그레이드와 오토스케일링과 같은 클러스터의 자동화 작업을 하려는 관리자를 위한 것이다. @@ -19,7 +19,7 @@ weight: 60 ## 자발적 중단과 비자발적 중단 -파드는 누군가(사람 또는 컨트롤러)가 파괴하거나 +파드는 누군가(사람 또는 컨트롤러)가 파괴하거나 불가피한 하드웨어 오류 또는 시스템 소프트웨어 오류가 아니면 사라지지 않는다. 우리는 이런 불가피한 상황을 애플리케이션의 *비자발적 중단* 으로 부른다. @@ -33,7 +33,8 @@ weight: 60 - 노드의 [리소스 부족](/docs/tasks/administer-cluster/out-of-resource/)으로 파드가 축출됨 리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다. -왜냐하면 그 조건은 쿠버네티스에 국한되지 않기 때문이다. +왜냐하면 +그 조건은 쿠버네티스에 국한되지 않기 때문이다. 우리는 다른 상황을 *자발적인 중단* 으로 부른다. 여기에는 애플리케이션 소유자의 작업과 클러스터 관리자의 작업이 모두 포함된다. @@ -46,19 +47,21 @@ weight: 60 클러스터 관리자의 작업: - 복구 또는 업그레이드를 위한 [노드 드레이닝](/docs/tasks/administer-cluster/safely-drain-node/). -- 클러스터의 스케일 축소를 위한 노드 드레이닝([클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)에 대해 알아보기). +- 클러스터의 스케일 축소를 위한 + 노드 드레이닝([클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)에 대해 알아보기 + ). - 노드에 다른 무언가를 추가하기 위해 파드를 제거. 위 작업은 클러스터 관리자가 직접 수행하거나 자동화를 통해 수행하며, 클러스터 호스팅 공급자에 의해서도 수행된다. -클러스터에 자발적인 중단을 일으킬 수 있는 어떤 원인이 있는지 +클러스터에 자발적인 중단을 일으킬 수 있는 어떤 원인이 있는지 클러스터 관리자에게 문의하거나 클라우드 공급자에게 문의하고, 배포 문서를 참조해서 확인해야 한다. 만약 자발적인 중단을 일으킬 수 있는 원인이 없다면 Pod Disruption Budget의 생성을 넘길 수 있다. {{< caution >}} 모든 자발적인 중단이 Pod Disruption Budget에 연관되는 것은 아니다. -예를 들어 디플로이먼트 또는 파드의 삭제는 Pod Disruption Budget를 무시한다. +예를 들어 디플로이먼트 또는 파드의 삭제는 Pod Disruption Budget을 무시한다. {{< /caution >}} ## 중단 다루기 @@ -66,48 +69,58 @@ weight: 60 비자발적인 중단으로 인한 영향을 경감하기 위한 몇 가지 방법은 다음과 같다. - 파드가 필요로 하는 [리소스를 요청](/docs/tasks/configure-pod-container/assign-cpu-ram-container)하는지 확인한다. -- 고가용성이 필요한 경우 애플리케이션을 복제한다. (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/)애플리케이션에 대해 알아보기.) -- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체([안티-어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 이용) 또는 -영역 간(또는 [다중 영역 클러스터](/ko/docs/setup/best-practices/multiple-zones/)를 이용한다.)에 -애플리케이션을 분산해야 한다. +- 고가용성이 필요한 경우 애플리케이션을 복제한다. + (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 + [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.) +- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체 + ([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용) + 또는 영역 간 + ([다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다면)에 + 애플리케이션을 분산해야 한다. 자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다. 그러나 클러스터 관리자 또는 호스팅 공급자가 자발적 중단이 발생할 수 있는 일부 부가 서비스를 운영할 수 있다. 예를 들어 노드 소프트웨어의 업데이트를 출시하는 경우 자발적 중단이 발생할 수 있다. -또한 클러스터(노드) 오토스케일링의 일부 구현에서는 단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다. -클러스터 관리자 또는 호스팅 공급자는 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다. +또한 클러스터(노드) 오토스케일링의 일부 구현에서는 +단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다. +클러스터 관리자 또는 호스팅 공급자는 +예측 가능한 자발적 중단 수준에 대해 문서화해야 한다. 쿠버네티스는 자주 발생하는 자발적 중단에도 고가용성 애플리케이션을 -실행 할 수 있는 기능을 제공한다. +실행 할 수 있는 기능을 제공한다. 우리는 이 기능을 *Disruption Budgets* 이라 부른다. + ## Disruption Budgets의 작동 방식 {{< feature-state for_k8s_version="v1.5" state="beta" >}} 애플리케이션 소유자는 각 애플리케이션에 대해 `PodDisruptionBudget` 오브젝트(PDB)를 만들 수 있다. -PDB는 자발적 중단으로 일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다. -예를 들어 정족수 기반의 애플리케이션이 +PDB는 자발적 중단으로 +일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다. +예를 들어 정족수 기반의 애플리케이션이 실행 중인 레플리카의 수가 정족수 이하로 떨어지지 않도록 한다. -웹 프런트 엔드는 부하를 처리하는 레플리카의 수가 +웹 프런트 엔드는 부하를 처리하는 레플리카의 수가 일정 비율 이하로 떨어지지 않도록 보장할 수 있다. -클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신 -[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로 -불리는 Pod Disruption Budgets를 준수하는 도구를 이용해야 한다. +클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신 +[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로 +불리는 Pod Disruption Budget을 준수하는 도구를 이용해야 한다. 예를 들어 `kubectl drain` 명령어나 Kubernetes-on-GCE 클러스터 업그레이드 스크립트(`cluster/gce/upgrade.sh`)이다. 클러스터 관리자가 노드를 비우고자 할 경우에는 `kubectl drain` 명령어를 사용한다. 해당 도구는 머신에 존재하는 모든 파드를 축출하려는 시도를 한다. -축출 요청은 일시적으로 거부될 수 있으며, 도구는 모든 파드가 종료되거나 +축출 요청은 일시적으로 거부될 수 있으며, +도구는 모든 파드가 종료되거나 설정 가능한 타임아웃이 도래할 때까지 주기적으로 모든 실패된 요청을 다시 시도한다. PDB는 애플리케이션이 필요로 하는 레플리카의 수에 상대적으로, 용인할 수 있는 레플리카의 수를 지정한다. 예를 들어 `.spec.replicas: 5` 의 값을 갖는 디플로이먼트는 어느 시점에든 5개의 파드를 가져야 한다. -만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면, Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다. +만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면, +Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다. -파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며 -애플리케이션 컨트롤러(디플로이먼트, 스테이트풀 셋 등)를 사용한 것과 같다. +파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며 +애플리케이션 컨트롤러(디플로이먼트, 스테이트풀셋 등)를 사용한 것과 같다. 파드의 "의도"하는 수량은 파드 컨트롤러의 `.spec.replicas` 를 기반으로 계산한다. 컨트롤러는 오브젝트의 `.metadata.ownerReferences` 를 사용해서 파드를 발견한다. @@ -116,7 +129,8 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 버짓이 차감된다. 애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다. -그러나 컨트롤러(디플로이먼트, 스테이트풀 셋과 같은)는 롤링 업데이트시 PDB의 제한을 받지 않는다. +그러나 컨트롤러(디플로이먼트, 스테이트풀셋과 같은)는 +롤링 업데이트시 PDB의 제한을 받지 않는다. 애플리케이션 업데이트 진행 중 발생하는 중단 처리는 컨트롤러 사양에 구성되어있다. ([디플로이먼트 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-업데이트)에 대해 알아보기.) @@ -126,7 +140,7 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 ## PDB 예시 `node-1` 부터 `node-3` 까지 3개의 노드가 있는 클러스터가 있다고 하자. -클러스터에는 여러 애플리케이션을 실행하고 있다. +클러스터에는 여러 애플리케이션을 실행하고 있다. 여러 애플리케이션 중 하나는 `pod-a`, `pod-b`, `pod-c` 로 부르는 3개의 레플리카가 있다. 여기에 `pod-x` 라고 부르는 PDB와 무관한 파드가 보인다. 초기에 파드는 다음과 같이 배치된다. @@ -135,7 +149,8 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 | pod-a *available* | pod-b *available* | pod-c *available* | | pod-x *available* | | | -전체 3개 파드는 디플로이먼트의 일부분으로 전체적으로 항상 3개의 파드 중 최소 2개의 파드를 사용할 수 있도록 하는 PDB를 가지고 있다. +전체 3개 파드는 디플로이먼트의 일부분으로 +전체적으로 항상 3개의 파드 중 최소 2개의 파드를 사용할 수 있도록 하는 PDB를 가지고 있다. 예를 들어, 클러스터 관리자가 커널 버그를 수정하기위해 새 커널 버전으로 재부팅하려는 경우를 가정해보자. 클러스터 관리자는 첫째로 `node-1` 을 `kubectl drain` 명령어를 사용해서 비우려 한다. @@ -149,12 +164,12 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 | pod-x *terminating* | | | 디플로이먼트는 한 개의 파드가 중지되는 것을 알게되고, `pod-d` 라는 대체 파드를 생성한다. -`node-1` 은 차단되어 있어 다른 노드에 위치한다. +`node-1` 은 차단되어 있어 다른 노드에 위치한다. 무언가가 `pod-x` 의 대체 파드로 `pod-y` 도 생성했다. -(참고: 스테이트풀 셋은 `pod-0`처럼 불릴, `pod-a`를 +(참고: 스테이트풀셋은 `pod-0` 처럼 불릴, `pod-a` 를 교체하기 전에 완전히 중지해야 하며, `pod-0` 로 불리지만, 다른 UID로 생성된다. -그렇지 않으면 이 예시는 스테이트풀 셋에도 적용된다.) +그렇지 않으면 이 예시는 스테이트풀셋에도 적용된다.) 이제 클러스터는 다음과 같은 상태이다. @@ -170,9 +185,9 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 | | pod-b *available* | pod-c *available* | | | pod-d *starting* | pod-y | -이 시점에서 만약 성급한 클러스터 관리자가 `node-2` 또는 `node-3` 을 -비우려고 하는 경우 디플로이먼트에 available 상태의 파드가 2개 뿐이고, -PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된다. 약간의 시간이 지나면 `pod-d`가 available 상태가 된다. +이 시점에서 만약 성급한 클러스터 관리자가 `node-2` 또는 `node-3` 을 +비우려고 하는 경우 디플로이먼트에 available 상태의 파드가 2개 뿐이고, +PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된다. 약간의 시간이 지나면 `pod-d` 가 available 상태가 된다. 이제 클러스터는 다음과 같은 상태이다. @@ -182,13 +197,13 @@ PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된 | | pod-d *available* | pod-y | 이제 클러스터 관리자는 `node-2` 를 비우려고 한다. -drain 커멘드는 `pod-b`에서 `pod-d`와 같이 어떤 순서대로 두 파드를 축출하려 할 것이다. -drain 커멘드는 `pod-b`를 축출하는데 성공했다. -그러나 drain 커멘드가 `pod-d` 를 축출하려 하는 경우 +drain 커멘드는 `pod-b` 에서 `pod-d` 와 같이 어떤 순서대로 두 파드를 축출하려 할 것이다. +drain 커멘드는 `pod-b` 를 축출하는데 성공했다. +그러나 drain 커멘드가 `pod-d` 를 축출하려 하는 경우 디플로이먼트에 available 상태의 파드는 1개로 축출이 거부된다. -디플로이먼트는`pod-b` 를 대체할 `pod-e`라는 파드를 생성한다. -클러스터에 `pod-e` 를 스케줄하기 위한 충분한 리소스가 없기 때문에 +디플로이먼트는`pod-b` 를 대체할 `pod-e` 라는 파드를 생성한다. +클러스터에 `pod-e` 를 스케줄하기 위한 충분한 리소스가 없기 때문에 드레이닝 명령어는 차단된다. 클러스터는 다음 상태로 끝나게 된다. @@ -200,7 +215,7 @@ drain 커멘드는 `pod-b`를 축출하는데 성공했다. 이 시점에서 클러스터 관리자는 클러스터에 노드를 추가해서 업그레이드를 진행해야 한다. -쿠버네티스에 중단이 발생할 수 있는 비율을 어떻게 변화시키는지 +쿠버네티스에 중단이 발생할 수 있는 비율을 어떻게 변화시키는지 다음의 사례를 통해 알 수 있다. - 애플리케이션에 필요한 레플리카의 수 @@ -211,28 +226,29 @@ drain 커멘드는 `pod-b`를 축출하는데 성공했다. ## 클러스터 소유자와 애플리케이션 소유자의 역할 분리 -보통 클러스터 매니저와 애플리케이션 소유자는 +보통 클러스터 매니저와 애플리케이션 소유자는 서로에 대한 지식이 부족한 별도의 역할로 생각하는 것이 유용하다. -이와 같은 책임의 분리는 +이와 같은 책임의 분리는 다음의 시나리오에서 타당할 수 있다. - 쿠버네티스 클러스터를 공유하는 애플리케이션 팀이 많고, 자연스럽게 역할이 나누어진 경우 -- 타사 도구 또는 타사 서비스를 이용해서 클러스터 관리를 자동화 하는 경우 +- 타사 도구 또는 타사 서비스를 이용해서 + 클러스터 관리를 자동화 하는 경우 -Pod Disruption Budgets는 역할 분리에 따라 +Pod Disruption Budget은 역할 분리에 따라 역할에 맞는 인터페이스를 제공한다. 만약 조직에 역할 분리에 따른 책임의 분리가 없다면 -Pod Disruption Budgets를 사용할 필요가 없다. +Pod Disruption Budget을 사용할 필요가 없다. ## 클러스터에서 중단이 발생할 수 있는 작업을 하는 방법 -만약 클러스터 관리자라면, 그리고 클러스터 전체 노드에 노드 또는 시스템 소프트웨어 업그레이드와 같은 +만약 클러스터 관리자라면, 그리고 클러스터 전체 노드에 노드 또는 시스템 소프트웨어 업그레이드와 같은 중단이 발생할 수 있는 작업을 수행하는 경우 다음과 같은 옵션을 선택한다. - 업그레이드 하는 동안 다운타임을 허용한다. - 다른 레플리카 클러스터로 장애조치를 한다. - - 다운타임은 없지만, 노드 사본과 + - 다운타임은 없지만, 노드 사본과 전환 작업을 조정하기 위한 인력 비용이 많이 발생할 수 있다. - PDB를 이용해서 애플리케이션의 중단에 견디도록 작성한다. - 다운타임 없음 @@ -251,5 +267,3 @@ Pod Disruption Budgets를 사용할 필요가 없다. * [Pod Disruption Budget 설정하기](/docs/tasks/run-application/configure-pdb/)의 단계를 따라서 애플리케이션을 보호한다. * [노드 비우기](/docs/tasks/administer-cluster/safely-drain-node/)에 대해 자세히 알아보기 - - diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md index 721405614c..1e8a54fff9 100644 --- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -9,13 +9,14 @@ weight: 80 {{< feature-state state="alpha" for_k8s_version="v1.16" >}} 이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는 -트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip term_id="pod" >}} 에서 +트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서 임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시 컨테이너를 사용한다. {{< warning >}} -임시 컨테이너는 초기 알파 상태이며, 프로덕션 클러스터에는 -적합하지 않다. [쿠버네티스 사용중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라 +임시 컨테이너는 초기 알파 상태이며, +프로덕션 클러스터에는 적합하지 않다. +[쿠버네티스 사용 중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라 이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다. {{< /warning >}} @@ -25,23 +26,23 @@ weight: 80 ## 임시 컨테이너 이해하기 -{{< glossary_tooltip text="파드" term_id="pod" >}} 는 쿠버네티스 애플리케이션의 -기본 구성 요소이다. 파드는 일회용이고, 교체 가능한 것으로 의도되었기 +{{< glossary_tooltip text="파드" term_id="pod" >}} 는 쿠버네티스 애플리케이션의 +기본 구성 요소이다. 파드는 일회용이고, 교체 가능한 것으로 의도되었기 때문에, 사용자는 파드가 한번 생성되면, 컨테이너를 추가할 수 없다. -대신, 사용자는 보통 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 를 +대신, 사용자는 보통 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 를 사용해서 제어하는 방식으로 파드를 삭제하고 교체한다. -그러나 때때로 재현하기 어려운 버그의 문제 해결을 위해 -기존 파드의 상태를 검사해야할 수 있다. 이 경우 사용자는 -기존 파드에서 임시 컨테이너를 실행해서 상태를 검사하고, 임의의 명령을 +그러나 때때로 재현하기 어려운 버그의 문제 해결을 위해 +기존 파드의 상태를 검사해야 할 수 있다. 이 경우 사용자는 +기존 파드에서 임시 컨테이너를 실행해서 상태를 검사하고, 임의의 명령을 실행할 수 있다. ### 임시 컨테이너는 무엇인가? -임시 컨테이너는 리소스 또는 실행에 대한 보증이 없다는 점에서 -다른 컨테이너와 다르며, 결코 자동으로 재시작되지 않는다. 그래서 -애플리케이션을 만드는데 적합하지 않다. 임시 컨테이너는 -일반 컨테이너와 동일한 `ContainerSpec` 을 사용해서 명시하지만, 많은 필드가 +임시 컨테이너는 리소스 또는 실행에 대한 보증이 없다는 점에서 +다른 컨테이너와 다르며, 결코 자동으로 재시작되지 않는다. 그래서 +애플리케이션을 만드는데 적합하지 않다. 임시 컨테이너는 +일반 컨테이너와 동일한 `ContainerSpec` 을 사용해서 명시하지만, 많은 필드가 호환되지 않으며 임시 컨테이너에는 허용되지 않는다. - 임시 컨테이너는 포트를 가지지 않을 수 있으므로, `ports`, @@ -60,20 +61,20 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 ## 임시 컨테이너의 사용 임시 컨테이너는 컨테이너가 충돌 되거나 또는 컨테이너 이미지에 -디버깅 도구가 포함되지 않은 이유로 `kubectl exec` 이 불충분할 때 +디버깅 도구가 포함되지 않은 이유로 `kubectl exec` 이 불충분할 때 대화형 문제 해결에 유용하다. 특히, [distroless 이미지](https://github.com/GoogleContainerTools/distroless) -를 사용하면 공격 표면(attack surface)과 버그 및 취약점의 노출을 줄이는 최소한의 -컨테이너 이미지를 배포할 수 있다. distroless 이미지는 쉘 또는 어떤 디버깅 도구를 -포함하지 않기 때문에, `kubectl exec` 만으로는 distroless +를 사용하면 공격 표면(attack surface)과 버그 및 취약점의 노출을 줄이는 최소한의 +컨테이너 이미지를 배포할 수 있다. distroless 이미지는 셸 또는 어떤 디버깅 도구를 +포함하지 않기 때문에, `kubectl exec` 만으로는 distroless 이미지의 문제 해결이 어렵다. -임시 컨테이너 사용시 [프로세스 네임스페이스 -공유](/docs/tasks/configure-pod-container/share-process-namespace/)를 +임시 컨테이너 사용 시 [프로세스 네임스페이스 +공유](/docs/tasks/configure-pod-container/share-process-namespace/)를 활성화하면 다른 컨테이너 안의 프로세스를 보는데 도움이 된다. -임시 컨테이너를 사용해서 문제를 해결하는 예시는 +임시 컨테이너를 사용해서 문제를 해결하는 예시는 [임시 디버깅 컨테이너로 디버깅하기] (/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)를 참조한다. @@ -81,17 +82,17 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 {{< note >}} 이 섹션의 예시는 `EphemeralContainers` [기능 -게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 +게이트](/docs/reference/command-line-tools-reference/feature-gates/)의 활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다. {{< /note >}} -이 섹션의 에시는 임시 컨테이너가 어떻게 API에 나타나는지 +이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지 보여준다. 일반적으로 `kubectl alpha debug` 또는 -다른 `kubectl` [플러그인](/docs/tasks/extend-kubectl/kubectl-plugins/)을 +다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을 사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다. -임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를 -사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저 +임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를 +사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저 `EphemeralContainers` 목록으로 추가하는 임시 컨테이너를 명시한다. ```json @@ -187,5 +188,3 @@ Ephemeral Containers: ```shell kubectl attach -it example-pod -c debugger ``` - - diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index 0e1f614de3..d29cc514e3 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -27,7 +27,7 @@ weight: 40 * 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다. 만약 파드를 위한 초기화 컨테이너가 실패한다면, 쿠버네티스는 초기화 컨테이너가 성공할 때까지 파드를 -반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy`을 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다. +반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy` 를 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다. 컨테이너를 초기화 컨테이너로 지정하기 위해서는, 파드 스펙에 앱 `containers` 배열과 나란히 `initContainers` 필드를 @@ -63,7 +63,7 @@ weight: 40 * 애플리케이션 이미지 빌더와 디플로이어 역할은 독립적으로 동작될 수 있어서 공동의 단일 앱 이미지 형태로 빌드될 필요가 없다. * 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 Linux 네임스페이스를 사용한다. - 결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는 + 결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는 {{< glossary_tooltip text="시크릿" term_id="secret" >}}에 접근 권한이 주어질 수 있다. * 앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱 컨테이너라도 시작되기 전에 실행 완료되어야 하므로, 초기화 컨테이너는 사전 조건들이 @@ -102,7 +102,7 @@ weight: 40 ### 사용 중인 초기화 컨테이너 쿠버네티스 1.5에 대한 다음의 yaml 파일은 두 개의 초기화 컨테이너를 포함한 간단한 파드에 대한 개요를 보여준다. -첫 번째는 `myservice`를 기다리고 두 번째는 `mydb`를 기다린다. 두 컨테이너들이 +첫 번째는 `myservice` 를 기다리고 두 번째는 `mydb` 를 기다린다. 두 컨테이너들이 완료되면, 파드가 시작될 것이다. ```yaml @@ -190,7 +190,7 @@ kubectl logs myapp-pod -c init-mydb # Inspect the second init container ``` `mydb` 및 `myservice` 서비스를 시작하고 나면, 초기화 컨테이너가 완료되고 -`myapp-pod`가 생성된 것을 볼 수 있다. +`myapp-pod` 가 생성된 것을 볼 수 있다. 여기에 이 서비스를 보이기 위해 사용할 수 있는 구성이 있다. @@ -217,7 +217,7 @@ spec: targetPort: 9377 ``` -`mydb`와 `myservice` 서비스 생성하기. +`mydb` 와 `myservice` 서비스 생성하기. ```shell kubectl apply -f services.yaml @@ -227,7 +227,7 @@ service/myservice created service/mydb created ``` -초기화 컨테이너들이 완료되는 것과 `myapp-pod` 파드가 Runnning 상태로 +초기화 컨테이너들이 완료되는 것과 `myapp-pod` 파드가 Running 상태로 변경되는 것을 볼 것이다. ```shell @@ -249,13 +249,13 @@ myapp-pod 1/1 Running 0 9m 각 초기화 컨테이너는 다음 컨테이너가 시작되기 전에 성공적으로 종료되어야 한다. 만약 런타임 문제나 실패 상태로 종료되는 문제로인하여 초기화 컨테이너의 시작이 -실패된다면, 초기화 컨테이너는 파드의 `restartPolicy`에 따라서 재시도 된다. 다만, -파드의 `restartPolicy`이 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는 -`restartPolicy`을 실패 시(OnFailure)로 사용한다. +실패된다면, 초기화 컨테이너는 파드의 `restartPolicy` 에 따라서 재시도 된다. 다만, +파드의 `restartPolicy` 가 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는 +`restartPolicy` 를 실패 시(OnFailure)로 사용한다. -파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready`될 수 없다. 초기화 컨테이너의 포트는 +파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready` 될 수 없다. 초기화 컨테이너의 포트는 서비스 하에 합쳐지지 않는다. 초기화 중인 파드는 `Pending` 상태이지만 -`Initialized`이 참이 되는 조건을 가져야 한다. +`Initialized` 가 참이 되는 조건을 가져야 한다. 만약 파드가 [재시작](#파드-재시작-이유)되었다면, 모든 초기화 컨테이너는 반드시 다시 실행된다. @@ -264,15 +264,16 @@ myapp-pod 1/1 Running 0 9m 초기화 컨테이너 이미지 필드를 변경하는 것은 파드를 재시작하는 것과 같다. 초기화 컨테이너는 재시작되거나, 재시도, 또는 재실행 될 수 있기 때문에, 초기화 컨테이너 -코드는 멱등성(indempotent)을 유지해야 한다. 특히, `EmptyDirs`에 있는 파일에 쓰기를 수행하는 코드는 +코드는 멱등성(idempotent)을 유지해야 한다. 특히, `EmptyDirs` 에 있는 파일에 쓰기를 수행하는 코드는 출력 파일이 이미 존재할 가능성에 대비해야 한다. 초기화 컨테이너는 앱 컨테이너의 필드를 모두 가지고 있다. 그러나, 쿠버네티스는 -`readinessProbe`가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을 +`readinessProbe` 가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을 구분해서 정의할 수 없기 때문이다. 이것은 유효성 검사 중에 시행된다. -초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서 -파드의 `activeDeadlineSeconds`와 컨테이너의 `livenessProbe`를 사용한다. +초기화 컨테이너들이 실패를 +영원히 지속하는 상황을 방지하기 위해서 +파드의 `activeDeadlineSeconds` 와 컨테이너의 `livenessProbe` 를 사용한다. 파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤 컨테이너가 다른 컨테이너와 같은 이름을 공유하는 경우 유효성 오류가 발생한다. @@ -310,7 +311,7 @@ myapp-pod 1/1 Running 0 9m 이미지의 변경은 앱 컨테이너만 재시작시킨다. * 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에 대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다. -* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy`이 항상으로 설정되어 있는, +* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy` 가 항상(Always)으로 설정되어 있는, 동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집 때문에 유실되었다. @@ -320,7 +321,5 @@ myapp-pod 1/1 Running 0 9m ## {{% heading "whatsnext" %}} -* [초기화 컨테이너를 가진 파드 생성하기](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) +* [초기화 컨테이너를 가진 파드 생성하기](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성) * [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기 - - diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index e8e384a4ab..18f4b3e813 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -114,9 +114,9 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 지원하지 않는다면, 기본 상태는 `Success`이다. * `startupProbe`: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. - 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는 + 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는 활성화 되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, - 컨테이너는 [재시작 정책](#재시작-정책)에 따라 처리된다. 컨테이너에 스타트업 + 컨테이너는 [재시작 정책](#재시작-정책)에 따라 처리된다. 컨테이너에 스타트업 프로브가 없는 경우, 기본 상태는 `Success`이다. ### 언제 활성 프로브를 사용해야 하는가? @@ -193,8 +193,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 ... ``` -* `Terminated`: 컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다. - 컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다. +* `Terminated`: 컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다. 컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다. ```yaml ... @@ -212,7 +211,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 애플리케이션은 추가 피드백 또는 신호를 PodStatus: _Pod readiness_ 와 같이 주입할 수 있다. 이를 사용하기 위해, 파드의 준비성을 평가하기 -위한 추가적인 조건들을 `PodSpec` 내의 `ReadinessGate` 필드를 통해서 지정할 수 있다. +위한 추가적인 조건들을 `PodSpec` 내의 `ReadinessGate` 필드를 통해서 지정할 수 있다. 준비성 게이트는 파드에 대한 `status.condition` 필드의 현재 상태에 따라 결정된다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는 @@ -261,6 +260,9 @@ status: * 파드 내의 모든 컨테이너들이 준비 상태이다. * `ReadinessGates`에 지정된 모든 조건들이 `True` 이다. +파드의 컨테이너가 Ready 이나 적어도 한 개의 사용자 지정 조건이 빠졌거나 `False` 이면, +Kubelet은 파드의 상태를 `ContainerReady`로 설정한다. + ## 재시작 정책 PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으로 설정 가능한 `restartPolicy` 필드를 가지고 있다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md index 5b2af22d73..bf52e77c2a 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ko/docs/concepts/workloads/pods/pod-overview.md @@ -26,6 +26,7 @@ card: * **단일 컨테이너만 동작하는 파드**. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직접 관리한다고 볼 수 있다. * **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다. + 각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(더 많은 인스턴스를 실행해서 더 많은 전체 리소스를 제공하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 일반적으로 워크로드 리소스와 해당 {{< glossary_tooltip text="_컨트롤러_" term_id="controller" >}}에 의해 그룹으로 생성과 관리된다. 쿠버네티스가 컨트롤러를 사용해서 워크로드의 확장과 복구를 구현하는 방법에 대한 자세한 내용은 [파드와 컨트롤러](#파드와-컨트롤러)를 참고한다. @@ -48,7 +49,7 @@ card: #### 저장소 -파드는 공유 저장소 집합인 {{< glossary_tooltip text="Volumes" term_id="volume" >}} 을 명시할 수 있다. 파드 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 파드 안의 공유 저장소를 사용하는지 보려면 [볼륨](/ko/docs/concepts/storage/volumes/)를 참고하길 바란다. +파드는 공유 저장소 집합인 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 명시할 수 있다. 파드 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 파드 안의 공유 저장소를 사용하는지 보려면 [볼륨](/ko/docs/concepts/storage/volumes/)을 참고하길 바란다. ## 파드 작업 @@ -64,13 +65,16 @@ card: 워크로드 리소스를 사용해서 여러 파드를 생성하고 관리할 수 있다. 리소스 컨트롤러는 파드 장애 발생 시 복제, 롤아웃, 자동 복구를 처리한다. 예를 들어, 노드에 장애가 발생하면, 컨트롤러는 해당 노드의 파드는 작동을 멈추고 교체용 파드를 생성한다는 것을 알게 된다. 스케줄러는 교체용 파드를 정상적인 노드에 배치하게 된다. +다음은 하나 이상의 파드를 관리하는 워크로드 리소스의 예이다. + * {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} * {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}} * {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}} + ## 파드 템플릿 -워크로드 리소스에 대한 컨트롤러는 파드 템플릿으로 파드를 생성하고 +{{< glossary_tooltip text="워크로드" term_id="workload" >}} 리소스에 대한 컨트롤러는 파드 템플릿으로 파드를 생성하고 사용자를 대신해서 이러한 파드를 관리한다. 파드템플릿은 파드를 생성하기 위한 명세이며 @@ -87,6 +91,7 @@ apiVersion: batch/v1 kind: Job metadata: name: hello +spec: template: # 이것이 파드 템플릿이다. spec: @@ -113,4 +118,3 @@ metadata: * 파드의 동작에 대해 더 알아보자. * [파드 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료) * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/) - diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index d7cc7d545b..f1f586f5d8 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -18,10 +18,10 @@ weight: 50 ### 기능 게이트 활성화 -를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와** -{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 -대해 `EvenPodsSpread` -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어야 한다. +를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와** +{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 대해 +`EvenPodsSpread` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 +활성화되어야 한다. ### 노드 레이블 @@ -160,6 +160,7 @@ spec: - 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다. - `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다. + 1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다. 2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다. @@ -191,13 +192,13 @@ spec: 토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다. - `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우. -- 서비스, 레플리케이션 컨트롤러, 레플리카 셋 또는 스테이트풀 셋에 속해있는 경우. +- 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우. 기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/profiles)에서 `PodTopologySpread` 플러그인의 일부로 설정할 수 있다. 제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로 제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러, -레플리카 셋 또는 스테이트풀 셋에서 계산한다. +레플리카 셋 또는 스테이트풀셋에서 계산한다. 예시 구성은 다음과 같다. @@ -226,17 +227,16 @@ profiles: ## 파드어피니티(PodAffinity)/파드안티어피니티(PodAntiAffinity)와의 비교 쿠버네티스에서 "어피니티(Affinity)"와 관련된 지침은 파드가 -더 많이 채워지거나 더 많이 분산되는 방식으로 스케줄 되는 방법을 제어한다. +더 많이 채워지거나 더 많이 분산되는 방식으로 스케줄 되는 방법을 제어한다. - `PodAffinity` 는, 사용자가 자격이 충족되는 토폴로지 도메인에 원하는 수의 파드를 얼마든지 채울 수 있다. - `PodAntiAffinity` 로는, 단일 토폴로지 도메인에 단 하나의 파드만 스케줄 될 수 있다. -"EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서 -고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와 -레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다. -더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation)를 참조한다. +"EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서 +고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다. +더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)를 참조한다. ## 알려진 제한사항 diff --git a/content/ko/docs/concepts/workloads/pods/pod.md b/content/ko/docs/concepts/workloads/pods/pod.md index 9f7d06d091..05de1ccb61 100644 --- a/content/ko/docs/concepts/workloads/pods/pod.md +++ b/content/ko/docs/concepts/workloads/pods/pod.md @@ -5,15 +5,21 @@ weight: 20 --- -_파드_ 는 쿠버네티스에서 생성되고 관리될 수 있는 배포 가능한 최소 컴퓨팅 단위이다. + +_파드_ 는 쿠버네티스에서 생성되고 관리될 수 있는 +배포 가능한 최소 컴퓨팅 단위이다. + ## 파드는 무엇인가? -_파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) 하나 이상의(도커 컨테이너 같은) 컨테이너 그룹이다. -이 그룹은 스토리지/네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. + +_파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) 하나 이상의(도커 컨테이너 같은) +{{< glossary_tooltip text="컨테이너" term_id="container" >}} 그룹이다. +이 그룹은 스토리지/네트워크를 공유하고, +해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠들은 항상 함께 배치되고 같이 스케줄되며, 공유 컨텍스트 내에서 구동된다. 파드는 애플리케이션에 특화된 "논리 호스트"를 모델로 하고 있다. 이것은 하나 또는 강하게 서로 결합되어 있는 여러 애플리케이션 컨테이너를 포함한다. @@ -47,9 +53,10 @@ _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지 개별 애플리케이션 컨테이너와 같이, 파드는 상대적으로 수명이 짧은 엔터티로 간주된다. [파드의 생애](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이, 파드가 만들어지고 고유한 ID(UID)가 할당되고, -재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다. +재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다. 노드가 종료되면 해당 노드로 스케줄 된 파드는 제한시간이 지나면 삭제되도록 스케줄된다. -해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다. 대신, 동일한 파드로, +해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다. +대신, 동일한 파드로, 원한다면 이름도 동일하게, 교체될 수 있지만, 새로운 UID가 부여된다. 더 자세한 내용은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다. @@ -59,6 +66,7 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것 동일한 대체품이 만들어 지더라도 관련된 것(예 : 볼륨) 또한 삭제되고 새로 만들어진다. {{< figure src="/images/docs/pod.svg" title="파드 다이어그램" width="50%" >}} + *파일 풀러(Puller)와 컨테이너 간 공유 스토리지로 퍼시스턴트 볼륨을 사용하는 웹 서버를 포함하는 멀티 컨테이너 파드.* @@ -70,7 +78,8 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것 파드는 그 구성 요소 집합보다 높은 수준의 추상화를 제공함으로써 애플리케이션 배포 및 관리를 단순화한다. 파드는 전개 단위, 수평 확장 및 복제를 한다. -공동 스케줄링, 공유 된 생애주기 (예 : 종료), 조정 된 복제, 자원 공유 및 종속성 관리는 +공동 스케줄링, +공유된 생애주기(예: 종료), 조정된 복제, 자원 공유 및 종속성 관리는 파드의 컨테이너에 대해 자동으로 처리된다. ### 리소스 공유 및 통신 @@ -80,10 +89,12 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것 파드의 모든 애플리케이션은 동일한 네트워크 네임스페이스(동일한 IP 및 포트 공간)를 사용하므로 서로를 찾고 통신하는데 `localhost`를 사용할 수 있다. 이 때문에 파드의 애플리케이션은 포트 사용을 조정 해야한다. -각 파드에는 다른 물리적 컴퓨터 및 파드들과 네트워크를 통해 통신할 수 있는 공유 네트워크 공간의 IP 주소가 있다. +각 파드에는 다른 물리적 컴퓨터 및 파드들과 +네트워크를 통해 통신할 수 있는 공유 네트워크 공간의 IP 주소가 있다. 호스트 이름은 파드 안에있는 애플리케이션 컨테이너의 파드 이름으로 설정된다. -더 자세한 내용은 [네트워킹의 더 자세한 내용](/docs/concepts/cluster-administration/networking/)을 참조한다. +더 자세한 내용은 +[네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션을 참조한다. 파드는 파드 안의 애플리케이션 컨테이너를 정의하는 것 이외에도 공유 저장 볼륨의 집합을 지정한다. 볼륨은 컨테이너가 재시작되어도 데이터가 생존할 수 있도록 하고, @@ -104,14 +115,17 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것 일반적으로 하나의 파드는 동일한 애플리케이션의 여러 인스턴스를 실행하도록 사용하지 않는다. -더 자세한 설명을 보려면 [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴] (https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)을 참조한다. +더 자세한 설명을 보려면 +[분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)을 +참조한다. ## 고려된 대안 _싱글 (도커)컨테이너에서 다중 프로그램을 실행하지 않는 이유는 무엇인가?_ 1. 투명도. 인프라에 파드 내의 컨테이너를 표시하면, - 인프라에서 프로세스 관리와 리소스 모니터링과 같은 기능을 제공할 수 있다. + 인프라에서 프로세스 관리와 리소스 모니터링과 같은 기능을 + 제공할 수 있다. 이 기능들은 사용자에게 편의를 제공한다. 1. 소프트웨어 의존성 분리. 각각의 컨테이너는 독립적으로 버전 관리, 재빌드, 재배포될 수 있다. @@ -129,19 +143,18 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하 ## 파드의 내구성 (또는 결핍) -파드는 내구성이 강한 엔터티로 취급하지는 않는다. 파드는 스케줄링 실패, -노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다. +파드는 내구성이 강한 엔터티로 취급하지는 않는다. 파드는 스케줄링 실패, 노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다. 일반적으로 사용자는 파드를 직접 만들 필요가 없다. -싱글톤이라도 대부분 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다. +싱글톤이라도 대부분 [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다. 컨트롤러는 클러스터 범위에서 복제와 롤아웃 관리 뿐 만 아니라 자가치료 기능도 제공한다. -[StatefulSet](/ko/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도 +[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과 같은 +컨트롤러는 상태를 저장하는 파드에도 위와 같은 기능 제공을 할 수 있다. 사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다. - 파드는 아래와 같은 사항들을 용이하게 하기 위해 노출이 된다: * 스케줄러 및 컨트롤러 연결 가능 @@ -149,58 +162,45 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하 * 부트스트랩과 같이 컨트롤러의 생애와 파드의 생애 분리 * 컨트롤러와 서비스의 분리 — 파드를 감시하는 엔드 포인트 컨트롤러 * 클러스터 레벨과 kubelet 레벨 기능의 깔끔한 구성 — Kubelet은 효과적인 "파드 컨트롤러" 이다. -* 계획된 삭제 또는 이미지 프리페칭과 같이 파드가 종료되기 전에 교체가 될 것이고, -삭제 전에는 확실히 교체되는 고가용성 애플리케이션. +* 계획된 삭제 또는 이미지 프리페칭과 같이 파드가 종료되기 전에 교체가 될 것이고, 삭제 전에는 확실히 교체되는 고가용성 애플리케이션. ## 파드의 종료 -파드는 클러스터의 노드에서 실행 중인 프로세스를 나타내므로 이러한 프로세스가 더 이상 필요하지 않을 때 (KILL 시그널로 강제로 죽여서 정리할 기회를 주지 않는 것과 대조적으로) 정상적으로 종료 되도록 허용하는 것이 중요하다. -사용자는 삭제를 요청할 수 있어야 하며, 프로세스가 종료 될 때 알 수 있어야 할 뿐 만 아니라, 삭제가 결국 완료되는 것을 확인 할 수 있어야 한다. -사용자가 파드를 삭제하도록 요청하면 시스템은 파드가 강제로 종료되기 전에 예정된 유예 기간을 기록하고 TERM 시그널이 각 컨테이너의 주 프로세스로 전송된다. -유예 기간이 만료되면 KILL 신호가 해당 프로세스로 전송되고 파드가 API 서버에서 삭제된다. 프로세스가 종료되기를 기다리는 동안 Kubelet 또는 컨테이너 관리자가 다시 시작되면 종료가 전체 유예 기간과 함께 재시도된다. +파드는 클러스터의 노드에서 실행 중인 프로세스를 나타내므로, 이러한 프로세스가 더 이상 필요하지 않을 때(KILL 시그널로 강제로 죽여서 정리할 기회를 주지 않는 것과 대조적으로) 정상적으로 종료 되도록 허용하는 것이 중요하다. 사용자는 삭제를 요청할 수 있어야 하며, 프로세스가 종료 될 때 알 수 있어야 할 뿐만 아니라, 삭제가 결국 완료되는 것을 확인할 수 있어야 한다. 사용자가 파드를 삭제하도록 요청하면, 시스템은 파드가 강제로 종료되기 전에 예정된 유예 기간을 기록하고, TERM 시그널이 각 컨테이너의 주 프로세스로 전송된다. 유예 기간이 만료되면, KILL 신호가 해당 프로세스로 전송되고, 파드가 API 서버에서 삭제된다. 프로세스가 종료되기를 기다리는 동안 Kubelet 또는 컨테이너 관리자가 다시 시작되면, 종료가 전체 유예 기간과 함께 재시도된다. 흐름 예시: 1. 사용자가 파드 삭제 명령을 내린다. (기본 유예 기간 30초) -1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은 것(죽은)것으로 간주되는 파드가 업데이트 된다. +1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은(죽은) 것으로 간주되는 파드가 업데이트된다. 1. 클라이언트 명령에서 파드는 "Terminating" 이라는 문구를 나타낸다. 1. (3번 단계와 동시에) Kubelet은 파드가 2번 단계에서 설정된 시간으로 인해 Terminating으로 표시되는 것을 확인하면 파드 종료 단계를 시작한다. 1. 파드의 컨테이너 중 하나에 [preStop hook](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초)를 1회 연장해서 2번 단계를 실행한다. 1. 파드의 프로세스에 TERM 시그널이 전달된다. 파드의 모든 컨테이너가 TERM 시그널을 동시에 받기 때문에 컨테이너의 종료 순서가 중요한 경우에는 `preStop` 훅이 각각 필요할 수 있음을 알아두자. 만약 `preStop` 훅을 완료하는 데 더 오랜 시간이 필요한 경우 `terminationGracePeriodSeconds` 를 수정해야 한다. -1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행중인 파드로 고려하지 않는다. -느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다. +1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행 중인 파드로 고려하지 않는다. 느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다. 1. 유예 기간이 만료되면, 파드에서 실행중이던 모든 프로세스가 SIGKILL로 종료된다. 1. Kubelet은 유예기간 0(즉시 삭제)을 세팅하여 API 서버에서 파드 삭제를 끝낼 것이다. API 서버에서 사라진 파드는 클라이언트에게서 더 이상 보이지 않는다. -기본적으로 모든 삭제는 30초 이내에 끝이난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드 하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=` 옵션을 지원한다. `0`값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제). kubectl 버전 >= 1.5 에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0`와 함께 추가 플래그인 `--force`를 지정해야 한다. +기본적으로 모든 삭제는 30초 이내에 끝이 난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=` 옵션을 지원한다. `0` 값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제). +kubectl 1.5 버전 이상에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0` 와 함께 추가 플래그인 `--force` 를 지정해야 한다. ### 파드 강제 삭제 -파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다. -API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다. -노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다. - -강제 삭제는 일부 파드의 경우 잠재적으로 위험 할 수 있으므로 주의해서 수행해야 한다. -스테이트풀셋 파드의 경우 [스테이트풀셋 파드 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 작업문서를 참조한다. +파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행 중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다. API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다. 노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다. +강제 삭제는 일부 파드의 경우 잠재적으로 위험할 수 있으므로 주의해서 수행해야 한다. 스테이트풀셋 파드의 경우 [스테이트풀셋 파드 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 작업 문서를 참조한다. ## 파드 컨테이너의 특권(Privileged) 모드 -Kubernetes v1.1부터, 파드의 모든 컨테이너는 컨테이너 스펙의 `SecurityContext`의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 Linux 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일 할 필요가 없는 별도의 파드로 쉽게 만들 수 있다. +파드의 모든 컨테이너는 컨테이너 스펙의 [시큐리티 콘텍스트(security context)](/docs/tasks/configure-pod-container/security-context/)의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 리눅스 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일할 필요가 없는 별도의 파드로 쉽게 만들 수 있다. -마스터가 Kubernetes v1.1 이상에서 실행 중이고, 노드가 v1.1 보다 낮은 버전을 실행중인 경우 새 권한이 부여 된 파드는 api-server에 의해 승인되지만 시작되지는 않는다. 이것들은 pending 상태가 될 것이다. -사용자가 `kubectl describe pod FooPodName` 을 호출하면 사용자는 파드가 pending 상태에 있는 이유를 볼 수 있다. describe 명령 출력의 이벤트 테이블은 다음과 같다. -`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'` - -마스터가 v1.1보다 낮은 버전에서 실행중인 경우 특권을 갖는 파드를 만들 수 없다. 유저가 특권을 갖는 컨테이너가 있는 파드를 만들려고 하면 다음과 같은 오류가 발생한다. -`The Pod "FooPodName" is invalid. -spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'` +{{< note >}} +이와 같은 설정을 위해서는 컨테이너 런타임에서 반드시 특권 컨테이너 개념을 지원해야 한다. +{{< /note >}} ## API 오브젝트 -파드는 쿠버네티스 REST API에서 최상위 리소스이다. API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다: +파드는 쿠버네티스 REST API에서 최상위 리소스이다. +API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다: [파드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core). 파드 오브젝트에 대한 매니페스트를 생성할때는 지정된 이름이 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)인지 확인해야 한다. - - +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인해야 한다. diff --git a/content/ko/docs/concepts/workloads/pods/podpreset.md b/content/ko/docs/concepts/workloads/pods/podpreset.md index 4b37e0c232..9793dbc52e 100644 --- a/content/ko/docs/concepts/workloads/pods/podpreset.md +++ b/content/ko/docs/concepts/workloads/pods/podpreset.md @@ -1,4 +1,6 @@ --- + + title: 파드 프리셋 content_type: concept weight: 50 @@ -25,6 +27,7 @@ weight: 50 제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드 템플릿 작성자는 해당 서비스에 대한 모든 세부 사항을 알 필요가 없다. + ## 클러스터에서 파드프리셋 활성화하기 {#enable-pod-preset} 클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다. diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 9dd0b23cd3..8f9ef72ba6 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -47,8 +47,8 @@ card: - [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를 참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다. - 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/docs/contribute/new-content/new-content/#changes-using-github) GitHub에서의 이슈 제기에 대해 자세히 알아봅니다. - 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 [풀 리퀘스트 검토](/docs/contribute/review/reviewing-prs/)를 합니다. -- 쿠버네티스 [컨텐츠](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다. -- [페이지 템플릿 사용](/docs/contribute/style/page-templates/)과 [휴고(Hugo) 단축코드(shortcodes)](/docs/contribute/style/hugo-shortcodes/)를 사용해서 큰 변경을 하는 방법에 대해 배워봅니다. +- 쿠버네티스 [콘텐츠](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다. +- [페이지 템플릿 사용](/docs/contribute/style/page-content-types/)과 [휴고(Hugo) 단축코드(shortcodes)](/docs/contribute/style/hugo-shortcodes/)를 사용해서 큰 변경을 하는 방법에 대해 배워봅니다. ## 다음 단계 @@ -67,12 +67,10 @@ SIG Docs는 여러가지 방법으로 의견을 나누고 있습니다. 자신을 소개하세요! - 더 광범위한 토론이 이루어지고 공식적인 결정이 기록이 되는 [`kubernetes-sig-docs` 메일링 리스트에 가입](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 하세요. -- [주간 SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 발표되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoon) 클라이언트](https://zoom.us/download)를 다운로드 하거나 전화를 이용하여 전화 접속해야 합니다. +- [주간 SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 발표되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoom) 클라이언트](https://zoom.us/download)를 다운로드하거나 전화를 이용하여 전화 접속해야 합니다. ## 다른 기여 방법들 - [쿠버네티스 커뮤니티 사이트](/community/)를 방문하십시오. 트위터 또는 스택 오버플로우에 참여하고, 현지 쿠버네티스 모임과 이벤트 등에 대해 알아봅니다. - [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 쿠버네티스 기능 개발에 참여합니다. - [블로그 게시물 또는 사례 연구](/docs/contribute/new-content/blogs-case-studies/)를 제출합니다. - - diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md index 72d6c7f3d7..f6e0ae13b7 100644 --- a/content/ko/docs/contribute/localization_ko.md +++ b/content/ko/docs/contribute/localization_ko.md @@ -132,21 +132,29 @@ weight: 10 ### API 오브젝트 용어 한글화 방침 -API 오브젝트 중 `kubectl api-resources` 결과의 `kind`에 해당하는 오브젝트는 +일반적으로 `kubectl api-resources` 결과의 `kind` 에 해당하는 API 오브젝트는 [국립국어원 외래어 표기법](http://kornorms.korean.go.kr/regltn/regltnView.do?regltn_code=0003#a)에 -따라 한글 표기한다. 예를 들면 다음과 같다. +따라 한글로 표기하고 영문을 병기한다. 예를 들면 다음과 같다. + +API 오브젝트(kind) | 한글화(외래어 표기 및 영문 병기) +--- | --- +ClusterRoleBinding | 클러스터롤바인딩(ClusterRoleBinding) +ConfigMap | 컨피그맵(ConfigMap) +Deployment | 디플로이먼트(Deployment) +PersistentVolumeClaim | 퍼시스턴트볼륨클레임(PersistentVolumeClaim) +... | ... + +`kind` 에 속하는 API 오브젝트 중에서도 일부는 표현의 간결함을 위해 한영병기를 하지 않는 등의 예외가 있으며, +예외에 대해서는 [한글화 용어집](#한글화-용어집)에 등록된 방식을 준용한다. 예를 들면 다음과 같다. API 오브젝트(kind) | 한글화(외래어 표기) --- | --- -ClusterRoleBinding | 클러스터롤바인딩 -ConfigMap | 컨피그맵 -Deployment | 디플로이먼트 Pod | 파드 -PersistentVolumeClaim | 퍼시스턴트볼륨클레임 Service | 서비스 ... | ... -그 이외의 API 오브젝트는, [한글화 용어집](#한글화-용어집)에 등록된 용어인 경우를 제외하고, + +`kind` 에 속하지 않는 API 오브젝트는, [한글화 용어집](#한글화-용어집)에 등록된 용어인 경우를 제외하고, 모두 원문 그대로 표기한다. 예를 들면 다음과 같다. API 오브젝트(kind가 아닌 경우) | 한글화(원문 유지) @@ -287,8 +295,6 @@ Daemon | 데몬 | DaemonSet | 데몬셋(DaemonSet) | API 오브젝트인 경우 Dashboard | 대시보드 | Data Plane | 데이터 플레인 | -Default Limit | 기본 상한 | -Default Request | 기본 요청량 | Deployment | 디플로이먼트(Deployment) | API 오브젝트인 경우 deprecated | 사용 중단(deprecated) | descriptor | 디스크립터, 식별자 | @@ -348,6 +354,7 @@ label | 레이블 | Lease | 리스(Lease) | API 오브젝트인 경우 lifecycle | 라이프사이클 | LimitRange | 리밋레인지(LimitRange) | API 오브젝트인 경우 +limit | 한도(limit) | 리소스의 개수나 용량을 한정하기 위한 수치로 사용된 경우 선택적으로 사용 (API 오브젝트의 속성으로 limit을 사용한 경우는 가능한 영문 유지) Linux | 리눅스 | load | 부하 | LocalSubjectAccessReview | 로컬서브젝트액세스리뷰(LocalSubjectAccessReview) | API 오브젝트인 경우 @@ -357,7 +364,6 @@ Lost | Lost | 클레임의 상태에 한함 Machine | 머신 | manifest | 매니페스트 | Master | 마스터 | -max limit/request ratio | 최대 상한/요청량 비율 | metadata | 메타데이터 | metric | 메트릭 | masquerading | 마스커레이딩 | @@ -382,7 +388,7 @@ PersistentVolume | 퍼시스턴트볼륨(PersistentVolume) | API 오브젝트인 PersistentVolumeClaim | 퍼시스턴트볼륨클레임(PersistentVolumeClaim) | API 오브젝트인 경우 pipeline | 파이프라인 | placeholder pod | 플레이스홀더(placeholder) 파드 | -Pod | 파드(Pod) | API 오브젝트인 경우 +Pod | 파드 | API 오브젝트인 경우에도 표현의 간결함을 위해 한영병기를 하지 않음 Pod Preset | 파드 프리셋 | PodAntiAffinity | 파드안티어피니티(PodAntiAffinity) | PodDisruptionBudget | PodDisruptionBudget | API 오브젝트인 경우 @@ -410,8 +416,8 @@ ReplicaSet | 레플리카셋(ReplicaSet) | API 오브젝트인 경우 replicas | 레플리카 | ReplicationController | 레플리케이션컨트롤러(ReplicationController) | API 오브젝트인 경우 repository | 리포지터리 | +request | 요청(request) | 리소스의 개수나 용량에 대한 요청 수치를 표현하기 위해 사용된 경우 선택적으로 사용 (API 오브젝트 속성으로 request를 사용한 경우는 가능한 영문을 유지) resource | 리소스 | -Resource Limit | 리소스 상한 | ResourceQuota | 리소스쿼터(ResourceQuota) | API 오브젝트인 경우 return | 반환하다 | revision | 리비전 | @@ -431,7 +437,7 @@ Selector | 셀렉터 | Self-healing | 자가 치유 | SelfSubjectAccessReview | 셀프서브젝트액세스리뷰(SelfSubjectAccessReview) | API 오브젝트인 경우 SelfSubjectRulesReview | SelfSubjectRulesReview | API 오브젝트이지만 용어를 구성하는 단어 중 복수형 Rules를 '룰스'로 외래어 표기하는 경우 한국어 독자에게 다소 생경할 수 있어 예외적으로 영문 용어를 사용함 -Service | 서비스(Service) | API 오브젝트인 경우 +Service | 서비스 | API 오브젝트인 경우에도 표현의 간결함을 위해 한영병기를 하지 않음 ServiceAccount | 서비스어카운트(ServiceAccount) | API 오브젝트인 경우 service discovery | 서비스 디스커버리 | service mesh | 서비스 메시 | @@ -479,5 +485,3 @@ Windows | 윈도우 | Worker | 워커 | 노드의 형태에 한함 Workload | 워크로드 | YAML | YAML | - - diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md index 6f01e04135..46439d3565 100644 --- a/content/ko/docs/contribute/new-content/open-a-pr.md +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -408,7 +408,7 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 git rebase -i HEAD~ ``` - 커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. `HEAD~` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다. 출력은 다음과 비슷하다. diff --git a/content/ko/docs/contribute/new-content/overview.md b/content/ko/docs/contribute/new-content/overview.md index c17a557c6d..f86bbb841f 100644 --- a/content/ko/docs/contribute/new-content/overview.md +++ b/content/ko/docs/contribute/new-content/overview.md @@ -19,7 +19,7 @@ weight: 5 - 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다. - 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다. -- [페이지 템플릿](/docs/contribute/style/page-templates/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다. +- [페이지 템플릿](/docs/contribute/style/page-content-types/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다. - 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러 [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다. - 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각 언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에 의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어, 한글 문서의 소스는 `/content/ko/docs/` 에 저장된다. - 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다. diff --git a/content/ko/docs/contribute/participating.md b/content/ko/docs/contribute/participating.md index 8f9cb0b5f6..a1897f350c 100644 --- a/content/ko/docs/contribute/participating.md +++ b/content/ko/docs/contribute/participating.md @@ -36,7 +36,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. ## 역할과 책임 -- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여시 [CLA에 서명](/docs/contribute/new-content/overview/#sign-the-cla))하고 GitHub 계정을 가지고 있어야 한다. +- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여 시 [CLA에 서명](/docs/contribute/new-content/overview/#sign-the-cla)하고 GitHub 계정을 가지고 있어야 한다. - 쿠버네티스 조직의 **멤버** 는 쿠버네티스 프로젝트에 시간과 노력을 투자한 기여자이다. 일반적으로 승인되는 변경이 되는 풀 리퀘스트를 연다. 멤버십 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참조한다. - SIG Docs의 **리뷰어** 는 쿠버네티스 조직의 일원으로 문서 풀 리퀘스트에 관심을 표명했고, SIG Docs 승인자에 @@ -75,7 +75,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. - [모든 사람](#모든-사람) 하위에 나열된 모든 것 - 풀 리퀘스트 코멘트에 `/lgtm` 을 사용해서 LGTM(looks good to me) 레이블을 붙일 수 있다. - 풀 리퀘스트에 이미 LGTM 과 승인 레이블이 있는 경우에 풀 리퀘스트가 병합되지 않도록 코멘트에 `/hold` 를 사용할 수 있다. -- 코멘트에 `/assgin` 을 사용해서 풀 리퀘스트에 리뷰어를 배정한다. +- 코멘트에 `/assign` 을 사용해서 풀 리퀘스트에 리뷰어를 배정한다. ### 멤버 되기 @@ -309,9 +309,6 @@ PR 소유자에게 조언하는데 활용된다. 쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다. -- [신규 컨텐츠 기여하기](/docs/contribute/overview/) -- [컨텐츠 검토하기](/docs/contribute/review/reviewing-prs) -- [문서 스타일 가이드](/docs/contribute/style/) - - - +- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/overview/) +- [콘텐츠 검토하기](/ko/docs/contribute/review/reviewing-prs/) +- [문서 스타일 가이드](/ko/docs/contribute/style/) diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md index b7416f505a..06c2b81f21 100644 --- a/content/ko/docs/contribute/review/reviewing-prs.md +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -86,7 +86,7 @@ weight: 10 - 이 PR이 페이지 제목, slug/alias 또는 앵커(anchor) 링크를 변경 또는 제거하는가? 그렇다면, 이 PR의 결과로 끊어진 링크가 있는가? slug를 변경 없이 페이지 제목을 변경하는 등의 다른 옵션이 있는가? - PR이 새로운 페이지를 소개하는가? 그렇다면, - - 페이지가 올바른 [페이지 템플릿](/docs/contribute/style/page-templates/)과 연관된 Hugo 단축 코드를 사용하는가? + - 페이지가 올바른 [페이지 콘텐츠 타입](/docs/contribute/style/page-content-types/)과 연관된 Hugo 단축 코드를 사용하는가? - 섹션의 측면 탐색에 페이지가 올바르게 나타나는가? - 페이지가 [문서 홈](/ko/docs/home/) 목록에 나타나야 하는가? - 변경 사항이 Netlify 미리보기에 표시되는가? 목록, 코드 블록, 표, 메모 및 이미지에 특히 주의한다. diff --git a/content/ko/docs/contribute/style/write-new-topic.md b/content/ko/docs/contribute/style/write-new-topic.md index 0c8ab86fbf..ac7252a50f 100644 --- a/content/ko/docs/contribute/style/write-new-topic.md +++ b/content/ko/docs/contribute/style/write-new-topic.md @@ -28,9 +28,8 @@ weight: 20 튜토리얼 | 튜토리얼 페이지는 여러 쿠버네티스의 특징들을 하나로 묶어서 목적을 달성하는 방법을 보여준다. 튜토리얼은 독자들이 페이지를 읽을 때 실제로 할 수 있는 몇 가지 단계의 순서를 제공한다. 또는 관련 코드 일부에 대한 설명을 제공할 수도 있다. 예를 들어 튜토리얼은 코드 샘플의 연습을 제공할 수 있다. 튜토리얼에는 쿠버네티스의 특징에 대한 간략한 설명이 포함될 수 있지만 개별 기능에 대한 자세한 설명은 관련 개념 문서과 연결지어야 한다. {{< /table >}} -새 페이지에 대한 템플릿을 사용하자. 각 페이지 타입에 있는 -[템플릿](/docs/contribute/style/page-templates/) -은 문서를 작성할 때 사용할 수 있다. 템플릿을 사용하면 +작성하는 각각의 새 페이지에 대해 [콘텐츠 타입](/docs/contribute/style/page-content-types/)을 +사용하자. 페이지 타입을 사용하면 지정된 타입의 문서 간에 일관성을 보장할 수 있다. ## 제목과 파일 이름 선택 @@ -38,12 +37,12 @@ weight: 20 검색 엔진에서 찾을 키워드가 있는 제목을 선택하자. 제목에 있는 단어를 하이픈으로 구분하여 사용하는 파일 이름을 만들자. 예를 들어 -[HTTP 프록시를 사용하여 쿠버네티스 API에 접근](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) +[HTTP 프록시를 사용하여 쿠버네티스 API에 접근](/docs/tasks/extend-kubernetes/http-proxy-access-api/) 이라는 제목의 문서는 `http-proxy-access-api.md`라는 이름의 파일을 가진다. "쿠버네티스"가 이미 해당 주제의 URL에 있기 때문에 파일 이름에 "쿠버네티스" 를 넣을 필요가 없다. 예를 들면 다음과 같다. - /docs/tasks/access-kubernetes-api/http-proxy-access-api/ + /docs/tasks/extend-kubernetes/http-proxy-access-api/ ## 전문에 항목 제목 추가 @@ -164,6 +163,6 @@ kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml ## {{% heading "whatsnext" %}} -* [페이지 템플릿 사용](/docs/contribute/page-templates/))에 대해 알아보기. +* [페이지 콘텐츠 타입 사용](/docs/contribute/style/page-content-types/)에 대해 알아보기. * [풀 리퀘스트 작성](/docs/contribute/new-content/open-a-pr/)에 대해 알아보기. diff --git a/content/ko/docs/home/_index.md b/content/ko/docs/home/_index.md index 2432f8781c..b47bbf5c14 100644 --- a/content/ko/docs/home/_index.md +++ b/content/ko/docs/home/_index.md @@ -43,7 +43,7 @@ cards: title: "교육" description: "공인 쿠버네티스 인증을 획득하고 클라우드 네이티브 프로젝트를 성공적으로 수행하세요!" button: "교육 보기" - button_path: "/training" + button_path: "/training" - name: reference title: 레퍼런스 정보 찾기 description: 용어, 커맨드 라인 구문, API 자원 종류, 그리고 설치 툴 문서를 살펴본다. @@ -54,8 +54,8 @@ cards: description: 이 프로젝트가 처음인 사람이든, 오래 활동한 사람이든 상관없이 누구나 기여할 수 있다. button: 문서에 기여하기 button_path: "/ko/docs/contribute" -- name: download - title: 쿠버네티스 내려받기 +- name: release-notes + title: 릴리스 노트 description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다. - name: about title: 문서에 대하여 diff --git a/content/ko/docs/reference/glossary/aggregation-layer.md b/content/ko/docs/reference/glossary/aggregation-layer.md index 404257f20b..b09902c287 100644 --- a/content/ko/docs/reference/glossary/aggregation-layer.md +++ b/content/ko/docs/reference/glossary/aggregation-layer.md @@ -16,4 +16,4 @@ tags: -{{< glossary_tooltip text="쿠버네티스 API 서버" term_id="kube-apiserver" >}}에서 [추가 API 지원](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)을 구성하였으면, 쿠버네티스 API의 URL 경로를 "요구하는" `APIService` 오브젝트 추가할 수 있다. +{{< glossary_tooltip text="쿠버네티스 API 서버" term_id="kube-apiserver" >}}에서 [추가 API 지원](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)을 구성하였으면, 쿠버네티스 API의 URL 경로를 "요구하는" `APIService` 오브젝트 추가할 수 있다. diff --git a/content/ko/docs/reference/glossary/container-env-variables.md b/content/ko/docs/reference/glossary/container-env-variables.md index 7df679f358..ab538071a5 100755 --- a/content/ko/docs/reference/glossary/container-env-variables.md +++ b/content/ko/docs/reference/glossary/container-env-variables.md @@ -2,7 +2,7 @@ title: 컨테이너 환경 변수(Container Environment Variables) id: container-env-variables date: 2018-04-12 -full_link: /ko/docs/concepts/containers/container-environment-variables/ +full_link: /ko/docs/concepts/containers/container-environment/ short_description: > 컨테이너 환경 변수는 파드에서 동작 중인 컨테이너에 유용한 정보를 제공하기 위한 이름=값 쌍이다. diff --git a/content/ko/docs/reference/glossary/customresourcedefinition.md b/content/ko/docs/reference/glossary/customresourcedefinition.md index 3e680ca2bd..97ef81c1c8 100755 --- a/content/ko/docs/reference/glossary/customresourcedefinition.md +++ b/content/ko/docs/reference/glossary/customresourcedefinition.md @@ -2,7 +2,7 @@ title: 커스텀 리소스 데피니션(CustomResourceDefinition) id: CustomResourceDefinition date: 2018-04-12 -full_link: /docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/ +full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ short_description: > 사용자 정의 서버를 완전히 새로 구축할 필요가 없도록 쿠버네티스 API 서버에 추가할 리소스를 정의하는 사용자 정의 코드. diff --git a/content/ko/docs/reference/glossary/image.md b/content/ko/docs/reference/glossary/image.md index d7583343b8..adfe414d57 100755 --- a/content/ko/docs/reference/glossary/image.md +++ b/content/ko/docs/reference/glossary/image.md @@ -10,7 +10,7 @@ aka: tags: - fundamental --- - {{< glossary_tooltip term_id="container" >}}의 저장된 인스턴스이며, 애플리케이션 구동에 필요한 소프트웨어 집합을 가지고 있다. + {{< glossary_tooltip text="컨테이너" term_id="container" >}}의 저장된 인스턴스이며, 애플리케이션 구동에 필요한 소프트웨어 집합을 가지고 있다. diff --git a/content/ko/docs/reference/glossary/statefulset.md b/content/ko/docs/reference/glossary/statefulset.md index afb2dd3ba9..54fc5d0526 100755 --- a/content/ko/docs/reference/glossary/statefulset.md +++ b/content/ko/docs/reference/glossary/statefulset.md @@ -1,12 +1,12 @@ --- -title: 스테이트풀 셋(StatefulSet) +title: 스테이트풀셋(StatefulSet) id: statefulset date: 2018-04-12 full_link: /ko/docs/concepts/workloads/controllers/statefulset/ short_description: > 내구성이 있는 스토리지와 파드별로 지속성 식별자를 사용해서 파드 집합의 디플로이먼트와 스케일링을 관리한다. -aka: +aka: tags: - fundamental - core-object @@ -15,7 +15,7 @@ tags: --- {{< glossary_tooltip text="파드" term_id="pod" >}} 집합의 디플로이먼트와 스케일링을 관리하며, 파드들의 *순서 및 고유성을 보장한다* . - + {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 유사하게, 스테이트풀셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다. diff --git a/content/ko/docs/reference/glossary/volume.md b/content/ko/docs/reference/glossary/volume.md index 24e37a3165..bbe78369a2 100755 --- a/content/ko/docs/reference/glossary/volume.md +++ b/content/ko/docs/reference/glossary/volume.md @@ -11,7 +11,7 @@ tags: - core-object - fundamental --- - 데이터를 포함하고 있는 디렉토리이며, {{< glossary_tooltip term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다. + 데이터를 포함하고 있는 디렉토리이며, {{< glossary_tooltip text="파드" term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다. diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md index d70eb8939a..0a4a3fefbe 100644 --- a/content/ko/docs/reference/kubectl/overview.md +++ b/content/ko/docs/reference/kubectl/overview.md @@ -7,14 +7,13 @@ card: weight: 20 --- -{{% capture overview %}} + Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 파일을 지정할 수 있다. 이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. 지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다. 설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다. -{{% /capture %}} -{{% capture body %}} + ## 구문 @@ -441,7 +440,7 @@ The following kubectl-compatible plugins are available: /usr/local/bin/kubectl-bar ``` ```shell -# 또한, 이 명령은 예를 들어 실행 불가능한 파일이거나, +# 또한, 이 명령은 예를 들어 실행 불가능한 파일이거나, # 다른 플러그인에 의해 가려진 플러그인에 대해 # 경고할 수 있다 sudo chmod -x /usr/local/bin/kubectl-foo @@ -486,10 +485,9 @@ Current user: plugins-user 플러그인에 대한 자세한 내용은 [cli plugin 예제](https://github.com/kubernetes/sample-cli-plugin)를 참고한다. -{{% /capture %}} -{{% capture whatsnext %}} +## {{% heading "whatsnext" %}} [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다. -{{% /capture %}} + diff --git a/content/ko/docs/reference/using-api/api-overview.md b/content/ko/docs/reference/using-api/api-overview.md index e7a0b8ce8d..098e9ad9bf 100644 --- a/content/ko/docs/reference/using-api/api-overview.md +++ b/content/ko/docs/reference/using-api/api-overview.md @@ -83,7 +83,7 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. [사용자 정의 리소스](/docs/concepts/api-extension/custom-resources/)로 API를 확장하는 경우에는 다음 두 종류의 경로가 지원된다. - 기본적인 CRUD 요구에는 - [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) + [커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) - 쿠버네티스 API의 의미론적 전체 집합으로 사용자만의 Apiserver를 구현하려는 경우에는 [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md) diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index 4757354dca..321cf5ed2f 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -47,6 +47,7 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery | Go | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) | | Java (OSGi) | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) | | Java (Fabric8, OSGi) | [github.com/fabric8io/kubernetes-client](https://github.com/fabric8io/kubernetes-client) | +| Java | [github.com/manusa/yakc](https://github.com/manusa/yakc) | | Lisp | [github.com/brendandburns/cl-k8s](https://github.com/brendandburns/cl-k8s) | | Lisp | [github.com/xh4/cube](https://github.com/xh4/cube) | | Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) | diff --git a/content/ko/docs/setup/best-practices/certificates.md b/content/ko/docs/setup/best-practices/certificates.md index 0ce3fe2270..f5d1486f39 100644 --- a/content/ko/docs/setup/best-practices/certificates.md +++ b/content/ko/docs/setup/best-practices/certificates.md @@ -29,7 +29,7 @@ weight: 40 * [front-proxy][proxy]를 위한 클라이언트와 서버 인증서 {{< note >}} -`front-proxy` 인증서는 kube-proxy에서 [API 서버 확장](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)을 지원할 때만 kube-proxy에서 필요하다. +`front-proxy` 인증서는 kube-proxy에서 [API 서버 확장](/docs/tasks/extend-kubernetes/setup-extension-api-server/)을 지원할 때만 kube-proxy에서 필요하다. {{< /note >}} etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. @@ -160,6 +160,6 @@ KUBECONFIG= kubectl config use-context default-system [usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage [kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/ -[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/ +[proxy]: /docs/tasks/extend-kubernetes/configure-aggregation-layer/ diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md index e8d169af96..7cc0eb9874 100644 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -135,7 +135,7 @@ Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다. -no body in request- ``` - 서비스나 클러스터가 더 이상 구동되지 않도록 하려면, 삭제한다. + 서비스나 클러스터가 더 이상 구동되지 않도록 하려면, 삭제한다. 7. `hello-minikube` 서비스 삭제 @@ -197,21 +197,21 @@ Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다. 이 커멘드는 또한 [kubectl](/docs/user-guide/kubectl-overview/)도 설정해서 클러스터와 통신할 수 있도록 한다. {{< note >}} -웹 프록시 뒤에 있다면, `minikube start` 커맨드에 해당 정보를 전달해야 한다. +웹 프록시 뒤에 있다면, `minikube start` 커맨드에 해당 정보를 전달해야 한다. ```shell https_proxy= minikube start --docker-env http_proxy= --docker-env https_proxy= --docker-env no_proxy=192.168.99.0/24 ``` 불행하게도, 환경 변수 설정만으로는 되지 않는다. -Minikube는 또한 "minikube" 컨텍스트를 생성하고 이를 kubectl의 기본값으로 설정한다. -이 컨텍스트로 돌아오려면, 다음의 코멘드를 입력한다. `kubectl config use-context minikube`. +Minikube는 또한 "minikube" 콘텍스트를 생성하고 이를 kubectl의 기본값으로 설정한다. +이 콘텍스트로 돌아오려면, 다음의 코멘드를 입력한다. `kubectl config use-context minikube`. {{< /note >}} #### 쿠버네티스 버전 지정하기 -`minikube start` 코멘드에 `--kubernetes-version` 문자열을 -추가해서 Minikube에서 사용할 쿠버네티스 버전을 지정할 수 있다. +`minikube start` 코멘드에 `--kubernetes-version` 문자열을 +추가해서 Minikube에서 사용할 쿠버네티스 버전을 지정할 수 있다. 예를 들어 버전 {{< param "fullversion" >}}를 구동하려면, 다음과 같이 실행한다. ``` @@ -239,7 +239,7 @@ Minikube는 다음의 드라이버를 지원한다. * vmware ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) (VMware unified driver) * parallels ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/)) * none (쿠버네티스 컴포넌트를 가상 머신이 아닌 호스트 상에서 구동한다. 리눅스를 실행중이어야 하고, {{< glossary_tooltip term_id="docker" >}}가 설치되어야 한다.) - + {{< caution >}} `none` 드라이버를 사용한다면 일부 쿠버네티스 컴포넌트는 Minikube 환경 외부에 있는 부작용이 있는 권한을 가진 컨테이너로 실행된다. 이런 부작용은 개인용 워크스테이션에는 `none` 드라이버가 권장하지 않는 것을 의미 한다. {{< /caution >}} @@ -357,27 +357,34 @@ Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설 ### 클러스터 중지 `minikube stop` 명령어는 클러스터를 중지하는데 사용할 수 있다. 이 명령어는 Minikube 가상 머신을 종료하지만, 모든 클러스터 상태와 데이터를 보존한다. -클러스터를 다시 시작하면 이전의 상태로 돌려줍니다. +클러스터를 다시 시작하면 이전의 상태로 돌려준다. ### 클러스터 삭제 `minikube delete` 명령은 클러스터를 삭제하는데 사용할 수 있다. 이 명령어는 Minikube 가상 머신을 종료하고 삭제한다. 어떤 데이터나 상태도 보존되지 않다. ### Minikube 업그레이드 -macOS를 사용하는 경우 기존에 설치된 Minikube를 업그레이드하려면 [Minikube 업그레이드](https://minikube.sigs.k8s.io/docs/start/macos/#upgrading-minikube)를 참조한다. +macOS를 사용하고 있고 [Brew 패키지 관리자](https://brew.sh/)가 설치되어 있다면 다음과 같이 실행한다. + +```shell +brew update +brew upgrade minikube +``` ## 클러스터와 상호 작용하기 ### Kubectl -`minikube start` 명령어는 Minikube로 부르는 [kubectl 컨텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)를 생성한다. -이 컨텍스트는 Minikube 클러스터와 통신하는 설정을 포함한다. +`minikube start` 명령어는 Minikube로 부르는 [kubectl 콘텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)를 생성한다. +이 콘텍스트는 Minikube 클러스터와 통신하는 설정을 포함한다. -Minikube는 이 컨텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 +Minikube는 이 콘텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 다음을 실행하자. -`kubectl config use-context minikube`을 실행하자. +`kubectl config use-context minikube` -혹은 `kubectl get pods --context=minikube`처럼 코멘드를 실행할때마다 매번 컨텍스트를 전달한다. +혹은 다음과 같이 커맨드를 실행할 때마다 매번 콘텍스트를 전달한다. + +`kubectl get pods --context=minikube` ### 대시보드 @@ -454,7 +461,7 @@ spec: ## 애드온 -Minikube에서 커스텀 애드온을 적절히 시작하고 재시작할 수 있으려면, +Minikube에서 커스텀 애드온을 적절히 시작하고 재시작할 수 있으려면, Minikube와 함께 시작하려는 애드온을 `~/.minikube/addons` 디렉터리에 두자. 폴더 내부의 애드온은 Minikube VM으로 이동되어 Minikube가 시작하거나 재시작될 때에 함께 실행된다. @@ -497,7 +504,7 @@ Minikube에 대한 더 자세한 정보는, [제안](https://git.k8s.io/communit * **개발 가이드**: 풀 리퀘스트를 보내는 방법에 대한 개요는 [기여하기](https://minikube.sigs.k8s.io/docs/contrib/)를 살펴보자. * **Minikube 빌드**: Minikube를 소스에서 빌드/테스트하는 방법은 [빌드 가이드](https://minikube.sigs.k8s.io/docs/contrib/building/)를 살펴보자. * **새 의존성 추가하기**: Minikube에 새 의존성을 추가하는 방법에 대해서는, [의존성 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/drivers/)를 보자. -* **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는, [애드온 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/addons/)를 보자. +* **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는, [애드온 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/addons/)를 보자. * **MicroK8s**: 가상 머신을 사용하지 않으려는 Linux 사용자는 대안으로 [MicroK8s](https://microk8s.io/)를 고려할 수 있다. ## 커뮤니티 diff --git a/content/ko/docs/setup/release/notes.md b/content/ko/docs/setup/release/notes.md index 270287b1b3..3bc3dad135 100644 --- a/content/ko/docs/setup/release/notes.md +++ b/content/ko/docs/setup/release/notes.md @@ -2,7 +2,7 @@ title: v1.18 릴리스 노트 weight: 10 card: - name: 다운로드 + name: release-notes weight: 20 anchors: - anchor: "#" @@ -306,7 +306,7 @@ NodeLocal DNSCache는 dnsCache 파드를 데몬셋으로 실행하여 clusterDNS - Kube-proxy: iptables 프록시에 이중 스택 IPv4/IPv6 지원이 추가되었다. ([#82462](https://github.com/kubernetes/kubernetes/pull/82462), [@vllry](https://github.com/vllry)) [SIG 네트워크] - Kubeadm은 이제 kube-controller-manager에 대한 이중 스택 노드 cidr 마스크의 자동 계산을 지원한다. ([#85609](https://github.com/kubernetes/kubernetes/pull/85609), [@Arvinderpal](https://github.com/Arvinderpal)) [SIG 클러스터 라이프사이클] - Kubeadm: 잡(Job)을 배포하는 업그레이드된 헬스 체크를 추가한다. ([#81319](https://github.com/kubernetes/kubernetes/pull/81319), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클] -- Kubeadm: 실험 기능 게이트 PublicKeysECDSA를 추가하여 "kubeadm init"에서 ECDSA 인증서가 있는 +- Kubeadm: 실험 기능 게이트 PublicKeysECDSA를 추가하여 "kubeadm init"에서 ECDSA 인증서가 있는 클러스터를 생성할 수 있게 한다. "kubeadm alpha certs renew"을 사용하여 기존 ECDSA 인증서의 갱신도 지원되지만, 즉시 또는 업그레이드 중에 RSA와 ECDSA 알고리즘간에 전환하지는 않는다. ([#86953](https://github.com/kubernetes/kubernetes/pull/86953), [@rojkov](https://github.com/rojkov)) [SIG API Machinery, Auth 및 클러스터 라이프사이클] - Kubeadm: JSON, YAML, Go 템플릿 및 JsonPath 형식으로 'kubeadm config images list' 커맨드의 구조화된 출력을 구현했다. ([#86810](https://github.com/kubernetes/kubernetes/pull/86810), [@bart0sh](https://github.com/bart0sh)) [SIG 클러스터 라이프사이클] - Kubeadm: kubeconfig 인증서 갱신 시, 내장된 CA를 디스크의 CA와 동기화된 상태로 유지한다. ([#88052](https://github.com/kubernetes/kubernetes/pull/88052), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클] @@ -689,8 +689,8 @@ filename | sha512 hash - Add `rest_client_rate_limiter_duration_seconds` metric to component-base to track client side rate limiter latency in seconds. Broken down by verb and URL. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, Cluster Lifecycle and Instrumentation] - Allow user to specify resource using --filename flag when invoking kubectl exec ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing] -- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver. - After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect. +- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver. + After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect. The flag min value is 0 (off), max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point. Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery] - Azure: add support for single stack IPv6 ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG Cloud Provider] @@ -739,7 +739,7 @@ filename | sha512 hash - Kubelets perform fewer unnecessary pod status update operations on the API server. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Scalability] - Plugin/PluginConfig and Policy APIs are mutually exclusive when running the scheduler ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] - Specifying PluginConfig for the same plugin more than once fails scheduler startup. - + Specifying extenders and configuring .ignoredResources for the NodeResourcesFit plugin fails ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] - Support TLS Server Name overrides in kubeconfig file and via --tls-server-name in kubectl ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and CLI] - Terminating a restartPolicy=Never pod no longer has a chance to report the pod succeeded when it actually failed. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Testing] @@ -806,18 +806,18 @@ filename | sha512 hash If you are setting `--redirect-container-streaming=true`, then you must migrate off this configuration. The flag will no longer be able to be enabled starting in v1.20. If you are not setting the flag, no action is necessary. ([#88290](https://github.com/kubernetes/kubernetes/pull/88290), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Node] - Yes. - + Feature Name: Support using network resources (VNet, LB, IP, etc.) in different AAD Tenant and Subscription than those for the cluster. - + Changes in Pull Request: - + 1. Add properties `networkResourceTenantID` and `networkResourceSubscriptionID` in cloud provider auth config section, which indicates the location of network resources. 2. Add function `GetMultiTenantServicePrincipalToken` to fetch multi-tenant service principal token, which will be used by Azure VM/VMSS Clients in this feature. 3. Add function `GetNetworkResourceServicePrincipalToken` to fetch network resource service principal token, which will be used by Azure Network Resource (Load Balancer, Public IP, Route Table, Network Security Group and their sub level resources) Clients in this feature. 4. Related unit tests. - + None. - + User Documentation: In PR https://github.com/kubernetes-sigs/cloud-provider-azure/pull/301 ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG Cloud Provider] ## Changes by Kind @@ -833,8 +833,8 @@ filename | sha512 hash - Added support for multiple sizes huge pages on a container level ([#84051](https://github.com/kubernetes/kubernetes/pull/84051), [@bart0sh](https://github.com/bart0sh)) [SIG Apps, Node and Storage] - AppProtocol is a new field on Service and Endpoints resources, enabled with the ServiceAppProtocol feature gate. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG Apps and Network] - Fixed missing validation of uniqueness of list items in lists with `x-kubernetes-list-type: map` or x-kubernetes-list-type: set` in CustomResources. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery] -- Introduces optional --detect-local flag to kube-proxy. - Currently the only supported value is "cluster-cidr", +- Introduces optional --detect-local flag to kube-proxy. + Currently the only supported value is "cluster-cidr", which is the default if not specified. ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling] - Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.SchedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing] - Moving Windows RunAsUserName feature to GA ([#87790](https://github.com/kubernetes/kubernetes/pull/87790), [@marosset](https://github.com/marosset)) [SIG Apps and Windows] @@ -1048,9 +1048,9 @@ filename | sha512 hash - aggragation api will have alpha support for network proxy ([#87515](https://github.com/kubernetes/kubernetes/pull/87515), [@Sh4d1](https://github.com/Sh4d1)) [SIG API Machinery] - API request throttling (due to a high rate of requests) is now reported in client-go logs at log level 2. The messages are of the form - + Throttling request took 1.50705208s, request: GET: - + The presence of these messages, may indicate to the administrator the need to tune the cluster accordingly. ([#87740](https://github.com/kubernetes/kubernetes/pull/87740), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery] - kubeadm: reject a node joining the cluster if a node with the same name already exists ([#81056](https://github.com/kubernetes/kubernetes/pull/81056), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] - disableAvailabilitySetNodes is added to avoid VM list for VMSS clusters. It should only be used when vmType is "vmss" and all the nodes (including masters) are VMSS virtual machines. ([#87685](https://github.com/kubernetes/kubernetes/pull/87685), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] @@ -1360,7 +1360,7 @@ filename | sha512 hash * Update Cluster Autoscaler to 1.17.0; changelog: https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.17.0 ([#85610](https://github.com/kubernetes/kubernetes/pull/85610), [@losipiuk](https://github.com/losipiuk)) * Filter published OpenAPI schema by making nullable, required fields non-required in order to avoid kubectl to wrongly reject null values. ([#85722](https://github.com/kubernetes/kubernetes/pull/85722), [@sttts](https://github.com/sttts)) * kubectl set resources will no longer return an error if passed an empty change for a resource. ([#85490](https://github.com/kubernetes/kubernetes/pull/85490), [@sallyom](https://github.com/sallyom)) - * kubectl set subject will no longer return an error if passed an empty change for a resource. + * kubectl set subject will no longer return an error if passed an empty change for a resource. * kube-apiserver: fixed a conflict error encountered attempting to delete a pod with gracePeriodSeconds=0 and a resourceVersion precondition ([#85516](https://github.com/kubernetes/kubernetes/pull/85516), [@michaelgugino](https://github.com/michaelgugino)) * kubeadm: add a upgrade health check that deploys a Job ([#81319](https://github.com/kubernetes/kubernetes/pull/81319), [@neolit123](https://github.com/neolit123)) * kubeadm: make sure images are pre-pulled even if a tag did not change but their contents changed ([#85603](https://github.com/kubernetes/kubernetes/pull/85603), [@bart0sh](https://github.com/bart0sh)) diff --git a/content/ko/docs/sitemap.md b/content/ko/docs/sitemap.md new file mode 100644 index 0000000000..c0a8e6c299 --- /dev/null +++ b/content/ko/docs/sitemap.md @@ -0,0 +1,114 @@ +--- +--- + + + +필터하려면 태그를 클릭하거나 드롭 다운을 사용하세요. 정순 또는 역순으로 정렬하려면 테이블 헤더를 클릭하세요. + +

+개념으로 필터:
+오브젝트로 필터:
+커맨드로 필터: +

+ +
diff --git a/content/ko/docs/tasks/_index.md b/content/ko/docs/tasks/_index.md index b9e161f26b..359ec82a9c 100644 --- a/content/ko/docs/tasks/_index.md +++ b/content/ko/docs/tasks/_index.md @@ -59,7 +59,7 @@ content_type: concept ## 스테이트풀 애플리케이션 관리하기 -스테이트풀 셋의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다. +스테이트풀셋(StatefulSet)의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다. ## 클러스터 데몬 diff --git a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index 9c70cbe8b1..0218324ff2 100644 --- a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -6,7 +6,7 @@ weight: 110 -이 페이지에서는 동일한 파드(Pod)에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨(Volume)을 이용하는지 +이 페이지에서는 동일한 파드에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨을 이용하는지 살펴본다. 컨테이너 간에 [프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를 통해 통신할 수 있는 방법을 참고하자. diff --git a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 4fa9a9492a..e279148e33 100644 --- a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -10,14 +10,14 @@ card: -이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록 -설정하는 방식을 보여준다. 클러스터, 사용자, 컨텍스트가 하나 이상의 -구성 파일에 정의된 다음 `kubectl config use-context` 커맨드를 +이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록 +설정하는 방식을 보여준다. 클러스터, 사용자, 컨텍스트가 하나 이상의 +구성 파일에 정의된 다음 `kubectl config use-context` 커맨드를 사용하여 클러스터를 빠르게 변경할 수 있다. {{< note >}} -클러스터에 접근할 수 있도록 설정하는데 사용되는 파일은 종종 *kubeconfig file* 이라고 -불린다. 이는 구성 파일을 참조하는 일반적인 방식으로 `kubeconfig`라는 이름을 가진 파일이 +클러스터에 접근할 수 있도록 설정하는데 사용되는 파일은 종종 *kubeconfig file* 이라고 +불린다. 이는 구성 파일을 참조하는 일반적인 방식으로 `kubeconfig`라는 이름을 가진 파일이 반드시 존재해야 한다는 것을 의미하는 것은 아니다. {{< /note >}} @@ -26,7 +26,12 @@ card: ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} + +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}이 설치되었는지 확인하려면, +`kubectl version --client`을 실행한다. kubectl 버전은 클러스터의 API 서버 버전과 +[마이너 버전 하나 차이 이내](/ko/docs/setup/release/version-skew-policy/#kubectl)여야 +한다. @@ -34,14 +39,14 @@ card: ## 클러스터, 사용자, 컨텍스트 정의 -당신이 개발 작업을 위한 클러스터와 스크래치 작업을 위한 클러스터를 가지고 있다고 가정해보자. -`development` 클러스터에서는 프런트 엔드 개발자들이 `frontend`라는 네임스페이스에서 -작업을 하고 있고, 스토리지 개발자들은 `storage`라는 네임스페이스에서 작업을 하고 있다. -`scratch` 클러스터에서는 개발자들이 default 네임스페이스에서 개발하거나 필요에 따라 보조 -네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고, +당신이 개발 작업을 위한 클러스터와 스크래치 작업을 위한 클러스터를 가지고 있다고 가정해보자. +`development` 클러스터에서는 프런트 엔드 개발자들이 `frontend`라는 네임스페이스에서 +작업을 하고 있고, 스토리지 개발자들은 `storage`라는 네임스페이스에서 작업을 하고 있다. +`scratch` 클러스터에서는 개발자들이 default 네임스페이스에서 개발하거나 필요에 따라 보조 +네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고, scratch 클러스터에 접근하려면 사용자네임과 패스워드로 인증을 해야 한다. -`config-exercise`라는 디렉토리를 생성한다. `config-exercise` 디렉토리에 +`config-exercise`라는 디렉토리를 생성한다. `config-exercise` 디렉토리에 다음 내용을 가진 `config-demo`라는 파일을 생성한다. ```shell @@ -68,10 +73,10 @@ contexts: name: exp-scratch ``` -구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과 +구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과 두 사용자들, 세 컨텍스트들을 기술하기 위한 프레임워크를 가진다. -`config-exercise` 디렉토리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의 +`config-exercise` 디렉토리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의 세부사항들을 추가한다. ```shell @@ -100,7 +105,7 @@ kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=develo kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter ``` -`config-demo` 파일을 열어서 세부사항들이 추가되었는지 확인한다. `config-demo` 파일을 열어보는 +`config-demo` 파일을 열어서 세부사항들이 추가되었는지 확인한다. `config-demo` 파일을 열어보는 것 대신에 `config view` 커맨드를 사용할 수도 있다. ```shell @@ -150,16 +155,16 @@ users: username: exp ``` -위 `fake-ca-file`, `fake-cert-file`, `fake-key-file`은 인증서 파일들의 실제 경로 이름을 위한 -플레이스홀더(placeholder)이다. +위 `fake-ca-file`, `fake-cert-file`, `fake-key-file`은 인증서 파일들의 실제 경로 이름을 위한 +플레이스홀더(placeholder)이다. 당신의 환경에 맞게 이들을 실제 인증서 경로로 변경해줘야 한다. -만약 당신이 인증서 파일들의 경로 대신에 여기에 포함된 base64로 인코딩된 데이터를 사용하려고 한다면 -이 경우 키에 `-data` 접미사를 추가해야 한다. 예를 들면 `certificate-authority-data`, +만약 당신이 인증서 파일들의 경로 대신에 여기에 포함된 base64로 인코딩된 데이터를 사용하려고 한다면 +이 경우 키에 `-data` 접미사를 추가해야 한다. 예를 들면 `certificate-authority-data`, `client-certificate-data`, `client-key-data` 같이 사용할 수 있다. -컨텍스트는 세 가지(클러스터, 사용자, 네임스페이스) 요소들로 이뤄진다. 예를 들어 -`dev-frontend` 컨텍스트는 "`development` 클러스터의 `frontend` 네임스페이스에 접근하는데 +컨텍스트는 세 가지(클러스터, 사용자, 네임스페이스) 요소들로 이뤄진다. 예를 들어 +`dev-frontend` 컨텍스트는 "`development` 클러스터의 `frontend` 네임스페이스에 접근하는데 `developer` 사용자 자격증명을 사용하라고 알려준다." 현재 컨텍스트를 설정한다. @@ -168,11 +173,11 @@ users: kubectl config --kubeconfig=config-demo use-context dev-frontend ``` -이제 당신이 `kubectl` 커맨드를 입력할 때마다 `dev-frontend` 컨텍스트에 명시된 클러스터와 -네임스페이스 상에서 동작하게 될 것이다. 그리고 커맨드는 `dev-frontend` 컨텍스트 내에 명시된 +이제 당신이 `kubectl` 커맨드를 입력할 때마다 `dev-frontend` 컨텍스트에 명시된 클러스터와 +네임스페이스 상에서 동작하게 될 것이다. 그리고 커맨드는 `dev-frontend` 컨텍스트 내에 명시된 사용자 자격증명을 사용할 것이다. -현재 컨텍스트에 관련된 구성 정보만을 보려면 +현재 컨텍스트에 관련된 구성 정보만을 보려면 `--minify` 플래그를 사용한다. ```shell @@ -212,8 +217,8 @@ users: kubectl config --kubeconfig=config-demo use-context exp-scratch ``` -이제 당신이 실행하는 모든 `kubectl` 커맨드는 `scratch` 클러스터의 -default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열된 +이제 당신이 실행하는 모든 `kubectl` 커맨드는 `scratch` 클러스터의 +default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열된 사용자의 자격증명을 사용할 것이다. 현재의 컨텍스트인 `exp-scratch`에 관련된 설정을 보자. @@ -222,7 +227,7 @@ default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열 kubectl config --kubeconfig=config-demo view --minify ``` -마지막으로 당신이 `development` 클러스터의 `storage` 네임스페이스에서 +마지막으로 당신이 `development` 클러스터의 `storage` 네임스페이스에서 잠시 작업을 하려고 한다고 가정해보자. 현재 컨텍스트를 `dev-storage`로 변경한다. @@ -259,7 +264,7 @@ contexts: ## KUBECONFIG 환경 변수 설정 -`KUBECONFIG`라는 환경 변수를 가지고 있는지 확인해보자. 만약 가지고 있다면, +`KUBECONFIG`라는 환경 변수를 가지고 있는지 확인해보자. 만약 가지고 있다면, 이후에 복원할 수 있도록 `KUBECONFIG` 환경 변수의 현재 값을 저장한다. 예: @@ -271,9 +276,9 @@ export KUBECONFIG_SAVED=$KUBECONFIG ```shell $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG ``` -`KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는 -Linux와 Mac에서는 콜론으로 구분되며 Windows에서는 세미콜론으로 구분된다. -`KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에 +`KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는 +Linux와 Mac에서는 콜론으로 구분되며 Windows에서는 세미콜론으로 구분된다. +`KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에 익숙해지길 바란다. 다음 예와 같이 임시로 `KUBECONFIG` 환경 변수에 두 개의 경로들을 덧붙여보자. @@ -293,9 +298,9 @@ $Env:KUBECONFIG=("config-demo;config-demo-2") kubectl config view ``` -당신의 `KUBECONFIG` 환경 변수에 나열된 모든 파일들이 합쳐진 정보가 출력 결과로 -표시될 것이다. 특히, 합쳐진 정보가 `config-demo-2` 파일의 `dev-ramp-up` -컨텍스트와 `config-demo` 파일의 세 개의 컨텍스트들을 +당신의 `KUBECONFIG` 환경 변수에 나열된 모든 파일들이 합쳐진 정보가 출력 결과로 +표시될 것이다. 특히, 합쳐진 정보가 `config-demo-2` 파일의 `dev-ramp-up` +컨텍스트와 `config-demo` 파일의 세 개의 컨텍스트들을 가지고 있다는 것에 주목하길 바란다. ```shell @@ -322,22 +327,22 @@ contexts: name: exp-scratch ``` -kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는 +kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는 [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)를 참조한다. ## $HOME/.kube 디렉토리 탐색 -만약 당신이 이미 클러스터를 가지고 있고 `kubectl`을 사용하여 -해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉토리에 `config`라는 +만약 당신이 이미 클러스터를 가지고 있고 `kubectl`을 사용하여 +해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉토리에 `config`라는 파일을 가지고 있을 것이다. -`$HOME/.kube`로 가서 어떤 파일들이 존재하는지 보자. -보통 `config`라는 파일이 존재할 것이다. 해당 디렉토리 내에는 다른 구성 파일들도 있을 수 있다. +`$HOME/.kube`로 가서 어떤 파일들이 존재하는지 보자. +보통 `config`라는 파일이 존재할 것이다. 해당 디렉토리 내에는 다른 구성 파일들도 있을 수 있다. 간단하게 말하자면 당신은 이 파일들의 컨텐츠에 익숙해져야 한다. ## $HOME/.kube/config를 KUBECONFIG 환경 변수에 추가 -당신이 `$HOME/.kube/config` 파일을 가지고 있는데 `KUBECONFIG` +당신이 `$HOME/.kube/config` 파일을 가지고 있는데 `KUBECONFIG` 환경 변수에 나타나지 않는다면 `KUBECONFIG` 환경 변수에 추가해보자. 예: @@ -350,7 +355,7 @@ export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config $Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config" ``` -이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자. +이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자. config-exercise 디렉토리에서 다음 커맨드를 실행한다. ```shell diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index bef17a789d..75bfb61a76 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -61,7 +61,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 ## 컨테이너화 된 애플리케이션 배포 -대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스(Service) 로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다. +대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다. 시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다. @@ -69,7 +69,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 배포 마법사는 다음 정보를 제공한다. -- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스(Service)에 추가되어야 한다. +- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스에 추가되어야 한다. 애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다. @@ -79,17 +79,21 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다. -- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다. +- **서비스** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. - 클러스터 내부에서만 보고 싶은 어떤 서비스(Serivce)들이 있을 것인다. 이를 내부 서비스라고 한다. + {{< note >}} + 외부 서비스들을 위해, 한 개 또는 여러 개의 포트를 열어 둘 필요가 있다. + {{< /note >}} - 서비스(Service) 타입과는 무관하게, 서비스(Service) 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스(Service)는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스(Service)는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스(Service)가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다. + 클러스터 내부에서만 보고 싶은 어떤 서비스들이 있을 것이다. 이를 내부 서비스라고 한다. + + 서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다. 만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다. - **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다. -- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스(Service), 그리고 파드를 생성할 때 추가적으로 정의할 수 있다. +- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를 생성할 때 추가적으로 정의할 수 있다. 예를 들면: @@ -119,13 +123,13 @@ track=stable - **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/docs/user-guide/pods/#privileged-mode-for-pod-containers)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다. -- **환경 변수**: 쿠버네티스 서비스(Service)를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스(Service)를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다. +- **환경 변수**: 쿠버네티스 서비스를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다. ### YAML 또는 JSON 파일 업로드 쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다. -배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다. +배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다. ## 대시보드 사용 다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다. @@ -140,12 +144,12 @@ track=stable 클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다. #### 워크로드 -선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀 셋 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다. +선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다. 워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카 셋으로 관리하는 파드들 또는 새로운 레플리카 셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다. -#### 서비스(Service) -외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스(Service)와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다. +#### 서비스 +외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다. #### 스토리지 스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다. @@ -163,7 +167,7 @@ track=stable ## {{% heading "whatsnext" %}} -더 많은 정보는 +더 많은 정보는 [쿠버네티스 대시보드 프로젝트 페이지](https://github.com/kubernetes/dashboard)를 참고한다. diff --git a/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md b/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md new file mode 100644 index 0000000000..9c9341919a --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md @@ -0,0 +1,101 @@ +--- +title: 기본 스토리지클래스(StorageClass) 변경하기 +content_type: task +--- + + +이 페이지는 특별한 요구사항이 없는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 볼륨을 프로비저닝 +하는데 사용되는 기본 스토리지 클래스를 변경하는 방법을 보여준다. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## 왜 기본 스토리지 클래스를 변경하는가? + +설치 방법에 따라, 사용자의 쿠버네티스 클러스터는 기본으로 표시된 기존 +스토리지클래스와 함께 배포될 수 있다. 이 기본 스토리지클래스는 특정 +스토리지 클래스가 필요하지 않은 퍼시스턴트볼륨클레임에 대해 스토리지를 +동적으로 프로비저닝 하기 위해 사용된다. +더 자세한 내용은 [퍼시스턴트볼륨클레임 문서](/ko/docs/concepts/storage/persistent-volumes/#class-1)를 +보자. + +미리 설치된 기본 스토리지클래스가 사용자의 예상되는 워크로드에 적합하지 +않을수도 있다. 예를 들어, 너무 가격이 높은 스토리지를 프로비저닝 해야할 +수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화 +하여 스토리지의 동적 프로비저닝을 방지할 수 있다. + +단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인 +애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자 +및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자. + +## 기본 스토리지클래스 변경하기 + +1. 사용자의 클러스터에 있는 스토리지클래스 목록을 조회한다. + + ```bash + kubectl get storageclass + ``` + + 결과는 아래와 유사하다. + + ```bash + NAME PROVISIONER AGE + standard (default) kubernetes.io/gce-pd 1d + gold kubernetes.io/gce-pd 1d + ``` + + 기본 스토리지클래스는 `(default)` 로 표시되어 있다. + +1. 기본 스토리지클래스를 기본값이 아닌 것으로 표시한다. + + 기본 스토리지클래스에는 + `storageclass.kubernetes.io/is-default-class` 의 값이 `true` 로 설정되어 있다. + 다른 값이거나 어노테이션이 없을 경우 `false` 로 처리된다. + + 스토리지클래스를 기본값이 아닌 것으로 표시하려면, 그 값을 `false` 로 변경해야 한다. + + ```bash + kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' + ``` + + 여기서 `standard` 는 사용자가 선택한 스토리지클래스의 이름이다. + +1. 스토리지클래스를 기본값으로 표시한다. + + 이전 과정과 유사하게, 어노테이션을 추가/설정 해야 한다. + `storageclass.kubernetes.io/is-default-class=true`. + + ```bash + kubectl patch storageclass gold -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' + ``` + + 최대 1개의 스토리지클래스를 기본값으로 표시할 수 있다는 것을 알아두자. 만약 + 2개 이상이 기본값으로 표시되면, 명시적으로 `storageClassName` 가 지정되지 않은 `PersistentVolumeClaim` 은 생성될 수 없다. + +1. 사용자가 선택한 스토리지클래스가 기본값으로 되어있는지 확인한다. + + ```bash + kubectl get storageclass + ``` + + 결과는 아래와 유사하다. + + ```bash + NAME PROVISIONER AGE + standard kubernetes.io/gce-pd 1d + gold (default) kubernetes.io/gce-pd 1d + ``` + + + +## {{% heading "whatsnext" %}} + +* [퍼시스턴트볼륨(PersistentVolume)](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 보기. diff --git a/content/ko/docs/tasks/administer-cluster/coredns.md b/content/ko/docs/tasks/administer-cluster/coredns.md new file mode 100644 index 0000000000..6f0caad9e4 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/coredns.md @@ -0,0 +1,98 @@ +--- +title: 서비스 디스커버리를 위해 CoreDNS 사용하기 +min-kubernetes-server-version: v1.9 +content_type: task +--- + + +이 페이지는 CoreDNS 업그레이드 프로세스와 kube-dns 대신 CoreDNS를 설치하는 방법을 보여준다. + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + +## CoreDNS 소개 + +[CoreDNS](https://coredns.io)는 쿠버네티스 클러스터의 DNS 역할을 수행할 수 있는, 유연하고 확장 가능한 DNS 서버이다. +쿠버네티스와 동일하게, CoreDNS 프로젝트도 {{< glossary_tooltip text="CNCF" term_id="cncf" >}}가 관리한다. + +사용자는 기존 디플로이먼트인 kube-dns를 교체하거나, 클러스터를 배포하고 업그레이드하는 +kubeadm과 같은 툴을 사용하여 클러스터 안의 kube-dns 대신 CoreDNS를 사용할 수 있다. + +## CoreDNS 설치 + +Kube-dns의 배포나 교체에 관한 매뉴얼은 [CoreDNS GitHub 프로젝트](https://github.com/coredns/deployment/tree/master/kubernetes)에 +있는 문서를 확인하자. + +## CoreDNS로 이관하기 + +### Kubeadm을 사용해 기존 클러스터 업그레이드하기 + +쿠버네티스 버전 1.10 이상에서, `kube-dns` 를 사용하는 클러스터를 업그레이드하기 위하여 +`kubeadm` 을 사용할 때 CoreDNS로 이동할 수도 있다. 이 경우, `kubeadm` 은 +`kube-dns` 컨피그맵(ConfigMap)을 기반으로 패더레이션, 스텁 도메인(stub domain), 업스트림 네임 서버의 +설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다. + +만약 kube-dns에서 CoreDNS로 이동하는 경우, 업그레이드 과정에서 기능 게이트의 `CoreDNS` 값을 `true` 로 설정해야 한다. +예를 들어, `v1.11.0` 로 업그레이드 하는 경우는 다음과 같다. +``` +kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true +``` + +쿠버네티스 1.13 이상에서 기능 게이트의 `CoreDNS` 항목은 제거되었으며, CoreDNS가 기본적으로 사용된다. +업그레이드된 클러스터에서 kube-dns를 사용하려는 경우, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 +설명된 지침 가이드를 참고하자. + +1.11 미만 버전일 경우 업그레이드 과정에서 만들어진 파일이 Corefile을 **덮어쓴다**. +**만약 컨피그맵을 사용자 정의한 경우, 기존의 컨피그맵을 저장해야 한다.** 새 컨피그맵이 +시작된 후에 변경 사항을 다시 적용해야 할 수도 있다. + +만약 쿠버네티스 1.11 이상 버전에서 CoreDNS를 사용하는 경우, 업그레이드 과정에서, +기존의 Corefile이 유지된다. + + +### Kubeadm을 사용해 CoreDNS가 아닌 kube-dns 설치하기 + +{{< note >}} +쿠버네티스 1.11 버전에서, CoreDNS는 GA(General Availability) 되었으며, +기본적으로 설치된다. +{{< /note >}} + +{{< warning >}} +쿠버네티스 1.18 버전에서, kubeadm을 통한 kube-dns는 사용 중단되었으며, 향후 버전에서 제거될 예정이다. +{{< /warning >}} + +1.13 보다 이전 버전에서 kube-dns를 설치하는경우, 기능 게이트의 `CoreDNS` +값을 `false` 로 변경해야 한다. + +``` +kubeadm init --feature-gates=CoreDNS=false +``` + +1.13 이후 버전에서는, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 설명된 지침 가이드를 참고하자. + +## CoreDNS 업그레이드하기 + +CoreDNS는 쿠버네티스 1.9 버전부터 사용할 수 있다. +쿠버네티스와 함께 제공되는 CoreDNS의 버전과 CoreDNS의 변경 사항은 [여기](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)에서 확인할 수 있다. + +CoreDNS는 사용자 정의 이미지를 사용하거나 CoreDNS만 업그레이드 하려는 경우에 수동으로 업그레이드할 수 있다. +업그레이드를 원활하게 수행하는 데 유용한 [가이드라인 및 연습](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)을 참고하자. + +## CoreDNS 튜닝하기 + +리소스 활용이 중요한 경우, CoreDNS 구성을 조정하는 것이 유용할 수 있다. +더 자세한 내용은 [CoreDNS 스케일링에 대한 설명서](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)를 확인하자. + + + +## {{% heading "whatsnext" %}} + + +`Corefile` 을 수정하여 kube-dns 보다 더 많은 유스케이스를 지원하도록 +[CoreDNS](https://coredns.io)를 구성할 수 있다. +더 자세한 내용은 [CoreDNS 웹사이트](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)을 확인하자. diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index dc17eb9cdc..5e9c61d3e6 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -241,4 +241,8 @@ CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지 [cert-cas]: /ko/docs/setup/best-practices/certificates/#단일-루트-ca [cert-table]: /ko/docs/setup/best-practices/certificates/#모든-인증서 +## 인증 기관(CA) 순환(rotation) {#certificate-authority-rotation} +Kubeadm은 CA 인증서의 순환이나 교체 기능을 기본적으로 지원하지 않는다. + +CA의 수동 순환이나 교체에 대한 보다 상세한 정보는 [CA 인증서 수동 순환](/docs/tasks/tls/manual-rotation-of-ca-certificates/) 문서를 참조한다. diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 452cfb1865..b6b1c878c6 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -294,6 +294,7 @@ sudo kubeadm upgrade apply kubelet을 다시 시작한다. ```shell +sudo systemctl daemon-reload sudo systemctl restart kubelet ``` @@ -372,6 +373,7 @@ sudo systemctl restart kubelet - kubelet을 다시 시작한다. ```shell + sudo systemctl daemon-reload sudo systemctl restart kubelet ``` diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index c735bc1a72..7127a7f235 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -199,3 +199,5 @@ kubectl delete namespace default-mem-example * [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) + + diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md index a90d2263d3..880444cefd 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md @@ -136,3 +136,8 @@ kubectl delete namespace quota-pod-example * [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) + + + + + diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md index 2d7f856e46..44f57b3b58 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md @@ -1,5 +1,4 @@ --- -reviewers: title: 네트워크 폴리시로 캘리코(Calico) 사용하기 content_type: task weight: 10 @@ -52,4 +51,3 @@ Kubeadm을 이용해서 15분 이내에 지역 단일 호스트 캘리코 클러 클러스터가 동작하면, 쿠버네티스 네트워크 폴리시(NetworkPolicy)를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. - diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md index 71a96ed8ee..1fbc5e4455 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md @@ -1,10 +1,11 @@ --- -reviewers: title: 네트워크 폴리시로 큐브 라우터(Kube-router) 사용하기 content_type: task weight: 30 --- + + 이 페이지는 네트워크 폴리시(NetworkPolicy)로 [큐브 라우터(Kube-router)](https://github.com/cloudnativelabs/kube-router)를 사용하는 방법을 살펴본다. diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md index dceaf495fc..462e482bff 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md @@ -1,10 +1,11 @@ --- -reviewers: title: 네트워크 폴리시로 로마나(Romana) content_type: task weight: 40 --- + + 이 페이지는 네트워크 폴리시(NetworkPolicy)로 로마나(Romana)를 사용하는 방법을 살펴본다. diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md index d5fef95e75..484a8d58cd 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md @@ -1,5 +1,4 @@ --- -reviewers: title: 네트워크 폴리시로 위브넷(Weave Net) 사용하기 content_type: task weight: 50 diff --git a/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md index 06e8f645b2..7083bdea67 100644 --- a/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -25,7 +25,8 @@ weight: 10 서비스 실행이 필요하다. 이미 실행중인 metrics-server가 있다면 다음 단계를 건너뛸 수 있다. -Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 활성화 할 수 있다. +Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 +활성화할 수 있다. ```shell minikube addons enable metrics-server @@ -52,7 +53,8 @@ v1beta1.metrics.k8s.io ## 네임스페이스 생성 -이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 네임스페이스를 생성한다. +이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 +네임스페이스를 생성한다. ```shell kubectl create namespace mem-example @@ -110,8 +112,9 @@ resources: kubectl top pod memory-demo --namespace=mem-example ``` -출력은 파드가 약 150MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다. -이는 파드의 100 MiB 요청 보다 많으나 파드의 200 MiB 상한보다는 적다. +출력은 파드가 약 150 MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다. +이는 파드의 100 MiB 요청 보다 많으나 +파드의 200 MiB 상한보다는 적다. ``` NAME CPU(cores) MEMORY(bytes) @@ -138,7 +141,7 @@ kubectl delete pod memory-demo --namespace=mem-example {{< codenew file="pods/resource/memory-request-limit-2.yaml" >}} -구성 파일의 'args' 섹션에서 컨테이너가 +구성 파일의 `args` 섹션에서 컨테이너가 100 MiB 상한을 훨씬 초과하는 250 MiB의 메모리를 할당하려는 것을 볼 수 있다. 파드 생성: @@ -242,7 +245,8 @@ kubectl delete pod memory-demo-2 --namespace=mem-example 이 예제에서는 메모리 요청량이 너무 커 클러스터 내 모든 노드의 용량을 초과하는 파드를 생성한다. 다음은 클러스터 내 모든 노드의 용량을 초과할 수 있는 1000 GiB 메모리 요청을 포함하는 -컨테이너를 갖는 파드의 구성 파일이다. +컨테이너를 갖는 +파드의 구성 파일이다. {{< codenew file="pods/resource/memory-request-limit-3.yaml" >}} @@ -302,8 +306,7 @@ kubectl delete pod memory-demo-3 --namespace=mem-example 컨테이너에 메모리 상한을 지정하지 않으면 다음 중 하나가 적용된다. * 컨테이너가 사용할 수 있는 메모리 상한은 없다. 컨테이너가 -실행 중인 노드에서 사용 가능한 모든 메모리를 사용하여 OOM Killer가 실행 될 수 있다. 또한 메모리 부족으로 인한 종료 시 메모리 상한이 -없는 컨테이너가 종료될 가능성이 크다. +실행 중인 노드에서 사용 가능한 모든 메모리를 사용하여 OOM Killer가 실행될 수 있다. 또한 메모리 부족으로 인한 종료 시 메모리 상한이 없는 컨테이너가 종료될 가능성이 크다. * 기본 메모리 상한을 갖는 네임스페이스 내에서 실행중인 컨테이너는 자동으로 기본 메모리 상한이 할당된다. 클러스터 관리자들은 @@ -356,3 +359,6 @@ kubectl delete namespace mem-example * [API 오브젝트에 할당량 구성 ](/docs/tasks/administer-cluster/quota-api-object/) + + + diff --git a/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md index 2e6356b896..cff2ae900d 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md @@ -1,22 +1,23 @@ --- title: 초기화 컨테이너에 대한 구성 -content_template: templates/task +content_type: task weight: 130 --- -{{% capture overview %}} + 이 페이지는 애플리케이션 실행 전에 파드를 초기화하기 위해 어떻게 초기화 컨테이너를 구성해야 하는지 보여준다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## 초기화 컨테이너를 갖는 파드 생성 @@ -78,9 +79,10 @@ init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다.

Kubernetes is open source giving you the freedom to take advantage ...

... -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [같은 파드 내 실행 중인 컨테이너들간 통신](/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)에 대해 배우기. @@ -88,4 +90,6 @@ init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다. * [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 배우기. * [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/)에 대해 배우기. -{{% /capture %}} + + + diff --git a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md index 662b7528bc..939919b2e6 100644 --- a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -7,7 +7,7 @@ weight: 100 이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을 -사용하는 파드(Pod)를 생성하는 방법을 보여준다. +사용하는 파드를 생성하는 방법을 보여준다. diff --git a/content/ko/docs/tasks/configure-pod-container/static-pod.md b/content/ko/docs/tasks/configure-pod-container/static-pod.md new file mode 100644 index 0000000000..a6ddeae8fb --- /dev/null +++ b/content/ko/docs/tasks/configure-pod-container/static-pod.md @@ -0,0 +1,238 @@ +--- + + +title: 스태틱(static) 파드 생성하기 +weight: 170 +content_template: task +--- + + + + +*스태틱 파드* 는 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} +없이 특정 노드에 있는 kubelet 데몬에 의해 +직접 관리된다. +컨트롤 플레인에 의해 관리되는 파드(예를 들어 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}})와는 달리, +kubelet 이 각각의 스태틱 파드를 감시한다. +(만약 충돌이 날 경우 다시 구동한다.) + +스태틱 파드는 항상 특정 노드에 있는 하나의 {{< glossary_tooltip term_id="kubelet" >}}에 매여 있다. + +Kubelet 은 각각의 스태틱 파드에 대하여 쿠버네티스 API 서버에서 {{< glossary_tooltip text="미러 파드(mirror pod)" term_id="mirror-pod" >}}를 +생성하려고 자동으로 시도한다. +즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만, +API 서버에서 제어될 수는 없다. + +{{< note >}} +만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여 +모든 노드에서 파드를 구동하고 있다면, +스태틱 파드를 사용하는 대신 {{< glossary_tooltip text="데몬셋(DaemonSet)" term_id="daemonset" >}} +을 사용하는 것이 바람직하다. +{{< /note >}} + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며, +노드에서 Fedora 운영 체제를 구동하고 있다고 가정한다. +다른 배포판이나 쿠버네티스 설치 지침과는 다소 상이할 수 있다. + + + + + + + +## 스태틱 파드 생성하기 {#static-pod-creation} + +[파일 시스템이 호스팅 하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#configuration-files)이나 [웹이 호스팅 하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http)을 사용하여 스태틱 파드를 구성할 수 있다. + +### 파일시스템이 호스팅 하는 스태틱 파드 매니페스트 {#configuration-files} + +매니페스트는 특정 디렉토리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: ` 필드를 사용하자. 이 디렉토리를 정기적으로 스캔하여, 디렉토리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다. +Kubelet 이 특정 디렉토리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자. + +예를 들어, 다음은 스태틱 파드로 간단한 웹 서버를 구동하는 방법을 보여준다. + +1. 스태틱 파드를 실행할 노드를 선택한다. 이 예제에서는 `my-model` 이다. + + ```shell + ssh my-node1 + ``` + +2. `/etc/kubelet.d` 와 같은 디렉토리를 선택하고 웹 서버 파드의 정의를 해당 위치에, 예를 들어 `/etc/kubelet.d/static-web.yaml` 에 배치한다. + + ```shell + # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. + mkdir /etc/kubelet.d/ + cat </etc/kubelet.d/static-web.yaml + apiVersion: v1 + kind: Pod + metadata: + name: static-web + labels: + role: myrole + spec: + containers: + - name: web + image: nginx + ports: + - name: web + containerPort: 80 + protocol: TCP + EOF + ``` + +3. 노드에서 kubelet 실행 시에 `--pod-manifest-path=/etc/kubelet.d/` 와 같이 인자를 제공하여 해당 디렉토리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 다음과 같이 수정한다. + + ``` + KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" + ``` + 혹은 [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)에 `staticPodPath: ` 필드를 추가한다. + +4. kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다. + + ```shell + # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. + systemctl restart kubelet + ``` + +### 웹이 호스팅 하는 스태틱 파드 매니페스트 {#pods-created-via-http} + +Kubelet은 `--manifest-url=` 의 인수로 지정된 파일을 주기적으로 다운로드하여 +해당 파일을 파드의 정의가 포함된 JSON/YAML 파일로 해석한다. +[파일시스템이 호스팅 하는 매니페스트](#configuration-files) 의 작동 방식과 +유사하게 kubelet은 스케줄에 맞춰 매니페스트 파일을 다시 가져온다. 스태틱 파드의 목록에 +변경된 부분이 있을 경우, kubelet 은 이를 적용한다. + +이 방법을 사용하기 위하여 다음을 수행한다. + +1. kubelet 에게 파일의 URL을 전달하기 위하여 YAML 파일을 생성하고 이를 웹 서버에 저장한다. + + ```yaml + apiVersion: v1 + kind: Pod + metadata: + name: static-web + labels: + role: myrole + spec: + containers: + - name: web + image: nginx + ports: + - name: web + containerPort: 80 + protocol: TCP + ``` + +2. 선택한 노드에서 `--manifest-url=` 을 실행하여 웹 메니페스트를 사용하도록 kubelet을 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 수정한다. + + ``` + KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=" + ``` + +3. Kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다. + + ```shell + # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. + systemctl restart kubelet + ``` + +## 스태틱 파드 행동 관찰하기 {#behavior-of-static-pods} + +Kubelet 을 시작하면, 정의된 모든 스태틱 파드가 자동으로 시작된다. +스태틱 파드를 정의하고, kubelet을 재시작했으므로, 새로운 스태틱 +파드가 이미 실행 중이어야 한다. + +(노드에서) 구동되고 있는 (스태틱 파드를 포함한) 컨테이너들을 볼 수 있다. +```shell +# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. +docker ps +``` + +결과는 다음과 유사하다. + +``` +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c +``` + +API 서버에서 미러 파드를 볼 수 있다. + +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +static-web-my-node1 1/1 Running 0 2m +``` + +{{< note >}} +Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다. +[파드시큐리티폴리시(PodSecurityPolicy)](/docs/concepts/policy/pod-security-policy/) 에 대해 보기. +{{< /note >}} + + +스태틱 파드에 있는 {{< glossary_tooltip term_id="label" text="레이블" >}} 은 +미러 파드로 전파된다. {{< glossary_tooltip term_id="selector" text="셀렉터" >}} 등을 +통하여 이러한 레이블을 사용할 수 있다. + +만약 API 서버로부터 미러 파드를 지우기 위하여 `kubectl` 을 사용하려 해도, +kubelet 은 스태틱 파드를 지우지 _않는다._ + +```shell +kubectl delete pod static-web-my-node1 +``` +``` +pod "static-web-my-node1" deleted +``` +파드가 여전히 구동 중인 것을 볼 수 있다. +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +static-web-my-node1 1/1 Running 0 12s +``` + +kubelet 이 구동 중인 노드로 돌아가서 도커 컨테이너를 수동으로 +중지할 수 있다. +일정 시간이 지나면, kubelet이 파드를 자동으로 인식하고 다시 시작하는 +것을 볼 수 있다. + +```shell +# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. +docker stop f6d05272b57e # 예제를 수행하는 사용자의 컨테이너 ID로 변경한다. +sleep 20 +docker ps +``` +``` +CONTAINER ID IMAGE COMMAND CREATED ... +5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ... +``` + +## 스태틱 파드의 동적 추가 및 제거 + +실행 중인 kubelet 은 주기적으로, 설정된 디렉토리(예제에서는 `/etc/kubelet.d`)에서 변경 사항을 스캔하고, 이 디렉토리에 새로운 파일이 생성되거나 삭제될 경우, 파드를 생성/삭제 한다. + +```shell +# 예제를 수행하는 사용자가 파일시스템이 호스팅하는 스태틱 파드 설정을 사용한다고 가정한다. +# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. +# +mv /etc/kubelet.d/static-web.yaml /tmp +sleep 20 +docker ps +# 구동 중인 nginx 컨테이너가 없는 것을 확인한다. +mv /tmp/static-web.yaml /etc/kubelet.d/ +sleep 20 +docker ps +``` +``` +CONTAINER ID IMAGE COMMAND CREATED ... +e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago +``` diff --git a/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md index b59e62f067..246e6af3bb 100644 --- a/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md +++ b/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md @@ -3,7 +3,7 @@ title: 파드 실패의 원인 검증하기 content_template: templates/task --- -{{% capture overview %}} + 이 페이지는 컨테이너 종료 메시지를 읽고 쓰는 방법을 보여준다. @@ -16,17 +16,18 @@ content_template: templates/task 일반 [쿠버네티스 로그](/ko/docs/concepts/cluster-administration/logging/)에도 쓰여져야 한다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## 종료 메시지 읽기 및 쓰기 @@ -82,6 +83,11 @@ content_template: templates/task 쿠버네티스가 종료 메시지를 검색할 때 다른 파일을 사용하도록 조정할 수 있다. 쿠버네티스는 지정된 파일의 내용을 사용하여 컨테이너의 성공 및 실패에 대한 상태 메시지를 채운다. +종료 메시지는 assertion failure 메세지처럼 간결한 최종 상태로 생성된다. +kubelet은 4096 바이트보다 긴 메시지를 자른다. 모든 컨테이너의 총 메시지 길이는 +12KiB로 제한된다. 기본 종료 메시지 경로는 `/dev/termination-log`이다. +파드가 시작된 후에는 종료 메시지 경로를 설정할 수 없다. + 다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록 `/tmp/my-log` 파일에 종료 메시지를 기록한다. @@ -105,13 +111,16 @@ spec: 쿠버네티스가 컨테이너 로그 출력의 마지막 청크를 사용하도록 지시할 수 있다. 로그 출력은 2048 바이트나 80 행 중 더 작은 값으로 제한된다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 에 있는 `terminationMessagePath` 에 대해 읽어보기. * [로그 검색](/docs/concepts/cluster-administration/logging/)에 대해 배워보기. * [Go 템플릿](https://golang.org/pkg/text/template/)에 대해 배워보기. -{{% /capture %}} + + + diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md index 9677ccd1b9..34c51ad860 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -18,15 +18,11 @@ title: 리소스 모니터링 도구 -쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다. -신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 [완전한 -메트릭 파이프라인](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 -수집할 수 있다. +쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다. 신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 [완전한 메트릭](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 수집할 수 있다. ## 리소스 메트릭 파이프라인 -리소스 메트릭 파이프라인은 -[Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale) +리소스 메트릭 파이프라인은 [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale) 컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는 메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인 [metrics-server](https://github.com/kubernetes-incubator/metrics-server)에 diff --git a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md index e299d4db51..1a72dbf241 100644 --- a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md +++ b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md @@ -1,23 +1,24 @@ --- title: 플러그인으로 kubectl 확장 description: kubectl 플러그인을 사용하면, 새로운 하위 명령을 추가하여 kubectl 명령의 기능을 확장할 수 있다. -content_template: templates/task +content_type: task --- -{{% capture overview %}} + 이 가이드는 [kubectl](/docs/reference/kubectl/kubectl/) 확장을 설치하고 작성하는 방법을 보여준다. 핵심 `kubectl` 명령을 쿠버네티스 클러스터와 상호 작용하기 위한 필수 구성 요소로 생각함으로써, 클러스터 관리자는 플러그인을 이러한 구성 요소를 활용하여 보다 복잡한 동작을 만드는 수단으로 생각할 수 있다. 플러그인은 새로운 하위 명령으로 `kubectl` 을 확장하고, 주요 배포판에 포함되지 않은 `kubectl` 의 새로운 사용자 정의 기능을 허용한다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + 동작하는 `kubectl` 바이너리가 설치되어 있어야 한다. -{{% /capture %}} -{{% capture steps %}} + + ## kubectl 플러그인 설치 @@ -372,9 +373,10 @@ kubectl 플러그인의 배포 패키지를 컴파일된 패키지를 사용 가능하게 하거나, Krew를 사용하면 설치가 더 쉬워진다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Go로 작성된 플러그인의 [자세한 예제](https://github.com/kubernetes/sample-cli-plugin)에 대해서는 @@ -383,4 +385,4 @@ kubectl 플러그인의 배포 패키지를 [SIG CLI 팀](https://github.com/kubernetes/community/tree/master/sig-cli)에 문의한다. * kubectl 플러그인 패키지 관리자인 [Krew](https://krew.dev/)에 대해 읽어본다. -{{% /capture %}} + diff --git a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md index 21fcf9e9c2..c7057c1887 100644 --- a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -30,7 +30,7 @@ weight: 20 이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성 파일은 `DEMO_GREETING` 이라는 이름과 `"Hello from the environment"`이라는 -값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 파일 +값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트 예시이다. {{< codenew file="pods/inject/envars.yaml" >}} @@ -63,7 +63,8 @@ weight: 20 1. 셸 안에서, 환경 변수를 나열하기 위해 `printenv` 커맨드를 실행한다. ```shell - root@envar-demo:/# printenv + # 컨테이너 내 셸에서 다음을 실행한다. + printenv ``` 출력은 아래와 비슷할 것이다. @@ -81,12 +82,24 @@ weight: 20 {{< note >}} `env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지 -안에서 명시된 어떠한 환경 변수들보다 더 우선시된다. +안에서 명시된 모든 환경 변수들을 오버라이딩한다. +{{< /note >}} + +{{< note >}} +환경 변수는 서로를 참조할 수 있으며 사이클이 가능하다. +사용하기 전에 순서에 주의한다. {{< /note >}} ## 설정 안에서 환경 변수 사용하기 -파드의 구성 파일 안에서 정의한 환경 변수는 파드의 컨테이너를 위해 설정하는 커맨드들과 인자들과 같이, 구성 파일 안의 다른 곳에서 사용할 수 있다. 아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고 `NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`, 그리고 `Kubernetes`로 설정되어 있다. 이들 환경 변수들은 이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서 사용된다. +파드의 구성 파일 안에서 정의한 환경 변수는 +파드의 컨테이너를 위해 설정하는 커맨드와 인자들과 같이, +구성 파일 안의 다른 곳에서 사용할 수 있다. +아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고 +`NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`, +그리고 `Kubernetes`로 설정되어 있다. 이 환경 변수들은 +이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서 +사용된다. ```yaml apiVersion: v1 diff --git a/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md b/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md index a1c3ba02dc..60aa4f4d1a 100644 --- a/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md @@ -1,27 +1,30 @@ --- title: 데몬셋(DaemonSet)에서 롤백 수행 -content_template: templates/task +content_type: task weight: 20 --- -{{% capture overview %}} + + + 이 페이지는 데몬셋에서 롤백을 수행하는 방법을 보여준다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * 데몬셋 롤아웃 기록과 데몬셋 롤백 기능은 쿠버네티스 버전 1.7 이상의 `kubectl` 에서만 지원된다. * [데몬셋에서 롤링 업데이트를 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)하는 방법을 알고 있어야 한다. -{{% /capture %}} -{{% capture steps %}} + + ## 데몬셋에서 롤백 수행 @@ -102,10 +105,10 @@ kubectl rollout status ds/ daemonset "" successfully rolled out ``` -{{% /capture %}} -{{% capture discussion %}} + + ## 데몬셋 리비전의 이해 @@ -152,4 +155,6 @@ NAME CONTROLLER REVISION AGE * [데몬셋 롤링 업데이트 문제 해결](/ko/docs/tasks/manage-daemon/update-daemon-set/#문제-해결)을 참고한다. -{{% /capture %}} + + + diff --git a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md index 78ff272042..925f174206 100644 --- a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md @@ -1,24 +1,27 @@ --- title: 데몬셋(DaemonSet)에서 롤링 업데이트 수행 -content_template: templates/task +content_type: task weight: 10 --- -{{% capture overview %}} + + + 이 페이지는 데몬셋에서 롤링 업데이트를 수행하는 방법을 보여준다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} * 데몬셋 롤링 업데이트 기능은 쿠버네티스 버전 1.6 이상에서만 지원된다. -{{% /capture %}} -{{% capture steps %}} + + + ## 데몬셋 업데이트 전략 @@ -188,13 +191,14 @@ kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system kubectl delete ds fluentd-elasticsearch -n kube-system ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [태스크: 데몬셋에서 롤백 수행](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)을 참고한다. * [개념: 기존 데몬셋 파드를 채택하기 위한 데몬셋 생성](/ko/docs/concepts/workloads/controllers/daemonset/)을 참고한다. -{{% /capture %}} + diff --git a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md index 01d6d8331e..7ea6b51d93 100644 --- a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md @@ -1,10 +1,10 @@ --- - - content_type: concept title: GPU 스케줄링 --- + + {{< feature-state state="beta" for_k8s_version="v1.10" >}} @@ -98,7 +98,7 @@ kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device - Kubelet은 자신의 컨테이너 런타임으로 도커를 사용해야 한다. - 도커는 runc 대신 `nvidia-container-runtime` 이 [기본 런타임](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)으로 설정되어야 한다. -- NVIDIA 드라이버의 버전은 조건 ~= 361.93 을 만족해야 한다. +- NVIDIA 드라이버의 버전은 조건 ~= 384.81을 만족해야 한다. 클러스터가 실행 중이고 위의 요구 사항이 만족된 후, NVIDIA 디바이스 플러그인을 배치하기 위해서는 아래 명령어를 실행한다. diff --git a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md index c48a11ab56..9d4e4ca2b3 100644 --- a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md +++ b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md @@ -1,18 +1,19 @@ --- title: HugePages 관리 -content_template: templates/task +content_type: task --- -{{% capture overview %}} + {{< feature-state state="stable" >}} 쿠버네티스는 **GA** 기능으로 파드의 애플리케이션에 미리 할당된 huge page의 할당과 사용을 지원한다. 이 페이지에서는 사용자가 huge page를 사용하는 방법과 현재의 제약 사항에 대해 설명한다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + 1. 쿠버네티스 노드는 노드에 대한 huge page 용량을 보고하기 위해 huge page를 미리 할당해야 한다. 노드는 여러 크기의 huge page를 미리 할당할 수 @@ -21,9 +22,9 @@ huge page를 사용하는 방법과 현재의 제약 사항에 대해 설명한 노드는 모든 huge page 리소스를 스케줄 가능한 리소스로 자동 검색하고 보고한다. -{{% /capture %}} -{{% capture steps %}} + + ## API @@ -123,4 +124,5 @@ term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`) - NUMA 지역성(locality)은 서비스 품질(QoS)의 기능으로 보장할 예정이다. - 리밋레인지(LimitRange)를 지원할 예정이다. -{{% /capture %}} + + diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md index 7c81129176..87469281c9 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md @@ -65,7 +65,7 @@ weight: 10 kubectl apply -f <디렉터리>/ ``` -이것은  각 오브젝트에 대해 `kubectl.kubernetes.io/last-applied-configuration: '{...}'` +이것은 각 오브젝트에 대해 `kubectl.kubernetes.io/last-applied-configuration: '{...}'` 어노테이션을 설정한다. 해당 어노테이션은 오브젝트를 생성하기 위해 사용했던 오브젝트 구성 파일의 내용을 포함한다.  @@ -78,9 +78,11 @@ kubectl apply -f <디렉터리>/ {{< codenew file="application/simple_deployment.yaml" >}} 생성될 오브젝트를 출력하려면 `kubectl diff`를 실행한다.  + ```shell kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml ``` + {{< note >}} `diff`는 `kube-apiserver`의 활성화가 필요한 [서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다. @@ -1000,8 +1002,10 @@ template: ## {{% heading "whatsnext" %}} + * [명령형 커맨드 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/) * [구성 파일 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/) * [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) + diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md index 47089a10dc..ddf2c2f1b9 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md @@ -164,8 +164,10 @@ kubectl create --edit -f /tmp/srv.yaml ## {{% heading "whatsnext" %}} + * [오브젝트 구성을 이용하여 쿠버네티스 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/) * [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) * [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) + diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md index ca6d1de04d..927c6df079 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md @@ -147,8 +147,10 @@ template: ## {{% heading "whatsnext" %}} + * [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/) * [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) * [Kubectl 커멘드 참조](/docs/reference/generated/kubectl/kubectl/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) + diff --git a/content/ko/docs/tasks/run-application/delete-stateful-set.md b/content/ko/docs/tasks/run-application/delete-stateful-set.md new file mode 100644 index 0000000000..ce5f030622 --- /dev/null +++ b/content/ko/docs/tasks/run-application/delete-stateful-set.md @@ -0,0 +1,88 @@ +--- +title: 스테이트풀셋(StatefulSet) 삭제하기 +content_type: task +weight: 60 +--- + + + +이 작업은 {{< glossary_tooltip term_id="StatefulSet"text="스테이트풀셋">}}을 삭제하는 방법을 설명한다. + + + +## {{% heading "prerequisites" %}} + + +* 이 작업은 클러스터에 스테이트풀셋으로 표시되는 애플리케이션이 있다고 가정한다. + + + + + +## 스테이트풀셋 삭제 + +쿠버네티스에서 다른 리소스를 삭제하는 것과 같은 방식으로 스테이트풀셋을 삭제할 수 있다. `kubectl delete` 명령어를 사용하고 파일 또는 이름으로 스테이트풀셋을 지정하자. + +```shell +kubectl delete -f +``` + +```shell +kubectl delete statefulsets +``` + +스테이트풀셋 자체를 삭제한 후 연결된 헤드리스 서비스는 별도로 삭제해야 할 수도 있다. + +```shell +kubectl delete service +``` + +kubectl을 통해 스테이트풀셋을 삭제하면 0으로 스케일이 낮아지고, 스테이트풀셋에 포함된 모든 파드가 삭제된다. +파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=false` 를 사용한다. + +```shell +kubectl delete -f --cascade=false +``` + +`kubectl delete` 에 `--cascade=false` 를 사용함으로써, 스테이트풀셋 객체가 삭제 된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다. + +```shell +kubectl delete pods -l app=myapp +``` + +### 퍼시스턴트볼륨(PersistentVolume) + +스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드들이 [terminating 상태](/ko/docs/concepts/workloads/pods/pod/#termination-of-pods)가 된 후 PVC를 삭제하는 것은 스토리지클래스(StorageClass) 와 반환 정책에 따라 백업 퍼시스턴트볼륨이 삭제될 수도 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다. + +{{< note >}} +PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자. +{{< /note >}} + +### 스테이트풀셋의 완벽한 삭제 + +연결된 파드를 포함해서 스테이트풀셋의 모든 것을 간단히 삭제하기 위해 다음과 같이 일련의 명령을 실행 한다. + +```shell +grace=$(kubectl get pods --template '{{.spec.terminationGracePeriodSeconds}}') +kubectl delete statefulset -l app=myapp +sleep $grace +kubectl delete pvc -l app=myapp + +``` + +위의 예에서 파드에는 `app=myapp` 라는 레이블이 있다. 사용자에게 적절한 레이블로 대체하자. + +### 스테이트풀셋 파드의 강제 삭제 + +스테이트풀셋의 일부 파드가 오랫동안 'Terminating' 또는 'Unknown' 상태에 있는 경우, apiserver에 수동적으로 개입하여 파드를 강제 삭제할 수도 있다. 이것은 잠재적으로 위험한 작업이다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다. + + + +## {{% heading "whatsnext" %}} + + +[스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 알아보기. + + + + diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index fdf1f75411..6b294b7850 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -8,7 +8,7 @@ weight: 100 Horizontal Pod Autoscaler는 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 -레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀 셋의 파드 개수를 자동으로 스케일한다. +레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. 이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다. diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index c242695165..2362c7f475 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -9,13 +9,17 @@ content_type: concept weight: 90 --- + + + + Horizontal Pod Autoscaler는 CPU 사용량 (또는 [사용자 정의 메트릭](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md), 아니면 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션 -컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀 셋의 파드 개수를 자동으로 스케일한다. Horizontal -Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬 셋)에는 적용되지 않는다. +컨트롤러(ReplicationController), 디플로이먼트(Deployment), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. Horizontal +Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬셋(DaemonSet))에는 적용되지 않는다. Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다. 리소스는 컨트롤러의 동작을 결정한다. @@ -160,11 +164,7 @@ HPA가 여전히 확장할 수 있음을 의미한다. 마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다. 컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장 -사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은 -`--horizontal-pod-autoscaler-downscale-stabilization` 플래그 또는 HPA 오브젝트 -동작 `behavior.scaleDown.stabilizationWindowSeconds` ([구성가능한 -스케일링 동작 지원](#구성가능한-스케일링-동작-지원)을 본다)을 -사용하여 설정할 수 있고, 기본 값은 5분이다. +사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization` 플래그를 사용하여 설정할 수 있고, 기본값은 5분이다. 즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의 영향을 완만하게 한다. @@ -233,11 +233,6 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대 있다. {{< /note >}} -v1.17 부터 v2beta2 API 필드에서 `behavior.scaleDown.stabilizationWindowSeconds` -를 설정하여 다운스케일 안정화 창을 HPA별로 설정할 수 있다. -[구성가능한 스케일링 -동작 지원](#구성가능한-스케일링-동작-지원)을 본다. - ## 멀티 메트릭을 위한 지원 Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API @@ -265,7 +260,7 @@ Horizontal Pod Autoscaler 컨트롤러에서는 더 이상 스케일 할 사용 기본적으로 HorizontalPodAutoscaler 컨트롤러는 일련의 API에서 메트릭을 검색한다. 이러한 API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. -* [API 집합 레이어](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 활성화 +* [API 애그리게이션 레이어](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 활성화 * 해당 API 등록: @@ -445,3 +440,4 @@ behavior: * kubectl 오토스케일 커맨드: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). * [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)의 사용 예제. + diff --git a/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md b/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md index 37ed18a70a..8642c374af 100644 --- a/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md +++ b/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md @@ -1,37 +1,39 @@ --- title: 단일 인스턴스 스테이트풀 애플리케이션 실행하기 -content_template: templates/tutorial +content_type: tutorial weight: 20 --- -{{% capture overview %}} + 이 페이지에서는 쿠버네티스 클러스터에서 퍼시스턴트볼륨(PersistentVolume)과 디플로이먼트(Deployment)를 사용하여, 단일 인스턴스 스테이트풀 애플리케이션을 실행하는 방법을 보인다. 해당 애플리케이션은 MySQL이다. -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * 사용자 환경의 디스크를 참조하는 퍼시스턴트볼륨 생성하기 * MySQL 디플로이먼트 생성하기 * 알려진 DNS 이름으로 클러스터의 다른 파드에 MySQL 서비스 노출하기 -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * {{< include "default-storage-class-prereqs.md" >}} -{{% /capture %}} -{{% capture lessoncontent %}} + + + ## MySQL 배포하기 @@ -180,10 +182,11 @@ kubectl delete pv mysql-pv-volume 일부 동적 프로비저너(EBS 와 PD와 같은)는 퍼시스턴트볼륨을 삭제할 때에 기본 리소스도 해제한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 더 배워 보기 @@ -193,4 +196,6 @@ kubectl delete pv mysql-pv-volume * [볼륨](/ko/docs/concepts/storage/volumes/)과 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/) -{{% /capture %}} + + + diff --git a/content/ko/docs/tasks/tls/_index.md b/content/ko/docs/tasks/tls/_index.md new file mode 100644 index 0000000000..8607aa28d2 --- /dev/null +++ b/content/ko/docs/tasks/tls/_index.md @@ -0,0 +1,5 @@ +--- +title: "TLS" +weight: 100 +--- + diff --git a/content/ko/docs/tasks/tls/certificate-rotation.md b/content/ko/docs/tasks/tls/certificate-rotation.md new file mode 100644 index 0000000000..7f7422411c --- /dev/null +++ b/content/ko/docs/tasks/tls/certificate-rotation.md @@ -0,0 +1,83 @@ +--- + + + +title: Kubelet의 인증서 갱신 구성 +content_type: task +--- + + +이 페이지는 kubelet에 대한 인증서 갱신을 활성화하고 구성하는 방법을 보여준다. + + +{{< feature-state for_k8s_version="v1.8" state="beta" >}} + +## {{% heading "prerequisites" %}} + + +* 쿠버네티스 1.8.0 버전 혹은 그 이상의 버전이 요구됨 + + + + + +## 개요 + +kubelet은 쿠버네티스 API 인증을 위해 인증서를 사용한다. +기본적으로 이러한 인증서는 1년 만기로 발급되므로 +너무 자주 갱신할 필요는 없다. + +쿠버네티스 1.8은 [kubelet 인증서 +갱신](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 포함하며, +이 기능은 현재 인증서의 만료 시한이 임박한 경우, +새로운 키를 자동으로 생성하고 쿠버네티스 API에서 새로운 인증서를 요청하는 베타 기능이다. +새로운 인증서를 사용할 수 있게 되면 +쿠버네티스 API에 대한 연결을 인증하는데 사용된다. + +## 클라이언트 인증서 갱신 활성화하기 + +`kubelet` 프로세스는 현재 사용 중인 인증서의 만료 시한이 다가옴에 따라 +kubelet이 자동으로 새 인증서를 요청할지 여부를 제어하는 +`--rotate-certificates` 인자를 허용한다. +인증서 갱신은 베타 기능이므로 기능 플래그는 +`--feature-gates = RotateKubeletClientCertificate=true` 를 사용하여 활성화해야 한다. + + +`kube-controller-manager` 프로세스는 얼마나 오랜 기간 인증서가 유효한지를 제어하는 +`--experimental-cluster-signing-duration` 인자를 +허용한다. + +## 인증서 갱신 구성에 대한 이해 + +kubelet이 시작할 때 부트 스트랩 (`--bootstrap-kubeconfig` 플래그를 사용) +을 구성하면 초기 인증서를 사용하여 쿠버네티스 API에 연결하고 +인증서 서명 요청을 발행한다. +다음을 사용하여 인증서 서명 요청 상태를 볼 수 있다. + +```sh +kubectl get csr +``` + +초기에 노드의 kubelet에서 인증서 서명 요청은 `Pending` 상태이다. +인증서 서명 요청이 특정 기준을 충족하면 컨트롤러 관리자가 +자동으로 승인한 후 상태가 `Approved` 가 된다. +다음으로, 컨트롤러 관리자는 +`--experimental-cluster-signing-duration` 파라미터에 의해 지정된 기간 동안 +발행된 인증서에 서명하고 +서명된 인증서는 인증서 서명 요청에 첨부된다. + +kubelet은 쿠버네티스 API로 서명된 인증서를 가져와서 +`--cert-dir`에 지정된 위치에 디스크에 기록한다. +그런 다음 kubelet은 쿠버네티스 API에 연결해서 새로운 인증서를 사용한다. + +서명된 인증서의 만료가 다가오면 kubelet은 쿠버네티스 API를 사용하여 +새로운 인증서 서명 요청을 자동으로 발행한다. +또한, 컨트롤러 관리자는 인증서 요청을 자동으로 승인하고 +서명된 인증서를 인증서 서명 요청에 첨부한다. +kubelet은 쿠버네티스 API로 서명된 새로운 인증서를 가져와서 디스크에 쓴다. +그런 다음 새로운 인증서를 사용한 재연결을 위해서 +가지고 있는 쿠버네티스 API로의 연결을 업데이트 한다. + + + + diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index 386d606769..dc43810c14 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -200,7 +200,6 @@ Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Mini {{% /tab %}} {{< /tabs >}} - ## 설치 확인 하이퍼바이저와 Minikube의 성공적인 설치를 확인하려면, 다음 명령어를 실행해서 로컬 쿠버네티스 클러스터를 시작할 수 있다. @@ -211,6 +210,10 @@ Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Mini {{< /note >}} +{{< caution >}} +KVM을 사용할 때 Debian과 다른 시스템에서 libvirt의 기본 QEMU URI는 `qemu:///session`이고, Minikube의 기본 QEMU URI는 `qemu:///system`이다. 시스템이 이런 환경이라면, `--kvm-qemu-uri qemu:///session`을 `minikube start`에 전달해야 한다. +{{< /caution >}} + ```shell minikube start --driver= ``` @@ -256,4 +259,4 @@ minikube delete ## {{% heading "whatsnext" %}} -* [Minikube로 로컬에서 쿠버네티스 실행하기](/docs/setup/minikube/) +* [Minikube로 로컬에서 쿠버네티스 실행하기](/ko/docs/setup/learning-environment/minikube/) diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md index 7a3ca934e0..4a18224f02 100644 --- a/content/ko/docs/tutorials/_index.md +++ b/content/ko/docs/tutorials/_index.md @@ -69,9 +69,8 @@ content_type: concept ## {{% heading "whatsnext" %}} -튜토리얼을 작성하고 싶다면, -튜토리얼 페이지 유형과 튜토리얼 템플릿에 대한 정보가 있는 -[Using Page Templates](/docs/home/contribute/page-templates/) +튜토리얼을 작성하고 싶다면, 튜토리얼 페이지 유형에 대한 정보가 있는 +[내용 페이지 유형](/docs/contribute/style/page-content-types/) 페이지를 참조한다. diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index a168b521e1..803b58594c 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -1,9 +1,10 @@ --- -reviewers: title: AppArmor content_type: tutorial --- + + {{< feature-state for_k8s_version="v1.4" state="beta" >}} @@ -13,7 +14,7 @@ AppArmor는 표준 리눅스 사용자와 그룹 기반의 권한을 보완하 프로그램을 제한하는 리눅스 커널 보안 모듈이다. AppArmor는 임의의 애플리케이션에 대해서 잠재적인 공격 범위를 줄이고 더욱 심층적인 방어를 제공하도록 구성할 수 있다. 이 기능은 특정 프로그램이나 컨테이너에서 필요한 리눅스 기능, 네트워크 사용, 파일 권한 등에 대한 -접근 허용 목록 조정한 프로파일로 구성한다. 각 프로파일은 +접근을 허용하는 프로파일로 구성한다. 각 프로파일은 허용하지 않은 리소스 접근을 차단하는 *강제(enforcing)* 모드 또는 위반만을 보고하는 *불평(complain)* 모드로 실행할 수 있다. @@ -29,7 +30,7 @@ AppArmor를 이용하면 컨테이너가 수행할 수 있는 작업을 제한 * 노드에 프로파일을 어떻게 적재하는지 예시를 본다. -* 파드(Pod)에 프로파일을 어떻게 강제 적용하는지 배운다. +* 파드에 프로파일을 어떻게 강제 적용하는지 배운다. * 프로파일이 적재되었는지 확인하는 방법을 배운다. * 프로파일을 위반하는 경우를 살펴본다. * 프로파일을 적재할 수 없을 경우를 살펴본다. diff --git a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md index 340ea6431f..7c14a811a5 100644 --- a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -90,7 +90,7 @@ pod/redis 1/1 Running 0 52s `kubectl exec`를 사용해 파드 속에서 `redis-cli` 툴을 실행해 본다. ```shell -kubectl exec -it redis redis-cli +kubectl exec -it redis -- redis-cli 127.0.0.1:6379> CONFIG GET maxmemory 1) "maxmemory" 2) "2097152" diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index d579a7b7d6..4549694159 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -97,6 +97,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. ```shell kubectl get pods ``` + 다음과 유사하게 출력된다. ``` diff --git a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html index e411c4f8ab..24405ac955 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -30,7 +30,7 @@ weight: 10

지난 모듈에서 디플로이먼트를 만들고, 서비스를 통해서 디플로이먼트를 외부에 노출시켜 봤다. 해당 디플로이먼트는 애플리케이션을 구동하기 위해 단 - 하나의 파드(Pod)만을 생성했었다. 트래픽이 증가하면, 사용자 요청에 맞추어 애플리케이션의 규모를 + 하나의 파드만을 생성했었다. 트래픽이 증가하면, 사용자 요청에 맞추어 애플리케이션의 규모를 조정할 필요가 있다.

디플로이먼트의 복제 수를 변경하면 스케일링이 수행된다

diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index 10e7aa7683..d384d07655 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -7,7 +7,7 @@ weight: 10 이 튜토리얼은 스테이트풀셋([StatefulSets](/ko/docs/concepts/workloads/controllers/statefulset/))을 이용하여 -애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드(Pod)을 생성하고 삭제하며 +애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드를 생성하고 삭제하며 스케일링하고 업데이트하는지 시연한다. diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index f67516cb80..ea6b3063cc 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -1,10 +1,11 @@ --- title: "예시: 카산드라를 스테이트풀셋으로 배포하기" -reviewers: content_type: tutorial weight: 30 --- + + 이 튜토리얼은 쿠버네티스에서 [아파치 카산드라](http://cassandra.apache.org/)를 실행하는 방법을 소개한다. 데이터베이스인 카산드라는 데이터 내구성을 제공하기 위해 퍼시스턴트 스토리지가 필요하다(애플리케이션 _상태_). 이 예제에서 사용자 지정 카산드라 시드 공급자는 카산드라가 클러스터에 가입할 때 카산드라가 인스턴스를 검색할 수 있도록 한다. @@ -24,7 +25,6 @@ weight: 30 {{< /note >}} - ## {{% heading "objectives" %}} * 카산드라 헤드리스 {{< glossary_tooltip text="Service" term_id="service" >}}를 생성하고 검증한다. @@ -36,18 +36,9 @@ weight: 30 ## {{% heading "prerequisites" %}} -이 튜토리얼을 완료하려면, [파드](/ko/docs/concepts/workloads/pods/pod/), [서비스](/ko/docs/concepts/services-networking/service/), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로 +{{< include "task-tutorial-prereqs.md" >}} -* *kubectl* 커맨드라인 도구를 [설치와 설정](/docs/tasks/tools/install-kubectl/)하자. - -* [`cassandra-service.yaml`](/examples/application/cassandra/cassandra-service.yaml)와 - [`cassandra-statefulset.yaml`](/examples/application/cassandra/cassandra-statefulset.yaml)를 다운로드한다. - -* 실행 중인 쿠버네티스 클러스터를 소유 - -{{< note >}} -아직 클러스터가 없다면 [설치](/ko/docs/setup/)를 읽도록 하자. -{{< /note >}} +이 튜토리얼을 완료하려면 {{< glossary_tooltip text="파드" term_id="pod" >}}, {{< glossary_tooltip text="서비스" term_id="service" >}}, {{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}}에 대한 기본 지식이 있어야 한다. ### 추가적인 Minikube 설정 요령 @@ -274,7 +265,6 @@ kubectl apply -f cassandra-statefulset.yaml - ## {{% heading "whatsnext" %}} @@ -283,3 +273,4 @@ kubectl apply -f cassandra-statefulset.yaml * 커스텀 [시드 제공자 설정](https://git.k8s.io/examples/cassandra/java/README.md)를 살펴본다. + diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index d4891dbe39..323a087408 100644 --- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -1,6 +1,5 @@ --- title: "예시: WordPress와 MySQL을 퍼시스턴트 볼륨에 배포하기" -reviewers: content_type: tutorial weight: 20 card: @@ -9,6 +8,8 @@ card: title: "스테이트풀셋 예시: Wordpress와 퍼시스턴트 볼륨" --- + + 이 튜토리얼은 WordPress 사이트와 MySQL 데이터베이스를 Minikube를 이용하여 어떻게 배포하는지 보여준다. 애플리케이션 둘 다 퍼시스턴트 볼륨과 퍼시스턴트볼륨클레임을 데이터를 저장하기 위해 사용한다. diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index 11120ca54d..bf4c2e179c 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -1095,3 +1095,5 @@ node "kubernetes-node-ixsl" uncordoned 모든 스토리지가 재확보되도록 하자. + + diff --git a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md index b37497b9bf..cd8ff4e03f 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md @@ -1,6 +1,5 @@ --- title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가" -reviewers: content_type: tutorial weight: 21 card: @@ -406,4 +405,3 @@ kubectl scale --replicas=3 deployment/frontend * [로깅 아키텍처](/docs/concepts/cluster-administration/logging/)를 더 읽어본다. * [애플리케이션 검사 및 디버깅](/ko/docs/tasks/debug-application-cluster/)을 더 읽어본다. * [애플리케이션 문제 해결](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)을 더 읽어본다. - diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index bf91733f9b..422ed877e2 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -369,4 +369,3 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 * [애플리케이션 접속](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아보기 * [자원 관리](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)에 대해 더 알아보기 - diff --git a/content/pl/_index.html b/content/pl/_index.html index 42e5bb4ae7..f127bff2c7 100644 --- a/content/pl/_index.html +++ b/content/pl/_index.html @@ -3,9 +3,6 @@ title: "Produkcyjny system zarządzania kontenerami" abstract: "Automatyzacja wdrażania, skalowania i zarządzania kontenerami" cid: home --- -{{< announcement >}} - -{{< deprecationwarning >}} {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} diff --git a/content/pl/docs/concepts/_index.md b/content/pl/docs/concepts/_index.md index f1eb3cd621..ec7abd87ce 100644 --- a/content/pl/docs/concepts/_index.md +++ b/content/pl/docs/concepts/_index.md @@ -41,7 +41,7 @@ Kubernetes zawiera także obiekty abstrakcyjne wyższego poziomu, zbudowane z ob * [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) * [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) * [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) - * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) + * [Job](/docs/concepts/workloads/controllers/job/) ## Warstwa sterowania (*Kubernetes Control Plane*) {#warstwa-sterowania} @@ -65,7 +65,7 @@ Węzły klastra to maszyny (wirtualne, fizyczne i in.), na których uruchamiane Jeśli chcesz dodać stronę z nowym pojęciem, odwiedź -[Jak używać szablonu strony](/docs/home/contribute/page-templates/) -aby dowiedzieć się o tworzeniu stron opisujących pojęcia i o dostępnych szablonach. +[Page Content Types](/docs/contribute/style/page-content-types/#concept), +aby dowiedzieć się o tworzeniu stron opisujących pojęcia. diff --git a/content/pl/docs/concepts/overview/kubernetes-api.md b/content/pl/docs/concepts/overview/kubernetes-api.md index 9126c6cfa3..e13a77196f 100644 --- a/content/pl/docs/concepts/overview/kubernetes-api.md +++ b/content/pl/docs/concepts/overview/kubernetes-api.md @@ -9,17 +9,13 @@ card: -Ogólne reguły dotyczące API opisane są w dokumentacji [API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md). +Sercem {{< glossary_tooltip text="warstwy sterowania" term_id="control-plane" >}} Kubernetes +jest {{< glossary_tooltip text="serwer API" term_id="kube-apiserver" >}}. Serwer udostępnia +API poprzez HTTP, umożliwiając wzajemną komunikację pomiędzy użytkownikami, częściami składowymi klastra i komponentami zewnętrznymi. -Punkty dostępowe *(endpoints)* API, typy zasobów oraz przykłady są dostępne w [API Reference](/docs/reference). +API Kubernetes pozwala na sprawdzanie i zmianę stanu obiektów (przykładowo: pody, _Namespaces_, _ConfigMaps_, _Events_). -Zdalny dostęp do API omówiono w dokumentacji [Controlling API Access](/docs/reference/access-authn-authz/controlling-access/). - -API Kubernetes to także podstawa deklaratywnego schematu konfiguracji dla systemu. Obiekty API mogą być tworzone, zmieniane, kasowane i odpytywane sa pomocą narzędzia linii poleceń [kubectl](/docs/reference/kubectl/overview/). - -Kubernetes przechowuje także swój serializowany stan (obecnie w [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)) w postaci obiektów API. - -Kubernetes jako taki składa się z wielu elementów składowych, które komunikują się ze sobą poprzez swoje API. +Punkt dostępowe _(endpoints)_ API, typy zasobów i przykłady opisane są w [API Reference](/docs/reference/kubernetes-api/). @@ -28,48 +24,76 @@ Kubernetes jako taki składa się z wielu elementów składowych, które komunik ## Zmiany w API -Z naszego doświadczenia wynika, że każdy system, który odniósł sukces, musi się nieustająco rozwijać w miarę zmieniających się potrzeb. Dlatego oczekujemy, że API też będzie się zmieniało i rozrastało. W dłuższym horyzoncie nie planujemy jednak żadnych zmian, które mogą być niezgodne z istniejącymi klientami. W ogólności, nowe zasoby i pola definiujące zasoby API są dodawane stosunkowo często. Usuwanie zasobów lub pól jest regulowane przez [API deprecation policy](/docs/reference/using-api/deprecation-policy/). +Jednym z wymagań, które odnoszą się do każdego systemu, który odniósł sukces, jest zdolność do rozwoju i ewolucji w miarę pojawiających się i zmieniających potrzeb. +Dlatego Kubernetes został zaprojektowany tak, aby umożliwić ciągły rozwój i zmiany w API. +Celem projektu Kubernetes jest _zachowanie_ zgodności z istniejącymi klientami i utrzymanie tej zgodności +przez odpowiednio długi czas, pozwalający innym projektom na stopniowe dostosowanie. -Definicja zmiany zgodnej (kompatybilnej) oraz metody wprowadzania zmian w API opisano w szczegółach w [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md). +W skrócie, nowe zasoby API i nowe pola dla konkretnych zasobów mogą być dodawane stosunkowo często. +Usunięcie zasobów lub pól wymaga stosowania +[API deprecation policy](/docs/reference/using-api/deprecation-policy/). -## Definicje OpenAPI i Swagger +Szczegółowe objaśnienia, jak wygląda zmiana, która zachowuje zgodność i jak zmieniać API, znajdują się w dokumencie +[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme). -Pełne szczegóły API są udokumentowane zgodnie z [OpenAPI](https://www.openapis.org/). +## Specyfikacja OpenAPI {#api-specification} -Począwszy od Kubernetes w wersji 1.10, serwer Kubernetes API dostarcza specyfikację OpenAPI poprzez punkt końcowy `/openapi/v2`. -Wymagany format określa się w nagłówkach HTTP: +Pełną specyfikację API udokumentowano za pomocą [OpenAPI](https://www.openapis.org/). -Nagłówek | Dopuszczalne wartości ------- | --------------- -Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (domyślnie content-type to `application/json` dla `*/*` lub pominięcie tego nagłówka) -Accept-Encoding | `gzip` (pominięcie nagłówka jest dozwolone) +Serwer API Kubernetes API udostępnia specyfikację OpenAPI poprzez ścieżkę `/openapi/v2`. +Aby wybrać format odpowiedzi, użyj nagłówków żądania zgodnie z: -W wersjach wcześniejszych niż 1.14, punkty końcowe określone przez ich format (`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`) udostępniały specyfikację OpenAPI zgodnie z tymi formatami. Te punkty końcowe były stopniowo wycofywane i ostatecznie usunięte w wersji 1.14 Kubernetes. - -**Przykłady pobierania specyfikacji OpenAPI**: - -Przed 1.10 | Kubernetes 1.10 i nowszy ------------ | ----------------------------- -GET /swagger.json | GET /openapi/v2 **Accept**: application/json -GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf -GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NagłówekDopuszczalne wartościUwagi
Accept-Encodinggzippominięcie tego nagłówka jest dozwolone
Acceptapplication/com.github.proto-openapi.spec.v2@v1.0+protobufgłównie do celu komunikacji wewnątrz klastra
application/jsondomyślne
*udostępnia application/json
Dozwolone nagłówki żądań dla zapytania OpenAPI v2
W Kubernetes zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o Protobuf, który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze i opisany w [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md). Pliki IDL dla każdego ze schematów można znaleźć w pakietach Go, które definiują obiekty API. -Przed wersją 1.14, apiserver Kubernetes udostępniał też specyfikację API [Swagger v1.2](http://swagger.io/) poprzez `/swaggerapi`. -Ten punkt końcowy został skierowany do wycofania i ostatecznie usunięty w wersji Kubernetes 1.14. - ## Obsługa wersji API -Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, na przykład: `/api/v1` lub +Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje +równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, na przykład: `/api/v1` lub `/apis/extensions/v1beta1`. -Zdecydowaliśmy się na rozdział wersji na poziomie całego API, a nie na poziomie poszczególnych zasobów lub pól, aby być pewnym, że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe i ich zachowania i pozwala na kontrolowany dostęp do tych API, które są w fazie wycofywania lub fazie eksperymentalnej. Schematy serializacji JSON i Protobuf stosują się do tych samych reguł wprowadzania zmian schematów — cały opis poniżej odnosi się do obydwu z nich. +Zdecydowaliśmy się na rozdział wersji na poziomie całego API, a nie na poziomie poszczególnych zasobów lub pól, aby być pewnym, +że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe i ich zachowania i pozwala +na kontrolowany dostęp do tych API, które są w fazie wycofywania lub fazie eksperymentalnej. -Należy mieć na uwadze, że wersje API i wersje oprogramowania są powiązane ze sobą w sposób niebezpośredni. [API and release -versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) opisuje związki pomiędzy zarządzaniem wersjami API i oprogramowania. +Schematy serializacji JSON i Protobuf stosują się do tych samych reguł wprowadzania zmian schematów — cały opis poniżej odnosi się do obydwu z nich. -Różne wersje API oznaczają inną stabilność i poziom wsparcia. Kryteria dla każdego z tych poziomów opisano szczegółowo w [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). Podsumowanie zamieszczono poniżej poniżej: +Należy mieć na uwadze, że wersje API i wersje oprogramowania są powiązane ze sobą w sposób niebezpośredni. Proponowany +[Kubernetes Release Versioning](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) opisuje związki pomiędzy zarządzaniem wersjami API i oprogramowania. + +Różne wersje API oznaczają inną stabilność i poziom wsparcia. Kryteria dla każdego z tych poziomów opisano szczegółowo +w [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). +Podsumowanie zamieszczono poniżej: - Poziom Alfa: - Nazwa wersji zawiera słowo `alpha` (np. `v1alpha1`). @@ -81,8 +105,11 @@ Różne wersje API oznaczają inną stabilność i poziom wsparcia. Kryteria dla - Nazwa wersji zawiera słowo `beta` (np. `v2beta3`). - Oprogramowanie jest dobrze przetestowane. Włączenie tej funkcjonalności uznaje się za bezpieczne. Funkcjonalność domyślnie włączona. - Wsparcie dla funkcjonalności będzie utrzymywane, choć może zmieniać się w niektórych szczegółach. - - Schemat lub semantyka obiektu może się zmienić w sposób niezgodny z poprzednimi wersjami w następnych wydaniach beta lub stabilnych. Jeśli taka zmiana będzie miała miejsce, dostarczymy instrukcję migracji do kolejnej wersji. Możemy wymagać skasowania, zmiany i odtworzenia obiektów API. Proces zmiany może wymagać dodatkowych wstępnych analiz. W czasie wprowadzania zmian mogą wystąpić przerwy w dostępności aplikacji, które z tej funkcjonalności korzystają. - - Rekomendowane tylko dla zastosowań niekrytycznych dla biznesu ze względu na potencjalnie niezgodne zmiany w kolejnych wersjach oprogramowania. Jeśli masz wiele klastrów, które mogą być aktualizowane niezależnie, można to ograniczenie pominąć. + - Schemat lub semantyka obiektu może się zmienić w sposób niezgodny z poprzednimi wersjami w następnych wydaniach beta lub stabilnych. Jeśli taka zmiana będzie miała miejsce, + dostarczymy instrukcję migracji do kolejnej wersji. Możemy wymagać skasowania, zmiany i odtworzenia obiektów API. + Proces zmiany może wymagać dodatkowych wstępnych analiz. W czasie wprowadzania zmian mogą wystąpić przerwy w dostępności aplikacji, które z tej funkcjonalności korzystają. + - Rekomendowane tylko dla zastosowań niekrytycznych dla biznesu ze względu na potencjalnie niezgodne zmiany w kolejnych wersjach oprogramowania. + Jeśli masz wiele klastrów, które mogą być aktualizowane niezależnie, można to ograniczenie pominąć. - **Testuj nasze funkcjonalności w fazie beta i zgłaszaj swoje uwagi! Po wyjściu z fazy beta, możemy nie mieć już możliwości — ze względów praktycznych — wprowadzać w nich żadnych zmian.** - Poziom Stabilny: - Nazwa wersji jest w postaci `vX`, gdzie `X` jest liczbą naturalną. @@ -111,18 +138,35 @@ API może być rozbudowane na dwa sposoby przy użyciu [custom resources](/docs/ ## Włączanie i wyłączanie grup API Określone zasoby i grupy API są włączone domyślnie. Włączanie i wyłączanie odbywa się poprzez ustawienie `--runtime-config` -w apiserwerze. `--runtime-config` przyjmuje wartości oddzielane przecinkami. Przykładowo, aby wyłączyć batch/v1, należy ustawić +w kube-apiserver. + +`--runtime-config` przyjmuje wartości oddzielane przecinkami. Przykładowo, aby wyłączyć batch/v1, należy ustawić `--runtime-config=batch/v1=false`, aby włączyć batch/v2alpha1, należy ustawić `--runtime-config=batch/v2alpha1`. -Ta opcja przyjmuje rozdzielony przecinkami zbiór par klucz=wartość, który opisuje konfigurację wykonawczą apiserwera. +Ta opcja przyjmuje rozdzielony przecinkami zbiór par klucz=wartość, który opisuje konfigurację wykonawczą serwera API. -{{< note >}}Włączenie lub wyłączenie grup lub zasobów wymaga restartu apiserver i controller-manager, aby zmiany w `--runtime-config` zostały wprowadzone.{{< /note >}} +{{< note >}}Włączenie lub wyłączenie grup lub zasobów wymaga restartu kube-apiserver i kube-controller-manager, +aby zmiany w `--runtime-config` zostały wprowadzone.{{< /note >}} -## Jak włączać dostęp do grup zasobów extensions/v1beta1 +## Dostęp do grup zasobów _extensions/v1beta1_ -DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs i ReplicaSets znajdują się w grupie API `extensions/v1beta1` i są domyślnie włączone. +DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs i ReplicaSets znajdują się w grupie API `extensions/v1beta1` i są domyślnie wyłączone. Przykładowo: aby włączyć deployments i daemonsets, ustaw `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. {{< note >}}Włączanie i wyłączanie pojedynczych zasobów możliwe jest jedynie w ramach grupy API `extensions/v1beta1` z przyczyn historycznych{{< /note >}} +## Trwałość +Kubernetes przechowuje swój stan w postaci serializowanej jako zasoby API zapisywane w +{{< glossary_tooltip term_id="etcd" >}}. + + +## {{% heading "whatsnext" %}} + +[Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) opisuje +sposoby, jakimi klaster zarządza dostępem do API. + +Ogólne wytyczne dotyczące API opisano w +[API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions). + +Punkty dostępowe API _(endpoints)_, typy zasobów i przykłady zamieszczono w [API Reference](/docs/reference/kubernetes-api/). diff --git a/content/pl/docs/concepts/overview/what-is-kubernetes.md b/content/pl/docs/concepts/overview/what-is-kubernetes.md index fcb8f7714c..861476a561 100644 --- a/content/pl/docs/concepts/overview/what-is-kubernetes.md +++ b/content/pl/docs/concepts/overview/what-is-kubernetes.md @@ -73,7 +73,7 @@ Kubernetes pozwala składować i zarządzać informacjami poufnymi, takimi jak h ## Czym Kubernetes nie jest -Kubernetes nie jest tradycyjnym, zawierającym wszystko systemem PaaS *(Platform as a Service)*. Ponieważ Kubernetes działa w warstwie kontenerów, a nie sprzętu, posiada różne funkcjonalności ogólnego zastosowania, wspólne dla innych rozwiązań PaaS, takie jak: instalacje *(deployments)*, skalowanie, balansowanie ruchu, logowanie i monitoring. Co ważne, Kubernetes nie jest monolitem i te domyślnie dostępne rozwiązania są opcjonalne i działają jako wtyczki. Kubernetes dostarcza elementy, z których może być zbudowana platforma deweloperska, ale pozostawia użytkownikowi wybór i elastyczność tam, gdzie jest to ważne. +Kubernetes nie jest tradycyjnym, zawierającym wszystko systemem PaaS *(Platform as a Service)*. Ponieważ Kubernetes działa w warstwie kontenerów, a nie sprzętu, posiada różne funkcjonalności ogólnego zastosowania, wspólne dla innych rozwiązań PaaS, takie jak: instalacje *(deployments)*, skalowanie i balansowanie ruchu, umożliwiając użytkownikom integrację rozwiązań służących do logowania, monitoringu i ostrzegania. Co ważne, Kubernetes nie jest monolitem i domyślnie dostępne rozwiązania są opcjonalne i działają jako wtyczki. Kubernetes dostarcza elementy, z których może być zbudowana platforma deweloperska, ale pozostawia użytkownikowi wybór i elastyczność tam, gdzie jest to ważne. Kubernetes: diff --git a/content/pl/docs/contribute/_index.md b/content/pl/docs/contribute/_index.md index 336c3bbf13..c8fa5f636b 100644 --- a/content/pl/docs/contribute/_index.md +++ b/content/pl/docs/contribute/_index.md @@ -23,8 +23,6 @@ Współtwórcy dokumentacji Kubernetesa: Zapraszamy do współpracy wszystkich - zarówno nowicjuszy, jak i doświadczonych! - - ## Jak zacząć? @@ -49,7 +47,7 @@ ról i uprawnień. - [Otwórz *pull request* przy pomocy GitHub-a](/docs/contribute/new-content/new-content/#changes-using-github) dotyczący zmiany istniejącej dokumentacji i dowiedz się, jak otwierać zgłoszenia przy GitHub-ie. - [Zrecenzuj *pull requests*](/docs/contribute/review/reviewing-prs/) innego członka społeczności Kubernetes pod kątem dokładności i stylu. - Zapoznaj się z poradnikami Kubernetesa dotyczącymi [zawartości](/docs/contribute/style/content-guide/) i [stylu](/docs/contribute/style/style-guide/), aby twoje uwagi były zgodne z tymi wytycznymi. -- Dowiedz się, jak [używać szablonów stron](/docs/contribute/style/page-templates/) i [skrótów Hugo](/docs/contribute/style/hugo-shortcodes/), aby wprowadzać większe zmiany. +- Przeczytaj o [różnych typach zawartości na stronie](/docs/contribute/style/page-content-types/) i [skrótach Hugo](/docs/contribute/style/hugo-shortcodes/). ## Co dalej? diff --git a/content/pl/docs/home/_index.md b/content/pl/docs/home/_index.md index cae9bb4dc5..5c8facdbc5 100644 --- a/content/pl/docs/home/_index.md +++ b/content/pl/docs/home/_index.md @@ -13,7 +13,7 @@ menu: title: "Dokumentacja" weight: 20 post: > -

Naucz się, jak korzystać z Kubernetesa z pomocą dokumentacji, która opisuje pojęcia, zawiera samouczki i informacje źródłowe. Możesz także pomóc w jej tworzeniu!

+

Naucz się, jak korzystać z Kubernetesa z pomocą dokumentacji, która opisuje pojęcia, zawiera samouczki i informacje źródłowe. Możesz także pomóc w jej tworzeniu!

description: > Kubernetes to otwarte oprogramowanie służące do automatyzacji procesów uruchamiania, skalowania i zarządzania aplikacjami w kontenerach. Gospodarzem tego projektu o otwartym kodzie źródłowym jest Cloud Native Computing Foundation. overview: > @@ -54,8 +54,8 @@ cards: description: Każdy może przyczynić się do tworzenia dokumentacji - zarówno nowicjusze, jak i starzy wyjadacze. button: Weź udział button_path: /docs/contribute -- name: download - title: Pobierz Kubernetesa +- name: release-notes + title: Informacje o wydaniu description: Jeśli instalujesz lub aktualizujesz Kubernetesa, zajrzyj do informacji o najnowszym wydaniu. - name: about title: O dokumentacji diff --git a/content/pl/docs/home/supported-doc-versions.md b/content/pl/docs/home/supported-doc-versions.md index 4744e68071..19e08be721 100644 --- a/content/pl/docs/home/supported-doc-versions.md +++ b/content/pl/docs/home/supported-doc-versions.md @@ -23,5 +23,3 @@ Bieżąca wersja to ## Poprzednie wersje {{< versions-other >}} - - diff --git a/content/pl/docs/setup/_index.md b/content/pl/docs/setup/_index.md index cd00fb0e4f..2b014be8a4 100644 --- a/content/pl/docs/setup/_index.md +++ b/content/pl/docs/setup/_index.md @@ -24,8 +24,6 @@ Klaster Kubernetes możesz zainstalować na lokalnym komputerze, w chmurze czy w W dużym uproszczeniu, możesz zbudować klaster Kubernetes zarówno w środowisku szkoleniowym, jak i na potrzeby produkcyjne. - - ## Środowisko do nauki {#srodowisko-do-nauki} @@ -45,5 +43,3 @@ Aby uruchomić klaster Kubernetes do nauki na lokalnym komputerze, skorzystaj z Wybierając rozwiązanie dla środowiska produkcyjnego musisz zdecydować, którymi poziomami zarządzania klastrem (_abstrakcjami_) chcesz zajmować się sam, a które będą realizowane po stronie zewnętrznego operatora. Na stronie [Partnerzy Kubernetes](https://kubernetes.io/partners/#conformance) znajdziesz listę dostawców posiadających [certyfikację Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes). - - diff --git a/content/pl/docs/setup/release/_index.md b/content/pl/docs/setup/release/_index.md new file mode 100755 index 0000000000..2783105198 --- /dev/null +++ b/content/pl/docs/setup/release/_index.md @@ -0,0 +1,4 @@ +--- +title: "Informacje o wydaniach i dozwolonych różnicach wersji" +weight: 10 +--- diff --git a/content/pl/docs/tasks/_index.md b/content/pl/docs/tasks/_index.md index 60f8f9808b..5a185543c3 100644 --- a/content/pl/docs/tasks/_index.md +++ b/content/pl/docs/tasks/_index.md @@ -5,80 +5,13 @@ weight: 50 content_type: concept --- -{{< toc >}} - W tej części dokumentacji Kubernetesa znajdują się opisy sposobu realizacji różnych zadań. Przedstawione są one zazwyczaj jako krótka sekwencja kilku kroków związanych z pojedynczym zadaniem. - - - - -## Graficzny interfejs użytkownika _(Dashboard)_ - -Instalacja i użycie graficznego interfejsu użytkownika z poziomu przeglądarki do zarządzania aplikacjami w kontenerach uruchomionymi na klastrze Kubernetes. - -## Jak używać polecenia kubectl - -Instalacja i konfiguracja polecenia `kubectl` do bezpośredniego zarządzania klastrami Kubernetes. - -## Konfigurowanie podów i kontenerów - -Najpopularniejsze czynności związane z konfiguracją podów i kontenerów. - -## Uruchamianie aplikacji - -Standardowe metody zarządzania aplikacjami, m. in. prowadzenie stopniowych aktualizacji _(rolling updates)_, przekazywanie konfiguracji oraz skalowanie horyzontalne podów. - -## Uruchamianie zadań - -Uruchamianie zadań w trybie równoległym. - -## Dostęp do aplikacji na klastrze - -Rozkładanie obciążenia i przekierowywanie ruchu sieciowego, konfigurowanie firewalla i usług DNS w celu zapewnienia dostępu do aplikacji w klastrze. - -## Monitoring, rejestracja i znajdowanie błędów - -Konfigurowanie monitoringu oraz rejestrowanie zdarzeń i komunikatów, pomagające rozwiązywać problemy związane z pracą klastra lub aplikacji uruchamianych w kontenerach. - -## Dostęp do API Kubernetes - -Różne metody bezpośredniego dostępu do API Kubernetes. - -## Używanie TLS - -Konfigurowanie aplikacji w taki sposób, aby korzystała i ufała łańcuchowi certyfikatów wydawanych przez Urząd Certyfikacji (CA) klastra. - -## Administracja klastrem - -Standardowe metody zarządzania klasterem. - -## Zarządzanie aplikacjami ze stanem (_Stateful_) - -Popularne zadania związane z zarządzaniem aplikacjami stanowymi _(Stateful)_, w tym: skalowanie, usuwanie i rozwiązywanie problemów dotyczących _StatefulSets_. - -## Procesy klastra typu _daemon_ - -Standardowe metody zarządzania _DaemonSet_, włączając sposoby prowadzenia stopniowej aktualizacji (_rolling update_). - -## Zarządzanie procesorami graficznymi (GPU) - -Konfiguracja i przydzielanie węzłom klastra procesorów GPU NVIDIA jako zasobów. - -## Zarządzanie HugePages - -Konfiguracja i dysponowanie _huge pages_ jako zasobu klastra. - - - ## {{% heading "whatsnext" %}} - Jeśli chciałbyś stworzyć nową stronę poświęconą jakiemuś zadaniu, przeczytaj [Jak przygotować propozycję zmian (PR)](/docs/home/contribute/create-pull-request/). - - diff --git a/content/pl/docs/tutorials/_index.md b/content/pl/docs/tutorials/_index.md index 19e4bf8d24..0f9d7ac723 100644 --- a/content/pl/docs/tutorials/_index.md +++ b/content/pl/docs/tutorials/_index.md @@ -69,8 +69,8 @@ Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do ## {{% heading "whatsnext" %}} -Jeśli chciałbyś napisać nowy samouczek, zajrzyj na stronę -[Jak używać szablonów stron](/docs/home/contribute/page-templates/) -gdzie znajdziesz dodatkowe informacje na temat stron i szablonów samouczków. +Jeśli chciałbyś napisać nowy samouczek, odwiedź +[Content Page Types](/docs/contribute/style/page-content-types/), +gdzie znajdziesz dodatkowe informacje o tym typie strony. diff --git a/content/ru/docs/concepts/architecture/_index.md b/content/ru/docs/concepts/architecture/_index.md new file mode 100755 index 0000000000..eb68a67e53 --- /dev/null +++ b/content/ru/docs/concepts/architecture/_index.md @@ -0,0 +1,5 @@ +--- +title: "Кластерная Архитектура" +weight: 30 +--- + diff --git a/content/ru/docs/concepts/architecture/nodes.md b/content/ru/docs/concepts/architecture/nodes.md new file mode 100644 index 0000000000..7c10f75e1b --- /dev/null +++ b/content/ru/docs/concepts/architecture/nodes.md @@ -0,0 +1,340 @@ +--- +reviewers: +- caesarxuchao +- dchen1107 +title: Узлы +content_template: concept +weight: 10 +--- + + + +Kubernetes запускает ваши приложения, помещая контейнеры в Поды для запуска на Узлах (_Nodes_). +В зависимости от кластера, узел может быть виртуальной или физической машиной. Каждый узел +содержит сервисы, необходимые для запуска +{{< glossary_tooltip text="Подов" term_id="pod" >}}, управляемых +{{< glossary_tooltip text="плоскостью управления" term_id="control-plane" >}}. + +Обычно у вас есть несколько узлов в кластере; однако в среде обучения или среде +с ограниченными ресурсами у вас может быть только один. + +[Компоненты](/ru/docs/concepts/overview/components/##компоненты-узла) на узле включают +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, +{{< glossary_tooltip text="среду выполнения контейнера" term_id="container-runtime" >}} и +{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}. + + + +## Управление + +Существует два основных способа добавления Узлов в {{< glossary_tooltip text="API сервер" term_id="kube-apiserver" >}}: + +1. Kubelet на узле саморегистрируется в плоскости управления +2. Вы или другой пользователь вручную добавляете объект Узла + +После того, как вы создадите объект Узла или kubelet на узле самозарегистируется, +плоскость управления проверяет, является ли новый объект Узла валидным (правильным). Например, если вы +попробуете создать Узел при помощи следующего JSON манифеста: + +```json +{ + "kind": "Node", + "apiVersion": "v1", + "metadata": { + "name": "10.240.79.157", + "labels": { + "name": "my-first-k8s-node" + } + } +} +``` + +Kubernetes создает внутри себя объект Узла (представление). Kubernetes проверяет, +что kubelet зарегистрировался на API сервере, который совпадает с значением поля `metadata.name` Узла. +Если узел здоров (если все необходимые сервисы запущены), +он имеет право на запуск Пода. В противном случае, этот узел игнорируется для любой активности кластера +до тех пор, пока он не станет здоровым. + +{{< note >}} +Kubernetes сохраняет объект для невалидного Узла и продолжает проверять, становится ли он здоровым. + +Вы или {{< glossary_tooltip term_id="controller" text="контроллер">}} должны явно удалить объект Узла, чтобы +остановить проверку доступности узла. +{{< /note >}} + +Имя объекта Узла дожно быть валидным +[именем поддомена DNS](/ru/docs/concepts/overview/working-with-objects/names#имена-поддоменов-dns). + +### Саморегистрация Узлов + +Когда kubelet флаг `--register-node` имеет значение _true_ (по умолчанию), то kubelet будет пытаться +зарегистрировать себя на API сервере. Это наиболее предпочтительная модель, используемая большиством дистрибутивов. + +Для саморегистрации kubelet запускается со следующими опциями: + + - `--kubeconfig` - Путь к учетным данным для аутентификации на API сервере. + - `--cloud-provider` - Как общаться с {{< glossary_tooltip text="облачным провайдером" term_id="cloud-provider" >}}, чтобы прочитать метаданные о себе. + - `--register-node` - Автоматически зарегистрироваться на API сервере. + - `--register-with-taints` - Зарегистрировать узел с приведенным списком {{< glossary_tooltip text="ограничений (taints)" term_id="taint" >}} (разделенных запятыми `=:`). + + Ничего не делает, если `register-node` - _false_. + - `--node-ip` - IP-адрес узла. + - `--node-labels` - {{< glossary_tooltip text="Метки" term_id="label" >}} для добавления при регистрации узла в кластере (смотрите ограничения для меток, установленные [плагином согласования (admission plugin) NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)). + - `--node-status-update-frequency` - Указывает, как часто kubelet отправляет статус узла мастеру. + +Когда [режим авторизации Узла](/docs/reference/access-authn-authz/node/) и +[плагин согласования NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) включены, +kubelet'ы имеют право только создавать/изменять свой собственный ресурс Узла. + +### Ручное администрирование узла + +Вы можете создавать и изменять объекты узла используя +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}. + +Когда вы хотите создать объекты Узла вручную, установите kubelet флаг `--register-node=false`. + +Вы можете изменять объекты Узла независимо от настройки `--register-node`. +Например, вы можете установить метки на существующем Узле или пометить его неназначаемым. + +Вы можете использовать метки на Узлах в сочетании с селекторами узла на Подах для управления планированием. +Например, вы можете ограничить Под иметь право на запуск только на группе доступных узлов. + +Маркировка узла как неназначаемого предотвращает размещение планировщиком новых подов на этом Узле, +но не влияет на существующие Поды на Узле. Это полезно в качестве +подготовительного шага перед перезагрузкой узла или другим обслуживанием. + +Чтобы отметить Узел неназначемым, выполните: + +```shell +kubectl cordon $NODENAME +``` + +{{< note >}} +Поды, являющиеся частью {{< glossary_tooltip term_id="daemonset" >}} допускают +запуск на неназначаемом Узле. DaemonSets обычно обеспечивает локальные сервисы узла, +которые должны запускаться на Узле, даже если узел вытесняется для запуска приложений. +{{< /note >}} + +## Статус Узла + +Статус узла содержит следующие данные: + +* [Адреса (Addresses)](#адреса) +* [Условия (Conditions)](#условие) +* [Емкость и Выделяемые ресурсы (Capacity and Allocatable)](#емкость) +* [Информация (Info)](#информация) + +Вы можете использовать `kubectl` для просмотра статуса Узла и других деталей: + +```shell +kubectl describe node +``` + +Каждая секция из вывода команды описана ниже. + +### Адреса (Addresses) + +Использование этих полей варьируется в зависимости от вашего облачного провайдера или конфигурации физических серверов (_bare metal_). + +* HostName: Имя хоста, сообщаемое ядром узла. Может быть переопределено через kubelet `--hostname-override` параметр. +* ExternalIP: Обычно, IP адрес узла, который является внешне маршрутизируемым (доступен за пределами кластера). +* InternalIP: Обычно, IP адрес узла, который маршрутизируется только внутри кластера. + +### Условия (Conditions) {#условие} + +Поле `conditions` описывает статус всех `Running` узлов. Примеры условий включают в себя: + +{{< table caption = "Условия узла и описание того, когда применяется каждое условие." >}} +| Условие Узла | Описание | +|----------------------|-------------| +| `Ready` | `True` если узел здоров и готов принять поды, `False` если узел нездоров и не принимает поды, и `Unknown` если контроллер узла не получал информацию от узла в течение последнего периода `node-monitor-grace-period` (по умолчанию 40 секунд) | +| `DiskPressure` | `True` если присутствует давление на размер диска - то есть, если емкость диска мала; иначе `False` | +| `MemoryPressure` | `True` если существует давление на память узла - то есть, если памяти на узле мало; иначе `False` | +| `PIDPressure` | `True` если существует давление на процессы - то есть, если на узле слишком много процессов; иначе `False` | +| `NetworkUnavailable` | `True` если сеть для узла настроена некорректно, иначе `False` | +{{< /table >}} + +{{< note >}} +Если вы используете инструменты командной строки для вывода сведений об блокированном узле, +то Условие включает `SchedulingDisabled`. `SchedulingDisabled` не является Условием в Kubernetes API; +вместо этого блокированные узлы помечены как Неназначемые в их спецификации. +{{< /note >}} + +Состояние узла представлено в виде 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" + } +] +``` + +Если значение параметра Status для условия Ready остается `Unknown` или `False` +дольше чем период `pod-eviction-timeout`(аргумент, переданный в +{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), то все Поды +на узле планируются к удалению контроллером узла. По умолчанию таймаут выселения **пять минут**. +В некоторых случаях, когда узел недоступен, API сервер не может связаться с kubelet на узле. +Решение об удалении подов не может быть передано в kubelet до тех пор, пока связь с API сервером не будет восстановлена. +В то же время поды, которые запланированы к удалению, могут продолжать работать на отделенном узле. + +Контроллер узла не будет принудительно удалять поды до тех пор, пока не будет подтверждено, +что они перестали работать в кластере. Вы можете видеть, что поды, которые могут работать на недоступном узле, +находятся в состоянии `Terminating` или `Unknown`. В тех случаях, когда Kubernetes не может сделать вывод +из основной инфраструктуры о том, что узел окончательно покинул кластер, администратору кластера может потребоваться +удалить объект узла вручную. Удаление объекта узла из Kubernetes приводит к удалению всех объектов Подов, запущенных +на узле, с API сервера и освобождает их имена. + +Контроллер жизненного цикла узла автоматически создает +[ограничения (taints)](/docs/concepts/scheduling-eviction/taint-and-toleration/), которые представляют собой условия. +Планировщик учитывает ограничения Узла при назначении Пода на Узел. +Поды так же могут иметь допуски (tolerations), что позволяет им сопротивляться ограничениям Узла. + +Смотрите раздел [Ограничить Узлы по Условию](/docs/concepts/configuration/taint-and-toleration/#taint-nodes-by-condition) +для дополнительной информации. + +### Емкость и Выделяемые ресурсы (Capacity and Allocatable) {#емкость} + +Описывает ресурсы, доступные на узле: CPU, память и максимальное количество подов, +которые могут быть запланированы на узле. + +Поля в блоке capasity указывают общее количество ресурсов, которые есть на Узле. +Блок allocatable указывает количество ресурсовна Узле, +которые доступны для использования обычными Подами. + +Вы можете прочитать больше о емкости и выделяемых ресурсах, изучая, как [зарезервировать вычислительные ресурсы](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) на Узле. + +### Информация (Info) + +Описывает общую информацию об узле, такую как версия ядра, версия Kubernetes (версии kubelet и kube-proxy), версия Docker (если используется) и название ОС. +Эта информация соберается Kubelet'ом на узле. + +### Контроллер узла + +{{< glossary_tooltip text="Контроллер " term_id="controller" >}} узла является компонентом +плоскости управления Kubernetes, который управляет различными аспектами узлов. + +Контроллер узла играет различные роли в жизни узла. Первая - назначение CIDR-блока узлу +при его регистрации (если включено назначение CIDR). + +Вторая - поддержание в актуальном состоянии внутреннего списка узлов контроллера узла +согласно списку доступных машин облачного провайдера. При работе в облачной среде всякий раз, +когда узел неисправен, контроллер узла запрашивает облачного провайдера, доступна ли +виртуальная машина для этого узла. Если нет, то контроллер узла удаляет узел из +своего списка узлов. + +Третья - это мониторинг работоспособности узлов. Контроллер узла +отвечает за обновление условия NodeReady для NodeStatus на +ConditionUnknown, когда узел становится недоступным (т.е. контроллер узла +по какой-то причине перестает получать сердцебиения (heartbeats) от узла, +например, из-за того, что узел упал), и затем позже выселяет все поды с узла +(используя мягкое (graceful) завершение) если узел продолжает быть недоступным. +(По умолчанию таймауты составляют 40 секунд, чтобы начать сообщать `ConditionUnknown`, +и 5 минут после, чтобы начать выселять поды.) Контроллер узла проверяет состояние каждого узла +каждые `--node-monitor-period` секунд. + +#### Сердцебиения + +Сердцебиения, посылаемые узлами Kubernetes, помогают определить доступность узла. + +Существует две формы сердцебиений: обновление `NodeStatus` и +[Lease объект](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io). +Каждый узел имеет связанный с ним Lease объект в `kube-node-lease` +{{< glossary_tooltip term_id="namespace" text="namespace">}}. +Lease - это легковестный ресурс, который улучшает производительность +сердцебиений узла при масштабировании кластера. + +Kubelet отвечает за создание и обновление `NodeStatus` и Lease объекта. + +- Kubelet обновляет `NodeStatus` либо когда происходит изменение статуса, + либо если в течение настронного интервала обновления не было. По умолчанию + интервал для обновлений `NodeStatus` составляет 5 минут (намного больше, + чем 40-секундный стандартный таймаут для недоступных узлов). +- Kubelet созадет и затем обновляет свой Lease объект каждый 10 секунд + (интервал обновления по умолчанию). Lease обновления происходят независимо от + `NodeStatus` обновлений. Если обновление Lease завершается неудачно, + kubelet повторяет попытку с экспоненциальным откатом, начинающимся с 200 миллисекунд и ограниченным 7 секундами. + +#### Надежность + +В большинстве случаев контроллер узла ограничивает скорость выселения +до `--node-eviction-rate` (по умолчанию 0,1) в секунду, что означает, +что он не выселяет поды с узлов быстрее чем c 1 узела в 10 секунд. + +Поведение выселения узла изменяется, когда узел в текущей зоне доступности +становится нездоровым. Контроллер узла проверяет, какой процент узлов в зоне +нездоров (NodeReady условие в значении ConditionUnknown или ConditiononFalse) +в одно и то же время. Если доля нездоровых узлов не меньше +`--unhealthy-zone-threshold` (по умолчанию 0.55), то скорость выселения уменьшается: +если кластер небольшой (т.е. количество узлов меньше или равно +`--large-cluster-size-threshold` - по умолчанию, 50), то выселения прекращаются, +в противном случае скорость выселения снижается до +`--secondary-node-eviction-rate` (по умолчанию, 0.01) в секунду. Причина, по которой +эти политики реализуются для каждой зоны доступности, заключается в том, +что одна зона доступности может стать отделенной от мастера, в то время как другие +остаются подключенными. Если ваш кластер не охватывает несколько зон доступности +облачного провайдера, то существует только одна зона доступности (весь кластер). + +Основная причина разнесения ваших узлов по зонам доступности заключается в том, +что приложения могут быть перенесены в здоровые зоны, когда одна из зон полностью +становится недоступной. Поэтому, если все узлы в зоне нездоровы, то контроллер узла +выселяет поды с нормальной скоростью `--node-eviction-rate`. Крайний случай - когда все зоны +полностью нездоровы (т.е. в кластере нет здоровых узлов). В таком случае +контроллер узла предполагает, что существует некоторая проблема с подключением к мастеру, +и останавеливает все выселения, пока какое-нибудь подключение не будет восстановлено. + +Контроллер узла также отвечает за выселение подов, запущенных на узлах с +`NoExecute` ограничениями, за исключением тех подов, которые сопротивляются этим ограничениям. +Контроллер узла так же добавляет {{< glossary_tooltip text="ограничения" term_id="taint" >}} +соотвествующие проблемам узла, таким как узел недоступен или не готов. Это означает, +что планировщик не будет размещать поды на нездоровых узлах. + +{{< caution >}} +`kubectl cordon` помечает узел как 'неназначемый', что имеет побочный эфект от контроллера сервисов, +удаляющего узел из любых списков целей LoadBalancer узла, на которые он ранее имел право, +эффектино убирая входящий трафик балансировщика нагрузки с блокированного узла(ов). +{{< /caution >}} + +### Емкость узла + +Объекты узла отслеживают информацию о емкости ресурсов узла (например, +объем доступной памяти и количество CPU). +Узлы, которые [самостоятельно зарегистировались](#саморегистрация-узлов) сообщают +о свое емкости во время регистрации. Если вы [вручную](#ручное-администрирование-узла) +добавляете узел, то вам нужно задать информацию о емкости узла при его добавлении. + +{{< glossary_tooltip text="Планировщик" term_id="kube-scheduler" >}} Kubernetes гарантирует, +что для всех Подов на Узле достаточно ресурсов. Планировщик проверяет, +что сумма requests от контейнеров на узле не превышает емкость узла. +Эта сумма requests включает все контейнеры, управляемые kubelet, +но исключает любые контейнеры, запущенные непосредственно средой выполнения контейнера, +а также исключает любые процессы, запущенные вне контроля kubelet. + +{{< note >}} +Если вы явно хотите зарезервировать ресурсы для процессов, не связанныз с Подами, смотрите раздел +[зарезервировать ресурсы для системных демонов](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved). +{{< /note >}} + +## Топология узла + +{{< feature-state state="alpha" for_k8s_version="v1.16" >}} + +Если вы включили `TopologyManager` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/), то kubelet +может использовать подсказки топологии при принятии решений о выделении ресурсов. +Смотрите [Контроль Политик Управления Топологией на Узле](/docs/tasks/administer-cluster/topology-manager/) +для дополнительной информации. + +## {{% heading "whatsnext" %}} + +* Подробнее про[компоненты](/ru/docs/concepts/overview/components/#компоненты-узла) из которых состоит узел. +* Подробнее про [Определение API для Узла](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). +* Подробнее про [Узлы](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) + of the architecture design document. +* Подробнее про [ограничения и допуски](/docs/concepts/configuration/taint-and-toleration/). +* Подробнее про [автомаштабирование кластера](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling). diff --git a/content/ru/docs/reference/glossary/cloud-provider.md b/content/ru/docs/reference/glossary/cloud-provider.md new file mode 100755 index 0000000000..55414a63ee --- /dev/null +++ b/content/ru/docs/reference/glossary/cloud-provider.md @@ -0,0 +1,32 @@ +--- +title: Облачный Провайдер (Cloud Provider) +id: cloud-provider +date: 2018-04-12 +full_link: /docs/concepts/cluster-administration/cloud-providers +short_description: > + Организация, которая предлагает платформу облачных вычислений. + +aka: +- Поставщик Облачных Услуг (Cloud Service Provider) +tags: +- community +--- + Бизнес или другая организация, которая предлагает платформу облачных вычислений. + + + +Облачные Провайдеры, иногда называемые Поставщиками Облачных Услуг (Cloud Service Provider, CSPs), +предлагают облачные вычислительные платформы или услуги. + +Многие облачные провайдеры предлагают управляемую инфраструктуру (также называемую +Инфраструктура как Услуга (Infrastructure as a Service) или IaaS). +С управляемой инфраструктурой облачный провайдер отвечает за +сервера, хранилище и сеть, в то время как вы управляете слоями поверх этого, +такими как запуск Kubernetes кластера. + +Вы также можете найти Kubernetes в качестве управляемого сервиса; иногда его называют +Платформа как Услуга (Platform as a Service) или PaaS. С упарвляемым Kubernetes +ваш облачный провайдер отвечает за +{{< glossary_tooltip term_id="control-plane" text="плоскость управления" >}} Kubernetes, а также за +{{< glossary_tooltip term_id="node" text="узлы" >}} и инфраструктуру, на которую они полагаются: +сеть, хранилище и, возможно, другие элементы, такие как балансировщики нагрузки. diff --git a/content/ru/docs/reference/glossary/controller.md b/content/ru/docs/reference/glossary/controller.md new file mode 100755 index 0000000000..c1efc41d1b --- /dev/null +++ b/content/ru/docs/reference/glossary/controller.md @@ -0,0 +1,29 @@ +--- +title: Контроллер (Controller) +id: controller +date: 2018-04-12 +full_link: /docs/concepts/architecture/controller/ +short_description: > + Управляющий цикл который отслеживает общее состояние кластера через API-сервер и вносит изменения пытаясь приветси текушее состояние к желаемому состоянию. + +aka: +tags: +- architecture +- fundamental +--- +Контроллеры в Kubernetes - управляющие циклы, которые отслеживают состояние вашего +{{< glossary_tooltip term_id="cluster" text="кластера">}}, затем вносят или запрашивают +изменения там, где это необходимо. +Каждый контроллер пытается привести текущее состояние кластера ближе к желаемому состоянию. + + + +Контроллеры отсллеживают общее состояние вашего кластера через +{{< glossary_tooltip text="API-сервер" term_id="kube-apiserver" >}} (часть +{{< glossary_tooltip text="плоскости управления" term_id="control-plane" >}}). + +Некоторые контроллеры также работают внутри плоскости управления, обеспечивая +управляющие циклы, которые являются ядром для операций Kubernetes. Например: +контроллер развертывания (deployment controller), контроллер daemonset (daemonset controller), +контроллер пространства имен (namespace controller) и контроллер постоянных томов (persistent volume +controller) (и другие) работают с {{< glossary_tooltip term_id="kube-controller-manager" >}}. diff --git a/content/ru/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/ru/docs/tasks/configure-pod-container/assign-cpu-resource.md new file mode 100644 index 0000000000..c94a1ba15e --- /dev/null +++ b/content/ru/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -0,0 +1,266 @@ +--- +title: Задание ресурсов CPU для контейнеров и Pod'ов +content_type: task +weight: 20 +--- + + + +На этой странице показывается, как настроить *запрос* CPU и *лимит* CPU +для контейнера. Контейнер не сможет использовать больше ресурсов CPU, +чем для него ограничено. Если в системе есть свободное время CPU, +контейнеру гарантируется выдача запрошенных им ресурсов CPU. + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +На кластере должен быть хотя бы 1 доступный для работы CPU, чтобы запускать учебные примеры. + +Для некоторых шагов с этой страницы понадобится запущенный +[сервер метрик](https://github.com/kubernetes-incubator/metrics-server) +на вашем кластере. Если сервер метрик уже запущен, следующие шаги можно пропустить. + +Если вы используете {{< glossary_tooltip term_id="minikube" >}}, выполните следующую команду, +чтобы запустить сервер метрик: + +```shell +minikube addons enable metrics-server +``` + +Проверим, работает ли сервер метрик (или другой провайдер API ресурсов метрик, +`metrics.k8s.io`), выполните команду: + +```shell +kubectl get apiservices +``` + +Если API ресурсов метрик доступно, в выводе будет присутствовать +ссылка на `metrics.k8s.io`. + + +``` +NAME +v1beta1.metrics.k8s.io +``` + + + + + + +## Создание пространства имён + +Создадим {{< glossary_tooltip term_id="namespace" >}}, чтобы создаваемые в этом упражнении +ресурсы были изолированы от остального кластера. + +```shell +kubectl create namespace cpu-example +``` + +## Установка запроса CPU и лимита CPU + +Чтобы установить запрос CPU для контейнера, подключите поле `resources:requests` +в манифест ресурсов контейнера. Для установки ограничения по CPU подключите `resources:limits`. + +В этом упражнении мы создадим Pod, имеющий один контейнер. Зададим для контейнера запрос в +0.5 CPU и лимит в 1 CPU. Конфигурационный файл для такого Pod'а: + +{{< codenew file="pods/resource/cpu-request-limit.yaml" >}} + +Раздел `args` конфигурационного файла содержит аргументы для контейнера в момент старта. +Аргумент `-cpus "2"` говорит контейнеру попытаться использовать 2 CPU. + +Создадим Pod: + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example +``` + +Удостоверимся, что Pod запущен: + +```shell +kubectl get pod cpu-demo --namespace=cpu-example +``` + +Посмотрим детальную информацию о Pod'е: + +```shell +kubectl get pod cpu-demo --output=yaml --namespace=cpu-example +``` + +В выводе видно, что Pod имеет один контейнер с запросом в 500 милли-CPU и с ограничением в 1 CPU. + +```yaml +resources: + limits: + cpu: "1" + requests: + cpu: 500m +``` + +Запустим `kubectl top`, чтобы получить метрики Pod'a: + +```shell +kubectl top pod cpu-demo --namespace=cpu-example +``` + +В этом варианте вывода Pod'ом использовано 974 милли-CPU, что лишь чуть меньше +заданного в конфигурации Pod'a ограничения в 1 CPU. + +``` +NAME CPU(cores) MEMORY(bytes) +cpu-demo 974m +``` + +Напомним, что установкой параметра `-cpu "2"` для контейнера было задано попытаться использовать 2 CPU, +однако в конфигурации присутствует ограничение всего в 1 CPU. Использование контейнером CPU было отрегулировано, +поскольку он попытался занять больше ресурсов, чем ему позволено. + +{{< note >}} +Другое возможное объяснение для выделения менее 1.0 CPU в отсутствии на ноде достаточного количества +свободных CPU ресурсов. Напомним, что в начальных условиях для этого упражнения было наличие у кластера +хотя бы 1 CPU, доступного для использования. Если контейнер запущен на ноде, имеющей в своём распоряжении всего 1 CPU, +контейнер не сможет использовать более 1 CPU независимо от заданных для него ограничений. +{{< /note >}} + +Удалим Pod: + +```shell +kubectl delete pod cpu-demo --namespace=cpu-example +``` + +## Единицы измерения CPU + +Ресурсы CPU измеряются в *CPU* единицах. Один CPU, в Kubernetes, соответствует: + +* 1 AWS vCPU +* 1 GCP Core +* 1 Azure vCore +* 1 гипертрединговое ядро на физическом процессоре Intel с Гипертредингом + +Дробные значения возможны. Контейнер, запрашивающий 0.5 CPU, получит вполовину меньше ресурсов, +чем контейнер, запрашивающий 1 CPU. Можно использовать окончание m для обозначения милли. Например, +100m CPU, 100 milliCPU и 0.1 CPU обозначают одно и то же. Точность выше 1m не поддерживается. + +CPU всегда запрашивается в абсолютных величинах, не в относиительных; 0.1 будет одинаковой частью от CPU +для одноядерного, двухъядерного или 48-ядерного процессора. + +## Запрос ресурсов CPU больше доступного на ноде + +Запросы и лимиты CPU устанавливаются для контейнеров, но также полезно рассматривать и Pod +имеющим эти характеристики. Запросом CPU для Pod'а является сумма запросов CPU всех его контейнеров. +Аналогично и лимит CPU для Pod'а - сумма всех ограничений CPU у его контейнеров. + +Планирование Pod'а основано на запросах. Pod попадает в расписание запуска на ноде лишь в случае +достаточного количества доступных ресурсов CPU на ноде, чтобы удовлетворить запрос CPU Pod'а. + +В этом упражнении мы создадим Pod с запросом CPU, превышающим мощности любой ноды в вашем кластере. +Ниже представлен конфигурационный файл для Pod'а с одним контейнером. Контейнер запрашивает 100 CPU, +что почти наверняка превышет имеющиеся мощности любой ноды в кластере. + +{{< codenew file="pods/resource/cpu-request-limit-2.yaml" >}} + +Создадим Pod: + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example +``` + +Проверим статус Pod'а: + +```shell +kubectl get pod cpu-demo-2 --namespace=cpu-example +``` + +Вывод показывает Pending статус у Pod'а. То есть Pod не запланирован к запуску +ни на одной ноде и будет оставаться в статусе Pending постоянно: + + +``` +NAME READY STATUS RESTARTS AGE +cpu-demo-2 0/1 Pending 0 7m +``` + +Посмотрим подробную информацию о Pod'е, включающую в себя события: + + +```shell +kubectl describe pod cpu-demo-2 --namespace=cpu-example +``` + +В выводе отражено, что контейнер не может быть запланирован из-за нехватки ресурсов +CPU на нодах: + + +``` +Events: + Reason Message + ------ ------- + FailedScheduling No nodes are available that match all of the following predicates:: Insufficient cpu (3). +``` + +Удалим Pod: + +```shell +kubectl delete pod cpu-demo-2 --namespace=cpu-example +``` + +## Если ограничения на CPU не заданы + +Если ограничения на использование контейнером CPU не установлены, возможны следующие варианты: + +* У контейнера отсутствует верхняя граница количества CPU доступных ему ресурсов. В таком случае +он может занять все ресурсы CPU, доступные на ноде, на которой он запущен. + +* Контейнер запущен в пространстве имён, в котором задана стандартная величина ограничения +ресурсов CPU. Тогда контейнеру автоматически присваивается это ограничение. Администраторы +кластера могут использовать [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core/), +чтобы задать стандартную величину ограничения ресурсов CPU. + +## Мотивация для использования запросов и лимитов CPU + +Вы можете распоряжаться ресурсами CPU на нодах вашего кластера эффективнее, если для +запущенных контейнеров установлены запросы и ограничения на использование ресурсов CPU. +Задание небольшого запроса CPU даёт Pod'у хорошие шансы быть запланированным. Установка +лимита на ресурсы CPU, большего, чем запрос, позволяет достичь 2 вещей: + +* При увеличении нагрузки Pod может задействовать дополнительные ресурсы CPU. +* Количество ресурсов CPU, которые Pod может задействовать при повышении нагрузки, ограничено +некоторой разумной величиной. + +## Очистка + +Удалим созданное для этого упражнения пространство имён: + +```shell +kubectl delete namespace cpu-example +``` + + + +## {{% heading "whatsnext" %}} + + +### Для разработчиков приложений + +* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/) + +* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/) + +### Для администраторов кластера + +* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/) + +* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/) + +* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) + +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) + +* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) + +* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/) + +* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) \ No newline at end of file diff --git a/content/ru/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ru/docs/tasks/configure-pod-container/assign-memory-resource.md new file mode 100644 index 0000000000..826aa6c577 --- /dev/null +++ b/content/ru/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -0,0 +1,352 @@ +--- +title: Задание ресурсов памяти для контейнеров и Pod'ов +content_type: task +weight: 10 +--- + + + +На этой странице рассказывается, как настраивать *запрос* памяти и её *лимит* для контейнеров. Контейнеру гарантируется столько памяти, сколько он запросит, но не больше установленных ограничений. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +Каждая нода вашего кластера должна располагать хотя бы 300 Мб памяти. + +Некоторые операции на этой странице предполагают работу +[сервера метрик](https://github.com/kubernetes-incubator/metrics-server) +на вашем кластере. Если сервер метрик у вас уже запущен, следующие действия +можно пропустить. + +Если вы используете Minikube, выполните следующую команду, чтобы запустить +сервер метрик: + +```shell +minikube addons enable metrics-server +``` + +Чтобы проверить работу сервера меток или другого провайдера API ресурсов метрик + (`metrics.k8s.io`), запустите команду: + +```shell +kubectl get apiservices +``` + +Если API ресурсов метрики доступно, в выводе команды будет содержаться +ссылка на `metrics.k8s.io`. + +```shell +NAME +v1beta1.metrics.k8s.io +``` + + + +## Создание пространства имён + +Создадим пространство имён, чтобы ресурсы, которыми будем пользоваться в данном упражнении, +были изолированы от остального кластера: + +```shell +kubectl create namespace mem-example +``` + +## Установка запроса памяти и лимита памяти + +Для установки запроса памяти контейнеру подключите поле `resources:requests` в манифест ресурсов контейнера. +Для ограничений по памяти - добавьте `resources:limits`. + +В этом упражнении создаётся Pod, содержащий один контейнер. +Зададим контейнеру запрос памяти в 100 Мб и её ограничение в 200 Мб. Конфигурационный файл для Pod'а: + +{{< codenew file="pods/resource/memory-request-limit.yaml" >}} + +Раздел `args` конфигурационного файла содержит аргументы для контейнера в момент старта. +Аргументы `"--vm-bytes", "150M"` указывают контейнеру попытаться занять 150 Мб памяти. + +Создадим Pod: + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example +``` + +Убедимся, что контейнер Pod'a запущен: + +```shell +kubectl get pod memory-demo --namespace=mem-example +``` + +Посмотрим подробную информацию о Pod'е: + +```shell +kubectl get pod memory-demo --output=yaml --namespace=mem-example +``` + +В выводе мы видим, что для контейнера в Pod'е зарезервировано 100 Мб памяти и выставлено 200 Мб ограничения. + + +```yaml +... +resources: + limits: + memory: 200Mi + requests: + memory: 100Mi +... +``` + +Запустим `kubectl top`, чтобы получить метрики Pod'a: + +```shell +kubectl top pod memory-demo --namespace=mem-example +``` + +Вывод команды показывает, что Pod использовал примерно 162900000 байт памяти - и это около 150 Мб. +Данная величина больше установленного запроса в 100 Мб, но укладывается в имеющееся ограничение на 200 Мб. + +``` +NAME CPU(cores) MEMORY(bytes) +memory-demo 162856960 +``` + +Удалим Pod: + +```shell +kubectl delete pod memory-demo --namespace=mem-example +``` + +## Превышение контейнером лимита памяти + +Контейнер может превысить величину запроса памяти, если нода имеет достаточно ресурсов памяти. +Но превышение заданного ограничения памяти не допускается. Если контейнер запрашивает +больше памяти, чем ему разрешено использовать, то он становится кандидатом на удаление. +Если превышение лимита памяти продолжится, контейнер удаляется. +Если удалённый контейнер может быть перезапущен, то kubelet перезапускает его, как и в случае +любой другой неполадки в работе. + +В этом упражнении создадим Pod, который попытается занять больше памяти, чем для него ограничено. +Ниже представлен конфигурационный файл для Pod'a с одним контейнером, имеющим 50 Мб +на запрос памяти и 100 Мб лимита памяти: + +{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}} + +В разделе `args` можно увидеть, что контейнер будет пытаться занять +250 Мб - и это значительно превышает лимит в 100 Мб. + +Создадим Pod: + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example +``` + +Посмотрим подробную информацию о Pod'е: + +```shell +kubectl get pod memory-demo-2 --namespace=mem-example +``` + +В этот момент контейнер уже либо запущен, либо убит. +Будем повторять предыдущую команду, пока контейнер не окажется убитым: + +```shell +NAME READY STATUS RESTARTS AGE +memory-demo-2 0/1 OOMKilled 1 24s +``` + +Посмотрим ещё более подробный вид статуса контейнера: + +```shell +kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example +``` + +В выводе показано, что контейнер был убит по причине недостатка памяти (OOM): + +```shell +lastState: + terminated: + containerID: docker://65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f + exitCode: 137 + finishedAt: 2017-06-20T20:52:19Z + reason: OOMKilled + startedAt: null +``` + +В данном упражнении контейнер может быть перезапущен, поэтому kubelet стартует его. +Выполните следующую команду несколько раз, чтобы увидеть, как контейнер раз за разом +убивается и запускается снова: + +```shell +kubectl get pod memory-demo-2 --namespace=mem-example +``` + +Вывод показывает, что контейнер убит, перезапущен, снова убит, перезапущен, и т.д.: + +``` +kubectl get pod memory-demo-2 --namespace=mem-example +NAME READY STATUS RESTARTS AGE +memory-demo-2 0/1 OOMKilled 1 37s +``` +``` + +kubectl get pod memory-demo-2 --namespace=mem-example +NAME READY STATUS RESTARTS AGE +memory-demo-2 1/1 Running 2 40s +``` + +Посмотрим подробную информацию об истории Pod'a: + +``` +kubectl describe pod memory-demo-2 --namespace=mem-example +``` + +Вывод показывает, что контейнер постоянно запускается и падает: + +``` +... Normal Created Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511 +... Warning BackOff Back-off restarting failed container +``` + +Посмотрим детальную информацию о нодах на кластере: + +``` +kubectl describe nodes +``` + +В выводе содержится запись о том, что контейнер убивается по причине нехватки памяти: + +``` +Warning OOMKilling Memory cgroup out of memory: Kill process 4481 (stress) score 1994 or sacrifice child +``` + +Удалим Pod: + +```shell +kubectl delete pod memory-demo-2 --namespace=mem-example +``` + +## Установка слишком большого для нод запроса памяти + +Запросы и ограничения памяти связаны с контейнерами, но полезно также рассматривать +эти параметры и для Pod'а. Запросом памяти для Pod'a будет сумма всех запросов памяти +контейнеров, имеющихся в Pod'е. Также и лимитом памяти будет сумма всех ограничений, +установленных для контейнеров. + +Планирование Pod'a основано на запросах. Pod запускается на ноде лишь в случае, если нода +может удовлетворить запрос памяти Pod'a. + +В данном упражнении мы создадим Pod, чей запрос памяти будет превышать ёмкость любой ноды +в кластере. Ниже представлен конфигурационный файл для Pod'a с одним контейнером, +имеющим запрос памяти в 1000 Гб (что наверняка превышает ёмкость любой имеющейся ноды): + +{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}} + +Создадим Pod: + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example +``` + +Проверим статус Pod'a: + +```shell +kubectl get pod memory-demo-3 --namespace=mem-example +``` + +Вывод показывает, что Pod имеет статус PENDING. Это значит, что он не запланирован ни на одной ноде, +и такой статус будет сохраняться всё время: + +``` +kubectl get pod memory-demo-3 --namespace=mem-example +NAME READY STATUS RESTARTS AGE +memory-demo-3 0/1 Pending 0 25s +``` + +Посмотрим подробную информацию о Pod'е, включающую события: + +```shell +kubectl describe pod memory-demo-3 --namespace=mem-example +``` + +Вывод показывает невозможность запуска контейнера из-за нехватки памяти на нодах: + +```shell +Events: + ... Reason Message + ------ ------- + ... FailedScheduling No nodes are available that match all of the following predicates:: Insufficient memory (3). +``` + +Удалим Pod: + +```shell +kubectl delete pod memory-demo-3 --namespace=mem-example +``` + +## Единицы измерения памяти + +Ресурсы памяти измеряются в байтах. Их можно задавать просто целым числом либо +целым числом с одним из следующих окончаний: E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki. +Например, представленные здесь варианты задают приблизительно одну и ту же величину: + +```shell +128974848, 129e6, 129M , 123Mi +``` + +## Если лимит памяти не задан + +Если вы не задали ограничение памяти для контейнера, возможны следующие варианты: + +* У контейнера отсутствует верхняя граница для памяти, которую он может использовать. +Такой контейнер может занять всю память, доступную на ноде, где он запущен, что, в свою очередь, может вызвать OOM Killer. +Также контейнеры без ограничений по ресурсам имеют более высокие шансы быть убитыми в случае вызова OOM Kill. + +* Контейнер запущен в пространстве имён, в котором настроена величина ограничений по умолчанию. +Тогда контейнеру автоматически присваивается это стандартное значение лимита. +Администраторы кластера могут использовать +[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) +для задания стандартной величины ограничений по памяти. + +## Мотивация для использования запросов и ограничений памяти + +При помощи задания величины запросов и лимитов памяти для контейнеров, +запущенных на вашем кластере, можно эффективно распоряжаться имеющимися на нодах ресурсами. +Задание Pod'у небольшого запроса памяти даёт хорошие шансы для него быть запланированным. +Ограничение памяти, превышающее величину запроса памяти, позволяет достичь 2 вещей: + +* Pod может иметь всплески активности, в течение которых ему может потребоваться дополнительная память. + +* Величина памяти, доступная Pod'у при повышении активности, ограничена некоторой разумной величиной. + +## Очистка + +Удалим пространство имён. Эта операция удалит все Pod'ы, созданные в рамках данного упражнения: + +```shell +kubectl delete namespace mem-example +``` + +## {{% heading "whatsnext" %}} + + +### Для разработчиков приложений + +* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/) + +* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/) + +### Для администраторов кластера + +* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/) + +* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/) + +* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/) + +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) + +* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) + +* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/) + +* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) \ No newline at end of file diff --git a/content/ru/examples/pods/resource/cpu-request-limit-2.yaml b/content/ru/examples/pods/resource/cpu-request-limit-2.yaml new file mode 100644 index 0000000000..f505c77fbb --- /dev/null +++ b/content/ru/examples/pods/resource/cpu-request-limit-2.yaml @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: Pod +metadata: + name: cpu-demo-2 + namespace: cpu-example +spec: + containers: + - name: cpu-demo-ctr-2 + image: vish/stress + resources: + limits: + cpu: "100" + requests: + cpu: "100" + args: + - -cpus + - "2" diff --git a/content/ru/examples/pods/resource/cpu-request-limit.yaml b/content/ru/examples/pods/resource/cpu-request-limit.yaml new file mode 100644 index 0000000000..2cc0b2cf4f --- /dev/null +++ b/content/ru/examples/pods/resource/cpu-request-limit.yaml @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: Pod +metadata: + name: cpu-demo + namespace: cpu-example +spec: + containers: + - name: cpu-demo-ctr + image: vish/stress + resources: + limits: + cpu: "1" + requests: + cpu: "0.5" + args: + - -cpus + - "2" diff --git a/content/ru/examples/pods/resource/memory-request-limit-2.yaml b/content/ru/examples/pods/resource/memory-request-limit-2.yaml new file mode 100644 index 0000000000..99032c4fc2 --- /dev/null +++ b/content/ru/examples/pods/resource/memory-request-limit-2.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: Pod +metadata: + name: memory-demo-2 + namespace: mem-example +spec: + containers: + - name: memory-demo-2-ctr + image: polinux/stress + resources: + requests: + memory: "50Mi" + limits: + memory: "100Mi" + command: ["stress"] + args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"] diff --git a/content/ru/examples/pods/resource/memory-request-limit-3.yaml b/content/ru/examples/pods/resource/memory-request-limit-3.yaml new file mode 100644 index 0000000000..9f089c4a7a --- /dev/null +++ b/content/ru/examples/pods/resource/memory-request-limit-3.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: Pod +metadata: + name: memory-demo-3 + namespace: mem-example +spec: + containers: + - name: memory-demo-3-ctr + image: polinux/stress + resources: + limits: + memory: "1000Gi" + requests: + memory: "1000Gi" + command: ["stress"] + args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"] diff --git a/content/ru/examples/pods/resource/memory-request-limit.yaml b/content/ru/examples/pods/resource/memory-request-limit.yaml new file mode 100644 index 0000000000..985b1308d9 --- /dev/null +++ b/content/ru/examples/pods/resource/memory-request-limit.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: Pod +metadata: + name: memory-demo + namespace: mem-example +spec: + containers: + - name: memory-demo-ctr + image: polinux/stress + resources: + limits: + memory: "200Mi" + requests: + memory: "100Mi" + command: ["stress"] + args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"] diff --git a/content/zh/docs/concepts/architecture/controller.md b/content/zh/docs/concepts/architecture/controller.md index 2d2b4e4317..445f5bdd3d 100644 --- a/content/zh/docs/concepts/architecture/controller.md +++ b/content/zh/docs/concepts/architecture/controller.md @@ -17,7 +17,7 @@ about your *desired state*. The actual room temperature is the closer to the desired state, by turning equipment on or off. --> -在机器人技术和自动化中，控制环是一个控制系统状态的不终止的循环。 +在机器人技术和自动化中，控制回路是一个非终止回路，用于调节系统状态。 这是一个控制环的例子：房间里的温度自动调节器。 diff --git a/content/zh/docs/concepts/architecture/nodes.md b/content/zh/docs/concepts/architecture/nodes.md index 4ad6f81c64..143df96209 100644 --- a/content/zh/docs/concepts/architecture/nodes.md +++ b/content/zh/docs/concepts/architecture/nodes.md @@ -4,14 +4,12 @@ content_type: concept weight: 10 --- @@ -26,18 +24,11 @@ architecture design doc for more details. --> 在 Kubernetes 中，节点（Node）是执行工作的机器，以前叫做 `minion`。根据你的集群环境，节点可以是一个虚拟机或者物理机器。每个节点都包含用于运行 [pods](/docs/concepts/workloads/pods/pod/) 的必要服务，并由主控组件管理。节点上的服务包括 [容器运行时](/docs/concepts/overview/components/#node-components)、kubelet 和 kube-proxy。查阅架构设计文档中 [Kubernetes 节点](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) 一节获取更多细节。 - - - - -## 节点状态 - + +## 节点状态 + 一个节点的状态包含以下信息: * [地址](#addresses) @@ -52,11 +46,11 @@ A node's status contains the following information: * [容量与可分配](#capacity) * [信息](#info) - 可以使用以下命令显示节点状态和有关节点的其他详细信息： + ```shell kubectl describe node ``` @@ -67,32 +61,29 @@ Each section is described in detail below. ### 地址 - 这些字段组合的用法取决于你的云服务商或者裸机配置。 -* HostName：由节点的内核指定。可以通过 kubelet 的 `--hostname-override` 参数覆盖。 -* ExternalIP：通常是可以外部路由的节点 IP 地址（从集群外可访问）。 -* InternalIP：通常是仅可在集群内部路由的节点 IP 地址。 - +* HostName：由节点的内核设置。可以通过 kubelet 的 `--hostname-override` 参数覆盖。 +* ExternalIP：通常是节点的可以外部路由（从集群外可访问）的 IP 地址。 +* InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。 ### 条件 {#condition} - `conditions` 字段描述了所有 `Running` 节点的状态。条件的示例包括： -| 节点条件 | 描述 | +| 节点条件 | 描述 | |----------------|-------------| -| `OutOfDisk` | `True` 表示节点的空闲空间不足以用于添加新 pods, 否则为 `False` | -| `Ready` | 表示节点是健康的并已经准备好接受 pods；`False` 表示节点不健康而且不能接受 pods；`Unknown` 表示节点控制器在最近 40 秒内没有收到节点的消息 | -| `MemoryPressure` | `True` 表示节点存在内存压力 -- 即节点内存用量低，否则为 `False` | -| `PIDPressure` | `True` 表示节点存在进程压力 -- 即进程过多；否则为 `False` | -| `DiskPressure` | `True` 表示节点存在磁盘压力 -- 即磁盘可用量低，否则为 `False` | -| `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` | +| `OutOfDisk` | `True` 表示节点的空闲空间不足以用于添加新 Pods, 否则为 `False` | +| `Ready` | 表示节点是健康的并已经准备好接收 Pods；`False` 表示节点不健康而且不能接收 Pods；`Unknown` 表示节点控制器在最近 `node-monitor-grace-period` 期间（默认 40 秒）没有收到节点的消息 | +| `MemoryPressure` | `True` 表示节点存在内存压力，即节点内存可用量低，否则为 `False` | +| `PIDPressure` | `True` 表示节点存在进程压力，即进程过多；否则为 `False` | +| `DiskPressure` | `True` 表示节点存在磁盘压力，即磁盘可用量低，否则为 `False` | +| `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` | -节点条件使用一个 JSON 对象表示。例如，下面的响应描述了一个健康的节点。 +节点条件使用 JSON 对象表示。例如，下面的响应描述了一个健康的节点。 ```json "conditions": [ @@ -135,8 +126,12 @@ The node condition is represented as a JSON object. For example, the following r -如果 Ready 条件处于状态 `Unknown` 或者 `False` 的时间超过了 `pod-eviction-timeout`（一个传递给 [kube-controller-manager](/docs/admin/kube-controller-manager/) 的参数），节点上的所有 Pods 都会被节点控制器计划删除。默认的删除超时时长为**5 分钟**。某些情况下，当节点不可访问时，apiserver 不能和其上的 kubelet 通信。删除 pods 的决定不能传达给 kubelet，直到它重新建立和 apiserver 的连接为止。与此同时，被计划删除的 pods 可能会继续在分区节点上运行。 - +如果 Ready 条件处于状态 `Unknown` 或者 `False` 的时间超过了 `pod-eviction-timeout` +（一个传递给 [kube-controller-manager](/docs/admin/kube-controller-manager/) 的参数）， +节点上的所有 Pods 都会被节点控制器计划删除。默认的逐出超时时长为 **5 分钟**。 +某些情况下，当节点不可访问时，apiserver 不能和其上的 kubelet 通信。 +删除 Pods 的决定不能传达给 kubelet，直到它重新建立和 apiserver 的连接为止。 +与此同时，被计划删除的 Pods 可能会继续在游离的节点上运行。 -在 1.5 版本之前的 Kubernetes 里，节点控制器会将不能访问的 pods 从 apiserver 中[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)。但在 1.5 或更高的版本里，在节点控制器确认这些 pods 已经在集群停止运行前不会强制删除它们。你可以看到这些处于 `Terminating` 或者 `Unknown` 状态的 pods 可能在无法访问的节点上运行。为了防止 kubernetes 不能从底层基础设施中推断出一个节点是否已经永久的离开了集群，集群管理员可能需要手动删除这个节点对象。从 Kubernetes 删除节点对象将导致 apiserver 删除节点上所有运行的 Pod 对象并释放它们的名字。 - +在 1.5 版本之前的 Kubernetes 上，节点控制器会将不能访问的 Pods 从 apiserver 中 +[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)。 +但在 1.5 或更高的版本里，在节点控制器确认这些 Pods 在集群中已经停止运行前，不会强制删除它们。 +你可以看到这些可能在无法访问的节点上运行的 Pods 处于 `Terminating` 或者 `Unknown` 状态。 +如果 kubernetes 不能基于下层基础设施推断出某节点是否已经永久离开了集群，集群管理员可能需要手动删除该节点对象。 +从 Kubernetes 删除节点对象将导致 apiserver 删除节点上所有运行的 Pod 对象并释放它们的名字。 节点生命周期控制器会自动创建代表条件的[污点](/docs/concepts/configuration/taint-and-toleration/)。 -当调度器将 Pod 分配给节点时，调度器会考虑节点上的污点，但是 Pod 可以容忍的污点除外。 +当调度器将 Pod 指派给某节点时，调度器会考虑节点上的污点，但是 Pod 可以容忍的污点除外。 -### 容量与可分配 {#capacity} - -描述节点上的可用资源：CPU、内存和可以调度到节点上的 pods 的最大数量。 +### 容量与可分配 {#capacity} + +描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pods 的个数上限。 -可以在学习如何在节点上[保留计算资源](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)的同时阅读有关容量和可分配资源的更多信息。 +可以在学习如何在节点上[保留计算资源](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +的同时阅读有关容量和可分配资源的更多信息。 -### 信息 - -关于节点的通用信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、Docker 版本（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。 + +### 信息 {#info} + +关于节点的通用信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、Docker 版本 +（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。 -## 管理 - -与 [pods](/docs/concepts/workloads/pods/pod/) 和 [services](/docs/concepts/services-networking/service/) 不同，节点并不是在 Kubernetes 内部创建的：它是被外部的云服务商创建，例如 Google Compute Engine 或者你的集群中的物理或者虚拟机。这意味着当 Kubernetes 创建一个节点时，它其实仅仅创建了一个对象来代表这个节点。创建以后，Kubernetes 将检查这个节点是否可用。例如，如果你尝试使用如下内容创建一个节点： +## 管理 +与 [Pods](/docs/concepts/workloads/pods/pod/) 和 [Services](/docs/concepts/services-networking/service/) 不同， +节点并不是在 Kubernetes 中从头创建的：它们由外部的云服务商（例如 Google Compute Engine）创建，或者是来自你的资源池 +中的物理机或者虚拟机。 +这意味着当 Kubernetes 创建一个节点时，它其实仅仅创建了一个对象来代表这个节点。 +创建以后，Kubernetes 将检查这个节点是否可用。例如，如果你尝试使用如下内容创建一个节点： ```json { @@ -229,12 +231,19 @@ validates the node by health checking based on the `metadata.name` field. If the services are running -- it is eligible to run a pod. Otherwise, it is ignored for any cluster activity until it becomes valid. --> -Kubernetes 会在内部创一个 Node 对象（用以表示节点），并基于 `metadata.name` 字段执行健康检查，对节点进行验证。如果节点可用，意即所有必要服务都已运行，它就符合了运行一个 pod 的条件；否则它将被所有的集群动作忽略直到变为可用。 +Kubernetes 会在内部创一个 Node 对象（用以表示节点），并基于 `metadata.name` 字段执行健康检查， +如果节点合法，即所有必要服务都处于运行状态，它就有资格运行 Pod；否则它将被所有的集群活动忽略直到其变为合法为止。 + + {{< note >}} - Kubernetes 保留无效节点的对象，并继续检查它是否有效。必须显式删除 Node 对象以停止此过程。 +Kubernetes 保留无效节点所对应的对象，并持续检查它是否合法。 +若要停止这种检查，必须显式删除 Node 对象。 {{< /note >}} -### 节点控制器 - -节点控制器是一个 Kubernetes master 组件，管理节点的方方面面。 - -节点控制器在节点的生命周期中扮演了多个角色。第一个是当节点注册时为它分配一个 CIDR block（如果打开了 CIDR 分配）。 +### 节点控制器 + +节点控制器是一个 Kubernetes 控制面组件，管理节点的方方面面。 + +节点控制器在节点的生命周期中扮演多个角色。第一个是当节点注册时为它分配一个 CIDR 区间（如果启用了 CIDR 分配）。 -第二个是使用云服务商提供了可用节点列表保持节点控制器内部的节点列表更新。如果在云环境下运行，任何时候当一个节点不健康时节点控制器将询问云服务节点的虚拟机是否可用。如果不可用，节点控制器会将这个节点从它的节点列表删除。 +第二个保持节点控制器内部的节点列表与云服务商所提供的可用机器列表同步。 +如果在云环境下运行，当某节点不健康时，节点控制器将询问云服务是否节点的虚拟机可用。 +如果不可用，节点控制器会将该节点从它的节点列表删除。 -第三个是监控节点的健康情况。节点控制器负责在节点不能访问时（也即是节点控制器因为某些原因没有收到心跳，例如节点宕机）将它的 NodeStatus 的 NodeReady 状态更新为 ConditionUnknown。后续如果节点持续不可访问，节点控制器将删除节点上的所有 pods（使用优雅终止）。（默认情况下 40s 开始报告 ConditionUnknown，在那之后 5m 开始删除 pods。）节点控制器每隔 `--node-monitor-period` 秒检查每个节点的状态。 +第三个是监控节点的健康情况。节点控制器负责在节点不可达 +（即，节点控制器因为某些原因没有收到心跳，例如节点宕机）时， +将它的 NodeStatus 的 NodeReady 条件更新为 ConditionUnknown。 +后续如果节点持续不可达，节点控制器将逐出节点上的所有 Pods（使用体面终止）。 +（默认情况下 40s 后开始报告 ConditionUnknown，在那之后 5m 开始逐出 Pods。） +节点控制器每隔 `--node-monitor-period` 秒检查每个节点的状态。 -#### 心跳机制 - +#### 心跳机制 + Kubernetes 节点发送的心跳有助于确定节点的可用性。 心跳有两种形式：`NodeStatus` 和 [`Lease` 对象](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io)。 每个节点在 `kube-node-lease`{{< glossary_tooltip term_id="namespace" text="命名空间">}} 中都有一个关联的 `Lease` 对象。 @@ -316,57 +329,69 @@ kubelet 负责创建和更新 `NodeStatus` 和 `Lease` 对象。 `NodeStatus` updates. --> - 当状态发生变化时，或者在配置的时间间隔内没有更新时，kubelet 会更新 `NodeStatus`。 -`NodeStatus` 更新的默认间隔为 5 分钟（比无法访问的节点的 40 秒默认超时时间长很多）。 + `NodeStatus` 更新的默认间隔为 5 分钟（比不可达节点的 40 秒默认超时时间长很多）。 - kubelet 会每 10 秒（默认更新间隔时间）创建并更新其 `Lease` 对象。`Lease` 更新独立于 `NodeStatus` 更新而发生。 -#### 可靠性 - -在 Kubernetes 1.4 中我们更新了节点控制器逻辑以更好地处理大批量节点访问 master 出问题的情况（例如 master 的网络出了问题）。从 1.4 开始，节点控制器在决定删除 pod 之前会检查集群中所有节点的状态。 +#### 可靠性 + +在 Kubernetes 1.4 中我们更新了节点控制器逻辑以更好地处理大批量节点访问控制面而出问题的情况 +（例如，控制面节点的网络出了问题）。从 1.4 开始，节点控制器在决定逐出 Pod 之前 +会检查集群中所有节点的状态。 -大部分情况下，节点控制器把驱逐频率限制在每秒 `--node-eviction-rate` 个（默认为 0.1）。这表示它每 10 秒钟内至多从一个节点驱逐 Pods。 + +大部分情况下，节点控制器把驱逐速率限制在每秒 `--node-eviction-rate` 个（默认为 0.1）。 +这表示它每 10 秒钟内至多从一个节点驱逐 Pods。 -当一个可用区域中的节点变为不健康时，它的驱逐行为将发生改变。节点控制器会同时检查可用区域中不健康（NodeReady 状态为 ConditionUnknown 或 ConditionFalse）的节点的百分比。如果不健康节点的部分超过 `--unhealthy-zone-threshold` （默认为 0.55），驱逐速率将会减小：如果集群较小（意即小于等于 `--large-cluster-size-threshold` 个 节点 - 默认为 50），驱逐操作将会停止，否则驱逐速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。在单个可用区域实施这些策略的原因是当一个可用区域可能从 master 分区时其它的仍然保持连接。如果你的集群没有跨越云服务商的多个可用区域，那就只有一个可用区域整个集群）。 +当一个可用区域（Availability Zone）中的节点变为不健康时，节点的驱逐行为将发生改变。 +节点控制器会同时检查可用区域中不健康（NodeReady 状态为 ConditionUnknown 或 ConditionFalse） +的节点的百分比。如果不健康节点的比例超过 `--unhealthy-zone-threshold` （默认为 0.55）， +驱逐速率将会降低：如果集群较小（意即小于等于 `--large-cluster-size-threshold` 个节点 - 默认为 50）， +驱逐操作将会停止，否则驱逐速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。 +在单个可用区域实施这些策略的原因是当一个可用区域可能从控制面脱离时其它可用区域可能仍然保持连接。 +如果你的集群没有跨越云服务商的多个可用区域，那（整个集群）就只有一个可用区域。 -在多个可用区域分布你的节点的一个关键原因是当整个可用区域故障时，工作负载可以转移到健康的可用区域。因此，如果一个可用区域中的所有节点都不健康时，节点控制器会以正常的速率 `--node-eviction-rate` 进行驱逐操作。在所有的可用区域都不健康（也即集群中没有健康节点）的极端情况下，节点控制器将假设 master 的连接出了某些问题，它将停止所有驱逐动作直到一些连接恢复。 +跨多个可用区域部署你的节点的一个关键原因是当某个可用区域整体出现故障时，工作负载可以转移到健康的可用区域。 +因此，如果一个可用区域中的所有节点都不健康时，节点控制器会以正常的速率 `--node-eviction-rate` 进行驱逐操作。 +在所有的可用区域都不健康（也即集群中没有健康节点）的极端情况下，节点控制器将假设控制面节点的连接出了某些问题， +它将停止所有驱逐动作直到一些连接恢复。 -从 Kubernetes 1.6 开始，NodeController 还负责驱逐运行在拥有 `NoExecute` 污点的节点上的 pods，如果这些 pods 没有容忍这些污点。此外，作为一个默认禁用的 alpha 特性，NodeController 还负责根据节点故障（例如节点不可访问或没有 ready）添加污点。请查看[这个文档](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)了解关于 `NoExecute` 污点和这个 alpha 特性。 - +从 Kubernetes 1.6 开始，NodeController 还负责驱逐运行在拥有 `NoExecute` 污点的节点上的 Pods，如果这些 Pods 没有容忍这些污点。 +此外，作为一个默认禁用的 alpha 特性，NodeController 还负责根据节点故障（例如节点不可访问或没有就绪）为其添加污点。 +请查看[这个文档](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)了解 `NoExecute` 污点 +和这个 alpha 特性。 ### 节点自注册 - -当 kubelet 标志 `--register-node` 为 true （默认）时，它会尝试向 API 服务注册自己。这是首选模式，被绝大多数发行版选用。 +当 kubelet 标志 `--register-node` 为 true （默认）时，它会尝试向 API 服务注册自己。 +这是首选模式，被绝大多数发行版选用。 - 对于自注册模式，kubelet 使用下列参数启动： +对于自注册模式，kubelet 使用下列参数启动： - - `--kubeconfig` - 用于向 apiserver 验证自己的凭据路径。 + - `--kubeconfig` - 用于向 apiserver 表明身份的凭据路径。 - `--cloud-provider` - 如何从云服务商读取关于自己的元数据。 - `--register-node` - 自动向 API 服务注册。 - - `--register-with-taints` - 使用 taints 列表（逗号分隔的 `=:`）注册节点。当 `register-node` 为 false 时无效。 + - `--register-with-taints` - 使用污点列表（逗号分隔的 `=:`）注册节点。当 `register-node` 为 false 时无效。 - `--node-ip` - 节点 IP 地址。 - - `--node-labels` - 在集群中注册节点时要添加的标签（请参阅 [NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) 在 1.13+ 中实施的标签限制）。 - - `--node-status-update-frequency` - 指定 kubelet 向 master 发送状态的频率。 + - `--node-labels` - 在集群中注册节点时要添加的标签（请参阅 + [NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) 在 1.13+ 中实施的标签限制）。 + - `--node-status-update-frequency` - 指定 kubelet 向控制面组件发送状态的频率。 -启用[节点授权模式](/docs/reference/access-authn-authz/node/) 和 [NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时，仅授权小组件创建或修改其自己的节点资源。 +启用[节点授权模式](/docs/reference/access-authn-authz/node/) 和 +[NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时， +仅授权 kubelet 创建或修改其自己的节点资源。 #### 手动节点管理 - 集群管理员可以创建及修改节点对象。 -如果管理员希望手动创建节点对象，请设置 kubelet 标记 `--register-node=false`。 +如果管理员希望手动创建节点对象，请设置 kubelet 标志 `--register-node=false`。 -管理员可以修改节点资源（忽略 `--register-node` 设置）。修改包括在节点上设置 labels 及标记它为不可调度。 +管理员可以修改节点资源（忽略 `--register-node` 设置）。修改包括在节点上设置标签及 +标记它为不可调度。 -节点上的 labels 可以和 pods 的节点 selectors 一起使用来控制调度，例如限制一个 pod 只能在一个符合要求的节点子集上运行。 +节点上的标签可以和 Pods 的节点选择算符一起使用来控制调度，例如限制某 pod 只能在符合要求的节点子集上运行。 -标记一个节点为不可调度的将防止新建 pods 调度到那个节点之上，但不会影响任何已经在它之上的 pods。这是重启节点等操作之前的一个有用的准备步骤。例如，标记一个节点为不可调度的，执行以下命令： - +如果标记节点为不可调度的（unschedulable），将阻止新 Pods 调度到该节点之上，但不会影响任何已经在其上的 Pods。 +这是重启节点等操作之前的一个有用的准备步骤。例如，要标记一个节点为不可调度的，执行以下命令： ```shell kubectl cordon $NODENAME ``` -{{< note >}} -请注意，被 daemonSet 控制器创建的 pods 将忽略 Kubernetes 调度器，且不会遵照节点上不可调度的属性。这个假设基于守护程序属于节点机器，即使在准备重启而隔离应用的时候。 + +{{< note >}} +请注意，被 DaemonSet 控制器创建的 Pods 将忽略 Kubernetes 调度器，且不会遵照节点上不可调度的属性。 +这个假设基于守护程序属于节点机器，即使在准备重启而隔离应用的时候。 {{< /note >}} -### 节点容量 - -节点的容量（cpu 数量和内存容量）是节点对象的一部分。通常情况下，在创建节点对象时，它们会注册自己并报告自己的容量。如果你正在执行[手动节点管理](#manual-node-administration)，那么你需要在添加节点时手动设置节点容量。 +### 节点容量 + +节点的容量（cpu 数量和内存容量）是节点对象的一部分。 +通常情况下，在创建节点对象时，它们会注册自己并报告自己的容量。 +如果你正在执行[手动节点管理](#manual-node-administration)，那么你需要在添加节点时手动设置节点容量。 -Kubernetes 调度器保证一个节点上有足够的资源供其上的所有 pods 使用。它会检查节点上所有容器要求的总和不会超过节点的容量。这包括由 kubelet 启动的所有容器，但不包括由 [container runtime](/docs/concepts/overview/components/#node-components) 直接启动的容器，也不包括在容器外部运行的任何进程。 +Kubernetes 调度器保证一个节点上有足够的资源供其上的所有 Pods 使用。 +它会检查节点上所有容器的请求的总和不会超过节点的容量。 +这包括由 kubelet 启动的所有容器，但不包括由[容器运行时](/docs/concepts/overview/components/#node-components) +直接启动的容器，也不包括在容器外部运行的任何进程。 -如果要为非 Pod 进程显式保留资源。请按照本教程[为系统守护程序保留资源](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。 +如果要为非 Pod 进程显式保留资源。请参考[为系统守护程序保留资源](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)教程。 -如果启用了 `TopologyManager` [功能开关](/docs/reference/command-line-tools-reference/feature-gates/)，则 kubelet 可以在做出资源分配决策时使用拓扑提示。 +如果启用了 `TopologyManager` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)， +则 kubelet 可以在做出资源分配决策时使用拓扑提示。 -## API 对象 - -节点是 Kubernetes REST API 的顶级资源。更多关于 API 对象的细节可以在这里找到：[节点 API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)。 +## API 对象 +节点是 Kubernetes REST API 的顶级资源。 +更多关于 API 对象的细节可以在这里找到：[节点 API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)。 ## {{% heading "whatsnext" %}} @@ -534,6 +570,6 @@ API object can be found at: * Read about [node components](https://kubernetes.io/docs/concepts/overview/components/#node-components) * Read about node-level topology: [Control Topology Management Policies on a node](/docs/tasks/administer-cluster/topology-manager/) --> -* 了解有关[节点组件](https://kubernetes.io/docs/concepts/overview/components/#node-components)的信息。 +* 了解有关[节点组件](/docs/concepts/overview/components/#node-components)的信息。 * 阅读有关节点级拓扑的信息：[控制节点上的拓扑管理策略](/docs/tasks/administer-cluster/topology-manager/)。 diff --git a/content/zh/docs/concepts/cluster-administration/addons.md b/content/zh/docs/concepts/cluster-administration/addons.md index 10eb8adb08..cb9a93121f 100644 --- a/content/zh/docs/concepts/cluster-administration/addons.md +++ b/content/zh/docs/concepts/cluster-administration/addons.md @@ -94,7 +94,7 @@ Add-ons 扩展了 Kubernetes 的功能。 ## 基础设施 -* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) 是可以让 Kubernetes 运行虚拟机的 add-ons。通常运行在裸机群集上。 +* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) 是可以让 Kubernetes 运行虚拟机的 add-ons。通常运行在裸机集群上。 * 在容器中运行的 kube-scheduler 和 kube-proxy。 -* 不在容器中运行的 kubelet 和容器运行时（例如 Docker。 +* 不在容器中运行的 kubelet 和容器运行时（例如 Docker）。 -{{< glossary_definition term_id="configmap" prepend="ConfigMap 是" length="all" >}} +{{< glossary_definition term_id="configmap" length="all" >}} {{< caution >}} - - - - -当您定义 [Pod](/docs/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存（RAM）大小。当为容器指定了资源请求后，调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制，Kubernetes 就可以按照指定的方式来处理节点上的资源竞争。关于资源请求和限制的不同点和更多资料请参考 [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md)。 - - - - - - - - -## 资源类型 - -*CPU* 和*内存*都是*资源类型*。资源类型具有基本单位。CPU 的单位是核心数，内存的单位是字节。 - -如果您使用的是 Kubernetes v1.14 或更高版本，则可以指定巨页资源。巨页是 Linux 特有的功能，节点内核在其中分配的内存块比默认页大小大得多。 - -例如，在默认页面大小为 4KiB 的系统上，您可以指定一个限制，`hugepages-2Mi: 80Mi`。如果容器尝试分配 40 个 2MiB 大页面（总共 80 MiB ），则分配失败。 - -{{< note >}} -您不能过量使用`hugepages- *`资源。 -这与`memory`和`cpu`资源不同。 -{{< /note >}} - -CPU和内存统称为*计算资源*，也可以称为*资源*。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/concepts/overview/kubernetes-api/) 不同。 API 资源（如 Pod 和 [Service](/docs/concepts/services-networking/service/)）是可通过 Kubernetes API server 读取和修改的对象。 - - - -## Pod 和 容器的资源请求和限制 - -Pod 中的每个容器都可以指定以下的一个或者多个值： - -- `spec.containers[].resources.limits.cpu` -- `spec.containers[].resources.limits.memory` -- `spec.containers[].resources.requests.cpu` -- `spec.containers[].resources.requests.memory` - -尽管只能在个别容器上指定请求和限制，但是我们可以方便地计算出 Pod 资源请求和限制。特定资源类型的Pod 资源请求/限制是 Pod 中每个容器的该类型的资源请求/限制的总和。 - - - -## CPU 的含义 - -CPU 资源的限制和请求以 *cpu* 为单位。 - -Kubernetes 中的一个 cpu 等于： - -- 1 AWS vCPU -- 1 GCP Core -- 1 Azure vCore -- 1 *Hyperthread* 在带有超线程的裸机 Intel 处理器上 - -允许浮点数请求。具有 `spec.containers[].resources.requests.cpu` 为 0.5 的容器保证了一半 CPU 要求 1 CPU的一半。表达式 `0.1` 等价于表达式 `100m`，可以看作 “100 millicpu”。有些人说成是“一百毫 cpu”，其实说的是同样的事情。具有小数点（如 `0.1`）的请求由 API 转换为`100m`，精度不超过 `1m`。因此，可能会优先选择 `100m` 的形式。 - -CPU 总是要用绝对数量，不可以使用相对数量；0.1 的 CPU 在单核、双核、48核的机器中的意义是一样的。 - - - -## 内存的含义 - -内存的限制和请求以字节为单位。您可以使用以下后缀之一作为平均整数或定点整数表示内存：E，P，T，G，M，K。您还可以使用两个字母的等效的幂数：Ei，Pi，Ti ，Gi，Mi，Ki。例如，以下代表大致相同的值： - -```shell -128974848, 129e6, 129M, 123Mi -``` - - - -下面是个例子。 - -以下 Pod 有两个容器。每个容器的请求为 0.25 cpu 和 64MiB（226 字节）内存，每个容器的限制为 0.5 cpu 和 128MiB 内存。您可以说该 Pod 请求 0.5 cpu 和 128 MiB 的内存，限制为 1 cpu 和 256MiB 的内存。 - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: frontend -spec: - containers: - - name: db - image: mysql - env: - - name: MYSQL_ROOT_PASSWORD - value: "password" - resources: - requests: - memory: "64Mi" - cpu: "250m" - limits: - memory: "128Mi" - cpu: "500m" - - name: wp - image: wordpress - resources: - requests: - memory: "64Mi" - cpu: "250m" - limits: - memory: "128Mi" - cpu: "500m" -``` - - - -## 具有资源请求的 Pod 如何调度 - -当您创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。每个节点具有每种资源类型的最大容量：可为 Pod 提供的 CPU 和内存量。调度程序确保对于每种资源类型，调度的容器的资源请求的总和小于节点的容量。请注意，尽管节点上的实际内存或 CPU 资源使用量非常低，但如果容量检查失败，则调度程序仍然拒绝在该节点上放置 Pod。当资源使用量稍后增加时，例如在请求率的每日峰值期间，这可以防止节点上的资源短缺。 - - - -## 具有资源限制的 Pod 如何运行 - -当 kubelet 启动一个 Pod 的容器时，它会将 CPU 和内存限制传递到容器运行时。 - -当使用 Docker 时： - - - -- `spec.containers[].resources.requests.cpu` 先被转换为可能是小数的 core 值，再乘以 1024，这个数字和 2 的较大者用作 `docker run` 命令中的[ `--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) 标志的值。 - -- `spec.containers[].resources.limits.cpu` 先被转换为 millicore 值，再乘以 100，结果就是每 100ms 内 container 可以使用的 CPU 总时间。在此时间间隔（100ms）内，一个 container 使用的 CPU 时间不会超过它被分配的时间。 - - - - {{< note >}} - 默认的配额（quota）周期为 100 毫秒。 CPU配额的最小精度为 1 毫秒。 - {{}} - - - -- `spec.containers[].resources.limits.memory` 被转换为整型，作为 `docker run` 命令中的 [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) 标志的值。 - - - -如果容器超过其内存限制，则可能会被终止。如果可重新启动，则与所有其他类型的运行时故障一样，kubelet 将重新启动它。 - -如果一个容器超过其内存请求，那么当节点内存不足时，它的 Pod 可能被逐出。 - -容器可能被允许也可能不被允许超过其 CPU 限制时间。但是，由于 CPU 使用率过高，不会被杀死。 - -要确定容器是否由于资源限制而无法安排或被杀死，请参阅[疑难解答](#troubleshooting) 部分。 - - - -## 监控计算资源使用 - -Pod 的资源使用情况被报告为 Pod 状态的一部分。 - -如果为集群配置了可选 [监控工具](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)，则可以直接从 -[指标 API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api) 或者监控工具检索 Pod 资源的使用情况。 - - - -## 疑难解答 - -### 我的 Pod 处于 pending 状态且事件信息显示 failedScheduling - -如果调度器找不到任何该 Pod 可以匹配的节点，则该 Pod 将保持不可调度状态，直到找到一个可以被调度到的位置。每当调度器找不到 Pod 可以调度的地方时，会产生一个事件，如下所示： - -```shell -kubectl describe pod frontend | grep -A 3 Events -``` -``` -Events: - FirstSeen LastSeen Count From Subobject PathReason Message - 36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others -``` - - - -在上述示例中，由于节点上的 CPU 资源不足，名为 “frontend” 的 Pod 将无法调度。由于内存不足（PodExceedsFreeMemory），类似的错误消息也可能会导致失败。一般来说，如果有这种类型的消息而处于 pending 状态，您可以尝试如下几件事情： - -- 向集群添加更多节点。 -- 终止不需要的 Pod，为待处理的 Pod 腾出空间。 -- 检查 Pod 所需的资源是否大于所有节点的资源。 例如，如果全部节点的容量为`cpu：1`，那么一个请求为 `cpu：1.1`的 Pod 永远不会被调度。 - -您可以使用 `kubectl describe nodes` 命令检查节点容量和分配的数量。 例如： - - -```shell -kubectl describe nodes e2e-test-node-pool-4lw4 -``` -``` -Name: e2e-test-node-pool-4lw4 -[ ... lines removed for clarity ...] -Capacity: - cpu: 2 - memory: 7679792Ki - pods: 110 -Allocatable: - cpu: 1800m - memory: 7474992Ki - pods: 110 -[ ... lines removed for clarity ...] -Non-terminated Pods: (5 in total) - Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits - --------- ---- ------------ ---------- --------------- ------------- - kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%) - kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%) - kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%) - kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%) - kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%) -Allocated resources: - (Total limits may be over 100 percent, i.e., overcommitted.) - CPU Requests CPU Limits Memory Requests Memory Limits - ------------ ---------- --------------- ------------- - 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) -``` - - - -在上面的输出中，您可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存，节点将无法满足。 - -通过查看 `Pods` 部分，您将看到哪些 Pod 占用的节点上的资源。 - -Pod 可用的资源量小于节点容量，因为系统守护程序使用一部分可用资源。 -[NodeStatus](/docs/resources-reference/{{< param "version" >}}/#nodestatus-v1-core) 的 `allocatable` 字段给出了可用于 Pod 的资源量。 -有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。 - -可以将 [资源配额](/docs/concepts/policy/resource-quotas/) 功能配置为限制可以使用的资源总量。如果与 namespace 配合一起使用，就可以防止一个团队占用所有资源。 - - - -## 我的容器被终止了 - -您的容器可能因为资源枯竭而被终止了。要查看容器是否因为遇到资源限制而被杀死，请在相关的 Pod 上调用 `kubectl describe pod`： - -```shell -kubectl describe pod simmemleak-hra99 -``` -``` -Name: simmemleak-hra99 -Namespace: default -Image(s): saadali/simmemleak -Node: kubernetes-node-tf0f/10.240.216.66 -Labels: name=simmemleak -Status: Running -Reason: -Message: -IP: 10.244.2.75 -Replication Controllers: simmemleak (1/1 replicas created) -Containers: - simmemleak: - Image: saadali/simmemleak - Limits: - cpu: 100m - memory: 50Mi - State: Running - Started: Tue, 07 Jul 2015 12:54:41 -0700 - Last Termination State: Terminated - Exit Code: 1 - Started: Fri, 07 Jul 2015 12:54:30 -0700 - Finished: Fri, 07 Jul 2015 12:54:33 -0700 - Ready: False - Restart Count: 5 -Conditions: - Type Status - Ready False -Events: - FirstSeen LastSeen Count From SubobjectPath Reason Message - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a -``` - - - -在上面的例子中，`Restart Count: 5` 意味着 Pod 中的 `simmemleak` 容器被终止并重启了五次。 - -您可以使用 `kubectl get pod` 命令加上 `-o go-template=...` 选项来获取之前终止容器的状态。 - - -```shell -kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99 -``` -``` -Container Name: simmemleak -LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]] -``` - - - -您可以看到容器因为 `reason:OOM killed` 被终止，`OOM` 表示 Out Of Memory。 - - - -## 本地临时存储 - -Kubernetes版本1.8引入了新资源_ephemeral-storage_，用于管理本地临时存储。 -在每个Kubernetes节点中，kubelet的根目录（默认为 /var/lib/kubelet）和日志目录（ /var/log ）存储在节点的根分区上。 -Pods还通过emptyDir卷，容器日志，镜像层和容器可写层共享和使用此分区。 - -该分区是“临时”分区，应用程序无法从该分区获得任何性能SLA（例如磁盘IOPS）。 本地临时存储管理仅适用于根分区。 图像层和可写层的可选分区超出范围。 - -{{< note >}} -如果使用可选的运行时分区，则根分区将不保存任何镜像层或可写层。 -{{< /note >}} - - - -### 本地临时存储的请求和限制设置 -Pod 的每个容器可以指定以下一项或多项： - -* `spec.containers[].resources.limits.ephemeral-storage` -* `spec.containers[].resources.requests.ephemeral-storage` - - - -对“临时存储”的限制和请求以字节为单位。您可以使用以下后缀之一将存储表示为纯整数或小数形式：E，P，T，G，M，K。您还可以使用2的幂次方：Ei，Pi，Ti，Gi，Mi，Ki。例如，以下内容表示的值其实大致相同： - -```shell -128974848, 129e6, 129M, 123Mi -``` - - - -例如，以下Pod具有两个容器。每个容器都有一个2GiB的本地临时存储请求。每个容器的本地临时存储限制为4GiB。因此，该Pod要求本地临时存储空间为4GiB，存储空间限制为8GiB。 - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: frontend -spec: - containers: - - name: db - image: mysql - env: - - name: MYSQL_ROOT_PASSWORD - value: "password" - resources: - requests: - ephemeral-storage: "2Gi" - limits: - ephemeral-storage: "4Gi" - - name: wp - image: wordpress - resources: - requests: - ephemeral-storage: "2Gi" - limits: - ephemeral-storage: "4Gi" -``` - - - -### 如何调度临时存储请求的 Pod - -创建Pod时，Kubernetes调度程序会选择一个节点来运行Pod。每个节点都可以为Pod提供最大数量的本地临时存储。 -有关更多信息，请参见[节点可分配](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)。 - -调度程序会确保调度的容器的资源请求的总和小于节点的容量。 - - - -### 具有临时存储限制的 Pod 如何运行 - -对于容器级隔离，如果容器的可写层和日志使用量超出其存储限制，则将驱逐Pod。对于 pod 级别的隔离，如果来自所有容器的本地临时存储使用量以及 Pod 的 emptyDir 卷的总和超过限制，则将驱逐Pod。 - - - -### 监控临时存储消耗 - -使用本地临时存储时，kubelet 会持续对本地临时存储时进行监视。 -通过定期扫描，来监视每个 emptyDir 卷，日志目录和可写层。 -从Kubernetes 1.15开始，作为集群操作员的一个选项，可以通过[项目配额](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 来管理 emptyDir 卷（但是不包括日志目录或可写层）。 -项目配额最初是在XFS中实现的，最近又被移植到ext4fs中。 项目配额可用于监视和执行； 从Kubernetes 1.15开始，它们可用作Alpha功能仅用于监视。 - - - -配额比目录扫描更快，更准确。 -将目录分配给项目时，在该目录下创建的所有文件都将在该项目中创建，内核仅需跟踪该项目中的文件正在使用多少块。 -如果创建并删除了文件，但是文件描述符已打开，它将继续占用空间。 该空间将由配额跟踪，但目录扫描不会检查。 - - - -Kubernetes使用从1048576开始的项目ID。正在使用的ID注册于 `/etc/projects` 和 `/etc/projid`。 -如果此范围内的项目ID用于系统上的其他目的，则这些项目ID必须在 `/etc/projects` 和 `/etc/projid` 中注册，以防止Kubernetes使用它们。 - - - -要启用项目配额，集群操作员必须执行以下操作： - -* 在kubelet配置中启用 `LocalStorageCapacityIsolationFSQuotaMonitoring = true` 功能。 在Kubernetes 1.15中默认为 false，因此必须显式设置为 true。 - -* 确保根分区（或可选的运行时分区）是在启用项目配额的情况下构建的。 所有 XFS 文件系统都支持项目配额，但是 ext4 文件系统必须专门构建。 - -* 确保在启用了项目配额的情况下挂载了根分区（或可选的运行时分区）。 - - - -#### 在启用项目配额的情况下构建和挂载文件系统 - -XFS文件系统在构建时不需要任何特殊操作; 它们是在启用项目配额的情况下自动构建的。 - -Ext4fs文件系统必须在启用了配额的情况下构建，然后必须在文件系统中启用它们： - -``` -% sudo mkfs.ext4 other_ext4fs_args... -E quotatype=prjquota /dev/block_device -% sudo tune2fs -O project -Q prjquota /dev/block_device - -``` - - - -要挂载文件系统，ext4fs 和 XFS 都需要在 `/etc/fstab` 中设置 `prjquota` 选项： - -``` -/dev/block_device /var/kubernetes_data defaults,prjquota 0 0 -``` - - - - -## 拓展资源 - -拓展资源是 `kubernetes.io` 域名之外的标准资源名称。它们允许集群管理员做分发，而且用户可以使用非Kubernetes内置资源。 -使用扩展资源需要两个步骤。 首先，集群管理员必须分发拓展资源。 其次，用户必须在 Pod 中请求拓展资源。 - -```shell -curl --header "Content-Type: application/json-patch+json" \ ---request PATCH \ ---data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ -http://k8s-master:8080/api/v1/nodes/k8s-node-1/status -``` - - - -### 管理拓展资源 - -#### 节点级拓展资源 - -节点级拓展资源绑定到节点。 - - - -##### 设备插件托管资源 - -有关如何在每个节点上分发设备插件托管资源的信息，请参阅[设备插件](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。 - - - -##### 其他资源 -为了发布新的节点级拓展资源，集群操作员可以向API服务器提交 `PATCH` HTTP 请求， -以在 `status.capacity` 中为集群中的节点指定可用数量。 -完成此操作后，节点的 `status.capacity` 将包含新资源。 -由kubelet异步使用新资源自动更新 `status.allocatable` 字段。 -请注意，由于调度程序在评估Pod适合性时使用节点的状态 `status.allocatable` 值， -因此在用新资源修补节点容量和请求在该节点上调度资源的第一个Pod之间可能会有短暂的延迟。 - - - -**示例:** - -这是一个示例，显示了如何使用 `curl` 进行HTTP请求，该请求在主节点为 `k8s-master` 的子节点 `k8s-node-1` -上通告五个 `example.com/foo` 资源。 - -```shell -curl --header "Content-Type: application/json-patch+json" \ ---request PATCH \ ---data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ -http://k8s-master:8080/api/v1/nodes/k8s-node-1/status -``` - -{{< note >}} - - - -在前面的请求中，`~1` 是 Patch 路径中字符 `/` 的编码。 JSON-Patch中的操作路径值被解释为JSON-Pointer。 -有关更多详细信息，请参见 -[IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3). -{{< /note >}} - - - -#### 集群级扩展资源 - -群集级扩展资源不绑定到节点。 它们通常由调度程序扩展程序管理，这些程序处理资源消耗和资源配额。 - -您可以在[调度程序策略配置](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)中指定由调度程序扩展程序处理的扩展资源。 - - - -**示例:** - -通过调度程序策略的以下配置，指示群集级扩展资源 "example.com/foo" 由调度程序扩展程序处理。 - -- 仅当Pod请求 "example.com/foo" 时，调度程序才会将 Pod 发送到调度程序扩展程序。 -- `ignoredByScheduler` 字段指定调度程序不在其 `PodFitsResources` 字段中检查 "example.com/foo" 资源。 - -```json -{ - "kind": "Policy", - "apiVersion": "v1", - "extenders": [ - { - "urlPrefix":"", - "bindVerb": "bind", - "managedResources": [ - { - "name": "example.com/foo", - "ignoredByScheduler": true - } - ] - } - ] -} -``` - - - -### 消耗扩展资源 - -就像 CPU 和内存一样，用户可以使用 Pod 的扩展资源。 -调度程序负责核算资源，因此不会同时将过多的可用资源分配给 Pod。 - -{{< note >}} - - - -扩展资源取代了 Opaque 整数资源。 用户可以使用保留字 `kubernetes.io` 以外的任何域名前缀。 - -{{< /note >}} - - - -要在Pod中使用扩展资源，请在容器规范的 `spec.containers[].resources.limits` 映射中包含资源名称作为键。 - -{{< note >}} - - - -扩展资源不能过量使用，因此如果容器规范中存在请求和限制，则它们必须一致。 - -{{< /note >}} - - - -仅当满足所有资源请求(包括 CPU ，内存和任何扩展资源)时，才能调度 Pod。 只要资源请求无法满足，则 Pod 保持在 `PENDING` 状态。 - -**示例:** - -下面的 Pod 请求2个 CPU 和1个"example.com/foo"(扩展资源)。 - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: my-pod -spec: - containers: - - name: my-container - image: myimage - resources: - requests: - cpu: 2 - example.com/foo: 1 - limits: - example.com/foo: 1 -``` - - - - -## {{% heading "whatsnext" %}} - - - - -* 获取将 [分配内存资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验 - -* 获取将 [分配 CPU 资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验 - -* [容器](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) - -* [资源需求](/docs/resources-reference/{{< param "version" >}}/#resourcerequirements-v1-core) - - diff --git a/content/zh/docs/concepts/configuration/manage-resources-containers.md b/content/zh/docs/concepts/configuration/manage-resources-containers.md new file mode 100644 index 0000000000..5b7b359848 --- /dev/null +++ b/content/zh/docs/concepts/configuration/manage-resources-containers.md @@ -0,0 +1,1310 @@ +--- +title: 为容器管理资源 +content_type: concept +weight: 40 +feature: + title: 自动装箱 + description: > + 根据资源需求和其他约束自动放置容器，同时避免影响可用性。将关键性工作负载和尽力而为性质的服务工作负载进行混合放置，以提高资源利用率并节省更多资源。 +--- + + + + + + + +当你定义 {{< glossary_tooltip term_id="pod" >}} 时可以选择性地为每个 +{{< glossary_tooltip text="容器" term_id="container" >}}设定所需要的资源数量。 +最常见的可设定资源是 CPU 和内存（RAM）大小；此外还有其他类型的资源。 + +当你为 Pod 中的 Container 指定了资源 __请求__ 时，调度器就利用该信息决定将 Pod 调度到哪个节点上。 +当你还为 Container 指定了资源 __约束__ 时，kubelet 就可以确保运行的容器不会使用超出所设约束的资源。 +kubelet 还会为容器预留所 __请求__ 数量的系统资源，供其使用。 + + + + + +## 请求和约束 + +如果 Pod 运行所在的节点具有足够的可用资源，容器可能（且可以）使用超出对应资源 +`request` 属性所设置的资源量。不过，容器不可以使用超出其资源 `limit` +属性所设置的资源量。 + +例如，如果你将容器的 `memory` 的请求量设置为 256 MiB，而该容器所处的 Pod +被调度到一个具有 8 GiB 内存的节点上，并且该节点上没有其他 Pods +运行，那么该容器就可以尝试使用更多的内存。 + + + +如果你将某容器的 `memory` 约束设置为 4 GiB，kubelet （和 +{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}） +就会确保该约束生效。 +容器运行时会禁止容器使用超出所设置资源约束的资源。 +例如：当容器中进程尝试使用超出所允许内存量的资源时，系统内核会将尝试申请内存的进程终止， +并引发内存不足（OOM）错误。 + +约束值可以以被动方式来实现（系统会在发现违例时进行干预），或者通过强制生效的方式实现 +（系统会避免容器用量超出约束值）。不同的容器运行时采用不同方式来实现相同的限制。 + + + +## 资源类型 + +*CPU* 和*内存*都是*资源类型*。每种资源类型具有其基本单位。 +CPU 表达的是计算处理能力，其单位是 [Kubernetes CPUs](#meaning-of-cpu)。 +内存的单位是字节。 +如果你使用的是 Kubernetes v1.14 或更高版本，则可以指定巨页（Huge Page）资源。 +巨页是 Linux 特有的功能，节点内核在其中分配的内存块比默认页大小大得多。 + +例如，在默认页面大小为 4KiB 的系统上，您可以指定约束 `hugepages-2Mi: 80Mi`。 +如果容器尝试分配 40 个 2MiB 大小的巨页（总共 80 MiB ），则分配请求会失败。 + + + + +{{< note >}} +您不能过量使用 `hugepages- * `资源。 +这与 `memory` 和 `cpu` 资源不同。 +{{< /note >}} + +CPU 和内存统称为*计算资源*，或简称为*资源*。 +计算资源的数量是可测量的，可以被请求、被分配、被消耗。 +它们与 [API 资源](/docs/concepts/overview/kubernetes-api/) 不同。 +API 资源（如 Pod 和 [Service](/docs/concepts/services-networking/service/)）是可通过 +Kubernetes API 服务器读取和修改的对象。 + + + +## Pod 和 容器的资源请求和约束 + +Pod 中的每个容器都可以指定以下的一个或者多个值： + +- `spec.containers[].resources.limits.cpu` +- `spec.containers[].resources.limits.memory` +- `spec.containers[].resources.limits.hugepages-` +- `spec.containers[].resources.requests.cpu` +- `spec.containers[].resources.requests.memory` +- `spec.containers[].resources.requests.hugepages-` + +尽管请求和限制值只能在单个容器上指定，我们仍可方便地计算出 Pod 的资源请求和约束。 +Pod 对特定资源类型的请求/约束值是 Pod 中各容器对该类型资源的请求/约束值的总和。 + + + +## CPU 的含义 {#meaning-of-cpu} + +CPU 资源的约束和请求以 *cpu* 为单位。 + +Kubernetes 中的一个 cpu 等于云平台上的 **1 个 vCPU/核**和裸机 Intel +处理器上的 **1 个超线程 **。 + +你也可以表达带小数 CPU 的请求。`spec.containers[].resources.requests.cpu` 为 0.5 +的 Container 肯定能够获得请求 1 CPU 的容器的一半 CPU 资源。表达式 `0.1` 等价于表达式 `100m`， +可以看作 “100 millicpu”。有些人说成是“一百毫 cpu”，其实说的是同样的事情。 +具有小数点（如 `0.1`）的请求由 API 转换为 `100m`；最大精度是 `1m`。 +因此，或许你应该优先考虑使用 `100m` 的形式。 + +CPU 总是按绝对数量来请求的，不可以使用相对数量； +0.1 的 CPU 在单核、双核、48 核的机器上的意义是一样的。 + + + +## 内存的含义 + +内存的约束和请求以字节为单位。你可以使用以下后缀之一以一般整数或定点整数形式来表示内存： +E、P、T、G、M、K。你也可以使用对应的 2 的幂数：Ei、Pi、Ti、Gi、Mi、Ki。 +例如，以下表达式所代表的是大致相同的值： + +```shell +128974848、129e6、129M、123Mi +``` + + + +下面是个例子。 + +以下 Pod 有两个 Container。每个 Container 的请求为 0.25 cpu 和 64MiB（226 字节）内存， +每个容器的资源约束为 0.5 cpu 和 128MiB 内存。 +你可以认为该 Pod 的资源请求为 0.5 cpu 和 128 MiB 内存，资源限制为 1 cpu 和 256MiB 内存。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: db + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "password" + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" + - name: wp + image: wordpress + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" +``` + + + +## 带资源请求的 Pod 如何调度 + +当你创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。 +每个节点对每种资源类型都有一个容量上限：可为 Pod 提供的 CPU 和内存量。 +调度程序确保对于每种资源类型，所调度的容器的资源请求的总和小于节点的容量。 +请注意，尽管节点上的实际内存或 CPU 资源使用量非常低，如果容量检查失败， +调度程序仍会拒绝在该节点上放置 Pod。 +当稍后节点上资源用量增加，例如到达请求率的每日峰值区间时，节点上也不会出现资源不足的问题。 + + + +## 带资源约束的 Pod 如何运行 + +当 kubelet 启动 Pod 中的 Container 时，它会将 CPU 和内存约束信息传递给容器运行时。 + +当使用 Docker 时： + + + +- `spec.containers[].resources.requests.cpu` 先被转换为可能是小数的基础值，再乘以 1024。 + 这个数值和 2 的较大者用作 `docker run` 命令中的 + [`--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) + 标志的值。 +- `spec.containers[].resources.limits.cpu` 先被转换为 millicore 值，再乘以 100。 + 其结果就是每 100 毫秒内容器可以使用的 CPU 时间总量。在此期间（100ms），容器所使用的 CPU + 时间不会超过它被分配的时间。 + + {{< note >}} + 默认的配额（quota）周期为 100 毫秒。 CPU配额的最小精度为 1 毫秒。 + {{}} + +- `spec.containers[].resources.limits.memory` 被转换为整数值，作为 `docker run` 命令中的 + [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) + 参数值。 + + + +如果 Container 超过其内存限制，则可能会被终止。如果容器可重新启动，则与所有其他类型的 +运行时失效一样，kubelet 将重新启动容器。 + +如果一个 Container 内存用量超过其内存请求值，那么当节点内存不足时，容器所处的 Pod 可能被逐出。 + +每个 Container 可能被允许也可能不被允许使用超过其 CPU 约束的处理时间。 +但是，容器不会由于 CPU 使用率过高而被杀死。 + +要确定 Container 是否会由于资源约束而无法调度或被杀死，请参阅[疑难解答](#troubleshooting) 部分。 + + + +## 监控计算和内存资源用量 + +Pod 的资源使用情况是作为 Pod 状态的一部分来报告的。 + +如果为集群配置了可选的 +[监控工具](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)， +则可以直接从 +[指标 API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api) +或者监控工具获得 Pod 的资源使用情况。 + + + +## 本地临时存储 + + +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + +节点通常还可以具有本地的临时性存储，由本地挂接的可写入设备或者有时也用 RAM +来提供支持。 +“临时（Ephemeral）”意味着对所存储的数据不提供长期可用性的保证。 + +Pods 通常可以使用临时性本地存储来实现缓冲区、保存日志等功能。 +kubelet 可以为使用本地临时存储的 Pods 提供这种存储空间，允许后者使用 +[`emptyDir`](/docs/concepts/storage/volumes/#emptydir) 类型的 +{{< glossary_tooltip term_id="volume" text="卷" >}}将其挂载到容器中。 + + + +kubelet 也使用此类存储来保存 +[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， +容器镜像文件、以及运行中容器的可写入层。 + +{{< caution >}} +如果节点失效，存储在临时性存储中的数据会丢失。 +你的应用不能对本地临时性存储的性能 SLA（例如磁盘 IOPS）作任何假定。 +{{< /caution >}} + +作为一种 beta 阶段功能特性，Kubernetes 允许你跟踪、预留和限制 Pod +可消耗的临时性本地存储数量。 + + + +### 本地临时性存储的配置 + +Kubernetes 有两种方式支持节点上配置本地临时性存储： + +{{< tabs name="local_storage_configurations" >}} +{{% tab name="单一文件系统" %}} +采用这种配置时，你会把所有类型的临时性本地数据（包括 `emptyDir` +卷、可写入容器层、容器镜像、日志等）放到同一个文件系统中。 +作为最有效的 kubelet 配置方式，这意味着该文件系统是专门提供给 Kubernetes +（kubelet）来保存数据的。 + +kubelet 也会生成 +[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， +并按临时性本地存储的方式对待之。 + + + +kubelet 会将日志写入到所配置的日志目录（默认为 `/var/log`）下的文件中； +还会针对其他本地存储的数据使用同一个基础目录（默认为 `/var/lib/kubelet`）。 + +通常，`/var/lib/kubelet` 和 `/var/log` 都是在系统的根文件系统中。kubelet +的设计也考虑到这一点。 + +你的集群节点当然可以包含其他的、并非用于 Kubernetes 的很多文件系统。 +{{% /tab %}} + + + +{{% tab name="双文件系统" %}} + +你使用节点上的某个文件系统来保存运行 Pods 时产生的临时性数据：日志和 +`emptyDir` 卷等。你可以使用这个文件系统来保存其他数据（例如：与 Kubernetes +无关的其他系统日志）；这个文件系统还可以是根文件系统。 + +kubelet 也将 +[节点层面的容器日志](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) +写入到第一个文件系统中，并按临时性本地存储的方式对待之。 + +同时你使用另一个由不同逻辑存储设备支持的文件系统。在这种配置下，你会告诉 +kubelet 将容器镜像层和可写层保存到这第二个文件系统上的某个目录中。 + +第一个文件系统中不包含任何镜像层和可写层数据。 + +当然，你的集群节点上还可以有很多其他与 Kubernetes 没有关联的文件系统。 +{{% /tab %}} +{{< /tabs >}} + + + +kubelet 能够度量其本地存储的用量。实现度量机制的前提是： + +- `LocalStorageCapacityIsolation` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)被启用（默认状态），并且 +- 你已经对节点进行了配置，使之使用所支持的本地临时性储存配置方式之一 + +如果你的节点配置不同于以上预期，kubelet 就无法对临时性本地存储的资源约束实施限制。 + +{{< note >}} +kubelet 会将 `tmpfs` emptyDir 卷的用量当作容器内存用量，而不是本地临时性存储来统计。 +{{< /note >}} + + + +### 为本地临时性存储设置请求和约束值 + +你可以使用_ephemeral-storage_来管理本地临时性存储。 +Pod 中的每个 Container 可以设置以下属性： + +* `spec.containers[].resources.limits.ephemeral-storage` +* `spec.containers[].resources.requests.ephemeral-storage` + +`ephemeral-storage` 的请求和约束值是按字节计量的。你可以使用一般整数或者定点整数 +加上下面的后缀来表达存储量：E、P、T、G、M、K。 +你也可以使用对应的 2 的幂级数来表达：Ei、Pi、Ti、Gi、Mi、Ki。 +例如，下面的表达式所表达的大致是同一个值： + +```shell +128974848, 129e6, 129M, 123Mi +``` + + + +在下面的例子中，Pod 包含两个 Container。每个 Container 请求 2 GiB 大小的本地临时性存储。 +每个 Container 都设置了 4 GiB 作为其本地临时性存储的约束值。 +因此，整个 Pod 的本地临时性存储请求是 4 GiB，且其本地临时性存储的约束为 8 GiB。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: db + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "password" + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" + - name: wp + image: wordpress + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" +``` + + + +### 带 ephemeral-storage 的 Pods 的调度行为 + +当你创建一个 Pod 时，Kubernetes 调度器会为 Pod 选择一个节点来运行之。 +每个节点都有一个本地临时性存储的上限，是其可提供给 Pods 使用的总量。 +欲了解更多信息，可参考 +[节点可分配资源](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +节。 + +调度器会确保所调度的 Containers 的资源请求总和不会超出节点的资源容量。 + + + +### 临时性存储消耗的管理 {#resource-emphemeralstorage-consumption} + +如果 kubelet 将本地临时性存储作为资源来管理，则 kubelet 会度量以下各处的存储用量： + +- `emptyDir` 卷，除了 _tmpfs_ `emptyDir` 卷 +- 保存节点层面日志的目录 +- 可写入的容器镜像层 + +如果某 Pod 的临时存储用量超出了你所允许的范围，kubelet +会向其发出逐出（eviction）信号，触发该 Pod 被逐出所在节点。 + +就容器层面的隔离而言，如果某容器的可写入镜像层和日志用量超出其存储约束， +kubelet 也会将所在的 Pod 标记为逐出候选。 + +就 Pod 层面的隔离而言，kubelet 会将 Pod 中所有容器的约束值相加，得到 Pod +存储约束的总值。如果所有容器的本地临时性存储用量总和加上 Pod 的 `emptyDir` +卷的用量超出 Pod 存储约束值，kubelet 也会将该 Pod 标记为逐出候选。 + + + +{{< caution >}} +如果 kubelet 没有度量本地临时性存储的用量，即使 Pod +的本地存储用量超出其约束值也不会被逐出。 + +不过，如果用于可写入容器镜像层、节点层面日志或者 `emptyDir` 卷的文件系统中可用空间太少， +节点会为自身设置本地存储不足的{{< glossary_tooltip text="污点" term_id="taint" >}} 标签。 +这一污点会触发对那些无法容忍该污点的 Pods 的逐出操作。 + +关于临时性本地存储的配置信息，请参考[这里](#configurations-for-local-ephemeral-storage) +{{< /caution >}} + + + +kubelet 支持使用不同方式来度量 Pod 的存储用量： + +{{< tabs name="resource-emphemeralstorage-measurement" >}} +{{% tab name="周期性扫描" %}} +kubelet 按预定周期执行扫描操作，检查 `emptyDir` 卷、容器日志目录以及可写入容器镜像层。 + +这一扫描会度量存储空间用量。 + +{{< note >}} +在这种模式下，kubelet 并不检查已删除文件所对应的、仍处于打开状态的文件描述符。 + +如果你（或者容器）在 `emptyDir` 卷中创建了一个文件，写入一些内容之后再次打开 +该文件并执行了删除操作，所删除文件对应的 inode 仍然存在，直到你关闭该文件为止。 +kubelet 不会将该文件所占用的空间视为已使用空间。 +{{< /note >}} + +{{% /tab %}} + + + +{{% tab name="文件系统项目配额" %}} + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +项目配额（Project Quota）是一个操作系统层的功能特性，用来管理文件系统中的存储用量。 +在 Kubernetes 中，你可以启用项目配额以监视存储用量。 +你需要确保节点上为 `emptyDir` 提供存储的文件系统支持项目配额。 +例如，XFS 和 ext4fs 文件系统都支持项目配额。 + +{{< note >}} +项目配额可以帮你监视存储用量，但无法对存储约束执行限制。 +{{< /note >}} + + + +Kubernetes 所使用的项目 ID 始于 `1048576`。 +所使用的 IDs 会注册在 `/etc/projects` 和 `/etc/projid` 文件中。 +如果该范围中的项目 ID 已经在系统中被用于其他目的，则已占用的项目 IDs +也必须注册到 `/etc/projects` 和 `/etc/projid` 中，这样 Kubernetes +才不会使用它们。 + +配额方式与目录扫描方式相比速度更快，结果更精确。当某个目录被分配给某个项目时， +该目录下所创建的所有文件都属于该项目，内核只需要跟踪该项目中的文件所使用的存储块个数。 +如果某文件被创建后又被删除，但对应文件描述符仍处于打开状态， +该文件会继续耗用存储空间。配额跟踪技术能够精确第记录对应存储空间的状态， +而目录扫描方式会忽略被删除文件所占用的空间。 + + + +如果你希望使用项目配额，你需要： + +* 在 kubelet 配置中启用 `LocalStorageCapacityIsolationFSQuotaMonitoring=true` + [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)。 + +* 确保根文件系统（或者可选的运行时文件系统）启用了项目配额。所有 XFS + 文件系统都支持项目配额。 + 对 extf 文件系统而言，你需要在文件系统尚未被挂载时启用项目配额跟踪特性： + + ```bash + # 对 ext4 而言，在 /dev/block-device 尚未被挂载时执行下面操作 + sudo tune2fs -O project -Q prjquota /dev/block-device + ``` + +* 确保根文件系统（或者可选的运行时文件系统）在挂载时项目配额特性是被启用了的。 + 对于 XFS 和 ext4fs 而言，对应的挂载选项称作 `prjquota`。 + +{{% /tab %}} +{{< /tabs >}} + + + +## 扩展资源（Extended Resources） + +扩展资源是 `kubernetes.io` 域名之外的标准资源名称。 +它们使得集群管理员能够颁布非 Kubernetes 内置资源，而用户可以使用他们。 + +使用扩展资源需要两个步骤。首先，集群管理员必须颁布扩展资源。 +其次，用户必须在 Pod 中请求扩展资源。 + + + +### 管理扩展资源 + +#### 节点级扩展资源 + +节点级扩展资源绑定到节点。 + +##### 设备插件管理的资源 + +有关如何颁布在各节点上由设备插件所管理的资源，请参阅[设备插件](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。 + + + +##### 其他资源 + +为了颁布新的节点级扩展资源，集群操作员可以向 API 服务器提交 `PATCH` HTTP 请求， +以在集群中节点的 `status.capacity` 中为其配置可用数量。 +完成此操作后，节点的 `status.capacity` 字段中将包含新资源。 +kubelet 会异步地对 `status.allocatable` 字段执行自动更新操作，使之包含新资源。 +请注意，由于调度器在评估 Pod 是否适合在某节点上执行时会使用节点的 `status.allocatable` 值， +在更新节点容量使之包含新资源之后和请求该资源的第一个 Pod 被调度到该节点之间， +可能会有短暂的延迟。 + + + +**示例：** + +这是一个示例，显示了如何使用 `curl` 构造 HTTP 请求，公告主节点为 `k8s-master` +的节点 `k8s-node-1` 上存在五个 `example.com/foo` 资源。 + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ +http://k8s-master:8080/api/v1/nodes/k8s-node-1/status +``` + + + +{{< note >}} +在前面的请求中，`~1` 是在 patch 路径中对字符 `/` 的编码。 +JSON-Patch 中的操作路径的值被视为 JSON-Pointer 类型。 +有关更多详细信息，请参见 +[IETF RFC 6901 第 3 节](https://tools.ietf.org/html/rfc6901#section-3)。 +{{< /note >}} + + + +#### 集群层面的扩展资源 + +集群层面的扩展资源并不绑定到具体节点。 +它们通常由调度器扩展程序（Scheduler Extenders）管理，这些程序处理资源消耗和资源配额。 + +您可以在[调度器策略配置](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)中指定由调度器扩展程序处理的扩展资源。 + + + +**示例：** + +下面的调度器策略配置标明集群层扩展资源 "example.com/foo" 由调度器扩展程序处理。 + +- 仅当 Pod 请求 "example.com/foo" 时，调度器才会将 Pod 发送到调度器扩展程序。 +- `ignoredByScheduler` 字段指定调度器不要在其 `PodFitsResources` 断言中检查 + "example.com/foo" 资源。 + +```json +{ + "kind": "Policy", + "apiVersion": "v1", + "extenders": [ + { + "urlPrefix":"", + "bindVerb": "bind", + "managedResources": [ + { + "name": "example.com/foo", + "ignoredByScheduler": true + } + ] + } + ] +} +``` + + + +### 使用扩展资源 + +就像 CPU 和内存一样，用户可以在 Pod 的规约中使用扩展资源。 +调度器负责资源的核算，确保同时分配给 Pod 的资源总量不会超过可用数量。 + + + +{{< note >}} +扩展资源取代了非透明整数资源（Opaque Integer Resources，OIR）。 +用户可以使用 `kubernetes.io` （保留）以外的任何域名前缀。 +{{< /note >}} + + + +要在 Pod 中使用扩展资源，请在容器规范的 `spec.containers[].resources.limits` +映射中包含资源名称作为键。 + +{{< note >}} +扩展资源不能过量使用，因此如果容器规范中同时存在请求和约束，则它们的取值必须相同。 +{{< /note >}} + + + +仅当所有资源请求（包括 CPU、内存和任何扩展资源）都被满足时，Pod 才能被调度。 +在资源请求无法满足时，Pod 会保持在 `PENDING` 状态。 + +**示例：** + +下面的 Pod 请求 2 个 CPU 和 1 个 "example.com/foo"（扩展资源）。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + containers: + - name: my-container + image: myimage + resources: + requests: + cpu: 2 + example.com/foo: 1 + limits: + example.com/foo: 1 +``` + + + +## 疑难解答 + +### 我的 Pod 处于悬决状态且事件信息显示 failedScheduling + +如果调度器找不到该 Pod 可以匹配的任何节点，则该 Pod 将保持未被调度状态， +直到找到一个可以被调度到的位置。每当调度器找不到 Pod 可以调度的地方时， +会产生一个事件，如下所示： + +```shell +kubectl describe pod frontend | grep -A 3 Events +``` +``` +Events: + FirstSeen LastSeen Count From Subobject PathReason Message + 36s 5s 6 {scheduler} FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others +``` + + + +在上述示例中，由于节点上的 CPU 资源不足，名为 “frontend” 的 Pod 无法被调度。 +由于内存不足（PodExceedsFreeMemory）而导致失败时，也有类似的错误消息。 +一般来说，如果 Pod 处于悬决状态且有这种类型的消息时，你可以尝试如下几件事情： + +- 向集群添加更多节点。 +- 终止不需要的 Pod，为悬决的 Pod 腾出空间。 +- 检查 Pod 所需的资源是否超出所有节点的资源容量。例如，如果所有节点的容量都是`cpu：1`， + 那么一个请求为 `cpu: 1.1` 的 Pod 永远不会被调度。 + +您可以使用 `kubectl describe nodes` 命令检查节点容量和已分配的资源数量。 例如： + +```shell +kubectl describe nodes e2e-test-node-pool-4lw4 +``` +``` +Name: e2e-test-node-pool-4lw4 +[ ... 这里忽略了若干行以便阅读 ...] +Capacity: + cpu: 2 + memory: 7679792Ki + pods: 110 +Allocatable: + cpu: 1800m + memory: 7474992Ki + pods: 110 +[ ... 这里忽略了若干行以便阅读 ...] +Non-terminated Pods: (5 in total) + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits + --------- ---- ------------ ---------- --------------- ------------- + kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%) + kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%) + kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%) + kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%) + kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%) +Allocated resources: + (Total limits may be over 100 percent, i.e., overcommitted.) + CPU Requests CPU Limits Memory Requests Memory Limits + ------------ ---------- --------------- ------------- + 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) +``` + + + +在上面的输出中，你可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存，节点将无法满足。 + +通过查看 `Pods` 部分，您将看到哪些 Pod 占用了节点上的资源。 + +可供 Pod 使用的资源量小于节点容量，因为系统守护程序也会使用一部分可用资源。 +[NodeStatus](/docs/resources-reference/{{< param "version" >}}/#nodestatus-v1-core) +的 `allocatable` 字段给出了可用于 Pod 的资源量。 +有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。 + +可以配置 [资源配额](/docs/concepts/policy/resource-quotas/) 功能特性以限制可以使用的资源总量。 +如果与名字空间配合一起使用，就可以防止一个团队占用所有资源。 + + + +### 我的容器被终止了 + +你的容器可能因为资源紧张而被终止。要查看容器是否因为遇到资源限制而被杀死， +请针对相关的 Pod 执行 `kubectl describe pod`： + +```shell +kubectl describe pod simmemleak-hra99 +``` + +``` +Name: simmemleak-hra99 +Namespace: default +Image(s): saadali/simmemleak +Node: kubernetes-node-tf0f/10.240.216.66 +Labels: name=simmemleak +Status: Running +Reason: +Message: +IP: 10.244.2.75 +Replication Controllers: simmemleak (1/1 replicas created) +Containers: + simmemleak: + Image: saadali/simmemleak + Limits: + cpu: 100m + memory: 50Mi + State: Running + Started: Tue, 07 Jul 2015 12:54:41 -0700 + Last Termination State: Terminated + Exit Code: 1 + Started: Fri, 07 Jul 2015 12:54:30 -0700 + Finished: Fri, 07 Jul 2015 12:54:33 -0700 + Ready: False + Restart Count: 5 +Conditions: + Type Status + Ready False +Events: + FirstSeen LastSeen Count From SubobjectPath Reason Message + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a +``` + + + +在上面的例子中，`Restart Count: 5` 意味着 Pod 中的 `simmemleak` 容器被终止并重启了五次。 + +你可以使用 `kubectl get pod` 命令加上 `-o go-template=...` 选项来获取之前终止容器的状态。 + +```shell +kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99 +``` +``` +Container Name: simmemleak +LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]] +``` + + + +你可以看到容器因为 `reason:OOM killed` 而被终止，`OOM` 表示内存不足（Out Of Memory）。 + +## {{% heading "whatsnext" %}} + + + +* 获取将 [分配内存资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验 +* 获取将 [分配 CPU 资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验 +* 关于请求和约束之间的区别，细节信息可参见[资源服务质量](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md) +* 阅读 API 参考文档中 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 部分。 +* 阅读 API 参考文档中 [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) 部分。 +* 阅读 XFS 中关于 [项目配额](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 的文档。 + diff --git a/content/zh/docs/concepts/configuration/resource-bin-packing.md b/content/zh/docs/concepts/configuration/resource-bin-packing.md index b43257f47f..dd4584c989 100644 --- a/content/zh/docs/concepts/configuration/resource-bin-packing.md +++ b/content/zh/docs/concepts/configuration/resource-bin-packing.md @@ -1,22 +1,12 @@ --- -reviewers: -- bsalamat -- k82cn -- ahg-g -title: 扩展资源的资源箱打包 +title: 扩展资源的资源装箱 content_type: concept -weight: 10 +weight: 50 --- @@ -26,46 +16,48 @@ weight: 10 -可以将 kube-scheduler 配置为使用 `RequestedToCapacityRatioResourceAllocation` 优先级函数启用资源箱打包以及扩展资源。 + +使用 `RequestedToCapacityRatioResourceAllocation` 优先级函数，可以将 kube-scheduler +配置为支持包含扩展资源在内的资源装箱操作。 优先级函数可用于根据自定义需求微调 kube-scheduler 。 - - -## 使用 RequestedToCapacityRatioResourceAllocation 启用装箱 - -在 Kubernetes 1.15 之前，Kube-scheduler 用于允许根据主要资源，如 CPU 和内存对容量之比的请求对节点进行评分。 -Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许用户指定资源以及每个资源的权重，以便根据容量之比的请求为节点评分。 -这允许用户通过使用适当的参数来打包扩展资源，从而提高了大型集群中稀缺资源的利用率。 -`RequestedToCapacityRatioResourceAllocation` 优先级函数的行为可以通过名为 `requestedToCapacityRatioArguments` 的配置选项进行控制。 -这个论证由两个参数 `shape` 和 `resources` 组成。 -Shape 允许用户根据 `utilization` 和 `score` 值将功能调整为要求最少或要求最高的功能。 -资源由 `name` 和 `weight` 组成，`name` 指定评分时要考虑的资源，`weight` 指定每种资源的权重。 + +## 使用 RequestedToCapacityRatioResourceAllocation 启用装箱 + +在 Kubernetes 1.15 之前，Kube-scheduler 通常允许根据对主要资源（如 CPU 和内存）的请求数量和可用容量 +之比率对节点评分。 +Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许用户指定资源以及每类资源的权重， +以便根据请求数量与可用容量之比率为节点评分。 +这就使得用户可以通过使用适当的参数来对扩展资源执行装箱操作，从而提高了大型集群中稀缺资源的利用率。 +`RequestedToCapacityRatioResourceAllocation` 优先级函数的行为可以通过名为 +`requestedToCapacityRatioArguments` 的配置选项进行控制。 +该标志由两个参数 `shape` 和 `resources` 组成。 +shape 允许用户根据 `utilization` 和 `score` 值将函数调整为最少请求（least requested）或 +最多请求（most requested）计算。 +resources 由 `name` 和 `weight` 组成，`name` 指定评分时要考虑的资源，`weight` 指定每种资源的权重。 -以下是一个配置示例，该配置将 `requestedToCapacityRatioArguments` 设置为扩展资源 `intel.com/foo` 和 `intel.com/bar` 的装箱行为 + +以下是一个配置示例，该配置将 `requestedToCapacityRatioArguments` 设置为对扩展资源 +`intel.com/foo` 和 `intel.com/bar` 的装箱行为 ```json { "kind" : "Policy", "apiVersion" : "v1", - ... - "priorities" : [ - ... - { "name": "RequestedToCapacityRatioPriority", "weight": 2, @@ -89,16 +81,17 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments` -**默认情况下禁用此功能** + +**默认情况下此功能处于被禁用状态** -### 调整 RequestedToCapacityRatioResourceAllocation 优先级函数 - + +### 调整 RequestedToCapacityRatioResourceAllocation 优先级函数 + `shape` 用于指定 `RequestedToCapacityRatioPriority` 函数的行为。 ```yaml @@ -109,8 +102,9 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments` -上面的参数在利用率为 0% 时给节点评分为0，在利用率为 100% 时给节点评分为10，因此启用了装箱行为。 -要启用最少请求，必须按如下方式反转得分值。 + +上面的参数在 utilization 为 0% 时给节点评分为 0，在 utilization 为 100% 时给节点评分为 10， +因此启用了装箱行为。要启用最少请求（least requested）模式，必须按如下方式反转得分值。 ```yaml {"utilization": 0, "score": 100}, @@ -124,9 +118,9 @@ The above arguments give the node a score of 0 if utilization is 0% and 10 for u ``` yaml "resources": [ - {"name": "CPU", "weight": 1}, - {"name": "Memory", "weight": 1} - ] + {"name": "CPU", "weight": 1}, + {"name": "Memory", "weight": 1} +] ``` -weight 参数是可选的，如果未指定，则设置为1。 -同样， weight 不能设置为负值。 +weight 参数是可选的，如果未指定，则设置为 1。 +同时，weight 不能设置为负值。 -### RequestedToCapacityRatioResourceAllocation 优先级函数如何对节点评分 - -本部分适用于希望了解此功能的内部细节的人员。 -以下是如何针对给定的一组值计算节点得分的示例。 + +### RequestedToCapacityRatioResourceAllocation 优先级函数如何对节点评分 + +本节适用于希望了解此功能的内部细节的人员。 +以下是如何针对给定的一组值来计算节点得分的示例。 ``` -Requested Resources +请求的资源 -intel.com/foo : 2 +intel.com/foo: 2 Memory: 256MB CPU: 2 -Resource Weights +资源权重 -intel.com/foo : 5 +intel.com/foo: 5 Memory: 1 CPU: 3 FunctionShapePoint {{0, 0}, {100, 10}} -Node 1 Spec +节点 Node 1 配置 -Available: -intel.com/foo : 4 -Memory : 1 GB -CPU: 8 +可用： + intel.com/foo : 4 + Memory : 1 GB + CPU: 8 -Used: -intel.com/foo: 1 -Memory: 256MB -CPU: 1 +已用： + intel.com/foo: 1 + Memory: 256MB + CPU: 1 - -Node Score: +节点得分： intel.com/foo = resourceScoringFunction((2+1),4) - = (100 - ((4-3)*100/4) - = (100 - 25) - = 75 - = rawScoringFunction(75) + = (100 - ((4-3)*100/4) + = (100 - 25) + = 75 + = rawScoringFunction(75) = 7 Memory = resourceScoringFunction((256+256),1024) @@ -214,27 +207,25 @@ NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) = 5 -Node 2 Spec +节点 Node 2 配置 -Available: -intel.com/foo: 8 -Memory: 1GB -CPU: 8 +可用： + intel.com/foo: 8 + Memory: 1GB + CPU: 8 -Used: +已用： + intel.com/foo: 2 + Memory: 512MB + CPU: 6 -intel.com/foo: 2 -Memory: 512MB -CPU: 6 - - -Node Score: +节点得分： intel.com/foo = resourceScoringFunction((2+2),8) - = (100 - ((8-4)*100/8) - = (100 - 25) - = 50 - = rawScoringFunction(50) + = (100 - ((8-4)*100/8) + = (100 - 25) + = 50 + = rawScoringFunction(50) = 5 Memory = resourceScoringFunction((256+512),1024) @@ -251,8 +242,5 @@ CPU = resourceScoringFunction((2+6),8) NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) = 7 - ``` - - diff --git a/content/zh/docs/concepts/configuration/taint-and-toleration.md b/content/zh/docs/concepts/configuration/taint-and-toleration.md index 5e72941c25..26cbc3d364 100755 --- a/content/zh/docs/concepts/configuration/taint-and-toleration.md +++ b/content/zh/docs/concepts/configuration/taint-and-toleration.md @@ -154,9 +154,9 @@ effect `PreferNoSchedule` then Kubernetes will *try* to not schedule the pod ont the node (if it is already running on the node), and will not be scheduled onto the node (if it is not yet running on the node). --> -* 如果未被过滤的 taint 中存在一个以上 effect 值为 `NoSchedule` 的 taint，则 Kubernetes 不会将 pod 分配到该节点。 +* 如果未被过滤的 taint 中存在至少一个 effect 值为 `NoSchedule` 的 taint，则 Kubernetes 不会将 pod 分配到该节点。 * 如果未被过滤的 taint 中不存在 effect 值为 `NoSchedule` 的 taint，但是存在 effect 值为 `PreferNoSchedule` 的 taint，则 Kubernetes 会 *尝试* 将 pod 分配到该节点。 -* 如果未被过滤的 taint 中存在一个以上 effect 值为 `NoExecute` 的 taint，则 Kubernetes 不会将 pod 分配到该节点（如果 pod 还未在节点上运行），或者将 pod 从该节点驱逐（如果 pod 已经在节点上运行）。 +* 如果未被过滤的 taint 中存在至少一个 effect 值为 `NoExecute` 的 taint，则 Kubernetes 不会将 pod 分配到该节点（如果 pod 还未在节点上运行），或者将 pod 从该节点驱逐（如果 pod 已经在节点上运行）。 ## 设备插件示例 {#examples} @@ -337,7 +337,7 @@ Here are some examples of device plugin implementations: * [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin) * [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin) * [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin) -* [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) +* [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) ## {{% heading "whatsnext" %}} diff --git a/content/zh/docs/concepts/overview/components.md b/content/zh/docs/concepts/overview/components.md index f05be27399..c02a8d3d06 100644 --- a/content/zh/docs/concepts/overview/components.md +++ b/content/zh/docs/concepts/overview/components.md @@ -21,7 +21,7 @@ card: -* 查阅 [Kubernetes 组件](/docs/concepts/overview/components/) -* 开始 [Kubernetes 入门](/docs/setup/)? - +* 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/) +* 开始 [Kubernetes 入门](/zh/docs/setup/)? \ No newline at end of file diff --git a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md index f340841e19..408c9c7641 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -3,7 +3,7 @@ title: 理解 Kubernetes 对象 content_type: concept weight: 10 card: - name: 概念 + name: concepts weight: 40 --- diff --git a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md index a6456f6400..a0b7b773dc 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md @@ -77,6 +77,13 @@ for namespaces](/docs/admin/namespaces). --> 命名空间的创建和删除已在[命名空间的管理指南文档](/docs/admin/namespaces)中进行了描述。 + +{{< note >}} +避免使用前缀 `kube-` 创建命名空间，因为它是为 Kubernetes 系统命名空间保留的。 +{{< /note >}} + diff --git a/content/zh/docs/concepts/policy/resource-quotas.md b/content/zh/docs/concepts/policy/resource-quotas.md index af65151588..29d222a63c 100644 --- a/content/zh/docs/concepts/policy/resource-quotas.md +++ b/content/zh/docs/concepts/policy/resource-quotas.md @@ -150,7 +150,7 @@ The following resource types are supported: In addition to the resources mentioned above, in release 1.10, quota support for [extended resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) is added. --> -除上述资源外，在 Kubernetes 1.10 版本中，还添加了对[扩展资源](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)的支持。 +除上述资源外，在 Kubernetes 1.10 版本中，还添加了对[扩展资源](/zh/docs/concepts/configuration/manage-resources-containers/#扩展资源-extended-resources)的支持。 查看[资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)了解更多信息。 - - diff --git a/content/zh/docs/concepts/services-networking/service.md b/content/zh/docs/concepts/services-networking/service.md index b4636869d3..9573261c05 100644 --- a/content/zh/docs/concepts/services-networking/service.md +++ b/content/zh/docs/concepts/services-networking/service.md @@ -5,7 +5,7 @@ title: Services feature: title: 服务发现与负载均衡 description: > - 无需修改您的应用程序即可使用陌生的服务发现机制。Kubernetes 为容器提供了自己的 IP 地址和一个 DNS 名称，并且可以在它们之间实现负载平衡。 + 无需修改您的应用程序即可使用陌生的服务发现机制。Kubernetes 为容器提供了自己的 IP 地址和一个 DNS 名称，并且可以在它们之间实现负载均衡。 content_type: concept weight: 10 @@ -328,6 +328,27 @@ Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的 Endpoint 切片提供了附加的属性和功能，这些属性和功能在 [Endpoint 切片](/docs/concepts/services-networking/endpoint-slices/)中进行了详细描述。 + +### 应用程序协议 + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +AppProtocol 字段提供了一种为每个 Service 端口指定应用程序协议的方式。 + +作为一个 alpha 特性，该字段默认未启用。要使用该字段，请启用 `ServiceAppProtocol` [特性开关] +(/docs/reference/command-line-tools-reference/feature-gates/)。 + ### NodePort 类型 @@ -891,6 +931,25 @@ and `.spec.clusterIP:spec.ports[*].port`. (If the `--nodeport-addresses` flag in 需要注意的是，Service 能够通过 `:spec.ports[*].nodePort` 和 `spec.clusterIp:spec.ports[*].port` 而对外可见。 +例如： +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + type: NodePort + selector: + app: MyApp + ports: + # 默认情况下，为了方便起见，`targetPort` 被设置为与 `port` 字段相同的值。 + - port: 80 + targetPort: 80 + # 可选字段 + # 默认情况下，为了方便起见，Kubernetes 控制平面会从某个范围内分配一个端口号（默认：30000-32767） + nodePort: 30007 +``` + - 标记一个 `StorageClass` 为 *默认*； -- 确保 [`DefaultStorageClass` 准入控制器](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。 +- 确保 [`DefaultStorageClass` 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。 管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类 ： -更多详情请参阅 [PersistentVolumeClaim 章节](/docs/concepts/storage/persistent-volumes/#class-1)。 +更多详情请参阅 [PersistentVolumeClaim 章节](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 ```yaml apiVersion: storage.k8s.io/v1 diff --git a/content/zh/docs/concepts/storage/volume-pvc-datasource.md b/content/zh/docs/concepts/storage/volume-pvc-datasource.md index 755fa2588d..c39fad6f42 100644 --- a/content/zh/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/zh/docs/concepts/storage/volume-pvc-datasource.md @@ -135,6 +135,6 @@ The result is a new PVC with the name `clone-of-pvc-1` that has the exact same c Upon availability of the new PVC, the cloned PVC is consumed the same as other PVC. It's also expected at this point that the newly created PVC is an independent object. It can be consumed, cloned, snapshotted, or deleted independently and without consideration for it's original dataSource PVC. This also implies that the source is not linked in any way to the newly created clone, it may also be modified or deleted without affecting the newly created clone. --> -一旦新的 PVC 可用，被克隆的 PVC 项其他 PVC 一样被使用。可以预期的是，新创建的 PVC 是一个独立的对象。可以独立使用，克隆，快照或删除它，而不需要考虑它的原始数据源 PVC。这也意味着，源没有以任何方式链接到新创建的 PVC，它也可以被修改或删除，而不会影响到新创建的克隆。 +一旦新的 PVC 可用，被克隆的 PVC 像其他 PVC 一样被使用。可以预期的是，新创建的 PVC 是一个独立的对象。可以独立使用，克隆，快照或删除它，而不需要考虑它的原始数据源 PVC。这也意味着，源没有以任何方式链接到新创建的 PVC，它也可以被修改或删除，而不会影响到新创建的克隆。 diff --git a/content/zh/docs/concepts/workloads/controllers/deployment.md b/content/zh/docs/concepts/workloads/controllers/deployment.md index ffeb5c550a..0895ba7cec 100644 --- a/content/zh/docs/concepts/workloads/controllers/deployment.md +++ b/content/zh/docs/concepts/workloads/controllers/deployment.md @@ -109,7 +109,7 @@ The following are typical use cases for Deployments: * [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore. --> -* [清理较旧的 ReplicaSets ](#clean-up-policy) ，那些不在需要的。 +* [清理较旧的 ReplicaSets ](#clean-up-policy) ，那些不再需要的。 如果 PR 拥有来自 Kubernetes 社区的任何人的 `/lgtm` 评论和来自 `sig-docs-maintainers` 组的 `/approve` 评论，只要它没有被 hold 并且作者已签署了 CLA，PR 就会被合并。 -{{< note >}} +The ["Participating"](/docs/contribute/participating/#approvers) section contains more information for reviewers and approvers, including specific responsibilities for approvers. +--> + +{{< note >}} ["参与"](/docs/contribute/participating/#approvers)部分包含有关 reviewers 和 approvers 的更多信息，包括 approvers 的具体职责。 {{< /note >}} diff --git a/content/zh/docs/contribute/start.md b/content/zh/docs/contribute/start.md index 40da4e7e4a..4e3e65136b 100644 --- a/content/zh/docs/contribute/start.md +++ b/content/zh/docs/contribute/start.md @@ -256,10 +256,12 @@ SIG Docs 团队交流采用如下机制： - 参与 [SIG Docs 视频周例会](https://github.com/kubernetes/community/tree/master/sig-docs)，会通过 Slack 频道和邮件列表通知。 目前通过 Zoom 进行会议，所以您需要下载 [Zoom 客户端](https://zoom.us/download)，或者通过手机拨入。 -{{< note >}} 您也可以查看 [Kubernetes 社区会议日历](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)。 +You can also check the SIG Docs weekly meeting on the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). +--> + +{{< note >}} +您也可以查看 [Kubernetes 社区会议日历](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)。 {{< /note >}} **Kubernetes 代码开发者**：如果您在撰写 Kubernetes 新版本的新功能文档，流程会稍有不同。 +process guidelines and information about deadlines. +--> + +{{< note >}} +**Kubernetes 代码开发者**：如果您在撰写 Kubernetes 新版本的新功能文档，流程会稍有不同。 关于流程指南和最后期限的信息，请参阅[编写功能文档](/docs/contribute/intermediate/#sig-members-documenting-new-features)。 {{< /note >}} diff --git a/content/zh/docs/home/_index.md b/content/zh/docs/home/_index.md index 9106ce3727..d0e81e59d9 100644 --- a/content/zh/docs/home/_index.md +++ b/content/zh/docs/home/_index.md @@ -13,47 +13,59 @@ menu: title: "文档" weight: 20 post: > -

通过演练，示例和参考文档了解如何使用 Kubernetes。你甚至可以帮助贡献文档！

-overview: > - - Kubernetes 是一个开源容器编排引擎，用于容器化应用的自动化部署、扩展和管理。该项目托管在 CNCF。 - +

通过概念、教程和参考文档了解如何使用 Kubernetes。你甚至可以帮助贡献文档！

+# description: > +# Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation. +description: > + Kubernetes 是一个开源的容器编排引擎，用来对容器化应用进行自动部署、 扩缩和管理。此开源项目由云原生计算基金会（CNCF）托管。 +# overview: +# Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation (CNCF). +overview: + Kubernetes 是一个开源的容器编排引擎，用来对容器化应用进行自动化部署、 扩缩和管理。该项目托管在 CNCF。 +# cards: +# - name: concepts +# title: "Understand the basics" +# description: "Learn about Kubernetes and its fundamental concepts." +# button: "Learn Concepts" +# button_path: "/docs/concepts" +# - name: tutorials +# title: "Try Kubernetes" +# description: "Follow tutorials to learn how to deploy applications in Kubernetes." +# button: "View Tutorials" +# button_path: "/docs/tutorials" +# - name: setup +# title: "Set up a cluster" +# description: "Get Kubernetes running based on your resources and needs." +# button: "Set up Kubernetes" +# button_path: "/docs/setup" +# - name: tasks +# title: "Learn how to use Kubernetes" +# description: "Look up common tasks and how to perform them using a short sequence of steps." +# button: "View Tasks" +# button_path: "/docs/tasks" +# - name: training +# title: "Training" +# description: "Get certified in Kubernetes and make your cloud native projects successful!" +# button: "View training" +# button_path: "/training" +# - name: reference +# title: Look up reference information +# description: Browse terminology, command line syntax, API resource types, and setup tool documentation. +# button: View Reference +# button_path: /docs/reference +# - name: contribute +# title: Contribute to the docs +# description: Anyone can contribute, whether you’re new to the project or you’ve been around a long time. +# button: Contribute to the docs +# button_path: /docs/contribute +# - name: release-notes +# title: Release Notes +# description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes. +# button: "Download Kubernetes" +# button_path: "/zh/docs/setup/release/notes" +# - name: about +# title: About the documentation +# description: This website contains documentation for the current and previous 4 versions of Kubernetes. cards: - name: concepts title: "了解基本知识" @@ -75,20 +87,27 @@ cards: description: "查看常见任务以及如何使用简单步骤执行它们。" button: "查看任务" button_path: "/zh/docs/tasks" +- name: training + title: "培训" + description: "通过 Kubernetes 认证，助你的云原生项目成功！" + button: "查看培训" + button_path: "/zh/training" - name: reference - title: 参考 - description: 术语、命令行语法、API 资源类型和设置工具文档。 + title: 查阅参考信息 + description: 浏览术语、命令行语法、API 资源类型和安装工具文档。 button: 查看参考 button_path: /zh/docs/reference - name: contribute - title: 为该文档作出贡献 + title: 为文档作贡献 description: 任何人，无论对该项目熟悉与否，都能贡献自己的力量。 - button: 参与贡献 + button: 为文档作贡献 button_path: /zh/docs/contribute -- name: download - title: 下载 Kubernetes - description: 如果你正在安装或升级 Kubernetes 的话，最好参考最新的发行版说明。 +- name: release-notes + title: 发布说明 + description: 如果你正在安装或升级 Kubernetes，最好参考最新的发布说明。 + button: "下载 Kubernetes" + button_path: "/zh/docs/setup/release/notes" - name: about title: 关于文档 - description: 该网站包含了当前版本以及前 4 个版本的 Kubernetes 文档。 + description: 本网站包含了当前及前 4 个版本的 Kubernetes 文档。 --- diff --git a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md index e1782b0419..4b0fcf0584 100644 --- a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md +++ b/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md @@ -631,9 +631,9 @@ Example of a minimal response from a webhook to allow a request: * `allowed`，设置为 `true` 或 `false` -Webhook 禁止请求的最简单响应示例： +Webhook 允许请求的最简单响应示例： {{< tabs name="AdmissionReview_response_allow" >}} {{% tab name="admission.k8s.io/v1" %}} diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md index 183bdf46d9..89d8914642 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md +++ b/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md @@ -42,973 +42,973 @@ kube-scheduler [flags] - - --add-dir-header - - - - - 如果为 true，则将文件目录添加到标题中 - - - - - - - --address string     默认: "0.0.0.0" - - - - - - 弃用: 要监听 --port 端口的 IP 地址（对于所有 IPv4 接口设置为 0.0.0.0，对于所有 IPv6 接口设置为 ::）。 请参阅 --bind-address。 - - - - - --algorithm-provider string - - - - - 弃用: 要使用的调度算法，可选值：ClusterAutoscalerProvider | DefaultProvider - - - - - --alsologtostderr - - - - - - - - - --authentication-kubeconfig string - - - - - - - - - --authentication-skip-lookup - - - - - 如果为 false，则 authentication-kubeconfig 将用于从集群中查找缺少的身份验证配置。 - - - - - - - --authentication-token-webhook-cache-ttl duration     默认: 10s - - - - - - 缓存来自 Webhook 令牌身份验证器的响应的持续时间。 - - - - - - - --authentication-tolerate-lookup-failure     默认: true - - - - - - 如果为 true，则无法从集群中查找缺少的身份验证配置是致命的。请注意，这可能导致身份验证将所有请求视为匿名。 - - - - - - - --authorization-always-allow-paths stringSlice     默认: [/healthz] - - - - - - 在授权过程中跳过的 HTTP 路径列表，即在不联系 'core' kubernetes 服务器的情况下被授权的 HTTP 路径。 - - - - - --authorization-kubeconfig string - - - - - 指向具有足够权限以创建 subjectaccessreviews.authorization.k8s.io 的 'core' kubernetes 服务器的 kubeconfig 文件。这是可选的。如果为空，则禁止所有未经授权跳过的请求。 - - - - - - - --authorization-webhook-cache-authorized-ttl duration     默认: 10s - - - - - - 缓存来自 Webhook 授权者的 'authorized' 响应的持续时间。 - - - - - - - --authorization-webhook-cache-unauthorized-ttl duration     默认: 10s - - - - - - 缓存来自 Webhook 授权者的 'unauthorized' 响应的持续时间。 - - - - - --azure-container-registry-config string - - - - - 包含 Azure 容器仓库配置信息的文件的路径。 - - - - - - - --bind-address ip     默认: 0.0.0.0 - - - - - - 侦听 --secure-port 端口的 IP 地址。集群的其余部分以及 CLI/ Web 客户端必须可以访问关联的接口。如果为空，将使用所有接口（所有 IPv4 接口使用 0.0.0.0，所有 IPv6 接口使用 ::）。 - - - - - --cert-dir string - - - - - TLS 证书所在的目录。如果提供了--tls-cert-file 和 --tls private-key-file，则将忽略此参数。 - - - - - --client-ca-file string - - - - - 如果已设置，由 client-ca-file 中的授权机构签名的客户端证书的任何请求都将使用与客户端证书的 CommonName 对应的身份进行身份验证。 - - - - - --config string - - - - - 配置文件的路径。标志会覆盖此文件中的值。 - - - - - --contention-profiling - - - - - 弃用: 如果启用了性能分析，则启用锁竞争分析 - - - - - --feature-gates mapStringBool - - - - - 一组 key=value 对，描述了 alpha/experimental 特征开关。选项包括：
APIListChunking=true|false (BETA - 默认值=true)
APIResponseCompression=true|false (BETA - 默认值=true)
AllAlpha=true|false (ALPHA - 默认值=false)
AppArmor=true|false (BETA - 默认值=true)
AttachVolumeLimit=true|false (BETA - 默认值=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)
BlockVolume=true|false (BETA - 默认值=true)
BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false)
CPUManager=true|false (BETA - 默认值=true)
CRIContainerLogRotation=true|false (BETA - 默认值=true)
CSIBlockVolume=true|false (BETA - 默认值=true)
CSIDriverRegistry=true|false (BETA - 默认值=true)
CSIInlineVolume=true|false (BETA - 默认值=true)
CSIMigration=true|false (ALPHA - 默认值=false)
CSIMigrationAWS=true|false (ALPHA - 默认值=false)
CSIMigrationAzureDisk=true|false (ALPHA - 默认值=false)
CSIMigrationAzureFile=true|false (ALPHA - 默认值=false)
CSIMigrationGCE=true|false (ALPHA - 默认值=false)
CSIMigrationOpenStack=true|false (ALPHA - 默认值=false)
CSINodeInfo=true|false (BETA - 默认值=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
CustomResourceDefaulting=true|false (BETA - 默认值=true)
DevicePlugins=true|false (BETA - 默认值=true)
DryRun=true|false (BETA - 默认值=true)
DynamicAuditing=true|false (ALPHA - 默认值=false)
DynamicKubeletConfig=true|false (BETA - 默认值=true)
EndpointSlice=true|false (ALPHA - 默认值=false)
EphemeralContainers=true|false (ALPHA - 默认值=false)
EvenPodsSpread=true|false (ALPHA - 默认值=false)
ExpandCSIVolumes=true|false (BETA - 默认值=true)
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
ExpandPersistentVolumes=true|false (BETA - 默认值=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)
HPAScaleToZero=true|false (ALPHA - 默认值=false)
HyperVContainer=true|false (ALPHA - 默认值=false)
IPv6DualStack=true|false (ALPHA - 默认值=false)
KubeletPodResources=true|false (BETA - 默认值=true)
LegacyNodeRoleBehavior=true|false (ALPHA - 默认值=true)
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
MountContainers=true|false (ALPHA - 默认值=false)
NodeDisruptionExclusion=true|false (ALPHA - 默认值=false)
NodeLease=true|false (BETA - 默认值=true)
NonPreemptingPriority=true|false (ALPHA - 默认值=false)
PodOverhead=true|false (ALPHA - 默认值=false)
PodShareProcessNamespace=true|false (BETA - 默认值=true)
ProcMountType=true|false (ALPHA - 默认值=false)
QOSReserved=true|false (ALPHA - 默认值=false)
RemainingItemCount=true|false (BETA - 默认值=true)
RemoveSelfLink=true|false (ALPHA - 默认值=false)
RequestManagement=true|false (ALPHA - 默认值=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - 默认值=false)
ResourceQuotaScopeSelectors=true|false (BETA - 默认值=true)
RotateKubeletClientCertificate=true|false (BETA - 默认值=true)
RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
RunAsGroup=true|false (BETA - 默认值=true)
RuntimeClass=true|false (BETA - 默认值=true)
SCTPSupport=true|false (ALPHA - 默认值=false)
ScheduleDaemonSetPods=true|false (BETA - 默认值=true)
ServerSideApply=true|false (BETA - 默认值=true)
ServiceLoadBalancerFinalizer=true|false (BETA - 默认值=true)
ServiceNodeExclusion=true|false (ALPHA - 默认值=false)
StartupProbe=true|false (BETA - 默认值=true)
StorageVersionHash=true|false (BETA - 默认值=true)
StreamingProxyRedirects=true|false (BETA - 默认值=true)
SupportNodePidsLimit=true|false (BETA - 默认值=true)
SupportPodPidsLimit=true|false (BETA - 默认值=true)
Sysctls=true|false (BETA - 默认值=true)
TTLAfterFinished=true|false (ALPHA - 默认值=false)
TaintBasedEvictions=true|false (BETA - 默认值=true)
TaintNodesByCondition=true|false (BETA - 默认值=true)
TokenRequest=true|false (BETA - 默认值=true)
TokenRequestProjection=true|false (BETA - 默认值=true)
TopologyManager=true|false (ALPHA - 默认值=false)
ValidateProxyRedirects=true|false (BETA - 默认值=true)
VolumePVCDataSource=true|false (BETA - 默认值=true)
VolumeSnapshotDataSource=true|false (ALPHA - 默认值=false)
VolumeSubpathEnvExpansion=true|false (BETA - 默认值=true)
WatchBookmark=true|false (BETA - 默认值=true)
WinDSR=true|false (ALPHA - 默认值=false)
WinOverlay=true|false (ALPHA - 默认值=false)
WindowsGMSA=true|false (BETA - 默认值=true)
WindowsRunAsUserName=true|false (ALPHA - 默认值=false) - - - - - - - --hard-pod-affinity-symmetric-weight int32     默认: 1 - - - - - - 弃用: RequiredDuringScheduling 亲和力不是对称的，但是存在与每个 RequiredDuringScheduling 关联性规则相对应的隐式 PreferredDuringScheduling 关联性规则 --hard-pod-affinity-symmetric-weight 代表隐式 PreferredDuringScheduling 关联性规则的权重。权重必须在 0-100 范围内。此选项已移至策略配置文件。 - - - - - -h, --help - - - - - kube-scheduler 帮助命令 - - - - - --http2-max-streams-per-connection int - - - - - 服务器为客户端提供的 HTTP/2 连接最大限制。零表示使用 golang 的默认值。 - - - - - - - --kube-api-burst int32     默认: 100 - - - - - - 弃用: 与 kubernetes apiserver 通信时使用 - - - - - - - --kube-api-content-type string     默认: "application/vnd.kubernetes.protobuf" - - - - - - 弃用: 发送到 apiserver 的请求的内容类型。 - - - - - - - --kube-api-qps float32     默认: 50 - - - - - - 弃用: 与 kubernetes apiserver 通信时要使用的 QPS - - - - - --kubeconfig string - - - - - 弃用: 具有授权和主节点位置信息的 kubeconfig 文件的路径。 - - - - - - - --leader-elect     默认: true - - - - - - 在执行主循环之前，开始领导者选举并选出领导者。为实现高可用性，运行多副本的组件并选出领导者。 - - - - - - - --leader-elect-lease-duration duration     默认: 15s - - - - - - 非领导者候选人在观察到领导者更新后将等待直到试图获得领导但未更新的领导者职位的等待时间。这实际上是领导者在被另一位候选人替代之前可以停止的最大持续时间。该情况仅在启用了领导者选举的情况下才适用。 - - - - - - - --leader-elect-renew-deadline duration     默认: 10s - - - - - - - 领导者尝试在停止领导之前更新领导职位的间隔时间。该时间必须小于或等于租赁期限。仅在启用了领导者选举的情况下才适用。 - - - - - - --leader-elect-resource-lock endpoints     默认: "endpoints" - - - - - - 在领导者选举期间用于锁定的资源对象的类型。支持的选项是端点（默认）和 `configmaps` - - - - - - - --leader-elect-resource-name string     默认: "kube-scheduler" - - - - - - 在领导者选举期间用于锁定的资源对象的名称。 - - - - - - - --leader-elect-resource-namespace string     默认: "kube-system" - - - - - - 在领导者选举期间用于锁定的资源对象的命名空间。 - - - - - - - --leader-elect-retry-period duration     默认: 2s - - - - - - 客户应在尝试获取和更新领导之间等待的时间。仅在启用了领导者选举的情况下才适用。 - - - - - - - --lock-object-name string     默认: "kube-scheduler" - - - - - - 弃用: 定义锁对象的名称。将被删除以便使用 Leader-elect-resource-name - - - - - - - --lock-object-namespace string     默认: "kube-system" - - - - - - 弃用: 定义锁对象的命名空间。将被删除以便使用 leader-elect-resource-namespace。 - - - - - - - --log-backtrace-at traceLocation     默认: :0 - - - - - - 当记录命中行文件：N 时发出堆栈跟踪 - - - - - --log-dir string - - - - - 如果为非空，则在此目录中写入日志文件 - - - - - --log-file string - - - - - 如果为非空，请使用此日志文件 - - - - - - - --log-file-max-size uint     默认: 1800 - - - - - - 定义日志文件可以增长到的最大值。单位为兆字节。如果值为0，则最大文件大小为无限制。 - - - - - - - --log-flush-frequency duration     默认: 5s - - - - - - 两次日志刷新之间的最大秒数 - - - - - - - --logtostderr     默认: true - - - - - - 日志记录到标准错误而不是文件 - - - - - --master string - - - - - Kubernetes API 服务器的地址（覆盖 kubeconfig 中的任何值） - - - - - --policy-config-file string - - - - - 弃用：具有调度程序策略配置的文件。如果未提供 policy ConfigMap 或 --use-legacy-policy-config = true，则使用此文件 - - - - - --policy-configmap string - - - - - 弃用: 包含调度程序策略配置的 ConfigMap 对象的名称。如果 --use-legacy-policy-config = false，则它必须在调度程序初始化之前存在于系统命名空间中。必须将配置作为键为 'policy.cfg' 的 'Data' 映射中元素的值提供 - - - - - - - --policy-configmap-namespace string     默认: "kube-system" - - - - - - 弃用: 策略 ConfigMap 所在的命名空间。如果未提供或为空，则将使用 kube-system 命名空间。 - - - - - - - --port int     默认: 10251 - - - - - - 弃用: 在没有身份验证和授权的情况下不安全地为 HTTP 服务的端口。如果为0，则根本不提供 HTTP。请参见--secure-port。 - - - - - --profiling - - - - - 弃用: 通过 Web 界面主机启用配置文件：port/debug/pprof/ - - - - - --requestheader-allowed-names stringSlice - - - - - 客户端证书通用名称列表允许在 --requestheader-username-headers 指定的头部中提供用户名。如果为空，则允许任何由权威机构 --requestheader-client-ca-file 验证的客户端证书。 - - - - - --requestheader-client-ca-file string - - - - - 在信任 --requestheader-username-headers 指定的头部中的用户名之前用于验证传入请求上的客户端证书的根证书包。警告：通常不依赖于传入请求已经完成的授权。 - - - - - - - --requestheader-extra-headers-prefix stringSlice     默认: [x-remote-extra-] - - - - - - 要检查请求头部前缀列表。建议使用 X-Remote-Extra- - - - - - - - --requestheader-group-headers stringSlice     默认: [x-remote-group] - - - - - - 用于检查组的请求头部列表。建议使用 X-Remote-Group。 - - - - - - - --requestheader-username-headers stringSlice     默认: [x-remote-user] - - - - - - 用于检查用户名的请求头部列表。 X-Remote-User 很常见。 - - - - - - - --scheduler-name string     默认: "default-scheduler" - - - - - - 弃用: 调度程序名称用于根据 Pod 的 "spec.schedulerName" 选择此调度程序将处理的 Pod。 - - - - - - - --secure-port int     默认: 10259 - - - - - - 通过身份验证和授权为 HTTPS 服务的端口。如果为 0，则根本不提供 HTTPS。 - - - - - --skip-headers - - - - - 如果为 true，请在日志消息中避免头部前缀 - - - - - --skip-log-headers - - - - - 如果为true，则在打开日志文件时避免头部 - - - - - - - --stderrthreshold severity     默认: 2 - - - - - - 达到或超过此阈值的日志转到 stderr - - - - - --tls-cert-file string - - - - - 包含默认的 HTTPS x509 证书的文件。（CA证书（如果有）在服务器证书之后并置）。如果启用了 HTTPS 服务，并且未提供 --tls-cert-file 和 --tls-private-key-file，则会为公共地址生成一个自签名证书和密钥，并将其保存到 --cert-dir 指定的目录中。 - - - - - --tls-cipher-suites stringSlice - - - - - 服务器的密码套件列表，以逗号分隔。如果省略，将使用默认的 Go 密码套件。可能的值： - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA - - - - - --tls-min-version string - - - - - 支持的最低 TLS 版本。可能的值：VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 - - - - - --tls-private-key-file string - - - - - 包含与 --tls-cert-file 匹配的默认 x509 私钥的文件。 - - - - - - - --tls-sni-cert-key namedCertKey     默认: [] - - - - - - 一对 x509 证书和私钥文件路径，可选地后缀为完全限定域名的域模式列表，并可能带有前缀的通配符段。如果未提供域模式，则获取证书名称。非通配符匹配胜过通配符匹配，显式域模式胜过获取名称。 对于多个密钥/证书对，请多次使用 --tls-sni-cert-key。例如: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。 - - - - - --use-legacy-policy-config - - - - - 弃用: 设置为 true 时，调度程序将忽略策略 ConfigMap 并使用策略配置文件 - - - - - -v, --v Level - - - - - 日志级别详细程度的数字 - - - - - --version version[=true] - - - - - 打印版本信息并退出 - - - - - --vmodule moduleSpec - - - - - 以逗号分隔的 pattern = N 设置列表，用于文件过滤的日志记录 - - - - - --write-config-to string - - - - - 如果已设置，请将配置值写入此文件并退出。 - - + + --add-dir-header + + + + + 如果为 true，则将文件目录添加到标题中 + + + + + + + --address string     默认: "0.0.0.0" + + + + + + 弃用: 要监听 --port 端口的 IP 地址（对于所有 IPv4 接口设置为 0.0.0.0，对于所有 IPv6 接口设置为 ::）。 请参阅 --bind-address。 + + + + + --algorithm-provider string + + + + + 弃用: 要使用的调度算法，可选值：ClusterAutoscalerProvider | DefaultProvider + + + + + --alsologtostderr + + + + + + + + + --authentication-kubeconfig string + + + + + + + + + --authentication-skip-lookup + + + + + 如果为 false，则 authentication-kubeconfig 将用于从集群中查找缺少的身份验证配置。 + + + + + + + --authentication-token-webhook-cache-ttl duration     默认: 10s + + + + + + 缓存来自 Webhook 令牌身份验证器的响应的持续时间。 + + + + + + + --authentication-tolerate-lookup-failure     默认: true + + + + + + 如果为 true，则无法从集群中查找缺少的身份验证配置是致命的。请注意，这可能导致身份验证将所有请求视为匿名。 + + + + + + + --authorization-always-allow-paths stringSlice     默认: [/healthz] + + + + + + 在授权过程中跳过的 HTTP 路径列表，即在不联系 'core' kubernetes 服务器的情况下被授权的 HTTP 路径。 + + + + + --authorization-kubeconfig string + + + + + 指向具有足够权限以创建 subjectaccessreviews.authorization.k8s.io 的 'core' kubernetes 服务器的 kubeconfig 文件。这是可选的。如果为空，则禁止所有未经授权跳过的请求。 + + + + + + + --authorization-webhook-cache-authorized-ttl duration     默认: 10s + + + + + + 缓存来自 Webhook 授权者的 'authorized' 响应的持续时间。 + + + + + + + --authorization-webhook-cache-unauthorized-ttl duration     默认: 10s + + + + + + 缓存来自 Webhook 授权者的 'unauthorized' 响应的持续时间。 + + + + + --azure-container-registry-config string + + + + + 包含 Azure 容器仓库配置信息的文件的路径。 + + + + + + + --bind-address ip     默认: 0.0.0.0 + + + + + + 侦听 --secure-port 端口的 IP 地址。集群的其余部分以及 CLI/ Web 客户端必须可以访问关联的接口。如果为空，将使用所有接口（所有 IPv4 接口使用 0.0.0.0，所有 IPv6 接口使用 ::）。 + + + + + --cert-dir string + + + + + TLS 证书所在的目录。如果提供了--tls-cert-file 和 --tls private-key-file，则将忽略此参数。 + + + + + --client-ca-file string + + + + + 如果已设置，由 client-ca-file 中的授权机构签名的客户端证书的任何请求都将使用与客户端证书的 CommonName 对应的身份进行身份验证。 + + + + + --config string + + + + + 配置文件的路径。标志会覆盖此文件中的值。 + + + + + --contention-profiling + + + + + 弃用: 如果启用了性能分析，则启用锁竞争分析 + + + + + --feature-gates mapStringBool + + + + + 一组 key=value 对，描述了 alpha/experimental 特征开关。选项包括：
APIListChunking=true|false (BETA - 默认值=true)
APIResponseCompression=true|false (BETA - 默认值=true)
AllAlpha=true|false (ALPHA - 默认值=false)
AppArmor=true|false (BETA - 默认值=true)
AttachVolumeLimit=true|false (BETA - 默认值=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)
BlockVolume=true|false (BETA - 默认值=true)
BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false)
CPUManager=true|false (BETA - 默认值=true)
CRIContainerLogRotation=true|false (BETA - 默认值=true)
CSIBlockVolume=true|false (BETA - 默认值=true)
CSIDriverRegistry=true|false (BETA - 默认值=true)
CSIInlineVolume=true|false (BETA - 默认值=true)
CSIMigration=true|false (ALPHA - 默认值=false)
CSIMigrationAWS=true|false (ALPHA - 默认值=false)
CSIMigrationAzureDisk=true|false (ALPHA - 默认值=false)
CSIMigrationAzureFile=true|false (ALPHA - 默认值=false)
CSIMigrationGCE=true|false (ALPHA - 默认值=false)
CSIMigrationOpenStack=true|false (ALPHA - 默认值=false)
CSINodeInfo=true|false (BETA - 默认值=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
CustomResourceDefaulting=true|false (BETA - 默认值=true)
DevicePlugins=true|false (BETA - 默认值=true)
DryRun=true|false (BETA - 默认值=true)
DynamicAuditing=true|false (ALPHA - 默认值=false)
DynamicKubeletConfig=true|false (BETA - 默认值=true)
EndpointSlice=true|false (ALPHA - 默认值=false)
EphemeralContainers=true|false (ALPHA - 默认值=false)
EvenPodsSpread=true|false (ALPHA - 默认值=false)
ExpandCSIVolumes=true|false (BETA - 默认值=true)
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
ExpandPersistentVolumes=true|false (BETA - 默认值=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)
HPAScaleToZero=true|false (ALPHA - 默认值=false)
HyperVContainer=true|false (ALPHA - 默认值=false)
IPv6DualStack=true|false (ALPHA - 默认值=false)
KubeletPodResources=true|false (BETA - 默认值=true)
LegacyNodeRoleBehavior=true|false (ALPHA - 默认值=true)
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
MountContainers=true|false (ALPHA - 默认值=false)
NodeDisruptionExclusion=true|false (ALPHA - 默认值=false)
NodeLease=true|false (BETA - 默认值=true)
NonPreemptingPriority=true|false (ALPHA - 默认值=false)
PodOverhead=true|false (ALPHA - 默认值=false)
PodShareProcessNamespace=true|false (BETA - 默认值=true)
ProcMountType=true|false (ALPHA - 默认值=false)
QOSReserved=true|false (ALPHA - 默认值=false)
RemainingItemCount=true|false (BETA - 默认值=true)
RemoveSelfLink=true|false (ALPHA - 默认值=false)
RequestManagement=true|false (ALPHA - 默认值=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - 默认值=false)
ResourceQuotaScopeSelectors=true|false (BETA - 默认值=true)
RotateKubeletClientCertificate=true|false (BETA - 默认值=true)
RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
RunAsGroup=true|false (BETA - 默认值=true)
RuntimeClass=true|false (BETA - 默认值=true)
SCTPSupport=true|false (ALPHA - 默认值=false)
ScheduleDaemonSetPods=true|false (BETA - 默认值=true)
ServerSideApply=true|false (BETA - 默认值=true)
ServiceLoadBalancerFinalizer=true|false (BETA - 默认值=true)
ServiceNodeExclusion=true|false (ALPHA - 默认值=false)
StartupProbe=true|false (BETA - 默认值=true)
StorageVersionHash=true|false (BETA - 默认值=true)
StreamingProxyRedirects=true|false (BETA - 默认值=true)
SupportNodePidsLimit=true|false (BETA - 默认值=true)
SupportPodPidsLimit=true|false (BETA - 默认值=true)
Sysctls=true|false (BETA - 默认值=true)
TTLAfterFinished=true|false (ALPHA - 默认值=false)
TaintBasedEvictions=true|false (BETA - 默认值=true)
TaintNodesByCondition=true|false (BETA - 默认值=true)
TokenRequest=true|false (BETA - 默认值=true)
TokenRequestProjection=true|false (BETA - 默认值=true)
TopologyManager=true|false (ALPHA - 默认值=false)
ValidateProxyRedirects=true|false (BETA - 默认值=true)
VolumePVCDataSource=true|false (BETA - 默认值=true)
VolumeSnapshotDataSource=true|false (ALPHA - 默认值=false)
VolumeSubpathEnvExpansion=true|false (BETA - 默认值=true)
WatchBookmark=true|false (BETA - 默认值=true)
WinDSR=true|false (ALPHA - 默认值=false)
WinOverlay=true|false (ALPHA - 默认值=false)
WindowsGMSA=true|false (BETA - 默认值=true)
WindowsRunAsUserName=true|false (ALPHA - 默认值=false) + + + + + + + --hard-pod-affinity-symmetric-weight int32     默认: 1 + + + + + + 弃用: RequiredDuringScheduling 亲和力不是对称的，但是存在与每个 RequiredDuringScheduling 关联性规则相对应的隐式 PreferredDuringScheduling 关联性规则 --hard-pod-affinity-symmetric-weight 代表隐式 PreferredDuringScheduling 关联性规则的权重。权重必须在 0-100 范围内。此选项已移至策略配置文件。 + + + + + -h, --help + + + + + kube-scheduler 帮助命令 + + + + + --http2-max-streams-per-connection int + + + + + 服务器为客户端提供的 HTTP/2 连接最大限制。零表示使用 golang 的默认值。 + + + + + + + --kube-api-burst int32     默认: 100 + + + + + + 弃用: 与 kubernetes apiserver 通信时使用 + + + + + + + --kube-api-content-type string     默认: "application/vnd.kubernetes.protobuf" + + + + + + 弃用: 发送到 apiserver 的请求的内容类型。 + + + + + + + --kube-api-qps float32     默认: 50 + + + + + + 弃用: 与 kubernetes apiserver 通信时要使用的 QPS + + + + + --kubeconfig string + + + + + 弃用: 具有授权和主节点位置信息的 kubeconfig 文件的路径。 + + + + + + + --leader-elect     默认: true + + + + + + 在执行主循环之前，开始领导者选举并选出领导者。为实现高可用性，运行多副本的组件并选出领导者。 + + + + + + + --leader-elect-lease-duration duration     默认: 15s + + + + + + 非领导者候选人在观察到领导者更新后将等待直到试图获得领导但未更新的领导者职位的等待时间。这实际上是领导者在被另一位候选人替代之前可以停止的最大持续时间。该情况仅在启用了领导者选举的情况下才适用。 + + + + + + + --leader-elect-renew-deadline duration     默认: 10s + + + + + + + 领导者尝试在停止领导之前更新领导职位的间隔时间。该时间必须小于或等于租赁期限。仅在启用了领导者选举的情况下才适用。 + + + + + + --leader-elect-resource-lock endpoints     默认: "endpoints" + + + + + + 在领导者选举期间用于锁定的资源对象的类型。支持的选项是端点（默认）和 `configmaps` + + + + + + + --leader-elect-resource-name string     默认: "kube-scheduler" + + + + + + 在领导者选举期间用于锁定的资源对象的名称。 + + + + + + + --leader-elect-resource-namespace string     默认: "kube-system" + + + + + + 在领导者选举期间用于锁定的资源对象的命名空间。 + + + + + + + --leader-elect-retry-period duration     默认: 2s + + + + + + 客户应在尝试获取和更新领导之间等待的时间。仅在启用了领导者选举的情况下才适用。 + + + + + + + --lock-object-name string     默认: "kube-scheduler" + + + + + + 弃用: 定义锁对象的名称。将被删除以便使用 Leader-elect-resource-name + + + + + + + --lock-object-namespace string     默认: "kube-system" + + + + + + 弃用: 定义锁对象的命名空间。将被删除以便使用 leader-elect-resource-namespace。 + + + + + + + --log-backtrace-at traceLocation     默认: :0 + + + + + + 当记录命中行文件：N 时发出堆栈跟踪 + + + + + --log-dir string + + + + + 如果为非空，则在此目录中写入日志文件 + + + + + --log-file string + + + + + 如果为非空，请使用此日志文件 + + + + + + + --log-file-max-size uint     默认: 1800 + + + + + + 定义日志文件可以增长到的最大值。单位为兆字节。如果值为0，则最大文件大小为无限制。 + + + + + + + --log-flush-frequency duration     默认: 5s + + + + + + 两次日志刷新之间的最大秒数 + + + + + + + --logtostderr     默认: true + + + + + + 日志记录到标准错误而不是文件 + + + + + --master string + + + + + Kubernetes API 服务器的地址（覆盖 kubeconfig 中的任何值） + + + + + --policy-config-file string + + + + + 弃用：具有调度程序策略配置的文件。如果未提供 policy ConfigMap 或 --use-legacy-policy-config = true，则使用此文件 + + + + + --policy-configmap string + + + + + 弃用: 包含调度程序策略配置的 ConfigMap 对象的名称。如果 --use-legacy-policy-config = false，则它必须在调度程序初始化之前存在于系统命名空间中。必须将配置作为键为 'policy.cfg' 的 'Data' 映射中元素的值提供 + + + + + + + --policy-configmap-namespace string     默认: "kube-system" + + + + + + 弃用: 策略 ConfigMap 所在的命名空间。如果未提供或为空，则将使用 kube-system 命名空间。 + + + + + + + --port int     默认: 10251 + + + + + + 弃用: 在没有身份验证和授权的情况下不安全地为 HTTP 服务的端口。如果为0，则根本不提供 HTTP。请参见--secure-port。 + + + + + --profiling + + + + + 弃用: 通过 Web 界面主机启用配置文件：port/debug/pprof/ + + + + + --requestheader-allowed-names stringSlice + + + + + 客户端证书通用名称列表允许在 --requestheader-username-headers 指定的头部中提供用户名。如果为空，则允许任何由权威机构 --requestheader-client-ca-file 验证的客户端证书。 + + + + + --requestheader-client-ca-file string + + + + + 在信任 --requestheader-username-headers 指定的头部中的用户名之前用于验证传入请求上的客户端证书的根证书包。警告：通常不依赖于传入请求已经完成的授权。 + + + + + + + --requestheader-extra-headers-prefix stringSlice     默认: [x-remote-extra-] + + + + + + 要检查请求头部前缀列表。建议使用 X-Remote-Extra- + + + + + + + --requestheader-group-headers stringSlice     默认: [x-remote-group] + + + + + + 用于检查组的请求头部列表。建议使用 X-Remote-Group。 + + + + + + + --requestheader-username-headers stringSlice     默认: [x-remote-user] + + + + + + 用于检查用户名的请求头部列表。 X-Remote-User 很常见。 + + + + + + + --scheduler-name string     默认: "default-scheduler" + + + + + + 弃用: 调度程序名称用于根据 Pod 的 "spec.schedulerName" 选择此调度程序将处理的 Pod。 + + + + + + + --secure-port int     默认: 10259 + + + + + + 通过身份验证和授权为 HTTPS 服务的端口。如果为 0，则根本不提供 HTTPS。 + + + + + --skip-headers + + + + + 如果为 true，请在日志消息中避免头部前缀 + + + + + --skip-log-headers + + + + + 如果为true，则在打开日志文件时避免头部 + + + + + + + --stderrthreshold severity     默认: 2 + + + + + + 达到或超过此阈值的日志转到 stderr + + + + + --tls-cert-file string + + + + + 包含默认的 HTTPS x509 证书的文件。（CA证书（如果有）在服务器证书之后并置）。如果启用了 HTTPS 服务，并且未提供 --tls-cert-file 和 --tls-private-key-file，则会为公共地址生成一个自签名证书和密钥，并将其保存到 --cert-dir 指定的目录中。 + + + + + --tls-cipher-suites stringSlice + + + + + 服务器的密码套件列表，以逗号分隔。如果省略，将使用默认的 Go 密码套件。可能的值： + TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA + + + + + --tls-min-version string + + + + + 支持的最低 TLS 版本。可能的值：VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 + + + + + --tls-private-key-file string + + + + + 包含与 --tls-cert-file 匹配的默认 x509 私钥的文件。 + + + + + + + --tls-sni-cert-key namedCertKey     默认: [] + + + + + + 一对 x509 证书和私钥文件路径，可选地后缀为完全限定域名的域模式列表，并可能带有前缀的通配符段。如果未提供域模式，则获取证书名称。非通配符匹配胜过通配符匹配，显式域模式胜过获取名称。 对于多个密钥/证书对，请多次使用 --tls-sni-cert-key。例如: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。 + + + + + --use-legacy-policy-config + + + + + 弃用: 设置为 true 时，调度程序将忽略策略 ConfigMap 并使用策略配置文件 + + + + + -v, --v Level + + + + + 日志级别详细程度的数字 + + + + + --version version[=true] + + + + + 打印版本信息并退出 + + + + + --vmodule moduleSpec + + + + + 以逗号分隔的 pattern = N 设置列表，用于文件过滤的日志记录 + + + + + --write-config-to string + + + + + 如果已设置，请将配置值写入此文件并退出。 + + diff --git a/content/zh/docs/reference/glossary/addons.md b/content/zh/docs/reference/glossary/addons.md new file mode 100644 index 0000000000..c4280561ac --- /dev/null +++ b/content/zh/docs/reference/glossary/addons.md @@ -0,0 +1,37 @@ +--- +title: 附加组件 +id: addons +date: 2019-12-15 +full_link: /docs/concepts/cluster-administration/addons/ +short_description: > + 扩展 Kubernetes 功能的资源。 + +aka: +tags: +- tool +--- + 扩展 Kubernetes 功能的资源。 + + + + + + + +[安装附加组件](/docs/concepts/cluster-administration/addons/) 阐释了更多关于如何在集群内使用附加组件，并列出了一些流行的附加组件。 diff --git a/content/zh/docs/reference/glossary/cidr.md b/content/zh/docs/reference/glossary/cidr.md new file mode 100644 index 0000000000..7e0a97d31e --- /dev/null +++ b/content/zh/docs/reference/glossary/cidr.md @@ -0,0 +1,36 @@ +--- +title: CIDR +id: cidr +date: 2019-11-12 +full_link: +short_description: > + CIDR 是一种描述 IP 地址块的符号，被广泛使用于各种网络配置中。 + +aka: +tags: +- networking +--- +CIDR (无类域间路由) 是一种描述 IP 地址块的符号，被广泛使用于各种网络配置中。 + + + + + + +在 Kubernetes 的上下文中，每个 {{< glossary_tooltip text="节点" term_id="node" >}} 以 CIDR 形式（含起始地址和子网掩码）获得一个 IP 地址段，从而能够为每个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 分配一个独一无二的 IP 地址。虽然其概念最初源自 IPv4，CIDR 已经被扩展为涵盖 IPv6。 diff --git a/content/zh/docs/reference/glossary/index.md b/content/zh/docs/reference/glossary/index.md index 0c13697ff9..d5d593d062 100755 --- a/content/zh/docs/reference/glossary/index.md +++ b/content/zh/docs/reference/glossary/index.md @@ -1,14 +1,11 @@ --- -approvers: -- chenopis -- abiogenesis-now title: 标准化词汇表 layout: glossary noedit: true default_active_tag: fundamental weight: 5 card: - name: 参考 + name: reference weight: 10 title: 词汇表 --- diff --git a/content/zh/docs/reference/kubectl/cheatsheet.md b/content/zh/docs/reference/kubectl/cheatsheet.md index 4ef61cac63..b157fefd71 100644 --- a/content/zh/docs/reference/kubectl/cheatsheet.md +++ b/content/zh/docs/reference/kubectl/cheatsheet.md @@ -1,9 +1,5 @@ --- title: kubectl 备忘单 -reviewers: -- erictune -- krousey -- clove content_type: concept card: name: reference @@ -23,34 +19,42 @@ card: - -也可以看下: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。 + +另见: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。 - 本页面是 `kubectl` 命令的概述。 - - -## kubectl - 备忘单 + +# kubectl - 备忘单 - ## Kubectl 自动补全 ### BASH - +``` + +You can also use a shorthand alias for `kubectl` that also works with completion: +--> ```bash source <(kubectl completion bash) # 在 bash 中设置当前 shell 的自动补全，要先安装 bash-completion 包。 echo "source <(kubectl completion bash)" >> ~/.bashrc # 在您的 bash shell 中永久的添加自动补全 ``` - 您还可以为 `kubectl` 使用一个速记别名，该别名也可以与 completion 一起使用： ```bash @@ -60,25 +64,32 @@ complete -F __start_kubectl k ### ZSH - +``` +--> ```bash source <(kubectl completion zsh) # 在 zsh 中设置当前 shell 的自动补全 echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # 在您的 zsh shell 中永久的添加自动补全 ``` - +detailed config file information. +--> ## Kubectl 上下文和配置 -设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看 [使用 kubeconfig 跨集群授权访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档获取详情配置文件信息。 +设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看 +[使用 kubeconfig 跨集群授权访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +文档获取配置文件详细信息。 - +``` +--> ```bash kubectl config view # 显示合并的 kubeconfig 配置。 @@ -115,36 +128,54 @@ KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view # 获取 e2e 用户的密码 kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' -kubectl config current-context # 展示当前所处的上下文 -kubectl config use-context my-cluster-name # 设置默认的上下文为 my-cluster-name +kubectl config view -o jsonpath='{.users[].name}' # 显示第一个用户 +kubectl config view -o jsonpath='{.users[*].name}' # 获取用户列表 +kubectl config get-contexts # 显示上下文列表 +kubectl config current-context # 展示当前所处的上下文 +kubectl config use-context my-cluster-name # 设置默认的上下文为 my-cluster-name -# 添加新的集群配置到 kubeconf 中，使用 basic auth 进行鉴权 +# 添加新的集群配置到 kubeconf 中，使用 basic auth 进行身份认证 kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword -# 使用特定的用户名和命名空间设置上下文。 +# 在指定上下文中持久性地保存名字空间，供所有后续 kubectl 命令使用 +kubectl config set-context --current --namespace=ggckad-s2 + +# 使用特定的用户名和名字空间设置上下文 kubectl config set-context gce --user=cluster-admin --namespace=foo \ && kubectl config use-context gce + +kubectl config unset users.foo # 删除用户 foo ``` - + +## Apply +`apply` 通过定义 Kubernetes 资源的文件来管理应用。它通过运行 +`kubectl apply` 在集群中创建和更新资源。 +这是在生产中管理 Kubernetes 应用的推荐方法。 +参见 [Kubectl 文档](https://kubectl.docs.kubernetes.io)。 - -## 创建对象 + -Kubernetes 配置可以用 json 或 yaml 定义。可以使用的文件扩展名有 `.yaml`，`.yml` 和 `.json`。 +Kubernetes manifests can be defined in YAML or JSON. The file extension `.yaml`, +`.yml`, and `.json` can be used. +--> +## 创建对象 {#creating-objects} - +``` +--> ```bash kubectl apply -f ./my-manifest.yaml # 创建资源 kubectl apply -f ./my1.yaml -f ./my2.yaml # 使用多个文件创建 -kubectl apply -f ./dir # 从目录下的全部配置文件创建资源 -kubectl apply -f https://git.io/vPieo # 从 url 中创建资源 -kubectl create deployment nginx --image=nginx # 启动单实例 nginx -kubectl explain pods,svc # 获取 pod，svc 配置的文档说明 +kubectl apply -f ./dir # 基于目录下的所有清单文件创建资源 +kubectl apply -f https://git.io/vPieo # 从 URL 中创建资源 +kubectl create deployment nginx --image=nginx # 启动单实例 nginx +kubectl explain pods,svc # 获取 pod 清单的文档说明 -# 从标准输入中的多个 YAML 对象中创建 +# 从标准输入创建多个 YAML 对象 cat < -## 获取和查找资源 + +## 查看和查找资源 - -```bash -# 使用 get 命令获取基本输出 -kubectl get services # 列出当前命名空间下的所有 services -kubectl get pods --all-namespaces # 列出所有命名空间下的全部的 pods -kubectl get pods -o wide # 列出当前命名空间下的全部 pods，有更多的详细信息 -kubectl get deployment my-dep # 列出某个特定的 deployment -kubectl get pods --include-uninitialized # 列出当前命名空间下的全部 pods，包含未初始化的 -kubectl get pod my-pod -o yaml # 获取一个 pod 的 YAML -kubectl get pod my-pod -o yaml --export # 获取一个没有集群特定信息的 YAML -# 使用 describe 命令获取详细输出 +# Compares the current state of the cluster against the state that the cluster would be in if the manifest was applied. +kubectl diff -f ./my-manifest.yaml +``` +--> +```bash +# get 命令的基本输出 +kubectl get services # 列出当前命名空间下的所有 services +kubectl get pods --all-namespaces # 列出所有命名空间下的全部的 Pods +kubectl get pods -o wide # 列出当前命名空间下的全部 Pods，并显示更详细的信息 +kubectl get deployment my-dep # 列出某个特定的 Deployment +kubectl get pods # 列出当前命名空间下的全部 Pods +kubectl get pod my-pod -o yaml # 获取一个 pod 的 YAML + +# describe 命令的详细输出 kubectl describe nodes my-node kubectl describe pods my-pod -kubectl get services --sort-by=.metadata.name # 列出当前命名空间下所有 services，按照名称排序 +# 列出当前名字空间下所有 Services，按名称排序 +kubectl get services --sort-by=.metadata.name -# 列出 pods 按照重启次数进行排序 +# 列出 Pods，按重启次数排序 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' -# 列出测试命名空间中的 Pod，按容量排序 -kubectl get pods -n test --sort-by=.spec.capacity.storage +# 列举所有 PV 持久卷，按容量排序 +kubectl get pv --sort-by=.spec.capacity.storage -# 获取包含 app=cassandra 标签全部 pods 的 version 标签 +# 获取包含 app=cassandra 标签的所有 Pods 的 version 标签 kubectl get pods --selector=app=cassandra -o \ jsonpath='{.items[*].metadata.labels.version}' -# 获取所有工作节点(使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果) +# 获取所有工作节点（使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果） kubectl get node --selector='!node-role.kubernetes.io/master' -# 获取当前命名空间中正在运行的 pods +# 获取当前命名空间中正在运行的 Pods kubectl get pods --field-selector=status.phase=Running -# 获取全部 node 的 ExternalIP 地址 +# 获取全部节点的 ExternalIP 地址 kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' -# 列出属于某个特定 RC 的 pods 的名称 -# "jq" 命令对于 jsonpath 过于复杂的转换非常有用，可以在 https://stedolan.github.io/jq/ 找到它。 +# 列出属于某个特定 RC 的 Pods 的名称 +# 在转换对于 jsonpath 过于复杂的场合，"jq" 命令很有用；可以在 https://stedolan.github.io/jq/ 找到它。 sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?} echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name}) -# 显示所有 Pod 的标签(或任何其他支持标签的 Kubernetes 对象) -# 也可以使用 "jq" -for item in $( kubectl get pod --output=name); do printf "Labels for %s\n" "$item" | grep --color -E '[^/]+$' && kubectl get "$item" --output=json | jq -r -S '.metadata.labels | to_entries | .[] | " \(.key)=\(.value)"' 2>/dev/null; printf "\n"; done - -# 或也可以使用此命令来获取与容器关联的所有标签 +# 显示所有 Pods 的标签（或任何其他支持标签的 Kubernetes 对象） kubectl get pods --show-labels -# 检查哪些节点处于 ready +# 检查哪些节点处于就绪状态 JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \ && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True" -# 列出被一个 pod 使用的全部 secret +# 列出被一个 Pod 使用的全部 Secret kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq -# 列出 events，按照创建时间排序 +# 列举所有 Pods 中初始化容器的容器 ID（containerID） +# Helpful when cleaning up stopped containers, while avoiding removal of initContainers. +kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3 + +# 列出事件（Events），按时间戳排序 kubectl get events --sort-by=.metadata.creationTimestamp + +# 比较当前的集群状态和假定某清单被应用之后的集群状态 +kubectl diff -f ./my-manifest.yaml ``` - + ## 更新资源 - -从版本 1.11 开始，`rolling-update` 已被弃用（参见 [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md))，请使用 `rollout` 代替。 - - +``` +--> ```bash -kubectl set image deployment/frontend www=image:v2 # 滚动更新 "frontend" deployment 的 "www" 容器镜像 -kubectl rollout history deployment/frontend # 检查部署的历史记录，包括版本 +kubectl set image deployment/frontend www=image:v2 # 滚动更新 "frontend" Deployment 的 "www" 容器镜像 +kubectl rollout history deployment/frontend # 检查 Deployment 的历史记录，包括版本 kubectl rollout undo deployment/frontend # 回滚到上次部署版本 kubectl rollout undo deployment/frontend --to-revision=2 # 回滚到特定部署版本 -kubectl rollout status -w deployment/frontend # Watch "frontend" deployment 的滚动升级状态直到完成 +kubectl rollout status -w deployment/frontend # 监视 "frontend" Deployment 的滚动升级状态直到完成 +kubectl rollout restart deployment/frontend # 轮替重启 "frontend" Deployment -# 从 1.11 版本开始弃用 -kubectl rolling-update frontend-v1 -f frontend-v2.json # (弃用) 滚动升级 frontend-v1 的 pods -kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (弃用) 修改资源的名称并更新镜像 -kubectl rolling-update frontend --image=image:v2 # (弃用) 更新 frontend 的 pods 的镜像 -kubectl rolling-update frontend-v1 frontend-v2 --rollback # (弃用) 终止已经进行中的 rollout +cat pod.json | kubectl replace -f - # 通过传入到标准输入的 JSON 来替换 Pod -cat pod.json | kubectl replace -f - # 通过传入到标准输入的 JSON 来替换 pod - -# 强制进行替换，会删除然后再创建资源，会导致服务不可用。 +# 强制替换，删除后重建资源。会导致服务不可用。 kubectl replace --force -f ./pod.json # 为多副本的 nginx 创建服务，使用 80 端口提供服务，连接到容器的 8000 端口。 kubectl expose rc nginx --port=80 --target-port=8000 -# 更新单容器 pod 的镜像标签到 v4 +# 将某单容器 Pod 的镜像版本（标签）更新到 v4 kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f - kubectl label pods my-pod new-label=awesome # 添加标签 kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # 添加注解 -kubectl autoscale deployment foo --min=2 --max=10 # 使 "foo" deployment 自动伸缩容 +kubectl autoscale deployment foo --min=2 --max=10 # 对 "foo" Deployment 自动伸缩容 ``` -## 局部更新资源 +## 部分更新资源 - +``` +--> ```bash -kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 部分更新 node +# 部分更新某节点 +kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' -#更新容器的镜像；spec.containers[*].name 是必须的。因为它是一个合并 key。 +# 更新容器的镜像；spec.containers[*].name 是必须的。因为它是一个合并性质的主键。 kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}' -# 使用带位置数组的 json patch 更新容器的镜像 +# 使用带位置数组的 JSON patch 更新容器的镜像 kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]' -# 使用带位置数组的 json patch 禁用 deployment 的 livenessProbe +# 使用带位置数组的 JSON patch 禁用某 Deployment 的 livenessProbe kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]' # 在带位置数组中添加元素 kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]' ``` - -## 编辑资源 - -在编辑器中编辑任何 API 资源 + +## 编辑资源 + +使用你偏爱的编辑器编辑 API 资源。 + + +``` +--> ```bash -kubectl edit svc/docker-registry # 编辑名为 docker-registry 的 service +kubectl edit svc/docker-registry # 编辑名为 docker-registry 的服务 KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 使用其他编辑器 ``` - + ## 对资源进行伸缩 +``` +--> ```bash kubectl scale --replicas=3 rs/foo # 将名为 'foo' 的副本集伸缩到 3 副本 kubectl scale --replicas=3 -f foo.yaml # 将在 "foo.yaml" 中的特定资源伸缩到 3 个副本 -kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # 如果名为 mysql 的 deployment 的副本当前是 2，那么将它伸缩到 3 -kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 伸缩多个 replication controllers +kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # 如果名为 mysql 的 Deployment 的副本当前是 2，那么将它伸缩到 3 +kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 伸缩多个副本控制器 ``` - + ## 删除资源 +``` +--> ```bash -kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 pod -kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 pod 和 service -kubectl delete pods,services -l name=myLabel # 删除包含 name=myLabel 标签的 pods 和 services -kubectl delete pods,services -l name=myLabel --include-uninitialized # 删除包含 label name=myLabel 标签的 pods 和 services，包括未初始化的 -kubectl -n my-ns delete po,svc --all # 删除在 my-ns 命名空间中全部的 pods 和 services ，包括未初始化的 -# 删除所有与 pattern1 或 pattern2 匹配的 pod +kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 Pod +kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 Pod 和服务 +kubectl delete pods,services -l name=myLabel # 删除包含 name=myLabel 标签的 pods 和服务 +kubectl delete pods,services -l name=myLabel --include-uninitialized # 删除包含 label name=myLabel 标签的 Pods 和服务 +kubectl -n my-ns delete po,svc --all # 删除在 my-ns 名字空间中全部的 Pods 和服务 +# 删除所有与 pattern1 或 pattern2 awk 模式匹配的 Pods kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod ``` - + ## 与运行中的 Pods 进行交互 - +``` +--> ```bash -kubectl logs my-pod # 获取 pod 日志(标准输出) -kubectl logs -l name=myLabel # 获取 pod label name=myLabel 日志(标准输出) -kubectl logs my-pod --previous # 获取上个容器实例的 pod 日志(标准输出) -kubectl logs my-pod -c my-container # 获取 pod 的容器日志 (标准输出, 多容器的场景) -kubectl logs -l name=myLabel -c my-container # 获取 label name=myLabel pod 的容器日志 (标准输出, 多容器的场景) -kubectl logs my-pod -c my-container --previous # 获取 pod 的上个容器实例日志 (标准输出, 多容器的场景) -kubectl logs -f my-pod # 流式输出 pod 的日志 (标准输出) -kubectl logs -f my-pod -c my-container # 流式输出 pod 容器的日志 (标准输出, 多容器的场景) -kubectl logs -f -l name=myLabel --all-containers # 流式输出 label name=myLabel pod 的日志 (标准输出) -kubectl run -i --tty busybox --image=busybox -- sh # 以交互式 shell 运行 pod -kubectl attach my-pod -i # 进入到一个运行中的容器中 +kubectl logs my-pod # 获取 pod 日志（标准输出） +kubectl logs -l name=myLabel # 获取含 name=myLabel 标签的 Pods 的日志（标准输出） +kubectl logs my-pod --previous # 获取上个容器实例的 pod 日志（标准输出） +kubectl logs my-pod -c my-container # 获取 Pod 容器的日志（标准输出, 多容器场景） +kubectl logs -l name=myLabel -c my-container # 获取含 name=myLabel 标签的 Pod 容器日志（标准输出, 多容器场景） +kubectl logs my-pod -c my-container --previous # 获取 Pod 中某容器的上个实例的日志（标准输出, 多容器场景） +kubectl logs -f my-pod # 流式输出 Pod 的日志（标准输出） +kubectl logs -f my-pod -c my-container # 流式输出 Pod 容器的日志（标准输出, 多容器场景） +kubectl logs -f -l name=myLabel --all-containers # 流式输出含 name=myLabel 标签的 Pod 的所有日志（标准输出） +kubectl run -i --tty busybox --image=busybox -- sh # 以交互式 Shell 运行 Pod +kubectl run nginx --image=nginx -n mynamespace # 在指定名字空间中运行 nginx Pod +kubectl run nginx --image=nginx # 运行 ngins Pod 并将其规约写入到名为 pod.yaml 的文件 + --dry-run=client -o yaml > pod.yaml + +kubectl attach my-pod -i # 挂接到一个运行的容器中 kubectl port-forward my-pod 5000:6000 # 在本地计算机上侦听端口 5000 并转发到 my-pod 上的端口 6000 -kubectl exec my-pod -- ls / # 在已有的 pod 中运行命令(单容器的场景) -kubectl exec my-pod -c my-container -- ls / # 在已有的 pod 中运行命令(多容器的场景) -kubectl top pod POD_NAME --containers # 显示给定 pod 和容器的监控数据 +kubectl exec my-pod -- ls / # 在已有的 Pod 中运行命令（单容器场景） +kubectl exec my-pod -c my-container -- ls / # 在已有的 Pod 中运行命令（多容器场景） +kubectl top pod POD_NAME --containers # 显示给定 Pod 和其中容器的监控数据 ``` - + ## 与节点和集群进行交互 - +``` +--> ```bash -kubectl cordon my-node # 设置 my-node 节点为不可调度 -kubectl drain my-node # 对 my-node 节点进行驱逐操作，为节点维护做准备 -kubectl uncordon my-node # 设置 my-node 节点为可以调度 -kubectl top node my-node # 显示给定 node 的指标 -kubectl cluster-info # 显示 master 和 services 的地址 -kubectl cluster-info dump # 将当前集群状态输出到标准输出 +kubectl cordon my-node # 标记 my-node 节点为不可调度 +kubectl drain my-node # 对 my-node 节点进行清空操作，为节点维护做准备 +kubectl uncordon my-node # 标记 my-node 节点为可以调度 +kubectl top node my-node # 显示给定节点的度量值 +kubectl cluster-info # 显示主控节点和服务的地址 +kubectl cluster-info dump # 将当前集群状态转储到标准输出 kubectl cluster-info dump --output-directory=/path/to/cluster-state # 将当前集群状态输出到 /path/to/cluster-state -# 如果已存在具有该键和效果的污点，则其值将按指定替换 +# 如果已存在具有指定键和效果的污点，则替换其值为指定值 kubectl taint nodes foo dedicated=special-user:NoSchedule ``` - + ### 资源类型 - -列出全部支持的资源类型和它们的简称, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), 无论它们是否是 [namespaced](/docs/concepts/overview/working-with-objects/namespaces), [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)。 + +列出所支持的全部资源类型和它们的简称、[API 组](/docs/concepts/overview/kubernetes-api/#api-groups), 是否是[名字空间作用域](/docs/concepts/overview/working-with-objects/namespaces) 和 [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)。 ```bash kubectl api-resources ``` - + 用于探索 API 资源的其他操作： - +``` +--> ```bash -kubectl api-resources --namespaced=true # 所有在命名空间中的资源 -kubectl api-resources --namespaced=false # 所有不在命名空间中的资源 -kubectl api-resources -o name # 输出简单的所有资源（只是资源名称） -kubectl api-resources -o wide # 具有扩展（又称 "wide"）输出的所有资源 +kubectl api-resources --namespaced=true # 所有命名空间作用域的资源 +kubectl api-resources --namespaced=false # 所有非命名空间作用域的资源 +kubectl api-resources -o name # 用简单格式列举所有资源（仅显示资源名称） +kubectl api-resources -o wide # 用扩展格式列举所有资源（又称 "wide" 格式） kubectl api-resources --verbs=list,get # 支持 "list" 和 "get" 请求动词的所有资源 kubectl api-resources --api-group=extensions # "extensions" API 组中的所有资源 ``` - + ### 格式化输出 - 要以特定格式将详细信息输出到终端窗口，可以将 `-o` 或 `--output` 参数添加到支持的 `kubectl` 命令。 - -输出格式 | 描述 +`-o=yaml` | Output a YAML formatted API object +--> +输出格式 | 描述 --------------| ----------- -`-o=custom-columns=` | 使用逗号分隔的自定义列列表打印表格 +`-o=custom-columns=` | 使用逗号分隔的自定义列来打印表格 `-o=custom-columns-file=` | 使用 `` 文件中的自定义列模板打印表格 `-o=json` | 输出 JSON 格式的 API 对象 `-o=jsonpath=