diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 25b0ff4753..795b340ba3 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -16,7 +16,7 @@ If you're working on a different localization (not English), or you are documenting a feature that will be part of a future release, see - https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use + https://kubernetes.io/docs/contribute/new-content/overview/#choose-which-git-branch-to-use for advice. --> diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index a3ea95ab8a..bf78ef6a64 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -123,6 +123,7 @@ aliases: sig-docs-id-reviews: # PR reviews for Indonesian content - girikuncoro - irvifa + - wahyuoi sig-docs-it-owners: # Admins for Italian content - fabriziopandini - mattiaperi diff --git a/README-ru.md b/README-ru.md index 357578acf8..bb290654a8 100644 --- a/README-ru.md +++ b/README-ru.md @@ -1,58 +1,9 @@ # Документация по 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) +[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) Добро пожаловать! Данный репозиторий содержит все необходимые файлы для сборки [сайта Kubernetes и документации](https://kubernetes.io/). Мы благодарим вас за старания! -## Вклад в документацию - -Нажмите на кнопку **Fork** в правом верхнем углу, чтобы создать копию этого репозитория в ваш GitHub-аккаунт. Эта копия называется *форк-репозиторием*. Делайте любые изменения в вашем форк-репозитории, и когда вы будете готовы опубликовать изменения, откройте форк-репозиторий и создайте новый пулреквест, чтобы уведомить нас. - -После того, как вы отправите пулреквест, ревьювер Kubernetes даст по нему обратную связь. Вы, как автор пулреквеста, **должны обновить свой пулреквест после его рассмотрения ревьювером Kubernetes.** Вполне возможно, что более одного ревьювера 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/) - -## Файл `README.md` на других языках -| | | -|-------------------------------|-------------------------------| -| [Английский](README.md) | [Французский](README-fr.md) | -| [Корейский](README-ko.md) | [Немецкий](README-de.md) | -| [Португальский](README-pt.md) | [Хинди](README-hi.md) | -| [Испанский](README-es.md) | [Индонезийский](README-id.md) | -| [Китайский](README-zh.md) | [Японский](README-ja.md) | -| [Вьетнамский](README-vi.md) | [Итальянский](README-it.md) | -| [Польский]( README-pl.md) | [Украинский](README-uk.md) | -| | | - -## Запуск сайта локально с помощью Docker - -Рекомендованный способ запуска сайта Kubernetes на локальной машине - использовать специальный образ [Docker](https://docker.com), который включает статический генератор сайтов [Hugo](https://gohugo.io). - -> Если вы используете Windows, вам необходимо установить дополнительные инструменты через [Chocolatey](https://chocolatey.org). `choco install make` - -> Если вы хотите запустить сайт локально без Docker, обратитесь к разделу [Запуск сайта с помощью Hugo](#запуск-сайта-с-помощью-hugo) ниже на этой странице. - -Когда Docker [установлен и запущен](https://www.docker.com/get-started), соберите локально Docker-образ `kubernetes-hugo`, выполнив команду в консоли: - -```bash -make docker-image -``` - -После того, как вы собрали образ, можно запустить сайт локально: - -```bash -make docker-serve -``` - -Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайт. Если вы редактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере. - ## Запуск сайта с помощью Hugo Обратитесь к [официальной документации Hugo](https://gohugo.io/getting-started/installing/), чтобы установить Hugo. Убедитесь, что вы установили правильную версию Hugo, которая устанавливается в переменной окружения `HUGO_VERSION` в файле [`netlify.toml`](netlify.toml#L10). @@ -60,7 +11,9 @@ make docker-serve После установки Hugo, чтобы запустить сайт, выполните в консоли: ```bash -make serve +git clone https://github.com/kubernetes/website.git +cd website +hugo server --buildFuture ``` Эта команда запустит сервер Hugo на порту 1313. Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайт. Если вы отредактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере. @@ -74,9 +27,35 @@ make serve - [Канал в Slack](https://kubernetes.slack.com/messages/sig-docs) - [Рассылка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) +## Вклад в документацию + +Нажмите на кнопку **Fork** в правом верхнем углу, чтобы создать копию этого репозитория в ваш GitHub-аккаунт. Эта копия называется *форк-репозиторием*. Делайте любые изменения в вашем форк-репозитории, и когда вы будете готовы опубликовать изменения, откройте форк-репозиторий и создайте новый пулреквест, чтобы уведомить нас. + +После того, как вы отправите пулреквест, ревьювер Kubernetes даст по нему обратную связь. Вы, как автор пулреквеста, **должны обновить свой пулреквест после его рассмотрения ревьювером Kubernetes.** + +Вполне возможно, что более одного ревьювера Kubernetes оставят свои комментарии или даже может быть так, что новый комментарий ревьювера Kubernetes будет отличаться от первоначального назначенного ревьювера. Кроме того, в некоторых случаях один из ревьюверов может запросить технический обзор у [технического ревьювера Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers), если это будет необходимо. Ревьюверы сделают все возможное, чтобы как можно оперативно оставить свои предложения и пожелания, но время ответа может варьироваться в зависимости от обстоятельств. + +Узнать подробнее о том, как поучаствовать в документации Kubernetes, вы можете по ссылкам ниже: + +* [Начните вносить свой вклад](https://kubernetes.io/docs/contribute/) +* [Использование шаблонов страниц](http://kubernetes.io/docs/contribute/style/page-templates/) +* [Руководство по оформлению документации](http://kubernetes.io/docs/contribute/style/style-guide/) +* [Руководство по локализации Kubernetes](https://kubernetes.io/docs/contribute/localization/) + +## Файл `README.md` на других языках +| другие языки | другие языки | +|-------------------------------|-------------------------------| +| [Английский](README.md) | [Французский](README-fr.md) | +| [Корейский](README-ko.md) | [Немецкий](README-de.md) | +| [Португальский](README-pt.md) | [Хинди](README-hi.md) | +| [Испанский](README-es.md) | [Индонезийский](README-id.md) | +| [Китайский](README-zh.md) | [Японский](README-ja.md) | +| [Вьетнамский](README-vi.md) | [Итальянский](README-it.md) | +| [Польский]( README-pl.md) | [Украинский](README-uk.md) | + ### Кодекс поведения -Участие в сообществе Kubernetes регулируется [кодексом поведения Kubernetes](code-of-conduct.md). +Участие в сообществе Kubernetes регулируется [кодексом поведения CNCF](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). ## Спасибо! diff --git a/config.toml b/config.toml index 947a84ed96..42918484f2 100644 --- a/config.toml +++ b/config.toml @@ -14,12 +14,6 @@ contentDir = "content/en" timeout = 3000 -# Highlighting config. -pygmentsCodeFences = true -pygmentsUseClasses = false -# See https://help.farbox.com/pygments.html -pygmentsStyle = "emacs" - # Enable Git variables like commit, lastmod enableGitInfo = true @@ -27,10 +21,20 @@ enableGitInfo = true # Hindi is disabled because it's currently in development. disableLanguages = ["hi", "no"] -[blackfriday] -hrefTargetBlank = true -fractions = false -smartDashes = false +[markup] + [markup.goldmark] + [markup.goldmark.renderer] + unsafe = true + [markup.highlight] + codeFences = true + guessSyntax = false + hl_Lines = "" + lineNoStart = 1 + lineNos = false + lineNumbersInTable = true + noClasses = true + style = "emacs" + tabWidth = 4 [frontmatter] date = ["date", ":filename", "publishDate", "lastmod"] diff --git a/content/en/blog/_posts/2020-03-18-Kong-Ingress-Controller-and-Service-Mesh.md b/content/en/blog/_posts/2020-03-18-Kong-Ingress-Controller-and-Service-Mesh.md index 2023f2e1da..02ff17838a 100644 --- a/content/en/blog/_posts/2020-03-18-Kong-Ingress-Controller-and-Service-Mesh.md +++ b/content/en/blog/_posts/2020-03-18-Kong-Ingress-Controller-and-Service-Mesh.md @@ -97,7 +97,16 @@ reviews-v2-ccffdd984-9jnsj 2/2 Running 0 101s reviews-v3-98dc67b68-nzw97 2/2 Running 0 101s ``` -This command outputs useful data, so let’s take a second to understand it. If you examine the READY column, each pod has two containers running: the service and an Envoy sidecar injected alongside it. Another thing to highlight is that there are three review pods but only 1 review service. The Envoy sidecar will load balance the traffic to three different review pods that contain different versions, giving us the ability to A/B test our changes. With that said, you should now be able to access your product page! +This command outputs useful data, so let’s take a second to understand it. If you examine the READY column, each pod has two containers running: the service and an Envoy sidecar injected alongside it. Another thing to highlight is that there are three review pods but only 1 review service. The Envoy sidecar will load balance the traffic to three different review pods that contain different versions, giving us the ability to A/B test our changes. We have one step before we can access the deployed application. We need to add an additional annotation to the `productpage` service. To do so, run: + +``` +$ kubectl annotate service productpage ingress.kubernetes.io/service-upstream=true +service/productpage annotated +``` + +Both the API gateway (Kong) and the service mesh (Istio) can handle the load-balancing. Without the additional `ingress.kubernetes.io/service-upstream: "true"` annotation, Kong will try to load-balance by selecting its own endpoint/target from the productpage service. This causes Envoy to receive that pod’s IP as the upstream local address, instead of the service’s cluster IP. But we want the service's cluster IP so that Envoy can properly load balance. + +With that added, you should now be able to access your product page! ``` $ kubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') -c ratings -- curl productpage:9080/productpage | grep -o ".*" @@ -150,6 +159,8 @@ metadata: name: do-not-preserve-host route: preserve_host: false +upstream: + host_header: productpage.default.svc " | kubectl apply -f - kongingress.configuration.konghq.com/do-not-preserve-host created ``` diff --git a/content/en/case-studies/booz-allen/booz-allen-featured.svg b/content/en/case-studies/booz-allen/booz-allen-featured-logo.svg similarity index 100% rename from content/en/case-studies/booz-allen/booz-allen-featured.svg rename to content/en/case-studies/booz-allen/booz-allen-featured-logo.svg diff --git a/content/en/case-studies/booz-allen/index.html b/content/en/case-studies/booz-allen/index.html index 8b82ef3787..2a48c7f3b7 100644 --- a/content/en/case-studies/booz-allen/index.html +++ b/content/en/case-studies/booz-allen/index.html @@ -1,10 +1,10 @@ --- title: Booz Allen Case Study -linkTitle: booz-allen +linkTitle: Booz Allen Hamilton case_study_styles: true cid: caseStudies css: /css/case-studies-gradient.css -logo: booz-allen_featured_logo.png +logo: booz-allen-featured-logo.svg featured: true weight: 2 quote: > diff --git a/content/en/case-studies/denso/denso_featured_logo.svg b/content/en/case-studies/denso/denso_featured_logo.svg new file mode 100644 index 0000000000..375d9cefbc --- /dev/null +++ b/content/en/case-studies/denso/denso_featured_logo.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/content/en/case-studies/denso/index.html b/content/en/case-studies/denso/index.html new file mode 100644 index 0000000000..3ad0812d24 --- /dev/null +++ b/content/en/case-studies/denso/index.html @@ -0,0 +1,110 @@ +--- +title: Denso Case Study +linkTitle: Denso +case_study_styles: true +cid: caseStudies +css: /css/case-studies-gradient.css +logo: denso_featured_logo.svg +featured: true +weight: 4 +quote: > + We got Kubernetes experts involved on our team, and it dramatically accelerated development speed. +--- + + +
+

CASE STUDY: Denso

+
How DENSO Is Fueling Development on the Vehicle Edge with Kubernetes
+
+ +
+ Company  Denso     Location  Japan     Industry  Automotive, Edge +
+ +
+
+
+
+

Challenge

+ DENSO Corporation is one of the biggest automotive components suppliers in the world. With the advent of connected cars, the company launched a Digital Innovation Department to expand into software, working on vehicle edge and vehicle cloud products. But there were several technical challenges to creating an integrated vehicle edge/cloud platform: "the amount of computing resources, the occasional lack of mobile signal, and an enormous number of distributed vehicles," says R&D Product Manager Seiichi Koizumi. + + +

Solution

+ Koizumi’s team realized that because mobility services evolve every day, they needed the flexibility of the cloud native ecosystem for their platform. After considering other orchestrators, DENSO went with Kubernetes for orchestration and added Prometheus, Fluentd, Envoy, Istio, and Helm to the platform. Today, DENSO is using a vehicle edge computer, a private Kubernetes cloud, and managed Kubernetes (GKE, EKS, AKS). + +

Impact

+ Critical layer features can take 2-3 years to implement in the traditional, waterfall model of development at DENSO. With the Kubernetes platform and agile methods, there’s a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and a new prototype is introduced every week. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," says Koizumi. +
+
+
+
+ "Another disruptive innovation is coming, so to survive in this situation, we need to change our culture." +

- SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO

+
+
+ + +
+
+

Spun off from Toyota in 1949, DENSO Corporation is one of the top automotive suppliers in the world today, with consolidated net revenue of $48.3 billion. +

+ +

The company’s mission is "contributing to a better world by creating value together with a vision for the future"—and part of that vision in recent years has been development on the vehicle edge and vehicle cloud.

+ +

With the advent of connected cars, DENSO established a Digital Innovation Department to expand its business beyond the critical layer of the engine, braking systems, and other automotive parts into the non-critical analytics and entertainment layer. Comparing connected cars to smartphones, R&D Product Manager Seiichi Koizumi says DENSO wants the ability to quickly and easily develop and install apps for the "blank slate" of the car, and iterate them based on the driver’s preferences. Thus "we need a flexible application platform," he says.

+ +

But working on vehicle edge and vehicle cloud products meant there were several technical challenges: "the amount of computing resources, the occasional lack of mobile signal, and an enormous number of distributed vehicles," says Koizumi. "We are tackling these challenges to create an integrated vehicle edge/cloud platform."

+ + +
+
+ +
+
+ "We got Kubernetes experts involved on our team, and it dramatically accelerated development speed."

— SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO

+
+
+ +
+
+

+ Koizumi’s team realized that because mobility services evolve every day, they needed the flexibility of the cloud native ecosystem for their platform. As they evaluated technologies, they were led by these criteria: Because their service-enabler business needed to support multiple cloud and on-premise environments, the solution needed to be cloud agnostic, with no vendor lock-in and open governance. It also had to support an edge-cloud integrated environment.

+

+ After considering other orchestrators, DENSO went with Kubernetes for orchestration and added Prometheus, Fluentd, Envoy, Istio, and Helm to the platform. During implementation, the team used "design thinking to clarify use cases and their value proposition," says Koizumi. Next, an agile development team worked on a POC, then an MVP, in DevOps style. "Even in the development phase, we are keeping a channel to end users," he adds.

+

+ One lesson learned during this process was the value of bringing in experts. "We tried to learn Kubernetes and cloud native technologies from scratch, but it took more time than expected," says Koizumi. "We got Kubernetes experts involved on our team, and it dramatically accelerated development speed."

+ +

+
+
+ + +
+
+ "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation."

- SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO

+
+
+ +
+
+

+ Today, DENSO is using a vehicle edge computer, a private Kubernetes cloud, and managed Kubernetes on GKE, EKS, and AKS. "We are developing a vehicle edge/cloud integrated platform based on a microservice and service mesh architecture," says Koizumi. "We extend cloud into multiple vehicle edges and manage it as a unified platform."

+

+ Cloud native has enabled DENSO to deliver applications via its new dash cam, which has a secure connection that collects data to the cloud. "It’s like a smartphone," he says. "We are installing new applications and getting the data through the cloud, and we can keep updating new applications all through the dash cam."

+

+ The unified cloud native platform, combined with agile development, has had a positive impact on productivity. Critical layer features—those involving engines or braking systems, for example—can take 2-3 years to implement at DENSO, because of the time needed to test safety, but also because of the traditional, waterfall model of development. With the Kubernetes platform and agile methods, there’s a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and with the department’s scrum-style development, a new prototype is introduced every week.

+

+ Application portability has also led to greater developer efficiency. "There’s no need to care about differences in the multi-cloud platform anymore," says Koizumi. Now, "we are also trying to have the same portability between vehicle edge and cloud platform." +

+

+ Another improvement: Automotive Tier-1 suppliers like DENSO always have multiple Tier-2 suppliers. "To provide automotive-grade high-availability services, we tried to do the same thing on a multi-cloud platform," says Koizumi. Before Kubernetes, maintaining two different systems simultaneously was difficult. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," he says. +

+

+Cloud native has also profoundly changed the culture at DENSO. The Digital Innovation Department is known as "Noah’s Ark," and it has grown from 2 members to 70—with plans to more than double in the next year. The way they operate is completely different from the traditional Japanese automotive culture. But just as the company embraced change brought by hybrid cars in the past decade, Koizumi says, they’re doing it again now, as technology companies have moved into the connected car space. "Another disruptive innovation is coming," he says, "so to survive in this situation, we need to change our culture." +

+

+Looking ahead, Koizumi and his team are expecting serverless and zero-trust security architecture to be important enhancements of Kubernetes. They are glad DENSO has come along for the ride. "Mobility service businesses require agility and flexibility," he says. "DENSO is trying to bring cloud native flexibility into the vehicle infrastructure." +

+
+
+ diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index 6540a05e8f..f9ccdca8e9 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -131,14 +131,14 @@ classes: namespace). These are important to isolate from other traffic because failures in leader election cause their controllers to fail and restart, which in turn causes more expensive traffic as the new controllers sync their informers. - + * The `workload-high` priority level is for other requests from built-in controllers. - + * The `workload-low` priority level is for requests from any other service account, which will typically include all requests from controllers runing in Pods. - + * The `global-default` priority level handles all other traffic, e.g. interactive `kubectl` commands run by nonprivileged users. @@ -150,7 +150,7 @@ are built in and may not be overwritten: special `exempt` FlowSchema classifies all requests from the `system:masters` group into this priority level. You may define other FlowSchemas that direct other requests to this priority level, if appropriate. - + * The special `catch-all` priority level is used in combination with the special `catch-all` FlowSchema to make sure that every request gets some kind of classification. Typically you should not rely on this catch-all configuration, @@ -164,7 +164,7 @@ are built in and may not be overwritten: ## Resources The flow control API involves two kinds of resources. -[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io) +[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io) define the available isolation classes, the share of the available concurrency budget that each can handle, and allow for fine-tuning queuing behavior. [FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io) @@ -204,7 +204,7 @@ to balance progress between request flows. The queuing configuration allows tuning the fair queuing algorithm for a priority level. Details of the algorithm can be read in the [enhancement -proposal](#what-s-next), but in short: +proposal](#whats-next), but in short: * Increasing `queues` reduces the rate of collisions between different flows, at the cost of increased memory usage. A value of 1 here effectively disables the @@ -233,20 +233,21 @@ given mouse (low-intensity flow) is squished by the elephants (high-intensity fl an illustrative collection of numbers of elephants. See https://play.golang.org/p/Gi0PLgVHiUg , which computes this table. -{{< table caption="Example Shuffle Sharding Configurations" >}} -|HandSize| Queues| 1 elephant| 4 elephants| 16 elephants| -|--------|-----------|------------|----------------|--------------------| -| 12| 32| 4.428838398950118e-09| 0.11431348830099144| 0.9935089607656024| -| 10| 32| 1.550093439632541e-08| 0.0626479840223545| 0.9753101519027554| -| 10| 64| 6.601827268370426e-12| 0.00045571320990370776| 0.49999929150089345| -| 9| 64| 3.6310049976037345e-11| 0.00045501212304112273| 0.4282314876454858| -| 8| 64| 2.25929199850899e-10| 0.0004886697053040446| 0.35935114681123076| -| 8| 128| 6.994461389026097e-13| 3.4055790161620863e-06| 0.02746173137155063| -| 7| 128| 1.0579122850901972e-11| 6.960839379258192e-06| 0.02406157386340147| -| 7| 256| 7.597695465552631e-14| 6.728547142019406e-08| 0.0006709661542533682| -| 6| 256| 2.7134626662687968e-12| 2.9516464018476436e-07| 0.0008895654642000348| -| 6| 512| 4.116062922897309e-14| 4.982983350480894e-09| 2.26025764343413e-05| -| 6| 1024| 6.337324016514285e-16| 8.09060164312957e-11| 4.517408062903668e-07| +{{< table caption = "Example Shuffle Sharding Configurations" >}} +HandSize | Queues | 1 elephant | 4 elephants | 16 elephants +|----------|-----------|------------|----------------|--------------------| +| 12 | 32 | 4.428838398950118e-09 | 0.11431348830099144 | 0.9935089607656024 | +| 10 | 32 | 1.550093439632541e-08 | 0.0626479840223545 | 0.9753101519027554 | +| 10 | 64 | 6.601827268370426e-12 | 0.00045571320990370776 | 0.49999929150089345 | +| 9 | 64 | 3.6310049976037345e-11 | 0.00045501212304112273 | 0.4282314876454858 | +| 8 | 64 | 2.25929199850899e-10 | 0.0004886697053040446 | 0.35935114681123076 | +| 8 | 128 | 6.994461389026097e-13 | 3.4055790161620863e-06 | 0.02746173137155063 | +| 7 | 128 | 1.0579122850901972e-11 | 6.960839379258192e-06 | 0.02406157386340147 | +| 7 | 256 | 7.597695465552631e-14 | 6.728547142019406e-08 | 0.0006709661542533682 | +| 6 | 256 | 2.7134626662687968e-12 | 2.9516464018476436e-07 | 0.0008895654642000348 | +| 6 | 512 | 4.116062922897309e-14 | 4.982983350480894e-09 | 2.26025764343413e-05 | +| 6 | 1024 | 6.337324016514285e-16 | 8.09060164312957e-11 | 4.517408062903668e-07 | +{{< /table >}} ### FlowSchema @@ -291,7 +292,7 @@ enabled has two extra headers: `X-Kubernetes-PF-FlowSchema-UID` and `X-Kubernetes-PF-PriorityLevel-UID`, noting the flow schema that matched the request and the priority level to which it was assigned, respectively. The API objects' names are not included in these headers in case the requesting user does not -have permission to view them, so when debugging you can use a command like +have permission to view them, so when debugging you can use a command like ```shell kubectl get flowschemas -o custom-columns="uid:{metadata.uid},name:{metadata.name}" @@ -363,7 +364,7 @@ poorly-behaved workloads that may be harming system health. * `apiserver_flowcontrol_request_execution_seconds` gives a histogram of how long requests took to actually execute, grouped by the FlowSchema that matched the request and the PriorityLevel to which it was assigned. - + {{% /capture %}} @@ -374,4 +375,4 @@ the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/maste You can make suggestions and feature requests via [SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery). -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/configuration/overview.md b/content/en/docs/concepts/configuration/overview.md index 100d04ae78..d07bf762bb 100644 --- a/content/en/docs/concepts/configuration/overview.md +++ b/content/en/docs/concepts/configuration/overview.md @@ -59,8 +59,7 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN - Avoid using `hostNetwork`, for the same reasons as `hostPort`. -- Use [headless Services](/docs/concepts/services-networking/service/#headless- -services) (which have a `ClusterIP` of `None`) for easy service discovery when you don't need `kube-proxy` load balancing. +- Use [headless Services](/docs/concepts/services-networking/service/#headless-services) (which have a `ClusterIP` of `None`) for easy service discovery when you don't need `kube-proxy` load balancing. ## Using Labels diff --git a/content/en/docs/concepts/containers/overview.md b/content/en/docs/concepts/containers/overview.md index 968ba7104a..49162710d7 100644 --- a/content/en/docs/concepts/containers/overview.md +++ b/content/en/docs/concepts/containers/overview.md @@ -9,9 +9,9 @@ weight: 1 {{% capture overview %}} -Containers are a technnology for packaging the (compiled) code for an +Containers are a technology for packaging the (compiled) code for an application along with the dependencies it needs at run time. Each -container that you run is repeatable; the standardisation from having +container that you run is repeatable; the standardization from having dependencies included means that you get the same behavior wherever you run it. diff --git a/content/en/docs/concepts/extend-kubernetes/operator.md b/content/en/docs/concepts/extend-kubernetes/operator.md index f77d83a553..eb56d5475a 100644 --- a/content/en/docs/concepts/extend-kubernetes/operator.md +++ b/content/en/docs/concepts/extend-kubernetes/operator.md @@ -106,7 +106,7 @@ as well as keeping the existing service in good shape. ## Writing your own Operator {#writing-operator} If there isn't an Operator in the ecosystem that implements the behavior you -want, you can code your own. In [What's next](#what-s-next) you'll find a few +want, you can code your own. In [What's next](#whats-next) you'll find a few links to libraries and tools you can use to write your own cloud native Operator. @@ -129,4 +129,4 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie * Read [CoreOS' original article](https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern * Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md index 0d4c633391..d1123b72e1 100644 --- a/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -157,13 +157,13 @@ the three things: 1. **wait** (with a timeout) \ If a Permit plugin returns "wait", then the Pod is kept in an internal "waiting" Pods list, and the binding cycle of this Pod starts but directly blocks until it - gets [approved](#frameworkhandle). If a timeout occurs, **wait** becomes **deny** + gets approved. If a timeout occurs, **wait** becomes **deny** and the Pod is returned to the scheduling queue, triggering [Unreserve](#unreserve) plugins. {{< note >}} While any plugin can access the list of "waiting" Pods and approve them -(see [`FrameworkHandle`](#frameworkhandle)), we expect only the permit +(see [`FrameworkHandle`](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md#frameworkhandle)), we expect only the permit plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod is approved, it is sent to the [PreBind](#pre-bind) phase. {{< /note >}} @@ -239,4 +239,4 @@ If you are using Kubernetes v1.18 or later, you can configure a set of plugins a a scheduler profile and then define multiple profiles to fit various kinds of workload. Learn more at [multiple profiles](/docs/reference/scheduling/profiles/#multiple-profiles). -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md index ba77587457..b479d8c96a 100644 --- a/content/en/docs/concepts/services-networking/dns-pod-service.md +++ b/content/en/docs/concepts/services-networking/dns-pod-service.md @@ -171,7 +171,7 @@ following pod-specific DNS policies. These policies are specified in the - "`None`": It allows a Pod to ignore DNS settings from the Kubernetes environment. All DNS settings are supposed to be provided using the `dnsConfig` field in the Pod Spec. - See [Pod's DNS config](#pod-s-dns-config) subsection below. + See [Pod's DNS config](#pod-dns-config) subsection below. {{< note >}} "Default" is not the default DNS policy. If `dnsPolicy` is not @@ -201,7 +201,7 @@ spec: dnsPolicy: ClusterFirstWithHostNet ``` -### Pod's DNS Config +### Pod's DNS Config {#pod-dns-config} Pod's DNS Config allows users more control on the DNS settings for a Pod. @@ -269,6 +269,4 @@ The availability of Pod DNS Config and DNS Policy "`None`"" is shown as below. For guidance on administering DNS configurations, check [Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/) -{{% /capture %}} - - +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index 39e57ffdb0..062dc14f66 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -134,11 +134,10 @@ path types: to the list of labels in the path split by the `/` separator. A request is a match for path _p_ if every _p_ is an element-wise prefix of _p_ of the request path. - {{< note >}} - If the last element of the path is a substring of the - last element in request path, it is not a match (for example: - `/foo/bar` matches`/foo/bar/baz`, but does not match `/foo/barbaz`). - {{< /note >}} + + {{< note >}} + If the last element of the path is a substring of the last element in request path, it is not a match (for example: `/foo/bar` matches`/foo/bar/baz`, but does not match `/foo/barbaz`). + {{< /note >}} #### Multiple Matches In some cases, multiple paths within an Ingress will match a request. In those @@ -402,16 +401,16 @@ metadata: spec: tls: - hosts: - - sslexample.foo.com + - sslexample.foo.com secretName: testsecret-tls rules: - - host: sslexample.foo.com - http: - paths: - - path: / - backend: - serviceName: service1 - servicePort: 80 + - host: sslexample.foo.com + http: + paths: + - path: / + backend: + serviceName: service1 + servicePort: 80 ``` {{< note >}} diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 4b22929177..c365e02171 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -736,9 +736,9 @@ and need persistent storage, it is recommended that you use the following patter `persistentVolumeClaim.storageClassName` field. This will cause the PVC to match the right storage class if the cluster has StorageClasses enabled by the admin. - - If the user does not provide a storage class name, leave the - `persistentVolumeClaim.storageClassName` field as nil. This will cause a - PV to be automatically provisioned for the user with the default StorageClass + - If the user does not provide a storage class name, leave the + `persistentVolumeClaim.storageClassName` field as nil. This will cause a + PV to be automatically provisioned for the user with the default StorageClass in the cluster. Many cluster environments have a default StorageClass installed, or administrators can create their own default StorageClass. - In your tooling, watch for PVCs that are not getting bound after some time @@ -759,4 +759,4 @@ and need persistent storage, it is recommended that you use the following patter * [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) * [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) * [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core) -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index faa40c8dc9..7a53c9ecff 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -248,14 +248,14 @@ spec: #### CSI Migration -{{< feature-state for_k8s_version="v1.14" state="alpha" >}} +{{< feature-state for_k8s_version="v1.18" state="beta" >}} The CSI Migration feature for Cinder, when enabled, shims all plugin operations from the existing in-tree plugin to the `cinder.csi.openstack.org` Container Storage Interface (CSI) Driver. In order to use this feature, the [Openstack Cinder CSI Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md) must be installed on the cluster and the `CSIMigration` and `CSIMigrationOpenStack` -Alpha features must be enabled. +Beta features must be enabled. ### configMap {#configmap} diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index c5751059f6..2610380641 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -53,12 +53,13 @@ In this example: In this case, you simply select a label that is defined in the Pod template (`app: nginx`). However, more sophisticated selection rules are possible, as long as the Pod template itself satisfies the rule. - {{< note >}} - The `.spec.selector.matchLabels` field is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map - is equivalent to an element of `matchExpressions`, whose key field is "key" the operator is "In", - and the values array contains only "value". - All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match. - {{< /note >}} + + {{< note >}} + The `.spec.selector.matchLabels` field is a map of {key,value} pairs. + A single {key,value} in the `matchLabels` map is equivalent to an element of `matchExpressions`, + whose key field is "key" the operator is "In", and the values array contains only "value". + All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match. + {{< /note >}} * The `template` field contains the following sub-fields: * The Pods are labeled `app: nginx`using the `.metadata.labels` field. @@ -67,84 +68,92 @@ In this example: [Docker Hub](https://hub.docker.com/) image at version 1.14.2. * Create one container and name it `nginx` using the `.spec.template.spec.containers[0].name` field. - Follow the steps given below to create the above Deployment: +Before you begin, make sure your Kubernetes cluster is up and running. +Follow the steps given below to create the above Deployment: - Before you begin, make sure your Kubernetes cluster is up and running. - 1. Create the Deployment by running the following command: +1. Create the Deployment by running the following command: - {{< note >}} - You may specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. It is useful for future introspection. - For example, to see the commands executed in each Deployment revision. - {{< /note >}} - - ```shell - kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml - ``` - - 2. Run `kubectl get deployments` to check if the Deployment was created. If the Deployment is still being created, the output is similar to the following: - ```shell - NAME READY UP-TO-DATE AVAILABLE AGE - nginx-deployment 0/3 0 0 1s - ``` - When you inspect the Deployments in your cluster, the following fields are displayed: - - * `NAME` lists the names of the Deployments in the namespace. - * `READY` displays how many replicas of the application are available to your users. It follows the pattern ready/desired. - * `UP-TO-DATE` displays the number of replicas that have been updated to achieve the desired state. - * `AVAILABLE` displays how many replicas of the application are available to your users. - * `AGE` displays the amount of time that the application has been running. - - Notice how the number of desired replicas is 3 according to `.spec.replicas` field. - - 3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. The output is similar to this: - ```shell - Waiting for rollout to finish: 2 out of 3 new replicas have been updated... - deployment.apps/nginx-deployment successfully rolled out - ``` - - 4. Run the `kubectl get deployments` again a few seconds later. The output is similar to this: - ```shell - NAME READY UP-TO-DATE AVAILABLE AGE - nginx-deployment 3/3 3 3 18s - ``` - Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available. - - 5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this: - ```shell - NAME DESIRED CURRENT READY AGE - nginx-deployment-75675f5897 3 3 3 18s - ``` - ReplicaSet output shows the following fields: - - * `NAME` lists the names of the ReplicaSets in the namespace. - * `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_. - * `CURRENT` displays how many replicas are currently running. - * `READY` displays how many replicas of the application are available to your users. - * `AGE` displays the amount of time that the application has been running. - - Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. The random string is - randomly generated and uses the `pod-template-hash` as a seed. - - 6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`. The following output is returned: - ```shell - NAME READY STATUS RESTARTS AGE LABELS - nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 - nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 - nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 - ``` - The created ReplicaSet ensures that there are three `nginx` Pods. + ```shell + kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml + ``` {{< note >}} - You must specify an appropriate selector and Pod template labels in a Deployment (in this case, - `app: nginx`). Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly. + You can specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. + The recorded change is useful for future introspection. For example, to see the commands executed in each Deployment revision. {{< /note >}} + +2. Run `kubectl get deployments` to check if the Deployment was created. + + If the Deployment is still being created, the output is similar to the following: + ```shell + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 0/3 0 0 1s + ``` + When you inspect the Deployments in your cluster, the following fields are displayed: + * `NAME` lists the names of the Deployments in the namespace. + * `READY` displays how many replicas of the application are available to your users. It follows the pattern ready/desired. + * `UP-TO-DATE` displays the number of replicas that have been updated to achieve the desired state. + * `AVAILABLE` displays how many replicas of the application are available to your users. + * `AGE` displays the amount of time that the application has been running. + + Notice how the number of desired replicas is 3 according to `.spec.replicas` field. + +3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. + + The output is similar to: + ```shell + Waiting for rollout to finish: 2 out of 3 new replicas have been updated... + deployment.apps/nginx-deployment successfully rolled out + ``` + +4. Run the `kubectl get deployments` again a few seconds later. + The output is similar to this: + ```shell + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 18s + ``` + Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available. + +5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this: + ```shell + NAME DESIRED CURRENT READY AGE + nginx-deployment-75675f5897 3 3 3 18s + ``` + ReplicaSet output shows the following fields: + + * `NAME` lists the names of the ReplicaSets in the namespace. + * `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_. + * `CURRENT` displays how many replicas are currently running. + * `READY` displays how many replicas of the application are available to your users. + * `AGE` displays the amount of time that the application has been running. + + Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. + The random string is randomly generated and uses the `pod-template-hash` as a seed. + +6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`. + The output is similar to: + ```shell + NAME READY STATUS RESTARTS AGE LABELS + nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + ``` + The created ReplicaSet ensures that there are three `nginx` Pods. + +{{< note >}} +You must specify an appropriate selector and Pod template labels in a Deployment +(in this case, `app: nginx`). + +Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly. +{{< /note >}} + ### Pod-template-hash label -{{< note >}} +{{< caution >}} Do not change this label. -{{< /note >}} +{{< /caution >}} The `pod-template-hash` label is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts. @@ -409,9 +418,7 @@ rolled back. ``` {{< note >}} - The Deployment controller stops the bad rollout automatically, and stops scaling up the new - ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified. - Kubernetes by default sets the value to 25%. + The Deployment controller stops the bad rollout automatically, and stops scaling up the new ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified. Kubernetes by default sets the value to 25%. {{< /note >}} * Get the description of the Deployment: @@ -901,9 +908,9 @@ example, rollback the Deployment to its previous version. {{< /note >}} {{< note >}} -If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can -safely pause a Deployment in the middle of a rollout and resume without triggering the condition for exceeding the -deadline. +If you pause a Deployment, Kubernetes does not check progress against your specified deadline. +You can safely pause a Deployment in the middle of a rollout and resume without triggering +the condition for exceeding the deadline. {{< /note >}} You may experience transient errors with your Deployments, either due to a low timeout that you have set or diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index aa6a07788b..661955cb48 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -156,7 +156,7 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain {{< note >}} Cluster Domain will be set to `cluster.local` unless -[otherwise configured](/docs/concepts/services-networking/dns-pod-service/#how-it-works). +[otherwise configured](/docs/concepts/services-networking/dns-pod-service/). {{< /note >}} ### Stable Storage diff --git a/content/en/docs/concepts/workloads/pods/init-containers.md b/content/en/docs/concepts/workloads/pods/init-containers.md index 8565f49bb3..eaf48a95a6 100644 --- a/content/en/docs/concepts/workloads/pods/init-containers.md +++ b/content/en/docs/concepts/workloads/pods/init-containers.md @@ -241,7 +241,7 @@ myapp-pod 1/1 Running 0 9m ``` This simple example should provide some inspiration for you to create your own -init containers. [What's next](#what-s-next) contains a link to a more detailed example. +init containers. [What's next](#whats-next) contains a link to a more detailed example. ## Detailed behavior @@ -325,4 +325,4 @@ reasons: * Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container) * Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/) -{{% /capture %}} +{{% /capture %}} \ No newline at end of file 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 c514aa3eb4..6e6f878449 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 @@ -97,7 +97,7 @@ If we want an incoming Pod to be evenly spread with existing Pods across zones, {{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}} -`topologyKey: zone` implies the even distribution will only be applied to the nodes which have label pair "zone:" present. `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let it stay pending if the incoming Pod can’t satisfy the constraint. +`topologyKey: zone` implies the even distribution will only be applied to the nodes which have label pair "zone:<any value>" present. `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let it stay pending if the incoming Pod can’t satisfy the constraint. If the scheduler placed this incoming Pod into "zoneA", the Pods distribution would become [3, 1], hence the actual skew is 2 (3 - 1) - which violates `maxSkew: 1`. In this example, the incoming Pod can only be placed onto "zoneB": diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md index f2be84f10d..dccc6cfe38 100644 --- a/content/en/docs/contribute/review/for-approvers.md +++ b/content/en/docs/contribute/review/for-approvers.md @@ -73,8 +73,7 @@ true: [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. +organization, like [adding and removing labels](#adding-and-removing-issue-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: diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md index 707005d020..595ef138fc 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md @@ -29,1240 +29,1240 @@ kubelet [flags] {{% capture options %}} - - - - - - +
++++ + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - - - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + + + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--add-dir-header
If true, adds the file directory to the header
--add-dir-header
If true, adds the file directory to the header
--address 0.0.0.0
The IP address for the Kubelet to serve on (set to 0.0.0.0 for all IPv4 interfaces and `::` for all IPv6 interfaces) (default 0.0.0.0) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--address 0.0.0.0
The IP address for the Kubelet to serve on (set to 0.0.0.0 for all IPv4 interfaces and `::` for all IPv6 interfaces) (default 0.0.0.0) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--allowed-unsafe-sysctls strings
Comma-separated whitelist of unsafe sysctls or unsafe sysctl patterns (ending in *). Use these at your own risk. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--allowed-unsafe-sysctls strings
Comma-separated whitelist of unsafe sysctls or unsafe sysctl patterns (ending in *). Use these at your own risk. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--alsologtostderr
log to standard error as well as files
--alsologtostderr
log to standard error as well as files
--anonymous-auth
Enables anonymous requests to the Kubelet server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated. (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--anonymous-auth
Enables anonymous requests to the Kubelet server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated. (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--application-metrics-count-limit int
Max number of application metrics to store (per container) (default 100) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--application-metrics-count-limit int
Max number of application metrics to store (per container) (default 100) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns,it will follow the standard CLI deprecation timeline before being removed.)
--authentication-token-webhook
Use the TokenReview API to determine authentication for bearer tokens. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--authentication-token-webhook
Use the TokenReview API to determine authentication for bearer tokens. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--authentication-token-webhook-cache-ttl duration
The duration to cache responses from the webhook token authenticator. (default 2m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--authentication-token-webhook-cache-ttl duration
The duration to cache responses from the webhook token authenticator. (default 2m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's +--config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--authorization-mode string
Authorization mode for Kubelet server. Valid options are AlwaysAllow or Webhook. Webhook mode uses the SubjectAccessReview API to determine authorization. (default "AlwaysAllow" when --config flag is not provided; "Webhook" when --config flag presents.) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--authorization-mode string
Authorization mode for Kubelet server. Valid options are AlwaysAllow or Webhook. Webhook mode uses the SubjectAccessReview API to determine authorization. (default "AlwaysAllow" when --config flag is not provided; "Webhook" when --config flag presents.) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--authorization-webhook-cache-authorized-ttl duration
The duration to cache 'authorized' responses from the webhook authorizer. (default 5m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--authorization-webhook-cache-authorized-ttl duration
The duration to cache 'authorized' responses from the webhook authorizer. (default 5m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--authorization-webhook-cache-unauthorized-ttl duration
The duration to cache 'unauthorized' responses from the webhook authorizer. (default 30s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--authorization-webhook-cache-unauthorized-ttl duration
The duration to cache 'unauthorized' responses from the webhook authorizer. (default 30s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--azure-container-registry-config string
Path to the file container Azure container registry configuration information.
--azure-container-registry-config string
Path to the file container Azure container registry configuration information.
--boot-id-file string
Comma-separated list of files to check for boot-id. Use the first one that exists. (default "/proc/sys/kernel/random/boot_id") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--boot-id-file string
Comma-separated list of files to check for boot-id. Use the first one that exists. (default "/proc/sys/kernel/random/boot_id") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--bootstrap-checkpoint-path string
Path to the directory where the checkpoints are stored
--bootstrap-checkpoint-path string
<Warning: Alpha feature> Path to the directory where the checkpoints are stored
--bootstrap-kubeconfig string
Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by --kubeconfig does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated client certificate and key is written to the path specified by --kubeconfig. The client certificate and key file will be stored in the directory pointed by --cert-dir.
--bootstrap-kubeconfig string
Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by --kubeconfig does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated client certificate and key is written to the path specified by --kubeconfig. The client certificate and key file will be stored in the directory pointed by --cert-dir.
--cert-dir string
The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/lib/kubelet/pki")
--cert-dir string
The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/lib/kubelet/pki")
--cgroup-driver string
Driver that the kubelet uses to manipulate cgroups on the host. Possible values: 'cgroupfs', 'systemd' (default "cgroupfs") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)/td> -
--cgroup-driver string
Driver that the kubelet uses to manipulate cgroups on the host. Possible values: 'cgroupfs', 'systemd' (default "cgroupfs") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)/td> +
--cgroup-root string
Optional root cgroup to use for pods. This is handled by the container runtime on a best effort basis. Default: '', which means use the container runtime default. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cgroup-root string
Optional root cgroup to use for pods. This is handled by the container runtime on a best effort basis. Default: '', which means use the container runtime default. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cgroups-per-qos
Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created. (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cgroups-per-qos
Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created. (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--chaos-chance float
If > 0.0, introduce random client errors and latency. Intended for testing.
--chaos-chance float
If > 0.0, introduce random client errors and latency. Intended for testing.
--client-ca-file string
If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--client-ca-file string
If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cloud-config string
The path to the cloud provider configuration file.
--cloud-config string
The path to the cloud provider configuration file.
--cloud-provider string
The provider for cloud services. Specify empty string for running with no cloud provider. If set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used).
--cloud-provider string
The provider for cloud services. Specify empty string for running with no cloud provider. If set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used).
--cluster-dns strings
Comma-separated list of DNS server IP address. This value is used for containers DNS server in case of Pods with "dnsPolicy=ClusterFirst". Note: all DNS servers appearing in the list MUST serve the same set of records otherwise name resolution within the cluster may not work correctly. There is no guarantee as to which DNS server may be contacted for name resolution. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cluster-dns strings
Comma-separated list of DNS server IP address. This value is used for containers DNS server in case of Pods with "dnsPolicy=ClusterFirst". Note: all DNS servers appearing in the list MUST serve the same set of records otherwise name resolution within the cluster may not work correctly. There is no guarantee as to which DNS server may be contacted for name resolution. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cluster-domain string
Domain for this cluster. If set, kubelet will configure all containers to search this domain in addition to the host's search domains (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cluster-domain string
Domain for this cluster. If set, kubelet will configure all containers to search this domain in addition to the host's search domains (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cni-bin-dir string
A comma-separated list of full paths of directories in which to search for CNI plugin binaries. This docker-specific flag only works when container-runtime is set to docker. (default "/opt/cni/bin")
--cni-bin-dir string
<Warning: Alpha feature> A comma-separated list of full paths of directories in which to search for CNI plugin binaries. This docker-specific flag only works when container-runtime is set to docker. (default "/opt/cni/bin")
--cni-cache-dir string
The full path of the directory in which CNI should store cache files. This docker-specific flag only works when container-runtime is set to docker. (default "/var/lib/cni/cache")
--cni-cache-dir string
<Warning: Alpha feature> The full path of the directory in which CNI should store cache files. This docker-specific flag only works when container-runtime is set to docker. (default "/var/lib/cni/cache")
--cni-conf-dir string
The full path of the directory in which to search for CNI config files. This docker-specific flag only works when container-runtime is set to docker. (default "/etc/cni/net.d")
--cni-conf-dir string
<Warning: Alpha feature> The full path of the directory in which to search for CNI config files. This docker-specific flag only works when container-runtime is set to docker. (default "/etc/cni/net.d")
--config string
The Kubelet will load its initial configuration from this file. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Omit this flag to use the built-in default configuration values. Command-line flags override configuration from this file.
--config string
The Kubelet will load its initial configuration from this file. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Omit this flag to use the built-in default configuration values. Command-line flags override configuration from this file.
--container-hints string
location of the container hints file (default "/etc/cadvisor/container_hints.json") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--container-hints string
location of the container hints file (default "/etc/cadvisor/container_hints.json") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--container-log-max-files int32
Set the maximum number of container log files that can be present for a container. The number must be >= 2. This flag can only be used with --container-runtime=remote. (default 5) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--container-log-max-size string
Set the maximum size (e.g. 10Mi) of container log file before it is rotated. This flag can only be used with --container-runtime=remote. (default "10Mi") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--container-log-max-files int32
<Warning: Beta feature> Set the maximum number of container log files that can be present for a container. The number must be ≥ 2. This flag can only be used with --container-runtime=remote. (default 5) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--container-runtime string
The container runtime to use. Possible values: 'docker', 'remote', 'rkt(deprecated)'. (default "docker")
--container-log-max-size string
<Warning: Beta feature> Set the maximum size (e.g. 10Mi) of container log file before it is rotated. This flag can only be used with --container-runtime=remote. (default "10Mi") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--container-runtime-endpoint string
[Experimental] The endpoint of remote runtime service. Currently unix socket endpoint is supported on Linux, while npipe and tcp endpoints are supported on windows. Examples:'unix:///var/run/dockershim.sock', 'npipe:////./pipe/dockershim' (default "unix:///var/run/dockershim.sock")
--container-runtime string
The container runtime to use. Possible values: 'docker', 'remote', 'rkt(deprecated)'. (default "docker")
--containerd string
containerd endpoint (default "/run/containerd/containerd.sock") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--container-runtime-endpoint string
[Experimental] The endpoint of remote runtime service. Currently unix socket endpoint is supported on Linux, while npipe and tcp endpoints are supported on windows. Examples:'unix:///var/run/dockershim.sock', 'npipe:////./pipe/dockershim' (default "unix:///var/run/dockershim.sock")
--containerd string
containerd endpoint (default "/run/containerd/containerd.sock") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--contention-profiling
Enable lock contention profiling, if profiling is enabled (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--contention-profiling
Enable lock contention profiling, if profiling is enabled (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cpu-cfs-quota
Enable CPU CFS quota enforcement for containers that specify CPU limits (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cpu-cfs-quota
Enable CPU CFS quota enforcement for containers that specify CPU limits (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cpu-cfs-quota-period duration
Sets CPU CFS quota period value, cpu.cfs_period_us, defaults to Linux Kernel default (default 100ms) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cpu-cfs-quota-period duration
Sets CPU CFS quota period value, cpu.cfs_period_us, defaults to Linux Kernel default (default 100ms) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cpu-manager-policy string
CPU Manager policy to use. Possible values: 'none', 'static'. Default: 'none' (default "none") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cpu-manager-policy string
CPU Manager policy to use. Possible values: 'none', 'static'. Default: 'none' (default "none") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cpu-manager-reconcile-period NodeStatusUpdateFrequency
CPU Manager reconciliation period. Examples: '10s', or '1m'. If not supplied, defaults to NodeStatusUpdateFrequency (default 10s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cpu-manager-reconcile-period NodeStatusUpdateFrequency
<Warning: Alpha feature> CPU Manager reconciliation period. Examples: '10s', or '1m'. If not supplied, defaults to NodeStatusUpdateFrequency (default 10s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--docker string
docker endpoint (default "unix:///var/run/docker.sock") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker string
docker endpoint (default "unix:///var/run/docker.sock") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-endpoint string
Use this for the docker endpoint to communicate with. This docker-specific flag only works when container-runtime is set to docker. (default "unix:///var/run/docker.sock")
--docker-endpoint string
Use this for the docker endpoint to communicate with. This docker-specific flag only works when container-runtime is set to docker. (default "unix:///var/run/docker.sock")
--docker-env-metadata-whitelist string
a comma-separated list of environment variable keys that needs to be collected for docker containers (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-env-metadata-whitelist string
a comma-separated list of environment variable keys that needs to be collected for docker containers (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-only
Only report docker containers in addition to root stats (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-only
Only report docker containers in addition to root stats (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-root string
DEPRECATED: docker root is read from docker info (this is a fallback, default: /var/lib/docker) (default "/var/lib/docker")
--docker-root string
DEPRECATED: docker root is read from docker info (this is a fallback, default: /var/lib/docker) (default "/var/lib/docker")
--docker-tls
use TLS to connect to docker (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-tls
use TLS to connect to docker (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-tls-ca string
path to trusted CA (default "ca.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-tls-ca string
path to trusted CA (default "ca.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-tls-cert string
path to client certificate (default "cert.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-tls-cert string
path to client certificate (default "cert.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-tls-key string
path to private key (default "key.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-tls-key string
path to private key (default "key.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--dynamic-config-dir string
The Kubelet will use this directory for checkpointing downloaded configurations and tracking configuration health. The Kubelet will create this directory if it does not already exist. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Providing this flag enables dynamic Kubelet configuration. The DynamicKubeletConfig feature gate must be enabled to pass this flag; this gate currently defaults to true because the feature is beta.
--dynamic-config-dir string
The Kubelet will use this directory for checkpointing downloaded configurations and tracking configuration health. The Kubelet will create this directory if it does not already exist. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Providing this flag enables dynamic Kubelet configuration. The DynamicKubeletConfig feature gate must be enabled to pass this flag; this gate currently defaults to true because the feature is beta.
--enable-cadvisor-json-endpoints
Enable cAdvisor json /spec and /stats/* endpoints. (default false) (DEPRECATED: will be removed in a future version)
--enable-cadvisor-json-endpoints
Enable cAdvisor json /spec and /stats/* endpoints. (default false) (DEPRECATED: will be removed in a future version)
--enable-controller-attach-detach
Enables the Attach/Detach controller to manage attachment/detachment of volumes scheduled to this node, and disables kubelet from executing any attach/detach operations (default true)
--enable-controller-attach-detach
Enables the Attach/Detach controller to manage attachment/detachment of volumes scheduled to this node, and disables kubelet from executing any attach/detach operations (default true)
--enable-debugging-handlers
Enables server endpoints for log collection and local running of containers and commands (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--enable-debugging-handlers
Enables server endpoints for log collection and local running of containers and commands (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--enable-load-reader
Whether to enable cpu load reader (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--enable-load-reader
Whether to enable cpu load reader (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--enable-server
Enable the Kubelet's server (default true)
--enable-server
Enable the Kubelet's server (default true)
--enforce-node-allocatable stringSlice
A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptable options are 'none', 'pods', 'system-reserved', and 'kube-reserved'. If the latter two options are specified, '--system-reserved-cgroup' and '--kube-reserved-cgroup' must also be set, respectively. If 'none' is specified, no additional options should be set. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (default [pods]) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--enforce-node-allocatable stringSlice
A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptable options are 'none', 'pods', 'system-reserved', and 'kube-reserved'. If the latter two options are specified, '--system-reserved-cgroup' and '--kube-reserved-cgroup' must also be set, respectively. If 'none' is specified, no additional options should be set. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (default [pods]) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--event-burst int32
Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding event-qps. Only used if --event-qps > 0 (default 10) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--event-burst int32
Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding event-qps. Only used if --event-qps > 0 (default 10) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--event-qps int32
If > 0, limit event creations per second to this value. If 0, unlimited. (default 5) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--event-qps int32
If > 0, limit event creations per second to this value. If 0, unlimited. (default 5) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--event-storage-age-limit string
Max length of time for which to store events (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: creation, oom) or "default" and the value is a duration. Default is applied to all non-specified event types (default "default=0") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--event-storage-age-limit string
Max length of time for which to store events (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: creation, oom) or "default" and the value is a duration. Default is applied to all non-specified event types (default "default=0") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--event-storage-event-limit string
Max number of events to store (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: creation, oom) or "default" and the value is an integer. Default is applied to all non-specified event types (default "default=0") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--event-storage-event-limit string
Max number of events to store (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: creation, oom) or "default" and the value is an integer. Default is applied to all non-specified event types (default "default=0") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--eviction-hard mapStringString
A set of eviction thresholds (e.g. memory.available<1Gi) that if met would trigger a pod eviction. (default imagefs.available<15%,memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-hard mapStringString
A set of eviction thresholds (e.g. memory.available<1Gi) that if met would trigger a pod eviction. (default imagefs.available<15%,memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-max-pod-grace-period int32
Maximum allowed grace period (in seconds) to use when terminating pods in response to a soft eviction threshold being met. If negative, defer to pod specified value. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-max-pod-grace-period int32
Maximum allowed grace period (in seconds) to use when terminating pods in response to a soft eviction threshold being met. If negative, defer to pod specified value. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-minimum-reclaim mapStringString
A set of minimum reclaims (e.g. imagefs.available=2Gi) that describes the minimum amount of resource the kubelet will reclaim when performing a pod eviction if that resource is under pressure. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-minimum-reclaim mapStringString
A set of minimum reclaims (e.g. imagefs.available=2Gi) that describes the minimum amount of resource the kubelet will reclaim when performing a pod eviction if that resource is under pressure. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-pressure-transition-period duration
Duration for which the kubelet has to wait before transitioning out of an eviction pressure condition. (default 5m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-pressure-transition-period duration
Duration for which the kubelet has to wait before transitioning out of an eviction pressure condition. (default 5m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-soft mapStringString
A set of eviction thresholds (e.g. memory.available<1.5Gi) that if met over a corresponding grace period would trigger a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-soft mapStringString
A set of eviction thresholds (e.g. memory.available<1.5Gi) that if met over a corresponding grace period would trigger a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-soft-grace-period mapStringString
A set of eviction grace periods (e.g. memory.available=1m30s) that correspond to how long a soft eviction threshold must hold before triggering a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-soft-grace-period mapStringString
A set of eviction grace periods (e.g. memory.available=1m30s) that correspond to how long a soft eviction threshold must hold before triggering a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--exit-on-lock-contention
Whether kubelet should exit upon lock-file contention.
--exit-on-lock-contention
Whether kubelet should exit upon lock-file contention.
--experimental-allocatable-ignore-eviction
When set to 'true', Hard Eviction Thresholds will be ignored while calculating Node Allocatable. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. [default=false]
--experimental-allocatable-ignore-eviction
When set to 'true', Hard Eviction Thresholds will be ignored while calculating Node Allocatable. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. [default=false]
--experimental-bootstrap-kubeconfig string
(DEPRECATED: Use --bootstrap-kubeconfig)
--experimental-bootstrap-kubeconfig string
(DEPRECATED: Use --bootstrap-kubeconfig)
--experimental-check-node-capabilities-before-mount
[Experimental] if set true, the kubelet will check the underlying node for required components (binaries, etc.) before performing the mount
--experimental-check-node-capabilities-before-mount
[Experimental] if set true, the kubelet will check the underlying node for required components (binaries, etc.) before performing the mount
--experimental-kernel-memcg-notification
If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling.
--experimental-kernel-memcg-notification
If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling.
--experimental-mounter-path string
[Experimental] Path of mounter binary. Leave empty to use the default mount.
--experimental-mounter-path string
[Experimental] Path of mounter binary. Leave empty to use the default mount.
--fail-swap-on
Makes the Kubelet fail to start if swap is enabled on the node. (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--fail-swap-on
Makes the Kubelet fail to start if swap is enabled on the node. (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--feature-gates mapStringBool
A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
APIListChunking=true|false (BETA - default=true)
APIResponseCompression=true|false (BETA - default=true)
AllAlpha=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
AttachVolumeLimit=true|false (BETA - default=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)
BlockVolume=true|false (BETA - default=true)
BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)
CPUManager=true|false (BETA - default=true)
CRIContainerLogRotation=true|false (BETA - default=true) -
CSIBlockVolume=true|false (BETA - default=true)
CSIDriverRegistry=true|false (BETA - default=true)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (ALPHA - default=false)
CSIMigrationAWS=true|false (ALPHA - default=false)
CSIMigrationAzureDisk=true|false (ALPHA - default=false)
CSIMigrationAzureFile=true|false (ALPHA - default=false)
CSIMigrationGCE=true|false (ALPHA - default=false)
CSIMigrationOpenStack=true|false (ALPHA - default=false)
CSINodeInfo=true|false (BETA - default=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
CustomResourceDefaulting=true|false (BETA - default=true)
DevicePlugins=true|false (BETA - default=true)
DryRun=true|false (BETA - default=true)
DynamicAuditing=true|false (ALPHA - default=false)
DynamicKubeletConfig=true|false (BETA - default=true)
EndpointSlice=true|false (ALPHA - default=false)
EphemeralContainers=true|false (ALPHA - default=false)
EvenPodsSpread=true|false (ALPHA - default=false)
ExpandCSIVolumes=true|false (BETA - default=true)
ExpandInUsePersistentVolumes=true|false (BETA - default=true)
ExpandPersistentVolumes=true|false (BETA - default=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
HyperVContainer=true|false (ALPHA - default=false)
IPv6DualStack=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
LegacyNodeRoleBehavior=true|false (ALPHA - default=true)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
MountContainers=true|false (ALPHA - default=false)
NodeDisruptionExclusion=true|false (ALPHA - default=false)
NodeLease=true|false (BETA - default=true)
NonPreemptingPriority=true|false (ALPHA - default=false)
PodOverhead=true|false (ALPHA - default=false)
PodShareProcessNamespace=true|false (BETA - default=true)
ProcMountType=true|false (ALPHA - default=false)br/>QOSReserved=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RemoveSelfLink=true|false (ALPHA - default=false)
RequestManagement=true|false (ALPHA - default=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)
ResourceQuotaScopeSelectors=true|false (BETA - default=true)
RotateKubeletClientCertificate=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
RunAsGroup=true|false (BETA - default=true)
RuntimeClass=true|false (BETA - default=true)
SCTPSupport=true|false (ALPHA - default=false)
ScheduleDaemonSetPods=true|false (BETA - default=true)
ServerSideApply=true|false (BETA - default=true)
ServiceLoadBalancerFinalizer=true|false (BETA - default=true)
ServiceNodeExclusion=true|false (ALPHA - default=false)
StartupProbe=true|false (BETA - default=true)
StorageVersionHash=true|false (BETA - default=true)
StreamingProxyRedirects=true|false (BETA - default=true)
SupportNodePidsLimit=true|false (BETA - default=true)
SupportPodPidsLimit=true|false (BETA - default=true)
Sysctls=true|false (BETA - default=true)
TTLAfterFinished=true|false (ALPHA - default=false)
TaintBasedEvictions=true|false (BETA - default=true)
TaintNodesByCondition=true|false (BETA - default=true)
TokenRequest=true|false (BETA - default=true)
TokenRequestProjection=true|false (BETA - default=true)
TopologyManager=true|false (ALPHA - default=false)
ValidateProxyRedirects=true|false (BETA - default=true)
VolumePVCDataSource=true|false (BETA - default=true)
VolumeSnapshotDataSource=true|false (ALPHA - default=false)
VolumeSubpathEnvExpansion=true|false (BETA - default=true)
WatchBookmark=true|false (BETA - default=true)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (ALPHA - default=false)
WindowsGMSA=true|false (BETA - default=true)
WindowsRunAsUserName=true|false (ALPHA - default=false) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--feature-gates mapStringBool
A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
APIListChunking=true|false (BETA - default=true)
APIResponseCompression=true|false (BETA - default=true)
AllAlpha=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
AttachVolumeLimit=true|false (BETA - default=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)
BlockVolume=true|false (BETA - default=true)
BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)
CPUManager=true|false (BETA - default=true)
CRIContainerLogRotation=true|false (BETA - default=true) +
CSIBlockVolume=true|false (BETA - default=true)
CSIDriverRegistry=true|false (BETA - default=true)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (ALPHA - default=false)
CSIMigrationAWS=true|false (ALPHA - default=false)
CSIMigrationAzureDisk=true|false (ALPHA - default=false)
CSIMigrationAzureFile=true|false (ALPHA - default=false)
CSIMigrationGCE=true|false (ALPHA - default=false)
CSIMigrationOpenStack=true|false (ALPHA - default=false)
CSINodeInfo=true|false (BETA - default=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
CustomResourceDefaulting=true|false (BETA - default=true)
DevicePlugins=true|false (BETA - default=true)
DryRun=true|false (BETA - default=true)
DynamicAuditing=true|false (ALPHA - default=false)
DynamicKubeletConfig=true|false (BETA - default=true)
EndpointSlice=true|false (ALPHA - default=false)
EphemeralContainers=true|false (ALPHA - default=false)
EvenPodsSpread=true|false (ALPHA - default=false)
ExpandCSIVolumes=true|false (BETA - default=true)
ExpandInUsePersistentVolumes=true|false (BETA - default=true)
ExpandPersistentVolumes=true|false (BETA - default=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
HyperVContainer=true|false (ALPHA - default=false)
IPv6DualStack=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
LegacyNodeRoleBehavior=true|false (ALPHA - default=true)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
MountContainers=true|false (ALPHA - default=false)
NodeDisruptionExclusion=true|false (ALPHA - default=false)
NodeLease=true|false (BETA - default=true)
NonPreemptingPriority=true|false (ALPHA - default=false)
PodOverhead=true|false (ALPHA - default=false)
PodShareProcessNamespace=true|false (BETA - default=true)
ProcMountType=true|false (ALPHA - default=false)br/>QOSReserved=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RemoveSelfLink=true|false (ALPHA - default=false)
RequestManagement=true|false (ALPHA - default=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)
ResourceQuotaScopeSelectors=true|false (BETA - default=true)
RotateKubeletClientCertificate=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
RunAsGroup=true|false (BETA - default=true)
RuntimeClass=true|false (BETA - default=true)
SCTPSupport=true|false (ALPHA - default=false)
ScheduleDaemonSetPods=true|false (BETA - default=true)
ServerSideApply=true|false (BETA - default=true)
ServiceLoadBalancerFinalizer=true|false (BETA - default=true)
ServiceNodeExclusion=true|false (ALPHA - default=false)
StartupProbe=true|false (BETA - default=true)
StorageVersionHash=true|false (BETA - default=true)
StreamingProxyRedirects=true|false (BETA - default=true)
SupportNodePidsLimit=true|false (BETA - default=true)
SupportPodPidsLimit=true|false (BETA - default=true)
Sysctls=true|false (BETA - default=true)
TTLAfterFinished=true|false (ALPHA - default=false)
TaintBasedEvictions=true|false (BETA - default=true)
TaintNodesByCondition=true|false (BETA - default=true)
TokenRequest=true|false (BETA - default=true)
TokenRequestProjection=true|false (BETA - default=true)
TopologyManager=true|false (ALPHA - default=false)
ValidateProxyRedirects=true|false (BETA - default=true)
VolumePVCDataSource=true|false (BETA - default=true)
VolumeSnapshotDataSource=true|false (ALPHA - default=false)
VolumeSubpathEnvExpansion=true|false (BETA - default=true)
WatchBookmark=true|false (BETA - default=true)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (ALPHA - default=false)
WindowsGMSA=true|false (BETA - default=true)
WindowsRunAsUserName=true|false (ALPHA - default=false) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--file-check-frequency duration
Duration between checking config files for new data (default 20s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--file-check-frequency duration
Duration between checking config files for new data (default 20s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--global-housekeeping-interval duration
Interval between global housekeepings (default 1m0s) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--global-housekeeping-interval duration
Interval between global housekeepings (default 1m0s) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--hairpin-mode string
How should the kubelet setup hairpin NAT. This allows endpoints of a Service to loadbalance back to themselves if they should try to access their own Service. Valid values are "promiscuous-bridge", "hairpin-veth" and "none". (default "promiscuous-bridge") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--hairpin-mode string
How should the kubelet setup hairpin NAT. This allows endpoints of a Service to loadbalance back to themselves if they should try to access their own Service. Valid values are "promiscuous-bridge", "hairpin-veth" and "none". (default "promiscuous-bridge") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--healthz-bind-address 0.0.0.0
The IP address for the healthz server to serve on (set to 0.0.0.0 for all IPv4 interfaces and `::` for all IPv6 interfaces) (default 127.0.0.1) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--healthz-bind-address 0.0.0.0
The IP address for the healthz server to serve on (set to 0.0.0.0 for all IPv4 interfaces and `::` for all IPv6 interfaces) (default 127.0.0.1) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--healthz-port int32
The port of the localhost healthz endpoint (set to 0 to disable) (default 10248) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--healthz-port int32
The port of the localhost healthz endpoint (set to 0 to disable) (default 10248) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
-h, --help
help for kubelet
-h, --help
help for kubelet
--hostname-override string
If non-empty, will use this string as identification instead of the actual hostname. If --cloud-provider is set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used).
--hostname-override string
If non-empty, will use this string as identification instead of the actual hostname. If --cloud-provider is set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used).
--housekeeping-interval duration
Interval between container housekeepings (default 10s)
--housekeeping-interval duration
Interval between container housekeepings (default 10s)
--http-check-frequency duration
Duration between checking http for new data (default 20s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--http-check-frequency duration
Duration between checking http for new data (default 20s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--image-gc-high-threshold int32
The percent of disk usage after which image garbage collection is always run. Values must be within the range [0, 100], To disable image garbage collection, set to 100. (default 85) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--image-gc-high-threshold int32
The percent of disk usage after which image garbage collection is always run. Values must be within the range [0, 100], To disable image garbage collection, set to 100. (default 85) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--image-gc-low-threshold int32
The percent of disk usage before which image garbage collection is never run. Lowest disk usage to garbage collect to. Values must be within the range [0, 100] and should not be larger than that of --image-gc-high-threshold. (default 80) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--image-gc-low-threshold int32
The percent of disk usage before which image garbage collection is never run. Lowest disk usage to garbage collect to. Values must be within the range [0, 100] and should not be larger than that of --image-gc-high-threshold. (default 80) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--image-pull-progress-deadline duration
If no pulling progress is made before this deadline, the image pulling will be cancelled. This docker-specific flag only works when container-runtime is set to docker. (default 1m0s)
--image-pull-progress-deadline duration
If no pulling progress is made before this deadline, the image pulling will be cancelled. This docker-specific flag only works when container-runtime is set to docker. (default 1m0s)
--image-service-endpoint string
[Experimental] The endpoint of remote image service. If not specified, it will be the same with container-runtime-endpoint by default. Currently unix socket endpoint is supported on Linux, while npipe and tcp endpoints are supported on windows. Examples:'unix:///var/run/dockershim.sock', 'npipe:////./pipe/dockershim'
--image-service-endpoint string
[Experimental] The endpoint of remote image service. If not specified, it will be the same with container-runtime-endpoint by default. Currently unix socket endpoint is supported on Linux, while npipe and tcp endpoints are supported on windows. Examples:'unix:///var/run/dockershim.sock', 'npipe:////./pipe/dockershim'
--iptables-drop-bit int32
The bit of the fwmark space to mark packets for dropping. Must be within the range [0, 31]. (default 15) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--iptables-drop-bit int32
The bit of the fwmark space to mark packets for dropping. Must be within the range [0, 31]. (default 15) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--iptables-masquerade-bit int32
The bit of the fwmark space to mark packets for SNAT. Must be within the range [0, 31]. Please match this parameter with corresponding parameter in kube-proxy. (default 14) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--iptables-masquerade-bit int32
The bit of the fwmark space to mark packets for SNAT. Must be within the range [0, 31]. Please match this parameter with corresponding parameter in kube-proxy. (default 14) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--keep-terminated-pod-volumes
Keep terminated pod volumes mounted to the node after the pod terminates. Can be useful for debugging volume related issues. (DEPRECATED: will be removed in a future version)
--keep-terminated-pod-volumes
Keep terminated pod volumes mounted to the node after the pod terminates. Can be useful for debugging volume related issues. (DEPRECATED: will be removed in a future version)
--kube-api-burst int32
Burst to use while talking with kubernetes apiserver (default 10) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kube-api-burst int32
Burst to use while talking with kubernetes apiserver (default 10) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kube-api-content-type string
Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kube-api-content-type string
Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kube-api-qps int32
QPS to use while talking with kubernetes apiserver (default 5) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kube-api-qps int32
QPS to use while talking with kubernetes apiserver (default 5) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kube-reserved mapStringString
A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi) pairs that describe resources reserved for kubernetes system components. Currently cpu, memory and local ephemeral storage for root file system are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. [default=none] (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kube-reserved mapStringString
A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi) pairs that describe resources reserved for kubernetes system components. Currently cpu, memory and local ephemeral storage for root file system are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. [default=none] (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kube-reserved-cgroup string
Absolute name of the top level cgroup that is used to manage kubernetes components for which compute resources were reserved via '--kube-reserved' flag. Ex. '/kube-reserved'. [default=''] (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kube-reserved-cgroup string
Absolute name of the top level cgroup that is used to manage kubernetes components for which compute resources were reserved via '--kube-reserved' flag. Ex. '/kube-reserved'. [default=''] (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kubeconfig string
Path to a kubeconfig file, specifying how to connect to the API server. Providing --kubeconfig enables API server mode, omitting --kubeconfig enables standalone mode.
--kubeconfig string
Path to a kubeconfig file, specifying how to connect to the API server. Providing --kubeconfig enables API server mode, omitting --kubeconfig enables standalone mode.
--kubelet-cgroups string
Optional absolute name of cgroups to create and run the Kubelet in. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kubelet-cgroups string
Optional absolute name of cgroups to create and run the Kubelet in. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--lock-file string
The path to file for kubelet to use as a lock file.
--lock-file string
<Warning: Alpha feature> The path to file for kubelet to use as a lock file.
--log-backtrace-at traceLocation
when logging hits line file:N, emit a stack trace (default :0)
--log-backtrace-at traceLocation
when logging hits line file:N, emit a stack trace (default :0)
--log-cadvisor-usage
Whether to log the usage of the cAdvisor container (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--log-cadvisor-usage
Whether to log the usage of the cAdvisor container (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--log-dir string
If non-empty, write log files in this directory
--log-dir string
If non-empty, write log files in this directory
--log-file string
If non-empty, use this log file
--log-file-max-size uint
Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
--log-flush-frequency duration
Maximum number of seconds between log flushes (default 5s)
--logtostderr
log to standard error instead of files (default true)
--machine-id-file string
Comma-separated list of files to check for machine-id. Use the first one that exists. (default "/etc/machine-id,/var/lib/dbus/machine-id") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--make-iptables-util-chains
If true, kubelet will ensure iptables utility rules are present on host. (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--manifest-url string
URL for accessing additional Pod specifications to run (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--manifest-url-header --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful'
Comma-separated list of HTTP headers to use when accessing the url provided to --manifest-url. Multiple headers with the same name will be added in the same order provided. This flag can be repeatedly invoked. For example: --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful' (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--master-service-namespace string
The namespace from which the kubernetes master services should be injected into pods (default "default") (DEPRECATED: This flag will be removed in a future version.)
--log-file string
If non-empty, use this log file
--log-file-max-size uint
Defines the maximum - size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
--log-flush-frequency duration
Maximum number of seconds between log flushes (default 5s)
--logtostderr
log to standard error instead of files (default true)
--machine-id-file string
Comma-separated list of files to check for machine-id. Use the first one that exists. (default "/etc/machine-id,/var/lib/dbus/machine-id") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--make-iptables-util-chains
If true, kubelet will ensure iptables utility rules are present on host. (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--manifest-url string
URL for accessing additional Pod specifications to run (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--manifest-url-header --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful'
Comma-separated list of HTTP headers to use when accessing the url provided to --manifest-url. Multiple headers with the same name will be added in the same order provided. This flag can be repeatedly invoked. For example: --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful' (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--master-service-namespace string
The namespace from which the kubernetes master services should be injected into pods (default "default") (DEPRECATED: This flag will be removed in a future version.)
--max-open-files int
Number of files that can be opened by Kubelet process. (default 1000000) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--max-pods int32
Number of Pods that can run on this Kubelet. (default 110) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--maximum-dead-containers int32
Maximum number of old instances of containers to retain globally. Each container takes up some disk space. To disable, set to a negative number. (default -1) (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)
--maximum-dead-containers-per-container int32
Maximum number of old instances to retain per container. Each container takes up some disk space. (default 1) (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)
--minimum-container-ttl-duration duration
Minimum age for a finished container before it is garbage collected. Examples: '300ms', '10s' or '2h45m' (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)
--minimum-image-ttl-duration duration
Minimum age for an unused image before it is garbage collected. Examples: '300ms', '10s' or '2h45m'. (default 2m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--network-plugin string
The name of the network plugin to be invoked for various events in kubelet/pod lifecycle. This docker-specific flag only works when container-runtime is set to docker.
--network-plugin-mtu int32
The MTU to be passed to the network plugin, to override the default. Set to 0 to use the default 1460 MTU. This docker-specific flag only works when container-runtime is set to docker.
--node-ip string
IP address of the node. If set, kubelet will use this IP address for the node
--node-labels mapStringString
Labels to add when registering the node in the cluster. Labels must be key=value pairs separated by ','. Labels in the 'kubernetes.io' namespace must begin with an allowed prefix (kubelet.kubernetes.io, node.kubernetes.io) or be in the specifically allowed set (beta.kubernetes.io/arch, beta.kubernetes.io/instance-type, beta.kubernetes.io/os, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, failure-domain.kubernetes.io/region, failure-domain.kubernetes.io/zone, kubernetes.io/arch, kubernetes.io/hostname, kubernetes.io/instance-type, kubernetes.io/os)
--node-status-max-images int32
The maximum number of images to report in Node.Status.Images. If -1 is specified, no cap will be applied. (default 50)
--node-status-update-frequency duration
Specifies how often kubelet posts node status to master. Note: be cautious when changing the constant, it must work with nodeMonitorGracePeriod in nodecontroller. (default 10s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--non-masquerade-cidr string
Traffic to IPs outside this range will use IP masquerade. Set to '0.0.0.0/0' to never masquerade. (default "10.0.0.0/8") (DEPRECATED: will be removed in a future version)
--oom-score-adj int32
The oom-score-adj value for kubelet process. Values must be within the range [-1000, 1000] (default -999) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--pod-cidr string
The CIDR to use for pod IP addresses, only used in standalone mode. In cluster mode, this is obtained from the master. For IPv6, the maximum number of IP's allocated is 65536 (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--pod-infra-container-image string
The image whose network/ipc namespaces containers in each pod will use. This docker-specific flag only works when container-runtime is set to docker. (default "k8s.gcr.io/pause:3.2")
--pod-manifest-path string
Path to the directory containing static pod files to run, or the path to a single static pod file. Files starting with dots will be ignored. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--pod-max-pids int
Set the maximum number of processes per pod. If -1, the kubelet defaults to the node allocatable pid capacity. (default -1) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--pods-per-core int32
Number of Pods per core that can run on this Kubelet. The total number of Pods on this Kubelet cannot exceed max-pods, so max-pods will be used if this calculation results in a larger number of Pods allowed on the Kubelet. A value of 0 disables this limit. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--port int32
The port for the Kubelet to serve on. (default 10250) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--protect-kernel-defaults
Default kubelet behaviour for kernel tuning. If set, kubelet errors if any of kernel tunables is different than kubelet defaults. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--provider-id string
Unique identifier for identifying the node in a machine database, i.e cloudprovider
--qos-reserved mapStringString
A set of ResourceName=Percentage (e.g. memory=50%) pairs that describe how pod resource requests are reserved at the QoS level. Currently only memory is supported. Requires the QOSReserved feature gate to be enabled. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--read-only-port int32
The read-only port for the Kubelet to serve on with no authentication/authorization (set to 0 to disable) (default 10255) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--really-crash-for-testing
If true, when panics occur crash. Intended for testing.
--redirect-container-streaming
Enables container streaming redirect. If false, kubelet will proxy container streaming data between apiserver and container runtime; if true, kubelet will return an http redirect to apiserver, and apiserver will access container runtime directly. The proxy approach is more secure, but introduces some overhead. The redirect approach is more performant, but less secure because the connection between apiserver and container runtime may not be authenticated.
--register-node
Register the node with the apiserver. If --kubeconfig is not provided, this flag is irrelevant, as the Kubelet won't have an apiserver to register with. Default=true. (default true)
--register-schedulable
Register the node as schedulable. Won't have any effect if register-node is false. (default true) (DEPRECATED: will be removed in a future version)
--register-with-taints []api.Taint
Register the node with the given list of taints (comma separated "=:"). No-op if register-node is false.
--registry-burst int32
Maximum size of a bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding registry-qps. Only used if --registry-qps > 0 (default 10) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--registry-qps int32
If > 0, limit registry pull QPS to this value. If 0, unlimited. (default 5) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--resolv-conf string
Resolver configuration file used as the basis for the container DNS resolution configuration. (default "/etc/resolv.conf") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--root-dir string
Directory path for managing kubelet files (volume mounts,etc). (default "/var/lib/kubelet")
--rotate-certificates
Auto rotate the kubelet client certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--rotate-server-certificates
Auto-request and rotate the kubelet serving certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. Requires the RotateKubeletServerCertificate feature gate to be enabled, and approval of the submitted CertificateSigningRequest objects. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--runonce
If true, exit after spawning pods from local manifests or remote urls. Exclusive with --enable-server
--runtime-cgroups string
Optional absolute name of cgroups to create and run the runtime in.
--runtime-request-timeout duration
Timeout of all runtime requests except long running request - pull, logs, exec and attach. When timeout exceeded, kubelet will cancel the request, throw out an error and retry later. (default 2m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--seccomp-profile-root string
Directory path for seccomp profiles. (default "/var/lib/kubelet/seccomp")
--serialize-image-pulls
Pull images one at a time. We recommend *not* changing the default value on nodes that run docker daemon with version < 1.9 or an Aufs storage backend. Issue #10959 has more details. (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--skip-headers
If true, avoid header prefixes in the log messages
--skip-log-headers
If true, avoid headers when opening log files
--stderrthreshold severity
logs at or above this threshold go to stderr (default 2)
--storage-driver-buffer-duration duration
Writes in the storage driver will be buffered for this duration, and committed to the non memory backends as a single transaction (default 1m0s) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-db string
database name (default "cadvisor") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-host string
database host:port (default "localhost:8086") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-password string
database password (default "root") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-secure
use secure connection with database (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-table string
table name (default "stats") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-user string
database username (default "root") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--streaming-connection-idle-timeout duration
Maximum time a streaming connection can be idle before the connection is automatically closed. 0 indicates no timeout. Example: '5m' (default 4h0m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--sync-frequency duration
Max period between synchronizing running containers and config (default 1m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--system-cgroups /
Optional absolute name of cgroups in which to place all non-kernel processes that are not already inside a cgroup under /. Empty for no container. Rolling back the flag requires a reboot. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--system-reserved mapStringString
A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi) pairs that describe resources reserved for non-kubernetes components. Currently only cpu and memory are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. [default=none] (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--system-reserved-cgroup string
Absolute name of the top level cgroup that is used to manage non-kubernetes components for which compute resources were reserved via '--system-reserved' flag. Ex. '/system-reserved'. [default=''] (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--tls-cert-file string
File containing x509 Certificate used for serving HTTPS (with intermediate certs, if any, concatenated after server cert). If --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to --cert-dir. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--tls-cipher-suites stringSlice
Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used. Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--tls-min-version string
Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--tls-private-key-file string
File containing x509 private key matching --tls-cert-file. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--topology-manager-policy string
Topology Manager policy to use. Possible values: 'none', 'best-effort', 'restricted', 'single-numa-node'. (default "none") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
-v, --v Level
number for the log level verbosity
--version version[=true]
Print version information and quit
--vmodule moduleSpec
comma-separated list of pattern=N settings for file-filtered logging
--volume-plugin-dir string
The full path of the directory in which to search for additional third party volume plugins (default "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/")
--volume-stats-agg-period duration
Specifies interval for kubelet to calculate and cache the volume disk usage for all pods and volumes. To disable volume calculations, set to 0. (default 1m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--max-open-files int
Number of files that can be opened by Kubelet process. (default 1000000) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--max-pods int32
Number of Pods that can run on this Kubelet. (default 110) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--maximum-dead-containers int32
Maximum number of old instances of containers to retain globally. Each container takes up some disk space. To disable, set to a negative number. (default -1) (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)
--maximum-dead-containers-per-container int32
Maximum number of old instances to retain per container. Each container takes up some disk space. (default 1) (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)
--minimum-container-ttl-duration duration
Minimum age for a finished container before it is garbage collected. Examples: '300ms', '10s' or '2h45m' (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)
--minimum-image-ttl-duration duration
Minimum age for an unused image before it is garbage collected. Examples: '300ms', '10s' or '2h45m'. (default 2m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--network-plugin string
<Warning: Alpha feature> The name of the network plugin to be invoked for various events in kubelet/pod lifecycle. This docker-specific flag only works when container-runtime is set to docker.
--network-plugin-mtu int32
<Warning: Alpha feature> The MTU to be passed to the network plugin, to override the default. Set to 0 to use the default 1460 MTU. This docker-specific flag only works when container-runtime is set to docker.
--node-ip string
IP address of the node. If set, kubelet will use this IP address for the node
--node-labels mapStringString
<Warning: Alpha feature> Labels to add when registering the node in the cluster. Labels must be key=value pairs separated by ','. Labels in the 'kubernetes.io' namespace must begin with an allowed prefix (kubelet.kubernetes.io, node.kubernetes.io) or be in the specifically allowed set (beta.kubernetes.io/arch, beta.kubernetes.io/instance-type, beta.kubernetes.io/os, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, failure-domain.kubernetes.io/region, failure-domain.kubernetes.io/zone, kubernetes.io/arch, kubernetes.io/hostname, kubernetes.io/instance-type, kubernetes.io/os)
--node-status-max-images int32
<Warning: Alpha feature> The maximum number of images to report in Node.Status.Images. If -1 is specified, no cap will be applied. (default 50)
--node-status-update-frequency duration
Specifies how often kubelet posts node status to master. Note: be cautious when changing the constant, it must work with nodeMonitorGracePeriod in nodecontroller. (default 10s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--non-masquerade-cidr string
Traffic to IPs outside this range will use IP masquerade. Set to '0.0.0.0/0' to never masquerade. (default "10.0.0.0/8") (DEPRECATED: will be removed in a future version)
--oom-score-adj int32
The oom-score-adj value for kubelet process. Values must be within the range [-1000, 1000] (default -999) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--pod-cidr string
The CIDR to use for pod IP addresses, only used in standalone mode. In cluster mode, this is obtained from the master. For IPv6, the maximum number of IP's allocated is 65536 (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--pod-infra-container-image string
The image whose network/ipc namespaces containers in each pod will use. This docker-specific flag only works when container-runtime is set to docker. (default "k8s.gcr.io/pause:3.2")
--pod-manifest-path string
Path to the directory containing static pod files to run, or the path to a single static pod file. Files starting with dots will be ignored. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--pod-max-pids int
Set the maximum number of processes per pod. If -1, the kubelet defaults to the node allocatable pid capacity. (default -1) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--pods-per-core int32
Number of Pods per core that can run on this Kubelet. The total number of Pods on this Kubelet cannot exceed max-pods, so max-pods will be used if this calculation results in a larger number of Pods allowed on the Kubelet. A value of 0 disables this limit. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--port int32
The port for the Kubelet to serve on. (default 10250) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--protect-kernel-defaults
Default kubelet behaviour for kernel tuning. If set, kubelet errors if any of kernel tunables is different than kubelet defaults. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--provider-id string
Unique identifier for identifying the node in a machine database, i.e cloudprovider
--qos-reserved mapStringString
<Warning: Alpha feature> A set of ResourceName=Percentage (e.g. memory=50%) pairs that describe how pod resource requests are reserved at the QoS level. Currently only memory is supported. Requires the QOSReserved feature gate to be enabled. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--read-only-port int32
The read-only port for the Kubelet to serve on with no authentication/authorization (set to 0 to disable) (default 10255) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--really-crash-for-testing
If true, when panics occur crash. Intended for testing.
--redirect-container-streaming
Enables container streaming redirect. If false, kubelet will proxy container streaming data between apiserver and container runtime; if true, kubelet will return an http redirect to apiserver, and apiserver will access container runtime directly. The proxy approach is more secure, but introduces some overhead. The redirect approach is more performant, but less secure because the connection between apiserver and container runtime may not be authenticated.
--register-node
Register the node with the apiserver. If --kubeconfig is not provided, this flag is irrelevant, as the Kubelet won't have an apiserver to register with. Default=true. (default true)
--register-schedulable
Register the node as schedulable. Won't have any effect if register-node is false. (default true) (DEPRECATED: will be removed in a future version)
--register-with-taints []api.Taint
Register the node with the given list of taints (comma separated "=:"). No-op if register-node is false.
--registry-burst int32
Maximum size of a bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding registry-qps. Only used if --registry-qps > 0 (default 10) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--registry-qps int32
If > 0, limit registry pull QPS to this value. If 0, unlimited. (default 5) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--resolv-conf string
Resolver configuration file used as the basis for the container DNS resolution configuration. (default "/etc/resolv.conf") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--root-dir string
Directory path for managing kubelet files (volume mounts,etc). (default "/var/lib/kubelet")
--rotate-certificates
<Warning: Beta feature> Auto rotate the kubelet client certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--rotate-server-certificates
Auto-request and rotate the kubelet serving certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. Requires the RotateKubeletServerCertificate feature gate to be enabled, and approval of the submitted CertificateSigningRequest objects. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--runonce
If true, exit after spawning pods from local manifests or remote urls. Exclusive with --enable-server
--runtime-cgroups string
Optional absolute name of cgroups to create and run the runtime in.
--runtime-request-timeout duration
Timeout of all runtime requests except long running request - pull, logs, exec and attach. When timeout exceeded, kubelet will cancel the request, throw out an error and retry later. (default 2m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--seccomp-profile-root string
<Warning: Alpha feature> Directory path for seccomp profiles. (default "/var/lib/kubelet/seccomp")
--serialize-image-pulls
Pull images one at a time. We recommend *not* changing the default value on nodes that run docker daemon with version < 1.9 or an Aufs storage backend. Issue #10959 has more details. (default true) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--skip-headers
If true, avoid header prefixes in the log messages
--skip-log-headers
If true, avoid headers when opening log files
--stderrthreshold severity
logs at or above this threshold go to stderr (default 2)
--storage-driver-buffer-duration duration
Writes in the storage driver will be buffered for this duration, and committed to the non memory backends as a single transaction (default 1m0s) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-db string
database name (default "cadvisor") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-host string
database host:port (default "localhost:8086") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-password string
database password (default "root") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-secure
use secure connection with database (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-table string
table name (default "stats") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-user string
database username (default "root") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--streaming-connection-idle-timeout duration
Maximum time a streaming connection can be idle before the connection is automatically closed. 0 indicates no timeout. Example: '5m' (default 4h0m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--sync-frequency duration
Max period between synchronizing running containers and config (default 1m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--system-cgroups /
Optional absolute name of cgroups in which to place all non-kernel processes that are not already inside a cgroup under /. Empty for no container. Rolling back the flag requires a reboot. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--system-reserved mapStringString
A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi) pairs that describe resources reserved for non-kubernetes components. Currently only cpu and memory are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. [default=none] (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--system-reserved-cgroup string
Absolute name of the top level cgroup that is used to manage non-kubernetes components for which compute resources were reserved via '--system-reserved' flag. Ex. '/system-reserved'. [default=''] (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--tls-cert-file string
File containing x509 Certificate used for serving HTTPS (with intermediate certs, if any, concatenated after server cert). If --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to --cert-dir. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--tls-cipher-suites stringSlice
Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used. Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--tls-min-version string
Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--tls-private-key-file string
File containing x509 private key matching --tls-cert-file. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--topology-manager-policy string
Topology Manager policy to use. Possible values: 'none', 'best-effort', 'restricted', 'single-numa-node'. (default "none") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
-v, --v Level
number for the log level verbosity
--version version[=true]
Print version information and quit
--vmodule moduleSpec
comma-separated list of pattern=N settings for file-filtered logging
--volume-plugin-dir string
<Warning: Alpha feature> The full path of the directory in which to search for additional third party volume plugins (default "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/")
--volume-stats-agg-period duration
Specifies interval for kubelet to calculate and cache the volume disk usage for all pods and volumes. To disable volume calculations, set to 0. (default 1m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
{{% /capture %}} diff --git a/content/en/docs/reference/kubectl/overview.md b/content/en/docs/reference/kubectl/overview.md index de5c98c887..fa8633fb5f 100644 --- a/content/en/docs/reference/kubectl/overview.md +++ b/content/en/docs/reference/kubectl/overview.md @@ -69,31 +69,49 @@ The following table includes short descriptions and the general syntax for all o Operation | Syntax | Description -------------------- | -------------------- | -------------------- +`alpha` | `kubectl alpha SUBCOMMAND [flags]` | List the available commands that correspond to alpha features, which are not enabled in Kubernetes clusters by default. `annotate` | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | Add or update the annotations of one or more resources. +`api-resources` | `kubectl api-resources [flags]` | List the API resources that are available. `api-versions` | `kubectl api-versions [flags]` | List the API versions that are available. `apply` | `kubectl apply -f FILENAME [flags]`| Apply a configuration change to a resource from a file or stdin. `attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | Attach to a running container either to view the output stream or interact with the container (stdin). +`auth` | `kubectl auth [flags] [options]` | Inspect authorization. `autoscale` | kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] | Automatically scale the set of pods that are managed by a replication controller. +`certificate` | `kubectl certificate SUBCOMMAND [options]` | Modify certificate resources. `cluster-info` | `kubectl cluster-info [flags]` | Display endpoint information about the master and services in the cluster. +`completion` | `kubectl completion SHELL [options]` | Output shell completion code for the specified shell (bash or zsh). `config` | `kubectl config SUBCOMMAND [flags]` | Modifies kubeconfig files. See the individual subcommands for details. +`convert` | `kubectl convert -f FILENAME [options]` | Convert config files between different API versions. Both YAML and JSON formats are accepted. +`cordon` | `kubectl cordon NODE [options]` | Mark node as unschedulable. +`cp` | `kubectl cp [options]` | Copy files and directories to and from containers. `create` | `kubectl create -f FILENAME [flags]` | Create one or more resources from a file or stdin. `delete` | kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] | Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources. `describe` | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | Display the detailed state of one or more resources. `diff` | `kubectl diff -f FILENAME [flags]`| Diff file or stdin against live configuration. +`drain` | `kubectl drain NODE [options]` | Drain node in preparation for maintenance. `edit` | kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] | Edit and update the definition of one or more resources on the server by using the default editor. `exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Execute a command against a container in a pod. `explain` | `kubectl explain [--recursive=false] [flags]` | Get documentation of various resources. For instance pods, nodes, services, etc. `expose` | kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] | Expose a replication controller, service, or pod as a new Kubernetes service. `get` | kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] | List one or more resources. +`kustomize` | `kubectl kustomize [flags] [options]` | List a set of API resources generated from instructions in a kustomization.yaml file. The argument must be the path to the directory containing the file, or a git repository URL with a path suffix specifying same with respect to the repository root. `label` | kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | Add or update the labels of one or more resources. `logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Print the logs for a container in a pod. +`options` | `kubectl options` | List of global command-line options, which apply to all commands. `patch` | kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags] | Update one or more fields of a resource by using the strategic merge patch process. +`plugin` | `kubectl plugin [flags] [options]` | Provides utilities for interacting with plugins. `port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | Forward one or more local ports to a pod. `proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Run a proxy to the Kubernetes API server. `replace` | `kubectl replace -f FILENAME` | Replace a resource from a file or stdin. +`rollout` | `kubectl rollout SUBCOMMAND [options]` | Manage the rollout of a resource. Valid resource types include: deployments, daemonsets and statefulsets. `run` | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags] | Run a specified image on the cluster. `scale` | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | Update the size of the specified replication controller. +`set` | `kubectl set SUBCOMMAND [options]` | Configure application resources. +`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | Update the taints on one or more nodes. +`top` | `kubectl top [flags] [options]` | Display Resource (CPU/Memory/Storage) usage. +`uncordon` | `kubectl uncordon NODE [options]` | Mark node as schedulable. `version` | `kubectl version [--client] [flags]` | Display the Kubernetes version running on the client and server. +`wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | Experimental: Wait for a specific condition on one or many resources. Remember: For more about command operations, see the [kubectl](/docs/user-guide/kubectl/) reference documentation. diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md index 380838b179..a0aa304217 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -325,7 +325,8 @@ deadlock conditions, kubeadm fails fast if `localhost:10255/healthz` (kubelet li kubeadm relies on the kubelet to pull the control plane images and run them properly as static Pods. After the control plane is up, kubeadm completes the tasks described in following paragraphs. -### (optional and alpha in v1.9) Write base kubelet configuration +### (optional) Write base kubelet configuration +{{< feature-state for_k8s_version="v1.9" state="alpha" >}} If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`: @@ -516,7 +517,8 @@ Please note that: access to CSR api during the `kubeadm init` process - The automatic CSR approval is managed by the csrapprover controller, according with configuration done the `kubeadm init` process -### (optional and alpha in v1.9) Write init kubelet configuration +### (optional) Write init kubelet configuration +{{< feature-state for_k8s_version="v1.9" state="alpha" >}} If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`: diff --git a/content/en/docs/setup/learning-environment/minikube.md b/content/en/docs/setup/learning-environment/minikube.md index ec8514c84c..e314d56608 100644 --- a/content/en/docs/setup/learning-environment/minikube.md +++ b/content/en/docs/setup/learning-environment/minikube.md @@ -37,116 +37,151 @@ See [Installing Minikube](/docs/tasks/tools/install-minikube/). This brief demo guides you on how to start, use, and delete Minikube locally. Follow the steps given below to start and explore Minikube. 1. Start Minikube and create a cluster: - ```shell - minikube start - ``` - The output is similar to this: - ``` - Starting local Kubernetes cluster... - Running pre-create checks... - Creating machine... - Starting local Kubernetes cluster... - ``` - For more information on starting your cluster on a specific Kubernetes version, VM, or container runtime, see [Starting a Cluster](#starting-a-cluster). + ```shell + minikube start + ``` + + The output is similar to this: + + ``` + Starting local Kubernetes cluster... + Running pre-create checks... + Creating machine... + Starting local Kubernetes cluster... + ``` + + For more information on starting your cluster on a specific Kubernetes version, VM, or container runtime, see [Starting a Cluster](#starting-a-cluster). 2. Now, you can interact with your cluster using kubectl. For more information, see [Interacting with Your Cluster](#interacting-with-your-cluster). - Let’s create a Kubernetes Deployment using an existing image named `echoserver`, which is a simple HTTP server and expose it on port 8080 using `--port`. - ```shell - kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10 - ``` - The output is similar to this: - ``` - deployment.apps/hello-minikube created - ``` -3. To access the `hello-minikube` Deployment, expose it as a Service: - ```shell - kubectl expose deployment hello-minikube --type=NodePort --port=8080 - ``` - The option `--type=NodePort` specifies the type of the Service. + Let’s create a Kubernetes Deployment using an existing image named `echoserver`, which is a simple HTTP server and expose it on port 8080 using `--port`. + + ```shell + kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10 + ``` + + The output is similar to this: + + ``` + deployment.apps/hello-minikube created + ``` +3. To access the `hello-minikube` Deployment, expose it as a Service: + + ```shell + kubectl expose deployment hello-minikube --type=NodePort --port=8080 + ``` + + The option `--type=NodePort` specifies the type of the Service. + + The output is similar to this: + + ``` + service/hello-minikube exposed + ``` - The output is similar to this: - ``` - service/hello-minikube exposed - ``` 4. The `hello-minikube` Pod is now launched but you have to wait until the Pod is up before accessing it via the exposed Service. - Check if the Pod is up and running: - ```shell - kubectl get pod - ``` - If the output shows the `STATUS` as `ContainerCreating`, the Pod is still being created: - ``` - NAME READY STATUS RESTARTS AGE - hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s - ``` - If the output shows the `STATUS` as `Running`, the Pod is now up and running: - ``` - NAME READY STATUS RESTARTS AGE - hello-minikube-3383150820-vctvh 1/1 Running 0 13s - ``` + Check if the Pod is up and running: + + ```shell + kubectl get pod + ``` + + If the output shows the `STATUS` as `ContainerCreating`, the Pod is still being created: + + ``` + NAME READY STATUS RESTARTS AGE + hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s + ``` + + If the output shows the `STATUS` as `Running`, the Pod is now up and running: + + ``` + NAME READY STATUS RESTARTS AGE + hello-minikube-3383150820-vctvh 1/1 Running 0 13s + ``` + 5. Get the URL of the exposed Service to view the Service details: - ```shell - minikube service hello-minikube --url - ``` + + ```shell + minikube service hello-minikube --url + ``` + 6. To view the details of your local cluster, copy and paste the URL you got as the output, on your browser. - The output is similar to this: - ``` - Hostname: hello-minikube-7c77b68cff-8wdzq + The output is similar to this: - Pod Information: - -no pod information available- + ``` + Hostname: hello-minikube-7c77b68cff-8wdzq - Server values: - server_version=nginx: 1.13.3 - lua: 10008 + Pod Information: + -no pod information available- - Request Information: - client_address=172.17.0.1 - method=GET - real path=/ - query= - request_version=1.1 - request_scheme=http - request_uri=http://192.168.99.100:8080/ + Server values: + server_version=nginx: 1.13.3 - lua: 10008 - Request Headers: + Request Information: + client_address=172.17.0.1 + method=GET + real path=/ + query= + request_version=1.1 + request_scheme=http + request_uri=http://192.168.99.100:8080/ + + Request Headers: accept=*/* host=192.168.99.100:30674 user-agent=curl/7.47.0 - Request Body: + Request Body: -no body in request- - ``` - If you no longer want the Service and cluster to run, you can delete them. + ``` + + If you no longer want the Service and cluster to run, you can delete them. + 7. Delete the `hello-minikube` Service: - ```shell - kubectl delete services hello-minikube - ``` - The output is similar to this: - ``` - service "hello-minikube" deleted - ``` + + ```shell + kubectl delete services hello-minikube + ``` + + The output is similar to this: + + ``` + service "hello-minikube" deleted + ``` + 8. Delete the `hello-minikube` Deployment: - ```shell - kubectl delete deployment hello-minikube - ``` - The output is similar to this: - ``` - deployment.extensions "hello-minikube" deleted - ``` + + ```shell + kubectl delete deployment hello-minikube + ``` + + The output is similar to this: + + ``` + deployment.extensions "hello-minikube" deleted + ``` + 9. Stop the local Minikube cluster: - ```shell - minikube stop - ``` - The output is similar to this: - ``` - Stopping "minikube"... - "minikube" stopped. - ``` - For more information, see [Stopping a Cluster](#stopping-a-cluster). + + ```shell + minikube stop + ``` + + The output is similar to this: + + ``` + Stopping "minikube"... + "minikube" stopped. + ``` + + For more information, see [Stopping a Cluster](#stopping-a-cluster). + 10. Delete the local Minikube cluster: + ```shell minikube delete ``` @@ -193,8 +228,8 @@ For example the command would be. minikube start --driver= ``` Minikube supports the following drivers: - {{< note >}} - See [DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/) for details on supported drivers and how to install +{{< note >}} +See [DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/) for details on supported drivers and how to install plugins. {{< /note >}} diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index cccf422587..7db25e022b 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -21,8 +21,8 @@ A flaw was found in the way runc handled system file descriptors when running co A malicious container could use this flaw to overwrite contents of the runc binary and consequently run arbitrary commands on the container host system. -Please refer to this link for more information about this issue -[cve-2019-5736 : runc vulnerability ] (https://access.redhat.com/security/cve/cve-2019-5736) +Please refer to [CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736) for more +information about the issue. {{< /caution >}} ### Applicability @@ -70,29 +70,39 @@ Keep track of the latest verified Docker version in the Kubernetes release notes Use the following commands to install Docker on your system: {{< tabs name="tab-cri-docker-installation" >}} -{{< tab name="Ubuntu 16.04+" codelang="bash" >}} -# Install Docker CE +{{< tab name="Ubuntu 16.04+" >}} + +```shell +# (Install Docker CE) ## Set up the repository: ### Install packages to allow apt to use a repository over HTTPS apt-get update && apt-get install -y \ apt-transport-https ca-certificates curl software-properties-common gnupg2 +``` -### Add Docker’s official GPG key +```shell +# Add Docker’s official GPG key: curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` -### Add Docker apt repository. +```shell +# Add the Docker apt repository: add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" +``` -## Install Docker CE. +```shell +# Install Docker CE apt-get update && apt-get install -y \ 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) +``` -# Setup daemon. +```shell +# Set up the Docker daemon cat > /etc/docker/daemon.json < /etc/docker/daemon.json <}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +{{< tab name="CentOS/RHEL 7.4+" >}} -# Install Docker CE +```shell +# (Install Docker CE) ## Set up the repository -### Install required packages. +### Install required packages yum install -y yum-utils device-mapper-persistent-data lvm2 +``` -### Add Docker repository. +```shell +## Add the Docker repository yum-config-manager --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +``` -## Install Docker CE. +```shell +# Install Docker CE yum update -y && yum install -y \ containerd.io-1.2.13 \ docker-ce-19.03.8 \ docker-ce-cli-19.03.8 +``` -## Create /etc/docker directory. +```shell +## Create /etc/docker mkdir /etc/docker +``` -# Setup daemon. +```shell +# Set up the Docker daemon cat > /etc/docker/daemon.json < /etc/docker/daemon.json <}} {{< /tabs >}} @@ -173,7 +202,7 @@ For more information, see the [CRI-O compatiblity matrix](https://github.com/cri modprobe overlay modprobe br_netfilter -# Setup required sysctl params, these persist across reboots. +# Set up required sysctl params, these persist across reboots. cat > /etc/sysctl.d/99-kubernetes-cri.conf <}} -{{< tab name="Debian" codelang="bash" >}} +{{< tab name="Debian" >}} + +```shell # 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 - +``` +```shell # 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 - +``` +```shell # 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 - +``` +```shell # 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 - +``` -# Install CRI-O +and then install CRI-O: +```shell sudo apt-get install cri-o-1.17 +``` {{< /tab >}} -{{< tab name="Ubuntu 18.04, 19.04 and 19.10" codelang="bash" >}} -# Setup repository +{{< tab name="Ubuntu 18.04, 19.04 and 19.10" >}} + +```shell +# Configure package repository . /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 +``` +```shell # Install CRI-O sudo apt-get install cri-o-1.17 +``` {{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +{{< tab name="CentOS/RHEL 7.4+" >}} + +```shell # Install prerequisites -yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/ +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo +``` +```shell # Install CRI-O -yum install --nogpgcheck -y cri-o +yum install -y cri-o +``` {{< /tab >}} -{{< tab name="openSUSE Tumbleweed" codelang="bash" >}} +{{< tab name="openSUSE Tumbleweed" >}} + +```shell sudo zypper install cri-o +``` {{< /tab >}} {{< /tabs >}} ### Start CRI-O -``` +```shell systemctl daemon-reload systemctl start crio ``` @@ -269,51 +323,72 @@ sysctl --system ### Install containerd {{< tabs name="tab-cri-containerd-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} -# Install containerd +{{< tab name="Ubuntu 16.04" >}} + +```shell +# (Install containerd) ## Set up the repository ### Install packages to allow apt to use a repository over HTTPS apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common +``` -### Add Docker’s official GPG key +```shell +## Add Docker’s official GPG key curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` -### Add Docker apt repository. +```shell +## Add Docker apt repository. add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" +``` +```shell ## Install containerd apt-get update && apt-get install -y containerd.io +``` +```shell # Configure containerd mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml +``` +```shell # Restart containerd systemctl restart containerd +``` {{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} -# Install containerd +{{< tab name="CentOS/RHEL 7.4+" >}} + +```shell +# (Install containerd) ## Set up the repository ### Install required packages yum install -y yum-utils device-mapper-persistent-data lvm2 -### Add docker repository +```shell +## Add docker repository yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +```shell ## Install containerd yum update -y && yum install -y containerd.io -# Configure containerd +```shell +## Configure containerd mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml +``` +```shell # Restart containerd systemctl restart containerd +``` {{< /tab >}} {{< /tabs >}} diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index 4a0d567f00..2d38666386 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -303,10 +303,10 @@ Below you can find installation instructions for some popular Pod network plugin {{% tab name="Calico" %}} [Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. Calico works on several architectures, including `amd64`, `arm64`, and `ppc64le`. -By default, Calico uses `192.168.0.0/16` as the Pod network CIDR, though this can be configured in the calico.yaml file. For Calico to work correctly, you need to pass this same CIDR to the `kubeadm init` command using the `--pod-network-cidr=192.168.0.0/16` flag or via kubeadm's configuration. +Calico will automatically detect which IP address range to use for pod IPs based on the value provided via the `--pod-network-cidr` flag or via kubeadm's configuration. ```shell -kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml +kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml ``` {{% /tab %}} diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md index c93186b28d..9d67fa8e53 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md @@ -122,8 +122,8 @@ option. Your cluster requirements may need a different configuration. {{< /note >}} {{< note >}} - Some CNI network plugins like Calico require a CIDR such as `192.168.0.0/16` and - some like Weave do not. See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network). + Some CNI network plugins require additional configuration, for example specifying the pod IP CIDR, while others do not. + See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network). To add a pod CIDR pass the flag `--pod-network-cidr`, or if you are using a kubeadm configuration file set the `podSubnet` field under the `networking` object of `ClusterConfiguration`. {{< /note >}} diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index b44275302a..9438e86140 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -28,7 +28,7 @@ For information how to create a cluster with kubeadm once you have performed thi * 2 GB or more of RAM per machine (any less will leave little room for your apps) * 2 CPUs or more * Full network connectivity between all machines in the cluster (public or private network is fine) -* Unique hostname, MAC address, and product_uuid for every node. See [here](#verify-the-mac-address-and-product-uuid-are-unique-for-every-node) for more details. +* Unique hostname, MAC address, and product_uuid for every node. See [here](#verify-mac-address) for more details. * Certain ports are open on your machines. See [here](#check-required-ports) for more details. * Swap disabled. You **MUST** disable swap in order for the kubelet to work properly. @@ -36,7 +36,7 @@ For information how to create a cluster with kubeadm once you have performed thi {{% capture steps %}} -## Verify the MAC address and product_uuid are unique for every node +## Verify the MAC address and product_uuid are unique for every node {#verify-mac-address} * You can get the MAC address of the network interfaces using the command `ip link` or `ifconfig -a` * The product_uuid can be checked by using the command `sudo cat /sys/class/dmi/id/product_uuid` @@ -210,12 +210,14 @@ yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes systemctl enable --now kubelet ``` - **Note:** + **Notes:** - Setting SELinux in permissive mode by running `setenforce 0` and `sed ...` effectively disables it. This is required to allow containers to access the host filesystem, which is needed by pod networks for example. You have to do this until SELinux support is improved in the kubelet. + - You can leave SELinux enabled if you know how to configure it but it may require settings that are not supported by kubeadm. + {{% /tab %}} {{% tab name="Container Linux" %}} Install CNI plugins (required for most pod network): @@ -303,4 +305,4 @@ If you are running into difficulties with kubeadm, please consult our [troublesh * [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md index 996f588dc7..ae323d38cf 100644 --- a/content/en/docs/setup/production-environment/tools/kubespray.md +++ b/content/en/docs/setup/production-environment/tools/kubespray.md @@ -21,7 +21,7 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in * openSUSE Leap 15 * continuous integration tests -To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops). +To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/). {{% /capture %}} @@ -119,4 +119,4 @@ When running the reset playbook, be sure not to accidentally target your product Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md). -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tasks/access-application-cluster/access-cluster.md b/content/en/docs/tasks/access-application-cluster/access-cluster.md index bd0de435e4..05835f2b08 100644 --- a/content/en/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/en/docs/tasks/access-application-cluster/access-cluster.md @@ -277,7 +277,7 @@ This shows the proxy-verb URL for accessing each service. For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed. Logging can also be reached through a kubectl proxy, for example at: `http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`. -(See [above](#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.) +(See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/) for how to pass credentials or use kubectl proxy.) #### Manually constructing apiserver proxy URLs @@ -376,4 +376,4 @@ There are several different proxies you may encounter when using Kubernetes: Kubernetes users will typically not need to worry about anything other than the first two types. The cluster admin will typically ensure that the latter types are setup correctly. -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md index b62438a8a1..0069334214 100644 --- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -97,7 +97,7 @@ If needed, you can expand the **Advanced options** section where you can specify Example: - ```conf +```conf release=1.0 tier=frontend environment=pod 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 ddcf7d4875..4fcd389ba2 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 @@ -28,6 +28,7 @@ into the Kubernetes API by creating a {{% /capture %}} {{% capture steps %}} + ## Create a CustomResourceDefinition When you create a new CustomResourceDefinition (CRD), the Kubernetes API Server @@ -41,6 +42,7 @@ For example, if you save the following CustomResourceDefinition to `resourcedefi {{< tabs name="CustomResourceDefinition_example_1" >}} {{% tab name="apiextensions.k8s.io/v1" %}} + ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition @@ -83,8 +85,10 @@ spec: shortNames: - ct ``` + {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} + ```yaml # Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 @@ -129,6 +133,7 @@ spec: replicas: type: integer ``` + {{% /tab %}} {{< /tabs >}} @@ -188,7 +193,7 @@ kubectl get crontab Should print a list like this: -```console +```none NAME AGE my-new-cron-object 6s ``` @@ -205,7 +210,7 @@ kubectl get ct -o yaml You should see that it contains the custom `cronSpec` and `image` fields from the yaml you used to create it: -```console +```yaml apiVersion: v1 kind: List items: @@ -228,14 +233,14 @@ metadata: ## Delete a CustomResourceDefinition When you delete a CustomResourceDefinition, the server will uninstall the RESTful API endpoint -and **delete all custom objects stored in it**. +and delete all custom objects stored in it. ```shell kubectl delete -f resourcedefinition.yaml kubectl get crontabs ``` -```console +```none Error from server (NotFound): Unable to list {"stable.example.com" "v1" "crontabs"}: the server could not find the requested resource (get crontabs.stable.example.com) ``` @@ -362,7 +367,7 @@ Structural schemas are a requirement for `apiextensions.k8s.io/v1`, and disables * [Webhook Conversion](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/#webhook-conversion) * [Pruning](#preserving-unknown-fields) -### Pruning versus preserving unknown fields +### Pruning versus preserving unknown fields {#preserving-unknown-fields} {{< feature-state state="stable" for_k8s_version="v1.16" >}} @@ -630,7 +635,9 @@ These fields can only be set with specific features enabled: - `default`: can be set for `apiextensions.k8s.io/v1` CustomResourceDefinitions. Defaulting is in GA since 1.17 (beta since 1.16 with the `CustomResourceDefaulting` feature gate to be enabled, which is the case automatically for many clusters for beta features). Compare [Validation Schema Defaulting](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting). -Note: compare with [structural schemas](#specifying-a-structural-schema) for further restriction required for certain CustomResourceDefinition features. +{{< note >}} +Compare with [structural schemas](#specifying-a-structural-schema) for further restriction required for certain CustomResourceDefinition features. +{{< /note >}} The schema is defined in the CustomResourceDefinition. In the following example, the CustomResourceDefinition applies the following validations on the custom object: @@ -642,6 +649,7 @@ Save the CustomResourceDefinition to `resourcedefinition.yaml`: {{< tabs name="CustomResourceDefinition_validation" >}} {{% tab name="apiextensions.k8s.io/v1" %}} + ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition @@ -676,8 +684,10 @@ spec: shortNames: - ct ``` + {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} + ```yaml # Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 @@ -714,6 +724,7 @@ spec: minimum: 1 maximum: 10 ``` + {{% /tab %}} {{< /tabs >}} @@ -852,7 +863,7 @@ spec: replicas: 1 ``` -Note that defaulting happens on the object +Defaulting happens on the object * in the request to the API server using the request version defaults, * when reading from etcd using the storage version defaults, @@ -895,9 +906,11 @@ columns are shown by the `kubectl get` command. You can customize these columns CustomResourceDefinition. The following example adds the `Spec`, `Replicas`, and `Age` columns. -1. Save the CustomResourceDefinition to `resourcedefinition.yaml`. - {{< tabs name="CustomResourceDefinition_printer_columns" >}} - {{% tab name="apiextensions.k8s.io/v1" %}} +Save the CustomResourceDefinition to `resourcedefinition.yaml`: + +{{< tabs name="CustomResourceDefinition_printer_columns" >}} +{{% tab name="apiextensions.k8s.io/v1" %}} + ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition @@ -942,8 +955,10 @@ spec: type: date jsonPath: .metadata.creationTimestamp ``` - {{% /tab %}} - {{% tab name="apiextensions.k8s.io/v1beta1" %}} + +{{% /tab %}} +{{% tab name="apiextensions.k8s.io/v1beta1" %}} + ```yaml # Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 @@ -986,31 +1001,34 @@ spec: type: date JSONPath: .metadata.creationTimestamp ``` - {{% /tab %}} - {{< /tabs >}} -2. Create the CustomResourceDefinition: +{{% /tab %}} +{{< /tabs >}} - ```shell - kubectl apply -f resourcedefinition.yaml - ``` +Create the CustomResourceDefinition: -3. Create an instance using the `my-crontab.yaml` from the previous section. +```shell +kubectl apply -f resourcedefinition.yaml +``` -4. Invoke the server-side printing: +Create an instance using the `my-crontab.yaml` from the previous section. - ```shell - kubectl get crontab my-new-cron-object - ``` +Invoke the server-side printing: - Notice the `NAME`, `SPEC`, `REPLICAS`, and `AGE` columns in the output: +```shell +kubectl get crontab my-new-cron-object +``` - ``` - NAME SPEC REPLICAS AGE - my-new-cron-object * * * * * 1 7s - ``` +Notice the `NAME`, `SPEC`, `REPLICAS`, and `AGE` columns in the output: +``` +NAME SPEC REPLICAS AGE +my-new-cron-object * * * * * 1 7s +``` + +{{< note >}} The `NAME` column is implicit and does not need to be defined in the CustomResourceDefinition. +{{< /note >}} #### Priority @@ -1133,6 +1151,7 @@ Save the CustomResourceDefinition to `resourcedefinition.yaml`: {{< tabs name="CustomResourceDefinition_scale" >}} {{% tab name="apiextensions.k8s.io/v1" %}} + ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition @@ -1184,8 +1203,10 @@ spec: shortNames: - ct ``` + {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} + ```yaml # Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 @@ -1238,6 +1259,7 @@ spec: # labelSelectorPath defines the JSONPath inside of a custom resource that corresponds to Scale.Status.Selector. labelSelectorPath: .status.labelSelector ``` + {{% /tab %}} {{< /tabs >}} @@ -1307,6 +1329,7 @@ Save the following CustomResourceDefinition to `resourcedefinition.yaml`: {{< tabs name="CustomResourceDefinition_categories" >}} {{% tab name="apiextensions.k8s.io/v1" %}} + ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition @@ -1342,8 +1365,10 @@ spec: categories: - all ``` + {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} + ```yaml # Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 @@ -1380,6 +1405,7 @@ spec: categories: - all ``` + {{% /tab %}} {{< /tabs >}} @@ -1431,4 +1457,4 @@ crontabs/my-new-cron-object 3s * Serve [multiple versions](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/) of a CustomResourceDefinition. -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tasks/administer-cluster/encrypt-data.md b/content/en/docs/tasks/administer-cluster/encrypt-data.md index 920fe19197..b96f034963 100644 --- a/content/en/docs/tasks/administer-cluster/encrypt-data.md +++ b/content/en/docs/tasks/administer-cluster/encrypt-data.md @@ -62,12 +62,12 @@ but not both in the same item). The first provider in the list is used to encrypt resources going into storage. When reading resources from storage each provider that matches the stored data attempts to decrypt the data in -order. If no provider can read the stored data due to a mismatch in format or secret key, an error -is returned which prevents clients from accessing that resource. +order. If no provider can read the stored data due to a mismatch in format or secret key, an error +is returned which prevents clients from accessing that resource. {{< caution >}} -**IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed), -the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to +**IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed), +the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to read that resource will fail until it is deleted or a valid decryption key is provided. {{< /caution >}} @@ -117,9 +117,9 @@ To create a new secret perform the following steps: 1. Generate a 32 byte random key and base64 encode it. If you're on Linux or macOS, run the following command: - ``` - head -c 32 /dev/urandom | base64 - ``` + ```shell + head -c 32 /dev/urandom | base64 + ``` 2. Place that value in the secret field. 3. Set the `--encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file. @@ -138,39 +138,42 @@ program to retrieve the contents of your secret. 1. Create a new secret called `secret1` in the `default` namespace: - ``` - kubectl create secret generic secret1 -n default --from-literal=mykey=mydata - ``` + ```shell + kubectl create secret generic secret1 -n default --from-literal=mykey=mydata + ``` 2. Using the etcdctl commandline, read that secret out of etcd: - ``` -    ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C - ``` + `ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C` + + where `[...]` must be the additional arguments for connecting to the etcd server. + +3. Verify the stored secret is prefixed with `k8s:enc:aescbc:v1:` which indicates the `aescbc` provider has encrypted the resulting data. - where `[...]` must be the additional arguments for connecting to the etcd server. -3. Verify the stored secret is prefixed with `k8s:enc:aescbc:v1:` which indicates the `aescbc` provider has encrypted the resulting data. 4. Verify the secret is correctly decrypted when retrieved via the API: - ``` - kubectl describe secret secret1 -n default - ``` + ```shell + kubectl describe secret secret1 -n default + ``` - should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/concepts/configuration/secret#decoding-a-secret) to - completely decode the secret. + should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/concepts/configuration/secret#decoding-a-secret) to + completely decode the secret. ## Ensure all secrets are encrypted Since secrets are encrypted on write, performing an update on a secret will encrypt that content. -``` +```shell kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` The command above reads all secrets and then updates them to apply server side encryption. + +{{< note >}} If an error occurs due to a conflicting write, retry the command. For larger clusters, you may wish to subdivide the secrets by namespace or script an update. +{{< /note >}} ## Rotating a decryption key @@ -206,7 +209,10 @@ resources: secret: ``` -and restart all `kube-apiserver` processes. Then run the command `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` +and restart all `kube-apiserver` processes. Then run: +```shell +kubectl get secrets --all-namespaces -o json | kubectl replace -f - +``` to force all secrets to be decrypted. {{% /capture %}} 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 6e7cfe079d..f0368ecaf9 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -50,59 +50,59 @@ The upgrade workflow at high level is the following: ## Determine which version to upgrade to -1. Find the latest stable 1.18 version: +Find the latest stable 1.18 version: - {{< tabs name="k8s_install_versions" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{< tabs name="k8s_install_versions" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} apt update apt-cache madison kubeadm # 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" %}} +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} yum list --showduplicates kubeadm --disableexcludes=kubernetes # 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 >}} +{{% /tab %}} +{{< /tabs >}} ## Upgrading control plane nodes ### Upgrade the first control plane node -1. On your first control plane node, upgrade kubeadm: +- On your first control plane node, upgrade kubeadm: - {{< tabs name="k8s_install_kubeadm_first_cp" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{< tabs name="k8s_install_kubeadm_first_cp" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} # replace x in 1.18.x-00 with the latest patch version apt-mark unhold kubeadm && \ apt-get update && apt-get install -y kubeadm=1.18.x-00 && \ apt-mark hold kubeadm - + - # since apt-get version 1.1 you can also use the following method apt-get update && \ apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00 - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} # replace x in 1.18.x-0 with the latest patch version yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} +{{% /tab %}} +{{< /tabs >}} -1. Verify that the download works and has the expected version: +- Verify that the download works and has the expected version: ```shell kubeadm version ``` -1. Drain the control plane node: +- Drain the control plane node: ```shell # replace with the name of your control plane node kubectl drain --ignore-daemonsets ``` -1. On the control plane node, run: +- On the control plane node, run: ```shell sudo kubeadm upgrade plan @@ -145,13 +145,13 @@ The upgrade workflow at high level is the following: This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to. - {{< note >}} - `kubeadm upgrade` also automatically renews the certificates that it manages on this node. - To opt-out of certificate renewal the flag `--certificate-renewal=false` can be used. - For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs). - {{}} +{{< note >}} +`kubeadm upgrade` also automatically renews the certificates that it manages on this node. +To opt-out of certificate renewal the flag `--certificate-renewal=false` can be used. +For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadmkubeadm-certs). +{{}} -1. Choose a version to upgrade to, and run the appropriate command. For example: +- Choose a version to upgrade to, and run the appropriate command. For example: ```shell # replace x with the patch version you picked for this upgrade @@ -240,7 +240,7 @@ The upgrade workflow at high level is the following: [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. ``` -1. Manually upgrade your CNI provider plugin. +- Manually upgrade your CNI provider plugin. Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow. Check the [addons](/docs/concepts/cluster-administration/addons/) page to @@ -248,7 +248,7 @@ The upgrade workflow at high level is the following: This step is not required on additional control plane nodes if the CNI provider runs as a DaemonSet. -1. Uncordon the control plane node: +- Uncordon the control plane node: ```shell # replace with the name of your control plane node @@ -257,46 +257,46 @@ The upgrade workflow at high level is the following: ### Upgrade additional control plane nodes -1. Same as the first control plane node but use: +Same as the first control plane node but use: - ``` - sudo kubeadm upgrade node - ``` +``` +sudo kubeadm upgrade node +``` - instead of: +instead of: - ``` - sudo kubeadm upgrade apply - ``` +``` +sudo kubeadm upgrade apply +``` - Also `sudo kubeadm upgrade plan` is not needed. +Also `sudo kubeadm upgrade plan` is not needed. ### Upgrade kubelet and kubectl -1. Upgrade the kubelet and kubectl on all control plane nodes: +Upgrade the kubelet and kubectl on all control plane nodes: - {{< tabs name="k8s_install_kubelet" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{< tabs name="k8s_install_kubelet" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} # replace x in 1.18.x-00 with the latest patch version apt-mark unhold kubelet kubectl && \ apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \ apt-mark hold kubelet kubectl - + - # since apt-get version 1.1 you can also use the following method apt-get update && \ apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00 - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} # replace x in 1.18.x-0 with the latest patch version yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} +{{% /tab %}} +{{< /tabs >}} -1. Restart the kubelet +Restart the kubelet - ```shell - sudo systemctl restart kubelet - ``` +```shell +sudo systemctl restart kubelet +``` ## Upgrade worker nodes @@ -305,28 +305,28 @@ without compromising the minimum required capacity for running your workloads. ### Upgrade kubeadm -1. Upgrade kubeadm on all worker nodes: +- Upgrade kubeadm on all worker nodes: - {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{< tabs name="k8s_install_kubeadm_worker_nodes" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} # replace x in 1.18.x-00 with the latest patch version apt-mark unhold kubeadm && \ apt-get update && apt-get install -y kubeadm=1.18.x-00 && \ apt-mark hold kubeadm - + - # since apt-get version 1.1 you can also use the following method apt-get update && \ apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00 - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} # replace x in 1.18.x-0 with the latest patch version yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} +{{% /tab %}} +{{< /tabs >}} ### Drain the node -1. Prepare the node for maintenance by marking it unschedulable and evicting the workloads: +- Prepare the node for maintenance by marking it unschedulable and evicting the workloads: ```shell # replace with the name of your node you are draining @@ -343,7 +343,7 @@ without compromising the minimum required capacity for running your workloads. ### Upgrade the kubelet configuration -1. Call the following command: +- Call the following command: ```shell sudo kubeadm upgrade node @@ -351,26 +351,26 @@ without compromising the minimum required capacity for running your workloads. ### Upgrade kubelet and kubectl -1. Upgrade the kubelet and kubectl on all worker nodes: +- Upgrade the kubelet and kubectl on all worker nodes: - {{< tabs name="k8s_kubelet_and_kubectl" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{< tabs name="k8s_kubelet_and_kubectl" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} # replace x in 1.18.x-00 with the latest patch version apt-mark unhold kubelet kubectl && \ apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \ apt-mark hold kubelet kubectl - + - # since apt-get version 1.1 you can also use the following method apt-get update && \ apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00 - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} # replace x in 1.18.x-0 with the latest patch version yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} +{{% /tab %}} +{{< /tabs >}} -1. Restart the kubelet +- Restart the kubelet ```shell sudo systemctl restart kubelet @@ -378,7 +378,7 @@ without compromising the minimum required capacity for running your workloads. ### Uncordon the node -1. Bring the node back online by marking it schedulable: +- Bring the node back online by marking it schedulable: ```shell # replace with the name of your node @@ -441,4 +441,4 @@ and post-upgrade manifest file for a certain component, a backup file for it wil `kubeadm upgrade node` does the following on worker nodes: - Fetches the kubeadm `ClusterConfiguration` from the cluster. -- Upgrades the kubelet configuration for this node. +- Upgrades the kubelet configuration for this node. \ No newline at end of file diff --git a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md index 83bb8f3379..af5696d622 100644 --- a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md +++ b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md @@ -70,10 +70,10 @@ and is overridden by command-line flags. Unspecified values in the new configura will receive default values appropriate to the configuration version (e.g. `kubelet.config.k8s.io/v1beta1`), unless overridden by flags. -The status of the Node's kubelet configuration is reported via +The status of the Node's kubelet configuration is reported via `Node.Spec.Status.Config`. Once you have updated a Node to use the new ConfigMap, you can observe this status to confirm that the Node is using the -intended configuration. +intended configuration. This document describes editing Nodes using `kubectl edit`. There are other ways to modify a Node's spec, including `kubectl patch`, for @@ -136,7 +136,7 @@ adapt the steps if you prefer to extract the `kubeletconfig` subobject manually. 1. Choose a Node to reconfigure. In this example, the name of this Node is referred to as `NODE_NAME`. -2. Start the kubectl proxy in the background using the following command: +2. Start the kubectl proxy in the background using the following command: ```bash kubectl proxy --port=8001 & @@ -236,8 +236,8 @@ Retrieve the Node using the `kubectl get node ${NODE_NAME} -o yaml` command and The`lastKnownGood` configuration might not be present if it is set to its default value, the local config deployed with the node. The status will update `lastKnownGood` to -match a valid `assigned` config after the kubelet becomes comfortable with the config. -The details of how the kubelet determines a config should become the `lastKnownGood` are +match a valid `assigned` config after the kubelet becomes comfortable with the config. +The details of how the kubelet determines a config should become the `lastKnownGood` are not guaranteed by the API, but is currently implemented as a 10-minute grace period. You can use the following command (using `jq`) to filter down @@ -287,7 +287,7 @@ by eye). If an error occurs, the kubelet reports it in the `Node.Status.Config.Error` structure. Possible errors are listed in -[Understanding Node.Status.Config.Error messages](#understanding-node-status-config-error-messages). +[Understanding Node.Status.Config.Error messages](#understanding-node-config-status-errors). You can search for the identical text in the kubelet log for additional details and context about the error. @@ -355,7 +355,7 @@ metadata and checkpoints. The structure of the kubelet's checkpointing directory | - ... ``` -## Understanding Node.Status.Config.Error messages +## Understanding Node.Status.Config.Error messages {#understanding-node-config-status-errors} The following table describes error messages that can occur when using Dynamic Kubelet Config. You can search for the identical text @@ -379,4 +379,4 @@ internal failure, see Kubelet log for details | The kubelet encountered some int - For more information on configuring the kubelet via a configuration file, see [Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file). - See the reference documentation for [`NodeConfigSource`](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core) -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md index e82b55583b..c78c9edb42 100644 --- a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md +++ b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md @@ -173,7 +173,7 @@ For example: in Centos, you can do this using the tuned toolset. Memory pressure at the node level leads to System OOMs which affects the entire node and all pods running on it. Nodes can go offline temporarily until memory has been reclaimed. To avoid (or reduce the probability of) system OOMs kubelet -provides [`Out of Resource`](./out-of-resource.md) management. Evictions are +provides [`Out of Resource`](/docs/tasks/administer-cluster/out-of-resource/) management. Evictions are supported for `memory` and `ephemeral-storage` only. By reserving some memory via `--eviction-hard` flag, the `kubelet` attempts to `evict` pods whenever memory availability on the node drops below the reserved value. Hypothetically, if @@ -190,7 +190,7 @@ The scheduler treats `Allocatable` as the available `capacity` for pods. `kubelet` enforce `Allocatable` across pods by default. Enforcement is performed by evicting pods whenever the overall usage across all pods exceeds `Allocatable`. More details on eviction policy can be found -[here](./out-of-resource.md#eviction-policy). This enforcement is controlled by +[here](/docs/tasks/administer-cluster/out-of-resource/#eviction-policy). This enforcement is controlled by specifying `pods` value to the kubelet flag `--enforce-node-allocatable`. @@ -251,4 +251,4 @@ If `kube-reserved` and/or `system-reserved` is not enforced and system daemons exceed their reservation, `kubelet` evicts pods whenever the overall node memory usage is higher than `31.5Gi` or `storage` is greater than `90Gi` -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md index a622eb5917..181b92b8e1 100644 --- a/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -180,9 +180,6 @@ The output shows that the Pod status is Pending. That is, the Pod has not been scheduled to run on any Node, and it will remain in the Pending state indefinitely: -```shell -kubectl get pod cpu-demo-2 --namespace=cpu-example -``` ``` NAME READY STATUS RESTARTS AGE cpu-demo-2 0/1 Pending 0 7m diff --git a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md index 530666e9dc..ac912327f3 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md +++ b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md @@ -16,6 +16,10 @@ This page shows how to use the `runAsUserName` setting for Pods and containers t You need to have a Kubernetes cluster and the kubectl command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes where pods with containers running Windows workloads will get scheduled. +{{% /capture %}} + +{{% capture steps %}} + ## Set the Username for a Pod To specify the username with which to execute the Pod's container processes, include the `securityContext` field ([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) in the Pod specification, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core) field containing the `runAsUserName` field. @@ -118,4 +122,4 @@ For more information about these limtations, check [here](https://support.micros * [Managing Workload Identity with Group Managed Service Accounts (GMSA)](/docs/setup/production-environment/windows/user-guide-windows-containers/#managing-workload-identity-with-group-managed-service-accounts) * [Configure GMSA for Windows pods and containers](/docs/tasks/configure-pod-container/configure-gmsa/) -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md index a86ae91aca..021a8feb22 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/en/docs/tasks/configure-pod-container/configure-service-account.md @@ -183,27 +183,38 @@ The content of `token` is elided here. ## Add ImagePullSecrets to a service account -First, create an imagePullSecret, as described [here](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). -Next, verify it has been created. For example: +### Create an imagePullSecret -```shell -kubectl get secrets myregistrykey -``` +- Create an imagePullSecret, as described in [Specifying ImagePullSecrets on a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). -The output is similar to this: + ```shell + kubectl create secret docker-registry myregistrykey --docker-server=DUMMY_SERVER \ + --docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \ + --docker-email=DUMMY_DOCKER_EMAIL + ``` -``` -NAME TYPE DATA AGE -myregistrykey   kubernetes.io/.dockerconfigjson   1       1d -``` +- Verify it has been created. + ```shell + kubectl get secrets myregistrykey + ``` + + The output is similar to this: + + ``` + NAME TYPE DATA AGE + myregistrykey   kubernetes.io/.dockerconfigjson   1       1d + ``` + +### Add image pull secret to service account Next, modify the default service account for the namespace to use this secret as an imagePullSecret. + ```shell kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' ``` -Interactive version requires manual edit: +You can instead use `kubectl edit`, or manually edit the YAML manifests as shown below: ```shell kubectl get serviceaccounts default -o yaml > ./sa.yaml @@ -248,12 +259,19 @@ Finally replace the serviceaccount with the new updated `sa.yaml` file kubectl replace serviceaccount default -f ./sa.yaml ``` -Now, any new pods created in the current namespace will have this added to their spec: +### Verify imagePullSecrets was added to pod spec -```yaml -spec: - imagePullSecrets: - - name: myregistrykey +Now, when a new Pod is created in the current namespace and using the default ServiceAccount, the new Pod has its `spec.imagePullSecrets` field set automatically: + +```shell +kubectl run nginx --image=nginx --restart=Never +kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}' +``` + +The output is: + +``` +myregistrykey ``` +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + +노드에는 로컬에 연결된 쓰기 가능 장치 또는, 때로는 RAM에 의해 +지원되는 로컬 임시 스토리지가 있다. +"임시"는 내구성에 대한 장기간의 보증이 없음을 의미한다. + +파드는 스크래치 공간, 캐싱 및 로그에 대해 임시 로컬 스토리지를 사용한다. +kubelet은 로컬 임시 스토리지를 사용하여 컨테이너에 +[`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) +{{< glossary_tooltip term_id="volume" text="볼륨" >}}을 마운트하기 위해 파드에 스크래치 공간을 제공할 수 있다. + +kubelet은 이러한 종류의 스토리지를 사용하여 +[노드-레벨 컨테이너 로그](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅), +컨테이너 이미지 및 실행 중인 컨테이너의 쓰기 가능 계층을 보유한다. + +{{< caution >}} +노드가 실패하면, 임시 스토리지의 데이터가 손실될 수 있다. +애플리케이션은 로컬 임시 스토리지에서 성능에 대한 SLA(예: 디스크 IOPS)를 +기대할 수 없다. +{{< /caution >}} + +베타 기능에서, 쿠버네티스는 파드가 사용할 수 있는 임시 로컬 스토리지의 양을 +추적, 예약 및 제한할 수 있도록 해준다. + +### 로컬 임시 스토리지 구성 + +쿠버네티스는 노드에서 로컬 임시 스토리지를 구성하는 두 가지 방법을 지원한다. +{{< tabs name="local_storage_configurations" >}} +{{% tab name="단일 파일시스템" %}} +이 구성에서, 모든 종류의 임시 로컬 데이터(`emptyDir` 볼륨, +쓰기 가능 계층, 컨테이너 이미지, 로그)를 하나의 파일시스템에 배치한다. +kubelet을 구성하는 가장 효과적인 방법은 이 파일시스템을 쿠버네티스(kubelet) 데이터 전용으로 +하는 것이다. + +kubelet은 또한 +[노드-레벨 컨테이너 로그](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)를 +작성하고 임시 로컬 스토리지와 유사하게 처리한다. + +kubelet은 구성된 로그 디렉터리 내의 파일에 로그를 기록한다(기본적으로 +`/var/log`). 그리고 로컬에 저장된 다른 데이터에 대한 기본 디렉터리가 있다(기본적으로 +`/var/lib/kubelet`). + +일반적으로, `/var/lib/kubelet` 와 `/var/log` 모두 시스템 루트 파일시스템에 위치하고, +그리고 kubelet은 이런 레이아웃을 염두에 두고 설계되었다. + +노드는 쿠버네티스에서 사용하지 않는 다른 많은 파일시스템을 +가질 수 있다. +{{% /tab %}} +{{% tab name="두 개의 파일시스템" %}} +사용하고 있는 노드에 실행 중인 파드에서 발생하는 임시 데이터를 +위한 파일시스템을 가진다(로그와 `emptyDir` 볼륨). 이 파일시스템을 +다른 데이터(예를 들어, 쿠버네티스와 관련없는 시스템 로그)를 위해 사용할 수 있다. 이 파일시스템은 +루트 파일시스템일 수도 있다. + +kubelet은 또한 +[노드-레벨 컨테이너 로그](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)를 +첫 번째 파일시스템에 기록하고, 임시 로컬 스토리지와 유사하게 처리한다. + +또한 다른 논리 스토리지 장치가 지원하는 별도의 파일시스템을 사용한다. +이 구성에서, 컨테이너 이미지 계층과 쓰기 가능한 계층을 배치하도록 +kubelet에 지시하는 디렉터리는 이 두 번째 파일시스템에 있다. + +첫 번째 파일시스템에는 이미지 계층이나 쓰기 가능한 계층이 없다. + +노드는 쿠버네티스에서 사용하지 않는 다른 많은 파일시스템을 +가질 수 있다. +{{% /tab %}} +{{< /tabs >}} + +kubelet은 사용 중인 로컬 스토리지 양을 측정할 수 있다. 이것은 다음을 +제공한다. + +- `LocalStorageCapacityIsolation` + [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)(이 + 기능이 기본적으로 설정되어 있음)를 활성화하고, +- 로컬 임시 스토리지에 대한 지원되는 구성 중 하나를 + 사용하여 노드를 설정한다. + +다른 구성을 사용하는 경우, kubelet은 임시 로컬 스토리지에 대한 리소스 +제한을 적용하지 않는다. + +{{< note >}} +kubelet은 로컬 임시 스토리지가 아닌 컨테이너 메모리 사용으로 +`tmpfs` emptyDir 볼륨을 추적한다. +{{< /note >}} + +### 로컬 임시 스토리지에 대한 요청 및 제한 설정 + +_임시-스토리지_ 를 사용하여 로컬 임시 저장소를 관리할 수 있다. 파드의 각 컨테이너는 다음 중 하나 이상을 지정할 수 있다. + +* `spec.containers[].resources.limits.ephemeral-storage` +* `spec.containers[].resources.requests.ephemeral-storage` + +`ephemeral-storage` 에 대한 제한 및 요청은 바이트 단위로 측정된다. E, P, T, G, M, K와 +같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 정수로 표현할 수 있다. +Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다. +예를 들어, 다음은 대략 동일한 값을 나타낸다. + +```shell +128974848, 129e6, 129M, 123Mi +``` + +다음 예에서, 파드에 두 개의 컨테이너가 있다. 각 컨테이너에는 2GiB의 로컬 임시 스토리지 요청이 있다. 각 컨테이너에는 4GiB의 로컬 임시 스토리지 제한이 있다. 따라서, 파드는 4GiB의 로컬 임시 스토리지 요청과 8GiB 스토리지 제한을 가진다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: db + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "password" + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" + - name: wp + image: wordpress + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" +``` + +### 임시-스토리지 요청이 있는 파드의 스케줄링 방법 + +파드를 생성할 때, 쿠버네티스 스케줄러는 파드를 실행할 노드를 +선택한다. 각 노드에는 파드에 제공할 수 있는 최대 임시 스토리지 공간이 있다. 자세한 정보는, [노드 할당 가능](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)을 참조한다. + +스케줄러는 스케줄된 컨테이너의 리소스 요청 합계가 노드 용량보다 작도록 한다. + +### 임시 스토리지 소비 관리 {#resource-emphemeralstorage-consumption} + +kubelet이 로컬 임시 스토리지를 리소스로 관리하는 경우, +kubelet은 다음에서 스토리지 사용을 측정한다. + +- _tmpfs_ `emptyDir` 볼륨을 제외한 `emptyDir` 볼륨 +- 노드-레벨 로그가 있는 디렉터리 +- 쓰기 가능한 컨테이너 계층 + +허용하는 것보다 더 많은 임시 스토리지를 파드가 사용하는 경우, kubelet은 +파드 축출을 트리거하는 축출 신호를 설정한다. + +컨테이너-레벨 격리의 경우, 컨테이너의 쓰기 가능한 계층과 로그 +사용량이 스토리지 제한을 초과하면, kubelet은 파드를 축출하도록 표시한다. + +파드-레벨 격리에 대해 kubelet은 해당 파드의 컨테이너에 대한 제한을 합하여 +전체 파드 스토리지 제한을 해결한다. 이 경우, 모든 +컨테이너와 파드의 `emptyDir` 볼륨의 로컬 임시 스토리지 사용량 합계가 +전체 파드 스토리지 제한을 초과하면, kubelet은 파드를 축출 대상으로 +표시한다. + +{{< caution >}} +kubelet이 로컬 임시 스토리지를 측정하지 않는 경우, +로컬 스토리지 제한을 초과하는 파드는 로컬 스토리지 리소스 제한을 +위반해도 축출되지 않는다. + +그러나, 쓰기 가능한 컨테이너 계층, 노드-레벨 로그 +또는 `emptyDir` 볼륨의 파일 시스템 공간이 부족하면, 로컬 +스토리지가 부족하다고 노드 자체에 {{< glossary_tooltip text="테인트" term_id="taint" >}}되고 +이로인해 특별히 이 테인트를 허용하지 않는 모든 파드를 축출하도록 트리거한다. + +임시 로컬 스토리지에 대해 지원되는 [구성](#로컬-임시-스토리지-구성)을 +참조한다. +{{< /caution >}} + +kubelet은 파드 스토리지 사용을 측정하는 다양한 방법을 지원한다. + +{{< tabs name="resource-emphemeralstorage-measurement" >}} +{{% tab name="주기적 스캐닝" %}} +kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기 가능한 컨테이너 계층을 +스캔하는 정기적인 스케줄 검사를 수행한다. + +스캔은 사용된 공간의 양을 측정한다. + +{{< note >}} +이 모드에서, kubelet은 삭제된 파일의 열린 파일 디스크립터를 +추적하지 않는다. + +여러분(또는 컨테이너)이 `emptyDir` 볼륨 안에 파일을 생성하면, +그 파일이 열리고, 파일이 열려있는 동안 파일을 +삭제하면, 삭제된 파일의 inode는 해당 파일을 닫을 때까지 +유지되지만 kubelet은 사용 중인 공간으로 분류하지 않는다. +{{< /note >}} +{{% /tab %}} +{{% tab name="파일시스템 프로젝트 쿼터" %}} + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +프로젝트 쿼터는 파일시스템에서 스토리지 사용을 관리하기 위한 +운영체제 레벨의 기능이다. 쿠버네티스를 사용하면, 스토리지 사용을 +모니터링하기 위해 프로젝트 쿼터를 사용할 수 있다. 노드에서 'emptyDir' 볼륨을 +지원하는 파일시스템이 프로젝트 쿼터 지원을 제공하는지 확인한다. +예를 들어, XFS와 ext4fs는 프로젝트 쿼터를 지원한다. + +{{< note >}} +프로젝트 쿼터를 통해 스토리지 사용을 모니터링할 수 있다. 이는 제한을 강제하지 않는다. +{{< /note >}} + +쿠버네티스는 `1048576` 부터 프로젝트 ID를 사용한다. 사용 중인 ID는 +`/etc/projects` 와 `/etc/projid` 에 등록되어 있다. 이 범위의 프로젝트 ID가 +시스템에서 다른 목적으로 사용되는 경우, 쿠버네티스가 +이를 사용하지 않도록 해당 프로젝트 ID를 `/etc/projects` 와 `/etc/projid` 에 +등록해야 한다. + +쿼터는 디렉터리 검색보다 빠르고 정확하다. 디렉터리가 +프로젝트에 할당되면, 디렉터리 아래에 생성된 +모든 파일이 해당 프로젝트에 생성되며, 커널은 해당 프로젝트의 +파일에서 사용 중인 블록 수를 추적하기만 하면 된다. +파일이 생성되고 삭제되었지만, 열린 파일 디스크립터가 있으면, +계속 공간을 소비한다. 쿼터 추적은 공간을 정확하게 기록하는 반면 +디렉터리 스캔은 삭제된 파일이 사용한 스토리지를 간과한다. + +프로젝트 쿼터를 사용하려면, 다음을 수행해야 한다. + +* kubelet 구성에서 `LocalStorageCapacityIsolationFSQuotaMonitoring=true` + [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 + 활성화한다. + +* 루트 파일시스템(또는 선택적인 런타임 파일시스템)에 + 프로젝트 쿼터가 활성화되어 있는지 확인한다. 모든 XFS 파일시스템은 프로젝트 쿼터를 지원한다. + ext4 파일시스템의 경우, 파일시스템이 마운트되지 않은 상태에서 프로젝트 쿼터 + 추적 기능을 활성화해야 한다. + ```bash + # ext4인 /dev/block-device가 마운트되지 않은 경우 + sudo tune2fs -O project -Q prjquota /dev/block-device + ``` + +* 루트 파일시스템(또는 선택적인 런타임 파일시스템)은 프로젝트 쿼터를 + 활성화한 상태에서 마운트해야 힌다. XFS와 ext4fs 모두에서, + 마운트 옵션의 이름은 `prjquota` 이다. + +{{% /tab %}} +{{< /tabs >}} + +## 확장된 리소스 + +확장된 리소스는 `kubernetes.io` 도메인 외부의 전체 주소(fully-qualified) +리소스 이름이다. 쿠버네티스에 내장되지 않은 리소스를 클러스터 운영자가 알리고 +사용자는 사용할 수 있다. + +확장된 리소스를 사용하려면 두 단계가 필요한다. 먼저, 클러스터 +운영자는 확장된 리소스를 알려야 한다. 둘째, 사용자는 파드의 +확장된 리소스를 요청해야 한다. + +### 확장된 리소스 관리 + +#### 노드-레벨의 확장된 리소스 + +노드-레벨의 확장된 리소스는 노드에 연결된다. + +##### 장치 플러그인 관리 리소스 +각 노드에서 +장치 플러그인 관리 리소스를 알리는 방법은 +[장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 참조한다. + +##### 기타 리소스 +새로운 노드-레벨의 확장된 리소스를 알리기 위해, 클러스터 운영자는 +API 서버에 `PATCH` HTTP 요청을 제출하여 클러스터의 +노드에 대해 `status.capacity` 에서 사용할 수 있는 수량을 지정할 수 있다. 이 작업 +후에는, 노드의 `status.capacity` 에 새로운 리소스가 포함된다. 이 +`status.allocatable` 필드는 kubelet에 의해 비동기적으로 새로운 +리소스로 자동 업데이트된다. 참고로 스케줄러가 파드 적합성을 평가할 때 노드 +`status.allocatable` 값을 사용하므로, 노드 용량을 +새 리소스로 패치하는 것과 해당 노드에서 리소스를 스케줄하도록 요청하는 첫 번째 파드 +사이에 약간의 지연이 있을 수 있다. + +**예제:** + +다음은 `curl` 을 사용하여 마스터가 `k8s-master` 인 노드 `k8s-node-1` 에 +5개의 "example.com/foo" 리소스를 알리는 HTTP 요청을 구성하는 방법을 +보여주는 예이다. + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ +http://k8s-master:8080/api/v1/nodes/k8s-node-1/status +``` + +{{< note >}} +앞의 요청에서, `~1` 은 패치 경로에서 문자 `/` 의 +인코딩이다. JSON-Patch의 작업 경로 값은 +JSON-Pointer로 해석된다. 더 자세한 내용은, +[IETF RFC 6901, 섹션 3](https://tools.ietf.org/html/rfc6901#section-3)을 참조한다. +{{< /note >}} + +#### 클러스터-레벨의 확장된 리소스 + +클러스터-레벨의 확장된 리소스는 노드에 연결되지 않는다. 이들은 일반적으로 +리소스 소비와 리소스 쿼터를 처리하는 스케줄러 익스텐더(extender)에 의해 관리된다. + +[스케줄러 정책 구성](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)에서 +스케줄러 익스텐더가 +처리하는 확장된 리소스를 지정할 수 있다. + +**예제:** + +스케줄러 정책에 대한 다음의 구성은 클러스터-레벨의 확장된 리소스 +"example.com/foo"가 스케줄러 익스텐더에 의해 처리됨을 +나타낸다. + +- 파드가 "example.com/foo"를 요청하는 경우에만 스케줄러가 파드를 스케줄러 + 익스텐더로 보낸다. +- 이 `ignoredByScheduler` 필드는 스케줄러가 `PodFitsResources` 속성에서 + "example.com/foo" 리소스를 확인하지 않도록 지정한다. + +```json +{ + "kind": "Policy", + "apiVersion": "v1", + "extenders": [ + { + "urlPrefix":"", + "bindVerb": "bind", + "managedResources": [ + { + "name": "example.com/foo", + "ignoredByScheduler": true + } + ] + } + ] +} +``` + +### 확장된 리소스 소비 + +사용자는 CPU와 메모리 같은 파드 스펙의 확장된 리소스를 사용할 수 있다. +스케줄러는 리소스 어카운팅(resource accounting)을 관리하여 사용 가능한 양보다 +많은 양의 리소스가 여러 파드에 동시에 할당되지 않도록 한다. + +API 서버는 확장된 리소스의 수량을 정수로 제한한다. +_유효한_ 수량의 예로는 `3`, `3000m` 그리고 `3Ki` 를 들 수 있다. _유효하지 않은_ +수량의 예는 `0.5` 와 `1500m` 이다. + +{{< note >}} +확장된 리소스는 불명확한 정수 리소스를 대체한다. +사용자는 예약된 `kubernetes.io` 이외의 모든 도메인 이름 접두사를 사용할 수 있다. +{{< /note >}} + +파드에서 확장된 리소스를 사용하려면, 컨테이너 사양에서 `spec.containers[].resources.limits` +맵에 리소스 이름을 키로 포함한다. + +{{< note >}} +확장된 리소스는 오버커밋할 수 없으므로, 컨테이너 사양에 +둘 다 있으면 요청과 제한이 동일해야 한다. +{{< /note >}} + +파드는 CPU, 메모리 및 확장된 리소스를 포함하여 모든 리소스 요청이 +충족되는 경우에만 예약된다. 리소스 요청을 충족할 수 없다면 +파드는 `PENDING` 상태를 유지한다. + +**예제:** + +아래의 파드는 2개의 CPU와 1개의 "example.com/foo"(확장된 리소스)를 요청한다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + containers: + - name: my-container + image: myimage + resources: + requests: + cpu: 2 + example.com/foo: 1 + limits: + example.com/foo: 1 +``` + +## 문제 해결 + +### 내 파드가 failedScheduling 이벤트 메시지로 보류 중이다 + +파드가 배치될 수 있는 노드를 스케줄러가 찾을 수 없으면, 노드를 +찾을 수 있을 때까지 파드는 스케줄되지 않은 상태로 유지한다. 스케줄러가 다음과 같이 +파드의 위치를 ​​찾지 못하면 이벤트가 생성된다. + +```shell +kubectl describe pod frontend | grep -A 3 Events +``` +``` +Events: + FirstSeen LastSeen Count From Subobject PathReason Message + 36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others +``` + +위의 예에서, 노드의 CPU 리소스가 충분하지 않아 이름이 +"frontend"인 파드를 스케줄하지 못했다. 비슷한 메시지로 +메모리 부족(PodExceedsFreeMemory)으로 인한 장애도 알릴 수 있다. 일반적으로, 파드가 +이 타입의 메시지로 보류 중인 경우, 몇 가지 시도해 볼 것들이 있다. + +- 클러스터에 더 많은 노드를 추가한다. +- 불필요한 파드를 종료하여 보류 중인 파드를 위한 공간을 확보한다. +- 파드가 모든 노드보다 크지 않은지 확인한다. 예를 들어, 모든 + 노드의 용량이 `cpu: 1` 인 경우, `cpu: 1.1` 요청이 있는 파드는 + 절대 스케줄되지 않는다. + +`kubectl describe nodes` 명령으로 노드 용량과 할당된 양을 +확인할 수 있다. 예를 들면, 다음과 같다. + +```shell +kubectl describe nodes e2e-test-node-pool-4lw4 +``` +``` +Name: e2e-test-node-pool-4lw4 +[ ... 명확하게 하기 위해 라인들을 제거함 ...] +Capacity: + cpu: 2 + memory: 7679792Ki + pods: 110 +Allocatable: + cpu: 1800m + memory: 7474992Ki + pods: 110 +[ ... 명확하게 하기 위해 라인들을 제거함 ...] +Non-terminated Pods: (5 in total) + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits + --------- ---- ------------ ---------- --------------- ------------- + kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%) + kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%) + kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%) + kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%) + kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%) +Allocated resources: + (Total limits may be over 100 percent, i.e., overcommitted.) + CPU Requests CPU Limits Memory Requests Memory Limits + ------------ ---------- --------------- ------------- + 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) +``` + +위의 출력에서, ​파드가 1120m 이상의 CPU 또는 6.23Gi의 메모리를 +요청하는 것은 노드에 맞지 않음을 알 수 있다. + +`Pods` 섹션을 살펴보면, 파드가 노드에서 공간을 차지하는 것을 +볼 수 있다. + +시스템 데몬이 사용 가능한 리소스의 일부를 사용하기 때문에, 파드에 +사용 가능한 리소스의 양이 노드 용량보다 적다. `allocatable` 필드 +[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)는 +파드가 사용할 수 있는 리소스의 양을 제공한다. 자세한 정보는 +[노드 할당 가능 리소스](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md)를 참조한다. + +[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/) 기능은 +소비될 수 있는 리소스의 총량을 제한하도록 구성할 수 있다. 네임스페이스와 +함께 사용하면, 한 팀이 모든 리소스를 사용하는 경우를 방지할 수 있다. + +### 내 컨테이너가 종료되었다 + +리소스가 부족하여 컨테이너가 종료될 수 있다. 리소스 +제한에 도달하여 컨테이너가 종료되고 있는지 확인하려면, +관심있는 파드에 대해 `kubectl describe pod` 를 호출한다. + +```shell +kubectl describe pod simmemleak-hra99 +``` +``` +Name: simmemleak-hra99 +Namespace: default +Image(s): saadali/simmemleak +Node: kubernetes-node-tf0f/10.240.216.66 +Labels: name=simmemleak +Status: Running +Reason: +Message: +IP: 10.244.2.75 +Replication Controllers: simmemleak (1/1 replicas created) +Containers: + simmemleak: + Image: saadali/simmemleak + Limits: + cpu: 100m + memory: 50Mi + State: Running + Started: Tue, 07 Jul 2015 12:54:41 -0700 + Last Termination State: Terminated + Exit Code: 1 + Started: Fri, 07 Jul 2015 12:54:30 -0700 + Finished: Fri, 07 Jul 2015 12:54:33 -0700 + Ready: False + Restart Count: 5 +Conditions: + Type Status + Ready False +Events: + FirstSeen LastSeen Count From SubobjectPath Reason Message + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a +``` + +앞의 예제에서, `Restart Count: 5` 표시는 파드의 `simmemleak` +컨테이너가 종료되고 5번 다시 시작되었음을 나타낸다. + +이전에 종료된 컨테이너의 상태를 가져오기 위해 `-o go-template=...` 옵션을 사용해서 +`kubectl get pod` 를 호출할 수 있다. + +```shell +kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99 +``` +``` +Container Name: simmemleak +LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]] +``` + +컨테이너가 `reason:OOM Killed`(`OOM` 은 메모리 부족(Out Of Memory)의 약자) 때문에 종료된 것을 알 수 있다. + + + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* [컨테이너와 파드에 메모리 리소스를 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는 핸즈온 경험을 해보자. + +* [컨테이너와 파드에 CPU 리소스를 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)하는 핸즈온 경험을 해보자. + +* 요청과 제한의 차이점에 대한 자세한 내용은, + [리소스 QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md)를 참조한다. + +* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) API 레퍼런스 읽어보기 + +* [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API 레퍼런스 읽어보기 + +* XFS의 [프로젝트 쿼터](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기 + +{{% /capture %}} diff --git a/content/ko/docs/concepts/configuration/pod-overhead.md b/content/ko/docs/concepts/configuration/pod-overhead.md new file mode 100644 index 0000000000..c5efc58c1e --- /dev/null +++ b/content/ko/docs/concepts/configuration/pod-overhead.md @@ -0,0 +1,193 @@ +--- +title: 파드 오버헤드 +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +노드 위에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다. +이러한 리소스는 파드 내의 컨테이너들을 구동하기 위한 리소스 이외에 추가적으로 필요한 것이다. +_파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해 +소비되는 리소스를 계산하는 기능이다. + + +{{% /capture %}} + + +{{% capture body %}} + +쿠버네티스에서 파드의 오버헤드는 파드의 +[런타임클래스](/ko/docs/concepts/containers/runtime-class/) 와 관련된 오버헤드에 따라 +[어드미션](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) +이 수행될 때 지정된다. + +파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에 +파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, Kubelet은 파드의 cgroups 크기를 변경하거나 +파드의 축출 등급을 부여할 때에도 파드의 오버헤드를 포함하여 고려한다. + +## 파드 오버헤드 활성화하기 {#set-up} + +기능 활성화를 위해 클러스터에서 +`PodOverhead` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 가 활성화 되어 있고 (1.18 버전에서는 기본적으로 활성화), +`overhead` 필드를 정의하는 `RuntimeClass` 가 사용되고 있는지 확인해야 한다. + +## 사용 예제 + +파드 오버헤드 기능을 사용하기 위하여, `overhead` 필드를 정의하는 런타임클래스가 필요하다. +예를 들어, 가상 머신 및 게스트 OS에 대하여 파드 당 120 MiB를 사용하는 +가상화 컨테이너 런타임의 런타임클래스의 경우 다음과 같이 정의 할 수 있다. + +```yaml +--- +kind: RuntimeClass +apiVersion: node.k8s.io/v1beta1 +metadata: + name: kata-fc +handler: kata-fc +overhead: + podFixed: + memory: "120Mi" + cpu: "250m" +``` + +`kata-fc` 런타임클래스 핸들러를 지정하는 워크로드는 리소스 쿼터 계산, +노드 스케줄링 및 파드 cgroup 크기 조정을 위하여 메모리와 CPU 오버헤드를 고려한다. + +주어진 예제 워크로드 test-pod의 구동을 고려해보자. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pod +spec: + runtimeClassName: kata-fc + containers: + - name: busybox-ctr + image: busybox + stdin: true + tty: true + resources: + limits: + cpu: 500m + memory: 100Mi + - name: nginx-ctr + image: nginx + resources: + limits: + cpu: 1500m + memory: 100Mi +``` + +어드미션 수행 시에, [어드미션 컨트롤러](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)는 +런타임클래스에 기술된 `overhead` 를 포함하기 위하여 워크로드의 PodSpec 항목을 갱신한다. 만약 PodSpec이 이미 해당 필드에 정의되어 있으면, +파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가 +`overhead` 를 포함하도록 변경한다. + +런타임클래스의 어드미션 수행 후에, 파드의 스펙이 갱신된 것을 확인할 수 있다. + +```bash +kubectl get pod test-pod -o jsonpath='{.spec.overhead}' +``` + +명령 실행 결과는 다음과 같다. +``` +map[cpu:250m memory:120Mi] +``` + +만약 리소스쿼터 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는 +`overhead` 필드도 추가된다. + +kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 때, 파드의 `overhead` 와 +해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다. 이 예제에서, 스케줄러는 +리소스 요청과 파드의 오버헤드를 더하고, 2.25 CPU와 320 MiB 메모리가 사용 가능한 노드를 찾는다. + +일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다. +기본 컨테이너 런타임이 만들어내는 컨테이너들은 이 파드 안에 존재한다. + +만약 각 컨테이너에 대하여 QoS가 보장되었거나 향상이 가능하도록 QoS 의 리소스 상한 제한이 걸려있으면, +kubelet 은 해당 리소스(CPU의 경우 cpu.cfs_quota_us, 메모리의 경우 memory.limit_in_bytes)와 연관된 파드의 +cgroup 의 상한선을 설정한다. 이 상한선은 컨테이너 리소스 상한과 PodSpec에 +정의된 `overhead` 의 합에 기반한다. + +CPU의 경우, 만약 파드가 보장형 또는 버스트형 QoS로 설정되었으면, kubelet은 PodSpec에 정의된 `overhead` 에 컨테이너의 +리소스 요청의 합을 더한 값을 `cpu.shares` 로 설정한다. + +다음의 예제를 참고하여, 워크로드에 대하여 컨테이너의 리소스 요청을 확인하자. +```bash +kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' +``` + +컨테이너 리소스 요청의 합은 각각 CPU 2000m 와 메모리 200MiB 이다. +``` +map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] +``` + +노드에서 측정된 내용과 비교하여 확인해보자. + +```bash +kubectl describe node | grep test-pod -B2 +``` + +CPU 2250m와 메모리 320MiB 가 리소스로 요청되었으며, 이 결과는 파드의 오버헤드를 포함한다. +``` + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE + --------- ---- ------------ ---------- --------------- ------------- --- + default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m +``` + +## 파드 cgroup 상한 확인하기 + +워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인 해보자. 다음의 예제에서, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며, +CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다. +파드의 오버헤드 동작을 보여주는 좋은 예이며, +사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다. + +먼저 특정 노드에서 파드의 식별자를 확인해 보자. + +```bash +# 파드가 스케줄 된 노드에서 이것을 실행 +POD_ID="$(sudo crictl pods --name test-pod -q)" +``` + +여기에서, 파드의 cgroup 경로를 확인할 수 있다. +```bash +# 파드가 스케줄 된 노드에서 이것을 실행 +sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath +``` + +명령의 결과로 나온 cgroup 경로는 파드의 `pause` 컨테이너를 포함한다. 파드 레벨의 cgroup은 하나의 디렉터리이다. +``` + "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" +``` + +아래의 특정한 경우에, 파드 cgroup 경로는 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2` 이다. 메모리의 파드 레벨 cgroup 설정을 확인하자. +```bash +# 파드가 스케줄 된 노드에서 이것을 실행. +# 또한 사용자의 파드에 할당된 cgroup 이름에 맞춰 해당 이름을 수정. + cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes +``` + +예상대로 320 MiB 이다. +``` +335544320 +``` + +### 관찰성 +`kube_pod_overhead` 항목은 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) +에서 사용할 수 있어, 파드 오버헤드가 사용되는 시기를 식별하고, +정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다. +이 기능은 kube-state-metrics 의 1.9 릴리스에서는 사용할 수 없지만, 다음 릴리스에서는 가능할 예정이다. +그 전까지는 소스로부터 kube-state-metric 을 빌드해야 한다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [런타임클래스](/ko/docs/concepts/containers/runtime-class/) +* [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) + +{{% /capture %}} diff --git a/content/ko/docs/concepts/configuration/pod-priority-preemption.md b/content/ko/docs/concepts/configuration/pod-priority-preemption.md new file mode 100644 index 0000000000..a69013f5bd --- /dev/null +++ b/content/ko/docs/concepts/configuration/pod-priority-preemption.md @@ -0,0 +1,417 @@ +--- +title: 파드 우선순위(priority)와 선점(preemption) +content_template: templates/concept +weight: 70 +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + +[파드](/ko/docs/concepts/workloads/pods/pod/)는 _우선순위_ 를 가질 수 있다. 우선순위는 +다른 파드에 대한 상대적인 파드의 중요성을 나타낸다. 파드를 스케줄링할 수 없는 경우, +스케줄러는 우선순위가 낮은 파드를 선점(축출)하여 보류 중인 파드를 +스케줄링할 수 있게 한다. + +{{% /capture %}} + +{{% capture body %}} + + +{{< warning >}} +모든 사용자를 신뢰할 수 없는 클러스터에서, 악의적인 사용자가 우선순위가 +가장 높은 파드를 생성하여 다른 파드가 축출되거나 스케줄링되지 +않을 수 있다. +관리자는 리소스쿼터를 사용하여 사용자가 우선순위가 높은 파드를 생성하지 +못하게 할 수 있다. + +자세한 내용은 [기본적으로 프라이어리티 클래스(Priority Class) 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 +참고한다. +{{< /warning >}} + +## 우선순위와 선점을 사용하는 방법 + +우선순위와 선점을 사용하려면 다음을 참고한다. + +1. 하나 이상의 [프라이어리티클래스](#프라이어리티클래스)를 추가한다. + +1. 추가된 프라이어리티클래스 중 하나에 [`priorityClassName`](#파드-우선순위)이 설정된 + 파드를 생성한다. 물론 파드를 직접 생성할 필요는 없다. + 일반적으로 디플로이먼트와 같은 컬렉션 오브젝트의 파드 템플릿에 `priorityClassName` + 을 추가한다. + +이 단계에 대한 자세한 내용은 계속 읽어보자. + +{{< note >}} +쿠버네티스는 이미 `system-cluster-critical` 과 `system-node-critical`, +두 개의 프라이어리티클래스를 제공한다. +이들은 일반적인 클래스이며 [중요한(critical) 컴포넌트가 항상 먼저 스케줄링이 되도록 하는 데](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 사용된다. +{{< /note >}} + +기능을 사용해 본 후 사용하지 않기로 했다면, PodPriority +커맨드-라인 플래그를 제거하거나 `false` 로 설정한 후, API 서버와 +스케줄러를 다시 시작해야 한다. 기능이 비활성화된 후, 기존 파드는 +우선순위 필드를 유지하지만, 선점은 비활성화되며, 우선순위 필드는 +무시된다. 이 기능이 비활성화되면, 새로운 파드에서 `priorityClassName` 을 설정할 수 +없다. + +## 선점을 비활성화하는 방법 + +{{< caution >}} +중요 파드는 클러스터에 리소스 압박(resource pressure)이 가해지면 +스케줄러 선점에 따라 스케줄링된다. 이런 이유로, 선점을 비활성화하지 +않는 것을 권장한다. +{{< /caution >}} + +{{< note >}} +쿠버네티스 1.15 이상에서, `NonPreemptingPriority` 기능이 활성화된 경우, +프라이어리티클래스는 옵션을 `preemptionPolicy: Never` 로 설정할 수 있다. +이렇게 하면 해당 프라이어리티클래스의 파드가 다른 파드를 축출할 수 없다. +{{< /note >}} + +선점은 기본값이 `false`로 설정된 `disablePreemption` kube-scheduler +플래그에 의해 제어된다. +위의 주의에도 불구하고 선점을 비활성화하려는 경우, +`disablePreemption` 을 `true` 로 설정할 수 있다. + +이 옵션은 컴포넌트 구성에서만 사용할 수 있으며 +이전 스타일의 커맨드 라인 옵션에서는 사용할 수 없다. 다음은 선점을 비활성화하는 샘플 컴포넌트 +구성이다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1alpha1 +kind: KubeSchedulerConfiguration +algorithmSource: + provider: DefaultProvider + +... + +disablePreemption: true +``` + +## 프라이어리티클래스 + +프라이어리티클래스는 프라이어리티 클래스 이름에서 우선순위의 정수 값으로의 매핑을 +정의하는 네임스페이스가 아닌(non-namespaced) 오브젝트이다. 이름은 +프라이어리티클래스 오브젝트의 메타데이터의 `name` 필드에 지정된다. 값은 +필수 `value` 필드에 지정되어 있다. 값이 클수록, 우선순위가 +높다. +프라이어리티클래스 오브젝트의 이름은 유효한 +[DNS 서브 도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 하며, +`system-` 접두사를 붙일 수 없다. + +프라이어리티클래스 오브젝트는 10억 이하의 32비트 정수 값을 가질 +수 있다. 일반적으로 선점하거나 축출해서는 안되는 중요한 시스템 파드에는 더 큰 숫자가 +예약되어 있다. 클러스터 관리자는 원하는 각 매핑에 대해 프라이어리티클래스 오브젝트를 +하나씩 생성해야 한다. + +프라이어리티클래스에는 `globalDefault` 와 `description` 두 개의 선택적인 필드도 있다. +`globalDefault` 필드는 이 프라이어리티클래스의 값을 `priorityClassName` 이 없는 +파드에 사용해야 함을 나타낸다. 시스템에서 `globalDefault` 가 `true` 로 설정된 +프라이어리티클래스는 하나만 존재할 수 있다. `globalDefault` 가 설정된 +프라이어리티클래스가 없을 경우, `priorityClassName` 이 없는 파드의 +우선순위는 0이다. + +`description` 필드는 임의의 문자열이다. 이 필드는 이 프라이어리티클래스를 언제 +사용해야 하는지를 클러스터 사용자에게 알려주기 위한 것이다. + +### PodPriority와 기존 클러스터에 대한 참고 사항 + +- 기존 클러스터를 업그레이드하고 이 기능을 활성화하면, 기존 파드의 + 우선순위는 사실상 0이다. + +- `globalDefault` 가 `true` 로 설정된 프라이어리티클래스를 추가해도 기존 파드의 + 우선순위는 변경되지 않는다. 이러한 프라이어리티클래스의 값은 + 프라이어리티클래스를 추가한 후 생성된 파드에만 사용된다. + +- 프라이어리티클래스를 삭제하면, 삭제된 프라이어리티클래스의 이름을 사용하는 + 기존 파드는 변경되지 않고 남아있지만, 삭제된 프라이어리티클래스의 이름을 + 사용하는 파드는 더 이상 생성할 수 없다. + +### 프라이어리티클래스 예제 + +```yaml +apiVersion: scheduling.k8s.io/v1 +kind: PriorityClass +metadata: + name: high-priority +value: 1000000 +globalDefault: false +description: "이 프라이어리티 클래스는 XYZ 서비스 파드에만 사용해야 한다." +``` + +## 비-선점 프라이어리티클래스 {#non-preempting-priority-class} + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +`PreemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의 +앞쪽에 배치되지만, +그 파드는 다른 파드를 축출할 수 없다. +스케줄링 대기 중인 비-선점 파드는 충분한 리소스가 확보되고 +스케줄링될 수 있을 때까지 +스케줄링 대기열에 대기한다. +다른 파드와 마찬가지로, +비-선점 파드는 +스케줄러 백오프(back-off)에 종속된다. +이는 스케줄러가 이러한 파드를 스케줄링하려고 시도하고 스케줄링할 수 없는 경우, +더 적은 횟수로 재시도하여, +우선순위가 낮은 다른 파드를 미리 스케줄링할 수 있음을 의미한다. + +비-선점 파드는 다른 우선순위가 높은 파드에 의해 +축출될 수 있다. + +`PreemptionPolicy` 는 기본값으로 `PreemptLowerPriority` 로 설정되어, +해당 프라이어리티클래스의 파드가 우선순위가 낮은 파드를 축출할 수 +있다(기존의 기본 동작과 동일). +`PreemptionPolicy` 가 `Never` 로 설정된 경우, +해당 프라이어리티클래스의 파드는 비-선점될 것이다. + +`PreemptionPolicy` 필드를 사용하려면 `NonPreemptingPriority` +[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 +활성화되어야 한다. + +예제 유스케이스는 데이터 과학 관련 워크로드이다. +사용자는 다른 워크로드보다 우선순위가 높은 잡(job)을 제출할 수 있지만, +실행 중인 파드를 축출하여 기존의 작업을 삭제하지는 않을 것이다. +클러스터 리소스가 "자연스럽게" 충분히 사용할 수 있게 되면, +`PreemptionPolicy: Never` 의 우선순위가 높은 잡이 +다른 대기 중인 파드보다 먼저 스케줄링된다. + +### 비-선점 프라이어리티클래스 예제 + +```yaml +apiVersion: scheduling.k8s.io/v1 +kind: PriorityClass +metadata: + name: high-priority-nonpreempting +value: 1000000 +preemptionPolicy: Never +globalDefault: false +description: "이 프라이어리티 클래스는 다른 파드를 축출하지 않는다." +``` + +## 파드 우선순위 + +프라이어리티클래스가 하나 이상 있으면, 그것의 명세에서 이들 프라이어리티클래스 이름 중 하나를 +지정하는 파드를 생성할 수 있다. 우선순위 어드미션 +컨트롤러는 `priorityClassName` 필드를 사용하고 우선순위의 정수 값을 +채운다. 프라이어리티 클래스를 찾을 수 없으면, 파드가 거부된다. + +다음의 YAML은 이전 예제에서 생성된 프라이어리티클래스를 +사용하는 파드 구성의 예이다. 우선순위 어드미션 컨트롤러는 +명세를 확인하고 파드의 우선순위를 1000000으로 +해석한다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + env: test +spec: + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + priorityClassName: high-priority +``` + +### 스케줄링 순서에 대한 파드 우선순위의 영향 + +파드 우선순위가 활성화되면, 스케줄러가 우선순위에 따라 보류 중인 +파드를 주문하고 보류 중인 파드는 스케줄링 대기열에서 +우선순위가 낮은 다른 보류 중인 파드보다 우선한다. 결과적으로, 스케줄링 +요구 사항이 충족되는 경우 우선순위가 더 낮은 파드보다 우선순위가 높은 파드가 +더 빨리 스케줄링될 수 있다. 이러한 파드를 스케줄링할 수 없는 경우, +스케줄러는 계속 진행하고 우선순위가 낮은 다른 파드를 스케줄링하려고 한다. + +## 선점 + +파드가 생성되면, 대기열로 이동하여 스케줄링을 기다린다. +스케줄러가 대기열에서 파드를 선택하여 노드에 스케줄링하려고 한다. +파드의 지정된 모든 요구 사항을 충족하는 노드가 없으면, +보류 중인 파드에 대해 선점 로직이 트리거된다. 보류 중인 파드를 P라 하자. +선점 로직은 P보다 우선순위가 낮은 하나 이상의 파드를 제거하면 +해당 노드에서 P를 스케줄링할 수 있는 노드를 찾는다. 이러한 +노드가 발견되면, 하나 이상의 우선순위가 낮은 파드가 노드에서 축출된다. +파드가 축출된 후, P는 노드에 스케줄링될 수 있다. + +### 사용자 노출 정보 + +파드 P가 노드 N에서 하나 이상의 파드를 축출할 경우, 파드 P의 상태 `nominatedNodeName` +필드는 노드 N의 이름으로 설정된다. 이 필드는 스케줄러가 파드 P에 +예약된 리소스를 추적하는 데 도움이 되고 사용자에게 클러스터의 선점에 대한 +정보를 제공한다. + +파드 P는 반드시 "지정된 노드"로 스케줄링되지는 않는다. +피해자 파드가 축출된 후, 그것은 정상적(graceful)으로 종료되는 기간을 갖는다. +스케줄러가 종료될 피해자 파드를 기다리는 동안 다른 노드를 사용할 수 +있게 되면, 스케줄러는 파드 P를 스케줄링하기 위해 다른 노드를 사용한다. 그 결과, +파드 스펙의 `nominatedNodeName` 과 `nodeName` 은 항상 동일하지 않다. 또한, +스케줄러가 노드 N에서 파드를 축출했지만, 파드 P보다 우선순위가 높은 파드가 +도착하면, 스케줄러가 노드 N에 새로운 우선순위가 높은 파드를 제공할 수 있다. 이러한 +경우, 스케줄러는 파드 P의 `nominatedNodeName` 을 지운다. 이렇게하면, 스케줄러는 +파드 P가 다른 노드에서 파드를 축출할 수 있도록 한다. + +### 선점의 한계 + +#### 선점 피해자의 정상적인 종료 + +파드가 축출되면, 축출된 피해자 파드는 +[정상적인 종료 기간](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)을 가진다. +피해자 파드는 작업을 종료하고 빠져나가는 데(exit) 많은 시간을 가진다. 그렇지 않으면, +파드는 강제종료(kill) 된다. 이 정상적인 종료 기간은 스케줄러가 파드를 축출하는 +지점과 보류 중인 파드(P)를 노드(N)에서 스케줄링할 수 있는 시점 사이의 +시간 간격을 만든다. 그 동안, 스케줄러는 보류 중인 다른 파드를 +계속 스케줄링한다. 피해자 파드가 빠져나가거나 종료되면, 스케줄러는 보류 대기열에서 +파드를 스케줄하려고 한다. 따라서, 일반적으로 스케줄러가 피해자 파드를 축출하는 시점과 +파드 P가 스케줄링된 시점 사이에 시간 간격이 있다. +이러한 차이를 최소화하기 위해, 우선순위가 낮은 파드의 정상적인 종료 기간을 0 또는 +작은 수로 설정할 수 있다. + +#### PodDisruptionBudget을 지원하지만, 보장하지 않음 + +[Pod Disruption Budget(PDB)](/ko/docs/concepts/workloads/pods/disruptions/)은 +애플리케이션 소유자가 자발적 중단에서 동시에 다운된 복제된 +애플리케이션의 파드 수를 제한할 수 있다. 쿠버네티스는 파드를 +선점할 때 PDB를 지원하지만, PDB를 따르는 것이 최선의 노력이다. 스케줄러는 +선점에 의해 PDB를 위반하지 않은 피해자 파드를 찾으려고 하지만, 그러한 피해자 파드가 +발견되지 않으면, 선점은 여전히 발생하며, PDB를 위반하더라도 우선순위가 +낮은 파드는 제거된다. + +#### 우선순위가 낮은 파드에 대한 파드-간 어피니티 + +이 질문에 대한 답변이 '예'인 경우에만 노드가 선점 대상으로 간주된다. +"대기 중인 파드보다 우선순위가 낮은 모든 파드가 노드에서 +제거되면, 보류 중인 파드를 노드에 스케줄링할 수 있습니까?" + +{{< note >}} +선점으로 우선순위가 낮은 모든 파드를 반드시 제거할 필요는 +없다. 우선순위가 낮은 모든 파드보다 적은 수를 제거하여 보류 중인 파드를 +스케줄링할 수 있는 경우, 우선순위가 낮은 파드의 일부만 제거된다. +그럼에도 불구하고, 앞의 질문에 대한 대답은 '예'여야 한다. 답변이 '아니오'인 경우, +노드가 선점 대상으로 간주되지 않는다. +{{< /note >}} + +보류 중인 파드가 노드에 있는 하나 이상의 우선순위가 낮은 파드에 대한 파드-간 어피니티를 +가진 경우에, 우선순위가 낮은 파드가 없을 때 파드-간 어피니티 규칙을 +충족할 수 없다. 이 경우, 스케줄러는 노드의 파드를 축출하지 +않는다. 대신, 다른 노드를 찾는다. 스케줄러가 +적합한 노드를 찾거나 찾지 못할 수 있다. 보류 중인 파드를 스케줄링할 수 있다는 +보장은 없다. + +이 문제에 대한 권장 솔루션은 우선순위가 같거나 높은 파드에 대해서만 파드-간 어피니티를 +생성하는 것이다. + +#### 교차 노드 선점 + +보류 중인 파드 P가 노드 N에 스케줄링될 수 있도록 노드 N이 선점 대상으로 고려되고 +있다고 가정한다. 다른 노드의 파드가 축출된 경우에만 P가 N에서 실행 가능해질 수 +있다. 예를 들면 다음과 같다. + +* 파드 P는 노드 N에 대해 고려된다. +* 파드 Q는 노드 N과 동일한 영역의 다른 노드에서 실행 중이다. +* 파드 P는 파드 Q(`topologyKey: + failure-domain.beta.kubernetes.io/zone`)와 영역(zone) 전체의 안티-어피니티를 갖는다. +* 영역에서 파드 P와 다른 파드 간의 안티-어피니티에 대한 다른 경우는 + 없다. +* 노드 N에서 파드 P를 스케줄링하기 위해, 파드 Q를 축출할 수 있지만, 스케줄러는 + 교차-노드 선점을 수행하지 않는다. 따라서, 파드 P가 노드 N에서 + 스케줄링할 수 없는 것으로 간주된다. + +파드 Q가 노드에서 제거되면, 파드 안티-어피니티 위반이 +사라지고, 파드 P는 노드 N에서 스케줄링될 수 있다. + +수요가 충분하고 합리적인 성능의 알고리즘을 찾을 경우 +향후 버전에서 교차 노드 선점의 추가를 고려할 수 있다. + +## 문제 해결 + +파드 우선순위와 선점은 원하지 않는 부작용을 가질 수 있다. 다음은 +잠재적 문제의 예시와 이를 해결하는 방법이다. + +### 파드가 불필요하게 선점(축출)됨 + +선점은 우선순위가 높은 보류 중인 파드를 위한 공간을 만들기 위해 리소스 압박을 받고 있는 +클러스터에서 기존 파드를 제거한다. 실수로 특정 파드에 높은 우선순위를 +부여하면, 의도하지 않은 높은 우선순위 파드가 클러스터에서 +선점을 유발할 수 있다. 파드 우선순위는 파드 명세에서 +`priorityClassName` 필드를 설정하여 지정한다. 그런 다음 +우선순위의 정수 값이 분석되어 `podSpec` 의 `priority` 필드에 채워진다. + +문제를 해결하기 위해, 해당 파드가 우선순위가 낮은 클래스를 사용하도록 `priorityClassName` 을 +변경하거나, 해당 필드를 비워둘 수 있다. 빈 +`priorityClassName` 은 기본값이 0으로 해석된다. + +파드가 축출되면, 축출된 파드에 대한 이벤트가 기록된다. +선점은 클러스터가 파드에 대한 리소스를 충분히 가지지 못한 경우에만 +발생한다. 이러한 경우, 선점은 보류 중인 파드(선점자)의 우선순위가 +피해자 파드보다 높은 경우에만 발생한다. 보류 중인 파드가 없거나, +보류 중인 파드의 우선순위가 피해자 파드와 같거나 낮은 경우 +선점이 발생하지 않아야 한다. 그러한 시나리오에서 선점이 발생하면, 이슈를 올리기 바란다. + +### 파드가 축출되었지만, 선점자는 스케줄링되지 않음 + +파드가 축출되면, 요청된 정상적인 종료 +기간(기본적으로 30초)이 주어진다. 이 기간 내에 대상 파드가 +종료되지 않으면, 강제 종료된다. 모든 피해자 파드가 사라지면, +선점자 파드를 스케줄링할 수 있다. + +선점자 파드가 피해자 파드가 없어지기를 기다리는 동안, 동일한 노드에 +적합한 우선순위가 높은 파드가 생성될 수 있다. 이 경우, 스케줄러는 +선점자 대신 우선순위가 높은 파드를 스케줄링한다. + +이것은 예상된 동작이다. 우선순위가 높은 파드는 우선순위가 낮은 파드를 +대체해야 한다. [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)과 +같은 다른 컨트롤러 작업은, +결국 보류 중인 파드를 스케줄링할 수 있는 용량을 제공할 수 있다. + +### 우선순위가 높은 파드는 우선순위가 낮은 파드보다 우선함 + +스케줄러가 보류 중인 파드를 실행할 수 있는 노드를 찾으려고 한다. 노드를 찾지 +못하면, 스케줄러는 임의의 노드에서 우선순위가 낮은 파드를 제거하여 +보류 중인 파드를 위한 공간을 만든다. +우선순위가 낮은 파드가 있는 노드가 보류 중인 파드를 실행할 수 없는 경우, 스케줄러는 +선점을 위해 우선순위가 높은 다른 노드(다른 노드의 파드와 비교)를 +선택할 수 있다. 피해자 파드는 여전히 선점자 파드보다 우선순위가 +낮아야 한다. + +선점할 수 있는 여러 노드가 있는 경우, 스케줄러는 +우선순위가 가장 낮은 파드 세트를 가진 노드를 선택하려고 한다. 그러나, +이러한 파드가 위반될 PodDisruptionBudget을 가지고 있고 축출된 경우 +스케줄러는 우선순위가 높은 파드를 가진 다른 노드를 선택할 수 있다. + +선점을 위해 여러 개의 노드가 존재하고 위의 시나리오 중 어느 것도 적용되지 않는 경우, +스케줄러는 우선순위가 가장 낮은 노드를 선택한다. + +## 파드 우선순위와 서비스 품질 간의 상호 작용 {#interactions-of-pod-priority-and-qos} + +파드 우선순위와 {{< glossary_tooltip text="QoS 클래스" term_id="qos-class" >}}는 +상호 작용이 거의 없고 QoS 클래스를 기반으로 파드 우선순위를 설정하는 데 대한 +기본 제한이 없는 두 개의 직교(orthogonal) 기능이다. 스케줄러의 +선점 로직은 선점 대상을 선택할 때 QoS를 고려하지 않는다. +선점은 파드 우선순위를 고려하고 우선순위가 가장 낮은 대상 세트를 +선택하려고 한다. 우선순위가 가장 높은 파드는 스케줄러가 +선점자 파드를 스케줄링할 수 없거나 우선순위가 가장 낮은 파드가 +`PodDisruptionBudget` 으로 보호되는 경우에만, 우선순위가 가장 낮은 파드를 +축출 대상으로 고려한다. + +QoS와 파드 우선순위를 모두 고려하는 유일한 컴포넌트는 +[kubelet 리소스 부족 축출](/docs/tasks/administer-cluster/out-of-resource/)이다. +kubelet은 부족한 리소스의 사용이 요청을 초과하는지 여부에 따라, 그런 다음 우선순위에 따라, +파드의 스케줄링 요청에 대한 부족한 컴퓨팅 리소스의 소비에 의해 +먼저 축출 대상 파드의 순위를 매긴다. +더 자세한 내용은 +[엔드유저 파드 축출](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)을 +참조한다. + +kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 경우 +파드를 축출하지 않는다. 우선순위가 낮은 파드가 요청을 +초과하지 않으면, 축출되지 않는다. 요청을 초과하는 우선순위가 +더 높은 다른 파드가 축출될 수 있다. + +{{% /capture %}} +{{% capture whatsnext %}} +* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자. +{{% /capture %}} diff --git a/content/ko/docs/concepts/configuration/resource-bin-packing.md b/content/ko/docs/concepts/configuration/resource-bin-packing.md index 976e2ec837..5b6af1c661 100644 --- a/content/ko/docs/concepts/configuration/resource-bin-packing.md +++ b/content/ko/docs/concepts/configuration/resource-bin-packing.md @@ -1,7 +1,7 @@ --- title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing) content_template: templates/concept -weight: 10 +weight: 50 --- {{% capture overview %}} diff --git a/content/ko/docs/concepts/configuration/taint-and-toleration.md b/content/ko/docs/concepts/configuration/taint-and-toleration.md index 012924c75d..ed59926d17 100644 --- a/content/ko/docs/concepts/configuration/taint-and-toleration.md +++ b/content/ko/docs/concepts/configuration/taint-and-toleration.md @@ -198,7 +198,7 @@ tolerations: ## 테인트 기반 축출 -{{< feature-state for_k8s_version="1.18" state="stable" >}} +{{< feature-state for_k8s_version="v1.18" state="stable" >}} 앞에서 우리는 노드에서 이미 실행 중인 파드에 영향을 주는 `NoExecute` 테인트 이펙트를 다음과 같이 언급했다. diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index e7e380d6ba..84481bdec7 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -78,7 +78,7 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트 - 클라이언트는 "이 작업을 수행한다"라고 말하고 완료되면 동기(synchronous) 응답을 받는다. - 클라이언트는 "이 작업을 수행한다"라고 말한 다음 작업 ID를 다시 가져오고 별도의 오퍼레이션(operation) 오브젝트를 확인하여 요청의 완료 여부를 결정해야 한다. - RPC(원격 프로시저 호출)에 대해 얘기한다. - - 대량의 데이터를 직접 저장한다(예: > 오브젝트별 몇 kB 또는 >1000개의 오브젝트). + - 대량의 데이터를 직접 저장한다. 예: > 오브젝트별 몇 kB 또는 > 1000개의 오브젝트. - 높은 대역폭 접근(초당 10개의 지속적인 요청)이 필요하다. - 최종 사용자 데이터(예: 이미지, PII 등) 또는 애플리케이션에서 처리한 기타 대규모 데이터를 저장한다. - 오브젝트에 대한 자연스러운 조작은 CRUD-y가 아니다. @@ -102,7 +102,7 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트 다음 중 대부분이 적용되는 경우 커스텀 리소스(CRD 또는 애그리게이트 API(aggregated API))를 사용하자. * 쿠버네티스 클라이언트 라이브러리 및 CLI를 사용하여 새 리소스를 만들고 업데이트하려고 한다. -* kubectl의 최상위 지원을 원한다(예: `kubectl get my-object object-name`). +* `kubectl` 의 최상위 지원을 원한다. 예: `kubectl get my-object object-name`. * 새 오브젝트에 대한 업데이트를 감시한 다음 다른 오브젝트를 CRUD하거나 그 반대로 하는 새로운 자동화를 구축하려고 한다. * 오브젝트의 업데이트를 처리하는 자동화를 작성하려고 한다. * `.spec`, `.status` 및 `.metadata`와 같은 쿠버네티스 API 규칙을 사용하려고 한다. @@ -214,7 +214,7 @@ CRD 또는 AA를 통해 커스텀 리소스를 생성하면 쿠버네티스 플 ### 써드파티 코드 및 새로운 장애 포인트 -CRD를 생성해도 새로운 장애 포인트(예를 들어, API 서버에서 장애를 유발하는 써드파티 코드가 실행됨)가 자동으로 추가되지는 않지만, 패키지(예: 차트(Charts)) 또는 기타 설치 번들에는 CRD 및 새로운 커스텀 리소스에 대한 비즈니스 로직을 구현하는 써드파티 코드의 디플로이먼트가 포함되는 경우가 종종 있다. +CRD를 생성해도 새로운 장애 포인트(예를 들어, API 서버에서 장애를 유발하는 써드파티 코드가 실행됨)가 자동으로 추가되지는 않지만, 패키지(예: 차트(Charts)) 또는 기타 설치 번들에는 CRD 및 새로운 커스텀 리소스에 대한 비즈니스 로직을 구현하는 써드파티 코드의 디플로이먼트가 포함되는 경우가 종종 있다. 애그리게이트 API 서버를 설치하려면 항상 새 디플로이먼트를 실행해야 한다. @@ -234,11 +234,11 @@ CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부 ## 커스텀 리소스에 접근 -쿠버네티스 [클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. Go와 python 클라이언트 라이브러리가 지원한다. +쿠버네티스 [클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. _Go_ 와 _python_ 클라이언트 라이브러리가 지원한다. 커스텀 리소스를 추가하면 다음을 사용하여 접근할 수 있다. -- kubectl +- `kubectl` - 쿠버네티스 동적 클라이언트 - 작성한 REST 클라이언트 - [쿠버네티스 클라이언트 생성 도구](https://github.com/kubernetes/code-generator)를 사용하여 생성된 클라이언트(하나를 생성하는 것은 고급 기능이지만, 일부 프로젝트는 CRD 또는 AA와 함께 클라이언트를 제공할 수 있다). diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 6fc04ab7bf..9db222e271 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -56,18 +56,19 @@ card: ### cloud-controller-manager -[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/)는 바탕을 이루는 클라우드 제공사업자와 상호작용하는 컨트롤러를 작동시킨다. cloud-controller-manager 바이너리는 쿠버네티스 릴리스 1.6에서 도입된 알파 기능이다. +cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다. +자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우 +클러스터에는 클라우드 컨트롤러 매니저가 없다. -cloud-controller-manager는 클라우드-제공사업자-특유 컨트롤러 루프만을 동작시킨다. 이 컨트롤러 루프는 kube-controller-manager에서 비활성 시켜야만 한다. kube-controller-manager를 구동시킬 때 `--cloud-provider` 플래그를 `external`로 설정함으로써 이 컨트롤러 루프를 비활성 시킬 수 있다. +kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적으로 +독립적인 여러 컨트롤 루프를 단일 프로세스로 실행하는 단일 바이너리로 결합한다. +수평으로 확장(두 개 이상의 복제 실행)해서 성능을 향상시키거나 장애를 견딜 수 있다. -cloud-controller-manager는 클라우드 벤더 코드와 쿠버네티스 코드가 서로 독립적으로 발전시켜 나갈 수 있도록 해준다. 이전 릴리스에서는 코어 쿠버네티스 코드가 기능상으로 클라우드-제공사업자-특유 코드에 대해 의존적이었다. 향후 릴리스에서 클라우드 벤더만의 코드는 클라우드 벤더가 유지해야 하며, 쿠버네티스가 동작하는 동안 cloud-controller-manager에 연계되도록 해야 한다. +다음 컨트롤러들은 클라우드 제공 사업자의 의존성을 가질 수 있다. -다음 컨트롤러들은 클라우드 제공사업자의 의존성을 갖는다. - - * 노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공사업자에게 확인하는 것 + * 노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인하는 것 * 라우트 컨트롤러: 기본 클라우드 인프라에 경로를 구성하는 것 - * 서비스 컨트롤러: 클라우드 제공사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것 - * 볼륨 컨트롤러: 볼륨의 생성, 연결 그리고 마운트 하는 것과 오케스트레이션하기 위해 클라우드 제공사업자와 상호작용하는 것 + * 서비스 컨트롤러: 클라우드 제공 사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것 ## 노드 컴포넌트 @@ -121,6 +122,6 @@ cloud-controller-manager는 클라우드 벤더 코드와 쿠버네티스 코드 {{% capture whatsnext %}} * [노드](/ko/docs/concepts/architecture/nodes/)에 대해 더 배우기 * [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 더 배우기 -* [kube-scheduler](/ko/docs/concepts/scheduling/kube-scheduler/)에 대해 더 배우기 +* [kube-scheduler](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 더 배우기 * etcd의 공식 [문서](https://etcd.io/docs/) 읽기 {{% /capture %}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md index c0e40eeec5..3028155e22 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -32,8 +32,8 @@ card: 원하는 특징(_의도한 상태_)에 대한 설명을 제공해서 설정한다. -`status`는 오브젝트의 _현재 상태_ 를 기술하고, 쿠버네티스 -컴포넌트에 의해 제공되고 업데이트 된다. 쿠버네티스 +`status` 는 쿠버네티스 시스템과 컴포넌트에 의해 제공되고 +업데이트된 오브젝트의 _현재 상태_ 를 설명한다. 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은 모든 오브젝트의 실제 상태를 사용자가 의도한 상태와 일치시키기 위해 끊임없이 그리고 능동적으로 관리한다. @@ -93,4 +93,3 @@ deployment.apps/nginx-deployment created * [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다. {{% /capture %}} - diff --git a/content/ko/docs/concepts/policy/limit-range.md b/content/ko/docs/concepts/policy/limit-range.md index e2588b33af..11356ed3ee 100644 --- a/content/ko/docs/concepts/policy/limit-range.md +++ b/content/ko/docs/concepts/policy/limit-range.md @@ -7,7 +7,7 @@ weight: 10 {{% capture overview %}} 기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 [컴퓨팅 리소스](/docs/user-guide/compute-resources)로 실행된다. -리소스 쿼터을 사용하면 클러스터 관리자는 네임스페이스별로 리소스 사용과 생성을 제한할 수 있다. +리소스 쿼터을 사용하면 클러스터 관리자는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}별로 리소스 사용과 생성을 제한할 수 있다. 네임스페이스 내에서 파드나 컨테이너는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있다. 리밋레인지는 네임스페이스에서 리소스 할당(파드 또는 컨테이너)을 제한하는 정책이다. {{% /capture %}} @@ -30,16 +30,16 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. 리밋레인지 오브젝트의 이름은 유효한 [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로 정의하라. @@ -49,19 +49,20 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. 경합이나 리밋레인지 변경은 이미 생성된 리소스에 영향을 미치지 않는다. -## 예제 - -- [네임스페이스당 최소 및 최대 CPU 제약 조건을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)을 본다. -- [네임스페이스당 최소 및 최대 메모리 제약 조건을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)을 본다. -- [네임스페이스당 기본 CPU 요청과 제한을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)을 본다. -- [네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/memory-default-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)를 참고하길 바란다. +자세한 내용은 [LimitRanger 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)를 참조한다. + +제한의 사용에 대한 예시는 다음을 참조한다. + +- [네임스페이스당 최소 및 최대 CPU 제약 조건을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/). +- [네임스페이스당 최소 및 최대 메모리 제약 조건을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/). +- [네임스페이스당 기본 CPU 요청과 제한을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/). +- [네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). +- [네임스페이스당 최소 및 최대 스토리지 사용량을 설정하는 방법](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage). +- [네임스페이스당 할당량을 설정하는 자세한 예시](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/). + {{% /capture %}} diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index d86685d986..4eeb59b510 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -193,7 +193,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. ### PriorityClass별 리소스 쿼터 -{{< feature-state for_k8s_version="1.12" state="beta" >}} +{{< feature-state for_k8s_version="v1.12" state="beta" >}} 특정 [우선 순위](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)로 파드를 생성할 수 있다. 쿼터 스펙의 `scopeSelector` 필드를 사용하여 파드의 우선 순위에 따라 파드의 시스템 리소스 사용을 diff --git a/content/ko/docs/concepts/scheduling-eviction/_index.md b/content/ko/docs/concepts/scheduling-eviction/_index.md new file mode 100644 index 0000000000..d368e230d7 --- /dev/null +++ b/content/ko/docs/concepts/scheduling-eviction/_index.md @@ -0,0 +1,4 @@ +--- +title: "스케줄링과 축출(eviction)" +weight: 90 +--- diff --git a/content/ko/docs/concepts/scheduling/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md similarity index 100% rename from content/ko/docs/concepts/scheduling/kube-scheduler.md rename to content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md diff --git a/content/ko/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md similarity index 100% rename from content/ko/docs/concepts/scheduling/scheduler-perf-tuning.md rename to content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md diff --git a/content/ko/docs/concepts/scheduling/_index.md b/content/ko/docs/concepts/scheduling/_index.md deleted file mode 100644 index 0ffab2ef77..0000000000 --- a/content/ko/docs/concepts/scheduling/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "스케줄링" -weight: 90 ---- - diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index fda1f15984..6dcbe57d58 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -140,8 +140,8 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 클라이언트와 먼저 TLS 핸드 셰이크를 수행하는 것이 이상적이다. 몇 가지 경우를 제외하고, 기본 동작은 전송 중인 모든 것을 암호화하는 것이다. 한걸음 더 나아가, VPC의 "방화벽 뒤"에서도 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication)를 통해 수행할 수 있다. 이것을 수행하기 위해 쿠버네티스에는 [Linkerd](https://linkerd.io/) 및 [Istio](https://istio.io/)와 같은 수많은 도구가 있다. | 통신 포트 범위 제한 | 이 권장사항은 당연할 수도 있지만, 가능하면 통신이나 메트릭 수집에 꼭 필요한 서비스의 포트만 노출시켜야 한다. | 타사 종속성 보안 | 애플리케이션은 자체 코드베이스의 외부에 종속적인 경향이 있기 때문에, 코드의 종속성을 정기적으로 스캔하여 현재 알려진 취약점이 없는지 확인하는 것이 좋다. 각 언어에는 이런 검사를 자동으로 수행하는 도구를 가지고 있다. | -정적 코드 분석 | 대부분 언어에는 잠재적으로 안전하지 않은 코딩 방법에 대해 코드 스니펫을 분석할 수 있는 방법을 제공한다. 가능한 언제든지 일반적인 보안 오류에 대해 코드베이스를 스캔할 수 있는 자동화된 도구를 사용하여 검사를 한다. 도구는 다음에서 찾을 수 있다: https://www.owasp.org/index.php/Source_Code_Analysis_Tools | -동적 탐지 공격 | 일반적으로 서비스에서 발생할 수 있는 잘 알려진 공격 중 일부를 서비스에 테스트할 수 있는 자동화된 몇 가지 도구가 있다. 이런 잘 알려진 공격에는 SQL 인젝션, CSRF 및 XSS가 포함된다. 가장 널리 사용되는 동적 분석 도구는 OWASP Zed Attack 프록시다. https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project | +정적 코드 분석 | 대부분 언어에는 잠재적으로 안전하지 않은 코딩 방법에 대해 코드 스니펫을 분석할 수 있는 방법을 제공한다. 가능한 언제든지 일반적인 보안 오류에 대해 코드베이스를 스캔할 수 있는 자동화된 도구를 사용하여 검사를 한다. 도구는 다음에서 찾을 수 있다. https://owasp.org/www-community/Source_Code_Analysis_Tools | +동적 탐지 공격 | 일반적으로 서비스에서 발생할 수 있는 잘 알려진 공격 중 일부를 서비스에 테스트할 수 있는 자동화된 몇 가지 도구가 있다. 이런 잘 알려진 공격에는 SQL 인젝션, CSRF 및 XSS가 포함된다. 가장 널리 사용되는 동적 분석 도구는 OWASP Zed Attack 프록시다. https://owasp.org/www-project-zap/ | ## 강력한(robust) 자동화 diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 91fbc782d7..db0abf1ede 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -164,7 +164,7 @@ DNS 정책은 파드별로 설정할 수 있다. 현재 쿠버네티스는 다 일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다. 클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다. 그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은 - [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods) + [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods) 에서 확인할 수 있다. - "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다. diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 85b6742b5f..5f6fbac267 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -652,6 +652,16 @@ metadata: [...] ``` {{% /tab %}} +{{% tab name="IBM Cloud" %}} +```yaml +[...] +metadata: + name: my-service + annotations: + service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private" +[...] +``` +{{% /tab %}} {{% tab name="OpenStack" %}} ```yaml [...] diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 66dd33d941..9f38f9f46c 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -296,12 +296,13 @@ parameters: `replication-type` 이 `regional-pd` 로 설정되면, [지역 퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks/#repds) -가 프로비전된다. 이 경우, 사용자는 `zone` 대신 `zones` 를 사용해서 원하는 -복제 영역을 지정해야 한다. 정확히 두 개의 영역이 지정된 경우, 해당 -영역에서 지역 PD가 프로비전된다. 둘 이상의 영역이 지정되면 -쿠버네티스는 지정된 영역 중에서 임의로 선택한다. `zones` 파라미터가 생략되면, -쿠버네티스는 클러스터가 관리하는 영역 중에서 -임의로 선택한다. +가 프로비전된다. 이는 퍼시스턴트볼륨클레임과 스토리지클래스를 소모하는 파드를 +생성할 때 지역 퍼시스턴트 디스크는 두개의 영역으로 +프로비전되기에 `volumeBindingMode: WaitForFirstConsumer` 를 +설정하는 것을 강력히 권장한다. 하나의 영역은 파드가 스케줄된 +영역과 동일하다. 다른 영역은 클러스터에서 사용할 수 +있는 영역에서 임의로 선택된다. 디스크 영역은 `allowedTopologies` 를 +사용하면 더 제한할 수 있다. {{< note >}} `zone` 과 `zones` 파라미터는 사용 중단 되었으며, diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index 534f3cf88b..60ad22c7cc 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -6,7 +6,7 @@ weight: 20 {{% capture overview %}} -{{< feature-state for_k8s_version="1.17" state="beta" >}} +{{< feature-state for_k8s_version="v1.17" state="beta" >}} 쿠버네티스에서 스토리지 시스템 볼륨 스냅샷은 _VolumeSnapshot_ 을 나타낸다. 이 문서는 이미 쿠버네티스 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다. {{% /capture %}} @@ -55,7 +55,9 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및 ### 스냅샷 소스 보호로서의 퍼시스턴트 볼륨 클레임 -이 보호의 목적은 스냅샷이 생성되는 동안 사용 중인 퍼시스턴트볼륨클레임 API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이터 손실이 발생할 수 있기 때문에). +이 보호의 목적은 스냅샷이 생성되는 동안 사용 중인 +{{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}} +API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이터 손실이 발생할 수 있기 때문에). 퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 객체를 삭제한다면, 퍼시스턴트볼륨클레임 객체는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 객체 삭제는 스냅샷이 준비(readyTouse) 혹은 중단(aborted) 상태가 될 때까지 연기된다. diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 0ad7755031..035b7bade7 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -9,7 +9,7 @@ weight: 10 컨테이너 내의 디스크에 있는 파일은 임시적이며, 컨테이너에서 실행될 때 애플리케이션에 적지 않은 몇 가지 문제가 발생한다. 첫째, 컨테이너가 충돌되면, kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상태로 -시작되기 때문에 기존 파일이 유실된다. 둘째, `파드` 에서 컨테이너를 함께 실행할 때 +시작되기 때문에 기존 파일이 유실된다. 둘째, `파드` 에서 컨테이너를 함께 실행할 때 컨테이너 사이에 파일을 공유해야 하는 경우가 자주 발생한다. 쿠버네티스의 `볼륨` 추상화는 이 두 가지 문제를 모두 해결한다. @@ -22,7 +22,7 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 ## 배경 -도커는 다소 느슨하고, 덜 관리되지만 +도커는 다소 느슨하고, 덜 관리되지만 [볼륨](https://docs.docker.com/engine/admin/volumes/)이라는 개념을 가지고 있다. 도커에서 볼륨은 단순한 디스크 내 디렉터리 또는 다른 컨테이너에 있는 디렉터리다. 수명은 관리되지 않으며 최근까지는 @@ -70,7 +70,7 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 * [csi](#csi) * [downwardAPI](#downwardapi) * [emptyDir](#emptydir) - * [fc (파이버 채널))](#fc) + * [fc (파이버 채널)](#fc) * [flexVolume](#flexVolume) * [flocker](#flocker) * [gcePersistentDisk](#gcepersistentdisk) @@ -496,7 +496,7 @@ gitRepo 볼륨 유형은 사용 중단(deprecated)되었다. git repo가 있는 `gitRepo` 볼륨은 볼륨 플러그인으로 할 수 있는 예시이다. 빈 디렉터리를 마운트하고 파드가 사용할 수 있도록 해당 디렉터리에 git 리포지트리를 -복제한다. 미래에는 모든 이용 사례에 대해 쿠버네티스 API를 확장하는 대신에 +복제한다. 미래에는 모든 이용 사례에 대해 쿠버네티스 API를 확장하는 대신에 이런 볼륨은 훨씬 더 분리된 모델로 이동될 수 있다. 여기 gitRepo 볼륨의 예시가 있다. @@ -1031,7 +1031,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토 ### storageOS {#storageos} -`storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com) +`storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com) 볼륨을 파드에 마운트할 수 있다. StorageOS 는 쿠버네티스 환경에서 컨테이너로 실행되므로 diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index b72607d41a..b06881c53f 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -8,13 +8,17 @@ weight: 80 {{< feature-state for_k8s_version="v1.8" state="beta" >}} -_크론 잡은_ 시간 기반의 일정에 따라 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 만든다. +_크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text="잡" >}}을 만든다. 하나의 크론잡 객체는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://en.wikipedia.org/wiki/Cron)형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. {{< caution >}} -모든 **크론잡** `일정:` 시간은 UTC로 표시된다. +모든 **크론잡** `일정:` 시간은 +{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}의 시간대를 기준으로 한다. + +컨트롤 플레인이 파드 또는 베어 컨테이너에서 kube-controller-manager를 실행하는 경우, +kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트롤러가 사용하는 시간대로 결정한다. {{< /caution >}} 크론잡 리소스에 대한 매니페스트를 생성할때에는 제공하는 이름이 @@ -23,14 +27,26 @@ _크론 잡은_ 시간 기반의 일정에 따라 [잡](/ko/docs/concepts/worklo 11자를 자동으로 추가하고, 작업 이름의 최대 길이는 63자라는 제약 조건이 있기 때문이다. -크론 잡을 생성하고 작동하는 방법은 크론 잡의 스펙 파일을 확안한다. 내용은 [크론 잡으로 자동 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs)를 참조한다. {{% /capture %}} - - {{% capture body %}} -## 크론 잡의 한계 +## 크론잡 + +크론잡은 백업 실행 또는 이메일 전송과 같은 정기적이고 반복적인 +작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을 +스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다. + +### 예제 + +이 크론잡 매니페스트 예제는 현재 시간과 hello 메시지를 1분마다 출력한다. + +{{< codenew file="application/job/cronjob.yaml" >}} + +([크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)는 +이 예시를 더 자세히 설명한다.) + +## 크론 잡의 한계 {#cron-job-limitations} 크론 잡은 일정의 실행시간 마다 _약_ 한 번의 잡을 생성한다. "약" 이라고 하는 이유는 특정 환경에서는 두 개의 잡이 만들어지거나, 잡이 생성되지 않기도 하기 때문이다. 보통 이렇게 하지 @@ -62,3 +78,11 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). 잡은 그 잡이 대표하는 파드 관리에 책임이 있다. {{% /capture %}} +{{% capture whatsnext %}} +[크론 표현 포맷](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format)은 +크론잡 `schedule` 필드의 포맷을 문서화 한다. + +크론 잡 생성과 작업에 대한 지침과 크론잡 매니페스트의 +예는 [크론 잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 5afb68b9bc..268175c200 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -46,24 +46,24 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 이 예시에 대한 설명은 다음과 같다. * `.metadata.name` 필드에 따라 `nginx-deployment` 이름으로 디플로이먼트가 생성된다. -* `replicas` 필드에 따라 디플로이먼트는 3개의 레플리카 파드를 생성한다. -* `selector` 필드는 디플로이먼트가 관리할 파드를 찾는 방법을 정의한다. +* `.spec.replicas` 필드에 따라 디플로이먼트는 3개의 레플리카 파드를 생성한다. +* `.spec.selector` 필드는 디플로이먼트가 관리할 파드를 찾는 방법을 정의한다. 이 사례에서는 간단하게 파드 템플릿에 정의된 레이블(`app: nginx`)을 선택한다. 그러나 파드 템플릿 자체의 규칙이 만족되는 한, 보다 정교한 선택 규칙의 적용이 가능하다. {{< note >}} - `matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된 + `.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된 단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, 키 필드는 "key"에 그리고 연산자는 "In"에 대응되며 값 배열은 "value"만 포함한다. 매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다. {{< /note >}} * `template` 필드에는 다음 하위 필드가 포함되어있다. - * 파드는 `labels` 필드를 사용해서 `app: nginx` 이라는 레이블을 붙인다. + * 파드는 `.metadata.labels` 필드를 사용해서 `app: nginx` 라는 레이블을 붙인다. * 파드 템플릿의 사양 또는 `.template.spec` 필드는 파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.14.2 버전 이미지를 실행하는 `nginx` 컨테이너 1개를 실행하는 것을 나타낸다. - * 컨테이너 1개를 생성하고, `name` 필드를 사용해서 `nginx` 이름을 붙인다. + * 컨테이너 1개를 생성하고, `.spec.template.spec.containers[0].name` 필드를 사용해서 `nginx` 이름을 붙인다. 위의 디플로이먼트를 생성하려면 다음 단계를 따른다. @@ -87,9 +87,8 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 ``` 클러스터에서 디플로이먼트를 점검할 때 다음 필드가 표시된다. - * `NAME` 은 클러스터에 있는 디플로이먼트 이름의 목록이다. - * `DESIRED` 는 디플로이먼트의 생성시 정의된 의도한 애플리케이션 _레플리카_ 의 수를 표시한다. 이것이 _의도한 상태_ 이다. - * `CURRENT` 는 현재 실행 중인 레플리카의 수를 표시한다. + * `NAME` 은 네임스페이스에 있는 디플로이먼트 이름의 목록이다. + * `READY` 는 사용자가 사용할 수 있는 애플리케이션의 레플리카의 수를 표시한다. ready/desired 패턴을 따른다. * `UP-TO-DATE` 는 의도한 상태를 얻기위해 업데이트 된 레플리카의 수를 표시한다. * `AVAILABLE` 은 사용자가 사용 가능한 애플리케이션 레플리카의 수를 표시한다. * `AGE` 는 애플리케이션의 실행 된 시간을 표시한다. @@ -114,8 +113,16 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 NAME DESIRED CURRENT READY AGE nginx-deployment-75675f5897 3 3 3 18s ``` + 레플리카셋의 출력에는 다음 필드가 표시된다. + + * `NAME` 은 네임스페이스에 있는 레플리카셋 이름의 목록이다. + * `DESIRED` 는 디플로이먼트의 생성 시 정의된 의도한 애플리케이션 _레플리카_ 의 수를 표시한다. 이것이 _의도한 상태_ 이다. + * `CURRENT` 는 현재 실행 중인 레플리카의 수를 표시한다. + * `READY` 는 사용자가 사용할 수 있는 애플리케이션의 레플리카의 수를 표시한다. + * `AGE` 는 애플리케이션의 실행된 시간을 표시한다. + 레플리카셋의 이름은 항상 `[DEPLOYMENT-NAME]-[RANDOM-STRING]` 형식으로 된 것을 알 수 있다. 무작위 문자열은 - 무작위로 생성되며, Pod-template-hash를 시드(seed)로 사용한다. + 무작위로 생성되며, `pod-template-hash` 를 시드(seed)로 사용한다. 6. 각 파드에 자동으로 생성된 레이블을 보려면 `kubectl get pods --show-labels` 를 실행한다. 다음과 유사하게 출력된다. ```shell @@ -508,7 +515,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 이와 유사하게 출력된다. ``` - deployment.apps/nginx-deployment + deployment.apps/nginx-deployment rolled back ``` Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`: @@ -518,7 +525,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 이와 유사하게 출력된다. ``` - deployment.apps/nginx-deployment + deployment.apps/nginx-deployment rolled back ``` 롤아웃 관련 명령에 대한 자세한 내용은 [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)을 참조한다. @@ -1015,7 +1022,7 @@ $ echo $? ## 디플로이먼트 사양 작성 -다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. +다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `.apiVersion`, `.kind` 그리고 `.metadata` 필드가 필요하다. 설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/), 컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다. 디플로이먼트 오브젝트의 이름은 유효한 diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index e373984219..e83c02b50d 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -147,7 +147,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | {{< note >}} -클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/#how-it-works)가 +클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/)가 아니라면 `cluster.local`로 설정된다. {{< /note >}} diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 42f86781c5..e29e358d97 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -181,7 +181,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 ... State: Waiting Reason: ErrImagePull - ... + ... ``` * `Running`: 컨테이너가 이슈 없이 구동된다는 뜻이다. `postStart` 훅(있는 경우)은 컨테이너가 Running 상태가 되기 전에 실행된다. 이 상태는 컨테이너가 언제 Running 상태에 돌입한 시간도 함께 출력된다. @@ -206,31 +206,34 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 ... ``` -## 파드의 준비성 게이트(readiness gate) +## 파드의 준비성(readiness) {#pod-readiness-gate} {{< feature-state for_k8s_version="v1.14" state="stable" >}} -파드의 준비성에 대한 확장성을 추가하기 위해서 -추가적인 피드백이나 신호를 `PodStatus`에 주입하는 방법인, -[파드 준비++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md)라는 특징이 쿠버네티스 1.11에서 소개되었다. -파드의 준비성을 평가하기 위한 추가적인 조건들을 `PodSpec` 내의 새로운 `ReadinessGate` 필드를 -통해서 지정할 수 있다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는 +애플리케이션은 추가 피드백 또는 신호를 PodStatus: _Pod readiness_ +와 같이 주입할 수 있다. 이를 사용하기 위해, 파드의 준비성을 평가하기 +위한 추가적인 조건들을 `PodSpec` 내의 `ReadinessGate` 필드를 통해서 지정할 수 있다. + +준비성 게이트는 파드에 대한 `status.condition` 필드의 현재 +상태에 따라 결정된다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는 조건을 찾지 못한다면, 그 조건의 상태는 기본 값인 "`False`"가 된다. 아래는 한 예제를 보여준다. +여기 예제가 있다. + ```yaml -Kind: Pod +kind: Pod ... spec: readinessGates: - conditionType: "www.example.com/feature-1" status: conditions: - - type: Ready # 이것은 내장된 PodCondition이다 + - type: Ready # 내장된 PodCondition이다 status: "False" lastProbeTime: null lastTransitionTime: 2018-01-01T00:00:00Z - - type: "www.example.com/feature-1" # 추가적인 PodCondition + - type: "www.example.com/feature-1" # 추가적인 PodCondition status: "False" lastProbeTime: null lastTransitionTime: 2018-01-01T00:00:00Z @@ -240,19 +243,23 @@ status: ... ``` -파드의 새로운 조건들은 -쿠버네티스의 [레이블 키 포멧](/ko/docs/concepts/overview/working-with-objects/labels/#구문과-캐릭터-셋)을 준수해야 한다. -`kubectl patch` 명령어가 오브젝트 상태 패치(patching)를 아직 제공하지 않기 때문에, -새로운 파드 조건들은 [KubeClient 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 통한 `PATCH` 액션을 통해서 주입되어야 한다. +추가하는 파드 상태에는 쿠버네티스 [레이블 키 포맷](/ko/docs/concepts/overview/working-with-objects/labels/#구문과-캐릭터-셋)을 충족하는 이름이 있어야 한다. -새로운 파드 조건들이 적용된 경우, 파드는 **오직** -다음 두 문장이 모두 참일 때만 준비 상태로 평가된다. + +### 파드 준비성 상태 {#pod-readiness-status} + +`kubectl patch` 명령어는 아직 오브젝트 상태 패치(patching)를 지원하지 않는다. +이러한 `status.conditions` 을 파드에 설정하려면 애플리케이션과 +{{< glossary_tooltip term_id="operator-pattern" text="오퍼레이터">}}의 +`PATCH` 액션을 필요로 한다. +[쿠버네티스 클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 +사용해서 파드 준비성에 대한 사용자 지정 파드 조건을 설정하는 코드를 작성할 수 있다. + +사용자 지정 조건을 사용하는 파드의 경우, 다음 두 조건이 모두 적용되는 +경우에 **만** 해당 파드가 준비된 것으로 평가된다. * 파드 내의 모든 컨테이너들이 준비 상태이다. -* `ReadinessGates`에 지정된 모든 조건들이 "`True`"이다. - -파드 준비성 평가에 대한 변경을 촉진하기 위해서, -이전 파드 조건인 `Ready`를 포착하기 위한 새로운 파드 조건 `ContainersReady`가 소개되었다. +* `ReadinessGates`에 지정된 모든 조건들이 `True` 이다. ## 재시작 정책 @@ -269,32 +276,31 @@ kubelet에 의해서 재시작되는 종료된 컨테이너는 ## 파드의 일생(lifetime) -일반적으로, 파드는 사람 혹은 컨트롤러의 프로세스가 명시적으로 파드를 삭제할 때까지 남아 있다. +일반적으로, 파드는 사람 혹은 +{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}의 +프로세스가 명시적으로 파드를 삭제할 때까지 남아 있다. 컨트롤 플레인은 파드의 수가 설정된 임계치(kube-controller-manager에서 `terminated-pod-gc-threshold`에 의해 결정)를 초과할 때, 종료된 파드들(`Succeeded` 또는 `Failed` 단계)을 정리한다. 이로써 시간이 지남에 따라 파드들이 생성 및 종료되며 발생하는 리소스 누수를 피할 수 있다. -세 가지 유형의 컨트롤러를 사용할 수 있다. +파드에는 다음과 같은 다양한 종류의 리소스가 있다. -- 배치 연산과 같이, 종료가 예상되는 파드를 위해서는 [잡](/docs/concepts/jobs/run-to-completion-finite-workloads/)을 +- 예를 들어 웹 서버와 같이 종료되지 않을 것으로 예상되는 파드용 + {{< glossary_tooltip term_id="deployment" >}}, {{< glossary_tooltip term_id="replica-set" >}} 또는 + {{< glossary_tooltip term_id="statefulset" >}}을 사용한다. + +- 배치 연산과 같이, 종료가 예상되는 파드를 위해서는 + {{< glossary_tooltip term_id="job" >}}을 사용하길 바란다. 잡은 `restartPolicy`가 실패 시(OnFailure) 또는 절대 안 함(Never)으로 지정된 경우에 적합하다. -- 웹 서버와 같이, 종료가 예상되지 않는 파드에 대해서는 - [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/), - [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/), 또는 - [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용하길 바란다. - 레플리케이션 컨트롤러는 `restartPolicy`가 항상(Always)으로 지정된 - 경우에만 적합하다. +- 적합한 노드 당 하나씩 실행해야 하는 파드에는 + {{< glossary_tooltip term_id="daemonset" >}}을 사용한다. -- 머신 당 하나씩 실행해야하는 파드를 위해서는 [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하길 - 바란다. 왜냐하면 데몬 셋은 특정 머신 전용 시스템 서비스(machine-specific system service)를 제공하기 때문이다. - -세 가지 모든 컨트롤러 유형은 PodTemplate을 가지고 있다. 파드를 -직접적으로 생성하는 것 보다는, 적절한 컨트롤러를 생성하고 컨트롤러가 파드를 -생성하도록 하는 것이 추천된다. 그 이유는 파드 -혼자서는 머신의 실패에 탄력적(resilient)이지 않지만, 컨트롤러는 탄력적이기 때문이다. +모든 워크로드 리소스에는 파드명세가 포함된다. 사용자가 직접적으로 파드를 생성하는 +것보다 적절한 워크로드 리소스를 생성하고 리소스 컨트롤러가 +사용자를 위한 파드를 생성하도록 하는 것을 권장한다. 만약 노드가 죽거나 다른 클러스터의 다른 노드들로부터 연결이 끊기면, 쿠버네티스는 잃어버린 노드에 있는 모든 파드의 `phase`를 실패된(Failed)으로 설정하는 정책을 적용한다. @@ -398,4 +404,3 @@ spec: {{% /capture %}} - diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md index 1902594c33..e1239a817e 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ko/docs/concepts/workloads/pods/pod-overview.md @@ -15,9 +15,9 @@ card: {{% capture body %}} ## 파드에 대해 이해하기 -*파드* 는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 {{< glossary_tooltip term_id="cluster" >}} 에서의 Running 프로세스를 나타낸다. +*파드* 는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 {{< glossary_tooltip term_id="cluster" text="클러스터" >}} 에서의 Running 프로세스를 나타낸다. -파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, {{< glossary_tooltip text="container" term_id="container" >}} 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미함. +파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 정체성(IP 주소) 및 컨테이너가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다. 아마 단일 {{< glossary_tooltip text="컨테이너" term_id="container" >}}로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미한다. [도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/) 역시 지원한다. @@ -26,12 +26,9 @@ card: * **단일 컨테이너만 동작하는 파드**. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직접 관리한다고 볼 수 있다. * **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다. -[쿠버네티스 블로그](https://kubernetes.io/blog)에는 파드 사용 사례의 몇 가지 추가적인 정보가 있다. 더 많은 정보를 위해서 아래 내용을 참조하길 바란다. - - * [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) - * [컨테이너 디자인 패턴](https://kubernetes.io/blog/2016/06/container-design-patterns) - -각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 더 많은 정보는 [파드와 컨트롤러](#파드와-컨트롤러)를 참고하길 바란다. +각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(더 많은 인스턴스를 실행해서 더 많은 전체 리소스를 제공하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. +복제된 파드는 일반적으로 워크로드 리소스와 해당 {{< glossary_tooltip text="_컨트롤러_" term_id="controller" >}}에 의해 그룹으로 생성과 관리된다. +쿠버네티스가 컨트롤러를 사용해서 워크로드의 확장과 복구를 구현하는 방법에 대한 자세한 내용은 [파드와 컨트롤러](#파드와-컨트롤러)를 참고한다. ## 어떻게 파드가 다중 컨테이너를 관리하는가 @@ -47,7 +44,7 @@ card: #### 네트워킹 -각각의 파드는 유일한 IP주소를 할당 받는다. 한 파드 내부의 모든 컨테이너는 네트워크 네임스페이스와 IP주소 및 네트워크 포트를 공유한다. *파드 안에 있는* 컨테이너는 다른 컨테이너와 `localhost`를 통해서 통신할 수 있다. 특정 파드 안에 있는 컨테이너가 *파드 밖의* 요소들과 통신하기 위해서는, 네트워크 리소스를 어떻게 쓰고 있는지 공유 해야 한다(예를 들어 포트 등). +각각의 파드는 각 주소 패밀리의 고유한 IP 주소를 할당 받는다. 한 파드 내부의 모든 컨테이너는 네트워크 네임스페이스와 IP주소 및 네트워크 포트를 공유한다. *파드 안에 있는* 컨테이너는 다른 컨테이너와 `localhost` 를 통해서 통신할 수 있다. 특정 파드 안에 있는 컨테이너가 *파드 밖의* 요소들과 통신하기 위해서는, 네트워크 리소스를 어떻게 쓰고 있는지 공유해야 한다(예를 들어 포트 등). #### 저장소 @@ -55,54 +52,63 @@ card: ## 파드 작업 -직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, 컨트롤러에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 {{< glossary_tooltip term_id="node" >}} 에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 객체가 삭제되거나, 파드가 리소스의 부족으로 인해 *제거되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있는다. +직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들 일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, {{< glossary_tooltip text="_컨트롤러_" term_id="controller" >}}에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 {{< glossary_tooltip term_id="node" >}}에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 오브젝트가 삭제되거나, 파드가 리소스의 부족으로 인해 *축출되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있다. {{< note >}} -파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 자기 스스로 동작하지 않는다. 하지만 컨테이너 환경은 그것이 삭제될 때까지 계속 동작한다. +파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 프로세스가 아니라, 컨테이너를 실행하는 환경이다. 파드는 삭제될 때까지 유지된다. {{< /note >}} -파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#파드와-컨트롤러)를 참고하길 바란다. +파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 축출되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용할 수 있지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서는 훨씬 더 보편적이다. ### 파드와 컨트롤러 -컨트롤러는 다중 파드를 생성하고 관리해 주는데, 클러스터 범위 내에서의 레플리케이션 핸들링, 롤아웃 그리고 셀프힐링 기능 제공을 한다. 예를 들어, 만약 노드가 고장났을 때, 컨트롤러는 다른 노드에 파드를 스케줄링 함으로써 자동으로 교체할 것이다. +워크로드 리소스를 사용해서 여러 파드를 생성하고 관리할 수 있다. 리소스 컨트롤러는 파드 장애 발생 시 복제, 롤아웃, 자동 복구를 처리한다. 예를 들어, 노드에 장애가 발생하면, 컨트롤러는 해당 노드의 파드는 작동을 멈추고 교체용 파드를 생성한다는 것을 알게 된다. 스케줄러는 교체용 파드를 정상적인 노드에 배치하게 된다. -한 가지 또는 그 이상의 파드를 보유한 컨트롤러의 몇 가지 예시. - -* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) -* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/) -* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/) - -일반적으로, 컨트롤러는 책임을 지고 제공한 파드 템플릿을 사용한다. +* {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} +* {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}} +* {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}} ## 파드 템플릿 -파드 템플릿은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/), -[잡](/docs/concepts/jobs/run-to-completion-finite-workloads/), -[데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다. -컨트롤러는 파드 템플릿을 사용하여 실제 파드를 만든다. -아래 예시는 메시지를 출력하는 컨테이너를 포함하는 파드에 대한 간단한 매니페스트이다. +워크로드 리소스에 대한 컨트롤러는 파드 템플릿으로 파드를 생성하고 +사용자를 대신해서 이러한 파드를 관리한다. + +파드템플릿은 파드를 생성하기 위한 명세이며 +[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/), +[잡](/ko/docs/concepts/jobs/run-to-completion-finite-workloads/) 그리고 +[데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/)과 같은 워크로드 리소스에 포함되어 있다. + +워크로드 리소스의 각 컨트롤러는 워크로드 오브젝트 내부의 파드템플릿을 사용해서 실제 파드를 만든다. 파드템플릿은 앱을 실행하는 데 사용되는 모든 워크로드 리소스의 의도하는 상태의 일부이다. + +아래 샘플은 하나의 컨테이너를 시작하는 `template` 이 있는 간단한 잡에 대한 매니페스트이다. 파드의 컨테이너가 메시지를 출력한 후 일시 중지하게 된다. ```yaml -apiVersion: v1 -kind: Pod +apiVersion: batch/v1 +kind: Job metadata: - name: myapp-pod - labels: - app: myapp -spec: - containers: - - name: myapp-container - image: busybox - command: ['sh', '-c', 'echo 안녕하세요 쿠버네티스! && sleep 3600'] + name: hello + template: + # 이것이 파드 템플릿이다. + spec: + containers: + - name: hello + image: busybox + command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] + restartPolicy: OnFailure + # 여기가 파드 템플릿의 끝이다. ``` -모든 레플리카의 현재 원하는 상태를 지정하는 대신, 파드 템플릿은 쿠키 틀과 같다. 쿠키가 한 번 잘리면, 그 쿠키는 쿠키 틀과 더이상 관련이 없다. 양자 얽힘이 없는 것이다. 그 이후 템플릿을 변경하거나 새로운 템플릿으로 바꿔도 이미 만들어진 파드에는 직접적인 영향이 없다. 마찬가지로, 레플리케이션 컨트롤러에 의해 만들어진 파드는 아마 그 이후 직접 업데이트될 수 있다. 이것은 모든 컨테이너가 속해있는 파드에서 현재 원하는 상태를 명시하는 것과 의도적으로 대비가 된다. 이러한 접근은 시스템의 의미를 철저히 단순화하고 유연성을 증가시킨다. +파드 템플릿을 수정하거나 새 파드 템플릿으로 전환해도 이미 존재하는 파드에는 영향을 미치지 않는다. 파드는 템플릿 업데이트를 직접 수신하지 않지만, 대신에 수정된 파드 템플릿과 일치하는 새 파드가 생성된다. + +예를 들어, 디플로이먼트 컨트롤러는 실행 중인 파드가 현재 파드 템플릿과 일치하는지 확인한다. 템플릿이 업데이트되면, 컨트롤러는 업데이트된 템플릿을 기반으로 기존 파드를 제거하고 새 파드를 생성한다. 각 워크로드 컨트롤러는 파드 템플릿의 변경사항을 처리하기 위해 자체 규칙을 구현한다. + +노드에서 "kubelet"이 파드 템플릿과 업데이트에 관련된 세부 정보를 직접 관찰하거나 관리하지 않으며, 이러한 세부 정보는 추상화되지 않는다. 이러한 추상화와 분리는 시스템 시맨틱을 단순화하며, 기존 코드를 변경하지 않고 클러스터의 동작을 확장할 수 있도록 한다. {{% /capture %}} {{% capture whatsnext %}} * [파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자. +* [분산 시스템 툴킷: 복합 컨테이너의 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)은 둘 이상의 컨테이너가 있는 파드의 공통 레이아웃에 대해 설명한다. * 파드의 동작에 대해 더 알아보자. * [파드 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료) * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/) diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 7bde7139a9..4bb95789d3 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 @@ -62,10 +62,10 @@ metadata: name: mypod spec: topologySpreadConstraints: - - maxSkew: - topologyKey: - whenUnsatisfiable: - labelSelector: + - maxSkew: + topologyKey: + whenUnsatisfiable: + labelSelector: ``` 사용자는 하나 또는 다중 `topologySpreadConstraint` 를 정의해서 kube-scheduler 에게 클러스터에 걸쳐 있는 기존 파드와 시작하는 각각의 파드와 연관하여 배치하는 방법을 명령할 수 있다. 필드는 다음과 같다. @@ -73,8 +73,8 @@ spec: - **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다. 이것은 주어진 토폴로지 유형의 임의의 두 토폴로지 도메인에 일치하는 파드의 수 사이에서 허용되는 차이의 최댓값이다. 이것은 0보다는 커야 한다. - **topologyKey** 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다. - **whenUnsatisfiable** 는 분산 제약 조건을 만족하지 않을 경우에 처리하는 방법을 나타낸다. - - `DoNotSchedule` (기본값)은 스케줄러에 스케줄을 하지 말라고 알려준다. - - `ScheduleAnyway` 는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선순위를 부여하면서, 스케줄을 계속하도록 지시한다. + - `DoNotSchedule` (기본값)은 스케줄러에 스케줄링을 하지 말라고 알려준다. + - `ScheduleAnyway` 는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선 순위를 부여하면서, 스케줄링을 계속하도록 지시한다. - **labelSelector** 는 일치하는 파드를 찾는데 사용된다. 이 레이블 셀렉터와 일치하는 파드의 수를 계산하여 해당 토폴로지 도메인에 속할 파드의 수를 결정한다. 자세한 내용은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다. 사용자는 `kubectl explain Pod.spec.topologySpreadConstraints` 를 실행해서 이 필드에 대한 자세한 내용을 알 수 있다. @@ -160,8 +160,8 @@ spec: - 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다. - `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다. - 1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone"레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다. - 2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다. + 1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다. + 2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다. - 들어오는 파드의 `topologySpreadConstraints[*].labelSelector` 와 자체 레이블과 일치하지 않을 경우 어떻게 되는지 알고 있어야 한다. 위의 예시에서, 만약 들어오는 파드의 레이블을 제거하더라도 여전히 제약 조건이 충족하기 때문에 "zoneB"에 배치할 수 있다. 그러나, 배치 이후에도 클러스터의 불균형 정도는 변경되지 않는다. - 여전히 zoneA는 {foo:bar} 레이블을 가지고 있는 2개의 파드를 가지고 있고, zoneB 도 {foo:bar}를 레이블로 가지는 파드 1개를 가지고 있다. 따라서 만약 예상과 다르면, 워크로드의 `topologySpreadConstraints[*].labelSelector` 가 자체 레이블과 일치하도록 하는 것을 권장한다. @@ -207,12 +207,12 @@ 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 >}} @@ -229,14 +229,14 @@ profiles: 더 많이 채워지거나 더 많이 분산되는 방식으로 스케줄 되는 방법을 제어한다. - `PodAffinity` 는, 사용자가 자격이 충족되는 토폴로지 도메인에 -원하는 수의 파드를 얼마든지 채울 수 있다. + 원하는 수의 파드를 얼마든지 채울 수 있다. - `PodAntiAffinity` 로는, 단일 토폴로지 도메인에 -단 하나의 파드만 스케줄 될 수 있다. + 단 하나의 파드만 스케줄 될 수 있다. "EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서 고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다. -더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-even-pods-spreading.md#motivation)를 참조한다. +더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation)를 참조한다. ## 알려진 제한사항 diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 18958c7531..f059747769 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -35,7 +35,7 @@ card: 1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명합니다. 2. [문서 리포지터리](https://github.com/kubernetes/website) 와 웹사이트의 [정적 사이트 생성기](https://gohugo.io)를 숙지합니다. -3. [풀 리퀘스트 열기](/docs/contribute/new-content/open-a-pr/)와 [변경 검토](/docs/contribute/review/reviewing-prs/)의 기본 프로세스를 이해하도록 합니다. +3. [풀 리퀘스트 열기](/docs/contribute/new-content/new-content/)와 [변경 검토](/docs/contribute/review/reviewing-prs/)의 기본 프로세스를 이해하도록 합니다. 일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다. 역할과 권한에 대한 자세한 내용은 @@ -44,6 +44,7 @@ card: ## 첫 번째 기여 - [기여 개요](/docs/contribute/new-content/overview/)를 읽고 기여할 수 있는 다양한 방법에 대해 알아봅니다. +- [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를 참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다. - 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/docs/contribute/new-content/new-content/#changes-using-github) GitHub에서의 이슈 제기에 대해 자세히 알아봅니다. - 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 [풀 리퀘스트 검토](/docs/contribute/review/reviewing-prs/)를 합니다. - 쿠버네티스 [컨텐츠](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다. diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md index 2ff7e51cdb..9b56a46dfa 100644 --- a/content/ko/docs/contribute/localization_ko.md +++ b/content/ko/docs/contribute/localization_ko.md @@ -166,11 +166,13 @@ boilerplate | 상용구 | Boot | 부트 | Build | 빌드 | Cache | 캐시 | +Calico | 캘리코(Calico) | canary | 카나리(canary) | 릴리스 방식에 관련한 용어인 경우에 한함 cascading | 캐스케이딩(cascading) | character set | 캐릭터 셋 | Charts | 차트 | checkpoint | 체크포인트 | +Cilium | 실리움(Cilium) | CLI | CLI | Cluster | 클러스터 | Command Line Tool | 커맨드라인 툴 | @@ -200,19 +202,22 @@ disruption | 중단(disruption) | distros | 배포판 | Docker | 도커 | Dockerfile | Dockerfile | +Docker Swarm | Docker Swarm | Downward API | 다운워드(Downward) API | draining | 드레이닝(draining) | egress | 이그레스, 송신(egress) | Endpoint | 엔드포인트 | entry point | 진입점 | Event | 이벤트 | +evict | 축출하다 | +eviction | 축출 | Exec | Exec | expose | 노출시키다 | extension | 익스텐션(extension) | Failed | Failed | 파드의 상태에 한함 Federation | 페더레이션 | field | 필드 | -Flannel | Flannel | +Flannel | 플란넬(Flannel) | form | 형식 | Google Compute Engine | Google Compute Engine | hash | 해시 | @@ -239,6 +244,7 @@ Job | 잡 | kube-proxy | kube-proxy | Kubelet | Kubelet | Kubernetes | 쿠버네티스 | +Kube-router | Kube-router | label | 레이블 | lifecycle | 라이프사이클 | Linux | 리눅스 | @@ -273,7 +279,7 @@ Persistent Volume | 퍼시스턴트 볼륨 | Persistent Volume Claim | 퍼시스턴트 볼륨 클레임 | pipeline | 파이프라인 | placeholder pod | 플레이스홀더(placeholder) 파드 | -Pod(파드) | 파드 | +Pod | 파드 | Pod Preset | 파드 프리셋 | PodAntiAffinity | 파드안티어피니티(PodAntiAffinity) | PodDisruptionBudget | PodDisruptionBudget | @@ -307,6 +313,7 @@ Role | 롤 | rollback | 롤백 | rolling update | 롤링 업데이트 | rollout | 롤아웃 | +Romana | 로마나(Romana) | Running | Running | 파드의 상태에 한함 runtime | 런타임 | Scale | 스케일 | @@ -325,6 +332,7 @@ Shell | 셸 | Sign In | 로그인 | Sign Out | 로그아웃 | skew | 차이(skew) | +snippet | 스니펫(snippet) | spec | 명세, 스펙, 사양 | specification | 명세 | Stateful Set | 스테이트풀 셋 | @@ -352,6 +360,7 @@ virtualization | 가상화 | Volume | 볼륨 | Waiting | Waiting | 파드의 상태에 한함 Walkthrough | 연습 | +Weave-net | 위브넷(Weave Net) | Weaveworks 사의 솔루션 공식 명칭은 'Weave Net'이므로 한영병기 시 공식 명칭 사용 Windows | 윈도우 | Worker | 워커 | 노드의 형태에 한함 Workload | 워크로드 | diff --git a/content/ko/docs/contribute/new-content/_index.md b/content/ko/docs/contribute/new-content/_index.md new file mode 100644 index 0000000000..2a97dcca2c --- /dev/null +++ b/content/ko/docs/contribute/new-content/_index.md @@ -0,0 +1,4 @@ +--- +title: 새로운 콘텐츠 기여하기 +weight: 20 +--- diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md new file mode 100644 index 0000000000..17ea3342c1 --- /dev/null +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -0,0 +1,484 @@ +--- +title: 풀 리퀘스트 열기 +slug: new-content +content_template: templates/concept +weight: 10 +card: + name: contribute + weight: 40 +--- + +{{% capture overview %}} + +{{< note >}} +**코드 개발자**: 향후 쿠버네티스 릴리스의 +새로운 기능을 문서화하는 경우, +[새 기능 문서화](/docs/contribute/new-content/new-features/)를 참고한다. +{{< /note >}} + +새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/overview/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다. + +변경 사항이 작거나, git에 익숙하지 않은 경우, [GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자. + +변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고 컴퓨터에서 로컬로 변경하는 방법을 배운다. + +{{% /capture %}} + +{{% capture body %}} + +## GitHub을 사용하여 변경하기 + +git 워크플로에 익숙하지 않은 경우, 풀 리퀘스트를 +여는 쉬운 방법이 있다. + +1. 이슈가 있는 페이지에서, 오른쪽 상단에 있는 연필 아이콘을 선택한다. + 페이지 하단으로 스크롤 하여 **페이지 편집하기** 를 선택할 수도 있다. + +2. GitHub 마크다운 편집기에서 수정한다. + +3. 편집기 아래에서, **Propose file change** 양식을 + 작성한다. 첫 번째 필드에서, 커밋 메시지 제목을 지정한다. + 두 번째 필드에는, 설명을 제공한다. + + {{< note >}} + 커밋 메시지에 [GitHub 키워드](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)를 사용하지 않는다. 나중에 풀 리퀘스트 설명에 + 추가할 수 있다. + {{< /note >}} + +4. **Propose file change** 를 선택한다. + +5. **Create pull requests** 를 선택한다. + +6. **Open a pull request** 화면이 나타난다. 양식을 작성한다. + + - 풀 리퀘스트의 **Subject** 필드는 기본적으로 커밋의 요약으로 설정한다. + 필요한 경우 변경할 수 있다. + - **Body** 는 만약 내용이 있다면, 확장된 커밋 메시지를 포함한다. + 그리고 일부 템플릿 텍스트를 포함한다. + 템플릿 텍스트에 필요한 세부 정보를 추가한 다음, 추가 템플릿 텍스트를 삭제한다. + - **Allow edits from maintainers** 체크박스는 선택된 상태로 둔다. + + {{< note >}} + PR 설명은 리뷰어가 변경 사항을 이해하는 데 유용한 방법이다. 자세한 내용은 [PR 열기](#open-a-pr)를 참고한다. + {{}} + +7. **Create pull request** 를 선택한다. + +### GitHub에서 피드백 해결 + +풀 리퀘스트를 병합하기 전에, 쿠버네티스 커뮤니티 회원은 이를 리뷰하고 +승인한다. `k8s-ci-robot` 은 이 페이지에 나와있는 가까운 +멤버에게 리뷰를 제안한다. 특정한 사람을 염두에 두고 있다면, +GitHub 사용자 이름을 코멘트로 남긴다. + +리뷰어가 변경을 요청하는 경우, 다음과 같이 한다. + +1. **Files changed** 탭으로 이동 한다. +2. 풀 리퀘스트에 의해 변경된 파일에서 연필(편집) 아이콘을 +선택한다. +3. 요청된 변경에 대한 수정을 한다. +4. 변경 사항을 커밋한다. + +리뷰어를 기다리고 있는 경우, 7일마다 한 번씩 연락한다. 슬랙 채널 `#sig-docs` 에 메시지를 게시할 수도 있다. + +리뷰가 완료되면, 리뷰어가 PR을 병합하고 몇 분 후에 변경 사항이 적용된다. + +## 로컬 포크에서 작업하기 {#fork-the-repo} + +git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우, +로컬 포크로 작업한다. + +컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다. git UI 애플리케이션을 사용할 수도 있다. + +### kubernetes/website 리포지터리 포크하기 + +1. [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다. +2. **Fork** 를 선택한다. + +### 로컬 클론 생성 및 업스트림 설정 + +3. 터미널 창에서, 포크를 클론한다. + + ```bash + git clone git@github.com//website + ``` + +4. 새 `website` 디렉터리로 이동한다. `kubernetes/website` 리포지터리를 `upstream` 원격으로 설정한다. + + ```bash + cd website + + git remote add upstream https://github.com/kubernetes/website.git + ``` + +5. `origin` 과 `upstream` 리포지터리를 확인한다. + + ```bash + git remote -v + ``` + + 출력은 다음과 비슷하다. + + ```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. 포크의 `origin/master` 와 `kubernetes/website` 의 `upstream/master` 에서 커밋을 가져온다. + + ```bash + git fetch origin + git fetch upstream + ``` + + 이를 통해 변경을 시작하기 전에 로컬 리포지터리가 최신 상태인지 확인한다. + + {{< note >}} + 이 워크플로는 [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)와 다르다. 포크에 업데이트를 푸시하기 전에 로컬의 `master` 복사본을 `upstream/master` 와 병합할 필요가 없다. + {{< /note >}} + +### 브랜치 만들기 + +1. 작업할 브랜치 기반을 결정한다. + + - 기존 콘텐츠를 개선하려면, `upstream/master` 를 사용한다. + - 기존 기능에 대한 새로운 콘텐츠를 작성하려면, `upstream/master` 를 사용한다. + - 현지화된 콘텐츠의 경우, 현지화 규칙을 사용한다. 자세한 내용은 [쿠버네티스 문서 현지화](/ko/docs/contribute/localization_ko/)를 참고한다. + - 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다. 자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다. + - 콘텐츠 재구성과 같이 여러 SIG Docs 기여자들이 협업하는 장기적인 작업에는, + 해당 작업을 위해 작성된 특정 기능 브랜치를 + 사용한다. + + 브랜치 선택에 도움이 필요하면, 슬랙 채널 `#sig-docs` 에 문의한다. + +2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. 이 예에서는 기본 브랜치가 `upstream/master` 라고 가정한다. + + ```bash + git checkout -b upstream/master + ``` + +3. 텍스트 편집기를 사용하여 변경한다. + +언제든지, `git status` 명령을 사용하여 변경한 파일을 본다. + +### 변경 사항 커밋 + +풀 리퀘스트를 제출할 준비가 되면, 변경 사항을 커밋한다. + +1. 로컬 리포지터리에서 커밋해야 할 파일을 확인한다. + + ```bash + git status + ``` + + 출력은 다음과 비슷하다. + + ```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. **Changes not staged for commit** 에 나열된 파일을 커밋에 추가한다. + + ```bash + git add + ``` + + 각 파일에 대해 이 작업을 반복한다. + +3. 모든 파일을 추가한 후, 커밋을 생성한다. + + ```bash + git commit -m "Your commit message" + ``` + + {{< note >}} + 커밋 메시지에 [GitHub 키워드](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)를 사용하지 말자. 나중에 풀 리퀘스트 설명에 추가할 + 수 있다. + {{< /note >}} + +4. 로컬 브랜치와 새로운 커밋을 원격 포크로 푸시한다. + + ```bash + git push origin + ``` + +### 로컬에서 변경 사항 미리보기 {#preview-locally} + +변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. 미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다. + +website의 도커 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다. + +{{< tabs name="tab_with_hugo" >}} +{{% tab name="Hugo 컨테이너" %}} + +1. 로컬에서 이미지를 빌드한다. + + ```bash + make docker-image + ``` + +2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다. + + ```bash + make docker-serve + ``` + +3. 웹 브라우저에서 `https://localhost:1313` 로 이동한다. Hugo는 + 변경 사항을 보고 필요에 따라 사이트를 다시 구축한다. + +4. 로컬의 Hugo 인스턴스를 중지하려면, 터미널로 돌아가서 `Ctrl+C` 를 입력하거나, + 터미널 창을 닫는다. + +{{% /tab %}} +{{% tab name="Hugo 커맨드 라인" %}} + +또는, 컴퓨터에 `hugo` 명령을 설치하여 사용한다. + +5. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다. + +6. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다. + + ```bash + cd /website + hugo server + ``` + +7. 브라우저의 주소 표시줄에 `https://localhost:1313` 을 입력한다. + +8. 로컬의 Hugo 인스턴스를 중지하려면, 터미널로 돌아가서 `Ctrl+C` 를 입력하거나, +    터미널 창을 닫는다. + +{{% /tab %}} +{{< /tabs >}} + +### 포크에서 kubernetes/website로 풀 리퀘스트 열기 {#open-a-pr} + +1. 웹 브라우저에서 [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다. +2. **New Pull Request** 를 선택한다. +3. **compare across forks** 를 선택한다. +4. **head repository** 드롭다운 메뉴에서, 포크를 선택한다. +5. **compare** 드롭다운 메뉴에서, 브랜치를 선택한다. +6. **Create Pull Request** 를 선택한다. +7. 풀 리퀘스트에 대한 설명을 추가한다. + - **Title**(50자 이하): 변경 사항에 대한 의도를 요약한다. + - **Description**: 변경 사항을 자세히 설명한다. + - 관련된 GitHub 이슈가 있는 경우, `Fixes #12345` 또는 `Closes #12345` 를 설명에 포함한다. 이렇게 하면 GitHub의 자동화 기능이 PR을 병합한 후 언급된 이슈를 닫는다. 다른 관련된 PR이 있는 경우, 이들 PR도 연결한다. + - 구체적인 내용에 대한 조언이 필요한 경우, 원하는 질문을 리뷰어가 생각해볼 수 있도록 설명에 포함한다. + +8. **Create pull request** 버튼을 선택한다. + + 축하한다! 여러분의 풀 리퀘스트가 [풀 리퀘스트](https://github.com/kubernetes/website/pulls)에 열렸다. + + +PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다. + + - Netlify 빌드가 실패하면, 자세한 정보를 위해 **Details** 를 선택한다. + - Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기 직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다. + +또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다. 자세한 내용은 [이슈 레이블 추가와 제거](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels)를 참고한다. + +### 로컬에서 피드백 해결 + +1. 변경한 후, 이전 커밋을 수정한다. + + ```bash + git commit -a --amend + ``` + + - `-a`: 모든 변경 사항을 커밋 + - `--amend`: 새로운 커밋을 만들지 않고, 이전 커밋을 수정한다. + +2. 필요한 경우 커밋 메시지를 업데이트한다. + +3. `git push origin ` 를 사용해서 변경 사항을 푸시하고 Netlify 테스트를 다시 실행한다. + + {{< note >}} + 수정하는 대신 `git commit -m` 을 사용하는 경우, 병합하기 전에 [커밋을 스쿼시](#커밋-스쿼시하기)해야 한다. + {{< /note >}} + +#### 리뷰어의 변경 + +때때로 리뷰어가 여러분의 풀 리퀘스트를 커밋한다. 다른 변경을 하기 전에, 커밋을 가져온다. + +1. 원격 포크에서 커밋을 가져오고 작업 브랜치를 리베이스한다. + + ```bash + git fetch origin + git rebase origin/ + ``` + +2. 리베이스한 후, 포크에 새로운 변경 사항을 강제로 푸시한다. + + ```bash + git push --force-with-lease origin + ``` + +#### 충돌 병합 및 리베이스 + +{{< note >}} +자세한 내용은 [Git 브랜치 - 기본 브랜치와 병합](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [고급 병합](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)을 참조하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다. +{{< /note >}} + +다른 기여자가 다른 PR에서 동일한 파일에 대한 변경 사항을 커밋하면, 병합 충돌이 발생할 수 있다. PR의 모든 병합 충돌을 해결해야 한다. + +1. 포크를 업데이트하고 로컬 브랜치를 리베이스한다. + + ```bash + git fetch origin + git rebase origin/ + ``` + + 그런 다음 포크에 변경 사항을 강제로 푸시한다. + + ```bash + git push --force-with-lease origin + ``` + +2. `kubernetes/website` 의 `upstream/master` 에 대한 변경 사항을 가져오고 브랜치를 리베이스한다. + + ```bash + git fetch upstream + git rebase upstream/master + ``` + +3. 리베이스의 결과를 검사한다. + + ```bash + git status + ``` + + 이 명령의 결과에 여러 파일이 충돌된 것으로 표시된다. + +4. 충돌하는 각 파일을 열고 충돌 마커(`>>>`,`<<<` 그리고 `===`)를 찾는다. 충돌을 해결하고 충돌 마커를 삭제한다. + + {{< note >}} + 자세한 내용은 [충돌이 표시되는 방법](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented)을 참고한다. + {{< /note >}} + +5. 변경 세트에 파일을 추가한다. + + ```bash + git add + ``` +6. 리베이스를 계속한다. + + ```bash + git rebase --continue + ``` + +7. 필요에 따라 2단계에서 5단계를 반복한다. + + 모든 커밋을 적용한 후, `git status` 명령은 리베이스가 완료되었음을 나타낸다. + +8. 브랜치를 포크에 강제로 푸시한다. + + ```bash + git push --force-with-lease origin + ``` + + 풀 리퀘스트에 더 이상 충돌이 표시되지 않는다. + + +### 커밋 스쿼시하기 + +{{< note >}} +자세한 내용은 [Git 도구 - 히스토리 다시 쓰기](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)를 참고하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다. +{{< /note >}} + +PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 단일 커밋으로 스쿼시해야 한다. PR의 **Commits** 탭에서 또는 `git log` 명령을 로컬에서 실행하여 커밋 수를 확인할 수 있다. + +{{< note >}} +여기서는 `vim` 을 커맨드 라인 텍스트 편집기로 사용하는 것을 가정한다. +{{< /note >}} + +1. 대화식 리베이스를 시작한다. + + ```bash + git rebase -i HEAD~ + ``` + + 커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. `HEAD~}} + 자세한 내용은 [대화식 모드](https://git-scm.com/docs/git-rebase#_interactive_mode)를 참고한다. + {{< /note >}} + +2. 파일 편집을 시작한다. + + 다음의 원본 텍스트를 변경한다. + + ```bash + pick d875112ca Original commit + pick 4fa167b80 Address feedback 1 + pick 7d54e15ee Address feedback 2 + ``` + + 아래와 같이 변경한다. + + ```bash + pick d875112ca Original commit + squash 4fa167b80 Address feedback 1 + squash 7d54e15ee Address feedback 2 + ``` + + 이것은 커밋 `4fa167b80 Address feedback 1` 과 `7d54e15ee Address feedback 2` 를 `d875112ca Original commit` 으로 스쿼시한다. 타임라인의 일부로 `d875112ca Original commit` 만 남긴다. + +3. 파일을 저장하고 종료한다. + +4. 스쿼시된 커밋을 푸시한다. + + ```bash + git push --force-with-lease origin + ``` + +## 다른 리포지터리에 기여하기 + +[쿠버네티스 프로젝트](https://github.com/kubernetes)에는 50개 이상의 리포지터리가 포함되어 있다. 이러한 리포지터리에는 사용자용 도움말 텍스트, 오류 메시지, API 레퍼런스 또는 코드 주석과 같은 문서가 포함되어 있다. + +개선하려는 텍스트가 보이면, GitHub을 사용하여 쿠버네티스 조직의 모든 리포지터리를 검색한다. +이를 통해 어디에 이슈나 PR을 제출할지를 파악할 수 있다. + +각 리포지터리에는 고유한 프로세스와 절차가 있다. 여러분이 이슈를 +제기하거나 PR을 제출하기 전에, 그 리포지터리의 `README.md`, `CONTRIBUTING.md` 그리고 +`code-of-conduct.md`(만약 이들 문서가 있다면)를 읽어본다. + +대부분의 리포지터리에는 이슈와 PR 템플릿이 사용된다. 팀의 프로세스에 대한 +느낌을 얻으려면 열린 이슈와 PR을 살펴보자. 이슈나 PR을 제출할 때 +가능한 한 상세하게 템플릿의 내용을 작성한다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +- 리뷰 프로세스에 대한 자세한 내용은 [리뷰하기](/ko/docs/contribute/reviewing/revewing-prs)를 읽어본다. + +{{% /capture %}} diff --git a/content/ko/docs/contribute/new-content/overview.md b/content/ko/docs/contribute/new-content/overview.md new file mode 100644 index 0000000000..ca1bc10737 --- /dev/null +++ b/content/ko/docs/contribute/new-content/overview.md @@ -0,0 +1,58 @@ +--- +title: 새로운 콘텐츠 기여하기에 대한 개요 +linktitle: 개요 +content_template: templates/concept +main_menu: true +weight: 5 +--- + +{{% capture overview %}} + +이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가 있다. + + +{{% /capture %}} + +{{% capture body %}} + +## 기여하기에 대한 기본 + +- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다. +- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다. +- [페이지 템플릿](/docs/contribute/style/page-templates/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다. +- 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러 [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다. +- 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각 언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에 의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어, 한글 문서의 소스는 `/content/ko/docs/` 에 저장된다. +- 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다. + +## 시작하기 전에 {#before-you-begin} + +### CNCF CLA 서명 {#sign-the-cla} + +모든 쿠버네티스 기여자는 **반드시** [기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고 [기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다. + +CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다. 제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며, git 이름과 이메일은 CNCF CLA에 사용된 것과 일치해야 한다. + +### 사용할 Git 브랜치를 선택한다 + +풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를 미리 알아야 한다. + +시나리오 | 브랜치 +:---------|:------------ +현재 릴리스의 기존 또는 새로운 영어 콘텐츠 | `master` +기능 변경 릴리스의 콘텐츠 | `dev-release-` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `{{< latest-version >}}` 에서 기능이 변경된 경우, ``dev-{{< release-branch >}}`` 에 문서 변경을 추가한다. +다른 언어로된 콘텐츠(현지화) | 현지화 규칙을 사용. 자세한 내용은 [현지화 브랜치 전략](/docs/contribute/localization/#branching-strategy)을 참고한다. + + +어떤 브랜치를 선택해야 할지 잘 모르는 경우 슬랙의 `#sig-docs` 에 문의한다. + +{{< note >}} +풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면, +제출자(제출자인 여러분만)가 이를 변경할 수 있다. +{{< /note >}} + +### PR 당 언어 + +PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 각 언어마다 별도의 PR을 연다. + + +{{% /capture %}} diff --git a/content/ko/docs/contribute/review/_index.md b/content/ko/docs/contribute/review/_index.md new file mode 100644 index 0000000000..a79fb6129f --- /dev/null +++ b/content/ko/docs/contribute/review/_index.md @@ -0,0 +1,14 @@ +--- +title: 변경 사항 리뷰하기 +weight: 30 +--- + +{{% capture overview %}} + +이 섹션은 콘텐츠를 리뷰하는 방법에 대해 설명한다. + +{{% /capture %}} + +{{% capture body %}} + +{{% /capture %}} diff --git a/content/ko/docs/contribute/review/for-approvers.md b/content/ko/docs/contribute/review/for-approvers.md new file mode 100644 index 0000000000..c6ebb465ac --- /dev/null +++ b/content/ko/docs/contribute/review/for-approvers.md @@ -0,0 +1,228 @@ +--- +title: 승인자와 리뷰어의 리뷰 +linktitle: 승인자와 리뷰어용 +slug: for-approvers +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)와 [승인자](/ko/docs/contribute/participating/#승인자)는 변경 사항을 리뷰할 때 몇 가지 추가 작업을 수행한다. + +매주 특정 문서 승인자 역할의 지원자가 +풀 리퀘스트를 심사하고 리뷰한다. 이 +사람은 일주일 동안 "PR 랭글러(Wrangler)"이다. 자세한 +정보는 [PR 랭글러 스케줄러](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 참고한다. PR 랭글러가 되려면, 매주 SIG Docs 회의에 참석하고 자원한다. 이번 주에 해당 일정이 없는 경우에도, 아직 리뷰 중이 아닌 +풀 리퀘스트(PR)를 여전히 리뷰할 수 있다. + +로테이션 외에도, 봇은 영향을 받는 파일의 소유자를 기반으로 +PR에 대한 리뷰어와 승인자를 할당한다. + +{{% /capture %}} + + +{{% capture body %}} + +## PR 리뷰 + +쿠버네티스의 문서는 [쿠버네티스의 코드 리뷰 프로세스](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process)를 따른다. + +[풀 리퀘스트 리뷰](/ko/docs/contribute/review/reviewing-prs)에 설명된 모든 내용이 적용되지만, 리뷰어와 승인자도 다음을 수행해야 한다. + +- `/assign` Prow 명령을 사용하여 필요에 따라 특정 리뷰어를 PR에 할당한다. 이는 코드 기여자에게 +기술 리뷰를 요청할 때 특히 중요하다. + + {{< note >}} + 마크다운 파일 맨 위에 있는 헤더의 `reviewers` 필드를 보고 기술 리뷰를 + 제공할 수 있는 사람을 확인한다. + {{< /note >}} + +- PR이 [콘텐츠](/docs/contribute/style/content-guide/)와 [스타일](/docs/contribute/style/style-guide/) 가이드를 따르는 지 확인한다. 그렇지 않은 경우 가이드의 관련 부분에 작성자를 연결한다. +- 적용이 가능한 경우 GitHub **Request Changes** 옵션을 사용하여 PR 작성자에게 변경을 제안한다. +- 제안한 사항이 구현된 경우, `/approve` 또는 `/lgtm` Prow 명령을 사용하여 GitHub에서 리뷰 상태를 변경한다. + +## 다른 사람의 PR에 커밋 + +PR 코멘트를 남기는 것이 도움이 되지만, 대신 다른 사람의 PR에 커밋을 +해야 하는 경우가 있다. + +다른 사람이 명시적으로 요청하거나, 오랫동안 +중단된 PR을 재개하려는 경우가 아니라면 다른 사람에게서 "가져오지" 마라. 단기적으로는 +작업이 빠를 수 있지만, 그 사람이 기여할 기회를 박탈하게 된다. + +사용할 프로세스는 이미 PR의 범위에 있는 파일을 편집해야 +하는지, 또는 PR이 아직 다루지 않은 파일을 편집해야 하는지에 따라 다르다. + +다음 중 하나에 해당하면 다른 사람의 PR에 커밋할 수 +없다. + +- PR 작성자가 브랜치를 + [https://github.com/kubernetes/website/](https://github.com/kubernetes/website/) + 리포지터리로 직접 푸시한 경우, 푸시 접근 권한이 있는 리뷰어만 다른 사용자의 PR에 커밋할 수 있다. + + {{< note >}} + 다음 번부터는 PR을 열기 전에 작성자가 브랜치를 자신의 포크로 + 푸시하도록 권장한다. + {{< /note >}} + +- PR 작성자가 승인자의 수정을 명시적으로 허용하지 않는다. + +## 리뷰를 위한 Prow 명령 + +[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md)는 +풀 리퀘스트 (PR)에 대한 작업을 실행하는 쿠버네티스 기반 CI/CD 시스템이다. Prow는 +챗봇 스타일 명령으로 쿠버네티스 +조직 전체에서 [레이블 추가와 +제거](#이슈-레이블-추가와-제거), 이슈 종료 및 승인자 할당과 같은 GitHub 작업을 처리할 수 ​​있다. `/` 형식을 사용하여 Prow 명령을 GitHub 코멘트로 입력한다. + +리뷰어와 승인자가 사용하는 가장 일반적인 Prow 명령은 다음과 같다. + +{{< table caption="리뷰를 위한 Prow 명령" >}} +Prow 명령 | 역할 제한 | 설명 +:------------|:------------------|:----------- +`/lgtm` | 누구나, 리뷰어나 승인자가 사용한다면 자동화를 트리거한다. | PR 리뷰를 마치고 변경 사항에 만족했음을 나타낸다. +`/approve` | 승인자 | PR을 병합(merge)하기 위해 승인한다. +`/assign` | 리뷰어 또는 승인자 | PR을 리뷰하거나 승인할 사람을 지정한다. +`/close` | 리뷰어 또는 승인자 | 이슈 또는 PR을 닫는다. +`/hold` | 누구나 | 자동으로 병합할 수 없음을 나타내는 `do-not-merge/hold` 레이블을 추가한다. +`/hold cancel` | 누구나 | `do-not-merge/hold` 레이블을 제거한다. +{{< /table >}} + +PR에서 사용할 수 있는 명령의 전체 목록을 보려면 +[Prow 명령 레퍼런스](https://prow.k8s.io/command-help)를 참고한다. + +## 이슈 심사와 분류 + + +일반적으로, SIG Docs는 [쿠버네티스 이슈 심사](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md) 프로세스를 따르며 동일한 레이블을 사용한다. + + +이 GitHub 이슈 [필터](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)는 +심사가 필요한 이슈를 찾는다. + +### 이슈 심사 + +1. 이슈 확인 + - 이슈가 website 문서에 관한 것인지 확인한다. 질문에 답하거나 + 리소스에 리포터를 지정하면 일부 이슈를 신속하게 종결할 수 있다. 자세한 내용은 + [지원 요청 또는 코드 버그 리포트](#지원-요청-또는-코드-버그-리포트) 섹션을 참고한다. + - 이슈가 가치가 있는지 평가한다. + - 이슈의 내용에 실행할 수 있는 세부 사항이 충분하지 않거나 템플릿의 내용이 + 제대로 작성되지 않은 경우 `triage/needs-information` 레이블을 추가한다. + - `lifecycle/stale` 과 `triage/needs-information` 레이블이 모두 있으면 이슈를 닫는다. + +2. 우선순위 레이블을 + 추가한다([이슈 심사 가이드라인](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority)은 우선순위 레이블을 자세히 정의함). + + {{< table caption="이슈 레이블" >}} + 레이블 | 설명 + :------------|:------------------ + `priority/critical-urgent` | 이 작업을 지금 즉시 수행한다. + `priority/important-soon` | 3개월 이내에 이 작업을 수행한다. + `priority/important-longterm` | 6개월 이내에 이 작업을 수행한다. + `priority/backlog` | 무기한 연기할 수 있다. 자원이 있을 때 수행한다. + `priority/awaiting-more-evidence` | 잠재적으로 좋은 이슈에 대해 잊지 않도록 표시한다. + `help` 또는 `good first issue` | 쿠버네티스나 SIG Docs 경험이 거의 없는 사람에게 적합하다. 자세한 내용은 [도움이 필요함 및 좋은 첫 번째 이슈 레이블](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md)을 참고한다. + + {{< /table >}} + + 재량에 따라, 이슈의 소유권을 가져와서 PR을 + 제출한다(특히, 이미 수행 중인 작업과 관련이 있거나 빠르다면). + +이슈 심사에 대해 질문이 있다면, 슬랙의 `#sig-docs` 채널이나 +[kubernetes-sig-docs 메일링리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 문의한다. + +## 이슈 레이블 추가와 제거 + +레이블을 추가하려면, 다음의 형식 중 하나로 코멘트를 남긴다. + +- `/` (예: `/good-first-issue`) +- `/ ` (예: `/triage needs-information` 또는 `/language ko`) + +레이블을 제거하려면, 다음의 형식 중 하나로 코멘트를 남긴다. + +- `/remove-` (예: `/remove-help`) +- `/remove- ` (예: `/remove-triage needs-information`) + +두 경우 모두, 사용하려는 레이블은 이미 존재하는 레이블이어야 한다. 존재하지 않는 레이블을 추가하려고 하면, 명령이 +자동으로 무시된다. + +모든 레이블 목록에 대해서는 [website 리포지터리의 레이블 섹션](https://github.com/kubernetes/website/labels)을 참고한다. SIG Docs에서 모든 레이블을 사용하는 것은 아니다. + +### 이슈의 lifecycle 레이블 + +이슈는 일반적으로 신속하게 열리고 닫힌다. +그러나, 가끔씩은 이슈가 열린 후 비활성 상태로 있다. +어떤 경우에는 이슈가 90일 이상 열려 있을 수도 있다. + +{{< table caption="이슈의 lifecycle 레이블" >}} +레이블 | 설명 +:------------|:------------------ +`lifecycle/stale` | 90일이 지나도 아무런 활동이 없는 이슈는 자동으로 오래된 것(stale)으로 표시된다. `/remove-lifecycle stale` 명령을 사용하여 라이프사이클을 수동으로 되돌리지 않으면 이슈가 자동으로 닫힌다. +`lifecycle/frozen` | 90일 동안 활동이 없어도 이 레이블의 이슈는 오래된 것(stale)으로 바뀌지 않는다. 사용자는 `priority/important-longterm` 레이블이 있는 이슈처럼 90일보다 훨씬 오래 열려 있어야 하는 이슈에 이 레이블을 수동으로 추가한다. +{{< /table >}} + +## 특별한 이슈 유형의 처리 + +SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의 이슈를 +자주 경험하게 된다. + +### 중복된 이슈 + +단일 문제에 대해 하나 이상의 이슈가 열려 있으면, 이를 단일 이슈로 합친다. +열린 상태를 유지할 이슈를 결정한 다음(또는 +새로운 이슈를 열어야 함), 모든 관련 정보로 이동하여 관련 이슈를 연결해야 한다. +마지막으로, 동일한 문제를 설명하는 다른 모든 이슈에 +`triage/duplicate` 레이블을 지정하고 닫는다. 하나의 이슈만 해결하는 것으로 혼동을 줄이고 +같은 문제에 대한 중복 작업을 피할 수 있다. + +### 깨진 링크 이슈 + +깨진 링크 이슈가 API 문서나 `kubectl` 문서에 있는 경우, 문제가 완전히 이해될 때까지 `/priority critical-urgent` 레이블을 할당한다. 다른 모든 깨진 링크 이슈는 수동으로 수정해야하므로, `/priority important-longterm` 를 할당한다. + +### 블로그 이슈 + +[쿠버네티스 블로그](https://kubernetes.io/blog/) 항목은 시간이 지남에 따라 +구식이 될 것으로 예상한다. 따라서, 1년 미만의 블로그 항목만 유지 관리한다. +1년이 지난 블로그 항목과 관련된 이슈일 경우, +수정하지 않고 이슈를 닫는다. + +### 지원 요청 또는 코드 버그 리포트 + +문서에 대한 일부 이슈는 실제로 기본 코드와 관련된 이슈이거나, 튜토리얼과 +같은 무언가가 작동하지 않을 때 도움을 요청하는 것이다. +문서와 관련이 없는 이슈의 경우, `triage/support` 레이블과 함께 요청자에게 지원받을 수 있는 곳(슬랙, Stack Overflow)을 +알려주며 이슈를 닫고, 기능 관련 버그에 대한 이슈인 경우, +관련 리포지터리를 코멘트로 남긴다(`kubernetes/kubernetes` 는 +시작하기 좋은 곳이다). + +지원 요청에 대한 샘플 응답은 다음과 같다. + +```none +이 이슈는 지원 요청과 비슷하지만 +문서 관련 이슈와는 관련이 없는 것 같습니다. +[쿠버네티스 슬랙](http://slack.k8s.io/)의 +`#kubernetes-users` 채널에서 질문을 하시기 바랍니다. 또한, +[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)와 +같은 리소스를 검색하여 유사한 질문에 대한 답변을 +얻을 수도 있습니다. + +https://github.com/kubernetes/kubernetes 에서 +쿠버네티스 기능 관련 이슈를 열 수도 있습니다. + +문서에 대한 이슈인 경우 이 이슈를 다시 여십시오. +``` + +샘플 코드 버그 리포트 응답은 다음과 같다. + +```none +이 이슈는 문서에 대한 이슈보다 코드에 대한 이슈와 +비슷합니다. https://github.com/kubernetes/kubernetes/issues 에서 +이슈를 여십시오. + +문서에 대한 이슈인 경우 이 이슈를 다시 여십시오. +``` + + +{{% /capture %}} diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md new file mode 100644 index 0000000000..c220e9599c --- /dev/null +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -0,0 +1,98 @@ +--- +title: 풀 리퀘스트 리뷰 +content_template: templates/concept +main_menu: true +weight: 10 +--- + +{{% capture overview %}} + +누구나 문서화에 대한 풀 리퀘스트를 리뷰할 수 있다. 쿠버네티스 website 리포지터리의 [풀 리퀘스트](https://github.com/kubernetes/website/pulls) 섹션을 방문하여 열린(open) 풀 리퀘스트를 확인한다. + +문서화에 대한 풀 리퀘스트를 리뷰하는 것은 +쿠버네티스 커뮤니티에 자신을 소개하는 훌륭한 방법이다. +아울러, 코드 베이스(code base)를 배우고 다른 기여자와 신뢰를 구축하는 데 도움이 된다. + +리뷰하기 전에, 다음을 수행하는 것이 좋다. + +- 적합한 코멘트를 남길 수 있도록 [콘텐츠 가이드](/docs/contribute/style/content-guide/)와 +[스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다. +- 쿠버네티스 문서화 커뮤니티의 다양한 [역할과 책임](/docs/contribute/participating/#roles-and-responsibilities)을 이해한다. + +{{% /capture %}} + +{{% capture body %}} + +## 시작하기 전에 + +리뷰를 시작하기 전에 다음을 명심하자. + +- [CNCF 행동 강령](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ko.md)을 읽고 항상 준수한다. +- 정중하고, 사려 깊고, 도움이 되자. +- PR의 긍정적인 측면과 변화에 대한 의견을 남긴다. +- 당신의 리뷰를 어떻게 받아들일지에 대해 공감하고 주의한다. +- 좋은 의도를 가지고 명확한 질문을 한다. +- 숙련된 기여자인 경우, 작업에 광범위한 변경이 필요한 새 기여자와 쌍을 이루어 리뷰해 본다. + +## 리뷰 과정 + +일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. + +1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로 + 이동한다. + 쿠버네티스 website와 문서에 대한 모든 열린 풀 리퀘스트 목록이 + 표시된다. + +2. 다음 레이블 중 하나 또는 모두를 사용하여 열린 PR을 필터링한다. + - `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/docs/contribute/new-content/overview/#sign-the-cla)을 참고한다. + - `language/en`(권장): 영어 문서에 대한 PR 전용 필터이다. + - `size/`: 특정 크기의 PR을 필터링한다. 새로 시작하는 사람이라면, 더 작은 PR로 시작한다. + + 또한, PR이 진행 중인 작업으로 표시되지 않았는지 확인한다. `work in progress` 레이블을 사용하는 PR은 아직 리뷰할 준비가 되지 않은 PR이다. + +3. 리뷰할 PR을 선택한 후, 다음을 통해 변경 사항을 이해한다. + - PR 설명을 통해 변경 사항을 이해하고, 연결된 이슈 읽기 + - 다른 리뷰어의 의견 읽기 + - **Files changed** 탭을 클릭하여 변경된 파일과 행 보기 + - **Conversation** 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여 **deploy/netlify** 행의 **Details** 링크를 클릭하고 Netlify 미리보기 빌드의 변경 사항을 확인 + +4. **Files changed** 탭으로 이동하여 리뷰를 시작한다. + 1. 코멘트을 달려는 줄 옆에 있는 `+` 기호를 클릭한다. + 2. 행에 대한 의견을 작성하고 **Add single comments**(작성할 의견이 하나만 있는 경우) 또는 **Start a review**(작성할 의견이 여러 개인 경우)를 클릭한다. + 3. 완료되면, 페이지 상단에서 **Review changes** 를 클릭한다. 여기에서 + 리뷰에 대한 요약을 추가하고(기여자에게 긍정적인 의견을 남겨주기 바란다!), + PR을 승인하거나, 의견을 보내거나 필요에 따라 변경을 요청할 수 있다. 새로운 기여자는 + 항상 **Comment** 를 선택해야 한다. + +## 리뷰 체크리스트 + +리뷰할 때, 다음을 시작점으로 사용한다. + +### 언어와 문법 + +- 언어나 문법에 명백한 오류가 있는가? 무언가를 표현하는 더 좋은 방법이 있는가? +- 더 간단한 단어로 대체될 수 있는 복잡하거나 오래된 단어가 있는가? +- 비 차별적 대안으로 대체될 수 있는 단어, 용어 또는 문구가 있는가? +- 단어 선택과 대소문자는 [스타일 가이드](/docs/contribute/style/style-guide/)를 따르는가? +- 더 짧고 간결하게 만들 수 있는 긴 문장이 있는가? +- 목록이나 표로 더 잘 표현할 수 있는 긴 단락이 있는가? + +### 콘텐츠 + +- 쿠버네티스 사이트의 다른 곳에도 비슷한 콘텐츠가 있는가? +- 콘텐츠가 오프-사이트, 개별 업체, 또는 공개되지 않은 소스 문서에 과도하게 링크되는가? + +### 웹 사이트 + +- 이 PR이 페이지 제목, slug/alias 또는 앵커(anchor) 링크를 변경 또는 제거하는가? 그렇다면, 이 PR의 결과로 끊어진 링크가 있는가? slug를 변경 없이 페이지 제목을 변경하는 등의 다른 옵션이 있는가? +- PR이 새로운 페이지를 소개하는가? 그렇다면, + - 페이지가 올바른 [페이지 템플릿](/docs/contribute/style/page-templates/)과 연관된 Hugo 단축 코드를 사용하는가? + - 섹션의 측면 탐색에 페이지가 올바르게 나타나는가? + - 페이지가 [문서 홈](/ko/docs/home/) 목록에 나타나야 하는가? +- 변경 사항이 Netlify 미리보기에 표시되는가? 목록, 코드 블록, 표, 메모 및 이미지에 특히 주의한다. + +### 기타 + +오타나 공백과 같은 작은 이슈의 PR인 경우, 코멘트 앞에 `nit:` 를 추가한다. 이를 통해 문서의 저자는 이슈가 긴급하지 않다는 것을 알 수 있다. + +{{% /capture %}} diff --git a/content/ko/docs/contribute/style/_index.md b/content/ko/docs/contribute/style/_index.md new file mode 100644 index 0000000000..69ece73a9a --- /dev/null +++ b/content/ko/docs/contribute/style/_index.md @@ -0,0 +1,9 @@ +--- +title: 문서 스타일 개요 +main_menu: true +weight: 80 +--- + +이 섹션의 주제는 문서 작성 스타일, 컨텐츠 형식과 +구성, 쿠버네티스 문서화에 적합하게 사용자 정의된 Hugo 사용 방법에 대한 +가이드를 제공한다. diff --git a/content/ko/docs/reference/glossary/cloud-controller-manager.md b/content/ko/docs/reference/glossary/cloud-controller-manager.md new file mode 100644 index 0000000000..20121a9371 --- /dev/null +++ b/content/ko/docs/reference/glossary/cloud-controller-manager.md @@ -0,0 +1,23 @@ +--- +title: 클라우드 컨트롤 매니저 +id: cloud-controller-manager +date: 2018-04-12 +full_link: /ko/docs/concepts/architecture/cloud-controller/ +short_description: > + 쿠버네티스를 타사 클라우드 공급자와 통합하는 컨트롤 플레인 컴포넌트. +aka: +tags: +- core-object +- architecture +- operation +--- + 클라우드별 컨트롤 로직을 포함하는 쿠버네티스 +{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} 컴포넌트이다. +클라우트 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, +해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와 상호 작용하는 컴포넌트를 분리할 수 있다. + + + +쿠버네티스와 기본 클라우드 인프라스터럭처 간의 상호 운용성 로직을 +분리함으로써, cloud-controller-manager 컴포넌트는 클라우드 공급자가 +주요 쿠버네티스 프로젝트와 다른 속도로 기능들을 릴리스할 수 있도록 한다. diff --git a/content/ko/docs/reference/glossary/configmap.md b/content/ko/docs/reference/glossary/configmap.md new file mode 100755 index 0000000000..06cd2c9c46 --- /dev/null +++ b/content/ko/docs/reference/glossary/configmap.md @@ -0,0 +1,20 @@ +--- +title: 컨피그맵(ConfigMap) +id: configmap +date: 2018-04-12 +full_link: /docs/concepts/configuration/configmap/ +short_description: > + 키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다. 볼륨에서 환경 변수, 커맨드-라인 인수 또는 구성 파일로 사용될 수 있다. + +aka: +tags: +- core-object +--- + 키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다. +{{< glossary_tooltip text="파드" term_id="pod" >}}는 +{{< glossary_tooltip text="볼륨" term_id="volume" >}}에서 +환경 변수, 커맨드-라인 인수 또는 구성 파일로 컨피그맵을 사용할 수 있다. + + + +컨피그맵을 사용하면 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에서 환경별 구성을 분리하여, 애플리케이션을 쉽게 이식할 수 있다. diff --git a/content/ko/docs/reference/glossary/control-plane.md b/content/ko/docs/reference/glossary/control-plane.md index 4cf2abbf5a..96b344ef76 100644 --- a/content/ko/docs/reference/glossary/control-plane.md +++ b/content/ko/docs/reference/glossary/control-plane.md @@ -11,3 +11,15 @@ tags: - fundamental --- 컨테이너의 라이프사이클을 정의, 배포, 관리하기 위한 API와 인터페이스들을 노출하는 컨테이너 오케스트레이션 레이어. + + + +이 계층은 다음과 같은 다양한 컴포넌트로 구성된다(그러나 제한되지는 않는다). + + * {{< glossary_tooltip text="etcd" term_id="etcd" >}} + * {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} + * {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}} + * {{< glossary_tooltip text="컨트롤러 매니저" term_id="kube-controller-manager" >}} + * {{< glossary_tooltip text="클라우드 컨트롤러 매니저" term_id="cloud-controller-manager" >}} + + 이러한 컴포넌트는 기존 운영체제 서비스(데몬) 또는 컨테이너로 실행할 수 있다. 이러한 컴포넌트를 실행하는 호스트를 {{< glossary_tooltip text="마스터" term_id="master" >}}라 한다. \ No newline at end of file diff --git a/content/ko/docs/reference/glossary/cronjob.md b/content/ko/docs/reference/glossary/cronjob.md index 452f95a4af..b0f8342b66 100755 --- a/content/ko/docs/reference/glossary/cronjob.md +++ b/content/ko/docs/reference/glossary/cronjob.md @@ -4,7 +4,7 @@ id: cronjob date: 2018-04-12 full_link: /ko/docs/concepts/workloads/controllers/cron-jobs/ short_description: > - 주기적인 일정에 따라 실행되는 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리. + 정기적인 일정으로 실행되는 반복 작업(잡). aka: tags: diff --git a/content/ko/docs/reference/glossary/deployment.md b/content/ko/docs/reference/glossary/deployment.md index e21c413d70..00bd0d12fb 100755 --- a/content/ko/docs/reference/glossary/deployment.md +++ b/content/ko/docs/reference/glossary/deployment.md @@ -4,7 +4,7 @@ id: deployment date: 2018-04-12 full_link: /ko/docs/concepts/workloads/controllers/deployment/ short_description: > - 복제된(replicated) 애플리케이션을 관리하는 API 오브젝트. + 클러스터에서 복제된 애플리케이션을 관리한다. aka: tags: @@ -12,9 +12,10 @@ tags: - core-object - workload --- - 복제된 애플리케이션을 관리하는 API 오브젝트. + 일반적으로 로컬 상태가 없는 파드를 실행하여 복제된 애플리케이션을 관리하는 API 오브젝트. -각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며, 파드는 클러스터의 {{< glossary_tooltip text="노드" term_id="node" >}}에 분산된다. - +각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며, +파드는 클러스터의 {{< glossary_tooltip text="노드" term_id="node" >}}에 분산된다. +로컬 상태가 필요한 워크로드의 경우 {{< glossary_tooltip term_id="StatefulSet" >}}의 사용을 고려한다. \ No newline at end of file diff --git a/content/ko/docs/reference/glossary/pod.md b/content/ko/docs/reference/glossary/pod.md index c7a4d4debc..565361ea7b 100755 --- a/content/ko/docs/reference/glossary/pod.md +++ b/content/ko/docs/reference/glossary/pod.md @@ -4,7 +4,7 @@ id: pod date: 2018-04-12 full_link: /ko/docs/concepts/workloads/pods/pod-overview/ short_description: > - 가장 작고 단순한 쿠버네티스 오브젝트. 파드는 사용자 클러스터에서 동작하는 컨테이너의 집합을 나타낸다. + 파드는 클러스터에서 실행 중인 컨테이너의 집합을 나타낸다. aka: tags: diff --git a/content/ko/docs/reference/glossary/service-account.md b/content/ko/docs/reference/glossary/service-account.md index 1de65927ba..d70aabf794 100755 --- a/content/ko/docs/reference/glossary/service-account.md +++ b/content/ko/docs/reference/glossary/service-account.md @@ -1,5 +1,5 @@ --- -title: 서비스 어카운트(ServiceAccount) +title: 서비스어카운트(ServiceAccount) id: service-account date: 2018-04-12 full_link: /docs/tasks/configure-pod-container/configure-service-account/ diff --git a/content/ko/docs/reference/glossary/statefulset.md b/content/ko/docs/reference/glossary/statefulset.md index 71fde2fc06..afb2dd3ba9 100755 --- a/content/ko/docs/reference/glossary/statefulset.md +++ b/content/ko/docs/reference/glossary/statefulset.md @@ -4,7 +4,7 @@ id: statefulset date: 2018-04-12 full_link: /ko/docs/concepts/workloads/controllers/statefulset/ short_description: > - 파드 집합의 디플로이먼트와 스케일링을 관리하며, 파드들의 *순서 및 고유성을 보장한다* . + 내구성이 있는 스토리지와 파드별로 지속성 식별자를 사용해서 파드 집합의 디플로이먼트와 스케일링을 관리한다. aka: tags: @@ -17,4 +17,6 @@ tags: -{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 유사하게, 스테이트풀 셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀 셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다. +{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 유사하게, 스테이트풀셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다. + +스토리지 볼륨을 사용해서 워크로드에 지속성을 제공하려는 경우, 솔루션의 일부로 스테이트풀셋을 사용할 수 있다. 스테이트풀셋의 개별 파드는 장애에 취약하지만, 퍼시스턴트 파드 식별자는 기존 볼륨을 실패한 볼륨을 대체하는 새 파드에 더 쉽게 일치시킬 수 있다. diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 94fd790fb9..8956d72474 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -64,7 +64,7 @@ kubectl config get-contexts # 컨텍스트 리스트 kubectl config current-context # 현재 컨텍스트 출력 kubectl config use-context my-cluster-name # my-cluster-name를 기본 컨텍스트로 설정 -# 기본 인증을 지원하는 새로운 클러스터를 kubeconf에 추가한다 +# 기본 인증을 지원하는 새로운 사용자를 kubeconf에 추가한다 kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword # 해당 컨텍스트에서 모든 후속 kubectl 커맨드에 대한 네임스페이스를 영구적으로 저장한다 @@ -342,6 +342,21 @@ kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든 `-o=wide` | 추가 정보가 포함된 일반-텍스트 형식으로 출력하고, 파드의 경우 노드 명이 포함 `-o=yaml` | YAML 형식의 API 오브젝트 출력 +`-o=custom-columns` 의 사용 예시: + +```bash +# 클러스터에서 실행 중인 모든 이미지 +kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image' + + # "k8s.gcr.io/coredns:1.6.2" 를 제외한 모든 이미지 +kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image' + +# 이름에 관계없이 메타데이터 아래의 모든 필드 +kubectl get pods -A -o=custom-columns='DATA:metadata.*' +``` + +More examples in the kubectl [reference documentation](/docs/reference/kubectl/overview/#custom-columns). + ### Kubectl 출력 로그 상세 레벨(verbosity)과 디버깅 Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그 레벨을 나타내는 정수로 제어된다. 일반적인 쿠버네티스 로깅 규칙과 관련 로그 레벨이 [여기](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)에 설명되어 있다. diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index 82ebdccb29..1ea418fd5e 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -50,28 +50,28 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery | Lisp | [github.com/brendandburns/cl-k8s](https://github.com/brendandburns/cl-k8s) | | Lisp | [github.com/xh4/cube](https://github.com/xh4/cube) | | Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) | -| Node.js | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) | -| Node.js | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) | | Node.js | [github.com/ajpauwels/easy-k8s](https://github.com/ajpauwels/easy-k8s) +| Node.js | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) | +| Node.js | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) | | Perl | [metacpan.org/pod/Net::Kubernetes](https://metacpan.org/pod/Net::Kubernetes) | -| PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) | | PHP | [github.com/allansun/kubernetes-php-client](https://github.com/allansun/kubernetes-php-client) | +| PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) | | PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) | | Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) | | Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) | | Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) | | Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) | -| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | | Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | +| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | | Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | | Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) | | Rust | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) | | Scala | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) | -| dotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | +| Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) | +| DotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | | DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | | Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | | Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) | -| Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | {{% /capture %}} diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md index 3aed39f400..3efc951e1b 100644 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -195,7 +195,7 @@ minikube start --driver= * virtualbox * vmwarefusion -* docker (EXPERIMENTAL) +* docker ([드라이버 설치](https://minikube.sigs.k8s.io/docs/drivers/docker/) * 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/)) @@ -457,11 +457,11 @@ Minikube에 대한 더 자세한 정보는, [제안](https://git.k8s.io/communit ## 추가적인 링크: -* **목표와 비목표**: Minikube 프로젝트의 목표와 비목표에 대해서는 [로드맵](https://git.k8s.io/minikube/docs/contributors/roadmap.md)을 살펴보자. -* **개발 가이드**: 풀 리퀘스트를 보내는 방법에 대한 개요는 [참여 가이드](https://git.k8s.io/minikube/CONTRIBUTING.md)를 살펴보자. -* **Minikube 빌드**: Minikube를 소스에서 빌드/테스트하는 방법은 [빌드 가이드](https://git.k8s.io/minikube/docs/contributors/build_guide.md)를 살펴보자. -* **새 의존성 추가하기**: Minikube에 새 의존성을 추가하는 방법에 대해서는, [의존성 추가 가이드](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)를 보자. -* **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는, [애드온 추가 가이드](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)를 보자. +* **목표와 비목표**: Minikube 프로젝트의 목표와 비목표에 대해서는 [로드맵](https://minikube.sigs.k8s.io/docs/contrib/roadmap/)을 살펴보자. +* **개발 가이드**: 풀 리퀘스트를 보내는 방법에 대한 개요는 [기여하기](https://minikube.sigs.k8s.io/docs/contrib/)를 살펴보자. +* **Minikube 빌드**: Minikube를 소스에서 빌드/테스트하는 방법은 [빌드 가이드](https://minikube.sigs.k8s.io/docs/contrib/building/)를 살펴보자. +* **새 의존성 추가하기**: Minikube에 새 의존성을 추가하는 방법에 대해서는, [의존성 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/drivers/)를 보자. +* **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는, [애드온 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/addons/)를 보자. * **MicroK8s**: 가상 머신을 사용하지 않으려는 Linux 사용자는 대안으로 [MicroK8s](https://microk8s.io/)를 고려할 수 있다. ## 커뮤니티 diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index 2520f1ed2d..7651fcc172 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -7,7 +7,7 @@ weight: 40 {{% capture overview %}} -{{< feature-state for_k8s_version="1.12" state="stable" >}} +{{< feature-state for_k8s_version="v1.12" state="stable" >}} kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러와 같은 컨트롤 플레인 구성요소에 전달되는 기본 플래그 `extraArgs` 필드를 노출한다. 이 구성요소는 다음 필드를 사용하도록 정의되어 있다. diff --git a/content/ko/docs/tasks/administer-cluster/highly-available-master.md b/content/ko/docs/tasks/administer-cluster/highly-available-master.md index cd9be9736c..880f4a4992 100644 --- a/content/ko/docs/tasks/administer-cluster/highly-available-master.md +++ b/content/ko/docs/tasks/administer-cluster/highly-available-master.md @@ -6,7 +6,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" >}} 구글 컴퓨트 엔진(Google Compute Engine, 이하 GCE)의 `kube-up`이나 `kube-down` 스크립트에 쿠버네티스 마스터를 복제할 수 있다. 이 문서는 kube-up/down 스크립트를 사용하여 고가용(HA) 마스터를 관리하는 방법과 GCE와 함께 사용하기 위해 HA 마스터를 구현하는 방법에 관해 설명한다. diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/_index.md b/content/ko/docs/tasks/administer-cluster/kubeadm/_index.md new file mode 100755 index 0000000000..6f01fc069a --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/_index.md @@ -0,0 +1,4 @@ +--- +title: "kubeadm으로 관리하기" +weight: 10 +--- diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md new file mode 100644 index 0000000000..f24ae129ec --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -0,0 +1,443 @@ +--- +title: kubeadm 클러스터 업그레이드 +content_template: templates/task +weight: 20 +min-kubernetes-server-version: 1.18 +--- + +{{% capture overview %}} + +이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를 +1.17.x 버전에서 1.18.x 버전으로, 1.18.x 버전에서 1.18.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다. + +이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면, +이 페이지 대신 다음의 페이지들을 참고한다. + +- [kubeadm 클러스터를 1.16에서 1.17로 업그레이드](https://v1-17.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [kubeadm 클러스터를 1.15에서 1.16으로 업그레이드](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [kubeadm 클러스터를 1.14에서 1.15로 업그레이드](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/) +- [kubeadm 클러스터를 1.13에서 1.14로 업그레이드](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/) + +추상적인 업그레이드 작업 절차는 다음과 같다. + +1. 기본 컨트롤 플레인 노드를 업그레이드한다. +1. 추가 컨트롤 플레인 노드를 업그레이드한다. +1. 워커(worker) 노드를 업그레이드한다. + +{{% /capture %}} + +{{% capture prerequisites %}} + +- 1.17.0 버전 이상을 실행하는 kubeadm 쿠버네티스 클러스터가 있어야 한다. +- [스왑을 비활성화해야 한다](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux). +- 클러스터는 정적 컨트롤 플레인 및 etcd 파드 또는 외부 etcd를 사용해야 한다. +- [릴리스 노트]({{< latest-release-notes >}})를 주의 깊게 읽어야 한다. +- 데이터베이스에 저장된 앱-레벨 상태와 같은 중요한 컴포넌트를 반드시 백업한다. + `kubeadm upgrade` 는 워크로드에 영향을 미치지 않고, 쿠버네티스 내부의 컴포넌트만 다루지만, 백업은 항상 모범 사례일 정도로 중요하다. + +### 추가 정보 + +- 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다. +- 하나의 MINOR 버전에서 다음 MINOR 버전으로, + 또는 동일한 MINOR의 PATCH 버전 사이에서만 업그레이드할 수 있다. 즉, 업그레이드할 때 MINOR 버전을 건너 뛸 수 없다. + 예를 들어, 1.y에서 1.y+1로 업그레이드할 수 있지만, 1.y에서 1.y+2로 업그레이드할 수는 없다. + +{{% /capture %}} + +{{% capture steps %}} + +## 업그레이드할 버전 결정 + +1. 최신의 안정 버전인 1.18을 찾는다. + + {{< tabs name="k8s_install_versions" >}} + {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} + apt update + apt-cache madison kubeadm + # 목록에서 최신 버전 1.18을 찾는다 + # 1.18.x-00과 같아야 한다. 여기서 x는 최신 패치이다. + {{% /tab %}} + {{% tab name="CentOS, RHEL 또는 Fedora" %}} + yum list --showduplicates kubeadm --disableexcludes=kubernetes + # 목록에서 최신 버전 1.18을 찾는다 + # 1.18.x-0과 같아야 한다. 여기서 x는 최신 패치이다. + {{% /tab %}} + {{< /tabs >}} + +## 컨트롤 플레인 노드 업그레이드 + +### 첫 번째 컨트롤 플레인 노드 업그레이드 + +1. 첫 번째 컨트롤 플레인 노드에서 kubeadm을 업그레이드한다. + + {{< tabs name="k8s_install_kubeadm_first_cp" >}} + {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} + # 1.18.x-00에서 x를 최신 패치 버전으로 바꾼다. + apt-mark unhold kubeadm && \ + apt-get update && apt-get install -y kubeadm=1.18.x-00 && \ + apt-mark hold kubeadm + + # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 + apt-get update && \ + apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00 + {{% /tab %}} + {{% tab name="CentOS, RHEL 또는 Fedora" %}} + # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다. + yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes + {{% /tab %}} + {{< /tabs >}} + +1. 다운로드하려는 버전이 잘 받아졌는지 확인한다. + + ```shell + kubeadm version + ``` + +1. 컨트롤 플레인 노드를 드레인(drain)한다. + + ```shell + # 을 컨트롤 플레인 노드 이름으로 바꾼다. + kubectl drain --ignore-daemonsets + ``` + +1. 컨트롤 플레인 노드에서 다음을 실행한다. + + ```shell + sudo kubeadm upgrade plan + ``` + + 다음과 비슷한 출력이 표시되어야 한다. + + ``` + [upgrade/config] Making sure the configuration is correct: + [upgrade/config] Reading configuration from the cluster... + [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml' + [preflight] Running pre-flight checks. + [upgrade] Running cluster health checks + [upgrade] Fetching available versions to upgrade to + [upgrade/versions] Cluster version: v1.17.3 + [upgrade/versions] kubeadm version: v1.18.0 + [upgrade/versions] Latest stable version: v1.18.0 + [upgrade/versions] Latest version in the v1.17 series: v1.18.0 + + Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply': + COMPONENT CURRENT AVAILABLE + Kubelet 1 x v1.17.3 v1.18.0 + + Upgrade to the latest version in the v1.17 series: + + COMPONENT CURRENT AVAILABLE + API Server v1.17.3 v1.18.0 + Controller Manager v1.17.3 v1.18.0 + Scheduler v1.17.3 v1.18.0 + Kube Proxy v1.17.3 v1.18.0 + CoreDNS 1.6.5 1.6.7 + Etcd 3.4.3 3.4.3-0 + + You can now apply the upgrade by executing the following command: + + kubeadm upgrade apply v1.18.0 + + _____________________________________________________________________ + ``` + + 이 명령은 클러스터를 업그레이드할 수 있는지를 확인하고, 업그레이드할 수 있는 버전을 가져온다. + + {{< note >}} + 또한 `kubeadm upgrade` 는 이 노드에서 관리하는 인증서를 자동으로 갱신한다. + 인증서 갱신을 하지 않으려면 `--certificate-renewal=false` 플래그를 사용할 수 있다. + 자세한 내용은 [인증서 관리 가이드](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다. + {{}} + +1. 업그레이드할 버전을 선택하고, 적절한 명령을 실행한다. 예를 들면 다음과 같다. + + ```shell + # 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다. + sudo kubeadm upgrade apply v1.18.x + ``` + + + 다음과 비슷한 출력이 표시되어야 한다. + + ``` + [upgrade/config] Making sure the configuration is correct: + [upgrade/config] Reading configuration from the cluster... + [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml' + [preflight] Running pre-flight checks. + [upgrade] Running cluster health checks + [upgrade/version] You have chosen to change the cluster version to "v1.18.0" + [upgrade/versions] Cluster version: v1.17.3 + [upgrade/versions] kubeadm version: v1.18.0 + [upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y + [upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd] + [upgrade/prepull] Prepulling image for component etcd. + [upgrade/prepull] Prepulling image for component kube-apiserver. + [upgrade/prepull] Prepulling image for component kube-controller-manager. + [upgrade/prepull] Prepulling image for component kube-scheduler. + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager + [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd + [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-etcd + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler + [upgrade/prepull] Prepulled image for component etcd. + [upgrade/prepull] Prepulled image for component kube-apiserver. + [upgrade/prepull] Prepulled image for component kube-controller-manager. + [upgrade/prepull] Prepulled image for component kube-scheduler. + [upgrade/prepull] Successfully prepulled the images for all the control plane components + [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.18.0"... + Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46 + Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18 + Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366 + [upgrade/etcd] Upgrading to TLS for etcd + [upgrade/etcd] Non fatal issue encountered during upgrade: the desired etcd version for this Kubernetes version "v1.18.0" is "3.4.3-0", but the current etcd version is "3.4.3". Won't downgrade etcd, instead just continue + [upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests308527012" + W0308 18:48:14.535122 3082 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC" + [upgrade/staticpods] Preparing for "kube-apiserver" upgrade + [upgrade/staticpods] Renewing apiserver certificate + [upgrade/staticpods] Renewing apiserver-kubelet-client certificate + [upgrade/staticpods] Renewing front-proxy-client certificate + [upgrade/staticpods] Renewing apiserver-etcd-client certificate + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-apiserver.yaml" + [upgrade/staticpods] Waiting for the kubelet to restart the component + [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) + Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46 + Static pod: kube-apiserver-myhost hash: 609429acb0d71dce6725836dd97d8bf4 + [apiclient] Found 1 Pods for label selector component=kube-apiserver + [upgrade/staticpods] Component "kube-apiserver" upgraded successfully! + [upgrade/staticpods] Preparing for "kube-controller-manager" upgrade + [upgrade/staticpods] Renewing controller-manager.conf certificate + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-controller-manager.yaml" + [upgrade/staticpods] Waiting for the kubelet to restart the component + [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) + Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18 + Static pod: kube-controller-manager-myhost hash: c7a1232ba2c5dc15641c392662fe5156 + [apiclient] Found 1 Pods for label selector component=kube-controller-manager + [upgrade/staticpods] Component "kube-controller-manager" upgraded successfully! + [upgrade/staticpods] Preparing for "kube-scheduler" upgrade + [upgrade/staticpods] Renewing scheduler.conf certificate + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-scheduler.yaml" + [upgrade/staticpods] Waiting for the kubelet to restart the component + [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) + Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366 + Static pod: kube-scheduler-myhost hash: b1b721486ae0ac504c160dcdc457ab0d + [apiclient] Found 1 Pods for label selector component=kube-scheduler + [upgrade/staticpods] Component "kube-scheduler" upgraded successfully! + [upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace + [kubelet] Creating a ConfigMap "kubelet-config-1.18" in namespace kube-system with the configuration for the kubelets in the cluster + [kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.18" ConfigMap in the kube-system namespace + [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml" + [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials + [bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token + [bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster + [addons] Applied essential addon: CoreDNS + [addons] Applied essential addon: kube-proxy + + [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.18.0". Enjoy! + + [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. + ``` + +1. CNI 제공자 플러그인을 수동으로 업그레이드한다. + + CNI(컨테이너 네트워크 인터페이스) 제공자는 자체 업그레이드 지침을 따를 수 있다. + [애드온](/docs/concepts/cluster-administration/addons/) 페이지에서 + 사용하는 CNI 제공자를 찾고 추가 업그레이드 단계가 필요한지 여부를 확인한다. + + CNI 제공자가 데몬셋(DaemonSet)으로 실행되는 경우 추가 컨트롤 플레인 노드에는 이 단계가 필요하지 않다. + +1. 컨트롤 플레인 노드에 적용된 cordon을 해제한다. + + ```shell + # 을 컨트롤 플레인 노드 이름으로 바꾼다. + kubectl uncordon + ``` + +### 추가 컨트롤 플레인 노드 업그레이드 + +1. 첫 번째 컨트롤 플레인 노드와 동일하지만 다음을 사용한다. + + ``` + sudo kubeadm upgrade node + ``` + + 아래 명령 대신 위의 명령을 사용한다. + + ``` + sudo kubeadm upgrade apply + ``` + + 또한 `sudo kubeadm upgrade plan` 은 필요하지 않다. + +### kubelet과 kubectl 업그레이드 + +1. 모든 컨트롤 플레인 노드에서 kubelet 및 kubectl을 업그레이드한다. + + {{< tabs name="k8s_install_kubelet" >}} + {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} + # 1.18.x-00의 x를 최신 패치 버전으로 바꾼다 + apt-mark unhold kubelet kubectl && \ + apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \ + apt-mark hold kubelet kubectl + + # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 + apt-get update && \ + apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00 + {{% /tab %}} + {{% tab name="CentOS, RHEL 또는 Fedora" %}} + # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes + {{% /tab %}} + {{< /tabs >}} + +1. kubelet을 다시 시작한다. + + ```shell + sudo systemctl restart kubelet + ``` + +## 워커 노드 업그레이드 + +워커 노드의 업그레이드 절차는 워크로드를 실행하는 데 필요한 최소 용량을 보장하면서, +한 번에 하나의 노드 또는 한 번에 몇 개의 노드로 실행해야 한다. + +### kubeadm 업그레이드 + +1. 모든 워커 노드에서 kubeadm을 업그레이드한다. + + {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} + {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} + # 1.18.x-00의 x를 최신 패치 버전으로 바꾼다 + apt-mark unhold kubeadm && \ + apt-get update && apt-get install -y kubeadm=1.18.x-00 && \ + apt-mark hold kubeadm + + # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 + apt-get update && \ + apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00 + {{% /tab %}} + {{% tab name="CentOS, RHEL 또는 Fedora" %}} + # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes + {{% /tab %}} + {{< /tabs >}} + +### 노드 드레인 + +1. 스케줄 불가능(unschedulable)으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다. + + ```shell + # 을 드레이닝하려는 노드 이름으로 바꾼다. + kubectl drain --ignore-daemonsets + ``` + + 다음과 비슷한 출력이 표시되어야 한다. + + ``` + node/ip-172-31-85-18 cordoned + WARNING: ignoring DaemonSet-managed Pods: kube-system/kube-proxy-dj7d7, kube-system/weave-net-z65qx + node/ip-172-31-85-18 drained + ``` + +### kubelet 구성 업그레이드 + +1. 다음의 명령을 호출한다. + + ```shell + sudo kubeadm upgrade node + ``` + +### kubelet과 kubectl 업그레이드 + +1. 모든 워커 노드에서 kubelet 및 kubectl을 업그레이드한다. + + {{< tabs name="k8s_kubelet_and_kubectl" >}} + {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} + # 1.18.x-00의 x를 최신 패치 버전으로 바꾼다 + apt-mark unhold kubelet kubectl && \ + apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \ + apt-mark hold kubelet kubectl + + # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 + apt-get update && \ + apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00 + {{% /tab %}} + {{% tab name="CentOS, RHEL 또는 Fedora" %}} + # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes + {{% /tab %}} + {{< /tabs >}} + +1. kubelet을 다시 시작한다. + + ```shell + sudo systemctl restart kubelet + ``` + +### 노드에 적용된 cordon 해제 + +1. 스케줄 가능(schedulable)으로 표시하여 노드를 다시 온라인 상태로 만든다. + + ```shell + # 을 노드의 이름으로 바꾼다. + kubectl uncordon + ``` + +## 클러스터 상태 확인 + +모든 노드에서 kubelet을 업그레이드 한 후 kubectl이 클러스터에 접근할 수 있는 곳에서 다음의 명령을 실행하여 모든 노드를 다시 사용할 수 있는지 확인한다. + +```shell +kubectl get nodes +``` + +모든 노드에 대해 `STATUS` 열에 `Ready` 가 표시되어야 하고, 버전 번호가 업데이트되어 있어야 한다. + +{{% /capture %}} + +## 장애 상태에서의 복구 + +예를 들어 `kubeadm upgrade` 를 실행하는 중에 예기치 못한 종료로 인해 업그레이드가 실패하고 롤백하지 않는다면, `kubeadm upgrade` 를 다시 실행할 수 있다. +이 명령은 멱등성을 보장하며 결국 실제 상태가 선언한 의도한 상태인지 확인한다. + +잘못된 상태에서 복구하기 위해, 클러스터가 실행 중인 버전을 변경하지 않고 `kubeadm upgrade apply --force` 를 실행할 수도 있다. + +업그레이드하는 동안 kubeadm은 `/etc/kubernetes/tmp` 아래에 다음과 같은 백업 폴더를 작성한다. + +- `kubeadm-backup-etcd--