diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index c7040f7fa8..25b0ff4753 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -6,6 +6,8 @@ your pull request. The description should explain what will change, and why. + PLEASE title the FIRST commit appropriately, so that if you squash all + your commits into one, the combined commit message makes sense. For overall help on editing and submitting pull requests, visit: https://kubernetes.io/docs/contribute/start/#improve-existing-content diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index cbaeb22d00..e02287ac56 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -182,6 +182,7 @@ aliases: - idealhack - markthink - SataQiu + - tanjunchen - tengqm - xiangpengzhao - xichengliudui @@ -222,3 +223,13 @@ aliases: - mfilocha - nvtkaszpir - kpucynski + sig-docs-uk-owners: # Admins for Ukrainian content + - anastyakulyk + - butuzov + - MaxymVlasov + sig-docs-uk-reviews: # PR reviews for Ukrainian content + - anastyakulyk + - butuzov + - idvoretskyi + - MaxymVlasov + - Potapy4 diff --git a/README-uk.md b/README-uk.md new file mode 100644 index 0000000000..c524d4b293 --- /dev/null +++ b/README-uk.md @@ -0,0 +1,71 @@ +# Документація Kubernetes + +[![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](https://kubernetes.io/). Ми щасливі, що ви хочете зробити свій внесок! + +## Внесок у документацію + +Ви можете створити копію цього репозиторія у своєму акаунті на GitHub, натиснувши на кнопку **Fork**, що розташована справа зверху. Ця копія називатиметься *fork* (відгалуження). Зробіть будь-які необхідні зміни у своєму відгалуженні. Коли ви будете готові надіслати їх нам, перейдіть до свого відгалуження і створіть новий pull request, щоб сповістити нас. + +Після того, як ви створили pull request, рецензент Kubernetes зобов’язується надати вам по ньому чіткий і конструктивний коментар. **Ваш обов’язок як творця pull request - відкоригувати його відповідно до зауважень рецензента Kubernetes.** Також, зауважте: може статися так, що ви отримаєте коментарі від декількох рецензентів Kubernetes або від іншого рецензента, ніж той, якого вам було призначено від початку. Крім того, за потреби один із ваших рецензентів може запросити технічну перевірку від одного з [технічних рецензентів Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers). Рецензенти намагатимуться відреагувати вчасно, проте час відповіді може відрізнятися в залежності від обставин. + +Більше інформації про внесок у документацію 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/docs/contribute/localization/) + +## Запуск сайту локально за допомогою Docker + +Для локального запуску сайту Kubernetes рекомендовано запустити спеціальний [Docker](https://docker.com)-образ, що містить генератор статичних сайтів [Hugo](https://gohugo.io). + +> Якщо ви працюєте під Windows, вам знадобиться ще декілька інструментів, які можна встановити за допомогою [Chocolatey](https://chocolatey.org). `choco install make` + +> Якщо ви вважаєте кращим запустити сайт локально без використання Docker, дивіться пункт нижче [Запуск сайту локально за допомогою Hugo](#запуск-сайту-локально-зa-допомогою-hugo). + +Якщо у вас вже [запущений](https://www.docker.com/get-started) Docker, зберіть локальний Docker-образ `kubernetes-hugo`: + +```bash +make docker-image +``` + +Після того, як образ зібрано, ви можете запустити сайт локально: + +```bash +make docker-serve +``` + +Відкрийте у своєму браузері http://localhost:1313, щоб побачити сайт. По мірі того, як ви змінюєте вихідний код, Hugo актуалізує сайт відповідно до внесених змін і оновлює сторінку у браузері. + +## Запуск сайту локально зa допомогою Hugo + +Для інструкцій по установці Hugo дивіться [офіційну документацію](https://gohugo.io/getting-started/installing/). Обов’язково встановіть розширену версію Hugo, яка позначена змінною оточення `HUGO_VERSION` у файлі [`netlify.toml`](netlify.toml#L9). + +Після установки Hugo, запустіть сайт локально командою: + +```bash +make serve +``` + +Команда запустить локальний Hugo-сервер на порту 1313. Відкрийте у своєму браузері http://localhost:1313, щоб побачити сайт. По мірі того, як ви змінюєте вихідний код, Hugo актуалізує сайт відповідно до внесених змін і оновлює сторінку у браузері. + +## Спільнота, обговорення, внесок і підтримка + +Дізнайтеся, як долучитися до спільноти Kubernetes на [сторінці спільноти](http://kubernetes.io/community/). + +Для зв’язку із супроводжуючими проекту скористайтеся: + +- [Slack](https://kubernetes.slack.com/messages/sig-docs) +- [Поштова розсилка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) + +### Кодекс поведінки + +Участь у спільноті Kubernetes визначається правилами [Кодексу поведінки спільноти Kubernetes](code-of-conduct.md). + +## Дякуємо! + +Долучення до спільноти - запорука успішного розвитку Kubernetes. Ми цінуємо ваш внесок у наш сайт і документацію! diff --git a/README.md b/README.md index 8be2ae4249..ebd864bdc8 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,7 @@ For more information about contributing to the Kubernetes documentation, see: |[Indonesian README](README-id.md)|[Chinese README](README-zh.md)| |[Japanese README](README-ja.md)|[Vietnamese README](README-vi.md)| |[Russian README](README-ru.md)|[Italian README](README-it.md)| -|[Polish README](README-pl.md)|| +|[Polish README](README-pl.md)|[Ukrainian README](README-uk.md)| ||| ## Running the website locally using Docker diff --git a/config.toml b/config.toml index f8da1f8938..2150f633b6 100644 --- a/config.toml +++ b/config.toml @@ -298,3 +298,15 @@ contentDir = "content/pl" time_format_blog = "01.02.2006" # A list of language codes to look for untranslated content, ordered from left to right. language_alternatives = ["en"] + +[languages.uk] +title = "Kubernetes" +description = "Довершена система оркестрації контейнерів" +languageName = "Українська" +weight = 14 +contentDir = "content/uk" + +[languages.uk.params] +time_format_blog = "02.01.2006" +# A list of language codes to look for untranslated content, ordered from left to right. +language_alternatives = ["en"] diff --git a/content/en/blog/_posts/2020-04-02-Improvements-to-the-Ingress-API-in-Kubernetes-1.18.md b/content/en/blog/_posts/2020-04-02-Improvements-to-the-Ingress-API-in-Kubernetes-1.18.md index 713c9821ce..6fdb291c5b 100644 --- a/content/en/blog/_posts/2020-04-02-Improvements-to-the-Ingress-API-in-Kubernetes-1.18.md +++ b/content/en/blog/_posts/2020-04-02-Improvements-to-the-Ingress-API-in-Kubernetes-1.18.md @@ -24,17 +24,17 @@ The new concept of a path type allows you to specify how a path should be matche The Ingress resource was designed with simplicity in mind, providing a simple set of fields that would be applicable in all use cases. Over time, as use cases evolved, implementations began to rely on a long list of custom annotations for further configuration. The new `IngressClass` resource provides a way to replace some of those annotations. Each `IngressClass` specifies which controller should implement Ingresses of the class and can reference a custom resource with additional parameters. -``` -apiVersion: networking.k8s.io/v1beta1 -kind: IngressClass +```yaml +apiVersion: "networking.k8s.io/v1beta1" +kind: "IngressClass" metadata: - name: external-lb + name: "external-lb" spec: - controller: example.com/ingress-controller + controller: "example.com/ingress-controller" parameters: - apiGroup: k8s.example.com/v1alpha - kind: IngressParameters - name: external-lb + apiGroup: "k8s.example.com/v1alpha" + kind: "IngressParameters" + name: "external-lb" ``` ### Specifying the Class of an Ingress @@ -51,30 +51,30 @@ IngressClass resource will ensure that new Ingresses without an `ingressClassNam ## Support for Hostname Wildcards Many Ingress providers have supported wildcard hostname matching like `*.foo.com` matching `app1.foo.com`, but until now the spec assumed an exact FQDN match of the host. Hosts can now be precise matches (for example “`foo.bar.com`”) or a wildcard (for example “`*.foo.com`”). Precise matches require that the http host header matches the Host setting. Wildcard matches require the http host header is equal to the suffix of the wildcard rule. -| Host | Host header | Match? | -| ------------- |-------------| -----| -| `*.foo.com` | `*.foo.com` | Matches based on shared suffix | -| `*.foo.com` | `*.foo.com` | No match, wildcard only covers a single DNS label | -| `*.foo.com` | `foo.com` | No match, wildcard only covers a single DNS label | +| Host | Host header | Match? | +| ----------- |-------------------| --------------------------------------------------| +| `*.foo.com` | `bar.foo.com` | Matches based on shared suffix | +| `*.foo.com` | `baz.bar.foo.com` | No match, wildcard only covers a single DNS label | +| `*.foo.com` | `foo.com` | No match, wildcard only covers a single DNS label | ### Putting it All Together These new Ingress features allow for much more configurability. Here’s an example of an Ingress that makes use of pathType, `ingressClassName`, and a hostname wildcard: -``` -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress +```yaml +apiVersion: "networking.k8s.io/v1beta1" +kind: "Ingress" metadata: - name: example-ingress + name: "example-ingress" spec: - ingressClassName: external-lb + ingressClassName: "external-lb" rules: - - host: *.example.com + - host: "*.example.com" http: paths: - - path: /example - pathType: Prefix + - path: "/example" + pathType: "Prefix" backend: - serviceName: example-service + serviceName: "example-service" servicePort: 80 ``` @@ -84,4 +84,4 @@ Since these features are new in Kubernetes 1.18, each Ingress controller impleme ## The Future of Ingress The Ingress API is on pace to graduate from beta to a stable API in Kubernetes 1.19. It will continue to provide a simple way to manage inbound network traffic for Kubernetes workloads. This API has intentionally been kept simple and lightweight, but there has been a desire for greater configurability for more advanced use cases. -Work is currently underway on a new highly configurable set of APIs that will provide an alternative to Ingress in the future. These APIs are being referred to as the new “Service APIs”. They are not intended to replace any existing APIs, but instead provide a more configurable alternative for complex use cases. For more information, check out the [Service APIs repo on GitHub](http://github.com/kubernetes-sigs/service-apis). \ No newline at end of file +Work is currently underway on a new highly configurable set of APIs that will provide an alternative to Ingress in the future. These APIs are being referred to as the new “Service APIs”. They are not intended to replace any existing APIs, but instead provide a more configurable alternative for complex use cases. For more information, check out the [Service APIs repo on GitHub](http://github.com/kubernetes-sigs/service-apis). diff --git a/content/en/blog/_posts/2020-04-06-API-Priority-and-Fairness-Alpha.md b/content/en/blog/_posts/2020-04-06-API-Priority-and-Fairness-Alpha.md new file mode 100644 index 0000000000..c4c983c543 --- /dev/null +++ b/content/en/blog/_posts/2020-04-06-API-Priority-and-Fairness-Alpha.md @@ -0,0 +1,68 @@ +--- +layout: blog +title: "API Priority and Fairness Alpha" +date: 2020-04-06 +slug: kubernetes-1-18-feature-api-priority-and-fairness-alpha +--- + +**Authors:** Min Kim (Ant Financial), Mike Spreitzer (IBM), Daniel Smith (Google) + +This blog describes “API Priority And Fairness”, a new alpha feature in Kubernetes 1.18. API Priority And Fairness permits cluster administrators to divide the concurrency of the control plane into different weighted priority levels. Every request arriving at a kube-apiserver will be categorized into one of the priority levels and get its fair share of the control plane’s throughput. + +## What problem does this solve? +Today the apiserver has a simple mechanism for protecting itself against CPU and memory overloads: max-in-flight limits for mutating and for readonly requests. Apart from the distinction between mutating and readonly, no other distinctions are made among requests; consequently, there can be undesirable scenarios where one subset of the requests crowds out other requests. + +In short, it is far too easy for Kubernetes workloads to accidentally DoS the apiservers, causing other important traffic--like system controllers or leader elections---to fail intermittently. In the worst cases, a few broken nodes or controllers can push a busy cluster over the edge, turning a local problem into a control plane outage. + +## How do we solve the problem? +The new feature “API Priority and Fairness” is about generalizing the existing max-in-flight request handler in each apiserver, to make the behavior more intelligent and configurable. The overall approach is as follows. + +1. Each request is matched by a _Flow Schema_. The Flow Schema states the Priority Level for requests that match it, and assigns a “flow identifier” to these requests. Flow identifiers are how the system determines whether requests are from the same source or not. +2. Priority Levels may be configured to behave in several ways. Each Priority Level gets its own isolated concurrency pool. Priority levels also introduce the concept of queuing requests that cannot be serviced immediately. +3. To prevent any one user or namespace from monopolizing a Priority Level, they may be configured to have multiple queues. [“Shuffle Sharding”](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/#What_is_shuffle_sharding.3F) is used to assign each flow of requests to a subset of the queues. +4. Finally, when there is capacity to service a request, a [“Fair Queuing”](https://en.wikipedia.org/wiki/Fair_queuing) algorithm is used to select the next request. Within each priority level the queues compete with even fairness. + +Early results have been very promising! Take a look at this [analysis](https://github.com/kubernetes/kubernetes/pull/88177#issuecomment-588945806). + +## How do I try this out? +You are required to prepare the following things in order to try out the feature: + +* Download and install a kubectl greater than v1.18.0 version +* Enabling the new API groups with the command line flag `--runtime-config="flowcontrol.apiserver.k8s.io/v1alpha1=true"` on the kube-apiservers +* Switch on the feature gate with the command line flag `--feature-gates=APIPriorityAndFairness=true` on the kube-apiservers + +After successfully starting your kube-apiservers, you will see a few default FlowSchema and PriorityLevelConfiguration resources in the cluster. These default configurations are designed for a general protection and traffic management for your cluster. +You can examine and customize the default configuration by running the usual tools, e.g.: + +* `kubectl get flowschemas` +* `kubectl get prioritylevelconfigurations` + + +## How does this work under the hood? +Upon arrival at the handler, a request is assigned to exactly one priority level and exactly one flow within that priority level. Hence understanding how FlowSchema and PriorityLevelConfiguration works will be helping you manage the request traffic going through your kube-apiservers. + +* FlowSchema: FlowSchema will identify a PriorityLevelConfiguration object and the way to compute the request’s “flow identifier”. Currently we support matching requests according to: the identity making the request, the verb, and the target object. The identity can match in terms of: a username, a user group name, or a ServiceAccount. And as for the target objects, we can match by apiGroup, resource[/subresource], and namespace. + * The flow identifier is used for shuffle sharding, so it’s important that requests have the same flow identifier if they are from the same source! We like to consider scenarios with “elephants” (which send many/heavy requests) vs “mice” (which send few/light requests): it is important to make sure the elephant’s requests all get the same flow identifier, otherwise they will look like many different mice to the system! + * See the API Documentation [here](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io)! + +* PriorityLevelConfiguration: Defines a priority level. + * For apiserver self requests, and any reentrant traffic (e.g., admission webhooks which themselves make API requests), a Priority Level can be marked “exempt”, which means that no queueing or limiting of any sort is done. This is to prevent priority inversions. + * Each non-exempt Priority Level is configured with a number of "concurrency shares" and gets an isolated pool of concurrency to use. Requests of that Priority Level run in that pool when it is not full, never anywhere else. Each apiserver is configured with a total concurrency limit (taken to be the sum of the old limits on mutating and readonly requests), and this is then divided among the Priority Levels in proportion to their concurrency shares. + * A non-exempt Priority Level may select a number of queues and a "hand size" to use for the shuffle sharding. Shuffle sharding maps flows to queues in a way that is better than consistent hashing. A given flow has access to a small collection of queues, and for each incoming request the shortest queue is chosen. When a Priority Level has queues, it also sets a limit on queue length. There is also a limit placed on how long a request can wait in its queue; this is a fixed fraction of the apiserver's request timeout. A request that cannot be executed and cannot be queued (any longer) is rejected. + * Alternatively, a non-exempt Priority Level may select immediate rejection instead of waiting in a queue. + * See the [API documentation](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io) for this feature. + +## What’s missing? When will there be a beta? +We’re already planning a few enhancements based on alpha and there will be more as users send feedback to our community. Here’s a list of them: + +* Traffic management for WATCH and EXEC requests +* Adjusting and improving the default set of FlowSchema/PriorityLevelConfiguration +* Enhancing observability on how this feature works +* Join the discussion [here](https://github.com/kubernetes/enhancements/pull/1632) + +Possibly treat LIST requests differently depending on an estimate of how big their result will be. + +## How can I get involved? +As always! Reach us on slack [#sig-api-machinery](https://kubernetes.slack.com/messages/sig-api-machinery), or through the [mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-api-machinery). We have lots of exciting features to build and can use all sorts of help. + +Many thanks to the contributors that have gotten this feature this far: Aaron Prindle, Daniel Smith, Jonathan Tomer, Mike Spreitzer, Min Kim, Bruce Ma, Yu Liao, Mengyi Zhou! diff --git a/content/en/docs/concepts/architecture/master-node-communication.md b/content/en/docs/concepts/architecture/master-node-communication.md index 8a4493e49b..ff536d160b 100644 --- a/content/en/docs/concepts/architecture/master-node-communication.md +++ b/content/en/docs/concepts/architecture/master-node-communication.md @@ -97,13 +97,28 @@ public networks. ### SSH Tunnels -Kubernetes supports SSH tunnels to protect the Master -> Cluster communication +Kubernetes supports SSH tunnels to protect the Master → Cluster communication paths. In this configuration, the apiserver initiates an SSH tunnel to each node in the cluster (connecting to the ssh server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or service through the tunnel. This tunnel ensures that the traffic is not exposed outside of the network in which the nodes are running. -SSH tunnels are currently deprecated so you shouldn't opt to use them unless you know what you are doing. A replacement for this communication channel is being designed. +SSH tunnels are currently deprecated so you shouldn't opt to use them unless you +know what you are doing. The Konnectivity service is a replacement for this +communication channel. + +### Konnectivity service +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +As a replacement to the SSH tunnels, the Konnectivity service provides TCP +level proxy for the Master → Cluster communication. The Konnectivity consists of +two parts, the Konnectivity server and the Konnectivity agents, running in the +Master network and the Cluster network respectively. The Konnectivity agents +initiate connections to the Konnectivity server and maintain the connections. +All Master → Cluster traffic then goes through these connections. + +See [Konnectivity Service Setup](/docs/tasks/setup-konnectivity/) on how to set +it up in your cluster. {{% /capture %}} diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index fd8227bfa0..6540a05e8f 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -18,12 +18,12 @@ potentially crashing the API server, but these flags are not enough to ensure that the most important requests get through in a period of high traffic. The API Priority and Fairness feature (APF) is an alternative that improves upon -aforementioned max-inflight limitations. APF classifies -and isolates requests in a more fine-grained way. It also introduces +aforementioned max-inflight limitations. APF classifies +and isolates requests in a more fine-grained way. It also introduces a limited amount of queuing, so that no requests are rejected in cases of very brief bursts. Requests are dispatched from queues using a -fair queuing technique so that, for example, a poorly-behaved {{< -glossary_tooltip text="controller" term_id="controller" >}}) need not +fair queuing technique so that, for example, a poorly-behaved +{{< glossary_tooltip text="controller" term_id="controller" >}} need not starve others (even at the same priority level). {{< caution >}} diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md index eedafce1a3..1f93b54d45 100644 --- a/content/en/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md @@ -427,12 +427,20 @@ We'll guide you through how to create and update applications with Deployments. Let's say you were running version 1.14.2 of nginx: ```shell -kubectl run my-nginx --image=nginx:1.14.2 --replicas=3 +kubectl create deployment my-nginx --image=nginx:1.14.2 ``` ```shell deployment.apps/my-nginx created ``` +with 3 replicas (so the old and new revisions can coexist): +```shell +kubectl scale deployment my-nginx --current-replicas=1 --replicas=3 +``` +``` +deployment.apps/my-nginx scaled +``` + To update to version 1.16.1, simply change `.spec.template.spec.containers[0].image` from `nginx:1.14.2` to `nginx:1.16.1`, with the kubectl commands we learned above. ```shell diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md index 3e47d1f0b7..e3ec1ee12f 100644 --- a/content/en/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md @@ -9,7 +9,7 @@ weight: 70 {{% capture overview %}} -{{< feature-state for_k8s_version="1.14" state="stable" >}} +{{< feature-state for_k8s_version="v1.14" state="stable" >}} [Pods](/docs/user-guide/pods) can have _priority_. Priority indicates the importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the @@ -145,7 +145,7 @@ description: "This priority class should be used for XYZ service pods only." ## Non-preempting PriorityClass {#non-preempting-priority-class} -{{< feature-state for_k8s_version="1.15" state="alpha" >}} +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} Pods with `PreemptionPolicy: Never` will be placed in the scheduling queue ahead of lower-priority pods, diff --git a/content/en/docs/concepts/configuration/resource-bin-packing.md b/content/en/docs/concepts/configuration/resource-bin-packing.md index 207460d7ad..eac4a37655 100644 --- a/content/en/docs/concepts/configuration/resource-bin-packing.md +++ b/content/en/docs/concepts/configuration/resource-bin-packing.md @@ -10,7 +10,7 @@ weight: 10 {{% capture overview %}} -{{< feature-state for_k8s_version="1.16" state="alpha" >}} +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} The kube-scheduler can be configured to enable bin packing of resources along with extended resources using `RequestedToCapacityRatioResourceAllocation` priority function. Priority functions can be used to fine-tune the kube-scheduler as per custom needs. diff --git a/content/en/docs/concepts/configuration/taint-and-toleration.md b/content/en/docs/concepts/configuration/taint-and-toleration.md index 2026390eff..0ee6d63f21 100644 --- a/content/en/docs/concepts/configuration/taint-and-toleration.md +++ b/content/en/docs/concepts/configuration/taint-and-toleration.md @@ -202,7 +202,7 @@ when there are node problems, which is described in the next section. ## Taint based Evictions -{{< feature-state for_k8s_version="1.18" state="stable" >}} +{{< feature-state for_k8s_version="v1.18" state="stable" >}} Earlier we mentioned the `NoExecute` taint effect, which affects pods that are already running on the node as follows diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md index d48c2db88a..8ae3111323 100644 --- a/content/en/docs/concepts/policy/resource-quotas.md +++ b/content/en/docs/concepts/policy/resource-quotas.md @@ -197,7 +197,7 @@ The `Terminating`, `NotTerminating`, and `NotBestEffort` scopes restrict a quota ### Resource Quota Per PriorityClass -{{< feature-state for_k8s_version="1.12" state="beta" >}} +{{< feature-state for_k8s_version="v1.12" state="beta" >}} Pods can be created at a specific [priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority). You can control a pod's consumption of system resources based on a pod's priority, by using the `scopeSelector` diff --git a/content/en/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/en/docs/concepts/scheduling/scheduler-perf-tuning.md index cfa5a4521c..245963ac88 100644 --- a/content/en/docs/concepts/scheduling/scheduler-perf-tuning.md +++ b/content/en/docs/concepts/scheduling/scheduler-perf-tuning.md @@ -8,7 +8,7 @@ weight: 70 {{% capture overview %}} -{{< feature-state for_k8s_version="1.14" state="beta" >}} +{{< feature-state for_k8s_version="v1.14" state="beta" >}} [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler) is the Kubernetes default scheduler. It is responsible for placement of Pods diff --git a/content/en/docs/concepts/scheduling/scheduling-framework.md b/content/en/docs/concepts/scheduling/scheduling-framework.md index ddc2225cac..0d4c633391 100644 --- a/content/en/docs/concepts/scheduling/scheduling-framework.md +++ b/content/en/docs/concepts/scheduling/scheduling-framework.md @@ -8,7 +8,7 @@ weight: 60 {{% capture overview %}} -{{< feature-state for_k8s_version="1.15" state="alpha" >}} +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} The scheduling framework is a pluggable architecture for Kubernetes Scheduler that makes scheduler customizations easy. It adds a new set of "plugin" APIs to diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index a62faf1e0f..65891d3ccb 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -534,6 +534,25 @@ to just expose one or more nodes' IPs directly. Note that this Service is visible as `:spec.ports[*].nodePort` and `.spec.clusterIP:spec.ports[*].port`. (If the `--nodeport-addresses` flag in kube-proxy is set, would be filtered NodeIP(s).) +For example: +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + type: NodePort + selector: + app: MyApp + ports: + # By default and for convenience, the `targetPort` is set to the same value as the `port` field. + - port: 80 + targetPort: 80 + # Optional field + # By default and for convenience, the Kubernetes control plane will allocate a port from a range (default: 30000-32767) + nodePort: 30007 +``` + ### Type LoadBalancer {#loadbalancer} On cloud providers which support external load balancers, setting the `type` diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 99c21105a9..3d444584ee 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -28,9 +28,9 @@ This document describes the current state of _persistent volumes_ in Kubernetes. Managing storage is a distinct problem from managing compute instances. The PersistentVolume subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. To do this, we introduce two new API resources: PersistentVolume and PersistentVolumeClaim. -A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [Storage Classes](/docs/concepts/storage/storage-classes/). It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system. +A _PersistentVolume_ (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [Storage Classes](/docs/concepts/storage/storage-classes/). It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system. -A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted once read/write or many times read-only). +A _PersistentVolumeClaim_ (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted once read/write or many times read-only). While PersistentVolumeClaims allow a user to consume abstract storage resources, it is common that users need PersistentVolumes with varying properties, such as performance, for different problems. Cluster administrators need to be able to offer a variety of PersistentVolumes that differ in more ways than just size and access modes, without exposing users to the details of how those volumes are implemented. For these needs, there is the _StorageClass_ resource. diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index 9d6fc1c3c5..ab1233e09c 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -185,7 +185,7 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent * All of the above * [Local](#local) -{{< feature-state state="stable" for_k8s_version="1.17" >}} +{{< feature-state state="stable" for_k8s_version="v1.17" >}} [CSI volumes](/docs/concepts/storage/volumes/#csi) are also supported with dynamic provisioning and pre-created PVs, but you'll need to look at the documentation for a specific CSI driver to see its supported topology keys and examples. @@ -410,7 +410,7 @@ parameters: round-robin-ed across all active zones where Kubernetes cluster has a node. {{< note >}} -{{< feature-state state="deprecated" for_k8s_version="1.11" >}} +{{< feature-state state="deprecated" for_k8s_version="v1.11" >}} This internal provisioner of OpenStack is deprecated. Please use [the external cloud provider for OpenStack](https://github.com/kubernetes/cloud-provider-openstack). {{< /note >}} @@ -813,10 +813,10 @@ volumeBindingMode: WaitForFirstConsumer ``` Local volumes do not currently support dynamic provisioning, however a StorageClass -should still be created to delay volume binding until pod scheduling. This is +should still be created to delay volume binding until Pod scheduling. This is specified by the `WaitForFirstConsumer` volume binding mode. -Delaying volume binding allows the scheduler to consider all of a pod's +Delaying volume binding allows the scheduler to consider all of a Pod's scheduling constraints when choosing an appropriate PersistentVolume for a PersistentVolumeClaim. diff --git a/content/en/docs/concepts/storage/volume-snapshots.md b/content/en/docs/concepts/storage/volume-snapshots.md index d29f5b52bf..dc8d5749d9 100644 --- a/content/en/docs/concepts/storage/volume-snapshots.md +++ b/content/en/docs/concepts/storage/volume-snapshots.md @@ -13,7 +13,7 @@ weight: 20 {{% capture overview %}} -{{< feature-state for_k8s_version="1.17" state="beta" >}} +{{< feature-state for_k8s_version="v1.17" state="beta" >}} In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/). {{% /capture %}} diff --git a/content/en/docs/concepts/workloads/pods/init-containers.md b/content/en/docs/concepts/workloads/pods/init-containers.md index 14e7054a86..2ecbdd702a 100644 --- a/content/en/docs/concepts/workloads/pods/init-containers.md +++ b/content/en/docs/concepts/workloads/pods/init-containers.md @@ -71,8 +71,8 @@ have some advantages for start-up related code: a mechanism to block or delay app container startup until a set of preconditions are met. Once preconditions are met, all of the app containers in a Pod can start in parallel. * Init containers can securely run utilities or custom code that would otherwise make an app - container image less secure. By keeping unnecessary tools separate you can limit the attack - surface of your app container image. + container image less secure. By keeping unnecessary tools separate you can limit the attack + surface of your app container image. ### Examples @@ -245,8 +245,11 @@ init containers. [What's next](#what-s-next) contains a link to a more detailed ## Detailed behavior -During the startup of a Pod, each init container starts in order, after the -network and volumes are initialized. Each container must exit successfully before +During Pod startup, the kubelet delays running init containers until the networking +and storage are ready. Then the kubelet runs the Pod's init containers in the order +they appear in the Pod's spec. + +Each init container must exit successfully before the next container starts. If a container fails to start due to the runtime or exits with failure, it is retried according to the Pod `restartPolicy`. However, if the Pod `restartPolicy` is set to Always, the init containers use diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 35a373473b..1c68ba4ebd 100644 --- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -18,7 +18,7 @@ You can use _topology spread constraints_ to control how {{< glossary_tooltip te ### Enable Feature Gate -The `EvenPodsSpread` [feature gate] (/docs/reference/command-line-tools-reference/feature-gates/) +The `EvenPodsSpread` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) must be enabled for the {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} **and** {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}. @@ -62,10 +62,10 @@ metadata: name: mypod spec: topologySpreadConstraints: - - maxSkew: - topologyKey: - whenUnsatisfiable: - labelSelector: + - maxSkew: + topologyKey: + whenUnsatisfiable: + labelSelector: ``` You can define one or multiple `topologySpreadConstraint` to instruct the kube-scheduler how to place each incoming Pod in relation to the existing Pods across your cluster. The fields are: @@ -73,8 +73,8 @@ You can define one or multiple `topologySpreadConstraint` to instruct the kube-s - **maxSkew** describes the degree to which Pods may be unevenly distributed. It's the maximum permitted difference between the number of matching Pods in any two topology domains of a given topology type. It must be greater than zero. - **topologyKey** is the key of node labels. If two Nodes are labelled with this key and have identical values for that label, the scheduler treats both Nodes as being in the same topology. The scheduler tries to place a balanced number of Pods into each topology domain. - **whenUnsatisfiable** indicates how to deal with a Pod if it doesn't satisfy the spread constraint: - - `DoNotSchedule` (default) tells the scheduler not to schedule it. - - `ScheduleAnyway` tells the scheduler to still schedule it while prioritizing nodes that minimize the skew. + - `DoNotSchedule` (default) tells the scheduler not to schedule it. + - `ScheduleAnyway` tells the scheduler to still schedule it while prioritizing nodes that minimize the skew. - **labelSelector** is used to find matching Pods. Pods that match this label selector are counted to determine the number of Pods in their corresponding topology domain. See [Label Selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) for more details. You can read more about this field by running `kubectl explain Pod.spec.topologySpreadConstraints`. @@ -160,8 +160,9 @@ There are some implicit conventions worth noting here: - Only the Pods holding the same namespace as the incoming Pod can be matching candidates. - Nodes without `topologySpreadConstraints[*].topologyKey` present will be bypassed. It implies that: - 1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incomingPod will be scheduled into "zoneA". - 2. the incoming Pod has no chances to be scheduled onto this kind of nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone". + + 1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incomingPod will be scheduled into "zoneA". + 2. the incoming Pod has no chances to be scheduled onto this kind of nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone". - Be aware of what will happen if the incomingPod’s `topologySpreadConstraints[*].labelSelector` doesn’t match its own labels. In the above example, if we remove the incoming Pod’s labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it’s still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload’s `topologySpreadConstraints[*].labelSelector` to match its own labels. @@ -182,7 +183,7 @@ There are some implicit conventions worth noting here: and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected. {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}} - + ### Cluster-level default constraints {{< feature-state for_k8s_version="v1.18" state="alpha" >}} @@ -207,16 +208,16 @@ kind: KubeSchedulerConfiguration profiles: pluginConfig: - - name: PodTopologySpread - args: - defaultConstraints: - - maxSkew: 1 - topologyKey: failure-domain.beta.kubernetes.io/zone - whenUnsatisfiable: ScheduleAnyway + - name: PodTopologySpread + args: + defaultConstraints: + - maxSkew: 1 + topologyKey: failure-domain.beta.kubernetes.io/zone + whenUnsatisfiable: ScheduleAnyway ``` {{< note >}} -The score produced by default scheduling constraints might conflict with the +The score produced by default scheduling constraints might conflict with the score produced by the [`DefaultPodTopologySpread` plugin](/docs/reference/scheduling/profiles/#scheduling-plugins). It is recommended that you disable this plugin in the scheduling profile when @@ -229,14 +230,14 @@ In Kubernetes, directives related to "Affinity" control how Pods are scheduled - more packed or more scattered. - For `PodAffinity`, you can try to pack any number of Pods into qualifying -topology domain(s) + topology domain(s) - For `PodAntiAffinity`, only one Pod can be scheduled into a -single topology domain. + single topology domain. The "EvenPodsSpread" feature provides flexible options to distribute Pods evenly across different topology domains - to achieve high availability or cost-saving. This can also help on rolling update workloads and scaling out replicas smoothly. -See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-even-pods-spreading.md#motivation) for more details. +See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation) for more details. ## Known Limitations diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md index c58c72f28f..7854dc8e7c 100644 --- a/content/en/docs/contribute/_index.md +++ b/content/en/docs/contribute/_index.md @@ -4,59 +4,74 @@ title: Contribute to Kubernetes docs linktitle: Contribute main_menu: true weight: 80 +card: + name: contribute + weight: 10 + title: Start contributing --- {{% capture overview %}} -If you would like to help contribute to the Kubernetes documentation or website, -we're happy to have your help! Anyone can contribute, whether you're new to the -project or you've been around a long time, and whether you self-identify as a -developer, an end user, or someone who just can't stand seeing typos. +This website is maintained by [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs). + +Kubernetes documentation contributors: + +- Improve existing content +- Create new content +- Translate the documentation +- Manage and publish the documentation parts of the Kubernetes release cycle + +Kubernetes documentation welcomes improvements from all contributors, new and experienced! {{% /capture %}} {{% capture body %}} -## Getting Started +## Getting started -Anyone can open an issue describing problems or desired improvements with documentation, or contribute a change with a pull request (PR). -Some tasks require more trust and need more access in the Kubernetes organization. -See [Participating in SIG Docs](/docs/contribute/participating/) for more details about -of roles and permissions. - -Kubernetes documentation resides in a GitHub repository. While we welcome -contributions from anyone, you do need basic comfort with git and GitHub to -operate effectively in the Kubernetes community. +Anyone can open an issue about documentation, or contribute a change with a pull request (PR) to the [`kubernetes/website` GitHub repository](https://github.com/kubernetes/website). You need to be comfortable with [git](https://git-scm.com/) and [GitHub](https://lab.github.com/) to operate effectively in the Kubernetes community. To get involved with documentation: 1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md). 2. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website) and the website's [static site generator](https://gohugo.io). -3. Make sure you understand the basic processes for [improving content](https://kubernetes.io/docs/contribute/start/#improve-existing-content) and [reviewing changes](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests). +3. Make sure you understand the basic processes for [opening a pull request](/docs/contribute/new-content/open-a-pr/) and [reviewing changes](/docs/contribute/review/reviewing-prs/). -## Contributions best practices +Some tasks require more trust and more access in the Kubernetes organization. +See [Participating in SIG Docs](/docs/contribute/participating/) for more details about +roles and permissions. -- Do write clear and meaningful GIT commit messages. -- Make sure to include _Github Special Keywords_ which references the issue and automatically closes the issue when PR is merged. -- When you make a small change to a PR like fixing a typo, any style change, or changing grammar. Make sure you squash your commits so that you dont get a large number of commits for a relatively small change. -- Make sure you include a nice PR description depicting the code you have changes, why to change a following piece of code and ensuring there is sufficient information for the reviewer to understand your PR. -- Additional Readings : - - [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/) - - [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests ) - - [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git ) +## Your first contribution + +- Read the [Contribution overview](/docs/contribute/new-content/overview/) to learn about the different ways you can contribute. +- [Open a pull request using GitHub](/docs/contribute/new-content/new-content/#changes-using-github) to existing documentation and learn more about filing issues in GitHub. +- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other Kubernetes community members for accuracy and language. +- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments. +- Learn how to [use page templates](/docs/contribute/style/page-templates/) and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) to make bigger changes. + +## Next steps + +- Learn to [work from a local clone](/docs/contribute/new-content/new-content/#fork-the-repo) of the repository. +- Document [features in a release](/docs/contribute/new-content/new-features/). +- Participate in [SIG Docs](/docs/contribute/participating/), and become a [member or reviewer](/docs/contribute/participating/#roles-and-responsibilities). +- Start or help with a [localization](/docs/contribute/localization/). + +## Get involved with SIG Docs + +[SIG Docs](/docs/contribute/participating/) is the group of contributors who publish and maintain Kubernetes documentation and the website. Getting involved with SIG Docs is a great way for Kubernetes contributors (feature development or otherwise) to have a large impact on the Kubernetes project. + +SIG Docs communicates with different methods: + +- [Join `#sig-docs` on the Kubernetes Slack instance](http://slack.k8s.io/). Make sure to + introduce yourself! +- [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs), + where broader discussions take place and official decisions are recorded. +- Join the [weekly SIG Docs video meeting](https://github.com/kubernetes/community/tree/master/sig-docs). Meetings are always announced on `#sig-docs` and added to the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). You'll need to download the [Zoom client](https://zoom.us/download) or dial in using a phone. ## Other ways to contribute -- To contribute to the Kubernetes community through online forums like Twitter or Stack Overflow, or learn about local meetups and Kubernetes events, visit the [Kubernetes community site](/community/). -- To contribute to feature development, read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get started. - -{{% /capture %}} - -{{% capture whatsnext %}} - -- For more information about the basics of contributing to documentation, read [Start contributing](/docs/contribute/start/). -- Follow the [Kubernetes documentation style guide](/docs/contribute/style/style-guide/) when proposing changes. -- For more information about SIG Docs, read [Participating in SIG Docs](/docs/contribute/participating/). -- For more information about localizing Kubernetes docs, read [Localizing Kubernetes documentation](/docs/contribute/localization/). +- Visit the [Kubernetes community site](/community/). Participate on Twitter or Stack Overflow, learn about local Kubernetes meetups and events, and more. +- Read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get involved with Kubernetes feature development. +- Submit a [blog post or case study](/docs/contribute/new-content/blogs-case-studies/). {{% /capture %}} diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md index c8ccd252f4..6574bba709 100644 --- a/content/en/docs/contribute/advanced.md +++ b/content/en/docs/contribute/advanced.md @@ -2,14 +2,14 @@ title: Advanced contributing slug: advanced content_template: templates/concept -weight: 30 +weight: 98 --- {{% capture overview %}} -This page assumes that you've read and mastered the -[Start contributing](/docs/contribute/start/) and -[Intermediate contributing](/docs/contribute/intermediate/) topics and are ready +This page assumes that you understand how to +[contribute to new content](/docs/contribute/new-content/overview) and +[review others' work](/docs/contribute/review/reviewing-prs/), and are ready to learn about more ways to contribute. You need to use the Git command line client and other tools for some of these tasks. @@ -19,7 +19,7 @@ client and other tools for some of these tasks. ## Be the PR Wrangler for a week -SIG Docs [approvers](/docs/contribute/participating/#approvers) take regular turns as the PR wrangler for the repository and are added to the [PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers#2019-schedule-q1q2) for weekly rotations. +SIG Docs [approvers](/docs/contribute/participating/#approvers) take week-long turns [wrangling PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository. The PR wrangler’s duties include: @@ -37,9 +37,9 @@ The PR wrangler’s duties include: - Assign `Docs Review` and `Tech Review` labels to indicate the PR's review status. - Assign`Needs Doc Review` or `Needs Tech Review` for PRs that haven't yet been reviewed. - 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. + - 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. -- Triage and tag incoming issues daily. See [Intermediate contributing](/docs/contribute/intermediate/) for guidelines on how SIG Docs uses metadata. +- 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 @@ -60,9 +60,9 @@ reviewed is usually small. These queries specifically exclude localization PRs, ### When to close Pull Requests -Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure. +Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure. -- Close any PR where the CLA hasn’t been signed for two weeks. +- Close any PR where the CLA hasn’t been signed for two weeks. PR authors can reopen the PR after signing the CLA, so this is a low-risk way to make sure nothing gets merged without a signed CLA. - Close any PR where the author has not responded to comments or feedback in 2 or more weeks. @@ -82,7 +82,7 @@ An automated service, [`fejta-bot`](https://github.com/fejta-bot) automatically SIG Docs [members](/docs/contribute/participating/#members) can propose improvements. After you've been contributing to the Kubernetes documentation for a while, you -may have ideas for improvement to the [Style Guide](/docs/contribute/style/style-guide/) +may have ideas for improving the [Style Guide](/docs/contribute/style/style-guide/) , the [Content Guide](/docs/contribute/style/content-guide/), the toolchain used to build the documentation, the website style, the processes for reviewing and merging pull requests, or other aspects of the documentation. For maximum transparency, @@ -134,21 +134,21 @@ rotated among SIG Docs approvers. ## Serve as a New Contributor Ambassador SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve as -New Contributor Ambassadors. +New Contributor Ambassadors. -New Contributor Ambassadors work together to welcome new contributors to SIG-Docs, +New Contributor Ambassadors welcome new contributors to SIG-Docs, suggest PRs to new contributors, and mentor new contributors through their first -few PR submissions. +few PR submissions. -Responsibilities for New Contributor Ambassadors include: +Responsibilities for New Contributor Ambassadors include: -- Being available on the [Kubernetes #sig-docs channel](https://kubernetes.slack.com) to answer questions from new contributors. -- Working with PR wranglers to identify good first issues for new contributors. -- Mentoring new contributors through their first few PRs to the docs repo. +- Monitoring the [#sig-docs Slack channel](https://kubernetes.slack.com) for questions from new contributors. +- Working with PR wranglers to identify good first issues for new contributors. +- Mentoring new contributors through their first few PRs to the docs repo. - Helping new contributors create the more complex PRs they need to become Kubernetes members. -- [Sponsoring contributors](/docs/contribute/advanced/#sponsor-a-new-contributor) on their path to becoming Kubernetes members. +- [Sponsoring contributors](/docs/contribute/advanced/#sponsor-a-new-contributor) on their path to becoming Kubernetes members. -Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and in the [Kubernetes #sig-docs channel](https://kubernetes.slack.com). +Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and in the [Kubernetes #sig-docs channel](https://kubernetes.slack.com). ## Sponsor a new contributor @@ -180,12 +180,12 @@ Approvers must meet the following requirements to be a co-chair: - Have been a SIG Docs approver for at least 6 months - Have [led a Kubernetes docs release](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) or shadowed two releases - Understand SIG Docs workflows and tooling: git, Hugo, localization, blog subproject -- Understand how other Kubernetes SIGs and repositories affect the SIG Docs workflow, including: [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs), plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture). +- Understand how other Kubernetes SIGs and repositories affect the SIG Docs workflow, including: [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs), plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture). - Commit at least 5 hours per week (and often more) to the role for a minimum of 6 months ### Responsibilities -The role of co-chair is primarily one of service: co-chairs handle process and policy, schedule and run meetings, schedule PR wranglers, and generally do the things that no one else wants to do in order to build contributor capacity. +The role of co-chair is one of service: co-chairs build contributor capacity, handle process and policy, schedule and run meetings, schedule PR wranglers, advocate for docs in the Kubernetes community, make sure that docs succeed in Kubernetes release cycles, and keep SIG Docs focused on effective priorities. Responsibilities include: @@ -228,7 +228,7 @@ For weekly meetings, copypaste the previous week's notes into the "Past meetings **Honor folks' time**: -- Begin and end meetings punctually +Begin and end meetings on time. **Use Zoom effectively**: @@ -240,9 +240,9 @@ For weekly meetings, copypaste the previous week's notes into the "Past meetings ### Recording meetings on Zoom When you’re ready to start the recording, click Record to Cloud. - + When you’re ready to stop recording, click Stop. The video uploads automatically to YouTube. -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/contribute/intermediate.md b/content/en/docs/contribute/intermediate.md deleted file mode 100644 index 9e477a90a4..0000000000 --- a/content/en/docs/contribute/intermediate.md +++ /dev/null @@ -1,967 +0,0 @@ ---- -title: Intermediate contributing -slug: intermediate -content_template: templates/concept -weight: 20 -card: - name: contribute - weight: 50 ---- - -{{% capture overview %}} - -This page assumes that you've read and mastered the tasks in the -[start contributing](/docs/contribute/start/) topic and are ready to -learn about more ways to contribute. - -{{< note >}} -Some tasks require you to use the Git command line client and other tools. -{{< /note >}} - -{{% /capture %}} - -{{% capture body %}} - -Now that you've gotten your feet wet and helped out with the Kubernetes docs in -the ways outlined in the [start contributing](/docs/contribute/start/) topic, -you may feel ready to do more. These tasks assume that you have, or are willing -to gain, deeper knowledge of the following topic areas: - -- Kubernetes concepts -- Kubernetes documentation workflows -- Where and how to find information about upcoming Kubernetes features -- Strong research skills in general - -These tasks are not as sequential as the beginner tasks. There is no expectation -that one person does all of them all of the time. - -## Learn about Prow - -[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md) is -the Kubernetes-based CI/CD system that runs jobs against pull requests (PRs). Prow -enables chatbot-style commands to handle GitHub actions across the Kubernetes -organization. You can perform a variety of actions such as [adding and removing -labels](#add-and-remove-labels), closing issues, and assigning an approver. Type -the Prow command into a comment field using the `/` format. Some common -commands are: - -- `/lgtm` (looks good to me): adds the `lgtm` label, signalling that a reviewer has finished reviewing the PR -- `/approve`: approves a PR so it can merge (approver use only) -- `/assign`: assigns a person to review or approve a PR -- `/close`: closes an issue or PR -- `/hold`: adds the `do-not-merge/hold` label, indicating the PR cannot be automatically merged -- `/hold cancel`: removes the `do-not-merge/hold` label - -{{% note %}} -Not all commands are available to every user. The Prow bot will tell you if you -try to execute a command beyond your authorization level. -{{% /note %}} - -Familiarize yourself with the [list of Prow -commands](https://prow.k8s.io/command-help) before you review PRs or triage issues. - - -## Review pull requests - -In any given week, a specific docs approver volunteers to do initial triage -and review of [pull requests and issues](#triage-and-categorize-issues). This -person is the "PR Wrangler" for the week. The schedule is maintained using the -[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers). -To be added to this list, attend the weekly SIG Docs meeting and volunteer. Even -if you are not on the schedule for the current week, you can still review pull -requests (PRs) that are not already under active review. - -In addition to the rotation, an automated system comments on each new PR and -suggests reviewers and approvers for the PR, based on the list of approvers and -reviewers in the affected files. The PR author is expected to follow the -guidance of the bot, and this also helps PRs to get reviewed quickly. - -We want to get pull requests (PRs) merged and published as quickly as possible. -To ensure the docs are accurate and up to date, each PR needs to be reviewed by -people who understand the content, as well as people with experience writing -great documentation. - -Reviewers and approvers need to provide actionable and constructive feedback to -keep contributors engaged and help them to improve. Sometimes helping a new -contributor get their PR ready to merge takes more time than just rewriting it -yourself, but the project is better in the long term when we have a diversity of -active participants. - -Before you start reviewing PRs, make sure you are familiar with the -[Documentation Content Guide](/docs/contribute/style/content-guide/), the -[Documentation Style Guide](/docs/contribute/style/style-guide/), -and the [code of conduct](/community/code-of-conduct/). - -### Find a PR to review - -To see all open PRs, go to the **Pull Requests** tab in the GitHub repository. -A PR is eligible for review when it meets all of the following criteria: - -- Has the `cncf-cla:yes` tag -- Does not have WIP in the description -- Does not a have tag including the phrase `do-not-merge` -- Has no merge conflicts -- Is based against the correct branch (usually `master` unless the PR relates to - a feature that has not yet been released) -- Is not being actively reviewed by another docs person (other technical - reviewers are fine), unless that person has explicitly asked for your help. In - particular, leaving lots of new comments after other review cycles have - already been completed on a PR can be discouraging and counter-productive. - -If a PR is not eligible to merge, leave a comment to let the author know about -the problem and offer to help them fix it. If they've been informed and have not -fixed the problem in several weeks or months, eventually their PR will be closed -without merging. - -If you're new to reviewing, or you don't have a lot of bandwidth, look for PRs -with the `size/XS` or `size/S` tag set. The size is automatically determined by -the number of lines the PR changes. - -#### Reviewers and approvers - -The Kubernetes website repo operates differently than some of the Kubernetes -code repositories when it comes to the roles of reviewers and approvers. For -more information about the responsibilities of reviewers and approvers, see -[Participating](/docs/contribute/participating/). Here's an overview. - -- A reviewer reviews pull request content for technical accuracy. A reviewer - indicates that a PR is technically accurate by leaving a `/lgtm` comment on - the PR. - - {{< note >}}Don't add a `/lgtm` unless you are confident in the technical - accuracy of the documentation modified or introduced in the PR.{{< /note >}} - -- An approver reviews pull request content for docs quality and adherence to - SIG Docs guidelines found in the Content and Style guides. Only people listed as - approvers in the - [`OWNERS`](https://github.com/kubernetes/website/blob/master/OWNERS) file can - approve a PR. To approve a PR, leave an `/approve` comment on the PR. - -A PR is merged when it has both a `/lgtm` comment from anyone in the Kubernetes -organization and an `/approve` comment from an approver in the -`sig-docs-maintainers` group, as long as it is not on hold and the PR author -has signed the CLA. - -{{< note >}} - -The ["Participating"](/docs/contribute/participating/#approvers) section contains more information for reviewers and approvers, including specific responsibilities for approvers. - -{{< /note >}} - -### Review a PR - -1. Read the PR description and read any attached issues or links, if - applicable. "Drive-by reviewing" is sometimes more harmful than helpful, so - make sure you have the right knowledge to provide a meaningful review. - -2. If someone else is the best person to review this particular PR, let them - know by adding a comment with `/assign @`. If you have - asked a non-docs person for technical review but still want to review the PR - from a docs point of view, keep going. - -3. Go to the **Files changed** tab. Look over all the changed lines. Removed - content has a red background, and those lines also start with a `-` symbol. - Added content has a green background, and those lines also start with a `+` - symbol. Within a line, the actual modified content has a slightly darker - green background than the rest of the line. - - - Especially if the PR uses tricky formatting or changes CSS, Javascript, - or other site-wide elements, you can preview the website with the PR - applied. Go to the **Conversation** tab and click the **Details** link - for the `deploy/netlify` test, near the bottom of the page. It opens in - the same browser window by default, so open it in a new window so you - don't lose your partial review. Switch back to the **Files changed** tab - to resume your review. - - Make sure the PR complies with the Content and Style guides; link the - author to the relevant part of the guide(s) if it doesn't. - - If you have a question, comment, or other feedback about a given - change, hover over a line and click the blue-and-white `+` symbol that - appears. Type your comment and click **Start a review**. - - If you have more comments, leave them in the same way. - - By convention, if you see a small problem that does not have to do with - the main purpose of the PR, such as a typo or whitespace error, you can - call it out, prefixing your comment with `nit:` so that the author knows - you consider it trivial. They should still address it. - - When you've reviewed everything, or if you didn't have any comments, go - back to the top of the page and click **Review changes**. Choose either - **Comment** or **Request Changes**. Add a summary of your review, and - add appropriate - [Prow commands](https://prow.k8s.io/command-help) to separate lines in - the Review Summary field. SIG Docs follows the - [Kubernetes code review process](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process). - All of your comments will be sent to the PR author in a single - notification. - - - If you think the PR is ready to be merged, add the text `/approve` to - your summary. - - If the PR does not need additional technical review, add the - text `/lgtm` as well. - - If the PR *does* need additional technical review, add the text - `/assign` with the GitHub username of the person who needs to - provide technical review. Look at the `reviewers` field in the - front-matter at the top of a given Markdown file to see who can - provide technical review. - - To prevent the PR from being merged, add `/hold`. This sets the - label `do-not-merge/hold`. - - If a PR has no conflicts and has the `lgtm` and `approve` labels but - no `hold` label, it is merged automatically. - - If a PR has the `lgtm` and/or `approve` labels and new changes are - detected, these labels are removed automatically. - - See - [the list of all available slash commands](https://prow.k8s.io/command-help) - that can be used in PRs. - - - If you previously selected **Request changes** and the PR author has - addressed your concerns, you can change your review status either in the - **Files changed** tab or at the bottom of the **Conversation** tab. Be - sure to add the `/approve` tag and assign technical reviewers if necessary, - so that the PR can be merged. - -### Commit into another person's PR - -Leaving PR comments is helpful, but there may be times when you need to commit -into another person's PR, rather than just leaving a review. - -Resist the urge to "take over" for another person unless they explicitly ask -you to, or you want to resurrect a long-abandoned PR. While it may be faster -in the short term, it deprives the person of the chance to contribute. - -The process you use depends on whether you need to edit a file that is already -in the scope of the PR or a file that the PR has not yet touched. - -You can't commit into someone else's PR if either of the following things is -true: - -- If the PR author pushed their branch directly to the - [https://github.com/kubernetes/website/](https://github.com/kubernetes/website/) - repository, only a reviewer with push access can commit into their PR. - Authors should be encouraged to push their branch to their fork before - opening the PR. -- If the PR author explicitly disallowed edits from approvers, you can't - commit into their PR unless they change this setting. - -#### If the file is already changed by the PR - -This method uses the GitHub UI. If you prefer, you can use the command line -even if the file you want to change is part of the PR, if you are more -comfortable working that way. - -1. Click the **Files changed** tab. -2. Scroll down to the file you want to edit, and click the pencil icon for - that file. -3. Make your changes, add a commit message in the field below the editor, and - click **Commit changes**. - -Your commit is now pushed to the branch the PR represents (probably on the -author's fork) and now shows up in the PR and your changes are reflected in -the **Files changed** tab. Leave a comment letting the PR author know you -changed the PR. - -If the author is using the command line rather than the GitHub UI to work on -this PR, they need to fetch their fork's changes and rebase their local branch -on the branch in their fork, before doing additional work on the PR. - -#### If the file has not yet been changed by the PR - -If changes need to be made to a file that is not yet included in the PR, you -need to use the command line. You can always use this method, if you prefer it -to the GitHub UI. - -1. Get the URL for the author's fork. You can find it near the bottom of the - **Conversation** tab. Look for the text **Add more commits by pushing to**. - The first link after this phrase is to the branch, and the second link is - to the fork. Copy the second link. Note the name of the branch for later. - -2. Add the fork as a remote. In your terminal, go to your clone of the - repository. Decide on a name to give the remote (such as the author's - GitHub username), and add the remote using the following syntax: - - ```bash - git remote add - ``` - -3. Fetch the remote. This doesn't change any local files, but updates your - clone's notion of the remote's objects (such as branches and tags) and - their current state. - - ```bash - git remote fetch - ``` - -4. Check out the remote branch. This command will fail if you already have a - local branch with the same name. - - ```bash - git checkout - ``` - -5. Make your changes, use `git add` to add them, and commit them. - -6. Push your changes to the author's remote. - - ```bash - git push - ``` - -7. Go back to the GitHub IU and refresh the PR. Your changes appear. Leave the - PR author a comment letting them know you changed the PR. - -If the author is using the command line rather than the GitHub UI to work on -this PR, they need to fetch their fork's changes and rebase their local branch -on the branch in their fork, before doing additional work on the PR. - -## Work from a local clone - -For changes that require multiple files or changes that involve creating new -files or moving files around, working from a local Git clone makes more sense -than relying on the GitHub UI. These instructions use the `git` command and -assume that you have it installed locally. You can adapt them to use a local -graphical Git client instead. - -### Clone the repository - -You only need to clone the repository once per physical system where you work -on the Kubernetes documentation. - -1. Create a fork of the `kubernetes/website` repository on GitHub. In your - web browser, go to - [https://github.com/kubernetes/website](https://github.com/kubernetes/website) - and click the **Fork** button. After a few seconds, you are redirected to - the URL for your fork, which is `https://github.com//website`. - -2. In a terminal window, use `git clone` to clone the your fork. - - ```bash - git clone git@github.com//website - ``` - - The new directory `website` is created in your current directory, with - the contents of your GitHub repository. Your fork is your `origin`. - -3. Change to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote. - - ```bash - cd website - - git remote add upstream https://github.com/kubernetes/website.git - ``` - -4. Confirm your `origin` and `upstream` repositories. - - ```bash - git remote -v - ``` - - Output is similar to: - - ```bash - origin git@github.com:/website.git (fetch) - origin git@github.com:/website.git (push) - upstream https://github.com/kubernetes/website (fetch) - upstream https://github.com/kubernetes/website (push) - ``` - -### Work on the local repository - -Before you start a new unit of work on your local repository, you need to figure -out which branch to base your work on. The answer depends on what you are doing, -but the following guidelines apply: - -- For general improvements to existing content, start from `master`. -- For new content that is about features that already exist in a released - version of Kubernetes, start from `master`. -- For long-running efforts that multiple SIG Docs contributors will collaborate on, - such as content reorganization, use a specific feature branch created for that - effort. -- For new content that relates to upcoming but unreleased Kubernetes versions, - use the pre-release feature branch created for that Kubernetes version. - -For more guidance, see -[Choose which branch to use](/docs/contribute/start/#choose-which-git-branch-to-use). - -After you decide which branch to start your work (or _base it on_, in Git -terminology), use the following workflow to be sure your work is based on the -most up-to-date version of that branch. - -1. There are three different copies of the repository when you work locally: - `local`, `upstream`, and `origin`. Fetch both the `origin` and `upstream` remotes. This - updates your cache of the remotes without actually changing any of the copies. - - ```bash - git fetch origin - git fetch upstream - ``` - - This workflow deviates from the one defined in the Community's [GitHub - Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). - In this workflow, you do not need to merge your local copy of `master` with `upstream/master` before - pushing the updates to your fork. That step is not required in - `kubernetes/website` because you are basing your branch on the upstream repository. - -2. Create a local working branch based on the most appropriate upstream branch: - `upstream/dev-1.xx` for feature developers or `upstream/master` for all other - contributors. This example assumes you are basing your work on - `upstream/master`. Because you didn't update your local `master` to match - `upstream/master` in the previous step, you need to explicitly create your - branch off of `upstream/master`. - - ```bash - git checkout -b upstream/master - ``` - -3. With your new branch checked out, make your changes using a text editor. - At any time, use the `git status` command to see what you've changed. - -4. When you are ready to submit a pull request, commit your changes. First - use `git status` to see what changes need to be added to the changeset. - There are two important sections: `Changes staged for commit` and - `Changes not staged for commit`. Any files that show up in the latter - section under `modified` or `untracked` need to be added if you want them to - be part of this commit. For each file that needs to be added, use `git add`. - - ```bash - git add example-file.md - ``` - - When all your intended changes are included, create a commit using the - `git commit` command: - - ```bash - git commit -m "Your commit message" - ``` - - {{< note >}} - Do not reference a GitHub issue or pull request by ID or URL in the - commit message. If you do, it will cause that issue or pull request to get - a notification every time the commit shows up in a new Git branch. You can - link issues and pull requests together later in the GitHub UI. - {{< /note >}} - -5. Optionally, you can test your change by staging the site locally using the - `hugo` command. See [View your changes locally](#view-your-changes-locally). - You'll be able to view your changes after you submit the pull request, as - well. - -6. Before you can create a pull request which includes your local commit, you - need to push the branch to your fork, which is the endpoint for the `origin` - remote. - - ```bash - git push origin - ``` - - Technically, you can omit the branch name from the `push` command, but - the behavior in that case depends upon the version of Git you are using. - The results are more repeatable if you include the branch name. - -7. Go to https://github.com/kubernetes/website in your web browser. GitHub - detects that you pushed a new branch to your fork and offers to create a pull - request. Fill in the pull request template. - - - The title should be no more than 50 characters and summarize the intent - of the change. - - The long-form description should contain more information about the fix, - including a line like `Fixes #12345` if the pull request fixes a GitHub - issue. This will cause the issue to be closed automatically when the - pull request is merged. - - You can add labels or other metadata and assign reviewers. See - [Triage and categorize issues](#triage-and-categorize-issues) for the - syntax. - - Click **Create pull request**. - -8. Several automated tests will run against the state of the website with your - changes applied. If any of the tests fail, click the **Details** link for - more information. If the Netlify test completes successfully, its - **Details** link goes to a staged version of the Kubernetes website with - your changes applied. This is how reviewers will check your changes. - -9. When you need to make more changes, address the feedback locally and amend - your original commit. - - ```bash - git commit -a --amend - ``` - - - `-a`: commit all changes - - `--amend`: amend the previous commit, rather than creating a new one - - An editor will open so you can update your commit message if necessary. - - If you use `git commit -m` as in Step 4, you will create a new commit rather - than amending changes to your original commit. Creating a new commit means - you must squash your commits before your pull request can be merged. - - Follow the instructions in Step 6 to push your commit. The commit is added - to your pull request and the tests run again, including re-staging the - Netlify staged site. - -10. If a reviewer adds changes to your pull request, you need to fetch those - changes from your fork before you can add more changes. Use the following - commands to do this, assuming that your branch is currently checked out. - - ```bash - git fetch origin - git rebase origin/ - ``` - - After rebasing, you need to add the `--force-with-lease` flag to - force push the branch's new changes to your fork. - - ```bash - git push --force-with-lease origin - ``` - -11. If someone else's change is merged into the branch your work is based on, - and you have made changes to the same parts of the same files, a conflict - might occur. If the pull request shows that there are conflicts to resolve, - you can resolve them using the GitHub UI or you can resolve them locally. - - First, do step 10 to be sure that your fork and your local branch are in - the same state. - - Next, fetch `upstream` and rebase your branch on the branch it was - originally based on, like `upstream/master`. - - ```bash - git fetch upstream - git rebase upstream/master - ``` - - If there are conflicts Git can't automatically resolve, you can see the - conflicted files using the `git status` command. For each conflicted file, - edit it and look for the conflict markers `>>>`, `<<<`, and `===`. Resolve - the conflict and remove the conflict markers. Then add the changes to the - changeset using `git add ` and continue the rebase using - `git rebase --continue`. When all commits have been applied and there are - no more conflicts, `git status` will show that you are not in a rebase and - there are no changes that need to be committed. At that point, force-push - the branch to your fork, and the pull request should no longer show any - conflicts. - -12. If your PR still has multiple commits after amending previous commits, you - must squash multiple commits into a single commit before your PR can be merged. - You can check the number of commits on your PR's `Commits` tab or by running - `git log` locally. Squashing commits is a form of rebasing. - - ```bash - git rebase -i HEAD~ - ``` - - The `-i` switch tells git you want to rebase interactively. This enables - you to tell git which commits to squash into the first one. For - example, you have 3 commits on your branch: - - ``` - 12345 commit 4 (2 minutes ago) - 6789d commit 3 (30 minutes ago) - 456df commit 2 (1 day ago) - ``` - - You must squash your last three commits into the first one. - - ``` - git rebase -i HEAD~3 - ``` - - That command opens an editor with the following: - - ``` - pick 456df commit 2 - pick 6789d commit 3 - pick 12345 commit 4 - ``` - - Change `pick` to `squash` on the commits you want to squash, and make sure - the one `pick` commit is at the top of the editor. - - ``` - pick 456df commit 2 - squash 6789d commit 3 - squash 12345 commit 4 - ``` - - Save and close your editor. Then push your squashed - commit with `git push --force-with-lease origin `. - - -If you're having trouble resolving conflicts or you get stuck with -anything else related to your pull request, ask for help on the `#sig-docs` -Slack channel or the -[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). - -### View your changes locally - -{{< tabs name="tab_with_hugo" >}} -{{% tab name="Hugo in a container" %}} - -If you aren't ready to create a pull request but you want to see what your -changes look like, you can build and run a docker image to generate all the documentation and -serve it locally. - -1. Build the image locally: - - ```bash - make docker-image - ``` - -2. Once the `kubernetes-hugo` image has been built locally, you can build and serve the site: - - ```bash - make docker-serve - ``` - -3. In your browser's address bar, enter `localhost:1313`. Hugo will watch the - filesystem for changes and rebuild the site as needed. - -4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C` - or just close the terminal window. -{{% /tab %}} -{{% tab name="Hugo locally" %}} - -Alternatively, you can install and use the `hugo` command on your development machine: - -1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml). - -2. In a terminal, go to the root directory of your clone of the Kubernetes - docs, and enter this command: - - ```bash - hugo server - ``` - -3. In your browser’s address bar, enter `localhost:1313`. - -4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C` - or just close the terminal window. -{{% /tab %}} -{{< /tabs >}} - -## Triage and categorize issues - -People in SIG Docs are responsible only for triaging and categorizing -documentation issues. General website issues are also filed in the -`kubernetes/website` repository. - -When you triage an issue, you: - -- Validate the issue - - Make sure the issue is about website documentation. Some issues can be closed quickly by - answering a question or pointing the reporter to a resource. See the - [Support requests or code bug reports](#support-requests-or-code-bug-reports) section for details. - - Assess whether the issue has merit. Add the `triage/needs-information` label if the issue doesn't have enough - detail to be actionable or the template is not filled out adequately. - Close the issue if it has both the `lifecycle/stale` and `triage/needs-information` labels. -- Add a priority label (the - [Issue Triage Guidelines](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority) - define Priority labels in detail) - - `priority/critical-urgent` - do this right now - - `priority/important-soon` - do this within 3 months - - `priority/important-longterm` - do this within 6 months - - `priority/backlog` - this can be deferred indefinitely; lowest priority; - do this when resources are available - - `priority/awaiting-more-evidence` - placeholder for a potentially good issue - so it doesn't get lost -- Optionally, add a `help` or `good first issue` label if the issue is suitable - for someone with very little Kubernetes or SIG Docs experience. Consult - [Help Wanted and Good First Issue Labels](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md) - for guidance. -- At your discretion, take ownership of an issue and submit a PR for it - (especially if it is quick or relates to work you were already doing). - -This GitHub Issue [filter](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc) -finds all the issues that need to be triaged. - -If you have questions about triaging an issue, ask in `#sig-docs` on Slack or -the [kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). - -### Add and remove labels - -To add a label, leave a comment like `/` or `/ `. The label must -already exist. If you try to add a label that does not exist, the command is -silently ignored. - -Examples: - -- `/triage needs-information` -- `/priority important-soon` -- `/language ja` -- `/help` -- `/good-first-issue` -- `/lifecycle frozen` - -To remove a label, leave a comment like `/remove-` or `/remove- `. - -Examples: - -- `/remove-triage needs-information` -- `/remove-priority important-soon` -- `/remove-language ja` -- `/remove-help` -- `/remove-good-first-issue` -- `/remove-lifecycle frozen` - -The list of all the labels used across Kubernetes is -[here](https://github.com/kubernetes/kubernetes/labels). Not all labels -are used by SIG Docs. - -### More about labels - -- An issue can have multiple labels. -- Some labels use slash notation for grouping, which can be thought of like - "sub-labels". For instance, many `sig/` labels exist, such as `sig/cli` and - `sig/api-machinery` ([full list](https://github.com/kubernetes/website/labels?utf8=%E2%9C%93&q=sig%2F)). -- Some labels are automatically added based on metadata in the files involved - in the issue, slash commands used in the comments of the issue, or - information in the issue text. -- Additional labels are manually added by the person triaging the issue (or the person - reporting the issue) - - `kind/bug`, `kind/feature`, and `kind/documentation`: A bug is a problem with existing content or - functionality, and a feature is a request for new content or functionality. - The `kind/documentation` label is seldom used. - - `language/ja`, `language/ko` and similar [language - labels](https://github.com/kubernetes/website/labels?utf8=%E2%9C%93&q=language) - if the issue is about localized content. - -### Issue lifecycle - -Issues are generally opened and closed within a relatively short time span. -However, sometimes an issue may not have associated activity after it is -created. Other times, an issue may need to remain open for longer than 90 days. - -`lifecycle/stale`: after 90 days with no activity, an issue is automatically -labeled as stale. The issue will be automatically closed if the lifecycle is not -manually reverted using the `/remove-lifecycle stale` command. - -`lifecycle/frozen`: an issue with this label will not become stale after 90 days -of inactivity. A user manually adds this label to issues that need to remain -open for much longer than 90 days, such as those with a -`priority/important-longterm` label. - - -### Handling special issue types - -We encounter the following types of issues often enough to document how -to handle them. - -#### Duplicate issues - -If a single problem has one or more issues open for it, the problem should be -consolidated into a single issue. You should decide which issue to keep open (or -open a new issue), port over all relevant information and link related issues. -Finally, label all other issues that describe the same problem with -`triage/duplicate` and close them. Only having a single issue to work on will -help reduce confusion and avoid duplicating work on the same problem. - -#### Dead link issues - -Depending on where the dead link is reported, different actions are required to -resolve the issue. Dead links in the API and Kubectl docs are automation issues -and should be assigned `/priority critical-urgent` until the problem can be fully understood. All other -dead links are issues that need to be manually fixed and can be assigned `/priority important-longterm`. - -#### Blog issues - -[Kubernetes Blog](https://kubernetes.io/blog/) entries are expected to become -outdated over time, so we maintain only blog entries that are less than one year old. -If an issue is related to a blog entry that is more than one year old, it should be closed -without fixing. - -#### Support requests or code bug reports - -Some issues opened for docs are instead issues with the underlying code, or -requests for assistance when something (like a tutorial) didn’t work. For issues -unrelated to docs, close the issue with the `triage/support` label and a comment -directing the requester to support venues (Slack, Stack Overflow) and, if -relevant, where to file an issue for bugs with features (kubernetes/kubernetes -is a great place to start). - -Sample response to a request for support: - -```none -This issue sounds more like a request for support and less -like an issue specifically for docs. I encourage you to bring -your question to the `#kubernetes-users` channel in -[Kubernetes slack](http://slack.k8s.io/). You can also search -resources like -[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) -for answers to similar questions. - -You can also open issues for Kubernetes functionality in - https://github.com/kubernetes/kubernetes. - -If this is a documentation issue, please re-open this issue. -``` - -Sample code bug report response: - -```none -This sounds more like an issue with the code than an issue with -the documentation. Please open an issue at -https://github.com/kubernetes/kubernetes/issues. - -If this is a documentation issue, please re-open this issue. -``` - -## Document new features - -Each major Kubernetes release includes new features, and many of them need -at least a small amount of documentation to show people how to use them. - -Often, the SIG responsible for a feature submits draft documentation for the -feature as a pull request to the appropriate release branch of -`kubernetes/website` repository, and someone on the SIG Docs team provides -editorial feedback or edits the draft directly. - -### Find out about upcoming features - -To find out about upcoming features, attend the weekly sig-release meeting (see -the [community](https://kubernetes.io/community/) page for upcoming meetings) -and monitor the release-specific documentation -in the [kubernetes/sig-release](https://github.com/kubernetes/sig-release/) -repository. Each release has a sub-directory under the [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases) -directory. Each sub-directory contains a release schedule, a draft of the release -notes, and a document listing each person on the release team. - -- The release schedule contains links to all other documents, meetings, - meeting minutes, and milestones relating to the release. It also contains - information about the goals and timeline of the release, and any special - processes in place for this release. Near the bottom of the document, several - release-related terms are defined. - - This document also contains a link to the **Feature tracking sheet**, which is - the official way to find out about all new features scheduled to go into the - release. -- The release team document lists who is responsible for each release role. If - it's not clear who to talk to about a specific feature or question you have, - either attend the release meeting to ask your question, or contact the release - lead so that they can redirect you. -- The release notes draft is a good place to find out a little more about - specific features, changes, deprecations, and more about the release. The - content is not finalized until late in the release cycle, so use caution. - -#### The feature tracking sheet - -The feature tracking sheet -[for a given Kubernetes release](https://github.com/kubernetes/sig-release/tree/master/releases) lists each feature that is planned for a release. -Each line item includes the name of the feature, a link to the feature's main -GitHub issue, its stability level (Alpha, Beta, or Stable), the SIG and -individual responsible for implementing it, whether it -needs docs, a draft release note for the feature, and whether it has been -merged. Keep the following in mind: - -- Beta and Stable features are generally a higher documentation priority than - Alpha features. -- It's hard to test (and therefore, document) a feature that hasn't been merged, - or is at least considered feature-complete in its PR. -- Determining whether a feature needs documentation is a manual process and - just because a feature is not marked as needing docs doesn't mean it doesn't - need them. - -### Document a feature - -As stated above, draft content for new features is usually submitted by the SIG -responsible for implementing the new feature. This means that your role may be -more of a shepherding role for a given feature than developing the documentation -from scratch. - -After you've chosen a feature to document/shepherd, ask about it in the `#sig-docs` -Slack channel, in a weekly sig-docs meeting, or directly on the PR filed by the -feature SIG. If you're given the go-ahead, you can edit into the PR using one of -the techniques described in -[Commit into another person's PR](#commit-into-another-persons-pr). - -If you need to write a new topic, the following links are useful: - -- [Writing a New Topic](/docs/contribute/style/write-new-topic/) -- [Using Page Templates](/docs/contribute/style/page-templates/) -- [Documentation Style Guide](/docs/contribute/style/style-guide/) -- [Documentation Content Guide](/docs/contribute/style/content-guide/) - -### SIG members documenting new features - -If you are a member of a SIG developing a new feature for Kubernetes, you need -to work with SIG Docs to be sure your feature is documented in time for the -release. Check the -[feature tracking spreadsheet](https://github.com/kubernetes/sig-release/tree/master/releases) -or check in the #sig-release Slack channel to verify scheduling details and -deadlines. Some deadlines related to documentation are: - -- **Docs deadline - Open placeholder PRs**: Open a pull request against the - `release-X.Y` branch in the `kubernetes/website` repository, with a small - commit that you will amend later. Use the Prow command `/milestone X.Y` to - assign the PR to the relevant milestone. This alerts the docs person managing - this release that the feature docs are coming. If your feature does not need - any documentation changes, make sure the sig-release team knows this, by - mentioning it in the #sig-release Slack channel. If the feature does need - documentation but the PR is not created, the feature may be removed from the - milestone. -- **Docs deadline - PRs ready for review**: Your PR now needs to contain a first - draft of the documentation for your feature. Don't worry about formatting or - polishing. Just describe what the feature does and how to use it. The docs - person managing the release will work with you to get the content into shape - to be published. If your feature needs documentation and the first draft - content is not received, the feature may be removed from the milestone. -- **Docs complete - All PRs reviewed and ready to merge**: If your PR has not - yet been merged into the `release-X.Y` branch by this deadline, work with the - docs person managing the release to get it in. If your feature needs - documentation and the docs are not ready, the feature may be removed from the - milestone. - -If your feature is an Alpha feature and is behind a feature gate, make sure you -add it to [Feature gates](/docs/reference/command-line-tools-reference/feature-gates/) -as part of your pull request. If your feature is moving to Beta -or to General Availability, update the feature gates file. - -## Contribute to other repos - -The [Kubernetes project](https://github.com/kubernetes) contains more than 50 -individual repositories. Many of these repositories contain code or content that -can be considered documentation, such as user-facing help text, error messages, -user-facing text in API references, or even code comments. - -If you see text and you aren't sure where it comes from, you can use GitHub's -search tool at the level of the Kubernetes organization to search through all -repositories for that text. This can help you figure out where to submit your -issue or PR. - -Each repository may have its own processes and procedures. Before you file an -issue or submit a PR, read that repository's `README.md`, `CONTRIBUTING.md`, and -`code-of-conduct.md`, if they exist. - -Most repositories use issue and PR templates. Have a look through some open -issues and PRs to get a feel for that team's processes. Make sure to fill out -the templates with as much detail as possible when you file issues or PRs. - -## Localize content - -The Kubernetes documentation is written in English first, but we want people to -be able to read it in their language of choice. If you are comfortable -writing in another language, especially in the software domain, you can help -localize the Kubernetes documentation or provide feedback on existing localized -content. See [Localization](/docs/contribute/localization/) and ask on the -[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) -or in `#sig-docs` on Slack if you are interested in helping out. - -### Working with localized content - -Follow these guidelines for working with localized content: - -- Limit PRs to a single language. - - Each language has its own reviewers and approvers. - -- Reviewers, verify that PRs contain changes to only one language. - - If a PR contains changes to source in more than one language, ask the PR contributor to open separate PRs for each language. - -{{% /capture %}} - -{{% capture whatsnext %}} - -When you are comfortable with all of the tasks discussed in this topic and you -want to engage with the Kubernetes docs team in even deeper ways, read the -[advanced docs contributor](/docs/contribute/advanced/) topic. - -{{% /capture %}} diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index 2522a832f3..bd561ed515 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -1,13 +1,14 @@ --- -title: Localizing Kubernetes Documentation +title: Localizing Kubernetes documentation content_template: templates/concept approvers: - remyleone - rlenferink - zacharysarah +weight: 50 card: name: contribute - weight: 30 + weight: 50 title: Translating the docs --- @@ -21,9 +22,9 @@ This page shows you how to [localize](https://blog.mozilla.org/l10n/2011/12/14/i ## Getting started -Because contributors can't approve their own pull requests, you need at least two contributors to begin a localization. +Because contributors can't approve their own pull requests, you need at least two contributors to begin a localization. -All localization teams must be self-sustaining with their own resources. We're happy to host your work, but we can't translate it for you. +All localization teams must be self-sustaining with their own resources. The Kubernetes website is happy to host your work, but it's up to you to translate it. ### Find your two-letter language code @@ -31,7 +32,7 @@ First, consult the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/p ### Fork and clone the repo -First, [create your own fork](/docs/contribute/start/#improve-existing-content) of the [kubernetes/website](https://github.com/kubernetes/website) repository. +First, [create your own fork](/docs/contribute/new-content/new-content/#fork-the-repo) of the [kubernetes/website](https://github.com/kubernetes/website) repository. Then, clone your fork and `cd` into it: @@ -42,12 +43,12 @@ cd website ### Open a pull request -Next, [open a pull request](/docs/contribute/start/#submit-a-pull-request) (PR) to add a localization to the `kubernetes/website` repository. +Next, [open a pull request](/docs/contribute/new-content/open-a-pr/#open-a-pr) (PR) to add a localization to the `kubernetes/website` repository. The PR must include all of the [minimum required content](#minimum-required-content) before it can be approved. For an example of adding a new localization, see the PR to enable [docs in French](https://github.com/kubernetes/website/pull/12548). - + ### Join the Kubernetes GitHub organization Once you've opened a localization PR, you can become members of the Kubernetes GitHub organization. Each person on the team needs to create their own [Organization Membership Request](https://github.com/kubernetes/org/issues/new/choose) in the `kubernetes/org` repository. @@ -74,7 +75,7 @@ For an example of adding a label, see the PR for adding the [Italian language la Let Kubernetes SIG Docs know you're interested in creating a localization! Join the [SIG Docs Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/). Other localization teams are happy to help you get started and answer any questions you have. -You can also create a Slack channel for your localization in the `kubernetes/community` repository. For an example of adding a Slack channel, see the PR for [adding channels for Indonesian and Portuguese](https://github.com/kubernetes/community/pull/3605). +You can also create a Slack channel for your localization in the `kubernetes/community` repository. For an example of adding a Slack channel, see the PR for [adding channels for Indonesian and Portuguese](https://github.com/kubernetes/community/pull/3605). ## Minimum required content @@ -105,11 +106,11 @@ Add a language-specific subdirectory to the [`content`](https://github.com/kuber mkdir content/de ``` -### Localize the Community Code of Conduct +### Localize the community code of conduct Open a PR against the [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) repository to add the code of conduct in your language. -### Add a localized README +### Add a localized README file To guide other localization contributors, add a new [`README-**.md`](https://help.github.com/articles/about-readmes/) to the top level of k/website, where `**` is the two-letter language code. For example, a German README file would be `README-de.md`. @@ -192,10 +193,10 @@ mkdir -p content/de/docs/tutorials cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md ``` -Translation tools can speed up the translation process. For example, some editors offers plugins to quickly translate text. +Translation tools can speed up the translation process. For example, some editors offers plugins to quickly translate text. {{< caution >}} -Machine-generated translation alone does not meet the minimum standard of quality and requires extensive human review to meet that standard. +Machine-generated translation is insufficient on its own. Localization requires extensive human review to meet minimum standards of quality. {{< /caution >}} To ensure accuracy in grammar and meaning, members of your localization team should carefully review all machine-generated translations before publishing. @@ -211,7 +212,7 @@ To find source files for the most recent release: The latest version is {{< latest-version >}}, so the most recent release branch is [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}}). -### Site strings in i18n/ +### Site strings in i18n Localizations must include the contents of [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) in a new language-specific file. Using German as an example: `i18n/de.toml`. @@ -264,7 +265,7 @@ Teams must merge localized content into the same release branch from which the c An approver must maintain a development branch by keeping it current with its source branch and resolving merge conflicts. The longer a development branch stays open, the more maintenance it typically requires. Consider periodically merging development branches and opening new ones, rather than maintaining one extremely long-running development branch. -At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous development branch and the current development branch. +At the beginning of every team milestone, it's helpful to open an issue [comparing upstream changes](https://github.com/kubernetes/website/blob/master/scripts/upstream_changes.py) between the previous development branch and the current development branch. While only approvers can open a new development branch and merge pull requests, anyone can open a pull request for a new development branch. No special permissions are required. @@ -272,7 +273,7 @@ For more information about working from forks or directly from the repository, s ## Upstream contributions -SIG Docs welcomes [upstream contributions and corrections](/docs/contribute/intermediate#localize-content) to the English source. +SIG Docs welcomes upstream contributions and corrections to the English source. ## Help an existing localization diff --git a/content/en/docs/contribute/new-content/_index.md b/content/en/docs/contribute/new-content/_index.md new file mode 100644 index 0000000000..4992a37654 --- /dev/null +++ b/content/en/docs/contribute/new-content/_index.md @@ -0,0 +1,4 @@ +--- +title: Contributing new content +weight: 20 +--- diff --git a/content/en/docs/contribute/new-content/blogs-case-studies.md b/content/en/docs/contribute/new-content/blogs-case-studies.md new file mode 100644 index 0000000000..2bfc7259ed --- /dev/null +++ b/content/en/docs/contribute/new-content/blogs-case-studies.md @@ -0,0 +1,60 @@ +--- +title: Submitting blog posts and case studies +linktitle: Blogs and case studies +slug: blogs-case-studies +content_template: templates/concept +weight: 30 +--- + + +{{% capture overview %}} + +Anyone can write a blog post and submit it for review. +Case studies require extensive review before they're approved. + +{{% /capture %}} + +{{% capture body %}} + +## Write a blog post + +Blog posts should not be +vendor pitches. They must contain content that applies broadly to +the Kubernetes community. The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post). + +To submit a blog post, you can either: + +- Use the +[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform) +- [Open a pull request](/docs/contribute/new-content/new-content/#fork-the-repo) with a new blog post. Create new blog posts in the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory. + +If you open a pull request, ensure that your blog post follows the correct naming conventions and frontmatter information: + +- The markdown file name must follow the format `YYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`. +- The front matter must include the following: + +```yaml +--- +layout: blog +title: "Your Title Here" +date: YYYY-MM-DD +slug: text-for-URL-link-here-no-spaces +--- +``` + +## Submit a case study + +Case studies highlight how organizations are using Kubernetes to solve +real-world problems. The Kubernetes marketing team and members of the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} collaborate with you on all case studies. + +Have a look at the source for the +[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies). + +Use the [Kubernetes case study submission form](https://www.cncf.io/people/end-user-community/) +to submit your proposal. + +{{% /capture %}} + +{{% capture whatsnext %}} + +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/contribute/new-content/new-features.md b/content/en/docs/contribute/new-content/new-features.md new file mode 100644 index 0000000000..2b886b350d --- /dev/null +++ b/content/en/docs/contribute/new-content/new-features.md @@ -0,0 +1,134 @@ +--- +title: Documenting a feature for a release +linktitle: Documenting for a release +content_template: templates/concept +main_menu: true +weight: 20 +card: + name: contribute + weight: 45 + title: Documenting a feature for a release +--- +{{% capture overview %}} + +Each major Kubernetes release introduces new features that require documentation. New releases also bring updates to existing features and documentation (such as upgrading a feature from alpha to beta). + +Generally, the SIG responsible for a feature submits draft documentation of the +feature as a pull request to the appropriate release branch of the +`kubernetes/website` repository, and someone on the SIG Docs team provides +editorial feedback or edits the draft directly. This section covers the branching +conventions and process used during a release by both groups. + +{{% /capture %}} + +{{% capture body %}} + +## For documentation contributors + +In general, documentation contributors don't write content from scratch for a release. +Instead, they work with the SIG creating a new feature to refine the draft documentation and make it release ready. + +After you've chosen a feature to document or assist, ask about it in the `#sig-docs` +Slack channel, in a weekly SIG Docs meeting, or directly on the PR filed by the +feature SIG. If you're given the go-ahead, you can edit into the PR using one of +the techniques described in +[Commit into another person's PR](/docs/contribute/review/for-approvers/#commit-into-another-persons-pr). + +### Find out about upcoming features + +To find out about upcoming features, attend the weekly SIG Release meeting (see +the [community](https://kubernetes.io/community/) page for upcoming meetings) +and monitor the release-specific documentation +in the [kubernetes/sig-release](https://github.com/kubernetes/sig-release/) +repository. Each release has a sub-directory in the [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases) +directory. The sub-directory contains a release schedule, a draft of the release +notes, and a document listing each person on the release team. + +The release schedule contains links to all other documents, meetings, +meeting minutes, and milestones relating to the release. It also contains +information about the goals and timeline of the release, and any special +processes in place for this release. Near the bottom of the document, several +release-related terms are defined. + +This document also contains a link to the **Feature tracking sheet**, which is +the official way to find out about all new features scheduled to go into the +release. + +The release team document lists who is responsible for each release role. If +it's not clear who to talk to about a specific feature or question you have, +either attend the release meeting to ask your question, or contact the release +lead so that they can redirect you. + +The release notes draft is a good place to find out about +specific features, changes, deprecations, and more about the release. The +content is not finalized until late in the release cycle, so use caution. + +### Feature tracking sheet + +The feature tracking sheet [for a given Kubernetes release](https://github.com/kubernetes/sig-release/tree/master/releases) +lists each feature that is planned for a release. +Each line item includes the name of the feature, a link to the feature's main +GitHub issue, its stability level (Alpha, Beta, or Stable), the SIG and +individual responsible for implementing it, whether it +needs docs, a draft release note for the feature, and whether it has been +merged. Keep the following in mind: + +- Beta and Stable features are generally a higher documentation priority than + Alpha features. +- It's hard to test (and therefore to document) a feature that hasn't been merged, + or is at least considered feature-complete in its PR. +- Determining whether a feature needs documentation is a manual process and + just because a feature is not marked as needing docs doesn't mean it doesn't + need them. + +## For developers or other SIG members + +This section is information for members of other Kubernetes SIGs documenting new features +for a release. + +If you are a member of a SIG developing a new feature for Kubernetes, you need +to work with SIG Docs to be sure your feature is documented in time for the +release. Check the +[feature tracking spreadsheet](https://github.com/kubernetes/sig-release/tree/master/releases) +or check in the `#sig-release` Kubernetes Slack channel to verify scheduling details and +deadlines. + +### Open a placeholder PR + +1. Open a pull request against the +`release-X.Y` branch in the `kubernetes/website` repository, with a small +commit that you will amend later. +2. Use the Prow command `/milestone X.Y` to +assign the PR to the relevant milestone. This alerts the docs person managing +this release that the feature docs are coming. + +If your feature does not need +any documentation changes, make sure the sig-release team knows this, by +mentioning it in the `#sig-release` Slack channel. If the feature does need +documentation but the PR is not created, the feature may be removed from the +milestone. + +### PR ready for review + +When ready, populate your placeholder PR with feature documentation. + +Do your best to describe your feature and how to use it. If you need help structuring your documentation, ask in the `#sig-docs` slack channel. + +When you complete your content, the documentation person assigned to your feature reviews it. Use their suggestions to get the content to a release ready state. + +If your feature needs documentation and the first draft +content is not received, the feature may be removed from the milestone. + +### All PRs reviewed and ready to merge + +If your PR has not yet been merged into the `release-X.Y` branch by the release deadline, work with the +docs person managing the release to get it in by the deadline. If your feature needs +documentation and the docs are not ready, the feature may be removed from the +milestone. + +If your feature is an Alpha feature and is behind a feature gate, make sure you +add it to [Alpha/Beta Feature gates](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) table +as part of your pull request. If your feature is moving out of Alpha, make sure to +remove it from that table. + +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md new file mode 100644 index 0000000000..d9f670ca44 --- /dev/null +++ b/content/en/docs/contribute/new-content/open-a-pr.md @@ -0,0 +1,484 @@ +--- +title: Opening a pull request +slug: new-content +content_template: templates/concept +weight: 10 +card: + name: contribute + weight: 40 +--- + +{{% capture overview %}} + +{{< note >}} +**Code developers**: If you are documenting a new feature for an +upcoming Kubernetes release, see +[Document a new feature](/docs/contribute/new-content/new-features/). +{{< /note >}} + +To contribute new content pages or improve existing content pages, open a pull request (PR). Make sure you follow all the requirements in the [Before you begin](#before-you-begin) section. + +If your change is small, or you're unfamiliar with git, read [Changes using GitHub](#changes-using-github) to learn how to edit a page. + +If your changes are large, read [Work from a local fork](#fork-the-repo) to learn how to make changes locally on your computer. + +{{% /capture %}} + +{{% capture body %}} + +## Changes using GitHub + +If you're less experienced with git workflows, here's an easier method of +opening a pull request. + +1. On the page where you see the issue, select the pencil icon at the top right. + You can also scroll to the bottom of the page and select **Edit this page**. + +2. Make your changes in the GitHub markdown editor. + +3. Below the editor, fill in the **Propose file change** + form. In the first field, give your commit message a title. In + the second field, provide a description. + + {{< note >}} + Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request + description later. + {{< /note >}} + +4. Select **Propose file change**. + +5. Select **Create pull request**. + +6. The **Open a pull request** screen appears. Fill in the form: + + - The **Subject** field of the pull request defaults to the commit summary. + You can change it if needed. + - The **Body** contains your extended commit message, if you have one, + and some template text. Add the + details the template text asks for, then delete the extra template text. + - Leave the **Allow edits from maintainers** checkbox selected. + + {{< note >}} + PR descriptions are a great way to help reviewers understand your change. For more information, see [Opening a PR](#open-a-pr). + {{}} + +7. Select **Create pull request**. + +### Addressing feedback in GitHub + +Before merging a pull request, Kubernetes community members review and +approve it. The `k8s-ci-robot` suggests reviewers based on the nearest +owner mentioned in the pages. If you have someone specific in mind, +leave a comment with their GitHub username in it. + +If a reviewer asks you to make changes: + +1. Go to the **Files changed** tab. +2. Select the pencil (edit) icon on any files changed by the +pull request. +3. Make the changes requested. +4. Commit the changes. + +If you are waiting on a reviewer, reach out once every 7 days. You can also post a message in the `#sig-docs` Slack channel. + +When your review is complete, a reviewer merges your PR and your changes go live a few minutes later. + +## Work from a local fork {#fork-the-repo} + +If you're more experienced with git, or if your changes are larger than a few lines, +work from a local fork. + +Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your computer. You can also use a git UI application. + +### Fork the kubernetes/website repository + +1. Navigate to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository. +2. Select **Fork**. + +### Create a local clone and set the upstream + +3. In a terminal window, clone your fork: + + ```bash + git clone git@github.com//website + ``` + +4. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote: + + ```bash + cd website + + git remote add upstream https://github.com/kubernetes/website.git + ``` + +5. Confirm your `origin` and `upstream` repositories: + + ```bash + git remote -v + ``` + + Output is similar to: + + ```bash + origin git@github.com:/website.git (fetch) + origin git@github.com:/website.git (push) + upstream https://github.com/kubernetes/website (fetch) + upstream https://github.com/kubernetes/website (push) + ``` + +6. Fetch commits from your fork's `origin/master` and `kubernetes/website`'s `upstream/master`: + + ```bash + git fetch origin + git fetch upstream + ``` + + This makes sure your local repository is up to date before you start making changes. + + {{< note >}} + This workflow is different than the [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). You do not need to merge your local copy of `master` with `upstream/master` before pushing updates to your fork. + {{< /note >}} + +### Create a branch + +1. Decide which branch base to your work on: + + - For improvements to existing content, use `upstream/master`. + - For new content about existing features, use `upstream/master`. + - For localized content, use the localization's conventions. For more information, see [localizing Kubernetes documentation](/docs/contribute/localization/). + - For new features in an upcoming Kubernetes release, use the feature branch. For more information, see [documenting for a release](/docs/contribute/new-content/new-features/). + - For long-running efforts that multiple SIG Docs contributors collaborate on, + like content reorganization, use a specific feature branch created for that + effort. + + If you need help choosing a branch, ask in the `#sig-docs` Slack channel. + +2. Create a new branch based on the branch identified in step 1. This example assumes the base branch is `upstream/master`: + + ```bash + git checkout -b upstream/master + ``` + +3. Make your changes using a text editor. + +At any time, use the `git status` command to see what files you've changed. + +### Commit your changes + +When you are ready to submit a pull request, commit your changes. + +1. In your local repository, check which files you need to commit: + + ```bash + git status + ``` + + Output is similar to: + + ```bash + On branch + Your branch is up to date with 'origin/'. + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: content/en/docs/contribute/new-content/contributing-content.md + + no changes added to commit (use "git add" and/or "git commit -a") + ``` + +2. Add the files listed under **Changes not staged for commit** to the commit: + + ```bash + git add + ``` + + Repeat this for each file. + +3. After adding all the files, create a commit: + + ```bash + git commit -m "Your commit message" + ``` + + {{< note >}} + Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request + description later. + {{< /note >}} + +4. Push your local branch and its new commit to your remote fork: + + ```bash + git push origin + ``` + +### Preview your changes locally {#preview-locally} + +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. + +{{< tabs name="tab_with_hugo" >}} +{{% tab name="Hugo in a container" %}} + +1. Build the image locally: + + ```bash + make docker-image + ``` + +2. After building the `kubernetes-hugo` image locally, build and serve the site: + + ```bash + make docker-serve + ``` + +3. In a web browser, navigate to `https://localhost:1313`. Hugo watches the + changes and rebuilds the site as needed. + +4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, + or close the terminal window. + +{{% /tab %}} +{{% tab name="Hugo on the command line" %}} + +Alternately, install and use the `hugo` command on your computer: + +5. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml). + +6. In a terminal, go to your Kubernetes website repository and start the Hugo server: + + ```bash + cd /website + hugo server + ``` + +7. In your browser’s address bar, enter `https://localhost:1313`. + +8. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, + or close the terminal window. + +{{% /tab %}} +{{< /tabs >}} + +### Open a pull request from your fork to kubernetes/website {#open-a-pr} + +1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository. +2. Select **New Pull Request**. +3. Select **compare across forks**. +4. From the **head repository** drop-down menu, select your fork. +5. From the **compare** drop-down menu, select your branch. +6. Select **Create Pull Request**. +7. Add a description for your pull request: + - **Title** (50 characters or less): Summarize the intent of the change. + - **Description**: Describe the change in more detail. + - If there is a related GitHub issue, include `Fixes #12345` or `Closes #12345` in the description. GitHub's automation closes the mentioned issue after merging the PR if used. If there are other related PRs, link those as well. + - If you want advice on something specific, include any questions you'd like reviewers to think about in your description. + +8. Select the **Create pull request** button. + + Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls). + + +After opening a PR, GitHub runs automated tests and tries to deploy a preview using [Netlify](https://www.netlify.com/). + + - If the Netlify build fails, select **Details** for more information. + - If the Netlify build succeeds, select **Details** opens a staged version of the Kubernetes website with your changes applied. This is how reviewers check your changes. + +GitHub also automatically assigns labels to a PR, to help reviewers. You can add them too, if needed. For more information, see [Adding and removing issue labels](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels). + +### Addressing feedback locally + +1. After making your changes, amend your previous commit: + + ```bash + git commit -a --amend + ``` + + - `-a`: commits all changes + - `--amend`: amends the previous commit, rather than creating a new one + +2. Update your commit message if needed. + +3. Use `git push origin ` to push your changes and re-run the Netlify tests. + + {{< note >}} + If you use `git commit -m` instead of amending, you must [squash your commits](#squashing-commits) before merging. + {{< /note >}} + +#### Changes from reviewers + +Sometimes reviewers commit to your pull request. Before making any other changes, fetch those commits. + +1. Fetch commits from your remote fork and rebase your working branch: + + ```bash + git fetch origin + git rebase origin/ + ``` + +2. After rebasing, force-push new changes to your fork: + + ```bash + git push --force-with-lease origin + ``` + +#### Merge conflicts and rebasing + +{{< note >}} +For more information, see [Git Branching - Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [Advanced Merging](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging), or ask in the `#sig-docs` Slack channel for help. +{{< /note >}} + +If another contributor commits changes to the same file in another PR, it can create a merge conflict. You must resolve all merge conflicts in your PR. + +1. Update your fork and rebase your local branch: + + ```bash + git fetch origin + git rebase origin/ + ``` + + Then force-push the changes to your fork: + + ```bash + git push --force-with-lease origin + ``` + +2. Fetch changes from `kubernetes/website`'s `upstream/master` and rebase your branch: + + ```bash + git fetch upstream + git rebase upstream/master + ``` + +3. Inspect the results of the rebase: + + ```bash + git status + ``` + + This results in a number of files marked as conflicted. + +4. Open each conflicted file and look for the conflict markers: `>>>`, `<<<`, and `===`. Resolve the conflict and delete the conflict marker. + + {{< note >}} + For more information, see [How conflicts are presented](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented). + {{< /note >}} + +5. Add the files to the changeset: + + ```bash + git add + ``` +6. Continue the rebase: + + ```bash + git rebase --continue + ``` + +7. Repeat steps 2 to 5 as needed. + + After applying all commits, the `git status` command shows that the rebase is complete. + +8. Force-push the branch to your fork: + + ```bash + git push --force-with-lease origin + ``` + + The pull request no longer shows any conflicts. + + +### Squashing commits + +{{< note >}} +For more information, see [Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History), or ask in the `#sig-docs` Slack channel for help. +{{< /note >}} + +If your PR has multiple commits, you must squash them into a single commit before merging your PR. You can check the number of commits on your PR's **Commits** tab or by running the `git log` command locally. + +{{< note >}} +This topic assumes `vim` as the command line text editor. +{{< /note >}} + +1. Start an interactive rebase: + + ```bash + git rebase -i HEAD~ + ``` + + Squashing commits is a form of rebasing. The `-i` switch tells git you want to rebase interactively. `HEAD~}} + For more information, see [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode). + {{< /note >}} + +2. Start editing the file. + + Change the original text: + + ```bash + pick d875112ca Original commit + pick 4fa167b80 Address feedback 1 + pick 7d54e15ee Address feedback 2 + ``` + + To: + + ```bash + pick d875112ca Original commit + squash 4fa167b80 Address feedback 1 + squash 7d54e15ee Address feedback 2 + ``` + + This squashes commits `4fa167b80 Address feedback 1` and `7d54e15ee Address feedback 2` into `d875112ca Original commit`, leaving only `d875112ca Original commit` as a part of the timeline. + +3. Save and exit your file. + +4. Push your squashed commit: + + ```bash + git push --force-with-lease origin + ``` + +## Contribute to other repos + +The [Kubernetes project](https://github.com/kubernetes) contains 50+ repositories. Many of these repositories contain documentation: user-facing help text, error messages, API references or code comments. + +If you see text you'd like to improve, use GitHub to search all repositories in the Kubernetes organization. +This can help you figure out where to submit your issue or PR. + +Each repository has its own processes and procedures. Before you file an +issue or submit a PR, read that repository's `README.md`, `CONTRIBUTING.md`, and +`code-of-conduct.md`, if they exist. + +Most repositories use issue and PR templates. Have a look through some open +issues and PRs to get a feel for that team's processes. Make sure to fill out +the templates with as much detail as possible when you file issues or PRs. + +{{% /capture %}} + +{{% capture whatsnext %}} + +- Read [Reviewing](/docs/contribute/reviewing/revewing-prs) to learn more about the review process. + +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/contribute/new-content/overview.md b/content/en/docs/contribute/new-content/overview.md new file mode 100644 index 0000000000..7a5043d56c --- /dev/null +++ b/content/en/docs/contribute/new-content/overview.md @@ -0,0 +1,73 @@ +--- +title: Contributing new content overview +linktitle: Overview +content_template: templates/concept +main_menu: true +weight: 5 +--- + +{{% capture overview %}} + +This section contains information you should know before contributing new content. + + +{{% /capture %}} + +{{% capture body %}} + +## Contributing basics + +- Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/). +- The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory. +- [Page templates](/docs/contribute/style/page-templates/) control the presentation of documentation content in Hugo. +- In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content. +- Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`. +- For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization). + +## Before you begin {#before-you-begin} + +### Sign the CNCF CLA {#sign-the-cla} + +All Kubernetes contributors **must** read the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md). + +Pull requests from contributors who haven't signed the CLA fail the automated tests. + +### Configure commit signoffs + +All commits to Kubernetes repositories must be _signed off_ using the Git `--signoff` or `-s` flag. +The signoff acknowledges that you have the rights to submit contributions under the same +license and [Developer Certificate of Origin](https://developercertificate.org/). + +If you're using a Git UI app, you can use the app's commit template functionality if it +exists, or add the following to your commit message body: + +``` +Signed-off-by: Your Name +``` + +In both cases, the name and email you provide must match those found in your `git config`, and your git name and email must match those used for the CNCF CLA. + +### Choose which Git branch to use + +When opening a pull request, you need to know in advance which branch to base your work on. + +Scenario | Branch +:---------|:------------ +Existing or new English language content for the current release | `master` +Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-release-`. For example, if a feature changes in the `{{< latest-version >}}` release, then add documentation changes to the ``dev-{{< release-branch >}}`` branch. +Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information. + + +If you're still not sure which branch to choose, ask in `#sig-docs` on Slack. + +{{< note >}} +If you already submitted your pull request and you know that the base branch +was wrong, you (and only you, the submitter) can change it. +{{< /note >}} + +### Languages per PR + +Limit pull requests to one language per PR. If you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language. + + +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/contribute/participating.md b/content/en/docs/contribute/participating.md index ac384c8eed..3f491dc856 100644 --- a/content/en/docs/contribute/participating.md +++ b/content/en/docs/contribute/participating.md @@ -1,9 +1,10 @@ --- title: Participating in SIG Docs content_template: templates/concept +weight: 60 card: name: contribute - weight: 40 + weight: 60 --- {{% capture overview %}} @@ -35,7 +36,7 @@ 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/start#sign-the-cla) and have a GitHub account. +- **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 @@ -61,7 +62,7 @@ Anyone can do the following: 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/start#sign-the-cla), anyone can also: +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 @@ -307,7 +308,8 @@ SIG Docs approvers. Here's how it works. For more information about contributing to the Kubernetes documentation, see: -- [Start contributing](/docs/contribute/start/) -- [Documentation style](/docs/contribute/style/) +- [Contributing new content](/docs/contribute/overview/) +- [Reviewing content](/docs/contribute/review/reviewing-prs) +- [Documentation style guide](/docs/contribute/style/) {{% /capture %}} diff --git a/content/en/docs/contribute/review/_index.md b/content/en/docs/contribute/review/_index.md new file mode 100644 index 0000000000..bc70e3c6f1 --- /dev/null +++ b/content/en/docs/contribute/review/_index.md @@ -0,0 +1,14 @@ +--- +title: Reviewing changes +weight: 30 +--- + +{{% capture overview %}} + +This section describes how to review content. + +{{% /capture %}} + +{{% capture body %}} + +{{% /capture %}} diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md new file mode 100644 index 0000000000..f2be84f10d --- /dev/null +++ b/content/en/docs/contribute/review/for-approvers.md @@ -0,0 +1,228 @@ +--- +title: Reviewing for approvers and reviewers +linktitle: For approvers and reviewers +slug: for-approvers +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +SIG Docs [Reviewers](/docs/contribute/participating/#reviewers) and [Approvers](/docs/contribute/participating/#approvers) do a few extra things when reviewing a change. + +Every week a specific docs approver volunteers to triage +and review pull requests. This +person is the "PR Wrangler" for the week. See the +[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers) for more information. To become a PR Wrangler, attend the weekly SIG Docs meeting and volunteer. Even if you are not on the schedule for the current week, you can still review pull +requests (PRs) that are not already under active review. + +In addition to the rotation, a bot assigns reviewers and approvers +for the PR based on the owners for the affected files. + +{{% /capture %}} + + +{{% capture body %}} + +## Reviewing a PR + +Kubernetes documentation follows the [Kubernetes code review process](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process). + +Everything described in [Reviewing a pull request](/docs/contribute/review/reviewing-prs) applies, but Reviewers and Approvers should also do the following: + +- Using the `/assign` Prow command to assign a specific reviewer to a PR as needed. This is extra important +when it comes to requesting technical review from code contributors. + + {{< note >}} + Look at the `reviewers` field in the front-matter at the top of a Markdown file to see who can + provide technical review. + {{< /note >}} + +- Making sure the PR follows the [Content](/docs/contribute/style/content-guide/) and [Style](/docs/contribute/style/style-guide/) guides; link the author to the relevant part of the guide(s) if it doesn't. +- Using the GitHub **Request Changes** option when applicable to suggest changes to the PR author. +- Changing your review status in GitHub using the `/approve` or `/lgtm` Prow commands, if your suggestions are implemented. + +## Commit into another person's PR + +Leaving PR comments is helpful, but there might be times when you need to commit +into another person's PR instead. + +Do not "take over" for another person unless they explicitly ask +you to, or you want to resurrect a long-abandoned PR. While it may be faster +in the short term, it deprives the person of the chance to contribute. + +The process you use depends on whether you need to edit a file that is already +in the scope of the PR, or a file that the PR has not yet touched. + +You can't commit into someone else's PR if either of the following things is +true: + +- If the PR author pushed their branch directly to the + [https://github.com/kubernetes/website/](https://github.com/kubernetes/website/) + repository. Only a reviewer with push access can commit to another user's PR. + + {{< note >}} + Encourage the author to push their branch to their fork before + opening the PR next time. + {{< /note >}} + +- The PR author explicitly disallows edits from approvers. + +## Prow commands for reviewing + +[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md) is +the Kubernetes-based CI/CD system that runs jobs against pull requests (PRs). Prow +enables chatbot-style commands to handle GitHub actions across the Kubernetes +organization, like [adding and removing +labels](#add-and-remove-labels), closing issues, and assigning an approver. Enter Prow commands as GitHub comments using the `/` format. + +The most common prow commands reviewers and approvers use are: + +{{< table caption="Prow commands for reviewing" >}} +Prow Command | Role Restrictions | Description +:------------|:------------------|:----------- +`/lgtm` | Anyone, but triggers automation if a Reviewer or Approver uses it | Signals that you've finished reviewing a PR and are satisfied with the changes. +`/approve` | Approvers | Approves a PR for merging. +`/assign` | Reviewers or Approvers | Assigns a person to review or approve a PR +`/close` | Reviewers or Approvers | Closes an issue or PR. +`/hold` | Anyone | Adds the `do-not-merge/hold` label, indicating the PR cannot be automatically merged. +`/hold cancel` | Anyone | Removes the `do-not-merge/hold` label. +{{< /table >}} + +See [the Prow command reference](https://prow.k8s.io/command-help) to see the full list +of commands you can use in a PR. + +## Triage and categorize issues + + +In general, SIG Docs follows the [Kubernetes issue triage](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md) process and uses the same labels. + + +This GitHub Issue [filter](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc) +finds issues that might need triage. + +### Triaging an issue + +1. Validate the issue + - Make sure the issue is about website documentation. Some issues can be closed quickly by + answering a question or pointing the reporter to a resource. See the + [Support requests or code bug reports](#support-requests-or-code-bug-reports) section for details. + - Assess whether the issue has merit. + - Add the `triage/needs-information` label if the issue doesn't have enough + detail to be actionable or the template is not filled out adequately. + - Close the issue if it has both the `lifecycle/stale` and `triage/needs-information` labels. + +2. Add a priority label (the + [Issue Triage Guidelines](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority) define priority labels in detail) + + {{< table caption="Issue labels" >}} + Label | Description + :------------|:------------------ + `priority/critical-urgent` | Do this right now. + `priority/important-soon` | Do this within 3 months. + `priority/important-longterm` | Do this within 6 months. + `priority/backlog` | Deferrable indefinitely. Do when resources are available. + `priority/awaiting-more-evidence` | Placeholder for a potentially good issue so it doesn't get lost. + `help` or `good first issue` | Suitable for someone with very little Kubernetes or SIG Docs experience. See [Help Wanted and Good First Issue Labels](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md) for more information. + + {{< /table >}} + + At your discretion, take ownership of an issue and submit a PR for it + (especially if it's quick or relates to work you're already doing). + +If you have questions about triaging an issue, ask in `#sig-docs` on Slack or +the [kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + +## Adding and removing issue labels + +To add a label, leave a comment in one of the following formats: + +- `/` (for example, `/good-first-issue`) +- `/ ` (for example, `/triage needs-information` or `/language ja`) + +To remove a label, leave a comment in one of the following formats: + +- `/remove-` (for example, `/remove-help`) +- `/remove- ` (for example, `/remove-triage needs-information`)` + +In both cases, the label must already exist. If you try to add a label that does not exist, the command is +silently ignored. + +For a list of all labels, see the [website repository's Labels section](https://github.com/kubernetes/website/labels). Not all labels are used by SIG Docs. + +### Issue lifecycle labels + +Issues are generally opened and closed quickly. +However, sometimes an issue is inactive after its opened. +Other times, an issue may need to remain open for longer than 90 days. + +{{< table caption="Issue lifecycle labels" >}} +Label | Description +:------------|:------------------ +`lifecycle/stale` | After 90 days with no activity, an issue is automatically labeled as stale. The issue will be automatically closed if the lifecycle is not manually reverted using the `/remove-lifecycle stale` command. +`lifecycle/frozen` | An issue with this label will not become stale after 90 days of inactivity. A user manually adds this label to issues that need to remain open for much longer than 90 days, such as those with a `priority/important-longterm` label. +{{< /table >}} + +## Handling special issue types + +SIG Docs encounters the following types of issues often enough to document how +to handle them. + +### Duplicate issues + +If a single problem has one or more issues open for it, combine them into a single issue. +You should decide which issue to keep open (or +open a new issue), then move over all relevant information and link related issues. +Finally, label all other issues that describe the same problem with +`triage/duplicate` and close them. Only having a single issue to work on reduces confusion +and avoids duplicate work on the same problem. + +### Dead link issues + +If the dead link issue is in the API or `kubectl` documentation, assign them `/priority critical-urgent` until the problem is fully understood. Assign all other dead link issues `/priority important-longterm`, as they must be manually fixed. + +### Blog issues + +We expect [Kubernetes Blog](https://kubernetes.io/blog/) entries to become +outdated over time. Therefore, we only maintain blog entries less than a year old. +If an issue is related to a blog entry that is more than one year old, +close the issue without fixing. + +### Support requests or code bug reports + +Some docs issues are actually issues with the underlying code, or requests for +assistance when something, for example a tutorial, doesn't work. +For issues unrelated to docs, close the issue with the `triage/support` label and a comment +directing the requester to support venues (Slack, Stack Overflow) and, if +relevant, the repository to file an issue for bugs with features (`kubernetes/kubernetes` +is a great place to start). + +Sample response to a request for support: + +```none +This issue sounds more like a request for support and less +like an issue specifically for docs. I encourage you to bring +your question to the `#kubernetes-users` channel in +[Kubernetes slack](http://slack.k8s.io/). You can also search +resources like +[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +for answers to similar questions. + +You can also open issues for Kubernetes functionality in +https://github.com/kubernetes/kubernetes. + +If this is a documentation issue, please re-open this issue. +``` + +Sample code bug report response: + +```none +This sounds more like an issue with the code than an issue with +the documentation. Please open an issue at +https://github.com/kubernetes/kubernetes/issues. + +If this is a documentation issue, please re-open this issue. +``` + + +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md new file mode 100644 index 0000000000..cb432a97ba --- /dev/null +++ b/content/en/docs/contribute/review/reviewing-prs.md @@ -0,0 +1,98 @@ +--- +title: Reviewing pull requests +content_template: templates/concept +main_menu: true +weight: 10 +--- + +{{% capture overview %}} + +Anyone can review a documentation pull request. Visit the [pull requests](https://github.com/kubernetes/website/pulls) section in the Kubernetes website repository to see open pull requests. + +Reviewing documentation pull requests is a +great way to introduce yourself to the Kubernetes community. +It helps you learn the code base and build trust with other contributors. + +Before reviewing, it's a good idea to: + +- Read the [content guide](/docs/contribute/style/content-guide/) and +[style guide](/docs/contribute/style/style-guide/) so you can leave informed comments. +- Understand the different [roles and responsibilities](/docs/contribute/participating/#roles-and-responsibilities) in the Kubernetes documentation community. + +{{% /capture %}} + +{{% capture body %}} + +## Before you begin + +Before you start a review: + +- Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) and ensure that you abide by it at all times. +- Be polite, considerate, and helpful. +- Comment on positive aspects of PRs as well as changes. +- Be empathetic and mindful of how your review may be received. +- Assume good intent and ask clarifying questions. +- Experienced contributors, consider pairing with new contributors whose work requires extensive changes. + +## Review process + +In general, review pull requests for content and style in English. + +1. Go to + [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls). + You see a list of every open pull request against the Kubernetes website and + docs. + +2. Filter the open PRs using one or all of the following labels: + - `cncf-cla: yes` (Recommended): PRs submitted by contributors who have not signed the CLA cannot be merged. See [Sign the CLA](/docs/contribute/new-content/overview/#sign-the-cla) for more information. + - `language/en` (Recommended): Filters for english language PRs only. + - `size/`: filters for PRs of a certain size. If you're new, start with smaller PRs. + + Additionally, ensure the PR isn't marked as a work in progress. PRs using the `work in progress` label are not ready for review yet. + +3. Once you've selected a PR to review, understand the change by: + - Reading the PR description to understand the changes made, and read any linked issues + - Reading any comments by other reviewers + - Clicking the **Files changed** tab to see the files and lines changed + - Previewing the changes in the Netlify preview build by scrolling to the PR's build check section at the bottom of the **Conversation** tab and clicking the **deploy/netlify** line's **Details** link. + +4. Go to the **Files changed** tab to start your review. + 1. Click on the `+` symbol beside the line you want to comment on. + 2. Fill in any comments you have about the line and click either **Add single comment** (if you have only one comment to make) or **Start a review** (if you have multiple comments to make). + 3. When finished, click **Review changes** at the top of the page. Here, you can add + add a summary of your review (and leave some positive comments for the contributor!), + approve the PR, comment or request changes as needed. New contributors should always + choose **Comment**. + +## Reviewing checklist + +When reviewing, use the following as a starting point. + +### Language and grammar + +- Are there any obvious errors in language or grammar? Is there a better way to phrase something? +- Are there any complicated or archaic words which could be replaced with a simpler word? +- Are there any words, terms or phrases in use which could be replaced with a non-discriminatory alternative? +- Does the word choice and its capitalization follow the [style guide](/docs/contribute/style/style-guide/)? +- Are there long sentences which could be shorter or less complex? +- Are there any long paragraphs which might work better as a list or table? + +### Content + +- Does similar content exist elsewhere on the Kubernetes site? +- Does the content excessively link to off-site, individual vendor or non-open source documentation? + +### Website + +- Did this PR change or remove a page title, slug/alias or anchor link? If so, are there broken links as a result of this PR? Is there another option, like changing the page title without changing the slug? +- Does the PR introduce a new page? If so: + - Is the page using the right [page template](/docs/contribute/style/page-templates/) and associated Hugo shortcodes? + - Does the page appear correctly in the section's side navigation (or at all)? + - Should the page appear on the [Docs Home](/docs/home/) listing? +- Do the changes show up in the Netlify preview? Be particularly vigilant about lists, code blocks, tables, notes and images. + +### Other + +For small issues with a PR, like typos or whitespace, prefix your comments with `nit:`. This lets the author know the issue is non-critical. + +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/contribute/start.md b/content/en/docs/contribute/start.md deleted file mode 100644 index 181e359682..0000000000 --- a/content/en/docs/contribute/start.md +++ /dev/null @@ -1,421 +0,0 @@ ---- -title: Start contributing -slug: start -content_template: templates/concept -weight: 10 -card: - name: contribute - weight: 10 ---- - -{{% capture overview %}} - -If you want to get started contributing to the Kubernetes documentation, this -page and its linked topics can help you get started. You don't need to be a -developer or a technical writer to make a big impact on the Kubernetes -documentation and user experience! All you need for the topics on this page is -a [GitHub account](https://github.com/join) and a web browser. - -If you're looking for information on how to start contributing to Kubernetes -code repositories, refer to -[the Kubernetes community guidelines](https://github.com/kubernetes/community/blob/master/governance.md). - -{{% /capture %}} - - -{{% capture body %}} - -## The basics about our docs - -The Kubernetes documentation is written in Markdown and processed and deployed using Hugo. The source is in GitHub at [https://github.com/kubernetes/website](https://github.com/kubernetes/website). Most of the documentation source is stored in `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory. - -You can file issues, edit content, and review changes from others, all from the -GitHub website. You can also use GitHub's embedded history and search tools. - -Not all tasks can be done in the GitHub UI, but these are discussed in the -[intermediate](/docs/contribute/intermediate/) and -[advanced](/docs/contribute/advanced/) docs contribution guides. - -### Participating in SIG Docs - -The Kubernetes documentation is maintained by a -{{< glossary_tooltip text="Special Interest Group" term_id="sig" >}} (SIG) -called SIG Docs. We [communicate](#participate-in-sig-docs-discussions) using a Slack channel, a mailing list, and -weekly video meetings. New participants are welcome. For more information, see -[Participating in SIG Docs](/docs/contribute/participating/). - -### Content guidelines - -The SIG Docs community created guidelines about what kind of content is allowed -in the Kubernetes documentation. Look over the [Documentation Content -Guide](/docs/contribute/style/content-guide/) to determine if the content -contribution you want to make is allowed. You can ask questions about allowed -content in the [#sig-docs](#participate-in-sig-docs-discussions) Slack -channel. - -### Style guidelines - -We maintain a [style guide](/docs/contribute/style/style-guide/) with information -about choices the SIG Docs community has made about grammar, syntax, source -formatting, and typographic conventions. Look over the style guide before you -make your first contribution, and use it when you have questions. - -Changes to the style guide are made by SIG Docs as a group. To propose a change -or addition, [add it to the agenda](https://docs.google.com/document/d/1ddHwLK3kUMX1wVFIwlksjTk0MsqitBnWPe1LRa1Rx5A/edit) for an upcoming SIG Docs meeting, and attend the meeting to participate in the -discussion. See the [advanced contribution](/docs/contribute/advanced/) topic for more -information. - -### Page templates - -We use page templates to control the presentation of our documentation pages. -Be sure to understand how these templates work by reviewing -[Using page templates](/docs/contribute/style/page-templates/). - -### Hugo shortcodes - -The Kubernetes documentation is transformed from Markdown to HTML using Hugo. -We make use of the standard Hugo shortcodes, as well as a few that are custom to -the Kubernetes documentation. See [Custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) for -information about how to use them. - -### Multiple languages - -Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`. - -For more information about contributing to documentation in multiple languages, see ["Localize content"](/docs/contribute/intermediate#localize-content) in the intermediate contributing guide. - -If you're interested in starting a new localization, see ["Localization"](/docs/contribute/localization/). - -## File actionable issues - -Anyone with a GitHub account can file an issue (bug report) against the -Kubernetes documentation. If you see something wrong, even if you have no idea -how to fix it, [file an issue](#how-to-file-an-issue). The exception to this -rule is a tiny bug like a typo that you intend to fix yourself. In that case, -you can instead [fix it](#improve-existing-content) without filing a bug first. - -### How to file an issue - -- **On an existing page** - - If you see a problem in an existing page in the [Kubernetes docs](/docs/), - go to the bottom of the page and click the **Create an Issue** button. If - you are not currently logged in to GitHub, log in. A GitHub issue form - appears with some pre-populated content. - - Using Markdown, fill in as many details as you can. In places where you see - empty square brackets (`[ ]`), put an `x` between the set of brackets that - represents the appropriate choice. If you have a proposed solution to fix - the issue, add it. - -- **Request a new page** - - If you think content should exist, but you aren't sure where it should go or - you don't think it fits within the pages that currently exist, you can - still file an issue. You can either choose an existing page near where you think the - new content should go and file the issue from that page, or go straight to - [https://github.com/kubernetes/website/issues/new/](https://github.com/kubernetes/website/issues/new/) - and file the issue from there. - -### How to file great issues - -To ensure that we understand your issue and can act on it, keep these guidelines -in mind: - -- Use the issue template, and fill out as many details as you can. -- Clearly explain the specific impact the issue has on users. -- Limit the scope of a given issue to a reasonable unit of work. For problems - with a large scope, break them down into smaller issues. - - For instance, "Fix the security docs" is not an actionable issue, but "Add - details to the 'Restricting network access' topic" might be. -- If the issue relates to another issue or pull request, you can refer to it - either by its full URL or by the issue or pull request number prefixed - with a `#` character. For instance, `Introduced by #987654`. -- Be respectful and avoid venting. For instance, "The docs about X suck" is not - helpful or actionable feedback. The - [Code of Conduct](/community/code-of-conduct/) also applies to interactions on - Kubernetes GitHub repositories. - -## Participate in SIG Docs discussions - -The SIG Docs team communicates using the following mechanisms: - -- [Join the Kubernetes Slack instance](http://slack.k8s.io/), then join the - `#sig-docs` channel, where we discuss docs issues in real-time. Be sure to - introduce yourself! -- [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs), - where broader discussions take place and official decisions are recorded. -- Participate in the [weekly SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) video meeting, which is announced on the Slack channel and the mailing list. Currently, these meetings take place on Zoom, so you'll need to download the [Zoom client](https://zoom.us/download) or dial in using a phone. - -{{< note >}} -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 >}} - -## Improve existing content - -To improve existing content, you file a _pull request (PR)_ after creating a -_fork_. Those two terms are [specific to GitHub](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/). -For the purposes of this topic, you don't need to know everything about them, -because you can do everything using your web browser. When you continue to the -[intermediate docs contributor guide](/docs/contribute/intermediate/), you will -need more background in Git terminology. - -{{< note >}} -**Kubernetes code developers**: If you are documenting a new feature for an -upcoming Kubernetes release, your process is a bit different. See -[Document a feature](/docs/contribute/intermediate/#sig-members-documenting-new-features) for -process guidelines and information about deadlines. -{{< /note >}} - -### Sign the CNCF CLA {#sign-the-cla} - -Before you can contribute code or documentation to Kubernetes, you **must** read -the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and -[sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md). -Don't worry -- this doesn't take long! - -### Find something to work on - -If you see something you want to fix right away, just follow the instructions -below. You don't need to [file an issue](#file-actionable-issues) (although you -certainly can). - -If you want to start by finding an existing issue to work on, go to -[https://github.com/kubernetes/website/issues](https://github.com/kubernetes/website/issues) -and look for issues with the label `good first issue` (you can use -[this](https://github.com/kubernetes/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) shortcut). Read through the comments and make sure there is not an open pull -request against the issue and that nobody has left a comment saying they are -working on the issue recently (3 days is a good rule). Leave a comment saying -that you would like to work on the issue. - -### Choose which Git branch to use - -The most important aspect of submitting pull requests is choosing which branch -to base your work on. Use these guidelines to make the decision: - -- Use `master` for fixing problems in content that is already published, or - making improvements to content that already exists. -- Use `master` to document something that is already part of the current - Kubernetes release, but isn't yet documented. You should write this content - in English first, and then localization teams will pick that change up as a - localization task. -- If you're working on a localization, you should follow the convention for - that particular localization. To find this out, you can look at other - pull requests (tip: search for `is:pr is:merged label:language/xx`) - {{< comment >}}Localization note: when localizing that tip, replace `xx` - with the actual ISO3166 two-letter code for your target locale.{{< /comment >}} - - Some localization teams work with PRs that target `master` - - Some localization teams work with a series of long-lived branches, and - periodically merge these to `master`. This kind of branch has a name like - dev-\-\.\; for example: - `dev-{{< latest-semver >}}-ja.1` -- If you're writing or updating documentation for a feature change release, - then you need to know the major and minor version of Kubernetes that - the change will first appear in. - - For example, if the feature gate JustAnExample is going to move from alpha - to beta in the next minor version, you need to know what the next minor - version number is. - - Find the release branch named for that version. For example, features that - changed in the {{< latest-version >}} release got documented in the branch - named `dev-{{< latest-semver >}}`. - -If you're still not sure which branch to choose, ask in `#sig-docs` on Slack or -attend a weekly SIG Docs meeting to get clarity. - -{{< note >}} -If you already submitted your pull request and you know that the Base Branch -was wrong, you (and only you, the submitter) can change it. -{{< /note >}} - -### Submit a pull request - -Follow these steps to submit a pull request to improve the Kubernetes -documentation. - -1. On the page where you see the issue, click the pencil icon at the top right. - A new GitHub page appears, with some help text. -2. If you have never created a fork of the Kubernetes documentation - repository, you are prompted to do so. Create the fork under your GitHub - username, rather than another organization you may be a member of. The - fork usually has a URL such as `https://github.com//website`, - unless you already have a repository with a conflicting name. - - The reason you are prompted to create a fork is that you do not have - access to push a branch directly to the definitive Kubernetes repository. - -3. The GitHub Markdown editor appears with the source Markdown file loaded. - Make your changes. Below the editor, fill in the **Propose file change** - form. The first field is the summary of your commit message and should be - no more than 50 characters long. The second field is optional, but can - include more detail if appropriate. - - {{< note >}} -Do not include references to other GitHub issues or pull -requests in your commit message. You can add those to the pull request -description later. -{{< /note >}} - - Click **Propose file change**. The change is saved as a commit in a - new branch in your fork, which is automatically named something like - `patch-1`. - -4. The next screen summarizes the changes you made, by comparing your new - branch (the **head fork** and **compare** selection boxes) to the current - state of the **base fork** and **base** branch (`master` on the - `kubernetes/website` repository by default). You can change any of the - selection boxes, but don't do that now. Have a look at the difference - viewer on the bottom of the screen, and if everything looks right, click - **Create pull request**. - - {{< note >}} -If you don't want to create the pull request now, you can do it -later, by browsing to the main URL of the Kubernetes website repository or -your fork's repository. The GitHub website will prompt you to create the -pull request if it detects that you pushed a new branch to your fork. -{{< /note >}} - -5. The **Open a pull request** screen appears. The subject of the pull request - is the same as the commit summary, but you can change it if needed. The - body is populated by your extended commit message (if present) and some - template text. Read the template text and fill out the details it asks for, - then delete the extra template text. If you add to the description `fixes #<000000>` - or `closes #<000000>`, where `#<000000>` is the number of an associated issue, - GitHub will automatically close the issue when the PR merges. - Leave the **Allow edits from maintainers** checkbox selected. Click - **Create pull request**. - - Congratulations! Your pull request is available in - [Pull requests](https://github.com/kubernetes/website/pulls). - - After a few minutes, you can preview the website with your PR's changes - applied. Go to the **Conversation** tab of your PR and click the **Details** - link for the `deploy/netlify` test, near the bottom of the page. It opens in - the same browser window by default. - - {{< note >}} - Please limit pull requests to one language per PR. For example, if you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language. - {{< /note >}} - -6. Wait for review. Generally, reviewers are suggested by the `k8s-ci-robot`. - If a reviewer asks you to make changes, you can go to the **Files changed** - tab and click the pencil icon on any files that have been changed by the - pull request. When you save the changed file, a new commit is created in - the branch being monitored by the pull request. If you are waiting on a - reviewer to review the changes, proactively reach out to the reviewer - once every 7 days. You can also drop into #sig-docs Slack channel, - which is a good place to ask for help regarding PR reviews. - -7. If your change is accepted, a reviewer merges your pull request, and the - change is live on the Kubernetes website a few minutes later. - -This is only one way to submit a pull request. If you are already a Git and -GitHub advanced user, you can use a local GUI or command-line Git client -instead of using the GitHub UI. Some basics about using the command-line Git -client are discussed in the [intermediate](/docs/contribute/intermediate/) docs -contribution guide. - -## Review docs pull requests - -People who are new to documentation can still review pull requests. You can -learn the code base and build trust with your fellow contributors. English docs -are the authoritative source for content. We communicate in English during -weekly meetings and in community announcements. Contributors' English skills -vary, so use simple and direct language in your reviews. Effective reviews focus -on both small details and a change's potential impact. - -The reviews are not considered "binding", which means that your review alone -won't cause a pull request to be merged. However, it can still be helpful. Even -if you don't leave any review comments, you can get a sense of pull request -conventions and etiquette and get used to the workflow. Familiarize yourself with the -[content guide](/docs/contribute/style/content-guide/) and -[style guide](/docs/contribute/style/style-guide/) before reviewing so you -get an idea of what the content should contain and how it should look. - -### Best practices - -- Be polite, considerate, and helpful -- Comment on positive aspects of PRs as well -- Be empathetic and mindful of how your review may be received -- Assume good intent and ask clarifying questions -- Experienced contributors, consider pairing with new contributors whose work requires extensive changes - -### How to find and review a pull request - -1. Go to - [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls). - You see a list of every open pull request against the Kubernetes website and - docs. - -2. By default, the only filter that is applied is `open`, so you don't see - pull requests that have already been closed or merged. It's a good idea to - apply the `cncf-cla: yes` filter, and for your first review, it's a good - idea to add `size/S` or `size/XS`. The `size` label is applied automatically - based on how many lines of code the PR modifies. You can apply filters using - the selection boxes at the top of the page, or use - [this shortcut](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+yes%22+label%3Asize%2FS) for only small PRs. All filters are `AND`ed together, so - you can't search for both `size/XS` and `size/S` in the same query. - -3. Go to the **Files changed** tab. Look through the changes introduced in the - PR, and if applicable, also look at any linked issues. If you see a problem - or room for improvement, hover over the line and click the `+` symbol that - appears. - - You can type a comment, and either choose **Add single comment** or **Start - a review**. Typically, starting a review is better because it allows you to - leave multiple comments and notifies the PR owner only when you have - completed the review, rather than a separate notification for each comment. - -4. When finished, click **Review changes** at the top of the page. You can - summarize your review, and you can choose to comment, approve, or request - changes. New contributors should always choose **Comment**. - -Thanks for reviewing a pull request! When you are new to the project, it's a -good idea to ask for feedback on your pull request reviews. The `#sig-docs` -Slack channel is a great place to do this. - -## Write a blog post - -Anyone can write a blog post and submit it for review. Blog posts should not be -commercial in nature and should consist of content that will apply broadly to -the Kubernetes community. - -To submit a blog post, you can either submit it using the -[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform), -or follow the steps below. - -1. [Sign the CLA](#sign-the-cla) if you have not yet done so. -2. Have a look at the Markdown format for existing blog posts in the - [website repository](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts). -3. Write out your blog post in a text editor of your choice. -4. On the same link from step 2, click the **Create new file** button. Paste - your content into the editor. Name the file to match the proposed title of - the blog post, but don't put the date in the file name. The blog reviewers - will work with you on the final file name and the date the blog will be - published. -5. When you save the file, GitHub will walk you through the pull request - process. -6. A blog post reviewer will review your submission and work with you on - feedback and final details. When the blog post is approved, the blog will be - scheduled for publication. - -## Submit a case study - -Case studies highlight how organizations are using Kubernetes to solve -real-world problems. They are written in collaboration with the Kubernetes -marketing team, which is handled by the {{< glossary_tooltip text="CNCF" term_id="cncf" >}}. - -Have a look at the source for the -[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies). -Use the [Kubernetes case study submission form](https://www.cncf.io/people/end-user-community/) -to submit your proposal. - -{{% /capture %}} - -{{% capture whatsnext %}} - -When you are comfortable with all of the tasks discussed in this topic and you -want to engage with the Kubernetes docs team in deeper ways, read the -[intermediate docs contribution guide](/docs/contribute/intermediate/). - -{{% /capture %}} diff --git a/content/en/docs/contribute/style/content-guide.md b/content/en/docs/contribute/style/content-guide.md index 18d469510c..bc4b5be64a 100644 --- a/content/en/docs/contribute/style/content-guide.md +++ b/content/en/docs/contribute/style/content-guide.md @@ -3,10 +3,6 @@ title: Documentation Content Guide linktitle: Content guide content_template: templates/concept weight: 10 -card: - name: contribute - weight: 20 - title: Documentation Content Guide --- {{% capture overview %}} diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md index 8cd3ed1e0f..60479c7fec 100644 --- a/content/en/docs/contribute/style/hugo-shortcodes/index.md +++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md @@ -243,4 +243,4 @@ Renders to: * Learn about [using page templates](/docs/home/contribute/page-templates/). * Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/) * Learn about [creating a pull request](/docs/home/contribute/create-pull-request/). -{{% /capture %}} \ No newline at end of file +{{% /capture %}} diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md index 26722e607f..34dce6adac 100644 --- a/content/en/docs/contribute/style/style-guide.md +++ b/content/en/docs/contribute/style/style-guide.md @@ -3,10 +3,6 @@ title: Documentation Style Guide linktitle: Style guide content_template: templates/concept weight: 10 -card: - name: contribute - weight: 20 - title: Documentation Style Guide --- {{% capture overview %}} @@ -15,10 +11,12 @@ These are guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request. For additional information on creating new content for the Kubernetes -documentation, read the [Documentation Content -Guide](/docs/contribute/style/content-guide/) and follow the instructions on -[using page templates](/docs/contribute/style/page-templates/) and [creating a -documentation pull request](/docs/contribute/start/#improve-existing-content). +documentation, read the [Documentation Content Guide](/docs/contribute/style/content-guide/) and follow the instructions on +[using page templates](/docs/contribute/style/page-templates/) and [creating a documentation pull request](/docs/contribute/new-content/open-a-pr). + +Changes to the style guide are made by SIG Docs as a group. To propose a change +or addition, [add it to the agenda](https://docs.google.com/document/d/1ddHwLK3kUMX1wVFIwlksjTk0MsqitBnWPe1LRa1Rx5A/edit) for an upcoming SIG Docs meeting, and attend the meeting to participate in the +discussion. {{% /capture %}} diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md index 50e49734a3..65dca22f1a 100644 --- a/content/en/docs/contribute/style/write-new-topic.md +++ b/content/en/docs/contribute/style/write-new-topic.md @@ -10,7 +10,7 @@ This page shows how to create a new topic for the Kubernetes docs. {{% capture prerequisites %}} Create a fork of the Kubernetes documentation repository as described in -[Start contributing](/docs/contribute/start/). +[Open a PR](/docs/new-content/open-a-pr/). {{% /capture %}} {{% capture steps %}} @@ -24,8 +24,8 @@ Type | Description :--- | :---------- Concept | A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application while it is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials. For an example of a concept topic, see Nodes. Task | A task page shows how to do a single thing. The idea is to give readers a sequence of steps that they can actually do as they read the page. A task page can be short or long, provided it stays focused on one area. In a task page, it is OK to blend brief explanations with the steps to be performed, but if you need to provide a lengthy explanation, you should do that in a concept topic. Related task and concept topics should link to each other. For an example of a short task page, see Configure a Pod to Use a Volume for Storage. For an example of a longer task page, see Configure Liveness and Readiness Probes -Tutorial | A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features. -{{< /table >}} +Tutorial | A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features. +{{< /table >}} Use a template for each new page. Each page type has a [template](/docs/contribute/style/page-templates/) @@ -162,7 +162,6 @@ image format is SVG. {{% /capture %}} {{% capture whatsnext %}} -* Learn about [using page templates](/docs/home/contribute/page-templates/). -* 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 [using page templates](/docs/contribute/page-templates/). +* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/). {{% /capture %}} diff --git a/content/en/docs/contribute/suggesting-improvements.md b/content/en/docs/contribute/suggesting-improvements.md new file mode 100644 index 0000000000..19133f379b --- /dev/null +++ b/content/en/docs/contribute/suggesting-improvements.md @@ -0,0 +1,65 @@ +--- +title: Suggesting content improvements +slug: suggest-improvements +content_template: templates/concept +weight: 10 +card: + name: contribute + weight: 20 +--- + +{{% capture overview %}} + +If you notice an issue with Kubernetes documentation, or have an idea for new content, then open an issue. All you need is a [GitHub account](https://github.com/join) and a web browser. + +In most cases, new work on Kubernetes documentation begins with an issue in GitHub. Kubernetes contributors +then review, categorize and tag issues as needed. Next, you or another member +of the Kubernetes community open a pull request with changes to resolve the issue. + +{{% /capture %}} + +{{% capture body %}} + +## Opening an issue + +If you want to suggest improvements to existing content, or notice an error, then open an issue. + +1. Go to the bottom of the page and click the **Create an Issue** button. This redirects you + to a GitHub issue page pre-populated with some headers. +2. Describe the issue or suggestion for improvement. Provide as many details as you can. +3. Click **Submit new issue**. + +After submitting, check in on your issue occasionally or turn on GitHub notifications. +Reviewers and other community members might ask questions before +they can take action on your issue. + +## Suggesting new content + +If you have an idea for new content, but you aren't sure where it should go, you can +still file an issue. Either: + +- Choose an existing page in the section you think the content belongs in and click **Create an issue**. +- Go to [GitHub](https://github.com/kubernetes/website/issues/new/) and file the issue directly. + +## How to file great issues + + +Keep the following in mind when filing an issue: + +- Provide a clear issue description. Describe what specifically is missing, out of date, + wrong, or needs improvement. +- Explain the specific impact the issue has on users. +- Limit the scope of a given issue to a reasonable unit of work. For problems + with a large scope, break them down into smaller issues. For example, "Fix the security docs" + is too broad, but "Add details to the 'Restricting network access' topic" is specific enough + to be actionable. +- Search the existing issues to see if there's anything related or similar to the + new issue. +- If the new issue relates to another issue or pull request, refer to it + either by its full URL or by the issue or pull request number prefixed + with a `#` character. For example, `Introduced by #987654`. +- Follow the [Code of Conduct](/community/code-of-conduct/). Respect your +fellow contributors. For example, "The docs are terrible" is not + helpful or polite feedback. + +{{% /capture %}} diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md index 1ca0b98b7c..eab71e4560 100644 --- a/content/en/docs/reference/access-authn-authz/rbac.md +++ b/content/en/docs/reference/access-authn-authz/rbac.md @@ -1182,7 +1182,7 @@ 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 DENY:`). +(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 diff --git a/content/en/docs/reference/glossary/cloud-controller-manager.md b/content/en/docs/reference/glossary/cloud-controller-manager.md index 974b8539df..0a74535857 100755 --- a/content/en/docs/reference/glossary/cloud-controller-manager.md +++ b/content/en/docs/reference/glossary/cloud-controller-manager.md @@ -4,7 +4,7 @@ id: cloud-controller-manager date: 2018-04-12 full_link: /docs/tasks/administer-cluster/running-cloud-controller/ short_description: > - Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud. + Cloud Controller Manager is a Kubernetes component that embeds cloud-specific control logic. aka: tags: @@ -12,8 +12,8 @@ tags: - architecture - operation --- - Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud. + Cloud Controller Manager is a Kubernetes component that embeds cloud-specific control logic. -Kubernetes v1.6 contains a new binary called cloud-controller-manager. cloud-controller-manager is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the kube-controller-manager. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the cloud-controller-manager binary allows cloud vendors to evolve independently from the core Kubernetes code. +Originally part of the kube-controller-manager, the cloud-controller-manager is responsible to decoupling the interoperability logic between Kubernetes and the underlying cloud infrastructure, enabling cloud providers to release features at a different pace compared to the main project. diff --git a/content/en/docs/reference/glossary/container-runtime.md b/content/en/docs/reference/glossary/container-runtime.md index c45bed0f7b..89bd4ae7ad 100644 --- a/content/en/docs/reference/glossary/container-runtime.md +++ b/content/en/docs/reference/glossary/container-runtime.md @@ -2,7 +2,7 @@ title: Container Runtime id: container-runtime date: 2019-06-05 -full_link: /docs/reference/generated/container-runtime +full_link: /docs/setup/production-environment/container-runtimes short_description: > The container runtime is the software that is responsible for running containers. diff --git a/content/en/docs/reference/glossary/host-aliases.md b/content/en/docs/reference/glossary/host-aliases.md index 47bd22d433..dc848960c3 100644 --- a/content/en/docs/reference/glossary/host-aliases.md +++ b/content/en/docs/reference/glossary/host-aliases.md @@ -2,7 +2,7 @@ title: HostAliases id: HostAliases date: 2019-01-31 -full_link: /docs/reference/generated/kubernetes-api/v1.13/#hostalias-v1-core +full_link: /docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core short_description: > A HostAliases is a mapping between the IP address and hostname to be injected into a Pod's hosts file. @@ -14,4 +14,4 @@ tags: -[HostAliases](/docs/reference/generated/kubernetes-api/v1.13/#hostalias-v1-corev) is an optional list of hostnames and IP addresses that will be injected into the Pod's hosts file if specified. This is only valid for non-hostNetwork Pods. +[HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) is an optional list of hostnames and IP addresses that will be injected into the Pod's hosts file if specified. This is only valid for non-hostNetwork Pods. diff --git a/content/en/docs/reference/glossary/service-account.md b/content/en/docs/reference/glossary/service-account.md index aee24891c8..7985f672fb 100755 --- a/content/en/docs/reference/glossary/service-account.md +++ b/content/en/docs/reference/glossary/service-account.md @@ -1,5 +1,5 @@ --- -title: Service Account +title: ServiceAccount id: service-account date: 2018-04-12 full_link: /docs/tasks/configure-pod-container/configure-service-account/ @@ -16,4 +16,3 @@ tags: When processes inside Pods access the cluster, they are authenticated by the API server as a particular service account, for example, `default`. When you create a Pod, if you do not specify a service account, it is automatically assigned the default service account in the same {{< glossary_tooltip text="Namespace" term_id="namespace" >}}. - diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index fbdbf14f87..4d06194a59 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -89,7 +89,7 @@ A given Kubernetes server will only preserve a historical list of changes for a ### Watch bookmarks -To mitigate the impact of short history window, we introduced a concept of `bookmark` watch event. It is a special kind of event to pass an information that all changes up to a given `resourceVersion` client is requesting has already been sent. Object returned in that event is of the type requested by the request, but only `resourceVersion` field is set, e.g.: +To mitigate the impact of short history window, we introduced a concept of `bookmark` watch event. It is a special kind of event to mark that all changes up to a given `resourceVersion` the client is requesting have already been sent. Object returned in that event is of the type requested by the request, but only `resourceVersion` field is set, e.g.: GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245&allowWatchBookmarks=true --- @@ -334,6 +334,17 @@ are not vulnerable to ordering changes in the list. Once the last finalizer is removed, the resource is actually removed from etcd. +## Single resource API + +API verbs GET, CREATE, UPDATE, PATCH, DELETE and PROXY support single resources only. +These verbs with single resource support have no support for submitting +multiple resources together in an ordered or unordered list or transaction. +Clients including kubectl will parse a list of resources and make +single-resource API requests. + +API verbs LIST and WATCH support getting multiple resources, and +DELETECOLLECTION supports deleting multiple resources. + ## Dry-run {{< feature-state for_k8s_version="v1.18" state="stable" >}} diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md index 880dd46024..16702b40f5 100644 --- a/content/en/docs/setup/_index.md +++ b/content/en/docs/setup/_index.md @@ -40,19 +40,15 @@ If you're learning Kubernetes, use the Docker-based solutions: tools supported b |Community |Ecosystem | | ------------ | -------- | -| [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) | -| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| -| | [Minishift](https://docs.okd.io/latest/minishift/)| +| [Minikube](/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| +| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Minishift](https://docs.okd.io/latest/minishift/)| | | [MicroK8s](https://microk8s.io/)| -| | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) | -| | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)| -| | [k3s](https://k3s.io)| ## Production environment When evaluating a solution for a production environment, consider which aspects of operating a Kubernetes cluster (or _abstractions_) you want to manage yourself or offload to a provider. -For a list of [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) providers, see "[Partners](https://kubernetes.io/partners/#conformance)". +[Kubernetes Partners](https://kubernetes.io/partners/#conformance) includes a list of [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) providers. {{% /capture %}} diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index af58f4f5a3..e2ae7267bc 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -8,7 +8,7 @@ weight: 40 {{% capture overview %}} -{{< feature-state for_k8s_version="1.12" state="stable" >}} +{{< feature-state for_k8s_version="v1.12" state="stable" >}} The kubeadm `ClusterConfiguration` object exposes the field `extraArgs` that can override the default flags passed to control plane components such as the APIServer, ControllerManager and Scheduler. The components are defined using the following fields: 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 d6e421b2ba..641d349440 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 @@ -8,7 +8,7 @@ weight: 80 {{% capture overview %}} -{{< feature-state for_k8s_version="1.11" state="stable" >}} +{{< feature-state for_k8s_version="v1.11" state="stable" >}} The lifecycle of the kubeadm CLI tool is decoupled from the [kubelet](/docs/reference/command-line-tools-reference/kubelet), which is a daemon that runs diff --git a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 6875453878..4cccac0f58 100644 --- a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -149,12 +149,12 @@ users: username: exp ``` -The `fake-ca-file`, `fake-cert-file` and `fake-key-file` above is the placeholders -for the real path of the certification files. You need change these to the real path -of certification files in your environment. +The `fake-ca-file`, `fake-cert-file` and `fake-key-file` above are the placeholders +for the pathnames of the certificate files. You need change these to the actual pathnames +of certificate files in your environment. -Some times you may want to use base64 encoded data here instead of the path of the -certification files, then you need add the suffix `-data` to the keys. For example, +Sometimes you may want to use Base64-encoded data embedded here instead of separate +certificate files; in that case you need add the suffix `-data` to the keys, for example, `certificate-authority-data`, `client-certificate-data`, `client-key-data`. Each context is a triple (cluster, user, namespace). For example, the diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md index 184e870fc3..ec35dd88e8 100644 --- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md @@ -275,7 +275,7 @@ the version. ## Webhook conversion -{{< feature-state state="stable" for_kubernetes_version="1.16" >}} +{{< feature-state state="stable" for_k8s_version="v1.16" >}} {{< note >}} Webhook conversion is available as beta since 1.15, and as alpha since Kubernetes 1.13. The diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md index dd96f2d6d6..ddcf7d4875 100644 --- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md +++ b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md @@ -243,7 +243,7 @@ If you later recreate the same CustomResourceDefinition, it will start out empty ## Specifying a structural schema -{{< feature-state state="stable" for_kubernetes_version="1.16" >}} +{{< feature-state state="stable" for_k8s_version="v1.16" >}} CustomResources traditionally store arbitrary JSON (next to `apiVersion`, `kind` and `metadata`, which is validated by the API server implicitly). With [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) a schema can be specified, which is validated during creation and updates, compare below for details and limits of such a schema. @@ -364,7 +364,7 @@ Structural schemas are a requirement for `apiextensions.k8s.io/v1`, and disables ### Pruning versus preserving unknown fields -{{< feature-state state="stable" for_kubernetes_version="1.16" >}} +{{< feature-state state="stable" for_k8s_version="v1.16" >}} CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources such as a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields. @@ -604,7 +604,7 @@ meaning all finalizers have been executed. ### Validation -{{< feature-state state="stable" for_kubernetes_version="1.16" >}} +{{< feature-state state="stable" for_k8s_version="v1.16" >}} Validation of custom objects is possible via [OpenAPI v3 schemas](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject) or [validatingadmissionwebhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook). In `apiextensions.k8s.io/v1` schemas are required, in `apiextensions.k8s.io/v1beta1` they are optional. @@ -781,7 +781,7 @@ crontab "my-new-cron-object" created ### Defaulting -{{< feature-state state="stable" for_kubernetes_version="1.17" >}} +{{< feature-state state="stable" for_k8s_version="v1.17" >}} {{< note >}} To use defaulting, your CustomResourceDefinition must use API version `apiextensions.k8s.io/v1`. @@ -866,7 +866,7 @@ Default values for `metadata` fields of `x-kubernetes-embedded-resources: true` ### Publish Validation Schema in OpenAPI v2 -{{< feature-state state="stable" for_kubernetes_version="1.16" >}} +{{< feature-state state="stable" for_k8s_version="v1.16" >}} {{< note >}} OpenAPI v2 Publishing is available as beta since 1.15, and as alpha since 1.14. The @@ -1051,7 +1051,7 @@ The column's `format` controls the style used when `kubectl` prints the value. ### Subresources -{{< feature-state state="stable" for_kubernetes_version="1.16" >}} +{{< feature-state state="stable" for_k8s_version="v1.16" >}} Custom resources support `/status` and `/scale` subresources. diff --git a/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md index 0b79ef581c..fc1975bc82 100644 --- a/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md +++ b/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md @@ -14,7 +14,7 @@ In upcoming releases, Cloud Controller Manager will be the preferred way to integrate Kubernetes with any cloud. This will ensure cloud providers can develop their features independently from the core Kubernetes release cycles. -{{< feature-state for_k8s_version="1.8" state="alpha" >}} +{{< feature-state for_k8s_version="v1.8" state="alpha" >}} Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62) is satisfied. diff --git a/content/en/docs/tasks/administer-cluster/highly-available-master.md b/content/en/docs/tasks/administer-cluster/highly-available-master.md index 1a0a36d875..e5529da7c7 100644 --- a/content/en/docs/tasks/administer-cluster/highly-available-master.md +++ b/content/en/docs/tasks/administer-cluster/highly-available-master.md @@ -7,7 +7,7 @@ content_template: templates/task {{% capture overview %}} -{{< feature-state for_k8s_version="1.5" state="alpha" >}} +{{< feature-state for_k8s_version="v1.5" state="alpha" >}} You can replicate Kubernetes masters in `kube-up` or `kube-down` scripts for Google Compute Engine. This document describes how to use kube-up/down scripts to manage highly available (HA) masters and how HA masters are implemented for use with GCE. diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 9fc79c1e12..42c8a4c786 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -50,18 +50,18 @@ The upgrade workflow at high level is the following: ## Determine which version to upgrade to -1. Find the latest stable 1.17 version: +1. Find the latest stable 1.18 version: {{< tabs name="k8s_install_versions" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} apt update apt-cache madison kubeadm - # find the latest 1.17 version in the list + # find the latest 1.18 version in the list # it should look like 1.18.x-00, where x is the latest patch {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} yum list --showduplicates kubeadm --disableexcludes=kubernetes - # find the latest 1.17 version in the list + # find the latest 1.18 version in the list # it should look like 1.18.x-0, where x is the latest patch {{% /tab %}} {{< /tabs >}} diff --git a/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md index 95065ca595..a812640555 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md @@ -107,7 +107,7 @@ If you attempt to use `kubectl exec` to create a shell you will see an error because there is no shell in this container image. ```shell -kubectl exec -it pause -- sh +kubectl exec -it ephemeral-demo -- sh ``` ``` diff --git a/content/en/docs/tasks/manage-daemon/update-daemon-set.md b/content/en/docs/tasks/manage-daemon/update-daemon-set.md index 8eec3c1781..e4640e3ccd 100644 --- a/content/en/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/en/docs/tasks/manage-daemon/update-daemon-set.md @@ -43,21 +43,39 @@ To enable the rolling update feature of a DaemonSet, you must set its You may want to set [`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable) (default to 1) and [`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (default to 0) as well. +### Creating a DaemonSet with `RollingUpdate` update strategy -### Step 1: Checking DaemonSet `RollingUpdate` update strategy +This YAML file specifies a DaemonSet with an update strategy as 'RollingUpdate' -First, check the update strategy of your DaemonSet, and make sure it's set to +{{< codenew file="controllers/fluentd-daemonset.yaml" >}} + +After verifying the update strategy of the DaemonSet manifest, create the DaemonSet: + +```shell +kubectl create -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml +``` + +Alternatively, use `kubectl apply` to create the same DaemonSet if you plan to +update the DaemonSet with `kubectl apply`. + +```shell +kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml +``` + +### Checking DaemonSet `RollingUpdate` update strategy + +Check the update strategy of your DaemonSet, and make sure it's set to `RollingUpdate`: ```shell -kubectl get ds/ -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' +kubectl get ds/fluentd-elasticsearch -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' -n kube-system ``` If you haven't created the DaemonSet in the system, check your DaemonSet manifest with the following command instead: ```shell -kubectl apply -f ds.yaml --dry-run=client -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' +kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml --dry-run=client -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' ``` The output from both commands should be: @@ -69,28 +87,13 @@ RollingUpdate If the output isn't `RollingUpdate`, go back and modify the DaemonSet object or manifest accordingly. -### Step 2: Creating a DaemonSet with `RollingUpdate` update strategy -If you have already created the DaemonSet, you may skip this step and jump to -step 3. - -After verifying the update strategy of the DaemonSet manifest, create the DaemonSet: - -```shell -kubectl create -f ds.yaml -``` - -Alternatively, use `kubectl apply` to create the same DaemonSet if you plan to -update the DaemonSet with `kubectl apply`. - -```shell -kubectl apply -f ds.yaml -``` - -### Step 3: Updating a DaemonSet template +### Updating a DaemonSet template Any updates to a `RollingUpdate` DaemonSet `.spec.template` will trigger a rolling -update. This can be done with several different `kubectl` commands. +update. Let's update the DaemonSet by applying a new YAML file. This can be done with several different `kubectl` commands. + +{{< codenew file="controllers/fluentd-daemonset-update.yaml" >}} #### Declarative commands @@ -99,21 +102,17 @@ If you update DaemonSets using use `kubectl apply`: ```shell -kubectl apply -f ds-v2.yaml +kubectl apply -f https://k8s.io/examples/application/fluentd-daemonset-update.yaml ``` #### Imperative commands If you update DaemonSets using [imperative commands](/docs/tasks/manage-kubernetes-objects/imperative-command/), -use `kubectl edit` or `kubectl patch`: +use `kubectl edit` : ```shell -kubectl edit ds/ -``` - -```shell -kubectl patch ds/ -p= +kubectl edit ds/fluentd-elasticsearch -n kube-system ``` ##### Updating only the container image @@ -122,21 +121,21 @@ If you just need to update the container image in the DaemonSet template, i.e. `.spec.template.spec.containers[*].image`, use `kubectl set image`: ```shell -kubectl set image ds/ = +kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system ``` -### Step 4: Watching the rolling update status +### Watching the rolling update status Finally, watch the rollout status of the latest DaemonSet rolling update: ```shell -kubectl rollout status ds/ +kubectl rollout status ds/fluentd-elasticsearch -n kube-system ``` When the rollout is complete, the output is similar to this: ```shell -daemonset "" successfully rolled out +daemonset "fluentd-elasticsearch" successfully rolled out ``` ## Troubleshooting @@ -156,7 +155,7 @@ When this happens, find the nodes that don't have the DaemonSet pods scheduled o by comparing the output of `kubectl get nodes` and the output of: ```shell -kubectl get pods -l = -o wide +kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system ``` Once you've found those nodes, delete some non-DaemonSet pods from the node to @@ -183,6 +182,13 @@ If `.spec.minReadySeconds` is specified in the DaemonSet, clock skew between master and nodes will make DaemonSet unable to detect the right rollout progress. +## Clean up + +Delete DaemonSet from a namespace : + +```shell +kubectl delete ds fluentd-elasticsearch -n kube-system +``` {{% /capture %}} diff --git a/content/en/docs/tasks/manage-gpus/scheduling-gpus.md b/content/en/docs/tasks/manage-gpus/scheduling-gpus.md index 97500e6beb..4c0b9f9bc3 100644 --- a/content/en/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/content/en/docs/tasks/manage-gpus/scheduling-gpus.md @@ -7,7 +7,7 @@ title: Schedule GPUs {{% capture overview %}} -{{< feature-state state="beta" for_k8s_version="1.10" >}} +{{< feature-state state="beta" for_k8s_version="v1.10" >}} Kubernetes includes **experimental** support for managing AMD and NVIDIA GPUs (graphical processing units) across several nodes. 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 b5f7612d75..059efbab7e 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -75,7 +75,7 @@ metrics-server, which needs to be launched separately. See for instructions. The HorizontalPodAutoscaler can also fetch metrics directly from Heapster. {{< note >}} -{{< feature-state state="deprecated" for_k8s_version="1.11" >}} +{{< feature-state state="deprecated" for_k8s_version="v1.11" >}} Fetching metrics from Heapster is deprecated as of Kubernetes 1.11. {{< /note >}} diff --git a/content/en/docs/tasks/run-application/run-stateless-application-deployment.md b/content/en/docs/tasks/run-application/run-stateless-application-deployment.md index c9e0aebd51..bebcd3cc70 100644 --- a/content/en/docs/tasks/run-application/run-stateless-application-deployment.md +++ b/content/en/docs/tasks/run-application/run-stateless-application-deployment.md @@ -97,7 +97,7 @@ a Deployment that runs the nginx:1.14.2 Docker image: ## Updating the deployment You can update the deployment by applying a new YAML file. This YAML file -specifies that the deployment should be updated to use nginx 1.8. +specifies that the deployment should be updated to use nginx 1.16.1. {{< codenew file="application/deployment-update.yaml" >}} diff --git a/content/en/docs/tasks/setup-konnectivity/_index.md b/content/en/docs/tasks/setup-konnectivity/_index.md new file mode 100755 index 0000000000..09f254eba0 --- /dev/null +++ b/content/en/docs/tasks/setup-konnectivity/_index.md @@ -0,0 +1,5 @@ +--- +title: "Setup Konnectivity Service" +weight: 20 +--- + diff --git a/content/en/docs/tasks/setup-konnectivity/setup-konnectivity.md b/content/en/docs/tasks/setup-konnectivity/setup-konnectivity.md new file mode 100644 index 0000000000..b5dbd05215 --- /dev/null +++ b/content/en/docs/tasks/setup-konnectivity/setup-konnectivity.md @@ -0,0 +1,52 @@ +--- +title: Set up Konnectivity service +content_template: templates/task +weight: 70 +--- + +{{% capture overview %}} + +The Konnectivity service provides TCP level proxy for the Master → Cluster +communication. + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} + +{{% /capture %}} + +{{% capture steps %}} + +## Configure the Konnectivity service + +First, you need to configure the API Server to use the Konnectivity service +to direct its network traffic to cluster nodes: + +1. Set the `--egress-selector-config-file` flag of the API Server, it is the +path to the API Server egress configuration file. +1. At the path, create a configuration file. For example, + +{{< codenew file="admin/konnectivity/egress-selector-configuration.yaml" >}} + +Next, you need to deploy the Konnectivity server and agents. +[kubernetes-sigs/apiserver-network-proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy) +is a reference implementation. + +Deploy the Konnectivity server on your master node. The provided yaml assumes +that the Kubernetes components are deployed as a {{< glossary_tooltip text="static Pod" +term_id="static-pod" >}} in your cluster. If not, you can deploy the Konnectivity +server as a DaemonSet. + +{{< codenew file="admin/konnectivity/konnectivity-server.yaml" >}} + +Then deploy the Konnectivity agents in your cluster: + +{{< codenew file="admin/konnectivity/konnectivity-agent.yaml" >}} + +Last, if RBAC is enabled in your cluster, create the relevant RBAC rules: + +{{< codenew file="admin/konnectivity/konnectivity-rbac.yaml" >}} + +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md index 4a0be4509a..6d9ffdcd0a 100644 --- a/content/en/docs/tasks/tools/install-kubectl.md +++ b/content/en/docs/tasks/tools/install-kubectl.md @@ -59,7 +59,7 @@ You must use a kubectl version that is within one minor version difference of yo {{< tabs name="kubectl_install" >}} {{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}} -sudo apt-get update && sudo apt-get install -y apt-transport-https +sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list sudo apt-get update @@ -419,7 +419,7 @@ You can test if you have bash-completion v2 already installed with `type _init_c brew install bash-completion@2 ``` -As stated in the output of this command, add the following to your `~/.bashrc` file: +As stated in the output of this command, add the following to your `~/.bash_profile` file: ```shell export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" @@ -432,10 +432,10 @@ Reload your shell and verify that bash-completion v2 is correctly installed with You now have to ensure that the kubectl completion script gets sourced in all your shell sessions. There are multiple ways to achieve this: -- Source the completion script in your `~/.bashrc` file: +- Source the completion script in your `~/.bash_profile` file: ```shell - echo 'source <(kubectl completion bash)' >>~/.bashrc + echo 'source <(kubectl completion bash)' >>~/.bash_profile ``` @@ -448,8 +448,8 @@ You now have to ensure that the kubectl completion script gets sourced in all yo - If you have an alias for kubectl, you can extend shell completion to work with that alias: ```shell - echo 'alias k=kubectl' >>~/.bashrc - echo 'complete -F __start_kubectl k' >>~/.bashrc + echo 'alias k=kubectl' >>~/.bash_profile + echo 'complete -F __start_kubectl k' >>~/.bash_profile ``` - If you installed kubectl with Homebrew (as explained [above](#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything. diff --git a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 8f38960de7..af2d5eeed2 100644 --- a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -31,7 +31,8 @@ weight: 10 Once you have a running Kubernetes cluster, you can deploy your containerized applications on top of it. To do so, you create a Kubernetes Deployment configuration. The Deployment instructs Kubernetes how to create and update instances of your application. Once you've created a Deployment, the Kubernetes - master schedules mentioned application instances onto individual Nodes in the cluster. + master schedules the application instances included in that Deployment to run on individual Nodes in the + cluster.

Once the application instances are created, a Kubernetes Deployment Controller continuously monitors those instances. If the Node hosting an instance goes down or is deleted, the Deployment controller replaces the instance with an instance on another Node in the cluster. This provides a self-healing mechanism to address machine failure or maintenance.

diff --git a/content/en/docs/tutorials/stateful-application/cassandra.md b/content/en/docs/tutorials/stateful-application/cassandra.md index a20d93926d..f55a852abb 100644 --- a/content/en/docs/tutorials/stateful-application/cassandra.md +++ b/content/en/docs/tutorials/stateful-application/cassandra.md @@ -1,5 +1,5 @@ --- -title: "Example: Deploying Cassandra with Stateful Sets" +title: "Example: Deploying Cassandra with a StatefulSet" reviewers: - ahmetb content_template: templates/tutorial @@ -7,79 +7,66 @@ weight: 30 --- {{% capture overview %}} -This tutorial shows you how to develop a native cloud [Cassandra](http://cassandra.apache.org/) deployment on Kubernetes. In this example, a custom Cassandra *SeedProvider* enables Cassandra to discover new Cassandra nodes as they join the cluster. +This tutorial shows you how to run [Apache Cassandra](http://cassandra.apache.org/) on Kubernetes. Cassandra, a database, needs persistent storage to provide data durability (application _state_). In this example, a custom Cassandra seed provider lets the database discover new Cassandra instances as they join the Cassandra cluster. -*StatefulSets* make it easier to deploy stateful applications within a clustered environment. For more information on the features used in this tutorial, see the [*StatefulSet*](/docs/concepts/workloads/controllers/statefulset/) documentation. +*StatefulSets* make it easier to deploy stateful applications into your Kubernetes cluster. For more information on the features used in this tutorial, see [StatefulSet](/docs/concepts/workloads/controllers/statefulset/). -**Cassandra on Docker** - -The *Pods* in this tutorial use the [`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile) -image from Google's [container registry](https://cloud.google.com/container-registry/docs/). -The Docker image above is based on [debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base) -and includes OpenJDK 8. - -This image includes a standard Cassandra installation from the Apache Debian repo. -By using environment variables you can change values that are inserted into `cassandra.yaml`. - -| ENV VAR | DEFAULT VALUE | -| ------------- |:-------------: | -| `CASSANDRA_CLUSTER_NAME` | `'Test Cluster'` | -| `CASSANDRA_NUM_TOKENS` | `32` | -| `CASSANDRA_RPC_ADDRESS` | `0.0.0.0` | +{{< note >}} +Cassandra and Kubernetes both use the term _node_ to mean a member of a cluster. In this +tutorial, the Pods that belong to the StatefulSet are Cassandra nodes and are members +of the Cassandra cluster (called a _ring_). When those Pods run in your Kubernetes cluster, +the Kubernetes control plane schedules those Pods onto Kubernetes +{{< glossary_tooltip text="Nodes" term_id="node" >}}. +When a Cassandra node starts, it uses a _seed list_ to bootstrap discovery of other +nodes in the ring. +This tutorial deploys a custom Cassandra seed provider that lets the database discover +new Cassandra Pods as they appear inside your Kubernetes cluster. +{{< /note >}} {{% /capture %}} {{% capture objectives %}} -* Create and validate a Cassandra headless [*Service*](/docs/concepts/services-networking/service/). -* Use a [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) to create a Cassandra ring. -* Validate the [StatefulSet](/docs/concepts/workloads/controllers/statefulset/). -* Modify the [StatefulSet](/docs/concepts/workloads/controllers/statefulset/). -* Delete the [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) and its [Pods](/docs/concepts/workloads/pods/pod/). +* Create and validate a Cassandra headless {{< glossary_tooltip text="Service" term_id="service" >}}. +* Use a {{< glossary_tooltip term_id="StatefulSet" >}} to create a Cassandra ring. +* Validate the StatefulSet. +* Modify the StatefulSet. +* Delete the StatefulSet and its {{< glossary_tooltip text="Pods" term_id="pod" >}}. {{% /capture %}} {{% capture prerequisites %}} -To complete this tutorial, you should already have a basic familiarity with [Pods](/docs/concepts/workloads/pods/pod/), [Services](/docs/concepts/services-networking/service/), and [StatefulSets](/docs/concepts/workloads/controllers/statefulset/). In addition, you should: +{{< include "task-tutorial-prereqs.md" >}} -* [Install and Configure](/docs/tasks/tools/install-kubectl/) the *kubectl* command-line tool +To complete this tutorial, you should already have a basic familiarity with {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip text="Services" term_id="service" >}}, and {{< glossary_tooltip text="StatefulSets" term_id="StatefulSet" >}}. -* Download [`cassandra-service.yaml`](/examples/application/cassandra/cassandra-service.yaml) - and [`cassandra-statefulset.yaml`](/examples/application/cassandra/cassandra-statefulset.yaml) - -* Have a supported Kubernetes cluster running - -{{< note >}} -Please read the [setup](/docs/setup/) if you do not already have a cluster. -{{< /note >}} - -### Additional Minikube Setup Instructions +### Additional Minikube setup instructions {{< caution >}} -[Minikube](/docs/getting-started-guides/minikube/) defaults to 1024MB of memory and 1 CPU. Running Minikube with the default resource configuration results in insufficient resource errors during this tutorial. To avoid these errors, start Minikube with the following settings: +[Minikube](/docs/getting-started-guides/minikube/) defaults to 1024MiB of memory and 1 CPU. Running Minikube with the default resource configuration results in insufficient resource errors during this tutorial. To avoid these errors, start Minikube with the following settings: ```shell minikube start --memory 5120 --cpus=4 ``` {{< /caution >}} - + {{% /capture %}} {{% capture lessoncontent %}} -## Creating a Cassandra Headless Service +## Creating a headless Service for Cassandra {#creating-a-cassandra-headless-service} -A Kubernetes [Service](/docs/concepts/services-networking/service/) describes a set of [Pods](/docs/concepts/workloads/pods/pod/) that perform the same task. +In Kubernetes, a {{< glossary_tooltip text="Service" term_id="service" >}} describes a set of {{< glossary_tooltip text="Pods" term_id="pod" >}} that perform the same task. -The following `Service` is used for DNS lookups between Cassandra Pods and clients within the Kubernetes cluster. +The following Service is used for DNS lookups between Cassandra Pods and clients within your cluster: {{< codenew file="application/cassandra/cassandra-service.yaml" >}} -1. Launch a terminal window in the directory you downloaded the manifest files. -1. Create a Service to track all Cassandra StatefulSet nodes from the `cassandra-service.yaml` file: +Create a Service to track all Cassandra StatefulSet members from the `cassandra-service.yaml` file: - ```shell - kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-service.yaml - ``` +```shell +kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-service.yaml +``` -### Validating (optional) + +### Validating (optional) {#validating} Get the Cassandra Service. @@ -94,9 +81,9 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cassandra ClusterIP None 9042/TCP 45s ``` -Service creation failed if anything else is returned. Read [Debug Services](/docs/tasks/debug-application-cluster/debug-service/) for common issues. +If you don't see a Service named `cassandra`, that means creation failed. Read [Debug Services](/docs/tasks/debug-application-cluster/debug-service/) for help troubleshooting common issues. -## Using a StatefulSet to Create a Cassandra Ring +## Using a StatefulSet to create a Cassandra ring The StatefulSet manifest, included below, creates a Cassandra ring that consists of three Pods. @@ -106,14 +93,23 @@ This example uses the default provisioner for Minikube. Please update the follow {{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}} -1. Update the StatefulSet if necessary. -1. Create the Cassandra StatefulSet from the `cassandra-statefulset.yaml` file: +Create the Cassandra StatefulSet from the `cassandra-statefulset.yaml` file: - ```shell - kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml - ``` +```shell +# Use this if you are able to apply cassandra-statefulset.yaml unmodified +kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml +``` -## Validating The Cassandra StatefulSet +If you need to modify `cassandra-statefulset.yaml` to suit your cluster, download +https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml and then apply +that manifest, from the folder you saved the modified version into: +```shell +# Use this if you needed to modify cassandra-statefulset.yaml locally +kubectl apply -f cassandra-statefulset.yaml +``` + + +## Validating the Cassandra StatefulSet 1. Get the Cassandra StatefulSet: @@ -121,31 +117,32 @@ This example uses the default provisioner for Minikube. Please update the follow kubectl get statefulset cassandra ``` - The response should be: + The response should be similar to: ``` NAME DESIRED CURRENT AGE cassandra 3 0 13s ``` - The `StatefulSet` resource deploys Pods sequentially. + The `StatefulSet` resource deploys Pods sequentially. 1. Get the Pods to see the ordered creation status: ```shell kubectl get pods -l="app=cassandra" ``` - - The response should be: - + + The response should be similar to: + ```shell NAME READY STATUS RESTARTS AGE cassandra-0 1/1 Running 0 1m cassandra-1 0/1 ContainerCreating 0 8s ``` - - It can take several minutes for all three Pods to deploy. Once they are deployed, the same command returns: - + + It can take several minutes for all three Pods to deploy. Once they are deployed, the same command + returns output similar to: + ``` NAME READY STATUS RESTARTS AGE cassandra-0 1/1 Running 0 10m @@ -153,13 +150,14 @@ This example uses the default provisioner for Minikube. Please update the follow cassandra-2 1/1 Running 0 8m ``` -3. Run the Cassandra [nodetool](https://wiki.apache.org/cassandra/NodeTool) to display the status of the ring. +3. Run the Cassandra [nodetool](https://cwiki.apache.org/confluence/display/CASSANDRA2/NodeTool) inside the first Pod, to + display the status of the ring. ```shell kubectl exec -it cassandra-0 -- nodetool status ``` - The response should look something like this: + The response should look something like: ``` Datacenter: DC1-K8Demo @@ -174,7 +172,7 @@ This example uses the default provisioner for Minikube. Please update the follow ## Modifying the Cassandra StatefulSet -Use `kubectl edit` to modify the size of a Cassandra StatefulSet. +Use `kubectl edit` to modify the size of a Cassandra StatefulSet. 1. Run the following command: @@ -182,14 +180,14 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet. kubectl edit statefulset cassandra ``` - This command opens an editor in your terminal. The line you need to change is the `replicas` field. The following sample is an excerpt of the `StatefulSet` file: + This command opens an editor in your terminal. The line you need to change is the `replicas` field. The following sample is an excerpt of the StatefulSet file: ```yaml # Please edit the object below. Lines beginning with a '#' will be ignored, # and an empty file will abort the edit. If an error occurs while saving this file will be # reopened with the relevant failures. # - apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 + apiVersion: apps/v1 kind: StatefulSet metadata: creationTimestamp: 2016-08-13T18:40:58Z @@ -204,50 +202,66 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet. replicas: 3 ``` -1. Change the number of replicas to 4, and then save the manifest. +1. Change the number of replicas to 4, and then save the manifest. - The `StatefulSet` now contains 4 Pods. + The StatefulSet now scales to run with 4 Pods. -1. Get the Cassandra StatefulSet to verify: +1. Get the Cassandra StatefulSet to verify your change: ```shell kubectl get statefulset cassandra ``` - The response should be + The response should be similar to: ``` NAME DESIRED CURRENT AGE cassandra 4 4 36m ``` - + {{% /capture %}} {{% capture cleanup %}} -Deleting or scaling a StatefulSet down does not delete the volumes associated with the StatefulSet. This setting is for your safety because your data is more valuable than automatically purging all related StatefulSet resources. +Deleting or scaling a StatefulSet down does not delete the volumes associated with the StatefulSet. This setting is for your safety because your data is more valuable than automatically purging all related StatefulSet resources. {{< warning >}} Depending on the storage class and reclaim policy, deleting the *PersistentVolumeClaims* may cause the associated volumes to also be deleted. Never assume you’ll be able to access data if its volume claims are deleted. {{< /warning >}} -1. Run the following commands (chained together into a single command) to delete everything in the Cassandra `StatefulSet`: +1. Run the following commands (chained together into a single command) to delete everything in the Cassandra StatefulSet: ```shell - grace=$(kubectl get po cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \ + grace=$(kubectl get pod cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \ && kubectl delete statefulset -l app=cassandra \ - && echo "Sleeping $grace" \ + && echo "Sleeping ${grace} seconds" 1>&2 \ && sleep $grace \ - && kubectl delete pvc -l app=cassandra + && kubectl delete persistentvolumeclaim -l app=cassandra ``` -1. Run the following command to delete the Cassandra Service. +1. Run the following command to delete the Service you set up for Cassandra: ```shell kubectl delete service -l app=cassandra ``` -{{% /capture %}} +## Cassandra container environment variables +The Pods in this tutorial use the [`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile) +image from Google's [container registry](https://cloud.google.com/container-registry/docs/). +The Docker image above is based on [debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base) +and includes OpenJDK 8. + +This image includes a standard Cassandra installation from the Apache Debian repo. +By using environment variables you can change values that are inserted into `cassandra.yaml`. + +| Environment variable | Default value | +| ------------------------ |:---------------: | +| `CASSANDRA_CLUSTER_NAME` | `'Test Cluster'` | +| `CASSANDRA_NUM_TOKENS` | `32` | +| `CASSANDRA_RPC_ADDRESS` | `0.0.0.0` | + + +{{% /capture %}} {{% capture whatsnext %}} * Learn how to [Scale a StatefulSet](/docs/tasks/run-application/scale-stateful-set/). diff --git a/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml b/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml new file mode 100644 index 0000000000..6659ff3fbb --- /dev/null +++ b/content/en/examples/admin/konnectivity/egress-selector-configuration.yaml @@ -0,0 +1,21 @@ +apiVersion: apiserver.k8s.io/v1beta1 +kind: EgressSelectorConfiguration +egressSelections: +# Since we want to control the egress traffic to the cluster, we use the +# "cluster" as the name. Other supported values are "etcd", and "master". +- name: cluster + connection: + # This controls the protocol between the API Server and the Konnectivity + # server. Supported values are "GRPC" and "HTTPConnect". There is no + # end user visible difference between the two modes. You need to set the + # Konnectivity server to work in the same mode. + proxyProtocol: GRPC + transport: + # This controls what transport the API Server uses to communicate with the + # Konnectivity server. UDS is recommended if the Konnectivity server + # locates on the same machine as the API Server. You need to configure the + # Konnectivity server to listen on the same UDS socket. + # The other supported transport is "tcp". You will need to set up TLS + # config to secure the TCP transport. + uds: + udsName: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket diff --git a/content/en/examples/admin/konnectivity/konnectivity-agent.yaml b/content/en/examples/admin/konnectivity/konnectivity-agent.yaml new file mode 100644 index 0000000000..c3dc71040b --- /dev/null +++ b/content/en/examples/admin/konnectivity/konnectivity-agent.yaml @@ -0,0 +1,53 @@ +apiVersion: apps/v1 +# Alternatively, you can deploy the agents as Deployments. It is not necessary +# to have an agent on each node. +kind: DaemonSet +metadata: + labels: + addonmanager.kubernetes.io/mode: Reconcile + k8s-app: konnectivity-agent + namespace: kube-system + name: konnectivity-agent +spec: + selector: + matchLabels: + k8s-app: konnectivity-agent + template: + metadata: + labels: + k8s-app: konnectivity-agent + spec: + priorityClassName: system-cluster-critical + tolerations: + - key: "CriticalAddonsOnly" + operator: "Exists" + containers: + - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.8 + name: konnectivity-agent + command: ["/proxy-agent"] + args: [ + "--logtostderr=true", + "--ca-cert=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt", + # Since the konnectivity server runs with hostNetwork=true, + # this is the IP address of the master machine. + "--proxy-server-host=35.225.206.7", + "--proxy-server-port=8132", + "--service-account-token-path=/var/run/secrets/tokens/konnectivity-agent-token" + ] + volumeMounts: + - mountPath: /var/run/secrets/tokens + name: konnectivity-agent-token + livenessProbe: + httpGet: + port: 8093 + path: /healthz + initialDelaySeconds: 15 + timeoutSeconds: 15 + serviceAccountName: konnectivity-agent + volumes: + - name: konnectivity-agent-token + projected: + sources: + - serviceAccountToken: + path: konnectivity-agent-token + audience: system:konnectivity-server diff --git a/content/en/examples/admin/konnectivity/konnectivity-rbac.yaml b/content/en/examples/admin/konnectivity/konnectivity-rbac.yaml new file mode 100644 index 0000000000..7687f49b77 --- /dev/null +++ b/content/en/examples/admin/konnectivity/konnectivity-rbac.yaml @@ -0,0 +1,24 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: system:konnectivity-server + labels: + kubernetes.io/cluster-service: "true" + addonmanager.kubernetes.io/mode: Reconcile +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: system:auth-delegator +subjects: + - apiGroup: rbac.authorization.k8s.io + kind: User + name: system:konnectivity-server +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: konnectivity-agent + namespace: kube-system + labels: + kubernetes.io/cluster-service: "true" + addonmanager.kubernetes.io/mode: Reconcile diff --git a/content/en/examples/admin/konnectivity/konnectivity-server.yaml b/content/en/examples/admin/konnectivity/konnectivity-server.yaml new file mode 100644 index 0000000000..730c26c66a --- /dev/null +++ b/content/en/examples/admin/konnectivity/konnectivity-server.yaml @@ -0,0 +1,70 @@ +apiVersion: v1 +kind: Pod +metadata: + name: konnectivity-server + namespace: kube-system +spec: + priorityClassName: system-cluster-critical + hostNetwork: true + containers: + - name: konnectivity-server-container + image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.8 + command: ["/proxy-server"] + args: [ + "--log-file=/var/log/konnectivity-server.log", + "--logtostderr=false", + "--log-file-max-size=0", + # This needs to be consistent with the value set in egressSelectorConfiguration. + "--uds-name=/etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket", + # The following two lines assume the Konnectivity server is + # deployed on the same machine as the apiserver, and the certs and + # key of the API Server are at the specified location. + "--cluster-cert=/etc/srv/kubernetes/pki/apiserver.crt", + "--cluster-key=/etc/srv/kubernetes/pki/apiserver.key", + # This needs to be consistent with the value set in egressSelectorConfiguration. + "--mode=grpc", + "--server-port=0", + "--agent-port=8132", + "--admin-port=8133", + "--agent-namespace=kube-system", + "--agent-service-account=konnectivity-agent", + "--kubeconfig=/etc/srv/kubernetes/konnectivity-server/kubeconfig", + "--authentication-audience=system:konnectivity-server" + ] + livenessProbe: + httpGet: + scheme: HTTP + host: 127.0.0.1 + port: 8133 + path: /healthz + initialDelaySeconds: 30 + timeoutSeconds: 60 + ports: + - name: agentport + containerPort: 8132 + hostPort: 8132 + - name: adminport + containerPort: 8133 + hostPort: 8133 + volumeMounts: + - name: varlogkonnectivityserver + mountPath: /var/log/konnectivity-server.log + readOnly: false + - name: pki + mountPath: /etc/srv/kubernetes/pki + readOnly: true + - name: konnectivity-uds + mountPath: /etc/srv/kubernetes/konnectivity-server + readOnly: false + volumes: + - name: varlogkonnectivityserver + hostPath: + path: /var/log/konnectivity-server.log + type: FileOrCreate + - name: pki + hostPath: + path: /etc/srv/kubernetes/pki + - name: konnectivity-uds + hostPath: + path: /etc/srv/kubernetes/konnectivity-server + type: DirectoryOrCreate diff --git a/content/en/examples/controllers/fluentd-daemonset-update.yaml b/content/en/examples/controllers/fluentd-daemonset-update.yaml new file mode 100644 index 0000000000..dcf08d4fc9 --- /dev/null +++ b/content/en/examples/controllers/fluentd-daemonset-update.yaml @@ -0,0 +1,48 @@ +apiVersion: apps/v1 +kind: DaemonSet +metadata: + name: fluentd-elasticsearch + namespace: kube-system + labels: + k8s-app: fluentd-logging +spec: + selector: + matchLabels: + name: fluentd-elasticsearch + updateStrategy: + type: RollingUpdate + rollingUpdate: + maxUnavailable: 1 + template: + metadata: + labels: + name: fluentd-elasticsearch + spec: + tolerations: + # this toleration is to have the daemonset runnable on master nodes + # remove it if your masters can't run pods + - key: node-role.kubernetes.io/master + effect: NoSchedule + containers: + - name: fluentd-elasticsearch + image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 + resources: + limits: + memory: 200Mi + requests: + cpu: 100m + memory: 200Mi + volumeMounts: + - name: varlog + mountPath: /var/log + - name: varlibdockercontainers + mountPath: /var/lib/docker/containers + readOnly: true + terminationGracePeriodSeconds: 30 + volumes: + - name: varlog + hostPath: + path: /var/log + - name: varlibdockercontainers + hostPath: + path: /var/lib/docker/containers diff --git a/content/en/examples/controllers/fluentd-daemonset.yaml b/content/en/examples/controllers/fluentd-daemonset.yaml new file mode 100644 index 0000000000..0e1e7d3345 --- /dev/null +++ b/content/en/examples/controllers/fluentd-daemonset.yaml @@ -0,0 +1,42 @@ +apiVersion: apps/v1 +kind: DaemonSet +metadata: + name: fluentd-elasticsearch + namespace: kube-system + labels: + k8s-app: fluentd-logging +spec: + selector: + matchLabels: + name: fluentd-elasticsearch + updateStrategy: + type: RollingUpdate + rollingUpdate: + maxUnavailable: 1 + template: + metadata: + labels: + name: fluentd-elasticsearch + spec: + tolerations: + # this toleration is to have the daemonset runnable on master nodes + # remove it if your masters can't run pods + - key: node-role.kubernetes.io/master + effect: NoSchedule + containers: + - name: fluentd-elasticsearch + image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 + volumeMounts: + - name: varlog + mountPath: /var/log + - name: varlibdockercontainers + mountPath: /var/lib/docker/containers + readOnly: true + terminationGracePeriodSeconds: 30 + volumes: + - name: varlog + hostPath: + path: /var/log + - name: varlibdockercontainers + hostPath: + path: /var/lib/docker/containers diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md new file mode 100644 index 0000000000..b06117cc00 --- /dev/null +++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md @@ -0,0 +1,122 @@ +--- +reviewers: +title: EndpointSlices +feature: + title: EndpointSlices + description: > + Suivi évolutif des réseaux Endpoints dans un cluster Kubernetes. + +content_template: templates/concept +weight: 10 +--- + + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +_EndpointSlices_ offrent une méthode simple pour suivre les Endpoints d'un réseau au sein d'un cluster de Kubernetes. Ils offrent une alternative plus évolutive et extensible aux Endpoints. + +{{% /capture %}} + +{{% capture body %}} + +## Resource pour EndpointSlice {#endpointslice-resource} + +Dans Kubernetes, un EndpointSlice contient des reférences à un ensemble de Endpoints. +Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Service quand un {{< glossary_tooltip text="sélecteur" term_id="selector" >}} est spécifié. +Ces EnpointSlices vont inclure des références à n'importe quels Pods qui correspond aux selecteur de Service. +EndpointSlices groupent ensemble les Endpoints d'un réseau par combinaisons uniques de Services et de Ports. + +Par exemple, voici un échantillon d'une resource EndpointSlice pour le Kubernetes Service `exemple`. + +```yaml +apiVersion: discovery.k8s.io/v1beta1 +kind: EndpointSlice +metadata: + name: exemple-abc + labels: + kubernetes.io/service-name: exemple +addressType: IPv4 +ports: + - name: http + protocol: TCP + port: 80 +endpoints: + - addresses: + - "10.1.2.3" + conditions: + ready: true + hostname: pod-1 + topology: + kubernetes.io/hostname: node-1 + topology.kubernetes.io/zone: us-west2-a +``` + +Les EndpointSlices géré par le contrôleur d'EndpointSlice n'auront, par défaut, pas plus de 100 Endpoints chacun. +En dessous de cette échelle, EndpointSlices devrait mapper 1:1 les Endpoints et les Service et devrait avoir une performance similaire. + +EndpointSlices peuvent agir en tant que source de vérité pour kube-proxy quand il s'agit du routage d'un trafic interne. +Lorsqu'ils sont activés, ils devraient offrir une amélioration de performance pour les services qui ont une grand quantité d'Endpoints. + +### Types d'addresses + +Les EndpointSlices supportent 3 types d'addresses: + +* IPv4 +* IPv6 +* FQDN (Fully Qualified Domain Name) - [serveur entièrement nommé] + +### Topologie + +Chaque Endpoint dans un EnpointSlice peut contenir des informations de topologie pertinentes. +Ceci est utilisé pour indiqué où se trouve un Endpoint, qui contient les informations sur le Node, zone et region correspondante. Lorsque les valeurs sont disponibles, les labels de Topologies suivantes seront définies par le contrôleur EndpointSlice: + +* `kubernetes.io/hostname` - Nom du Node sur lequel l'Endpoint se situe. +* `topology.kubernetes.io/zone` - Zone dans laquelle l'Endpoint se situe. +* `topology.kubernetes.io/region` - Region dans laquelle l'Endpoint se situe. + +Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que leurs correspondances avec les EndpointSlices sont à jour. +Le contrôleur gère les EndpointSlices pour tous les Services qui ont un sélecteur - [référence: {{< glossary_tooltip text="sélecteur" term_id="selector" >}}] - specifié. Celles-ci représenteront les IPs des Pods qui correspond au sélecteur. + +### Capacité d'EndpointSlices + +Les EndpointSlices sont limités a une capacité de 100 Endpoints chacun, par défaut. Vous pouvez configurer ceci avec l'indicateur `--max-endpoints-per-slice` {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} jusqu'à un maximum de 1000. + +### Distribution d'EndpointSlices + +Chaque EndpointSlice a un ensemble de ports qui s'applique à tous les Endpoints dans la resource. +Lorsque les ports nommés sont utilisés pour un Service, les Pods peuvent se retrouver avec différents port cible pour le même port nommé, nécessitant différents EndpointSlices. + +Le contrôleur essaie de remplir l'EndpointSlice aussi complètement que possible, mais ne les rééquilibre pas activement. La logique du contrôleur est assez simple: + +1. Itérer à travers les EnpointSlices existants, retirer les Endpoints qui ne sont plus voulus et mettre à jour les Endpoints qui ont changés. +2. Itérer à travers les EndpointSlices qui ont été modifiés dans la première étape et les remplir avec n'importe quel Endpoint nécéssaire. +3. S'il reste encore des Endpoints neufs à ajouter, essayez de les mettre dans une slice qui n'a pas été changé et/ou en crée de nouveaux. + +Par-dessus tout, la troisième étape priorise la limitation de mises à jour d'EnpointSlice sur une distribution complètement pleine d'EndpointSlices. Par exemple, si il y avait 10 nouveaux Endpoints à ajouter et 2 EndpointSlices qui peuvent contenir 5 Endpoints en plus chacun; cette approche créera un nouveau EndpointSlice au lieu de remplir les EndpointSlice existants. +C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlice. + +Avec kube-proxy exécuté sur chaque Node et surveillant EndpointSlices, chaque changement d'un EndpointSlice devient relativement coûteux puisqu'ils seront transmis à chaque Node du cluster. +Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Node, même si ça peut causer plusieurs EndpointSlices non remplis. + +En pratique, cette distribution bien peu idéale devrait être rare. La plupart des changements traités par le contrôleur EndpointSlice sera suffisamment petite pour tenir dans un EndpointSlice existant, et sinon, un nouveau EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour continues des déploiements fournissent également une compaction naturelle des EndpointSlices avec tous leurs pods et les Endpoints correspondants qui se feront remplacer. + +## Motivation + +L'API des Endpoints fournit une méthode simple et facile à suivre pour les Endpoints dans Kubernetes. +Malheureusement, comme les clusters Kubernetes et Services sont devenus plus larges, les limitations de cette API sont devenues plus visibles. +Plus particulièrement, ceux-ci comprenaient des limitations liés au dimensionnement vers un plus grand nombre d'Endpoint d'un réseau. + +Puisque tous les Endpoints d'un réseau pour un Service ont été stockés dans une seule ressource Endpoints, ces ressources pourraient devenir assez lourdes. +Cela a affecté les performances des composants Kubernetes (notamment le plan de contrôle) et a causé une grande quantité de trafic réseau et de traitements lorsque les Endpoints changent. +Les EndpointSlices aident à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [Activer EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices) +* Lire [Connecter des applications aux Services](/docs/concepts/services-networking/connect-applications-service/) + +{{% /capture %}} \ No newline at end of file diff --git a/content/id/docs/concepts/_index.md b/content/id/docs/concepts/_index.md index 31a1404f48..cd135ca14d 100644 --- a/content/id/docs/concepts/_index.md +++ b/content/id/docs/concepts/_index.md @@ -17,11 +17,11 @@ kamu belajar lebih dalam bagaimana cara kerja Kubernetes. ## Ikhtisar -Untuk menggunakan Kubernetes, kamu menggunakan obyek-obyek *Kubernetes API* untuk merepresentasikan +Untuk menggunakan Kubernetes, kamu menggunakan objek-objek *Kubernetes API* untuk merepresentasikan *state* yang diinginkan: apa yang aplikasi atau *workload* lain yang ingin kamu jalankan, *image* kontainer yang digunakan, jaringan atau *resource disk* apa yang ingin kamu sediakan, dan lain sebagainya. Kamu membuat *state* yang diinginkan dengan cara membuat -obyek dengan menggunakan API Kubernetes, dan biasanya menggunakan `command-line interface`, yaitu `kubectl`. +objek dengan menggunakan API Kubernetes, dan biasanya menggunakan `command-line interface`, yaitu `kubectl`. Kamu juga dapat secara langsung berinteraksi dengan klaster untuk membuat atau mengubah *state* yang kamu inginkan. @@ -38,16 +38,16 @@ suatu aplikasi, dan lain sebagainya. *Control Plane* Kubernetes terdiri dari sek * **[kubelet](/docs/admin/kubelet/)**, yang menjadi perantara komunikasi dengan *master*. * **[kube-proxy](/docs/admin/kube-proxy/)**, sebuah *proxy* yang merupakan representasi jaringan yang ada pada setiap *node*. -## Obyek Kubernetes +## Objek Kubernetes Kubernetes memiliki beberapa abstraksi yang merepresentasikan *state* dari sistem kamu: apa yang aplikasi atau *workload* lain yang ingin kamu jalankan, jaringan atau *resource disk* apa yang ingin kamu sediakan, serta beberapa informasi lain terkait apa yang sedang klaster kamu lakukan. -Abstraksi ini direpresentasikan oleh obyek yang tersedia di API Kubernetes; -lihat [ikhtisar obyek-obyek Kubernetes](/docs/concepts/abstractions/overview/) +Abstraksi ini direpresentasikan oleh objek yang tersedia di API Kubernetes; +lihat [ikhtisar objek-objek Kubernetes](/docs/concepts/abstractions/overview/) untuk penjelasan yang lebih mendetail. -Obyek mendasar Kubernetes termasuk: +Objek mendasar Kubernetes termasuk: * [Pod](/docs/concepts/workloads/pods/pod-overview/) * [Service](/docs/concepts/services-networking/service/) @@ -55,7 +55,7 @@ Obyek mendasar Kubernetes termasuk: * [Namespace](/docs/concepts/overview/working-with-objects/namespaces/) Sebagai tambahan, Kubernetes memiliki beberapa abstraksi yang lebih tinggi yang disebut kontroler. -Kontroler merupakan obyek mendasar dengan fungsi tambahan, contoh dari kontroler ini adalah: +Kontroler merupakan objek mendasar dengan fungsi tambahan, contoh dari kontroler ini adalah: * [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) * [Deployment](/docs/concepts/workloads/controllers/deployment/) @@ -67,14 +67,14 @@ Kontroler merupakan obyek mendasar dengan fungsi tambahan, contoh dari kontroler Berbagai bagian *Control Plane* Kubernetes, seperti *master* dan *process-process* kubelet, mengatur bagaimana Kubernetes berkomunikasi dengan klaster kamu. *Control Plane* -menjaga seluruh *record* dari obyek Kubernetes serta terus menjalankan -iterasi untuk melakukan manajemen *state* obyek. *Control Plane* akan memberikan respon +menjaga seluruh *record* dari objek Kubernetes serta terus menjalankan +iterasi untuk melakukan manajemen *state* objek. *Control Plane* akan memberikan respon apabila terdapat perubahan pada klaster kamu dan mengubah *state* saat ini agar sesuai dengan *state* yang diinginkan. Contohnya, ketika kamu menggunakan API Kubernetes untuk membuat sebuah *Deployment*, kamu memberikan sebuah *state* baru yang harus dipenuhi oleh sistem. *Control Plane* -kemudian akan mencatat obyek apa saja yang dibuat, serta menjalankan instruksi yang kamu berikan +kemudian akan mencatat objek apa saja yang dibuat, serta menjalankan instruksi yang kamu berikan dengan cara melakukan `start` aplikasi dan melakukan `scheduling` aplikasi tersebut pada *node*, dengan kata lain mengubah *state* saat ini agar sesuai dengan *state* yang diinginkan. @@ -92,7 +92,7 @@ kamu berkomunikasi dengan *master* klaster Kubernetes kamu. menjalankan aplikasi kamu. Master mengontrol setiap node; kamu akan jarang berinteraksi dengan *node* secara langsung. -#### Metadata obyek +#### Metadata objek * [Anotasi](/docs/concepts/overview/working-with-objects/annotations/) diff --git a/content/id/docs/concepts/architecture/controller.md b/content/id/docs/concepts/architecture/controller.md new file mode 100644 index 0000000000..4ce6974b34 --- /dev/null +++ b/content/id/docs/concepts/architecture/controller.md @@ -0,0 +1,178 @@ +--- +title: Controller +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +Dalam bidang robotika dan otomatisasi, _control loop_ atau kontrol tertutup adalah +lingkaran tertutup yang mengatur keadaan suatu sistem. + +Berikut adalah salah satu contoh kontrol tertutup: termostat di sebuah ruangan. + +Ketika kamu mengatur suhunya, itu mengisyaratkan ke termostat +tentang *keadaan yang kamu inginkan*. Sedangkan suhu kamar yang sebenarnya +adalah *keadaan saat ini*. Termostat berfungsi untuk membawa keadaan saat ini +mendekati ke keadaan yang diinginkan, dengan menghidupkan atau mematikan +perangkat. + +Di Kubernetes, _controller_ adalah kontrol tertutup yang mengawasi keadaan klaster +{{< glossary_tooltip term_id="cluster" text="klaster" >}} kamu, lalu membuat atau meminta +perubahan jika diperlukan. Setiap _controller_ mencoba untuk memindahkan status +klaster saat ini mendekati keadaan yang diinginkan. + +{{< glossary_definition term_id="controller" length="short">}} + +{{% /capture %}} + + +{{% capture body %}} + +## Pola _controller_ + +Sebuah _controller_ melacak sekurang-kurangnya satu jenis sumber daya dari +Kubernetes. +[objek-objek](/docs/concepts/overview/working-with-objects/kubernetes-objects/) ini +memiliki *spec field* yang merepresentasikan keadaan yang diinginkan. Satu atau +lebih _controller_ untuk *resource* tersebut bertanggung jawab untuk membuat +keadaan sekarang mendekati keadaan yang diinginkan. + +_Controller_ mungkin saja melakukan tindakan itu sendiri; namun secara umum, di +Kubernetes, _controller_ akan mengirim pesan ke +{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} yang +mempunyai efek samping yang bermanfaat. Kamu bisa melihat contoh-contoh +di bawah ini. + +{{< comment >}} +Beberapa _controller_ bawaan, seperti _controller namespace_, bekerja pada objek +yang tidak memiliki *spec*. Agar lebih sederhana, halaman ini tidak +menjelaskannya secara detail. +{{< /comment >}} + +### Kontrol melalui server API + +_Controller_ {{< glossary_tooltip term_id="job" >}} adalah contoh dari _controller_ +bawaan dari Kubernetes. _Controller_ bawaan tersebut mengelola status melalui +interaksi dengan server API dari suatu klaster. + +Job adalah sumber daya dalam Kubernetes yang menjalankan a +{{< glossary_tooltip term_id="pod" >}}, atau mungkin beberapa Pod sekaligus, +untuk melakukan sebuah pekerjaan dan kemudian berhenti. + +(Setelah [dijadwalkan](../../../../en/docs/concepts/scheduling/), objek Pod +akan menjadi bagian dari keadaan yang diinginkan oleh kubelet). + +Ketika _controller job_ melihat tugas baru, maka _controller_ itu memastikan bahwa, +di suatu tempat pada klaster kamu, kubelet dalam sekumpulan Node menjalankan +Pod-Pod dengan jumlah yang benar untuk menyelesaikan pekerjaan. _Controller job_ +tidak menjalankan sejumlah Pod atau kontainer apa pun untuk dirinya sendiri. +Namun, _controller job_ mengisyaratkan kepada server API untuk membuat atau +menghapus Pod. Komponen-komponen lain dalam +{{< glossary_tooltip text="control plane" term_id="control-plane" >}} +bekerja berdasarkan informasi baru (adakah Pod-Pod baru untuk menjadwalkan dan +menjalankan pekerjan), dan pada akhirnya pekerjaan itu selesai. + +Setelah kamu membuat Job baru, status yang diharapkan adalah bagaimana +pekerjaan itu bisa selesai. _Controller job_ membuat status pekerjaan saat ini +agar mendekati dengan keadaan yang kamu inginkan: membuat Pod yang melakukan +pekerjaan yang kamu inginkan untuk Job tersebut, sehingga Job hampir +terselesaikan. + +_Controller_ juga memperbarui objek yang mengkonfigurasinya. Misalnya: setelah +pekerjaan dilakukan untuk Job tersebut, _controller job_ memperbarui objek Job +dengan menandainya `Finished`. + +(Ini hampir sama dengan bagaimana beberapa termostat mematikan lampu untuk +mengindikasikan bahwa kamar kamu sekarang sudah berada pada suhu yang kamu +inginkan). + +### Kontrol Langsung + +Berbeda dengan sebuah Job, beberapa dari _controller_ perlu melakukan perubahan +sesuatu di luar dari klaster kamu. + +Sebagai contoh, jika kamu menggunakan kontrol tertutup untuk memastikan apakah +cukup {{< glossary_tooltip text="Node" term_id="node" >}} +dalam kluster kamu, maka _controller_ memerlukan sesuatu di luar klaster saat ini +untuk mengatur Node-Node baru apabila dibutuhkan. + +_controller_ yang berinteraksi dengan keadaan eksternal dapat menemukan keadaan +yang diinginkannya melalui server API, dan kemudian berkomunikasi langsung +dengan sistem eksternal untuk membawa keadaan saat ini mendekat keadaan yang +diinginkan. + +(Sebenarnya ada sebuah _controller_ yang melakukan penskalaan node secara +horizontal dalam klaster kamu. Silahkan lihat +[_autoscaling_ klaster](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)). + +## Status sekarang berbanding status yang diinginkan {#sekarang-banding-diinginkan} + +Kubernetes mengambil pandangan sistem secara _cloud-native_, dan mampu menangani +perubahan yang konstan. + +Klaster kamu dapat mengalami perubahan kapan saja pada saat pekerjaan sedang +berlangsung dan kontrol tertutup secara otomatis memperbaiki setiap kegagalan. +Hal ini berarti bahwa, secara potensi, klaster kamu tidak akan pernah mencapai +kondisi stabil. + +Selama _controller_ dari klaster kamu berjalan dan mampu membuat perubahan yang +bermanfaat, tidak masalah apabila keadaan keseluruhan stabil atau tidak. + +## Perancangan + +Sebagai prinsip dasar perancangan, Kubernetes menggunakan banyak _controller_ yang +masing-masing mengelola aspek tertentu dari keadaan klaster. Yang paling umum, +kontrol tertutup tertentu menggunakan salah satu jenis sumber daya +sebagai suatu keadaan yang diinginkan, dan memiliki jenis sumber daya yang +berbeda untuk dikelola dalam rangka membuat keadaan yang diinginkan terjadi. + +Sangat penting untuk memiliki beberapa _controller_ sederhana daripada hanya satu +_controller_ saja, dimana satu kumpulan monolitik kontrol tertutup saling +berkaitan satu sama lain. Karena _controller_ bisa saja gagal, sehingga Kubernetes +dirancang untuk memungkinkan hal tersebut. + +Misalnya: _controller_ pekerjaan melacak objek pekerjaan (untuk menemukan +adanya pekerjaan baru) dan objek Pod (untuk menjalankan pekerjaan tersebut dan +kemudian melihat lagi ketika pekerjaan itu sudah selesai). Dalam hal ini yang +lain membuat pekerjaan, sedangkan _controller_ pekerjaan membuat Pod-Pod. + +{{< note >}} +Ada kemungkinan beberapa _controller_ membuat atau memperbarui jenis objek yang +sama. Namun di belakang layar, _controller_ Kubernetes memastikan bahwa mereka +hanya memperhatikan sumbr daya yang terkait dengan sumber daya yang mereka +kendalikan. + +Misalnya, kamu dapat memiliki Deployment dan Job; dimana keduanya akan membuat +Pod. _Controller Job_ tidak akan menghapus Pod yang dibuat oleh Deployment kamu, +karena ada informasi ({{< glossary_tooltip term_id="label" text="labels" >}}) +yang dapat oleh _controller_ untuk membedakan Pod-Pod tersebut. +{{< /note >}} + +## Berbagai cara menjalankan beberapa _controller_ {#menjalankan-_controller_} + +Kubernetes hadir dengan seperangkat _controller_ bawaan yang berjalan di dalam +{{< glossary_tooltip term_id="kube-controller-manager" >}}. Beberapa _controller_ +bawaan memberikan perilaku inti yang sangat penting. + +_Controller Deployment_ dan _controller Job_ adalah contoh dari _controller_ yang +hadir sebagai bagian dari Kubernetes itu sendiri (_controller_ "bawaan"). +Kubernetes memungkinkan kamu menjalankan _control plane_ yang tangguh, sehingga +jika ada _controller_ bawaan yang gagal, maka bagian lain dari _control plane_ akan +mengambil alih pekerjaan. + +Kamu juga dapat menemukan pengontrol yang berjalan di luar _control plane_, untuk +mengembangkan lebih jauh Kubernetes. Atau, jika mau, kamu bisa membuat +_controller_ baru sendiri. Kamu dapat menjalankan _controller_ kamu sendiri sebagai +satu kumpulan dari beberapa Pod, atau bisa juga sebagai bagian eksternal dari +Kubernetes. Manakah yang paling sesuai akan tergantung pada apa yang _controller_ +khusus itu lakukan. + +{{% /capture %}} + +{{% capture whatsnext %}} +* Silahkan baca tentang [_control plane_ Kubernetes](/docs/concepts/#kubernetes-control-plane) +* Temukan beberapa dasar tentang [objek-objek Kubernetes](/docs/concepts/#kubernetes-objects) +* Pelajari lebih lanjut tentang [Kubernetes API](/docs/concepts/overview/kubernetes-api/) +* Apabila kamu ingin membuat _controller_ sendiri, silakan lihat [pola perluasan](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) dalam memperluas Kubernetes. +{{% /capture %}} diff --git a/content/id/docs/concepts/cluster-administration/manage-deployment.md b/content/id/docs/concepts/cluster-administration/manage-deployment.md index d53b4106a6..5a94792af2 100644 --- a/content/id/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/id/docs/concepts/cluster-administration/manage-deployment.md @@ -255,7 +255,7 @@ Servis _frontend_ akan meliputi kedua set replika dengan menentukan subset bersa tier: frontend ``` -Anda dapat mengatur jumlah replika rilis _stable_ dan _canary_ untuk menentukan rasio dari tiap rilis yang akan menerima _traffic production live_ (dalam kasus ini 3:1). +Kamu dapat mengatur jumlah replika rilis _stable_ dan _canary_ untuk menentukan rasio dari tiap rilis yang akan menerima _traffic production live_ (dalam kasus ini 3:1). Ketika telah yakin, kamu dapat memindahkan _track stable_ ke rilis baru dan menghapus _canary_. Untuk contoh yang lebih jelas, silahkan cek [tutorial melakukan deploy Ghost](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary). @@ -322,7 +322,7 @@ kubectl scale deployment/my-nginx --replicas=1 deployment.extensions/my-nginx scaled ``` -Sekarang anda hanya memiliki satu _pod_ yang dikelola oleh deployment. +Sekarang kamu hanya memiliki satu _pod_ yang dikelola oleh deployment. ```shell kubectl get pods -l app=nginx diff --git a/content/id/docs/concepts/containers/container-environment-variables.md b/content/id/docs/concepts/containers/container-environment.md similarity index 98% rename from content/id/docs/concepts/containers/container-environment-variables.md rename to content/id/docs/concepts/containers/container-environment.md index 2a44dcbdcd..55c1bea6cb 100644 --- a/content/id/docs/concepts/containers/container-environment-variables.md +++ b/content/id/docs/concepts/containers/container-environment.md @@ -1,5 +1,5 @@ --- -title: Variabel Environment Kontainer +title: Kontainer Environment content_template: templates/concept weight: 20 --- diff --git a/content/id/docs/concepts/containers/overview.md b/content/id/docs/concepts/containers/overview.md new file mode 100644 index 0000000000..7ec5ef55d5 --- /dev/null +++ b/content/id/docs/concepts/containers/overview.md @@ -0,0 +1,49 @@ +--- +title: Ikhtisar Kontainer +content_template: templates/concept +weight: 1 +--- + +{{% capture overview %}} + +Kontainer adalah teknologi untuk mengemas kode (yang telah dikompilasi) menjadi +suatu aplikasi beserta dengan dependensi-dependensi yang dibutuhkannya pada saat +dijalankan. Setiap kontainer yang Anda jalankan dapat diulang; standardisasi +dengan menyertakan dependensinya berarti Anda akan mendapatkan perilaku yang +sama di mana pun Anda menjalankannya. + +Kontainer memisahkan aplikasi dari infrastruktur host yang ada dibawahnya. Hal +ini membuat penyebaran lebih mudah di lingkungan cloud atau OS yang berbeda. + +{{% /capture %}} + +{{% capture body %}} + +## Image-Image Kontainer + +[Kontainer image](/docs/concepts/containers/images/) meruapakan paket perangkat lunak +yang siap dijalankan, mengandung semua yang diperlukan untuk menjalankan +sebuah aplikasi: kode dan setiap *runtime* yang dibutuhkan, *library* dari +aplikasi dan sistem, dan nilai *default* untuk penganturan yang penting. + +Secara desain, kontainer tidak bisa berubah: Anda tidak dapat mengubah kode +dalam kontainer yang sedang berjalan. Jika Anda memiliki aplikasi yang +terkontainerisasi dan ingin melakukan perubahan, maka Anda perlu membuat +kontainer baru dengan menyertakan perubahannya, kemudian membuat ulang kontainer +dengan memulai dari _image_ yang sudah diubah. + +## Kontainer _runtime_ + +Kontainer *runtime* adalah perangkat lunak yang bertanggung jawab untuk +menjalankan kontainer. Kubernetes mendukung beberapa kontainer *runtime*: +{{< glossary_tooltip term_id="docker" >}}, +{{< glossary_tooltip term_id="containerd" >}}, +{{< glossary_tooltip term_id="cri-o" >}}, dan semua implementasi dari +[Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). + +## Selanjutnya + +- Baca tentang [image-image kontainer](https://kubernetes.io/docs/concepts/containers/images/) +- Baca tentang [Pod](https://kubernetes.io/docs/concepts/workloads/pods/) + +{{% /capture %}} \ No newline at end of file diff --git a/content/id/docs/reference/glossary/controller.md b/content/id/docs/reference/glossary/controller.md new file mode 100755 index 0000000000..c88dfccb14 --- /dev/null +++ b/content/id/docs/reference/glossary/controller.md @@ -0,0 +1,30 @@ +--- +title: Controller +id: controller +date: 2018-04-12 +full_link: /docs/concepts/architecture/controller/ +short_description: > + Kontrol tertutup yang mengawasi kondisi bersama dari klaster melalui apiserver dan membuat perubahan yang mencoba untuk membawa kondisi saat ini ke kondisi yang diinginkan. + +aka: +tags: +- architecture +- fundamental +--- +Di Kubernetes, _controller_ adalah kontrol tertutup yang mengawasi kondisi +{{< glossary_tooltip term_id="cluster" text="klaster">}} anda, lalu membuat atau +meminta perubahan jika diperlukan. +Setiap _controller_ mencoba untuk memindahkan status klaster saat ini lebih +dekat ke kondisi yang diinginkan. + + + +_Controller_ mengawasi keadaan bersama dari klaster kamu melalui +{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} (bagian dari +{{< glossary_tooltip term_id="control-plane" >}}). + +Beberapa _controller_ juga berjalan di dalam _control plane_, menyediakan +kontrol tertutup yang merupakan inti dari operasi Kubernetes. Sebagai contoh: +_controller Deployment_, _controller daemonset_, _controller namespace_, dan +_controller volume persisten_ (dan lainnya) semua berjalan di dalam +{{< glossary_tooltip term_id="kube-controller-manager" >}}. diff --git a/content/ja/docs/home/_index.md b/content/ja/docs/home/_index.md index c0f9abdb4c..1c46fab5b7 100644 --- a/content/ja/docs/home/_index.md +++ b/content/ja/docs/home/_index.md @@ -4,7 +4,7 @@ title: Kubernetesドキュメント noedit: true cid: docsHome layout: docsportal_home -class: gridPage +class: gridPage gridPageHome linkTitle: "ホーム" main_menu: true weight: 10 diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 423004b27e..42f14c04ef 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -180,7 +180,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 보다 훨씬 길다). - kubelet은 10초마다 리스 오브젝트를 생성하고 업데이트 한다(기본 업데이트 주기). 리스 업데이트는 `NodeStatus` 업데이트와는 - 독립적으로 발생한다. + 독립적으로 발생한다. 리스 업데이트가 실패하면 kubelet에 의해 재시도하며 7초로 제한된 지수 백오프를 200 밀리초에서 부터 시작한다. #### 안정성 diff --git a/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md index 2ae19a2961..bcae9a4a1d 100644 --- a/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -41,7 +41,7 @@ weight: 10 * [인증서](/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다. -* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment-variables/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다. +* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다. * [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 계정에 어떻게 권한 설정을 하는지 설명한다. diff --git a/content/ko/docs/concepts/configuration/assign-pod-node.md b/content/ko/docs/concepts/configuration/assign-pod-node.md index 027a7d38d3..5136fddeeb 100644 --- a/content/ko/docs/concepts/configuration/assign-pod-node.md +++ b/content/ko/docs/concepts/configuration/assign-pod-node.md @@ -315,7 +315,7 @@ spec: topologyKey: "kubernetes.io/hostname" containers: - name: web-app - image: nginx:1.12-alpine + image: nginx:1.16-alpine ``` 만약 위의 두 디플로이먼트를 생성하면 세 개의 노드가 있는 클러스터는 다음과 같아야 한다. diff --git a/content/ko/docs/concepts/containers/container-environment-variables.md b/content/ko/docs/concepts/containers/container-environment.md similarity index 100% rename from content/ko/docs/concepts/containers/container-environment-variables.md rename to content/ko/docs/concepts/containers/container-environment.md diff --git a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md index 6967e70fc0..6264621a24 100644 --- a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md @@ -113,7 +113,7 @@ Events: {{% capture whatsnext %}} -* [컨테이너 환경](/ko/docs/concepts/containers/container-environment-variables/)에 대해 더 배우기. +* [컨테이너 환경](/ko/docs/concepts/containers/container-environment/)에 대해 더 배우기. * [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실습 경험하기. diff --git a/content/ko/docs/concepts/containers/overview.md b/content/ko/docs/concepts/containers/overview.md new file mode 100644 index 0000000000..11d29a18ce --- /dev/null +++ b/content/ko/docs/concepts/containers/overview.md @@ -0,0 +1,43 @@ +--- +title: 컨테이너 개요 +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +컨테이너는 런타임에 필요한 종속성과 애플리케이션의 +컴파일 된 코드를 패키징 하는 기술이다. 실행되는 각각의 +컨테이너는 반복해서 사용 가능하다. 종속성이 포함된 표준화를 +통해 컨테이너가 실행되는 환경과 무관하게 항상 동일하게 +동작한다. + +컨테이너는 기본 호스트 인프라 환경에서 애플리케이션의 실행환경을 분리한다. +따라서 다양한 클라우드 환경이나 운영체제에서 쉽게 배포 할 수 있다. + +{{% /capture %}} + + +{{% capture body %}} + +## 컨테이너 이미지 +[컨테이너 이미지](/ko/docs/concepts/containers/images/) 는 즉시 실행할 수 있는 +소프트웨어 패키지이며, 애플리케이션을 실행하는데 필요한 모든 것 +(필요한 코드와 런타임, 애플리케이션 및 시스템 라이브러리 등의 모든 필수 설정에 대한 기본값) +을 포함한다. + +원칙적으로, 컨테이너는 변경되지 않는다. 이미 구동 중인 컨테이너의 +코드를 변경할 수 없다. 컨테이너화 된 애플리케이션이 있고 그 +애플리케이션을 변경하려는 경우, 변경사항을 포함하여 만든 +새로운 이미지를 통해 컨테이너를 다시 생성해야 한다. + + +## 컨테이너 런타임 + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +{{% /capture %}} +{{% capture whatsnext %}} +* [컨테이너 이미지](/ko/docs/concepts/containers/images/)에 대해 읽어보기 +* [파드](/ko/docs/concepts/workloads/pods/)에 대해 읽어보기 +{{% /capture %}} diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index befcefcfe4..eab78a19fb 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -10,22 +10,14 @@ weight: 20 이 페이지는 런타임 클래스(RuntimeClass) 리소스와 런타임 선택 메커니즘에 대해서 설명한다. -{{< warning >}} -런타임클래스는 v1.14 베타 업그레이드에서 *중대한* 변화를 포함한다. -런타임클래스를 v1.14 이전부터 사용하고 있었다면, -[런타임 클래스를 알파에서 베타로 업그레이드하기](#upgrading-runtimeclass-from-alpha-to-beta)를 확인한다. -{{< /warning >}} +런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임 +구성은 파드의 컨테이너를 실행하는데 사용된다. {{% /capture %}} {{% capture body %}} -## 런타임 클래스 - -런타임 클래스는 컨테이너 런타임 설정을 선택하는 기능이다. -이 컨테이너 런타임 설정은 파드의 컨테이너를 실행할 때에 이용한다. - ## 동기 서로 다른 파드간에 런타임 클래스를 설정하여 @@ -38,7 +30,7 @@ weight: 20 또한 런타임 클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른 여러 파드를 실행할 수 있다. -### 셋업 +## 셋업 RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다. 특징 게이트 활성화에 대한 설명은 [특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 @@ -47,7 +39,7 @@ RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다. 1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서) 2. 상응하는 런타임 클래스 리소스 생성 -#### 1. CRI 구현을 노드에 설정 +### 1. CRI 구현을 노드에 설정 런타임 클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다. 사용자의 CRI 구현에 따른 설정 방법은 @@ -62,7 +54,7 @@ RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다. 해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다. 런타임 핸들러는 유효한 DNS 1123 서브도메인(알파-숫자 + `-`와 `.`문자)을 가져야 한다. -#### 2. 상응하는 런타임 클래스 리소스 생성 +### 2. 상응하는 런타임 클래스 리소스 생성 1단계에서 셋업 한 설정은 연관된 `handler` 이름을 가져야 하며, 이를 통해서 설정을 식별할 수 있다. 각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 상응하는 런타임 클래스 오브젝트를 생성한다. @@ -88,7 +80,7 @@ handler: myconfiguration # 상응하는 CRI 설정의 이름임 더 자세한 정보는 [권한 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다. {{< /note >}} -### 사용 +## 사용 클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에 `runtimeClassName`를 명시한다. 예를 들면 다음과 같다. @@ -147,13 +139,13 @@ https://github.com/containerd/cri/blob/master/docs/config.md [100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md -### 스케줄 +## 스케줄 {{< feature-state for_k8s_version="v1.16" state="beta" >}} 쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터 지원을 포함한다. 이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 노드로 스케줄된다는 것을 보장할 수 있다. -이 스케줄링 기능을 사용하려면, 런타임 클래스 [어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본 값)해야 한다. +이 스케줄링 기능을 사용하려면, [런타임 클래스 어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본 값)해야 한다. 파드가 지정된 런타임 클래스를 지원하는 노드에 안착한다는 것을 보장하려면, 해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다. @@ -168,50 +160,24 @@ https://github.com/containerd/cri/blob/master/docs/config.md 노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면 [노드에 파드 할당](/ko/docs/concepts/configuration/assign-pod-node/)을 참고한다. -[어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/ +[런타임 클래스 어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass ### 파드 오버헤드 -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} +{{< feature-state for_k8s_version="v1.18" state="beta" >}} -쿠버네티스 v1.16 부터는, 런타임 클래스에는 구동 중인 파드와 관련된 오버헤드를 -지정할 수 있는 기능이 [`PodOverhead`](/docs/concepts/configuration/pod-overhead) 기능을 통해 지원된다. -`PodOverhead`를 사용하려면, PodOverhead [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 -활성화 시켜야 한다. (기본 값으로는 비활성화 되어 있다.) +파드 실행과 연관되는 _오버헤드_ 리소스를 지정할 수 있다. 오버헤드를 선언하면 +클러스터(스케줄러 포함)가 파드와 리소스에 대한 결정을 내릴 때 처리를 할 수 있다. +PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) +를 활성화 시켜야 한다. (기본으로 활성화 되어 있다.) -파드 오버헤드는 런타임 클래스에서 `Overhead` 필드를 통해 정의된다. 이 필드를 사용하면, +파드 오버헤드는 런타임 클래스에서 `overhead` 필드를 통해 정의된다. 이 필드를 사용하면, 해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가 쿠버네티스 내에서 처리된다는 것을 보장할 수 있다. -### 런타임 클래스를 알파에서 베타로 업그레이드 {#upgrading-runtimeclass-from-alpha-to-beta} - -런타임 클래스 베타 기능은 다음의 변화를 포함한다. - -- `node.k8s.io` API 그룹과 `runtimeclasses.node.k8s.io` 리소스는 CustomResourceDefinition에서 - 내장 API로 이전되었다. -- 런타임 클래스 정의에서 `spec`을 직접 사용할 수 있다. - (즉, 더 이상 RuntimeClassSpec는 없다). -- `runtimeHandler` 필드는 `handler`로 이름이 바뀌었다. -- `handler` 필드는 이제 모두 API 버전에서 요구된다. 이는 알파 API에서도 `runtimeHandler` 필드가 - 필요하다는 의미이다. -- `handler` 필드는 반드시 올바른 DNS 레이블([RFC 1123](https://tools.ietf.org/html/rfc1123))으로, - 이는 더 이상 `.` 캐릭터(모든 버전에서)를 포함할 수 없다 의미이다. 올바른 핸들러는 - 다음의 정규 표현식을 따른다. `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`. - -**작업 필요** 다음 작업은 알파 버전의 런타임 기능을 -베타 버전으로 업그레이드하기 위해 진행되어야 한다. - -- 런타임 클래스 리소스는 v1.14로 업그레이드 *후에* 반드시 재생성되어야 하고, - `runtimeclasses.node.k8s.io` CRD는 다음과 같이 수동으로 지워야 한다. - ``` - kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io - ``` -- 지정되지 않았거나 비어 있는 `runtimeHandler` 이거나 핸들러 내에 `.` 캐릭터를 사용한 알파 런타임 클래스는 - 더 이상 올바르지 않으며, 반드시 올바른 핸들러 구성으로 이전헤야 한다 - (위를 참조). - -### 더 읽기 +{{% /capture %}} +{{% capture 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) 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 new file mode 100644 index 0000000000..e7e380d6ba --- /dev/null +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -0,0 +1,254 @@ +--- +title: 커스텀 리소스 +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +*커스텀 리소스* 는 쿠버네티스 API의 익스텐션이다. 이 페이지에서는 쿠버네티스 클러스터에 +커스텀 리소스를 추가할 시기와 독립형 서비스를 사용하는 시기에 대해 설명한다. 커스텀 리소스를 +추가하는 두 가지 방법과 이들 중에서 선택하는 방법에 대해 설명한다. + +{{% /capture %}} + +{{% capture body %}} +## 커스텀 리소스 + +*리소스* 는 [쿠버네티스 API](/ko/docs/reference/using-api/api-overview/)에서 특정 종류의 +[API 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 모음을 저장하는 엔드포인트이다. 예를 들어 빌트인 *파드* 리소스에는 파드 오브젝트 모음이 포함되어 있다. + +*커스텀 리소스* 는 쿠버네티스 API의 익스텐션으로, 기본 쿠버네티스 설치에서 반드시 +사용할 수 있는 것은 아니다. 이는 특정 쿠버네티스 설치에 수정이 가해졌음을 나타낸다. 그러나 +많은 핵심 쿠버네티스 기능은 이제 커스텀 리소스를 사용하여 구축되어, 쿠버네티스를 더욱 모듈화한다. + +동적 등록을 통해 실행 중인 클러스터에서 커스텀 리소스가 나타나거나 사라질 수 있으며 +클러스터 관리자는 클러스터 자체와 독립적으로 커스텀 리소스를 업데이트 할 수 있다. +커스텀 리소스가 설치되면 사용자는 *파드* 와 같은 빌트인 리소스와 마찬가지로 +[kubectl](/docs/user-guide/kubectl-overview/)을 사용하여 해당 오브젝트를 생성하고 +접근할 수 있다. + +## 커스텀 컨트롤러 + +자체적으로 커스텀 리소스를 사용하면 구조화된 데이터를 저장하고 검색할 수 있다. +커스텀 리소스를 *커스텀 컨트롤러* 와 결합하면, 커스텀 리소스가 진정한 +_선언적(declarative) API_ 를 제공하게 된다. + +[선언적 API](/ko/docs/concepts/overview/kubernetes-api/)는 리소스의 의도한 상태를 +_선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트의 현재 상태를 의도한 상태와 +동기화 상태로 유지하려고 한다. 컨트롤러는 구조화된 데이터를 사용자가 +원하는 상태의 레코드로 해석하고 지속적으로 +이 상태를 유지한다. + +클러스터 라이프사이클과 관계없이 실행 중인 클러스터에 커스텀 컨트롤러를 배포하고 +업데이트할 수 있다. 커스텀 컨트롤러는 모든 종류의 리소스와 함께 작동할 수 있지만 +커스텀 리소스와 결합할 때 특히 효과적이다. +[오퍼레이터 패턴](https://coreos.com/blog/introducing-operators.html)은 사용자 정의 +리소스와 커스텀 컨트롤러를 결합한다. 커스텀 컨트롤러를 사용하여 특정 애플리케이션에 대한 도메인 지식을 +쿠버네티스 API의 익스텐션으로 인코딩할 수 있다. + +## 쿠버네티스 클러스터에 커스텀 리소스를 추가해야 하나? + +새로운 API를 생성할 때 [쿠버네티스 클러스터 API와 생성한 API를 애그리게이트](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)할 것인지 아니면 생성한 API를 독립적으로 유지할 것인지 고려하자. + +| API 애그리게이트를 고려할 경우 | 독립 API를 고려할 경우 | +| ---------------------------- | ---------------------------- | +| API가 [선언적](#선언적-api)이다. | API가 [선언적](#선언적-api) 모델에 맞지 않다. | +| `kubectl`을 사용하여 새로운 타입을 읽고 쓸 수 있기를 원한다.| `kubectl` 지원이 필요하지 않다. | +| 쿠버네티스 UI(예: 대시보드)에서 빌트인 타입과 함께 새로운 타입을 보길 원한다. | 쿠버네티스 UI 지원이 필요하지 않다. | +| 새로운 API를 개발 중이다. | 생성한 API를 제공하는 프로그램이 이미 있고 잘 작동하고 있다. | +| API 그룹 및 네임스페이스와 같은 REST 리소스 경로에 적용하는 쿠버네티스의 형식 제한을 기꺼이 수용한다. ([API 개요](/ko/docs/concepts/overview/kubernetes-api/)를 참고한다.) | 이미 정의된 REST API와 호환되도록 특정 REST 경로가 있어야 한다. | +| 자체 리소스는 자연스럽게 클러스터 또는 클러스터의 네임스페이스로 범위가 지정된다. | 클러스터 또는 네임스페이스 범위의 리소스는 적합하지 않다. 특정 리소스 경로를 제어해야 한다. | +| [쿠버네티스 API 지원 기능](#일반적인-기능)을 재사용하려고 한다. | 이러한 기능이 필요하지 않다. | + +### 선언적 API + +선언적 API에서는 다음의 특성이 있다. + + - API는 상대적으로 적은 수의 상대적으로 작은 오브젝트(리소스)로 구성된다. + - 오브젝트는 애플리케이션 또는 인프라의 구성을 정의한다. + - 오브젝트는 비교적 드물게 업데이트 된다. + - 사람이 종종 오브젝트를 읽고 쓸 필요가 있다. + - 오브젝트의 주요 작업은 CRUD-y(생성, 읽기, 업데이트 및 삭제)이다. + - 오브젝트 간 트랜잭션은 필요하지 않다. API는 정확한(exact) 상태가 아니라 의도한 상태를 나타낸다. + +명령형 API는 선언적이지 않다. +자신의 API가 선언적이지 않을 수 있다는 징후는 다음과 같다. + + - 클라이언트는 "이 작업을 수행한다"라고 말하고 완료되면 동기(synchronous) 응답을 받는다. + - 클라이언트는 "이 작업을 수행한다"라고 말한 다음 작업 ID를 다시 가져오고 별도의 오퍼레이션(operation) 오브젝트를 확인하여 요청의 완료 여부를 결정해야 한다. + - RPC(원격 프로시저 호출)에 대해 얘기한다. + - 대량의 데이터를 직접 저장한다(예: > 오브젝트별 몇 kB 또는 >1000개의 오브젝트). + - 높은 대역폭 접근(초당 10개의 지속적인 요청)이 필요하다. + - 최종 사용자 데이터(예: 이미지, PII 등) 또는 애플리케이션에서 처리한 기타 대규모 데이터를 저장한다. + - 오브젝트에 대한 자연스러운 조작은 CRUD-y가 아니다. + - API는 오브젝트로 쉽게 모델링되지 않는다. + - 작업 ID 또는 작업 오브젝트로 보류 중인 작업을 나타내도록 선택했다. + +## 컨피그맵을 사용해야 하나, 커스텀 리소스를 사용해야 하나? + +다음 중 하나에 해당하면 컨피그맵을 사용하자. + +* `mysql.cnf` 또는 `pom.xml`과 같이 잘 문서화된 기존 구성 파일 형식이 있다. +* 전체 구성 파일을 컨피그맵의 하나의 키에 넣고 싶다. +* 구성 파일의 주요 용도는 클러스터의 파드에서 실행 중인 프로그램이 파일을 사용하여 자체 구성하는 것이다. +* 파일 사용자는 쿠버네티스 API가 아닌 파드의 환경 변수 또는 파드의 파일을 통해 사용하는 것을 선호한다. +* 파일이 업데이트될 때 디플로이먼트 등을 통해 롤링 업데이트를 수행하려고 한다. + +{{< note >}} +민감한 데이터에는 [시크릿](/docs/concepts/configuration/secret/)을 사용하자. 이는 컨피그맵과 비슷하지만 더 안전한다. +{{< /note >}} + +다음 중 대부분이 적용되는 경우 커스텀 리소스(CRD 또는 애그리게이트 API(aggregated API))를 사용하자. + +* 쿠버네티스 클라이언트 라이브러리 및 CLI를 사용하여 새 리소스를 만들고 업데이트하려고 한다. +* kubectl의 최상위 지원을 원한다(예: `kubectl get my-object object-name`). +* 새 오브젝트에 대한 업데이트를 감시한 다음 다른 오브젝트를 CRUD하거나 그 반대로 하는 새로운 자동화를 구축하려고 한다. +* 오브젝트의 업데이트를 처리하는 자동화를 작성하려고 한다. +* `.spec`, `.status` 및 `.metadata`와 같은 쿠버네티스 API 규칙을 사용하려고 한다. +* 제어된 리소스의 콜렉션 또는 다른 리소스의 요약에 대한 오브젝트가 되기를 원한다. + +## 커스텀 리소스 추가 + +쿠버네티스는 클러스터에 커스텀 리소스를 추가하는 두 가지 방법을 제공한다. + +- CRD는 간단하며 프로그래밍 없이 만들 수 있다. +- [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)에는 프로그래밍이 필요하지만, 데이터 저장 방법 및 API 버전 간 변환과 같은 API 동작을 보다 강력하게 제어할 수 있다. + +쿠버네티스는 다양한 사용자의 요구를 충족시키기 위해 이 두 가지 옵션을 제공하므로 사용의 용이성이나 유연성이 저하되지 않는다. + +애그리게이트 API는 기본 API 서버 뒤에 있는 하위 API 서버이며 프록시 역할을 한다. 이 배치를 [API 애그리게이션](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)(AA)이라고 한다. 사용자에게는 쿠버네티스 API가 확장된 것과 같다. + +CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입의 리소스를 생성할 수 있다. CRD를 사용하기 위해 API 애그리게이션을 이해할 필요는 없다. + +설치 방법에 관계없이 새 리소스는 커스텀 리소스라고 하며 빌트인 쿠버네티스 리소스(파드 등)와 구별된다. + +## 커스텀리소스데피니션 + +[커스텀리소스데피니션](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) +API 리소스를 사용하면 커스텀 리소스를 정의할 수 있다. +CRD 오브젝트를 정의하면 지정한 이름과 스키마를 사용하여 새 커스텀 리소스가 만들어진다. +쿠버네티스 API는 커스텀 리소스의 스토리지를 제공하고 처리한다. +CRD 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다. + +따라서 커스텀 리소스를 처리하기 위해 자신의 API 서버를 작성할 수 없지만 +구현의 일반적인 특성으로 인해 +[API 서버 애그리게이션](#api-서버-애그리게이션)보다 유연성이 떨어진다. + +새 커스텀 리소스를 등록하고 새 리소스 타입의 인스턴스에 대해 작업하고 +컨트롤러를 사용하여 이벤트를 처리하는 방법에 대한 예제는 +[커스텀 컨트롤러 예제](https://github.com/kubernetes/sample-controller)를 참고한다. + +## API 서버 애그리게이션 + +일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 ​​있다. + +[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 독립형 API 서버를 +작성하고 배포하여 커스텀 리소스에 대한 특수한 구현을 제공할 수 있다. +기본 API 서버는 처리하는 커스텀 리소스에 대한 요청을 사용자에게 위임하여 +모든 클라이언트가 사용할 수 있게 한다. + +## 커스텀 리소스를 추가할 방법 선택 + +CRD는 사용하기가 더 쉽다. 애그리게이트 API가 더 유연하다. 자신의 요구에 가장 잘 맞는 방법을 선택하자. + +일반적으로 CRD는 다음과 같은 경우에 적합하다. + +* 필드가 몇 개 되지 않는다 +* 회사 내에서 또는 소규모 오픈소스 프로젝트의 일부인(상용 제품이 아닌) 리소스를 사용하고 있다. + +### 사용 편의성 비교 + +CRD는 애그리게이트 API보다 생성하기가 쉽다. + +| CRD | 애그리게이트 API | +| --------------------------- | -------------- | +| 프로그래밍이 필요하지 않다. 사용자는 CRD 컨트롤러에 대한 모든 언어를 선택할 수 있다. | Go로 프로그래밍하고 바이너리와 이미지를 빌드해야 한다. | +| 실행할 추가 서비스가 없다. CR은 API 서버에서 처리한다. | 추가 서비스를 생성하면 실패할 수 있다. | +| CRD가 생성된 후에는 지속적인 지원이 없다. 모든 버그 픽스는 일반적인 쿠버네티스 마스터 업그레이드의 일부로 선택된다. | 업스트림에서 버그 픽스를 주기적으로 선택하고 애그리게이트 API 서버를 다시 빌드하고 업데이트해야 할 수 있다. | +| 여러 버전의 API를 처리할 필요가 없다. 예를 들어, 이 리소스에 대한 클라이언트를 제어할 때 API와 동기화하여 업그레이드할 수 있다. | 인터넷에 공유할 익스텐션을 개발할 때와 같이 여러 버전의 API를 처리해야 한다. | + +### 고급 기능 및 유연성 + +애그리게이트 API는 보다 고급 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) | 예 | +| 사용자 정의 스토리지 | 다른 성능 모드(예를 들어, 키-값 저장소 대신 시계열 데이터베이스)나 보안에 대한 격리(예를 들어, 암호화된 시크릿이나 다른 암호화) 기능을 가진 스토리지가 필요한 경우 | 아니오 | 예 | +| 사용자 정의 비즈니스 로직 | 오브젝트를 생성, 읽기, 업데이트 또는 삭제를 할 때 임의의 점검 또는 조치를 수행한다. | 예, [웹훅](/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) | 예 | +| 기타 서브리소스 | "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/)를 참고한다. | 아니오 | 예 | +| 프로토콜 버퍼 | 새로운 리소스는 프로토콜 버퍼를 사용하려는 클라이언트를 지원한다. | 아니오 | 예 | +| OpenAPI 스키마 | 서버에서 동적으로 가져올 수 있는 타입에 대한 OpenAPI(스웨거(swagger)) 스키마가 있는가? 허용된 필드만 설정하여 맞춤법이 틀린 필드 이름으로부터 사용자를 보호하는가? 타입이 적용되는가(즉, `string` 필드에 `int`를 넣지 않는가?) | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)를 기반으로 하는 스키마(1.16에서 GA) | 예 | + +### 일반적인 기능 + +CRD 또는 AA를 통해 커스텀 리소스를 생성하면 쿠버네티스 플랫폼 외부에서 구현하는 것과 비교하여 API에 대한 많은 기능이 제공된다. + +| 기능 | 설명 | +| ------- | ------------ | +| CRUD | 새로운 엔드포인트는 HTTP 및 `kubectl`을 통해 CRUD 기본 작업을 지원한다. | +| 감시 | 새로운 엔드포인트는 HTTP를 통해 쿠버네티스 감시 작업을 지원한다. | +| 디스커버리 | kubectl 및 대시보드와 같은 클라이언트는 리소스에 대해 목록, 표시 및 필드 수정 작업을 자동으로 제공한다. | +| json-patch | 새로운 엔드포인트는 `Content-Type: application/json-patch+json` 형식의 PATCH를 지원한다. | +| merge-patch | 새로운 엔드포인트는 `Content-Type: application/merge-patch+json` 형식의 PATCH를 지원한다. | +| HTTPS | 새로운 엔드포인트는 HTTPS를 사용한다. | +| 빌트인 인증 | 익스텐션에 대한 접근은 인증을 위해 기본 API 서버(애그리게이션 레이어)를 사용한다. | +| 빌트인 권한 부여 | 익스텐션에 접근하면 기본 API 서버(예: RBAC)에서 사용하는 권한을 재사용할 수 있다. | +| Finalizer | 외부 정리가 발생할 때까지 익스텐션 리소스의 삭제를 차단한다. | +| 어드미션 웹훅 | 생성/업데이트/삭제 작업 중에 기본값을 설정하고 익스텐션 리소스의 유효성 검사를 한다. | +| UI/CLI 디스플레이 | Kubectl, 대시보드는 익스텐션 리소스를 표시할 수 있다. | +| 설정하지 않음(unset)과 비어있음(empty) | 클라이언트는 값이 없는 필드 중에서 설정되지 않은 필드를 구별할 수 있다. | +| 클라이언트 라이브러리 생성 | 쿠버네티스는 일반 클라이언트 라이브러리와 타입별 클라이언트 라이브러리를 생성하는 도구를 제공한다. | +| 레이블 및 어노테이션 | 공통 메타데이터는 핵심 및 커스텀 리소스를 수정하는 방법을 알고 있는 도구이다. | + +## 커스텀 리소스 설치 준비 + +클러스터에 커스텀 리소스를 추가하기 전에 알아야 할 몇 가지 사항이 있다. + +### 써드파티 코드 및 새로운 장애 포인트 + +CRD를 생성해도 새로운 장애 포인트(예를 들어, API 서버에서 장애를 유발하는 써드파티 코드가 실행됨)가 자동으로 추가되지는 않지만, 패키지(예: 차트(Charts)) 또는 기타 설치 번들에는 CRD 및 새로운 커스텀 리소스에 대한 비즈니스 로직을 구현하는 써드파티 코드의 디플로이먼트가 포함되는 경우가 종종 있다. + +애그리게이트 API 서버를 설치하려면 항상 새 디플로이먼트를 실행해야 한다. + +### 스토리지 + +커스텀 리소스는 컨피그맵과 동일한 방식으로 스토리지 공간을 사용한다. 너무 많은 커스텀 리소스를 생성하면 API 서버의 스토리지 공간이 과부하될 수 있다. + +애그리게이트 API 서버는 기본 API 서버와 동일한 스토리지를 사용할 수 있으며 이 경우 동일한 경고가 적용된다. + +### 인증, 권한 부여 및 감사 + +CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부여 및 감사 로깅을 사용한다. + +권한 부여에 RBAC를 사용하는 경우 대부분의 RBAC 역할은 새로운 리소스에 대한 접근 권한을 부여하지 않는다(클러스터 관리자 역할 또는 와일드 카드 규칙으로 생성된 역할 제외). 새로운 리소스에 대한 접근 권한을 명시적으로 부여해야 한다. CRD 및 애그리게이트 API는 종종 추가하는 타입에 대한 새로운 역할 정의와 함께 제공된다. + +애그리게이트 API 서버는 기본 API 서버와 동일한 인증, 권한 부여 및 감사를 사용하거나 사용하지 않을 수 있다. + +## 커스텀 리소스에 접근 + +쿠버네티스 [클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. Go와 python 클라이언트 라이브러리가 지원한다. + +커스텀 리소스를 추가하면 다음을 사용하여 접근할 수 있다. + +- kubectl +- 쿠버네티스 동적 클라이언트 +- 작성한 REST 클라이언트 +- [쿠버네티스 클라이언트 생성 도구](https://github.com/kubernetes/code-generator)를 사용하여 생성된 클라이언트(하나를 생성하는 것은 고급 기능이지만, 일부 프로젝트는 CRD 또는 AA와 함께 클라이언트를 제공할 수 있다). + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)하는 방법에 대해 배우기. + +* [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md new file mode 100644 index 0000000000..a2a7c1745c --- /dev/null +++ b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md @@ -0,0 +1,205 @@ +--- +title: 쿠버네티스 클러스터 확장 +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로 +쿠버네티스 프로젝트를 포크하거나 코드에 패치를 제출할 필요가 +거의 없다. + +이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다. +쿠버네티스 클러스터를 업무 환경의 요구에 맞게 +조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 대상으로 한다. +잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도 +어떤 익스텐션 포인트와 패턴이 있는지, +그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다. + +{{% /capture %}} + + +{{% capture body %}} + +## 개요 + +사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로 나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다. + +## 구성 + +*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다. + +* [kubelet](/docs/admin/kubelet/) +* [kube-apiserver](/docs/admin/kube-apiserver/) +* [kube-controller-manager](/docs/admin/kube-controller-manager/) +* [kube-scheduler](/docs/admin/kube-scheduler/). + +호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다. + +[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 ​​있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 구성 파일과 플래그보다 선호된다. + +## 익스텐션(Extension) {#익스텐션} + +익스텐션은 쿠버네티스를 확장하고 쿠버네티스와 긴밀하게 통합되는 소프트웨어 컴포넌트이다. +이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다. + +대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다. +결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 있고 +새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다. + +## 익스텐션 패턴 + +쿠버네티스는 클라이언트 프로그램을 작성하여 자동화 되도록 설계되었다. +쿠버네티스 API를 읽고 쓰는 프로그램은 유용한 자동화를 제공할 수 있다. +*자동화* 는 클러스터 상에서 또는 클러스터 밖에서 실행할 수 있다. 이 문서의 지침에 따라 +고가용성과 강력한 자동화를 작성할 수 있다. +자동화는 일반적으로 호스트 클러스터 및 매니지드 설치 환경을 포함한 모든 +쿠버네티스 클러스터에서 작동한다. + +쿠버네티스와 잘 작동하는 클라이언트 프로그램을 작성하기 위한 특정 패턴은 *컨트롤러* 패턴이라고 한다. +컨트롤러는 일반적으로 오브젝트의 `.spec`을 읽고, 가능한 경우 수행한 다음 +오브젝트의 `.status`를 업데이트 한다. + +컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고 +원격 서비스를 호출할 때 이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를 +*웹훅 백엔드* 라고 한다. 컨트롤러와 마찬가지로 웹훅은 장애 지점을 +추가한다. + +웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다. +*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다. +바이너리 플러그인은 kubelet(예: +[Flex Volume 플러그인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)과 +[네트워크 플러그인](/docs/concepts/cluster-administration/network-plugins/))과 +kubectl에서 +사용한다. + +아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을 +보여주는 다이어그램이다. + + + + + + +## 익스텐션 포인트 + +이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다. + + + + + +1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. +2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다. +3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. +4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다. +5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다. +6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다. +7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다. + +어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다. + + + + + + +## API 익스텐션 +### 사용자 정의 유형 + +새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl`과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자. + +애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다. + +커스텀 리소스에 대한 자세한 내용은 [커스텀 리소스 개념 가이드](/docs/concepts/api-extension/custom-resources/)를 참고하길 바란다. + + +### 새로운 API와 자동화의 결합 + +사용자 정의 리소스 API와 컨트롤 루프의 조합을 [오퍼레이터(operator) 패턴](/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은 특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다. + +### 빌트인 리소스 변경 + +사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다. +API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API 접근 익스텐션은 영향을 준다. + + +### API 접근 익스텐션 + +요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다. + +이러한 각 단계는 익스텐션 포인트를 제공한다. + +쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 확인할 수 있다(웹훅). 이러한 방법은 모두 [인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다. + +### 인증 + +[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 요청하는 클라이언트의 사용자 이름에 매핑한다. + +쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 [인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다. + + +### 승인 + +[승인](/docs/reference/access-authn-authz/webhook/)은 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인증 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. + + +### 동적 어드미션 컨트롤 + +요청이 승인된 후, 쓰기 작업인 경우 [어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다. 빌트인 단계 외에도 몇 가지 익스텐션이 있다. + +* [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은 컨테이너에서 실행할 수 있는 이미지를 제한한다. +* 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다. + +## 인프라스트럭처 익스텐션 + + +### 스토리지 플러그인 + +[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 사용하면 +Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써 +빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다. + + +### 장치 플러그인 + +장치 플러그인은 노드가 [장치 플러그인](/docs/concepts/cluster-administration/device-plugins/)을 +통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를 +발견할 수 있게 해준다. + + +### 네트워크 플러그인 + +노드-레벨의 [네트워크 플러그인](/docs/admin/network-plugins/)을 통해 다양한 네트워킹 패브릭을 지원할 수 있다. + +### 스케줄러 익스텐션 + +스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의 +컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서 +기본 스케줄러를 완전히 교체하거나, +[여러 스케줄러](/docs/tasks/administer-cluster/configure-multiple-schedulers/)를 +동시에 실행할 수 있다. + +이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할 +필요가 없다는 것을 알게 된다. + +스케줄러는 또한 웹훅 백엔드(스케줄러 익스텐션)가 +파드에 대해 선택된 노드를 필터링하고 우선 순위를 지정할 수 있도록 하는 +[웹훅](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)을 +지원한다. + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* [커스텀 리소스](/docs/concepts/api-extension/custom-resources/)에 대해 더 알아보기 +* [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기 +* 인프라스트럭처 익스텐션에 대해 더 알아보기 + * [네트워크 플러그인](/docs/concepts/cluster-administration/network-plugins/) + * [장치 플러그인](/docs/concepts/cluster-administration/device-plugins/) +* [kubectl 플러그인](/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기 +* [오퍼레이터 패턴](/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기 + +{{% /capture %}} diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md new file mode 100644 index 0000000000..91c6b4165b --- /dev/null +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -0,0 +1,133 @@ +--- +title: 오퍼레이터(operator) 패턴 +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +오퍼레이터(Operator)는 +[사용자 정의 리소스](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 +사용하여 애플리케이션 및 해당 컴포넌트를 관리하는 쿠버네티스의 소프트웨어 익스텐션이다. 오퍼레이터는 +쿠버네티스 원칙, 특히 [컨트롤 루프](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)를 따른다. + +{{% /capture %}} + + +{{% capture body %}} + +## 동기 부여 + +오퍼레이터 패턴은 서비스 또는 서비스 셋을 관리하는 운영자의 +주요 목표를 포착하는 것을 목표로 한다. 특정 애플리케이션 및 +서비스를 돌보는 운영자는 시스템의 작동 방식, 배포 방법 및 문제가 있는 경우 +대처 방법에 대해 깊이 알고 있다. + +쿠버네티스에서 워크로드를 실행하는 사람들은 종종 반복 가능한 작업을 처리하기 위해 +자동화를 사용하는 것을 좋아한다. 오퍼레이터 패턴은 쿠버네티스 자체가 제공하는 것 이상의 +작업을 자동화하기 위해 코드를 작성하는 방법을 포착한다. + +## 쿠버네티스의 오퍼레이터 + +쿠버네티스는 자동화를 위해 설계되었다. 기본적으로 쿠버네티스의 중추를 통해 많은 +빌트인 자동화 기능을 사용할 수 있다. 쿠버네티스를 사용하여 워크로드 배포 +및 실행을 자동화할 수 있고, *또한* 쿠버네티스가 수행하는 방식을 +자동화할 수 있다. + +쿠버네티스의 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}} +개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 클러스터의 동작을 +확장할 수 있다. +오퍼레이터는 [사용자 정의 리소스](/docs/concepts/api-extension/custom-resources/)의 +컨트롤러 역할을 하는 쿠버네티스 API의 클라이언트이다. + +## 오퍼레이터 예시 {#example} + +오퍼레이터를 사용하여 자동화할 수 있는 몇 가지 사항은 다음과 같다. + +* 주문형 애플리케이션 배포 +* 해당 애플리케이션의 상태를 백업하고 복원 +* 데이터베이스 스키마 또는 추가 구성 설정과 같은 관련 변경 사항에 따른 + 애플리케이션 코드 업그레이드 처리 +* 쿠버네티스 API를 지원하지 않는 애플리케이션에 서비스를 + 게시하여 검색을 지원 +* 클러스터의 전체 또는 일부에서 장애를 시뮬레이션하여 가용성 테스트 +* 내부 멤버 선출 절차없이 분산 애플리케이션의 + 리더를 선택 + +오퍼레이터의 모습을 더 자세하게 볼 수 있는 방법은 무엇인가? 자세한 예는 +다음과 같다. + +1. 클러스터에 구성할 수 있는 SampleDB라는 사용자 정의 리소스. +2. 오퍼레이터의 컨트롤러 부분이 포함된 파드의 실행을 + 보장하는 디플로이먼트. +3. 오퍼레이터 코드의 컨테이너 이미지. +4. 컨트롤 플레인을 쿼리하여 어떤 SampleDB 리소스가 구성되어 있는지 + 알아내는 컨트롤러 코드. +5. 오퍼레이터의 핵심은 API 서버에 구성된 리소스와 현재 상태를 + 일치시키는 방법을 알려주는 코드이다. + * 새 SampleDB를 추가하면 오퍼레이터는 퍼시스턴트볼륨클레임을 + 설정하여 내구성있는 데이터베이스 스토리지, SampleDB를 실행하는 스테이트풀셋 및 + 초기 구성을 처리하는 잡을 제공한다. + * SampleDB를 삭제하면 오퍼레이터는 스냅샷을 생성한 다음 스테이트풀셋과 볼륨도 + 제거되었는지 확인한다. +6. 오퍼레이터는 정기적인 데이터베이스 백업도 관리한다. 오퍼레이터는 각 SampleDB + 리소스에 대해 데이터베이스에 연결하고 백업을 수행할 수 있는 파드를 생성하는 + 시기를 결정한다. 이 파드는 데이터베이스 연결 세부 정보 및 자격 증명이 있는 + 컨피그맵 및 / 또는 시크릿에 의존한다. +7. 오퍼레이터는 관리하는 리소스에 견고한 자동화를 제공하는 것을 목표로 하기 때문에 + 추가 지원 코드가 있다. 이 예제에서 코드는 데이터베이스가 이전 버전을 실행 중인지 + 확인하고, 업그레이드된 경우 이를 업그레이드하는 + 잡 오브젝트를 생성한다. + +## 오퍼레이터 배포 + +오퍼레이터를 배포하는 가장 일반적인 방법은 +커스텀 리소스 데피니션의 정의 및 연관된 컨트롤러를 클러스터에 추가하는 것이다. +컨테이너화된 애플리케이션을 실행하는 것처럼 +컨트롤러는 일반적으로 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} +외부에서 실행된다. +예를 들어 클러스터에서 컨트롤러를 디플로이먼트로 실행할 수 있다. + +## 오퍼레이터 사용 {#using-operators} + +오퍼레이터가 배포되면 오퍼레이터가 사용하는 리소스의 종류를 추가, 수정 또는 +삭제하여 사용한다. 위의 예에 따라 오퍼레이터 자체에 대한 +디플로이먼트를 설정한 후 다음을 수행한다. + +```shell +kubectl get SampleDB # 구성된 데이터베이스 찾기 + +kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하기 +``` + +…이것으로 끝이다! 오퍼레이터는 변경 사항을 적용하고 기존 서비스를 +양호한 상태로 유지한다. + +## 자신만의 오퍼레이터 작성 {#writing-operator} + +에코시스템에 원하는 동작을 구현하는 오퍼레이터가 없다면 직접 코딩할 수 있다. +[다음 내용](#다음-내용)에서는 클라우드 네이티브 오퍼레이터를 작성하는 데 +사용할 수 있는 라이브러리 및 도구에 대한 몇 가지 링크를 +찾을 수 있다. + +또한 [쿠버네티스 API의 클라이언트](/docs/reference/using-api/client-libraries/) +역할을 할 수 있는 모든 언어 / 런타임을 사용하여 오퍼레이터(즉, 컨트롤러)를 구현한다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [사용자 정의 리소스](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기 +* [OperatorHub.io](https://operatorhub.io/)에서 유스케이스에 맞는 이미 만들어진 오퍼레이터 찾기 +* 기존 도구를 사용하여 자신만의 오퍼레이터를 작성해보자. 다음은 예시이다. + * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) 사용하기 + * [kubebuilder](https://book.kubebuilder.io/) 사용하기 + * 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를 + 사용하여 직접 구현하기 + * [오퍼레이터 프레임워크](https://github.com/operator-framework/getting-started) 사용하기 +* 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기 +* 오퍼레이터 패턴을 소개한 [CoreOS 원본 기사](https://coreos.com/blog/introducing-operators.html) 읽기 +* 오퍼레이터 구축을 위한 모범 사례에 대한 구글 클라우드(Google Cloud)의 [기사](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) 읽기 + +{{% /capture %}} + diff --git a/content/ko/docs/concepts/overview/working-with-objects/annotations.md b/content/ko/docs/concepts/overview/working-with-objects/annotations.md index dfac3521d1..4b238bf313 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/ko/docs/concepts/overview/working-with-objects/annotations.md @@ -82,7 +82,7 @@ metadata: spec: containers: - name: nginx - image: nginx:1.7.9 + image: nginx:1.14.2 ports: - containerPort: 80 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 a76972a874..7c9983093b 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -67,7 +67,7 @@ metadata: spec: containers: - name: nginx - image: nginx:1.7.9 + image: nginx:1.14.2 ports: - containerPort: 80 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 069c49d908..3841e76c1e 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/names.md +++ b/content/ko/docs/concepts/overview/working-with-objects/names.md @@ -62,7 +62,7 @@ metadata: spec: containers: - name: nginx - image: nginx:1.7.9 + image: nginx:1.14.2 ports: - containerPort: 80 ``` diff --git a/content/ko/docs/concepts/policy/_index.md b/content/ko/docs/concepts/policy/_index.md new file mode 100644 index 0000000000..ae03c565c1 --- /dev/null +++ b/content/ko/docs/concepts/policy/_index.md @@ -0,0 +1,4 @@ +--- +title: "정책" +weight: 90 +--- diff --git a/content/ko/docs/concepts/policy/limit-range.md b/content/ko/docs/concepts/policy/limit-range.md new file mode 100644 index 0000000000..527acb63ef --- /dev/null +++ b/content/ko/docs/concepts/policy/limit-range.md @@ -0,0 +1,388 @@ +--- +title: 리밋 레인지(Limit Range) +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 [컴퓨팅 리소스](/docs/user-guide/compute-resources)로 실행된다. +리소스 쿼터을 사용하면 클러스터 관리자는 네임스페이스별로 리소스 사용과 생성을 제한할 수 있다. +네임스페이스 내에서 파드나 컨테이너는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있다. 리밋레인지는 네임스페이스에서 리소스 할당(파드 또는 컨테이너)을 제한하는 정책이다. + +{{% /capture %}} + + +{{% capture body %}} + +_리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. + +- 네임스페이스에서 파드 또는 컨테이너별 최소 및 최대 컴퓨팅 리소스 사용량을 지정한다. +- 네임스페이스에서 스토리지클래스별 최소 및 최대 스토리지 요청을 지정한다. +- 네임스페이스에서 리소스에 대한 요청과 제한 사이의 비율을 지정한다. +- 네임스페이스에서 컴퓨팅 리소스에 대한 기본 요청/제한을 설정하고 런타임에 있는 컨테이너에 자동으로 설정한다. + +## 리밋레인지 활성화 + +많은 쿠버네티스 배포판에 리밋레인지 지원이 기본적으로 활성화되어 있다. apiserver `--enable-admission-plugins=` 플래그의 인수 중 하나로 `LimitRanger` 어드미션 컨트롤러가 있는 경우 활성화된다. + +해당 네임스페이스에 리밋레인지 오브젝트가 있는 경우 특정 네임스페이스에 리밋레인지가 지정된다. + +리밋레인지 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야한다. + +### 범위 제한의 개요 + +- 관리자는 하나의 네임스페이스에 하나의 `LimitRange`를 만든다. +- 사용자는 네임스페이스에서 파드, 컨테이너 및 퍼시스턴트볼륨클레임과 같은 리소스를 생성한다. +- `LimitRanger` 어드미션 컨트롤러는 컴퓨팅 리소스 요청 사항을 설정하지 않은 모든 파드와 컨테이너에 대한 기본값과 제한을 지정하고 네임스페이스의 리밋레인지에 정의된 리소스의 최소, 최대 및 비율을 초과하지 않도록 사용량을 추적한다. +- 리밋레인지 제약 조건을 위반하는 리소스(파드, 컨테이너, 퍼시스턴트볼륨클레임)를 생성하거나 업데이트하는 경우 HTTP 상태 코드 `403 FORBIDDEN` 및 위반된 제약 조건을 설명하는 메시지와 함께 API 서버에 대한 요청이 실패한다. +- `cpu`, `memory`와 같은 컴퓨팅 리소스의 네임스페이스에서 리밋레인지가 활성화된 경우 사용자는 해당 값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 시스템에서 파드 생성이 거부될 수 있다. +- 리밋레인지 유효성 검사는 파드 실행 단계가 아닌 파드 어드미션 단계에서만 발생한다. + +범위 제한을 사용하여 생성할 수 있는 정책의 예는 다음과 같다. + +- 용량이 8GiB RAM과 16 코어인 2 노드 클러스터에서 네임스페이스의 파드를 제한하여 CPU의 최대 제한이 500m인 CPU 100m를 요청하고 메모리의 최대 제한이 600M인 메모리 200Mi를 요청하라. +- 스펙에 CPU 및 메모리 요청없이 시작된 컨테이너에 대해 기본 CPU 제한 및 요청을 150m로, 메모리 기본 요청을 300Mi로 정의하라. + +네임스페이스의 총 제한이 파드/컨테이너의 제한 합보다 작은 경우 리소스에 대한 경합이 있을 수 있다. +이 경우 컨테이너 또는 파드가 생성되지 않는다. + +경합이나 리밋레인지 변경은 이미 생성된 리소스에 영향을 미치지 않는다. + +## 컨테이너 컴퓨팅 리소스 제한 + +다음 절에서는 컨테이너 레벨에서 작동하는 리밋레인지 생성에 대해 설명한다. +4개의 컨테이너가 있는 파드가 먼저 생성된다. 파드 내의 각 컨테이너에는 특정 `spec.resource` 구성이 있다. +파드 내의 각 컨테이너는 `LimitRanger` 어드미션 컨트롤러에 의해 다르게 처리된다. + +다음 kubectl 명령을 사용하여 네임스페이스 `limitrange-demo`를 생성한다. + +```shell +kubectl create namespace limitrange-demo +``` + +kubectl 명령에서 네임스페이스 대상인 `limitrange-demo`를 빠트리지 않으려면 다음 명령으로 컨텍스트를 변경한다. + +```shell +kubectl config set-context --current --namespace=limitrange-demo +``` + +다음은 리밋레인지 오브젝트의 구성 파일이다. +{{< codenew file="admin/resource/limit-mem-cpu-container.yaml" >}} + +이 오브젝트는 컨테이너에 적용할 최소 및 최대 CPU/메모리 제한, 기본 CPU/메모리 요청과 CPU/메모리 리소스에 대한 기본 제한을 정의한다. + +다음 kubectl 명령을 사용하여 `limit-mem-cpu-per-container` 리밋레인지를 생성한다. + +```shell +kubectl create -f https://k8s.io/examples/admin/resource/limit-mem-cpu-container.yaml +``` + +```shell +kubectl describe limitrange/limit-mem-cpu-per-container +``` + +```shell +Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio +---- -------- --- --- --------------- ------------- ----------------------- +Container cpu 100m 800m 110m 700m - +Container memory 99Mi 1Gi 111Mi 900Mi - +``` +다음은 4개의 컨테이너가 포함된 파드의 구성 파일로 리밋레인지 기능을 보여준다. +{{< codenew file="admin/resource/limit-range-pod-1.yaml" >}} + +`busybox1` 파드를 생성한다. + +```shell +kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-1.yaml +``` + +### 유효한 CPU/메모리 요청과 제한이 있는 컨테이너 스펙 + +`busybox-cnt01`의 리소스 구성을 보자. + +```shell +kubectl get po/busybox1 -o json | jq ".spec.containers[0].resources" +``` + +```json +{ + "limits": { + "cpu": "500m", + "memory": "200Mi" + }, + "requests": { + "cpu": "100m", + "memory": "100Mi" + } +} +``` + +- `busybox` 파드 내의 `busybox-cnt01` 컨테이너는 `requests.cpu=100m`와 `requests.memory=100Mi`로 정의됐다. +- `100m <= 500m <= 800m`, 컨테이너 CPU 제한(500m)은 승인된 CPU 리밋레인지 내에 있다. +- `99Mi <= 200Mi <= 1Gi`, 컨테이너 메모리 제한(200Mi)은 승인된 메모리 리밋레인지 내에 있다. +- CPU/메모리에 대한 요청/제한 비율 검증이 없으므로 컨테이너가 유효하며 생성되었다. + + +### 유효한 CPU/메모리 요청은 있지만 제한이 없는 컨테이너 스펙 + +`busybox-cnt02`의 리소스 구성을 보자. + +```shell +kubectl get po/busybox1 -o json | jq ".spec.containers[1].resources" +``` + +```json +{ + "limits": { + "cpu": "700m", + "memory": "900Mi" + }, + "requests": { + "cpu": "100m", + "memory": "100Mi" + } +} +``` +- `busybox1` 파드 내의 `busybox-cnt02` 컨테이너는 `requests.cpu=100m`와 `requests.memory=100Mi`를 정의했지만 CPU와 메모리에 대한 제한은 없다. +- 컨테이너에 제한 섹션이 없다. `limit-mem-cpu-per-container` 리밋레인지 오브젝트에 정의된 기본 제한은 `limits.cpu=700mi` 및 `limits.memory=900Mi`로 이 컨테이너에 설정된다. +- `100m <= 700m <= 800m`, 컨테이너 CPU 제한(700m)이 승인된 CPU 제한 범위 내에 있다. +- `99Mi <= 900Mi <= 1Gi`, 컨테이너 메모리 제한(900Mi)이 승인된 메모리 제한 범위 내에 있다. +- 요청/제한 비율이 설정되지 않았으므로 컨테이너가 유효하며 생성되었다. + +### 유효한 CPU/메모리 제한은 있지만 요청은 없는 컨테이너 스펙 + +`busybox-cnt03`의 리소스 구성을 보자. + +```shell +kubectl get po/busybox1 -o json | jq ".spec.containers[2].resources" +``` +```json +{ + "limits": { + "cpu": "500m", + "memory": "200Mi" + }, + "requests": { + "cpu": "500m", + "memory": "200Mi" + } +} +``` + +- `busybox1` 파드 내의 `busybox-cnt03` 컨테이너는 `limits.cpu=500m`와 `limits.memory=200Mi`를 정의했지만 CPU와 메모리에 대한 요청은 없다. +- 컨테이너에 요청 섹션이 정의되지 않았다. `limit-mem-cpu-per-container` 리밋레인지에 정의된 기본 요청은 제한 섹션을 채우는 데 사용되지 않지만 컨테이너에 의해 정의된 제한은 `limits.cpu=500m` 및 `limits.memory=200Mi`로 설정된다. +- `100m <= 500m <= 800m`, 컨테이너 CPU 제한(500m)은 승인된 CPU 제한 범위 내에 있다. +- `99Mi <= 200Mi <= 1Gi`, 컨테이너 메모리 제한(200Mi)은 승인된 메모리 제한 범위 내에 있다. +- 요청/제한 비율이 설정되지 않았으므로 컨테이너가 유효하며 생성되었다. + +### CPU/메모리 요청/제한이 없는 컨테이너 스펙 + +`busybox-cnt04`의 리소스 구성을 보자. + +```shell +kubectl get po/busybox1 -o json | jq ".spec.containers[3].resources" +``` + +```json +{ + "limits": { + "cpu": "700m", + "memory": "900Mi" + }, + "requests": { + "cpu": "110m", + "memory": "111Mi" + } +} +``` + +- `busybox1`의 `busybox-cnt04` 컨테이너는 제한이나 요청을 정의하지 않았다. +- 컨테이너는 제한 섹션을 정의하지 않으며 `limit-mem-cpu-per-container` 리밋레인지에 정의된 기본 제한은 `limit.cpu=700m` 및 `limits.memory=900Mi`로 설정된다. +- 컨테이너는 요청 섹션을 정의하지 않으며 `limit-mem-cpu-per-container` 리밋레인지에 정의된 defaultRequest는 `requests.cpu=110m` 및 `requests.memory=111Mi`로 설정된다. +- `100m <= 700m <= 800m`, 컨테이너 CPU 제한(700m)은 승인된 CPU 제한 범위 내에 있다. +- `99Mi <= 900Mi <= 1Gi`, 컨테이너 메모리 제한(900Mi)은 승인된 메모리 제한 범위 내에 있다. +- 요청/제한 비율이 설정되지 않았으므로 컨테이너가 유효하며 생성되었다. + +`busybox` 파드에 정의된 모든 컨테이너는 리밋레인지 유효성 검사를 통과했으므로 이 파드는 유효하며 네임스페이스에서 생성된다. + +## 파드 컴퓨팅 리소스 제한 + +다음 절에서는 파드 레벨에서 리소스를 제한하는 방법에 대해 설명한다. + +{{< codenew file="admin/resource/limit-mem-cpu-pod.yaml" >}} + +`busybox1` 파드를 삭제하지 않고 `limitrange-demo` 네임스페이스에 `limit-mem-cpu-pod` 리밋레인지를 생성한다. + +```shell +kubectl apply -f https://k8s.io/examples/admin/resource/limit-mem-cpu-pod.yaml +``` +리밋레인지가 생성되고 파드별로 CPU가 2 코어로, 메모리가 2Gi로 제한된다. + +```shell +limitrange/limit-mem-cpu-per-pod created +``` + +다음 kubectl 명령을 사용하여 `limit-mem-cpu-per-pod` 리밋레인지 오브젝트의 정보를 나타낸다. + +```shell +kubectl describe limitrange/limit-mem-cpu-per-pod +``` + +```shell +Name: limit-mem-cpu-per-pod +Namespace: limitrange-demo +Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio +---- -------- --- --- --------------- ------------- ----------------------- +Pod cpu - 2 - - - +Pod memory - 2Gi - - - +``` + +이제 `busybox2` 파드를 생성한다. + +{{< codenew file="admin/resource/limit-range-pod-2.yaml" >}} + +```shell +kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-2.yaml +``` + +`busybox2` 파드 정의는 `busybox1`과 동일하지만 이제 파드 리소스가 제한되어 있으므로 오류가 보고된다. + +```shell +Error from server (Forbidden): error when creating "limit-range-pod-2.yaml": pods "busybox2" is forbidden: [maximum cpu usage per Pod is 2, but limit is 2400m., maximum memory usage per Pod is 2Gi, but limit is 2306867200.] +``` + +```shell +kubectl get po/busybox1 -o json | jq ".spec.containers[].resources.limits.memory" +"200Mi" +"900Mi" +"200Mi" +"900Mi" +``` + +해당 컨테이너의 총 메모리 제한이 리밋레인지에 정의된 제한보다 크므로 `busybox2` 파드는 클러스터에서 허용되지 않는다. +`busyRange1`은 리밋레인지를 생성하기 전에 클러스터에서 생성되고 허용되므로 제거되지 않는다. + +## 스토리지 리소스 제한 + +리밋레인지를 사용하여 네임스페이스에서 각 퍼시스턴트볼륨클레임이 요청할 수 있는 [스토리지 리소스](/ko/docs/concepts/storage/persistent-volumes/)의 최소 및 최대 크기를 지정할 수 있다. + +{{< codenew file="admin/resource/storagelimits.yaml" >}} + +`kubectl create`를 사용하여 YAML을 적용한다. + +```shell +kubectl create -f https://k8s.io/examples/admin/resource/storagelimits.yaml +``` + +```shell +limitrange/storagelimits created +``` + +생성된 오브젝트의 정보를 나타낸다. + +```shell +kubectl describe limits/storagelimits +``` + +출력은 다음과 같다. + +```shell +Name: storagelimits +Namespace: limitrange-demo +Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio +---- -------- --- --- --------------- ------------- ----------------------- +PersistentVolumeClaim storage 1Gi 2Gi - - - +``` + +{{< codenew file="admin/resource/pvc-limit-lower.yaml" >}} + +```shell +kubectl create -f https://k8s.io/examples/admin/resource/pvc-limit-lower.yaml +``` + +`requests.storage`가 리밋레인지의 Min 값보다 낮은 PVC를 만드는 동안 서버에서 발생하는 오류는 다음과 같다. + +```shell +Error from server (Forbidden): error when creating "pvc-limit-lower.yaml": persistentvolumeclaims "pvc-limit-lower" is forbidden: minimum storage usage per PersistentVolumeClaim is 1Gi, but request is 500Mi. +``` + +`requests.storage`가 리밋레인지의 Max 값보다 큰 경우에도 동일한 동작이 나타난다. + +{{< codenew file="admin/resource/pvc-limit-greater.yaml" >}} + +```shell +kubectl create -f https://k8s.io/examples/admin/resource/pvc-limit-greater.yaml +``` + +```shell +Error from server (Forbidden): error when creating "pvc-limit-greater.yaml": persistentvolumeclaims "pvc-limit-greater" is forbidden: maximum storage usage per PersistentVolumeClaim is 2Gi, but request is 5Gi. +``` + +## 제한/요청 비율 + +`LimitRangeSpec`에 `LimitRangeItem.maxLimitRequestRatio`가 지정되어 있으면 명명된 리소스는 제한을 요청으로 나눈 값이 열거된 값보다 작거나 같은 0이 아닌 값을 요청과 제한 모두 가져야 한다. + +다음의 리밋레인지는 메모리 제한이 네임스페이스의 모든 파드에 대한 메모리 요청 양의 최대 두 배가 되도록 한다. + +{{< codenew file="admin/resource/limit-memory-ratio-pod.yaml" >}} + +```shell +kubectl apply -f https://k8s.io/examples/admin/resource/limit-memory-ratio-pod.yaml +``` + +다음의 kubectl 명령으로 `limit-memory-ratio-pod` 리밋레인지의 정보를 나타낸다. + +```shell +kubectl describe limitrange/limit-memory-ratio-pod +``` + +```shell +Name: limit-memory-ratio-pod +Namespace: limitrange-demo +Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio +---- -------- --- --- --------------- ------------- ----------------------- +Pod memory - - - - 2 +``` + + +`requests.memory=100Mi` 및 `limits.memory=300Mi`로 파드를 생성한다. + +{{< codenew file="admin/resource/limit-range-pod-3.yaml" >}} + +```shell +kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-3.yaml +``` + +위 예에서 제한/요청 비율(`3`)이 `limit-memory-ratio-pod` 리밋레인지에 지정된 제한 비율(`2`)보다 커서 파드 생성에 실패했다. + +``` +Error from server (Forbidden): error when creating "limit-range-pod-3.yaml": pods "busybox3" is forbidden: memory max limit to request ratio per Pod is 2, but provided ratio is 3.000000. +``` + +## 정리 + +모든 리소스를 해제하려면 `limitrange-demo` 네임스페이스를 삭제한다. + +```shell +kubectl delete ns limitrange-demo +``` +다음 명령을 사용하여 컨텍스트를 `default` 네임스페이스로 변경한다. + +```shell +kubectl config set-context --current --namespace=default +``` + +## 예제 + +- [네임스페이스별 컴퓨팅 리소스를 제한하는 방법에 대한 튜토리얼](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)을 참고하길 바란다. +- [스토리지 사용을 제한하는 방법](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)을 확인하라. +- [네임스페이스별 쿼터에 대한 자세한 예](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)를 참고하길 바란다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +보다 자세한 내용은 [LimitRanger 설계 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)를 참고하길 바란다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md new file mode 100644 index 0000000000..13d363aa39 --- /dev/null +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -0,0 +1,635 @@ +--- +title: 파드 시큐리티 폴리시 +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +{{< feature-state state="beta" >}} + +파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을 +부여할 수 있다. + +{{% /capture %}} + + +{{% capture body %}} + +## 파드 시큐리티 폴리시란? + +_Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 ​​클러스터-레벨의 +리소스이다. [파드시큐리티폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 오브젝트는 +관련 필드에 대한 기본값뿐만 아니라 시스템에 적용하기 위해 파드가 실행해야만 하는 +조건 셋을 정의한다. 관리자는 +다음을 제어할 수 있다. + +| 제어 측면 | 필드 이름 | +| ----------------------------------------------------| ------------------------------------------- | +| 특권을 가진(privileged) 컨테이너의 실행 | [`privileged`](#privileged) | +| 호스트 네임스페이스의 사용 | [`hostPID`, `hostIPC`](#host-namespaces) | +| 호스트 네트워킹과 포트의 사용 | [`hostNetwork`, `hostPorts`](#host-namespaces) | +| 볼륨 유형의 사용 | [`volumes`](#volumes-and-file-systems) | +| 호스트 파일시스템의 사용 | [`allowedHostPaths`](#volumes-and-file-systems) | +| FlexVolume 드라이버의 화이트리스트 | [`allowedFlexVolumes`](#flexvolume-drivers) | +| 파드 볼륨을 소유한 FSGroup 할당 | [`fsGroup`](#volumes-and-file-systems) | +| 읽기 전용 루트 파일시스템 사용 필요 | [`readOnlyRootFilesystem`](#volumes-and-file-systems) | +| 컨테이너의 사용자 및 그룹 ID | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#users-and-groups) | +| 루트 특권으로의 에스컬레이션 제한 | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#privilege-escalation) | +| 리눅스 기능 | [`defaultAddCapabilities`, `requiredDropCapabilities`, `allowedCapabilities`](#capabilities) | +| 컨테이너의 SELinux 컨텍스트 | [`seLinux`](#selinux) | +| 컨테이너에 허용된 Proc 마운트 유형 | [`allowedProcMountTypes`](#allowedprocmounttypes) | +| 컨테이너가 사용하는 AppArmor 프로파일 | [어노테이션](#apparmor) | +| 컨테이너가 사용하는 seccomp 프로파일 | [어노테이션](#seccomp) | +| 컨테이너가 사용하는 sysctl 프로파일 | [`forbiddenSysctls`,`allowedUnsafeSysctls`](#sysctl) | + + +## 파드 시큐리티 폴리시 활성화 + +파드 시큐리티 폴리시 제어는 선택 사항(하지만 권장함)인 +[어드미션 +컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)로 +구현된다. [어드미션 컨트롤러 활성화](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)하면 +파드시큐리티폴리시가 적용되지만, +정책을 승인하지 않고 활성화하면 클러스터에 +**파드가 생성되지 않는다.** + +파드 시큐리티 폴리시 API(`policy/v1beta1/podsecuritypolicy`)는 +어드미션 컨트롤러와 독립적으로 활성화되므로 기존 클러스터의 경우 +어드미션 컨트롤러를 활성화하기 전에 정책을 추가하고 권한을 +부여하는 것이 좋다. + +## 정책 승인 + +파드시큐리티폴리시 리소스가 생성되면 아무 것도 수행하지 않는다. 이를 사용하려면 +요청 사용자 또는 대상 파드의 +[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/)는 +정책에서 `use` 동사를 허용하여 정책을 사용할 권한이 있어야 한다. + +대부분의 쿠버네티스 파드는 사용자가 직접 만들지 않는다. 대신 일반적으로 +컨트롤러 관리자를 통해 +[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/), +[레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/), 또는 기타 +템플릿 컨트롤러의 일부로 간접적으로 생성된다. 컨트롤러에 정책에 대한 접근 권한을 부여하면 +해당 컨트롤러에 의해 생성된 *모든* 파드에 대한 접근 권한이 부여되므로 정책을 승인하는 +기본 방법은 파드의 서비스 어카운트에 대한 접근 권한을 +부여하는 것이다([예](#다른-파드를-실행) 참고). + +### RBAC을 통한 방법 + +[RBAC](/docs/reference/access-authn-authz/rbac/)은 표준 쿠버네티스 권한 부여 모드이며, +정책 사용 권한을 부여하는 데 쉽게 사용할 수 있다. + +먼저, `Role` 또는 `ClusterRole`은 원하는 정책을 `use` 하려면 접근 권한을 부여해야 한다. +접근 권한을 부여하는 규칙은 다음과 같다. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: +rules: +- apiGroups: ['policy'] + resources: ['podsecuritypolicies'] + verbs: ['use'] + resourceNames: + - +``` + +그런 다음 `(Cluster)Role`이 승인된 사용자에게 바인딩된다. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: +roleRef: + kind: ClusterRole + name: + apiGroup: rbac.authorization.k8s.io +subjects: +# Authorize specific service accounts: +- kind: ServiceAccount + name: + namespace: +# Authorize specific users (not recommended): +- kind: User + apiGroup: rbac.authorization.k8s.io + name: +``` + +`RoleBinding`(`ClusterRoleBinding` 아님)을 사용하는 경우, 바인딩과 동일한 네임스페이스에서 +실행되는 파드에 대해서만 사용 권한을 부여한다. 네임스페이스에서 실행되는 모든 파드에 접근 권한을 +부여하기 위해 시스템 그룹과 쌍을 이룰 수 있다. +```yaml +# Authorize all service accounts in a namespace: +- kind: Group + apiGroup: rbac.authorization.k8s.io + name: system:serviceaccounts +# Or equivalently, all authenticated users in a namespace: +- kind: Group + apiGroup: rbac.authorization.k8s.io + name: system:authenticated +``` + +RBAC 바인딩에 대한 자세한 예는, +[역할 바인딩 예제](/docs/reference/access-authn-authz/rbac#role-binding-examples)를 참고하길 바란다. +파드시큐리티폴리시 인증에 대한 전체 예제는 +[아래](#예제)를 참고하길 바란다. + + +### 문제 해결 + +- [컨트롤러 관리자](/docs/admin/kube-controller-manager/)는 +[보안 API 포트](/docs/reference/access-authn-authz/controlling-access/)에 대해 실행해야 하며, +슈퍼유저 권한이 없어야 한다. 그렇지 않으면 요청이 인증 및 권한 부여 모듈을 우회하고, +모든 파드시큐리티폴리시 오브젝트가 허용되며 +사용자는 특권있는 컨테이너를 만들 수 있다. 컨트롤러 관리자 권한 구성에 대한 자세한 +내용은 [컨트롤러 역할](/docs/reference/access-authn-authz/rbac/#controller-roles)을 +참고하길 바란다. + +## 정책 순서 + +파드 생성 및 업데이트를 제한할 뿐만 아니라 파드 시큐리티 폴리시를 사용하여 +제어하는 ​​많은 필드에 기본값을 제공할 수도 있다. 여러 정책을 +사용할 수 있는 경우 파드 시큐리티 폴리시 컨트롤러는 +다음 기준에 따라 정책을 선택한다. + +1. 기본 설정을 변경하거나 파드를 변경하지 않고 파드를 있는 그대로 허용하는 파드시큐리티폴리시가 + 선호된다. 이러한 비-변이(non-mutating) 파드시큐리티폴리시의 + 순서는 중요하지 않다. +2. 파드를 기본값으로 설정하거나 변경해야 하는 경우, 파드를 허용할 첫 번째 파드시큐리티폴리시 + (이름순)가 선택된다. + +{{< note >}} +업데이트 작업 중(파드 스펙에 대한 변경이 허용되지 않는 동안) 비-변이 파드시큐리티폴리시만 +파드의 유효성을 검사하는 데 사용된다. +{{< /note >}} + +## 예제 + +_이 예에서는 파드시큐리티폴리시 어드미션 컨트롤러가 활성화된 클러스터가 실행 중이고 +클러스터 관리자 권한이 있다고 가정한다._ + +### 설정 + +이 예제와 같이 네임스페이스와 서비스 어카운트를 설정한다. +이 서비스 어카운트를 사용하여 관리자가 아닌 사용자를 조정한다. + +```shell +kubectl create namespace psp-example +kubectl create serviceaccount -n psp-example fake-user +kubectl create rolebinding -n psp-example fake-editor --clusterrole=edit --serviceaccount=psp-example:fake-user +``` + +어떤 사용자로 활동하고 있는지 명확하게 하고 입력 내용을 저장하려면 2개의 별칭(alias)을 +만든다. + +```shell +alias kubectl-admin='kubectl -n psp-example' +alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n psp-example' +``` + +### 정책과 파드 생성 + +파일에서 예제 파드시큐리티폴리시 오브젝트를 정의한다. 이는 특권있는 파드를 +만들지 못하게 하는 정책이다. +파드시큐리티폴리시 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다. + +{{< codenew file="policy/example-psp.yaml" >}} + +그리고 kubectl로 생성한다. + +```shell +kubectl-admin create -f example-psp.yaml +``` + +이제 권한이 없는 사용자로서 간단한 파드를 생성해보자. + +```shell +kubectl-user create -f- <}} +이 방법은 권장하지 않는다! 선호하는 방법은 [다음 절](#다른-파드를-실행)을 +참고하길 바란다. +{{< /note >}} + +```shell +kubectl-admin create role psp:unprivileged \ + --verb=use \ + --resource=podsecuritypolicy \ + --resource-name=example +role "psp:unprivileged" created + +kubectl-admin create rolebinding fake-user:psp:unprivileged \ + --role=psp:unprivileged \ + --serviceaccount=psp-example:fake-user +rolebinding "fake-user:psp:unprivileged" created + +kubectl-user auth can-i use podsecuritypolicy/example +yes +``` + +이제 파드 생성을 다시 시도하자. + +```shell +kubectl-user create -f- <}} + +다음은 권한이 없는 사용자로서의 실행을 필요로 하고, 루트로의 에스컬레이션(escalation) 가능성을 차단하고, +여러 보안 메커니즘을 사용을 필요로 하는 제한적 +정책의 예제이다. + +{{< codenew file="policy/restricted-psp.yaml" >}} + +## 정책 레퍼런스 + +### 특권을 가진 + +**Privileged** - 파드의 컨테이너가 특권 모드를 사용할 수 있는지 여부를 결정한다. +기본적으로 컨테이너는 호스트의 모든 장치에 접근할 수 없지만 +"특권을 가진" 컨테이너는 호스트의 모든 장치에 접근할 수 있다. 이것은 +컨테이너가 호스트에서 실행되는 프로세스와 거의 동일한 접근을 허용한다. +이것은 네트워크 스택 조작 및 장치 접근과 같은 +리눅스 기능을 사용하려는 컨테이너에 유용하다. + +### 호스트 네임스페이스 + +**HostPID** - 파드 컨테이너가 호스트 프로세스 ID 네임스페이스를 공유할 수 있는지 여부를 +제어한다. ptrace와 함께 사용하면 컨테이너 외부로 권한을 에스컬레이션하는 데 사용할 수 +있다(ptrace는 기본적으로 금지되어 있음). + +**HostIPC** - 파드 컨테이너가 호스트 IPC 네임스페이스를 공유할 수 있는지 여부를 +제어한다. + +**HostNetwork** - 파드가 노드 네트워크 네임스페이스를 사용할 수 있는지 여부를 제어한다. +이렇게 하면 파드에 루프백 장치에 접근 권한을 주고, 서비스는 로컬호스트(localhost)를 리스닝할 수 있으며, +동일한 노드에 있는 다른 파드의 네트워크 활동을 스누핑(snoop)하는 데 +사용할 수 있다. + +**HostPorts** - 호스트 네트워크 네임스페이스에 허용되는 포트 범위의 화이트리스트(whitelist)를 +제공한다. `min`과 `max`를 포함하여 `HostPortRange`의 목록으로 정의된다. +기본값은 허용하는 호스트 포트 없음(no allowed host ports)이다. + +### 볼륨 및 파일시스템 + +**Volumes** - 허용되는 볼륨 유형의 화이트리스트를 제공한다. 허용 가능한 값은 +볼륨을 생성할 때 정의된 볼륨 소스에 따른다. 볼륨 유형의 전체 목록은 +[볼륨 유형들](/ko/docs/concepts/storage/volumes/#볼륨-유형들)에서 참고한다. +또한 `*`를 사용하여 모든 볼륨 유형을 +허용할 수 있다. + +새 PSP에 허용되는 볼륨의 **최소 권장 셋** 은 다음과 같다. + +- 컨피그맵 +- 다운워드API +- emptyDir +- 퍼시스턴트볼륨클레임 +- 시크릿 +- 프로젝티드(projected) + +{{< warning >}} +파드시큐리티폴리시는 `PersistentVolumeClaim`이 참조할 수 있는 `PersistentVolume` +오브젝트의 유형을 제한하지 않으며 hostPath 유형 +`PersistentVolumes`은 읽기-전용 접근 모드를 지원하지 않는다. 신뢰할 수 있는 사용자만 +`PersistentVolume` 오브젝트를 생성할 수 있는 권한을 부여 받아야 한다. +{{< /warning >}} + +**FSGroup** - 일부 볼륨에 적용되는 보충 그룹(supplemental group)을 제어한다. + +- *MustRunAs* - 하나 이상의 `range`를 지정해야 한다. 첫 번째 범위의 최솟값을 +기본값으로 사용한다. 모든 범위에 대해 검증한다. +- *MayRunAs* - 하나 이상의 `range`를 지정해야 한다. 기본값을 제공하지 않고 +`FSGroups`을 설정하지 않은 상태로 둘 수 있다. `FSGroups`이 설정된 경우 모든 범위에 대해 +유효성을 검사한다. +- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `fsGroup` ID의 지정도 허용한다. + +**AllowedHostPaths** - hostPath 볼륨에서 사용할 수 있는 호스트 경로의 화이트리스트를 +지정한다. 빈 목록은 사용되는 호스트 경로에 제한이 없음을 의미한다. +이는 단일 `pathPrefix` 필드가 있는 오브젝트 목록으로 정의되며, hostPath 볼륨은 +허용된 접두사로 시작하는 경로를 마운트할 수 있으며 `readOnly` 필드는 +읽기-전용으로 마운트 되어야 함을 나타낸다. +예를 들면 다음과 같습니다. + +```yaml +allowedHostPaths: + # 이 정책은 "/foo", "/foo/", "/foo/bar" 등을 허용하지만, + # "/fool", "/etc/foo" 등은 허용하지 않는다. + # "/foo/../" 는 절대 유효하지 않다. + - pathPrefix: "/foo" + readOnly: true # 읽기 전용 마운트만 허용 +``` + +{{< warning >}}호스트 파일시스템에 제한없는 접근을 부여하며, 컨테이너가 특권을 에스컬레이션 +(다른 컨테이너들에 있는 데이터를 읽고, 시스템 서비스의 자격 증명을 어뷰징(abusing)하는 등)할 +수 있도록 만드는 다양한 방법이 있다. 예를 들면, Kubelet과 같다. + +쓰기 가능한 hostPath 디렉토리 볼륨을 사용하면, 컨테이너가 `pathPrefix` 외부의 +호스트 파일시스템에 대한 통행을 허용하는 방식으로 컨테이너의 파일시스템 쓰기(write)를 허용한다. +쿠버네티스 1.11 이상 버전에서 사용 가능한 `readOnly: true`는 지정된 `pathPrefix`에 대한 +접근을 효과적으로 제한하기 위해 **모든** `allowedHostPaths`에서 사용해야 한다. +{{< /warning >}} + +**ReadOnlyRootFilesystem** - 컨테이너는 읽기-전용 루트 파일시스템(즉, 쓰기 가능한 레이어 없음)으로 +실행해야 한다. + +### FlexVolume 드라이버 + +flexvolume에서 사용할 수 있는 FlexVolume 드라이버의 화이트리스트를 지정한다. +빈 목록 또는 nil은 드라이버에 제한이 없음을 의미한다. +[`volumes`](#볼륨-및-파일시스템) 필드에 `flexVolume` 볼륨 유형이 포함되어 +있는지 확인한다. 그렇지 않으면 FlexVolume 드라이버가 허용되지 않는다. + +예를 들면 다음과 같다. + +```yaml +apiVersion: policy/v1beta1 +kind: PodSecurityPolicy +metadata: + name: allow-flex-volumes +spec: + # ... 다른 스펙 필드 + volumes: + - flexVolume + allowedFlexVolumes: + - driver: example/lvm + - driver: example/cifs +``` + +### 사용자 및 그룹 + +**RunAsUser** - 컨테이너를 실행할 사용자 ID를 제어힌다. + +- *MustRunAs* - 하나 이상의 `range`를 지정해야 한다. 첫 번째 범위의 최솟값을 +기본값으로 사용한다. 모든 범위에 대해 검증한다. +- *MustRunAsNonRoot* - 파드가 0이 아닌 `runAsUser`로 제출되거나 +이미지에 `USER` 지시문이 정의되어 있어야 한다(숫자 UID 사용). `runAsNonRoot` 또는 +`runAsUser` 설정을 지정하지 않은 파드는 `runAsNonRoot=true`를 설정하도록 +변경되므로 컨테이너에 0이 아닌 숫자가 정의된 `USER` 지시문이 +필요하다. 기본값은 제공되지 않는다. +이 전략에서는 `allowPrivilegeEscalation=false`를 설정하는 것이 좋다. +- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `runAsUser`의 지정도 허용한다. + +**RunAsGroup** - 컨테이너가 실행될 기본 그룹 ID를 제어한다. + +- *MustRunAs* - 하나 이상의 `range`를 지정해야 한다. 첫 번째 범위의 최솟값을 +기본값으로 사용한다. 모든 범위에 대해 검증한다. +- *MayRunAs* - `RunAsGroup`을 지정할 필요가 없다. 그러나 `RunAsGroup`을 지정하면 +정의된 범위에 속해야 한다. +- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `runAsGroup`의 지정도 허용한다. + + +**SupplementalGroups** - 컨테이너가 추가할 그룹 ID를 제어한다. + +- *MustRunAs* - 하나 이상의 `range`를 지정해야 한다. 첫 번째 범위의 최솟값을 +기본값으로 사용한다. 모든 범위에 대해 검증한다. +- *MayRunAs* - 하나 이상의 `range`를 지정해야 한다. `supplementalGroups`에 +기본값을 제공하지 않고 설정하지 않은 상태로 둘 수 있다. +`supplementalGroups`가 설정된 경우 모든 범위에 대해 유효성을 검증한다. +- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `supplementalGroups`의 지정도 +허용한다. + +### 권한 에스컬레이션 + +이 옵션은 `allowPrivilegeEscalation` 컨테이너 옵션을 제어한다. 이 bool은 +컨테이너 프로세스에서 +[`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) +플래그가 설정되는지 여부를 직접 제어한다. 이 플래그는 `setuid` 바이너리가 +유효 사용자 ID를 변경하지 못하게 하고 파일에 추가 기능을 활성화하지 못하게 +한다(예: `ping` 도구 사용을 못하게 함). `MustRunAsNonRoot`를 효과적으로 +강제하려면 이 동작이 필요하다. + +**AllowPrivilegeEscalation** - 사용자가 컨테이너의 보안 컨텍스트를 +`allowPrivilegeEscalation=true`로 설정할 수 있는지 여부를 게이트한다. +이 기본값은 setuid 바이너리를 중단하지 않도록 허용한다. 이를 `false`로 설정하면 +컨테이너의 하위 프로세스가 상위 프로세스보다 더 많은 권한을 얻을 수 없다. + +**DefaultAllowPrivilegeEscalation** - `allowPrivilegeEscalation` 옵션의 +기본값을 설정한다. 이것이 없는 기본 동작은 setuid 바이너리를 중단하지 않도록 +권한 에스컬레이션을 허용하는 것이다. 해당 동작이 필요하지 않은 경우 이 필드를 사용하여 +기본적으로 허용하지 않도록 설정할 수 있지만 파드는 여전히 `allowPrivilegeEscalation`을 +명시적으로 요청할 수 있다. + +### 기능 + +리눅스 기능은 전통적으로 슈퍼유저와 관련된 권한을 보다 세밀하게 분류한다. +이러한 기능 중 일부는 권한 에스컬레이션 또는 컨테이너 분류에 사용될 수 있으며 +파드시큐리티폴리시에 의해 제한될 수 있다. 리눅스 기능에 대한 자세한 내용은 +[기능(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html)을 +참고하길 바란다. + +다음 필드는 대문자로 표기된 기능 이름 목록을 +`CAP_` 접두사 없이 가져온다. + +**AllowedCapabilities** - 컨테이너에 추가될 수 있는 기능의 화이트리스트를 +제공한다. 기본적인 기능 셋은 암시적으로 허용된다. 비어있는 셋은 +기본 셋을 넘어서는 추가 기능이 추가되지 않는 것을 +의미한다. `*`는 모든 기능을 허용하는 데 사용할 수 있다. + +**RequiredDropCapabilities** - 컨테이너에서 삭제해야 하는 기능이다. +이러한 기능은 기본 셋에서 제거되며 추가해서는 안된다. +`RequiredDropCapabilities`에 나열된 기능은 `AllowedCapabilities` 또는 +`DefaultAddCapabilities`에 포함되지 않아야 한다. + +**DefaultAddCapabilities** - 런타임 기본값 외에 기본적으로 컨테이너에 추가되는 기능이다. +도커 런타임을 사용할 때 기본 기능 목록은 +[도커 문서](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)를 +참고하길 바란다. + +### SELinux + +- *MustRunAs* - `seLinuxOptions`을 구성해야 한다. +`seLinuxOptions`을 기본값으로 사용한다. `seLinuxOptions`에 대해 유효성을 검사한다. +- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `seLinuxOptions`의 지정도 +허용한다. + +### AllowedProcMountTypes + +`allowedProcMountTypes`는 허용된 ProcMountTypes의 화이트리스트이다. +비어 있거나 nil은 `DefaultProcMountType`만 사용할 수 있음을 나타낸다. + +`DefaultProcMount`는 /proc의 읽기 전용 및 마스킹(masking)된 경로에 컨테이너 런타임 +기본값을 사용한다. 대부분의 컨테이너 런타임은 특수 장치나 정보가 실수로 보안에 +노출되지 않도록 /proc의 특정 경로를 마스킹한다. 이것은 문자열 +`Default`로 표시된다. + +유일하게 다른 ProcMountType은 `UnmaskedProcMount`로, 컨테이너 런타임의 +기본 마스킹 동작을 무시하고 새로 작성된 /proc 컨테이너가 수정없이 +그대로 유지되도록 한다. 이 문자열은 +`Unmasked`로 표시된다. + +### AppArmor + +파드시큐리티폴리시의 어노테이션을 통해 제어된다. [AppArmor +문서](/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations)를 참고하길 바란다. + +### Seccomp + +파드에서 seccomp 프로파일의 사용은 파드시큐리티폴리시의 어노테이션을 통해 +제어할 수 있다. Seccomp는 쿠버네티스의 알파 기능이다. + +**seccomp.security.alpha.kubernetes.io/defaultProfileName** - 컨테이너에 +적용할 기본 seccomp 프로파일을 지정하는 어노테이션이다. 가능한 값은 +다음과 같다. + +- `unconfined` - 대안이 제공되지 않으면 Seccomp가 컨테이너 프로세스에 적용되지 + 않는다(쿠버네티스의 기본값임). +- `runtime/default` - 기본 컨테이너 런타임 프로파일이 사용된다. +- `docker/default` - 도커 기본 seccomp 프로파일이 사용된다. 쿠버네티스 1.11 부터 사용 중단(deprecated) + 되었다. 대신 `runtime/default` 사용을 권장한다. +- `localhost/` - `/`에 있는 노드에서 파일을 프로파일로 + 지정한다. 여기서 ``는 Kubelet의 `--seccomp-profile-root` 플래그를 + 통해 정의된다. + +**seccomp.security.alpha.kubernetes.io/allowedProfileNames** - 파드 seccomp +어노테이션에 허용되는 값을 지정하는 어노테이션. 쉼표로 구분된 +허용된 값의 목록으로 지정된다. 가능한 값은 위에 나열된 값과 +모든 프로파일을 허용하는 `*` 이다. +이 주석이 없으면 기본값을 변경할 수 없다. + +### Sysctl + +기본적으로 모든 안전한 sysctls가 허용된다. + +- `forbiddenSysctls` - 특정 sysctls를 제외한다. 목록에서 안전한 것과 안전하지 않은 sysctls의 조합을 금지할 수 있다. 모든 sysctls 설정을 금지하려면 자체적으로 `*`를 사용한다. +- `allowedUnsafeSysctls` - `forbiddenSysctls`에 나열되지 않는 한 기본 목록에서 허용하지 않은 특정 sysctls를 허용한다. + +[Sysctl 문서]( +/docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy)를 참고하길 바란다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조 + +{{% /capture %}} diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md new file mode 100644 index 0000000000..d86685d986 --- /dev/null +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -0,0 +1,600 @@ +--- +title: 리소스 쿼터 +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +여러 사용자나 팀이 정해진 수의 노드로 클러스터를 공유할 때 +한 팀이 공정하게 분배된 리소스보다 많은 리소스를 사용할 수 있다는 우려가 있다. + +리소스 쿼터는 관리자가 이 문제를 해결하기 위한 도구이다. + +{{% /capture %}} + + +{{% capture body %}} + +`ResourceQuota` 오브젝트로 정의된 리소스 쿼터는 네임스페이스별 총 리소스 사용을 제한하는 +제약 조건을 제공한다. 유형별로 네임스페이스에서 만들 수 있는 오브젝트 수와 +해당 프로젝트의 리소스가 사용할 수 있는 총 컴퓨트 리소스의 양을 +제한할 수 있다. + +리소스 쿼터는 다음과 같이 작동한다. + +- 다른 팀은 다른 네임스페이스에서 작동한다. 현재 이것은 자발적이지만 ACL을 통해 이 필수 사항을 + 적용하기 위한 지원이 계획되어 있다. +- 관리자는 각 네임스페이스에 대해 하나의 `ResourceQuota`를 생성한다. +- 사용자는 네임스페이스에서 리소스(파드, 서비스 등)를 생성하고 쿼터 시스템은 + 사용량을 추적하여 `ResourceQuota`에 정의된 하드(hard) 리소스 제한을 초과하지 않도록 한다. +- 리소스를 생성하거나 업데이트할 때 쿼터 제약 조건을 위반하면 위반된 제약 조건을 설명하는 + 메시지와 함께 HTTP 상태 코드 `403 FORBIDDEN`으로 요청이 실패한다. +- `cpu`, `memory`와 같은 컴퓨트 리소스에 대해 네임스페이스에서 쿼터가 활성화된 경우 + 사용자는 해당값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 쿼터 시스템이 + 파드 생성을 거부할 수 있다. 힌트: 컴퓨트 리소스 요구 사항이 없는 파드를 기본값으로 설정하려면 `LimitRanger` 어드미션 컨트롤러를 사용하자. + 이 문제를 회피하는 방법에 대한 예제는 [연습](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)을 참고하길 바란다. + +`ResourceQuota` 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다. + +네임스페이스와 쿼터를 사용하여 만들 수 있는 정책의 예는 다음과 같다. + +- 용량이 32GiB RAM, 16 코어인 클러스터에서 A 팀이 20GiB 및 10 코어를 사용하고 + B 팀은 10GiB 및 4 코어를 사용하게 하고 2GiB 및 2 코어를 향후 할당을 위해 보유하도록 한다. +- "testing" 네임스페이스를 1 코어 및 1GiB RAM을 사용하도록 제한한다. + "production" 네임스페이스에는 원하는 양을 사용하도록 한다. + +클러스터의 총 용량이 네임스페이스의 쿼터 합보다 작은 경우 리소스에 대한 경합이 있을 수 있다. +이것은 선착순으로 처리된다. + +경합이나 쿼터 변경은 이미 생성된 리소스에 영향을 미치지 않는다. + +## 리소스 쿼터 활성화 + +많은 쿠버네티스 배포판에 기본적으로 리소스 쿼터 지원이 활성화되어 있다. +API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로 +`ResourceQuota`가 있는 경우 활성화된다. + +해당 네임스페이스에 `ResourceQuota`가 있는 경우 특정 네임스페이스에 리소스 쿼터가 적용된다. + +## 컴퓨트 리소스 쿼터 + +지정된 네임스페이스에서 요청할 수 있는 총 [컴퓨트 리소스](/docs/user-guide/compute-resources) 합을 제한할 수 있다. + +다음과 같은 리소스 유형이 지원된다. + +| 리소스 이름 | 설명 | +| --------------------- | ----------------------------------------------------------- | +| `limits.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 제한의 합은 이 값을 초과할 수 없음 | +| `limits.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 제한의 합은 이 값을 초과할 수 없음 | +| `requests.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 요청의 합은 이 값을 초과할 수 없음 | +| `requests.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 요청의 합은 이 값을 초과할 수 없음 | + +### 확장된 리소스에 대한 리소스 쿼터 + +위에서 언급한 리소스 외에도 릴리스 1.10에서는 +[확장된 리소스](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)에 대한 쿼터 지원이 추가되었다. + +확장된 리소스에는 오버커밋(overcommit)이 허용되지 않으므로 하나의 쿼터에서 +동일한 확장된 리소스에 대한 `requests`와 `limits`을 모두 지정하는 것은 의미가 없다. 따라서 확장된 +리소스의 경우 지금은 접두사 `requests.`이 있는 쿼터 항목만 허용된다. + +예를 들어, 리소스 이름이 `nvidia.com/gpu`이고 네임스페이스에서 요청된 총 GPU 수를 4개로 제한하려는 경우, +GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. + +* `requests.nvidia.com/gpu: 4` + +자세한 내용은 [쿼터 보기 및 설정](#쿼터-보기-및-설정)을 참고하길 바란다. + + +## 스토리지 리소스 쿼터 + +지정된 네임스페이스에서 요청할 수 있는 총 [스토리지 리소스](/ko/docs/concepts/storage/persistent-volumes/) 합을 제한할 수 있다. + +또한 연관된 ​​스토리지 클래스를 기반으로 스토리지 리소스 사용을 제한할 수 있다. + +| 리소스 이름 | 설명 | +| --------------------- | ----------------------------------------------------------- | +| `requests.storage` | 모든 퍼시스턴트 볼륨 클레임에서 스토리지 요청의 합은 이 값을 초과할 수 없음 | +| `persistentvolumeclaims` | 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 | +| `.storageclass.storage.k8s.io/requests.storage` | storage-class-name과 관련된 모든 퍼시스턴트 볼륨 클레임에서 스토리지 요청의 합은 이 값을 초과할 수 없음 | +| `.storageclass.storage.k8s.io/persistentvolumeclaims` | storage-class-name과 관련된 모든 퍼시스턴트 볼륨 클레임에서 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 | + +예를 들어, 운영자가 `bronze` 스토리지 클래스와 별도로 `gold` 스토리지 클래스를 사용하여 스토리지에 쿼터를 지정하려는 경우 운영자는 다음과 같이 +쿼터를 정의할 수 있다. + +* `gold.storageclass.storage.k8s.io/requests.storage: 500Gi` +* `bronze.storageclass.storage.k8s.io/requests.storage: 100Gi` + +릴리스 1.8에서는 로컬 임시 스토리지에 대한 쿼터 지원이 알파 기능으로 추가되었다. + +| 리소스 이름 | 설명 | +| ------------------------------- |----------------------------------------------------------- | +| `requests.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 요청의 합은 이 값을 초과할 수 없음 | +| `limits.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 제한의 합은 이 값을 초과할 수 없음 | + +## 오브젝트 수 쿼터 + +1.9 릴리스는 다음 구문을 사용하여 모든 표준 네임스페이스 리소스 유형에 쿼터를 지정하는 지원을 추가했다. + +* `count/.` + +다음은 사용자가 오브젝트 수 쿼터 아래에 배치하려는 리소스 셋의 예이다. + +* `count/persistentvolumeclaims` +* `count/services` +* `count/secrets` +* `count/configmaps` +* `count/replicationcontrollers` +* `count/deployments.apps` +* `count/replicasets.apps` +* `count/statefulsets.apps` +* `count/jobs.batch` +* `count/cronjobs.batch` +* `count/deployments.extensions` + +1.15 릴리스는 동일한 구문을 사용하여 사용자 정의 리소스에 대한 지원을 추가했다. +예를 들어 `example.com` API 그룹에서 `widgets` 사용자 정의 리소스에 대한 쿼터를 생성하려면 `count/widgets.example.com`을 사용한다. + +`count/*` 리소스 쿼터를 사용할 때 서버 스토리지 영역에 있다면 오브젝트는 쿼터에 대해 과금된다. +이러한 유형의 쿼터는 스토리지 리소스 고갈을 방지하는 데 유용하다. 예를 들어, +크기가 큰 서버에서 시크릿 수에 쿼터를 지정할 수 있다. 클러스터에 시크릿이 너무 많으면 실제로 서버와 +컨트롤러가 시작되지 않을 수 있다! 네임스페이스에 너무 많은 작업을 생성하는 +잘못 구성된 크론 잡으로 인해 서비스 거부를 유발하는 것으로부터 보호하기 위해 작업의 쿼터를 지정하도록 선택할 수 있다. + +1.9 릴리스 이전에는 제한된 리소스 셋에서 일반 오브젝트 수 쿼터를 적용할 수 있었다. +또한, 특정 리소스에 대한 쿼터를 유형별로 추가로 제한할 수 있다. + +다음 유형이 지원된다. + +| 리소스 이름 | 설명 | +| ------------------------------- | ------------------------------------------------- | +| `configmaps` | 네임스페이스에 존재할 수 있는 총 구성 맵 수 | +| `persistentvolumeclaims` | 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 | +| `pods` | 네임스페이스에 존재할 수 있는 터미널이 아닌 상태의 파드의 총 수. `.status.phase in (Failed, Succeeded)`가 true인 경우 파드는 터미널 상태임 | +| `replicationcontrollers` | 네임스페이스에 존재할 수 있는 총 레플리케이션 컨트롤러 수 | +| `resourcequotas` | 네임스페이스에 존재할 수 있는 총 [리소스 쿼터](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) 수 | +| `services` | 네임스페이스에 존재할 수 있는 총 서비스 수 | +| `services.loadbalancers` | 네임스페이스에 존재할 수 있는 로드 밸런서 유형의 총 서비스 수 | +| `services.nodeports` | 네임스페이스에 존재할 수 있는 노드 포트 유형의 총 서비스 수 | +| `secrets` | 네임스페이스에 존재할 수 있는 총 시크릿 수 | + +예를 들어, `pods` 쿼터는 터미널이 아닌 단일 네임스페이스에서 생성된 `pods` 수를 계산하고 최대값을 적용한다. +사용자가 작은 파드를 많이 생성하여 클러스터의 파드 IP 공급이 고갈되는 경우를 피하기 위해 +네임스페이스에 `pods` 쿼터를 설정할 수 있다. + +## 쿼터 범위 + +각 쿼터에는 연결된 범위 셋이 있을 수 있다. 쿼터는 열거된 범위의 교차 부분과 일치하는 경우에만 +리소스 사용량을 측정한다. + +범위가 쿼터에 추가되면 해당 범위와 관련된 리소스를 지원하는 리소스 수가 제한된다. +허용된 셋 이외의 쿼터에 지정된 리소스는 유효성 검사 오류가 발생한다. + +| 범위 | 설명 | +| ----- | ----------- | +| `Terminating` | `.spec.activeDeadlineSeconds >= 0`에 일치하는 파드 | +| `NotTerminating` | `.spec.activeDeadlineSeconds is nil`에 일치하는 파드 | +| `BestEffort` | 최상의 서비스 품질을 제공하는 파드 | +| `NotBestEffort` | 서비스 품질이 나쁜 파드 | + +`BestEffort` 범위는 다음의 리소스(파드)를 추적하도록 쿼터를 제한한다. + +`Terminating`, `NotTerminating` 및 `NotBestEffort` 범위는 쿼터를 제한하여 다음의 리소스를 추적한다. + +* `cpu` +* `limits.cpu` +* `limits.memory` +* `memory` +* `pods` +* `requests.cpu` +* `requests.memory` + +### PriorityClass별 리소스 쿼터 + +{{< feature-state for_k8s_version="1.12" state="beta" >}} + +특정 [우선 순위](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)로 파드를 생성할 수 있다. +쿼터 스펙의 `scopeSelector` 필드를 사용하여 파드의 우선 순위에 따라 파드의 시스템 리소스 사용을 +제어할 수 있다. + +쿼터 스펙의 `scopeSelector`가 파드를 선택한 경우에만 쿼터가 일치하고 사용된다. + +이 예에서는 쿼터 오브젝트를 생성하여 특정 우선 순위의 파드와 일치시킨다. +예제는 다음과 같이 작동한다. + +- 클러스터의 파드는 "low(낮음)", "medium(중간)", "high(높음)"의 세 가지 우선 순위 클래스 중 하나를 가진다. +- 각 우선 순위마다 하나의 쿼터 오브젝트가 생성된다. + +다음 YAML을 `quota.yml` 파일에 저장한다. + +```yaml +apiVersion: v1 +kind: List +items: +- apiVersion: v1 + kind: ResourceQuota + metadata: + name: pods-high + spec: + hard: + cpu: "1000" + memory: 200Gi + pods: "10" + scopeSelector: + matchExpressions: + - operator : In + scopeName: PriorityClass + values: ["high"] +- apiVersion: v1 + kind: ResourceQuota + metadata: + name: pods-medium + spec: + hard: + cpu: "10" + memory: 20Gi + pods: "10" + scopeSelector: + matchExpressions: + - operator : In + scopeName: PriorityClass + values: ["medium"] +- apiVersion: v1 + kind: ResourceQuota + metadata: + name: pods-low + spec: + hard: + cpu: "5" + memory: 10Gi + pods: "10" + scopeSelector: + matchExpressions: + - operator : In + scopeName: PriorityClass + values: ["low"] +``` + +`kubectl create`를 사용하여 YAML을 적용한다. + +```shell +kubectl create -f ./quota.yml +``` + +```shell +resourcequota/pods-high created +resourcequota/pods-medium created +resourcequota/pods-low created +``` + +`kubectl describe quota`를 사용하여 `Used` 쿼터가 `0`인지 확인하자. + +```shell +kubectl describe quota +``` + +```shell +Name: pods-high +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 1k +memory 0 200Gi +pods 0 10 + + +Name: pods-low +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 5 +memory 0 10Gi +pods 0 10 + + +Name: pods-medium +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 10 +memory 0 20Gi +pods 0 10 +``` + +우선 순위가 "high"인 파드를 생성한다. 다음 YAML을 +`high-priority-pod.yml` 파일에 저장한다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: high-priority +spec: + containers: + - name: high-priority + image: ubuntu + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello; sleep 10;done"] + resources: + requests: + memory: "10Gi" + cpu: "500m" + limits: + memory: "10Gi" + cpu: "500m" + priorityClassName: high +``` + +`kubectl create`로 적용하자. + +```shell +kubectl create -f ./high-priority-pod.yml +``` + +"high" 우선 순위 쿼터가 적용된 `pods-high`에 대한 "Used" 통계가 변경되었고 +다른 두 쿼터는 변경되지 않았는지 확인한다. + +```shell +kubectl describe quota +``` + +```shell +Name: pods-high +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 500m 1k +memory 10Gi 200Gi +pods 1 10 + + +Name: pods-low +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 5 +memory 0 10Gi +pods 0 10 + + +Name: pods-medium +Namespace: default +Resource Used Hard +-------- ---- ---- +cpu 0 10 +memory 0 20Gi +pods 0 10 +``` + +`scopeSelector`는 `operator` 필드에서 다음 값을 지원한다. + +* `In` +* `NotIn` +* `Exist` +* `DoesNotExist` + +## 요청과 제한의 비교 {#requests-vs-limits} + +컴퓨트 리소스를 할당할 때 각 컨테이너는 CPU 또는 메모리에 대한 요청과 제한값을 지정할 수 있다. +쿼터는 값에 대한 쿼터를 지정하도록 구성할 수 있다. + +쿼터에 `requests.cpu`나 `requests.memory`에 지정된 값이 있으면 들어오는 모든 +컨테이너가 해당 리소스에 대한 명시적인 요청을 지정해야 한다. 쿼터에 `limits.cpu`나 +`limits.memory`에 지정된 값이 있으면 들어오는 모든 컨테이너가 해당 리소스에 대한 명시적인 제한을 지정해야 한다. + +## 쿼터 보기 및 설정 + +Kubectl은 쿼터 생성, 업데이트 및 보기를 지원한다. + +```shell +kubectl create namespace myspace +``` + +```shell +cat < compute-resources.yaml +apiVersion: v1 +kind: ResourceQuota +metadata: + name: compute-resources +spec: + hard: + requests.cpu: "1" + requests.memory: 1Gi + limits.cpu: "2" + limits.memory: 2Gi + requests.nvidia.com/gpu: 4 +EOF +``` + +```shell +kubectl create -f ./compute-resources.yaml --namespace=myspace +``` + +```shell +cat < object-counts.yaml +apiVersion: v1 +kind: ResourceQuota +metadata: + name: object-counts +spec: + hard: + configmaps: "10" + persistentvolumeclaims: "4" + pods: "4" + replicationcontrollers: "20" + secrets: "10" + services: "10" + services.loadbalancers: "2" +EOF +``` + +```shell +kubectl create -f ./object-counts.yaml --namespace=myspace +``` + +```shell +kubectl get quota --namespace=myspace +``` + +```shell +NAME AGE +compute-resources 30s +object-counts 32s +``` + +```shell +kubectl describe quota compute-resources --namespace=myspace +``` + +```shell +Name: compute-resources +Namespace: myspace +Resource Used Hard +-------- ---- ---- +limits.cpu 0 2 +limits.memory 0 2Gi +requests.cpu 0 1 +requests.memory 0 1Gi +requests.nvidia.com/gpu 0 4 +``` + +```shell +kubectl describe quota object-counts --namespace=myspace +``` + +```shell +Name: object-counts +Namespace: myspace +Resource Used Hard +-------- ---- ---- +configmaps 0 10 +persistentvolumeclaims 0 4 +pods 0 4 +replicationcontrollers 0 20 +secrets 1 10 +services 0 10 +services.loadbalancers 0 2 +``` + +Kubectl은 `count/.` 구문을 사용하여 모든 표준 네임스페이스 리소스에 대한 +오브젝트 수 쿼터를 지원한다. + +```shell +kubectl create namespace myspace +``` + +```shell +kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace +``` + +```shell +kubectl run nginx --image=nginx --replicas=2 --namespace=myspace +``` + +```shell +kubectl describe quota --namespace=myspace +``` + +```shell +Name: test +Namespace: myspace +Resource Used Hard +-------- ---- ---- +count/deployments.extensions 1 2 +count/pods 2 3 +count/replicasets.extensions 1 4 +count/secrets 1 4 +``` + +## 쿼터 및 클러스터 용량 + +`ResourceQuotas`는 클러스터 용량과 무관하다. 그것들은 절대 단위로 표현된다. +따라서 클러스터에 노드를 추가해도 각 네임스페이스에 더 많은 리소스를 +사용할 수 있는 기능이 자동으로 부여되지는 *않는다*. + +가끔 다음과 같은 보다 복잡한 정책이 필요할 수 있다. + + - 여러 팀으로 전체 클러스터 리소스를 비례적으로 나눈다. + - 각 테넌트가 필요에 따라 리소스 사용량을 늘릴 수 있지만, 실수로 리소스가 고갈되는 것을 + 막기 위한 충분한 제한이 있다. + - 하나의 네임스페이스에서 요구를 감지하고 노드를 추가하며 쿼터를 늘린다. + +이러한 정책은 쿼터 사용을 감시하고 다른 신호에 따라 각 네임스페이스의 쿼터 하드 제한을 +조정하는 "컨트롤러"를 작성하여 `ResourceQuotas`를 구성 요소로 +사용하여 구현할 수 있다. + +리소스 쿼터는 통합된 클러스터 리소스를 분할하지만 노드에 대한 제한은 없다. +여러 네임스페이스의 파드가 동일한 노드에서 실행될 수 있다. + +## 기본적으로 우선 순위 클래스 소비 제한 + +파드가 특정 우선 순위, 예를 들어 일치하는 쿼터 오브젝트가 존재하는 경우에만 "cluster-services"가 네임스페이스에 허용되어야 힌다. + +이 메커니즘을 통해 운영자는 특정 우선 순위가 높은 클래스의 사용을 제한된 수의 네임스페이스로 제한할 수 있으며 모든 네임스페이스가 기본적으로 이러한 우선 순위 클래스를 사용할 수 있는 것은 아니다. + +이를 적용하려면 kube-apiserver 플래그 `--admission-control-config-file`을 사용하여 다음 구성 파일의 경로를 전달해야 한다. + +{{< tabs name="example1" >}} +{{% tab name="apiserver.config.k8s.io/v1" %}} +```yaml +apiVersion: apiserver.config.k8s.io/v1 +kind: AdmissionConfiguration +plugins: +- name: "ResourceQuota" + configuration: + apiVersion: apiserver.config.k8s.io/v1 + kind: ResourceQuotaConfiguration + limitedResources: + - resource: pods + matchScopes: + - scopeName: PriorityClass + operator: In + values: ["cluster-services"] +``` +{{% /tab %}} +{{% tab name="apiserver.k8s.io/v1alpha1" %}} +```yaml +# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1 +apiVersion: apiserver.k8s.io/v1alpha1 +kind: AdmissionConfiguration +plugins: +- name: "ResourceQuota" + configuration: + # Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1, ResourceQuotaConfiguration + apiVersion: resourcequota.admission.k8s.io/v1beta1 + kind: Configuration + limitedResources: + - resource: pods + matchScopes: + - scopeName: PriorityClass + operator: In + values: ["cluster-services"] +``` +{{% /tab %}} +{{< /tabs >}} + +이제 "cluster-services" 파드는 `scopeSelector`와 일치하는 쿼터 오브젝트가 있는 네임스페이스에서만 허용된다. +예를 들면 다음과 같다. +```yaml + scopeSelector: + matchExpressions: + - scopeName: PriorityClass + operator: In + values: ["cluster-services"] +``` + +자세한 내용은 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)와 [우선 순위 클래스에 대한 쿼터 지원 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)를 참고하길 바란다. + +## 예제 + +[리소스 쿼터를 사용하는 방법에 대한 자세한 예](/docs/tasks/administer-cluster/quota-api-object/)를 참고하길 바란다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고하길 바란다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/scheduling/kube-scheduler.md b/content/ko/docs/concepts/scheduling/kube-scheduler.md new file mode 100644 index 0000000000..a7c33265f2 --- /dev/null +++ b/content/ko/docs/concepts/scheduling/kube-scheduler.md @@ -0,0 +1,97 @@ +--- +title: 쿠버네티스 스케줄러 +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} + +쿠버네티스에서 _스케줄링_ 은 {{< glossary_tooltip term_id="kubelet" >}}이 +파드를 실행할 수 있도록 {{< glossary_tooltip text="파드" term_id="pod" >}}가 +{{< glossary_tooltip text="노드" term_id="node" >}}에 적합한지 확인하는 것을 말한다. + +{{% /capture %}} + +{{% capture body %}} + +## 스케줄링 개요 {#scheduling} + +스케줄러는 노드가 할당되지 않은 새로 생성된 파드를 감시한다. +스케줄러가 발견한 모든 파드에 대해 스케줄러는 해당 파드가 실행될 +최상의 노드를 찾는 책임을 진다. 스케줄러는 +아래 설명된 스케줄링 원칙을 고려하여 이 배치 결정을 +하게 된다. + +파드가 특정 노드에 배치되는 이유를 이해하려고 하거나 +사용자 정의된 스케줄러를 직접 구현하려는 경우 이 +페이지를 통해서 스케줄링에 대해 배울 수 있을 것이다. + +## kube-scheduler + +[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)는 +쿠버네티스의 기본 스케줄러이며 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 +일부로 실행된다. +kube-scheduler는 원하거나 필요에 따라 자체 스케줄링 컴포넌트를 +만들고 대신 사용할 수 있도록 설계되었다. + +새로 생성된 모든 파드 또는 예약되지 않은 다른 파드에 대해 kube-scheduler는 +실행할 최적의 노드를 선택한다. 그러나 파드의 모든 컨테이너에는 +리소스에 대한 요구사항이 다르며 모든 파드에도 +요구사항이 다르다. 따라서 기존 노드들은 +특정 스케줄링 요구사항에 따라 필터링 되어야 한다. + +클러스터에서 파드에 대한 스케줄링 요구사항을 충족하는 노드를 +_실행 가능한(feasible)_ 노드라고 한다. 적합한 노드가 없으면 스케줄러가 +배치할 수 있을 때까지 파드가 스케줄 되지 않은 상태로 유지된다. + +스케줄러는 파드가 실행 가능한 노드를 찾은 다음 실행 가능한 노드의 +점수를 측정하는 기능 셋을 수행하고 실행 가능한 노드 중에서 가장 높은 점수를 +가진 노드를 선택하여 파드를 실행한다. 그런 다음 스케줄러는 +_바인딩_ 이라는 프로세스에서 이 결정에 대해 API 서버에 알린다. + +스케줄링 결정을 위해 고려해야 할 요소에는 +개별 및 집단 리소스 요구사항, 하드웨어 / 소프트웨어 / +정책 제한조건, 어피니티 및 안티-어피니티 명세, 데이터 +지역성(data locality), 워크로드 간 간섭 등이 포함된다. + +### kube-scheduler에서 노드 선택 {#kube-scheduler-implementation} + +kube-scheduler는 2단계 작업에서 파드에 대한 노드를 선택한다. + +1. 필터링 +1. 스코어링(scoring) + +_필터링_ 단계는 파드를 스케줄링 할 수 있는 노드 셋을 +찾는다. 예를 들어 PodFitsResources 필터는 +후보 노드가 파드의 특정 리소스 요청을 충족시키기에 충분한 가용 리소스가 +있는지 확인한다. 이 단계 다음에 노드 목록에는 적합한 노드들이 +포함된다. 하나 이상의 노드가 포함된 경우가 종종 있을 것이다. 목록이 비어 있으면 +해당 파드는 (아직) 스케줄링 될 수 없다. + +_스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순위를 지정하여 +가장 적합한 파드 배치를 선택한다. 스케줄러는 사용 중인 스코어링 규칙에 따라 +이 점수를 기준으로 필터링에서 통과된 각 노드에 대해 점수를 지정한다. + +마지막으로 kube-scheduler는 파드를 순위가 가장 높은 노드에 할당한다. +점수가 같은 노드가 두 개 이상인 경우 kube-scheduler는 +이들 중 하나를 임의로 선택한다. + +스케줄러의 필터링 및 스코어링 동작을 구성하는 데 지원되는 두 가지 +방법이 있다. + +1. [스케줄링 정책](/docs/reference/scheduling/policies)을 사용하면 + 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다. +1. [스케줄링 프로파일](/docs/reference/scheduling/profiles)을 사용하면 + `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 + 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 + kube-scheduler를 구성할 수도 있다. + +{{% /capture %}} +{{% capture whatsnext %}} +* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling/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/)에 대해 배우기 +{{% /capture %}} diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 03d8700cd2..dac88a68c3 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -71,6 +71,7 @@ spec: - http: paths: - path: /testpath + pathType: Prefix backend: serviceName: test servicePort: 80 @@ -115,6 +116,84 @@ spec: 만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은 기본 백엔드로 라우팅 된다. +### 경로(Path) 유형 + +인그레스의 각 경로에는 해당하는 경로 유형이 있다. 지원되는 세 가지의 경로 +유형이 있다. + +* _`ImplementationSpecific`_ (기본): 이 경로 유형의 일치 여부는 IngressClass에 따라 + 달라진다. 이를 구현할 때 별도 pathType으로 처리하거나, `Prefix` 또는 `Exact` + 경로 유형과 같이 동일하게 처리할 수 있다. + +* _`Exact`_: URL 경로의 대소문자를 엄격하게 일치시킨다. + +* _`Prefix`_: URL 경로의 접두사를 `/` 를 기준으로 분리한 값과 일치시킨다. + 일치는 대소문자를 구분하고, + 요소별로 경로 요소에 대해 수행한다. + 모든 _p_ 가 요청 경로의 요소별 접두사가 _p_ 인 경우 + 요청은 _p_ 경로에 일치한다. + {{< note >}} + 경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 + 하위 문자열인 경우에는 일치하지 않는다(예시: + `/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다). + {{< /note >}} + +#### 다중 일치 +경우에 따라 인그레스의 여러 경로가 요청과 일치할 수 있다. +이 경우 가장 긴 일치하는 경로가 우선하게 된다. 두 개의 경로가 +여전히 동일하게 일치하는 경우 접두사(prefix) 경로 유형보다 +정확한(exact) 경로 유형을 가진 경로가 사용 된다. + +## 인그레스 클래스 + +인그레스는 서로 다른 컨트롤러에 의해 구현될 수 있으며, 종종 다른 구성으로 +구현될 수 있다. 각 인그레스에서는 클래스를 구현해야하는 컨트롤러 +이름을 포함하여 추가 구성이 포함된 IngressClass +리소스에 대한 참조 클래스를 지정해야 한다. + +```yaml +apiVersion: networking.k8s.io/v1beta1 +kind: IngressClass +metadata: + name: external-lb +spec: + controller: example.com/ingress-controller + parameters: + apiGroup: k8s.example.com/v1alpha + kind: IngressParameters + name: external-lb +``` + +IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한 +추가 구성을 참조하는데 사용할 수 있다. + +### 사용중단(Deprecated) 어노테이션 + +쿠버네티스 1.18에 IngressClass 리소스 및 `ingressClassName` 필드가 추가되기 +전에 인그레스 클래스는 인그레스에서 +`kubernetes.io/ingress.class` 어노테이션으로 지정되었다. 이 어노테이션은 +공식적으로 정의된 것은 아니지만, 인그레스 컨트롤러에서 널리 지원되었었다. + +인그레스의 최신 `ingressClassName` 필드는 해당 어노테이션을 +대체하지만, 직접적으로 해당하는 것은 아니다. 어노테이션은 일반적으로 +인그레스를 구현해야 하는 인그레스 컨트롤러의 이름을 참조하는 데 사용되었지만, +이 필드는 인그레스 컨트롤러의 이름을 포함하는 추가 인그레스 구성이 +포함된 인그레스 클래스 리소스에 대한 참조이다. + +### 기본 인그레스 클래스 + +특정 IngressClass를 클러스터의 기본 값으로 표시할 수 있다. IngressClass +리소스에서 `ingressclass.kubernetes.io/is-default-class` 를 `true` 로 +설정하면 `ingressClassName` 필드가 지정되지 않은 +새 인그레스에게 기본 IngressClass가 할당된다. + +{{< caution >}} +클러스터의 기본값으로 표시된 IngressClass가 두 개 이상 있는 경우 +어드미션 컨트롤러에서 `ingressClassName` 이 지정되지 않은 +새 인그레스 오브젝트를 생성할 수 없다. 클러스터에서 최대 1개의 IngressClass가 +기본값으로 표시하도록 해서 이 문제를 해결할 수 있다. +{{< /caution >}} + ## 인그레스 유형들 ### 단일 서비스 인그레스 diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 3072c277a0..1b19121672 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -202,6 +202,17 @@ API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만, 엔드포인트슬라이스는 [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에서 자세하게 설명된 추가적인 속성 및 기능을 제공한다. +### 애플리케이션 프로토콜 + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +AppProtocol 필드는 각 서비스 포트에 사용될 애플리케이션 프로토콜을 +지정하는 방법을 제공한다. + +알파 기능으로 이 필드는 기본적으로 활성화되어 있지 않다. 이 필드를 사용하려면, +[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)에서 +`ServiceAppProtocol` 을 활성화해야 한다. + ## 가상 IP와 서비스 프록시 쿠버네티스 클러스터의 모든 노드는 `kube-proxy`를 실행한다. `kube-proxy`는 diff --git a/content/ko/docs/concepts/storage/dynamic-provisioning.md b/content/ko/docs/concepts/storage/dynamic-provisioning.md new file mode 100644 index 0000000000..11564490ec --- /dev/null +++ b/content/ko/docs/concepts/storage/dynamic-provisioning.md @@ -0,0 +1,131 @@ +--- +title: 동적 볼륨 프로비저닝 +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + +동적 볼륨 프로비저닝을 통해 온-디맨드 방식으로 스토리지 볼륨을 생성할 수 있다. +동적 프로비저닝이 없으면 클러스터 관리자는 클라우드 또는 스토리지 +공급자에게 수동으로 요청해서 새 스토리지 볼륨을 생성한 다음, 쿠버네티스에 +표시하기 위해 [`PersistentVolume` 오브젝트](/ko/docs/concepts/storage/persistent-volumes/)를 +생성해야 한다. 동적 프로비저닝 기능을 사용하면 클러스터 관리자가 +스토리지를 사전 프로비저닝 할 필요가 없다. 대신 사용자가 +스토리지를 요청하면 자동으로 프로비저닝 한다. + +{{% /capture %}} + + +{{% capture body %}} + +## 배경 + +동적 볼륨 프로비저닝의 구현은 `storage.k8s.io` API 그룹의 `StorageClass` +API 오브젝트를 기반으로 한다. 클러스터 관리자는 볼륨을 프로비전하는 +*볼륨 플러그인* (프로비저너라고도 알려짐)과 프로비저닝시에 프로비저너에게 +전달할 파라미터 집합을 지정하는 `StorageClass` +오브젝트를 필요한 만큼 정의할 수 있다. +클러스터 관리자는 클러스터 내에서 사용자 정의 파라미터 집합을 +사용해서 여러 가지 유형의 스토리지 (같거나 다른 스토리지 시스템들)를 +정의하고 노출시킬 수 있다. 또한 이 디자인을 통해 최종 사용자는 +스토리지 프로비전 방식의 복잡성과 뉘앙스에 대해 걱정할 필요가 없다. 하지만, +여전히 여러 스토리지 옵션들을 선택할 수 있다. + +스토리지 클래스에 대한 자세한 정보는 +[여기](/docs/concepts/storage/storage-classes/)에서 찾을 수 있다. + +## 동적 프로비저닝 활성화하기 + +동적 프로비저닝을 활성화하려면 클러스터 관리자가 사용자를 위해 하나 이상의 StorageClass +오브젝트를 사전 생성해야 한다. +StorageClass 오브젝트는 동적 프로비저닝이 호출될 때 사용할 프로비저너와 +해당 프로비저너에게 전달할 파라미터를 정의한다. +StorageClass 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. + +다음 매니페스트는 표준 디스크와 같은 퍼시스턴트 디스크를 프로비전하는 +스토리지 클래스 "slow"를 만든다. + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: slow +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-standard +``` + +다음 매니페스트는 SSD와 같은 퍼시스턴트 디스크를 프로비전하는 +스토리지 클래스 "fast"를 만든다. + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: fast +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-ssd +``` + +## 동적 프로비저닝 사용하기 + +사용자는 `PersistentVolumeClaim` 에 스토리지 클래스를 포함시켜 동적으로 프로비전된 +스토리지를 요청한다. 쿠버네티스 v1.6 이전에는 `volume.beta.kubernetes.io/storage-class` +어노테이션을 통해 수행되었다. 그러나 이 어노테이션은 +v1.6부터 더 이상 사용하지 않는다. 사용자는 이제 `PersistentVolumeClaim` 오브젝트의 +`storageClassName` 필드를 사용할 수 있기에 대신하여 사용해야 한다. 이 필드의 값은 +관리자가 구성한 `StorageClass` 의 이름과 +일치해야 한다. ([아래](#동적-프로비저닝-활성화하기)를 참고) + +예를 들어 “fast” 스토리지 클래스를 선택하려면 다음과 +같은 `PersistentVolumeClaim` 을 생성한다. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: claim1 +spec: + accessModes: + - ReadWriteOnce + storageClassName: fast + resources: + requests: + storage: 30Gi +``` + +이 클레임의 결과로 SSD와 같은 퍼시스턴트 디스크가 자동으로 +프로비전 된다. 클레임이 삭제되면 볼륨이 삭제된다. + +## 기본 동작 + +스토리지 클래스가 지정되지 않은 경우 모든 클레임이 동적으로 +프로비전이 되도록 클러스터에서 동적 프로비저닝을 활성화 할 수 있다. 클러스터 관리자는 +이 방법으로 활성화 할 수 있다. + +- 하나의 `StorageClass` 오브젝트를 *default* 로 표시한다. +- API 서버에서 [`DefaultStorageClass` 어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)를 + 사용하도록 설정한다. + +관리자는 `storageclass.kubernetes.io/is-default-class` 어노테이션을 +추가해서 특정 `StorageClass` 를 기본으로 표시할 수 있다. +기본 `StorageClass` 가 클러스터에 존재하고 사용자가 +`storageClassName` 를 지정하지 않은 `PersistentVolumeClaim` 을 +작성하면, `DefaultStorageClass` 어드미션 컨트롤러가 디폴트 +스토리지 클래스를 가리키는 `storageClassName` 필드를 자동으로 추가한다. + +클러스터에는 최대 하나의 *default* 스토리지 클래스가 있을 수 있다. 그렇지 않은 경우 +`storageClassName` 을 명시적으로 지정하지 않은 `PersistentVolumeClaim` 을 +생성할 수 없다. + +## 토폴로지 인식 + +[다중 영역](/ko/docs/setup/best-practices/multiple-zones/) 클러스터에서 파드는 한 지역 내 +여러 영역에 걸쳐 분산될 수 있다. 파드가 예약된 영역에서 단일 영역 스토리지 백엔드를 +프로비전 해야 한다. [볼륨 바인딩 모드](/docs/concepts/storage/storage-classes/#volume-binding-mode)를 +설정해서 수행할 수 있다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md new file mode 100644 index 0000000000..879ef3b939 --- /dev/null +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -0,0 +1,757 @@ +--- +title: 퍼시스턴트 볼륨 +feature: + title: 스토리지 오케스트레이션 + description: > + 로컬 스토리지, GCP나 AWS와 같은 퍼블릭 클라우드 공급자 또는 NFS, iSCSI, Gluster, Ceph, Cinder나 Flocker와 같은 네트워크 스토리지 시스템에서 원하는 스토리지 시스템을 자동으로 마운트한다. + +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +이 페이지는 쿠버네티스의 _퍼시스턴트 볼륨_ 의 현재 상태를 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다. + +{{% /capture %}} + + +{{% capture body %}} + +## 소개 + +스토리지 관리는 컴퓨트 인스턴스 관리와는 별개의 문제다. 퍼시스턴트볼륨 서브시스템은 사용자 및 관리자에게 스토리지 사용 방법에서부터 스토리지가 제공되는 방법에 대한 세부 사항을 추상화하는 API를 제공한다. 이를 위해 퍼시스턴트볼륨 및 퍼시스턴트볼륨클레임이라는 두 가지 새로운 API 리소스를 소개한다. + +퍼시스턴트볼륨(PV)은 관리자가 프로비저닝하거나 [스토리지 클래스](/docs/concepts/storage/storage-classes/)를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와는 별개의 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다. + +퍼시스턴트볼륨클레임(PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: 한 번 읽기/쓰기 또는 여러 번 읽기 전용으로 마운트 할 수 있음). + +퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 단순히 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다. + +[실습 예제와 함께 상세한 내용](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)을 참고하길 바란다. + +## 볼륨과 클레임 라이프사이클 + +PV는 클러스터 리소스이다. PVC는 해당 리소스에 대한 요청이며 리소스에 대한 클레임 검사 역할을 한다. PV와 PVC 간의 상호 작용은 다음 라이프사이클을 따른다. + +### 프로비저닝 + +PV를 프로비저닝 할 수 있는 두 가지 방법이 있다: 정적(static) 프로비저닝과 동적(dynamic) 프로비저닝 + +#### 정적 프로비저닝 + +클러스터 관리자는 여러 PV를 만든다. 클러스터 사용자가 사용할 수 있는 실제 스토리지의 세부 사항을 제공한다. 이 PV들은 쿠버네티스 API에 존재하며 사용할 수 있다. + +#### 동적 프로비저닝 + +관리자가 생성한 정적 PV가 사용자의 퍼시스턴트볼륨클레임과 일치하지 않으면 +클러스터는 PVC를 위해 특별히 볼륨을 동적으로 프로비저닝 하려고 시도할 수 있다. +이 프로비저닝은 스토리지클래스를 기반으로 한다. PVC는 +[스토리지 클래스](/docs/concepts/storage/storage-classes/)를 +요청해야 하며 관리자는 동적 프로비저닝이 발생하도록 해당 클래스를 생성하고 구성해야 한다. +`""` 클래스를 요청하는 클레임은 동적 프로비저닝을 효과적으로 +비활성화한다. + +스토리지 클래스를 기반으로 동적 스토리지 프로비저닝을 사용하려면 클러스터 관리자가 API 서버에서 +`DefaultStorageClass` [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)를 사용하도록 설정해야 한다. +예를 들어 API 서버 컴포넌트의 `--enable-admission-plugins` 플래그에 대한 쉼표로 구분되어 +정렬된 값들의 목록 중에 `DefaultStorageClass`가 포함되어 있는지 확인하여 설정할 수 있다. +API 서버 커맨드라인 플래그에 대한 자세한 정보는 +[kube-apiserver](/docs/admin/kube-apiserver/) 문서를 확인하면 된다. + +### 바인딩 + +사용자는 원하는 특정 용량의 스토리지와 특정 접근 모드로 퍼시스턴트볼륨클레임을 생성하거나 동적 프로비저닝의 경우 이미 생성한 상태다. 마스터의 컨트롤 루프는 새로운 PVC를 감시하고 일치하는 PV(가능한 경우)를 찾아 서로 바인딩한다. PV가 새 PVC에 대해 동적으로 프로비저닝된 경우 루프는 항상 해당 PV를 PVC에 바인딩한다. 그렇지 않으면 사용자는 항상 최소한 그들이 요청한 것을 얻지만 볼륨은 요청된 것을 초과할 수 있다. 일단 바인딩되면 퍼시스턴트볼륨클레임은 어떻게 바인딩되었는지 상관없이 배타적으로 바인딩된다. PVC 대 PV 바인딩은 일대일 매핑으로, 퍼시스턴트볼륨과 퍼시스턴트볼륨클레임 사이의 양방향 바인딩인 ClaimRef를 사용한다. + +일치하는 볼륨이 없는 경우 클레임은 무한정 바인딩되지 않은 상태로 남아 있다. 일치하는 볼륨이 제공되면 클레임이 바인딩된다. 예를 들어 많은 수의 50Gi PV로 프로비저닝된 클러스터는 100Gi를 요청하는 PVC와 일치하지 않는다. 100Gi PV가 클러스터에 추가되면 PVC를 바인딩할 수 있다. + +### 사용 중 + +파드는 클레임을 볼륨으로 사용한다. 클러스터는 클레임을 검사하여 바인딩된 볼륨을 찾고 해당 볼륨을 파드에 마운트한다. 여러 접근 모드를 지원하는 볼륨의 경우 사용자는 자신의 클레임을 파드에서 볼륨으로 사용할 때 원하는 접근 모드를 지정한다. + +일단 사용자에게 클레임이 있고 그 클레임이 바인딩되면, 바인딩된 PV는 사용자가 필요로 하는 한 사용자에게 속한다. 사용자는 파드의 `volumes` 블록에 `persistentVolumeClaim`을 포함하여 파드를 스케줄링하고 클레임한 PV에 접근한다. 이에 대한 자세한 내용은 [볼륨으로 클레임하기](#볼륨으로-클레임하기)를 참고하길 바란다. + +### 사용 중인 스토리지 오브젝트 ​​보호 +사용 중인 스토리지 오브젝트 ​​보호 기능의 목적은 PVC에 바인딩된 파드와 퍼시스턴트볼륨(PV)이 사용 중인 퍼시스턴트볼륨클레임(PVC)을 시스템에서 삭제되지 않도록 하는 것이다. 삭제되면 이로 인해 데이터의 손실이 발생할 수 있기 때문이다. + +{{< note >}} +PVC를 사용하는 파드 오브젝트가 존재하면 파드가 PVC를 사용하고 있는 상태이다. +{{< /note >}} + +사용자가 파드에서 활발하게 사용 중인 PVC를 삭제하면 PVC는 즉시 삭제되지 않는다. PVC가 더 이상 파드에서 적극적으로 사용되지 않을 때까지 PVC 삭제가 연기된다. 또한 관리자가 PVC에 바인딩된 PV를 삭제하면 PV는 즉시 삭제되지 않는다. PV가 더 이상 PVC에 바인딩되지 않을 때까지 PV 삭제가 연기된다. + +PVC의 상태가 `Terminating`이고 `Finalizers` 목록에 `kubernetes.io/pvc-protection`이 포함되어 있으면 PVC가 보호된 것으로 볼 수 있다. + +```shell +kubectl describe pvc hostpath +Name: hostpath +Namespace: default +StorageClass: example-hostpath +Status: Terminating +Volume: +Labels: +Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath + volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath +Finalizers: [kubernetes.io/pvc-protection] +... +``` + +마찬가지로 PV 상태가 `Terminating`이고 `Finalizers` 목록에 `kubernetes.io/pv-protection`이 포함되어 있으면 PV가 보호된 것으로 볼 수 있다. + +```shell +kubectl describe pv task-pv-volume +Name: task-pv-volume +Labels: type=local +Annotations: +Finalizers: [kubernetes.io/pv-protection] +StorageClass: standard +Status: Terminating +Claim: +Reclaim Policy: Delete +Access Modes: RWO +Capacity: 1Gi +Message: +Source: + Type: HostPath (bare host directory volume) + Path: /tmp/data + HostPathType: +Events: +``` + +### 반환(Reclaiming) + +사용자가 볼륨을 다 사용하고나면 리소스를 반환할 수 있는 API를 사용하여 PVC 오브젝트를 삭제할 수 있다. 퍼시스턴트볼륨의 반환 정책은 볼륨에서 클레임을 해제한 후 볼륨에 수행할 작업을 클러스터에 알려준다. 현재 볼륨에 대한 반환 정책은 Retain, Recycle, 그리고 Delete가 있다. + +#### Retain(보존) + +`Retain` 반환 정책은 리소스를 수동으로 반환할 수 있게 한다. 퍼시스턴트볼륨클레임이 삭제되면 퍼시스턴트볼륨은 여전히 존재하며 볼륨은 "릴리스 된" 것으로 간주된다. 그러나 이전 요청자의 데이터가 여전히 볼륨에 남아 있기 때문에 다른 요청에 대해서는 아직 사용할 수 없다. 관리자는 다음 단계에 따라 볼륨을 수동으로 반환할 수 있다. + +1. 퍼시스턴트볼륨을 삭제한다. PV가 삭제된 후에도 외부 인프라(예: AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산이 존재한다. +1. 관련 스토리지 자산의 데이터를 수동으로 삭제한다. +1. 연결된 스토리지 자산을 수동으로 삭제하거나 동일한 스토리지 자산을 재사용하려는 경우 스토리지 자산 정의로 새 퍼시스턴트볼륨을 생성한다. + +#### Delete(삭제) + +`Delete` 반환 정책을 지원하는 볼륨 플러그인의 경우, 삭제는 쿠버네티스에서 퍼시스턴트볼륨 오브젝트와 외부 인프라(예: AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산을 모두 삭제한다. 동적으로 프로비저닝된 볼륨은 [스토리지클래스의 반환 정책](#반환-정책)을 상속하며 기본값은 `Delete`이다. 관리자는 사용자의 기대에 따라 스토리지클래스를 구성해야 한다. 그렇지 않으면 PV를 생성한 후 PV를 수정하거나 패치해야 한다. [퍼시스턴트볼륨의 반환 정책 변경](/docs/tasks/administer-cluster/change-pv-reclaim-policy/)을 참고하길 바란다. + +#### Recycle(재활용) + +{{< warning >}} +`Recycle` 반환 정책은 더 이상 사용하지 않는다. 대신 권장되는 방식은 동적 프로비저닝을 사용하는 것이다. +{{< /warning >}} + +기본 볼륨 플러그인에서 지원하는 경우 `Recycle` 반환 정책은 볼륨에서 기본 스크럽(`rm -rf /thevolume/*`)을 수행하고 새 클레임에 다시 사용할 수 있도록 한다. + +그러나 관리자는 [여기](/docs/admin/kube-controller-manager/)에 설명된대로 쿠버네티스 컨트롤러 관리자 커맨드라인 인자(command line arguments)를 사용하여 사용자 정의 재활용 파드 템플릿을 구성할 수 있다. 사용자 정의 재활용 파드 템플릿에는 아래 예와 같이 `volumes` 명세가 포함되어야 한다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pv-recycler + namespace: default +spec: + restartPolicy: Never + volumes: + - name: vol + hostPath: + path: /any/path/it/will/be/replaced + containers: + - name: pv-recycler + image: "k8s.gcr.io/busybox" + command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"] + volumeMounts: + - name: vol + mountPath: /scrub +``` + +그러나 `volumes` 부분의 사용자 정의 재활용 파드 템플릿에 지정된 특정 경로는 재활용되는 볼륨의 특정 경로로 바뀐다. + +### 퍼시스턴트 볼륨 클레임 확장 + +{{< feature-state for_k8s_version="v1.11" state="beta" >}} + +이제 퍼시스턴트볼륨클레임(PVC) 확장 지원이 기본적으로 활성화되어 있다. 다음 유형의 +볼륨을 확장할 수 있다. + +* gcePersistentDisk +* awsElasticBlockStore +* Cinder +* glusterfs +* rbd +* Azure File +* Azure Disk +* Portworx +* FlexVolumes +* CSI + +스토리지 클래스의 `allowVolumeExpansion` 필드가 true로 설정된 경우에만 PVC를 확장할 수 있다. + +``` yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: gluster-vol-default +provisioner: kubernetes.io/glusterfs +parameters: + resturl: "http://192.168.10.100:8080" + restuser: "" + secretNamespace: "" + secretName: "" +allowVolumeExpansion: true +``` + +PVC에 대해 더 큰 볼륨을 요청하려면 PVC 오브젝트를 수정하여 더 큰 용량을 +지정한다. 이는 기본 퍼시스턴트볼륨을 지원하는 볼륨의 확장을 트리거한다. 클레임을 만족시키기 위해 +새로운 퍼시스턴트볼륨이 생성되지 않고 기존 볼륨의 크기가 조정된다. + +#### CSI 볼륨 확장 + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +CSI 볼륨 확장 지원은 기본적으로 활성화되어 있지만 볼륨 확장을 지원하려면 특정 CSI 드라이버도 필요하다. 자세한 내용은 특정 CSI 드라이버 문서를 참고한다. + + +#### 파일시스템을 포함하는 볼륨 크기 조정 + +파일시스템이 XFS, Ext3 또는 Ext4 인 경우에만 파일시스템을 포함하는 볼륨의 크기를 조정할 수 있다. + +볼륨에 파일시스템이 포함된 경우 새 파드가 `ReadWrite` 모드에서 퍼시스턴트볼륨클레임을 사용하는 +경우에만 파일시스템의 크기가 조정된다. 파일시스템 확장은 파드가 시작되거나 +파드가 실행 중이고 기본 파일시스템이 온라인 확장을 지원할 때 수행된다. + +FlexVolumes는 `RequiresFSResize` 기능으로 드라이버가 `true`로 설정된 경우 크기 조정을 허용한다. +FlexVolume은 파드 재시작 시 크기를 조정할 수 있다. + +#### 사용 중인 퍼시스턴트볼륨클레임 크기 조정 + +{{< feature-state for_k8s_version="v1.15" state="beta" >}} + +{{< note >}} +사용 중인 PVC 확장은 쿠버네티스 1.15 이후 버전에서는 베타로, 1.11 이후 버전에서는 알파로 제공된다. `ExpandInUsePersistentVolumes` 기능을 사용하도록 설정해야 한다. 베타 기능의 경우 여러 클러스터에서 자동으로 적용된다. 자세한 내용은 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참고한다. +{{< /note >}} + +이 경우 기존 PVC를 사용하는 파드 또는 디플로이먼트를 삭제하고 다시 만들 필요가 없다. +파일시스템이 확장되자마자 사용 중인 PVC가 파드에서 자동으로 사용 가능하다. +이 기능은 파드나 디플로이먼트에서 사용하지 않는 PVC에는 영향을 미치지 않는다. 확장을 완료하기 전에 +PVC를 사용하는 파드를 만들어야 한다. + + +다른 볼륨 유형과 비슷하게 FlexVolume 볼륨도 파드에서 사용 중인 경우 확장할 수 있다. + +{{< note >}} +FlexVolume의 크기 조정은 기본 드라이버가 크기 조정을 지원하는 경우에만 가능하다. +{{< /note >}} + +{{< note >}} +EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터(quota)가 있다. +{{< /note >}} + + +## 퍼시스턴트 볼륨의 유형 + +퍼시스턴트볼륨 유형은 플러그인으로 구현된다. 쿠버네티스는 현재 다음의 플러그인을 지원한다. + +* GCEPersistentDisk +* AWSElasticBlockStore +* AzureFile +* AzureDisk +* CSI +* FC (파이버 채널) +* FlexVolume +* Flocker +* NFS +* iSCSI +* RBD (Ceph Block Device) +* CephFS +* Cinder (OpenStack 블록 스토리지) +* Glusterfs +* VsphereVolume +* Quobyte Volumes +* HostPath (단일 노드 테스트 전용 – 로컬 스토리지는 어떤 방식으로도 지원되지 않으며 다중-노드 클러스터에서 작동하지 않음) +* Portworx Volumes +* ScaleIO Volumes +* StorageOS + +## 퍼시스턴트 볼륨 + +각 PV에는 스펙과 상태(볼륨의 명세와 상태)가 포함된다. +퍼시스턴트볼륨 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: pv0003 +spec: + capacity: + storage: 5Gi + volumeMode: Filesystem + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Recycle + storageClassName: slow + mountOptions: + - hard + - nfsvers=4.1 + nfs: + path: /tmp + server: 172.17.0.2 +``` + +{{< note >}} +클러스터 내에서 퍼시스턴트볼륨을 사용하려면 볼륨 유형과 관련된 헬퍼(Helper) 프로그램이 필요할 수 있다. 이 예에서 퍼시스턴트볼륨은 NFS 유형이며 NFS 파일시스템 마운트를 지원하려면 헬퍼 프로그램인 /sbin/mount.nfs가 필요하다. +{{< /note >}} + +### 용량 + +일반적으로 PV는 특정 저장 용량을 가진다. 이것은 PV의 `capacity` 속성을 사용하여 설정된다. `capacity`가 사용하는 단위를 이해하려면 쿠버네티스 [리소스 모델](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)을 참고한다. + +현재 스토리지 용량 크기는 설정하거나 요청할 수 있는 유일한 리소스이다. 향후 속성에 IOPS, 처리량 등이 포함될 수 있다. + +### 볼륨 모드 + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +쿠버네티스는 퍼시스턴트볼륨의 두 가지 `volumeModes`인 `Filesystem`과 `Block`을 지원한다. + +`volumeMode`는 선택적 API 파라미터이다. +`Filesystem`은 `volumeMode` 파라미터가 생략될 때 사용되는 기본 모드이다. + +`volumeMode: Filesystem`이 있는 볼륨은 파드의 디렉터리에 *마운트* 된다. 볼륨이 장치에 +의해 지원되고 그 장치가 비어 있으면 쿠버네티스는 장치를 +처음 마운트하기 전에 장치에 파일시스템을 만든다. + +볼륨을 원시 블록 장치로 사용하려면 `volumeMode`의 값을 `Block`으로 설정할 수 있다. +이러한 볼륨은 파일시스템이 없는 블록 장치로 파드에 제공된다. +이 모드는 파드와 볼륨 사이에 파일시스템 계층 없이도 볼륨에 액세스하는 +가장 빠른 방법을 파드에 제공하는 데 유용하다. 반면에 파드에서 실행되는 애플리케이션은 +원시 블록 장치를 처리하는 방법을 알아야 한다. +파드에서 `volumeMode: Block`으로 볼륨을 사용하는 방법에 대한 예는 +[원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)를 참조하십시오. + +### 접근 모드 + +리소스 제공자가 지원하는 방식으로 호스트에 퍼시스턴트볼륨을 마운트할 수 있다. 아래 표에서 볼 수 있듯이 제공자들은 서로 다른 기능을 가지며 각 PV의 접근 모드는 해당 볼륨에서 지원하는 특정 모드로 설정된다. 예를 들어 NFS는 다중 읽기/쓰기 클라이언트를 지원할 수 있지만 특정 NFS PV는 서버에서 읽기 전용으로 export할 수 있다. 각 PV는 특정 PV의 기능을 설명하는 자체 접근 모드 셋을 갖는다. + +접근 모드는 다음과 같다. + +* ReadWriteOnce -- 하나의 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다 +* ReadOnlyMany -- 여러 노드에서 볼륨을 읽기 전용으로 마운트할 수 있다 +* ReadWriteMany -- 여러 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다 + +CLI에서 접근 모드는 다음과 같이 약어로 표시된다. + +* RWO - ReadWriteOnce +* ROX - ReadOnlyMany +* RWX - ReadWriteMany + +> __중요!__ 볼륨이 여러 접근 모드를 지원하더라도 한 번에 하나의 접근 모드를 사용하여 마운트할 수 있다. 예를 들어 GCEPersistentDisk는 하나의 노드가 ReadWriteOnce로 마운트하거나 여러 노드가 ReadOnlyMany로 마운트할 수 있지만 동시에는 불가능하다. + + +| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany| +| :--- | :---: | :---: | :---: | +| AWSElasticBlockStore | ✓ | - | - | +| AzureFile | ✓ | ✓ | ✓ | +| AzureDisk | ✓ | - | - | +| CephFS | ✓ | ✓ | ✓ | +| Cinder | ✓ | - | - | +| CSI | 드라이버에 따라 다름 | 드라이버에 따라 다름 | 드라이버에 따라 다름 | +| FC | ✓ | ✓ | - | +| FlexVolume | ✓ | ✓ | 드라이버에 따라 다름 | +| Flocker | ✓ | - | - | +| GCEPersistentDisk | ✓ | ✓ | - | +| Glusterfs | ✓ | ✓ | ✓ | +| HostPath | ✓ | - | - | +| iSCSI | ✓ | ✓ | - | +| Quobyte | ✓ | ✓ | ✓ | +| NFS | ✓ | ✓ | ✓ | +| RBD | ✓ | ✓ | - | +| VsphereVolume | ✓ | - | - (파드가 병치될(collocated) 때 작동) | +| PortworxVolume | ✓ | - | ✓ | +| ScaleIO | ✓ | ✓ | - | +| StorageOS | ✓ | - | - | + +### 클래스 + +PV는 `storageClassName` 속성을 +[스토리지클래스](/docs/concepts/storage/storage-classes/)의 +이름으로 설정하여 지정하는 클래스를 가질 수 있다. +특정 클래스의 PV는 해당 클래스를 요청하는 PVC에만 바인딩될 수 있다. +`storageClassName`이 없는 PV에는 클래스가 없으며 특정 클래스를 요청하지 않는 PVC에만 +바인딩할 수 있다. + +이전에는 `volume.beta.kubernetes.io/storage-class` 어노테이션이 +`storageClassName` 속성 대신 사용되었다. 이 어노테이션은 아직까지는 사용할 수 있지만, +향후 쿠버네티스 릴리스에서 완전히 사용 중단(deprecated)이 될 예정이다. + +### 반환 정책 + +현재 반환 정책은 다음과 같다. + +* Retain(보존) -- 수동 반환 +* Recycle(재활용) -- 기본 스크럽 (`rm -rf /thevolume/*`) +* Delete(삭제) -- AWS EBS, GCE PD, Azure Disk 또는 OpenStack Cinder 볼륨과 같은 관련 스토리지 자산이 삭제됨 + +현재 NFS 및 HostPath만 재활용을 지원한다. AWS EBS, GCE PD, Azure Disk 및 Cinder 볼륨은 삭제를 지원한다. + +### 마운트 옵션 + +쿠버네티스 관리자는 퍼시스턴트 볼륨이 노드에 마운트될 때 추가 마운트 옵션을 지정할 수 있다. + +{{< note >}} +모든 퍼시스턴트 볼륨 유형이 마운트 옵션을 지원하는 것은 아니다. +{{< /note >}} + +다음 볼륨 유형은 마운트 옵션을 지원한다. + +* AWSElasticBlockStore +* AzureDisk +* AzureFile +* CephFS +* Cinder (OpenStack 블록 스토리지) +* GCEPersistentDisk +* Glusterfs +* NFS +* Quobyte Volumes +* RBD (Ceph Block Device) +* StorageOS +* VsphereVolume +* iSCSI + +마운트 옵션의 유효성이 검사되지 않으므로 마운트 옵션이 유효하지 않으면 마운트가 실패한다. + +이전에는 `mountOptions` 속성 대신 `volume.beta.kubernetes.io/mount-options` 어노테이션이 +사용되었다. 이 어노테이션은 아직까지는 사용할 수 있지만, +향후 쿠버네티스 릴리스에서 완전히 사용 중단(deprecated)이 될 예정이다. + +### 노드 어피니티(affinity) + +{{< note >}} +대부분의 볼륨 유형의 경우 이 필드를 설정할 필요가 없다. [AWS EBS](/ko/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) 및 [Azure Disk](/ko/docs/concepts/storage/volumes/#azuredisk) 볼륨 블록 유형에 자동으로 채워진다. [로컬](/ko/docs/concepts/storage/volumes/#local) 볼륨에 대해서는 이를 명시적으로 설정해야 한다. +{{< /note >}} + +PV는 [노드 어피니티](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core)를 지정하여 이 볼륨에 접근할 수 있는 노드를 제한하는 제약 조건을 정의할 수 있다. PV를 사용하는 파드는 노드 어피니티에 의해 선택된 노드로만 스케줄링된다. + +### 단계(Phase) + +볼륨은 다음 단계 중 하나이다. + +* Available(사용 가능) -– 아직 클레임에 바인딩되지 않은 사용할 수 있는 리소스 +* Bound(바인딩) –- 볼륨이 클레임에 바인딩됨 +* Released(릴리스) –- 클레임이 삭제되었지만 클러스터에서 아직 리소스를 반환하지 않음 +* Failed(실패) –- 볼륨이 자동 반환에 실패함 + +CLI는 PV에 바인딩된 PVC의 이름을 표시한다. + +## 퍼시스턴트볼륨클레임 + +각 PVC에는 스펙과 상태(클레임의 명세와 상태)가 포함된다. +퍼시스턴트볼륨클레임 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 +한다. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: myclaim +spec: + accessModes: + - ReadWriteOnce + volumeMode: Filesystem + resources: + requests: + storage: 8Gi + storageClassName: slow + selector: + matchLabels: + release: "stable" + matchExpressions: + - {key: environment, operator: In, values: [dev]} +``` + +### 접근 모드 + +클레임은 특정 접근 모드로 저장소를 요청할 때 볼륨과 동일한 규칙을 사용한다. + +### 볼륨 모드 + +클레임은 볼륨과 동일한 규칙을 사용하여 파일시스템 또는 블록 장치로 볼륨을 사용함을 나타낸다. + +### 리소스 + +파드처럼 클레임은 특정 수량의 리소스를 요청할 수 있다. 이 경우는 스토리지에 대한 요청이다. 동일한 [리소스 모델](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)이 볼륨과 클레임 모두에 적용된다. + +### 셀렉터 + +클레임은 볼륨 셋을 추가로 필터링하기 위해 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 지정할 수 있다. 레이블이 셀렉터와 일치하는 볼륨만 클레임에 바인딩할 수 있다. 셀렉터는 두 개의 필드로 구성될 수 있다. + +* `matchLabels` - 볼륨에 이 값의 레이블이 있어야함 +* `matchExpressions` - 키, 값의 목록, 그리고 키와 값에 관련된 연산자를 지정하여 만든 요구 사항 목록. 유효한 연산자에는 In, NotIn, Exists 및 DoesNotExist가 있다. + +`matchLabels` 및 `matchExpressions`의 모든 요구 사항이 AND 조건이다. 일치하려면 모두 충족해야 한다. + +### 클래스 + +클레임은 `storageClassName` 속성을 사용하여 +[스토리지클래스](/docs/concepts/storage/storage-classes/)의 이름을 지정하여 +특정 클래스를 요청할 수 있다. +요청된 클래스의 PV(PVC와 동일한 `storageClassName`을 갖는 PV)만 PVC에 +바인딩될 수 있다. + +PVC는 반드시 클래스를 요청할 필요는 없다. `storageClassName`이 `""`로 설정된 +PVC는 항상 클래스가 없는 PV를 요청하는 것으로 해석되므로 +클래스가 없는 PV(어노테이션이 없거나 `""`와 같은 하나의 셋)에만 바인딩될 수 +있다. `storageClassName`이 없는 PVC는 +[`DefaultStorageClass` 어드미션 플러그인](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)이 +켜져 있는지 여부에 따라 동일하지 않으며 +클러스터에 따라 다르게 처리된다. + +* 어드미션 플러그인이 켜져 있으면 관리자가 기본 스토리지클래스를 지정할 수 있다. + `storageClassName`이 없는 모든 PVC는 해당 기본값의 PV에만 바인딩할 수 있다. 기본 + 스토리지클래스 지정은 스토리지클래스 오브젝트에서 어노테이션 + `storageclass.kubernetes.io/is-default-class`를 `true`로 + 설정하여 수행된다. 관리자가 기본값을 지정하지 않으면 어드미션 플러그인이 꺼져 있는 것처럼 + 클러스터가 PVC 생성에 응답한다. 둘 이상의 기본값이 지정된 경우 어드미션 + 플러그인은 모든 PVC 생성을 + 금지한다. +* 어드미션 플러그인이 꺼져 있으면 기본 스토리지클래스에 대한 기본값 자체가 없다. + `storageClassName`이 없는 모든 PVC는 클래스가 없는 PV에만 바인딩할 수 있다. 이 경우 + `storageClassName`이 없는 PVC는 `storageClassName`이 `""`로 설정된 PVC와 + 같은 방식으로 처리된다. + +설치 방법에 따라 설치 중에 애드온 관리자가 기본 스토리지클래스를 쿠버네티스 클러스터에 +배포할 수 있다. + +PVC가 스토리지클래스를 요청하는 것 외에도 `selector`를 지정하면 요구 사항들이 +AND 조건으로 동작한다. 요청된 클래스와 요청된 레이블이 있는 PV만 PVC에 +바인딩될 수 있다. + +{{< note >}} +현재 비어 있지 않은 `selector`가 있는 PVC에는 PV를 동적으로 프로비저닝할 수 없다. +{{< /note >}} + +이전에는 `volume.beta.kubernetes.io/storage-class` 어노테이션이 `storageClassName` +속성 대신 사용되었다. 이 어노테이션은 아직까지는 사용할 수 있지만, +향후 쿠버네티스 릴리스에서는 지원되지 않는다. + +## 볼륨으로 클레임하기 + +클레임을 볼륨으로 사용해서 파드가 스토리지에 접근한다. 클레임은 클레임을 사용하는 파드와 동일한 네임스페이스에 있어야 한다. 클러스터는 파드의 네임스페이스에서 클레임을 찾고 이를 사용하여 클레임과 관련된 퍼시스턴트볼륨을 얻는다. 그런 다음 볼륨이 호스트와 파드에 마운트된다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: myfrontend + image: nginx + volumeMounts: + - mountPath: "/var/www/html" + name: mypd + volumes: + - name: mypd + persistentVolumeClaim: + claimName: myclaim +``` + +### 네임스페이스에 대한 참고 사항 + +퍼시스턴트볼륨 바인딩은 배타적이며, 퍼시스턴트볼륨클레임은 네임스페이스 오브젝트이므로 "다중" 모드(`ROX`, `RWX`)를 사용한 클레임은 하나의 네임스페이스 내에서만 가능하다. + +## 원시 블록 볼륨 지원 + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +다음 볼륨 플러그인에 해당되는 경우 동적 프로비저닝을 포함하여 원시 블록 볼륨을 +지원한다. + +* AWSElasticBlockStore +* AzureDisk +* CSI +* FC (파이버 채널) +* GCEPersistentDisk +* iSCSI +* Local volume +* OpenStack Cinder +* RBD (Ceph Block Device) +* VsphereVolume + +### 원시 블록 볼륨을 사용하는 퍼시스턴트볼륨 {#persistent-volume-using-a-raw-block-volume} + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: block-pv +spec: + capacity: + storage: 10Gi + accessModes: + - ReadWriteOnce + volumeMode: Block + persistentVolumeReclaimPolicy: Retain + fc: + targetWWNs: ["50060e801049cfd1"] + lun: 0 + readOnly: false +``` +### 원시 블록 볼륨을 요청하는 퍼시스턴트볼륨클레임 {#persistent-volume-claim-requesting-a-raw-block-volume} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: block-pvc +spec: + accessModes: + - ReadWriteOnce + volumeMode: Block + resources: + requests: + storage: 10Gi +``` + +### 컨테이너에 원시 블록 장치 경로를 추가하는 파드 명세 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod-with-block-volume +spec: + containers: + - name: fc-container + image: fedora:26 + command: ["/bin/sh", "-c"] + args: [ "tail -f /dev/null" ] + volumeDevices: + - name: data + devicePath: /dev/xvda + volumes: + - name: data + persistentVolumeClaim: + claimName: block-pvc +``` + +{{< note >}} +파드에 대한 원시 블록 장치를 추가할 때 마운트 경로 대신 컨테이너에 장치 경로를 지정한다. +{{< /note >}} + +### 블록 볼륨 바인딩 + +사용자가 퍼시스턴트볼륨클레임 스펙에서 `volumeMode` 필드를 사용하여 이를 나타내는 원시 블록 볼륨을 요청하는 경우 바인딩 규칙은 스펙의 일부분으로 이 모드를 고려하지 않은 이전 릴리스에 비해 약간 다르다. +사용자와 관리자가 원시 블록 장치를 요청하기 위해 지정할 수 있는 가능한 조합의 표가 아래 나열되어 있다. 이 테이블은 볼륨이 바인딩되는지 여부를 나타낸다. +정적 프로비저닝된 볼륨에 대한 볼륨 바인딩 매트릭스이다. + +| PV volumeMode | PVC volumeMode | Result | +| --------------|:---------------:| ----------------:| +| 지정되지 않음 | 지정되지 않음 | BIND | +| 지정되지 않음 | Block | NO BIND | +| 지정되지 않음 | Filesystem | BIND | +| Block | 지정되지 않음 | NO BIND | +| Block | Block | BIND | +| Block | Filesystem | NO BIND | +| Filesystem | Filesystem | BIND | +| Filesystem | Block | NO BIND | +| Filesystem | 지정되지 않음 | BIND | + +{{< note >}} +알파 릴리스에서는 정적으로 프로비저닝된 볼륨만 지원된다. 관리자는 원시 블록 장치로 작업할 때 이러한 값을 고려해야 한다. +{{< /note >}} + +## 볼륨 스냅샷 및 스냅샷 지원에서 볼륨 복원 + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +CSI 볼륨 플러그인만 지원하도록 볼륨 스냅샷 기능이 추가되었다. 자세한 내용은 [볼륨 스냅샷](/docs/concepts/storage/volume-snapshots/)을 참고한다. + +볼륨 스냅샷 데이터 소스에서 볼륨 복원을 지원하려면 apiserver와 controller-manager에서 +`VolumeSnapshotDataSource` 기능 게이트를 활성화한다. + +### 볼륨 스냅샷에서 퍼시스턴트볼륨클레임 생성 {#create-persistent-volume-claim-from-volume-snapshot} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: restore-pvc +spec: + storageClassName: csi-hostpath-sc + dataSource: + name: new-snapshot-test + kind: VolumeSnapshot + apiGroup: snapshot.storage.k8s.io + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +## 볼륨 복제 + +[볼륨 복제](/docs/concepts/storage/volume-pvc-datasource/)는 CSI 볼륨 플러그인만 사용할 수 있다. + +### 기존 pvc에서 퍼시스턴트볼륨클레임 생성 {#create-persistent-volume-claim-from-an-existing-pvc} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: cloned-pvc +spec: + storageClassName: my-csi-plugin + dataSource: + name: existing-src-pvc-name + kind: PersistentVolumeClaim + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +## 포터블 구성 작성 + +광범위한 클러스터에서 실행되고 퍼시스턴트 스토리지가 필요한 +구성 템플릿 또는 예제를 작성하는 경우 다음 패턴을 사용하는 것이 좋다. + +- 구성 번들(디플로이먼트, 컨피그맵 등)에 퍼시스턴트볼륨클레임 + 오브젝트를 포함시킨다. +- 구성을 인스턴스화 하는 사용자에게 퍼시스턴트볼륨을 생성할 권한이 없을 수 있으므로 + 퍼시스턴트볼륨 오브젝트를 구성에 포함하지 않는다. +- 템플릿을 인스턴스화 할 때 스토리지 클래스 이름을 제공하는 옵션을 + 사용자에게 제공한다. + - 사용자가 스토리지 클래스 이름을 제공하는 경우 해당 값을 + `permanentVolumeClaim.storageClassName` 필드에 입력한다. + 클러스터에서 관리자가 스토리지클래스를 활성화한 경우 + PVC가 올바른 스토리지 클래스와 일치하게 된다. + - 사용자가 스토리지 클래스 이름을 제공하지 않으면 + `permanentVolumeClaim.storageClassName` 필드를 nil로 남겨둔다. + 그러면 클러스터에 기본 스토리지클래스가 있는 사용자에 대해 PV가 자동으로 프로비저닝된다. + 많은 클러스터 환경에 기본 스토리지클래스가 설치되어 있거나 관리자가 + 고유한 기본 스토리지클래스를 생성할 수 있다. +- 도구(tooling)에서 일정 시간이 지나도 바인딩되지 않는 PVC를 관찰하여 사용자에게 + 노출시킨다. 이는 클러스터가 동적 스토리지를 지원하지 + 않거나(이 경우 사용자가 일치하는 PV를 생성해야 함), + 클러스터에 스토리지 시스템이 없음을 나타낸다(이 경우 + 사용자는 PVC가 필요한 구성을 배포할 수 없음). +{{% /capture %}} + {{% capture whatsnext %}} + +* [퍼시스턴트볼륨 생성](/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) 읽기 + +### 참고 + +* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) +* [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) +{{% /capture %}} diff --git a/content/ko/docs/concepts/storage/volume-pvc-datasource.md b/content/ko/docs/concepts/storage/volume-pvc-datasource.md index 92ea37f8cc..b58b882d6d 100644 --- a/content/ko/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ko/docs/concepts/storage/volume-pvc-datasource.md @@ -6,7 +6,6 @@ weight: 30 {{% capture overview %}} -{{< feature-state for_k8s_version="v1.16" state="beta" >}} 이 문서에서는 쿠버네티스의 기존 CSI 볼륨 복제의 개념을 설명한다. [볼륨] (/ko/docs/concepts/storage/volumes)을 숙지하는 것을 추천한다. @@ -32,6 +31,7 @@ weight: 30 * 복제는 동일한 스토리지 클래스 내에서만 지원된다. - 대상 볼륨은 소스와 동일한 스토리지 클래스여야 한다. - 기본 스토리지 클래스를 사용할 수 있으며, 사양에 storageClassName을 생략할 수 있다. +* 동일한 VolumeMode 설정을 사용하는 두 볼륨에만 복제를 수행할 수 있다(블록 모드 볼륨을 요청하는 경우에는 반드시 소스도 블록 모드여야 한다). ## 프로비저닝 diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 95395f7587..9d79a5ff13 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -1327,19 +1327,13 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면 #### CSI 원시(raw) 블록 볼륨 지원 -{{< feature-state for_k8s_version="v1.14" state="beta" >}} +{{< feature-state for_k8s_version="v1.18" state="stable" >}} -1.11 버전부터 CSI는 이전 버전의 쿠버네티스에서 도입된 원시 -블록 볼륨 기능에 의존하는 원시 블록 볼륨에 대한 지원을 -도입했다. 이 기능을 사용하면 외부 CSI 드라이버가 있는 벤더들이 쿠버네티스 -워크로드에서 원시 블록 볼륨 지원을 구현할 수 있다. +외부 CSI 드라이버가 있는 벤더들은 쿠버네티스 워크로드에서 원시(raw) 블록 볼륨 +지원을 구현할 수 있다. -CSI 블록 볼륨은 기능 게이트로 지원하지만, 기본적으로 활성화되어있다. 이 -기능을 위해 활성화 되어야하는 두개의 기능 게이트는 `BlockVolume` 과 -`CSIBlockVolume` 이다. - -[원시 블록 볼륨 지원으로 PV/PVC 설정](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support) -방법을 알아본다. +CSI 설정 변경 없이 평소와 같이 +[원시 블록 볼륨 지원으로 PV/PVC 설정](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)을 할 수 있다. #### CSI 임시(ephemeral) 볼륨 diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 4bbcf22ebb..b72607d41a 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -14,12 +14,7 @@ _크론 잡은_ 시간 기반의 일정에 따라 [잡](/ko/docs/concepts/worklo {{< caution >}} -모든 **크론잡** `일정:` 시간은 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} -의 시간대를 기준으로 한다. - -컨트롤 플레인이 파드 또는 베어 컨테이너에서 kube-controller-manager를 -실행하는 경우 kube-controller-manager 컨테이너의 설정된 시간대는 크론 잡 컨트롤러가 -사용하는 시간대로 설정한다. +모든 **크론잡** `일정:` 시간은 UTC로 표시된다. {{< /caution >}} 크론잡 리소스에 대한 매니페스트를 생성할때에는 제공하는 이름이 diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 2d9097c718..810b750a49 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -61,7 +61,7 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 * `template` 필드에는 다음 하위 필드가 포함되어있다. * 파드는 `labels` 필드를 사용해서 `app: nginx` 이라는 레이블을 붙인다. * 파드 템플릿의 사양 또는 `.template.spec` 필드는 - 파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.7.9 버전 이미지를 실행하는 + 파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.14.2 버전 이미지를 실행하는 `nginx` 컨테이너 1개를 실행하는 것을 나타낸다. * 컨테이너 1개를 생성하고, `name` 필드를 사용해서 `nginx` 이름을 붙인다. @@ -151,15 +151,15 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 다음 단계에 따라 디플로이먼트를 업데이트한다. -1. `nginx:1.7.9` 이미지 대신 `nginx:1.9.1` 이미지를 사용하도록 nginx 파드를 업데이트 한다. +1. `nginx:1.14.2` 이미지 대신 `nginx:1.16.1` 이미지를 사용하도록 nginx 파드를 업데이트 한다. ```shell - kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 + kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 ``` 또는 간단하게 다음의 명령어를 사용한다. ```shell - kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record + kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record ``` 이와 유사하게 출력된다. @@ -167,7 +167,7 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 deployment.apps/nginx-deployment image updated ``` - 대안으로 디플로이먼트를 `edit` 해서 `.spec.template.spec.containers[0].image` 를 `nginx:1.7.9` 에서 `nginx:1.9.1` 로 변경한다. + 대안으로 디플로이먼트를 `edit` 해서 `.spec.template.spec.containers[0].image` 를 `nginx:1.14.2` 에서 `nginx:1.16.1` 로 변경한다. ```shell kubectl edit deployment.v1.apps/nginx-deployment @@ -263,7 +263,7 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 Labels: app=nginx Containers: nginx: - Image: nginx:1.9.1 + Image: nginx:1.16.1 Port: 80/TCP Environment: Mounts: @@ -304,11 +304,11 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 스케일 업하기 시작한다. 그리고 이전에 스케일 업 하던 레플리카셋에 롤오버 한다. --이것은 기존 레플리카셋 목록에 추가하고 스케일 다운을 할 것이다. -예를 들어 디플로이먼트로 `nginx:1.7.9` 레플리카를 5개 생성을 한다. -하지만 `nginx:1.7.9` 레플리카 3개가 생성되었을 때 디플로이먼트를 업데이트해서 `nginx:1.9.1` +예를 들어 디플로이먼트로 `nginx:1.14.2` 레플리카를 5개 생성을 한다. +하지만 `nginx:1.14.2` 레플리카 3개가 생성되었을 때 디플로이먼트를 업데이트해서 `nginx:1.16.1` 레플리카 5개를 생성성하도록 업데이트를 한다고 가정한다. 이 경우 디플로이먼트는 즉시 생성된 3개의 -`nginx:1.7.9` 파드 3개를 죽이기 시작하고 `nginx:1.9.1` 파드를 생성하기 시작한다. -이것은 과정이 변경되기 전 `nginx:1.7.9` 레플리카 5개가 +`nginx:1.14.2` 파드 3개를 죽이기 시작하고 `nginx:1.16.1` 파드를 생성하기 시작한다. +이것은 과정이 변경되기 전 `nginx:1.14.2` 레플리카 5개가 생성되는 것을 기다리지 않는다. ### 레이블 셀렉터 업데이트 @@ -345,10 +345,10 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 롤백된다는 것을 의미한다. {{< /note >}} -* 디플로이먼트를 업데이트하는 동안 이미지 이름을 `nginx:1.9.1` 이 아닌 `nginx:1.91` 로 입력해서 오타를 냈다고 가정한다. +* 디플로이먼트를 업데이트하는 동안 이미지 이름을 `nginx:1.16.1` 이 아닌 `nginx:1.161` 로 입력해서 오타를 냈다고 가정한다. ```shell - kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true + kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true ``` 이와 유사하게 출력된다. @@ -425,7 +425,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 Labels: app=nginx Containers: nginx: - Image: nginx:1.91 + Image: nginx:1.161 Port: 80/TCP Host Port: 0/TCP Environment: @@ -466,13 +466,13 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 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 + 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true + 3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true ``` `CHANGE-CAUSE` 는 수정 생성시 디플로이먼트 주석인 `kubernetes.io/change-cause` 에서 복사한다. 다음에 대해 `CHANGE-CAUSE` 메시지를 지정할 수 있다. - * 디플로이먼트에 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"` 로 주석을 단다. + * 디플로이먼트에 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` 로 주석을 단다. * `kubectl` 명령어 이용시 `--record` 플래그를 추가해서 리소스 변경을 저장한다. * 수동으로 리소스 매니페스트 편집. @@ -486,10 +486,10 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 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 + Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true Containers: nginx: - Image: nginx:1.9.1 + Image: nginx:1.16.1 Port: 80/TCP QoS Tier: cpu: BestEffort @@ -547,7 +547,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 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 + kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true Selector: app=nginx Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: RollingUpdate @@ -557,7 +557,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 Labels: app=nginx Containers: nginx: - Image: nginx:1.9.1 + Image: nginx:1.16.1 Port: 80/TCP Host Port: 0/TCP Environment: @@ -720,7 +720,7 @@ nginx-deployment-618515232 11 11 11 7m * 그런 다음 디플로이먼트의 이미지를 업데이트 한다. ```shell - kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 + kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 ``` 이와 유사하게 출력된다. diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md index c394c58ab7..dd061e5130 100644 --- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -15,10 +15,8 @@ weight: 80 {{< warning >}} 임시 컨테이너는 초기 알파 상태이며, 프로덕션 클러스터에는 -적합하지 않다. 사용자는 컨테이너 네임스페이스를 대상으로 하는 경우와 -같은 어떤 상황에서 기능이 작동하지 않을 것으로 예상해야 한다. [쿠버네티스 -사용중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라 이 알파 -기능은 향후 크게 변경되거나, 완전히 제거될 수 있다. +적합하지 않다. [쿠버네티스 사용중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라 +이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다. {{< /warning >}} {{% /capture %}} @@ -75,7 +73,11 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 공유](/docs/tasks/configure-pod-container/share-process-namespace/)를 활성화하면 다른 컨테이너 안의 프로세스를 보는데 도움이 된다. -### 예시 +임시 컨테이너를 사용해서 문제를 해결하는 예시는 +[임시 디버깅 컨테이너로 디버깅하기] +(/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)를 참조한다. + +## 임시 컨테이너 API {{< note >}} 이 섹션의 예시는 `EphemeralContainers` [기능 @@ -84,8 +86,9 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 {{< /note >}} 이 섹션의 에시는 임시 컨테이너가 어떻게 API에 나타나는지 -보여준다. 사용자는 일반적으로 자동화하는 단계의 문제 해결을 위해 `kubectl` -플러그인을 사용했을 것이다. +보여준다. 일반적으로 `kubectl alpha debug` 또는 +다른 `kubectl` [플러그인](/docs/tasks/extend-kubectl/kubectl-plugins/)을 +사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다. 임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를 사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저 @@ -177,35 +180,12 @@ Ephemeral Containers: ... ``` -사용자는 `kubectl attach` 를 사용해서 새로운 임시 컨테이너에 붙을 수 있다. +예시와 같이 `kubectl attach`, `kubectl exec`, 그리고 `kubectl logs` 를 사용해서 +다른 컨테이너와 같은 방식으로 새로운 임시 컨테이너와 +상호작용할 수 있다. ```shell kubectl attach -it example-pod -c debugger ``` -만약 프로세스 네임스페이스를 공유를 활성화하면, 사용자는 해당 파드 안의 모든 컨테이너의 프로세스를 볼 수 있다. -예를 들어, 임시 컨테이너에 붙은 이후에 디버거 컨테이너에서 `ps` 를 실행한다. - -```shell -# "디버거" 임시 컨테이너 내부 쉘에서 이것을 실행한다. -ps auxww -``` -다음과 유사하게 출력된다. -``` -PID USER TIME COMMAND - 1 root 0:00 /pause - 6 root 0:00 nginx: master process nginx -g daemon off; - 11 101 0:00 nginx: worker process - 12 101 0:00 nginx: worker process - 13 101 0:00 nginx: worker process - 14 101 0:00 nginx: worker process - 15 101 0:00 nginx: worker process - 16 101 0:00 nginx: worker process - 17 101 0:00 nginx: worker process - 18 101 0:00 nginx: worker process - 19 root 0:00 /pause - 24 root 0:00 sh - 29 root 0:00 ps auxww -``` - {{% /capture %}} 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 8ebdab2345..7bde7139a9 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 @@ -6,7 +6,7 @@ weight: 50 {{% capture overview %}} -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} +{{< feature-state for_k8s_version="v1.18" state="beta" >}} 사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다. @@ -18,11 +18,10 @@ weight: 50 ### 기능 게이트 활성화 -`EvenPodsSpread` 기능 게이트의 활성화가 되었는지 확인한다(기본적으로 1.16에서는 -비활성화되어있다). 기능 게이트의 활성화에 대한 설명은 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와** {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 -대해 `EvenPodsSpread` 기능 게이트가 활성화되어야 한다. +대해 `EvenPodsSpread` +[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어야 한다. ### 노드 레이블 @@ -184,6 +183,46 @@ spec: {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}} +### 클러스터 수준의 기본 제약 조건 + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +클러스터에 대한 기본 토폴로지 분배 제약 조건을 설정할 수 있다. 기본 +토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다. + +- `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우. +- 서비스, 레플리케이션 컨트롤러, 레플리카 셋 또는 스테이트풀 셋에 속해있는 경우. + +기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/profiles)에서 +`PodTopologySpread` 플러그인의 일부로 설정할 수 있다. +제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로 +제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러, +레플리카 셋 또는 스테이트풀 셋에서 계산한다. + +예시 구성은 다음과 같다. + +```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 >}} +기본 스케줄링 제약 조건에 의해 생성된 점수는 +[`DefaultPodTopologySpread` 플러그인](/docs/reference/scheduling/profiles/#scheduling-plugins)에 +의해 생성된 점수와 충돌 할 수 있다. +`PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서 +이 플러그인을 비활성화 하는 것을 권장한다. +{{< /note >}} + ## 파드어피니티(PodAffinity)/파드안티어피니티(PodAntiAffinity)와의 비교 쿠버네티스에서 "어피니티(Affinity)"와 관련된 지침은 파드가 @@ -201,9 +240,9 @@ spec: ## 알려진 제한사항 -1.16을 기준으로 이 기능은 알파(Alpha)이며, 몇 가지 알려진 제한사항이 있다. +1.18을 기준으로 이 기능은 베타(Beta)이며, 몇 가지 알려진 제한사항이 있다. -- `Deployment` 를 스케일링 다운하면 그 결과로 파드의 분포가 불균형이 될 수 있다. +- 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형이 될 수 있다. - 파드와 일치하는 테인트(taint)가 된 노드가 존중된다. [이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다. {{% /capture %}} diff --git a/content/ko/docs/home/_index.md b/content/ko/docs/home/_index.md index 1a12f2028a..94927fbfc1 100644 --- a/content/ko/docs/home/_index.md +++ b/content/ko/docs/home/_index.md @@ -3,7 +3,7 @@ title: 쿠버네티스 문서 noedit: true cid: docsHome layout: docsportal_home -class: gridPage +class: gridPage gridPageHome linkTitle: "홈" main_menu: true weight: 10 @@ -40,7 +40,7 @@ cards: button: "태스크 보기" button_path: "/ko/docs/tasks" - name: training - title: 교육" + title: "교육" description: "공인 쿠버네티스 인증을 획득하고 클라우드 네이티브 프로젝트를 성공적으로 수행하세요!" button: "교육 보기" button_path: "/training" diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index ada3246855..a9ce09b988 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -36,13 +36,15 @@ content_template: templates/concept * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. * [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. -## 설정 레퍼런스 +## 컴포넌트 레퍼런스 * [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 노드에서 구동되는 주요한 *노드 에이전트*. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다. * [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API. * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬. * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다. * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러. + * [kube-scheduler 정책](/docs/reference/scheduling/policies) + * [kube-scheduler 프로파일](/docs/reference/scheduling/profiles) ## 설계 문서 diff --git a/content/ko/docs/reference/glossary/managed-service.md b/content/ko/docs/reference/glossary/managed-service.md new file mode 100644 index 0000000000..282bc7e9d6 --- /dev/null +++ b/content/ko/docs/reference/glossary/managed-service.md @@ -0,0 +1,18 @@ +--- +title: 매니지드 서비스 +id: managed-service +date: 2018-04-12 +full_link: +short_description: > + 타사 공급자가 유지보수하는 소프트웨어. + +aka: + +tags: +- extension +--- + 타사 공급자가 유지보수하는 소프트웨어. + + + +매니지드 서비스의 몇 가지 예시로 AWS EC2, Azure SQL Database 그리고 GCP Pub/Sub이 있으나, 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품이 될 수 있다. [서비스 카탈로그](/docs/concepts/service-catalog/)는 {{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}가 제공하는 매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다. diff --git a/content/ko/docs/reference/glossary/replication-controller.md b/content/ko/docs/reference/glossary/replication-controller.md index 30f2aabf94..352529f4ce 100755 --- a/content/ko/docs/reference/glossary/replication-controller.md +++ b/content/ko/docs/reference/glossary/replication-controller.md @@ -1,19 +1,25 @@ --- -title: 레플리케이션 컨트롤러(Replication Controller) +title: 레플리케이션 컨트롤러(ReplicationController) id: replication-controller date: 2018-04-12 full_link: short_description: > - 특정 수의 파드 인스턴스가 항상 동작하도록 보장하는 쿠버네티스 서비스. + (사용 중단된) 복제된 애플리케이션을 관리하는 API 오브젝트 aka: tags: - workload - core-object --- - 특정 수의 {{< glossary_tooltip text="파드" term_id="pod" >}} 인스턴스가 항상 동작하도록 보장하는 쿠버네티스 서비스. + 특정한 수의 {{< glossary_tooltip text="파드" term_id="pod" >}} 인스턴스가 +실행 중인지 확인하면서 복제된 애플리케이션을 관리하는 워크로드 리소스이다. -레플리케이션 컨트롤러는 파드에 설정된 값에 따라서, 동작하는 파드의 인스턴스를 자동으로 추가하거나 제거할 것이다. 파드가 삭제되거나 실수로 너무 많은 수의 파드가 시작된 경우, 파드가 지정된 수의 인스턴스로 돌아갈 수 있게 허용한다. +컨트롤 플레인은 일부 파드에 장애가 발생하거나, 수동으로 파드를 삭제하거나, +실수로 너무 많은 수의 파드가 시작된 경우에도 정의된 수량의 파드가 실행되도록 한다. +{{< note >}} +레플리케이션컨트롤러는 사용 중단되었다. 유사한 +것으로는 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}를 본다. +{{< /note >}} diff --git a/content/ko/docs/reference/glossary/service-catalog.md b/content/ko/docs/reference/glossary/service-catalog.md new file mode 100644 index 0000000000..25f1667853 --- /dev/null +++ b/content/ko/docs/reference/glossary/service-catalog.md @@ -0,0 +1,18 @@ +--- +title: 서비스 카탈로그(Service Catalog) +id: service-catalog +date: 2018-04-12 +full_link: +short_description: > + 쿠버네티스 클러스터 내에서 실행되는 응용 프로그램이 클라우드 공급자가 제공하는 데이터 저장소 서비스와 같은 외부 관리 소프트웨어 제품을 쉽게 사용할 수 있도록하는 확장 API이다. + +aka: +tags: +- extension +--- + 쿠버네티스 클러스터 내에서 실행되는 응용 프로그램이 클라우드 공급자가 제공하는 데이터 저장소 서비스와 같은 외부 관리 소프트웨어 제품을 쉽게 사용할 수 있도록하는 확장 API이다. + + + +서비스 생성 또는 관리에 대한 자세한 지식 없이도 {{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}를 통해 외부의 {{< glossary_tooltip text="매니지드 서비스" term_id="managed-service" >}}의 목록과 프로비전, 바인딩하는 방법을 제공한다. + diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index fe3e81d84f..5196fb724f 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -49,63 +49,6 @@ card: 운영 환경을 위한 솔루션을 평가할 때에는, 쿠버네티스 클러스터 운영에 대한 어떤 측면(또는 _추상적인 개념_)을 스스로 관리하기를 원하는지, 제공자에게 넘기기를 원하는지 고려하자. -몇 가지 가능한 쿠버네티스 클러스터의 추상적인 개념은 {{< glossary_tooltip text="애플리케이션" term_id="applications" >}}, {{< glossary_tooltip text="데이터 플레인" term_id="data-plane" >}}, {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}, {{< glossary_tooltip text="클러스터 인프라스트럭처" term_id="cluster-infrastructure" >}}, 및 {{< glossary_tooltip text="클러스터 운영" term_id="cluster-operations" >}}이다. - -다음의 다이어그램은 쿠버네티스 클러스터에 대해 가능한 추상적인 개념을 나열하고, 각 추상적인 개념을 사용자 스스로 관리하는지 제공자에 의해 관리되는지를 보여준다. - -운영 환경 솔루션![운영 환경 솔루션](/images/docs/KubernetesSolutions.svg) - -{{< table caption="제공자와 솔루션을 나열한 운영 환경 솔루션 표." >}} -다음 운영 환경 솔루션 표는 제공자와 솔루션을 나열한다. - -|제공자 | 매니지드 | 턴키 클라우드 | 온-프렘(on-prem) 데이터센터 | 커스텀 (클라우드) | 커스텀 (온-프레미스 VMs)| 커스텀 (베어 메탈) | -| --------- | ------ | ------ | ------ | ------ | ------ | ----- | -| [Agile Stacks](https://www.agilestacks.com/products/kubernetes)| | ✔ | ✔ | | | -| [Alibaba Cloud](https://www.alibabacloud.com/product/kubernetes)| | ✔ | | | | -| [Amazon](https://aws.amazon.com) | [Amazon EKS](https://aws.amazon.com/eks/) |[Amazon EC2](https://aws.amazon.com/ec2/) | | | | -| [AppsCode](https://appscode.com/products/pharmer/) | ✔ | | | | | -| [APPUiO](https://appuio.ch/)  | ✔ | ✔ | ✔ | | | | -| [Banzai Cloud Pipeline Kubernetes Engine (PKE)](https://banzaicloud.com/products/pke/) | | ✔ | | ✔ | ✔ | ✔ | -| [CenturyLink Cloud](https://www.ctl.io/) | | ✔ | | | | -| [Cisco Container Platform](https://cisco.com/go/containers) | | | ✔ | | | -| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | ✔ |✔ | -| [CloudStack](https://cloudstack.apache.org/) | | | | | ✔| -| [Canonical](https://ubuntu.com/kubernetes) | ✔ | ✔ | ✔ | ✔ |✔ | ✔ -| [Containership](https://containership.io) | ✔ |✔ | | | | -| [D2iQ](https://d2iq.com/) | | [Kommander](https://docs.d2iq.com/ksphere/kommander/) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | -| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔ -| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | | -| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔ -| [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ | ✔ | ✔ | [사용자 정의 확장](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) | -| [Giant Swarm](https://www.giantswarm.io/) | ✔ | ✔ | ✔ | | -| [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | | -| [Hidora](https://hidora.com/) | ✔ | ✔| ✔ | | | | | | | | -| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | | -| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | | -| [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | | -| [KubeOne](https://kubeone.io/) | | ✔ | ✔ | ✔ | ✔ | ✔ | -| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | -| [KubeSail](https://kubesail.com/) | ✔ | | | | | -| [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ | -| [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ | -| [Microsoft Azure](https://azure.microsoft.com) | [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/) | | | | | -| [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) | | | ✔ | | | -| [NetApp Kubernetes Service (NKS)](https://cloud.netapp.com/kubernetes-service) | ✔ | ✔ | ✔ | | | -| [Nirmata](https://www.nirmata.com/) | | ✔ | ✔ | | | -| [Nutanix](https://www.nutanix.com/en) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | | | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization) | -| [OpenNebula](https://www.opennebula.org) |[OpenNebula Kubernetes](https://marketplace.opennebula.systems/docs/service/kubernetes.html) | | | | | -| [OpenShift](https://www.openshift.com) |[OpenShift Dedicated](https://www.openshift.com/products/dedicated/) and [OpenShift Online](https://www.openshift.com/products/online/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) |[OpenShift Container Platform](https://www.openshift.com/products/container-platform/) -| [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | ✔ | ✔ | | | | -| [oVirt](https://www.ovirt.org/) | | | | | ✔ | -| [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | | | -| [Platform9](https://platform9.com/) | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | ✔ | ✔ | ✔ -| [Rancher](https://rancher.com/) | | [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/) | | [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) | | [k3s](https://k3s.io/) -| [Supergiant](https://supergiant.io/) | |✔ | | | | -| [SUSE](https://www.suse.com/) | | ✔ | | | | -| [SysEleven](https://www.syseleven.io/) | ✔ | | | | | -| [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | ✔ | ✔ | | | ✔ | -| [VEXXHOST](https://vexxhost.com/) | ✔ | ✔ | | | | -| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) -| [Z.A.R.V.I.S.](https://zarvis.ai/) | ✔ | | | | | | +[공인 쿠버네티스](https://github.com/cncf/k8s-conformance/#certified-kubernetes) 공급자의 목록과 "[파트너](https://kubernetes.io/partners/#conformance)"를 참조한다. {{% /capture %}} diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md index f6af768b68..82d3f4f26d 100644 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -183,23 +183,25 @@ Minikube는 또한 "minikube" 컨텍스트를 생성하고 이를 kubectl의 기 minikube start --kubernetes-version {{< param "fullversion" >}} ``` #### VM 드라이버 지정하기 -`minikube start` 코멘드에 `--vm-driver=` 플래그를 추가해서 VM 드라이버를 변경할 수 있다. +`minikube start` 코멘드에 `--driver=` 플래그를 추가해서 VM 드라이버를 변경할 수 있다. 코멘드를 예를 들면 다음과 같다. ```shell -minikube start --vm-driver= +minikube start --driver= ``` Minikube는 다음의 드라이버를 지원한다. {{< note >}} - 지원되는 드라이버와 플러그인 설치 방법에 대한 보다 상세한 정보는 [드라이버](https://git.k8s.io/minikube/docs/drivers.md)를 참조한다. + 지원되는 드라이버와 플러그인 설치 방법에 대한 보다 상세한 정보는 [드라이버](https://minikube.sigs.k8s.io/docs/reference/drivers/)를 참조한다. {{< /note >}} * virtualbox * vmwarefusion -* kvm2 ([드라이버 설치](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver)) -* hyperkit ([드라이버 설치](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver)) -* hyperv ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) +* docker (EXPERIMENTAL) +* kvm2 ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/)) +* hyperkit ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/)) +* hyperv ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/)) 다음 IP는 동적이며 변경할 수 있다. `minikube ip`로 알아낼 수 있다. -* vmware ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver) +* 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 >}} diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 4429049bfb..0331440eac 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -62,7 +62,7 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다. ## Docker 각 머신들에 대해서, Docker를 설치한다. -버전 19.03.4가 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다. +버전 19.03.8이 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다. 쿠버네티스 릴리스 노트를 통해서, 최신에 검증된 Docker 버전의 지속적인 파악이 필요하다. 시스템에 Docker를 설치하기 위해서 아래의 커맨드들을 사용한다. @@ -86,9 +86,9 @@ add-apt-repository \ ## Docker CE 설치. apt-get update && apt-get install -y \ - containerd.io=1.2.10-3 \ - docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \ - docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) + containerd.io=1.2.13-1 \ + docker-ce=5:19.03.8~3-0~ubuntu-$(lsb_release -cs) \ + docker-ce-cli=5:19.03.8~3-0~ubuntu-$(lsb_release -cs) # 데몬 설정. cat > /etc/docker/daemon.json <}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} +{{< tab name="Debian" codelang="bash" >}} +# Debian 개발 배포본(Unstable/Sid) +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - -# 선행 조건 설치 -apt-get update -apt-get install -y software-properties-common +# Debian Testing +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - -add-apt-repository ppa:projectatomic/ppa -apt-get update +# Debian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - + +# Raspbian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - # CRI-O 설치 -apt-get install -y cri-o-1.15 - +sudo apt-get install cri-o-1.17 {{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +{{< tab name="Ubuntu 18.04, 19.04 and 19.10" codelang="bash" >}} +# 리포지터리 설치 +. /etc/os-release +sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - +sudo apt-get update + +# CRI-O 설치 +sudo apt-get install cri-o-1.17 +{{< /tab >}} + +{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} # 선행 조건 설치 yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/ # CRI-O 설치 yum install --nogpgcheck -y cri-o +{{< tab name="openSUSE Tumbleweed" codelang="bash" >}} +sudo zypper install cri-o {{< /tab >}} {{< /tabs >}} @@ -304,4 +324,4 @@ kubeadm을 사용하는 경우에도 마찬가지로, 수동으로 자세한 정보는 [Frakti 빠른 시작 가이드](https://github.com/kubernetes/frakti#quickstart)를 참고한다. -{{% /capture %}} \ No newline at end of file +{{% /capture %}} diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md index c12f9e68a3..c1ba8d3646 100644 --- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -19,7 +19,7 @@ weight: 75 ## 시작하기 전에 -* [윈도우 서버에서 운영하는 마스터와 워커 노드](../user-guide-windows-nodes)를 포함한 쿠버네티스 클러스터를 생성한다. +* [윈도우 서버에서 운영하는 마스터와 워커 노드](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를 포함한 쿠버네티스 클러스터를 생성한다. * 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 모두 비슷한 방식이라는 것이 중요하다. [Kubectl 커맨드](/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다. 아래 단원의 예시는 윈도우 컨테이너를 경험하기 위해 제공한다. ## 시작하기: 윈도우 컨테이너 배포하기 diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md deleted file mode 100644 index e6720c9b0b..0000000000 --- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md +++ /dev/null @@ -1,354 +0,0 @@ ---- -reviewers: -title: 쿠버네티스에서 윈도우 노드 추가 가이드 -min-kubernetes-server-version: v1.14 -content_template: templates/tutorial -weight: 70 ---- - -{{% capture overview %}} - -쿠버네티스 플랫폼은 이제 리눅스와 윈도우 컨테이너 모두 운영할 수 있다. 윈도우 노드도 클러스터에 등록할 수 있다. 이 페이지에서는 어떻게 하나 또는 그 이상의 윈도우 노드를 클러스터에 등록할 수 있는지 보여준다. -{{% /capture %}} - - -{{% capture prerequisites %}} - -* 윈도우 컨테이너를 호스트하는 윈도우 노드를 구성하려면 [윈도우 서버 2019 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)를 소유해야 한다. 클러스터를 위해서 소속 기관의 라이선스를 사용하거나, Microsoft, 리셀러로 부터 취득할 수 있으며, GCP, AWS, Azure와 같은 주요 클라우드 제공자의 마켓플레이스를 통해 윈도우 서버를 운영하는 가상머신을 프로비저닝하여 취득할 수도 있다. [사용시간이 제한된 시험판](https://www.microsoft.com/en-us/cloud-platform/windows-server-trial)도 활용 가능하다. - -* 컨트롤 플레인에 접근할 수 있는 리눅스 기반의 쿠버네티스 클러스터를 구축한다.(몇 가지 예시는 [kubeadm으로 단일 컨트롤플레인 클러스터 만들기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), [AKS Engine](/docs/setup/production-environment/turnkey/azure/), [GCE](/docs/setup/production-environment/turnkey/gce/), [AWS](/docs/setup/production-environment/turnkey/aws/)를 포함한다) - -{{% /capture %}} - - -{{% capture objectives %}} - -* 윈도우 노드를 클러스터에 등록하기 -* 리눅스와 윈도우에서 동작하는 파드와 서비스가 상호 간에 통신할 수 있게 네트워크를 구성하기 - -{{% /capture %}} - - -{{% capture lessoncontent %}} - -## 시작하기: 사용자 클러스터에 윈도우 노드 추가하기 - -### IP 주소 체계 설계하기 - -쿠버네티스 클러스터 관리를 위해 실수로 네트워크 충돌을 일으키지 않도록 IP 주소에 대해 신중히 설계해야 한다. 이 가이드는 [쿠버네티스 네트워킹 개념](/docs/concepts/cluster-administration/networking/)에 익숙하다 가정한다. - -클러스터를 배포하려면 다음 주소 공간이 필요하다. - -| 서브넷 / 주소 범위 | 비고 | 기본값 | -| --- | --- | --- | -| 서비스 서브넷 | 라우트 불가한 순수한 가상 서브넷으로 네트워크 토플로지에 관계없이 파드에서 서비스로 단일화된 접근을 제공하기 위해 사용한다. 서비스 서브넷은 노드에서 실행 중인 `kube-proxy`에 의해서 라우팅 가능한 주소 공간으로(또는 반대로) 번역된다. | 10.96.0.0/12 | -| 클러스터 서브넷 | 클러스터 내에 모든 파드에 사용되는 글로벌 서브넷이다. 각 노드에는 파드가 사용하기 위한 /24 보다 작거나 같은 서브넷을 할당한다. 서브넷은 클러스터 내에 모든 파드를 수용할 수 있을 정도로 충분히 큰 값이어야 한다. *최소 서브넷*의 크기를 계산하려면: `(노드의 개수) + (노드의 개수 * 구성하려는 노드 당 최대 파드 개수)`. 예: 노드 당 100개 파드인 5 노드짜리 클러스터 = `(5) + (5 * 100) = 505.` | 10.244.0.0/16 | -| 쿠버네티스 DNS 서비스 IP | DNS 확인 및 클러스터 서비스 검색에 사용되는 서비스인 `kube-dns`의 IP 주소이다. | 10.96.0.10 | - -클러스터에 IP 주소를 얼마나 할당해야 할지 결정하기 위해 '쿠버네티스에서 윈도우 컨테이너: 지원되는 기능: 네트워킹'에서 소개한 네트워킹 선택 사항을 검토하자. - -### 윈도우에서 실행되는 구성 요소 - -쿠버네티스 컨트롤 플레인이 리눅스 노드에서 운영되는 반면, 다음 요소는 윈도우 노드에서 구성되고 운영된다. - -1. kubelet -2. kube-proxy -3. kubectl (선택적) -4. 컨테이너 런타임 - -v1.14 이후의 최신 바이너리를 [https://github.com/kubernetes/kubernetes/releases](https://github.com/kubernetes/kubernetes/releases)에서 받아온다. kubeadm, kubectl, kubelet, kube-proxy의 Windows-amd64 바이너리는 CHANGELOG 링크에서 찾아볼 수 있다. - -### 네트워크 구성 - -리눅스 기반의 쿠버네티스 컨트롤 플레인("마스터") 노드를 가지고 있다면 네트워킹 솔루션을 선택할 준비가 된 것이다. 이 가이드는 단순화를 위해 VXLAN 방식의 플라넬(Flannel)을 사용하여 설명한다. - -#### 리눅스 컨트롤 플레인에서 VXLAN 방식으로 플라넬 구성하기 - -1. 플라넬을 위해 쿠버네티스 마스터를 준비한다. - - 클러스터의 쿠버네티스 마스터에서 사소한 준비를 권장한다. 플라넬을 사용할 때에 iptables 체인으로 IPv4 트래픽을 브릿지할 수 있게 하는 것은 추천한다. 이는 다음 커맨드를 이용하여 수행할 수 있다. - - ```bash - sudo sysctl net.bridge.bridge-nf-call-iptables=1 - ``` - -1. 플라넬 다운로드 받고 구성하기 - - 가장 최신의 플라넬 메니페스트를 다운로드한다. - - ```bash - wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml - ``` - - VXLAN 네트워킹 벡엔드를 가능하게 하기 위해 수정할 곳은 두 곳이다. - - 아래 단계를 적용하면 `kube-flannel.yml`의 `net-conf.json`부분을 다음과 같게 된다. - - ```json - net-conf.json: | - { - "Network": "10.244.0.0/16", - "Backend": { - "Type": "vxlan", - "VNI" : 4096, - "Port": 4789 - } - } - ``` - - {{< note >}}리눅스의 플라넬과 윈도우의 플라넬이 상호운용하기 위해서 `VNI`는 반드시 4096이고, `Port`는 4789여야 한다. 다른 VNI는 곧 지원될 예정이다. [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)에서 - 이 필드의 설명 부분을 보자.{{< /note >}} - -1. `kube-flannel.yml`의 `net-conf.json` 부분을 거듭 확인하자. - 1. 클러스터 서브넷(예, "10.244.0.0/16")은 IP 주소 설계에 따라 설정되어야 한다. - * VNI 4096 은 벡엔드에 설정한다. - * Port 4789 는 벡엔드에 설정한다. - 1. `kube-flannel.yml`의 `cni-conf.json` 부분에서 네트워크 이름을 `vxlan0`로 바꾼다. - - `cni-conf.json`는 다음과 같다. - - ```json - cni-conf.json: | - { - "name": "vxlan0", - "plugins": [ - { - "type": "flannel", - "delegate": { - "hairpinMode": true, - "isDefaultGateway": true - } - }, - { - "type": "portmap", - "capabilities": { - "portMappings": true - } - } - ] - } - ``` - -1. 플라넬 매니페스트를 적용하고 확인하기 - - 플라넬 구성을 적용하자. - - ```bash - kubectl apply -f kube-flannel.yml - ``` - - 몇 분 뒤에 플라넬 파드 네트워크가 배포되었다면, 모든 파드에서 운영 중인 것을 확인할 수 있다. - - ```bash - kubectl get pods --all-namespaces - ``` - - 결과는 다음과 같다. - - ``` - NAMESPACE NAME READY STATUS RESTARTS AGE - kube-system etcd-flannel-master 1/1 Running 0 1m - kube-system kube-apiserver-flannel-master 1/1 Running 0 1m - kube-system kube-controller-manager-flannel-master 1/1 Running 0 1m - kube-system kube-dns-86f4d74b45-hcx8x 3/3 Running 0 12m - kube-system kube-flannel-ds-54954 1/1 Running 0 1m - kube-system kube-proxy-Zjlxz 1/1 Running 0 1m - kube-system kube-scheduler-flannel-master 1/1 Running 0 1m - ``` - - 플라넬 데몬셋에 노드 셀렉터가 적용되었음을 확인한다. - - ```bash - kubectl get ds -n kube-system - ``` - - 결과는 다음과 같다. 노드 셀렉터 `beta.kubernetes.io/os=linux`가 적용되었다. - - ``` - NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE - kube-flannel-ds 2 2 2 2 2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux 21d - kube-proxy 2 2 2 2 2 beta.kubernetes.io/os=linux 26d - ``` - - - -### 윈도우 워커 노드 추가하기 - -이번 단원은 맨 땅에서부터 온프레미스 클러스터에 가입하기까지 윈도우 노드 구성을 다룬다. 클러스터가 클라우드상에 있다면, [퍼블릭 클라우드 제공자 단원](#퍼블릭-클라우드-제공자)에 있는 클라우드에 특정한 가이드를 따르도록 된다. - -#### 윈도우 노드 준비하기 - -{{< note >}} -윈도우 단원에서 모든 코드 부분은 윈도우 워커 노드에서 높은 권한(Administrator)으로 파워쉘(PowerShell) 환경에서 구동한다. -{{< /note >}} - -1. 설치 및 참여(join) 스크립트가 포함된 [SIG Windows tools](https://github.com/kubernetes-sigs/sig-windows-tools) 리포지터리를 내려받는다. - ```PowerShell - [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 - Start-BitsTransfer https://github.com/kubernetes-sigs/sig-windows-tools/archive/master.zip - tar -xvf .\master.zip --strip-components 3 sig-windows-tools-master/kubeadm/v1.15.0/* - Remove-Item .\master.zip - ``` - -1. 쿠버네티스 [구성 파일](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/v1.15.0/Kubeclustervxlan.json)을 커스터마이즈한다. - - ``` - { - "Cri" : { // Contains values for container runtime and base container setup - "Name" : "dockerd", // Container runtime name - "Images" : { - "Pause" : "mcr.microsoft.com/k8s/core/pause:1.2.0", // Infrastructure container image - "Nanoserver" : "mcr.microsoft.com/windows/nanoserver:1809", // Base Nanoserver container image - "ServerCore" : "mcr.microsoft.com/windows/servercore:ltsc2019" // Base ServerCore container image - } - }, - "Cni" : { // Contains values for networking executables - "Name" : "flannel", // Name of network fabric - "Source" : [{ // Contains array of objects containing values for network daemon(s) - "Name" : "flanneld", // Name of network daemon - "Url" : "https://github.com/coreos/flannel/releases/download/v0.11.0/flanneld.exe" // Direct URL pointing to network daemon executable - } - ], - "Plugin" : { // Contains values for CNI network plugin - "Name": "vxlan" // Backend network mechanism to use: ["vxlan" | "bridge"] - }, - "InterfaceName" : "Ethernet" // Designated network interface name on Windows node to use as container network - }, - "Kubernetes" : { // Contains values for Kubernetes node binaries - "Source" : { // Contains values for Kubernetes node binaries - "Release" : "1.15.0", // Version of Kubernetes node binaries - "Url" : "https://dl.k8s.io/v1.15.0/kubernetes-node-windows-amd64.tar.gz" // Direct URL pointing to Kubernetes node binaries tarball - }, - "ControlPlane" : { // Contains values associated with Kubernetes control-plane ("Master") node - "IpAddress" : "kubemasterIP", // IP address of control-plane ("Master") node - "Username" : "localadmin", // Username on control-plane ("Master") node with remote SSH access - "KubeadmToken" : "token", // Kubeadm bootstrap token - "KubeadmCAHash" : "discovery-token-ca-cert-hash" // Kubeadm CA key hash - }, - "KubeProxy" : { // Contains values for Kubernetes network proxy configuration - "Gates" : "WinOverlay=true" // Comma-separated key-value pairs passed to kube-proxy feature gate flag - }, - "Network" : { // Contains values for IP ranges in CIDR notation for Kubernetes networking - "ServiceCidr" : "10.96.0.0/12", // Service IP subnet used by Services in CIDR notation - "ClusterCidr" : "10.244.0.0/16" // Cluster IP subnet used by Pods in CIDR notation - } - }, - "Install" : { // Contains values and configurations for Windows node installation - "Destination" : "C:\\ProgramData\\Kubernetes" // Absolute DOS path where Kubernetes will be installed on the Windows node - } -} - ``` - -{{< note >}} -사용자는 쿠버네티스 컨트롤 플레인("마스터") 노드에서 `kubeadm token create --print-join-command`를 실행해서 `ControlPlane.KubeadmToken`과 `ControlPlane.KubeadmCAHash` 필드를 위한 값을 생성할 수 있다. -{{< /note >}} - -1. 컨테이너와 쿠버네티스를 설치 (시스템 재시작 필요) - -기존에 내려받은 [KubeCluster.ps1](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/KubeCluster.ps1) 스크립트를 사용해서 쿠버네티스를 윈도우 서버 컨테이너 호스트에 설치한다. - - ```PowerShell - .\KubeCluster.ps1 -ConfigFile .\Kubeclustervxlan.json -install - ``` - 이 때 `-ConfigFile`는 쿠버네티스 구성 파일의 경로를 가리킨다. - -{{< note >}} -아래 예제에서, 우리는 오버레이 네트워킹 모드를 사용한다. 이는 [KB4489899](https://support.microsoft.com/help/4489899)를 포함한 윈도우 서버 버전 2019와 최소 쿠버네티스 v1.14 이상이 필요하다. 이 요구사항을 만족시키기 어려운 사용자는 구성 파일의 [플러그인](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/v1.15.0/Kubeclusterbridge.json#L18)으로 `bridge`를 선택하지 말고 `L2bridge` 네트워킹을 사용해야만 한다. -{{< /note >}} - - ![alt_text](../kubecluster.ps1-install.gif "KubeCluster.ps1 install output") - - -대상으로 하는 윈도우 노드에서, 본 단계는 - -1. 윈도우 서버 컨테이너 역할을 활성화(및 재시작) 한다. -1. 선택된 컨테이너 런타임을 내려받아 설치한다. -1. 필요한 컨테이너 이미지를 모두 내려받는다. -1. 쿠버네티스 바이너리를 내려받아서 `$PATH` 환경 변수에 추가한다. -1. 쿠버네티스 구성 파일에서 선택한 내용을 기반으로 CNI 플러그인을 내려받는다. -1. (선택적으로) 참여(join) 중에 컨트롤 플레인("마스터") 노드에 접속하기 위한 새로운 SSH 키를 생성한다. - - {{< note >}}또한, SSH 키 생성 단계에서 생성된 공개 SSH 키를 (리눅스) 컨트롤 플레인 노드의 `authorized_keys` 파일에 추가해야 한다. 이는 한 번만 수행하면 된다. 스크립트가 출력물의 마지막 부분에 이를 따라 할 수 있도록 단계를 출력해 준다.{{< /note >}} - -일단 설치가 완료되면, 생성된 모든 구성 파일이나 바이너리는 윈도우 노드가 참여하기 전에 수정될 수 있다. - -#### 윈도우 노드를 쿠버네티스 클러스터에 참여시키기 - -이 섹션에서는 클러스터를 구성하기 위해서 [쿠버네티스가 설치된 윈도우 노드](#윈도우-노드-준비하기)를 기존의 (리눅스) 컨트롤 플레인에 참여시키는 방법을 다룬다. - -앞서 내려받은 [KubeCluster.ps1](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/KubeCluster.ps1) 스크립트를 사용해서 윈도우 노드를 클러스터에 참여시킨다. - - ```PowerShell - .\KubeCluster.ps1 -ConfigFile .\Kubeclustervxlan.json -join - ``` - 이 때 `-ConfigFile` 쿠버네티스 구성 파일의 경로를 가리킨다. - -![alt_text](../kubecluster.ps1-join.gif "KubeCluster.ps1 join output") - -{{< note >}} -어떤 이유에서든 부트스트랩 동안이나 참여 과정에서 스크립트가 실패하면, 뒤따르는 참여 시도를 시작하기 전에 신규 PowerShell 세션을 시작해야한다. -{{< /note >}} - -본 단계는 다음의 행위를 수행한다. - -1. 컨트롤 플레인("마스터") 노드에 SSH로 접속해서 [Kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 얻어온다. -1. kubelet을 윈도우 서비스로 등록한다. -1. CNI 네트워크 플러그인을 구성한다. -1. 선택된 네트워크 인터페이스 상에서 HNS 네트워크를 생성한다. - {{< note >}} - 이는 vSwitch가 생성되는 동안 몇 초간의 네트워크 순단현상을 야기할 수 있다. - {{< /note >}} -1. (vxlan 플러그인을 선택한 경우) 오버레이 트래픽을 위해서 인바운드(inbound) 방화벽의 UDP 포트 4789를 열어준다. -1. flanneld를 윈도우 서비스로 등록한다. -1. kube-proxy를 윈도우 서비스로 등록한다. - -이제 클러스터에서 다음의 명령을 실행해서 윈도우 노드를 볼 수 있다. - -```bash -kubectl get nodes -``` - -#### 윈도우 노드를 쿠버네티스 클러스터에서 제거하기 -이 섹션에서는 윈도우 노드를 쿠버네티스 클러스터에서 제거하는 방법을 다룬다. - -앞서 내려받은 [KubeCluster.ps1](https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/KubeCluster.ps1) 스크립트를 사용해서 클러스터에서 윈도우 노드를 제거한다. - - ```PowerShell - .\KubeCluster.ps1 -ConfigFile .\Kubeclustervxlan.json -reset - ``` - 이 때 `-ConfigFile` 쿠버네티스 구성 파일의 경로를 가리킨다. - -![alt_text](../kubecluster.ps1-reset.gif "KubeCluster.ps1 reset output") - -본 단계는 다음의 행위를 대상이되는 윈도우 노드에서 수행한다. - -1. 윈도우 노드를 쿠버네티스 클러스터에서 삭제한다. -1. 구동 중인 모든 컨테이너를 중지시킨다. -1. 모든 컨테이너 네트워킹(HNS) 자원을 삭제한다. -1. 등록된 모든 쿠버네티스 서비스(flanneld, kubelet, kube-proxy)를 해지한다. -1. 쿠버네티스 바이너리(kube-proxy.exe, kubelet.exe, flanneld.exe, kubeadm.exe)를 모두 삭제한다. -1. CNI 네트워크 플러그인 바이너리를 모두 삭제한다. -1. 쿠버네티스 클러스터에 접근하기 위한 [Kubeconfig 파일](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 삭제한다. - - -### 퍼블릭 클라우드 제공자 - -#### Azure - -AKS-Engine은 완전하고, 맞춤 설정이 가능한 쿠버네티스 클러스터를 리눅스와 윈도우 노드에 배포할 수 있다. 단계별 안내가 [GitHub에 있는 문서](https://github.com/Azure/aks-engine/blob/master/docs/topics/windows.md)로 제공된다. - -#### GCP - -사용자가 [GitHub](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/windows/README-GCE-Windows-kube-up.md)에 있는 단계별 안내를 따라서 완전한 쿠버네티스 클러스터를 GCE 상에 쉽게 배포할 수 있다. - -#### kubeadm과 클러스터 API로 배포하기 - -Kubeadm은 쿠버네티스 클러스터를 배포하는 사용자에게 산업 표준이 되었다. Kubeadm에서 윈도우 노드 지원은 쿠버네티스 v1.16 이후 부터 알파 기능이다. 또한 윈도우 노드가 올바르게 프로비저닝되도록 클러스터 API에 투자하고 있다. 보다 자세한 내용은, [Windows KEP를 위한 kubeadm](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/kubeadm/20190424-kubeadm-for-windows.md)을 통해 상담하도록 하자. - - -### 다음 단계 - -이제 클러스터 내에 윈도우 컨테이너를 실행하도록 윈도우 워커를 구성했으니, 리눅스 컨테이너를 실행할 리눅스 노드를 1개 이상 추가할 수 있다. 이제 윈도우 컨테이너를 클러스터에 스케줄링할 준비가 됬다. - -{{% /capture %}} - diff --git a/content/ko/docs/tasks/administer-cluster/cluster-management.md b/content/ko/docs/tasks/administer-cluster/cluster-management.md index 4d1446526f..1fd99c0895 100644 --- a/content/ko/docs/tasks/administer-cluster/cluster-management.md +++ b/content/ko/docs/tasks/administer-cluster/cluster-management.md @@ -21,7 +21,7 @@ content_template: templates/concept ## 클러스터 업그레이드 -클러스터 업그레이드 상태의 현황은 제공자에 따라 달라지며, 몇몇 릴리스들은 업그레이드에 각별한 주의를 요하기도 한다. 관리자들에게는 클러스터 업그레이드에 앞서 [릴리스 노트](https://git.k8s.io/kubernetes/CHANGELOG.md)와 버전에 맞는 업그레이드 노트 모두를 검토하도록 권장하고 있다. +클러스터 업그레이드 상태의 현황은 제공자에 따라 달라지며, 몇몇 릴리스들은 업그레이드에 각별한 주의를 요하기도 한다. 관리자들에게는 클러스터 업그레이드에 앞서 [릴리스 노트](https://git.k8s.io/kubernetes/CHANGELOG/README.md)와 버전에 맞는 업그레이드 노트 모두를 검토하도록 권장하고 있다. ### Azure Kubernetes Service (AKS) 클러스터 업그레이드 diff --git a/content/ko/docs/tasks/configure-pod-container/_index.md b/content/ko/docs/tasks/configure-pod-container/_index.md new file mode 100644 index 0000000000..560261ecad --- /dev/null +++ b/content/ko/docs/tasks/configure-pod-container/_index.md @@ -0,0 +1,4 @@ +--- +title: "파드와 컨테이너 설정" +weight: 20 +--- diff --git a/content/ko/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/ko/docs/tasks/configure-pod-container/assign-pods-nodes.md new file mode 100644 index 0000000000..8ce67986bc --- /dev/null +++ b/content/ko/docs/tasks/configure-pod-container/assign-pods-nodes.md @@ -0,0 +1,104 @@ +--- +title: 노드에 파드 할당 +content_template: templates/task +weight: 120 +--- + +{{% capture overview %}} +이 문서는 쿠버네티스 클러스터의 특정 노드에 쿠버네티스 파드를 할당하는 +방법을 설명한다. +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + +## 노드에 레이블 추가 + +1. 클러스터의 {{< glossary_tooltip term_id="node" text="노드" >}}를 레이블과 함께 나열하자. + + ```shell + kubectl get nodes --show-labels + ``` + + 결과는 아래와 같다. + + ```shell + NAME STATUS ROLES AGE VERSION LABELS + worker0 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker0 + worker1 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker1 + worker2 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker2 + ``` +1. 노드 한 개를 선택하고, 레이블을 추가하자. + + ```shell + kubectl label nodes disktype=ssd + ``` + + ``는 선택한 노드의 이름이다. + +1. 선택한 노드가 `disktype=ssd` 레이블을 갖고 있는지 확인하자. + + ```shell + kubectl get nodes --show-labels + ``` + + 결과는 아래와 같다. + + ```shell + NAME STATUS ROLES AGE VERSION LABELS + worker0 Ready 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0 + worker1 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker1 + worker2 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker2 + ``` + + 위의 결과에서, `worker0` 노드에 `disktype=ssd` 레이블이 있는 것을 + 확인할 수 있다. + +## 선택한 노드에 스케줄되도록 파드 생성하기 + +이 파드 구성 파일은 `disktype: ssd`라는 선택하는 노드 셀렉터를 가진 파드를 +설명한다. +즉, `disktype=ssd` 레이블이 있는 노드에 파드가 스케줄될 것이라는 +것을 의미한다. + +{{< codenew file="pods/pod-nginx.yaml" >}} + +1. 구성 파일을 사용해서 선택한 노드로 스케줄되도록 파드를 + 생성하자. + + ```shell + kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml + ``` + +1. 파드가 선택한 노드에서 실행 중인지 확인하자. + + ```shell + kubectl get pods --output=wide + ``` + + 결과는 아래와 같다. + + ```shell + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 + ``` + +## 특정 노드에 스케줄되도록 파드 생성하기 + +`nodeName` 설정을 통해 특정 노드로 파드를 배포할 수 있다. + +{{< codenew file="pods/pod-nginx-specific-node.yaml" >}} + +설정 파일을 사용해 `foo-node` 노드에 파드를 스케줄되도록 만들어 보자. + +{{% /capture %}} + +{{% capture whatsnext %}} +* [레이블과 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 배우기. +* [노드](/ko/docs/concepts/architecture/nodes/)에 대해 배우기. +{{% /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 dde6650e20..013854884a 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md @@ -117,7 +117,7 @@ metadata: {"apiVersion":"apps/v1","kind":"Deployment", "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"}, "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}}, - "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx", + "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx", "ports":[{"containerPort":80}]}]}}}} # ... spec: @@ -134,7 +134,7 @@ spec: app: nginx spec: containers: - - image: nginx:1.7.9 + - image: nginx:1.14.2 # ... name: nginx ports: @@ -197,7 +197,7 @@ metadata: {"apiVersion":"apps/v1","kind":"Deployment", "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"}, "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}}, - "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx", + "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx", "ports":[{"containerPort":80}]}]}}}} # ... spec: @@ -214,7 +214,7 @@ spec: app: nginx spec: containers: - - image: nginx:1.7.9 + - image: nginx:1.14.2 # ... name: nginx ports: @@ -253,7 +253,7 @@ metadata: {"apiVersion":"apps/v1","kind":"Deployment", "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"}, "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}}, - "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx", + "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx", "ports":[{"containerPort":80}]}]}}}} # ... spec: @@ -271,7 +271,7 @@ spec: app: nginx spec: containers: - - image: nginx:1.7.9 + - image: nginx:1.14.2 # ... name: nginx ports: @@ -279,7 +279,7 @@ spec: # ... ``` -`nginx:1.7.9`에서 `nginx:1.11.9`로 이미지를 변경하기 위해 `simple_deployment.yaml` +`nginx:1.14.2`에서 `nginx:1.16.1`로 이미지를 변경하기 위해 `simple_deployment.yaml` 구성 파일을 업데이트 하고, `minReadySeconds` 필드를 삭제한다. {{< codenew file="application/update_deployment.yaml" >}} @@ -301,7 +301,7 @@ kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yam * `replicas` 필드는 `kubectl scale`에 의해 설정된 값 2를 유지한다. 이는 구성 파일에서 생략되었기 때문에 가능하다. -* `image` 필드는 `nginx:1.7.9`에서 `nginx:1.11.9`로 업데이트되었다. +* `image` 필드는 `nginx:1.14.2`에서 `nginx:1.16.1`로 업데이트되었다. * `last-applied-configuration` 어노테이션은 새로운 이미지로 업데이트되었다. * `minReadySeconds` 필드는 지워졌다. * `last-applied-configuration` 어노테이션은 더 이상 `minReadySeconds` 필드를 포함하지 않는다. @@ -318,7 +318,7 @@ metadata: {"apiVersion":"apps/v1","kind":"Deployment", "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"}, "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}}, - "spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx", + "spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx", "ports":[{"containerPort":80}]}]}}}} # ... spec: @@ -336,7 +336,7 @@ spec: app: nginx spec: containers: - - image: nginx:1.11.9 # Set by `kubectl apply` + - image: nginx:1.16.1 # Set by `kubectl apply` # ... name: nginx ports: @@ -458,7 +458,7 @@ metadata: {"apiVersion":"apps/v1","kind":"Deployment", "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"}, "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}}, - "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx", + "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx", "ports":[{"containerPort":80}]}]}}}} # ... spec: @@ -476,7 +476,7 @@ spec: app: nginx spec: containers: - - image: nginx:1.7.9 + - image: nginx:1.14.2 # ... name: nginx ports: @@ -516,7 +516,7 @@ metadata: {"apiVersion":"apps/v1","kind":"Deployment", "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"}, "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}}, - "spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx", + "spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx", "ports":[{"containerPort":80}]}]}}}} # ... spec: @@ -534,7 +534,7 @@ spec: app: nginx spec: containers: - - image: nginx:1.11.9 # Set by `kubectl apply` + - image: nginx:1.16.1 # Set by `kubectl apply` # ... name: nginx ports: @@ -777,7 +777,7 @@ spec: app: nginx spec: containers: - - image: nginx:1.7.9 + - image: nginx:1.14.2 imagePullPolicy: IfNotPresent # defaulted by apiserver name: nginx ports: @@ -817,7 +817,7 @@ spec: spec: containers: - name: nginx - image: nginx:1.7.9 + image: nginx:1.14.2 ports: - containerPort: 80 @@ -832,7 +832,7 @@ spec: spec: containers: - name: nginx - image: nginx:1.7.9 + image: nginx:1.14.2 ports: - containerPort: 80 @@ -850,7 +850,7 @@ spec: spec: containers: - name: nginx - image: nginx:1.7.9 + image: nginx:1.14.2 ports: - containerPort: 80 @@ -868,7 +868,7 @@ spec: spec: containers: - name: nginx - image: nginx:1.7.9 + image: nginx:1.14.2 ports: - containerPort: 80 ``` 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 695ec57d09..7f2d17ca5f 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md @@ -139,10 +139,10 @@ TODO(pwittrock): 구현이 이루어지면 주석을 해제한다. 다음은 관련 예제이다. ```sh -kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f - +kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f - ``` -1. `kubectl create service -o yaml --dry-run` 커맨드는 서비스에 대한 구성을 생성하지만, 이를 쿠버네티스 API 서버에 전송하는 대신 YAML 형식으로 stdout에 출력한다. +1. `kubectl create service -o yaml --dry-run=client` 커맨드는 서비스에 대한 구성을 생성하지만, 이를 쿠버네티스 API 서버에 전송하는 대신 YAML 형식으로 stdout에 출력한다. 1. `kubectl set selector --local -f - -o yaml` 커맨드는 stdin으로부터 구성을 읽어, YAML 형식으로 stdout에 업데이트된 구성을 기록한다. 1. `kubectl create -f -` 커맨드는 stdin을 통해 제공된 구성을 사용하여 오브젝트를 생성한다. @@ -152,7 +152,7 @@ kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run | k 다음은 관련 예제이다. ```sh -kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run > /tmp/srv.yaml +kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client > /tmp/srv.yaml kubectl create --edit -f /tmp/srv.yaml ``` diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md index 6cd56ae881..87ca926908 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -791,6 +791,12 @@ kubectl get -k ./ kubectl describe -k ./ ``` +다음 명령을 실행해서 디플로이먼트 오브젝트 `dev-my-nginx` 를 매니페스트가 적용된 경우의 클러스터 상태와 비교한다. + +```shell +kubectl diff -k ./ +``` + 디플로이먼트 오브젝트 `dev-my-nginx`를 삭제하려면 다음 명령어를 실행한다. ```shell 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 136ff556e9..9ab479baf3 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -291,7 +291,7 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. ## 구성가능한 스케일링 동작 지원 -[v1.17](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md) +[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md) 부터 `v2beta2` API는 HPA `behavior` 필드를 통해 스케일링 동작을 구성할 수 있다. 동작은 `behavior` 필드 아래의 `scaleUp` 또는 `scaleDown` diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index 82a899bba0..41ff7092ec 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -26,7 +26,7 @@ grep -E --color 'vmx|svm' /proc/cpuinfo {{% tab name="맥OS" %}} 맥OS에서 가상화 지원 여부를 확인하려면, 아래 명령어를 터미널에서 실행한다. ``` -sysctl -a | grep -E --color 'machdep.cpu.features|VMX' +sysctl -a | grep -E --color 'machdep.cpu.features|VMX' ``` 만약 출력 중에 (색상으로 강조된) `VMX`를 볼 수 있다면, VT-x 기능이 머신에서 활성화된 것이다. {{% /tab %}} @@ -74,7 +74,7 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads) -Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. +Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--driver=none` 옵션도 지원한다. 이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않다. 데비안(Debian) 또는 파생된 배포판에서 `none` 드라이버를 사용하는 경우, @@ -83,7 +83,7 @@ Minikube에서는 동작하지 않는 스냅 패키지 대신 도커용 `.deb` {{< caution >}} `none` VM 드라이버는 보안과 데이터 손실 이슈를 일으킬 수 있다. -`--vm-driver=none` 을 사용하기 전에 [이 문서](https://minikube.sigs.k8s.io/docs/reference/drivers/none/)를 참조해서 더 자세한 내용을 본다. +`--driver=none` 을 사용하기 전에 [이 문서](https://minikube.sigs.k8s.io/docs/reference/drivers/none/)를 참조해서 더 자세한 내용을 본다. {{< /caution >}} Minikube는 도커 드라이브와 비슷한 `vm-driver=podman` 도 지원한다. 슈퍼사용자 권한(root 사용자)으로 실행되는 Podman은 컨테이너가 시스템에서 사용 가능한 모든 기능에 완전히 접근할 수 있는 가장 좋은 방법이다. @@ -214,12 +214,12 @@ Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Mini {{< note >}} -`minikube start` 시 `--vm-driver` 를 설정하려면, 아래에 `` 로 소문자로 언급된 곳에 설치된 하이퍼바이저의 이름을 입력한다. `--vm-driver` 값의 전체 목록은 [VM driver 문서에서 지정하기](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)에서 확인할 수 있다. +`minikube start` 시 `--driver` 를 설정하려면, 아래에 `` 로 소문자로 언급된 곳에 설치된 하이퍼바이저의 이름을 입력한다. `--driver` 값의 전체 목록은 [VM driver 문서에서 지정하기](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)에서 확인할 수 있다. {{< /note >}} ```shell -minikube start --vm-driver= +minikube start --driver= ``` `minikube start` 가 완료되면, 아래 명령을 실행해서 클러스터의 상태를 확인한다. diff --git a/content/ko/examples/admin/resource/limit-mem-cpu-container.yaml b/content/ko/examples/admin/resource/limit-mem-cpu-container.yaml new file mode 100644 index 0000000000..3c2b30f29c --- /dev/null +++ b/content/ko/examples/admin/resource/limit-mem-cpu-container.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: limit-mem-cpu-per-container +spec: + limits: + - max: + cpu: "800m" + memory: "1Gi" + min: + cpu: "100m" + memory: "99Mi" + default: + cpu: "700m" + memory: "900Mi" + defaultRequest: + cpu: "110m" + memory: "111Mi" + type: Container diff --git a/content/ko/examples/admin/resource/limit-mem-cpu-pod.yaml b/content/ko/examples/admin/resource/limit-mem-cpu-pod.yaml new file mode 100644 index 0000000000..0ce0f69ac8 --- /dev/null +++ b/content/ko/examples/admin/resource/limit-mem-cpu-pod.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: limit-mem-cpu-per-pod +spec: + limits: + - max: + cpu: "2" + memory: "2Gi" + type: Pod diff --git a/content/ko/examples/admin/resource/limit-memory-ratio-pod.yaml b/content/ko/examples/admin/resource/limit-memory-ratio-pod.yaml new file mode 100644 index 0000000000..859fc20ece --- /dev/null +++ b/content/ko/examples/admin/resource/limit-memory-ratio-pod.yaml @@ -0,0 +1,9 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: limit-memory-ratio-pod +spec: + limits: + - maxLimitRequestRatio: + memory: 2 + type: Pod diff --git a/content/ko/examples/admin/resource/limit-range-pod-1.yaml b/content/ko/examples/admin/resource/limit-range-pod-1.yaml new file mode 100644 index 0000000000..0457792af9 --- /dev/null +++ b/content/ko/examples/admin/resource/limit-range-pod-1.yaml @@ -0,0 +1,37 @@ +apiVersion: v1 +kind: Pod +metadata: + name: busybox1 +spec: + containers: + - name: busybox-cnt01 + image: busybox + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt01; sleep 10;done"] + resources: + requests: + memory: "100Mi" + cpu: "100m" + limits: + memory: "200Mi" + cpu: "500m" + - name: busybox-cnt02 + image: busybox + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt02; sleep 10;done"] + resources: + requests: + memory: "100Mi" + cpu: "100m" + - name: busybox-cnt03 + image: busybox + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt03; sleep 10;done"] + resources: + limits: + memory: "200Mi" + cpu: "500m" + - name: busybox-cnt04 + image: busybox + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt04; sleep 10;done"] diff --git a/content/ko/examples/admin/resource/limit-range-pod-2.yaml b/content/ko/examples/admin/resource/limit-range-pod-2.yaml new file mode 100644 index 0000000000..efac440269 --- /dev/null +++ b/content/ko/examples/admin/resource/limit-range-pod-2.yaml @@ -0,0 +1,37 @@ +apiVersion: v1 +kind: Pod +metadata: + name: busybox2 +spec: + containers: + - name: busybox-cnt01 + image: busybox + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt01; sleep 10;done"] + resources: + requests: + memory: "100Mi" + cpu: "100m" + limits: + memory: "200Mi" + cpu: "500m" + - name: busybox-cnt02 + image: busybox + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt02; sleep 10;done"] + resources: + requests: + memory: "100Mi" + cpu: "100m" + - name: busybox-cnt03 + image: busybox + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt03; sleep 10;done"] + resources: + limits: + memory: "200Mi" + cpu: "500m" + - name: busybox-cnt04 + image: busybox + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt04; sleep 10;done"] diff --git a/content/ko/examples/admin/resource/limit-range-pod-3.yaml b/content/ko/examples/admin/resource/limit-range-pod-3.yaml new file mode 100644 index 0000000000..8afdb6379c --- /dev/null +++ b/content/ko/examples/admin/resource/limit-range-pod-3.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: busybox3 +spec: + containers: + - name: busybox-cnt01 + image: busybox + resources: + limits: + memory: "300Mi" + requests: + memory: "100Mi" diff --git a/content/ko/examples/admin/resource/pvc-limit-greater.yaml b/content/ko/examples/admin/resource/pvc-limit-greater.yaml new file mode 100644 index 0000000000..2d92bf92b3 --- /dev/null +++ b/content/ko/examples/admin/resource/pvc-limit-greater.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: pvc-limit-greater +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 5Gi diff --git a/content/ko/examples/admin/resource/pvc-limit-lower.yaml b/content/ko/examples/admin/resource/pvc-limit-lower.yaml new file mode 100644 index 0000000000..ef819b6292 --- /dev/null +++ b/content/ko/examples/admin/resource/pvc-limit-lower.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: pvc-limit-lower +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 500Mi diff --git a/content/ko/examples/admin/resource/storagelimits.yaml b/content/ko/examples/admin/resource/storagelimits.yaml new file mode 100644 index 0000000000..7f597e4dfe --- /dev/null +++ b/content/ko/examples/admin/resource/storagelimits.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: storagelimits +spec: + limits: + - type: PersistentVolumeClaim + max: + storage: 2Gi + min: + storage: 1Gi diff --git a/content/ko/examples/application/deployment.yaml b/content/ko/examples/application/deployment.yaml index 68ab8289b5..2cd599218d 100644 --- a/content/ko/examples/application/deployment.yaml +++ b/content/ko/examples/application/deployment.yaml @@ -1,4 +1,4 @@ -apiVersion: apps/v1 # apps/v1beta2를 사용하는 1.9.0보다 더 이전의 버전용 +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 kind: Deployment metadata: name: nginx-deployment @@ -6,7 +6,7 @@ spec: selector: matchLabels: app: nginx - replicas: 2 # 템플릿에 매칭되는 파드 2개를 구동하는 디플로이먼트임 + replicas: 2 # tells deployment to run 2 pods matching the template template: metadata: labels: @@ -14,6 +14,6 @@ spec: spec: containers: - name: nginx - image: nginx:1.7.9 + image: nginx:1.14.2 ports: - containerPort: 80 diff --git a/content/ko/examples/application/simple_deployment.yaml b/content/ko/examples/application/simple_deployment.yaml index 10fa1ddf29..d9c74af8c5 100644 --- a/content/ko/examples/application/simple_deployment.yaml +++ b/content/ko/examples/application/simple_deployment.yaml @@ -14,6 +14,6 @@ spec: spec: containers: - name: nginx - image: nginx:1.7.9 + image: nginx:1.14.2 ports: - containerPort: 80 diff --git a/content/ko/examples/application/update_deployment.yaml b/content/ko/examples/application/update_deployment.yaml index d53aa3e6d2..2d7603acb9 100644 --- a/content/ko/examples/application/update_deployment.yaml +++ b/content/ko/examples/application/update_deployment.yaml @@ -13,6 +13,6 @@ spec: spec: containers: - name: nginx - image: nginx:1.11.9 # update the image + image: nginx:1.16.1 # update the image ports: - containerPort: 80 diff --git a/content/ko/examples/controllers/daemonset.yaml b/content/ko/examples/controllers/daemonset.yaml index 1bfa082833..f291b750c1 100644 --- a/content/ko/examples/controllers/daemonset.yaml +++ b/content/ko/examples/controllers/daemonset.yaml @@ -15,6 +15,8 @@ spec: name: fluentd-elasticsearch spec: tolerations: + # this toleration is to have the daemonset runnable on master nodes + # remove it if your masters can't run pods - key: node-role.kubernetes.io/master effect: NoSchedule containers: diff --git a/content/ko/examples/controllers/nginx-deployment.yaml b/content/ko/examples/controllers/nginx-deployment.yaml index f7f95deebb..685c17aa68 100644 --- a/content/ko/examples/controllers/nginx-deployment.yaml +++ b/content/ko/examples/controllers/nginx-deployment.yaml @@ -16,6 +16,6 @@ spec: spec: containers: - name: nginx - image: nginx:1.7.9 + image: nginx:1.14.2 ports: - containerPort: 80 diff --git a/content/ko/examples/pods/pod-nginx-specific-node.yaml b/content/ko/examples/pods/pod-nginx-specific-node.yaml new file mode 100644 index 0000000000..27ead0118a --- /dev/null +++ b/content/ko/examples/pods/pod-nginx-specific-node.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + nodeName: foo-node # 특정 노드에 파드 스케줄 + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent diff --git a/content/ko/examples/policy/example-psp.yaml b/content/ko/examples/policy/example-psp.yaml new file mode 100644 index 0000000000..7c7a19343f --- /dev/null +++ b/content/ko/examples/policy/example-psp.yaml @@ -0,0 +1,17 @@ +apiVersion: policy/v1beta1 +kind: PodSecurityPolicy +metadata: + name: example +spec: + privileged: false # 특권을 가진 파드는 허용금지! + # 나머지는 일부 필수 필드를 채운다. + seLinux: + rule: RunAsAny + supplementalGroups: + rule: RunAsAny + runAsUser: + rule: RunAsAny + fsGroup: + rule: RunAsAny + volumes: + - '*' diff --git a/content/ko/examples/policy/privileged-psp.yaml b/content/ko/examples/policy/privileged-psp.yaml new file mode 100644 index 0000000000..915c8d37b5 --- /dev/null +++ b/content/ko/examples/policy/privileged-psp.yaml @@ -0,0 +1,27 @@ +apiVersion: policy/v1beta1 +kind: PodSecurityPolicy +metadata: + name: privileged + annotations: + seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*' +spec: + privileged: true + allowPrivilegeEscalation: true + allowedCapabilities: + - '*' + volumes: + - '*' + hostNetwork: true + hostPorts: + - min: 0 + max: 65535 + hostIPC: true + hostPID: true + runAsUser: + rule: 'RunAsAny' + seLinux: + rule: 'RunAsAny' + supplementalGroups: + rule: 'RunAsAny' + fsGroup: + rule: 'RunAsAny' diff --git a/content/ko/examples/policy/restricted-psp.yaml b/content/ko/examples/policy/restricted-psp.yaml new file mode 100644 index 0000000000..cbaf2758c0 --- /dev/null +++ b/content/ko/examples/policy/restricted-psp.yaml @@ -0,0 +1,48 @@ +apiVersion: policy/v1beta1 +kind: PodSecurityPolicy +metadata: + name: restricted + annotations: + seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default' + apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' + seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default' + apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' +spec: + privileged: false + # 루트로의 에스컬레이션을 방지하는데 필요하다. + allowPrivilegeEscalation: false + # 이것은 루트가 아닌 사용자 + 권한 에스컬레이션을 허용하지 않는 것으로 중복이지만, + # 심층 방어를 위해 이를 제공한다. + requiredDropCapabilities: + - ALL + # 기본 볼륨 유형을 허용한다. + volumes: + - 'configMap' + - 'emptyDir' + - 'projected' + - 'secret' + - 'downwardAPI' + # 클러스터 관리자가 설정한 퍼시스턴트볼륨을 사용하는 것이 안전하다고 가정한다. + - 'persistentVolumeClaim' + hostNetwork: false + hostIPC: false + hostPID: false + runAsUser: + # 루트 권한없이 컨테이너를 실행해야 한다. + rule: 'MustRunAsNonRoot' + seLinux: + # 이 정책은 노드가 SELinux가 아닌 AppArmor를 사용한다고 가정한다. + rule: 'RunAsAny' + supplementalGroups: + rule: 'MustRunAs' + ranges: + # 루트 그룹을 추가하지 않는다. + - min: 1 + max: 65535 + fsGroup: + rule: 'MustRunAs' + ranges: + # 루트 그룹을 추가하지 않는다. + - min: 1 + max: 65535 + readOnlyRootFilesystem: false diff --git a/content/ko/partners/_index.html b/content/ko/partners/_index.html new file mode 100644 index 0000000000..2ac7e6945c --- /dev/null +++ b/content/ko/partners/_index.html @@ -0,0 +1,91 @@ +--- +title: 파트너 +bigheader: 쿠버네티스 파트너 +abstract: 쿠버네티스 생태계의 성장 +class: gridPage +cid: partners +--- + +
+
+
쿠버네티스는 파트너와 협력하여 다양하게 보완하는 플랫폼을 지원하는 강력하고 활기찬 코드베이스를 만들어갑니다.
+
+
+
+
+ 공인 쿠버네티스 서비스 공급자(Kubernetes Certified Service Providers, KCSP) +
+
기업들이 쿠버네티스를 성공적으로 채택하도록 도와주는 풍부한 경험을 가진 노련한 서비스 공급자입니다. +


+ +

KCSP에 관심이 있으신가요? +
+
+
+
+
+ 공인 쿠버네티스 배포, 호스트된 플랫폼 그리고 설치 프로그램 +
소프트웨어 적합성은 모든 벤더의 쿠버네티스 버전이 필요한 API를 지원하도록 보장합니다. +


+ +

공인 쿠버네티스에 관심이 있으신가요? +
+
+
+
+
쿠버네티스 교육 파트너(Kubernetes Training Partners, KTP)
+
클라우드 네이티브 기술 교육 경험이 풍부하고 노련한 교육 공급자입니다. +



+ +

KTP에 관심이 있으신가요? +
+
+
+ + + +
+ + +
+ +
+
+ + + + diff --git a/content/pt/docs/concepts/extend-kubernetes/_index.md b/content/pt/docs/concepts/extend-kubernetes/_index.md new file mode 100644 index 0000000000..db8257b625 --- /dev/null +++ b/content/pt/docs/concepts/extend-kubernetes/_index.md @@ -0,0 +1,4 @@ +--- +title: Extendendo o Kubernetes +weight: 110 +--- diff --git a/content/pt/docs/concepts/extend-kubernetes/operator.md b/content/pt/docs/concepts/extend-kubernetes/operator.md new file mode 100644 index 0000000000..9b7198d2fe --- /dev/null +++ b/content/pt/docs/concepts/extend-kubernetes/operator.md @@ -0,0 +1,137 @@ +--- +title: Padrão Operador +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +Operadores são extensões de software para o Kubernetes que +fazem uso de [*recursos personalizados*](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +para gerir aplicações e os seus componentes. Operadores seguem os +princípios do Kubernetes, notavelmente o [ciclo de controle](/docs/concepts/#kubernetes-control-plane). + +{{% /capture %}} + + +{{% capture body %}} + +## Motivação + +O padrão Operador tem como objetivo capturar o principal objetivo de um operador +humano que gere um serviço ou um conjunto de serviços. Operadores humanos +responsáveis por aplicações e serviços específicos têm um conhecimento +profundo da forma como o sistema é suposto se comportar, como é instalado +e como deve reagir na ocorrência de problemas. + +As pessoas que executam cargas de trabalho no Kubernetes habitualmente gostam +de usar automação para cuidar de tarefas repetitivas. O padrão Operador captura +a forma como pode escrever código para automatizar uma tarefa para além do que +o Kubernetes fornece. + +## Operadores no Kubernetes + +O Kubernetes é desenhado para automação. *Out of the box*, você tem bastante +automação embutida no núcleo do Kubernetes. Pode usar +o Kubernetes para automatizar instalações e executar cargas de trabalho, +e pode ainda automatizar a forma como o Kubernetes faz isso. + +O conceito de {{< glossary_tooltip text="controlador" term_id="controller" >}} no +Kubernetes permite a extensão do comportamento sem modificar o código do próprio +Kubernetes. +Operadores são clientes da API do Kubernetes que atuam como controladores para +um dado [*Custom Resource*](/docs/concepts/api-extension/custom-resources/) + +## Exemplo de um Operador {#exemplo} + +Algumas das coisas que um operador pode ser usado para automatizar incluem: + +* instalar uma aplicação a pedido +* obter e restaurar backups do estado dessa aplicação +* manipular atualizações do código da aplicação juntamente com alterações + como esquemas de base de dados ou definições de configuração extra +* publicar um *Service* para aplicações que não suportam a APIs do Kubernetes + para as descobrir +* simular una falha em todo ou parte do cluster de forma a testar a resiliência +* escolher um lider para uma aplicação distribuída sem um processo + de eleição de membro interno + +Como deve um Operador parecer em mais detalhe? Aqui está um exemplo em mais +detalhe: + +1. Um recurso personalizado (*custom resource*) chamado SampleDB, que você pode + configurar para dentro do *cluster*. +2. Um *Deployment* que garante que um *Pod* está a executar que contém a + parte controlador do operador. +3. Uma imagem do *container* do código do operador. +4. Código do controlador que consulta o plano de controle para descobrir quais + recursos *SampleDB* estão configurados. +5. O núcleo do Operador é o código para informar ao servidor da API (*API server*) como fazer + a realidade coincidir com os recursos configurados. + * Se você adicionar um novo *SampleDB*, o operador configurará *PersistentVolumeClaims* + para fornecer armazenamento de base de dados durável, um *StatefulSet* para executar *SampleDB* e + um *Job* para lidar com a configuração inicial. + * Se você apagá-lo, o Operador tira um *snapshot* e então garante que + o *StatefulSet* e *Volumes* também são removidos. +6. O operador também gere backups regulares da base de dados. Para cada recurso *SampleDB*, + o operador determina quando deve criar um *Pod* que possa se conectar + à base de dados e faça backups. Esses *Pods* dependeriam de um *ConfigMap* + e / ou um *Secret* que possui detalhes e credenciais de conexão com à base de dados. +7. Como o Operador tem como objetivo fornecer automação robusta para o recurso + que gere, haveria código de suporte adicional. Para este exemplo, + O código verifica se a base de dados está a executar uma versão antiga e, se estiver, + cria objetos *Job* que o atualizam para si. + +## Instalar Operadores + +A forma mais comum de instalar um Operador é a de adicionar a +definição personalizada de recurso (*Custom Resource Definition*) e +o seu Controlador associado ao seu cluster. +O Controlador vai normalmente executar fora do +{{< glossary_tooltip text="plano de controle" term_id="control-plane" >}}, +como você faria com qualquer aplicação containerizada. +Por exemplo, você pode executar o controlador no seu cluster como um *Deployment*. + +## Usando um Operador + +Uma vez que você tenha um Operador instalado, usaria-o adicionando, modificando +ou apagando a espécie de recurso que o Operador usa. Seguindo o exemplo acima, +você configuraria um *Deployment* para o próprio Operador, e depois: + +```shell +kubectl get SampleDB # encontra a base de dados configurada + +kubectl edit SampleDB/example-database # mudar manualmente algumas definições +``` + +…e é isso! O Operador vai tomar conta de aplicar +as mudanças assim como manter o serviço existente em boa forma. + +## Escrevendo o seu prórpio Operador {#escrevendo-operador} + +Se não existir no ecosistema um Operador que implementa +o comportamento que pretende, pode codificar o seu próprio. +[Qual é o próximo](#qual-é-o-próximo) você vai encontrar +alguns *links* para bibliotecas e ferramentas que pode usar +para escrever o seu próprio Operador *cloud native*. + +Pode também implementar um Operador (isto é, um Controlador) usando qualquer linguagem / *runtime* +que pode atuar como um [cliente da API do Kubernetes](/docs/reference/using-api/client-libraries/). + +{{% /capture %}} + +{{% capture whatsnext %}} + +* Aprenda mais sobre [Recursos Personalizados](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* Encontre operadores prontos em [OperatorHub.io](https://operatorhub.io/) para o seu caso de uso +* Use ferramentes existentes para escrever os seus Operadores: + * usando [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) + * usando [kubebuilder](https://book.kubebuilder.io/) + * usando [Metacontroller](https://metacontroller.app/) juntamente com WebHooks que + implementa você mesmo + * usando o [Operator Framework](https://github.com/operator-framework/getting-started) +* [Publique](https://operatorhub.io/) o seu operador para que outras pessoas o possam usar +* Leia o [artigo original da CoreOS](https://coreos.com/blog/introducing-operators.html) que introduz o padrão Operador +* Leia um [artigo](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) da Google Cloud sobre as melhores práticas para contruir Operadores + +{{% /capture %}} diff --git a/content/pt/docs/concepts/workloads/controllers/_index.md b/content/pt/docs/concepts/workloads/controllers/_index.md new file mode 100755 index 0000000000..376ef67943 --- /dev/null +++ b/content/pt/docs/concepts/workloads/controllers/_index.md @@ -0,0 +1,4 @@ +--- +title: "Controladores" +weight: 20 +--- diff --git a/content/pt/docs/concepts/workloads/controllers/cron-jobs.md b/content/pt/docs/concepts/workloads/controllers/cron-jobs.md new file mode 100644 index 0000000000..a3241f73b0 --- /dev/null +++ b/content/pt/docs/concepts/workloads/controllers/cron-jobs.md @@ -0,0 +1,54 @@ +--- +reviewers: + - erictune + - soltysh + - janetkuo +title: CronJob +content_template: templates/concept +weight: 80 +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.8" state="beta" >}} + +Um _Cron Job_ cria [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) em um cronograma baseado em tempo. + +Um objeto CronJob é como um arquivo _crontab_ (tabela cron). Executa um job periodicamente em um determinado horário, escrito no formato [Cron](https://en.wikipedia.org/wiki/Cron). + +{{< note >}} +Todos os **CronJob** `schedule (horários):` são indicados em UTC. +{{< /note >}} + +Ao criar o manifesto para um recurso CronJob, verifique se o nome que você fornece é um [nome de subdomínio DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. +O nome não deve ter mais que 52 caracteres. Isso ocorre porque o controlador do CronJob anexará automaticamente 11 caracteres ao nome da tarefa fornecido e há uma restrição de que o comprimento máximo de um nome da tarefa não pode ultrapassar 63 caracteres. + +Para obter instruções sobre como criar e trabalhar com tarefas cron, e para obter um exemplo de arquivo de especificação para uma tarefa cron, consulte [Executando tarefas automatizadas com tarefas cron](/docs/tasks/job/automated-tasks-with-cron-jobs). + +{{% /capture %}} + +{{% capture body %}} + +## Limitações do Cron Job + +Um trabalho cron cria um objeto de trabalho _about_ uma vez por tempo de execução de seu planejamento, Dizemos "about" porque há certas circunstâncias em que duas tarefas podem ser criadas ou nenhum trabalho pode ser criado. Tentamos torná-los únicos, mas não os impedimos completamente. Portanto, os trabalhos devem ser _idempotente_. + +Se `startingDeadlineSeconds` estiver definido como um valor grande ou não definido (o padrão) e se `concurrencyPolicy` estiver definido como `Allow(Permitir)` os trabalhos sempre serão executados pelo menos uma vez. + +Para cada CronJob, o CronJob {{< glossary_tooltip term_id="controller" >}} verifica quantas agendas faltou na duração, desde o último horário agendado até agora. Se houver mais de 100 agendamentos perdidos, ele não iniciará o trabalho e registrará o erro + +``` +Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. +``` + +É importante observar que, se o campo `startingDeadlineSeconds` estiver definido (não `nil`), o controlador contará quantas tarefas perdidas ocorreram a partir do valor de `startingDeadlineSeconds` até agora, e não do último horário programado até agora. Por exemplo, se `startingDeadlineSeconds` for `200`, o controlador contará quantas tarefas perdidas ocorreram nos últimos 200 segundos. + +Um CronJob é contado como perdido se não tiver sido criado no horário agendado. Por exemplo, se `concurrencyPolicy` estiver definido como `Forbid` e um CronJob tiver sido tentado ser agendado quando havia um agendamento anterior ainda em execução, será contabilizado como perdido. + +Por exemplo, suponha que um CronJob esteja definido para agendar um novo trabalho a cada minuto, começando em `08:30:00`, e seu campo `startingDeadlineSeconds` não esteja defindo. Se o controlador CronJob estiver baixo de `08:29:00` para `10:21:00`, o trabalho não será iniciado, pois o número de trabalhos perdidos que perderam o cronograma é maior que 100. + +Para ilustrar ainda mais esse conceito, suponha que um CronJob esteja definido para agendar um novo trabalho a cada minuto, começando em `08:30:00`, e seu `startingDeadlineSeconds` está definido em 200 segundos. Se o controlador CronJob estiver inativo no mesmo período do exemplo anterior (`08:29:00` a `10:21:00`), o trabalho ainda será iniciado às 10:22:00. Isso acontece pois o controlador agora verifica quantos agendamentos perdidos ocorreram nos últimos 200 segundos (ou seja, 3 agendamentos perdidos), em vez do último horário agendado até agora. + +O CronJob é responsável apenas pela criação de trabalhos que correspondem à sua programação, e o trabalho, por sua vez, é responsável pelo gerenciamento dos Pods que ele representa. + +{{% /capture %}} diff --git a/content/pt/docs/templates/feature-state-alpha.txt b/content/pt/docs/templates/feature-state-alpha.txt new file mode 100644 index 0000000000..891096f123 --- /dev/null +++ b/content/pt/docs/templates/feature-state-alpha.txt @@ -0,0 +1,7 @@ +Atualmente, esse recurso está no estado *alpha*, o que significa: + +* Os nomes das versões contêm alfa (ex. v1alpha1). +* Pode estar com bugs. A ativação do recurso pode expor bugs. Desabilitado por padrão. +* O suporte ao recurso pode ser retirado a qualquer momento sem aviso prévio. +* A API pode mudar de maneiras incompatíveis em uma versão de software posterior sem aviso prévio. +* Recomendado para uso apenas em clusters de teste de curta duração, devido ao aumento do risco de erros e falta de suporte a longo prazo. diff --git a/content/pt/docs/templates/feature-state-beta.txt b/content/pt/docs/templates/feature-state-beta.txt new file mode 100644 index 0000000000..0a0970f83b --- /dev/null +++ b/content/pt/docs/templates/feature-state-beta.txt @@ -0,0 +1,8 @@ +Atualmente, esse recurso está no estado *beta*, o que significa: + +* Os nomes das versões contêm beta (ex, v2beta3). +* O código está bem testado. A ativação do recurso é considerada segura. Ativado por padrão. +* O suporte para o recurso geral não será descartado, embora os detalhes possam mudar. +* O esquema e/ou semântica dos objetos podem mudar de maneiras incompatíveis em uma versão beta ou estável subsequente. Quando isso acontecer, forneceremos instruções para migrar para a próxima versão. Isso pode exigir a exclusão, edição e recriação de objetos da API. O processo de edição pode exigir alguma reflexão. Isso pode exigir tempo de inatividade para aplicativos que dependem do recurso. +* Recomendado apenas para usos não comerciais, devido ao potencial de alterações incompatíveis nas versões subsequentes. Se você tiver vários clusters que podem ser atualizados independentemente, poderá relaxar essa restrição. +* **Por favor, experimente nossos recursos beta e dê um feedback sobre eles! Depois que eles saem da versão beta, pode não ser prático para nós fazer mais alterações.** diff --git a/content/pt/docs/templates/feature-state-deprecated.txt b/content/pt/docs/templates/feature-state-deprecated.txt new file mode 100644 index 0000000000..e75f713b73 --- /dev/null +++ b/content/pt/docs/templates/feature-state-deprecated.txt @@ -0,0 +1 @@ +Este recurso está *obsoleto*. Para obter mais informações sobre esse estado, consulte a [Política de descontinuação do Kubernetes](/docs/reference/deprecation-policy/). diff --git a/content/pt/docs/templates/feature-state-stable.txt b/content/pt/docs/templates/feature-state-stable.txt new file mode 100644 index 0000000000..a9ef64609c --- /dev/null +++ b/content/pt/docs/templates/feature-state-stable.txt @@ -0,0 +1,4 @@ +Esse recurso é *estável*, o que significa: + +* O nome da versão é vX, em que X é um número inteiro. +* Versões estáveis dos recursos aparecerão no software lançado para muitas versões subsequentes. diff --git a/content/pt/docs/templates/index.md b/content/pt/docs/templates/index.md new file mode 100644 index 0000000000..9d7bccd143 --- /dev/null +++ b/content/pt/docs/templates/index.md @@ -0,0 +1,13 @@ +--- +headless: true + +resources: +- src: "*alpha*" + title: "alpha" +- src: "*beta*" + title: "beta" +- src: "*deprecated*" + title: "deprecated" +- src: "*stable*" + title: "stable" +--- diff --git a/content/ru/docs/concepts/overview/kubernetes-api.md b/content/ru/docs/concepts/overview/kubernetes-api.md new file mode 100644 index 0000000000..c3812c8469 --- /dev/null +++ b/content/ru/docs/concepts/overview/kubernetes-api.md @@ -0,0 +1,117 @@ +--- +title: API Kubernetes +content_template: templates/concept +weight: 30 +card: + name: concepts + weight: 30 +--- + +{{% capture overview %}} + +Общие соглашения API описаны на [странице соглашений API](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md). + +Конечные точки API, типы ресурсов и примеры описаны в [справочнике API](/docs/reference). + +Удаленный доступ к API обсуждается в [Controlling API Access doc](/docs/reference/access-authn-authz/controlling-access/). + +API Kubernetes также служит основой декларативной схемы конфигурации системы. С помощью инструмента командной строки [kubectl](/ru/docs/reference/kubectl/overview/) можно создавать, обновлять, удалять и получать API-объекты. + +Kubernetes также сохраняет сериализованное состояние (в настоящее время в хранилище [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)) каждого API-ресурса. + +Kubernetes как таковой состоит из множества компонентов, которые взаимодействуют друг с другом через собственные API. + +{{% /capture %}} + +{{% capture body %}} + +## Изменения в API + +Исходя из нашего опыта, любая успешная система должна улучшаться и изменяться по мере появления новых сценариев использования или изменения существующих. Поэтому мы надеемся, что и API Kubernetes будет постоянно меняться и расширяться. Однако в течение продолжительного периода времени мы будем поддерживать хорошую обратную совместимость с существующими клиентами. В целом, новые ресурсы API и поля ресурсов будут добавляться часто. Удаление ресурсов или полей регулируются [соответствующим процессом](/docs/reference/using-api/deprecation-policy/). + +Определение совместимого изменения и методы изменения API подробно описаны в [документе об изменениях API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md). + +## Определения OpenAPI и Swagger + +Все детали API документируется с использованием [OpenAPI](https://www.openapis.org/). + +Начиная с Kubernetes 1.10, API-сервер Kubernetes основывается на спецификации OpenAPI через конечную точку `/openapi/v2`. +Нужный формат устанавливается через HTTP-заголовоки: + +Заголовок | Возможные значения +------ | --------------- +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 в разных форматах. Эти конечные точки были объявлены устаревшими и удалены в Kubernetes 1.14. + +**Примеры получения спецификации OpenAPI**: + +До 1.10 | С версии Kubernetes 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 + +В Kubernetes реализован альтернативный формат сериализации API, основанный на Protobuf, который в первую очередь предназначен для взаимодействия внутри кластера. Описание этого формата можно найти в [проектом решении](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md), а IDL-файлы по каждой схемы — в пакетах Go, определяющих API-объекты. + +До версии 1.14 apiserver Kubernetes также представлял API, который можно использовать для получения спецификации [Swagger v1.2](http://swagger.io/) для API Kubernetes по пути `/swaggerapi`. Эта конечная точка устарела и была удалена в Kubernetes 1.14 + +## Версионирование API + +Чтобы упростить удаления полей или изменение ресурсов, Kubernetes поддерживает несколько версий API, каждая из которых доступна по собственному пути, например, `/api/v1` или `/apis/extensions/v1beta1`. + +Мы выбрали версионирование API, а не конкретных ресурсов или полей, чтобы API отражал четкое и согласованное представление о системных ресурсах и их поведении, а также, чтобы разграничивать API, которые уже не поддерживаются и/или находятся в экспериментальной стадии. Схемы сериализации JSON и Protobuf следуют одним и тем же правилам по внесению изменений в схему, поэтому описание ниже охватывают оба эти формата. + +Обратите внимание, что версиоирование API и программное обеспечение косвенно связаны друг с другом. [Предложение по версионированию API и новых выпусков](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) описывает, как связаны между собой версии API с версиями программного обеспечения. + +Разные версии API имеют характеризуются разной уровнем стабильностью и поддержкой. Критерии каждого уровня более подробно описаны в [документации изменений API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). Ниже приводится краткое изложение: + +- Альфа-версии: + - Названия версий включают надпись `alpha` (например, `v1alpha1`). + - Могут содержать баги. Включение такой функциональности может привести к ошибкам. По умолчанию она отключена. + - Поддержка функциональности может быть прекращена в любое время без какого-либо оповещения об этом. + - API может быть несовместим с более поздними версиями без упоминания об этом. + - Рекомендуется для использования только в тестировочных кластерах с коротким жизненным циклом из-за высокого риска наличия багов и отсутствия долгосрочной поддержки. +- Бета-версии: + - Названия версий включают надпись `beta` (например, `v2beta3`). + - Код хорошо протестирован. Активация этой функциональности — безопасно. Поэтому она включена по умолчанию. + - Поддержка функциональности в целом не будет прекращена, хотя кое-что может измениться. + - Схема и/или семантика объектов может стать несовместимой с более поздними бета-версиями или стабильными выпусками. Когда это случится, мы даим инструкции по миграции на следующую версию. Это обновление может включать удаление, редактирование и повторного создание API-объектов. Этот процесс может потребовать тщательного анализа. Кроме этого, это может привести к простою приложений, которые используют данную функциональность. + - Рекомендуется только для неосновного производственного использования из-за риска возникновения возможных несовместимых изменений с будущими версиями. Если у вас есть несколько кластеров, которые возможно обновить независимо, вы можете снять это ограничение. + - **Пожалуйста, попробуйте в действии бета-версии функциональности и поделитесь своими впечатлениями! После того, как функциональность выйдет из бета-версии, нам может быть нецелесообразно что-то дальше изменять.** +- Стабильные версии: + - Имя версии `vX`, где `vX` — целое число. + - Стабильные версии функциональностей появятся в новых версиях. + +## API-группы + +Чтобы упростить расширение API Kubernetes, реализованы [*группы API*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md). +Группа API указывается в пути REST и в поле `apiVersion` сериализованного объекта. + +В настоящее время используется несколько API-групп: + +1. Группа *core*, которая часто упоминается как *устаревшая* (*legacy group*), доступна по пути `/api/v1` и использует `apiVersion: v1`. + +1. Именованные группы находятся в пути REST `/apis/$GROUP_NAME/$VERSION` и используют `apiVersion: $GROUP_NAME/$VERSION` (например, `apiVersion: batch/v1`). Полный список поддерживаемых групп API можно увидеть в [справочнике API Kubernetes](/docs/reference/). + +Есть два поддерживаемых пути к расширению API с помощью [пользовательских ресурсов](/docs/concepts/api-extension/custom-resources/): + +1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) для пользователей, которым нужен очень простой CRUD. +2. Пользователи, которым нужна полная семантика API Kubernetes, могут реализовать собственный apiserver и использовать [агрегатор](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) для эффективной интеграции для клиентов. + +## Включение или отключение групп API + +Некоторые ресурсы и группы API включены по умолчанию. Их можно включить или отключить, установив `--runtime-config` для apiserver. Флаг `--runtime-config` принимает значения через запятую. Например, чтобы отключить batch/v1, используйте `--runtime-config=batch/v1=false`, а чтобы включить batch/v2alpha1, используйте флаг `--runtime-config=batch/v2alpha1`. +Флаг набор пар ключ-значение, указанных через запятую, который описывает конфигурацию во время выполнения сервера. + +{{< note >}}Включение или отключение групп или ресурсов требует перезапуска apiserver и controller-manager для применения изменений `--runtime-config`.{{< /note >}} + +## Включение определённых ресурсов в группу extensions/v1beta1 + +DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies и ReplicaSets в API-группе `extensions/v1beta1` по умолчанию отключены. +Например: чтобы включить deployments и daemonsets, используйте флаг `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. + +{{< note >}}Включение/отключение отдельных ресурсов поддерживается только в API-группе `extensions/v1beta1` по историческим причинам.{{< /note >}} + +{{% /capture %}} diff --git a/content/ru/docs/concepts/overview/working-with-objects/_index.md b/content/ru/docs/concepts/overview/working-with-objects/_index.md new file mode 100755 index 0000000000..9f2b4ef4f3 --- /dev/null +++ b/content/ru/docs/concepts/overview/working-with-objects/_index.md @@ -0,0 +1,5 @@ +--- +title: "Работа с объектами Kubernetes" +weight: 40 +--- + diff --git a/content/ru/docs/concepts/overview/working-with-objects/annotations.md b/content/ru/docs/concepts/overview/working-with-objects/annotations.md new file mode 100644 index 0000000000..fd1fd6669b --- /dev/null +++ b/content/ru/docs/concepts/overview/working-with-objects/annotations.md @@ -0,0 +1,79 @@ +--- +title: Аннотации +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} +Аннотации Kubernetes можно использовать для добавления собственных метаданных к объектам. Такие клиенты, как инструменты и библиотеки, могут получить эти метаданные. +{{% /capture %}} + +{{% capture body %}} + +## Добавление метаданных к объектам + +Вы можете использовать метки или аннотации для добавления метаданных к объектам Kubernetes. Метки можно использовать для выбора объектов и для поиска коллекций объектов, которые соответствуют определенным условиям. В отличие от них аннотации не используются для идентификации и выбора объектов. Метаданные в аннотации могут быть маленькими или большими, структурированными или неструктурированными, кроме этого они включать символы, которые не разрешены в метках. + +Аннотации, как и метки, являются коллекциями с наборами пар ключ-значение: + +```json +"metadata": { + "annotations": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + +Некоторые примеры информации, которая может быть в аннотациях: + +* Поля, управляемые декларативным уровнем конфигурации. Добавление этих полей в виде аннотаций позволяет отличать их от значений по умолчанию, установленных клиентами или серверами, а также от автоматически сгенерированных полей и полей, заданных системами автоматического масштабирования. + +* Информация о сборке, выпуске или образе, например, метка времени, идентификаторы выпуска, ветка git, номера PR, хеши образов и адрес реестра. + +* Ссылки на репозитории логирования, мониторинга, аналитики или аудита. + +* Информация о клиентской библиотеке или инструменте, которая может использоваться при отладке (например, имя, версия и информация о сборке). + +* Информация об источнике пользователя или инструмента/системы, например, URL-адреса связанных объектов из других компонентов экосистемы. + +* Небольшие метаданные развертывания (например, конфигурация или контрольные точки). + +* Номера телефонов или пейджеров ответственных лиц или записи в справочнике, в которых можно найти нужную информацию, например, сайт группы. + +* Инструкции от конечных пользователей по исправлению работы или использования нестандартной функциональности. + +Вместо использования аннотаций, вы можете сохранить такого рода информацию во внешней базе данных или директории, хотя это усложнило бы создание общих клиентских библиотек и инструментов развертывания, управления, самодиагностики и т.д. + +## Синтаксис и набор символов + +_Аннотации_ представляют собой пары ключ-значение. Разрешенные ключи аннотации имеют два сегмента, разделённые слешем (`/`): префикс (необязательно) и имя. Сегмент имени обязателен и должен содержать не более 63 символов, среди которых могут быть буквенно-цифровые символы(`[a-z0-9A-Z]`), а также дефисы (`-`), знаки подчеркивания (`_`), точки (`.`). Префикс не обязателен, но он быть поддоменом DNS: набор меток DNS, разделенных точками (`.`), общей длиной не более 253 символов, за которыми следует слеш (`/`). + +Если префикс не указан, ключ аннотации считается закрытым для пользователя. Компоненты автоматизированной системы (например, `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` или другие сторонние), которые добавляют аннотации к объектам пользователя, должны указывать префикс. + +Префиксы `kubernetes.io/` и `k8s.io/` зарезервированы для использования основными компонентами Kubernetes. + +Например, ниже представлен конфигурационный файл объекта Pod с аннотацией `imageregistry: https://hub.docker.com/`: + +```yaml + +apiVersion: v1 +kind: Pod +metadata: + name: annotations-demo + annotations: + imageregistry: "https://hub.docker.com/" +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 + +``` + +{{% /capture %}} + +{{% capture whatsnext %}} +Узнать подробнее про [метки и селекторы](/ru/docs/concepts/overview/working-with-objects/labels/). +{{% /capture %}} diff --git a/content/ru/docs/concepts/overview/working-with-objects/common-labels.md b/content/ru/docs/concepts/overview/working-with-objects/common-labels.md new file mode 100644 index 0000000000..06fe6d8f2d --- /dev/null +++ b/content/ru/docs/concepts/overview/working-with-objects/common-labels.md @@ -0,0 +1,165 @@ +--- +title: Рекомендуемые метки +content_template: templates/concept +--- + +{{% capture overview %}} + +Вы можете визуализировать и управлять объектами Kubernetes не только с помощью kubectl и панели управления. С помощью единого набора меток можно единообразно описывать объекты, что позволяет инструментам согласованно работать между собой. + +В дополнение к существующим инструментам, рекомендуемый набор меток описывают приложения в том виде, в котором они могут быть получены. + +{{% /capture %}} + +{{% capture body %}} + + +Метаданные сосредоточены на понятии _приложение_. Kubernetes — это не платформа как услуга (PaaS), поэтому не закрепляет формальное понятие приложения. +Вместо этого приложения являются неформальными и описываются через метаданные. Определение приложения довольно расплывчатое. + +{{< note >}} + +Это рекомендуемые для использования метки. Они облегчают процесс управления приложениями, но при этом не являются обязательными для основных инструментов. + +{{< /note >}} + +Общие метки и аннотации используют один и тот же префикс: `app.kubernetes.io`. Метки без префикса являются приватными для пользователей. Совместно используемый префикс гарантирует, что общие метки не будут влиять на пользовательские метки. + +## Метки + +Чтобы извлечь максимум пользы от использования таких меток, они должны добавляться к каждому ресурсному объекту. + +| Ключ | Описание | Пример | Тип | +| ----------------------------------- | --------------------- | -------- | ---- | +| `app.kubernetes.io/name` | Имя приложения | `mysql` | string | +| `app.kubernetes.io/instance` | Уникальное имя экземпляра приложения | `wordpress-abcxzy` | string | +| `app.kubernetes.io/version` | Текущая версия приложения (например, семантическая версия, хеш коммита и т.д.) | `5.7.21` | string | +| `app.kubernetes.io/component` | Имя компонента в архитектуре | `database` | string | +| `app.kubernetes.io/part-of` | Имя основного приложения, частью которого является текущий объект | `wordpress` | string | +| `app.kubernetes.io/managed-by` | Инструмент управления приложением | `helm` | string | + +Для демонстрации этих меток, рассмотрим следующий объект `StatefulSet`: + +```yaml +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress + app.kubernetes.io/managed-by: helm +``` + +## Приложения и экземпляры приложений + +Одно и то же приложение может быть установлено несколько раз в кластер Kubernetes, в ряде случаев — в одинаковое пространство имен. Например, WordPress может быть установлен более одного раза, тогда каждый из сайтов будет иметь собственный установленный экземпляр WordPress. + +Имя приложения и имя экземпляра хранятся по отдельности. Например, WordPress имеет ключ `app.kubernetes.io/name` со значением `wordpress`, при этом у него есть имя экземпляра, представленное ключом `app.kubernetes.io/instance` со значением `wordpress-abcxzy`. Такой механизм позволяет идентифицировать как приложение, так и экземпляры приложения. У каждого экземпляра приложения должно быть уникальное имя. + +## Примеры + +Следующие примеры показывают разные способы использования общих меток, поэтому они различаются по степени сложности. + +### Простой сервис без состояния + +Допустим, у нас есть простой сервис без состояния, развернутый с помощью объектов `Deployment` и `Service`. Следующие два фрагмента конфигурации показывают, как можно использовать метки в самом простом варианте. + +Объект `Deployment` используется для наблюдения за подами, на которых запущено приложение. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: myservice + app.kubernetes.io/instance: myservice-abcxzy +... +``` + +Объект `Service` используется для открытия доступа к приложению. + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: myservice + app.kubernetes.io/instance: myservice-abcxzy +... +``` + +### Веб-приложение с базой данных + +Рассмотрим случай немного посложнее: веб-приложение (WordPress), которое использует базу данных (MySQL), установленное с помощью Helm. В следующих фрагментов конфигурации объектов отображена отправная точка развертывания такого приложения. + +Следующий объект `Deployment` используется для WordPress: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: wordpress + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/version: "4.9.4" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: server + app.kubernetes.io/part-of: wordpress +... +``` + +Объект `Service` используется для открытия доступа к WordPress: + + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: wordpress + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/version: "4.9.4" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: server + app.kubernetes.io/part-of: wordpress +... +``` + +MySQL открывается в виде `StatefulSet` с метаданными как для самого приложения, так и основного (родительского) приложения, к которому принадлежит СУБД: + +```yaml +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxzy + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress +... +``` + +Объект `Service` предоставляет MySQL в составе WordPress: + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxzy + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress +... +``` + +Вы заметите, что `StatefulSet` и `Service` MySQL содержат больше информации о MySQL и WordPress. + +{{% /capture %}} diff --git a/content/ru/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ru/docs/concepts/overview/working-with-objects/field-selectors.md new file mode 100644 index 0000000000..207322ca26 --- /dev/null +++ b/content/ru/docs/concepts/overview/working-with-objects/field-selectors.md @@ -0,0 +1,61 @@ +--- +title: Селекторы полей +weight: 60 +--- + +_Селекторы полей_ позволяют [выбирать ресурсы Kubernetes](/ru/docs/concepts/overview/working-with-objects/kubernetes-objects), исходя из значения одного или нескольких полей ресурсов. Ниже приведены несколько примеров запросов селекторов полей: + +* `metadata.name=my-service` +* `metadata.namespace!=default` +* `status.phase=Pending` + +Следующая команда `kubectl` выбирает все Pod-объекты, в которых значение поля [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) равно `Running`: + +```shell +kubectl get pods --field-selector status.phase=Running +``` + +{{< note >}} +По сути, селекторы полей являются *фильтрами* ресурсов. По умолчанию нет установленных селекторов/фильтров, поэтому выбираются ресурсы всех типов. Это означает, что два запроса `kubectl` ниже одинаковы: + +```shell +kubectl get pods +kubectl get pods --field-selector "" +``` +{{< /note >}} + +## Поддерживаемые поля + +Доступные селекторы полей зависят от типа ресурса Kubernetes. У всех типов ресурсов есть поля `metadata.name` и `metadata.namespace`. При использовании несуществующего селекторов полей приведёт к возникновению ошибки. Например: + +```shell +kubectl get ingress --field-selector foo.bar=baz +``` + +``` +Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace" +``` + +## Поддерживаемые операторы + +Можно использовать операторы `=`, `==` и `!=` в селекторах полей (`=` и `==` — синонимы). Например, следующая команда `kubectl` выбирает все сервисы Kubernetes, не принадлежавшие пространству имен `default`: + +```shell +kubectl get services --all-namespaces --field-selector metadata.namespace!=default +``` + +## Составные селекторы + +Аналогично [метки](/ru/docs/concepts/overview/working-with-objects/labels) и другим селекторам, несколько селекторы полей могут быть объединены через запятую. Приведенная ниже команда `kubectl` выбирает все Pod-объекты, у которых значение поле `status.phase`, отличное от `Running`, а поле `spec.restartPolicy` имеет значение `Always`: + +```shell +kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always +``` + +## Множественные типы ресурсов + +Можно использовать селекторы полей с несколькими типами ресурсов одновременно. Команда `kubectl` выбирает все объекты StatefulSet и Services, не включенные в пространство имен `default`: + +```shell +kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default +``` diff --git a/content/ru/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ru/docs/concepts/overview/working-with-objects/kubernetes-objects.md new file mode 100644 index 0000000000..dc8a73cd51 --- /dev/null +++ b/content/ru/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -0,0 +1,80 @@ +--- +title: Изучение объектов Kubernetes +content_template: templates/concept +weight: 10 +card: + name: concepts + weight: 40 +--- + +{{% capture overview %}} + +На этой странице объясняется, как объекты Kubernetes представлены в API Kubernetes, и как их можно определить в формате `.yaml`. + +{{% /capture %}} + +{{% capture body %}} + +## Изучение объектов Kubernetes {#kubernetes-objects} + +*Объекты Kubernetes* — сущности, которые хранятся в Kubernetes. Kubernetes использует их для представления состояния кластера. В частности, они описывают следующую информацию: + +* Какие контейнеризированные приложения запущены (и на каких узлах). +* Доступные ресурсы для этих приложений. +* Стратегии управления приложения, которые относятся, например, к перезапуску, обновлению или отказоустойчивости. + +После создания объекта Kubernetes будет следить за существованием объекта. Создавая объект, вы таким образом указываете системе Kubernetes, какой должна быть рабочая нагрузка кластера; это *требуемое состояние* кластера. + +Для работы с объектами Kubernetes – будь то создание, изменение или удаление — нужно использовать [API Kubernetes](/docs/concepts/overview/kubernetes-api/). Например, при использовании CLI-инструмента `kubectl`, он обращается к API Kubernetes. С помощью одной из [клиентской библиотеки](/docs/reference/using-api/client-libraries/) вы также можете использовать API Kubernetes в собственных программах. + +### Спецификация и статус объекта + +Почти в каждом объекте Kubernetes есть два вложенных поля-объекта, которые управляют конфигурацией объекта: *`spec`* и *`status`*. +При создании объекта в поле `spec` указывается _требуемое состояние_ (описание характеристик, которые должны быть у объекта). + +Поле `status` описывает _текущее состояние_ объекта, которое создаётся и обновляется самим Kubernetes и его компонентами. {{< glossary_tooltip text="Плоскость управления" term_id="control-plane" >}} Kubernetes непрерывно управляет фактическим состоянием каждого объекта, чтобы оно соответствовало требуемому состоянию, которое было задано пользователем. + +Например: Deployment — это объект Kubernetes, представляющий работающее приложение в кластере. При создании объекта Deployment вы можете указать в его поле `spec`, что хотите иметь три реплики приложения. Система Kubernetes получит спецификацию объекта Deployment и запустит три экземпляра приложения, таким образом обновит статус (состояние) объекта, чтобы он соответствовал заданной спецификации. В случае сбоя одного из экземпляров (это влечет за собой изменение состояние), Kubernetes обнаружит несоответствие между спецификацией и статусом и исправит его, т.е. активирует новый экземпляр вместо того, который вышел из строя. + +Для получения дополнительной информации о спецификации объекта, статусе и метаданных смотрите документ с [соглашениями API Kubernetes](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md). + +### Описание объекта Kubernetes + +При создании объекта в Kubernetes нужно передать спецификацию объекта, которая содержит требуемое состояние, а также основную информацию об объекте (например, его имя). Когда вы используете API Kubernetes для создания объекта (напрямую либо через `kubectl`), соответствующий API-запрос должен включать в теле запроса всю указанную информацию в JSON-формате. **В большинстве случаев вы будете передавать `kubectl` эти данные, записанные в файле .yaml**. Тогда инструмент `kubectl` преобразует их в формат JSON при выполнении запроса к API. + +Ниже представлен пример `.yaml`-файла, в котором заданы обязательные поля и спецификация объекта, необходимая для объекта Deployment в Kubernetes: + +{{< codenew file="application/deployment.yaml" >}} + +Один из способов создания объекта Deployment с помощью файла `.yaml`, показанного выше — использовать команду [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply), которая принимает в качестве аргумента файл в формате `.yaml`. Например: + +```shell +kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record +``` + +Вывод будет примерно таким: + +``` +deployment.apps/nginx-deployment created +``` + +### Обязательные поля + +В файле `.yaml` создаваемого объекта Kubernetes необходимо указать значения для следующих полей: + +* `apiVersion` — используемая для создания объекта версия API Kubernetes +* `kind` — тип создаваемого объекта +* `metadata` — данные, позволяющие идентифицировать объект (`name`, `UID` и необязательное поле `namespace`) +* `spec` — требуемое состояние состояние объекта + +Конкретный формат поля-объекта `spec` зависит от типа объекта Kubernetes и содержит вложенные поля, предназначенные только для используемого объекта. В [справочнике API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) можно найти формат спецификации любого объекта Kubernetes. +Например, формат `spec` для объекта Pod находится в [ядре PodSpec v1](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core), а формат `spec` для Deployment — в [DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps). + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [Обзор API Kubernetes](/docs/reference/using-api/api-overview/) более подробно объясняет некоторые из API-концепций +* Познакомиться с наиболее важными и основными объектами в Kubernetes, например, с [подами](/docs/concepts/workloads/pods/pod-overview/). +* Узнать подробнее про [контролеры](/docs/concepts/architecture/controller/) в Kubernetes +{{% /capture %}} diff --git a/content/ru/docs/concepts/overview/working-with-objects/labels.md b/content/ru/docs/concepts/overview/working-with-objects/labels.md new file mode 100644 index 0000000000..b0af52c940 --- /dev/null +++ b/content/ru/docs/concepts/overview/working-with-objects/labels.md @@ -0,0 +1,221 @@ +--- +title: Метки и селекторы +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + +_Метки_ — это пары ключ-значение, которые добавляются к объектам, как поды. +Метки предназначены для идентификации атрибутов объектов, которые имеют значимость и важны для пользователей, но при этом не относятся напрямую к основной системе. +Метки можно использовать для группировки и выбора подмножеств объектов. Метки могут быть добавлены к объектам во время создания и изменены в любое время после этого. +Каждый объект может иметь набор меток в виде пары ключ-значение. Каждый ключ должен быть уникальным в рамках одного и того же объекта. + +```json +"metadata": { + "labels": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + +Метки используются при получении и отслеживании объектов и в веб-панелях и CLI-инструментах. Любая неидентифицирующая информация должна быть записана в [аннотации](/ru/docs/concepts/overview/working-with-objects/annotations/). + +{{% /capture %}} + +{{% capture body %}} + +## Причины использования + +Метки позволяют пользователям гибко сопоставить их организационные структуры с системными объектами, не требуя от клиентов хранить эти соответствия. + +Развертывания сервисов и процессы пакетной обработки часто являются многомерными сущностями (например, множество разделов или развертываний, несколько групп выпусков, несколько уровней приложения, несколько микросервисов на каждый уровень приложения). Для управления часто требуются сквозные операции, которые нарушают инкапсуляцию строго иерархических представлений, особенно жестких иерархий, определяемых инфраструктурой, а не пользователями. + +Примеры меток: + + * `"release" : "stable"`, `"release" : "canary"` + * `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"` + * `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"` + * `"partition" : "customerA"`, `"partition" : "customerB"` + * `"track" : "daily"`, `"track" : "weekly"` + +Это всего лишь примеры часто используемых меток; конечно, вы можете использовать свои собственные. Помните о том, что ключ метки должна быть уникальной в пределах одного объекта. + +## Синтаксис и набор символов + +_Метки_ представляют собой пары ключ-значение. Разрешенные ключи метки имеют два сегмента, разделённые слешем (`/`): префикс (необязательно) и имя. Сегмент имени обязателен и должен содержать не более 63 символов, среди которых могут быть буквенно-цифровые символы (`[a-z0-9A-Z]`), а также дефисы (`-`), знаки подчеркивания (`_`), точки (`.`). Префикс не обязателен, но он быть поддоменом DNS: набор меток DNS, разделенных точками (`.`), общей длиной не более 253 символов, за которыми следует слеш (`/`). + +Если префикс не указан, ключ метки считается закрытым для пользователя. Компоненты автоматизированной системы (например, `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` или другие сторонние), которые добавляют метки к объектам пользователя, должны указывать префикс. + +Префиксы `kubernetes.io/` и `k8s.io/` зарезервированы для использования основными компонентами Kubernetes. + +Например, ниже представлен конфигурационный файл объекта Pod с двумя метками `environment: production` и `app: nginx`: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: label-demo + labels: + environment: production + app: nginx +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 +``` + +## Селекторы меток + +В отличие от [имен и идентификаторов](/docs/user-guide/identifiers), метки не гарантируют уникальность. Поэтому мы предполагаем, что многие объекты будут иметь одинаковые метки. + +С помощью _селектора меток_ клиент/пользователь может идентифицировать набор объектов. Селектор меток — основное средство группировки в Kubernetes. + +В настоящее время API поддерживает два типа селекторов: _на равенстве_ и _на наборе_. +Селектор меток может состоять из нескольких _условий_, разделенных запятыми. В таком случае все условия должны быть выполнены, поэтому запятая-разделитель работает как логический оператор _И_ (`&&`). + +Работа пустых или неопределённых селекторов зависит от контекста. Типы API, которые использует селекторы, должны задокументировать это поведение. + +{{< note >}} +Для некоторых API-типов, например, ReplicaSets, селекторы меток двух экземпляров не должны дублироваться в пространстве имен, в противном случае контроллер может рассматривать их как конфликтующие инструкции и не сможет определить количество реплик. +{{< /note >}} + +{{< caution >}} +Как для условий, основанных на равенстве, так и для условий на основе набора, не существует логического оператора _ИЛИ_ (`||`). Убедитесь, что синтаксис фильтрации правильно составлен. +{{< /caution >}} + +### Условие _равенства_ + +Условия _равенства_ или _неравенства_ позволяют отфильтровать объекты по ключам и значениям меток. Сопоставляемые объекты должны удовлетворять всем указанным условиям меток, хотя при этом у объектов также могут быть заданы другие метки. +Доступны три оператора: `=`,`==`,`!=`. Первые два означают _равенство_ (и являются всего лишь синонимами), а последний оператор определяет _неравенство_. Например: + +``` +environment = production +tier != frontend +``` + +Первый пример выбирает все ресурсы с ключом `environment`, у которого значение указано `production`. +Последний получает все ресурсы с ключом `tier` без значения `frontend`, а также все ресурсы, в которых нет метки с ключом `tier`. +Используя оператор запятой можно совместить показанные два условия в одно, запросив ресурсы, в которых есть значение метки `production` и исключить `frontend`: `environment=production,tier!=frontend`. + +С помощью условия равенства в объектах Pod можно указать, какие нужно выбрать ресурсы. Например, в примере ниже объект Pod выбирает узлы с меткой "`accelerator=nvidia-tesla-p100`". + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: cuda-test +spec: + containers: + - name: cuda-test + image: "k8s.gcr.io/cuda-vector-add:v0.1" + resources: + limits: + nvidia.com/gpu: 1 + nodeSelector: + accelerator: nvidia-tesla-p100 +``` + +### Условие _набора_ + +Условие меток _на основе набора_ фильтрует ключи в соответствии с набором значений. Поддерживаются три вида операторов: `in`, `notin` и `exists` (только идентификатор ключа). Например: + +``` +environment in (production, qa) +tier notin (frontend, backend) +partition +!partition +``` + +В первом примере выбираются все ресурсы с ключом `environment` и значением `production` или `qa`. +Во втором примере выбираются все ресурсы с ключом `tier` и любыми значениями, кроме `frontend` и `backend`, а также все ресурсы без меток с ключом `tier`. +Третий пример выбирает все ресурсы, включая метку с ключом `partition` (с любым значением). +В четвертом примере выбираются все ресурсы без метки с ключом `partition` (с любым значением). +Как и логический оператор _И_ работает разделитель в виде запятой. Таким образом, фильтрация ресурсов по ключу `partition` (вне зависимости от значения) и ключу `environment` с любым значением, кроме `qa`, можно получить с помощью следующего выражения: `partition,environment notin (qa)`. +Селектор меток _на основе набора_ — основная форма равенства, поскольку `environment=production` то же самое, что и `environment in (production)`; аналогично, оператор `!=` соответствует `notin`. + +Условия _набора_ могут использоваться одновременно с условия _равенства_. Например, так: `partition in (customerA, customerB),environment!=qa`. + +## API + +### Фильтрация LIST и WATCH + +Операции LIST и WATCH могут использовать параметр запроса, чтобы указать селекторы меток фильтрации наборов объектов. Есть поддержка обоих условий (строка запроса URL ниже показывается в исходном виде): + + * Условия _на основе равенства_: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` + * Условия _на основе набора_: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` + +Указанные выше формы селектора меток можно использовать для просмотра или отслеживания ресурсов через REST-клиент. Например, `apiserver` с `kubectl`, который использует _условие равенства_: + +```shell +kubectl get pods -l environment=production,tier=frontend +``` + +Либо используя условия _на основе набора_: + +```shell +kubectl get pods -l 'environment in (production),tier in (frontend)' +``` + +Как уже показывалось, _условия набора_ дают больше возможностей. Например, в них можно использовать подобие оператора _И_: + +```shell +kubectl get pods -l 'environment in (production, qa)' +``` + +Либо можно воспользоваться исключающим сопоставлением с помощью оператора _exists_: + +```shell +kubectl get pods -l 'environment,environment notin (frontend)' +``` + +### Установка ссылок в API-объекты + +Некоторые объекты Kubernetes, такие как [`services`](/docs/user-guide/services) и [`replicationcontrollers`](/docs/user-guide/replication-controller), также используют селекторы меток для ссылки на наборы из других ресурсов, например, [подов](/docs/user-guide/pods). + +#### Service и ReplicationController + +Набор подов, на которые указывает `service`, определяется через селектор меток. Аналогичным образом, количество подов, которыми должен управлять `replicationcontroller`, также формируются с использованием селектора меток. + +Селекторы меток для обоих объектов записываются в словарях файлов формата `json` и `yaml`, при этом поддерживаются только селекторы с условием _равенства_: + +```json +"selector": { + "component" : "redis", +} +``` + +Или: + +```yaml +selector: + component: redis +``` + +Этот селектор (как в формате `json`, так и в `yaml`) эквивалентен `component=redis` или `component in (redis)`. + +#### Ресурсы, поддерживающие условия набора + +Новые ресурсы, такие как [`Job`](/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`Deployment`](/docs/concepts/workloads/controllers/deployment/), [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) и [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/), также поддерживают условия _набора_. + +```yaml +selector: + matchLabels: + component: redis + matchExpressions: + - {key: tier, operator: In, values: [cache]} + - {key: environment, operator: NotIn, values: [dev]} +``` + +`matchLabels` — словарь пар `{key,value}`. Каждая пара `{key,value}` в словаре `matchLabels` эквивалентна элементу `matchExpressions`, где поле `key` — "key", поле `operator` — "In", а массив `values` содержит только "value". +`matchExpressions` представляет собой список условий селектора пода. В качестве операторов могут быть In, NotIn, Exists и DoesNotExist. В случае использования In и NotIn должны заданы непустые значения. Все условия, как для `matchLabels`, так и для `matchExpressions`, объединяются с помощью логического И, поэтому при выборке объектов все они должны быть выполнены. + +#### Выбор наборов узлов + +Один из вариантов использования меток — возможность выбора набора узлов, в которых может быть развернут под. +Смотрите документацию про [выбор узлов](/docs/concepts/configuration/assign-pod-node/), чтобы получить дополнительную информацию. + +{{% /capture %}} diff --git a/content/ru/docs/concepts/overview/working-with-objects/names.md b/content/ru/docs/concepts/overview/working-with-objects/names.md new file mode 100644 index 0000000000..aedbb44667 --- /dev/null +++ b/content/ru/docs/concepts/overview/working-with-objects/names.md @@ -0,0 +1,78 @@ +--- +title: Имена и идентификаторы объектов +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +Каждый объект в кластере имеет уникальное [_имя_](#имена) для конкретного типа ресурса. +Кроме этого, у каждого объекта Kubernetes есть собственный [_уникальный идентификатор (UID)_](#идентификаторы) в пределах кластера. + +Например, в одном и том же [пространстве имён](/ru/docs/concepts/overview/working-with-objects/namespaces/) может быть только один Pod-объект с именем `myapp-1234`, и при этом существовать объект Deployment с этим же названием `myapp-1234`. + +Для создания пользовательских неуникальных атрибутов у Kubernetes есть [метки](/ru/docs/concepts/overview/working-with-objects/labels/) и [аннотации](/ru/docs/concepts/overview/working-with-objects/annotations/). + +{{% /capture %}} + +{{% capture body %}} + +## Имена + +{{< glossary_definition term_id="name" length="all" >}} + +Ниже перечислены три типа распространённых требований к именам ресурсов. + +### Имена поддоменов DNS + +Большинству типов ресурсов нужно указать имя, используемое в качестве имени поддомена DNS в соответствии с [RFC 1123](https://tools.ietf.org/html/rfc1123). Соответственно, имя должно: + +- содержать не более 253 символов +- иметь только строчные буквенно-цифровые символы, '-' или '.' +- начинаться с буквенно-цифрового символа +- заканчивается буквенно-цифровым символом + +### Имена меток DNS + +Некоторые типы ресурсов должны соответствовать стандарту меток DNS, который описан в [RFC 1123](https://tools.ietf.org/html/rfc1123). Таким образом, имя должно: + +- содержать не более 63 символов +- содержать только строчные буквенно-цифровые символы или '.' +- начинаться с буквенно-цифрового символа +- заканчивается буквенно-цифровым символом + +### Имена сегментов пути + +Определённые имена типов ресурсов должны закодированы для использования в качестве сегмента пути. Проще говоря, имя не может быть "." или "..", а также не может содержать "/" или "%". + +Пример файла манифеста пода `nginx-demo`. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx-demo +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 +``` + +{{< note >}} +У отдельных типов ресурсов есть дополнительные ограничения именования. +{{< /note >}} + +## Уникальные идентификаторы + +{{< glossary_definition term_id="uid" length="all" >}} + +Уникальные идентификатор (UID) в Kubernetes — это универсальные уникальные идентификаторы (известные также как Universally Unique IDentifier, сокращенно UUID). +Эти идентификаторы стандартизированы под названием ISO/IEC 9834-8, а также как ITU-T X.667. + +{{% /capture %}} +{{% capture whatsnext %}} +* Узнать подробнее про [метки](/ru/docs/concepts/overview/working-with-objects/labels/) в Kubernetes. +* Посмотреть архитектуру [идентификаторов и имён Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md). +{{% /capture %}} diff --git a/content/ru/docs/concepts/overview/working-with-objects/namespaces.md b/content/ru/docs/concepts/overview/working-with-objects/namespaces.md new file mode 100644 index 0000000000..75eae895ed --- /dev/null +++ b/content/ru/docs/concepts/overview/working-with-objects/namespaces.md @@ -0,0 +1,97 @@ +--- +title: Пространства имён +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +Kubernetes поддерживает несколько виртуальных кластеров в одном физическом кластере. Такие виртуальные кластеры называются пространствами имён. + +{{% /capture %}} + +{{% capture body %}} + +## Причины использования нескольких пространств имён + +Пространства имён применяются в окружениях с многочисленными пользователями, распределенными по нескольким командам или проектам. Пространства имён не нужно создавать, если есть кластеры с небольшим количеством пользователей (например, десяток пользователей). Пространства имён имеет смысл использовать, когда необходима такая функциональность. + +Пространства имён определяют область имён. Имена ресурсов должны быть уникальными в пределах одного и того же пространства имён. Пространства имён не могут быть вложенными, а каждый ресурс Kubernetes может находиться только в одном пространстве имён. + +Пространства имён — это способ разделения ресурсов кластера между несколькими пользователями (с помощью [квоты ресурсов](/docs/concepts/policy/resource-quotas/)). + +По умолчанию в будущих версиях Kubernetes объекты в одном и том же пространстве имён будут иметь одинаковую политику контроля доступа. + +Не нужно использовать пространства имён только для разделения слегка отличающихся ресурсов, например, в случае разных версий одного и того же приложения. Используйте [метки](/ru/docs/concepts/overview/working-with-objects/labels/), чтобы различать ресурсы в рамках одного пространства имён. + +## Использование пространств имён + +Создание и удаление пространств имён описаны в [руководстве администратора по пространствам имён](/docs/admin/namespaces). + +### Просмотр пространств имён + +Используйте следующую команду, чтобы вывести список существующих пространств имён в кластере: + +```shell +kubectl get namespace +``` +``` +NAME STATUS AGE +default Active 1d +kube-system Active 1d +kube-public Active 1d +``` + +По умолчанию в Kubernetes определены три пространства имён: + + * `default` — пространство имён по умолчанию для объектов без какого-либо другого пространства имён. + * `kube-system` — пространство имён для объектов, созданных Kubernetes + * `kube-public` — создаваемое автоматически пространство имён, которое доступно для чтения всем пользователям (включая также неаутентифицированных пользователей). Как правило, это пространство имён используется кластером, если некоторые ресурсы должны быть общедоступными для всего кластера. Главная особенность этого пространства имён — оно всего лишь соглашение, а не требование. + +### Определение пространства имён для отдельных команд + +Используйте флаг `--namespace`, чтобы определить пространство имён только для текущего запроса. + +Примеры: + +```shell +kubectl run nginx --image=nginx --namespace= +kubectl get pods --namespace= +``` + +### Определение пространства имён для всех команд + +Можно определить пространство имён, которое должно использоваться для всех выполняемых команд kubectl в текущем контексте. + +```shell +kubectl config set-context --current --namespace= +# Проверка +kubectl config view --minify | grep namespace: +``` + +## Пространства имён и DNS + +При создании [сервиса](/docs/user-guide/services) создаётся соответствующая ему [DNS-запись](/docs/concepts/services-networking/dns-pod-service/). +Эта запись вида `..svc.cluster.local` означает, что если контейнер использует только ``, то он будет локальным сервисом в пространстве имён. Это позволит применять одну и ту же конфигурацию в нескольких пространствах имен (например, development, staging и production). Если нужно обращаться к другим пространствам имён, то нужно использовать полностью определенное имя домена (FQDN). + +## Объекты без пространства имён + +Большинство ресурсов Kubernetes (например, поды, сервисы, контроллеры репликации и другие) расположены в определённых пространствах имён. При этом сами ресурсы пространства имён не находятся ни в других пространствах имён. А такие низкоуровневые ресурсы, как [узлы](/docs/admin/node) и persistentVolumes, не принадлежат ни одному пространству имён. + +Чтобы посмотреть, какие ресурсы Kubernetes находятся в пространстве имён, а какие — нет, используйте следующие команды: + +```shell +# Ресурсы в пространстве имён +kubectl api-resources --namespaced=true + +# Ресурсы, не принадлежавшие ни одному пространству имён +kubectl api-resources --namespaced=false +``` + +{{% /capture %}} + +{{% capture whatsnext %}} +* Узнать подробнее про [создание нового пространства имён](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace). +* Узнать подробнее про [удаление пространства имён](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace). + +{{% /capture %}} diff --git a/content/ru/docs/concepts/overview/working-with-objects/object-management.md b/content/ru/docs/concepts/overview/working-with-objects/object-management.md new file mode 100644 index 0000000000..c440ea082b --- /dev/null +++ b/content/ru/docs/concepts/overview/working-with-objects/object-management.md @@ -0,0 +1,168 @@ +--- +title: Управление объектами Kubernetes +content_template: templates/concept +weight: 15 +--- + +{{% capture overview %}} + +В инструменте командной строки `kubectl` есть несколько разных способов создания и управления объектами Kubernetes. На этой странице рассматриваются различные подходы. Изучите [документацию по Kubectl](https://kubectl.docs.kubernetes.io) для получения подробной информации по управлению объектами с помощью Kubectl. + +{{% /capture %}} + +{{% capture body %}} + +## Способы управления + +{{< warning >}} + +Используйте только один способ для управления объектами Kubernetes. Применение нескольких методов управления к одному и тому же объекту может привести к неопределенному поведению. + +{{< /warning >}} + +| Способ управления | Область применения |Рекомендуемое окружение | Количество поддерживаемых авторов | Трудность изучения | +|----------------------------------|----------------------|------------------------|--------------------|----------------| +| Императивные команды | Активные объекты | Проекты в стадии разработки | 1+ | Низкая | +| Императивная конфигурация объекта | Отдельные файлы | Продакшен-проекты | 1 | Средняя | +| Декларативная конфигурация объекта | Директории или файлы | Продакшен-проекты | 1+ | Сложная | + +## Императивные команды + +При использовании императивных команд пользователь работает непосредственно с активными (текущими) объектами в кластере. Пользователь указывает выполняемые операции команде `kubectl` в качестве аргументов или флагов. + +Это самый простой способ начать или выполнять одноразовые задачи в кластере. Из-за того, что происходит работа с активными объектами напрямую, нет возможности посмотреть историю предыдущих конфигураций. + +### Примеры + +Запустите экземпляр контейнера nginx, посредством создания объекта Deployment: + +```sh +kubectl run nginx --image nginx +``` + +То же самое, но с другим синтаксисом: + +```sh +kubectl create deployment nginx --image nginx +``` + +### Плюсы и минусы + +Преимущества по сравнению с конфигурацией объекта: + +- Простые команды, которые легко выучить и запомнить. +- Для применения изменений в кластер нужно только выполнить команды. + +Недостатки по сравнению с конфигурацией объекта: + +- Команды не интегрированы с процессом проверки (обзора) изменений. +- У команд нет журнала с изменениями. +- Команды не дают источник записей, за исключением активных объектов. +- Команды не содержат шаблон для создания новых объектов. + +## Императивная конфигурация объекта + +В случае использования императивной конфигурации объекта команде kubectl устанавливают действие (создание, замена и т.д.), необязательные флаги и как минимум одно имя файла. Файл должен содержать полное определение объекта в формате YAML или JSON. + +Посмотрите [Справочник API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) для получения более подробной информации про определения объекта. + +{{< warning >}} + +Императивная команда `replace` заменяет существующую спецификацию новой (переданной), удаляя все изменения в объекте, которые не определены в конфигурационном файле. Такой подход не следует использовать для типов ресурсов, спецификации которых обновляются независимо от конфигурационного файла. +Например, поле `externalIPs` в сервисах типа `LoadBalancer` обновляется кластером независимо от конфигурации. + +{{< /warning >}} + +### Примеры + +Создать объекты, определенные в конфигурационном файле: + +```sh +kubectl create -f nginx.yaml +``` + +Удалить объекты, определенные в двух конфигурационных файлах: + +```sh +kubectl delete -f nginx.yaml -f redis.yaml +``` + +Обновить объекты, определенные в конфигурационном файле, перезаписав текущую конфигурацию: + +```sh +kubectl replace -f nginx.yaml +``` + +### Плюсы и минусы + +Преимущества по сравнению с императивными командами: + +- Конфигурация объекта может храниться в системе управления версиями, такой как Git. +- Конфигурация объекта может быть интегрирована с процессами проверки изменений и логирования. +- Конфигурация объекта предусматривает шаблон для создания новых объектов. + +Недостатки по сравнению с императивными командами: + +- Конфигурация объекта требует наличие общего представления об схеме объекта. +- Конфигурация объекта предусматривает написание файла YAML. + +Преимущества по сравнению с декларативной конфигурацией объекта: + +- Императивная конфигурация объекта проще и легче для понимания. +- Начиная с Kubernetes 1.5, конфигурация императивных объектов стала лучше и совершеннее. + +Недостатки по сравнению с декларативной конфигурацией объекта: + +- Императивная конфигурация объекта наилучшим образом работает с файлами, а не с директориями. +- Обновления текущих объектов должны быть описаны в файлах конфигурации, в противном случае они будут потеряны при следующей замене. + +## Декларативная конфигурация объекта + +При использовании декларативной конфигурации объекта пользователь работает с локальными конфигурационными файлами объекта, при этом он не определяет операции, которые будут выполняться над этими файлами. Операции создания, обновления и удаления автоматически для каждого объекта определяются `kubectl`. Этот механизм позволяет работать с директориями, в ситуациях, когда для разных объектов может потребоваться выполнение других операций. + +{{< note >}} +Декларативная конфигурация объекта сохраняет изменения, сделанные другими, даже если эти изменения не будут зафиксированы снова в конфигурационный файл объекта. +Это достигается путем использования API-операции `patch`, чтобы записать только обнаруженные изменения, а не использовать для этого API-операцию `replace`, которая полностью заменяет конфигурацию объекта. +{{< /note >}} + +### Примеры + +Обработать все конфигурационные файлы объектов в директории `configs` и создать либо частично обновить активные объекты. Сначала можно выполнить `diff`, чтобы посмотреть, какие изменения будут внесены, и только после этого применить их: + +```sh +kubectl diff -f configs/ +kubectl apply -f configs/ +``` + +Рекурсивная обработка директорий: + +```sh +kubectl diff -R -f configs/ +kubectl apply -R -f configs/ +``` + +### Плюсы и минусы + +Преимущества по сравнению с императивной конфигурацией объекта: + +- Изменения, внесенные непосредственно в активные объекты, будут сохранены, даже если они не отражены в конфигурационных файлах. +- Декларативная конфигурация объекта лучше работает с директориями и автоматически определяет тип операции (создание, частичное обновление, удаление) каждого объекта. + +Недостатки по сравнению с императивной конфигурацией объекта: + +- Декларативную конфигурацию объекта сложнее отладить и понять, когда можно получить неожиданные результаты. +- Частичные обновления с использованием различий приводит к сложным операциям слияния и исправления. + +{{% /capture %}} + +{{% capture whatsnext %}} + +- [Управление объектами Kubernetes с помощью императивных команд](/docs/tasks/manage-kubernetes-objects/imperative-command/) +- [Управление объектами Kubernetes с помощью императивной конфигурации объекта](/docs/tasks/manage-kubernetes-objects/imperative-config/) +- [Управление объектами Kubernetes с помощью декларативной конфигурации объекта](/docs/tasks/manage-kubernetes-objects/declarative-config/) +- [Управление объектами Kubernetes с помощью Kustomize (декларативный способ)](/docs/tasks/manage-kubernetes-objects/kustomization/) +- [Справочник по командам Kubectl](/docs/reference/generated/kubectl/kubectl-commands/) +- [Документация Kubectl](https://kubectl.docs.kubernetes.io) +- [Справочник API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) + +{{% /capture %}} diff --git a/content/ru/docs/contribute/start.md b/content/ru/docs/contribute/start.md index 91515c378c..da0af7eb22 100644 --- a/content/ru/docs/contribute/start.md +++ b/content/ru/docs/contribute/start.md @@ -25,21 +25,12 @@ card: Вы можете создавать новые задачи, редактировать содержимое и проверять изменения от других участников, — всё это доступно с сайта GitHub. Вы также можете использовать встроенный в GitHub поиск и историю коммитов. -<<<<<<< HEAD Не все задачи могут быть выполнены с помощью интерфейса GitHub, но некоторые из них обсуждаются в руководствах для [продвинутых](/ru/docs/contribute/intermediate/) и [опытных](/ru/docs/contribute/advanced/) участников. ### Участие в документации SIG Документация Kubernetes поддерживается {{< glossary_tooltip text="специальной группой" term_id="sig" >}} (Special Interest Group, SIG) под названием SIG Docs. Мы [общаемся](#participate-in-sig-docs-discussions) с помощью канала Slack, списка рассылки и еженедельных видеозвонков. Будем рады новым участникам. Для получения дополнительной информации обратитесь к странице [Участие в SIG Docs](ru/docs/contribute/participating/). -======= -Не все задачи могут быть выполнены на GitHub, поэтому они обсуждаются в [intermediate](/docs/contribute/intermediate/) and -[advanced](/docs/contribute/advanced/) docs contribution guides. - -### Участие в документации SIG - -Документация Kubernetes поддерживается {{< glossary_tooltip text="специальной группой" term_id="sig" >}} (Special Interest Group, SIG) под названием SIG Docs. Мы [общаемся](#participate-in-sig-docs-discussions) с помощью канала Slack, списка рассылки и еженедельных видеозвонков. Будем рады новым участникам. Для получения дополнительной информации обратитесь к странице [Participating in SIG Docs](/docs/contribute/participating/). ->>>>>>> bc6cb17bb... Translate Start contributing page into Russian (#19124) ### Руководящие принципы по содержанию @@ -49,11 +40,7 @@ card: Мы поддерживаем [руководство по оформлению](/docs/contribute/style/style-guide/) с информацией о выборе, сделанном сообществом SIG Docs в отношении грамматики, синтаксиса, исходного форматирования и типографских соглашений. Прежде чем сделать свой первый вклад, просмотрите руководство по стилю и используйте его, когда у вас есть вопросы. -<<<<<<< HEAD SIG Docs совместными усилиями вносит изменения в руководство по оформлению. Чтобы предложить изменение или дополнение, добавьте его в повестку дня предстоящей встречи SIG Docs и посетите её, чтобы принять участие в обсуждении. Смотрите руководство для [продвинутых участников](/docs/contribute/advanced/), чтобы получить дополнительную информацию. -======= -SIG Docs совместными усилиями вносит изменения в руководство по оформлению. Чтобы предложить изменение или дополнение, добавьте его в повестку дня предстоящей встречи SIG Docs и посетите её, чтобы принять участие в обсуждении. Смотрите страницу с [продвинутым руководством](/docs/contribute/advanced/) для получения дополнительной информации. ->>>>>>> bc6cb17bb... Translate Start contributing page into Russian (#19124) ### Шаблоны страниц @@ -69,11 +56,7 @@ SIG Docs совместными усилиями вносит изменения Более подробную информацию про участие в работе над документацией на нескольких языках ["Localize content"](/docs/contribute/intermediate#localize-content) в промежуточном руководстве по добавлению. -<<<<<<< HEAD Если вы заинтересованы в переводе документации на новый язык, посмотрите раздел ["Локализация"](/ru/docs/contribute/localization/). -======= -Если вы заинтересованы в переводе документации на новый язык, посмотрите раздел ["Локализация"](/docs/contribute/localization/). ->>>>>>> bc6cb17bb... Translate Start contributing page into Russian (#19124) ## Создание хороших заявок @@ -83,11 +66,7 @@ SIG Docs совместными усилиями вносит изменения - **Для существующей страницы** -<<<<<<< HEAD Если заметили проблему на существующей странице в [документации Kubernetes](/ru/docs/), перейдите в конец страницы и нажмите кнопку **Create an Issue**. Если вы ещё не авторизованы в GitHub, сделайте это. После этого откроется страница с форма для создания нового запроса в GitHub с уже предварительно заполненным полями. -======= - Если заметили проблему на существующей странице в [документации Kubernetes](/docs/), перейдите в конец страницы и нажмите кнопку **Create an Issue**. Если вы ещё не авторизованы в GitHub, сделайте это. После этого откроется страница с форма для создания нового запроса в GitHub с уже предварительно заполненным полями. ->>>>>>> bc6cb17bb... Translate Start contributing page into Russian (#19124) При помощи разметки Markdown опишите как можно подробнее, что хотите. Там, где вы видите пустые квадратные скобки (`[ ]`), проставьте `x` между скобками. Если у вас есть предлагаемое решение проблемы, напишите его. @@ -127,11 +106,7 @@ SIG Docs совместными усилиями вносит изменения Примечание. Разработчики кода Kubernetes. Если вы документируете новую функцию для предстоящего выпуска Kubernetes, ваш процесс будет немного другим. См. Документирование функции для руководства по процессу и информации о сроках. {{< note >}} -<<<<<<< HEAD **Для разработчиков кода Kubernetes**: если вы документируете новую функциональность для новой версии Kubernetes, то процесс рассмотрения будет немного другим. Посетите страницу [Документирование функциональности](/ru/docs/contribute/intermediate/#добавление-документации-для-новой-функциональности), чтобы узнать про процесс и информацию о крайних сроках. -======= -**Для разработчиков кода Kubernetes**: если вы документируете новую функциональность для новой версии Kubernetes, то процесс рассмотрения будет немного другим. Посетите страницу [Документирование функциональности](/docs/contribute/intermediate/#sig-members-documenting-new-features), чтобы узнать про процесс и информацию о крайних сроках. ->>>>>>> bc6cb17bb... Translate Start contributing page into Russian (#19124) {{< /note >}} ### Подписание CLA-соглашения CNCF {#sign-the-cla} @@ -141,11 +116,7 @@ SIG Docs совместными усилиями вносит изменения ### Поиск задач для работы -<<<<<<< HEAD Если вы уже нашли что исправить, просто следуйте инструкциям ниже. Для этого вам не обязательно [создавать ишью](#создание-хороших-заявок) (хотя вы, безусловно, пойти этим путём). -======= -Если вы уже нашли что исправить, просто следуйте инструкциям ниже. Для этого вам не обязательно [создавать ишью](#file-actionable-issues) (хотя вы, безусловно, пойти этим путём). ->>>>>>> bc6cb17bb... Translate Start contributing page into Russian (#19124) Если вы хотите ещё не определились с тем, над чем хотите поработать, перейдите по адресу [https://github.com/kubernetes/website/issues](https://github.com/kubernetes/website/issues) и найдите ишью с меткой `good first issue` (вы можете использовать [эту](https://github.com/kubernetes/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) ссылку для быстрого поиска). Прочитайте комментарии, чтобы убедиться что нет открытого пулреквеста для решения текущей ишью, а также, что никто другой не оставил комментарий, что он работает над этой задачей в последнее время (как правило, 3 дня). Добавьте комментарий, что вы хотели бы заняться решением этой задачи. @@ -203,11 +174,7 @@ SIG Docs совместными усилиями вносит изменения 7. Если ваши изменения одобрены, то рецензент объединяет соответствующий пулреквест. Через несколько минут вы сможете сможете увидеть его в действии на сайте Kubernetes. -<<<<<<< HEAD Это только один из способов отправить пулреквест. Если вы уже опытный пользователь Git и GitHub, вы можете вносить изменения, используя локальный GUI-клиент или Git из терминала вместо того, чтобы использовать интерфейс GitHub для этого. Некоторые основы использования Git-клиента из командной строки обсуждаются в руководстве для [продвинутого участника](/ru/docs/contribute/intermediate/). -======= -Это только один из способов отправить пулреквест. Если вы уже опытный пользователь Git и GitHub, вы можете вносить изменения, используя локальный GUI-клиент или Git из терминала вместо того, чтобы использовать интерфейс GitHub для этого. Некоторые основы использования Git-клиента из командной строки обсуждаются в [продвинутом](/docs/contribute/intermediate/) руководстве участника. ->>>>>>> bc6cb17bb... Translate Start contributing page into Russian (#19124) ## Просмотр пулреквестов в документацию diff --git a/content/ru/docs/reference/glossary/name.md b/content/ru/docs/reference/glossary/name.md new file mode 100755 index 0000000000..97d9873b82 --- /dev/null +++ b/content/ru/docs/reference/glossary/name.md @@ -0,0 +1,17 @@ +--- +title: Имя +id: name +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/names +short_description: > + Клиентская строка, предназначенная для ссылки на объект в URL-адресе ресурса, например `/api/v1/pods/some-name`. + +aka: +tags: +- fundamental +--- + Клиентская строка, предназначенная для ссылки на объект в URL-адресе ресурса, например `/api/v1/pods/some-name`. + + + +Указанное имя может иметь только один объект определённого типа. Но если вы удалите этот объект, вы можете создать новый с таким же именем diff --git a/content/ru/docs/reference/glossary/uid.md b/content/ru/docs/reference/glossary/uid.md new file mode 100755 index 0000000000..fe050683ba --- /dev/null +++ b/content/ru/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: > + Уникальная строка, сгенерированная самим Kubernetes, для идентификации объектов. + +aka: +tags: +- fundamental +--- + Уникальная строка, сгенерированная самим Kubernetes, для идентификации объектов. + + + +У каждого объекта, созданного в течение всего периода работы кластера Kubernetes, есть собственный уникальный идентификатор (UID). Он предназначен для выяснения различий между событиями похожих сущностей. \ No newline at end of file diff --git a/content/ru/docs/setup/learning-environment/minikube.md b/content/ru/docs/setup/learning-environment/minikube.md index 586a491ad3..0aac092ae3 100644 --- a/content/ru/docs/setup/learning-environment/minikube.md +++ b/content/ru/docs/setup/learning-environment/minikube.md @@ -67,7 +67,7 @@ Minikube поддерживает следующие возможности Kube deployment.apps/hello-minikube created ``` -3. Чтобы получить доступ к объекту Deployment `hello-minikube` извне, создайте объект сервиса (Service): +3. Чтобы получить доступ к объекту Deployment `hello-minikube` извне, создайте объект сервиса (Service): ```shell kubectl expose deployment hello-minikube --type=NodePort --port=8080 @@ -81,32 +81,34 @@ Minikube поддерживает следующие возможности Kube service/hello-minikube exposed ``` -4. Под (Pod) `hello-minikube` теперь запущен, но нужно подождать, пока он начнёт функционировать, прежде чем обращаться к нему. +4. Под (Pod) `hello-minikube` теперь запущен, но нужно подождать, пока он начнёт функционировать, прежде чем обращаться к нему. - Проверьте, что под работает: + Проверьте, что под работает: - ```shell - kubectl get pod - ``` + ```shell + kubectl get pod + ``` - Если в столбце вывода `STATUS` выводится `ContainerCreating`, значит под все еще создается: + Если в столбце вывода `STATUS` выводится `ContainerCreating`, значит под все еще создается: - ``` - NAME READY STATUS RESTARTS AGE - hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s - ``` + ``` + NAME READY STATUS RESTARTS AGE + hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s + ``` - Если в столбце `STATUS` указано `Running`, то под теперь в рабочем состоянии: + Если в столбце `STATUS` указано `Running`, то под теперь в рабочем состоянии: + + ``` + NAME READY STATUS RESTARTS AGE + hello-minikube-3383150820-vctvh 1/1 Running 0 13s + ``` - ``` - NAME READY STATUS RESTARTS AGE - hello-minikube-3383150820-vctvh 1/1 Running 0 13s - ``` 5. Узнайте URL-адрес открытого (exposed) сервиса, чтобы просмотреть подробные сведения о сервисе: - ```shell - minikube service hello-minikube --url - ``` + ```shell + minikube service hello-minikube --url + ``` + 6. Чтобы ознакомиться с подробной информацией о локальном кластере, скопируйте и откройте полученный из вывода команды на предыдущем шаге URL-адрес в браузере. Вывод будет примерно следующим: @@ -138,7 +140,8 @@ Minikube поддерживает следующие возможности Kube -no body in request- ``` - Если сервис и кластер вам больше не нужны, их можно удалить. + Если сервис и кластер вам больше не нужны, их можно удалить. + 7. Удалите сервис `hello-minikube`: ```shell @@ -150,6 +153,7 @@ Minikube поддерживает следующие возможности Kube ``` service "hello-minikube" deleted ``` + 8. Удалите развёртывание `hello-minikube`: ```shell @@ -161,17 +165,24 @@ Minikube поддерживает следующие возможности Kube ``` deployment.extensions "hello-minikube" deleted ``` + 9. Остановите локальный кластер Minikube: + ```shell minikube stop ``` + Вывод будет примерно следующим: + ``` Stopping "minikube"... "minikube" stopped. ``` - Подробности смотрите в разделе [Остановка кластера](#остановка-кластера). + + Подробности смотрите в разделе [Остановка кластера](#остановка-кластера). + 10. Удалите локальный кластер Minikube: + ```shell minikube delete ``` @@ -182,7 +193,8 @@ Minikube поддерживает следующие возможности Kube Deleting "minikube" ... The "minikube" cluster has been deleted. ``` - Подробности смотрите в разделе [Удаление кластера](#удаление-кластера). + + Подробности смотрите в разделе [Удаление кластера](#удаление-кластера). ## Управление кластером @@ -357,16 +369,19 @@ Minikube имеет такую возможность как "конфигура Чтобы изменить настройку `AuthorizationMode` в `apiserver` на значение `RBAC`, используйте флаг `--extra-config=apiserver.authorization-mode=RBAC`. ### Остановка кластера + Команда `minikube stop` используется для остановки кластера. Эта команда выключает виртуальную машины Minikube, но сохраняет всё состояние кластера и данные. Повторный запуск кластера вернет его в прежнее состояние. ### Удаление кластера + Команда `minikube delete` используется для удаления кластера. Эта команда выключает и удаляет виртуальную машину Minikube. Данные или состояние не сохраняются. ### Обновление minikube + Смотрите [инструкцию по обновлению minikube](https://minikube.sigs.k8s.io/docs/start/macos/). ## Работа с кластером @@ -440,6 +455,7 @@ spec: ``` ## Смонтированные директории хоста + Некоторые драйверы монтируют директорию хоста в виртуальную машину, чтобы можно было легко обмениваться файлами между виртуальной машиной и хостом. В настоящее время это не настраивается и отличается от используемого драйвера и ОС. {{< note >}} diff --git a/content/ru/examples/application/deployment.yaml b/content/ru/examples/application/deployment.yaml new file mode 100644 index 0000000000..f7a4886e4e --- /dev/null +++ b/content/ru/examples/application/deployment.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 # до версии 1.9.0 нужно использовать apps/v1beta2 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 2 # запускает 2 пода, созданных по шаблону + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 diff --git a/content/uk/OWNERS b/content/uk/OWNERS new file mode 100644 index 0000000000..09fbf1170c --- /dev/null +++ b/content/uk/OWNERS @@ -0,0 +1,13 @@ +# See the OWNERS docs at https://go.k8s.io/owners + +# This is the directory for Ukrainian source content. +# Teams and members are visible at https://github.com/orgs/kubernetes/teams. + +reviewers: +- sig-docs-uk-reviews + +approvers: +- sig-docs-uk-owners + +labels: +- language/uk diff --git a/content/uk/_common-resources/index.md b/content/uk/_common-resources/index.md new file mode 100644 index 0000000000..ca03031f1e --- /dev/null +++ b/content/uk/_common-resources/index.md @@ -0,0 +1,3 @@ +--- +headless: true +--- diff --git a/content/uk/_index.html b/content/uk/_index.html new file mode 100644 index 0000000000..02df4d395d --- /dev/null +++ b/content/uk/_index.html @@ -0,0 +1,85 @@ +--- +title: "Довершена система оркестрації контейнерів" +abstract: "Автоматичне розгортання, масштабування і управління контейнерами" +cid: home +--- + +{{< announcement >}} + +{{< deprecationwarning >}} + +{{< blocks/section id="oceanNodes" >}} +{{% blocks/feature image="flower" %}} + +### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) - це система з відкритим вихідним кодом для автоматичного розгортання, масштабування і управління контейнеризованими застосунками. + + +Вона об'єднує контейнери, що утворюють застосунок, у логічні елементи для легкого управління і виявлення. В основі Kubernetes - [15 років досвіду запуску і виконання застосунків у продуктивних середовищах Google](http://queue.acm.org/detail.cfm?id=2898444), поєднані з найкращими ідеями і практиками від спільноти. +{{% /blocks/feature %}} + +{{% blocks/feature image="scalable" %}} + +#### Глобальне масштабування + + +Заснований на тих самих принципах, завдяки яким Google запускає мільярди контейнерів щотижня, Kubernetes масштабується без потреби збільшення вашого штату з експлуатації. + +{{% /blocks/feature %}} + +{{% blocks/feature image="blocks" %}} + +#### Невичерпна функціональність + + +Запущений для локального тестування чи у глобальній корпорації, Kubernetes динамічно зростатиме з вами, забезпечуючи регулярну і легку доставку ваших застосунків незалежно від рівня складності ваших потреб. + +{{% /blocks/feature %}} + +{{% blocks/feature image="suitcase" %}} + +#### Працює всюди + + +Kubernetes - проект з відкритим вихідним кодом. Він дозволяє скористатися перевагами локальної, гібридної чи хмарної інфраструктури, щоб легко переміщати застосунки туди, куди вам потрібно. + +{{% /blocks/feature %}} + +{{< /blocks/section >}} + +{{< blocks/section id="video" background-image="kub_video_banner_homepage" >}} +
+ +

Проблеми міграції 150+ мікросервісів у Kubernetes

+ +

Сара Уеллз, технічний директор з експлуатації і безпеки роботи, Financial Times

+ +
+
+
+ Відвідати KubeCon в Амстердамі, 30.03-02.04 2020 +
+
+
+
+ Відвідати KubeCon у Шанхаї, 28-30 липня 2020 +
+
+ + +
+{{< /blocks/section >}} + +{{< blocks/kubernetes-features >}} + +{{< blocks/case-studies >}} diff --git a/content/uk/case-studies/_index.html b/content/uk/case-studies/_index.html new file mode 100644 index 0000000000..f8003e82e0 --- /dev/null +++ b/content/uk/case-studies/_index.html @@ -0,0 +1,13 @@ +--- +#title: Case Studies +title: Приклади використання +#linkTitle: Case Studies +linkTitle: Приклади використання +#bigheader: Kubernetes User Case Studies +bigheader: Приклади використання Kubernetes від користувачів. +#abstract: A collection of users running Kubernetes in production. +abstract: Підбірка користувачів, що використовують Kubernetes для робочих навантажень. +layout: basic +class: gridPage +cid: caseStudies +--- diff --git a/content/uk/docs/_index.md b/content/uk/docs/_index.md new file mode 100644 index 0000000000..a601666b67 --- /dev/null +++ b/content/uk/docs/_index.md @@ -0,0 +1,3 @@ +--- +title: Документація +--- diff --git a/content/uk/docs/concepts/_index.md b/content/uk/docs/concepts/_index.md new file mode 100644 index 0000000000..64f6e82323 --- /dev/null +++ b/content/uk/docs/concepts/_index.md @@ -0,0 +1,123 @@ +--- +title: Концепції +main_menu: true +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + + +В розділі "Концепції" описані складові системи Kubernetes і абстракції, за допомогою яких Kubernetes реалізовує ваш {{< glossary_tooltip text="кластер" term_id="cluster" length="all" >}}. Цей розділ допоможе вам краще зрозуміти, як працює Kubernetes. + +{{% /capture %}} + +{{% capture body %}} + + + +## Загальна інформація + + +Для роботи з Kubernetes ви використовуєте *об'єкти API Kubernetes* для того, щоб описати *бажаний стан* вашого кластера: які застосунки або інші робочі навантаження ви плануєте запускати, які образи контейнерів вони використовують, кількість реплік, скільки ресурсів мережі та диску ви хочете виділити тощо. Ви задаєте бажаний стан, створюючи об'єкти в Kubernetes API, зазвичай через інтерфейс командного рядка `kubectl`. Ви також можете взаємодіяти із кластером, задавати або змінювати його бажаний стан безпосередньо через Kubernetes API. + + +Після того, як ви задали бажаний стан, *площина управління Kubernetes* приводить поточний стан кластера до бажаного за допомогою Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). Для цього Kubernetes автоматично виконує ряд задач: запускає або перезапускає контейнери, масштабує кількість реплік у певному застосунку тощо. Площина управління Kubernetes складається із набору процесів, що виконуються у вашому кластері: + + + +* **Kubernetes master** становить собою набір із трьох процесів, запущених на одному вузлі вашого кластера, що визначений як керівний (master). До цих процесів належать: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) і [kube-scheduler](/docs/admin/kube-scheduler/). +* На кожному не-мастер вузлі вашого кластера виконуються два процеси: + * **[kubelet](/docs/admin/kubelet/)**, що обмінюється даними з Kubernetes master. + * **[kube-proxy](/docs/admin/kube-proxy/)**, мережевий проксі, що відображає мережеві сервіси Kubernetes на кожному вузлі. + + + +## Об'єкти Kubernetes + + +Kubernetes оперує певною кількістю абстракцій, що відображають стан вашої системи: розгорнуті у контейнерах застосунки та робочі навантаження, пов'язані з ними ресурси мережі та диску, інша інформація щодо функціонування вашого кластера. Ці абстракції представлені як об'єкти Kubernetes API. Для більш детальної інформації ознайомтесь з [Об'єктами Kubernetes](/docs/concepts/overview/working-with-objects/kubernetes-objects/). + + +До базових об'єктів Kubernetes належать: + +* [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 є також абстракції вищого рівня, які надбудовуються над базовими об'єктами за допомогою [контролерів](/docs/concepts/architecture/controller/) і забезпечують додаткову функціональність і зручність. До них належать: + +* [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/jobs-run-to-completion/) + + + +## Площина управління Kubernetes (*Kubernetes Control Plane*) {#площина-управління-kubernetes} + + +Різні частини площини управління Kubernetes, такі як Kubernetes Master і kubelet, регулюють, як Kubernetes спілкується з вашим кластером. Площина управління веде облік усіх об'єктів Kubernetes в системі та безперервно, в циклі перевіряє стан цих об'єктів. У будь-який момент часу контрольні цикли, запущені площиною управління, реагуватимуть на зміни у кластері і намагатимуться привести поточний стан об'єктів до бажаного, що заданий у конфігурації. + + +Наприклад, коли за допомогою API Kubernetes ви створюєте Deployment, ви задаєте новий бажаний стан для системи. Площина управління Kubernetes фіксує створення цього об'єкта і виконує ваші інструкції шляхом запуску потрібних застосунків та їх розподілу між вузлами кластера. В такий спосіб досягається відповідність поточного стану бажаному. + + + +### Kubernetes Master + + +Kubernetes Master відповідає за підтримку бажаного стану вашого кластера. Щоразу, як ви взаємодієте з Kubernetes, наприклад при використанні інтерфейсу командного рядка `kubectl`, ви обмінюєтесь даними із Kubernetes master вашого кластера. + + +Слово "master" стосується набору процесів, які управляють станом кластера. Переважно всі ці процеси виконуються на одному вузлі кластера, який також називається master. Master-вузол можна реплікувати для забезпечення високої доступності кластера. + + + +### Вузли Kubernetes + + +Вузлами кластера називають машини (ВМ, фізичні сервери тощо), на яких запущені ваші застосунки та хмарні робочі навантаження. Кожен вузол керується Kubernetes master; ви лише зрідка взаємодіятимете безпосередньо із вузлами. + + +{{% /capture %}} + +{{% capture whatsnext %}} + + +Якщо ви хочете створити нову сторінку у розділі Концепції, у статті +[Використання шаблонів сторінок](/docs/home/contribute/page-templates/) +ви знайдете інформацію щодо типу і шаблона сторінки. + +{{% /capture %}} diff --git a/content/uk/docs/concepts/configuration/_index.md b/content/uk/docs/concepts/configuration/_index.md new file mode 100644 index 0000000000..588d144f6e --- /dev/null +++ b/content/uk/docs/concepts/configuration/_index.md @@ -0,0 +1,5 @@ +--- +title: "Конфігурація" +weight: 80 +--- + diff --git a/content/uk/docs/concepts/overview/_index.md b/content/uk/docs/concepts/overview/_index.md new file mode 100644 index 0000000000..efffaf0892 --- /dev/null +++ b/content/uk/docs/concepts/overview/_index.md @@ -0,0 +1,4 @@ +--- +title: "Огляд" +weight: 20 +--- diff --git a/content/uk/docs/concepts/overview/what-is-kubernetes.md b/content/uk/docs/concepts/overview/what-is-kubernetes.md new file mode 100644 index 0000000000..269239c30a --- /dev/null +++ b/content/uk/docs/concepts/overview/what-is-kubernetes.md @@ -0,0 +1,182 @@ +--- +title: Що таке Kubernetes? +content_template: templates/concept +weight: 10 +card: + name: concepts + weight: 10 +--- + +{{% capture overview %}} + +Ця сторінка являє собою узагальнений огляд Kubernetes. +{{% /capture %}} + +{{% capture body %}} + +Kubernetes - це платформа з відкритим вихідним кодом для управління контейнеризованими робочими навантаженнями та супутніми службами. Її основні характеристики - кросплатформенність, розширюваність, успішне використання декларативної конфігурації та автоматизації. Вона має гігантську, швидкопрогресуючу екосистему. + + +Назва Kubernetes походить з грецької та означає керманич або пілот. Google відкрив доступ до вихідного коду проекту Kubernetes у 2014 році. Kubernetes побудовано [на базі п'ятнадцятирічного досвіду, що Google отримав, оперуючи масштабними робочими навантаженнями](https://ai.google/research/pubs/pub43438) у купі з найкращими у своєму класі ідеями та практиками, які може запропонувати спільнота. + + +## Озираючись на першопричини + + +Давайте повернемось назад у часі та дізнаємось, завдяки чому Kubernetes став таким корисним. + +![Еволюція розгортання](/images/docs/Container_Evolution.svg) + + +**Ера традиційного розгортання:** На початку організації запускали застосунки на фізичних серверах. Оскільки в такий спосіб не було можливості задати обмеження використання ресурсів, це спричиняло проблеми виділення та розподілення ресурсів на фізичних серверах. Наприклад: якщо багато застосунків було запущено на фізичному сервері, могли траплятись випадки, коли один застосунок забирав собі найбільше ресурсів, внаслідок чого інші програми просто не справлялись з обов'язками. Рішенням може бути запуск кожного застосунку на окремому фізичному сервері. Але такий підхід погано масштабується, оскільки ресурси не повністю використовуються; на додачу, це дорого, оскільки організаціям потрібно опікуватись багатьма фізичними серверами. + + +**Ера віртуалізованого розгортання:** Як рішення - була представлена віртуалізація. Вона дозволяє запускати численні віртуальні машини (Virtual Machines або VMs) на одному фізичному ЦПУ сервера. Віртуалізація дозволила застосункам бути ізольованими у межах віртуальних машин та забезпечувала безпеку, оскільки інформація застосунку на одній VM не була доступна застосунку на іншій VM. + + +Віртуалізація забезпечує краще використання ресурсів на фізичному сервері та кращу масштабованість, оскільки дозволяє легко додавати та оновлювати застосунки, зменшує витрати на фізичне обладнання тощо. З віртуалізацією ви можете представити ресурси у вигляді одноразових віртуальних машин. + + +Кожна VM є повноцінною машиною з усіма компонентами, включно з власною операційною системою, що запущені поверх віртуалізованого апаратного забезпечення. + + +**Ера розгортання контейнерів:** Контейнери схожі на VM, але мають спрощений варіант ізоляції і використовують спільну операційну систему для усіх застосунків. Саму тому контейнери вважаються легковісними. Подібно до VM, контейнер має власну файлову систему, ЦПУ, пам'ять, простір процесів тощо. Оскільки контейнери вивільнені від підпорядкованої інфраструктури, їх можна легко переміщати між хмарними провайдерами чи дистрибутивами операційних систем. + +Контейнери стали популярними, бо надавали додаткові переваги, такі як: + + + +* Створення та розгортання застосунків за методологією Agile: спрощене та більш ефективне створення образів контейнерів у порівнянні до використання образів віртуальних машин. +* Безперервна розробка, інтеграція та розгортання: забезпечення надійних та безперервних збирань образів контейнерів, їх швидке розгортання та легкі відкатування (за рахунок незмінності образів). +* Розподіл відповідальності команд розробки та експлуатації: створення образів контейнерів застосунків під час збирання/релізу на противагу часу розгортання, і як наслідок, вивільнення застосунків із інфраструктури. +* Спостереження не лише за інформацією та метриками на рівні операційної системи, але й за станом застосунку та іншими сигналами. +* Однорідність середовища для розробки, тестування та робочого навантаження: запускається так само як на робочому комп'ютері, так і у хмарного провайдера. +* ОС та хмарна кросплатформність: запускається на Ubuntu, RHEL, CoreOS, у власному дата-центрі, у Google Kubernetes Engine і взагалі будь-де. +* Керування орієнтоване на застосунки: підвищення рівня абстракції від запуску операційної системи у віртуальному апаратному забезпеченні до запуску застосунку в операційній системі, використовуючи логічні ресурси. +* Нещільно зв'язані, розподілені, еластичні, вивільнені мікросервіси: застосунки розбиваються на менші, незалежні частини для динамічного розгортання та управління, на відміну від монолітної архітектури, що працює на одній великій виділеній машині. +* Ізоляція ресурсів: передбачувана продуктивність застосунку. +* Використання ресурсів: висока ефективність та щільність. + + +## Чому вам потрібен Kebernetes і що він може робити + + +Контейнери - це прекрасний спосіб упакувати та запустити ваші застосунки. У прод оточенні вам потрібно керувати контейнерами, в яких працюють застосунки, і стежити, щоб не було простою. Наприклад, якщо один контейнер припиняє роботу, інший має бути запущений йому на заміну. Чи не легше було б, якби цим керувала сама система? + + +Ось де Kubernetes приходить на допомогу! Kubernetes надає вам каркас для еластичного запуску розподілених систем. Він опікується масштабуванням та аварійним відновленням вашого застосунку, пропонує шаблони розгортань тощо. Наприклад, Kubernetes дозволяє легко створювати розгортання за стратегією canary у вашій системі. + + +Kubernetes надає вам: + + + +* **Виявлення сервісів та балансування навантаження** +Kubernetes може надавати доступ до контейнера, використовуючи DNS-ім'я або його власну IP-адресу. Якщо контейнер зазнає завеликого мережевого навантаження, Kubernetes здатний збалансувати та розподілити його таким чином, щоб якість обслуговування залишалась стабільною. +* **Оркестрація сховища інформації** +Kubernetes дозволяє вам автоматично монтувати системи збереження інформації на ваш вибір: локальні сховища, рішення від хмарних провайдерів тощо. +* **Автоматичне розгортання та відкатування** +За допомогою Kubernetes ви можете описати бажаний стан контейнерів, що розгортаються, і він регульовано простежить за виконанням цього стану. Наприклад, ви можете автоматизувати в Kubernetes процеси створення нових контейнерів для розгортання, видалення існуючих контейнерів і передачу їхніх ресурсів на новостворені контейнери. +* **Автоматичне розміщення задач** +Ви надаєте Kubernetes кластер для запуску контейнерізованих задач і вказуєте, скільки ресурсів ЦПУ та пам'яті (RAM) необхідно для роботи кожного контейнера. Kubernetes розподіляє контейнери по вузлах кластера для максимально ефективного використання ресурсів. +* **Самозцілення** +Kubernetes перезапускає контейнери, що відмовили; заміняє контейнери; зупиняє роботу контейнерів, що не відповідають на задану користувачем перевірку стану, і не повідомляє про них клієнтам, допоки ці контейнери не будуть у стані робочої готовності. +* **Управління секретами та конфігурацією** +Kubernetes дозволяє вам зберігати та керувати чутливою інформацією, такою як паролі, OAuth токени та SSH ключі. Ви можете розгортати та оновлювати секрети та конфігурацію без перезбирання образів ваших контейнерів, не розкриваючи секрети в конфігурацію стека. + + + +## Чим не є Kubernetes + + +Kubernetes не є комплексною системою PaaS (Платформа як послуга) у традиційному розумінні. Оскільки Kubernetes оперує швидше на рівні контейнерів, аніж на рівні апаратного забезпечення, деяка загальнозастосована функціональність і справді є спільною з PaaS, як-от розгортання, масштабування, розподіл навантаження, логування і моніторинг. Водночас Kubernetes не є монолітним, а вищезазначені особливості підключаються і є опціональними. Kubernetes надає будівельні блоки для створення платформ для розробників, але залишає за користувачем право вибору у важливих питаннях. + + +Kubernetes: + + + +* Не обмежує типи застосунків, що підтримуються. Kubernetes намагається підтримувати найрізноманітніші типи навантажень, включно із застосунками зі станом (stateful) та без стану (stateless), навантаження по обробці даних тощо. Якщо ваш застосунок можна контейнеризувати, він чудово запуститься під Kubernetes. +* Не розгортає застосунки з вихідного коду та не збирає ваші застосунки. Процеси безперервної інтеграції, доставки та розгортання (CI/CD) визначаються на рівні організації, та в залежності від технічних вимог. +* Не надає сервіси на рівні застосунків як вбудовані: програмне забезпечення проміжного рівня (наприклад, шина передачі повідомлень), фреймворки обробки даних (наприклад, Spark), бази даних (наприклад, MySQL), кеш, некластерні системи збереження інформації (наприклад, Ceph). Ці компоненти можуть бути запущені у Kubernetes та/або бути доступними для застосунків за допомогою спеціальних механізмів, наприклад [Open Service Broker](https://openservicebrokerapi.org/). +* Не нав'язує використання інструментів для логування, моніторингу та сповіщень, натомість надає певні інтеграційні рішення як прототипи, та механізми зі збирання та експорту метрик. +* Не надає та не змушує використовувати якусь конфігураційну мову/систему (як наприклад `Jsonnet`), натомість надає можливість використовувати API, що може бути використаний довільними формами декларативних специфікацій. +* Не надає і не запроваджує жодних систем машинної конфігурації, підтримки, управління або самозцілення. +* На додачу, Kubernetes - не просто система оркестрації. Власне кажучи, вона усуває потребу оркестрації як такої. Технічне визначення оркестрації - це запуск визначених процесів: спочатку A, за ним B, потім C. На противагу, Kubernetes складається з певної множини незалежних, складних процесів контролерів, що безперервно опрацьовують стан у напрямку, що заданий бажаною конфігурацією. Неважливо, як ви дістанетесь з пункту A до пункту C. Централізоване управління також не є вимогою. Все це виливається в систему, яку легко використовувати, яка є потужною, надійною, стійкою та здатною до легкого розширення. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* Перегляньте [компоненти Kubernetes](/docs/concepts/overview/components/) +* Готові [розпочати роботу](/docs/setup/)? +{{% /capture %}} diff --git a/content/uk/docs/concepts/services-networking/_index.md b/content/uk/docs/concepts/services-networking/_index.md new file mode 100644 index 0000000000..634694311a --- /dev/null +++ b/content/uk/docs/concepts/services-networking/_index.md @@ -0,0 +1,4 @@ +--- +title: "Сервіси, балансування навантаження та мережа" +weight: 60 +--- diff --git a/content/uk/docs/concepts/storage/_index.md b/content/uk/docs/concepts/storage/_index.md new file mode 100644 index 0000000000..23108a421c --- /dev/null +++ b/content/uk/docs/concepts/storage/_index.md @@ -0,0 +1,4 @@ +--- +title: "Сховища інформації" +weight: 70 +--- diff --git a/content/uk/docs/concepts/workloads/_index.md b/content/uk/docs/concepts/workloads/_index.md new file mode 100644 index 0000000000..c826cbbcbc --- /dev/null +++ b/content/uk/docs/concepts/workloads/_index.md @@ -0,0 +1,4 @@ +--- +title: "Робочі навантаження" +weight: 50 +--- diff --git a/content/uk/docs/concepts/workloads/controllers/_index.md b/content/uk/docs/concepts/workloads/controllers/_index.md new file mode 100644 index 0000000000..3e5306f908 --- /dev/null +++ b/content/uk/docs/concepts/workloads/controllers/_index.md @@ -0,0 +1,4 @@ +--- +title: "Контролери" +weight: 20 +--- diff --git a/content/uk/docs/contribute/localization_uk.md b/content/uk/docs/contribute/localization_uk.md new file mode 100644 index 0000000000..0235b56a32 --- /dev/null +++ b/content/uk/docs/contribute/localization_uk.md @@ -0,0 +1,122 @@ +--- +title: Рекомендації з перекладу на українську мову +content_template: templates/concept +anchors: + - anchor: "#правила-перекладу" + title: Правила перекладу + - anchor: "#словник" + title: Словник +--- + +{{% capture overview %}} + +Дорогі друзі! Раді вітати вас у спільноті українських контриб'юторів проекту Kubernetes. Ця сторінка створена з метою полегшити вашу роботу при перекладі документації. Вона містить правила, якими ми керувалися під час перекладу, і базовий словник, який ми почали укладати. Перелічені у ньому терміни ви знайдете в українській версії документації Kubernetes. Будемо дуже вдячні, якщо ви допоможете нам доповнити цей словник і розширити правила перекладу. + +Сподіваємось, наші рекомендації стануть вам у пригоді. + +{{% /capture %}} + +{{% capture body %}} + +## Правила перекладу {#правила-перекладу} + +* У випадку, якщо у перекладі термін набуває неоднозначності і розуміння тексту ускладнюється, надайте у дужках англійський варіант, наприклад: кінцеві точки (endpoints). Якщо при перекладі термін втрачає своє значення, краще не перекладати його, наприклад: характеристики affinity. + +* Назви об'єктів Kubernetes залишаємо без перекладу і пишемо з великої літери: Service, Pod, Deployment, Volume, Namespace, за винятком терміна node (вузол). Назви об'єктів Kubernetes вважаємо за іменники ч.р. і відмінюємо за допомогою апострофа: Pod'ів, Deployment'ами. + Для слів, що закінчуються на приголосний, у родовому відмінку однини використовуємо закінчення -а: Pod'а, Deployment'а. + Слова, що закінчуються на голосний, не відмінюємо: доступ до Service, за допомогою Namespace. У множині використовуємо англійську форму: користуватися Services, спільні Volumes. + +* Частовживані і усталені за межами Kubernetes слова перекладаємо українською і пишемо з малої літери (label -> мітка). У випадку, якщо термін для означення об'єкта Kubernetes вживається у своєму загальному значенні поза контекстом Kubernetes (service як службова програма, deployment як розгортання), перекладаємо його і пишемо з малої літери, наприклад: service discovery -> виявлення сервісу, continuous deployment -> безперервне розгортання. + +* Складені слова вважаємо за власні назви і не перекладаємо (LabelSelector, kube-apiserver). + +* Для перевірки закінчень слів у родовому відмінку однини (-а/-я, -у/-ю) використовуйте [онлайн словник](https://slovnyk.ua/). Якщо слова немає у словнику, визначте його відміну і далі відмінюйте за правилами. Докладніше [дивіться тут](https://pidruchniki.com/1948041951499/dokumentoznavstvo/vidminyuvannya_imennikiv). + +## Словник {#словник} + +English | Українська | +--- | --- | +addon | розширення | +application | застосунок | +backend | бекенд | +build | збирання (результат) | +build | збирати (процес) | +cache | кеш | +CLI | інтерфейс командного рядка | +cloud | хмара; хмарний провайдер | +containerized | контейнеризований | +continuous deployment | безперервне розгортання | +continuous development | безперервна розробка | +continuous integration | безперервна інтеграція | +contribute | робити внесок (до проекту), допомагати (проекту) | +contributor | контриб'ютор, учасник проекту | +control plane | площина управління | +controller | контролер | +CPU | ЦП | +dashboard | дашборд | +data plane | площина даних | +default (by) | за умовчанням | +default settings | типові налаштування | +Deployment | Deployment | +deprecated | застарілий | +desired state | бажаний стан | +downtime | недоступність, простій | +ecosystem | сімейство проектів (екосистема) | +endpoint | кінцева точка | +expose (a service) | відкрити доступ (до сервісу) | +fail | відмовити | +feature | компонент | +framework | фреймворк | +frontend | фронтенд | +image | образ | +Ingress | Ingress | +instance | інстанс | +issue | запит | +kube-proxy | kube-proxy | +kubelet | kubelet | +Kubernetes features | функціональні можливості Kubernetes | +label | мітка | +lifecycle | життєвий цикл | +logging | логування | +maintenance | обслуговування | +map | спроектувати, зіставити, встановити відповідність | +master | master | +monitor | моніторити | +monitoring | моніторинг | +Namespace | Namespace | +network policy | мережева політика | +node | вузол | +orchestrate | оркеструвати | +output | вивід | +patch | патч | +Pod | Pod | +production | прод | +pull request | pull request | +release | реліз | +replica | репліка | +rollback | відкатування | +rolling update | послідовне оновлення | +rollout (new updates) | викатка (оновлень) | +run | запускати | +scale | масштабувати | +schedule | розподіляти (Pod'и по вузлах) | +Scheduler | Scheduler | +Secret | Secret | +Selector | Селектор | +self-healing | самозцілення | +self-restoring | самовідновлення | +Service | Service (як об'єкт Kubernetes) | +service | сервіс (як службова програма) | +service discovery | виявлення сервісу | +source code | вихідний код | +stateful app | застосунок зі станом | +stateless app | застосунок без стану | +task | завдання | +terminated | зупинений | +traffic | трафік | +VM (virtual machine) | ВМ (віртуальна машина) | +Volume | Volume | +workload | робоче навантаження | +YAML | YAML | + +{{% /capture %}} diff --git a/content/uk/docs/home/_index.md b/content/uk/docs/home/_index.md new file mode 100644 index 0000000000..5a8cfc3c51 --- /dev/null +++ b/content/uk/docs/home/_index.md @@ -0,0 +1,56 @@ +--- +title: Документація Kubernetes +noedit: true +cid: docsHome +layout: docsportal_home +class: gridPage gridPageHome +linkTitle: "Головна" +main_menu: true +weight: 10 +hide_feedback: true +menu: + main: + title: "Документація" + weight: 20 + post: > +

Дізнайтеся про основи роботи з Kubernetes, використовуючи схеми, навчальну та довідкову документацію. Ви можете навіть зробити свій внесок у документацію!

+overview: > + Kubernetes - рушій оркестрації контейнерів з відкритим вихідним кодом для автоматичного розгортання, масштабування і управління контейнеризованими застосунками. Цей проект розробляється під егідою Cloud Native Computing Foundation (CNCF). +cards: +- name: concepts + title: "Розуміння основ" + description: "Дізнайтеся про Kubernetes і його фундаментальні концепції." + button: "Дізнатися про концепції" + button_path: "/docs/concepts" +- name: tutorials + title: "Спробуйте Kubernetes" + description: "Дізнайтеся із навчальних матеріалів, як розгортати застосунки в Kubernetes." + button: "Переглянути навчальні матеріали" + button_path: "/docs/tutorials" +- name: setup + title: "Налаштування кластера" + description: "Розгорніть Kubernetes з урахуванням власних ресурсів і потреб." + button: "Налаштувати Kubernetes" + button_path: "/docs/setup" +- name: tasks + title: "Дізнайтеся, як користуватись Kubernetes" + description: "Ознайомтеся з типовими задачами і способами їх виконання за допомогою короткого алгоритму дій." + button: "Переглянути задачі" + button_path: "/docs/tasks" +- name: reference + title: Переглянути довідкову інформацію + description: Ознайомтеся з термінологією, синтаксисом командного рядка, типами ресурсів API і документацією з налаштування інструментів. + button: Переглянути довідкову інформацію + button_path: /docs/reference +- name: contribute + title: Зробити внесок у документацію + description: Будь-хто може зробити свій внесок, незалежно від того, чи ви нещодавно долучилися до проекту, чи працюєте над ним вже довгий час. + button: Зробити внесок у документацію + button_path: /docs/contribute +- name: download + title: Завантажити Kubernetes + description: Якщо ви встановлюєте Kubernetes чи оновлюєтесь до останньої версії, звіряйтеся з актуальною інформацією по релізу. +- name: about + title: Про документацію + description: Цей вебсайт містить документацію по актуальній і чотирьох попередніх версіях Kubernetes. +--- diff --git a/content/uk/docs/reference/glossary/applications.md b/content/uk/docs/reference/glossary/applications.md new file mode 100644 index 0000000000..c42c6ec343 --- /dev/null +++ b/content/uk/docs/reference/glossary/applications.md @@ -0,0 +1,16 @@ +--- +# title: Applications +title: Застосунки +id: applications +date: 2019-05-12 +full_link: +# short_description: > +# The layer where various containerized applications run. +short_description: > + Шар, в якому запущено контейнерізовані застосунки. +aka: +tags: +- fundamental +--- + +Шар, в якому запущено контейнерізовані застосунки. diff --git a/content/uk/docs/reference/glossary/cluster-infrastructure.md b/content/uk/docs/reference/glossary/cluster-infrastructure.md new file mode 100644 index 0000000000..557180912a --- /dev/null +++ b/content/uk/docs/reference/glossary/cluster-infrastructure.md @@ -0,0 +1,17 @@ +--- +# title: Cluster Infrastructure +title: Інфраструктура кластера +id: cluster-infrastructure +date: 2019-05-12 +full_link: +# short_description: > +# The infrastructure layer provides and maintains VMs, networking, security groups and others. +short_description: > + Шар інфраструктури забезпечує і підтримує роботу ВМ, мережі, груп безпеки тощо. + +aka: +tags: +- operations +--- + +Шар інфраструктури забезпечує і підтримує роботу ВМ, мережі, груп безпеки тощо. diff --git a/content/uk/docs/reference/glossary/cluster-operations.md b/content/uk/docs/reference/glossary/cluster-operations.md new file mode 100644 index 0000000000..0b8ec9f510 --- /dev/null +++ b/content/uk/docs/reference/glossary/cluster-operations.md @@ -0,0 +1,16 @@ +--- +# title: Cluster Operations +title: Операції з кластером +id: cluster-operations +date: 2019-05-12 +full_link: +# short_description: > +# Activities such as upgrading the clusters, implementing security, storage, ingress, networking, logging and monitoring, and other operations involved in managing a Kubernetes cluster. +short_description: > + Дії і операції, такі як оновлення кластерів, впровадження і використання засобів безпеки, сховища даних, Ingress'а, мережі, логування, моніторингу та інших операцій, пов'язаних з управлінням Kubernetes кластером. +aka: +tags: +- operations +--- + +Дії і операції, такі як оновлення кластерів, впровадження і використання засобів безпеки, сховища даних, Ingress'а, мережі, логування, моніторингу та інших операцій, пов'язаних з управлінням Kubernetes кластером. diff --git a/content/uk/docs/reference/glossary/cluster.md b/content/uk/docs/reference/glossary/cluster.md new file mode 100644 index 0000000000..4748e61236 --- /dev/null +++ b/content/uk/docs/reference/glossary/cluster.md @@ -0,0 +1,22 @@ +--- +# title: Cluster +title: Кластер +id: cluster +date: 2019-06-15 +full_link: +# short_description: > +# A set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node. +short_description: > + Група робочих машин (їх називають вузлами), на яких запущені контейнерізовані застосунки. Кожен кластер має щонайменше один вузол. + +aka: +tags: +- fundamental +- operation +--- + +Група робочих машин (їх називають вузлами), на яких запущені контейнерізовані застосунки. Кожен кластер має щонайменше один вузол. + + + +На робочих вузлах розміщуються Pod'и, які є складовими застосунку. Площина управління керує робочими вузлами і Pod'ами кластера. У прод оточеннях площина управління зазвичай розповсюджується на багато комп'ютерів, а кластер складається з багатьох вузлів для забезпечення відмовостійкості і високої доступності. diff --git a/content/uk/docs/reference/glossary/control-plane.md b/content/uk/docs/reference/glossary/control-plane.md new file mode 100644 index 0000000000..1fb28e40a4 --- /dev/null +++ b/content/uk/docs/reference/glossary/control-plane.md @@ -0,0 +1,17 @@ +--- +# title: Control Plane +title: Площина управління +id: control-plane +date: 2019-05-12 +full_link: +# short_description: > +# The container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers. +short_description: > + Шар оркестрації контейнерів, який надає API та інтерфейси для визначення, розгортання і управління життєвим циклом контейнерів. + +aka: +tags: +- fundamental +--- + +Шар оркестрації контейнерів, який надає API та інтерфейси для визначення, розгортання і управління життєвим циклом контейнерів. diff --git a/content/uk/docs/reference/glossary/data-plane.md b/content/uk/docs/reference/glossary/data-plane.md new file mode 100644 index 0000000000..263a544010 --- /dev/null +++ b/content/uk/docs/reference/glossary/data-plane.md @@ -0,0 +1,17 @@ +--- +# title: Data Plane +title: Площина даних +id: data-plane +date: 2019-05-12 +full_link: +# short_description: > +# The layer that provides capacity such as CPU, memory, network, and storage so that the containers can run and connect to a network. +short_description: > + Шар, який надає контейнерам ресурси, такі як ЦПУ, пам'ять, мережа і сховище даних для того, щоб контейнери могли працювати і підключатися до мережі. + +aka: +tags: +- fundamental +--- + +Шар, який надає контейнерам ресурси, такі як ЦПУ, пам'ять, мережа і сховище даних для того, щоб контейнери могли працювати і підключатися до мережі. diff --git a/content/uk/docs/reference/glossary/deployment.md b/content/uk/docs/reference/glossary/deployment.md new file mode 100644 index 0000000000..4c9c5ba3b9 --- /dev/null +++ b/content/uk/docs/reference/glossary/deployment.md @@ -0,0 +1,23 @@ +--- +title: Deployment +id: deployment +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/deployment/ +# short_description: > +# An API object that manages a replicated application. +short_description: > + Об'єкт API, що керує реплікованим застосунком. + +aka: +tags: +- fundamental +- core-object +- workload +--- + +Об'єкт API, що керує реплікованим застосунком. + + + + +Кожна репліка являє собою {{< glossary_tooltip term_id="pod" text="Pod" >}}; Pod'и розподіляються між вузлами кластера. diff --git a/content/uk/docs/reference/glossary/index.md b/content/uk/docs/reference/glossary/index.md new file mode 100644 index 0000000000..fd57553ef8 --- /dev/null +++ b/content/uk/docs/reference/glossary/index.md @@ -0,0 +1,17 @@ +--- +approvers: +- maxymvlasov +- anastyakulyk +# title: Standardized Glossary +title: Глосарій +layout: glossary +noedit: true +default_active_tag: fundamental +weight: 5 +card: + name: reference + weight: 10 +# title: Glossary + title: Глосарій +--- + diff --git a/content/uk/docs/reference/glossary/kube-apiserver.md b/content/uk/docs/reference/glossary/kube-apiserver.md new file mode 100644 index 0000000000..82e3caa0ba --- /dev/null +++ b/content/uk/docs/reference/glossary/kube-apiserver.md @@ -0,0 +1,29 @@ +--- +# title: API server +title: API-сервер +id: kube-apiserver +date: 2018-04-12 +full_link: /docs/reference/generated/kube-apiserver/ +# short_description: > +# Control plane component that serves the Kubernetes API. +short_description: > + Компонент площини управління, що надає доступ до API Kubernetes. + +aka: +- kube-apiserver +tags: +- architecture +- fundamental +--- + +API-сервер є компонентом {{< glossary_tooltip text="площини управління" term_id="control-plane" >}} Kubernetes, через який можна отримати доступ до API Kubernetes. API-сервер є фронтендом площини управління Kubernetes. + + + + + + +Основною реалізацією Kubernetes API-сервера є [kube-apiserver](/docs/reference/generated/kube-apiserver/). kube-apiserver підтримує горизонтальне масштабування, тобто масштабується за рахунок збільшення кількості інстансів. kube-apiserver можна запустити на декількох інстансах, збалансувавши між ними трафік. diff --git a/content/uk/docs/reference/glossary/kube-controller-manager.md b/content/uk/docs/reference/glossary/kube-controller-manager.md new file mode 100644 index 0000000000..edd56dcc90 --- /dev/null +++ b/content/uk/docs/reference/glossary/kube-controller-manager.md @@ -0,0 +1,22 @@ +--- +title: kube-controller-manager +id: kube-controller-manager +date: 2018-04-12 +full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/ +# short_description: > +# Control Plane component that runs controller processes. +short_description: > + Компонент площини управління, який запускає процеси контролера. + +aka: +tags: +- architecture +- fundamental +--- + +Компонент площини управління, який запускає процеси {{< glossary_tooltip text="контролера" term_id="controller" >}}. + + + + +За логікою, кожен {{< glossary_tooltip text="контролер" term_id="controller" >}} є окремим процесом. Однак для спрощення їх збирають в один бінарний файл і запускають як єдиний процес. diff --git a/content/uk/docs/reference/glossary/kube-proxy.md b/content/uk/docs/reference/glossary/kube-proxy.md new file mode 100644 index 0000000000..a6db7e07de --- /dev/null +++ b/content/uk/docs/reference/glossary/kube-proxy.md @@ -0,0 +1,33 @@ +--- +title: kube-proxy +id: kube-proxy +date: 2018-04-12 +full_link: /docs/reference/command-line-tools-reference/kube-proxy/ +# short_description: > +# `kube-proxy` is a network proxy that runs on each node in the cluster. +short_description: > + `kube-proxy` - це мережеве проксі, що запущене на кожному вузлі кластера. + +aka: +tags: +- fundamental +- networking +--- + +[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) є мережевим проксі, що запущене на кожному вузлі кластера і реалізує частину концепції Kubernetes {{< glossary_tooltip term_id="service" text="Service">}}. + + + + +kube-proxy відповідає за мережеві правила на вузлах. Ці правила обумовлюють підключення по мережі до ваших Pod'ів всередині чи поза межами кластера. + + +kube-proxy використовує шар фільтрації пакетів операційної системи, за наявності такого. В іншому випадку kube-proxy скеровує трафік самостійно. diff --git a/content/uk/docs/reference/glossary/kube-scheduler.md b/content/uk/docs/reference/glossary/kube-scheduler.md new file mode 100644 index 0000000000..0864f8570e --- /dev/null +++ b/content/uk/docs/reference/glossary/kube-scheduler.md @@ -0,0 +1,22 @@ +--- +title: kube-scheduler +id: kube-scheduler +date: 2018-04-12 +full_link: /docs/reference/generated/kube-scheduler/ +# short_description: > +# Control Plane component that watches for newly created pods with no assigned node, and selects a node for them to run on. +short_description: > + Компонент площини управління, що відстежує створені Pod'и, які ще не розподілені по вузлах, і обирає вузол, на якому вони працюватимуть. + +aka: +tags: +- architecture +--- + +Компонент площини управління, що відстежує створені Pod'и, які ще не розподілені по вузлах, і обирає вузол, на якому вони працюватимуть. + + + + +При виборі вузла враховуються наступні фактори: індивідуальна і колективна потреба у ресурсах, обмеження за апаратним/програмним забезпеченням і політиками, характеристики affinity і anti-affinity, локальність даних, сумісність робочих навантажень і граничні терміни виконання. diff --git a/content/uk/docs/reference/glossary/kubelet.md b/content/uk/docs/reference/glossary/kubelet.md new file mode 100644 index 0000000000..d46d18610c --- /dev/null +++ b/content/uk/docs/reference/glossary/kubelet.md @@ -0,0 +1,23 @@ +--- +title: Kubelet +id: kubelet +date: 2018-04-12 +full_link: /docs/reference/generated/kubelet +# short_description: > +# An agent that runs on each node in the cluster. It makes sure that containers are running in a pod. +short_description: > + Агент, що запущений на кожному вузлі кластера. Забезпечує запуск і роботу контейнерів у Pod'ах. + +aka: +tags: +- fundamental +- core-object +--- + +Агент, що запущений на кожному вузлі кластера. Забезпечує запуск і роботу контейнерів у Pod'ах. + + + + +kubelet використовує специфікації PodSpecs, які надаються за допомогою різних механізмів, і забезпечує працездатність і справність усіх контейнерів, що описані у PodSpecs. kubelet керує лише тими контейнерами, що були створені Kubernetes. diff --git a/content/uk/docs/reference/glossary/pod.md b/content/uk/docs/reference/glossary/pod.md new file mode 100644 index 0000000000..7ee87bb1af --- /dev/null +++ b/content/uk/docs/reference/glossary/pod.md @@ -0,0 +1,23 @@ +--- +# title: Pod +title: Pod +id: pod +date: 2018-04-12 +full_link: /docs/concepts/workloads/pods/pod-overview/ +# short_description: > +# The smallest and simplest Kubernetes object. A Pod represents a set of running containers on your cluster. +short_description: > + Найменший і найпростіший об'єкт Kubernetes. Pod являє собою групу контейнерів, що запущені у вашому кластері. + +aka: +tags: +- core-object +- fundamental +--- + + Найменший і найпростіший об'єкт Kubernetes. Pod являє собою групу {{< glossary_tooltip text="контейнерів" term_id="container" >}}, що запущені у вашому кластері. + + + + +Як правило, в одному Pod'і запускається один контейнер. У Pod'і також можуть бути запущені допоміжні контейнери, що забезпечують додаткову функціональність, наприклад, логування. Управління Pod'ами зазвичай здійснює {{< glossary_tooltip term_id="deployment" >}}. diff --git a/content/uk/docs/reference/glossary/selector.md b/content/uk/docs/reference/glossary/selector.md new file mode 100644 index 0000000000..77eb861f4e --- /dev/null +++ b/content/uk/docs/reference/glossary/selector.md @@ -0,0 +1,22 @@ +--- +# title: Selector +title: Селектор +id: selector +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/labels/ +# short_description: > +# Allows users to filter a list of resources based on labels. +short_description: > + Дозволяє користувачам фільтрувати ресурси за мітками. + +aka: +tags: +- fundamental +--- + +Дозволяє користувачам фільтрувати ресурси за мітками. + + + + +Селектори застосовуються при створенні запитів для фільтрації ресурсів за {{< glossary_tooltip text="мітками" term_id="label" >}}. diff --git a/content/uk/docs/reference/glossary/service.md b/content/uk/docs/reference/glossary/service.md new file mode 100755 index 0000000000..d813d7056c --- /dev/null +++ b/content/uk/docs/reference/glossary/service.md @@ -0,0 +1,24 @@ +--- +title: Service +id: service +date: 2018-04-12 +full_link: /docs/concepts/services-networking/service/ +# A way to expose an application running on a set of Pods as a network service. +short_description: > + Спосіб відкрити доступ до застосунку, що запущений на декількох Pod'ах у вигляді мережевої служби. + +aka: +tags: +- fundamental +- core-object +--- + +Це абстрактний спосіб відкрити доступ до застосунку, що працює як один (або декілька) {{< glossary_tooltip text="Pod'ів" term_id="pod" >}} у вигляді мережевої служби. + + + + +Переважно група Pod'ів визначається як Service за допомогою {{< glossary_tooltip text="селектора" term_id="selector" >}}. Додання або вилучення Pod'ів змінить групу Pod'ів, визначених селектором. Service забезпечує надходження мережевого трафіка до актуальної групи Pod'ів для підтримки робочого навантаження. diff --git a/content/uk/docs/setup/_index.md b/content/uk/docs/setup/_index.md new file mode 100644 index 0000000000..f7874f9fc4 --- /dev/null +++ b/content/uk/docs/setup/_index.md @@ -0,0 +1,136 @@ +--- +reviewers: +- brendandburns +- erictune +- mikedanese +no_issue: true +title: Початок роботи +main_menu: true +weight: 20 +content_template: templates/concept +card: + name: setup + weight: 20 + anchors: + - anchor: "#навчальне-середовище" + title: Навчальне середовище + - anchor: "#прод-оточення" + title: Прод оточення +--- + +{{% capture overview %}} + + +У цьому розділі розглянуто різні варіанти налаштування і запуску Kubernetes. + + +Різні рішення Kubernetes відповідають різним вимогам: легкість в експлуатації, безпека, система контролю, наявні ресурси та досвід, необхідний для управління кластером. + + +Ви можете розгорнути Kubernetes кластер на робочому комп'ютері, у хмарі чи в локальному дата-центрі, або обрати керований Kubernetes кластер. Також можна створити індивідуальні рішення на базі різних провайдерів хмарних сервісів або на звичайних серверах. + + +Простіше кажучи, ви можете створити Kubernetes кластер у навчальному і в прод оточеннях. + +{{% /capture %}} + +{{% capture body %}} + + + +## Навчальне оточення {#навчальне-оточення} + + +Для вивчення Kubernetes використовуйте рішення на базі Docker: інструменти, підтримувані спільнотою Kubernetes, або інші інструменти з сімейства проектів для налаштування Kubernetes кластера на локальному комп'ютері. + +{{< table caption="Таблиця інструментів для локального розгортання Kubernetes, які підтримуються спільнотою або входять до сімейства проектів Kubernetes." >}} + +|Спільнота |Сімейство проектів | +| ------------ | -------- | +| [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) | +| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| +| | [Minishift](https://docs.okd.io/latest/minishift/)| +| | [MicroK8s](https://microk8s.io/)| +| | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) | +| | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)| +| | [k3s](https://k3s.io)| + + +## Прод оточення {#прод-оточення} + + +Обираючи рішення для проду, визначіться, якими з функціональних складових (або абстракцій) Kubernetes кластера ви хочете керувати самі, а управління якими - доручити провайдеру. + + +У Kubernetes кластері можливі наступні абстракції: {{< glossary_tooltip text="застосунки" term_id="applications" >}}, {{< glossary_tooltip text="площина даних" term_id="data-plane" >}}, {{< glossary_tooltip text="площина управління" term_id="control-plane" >}}, {{< glossary_tooltip text="інфраструктура кластера" term_id="cluster-infrastructure" >}} та {{< glossary_tooltip text="операції з кластером" term_id="cluster-operations" >}}. + + +На діаграмі нижче показані можливі абстракції Kubernetes кластера із зазначенням, які з них потребують самостійного управління, а які можуть бути керовані провайдером. + +Рішення для прод оточення![Рішення для прод оточення](/images/docs/KubernetesSolutions.svg) + +{{< table caption="Таблиця рішень для прод оточення містить перелік провайдерів і їх технологій." >}} + +Таблиця рішень для прод оточення містить перелік провайдерів і технологій, які вони пропонують. + +|Провайдери | Керований сервіс | Хмара "під ключ" | Локальний дата-центр | Під замовлення (хмара) | Під замовлення (локальні ВМ)| Під замовлення (сервери без ОС) | +| --------- | ------ | ------ | ------ | ------ | ------ | ----- | +| [Agile Stacks](https://www.agilestacks.com/products/kubernetes)| | ✔ | ✔ | | | +| [Alibaba Cloud](https://www.alibabacloud.com/product/kubernetes)| | ✔ | | | | +| [Amazon](https://aws.amazon.com) | [Amazon EKS](https://aws.amazon.com/eks/) |[Amazon EC2](https://aws.amazon.com/ec2/) | | | | +| [AppsCode](https://appscode.com/products/pharmer/) | ✔ | | | | | +| [APPUiO](https://appuio.ch/)  | ✔ | ✔ | ✔ | | | | +| [Banzai Cloud Pipeline Kubernetes Engine (PKE)](https://banzaicloud.com/products/pke/) | | ✔ | | ✔ | ✔ | ✔ | +| [CenturyLink Cloud](https://www.ctl.io/) | | ✔ | | | | +| [Cisco Container Platform](https://cisco.com/go/containers) | | | ✔ | | | +| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | ✔ |✔ | +| [CloudStack](https://cloudstack.apache.org/) | | | | | ✔| +| [Canonical](https://ubuntu.com/kubernetes) | ✔ | ✔ | ✔ | ✔ |✔ | ✔ +| [Containership](https://containership.io) | ✔ |✔ | | | | +| [D2iQ](https://d2iq.com/) | | [Kommander](https://d2iq.com/solutions/ksphere) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | +| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔ +| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | | +| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔ +| [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ | ✔ | ✔ | [Custom Extensions](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) | +| [Giant Swarm](https://www.giantswarm.io/) | ✔ | ✔ | ✔ | | +| [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | | +| [Hidora](https://hidora.com/) | ✔ | ✔| ✔ | | | | | | | | +| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | | +| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | | +| [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | | +| [KubeOne](https://kubeone.io/) | | ✔ | ✔ | ✔ | ✔ | ✔ | +| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | | +| [KubeSail](https://kubesail.com/) | ✔ | | | | | +| [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ | +| [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ | +| [Microsoft Azure](https://azure.microsoft.com) | [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/) | | | | | +| [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) | | | ✔ | | | +| [NetApp Kubernetes Service (NKS)](https://cloud.netapp.com/kubernetes-service) | ✔ | ✔ | ✔ | | | +| [Nirmata](https://www.nirmata.com/) | | ✔ | ✔ | | | +| [Nutanix](https://www.nutanix.com/en) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | | | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization) | +| [OpenNebula](https://www.opennebula.org) |[OpenNebula Kubernetes](https://marketplace.opennebula.systems/docs/service/kubernetes.html) | | | | | +| [OpenShift](https://www.openshift.com) |[OpenShift Dedicated](https://www.openshift.com/products/dedicated/) and [OpenShift Online](https://www.openshift.com/products/online/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) |[OpenShift Container Platform](https://www.openshift.com/products/container-platform/) +| [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | ✔ | ✔ | | | | +| [oVirt](https://www.ovirt.org/) | | | | | ✔ | +| [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | | | +| [Platform9](https://platform9.com/) | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | ✔ | ✔ | ✔ +| [Rancher](https://rancher.com/) | | [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/) | | [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) | | [k3s](https://k3s.io/) +| [Supergiant](https://supergiant.io/) | |✔ | | | | +| [SUSE](https://www.suse.com/) | | ✔ | | | | +| [SysEleven](https://www.syseleven.io/) | ✔ | | | | | +| [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | ✔ | ✔ | | | ✔ | +| [VEXXHOST](https://vexxhost.com/) | ✔ | ✔ | | | | +| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) +| [Z.A.R.V.I.S.](https://zarvis.ai/) | ✔ | | | | | | + +{{% /capture %}} diff --git a/content/uk/docs/setup/best-practices/_index.md b/content/uk/docs/setup/best-practices/_index.md new file mode 100644 index 0000000000..696ad54d32 --- /dev/null +++ b/content/uk/docs/setup/best-practices/_index.md @@ -0,0 +1,5 @@ +--- +#title: Best practices +title: Найкращі практики +weight: 40 +--- diff --git a/content/uk/docs/setup/learning-environment/_index.md b/content/uk/docs/setup/learning-environment/_index.md new file mode 100644 index 0000000000..879c4eb9f6 --- /dev/null +++ b/content/uk/docs/setup/learning-environment/_index.md @@ -0,0 +1,5 @@ +--- +# title: Learning environment +title: Навчальне оточення +weight: 20 +--- diff --git a/content/uk/docs/setup/production-environment/_index.md b/content/uk/docs/setup/production-environment/_index.md new file mode 100644 index 0000000000..81463114fd --- /dev/null +++ b/content/uk/docs/setup/production-environment/_index.md @@ -0,0 +1,5 @@ +--- +#title: Production environment +title: Прод оточення +weight: 30 +--- diff --git a/content/uk/docs/setup/production-environment/on-premises-vm/_index.md b/content/uk/docs/setup/production-environment/on-premises-vm/_index.md new file mode 100644 index 0000000000..d672032037 --- /dev/null +++ b/content/uk/docs/setup/production-environment/on-premises-vm/_index.md @@ -0,0 +1,5 @@ +--- +# title: On-Premises VMs +title: Менеджери віртуалізації +weight: 40 +--- diff --git a/content/uk/docs/setup/production-environment/tools/_index.md b/content/uk/docs/setup/production-environment/tools/_index.md new file mode 100644 index 0000000000..8891b3ef4f --- /dev/null +++ b/content/uk/docs/setup/production-environment/tools/_index.md @@ -0,0 +1,5 @@ +--- +# title: Installing Kubernetes with deployment tools +title: Встановлення Kubernetes за допомогою інструментів розгортання +weight: 30 +--- diff --git a/content/uk/docs/setup/production-environment/tools/kubeadm/_index.md b/content/uk/docs/setup/production-environment/tools/kubeadm/_index.md new file mode 100644 index 0000000000..b5cd8e5426 --- /dev/null +++ b/content/uk/docs/setup/production-environment/tools/kubeadm/_index.md @@ -0,0 +1,5 @@ +--- +# title: "Bootstrapping clusters with kubeadm" +title: "Запуск кластерів з kubeadm" +weight: 10 +--- diff --git a/content/uk/docs/setup/production-environment/turnkey/_index.md b/content/uk/docs/setup/production-environment/turnkey/_index.md new file mode 100644 index 0000000000..4251bca2c4 --- /dev/null +++ b/content/uk/docs/setup/production-environment/turnkey/_index.md @@ -0,0 +1,5 @@ +--- +# title: Turnkey Cloud Solutions +title: Хмарні рішення під ключ +weight: 30 +--- diff --git a/content/uk/docs/setup/production-environment/windows/_index.md b/content/uk/docs/setup/production-environment/windows/_index.md new file mode 100644 index 0000000000..a0d1574f6c --- /dev/null +++ b/content/uk/docs/setup/production-environment/windows/_index.md @@ -0,0 +1,5 @@ +--- +# title: "Windows in Kubernetes" +title: "Windows в Kubernetes" +weight: 50 +--- diff --git a/content/uk/docs/setup/release/_index.md b/content/uk/docs/setup/release/_index.md new file mode 100755 index 0000000000..5fed3d9c90 --- /dev/null +++ b/content/uk/docs/setup/release/_index.md @@ -0,0 +1,5 @@ +--- +#title: "Release notes and version skew" +title: "Зміни в релізах нових версій" +weight: 10 +--- diff --git a/content/uk/docs/templates/feature-state-alpha.txt b/content/uk/docs/templates/feature-state-alpha.txt new file mode 100644 index 0000000000..e061aa52be --- /dev/null +++ b/content/uk/docs/templates/feature-state-alpha.txt @@ -0,0 +1,7 @@ +Наразі цей компонент у статусі *alpha*, що означає: + +* Назва версії містить слово alpha (напр. v1alpha1). +* Увімкнення цього компонента може призвести до помилок у системі. За умовчанням цей компонент вимкнутий. +* Підтримка цього компонентa може бути припинена у будь-який час без попередження. +* API може стати несумісним у наступних релізах без попередження. +* Рекомендований до використання лише у тестових кластерах через підвищений ризик виникнення помилок і відсутність довгострокової підтримки. diff --git a/content/uk/docs/templates/feature-state-beta.txt b/content/uk/docs/templates/feature-state-beta.txt new file mode 100644 index 0000000000..3790be73f4 --- /dev/null +++ b/content/uk/docs/templates/feature-state-beta.txt @@ -0,0 +1,22 @@ + +Наразі цей компонент у статусі *beta*, що означає: + + +* Назва версії містить слово beta (наприклад, v2beta3). + +* Код добре відтестований. Увімкнення цього компонента не загрожує роботі системи. Компонент увімкнутий за умовчанням. + +* Загальна підтримка цього компонента триватиме, однак деталі можуть змінитися. + +* У наступній beta- чи стабільній версії схема та/або семантика об'єктів може змінитися і стати несумісною. У такому випадку ми надамо інструкції для міграції на наступну версію. Це може призвести до видалення, редагування і перестворення об'єктів API. У процесі редагування вам, можливо, знадобиться продумати зміни в об'єкті. Це може призвести до недоступності застосунків, для роботи яких цей компонент є істотно важливим. + +* Використання компонента рекомендоване лише у некритичних для безперебійної діяльності випадках через ризик несумісних змін у подальших релізах. Це обмеження може бути пом'якшене у випадку декількох кластерів, які можна оновлювати окремо. + +* **Будь ласка, спробуйте beta-версії наших компонентів і поділіться з нами своєю думкою! Після того, як компонент вийде зі статусу beta, нам буде важче змінити його.** diff --git a/content/uk/docs/templates/feature-state-deprecated.txt b/content/uk/docs/templates/feature-state-deprecated.txt new file mode 100644 index 0000000000..7c35b3fc2f --- /dev/null +++ b/content/uk/docs/templates/feature-state-deprecated.txt @@ -0,0 +1,4 @@ + + +Цей компонент є *застарілим*. Дізнатися більше про цей статус ви можете зі статті [Політика Kubernetes щодо застарілих компонентів](/docs/reference/deprecation-policy/). diff --git a/content/uk/docs/templates/feature-state-stable.txt b/content/uk/docs/templates/feature-state-stable.txt new file mode 100644 index 0000000000..a794f5ceb6 --- /dev/null +++ b/content/uk/docs/templates/feature-state-stable.txt @@ -0,0 +1,11 @@ + + +Цей компонент є *стабільним*, що означає: + + +* Назва версії становить vX, де X є цілим числом. + +* Стабільні версії компонентів з'являтимуться у багатьох наступних версіях програмного забезпечення. \ No newline at end of file diff --git a/content/uk/docs/templates/index.md b/content/uk/docs/templates/index.md new file mode 100644 index 0000000000..0e0b890542 --- /dev/null +++ b/content/uk/docs/templates/index.md @@ -0,0 +1,15 @@ +--- +headless: true + +resources: +- src: "*alpha*" + title: "alpha" +- src: "*beta*" + title: "beta" +- src: "*deprecated*" +# title: "deprecated" + title: "застарілий" +- src: "*stable*" +# title: "stable" + title: "стабільний" +--- \ No newline at end of file diff --git a/content/uk/docs/tutorials/_index.md b/content/uk/docs/tutorials/_index.md new file mode 100644 index 0000000000..5c30bc87ff --- /dev/null +++ b/content/uk/docs/tutorials/_index.md @@ -0,0 +1,90 @@ +--- +#title: Tutorials +title: Навчальні матеріали +main_menu: true +weight: 60 +content_template: templates/concept +--- + +{{% capture overview %}} + + +У цьому розділі документації Kubernetes зібрані навчальні матеріали. Кожний матеріал показує, як досягти окремої мети, що більша за одне [завдання](/docs/tasks/). Зазвичай навчальний матеріал має декілька розділів, кожен з яких містить певну послідовність дій. До ознайомлення з навчальними матеріалами вам, можливо, знадобиться додати у закладки сторінку з [Глосарієм](/docs/reference/glossary/) для подальшого консультування. + +{{% /capture %}} + +{{% capture body %}} + + +## Основи + + +* [Основи Kubernetes](/docs/tutorials/kubernetes-basics/) - детальний навчальний матеріал з інтерактивними уроками, що допоможе вам зрозуміти Kubernetes і спробувати його базову функціональність. + +* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) + +* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) + +* [Привіт Minikube](/docs/tutorials/hello-minikube/) + + +## Конфігурація + +* [Configuring Redis Using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) + +## Застосунки без стану (Stateless Applications) {#застосунки-без-стану} + +* [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/) + +* [Example: Deploying PHP Guestbook application with Redis](/docs/tutorials/stateless-application/guestbook/) + +## Застосунки зі станом (Stateful Applications) {#застосунки-зі-станом} + +* [StatefulSet Basics](/docs/tutorials/stateful-application/basic-stateful-set/) + +* [Example: WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) + +* [Example: Deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/) + +* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/) + +## CI/CD Pipeline + +* [Set Up a CI/CD Pipeline with Kubernetes Part 1: Overview](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview) + +* [Set Up a CI/CD Pipeline with a Jenkins Pod in Kubernetes (Part 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2) + +* [Run and Scale a Distributed Crossword Puzzle App with CI/CD on Kubernetes (Part 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3) + +* [Set Up CI/CD for a Distributed Crossword Puzzle App on Kubernetes (Part 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4) + +## Кластери + +* [AppArmor](/docs/tutorials/clusters/apparmor/) + +## Сервіси + +* [Using Source IP](/docs/tutorials/services/source-ip/) + +{{% /capture %}} + +{{% capture whatsnext %}} + + +Якщо ви хочете написати навчальний матеріал, у статті +[Використання шаблонів сторінок](/docs/home/contribute/page-templates/) +ви знайдете інформацію про тип навчальної сторінки і шаблон. + +{{% /capture %}} diff --git a/content/uk/docs/tutorials/hello-minikube.md b/content/uk/docs/tutorials/hello-minikube.md new file mode 100644 index 0000000000..b887c8f4cd --- /dev/null +++ b/content/uk/docs/tutorials/hello-minikube.md @@ -0,0 +1,394 @@ +--- +#title: Hello Minikube +title: Привіт Minikube +content_template: templates/tutorial +weight: 5 +menu: + main: + #title: "Get Started" + title: "Початок роботи" + weight: 10 + #post: > + #

Ready to get your hands dirty? Build a simple Kubernetes cluster that runs "Hello World" for Node.js.

+ post: > +

Готові попрацювати? Створимо простий Kubernetes кластер для запуску Node.js застосунку "Hello World".

+card: + #name: tutorials + name: навчальні матеріали + weight: 10 +--- + +{{% capture overview %}} + + +З цього навчального матеріалу ви дізнаєтесь, як запустити у Kubernetes простий Hello World застосунок на Node.js за допомогою [Minikube](/docs/setup/learning-environment/minikube) і Katacoda. Katacoda надає безплатне Kubernetes середовище, що доступне у вашому браузері. + + +{{< note >}} +Також ви можете навчатись за цим матеріалом, якщо встановили [Minikube локально](/docs/tasks/tools/install-minikube/). +{{< /note >}} + +{{% /capture %}} + +{{% capture objectives %}} + + +* Розгорнути Hello World застосунок у Minikube. + +* Запустити застосунок. + +* Переглянути логи застосунку. + +{{% /capture %}} + +{{% capture prerequisites %}} + + +У цьому навчальному матеріалі ми використовуємо образ контейнера, зібраний із наступних файлів: + +{{< codenew language="js" file="minikube/server.js" >}} + +{{< codenew language="conf" file="minikube/Dockerfile" >}} + + +Більше інформації про команду `docker build` ви знайдете у [документації Docker](https://docs.docker.com/engine/reference/commandline/build/). + +{{% /capture %}} + +{{% capture lessoncontent %}} + + +## Створення Minikube кластера + + +1. Натисніть кнопку **Запуск термінала** + + {{< kat-button >}} + + + {{< note >}}Якщо Minikube встановлений локально, виконайте команду `minikube start`.{{< /note >}} + + +2. Відкрийте Kubernetes дашборд у браузері: + + ```shell + minikube dashboard + ``` + + +3. Тільки для Katacoda: у верхній частині вікна термінала натисніть знак плюс, а потім -- **Select port to view on Host 1**. + + +4. Тільки для Katacoda: введіть `30000`, а потім натисніть **Display Port**. + + +## Створення Deployment + + +[*Pod*](/docs/concepts/workloads/pods/pod/) у Kubernetes -- це група з одного або декількох контейнерів, що об'єднані разом з метою адміністрування і роботи у мережі. У цьому навчальному матеріалі Pod має лише один контейнер. Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) перевіряє стан Pod'а і перезапускає контейнер Pod'а, якщо контейнер перестає працювати. Створювати і масштабувати Pod'и рекомендується за допомогою Deployment'ів. + + +1. За допомогою команди `kubectl create` створіть Deployment, який керуватиме Pod'ом. Pod запускає контейнер на основі наданого Docker образу. + + ```shell + kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node + ``` + + +2. Перегляньте інформацію про запущений Deployment: + + ```shell + kubectl get deployments + ``` + + + У виводі ви побачите подібну інформацію: + + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + hello-node 1/1 1 1 1m + ``` + + +3. Перегляньте інформацію про запущені Pod'и: + + ```shell + kubectl get pods + ``` + + + У виводі ви побачите подібну інформацію: + + ``` + NAME READY STATUS RESTARTS AGE + hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m + ``` + + +4. Перегляньте події кластера: + + ```shell + kubectl get events + ``` + + +5. Перегляньте конфігурацію `kubectl`: + + ```shell + kubectl config view + ``` + + + {{< note >}}Більше про команди `kubectl` ви можете дізнатися зі статті [Загальна інформація про kubectl](/docs/user-guide/kubectl-overview/).{{< /note >}} + + +## Створення Service + + +За умовчанням, Pod доступний лише за внутрішньою IP-адресою у межах Kubernetes кластера. Для того, щоб контейнер `hello-node` став доступний за межами віртуальної мережі Kubernetes, Pod необхідно відкрити як Kubernetes [*Service*](/docs/concepts/services-networking/service/). + + +1. Відкрийте Pod для публічного доступу з інтернету за допомогою команди `kubectl expose`: + + ```shell + kubectl expose deployment hello-node --type=LoadBalancer --port=8080 + ``` + + + Прапорець `--type=LoadBalancer` вказує, що ви хочете відкрити доступ до Service за межами кластера. + + +2. Перегляньте інформацію про Service, який ви щойно створили: + + ```shell + kubectl get services + ``` + + + У виводі ви побачите подібну інформацію: + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + hello-node LoadBalancer 10.108.144.78 8080:30369/TCP 21s + kubernetes ClusterIP 10.96.0.1 443/TCP 23m + ``` + + + Для хмарних провайдерів, що підтримують балансування навантаження, доступ до Service надається через зовнішню IP-адресу. Для Minikube, тип `LoadBalancer` робить Service доступним ззовні за допомогою команди `minikube service`. + + +3. Виконайте наступну команду: + + ```shell + minikube service hello-node + ``` + + +4. Тільки для Katacoda: натисніть знак плюс, а потім -- **Select port to view on Host 1**. + + +5. Тільки для Katacoda: запишіть п'ятизначний номер порту, що відображається напроти `8080` у виводі сервісу. Номер цього порту генерується довільно і тому може бути іншим у вашому випадку. Введіть номер порту у призначене для цього текстове поле і натисніть Display Port. У нашому прикладі номер порту `30369`. + + + Це відкриє вікно браузера, в якому запущений ваш застосунок, і покаже повідомлення "Hello World". + + +## Увімкнення розширень + + +Minikube має ряд вбудованих {{< glossary_tooltip text="розширень" term_id="addons" >}}, які можна увімкнути, вимкнути і відкрити у локальному Kubernetes оточенні. + + +1. Перегляньте перелік підтримуваних розширень: + + ```shell + minikube addons list + ``` + + + У виводі ви побачите подібну інформацію: + + ``` + addon-manager: enabled + dashboard: enabled + default-storageclass: enabled + efk: disabled + freshpod: disabled + gvisor: disabled + helm-tiller: disabled + ingress: disabled + ingress-dns: disabled + logviewer: disabled + metrics-server: disabled + nvidia-driver-installer: disabled + nvidia-gpu-device-plugin: disabled + registry: disabled + registry-creds: disabled + storage-provisioner: enabled + storage-provisioner-gluster: disabled + ``` + + +2. Увімкніть розширення, наприклад `metrics-server`: + + ```shell + minikube addons enable metrics-server + ``` + + + У виводі ви побачите подібну інформацію: + + ``` + metrics-server was successfully enabled + ``` + + +3. Перегляньте інформацію про Pod і Service, які ви щойно створили: + + ```shell + kubectl get pod,svc -n kube-system + ``` + + + У виводі ви побачите подібну інформацію: + + ``` + NAME READY STATUS RESTARTS AGE + pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m + pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m + pod/metrics-server-67fb648c5 1/1 Running 0 26s + pod/etcd-minikube 1/1 Running 0 34m + pod/influxdb-grafana-b29w8 2/2 Running 0 26s + pod/kube-addon-manager-minikube 1/1 Running 0 34m + pod/kube-apiserver-minikube 1/1 Running 0 34m + pod/kube-controller-manager-minikube 1/1 Running 0 34m + pod/kube-proxy-rnlps 1/1 Running 0 34m + pod/kube-scheduler-minikube 1/1 Running 0 34m + pod/storage-provisioner 1/1 Running 0 34m + + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + service/metrics-server ClusterIP 10.96.241.45 80/TCP 26s + service/kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP 34m + service/monitoring-grafana NodePort 10.99.24.54 80:30002/TCP 26s + service/monitoring-influxdb ClusterIP 10.111.169.94 8083/TCP,8086/TCP 26s + ``` + + +4. Вимкніть `metrics-server`: + + ```shell + minikube addons disable metrics-server + ``` + + + У виводі ви побачите подібну інформацію: + + ``` + metrics-server was successfully disabled + ``` + + +## Вивільнення ресурсів + + +Тепер ви можете видалити ресурси, які створили у вашому кластері: + +```shell +kubectl delete service hello-node +kubectl delete deployment hello-node +``` + + +За бажанням, зупиніть віртуальну машину (ВМ) з Minikube: + +```shell +minikube stop +``` + + +За бажанням, видаліть ВМ з Minikube: + +```shell +minikube delete +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + + +* Дізнайтеся більше про [об'єкти Deployment](/docs/concepts/workloads/controllers/deployment/). + +* Дізнайтеся більше про [розгортання застосунків](/docs/user-guide/deploying-applications/). + +* Дізнайтеся більше про [об'єкти Service](/docs/concepts/services-networking/service/). + +{{% /capture %}} diff --git a/content/uk/docs/tutorials/kubernetes-basics/_index.html b/content/uk/docs/tutorials/kubernetes-basics/_index.html new file mode 100644 index 0000000000..466b8b3437 --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/_index.html @@ -0,0 +1,138 @@ +--- +title: Дізнатися про основи Kubernetes +linkTitle: Основи Kubernetes +weight: 10 +card: + name: навчальні матеріали + weight: 20 + title: Знайомство з основами +--- + + + + + + + + + +
+ +
+ +
+
+ +

Основи Kubernetes

+ +

Цей навчальний матеріал ознайомить вас з основами системи оркестрації Kubernetes кластера. Кожен модуль містить загальну інформацію щодо основної функціональності і концепцій Kubernetes, а також інтерактивний онлайн-урок. Завдяки цим інтерактивним урокам ви зможете самостійно керувати простим кластером і розгорнутими в ньому контейнеризованими застосунками.

+ +

З інтерактивних уроків ви дізнаєтесь:

+
    + +
  • як розгорнути контейнеризований застосунок у кластері.
    • + +
  • як масштабувати Deployment.
    • + +
  • як розгорнути нову версію контейнеризованого застосунку.
    • + +
  • як відлагодити контейнеризований застосунок.
    • +
+ +

Навчальні матеріали використовують Katacoda для запуску у вашому браузері віртуального термінала, в якому запущено Minikube - невеликий локально розгорнутий Kubernetes, що може працювати будь-де. Вам не потрібно встановлювати або налаштовувати жодне програмне забезпечення: кожен інтерактивний урок запускається просто у вашому браузері.

+
+
+ +
+ +
+
+ +

Чим Kubernetes може бути корисний для вас?

+ +

Від сучасних вебсервісів користувачі очікують доступності 24/7, а розробники - можливості розгортати нові версії цих застосунків по кілька разів на день. Контейнеризація, що допомагає упакувати програмне забезпечення, якнайкраще сприяє цим цілям. Вона дозволяє випускати і оновлювати застосунки легко, швидко та без простою. Із Kubernetes ви можете бути певні, що ваші контейнеризовані застосунки запущені там і тоді, де ви цього хочете, а також забезпечені усіма необхідними для роботи ресурсами та інструментами. Kubernetes - це висококласна платформа з відкритим вихідним кодом, в основі якої - накопичений досвід оркестрації контейнерів від Google, поєднаний із найкращими ідеями і практиками від спільноти.

+
+
+ +
+ +
+ +

Навчальні модулі "Основи Kubernetes"

+
+
+
+
+
+ +
+
1. Створення Kubernetes кластера
 +
+
+
+
+
+ +
+
2. Розгортання застосунку
 +
+
+
+
+
+ +
+
3. Вивчення застосунку
 +
+
+
+
+
+
+
+
+
+ +
+
4. Відкриття доступу до застосунку за межами кластера
 +
+
+
+
+
+ +
+
5. Масштабування застосунку
 +
+
+
+
+
+ +
+
6. Оновлення застосунку
 +
+
+
+
+
+
+
+ +
+ +
+ + + diff --git a/content/uk/docs/tutorials/kubernetes-basics/create-cluster/_index.md b/content/uk/docs/tutorials/kubernetes-basics/create-cluster/_index.md new file mode 100644 index 0000000000..9173c90d34 --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/create-cluster/_index.md @@ -0,0 +1,4 @@ +--- +title: Створення кластера +weight: 10 +--- diff --git a/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html new file mode 100644 index 0000000000..20d89f23ca --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -0,0 +1,37 @@ +--- +title: Інтерактивний урок - Створення кластера +weight: 20 +--- + + + + + + + + + + + +
+ +
+ +
+
+ Для роботи з терміналом використовуйте комп'ютер або планшет +
+
+
+
+
+ Перейти до модуля 2› +
+
+ +
+ +
+ + + diff --git a/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html new file mode 100644 index 0000000000..1a4e179a69 --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -0,0 +1,152 @@ +--- +title: Використання Minikube для створення кластера +weight: 10 +--- + + + + + + + + + +
+ +
+ +
+ +
+ +

Цілі

+
    + +
  • Зрозуміти, що таке Kubernetes кластер.
    • + +
  • Зрозуміти, що таке Minikube.
    • + +
  • Запустити Kubernetes кластер за допомогою онлайн-термінала.
    • +
+
+ +
+ +

Kubernetes кластери

+ +

+ Kubernetes координує високодоступний кластер комп'ютерів, з'єднаних таким чином, щоб працювати як одне ціле. Абстракції Kubernetes дозволяють вам розгортати контейнеризовані застосунки в кластері без конкретної прив'язки до окремих машин. Для того, щоб скористатися цією новою моделлю розгортання, застосунки потрібно упакувати таким чином, щоб звільнити їх від прив'язки до окремих хостів, тобто контейнеризувати. Контейнеризовані застосунки більш гнучкі і доступні, ніж попередні моделі розгортання, що передбачали встановлення застосунків безпосередньо на призначені для цього машини у вигляді програмного забезпечення, яке глибоко інтегрувалося із хостом. Kubernetes дозволяє автоматизувати розподіл і запуск контейнерів застосунку у кластері, а це набагато ефективніше. Kubernetes - це платформа з відкритим вихідним кодом, готова для використання у проді. +

+ +

Kubernetes кластер складається з двох типів ресурсів: +

    +
  • master, що координує роботу кластера
    • +
  • вузли (nodes) - робочі машини, на яких запущені застосунки
    • +
+

+
+ +
+
+ +

Зміст:

+
    + +
  • Kubernetes кластер
    • + +
  • Minikube
    • +
+
+
+ +

+ Kubernetes - це довершена платформа з відкритим вихідним кодом, що оркеструє розміщення і запуск контейнерів застосунку всередині та між комп'ютерними кластерами. +

+
+
+
+
+ +
+
+

Схема кластера

+
+
+ +
+
+

+
+
+
+ +
+
+ +

Master відповідає за керування кластером. Master координує всі процеси у вашому кластері, такі як запуск застосунків, підтримка їх бажаного стану, масштабування застосунків і викатка оновлень.

+ + +

Вузол (node) - це ВМ або фізичний комп'ютер, що виступає у ролі робочої машини в Kubernetes кластері. Кожен вузол має kubelet - агент для управління вузлом і обміну даними з Kubernetes master. Також на вузлі мають бути встановлені інструменти для виконання операцій з контейнерами, такі як Docker або rkt. Kubernetes кластер у проді повинен складатися як мінімум із трьох вузлів.

+ +
+
+
+ +

Master'и керують кластером, а вузли використовуються для запуску застосунків.

+
+
+
+ +
+
+ +

Коли ви розгортаєте застосунки у Kubernetes, ви кажете master-вузлу запустити контейнери застосунку. Master розподіляє контейнери для запуску на вузлах кластера. Для обміну даними з master вузли використовують Kubernetes API, який надається master-вузлом. Кінцеві користувачі також можуть взаємодіяти із кластером безпосередньо через Kubernetes API.

+ + +

Kubernetes кластер можна розгорнути як на фізичних, так і на віртуальних серверах. Щоб розпочати розробку під Kubernetes, ви можете скористатися Minikube - спрощеною реалізацією Kubernetes. Minikube створює на вашому локальному комп'ютері ВМ, на якій розгортає простий кластер з одного вузла. Існують версії Minikube для операційних систем Linux, macOS та Windows. Minikube CLI надає основні операції для роботи з вашим кластером, такі як start, stop, status і delete. Однак у цьому уроці ви використовуватимете онлайн термінал із вже встановленим Minikube.

+ + +

Тепер ви знаєте, що таке Kubernetes. Тож давайте перейдемо до інтерактивного уроку і створимо ваш перший кластер!

+ +
+
+
+ +
+
+ Почати інтерактивний урок › +
+
+ +
+ +
+ + + diff --git a/content/uk/docs/tutorials/kubernetes-basics/deploy-app/_index.md b/content/uk/docs/tutorials/kubernetes-basics/deploy-app/_index.md new file mode 100644 index 0000000000..a9c1ff2376 --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/deploy-app/_index.md @@ -0,0 +1,4 @@ +--- +title: Розгортання застосунку +weight: 20 +--- diff --git a/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html new file mode 100644 index 0000000000..d89a05a95b --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -0,0 +1,41 @@ +--- +title: Інтерактивний урок - Розгортання застосунку +weight: 20 +--- + + + + + + + + + + + +
+ +
+ +
+
+
+ Для роботи з терміналом використовуйте комп'ютер або планшет +
+ +
+
+ +
+
+
+ Перейти до модуля 3› +
+
+ +
+ +
+ + + diff --git a/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html new file mode 100644 index 0000000000..3cdf8dfd93 --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -0,0 +1,151 @@ +--- +title: Використання kubectl для створення Deployment'а +weight: 10 +--- + + + + + + + + + +
+ +
+ +
+ +
+ +

Цілі

+
    + +
  • Дізнатися, що таке Deployment застосунків.
    • + +
  • Розгорнути свій перший застосунок у Kubernetes за допомогою kubectl.
    • +
+
+ +
+ +

Процеси Kubernetes Deployment

+ +

+ Після того, як ви запустили Kubernetes кластер, ви можете розгортати в ньому контейнеризовані застосунки. Для цього вам необхідно створити Deployment конфігурацію. Вона інформує Kubernetes, як створювати і оновлювати Pod'и для вашого застосунку. Після того, як ви створили Deployment, Kubernetes master розподіляє ці Pod'и по окремих вузлах кластера. +

+ + +

Після створення Pod'и застосунку безперервно моніторяться контролером Kubernetes Deployment. Якщо вузол, на якому розміщено Pod, зупинив роботу або був видалений, Deployment контролер переміщає цей Pod на інший вузол кластера. Так працює механізм самозцілення, що підтримує робочий стан кластера у разі апаратного збою чи технічних робіт.

+ + +

До появи оркестрації застосунки часто запускали за допомогою скриптів установлення. Однак скрипти не давали можливості відновити працездатний стан застосунку після апаратного збою. Завдяки створенню Pod'ів та їхньому запуску на вузлах кластера, Kubernetes Deployment надає цілковито інший підхід до управління застосунками.

+ +
+ +
+
+ +

Зміст:

+
    + +
  • Deployment'и
    • +
  • Kubectl
    • +
+
+
+ +

+ Deployment відповідає за створення і оновлення Pod'ів для вашого застосунку +

+
+
+
+
+ +
+
+

Як розгорнути ваш перший застосунок у Kubernetes

+
+
+ +
+
+

+
+
+
+ +
+
+ + +

Ви можете створити Deployment і керувати ним за допомогою командного рядка Kubernetes - kubectl. kubectl взаємодіє з кластером через API Kubernetes. У цьому модулі ви вивчите найпоширеніші команди kubectl для створення Deployment'ів, які запускатимуть ваші застосунки у Kubernetes кластері.

+ + +

Коли ви створюєте Deployment, вам необхідно задати образ контейнера для вашого застосунку і скільки реплік ви хочете запустити. Згодом цю інформацію можна змінити, оновивши Deployment. У навчальних модулях 5 і 6 йдеться про те, як масштабувати і оновлювати Deployment'и.

+ + + + +
+
+
+ +

Для того, щоб розгортати застосунки в Kubernetes, їх потрібно упакувати в один із підтримуваних форматів контейнерів

+
+
+
+ +
+
+ +

+ Для створення Deployment'а ви використовуватимете застосунок, написаний на Node.js і упакований в Docker контейнер. (Якщо ви ще не пробували створити Node.js застосунок і розгорнути його у контейнері, радимо почати саме з цього; інструкції ви знайдете у навчальному матеріалі Привіт Minikube). +

+ + +

Тепер ви знаєте, що таке Deployment. Тож давайте перейдемо до інтерактивного уроку і розгорнемо ваш перший застосунок!

+
+
+
+ +
+
+ Почати інтерактивний урок › +
+
+ +
+ +
+ + + diff --git a/content/uk/docs/tutorials/kubernetes-basics/explore/_index.md b/content/uk/docs/tutorials/kubernetes-basics/explore/_index.md new file mode 100644 index 0000000000..93ac6a7774 --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/explore/_index.md @@ -0,0 +1,4 @@ +--- +title: Вивчення застосунку +weight: 30 +--- diff --git a/content/uk/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/explore/explore-interactive.html new file mode 100644 index 0000000000..a4bec18079 --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/explore/explore-interactive.html @@ -0,0 +1,41 @@ +--- +title: Інтерактивний урок - Вивчення застосунку +weight: 20 +--- + + + + + + + + + + + +
+ +
+ +
+
+ +
+ Для роботи з терміналом використовуйте комп'ютер або планшет +
+ +
+
+
+
+
+ Перейти до модуля 4› +
+
+ +
+ +
+ + + diff --git a/content/uk/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/uk/docs/tutorials/kubernetes-basics/explore/explore-intro.html new file mode 100644 index 0000000000..b40ac6e1ef --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -0,0 +1,200 @@ +--- +title: Ознайомлення з Pod'ами і вузлами (nodes) +weight: 10 +--- + + + + + + + + + + +
+ +
+ +
+ +
+ +

Цілі

+
    + +
  • Дізнатися, що таке Pod'и Kubernetes.
    • + +
  • Дізнатися, що таке вузли Kubernetes.
    • + +
  • Діагностика розгорнутих застосунків.
    • +
+
+ +
+ +

Pod'и Kubernetes

+ +

Коли ви створили Deployment у модулі 2, Kubernetes створив Pod, щоб розмістити ваш застосунок. Pod - це абстракція в Kubernetes, що являє собою групу з одного або декількох контейнерів застосунку (як Docker або rkt) і ресурси, спільні для цих контейнерів. До цих ресурсів належать:

+
    + +
  • Спільні сховища даних, або Volumes
    • + +
  • Мережа, адже кожен Pod у кластері має унікальну IP-адресу
    • + +
  • Інформація з запуску кожного контейнера, така як версія образу контейнера або використання певних портів
    • +
+ +

Pod моделює специфічний для даного застосунку "логічний хост" і може містити різні, але доволі щільно зв'язані контейнери. Наприклад, в одному Pod'і може бути контейнер з вашим Node.js застосунком та інший контейнер, що передає дані для публікації Node.js вебсерверу. Контейнери в межах Pod'а мають спільну IP-адресу і порти, завжди є сполученими, плануються для запуску разом і запускаються у спільному контексті на одному вузлі.

+ + +

Pod є неподільною одиницею платформи Kubernetes. Коли ви створюєте Deployment у Kubernetes, цей Deployment створює Pod'и вже з контейнерами всередині, на відміну від створення контейнерів окремо. Кожен Pod прив'язаний до вузла, до якого його було розподілено, і лишається на ньому до припинення роботи (згідно з політикою перезапуску) або видалення. У разі відмови вузла ідентичні Pod'и розподіляються по інших доступних вузлах кластера.

+ +
+
+
+

Зміст:

+
    +
  • Pod'и
    • +
  • Вузли
    • +
  • Основні команди kubectl
    • +
+
+
+ +

+ Pod - це група з одного або декількох контейнерів (таких як Docker або rkt), що має спільне сховище даних (volumes), унікальну IP-адресу і містить інформацію як їх запустити. +

+
+
+
+
+ +
+
+

Узагальнена схема Pod'ів

+
+
+ +
+
+

+
+
+
+ +
+
+ +

Вузли

+ +

Pod завжди запускається на вузлі. Вузол - це робоча машина в Kubernetes, віртуальна або фізична, в залежності від кластера. Функціонування кожного вузла контролюється master'ом. Вузол може мати декілька Pod'ів. Kubernetes master автоматично розподіляє Pod'и по вузлах кластера з урахуванням ресурсів, наявних на кожному вузлі.

+ + +

На кожному вузлі Kubernetes запущені як мінімум:

+
    + +
  • kubelet - процес, що забезпечує обмін даними між Kubernetes master і робочим вузлом; kubelet контролює Pod'и і контейнери, запущені на машині.
    • + +
  • оточення для контейнерів (таке як Docker, rkt), що забезпечує завантаження образу контейнера з реєстру, розпакування контейнера і запуск застосунку.
    • + +
+ +
+
+
+ +

Контейнери повинні бути разом в одному Pod'і, лише якщо вони щільно зв'язані і мають спільні ресурси, такі як диск.

+
+
+
+ +
+ +
+
+

Узагальнена схема вузлів

+
+
+ +
+
+

+
+
+
+ +
+
+ +

Діагностика за допомогою kubectl

+ +

У модулі 2 ви вже використовували інтерфейс командного рядка kubectl. У модулі 3 ви продовжуватимете користуватися ним для отримання інформації про застосунки та оточення, в яких вони розгорнуті. Нижченаведені команди kubectl допоможуть вам виконати наступні поширені дії:

+
    + +
  • kubectl get - відобразити список ресурсів
    • + +
  • kubectl describe - показати детальну інформацію про ресурс
    • + +
  • kubectl logs - вивести логи контейнера, розміщеного в Pod'і
    • + +
  • kubectl exec - виконати команду в контейнері, розміщеному в Pod'і
    • +
+ + +

За допомогою цих команд ви можете подивитись, коли і в якому оточенні був розгорнутий застосунок, перевірити його поточний статус і конфігурацію.

+ + +

А зараз, коли ми дізналися більше про складові нашого кластера і командний рядок, давайте детальніше розглянемо наш застосунок.

+ +
+
+
+ +

Вузол - це робоча машина в Kubernetes, віртуальна або фізична, в залежності від кластера. На одному вузлі можуть бути запущені декілька Pod'ів.

+
+
+
+
+ +
+
+ Почати інтерактивний урок › +
+
+ +
+ +
+ + + diff --git a/content/uk/docs/tutorials/kubernetes-basics/expose/_index.md b/content/uk/docs/tutorials/kubernetes-basics/expose/_index.md new file mode 100644 index 0000000000..ef49a1b632 --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/expose/_index.md @@ -0,0 +1,4 @@ +--- +title: Відкриття доступу до застосунку за межами кластера +weight: 40 +--- diff --git a/content/uk/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/expose/expose-interactive.html new file mode 100644 index 0000000000..4f3a87928d --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -0,0 +1,38 @@ +--- +title: Інтерактивний урок - Відкриття доступу до застосунку +weight: 20 +--- + + + + + + + + + + + +
+ +
+ +
+
+ Для роботи з терміналом використовуйте комп'ютер або планшет +
+
+
+
+
+
+ Перейти до модуля 5› +
+
+ +
+ +
+ + + diff --git a/content/uk/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/uk/docs/tutorials/kubernetes-basics/expose/expose-intro.html new file mode 100644 index 0000000000..61521e394b --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -0,0 +1,169 @@ +--- +#title: Using a Service to Expose Your App +title: Використання Cервісу для відкриття доступу до застосунку за межами кластера +weight: 10 +--- + + + + + + + + + +
+ +
+ +
+
+ +

Цілі

+
    + +
  • Дізнатись, що таке Cервіс у Kubernetes
    • + +
  • Зрозуміти, яке відношення до Cервісу мають мітки та LabelSelector
    • + +
  • Відкрити доступ до застосунку за межами Kubernetes кластера, використовуючи Cервіс
    • +
+
+ +
+ +

Загальна інформація про Kubernetes Cервіси

+ + +

Pod'и Kubernetes "смертні" і мають власний життєвий цикл. Коли робочий вузол припиняє роботу, ми також втрачаємо всі Pod'и, запущені на ньому. ReplicaSet здатна динамічно повернути кластер до бажаного стану шляхом створення нових Pod'ів, забезпечуючи безперебійність роботи вашого застосунку. Як інший приклад, візьмемо бекенд застосунку для обробки зображень із трьома репліками. Ці репліки взаємозамінні; система фронтенду не повинна зважати на репліки бекенду чи на втрату та перестворення Pod'а. Водночас, кожний Pod у Kubernetes кластері має унікальну IP-адресу, навіть Pod'и на одному вузлі. Відповідно, має бути спосіб автоматично синхронізувати зміни між Pod'ами для того, щоб ваші застосунки продовжували працювати.

+ + +

Service у Kubernetes - це абстракція, що визначає логічний набір Pod'ів і політику доступу до них. Services уможливлюють слабку зв'язаність між залежними Pod'ами. Для визначення Service використовують YAML-файл (рекомендовано) або JSON, як для решти об'єктів Kubernetes. Набір Pod'ів, призначених для Service, зазвичай визначається через LabelSelector (нижче пояснюється, чому параметр selector іноді не включають у специфікацію Service).

+ + +

Попри те, що кожен Pod має унікальний IP, ці IP-адреси не видні за межами кластера без Service. Services уможливлюють надходження трафіка до ваших застосунків. Відкрити Service можна по-різному, вказавши потрібний type у ServiceSpec:

+
    + +
  • ClusterIP (типове налаштування) - відкриває доступ до Service у кластері за внутрішнім IP. Цей тип робить Service доступним лише у межах кластера.
    • + +
  • NodePort - відкриває доступ до Service на однаковому порту кожного обраного вузла в кластері, використовуючи NAT. Робить Service доступним поза межами кластера, використовуючи <NodeIP>:<NodePort>. Є надмножиною відносно ClusterIP.
    • + +
  • LoadBalancer - створює зовнішній балансувальник навантаження у хмарі (за умови хмарної інфраструктури) і призначає Service статичну зовнішню IP-адресу. Є надмножиною відносно NodePort.
    • + +
  • ExternalName - відкриває доступ до Service, використовуючи довільне ім'я (визначається параметром externalName у специфікації), повертає запис CNAME. Проксі не використовується. Цей тип потребує версії kube-dns 1.7 і вище.
    • +
+ +

Більше інформації про різні типи Services ви знайдете у навчальному матеріалі Використання вихідної IP-адреси. Дивіться також Поєднання застосунків з Services.

+ +

Також зауважте, що для деяких сценаріїв використання Services параметр selector не задається у специфікації Service. Service, створений без визначення параметра selector, також не створюватиме відповідного Endpoint об'єкта. Це дозволяє користувачам вручну спроектувати Service на конкретні кінцеві точки (endpoints). Інший випадок, коли Селектор може бути не потрібний - використання строго заданого параметра type: ExternalName.

+
+
+
+ +

Зміст

+
    + +
  • Відкриття Pod'ів для зовнішнього трафіка
    • + +
  • Балансування навантаження трафіка між Pod'ами
    • + +
  • Використання міток
    • +
+
+
+ +

Service Kubernetes - це шар абстракції, який визначає логічний набір Pod'ів і відкриває їх для зовнішнього трафіка, балансує навантаження і здійснює виявлення цих Pod'ів.

+
+
+
+
+ +
+
+ +

Services і мітки

+
+
+ +
+
+

+
+
+ +
+
+ +

Service маршрутизує трафік між Pod'ами, що входять до його складу. Service - це абстракція, завдяки якій Pod'и в Kubernetes "вмирають" і відтворюються, не впливаючи на роботу вашого застосунку. Services в Kubernetes здійснюють виявлення і маршрутизацію між залежними Pod'ами (як наприклад, фронтенд- і бекенд-компоненти застосунку).

+ +

Services співвідносяться з набором Pod'ів за допомогою міток і Селекторів -- примітивів групування, що роблять можливими логічні операції з об'єктами у Kubernetes. Мітки являють собою пари ключ/значення, що прикріплені до об'єктів і можуть використовуватися для різних цілей:

+
    + +
  • Позначення об'єктів для дев, тест і прод оточень
    • + +
  • Прикріплення тегу версії
    • + +
  • Класифікування об'єктів за допомогою тегів
    • +
+ +
+
+
+ +

Ви можете створити Service одночасно із Deployment, виконавши команду
--expose в kubectl.

+
+
+
+ +
+ +
+
+

+
+
+
+
+
+ +

Мітки можна прикріпити до об'єктів під час створення або пізніше. Їх можна змінити у будь-який час. А зараз давайте відкриємо наш застосунок за допомогою Service і прикріпимо мітки.

+
+
+
+
+
+ Почати інтерактивний урок› +
+
+
+
+ + + diff --git a/content/uk/docs/tutorials/kubernetes-basics/scale/_index.md b/content/uk/docs/tutorials/kubernetes-basics/scale/_index.md new file mode 100644 index 0000000000..c6e1a94dc1 --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/scale/_index.md @@ -0,0 +1,4 @@ +--- +title: Масштабування застосунку +weight: 50 +--- diff --git a/content/uk/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/scale/scale-interactive.html new file mode 100644 index 0000000000..540ae92b23 --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/scale/scale-interactive.html @@ -0,0 +1,40 @@ +--- +title: Інтерактивний урок - Масштабування застосунку +weight: 20 +--- + + + + + + + + + + + +
+ +
+ +
+
+ Для роботи з терміналом використовуйте комп'ютер або планшет +
+
+
+
+
+
+ Перейти до модуля 6› +
+
+ +
+ + + +
+ + + diff --git a/content/uk/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/uk/docs/tutorials/kubernetes-basics/scale/scale-intro.html new file mode 100644 index 0000000000..0add32ddc1 --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -0,0 +1,145 @@ +--- +title: Запуск вашого застосунку на декількох Pod'ах +weight: 10 +--- + + + + + + + + + +
+ +
+ +
+ +
+ +

Цілі

+
    + +
  • Масштабувати застосунок за допомогою kubectl.
    • +
+
+ +
+ +

Масштабування застосунку

+ + +

У попередніх модулях ми створили Deployment і відкрили його для зовнішнього трафіка за допомогою Service. Deployment створив лише один Pod для запуску нашого застосунку. Коли трафік збільшиться, нам доведеться масштабувати застосунок, аби задовольнити вимоги користувачів.

+ + +

Масштабування досягається шляхом зміни кількості реплік у Deployment'і.

+ +
+
+
+ +

Зміст:

+
    + +
  • Масштабування Deployment'а
    • +
+
+
+ +

Кількість Pod'ів можна вказати одразу при створенні Deployment'а за допомогою параметра --replicas, під час запуску команди kubectl run

+
+
+
+
+ +
+
+

Загальна інформація про масштабування

+
+
+ +
+
+
+ +
+
+ +
+ +
+
+ + +

Масштабування Deployment'а забезпечує створення нових Pod'ів і їх розподілення по вузлах з доступними ресурсами. Масштабування збільшить кількість Pod'ів відповідно до нового бажаного стану. Kubernetes також підтримує автоматичне масштабування, однак це виходить за межі даного матеріалу. Масштабування до нуля також можливе - це призведе до видалення всіх Pod'ів у визначеному Deployment'і.

+ + +

Запустивши застосунок на декількох Pod'ах, необхідно розподілити між ними трафік. Services мають інтегрований балансувальник навантаження, що розподіляє мережевий трафік між усіма Pod'ами відкритого Deployment'а. Services безперервно моніторять запущені Pod'и за допомогою кінцевих точок, для того щоб забезпечити надходження трафіка лише на доступні Pod'и.

+ +
+
+
+ +

Масштабування досягається шляхом зміни кількості реплік у Deployment'і.

+
+
+
+ +
+ +
+
+ +

Після запуску декількох примірників застосунку ви зможете виконувати послідовне оновлення без шкоди для доступності системи. Ми розповімо вам про це у наступному модулі. А зараз давайте повернемось до онлайн термінала і масштабуємо наш застосунок.

+
+
+
+ +
+
+ Почати інтерактивний урок › +
+
+ +
+ +
+ + + diff --git a/content/uk/docs/tutorials/kubernetes-basics/update/_index.md b/content/uk/docs/tutorials/kubernetes-basics/update/_index.md new file mode 100644 index 0000000000..c253433db1 --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/update/_index.md @@ -0,0 +1,4 @@ +--- +title: Оновлення застосунку +weight: 60 +--- diff --git a/content/uk/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/update/update-interactive.html new file mode 100644 index 0000000000..5d8e398b40 --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -0,0 +1,37 @@ +--- +title: Інтерактивний урок - Оновлення застосунку +weight: 20 +--- + + + + + + + + + + + +
+ +
+ +
+
+ Для роботи з терміналом використовуйте комп'ютер або планшет +
+
+
+
+
+
+ Повернутися до "Основ Kubernetes"› +
+
+
+ +
+ + + diff --git a/content/uk/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/uk/docs/tutorials/kubernetes-basics/update/update-intro.html new file mode 100644 index 0000000000..089e567c35 --- /dev/null +++ b/content/uk/docs/tutorials/kubernetes-basics/update/update-intro.html @@ -0,0 +1,168 @@ +--- +title: Виконання послідовного оновлення (rolling update) +weight: 10 +--- + + + + + + + + + + +
+ +
+ +
+ +
+ +

Цілі

+
    + +
  • Виконати послідовне оновлення, використовуючи kubectl.
    • +
+
+ +
+ +

Оновлення застосунку

+ + +

Користувачі очікують від застосунків високої доступності у будь-який час, а розробники - оновлення цих застосунків декілька разів на день. У Kubernetes це стає можливим завдяки послідовному оновленню. Послідовні оновлення дозволяють оновити Deployment без простою, шляхом послідовної заміни одних Pod'ів іншими. Нові Pod'и розподіляються по вузлах з доступними ресурсами.

+ + +

У попередньому модулі ми масштабували наш застосунок, запустивши його на декількох Pod'ах. Масштабування - необхідна умова для проведення оновлень без шкоди для доступності застосунку. За типовими налаштуваннями, максимальна кількість Pod'ів, недоступних під час оновлення, і максимальна кількість нових Pod'ів, які можуть бути створені, дорівнює одиниці. Обидві опції можна налаштувати в числовому або відсотковому (від кількості Pod'ів) еквіваленті. + У Kubernetes оновлення версіонуються, тому кожне оновлення Deployment'а можна відкотити до попередньої (стабільної) версії.

+ +
+
+
+ +

Зміст:

+
    + +
  • Оновлення застосунку
    • +
+
+
+ +

Послідовне оновлення дозволяє оновити Deployment без простою шляхом послідовної заміни одних Pod'ів іншими.

+
+
+
+
+ +
+
+

Загальна інформація про послідовне оновлення

+
+
+
+
+
+ +
+
+
+ +
+
+ + +

Як і у випадку з масштабуванням, якщо Deployment "відкритий у світ", то під час оновлення Service розподілятиме трафік лише на доступні Pod'и. Під доступним мається на увазі Pod, готовий до експлуатації користувачами застосунку.

+ + +

Послідовне оновлення дозволяє вам:

+
    + +
  • Просувати застосунок з одного оточення в інше (шляхом оновлення образу контейнера)
    • + +
  • Відкочуватися до попередніх версій
    • + +
  • Здійснювати безперервну інтеграцію та розгортання застосунків без простою
    • + +
+ +
+
+
+ +

Якщо Deployment "відкритий у світ", то під час оновлення Service розподілятиме трафік лише на доступні Pod'и.

+
+
+
+ +
+ +
+
+ +

В інтерактивному уроці ми оновимо наш застосунок до нової версії, а потім відкотимося до попередньої.

+
+
+
+ +
+
+ Почати інтерактивний урок › +
+
+ +
+ +
+ + + diff --git a/content/uk/examples/controllers/job.yaml b/content/uk/examples/controllers/job.yaml new file mode 100644 index 0000000000..b448f2eb81 --- /dev/null +++ b/content/uk/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/uk/examples/controllers/nginx-deployment.yaml b/content/uk/examples/controllers/nginx-deployment.yaml new file mode 100644 index 0000000000..f7f95deebb --- /dev/null +++ b/content/uk/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/uk/examples/controllers/replication.yaml b/content/uk/examples/controllers/replication.yaml new file mode 100644 index 0000000000..6eff0b9b57 --- /dev/null +++ b/content/uk/examples/controllers/replication.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: ReplicationController +metadata: + name: nginx +spec: + replicas: 3 + selector: + app: nginx + template: + metadata: + name: nginx + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx + ports: + - containerPort: 80 diff --git a/content/uk/examples/minikube/Dockerfile b/content/uk/examples/minikube/Dockerfile new file mode 100644 index 0000000000..dd58cb7e75 --- /dev/null +++ b/content/uk/examples/minikube/Dockerfile @@ -0,0 +1,4 @@ +FROM node:6.14.2 +EXPOSE 8080 +COPY server.js . +CMD [ "node", "server.js" ] diff --git a/content/uk/examples/minikube/server.js b/content/uk/examples/minikube/server.js new file mode 100644 index 0000000000..76345a17d8 --- /dev/null +++ b/content/uk/examples/minikube/server.js @@ -0,0 +1,9 @@ +var http = require('http'); + +var handleRequest = function(request, response) { + console.log('Received request for URL: ' + request.url); + response.writeHead(200); + response.end('Hello World!'); +}; +var www = http.createServer(handleRequest); +www.listen(8080); diff --git a/content/uk/examples/service/networking/dual-stack-default-svc.yaml b/content/uk/examples/service/networking/dual-stack-default-svc.yaml new file mode 100644 index 0000000000..00ed87ba19 --- /dev/null +++ b/content/uk/examples/service/networking/dual-stack-default-svc.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 \ No newline at end of file diff --git a/content/uk/examples/service/networking/dual-stack-ipv4-svc.yaml b/content/uk/examples/service/networking/dual-stack-ipv4-svc.yaml new file mode 100644 index 0000000000..a875f44d6d --- /dev/null +++ b/content/uk/examples/service/networking/dual-stack-ipv4-svc.yaml @@ -0,0 +1,12 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + ipFamily: IPv4 + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 \ No newline at end of file diff --git a/content/uk/examples/service/networking/dual-stack-ipv6-lb-svc.yaml b/content/uk/examples/service/networking/dual-stack-ipv6-lb-svc.yaml new file mode 100644 index 0000000000..2586ec9b39 --- /dev/null +++ b/content/uk/examples/service/networking/dual-stack-ipv6-lb-svc.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-service + labels: + app: MyApp +spec: + ipFamily: IPv6 + type: LoadBalancer + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 \ No newline at end of file diff --git a/content/uk/examples/service/networking/dual-stack-ipv6-svc.yaml b/content/uk/examples/service/networking/dual-stack-ipv6-svc.yaml new file mode 100644 index 0000000000..2aa0725059 --- /dev/null +++ b/content/uk/examples/service/networking/dual-stack-ipv6-svc.yaml @@ -0,0 +1,12 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + ipFamily: IPv6 + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 \ No newline at end of file diff --git a/content/zh/docs/concepts/cluster-administration/addons.md b/content/zh/docs/concepts/cluster-administration/addons.md index be54c6f48b..c58f49b1ac 100644 --- a/content/zh/docs/concepts/cluster-administration/addons.md +++ b/content/zh/docs/concepts/cluster-administration/addons.md @@ -89,12 +89,12 @@ Add-ons 扩展了 Kubernetes 的功能。 ## 基础设施 -* [KubeVirt](https://kubevirt.io/user-guide/docs/latest/administration/intro.html#cluster-side-add-on-deployment) 是可以让 Kubernetes 运行虚拟机的 add-ons 。通常运行在裸机群集上。 +* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) 是可以让 Kubernetes 运行虚拟机的 add-ons 。通常运行在裸机群集上。 ## 监控计算资源使用 Pod 的资源使用情况被报告为 Pod 状态的一部分。 -如果为集群配置了 [可选监控](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/)，则可以从监控系统检索 Pod 资源的使用情况。 +如果为集群配置了可选 [监控工具](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)，则可以直接从 +[指标 API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api) 或者监控工具检索 Pod 资源的使用情况。 ## 介绍 -`StorageClass` 为管理员提供了描述存储 `"类"` 的方法。 -不同的`类型`可能会映射到不同的服务质量等级或备份策略，或是由集群管理员制定的任意策略。 -Kubernetes 本身并不清楚各种`类`代表的什么。这个`类`的概念在其他存储系统中有时被称为"配置文件"。 +StorageClass 为管理员提供了描述存储 "类" 的方法。 +不同的类型可能会映射到不同的服务质量等级或备份策略，或是由集群管理员制定的任意策略。 +Kubernetes 本身并不清楚各种类代表的什么。这个类的概念在其他存储系统中有时被称为 "配置文件"。 ## StorageClass 资源 -每个 `StorageClass` 都包含 `provisioner`、`parameters` 和 `reclaimPolicy` 字段， -这些字段会在`StorageClass`需要动态分配 `PersistentVolume` 时会使用到。 +每个 StorageClass 都包含 `provisioner`、`parameters` 和 `reclaimPolicy` 字段， +这些字段会在 StorageClass 需要动态分配 `PersistentVolume` 时会使用到。 -`StorageClass` 对象的命名很重要，用户使用这个命名来请求生成一个特定的类。 -当创建 `StorageClass` 对象时，管理员设置 StorageClass 对象的命名和其他参数，一旦创建了对象就不能再对其更新。 +StorageClass 对象的命名很重要，用户使用这个命名来请求生成一个特定的类。 +当创建 StorageClass 对象时，管理员设置 StorageClass 对象的命名和其他参数，一旦创建了对象就不能再对其更新。 -管理员可以为没有申请绑定到特定 `StorageClass` 的 PVC 指定一个默认的存储`类` ： -更多详情请参阅 [`PersistentVolumeClaim` 章节](/docs/concepts/storage/persistent-volumes/#class-1)。 +管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类 ： +更多详情请参阅 [PersistentVolumeClaim 章节](/docs/concepts/storage/persistent-volumes/#class-1)。 ```yaml apiVersion: storage.k8s.io/v1 @@ -87,38 +87,38 @@ volumeBindingMode: Immediate ### 存储分配器 -`StorageClass` 有一个分配器，用来决定使用哪个`卷插件`分配`PV`。该字段必须指定。 +每个 StorageClass 都有一个分配器，用来决定使用哪个卷插件分配 PV。该字段必须指定。 -| 卷插件 | 内置分配器 | 配置例子 | -| :--- | :---: | :---: | -| AWSElasticBlockStore | ✓ | [AWS EBS](#aws-ebs) | -| AzureFile | ✓ | [Azure File](#azure-file) | -| AzureDisk | ✓ | [Azure Disk](#azure-disk) | -| CephFS | - | - | -| Cinder | ✓ | [OpenStack Cinder](#openstack-cinder)| -| FC | - | - | -| FlexVolume | - | - | -| Flocker | ✓ | - | -| GCEPersistentDisk | ✓ | [GCE PD](#gce-pd) | -| Glusterfs | ✓ | [Glusterfs](#glusterfs) | -| iSCSI | - | - | -| Quobyte | ✓ | [Quobyte](#quobyte) | -| NFS | - | - | -| RBD | ✓ | [Ceph RBD](#ceph-rbd) | -| VsphereVolume | ✓ | [vSphere](#vsphere) | -| PortworxVolume | ✓ | [Portworx Volume](#portworx-volume) | -| ScaleIO | ✓ | [ScaleIO](#scaleio) | -| StorageOS | ✓ | [StorageOS](#storageos) | -| Local | - | [Local](#local) | +| 卷插件 | 内置分配器 | 配置例子 | +|:---------------------|:----------:|:-------------------------------------:| +| AWSElasticBlockStore | ✓ | [AWS EBS](#aws-ebs) | +| AzureFile | ✓ | [Azure File](#azure-file) | +| AzureDisk | ✓ | [Azure Disk](#azure-disk) | +| CephFS | - | - | +| Cinder | ✓ | [OpenStack Cinder](#openstack-cinder) | +| FC | - | - | +| FlexVolume | - | - | +| Flocker | ✓ | - | +| GCEPersistentDisk | ✓ | [GCE PD](#gce-pd) | +| Glusterfs | ✓ | [Glusterfs](#glusterfs) | +| iSCSI | - | - | +| Quobyte | ✓ | [Quobyte](#quobyte) | +| NFS | - | - | +| RBD | ✓ | [Ceph RBD](#ceph-rbd) | +| VsphereVolume | ✓ | [vSphere](#vsphere) | +| PortworxVolume | ✓ | [Portworx Volume](#portworx-volume) | +| ScaleIO | ✓ | [ScaleIO](#scaleio) | +| StorageOS | ✓ | [StorageOS](#storageos) | +| Local | - | [Local](#local) | -您不限于指定此处列出的"内置"分配器（其名称前缀为 kubernetes.io 并打包在 Kubernetes 中）。 +您不限于指定此处列出的 "内置" 分配器（其名称前缀为 "kubernetes.io" 并打包在 Kubernetes 中）。 您还可以运行和指定外部分配器，这些独立的程序遵循由 Kubernetes 定义的 [规范](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)。 外部供应商的作者完全可以自由决定他们的代码保存于何处、打包方式、运行方式、使用的插件（包括 Flex）等。 代码仓库 [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner) @@ -152,20 +152,20 @@ vendors provide their own external provisioner. ### 回收策略 -由 `StorageClass` 动态创建的持久化卷会在的 `reclaimPolicy` 字段中指定回收策略，可以是 -`Delete` 或者 `Retain`。如果 `StorageClass` 对象被创建时没有指定 `reclaimPolicy` ，它将默认为 `Delete`。 +由 StorageClass 动态创建的 PersistentVolume 会在类的 `reclaimPolicy` 字段中指定回收策略，可以是 +`Delete` 或者 `Retain`。如果 StorageClass 对象被创建时没有指定 `reclaimPolicy`，它将默认为 `Delete`。 -通过 `StorageClass` 手动创建并管理的 Persistent Volume 会使用它们被创建时指定的回收政策。 +通过 StorageClass 手动创建并管理的 PersistentVolume 会使用它们被创建时指定的回收政策。 -永久卷可以配置为可扩展。将此功能设置为 `true` 时，允许用户通过编辑相应的PVC对象来调整卷大小。 +PersistentVolume 可以配置为可扩展。将此功能设置为 `true` 时，允许用户通过编辑相应的 PVC 对象来调整卷大小。 -当基础存储类的 `allowVolumeExpansion` 字段设置为true时，以下类型的卷支持卷扩展。 +当基础存储类的 `allowVolumeExpansion` 字段设置为 true 时，以下类型的卷支持卷扩展。 -* gcePersistentDisk -* awsElasticBlockStore -* Cinder -* glusterfs -* rbd -* Azure File -* Azure Disk -* Portworx -* FlexVolumes -* CSI {{< feature-state for_k8s_version="v1.14" state="alpha" >}} +{{< table caption = "Table of Volume types and the version of Kubernetes they require" >}} + + +| 卷类型 | Kubernetes 版本要求 | +|:---------------------|:--------------------------| +| gcePersistentDisk | 1.11 | +| awsElasticBlockStore | 1.11 | +| Cinder | 1.11 | +| glusterfs | 1.11 | +| rbd | 1.11 | +| Azure File | 1.11 | +| Azure Disk | 1.11 | +| Portworx | 1.11 | +| FlexVolume | 1.13 | +| CSI | 1.14 (alpha), 1.16 (beta) | + +{{< /table >}} {{< note >}} - -此功能不能用于缩小卷。 - +此功能仅可用于扩容卷，不能用于缩小卷。 {{< /note >}} ### 挂载选项 -由 `StorageClass` 动态创建的 Persistent Volume 将使用`类`中 `mountOption` 字段指定的挂载选项。 +由 StorageClass 动态创建的 PersistentVolume 将使用类中 `mountOptions` 字段指定的挂载选项。 如果卷插件不支持挂载选项，却指定了该选项，则分配操作会失败。 -挂载选项在 `StorageClass` 和持久卷上都不会做验证，所以如果挂载选项无效，那么这个 PV 就会失败。 +挂载选项在 StorageClass 和 PV 上都不会做验证，所以如果挂载选项无效，那么这个 PV 就会失败。 ### 卷绑定模式 -{{< feature-state for_k8s_version="v1.12" state="beta" >}} - - -**注意：** 这个功能特性需要启用 `VolumeScheduling` 参数才能使用。 - 以下插件支持预创建绑定 PersistentVolume 的 `WaitForFirstConsumer` 模式： -* All of the above +* 上述全部 * [Local](#local) -{{< feature-state state="beta" for_k8s_version="1.14" >}} +{{< feature-state state="beta" for_k8s_version="1.17" >}} -动态配置和预先创建的PVs也支持 [CSI卷](/docs/concepts/storage/volumes/#csi)， -但是您需要查看特定CSI驱动程序的文档以查看其支持的拓扑密钥和例子。 必须启用 `CSINodeInfo` 特性。 +动态配置和预先创建的 PV 也支持 [CSI卷](/docs/concepts/storage/volumes/#csi)， +但是您需要查看特定 CSI 驱动程序的文档以查看其支持的拓扑键名和例子。 -**注意：** 这个特性需要开启 `VolumeScheduling` 特性开关。 - -这个例子描述了如何将分配卷限的拓扑限制在特定的区域，在使用时应该根据插件支持情况替换 `zone` 和 `zones` 参数。 +这个例子描述了如何将分配卷的拓扑限制在特定的区域，在使用时应该根据插件支持情况替换 `zone` 和 `zones` 参数。 ```yaml apiVersion: storage.k8s.io/v1 @@ -358,12 +352,18 @@ class. Different parameters may be accepted depending on the `provisioner`. For example, the value `io1`, for the parameter `type`, and the parameter `iopsPerGB` are specific to EBS. When a parameter is omitted, some default is used. + +There can be at most 512 parameters defined for a StorageClass. +The total length of the parameters object including its keys and values cannot +exceed 256 KiB. --> ## 参数 Storage class 具有描述属于卷的参数。取决于分配器，可以接受不同的参数。 例如，参数 type 的值 io1 和参数 iopsPerGB 特定于 EBS PV。当参数被省略时，会使用默认值。 +一个 StorageClass 最多可以定义 512 个参数。这些参数对象的总长度不能超过 256 KiB, 包括参数的键和值。 + ### AWS EBS ```yaml @@ -441,11 +441,13 @@ parameters: is specified, volumes are generally round-robin-ed across all active zones where Kubernetes cluster has a node. `zone` and `zones` parameters must not be used at the same time. +* `fstype`: `ext4` or `xfs`. Default: `ext4`. The defined filesystem type must be supported by the host operating system. * `replication-type`: `none` or `regional-pd`. Default: `none`. --> * `type`：`pd-standard` 或者 `pd-ssd`。默认：`pd-standard` * `zone`(弃用)：GCE 区域。如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。 * `zones`(弃用)：逗号分隔的 GCE 区域列表。如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度（round-robin）分配。`zone` 和 `zones` 参数不能同时使用。 +* `fstype`: `ext4` 或 `xfs`。 默认: `ext4`。宿主机操作系统必须支持所定义的文件系统类型。 * `replication-type`：`none` 或者 `regional-pd`。默认值：`none`。 -#### Azure Unmanaged Disk Storage Class（非托管磁盘存储类） +#### Azure Unmanaged Disk Storage Class（非托管磁盘存储类）{#azure-unmanaged-disk-storage-class} ```yaml kind: StorageClass @@ -921,9 +923,9 @@ parameters: * `storageAccount`：Azure 存储帐户名称。如果提供存储帐户，它必须位于与集群相同的资源组中，并且 `location` 是被忽略的。如果未提供存储帐户，则会在与群集相同的资源组中创建新的存储帐户。 -#### 新的 Azure 磁盘 Storage Class（从 v1.7.2 开始） +#### Azure 磁盘 Storage Class（从 v1.7.2 开始）{#azure-disk-storage-class} ```yaml kind: StorageClass @@ -945,12 +947,15 @@ parameters: unmanaged disk in the same resource group as the cluster. When `kind` is `managed`, all managed disks are created in the same resource group as the cluster. +* `resourceGroup`: Specify the resource group in which the Azure disk will be created. + It must be an existing resource group name. If it is unspecified, the disk will be + placed in the same resource group as the current Kubernetes cluster. --> * `storageaccounttype`：Azure 存储帐户 Sku 层。默认为空。 * `kind`：可能的值是 `shared`（默认）、`dedicated` 和 `managed`。 当 `kind` 的值是 `shared` 时，所有非托管磁盘都在集群的同一个资源组中的几个共享存储帐户中创建。 当 `kind` 的值是 `dedicated` 时，将为在集群的同一个资源组中新的非托管磁盘创建新的专用存储帐户。 - +* `resourceGroup`: 指定要创建 Azure 磁盘所属的资源组。必须是已存在的资源组名称。若未指定资源组，磁盘会默认放入与当前 Kubernetes 集群相同的资源组中。 -* [Kubernetes 基础知识](/docs/tutorials/Kubernetes-Basics/)是一个深入的交互式教程，帮助您理解 Kubernetes 系统，并尝试一些基本的 Kubernetes 特性。 +* [Kubernetes 基础知识](/zh/docs/tutorials/Kubernetes-Basics/)是一个深入的交互式教程，帮助您理解 Kubernetes 系统，并尝试一些基本的 Kubernetes 特性。 -* [你好 Minikube](/docs/tutorials/hello-minikube/) +* [你好 Minikube](/zh/docs/tutorials/hello-minikube/) ## 配置 @@ -69,7 +69,7 @@ Before walking through each tutorial, you may want to bookmark the ## Configuration --> -* [使用一个 ConfigMap 配置 Redis](/docs/tutorials/configuration/configure-redis-using-configmap/) +* [使用一个 ConfigMap 配置 Redis](/zh/docs/tutorials/configuration/configure-redis-using-configmap/) -* [公开外部 IP 地址访问集群中的应用程序](/docs/tutorials/stateless-application/expose-external-ip-address/) +* [公开外部 IP 地址访问集群中的应用程序](/zh/docs/tutorials/stateless-application/expose-external-ip-address/) -* [示例：使用 Redis 部署 PHP 留言板应用程序](/docs/tutorials/stateless-application/guestbook/) +* [示例：使用 Redis 部署 PHP 留言板应用程序](/zh/docs/tutorials/stateless-application/guestbook/) -* [StatefulSet 基础](/docs/tutorials/stateful-application/basic-stateful-set/) +* [StatefulSet 基础](/zh/docs/tutorials/stateful-application/basic-stateful-set/) -* [示例：WordPress 和 MySQL 使用持久卷](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) +* [示例：WordPress 和 MySQL 使用持久卷](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) -* [示例：使用有状态集部署 Cassandra](/docs/tutorials/stateful-application/cassandra/) +* [示例：使用有状态集部署 Cassandra](/zh/docs/tutorials/stateful-application/cassandra/) -* [运行 ZooKeeper，CP 分布式系统](/docs/tutorials/stateful-application/zookeeper/) +* [运行 ZooKeeper，CP 分布式系统](/zh/docs/tutorials/stateful-application/zookeeper/) -2. AppArmor 内核模块已启用 -- 要使 Linux 内核强制执行 AppArmor 配置文件，必须安装并且启动 AppArmor 内核模块。默认情况下，有几个发行版支持该模块，如 Ubuntu 和 SUSE，还有许多发行版提供可选支持。要检查模块是否已启用，请检查 +2. AppArmor 内核模块已启用 -- 要使 Linux 内核强制执行 AppArmor 配置文件，必须安装并且启动 AppArmor 内核模块。默认情况下，有几个发行版支持该模块，如 Ubuntu 和 SUSE，还有许多发行版提供可选支持。要检查模块是否已启用，请检查 `/sys/module/apparmor/parameters/enabled` 文件： ```shell cat /sys/module/apparmor/parameters/enabled @@ -423,7 +423,7 @@ Kubernetes 目前不提供任何本地机制来将 AppArmor 配置文件加载 image. * By copying the profiles to each node and loading them through SSH, as demonstrated in the [Example](#example). --> -* 通过在每个节点上运行 Pod 的[DaemonSet](/docs/concepts/workloads/controllers/daemonset/)确保加载了正确的配置文件。可以找到一个示例实现[这里](https://git.k8s.io/kubernetes/test/images/apparmor-loader)。 +* 通过在每个节点上运行 Pod 的[DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/)确保加载了正确的配置文件。可以找到一个示例实现[这里](https://git.k8s.io/kubernetes/test/images/apparmor-loader)。 * 在节点初始化时，使用节点初始化脚本(例如 Salt 、Ansible 等)或镜像。 * 通过将配置文件复制到每个节点并通过 SSH 加载它们，如[示例](#example)。 @@ -432,7 +432,7 @@ must be loaded onto every node. An alternative approach is to add a node label class of profiles) on the node, and use a [node selector](/docs/concepts/configuration/assign-pod-node/) to ensure the Pod is run on a node with the required profile. --> -调度程序不知道哪些配置文件加载到哪个节点上，因此必须将全套配置文件加载到每个节点上。另一种方法是为节点上的每个配置文件(或配置文件类)添加节点标签，并使用[节点选择器](/docs/concepts/configuration/assign pod node/)确保 Pod 在具有所需配置文件的节点上运行。 +调度程序不知道哪些配置文件加载到哪个节点上，因此必须将全套配置文件加载到每个节点上。另一种方法是为节点上的每个配置文件(或配置文件类)添加节点标签，并使用[节点选择器](/zh/docs/concepts/configuration/assign pod node/)确保 Pod 在具有所需配置文件的节点上运行。 ### 使用 PodSecurityPolicy 限制配置文件 @@ -525,7 +525,7 @@ logs or through `journalctl`. More information is provided in 想要调试 AppArmor 的问题，您可以检查系统日志，查看具体拒绝了什么。AppArmor 将详细消息记录到 `dmesg` ，错误通常可以在系统日志中或通过 `journalctl` 找到。更多详细信息见[AppArmor 失败](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures)。 -## API 参考 +## API 参考 ### Pod 注释 diff --git a/content/zh/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/zh/docs/tutorials/configuration/configure-redis-using-configmap.md index 7150b572e1..8cc92c076e 100644 --- a/content/zh/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/zh/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -9,9 +9,9 @@ content_template: templates/tutorial {{% capture overview %}} -这篇文档基于[使用 ConfigMap 来配置 Containers](/docs/tasks/configure-pod-container/configure-pod-configmap/) 这个任务，提供了一个使用 ConfigMap 来配置 Redis 的真实案例。 +这篇文档基于[使用 ConfigMap 来配置 Containers](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 这个任务，提供了一个使用 ConfigMap 来配置 Redis 的真实案例。 {{% /capture %}} @@ -43,7 +43,7 @@ This page provides a real world example of how to configure Redis using a Config * Understand [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/). --> * 此页面上显示的示例适用于 `kubectl` 1.14和在其以上的版本。 -* 理解[使用ConfigMap来配置Containers](/docs/tasks/configure-pod-container/configure-pod-configmap/)。 +* 理解[使用ConfigMap来配置Containers](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。 {{% /capture %}} @@ -77,8 +77,8 @@ configMapGenerator: EOF ``` - 将 pod 的资源配置添加到 `kustomization.yaml` 文件中： @@ -93,8 +93,8 @@ resources: EOF ``` - 应用整个 kustomization 文件夹以创建 ConfigMap 和 Pod 对象： @@ -102,8 +102,8 @@ Apply the kustomization directory to create both the ConfigMap and Pod objects: kubectl apply -k . ``` - 使用以下命令检查创建的对象 @@ -116,20 +116,20 @@ NAME READY STATUS RESTARTS AGE pod/redis 1/1 Running 0 52s ``` - 在示例中，配置卷挂载在 `/redis-master` 下。 它使用 `path` 将 `redis-config` 密钥添加到名为 `redis.conf` 的文件中。 因此，redis配置的文件路径为 `/redis-master/redis.conf`。 这是镜像将在其中查找 redis master 的配置文件的位置。 - 使用 `kubectl exec` 进入 pod 并运行 `redis-cli` 工具来验证配置已正确应用： @@ -143,8 +143,8 @@ kubectl exec -it redis redis-cli 2) "allkeys-lru" ``` - 删除创建的 pod： ```shell @@ -155,10 +155,10 @@ kubectl delete pod redis {{% capture whatsnext %}} - -* 了解有关 [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)的更多信息。 +* 了解有关 [ConfigMaps](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)的更多信息。 {{% /capture %}} diff --git a/content/zh/docs/tutorials/hello-minikube.md b/content/zh/docs/tutorials/hello-minikube.md index c10be6b6f9..bafa1340f2 100644 --- a/content/zh/docs/tutorials/hello-minikube.md +++ b/content/zh/docs/tutorials/hello-minikube.md @@ -36,13 +36,13 @@ This tutorial shows you how to run a simple Hello World Node.js app on Kubernetes using [Minikube](/docs/setup/learning-environment/minikube) and Katacoda. Katacoda provides a free, in-browser Kubernetes environment. --> -本教程向您展示如何使用 [Minikube](/docs/setup/learning-environment/minikube) 和 Katacoda 在 Kubernetes 上运行一个简单的 “Hello World” Node.js 应用程序。Katacoda 提供免费的浏览器内 Kubernetes 环境。 +本教程向您展示如何使用 [Minikube](/zh/docs/setup/learning-environment/minikube) 和 Katacoda 在 Kubernetes 上运行一个简单的 “Hello World” Node.js 应用程序。Katacoda 提供免费的浏览器内 Kubernetes 环境。 {{< note >}} -如果您已在本地安装 [Minikube](/docs/tasks/tools/install-minikube/)，也可以按照本教程操作。 +如果您已在本地安装 [Minikube](/zh/docs/tasks/tools/install-minikube/)，也可以按照本教程操作。 {{< /note >}} @@ -127,7 +127,7 @@ recommended way to manage the creation and scaling of Pods. ## 创建 Deployment -Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) 是由一个或多个为了管理和联网而绑定在一起的容器构成的组。本教程中的 Pod 只有一个容器。Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) 检查 Pod 的健康状况，并在 Pod 中的容器终止的情况下重新启动新的容器。Deployment 是管理 Pod 创建和扩展的推荐方法。 +Kubernetes [*Pod*](/zh/docs/concepts/workloads/pods/pod/) 是由一个或多个为了管理和联网而绑定在一起的容器构成的组。本教程中的 Pod 只有一个容器。Kubernetes [*Deployment*](/zh/docs/concepts/workloads/controllers/deployment/) 检查 Pod 的健康状况，并在 Pod 中的容器终止的情况下重新启动新的容器。Deployment 是管理 Pod 创建和扩展的推荐方法。 - {{< note >}}有关 kubectl 命令的更多信息，请参阅 [kubectl 概述](/docs/user-guide/kubectl-overview/)。{{< /note >}} + {{< note >}}有关 kubectl 命令的更多信息，请参阅 [kubectl 概述](/zh/docs/user-guide/kubectl-overview/)。{{< /note >}} -* 进一步了解 [Deployment 对象](/docs/concepts/workloads/controllers/deployment/)。 -* 学习更多关于 [部署应用](/docs/tasks/run-application/run-stateless-application-deployment/)。 -* 学习更多关于 [Service 对象](/docs/concepts/services-networking/service/)。 +* 进一步了解 [Deployment 对象](/zh/docs/concepts/workloads/controllers/deployment/)。 +* 学习更多关于 [部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。 +* 学习更多关于 [Service 对象](/zh/docs/concepts/services-networking/service/)。 {{% /capture %}} diff --git a/content/zh/docs/tutorials/services/source-ip.md b/content/zh/docs/tutorials/services/source-ip.md index d8811a57ce..098f5d760f 100644 --- a/content/zh/docs/tutorials/services/source-ip.md +++ b/content/zh/docs/tutorials/services/source-ip.md @@ -24,8 +24,8 @@ Kubernetes 集群中运行的应用通过 Service 抽象来互相查找、通信 * [NAT](https://en.wikipedia.org/wiki/Network_address_translation): 网络地址转换 * [Source NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT): 替换数据包的源 IP, 通常为节点的 IP * [Destination NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT): 替换数据包的目的 IP, 通常为 Pod 的 IP -* [VIP](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): 一个虚拟 IP, 例如分配给每个 Kubernetes Service 的 IP -* [Kube-proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): 一个网络守护程序，在每个节点上协调 Service VIP 管理 +* [VIP](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): 一个虚拟 IP, 例如分配给每个 Kubernetes Service 的 IP +* [Kube-proxy](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): 一个网络守护程序，在每个节点上协调 Service VIP 管理 ## 准备工作 @@ -59,7 +59,7 @@ deployment.apps/source-ip-app created ## Type=ClusterIP 类型 Services 的 Source IP -如果你的 kube-proxy 运行在 [iptables 模式](/docs/user-guide/services/#proxy-mode-iptables)下，从集群内部发送到 ClusterIP 的包永远不会进行源地址 NAT，这从 Kubernetes 1.2 开始是默认选项。Kube-proxy 通过一个 `proxyMode` endpoint 暴露它的模式。 +如果你的 kube-proxy 运行在 [iptables 模式](/zh/docs/user-guide/services/#proxy-mode-iptables)下，从集群内部发送到 ClusterIP 的包永远不会进行源地址 NAT，这从 Kubernetes 1.2 开始是默认选项。Kube-proxy 通过一个 `proxyMode` endpoint 暴露它的模式。 ```console kubectl get nodes @@ -136,7 +136,7 @@ command=GET ## Type=NodePort 类型 Services 的 Source IP -从 Kubernetes 1.5 开始，发送给类型为 [Type=NodePort](/docs/user-guide/services/#type-nodeport) Services 的数据包默认进行源地址 NAT。你可以通过创建一个 `NodePort` Service 来进行测试： +从 Kubernetes 1.5 开始，发送给类型为 [Type=NodePort](/zh/docs/user-guide/services/#type-nodeport) Services 的数据包默认进行源地址 NAT。你可以通过创建一个 `NodePort` Service 来进行测试： ```console kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort @@ -189,7 +189,7 @@ client_address=10.240.0.3 ``` -为了防止这种情况发生，Kubernetes 提供了一个特性来保留客户端的源 IP 地址[(点击此处查看可用特性)](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)。设置 `service.spec.externalTrafficPolicy` 的值为 `Local`，请求就只会被代理到本地 endpoints 而不会被转发到其它节点。这样就保留了最初的源 IP 地址。如果没有本地 endpoints，发送到这个节点的数据包将会被丢弃。这样在应用到数据包的任何包处理规则下，你都能依赖这个正确的 source-ip 使数据包通过并到达 endpoint。 +为了防止这种情况发生，Kubernetes 提供了一个特性来保留客户端的源 IP 地址[(点击此处查看可用特性)](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)。设置 `service.spec.externalTrafficPolicy` 的值为 `Local`，请求就只会被代理到本地 endpoints 而不会被转发到其它节点。这样就保留了最初的源 IP 地址。如果没有本地 endpoints，发送到这个节点的数据包将会被丢弃。这样在应用到数据包的任何包处理规则下，你都能依赖这个正确的 source-ip 使数据包通过并到达 endpoint。 设置 `service.spec.externalTrafficPolicy` 字段如下： @@ -244,7 +244,7 @@ client_address=104.132.1.79 ## Type=LoadBalancer 类型 Services 的 Source IP -从Kubernetes1.5开始，发送给类型为 [Type=LoadBalancer](/docs/user-guide/services/#type-nodeport) Services 的数据包默认进行源地址 NAT，这是因为所有处于 `Ready` 状态的可调度 Kubernetes 节点对于负载均衡的流量都是符合条件的。所以如果数据包到达一个没有 endpoint 的节点，系统将把这个包代理到*有* endpoint 的节点，并替换数据包的源 IP 为节点的 IP（如前面章节所述）。 +从Kubernetes1.5开始，发送给类型为 [Type=LoadBalancer](/zh/docs/user-guide/services/#type-nodeport) Services 的数据包默认进行源地址 NAT，这是因为所有处于 `Ready` 状态的可调度 Kubernetes 节点对于负载均衡的流量都是符合条件的。所以如果数据包到达一个没有 endpoint 的节点，系统将把这个包代理到*有* endpoint 的节点，并替换数据包的源 IP 为节点的 IP（如前面章节所述）。 你可以通过在一个 loadbalancer 上暴露这个 source-ip-app 来进行测试。 @@ -390,6 +390,6 @@ $ kubectl delete deployment source-ip-app {{% capture whatsnext %}} -* 学习更多关于 [通过 services 连接应用](/docs/concepts/services-networking/connect-applications-service/) -* 学习更多关于 [负载均衡](/docs/user-guide/load-balancer) +* 学习更多关于 [通过 services 连接应用](/zh/docs/concepts/services-networking/connect-applications-service/) +* 学习更多关于 [负载均衡](/zh/docs/user-guide/load-balancer) {{% /capture %}} diff --git a/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md index 2586d8600a..e48f5f2528 100644 --- a/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md @@ -13,37 +13,37 @@ approvers: {{% capture overview %}} - -本教程介绍如何了使用 [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/) 来管理应用。演示了如何创建、删除、扩容/缩容和更新 StatefulSets 的 Pods。 +本教程介绍如何了使用 [StatefulSets](/zh/docs/concepts/abstractions/controllers/statefulsets/) 来管理应用。演示了如何创建、删除、扩容/缩容和更新 StatefulSets 的 Pods。 {{% /capture %}} {{% capture prerequisites %}} - 在开始本教程之前，你应该熟悉以下 Kubernetes 的概念： -* [Pods](/docs/user-guide/pods/single-container/) -* [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/) -* [Headless Services](/docs/concepts/services-networking/service/#headless-services) -* [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) +* [Pods](/zh/docs/user-guide/pods/single-container/) +* [Cluster DNS](/zh/docs/concepts/services-networking/dns-pod-service/) +* [Headless Services](/zh/docs/concepts/services-networking/service/#headless-services) +* [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) * [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) -* [StatefulSets](/docs/concepts/workloads/controllers/statefulset/) -* [kubectl CLI](/docs/user-guide/kubectl/) +* [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/) +* [kubectl CLI](/zh/docs/user-guide/kubectl/) - @@ -53,11 +53,11 @@ tutorial. {{% capture objectives %}} - 下载上面的例子并保存为文件 `web.yaml`。 -你需要使用两个终端窗口。在第一个终端中，使用 [`kubectl get`](/docs/user-guide/kubectl/{{< param "version" >}}/#get) 来查看 StatefulSet 的 Pods 的创建情况。 +你需要使用两个终端窗口。在第一个终端中，使用 [`kubectl get`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#get) 来查看 StatefulSet 的 Pods 的创建情况。 ```shell kubectl get pods -w -l app=nginx ``` -在另一个终端中，使用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)来创建定义在 `web.yaml` 中的 Headless Service 和 StatefulSet。 +在另一个终端中，使用 [`kubectl apply`](/zh/docs/reference/generated/kubectl/kubectl-commands/#apply)来创建定义在 `web.yaml` 中的 Headless Service 和 StatefulSet。 ```shell kubectl apply -f web.yaml @@ -123,8 +123,8 @@ statefulset.apps/web created ``` @@ -144,9 +144,9 @@ web 2 1 20s ### Ordered Pod Creation -For a StatefulSet with N replicas, when Pods are being deployed, they are -created sequentially, in order from {0..N-1}. Examine the output of the -`kubectl get` command in the first terminal. Eventually, the output will +For a StatefulSet with N replicas, when Pods are being deployed, they are +created sequentially, in order from {0..N-1}. Examine the output of the +`kubectl get` command in the first terminal. Eventually, the output will look like the example below. --> @@ -165,14 +165,14 @@ web-0 1/1 Running 0 19s web-1 0/1 Pending 0 0s web-1 0/1 Pending 0 0s web-1 0/1 ContainerCreating 0 0s -web-1 1/1 Running 0 18s +web-1 1/1 Running 0 18s ``` -请注意在 `web-0` Pod 处于 [Running和Ready](/docs/user-guide/pod-states) 状态后 `web-1` Pod 才会被启动。 +请注意在 `web-0` Pod 处于 [Running和Ready](/zh/docs/user-guide/pod-states) 状态后 `web-1` Pod 才会被启动。 -如同 [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/) 概念中所提到的，StatefulSet 中的 Pod 拥有一个具有黏性的、独一无二的身份标志。这个标志基于 StatefulSet 控制器分配给每个 Pod 的唯一顺序索引。Pod 的名称的形式为`-`。`web`StatefulSet 拥有两个副本，所以它创建了两个 Pod：`web-0`和`web-1`。 +如同 [StatefulSets](/zh/docs/concepts/abstractions/controllers/statefulsets/) 概念中所提到的，StatefulSet 中的 Pod 拥有一个具有黏性的、独一无二的身份标志。这个标志基于 StatefulSet 控制器分配给每个 Pod 的唯一顺序索引。Pod 的名称的形式为`-`。`web`StatefulSet 拥有两个副本，所以它创建了两个 Pod：`web-0`和`web-1`。 ### 使用稳定的网络身份标识 -每个 Pod 都拥有一个基于其顺序索引的稳定的主机名。使用[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec)在每个 Pod 中执行`hostname`。 +每个 Pod 都拥有一个基于其顺序索引的稳定的主机名。使用[`kubectl exec`](/zh/docs/reference/generated/kubectl/kubectl-commands/#exec)在每个 Pod 中执行`hostname`。 ```shell for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done @@ -231,17 +231,17 @@ web-0 web-1 ``` - -使用 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) 运行一个提供 `nslookup` 命令的容器，该命令来自于 `dnsutils` 包。通过对 Pod 的主机名执行 `nslookup`，你可以检查他们在集群内部的 DNS 地址。 +使用 [`kubectl run`](/zh/docs/reference/generated/kubectl/kubectl-commands/#run) 运行一个提供 `nslookup` 命令的容器，该命令来自于 `dnsutils` 包。通过对 Pod 的主机名执行 `nslookup`，你可以检查他们在集群内部的 DNS 地址。 ```shell -kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm nslookup web-0.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -258,11 +258,11 @@ Address 1: 10.244.2.6 ``` headless service 的 CNAME 指向 SRV 记录（记录每个 Running 和 Ready 状态的 Pod）。SRV 记录指向一个包含 Pod IP 地址的记录表项。 @@ -274,11 +274,11 @@ kubectl get pod -w -l app=nginx ``` -在另一个终端中使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) 删除 StatefulSet 中所有的 Pod。 +在另一个终端中使用 [`kubectl delete`](/zh/docs/reference/generated/kubectl/kubectl-commands/#delete) 删除 StatefulSet 中所有的 Pod。 ```shell kubectl delete pod -l app=nginx @@ -287,7 +287,7 @@ pod "web-1" deleted ``` @@ -306,7 +306,7 @@ web-1 1/1 Running 0 34s ``` @@ -317,7 +317,7 @@ for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done web-0 web-1 -kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh nslookup web-0.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -333,23 +333,23 @@ Name: web-1.nginx Address 1: 10.244.2.8 ``` @@ -381,20 +381,20 @@ www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO ``` -StatefulSet 控制器创建了两个 PersistentVolumeClaims，绑定到两个 [PersistentVolumes](/docs/concepts/storage/volumes/)。由于本教程使用的集群配置为动态提供 PersistentVolume，所有的 PersistentVolume 都是自动创建和绑定的。 +StatefulSet 控制器创建了两个 PersistentVolumeClaims，绑定到两个 [PersistentVolumes](/zh/docs/concepts/storage/volumes/)。由于本教程使用的集群配置为动态提供 PersistentVolume，所有的 PersistentVolume 都是自动创建和绑定的。 NGINX web 服务器默认会加载位于 `/usr/share/nginx/html/index.html` 的 index 文件。StatefulSets `spec` 中的 `volumeMounts` 字段保证了 `/usr/share/nginx/html` 文件夹由一个 PersistentVolume 支持。 @@ -451,7 +451,7 @@ pod "web-0" deleted pod "web-1" deleted ``` @@ -482,14 +482,14 @@ web-1 ``` 在另一个终端窗口使用 `kubectl scale` 扩展副本数为 5。 @@ -527,7 +527,7 @@ kubectl scale sts web --replicas=5 statefulset.apps/web scaled ``` @@ -556,8 +556,8 @@ web-4 1/1 Running 0 19s 在另一个终端使用 `kubectl patch` 将 StatefulSet 缩容回三个副本。 @@ -614,11 +614,11 @@ web-3 1/1 Terminating 0 42s ### 顺序终止 Pod @@ -641,16 +641,16 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO ``` @@ -740,15 +740,15 @@ web-0 1/1 Running 0 10s ``` @@ -1026,22 +1026,22 @@ k8s.gcr.io/nginx-slim:0.7 ``` -使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) 删除 StatefulSet。请确保提供了 `--cascade=false` 参数给命令。这个参数告诉 Kubernetes 只删除 StatefulSet 而不要删除它的任何 Pod。 +使用 [`kubectl delete`](/zh/docs/reference/generated/kubectl/kubectl-commands/#delete) 删除 StatefulSet。请确保提供了 `--cascade=false` 参数给命令。这个参数告诉 Kubernetes 只删除 StatefulSet 而不要删除它的任何 Pod。 ```shell kubectl delete statefulset web --cascade=false @@ -1141,7 +1141,7 @@ kubectl get pods -w -l app=nginx 在另一个终端里重新创建 StatefulSet。请注意，除非你删除了 `nginx` Service （你不应该这样做），你将会看到一个错误，提示 Service 已经存在。 @@ -1154,7 +1154,7 @@ service/nginx unchanged ``` @@ -1181,14 +1181,14 @@ web-2 0/1 Terminating 0 3m ``` @@ -1204,10 +1204,10 @@ web-1 ``` @@ -1260,12 +1260,12 @@ web-1 0/1 Terminating 0 29m ``` @@ -1294,7 +1294,7 @@ statefulset.apps/web created ``` @@ -1307,8 +1307,8 @@ web-1 ``` @@ -1371,7 +1371,7 @@ Pod. @@ -1453,7 +1453,7 @@ web-3 1/1 Running 0 26s ``` @@ -1522,8 +1522,8 @@ kubectl delete svc nginx diff --git a/content/zh/docs/tutorials/stateful-application/cassandra.md b/content/zh/docs/tutorials/stateful-application/cassandra.md index 062171966f..98d0d6ab44 100644 --- a/content/zh/docs/tutorials/stateful-application/cassandra.md +++ b/content/zh/docs/tutorials/stateful-application/cassandra.md @@ -28,18 +28,18 @@ title: "Example: Deploying Cassandra with Stateful Sets" 本示例也使用了Kubernetes的一些核心组件： -- [_Pods_](/docs/user-guide/pods) -- [ _Services_](/docs/user-guide/services) -- [_Replication Controllers_](/docs/user-guide/replication-controller) -- [_Stateful Sets_](/docs/concepts/workloads/controllers/statefulset/) -- [_Daemon Sets_](/docs/admin/daemons) +- [_Pods_](/zh/docs/user-guide/pods) +- [ _Services_](/zh/docs/user-guide/services) +- [_Replication Controllers_](/zh/docs/user-guide/replication-controller) +- [_Stateful Sets_](/zh/docs/concepts/workloads/controllers/statefulset/) +- [_Daemon Sets_](/zh/docs/admin/daemons) ## 准备工作 -本示例假设你已经安装运行了一个 Kubernetes集群（版本 >=1.2），并且还在某个路径下安装了 [`kubectl`](/docs/tasks/tools/install-kubectl/) 命令行工具。请查看 [getting started guides](/docs/getting-started-guides/) 获取关于你的平台的安装说明。 +本示例假设你已经安装运行了一个 Kubernetes集群（版本 >=1.2），并且还在某个路径下安装了 [`kubectl`](/zh/docs/tasks/tools/install-kubectl/) 命令行工具。请查看 [getting started guides](/zh/docs/getting-started-guides/) 获取关于你的平台的安装说明。 本示例还需要一些代码和配置文件。为了避免手动输入，你可以 `git clone` Kubernetes 源到你本地。 @@ -133,7 +133,7 @@ kubectl delete daemonset cassandra ## 步骤 1：创建 Cassandra Headless Service -Kubernetes _[Service](/docs/user-guide/services)_ 描述一组执行同样任务的 [_Pod_](/docs/user-guide/pods)。在 Kubernetes 中，一个应用的原子调度单位是一个 Pod：一个或多个_必须_调度到相同主机上的容器。 +Kubernetes _[Service](/zh/docs/user-guide/services)_ 描述一组执行同样任务的 [_Pod_](/zh/docs/user-guide/pods)。在 Kubernetes 中，一个应用的原子调度单位是一个 Pod：一个或多个_必须_调度到相同主机上的容器。 这个 Service 用于在 Kubernetes 集群内部进行 Cassandra 客户端和 Cassandra Pod 之间的 DNS 查找。 @@ -354,7 +354,7 @@ $ kubectl exec cassandra-0 -- cqlsh -e 'desc keyspaces' system_traces system_schema system_auth system system_distributed ``` -你需要使用 `kubectl edit` 来增加或减小 Cassandra StatefulSet 的大小。你可以在[文档](/docs/user-guide/kubectl/kubectl_edit) 中找到更多关于 `edit` 命令的信息。 +你需要使用 `kubectl edit` 来增加或减小 Cassandra StatefulSet 的大小。你可以在[文档](/zh/docs/user-guide/kubectl/kubectl_edit) 中找到更多关于 `edit` 命令的信息。 使用以下命令编辑 StatefulSet。 @@ -429,7 +429,7 @@ $ grace=$(kubectl get po cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodS ## 步骤 5：使用 Replication Controller 创建 Cassandra 节点 pod -Kubernetes _[Replication Controller](/docs/user-guide/replication-controller)_ 负责复制一个完全相同的 pod 集合。像 Service 一样，它具有一个 selector query，用来识别它的集合成员。和 Service 不一样的是，它还具有一个期望的副本数，并且会通过创建或删除 Pod 来保证 Pod 的数量满足它期望的状态。 +Kubernetes _[Replication Controller](/zh/docs/user-guide/replication-controller)_ 负责复制一个完全相同的 pod 集合。像 Service 一样，它具有一个 selector query，用来识别它的集合成员。和 Service 不一样的是，它还具有一个期望的副本数，并且会通过创建或删除 Pod 来保证 Pod 的数量满足它期望的状态。 和我们刚才定义的 Service 一起，Replication Controller 能够让我们轻松的构建一个复制的、可扩展的 Cassandra 集群。 @@ -639,7 +639,7 @@ $ kubectl delete rc cassandra ## 步骤 8：使用 DaemonSet 替换 Replication Controller -在 Kubernetes中，[_DaemonSet_](/docs/admin/daemons) 能够将 pod 一对一的分布到 Kubernetes 节点上。和 _ReplicationController_ 相同的是它也有一个用于识别它的集合成员的 selector query。但和 _ReplicationController_ 不同的是，它拥有一个节点 selector，用于限制基于模板的 pod 可以调度的节点。并且 pod 的复制不是基于一个设置的数量，而是为每一个节点分配一个 pod。 +在 Kubernetes中，[_DaemonSet_](/zh/docs/admin/daemons) 能够将 pod 一对一的分布到 Kubernetes 节点上。和 _ReplicationController_ 相同的是它也有一个用于识别它的集合成员的 selector query。但和 _ReplicationController_ 不同的是，它拥有一个节点 selector，用于限制基于模板的 pod 可以调度的节点。并且 pod 的复制不是基于一个设置的数量，而是为每一个节点分配一个 pod。 示范用例：当部署到云平台时，预期情况是实例是短暂的并且随时可能终止。Cassandra 被搭建成为在各个节点间复制数据以便于实现数据冗余。这样的话，即使一个实例终止了，存储在它上面的数据却没有，并且集群会通过重新复制数据到其它运行节点来作为响应。 @@ -802,6 +802,6 @@ $ kubectl delete daemonset cassandra 查看本示例的 [image](https://github.com/kubernetes/examples/tree/master/cassandra/image) 目录，了解如何构建容器的 docker 镜像及其内容。 -你可能还注意到我们设置了一些 Cassandra 参数（`MAX_HEAP_SIZE`和`HEAP_NEWSIZE`），并且增加了关于 [namespace](/docs/user-guide/namespaces) 的信息。我们还告诉 Kubernetes 容器暴露了 `CQL` 和 `Thrift` API 端口。最后，我们告诉集群管理器我们需要 0.1 cpu（0.1 核）。 +你可能还注意到我们设置了一些 Cassandra 参数（`MAX_HEAP_SIZE`和`HEAP_NEWSIZE`），并且增加了关于 [namespace](/zh/docs/user-guide/namespaces) 的信息。我们还告诉 Kubernetes 容器暴露了 `CQL` 和 `Thrift` API 端口。最后，我们告诉集群管理器我们需要 0.1 cpu（0.1 核）。 [!Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/cassandra/README.md?pixel)]() diff --git a/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index ed0e8f8f7d..d05f07d135 100644 --- a/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -12,23 +12,23 @@ card: {{% capture overview %}} - 本示例描述了如何通过 Minikube 在 Kubernetes 上安装 WordPress 和 MySQL。这两个应用都使用 PersistentVolumes 和 PersistentVolumeClaims 保存数据。 -[PersistentVolume](/docs/concepts/storage/persistent-volumes/)（PV）是一块集群里由管理员手动提供，或 kubernetes 通过 [StorageClass](/docs/concepts/storage/storage-classes) 动态创建的存储。 -[PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)（PVC）是一个满足对 PV 存储需要的请求。PersistentVolumes 和 PersistentVolumeClaims 是独立于 Pod 生命周期而在 Pod 重启，重新调度甚至删除过程中保存数据。 +[PersistentVolume](/zh/docs/concepts/storage/persistent-volumes/)（PV）是一块集群里由管理员手动提供，或 kubernetes 通过 [StorageClass](/zh/docs/concepts/storage/storage-classes) 动态创建的存储。 +[PersistentVolumeClaim](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)（PVC）是一个满足对 PV 存储需要的请求。PersistentVolumes 和 PersistentVolumeClaims 是独立于 Pod 生命周期而在 Pod 重启，重新调度甚至删除过程中保存数据。 {{< warning >}} deployment 在生产场景中并不适合，它使用单实例 WordPress 和 MySQL Pods。考虑使用 [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress) 在生产场景中部署 WordPress。 @@ -53,7 +53,7 @@ deployment 在生产场景中并不适合，它使用单实例 WordPress 和 MyS * MySQL resource configs * WordPress resource configs * Apply the kustomization directory by `kubectl apply -k ./` -* Clean up +* Clean up --> * 创建 PersistentVolumeClaims 和 PersistentVolumes @@ -77,7 +77,7 @@ Download the following configuration files: 1. [mysql-deployment.yaml](/examples/application/wordpress/mysql-deployment.yaml) -1. [wordpress-deployment.yaml](/examples/application/wordpress/wordpress-deployment.yaml) +1. [wordpress-deployment.yaml](/examples/application/wordpress/wordpress-deployment.yaml) --> 此例在`kubectl` 1.14 或者更高版本有效。 @@ -86,14 +86,14 @@ Download the following configuration files: 1. [mysql-deployment.yaml](/examples/application/wordpress/mysql-deployment.yaml) -2. [wordpress-deployment.yaml](/examples/application/wordpress/wordpress-deployment.yaml) - +2. [wordpress-deployment.yaml](/examples/application/wordpress/wordpress-deployment.yaml) + {{% /capture %}} {{% capture lessoncontent %}} ## 创建 PersistentVolumeClaims 和 PersistentVolumes @@ -113,15 +113,15 @@ MySQL 和 Wordpress 都需要一个 PersistentVolume 来存储数据。他们的 {{< warning >}} 在本地群集中，默认的 StorageClass 使用`hostPath`供应器。 `hostPath`卷仅适用于开发和测试。使用 `hostPath` 卷，您的数据位于 Pod 调度到的节点上的`/tmp`中，并且不会在节点之间移动。如果 Pod 死亡并被调度到群集中的另一个节点，或者该节点重新启动，则数据将丢失。 {{< /warning >}} {{< note >}} - 如果要建立需要使用`hostPath`设置程序的集群，则必须在 controller-manager 组件中设置`--enable-hostpath-provisioner`标志。 @@ -133,14 +133,14 @@ If you are bringing up a cluster that needs to use the `hostPath` provisioner, t 如果你已经有运行在 Google Kubernetes Engine 的集群，请参考 [this guide](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk)。 {{< /note >}} - ## 创建 kustomization.yaml - ### 创建 Secret 生成器 @@ -148,10 +148,10 @@ If you are bringing up a cluster that needs to use the `hostPath` provisioner, t -A [Secret](/docs/concepts/configuration/secret/) 是存储诸如密码或密钥之类的敏感数据的对象。从 1.14 开始，`kubectl`支持使用 kustomization 文件管理 Kubernetes 对象。您可以通过`kustomization.yaml`中的生成器创建一个 Secret。 +A [Secret](/zh/docs/concepts/configuration/secret/) 是存储诸如密码或密钥之类的敏感数据的对象。从 1.14 开始，`kubectl`支持使用 kustomization 文件管理 Kubernetes 对象。您可以通过`kustomization.yaml`中的生成器创建一个 Secret。 通过以下命令在`kustomization.yaml`中添加一个 Secret 生成器。您需要用您要使用的密码替换`YOUR_PASSWORD`。 @@ -164,13 +164,13 @@ secretGenerator: EOF ``` - ## 补充 MySQL 和 WordPress 的资源配置 - @@ -178,11 +178,11 @@ The following manifest describes a single-instance MySQL Deployment. The MySQL c {{< codenew file="application/wordpress/mysql-deployment.yaml" >}} - 以下 manifest 文件描述了单实例 WordPress 部署。WordPress 容器将网站数据文件位于`/var/www/html`的 PersistentVolume。`WORDPRESS_DB_HOST`环境变量集上面定义的 MySQL Service 的名称，WordPress 将通过 Service 访问数据库。`WORDPRESS_DB_PASSWORD`环境变量设置从 Secret kustomize 生成的数据库密码。 @@ -234,8 +234,8 @@ the name of the MySQL Service defined above, and WordPress will access the datab ``` - ## 应用和验证 @@ -348,7 +348,7 @@ kubectl apply -k ./ ``` 响应应如下所示： - + ```shell NAME TYPE DATA AGE mysql-pass-c57bb4t7mf Opaque 1 9s @@ -419,7 +419,7 @@ kubectl apply -k ./ ``` 6. 复制 IP 地址，然后将页面加载到浏览器中来查看您的站点。 - + 您应该看到类似于以下屏幕截图的 WordPress 设置页面。 ![wordpress-init](https://raw.githubusercontent.com/kubernetes/examples/master/mysql-wordpress-pd/WordPress.png) @@ -427,8 +427,8 @@ kubectl apply -k ./ {{% /capture %}} {{< warning >}} - 不要在此页面上保留 WordPress 安装。如果其他用户找到了它，他们可以在您的实例上建立一个网站并使用它来提供恶意内容。

通过创建用户名和密码来安装 WordPress 或删除您的实例。 @@ -453,24 +453,16 @@ Do not leave your WordPress installation on this page. If another user finds it, {{% capture whatsnext %}} + -1. 运行以下命令以删除您的 Secret，Deployments，Services 和 PersistentVolumeClaims： - ```shell - kubectl delete -k ./ - ``` - -{{% /capture %}} - -{{% capture whatsnext %}} - -* 了解更多关于 [Introspection and Debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/) -* 了解更多关于 [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) -* 了解更多关于 [Port Forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) -* 了解如何 [Get a Shell to a Container](/docs/tasks/debug-application-cluster/get-shell-running-container/) +* 了解更多关于 [Introspection and Debugging](/zh/docs/tasks/debug-application-cluster/debug-application-introspection/) +* 了解更多关于 [Jobs](/zh/docs/concepts/workloads/controllers/jobs-run-to-completion/) +* 了解更多关于 [Port Forwarding](/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) +* 了解如何 [Get a Shell to a Container](/zh/docs/tasks/debug-application-cluster/get-shell-running-container/) {{% /capture %}} diff --git a/content/zh/docs/tutorials/stateful-application/zookeeper.md b/content/zh/docs/tutorials/stateful-application/zookeeper.md index a7bcaad1d7..2c5189ac4a 100644 --- a/content/zh/docs/tutorials/stateful-application/zookeeper.md +++ b/content/zh/docs/tutorials/stateful-application/zookeeper.md @@ -14,23 +14,23 @@ content_template: templates/tutorial {{% capture overview %}} -本教程展示了在 Kubernetes 上使用 [PodDisruptionBudgets](/docs/admin/disruptions/#specifying-a-poddisruptionbudget) 和 [PodAntiAffinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 特性运行 [Apache Zookeeper](https://zookeeper.apache.org)。 +本教程展示了在 Kubernetes 上使用 [PodDisruptionBudgets](/zh/docs/admin/disruptions/#specifying-a-poddisruptionbudget) 和 [PodAntiAffinity](/zh/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 特性运行 [Apache Zookeeper](https://zookeeper.apache.org)。 {{% /capture %}} {{% capture prerequisites %}} 在开始本教程前，你应该熟悉以下 Kubernetes 概念。 -* [Pods](/docs/user-guide/pods/single-container/) -* [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/) -* [Headless Services](/docs/concepts/services-networking/service/#headless-services) -* [PersistentVolumes](/docs/concepts/storage/volumes/) +* [Pods](/zh/docs/user-guide/pods/single-container/) +* [Cluster DNS](/zh/docs/concepts/services-networking/dns-pod-service/) +* [Headless Services](/zh/docs/concepts/services-networking/service/#headless-services) +* [PersistentVolumes](/zh/docs/concepts/storage/volumes/) * [PersistentVolume Provisioning](http://releases.k8s.io/{{< param "githubbranch" >}}/examples/persistent-volume-provisioning/) -* [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) -* [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/) -* [PodDisruptionBudgets](/docs/admin/disruptions/#specifying-a-poddisruptionbudget) -* [PodAntiAffinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) -* [kubectl CLI](/docs/user-guide/kubectl) +* [ConfigMaps](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) +* [StatefulSets](/zh/docs/concepts/abstractions/controllers/statefulsets/) +* [PodDisruptionBudgets](/zh/docs/admin/disruptions/#specifying-a-poddisruptionbudget) +* [PodAntiAffinity](/zh/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) +* [kubectl CLI](/zh/docs/user-guide/kubectl) @@ -69,14 +69,14 @@ ZooKeeper 在内存中保存它们的整个状态机，但是每个改变都被 下面的清单包含一个 -[Headless Service](/docs/concepts/services-networking/service/#headless-services)， -一个 [Service](/docs/concepts/services-networking/service/)， -一个 [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget)， -和一个 [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)。 +[Headless Service](/zh/docs/concepts/services-networking/service/#headless-services)， +一个 [Service](/zh/docs/concepts/services-networking/service/)， +一个 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget)， +和一个 [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)。 {{< codenew file="application/zookeeper/zookeeper.yaml" >}} -打开一个命令行终端，使用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) +打开一个命令行终端，使用 [`kubectl apply`](/zh/docs/reference/generated/kubectl/kubectl-commands/#apply) 创建这个清单。 ```shell @@ -92,7 +92,7 @@ poddisruptionbudget.policy/zk-pdb created statefulset.apps/zk created ``` -使用 [`kubectl get`](/docs/user-guide/kubectl/{{< param "version" >}}/#get) 查看 StatefulSet 控制器创建的 Pods。 +使用 [`kubectl get`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#get) 查看 StatefulSet 控制器创建的 Pods。 ```shell kubectl get pods -w -l app=zk @@ -130,7 +130,7 @@ StatefulSet 控制器创建了3个 Pods，每个 Pod 包含一个 [ZooKeeper 3.4 由于在匿名网络中没有用于选举 leader 的终止算法，Zab 要求显式的进行成员关系配置，以执行 leader 选举。Ensemble 中的每个服务都需要具有一个独一无二的标识符，所有的服务均需要知道标识符的全集，并且每个标志都需要和一个网络地址相关联。 -使用 [`kubectl exec`](/docs/user-guide/kubectl/{{< param "version" >}}/#exec) 获取 `zk` StatefulSet 中 Pods 的主机名。 +使用 [`kubectl exec`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#exec) 获取 `zk` StatefulSet 中 Pods 的主机名。 ```shell for i in 0 1 2; do kubectl exec zk-$i -- hostname; done @@ -184,7 +184,7 @@ zk-2.zk-headless.default.svc.cluster.local ``` -[Kubernetes DNS](/docs/concepts/services-networking/dns-pod-service/) 中的 A 记录将 FQDNs 解析成为 Pods 的 IP 地址。如果 Pods 被调度，这个 A 记录将会使用 Pods 的新 IP 地址更新，但 A 记录的名称不会改变。 +[Kubernetes DNS](/zh/docs/concepts/services-networking/dns-pod-service/) 中的 A 记录将 FQDNs 解析成为 Pods 的 IP 地址。如果 Pods 被调度，这个 A 记录将会使用 Pods 的新 IP 地址更新，但 A 记录的名称不会改变。 ZooKeeper 在一个名为 `zoo.cfg` 的文件中保存它的应用配置。使用 `kubectl exec` 在 `zk-0` Pod 中查看 `zoo.cfg` 文件的内容。 @@ -320,7 +320,7 @@ numChildren = 0 如同在 [ZooKeeper 基础](#zookeeper-basics) 一节所提到的，ZooKeeper 提交所有的条目到一个持久 WAL，并周期性的将内存快照写入存储介质。对于使用一致性协议实现一个复制状态机的应用来说，使用 WALs 提供持久化是一种常用的技术，对于普通的存储应用也是如此。 -使用 [`kubectl delete`](/docs/user-guide/kubectl/{{< param "version" >}}/#delete) 删除 `zk` StatefulSet。 +使用 [`kubectl delete`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#delete) 删除 `zk` StatefulSet。 ```shell kubectl delete statefulset zk @@ -641,7 +641,7 @@ log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %- 这是在容器里安全记录日志的最简单的方法。由于应用的日志被写入标准输出，Kubernetes 将会为你处理日志轮转。Kubernetes 还实现了一个智能保存策略，保证写入标准输出和标准错误流的应用日志不会耗尽本地存储媒介。 -使用 [`kubectl logs`](/docs/user-guide/kubectl/{{< param "version" >}}/#logs) 从一个 Pod 中取回最后几行日志。 +使用 [`kubectl logs`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#logs) 从一个 Pod 中取回最后几行日志。 ```shell kubectl logs zk-0 --tail 20 @@ -679,7 +679,7 @@ kubectl logs zk-0 --tail 20 ### 配置非特权用户 -在容器中允许应用以特权用户运行这条最佳实践是值得商讨的。如果你的组织要求应用以非特权用户运行，你可以使用 [SecurityContext](/docs/tasks/configure-pod-container/security-context/) 控制运行容器入口点的用户。 +在容器中允许应用以特权用户运行这条最佳实践是值得商讨的。如果你的组织要求应用以非特权用户运行，你可以使用 [SecurityContext](/zh/docs/tasks/configure-pod-container/security-context/) 控制运行容器入口点的用户。 `zk` StatefulSet 的 Pod 的 `template` 包含了一个 SecurityContext。 @@ -736,7 +736,7 @@ drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data ### 处理进程故障 -[Restart Policies](/docs/user-guide/pod-states/#restartpolicy) 控制 Kubernetes 如何处理一个 Pod 中容器入口点的进程故障。对于 StatefulSet 中的 Pods 来说，Always 是唯一合适的 RestartPolicy，这也是默认值。你应该**绝不**覆盖 stateful 应用的默认策略。 +[Restart Policies](/zh/docs/user-guide/pod-states/#restartpolicy) 控制 Kubernetes 如何处理一个 Pod 中容器入口点的进程故障。对于 StatefulSet 中的 Pods 来说，Always 是唯一合适的 RestartPolicy，这也是默认值。你应该**绝不**覆盖 stateful 应用的默认策略。 检查 `zk-0` Pod 中运行的 ZooKeeper 服务的进程树。 @@ -947,7 +947,7 @@ kubectl get nodes ``` -使用 [`kubectl cordon`](/docs/user-guide/kubectl/{{< param "version" >}}/#cordon) cordon 你的集群中除4个节点以外的所有节点。 +使用 [`kubectl cordon`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#cordon) cordon 你的集群中除4个节点以外的所有节点。 ```shell kubectl cordon < node name > @@ -987,7 +987,7 @@ kubernetes-minion-group-i4c4 ``` -使用 [`kubectl drain`](/docs/user-guide/kubectl/{{< param "version" >}}/#drain) 来 cordon 和 drain `zk-0` Pod 调度的节点。 +使用 [`kubectl drain`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#drain) 来 cordon 和 drain `zk-0` Pod 调度的节点。 ```shell kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data @@ -1102,7 +1102,7 @@ numChildren = 0 ``` -使用 [`kubectl uncordon`](/docs/user-guide/kubectl/{{< param "version" >}}/#uncordon) 来取消对第一个节点的隔离。 +使用 [`kubectl uncordon`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#uncordon) 来取消对第一个节点的隔离。 ```shell kubectl uncordon kubernetes-minion-group-pb41 diff --git a/content/zh/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/zh/docs/tutorials/stateless-application/expose-external-ip-address.md index b22d2a365a..371ba45f34 100644 --- a/content/zh/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/zh/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -37,10 +37,10 @@ external IP address. instructions, see the documentation for your cloud provider. --> - * 安装 [kubectl](/docs/tasks/tools/install-kubectl/). + * 安装 [kubectl](/zh/docs/tasks/tools/install-kubectl/). * 使用 Google Kubernetes Engine 或 Amazon Web Services 等云供应商创建 Kubernetes 群集。 - 本教程创建了一个[外部负载均衡器](/docs/tasks/access-application-cluster/create-external-load-balancer/)，需要云供应商。 + 本教程创建了一个[外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)，需要云供应商。 * 配置 `kubectl` 与 Kubernetes API 服务器通信。有关说明，请参阅云供应商文档。 @@ -86,9 +86,9 @@ external IP address. [Pods](/docs/concepts/workloads/pods/pod/), each of which runs the Hello World application. --> - 前面的命令创建一个 [Deployment](/docs/concepts/workloads/controllers/deployment/) - 对象和一个关联的 [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)对象。 - ReplicaSet 有五个 [Pod](/docs/concepts/workloads/pods/pod/)，每个都运行 Hello World 应用程序。 + 前面的命令创建一个 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) + 对象和一个关联的 [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)对象。 + ReplicaSet 有五个 [Pod](/zh/docs/concepts/workloads/pods/pod/)，每个都运行 Hello World 应用程序。 成功请求的响应是一条问候消息： @@ -252,6 +252,6 @@ Learn more about [connecting applications with services](/docs/concepts/services-networking/connect-applications-service/). --> -了解更多关于[将应用程序与服务连接](/docs/concepts/services-networking/connect-applications-service/)。 +了解更多关于[将应用程序与服务连接](/zh/docs/concepts/services-networking/connect-applications-service/)。 {{% /capture %}} diff --git a/content/zh/docs/tutorials/stateless-application/guestbook.md b/content/zh/docs/tutorials/stateless-application/guestbook.md index 0dac40d655..8eea7b7922 100644 --- a/content/zh/docs/tutorials/stateless-application/guestbook.md +++ b/content/zh/docs/tutorials/stateless-application/guestbook.md @@ -25,8 +25,8 @@ This tutorial shows you how to build and deploy a simple, multi-tier web applica 一个简单的多层 web 应用程序。本例由以下组件组成： @@ -145,12 +145,12 @@ Replace POD-NAME with the name of your Pod. -留言板应用程序需要往 Redis 主节点中写数据。因此，需要创建 [Service](/docs/concepts/services-networking/service/) 来代理 Redis 主节点 Pod 的流量。Service 定义了访问 Pod 的策略。 +留言板应用程序需要往 Redis 主节点中写数据。因此，需要创建 [Service](/zh/docs/concepts/services-networking/service/) 来代理 Redis 主节点 Pod 的流量。Service 定义了访问 Pod 的策略。 {{< codenew file="application/guestbook/redis-master-service.yaml" >}} 1. 使用下面的 `redis-master-service.yaml` 文件创建 Redis 主节点的服务： @@ -181,7 +181,7 @@ The guestbook applications needs to communicate to the Redis master to write its {{< note >}} 这个清单文件创建了一个名为 `Redis-master` 的 Service，其中包含一组与前面定义的标签匹配的标签，因此服务将网络流量路由到 Redis 主节点 Pod 上。 @@ -205,12 +205,12 @@ Although the Redis master is a single pod, you can make it highly available to m ### 创建 Redis 从节点 Deployment Deployments 根据清单文件中设置的配置进行伸缩。在这种情况下，Deployment 对象指定两个副本。 如果没有任何副本正在运行，则此 Deployment 将启动容器集群上的两个副本。相反， 如果有两个以上的副本在运行，那么它的规模就会缩小，直到运行两个副本为止。 @@ -352,17 +352,17 @@ The guestbook application has a web frontend serving the HTTP requests written i The `redis-slave` and `redis-master` Services you applied are only accessible within the container cluster because the default type for a Service is [ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types). `ClusterIP` provides a single IP address for the set of Pods the Service is pointing to. This IP address is accessible only within the cluster. --> 应用的 `redis-slave` 和 `redis-master` 服务只能在容器集群中访问，因为服务的默认类型是 -[ClusterIP](/docs/concepts/Services-networking/Service/#publishingservices-Service-types)。`ClusterIP` 为服务指向的 Pod 集提供一个 IP 地址。这个 IP 地址只能在集群中访问。 +[ClusterIP](/zh/docs/concepts/Services-networking/Service/#publishingservices-Service-types)。`ClusterIP` 为服务指向的 Pod 集提供一个 IP 地址。这个 IP 地址只能在集群中访问。 如果您希望客人能够访问您的留言板，您必须将前端服务配置为外部可见的，以便客户机可以从容器集群之外请求服务。Minikube 只能通过 `NodePort` 公开服务。 {{< note >}} 一些云提供商，如 Google Compute Engine 或 Google Kubernetes Engine，支持外部负载均衡器。如果您的云提供商支持负载均衡器，并且您希望使用它， 只需删除或注释掉 `type: NodePort`，并取消注释 `type: LoadBalancer` 即可。 @@ -386,14 +386,14 @@ Some cloud providers, like Google Compute Engine or Google Kubernetes Engine, su 2. 查询服务列表以验证前端服务正在运行: ```shell - kubectl get services + kubectl get services ``` 响应应该与此类似： - + ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend ClusterIP 10.0.0.112 80:31323/TCP 6s @@ -472,7 +472,7 @@ If you deployed the `frontend-service.yaml` manifest with type: `LoadBalancer` y 2. 复制外部 IP 地址，然后在浏览器中加载页面以查看留言板。 ## 扩展 Web 前端 @@ -501,7 +501,7 @@ Scaling up or down is easy because your servers are defined as a Service that us ``` 响应应该类似于这样： @@ -548,7 +548,7 @@ Scaling up or down is easy because your servers are defined as a Service that us redis-slave-2005841000-fpvqc 1/1 Running 0 1h redis-slave-2005841000-phfv9 1/1 Running 0 1h ``` - + {{% /capture %}} {{% capture cleanup %}} @@ -580,7 +580,7 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels deployment.apps "redis-slave" deleted service "redis-master" deleted service "redis-slave" deleted - deployment.apps "frontend" deleted + deployment.apps "frontend" deleted service "frontend" deleted ``` @@ -594,9 +594,9 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels ``` - 响应应该是： + 响应应该是： ``` No resources found. @@ -608,15 +608,15 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels -* 完成 [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) 交互式教程 -* 使用 Kubernetes 创建一个博客，使用 [MySQL 和 Wordpress 的持久卷](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog) -* 阅读更多关于[连接应用程序](/docs/concepts/services-networking/connect-applications-service/) -* 阅读更多关于[管理资源](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively) +* 完成 [Kubernetes Basics](/zh/docs/tutorials/kubernetes-basics/) 交互式教程 +* 使用 Kubernetes 创建一个博客，使用 [MySQL 和 Wordpress 的持久卷](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog) +* 阅读更多关于[连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/) +* 阅读更多关于[管理资源](/zh/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively) {{% /capture %}} diff --git a/i18n/uk.toml b/i18n/uk.toml new file mode 100644 index 0000000000..ef59e46cfa --- /dev/null +++ b/i18n/uk.toml @@ -0,0 +1,251 @@ +# i18n strings for the Ukrainian (main) site. + +[caution] +# other = "Caution:" +other = "Увага:" + +[cleanup_heading] +# other = "Cleaning up" +other = "Очистка" + +[community_events_calendar] +# other = "Events Calendar" +other = "Календар подій" + +[community_forum_name] +# other = "Forum" +other = "Форум" + +[community_github_name] +other = "GitHub" + +[community_slack_name] +other = "Slack" + +[community_stack_overflow_name] +other = "Stack Overflow" + +[community_twitter_name] +other = "Twitter" + +[community_youtube_name] +other = "YouTube" + +[deprecation_warning] +# other = " documentation is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the " +other = " документація більше не підтримується. Версія, яку ви зараз переглядаєте, є статичною. Для перегляду актуальної документації дивіться " + +[deprecation_file_warning] +# other = "Deprecated" +other = "Застаріла версія" + +[docs_label_browse] +# other = "Browse Docs" +other = "Переглянути документацію" + +[docs_label_contributors] +# other = "Contributors" +other = "Контриб'ютори" + +[docs_label_i_am] +# other = "I AM..." +other = "Я..." + +[docs_label_users] +# other = "Users" +other = "Користувачі" + +[feedback_heading] +# other = "Feedback" +other = "Ваша думка" + +[feedback_no] +# other = "No" +other = "Ні" + +[feedback_question] +# other = "Was this page helpful?" +other = "Чи була ця сторінка корисною?" + +[feedback_yes] +# other = "Yes" +other = "Так" + +[input_placeholder_email_address] +# other = "email address" +other = "електронна адреса" + +[latest_version] +# other = "latest version." +other = "остання версія." + +[layouts_blog_pager_prev] +# other = "<< Prev" +other = "<< Назад" + +[layouts_blog_pager_next] +# other = "Next >>" +other = "Далі >>" + +[layouts_case_studies_list_tell] +# other = "Tell your story" +other = "Розкажіть свою історію" + +[layouts_docs_glossary_aka] +# other = "Also known as" +other = "Також відомий як" + +[layouts_docs_glossary_description] +# other = "This glossary is intended to be a comprehensive, standardized list of Kubernetes terminology. It includes technical terms that are specific to Kubernetes, as well as more general terms that provide useful context." +other = "Даний словник створений як повний стандартизований список термінології Kubernetes. Він включає в себе технічні терміни, специфічні для Kubernetes, а також більш загальні терміни, необхідні для кращого розуміння контексту." + +[layouts_docs_glossary_deselect_all] +# other = "Deselect all" +other = "Очистити вибір" + +[layouts_docs_glossary_click_details_after] +# other = "indicators below to get a longer explanation for any particular term." +other = "для отримання розширеного пояснення конкретного терміна." + +[layouts_docs_glossary_click_details_before] +# other = "Click on the" +other = "Натисність на" + +[layouts_docs_glossary_filter] +# other = "Filter terms according to their tags" +other = "Відфільтрувати терміни за тегами" + +[layouts_docs_glossary_select_all] +# other = "Select all" +other = "Вибрати все" + +[layouts_docs_partials_feedback_improvement] +# other = "suggest an improvement" +other = "запропонувати покращення" + +[layouts_docs_partials_feedback_issue] +# other = "Open an issue in the GitHub repo if you want to " +other = "Створіть issue в GitHub репозиторії, якщо ви хочете " + +[layouts_docs_partials_feedback_or] +# other = "or" +other = "або" + +[layouts_docs_partials_feedback_problem] +# other = "report a problem" +other = "повідомити про проблему" + +[layouts_docs_partials_feedback_thanks] +# other = "Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on" +other = "Дякуємо за ваш відгук. Якщо ви маєте конкретне запитання щодо використання Kubernetes, ви можете поставити його" + +[layouts_docs_search_fetching] +# other = "Fetching results..." +other = "Отримання результатів..." + +[main_by] +other = "by" + +[main_cncf_project] +# other = """We are a CNCF graduated project

""" +other = """Ми є проектом CNCF

""" + +[main_community_explore] +# other = "Explore the community" +other = "Познайомитись із спільнотою" + +[main_contribute] +# other = "Contribute" +other = "Допомогти проекту" + +[main_copyright_notice] +# other = """The Linux Foundation ®. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page""" +other = """The Linux Foundation ®. Всі права застережено. The Linux Foundation є зареєстрованою торговою маркою. Перелік торгових марок The Linux Foundation ви знайдете на нашій сторінці Використання торгових марок""" + +[main_documentation_license] +# other = """The Kubernetes Authors | Documentation Distributed under CC BY 4.0""" +other = """Автори Kubernetes | Документація розповсюджується під ліцензією CC BY 4.0""" + +[main_edit_this_page] +# other = "Edit This Page" +other = "Редагувати цю сторінку" + +[main_github_create_an_issue] +# other = "Create an Issue" +other = "Створити issue" + +[main_github_invite] +# other = "Interested in hacking on the core Kubernetes code base?" +other = "Хочете зламати основну кодову базу Kubernetes?" + +[main_github_view_on] +# other = "View On GitHub" +other = "Переглянути у GitHub" + +[main_kubernetes_features] +# other = "Kubernetes Features" +other = "Функціональні можливості Kubernetes" + +[main_kubeweekly_baseline] +# other = "Interested in receiving the latest Kubernetes news? Sign up for KubeWeekly." +other = "Хочете отримувати останні новини Kubernetes? Підпишіться на KubeWeekly." + +[main_kubernetes_past_link] +# other = "View past newsletters" +other = "Переглянути попередні інформаційні розсилки" + +[main_kubeweekly_signup] +# other = "Subscribe" +other = "Підписатися" + +[main_page_history] +# other ="Page History" +other ="Історія сторінки" + +[main_page_last_modified_on] +# other = "Page last modified on" +other = "Сторінка востаннє редагувалася" + +[main_read_about] +# other = "Read about" +other = "Прочитати про" + +[main_read_more] +# other = "Read more" +other = "Прочитати більше" + +[note] +# other = "Note:" +other = "Примітка:" + +[objectives_heading] +# other = "Objectives" +other = "Цілі" + +[prerequisites_heading] +# other = "Before you begin" +other = "Перш ніж ви розпочнете" + +[ui_search_placeholder] +# other = "Search" +other = "Пошук" + +[version_check_mustbe] +# other = "Your Kubernetes server must be version " +other = "Версія вашого Kubernetes сервера має бути " + +[version_check_mustbeorlater] +# other = "Your Kubernetes server must be at or later than version " +other = "Версія вашого Kubernetes сервера має дорівнювати або бути молодшою ніж " + +[version_check_tocheck] +# other = "To check the version, enter " +other = "Для перевірки версії введіть " + +[warning] +# other = "Warning:" +other = "Попередження:" + +[whatsnext_heading] +# other = "What's next" +other = "Що далі" diff --git a/layouts/partials/head.html b/layouts/partials/head.html index 1e34c3c903..16b09cd103 100644 --- a/layouts/partials/head.html +++ b/layouts/partials/head.html @@ -52,3 +52,5 @@ {{ with .Params.js }}{{ range (split . ",") }} {{ end }}{{ else }}{{ end }} + + diff --git a/static/_redirects b/static/_redirects index 13cfce2d49..523d39cef9 100644 --- a/static/_redirects +++ b/static/_redirects @@ -16,6 +16,7 @@ /pl/docs/ /pl/docs/home/ 301! /pt/docs/ /pt/docs/home/ 301! /ru/docs/ /ru/docs/home/ 301! +/uk/docs/ /uk/docs/home/ 301! /vi/docs/ /vi/docs/home/ 301! /zh/docs/ /zh/docs/home/ 301! /blog/2018/03/kubernetes-1.10-stabilizing-storage-security-networking/ /blog/2018/03/26/kubernetes-1.10-stabilizing-storage-security-networking/ 301! @@ -132,8 +133,11 @@ /docs/contribute/review-issues/ /docs/home/contribute/review-issues/ 301 /docs/contribute/stage-documentation-changes/ /docs/home/contribute/stage-documentation-changes/ 301 /docs/contribute/style-guide/ /docs/home/contribute/style-guide/ 301 - /docs/contribute/write-new-topic/ /docs/home/contribute/write-new-topic/ 301 +/docs/contribute/start/ /docs/contribute/ 301 +/docs/contribute/intermediate/ /docs/contribute/ 301 + + /docs/deprecate/ /docs/reference/using-api/deprecation-policy/ 301 /docs/deprecated/ /docs/reference/using-api/deprecation-policy/ 301 /docs/deprecation-policy/ /docs/reference/using-api/deprecation-policy/ 301 @@ -477,4 +481,4 @@ /docs/setup/multiple-zones/ /docs/setup/best-practices/multiple-zones/ 301 /docs/setup/cluster-large/ /docs/setup/best-practices/cluster-large/ 301 /docs/setup/node-conformance/ /docs/setup/best-practices/node-conformance/ 301 -/docs/setup/certificates/ /docs/setup/best-practices/certificates/ 301 +/docs/setup/certificates/ /docs/setup/best-practices/certificates/ 301 \ No newline at end of file diff --git a/static/css/gridpage.css b/static/css/gridpage.css index d762aeb19c..297c7d3637 100644 --- a/static/css/gridpage.css +++ b/static/css/gridpage.css @@ -23,7 +23,6 @@ min-height: 152px; } - .gridPage p { color: rgb(26,26,26); margin-left: 0 !important; @@ -289,6 +288,15 @@ section.bullets .content { } } +@media screen and (max-width: 768px){ + .launch-card { + width: 100%; + margin-bottom: 30px; + padding: 0; + min-height: auto; + } +} + @media screen and (max-width: 640px){ .case-study { width: 100%; diff --git a/static/images/kubernetes-192x192.png b/static/images/kubernetes-192x192.png new file mode 100644 index 0000000000..49236b71bb Binary files /dev/null and b/static/images/kubernetes-192x192.png differ diff --git a/static/images/kubernetes-512x512.png b/static/images/kubernetes-512x512.png new file mode 100644 index 0000000000..1bf2ce524e Binary files /dev/null and b/static/images/kubernetes-512x512.png differ diff --git a/static/manifest.webmanifest b/static/manifest.webmanifest new file mode 100644 index 0000000000..8ae9a16ab3 --- /dev/null +++ b/static/manifest.webmanifest @@ -0,0 +1,22 @@ +{ + "short_name": "Kubernetes", + "name": "Kubernetes", + "description": "An open-source system for automating deployment, scaling, and management of containerized applications", + "icons": [ + { + "src": "/images/kubernetes-192x192.png", + "type": "image/png", + "sizes": "192x192" + }, + { + "src": "/images/kubernetes-512x512.png", + "type": "image/png", + "sizes": "512x512" + } + ], + "start_url": "/", + "background_color": "#326ce5", + "display": "browser", + "scope": "/", + "theme_color": "#326ce5" +}