From 7786c86454f9d7db7c2d32d48bfa88fbda2ba9db Mon Sep 17 00:00:00 2001 From: Alexey Pyltsyn Date: Mon, 2 Mar 2020 08:08:42 +0300 Subject: [PATCH 001/194] Translate Advanced contributing page into Russian (#19230) --- content/ru/docs/contribute/advanced.md | 196 +++++++++++++++++++++++++ 1 file changed, 196 insertions(+) create mode 100644 content/ru/docs/contribute/advanced.md diff --git a/content/ru/docs/contribute/advanced.md b/content/ru/docs/contribute/advanced.md new file mode 100644 index 0000000000..b450c088b5 --- /dev/null +++ b/content/ru/docs/contribute/advanced.md @@ -0,0 +1,196 @@ +--- +title: Участие для опытных +slug: advanced +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +На этой странице предполагается, что вы изучили темы [Участие для начинающих](/ru/docs/contribute/start/) и [Участие для опытных](/ru/docs/contribute/intermediate/) и теперь хотите узнать ещё больше про то, как можно помочь проекту. Для решения некоторых задач вам потребуется использовать Git из командной строки и прочие другие инструменты. + +{{% /capture %}} + +{{% capture body %}} + +## Дежурный по PR на неделю + +[Утверждающие](/ru/docs/contribute/participating/#утверждающие) группы SIG Docs регулярно по очереди становятся дежурными по PR в репозитории и поэтому участвуют в [графике ротации PR-дежурного](https://github.com/kubernetes/website/wiki/PR-Wranglers#2019-schedule-q1q2) на неделю. + +В обязанности дежурного по PR входят: + +- Ежедневно проверять [открытые пулреквесты](https://github.com/kubernetes/website/pulls) для контроля качества и соблюдения рекомендаций по [оформлению](/docs/contribute/style/style-guide/) и [содержимому](/docs/contribute/style/content-guide/). + - В первую очередь просматривайте самые маленькие пулреквесты (`size/XS`), и только потом беритесь за самые большие (`size/XXL`). + - Проверяйте столько пулреквестов, сколько сможете. +- Проследить, что CLA подписан каждым участником. + - Помогайте новым участникам подписать [CLA](https://github.com/kubernetes/community/blob/master/CLA.md). + - Используйте [этот](https://github.com/zparnold/k8s-docs-pr-botherer) скрипт, чтобы автоматически напомнить участникам, не подписавшим CLA, чтобы они подписали CLA. +- Оставить свое мнение о предложенных изменениях и поспособствовать в проведении технического обзора от членов других SIG-групп. + - Предложить исправления для измененного контента в PR. + - Если вы хотите убедиться в правильности контента, прокомментируйте PR и задайте уточняющие вопросы. + - Добавьте нужны метки с `sig/`. + - Если нужно, то назначьте рецензентов из секции `reviewers:` в фронтальной части файла. + - Добавьте метки `Docs Review` и `Tech Review` для установки статуса проверки PR. + - Добавьте метку `Needs Doc Review` или `Needs Tech Review` для пулреквестов, которые ещё не были проверены. + - Добавьте метку `Doc Review: Open Issues` или `Tech Review: Open Issues` для пулреквестов, которые были проверены и требуют дополнительную информацию и выполнение действия перед слиянием. + - Добавьте метки `/lgtm` и `/approve` для пулреквестов, которые могут быть приняты. +- Объедините пулреквесты, если они готовы, либо закройте те, которые не могут быть приняты. +- Ежедневно отсортируйте и пометьте новые заявки. Обратитесь к странице [Участие для опытных](/ru/docs/contribute/intermediate/) для получения информации по использование метаданных SIG Docs. + +### Полезные ссылки на GitHub для дежурных + +Следующие ссылки помогут при дежурстве. После обработки заявок по трём первым ссылкам, как правило, список пулреквестов для проверки сократится. По указанным ссылкам вы найдете PR только в английскую версию, предназначенные для слияния в ветку `master` (кроме последней ссылки). + +- [Нет CLA, нет права на слияние](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): напомните участнику подписать CLA. Если об этом уже напомнил и бот, и человек, то закройте PR и напишите автору, что он может открыть свой PR после подписания CLA. +**Не проверяйте PR, если их авторы не подписали CLA!** +- [Требуется LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): если нужен проверка с технической точки зрения, попросите её провести одного из рецензентов, который предложил бот. Если требуется просмотр пулреквест со стороны группы документации или вычитка, то предложите изменения, либо сами измените PR, чтобы ускорить процесс принятия пулреквеста. +- [Имеет LGTM, нужно одобрение со стороны группы документации](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): выясните, нужно ли внести какие-либо дополнительные изменения или обновления, чтобы принять PR. Если по вашему мнению PR готов к слияния, оставьте комментарий с текстом `/approve`. +- [Быстрые результаты](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): если маленький PR направлен в основную ветку и не имеет условий для объединения. (поменяйте "XS" в метке с размером при работе с другими пулреквестами [XS, S, M, L, XL, XXL]). +- [Вне основной ветки](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): если PR отправлен в ветку `dev-`, значит он предназначается для будущего выпуска. Убедитесь, что [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) знает об этом, добавив комментарий с `/assign @`. Если он направлен в старую ветку, помогите автору PR изменить на более подходящую ветку. + +### Когда закрывать пулреквесты + +Обзоры и одобрения — это только один из способов, позволяющих держать список PR коротким и актуальным. Закрытие пулреквестов — альтернативный метод для этого. + +- Можете закрыть любой PR, если CLA-соглашение не было подписано в течение двух недель. +Авторы PR могут повторно открыть PR после подписания CLA, так что это безопасный способ убедиться, что ничто не будет объединено без подписанного CLA. + +- Закройте любой PR, если автор не отреагировал на комментарии или проверки в течение 2 или более недель. + +Не бойтесь закрывать пулреквесты. Участники с лёгкостью открыть и возобновить незаконченную работу. Зачастую уведомление о закрытии стимулировать автора возобновить и закончить свой вклад. + +Чтобы закрыть пулреквест, оставьте комментарий `/close` в PR. + +{{< note >}} + +Бот [`fejta-bot`](https://github.com/fejta-bot) автоматически помечает заявки как устаревшие после 90 дней отсутствия активности, а затем закрывает их после ещё 30 дней простоя, когда они становятся тухлыми. Дежурные по PR должны закрывать заявки после 14-30 дней бездействия. + +{{< /note >}} + +## Внесение улучшений + +[Члены](/ru/docs/contribute/participating/#члены) SIG Docs могут предлагать улучшения. + +После того, как вы давно начали работать над документацией Kubernetes, у наверняка появились какие-нибудь идеи по улучшению [руководства по оформлению](/docs/contribute/style/style-guide/), [руководства по оформлению](/docs/contribute/style/content-guide/), набору инструментов, который используется для создания документации, стилизации сайта, процессов проверки и объединения пулреквестов. Для максимальной открытости подобные типы предложений по улучшению должны обсуждаться на встречи SIG Docs или в [списке рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). +Помимо этого, это поможет разъяснить, как всё устроено в данный момент, и объяснить, почему так было принято, прежде чем предлагать радикальные изменения. Самый быстрый способ узнать ответы на вопросы о том, как в настоящее время работает документация, это задать их на канале `#sig-docs` Slack на [kubernetes.slack.com](https://kubernetes.slack.com). + +Когда обсуждение состоялось, а SIG-группа согласилась с желаемым результатом, вы можете работать над предлагаемыми изменениями наиболее приемлемым способом. Например, обновление руководства по оформлению или функциональности сайта может включать открытие пулреквеста, а изменение, связанное с тестированием документации, может предполагать взаимодействие с sig-testing. + +## Координация документации по выпуску Kubernetes + +[Утверждающие](/ru/docs/contribute/participating/#утверждающие) SIG Docs могут координировать документацию для выпуска Kubernetes. + +Каждый выпуск Kubernetes координируется командой людей, участвующих в специальной группе (Special Interest Group, SIG) sig-release. Другие члены команды в данном выпуске включают в себя общего руководителя выпуском, а также представителей sig-pm, sig-testing и др. Чтобы узнать больше о процессах выпуска версий Kubernetes, обратитесь к [https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release). + +Представитель SIG Docs для данного выпуска координирует следующие задачи: + +- Мониторинг электронной таблицы с отслеживанием функциональности на наличие новых или измененных возможностей, затрагивают документацию. Если документация для определенной функциональности не будет готова к выпуску, возможно, она не попадет в выпуск. +- Регулярное посещение встречи sig-release и обновлять информацию о статусе документации в выпуске. +- Проверка и вычитка документации по функциональности, подготовленной SIG-группой, ответственной за реализацию этой функциональности. +- Объединение связанных с выпуском пулреквестов и поддержка Git-ветки выпуска. +- Консультируйте других участников SIG Docs, которые хотят научиться выполнять эту роль в будущем. Это называется сопровождение (shadowing). +- Публикация изменений в документации, связанные с выпуском при размещении артефактов. + +Координация выпуска обычно занимает 3-4 месяца, а обязанности распределяются между утверждающими SIG Docs. + +## Амбассадор нового участника + +[Утверждающие](/ru/docs/contribute/participating/#утверждающие) SIG Docs могут выступать в качестве амбассадоров новых участников. + +Амбассадоры новых участников работают бок о бок, чтобы поприветствовать новых участников SIG Docs, предлагать PR новым участникам и консультировать новых участников в их собственных PR. + +Обязанности амбассадоров новых участников включают в себя: + +- Отвечать на вопросы новых участников на [Slack-канале Kubernetes #sig-docs](https://kubernetes.slack.com). +- Совместно работать с дежурным по PR, чтобы определять заявки, которые подойдут для решения новыми участниками. +- Консультировать новых участников в их PR. +- Помогать новых участникам в создании более сложных PR, чтобы они могли стать членами Kubernetes. +- [Оказывать содействие участникам](/ru/docs/contribute/advanced/#поддержка-нового-участника) на их пути становления членом в Kubernetes. + +Текущие амбассадоры новых участников объявляются на каждом собрании SIG Docs и на канале [#sig-docs в Kubernetes](https://kubernetes.slack.com). + +## Поддержка нового участника + +[Рецензенты](/ru/docs/contribute/participating/#рецензенты) SIG Docs могут содействовать новым участникам в членстве организации. + +Если участник сделал 5 значительных пулреквестов в один или несколько репозиториев Kubernetes, он имеет право на [членство](/ru/docs/contribute/participating#члены) в организации Kubernetes. Членство участника должно быть поддержано двумя спонсорами, которые уже являются рецензентами. + +Новые участники документации могут найти спонсоров в канале #sig-docs в [в Slack Kubernetes](https://kubernetes.slack.com) или в [списке рассылки SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). Если вы осознали полезность работы автора заявки на членство, вы добровольно можете поддержать (спонсировать) его. Когда они подадут заявку на членство, отреагируйте на заявку "+1" и напишите подробный комментарий о том, почему вы считаете, что кандидат отлично вписывается в члены организации Kubernetes. + +## Сопредседатель SIG + +[Утверждающие](/ru/docs/contribute/participating/#утверждающие) SIG Docs могут быть сопредседателями SIG Docs. + +### Требования + +Сопредседатели должны соответствовать следующим требованиям: + +- Быть утверждающим SIG Docs не меньше 6 месяцев +- [Руководить выпуском документации Kubernetes](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) или сопровождать два выпуска +- Понимание рабочих процессов и инструментов SIG Docs: git, Hugo, локализация, блог +- Понимать, как другие SIG-группы и репозитории Kubernetes влияют на рабочий процесс SIG Docs, включая: [команды в k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [процессы в k/community](https://github.com/kubernetes/community/tree/master/sig-docs), плагины в [k/test-infra](https://github.com/kubernetes/test-infra/) и роль [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture). +- Уделять не менее 5 часов в неделю (но зачастую больше) в течение как минимум 6 месяцев для выполнения обязанностей. + +### Обязанности + +Роль сопредседателя посвящена в основном одной из задач: сопредседатели управляют процессом и политикой, планируют и проводят собрания, назначают дежурных по PR и, как правило, делают то, что никто больше не хочет делать, для увеличения количества участников. + +Обязанности включают в себя: + +- Сосредоточить группу SIG Docs на достижении максимального счастья для разработчиков через отличную документацию +- Быть примером соблюдения [норм поведения сообщества]https://github.com/cncf/foundation/blob/master/code-of-conduct.md) и контролировать их выполнение членами SIG +- Изучение и внедрение передовых практик для SIG-группы, обновляя рекомендации по участию +- Планирование и проведение встреч SIG: еженедельные обновления информации, ежеквартальные ретроспективные/плановые совещания и многое другое +- Планирование и проведение спринтов по документации на мероприятиях KubeCon и других конференциях +- Набирать персонал и выступать в поддержку {{< glossary_tooltip text="CNCF" term_id="cncf" >}} и его платиновых партнеров, включая Google, Oracle, Azure, IBM и Huawei. +- Поддерживать нормальную работу SIG + +### Проведение продуктивных встреч + +Для планирования и проведения результативных встреч мы составили рекомендации, которые показывают и объясняют, как лучше всего их подготовить. + +**Соблюдайте [нормы поведения сообщества](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)**: + +- Привлекайте самый широкий круг участников к дискуссии и уважительно общайтесь между собой, стараясь никого не обидеть. + +**Сформулируйте четкую повестку дня**: + +- Определите конкретную цель встречи +- Опубликуйте программу дня заранее + +Для еженедельных встреч скопируйте примечания из предыдущей недели в раздел "Past meetings". + +**Работайте вместе для создания точных примечания**: + +- Запишите обсуждение встречи +- Подумайте над тем, чтобы делегировать роль стенографист кому-нибудь другому + +**Определяйте решения по пунктам повестки четко и точно**: + +- Записывайте решения по пунктам, кто будет ими заниматься и ожидаемую дату завершения + +**Руководите обсуждением, когда это необходимо**: + +- Если обсуждение выходит за пределы повестки дня, снова обратите внимание участников на обсуждаемую тему +- Найдите место для различных стилей ведения обсуждения, не отвлекаясь от темы обсуждения и уважая время людей + +**Уважайте время людей**: + +- Начинайте и заканчивайте встречи своевременно + +**Используйте Zoom эффективно**: + +- Ознакомьтесь с [рекомендациями Zoom для Kubernetes](https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md) +- Попробуйте попроситься быть ведущим в самом начале встречи, введя ключ ведущего + +Исполнение роли ведущего в Zoom + +### Запись встреч на Zoom + +Когда вам потребуется начать запись, нажмите пункт с надписью Record to Cloud. + +Если нужно остановить запись, нажмите на кнопку Stop. + +Запись автоматически загрузится на YouTube. + +{{% /capture %}} From 653fd205f763cba93bddd9f6210c3569bc981ac7 Mon Sep 17 00:00:00 2001 From: Merlin Dienst Date: Mon, 2 Mar 2020 12:10:42 +0100 Subject: [PATCH 002/194] Fixed typo in German kubernetes concepts (#19432) Kommanduzeilen -> Kommandozeilen --- content/de/docs/concepts/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/de/docs/concepts/_index.md b/content/de/docs/concepts/_index.md index b8fc0272db..82b5b0e5b0 100644 --- a/content/de/docs/concepts/_index.md +++ b/content/de/docs/concepts/_index.md @@ -52,7 +52,7 @@ Wenn Sie beispielsweise mit der Kubernetes-API ein Deployment-Objekt erstellen, ### Kubernetes Master -Der Kubernetes-Master ist für Erhalt des gewünschten Status Ihres Clusters verantwortlich. Wenn Sie mit Kubernetes interagieren, beispielsweise mit dem Kommanduzeilen-Tool `kubectl`, kommunizieren Sie mit dem Kubernetes-Master Ihres Clusters. +Der Kubernetes-Master ist für Erhalt des gewünschten Status Ihres Clusters verantwortlich. Wenn Sie mit Kubernetes interagieren, beispielsweise mit dem Kommandozeilen-Tool `kubectl`, kommunizieren Sie mit dem Kubernetes-Master Ihres Clusters. > Der Begriff "Master" bezeichnet dabei eine Reihe von Prozessen, die den Clusterstatus verwalten. Normalerweise werden diese Prozesse alle auf einem einzigen Node im Cluster ausgeführt. Dieser Node wird auch als Master bezeichnet. Der Master kann repliziert werden, um die Verfügbarkeit und Redundanz zu erhöhen. From 007080e2d212d0713cd425e4eed6b004fb8b9f9e Mon Sep 17 00:00:00 2001 From: Merlin Dienst Date: Mon, 2 Mar 2020 12:44:42 +0100 Subject: [PATCH 003/194] Fixed typo in line 208 (#19326) importORtieren -> importieren --- content/de/docs/setup/minikube.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/de/docs/setup/minikube.md b/content/de/docs/setup/minikube.md index f4d19ea80c..06734bd28f 100644 --- a/content/de/docs/setup/minikube.md +++ b/content/de/docs/setup/minikube.md @@ -205,7 +205,7 @@ Weitere Informationen zu unterstützten Treibern und zur Installation von Plugin ### Lokale Images durch erneute Verwendung des Docker-Daemon ausführen -Wenn Sie eine einzige Kubernetes VM verwenden, ist es sehr praktisch, den integrierten Docker-Daemon von Minikube wiederzuverwenden; Dies bedeutet, dass Sie auf Ihrem lokalen Computer keine Docker-Registy erstellen und das Image in die Registry importortieren müssen - Sie können einfach innerhalb desselben Docker-Daemons wie Minikube arbeiten, was lokale Experimente beschleunigt. Stellen Sie einfach sicher, dass Sie Ihr Docker-Image mit einem anderen Element als 'latest' versehen, und verwenden Sie dieses Tag, wenn Sie das Image laden. Andernfalls, wenn Sie keine Version Ihres Images angeben, wird es als `:latest` angenommen, mit der Pull-Image-Richtlinie von `Always` entsprechend, was schließlich zu `ErrImagePull` führen kann, da Sie möglicherweise noch keine Versionen Ihres Docker-Images in der Standard-Docker-Registry (normalerweise DockerHub) haben. +Wenn Sie eine einzige Kubernetes VM verwenden, ist es sehr praktisch, den integrierten Docker-Daemon von Minikube wiederzuverwenden; Dies bedeutet, dass Sie auf Ihrem lokalen Computer keine Docker-Registy erstellen und das Image in die Registry importieren müssen - Sie können einfach innerhalb desselben Docker-Daemons wie Minikube arbeiten, was lokale Experimente beschleunigt. Stellen Sie einfach sicher, dass Sie Ihr Docker-Image mit einem anderen Element als 'latest' versehen, und verwenden Sie dieses Tag, wenn Sie das Image laden. Andernfalls, wenn Sie keine Version Ihres Images angeben, wird es als `:latest` angenommen, mit der Pull-Image-Richtlinie von `Always` entsprechend, was schließlich zu `ErrImagePull` führen kann, da Sie möglicherweise noch keine Versionen Ihres Docker-Images in der Standard-Docker-Registry (normalerweise DockerHub) haben. Um mit dem Docker-Daemon auf Ihrem Mac/Linux-Computer arbeiten zu können, verwenden Sie den `docker-env`-Befehl in Ihrer Shell: From 9865699335611228894bebe1140c8aad8cb23ac1 Mon Sep 17 00:00:00 2001 From: Ihor Sychevskyi <26163841+Arhell@users.noreply.github.com> Date: Tue, 3 Mar 2020 00:27:38 +0200 Subject: [PATCH 004/194] fix image display in firefox browser (#19421) --- assets/sass/_tablet.sass | 3 +++ 1 file changed, 3 insertions(+) diff --git a/assets/sass/_tablet.sass b/assets/sass/_tablet.sass index 96b24322a2..90215de1af 100644 --- a/assets/sass/_tablet.sass +++ b/assets/sass/_tablet.sass @@ -133,18 +133,21 @@ $feature-box-div-width: 45% max-width: 25% max-height: 100% transform: translateY(-50%) + width: 100% &:nth-child(odd) padding-right: 210px .image-wrapper right: 0 + text-align: right &:nth-child(even) padding-left: 210px .image-wrapper left: 0 + text-align: left &:nth-child(1) padding-right: 0 From 06409da263b209483ccd9528b27a186cb80c6c38 Mon Sep 17 00:00:00 2001 From: Cria Hu Date: Tue, 3 Mar 2020 15:07:37 +0800 Subject: [PATCH 005/194] Modify sentences with poor translation (#19330) * Modify sentences with poor translation * Modify sentences with poor translation --- content/zh/docs/concepts/architecture/cloud-controller.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/zh/docs/concepts/architecture/cloud-controller.md b/content/zh/docs/concepts/architecture/cloud-controller.md index f3bdc03e1f..f313808371 100644 --- a/content/zh/docs/concepts/architecture/cloud-controller.md +++ b/content/zh/docs/concepts/architecture/cloud-controller.md @@ -235,19 +235,19 @@ The Service controller is responsible for listening to service create, update, a The Node controller contains the cloud-dependent functionality of the kubelet. Prior to the introduction of the CCM, the kubelet was responsible for initializing a node with cloud-specific details such as IP addresses, region/zone labels and instance type information. The introduction of the CCM has moved this initialization operation from the kubelet into the CCM. --> -节点控制器包含 kubelet 中依赖于云的功能，在引入 CCM 之前，kubelet 负责使用特定于云的详细信息（如 IP 地址，域/区标签和实例类型信息）初始化节点。CCM 的引入已将此初始化操作从 kubelet 转移到 CCM 中。 +节点控制器包含 kubelet 中云依赖的功能，在引入 CCM 之前，kubelet 负责使用特定于云平台的功能特性（如 IP 地址，域/区标签和实例类型信息）初始化节点。CCM 的引入已将此初始化操作从 kubelet 转移到 CCM 中。 -在这个新模型中，kubelet 初始化一个没有特定于云的信息的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用特定于云的信息初始化节点后，才会清除这种污点，便得该节点可被调度。 +在这个新模型中，kubelet 初始化一个没有特定于云平台的功能特性的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用云的规格信息初始化节点后，才会清除这种污点，便得该节点可被调度。 -在这个新模型中，kubelet 初始化一个没有特定于云的信息的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用特定于云的信息初始化节点后，才会清除这种污点，便得该节点可被调度。 +在这个新模型中，kubelet 初始化一个没有特定于云平台的功能特性的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用云的规格信息初始化节点后，才会清除这种污点，便得该节点可被调度。 ```sh - kubeadm alpha phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml - kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml - kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml - kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml + kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml + kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml + kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml + kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml cp -R /etc/kubernetes/pki /tmp/${HOST2}/ # 清理不可重复使用的证书 find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete - kubeadm alpha phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml - kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml - kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml - kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml + kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml + kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml + kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml + kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml cp -R /etc/kubernetes/pki /tmp/${HOST1}/ find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete - kubeadm alpha phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml - kubeadm alpha phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml - kubeadm alpha phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml - kubeadm alpha phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml + kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml + kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml + kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml + kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml # 不需要移动 certs 因为它们是给 HOST0 使用的 # 清理不应从此主机复制的证书 @@ -370,9 +370,9 @@ kubeadm 包含生成下述证书所需的所有必要的密码学工具；在这 既然证书和配置已经就绪，是时候去创建清单了。在每台主机上运行 `kubeadm` 命令来生成 etcd 使用的静态清单。 ```sh - root@HOST0 $ kubeadm alpha phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml - root@HOST1 $ kubeadm alpha phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml - root@HOST2 $ kubeadm alpha phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml + root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml + root@HOST1 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml + root@HOST2 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml ``` + +{{% capture overview %}} + +基于角色（Role）的访问控制（RBAC）是一种基于企业中用户的角色来调节控制对计算机或网络资源的访问方法。 +{{% /capture %}} + +{{% capture body %}} + +`RBAC` 使用 `rbac.authorization.k8s.io` {{< glossary_tooltip text="API 组" term_id="api-group" >}} +来驱动鉴权操作，允许管理员通过 Kubernetes API 动态配置策略。 + +在 1.8 版本中，RBAC 模式是稳定的并通过 rbac.authorization.k8s.io/v1 API 提供支持。 + +要启用 RBAC，在启动 API 服务器时添加 `--authorization-mode=RBAC` 参数。 + + + +## API 概述 + +本节介绍 RBAC API 所声明的四种顶级类型。用户可以像与其他 API 资源交互一样， +（通过 `kubectl`、API 调用等方式）与这些资源交互。例如， +命令 `kubectl apply -f (resource).yml` 可以用在这里的任何一个例子之上。 +尽管如此，建议读者循序渐进阅读下面的章节，由浅入深。 + + +### Role 和 ClusterRole + +在 RBAC API 中，一个角色包含一组相关权限的规则。权限是纯粹累加的（不存在拒绝某操作的规则）。 +角色可以用 `Role` 来定义到某个命名空间上， +或者用 `ClusterRole` 来定义到整个集群作用域。 + +一个 `Role` 只可以用来对某一命名空间中的资源赋予访问权限。 +下面的 `Role` 示例定义到名称为 "default" 的命名空间，可以用来授予对该命名空间中的 Pods 的读取权限： + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: pod-reader +rules: +- apiGroups: [""] # "" 指定核心 API 组 + resources: ["pods"] + verbs: ["get", "watch", "list"] +``` + +`ClusterRole` 可以授予的权限和 `Role` 相同， +但是因为 `ClusterRole` 属于集群范围，所以它也可以授予以下访问权限： + +* 集群范围资源 （比如 nodes） +* 非资源端点（比如 "/healthz"） +* 跨命名空间访问的有名字空间作用域的资源（如 Pods），比如运行命令`kubectl get pods --all-namespaces` 时需要此能力 + +下面的 `ClusterRole` 示例可用来对某特定命名空间下的 Secrets 的读取操作授权， +或者跨所有命名空间执行授权（取决于它是如何[绑定](#rolebinding-and-clusterrolebinding)的）: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + # 此处的 "namespace" 被省略掉是因为 ClusterRoles 是没有命名空间的。 + name: secret-reader +rules: +- apiGroups: [""] + resources: ["secrets"] + verbs: ["get", "watch", "list"] +``` + + +### RoleBinding 和 ClusterRoleBinding + +角色绑定（RoleBinding）是将角色中定义的权限赋予一个或者一组用户。 +它包含若干主体（用户，组和服务账户）的列表和对这些主体所获得的角色的引用。 +可以使用 `RoleBinding` 在指定的命名空间中执行授权， +或者在集群范围的命名空间使用 `ClusterRoleBinding` 来执行授权。 + +一个 `RoleBinding` 可以引用同一的命名空间中的 `Role` 。 +下面的例子 `RoleBinding` 将 "pod-reader" 角色授予在 "default" 命名空间中的用户 "jane"； +这样，用户 "jane" 就具有了读取 "default" 命名空间中 pods 的权限。 + +`roleRef` 里的内容决定了实际创建绑定的方法。`kind` 可以是 `Role` 或 `ClusterRole`， +`name` 将引用你要指定的 `Role` 或 `ClusterRole` 的名称。在下面的例子中，角色绑定使用 +`roleRef` 将用户 "jane" 绑定到前文创建的角色 `Role`，其名称是 `pod-reader`。 + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# 此角色绑定使得用户 "jane" 能够读取 "default" 命名空间中的 Pods +kind: RoleBinding +metadata: + name: read-pods + namespace: default +subjects: +- kind: User + name: jane # Name is case sensitive + apiGroup: rbac.authorization.k8s.io +roleRef: + kind: Role #this must be Role or ClusterRole + name: pod-reader # 这里的名称必须与你想要绑定的 Role 或 ClusterRole 名称一致 + apiGroup: rbac.authorization.k8s.io +``` + + +`RoleBinding` 也可以引用 `ClusterRole`，对 `ClusterRole` 所定义的、位于 `RoleBinding` 命名空间内的资源授权。 +这可以允许管理者在 +整个集群中定义一组通用的角色，然后在多个命名空间中重用它们。 + +例如下面的例子，`RoleBinding` 指定的是 `ClusterRole`， +"dave" （主体，区分大小写）将只可以读取在"development" +命名空间（ `RoleBinding` 的命名空间）中的"secrets"。 + + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# 这个角色绑定允许 "dave" 用户在 "development" 命名空间中有读取 secrets 的权限。 +kind: RoleBinding +metadata: + name: read-secrets + namespace: development # 这里只授予 "development" 命名空间的权限。 +subjects: +- kind: User + name: dave # 名称区分大小写 + apiGroup: rbac.authorization.k8s.io +roleRef: + kind: ClusterRole + name: secret-reader + apiGroup: rbac.authorization.k8s.io +``` + + + +最后，`ClusterRoleBinding` 可用来在集群级别或对所有命名空间执行授权。 +下面的例子允许 "manager" 组中的任何用户读取任意命名空间中 "secrets"。 + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# 这个集群角色绑定允许 "manager" 组中的任何用户读取任意命名空间中 "secrets"。 +kind: ClusterRoleBinding +metadata: + name: read-secrets-global +subjects: +- kind: Group + name: manager # 名称区分大小写 + apiGroup: rbac.authorization.k8s.io +roleRef: + kind: ClusterRole + name: secret-reader + apiGroup: rbac.authorization.k8s.io +``` + +你不能修改绑定对象所引用的 `Role` 或 `ClusterRole` 。 +试图改变绑定对象的 `roleRef` 将导致验证错误。想要 +改变现有绑定对象中 `roleRef` 字段的内容，必须删除并 +重新创建绑定对象。这种限制有两个主要原因： + +1.关于不同角色的绑定是完全不一样的。更改 `roleRef` + 需要删除/重建绑定，确保要赋予绑定的完整主体列表是新 +的角色（而不是只是启用修改 `roleRef` 在不验证所有现有 +主体的情况下的，应该授予新角色对应的权限）。 + +2.使得 `roleRef` 不可以改变现有绑定主体用户的 `update` 权限， +这样可以让它们能够管理主体列表，而不能更改授予这些主体相关 +的角色。 + +命令 `kubectl auth reconcile` 可以创建或者更新包含 RBAC 对象的清单文件， +并且在必要的情况下删除和重新创建绑定对象，以改变所引用的角色。 +更多相关信息请参照[命令用法和示例](#kubectl-auth-reconcile) + + +### 对资源的引用 + +大多数资源都是使用名称的字符串表示，例如在相关的 API 端点的 URL 之中出现的 "pods" 。 +然而有一些 Kubernetes API 涉及 "子资源（subresources）"，例如 pod 的日志。Pod 日志相关的端点 URL 如下： + +```http +GET /api/v1/namespaces/{namespace}/pods/{name}/log +``` + +在这种情况下，"pods" 是有命名空间的资源，而 "log" 是 pods 的子资源。在 RBAC 角色中， +使用"/"分隔资源和子资源。允许一个主体要同时读取 pods 和 pod logs，你可以这么写： + + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: pod-and-pod-logs-reader +rules: +- apiGroups: [""] + resources: ["pods", "pods/log"] + verbs: ["get", "list"] +``` + + +对于某些请求，也可以通过 `resourceNames` 列表按名称引用资源。 +在指定时，可以将请求类型限制资源的单个实例。限制只可以 "get" 和 "update" +的单一configmap，你可以这么写： + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: configmap-updater +rules: +- apiGroups: [""] + resources: ["configmaps"] + resourceNames: ["my-configmap"] + verbs: ["update", "get"] +``` + +需要注意的是，`create` 请求不能被 resourceName 限制，因为在鉴权时还不知道对象名称。 +另一个例外是 `deletecollection`。 + + +### Aggregated ClusterRoles + +从 1.9 开始，集群角色（ClusterRole）可以通过使用 `aggregationRule` 的方式并组合其他 ClusterRoles 来创建。 +聚合集群角色的权限是由控制器管理的，方法是通过过滤与标签选择器匹配的 ClusterRules，并将其中的权限进行组合。 +一个聚合集群角色的示例如下： + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: monitoring +aggregationRule: + clusterRoleSelectors: + - matchLabels: + rbac.example.com/aggregate-to-monitoring: "true" +rules: [] # 具体规则由控制器管理器自动填写。 +``` + +创建一个与标签选择器匹配的 ClusterRole 之后，其上定义的规则将成为聚合集群角色的一部分。在下面的例子中， +通过创建一个新的、标签同样为 `rbac.example.com/aggregate-to-monitoring: true` 的 +ClusterRole，新的规则可被添加到 "monitoring" 集群角色中。 + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: monitoring-endpoints + labels: + rbac.example.com/aggregate-to-monitoring: "true" +# 这些规则将被添加到 "monitoring" 角色中。 +rules: +- apiGroups: [""] + resources: ["services", "endpoints", "pods"] + verbs: ["get", "list", "watch"] +``` + + + +默认的面向用户的角色（如下所述）使用 ClusterRole 聚合。这使得管理者可以为自定义资源设置使用规则属性， +比如通过 CustomResourceDefinitions 或聚合 API 服务器为默认角色提供的服务。 + +例如，在以下 ClusterRoles 中让 "admin" 和 "edit" 拥有管理自定义资源 "CronTabs" 的权限， + "view" 角色对资源有只读操作权限。 + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: aggregate-cron-tabs-edit + labels: + # 将这些权限添加到默认角色 "admin" 和 "edit" 中。 + rbac.authorization.k8s.io/aggregate-to-admin: "true" + rbac.authorization.k8s.io/aggregate-to-edit: "true" +rules: +- apiGroups: ["stable.example.com"] + resources: ["crontabs"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +--- +kind: ClusterRole +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: aggregate-cron-tabs-view + labels: + # 将这些权限添加到默认角色 "view" 中。 + rbac.authorization.k8s.io/aggregate-to-view: "true" +rules: +- apiGroups: ["stable.example.com"] + resources: ["crontabs"] + verbs: ["get", "list", "watch"] +``` + + +#### 角色示例 + +在以下示例中，我们仅截取展示了 `rules` 对应部分， +允许读取在核心 {{< glossary_tooltip text="API 组" term_id="api-group" >}}下的 Pods: + +```yaml +rules: +- apiGroups: [""] + resources: ["pods"] + verbs: ["get", "list", "watch"] +``` + +允许读/写在 "extensions" 和 "apps" API 组中的 "deployments" 资源： + +```yaml +rules: +- apiGroups: ["extensions", "apps"] + resources: ["deployments"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +``` + +允许读取 "pods" 和读/写 "jobs" : + +```yaml +rules: +- apiGroups: [""] + resources: ["pods"] + verbs: ["get", "list", "watch"] +- apiGroups: ["batch", "extensions"] + resources: ["jobs"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +``` + + +允许读取名称为 "my-config"的 `ConfigMap` （需要通过 `RoleBinding` 绑定带某名字空间中特定的 `ConfigMap`）： + +```yaml +rules: +- apiGroups: [""] + resources: ["configmaps"] + resourceNames: ["my-config"] + verbs: ["get"] +``` + +允许读取在核心组中的 "nodes" 资源（因为 `Node` 是集群范围的，所以需要 `ClusterRole` 绑定到 `ClusterRoleBinding` 才生效） + +```yaml +rules: +- apiGroups: [""] + resources: ["nodes"] + verbs: ["get", "list", "watch"] +``` + +允许在非资源端点 "/healthz" 和其子路径上发起 "GET" 和 "POST" 请求（必须在 `ClusterRole` 绑定 `ClusterRoleBinding` 才生效） + +```yaml +rules: +- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' 在 nonResourceURL 中的意思是后缀全局匹配。 + verbs: ["get", "post"] +``` + + +### 对主体的引用 + +`RoleBinding` 或者 `ClusterRoleBinding` 需要绑定角色到 *主体*。 +主体可以是组，用户或者服务账户。 + +用户是由字符串表示，它们可以是普通的用户名，像 "alice"，或者是 +邮件格式 "bob@example.com"，或者是数字ID。由 Kubernetes 管理员配置[身份认证模块](/docs/reference/access-authn-authz/authentication/) +需要的格式。RBAC 鉴权系统不对格式作任何要求，但是前缀 `system:` 是 Kubernetes 系统保留的， +所以管理员要确保配置的用户名不能出现上述前缀格式。 + +用户组信息是 Kubernetes 现在提供的一种身份验证模块，与用户一样，对组的字符串没有格式要求， +只是不能使用保留的前缀 `system:` 。 + +[服务账号](/docs/tasks/configure-pod-container/configure-service-account/) 的用户名前缀为`system:serviceaccount:`， +属于前缀为 `system:serviceaccounts:` 的用户组。 + + +#### RoleBinding的示例 + +下面的示例只是展示 `RoleBinding` 中 `subjects` 的部分。 + +用户的名称为 "alice@example.com": + +```yaml +subjects: +- kind: User + name: "alice@example.com" + apiGroup: rbac.authorization.k8s.io +``` + +组的名称为 "frontend-admins": + +```yaml +subjects: +- kind: Group + name: "frontend-admins" + apiGroup: rbac.authorization.k8s.io +``` + +服务账号在 kube-system 命名空间中: + +```yaml +subjects: +- kind: ServiceAccount + name: default + namespace: kube-system +``` + +在名称为 "qa" 命名空间中所有的服务账号: + +```yaml +subjects: +- kind: Group + name: system:serviceaccounts:qa + apiGroup: rbac.authorization.k8s.io +``` + + + +所有的服务账号: + +```yaml +subjects: +- kind: Group + name: system:serviceaccounts + apiGroup: rbac.authorization.k8s.io +``` + +所有认证过的用户 （版本 1.5+）: + +```yaml +subjects: +- kind: Group + name: system:authenticated + apiGroup: rbac.authorization.k8s.io +``` + +所有未认证的用户 （版本 1.5+）: + +```yaml +subjects: +- kind: Group + name: system:unauthenticated + apiGroup: rbac.authorization.k8s.io +``` + +所有用户 （版本 1.5+）: + +```yaml +subjects: +- kind: Group + name: system:authenticated + apiGroup: rbac.authorization.k8s.io +- kind: Group + name: system:unauthenticated + apiGroup: rbac.authorization.k8s.io +``` + + +## 默认 Roles 和 Role Bindings + +API servers创建一组默认为 `ClusterRole` 和 `ClusterRoleBinding` 的对象。 +其中许多是以 `system:` 为前缀的，它表示资源是基础设施 "owned" 的。对于这些资源的修改可能导致集群功能失效。 +例如，`system:node` 是集群角色，它是定义 kubelets 相关的权限，如果这个角色被修改，它将导致 kubelets 无法正常工作。 + +所有默认的 ClusterRole 和 ClusterRoleBinding 对象都会被标记为 `kubernetes.io/bootstrapping=rbac-defaults`。 + + +### 自动更新 + +在每次启动时，API Server 都会更新默认 ClusterRole 所缺少的各种权限，并更新默认 ClusterRoleBinding 所缺少的各个角色绑定主体。 +这种自动更新机制允许集群去修复一些特殊的修改。 +由于权限和角色绑定主体在新的 Kubernetes 版本中可能发生变化，所以这样的话也能够保证角色和角色绑定始终保持是最新的。 + +如果要禁止此功能,请将默认ClusterRole以及ClusterRoleBinding的`rbac.authorization.kubernetes.io/autoupdate`设置成`false`。 + +注意，缺乏默认权限和角色绑定主体可能会导致非功能性集群问题。 + +自动更新功能在 Kubernetes 版本1.6+ 的 RBAC 认证是默认开启的。 + + +### Discovery Roles + +无论是经过身份验证的还是未经过身份验证的用户，默认角色的用户读取API被认为是安全的，可以公开访问（包括CustomResourceDefinitions）， +如果要禁用匿名未经过身份验证的用户访问，请在 API server 中添加 `--anonymous-auth=false` 的配置选项。 + +通过运行命令 `kubectl` 可以查看这些角色的配置信息: + +``` +kubectl get clusterroles system:discovery -o yaml +``` + +注意：不建议编辑这个角色，因为更改将在 API server 重启时自动更新时覆盖（见上文） + + + + + + + + + + + + + + + + + + + + + + + +
默认 ClusterRole默认 ClusterRoleBinding描述
system:basic-usersystem:authenticated 组允许用户以只读的方式去访问他们自己的基本信息。在1.14版本之前，这个角色在默认情况下也绑定在 `system:unauthenticated` 上。
system:discoverysystem:authenticated 组允许以只读方式访问 API 发现端点，这些端点用来发现和协商 API 级别。在1.14版本之前，这个角色在默认情况下绑定在 `system:unauthenticated` 上。
system:public-info-viewersystem:authenticated 和 system:unauthenticated 组允许对集群的非敏感信息进行只读访问，它是在1.14版本中引入的。
+ + +### 面向用户的角色 + +一些默认的角色不是前缀 `system:` 开头的。这些是面向用户的角色。它们包括 super-user 角色（`cluster-admin`）， +使用 ClusterRoleBindings （`cluster-status`）在集群范围内授予角色， +以及使用 RoleBindings （`admin`, `edit`, `view`）在特定命名空间中授予的角色。 + +在 1.9 开始，面向用户的角色使用[ClusterRole Aggregation](#aggregated-clusterroles)允许管理员在包含这些角色上的 +自定义资源上添加规则。如果想要添加 "admin" "edit" 或者 "view" ，需要先创建使用以下一个或多个的 ClusterRole 的标签： + +```yaml +metadata: + labels: + rbac.authorization.k8s.io/aggregate-to-admin: "true" + rbac.authorization.k8s.io/aggregate-to-edit: "true" + rbac.authorization.k8s.io/aggregate-to-view: "true" +``` + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
默认 ClusterRole默认 ClusterRoleBinding描述
cluster-adminsystem:masters 组允许超级用户在平台上的任何资源的所有操作。 +当在 ClusterRoleBinding 中使用时，可以授权对集群中以及所有命名空间中的全部资源进行完全控制。 +当在 RoleBinding 中使用时，可以授权控制 RoleBinding 所在命名空间中的所有资源，包括命名空间本身。
admin无允许管理员访问权限，旨在使用 RoleBinding 在命名空间内执行授权。 +如果在 RoleBinding 中使用，则可授予对命名空间中的大多数资源的读/写权限， +包括创建角色和绑定角色（RoleBinding）的能力。 +但是它不允许对资源配额或者命名空间本身进行写操作。
edit无允许对命名空间的大多数对象进行读/写操作。 +它不允许查看或者修改角色（Roles）或者角色绑定（RoleBindings）。
view无允许对命名空间的大多数对象有只读权限。 +它不允许查看角色（Roles）或角色绑定（RoleBindings）。 +它不允许查看 Secrets，因为这类操作属于越权。
+ + +### 核心组件角色 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
默认 ClusterRole默认 ClusterRoleBinding描述
system:kube-schedulersystem:kube-scheduler 用户允许访问 kube-scheduler 组件所需要的资源。
system:volume-schedulersystem:kube-scheduler 用户允许访问 kube-scheduler 组件所需要的的卷资源。
system:kube-controller-managersystem:kube-controller-manager 用户允许访问 kube-controller-manager 组件所需要的资源。 +各个控制环所需要的权限包含在 controller roles 之中。
system:node在版本1.8之后无允许访问 kubelet 组件所需要的资源，它包括读取所有的 Secrets 和对所有 Pod 状态对象的写操作。 + +从版本 1.7 开始，推荐使用 Node authorizer 和 NodeRestriction 准入插件 来代替这个角色，它允许基于 kubelet 上调度执行的 Pods 来授权对 kubelet API 的访问。 +在版本 1.7 之前，这个角色会自动绑定到 `system:nodes` 组。 +在版本 1.7中，如果未启用`Node` 鉴权模式，这个角色将自动绑定到 `system:nodes` 组 +在版本 1.8+ 之后，不再自动创建绑定。 +
system:node-proxiersystem:kube-proxy 用户允许访问 kube-proxy 组件所需要的资源。
+ + +### 其他组件角色 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
默认 ClusterRole默认 ClusterRoleBinding描述
system:auth-delegator无允许代理身份认证和鉴权， +它通常用在插件式 API 服务器上，以实现统一的身份认证和鉴权。
system:heapster无为 Heapster 组件定义的角色。
system:kube-aggregator无为 kube-aggregator 组件定义的角色。
system:kube-dns在kube-system命名空间中的kube-dns服务账号为 kube-dns 组件定义的角色。
system:kubelet-api-admin无允许完全访问 kubelet API 。
system:node-bootstrapper无允许访问执行 +Kubelet TLS 启动引导 所需要的资源。
system:node-problem-detector无为 node-problem-detector 组件定义的角色。
system:persistent-volume-provisioner无允许访问大部分的 动态卷驱动 所需要的资源。
+ + +### 控制器角色 {#controller-roles} + +[Kubernetes 控制器管理器](/docs/admin/kube-controller-manager/) 运行核心控制环。 +当使用 `--use-service-account-credentials` 参数时, 每个控制环使用一个单独的服务账号启动。 +每个控制环都有相应的、前缀为 `system:controller:` 的角色。 +如果控制管理器启动时未设置 `--use-service-account-credentials`， +它使用自己的身份信息来运行所有的控制环，该身份必须被授予所有相关的角色。 +这些角色包括: + +* system:controller:attachdetach-controller +* system:controller:certificate-controller +* system:controller:clusterrole-aggregation-controller +* system:controller:cronjob-controller +* system:controller:daemon-set-controller +* system:controller:deployment-controller +* system:controller:disruption-controller +* system:controller:endpoint-controller +* system:controller:expand-controller +* system:controller:generic-garbage-collector +* system:controller:horizontal-pod-autoscaler +* system:controller:job-controller +* system:controller:namespace-controller +* system:controller:node-controller +* system:controller:persistent-volume-binder +* system:controller:pod-garbage-collector +* system:controller:pv-protection-controller +* system:controller:pvc-protection-controller +* system:controller:replicaset-controller +* system:controller:replication-controller +* system:controller:resourcequota-controller +* system:controller:root-ca-cert-publisher +* system:controller:route-controller +* system:controller:service-account-controller +* system:controller:service-controller +* system:controller:statefulset-controller +* system:controller:ttl-controller + + +## 初始化与预防权限升级 + +RBAC API 会阻止用户通过编辑角色或者角色绑定来升级权限。 +由于这一点是在 API 级别实现的，所以在 RBAC 鉴权器（RBAC authorizer）未启用的状态下依然可以正常工作。 + +用户只有在符合下列条件之一的情况下，才能创建/更新角色: + + +1. 他们已经拥有角色中包含的所有权限，且其作用域与正被修改的对象相同。 +（对 `ClusterRole` 而言意味着集群范围，对 `Role` 而言意味着相同命名空间或者集群范围） +2. 他们被明确允许在 `rbac.authorization.k8s.io` API 组中的 `roles` 或者 `clusterroles` 资源上使用 `escalate` 动词（Kubernetes 版本 1.12 及以上） + +例如，如果 "user-1" 没有列举集群范围所有 Secrets 的权限，他将不能创建包含对应权限的 `ClusterRole`。 +若要允许用户创建/更新角色： + +根据需要授予他们一个角色，允许他们根据需要创建/更新 `Role` 或者 `ClusterRole` 对象。 +2. 授予他们在所创建/更新角色中包含特殊权限的权限: + * 隐式的，通过给他们权限（如果它们试图创建或者更改 `Role` 或 `ClusterRole` 的权限，但自身没有被授权，API 请求将被禁止） + * 或通过允许他们在 `Role` 或 `ClusterRole` 资源上执行 `escalate` 动作的权限，它包含在 `rbac.authorization.k8s.io` API 组中 （Kubernetes 1.12 及以上版本） + +如果用户已经拥有引用角色中包含的权限，那他则只能创建/更新角色绑定。 +（在角色绑定相同的作用域内）*或* 如果他们被授予对所引用角色执行 `bind` 操作的显式权限。 +例如，如果 "user-1" 没有集群范围内 Secret 的列表权限，他就不能创建可以授予角色权限的 `ClusterRoleBinding`。 +通过以下方法可以允许用户创建/更新角色绑定： + +授予他们一个角色，允许他们根据需要创建/更新 `RoleBinding` 或者`ClusterRoleBinding` 对象。 +2. 授予他们绑定特定角色所需的权限: + * 隐式地，通过给他们授予角色中包含的权限。 + * 显式地，通过允许他们对特定角色（或集群角色）执行`bind` 操作的权限。 + + +例如，这个集群角色和角色绑定将允许 "user-1" 有对"user-1-namespace" 命名空间中的角色执行 `admin`、`edit` 和 `view` 操作权限： + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: role-grantor +rules: +- apiGroups: ["rbac.authorization.k8s.io"] + resources: ["rolebindings"] + verbs: ["create"] +- apiGroups: ["rbac.authorization.k8s.io"] + resources: ["clusterroles"] + verbs: ["bind"] + resourceNames: ["admin","edit","view"] +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: role-grantor-binding + namespace: user-1-namespace +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: role-grantor +subjects: +- apiGroup: rbac.authorization.k8s.io + kind: User + name: user-1 +``` + +当初始化第一个角色和角色绑定时，需要为初始用户授予他们尚未拥有的权限。 对初始角色和角色绑定进行初始化时需要： + +* 使用用户组为 `system:masters` 的凭据，该用户组由默认绑定关联到 `cluster-admin` 这个超级用户角色。 +* 如果你的 API server 启动时启用了不安全端口（使用`--insecure-port`）, 你也可以通过该端口调用 API ，这样操作会绕过身份验证或鉴权。 + + +## 一些命令行工具 + +### `kubectl create role` + +创建 `Role` 对象，定义在某命名空间中的权限。例如: + +* 创建名称为 "pod-reader" 的 `Role` 对象，允许用户对 pods 执行 "get"、"watch" 和 "list" 操作： + + ``` + kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods + ``` + +* 创建名称为 "pod-reader" 的 `Role` 对象并指定 resourceNames： + + ``` + kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod + ``` + +* 创建名为 "foo" 的 `Role` 对象并指定 apiGroups: + + ``` + kubectl create role foo --verb=get,list,watch --resource=replicasets.apps + ``` + +* 创建名为 "foo" 的 `Role` 对象并指定子资源权限: + + ``` + kubectl create role foo --verb=get,list,watch --resource=pods,pods/status + ``` + +* 创建名为 "my-component-lease-holder" 的 `Role` 对象，使其具有对特定名称资源执行 get/update 的权限： + + ``` + kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component + ``` + + +### `kubectl create clusterrole` + +创建 `ClusterRole` 对象。例如： + +* 创建名称为 "pod-reader" 的 `ClusterRole` 对象，允许用户对 pods 对象执行 "get"、"watch" 和 "list" 操作： + + ``` + kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods + ``` + +* 创建名为 "pod-reader" 的 `ClusterRole` 对象并指定资源名称： + + ``` + kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod + ``` + +* 创建名为 "foo" 的 `ClusterRole` 对象并指定 apiGroups： + + ``` + kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps + ``` + +* 创建名为 "foo" 的`ClusterRole` 对象并指定子资源: + + ``` + kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status + ``` + +* 创建名为 "foo" 的 `ClusterRole` 对象并指定非资源路径： + + ``` + kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* + ``` + +* 创建名为 "monitoring" 的 `ClusterRole` 对象并指定聚合规则： + + ``` + kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" + ``` + + +### `kubectl create rolebinding` + +在特定的命名空间中对 `Role` 或 `ClusterRole` 授权。例如： + +* 在命名空间 "acme" 中，将名为 `admin` 的 `ClusterRole` 中的权限授予名称 "bob" 的用户: + + ``` + kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme + ``` + +* 在命名空间 "acme"中，将名为 `view` 的 `ClusterRole` 中的权限授予该命名空间 "acme" 中名为 "myapp" 的服务账号： + + ``` + kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme + ``` + +* 在命名空间 "acme" 中，将名为 `view` 的 `ClusterRole` 对象中的权限授予命名空间 "myappnamespace" 中名称为 "myapp" 的服务账号： + + ``` + kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme + ``` + + +### `kubectl create clusterrolebinding` + +在整个集群、包括所有的命名空间中对 `ClusterRole` 授权。例如： + +* 在整个集群范围，将名为 `cluster-admin` 的 `ClusterRole` 中定义的权限授予名为 "root" 用户： + + ``` + kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root + ``` + +* 在整个集群范围，将名为 `system:node-proxier` 的 `ClusterRole` 的权限授予名为 "system:kube-proxy" 的用户： + + ``` + kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy + ``` + +* 在整个集群范围，将名为 `view` 的 `ClusterRole` 对象中定义的权限授予 "acme" 命名空间中名为 "myapp" 的服务账号： + + ``` + kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp + ``` + + +### `kubectl auth reconcile` {#kubectl-auth-reconcile} + +使用清单文件来创建或者更新 `rbac.authorization.k8s.io/v1` API 对象。 + +尚不存在的对象会被创建，如果对应的命名空间也不存在，必要的话也会被创建。 +已经存在的角色会被更新，使之包含输入对象中所给的权限。如果指定了 `--remove-extra-permissions`，可以删除其余权限。 + +已经存在的绑定也会被更新，使之包含输入对象中所给的主体。如果指定了 `--remove-extra-permissions`，则可以删除其余主体。 + +例如: + +* 测试应用 RBAC 对象的清单文件，显示将要进行的更改： + + ``` + kubectl auth reconcile -f my-rbac-rules.yaml --dry-run + ``` + +* 应用 RBAC 对象的清单文件， 保留角色中的其余权限和绑定中的其他主体： + + ``` + kubectl auth reconcile -f my-rbac-rules.yaml + ``` + +* 应用 RBAC 对象的清单文件, 删除角色中的其他权限和绑定中的其他主体： + + ``` + kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions + ``` + +查看 CLI 帮助获取详细的用法。 + + +## 服务账号权限 + +默认的 RBAC 策略为控制面组件、节点和控制器授予权限。 +但是不会对 `kube-system` 命名空间之外的服务账号授予权限。 +（除了授予所有已认证用户的 discovery 权限） + +这使得您可以根据需要向特定服务账号授予特定权限。 细粒度的角色绑定可带来更好的安全性，但需要更多精力管理。 +更粗粒度的授权可能导致服务账号被授予不必要的 API 访问权限（甚至导致潜在的权限升级），但更易于管理。 + +按从最安全到最不安全的顺序，存在以下方法： + +1. 为特定应用的服务账户授予角色（最佳实践） + + 这要求应用在其 pod 规范中指定 `serviceAccountName` ， + 并额外创建服务账号（包括通过 API、应用程序清单、`kubectl create serviceaccount` 等）。 + + 例如，在命名空间 "my-namespace" 中授予服务账号 "my-sa" 只读权限： + + ```shell + kubectl create rolebinding my-sa-view \ + --clusterrole=view \ + --serviceaccount=my-namespace:my-sa \ + --namespace=my-namespace + ``` + +2. 将角色授予某命名空间中的 ”default” 服务账号 + + 如果一个应用没有指定 `serviceAccountName`，那么它将使用 "default" 服务账号。 + + {{< note >}}不指定 `serviceAccountName` 的话， + "default" 服务账号的权限会授予给命名空间中所有未指定 `serviceAccountName` 的 Pods。{{< /note >}} + + + 例如，在命名空间 "my-namespace" 中授予服务账号 "default" 只读权限： + + ```shell + kubectl create rolebinding default-view \ + --clusterrole=view \ + --serviceaccount=my-namespace:default \ + --namespace=my-namespace + ``` + + 许多附加组件 [add-ons](/docs/concepts/cluster-administration/addons/) 目前在 `kube-system` 命名空间以 "default" 服务账号运行。 + 要允许这些附加组件以超级用户权限运行，需要将集群的 cluster-admin 权限授予 `kube-system` 命名空间中的 "default" 服务账号。 + + {{< note >}}启用这一配置意味着在 `kube-system` 命名空间中包含以超级用户账号来访问 API 的 Secrets。{{< /note >}} + + ```shell + kubectl create clusterrolebinding add-on-cluster-admin \ + --clusterrole=cluster-admin \ + --serviceaccount=kube-system:default + ``` + + + +3. 将角色授予命名空间中所有的服务账号 + + 如果你想要在命名空间中所有的应用都具有某角色，无论它们使用的什么服务账号， + 你可以将角色授予该命名空间的服务账号组。 + + 例如，在命名空间 "my-namespace" 中的只读权限授予该命名空间中的所有服务账号： + + ```shell + kubectl create rolebinding serviceaccounts-view \ + --clusterrole=view \ + --group=system:serviceaccounts:my-namespace \ + --namespace=my-namespace + ``` + +4. 对集群范围内的所有服务账户授予一个受限角色（不鼓励） + + 如果你不想管理每一个命名空间的权限，你可以向所有的服务账号授予集群范围的角色。 + + 例如，为集群范围的所有服务账号授予跨所有命名空间的只读权限： + + ```shell + kubectl create clusterrolebinding serviceaccounts-view \ + --clusterrole=view \ + --group=system:serviceaccounts + ``` + +5. 授予超级用户访问权限给集群范围内的所有服务帐户（强烈不鼓励） + + 如果你不关心如何区分权限，你可以将超级用户访问权限授予所有服务账号。 + + {{< warning >}} + 这将允许所有能够读取 Secrets 和创建 Pods 的用户访问超级用户的私密信息。 + {{< /warning >}} + + ```shell + kubectl create clusterrolebinding serviceaccounts-cluster-admin \ + --clusterrole=cluster-admin \ + --group=system:serviceaccounts + ``` + + +# 从版本1.5升级 + +在Kubernetes 1.6版本之前，许多部署可以使用非常宽松的 ABAC 策略， +包括授予所有服务帐户全权访问 API 的能力。 + +默认的 RBAC 策略被授予控制面组件、节点和控制器。 +`kube-system` 命名空间外的服务账号将没有权限 +（除了授予所有认证用户的发现权限之外） + +这样做虽然安全得多，但可能会干扰期望自动获得 API 权限的现有工作负载。 +这里有两种方法来完成这种转变: + + +### 平行鉴权 + +同时运行 RBAC 和 ABAC 鉴权模式, 并指定包含 +[现有的 ABAC 策略](/docs/reference/access-authn-authz/abac/#policy-file-format) 的策略文件： + +``` +--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.json +``` + +RBAC 鉴权器将首先尝试对请求进行鉴权。如果它拒绝 API 请求， +则 ABAC 鉴权器运行。这意味着被 RBAC 或 ABAC 策略所允许的任何请求 +都是被允许的请求。 + +如果 API 服务器启动时，RBAC 组件的日志级别为 5 或更高（`--vmodule=rbac*=5` or `--v=5`）， +你可以在 API 服务器的日志中看到 RBAC 的细节 （前缀 `RBAC DENY:`） +您可以使用这些信息来确定需要将哪些角色授予哪些用户、组或服务帐户。 +一旦你将 [角色授予服务账号](#服务账号权限) ，工作负载运行时在服务器日志中 +没有出现 RBAC 拒绝消息，就可以删除 ABAC 鉴权器。 + + + +## 宽松的 RBAC 权限 + +可以使用 RBAC 角色绑定在多个场合使用宽松的策略。 + +{{< warning >}} +下面的策略允许 **所有** 服务帐户充当集群管理员。 +容器中运行的所有应用程序都会自动收到服务帐户的凭据， +可以对 API 执行任何操作，包括查看 Secrets 和修改权限。 +这个策略是不被推荐的。 + +``` +kubectl create clusterrolebinding permissive-binding \ + --clusterrole=cluster-admin \ + --user=admin \ + --user=kubelet \ + --group=system:serviceaccounts +``` +{{< /warning >}} + +{{% /capture %}} From dd1d544f99534b491acafdaca704b9d88f84dd0a Mon Sep 17 00:00:00 2001 From: GoodGameZoo Date: Fri, 6 Mar 2020 15:11:24 +0800 Subject: [PATCH 027/194] Csi volume cloning modification (#19252) --- .../concepts/storage/volume-pvc-datasource.md | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/content/zh/docs/concepts/storage/volume-pvc-datasource.md b/content/zh/docs/concepts/storage/volume-pvc-datasource.md index c740f56a5f..a8e1a51175 100644 --- a/content/zh/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/zh/docs/concepts/storage/volume-pvc-datasource.md @@ -24,18 +24,7 @@ weight: 30 This document describes the concept of cloning existing CSI Volumes in Kubernetes. Familiarity with [Volumes](/docs/concepts/storage/volumes) is suggested. --> -本文档描述 Kubernetes 中克隆现有 CSI 卷的概念。建议先熟悉[卷](/docs/concepts/storage/volumes)。 - - - -此功能需要启动 VolumePVCDataSource 功能门： - -``` ---feature-gates=VolumePVCDataSource=true -``` - +本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉[卷](/docs/concepts/storage/volumes)。 {{% /capture %}} @@ -52,13 +41,13 @@ This feature requires VolumePVCDataSource feature gate to be enabled: The {{< glossary_tooltip text="CSI" term_id="csi" >}} Volume Cloning feature adds support for specifying existing {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s in the `dataSource` field to indicate a user would like to clone a {{< glossary_tooltip term_id="volume" >}}. --> -{{< glossary_tooltip text="CSI" term_id="csi" >}} 卷克隆功能增加了在 `dataSource` 字段指定现有的 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s，来表示用户想要克隆的 {{< glossary_tooltip term_id="volume" >}}。 +{{< glossary_tooltip text="CSI" term_id="csi" >}} 卷克隆功能增加了通过在 `dataSource` 字段中指定存在的 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s，来表示用户想要克隆的 {{< glossary_tooltip term_id="volume" >}}。 -克隆定义为已有 Kubernetes 卷的副本，可以像任何标准卷一样被使用。唯一的区别就是配置后，后端设备将创建指定卷的精确副本，而不是创建一个“新的”空卷。 +克隆，意思是为已有的 Kubernetes 卷创建副本，它可以像任何其它标准卷一样被使用。唯一的区别就是配置后，后端设备将创建指定完全相同的副本，而不是创建一个“新的”空卷。 + +{{% capture overview %}} + + +此页面显示如何将内存 *请求* （request）和内存 *限制* （limit）分配给一个容器。我们保障容器拥有它请求数量的内存，但不允许使用超过限制数量的内存。 + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + +您集群中的每个节点必须拥有至少 300 MiB 的内存。 + + +该页面上的一些步骤要求您在集群中运行 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 服务。如果您已经有在运行中的 metrics-server，则可以跳过这些步骤。 + + +如果您运行的是 Minikube，可以运行下面的命令启用 metrics-server： + +```shell +minikube addons enable metrics-server +``` + + +要查看 metrics-server 或资源指标 API (`metrics.k8s.io`) 是否已经运行，请运行以下命令： + +```shell +kubectl get apiservices +``` + + +如果资源指标 API 可用，则输出结果将包含对 `metrics.k8s.io` 的引用信息。 + +```shell +NAME +v1beta1.metrics.k8s.io +``` + +{{% /capture %}} + +{{% capture steps %}} + + +## 创建命名空间 + +创建一个命名空间，以便将本练习中创建的资源与集群的其余部分隔离。 + +```shell +kubectl create namespace mem-example +``` + + +## 指定内存请求和限制 + +要为容器指定内存请求，请在容器资源清单中包含 `resources：requests` 字段。 +同理，要指定内存限制，请包含 `resources：limits`。 + +在本练习中，您将创建一个拥有一个容器的 Pod。 +容器将会请求 100 MiB 内存，并且内存会被限制在 200 MiB 以内。 +这是 Pod 的配置文件： + +{{< codenew file="pods/resource/memory-request-limit.yaml" >}} + + +配置文件的 `args` 部分提供了容器启动时的参数。 +`"--vm-bytes", "150M"` 参数告知容器尝试分配 150 MiB 内存。 + +开始创建 Pod： + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example +``` + + +验证 Pod 中的容器是否已运行： + +```shell +kubectl get pod memory-demo --namespace=mem-example +``` + + +查看 Pod 相关的详细信息： + +```shell +kubectl get pod memory-demo --output=yaml --namespace=mem-example +``` + + +输出结果显示：该 Pod 中容器的内存请求为 100 MiB，内存限制为 200 MiB。 + +```yaml +... +resources: + limits: + memory: 200Mi + requests: + memory: 100Mi +... +``` + + +运行 `kubectl top` 命令，获取该 Pod 的指标数据： + +```shell +kubectl top pod memory-demo --namespace=mem-example +``` + + +输出结果显示：Pod 正在使用的内存大约为 162,900,000 字节，约为 150 MiB。 +这大于 Pod 请求的 100 MiB，但在 Pod 限制的 200 MiB之内。 + +``` +NAME CPU(cores) MEMORY(bytes) +memory-demo 162856960 +``` + + +删除 Pod： + +```shell +kubectl delete pod memory-demo --namespace=mem-example +``` + + +## 超过容器限制的内存 + +当节点拥有足够的可用内存时，容器可以使用其请求的内存。但是，容器不允许使用超过其限制的内存。 +如果容器分配的内存超过其限制，该容器会成为被终止的候选容器。如果容器继续消耗超出其限制的内存，则终止容器。 +如果终止的容器可以被重启，则 kubelet 会重新启动它，就像其他任何类型的运行时失败一样。 + + +在本练习中，您将创建一个 Pod，尝试分配超出其限制的内存。 +这是一个 Pod 的配置文件，其拥有一个容器，该容器的内存请求为 50 MiB，内存限制为 100 MiB： + +{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}} + + +在配置文件的 `args` 部分中，您可以看到容器会尝试分配 250 MiB 内存，这远高于 100 MiB 的限制。 + +创建 Pod： + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example +``` + + +查看 Pod 相关的详细信息： + +```shell +kubectl get pod memory-demo-2 --namespace=mem-example +``` + +此时，容器可能正在运行或被杀死。重复前面的命令，直到容器被杀掉： + +```shell +NAME READY STATUS RESTARTS AGE +memory-demo-2 0/1 OOMKilled 1 24s +``` + + +获取容器更详细的状态信息： + +```shell +kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example +``` + + +输出结果显示：由于内存溢出（OOM），容器已被杀掉： + +```shell +lastState: + terminated: + containerID: docker://65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f + exitCode: 137 + finishedAt: 2017-06-20T20:52:19Z + reason: OOMKilled + startedAt: null +``` + + +本练习中的容器可以被重启，所以 kubelet 会重启它。多次运行下面的命令，可以看到容器在反复的被杀死和重启： + +```shell +kubectl get pod memory-demo-2 --namespace=mem-example +``` + + +输出结果显示：容器被杀掉、重启、再杀掉、再重启……： + +``` +kubectl get pod memory-demo-2 --namespace=mem-example +NAME READY STATUS RESTARTS AGE +memory-demo-2 0/1 OOMKilled 1 37s +``` +``` + +kubectl get pod memory-demo-2 --namespace=mem-example +NAME READY STATUS RESTARTS AGE +memory-demo-2 1/1 Running 2 40s +``` + + +查看关于该 Pod 历史的详细信息： + +``` +kubectl describe pod memory-demo-2 --namespace=mem-example +``` + + +输出结果显示：该容器反复的在启动和失败： + +``` +... Normal Created Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511 +... Warning BackOff Back-off restarting failed container +``` + + +查看关于集群节点的详细信息： + +``` +kubectl describe nodes +``` + + +输出结果包含了一条练习中的容器由于内存溢出而被杀掉的记录： + +``` +Warning OOMKilling Memory cgroup out of memory: Kill process 4481 (stress) score 1994 or sacrifice child +``` + + +删除 Pod: + +```shell +kubectl delete pod memory-demo-2 --namespace=mem-example +``` + + +## 超过整个节点容量的内存 + +内存请求和限制是与容器关联的，但将 Pod 视为具有内存请求和限制，也是很有用的。 +Pod 的内存请求是 Pod 中所有容器的内存请求之和。 +同理，Pod 的内存限制是 Pod 中所有容器的内存限制之和。 + + +Pod 的调度基于请求。只有当节点拥有足够满足 Pod 内存请求的内存时，才会将 Pod 调度至节点上运行。 + +在本练习中，你将创建一个 Pod，其内存请求超过了您集群中的任意一个节点所拥有的内存。 +这是该 Pod 的配置文件，其拥有一个请求 1000 GiB 内存的容器，这应该超过了您集群中任何节点的容量。 + +{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}} + + +创建 Pod： + +```shell +kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example +``` + + +查看 Pod 状态： + +```shell +kubectl get pod memory-demo-3 --namespace=mem-example +``` + + +输出结果显示：Pod 处于 PENDING 状态。这意味着，该 Pod 没有被调度至任何节点上运行，并且它会无限期的保持该状态： + +``` +kubectl get pod memory-demo-3 --namespace=mem-example +NAME READY STATUS RESTARTS AGE +memory-demo-3 0/1 Pending 0 25s +``` + + +查看关于 Pod 的详细信息，包括事件： + + +```shell +kubectl describe pod memory-demo-3 --namespace=mem-example +``` + + +输出结果显示：由于节点内存不足，该容器无法被调度： + +```shell +Events: + ... Reason Message + ------ ------- + ... FailedScheduling No nodes are available that match all of the following predicates:: Insufficient memory (3). +``` + + +## 内存单位 + +内存资源的基本单位是字节（byte）。您可以使用这些后缀之一，将内存表示为纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。例如，下面是一些近似相同的值： + +```shell +128974848, 129e6, 129M , 123Mi +``` + + +删除 Pod： + +```shell +kubectl delete pod memory-demo-3 --namespace=mem-example +``` + + +## 如果你没有指定内存限制 + +如果你没有为一个容器指定内存限制，则自动遵循以下情况之一： + + +* 容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存，进而可能导致该节点调用 OOM Killer。 +此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。 + +* 运行的容器所在命名空间有默认的内存限制，那么该容器会被自动分配默认限制。 +集群管理员可用使用 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) +来指定默认的内存限制。 + + +## 内存请求和限制的目的 + +通过为集群中运行的容器配置内存请求和限制，您可以有效利用集群节点上可用的内存资源。通过将 Pod 的内存请求保持在较低水平，您可以更好地安排 Pod 调度。通过让内存限制大于内存请求，您可以完成两件事： + + +* Pod 可以进行一些突发活动，从而更好的利用可用内存。 +* Pod 在突发活动期间，可使用的内存被限制为合理的数量。 + + +## 清理 + +删除命名空间。下面的命令会删除你根据这个任务创建的所有 Pod： + +```shell +kubectl delete namespace mem-example +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + +### 应用开发者扩展阅读 + +* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/) + +* [配置 Pod 的服务质量](/docs/tasks/configure-pod-container/quality-service-pod/) + +### 集群管理员扩展阅读 + +* [为命名空间配置默认的内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/) + +* [为命名空间配置默认的 CPU 请求和限制](/docs/tasks/administer-cluster/cpu-default-namespace/) + +* [配置命名空间的最小和最大内存约束](/docs/tasks/administer-cluster/memory-constraint-namespace/) + +* [配置命名空间的最小和最大 CPU 约束](/docs/tasks/administer-cluster/cpu-constraint-namespace/) + +* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) + +* [配置命名空间下 Pod 总数](/docs/tasks/administer-cluster/quota-pod-namespace/) + +* [配置 API 对象配额](/docs/tasks/administer-cluster/quota-api-object/) + +{{% /capture %}} + + + From e9342c00a208a63521cd87c7a66ebb952991ba60 Mon Sep 17 00:00:00 2001 From: GoodGameZoo Date: Sat, 7 Mar 2020 00:15:23 +0800 Subject: [PATCH 032/194] Translation modification (#19250) --- content/zh/docs/concepts/storage/storage-classes.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/zh/docs/concepts/storage/storage-classes.md b/content/zh/docs/concepts/storage/storage-classes.md index 3c7dc98bc8..b1d8becc60 100644 --- a/content/zh/docs/concepts/storage/storage-classes.md +++ b/content/zh/docs/concepts/storage/storage-classes.md @@ -36,7 +36,7 @@ systems. ## 介绍 `StorageClass` 为管理员提供了描述存储 `"类"` 的方法。 -不同的`类型`可能会映射到不同的服务质量等级或备份策略，或是由群集管理员制定的任意策略。 +不同的`类型`可能会映射到不同的服务质量等级或备份策略，或是由集群管理员制定的任意策略。 Kubernetes 本身并不清楚各种`类`代表的什么。这个`类`的概念在其他存储系统中有时被称为"配置文件"。 -管理员可以为没有申请绑定到特定 `StorageClass` 的 PVC 指定一个默认的`类` ： -更多详情请参阅 [`PersistentVolumeClaim` 章节](#persistentvolumeclaims)。 +管理员可以为没有申请绑定到特定 `StorageClass` 的 PVC 指定一个默认的存储`类` ： +更多详情请参阅 [`PersistentVolumeClaim` 章节](/docs/concepts/storage/persistent-volumes/#class-1)。 ```yaml apiVersion: storage.k8s.io/v1 @@ -92,13 +92,13 @@ for provisioning PVs. This field must be specified. --> ### 存储分配器 -`StorageClass` 有一个分配器，用来决定使用哪个`卷插件`分配`持久化卷申领`。该字段必须指定。 +`StorageClass` 有一个分配器，用来决定使用哪个`卷插件`分配`PV`。该字段必须指定。 -| 卷插件 | 提供厂商 | 配置例子 | +| 卷插件 | 内置分配器 | 配置例子 | | :--- | :---: | :---: | | AWSElasticBlockStore | ✓ | [AWS EBS](#aws-ebs) | | AzureFile | ✓ | [Azure File](#azure-file) | From 03f13f0fb034b0bfcd90dafd742a1ef98f9dfb72 Mon Sep 17 00:00:00 2001 From: Jie Shen Date: Sat, 7 Mar 2020 00:25:24 +0800 Subject: [PATCH 033/194] Polish configure-pod-configmap.md format (#19508) --- .../configure-pod-configmap.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md index 1d4dce70ce..fcaaf4f940 100644 --- a/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -74,9 +74,16 @@ For example: --> 例如： -# Create the local directory + + ```shell # 创建本地目录 mkdir -p configure-pod-container/configmap/ @@ -242,7 +249,7 @@ allowed="true" --> # env 文件中的每一行必须为 VAR = VAL 格式。 # 以＃开头的行(即注释)将被忽略。 # 空行将被忽略。 -# 引号没有特殊处理(即它们将成为 ConfigMap 值的一部分)。 +# 引号没有特殊处理(即它们将成为 ConfigMap 值的一部分)。 # 将样本文件下载到 `configure-pod-container/configmap/` 目录 wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties @@ -527,6 +534,7 @@ configmap/game-config-5-m67dt67794 created 要从文字 `special.type=charm` 和 `special.how=very` 生成 ConfigMap，可以在 `kusotmization.yaml` 中将 ConfigMap 生成器指定。 + + ```shell # 使用 ConfigMapGenerator 创建 kustomization.yaml 文件 cat <./kustomization.yaml From ee049c4431b841001172539dff26ec590eefbeee Mon Sep 17 00:00:00 2001 From: "Yuk, Yongsu" Date: Sat, 7 Mar 2020 14:05:34 +0900 Subject: [PATCH 034/194] Update to Outdated files in dev-1.17-ko.6 branch. (#19368) * Update to Outdated files in dev-1.17-ko.6 branch. * Apply suggestions from code review Co-Authored-By: Seokho Son Co-authored-by: Seokho Son --- .../ko/docs/concepts/architecture/nodes.md | 4 +- .../docs/concepts/configuration/overview.md | 4 +- content/ko/docs/concepts/containers/images.md | 15 ++-- .../overview/working-with-objects/names.md | 33 +++++++- .../concepts/services-networking/ingress.md | 2 +- .../workloads/controllers/cron-jobs.md | 11 ++- .../workloads/controllers/replicaset.md | 82 +++++++++---------- .../workloads/controllers/ttlafterfinished.md | 4 +- content/ko/docs/contribute/participating.md | 11 +-- content/ko/docs/tasks/_index.md | 4 - .../configure-access-multiple-clusters.md | 4 +- .../tutorials/online-training/overview.md | 2 - 12 files changed, 103 insertions(+), 73 deletions(-) diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index f9c28cee9c..a94a81a0cb 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -184,7 +184,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 #### 안정성 쿠버네티스 1.4에서, 대량의 노드들이 마스터 접근에 -문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제가 발생했기 때문에) +문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제들이 발생했기 때문에) 더 개선된 문제 해결을 하도록 노드 컨트롤러의 로직을 업데이트 했다. 1.4를 시작으로, 노드 컨트롤러는 파드 축출에 대한 결정을 내릴 경우 클러스터 내 모든 노드를 살핀다. @@ -210,7 +210,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. 그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 -정상 비율 `--node-eviction-rate`로 축출한다. 코너 케이스란 모든 영역이 +`--node-eviction-rate` 의 정상 비율로 축출한다. 코너 케이스란 모든 영역이 완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다. 이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이 복원될 때까지 모든 축출을 중지하는 것으로 여긴다. diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index 794f46d079..1bcb7362d6 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -28,7 +28,7 @@ weight: 10 - 더 나은 인트로스펙션(introspection)을 위해서, 어노테이션에 오브젝트의 설명을 넣는다. -## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡 +## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡 {#naked-pods-vs-replicasets-deployments-and-jobs} - 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다. @@ -85,7 +85,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 - `imagePullPolicy: Never`: 이미지가 로컬에 존재한다고 가정한다. 이미지를 풀(Pull) 하기 위해 시도하지 않는다. {{< note >}} -컨테이너가 항상 같은 버전의 이미지를 사용하도록 만들기 위해, `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`와 같은 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)를 명시할 수 있다. 다이제스트는 특정 버전의 이미지를 고유하게 식별하며, 다이제스트 값을 변경하지 않는 한 쿠버네티스에 의해 절대로 변경되지 않는다. +컨테이너가 항상 같은 버전의 이미지를 사용하도록 하기 위해, `<이미지 이름>:<태그>` 를 `<이미지 이름>@<다이제스트>` (예시 `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`)로 변경해서 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)를 명시할 수 있다. 다이제스트는 특정 버전의 이미지를 고유하게 식별하며, 다이제스트 값을 변경하지 않는 한 쿠버네티스에 의해 절대로 변경되지 않는다. {{< /note >}} {{< note >}} diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 3bc71c53c8..615e84dc40 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -64,6 +64,7 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전 - IAM 역할과 정책을 사용하여 OCIR 저장소에 접근을 제어함 - Azure 컨테이너 레지스트리(ACR) 사용 - IBM 클라우드 컨테이너 레지스트리 사용 + - IAM 역할 및 정책을 사용하여 IBM 클라우드 컨테이너 레지스트리에 대한 접근 권한 부여 - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 - 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음 - 클러스터 관리자에 의한 노드 구성 필요 @@ -85,8 +86,9 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전 클러스터 내에서 모든 파드는 해당 레지스트리에 있는 이미지에 읽기 접근 권한을 가질 것이다. -Kubelet은 해당 인스턴스의 Google 서비스 계정을 이용하여 GCR을 인증할 것이다. -인스턴스의 서비스 계정은 `https://www.googleapis.com/auth/devstorage.read_only`라서, +Kubelet은 해당 인스턴스의 Google 서비스 계정을 이용하여 +GCR을 인증할 것이다. 인스턴스의 서비스 계정은 +`https://www.googleapis.com/auth/devstorage.read_only`라서, 프로젝트의 GCR로부터 풀은 할 수 있지만 푸시는 할 수 없다. ### Amazon Elastic Container Registry 사용 @@ -144,12 +146,11 @@ kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다 [쿠버네티스 시크릿을 구성하고 그것을 파드 디플로이를 위해서 사용](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시)할 수 있다. ### IBM 클라우드 컨테이너 레지스트리 사용 -IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗 이미지 레지스트리를 제공하여 사용자가 Docker 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로, -프라이빗 레지스트리의 이미지는 통합된 취약점 조언기(Vulnerability Advisor)를 통해 조사되어 보안 이슈와 잠재적 취약성을 검출한다. IBM 클라우드 계정의 모든 사용자가 이미지에 접근할 수 있도록 하거나, 레지스트리 네임스페이스에 접근을 승인하는 토큰을 생성할 수 있다. +IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗 이미지 레지스트리를 제공하여 사용자가 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로, 프라이빗 레지스트리의 이미지는 통합된 취약점 조언기(Vulnerability Advisor)를 통해 조사되어 보안 이슈와 잠재적 취약성을 검출한다. IBM 클라우드 계정의 모든 사용자가 이미지에 접근할 수 있도록 하거나, IAM 역할과 정책으로 IBM 클라우드 컨테이너 레지스트리 네임스페이스의 접근 권한을 부여해서 사용할 수 있다. -IBM 클라우드 컨테이너 레지스트리 CLI 플러그인을 설치하고 사용자 이미지를 위한 네임스페이스를 생성하기 위해서는, [IBM 클라우드 컨테이너 레지스트리 시작하기](https://cloud.ibm.com/docs/services/Registry?topic=registry-getting-started)를 참고한다. +IBM 클라우드 컨테이너 레지스트리 CLI 플러그인을 설치하고 사용자 이미지를 위한 네임스페이스를 생성하기 위해서는, [IBM 클라우드 컨테이너 레지스트리 시작하기](https://cloud.ibm.com/docs/Registry?topic=registry-getting-started)를 참고한다. -[IBM 클라우드 퍼블릭 이미지](https://cloud.ibm.com/docs/services/Registry?topic=registry-public_images) 및 사용자의 프라이빗 이미지로부터 컨테이너를 사용자의 IBM 클라우드 쿠버네티스 서비스 클러스터의 `default` 네임스페이스에 디플로이하기 위해서 IBM 클라우드 컨테이너 레지스트리를 사용하면 된다. 컨테이너를 다른 네임스페이스에 디플로이하거나, 다른 IBM 클라우드 컨테이너 레지스트리 지역 또는 IBM 클라우드 계정을 사용하기 위해서는, 쿠버네티스 `imagePullSecret`를 생성한다. 더 자세한 정보는, [이미지로부터 컨테이너 빌드하기](https://cloud.ibm.com/docs/containers?topic=containers-images)를 참고한다. +다른 추가적인 구성이 없는 IBM 클라우드 쿠버네티스 서비스 클러스터의 IBM 클라우드 컨테이너 레지스트리 내 기본 네임스페이스에 저장되어 있는 배포된 이미지를 동일 계정과 동일 지역에서 사용하려면 [이미지로부터 컨테이너 빌드하기](https://cloud.ibm.com/docs/containers?topic=containers-images)를 본다. 다른 구성 옵션에 대한 것은 [레지스트리부터 클러스터에 이미지를 가져오도록 권한을 부여하는 방법 이해하기](https://cloud.ibm.com/docs/containers?topic=containers-registry#cluster_registry_auth)를 본다. ### 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 @@ -239,6 +240,7 @@ kubectl describe pods/private-image-test-1 | grep 'Failed' Fri, 26 Jun 2015 15:36:13 -0700 Fri, 26 Jun 2015 15:39:13 -0700 19 {kubelet node-i2hq} spec.containers{uses-private-image} failed Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found ``` + 클러스터의 모든 노드가 반드시 동일한 `.docker/config.json`를 가져야 한다. 그렇지 않으면, 파드가 일부 노드에서만 실행되고 다른 노드에서는 실패할 것이다. 예를 들어, 노드 오토스케일링을 사용한다면, 각 인스턴스 템플릿은 `.docker/config.json`을 포함하거나 그것을 포함한 드라이브를 마운트해야 한다. @@ -362,7 +364,6 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다. - 테넌트는 해당 시크릿을 각 네임스페이스의 imagePullSecrets에 추가한다. - 다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다. Kubelet은 모든`imagePullSecrets` 파일을 하나의 가상`.docker / config.json` 파일로 병합한다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/names.md b/content/ko/docs/concepts/overview/working-with-objects/names.md index 0804c0d425..0ab2681a77 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/names.md +++ b/content/ko/docs/concepts/overview/working-with-objects/names.md @@ -1,5 +1,5 @@ --- -title: 이름(Name) +title: 오브젝트 이름과 ID content_template: templates/concept weight: 20 --- @@ -22,7 +22,35 @@ weight: 20 {{< glossary_definition term_id="name" length="all" >}} -관례에 따라, 쿠버네티스 리소스의 이름은 최대 253자까지 허용되고 소문자 알파벳과 숫자(alphanumeric), `-`, 그리고 `.`로 구성되며 특정 리소스는 보다 구체적인 제약을 갖는다. +다음은 리소스에 일반적으로 사용되는 세가지 유형의 이름 제한 조건이다. + +### DNS 서브도메인 이름들 + +대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로 +DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다. +이것은 이름이 다음을 충족해야 한다는 것을 의미한다. + +- 253자를 넘지 말아야 한다. +- 소문자와 영숫자 `-` 또는 `.` 만 포함한다. +- 영숫자로 시작한다. +- 영숫자로 끝난다. + +### DNS 레이블 이름 + +일부 리소스 유형은 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 +정의된 대로 DNS 레이블 표준을 따라야 한다. +이것은 이름이 다음을 충족해야 한다는 것을 의미한다. + +- 최대 63자이다. +- 소문자와 영숫자 또는 `-` 만 포함한다. +- 영숫자로 시작한다. +- 영숫자로 끝난다. + +### 경로 세그먼트 이름 + +일부 리소스 유형에서는 이름을 경로 세그먼트로 안전하게 인코딩 할 수 +있어야 한다. 즉 이름이 "." 또는 ".."이 아닐 수 있으며 이름에는 +"/" 또는 "%"가 포함될 수 없다. 여기 파드의 이름이 `nginx-demo`라는 매니페스트 예시가 있다. @@ -39,6 +67,7 @@ spec: - containerPort: 80 ``` + {{< note >}} 일부 리소스 유형은 이름에 추가적인 제약이 있다. {{< /note >}} diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 793a1520e3..64d610a499 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -334,7 +334,7 @@ spec: {{< note >}} TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능 차이가 있다. 사용자 환경에서의 TLS의 작동 방식을 이해하려면 -[nginx](https://git.k8s.io/ingress-nginx/README.md#https), +[nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/), [GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https) 또는 기타 플랫폼의 특정 인그레스 컨트롤러에 대한 설명서를 참조한다. {{< /note >}} diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index ff76d12f86..4e912069ec 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -13,9 +13,14 @@ _크론 잡은_ 시간 기반의 일정에 따라 [잡](/docs/concepts/workloads 하나의 크론잡 객체는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://en.wikipedia.org/wiki/Cron)형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. -{{< note >}} -모든 **크론잡** `일정:` 시간은 잡이 처음 시작된 마스터의 시간대를 기반으로 한다. -{{< /note >}} +{{< caution >}} +모든 **크론잡** `일정:` 시간은 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +의 시간대를 기준으로 한다. + +컨트롤 플레인이 파드 또는 베어 컨테이너에서 kube-controller-manager를 +실행하는 경우 kube-controller-manager 컨테이너의 설정된 시간대는 크론 잡 컨트롤러가 +사용하는 시간대로 설정한다. +{{< /caution >}} 크론잡 리소스에 대한 매니페스트를 생성할때에는 제공하는 이름이 52자 이하인지 확인해야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에 diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index f5d199c746..47b74587aa 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -71,53 +71,50 @@ kubectl describe rs/frontend 출력은 다음과 유사할 것이다. ```shell -Name: frontend -Namespace: default -Selector: tier=frontend -Labels: app=guestbook - tier=frontend -Annotations: -Replicas: 3 current / 3 desired -Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed +Name: frontend +Namespace: default +Selector: tier=frontend +Labels: app=guestbook + tier=frontend +Annotations: kubectl.kubernetes.io/last-applied-configuration: + {"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"labels":{"app":"guestbook","tier":"frontend"},"name":"frontend",... +Replicas: 3 current / 3 desired +Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template: - Labels: app=guestbook - tier=frontend + Labels: tier=frontend Containers: php-redis: - Image: gcr.io/google_samples/gb-frontend:v3 - Port: 80/TCP - Requests: - cpu: 100m - memory: 100Mi - Environment: - GET_HOSTS_FROM: dns - Mounts: - Volumes: + Image: gcr.io/google_samples/gb-frontend:v3 + Port: + Host Port: + Environment: + Mounts: + Volumes: Events: - FirstSeen LastSeen Count From SubobjectPath Type Reason Message - --------- -------- ----- ---- ------------- -------- ------ ------- - 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh - 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy - 1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 117s replicaset-controller Created pod: frontend-wtsmm + Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-b2zdv + Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-vcmts ``` 마지막으로 파드가 올라왔는지 확인할 수 있다. ```shell -kubectl get Pods +kubectl get pods ``` 다음과 유사한 파드 정보를 볼 수 있다. ```shell -NAME READY STATUS RESTARTS AGE -frontend-9si5l 1/1 Running 0 1m -frontend-dnjpy 1/1 Running 0 1m -frontend-qhloh 1/1 Running 0 1m +NAME READY STATUS RESTARTS AGE +frontend-b2zdv 1/1 Running 0 6m36s +frontend-vcmts 1/1 Running 0 6m36s +frontend-wtsmm 1/1 Running 0 6m36s ``` 또한 파드들의 소유자 참조 정보가 해당 프런트엔드 레플리카셋으로 설정되어 있는지 확인할 수 있다. 확인을 위해서는 실행 중인 파드 중 하나의 yaml을 확인한다. ```shell -kubectl get pods frontend-9si5l -o yaml +kubectl get pods frontend-b2zdv -o yaml ``` 메타데이터의 ownerReferences 필드에 설정되어있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다. @@ -125,11 +122,11 @@ kubectl get pods frontend-9si5l -o yaml apiVersion: v1 kind: Pod metadata: - creationTimestamp: 2019-01-31T17:20:41Z + creationTimestamp: "2020-02-12T07:06:16Z" generateName: frontend- labels: tier: frontend - name: frontend-9si5l + name: frontend-b2zdv namespace: default ownerReferences: - apiVersion: apps/v1 @@ -137,7 +134,7 @@ metadata: controller: true kind: ReplicaSet name: frontend - uid: 892a2330-257c-11e9-aecd-025000000001 + uid: f391f6db-bb9b-4c09-ae74-6a1f77f3d5cf ... ``` @@ -166,16 +163,17 @@ kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml 파드를 가져온다. ```shell -kubectl get Pods +kubectl get pods ``` 결과에는 새로운 파드가 이미 종료되었거나 종료가 진행 중인 것을 보여준다. ```shell NAME READY STATUS RESTARTS AGE -frontend-9si5l 1/1 Running 0 1m -frontend-dnjpy 1/1 Running 0 1m -frontend-qhloh 1/1 Running 0 1m -pod2 0/1 Terminating 0 4s +frontend-b2zdv 1/1 Running 0 10m +frontend-vcmts 1/1 Running 0 10m +frontend-wtsmm 1/1 Running 0 10m +pod1 0/1 Terminating 0 1s +pod2 0/1 Terminating 0 1s ``` 파드를 먼저 생성한다. @@ -191,15 +189,15 @@ kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml 레플리카셋이 해당 파드를 소유한 것을 볼 수 있으며 새 파드 및 기존 파드의 수가 레플리카셋이 필요로 하는 수와 일치할 때까지 사양에 따라 신규 파드만 생성한다. 파드를 가져온다. ```shell -kubectl get Pods +kubectl get pods ``` 다음 출력에서 볼 수 있다. ```shell NAME READY STATUS RESTARTS AGE -frontend-pxj4r 1/1 Running 0 5s -pod1 1/1 Running 0 13s -pod2 1/1 Running 0 13s +frontend-hmmj2 1/1 Running 0 9s +pod1 1/1 Running 0 36s +pod2 1/1 Running 0 36s ``` 이러한 방식으로 레플리카셋은 템플릿을 사용하지 않는 파드를 소유하게 된다. diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md index ff6cc0284f..48a8bdb303 100644 --- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -33,8 +33,8 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 완료된 잡(`완료` 또는 `실패`)을 자동으로 정리하기 위해 이 기능을 사용할 수 있다. 리소스의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때), TTL 컨트롤러는 해당 리소스가 정리될 수 있다고 가정한다. -TTL 컨트롤러가 리소스를 정리할때 리소스를 연속적으로 삭제한다. 즉, -의존하는 오브젝트와 함께 삭제한다. 리소스가 삭제되면 완료자(finalizers)와 +TTL 컨트롤러가 리소스를 정리할때 리소스를 연속적으로 삭제한다. 이는 +의존하는 오브젝트도 해당 리소스와 함께 삭제되는 것을 의미한다. 리소스가 삭제되면 완료자(finalizers)와 같은 라이프 사이클 보증이 적용 된다. TTL 초(sec)는 언제든지 설정이 가능하다. 여기에 잡 필드 중 diff --git a/content/ko/docs/contribute/participating.md b/content/ko/docs/contribute/participating.md index 88db56aa34..f1abbfc27c 100644 --- a/content/ko/docs/contribute/participating.md +++ b/content/ko/docs/contribute/participating.md @@ -24,6 +24,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. 쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md) 문서를 확인한다. + 문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스 웹사이트와 문서를 관리하는 책임을 가지는 SIG Docs에서, 이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다. @@ -52,7 +53,8 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. 누구나 다음 작업을 할 수 있다. - 문서를 포함한 쿠버네티스의 모든 부분에 대해 GitHub 이슈 열기. -- 풀 리퀘스트/ 에 대한 구속력 없는 피드백 제공 +- 풀 리퀘스트에 대한 구속력 없는 피드백 제공 +- 기존 컨텐츠를 현지화하는데 도움주는 것 - [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선할 아이디어를 제시한다. - `/lgtm` Prow 명령 ("looks good to me" 의 줄임말)을 사용해서 병합을 위한 풀 리퀘스트의 변경을 추천한다. {{< note >}} @@ -120,7 +122,6 @@ GitHub 그룹의 멤버이다. 리뷰어는 문서 풀 리퀘스트를 리뷰하 - 이슈 해결 및 분류 - 풀 리퀘스트 리뷰와 구속력있는 피드백 제공 - 다이어그램, 그래픽 자산과 포함가능한 스크린샷과 비디오를 생성 -- 현지화 - 코드에서 사용자 화면 문자열 편집 - 코드 코멘트 개선 @@ -166,7 +167,7 @@ GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-adm 승인자는 [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) -GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-within-sig-docs) 문서를 참조한다. +GitHub 그룹의 멤버이다. [SIG Docs 팀과 자동화](#sig-docs-팀과-자동화) 문서를 참조한다. 승인자는 다음의 작업을 할 수 있다. @@ -225,7 +226,7 @@ GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-adm 것으로 기대한다. [일주일 간 PR Wrangler 되기](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) 문서를 참고한다. -## SIG Docs chairperson +## SIG Docs 의장 SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와 다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과 @@ -297,7 +298,7 @@ PR 소유자에게 조언하는데 활용된다. - 모든 쿠버네티스 맴버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다. - SIG Docs 승인자들만이 코멘트에 `/approve` 를 추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은 - [PR Wrangler](#pr-wrangler) EHsms [SIG Docs 의장](#sig-docs-chairperson)과 + [PR Wrangler](#pr-wrangler) 또는 [SIG Docs 의장](#sig-docs-의장)과 같은 특정 역할도 수행한다. {{% /capture %}} diff --git a/content/ko/docs/tasks/_index.md b/content/ko/docs/tasks/_index.md index 4289d0544d..9624c907d3 100644 --- a/content/ko/docs/tasks/_index.md +++ b/content/ko/docs/tasks/_index.md @@ -57,10 +57,6 @@ content_template: templates/concept 클러스터를 운영하기 위한 일반적인 태스크를 배운다. -## 페더레이션(federation) 운영하기(administering) - -클러스터 페더레이션의 컴포넌트들을 구성한다. - ## 스테이트풀 애플리케이션 관리하기 스테이트풀 셋의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다. diff --git a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 0a3778288d..0ab00f5d1c 100644 --- a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -86,7 +86,9 @@ kubectl config --kubeconfig=config-demo set-credentials experimenter --username= ``` {{< note >}} -`kubectl config unset users.`을 실행하여 사용자를 삭제할 수 있다. +- 사용자를 삭제하려면 `kubectl --kubeconfig=config-demo config unset users.` 를 실행한다. +- 클러스터를 제거하려면 `kubectl --kubeconfig=config-demo config unset clusters.` 를 실행한다. +- 컨텍스트를 제거하려면 `kubectl --kubeconfig=config-demo config unset contexts.` 를 실행한다. {{< /note >}} 컨텍스트 세부사항들을 구성 파일에 추가한다. diff --git a/content/ko/docs/tutorials/online-training/overview.md b/content/ko/docs/tutorials/online-training/overview.md index 9a9dfd794b..44f1c69ddc 100644 --- a/content/ko/docs/tutorials/online-training/overview.md +++ b/content/ko/docs/tutorials/online-training/overview.md @@ -39,8 +39,6 @@ content_template: templates/concept * [Hands-on Introduction to Kubernetes (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes) -* [IBM Cloud: Deploying Microservices with Kubernetes (Coursera)](https://www.coursera.org/learn/deploy-micro-kube-ibm-cloud) - * [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x) * [Kubernetes Essentials with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials) From b68978c959ecf7337b334023aa7fc73587bc7363 Mon Sep 17 00:00:00 2001 From: Sophy417 <53026875+Sophy417@users.noreply.github.com> Date: Sat, 7 Mar 2020 14:35:34 +0800 Subject: [PATCH 035/194] Create proxy.md (#19510) --- content/zh/docs/reference/glossary/proxy.md | 55 +++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 content/zh/docs/reference/glossary/proxy.md diff --git a/content/zh/docs/reference/glossary/proxy.md b/content/zh/docs/reference/glossary/proxy.md new file mode 100644 index 0000000000..e8ab669393 --- /dev/null +++ b/content/zh/docs/reference/glossary/proxy.md @@ -0,0 +1,55 @@ +--- +title: 代理 +id: proxy +date: 2019-09-10 +short_description: > + 充当客户端和服务器之间的中介的应用程序 + +aka: +tags: +- networking +--- + + +在计算机领域，代理指的是充当远程服务中介的服务器。 + + + + + +客户端与代理进行交互；代理将客户端的数据复制到实际服务器；实际服务器回复代理；代理将实际服务器的回复发送给客户端。 + + +[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) 是集群中每个节点上运行的网络代理，实现了部分 Kubernetes {{< glossary_tooltip term_id="service">}} 概念。 + + +你可以将 kube-proxy 作为普通的用户态代理服务运行。 +如果你的操作系统支持，则可以在混合模式下运行 kube-proxy；该模式使用较少的系统资源即可达到相同的总体效果。 + From 8f371f4c84b4122d98c10021282bb0c3f6a2467d Mon Sep 17 00:00:00 2001 From: bryan Date: Sat, 7 Mar 2020 16:43:34 +0800 Subject: [PATCH 036/194] Add zh translation of `Metrics For The Kubernetes Control Plane` (#19403) * Add zh translation of * update some translations * resolve conversation * resolve conversation --- .../cluster-administration/monitoring.md | 222 ++++++++++++++++++ 1 file changed, 222 insertions(+) create mode 100644 content/zh/docs/concepts/cluster-administration/monitoring.md diff --git a/content/zh/docs/concepts/cluster-administration/monitoring.md b/content/zh/docs/concepts/cluster-administration/monitoring.md new file mode 100644 index 0000000000..b2ff727eac --- /dev/null +++ b/content/zh/docs/concepts/cluster-administration/monitoring.md @@ -0,0 +1,222 @@ +--- +title: Kubernetes 控制面板的指标 +content_template: templates/concept +weight: 60 +--- + +{{% capture overview %}} + + + +系统组件的指标可以让我们更好的看清系统内部究竟发生了什么，尤其对于构建仪表盘和告警都非常有用。 + +Kubernetes 控制面板中的指标是以 [prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/) 格式发出的，而且是易于阅读的。 + +{{% /capture %}} + +{{% capture body %}} + + + +## Kubernetes 的指标 + +在大多数情况下，指标在 HTTP 服务器的 `/metrics` 端点使用，对于默认情况下不暴露端点的组件，可以使用 `--bind-address` 参数启用。 + + + +举例下面这些组件： + +* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +* {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} +* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} +* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} + + + +在生产环境中，你可能需要配置 [Prometheus Server](https://prometheus.io/) 或其他指标收集器来定期收集这些指标，并使它们在某种时间序列数据库中可用。 + +请注意 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 同样在 `/metrics/cadvisor`、`/metrics/resource` 和 `/metrics/probes` 等端点提供性能指标。这些指标的生命周期并不相同。 + +如果你的集群还使用了 {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ，那读取指标数据的时候，还需要通过具有 ClusterRole 的用户、组或者 ServiceAccount 来进行授权，才有权限访问 `/metrics` 。 + +举例： + +``` +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: prometheus +rules: + - nonResourceURLs: + - "/metrics" + verbs: + - get +``` + + + +## 指标的生命周期 + +内测版指标 → 稳定版指标 → 弃用指标 → 隐藏指标 → 删除 + +内测版指标没有任何稳定性保证，因此可能随时被修改或删除。 + +稳定版指标可以保证不会改变，具体的说，稳定就意味着： + + + +* 这个指标自身不会被删除或者重命名。 +* 这个指标类型不会被更改 + + + +弃用指标表明这个指标最终将会被删除，要想查找是哪个版本，你需要检查其注释，注释中包括该指标从哪个 kubernetes 版本被弃用。 + +指标弃用前： + +``` +# HELP some_counter this counts things +# TYPE some_counter counter +some_counter 0 +``` + + + +指标弃用后： + +``` +# HELP some_counter (Deprecated since 1.15.0) this counts things +# TYPE some_counter counter +some_counter 0 +``` + + + +一个指标一旦被隐藏，默认这个指标是不会发布来被抓取的。如果你想要使用这个隐藏指标，你需要覆盖相关集群组件的配置。 + +一个指标一旦被删除，那这个指标就不会被发布，您也不可以通过覆盖配置来进行更改。 + + + +## 显示隐藏指标 + +综上所述，管理员可以通过在运行可执行文件时添加一些特定的参数来开启一些隐藏的指标。当管理员错过了之前版本的的一些已弃用的指标时，这个可被视作是一个后门。 + +`show-hidden-metrics-for-version` 参数可以指定一个版本，用来显示这个版本中被隐藏的指标。这个版本号形式是x.y，x 是主要版本号，y 是次要版本号。补丁版本并不是必须的，尽管在一些补丁版本中也会有一些指标会被弃用，因为指标弃用策略主要是针对次要版本。 + +这个参数只能使用上一版本作为其值，如果管理员将上一版本设置为 `show-hidden-metrics-for-version` 的值，那么就会显示上一版本所有被隐藏的指标，太老的版本是不允许的，因为这不符合指标弃用策略。 + +以指标 `A` 为例，这里假设 `A` 指标在 1.n 版本中被弃用，根据指标弃用策略，我们可以得出以下结论： + + + +* 在 `1.n` 版本中，这个指标被弃用，并且默认情况下，这个指标还是可以发出. +* 在 `1.n+1` 版本中，这个指标默认被隐藏，你可以通过设置参数 `show-hidden-metrics-for-version=1.n` 来使它可以被发出. +* 在 `1.n+2` 版本中，这个指标就被从代码库中删除，也不会再有后门了. + +如果你想要从 `1.12` 版本升级到 `1.13` ，但仍然需要依赖指标 `A` ，你可以通过命令行设置隐藏指标 `--show-hidden-metrics=1.12` ，但是在升级到 `1.14`时就必须要删除这个指标的依赖，因为这个版本中这个指标已经被删除了。 + + + +## 组件指标 + +### kube-controller-manager 指标 + +控制器管理器指标提供了有关控制器管理器性能和运行状况的重要见解。这些指标包括常见的一些 Go 语言运行时的重要指标（比如 go_routine 的数量）和一些控制器的特定指标（比如 etcd 的请求时延），还有一些云供应商（比如 AWS、GCE、OpenStack）的 API 请求延迟，用来评估集群的整体运行状况。 + +从 Kubernetes 1.7 开始，详细的云供应商指标便可用于 GCE、 AWS、Vsphere 和 OpenStack 的存储操作，这些指标可用于监控持久卷运行时的健康状况。 + +举例，GCE 的这些指标是这些： + +``` +cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} +cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} +``` + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* 了解有关 [Prometheus 指标相关的文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) +* 查看 [Kubernetes 稳定版指标](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)列表 +* 了解有关 [Kubernetes 指标弃用策略](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior ) + +{{% /capture %}} From 2e55fa8a4732250f4ac347548e466970c36d680a Mon Sep 17 00:00:00 2001 From: Alexey Pyltsyn Date: Sat, 7 Mar 2020 11:47:34 +0300 Subject: [PATCH 037/194] Translate Documentation style overview section into Russian (#19521) --- content/ru/docs/contribute/style/_index.md | 7 + .../ru/docs/contribute/style/content-guide.md | 101 ++++ .../contribute/style/content-organization.md | 131 ++++ .../style/hugo-shortcodes/example1.md | 9 + .../style/hugo-shortcodes/example2.md | 7 + .../contribute/style/hugo-shortcodes/index.md | 245 ++++++++ .../style/hugo-shortcodes/podtemplate.json | 22 + .../docs/contribute/style/page-templates.md | 186 ++++++ .../ru/docs/contribute/style/style-guide.md | 570 ++++++++++++++++++ .../docs/contribute/style/write-new-topic.md | 119 ++++ 10 files changed, 1397 insertions(+) create mode 100644 content/ru/docs/contribute/style/_index.md create mode 100644 content/ru/docs/contribute/style/content-guide.md create mode 100644 content/ru/docs/contribute/style/content-organization.md create mode 100644 content/ru/docs/contribute/style/hugo-shortcodes/example1.md create mode 100644 content/ru/docs/contribute/style/hugo-shortcodes/example2.md create mode 100644 content/ru/docs/contribute/style/hugo-shortcodes/index.md create mode 100644 content/ru/docs/contribute/style/hugo-shortcodes/podtemplate.json create mode 100644 content/ru/docs/contribute/style/page-templates.md create mode 100644 content/ru/docs/contribute/style/style-guide.md create mode 100644 content/ru/docs/contribute/style/write-new-topic.md diff --git a/content/ru/docs/contribute/style/_index.md b/content/ru/docs/contribute/style/_index.md new file mode 100644 index 0000000000..57686140c2 --- /dev/null +++ b/content/ru/docs/contribute/style/_index.md @@ -0,0 +1,7 @@ +--- +title: Обзор оформления документации +main_menu: true +weight: 80 +--- + +Темы в этом разделе содержат рекомендации по написанию, форматированию и организации контента, а также охватывают настройку Hugo в контексте документации Kubernetes. diff --git a/content/ru/docs/contribute/style/content-guide.md b/content/ru/docs/contribute/style/content-guide.md new file mode 100644 index 0000000000..567e3b6dce --- /dev/null +++ b/content/ru/docs/contribute/style/content-guide.md @@ -0,0 +1,101 @@ +--- +title: Руководство по содержанию документации +linktitle: Руководство по содержанию +content_template: templates/concept +weight: 10 +card: + name: contribute + weight: 20 + title: Руководство по содержанию документации +--- + +{{% capture overview %}} + +Эта страница содержит рекомендации по добавлению контента в документацию Kubernetes. +Если у вас есть вопросы по поводу допустимого контента, обратитесь к каналу #sig-docs в [Slack Kubernetes](http://slack.k8s.io/) и задайте свои вопросы! Поступайте на своё усмотрение и не стесняйтесь вносить изменения в этот документ через пулреквест. + +Для получения дополнительной информации о создании нового контента для документации Kubernetes следуйте инструкциям в [руководстве по оформлению](/ru/docs/contribute/style/style-guide). +{{% /capture %}} + +{{% capture body %}} + +## Участие в контенте + +Документация Kubernetes включает содержимое из оригинального репозитория [kubernetes/website](https://github.com/kubernetes/website). Документация Kubernetes находится в директории `kubernetes/website/content//docs`, большая часть которой относится к [проекту Kubernetes](https://github.com/kubernetes/kubernetes). Документация Kubernetes может также включать содержимое их проектов в GitHub-организациях [kubernetes](https://github.com/kubernetes) и [kubernetes-sigs](https://github.com/kubernetes-sigs), если у этих проектов нет собственной документации. Всегда можно ссылаться на действующие проекты kubernetes, kubernetes-sigs и ({{< glossary_tooltip text="CNCF" term_id="cncf" >}}) в документации Kubernetes, но перелинковка с продуктами определённого разработчика не допускается. Проверьте списки проектов CNCF ([Graduated/Incubating](https://www.cncf.io/projects/), [Sandbox](https://www.cncf.io/sandbox-projects/), [Archived](https://www.cncf.io/archived-projects/)), если вы не уверены в статусе CNCF проекта + +### Контент, полученный из двух источников + +Документация Kubernetes не содержит дублированный контент, полученный из разных мест (так называемый **контент из двумя источниками**). Контент из двух источников требует дублирования работы со стороны мейнтейнеров проекта и к тому же быстро теряет актуальность. +Перед добавлением контента, задайте себе вопрос: + +- Новая информация относится к действующему проекту CNCF ИЛИ проекту в организациях на GitHub kubernetes или kubernetes-sigs? + - Если да, то: + - У этого проекта есть собственная документация? + - если да, то укажите ссылку на документацию проекта в документации Kubernetes + - если нет, добавьте информацию в репозиторий проекта (если это возможно), а затем укажите ссылку на неё в документации Kubernetes + - Если нет, то: + - Остановитесь! + - Добавление информации по продуктам от других разработчиков не допускается + - Не разрешено ссылаться на документацию и сайты сторонних разработчиков. + +### Разрешенная и запрещённая информация + +Есть несколько условий, когда в документации Kubernetes может быть информация, относящиеся не к проектам Kubernetes. +Ниже перечислены основные категории по содержанию проектов, не касающихся к Kubernetes, а также приведены рекомендации о том, что разрешено, а что нет: + +1. Инструкции по установке или эксплуатации Kubernetes, которые не связаны с проектами Kubernetes + - Разрешено: + - Ссылаться на документацию на CNCF-проекта или на проект в GitHub-организациях kubernetes или kubernetes-sigs + - Пример: для установки Kubernetes в процессе обучения нужно обязательно установить и настроить minikube, а также сослаться на соответствующую документацию minikube + - Добавление инструкций для проектов в организации kubernetes или kubernetes-sigs, если по ним нет инструкций + - Пример: добавление инструкций по установке и решению неполадок [kubadm](https://github.com/kubernetes/kubeadm) + - Запрещено: + - Добавление информацию, которая повторяет документацию в другом репозитории + - Примеры: + - Добавление инструкций по установке и настройке minikube; Minikube имеет собственную [документацию](https://minikube.sigs.k8s.io/docs/), которая включают эти инструкции + - Добавление инструкций по установке Docker, CRI-O, containerd и других окружений для выполнения контейнеров в разных операционных системах + - Добавление инструкций по установке Kubernetes в промышленных окружениях, используя разные проекты: + -Kubernetes Rebar Integrated Bootstrap (KRIB) — это проект стороннего разработчика, поэтому все содержимое находится репозитории разработчика. + - У проекта [Kubernetes Operations (kops)](https://github.com/kubernetes/kops) есть инструкции по установке и руководства в GitHub-репозитории. + - У проекта [Kubespray](https://kubespray.io) есть собственная документация + - Добавление руководства, в котором объясняется, как выполнить задачу с использованием продукта определенного разработчика или проекта с открытым исходным кодом, не являющиеся CNCF-проектом или проектом в GitHub-организациях kubernetes или kubnetes-sigs. + - Добавление руководства по использованию CNCF-проекта или проекта в GitHub-организациях kubernetes или kubnetes-sigs, если у проекта есть собственная документация +1. Подробное описание технических аспектов по использованию стороннего проекта (не Kubernetes) или как этот проект разработан + + Добавление такого типа информации в документацию Kubernetes не допускается. +1. Информация стороннему проекту + - Разрешено: + - Добавление краткого введения о CNCF-проекте или проекте в GitHub-организациях kubernetes или kubernetes-sigs; этот абзац может содержать ссылки на проект + - Запрещено: + - Добавление информации по продукту определённого разработчика + - Добавление информации по проекту с открытым исходным кодом, который не является CNCF-проектом или проектом в GitHub-организациях kubernetes или kubnetes-sigs + - Добавление информации, дублирующего документацию из другого проекта, независимо от оригинального репозитория + - Пример: добавление документации для проекта [Kubernetes in Docker (KinD)](https://kind.sigs.k8s.io) в документацию Kubernetes +1. Только ссылки на сторонний проект + - Разрешено: + - Ссылаться на проекты в GitHub-организациях kubernetes и kubernetes-sigs + - Пример: добавление ссылок на [документацию](https://kind.sigs.k8s.io/docs/user/quick-start) проекта Kubernetes in Docker (KinD), который находится в GitHub-организации kubernetes-sigs + - Добавление ссылок на действующие CNCF-проекты + - Пример: добавление ссылок на [документацию](https://prometheus.io/docs/introduction/overview/) проекта Prometheus; Prometheus — это действующий проект CNCF + - Запрещено: + - Ссылаться на продукты стороннего разработчика + - Ссылаться на архивированные проекты CNCF + - Ссылаться на недействующие проекты в организациях GitHub в kubernetes и kubernetes-sigs + - Ссылаться на проекты с открытым исходным кодом, которые не являются проектами CNCF или не находятся в организациях GitHub kubernetes или kubernetes-sigs. +1. Содержание учебных курсов + - Разрешено: + - Ссылаться на независимые от разработчиков учебные курсы Kubernetes, предлагаемыми [CNCF](https://www.cncf.io/), [Linux Foundation](https://www.linuxfoundation.org/) и [Linux Academy](https://linuxacademy.com/) (партнер Linux Foundation) + - Пример: добавление ссылок на курсы Linux Academy, такие как [Kubernetes Quick Start](https://linuxacademy.com/course/kubernetes-quick-start/) в [Kubernetes Security](https://linuxacademy.com/course/kubernetes-security/) + - Запрещено: + - Ссылаться на учебныЕе онлайн-курсы, вне CNCF, Linux Foundation или Linux Academy; документация Kubernetes не содержит ссылок на сторонний контент + - Пример: добавление ссылок на учебные руководства или курсы Kubernetes на Medium, KodeKloud, Udacity, Coursera, learnk8s и т.д. + - Ссылаться на руководства определённых разработчиков вне зависимости от обучающей организации + - Пример: добавление ссылок на такие курсы Linux Academy, как [Google Kubernetes Engine Deep Dive](https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive) and [Amazon EKS Deep Dive](https://linuxacademy.com/course/amazon-eks-deep-dive/) + +Если у вас есть вопросы по поводу допустимого контента, присоединяйтесь к каналу #sig-docs в [Slack Kubernetes](http://slack.k8s.io/)! + +{{% /capture %}} + +{{% capture whatsnext %}} +* Прочитайте [руководство по оформлению](/ru/docs/contribute/style/style-guide). +{{% /capture %}} diff --git a/content/ru/docs/contribute/style/content-organization.md b/content/ru/docs/contribute/style/content-organization.md new file mode 100644 index 0000000000..5c2e00dba6 --- /dev/null +++ b/content/ru/docs/contribute/style/content-organization.md @@ -0,0 +1,131 @@ +--- +title: Организация контента +content_template: templates/concept +weight: 40 +--- + + +{{% capture overview %}} + +Этот сайт использует Hugo. В Hugo [организация контента](https://gohugo.io/content-management/organization/) — основная концепция. + +{{% /capture %}} + +{{% capture body %}} + +{{% note %}} +**Подсказка:** при редактировании контента используйте команду `hugo server --navigateToChanged`, чтобы запустить Hugo. +{{% /note %}} + +## Списки страниц + +### Порядок страницы + +Меню в сайдбаре, каталог страниц документации используют стандартный порядок перечисления Hugo, который сортирует элементы по весу (от 1), дате (начиная с самых новых) и затем по заголовку ссылки. + +Таким образом, если вам нужно поднять страницу или раздел, определите её вес в фронтальной части: + +```yaml +title: Моя страница +weight: 10 +``` + +{{% note %}} +Для значений веса страниц лучше не использовать привычный порядок 1, 2, 3..., а предпочесть другой интервал, например, 10, 20, 30... В будущем это позволит вставить последующие страницы в желаемую позицию. +{{% /note %}} + +### Главное меню документации + +Главное меню `Документация` состоит из разделов по пути `docs/` с установленным флагом `main_menu` в фронтальной части файла раздела `_index.md`: + +```yaml +main_menu: true +``` + +Обратите внимание, что текст ссылки берётся из переменной `linkTitle`, поэтому, если вы хотите, чтобы он отличался от заголовка страницы, измените его в файле: + +```yaml +main_menu: true +title: Название страницы +linkTitle: Название, которое будет использоваться в ссылках +``` + +{{% note %}} +Перечисленные выше переменные должны быть определены для каждого перевода. Если вы не видите созданный вами раздел в меню, скорее всего, это может быть связано с тем, что Hugo не определил его как раздел. Создайте файл `_index.md` в директории раздела. +{{% /note %}} + +### Документация в боковом меню + +Меню сайдбара в документации собирается из _текущего дерева разделов_ по пути `docs/`. + +Оно отобразит все разделы и их страницы. + +Если вы хотите, чтобы раздел или страница не отображались в меню, установите для флага `toc_hide` значение `true` в фронтальной части файла: + +```yaml +toc_hide: true +``` + +При переходе к непустому разделу будет отображаться указанный раздел или страница (например, `_index.md`). В противном случае выводиться первая страница в этом разделе. + +### Каталог документации + +Каталог страниц на главной странице документации сгенерирован с учётом всех разделов и страниц документации. + +Если вы хотите скрыть раздел или страницу, установите для флага `toc_hide` значение `true` в фронтальной части файла: + +```yaml +toc_hide: true +``` + +### Главное меню + +Ссылки сайта в верхнем правом меню, а также в футере, создаются посредством сканирования страниц. Этот процесс гарантирует, что страница действительно существует на сайте. Поэтому, если раздела `case-studies` на сайте (или в переводе) не существует, ссылка не появится. + +## Пакеты страниц + +В дополнение к отдельным страницам с контентом (Markdown-файлам), Hugo поддерживает [пакеты страниц (page bundles)](https://gohugo.io/content-management/page-bundles/). + +К примеру, [пользовательские макрокоды Hugo](/docs/contribute/style/hugo-shortcodes/) — узел пакета (`leaf bundle`). Все, что находится в директории, включая `index.md`, будет частью пакета. Сюда также относятся относительные ссылки на страницы, изображения, которые могут быть обработаны и т.д.: + +```bash +en/docs/home/contribute/includes +├── example1.md +├── example2.md +├── index.md +└── podtemplate.json +``` + +Другой распространённый пример — это пакет `includes`. Он устанавливает переменную `headless: true`, которая означает, что файл не будет доступен по собственному URL-адресу. Вместо этого он будет использоваться в других страницах как вставляемый файл. + +```bash +en/includes +├── default-storage-class-prereqs.md +├── federated-task-tutorial-prereqs.md +├── index.md +├── partner-script.js +├── partner-style.css +├── task-tutorial-prereqs.md +├── user-guide-content-moved.md +└── user-guide-migration-notice.md +``` + +Необходимо отметить следующие особенности файлов в пакетах: + +* Для переведенных пакетов любые отсутствующие файлы будут унаследованы от файлов на оригинальном (английском) языке. Это позволяет избежать дублирования. +* Все файлы в пакете — в Hugo называются ресурсы (`Resources`), в которых вы можете определить метаданные, зависимые от языка, например, параметры и заголовок, даже если они не поддерживают в фронтальной части (YAML-файлы и т.д.). Смотрите [Метаданные ресурсов страницы](https://gohugo.io/content-management/page-resources/#page-resources-metadata) для получения дополнительной информации. +* Значение, которое вы получаете через `.RelPermalink` в `Resource` будет отличаться в зависимости от страницы. Смотрите [Постоянные ссылки](https://gohugo.io/content-management/urls/#permalinks) для получения дополнительной информации. + +## Стилизация + +Исходные файлы стилей в формате [SASS](https://sass-lang.com/) находятся в директории `assets/sass` и автоматически собираются Hugo. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* Подробнее про [пользовательские макрокоды Hugo](/ru/docs/contribute/style/hugo-shortcodes/) +* Подробнее про [оформление документации](/ru/docs/contribute/style/style-guide) +* Подробнее про [содержание документации](/ru/docs/contribute/style/content-guide) + +{{% /capture %}} diff --git a/content/ru/docs/contribute/style/hugo-shortcodes/example1.md b/content/ru/docs/contribute/style/hugo-shortcodes/example1.md new file mode 100644 index 0000000000..30ffcf0235 --- /dev/null +++ b/content/ru/docs/contribute/style/hugo-shortcodes/example1.md @@ -0,0 +1,9 @@ +--- +title: Пример #1 +--- + +Это **пример** содержимого в файле внутри пакета узла **includes**. + +{{< note >}} +Подключаемые файлы также могут содержать макрокоды. +{{< /note >}} \ No newline at end of file diff --git a/content/ru/docs/contribute/style/hugo-shortcodes/example2.md b/content/ru/docs/contribute/style/hugo-shortcodes/example2.md new file mode 100644 index 0000000000..68a9730617 --- /dev/null +++ b/content/ru/docs/contribute/style/hugo-shortcodes/example2.md @@ -0,0 +1,7 @@ +--- +title: Пример #1 +--- + +Это другой **пример** содержимого в файле внутри пакета узла **includes**. + + diff --git a/content/ru/docs/contribute/style/hugo-shortcodes/index.md b/content/ru/docs/contribute/style/hugo-shortcodes/index.md new file mode 100644 index 0000000000..b77cc77ec1 --- /dev/null +++ b/content/ru/docs/contribute/style/hugo-shortcodes/index.md @@ -0,0 +1,245 @@ +--- +approvers: +- chenopis +title: Пользовательские макрокоды Hugo +content_template: templates/concept +--- + +{{% capture overview %}} +На этой странице объясняются пользовательские макрокоды Hugo, которые можно использовать в Markdown-файлах документации Kubernetes. + +Узнать подробнее про макрокоды можно в [документации Hugo](https://gohugo.io/content-management/shortcodes). +{{% /capture %}} + +{{% capture body %}} + +## Состояние функциональности + +В Markdown странице (файл с расширением `.md`) вы можете добавить макрокод, чтобы отобразить версию и состояние документированной функциональной возможности. + +### Демонстрация состояния функциональности + +Ниже показан фрагмент кода для вывода состояния функциональности, который сообщает о функциональности в стабильной версии Kubernetes 1.10. + +``` +{{}} +``` + +Результат: + +{{< feature-state for_k8s_version="v1.10" state="stable" >}} + +Допустимые значения для `state`: + +* alpha +* beta +* deprecated +* stable + +### Код состояния функциональности + +По умолчанию отображается версия Kubernetes, соответствующая версии страницы или сайта. Это значение можно переопределить, передав параметр макрокода for_k8s_version. + +``` +{{}} +``` + +Результат: + +{{< feature-state for_k8s_version="v1.10" state="stable" >}} + +#### Функциональность в альфа-версии + +``` +{{}} +``` + +Результат: + +{{< feature-state state="alpha" >}} + +#### Функциональность в бета-версии + +``` +{{}} +``` + +Результат: + +{{< feature-state state="beta" >}} + +#### Функциональность в стабильной версии + +``` +{{}} +``` + +Результат: + +{{< feature-state state="stable" >}} + +#### Устаревшая функциональность + +``` +{{}} +``` + +Результат: + +{{< feature-state state="deprecated" >}} + +## Глоссарий + +Вы можете сослаться на термины из [глоссария](/docs/reference/glossary/) в виде всплывающей (при наведении мыши) подсказки, что удобно при чтении документации через интернет. + +Исходные файлы терминов глоссария хранятся в отдельной директории по URL-адресу [https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary). + +### Демонстрация глоссария + +Например, следующий фрагмент кода в Markdown будет отображен в виде всплывающей подсказки — {{< glossary_tooltip text="cluster" term_id="cluster" >}}: + +```liquid +{{}} +``` + +## Заголовки таблиц + +Для улучшения доступности таблиц для программ для чтения с экрана, добавьте заголовок к таблице. Чтобы добавить [заголовок](https://www.w3schools.com/tags/tag_caption.asp) таблицы, поместите таблицу в макрокод `table` и определите значение заголовка в параметре` caption`. + +{{< note >}} +Заголовки таблиц предназначены только для программ чтения с экрана, поэтому в браузере они не будут отображаться. +{{< /note >}} + +Пример: + +```go-html-template +{{}} +Параметр | Описание | Значение по умолчанию +:---------|:------------|:------- +`timeout` | Тайм-аут для запросов | `30s` +`logLevel` | Уровень логирования | `INFO` +{{< /table */>}} +``` + +Результат: + +{{}} +Параметр | Описание | Значение по умолчанию +:---------|:------------|:------- +`timeout` | Тайм-аут для запросов | `30s` +`logLevel` | Уровень логирования | `INFO` +{{< /table >}} + +Если вы изучите HTML-код таблицы, вы заметите следующий ниже элемент сразу после открывающего элемента ``: + +```html + +``` + +## Вкладки + +Страница в формате Markdown (файл с расширением `.md`) на этом сайте может содержать набор вкладок для отображения нескольких разновидностей определённого решения. + +Макрокод `tabs` принимает следующие параметры: + +* `name`: имя, отображаемое на вкладке. +* `codelang`: если вы указываете встроенный контент для макрокода `tab`, вы можете сообщить Hugo, какой язык использовать для подсветки синтаксиса. +* `include`: включаемый файл в вкладку. Если вкладка находится в [узле пакета (leaf bundle)](https://gohugo.io/content-management/page-bundles/#leaf-bundles) Hugo, то файл (может быть любым MIME-типом, который поддерживает Hugo) ищется в самом пакете. Если нет, то включаемое содержимое ищется относительно текущей страницы. Обратите внимание, что при использовании `include` вам следует использовать самозакрывающийся синтаксис. Например, {{}}. Язык может быть указан в `codelang`, в противном случае язык определяется из имени файла. +* Если содержимое вкладки это Markdown, вам нужно использовать символ `%`. Например, `{{%/* tab name="Вкладка 1" %}}This is **markdown**{{% /tab */%}}` +* Вы можете совместно использовать перечисленные выше параметры. +Ниже приведена демонстрация шорткода вкладок. + +Ниже приведены примеры вкладок. + +{{< note >}} +**Имя** вкладки в элементе `tabs` должно быть уникальным на странице. +{{< /note >}} + +### Демонстрация вкладок: подсветка синтаксиса в блоках кода + +```go-text-template +{{}} +{{{< tab name="Вкладка 1" codelang="bash" >}} +echo "Это вкладка 1." +{{< /tab >}} +{{< tab name="Вкладка 2" codelang="go" >}} +println "Это вкладка 2." +{{< /tab >}}} +{{< /tabs */>}} +``` + +Результат: + +{{< tabs name="tab_with_code" >}} +{{< tab name="Вкладка 1" codelang="bash" >}} +echo "Это вкладка 1." +{{< /tab >}} +{{< tab name="Вкладка 2" codelang="go" >}} +println "Это вкладка 2." +{{< /tab >}} +{{< /tabs >}} + +### Демонстрация вкладок: встроенный Markdown и HTML + +```go-html-template +{{}} +{{% tab name="Markdown" %}} +Это **разметка Markdown.** +{{< note >}} +Также можно использовать макрокоды. +{{< /note >}} +{{% /tab %}} +{{< tab name="HTML" >}} +
+

Обычный HTML

+

Это обычный HTML.

+
+{{< /tab >}} +{{< /tabs */>}} +``` + +Результат: + +{{< tabs name="tab_with_md" >}} +{{% tab name="Markdown" %}} +Это **разметка Markdown.** + +{{< note >}} +Также можно использовать макрокоды. +{{< /note >}} + +{{% /tab %}} +{{< tab name="HTML" >}} +
+

Обычный HTML

+

Это обычный HTML.

+
+{{< /tab >}} +{{< /tabs >}} + +### Демонстрация вкладок: включение файлов + +```go-text-template +{{}} +{{< tab name="Content File #1" include="example1" />}} +{{< tab name="Content File #2" include="example2" />}} +{{< tab name="JSON File" include="podtemplate" />}} +{{< /tabs */>}} +``` + +Результат: + +{{< tabs name="tab_with_file_include" >}} +{{< tab name="Content File #1" include="example1" />}} +{{< tab name="Content File #2" include="example2" />}} +{{< tab name="JSON File" include="podtemplate" />}} +{{< /tabs >}} + +{{% /capture %}} + +{{% capture whatsnext %}} +* Подробнее про [Hugo](https://gohugo.io/). +* Подробнее про [написание новой темы](/ru/docs/contribute/style/write-new-topic/). +* Подробнее про [использование шаблонов страниц](/ru/docs/contribute/style/page-templates/). +* Подробнее про [создание пулреквеста](/ru/docs/contribute/start/#отправка-пулреквеста). +{{% /capture %}} \ No newline at end of file diff --git a/content/ru/docs/contribute/style/hugo-shortcodes/podtemplate.json b/content/ru/docs/contribute/style/hugo-shortcodes/podtemplate.json new file mode 100644 index 0000000000..bd4327414a --- /dev/null +++ b/content/ru/docs/contribute/style/hugo-shortcodes/podtemplate.json @@ -0,0 +1,22 @@ + { + "apiVersion": "v1", + "kind": "PodTemplate", + "metadata": { + "name": "nginx" + }, + "template": { + "metadata": { + "labels": { + "name": "nginx" + }, + "generateName": "nginx-" + }, + "spec": { + "containers": [{ + "name": "nginx", + "image": "dockerfile/nginx", + "ports": [{"containerPort": 80}] + }] + } + } + } diff --git a/content/ru/docs/contribute/style/page-templates.md b/content/ru/docs/contribute/style/page-templates.md new file mode 100644 index 0000000000..f49307b414 --- /dev/null +++ b/content/ru/docs/contribute/style/page-templates.md @@ -0,0 +1,186 @@ +--- +title: Использование шаблонов страниц +content_template: templates/concept +weight: 30 +card: + name: contribute + weight: 30 +--- + +{{% capture overview %}} +При добавлении новых тем воспользуйтесь одним из перечисленных ниже шаблонов. +Это регламентирует пользовательское восприятие определённой страницы. + +Шаблоны страниц находятся в директории [`layouts/partials/templates`](https://git.k8s.io/website/layouts/partials/templates) репозитория [`kubernetes/website`](https://github.com/kubernetes/website). + +{{< note >}} +Каждая новая тема должна использовать шаблон. Если вы не уверены, какой шаблон использовать для новой темы, начните с [шаблона концепции](#шаблон-концепции). +{{< /note >}} + +{{% /capture %}} + + +{{% capture body %}} + +## Шаблон концепции + +Страница концепции объясняет некоторые аспекты Kubernetes. Например, страницы концепции может описывать объект Deployment в Kubernetes и разъяснить какую роль он играет после развертывания, масштабирования и обновления приложения. Как правило, страницы концепций не включают последовательности шагов, и вместо этого содержат ссылки на задачи или руководства. + +Для написания новой страницы концепции в директории `/content/en/docs/concepts` создайте поддиректорию с Markdown-файлом со следующим требованиями: + +- Во фронтальной части YAML этой страницы определите поле `content_template: templates/concept`. +- В теле страницы укажите переменные `capture` и любые другие, которые вы хотите включить: + + | Переменная | Обязательна? | + |------------|--------------| + | overview | да | + | body | да | + | whatsnext | нет | + + + Тело страницы будет выглядеть следующим образом (удалите все необязательные capture-блоки, если они вам не понадобятся): + + ``` + {{%/* capture overview */%}} + + {{%/* /capture */%}} + + {{%/* capture body */%}} + + {{%/* /capture */%}} + + {{%/* capture whatsnext */%}} + + {{%/* /capture */%}} + ``` + +- Заполните каждый раздел информацией. Следуйте этим рекомендациям: + - Структурируйте контент с помощью заголовков H2 и H3. + - В блоке `overview` одним абзацем сформируйте контекст темы. + - В блоке `body` объясните суть концепции. + - В блоке `whatsnext` сформируйте ненумерованный список тем (до 5), к которым нужно обратиться, чтобы получить дополнительную информацию о концепции. + +[Annotations](/docs/concepts/overview/working-with-objects/annotations/) — это готовый пример шаблона концепции. Кстати, текущая страница использует шаблон концепции. + +## Шаблон задачи + +На странице задачи показывается, как сделать что-то одно конкретное, главным образом с помощью короткой последовательности шагов. В страницах задач очень короткое объяснение, хотя они часто ссылаются на концептуальные темы, где уже можно найти соответствующую справочную информацию и ресурсы. + +Для написания новой страницы задачи в директории `/content/en/docs/tasks` создайте поддиректорию с Markdown-файлом со следующим требованиями: + +- Во фронтальной части YAML этой страницы определите поле `content_template: templates/task`. +- В теле страницы укажите переменные `capture` и любые другие, которые вы хотите включить: + + | Переменная | Обязательна? | + |------------|--------------| + | overview | да | + | prerequisites | да | + | steps | нет | + | discussion | нет | + | whatsnext | нет | + + + Тело страницы будет выглядеть следующим образом (удалите все необязательные capture-блоки, если они вам не нужны): + + ``` + {{%/* capture overview */%}} + + {{%/* /capture */%}} + + {{%/* capture prerequisites */%}} + + {{}} {{}} + + {{%/* /capture */%}} + + {{%/* capture steps */%}} + + {{%/* /capture */%}} + + {{%/* capture discussion */%}} + + {{%/* /capture */%}} + + {{%/* capture whatsnext */%}} + + {{%/* /capture */%}} + ``` + +- Заполните каждый блок информацией. Следуйте этим рекомендациям: + - Используйте по минимуму заголовков H2 (с двумя ведущими символами `#`). У самих разделов заголовок формируется автоматически по заданному шаблону. + - В блоке `overview` обозначьте контекст для всей темы. + - В блоке `prerequisites` используйте ненумерованные списки, где это возможно. Добавьте дополнительные предварительные условия ниже `include`. Предварительные условия по умолчанию содержат пункт про наличие работающего кластера. + - В блоке `steps` используйте нумерованные списки. + - В блоке `discussion` подробно распишите информацию, описанную в разделе `steps`. + - В блоке `whatsnext` сформируйте ненумерованный список тем (до 5), которые могут быть интересны читателю в качестве дополнительного чтения. + +Пример готовой темы, в которой используется шаблон задачи — [Using an HTTP proxy to access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api). + +## Шаблон руководства + +На странице руководства показывается, как выполнить что-то более крупнее одной-единственной задачи. Как правило, страницы руководства поделена на несколько разделов, в каждом из которых есть последовательность шагов. Например, руководство может включать анализ примера кода, демонстрирующий определенную возможность Kubernetes. Руководства могут содержать поверхностные объяснения и одновременно включать ссылки на соответствующие концептуальные темы для получения углубленных знаний. + +Для написания новой страницы задачи в директории `/content/en/docs/tutorials` создайте поддиректорию с Markdown-файлом со следующим требованиями: + +- Во фронтальной части YAML этой страницы определите поле `content_template: templates/tutorial`. +- В теле страницы укажите переменные `capture` и любые другие, которые вы хотите включить: + + | Переменная | Обязательна? | + |------------|--------------| + | overview | да | + | prerequisites | да | + | objectives | да | + | lessoncontent | да | + | cleanup | нет | + | whatsnext | нет | + + Тело страницы будет выглядеть следующим образом (удалите все необязательные capture-блоки, если они вам не понадобятся): + + ``` + {{%/* capture overview */%}} + + {{%/* /capture */%}} + + {{%/* capture prerequisites */%}} + + {{}} {{}} + + {{%/* /capture */%}} + + {{%/* capture objectives */%}} + + {{%/* /capture */%}} + + {{%/* capture lessoncontent */%}} + + {{%/* /capture */%}} + + {{%/* capture cleanup */%}} + + {{%/* /capture */%}} + + {{%/* capture whatsnext */%}} + + {{%/* /capture */%}} + ``` + +- Заполните каждый блок информацией. Следуйте этим рекомендациям: + - Используйте по минимуму заголовков H2 (с двумя ведущими символами `#`). У самих разделов заголовок формируется автоматически по заданному шаблону. + - В блоке `overview` обозначьте контекст для всей темы. + - В блоке `prerequisites` используйте ненумерованные списки, где это возможно. Добавьте дополнительные предварительные условия ниже `include`. Предварительные условия по умолчанию содержат пункт про наличие работающего кластера. + - В блоке `objectives` используйте ненумерованные списки. + - В блоке `lessoncontent` целесообразно используйте совместно нумерованные списки и повествовательное содержание. + - В блоке `cleanup` используйте нумерованные списки для описания шагов для очистки состояния кластера после выполнения задачи. + - В блоке `whatsnext` сформируйте ненумерованный список тем (до 5), которые могут быть интересны читателю в качестве дополнительного чтения. + +Пример завершенной темы, в которой используется шаблон руководства — [Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/). + +{{% /capture %}} + +{{% capture whatsnext %}} + +- Подробнее про [оформление документации](/ru/docs/contribute/style/style-guide/) +- Подробнее про [содержание документации](/ru/docs/contribute/style/content-guide/) +- Подробнее про [организацию контента](/ru/docs/contribute/style/content-organization/) + +{{% /capture %}} diff --git a/content/ru/docs/contribute/style/style-guide.md b/content/ru/docs/contribute/style/style-guide.md new file mode 100644 index 0000000000..612111c673 --- /dev/null +++ b/content/ru/docs/contribute/style/style-guide.md @@ -0,0 +1,570 @@ +--- +title: Руководство по оформлению документации +linktitle: Руководство по оформлению +content_template: templates/concept +weight: 10 +card: + name: contribute + weight: 20 + title: Руководство по оформлению документации +--- + +{{% capture overview %}} +На этой странице вы найдёте рекомендации по оформлению написания документации Kubernetes. Это рекомендации, а не правила. Используйте здравый смысл и не стесняйтесь предлагать изменения в этот документ в виде пулреквеста. + +Для получения подробной информации о создании нового контента в документацию Kubernetes посмотрите [руководство по контенту документации](/ru/docs/contribute/style/content-guide/), а также следуйте инструкциям по [использованию шаблонов страниц](/ru/docs/contribute/style/page-templates/) и [открытию пулревеста в документацию](/ru/docs/contribute/start/#улучшение-существующего-текста). + +{{% /capture %}} + +{{% capture body %}} + +{{< note >}} +В документации Kubernetes используется [Blackfriday Markdown Renderer](https://github.com/russross/blackfriday) вместе с несколькими [макрокодами Hugo](/docs/home/contribute/includes/) для добавления поддержки записей глоссария, вкладок и отображения состояний функциональностей. +{{< /note >}} + +## Язык + +Документация Kubernetes была переведена на несколько языков (см. [README-файлы локализаций](https://github.com/kubernetes/website/blob/master/README.md#localization-readmemds)). + +Процесс локализации документации на другие языки описан в [соответствующей странице по локализации](/ru/docs/contribute/localization/). + +## Правила форматирования документации + +### Используйте верблюжью нотацию для написания объектов API + +Когда вы указываете имя API-объекта, используйте те же самые прописные и строчные буквы так, как они записаны в имени объекта. Как правило, имена объектов API написаны с использованием [верблюжьей нотации](https://ru.wikipedia.org/wiki/Camel_case). + +Не разделяйте имя объекта API на отдельные слова. Например, пишите PodTemplateList, а не Pod Template List. + +Указывая имена API-объектов, не добавляйте к ним слово "объект", за исключением случаев, когда это только ухудшает читаемость. + +{{< table caption = "Можно делать и нельзя - Объекты API" >}} +Можно | Нельзя +:--| :----- +В Pod два контейнера. | В поде два контейнера. +Deployment отвечает за ... | Объект Deployment отвечает за ... +PodList — это список Pod. | Pod List — это список подов. +Два ContainerPorts ... | Два объекта ContainerPort ... +Два объекта ContainerStateTerminated ... | Два ContainerStateTerminated ... +{{< /table >}} + + +### Используйте угловые скобки для заполнителей + +Используйте угловые скобки для заполнителей. Сообщите читателю, что означает заполнитель. + +1. Отобразить информацию о Pod: + + kubectl describe pod -n + + Если пространство имён пода равняется `default`, вы можете опустить параметр '-n'. + +### Используйте полужирное начертание для элементов пользовательского интерфейса + +{{< table caption = "Можно делать и нельзя - Элементы интерфейса в полужирном начертании" >}} +Можно | Нельзя +:--| :----- +Нажмите на **Fork**. | Нажмите на "Fork". +Выберите **Other**. | Выберите "Other". +{{< /table >}} + +### Используйте курсивное начертание для определения или включения новых терминов + +{{< table caption = "Можно делать и нельзя - Используйте курсивное начертание для новых терминов" >}} +Можно | Нельзя +:--| :----- +_Кластер_ — это набор узлов ... | "Кластер" — это набор узлов ... +Эти компоненты формируют _панель управления_. | Эти компоненты формируют **панель управления**. +{{< /table >}} + +### Оформляйте как код имена файлов, директории и пути + +{{< table caption = "Можно делать и нельзя - Оформляйте как код имена файлов, директории и пути" >}} +Можно | Нельзя +:--| :----- +Откройте файл `envars.yaml`. | Откройте файл envars.yaml. +Перейдите в директорию `/docs/tutorials`. | Перейдите в директорию /docs/tutorials. +Откройте файл `/_data/concepts.yaml` file. | Откройте файл /_data/concepts.yaml. +{{< /table >}} + +### Используйте международные правила для пунктуации внутри кавычек + +{{< table caption = "Можно делать и нельзя - Используйте международные правила для пунктуации внутри кавычек" >}} +Можно | Нельзя +:--| :----- +события записываются с соответствующей "стадией". | события записываются с соответствующей "стадией." +Копия называется "fork". | Копия называется "fork." +{{< /table >}} + +## Форматирование с использованием однострочного кода + +### Используйте оформление кода для встроенного кода и команд + +Для однострочного (встроенного) блока кода в HTML-документе используйте тег ``. В файле Markdown используйте обратную кавычку (`). + +{{< table caption = "Можно делать и нельзя - Use code style for inline code and commands" >}} +Можно | Нельзя +:--| :----- +Команда `kubectl run` создает Deployment. | Команда "kubectl run" создает Deployment. +Для декларативного управления используйте `kubectl apply`. | Для декларативного управления используйте "kubectl apply". +Заключите примеры кода в тройные обратные кавычки. `(```)` | Заключите примеры кода с использованием любого другого синтаксиса. +Используйте одинарные обратные кавычки для выделения встроенного кода. Например, `var example = true`. | Используйте две звездочки (**) или подчёркивание (_) для выделения встроенного кода. Например, **var example = true**. +Используйте тройные обратные кавычки до и после многострочного блока кода для отдельных блоков кода. | Используйте многострочные блоки кода для создания диаграмм, блок-схем или т.д. +Используйте понятные имена переменных с соответствующим контекстом. | Используйте имена переменных, такие как 'foo', 'bar' и 'baz', которые не имеют смысла и которым не хватает контекста. +Удаляйте завершающие пробелы в коде. | Добавляйте конечные пробелы в код там, где они необходимо, поскольку программа для чтения с экрана также будет зачитывать пробелы. +{{< /table >}} + +{{< note >}} +На сайте включена подсветка синтаксиса для примеров кода, хотя указывать язык необязательно. Подсветка синтаксиса в блоке кода должна соответствовать [рекомендациям по контрастности](https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0&showtechniques=141%2C143#contrast-minimum). +{{< /note >}} + +### Имена полей объектов и пространства имён оформляйте как код + +{{< table caption = "Можно делать и нельзя - Имена полей объектов и пространства имён оформляйте как код" >}} +Можно | Нельзя +:--| :----- +Задайте значение для поля `replicas` в конфигурационном файле. | Задайте значение для поля "replicas" в конфигурационном файле. +Значением поля `exec` является объект ExecAction. | Значением поля "exec" является объект ExecAction. +Запустите процесс как Daemonset в пространстве имен `kube-system`. | Запустите процесс как Daemonset в пространстве имен kube-system. +{{< /table >}} + +### Имена компонентов и командного инструмента оформляйте как код + +{{< table caption = "Можно делать и нельзя - Имена компонентов и командного инструмента оформляйте как код" >}} +Можно | Нельзя +:--| :----- +kubelet сохраняет стабильность узла. | `kubelet` сохраняет стабильность узла. +`kubectl` обрабатывает поиск и аутентификацию на сервере API. | kubectl обрабатывает поиск и аутентификацию на apiserver. +Запустите процесс с использованием сертификата `kube-apiserver --client-ca-file=FILENAME`. | Запустите процесс с использованием сертификата kube-apiserver --client-ca-file=FILENAME. +{{< /table >}} + +### Начинайте предложение с имени инструмента или компонента + +{{< table caption = "Можно делать и нельзя - Начинайте предложение с имени инструмента или компонента" >}} +Можно | Нельзя +:--| :----- +The `kubeadm` tool bootstraps and provisions machines in a cluster. | `kubeadm` tool bootstraps and provisions machines in a cluster. +The kube-scheduler is the default scheduler for Kubernetes. | kube-scheduler is the default scheduler for Kubernetes. +{{< /table >}} + +### Используйте общее описание вместо имени компонента + +{{< table caption = "Можно делать и нельзя - Используйте общее описание вместо имени компонента" >}} +Можно | Нельзя +:--| :----- +Сервер Kubernetes API следует спецификации OpenAPI. | apiserver следует спецификации OpenAPI. +Агрегированные API-интерфейсы — вспомогательные API-серверы. | Агрегированные API-интерфейсы — вспомогательные APIServers. +{{< /table >}} + +### Cтроковые и целочисленные значения полей пишите в обычном стиле + +Для значений полей типа string или integer используйте обычный стиль без кавычек. + +{{< table caption = "Можно делать и нельзя - Cтроковые и целочисленные значения полей пишите в обычном стиле" >}} +Можно | Нельзя +:--| :----- +Задайте значение для поля `imagePullPolicy` как Always. | Задайте значение для поля `imagePullPolicy` как "Always". +Задайте значение для поля `image` как nginx:1.8. | Задайте значение для поля`image` как `nginx:1.8`. +Задайте значение для поля `replicas` как 2. | Задайте значение для поля `replicas` как `2`. +{{< /table >}} + + +## Форматирование фрагментов кода + +### Не добавляйте символ приглашения командной строки + +{{< table caption = "Можно делать и нельзя - Не добавляйте символ приглашения командной строки" >}} +Можно | Нельзя +:--| :----- +kubectl get pods | $ kubectl get pods +{{< /table >}} + + +### Отделяйте команды от вывода + +Убедитесь, что Pod работает на выбранном вами узле: + + kubectl get pods --output=wide + +Вывод будет примерно таким: + + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 + +### Версионирование примеров Kubernetes + +Примеры кода и примеры конфигурации, которые включают информацию о версии, должны согласовываться с относящемуся к нему тексту. + +Если информация зависит от версии, необходимо определить версию Kubernetes в секции `prerequisites` [шаблона задачи](/ru/docs/contribute/style/page-templates/#шаблон-задачи) или [шаблона руководства](/ru/docs/contribute/style/page-templates/#шаблон-руководства). После сохранения страницы секция `prerequisites` отобразится в отдельном блоке с заголовком **Подготовка к работе**. + +Для указания версии Kubernetes для страницы задачи или руководства в фронтальную часть файла добавьте поле `min-kubernetes-server-version`. + +Если YAML-пример определён в отдельном файле, поищите и просмотрите темы, которые ссылаются на него. +Убедитесь, что темы с подключённым YAML-файлом содержат соответствующую информацию о версии. +Если ни одна из тем не использует какой-либо YAML-файл подумайте над тем, чтобы удалить его вместо того, чтобы обновления. + +Например, если вы пишете руководство, предназначенное для использования с версией Kubernetes 1.8, фронтальная часть вашего Markdown-файла должен выглядеть примерно так: + +```yaml +--- +title: +min-kubernetes-server-version: v1.8 +--- +``` + +В примерах кода и конфигурации не добавляйте комментарии про альтернативные версии. +Убедитесь в том, чтобы в комментариях ваших примеров не содержались некорректные сведения, такие как ниже: + +```yaml +apiVersion: v1 # в более ранних версиях... +kind: Pod +... +``` + +## Словарь Kubernetes.io + +Список специфичных для Kubernetes терминов и слов, которые будут регулярно встречаться по всему сайту. + +{{< table caption = "Словарь Kubernetes.io" >}} +Термин | Пример использования +:--- | :---- +Kubernetes | Kubernetes всегда должен начинаться с заглавной буквы. +Docker | Docker всегда должен начинаться с заглавной буквы. +SIG Docs | SIG Docs, а не SIG-DOCS или другие варианты. +On-premises | On-premises or On-prem rather than On-premise or other variations. +{{< /table >}} + +## Макрокоды + +[Макрокоды Hugo](https://gohugo.io/content-management/shortcodes) помогают создавать разного рода обращений к читателю. Наша документация поддерживает три разных макрокода для этого: **примечание** {{}}, **предостережение** {{}} и **предупреждение** {{}}. + +1. Заключите текст в открывающий и закрывающий макрокод. + +2. Используйте следующий синтаксис для определения стиля: + + ``` + {{}} + Вам не нужно указывать надпись; макрокод автоматически добавит её. (Примечание:, Предостережение:, и т.д.) + {{}} + ``` + +Результат: + +{{< note >}} +Надпись блока будет такой же, как и имя тега. +{{< /note >}} + +### Примечание + +Используйте {{}} для выделения подсказки или части информации, которая может быть полезна для ознакомления. + +Например: + +``` +{{}} +Вы _также_ можете использовать Markdown внутри этих выносок. +{{}} +``` + +Результат: + +{{< note >}} +Вы _также_ можете использовать Markdown внутри этих выносок. +{{< /note >}} + +Вы можете использовать {{}} в списке: + +``` +1. Используйте макрокод примечания в списке + +1. Второй пункт с добавленным блоком примечания + + {{}} + Макрокоды предупреждения, предостережения и примечания, добавленные в списки, должны содержать отступ в четыре пробела. Смотрите раздел [Распространённые проблемы с шорткодами](#распространённые-проблемы-с-шорткодами). + {{}} + +1. Третий пункт в списке + +1. Четвертый пункт в списке +``` + +Результат: + +1. Используйте макрокод примечания в списке + +1. Второй пункт с добавленным блоком примечания + + {{< note >}} + Макрокоды предупреждения, предостережения и примечания, добавленные в списки, должны содержать отступ в четыре пробела. Смотрите раздел [Распространённые проблемы с шорткодами](#распространённые-проблемы-с-шорткодами). + {{< /note >}} + +1. Третий пункт в списке + +1. Четвертый пункт в списке + +### Предостережение + +Используйте {{}}, чтобы обратить внимание к важной информации, которая поможет избежать подводных камней. + +Например: + +``` +{{}} +Оформление выноски применяется только к строке, следующей после тега выше. +{{}} +``` + +Результат: + +{{< caution >}} +Оформление выноски применяется только к строке, следующей после тега выше. +{{< /caution >}} + +### Предупреждение + +Используйте {{}} для обозначения предупреждающей информации или такой, которую чрезвычайно важно соблюдать. + +Например: + +``` +{{}} +Острожно. +{{}} +``` + +Результат: + +{{< warning >}} +Острожно. +{{< /warning >}} + +### Встраиваемая среда выполнения Katacoda + +С помощью этой кнопки пользователи могут запустить Minikube в своём браузере с помощью [терминала Katacoda](https://www.katacoda.com/embed/panel). +Таким образом снижается порог входа, позволяя пользователям попробовать Minikube с помощью одного щелчка мыши, вместо того, чтобы устанавливать Minikube и Kubectl локально. + +Встроенная среда выполнения сконфигурирована для выполнения команды `minikube start` и позволяет пользователям пройти руководство в той же самой вкладке, что и документация. + +{{< caution >}} +Сессия ограничена 15 минутами. +{{< /caution >}} + +Например: + +``` +{{}} +``` + +Результат: + +{{< kat-button >}} + +## Распространённые проблемы с шорткодами + +### Упорядоченные списки + +Макрокоды сбросят нумерацию в нумерованных списках, если вы не добавите отступ в четыре пробела перед уведомлением и тегом. + +Например: + + 1. Разогреть духовку до 350˚F + + 1. Подготовить тесто и вылить её в формочку для выпечки. + {{}}Для лучшего результата смажьте формочку.{{}} + + 1. Выпекать 20-25 minutes или пока тесто не зарумянится. + +Результат: + +1. Разогреть духовку до 350˚F + +1. Подготовить тесто и вылить её в формочку для выпечки. + + {{< note >}}Для лучшего результата смажьте формочку.{{< /note >}} + +1. Выпекать 20-25 minutes или пока тесто не зарумянится. + +### Выражения для вставок + +Макрокоды внутри include-выражений нарушит процесс сборки. Поэтому они должны быть вставлены в родительский документ до и после вызова include. Например: + +``` +{{}} +{{}} +{{}} +``` + + +## Элементы Markdown + +### Переносы строк +Добавляйте одну новую строку для разделения содержимого таких блоков, как заголовки, списки, изображения, многострочный код и т.д. Исключение составляют заголовки второго уровня, которые должны быть разделены двумя переводами строки. Заголовки второго уровня следуют за первым уровнем (или названием страницы). Две пустые строки помогает лучше наглядно представить общую структуру содержимого в редакторе кода. + +### Заголовки +Люди, просматривающие документацию, могут использовать программу чтения с экрана или другую вспомогательную технологию (Assistive technologies, AT). [Программы чтения с экрана](https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%80%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D1%81%D1%87%D0%B8%D1%82%D1%8B%D0%B2%D0%B0%D1%8E%D1%89%D0%B5%D0%B5_%D1%83%D1%81%D1%82%D1%80%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%BE) — устройства вывода, которые выводят элементы на странице по очереди. Если на странице много текста, вы можете использовать заголовки, чтобы придать странице внутреннюю структуру. Хорошая структура страницы помогает всем читателям легко перемещаться по странице или выбрать интересующие темы. + +{{< table caption = "Можно делать и нельзя - Заголовки" >}} +Можно | Нельзя +:--| :----- +Обновите заголовок в фронтальной части страницы или записи блога. | Используйте заголовок первого уровня, так как Hugo автоматически преобразует название страницы в фронтальной части в заголовок первого уровня. +Используйте упорядоченные заголовки, чтобы сформировать общее представление о содержании страницы. | Используйте заголовки с уровня 4 по 6, если только это только в этом нет необходимости. Если текст настолько подробный, возможно, его нужно разделить на отдельные статьи. +Используйте знак решётки или хеша (#) для всех видов контента, кроме записей блога. | Используйте подчеркивание (--- или ===) для обозначения заголовков первого уровня. +Начинайте с большой буквы только первое слово в заголовке. Например, **Расширение kubectl с помощью плагинов** | Пишите с заглавной буквы все слова в заголовке. Например, **Расширение Kubectl С Помощью Плагинов** +{{< /table >}} + +### Параграфы + +{{< table caption = "Можно делать и нельзя - Параграфы" >}} +Можно | Нельзя +:--| :----- +Проследите за тем, чтобы в одном абзаце было не более 6 предложений. | Добавить к первом абзацу отступ с пробелами. Например, ⋅⋅⋅Три пробела перед абзацем образуют отступ. +Используйте три дефиса (---) для создания горизонтальной черты. Используйте горизонтальные линии для обозначения конца в содержании абзаца. Например, смена места в истории или переход темы в разделе. | Используйте горизонтальные линии для оформления. +{{< /table >}} + +### Ссылки + +{{< table caption = "Можно делать и нельзя - Ссылки" >}} +Можно | Нельзя +:--| :----- +Указывайте ссылки, которые передают суть содержания, на который они ссылаются. Например: "Некоторые порты открыты на ваших машинах. Смотрите раздел Проверка необходимых портов, чтобы получить дополнительную информацию". | Используйте двусмысленные термины, такие как "нажмите сюда". Например: Некоторые порты открыты на ваших машинах. Смотрите этот раздел, чтобы получить дополнительную информацию". +Указывайте ссылки в стиле Markdown: `[текст ссылки](URL)`. Например: `[Макрокоды Hugo](/docs/contribute/style/hugo-shortcodes/#table-captions)` отобразится как [Макрокоды Hugo](/docs/contribute/style/hugo-shortcodes/#table-captions). | Указывайте ссылки в формате HTML: `Ознакомьтесь с нашим руководством!` или добавляйте ссылки, которые открываются в новых вкладках или окнах. Например: `[example website](https://example.com){target="_blank"}` +{{< /table >}} + + +### Списки +Сгруппируйте пункты в списке так, чтобы они были связаны друг с другом и следовали в определённом порядке, либо чтобы они сохраняли взаимосвязь между несколькими элементами. Когда программа чтения с экрана встречает нумерованный или неупорядоченный список, пользователю будет проинформирован, что существует группа из элементов списка. Затем пользователь может использовать клавиши-стрелки для перемещения между разными элементами в списке. +Навигационные ссылки по сайту также могут быть помечены как элементы списка; в конечном счёте, все они просто группа связанных ссылок. + + - Заканчивайте каждый элемент в списке точкой, если один или несколько элементов в списке являются законченными предложениями. Как правило, для согласованности либо все элементы должны быть целыми предложениями, либо ни один из них. + + {{< note >}} Упорядоченные списки, которые являются частью неполного вступительного предложения, могут быть написаны в нижнем регистре и оканчиваться на точку, как если бы каждый элемент был составляющей вступительного предложения.{{< /note >}} + + - Используйте цифру один (1.) для упорядоченных списков. + + - Используйте (+), (*) или (-) для неупорядоченных списков. + + - Добавьте пустую строку после каждого списка. + + - Во вложенных списках добавьте отступ в четыре пробела (например, ⋅⋅⋅⋅). + + - Элементы списка могут содержать несколько абзацев. Каждый последующий абзац в элементе списка должен иметь отступ в четыре пробела или один символ табуляции. + +### Таблицы + +Семантическая цель таблицы данных состоит в представлении данных в табличном виде. Пользователи с нормальным зрением могут бегло просмотреть таблицу, однако программа для чтения с экрана сканирует таблицу построчно. Заголовок таблицы используется для создания информативного заголовка для табличных данных. Инструменты вспомогательных технологий (Assistive technologies, AT) используют элемент заголовка HTML-таблицы, чтобы идентифицировать для пользователей, какие на странице есть таблицы. + +- Добавьте подписи к таблицам с помощью соответствующих [макрокодов Hugo](/docs/contribute/style/hugo-shortcodes/#table-captions). + +## Рекомендации по написанию контента + +В этом разделе перечислены рекомендации для написания ясного, лаконичного и единообразного текста документации. + +### Используйте настоящее время + +{{< table caption = "Можно делать и нельзя - Используйте настоящее время" >}} +Можно | Нельзя +:--| :----- +Эта команда запускает прокси. | Эта команда запустит прокси. + {{< /table >}} + +Исключение: используйте будущее или прошедшее время, если требуется передать правильный смысл. + +### Используйте действительный залог + +{{< table caption = "Можно делать и нельзя - Используйте действительный залог" >}} +Можно | Нельзя +:--| :----- +Вы можете изучить API с помощью браузера. | API можно изучить с помощью браузера. +В файле YAML определяется количество реплик. | Количество реплик определяется в файле YAML. +{{< /table >}} + +Исключение: используйте страдательный залог, если в действительном залоге получается неудачная формулировка. + +### Используйте простой и понятный язык + +Используйте простой и доступный язык. Избегайте использования ненужных фраз, например, "пожалуйста". + +{{< table caption = "Можно делать и нельзя - Используйте простой и понятный язык" >}} +Можно | Нельзя +:--| :----- +Чтобы создать ReplicaSet, ... | Для того чтобы создать a ReplicaSet, ... +Смотрите конфигурационный файл. | Пожалуйста, смотрите конфигурационный файл. +Посмотрите Pods. | С помощью следующей команды мы посмотрим Pods. +{{< /table >}} + +### Обращайтесь к читателю на "вы" + +{{< table caption = "Можно делать и нельзя - Обращайтесь к читателю на вы" >}} +Можно | Нельзя +:--| :----- +Вы можете создать Deployment с помощью ... | Мы создадим Deployment с помощью ... +В предыдущем выводе вы можете увидеть ... | В предыдущем выводе мы можем увидеть ... +{{< /table >}} + + +### Избегайте использования латинских фраз + +Вместо латинских аббревиатур используйте соответствующие выражения на английском. + +{{< table caption = "Можно делать и нельзя - Избегайте использования латинских фраз" >}} +Можно | Нельзя +:--| :----- +For example, ... | e.g., ... +That is, ...| i.e., ... +{{< /table >}} + + +Исключение: используйте "etc." вместо "et cetera". + +## Ошибки, которые следует избегать + +### Избегайте использования "мы" + +Использование "мы" в предложении может сбить с толку, так так неясно, кто под этим "мы" подразумевается (имеется ли в виду сам читатель при этом). + +{{< table caption = "Можно делать и нельзя - Избегайте использования мы" >}} +Можно | Нельзя +:--| :----- +Версия 1.4 включает в себя ... | В версии 1.4 мы добавили ... +Kubernetes представляет новую возможность для ... | Мы представляем новую возможность ... +На этой странице вы узнаете, как использовать Pods. | На этой странице мы познакомимся с Pods. +{{< /table >}} + + +### Избегайте жаргона и идиомы + +Некоторые читатели говорят на английском как на втором языке. Избегайте жаргона и идиом, чтобы облегчить им понимание. + +{{< table caption = "Можно делать и нельзя - Избегайте жаргона и идиомы" >}} +Можно | Нельзя +:--| :----- +Internally, ... | Under the hood, ... +Create a new cluster. | Turn up a new cluster. +{{< /table >}} + + +### Избегайте выражений о будущем + +Не давайте обещаний или намеков на будущее. Если вам нужно рассказать про функциональность в альфа-версии, под соответствующем заголовком напишите поясняющий текст, что информация относится к альфа-версии. + +### Избегайте выражений, которые могут потерять актуальность + +Избегайте таких слов, как "в настоящее время" и "новый". Новая функциональность в настоящее время не будет таковой через несколько месяцев. + +{{< table caption = "Можно делать и нельзя - Избегайте выражений, которые могут потерять актуальность" >}} +Можно | Нельзя +:--| :----- +В версии 1.4 ... | В текущей версии ... +Функциональность Federation предоставляет ... | Новая функциональность Federation предоставляет ... +{{< /table >}} + + +{{% /capture %}} + +{{% capture whatsnext %}} + +* Подробнее про [написание новой темы](/ru/docs/contribute/style/write-new-topic/). +* Подробнее про [использование шаблонов страниц](/ru/docs/contribute/style/page-templates/). +* Подробнее про [создание пулреквеста](/ru/docs/contribute/start/#отправка-пулреквеста)). + +{{% /capture %}} diff --git a/content/ru/docs/contribute/style/write-new-topic.md b/content/ru/docs/contribute/style/write-new-topic.md new file mode 100644 index 0000000000..d13789e529 --- /dev/null +++ b/content/ru/docs/contribute/style/write-new-topic.md @@ -0,0 +1,119 @@ +--- +title: Написание новой темы +content_template: templates/task +weight: 20 +--- + +{{% capture overview %}} +На этой странице показано, как создать новую тему для документации Kubernetes. +{{% /capture %}} + + +{{% capture prerequisites %}} +Создайте копию репозитория документации Kubernetes, как описано в разделе [Участие для начинающих](/ru/docs/contribute/start/). +{{% capture steps %}} + +## Выбор типы страницы + +Перед написанием новой темы, выберите тип страницы, который бы лучше всего подходил под ваш текст: + +{{< table caption = "Правила выбора типа страницы" >}} +Тип | Описание +:--- | :---------- +Концепция | Страница концепции объясняет некоторые аспекты Kubernetes. Например, страницы концепции может описывать объект Deployment в Kubernetes и разъяснить, какую роль он играет после развертывания, масштабирования и обновления приложения. Как правило, страницы концепций не включают последовательности шагов, а вместо этого содержат ссылки на задачи или руководства. В качестве примера концептуальной темы посмотрите страницу Nodes. +Задача | На странице задачи показывается, как сделать что-то одно конкретное, главным образом с помощью короткой последовательности шагов. Страница задачи может быть короткой или длинной, если она остаётся сконцентрированной на одном аспекте. На странице задач можно сочетать краткие объяснения с необходимыми шагами для выполнения, однако если вам нужно дать подробное пояснение, вам следует сделать это в концептуальной теме. Смежные задачи и концептуальные темы должны быть связаны друг с другом. В качестве примера короткой страницы задачи посмотрите Configure a Pod to Use a Volume for Storage. Пример длинной страницы задачи смотрите Configure Liveness and Readiness Probes +Руководство | На странице руководства показано, как сделать что-то более крупнее одной-единственной задачи. В руководстве может быть несколько последовательностей шагов, которые читатели могут реально выполнить по ходу чтения страницы. Либо на странице руководства могут приведены объяснения связанных частей кода. Например, руководство может содержать разбор примера кода. Руководство может включать в себя краткие объяснения связанной функциональности Kubernetes, но при они этом должны ссылаться на сопутствующие концептуальные темы, где можно узнать подробнее про конкретные возможности. +{{< /table >}} + +Используйте шаблон для каждой новой страницы. Каждый тип страницы использует определённый [шаблон](/docs/contribute/style/page-templates/), поэтому при написании собственных тем вам следует выбрать свой шаблон. Использование шаблонов помогает поддерживать единообразие в темах конкретного типа. + +## Выбор заголовка и имени файла a title and filename + +Подберите заголовок, содержащий такие ключевые слова, по которым вы могли его найти в поисковике. +Имя файла должно создаваться из слов в заголовке, написанных через дефис. +Например, для темы с заголовком [Using an HTTP Proxy to Access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) имя файла будет `http-proxy-access-api.md`. Вам не нужно указывать "kubernetes" в имени файла, потому что слово "kubernetes" уже есть в полном URL-адресе темы, например: + + /docs/tasks/access-kubernetes-api/http-proxy-access-api/ + +## Добавление заголовка темы в фронтальную часть + +В [фронтальную часть](https://gohugo.io/content-management/front-matter/) файла вашей темы поместите поле заголовка `title`. Фронтальная часть — YAML-блок, который находится тремя дефисами в самом верху страницы. Например: + + --- + title: Using an HTTP Proxy to Access the Kubernetes API + --- + +## Выбор директории + +В зависимости от типа вашей страницы поместите новый файл в одну из следующую поддиректорию: + +* /content/en/docs/tasks/ +* /content/en/docs/tutorials/ +* /content/en/docs/concepts/ + +Вы можете поместить файл в имеющуюся поддиректорию либо создать новую. + +## Добавление темы в оглавлении + +Оглавление динамически генерируется исходя из структуры директорий документации. Корневые директории в `/content/en/docs/` создают навигацию с основными ссылками, где у каждой поддиректории есть записи в оглавлении. + +В каждой поддиректории есть файл `_index.md`, представляющий собой "главную" страницу всего содержимого этой поддиректории. В файле `_index.md` не нужно применять шаблон. В нём находится обзор содержания тем в поддиректории. + +Другие файлы в директории по умолчанию сортируются в алфавитном порядке. Такой порядок сортировки редко устраивает. Для управления такой относительной сортировкой тем в поддиректории, определите ключ `weight:` с целым числом в фронтальной части файла. Как правило, мы используем значения, кратные 10, чтобы оставить про запас для будущих страниц. Например, тема с весом `10` будет отображаться перед темой с весом `20`. + +## Вставка кода в тему + +Если вы хотите добавить код в тему, вы можете встроить код из файла напрямую, используя синтаксис блока кода в Markdown. Такой способ рекомендуется использовать в следующих случаев (это не исчерпывающий список): + +- В вашем коде показывается вывод такой команды, как `kubectl get deploy mydeployment -o json | jq '.status'`. +- Ваш код недостаточно универсален, чтобы пользователи могли его попробовать сами. В качестве примера можно привести пример YAML-файла для создания Pod, который зависит от конкретной реализации [FlexVolume](/docs/concepts/storage/volumes#flexvolume). +- Ваш код — это не готовый пример, потому что он предзначен для выделения части большего файла. Например, при описании способов настройки [PodSecurityPolicy](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy) по определённым причинам вы можете включить небольшой фрагмент напрямую в файле темы. +- Ваш код по разным причинам не подходит для тестирования пользователями. Например, если вы описываете, как новый атрибут должен добавляться к ресурсу с помощью команды `kubectl edit`, то вы можете добавить короткий пример, показывающий только добавляемый атрибут. + +## Добавление кода из другого файла + +Другой способ добавить код в вашу тему — создать новый полноценный файл с примером (или группу файлов примеров), а затем из вашей темы подключить этот пример. +Используйте этот метод, чтобы включить универсальный и повторно используемый пример YAML-файла, который читатель может проверить сам. + +При добавлении нового отдельного файла примера, например, в формате YAML, поместите код в одну из директорий `/examples/`, где `` — язык темы. В вашем файле темы используйте макрокод `codenew`: + +```none +{{/my-example-yaml>" */>}} +``` + +где `` — это путь к включаемому файлу относительно директории `examples`. Следующий макрокод Hugo ссылается на YAML-файл по пути `/content/en/examples/pods/storage/gce-volume.yaml`. + +```none +{{}} +``` + +{{< note >}} +Чтобы отобразить Hugo-макрокоды в исходном виде, как в приведенном выше примере, поместите их в комментарии в стиле языка Си между `<` и `>`. Для примера посмотрите исходный код этой страницы. +{{< /note >}} + +## Демонстрация создания API-объекта из конфигурационного файла + +Если вам нужно показать, как создать объект API из файла конфигурации, поместите файл конфигурации в одну из директорий в `/examples`. + +В вашей теме укажите эту команду: + +``` +kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml +``` + +{{< note >}} +При добавлении новых YAML-файлов в директорию `/examples`, убедитесь, что этот файл перечислен в файле `/examples_test.go`. Подключённый к сайту Travis CI автоматически выполнит этот тестовый сценарий при отправке PR, чтобы проверить все примеры. +{{< /note >}} + +В качестве примера темы, в которой используется этот метод, смотрите [Running a Single-Instance Stateful Application](/docs/tutorials/stateful-application/run-stateful-application/). + +## Добавление изображений в тему + +Поместите файлы изображений в директорию `/images`. Предпочтительный формат изображения — SVG. + +{{% /capture %}} + +{{% capture whatsnext %}} +* Подробнее про [использование шаблонов страниц](/ru/docs/contribute/style/page-templates/). +* Подробнее про [создание пулреквеста](/ru/docs/contribute/start/#отправка-пулреквеста)). +{{% /capture %}} From aa44d74fc9d0162bfa43f1965faf585881ac171e Mon Sep 17 00:00:00 2001 From: 2BFL Date: Sat, 7 Mar 2020 18:25:34 +0800 Subject: [PATCH 038/194] translation certificates for zh (#19492) Accept tengqm's suggestion --- .../docs/setup/best-practices/certificates.md | 285 ++++++++++++++++++ 1 file changed, 285 insertions(+) create mode 100644 content/zh/docs/setup/best-practices/certificates.md diff --git a/content/zh/docs/setup/best-practices/certificates.md b/content/zh/docs/setup/best-practices/certificates.md new file mode 100644 index 0000000000..0d04a4dbf4 --- /dev/null +++ b/content/zh/docs/setup/best-practices/certificates.md @@ -0,0 +1,285 @@ +--- +title: PKI 证书和要求 +reviewers: +- sig-cluster-lifecycle +content_template: templates/concept +weight: 40 +--- + + +{{% capture overview %}} + + +Kubernetes 需要 PKI 证书才能进行基于 TLS 的身份验证。如果您是使用 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) 安装的 Kubernetes，则会自动生成集群所需的证书。您还可以生成自己的证书。例如，不将私钥存储在 API 服务器上，可以让私钥更加安全。此页面说明了集群必需的证书。 + +{{% /capture %}} + +{{% capture body %}} + + +## 集群是如何使用证书的 + +Kubernetes 需要 PKI 才能执行以下操作： + + +* Kubelet 的客户端证书，用于 API 服务器身份验证 +* API 服务器端点的证书 +* 集群管理员的客户端证书，用于 API 服务器身份认证 +* API 服务器的客户端证书，用于和 Kubelet 的会话 +* API 服务器的客户端证书，用于和 etcd 的会话 +* 控制器管理器的客户端证书/kubeconfig，用于和 API server 的会话 +* 调度器的客户端证书/kubeconfig，用于和 API server 的会话 +* [前端代理][proxy] 的客户端及服务端证书 + +{{< note >}} + +只有当您运行 kube-proxy 并要支持[扩展 API 服务器](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)时，才需要 `front-proxy` 证书 +{{< /note >}} + + +etcd 还实现了双向 TLS 来对客户端和对其他对等节点进行身份验证。 + + +## 证书存放的位置 + +如果你是通过 kubeadm 安装的 Kubernetes，所有证书都存放在 `/etc/kuberntes/pki` 目录下。本文所有相关的路径都是基于该路径的相对路径。 + + +## 手动配置证书 + +如果你不想通过 kubeadm 生成这些必需的证书，你可以通过下面两种方式之一来手动创建他们。 + + +### 单根 CA + +你可以创建一个单根 CA，由管理员控制器它。该根 CA 可以创建多个中间 CA，并将所有进一步的创建委托给 Kubernetes。 + + +需要这些 CA： + +| 路径 | 默认 CN | 描述 | +|------------------------|---------------------------|----------------------------------| +| ca.crt,key | kubernetes-ca | Kubernetes 通用 CA | +| etcd/ca.crt,key | etcd-ca | 与 etcd 相关的所有功能 | +| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | 用于 [前端代理][proxy] | + +上面的 CA 之外，还需要获取用于服务账户管理的密钥对，也就是 `sa.key` 和 `sa.pub`。 + + +### 所有的证书 + +如果你不想将 CA 的私钥拷贝至你的集群中，你也可以自己生成全部的证书。 + +需要这些证书： + +| 默认 CN | 父级 CA | O (位于 Subject 中) | 类型 | 主机 (SAN) | +|-------------------------------|---------------------------|----------------|----------------------------------------|---------------------------------------------| +| kube-etcd | etcd-ca | | server, client | `localhost`, `127.0.0.1` | +| kube-etcd-peer | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | +| kube-etcd-healthcheck-client | etcd-ca | | client | | +| kube-apiserver-etcd-client | etcd-ca | system:masters | client | | +| kube-apiserver | kubernetes-ca | | server | ``, ``, ``, `[1]` | +| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | +| front-proxy-client | kubernetes-front-proxy-ca | | client | | + + +[1]: 用来连接到集群的不同 IP 或 DNS 名（就像 [kubeadm][kubeadm] 为负载均衡所使用的固定 IP 或 DNS 名，`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`） + +其中，`kind` 对应一种或多种类型的 [x509 密钥用途][usage]： + + +| kind | 密钥用途 | +|--------|---------------------------------------------------------------------------------| +| server | 数字签名、密钥加密、服务端认证 | +| client | 数字签名、密钥加密、客户端认证 | + + +{{< note >}} + +上面列出的 Hosts/SAN 是推荐的配置方式；如果需要特殊安装，则可以在所有服务器证书上添加其他 SAN。 +{{< /note >}} + +{{< note >}} + +对于 kubeadm 用户： + +* 不使用私钥，将证书复制到集群 CA 的方案，在 kubeadm 文档中将这种方案称为外部 CA。 +* 如果将以上列表与 kubeadm 生成的 PKI 进行比较，你会注意到，如果使用外部 etcd，则不会生成 `kube-etcd`、`kube-etcd-peer` 和 `kube-etcd-healthcheck-client` 证书。 + +{{< /note >}} + + +### 证书路径 + +证书应放置在建议的路径中（以便 [kubeadm][kubeadm]使用）。无论使用什么位置，都应使用给定的参数指定路径。 + +| 默认 CN | 建议的密钥路径 | 建议的证书路径 | 命令 | 密钥参数 | 证书参数 | +|------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------| +| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile | +| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile | +| kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file | +| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file, --root-ca-file, --cluster-signing-cert-file | +| kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file | +| kube-apiserver-kubelet-client| apiserver-kubelet-client.key | apiserver-kubelet-client.crt| kube-apiserver | --kubelet-client-key | --kubelet-client-certificate | +| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file | +| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | --requestheader-client-ca-file | +| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file | +| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | --trusted-ca-file, --peer-trusted-ca-file | +| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file | +| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file | +| etcd-ca | | etcd/ca.crt | etcdctl | | --cacert | +| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert | + + +注意事项同样适用于服务帐户密钥对： + +| 私钥路径 | 公钥路径 | 命令 | 参数 | +|------------------------------|-----------------------------|-------------------------|--------------------------------------| +| sa.key | | kube-controller-manager | service-account-private | +| | sa.pub | kube-apiserver | service-account-key | + + +## 为用户帐户配置证书 + +您必须手动配置以下管理员帐户和服务帐户： + +| 文件名 | 凭据名称 | 默认 CN | O (位于 Subject 中) | +|-------------------------|----------------------------|--------------------------------|----------------| +| admin.conf | default-admin | kubernetes-admin | system:masters | +| kubelet.conf | default-auth | system:node:`` (see note) | system:nodes | +| controller-manager.conf | default-controller-manager | system:kube-controller-manager | | +| scheduler.conf | default-scheduler | system:kube-scheduler | | + +{{< note >}} + +`kubelet.conf` 中 `` 的值 **必须** 与 kubelet 向 apiserver 注册时提供的节点名称的值完全匹配。有关更多详细信息，请阅读[节点授权](/docs/reference/access-authn-authz/node/)。 +{{< /note >}} + + +1. 对于每个配置，请都使用给定的 CN 和 O 生成 x509 证书/密钥偶对。 + +1. 为每个配置运行下面的 `kubectl` 命令： + +```shell +KUBECONFIG= kubectl config set-cluster default-cluster --server=https://:6443 --certificate-authority --embed-certs +KUBECONFIG= kubectl config set-credentials --client-key .pem --client-certificate .pem --embed-certs +KUBECONFIG= kubectl config set-context default-system --cluster default-cluster --user +KUBECONFIG= kubectl config use-context default-system +``` + + +这些文件用途如下： + +| 文件名 | 命令 | 说明 | +|-------------------------|-------------------------|-----------------------------------------------------------------------| +| admin.conf | kubectl | 配置集群的管理员 | +| kubelet.conf | kubelet | 集群中的每个节点都需要一份 | +| controller-manager.conf | kube-controller-manager | 必需添加到 `manifests/kube-controller-manager.yaml` 清单中 | +| scheduler.conf | kube-scheduler | 必需添加到 `manifests/kube-scheduler.yaml` 清单中 | + +[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage +[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/ +[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/ + +{{% /capture %}} From 56379649d38f5e49a77b54ccf737cf7177c1dacd Mon Sep 17 00:00:00 2001 From: divya-mohan0209 Date: Sat, 7 Mar 2020 19:01:34 +0530 Subject: [PATCH 039/194] Added date metadata to blog articles #19503 (#19523) Added HTML element to the date heading in blog post articles. The opening
- + + @@ -496,30 +615,30 @@ NOTE: editing the role is not recommended as changes will be overwritten on API - + - + - +
Kubernetes RBAC API discovery roles
Default ClusterRole Default ClusterRoleBinding
system:basic-user system:authenticated groupAllows a user read-only access to basic information about themselves. Prior to 1.14, this role was also bound to `system:unauthenticated` by default.Allows a user read-only access to basic information about themselves. Prior to v1.14, this role was also bound to system:unauthenticated by default.
system:discovery system:authenticated groupAllows read-only access to API discovery endpoints needed to discover and negotiate an API level. Prior to 1.14, this role was also bound to `system:unauthenticated` by default.Allows read-only access to API discovery endpoints needed to discover and negotiate an API level. Prior to v1.14, this role was also bound to system:unauthenticated by default.
system:public-info-viewer system:authenticated and system:unauthenticated groupsAllows read-only access to non-sensitive information about the cluster. Introduced in 1.14.Allows read-only access to non-sensitive information about the cluster. Introduced in Kubernetes v1.14.
-### User-facing Roles +### User-facing roles -Some of the default roles are not `system:` prefixed. These are intended to be user-facing roles. -They include super-user roles (`cluster-admin`), -roles intended to be granted cluster-wide using ClusterRoleBindings (`cluster-status`), -and roles intended to be granted within particular namespaces using RoleBindings (`admin`, `edit`, `view`). +Some of the default ClusterRoles are not `system:` prefixed. These are intended to be user-facing roles. +They include super-user roles (`cluster-admin`), roles intended to be granted cluster-wide +using ClusterRoleBindings, and roles intended to be granted within particular +namespaces using RoleBindings (`admin`, `edit`, `view`). -As of 1.9, user-facing roles use [ClusterRole Aggregation](#aggregated-clusterroles) to allow admins to include -rules for custom resources on these roles. To add rules to the "admin", "edit", or "view" role, create a -ClusterRole with one or more of the following labels: +User-facing ClusterRoles use [ClusterRole aggregation](#aggregated-clusterroles) to allow admins to include +rules for custom resources on these ClusterRoles. To add rules to the `admin`, `edit`, or `view` roles, create +a ClusterRole with one or more of the following labels: ```yaml metadata: @@ -541,32 +660,40 @@ metadata: system:masters group Allows super-user access to perform any action on any resource. When used in a ClusterRoleBinding, it gives full control over every resource in the cluster and in all namespaces. -When used in a RoleBinding, it gives full control over every resource in the rolebinding's namespace, including the namespace itself. +When used in a RoleBinding, it gives full control over every resource in the role binding's namespace, including the namespace itself. admin None Allows admin access, intended to be granted within a namespace using a RoleBinding. If used in a RoleBinding, allows read/write access to most resources in a namespace, -including the ability to create roles and rolebindings within the namespace. -It does not allow write access to resource quota or to the namespace itself. +including the ability to create roles and role bindings within the namespace. +This role does not allow write access to resource quota or to the namespace itself. edit None Allows read/write access to most objects in a namespace. -It does not allow viewing or modifying roles or rolebindings. + +This role does not allow viewing or modifying roles or role bindings. +However, this role allows accessing Secrets and running Pods as any ServiceAccount in +the namespace, so it can be used to gain the API access levels of any ServiceAccount in +the namespace. view None Allows read-only access to see most objects in a namespace. -It does not allow viewing roles or rolebindings. -It does not allow viewing secrets, since those are escalating. +It does not allow viewing roles or role bindings. + +This role does not allow viewing Secrets, since reading +the contents of Secrets enables access to ServiceAccount credentials +in the namespace, which would allow API access as any ServiceAccount +in the namespace (a form of privilege escalation). -### Core Component Roles +### Core component roles @@ -578,7 +705,7 @@ It does not allow viewing secrets, since those are escalating. - + @@ -588,28 +715,27 @@ It does not allow viewing secrets, since those are escalating. - + - - + - +
system:kube-scheduler system:kube-scheduler userAllows access to the resources required by the kube-scheduler component.Allows access to the resources required by the {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} component.
system:volume-scheduler
system:kube-controller-manager system:kube-controller-manager userAllows access to the resources required by the kube-controller-manager component. -The permissions required by individual control loops are contained in the controller roles.Allows access to the resources required by the {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} component. +The permissions required by individual controllers are detailed in the controller roles.
system:nodeNone in 1.8+Allows access to resources required by the kubelet component, including read access to all secrets, and write access to all pod status objects. +NoneAllows access to resources required by the kubelet, including read access to all secrets, and write access to all pod status objects. -As of 1.7, use of the Node authorizer and NodeRestriction admission plugin is recommended instead of this role, and allow granting API access to kubelets based on the pods scheduled to run on them. -Prior to 1.7, this role was automatically bound to the `system:nodes` group. -In 1.7, this role was automatically bound to the `system:nodes` group if the `Node` authorization mode is not enabled. -In 1.8+, no binding is automatically created. +You should use the Node authorizer and NodeRestriction admission plugin instead of the system:node role, and allow granting API access to kubelets based on the Pods scheduled to run on them. + +The system:node role only exists for compatibility with Kubernetes clusters upgraded from versions prior to v1.8.
system:node-proxier system:kube-proxy userAllows access to the resources required by the kube-proxy component.Allows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.
-### Other Component Roles +### Other component roles @@ -627,7 +753,7 @@ This is commonly used by add-on API servers for unified authentication and autho - + @@ -648,7 +774,7 @@ This is commonly used by add-on API servers for unified authentication and autho +kubelet TLS bootstrapping. @@ -662,73 +788,80 @@ This is commonly used by add-on API servers for unified authentication and autho
system:heapster NoneRole for the Heapster component.Role for the Heapster component (deprecated).
system:kube-aggregatorsystem:node-bootstrapper None Allows access to the resources required to perform -Kubelet TLS bootstrapping.
system:node-problem-detector
-### Controller Roles +### Roles for built-in controllers {#controller-roles} -The [Kubernetes controller manager](/docs/admin/kube-controller-manager/) runs core control loops. -When invoked with `--use-service-account-credentials`, each control loop is started using a separate service account. -Corresponding roles exist for each control loop, prefixed with `system:controller:`. -If the controller manager is not started with `--use-service-account-credentials`, -it runs all control loops using its own credential, which must be granted all the relevant roles. +The Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} runs +{{< glossary_tooltip term_id="controller" text="controllers" >}} that are built in to the Kubernetes +control plane. +When invoked with `--use-service-account-credentials`, kube-controller-manager starts each controller +using a separate service account. +Corresponding roles exist for each built-in controller, prefixed with `system:controller:`. +If the controller manager is not started with `--use-service-account-credentials`, it runs all control loops +using its own credential, which must be granted all the relevant roles. These roles include: -* system:controller:attachdetach-controller -* system:controller:certificate-controller -* system:controller:clusterrole-aggregation-controller -* system:controller:cronjob-controller -* system:controller:daemon-set-controller -* system:controller:deployment-controller -* system:controller:disruption-controller -* system:controller:endpoint-controller -* system:controller:expand-controller -* system:controller:generic-garbage-collector -* system:controller:horizontal-pod-autoscaler -* system:controller:job-controller -* system:controller:namespace-controller -* system:controller:node-controller -* system:controller:persistent-volume-binder -* system:controller:pod-garbage-collector -* system:controller:pv-protection-controller -* system:controller:pvc-protection-controller -* system:controller:replicaset-controller -* system:controller:replication-controller -* system:controller:resourcequota-controller -* system:controller:root-ca-cert-publisher -* system:controller:route-controller -* system:controller:service-account-controller -* system:controller:service-controller -* system:controller:statefulset-controller -* system:controller:ttl-controller +* `system:controller:attachdetach-controller` +* `system:controller:certificate-controller` +* `system:controller:clusterrole-aggregation-controller` +* `system:controller:cronjob-controller` +* `system:controller:daemon-set-controller` +* `system:controller:deployment-controller` +* `system:controller:disruption-controller` +* `system:controller:endpoint-controller` +* `system:controller:expand-controller` +* `system:controller:generic-garbage-collector` +* `system:controller:horizontal-pod-autoscaler` +* `system:controller:job-controller` +* `system:controller:namespace-controller` +* `system:controller:node-controller` +* `system:controller:persistent-volume-binder` +* `system:controller:pod-garbage-collector` +* `system:controller:pv-protection-controller` +* `system:controller:pvc-protection-controller` +* `system:controller:replicaset-controller` +* `system:controller:replication-controller` +* `system:controller:resourcequota-controller` +* `system:controller:root-ca-cert-publisher` +* `system:controller:route-controller` +* `system:controller:service-account-controller` +* `system:controller:service-controller` +* `system:controller:statefulset-controller` +* `system:controller:ttl-controller` -## Privilege Escalation Prevention and Bootstrapping +## Privilege escalation prevention and bootstrapping The RBAC API prevents users from escalating privileges by editing roles or role bindings. Because this is enforced at the API level, it applies even when the RBAC authorizer is not in use. -A user can only create/update a role if at least one of the following things is true: +### Restrictions on role creation or update -1. They already have all the permissions contained in the role, at the same scope as the object being modified -(cluster-wide for a `ClusterRole`, within the same namespace or cluster-wide for a `Role`) -2. They are given explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group (Kubernetes 1.12 and newer) +You can only create/update a role if at least one of the following things is true: -For example, if "user-1" does not have the ability to list secrets cluster-wide, they cannot create a `ClusterRole` +1. You already have all the permissions contained in the role, at the same scope as the object being modified +(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role). +2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group. + +For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRole containing that permission. To allow a user to create/update roles: -1. Grant them a role that allows them to create/update `Role` or `ClusterRole` objects, as desired. -2. Grant them permission to include specific permissions in the roles the create/update: - * implicitly, by giving them those permissions (if they attempt to create or modify a `Role` or `ClusterRole` with permissions they themselves have not been granted, the API request will be forbidden) - * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group (Kubernetes 1.12 and newer) +1. Grant them a role that allows them to create/update Role or ClusterRole objects, as desired. +2. Grant them permission to include specific permissions in the roles they create/update: + * implicitly, by giving them those permissions (if they attempt to create or modify a Role or ClusterRole with permissions they themselves have not been granted, the API request will be forbidden) + * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group -A user can only create/update a role binding if they already have all the permissions contained in the referenced role -(at the same scope as the role binding) *or* if they've been given explicit permission to perform the `bind` verb on the referenced role. -For example, if "user-1" does not have the ability to list secrets cluster-wide, they cannot create a `ClusterRoleBinding` +### Restrictions on role binding creation or update + +You can only create/update a role binding if you already have all the permissions contained in the referenced role +(at the same scope as the role binding) *or* if you have been authorized to perform the `bind` verb on the referenced role. +For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRoleBinding to a role that grants that permission. To allow a user to create/update role bindings: -1. Grant them a role that allows them to create/update `RoleBinding` or `ClusterRoleBinding` objects, as desired. +1. Grant them a role that allows them to create/update RoleBinding or ClusterRoleBinding objects, as desired. 2. Grant them permissions needed to bind a particular role: * implicitly, by giving them the permissions contained in the role. - * explicitly, by giving them permission to perform the `bind` verb on the particular role (or cluster role). + * explicitly, by giving them permission to perform the `bind` verb on the particular Role (or ClusterRole). -For example, this cluster role and role binding would allow "user-1" to grant other users the `admin`, `edit`, and `view` roles in the "user-1-namespace" namespace: +For example, this ClusterRole and RoleBinding would allow `user-1` to grant other users the `admin`, `edit`, and `view` roles in the namespace `user-1-namespace`: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -762,126 +895,126 @@ subjects: When bootstrapping the first roles and role bindings, it is necessary for the initial user to grant permissions they do not yet have. To bootstrap initial roles and role bindings: -* Use a credential with the `system:masters` group, which is bound to the `cluster-admin` super-user role by the default bindings. +* Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings. * If your API server runs with the insecure port enabled (`--insecure-port`), you can also make API calls via that port, which does not enforce authentication or authorization. -## Command-line Utilities +## Command-line utilities ### `kubectl create role` -Creates a `Role` object defining permissions within a single namespace. Examples: +Creates a Role object defining permissions within a single namespace. Examples: -* Create a `Role` named "pod-reader" that allows user to perform "get", "watch" and "list" on pods: +* Create a Role named "pod-reader" that allows users to perform `get`, `watch` and `list` on pods: - ``` + ```shell kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods ``` -* Create a `Role` named "pod-reader" with resourceNames specified: +* Create a Role named "pod-reader" with resourceNames specified: - ``` + ```shell kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod ``` -* Create a `Role` named "foo" with apiGroups specified: +* Create a Role named "foo" with apiGroups specified: - ``` + ```shell kubectl create role foo --verb=get,list,watch --resource=replicasets.apps ``` -* Create a `Role` named "foo" with subresource permissions: +* Create a Role named "foo" with subresource permissions: - ``` + ```shell kubectl create role foo --verb=get,list,watch --resource=pods,pods/status ``` -* Create a `Role` named "my-component-lease-holder" with permissions to get/update a resource with a specific name: +* Create a Role named "my-component-lease-holder" with permissions to get/update a resource with a specific name: - ``` + ```shell kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component ``` ### `kubectl create clusterrole` -Creates a `ClusterRole` object. Examples: +Creates a ClusterRole. Examples: -* Create a `ClusterRole` named "pod-reader" that allows user to perform "get", "watch" and "list" on pods: +* Create a ClusterRole named "pod-reader" that allows user to perform `get`, `watch` and `list` on pods: - ``` + ```shell kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods ``` -* Create a `ClusterRole` named "pod-reader" with resourceNames specified: +* Create a ClusterRole named "pod-reader" with resourceNames specified: - ``` + ```shell kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod ``` -* Create a `ClusterRole` named "foo" with apiGroups specified: +* Create a ClusterRole named "foo" with apiGroups specified: - ``` + ```shell kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps ``` -* Create a `ClusterRole` named "foo" with subresource permissions: +* Create a ClusterRole named "foo" with subresource permissions: - ``` + ```shell kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status ``` -* Create a `ClusterRole` name "foo" with nonResourceURL specified: +* Create a ClusterRole named "foo" with nonResourceURL specified: - ``` + ```shell kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* ``` -* Create a `ClusterRole` name "monitoring" with aggregationRule specified: +* Create a ClusterRole named "monitoring" with an aggregationRule specified: - ``` + ```shell kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" ``` ### `kubectl create rolebinding` -Grants a `Role` or `ClusterRole` within a specific namespace. Examples: +Grants a Role or ClusterRole within a specific namespace. Examples: -* Within the namespace "acme", grant the permissions in the `admin` `ClusterRole` to a user named "bob": +* Within the namespace "acme", grant the permissions in the "admin" ClusterRole to a user named "bob": - ``` + ```shell kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme ``` -* Within the namespace "acme", grant the permissions in the `view` `ClusterRole` to the service account in the namespace "acme" named "myapp" : +* Within the namespace "acme", grant the permissions in the "view" ClusterRole to the service account in the namespace "acme" named "myapp": - ``` + ```shell kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme ``` -* Within the namespace "acme", grant the permissions in the `view` `ClusterRole` to a service account in the namespace "myappnamespace" named "myapp": +* Within the namespace "acme", grant the permissions in the "view" ClusterRole to a service account in the namespace "myappnamespace" named "myapp": - ``` + ```shell kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme ``` ### `kubectl create clusterrolebinding` -Grants a `ClusterRole` across the entire cluster, including all namespaces. Examples: +Grants a ClusterRole across the entire cluster (all namespaces). Examples: -* Across the entire cluster, grant the permissions in the `cluster-admin` `ClusterRole` to a user named "root": +* Across the entire cluster, grant the permissions in the "cluster-admin" ClusterRole to a user named "root": - ``` + ```shell kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root ``` -* Across the entire cluster, grant the permissions in the `system:node-proxier ` `ClusterRole` to a user named "system:kube-proxy": +* Across the entire cluster, grant the permissions in the "system:node-proxier" ClusterRole to a user named "system:kube-proxy": - ``` + ```shell kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy ``` -* Across the entire cluster, grant the permissions in the `view` `ClusterRole` to a service account named "myapp" in the namespace "acme": +* Across the entire cluster, grant the permissions in the "view" ClusterRole to a service account named "myapp" in the namespace "acme": - ``` + ```shell kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp ``` @@ -901,33 +1034,32 @@ Examples: * Test applying a manifest file of RBAC objects, displaying changes that would be made: - ``` + ```shell kubectl auth reconcile -f my-rbac-rules.yaml --dry-run ``` * Apply a manifest file of RBAC objects, preserving any extra permissions (in roles) and any extra subjects (in bindings): - ``` + ```shell kubectl auth reconcile -f my-rbac-rules.yaml ``` * Apply a manifest file of RBAC objects, removing any extra permissions (in roles) and any extra subjects (in bindings): - ``` + ```shell kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions ``` -See the CLI help for detailed usage. - -## Service Account Permissions +## ServiceAccount permissions {#service-account-permissions} Default RBAC policies grant scoped permissions to control-plane components, nodes, and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace (beyond discovery permissions given to all authenticated users). -This allows you to grant particular roles to particular service accounts as needed. +This allows you to grant particular roles to particular ServiceAccounts as needed. Fine-grained role bindings provide greater security, but require more effort to administrate. -Broader grants can give unnecessary (and potentially escalating) API access to service accounts, but are easier to administrate. +Broader grants can give unnecessary (and potentially escalating) API access to +ServiceAccounts, but are easier to administrate. In order from most secure to least secure, the approaches are: @@ -949,9 +1081,10 @@ In order from most secure to least secure, the approaches are: If an application does not specify a `serviceAccountName`, it uses the "default" service account. - {{< note >}}Permissions given to the "default" service - account are available to any pod in the namespace that does not - specify a `serviceAccountName`.{{< /note >}} + {{< note >}} + Permissions given to the "default" service account are available to any pod + in the namespace that does not specify a `serviceAccountName`. + {{< /note >}} For example, grant read-only permission within "my-namespace" to the "default" service account: @@ -962,12 +1095,15 @@ In order from most secure to least secure, the approaches are: --namespace=my-namespace ``` - Many [add-ons](/docs/concepts/cluster-administration/addons/) currently run as the "default" service account in the `kube-system` namespace. - To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the `kube-system` namespace. + Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the + "default" service account in the `kube-system` namespace. + To allow those add-ons to run with super-user access, grant cluster-admin + permissions to the "default" service account in the `kube-system` namespace. - {{< note >}}Enabling this means the `kube-system` - namespace contains secrets that grant super-user access to the - API.{{< /note >}} + {{< caution >}} + Enabling this means the `kube-system` namespace contains Secrets + that grant super-user access to your cluster's API. + {{< /caution >}} ```shell kubectl create clusterrolebinding add-on-cluster-admin \ @@ -1006,9 +1142,9 @@ In order from most secure to least secure, the approaches are: If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts. {{< warning >}} - This allows any user with read access - to secrets or the ability to create a pod to access super-user - credentials. + This allows any application full access to your cluster, and also grants + any user with read access to Secrets (or the ability to create any pod) + full access to your cluster. {{< /warning >}} ```shell @@ -1017,10 +1153,11 @@ In order from most secure to least secure, the approaches are: --group=system:serviceaccounts ``` -## Upgrading from 1.5 +## Upgrading from ABAC -Prior to Kubernetes 1.6, many deployments used very permissive ABAC policies, -including granting full API access to all service accounts. +Clusters that originally ran older Kubernetes versions often used +permissive ABAC policies, including granting full API access to all +service accounts. Default RBAC policies grant scoped permissions to control-plane components, nodes, and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace @@ -1029,28 +1166,31 @@ and controllers, but grant *no permissions* to service accounts outside the `kub While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions. Here are two approaches for managing this transition: -### Parallel Authorizers +### Parallel authorizers Run both the RBAC and ABAC authorizers, and specify a policy file that contains -[the legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format): +the [legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format): ``` ---authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.json +--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json ``` -The RBAC authorizer will attempt to authorize requests first. If it denies an API request, -the ABAC authorizer is then run. This means that any request allowed by *either* the RBAC -or ABAC policies is allowed. +To explain that first command line option in detail: if earlier authorizers, such as Node, +deny a request, then the the RBAC authorizer attempts to authorize the API request. If RBAC +also denies that API request, the ABAC authorizer is then run. This means that any request +allowed by *either* the RBAC or ABAC policies is allowed. -When the apiserver is run with a log level of 5 or higher for the RBAC component (`--vmodule=rbac*=5` or `--v=5`), -you can see RBAC denials in the apiserver log (prefixed with `RBAC DENY:`). +When the kube-apiserver is run with a log level of 5 or higher for the RBAC component +(`--vmodule=rbac*=5` or `--v=5`), you can see RBAC denials in the API server log +(prefixed with `RBAC DENY:`). You can use that information to determine which roles need to be granted to which users, groups, or service accounts. -Once you have [granted roles to service accounts](#service-account-permissions) and workloads are running with no RBAC denial messages -in the server logs, you can remove the ABAC authorizer. -## Permissive RBAC Permissions +Once you have [granted roles to service accounts](#service-account-permissions) and workloads +are running with no RBAC denial messages in the server logs, you can remove the ABAC authorizer. -You can replicate a permissive policy using RBAC role bindings. +### Permissive RBAC permissions + +You can replicate a permissive ABAC policy using RBAC role bindings. {{< warning >}} The following policy allows **ALL** service accounts to act as cluster administrators. @@ -1058,7 +1198,7 @@ Any application running in a container receives service account credentials auto and could perform any action against the API, including viewing secrets and modifying permissions. This is not a recommended policy. -``` +```shell kubectl create clusterrolebinding permissive-binding \ --clusterrole=cluster-admin \ --user=admin \ @@ -1067,4 +1207,7 @@ kubectl create clusterrolebinding permissive-binding \ ``` {{< /warning >}} +After you have transitioned to use RBAC, you should adjust the access controls +for your cluster to ensure that these meet your information security needs. + {{% /capture %}} From 4ed2cf77485fa35bbfa8d8d32d13d13bc8afe968 Mon Sep 17 00:00:00 2001 From: "Yuk, Yongsu" Date: Thu, 19 Mar 2020 09:02:43 +0900 Subject: [PATCH 163/194] Edit kube-scheduler glossary. (#19708) * Edit kube-scheduler glossary. #19707 * Apply suggestions from code review Co-Authored-By: Tim Bannister Co-authored-by: Tim Bannister --- content/en/docs/reference/glossary/kube-scheduler.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/glossary/kube-scheduler.md b/content/en/docs/reference/glossary/kube-scheduler.md index e3babcab3f..a1a91a1527 100755 --- a/content/en/docs/reference/glossary/kube-scheduler.md +++ b/content/en/docs/reference/glossary/kube-scheduler.md @@ -11,7 +11,7 @@ tags: - architecture --- Control plane component that watches for newly created -{{< glossary_tooltip term_id="node" >}} with no assigned +{{< glossary_tooltip term_id="pod" text="Pods" >}} with no assigned {{< glossary_tooltip term_id="node" text="node">}}, and selects a node for them to run on. From c944c3ab6d377912a36f639acb77f5c0bcdd50bf Mon Sep 17 00:00:00 2001 From: Karen Bradshaw Date: Thu, 19 Mar 2020 13:32:36 -0400 Subject: [PATCH 164/194] update redirects, netlify changes (#19695) fixes and updates --- static/_redirects | 80 +++++++++++++++++------------------------------ 1 file changed, 29 insertions(+), 51 deletions(-) diff --git a/static/_redirects b/static/_redirects index e032dcbdf9..1c470854bb 100644 --- a/static/_redirects +++ b/static/_redirects @@ -4,24 +4,21 @@ # test at https://play.netlify.com/redirects # ############################################### -/api-ref/ https://github.com/kubernetes/kubernetes/milestones/ 301 /concepts/containers/container-lifecycle-hooks/ /docs/concepts/containers/container-lifecycle-hooks/ 301 -/docs/ /docs/home/ 301 -/de/docs/ /de/docs/home/ 301 -/es/docs/ /es/docs/home/ 301 -/fr/docs/ /fr/docs/home/ 301 -/id/docs/ /id/docs/home/ 301 -/ja/docs/ /ja/docs/home/ 301 -/ko/docs/ /ko/docs/home/ 301 -/no/docs/ /no/docs/home/ 301 -/pl/docs/ /pl/docs/home/ 301 -/pt/docs/ /pt/docs/home/ 301 -/ru/docs/ /ru/docs/home/ 301 -/vi/docs/ /vi/docs/home/ 301 -/zh/docs/ /zh/docs/home/ 301 - -/blog/2018/03/kubernetes-1.10-stabilizing-storage-security-networking/ /blog/2018/03/27/kubernetes-1.10-stabilizing-storage-security-networking/ 301 - +/docs/ /docs/home/ 301! +/de/docs/ /de/docs/home/ 301! +/es/docs/ /es/docs/home/ 301! +/fr/docs/ /fr/docs/home/ 301! +/id/docs/ /id/docs/home/ 301! +/ja/docs/ /ja/docs/home/ 301! +/ko/docs/ /ko/docs/home/ 301! +/no/docs/ /no/docs/home/ 301! +/pl/docs/ /pl/docs/home/ 301! +/pt/docs/ /pt/docs/home/ 301! +/ru/docs/ /ru/docs/home/ 301! +/vi/docs/ /vi/docs/home/ 301! +/zh/docs/ /zh/docs/home/ 301! +/blog/2018/03/kubernetes-1.10-stabilizing-storage-security-networking/ /blog/2018/03/26/kubernetes-1.10-stabilizing-storage-security-networking/ 301! /docs/admin/ /docs/concepts/cluster-administration/cluster-administration-overview/ 301 /docs/admin/add-ons/ /docs/concepts/cluster-administration/addons/ 301 /docs/admin/addons/ /docs/concepts/cluster-administration/addons/ 301 @@ -36,12 +33,11 @@ /docs/admin/dns/ /docs/concepts/services-networking/dns-pod-service/ 301 /docs/admin/etcd/ /docs/tasks/administer-cluster/configure-upgrade-etcd/ 301 /docs/admin/etcd_upgrade/ /docs/tasks/administer-cluster/configure-upgrade-etcd/ 301 -/docs/admin/extensible-admission-controllers.md /docs/admin/extensible-admission-controllers/ 301 +/docs/admin/extensible-admission-controllers.md /docs/reference/access-authn-authz/extensible-admission-controllers/ 301 /docs/admin/garbage-collection/ /docs/concepts/cluster-administration/kubelet-garbage-collection/ 301 /docs/admin/ha-master-gce/ /docs/tasks/administer-cluster/highly-available-master/ 301 /docs/admin/ha-master-gce.md/ /docs/tasks/administer-cluster/highly-available-master/ 301 -/docs/admin/high-availability/ /docs/admin/high-availability/building/ 301 -/docs/admin/kubeadm-upgrade-1-7/ /docs/tasks/administer-cluster/upgrade-downgrade/kubeadm-upgrade-1-7/ 301 +/docs/admin/high-availability/ /docs/setup/production-environment/tools/kubeadm/high-availability/ 301 /docs/admin/kubelet-authentication-authorization/ /docs/reference/command-line-tools-reference/kubelet-authentication-authorization/ 301 /docs/admin/kubelet-tls-bootstrapping/ /docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/ 301 /docs/admin/limitrange/ /docs/tasks/administer-cluster/cpu-memory-limit/ 301 @@ -56,6 +52,7 @@ /docs/admin/node-allocatable/ /docs/tasks/administer-cluster/reserve-compute-resources/ 301 /docs/admin/node-allocatable.md /docs/tasks/administer-cluster/reserve-compute-resources/ 301 /docs/admin/node-conformance.md /docs/admin/node-conformance/ 301 +/docs/admin/node-conformance/ /docs/setup/best-practices/node-conformance/ 301 /docs/admin/node-problem/ /docs/tasks/debug-application-cluster/monitor-node-health/ 301 /docs/admin/out-of-resource/ /docs/tasks/administer-cluster/out-of-resource/ 301 /docs/admin/rescheduler/ /docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/ 301 @@ -65,18 +62,10 @@ /docs/admin/static-pods/ /docs/tasks/administer-cluster/static-pod/ 301 /docs/admin/sysctls/ /docs/tasks/administer-cluster/sysctl-cluster/ 301 /docs/admin/resource-quota/ /docs/concepts/policy/resource-quotas/ 301 -/docs/admin/upgrade-1-6/ /docs/tasks/administer-cluster/upgrade-downgrade/upgrade-1-6/ 301 /docs/api/ /docs/concepts/overview/kubernetes-api/ 301 /docs/api-reference/labels-annotations-taints/ /docs/reference/labels-annotations-taints/ 301 -/docs/api-reference/v1.6/* https://v1-6.docs.kubernetes.io/docs/reference/ 301 -/docs/api-reference/v1.7/* https://v1-7.docs.kubernetes.io/docs/reference/ 301 -/docs/api-reference/v1.8/* https://v1-8.docs.kubernetes.io/docs/api-reference/v1.8/:splat 301 -/docs/api-reference/v1.9/ https://v1-9.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/ 301 -/docs/api-reference/v1/definitions/ /docs/reference/generated/kubernetes-api/v1.10/ 301 -/docs/api-reference/v1/definitions.html /docs/reference/generated/kubernetes-api/v1.10/ 301 -/docs/api-reference/v1/operations/ /docs/reference/generated/kubernetes-api/v1.10/ 301 /docs/concepts/abstractions/controllers/garbage-collection/ /docs/concepts/workloads/controllers/garbage-collection/ 301 /docs/concepts/abstractions/controllers/statefulsets/ /docs/concepts/workloads/controllers/statefulset/ 301 @@ -132,7 +121,7 @@ /docs/concepts/workloads/controllers/deployment/docs/concepts/workloads/pods/pod/ /docs/concepts/workloads/pods/pod/ 301 /docs/concepts/workloads/controllers/job/ /docs/concepts/workloads/controllers/jobs-run-to-completion/ 301 /docs/concepts/workloads/controllers/statefulsets/ /docs/concepts/workloads/controllers/statefulset/ 301 -/docs/concepts/workloads/controllers/statefulset.md /docs/concepts/workloads/controllers/statefulset/ 301 +/docs/concepts/workloads/controllers/statefulset.md /docs/concepts/workloads/controllers/statefulset/ 301! /docs/concepts/workloads/pods/init-containers/Kubernetes/ /docs/concepts/workloads/pods/init-containers/ 301 /docs/consumer-guideline/pod-security-coverage/ /docs/concepts/policy/pod-security-policy/ 301 @@ -209,19 +198,14 @@ /docs/reference/glossary/maintainer/ /docs/reference/glossary/approver/ 301 /docs/reference/kubectl/kubectl/kubectl_*.md /docs/reference/generated/kubectl/kubectl-commands#:splat 301 -/docs/reference/workloads-18-19/ https://v1-9.docs.kubernetes.io/docs/reference/workloads-18-19/ 301 /docs/reporting-security-issues/ /security/ 301 -/docs/resources-reference/1_6/* /docs/resources-reference/v1.6/ 301 -/docs/resources-reference/1_7/* /docs/resources-reference/v1.7/ 301 -/docs/resources-reference/v1.8/* /docs/api-reference/v1.8/:splat 301 - /docs/roadmap/ https://github.com/kubernetes/kubernetes/milestones/ 301 /docs/samples/ /docs/tutorials/ 301 /docs/stable/user-guide/labels/ /docs/concepts/overview/working-with-objects/labels/ 301 -/docs/tasks/access-application-cluster/access-cluster.md /docs/tasks/access-application-cluster/access-cluster/ 301 +/docs/tasks/access-application-cluster/access-cluster.md /docs/tasks/access-application-cluster/access-cluster/ 301! /docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/ /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ 301 /docs/tasks/access-kubernetes-api/access-kubernetes-api/http-proxy-access-api/ /docs/tasks/access-kubernetes-api/http-proxy-access-api/ 301 /docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/ /docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/ 301 @@ -244,9 +228,9 @@ /docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-13 /docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/ 301 /docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14 /docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/ 301 /docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15 /docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/ 301 -/docs/tasks/administer-cluster/kubeadm-upgrade-1-7/ /docs/tasks/administer-cluster/upgrade-downgrade/kubeadm-upgrade-1-7/ 301 -/docs/tasks/administer-cluster/kubeadm-upgrade-1-8/ /docs/tasks/administer-cluster/upgrade-downgrade/kubeadm-upgrade-1-8/ 301 -/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/ /docs/tasks/administer-cluster/upgrade-downgrade/kubeadm-upgrade-1-9/ 301 +#/docs/tasks/administer-cluster/kubeadm-upgrade-1-7/ /docs/tasks/administer-cluster/upgrade-downgrade/kubeadm-upgrade-1-7/ 301 +#/docs/tasks/administer-cluster/kubeadm-upgrade-1-8/ /docs/tasks/administer-cluster/upgrade-downgrade/kubeadm-upgrade-1-8/ 301 +#/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/ /docs/tasks/administer-cluster/upgrade-downgrade/kubeadm-upgrade-1-9/ 301 /docs/tasks/administer-cluster/kubeadm-upgrade-ha/ /docs/tasks/administer-cluster/upgrade-downgrade/kubeadm-upgrade-ha/ 301 /docs/tasks/administer-cluster/kube-router-network-policy/ /docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/ 301 /docs/tasks/administer-cluster/memory-constraint-namespace/ /docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/ 301 @@ -260,7 +244,7 @@ /docs/tasks/administer-cluster/running-cloud-controller.md /docs/tasks/administer-cluster/running-cloud-controller/ 301 /docs/tasks/administer-cluster/share-configuration/ /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ 301 /docs/tasks/administer-cluster/static-pod/ /docs/tasks/configure-pod-container/static-pod/ 301 -/docs/tasks/administer-cluster/upgrade-1-6/ /docs/tasks/administer-cluster/upgrade-downgrade/upgrade-1-6/ 301 +#/docs/tasks/administer-cluster/upgrade-1-6/ /docs/tasks/administer-cluster/upgrade-downgrade/upgrade-1-6/ 301 /docs/tasks/administer-cluster/weave-network-policy/ /docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/ 301 /docs/tasks/configure-pod-container/apply-resource-quota-limit/ /docs/tasks/administer-cluster/apply-resource-quota-limit/ 301 /docs/tasks/configure-pod-container/assign-cpu-ram-container/ /docs/tasks/configure-pod-container/assign-memory-resource/ 301 @@ -378,13 +362,13 @@ /docs/user-guide/kubeconfig-file/ /docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/ 301 /docs/user-guide/kubectl-overview/ /docs/reference/kubectl/overview/ /docs/user-guide/kubectl/ /docs/reference/generated/kubectl/kubectl-options/ -/docs/user-guide/kubectl/v1.8/* https://v1-8.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/:splat 301 -/docs/user-guide/kubectl/v1.9/* https://v1-9.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/:splat 301 -/docs/user-guide/kubectl/v1.10/* /docs/reference/generated/kubectl/kubectl-commands/:splat 301 +#/docs/user-guide/kubectl/v1.8/* https://v1-8.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/:splat 301 +#/docs/user-guide/kubectl/v1.9/* https://v1-9.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/:splat 301 +#/docs/user-guide/kubectl/v1.10/* /docs/reference/generated/kubectl/kubectl-commands/:splat 301 /docs/user-guide/kubectl-conventions/ /docs/reference/kubectl/conventions/ /docs/user-guide/kubectl-cheatsheet/ /docs/reference/kubectl/cheatsheet/ /docs/user-guide/kubectl/kubectl_*/ /docs/reference/generated/kubectl/kubectl-commands#:splat 301 -/docs/user-guide/kubectl/v1.6/node_modules/* https://v1-6.docs.kubernetes.io/docs/user-guide/kubectl/v1.6/ 301 +#/docs/user-guide/kubectl/v1.6/node_modules/* https://v1-6.docs.kubernetes.io/docs/user-guide/kubectl/v1.6/ 301 /docs/user-guide/labels/ /docs/concepts/overview/working-with-objects/labels/ 301 /docs/user-guide/liveness/ /docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ 301 /docs/user-guide/load-balancer/ /docs/tasks/access-application-cluster/create-external-load-balancer/ 301 @@ -445,25 +429,19 @@ /horizontal-pod-autoscaler/ /docs/tasks/run-application/horizontal-pod-autoscale/ 301 /kubernetes/ /docs/ 301 /kubernetes-bootcamp/* /docs/tutorials/kubernetes-basics/ 301 -/kubernetes/swagger-spec/ https://github.com/kubernetes/kubernetes/tree/master/api/swagger-spec/ 301 /kubernetes/third_party/swagger-ui/ /docs/reference/ 301 /latest/docs/ /docs/home/ 301 /media/ /docs/community 301 /news/ /docs/community 301 /resource-quota/ /docs/concepts/policy/resource-quotas/ 301 /serviceaccount/token/ /docs/tasks/configure-pod-container/configure-service-account/ 301 -/swagger-spec/* https://github.com/kubernetes/kubernetes/tree/master/api/swagger-spec/ 301 /third_party/swagger-ui/* /docs/reference/ 301 -/v1.1/docs/admin/networking.html /docs/concepts/cluster-administration/networking/ 301 - -https://kubernetes-io-v1-7.netlify.com/* https://v1-7.docs.kubernetes.io/:splat 301 /docs/admin/cloud-controller-manager/ /docs/reference/generated/cloud-controller-manager/ 301 /docs/admin/kube-apiserver/ /docs/reference/generated/kube-apiserver/ 301 /docs/admin/kube-controller-manager/ /docs/reference/generated/kube-controller-manager/ 301 /docs/admin/kube-proxy/ /docs/reference/generated/kube-proxy/ 301 /docs/admin/kube-scheduler/ /docs/reference/generated/kube-scheduler/ 301 -/docs/admin/kube-scheduler/ /docs/reference/generated/kube-scheduler/ 301 /docs/admin/kubeadm/ /docs/reference/generated/kubeadm/ 301 /docs/admin/kubelet/ /docs/reference/generated/kubelet/ 301 /docs/admin/federation-controller-manager/ /docs/reference/generated/federation-controller-manager/ 301 @@ -484,6 +462,7 @@ https://kubernetes-io-v1-7.netlify.com/* https://v1-7.docs.kubernetes.io/:spl /docs/admin/admission-controllers/ /docs/reference/access-authn-authz/admission-controllers/ 301 /docs/admin/authentication/ /docs/reference/access-authn-authz/authentication/ 301 /docs/admin/bootstrap-tokens/ /docs/reference/access-authn-authz/bootstrap-tokens/ 301 + /docs/admin/extensible-admission-controllers/ /docs/reference/access-authn-authz/extensible-admission-controllers/ 301 /docs/admin/service-accounts-admin/ /docs/reference/access-authn-authz/service-accounts-admin/ 301 /docs/admin/authorization/abac/ /docs/reference/access-authn-authz/abac/ 301 @@ -491,8 +470,7 @@ https://kubernetes-io-v1-7.netlify.com/* https://v1-7.docs.kubernetes.io/:spl /docs/admin/authorization/rbac/ /docs/reference/access-authn-authz/rbac/ 301 /docs/admin/authorization/webhook/ /docs/reference/access-authn-authz/webhook/ 301 /docs/admin/authorization/ /docs/reference/access-authn-authz/authorization/ 301 - -/docs/admin/high-availability/building/ /docs/setup/independent/high-availability/ 301 +/docs/admin/high-availability/building/ /docs/setup/production-environment/tools/kubeadm/high-availability/ 301 /code-of-conduct/ /community/code-of-conduct/ 301 /docs/setup/version-skew-policy/ /docs/setup/release/version-skew-policy/ 301 From 4ca2b2c3244694a899542eff7719875e36d24875 Mon Sep 17 00:00:00 2001 From: Karen Bradshaw Date: Thu, 19 Mar 2020 13:58:36 -0400 Subject: [PATCH 165/194] clean up css for tablet, nav (#19477) --- assets/sass/_base.sass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/assets/sass/_base.sass b/assets/sass/_base.sass index 2315ae5e94..c5a576995c 100644 --- a/assets/sass/_base.sass +++ b/assets/sass/_base.sass @@ -109,6 +109,7 @@ header box-shadow: 0 0 0 transparent transition: 0.3s text-align: center + overflow: hidden .logo @@ -244,8 +245,7 @@ header background-color: white #mainNav - display: none - + h5 color: $blue font-weight: normal From 60a265e6bdb62d51429d59ff434da40422c146df Mon Sep 17 00:00:00 2001 From: Lorenzo Paris Date: Thu, 19 Mar 2020 11:16:36 -0700 Subject: [PATCH 166/194] Update authentication.md with link to anon reqs (#19706) Suggest adding a link in case the reader is not familiar with what "anonymous requests" means. This paragraph also includes a reference to "anonymous user," so I think the link is warranted. Thanks. --- content/en/docs/reference/access-authn-authz/authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index 0089c08a91..cd941bcadb 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -33,7 +33,7 @@ stored as `Secrets`, which are mounted into pods allowing in-cluster processes to talk to the Kubernetes API. API requests are tied to either a normal user or a service account, or are treated -as anonymous requests. This means every process inside or outside the cluster, from +as [anonymous requests](#anonymous-requests). This means every process inside or outside the cluster, from a human user typing `kubectl` on a workstation, to `kubelets` on nodes, to members of the control plane, must authenticate when making requests to the API server, or be treated as an anonymous user. From e19f9121753447c1dbd435c7ffc60cc3b4a944e9 Mon Sep 17 00:00:00 2001 From: Alena Prokharchyk Date: Thu, 19 Mar 2020 12:08:36 -0700 Subject: [PATCH 167/194] Lease heartbeat: more description on error handling (#19673) --- content/en/docs/concepts/architecture/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 338e9a2408..97188ee9ad 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -184,7 +184,7 @@ a Lease object. timeout for unreachable nodes). - The kubelet creates and then updates its Lease object every 10 seconds (the default update interval). Lease updates occur independently from the - `NodeStatus` updates. + `NodeStatus` updates. If the Lease update fails, the kubelet retries with exponential backoff starting at 200 milliseconds and capped at 7 seconds. #### Reliability From 735259f7326e30191cf5826efafe2473b07b771c Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 19 Mar 2020 20:32:36 +0000 Subject: [PATCH 168/194] Fix ordering (#19729) Put entries in alphabetical order. Fixup for commit 55de25393429a94c92b98a883cbd30b0062c8eeb. --- i18n/en.toml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/i18n/en.toml b/i18n/en.toml index 48c0c5f469..c3a5ab69ae 100644 --- a/i18n/en.toml +++ b/i18n/en.toml @@ -58,6 +58,9 @@ other = "Was this page helpful?" [feedback_yes] other = "Yes" +[input_placeholder_email_address] +other = "email address" + [latest_version] other = "latest version." @@ -188,7 +191,4 @@ other = "To check the version, enter " other = "Warning:" [whatsnext_heading] -other = "What's next" - -[input_placeholder_email_address] -other = "email address" \ No newline at end of file +other = "What's next" \ No newline at end of file From 3b241356e50f05003bee139e6eb7b3376c17eeb1 Mon Sep 17 00:00:00 2001 From: Maciej Filocha <12587791+mfilocha@users.noreply.github.com> Date: Fri, 20 Mar 2020 11:14:36 +0100 Subject: [PATCH 169/194] Synchronize Polish translation with master (#19681) Update translated content to uptream master version as for March 15th. Commits from 90ee7559a0fcb73da45e2e5ce3fa2ee620f2cd2a to d4167faa2ce59612b36e4edcc7357c1a63131bbc. --- content/pl/_index.html | 4 +- content/pl/docs/concepts/_index.md | 2 +- .../pl/docs/concepts/overview/components.md | 8 +- .../docs/concepts/overview/kubernetes-api.md | 2 +- content/pl/docs/contribute/_index.md | 75 ++++++------------- content/pl/docs/reference/_index.md | 24 +++--- content/pl/docs/reference/glossary/cluster.md | 6 +- .../reference/glossary/container-runtime.md | 8 +- .../glossary/kube-controller-manager.md | 2 +- .../docs/reference/glossary/kube-scheduler.md | 4 +- content/pl/docs/setup/_index.md | 9 +-- content/pl/docs/tasks/_index.md | 4 - content/pl/docs/tutorials/_index.md | 2 - content/pl/docs/tutorials/hello-minikube.md | 31 ++++---- .../create-cluster/cluster-intro.html | 2 +- .../deploy-app/deploy-interactive.html | 9 +++ .../expose/expose-intro.html | 5 -- content/pl/examples/minikube/Dockerfile | 2 +- 18 files changed, 80 insertions(+), 119 deletions(-) diff --git a/content/pl/_index.html b/content/pl/_index.html index 4d7de6d3b4..4e55c429bd 100644 --- a/content/pl/_index.html +++ b/content/pl/_index.html @@ -45,12 +45,12 @@ Kubernetes jako projekt open-source daje Ci wolność wyboru ⏤ skorzystaj z pr


- Weź udział w KubeCon w Amsterdamie 30.03-2.04.2020 + Weź udział w KubeCon w Amsterdamie (lipiec/sierpień)



- Weź udział w KubeCon w Szanghaju 28-30.07.2020 + Weź udział w KubeCon w Bostonie 17-20.11.2020
diff --git a/content/pl/docs/concepts/_index.md b/content/pl/docs/concepts/_index.md index 8be3830b9c..3f147f5f43 100644 --- a/content/pl/docs/concepts/_index.md +++ b/content/pl/docs/concepts/_index.md @@ -26,7 +26,7 @@ Gdy tylko zdefiniujesz zamierzony stan, warstwa sterowania Kubernetes (*Kubernet ## Obiekty Kubernetes -Kubernetes składa się z różnych abstrakcyjnych obiektów, które reprezentują stan systemu: wdrożone aplikacje i zadania w kontenerach, powiązane zasoby sieciowe i dyskowe oraz inne informacje o tym, co się dzieje na klasterze. Te abstrakcyjne obiekty są reprezentowane przez API Kubernetes. [Opis Obiektów w Kubernetesie](/docs/concepts/overview/working-with-objects/kubernetes-objects/) zawiera więcej szczegółów na ten temat. +Kubernetes składa się z różnych abstrakcyjnych obiektów, które reprezentują stan systemu: wdrożone aplikacje i zadania w kontenerach, powiązane zasoby sieciowe i dyskowe oraz inne informacje o tym, co się dzieje na klasterze. Te abstrakcyjne obiekty są reprezentowane przez API Kubernetes. [Opis obiektów w Kubernetesie](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) zawiera więcej szczegółów na ten temat. Do podstawowych obiektów Kubernetes należą: diff --git a/content/pl/docs/concepts/overview/components.md b/content/pl/docs/concepts/overview/components.md index eda8ed7519..966f67b004 100644 --- a/content/pl/docs/concepts/overview/components.md +++ b/content/pl/docs/concepts/overview/components.md @@ -10,7 +10,7 @@ card: {{% capture overview %}} W wyniku instalacji Kubernetes otrzymujesz klaster. -{{< glossary_definition term_id="cluster" length="all" prepend="Klaster to">}} +{{< glossary_definition term_id="cluster" length="all" prepend="Klaster Kubernetes to">}} W tym dokumencie opisujemy składniki niezbędne do zbudowania kompletnego, poprawnie działającego klastra Kubernetes. @@ -20,11 +20,11 @@ Poniższy rysunek przedstawia klaster Kubernetes i powiązania pomiędzy jego r {{% /capture %}} {{% capture body %}} -## Master — częsci składowe +## Częsci składowe warstwy sterowania -Komponenty *master* odpowiadają za warstwę sterowania klastra. Podejmują ogólne decyzje dotyczące klastra (np. zlecanie zadań), wykrywają i reagują na zdarzenia w klastrze (przykładowo, start nowego {{< glossary_tooltip text="poda" term_id="pod">}}, kiedy wartość `replicas` dla deploymentu nie zgadza się z faktyczną liczbą replik). +Komponenty warstwy sterowania podejmują ogólne decyzje dotyczące klastra (np. zlecanie zadań), a także wykrywają i reagują na zdarzenia w klastrze (przykładowo, start nowego {{< glossary_tooltip text="poda" term_id="pod">}}, kiedy wartość `replicas` dla deploymentu nie zgadza się z faktyczną liczbą replik). -Komponenty *master* mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia skrypty instalacyjne zazwyczaj startują wszystkie składniki na tej samej maszynie i jednocześnie nie pozwalają na uruchamianie na niej kontenerów użytkowników. Na stronie [Tworzenie Wysoko Dostępnych Klastrów](/docs/admin/high-availability/) jest więcej informacji o konfiguracji typu *multi-master-VM*. +Komponenty warstwy sterowania mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia jednak skrypty instalacyjne zazwyczaj startują wszystkie składniki na tej samej maszynie i jednocześnie nie pozwalają na uruchamianie na niej kontenerów użytkowników. Na stronie [Tworzenie Wysoko Dostępnych Klastrów](/docs/admin/high-availability/) jest więcej informacji o konfiguracji typu *multi-master-VM*. ### kube-apiserver diff --git a/content/pl/docs/concepts/overview/kubernetes-api.md b/content/pl/docs/concepts/overview/kubernetes-api.md index 5813ada50e..eb86295321 100644 --- a/content/pl/docs/concepts/overview/kubernetes-api.md +++ b/content/pl/docs/concepts/overview/kubernetes-api.md @@ -57,7 +57,7 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github W Kubernetes zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o Protobuf, który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze i opisany w [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md). Pliki IDL dla każdego ze schematów można znaleźć w pakietach Go, które definiują obiekty API. Przed wersją 1.14, apiserver Kubernetes udostępniał też specyfikację API [Swagger v1.2](http://swagger.io/) poprzez `/swaggerapi`. -Ten punkt końcowy jest fazie wycofywania i zostanie ostatecznie usunięty w wersji Kubernetes 1.14. +Ten punkt końcowy został skierowany do wycofania i ostatecznie usunięty w wersji Kubernetes 1.14. ## Obsługa wersji API diff --git a/content/pl/docs/contribute/_index.md b/content/pl/docs/contribute/_index.md index ad2a2adb70..bd40241596 100644 --- a/content/pl/docs/contribute/_index.md +++ b/content/pl/docs/contribute/_index.md @@ -13,65 +13,38 @@ lub strony www Kubernetesa! Nieważne, czy dopiero poznajesz projekt, czy jeste z nami już od dawna, czy uważasz się za programistę, użytkownika, czy po prostu nie możesz patrzeć na literówki. -Więcej informacji na temat zawartości dokumentacji Kubernetesa i jej stylu, -znajdziesz w - [Opisie stylu dokumentacji](/docs/contribute/style/). +{{% /capture %}} {{% capture body %}} -## Rodzaje uczestnictwa w procesie tworzenia dokumentacji +## Od czego zacząć? -- _Członek_ (_member_) organizacji Kubernetes, który [podpisał CLA](/docs/contribute/start#sign-the-cla) - i poświęcił swój czas oraz wysiłek na rzecz projektu. Dokument - [Członkostwo w organizacji](https://github.com/kubernetes/community/blob/master/community-membership.md) - zawiera szczegóły z tym związane. -- _Recenzent_ (_reviewer_) SIG Docs to członek organizacji Kubernetes, który zgłosił - swoją chęć weryfikacji propozycji zmian w dokumentacji (PR) i został dodany - do odpowiedniej grupy GitHub i pliku 'OWNERS' w repozytorium GitHub przez - osobę zatwierdzającą SIG Docs. -- _Osoba zatwierdzająca_ (_approver_) SIG Docs to członek organizacji o uznanej reputacji, - który wykazał się długotrwałym zaangażowaniem w prace projektu. - Osoba zatwierdzająca może włączać propozycje zmian do repozytoriów i publikować - treści w imieniu organizacji Kubernetes. - Osoby zatwierdzające mogą również reprezentować SIG Docs na szerszym forum - społeczności Kubernetes. - Niektóre wymagania związane z tą rolą, jak na przykład koordynacja kolejnego wydania, - wymagają poświęcenia znacznej ilości czasu. +Każdy może otworzyć zgłoszenie, które zawiera opis problemu czy oczekiwane usprawnienia dokumentacji lub samemu zaproponować zmianę poprzez *pull request* (PR). +Do realizacji niektórych zadań potrzeba wyższego poziomu zaufania i odpowiednich uprawnień w organizacji Kubernetes. +Zajrzyj do [Participating in SIG Docs](/docs/contribute/participating/) po więcej szczegółów +dotyczących ról i uprawnień. -## Sposoby współpracy przy tworzeniu dokumentacji +Dokumentacja Kubernetesa znajduje się w repozytorium GitHub. Zapraszamy wszystkich +do aktywnych działań na rzecz jej rozwoju, niemniej aby móc sprawnie funkcjonować w społeczności Kubernetes, +wymagana jest pewna biegłość w korzystaniu z git i GitHuba. -Poniższa lista podzielona jest na rzeczy, które może robić każdy, te, które może -robić członek organizacji Kubernetes oraz na takie, które wymagają wyższych uprawnień -i znajomości procesów SIG Docs. W miarę postępującej współpracy, będziesz mógł lepiej -zrozumieć niektóre narzędzia czy decyzje, które zostały wcześniej podjęte -na poziomie organizacyjnym. +Aby zaangażować się w prace nad dokumentacją należy: -Ta lista nie wyczerpuje wszystkich możliwości udziału, ale powinna być pomocna -na początku. +1. Podpisać [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md) CNCF. +2. Zapoznać się z [repozytorium dokumentacji](https://github.com/kubernetes/website) i z [generatorem statycznej strony](https://gohugo.io) www. +3. Zrozumieć podstawowe procesy [ulepszania zawartości](https://kubernetes.io/docs/contribute/start/#improve-existing-content) i [recenzowania propozycji zmian](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests). + +## Najlepsze praktyki zgłaszania zmian + +- Opis GIT commit powinien być jasny i zrozumiały. +- Należy używać _Github Special Keywords_, które odwołują się do zgłoszenia _(issue)_ i automatycznie je zamykają, kiedy PR zostaje zaakceptowany. +- Kiedy wprowadzasz drobne zmiany do PR, takie jak literówki czy poprawki stylu lub gramatyki, pamiętaj o ich zgrupowaniu _(squash)_, aby uniknąć sytuacji, kiedy mamy dużą liczbę commitów dla stosunkowo niewielkiej zmiany. +- Dołącz dobry opis PR, który tłumaczy zmiany w kodzie, powód dla tych zmian i wszystkie informacje wystarczające, aby recenzent zrozumiał Twój PR. +- Dodatkowa literatura: + - [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/) + - [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests) + - [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git ) -- [Każdy](/docs/contribute/start/) - - Otwieranie wszelkiego rodzaju zgłoszeń, względem których mogą zostać podjęte jakieś działania -- [Członek](/docs/contribute/start/) - - Ulepszanie istniejącej dokumentacji - - Zgłaszanie pomysłów na ulepszenia poprzez komunikator [Slack](http://slack.k8s.io/) lub [listę dystrybucyjną SIG docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) - - Zwiększanie dostępności dokumentacji - - Zgłaszanie niewiążących uwag do propozycji zmian (PR) - - Pisanie bloga lub studium przypadku -- [Recenzent](/docs/contribute/intermediate/) - - Opisywanie nowych funkcjonalności - - Przydzielanie kategorii i klasyfikowanie zgłoszeń - - Recenzowanie propozycji zmian - - Tworzenie schematów, grafik, osadzonych prezentacji (_screencasts_) i filmów - - Tłumaczenie - - Współtworzenie zawartości innych repozytoriów jako przedstawiciel zespołu dokumentacji - - Opracowywanie osadzonych w oprogramowaniu komunikatów dla użytkownika - - Ulepszanie komentarzy w oprogramowaniu, Godoc -- [Osoba zatwierdzająca](/docs/contribute/advanced/) - - Publikowanie dostarczonych treści poprzez zatwierdzanie propozycji zmian i włączanie ich do repozytorium - - Udział w pracach zespołu przygotowującego nowe wydanie Kubernetesa jako przedstawiciel zespołu dokumentacji - - Proponowanie ulepszeń wytycznych dotyczących stylu - - Proponowanie ulepszeń testowania dokumentacji - - Proponowanie ulepszeń strony Kubernetes lub innych narzędzi ## Inne metody współpracy diff --git a/content/pl/docs/reference/_index.md b/content/pl/docs/reference/_index.md index 92177da44b..41a213e5e3 100644 --- a/content/pl/docs/reference/_index.md +++ b/content/pl/docs/reference/_index.md @@ -17,12 +17,7 @@ Tutaj znajdziesz dokumentację źródłową Kubernetes. ## Dokumentacja API * [Kubernetes API Overview](/docs/reference/using-api/api-overview/) - Ogólne informacje na temat Kubernetes API. -* Wersje Kubernetes API - * [1.17](/docs/reference/generated/kubernetes-api/v1.17/) - * [1.16](/docs/reference/generated/kubernetes-api/v1.16/) - * [1.15](/docs/reference/generated/kubernetes-api/v1.15/) - * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) - * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) + * [Dokumentacja źródłowa Kubernetes API {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) ## Biblioteki klientów API @@ -37,18 +32,17 @@ biblioteki to: ## Dokumentacja poleceń tekstowych *(CLI)* -* [kubectl](/docs/user-guide/kubectl-overview) - Główne narzędzie tekstowe (linii poleceń) do zarządzania klastrem Kubernetes. - * [JSONPath](/docs/user-guide/jsonpath/) - Podręcznik składni [wyrażeń JSONPath](http://goessner.net/articles/JsonPath/) dla kubectl. -* [kubeadm](/docs/admin/kubeadm/) - Narzędzie tekstowe do łatwego budowania klastra Kubernetes spełniającego niezbędne wymogi bezpieczeństwa. -* [kubefed](/docs/admin/kubefed/) - Narzędzie tekstowe poleceń do zarządzania klastrami w federacji. +* [kubectl](/docs/reference/kubectl/overview/) - Główne narzędzie tekstowe (linii poleceń) do zarządzania klastrem Kubernetes. + * [JSONPath](/docs/reference/kubectl/jsonpath/) - Podręcznik składni [wyrażeń JSONPath](http://goessner.net/articles/JsonPath/) dla kubectl. +* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - Narzędzie tekstowe do łatwego budowania klastra Kubernetes spełniającego niezbędne wymogi bezpieczeństwa. ## Dokumentacja konfiguracji -* [kubelet](/docs/admin/kubelet/) - Główny agent działający na każdym węźle. Kubelet pobiera zestaw definicji PodSpecs i gwarantuje, że opisane przez nie kontenery poprawnie działają. -* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API, które sprawdza poprawność i konfiguruje obiekty API, takie jak pody, serwisy czy kontrolery replikacji. -* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Proces wykonujący główne pętle sterowania Kubernetes. -* [kube-proxy](/docs/admin/kube-proxy/) - Przekazuje bezpośrednio dane przepływające w transmisji TCP/UDP lub dystrybuuje ruch TCP/UDP zgodnie ze schematem *round-robin* pomiędzy usługi back-endu. -* [kube-scheduler](/docs/admin/kube-scheduler/) - Scheduler odpowiada za dostępność, wydajność i zasoby. +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - Główny agent działający na każdym węźle. Kubelet pobiera zestaw definicji PodSpecs i gwarantuje, że opisane przez nie kontenery poprawnie działają. +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - REST API, które sprawdza poprawność i konfiguruje obiekty API, takie jak pody, serwisy czy kontrolery replikacji. +* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Proces wykonujący główne pętle sterowania Kubernetes. +* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - Przekazuje bezpośrednio dane przepływające w transmisji TCP/UDP lub dystrybuuje ruch TCP/UDP zgodnie ze schematem *round-robin* pomiędzy usługi back-endu. +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - Scheduler odpowiada za dostępność, wydajność i zasoby. ## Dokumentacja projektowa diff --git a/content/pl/docs/reference/glossary/cluster.md b/content/pl/docs/reference/glossary/cluster.md index 0021caefe0..650db52c3d 100755 --- a/content/pl/docs/reference/glossary/cluster.md +++ b/content/pl/docs/reference/glossary/cluster.md @@ -4,14 +4,14 @@ id: cluster date: 2019-06-15 full_link: short_description: > - Zestaw maszyn, nazywanych węzłami, na których uruchamiane są aplikacje zarządzane przez Kubernetes. Klaster posiada przynajmniej jeden węzeł roboczy (*node*) i jeden węzeł typu master (*master node*). + Zestaw maszyn roboczych, nazywanych węzłami, na których uruchamiane są aplikacje w kontenerach. Każdy klaster musi posiadać przynajmniej jeden węzeł. aka: tags: - fundamental - operation --- -Zestaw maszyn, nazywanych węzłami, na których uruchamiane są aplikacje zarządzane przez Kubernetes. Klaster posiada przynajmniej jeden węzeł roboczy (*node*) i jeden węzeł typu master (*master node*). +Zestaw maszyn roboczych, nazywanych węzłami, na których uruchamiane są aplikacje w kontenerach. Każdy klaster musi posiadać przynajmniej jeden węzeł. -Na węźle (lub węzłach) roboczych rozmieszczane są pody, które są częściami składowymi aplikacji. Węzeł (lub węzły) typu master zarządzają węzłami roboczymi i podami należącymi do klastra. Zwielokrotnione węzły typu master zapewniają większą niezawodność i odporność klastra na awarie. +Na węźle (lub węzłach) roboczych rozmieszczane są pody, które są częściami składowymi aplikacji. Warstwa sterowania zarządza węzłami roboczymi i podami należącymi do klastra. W środowisku produkcyjnym warstwa sterowania rozłożona jest zazwyczaj na kilka maszyn, a klaster uruchomiony jest na wielu węzłach zapewniając większą niezawodność i odporność na awarie. diff --git a/content/pl/docs/reference/glossary/container-runtime.md b/content/pl/docs/reference/glossary/container-runtime.md index 804e367a70..170d500221 100644 --- a/content/pl/docs/reference/glossary/container-runtime.md +++ b/content/pl/docs/reference/glossary/container-runtime.md @@ -15,7 +15,7 @@ tags: -Kubernetes obsługuje różne *container runtimes*: [Docker](http://www.docker.com), -[containerd](https://containerd.io), [cri-o](https://cri-o.io/), -[rktlet](https://github.com/kubernetes-incubator/rktlet) oraz każdą implementację zgodną z -[Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). +Kubernetes obsługuje różne *container runtimes*: {{< glossary_tooltip term_id="docker">}}, +{{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}} +oraz każdą implementację zgodną z [Kubernetes CRI (Container Runtime +Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). diff --git a/content/pl/docs/reference/glossary/kube-controller-manager.md b/content/pl/docs/reference/glossary/kube-controller-manager.md index 4a3a4e64b5..cd1ac2adfa 100755 --- a/content/pl/docs/reference/glossary/kube-controller-manager.md +++ b/content/pl/docs/reference/glossary/kube-controller-manager.md @@ -11,7 +11,7 @@ tags: - architecture - fundamental --- - Składnik *master* odpowiedzialny za uruchamianie {{< glossary_tooltip text="kontrolerów" term_id="controller" >}}. + Składnik warstwy sterowania odpowiedzialny za uruchamianie {{< glossary_tooltip text="kontrolerów" term_id="controller" >}}. diff --git a/content/pl/docs/reference/glossary/kube-scheduler.md b/content/pl/docs/reference/glossary/kube-scheduler.md index 074680ac02..6382cb0d6f 100755 --- a/content/pl/docs/reference/glossary/kube-scheduler.md +++ b/content/pl/docs/reference/glossary/kube-scheduler.md @@ -4,13 +4,13 @@ id: kube-scheduler date: 2018-04-12 full_link: /docs/reference/generated/kube-scheduler/ short_description: > - Składnik *master*, który monitoruje tworzenie nowych podów i przypisuje im węzły, na których powinny zostać uruchomione. + Składnik warstwy sterowania, który śledzi tworzenie nowych podów i przypisuje im węzły, na których powinny zostać uruchomione. aka: tags: - architecture --- -Składnik *master*, który monitoruje tworzenie nowych podów i przypisuje im węzły, na których powinny zostać uruchomione. +Składnik warstwy sterowania, który śledzi tworzenie nowych podów i przypisuje im węzły, na których powinny zostać uruchomione. diff --git a/content/pl/docs/setup/_index.md b/content/pl/docs/setup/_index.md index 0d0fde34b8..5c89d184d3 100644 --- a/content/pl/docs/setup/_index.md +++ b/content/pl/docs/setup/_index.md @@ -37,13 +37,12 @@ Aby uruchomić klaster Kubernetes do nauki na lokalnym komputerze, skorzystaj z |Społeczność |Ekosystem | | ------------ | -------- | | [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) | -| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| +| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| | | [Minishift](https://docs.okd.io/latest/minishift/)| | | [MicroK8s](https://microk8s.io/)| | | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) | | | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)| | | [k3s](https://k3s.io)| -| | [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/)| ## Środowisko produkcyjne {#srodowisko-produkcyjne} @@ -76,8 +75,6 @@ Poniższa tabela zawiera przegląd dostawców środowisk produkcyjnych i rozwią | [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔ | [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | | | [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔ -| [Fedora (Multi Node)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)  | | | | | ✔ | ✔ -| [Fedora (Single Node)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)  | | | | | | ✔ | [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ | ✔ | ✔ | [Custom Extensions](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) | | [Giant Swarm](https://www.giantswarm.io/) | ✔ | ✔ | ✔ | | | [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | | @@ -85,12 +82,13 @@ Poniższa tabela zawiera przegląd dostawców środowisk produkcyjnych i rozwią | [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | | | [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | | | [KubeOne](https://kubeone.io/) | | ✔ | ✔ | ✔ | ✔ | ✔ | -| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | | +| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | | [KubeSail](https://kubesail.com/) | ✔ | | | | | | [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ | | [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ | | [Microsoft Azure](https://azure.microsoft.com) | [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/) | | | | | | [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) | | | ✔ | | | +| [NetApp Kubernetes Service (NKS)](https://cloud.netapp.com/kubernetes-service) | ✔ | ✔ | ✔ | | | | [Nirmata](https://www.nirmata.com/) | | ✔ | ✔ | | | | [Nutanix](https://www.nutanix.com/en) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | | | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization) | | [OpenNebula](https://www.opennebula.org) |[OpenNebula Kubernetes](https://marketplace.opennebula.systems/docs/service/kubernetes.html) | | | | | @@ -100,7 +98,6 @@ Poniższa tabela zawiera przegląd dostawców środowisk produkcyjnych i rozwią | [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | | | | [Platform9](https://platform9.com/) | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | ✔ | ✔ | ✔ | [Rancher](https://rancher.com/) | | [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/) | | [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) | | [k3s](https://k3s.io/) -| [StackPoint](https://stackpoint.io/)  | ✔ | ✔ | | | | | [Supergiant](https://supergiant.io/) | |✔ | | | | | [SUSE](https://www.suse.com/) | | ✔ | | | | | [SysEleven](https://www.syseleven.io/) | ✔ | | | | | diff --git a/content/pl/docs/tasks/_index.md b/content/pl/docs/tasks/_index.md index 1d96d99a0b..253cd26cd2 100644 --- a/content/pl/docs/tasks/_index.md +++ b/content/pl/docs/tasks/_index.md @@ -57,10 +57,6 @@ Konfigurowanie aplikacji w taki sposób, aby korzystała i ufała łańcuchowi c Standardowe metody zarządzania klasterem. -## Administracja federacją - -Konfigurowanie federacji klastrów. - ## Zarządzanie aplikacjami ze stanem (_Stateful_) Popularne zadania związane z zarządzaniem aplikacjami stanowymi _(Stateful)_, w tym: skalowanie, usuwanie i rozwiązywanie problemów dotyczących _StatefulSets_. diff --git a/content/pl/docs/tutorials/_index.md b/content/pl/docs/tutorials/_index.md index 6005968936..0723c6f4a4 100644 --- a/content/pl/docs/tutorials/_index.md +++ b/content/pl/docs/tutorials/_index.md @@ -22,8 +22,6 @@ Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do * [Podstawy Kubernetes](/docs/tutorials/kubernetes-basics/) to interaktywny samouczek, który pomoże zrozumieć system Kubernetes i wypróbować jego podstawowe możliwości. -* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) - * [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) * [Hello Minikube](/docs/tutorials/hello-minikube/) diff --git a/content/pl/docs/tutorials/hello-minikube.md b/content/pl/docs/tutorials/hello-minikube.md index f962199317..1a7da3cd3c 100644 --- a/content/pl/docs/tutorials/hello-minikube.md +++ b/content/pl/docs/tutorials/hello-minikube.md @@ -8,7 +8,7 @@ menu: weight: 10 post: >

Jesteś gotowy ubrudzić ręce? Zbuduj własny klaster kubernetes z działającą na nim aplikacją "Hello World" w Node.js.

-card: +card: name: tutorials weight: 10 --- @@ -49,7 +49,7 @@ Więcej informacji na temat polecenia `docker build` znajdziesz w [dokumentacji ## Stwórz klaster Minikube -1. Kliknij w **Launch Terminal** +1. Kliknij w **Launch Terminal** {{< kat-button >}} @@ -117,7 +117,7 @@ wykorzystując podany obraz Dockera. ```shell kubectl config view ``` - + {{< note >}}Więcej informacji na temat polecenia `kubectl` znajdziesz w [przeglądzie kubectl](/docs/user-guide/kubectl-overview/).{{< /note >}} ## Stwórz Serwis @@ -167,7 +167,7 @@ musisz najpierw wystawić Pod jako [*Serwis*](/docs/concepts/services-networking ## Włącz dodatki -Minikube ma zestaw wbudowanych dodatków, które mogą być włączane, wyłączane i otwierane w lokalnym środowisku Kubernetes. +Minikube ma zestaw wbudowanych {{< glossary_tooltip text="dodatków" term_id="addons" >}}, które mogą być włączane, wyłączane i otwierane w lokalnym środowisku Kubernetes. 1. Lista aktualnie obsługiwanych dodatków: @@ -184,7 +184,6 @@ Minikube ma zestaw wbudowanych dodatków, które mogą być włączane, wyłącz efk: disabled freshpod: disabled gvisor: disabled - heapster: disabled helm-tiller: disabled ingress: disabled ingress-dns: disabled @@ -198,16 +197,16 @@ Minikube ma zestaw wbudowanych dodatków, które mogą być włączane, wyłącz storage-provisioner-gluster: disabled ``` -2. Włącz dodatek, na przykład `heapster`: +2. Włącz dodatek, na przykład `metrics-server`: ```shell - minikube addons enable heapster + minikube addons enable metrics-server ``` - + Wynik powinien wyglądać podobnie do: ``` - heapster was successfully enabled + metrics-server was successfully enabled ``` 3. Sprawdź Pod i Serwis, który właśnie stworzyłeś: @@ -222,7 +221,7 @@ Minikube ma zestaw wbudowanych dodatków, które mogą być włączane, wyłącz NAME READY STATUS RESTARTS AGE pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m - pod/heapster-9jttx 1/1 Running 0 26s + pod/metrics-server-67fb648c5 1/1 Running 0 26s pod/etcd-minikube 1/1 Running 0 34m pod/influxdb-grafana-b29w8 2/2 Running 0 26s pod/kube-addon-manager-minikube 1/1 Running 0 34m @@ -233,23 +232,23 @@ Minikube ma zestaw wbudowanych dodatków, które mogą być włączane, wyłącz pod/storage-provisioner 1/1 Running 0 34m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - service/heapster ClusterIP 10.96.241.45 80/TCP 26s + service/metrics-server ClusterIP 10.96.241.45 80/TCP 26s service/kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP 34m service/monitoring-grafana NodePort 10.99.24.54 80:30002/TCP 26s service/monitoring-influxdb ClusterIP 10.111.169.94 8083/TCP,8086/TCP 26s ``` -4. Wyłącz dodatek `heapster`: +4. Wyłącz dodatek `metrics-server`: ```shell - minikube addons disable heapster + minikube addons disable metrics-server ``` - + Wynik powinien wyglądać podobnie do: ``` - heapster was successfully disabled + heapster was successfully metrics-server ``` ## Porządkujemy po sobie @@ -278,7 +277,7 @@ minikube delete {{% capture whatsnext %}} * Dowiedz się więcej o [obiektach typu Deployment](/docs/concepts/workloads/controllers/deployment/). -* Dowiedz się więcej o [instalowaniu aplikacji](/docs/user-guide/deploying-applications/). +* Dowiedz się więcej o [instalowaniu aplikacji](/docs/tasks/run-application/run-stateless-application-deployment/). * Dowiedz się więcej o [obiektach typu Serwis](/docs/concepts/services-networking/service/). {{% /capture %}} diff --git a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index 64b9336dec..df3b93c61b 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -84,7 +84,7 @@ weight: 10
-

Kiedy instalujesz aplikację na Kubernetes, polecasz masterowi uruchomienie kontenera z aplikacją. Master zleca uruchomienie kontenera na węzłach klastra. Węzły komunikują się z masterem przy użyciu Kubernetes API, wystawianego przez mastera. Użytkownicy końcowi mogą korzystać bezpośrednio z Kubernetes API do komunikacji z klastrem.

+

Kiedy instalujesz aplikację na Kubernetes, polecasz masterowi uruchomienie kontenera z aplikacją. Master zleca uruchomienie kontenera na węzłach klastra. Węzły komunikują się z masterem przy użyciu Kubernetes API, wystawianego przez mastera. Użytkownicy końcowi mogą korzystać bezpośrednio z Kubernetes API do komunikacji z klastrem.

Klaster Kubernetes może być zainstalowany zarówno na fizycznych, jak i na maszynach wirtualnych. Aby wypróbować Kubernetes, można też wykorzystać Minikube. Minikube to "lekka" implementacja Kubernetes, która tworzy VM na maszynie lokalnej i instaluje prosty klaster składający się tylko z jednego węzła. Minikube jest dostępne na systemy Linux, macOS i Windows. Narzędzie linii poleceń Minikube obsługuje podstawowe operacje na klastrze, takie jak start, stop, informacje o stanie i usunięcie klastra. Na potrzeby tego samouczka wykorzystamy jednak terminal online z zainstalowanym już wcześniej Minikube.

diff --git a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index be179683c1..ea083b33e7 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -17,7 +17,16 @@ weight: 20
+
+
+

+ Pod to podstawowy element odpowiedzialny za uruchomienie aplikacji na Kubernetesie. Każdy pod to część składowa całościowego obciążenia Twojego klastra. Dowiedz się więcej na temat Podów. +

+
+
+
+
Do pracy z terminalem użyj wersji na desktop/tablet diff --git a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 2dd9a35e99..d3fa9a8343 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -81,11 +81,6 @@ weight: 10
-
-
-

Możemy połączyć tworzenie Deploymentu i Serwisu stosując opcję
--expose w kubectl.

-
-

diff --git a/content/pl/examples/minikube/Dockerfile b/content/pl/examples/minikube/Dockerfile index 1fe745295a..dd58cb7e75 100644 --- a/content/pl/examples/minikube/Dockerfile +++ b/content/pl/examples/minikube/Dockerfile @@ -1,4 +1,4 @@ FROM node:6.14.2 EXPOSE 8080 COPY server.js . -CMD node server.js +CMD [ "node", "server.js" ] From 9df5b4ec4cf42853e94e5fc03d9b6b6fc1fc07d8 Mon Sep 17 00:00:00 2001 From: Danni Setiawan Date: Fri, 20 Mar 2020 18:50:36 +0700 Subject: [PATCH 170/194] Add ID translation for Labels (#19072) --- .../overview/working-with-objects/labels.md | 225 ++++++++++++++++++ 1 file changed, 225 insertions(+) create mode 100644 content/id/docs/concepts/overview/working-with-objects/labels.md diff --git a/content/id/docs/concepts/overview/working-with-objects/labels.md b/content/id/docs/concepts/overview/working-with-objects/labels.md new file mode 100644 index 0000000000..0b6060e2fd --- /dev/null +++ b/content/id/docs/concepts/overview/working-with-objects/labels.md @@ -0,0 +1,225 @@ +--- +title: Label dan Selektor +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} + +_Label_ merupakan pasangan _key/value_ yang melekat pada objek-objek, misalnya pada Pod. +Label digunakan untuk menentukan atribut identitas dari objek agar memiliki arti dan relevan bagi para pengguna, namun tidak secara langsung memiliki makna terhadap sistem inti. +Label dapat digunakan untuk mengatur dan memilih sebagian dari banyak objek. Label-label dapat ditempelkan ke objek-objek pada saat dibuatnya objek-objek tersebut dan kemudian ditambahkan atau diubah kapan saja setelahnya. +Setiap objek dapat memiliki satu set label _key/value_. Setiap _Key_ harus unik untuk objek tersebut. + +```json +"metadata": { + "labels": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + +Label memungkinkan untuk menjalankan kueri dan pengamatan dengan efisien, serta ideal untuk digunakan pada UI dan CLI. Informasi yang tidak digunakan untuk identifikasi sebaiknya menggunakan [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/). + +{{% /capture %}} + + +{{% capture body %}} + +## Motivasi + +Label memungkinkan pengguna untuk memetakan struktur organisasi mereka ke dalam objek-objek sistem yang tidak terikat secara erat, tanpa harus mewajibkan klien untuk menyimpan pemetaan tersebut. + +_Service deployments_ dan _batch processing pipelines_ sering menjadi entitas yang berdimensi ganda (contohnya partisi berganda atau _deployment_, jalur rilis berganda, tingkatan berganda, _micro-services_ berganda per tingkatan). Manajemen seringkali membutuhkan operasi lintas tim, yang menyebabkan putusnya enkapsulasi dari representasi hierarki yang ketat, khususnya pada hierarki-hierarki kaku yang justru ditentukan oleh infrastruktur, bukan oleh pengguna. + +Contoh label: + + * `"release" : "stable"`, `"release" : "canary"` + * `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"` + * `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"` + * `"partition" : "customerA"`, `"partition" : "customerB"` + * `"track" : "daily"`, `"track" : "weekly"` + +Ini hanya contoh label yang biasa digunakan; kamu bebas mengembangkan caramu sendiri. Perlu diingat bahwa _Key_ dari label harus unik untuk objek tersebut. + +## Sintaksis dan set karakter + +_Label_ merupakan pasangan _key/value_. _Key-key_ dari Label yang valid memiliki dua segmen: sebuah prefiks dan nama yang opsional, yang dipisahkan oleh garis miring (`/`). Segmen nama wajib diisi dan tidak boleh lebih dari 63, dimulai dan diakhiri dengan karakter alfanumerik (`[a-z0-9A-Z]`) dengan tanda pisah (`-`), garis bawah (`_`), titik (`.`), dan alfanumerik di antaranya. Sedangkan prefiks bersifat opsional. Jika ditentukan, prefiks harus berupa subdomain DNS: rangkaian label DNS yang dipisahkan oleh titik (`.`), dengan total tidak lebih dari 253 karakter, yang diikuti oleh garis miring (`/`). + +Jika prefiks dihilangkan, _Key_ dari label diasumsikan privat bagi pengguna. Komponen sistem otomatis (contoh `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, atau otomasi pihak ketiga lainnya) yang akan menambah label ke objek-objek milik pengguna akhir harus menentukan prefiks. + +Prefiks `kubernetes.io/` dan `k8s.io/` dikhususkan untuk komponen inti Kubernetes. + +Nilai label yang valid tidak boleh lebih dari 63 karakter dan harus kosong atau diawali dan diakhiri dengan karakter alfanumerik (`[a-z0-9A-Z]`) dengan tanda pisah (`-`), garis bawah (`_`), titik (`.`), dan alfanumerik di antaranya. + +Contoh di bawah ini merupakan berkas konfigurasi untuk Pod yang memiliki dua label `environment: production` dan `app: nginx` : + +```yaml + +apiVersion: v1 +kind: Pod +metadata: + name: label-demo + labels: + environment: production + app: nginx +spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 + +``` + +## Selektor label + +Tidak seperti [nama dan UID](/id/docs/concepts/overview/working-with-objects/names/), label tidak memberikan keunikan. Secara umum, kami memperkirakan bahwa banyak objek yang akan memiliki label yang sama. + +Menggunakan sebuah _label selector_, klien/pengguna dapat mengidentifikasi suatu kumpulan objek. Selektor label merupakan alat/cara pengelompokan utama pada Kubernetes. + +Saat ini API mendukung dua jenis selektor: _equality-based_ dan _set-based_. +Sebuah selektor label dapat dibuat dari kondisi berganda yang dipisahkan oleh koma. Pada kasus kondisi berganda, semua kondisi harus dipenuhi sehingga separator koma dapat bertindak sebagai operator logika _AND_ (`&&`). + +Makna dari selektor yang kosong atau tidak diisi tergantung dari konteks, dan tipe API yang menggunakan selektor harus mendokumentasikan keabsahan dan arti dari selektor yang kosong tersebut. + +{{< note >}} +Untuk beberapa tipe API, seperti ReplicaSet, selektor label untuk dua objek tidak boleh tumpang tindih dengan Namespace, jika tidak maka _controller_ akan melihatnya sebagai instruksi yang menyebabkan konflik dan akan gagal menentukan berapa banyak replika yang seharusnya tersedia. +{{< /note >}} + +{{< caution >}} +Untuk kedua kondisi _equality-based_ dan _set-based_ tidak ada logika operator _OR_ (`||`). Pastikan struktur pernyataan filter kamu ikut disesuaikan. +{{< /caution >}} + +### Kondisi _Equality-based_ + +Kondisi _Equality-based_ atau _inequality-based_ memungkinkan untuk melakukan filter dengan menggunakan _key_ dan _value_ dari label. Objek yang cocok harus memenuhi semua batasan label yang telah ditentukan, meskipun mereka dapat memiliki label tambahan lainnya. +Terdapat tiga jenis operator yang didukung yaitu `=`,`==`,`!=`. Dua operator pertama menyatakan kesamaan (keduanya hanyalah sinonim), sementara operator terakhir menyatakan ketidaksamaan. Contoh: + +``` +environment = production +tier != frontend +``` + +Kondisi pertama akan memilih semua sumber daya dengan _key_ `environment` dan nilai _key_ `production`. +Kondisi berikutnya akan memilih semua sumber daya dengan _key_ `tier` dan nilai _key_ selain `frontend`, dan semua sumber daya yang tidak memiliki label dengan _key_ `tier`. +Kamu juga dapat memfilter sumber daya dalam `production` selain `frontend` dengan menggunakan operator koma: `environment=production,tier!=frontend` + +Salah satu skenario penggunaan label dengan kondisi _equality-based_ yaitu untuk kriteria pemilihan Node untuk Pod-Pod. Sebagai contoh, Pod percontohan di bawah ini akan memilih Node dengan label "`accelerator=nvidia-tesla-p100`". + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: cuda-test +spec: + containers: + - name: cuda-test + image: "k8s.gcr.io/cuda-vector-add:v0.1" + resources: + limits: + nvidia.com/gpu: 1 + nodeSelector: + accelerator: nvidia-tesla-p100 +``` + +### Kondisi _Set-based_ + +Kondisi label _Set-based_ memungkinkan memfilter _key_ terhadap suatu kumpulan nilai. Terdapat tiga jenis operator yang didukung, yaitu: `in`,`notin`, dan `exists` (hanya _key_-nya saja). Contoh: + +``` +environment in (production, qa) +tier notin (frontend, backend) +partition +!partition +``` + +Contoh pertama akan memilih semua sumber daya dengan _key_ `environment` dan nilai `production` atau `qa`. +Contoh kedua akan memilih semua sumber daya dengan _key_ `tier` dan nilai selain `frontend` dan `backend`, serta semua sumber daya yang tidak memiliki label dengan _key_ `tier`. +Contoh ketiga akan memilih semua sumber daya yang memiliki _key_ dari label`partition`; nilainya tidak diperiksa. +Sedangkan contoh keempat akan memilih semua sumber daya yang tidak memiliki label dengan _key_ `partition`; nilainya tidak diperiksa. +Secara serupa, operator koma bertindak sebagai operator _AND_. Sehingga penyaringan sumber daya dengan _key_ `partition` (tidak peduli nilai dari _key_) dan `environment` yang tidak sama dengan `qa` dapat dicapai dengan `partition,environment notin (qa)`. +Selektor label _set-based_ merupakan bentuk umum persamaan karena `environment=production` sama dengan `environment in (production)`; demikian pula `!=` dan `notin`. + +Kondisi _Set-based_ dapat digabungkan dengan kondisi _equality-based_. Contoh: `partition in (customerA, customerB),environment!=qa`. + + +## API + +### Penyaringan LIST dan WATCH + +Operasi LIST dan WATCH dapat menentukan selektor label untuk memfilter suatu kumpulan objek yang didapat dengan menggunakan parameter kueri. Kedua jenis kondisi diperbolehkan (ditampilkan sebagai berikut, sama seperti saat tampil pada string kueri di URL): + + * Kondisi _equality-based_: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` + * Kondisi _set-based_: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` + +Kedua jenis selektor label dapat digunakan untuk menampilkan (_list_) dan mengamati (_watch_) sumber daya melalui klien REST. Contohnya, menargetkan `apiserver` dengan `kubectl` dan menggunakan _equality-based_ kamu dapat menuliskan: + +```shell +kubectl get pods -l environment=production,tier=frontend +``` + +atau menggunakan kondisi _set-based_: + +```shell +kubectl get pods -l 'environment in (production),tier in (frontend)' +``` + +Seperti yang telah disebutkan sebelumnya, kondisi _set-based_ lebih ekspresif. Sebagai contoh, mereka dapat digunakan untuk mengimplementasi operator _OR_ pada nilai: + +```shell +kubectl get pods -l 'environment in (production, qa)' +``` + +atau membatasi pencocokan negatif dengan operator _exists_: + +```shell +kubectl get pods -l 'environment,environment notin (frontend)' +``` + +### Mengatur referensi pada objek API + +Pada beberapa objek Kubernetes, seperti [`Service`](/docs/user-guide/services) dan [`ReplicationController`](/id/docs/concepts/workloads/controllers/replicationcontroller/), juga menggunakan selektor label untuk menentukan kumpulan dari sumber daya lain, seperti [Pod](/id/docs/concepts/workloads/pods/pod). + +#### Service dan ReplicationController + +Kumpulan Pod yang ditargetkan oleh sebuah `service` ditentukan dengan selektor label. Demikian pula kumpulan Pod yang harus ditangani oleh `replicationcontroller` juga ditentukan dengan selektor label. + +Selektor label untuk kedua objek tersebut ditentukan dalam berkas `json` atau `yaml` menggunakan _maps_, dan hanya mendukung kondisi _equality-based_: + +```json +"selector": { + "component" : "redis", +} +``` +atau + +```yaml +selector: + component: redis +``` + +selektor ini (baik dalam bentuk `json` atau `yaml`) sama dengan `component=redis` atau `component in (redis)`. + +#### Sumber daya yang mendukung kondisi set-based + +Sumber daya yang lebih baru, seperti [`Job`](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`Deployment`](/id/docs/concepts/workloads/controllers/deployment/), [`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/), dan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/), juga mendukung kondisi _set-based_. + +```yaml +selector: + matchLabels: + component: redis + matchExpressions: + - {key: tier, operator: In, values: [cache]} + - {key: environment, operator: NotIn, values: [dev]} +``` + +`matchLabels` merupakan pemetaan dari pasangan `{key,value}`. Sebuah `{key,value}` pada pemetaan `matchLabels` adalah sama dengan elemen dari `matchExpressions`, yang nilai `key` nya adalah "key", dengan `operator` "In", dan _array_ `values` hanya berisi "value". `matchExpressions` merupakan daftar kondisi untuk selektor Pod. Operator yang valid termasuk In, NotIn, Exists, dan DoesNotExist. Kumpulan nilai ini tidak boleh kosong pada kasus In dan NotIn. Semua kondisi, baik dari `matchLabels` dan `matchExpressions` di-AND secara sekaligus -- mereka harus memenuhi semua kondisi agar cocok. + +#### Memilih kumpulan Node + +Salah satu contoh penggunaan pemilihan dengan menggunakan label yaitu untuk membatasi suatu kumpulan Node tertentu yang dapat digunakan oleh Pod. +Lihat dokumentasi pada [pemilihan Node](/id/docs/concepts/configuration/assign-pod-node/) untuk informasi lebih lanjut. + +{{% /capture %}} From a6d1aa81109a9c94bad7e798e3fc0222d0126481 Mon Sep 17 00:00:00 2001 From: chentanjun <2799194073@qq.com> Date: Sat, 21 Mar 2020 10:08:44 +0800 Subject: [PATCH 171/194] update zh-trans content/zh/docs/tasks/job/parallel-processing-expansion.md (#19636) --- .../job/parallel-processing-expansion.md | 643 ++++++++++-------- 1 file changed, 341 insertions(+), 302 deletions(-) diff --git a/content/zh/docs/tasks/job/parallel-processing-expansion.md b/content/zh/docs/tasks/job/parallel-processing-expansion.md index 5cbdc3e8da..e113804e73 100644 --- a/content/zh/docs/tasks/job/parallel-processing-expansion.md +++ b/content/zh/docs/tasks/job/parallel-processing-expansion.md @@ -1,302 +1,341 @@ ---- -title: 使用扩展进行并行处理 -content_template: templates/concept -weight: 20 ---- - - - -{{% capture overview %}} - - -在这个示例中，我们将运行从一个公共模板创建的多个 Kubernetes 作业。您可能希望熟悉 -[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 的基本、非并行使用。 - -{{% /capture %}} - - -{{% capture body %}} - - - -## 基本模板扩展 - - -首先，将以下作业模板下载到名为 `job-tmpl.yaml` 的文件中 - -{{< codenew file="application/job/job-tmpl.yaml" >}} - - -与 *pod 模板*不同，我们的 *job 模板*不是 Kubernetes API 类型。它只是作业对象的 yaml 表示， -YAML 文件有一些占位符，在使用它之前需要填充这些占位符。`$ITEM` 语法对 Kubernetes 没有意义。 - - -在这个例子中，容器所做的唯一处理是 `echo` 一个字符串并休眠一段时间。 -在真实的用例中，处理将是一些重要的计算，例如呈现电影的帧，或者处理数据库中的一系列行。例如，`$ITEM` 参数将指定帧号或行范围。 - - -这个作业及其 Pod 模板有一个标签: `jobgroup=jobexample`。这个标签在系统中没有什么特别之处。 -这个标签使得我们可以方便地同时操作组中的所有作业。 -我们还将相同的标签放在 pod 模板上，这样我们就可以用一个命令检查这些作业的所有 pod。 -创建作业之后，系统将添加更多的标签来区分一个作业的 pod 和另一个作业的 pod。 -注意，标签键 `jobgroup` 对 Kubernetes 并无特殊含义。您可以选择自己的标签方案。 - - -下一步，将模板展开到多个文件中，每个文件对应要处理的项。 - -```shell -# Expand files into a temporary directory -$ mkdir ./jobs -$ for i in apple banana cherry -do - cat job-tmpl.yaml | sed "s/\$ITEM/$i/" > ./jobs/job-$i.yaml -done -``` - - -检查是否工作正常： - -```shell -$ ls jobs/ -job-apple.yaml -job-banana.yaml -job-cherry.yaml -``` - - -在这里，我们使用 `sed` 将字符串 `$ITEM` 替换为循环变量。 -您可以使用任何类型的模板语言(jinja2, erb) 或编写程序来生成作业对象。 - - -接下来，使用 kubectl 命令创建所有作业： - -```shell -$ kubectl create -f ./jobs -job "process-item-apple" created -job "process-item-banana" created -job "process-item-cherry" created -``` - - -现在，检查这些作业： - -```shell -$ kubectl get jobs -l jobgroup=jobexample -NAME DESIRED SUCCESSFUL AGE -process-item-apple 1 1 31s -process-item-banana 1 1 31s -process-item-cherry 1 1 31s -``` - - -在这里，我们使用 `-l` 选项选择属于这组作业的所有作业。(系统中可能还有其他不相关的工作，我们不想看到。) - - -我们可以检查 pod 以及使用同样地标签选择器： - -```shell -$ kubectl get pods -l jobgroup=jobexample -NAME READY STATUS RESTARTS AGE -process-item-apple-kixwv 0/1 Completed 0 4m -process-item-banana-wrsf7 0/1 Completed 0 4m -process-item-cherry-dnfu9 0/1 Completed 0 4m -``` - - -没有一个命令可以一次检查所有作业的输出，但是循环遍历所有 pod 非常简单： - -```shell -$ for p in $(kubectl get pods -l jobgroup=jobexample -o name) -do - kubectl logs $p -done -Processing item apple -Processing item banana -Processing item cherry -``` - - - -## 多个模板参数 - - -在第一个示例中，模板的每个实例都有一个参数，该参数也用作标签。 -但是标签的键名在[可包含的字符](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)方面有一定的约束。 - - -这个稍微复杂一点的示例使用 jinja2 板语言来生成我们的对象。 -我们将使用一行 python 脚本将模板转换为文件。 - - -首先，粘贴作业对象的以下模板到一个名为 `job.yaml.jinja2` 的文件中： - -```liquid -{%- set params = [{ "name": "apple", "url": "http://www.orangepippin.com/apples", }, - { "name": "banana", "url": "https://en.wikipedia.org/wiki/Banana", }, - { "name": "raspberry", "url": "https://www.raspberrypi.org/" }] -%} -{%- for p in params %} -{%- set name = p["name"] %} -{%- set url = p["url"] %} -apiVersion: batch/v1 -kind: Job -metadata: - name: jobexample-{{ name }} - labels: - jobgroup: jobexample -spec: - template: - metadata: - name: jobexample - labels: - jobgroup: jobexample - spec: - containers: - - name: c - image: busybox - command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"] - restartPolicy: Never ---- -{%- endfor %} - -``` - - -上面的模板使用 python dicts 列表（第1-4行）定义每个作业对象的参数。 -然后 for 循环为每组参数（剩余行）生成一个作业 yaml 对象。 -我们利用了多个 yaml 文档可以与 `---` 分隔符连接的事实（倒数第二行）。 -我们可以将输出直接传递给 kubectl 来创建对象。 - - -如果您还没有 jinja2 包则需要安装它: `pip install --user jinja2`。 -现在，使用这个一行 python 程序来展开模板: - -```shell -alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"' -``` - - - -输出可以保存到一个文件，像这样： - -```shell -cat job.yaml.jinja2 | render_template > jobs.yaml -``` - - -或直接发送到 kubectl，如下所示： - -```shell -cat job.yaml.jinja2 | render_template | kubectl create -f - -``` - - -## 替代方案 - - -如果您有大量作业对象，您可能会发现： - - - -- 即使使用标签，管理这么多作业对象也很麻烦。 -- 在一次创建所有作业时，您超过了资源配额，可是您也不希望以递增方式创建作业并等待其完成。 -- 同时创建的大量作业会使 Kubernetes apiserver、控制器或调度程序过载。 - - - -在这种情况下，您可以考虑 -其他[工作模式](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)。 - -{{% /capture %}} +--- +title: 使用扩展进行并行处理 +content_template: templates/concept +min-kubernetes-server-version: v1.8 +weight: 20 +--- + + + +{{% capture overview %}} + + +在这个示例中，我们将运行从一个公共模板创建的多个 Kubernetes Job。您可能需要先熟悉 [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 的基本概念、非并行以及如何使用它。 + +{{% /capture %}} + + +{{% capture body %}} + + + +## 基本模板扩展 + + +首先，将以下作业模板下载到名为 `job-tmpl.yaml` 的文件中。 + +{{< codenew file="application/job/job-tmpl.yaml" >}} + + +与 *pod 模板*不同，我们的 *job 模板*不是 Kubernetes API 类型。它只是 Job 对象的 yaml 表示， +YAML 文件有一些占位符，在使用它之前需要填充这些占位符。`$ITEM` 语法对 Kubernetes 没有意义。 + + +在这个例子中，容器所做的唯一处理是 `echo` 一个字符串并睡眠一段时间。 +在真实的用例中，处理将是一些重要的计算，例如渲染电影的一帧，或者处理数据库中的若干行。这时，`$ITEM` 参数将指定帧号或行范围。 + + +这个 Job 及其 Pod 模板有一个标签: `jobgroup=jobexample`。这个标签在系统中没有什么特别之处。 +这个标签使得我们可以方便地同时操作组中的所有作业。 +我们还将相同的标签放在 pod 模板上，这样我们就可以用一个命令检查这些 Job 的所有 pod。 +创建作业之后，系统将添加更多的标签来区分一个 Job 的 pod 和另一个 Job 的 pod。 +注意，标签键 `jobgroup` 对 Kubernetes 并无特殊含义。您可以选择自己的标签方案。 + + +下一步，将模板展开到多个文件中，每个文件对应要处理的项。 + +```shell +# 下载 job-templ.yaml +curl -L -s -O https://k8s.io/examples/application/job/job-tmpl.yaml + +# 创建临时目录，并且在目录中创建 job yaml 文件 +mkdir ./jobs +for i in apple banana cherry +do + cat job-tmpl.yaml | sed "s/\$ITEM/$i/" > ./jobs/job-$i.yaml +done +``` + + +检查是否工作正常： + +```shell +ls jobs/ +``` + + +输出类似以下内容： + +``` +job-apple.yaml +job-banana.yaml +job-cherry.yaml +``` + + +在这里，我们使用 `sed` 将字符串 `$ITEM` 替换为循环变量。 +您可以使用任何类型的模板语言(jinja2, erb) 或编写程序来生成 Job 对象。 + + +接下来，使用 kubectl 命令创建所有作业： + +```shell +kubectl create -f ./jobs +``` + + +输出类似以下内容： + +``` +job.batch/process-item-apple created +job.batch/process-item-banana created +job.batch/process-item-cherry created +``` + + +现在，检查这些作业： + +```shell +kubectl get jobs -l jobgroup=jobexample +``` + + +输出类似以下内容： + +``` +NAME COMPLETIONS DURATION AGE +process-item-apple 1/1 14s 20s +process-item-banana 1/1 12s 20s +process-item-cherry 1/1 12s 20s +``` + + +在这里，我们使用 `-l` 选项选择属于这组作业的所有作业。(系统中可能还有其他不相关的工作，我们不想看到。) + + +使用同样的标签选择器，我们还可以检查 pods： + +```shell +kubectl get pods -l jobgroup=jobexample +``` + + +输出类似以下内容： + +``` +NAME READY STATUS RESTARTS AGE +process-item-apple-kixwv 0/1 Completed 0 4m +process-item-banana-wrsf7 0/1 Completed 0 4m +process-item-cherry-dnfu9 0/1 Completed 0 4m +``` + + +我们可以使用以下操作命令一次性地检查所有作业的输出： + +```shell +kubectl logs -f -l jobgroup=jobexample +``` + + +输出内容为： + +``` +Processing item apple +Processing item banana +Processing item cherry +``` + + + +## 多个模板参数 + + +在第一个示例中，模板的每个实例都有一个参数，该参数也用作标签。 +但是标签的键名在[可包含的字符](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)方面有一定的约束。 + + +这个稍微复杂一点的示例使用 jinja2 模板语言来生成我们的对象。 +我们将使用一行 python 脚本将模板转换为文件。 + + +首先，粘贴 Job 对象的以下模板到一个名为 `job.yaml.jinja2` 的文件中： + +```liquid +{%- set params = [{ "name": "apple", "url": "https://www.orangepippin.com/varieties/apples", }, + { "name": "banana", "url": "https://en.wikipedia.org/wiki/Banana", }, + { "name": "raspberry", "url": "https://www.raspberrypi.org/" }] +%} +{%- for p in params %} +{%- set name = p["name"] %} +{%- set url = p["url"] %} +apiVersion: batch/v1 +kind: Job +metadata: + name: jobexample-{{ name }} + labels: + jobgroup: jobexample +spec: + template: + metadata: + name: jobexample + labels: + jobgroup: jobexample + spec: + containers: + - name: c + image: busybox + command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"] + restartPolicy: Never +--- +{%- endfor %} + +``` + + +上面的模板使用 python 字典列表（第 1-4 行）定义每个作业对象的参数。 +然后使用 for 循环为每组参数（剩余行）生成一个作业 yaml 对象。 +我们利用了多个 yaml 文档可以与 `---` 分隔符连接的事实（倒数第二行）。 +我们可以将输出直接传递给 kubectl 来创建对象。 + + +如果您还没有 jinja2 包则需要安装它: `pip install --user jinja2`。 +现在，使用这个一行 python 程序来展开模板: + +```shell +alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"' +``` + + + +输出可以保存到一个文件，像这样： + +```shell +cat job.yaml.jinja2 | render_template > jobs.yaml +``` + + +或直接发送到 kubectl，如下所示： + +```shell +cat job.yaml.jinja2 | render_template | kubectl apply -f - +``` + + +## 替代方案 + + +如果您有大量作业对象，您可能会发现： + + + +- 即使使用标签，管理这么多 Job 对象也很麻烦。 +- 在一次创建所有作业时，您超过了资源配额，可是您也不希望以递增方式创建 Job 并等待其完成。 +- 同时创建大量作业会使 Kubernetes apiserver、控制器或者调度器负压过大。 + + + +在这种情况下，您可以考虑其他的[作业模式](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)。 + +{{% /capture %}} From f4ab262cba7cb47a504d5841c06e13a87c04bc88 Mon Sep 17 00:00:00 2001 From: xieyanker Date: Sat, 21 Mar 2020 10:38:44 +0800 Subject: [PATCH 172/194] fix service docs' jump and format error (#19741) * fix service docs' jump and format error * Add jump flag after title --- content/zh/docs/concepts/services-networking/service.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/zh/docs/concepts/services-networking/service.md b/content/zh/docs/concepts/services-networking/service.md index 1971035ebd..9c07ff3097 100644 --- a/content/zh/docs/concepts/services-networking/service.md +++ b/content/zh/docs/concepts/services-networking/service.md @@ -169,7 +169,7 @@ also named “my-service”. 上述配置创建一个名称为 "my-service" 的 `Service` 对象，它会将请求代理到使用 TCP 端口 9376，并且具有标签 `"app=MyApp"` 的 `Pod` 上。 Kubernetes 为该服务分配一个 IP 地址（有时称为 "集群IP" ），该 IP 地址由服务代理使用。 -(请参见下面的 [虚拟 IP 和服务代理](#virtual-ips-and-service-proxies)). +(请参见下面的 [VIP 和 Service 代理](#virtual-ips-and-service-proxies)). 服务选择器的控制器不断扫描与其选择器匹配的 Pod，然后将所有更新发布到也称为 “my-service” 的Endpoint对象。 {{< note >}} @@ -336,7 +336,7 @@ responsible for implementing a form of virtual IP for `Services` of type other than [`ExternalName`](#externalname). --> -## VIP 和 Service 代理 +## VIP 和 Service 代理 {#virtual-ips-and-service-proxies} 在 Kubernetes 集群中，每个 Node 运行一个 `kube-proxy` 进程。`kube-proxy` 负责为 `Service` 实现了一种 VIP（虚拟 IP）的形式，而不是 [`ExternalName`](#externalname) 的形式。 @@ -828,6 +828,7 @@ You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expos Kubernetes `ServiceTypes` 允许指定一个需要的类型的 Service，默认是 `ClusterIP` 类型。 `Type` 的取值以及行为如下： + * `ClusterIP`：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 `ServiceType`。 * [`NodePort`](#nodeport)：通过每个 Node 上的 IP 和静态端口（`NodePort`）暴露服务。`NodePort` 服务会路由到 `ClusterIP` 服务，这个 `ClusterIP` 服务会自动创建。通过请求 `:`，可以从集群的外部访问一个 `NodePort` 服务。 * [`LoadBalancer`](#loadbalancer)：使用云提供商的负载局衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 `NodePort` 服务和 `ClusterIP` 服务。 From ef4642ae22774865018d7f0b117f2380ec6b5c80 Mon Sep 17 00:00:00 2001 From: chentanjun <2799194073@qq.com> Date: Sat, 21 Mar 2020 10:40:44 +0800 Subject: [PATCH 173/194] add en content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md (#19754) --- .../define-environment-variable-container.md | 68 +++++++++++++++++-- 1 file changed, 61 insertions(+), 7 deletions(-) diff --git a/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md index a7de28d98b..53795cf0d6 100644 --- a/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -3,8 +3,21 @@ title: 为容器设置环境变量 content_template: templates/task --- + + {{% capture overview %}} + + 本页将展示如何为 kubernetes Pod 下的容器设置环境变量。 {{% /capture %}} @@ -19,46 +32,81 @@ content_template: templates/task {{% capture steps %}} + + ## 为容器设置一个环境变量 + + 创建 Pod 时，可以为其下的容器设置环境变量。通过配置文件的 `env` 或者 `envFrom` 字段来设置环境变量。 + + 本示例中，将创建一个只包含单个容器的 Pod。Pod 的配置文件中设置环境变量的名称为 `DEMO_GREETING`， 其值为 `"Hello from the environment"`。下面是 Pod 的配置文件内容： {{< codenew file="pods/inject/envars.yaml" >}} + 1. 基于 YAML 文件创建一个 Pod： ```shell kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml ``` - + + 1. 获取一下当前正在运行的 Pods 信息： ```shell kubectl get pods -l purpose=demonstrate-envars ``` - + + 查询结果应为： ```shell NAME READY STATUS RESTARTS AGE envar-demo 1/1 Running 0 9s ``` - + + 1. 进入该 Pod 下的容器并打开一个命令终端： ```shell kubectl exec -it envar-demo -- /bin/bash ``` + 1. 在命令终端中通过执行 `printenv` 打印出环境变量。 ```shell root@envar-demo:/# printenv ``` + 打印结果应为： ```shell @@ -69,7 +117,10 @@ content_template: templates/task DEMO_GREETING=Hello from the environment DEMO_FAREWELL=Such a sweet sorrow ``` - + + 1. 通过键入 `exit` 退出命令终端。 + * 有关环境变量的更多信息，请参阅[这里](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)。 * 有关如何通过环境变量来使用 Secret，请参阅[这里](/docs/user-guide/secrets/#using-secrets-as-environment-variables)。 * 关于 [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core) 资源的信息。 {{% /capture %}} - - - From 6cda04257bf3571cbf697494cf7c71b8328964c2 Mon Sep 17 00:00:00 2001 From: chentanjun <2799194073@qq.com> Date: Sat, 21 Mar 2020 14:00:44 +0800 Subject: [PATCH 174/194] sync en zh content/zh/examples/controllers/ (#19764) --- ...7.9.yaml => replication-nginx-1.14.2.yaml} | 32 +++++++------- ...9.2.yaml => replication-nginx-1.16.1.yaml} | 42 +++++++++---------- 2 files changed, 37 insertions(+), 37 deletions(-) rename content/zh/examples/controllers/{replication-nginx-1.7.9.yaml => replication-nginx-1.14.2.yaml} (84%) rename content/zh/examples/controllers/{replication-nginx-1.9.2.yaml => replication-nginx-1.16.1.yaml} (87%) diff --git a/content/zh/examples/controllers/replication-nginx-1.7.9.yaml b/content/zh/examples/controllers/replication-nginx-1.14.2.yaml similarity index 84% rename from content/zh/examples/controllers/replication-nginx-1.7.9.yaml rename to content/zh/examples/controllers/replication-nginx-1.14.2.yaml index 768ab92ca7..2da69a152f 100644 --- a/content/zh/examples/controllers/replication-nginx-1.7.9.yaml +++ b/content/zh/examples/controllers/replication-nginx-1.14.2.yaml @@ -1,16 +1,16 @@ -apiVersion: v1 -kind: ReplicationController -metadata: - name: my-nginx -spec: - replicas: 5 - template: - metadata: - labels: - app: nginx - spec: - containers: - - name: nginx - image: nginx:1.7.9 - ports: - - containerPort: 80 +apiVersion: v1 +kind: ReplicationController +metadata: + name: my-nginx +spec: + replicas: 5 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 diff --git a/content/zh/examples/controllers/replication-nginx-1.9.2.yaml b/content/zh/examples/controllers/replication-nginx-1.16.1.yaml similarity index 87% rename from content/zh/examples/controllers/replication-nginx-1.9.2.yaml rename to content/zh/examples/controllers/replication-nginx-1.16.1.yaml index f92f2657ed..64efa4d1c3 100644 --- a/content/zh/examples/controllers/replication-nginx-1.9.2.yaml +++ b/content/zh/examples/controllers/replication-nginx-1.16.1.yaml @@ -1,21 +1,21 @@ -apiVersion: v1 -kind: ReplicationController -metadata: - name: my-nginx-v4 -spec: - replicas: 5 - selector: - app: nginx - deployment: v4 - template: - metadata: - labels: - app: nginx - deployment: v4 - spec: - containers: - - name: nginx - image: nginx:1.9.2 - args: ["nginx", "-T"] - ports: - - containerPort: 80 +apiVersion: v1 +kind: ReplicationController +metadata: + name: my-nginx-v4 +spec: + replicas: 5 + selector: + app: nginx + deployment: v4 + template: + metadata: + labels: + app: nginx + deployment: v4 + spec: + containers: + - name: nginx + image: nginx:1.16.1 + args: ["nginx", "-T"] + ports: + - containerPort: 80 From 4605d2b1f9896a0e039bf411da7e93503c21f306 Mon Sep 17 00:00:00 2001 From: Joshua Bezaleel Abednego Date: Sat, 21 Mar 2020 16:04:45 +0700 Subject: [PATCH 175/194] Add translation for ReplicationController in ID localization (#19071) * Add translation for ReplicationController in ID localization * Fix typos like pod, node, web server, spesifikasi, etc. * Fix typos on several words --- .../controllers/replicationcontroller.md | 243 ++++++++++++++++++ .../id/examples/controllers/replication.yaml | 19 ++ 2 files changed, 262 insertions(+) create mode 100644 content/id/docs/concepts/workloads/controllers/replicationcontroller.md create mode 100644 content/id/examples/controllers/replication.yaml diff --git a/content/id/docs/concepts/workloads/controllers/replicationcontroller.md b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md new file mode 100644 index 0000000000..3dad74fb07 --- /dev/null +++ b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md @@ -0,0 +1,243 @@ +--- +title: ReplicationController +feature: + title: Reparasi otomatis + anchor: Bagaimana Sebuah ReplicationController Bekerja + description: > + Mengulang dan menjalankan kembali kontainer yang gagal, mengganti dan menjadwalkan ulang ketika ada Node yang mati, mematikan kontainer yang tidak memberikan respon terhadap health-check yang telah didefinisikan, dan tidak menunjukkannya ke klien sampai siap untuk digunakan. + +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +{{< note >}} +[`Deployment`](/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi. +{{< /note >}} + +Sebuah _ReplicationController_ memastikan bahwa terdapat sejumlah Pod yang sedang berjalan dalam suatu waktu tertentu. Dengan kata lain, ReplicationController memastikan bahwa sebuah Pod atau sebuah kumpulan Pod yang homogen selalu berjalan dan tersedia. + +{{% /capture %}} + + +{{% capture body %}} + +## Bagaimana ReplicationController Bekerja + +Jika terdapat terlalu banyak Pod, maka ReplicationController akan membatasi dan mematikan Pod-Pod yang berlebih. Jika terdapat terlalu sedikit, maka ReplicationController akan memulai dan menjalankan Pod-Pod baru lainnya. Tidak seperti Pod yang dibuat secara manual, Pod-Pod yang diatur oleh sebuah ReplicationController akan secara otomatis diganti jika mereka gagal, dihapus, ataupun dimatikan. +Sebagai contoh, Pod-Pod yang kamu miliki akan dibuat ulang dalam sebuah Node setelah terjadi proses pemeliharaan seperti pembaruan kernel. Untuk alasan ini, maka kamu sebaiknya memiliki sebuah ReplicationController bahkan ketika aplikasimu hanya membutuhkan satu buah Pod saja. Sebuah ReplicationController memiliki kemiripan dengan sebuah pengawas proses, tetapi alih-alih mengawasi sebuah proses individu pada sebuah Node, ReplicationController banyak Pod yang terdapat pada beberapa Node. + +ReplicationController seringkali disingkat sebagai "rc" dalam diskusi, dan sebagai _shortcut_ dalam perintah kubectl. + +Sebuah contoh sederhana adalah membuat sebuah objek ReplicationController untuk menjalankan sebuah _instance_ Pod secara berkelanjutan. Contoh pemakaian lainnya adalah untuk menjalankan beberapa replika identik dari sebuah servis yang direplikasi, seperti peladen web. + +## Menjalankan Sebuah Contoh ReplicationController + +Contoh ReplicationController ini mengonfigurasi tiga salinan dari peladen web nginx. + +{{< codenew file="controllers/replication.yaml" >}} + +Jalankan contoh di atas dengan mengunduh berkas contoh dan menjalankan perintah ini: + +```shell +kubectl apply -f https://k8s.io/examples/controllers/replication.yaml +``` +``` +replicationcontroller/nginx created +``` + +Periksa status dari ReplicationController menggunakan perintah ini: + +```shell +kubectl describe replicationcontrollers/nginx +``` +``` +Name: nginx +Namespace: default +Selector: app=nginx +Labels: app=nginx +Annotations: +Replicas: 3 current / 3 desired +Pods Status: 0 Running / 3 Waiting / 0 Succeeded / 0 Failed +Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx + Port: 80/TCP + Environment: + Mounts: + Volumes: +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- ---- ------ ------- + 20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-qrm3m + 20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-3ntk0 + 20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-4ok8v +``` + +Tiga Pod telah dibuat namun belum ada yang berjalan, kemungkinan karena _image_ yang sedang di-_pull_. +Beberapa waktu kemudian, perintah yang sama akan menunjukkan: + +```shell +Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed +``` + +Untuk melihat semua Pod yang dibuat oleh ReplicationController dalam bentuk yang lebih mudah dibaca mesin, kamu dapat menggunakan perintah seperti ini: + +```shell +pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name}) +echo $pods +``` +``` +nginx-3ntk0 nginx-4ok8v nginx-qrm3m +``` + +Pada perintah di atas, selektor yang dimaksud adalah selektor yang sama dengan yang terdapat pada ReplicationController (yang dapat dilihat pada keluaran `kubectl describe`), dan dalam bentuk yang berbeda dengan yang terdapat pada `replication.yaml`. Opsi `--output=jsonpath` menentukan perintah untuh mendapatkan hanya nama dari setiap Pod yang ada pada daftar hasil. + + +## Menulis Spesifikasi ReplicationController + +Seperti semua konfigurasi Kubernetes lainnya, sebuah ReplicationController membutuhkan _field_ `apiVersion`, `kind`, dan `metadata`. + +Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/docs/concepts/overview/working-with-objects/object-management/). + +Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Templat Pod + +`.spec.template` adalah satu-satunya _field_ yang diwajibkan pada `.spec`. + +`.spec.template` adalah sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`. + +Selain _field-field_ yang diwajibkan untuk sebuah Pod, templat Pod pada ReplicationController harus menentukan label dan kebijakan pengulangan kembali yang tepat. Untuk label, pastikan untuk tidak tumpang tindih dengan kontroler lain. Lihat [selektor pod](#selektor-pod). + +Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan. + +Untuk pengulangan kembali dari sebuah kontainer lokal, ReplicationController mendelegasikannya ke agen pada Node, contohnya [Kubelet](/docs/admin/kubelet/) atau Docker. + +### Label pada ReplicationController + +ReplicationController itu sendiri dapat memiliki label (`.metadata.labels`). Biasanya, kamu akan mengaturnya untuk memiliki nilai yang sama dengan `.spec.template.metadata.labels`; jika `.metadata.labels` tidak ditentukan maka akan menggunakan nilai bawaan yaitu `.spec.template.metadata.labels`. Namun begitu, kedua label ini diperbolehkan untuk memiliki nilai yang berbeda, dan `.metadata.labels` tidak akan memengaruhi perilaku dari ReplicationController. + +### Selektor Pod + +_Field_ `.spec.selector` adalah sebuah [selektor label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan. + +Jika ditentukan, `.spec.template.metadata.labels` harus memiliki nilai yang sama dengan `.spec.selector`, atau akan ditolak oleh API. Jika `.spec.selector` tidak ditentukan, maka akan menggunakan nilai bawaan yaitu `.spec.template.metadata.labels`. + +Selain itu, kamu juga sebaiknya tidak membuat Pod dengan label yang cocok dengan selektor ini, baik secara langsung, dengan menggunakan ReplicationController lain, ataupun menggunakan kontroler lain seperti Job. Jika kamu melakukannya, ReplicationController akan menganggap bahwa ia telah membuat Pod-Pod lainnya. Kubernetes tidak akan menghentikan kamu untuk melakukan aksi ini. + +Jika kamu pada akhirnya memiliki beberapa kontroler dengan selektor-selektor yang tumpang tindih, kamu harus mengatur penghapusannya sendiri (lihat [di bawah](#bekerja-dengan-replicationcontroller)). + +### Beberapa Replika + +Kamu dapat menentukan jumlah Pod yang seharusnya berjalan secara bersamaan dengan mengatur nilai `.spec.replicas` dengan jumlah Pod yang kamu inginkan untuk berjalan secara bersamaan. Jumlah yang berjalan dalam satu satuan waktu dapat lebih tinggi ataupun lebih rendah, seperti jika replika-replika tersebut melewati proses penambahan atau pengurangan, atau jika sebuah Pod melalui proses _graceful shutdown_, dan penggantinya telah dijalankan terlebih dahulu. + +Jika kamu tidak menentukan nilai dari `.spec.replicas`, maka akan digunakan nilai bawaan 1. + +## Bekerja dengan ReplicationController + +### Menghapus Sebuah ReplicationController dan Pod-nya + +Untuk menghapus sebuah ReplicationController dan Pod-Pod yang berhubungan dengannya, gunakan perintah [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). Kubectl akan mengatur ReplicationController ke nol dan menunggunya untuk menghapus setiap Pod sebelum menghapus ReplicationController itu sendiri. Jika perintah kubectl ini terhenti, maka dapat diulang kembali. + +Ketika menggunakan REST API atau _library_ klien go, maka kamu perlu melakukan langkah-langkahnya secara eksplisit (mengatur replika-replika ke 0, menunggu penghapusan Pod, dan barulah menghapus ReplicationController). + +### Menghapus Hanya ReplicationController + +Kamu dapat menghapus ReplicationController tanpa memengaruhi Pod-Pod yang berhubungan dengannya. + +Dengan menggunakan kubectl, tentukan opsi `--cascade=false` ke [`kubectl delete`](/docs/reference/generDeated/kubectl/kubectl-commands#delete). + +Ketika menggunakan REST API atau _library_ klien go, cukup hapus objek ReplicationController. + +Ketika ReplicationController yang asli telah dihapus, kamu dapat membuat ReplicationController yang baru sebagai penggantinya. Selama `.spec.selector` yang lama dan baru memiliki nilai yang sama, maka ReplicationController baru akan mengadopsi Pod-Pod yang lama. +Walaupun begitu, ia tidak akan melakukan usaha apapun untuk membuat Pod-Pod yang telah ada sebelumnya untuk sesuai dengan templat Pod yang baru dan berbeda. +Untuk memperbarui Pod-Pod ke spesifikasi yang baru dengan cara yang terkontrol, gunakan [pembaruan bergulir](#pembaruan-bergulir). + +### Mengisolasi Pod dari ReplicationController + +Pod-Pod dapat dihapus dari kumpulan target sebuah ReplicationController dengan mengganti nilai dari labelnya. Teknik ini dapat digunakan untuk mencopot Pod-Pod dari servis untuk keperluan pengawakutuan (_debugging_), pemulihan data, dan lainnya. Pod-Pod yang dicopot dengan cara ini dapat digantikan secara otomatis (dengan asumsi bahwa jumlah replika juga tidak berubah). + +## Pola penggunaan umum + +### Penjadwalan ulang + +Seperti yang telah disebutkan sebelumnya, baik kamu memiliki hanya 1 Pod untuk tetap dijalankan, ataupun 1000, ReplicationController akan memastikan tersedianya jumlah Pod yang telat ditentukan, bahkan ketika terjadi kegagalan Node atau terminasi Pod (sebagai contoh karena adanya tindakan dari agen kontrol lain). + +### Penskalaan + +ReplicationController memudahkan penskalaan jumlah replika, baik meningkatkan ataupun mengurangi, secara manual ataupun dengan agen kontrol penskalaan otomatis, dengan hanya mengubah nilai dari _field_ `replicas`. + +### Pembaruan bergulir + +ReplicationController didesain untuk memfasilitasi pembaruan bergulir untuk sebuah servis dengan mengganti Pod-Pod satu per satu. + +Seperti yang telah dijelaskan di [#1353](http://issue.k8s.io/1353), pendekatan yang direkomendasikan adalah dengan membuat ReplicationController baru dengan 1 replika, skala kontroler yang baru (+1) atau yang lama (-1) satu per satu, dan kemudian hapus kontroler lama setelah menyentuh angka 0 replika. Hal ini memungkinkan pembaruan dilakukan dengan dapat diprediksi terlepas dari adanya kegagalan yang tak terduga. + +Idealnya, kontroler pembaruan bergulir akan memperhitungkan kesiapan dari aplikasi, dan memastikan cukupnya jumlah Pod yang secara produktif meladen kapanpun. + +Dua ReplicationController diharuskan untuk memiliki setidaknya satu label yang berbeda, seperti _tag_ _image_ dari kontainer utama dari Pod, karena pembaruan bergulir biasanya dilakukan karena adanya pembaruan _image_. + +Pembaruan bergulir diimplementasikan pada perkakas klien [`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update). Lihat [`kubectl rolling-update` task](/docs/tasks/run-application/rolling-update-replication-controller/) untuk contoh-contoh yang lebih konkrit. + +### Operasi rilis majemuk + +Selain menjalankan beberapa rilis dari sebuah aplikasi ketika proses pembaruan bergulir sedang berjalan, adalah hal yang awam untuk menjalankan beberapa rilis untuk suatu periode waktu tertentu, atau bahkan secara kontinu, menggunakan operasi rilis majemuk. Operasi-operasi ini akan dibedakan menggunakan label. + +Sebagai contoh, sebuah servis dapat menyasar semua Pod dengan `tier in (frontend), environment in (prod)`. Anggap kamu memiliki 10 Pod tiruan yang membangun _tier_ ini tetapi kamu ingin bisa menggunakan 'canary' terhadap versi baru dari komponen ini. Kamu dapat mengatur sebuah ReplicationController dengan nilai `replicas` 9 untuk replika-replikanya, dengan label `tier=frontend, environment=prod, track=stable`, dan ReplicationController lainnya dengan nilai `replicas` 1 untuk canary, dengan label `tier=frontend, environment=prod, track=canary`. Sekarang servis sudah mencakup baik canary maupun Pod-Pod yang bukan canary. Kamu juga dapat mencoba-coba ReplicationController secara terpisah untuk melakukan pengujian, mengamati hasilnya, dan lainnya. + +### Menggunakan ReplicationController dengan Service + +Beberapa ReplicationController dapat berada di belakang sebuah Service, sedemikian sehingga, sebagai contoh, sebagian _traffic_ dapat ditujukan ke versi lama, dan sebagian lainnya ke versi yang baru. + +Sebuah ReplicationController tidak akan berhenti dengan sendirinya, namun ia tidak diekspektasikan untuk berjalan selama Service-Service yang ada. Service dapat terdiri dari berbagai Pod yang dikontrol beberapa ReplicationController, dan terdapat kemungkinan bahwa beberapa ReplicationController untuk dibuat dan dimatikan dalam jangka waktu hidup Service (contohnya adalah untuk melakukan pembaruan Pod-Pod yang menjalankan Service). Baik Service itu sendiri dan kliennya harus tetap dalam keadaan tidak mempunyai pengetahuan terhadap ReplicationController yang memelihara Pod-Pod dari Service tersebut. + +## Menulis program untuk Replikasi + +Pod-Pod yang dibuat oleh ReplicationController ditujukan untuk dapat sepadan dan memiliki semantik yang identik, walaupun konfigurasi mereka dapat berbeda seiring keberjalanan waktunya. Ini adalah contoh yang cocok untuk peladen _stateless_, namun ReplicationController juga dapat digunakan untuk memelihara ketersediaan dari aplikasi-aplikasi yang _master-elected_, _sharded_, _worker-pool_. Aplikasi-aplikasi seperti itu sebaiknya menggunakan mekanisme penetapan kerja yang dinamis, seperti [antrian kerja RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-two-python.html), berlainan dengan pengubahan statis/satu kali dari konfigurasi setiap Pod, yang dipandang sebagai sebuah _anti-pattern_. Pengubahan apapun yang dilakukan terhadap Pod, seperti _auto-sizing_ vertikal dari sumber daya (misalnya cpu atau memori), sebaiknya dilakukan oleh proses kontroller luring lainnya, dan bukan oleh ReplicationController itu sendiri. + +## Tanggung Jawab ReplicationController + +ReplicationController hanya memastikan ketersediaan dari sejumlah Pod yang cocok dengan selektor label dan berjalan dengan baik. Saat ini, hanya Pod yang diterminasi yang dijadikan pengecualian dari penghitungan. Kedepannya, [kesiapan](http://issue.k8s.io/620) dan informasi yang ada lainnya dari sistem dapat menjadi pertimbangan, kami dapat meningkatkan kontrol terhadap kebijakan penggantian, dan kami berencana untuk menginformasikan kejadian (_event_) yang dapat digunakan klien eksternal untuk implementasi penggantian yang sesuai dan/atau kebijakan pengurangan. + +ReplicationController akan selalu dibatasi terhadap tanggung jawab spesifik ini. Ia tidak akan melakukan _probe_ kesiapan atau keaktifan. Daripada melakukan _auto-scaling_, ia ditujukan untuk dikontrol oleh _auto-scaler_ eksternal (seperti yang didiskusikan pada [#492](http://issue.k8s.io/492)), yang akan mengganti _field_ `replicas`. Kami tidak akan menambahkan kebijakan penjadwalan (contohnya [_spreading_](http://issue.k8s.io/367#issuecomment-48428019)) untuk ReplicationController. Ia juga tidak seharusnya melakukan verifikasi terhadap Pod-Pod yang sedang dikontrol yang cocok dengan spesifikasi templat saat ini, karena hal itu dapat menghambat _auto-sizing_ dan proses otomatis lainnya. Demikian pula batas waktu penyelesaian, pengurutan _dependencies_, ekspansi konfigurasi, dan fitur-fitur lain yang seharusnya berada di komponen lain. Kami juga bahkan berencana untuk mengeluarkan mekanisme pembuatan Pod secara serentak ([#170](http://issue.k8s.io/170)). + +ReplicationController ditujukan untuk menjadi primitif komponen yang dapat dibangun untuk berbagai kebutuhan. Kami menargetkan API dengan tingkatan yang lebih tinggi dan/atau perkakas-perkakas untuk dibangun di atasnya dan primitif tambahan lainnya untuk kenyamanan pengguna kedepannya. Operasi-operasi makro yang sudah didukung oleh kubectl (_run_, _scale_, _rolling-update_) adalah contoh _proof-of-concept_ dari konsep ini. Sebagai contohnya, kita dapat menganggap sesuatu seperti [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) yang mengatur beberapa ReplicationController, _auto-scaler_, servis, kebijakan penjadwalan, canary, dan yang lainnya. + + +## Objek API + +ReplicationController adalah sebuah sumber daya _top-level_ pada REST API Kubernetes. Detil dari objek API dapat ditemukan di: [objek API ReplicationController](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replicationcontroller-v1-core). + +## Alternatif untuk ReplicationController + +### ReplicaSet + +[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod. +Perhatikan bahwa kami merekomendasikan untuk menggunakan Deployment sebagai ganti dari menggunakan ReplicaSet secara langsung, kecuali jika kamu membutuhkan orkestrasi pembaruan khusus atau tidak membutuhkan pembaruan sama sekali. + + +### Deployment (Direkomendasikan) + +[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya. + +### Pod sederhana + +Tidak seperti pada kasus ketika pengguna secara langsung membuat Pod, ReplicationController menggantikan Pod-Pod yang dihapus atau dimatikan untuk alasan apapun, seperti pada kasus kegagalan Node atau pemeliharaan Node yang disruptif, seperti pembaruan kernel. Untuk alasan ini, kami merekomendasikan kamu untuk menggunakan ReplicationController bahkan ketika aplikasimu hanya membutuhkan satu Pod saja. Anggap hal ini mirip dengan pengawas proses, hanya pada kasus ini mengawasi banyak Pod yang terdapat pada berbagai Node dan bukan proses-proses tunggal pada satu Node. ReplicationController mendelegasikan pengulangan kontainer lokal ke agen yang terdapat dalam Node (contohnya Kubelet atau Docker). + +### Job + +Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) sebagai ganti ReplicationController untuk Pod-Pod yang diharapkan diterminasi dengan sendirinya (seperti _batch jobs_). + +### DaemonSet + +Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan. + +## Informasi lanjutan + +Baca [Menjalankan Kontroler Replikasi AP _Stateless_](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/). + +{{% /capture %}} diff --git a/content/id/examples/controllers/replication.yaml b/content/id/examples/controllers/replication.yaml new file mode 100644 index 0000000000..e43ccbc32d --- /dev/null +++ b/content/id/examples/controllers/replication.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: ReplicationController +metadata: + name: nginx +spec: + replicas: 3 + selector: + app: nginx + template: + metadata: + name: nginx + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx + ports: + - containerPort: 80 \ No newline at end of file From 7c82b6e26bdaa02c567dfa599368117f261eaa6f Mon Sep 17 00:00:00 2001 From: xieyanker Date: Sat, 21 Mar 2020 20:08:44 +0800 Subject: [PATCH 176/194] fix some glossary translate (#19770) --- .../docs/reference/glossary/applications.md | 1 + .../docs/reference/glossary/control-plane.md | 3 +- .../docs/reference/glossary/pod-lifecycle.md | 40 ++++++++++--------- content/zh/docs/reference/glossary/service.md | 2 +- .../docs/reference/glossary/storage-class.md | 38 ++++++++++-------- .../zh/docs/reference/glossary/upstream.md | 2 +- 6 files changed, 47 insertions(+), 39 deletions(-) diff --git a/content/zh/docs/reference/glossary/applications.md b/content/zh/docs/reference/glossary/applications.md index cd02a4ee14..cbff609142 100644 --- a/content/zh/docs/reference/glossary/applications.md +++ b/content/zh/docs/reference/glossary/applications.md @@ -23,4 +23,5 @@ tags: - fundamental --- --> + 各种容器化应用运行所在的层。 diff --git a/content/zh/docs/reference/glossary/control-plane.md b/content/zh/docs/reference/glossary/control-plane.md index 1916feac7f..05f3f57978 100644 --- a/content/zh/docs/reference/glossary/control-plane.md +++ b/content/zh/docs/reference/glossary/control-plane.md @@ -25,7 +25,8 @@ tags: - fundamental --- --> + - 容器编排层，它暴露 API 和接口来定义、部署容器和管理容器的生命周期。 \ No newline at end of file + 容器编排层，它暴露 API 和接口来定义、部署容器和管理容器的生命周期。 diff --git a/content/zh/docs/reference/glossary/pod-lifecycle.md b/content/zh/docs/reference/glossary/pod-lifecycle.md index 67376a475c..bb3811ccf8 100644 --- a/content/zh/docs/reference/glossary/pod-lifecycle.md +++ b/content/zh/docs/reference/glossary/pod-lifecycle.md @@ -1,3 +1,17 @@ +--- +title: Pod 生命周期 +id: pod-lifecycle +date: 2019-02-17 +full-link: /docs/concepts/workloads/pods/pod-lifecycle/ +related: + - pod + - container +tags: + - fundamental +short_description: > + 关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。 +--- + --> ---- -title: Pod 生命周期 -id: pod-lifecycle -date: 2019-02-17 -full-link: /docs/concepts/workloads/pods/pod-lifecycle/ -related: - - pod - - container -tags: - - fundamental -short_description: > - 关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。 - ---- + + + 关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。 - + + diff --git a/content/zh/docs/reference/glossary/service.md b/content/zh/docs/reference/glossary/service.md index 67a1ba8404..54a03b3b1a 100755 --- a/content/zh/docs/reference/glossary/service.md +++ b/content/zh/docs/reference/glossary/service.md @@ -4,7 +4,7 @@ id: service date: 2018-04-12 full_link: /docs/concepts/services-networking/service/ short_description: > - A way to expose an application running on a set of Pods as a network service. + 将运行在一组 {{< glossary_tooltip text="Pods" term_id="pod" >}} 上的应用程序公开为网络服务的抽象方法。 aka: tags: diff --git a/content/zh/docs/reference/glossary/storage-class.md b/content/zh/docs/reference/glossary/storage-class.md index 52886478eb..49cadefe44 100644 --- a/content/zh/docs/reference/glossary/storage-class.md +++ b/content/zh/docs/reference/glossary/storage-class.md @@ -1,20 +1,3 @@ - - --- title: 存储类别 id: storageclass @@ -29,9 +12,30 @@ tags: - storage --- + + + + StorageClass 是管理员用来描述不同的可用存储类型的一种方法。 + diff --git a/content/zh/docs/reference/glossary/upstream.md b/content/zh/docs/reference/glossary/upstream.md index 7f2c7ded3e..118b3838f7 100644 --- a/content/zh/docs/reference/glossary/upstream.md +++ b/content/zh/docs/reference/glossary/upstream.md @@ -4,7 +4,7 @@ id: upstream date: 2018-04-12 full_link: short_description: > - May refer to: core Kubernetes or the source repo from which a repo was forked. + 可以参考：核心 Kubernetes 仓库或作为当前仓库派生来源的来源仓库。 aka: tags: From 3dca72800ce4868416ea8ccb4a38714294e3d282 Mon Sep 17 00:00:00 2001 From: Gede Wahyu Adi Pramana Date: Sun, 22 Mar 2020 16:30:44 +0700 Subject: [PATCH 177/194] Translate networking page to ID localization (#19420) Co-Authored-By: yofriadi Co-Authored-By: Giri Kuncoro Co-authored-by: yofriadi Co-authored-by: Giri Kuncoro --- .../cluster-administration/networking.md | 228 ++++++++++++++++++ 1 file changed, 228 insertions(+) create mode 100644 content/id/docs/concepts/cluster-administration/networking.md diff --git a/content/id/docs/concepts/cluster-administration/networking.md b/content/id/docs/concepts/cluster-administration/networking.md new file mode 100644 index 0000000000..23fd828fa7 --- /dev/null +++ b/content/id/docs/concepts/cluster-administration/networking.md @@ -0,0 +1,228 @@ +--- +title: Jaringan Kluster +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} +Jaringan adalah bagian utama dari Kubernetes, tetapi bisa menjadi sulit +untuk memahami persis bagaimana mengharapkannya bisa bekerja. +Ada 4 masalah yang berbeda untuk diatasi: + +1. Komunikasi antar kontainer yang sangat erat: hal ini diselesaikan oleh + [Pod](/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`. +2. Komunikasi antar Pod: ini adalah fokus utama dari dokumen ini. +3. Komunikasi Pod dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/). +4. Komunikasi eksternal dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/). + +{{% /capture %}} + + +{{% capture body %}} + +Kubernetes adalah tentang berbagi mesin antar aplikasi. Pada dasarnya, +saat berbagi mesin harus memastikan bahwa dua aplikasi tidak mencoba menggunakan +_port_ yang sama. Mengkoordinasikan _port_ di banyak pengembang sangat sulit +dilakukan pada skala yang berbeda dan memaparkan pengguna ke masalah +tingkat kluster yang di luar kendali mereka. + +Alokasi _port_ yang dinamis membawa banyak komplikasi ke sistem - setiap aplikasi +harus menganggap _port_ sebagai _flag_, _server_ API harus tahu cara memasukkan +nomor _port_ dinamis ke dalam blok konfigurasi, Service-Service harus tahu cara +menemukan satu sama lain, dll. Sebaliknya daripada berurusan dengan ini, +Kubernetes mengambil pendekatan yang berbeda. + +## Model jaringan Kubernetes + +Setiap Pod mendapatkan alamat IP sendiri. Ini berarti kamu tidak perlu secara langsung membuat tautan antara Pod dan kamu hampir tidak perlu berurusan dengan memetakan _port_ kontainer ke _port_ pada _host_. Ini menciptakan model yang bersih, kompatibel dengan yang sebelumnya dimana Pod dapat diperlakukan seperti halnya VM atau _host_ fisik dari perspektif alokasi _port_, penamaan, _service discovery_, _load balancing_, konfigurasi aplikasi, dan migrasi. + +Kubernetes memberlakukan persyaratan mendasar berikut pada setiap implementasi jaringan (kecuali kebijakan segmentasi jaringan yang disengaja): + + * Pod pada suatu Node dapat berkomunikasi dengan semua Pod pada semua Node tanpa NAT + * agen pada suatu simpul (mis. _daemon_ sistem, kubelet) dapat berkomunikasi dengan semua Pod pada Node itu + +Catatan: Untuk platform yang mendukung Pod yang berjalan di jaringan _host_ (mis. Linux): + + * Pod di jaringan _host_ dari sebuah Node dapat berkomunikasi dengan semua Pod pada semua Node tanpa NAT + +Model ini tidak hanya sedikit kompleks secara keseluruhan, tetapi pada prinsipnya kompatibel dengan keinginan Kubernetes untuk memungkinkan _low-friction porting_ dari aplikasi dari VM ke kontainer. Jika pekerjaan kamu sebelumnya dijalankan dalam VM, VM kamu memiliki IP dan dapat berbicara dengan VM lain di proyek yang sama. Ini adalah model dasar yang sama. + +Alamat IP Kubernetes ada di lingkup Pod - kontainer dalam Pod berbagi jaringan _namespace_ mereka - termasuk alamat IP mereka. Ini berarti bahwa kontainer dalam Pod semua dapat mencapai _port_ satu sama lain di `_localhost_`. Ini juga berarti bahwa kontainer dalam Pod harus mengoordinasikan penggunaan _port_, tetapi ini tidak berbeda dari proses di VM. Ini disebut model "IP-per-pod". + +## Bagaimana menerapkan model jaringan Kubernetes + +Ada beberapa cara agar model jaringan ini dapat diimplementasikan. Dokumen ini bukan studi lengkap tentang berbagai metode, tetapi semoga berfungsi sebagai pengantar ke berbagai teknologi dan berfungsi sebagai titik awal. + +Opsi jaringan berikut ini disortir berdasarkan abjad - urutan tidak menyiratkan status istimewa apa pun. + +### ACI + +[Infrastruktur Sentral Aplikasi Cisco](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) menawarkan solusi SDN overlay dan underlay terintegrasi yang mendukung kontainer, mesin virtual, dan _bare metal server_. [ACI](https://www.github.com/noironetworks/aci-containers) menyediakan integrasi jaringan kontainer untuk ACI. Tinjauan umum integrasi disediakan [di sini](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf). + +### AOS dari Apstra + +[AOS](http://www.apstra.com/products/aos/) adalah sistem Jaringan Berbasis Intent yang menciptakan dan mengelola lingkungan pusat data yang kompleks dari platform terintegrasi yang sederhana. AOS memanfaatkan desain terdistribusi sangat _scalable_ untuk menghilangkan pemadaman jaringan sambil meminimalkan biaya. + +Desain Referensi AOS saat ini mendukung _host_ yang terhubung dengan Lapis-3 yang menghilangkan masalah peralihan Lapis-2 yang lama. Host Lapis-3 ini bisa berupa _server_ Linux (Debian, Ubuntu, CentOS) yang membuat hubungan tetangga BGP secara langsung dengan _top of rack switches_ (TORs). AOS mengotomatisasi kedekatan perutean dan kemudian memberikan kontrol yang halus atas _route health injections_ (RHI) yang umum dalam _deployment_ Kubernetes. + +AOS memiliki banyak kumpulan endpoint REST API yang memungkinkan Kubernetes dengan cepat mengubah kebijakan jaringan berdasarkan persyaratan aplikasi. Peningkatan lebih lanjut akan mengintegrasikan model Grafik AOS yang digunakan untuk desain jaringan dengan penyediaan beban kerja, memungkinkan sistem manajemen ujung ke ujung untuk layanan cloud pribadi dan publik. + +AOS mendukung penggunaan peralatan vendor umum dari produsen termasuk Cisco, Arista, Dell, Mellanox, HPE, dan sejumlah besar sistem white-box dan sistem operasi jaringan terbuka seperti Microsoft SONiC, Dell OPX, dan Cumulus Linux. + +Detail tentang cara kerja sistem AOS dapat diakses di sini: http://www.apstra.com/products/how-it-works/ + +### AWS VPC CNI untuk Kubernetes + +[AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) menawarkan jaringan AWS _Virtual Private Cloud_ (VPC) terintegrasi untuk kluster Kubernetes. Plugin CNI ini menawarkan _throughput_ dan ketersediaan tinggi, latensi rendah, dan _jitter_ jaringan minimal. Selain itu, pengguna dapat menerapkan jaringan AWS VPC dan praktik keamanan terbaik untuk membangun kluster Kubernetes. Ini termasuk kemampuan untuk menggunakan catatan aliran VPC, kebijakan perutean VPC, dan grup keamanan untuk isolasi lalu lintas jaringan. + +Menggunakan _plugin_ CNI ini memungkinkan Pod Kubernetes memiliki alamat IP yang sama di dalam Pod seperti yang mereka lakukan di jaringan VPC. CNI mengalokasikan AWS _Elastic Networking Interfaces_ (ENIs) ke setiap node Kubernetes dan menggunakan rentang IP sekunder dari setiap ENI untuk Pod pada Node. CNI mencakup kontrol untuk pra-alokasi ENI dan alamat IP untuk waktu mulai Pod yang cepat dan memungkinkan kluster besar hingga 2.000 Node. + +Selain itu, CNI dapat dijalankan bersama [Calico untuk penegakan kebijakan jaringan](https://docs.aws.amazon.com/eks/latest/userguide/calico.html). Proyek AWS VPC CNI adalah _open source_ dengan [dokumentasi di GitHub](https://github.com/aws/amazon-vpc-cni-k8s). + +### Big Cloud Fabric dari Big Switch Networks + +[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) adalah arsitektur jaringan asli layanan cloud, yang dirancang untuk menjalankan Kubernetes di lingkungan cloud pribadi / lokal. Dengan menggunakan SDN fisik & _virtual_ terpadu, Big Cloud Fabric menangani masalah yang sering melekat pada jaringan kontainer seperti penyeimbangan muatan, visibilitas, pemecahan masalah, kebijakan keamanan & pemantauan lalu lintas kontainer. + +Dengan bantuan arsitektur multi-penyewa Pod virtual pada Big Cloud Fabric, sistem orkestrasi kontainer seperti Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm akan terintegrasi secara alami bersama dengan sistem orkestrasi VM seperti VMware, OpenStack & Nutanix. Pelanggan akan dapat terhubung dengan aman berapa pun jumlah klusternya dan memungkinkan komunikasi antar penyewa di antara mereka jika diperlukan. + +Terbaru ini BCF diakui oleh Gartner sebagai visioner dalam [_Magic Quadrant_](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). Salah satu penyebaran BCF Kubernetes di tempat (yang mencakup Kubernetes, DC/OS & VMware yang berjalan di beberapa DC di berbagai wilayah geografis) juga dirujuk [di sini](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/). + +### Cilium + +[Cilium](https://github.com/cilium/cilium) adalah perangkat lunak _open source_ untuk menyediakan dan secara transparan mengamankan konektivitas jaringan antar kontainer aplikasi. Cilium mengetahui L7/HTTP dan dapat memberlakukan kebijakan jaringan pada L3-L7 menggunakan model keamanan berbasis identitas yang dipisahkan dari pengalamatan jaringan. + +### CNI-Genie dari Huawei + +[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) adalah _plugin_ CNI yang memungkinkan Kubernetes [secara bersamaan memiliki akses ke berbagai implementasi](https://github.com/Huawei-PaaS /CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) dari [model jaringan Kubernetes] (https://git.k8s.io/website/docs/concepts/cluster-administration/networking.md#kubernetes-model) dalam _runtime_. Ini termasuk setiap implementasi yang berjalan sebagai [_plugin_ CNI](https://github.com/containernetworking/cni#3rd-party-plugins), seperti [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/). + +CNI-Genie juga mendukung [menetapkan beberapa alamat IP ke sebuah Pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-address-per-pod), masing-masing dari _plugin_ CNI yang berbeda. + +### cni-ipvlan-vpc-k8s + +[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) berisi satu set _plugin_ CNI dan IPAM untuk menyediakan kemudahan, host-lokal, latensi rendah, _throughput_ tinggi , dan tumpukan jaringan yang sesuai untuk Kubernetes dalam lingkungan Amazon Virtual Private Cloud (VPC) dengan memanfaatkan Amazon Elastic Network Interfaces (ENI) dan mengikat IP yang dikelola AWS ke Pod-Pod menggunakan _driver_ IPvlan _kernel_ Linux dalam mode L2. + +Plugin ini dirancang untuk secara langsung mengkonfigurasi dan _deploy_ dalam VPC. Kubelet melakukan _booting_ dan kemudian mengkonfigurasi sendiri dan memperbanyak penggunaan IP mereka sesuai kebutuhan tanpa memerlukan kompleksitas yang sering direkomendasikan untuk mengelola jaringan _overlay_, BGP, menonaktifkan pemeriksaan sumber/tujuan, atau menyesuaikan tabel rute VPC untuk memberikan _subnet_ per _instance_ ke setiap _host_ (yang terbatas hingga 50-100 masukan per VPC). Singkatnya, cni-ipvlan-vpc-k8s secara signifikan mengurangi kompleksitas jaringan yang diperlukan untuk menggunakan Kubernetes yang berskala di dalam AWS. + +### Contiv + +[Contiv](https://github.com/contiv/netplugin) menyediakan jaringan yang dapat dikonfigurasi (_native_ l3 menggunakan BGP, _overlay_ menggunakan vxlan, classic l2, atau Cisco-SDN / ACI) untuk berbagai kasus penggunaan. [Contiv](http://contiv.io) semuanya open sourced. + +### Contrail / Tungsten Fabric + +[Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), berdasarkan [Tungsten Fabric](https://tungsten.io), adalah platform virtualisasi jaringan dan manajemen kebijakan _multi-cloud_ yang benar-benar terbuka. Contrail dan Tungsten Fabric terintegrasi dengan berbagai sistem orkestrasi seperti Kubernetes, OpenShift, OpenStack dan Mesos, dan menyediakan mode isolasi yang berbeda untuk mesin _virtual_, banyak kontainer / banyak Pod dan beban kerja _bare metal_. + +### DANM + +[DANM] (https://github.com/nokia/danm) adalah solusi jaringan untuk beban kerja telco yang berjalan di kluster Kubernetes. Dibangun dari komponen-komponen berikut: + + * Plugin CNI yang mampu menyediakan antarmuka IPVLAN dengan fitur-fitur canggih + * Modul IPAM built-in dengan kemampuan mengelola dengan jumlah banyak, _cluster-wide_, _discontinous_ jaringan L3 dan menyediakan skema dinamis, statis, atau tidak ada permintaan skema IP + * Metaplugin CNI yang mampu melampirkan beberapa antarmuka jaringan ke kontainer, baik melalui CNI sendiri, atau mendelegasikan pekerjaan ke salah satu solusi CNI populer seperti SRI-OV, atau Flannel secara paralel + * Pengontrol Kubernetes yang mampu mengatur secara terpusat antarmuka VxLAN dan VLAN dari semua _host_ Kubernetes + * Pengontrol Kubernetes lain yang memperluas konsep _service discovery_ berbasis servis untuk bekerja di semua antarmuka jaringan Pod + +Dengan _toolset_ ini, DANM dapat memberikan beberapa antarmuka jaringan yang terpisah, kemungkinan untuk menggunakan ujung belakang jaringan yang berbeda dan fitur IPAM canggih untuk Pod. + +### Flannel + +[Flannel] (https://github.com/coreos/flannel#flannel) adalah jaringan overlay yang sangat sederhana yang memenuhi persyaratan Kubernetes. Banyak orang telah melaporkan kesuksesan dengan Flannel dan Kubernetes. + +### Google Compute Engine (GCE) + +Untuk skrip konfigurasi kluster Google Compute Engine, [perutean lanjutan](https://cloud.google.com/vpc/docs/routes) digunakan untuk menetapkan setiap VM _subnet_ (standarnya adalah `/24` - 254 IP). Setiap lalu lintas yang terikat untuk _subnet_ itu akan dialihkan langsung ke VM oleh _fabric_ jaringan GCE. Ini adalah tambahan untuk alamat IP "utama" yang ditugaskan untuk VM, yang NAT'ed untuk akses internet keluar. Sebuah linux _bridge_ (disebut `cbr0`) dikonfigurasikan untuk ada pada subnet itu, dan diteruskan ke _flag_ `-bridge` milik docker. + +Docker dimulai dengan: + +```shell +DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false" +``` + +Jembatan ini dibuat oleh Kubelet (dikontrol oleh _flag_ `--network-plugin=kubenet`) sesuai dengan `.spec.podCIDR` yang dimiliki oleh Node. + +Docker sekarang akan mengalokasikan IP dari blok `cbr-cidr`. Kontainer dapat menjangkau satu sama lain dan Node di atas jembatan` cbr0`. IP-IP tersebut semuanya dapat dirutekan dalam jaringan proyek GCE. + +GCE sendiri tidak tahu apa-apa tentang IP ini, jadi tidak akan NAT untuk lalu lintas internet keluar. Untuk mencapai itu aturan iptables digunakan untuk menyamar (alias SNAT - untuk membuatnya seolah-olah paket berasal dari lalu lintas `Node` itu sendiri) yang terikat untuk IP di luar jaringan proyek GCE (10.0.0.0/8). + +```shell +iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE +``` + +Terakhir IP forwarding diaktifkan di kernel (sehingga kernel akan memproses paket untuk kontainer yang dijembatani): + +```shell +sysctl net.ipv4.ip_forward=1 +``` + +Hasil dari semua ini adalah bahwa semua Pod dapat saling menjangkau dan dapat keluar lalu lintas ke internet. + +### Jaguar + +[Jaguar](https://gitlab.com/sdnlab/jaguar) adalah solusi open source untuk jaringan Kubernetes berdasarkan OpenDaylight. Jaguar menyediakan jaringan overlay menggunakan vxlan dan Jaguar CNIPlugin menyediakan satu alamat IP per Pod. + +### Knitter + +[Knitter](https://github.com/ZTE/Knitter/) adalah solusi jaringan yang mendukung banyak jaringan di Kubernetes. Solusi ini menyediakan kemampuan manajemen penyewa dan manajemen jaringan. Knitter mencakup satu set solusi jaringan kontainer NFV ujung ke ujung selain beberapa pesawat jaringan, seperti menjaga alamat IP untuk aplikasi, migrasi alamat IP, dll. + +### Kube-OVN + +[Kube-OVN](https://github.com/alauda/kube-ovn) adalah _fabric_ jaringan kubernetes berbasis OVN untuk _enterprises_. Dengan bantuan OVN/OVS, solusi ini menyediakan beberapa fitur jaringan _overlay_ canggih seperti _subnet_, QoS, alokasi IP statis, _mirroring traffic_, _gateway_, kebijakan jaringan berbasis _openflow_, dan proksi layanan. + +### Kube-router + +[Kube-router](https://github.com/cloudnativelabs/kube-router) adalah solusi jaringan yang dibuat khusus untuk Kubernetes yang bertujuan untuk memberikan kinerja tinggi dan kesederhanaan operasional. Kube-router menyediakan Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html) berbasis proksi layanan, solusi jaringan berbasis penerusan _pod-to-pod_ Linux _kernel_ tanpa _overlay_, dan penegak kebijakan jaringan berbasis _iptables/ipset_. + +### L2 networks and linux bridging + +Jika Anda memiliki jaringan L2 yang "bodoh", seperti saklar sederhana di _environment_ "bare-metal", kamu harus dapat melakukan sesuatu yang mirip dengan pengaturan GCE di atas. Perhatikan bahwa petunjuk ini hanya dicoba dengan sangat sederhana - sepertinya berhasil, tetapi belum diuji secara menyeluruh. Jika kamu menggunakan teknik ini dan telah menyempurnakan prosesnya, tolong beri tahu kami. + +Ikuti bagian "With Linux Bridge devices" dari [tutorial yang sangat bagus ini](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) dari Lars Kellogg-Stedman. + +### Multus (plugin Multi-Jaringan) + +[Multus](https://github.com/Intel-Corp/multus-cni) adalah plugin Multi CNI untuk mendukung fitur Banyak Jaringan di Kubernetes menggunakan objek jaringan berbasis CRD di Kubernetes. + +Multus mendukung semua [plugin referensi](https://github.com/containernetworking/plugins) (mis. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main / macvlan)) yang mengimplementasikan spesifikasi CNI dan plugin pihak ke-3 (mis. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave ), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). Selain itu, Multus mendukung [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS- DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) beban kerja di Kubernetes dengan aplikasi cloud asli dan aplikasi berbasis NFV di Kubernetes. + +### NSX-T + +[VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) adalah virtualisasi jaringan dan platform keamanan. NSX-T dapat menyediakan virtualisasi jaringan untuk lingkungan multi-cloud dan multi-hypervisor dan berfokus pada kerangka kerja dan arsitektur aplikasi yang muncul yang memiliki titik akhir dan tumpukan teknologi yang heterogen. Selain hypervisor vSphere, lingkungan ini termasuk hypervisor lainnya seperti KVM, wadah, dan bare metal. + +[NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) menyediakan integrasi antara NSX-T dan pembuat wadah seperti Kubernetes, serta integrasi antara NSX-T dan platform CaaS / PaaS berbasis-kontainer seperti Pivotal Container Service (PKS) dan OpenShift. + +### Nuage Networks VCS (Layanan Cloud Virtual) + +[Nuage](http://www.nuagenetworks.net) menyediakan platform SDN (Software-Defined Networking) berbasis kebijakan yang sangat skalabel. Nuage menggunakan Open vSwitch _open source_ untuk data _plane_ bersama dengan SDN Controller yang kaya fitur yang dibangun pada standar terbuka. + +Platform Nuage menggunakan _overlay_ untuk menyediakan jaringan berbasis kebijakan yang mulus antara Kubernetes Pod-Pod dan lingkungan non-Kubernetes (VM dan server _bare metal_). Model abstraksi kebijakan Nuage dirancang dengan mempertimbangkan aplikasi dan membuatnya mudah untuk mendeklarasikan kebijakan berbutir halus untuk aplikasi. Mesin analisis _real-time_ platform memungkinkan pemantauan visibilitas dan keamanan untuk aplikasi Kubernetes. + +### OpenVSwitch + +[OpenVSwitch](https://www.openvswitch.org/) adalah cara yang agak lebih dewasa tetapi juga rumit untuk membangun jaringan _overlay_. Ini didukung oleh beberapa "Toko Besar" untuk jaringan. + +### OVN (Open Virtual Networking) + +OVN adalah solusi virtualisasi jaringan opensource yang dikembangkan oleh komunitas Open vSwitch. Ini memungkinkan seseorang membuat switch logis, router logis, ACL stateful, load-balancers dll untuk membangun berbagai topologi jaringan virtual. Proyek ini memiliki plugin dan dokumentasi Kubernetes spesifik di [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes). + +### Project Calico + +[Project Calico](http://docs.projectcalico.org/) adalah penyedia jaringan wadah sumber terbuka dan mesin kebijakan jaringan. + +Calico menyediakan solusi jaringan dan kebijakan kebijakan jaringan yang sangat berskala untuk menghubungkan Pod Kubernetes berdasarkan prinsip jaringan IP yang sama dengan internet, untuk Linux (open source) dan Windows (milik - tersedia dari [Tigera](https://www.tigera.io/essentials/)). Calico dapat digunakan tanpa enkapsulasi atau _overlay_ untuk menyediakan jaringan pusat data skala tinggi yang berkinerja tinggi. Calico juga menyediakan kebijakan keamanan jaringan berbutir halus, berdasarkan niat untuk Pod Kubernetes melalui _firewall_ terdistribusi. + +Calico juga dapat dijalankan dalam mode penegakan kebijakan bersama dengan solusi jaringan lain seperti Flannel, alias [kanal](https://github.com/tigera/canal), atau jaringan GCE, AWS atau Azure asli. + +### Romana + +[Romana](http://romana.io) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan. + +### Weave Net dari Weaveworks + +[Weave Net](https://www.weave.works/products/weave-net/) adalah jaringan yang tangguh dan mudah digunakan untuk Kubernetes dan aplikasi yang dihostingnya. Weave Net berjalan sebagai [plug-in CNI](https://www.weave.works/docs/net/latest/cni-plugin/) atau berdiri sendiri. Di kedua versi, itu tidak memerlukan konfigurasi atau kode tambahan untuk dijalankan, dan dalam kedua kasus, jaringan menyediakan satu alamat IP per Pod - seperti standar untuk Kubernetes. + +{{% /capture %}} + +{{% capture whatsnext %}} + +Desain awal model jaringan dan alasannya, dan beberapa rencana masa depan dijelaskan secara lebih rinci dalam [dokumen desain jaringan](https://git.k8s.io/community/contributors/design-proposals/network/networking.md). + +{{% /capture %}} From d1233d35317d009eeda2af1edd3a8855b21b5749 Mon Sep 17 00:00:00 2001 From: chentanjun <2799194073@qq.com> Date: Sun, 22 Mar 2020 20:04:44 +0800 Subject: [PATCH 178/194] sync en zh yaml in content/zh/example/admin direcroty (#19766) --- .../zh/examples/admin/cloud/ccm-example.yaml | 138 +++++++++--------- .../admin/dns/dns-horizontal-autoscaler.yaml | 66 ++++----- content/zh/examples/admin/dns/dnsutils.yaml | 14 ++ .../admin/resource/cpu-constraints-pod-3.yaml | 4 +- .../admin/resource/quota-objects-pvc-2.yaml | 2 +- .../admin/resource/quota-objects-pvc.yaml | 2 +- .../zh/examples/admin/sched/my-scheduler.yaml | 134 ++++++++--------- 7 files changed, 187 insertions(+), 173 deletions(-) create mode 100644 content/zh/examples/admin/dns/dnsutils.yaml diff --git a/content/zh/examples/admin/cloud/ccm-example.yaml b/content/zh/examples/admin/cloud/ccm-example.yaml index 4c98162a70..27386be675 100644 --- a/content/zh/examples/admin/cloud/ccm-example.yaml +++ b/content/zh/examples/admin/cloud/ccm-example.yaml @@ -1,69 +1,69 @@ -# This is an example of how to setup cloud-controller-manger as a Daemonset in your cluster. -# It assumes that your masters can run pods and has the role node-role.kubernetes.io/master -# Note that this Daemonset will not work straight out of the box for your cloud, this is -# meant to be a guideline. - ---- -apiVersion: v1 -kind: ServiceAccount -metadata: - name: cloud-controller-manager - namespace: kube-system ---- -kind: ClusterRoleBinding -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: system:cloud-controller-manager -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: cluster-admin -subjects: -- kind: ServiceAccount - name: cloud-controller-manager - namespace: kube-system ---- -apiVersion: apps/v1 -kind: DaemonSet -metadata: - labels: - k8s-app: cloud-controller-manager - name: cloud-controller-manager - namespace: kube-system -spec: - selector: - matchLabels: - k8s-app: cloud-controller-manager - template: - metadata: - labels: - k8s-app: cloud-controller-manager - spec: - serviceAccountName: cloud-controller-manager - containers: - - name: cloud-controller-manager - # for in-tree providers we use k8s.gcr.io/cloud-controller-manager - # this can be replaced with any other image for out-of-tree providers - image: k8s.gcr.io/cloud-controller-manager:v1.8.0 - command: - - /usr/local/bin/cloud-controller-manager - - --cloud-provider= # Add your own cloud provider here! - - --leader-elect=true - - --use-service-account-credentials - # these flags will vary for every cloud provider - - --allocate-node-cidrs=true - - --configure-cloud-routes=true - - --cluster-cidr=172.17.0.0/16 - tolerations: - # this is required so CCM can bootstrap itself - - key: node.cloudprovider.kubernetes.io/uninitialized - value: "true" - effect: NoSchedule - # this is to have the daemonset runnable on master nodes - # the taint may vary depending on your cluster setup - - key: node-role.kubernetes.io/master - effect: NoSchedule - # this is to restrict CCM to only run on master nodes - # the node selector may vary depending on your cluster setup - nodeSelector: - node-role.kubernetes.io/master: "" +# This is an example of how to setup cloud-controller-manger as a Daemonset in your cluster. +# It assumes that your masters can run pods and has the role node-role.kubernetes.io/master +# Note that this Daemonset will not work straight out of the box for your cloud, this is +# meant to be a guideline. + +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: cloud-controller-manager + namespace: kube-system +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: system:cloud-controller-manager +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: cluster-admin +subjects: +- kind: ServiceAccount + name: cloud-controller-manager + namespace: kube-system +--- +apiVersion: apps/v1 +kind: DaemonSet +metadata: + labels: + k8s-app: cloud-controller-manager + name: cloud-controller-manager + namespace: kube-system +spec: + selector: + matchLabels: + k8s-app: cloud-controller-manager + template: + metadata: + labels: + k8s-app: cloud-controller-manager + spec: + serviceAccountName: cloud-controller-manager + containers: + - name: cloud-controller-manager + # for in-tree providers we use k8s.gcr.io/cloud-controller-manager + # this can be replaced with any other image for out-of-tree providers + image: k8s.gcr.io/cloud-controller-manager:v1.8.0 + command: + - /usr/local/bin/cloud-controller-manager + - --cloud-provider=[YOUR_CLOUD_PROVIDER] # Add your own cloud provider here! + - --leader-elect=true + - --use-service-account-credentials + # these flags will vary for every cloud provider + - --allocate-node-cidrs=true + - --configure-cloud-routes=true + - --cluster-cidr=172.17.0.0/16 + tolerations: + # this is required so CCM can bootstrap itself + - key: node.cloudprovider.kubernetes.io/uninitialized + value: "true" + effect: NoSchedule + # this is to have the daemonset runnable on master nodes + # the taint may vary depending on your cluster setup + - key: node-role.kubernetes.io/master + effect: NoSchedule + # this is to restrict CCM to only run on master nodes + # the node selector may vary depending on your cluster setup + nodeSelector: + node-role.kubernetes.io/master: "" diff --git a/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml b/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml index 5e6d55a6b2..3676a0acdb 100644 --- a/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml +++ b/content/zh/examples/admin/dns/dns-horizontal-autoscaler.yaml @@ -1,33 +1,33 @@ -apiVersion: apps/v1 -kind: Deployment -metadata: - name: dns-autoscaler - namespace: kube-system - labels: - k8s-app: dns-autoscaler -spec: - selector: - matchLabels: - k8s-app: dns-autoscaler - template: - metadata: - labels: - k8s-app: dns-autoscaler - spec: - containers: - - name: autoscaler - image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.1.1 - resources: - requests: - cpu: "20m" - memory: "10Mi" - command: - - /cluster-proportional-autoscaler - - --namespace=kube-system - - --configmap=dns-autoscaler - - --target= - # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate. - # If using small nodes, "nodesPerReplica" should dominate. - - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"min":1}} - - --logtostderr=true - - --v=2 +apiVersion: apps/v1 +kind: Deployment +metadata: + name: dns-autoscaler + namespace: kube-system + labels: + k8s-app: dns-autoscaler +spec: + selector: + matchLabels: + k8s-app: dns-autoscaler + template: + metadata: + labels: + k8s-app: dns-autoscaler + spec: + containers: + - name: autoscaler + image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.6.0 + resources: + requests: + cpu: 20m + memory: 10Mi + command: + - /cluster-proportional-autoscaler + - --namespace=kube-system + - --configmap=dns-autoscaler + - --target= + # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate. + # If using small nodes, "nodesPerReplica" should dominate. + - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"min":1}} + - --logtostderr=true + - --v=2 diff --git a/content/zh/examples/admin/dns/dnsutils.yaml b/content/zh/examples/admin/dns/dnsutils.yaml new file mode 100644 index 0000000000..5eb9833f39 --- /dev/null +++ b/content/zh/examples/admin/dns/dnsutils.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dnsutils + namespace: default +spec: + containers: + - name: dnsutils + image: gcr.io/kubernetes-e2e-test-images/dnsutils:1.3 + command: + - sleep + - "3600" + imagePullPolicy: IfNotPresent + restartPolicy: Always diff --git a/content/zh/examples/admin/resource/cpu-constraints-pod-3.yaml b/content/zh/examples/admin/resource/cpu-constraints-pod-3.yaml index 896d98ec2f..0a2083acd8 100644 --- a/content/zh/examples/admin/resource/cpu-constraints-pod-3.yaml +++ b/content/zh/examples/admin/resource/cpu-constraints-pod-3.yaml @@ -1,10 +1,10 @@ apiVersion: v1 kind: Pod metadata: - name: constraints-cpu-demo-4 + name: constraints-cpu-demo-3 spec: containers: - - name: constraints-cpu-demo-4-ctr + - name: constraints-cpu-demo-3-ctr image: nginx resources: limits: diff --git a/content/zh/examples/admin/resource/quota-objects-pvc-2.yaml b/content/zh/examples/admin/resource/quota-objects-pvc-2.yaml index 88c165d144..2539c2d309 100644 --- a/content/zh/examples/admin/resource/quota-objects-pvc-2.yaml +++ b/content/zh/examples/admin/resource/quota-objects-pvc-2.yaml @@ -1,5 +1,5 @@ -kind: PersistentVolumeClaim apiVersion: v1 +kind: PersistentVolumeClaim metadata: name: pvc-quota-demo-2 spec: diff --git a/content/zh/examples/admin/resource/quota-objects-pvc.yaml b/content/zh/examples/admin/resource/quota-objects-pvc.yaml index b38256b897..728bb4d708 100644 --- a/content/zh/examples/admin/resource/quota-objects-pvc.yaml +++ b/content/zh/examples/admin/resource/quota-objects-pvc.yaml @@ -1,5 +1,5 @@ -kind: PersistentVolumeClaim apiVersion: v1 +kind: PersistentVolumeClaim metadata: name: pvc-quota-demo spec: diff --git a/content/zh/examples/admin/sched/my-scheduler.yaml b/content/zh/examples/admin/sched/my-scheduler.yaml index ab0c385cd6..4903c6f54c 100644 --- a/content/zh/examples/admin/sched/my-scheduler.yaml +++ b/content/zh/examples/admin/sched/my-scheduler.yaml @@ -1,67 +1,67 @@ -apiVersion: v1 -kind: ServiceAccount -metadata: - name: my-scheduler - namespace: kube-system ---- -kind: ClusterRoleBinding -apiVersion: rbac.authorization.k8s.io/v1 -metadata: - name: my-scheduler-as-kube-scheduler -subjects: -- kind: ServiceAccount - name: my-scheduler - namespace: kube-system -roleRef: - kind: ClusterRole - name: kube-scheduler - apiGroup: rbac.authorization.k8s.io ---- -apiVersion: apps/v1 -kind: Deployment -metadata: - labels: - component: scheduler - tier: control-plane - name: my-scheduler - namespace: kube-system -spec: - selector: - matchLabels: - component: scheduler - tier: control-plane - replicas: 1 - template: - metadata: - labels: - component: scheduler - tier: control-plane - version: second - spec: - serviceAccountName: my-scheduler - containers: - - command: - - /usr/local/bin/kube-scheduler - - --address=0.0.0.0 - - --leader-elect=false - - --scheduler-name=my-scheduler - image: gcr.io/my-gcp-project/my-kube-scheduler:1.0 - livenessProbe: - httpGet: - path: /healthz - port: 10251 - initialDelaySeconds: 15 - name: kube-second-scheduler - readinessProbe: - httpGet: - path: /healthz - port: 10251 - resources: - requests: - cpu: '0.1' - securityContext: - privileged: false - volumeMounts: [] - hostNetwork: false - hostPID: false - volumes: [] +apiVersion: v1 +kind: ServiceAccount +metadata: + name: my-scheduler + namespace: kube-system +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: my-scheduler-as-kube-scheduler +subjects: +- kind: ServiceAccount + name: my-scheduler + namespace: kube-system +roleRef: + kind: ClusterRole + name: system:kube-scheduler + apiGroup: rbac.authorization.k8s.io +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + component: scheduler + tier: control-plane + name: my-scheduler + namespace: kube-system +spec: + selector: + matchLabels: + component: scheduler + tier: control-plane + replicas: 1 + template: + metadata: + labels: + component: scheduler + tier: control-plane + version: second + spec: + serviceAccountName: my-scheduler + containers: + - command: + - /usr/local/bin/kube-scheduler + - --address=0.0.0.0 + - --leader-elect=false + - --scheduler-name=my-scheduler + image: gcr.io/my-gcp-project/my-kube-scheduler:1.0 + livenessProbe: + httpGet: + path: /healthz + port: 10251 + initialDelaySeconds: 15 + name: kube-second-scheduler + readinessProbe: + httpGet: + path: /healthz + port: 10251 + resources: + requests: + cpu: '0.1' + securityContext: + privileged: false + volumeMounts: [] + hostNetwork: false + hostPID: false + volumes: [] From 870128c48f3e99f75daad33bd8556a63ebe5a79d Mon Sep 17 00:00:00 2001 From: 2BFL Date: Sun, 22 Mar 2020 20:06:44 +0800 Subject: [PATCH 179/194] zh-translation: upate hello-minikube.md (#19660) Fix missing items --- content/zh/docs/tutorials/hello-minikube.md | 394 ++++++++---------- .../tutorials/kubernetes-basics/_index.html | 5 + 2 files changed, 169 insertions(+), 230 deletions(-) diff --git a/content/zh/docs/tutorials/hello-minikube.md b/content/zh/docs/tutorials/hello-minikube.md index a8587d6967..c10be6b6f9 100644 --- a/content/zh/docs/tutorials/hello-minikube.md +++ b/content/zh/docs/tutorials/hello-minikube.md @@ -30,12 +30,13 @@ card: --> {{% capture overview %}} + -本教程向您展示如何使用 [Minikube](/docs/getting-started-guides/minikube) 和 Katacoda 在 Kubernetes 上运行一个简单的 “Hello World” Node.js 应用程序。Katacoda 提供免费的浏览器内 Kubernetes 环境。 +本教程向您展示如何使用 [Minikube](/docs/setup/learning-environment/minikube) 和 Katacoda 在 Kubernetes 上运行一个简单的 “Hello World” Node.js 应用程序。Katacoda 提供免费的浏览器内 Kubernetes 环境。 {{< note >}} @@ -68,6 +71,7 @@ This tutorial provides a container image built from the following files: {{< codenew language="js" file="minikube/server.js" >}} {{< codenew language="conf" file="minikube/Dockerfile" >}} + @@ -81,39 +85,36 @@ For more information on the `docker build` command, read the [Docker documentati ## Create a Minikube cluster 1. Click **Launch Terminal** +--> +## 创建 Minikube 集群 + +1. 点击 **启动终端** {{< kat-button >}} {{< note >}}If you installed Minikube locally, run `minikube start`.{{< /note >}} + -## 创建 Minikube 集群 - -1. 点击 **启动终端** - {{< kat-button >}} - - {{< note >}}如果您本地安装了 Minikube, 运行 `minikube start`.{{< /note >}} - 2. 在浏览器中打开 Kubernetes dashboard： ```shell minikube dashboard ``` + + 3. 仅限 Katacoda 环境：在终端窗口的顶部，单击加号，然后单击 **选择要在主机 1 上查看的端口**。 4. 仅限 Katacoda 环境：输入“30000”，然后单击 **显示端口**。 + ## 创建 Deployment Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) 是由一个或多个为了管理和联网而绑定在一起的容器构成的组。本教程中的 Pod 只有一个容器。Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) 检查 Pod 的健康状况，并在 Pod 中的容器终止的情况下重新启动新的容器。Deployment 是管理 Pod 创建和扩展的推荐方法。 + + 1. 使用 `kubectl create` 命令创建管理 Pod 的 Deployment。该 Pod 根据提供的 Docker 镜像运行 Container。 ```shell kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node ``` + + 2. 查看 Deployment： ```shell kubectl get deployments ``` - 输出: + + + 输出结果类似于这样： - ```shell - NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE - hello-node 1 1 1 1 1m ``` + NAME READY UP-TO-DATE AVAILABLE AGE + hello-node 1/1 1 1 1m + ``` + + 3. 查看 Pod： ```shell kubectl get pods ``` - 输出: - ```shell + + + 输出结果类似于这样： + + ``` NAME READY STATUS RESTARTS AGE hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m ``` + + 4. 查看集群事件： ```shell kubectl get events ``` + + 5. 查看 `kubectl` 配置： ```shell kubectl config view ``` + + {{< note >}}有关 kubectl 命令的更多信息，请参阅 [kubectl 概述](/docs/user-guide/kubectl-overview/)。{{< /note >}} + ## 创建 Service 默认情况下，Pod 只能通过 Kubernetes 集群中的内部 IP 地址访问。要使得 `hello-node` 容器可以从 Kubernetes 虚拟网络的外部访问，您必须将 Pod 暴露为 Kubernetes [*Service*](/docs/concepts/services-networking/service/)。 + + 1. 使用 `kubectl expose` 命令将 Pod 暴露给公网： ```shell @@ -278,117 +233,69 @@ Kubernetes [*Service*](/docs/concepts/services-networking/service/). The `--type=LoadBalancer` flag indicates that you want to expose your Service outside of the cluster. + + 2. 查看您刚刚创建的服务: ```shell kubectl get services ``` - 输出: + - ```shell + 输出结果类似于这样: + + ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-node LoadBalancer 10.108.144.78 8080:30369/TCP 21s kubernetes ClusterIP 10.96.0.1 443/TCP 23m ``` + 在支持负载均衡器的云服务提供商上，将提供一个外部 IP 来访问该服务。在 Minikube 上，`LoadBalancer` 使得服务可以通过命令 `minikube service` 访问。 + 3. 运行下面的命令： ```shell minikube service hello-node ``` + 4. 仅限 Katacoda 环境：单击加号，然后单击 **选择要在主机 1 上查看的端口**。 -5. 仅限 Katacoda 环境：输入 `30369`（请参阅服务输出中与 `8080` 相对的端口），然后单击 + +5. 仅限 Katacoda 环境：请注意在 service 输出中与 `8080` 对应的长度为 5 位的端口号。此端口号是随机生成的，可能与您不同。在端口号文本框中输入您自己的端口号，然后单击显示端口。如果是上面那个例子，就需要输入 `30369`。 这将打开一个浏览器窗口，为您的应用程序提供服务并显示 “Hello World” 消息。 ## 启用插件 -Minikube 有一组内置的插件，可以在本地 Kubernetes 环境中启用、禁用和打开。 +Minikube 有一组内置的 {{< glossary_tooltip text="插件" term_id="addons" >}}，可以在本地 Kubernetes 环境中启用、禁用和打开。 1. 列出当前支持的插件： @@ -396,37 +303,55 @@ Minikube 有一组内置的插件，可以在本地 Kubernetes 环境中启用 minikube addons list ``` - 输出: + - ```shell + 输出结果类似于这样： + + ``` addon-manager: enabled - coredns: disabled dashboard: enabled default-storageclass: enabled efk: disabled freshpod: disabled - heapster: disabled + gvisor: disabled + helm-tiller: disabled ingress: disabled - kube-dns: enabled + ingress-dns: disabled + logviewer: disabled metrics-server: disabled nvidia-driver-installer: disabled nvidia-gpu-device-plugin: disabled registry: disabled registry-creds: disabled storage-provisioner: enabled + storage-provisioner-gluster: disabled ``` -2. 启用插件，例如 `heapster`： + + +2. 启用插件，例如 `metrics-server`： ```shell - minikube addons enable heapster + minikube addons enable metrics-server ``` - 输出: + + + 输出结果类似于这样： - ```shell - heapster was successfully enabled ``` + metrics-server was successfully enabled + ``` + + 3. 查看刚才创建的 Pod 和 Service： @@ -434,59 +359,60 @@ Minikube 有一组内置的插件，可以在本地 Kubernetes 环境中启用 kubectl get pod,svc -n kube-system ``` - 输出: + - ```shell + 输出结果类似于这样： + + ``` NAME READY STATUS RESTARTS AGE - pod/heapster-9jttx 1/1 Running 0 26s + pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m + pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m + pod/metrics-server-67fb648c5 1/1 Running 0 26s + pod/etcd-minikube 1/1 Running 0 34m pod/influxdb-grafana-b29w8 2/2 Running 0 26s pod/kube-addon-manager-minikube 1/1 Running 0 34m - pod/kube-dns-6dcb57bcc8-gv7mw 3/3 Running 0 34m - pod/kubernetes-dashboard-5498ccf677-cgspw 1/1 Running 0 34m + pod/kube-apiserver-minikube 1/1 Running 0 34m + pod/kube-controller-manager-minikube 1/1 Running 0 34m + pod/kube-proxy-rnlps 1/1 Running 0 34m + pod/kube-scheduler-minikube 1/1 Running 0 34m pod/storage-provisioner 1/1 Running 0 34m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - service/heapster ClusterIP 10.96.241.45 80/TCP 26s + service/metrics-server ClusterIP 10.96.241.45 80/TCP 26s service/kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP 34m - service/kubernetes-dashboard NodePort 10.109.29.1 80:30000/TCP 34m service/monitoring-grafana NodePort 10.99.24.54 80:30002/TCP 26s service/monitoring-influxdb ClusterIP 10.111.169.94 8083/TCP,8086/TCP 26s ``` -4. 禁用 `heapster`： + + +4. 禁用 `metrics-server`： + ```shell - minikube addons disable heapster + minikube addons disable metrics-server ``` - 输出: + - ```shell - heapster was successfully disabled + 输出结果类似于这样： + + ``` + metrics-server was successfully disabled ``` + ## 清理 现在可以清理您在集群中创建的资源： @@ -496,13 +422,21 @@ kubectl delete service hello-node kubectl delete deployment hello-node ``` -可以停止 Minikube VM： + + +可选的，停止 Minikube 虚拟机（VM）： ```shell minikube stop ``` -或者，删除 Minikube VM： + + +可选的，删除 Minikube 虚拟机（VM）： ```shell minikube delete @@ -514,11 +448,11 @@ minikube delete * 进一步了解 [Deployment 对象](/docs/concepts/workloads/controllers/deployment/)。 -* 学习更多关于 [部署应用](/docs/user-guide/deploying-applications/)。 +* 学习更多关于 [部署应用](/docs/tasks/run-application/run-stateless-application-deployment/)。 * 学习更多关于 [Service 对象](/docs/concepts/services-networking/service/)。 {{% /capture %}} diff --git a/content/zh/docs/tutorials/kubernetes-basics/_index.html b/content/zh/docs/tutorials/kubernetes-basics/_index.html index ecfbbd626a..39b52b2ce1 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/_index.html +++ b/content/zh/docs/tutorials/kubernetes-basics/_index.html @@ -1,6 +1,11 @@ --- title: 学习 Kubernetes 基础知识 linkTitle: 学习 Kubernetes 基础知识 +weight: 10 +card: + name: tutorials + weight: 20 + title: 基础知识介绍 --- From 3cd0b293017cc2bfc1dac8ea5ccfe4ae65695f33 Mon Sep 17 00:00:00 2001 From: Rajesh Deshpande Date: Mon, 23 Mar 2020 00:38:45 +0530 Subject: [PATCH 180/194] Add new reviewer for sig-docs-en-reviews (#19661) * Adding reviewer for sig-docs-en-reviews Adding reviewer for sig-docs-en-reviews * Adding new entry following alphabetical sort order Adding new entry following alphabetical sort order --- OWNERS_ALIASES | 1 + 1 file changed, 1 insertion(+) diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 43f27a88b2..9bc9a38f16 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -64,6 +64,7 @@ aliases: - makoscafee - onlydole - rajakavitha1 + - rajeshdeshpande02 - sftim - steveperry-53 - tengqm From d7e94ea4b8f9ea693559312ff7c36beac1ed43ef Mon Sep 17 00:00:00 2001 From: Yong Zhang Date: Mon, 23 Mar 2020 04:50:44 +0800 Subject: [PATCH 181/194] =?UTF-8?q?Localize=20=E2=80=9Cemail=20address?= =?UTF-8?q?=E2=80=9D=20placeholder=20on=20home=20page=20(#19362)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Localize “email address” placeholder on home page * Apply suggestions from code review Co-authored-by: inductor --- i18n/ja.toml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/i18n/ja.toml b/i18n/ja.toml index 61f802b84d..a80eac684f 100644 --- a/i18n/ja.toml +++ b/i18n/ja.toml @@ -186,3 +186,6 @@ other = "次の項目" [warning] other = "警告:" + +[input_placeholder_email_address] +other = "メールアドレス" From 97849f96e3680c0e36eaa94df934e6a1c1899af0 Mon Sep 17 00:00:00 2001 From: Ihor Sychevskyi <26163841+Arhell@users.noreply.github.com> Date: Sun, 22 Mar 2020 23:06:44 +0200 Subject: [PATCH 182/194] fix home docs page button on mobile & tablet (#19646) --- assets/sass/_base.sass | 3 +++ content/en/docs/home/_index.md | 2 +- layouts/partials/css.html | 2 +- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/assets/sass/_base.sass b/assets/sass/_base.sass index c5a576995c..7384fe36c0 100644 --- a/assets/sass/_base.sass +++ b/assets/sass/_base.sass @@ -1052,6 +1052,9 @@ dd a.issue margin-left: 0px +.gridPageHome .flyout-button + display: none + .feedback--no margin-left: 1em diff --git a/content/en/docs/home/_index.md b/content/en/docs/home/_index.md index 692f10dbef..dcaf693039 100644 --- a/content/en/docs/home/_index.md +++ b/content/en/docs/home/_index.md @@ -5,7 +5,7 @@ title: Kubernetes Documentation noedit: true cid: docsHome layout: docsportal_home -class: gridPage +class: gridPage gridPageHome linkTitle: "Home" main_menu: true weight: 10 diff --git a/layouts/partials/css.html b/layouts/partials/css.html index b4aadaed4f..5b85f9409a 100644 --- a/layouts/partials/css.html +++ b/layouts/partials/css.html @@ -22,7 +22,7 @@ {{- if .Params.deprecated }} {{- end }} -{{- if eq .Params.class "gridPage" }} +{{- if or (eq .Params.class "gridPage") (eq .Params.class "gridPage gridPageHome") }} {{- end }} {{- if eq .Params.class "training" }} From 06029f5a1b897b6be721abf81d715cf26f42f705 Mon Sep 17 00:00:00 2001 From: Sascha Grunert Date: Sun, 22 Mar 2020 22:10:45 +0100 Subject: [PATCH 183/194] Update CRI-O installation guide (#19568) CRI-O now uses a different location for their repositories which also supports further distributions. Signed-off-by: Sascha Grunert --- .../container-runtimes.md | 39 ++++++++++++++----- 1 file changed, 30 insertions(+), 9 deletions(-) diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index 493e2ae5ef..f51ada8f6d 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -184,27 +184,48 @@ sysctl --system ``` {{< tabs name="tab-cri-cri-o-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} +{{< tab name="Debian" codelang="bash" >}} +# Debian Unstable/Sid +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - -# Install prerequisites -apt-get update -apt-get install -y software-properties-common +# Debian Testing +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - -add-apt-repository ppa:projectatomic/ppa -apt-get update +# Debian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - + +# Raspbian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - # Install CRI-O -apt-get install -y cri-o-1.15 - +sudo apt-get install cri-o-1.17 {{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +{{< tab name="Ubuntu 18.04, 19.04 and 19.10" codelang="bash" >}} +# Setup 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 + +# Install CRI-O +sudo apt-get install cri-o-1.17 +{{< /tab >}} + +{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} # Install prerequisites yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/ # Install CRI-O yum install --nogpgcheck -y cri-o +{{< /tab >}} +{{< tab name="openSUSE Tumbleweed" codelang="bash" >}} +sudo zypper install cri-o {{< /tab >}} {{< /tabs >}} From 489d44d7bda8f391eab2eb9ef3575c16d949eac6 Mon Sep 17 00:00:00 2001 From: Roy Lenferink Date: Sun, 22 Mar 2020 22:24:44 +0100 Subject: [PATCH 184/194] Adding fix for #19646 (#19727) --- content/de/docs/home/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/de/docs/home/_index.md b/content/de/docs/home/_index.md index e8d87597a6..128cd67c2e 100644 --- a/content/de/docs/home/_index.md +++ b/content/de/docs/home/_index.md @@ -3,7 +3,7 @@ title: Kubernetes Dokumentation noedit: true cid: docsHome layout: docsportal_home -class: gridPage +class: gridPage gridPageHome linkTitle: "Home" main_menu: true weight: 10 From 7375753caee0f1c99caae3777e1489e296ee4a15 Mon Sep 17 00:00:00 2001 From: Ihor Sychevskyi <26163841+Arhell@users.noreply.github.com> Date: Mon, 23 Mar 2020 00:36:44 +0200 Subject: [PATCH 185/194] fix vendorStrip block on mobile (#19716) --- assets/sass/_base.sass | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/assets/sass/_base.sass b/assets/sass/_base.sass index 7384fe36c0..c59d20c346 100644 --- a/assets/sass/_base.sass +++ b/assets/sass/_base.sass @@ -578,6 +578,9 @@ section li display: inline-block height: 100% + margin-right: 10px + &:last-child + margin-right: 0 a display: block @@ -598,11 +601,11 @@ section #vendorStrip line-height: 44px max-width: 100% - overflow-x: auto -webkit-overflow-scrolling: touch ul float: none + overflow-x: auto #searchBox float: none From 9a332233c0c702597df44b5dd99ee909066defc1 Mon Sep 17 00:00:00 2001 From: chentanjun <2799194073@qq.com> Date: Mon, 23 Mar 2020 11:30:45 +0800 Subject: [PATCH 186/194] sync en zh example yaml (#19779) --- .../zh/examples/controllers/daemonset.yaml | 86 +- content/zh/examples/controllers/frontend.yaml | 59 +- .../controllers/nginx-deployment.yaml | 42 +- .../examples/debug/fluentd-gcp-configmap.yaml | 758 +++++++++--------- .../examples/podpreset/allow-db-merged.yaml | 68 +- content/zh/examples/podpreset/allow-db.yaml | 54 +- .../service/access/hello-service.yaml | 24 +- .../examples/service/networking/ingress.yaml | 18 +- .../service/networking/nginx-secure-app.yaml | 97 +-- 9 files changed, 592 insertions(+), 614 deletions(-) diff --git a/content/zh/examples/controllers/daemonset.yaml b/content/zh/examples/controllers/daemonset.yaml index 1bfa082833..a7e895a9cf 100644 --- a/content/zh/examples/controllers/daemonset.yaml +++ b/content/zh/examples/controllers/daemonset.yaml @@ -1,42 +1,44 @@ -apiVersion: apps/v1 -kind: DaemonSet -metadata: - name: fluentd-elasticsearch - namespace: kube-system - labels: - k8s-app: fluentd-logging -spec: - selector: - matchLabels: - name: fluentd-elasticsearch - template: - metadata: - labels: - name: fluentd-elasticsearch - spec: - tolerations: - - key: node-role.kubernetes.io/master - effect: NoSchedule - containers: - - name: fluentd-elasticsearch - image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 - resources: - limits: - memory: 200Mi - requests: - cpu: 100m - memory: 200Mi - volumeMounts: - - name: varlog - mountPath: /var/log - - name: varlibdockercontainers - mountPath: /var/lib/docker/containers - readOnly: true - terminationGracePeriodSeconds: 30 - volumes: - - name: varlog - hostPath: - path: /var/log - - name: varlibdockercontainers - hostPath: - path: /var/lib/docker/containers +apiVersion: apps/v1 +kind: DaemonSet +metadata: + name: fluentd-elasticsearch + namespace: kube-system + labels: + k8s-app: fluentd-logging +spec: + selector: + matchLabels: + name: fluentd-elasticsearch + template: + metadata: + labels: + name: fluentd-elasticsearch + spec: + tolerations: + # this toleration is to have the daemonset runnable on master nodes + # remove it if your masters can't run pods + - key: node-role.kubernetes.io/master + effect: NoSchedule + containers: + - name: fluentd-elasticsearch + image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 + resources: + limits: + memory: 200Mi + requests: + cpu: 100m + memory: 200Mi + volumeMounts: + - name: varlog + mountPath: /var/log + - name: varlibdockercontainers + mountPath: /var/lib/docker/containers + readOnly: true + terminationGracePeriodSeconds: 30 + volumes: + - name: varlog + hostPath: + path: /var/log + - name: varlibdockercontainers + hostPath: + path: /var/lib/docker/containers diff --git a/content/zh/examples/controllers/frontend.yaml b/content/zh/examples/controllers/frontend.yaml index f9dba82b7e..fd7665c7f3 100644 --- a/content/zh/examples/controllers/frontend.yaml +++ b/content/zh/examples/controllers/frontend.yaml @@ -1,38 +1,21 @@ -apiVersion: apps/v1 -kind: ReplicaSet -metadata: - name: frontend - labels: - app: guestbook - tier: frontend -spec: - # modify replicas according to your case - replicas: 3 - selector: - matchLabels: - tier: frontend - matchExpressions: - - {key: tier, operator: In, values: [frontend]} - template: - metadata: - labels: - app: guestbook - tier: frontend - spec: - containers: - - name: php-redis - image: gcr.io/google_samples/gb-frontend:v3 - resources: - requests: - cpu: 100m - memory: 100Mi - env: - - name: GET_HOSTS_FROM - value: dns - # If your cluster config does not include a dns service, then to - # instead access environment variables to find service host - # info, comment out the 'value: dns' line above, and uncomment the - # line below. - # value: env - ports: - - containerPort: 80 +apiVersion: apps/v1 +kind: ReplicaSet +metadata: + name: frontend + labels: + app: guestbook + tier: frontend +spec: + # modify replicas according to your case + replicas: 3 + selector: + matchLabels: + tier: frontend + template: + metadata: + labels: + tier: frontend + spec: + containers: + - name: php-redis + image: gcr.io/google_samples/gb-frontend:v3 diff --git a/content/zh/examples/controllers/nginx-deployment.yaml b/content/zh/examples/controllers/nginx-deployment.yaml index 5dd80da371..33e68a941f 100644 --- a/content/zh/examples/controllers/nginx-deployment.yaml +++ b/content/zh/examples/controllers/nginx-deployment.yaml @@ -1,21 +1,21 @@ -apiVersion: apps/v1 -kind: Deployment -metadata: - name: nginx-deployment - labels: - app: nginx -spec: - replicas: 3 - selector: - matchLabels: - app: nginx - template: - metadata: - labels: - app: nginx - spec: - containers: - - name: nginx - image: nginx:1.15.4 - ports: - - containerPort: 80 +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + replicas: 3 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 diff --git a/content/zh/examples/debug/fluentd-gcp-configmap.yaml b/content/zh/examples/debug/fluentd-gcp-configmap.yaml index 71e0ac5d82..0235ce551a 100644 --- a/content/zh/examples/debug/fluentd-gcp-configmap.yaml +++ b/content/zh/examples/debug/fluentd-gcp-configmap.yaml @@ -1,379 +1,379 @@ -kind: ConfigMap -apiVersion: v1 -data: - containers.input.conf: |- - # This configuration file for Fluentd is used - # to watch changes to Docker log files that live in the - # directory /var/lib/docker/containers/ and are symbolically - # linked to from the /var/log/containers directory using names that capture the - # pod name and container name. These logs are then submitted to - # Google Cloud Logging which assumes the installation of the cloud-logging plug-in. - # - # Example - # ======= - # A line in the Docker log file might look like this JSON: - # - # {"log":"2014/09/25 21:15:03 Got request with path wombat\\n", - # "stream":"stderr", - # "time":"2014-09-25T21:15:03.499185026Z"} - # - # The record reformer is used to write the tag to focus on the pod name - # and the Kubernetes container name. For example a Docker container's logs - # might be in the directory: - # /var/lib/docker/containers/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b - # and in the file: - # 997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b-json.log - # where 997599971ee6... is the Docker ID of the running container. - # The Kubernetes kubelet makes a symbolic link to this file on the host machine - # in the /var/log/containers directory which includes the pod name and the Kubernetes - # container name: - # synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log - # -> - # /var/lib/docker/containers/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b-json.log - # The /var/log directory on the host is mapped to the /var/log directory in the container - # running this instance of Fluentd and we end up collecting the file: - # /var/log/containers/synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log - # This results in the tag: - # var.log.containers.synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log - # The record reformer is used is discard the var.log.containers prefix and - # the Docker container ID suffix and "kubernetes." is pre-pended giving the tag: - # kubernetes.synthetic-logger-0.25lps-pod_default-synth-lgr - # Tag is then parsed by google_cloud plugin and translated to the metadata, - # visible in the log viewer - - # Example: - # {"log":"[info:2016-02-16T16:04:05.930-08:00] Some log text here\n","stream":"stdout","time":"2016-02-17T00:04:05.931087621Z"} - - type tail - format json - time_key time - path /var/log/containers/*.log - pos_file /var/log/gcp-containers.log.pos - time_format %Y-%m-%dT%H:%M:%S.%N%Z - tag reform.* - read_from_head true - - - - type parser - format /^(?\w)(? - - - type record_reformer - enable_ruby true - tag raw.kubernetes.${tag_suffix[4].split('-')[0..-2].join('-')} - - - # Detect exceptions in the log output and forward them as one log entry. - - @type copy - - - @type prometheus - - - type counter - name logging_line_count - desc Total number of lines generated by application containers - - tag ${tag} - - - - - @type detect_exceptions - - remove_tag_prefix raw - message log - stream stream - multiline_flush_interval 5 - max_bytes 500000 - max_lines 1000 - - - system.input.conf: |- - # Example: - # Dec 21 23:17:22 gke-foo-1-1-4b5cbd14-node-4eoj startupscript: Finished running startup script /var/run/google.startup.script - - type tail - format syslog - path /var/log/startupscript.log - pos_file /var/log/gcp-startupscript.log.pos - tag startupscript - - - # Examples: - # time="2016-02-04T06:51:03.053580605Z" level=info msg="GET /containers/json" - # time="2016-02-04T07:53:57.505612354Z" level=error msg="HTTP Error" err="No such image: -f" statusCode=404 - - type tail - format /^time="(?
-

Węzły typu master zarządzają klastrem, pozostałe węzły są wykorzystywane do uruchamiania na nich aplikacji.

+

Węzły typu master zarządzają klastrem i węzłami wykorzystywanymi do uruchamiania aplikacji.

From 6848ca460044f7fa86242c752cda3eecbc3665a2 Mon Sep 17 00:00:00 2001 From: Alexey Pyltsyn Date: Mon, 23 Mar 2020 13:56:45 +0300 Subject: [PATCH 190/194] Fix Russian translation for "control plane" term (#19802) --- content/ru/docs/concepts/_index.md | 8 ++++---- .../ru/docs/concepts/overview/components.md | 2 +- .../ru/docs/contribute/style/style-guide.md | 2 +- content/ru/docs/reference/glossary/cluster.md | 2 +- content/ru/docs/reference/glossary/node.md | 2 +- .../setup/learning-environment/minikube.md | 2 +- content/ru/docs/tutorials/hello-minikube.md | 20 +++++++++---------- 7 files changed, 19 insertions(+), 19 deletions(-) diff --git a/content/ru/docs/concepts/_index.md b/content/ru/docs/concepts/_index.md index 997a1b2b59..b2e7e77c79 100644 --- a/content/ru/docs/concepts/_index.md +++ b/content/ru/docs/concepts/_index.md @@ -17,7 +17,7 @@ weight: 40 Чтобы работать с Kubernetes, вы используете *объекты API Kubernetes* для описания *желаемого состояния вашего кластера*: какие приложения или другие рабочие нагрузки вы хотите запустить, какие образы контейнеров они используют, количество реплик, какие сетевые и дисковые ресурсы вы хотите использовать и сделать доступными и многое другое. Вы устанавливаете желаемое состояние, создавая объекты с помощью API Kubernetes, обычно через интерфейс командной строки `kubectl`. Вы также можете напрямую использовать API Kubernetes для взаимодействия с кластером и установки или изменения желаемого состояния. -После того, как вы установили желаемое состояние, *Панель управления Kubernetes* заставляет текущее состояние кластера соответствовать желаемому состоянию с помощью генератора событий жизненного цикла подов ([Pod Lifecycle Event Generator, PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). Для этого Kubernetes автоматически выполняет множество задач, таких как запуск или перезапуск контейнеров, масштабирование количества реплик данного приложения и многое другое. Плоскость управления Kubernetes состоит из набора процессов, запущенных в вашем кластере: +После того, как вы установили желаемое состояние, *Плоскость управления Kubernetes* заставляет текущее состояние кластера соответствовать желаемому состоянию с помощью генератора событий жизненного цикла подов ([Pod Lifecycle Event Generator, PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). Для этого Kubernetes автоматически выполняет множество задач, таких как запуск или перезапуск контейнеров, масштабирование количества реплик данного приложения и многое другое. Плоскость управления Kubernetes состоит из набора процессов, запущенных в вашем кластере: * **Мастер Kubernetes** — это коллекция из трех процессов, которые выполняются на одном узле в вашем кластере, который обозначен как главный узел. Это процессы: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) и [kube-scheduler](/docs/admin/kube-scheduler/). * Каждый отдельный неосновной узел в вашем кластере выполняет два процесса: @@ -43,11 +43,11 @@ Kubernetes также содержит абстракции более высо * [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) -## Панель управления Kubernetes +## Плоскость управления Kubernetes -Различные части панели управления Kubernetes, такие как мастер Kubernetes и процессы kubelet, определяют, как Kubernetes взаимодействует с кластером. Панель управления поддерживает запись всех объектов Kubernetes в системе и запускает непрерывные циклы управления для обработки состояния этих объектов. В любое время циклы управления панели управления будут реагировать на изменения в кластере и работать, чтобы фактическое состояние всех объектов в системе соответствовало желаемому состоянию, которое вы указали. +Различные части панели управления Kubernetes, такие как мастер Kubernetes и процессы kubelet, определяют, как Kubernetes взаимодействует с кластером. Плоскость управления поддерживает запись всех объектов Kubernetes в системе и запускает непрерывные циклы управления для обработки состояния этих объектов. В любое время циклы управления панели управления будут реагировать на изменения в кластере и работать, чтобы фактическое состояние всех объектов в системе соответствовало желаемому состоянию, которое вы указали. -Например, когда вы используете API Kubernetes для создания развертывания, вы предоставляете новое желаемое состояние для системы. Панель управления Kubernetes записывает создание этого объекта и выполняет ваши инструкции, запуская необходимые приложения и планируя их на узлы кластера, чтобы фактическое состояние кластера соответствовало желаемому состоянию. +Например, когда вы используете API Kubernetes для создания развертывания, вы предоставляете новое желаемое состояние для системы. Плоскость управления Kubernetes записывает создание этого объекта и выполняет ваши инструкции, запуская необходимые приложения и планируя их на узлы кластера, чтобы фактическое состояние кластера соответствовало желаемому состоянию. ### Мастер Kubernetes diff --git a/content/ru/docs/concepts/overview/components.md b/content/ru/docs/concepts/overview/components.md index 9689c2e1fd..d1e417cd85 100644 --- a/content/ru/docs/concepts/overview/components.md +++ b/content/ru/docs/concepts/overview/components.md @@ -23,7 +23,7 @@ card: {{% capture body %}} -## Панель управления компонентами +## Плоскость управления компонентами Компоненты панели управления отвечают за основные операции кластера (например, планирование), а также обрабатывают события кластера (например, запускают новый {{< glossary_tooltip text="под" term_id="pod">}}, когда поле `replicas` развертывания не соответствует требуемому количеству реплик). diff --git a/content/ru/docs/contribute/style/style-guide.md b/content/ru/docs/contribute/style/style-guide.md index 612111c673..5a74f1ed0f 100644 --- a/content/ru/docs/contribute/style/style-guide.md +++ b/content/ru/docs/contribute/style/style-guide.md @@ -74,7 +74,7 @@ PodList — это список Pod. | Pod List — это список подо Можно | Нельзя :--| :----- _Кластер_ — это набор узлов ... | "Кластер" — это набор узлов ... -Эти компоненты формируют _панель управления_. | Эти компоненты формируют **панель управления**. +Эти компоненты формируют _плоскость управления_. | Эти компоненты формируют **плоскость управления**. {{< /table >}} ### Оформляйте как код имена файлов, директории и пути diff --git a/content/ru/docs/reference/glossary/cluster.md b/content/ru/docs/reference/glossary/cluster.md index 79e10c8fcc..00c5609b48 100644 --- a/content/ru/docs/reference/glossary/cluster.md +++ b/content/ru/docs/reference/glossary/cluster.md @@ -14,4 +14,4 @@ tags: Набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел. -В рабочих узлах размещены поды, являющиеся компонентами приложения. Панель управления управляет рабочими узлами и подами в кластере. В промышленных средах панель управления обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность. +В рабочих узлах размещены поды, являющиеся компонентами приложения. Плоскость управления управляет рабочими узлами и подами в кластере. В промышленных средах плоскость управления обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность. diff --git a/content/ru/docs/reference/glossary/node.md b/content/ru/docs/reference/glossary/node.md index 0a2cc77e62..34f68b99b0 100755 --- a/content/ru/docs/reference/glossary/node.md +++ b/content/ru/docs/reference/glossary/node.md @@ -14,4 +14,4 @@ tags: -Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< glossary_tooltip text="подов" term_id="pod" >}}, а сам он управляется панелью управления. Демоны на узле включают в себя {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} и среду выполнения контейнера, основанную на {{< glossary_tooltip text="CRI" term_id="cri" >}}, например {{< glossary_tooltip term_id="docker" >}}. +Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< glossary_tooltip text="подов" term_id="pod" >}}, а сам он управляется плоскостью управления. Демоны на узле включают в себя {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} и среду выполнения контейнера, основанную на {{< glossary_tooltip text="CRI" term_id="cri" >}}, например {{< glossary_tooltip term_id="docker" >}}. diff --git a/content/ru/docs/setup/learning-environment/minikube.md b/content/ru/docs/setup/learning-environment/minikube.md index 1e0cb02673..586a491ad3 100644 --- a/content/ru/docs/setup/learning-environment/minikube.md +++ b/content/ru/docs/setup/learning-environment/minikube.md @@ -386,7 +386,7 @@ kubectl config use-context minikube ### Панель управления -Чтобы получить доступ к [панели управления Kubernetes](/docs/tasks/access-application-cluster/web-ui-dashboard/), запустите эту команду в командной оболочке после запуска Minikube, чтобы получить адрес: +Чтобы получить доступ к [веб-панели управления Kubernetes](/docs/tasks/access-application-cluster/web-ui-dashboard/), запустите эту команду в командной оболочке после запуска Minikube, чтобы получить адрес: ```shell minikube dashboard diff --git a/content/ru/docs/tutorials/hello-minikube.md b/content/ru/docs/tutorials/hello-minikube.md index 845ccc3600..7bbb5b0f2b 100644 --- a/content/ru/docs/tutorials/hello-minikube.md +++ b/content/ru/docs/tutorials/hello-minikube.md @@ -8,7 +8,7 @@ menu: weight: 10 post: >

Готовы испачкать руки? Создайте простой кластер Kubernetes с запуском "Hello World" на Node.js

-card: +card: name: tutorials weight: 10 --- @@ -17,7 +17,7 @@ card: Это руководство покажет вам, как запустить простое Hello World Node.js приложение на Kubernetes используя [Minikube](/docs/getting-started-guides/minikube) и Katacoda. -Katacoda предоставляет бесплатную, встроенную в браузер Kubernetes среду. +Katacoda предоставляет бесплатную, встроенную в браузер Kubernetes среду. {{< note >}} Вы также можете следовать этому руководству, если вы установили [Minikube locally](/docs/tasks/tools/install-minikube/). @@ -49,13 +49,13 @@ Katacoda предоставляет бесплатную, встроенную ## Создание кластера Minikube -1. Нажмите **Запуск Терминала** +1. Нажмите **Запуск Терминала** {{< kat-button >}} {{< note >}}Если у вас локально установлен Minikube, выполните `minikube start`.{{< /note >}} -2. Откройте панель Kubernetes в браузере: +2. Откройте веб-панель Kubernetes в браузере: ```shell minikube dashboard @@ -111,7 +111,7 @@ Katacoda предоставляет бесплатную, встроенную ```shell kubectl config view ``` - + {{< note >}}Больше информации о командах `kubectl` можно найти по ссылке [обзор kubectl](/docs/user-guide/kubectl-overview/).{{< /note >}} ## Создание сервиса @@ -123,7 +123,7 @@ Katacoda предоставляет бесплатную, встроенную ```shell kubectl expose deployment hello-node --type=LoadBalancer --port=8080 ``` - + Флаг `--type=LoadBalancer` показывает, что сервис должен быть виден вне кластера. 2. Посмотреть только что созданный сервис: @@ -150,7 +150,7 @@ Katacoda предоставляет бесплатную, встроенную 4. Только для окружения Katacoda: Нажмите на знак "Плюс", затем нажмите **Select port to view on Host 1**. -5. Только для окружения Katacoda: Введите `30369` (порт указан рядом с `8080` в выводе сервиса), затем нажмите ???. +5. Только для окружения Katacoda: Введите `30369` (порт указан рядом с `8080` в выводе сервиса), затем нажмите ???. Откроется окно браузера, в котором запущено ваше приложение и будет отображено сообщение "Hello World". @@ -186,13 +186,13 @@ Katacoda предоставляет бесплатную, встроенную storage-provisioner: enabled storage-provisioner-gluster: disabled ``` - + 2. Включить дополнение, например, `metrics-server`: ```shell minikube addons enable metrics-server ``` - + Вывод: ```shell @@ -233,7 +233,7 @@ Katacoda предоставляет бесплатную, встроенную ```shell minikube addons disable metrics-server ``` - + Вывод: ```shell From 9b1c863e1f5a25f21131ab4e85c0daff5266706e Mon Sep 17 00:00:00 2001 From: Jacky Wu Date: Mon, 23 Mar 2020 20:04:45 +0800 Subject: [PATCH 191/194] fix: make update-imported-docs.py works on macOS. (#19667) --- update-imported-docs/update-imported-docs.py | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/update-imported-docs/update-imported-docs.py b/update-imported-docs/update-imported-docs.py index dbbc408f4e..7f7c420173 100755 --- a/update-imported-docs/update-imported-docs.py +++ b/update-imported-docs/update-imported-docs.py @@ -33,12 +33,14 @@ import shutil import subprocess import sys import tempfile +import platform error_msgs = [] # pip should be installed when Python is installed, but just in case... if not (shutil.which('pip') or shutil.which('pip3')): - error_msgs.append("Install pip so you can install PyYAML. https://pip.pypa.io/en/stable/installing") + error_msgs.append( + "Install pip so you can install PyYAML. https://pip.pypa.io/en/stable/installing") reqs = subprocess.check_output([sys.executable, '-m', 'pip', 'freeze']) installed_packages = [r.decode().split('==')[0] for r in reqs.split()] @@ -203,7 +205,9 @@ def main(): # create the temp work_dir try: print("Making temp work_dir") - work_dir = tempfile.mkdtemp() + work_dir = tempfile.mkdtemp( + dir='/tmp' if platform.system() == 'Darwin' else tempfile.gettempdir() + ) except OSError as ose: print("[Error] Unable to create temp work_dir {}; error: {}" .format(work_dir, ose)) From d919c58f3511c5703e70e59a55e88f56d4b880b6 Mon Sep 17 00:00:00 2001 From: Jim Angel Date: Mon, 23 Mar 2020 07:16:45 -0500 Subject: [PATCH 192/194] remove vendor specific cpu definition (#19797) --- .../configuration/manage-compute-resources-container.md | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/content/en/docs/concepts/configuration/manage-compute-resources-container.md b/content/en/docs/concepts/configuration/manage-compute-resources-container.md index 576a008ba9..43dec5331c 100644 --- a/content/en/docs/concepts/configuration/manage-compute-resources-container.md +++ b/content/en/docs/concepts/configuration/manage-compute-resources-container.md @@ -68,13 +68,7 @@ resource requests/limits of that type for each Container in the Pod. ## Meaning of CPU Limits and requests for CPU resources are measured in *cpu* units. -One cpu, in Kubernetes, is equivalent to: - -- 1 AWS vCPU -- 1 GCP Core -- 1 Azure vCore -- 1 IBM vCPU -- 1 *Hyperthread* on a bare-metal Intel processor with Hyperthreading +One cpu, in Kubernetes, is equivalent to **1 vCPU/Core** for cloud providers and **1 hyperthread** on bare-metal Intel processors. Fractional requests are allowed. A Container with `spec.containers[].resources.requests.cpu` of `0.5` is guaranteed half as much From 1c263b231449064910fb1dbfa149502f9ab61a2f Mon Sep 17 00:00:00 2001 From: James Spurin Date: Mon, 23 Mar 2020 12:18:45 +0000 Subject: [PATCH 193/194] add note, regarding example requirement for nfs helper /sbin/mount.nfs (#19774) --- content/en/docs/concepts/storage/persistent-volumes.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index a4451f2867..77551398b6 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -312,6 +312,10 @@ spec: server: 172.17.0.2 ``` +{{< note >}} +Helper programs relating to the volume type may be required for consumption of a PersistentVolume within a cluster. In this example, the PersistentVolume is of type NFS and the helper program /sbin/mount.nfs is required to support the mounting of NFS filesystems. +{{< /note >}} + ### Capacity Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. See the Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) to understand the units expected by `capacity`. From fbaeb89823c3d7744aa48251c9148e8a688f6a8d Mon Sep 17 00:00:00 2001 From: Celeste Horgan Date: Mon, 23 Mar 2020 13:22:45 +0100 Subject: [PATCH 194/194] Fix markdown escaping (#19744) Signed-off-by: Celeste Horgan --- .../en/docs/contribute/style/style-guide.md | 94 +++++++++---------- 1 file changed, 47 insertions(+), 47 deletions(-) diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md index 12a6c66839..26722e607f 100644 --- a/content/en/docs/contribute/style/style-guide.md +++ b/content/en/docs/contribute/style/style-guide.md @@ -14,10 +14,10 @@ This page gives writing style guidelines for the Kubernetes documentation. These are guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request. -For additional information on creating new content for the Kubernetes -documentation, read the [Documentation Content -Guide](/docs/contribute/style/content-guide/) and follow the instructions on -[using page templates](/docs/contribute/style/page-templates/) and [creating a +For additional information on creating new content for the Kubernetes +documentation, read the [Documentation Content +Guide](/docs/contribute/style/content-guide/) and follow the instructions on +[using page templates](/docs/contribute/style/page-templates/) and [creating a documentation pull request](/docs/contribute/start/#improve-existing-content). {{% /capture %}} @@ -58,11 +58,11 @@ leads to an awkward construction. {{< table caption = "Do and Don't - API objects" >}} Do | Don't :--| :----- -The Pod has two containers. | The pod has two containers. +The Pod has two containers. | The pod has two containers. The Deployment is responsible for ... | The Deployment object is responsible for ... A PodList is a list of Pods. | A Pod List is a list of pods. -The two ContainerPorts ... | The two ContainerPort objects ... -The two ContainerStateTerminated objects ... | The two ContainerStateTerminateds ... +The two ContainerPorts ... | The two ContainerPort objects ... +The two ContainerStateTerminated objects ... | The two ContainerStateTerminateds ... {{< /table >}} @@ -83,11 +83,11 @@ represents. Do | Don't :--| :----- Click **Fork**. | Click "Fork". -Select **Other**. | Select "Other". +Select **Other**. | Select "Other". {{< /table >}} ### Use italics to define or introduce new terms - + {{< table caption = "Do and Don't - Use italics for new terms" >}} Do | Don't :--| :----- @@ -102,7 +102,7 @@ Do | Don't :--| :----- Open the `envars.yaml` file. | Open the envars.yaml file. Go to the `/docs/tutorials` directory. | Go to the /docs/tutorials directory. -Open the `/_data/concepts.yaml` file. | Open the /_data/concepts.yaml file. +Open the `/_data/concepts.yaml` file. | Open the /\_data/concepts.yaml file. {{< /table >}} ### Use the international standard for punctuation inside quotes @@ -119,18 +119,18 @@ The copy is called a "fork". | The copy is called a "fork." ### Use code style for inline code and commands For inline code in an HTML document, use the `` tag. In a Markdown -document, use the backtick (`). +document, use the backtick (`` ` ``). {{< table caption = "Do and Don't - Use code style for inline code and commands" >}} Do | Don't :--| :----- The `kubectl run`command creates a Deployment. | The "kubectl run" command creates a Deployment. For declarative management, use `kubectl apply`. | For declarative management, use "kubectl apply". -Enclose code samples with triple backticks. `(```)`| Enclose code samples with any other syntax. -Use single backticks to enclose inline code. For example, `var example = true`. | Use two asterisks (**) or an underscore (_) to enclose inline code. For example, **var example = true**. +Enclose code samples with triple backticks. (\`\`\`)| Enclose code samples with any other syntax. +Use single backticks to enclose inline code. For example, `var example = true`. | Use two asterisks (`**`) or an underscore (`_`) to enclose inline code. For example, **var example = true**. Use triple backticks before and after a multi-line block of code for fenced code blocks. | Use multi-line blocks of code to create diagrams, flowcharts, or other illustrations. Use meaningful variable names that have a context. | Use variable names such as 'foo','bar', and 'baz' that are not meaningful and lack context. -Remove trailing spaces in the code. | Add trailing spaces in the code, where these are important, because the screen reader will read out the spaces as well. +Remove trailing spaces in the code. | Add trailing spaces in the code, where these are important, because the screen reader will read out the spaces as well. {{< /table >}} {{< note >}} @@ -185,7 +185,7 @@ Do | Don't Set the value of `imagePullPolicy` to Always. | Set the value of `imagePullPolicy` to "Always". Set the value of `image` to nginx:1.16. | Set the value of `image` to `nginx:1.16`. Set the value of the `replicas` field to 2. | Set the value of the `replicas` field to `2`. -{{< /table >}} +{{< /table >}} ## Code snippet formatting @@ -196,7 +196,7 @@ Set the value of the `replicas` field to 2. | Set the value of the `replicas` fi Do | Don't :--| :----- kubectl get pods | $ kubectl get pods -{{< /table >}} +{{< /table >}} ### Separate commands from output @@ -214,7 +214,7 @@ The output is similar to this: Code examples and configuration examples that include version information should be consistent with the accompanying text. -If the information is version specific, the Kubernetes version needs to be defined in the `prerequisites` section of the [Task template](/docs/contribute/style/page-templates/#task-template) or the [Tutorial template] (/docs/contribute/style/page-templates/#tutorial-template). Once the page is saved, the `prerequisites` section is shown as **Before you begin**. +If the information is version specific, the Kubernetes version needs to be defined in the `prerequisites` section of the [Task template](/docs/contribute/style/page-templates/#task-template) or the [Tutorial template](/docs/contribute/style/page-templates/#tutorial-template). Once the page is saved, the `prerequisites` section is shown as **Before you begin**. To specify the Kubernetes version for a task or tutorial page, include `min-kubernetes-server-version` in the front matter of the page. @@ -251,11 +251,11 @@ Kubernetes | Kubernetes should always be capitalized. Docker | Docker should always be capitalized. SIG Docs | SIG Docs rather than SIG-DOCS or other variations. On-premises | On-premises or On-prem rather than On-premise or other variations. -{{< /table >}} +{{< /table >}} ## Shortcodes -Hugo [Shortcodes](https://gohugo.io/content-management/shortcodes) help create different rhetorical appeal levels. Our documentation supports three different shortcodes in this category: **Note** {{}}, **Caution** {{}}, and **Warning** {{}}. +Hugo [Shortcodes](https://gohugo.io/content-management/shortcodes) help create different rhetorical appeal levels. Our documentation supports three different shortcodes in this category: **Note** `{{}}`, **Caution** `{{}}`, and **Warning** `{{}}`. 1. Surround the text with an opening and closing shortcode. @@ -275,7 +275,7 @@ The prefix you choose is the same text for the tag. ### Note -Use {{}} to highlight a tip or a piece of information that may be helpful to know. +Use `{{}}` to highlight a tip or a piece of information that may be helpful to know. For example: @@ -291,7 +291,7 @@ The output is: You can _still_ use Markdown inside these callouts. {{< /note >}} -You can use a {{}} in a list: +You can use a `{{}}` in a list: ``` 1. Use the note shortcode in a list @@ -323,7 +323,7 @@ The output is: ### Caution -Use {{}} to call attention to an important piece of information to avoid pitfalls. +Use `{{}}` to call attention to an important piece of information to avoid pitfalls. For example: @@ -341,7 +341,7 @@ The callout style only applies to the line directly above the tag. ### Warning -Use {{}} to indicate danger or a piece of information that is crucial to follow. +Use `{{}}` to indicate danger or a piece of information that is crucial to follow. For example: @@ -359,11 +359,11 @@ Beware. ### Katacoda Embedded Live Environment -This button lets users run Minikube in their browser using the [Katacoda Terminal](https://www.katacoda.com/embed/panel). -It lowers the barrier of entry by allowing users to use Minikube with one click instead of going through the complete +This button lets users run Minikube in their browser using the [Katacoda Terminal](https://www.katacoda.com/embed/panel). +It lowers the barrier of entry by allowing users to use Minikube with one click instead of going through the complete Minikube and Kubectl installation process locally. -The Embedded Live Environment is configured to run `minikube start` and lets users complete tutorials in the same window +The Embedded Live Environment is configured to run `minikube start` and lets users complete tutorials in the same window as the documentation. {{< caution >}} @@ -376,7 +376,7 @@ For example: {{}} ``` -The output is: +The output is: {{< kat-button >}} @@ -391,7 +391,7 @@ For example: 1. Preheat oven to 350˚F 1. Prepare the batter, and pour into springform pan. - {{}}Grease the pan for best results.{{}} + `{{}}Grease the pan for best results.{{}}` 1. Bake for 20-25 minutes or until set. @@ -429,9 +429,9 @@ Do | Don't :--| :----- Update the title in the front matter of the page or blog post. | Use first level heading, as Hugo automatically converts the title in the front matter of the page into a first-level heading. Use ordered headings to provide a meaningful high-level outline of your content. | Use headings level 4 through 6, unless it is absolutely necessary. If your content is that detailed, it may need to be broken into separate articles. -Use pound or hash signs (#) for non-blog post content. | Use underlines (--- or ===) to designate first-level headings. +Use pound or hash signs (`#`) for non-blog post content. | Use underlines (`---` or `===`) to designate first-level headings. Use sentence case for headings. For example, **Extend kubectl with plugins** | Use title case for headings. For example, **Extend Kubectl With Plugins** -{{< /table >}} +{{< /table >}} ### Paragraphs @@ -439,8 +439,8 @@ Use sentence case for headings. For example, **Extend kubectl with plugins** | U Do | Don't :--| :----- Try to keep paragraphs under 6 sentences. | Indent the first paragraph with space characters. For example, ⋅⋅⋅Three spaces before a paragraph will indent it. -Use three hyphens (---) to create a horizontal rule. Use horizontal rules for breaks in paragraph content. For example, a change of scene in a story, or a shift of topic within a section. | Use horizontal rules for decoration. -{{< /table >}} +Use three hyphens (`---`) to create a horizontal rule. Use horizontal rules for breaks in paragraph content. For example, a change of scene in a story, or a shift of topic within a section. | Use horizontal rules for decoration. +{{< /table >}} ### Links @@ -449,7 +449,7 @@ Do | Don't :--| :----- Write hyperlinks that give you context for the content they link to. For example: Certain ports are open on your machines. See Check required ports for more details. | Use ambiguous terms such as “click here”. For example: Certain ports are open on your machines. See here for more details. Write Markdown-style links: `[link text](URL)`. For example: `[Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions)` and the output is [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/#table-captions). | Write HTML-style links: `Visit our tutorial!`, or create links that open in new tabs or windows. For example: `[example website](https://example.com){target="_blank"}` -{{< /table >}} +{{< /table >}} ### Lists @@ -457,17 +457,17 @@ Group items in a list that are related to each other and need to appear in a spe Website navigation links can also be marked up as list items; after all they are nothing but a group of related links. - End each item in a list with a period if one or more items in the list are complete sentences. For the sake of consistency, normally either all items or none should be complete sentences. - + {{< note >}} Ordered lists that are part of an incomplete introductory sentence can be in lowercase and punctuated as if each item was a part of the introductory sentence.{{< /note >}} - - - Use the number one (1.) for ordered lists. - - - Use (+), (* ), or (-) for unordered lists. - - - Leave a blank line after each list. - - - Indent nested lists with four spaces (for example, ⋅⋅⋅⋅). - + + - Use the number one (`1.`) for ordered lists. + + - Use (`+`), (`*`), or (`-`) for unordered lists. + + - Leave a blank line after each list. + + - Indent nested lists with four spaces (for example, ⋅⋅⋅⋅). + - List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must be indented by either four spaces or one tab. ### Tables @@ -486,7 +486,7 @@ This section contains suggested best practices for clear, concise, and consisten Do | Don't :--| :----- This command starts a proxy. | This command will start a proxy. - {{< /table >}} + {{< /table >}} Exception: Use future or past tense if it is required to convey the correct @@ -512,7 +512,7 @@ Use simple and direct language. Avoid using unnecessary phrases, such as saying Do | Don't :--| :----- To create a ReplicaSet, ... | In order to create a ReplicaSet, ... -See the configuration file. | Please see the configuration file. +See the configuration file. | Please see the configuration file. View the Pods. | With this next command, we'll view the Pods. {{< /table >}} @@ -522,7 +522,7 @@ View the Pods. | With this next command, we'll view the Pods. Do | Don't :--| :----- You can create a Deployment by ... | We'll create a Deployment by ... -In the preceding output, you can see... | In the preceding output, we can see ... +In the preceding output, you can see... | In the preceding output, we can see ... {{< /table >}} @@ -583,7 +583,7 @@ considered new in a few months. Do | Don't :--| :----- In version 1.4, ... | In the current version, ... -The Federation feature provides ... | The new Federation feature provides ... +The Federation feature provides ... | The new Federation feature provides ... {{< /table >}}