Merge remote-tracking branch 'upstream/master'
This commit is contained in:
Joao Luna
@@ -16,7 +16,7 @@
|
||||
|
||||
If you're working on a different localization (not English), or you
|
||||
are documenting a feature that will be part of a future release, see
|
||||
https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use
|
||||
https://kubernetes.io/docs/contribute/new-content/overview/#choose-which-git-branch-to-use
|
||||
for advice.
|
||||
|
||||
-->
|
||||
|
||||
@@ -36,7 +36,10 @@ serve: ## Boot the development server.
|
||||
hugo server --buildFuture
|
||||
|
||||
docker-image:
|
||||
$(DOCKER) build . --tag $(DOCKER_IMAGE) --build-arg HUGO_VERSION=$(HUGO_VERSION)
|
||||
$(DOCKER) build . \
|
||||
--network=host \
|
||||
--tag $(DOCKER_IMAGE) \
|
||||
--build-arg HUGO_VERSION=$(HUGO_VERSION)
|
||||
|
||||
docker-build:
|
||||
$(DOCKER_RUN) $(DOCKER_IMAGE) hugo
|
||||
|
||||
+1
-4
@@ -41,7 +41,6 @@ aliases:
|
||||
sig-docs-en-owners: # Admins for English content
|
||||
- bradtopol
|
||||
- daminisatya
|
||||
- jaredbhatti
|
||||
- jimangel
|
||||
- kbarnard10
|
||||
- kbhawkey
|
||||
@@ -59,7 +58,6 @@ aliases:
|
||||
sig-docs-en-reviews: # PR reviews for English content
|
||||
- bradtopol
|
||||
- daminisatya
|
||||
- jaredbhatti
|
||||
- jimangel
|
||||
- kbarnard10
|
||||
- kbhawkey
|
||||
@@ -125,6 +123,7 @@ aliases:
|
||||
sig-docs-id-reviews: # PR reviews for Indonesian content
|
||||
- girikuncoro
|
||||
- irvifa
|
||||
- wahyuoi
|
||||
sig-docs-it-owners: # Admins for Italian content
|
||||
- fabriziopandini
|
||||
- mattiaperi
|
||||
@@ -171,7 +170,6 @@ aliases:
|
||||
- haibinxie
|
||||
- hanjiayao
|
||||
- lichuqiang
|
||||
- markthink
|
||||
- SataQiu
|
||||
- tengqm
|
||||
- xiangpengzhao
|
||||
@@ -181,7 +179,6 @@ aliases:
|
||||
sig-docs-zh-reviews: # PR reviews for Chinese content
|
||||
- chenrui333
|
||||
- idealhack
|
||||
- markthink
|
||||
- SataQiu
|
||||
- tanjunchen
|
||||
- tengqm
|
||||
|
||||
+1
-1
@@ -36,7 +36,7 @@
|
||||
|
||||
> यदि आप डॉकर के बिना स्थानीय रूप से वेबसाइट चलाना पसंद करते हैं, तो नीचे Hugo का उपयोग करके स्थानीय रूप से साइट चलाना देखें।
|
||||
|
||||
यदि आप डॉकर के बिना स्थानीय रूप से वेबसाइट चलाना पसंद करते हैं, तो नीचे दिए गए Hugo का उपयोग करके स्थानीय रूप से [साइट को चलाने](#running-the-site-locally-using-hugo) का तरीका देखें।
|
||||
यदि आप डॉकर के बिना स्थानीय रूप से वेबसाइट चलाना पसंद करते हैं, तो नीचे दिए गए Hugo का उपयोग करके स्थानीय रूप से [साइट को चलाने](#hugo-का-उपयोग-करते-हुए-स्थानीय-रूप-से-साइट-चलाना) का तरीका देखें।
|
||||
|
||||
यदि आप [डॉकर](https://www.docker.com/get-started) चला रहे हैं, तो स्थानीय रूप से `कुबेरनेट्स-ह्यूगो` Docker image बनाएँ:
|
||||
|
||||
|
||||
+31
-52
@@ -1,58 +1,9 @@
|
||||
# Документация по Kubernetes
|
||||
|
||||
[](https://travis-ci.org/kubernetes/website)
|
||||
[](https://github.com/kubernetes/website/releases/latest)
|
||||
[](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [](https://github.com/kubernetes/website/releases/latest)
|
||||
|
||||
Добро пожаловать! Данный репозиторий содержит все необходимые файлы для сборки [сайта Kubernetes и документации](https://kubernetes.io/). Мы благодарим вас за старания!
|
||||
|
||||
## Вклад в документацию
|
||||
|
||||
Нажмите на кнопку **Fork** в правом верхнем углу, чтобы создать копию этого репозитория в ваш GitHub-аккаунт. Эта копия называется *форк-репозиторием*. Делайте любые изменения в вашем форк-репозитории, и когда вы будете готовы опубликовать изменения, откройте форк-репозиторий и создайте новый пулреквест, чтобы уведомить нас.
|
||||
|
||||
После того, как вы отправите пулреквест, ревьювер Kubernetes даст по нему обратную связь. Вы, как автор пулреквеста, **должны обновить свой пулреквест после его рассмотрения ревьювером Kubernetes.** Вполне возможно, что более одного ревьювера Kubernetes оставят свои комментарии или даже может быть так, что новый комментарий ревьювера Kubernetes будет отличаться от первоначального назначенного ревьювера. Кроме того, в некоторых случаях один из ревьюверов может запросить технический обзор у [технического ревьювера Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers), если это будет необходимо. Ревьюверы сделают все возможное, чтобы как можно оперативно оставить свои предложения и пожелания, но время ответа может варьироваться в зависимости от обстоятельств.
|
||||
|
||||
Узнать подробнее о том, как поучаствовать в документации Kubernetes, вы можете по ссылкам ниже:
|
||||
|
||||
* [Начните вносить свой вклад](https://kubernetes.io/docs/contribute/start/)
|
||||
* [Просмотр локальных изменений](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
|
||||
* [Использование шаблонов страниц](http://kubernetes.io/docs/contribute/style/page-templates/)
|
||||
* [Руководство по оформлению документации](http://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Руководство по локализации Kubernetes](https://kubernetes.io/docs/contribute/localization/)
|
||||
|
||||
## Файл `README.md` на других языках
|
||||
| | |
|
||||
|-------------------------------|-------------------------------|
|
||||
| [Английский](README.md) | [Французский](README-fr.md) |
|
||||
| [Корейский](README-ko.md) | [Немецкий](README-de.md) |
|
||||
| [Португальский](README-pt.md) | [Хинди](README-hi.md) |
|
||||
| [Испанский](README-es.md) | [Индонезийский](README-id.md) |
|
||||
| [Китайский](README-zh.md) | [Японский](README-ja.md) |
|
||||
| [Вьетнамский](README-vi.md) | [Итальянский](README-it.md) |
|
||||
| [Польский]( README-pl.md) | [Украинский](README-uk.md) |
|
||||
| | |
|
||||
|
||||
## Запуск сайта локально с помощью Docker
|
||||
|
||||
Рекомендованный способ запуска сайта Kubernetes на локальной машине - использовать специальный образ [Docker](https://docker.com), который включает статический генератор сайтов [Hugo](https://gohugo.io).
|
||||
|
||||
> Если вы используете Windows, вам необходимо установить дополнительные инструменты через [Chocolatey](https://chocolatey.org). `choco install make`
|
||||
|
||||
> Если вы хотите запустить сайт локально без Docker, обратитесь к разделу [Запуск сайта с помощью Hugo](#запуск-сайта-с-помощью-hugo) ниже на этой странице.
|
||||
|
||||
Когда Docker [установлен и запущен](https://www.docker.com/get-started), соберите локально Docker-образ `kubernetes-hugo`, выполнив команду в консоли:
|
||||
|
||||
```bash
|
||||
make docker-image
|
||||
```
|
||||
|
||||
После того, как вы собрали образ, можно запустить сайт локально:
|
||||
|
||||
```bash
|
||||
make docker-serve
|
||||
```
|
||||
|
||||
Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайт. Если вы редактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере.
|
||||
|
||||
## Запуск сайта с помощью Hugo
|
||||
|
||||
Обратитесь к [официальной документации Hugo](https://gohugo.io/getting-started/installing/), чтобы установить Hugo. Убедитесь, что вы установили правильную версию Hugo, которая устанавливается в переменной окружения `HUGO_VERSION` в файле [`netlify.toml`](netlify.toml#L10).
|
||||
@@ -60,7 +11,9 @@ make docker-serve
|
||||
После установки Hugo, чтобы запустить сайт, выполните в консоли:
|
||||
|
||||
```bash
|
||||
make serve
|
||||
git clone https://github.com/kubernetes/website.git
|
||||
cd website
|
||||
hugo server --buildFuture
|
||||
```
|
||||
|
||||
Эта команда запустит сервер Hugo на порту 1313. Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайт. Если вы отредактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере.
|
||||
@@ -74,9 +27,35 @@ make serve
|
||||
- [Канал в Slack](https://kubernetes.slack.com/messages/sig-docs)
|
||||
- [Рассылка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
|
||||
|
||||
## Вклад в документацию
|
||||
|
||||
Нажмите на кнопку **Fork** в правом верхнем углу, чтобы создать копию этого репозитория в ваш GitHub-аккаунт. Эта копия называется *форк-репозиторием*. Делайте любые изменения в вашем форк-репозитории, и когда вы будете готовы опубликовать изменения, откройте форк-репозиторий и создайте новый пулреквест, чтобы уведомить нас.
|
||||
|
||||
После того, как вы отправите пулреквест, ревьювер Kubernetes даст по нему обратную связь. Вы, как автор пулреквеста, **должны обновить свой пулреквест после его рассмотрения ревьювером Kubernetes.**
|
||||
|
||||
Вполне возможно, что более одного ревьювера Kubernetes оставят свои комментарии или даже может быть так, что новый комментарий ревьювера Kubernetes будет отличаться от первоначального назначенного ревьювера. Кроме того, в некоторых случаях один из ревьюверов может запросить технический обзор у [технического ревьювера Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers), если это будет необходимо. Ревьюверы сделают все возможное, чтобы как можно оперативно оставить свои предложения и пожелания, но время ответа может варьироваться в зависимости от обстоятельств.
|
||||
|
||||
Узнать подробнее о том, как поучаствовать в документации Kubernetes, вы можете по ссылкам ниже:
|
||||
|
||||
* [Начните вносить свой вклад](https://kubernetes.io/docs/contribute/)
|
||||
* [Использование шаблонов страниц](http://kubernetes.io/docs/contribute/style/page-templates/)
|
||||
* [Руководство по оформлению документации](http://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Руководство по локализации Kubernetes](https://kubernetes.io/docs/contribute/localization/)
|
||||
|
||||
## Файл `README.md` на других языках
|
||||
| другие языки | другие языки |
|
||||
|-------------------------------|-------------------------------|
|
||||
| [Английский](README.md) | [Французский](README-fr.md) |
|
||||
| [Корейский](README-ko.md) | [Немецкий](README-de.md) |
|
||||
| [Португальский](README-pt.md) | [Хинди](README-hi.md) |
|
||||
| [Испанский](README-es.md) | [Индонезийский](README-id.md) |
|
||||
| [Китайский](README-zh.md) | [Японский](README-ja.md) |
|
||||
| [Вьетнамский](README-vi.md) | [Итальянский](README-it.md) |
|
||||
| [Польский]( README-pl.md) | [Украинский](README-uk.md) |
|
||||
|
||||
### Кодекс поведения
|
||||
|
||||
Участие в сообществе Kubernetes регулируется [кодексом поведения Kubernetes](code-of-conduct.md).
|
||||
Участие в сообществе Kubernetes регулируется [кодексом поведения CNCF](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
|
||||
|
||||
## Спасибо!
|
||||
|
||||
|
||||
+54
-53
@@ -1,27 +1,68 @@
|
||||
<!-- # The Kubernetes documentation -->
|
||||
# Документація Kubernetes
|
||||
|
||||
[](https://travis-ci.org/kubernetes/website)
|
||||
[](https://github.com/kubernetes/website/releases/latest)
|
||||
[](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [](https://github.com/kubernetes/website/releases/latest)
|
||||
|
||||
<!-- This repository contains the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/). We're glad that you want to contribute! -->
|
||||
Вітаємо! В цьому репозиторії міститься все необхідне для роботи над [сайтом і документацією Kubernetes](https://kubernetes.io/). Ми щасливі, що ви хочете зробити свій внесок!
|
||||
|
||||
<!-- ## Running the website locally using Hugo -->
|
||||
## Запуск сайту локально зa допомогою Hugo
|
||||
|
||||
<!-- See the [official Hugo documentation](https://gohugo.io/getting-started/installing/) for Hugo installation instructions. Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L10) file. -->
|
||||
Для інструкцій з встановлення Hugo дивіться [офіційну документацію](https://gohugo.io/getting-started/installing/). Обов’язково встановіть розширену версію Hugo, яка позначена змінною оточення `HUGO_VERSION` у файлі [`netlify.toml`](netlify.toml#L10).
|
||||
|
||||
<!-- To run the website locally when you have Hugo installed: -->
|
||||
Після встановлення Hugo, запустіть сайт локально командою:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/kubernetes/website.git
|
||||
cd website
|
||||
hugo server --buildFuture
|
||||
```
|
||||
|
||||
<!-- This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh. -->
|
||||
Команда запустить локальний Hugo-сервер на порту 1313. Відкрийте у своєму браузері http://localhost:1313, щоб побачити сайт. По мірі того, як ви змінюєте вихідний код, Hugo актуалізує сайт відповідно до внесених змін і оновлює сторінку у браузері.
|
||||
|
||||
<!-- ## Get involved with SIG Docs -->
|
||||
## Спільнота, обговорення, внесок і підтримка
|
||||
|
||||
<!-- Learn more about SIG Docs Kubernetes community and meetings on the [community page](https://github.com/kubernetes/community/tree/master/sig-docs#meetings). -->
|
||||
Дізнайтеся, як долучитися до спільноти Kubernetes на [сторінці спільноти](http://kubernetes.io/community/).
|
||||
|
||||
<!-- You can also reach the maintainers of this project at: -->
|
||||
Для зв’язку із супроводжуючими проекту скористайтеся:
|
||||
|
||||
- [Slack](https://kubernetes.slack.com/messages/sig-docs)
|
||||
- [Поштова розсилка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
|
||||
|
||||
<!-- ## Contributing to the docs -->
|
||||
## Внесок у документацію
|
||||
|
||||
<!-- You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a *fork*. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it. -->
|
||||
Ви можете створити копію цього репозиторія у своєму акаунті на GitHub, натиснувши на кнопку **Fork**, що розташована справа зверху. Ця копія називатиметься *fork* (відгалуження). Зробіть будь-які необхідні зміни у своєму відгалуженні. Коли ви будете готові надіслати їх нам, перейдіть до свого відгалуження і створіть новий pull request, щоб сповістити нас.
|
||||
|
||||
Після того, як ви створили pull request, рецензент Kubernetes зобов’язується надати вам по ньому чіткий і конструктивний коментар. **Ваш обов’язок як творця pull request - відкоригувати його відповідно до зауважень рецензента Kubernetes.** Також, зауважте: може статися так, що ви отримаєте коментарі від декількох рецензентів Kubernetes або від іншого рецензента, ніж той, якого вам було призначено від початку. Крім того, за потреби один із ваших рецензентів може запросити технічну перевірку від одного з [технічних рецензентів Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers). Рецензенти намагатимуться відреагувати вчасно, проте час відповіді може відрізнятися в залежності від обставин.
|
||||
<!-- Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback. As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.** -->
|
||||
Після того, як ви створили pull request, рецензент Kubernetes зобов’язується надати вам по ньому чіткий і конструктивний коментар. **Ваш обов’язок як творця pull request - відкоригувати його відповідно до зауважень рецензента Kubernetes.**
|
||||
|
||||
<!-- Also, note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one initially assigned to provide you feedback. -->
|
||||
Також, зауважте: може статися так, що ви отримаєте коментарі від декількох рецензентів Kubernetes або від іншого рецензента, ніж той, якого вам було призначено від початку.
|
||||
|
||||
<!-- Furthermore, in some cases, one of your reviewers might ask for a technical review from a Kubernetes tech reviewer when needed. Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances. -->
|
||||
Крім того, за потреби один із ваших рецензентів може запросити технічну перевірку від одного з технічних рецензентів Kubernetes, коли це необхідно. Рецензенти намагатимуться відреагувати вчасно, проте час відповіді може відрізнятися в залежності від обставин.
|
||||
|
||||
<!-- For more information about contributing to the Kubernetes documentation, see: -->
|
||||
Більше інформації про внесок у документацію Kubernetes ви знайдете у наступних джерелах:
|
||||
|
||||
* [Внесок: з чого почати](https://kubernetes.io/docs/contribute/start/)
|
||||
* [Візуалізація запропонованих змін до документації](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
|
||||
* [Внесок: з чого почати](https://kubernetes.io/docs/contribute/)
|
||||
* [Використання шаблонів сторінок](http://kubernetes.io/docs/contribute/style/page-templates/)
|
||||
* [Керівництво зі стилю оформлення документації](http://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Переклад документації Kubernetes іншими мовами](https://kubernetes.io/docs/contribute/localization/)
|
||||
|
||||
<!-- ## Localization `README.md`'s -->
|
||||
## Файл `README.md` іншими мовами
|
||||
|
||||
| | |
|
||||
| інші мови | інші мови |
|
||||
|-------------------------------|-------------------------------|
|
||||
| [Англійська](README.md) | [Французька](README-fr.md) |
|
||||
| [Корейська](README-ko.md) | [Німецька](README-de.md) |
|
||||
@@ -30,55 +71,15 @@
|
||||
| [Китайська](README-zh.md) | [Японська](README-ja.md) |
|
||||
| [В'єтнамська](README-vi.md) | [Російська](README-ru.md) |
|
||||
| [Італійська](README-it.md) | [Польська](README-pl.md) |
|
||||
| | |
|
||||
|
||||
## Запуск сайту локально за допомогою Docker
|
||||
<!-- ## Code of conduct -->
|
||||
## Кодекс поведінки
|
||||
|
||||
Для локального запуску сайту Kubernetes рекомендовано запустити спеціальний [Docker](https://docker.com)-образ, що містить генератор статичних сайтів [Hugo](https://gohugo.io).
|
||||
|
||||
> Якщо ви працюєте під Windows, вам знадобиться ще декілька інструментів, які можна встановити за допомогою [Chocolatey](https://chocolatey.org). `choco install make`
|
||||
|
||||
> Якщо ви вважаєте кращим запустити сайт локально без використання Docker, дивіться пункт нижче [Запуск сайту локально за допомогою Hugo](#запуск-сайту-локально-зa-допомогою-hugo).
|
||||
|
||||
Якщо у вас вже [запущений](https://www.docker.com/get-started) Docker, зберіть локальний Docker-образ `kubernetes-hugo`:
|
||||
|
||||
```bash
|
||||
make docker-image
|
||||
```
|
||||
|
||||
Після того, як образ зібрано, ви можете запустити сайт локально:
|
||||
|
||||
```bash
|
||||
make docker-serve
|
||||
```
|
||||
|
||||
Відкрийте у своєму браузері http://localhost:1313, щоб побачити сайт. По мірі того, як ви змінюєте вихідний код, Hugo актуалізує сайт відповідно до внесених змін і оновлює сторінку у браузері.
|
||||
|
||||
## Запуск сайту локально зa допомогою Hugo
|
||||
|
||||
Для інструкцій по установці Hugo дивіться [офіційну документацію](https://gohugo.io/getting-started/installing/). Обов’язково встановіть розширену версію Hugo, яка позначена змінною оточення `HUGO_VERSION` у файлі [`netlify.toml`](netlify.toml#L9).
|
||||
|
||||
Після установки Hugo, запустіть сайт локально командою:
|
||||
|
||||
```bash
|
||||
make serve
|
||||
```
|
||||
|
||||
Команда запустить локальний Hugo-сервер на порту 1313. Відкрийте у своєму браузері http://localhost:1313, щоб побачити сайт. По мірі того, як ви змінюєте вихідний код, Hugo актуалізує сайт відповідно до внесених змін і оновлює сторінку у браузері.
|
||||
|
||||
## Спільнота, обговорення, внесок і підтримка
|
||||
|
||||
Дізнайтеся, як долучитися до спільноти Kubernetes на [сторінці спільноти](http://kubernetes.io/community/).
|
||||
|
||||
Для зв’язку із супроводжуючими проекту скористайтеся:
|
||||
|
||||
- [Slack](https://kubernetes.slack.com/messages/sig-docs)
|
||||
- [Поштова розсилка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
|
||||
|
||||
### Кодекс поведінки
|
||||
|
||||
Участь у спільноті Kubernetes визначається правилами [Кодексу поведінки спільноти Kubernetes](code-of-conduct.md).
|
||||
<!-- Participation in the Kubernetes community is governed by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). -->
|
||||
Участь у спільноті Kubernetes визначається правилами [Кодексу поведінки СNCF](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
|
||||
|
||||
<!-- ## Thank you! -->
|
||||
## Дякуємо!
|
||||
|
||||
Долучення до спільноти - запорука успішного розвитку Kubernetes. Ми цінуємо ваш внесок у наш сайт і документацію!
|
||||
<!-- Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation! -->
|
||||
Долучення до спільноти - запорука успішного розвитку Kubernetes. Ми цінуємо ваш внесок у наш сайт і документацію!
|
||||
@@ -48,13 +48,13 @@ For more information about contributing to the Kubernetes documentation, see:
|
||||
|
||||
| Language | Language |
|
||||
|---|---|
|
||||
|[French](README-fr.md)|[Korean](README-ko.md)|
|
||||
|[Chinese](README-zh.md)|[Korean](README-ko.md)|
|
||||
|[French](README-fr.md)|[Polish](README-pl.md)|
|
||||
|[German](README-de.md)|[Portuguese](README-pt.md)|
|
||||
|[Hindi](README-hi.md)|[Spanish](README-es.md)|
|
||||
|[Indonesian](README-id.md)|[Chinese](README-zh.md)|
|
||||
|[Hindi](README-hi.md)|[Russian](README-ru.md)|
|
||||
|[Indonesian](README-id.md)|[Spanish](README-es.md)|
|
||||
|[Italian](README-it.md)|[Ukrainian](README-uk.md)|
|
||||
|[Japanese](README-ja.md)|[Vietnamese](README-vi.md)|
|
||||
|[Russian](README-ru.md)|[Italian](README-it.md)|
|
||||
|[Polish](README-pl.md)|[Ukrainian](README-uk.md)|
|
||||
|
||||
## Code of conduct
|
||||
|
||||
|
||||
@@ -439,6 +439,7 @@ footer
|
||||
width: 100%
|
||||
background-image: url(/images/texture.png)
|
||||
background-color: $dark-grey
|
||||
overflow-x: hidden
|
||||
|
||||
.main-section
|
||||
padding: 20px 0
|
||||
@@ -1214,7 +1215,7 @@ $feature-box-div-margin-bottom: 40px
|
||||
margin-bottom: 20px
|
||||
|
||||
#desktopKCButton
|
||||
position: relative
|
||||
position: absolute
|
||||
font-size: 18px
|
||||
background-color: $dark-grey
|
||||
border-radius: 8px
|
||||
@@ -1802,6 +1803,7 @@ $feature-box-div-margin-bottom: 40px
|
||||
|
||||
img
|
||||
padding-bottom: 1rem
|
||||
max-width: 100%
|
||||
|
||||
div
|
||||
position: relative
|
||||
|
||||
+17
-14
@@ -14,24 +14,27 @@ contentDir = "content/en"
|
||||
|
||||
timeout = 3000
|
||||
|
||||
# Highlighting config.
|
||||
pygmentsCodeFences = true
|
||||
pygmentsUseClasses = false
|
||||
# See https://help.farbox.com/pygments.html
|
||||
pygmentsStyle = "emacs"
|
||||
|
||||
# Enable Git variables like commit, lastmod
|
||||
enableGitInfo = true
|
||||
|
||||
# Norwegian ("no") is sometimes but not currently used for testing.
|
||||
# Hindi is disabled because it's currently in development.
|
||||
# Italian is disabled until it meets minimum standards for quality.
|
||||
disableLanguages = ["hi", "it", "no"]
|
||||
disableLanguages = ["hi", "no"]
|
||||
|
||||
[blackfriday]
|
||||
hrefTargetBlank = true
|
||||
fractions = false
|
||||
smartDashes = false
|
||||
[markup]
|
||||
[markup.goldmark]
|
||||
[markup.goldmark.renderer]
|
||||
unsafe = true
|
||||
[markup.highlight]
|
||||
codeFences = true
|
||||
guessSyntax = false
|
||||
hl_Lines = ""
|
||||
lineNoStart = 1
|
||||
lineNos = false
|
||||
lineNumbersInTable = true
|
||||
noClasses = true
|
||||
style = "emacs"
|
||||
tabWidth = 4
|
||||
|
||||
[frontmatter]
|
||||
date = ["date", ":filename", "publishDate", "lastmod"]
|
||||
@@ -188,8 +191,8 @@ language_alternatives = ["en"]
|
||||
|
||||
[languages.it]
|
||||
title = "Kubernetes"
|
||||
description = "Production-Grade Container Orchestration"
|
||||
languageName ="Italian"
|
||||
description = "Orchestrazione di Container in produzione"
|
||||
languageName = "Italiano"
|
||||
weight = 6
|
||||
contentDir = "content/it"
|
||||
|
||||
|
||||
@@ -14,23 +14,23 @@ Es gruppiert Container, aus denen sich eine Anwendung zusammensetzt, in logische
|
||||
{{% /blocks/feature %}}
|
||||
|
||||
{{% blocks/feature image="scalable" %}}
|
||||
#### Planet Scale
|
||||
#### Ausgereift
|
||||
|
||||
Kubernetes basiert auf denselben Prinzipien, die es Google ermöglichen, Milliarden von Containern pro Woche zu betreiben.
|
||||
|
||||
{{% /blocks/feature %}}
|
||||
|
||||
{{% blocks/feature image="blocks" %}}
|
||||
#### Never Outgrow
|
||||
#### Mitwachsend
|
||||
|
||||
Unabhängig davon, ob Sie lokal testen oder ein globales Unternehmen betreiben, die Flexibilität von Kubernetes wächst mit Ihnen, um Ihre Anwendungen konsistent und einfach bereitzustellen, unabhängig von der Komplexität Ihrer Anforderungen.
|
||||
Unabhängig davon, ob Du lokal testest oder ein globales Unternehmen betreibst: Die Flexibilität von Kubernetes wächst mit Dir, um Deine Anwendungen konsistent und einfach bereitzustellen - Unabhängig von der Komplexität Deiner Anforderungen.
|
||||
|
||||
{{% /blocks/feature %}}
|
||||
|
||||
{{% blocks/feature image="suitcase" %}}
|
||||
#### Run Anywhere
|
||||
#### Überall Lauffähig
|
||||
|
||||
Kubernetes ist Open Source und bietet Ihnen die Freiheit, die Infrastruktur vor Ort, Hybrid oder Public Cloud zu nutzen. So können Sie Workloads mühelos dorthin verschieben, wo es Ihnen wichtig ist.
|
||||
Kubernetes ist Open Source und bietet Dir die Freiheit, die Infrastruktur vor Ort, Hybrid oder Public Cloud zu nutzen. So kannst Du Workloads mühelos dorthin verschieben, wo es Dir wichtig ist.
|
||||
|
||||
{{% /blocks/feature %}}
|
||||
|
||||
@@ -39,17 +39,17 @@ Kubernetes ist Open Source und bietet Ihnen die Freiheit, die Infrastruktur vor
|
||||
{{< blocks/section id="video" background-image="kub_video_banner_homepage" >}}
|
||||
<div class="light-text">
|
||||
<h2>Die Herausforderungen bei der Migration von über 150 Microservices auf Kubernetes</h2>
|
||||
<p>Von Sarah Wells, technischer Direktor für Betrieb und Zuverlässigkeit, Financial Times</p>
|
||||
<p>Von Sarah Wells, technische Direktorin für Betrieb und Zuverlässigkeit, Financial Times</p>
|
||||
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Video ansehen</button>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Besuchen Sie die KubeCon vom 30 März-2 Apr. 2020 in Amsterdam</a>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Besuche die KubeCon - 13-16 August 2020 in Amsterdam</a>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<a href="https://www.lfasiallc.cn/kubecon-cloudnativecon-open-source-summit-china/" button id="desktopKCButton">Besuchen Sie die KubeCon vom 28-30 Juli 2020 in Shanghai</a>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Besuche die KubeCon - 17-20 November 2020 in Boston</a>
|
||||
</div>
|
||||
<div id="videoPlayer">
|
||||
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
|
||||
|
||||
@@ -45,7 +45,7 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Attend KubeCon in Amsterdam on August 13-16, 2020</a>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Attend KubeCon EU virtually on August 17-20, 2020</a>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
@@ -8,3 +8,9 @@ menu:
|
||||
post: >
|
||||
<p>Read the latest news for Kubernetes and the containers space in general, and get technical how-tos hot off the presses.</p>
|
||||
---
|
||||
{{< comment >}}
|
||||
|
||||
For information about contributing to the blog, see
|
||||
https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/#write-a-blog-post
|
||||
|
||||
{{< /comment >}}
|
||||
|
||||
@@ -144,7 +144,7 @@ The local persistent volume beta feature is not complete by far. Some notable en
|
||||
|
||||
[Pod disruption budget](/docs/concepts/workloads/pods/disruptions/) is also very important for those workloads that must maintain quorum. Setting a disruption budget for your workload ensures that it does not drop below quorum due to voluntary disruption events, such as node drains during upgrade.
|
||||
|
||||
[Pod affinity and anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) ensures that your workloads stay either co-located or spread out across failure domains. If you have multiple local persistent volumes available on a single node, it may be preferable to specify an pod anti-affinity policy to spread your workload across nodes. Note that if you want multiple pods to share the same local persistent volume, you do not need to specify a pod affinity policy. The scheduler understands the locality constraints of the local persistent volume and schedules your pod to the correct node.
|
||||
[Pod affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) ensures that your workloads stay either co-located or spread out across failure domains. If you have multiple local persistent volumes available on a single node, it may be preferable to specify an pod anti-affinity policy to spread your workload across nodes. Note that if you want multiple pods to share the same local persistent volume, you do not need to specify a pod affinity policy. The scheduler understands the locality constraints of the local persistent volume and schedules your pod to the correct node.
|
||||
|
||||
## Getting involved
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ Why is RuntimeClass a pod level concept? The Kubernetes resource model expects c
|
||||
|
||||
## What's next?
|
||||
|
||||
The RuntimeClass resource is an important foundation for surfacing runtime properties to the control plane. For example, to implement scheduler support for clusters with heterogeneous nodes supporting different runtimes, we might add [NodeAffinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) terms to the RuntimeClass definition. Another area to address is managing the variable resource requirements to run pods of different runtimes. The [Pod Overhead proposal](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview) was an early take on this that aligns nicely with the RuntimeClass design, and may be pursued further.
|
||||
The RuntimeClass resource is an important foundation for surfacing runtime properties to the control plane. For example, to implement scheduler support for clusters with heterogeneous nodes supporting different runtimes, we might add [NodeAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) terms to the RuntimeClass definition. Another area to address is managing the variable resource requirements to run pods of different runtimes. The [Pod Overhead proposal](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview) was an early take on this that aligns nicely with the RuntimeClass design, and may be pursued further.
|
||||
|
||||
Many other RuntimeClass extensions have also been proposed, and will be revisited as the feature continues to develop and mature. A few more extensions that are being considered include:
|
||||
|
||||
|
||||
@@ -97,7 +97,16 @@ reviews-v2-ccffdd984-9jnsj 2/2 Running 0 101s
|
||||
reviews-v3-98dc67b68-nzw97 2/2 Running 0 101s
|
||||
```
|
||||
|
||||
This command outputs useful data, so let’s take a second to understand it. If you examine the READY column, each pod has two containers running: the service and an Envoy sidecar injected alongside it. Another thing to highlight is that there are three review pods but only 1 review service. The Envoy sidecar will load balance the traffic to three different review pods that contain different versions, giving us the ability to A/B test our changes. With that said, you should now be able to access your product page!
|
||||
This command outputs useful data, so let’s take a second to understand it. If you examine the READY column, each pod has two containers running: the service and an Envoy sidecar injected alongside it. Another thing to highlight is that there are three review pods but only 1 review service. The Envoy sidecar will load balance the traffic to three different review pods that contain different versions, giving us the ability to A/B test our changes. We have one step before we can access the deployed application. We need to add an additional annotation to the `productpage` service. To do so, run:
|
||||
|
||||
```
|
||||
$ kubectl annotate service productpage ingress.kubernetes.io/service-upstream=true
|
||||
service/productpage annotated
|
||||
```
|
||||
|
||||
Both the API gateway (Kong) and the service mesh (Istio) can handle the load-balancing. Without the additional `ingress.kubernetes.io/service-upstream: "true"` annotation, Kong will try to load-balance by selecting its own endpoint/target from the productpage service. This causes Envoy to receive that pod’s IP as the upstream local address, instead of the service’s cluster IP. But we want the service's cluster IP so that Envoy can properly load balance.
|
||||
|
||||
With that added, you should now be able to access your product page!
|
||||
|
||||
```
|
||||
$ kubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') -c ratings -- curl productpage:9080/productpage | grep -o "<title>.*</title>"
|
||||
@@ -150,6 +159,8 @@ metadata:
|
||||
name: do-not-preserve-host
|
||||
route:
|
||||
preserve_host: false
|
||||
upstream:
|
||||
host_header: productpage.default.svc
|
||||
" | kubectl apply -f -
|
||||
kongingress.configuration.konghq.com/do-not-preserve-host created
|
||||
```
|
||||
|
||||
@@ -0,0 +1,192 @@
|
||||
---
|
||||
title: "Introducing PodTopologySpread"
|
||||
date: 2020-05-05
|
||||
slug: introducing-podtopologyspread
|
||||
url: /blog/2020/05/Introducing-PodTopologySpread
|
||||
---
|
||||
|
||||
**Author:** Wei Huang (IBM), Aldo Culquicondor (Google)
|
||||
|
||||
Managing Pods distribution across a cluster is hard. The well-known Kubernetes
|
||||
features for Pod affinity and anti-affinity, allow some control of Pod placement
|
||||
in different topologies. However, these features only resolve part of Pods
|
||||
distribution use cases: either place unlimited Pods to a single topology, or
|
||||
disallow two Pods to co-locate in the same topology. In between these two
|
||||
extreme cases, there is a common need to distribute the Pods evenly across the
|
||||
topologies, so as to achieve better cluster utilization and high availability of
|
||||
applications.
|
||||
|
||||
The PodTopologySpread scheduling plugin (originally proposed as EvenPodsSpread)
|
||||
was designed to fill that gap. We promoted it to beta in 1.18.
|
||||
|
||||
## API changes
|
||||
|
||||
A new field `topologySpreadConstraints` is introduced in the Pod's spec API:
|
||||
|
||||
```
|
||||
spec:
|
||||
topologySpreadConstraints:
|
||||
- maxSkew: <integer>
|
||||
topologyKey: <string>
|
||||
whenUnsatisfiable: <string>
|
||||
labelSelector: <object>
|
||||
```
|
||||
|
||||
As this API is embedded in Pod's spec, you can use this feature in all the
|
||||
high-level workload APIs, such as Deployment, DaemonSet, StatefulSet, etc.
|
||||
|
||||
Let's see an example of a cluster to understand this API.
|
||||
|
||||
|
||||
|
||||
- **labelSelector** is used to find matching Pods. For each topology, we count
|
||||
the number of Pods that match this label selector. In the above example, given
|
||||
the labelSelector as "app: foo", the matching number in "zone1" is 2; while
|
||||
the number in "zone2" is 0.
|
||||
- **topologyKey** is the key that defines a topology in the Nodes' labels. In
|
||||
the above example, some Nodes are grouped into "zone1" if they have the label
|
||||
"zone=zone1" label; while other ones are grouped into "zone2".
|
||||
- **maxSkew** describes the maximum degree to which Pods can be unevenly
|
||||
distributed. In the above example:
|
||||
- if we put the incoming Pod to "zone1", the skew on "zone1" will become 3 (3
|
||||
Pods matched in "zone1"; global minimum of 0 Pods matched on "zone2"), which
|
||||
violates the "maxSkew: 1" constraint.
|
||||
- if the incoming Pod is placed to "zone2", the skew on "zone2" is 0 (1 Pod
|
||||
matched in "zone2"; global minimum of 1 Pod matched on "zone2" itself),
|
||||
which satisfies the "maxSkew: 1" constraint. Note that the skew is
|
||||
calculated per each qualified Node, instead of a global skew.
|
||||
- **whenUnsatisfiable** specifies, when "maxSkew" can't be satisfied, what
|
||||
action should be taken:
|
||||
- `DoNotSchedule` (default) tells the scheduler not to schedule it. It's a
|
||||
hard constraint.
|
||||
- `ScheduleAnyway` tells the scheduler to still schedule it while prioritizing
|
||||
Nodes that reduce the skew. It's a soft constraint.
|
||||
|
||||
## Advanced usage
|
||||
|
||||
As the feature name "PodTopologySpread" implies, the basic usage of this feature
|
||||
is to run your workload with an absolute even manner (maxSkew=1), or relatively
|
||||
even manner (maxSkew>=2). See the [official
|
||||
document](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
|
||||
for more details.
|
||||
|
||||
In addition to this basic usage, there are some advanced usage examples that
|
||||
enable your workloads to benefit on high availability and cluster utilization.
|
||||
|
||||
### Usage along with NodeSelector / NodeAffinity
|
||||
|
||||
You may have found that we didn't have a "topologyValues" field to limit which
|
||||
topologies the Pods are going to be scheduled to. By default, it is going to
|
||||
search all Nodes and group them by "topologyKey". Sometimes this may not be the
|
||||
ideal case. For instance, suppose there is a cluster with Nodes tagged with
|
||||
"env=prod", "env=staging" and "env=qa", and now you want to evenly place Pods to
|
||||
the "qa" environment across zones, is it possible?
|
||||
|
||||
The answer is yes. You can leverage the NodeSelector or NodeAffinity API spec.
|
||||
Under the hood, the PodTopologySpread feature will **honor** that and calculate
|
||||
the spread constraints among the nodes that satisfy the selectors.
|
||||
|
||||
|
||||
|
||||
As illustrated above, you can specify `spec.affinity.nodeAffinity` to limit the
|
||||
"searching scope" to be "qa" environment, and within that scope, the Pod will be
|
||||
scheduled to one zone which satisfies the topologySpreadConstraints. In this
|
||||
case, it's "zone2".
|
||||
|
||||
### Multiple TopologySpreadConstraints
|
||||
|
||||
It's intuitive to understand how one single TopologySpreadConstraint works.
|
||||
What's the case for multiple TopologySpreadConstraints? Internally, each
|
||||
TopologySpreadConstraint is calculated independently, and the result sets will
|
||||
be merged to generate the eventual result set - i.e., suitable Nodes.
|
||||
|
||||
In the following example, we want to schedule a Pod to a cluster with 2
|
||||
requirements at the same time:
|
||||
|
||||
- place the Pod evenly with Pods across zones
|
||||
- place the Pod evenly with Pods across nodes
|
||||
|
||||
|
||||
|
||||
For the first constraint, there are 3 Pods in zone1 and 2 Pods in zone2, so the
|
||||
incoming Pod can be only put to zone2 to satisfy the "maxSkew=1" constraint. In
|
||||
other words, the result set is nodeX and nodeY.
|
||||
|
||||
For the second constraint, there are too many Pods in nodeB and nodeX, so the
|
||||
incoming Pod can be only put to nodeA and nodeY.
|
||||
|
||||
Now we can conclude the only qualified Node is nodeY - from the intersection of
|
||||
the sets {nodeX, nodeY} (from the first constraint) and {nodeA, nodeY} (from the
|
||||
second constraint).
|
||||
|
||||
Multiple TopologySpreadConstraints is powerful, but be sure to understand the
|
||||
difference with the preceding "NodeSelector/NodeAffinity" example: one is to
|
||||
calculate result set independently and then interjoined; while the other is to
|
||||
calculate topologySpreadConstraints based on the filtering results of node
|
||||
constraints.
|
||||
|
||||
Instead of using "hard" constraints in all topologySpreadConstraints, you can
|
||||
also combine using "hard" constraints and "soft" constraints to adhere to more
|
||||
diverse cluster situations.
|
||||
|
||||
{{< note >}}
|
||||
If two TopologySpreadConstraints are being applied for the same {topologyKey,
|
||||
whenUnsatisfiable} tuple, the Pod creation will be blocked returning a
|
||||
validation error.
|
||||
{{< /note >}}
|
||||
|
||||
## PodTopologySpread defaults
|
||||
|
||||
PodTopologySpread is a Pod level API. As such, to use the feature, workload
|
||||
authors need to be aware of the underlying topology of the cluster, and then
|
||||
specify proper `topologySpreadConstraints` in the Pod spec for every workload.
|
||||
While the Pod-level API gives the most flexibility it is also possible to
|
||||
specify cluster-level defaults.
|
||||
|
||||
The default PodTopologySpread constraints allow you to specify spreading for all
|
||||
the workloads in the cluster, tailored for its topology. The constraints can be
|
||||
specified by an operator/admin as PodTopologySpread plugin arguments in the
|
||||
[scheduling profile configuration
|
||||
API](/docs/reference/scheduling/profiles/) when starting
|
||||
kube-scheduler.
|
||||
|
||||
A sample configuration could look like this:
|
||||
|
||||
```
|
||||
apiVersion: kubescheduler.config.k8s.io/v1alpha2
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
pluginConfig:
|
||||
- name: PodTopologySpread
|
||||
args:
|
||||
defaultConstraints:
|
||||
- maxSkew: 1
|
||||
topologyKey: example.com/rack
|
||||
whenUnsatisfiable: ScheduleAnyway
|
||||
```
|
||||
|
||||
When configuring default constraints, label selectors must be left empty.
|
||||
kube-scheduler will deduce the label selectors from the membership of the Pod to
|
||||
Services, ReplicationControllers, ReplicaSets or StatefulSets. Pods can
|
||||
always override the default constraints by providing their own through the
|
||||
PodSpec.
|
||||
|
||||
{{< note >}}
|
||||
When using default PodTopologySpread constraints, it is recommended to disable
|
||||
the old DefaultTopologySpread plugin.
|
||||
{{< /note >}}
|
||||
|
||||
## Wrap-up
|
||||
|
||||
PodTopologySpread allows you to define spreading constraints for your workloads
|
||||
with a flexible and expressive Pod-level API. In the past, workload authors used
|
||||
Pod AntiAffinity rules to force or hint the scheduler to run a single Pod per
|
||||
topology domain. In contrast, the new PodTopologySpread constraints allow Pods
|
||||
to specify skew levels that can be required (hard) or desired (soft). The
|
||||
feature can be paired with Node selectors and Node affinity to limit the
|
||||
spreading to specific domains. Pod spreading constraints can be defined for
|
||||
different topologies such as hostnames, zones, regions, racks, etc.
|
||||
|
||||
Lastly, cluster operators can define default constraints to be applied to all
|
||||
Pods. This way, Pods don't need to be aware of the underlying topology of the
|
||||
cluster.
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: "How Docs Handle Third Party and Dual Sourced Content"
|
||||
date: 2020-05-06
|
||||
slug: third-party-dual-sourced
|
||||
url: /blog/2020/05/third-party-dual-sourced-content
|
||||
---
|
||||
|
||||
**Author:** Zach Corleissen, Cloud Native Computing Foundation
|
||||
|
||||
*Editor's note: Zach is one of the chairs for the Kubernetes documentation special interest group (SIG Docs).*
|
||||
|
||||
Late last summer, SIG Docs started a community conversation about third party content in Kubernetes docs. This conversation became a [Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements/pull/1327) (KEP) and, after five months for review and comment, SIG Architecture approved the KEP as a [content guide](/docs/contribute/style/content-guide/) for Kubernetes docs.
|
||||
|
||||
Here's how Kubernetes docs handle third party content now:
|
||||
|
||||
> Links to active content in the Kubernetes project (projects in the kubernetes and kubernetes-sigs GitHub orgs) are always allowed.
|
||||
>
|
||||
> Kubernetes requires some third party content to function. Examples include container runtimes (containerd, CRI-O, Docker), networking policy (CNI plugins), Ingress controllers, and logging.
|
||||
>
|
||||
> Docs can link to third party open source software (OSS) outside the Kubernetes project if it’s necessary for Kubernetes to function.
|
||||
|
||||
These common sense guidelines make sure that Kubernetes docs document Kubernetes.
|
||||
|
||||
## Keeping the docs focused
|
||||
|
||||
Our goal is for Kubernetes docs to be a trustworthy guide to Kubernetes features. To achieve this goal, SIG Docs is [tracking third party content](https://github.com/kubernetes/website/issues/20232) and removing any third party content that isn't both in the Kubernetes project _and_ required for Kubernetes to function.
|
||||
|
||||
### Re-homing content
|
||||
|
||||
Some content will be removed that readers may find helpful. To make sure readers have continous access to information, we're giving stakeholders until the [1.19 release deadline for docs](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.19), **July 9th, 2020** to re-home any content slated for removal.
|
||||
|
||||
Over the next few months you'll see less third party content in the docs as contributors open PRs to remove content.
|
||||
|
||||
## Background
|
||||
|
||||
Over time, SIG Docs observed increasing vendor content in the docs. Some content took the form of vendor-specific implementations that aren't required for Kubernetes to function in-project. Other content was thinly-disguised advertising with minimal to no feature content. Some vendor content was new; other content had been in the docs for years. It became clear that the docs needed clear, well-bounded guidelines for what kind of third party content is and isn't allowed. The [content guide](https://kubernetes.io/docs/contribute/content-guide/) emerged from an extensive period for review and comment from the community.
|
||||
|
||||
Docs work best when they're accurate, helpful, trustworthy, and remain focused on features. In our experience, vendor content dilutes trust and accuracy.
|
||||
|
||||
Put simply: feature docs aren't a place for vendors to advertise their products. Our content policy keeps the docs focused on helping developers and cluster admins, not on marketing.
|
||||
|
||||
## Dual sourced content
|
||||
|
||||
Less impactful but also important is how Kubernetes docs handle _dual-sourced content_. Dual-sourced content is content published in more than one location, or from a non-canonical source.
|
||||
|
||||
From the [Kubernetes content guide](https://kubernetes.io/docs/contribute/style/content-guide/#dual-sourced-content):
|
||||
|
||||
> Wherever possible, Kubernetes docs link to canonical sources instead of hosting dual-sourced content.
|
||||
|
||||
Minimizing dual-sourced content streamlines the docs and makes content across the Web more searchable. We're working to consolidate and redirect dual-sourced content in the Kubernetes docs as well.
|
||||
|
||||
## Ways to contribute
|
||||
|
||||
We're tracking third-party content in an [issue in the Kubernetes website repository](https://github.com/kubernetes/website/issues/20232). If you see third party content that's out of project and isn't required for Kubernetes to function, please comment on the tracking issue.
|
||||
|
||||
Feel free to open a PR that removes non-conforming content once you've identified it!
|
||||
|
||||
## Want to know more?
|
||||
|
||||
For more information, read the issue description for [tracking third party content](https://github.com/kubernetes/website/issues/20232).
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 8.5 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 224 KiB |
@@ -0,0 +1,109 @@
|
||||
---
|
||||
title: Babylon Case Study
|
||||
linkTitle: Babylon
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/case-studies-gradient.css
|
||||
logo: babylon_featured_logo.svg
|
||||
featured: true
|
||||
weight: 1
|
||||
quote: >
|
||||
Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need.
|
||||
---
|
||||
|
||||
|
||||
<div class="article image overlay" style="background-image: url('/images/babylon4.jpg')">
|
||||
<h1> CASE STUDY: Babylon</h1>
|
||||
<div class="subhead">How Cloud Native Is Enabling Babylon’s Medical AI Innovations</div>
|
||||
</div>
|
||||
|
||||
<div class="details">
|
||||
Company <b>Babylon</b> Location <b>United Kingdom</b> Industry <b>AI, Healthcare</b>
|
||||
</div>
|
||||
|
||||
<hr>
|
||||
<section class="section1">
|
||||
<div class="colsgradient">
|
||||
<div class="col1">
|
||||
<h2>Challenge</h2>
|
||||
A large number of Babylon’s products leverage machine learning and artificial intelligence, and in 2019, there wasn’t enough computing power in-house to run a particular experiment. The company was also growing (from 100 to 1,600 in three years) and planning expansion into other countries.
|
||||
|
||||
|
||||
<h2>Solution</h2>
|
||||
Babylon had migrated its user-facing applications to a Kubernetes platform in 2018, so the infrastructure team turned to Kubeflow, a toolkit for machine learning on Kubernetes. “We tried to create a Kubernetes core server, we deployed Kubeflow, and we orchestrated the whole experiment, which ended up being a really good success,” says AI Infrastructure Lead Jérémie Vallée. The team began building a self-service AI training platform on top of Kubernetes.
|
||||
|
||||
<h2>Impact</h2>
|
||||
Instead of waiting hours or days to be able to compute, teams can get access instantaneously. Clinical validations used to take 10 hours; now they are done in under 20 minutes. The portability of the cloud native platform has also enabled Babylon to expand into other countries.</div>
|
||||
</div>
|
||||
</section>
|
||||
<div class="article image overlay" style="background-image: url('/images/babylon1.jpg');">
|
||||
<div class="quotetext">
|
||||
“Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need.”
|
||||
<p><div class="quoteauthortext">- JÉRÉMIE VALLÉE, AI INFRASTRUCTURE LEAD AT BABYLON</div></p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
<section class="section2">
|
||||
<div class="fullcol">
|
||||
<h4>Babylon’s mission is to put accessible and affordable healthcare services in the hands of every person on earth.</h4>
|
||||
|
||||
<p>Since its launch in the U.K. in 2013, the startup has facilitated millions of digital consultations around the world. In the U.K., patients were typically waiting a week or two for a doctor’s appointment. Through Babylon’s NHS service, GP at Hand—which has more than 75,000 registered patients—39% get an appointment through their phone within 30 minutes, and 89% within 6 hours. </p>
|
||||
|
||||
<p>That’s just the start. “We try to combine different types of technology with the medical expertise that we have in-house to build products that will help patients manage and understand their health, and also help doctors be more efficient at what they do,” says Jérémie Vallée, AI Infrastructure Lead at Babylon. </p>
|
||||
|
||||
<p>A large number of these products leverage machine learning and artificial intelligence, and in 2019, researchers hit a pain point. “We have some servers in-house where our researchers were doing a lot of AI experiments and some training of models, and we came to a point where we didn’t have enough compute in-house to run a particular experiment,” says Vallée. </p>
|
||||
<p>
|
||||
Babylon had migrated its user-facing applications to a Kubernetes platform in 2018, “and we had a lot of Kubernetes knowledge thanks to the migration,” he adds. To optimize some of the models that had been created, the team turned to Kubeflow, a toolkit for machine learning on Kubernetes. “We tried to create a Kubernetes core server, we deployed Kubeflow, and we orchestrated the whole experiment, which ended up being a really good success,” he says.</p>
|
||||
<p>
|
||||
Based on that experience, Vallée’s team was tasked with building a self-service platform to help Babylon’s AI teams become more efficient, and by extension help get products to market faster. The main requirements: (1) the ability to give researchers and engineers access to the compute they needed, regardless of the size of the experiments they may need to run; (2) a way to provide teams with the best tools that they needed to do their work, on demand and in a centralized way; and (3) the training platform had to be close to the data that was being managed, because of the company’s expansion into different countries.</p>
|
||||
|
||||
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="greybanner">
|
||||
<div class="greyquotetext">
|
||||
“Delivering a self-service platform where users are empowered to run their own workload has enabled our data scientist community to do hyper parameter tuning and general algorithm development without any cloud skill and without the help of platform engineers, thus accelerating our innovation.”<p><div class="quoteauthortext">- CAROLINE HARGROVE, CHIEF TECHNOLOGY OFFICER AT BABYLON</div></p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
<p>
|
||||
Kubernetes was an enabler on every count. “Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need,” says Vallée. The need to keep data in every country in which Babylon operates requires a multi-region, multi-cloud strategy, and some countries might not even have a public cloud provider at all. “We wanted to make this platform portable so that we can run training jobs anywhere,” he says. “Kubernetes offered a base layer that allows you to deploy the platform outside of the cloud provider, and then deploy whatever tooling you need. That was a very good selling point for us.” </p>
|
||||
<p>
|
||||
Once the team decided to build the Babylon AI Research platform on top of Kubernetes, they referred to the Cloud Native Landscape to build out the stack: Prometheus and Grafana for monitoring; an Istio service mesh to control the network on the training platform and control what access all of the workflows would have; Helm to deploy the stack; and Flux to manage the GitOps part of the pipeline. </p>
|
||||
<p>
|
||||
The cloud native AI platform has had a huge impact at Babylon. The first research projects run on the platform mostly involved machine learning and natural language processing. These experiments required a huge amount of compute—1600 CPU, 3.2 TB RAM—which was much more than Babylon had in-house. Plus, access to compute used to take hours, or sometimes even days, depending on how busy the platform team was. “Now, with Kubernetes and the self-service platform that we provide, it’s pretty much instantaneous,” says Vallée. </p>
|
||||
<p>
|
||||
Another important type of work that’s done on the platform is clinical validation for new applications such as Babylon’s Symptom Checker, which calculates the probability of a disease given the evidence input by the user. “Being in healthcare, we want all of our models to be safe before they’re going to hit production,” says Vallée. Using Argo for GitOps “enabled us to scale the process massively.” </p>
|
||||
|
||||
</p>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
|
||||
<div class="article image overlay" style="background-image: url('/images/babylon2.jpg');">
|
||||
<div class="quotetext">
|
||||
“Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases.” <p><div class="quoteauthortext">- JEAN MARIE FERDEGUE, DIRECTOR OF PLATFORM OPERATIONS AT BABYLON</div></p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section5">
|
||||
<div class="fullcol">
|
||||
<p>
|
||||
Researchers used to have to wait up to 10 hours to get results on new versions of their models. With Kubernetes, that time is now down to under 20 minutes. Plus, previously they could only run one clinical validation at a time, now they can run many parallel ones if they need to—a huge benefit considering that in the past three years, Babylon has grown from 100 to 1,600 employees. </p>
|
||||
<p>
|
||||
“Delivering a self-service platform where users are empowered to run their own workload has enabled our data scientist community to do hyper parameter tuning and general algorithm development without any cloud skill and without the help of platform engineers, thus accelerating our innovation,” says Chief Technology Officer Caroline Hargrove.</p>
|
||||
<p>
|
||||
Adds Director of Platform Operations Jean Marie Ferdegue: “Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases.” </p>
|
||||
<p>
|
||||
Plus, as Babylon continues to expand, “it will be very easy to onboard new countries,” says Vallée. “Fifteen months ago when we deployed this platform, we had one big environment in the U.K., but now we have one in Canada, we have one in Asia, and we have one coming in the U.S. This is one of the things that Kubernetes and the other cloud native projects have enabled for us.”
|
||||
</p>
|
||||
<p>
|
||||
Babylon’s road map for cloud native involves onboarding all of the company’s AI efforts to the platform. Increasingly, that includes AI services of care. “I think this is going to be an interesting field where AI and healthcare meet,” Vallée says. “It’s kind of a complex problem and there’s a lot of issues around this. So with our platform, we want to say, ‘What can we do to make this less painful for our developers and machine learning engineers?’”
|
||||
</p>
|
||||
</div>
|
||||
</section>
|
||||
</body>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 4.1 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 9.2 KiB |
@@ -0,0 +1,117 @@
|
||||
---
|
||||
title: Booking.com Case Study
|
||||
linkTitle: Booking.com
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/case-studies-gradient.css
|
||||
logo: booking.com_featured_logo.png
|
||||
featured: true
|
||||
weight: 3
|
||||
quote: >
|
||||
We realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform.
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
<div class="article image overlay" style="background-image: url('/images/booking1.jpg')">
|
||||
<h1> CASE STUDY: Booking.com</h1>
|
||||
<div class="subhead">After Learning the Ropes with a Kubernetes Distribution, Booking.com Built a Platform of Its Own</div>
|
||||
</div>
|
||||
|
||||
|
||||
<div class="details">
|
||||
Company <b>Booking.com</b> Location <b>Netherlands</b> Industry <b>Travel</b>
|
||||
</div>
|
||||
|
||||
<hr>
|
||||
<section class="section1">
|
||||
<div class="colsgradient">
|
||||
<div class="col1">
|
||||
<h2>Challenge</h2>
|
||||
In 2016, Booking.com migrated to an OpenShift platform, which gave product developers faster access to infrastructure. But because Kubernetes was abstracted away from the developers, the infrastructure team became a “knowledge bottleneck” when challenges arose. Trying to scale that support wasn’t sustainable.
|
||||
|
||||
|
||||
<h2>Solution</h2>
|
||||
After a year operating OpenShift, the platform team decided to build its own vanilla Kubernetes platform—and ask developers to learn some Kubernetes in order to use it. “This is not a magical platform,” says Ben Tyler, Principal Developer, B Platform Track. “We’re not claiming that you can just use it with your eyes closed. Developers need to do some learning, and we’re going to do everything we can to make sure they have access to that knowledge.”
|
||||
|
||||
<h2>Impact</h2>
|
||||
Despite the learning curve, there’s been a great uptick in adoption of the new Kubernetes platform. Before containers, creating a new service could take a couple of days if the developers understood Puppet, or weeks if they didn’t. On the new platform, it can take as few as 10 minutes. About 500 new services were built on the platform in the first 8 months.
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
<div class="article image overlay" style="background-image: url('/images/booking2.JPG');">
|
||||
<div class="quotetext">
|
||||
“As our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better, more native Kubernetes experience, which is great. It’s a super healthy dynamic.”
|
||||
<p><div class="quoteauthortext">- BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM</div></p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
<section class="section2">
|
||||
<div class="fullcol">
|
||||
<h4>Booking.com has a long history with Kubernetes: In 2015, a team at the travel platform prototyped a container platform based on Mesos and Marathon.
|
||||
</h4>
|
||||
|
||||
<p>Impressed by what the technology offered, but in need of enterprise features at its scale—the site handles more than 1.5 million room-night reservations a day on average—the team decided to adopt an OpenShift platform.</p>
|
||||
|
||||
<p>This platform, which was wrapped in a Heroku-style, high-level CLI interface, “was definitely popular with our product developers,” says Ben Tyler, Principal Developer, B Platform Track. “We gave them faster access to infrastructure.”</p>
|
||||
|
||||
<p>But, he adds, “anytime something went slightly off the rails, developers didn’t have any of the knowledge required to support themselves.”</p>
|
||||
|
||||
<p>And after a year of operating this platform, the infrastructure team found that it had become “a knowledge bottleneck,” he says. “Most of the developers who used it did not know it was Kubernetes underneath. An application failure and a platform failure both looked like failures of that Heroku-style tool.”</p>
|
||||
<p>
|
||||
Scaling the necessary support did not seem feasible or sustainable, so the platform team needed a new solution. The understanding of Kubernetes that they had gained operating the OpenShift platform gave them confidence to build a vanilla Kubernetes platform of their own and customize it to suit the company’s needs.</p>
|
||||
|
||||
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="greybanner">
|
||||
<div class="greyquotetext">
|
||||
“For entering the landscape, OpenShift was definitely very helpful. It shows you what the technology can do, and it makes it easy for you to use it. After we spent some time on it, we realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform. We definitely benefit in the long term for taking that step and investing the time in gaining that knowledge.”<p><div class="quoteauthortext">- EDUARD IACOBOAIA, SENIOR SYSTEM ADMINISTRATOR, B PLATFORM TRACK AT BOOKING.COM</div></p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
<p>
|
||||
“For entering the landscape, OpenShift was definitely very helpful,” says Eduard Iacoboaia, Senior System Administrator, B Platform Track. “It shows you what the technology can do, and it makes it easy for you to use it. After we spent some time on it, we realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform. We definitely benefit in the long term for taking that step and investing the time in gaining that knowledge.” </p>
|
||||
<p>
|
||||
Iacoboaia’s team had customized a lot of OpenShift tools to make them work at Booking.com, and “those integrations points were kind of fragile,” he says. “We spent much more time understanding all the components of Kubernetes, how they work, how they interact with each other.” That research led the team to switch from OpenShift’s built-in Ansible playbooks to Puppet deployments, which are used for the rest of Booking’s infrastructure. The control plane was also moved from inside the cluster onto bare metal, as the company runs tens of thousands of bare-metal servers and a large infrastructure for running applications on bare metal. (Booking runs Kubernetes in multiple clusters in multiple data centers across the various regions where it has compute.) “We decided to keep it as simple as possible and to also use the tools that we know best,” says Iacoboaia. </p>
|
||||
<p>
|
||||
The other big change was that product engineers would have to learn Kubernetes in order to onboard. “This is not a magical platform,” says Tyler. “We’re not claiming that you can just use it with your eyes closed. Developers need to do some learning, and we’re going to do everything we can to make sure they have access to that knowledge.” That includes trainings, blog posts, videos, and Udemy courses. </p>
|
||||
<p>
|
||||
Despite the learning curve, there’s been a great uptick in adoption of the new Kubernetes platform. “I think the reason we’ve been able to strike this bargain successfully is that we’re not asking them to learn a proprietary app system,” says Tyler. “We’re asking them to learn something that’s open source, where the knowledge is transferable. They’re investing in their own careers by learning Kubernetes.”</p>
|
||||
<p>
|
||||
One clear sign that this strategy has been a success is that in the support channel, when users have questions, other product engineers are jumping in to respond. “I haven’t seen that kind of community engagement around a particular platform product internally before,” says Tyler. “It helps a lot that it’s visibly an ecosystem standard outside of the company, so people feel value in investing in that knowledge and sharing it with others, which is really, really powerful.” </p>
|
||||
|
||||
|
||||
</div>
|
||||
</section>
|
||||
|
||||
|
||||
<div class="article image overlay" style="background-image: url('/images/booking3.jpg');">
|
||||
<div class="quotetext">
|
||||
“We have a tutorial. You follow the tutorial. Your code is running. Then, it’s business-logic time. The time to gain access to resources is decreased enormously.” <p><div class="quoteauthortext">- BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM</div></p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section5">
|
||||
<div class="fullcol">
|
||||
<p>
|
||||
There’s other quantifiable evidence too: Before containers, creating a new service could take a couple of days if the developers understood Puppet, or weeks if they didn’t. On the new platform, it takes 10 minutes. “We have a tutorial. You follow the tutorial. Your code is running. Then, it’s business-logic time,” says Tyler. “The time to gain access to resources is decreased enormously.” About 500 new services were built in the first 8 months on the platform, with hundreds of releases per day. </p>
|
||||
<p>
|
||||
The platform offers different “layers of contracts, so to speak,” says Tyler. “At the very base, it’s just Kubernetes. If you’re a pro Kubernetes user, here’s a Kubernetes API, just like you get from GKE or AKS. We’re trying to be a provider on that same level. But our whole job inside the company is to be a bigger value add than just vanilla infrastructure, so we provide a set of base images for our main stacks, Perl and Java.”
|
||||
</p>
|
||||
<p>
|
||||
And “as our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better more native Kubernetes experience, which is great,” says Tyler. “It’s a super healthy dynamic.”</p>
|
||||
<p>
|
||||
The platform also includes other CNCF technologies, such as Envoy, Helm, and Prometheus. Most of the critical service traffic for Booking.com is routed through Envoy, and Prometheus is used primarily to monitor infrastructure components. Helm is consumed as a packaging standard. The team also developed and open sourced Shipper, an extension for Kubernetes to add more complex rollout strategies and multi-cluster orchestration.
|
||||
</p>
|
||||
<p>
|
||||
To be sure, there have been internal discussions about the wisdom of building a Kubernetes platform from the ground up. “This is not really our core competency—Kubernetes and travel, they’re kind of far apart, right?” says Tyler. “But we’ve made a couple of bets on CNCF components that have worked out really well for us. Envoy and Kubernetes, in particular, have been really beneficial to our organization. We were able to customize them, either because we could look at the source code or because they had extension points, and we were able to get value out of them very quickly without having to change any paradigms internally.”
|
||||
</p>
|
||||
</div>
|
||||
</section>
|
||||
</body>
|
||||
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.9 KiB |
@@ -0,0 +1,103 @@
|
||||
---
|
||||
title: Booz Allen Case Study
|
||||
linkTitle: Booz Allen Hamilton
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/case-studies-gradient.css
|
||||
logo: booz-allen-featured-logo.svg
|
||||
featured: true
|
||||
weight: 2
|
||||
quote: >
|
||||
Kubernetes is a great solution for us. It allows us to rapidly iterate on our clients’ demands.
|
||||
---
|
||||
|
||||
|
||||
|
||||
<div class="article image overlay" style="background-image: url('/images/BoozAllen4.jpg')">
|
||||
<h1> CASE STUDY: Booz Allen Hamilton</h1>
|
||||
<div class="subhead">How Booz Allen Hamilton Is Helping Modernize the Federal Government with Kubernetes</div>
|
||||
</div>
|
||||
|
||||
|
||||
<div class="details">
|
||||
Company <b>Booz Allen Hamilton</b> Location <b>United States</b> Industry <b>Government</b>
|
||||
</div>
|
||||
|
||||
<hr>
|
||||
<section class="section1">
|
||||
<div class="colsgradient">
|
||||
<div class="col1">
|
||||
<h2>Challenge</h2>
|
||||
In 2017, Booz Allen Hamilton’s Strategic Innovation Group worked with the federal government to relaunch the decade-old recreation.gov website, which provides information and real-time booking for more than 100,000 campsites and facilities on federal lands across the country. The infrastructure needed to be agile, reliable, and scalable—as well as repeatable for the other federal agencies that are among Booz Allen Hamilton’s customers.
|
||||
|
||||
<h2>Solution</h2>
|
||||
“The only way that we thought we could be successful with this problem across all the different agencies is to create a microservice architecture and containers, so that we could be very dynamic and very agile to any given agency for whatever requirements that they may have,” says Booz Allen Hamilton Senior Lead Technologist Martin Folkoff. To meet those requirements, Folkoff’s team looked to Kubernetes for orchestration.
|
||||
|
||||
<h2>Impact</h2>
|
||||
With the recreation.gov Kubernetes platform, changes can be implemented in about 30 minutes, compared to the multiple hours or even days legacy government applications require to review the code, get approval, and deploy the fix. Recreation.gov deploys to production on average 10 times a day. With monitoring, security, and logging built in, developers can create and publish new services to production within a week. Additionally, Folkoff says, “supporting the large, existing monoliths in the government is extremely expensive,” and migrating into a more modern platform has resulted in perhaps 50% cost savings.
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
<div class="article image overlay" style="background-image: url('/images/BoozAllen2.jpg');">
|
||||
<div class="quotetext">
|
||||
"When there’s a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that’s the problem we’re trying to help the government solve with tools like Kubernetes."
|
||||
<p><div class="quoteauthortext">- JOSH BOYD, CHIEF TECHNOLOGIST AT BOOZ ALLEN HAMILTON</div></p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
<section class="section2">
|
||||
<div class="fullcol">
|
||||
<h4>The White House launched an IT modernization effort in 2017, and in addition to improving cybersecurity and shifting to the public cloud and a consolidated IT model, “the federal government is looking to provide a better experience to citizens in every way that we interact with the government through every channel,” says Booz Allen Hamilton Senior Lead Technologist Martin Folkoff.</h4>
|
||||
|
||||
<p>To that end, Folkoff’s Strategic Innovation Group worked with the federal government last year to relaunch the decade-old recreation.gov website, which provides information and real-time booking for more than 100,000 campsites and facilities on federal lands across the country.</p>
|
||||
|
||||
<p>The infrastructure needed to be agile, reliable, and scalable—as well as repeatable for the other federal agencies that are among Booz Allen Hamilton’s customers. “The only way that we thought we could be successful with this problem across all the different agencies is to create a microservice architecture, so that we could be very dynamic and very agile to any given agency for whatever requirements that they may have,” says Folkoff.</p>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="greybanner">
|
||||
<div class="greyquotetext">
|
||||
"With CNCF, there’s a lot of focus on scale, and so there’s a lot of comfort knowing that as the project grows, we’re going to be comfortable using that tool set."<p><div class="quoteauthortext">- MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON</div></p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
<p>
|
||||
Booz Allen Hamilton, which has provided consulting services to the federal government for more than a century, introduced microservices, Docker containers, and AWS to its federal agency clients about five years ago. The next logical step was Kubernetes for orchestration. “Knowing that we had to be really agile and really reliable and scalable, we felt that the only technology that we know that can enable those kinds of things are the ones the CNCF provides,” Folkoff says. “One of the things that is always important for the government is to make sure that the things that we build really endure. Using technology that is supported across multiple different companies and has strong governance gives people a lot of confidence.”</p>
|
||||
<p>
|
||||
Kubernetes was also aligned with the government’s open source and IT modernization initiatives, so there has been an uptick in its usage at federal agencies over the past two years. “Now that Kubernetes is becoming offered as a service by the cloud providers like AWS and Microsoft, we’re starting to see even more interest,” says Chief Technologist Josh Boyd. Adds Folkoff: “With CNCF, there’s a lot of focus on scale, and so there’s a lot of comfort knowing that as the project grows, we’re going to be comfortable using that tool set.” </p>
|
||||
<p>
|
||||
The greenfield recreation.gov project allowed the team to build a new Kubernetes-enabled site running on AWS, and the migration lasted only a week, when the old site didn’t take bookings. “For the actual transition, we just swapped a DNS server, and it only took about 35 seconds between the old site being down and our new site being up and available,” Folkoff adds. </p>
|
||||
</p>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
|
||||
<div class="article image overlay" style="background-image: url('/images/BoozAllen1.png');">
|
||||
<div class="quotetext">
|
||||
"Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day’s event" <p><div class="quoteauthortext">- MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON</div></p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section5">
|
||||
<div class="fullcol">
|
||||
<p>
|
||||
In addition to its work with the Department of Interior for recreation.gov, Booz Allen Hamilton has brought Kubernetes to various Defense, Intelligence, and civilian agencies. Says Boyd: “When there’s a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that’s the problem we’re trying to help the government solve with tools like Kubernetes.”</p>
|
||||
<p>
|
||||
For recreation.gov, the impact was clear and immediate. With the Kubernetes platform, Folkoff says, “if a new requirement for a permit comes out, we have the ability to design and develop and implement that completely independently of reserving a campsite. It provides a much better experience to users.” Today, changes can be implemented in about 30 minutes, compared to the multiple hours or even days legacy government applications require to review the code, get approval, and deploy the fix. Recreation.gov deploys to production on average 10 times a day. </p>
|
||||
<p>
|
||||
Developer velocity has been improved. “When I want to do monitoring or security or logging, I don’t have to do anything to my services or my application to enable that anymore,” says Boyd. “I get all of this magic just by being on the Kubernetes platform.” With all of those things built in, developers can create and publish new services to production within one week. </p>
|
||||
<p>
|
||||
Additionally, Folkoff says, “supporting the large, existing monoliths in the government is extremely expensive,” and migrating into a more modern platform has resulted in perhaps 50% cost savings. “Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day’s event,” he says. “For example, during a popular campsite release, camping-related services are scaled out while permit services are scaled down.”</p>
|
||||
<p>
|
||||
So far, “Kubernetes is a great solution for us,” says Folkoff. “It allows us to rapidly iterate on our clients’ demands.” Looking ahead, the team sees further adoption of the Kubernetes platform across federal agencies. Says Boyd: “You get the ability for the rapid delivery of business value for your customers. You now have observability into everything that you’re doing. You don’t have these onesies and twosies unicorn servers anymore. Now everything that you deploy is deployed in the same way, it’s all instrumented the same way, and it’s all built and deployed the same way through our CI/CD processes.”</p>
|
||||
<p>
|
||||
They also see a push toward re-platforming. “There’s still a lot of legacy workloads out there,” says Boyd. “We’ve got the new challenges of greenfield development and integration with legacy systems, but also that brown field of ‘Hey, how do I take this legacy monolith and get it onto a platform where now it’s instrumented with all the magic of the Kubernetes platform without having to do a whole lot to my application?’ I think re-platforming is a pretty big use case for the government right now.”</p>
|
||||
<p>
|
||||
And given the success that they’ve had with Kubernetes so far, Boyd says, “I think at this point that technology is becoming pretty easy to sell.” Adds Folkoff: “People are really excited about being able to deploy, scale, be reliable, and do cheaper maintenance of all of this.”
|
||||
</p>
|
||||
</div>
|
||||
</section>
|
||||
</body>
|
||||
@@ -1 +0,0 @@
|
||||
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215 127"><defs><style>.cls-1{fill:#fbfbfb;}.cls-2{fill:#918f90;}.cls-3{fill:#231f20;}.cls-4{fill:#fff;}</style></defs><title>kubernetes.io-logos</title><rect class="cls-1" x="-3.55202" y="-3.16104" width="223.25536" height="134.51136"/><g id="g10"><g id="g12"><path id="path14" class="cls-2" d="M58.27642,43.45186A13.87083,13.87083,0,1,1,44.40989,29.577,13.86679,13.86679,0,0,1,58.27642,43.45186"/><path id="path16" class="cls-2" d="M118.31862,43.45186A13.87534,13.87534,0,1,1,104.44607,29.577a13.868,13.868,0,0,1,13.87255,13.87483"/><path id="path18" class="cls-2" d="M58.27642,78.10812A13.87083,13.87083,0,1,1,44.40989,64.23586,13.86592,13.86592,0,0,1,58.27642,78.10812"/><path id="path20" class="cls-2" d="M88.30182,60.78355A13.87432,13.87432,0,1,1,74.42662,46.9099a13.876,13.876,0,0,1,13.8752,13.87365"/><path id="path22" class="cls-2" d="M88.30182,26.12046a13.87432,13.87432,0,1,1-13.8752-13.874,13.8772,13.8772,0,0,1,13.8752,13.874"/><path id="path24" class="cls-2" d="M88.30182,95.44422a13.87432,13.87432,0,1,1-13.8752-13.87233,13.88079,13.88079,0,0,1,13.8752,13.87233"/><path id="path26" class="cls-3" d="M104.405,91.88866a13.87443,13.87443,0,0,1,0-27.74885h57.96422a13.87443,13.87443,0,1,1,0,27.74885H104.405"/><path id="path28" class="cls-4" d="M108.44973,74.99434a3.07749,3.07749,0,0,0-2.90728-1.56908c-2.38678,0-3.75361,1.90181-3.75361,4.58681,0,2.60465,1.39092,4.5882,3.77637,4.5882a3.36511,3.36511,0,0,0,3.11217-1.83873l2.67963,1.44431a6.15354,6.15354,0,0,1-5.888,3.26586c-4.15781,0-6.95236-2.89435-6.95236-7.45964,0-4.40183,2.91073-7.45392,7.06838-7.45392a6.0724,6.0724,0,0,1,5.819,3.19984l-2.95428,1.23635"/><path id="path30" class="cls-4" d="M124.883,74.99434a3.07653,3.07653,0,0,0-2.91095-1.56908c-2.38369,0-3.74223,1.90181-3.74223,4.58681,0,2.60465,1.38424,4.5882,3.77234,4.5882a3.36145,3.36145,0,0,0,3.11217-1.83873l2.67889,1.44431a6.148,6.148,0,0,1-5.88579,3.26586c-4.15787,0-6.95353-2.89435-6.95353-7.45964,0-4.40183,2.90728-7.45392,7.06662-7.45392a6.08392,6.08392,0,0,1,5.82338,3.19984L124.883,74.99434"/><path id="path32" class="cls-4" d="M139.27909,78.98589h-2.91462v-5.41h2.91462a2.705,2.705,0,1,1,0,5.41Zm.78061-8.22983-6.88083.02438v14.466h3.1856v-3.448l3.69523-.02152a5.51047,5.51047,0,1,0,0-11.02093"/><path id="path34" class="cls-3" d="M178.45064,88.67875a2.45448,2.45448,0,1,0,2.45419-2.49252A2.4339,2.4339,0,0,0,178.45064,88.67875Zm5.36147,0a2.90728,2.90728,0,1,1-2.90728-2.90786,2.86847,2.86847,0,0,1,2.90728,2.90786"/><path id="path36" class="cls-3" d="M180.77632,88.4782h-.5302V87.34657h.73581c.398,0,.77694.105.77694.56112C181.75887,88.46212,181.27054,88.4782,180.77632,88.4782Zm.564.34309a.88252.88252,0,0,0,.82026-.9136c0-.5852-.32458-.90332-1.0626-.90332h-1.25647v3.26726h.40463V88.82129h.6778l.91794,1.45034h.47145l-.973-1.45034"/></g></g></svg>
|
||||
|
Before Width: | Height: | Size: 2.8 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: CCP Games
|
||||
content_url: https://cloud.google.com/customers/ccp-games/
|
||||
---
|
||||
@@ -5,11 +5,7 @@ linkTitle: chinaunicom
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
logo: chinaunicom_featured_logo.png
|
||||
featured: true
|
||||
weight: 1
|
||||
quote: >
|
||||
Kubernetes has improved our experience using cloud infrastructure. There is currently no alternative technology that can replace it.
|
||||
featured: false
|
||||
---
|
||||
|
||||
<div class="banner1" style="background-image: url('/images/CaseStudy_chinaunicom_banner1.jpg')">
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215 127"><defs><style>.cls-1{fill:#fbfbfb;}.cls-2{fill:#2d2a26;}.cls-3{fill:#7d77b7;}.cls-4{fill:#ce1141;}.cls-5{fill:#009ddd;}.cls-6{fill:#f47a3f;}.cls-7{fill:#62bb46;}.cls-8{fill:#febe10;}</style></defs><title>kubernetes.io-logos</title><rect class="cls-1" x="-3.55202" y="-3.16104" width="223.25536" height="134.51136"/><path class="cls-2" d="M55.45758,63.38456a13.5171,13.5171,0,1,0,13.51376,13.515A13.52915,13.52915,0,0,0,55.45758,63.38456Zm0,24.37138a10.85428,10.85428,0,1,1,10.857-10.85638A10.87113,10.87113,0,0,1,55.45758,87.75594Z"/><path class="cls-2" d="M171.99062,77.07207c-.72693-.38066-5.1347-2.65285-5.77024-2.98164-2.31351-1.17937-3.134-2.227-3.134-3.99876,0-2.45829,2.01913-4.04731,5.151-4.04731a10.02931,10.02931,0,0,1,4.65811,1.395,1.35062,1.35062,0,0,0,.64672.16139,1.32785,1.32785,0,0,0,.66238-2.47883,12.80669,12.80669,0,0,0-5.96721-1.73741c-4.599,0-7.81231,2.75934-7.81231,6.70711,0,3.54721,2.33072,5.22038,4.61289,6.3856.63763.32484,5.09881,2.62542,5.76844,2.97772a4.46184,4.46184,0,0,1,2.73581,3.89862c0,2.13465-1.8074,4.40384-5.15493,4.40384a10.0211,10.0211,0,0,1-6.48209-2.855l-.20571-.19969-1.96907,1.79233.23225.22922a12.61506,12.61506,0,0,0,8.42462,3.69442c4.88887,0,7.81111-3.59336,7.81111-7.06515A7.12542,7.12542,0,0,0,171.99062,77.07207Z"/><path class="cls-2" d="M27.74831,66.04738a10.7845,10.7845,0,0,1,7.67687,3.1762,1.39844,1.39844,0,0,0,1.88011,0,1.32506,1.32506,0,0,0,0-1.87767l-.16108-.16741a13.5269,13.5269,0,1,0,.55047,18.86116L35.8143,84.15594a10.85243,10.85243,0,1,1-8.066-18.10856Z"/><path class="cls-2" d="M119.36676,66.04738a10.78435,10.78435,0,0,1,7.67566,3.1762,1.40036,1.40036,0,0,0,1.88159,0,1.32136,1.32136,0,0,0,0-1.87767l-.16227-.16741a13.52616,13.52616,0,1,0,.552,18.86116l-1.88218-1.88372a10.85235,10.85235,0,1,1-8.06478-18.10856Z"/><path class="cls-2" d="M96.4737,63.38456a1.26776,1.26776,0,0,0-1.1082.73839c-.2181.41476-7.95227,19.54645-7.95258,19.54645,0,0-7.73479-19.13169-7.95316-19.54645a1.267,1.267,0,0,0-1.10789-.73839,1.25029,1.25029,0,0,0-1.1761.96915c-.15382.54294-4.51785,24.62385-4.51785,24.62385a1.26706,1.26706,0,0,0-.02353.24129,1.19944,1.19944,0,0,0,2.37686.22925l3.77888-20.6S86.08181,86.86249,86.296,87.29143a1.2006,1.2006,0,0,0,2.23327,0c.21417-.42894,7.50585-18.44338,7.50585-18.44338l3.92849,21.42051h2.4375s-4.5972-25.37191-4.751-25.91485A1.25082,1.25082,0,0,0,96.4737,63.38456Z"/><path class="cls-2" d="M144.52511,63.38456a1.27135,1.27135,0,0,0-1.11605.758c-.21837.42832-10.00942,24.60937-10.00942,24.60937a1.21412,1.21412,0,0,0-.09229.46692,1.198,1.198,0,0,0,2.31352.43888l3.8024-9.34973h10.20729l4.05395,9.96056h2.58922s-10.419-25.69768-10.63319-26.126A1.26312,1.26312,0,0,0,144.52511,63.38456Zm-4.01776,14.26213,4.01776-9.883,4.02257,9.883Z"/><path class="cls-2" d="M197.13782,64.85835a1.33185,1.33185,0,0,0-1.332-1.32961H180.75732a1.3287,1.3287,0,0,0,0,2.65739h6.30894V90.26856h2.4354V66.18613h6.30415A1.33186,1.33186,0,0,0,197.13782,64.85835Z"/><path class="cls-3" d="M116.06206,29.12533a5.73633,5.73633,0,0,1-.49861,5.11963L109.174,48.61779l-.054.06514-2.31053-14.57869c-.18427-1.39926,1.31271-1.99622,2.19139-2.66854-.04373-.20633-.27146-.19518-.41265-.2929l-2.15819-.022-.06514-.06487a4.94419,4.94419,0,0,1,2.636-4.36057,5.12476,5.12476,0,0,1,5.65138.553A5.32954,5.32954,0,0,1,116.06206,29.12533Z"/><path class="cls-4" d="M104.29294,28.62613a5.1566,5.1566,0,0,1,.64,3.27588l-2.60339,16.69376c.01056.022-.01085.04389-.03228.05461l-.67294-1.345L95.09431,32.72685a5.06253,5.06253,0,0,1,6.76866-6.20491A5.4244,5.4244,0,0,1,104.29294,28.62613Z"/><path class="cls-5" d="M125.50952,35.65509a5.12575,5.12575,0,0,1-.29287,5.15267,8.54241,8.54241,0,0,1-2.45109,2.10463l-13.52643,9.285h-.03259l.152-.44478,7.16983-16.18412a5.1622,5.1622,0,0,1,5.29364-2.58183A5.22333,5.22333,0,0,1,125.50952,35.65509Z"/><path class="cls-6" d="M94.78,35.56854l7.4627,16.6289h-.11916L87.07826,41.827a4.96079,4.96079,0,0,1-1.63774-5.17408A5.07442,5.07442,0,0,1,94.78,35.56854Z"/><path class="cls-7" d="M129.4368,47.39209a5.12788,5.12788,0,0,1-.61867,5.09822,5.06429,5.06429,0,0,1-4.1544,1.95233l-16.043.01087,13.43957-9.35035a5.19275,5.19275,0,0,1,4.74048-.31474A5.26886,5.26886,0,0,1,129.4368,47.39209Z"/><path class="cls-8" d="M81.93661,47.39209a5.12816,5.12816,0,0,0,.61821,5.09822,5.06593,5.06593,0,0,0,4.15483,1.95233l16.04316.01087L89.31305,45.10316a5.19268,5.19268,0,0,0-4.74046-.31474A5.2689,5.2689,0,0,0,81.93661,47.39209Z"/></svg>
|
||||
|
Before Width: | Height: | Size: 4.4 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 6.1 KiB |
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: Comcast
|
||||
content_url: https://youtu.be/lmeFkH-rHII
|
||||
---
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
@@ -1 +0,0 @@
|
||||
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215 127"><defs><style>.cls-1{fill:#fbfbfb;}.cls-2{fill:#0075c9;}</style></defs><title>kubernetes.io-logos</title><rect class="cls-1" x="-4.03751" y="-4.582" width="223.25536" height="134.51136"/><path class="cls-2" d="M60.85857,43.59905a2.41437,2.41437,0,0,0-2.38123-2.38123H19.43513a2.41437,2.41437,0,0,0-2.38123,2.38123V81.74831a2.41436,2.41436,0,0,0,2.38123,2.38122H58.47734a2.41436,2.41436,0,0,0,2.38123-2.38122ZM37.98886,70.884a11.98933,11.98933,0,0,0,3.72067-.74414.33416.33416,0,0,1,.39687.14882,14.28731,14.28731,0,0,0,2.87732,3.86949c.14883.24805-.14883.39687-.14883.39687a14.109,14.109,0,0,1-6.846,1.63709A13.89042,13.89042,0,0,1,23.7511,62.59926,13.42058,13.42058,0,0,1,37.74081,48.9072,15.13234,15.13234,0,0,1,45.82707,51.338c.5457.34726.5457.49609.39687.69452a29.88443,29.88443,0,0,0-2.282,3.72067.30167.30167,0,0,1-.49609.09922,10.304,10.304,0,0,0-6.00268-1.6867,7.97435,7.97435,0,0,0-7.987,8.3343A8.46744,8.46744,0,0,0,37.98886,70.884Zm12.15418.39686a3.86949,3.86949,0,1,1,3.8695-3.86949A3.87447,3.87447,0,0,1,50.143,71.28082Z"/><path class="cls-2" d="M68.64717,62.54966c0-5.95307,4.51441-10.021,10.269-10.021a8.91,8.91,0,0,1,8.08626,4.71285l-3.52224,1.73631a5.26387,5.26387,0,0,0-4.564-2.82771,5.99857,5.99857,0,0,0-6.05228,6.34994A5.99858,5.99858,0,0,0,78.91621,68.85a5.29072,5.29072,0,0,0,4.564-2.82772l3.52224,1.6867a8.9438,8.9438,0,0,1-8.08626,4.76246c-5.80424.04962-10.269-3.96871-10.269-9.92177"/><path class="cls-2" d="M88.73878,62.54966a10.09619,10.09619,0,1,1,10.07061,9.97139,9.73545,9.73545,0,0,1-10.07061-9.97139m15.97407,0c0-3.62145-2.33162-6.34994-5.90346-6.34994s-5.85385,2.72849-5.85385,6.34994c0,3.57184,2.282,6.34994,5.85385,6.34994s5.90346-2.7781,5.90346-6.34994"/><polygon class="cls-2" points="125.747 72.174 116.52 59.573 116.52 72.174 112.402 72.174 112.402 52.876 116.669 52.876 125.598 64.98 125.598 52.876 129.716 52.876 129.716 72.174 125.747 72.174"/><path class="cls-2" d="M133.18837,62.54966c0-5.95307,4.4648-10.021,10.26905-10.021a8.85137,8.85137,0,0,1,8.08625,4.71285l-3.52224,1.73631a5.26385,5.26385,0,0,0-4.564-2.82771,6.02732,6.02732,0,0,0-6.0523,6.34994,5.99858,5.99858,0,0,0,6.0523,6.34994,5.29073,5.29073,0,0,0,4.564-2.82772l3.52224,1.6867a8.94378,8.94378,0,0,1-8.08625,4.76246c-5.80425.04962-10.26905-3.96871-10.26905-9.92177"/><path class="cls-2" d="M154.22255,64.4844V52.87592h4.16714V64.33558a4.197,4.197,0,0,0,4.564,4.564c2.97654,0,4.51441-1.83554,4.51441-4.564V52.87592h4.21676V64.4844c0,4.81207-2.82771,8.08626-8.73117,8.08626s-8.73117-3.32381-8.73117-8.08626"/><path class="cls-2" d="M186.66678,72.17379l-3.8199-6.846h-3.02614v6.846H175.7032V52.82632H184.732c4.01833,0,6.49877,2.62927,6.49877,6.25072a5.55983,5.55983,0,0,1-4.21676,5.75464l4.36558,7.34211Zm.39688-13.09676a2.62258,2.62258,0,0,0-2.87731-2.62927h-4.316V61.6567h4.316a2.55935,2.55935,0,0,0,2.87731-2.57967"/><path class="cls-2" d="M198.12644,70.13982a2.45577,2.45577,0,0,1-4.91128,0,2.405,2.405,0,0,1,2.48044-2.38122A2.36249,2.36249,0,0,1,198.12644,70.13982Zm-4.316,0a1.86535,1.86535,0,0,0,1.88513,1.93475,1.9101,1.9101,0,1,0-1.88513-1.93475Zm1.48826,1.24023h-.5457V68.99882a4.18583,4.18583,0,0,1,.94257-.09922,1.60369,1.60369,0,0,1,.84336.19843.64015.64015,0,0,1,.248.5457.62217.62217,0,0,1-.49609.54571v.04961c.24805.09922.34727.248.44648.59531s.09922.49609.19843.59531h-.59531c-.09922-.09922-.09922-.29765-.19843-.59531a.45069.45069,0,0,0-.49609-.39686h-.24805l-.09921.94255Zm0-1.33945h.24805c.29766,0,.5457-.09922.5457-.34727,0-.19843-.14882-.34727-.49609-.34727-.14882,0-.248,0-.29766.04961v.64493Z"/></svg>
|
||||
|
Before Width: | Height: | Size: 3.5 KiB |
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: Concur
|
||||
content_url: http://searchitoperations.techtarget.com/news/450297178/Tech-firms-roll-out-Kubernetes-in-production
|
||||
---
|
||||
@@ -0,0 +1 @@
|
||||
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 215 127"><defs><style>.cls-1{fill:none;}.cls-2{fill:#fbfbfb;}.cls-3{clip-path:url(#clip-path);}.cls-4{fill:#ee3248;fill-rule:evenodd;}</style><clipPath id="clip-path"><rect class="cls-1" x="4.70501" y="-8.81268" width="206.90403" height="145.3255"/></clipPath></defs><rect class="cls-2" x="-3.37342" y="-3.34411" width="223.25536" height="134.51135"/><g class="cls-3"><g class="cls-3"><path class="cls-4" d="M28.02166,50.76936l7.69058-.0617c6.9525.12305,7.75228,4.1837,4.61435,13.41275-2.64567,7.87531-6.76768,12.67414-14.58165,12.61279h-6.091ZM169.22325,61.044c4.55274-11.01316,10.52065-15.19686,22.76431-15.50454,10.9518-.24609,15.81224,4.79908,11.813,17.41187C199.49376,76.67151,191.67987,82.209,179.86693,82.209c-12.98175.06134-16.24263-7.87514-10.64368-21.165m8.429.73843c2.83006-7.01411,6.95215-11.87463,13.04345-11.93633,5.47555-.06125,6.46007,3.938,3.99905,12.36706-3.13794,10.82842-7.69068,15.5659-13.90466,15.44286-6.89106-.06135-6.768-6.82946-3.13784-15.87359m-15.07382-8.67536,2.09172-6.02932a34.76316,34.76316,0,0,0-10.95146-1.66134c-7.62924-.0616-13.35114,2.33806-15.6892,7.69066-3.69162,8.183,1.4766,10.70564,7.69084,13.59749,9.10583,4.245,3.876,11.56684-4.86069,10.82842-3.50688-.3077-6.58311-1.90724-9.65961-3.38384l-1.96859,6.15264A33.79646,33.79646,0,0,0,142.64393,82.209c9.0444-.55369,14.64308-4.184,16.91972-9.90595,2.584-6.52159-1.41525-10.52064-7.38324-12.42789-12.42831-3.99939-4.98338-15.75088,10.398-6.76811M95.57659,46.15492a19.153,19.153,0,0,1,2.215,3.62993L87.76306,81.47059H93.854l8.36766-26.45618,9.59791,26.45618h8.61375l-.36939-.98451,10.89012-34.33116h-6.15273l-7.99827,25.34837-9.22879-25.34837c-3.999,0-7.99836.06135-11.99767,0m-34.39259,0a14.395,14.395,0,0,1,2.21468,3.62993L53.43173,81.47059H79.826L81.05656,77.533H63.21437L67.152,65.16635H78.96492l1.23051-3.87627H68.3825L71.95081,49.9695H89.17822L90.347,46.15492c-9.72121,0-19.44208.06135-29.163,0m-42.26817,0a16.4482,16.4482,0,0,1,2.21468,3.62993L11.102,81.47059h8.61366l5.04517-.06135c14.766,0,21.77988-7.32179,24.73333-16.85828,4.245-13.5973-.92316-18.33469-13.47418-18.33469Z"/></g></g></svg>
|
||||
|
After Width: | Height: | Size: 2.2 KiB |
@@ -0,0 +1,110 @@
|
||||
---
|
||||
title: Denso Case Study
|
||||
linkTitle: Denso
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/case-studies-gradient.css
|
||||
logo: denso_featured_logo.svg
|
||||
featured: true
|
||||
weight: 4
|
||||
quote: >
|
||||
We got Kubernetes experts involved on our team, and it dramatically accelerated development speed.
|
||||
---
|
||||
|
||||
|
||||
<div class="article image overlay" style="background-image: url('/images/Denso2.jpg')">
|
||||
<h1> CASE STUDY: Denso</h1>
|
||||
<div class="subhead">How DENSO Is Fueling Development on the Vehicle Edge with Kubernetes</div>
|
||||
</div>
|
||||
|
||||
<div class="details">
|
||||
Company <b>Denso</b> Location <b>Japan</b> Industry <b>Automotive, Edge</b>
|
||||
</div>
|
||||
|
||||
<hr>
|
||||
<section class="section1">
|
||||
<div class="colsgradient">
|
||||
<div class="col1">
|
||||
<h2>Challenge</h2>
|
||||
DENSO Corporation is one of the biggest automotive components suppliers in the world. With the advent of connected cars, the company launched a Digital Innovation Department to expand into software, working on vehicle edge and vehicle cloud products. But there were several technical challenges to creating an integrated vehicle edge/cloud platform: "the amount of computing resources, the occasional lack of mobile signal, and an enormous number of distributed vehicles," says R&D Product Manager Seiichi Koizumi.
|
||||
|
||||
|
||||
<h2>Solution</h2>
|
||||
Koizumi’s team realized that because mobility services evolve every day, they needed the flexibility of the cloud native ecosystem for their platform. After considering other orchestrators, DENSO went with Kubernetes for orchestration and added Prometheus, Fluentd, Envoy, Istio, and Helm to the platform. Today, DENSO is using a vehicle edge computer, a private Kubernetes cloud, and managed Kubernetes (GKE, EKS, AKS).
|
||||
|
||||
<h2>Impact</h2>
|
||||
Critical layer features can take 2-3 years to implement in the traditional, waterfall model of development at DENSO. With the Kubernetes platform and agile methods, there’s a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and a new prototype is introduced every week. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," says Koizumi.
|
||||
</div>
|
||||
</section>
|
||||
<div class="article image overlay" style="background-image: url('/images/Denso1.png');">
|
||||
<div class="quotetext">
|
||||
"Another disruptive innovation is coming, so to survive in this situation, we need to change our culture."
|
||||
<p><div class="quoteauthortext">- SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO</div></p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
<section class="section2">
|
||||
<div class="fullcol">
|
||||
<h4>Spun off from Toyota in 1949, DENSO Corporation is one of the top automotive suppliers in the world today, with consolidated net revenue of $48.3 billion.
|
||||
</h4>
|
||||
|
||||
<p>The company’s mission is "contributing to a better world by creating value together with a vision for the future"—and part of that vision in recent years has been development on the vehicle edge and vehicle cloud.</p>
|
||||
|
||||
<p>With the advent of connected cars, DENSO established a Digital Innovation Department to expand its business beyond the critical layer of the engine, braking systems, and other automotive parts into the non-critical analytics and entertainment layer. Comparing connected cars to smartphones, R&D Product Manager Seiichi Koizumi says DENSO wants the ability to quickly and easily develop and install apps for the "blank slate" of the car, and iterate them based on the driver’s preferences. Thus "we need a flexible application platform," he says. </p>
|
||||
|
||||
<p>But working on vehicle edge and vehicle cloud products meant there were several technical challenges: "the amount of computing resources, the occasional lack of mobile signal, and an enormous number of distributed vehicles," says Koizumi. "We are tackling these challenges to create an integrated vehicle edge/cloud platform."</p>
|
||||
|
||||
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<div class="greybanner">
|
||||
<div class="greyquotetext">
|
||||
"We got Kubernetes experts involved on our team, and it dramatically accelerated development speed."<p><div class="quoteauthortext">— SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO</div></p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section3">
|
||||
<div class="fullcol">
|
||||
<p>
|
||||
Koizumi’s team realized that because mobility services evolve every day, they needed the flexibility of the cloud native ecosystem for their platform. As they evaluated technologies, they were led by these criteria: Because their service-enabler business needed to support multiple cloud and on-premise environments, the solution needed to be cloud agnostic, with no vendor lock-in and open governance. It also had to support an edge-cloud integrated environment.</p>
|
||||
<p>
|
||||
After considering other orchestrators, DENSO went with Kubernetes for orchestration and added Prometheus, Fluentd, Envoy, Istio, and Helm to the platform. During implementation, the team used "design thinking to clarify use cases and their value proposition," says Koizumi. Next, an agile development team worked on a POC, then an MVP, in DevOps style. "Even in the development phase, we are keeping a channel to end users," he adds. </p>
|
||||
<p>
|
||||
One lesson learned during this process was the value of bringing in experts. "We tried to learn Kubernetes and cloud native technologies from scratch, but it took more time than expected," says Koizumi. "We got Kubernetes experts involved on our team, and it dramatically accelerated development speed."</p>
|
||||
|
||||
</p>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
|
||||
<div class="article image overlay" style="background-image: url('/images/Denso4.jpg');">
|
||||
<div class="quotetext">
|
||||
"By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation." <p><div class="quoteauthortext">- SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO</div></p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section class="section5">
|
||||
<div class="fullcol">
|
||||
<p>
|
||||
Today, DENSO is using a vehicle edge computer, a private Kubernetes cloud, and managed Kubernetes on GKE, EKS, and AKS. "We are developing a vehicle edge/cloud integrated platform based on a microservice and service mesh architecture," says Koizumi. "We extend cloud into multiple vehicle edges and manage it as a unified platform."</p>
|
||||
<p>
|
||||
Cloud native has enabled DENSO to deliver applications via its new dash cam, which has a secure connection that collects data to the cloud. "It’s like a smartphone," he says. "We are installing new applications and getting the data through the cloud, and we can keep updating new applications all through the dash cam."</p>
|
||||
<p>
|
||||
The unified cloud native platform, combined with agile development, has had a positive impact on productivity. Critical layer features—those involving engines or braking systems, for example—can take 2-3 years to implement at DENSO, because of the time needed to test safety, but also because of the traditional, waterfall model of development. With the Kubernetes platform and agile methods, there’s a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and with the department’s scrum-style development, a new prototype is introduced every week. </p>
|
||||
<p>
|
||||
Application portability has also led to greater developer efficiency. "There’s no need to care about differences in the multi-cloud platform anymore," says Koizumi. Now, "we are also trying to have the same portability between vehicle edge and cloud platform."
|
||||
</p>
|
||||
<p>
|
||||
Another improvement: Automotive Tier-1 suppliers like DENSO always have multiple Tier-2 suppliers. "To provide automotive-grade high-availability services, we tried to do the same thing on a multi-cloud platform," says Koizumi. Before Kubernetes, maintaining two different systems simultaneously was difficult. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," he says.
|
||||
</p>
|
||||
<p>
|
||||
Cloud native has also profoundly changed the culture at DENSO. The Digital Innovation Department is known as "Noah’s Ark," and it has grown from 2 members to 70—with plans to more than double in the next year. The way they operate is completely different from the traditional Japanese automotive culture. But just as the company embraced change brought by hybrid cars in the past decade, Koizumi says, they’re doing it again now, as technology companies have moved into the connected car space. "Another disruptive innovation is coming," he says, "so to survive in this situation, we need to change our culture."
|
||||
</p>
|
||||
<p>
|
||||
Looking ahead, Koizumi and his team are expecting serverless and zero-trust security architecture to be important enhancements of Kubernetes. They are glad DENSO has come along for the ride. "Mobility service businesses require agility and flexibility," he says. "DENSO is trying to bring cloud native flexibility into the vehicle infrastructure."
|
||||
</p>
|
||||
</div>
|
||||
</section>
|
||||
</body>
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB |
@@ -1 +0,0 @@
|
||||
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215 127"><defs><style>.cls-1{fill:#fbfbfb;}.cls-2{fill:#e53238;}.cls-3{fill:#0064d2;}.cls-4{fill:#f5af02;}.cls-5{fill:#86b817;}</style></defs><title>kubernetes.io-logos</title><rect class="cls-1" x="-3.55202" y="-3.16104" width="223.25536" height="134.51136"/><path id="e" class="cls-2" d="M44.41375,44.77747c-12.0763,0-22.13948,5.12337-22.13948,20.58035,0,12.24533,6.76676,19.95671,22.4513,19.95671,18.46144,0,19.64488-12.16112,19.64488-12.16112H55.425S53.507,79.7017,44.17988,79.7017c-7.59672,0-13.06058-5.1318-13.06058-12.32478H65.30592V62.86323c0-7.11611-4.51743-18.08577-20.89217-18.08577Zm-.31183,5.76874c7.23129,0,12.16112,4.43,12.16112,11.06973H31.31716C31.31716,54.56709,37.75185,50.54621,44.10192,50.54621Z"/><path id="b" class="cls-3" d="M65.29958,29.80994V77.5521c0,2.71-.19342,6.51514-.19342,6.51514h8.53207s.30624-2.73291.30624-5.23052c0,0,4.21539,6.59475,15.67735,6.59475,12.06991,0,20.26852-8.37974,20.26852-20.38547,0-11.16875-7.5307-20.15159-20.249-20.15159-11.90983,0-15.61067,6.43136-15.61067,6.43136V29.80994ZM87.43905,50.79956c8.1964,0,13.40842,6.08315,13.40842,14.24644,0,8.75365-6.0197,14.48031-13.35,14.48031-8.748,0-13.46688-6.83041-13.46688-14.40235C74.03064,58.06838,78.265,50.79956,87.43905,50.79956Z"/><path id="a" class="cls-4" d="M131.09435,44.77747c-18.16788,0-19.33306,9.94784-19.33306,11.53747h9.04288s.47421-5.80771,9.66654-5.80771c5.97332,0,10.602,2.73408,10.602,7.99048v1.87094h-10.602c-14.07492,0-21.51583,4.11747-21.51583,12.47294,0,8.223,6.87517,12.69707,16.16611,12.69707,12.6621,0,16.741-6.99654,16.741-6.99654,0,2.78284.21455,5.52512.21455,5.52512h8.039s-.31183-3.39915-.31183-5.57384V59.69628c0-12.325-9.94141-14.91881-18.70941-14.91881Zm9.97836,21.204v2.49459c0,3.25362-2.00772,11.34258-13.82743,11.34258-6.47244,0-9.24752-3.23023-9.24752-6.97705,0-6.81622,9.34533-6.86012,23.07494-6.86012Z"/><path id="y" class="cls-5" d="M144.93431,46.33816h10.17324l14.6,29.25016,14.56661-29.25016h9.2155L166.95684,98.41267H157.2903l7.65638-14.51648Z"/></svg>
|
||||
|
Before Width: | Height: | Size: 2.0 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.1 KiB |
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: Ebay
|
||||
content_url: http://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/
|
||||
---
|
||||
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB |
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: Goldman Sachs
|
||||
content_url: http://blogs.wsj.com/cio/2016/02/24/big-changes-in-goldmans-software-emerge-from-small-containers/
|
||||
---
|
||||
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 27 KiB |
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: Home Office UK
|
||||
content_url: https://www.youtube.com/watch?v=F3iMkz_NSvU
|
||||
---
|
||||
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: JD.COM
|
||||
content_url: https://kubernetes.io/blog/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack
|
||||
---
|
||||
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 147 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 10 KiB |
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: LivePerson
|
||||
content_url: https://www.openstack.org/videos/video/running-kubernetes-on-openstack-at-liveperson
|
||||
---
|
||||
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: Monzo
|
||||
content_url: https://youtu.be/YkOY7DgXKyw
|
||||
---
|
||||
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 5.9 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.4 KiB |
@@ -5,11 +5,7 @@ linkTitle: Nav
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
logo: nav_featured_logo.png
|
||||
featured: true
|
||||
weight: 3
|
||||
quote: >
|
||||
The community is absolutely vital: being able to pass ideas around, talk about a lot of the similar challenges that we’re all facing, and just get help. I like that we’re able to tackle the same problems for different reasons but help each other along the way.
|
||||
featured: false
|
||||
---
|
||||
|
||||
<div class="banner1" style="background-image: url('/images/CaseStudy_nav_banner1.jpg')">
|
||||
|
||||
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: Philips
|
||||
content_url: https://cloud.google.com/customers/philips/
|
||||
---
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 3.8 KiB |
@@ -1 +0,0 @@
|
||||
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215 127"><defs><style>.cls-1{fill:#fbfbfb;}.cls-2{fill:#0b5ed7;}</style></defs><title>kubernetes.io-logos2</title><rect class="cls-1" x="-3.35417" y="-4.36563" width="223.25536" height="134.51136"/><g id="layer1"><g id="g2851"><g id="g2853"><path id="path2859" class="cls-2" d="M78.15934,46.64334H68.28353V59.503H58.00314V46.64334H48.12733V78.99717h9.87581V66.27081H68.28353V78.99717h9.87581Zm34.35383,25.85272V46.64334h-9.87581V78.99717h17.85736l1.48506-6.50112h-9.46661ZM95.33626,46.64334H85.46045V78.99717h9.87581Zm40.03656,0h-9.87121V78.99717h9.87121Zm48.68938,8.25741c0-1.7609,1.76092-2.5747,4.59767-2.5747a24.7387,24.7387,0,0,1,8.79536,1.63217l-.8092-7.04364a38.62324,38.62324,0,0,0-9.062-.94712c-7.98156,0-13.393,3.14941-13.393,9.74708,0,11.37005,15.42519,9.07121,15.42519,14.34934,0,2.02757-1.49424,3.108-5.1448,3.108a29.53736,29.53736,0,0,1-11.22751-2.5701l1.085,7.44824a32.59635,32.59635,0,0,0,10.2804,1.623c8.24823,0,15.01141-2.708,15.01141-10.83212,0-10.82293-15.55854-8.79536-15.55854-13.94016M156.20485,71.28227c9.19075,0,15.01142-4.7402,15.01142-12.99762,0-9.06661-6.22067-12.31717-16.36771-12.31717a111.49549,111.49549,0,0,0-12.03671.67586V78.99717h9.8758v-7.7149h3.5172Zm5.27352-12.8597c0,4.19308-2.02756,7.039-7.17236,7.039h-1.61839v-13.37c.57471-.03219,1.11263-.03219,1.61839-.03219,4.869,0,7.17236,2.29884,7.17236,6.36318M29.19408,71.28227c9.19535,0,15.01141-4.7402,15.01141-12.99762,0-9.06661-6.22066-12.31717-16.36313-12.31717a111.58362,111.58362,0,0,0-12.04131.67586V78.99717h9.87581v-7.7149Zm5.27814-12.8597c0,4.19308-2.03218,7.039-7.17238,7.039h-1.623v-13.37c.57471-.03219,1.11724-.03219,1.623-.03219,4.86894,0,7.17238,2.29884,7.17238,6.36318"/></g></g></g></svg>
|
||||
|
Before Width: | Height: | Size: 1.7 KiB |
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: Pokemon GO
|
||||
content_url: https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-to-life-on-Google-Cloud.html
|
||||
---
|
||||
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 68 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: Samsung SDS
|
||||
content_url: http://www.nextplatform.com/2016/05/24/samsung-experts-put-kubernetes-paces/
|
||||
---
|
||||
@@ -1 +0,0 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" role="img" viewBox="-6.20 0.80 1570.40 240.40"><title>Samsung SDS (member) logo</title><path fill="#034ea2" d="M76.753 211.407c-45.155 0-53.607-26.556-51.683-56.738h36.468c0 16.662.723 30.664 20.765 30.664 12.313 0 18.359-7.974 18.359-19.805 0-31.379-73.413-33.316-73.413-85.231 0-27.289 13.041-49.022 57.47-49.022 35.502 0 53.125 15.938 50.705 52.405H99.925c0-13.045-2.161-26.323-16.903-26.323-11.823 0-18.832 6.51-18.832 18.591 0 33.075 73.412 30.19 73.412 84.998 0 45.156-33.078 50.46-60.849 50.46zm72.427-2.893l48.31-174.338h48.045l47.334 174.338h-38.392l-9.661-38.638h-49.741l-9.902 38.638zm70.277-140.78h-.481l-16.654 75.345h34.763zm88.624 140.78V34.176h58.675l27.276 118.556h.49l28.976-118.556h56.75v174.338h-35.503V74.019h-.481l-33.562 134.495h-34.775L344.05 74.019h-.482v134.495zm247.979 2.893c-45.156 0-53.608-26.556-51.666-56.738h36.459c0 16.662.723 30.664 20.764 30.664 12.314 0 18.35-7.974 18.35-19.805 0-31.379-73.403-33.316-73.403-85.231 0-27.289 13.036-49.022 57.46-49.022 35.503 0 53.125 15.938 50.718 52.405H579.25c0-13.045-2.17-26.323-16.908-26.323-11.831 0-18.833 6.51-18.833 18.591 0 33.075 73.404 30.19 73.404 84.998 0 45.156-33.078 50.46-60.853 50.46zM759.617 34.176v123.628c0 26.082-14.724 53.603-59.165 53.603-40.072 0-59.395-20.761-59.395-53.603V34.176h36.46v121.217c0 21.493 9.179 29.94 22.465 29.94 15.926 0 23.173-10.617 23.173-29.94V34.176zm28.739 174.338V34.176h49.254l46.37 120.734h.483V34.176h34.04v174.338h-48.059L822.877 81.02h-.486v127.494zM1027.654 87.78c.232-16.18-2.428-30.423-21.734-30.423-22.707 0-22.707 30.663-22.707 64.479 0 54.559 5.321 64.22 26.082 64.22a57.325 57.325 0 0 0 18.109-3.375v-38.646h-19.797v-26.798h56.256v88.383c-9.894 1.92-34.77 5.787-49.263 5.787-61.336 0-68.328-25.351-68.328-91.509 0-43.95 2.17-88.623 61.818-88.623 35.744 0 57.943 20.046 55.773 56.505zm166.355 123.627c-45.156 0-53.603-26.556-51.675-56.738h36.476c0 16.662.715 30.664 20.76 30.664 12.315 0 18.351-7.974 18.351-19.805 0-31.379-73.408-33.316-73.408-85.231 0-27.289 13.045-49.022 57.47-49.022 35.502 0 53.12 15.938 50.71 52.405h-35.504c0-13.045-2.179-26.323-16.894-26.323-11.832 0-18.84 6.51-18.84 18.591 0 33.075 73.407 30.19 73.407 84.998 0 45.156-33.074 50.46-60.853 50.46zm86.445-177.231h60.853c47.817 0 56.746 31.869 56.746 86.205 0 26.796 4.098 88.133-58.193 88.133h-59.406zm36.475 147.531h17.619c22.216 0 26.565-16.662 26.565-60.37 0-32.11 0-60.355-25.36-60.355h-18.824zm156.453 29.7c-45.14 0-53.587-26.556-51.666-56.738h36.459c0 16.662.732 30.664 20.769 30.664 12.314 0 18.341-7.974 18.341-19.805 0-31.379-73.39-33.316-73.39-85.231 0-27.289 13.037-49.022 57.469-49.022 35.486 0 53.121 15.938 50.7 52.405h-35.493c0-13.045-2.17-26.323-16.903-26.323-11.824 0-18.833 6.51-18.833 18.591 0 33.075 73.4 30.19 73.4 84.998 0 45.156-33.083 50.46-60.853 50.46z" data-name="Layer 2"/></svg>
|
||||
|
Before Width: | Height: | Size: 2.8 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB |
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: SAP
|
||||
content_url: https://youtu.be/4gyeixJLabo
|
||||
---
|
||||
@@ -1 +0,0 @@
|
||||
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 215 127"><defs><style>.cls-1{fill:#fbfbfb;}.cls-2,.cls-3{fill-rule:evenodd;}.cls-2{fill:url(#linear-gradient);}.cls-3{fill:#fff;}.cls-4{fill:#0072bc;}</style><linearGradient id="linear-gradient" x1="113.16584" y1="109.70976" x2="113.16584" y2="24.03158" gradientTransform="matrix(1, 0, 0, -1, 0, 130.69843)" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#00b9f2"/><stop offset="0.205" stop-color="#00a3e1"/><stop offset="0.515" stop-color="#0088cd"/><stop offset="0.79" stop-color="#0078c0"/><stop offset="1" stop-color="#0072bc"/></linearGradient></defs><title>kubernetes.io-logos2</title><rect class="cls-1" x="-3.35417" y="-4.36563" width="223.25536" height="134.51136"/><path class="cls-2" d="M26.56814,106.66686H114.0994l85.66414-85.67819H26.56814v85.67819"/><path class="cls-3" d="M129.351,37.09889l-17.04846-.0103V77.62492L97.40957,37.08859h-14.767L69.92668,70.9884c-1.354-8.54717-10.19611-11.49954-17.15286-13.71218-4.59336-1.47478-9.46669-3.64434-9.42221-6.04238.03839-1.96872,2.61434-3.797,7.71848-3.52169,3.43179.18166,6.45626.45883,12.478,3.3625l5.92253-10.3141a46.10121,46.10121,0,0,0-19.3126-4.57041h-.03652c-7.25639,0-13.30392,2.35075-17.05221,6.22592a14.38121,14.38121,0,0,0-4.07929,9.9447,13.345,13.345,0,0,0,5.85371,11.90171,39.8171,39.8171,0,0,0,11.59318,5.30265c4.73334,1.46682,8.59586,2.74122,8.55139,5.4609a4.01425,4.01425,0,0,1-1.12178,2.66163c-1.17935,1.21681-2.99169,1.67423-5.49554,1.72058-4.82885.10253-8.41093-.65452-14.11576-4.02545L28.99005,85.842a39.37711,39.37711,0,0,0,19.29949,5.13317l.88487-.0103A23.27906,23.27906,0,0,0,63.844,86.04615c.22145-.17464.4209-.35489.625-.53654l-1.71075,4.56714H78.24585l2.59936-7.90529a28.27221,28.27221,0,0,0,9.10384,1.44388,28.668,28.668,0,0,0,8.88519-1.3657l2.50526,7.82711h25.25666V73.71043h5.50773c13.31609,0,21.19095-6.78211,21.19095-18.14448,0-12.6583-7.65153-18.46706-23.94388-18.46706ZM89.94858,71.78479a15.53362,15.53362,0,0,1-5.46231-.9551L89.88959,53.7803h.10253l5.31014,17.09715a16.07371,16.07371,0,0,1-5.35322.90687Zm40.4029-9.79582h-3.75484V48.251h3.75484c5.00957,0,9.00318,1.66393,9.00318,6.77837,0,5.29282-3.99361,6.96-9.00318,6.96"/><path class="cls-4" d="M134.86056,101.02945a4.4946,4.4946,0,1,1-.00225.16481q-.00037-.08243.00225-.16481Zm4.5133,5.55922a5.537,5.537,0,1,0-.11885.00077Q139.31444,106.5897,139.37386,106.58867Zm-1.17374-5.11913h1.11475l1.67609,2.76462h1.09415l-1.83013-2.81144A1.66065,1.66065,0,0,0,141.92453,99.66c0-1.25192-.75-1.8128-2.25478-1.8128h-2.43456v6.387h.96493Zm0-.82448v-1.979h1.31935c.66857,0,1.383.14185,1.383.93636,0,.994-.7285,1.04265-1.53892,1.04265Z"/></svg>
|
||||
|
Before Width: | Height: | Size: 2.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 4.8 KiB |
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: Soundcloud
|
||||
content_url: https://www.youtube.com/watch?v=5378N5iLb2Q
|
||||
---
|
||||
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 6.3 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB |
@@ -4,11 +4,7 @@ linkTitle: Spotify
|
||||
case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
logo: spotify_featured_logo.png
|
||||
featured: true
|
||||
weight: 2
|
||||
quote: >
|
||||
We saw the amazing community that’s grown up around Kubernetes, and we wanted to be part of that. We wanted to benefit from added velocity and reduced cost, and also align with the rest of the industry on best practices and tools.
|
||||
featured: false
|
||||
---
|
||||
|
||||
<div class="banner1" style="background-image: url('/images/CaseStudy_spotify_banner1.jpg')">
|
||||
|
||||
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: WePay
|
||||
content_url: http://thenewstack.io/wepay-kubernetes-changed-business/
|
||||
---
|
||||
@@ -1 +0,0 @@
|
||||
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 215 127"><defs><style>.cls-1{fill:none;}.cls-2{fill:#fbfbfb;}.cls-3{clip-path:url(#clip-path);}.cls-4{fill:#5791cd;}.cls-5{fill:#33a736;}.cls-6{fill:#a1aaad;}</style><clipPath id="clip-path"><rect class="cls-1" x="15.7031" y="42.28302" width="183.59379" height="43.44872"/></clipPath></defs><title>kubernetes.io-logos2</title><rect class="cls-2" x="-3.35417" y="-4.36563" width="223.25536" height="134.51136"/><g class="cls-3"><path class="cls-4" d="M33.07482,73.41877a1.64932,1.64932,0,0,1-.702-.11747l-14.3133-5.77157a3.76332,3.76332,0,0,1,.01212-6.98565l14.33379-5.71972a1.646,1.646,0,1,1,1.22037,3.05739L19.29205,63.60148a.472.472,0,0,0-.00167.87629l14.3133,5.7703a1.64632,1.64632,0,0,1-.52886,3.1707"/><path class="cls-5" d="M50.07448,63.2673a1.64887,1.64887,0,0,1-1.69823-1.90936l2.48422-15.23266a.47139.47139,0,0,0-.74878-.45236L37.78843,54.96637a1.6459,1.6459,0,0,1-1.98169-2.62846L48.12916,43.0453A3.763,3.763,0,0,1,54.10892,46.655L51.62471,61.88765a1.64753,1.64753,0,0,1-1.55023,1.37965"/><path class="cls-6" d="M50.58161,85.64955a3.7564,3.7564,0,0,1-2.41858-.75086l-12.3521-9.25332a1.64572,1.64572,0,0,1,1.97332-2.6343l12.35252,9.25331a.47145.47145,0,0,0,.74753-.45487L48.35116,66.58563a1.64592,1.64592,0,1,1,3.24722-.54015l2.53313,15.22388a3.77057,3.77057,0,0,1-3.5499,4.38019"/></g><polygon class="cls-4" points="89.507 78.162 87.134 78.162 82.224 62.9 82.142 62.9 77.231 78.162 74.899 78.162 66.43 55.494 70.97 55.494 76.004 70.224 76.086 70.224 80.791 55.494 83.574 55.494 88.279 70.224 88.361 70.224 93.353 55.494 97.895 55.494 89.507 78.162"/><g class="cls-3"><path class="cls-4" d="M102.44593,68.669a7.68938,7.68938,0,0,0,7.44722,6.17877,7.247,7.247,0,0,0,6.46473-3.80576h4.25562A11.55321,11.55321,0,0,1,109.72927,78.735,11.82749,11.82749,0,0,1,98.19074,66.78719a11.58182,11.58182,0,1,1,23.159-.28639c0,.73624-.08194,1.88177-.1225,2.16815Zm14.64861-3.27355a7.36081,7.36081,0,0,0-14.64861,0Z"/><path class="cls-5" d="M124.58243,55.49328h3.88729v3.47883h.08153a9.57913,9.57913,0,0,1,8.061-4.09256c7.6922,0,11.743,6.17877,11.743,12.2342a11.42958,11.42958,0,0,1-11.457,11.62089c-4.746,0-7.11945-2.4144-7.9786-3.84632h-.08194V85.73159H124.582V55.49328Zm11.74339,3.27355a8.04764,8.04764,0,1,0,7.77457,8.10193,7.99423,7.99423,0,0,0-7.77457-8.10193"/><path class="cls-5" d="M170.24583,78.16271v-3.519h-.08193a8.67529,8.67529,0,0,1-7.69221,4.09131,11.63792,11.63792,0,0,1-12.0302-11.82491c0-5.52406,3.88729-12.03019,12.0302-12.03019a8.983,8.983,0,0,1,7.69221,3.80535h.08193v-3.1916h4.2552V78.16313h-4.2552Zm-7.77414-19.39588c-5.23726,0-7.775,4.54158-7.775,8.10193a7.81723,7.81723,0,1,0,15.63109,0,7.74352,7.74352,0,0,0-7.85609-8.10193"/></g><polygon class="cls-5" points="194.714 55.493 187.881 73.088 181.212 55.493 176.629 55.493 185.672 77.711 182.358 85.732 186.777 85.732 199.297 55.494 199.297 55.493 194.714 55.493"/></svg>
|
||||
|
Before Width: | Height: | Size: 2.9 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: Zulily
|
||||
content_url: https://www.youtube.com/embed/of45hYbkIZs
|
||||
---
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 7.8 KiB |
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 8.6 KiB |
@@ -9,32 +9,132 @@ weight: 10
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
A node is a worker machine in Kubernetes, previously known as a `minion`. A node
|
||||
may be a VM or physical machine, depending on the cluster. Each node contains
|
||||
the services necessary to run [pods](/docs/concepts/workloads/pods/pod/) and is managed by the master
|
||||
components. The services on a node include the [container runtime](/docs/concepts/overview/components/#container-runtime), kubelet and kube-proxy. See
|
||||
[The Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) section in the
|
||||
architecture design doc for more details.
|
||||
Kubernetes runs your workload by placing containers into Pods to run on _Nodes_.
|
||||
A node may be a virtual or physical machine, depending on the cluster. Each node
|
||||
contains the services necessary to run
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}}, managed by the
|
||||
{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
|
||||
|
||||
Typically you have several nodes in a cluster; in a learning or resource-limited
|
||||
environment, you might have just one.
|
||||
|
||||
The [components](/docs/concepts/overview/components/#node-components) on a node include the
|
||||
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, a
|
||||
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}, and the
|
||||
{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Node Status
|
||||
## Management
|
||||
|
||||
A node's status contains the following information:
|
||||
There are two main ways to have Nodes added to the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}:
|
||||
|
||||
1. The kubelet on a node self-registers to the control plane
|
||||
2. You, or another human user, manually add a Node object
|
||||
|
||||
After you create a Node object, or the kubelet on a node self-registers, the
|
||||
control plane checks whether the new Node object is valid. For example, if you
|
||||
try to create a Node from the following JSON manifest:
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "Node",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "10.240.79.157",
|
||||
"labels": {
|
||||
"name": "my-first-k8s-node"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Kubernetes creates a Node object internally (the representation). Kubernetes checks
|
||||
that a kubelet has registered to the API server that matches the `metadata.name`
|
||||
field of the Node. If the node is healthy (if all necessary services are running),
|
||||
it is eligible to run a Pod. Otherwise, that node is ignored for any cluster activity
|
||||
until it becomes healthy.
|
||||
|
||||
{{< note >}}
|
||||
Kubernetes keeps the object for the invalid Node and continues checking to see whether
|
||||
it becomes healthy.
|
||||
|
||||
You, or a {{< glossary_tooltip term_id="controller" text="controller">}}, must explicitly
|
||||
delete the Node object to stop that health checking.
|
||||
{{< /note >}}
|
||||
|
||||
The name of a Node object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
|
||||
### Self-registration of Nodes
|
||||
|
||||
When the kubelet flag `--register-node` is true (the default), the kubelet will attempt to
|
||||
register itself with the API server. This is the preferred pattern, used by most distros.
|
||||
|
||||
For self-registration, the kubelet is started with the following options:
|
||||
|
||||
- `--kubeconfig` - Path to credentials to authenticate itself to the API server.
|
||||
- `--cloud-provider` - How to talk to a {{< glossary_tooltip text="cloud provider" term_id="cloud-provider" >}} to read metadata about itself.
|
||||
- `--register-node` - Automatically register with the API server.
|
||||
- `--register-with-taints` - Register the node with the given list of {{< glossary_tooltip text="taints" term_id="taint" >}} (comma separated `<key>=<value>:<effect>`).
|
||||
|
||||
No-op if `register-node` is false.
|
||||
- `--node-ip` - IP address of the node.
|
||||
- `--node-labels` - {{< glossary_tooltip text="Labels" term_id="label" >}} to add when registering the node in the cluster (see label restrictions enforced by the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)).
|
||||
- `--node-status-update-frequency` - Specifies how often kubelet posts node status to master.
|
||||
|
||||
When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and
|
||||
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled,
|
||||
kubelets are only authorized to create/modify their own Node resource.
|
||||
|
||||
### Manual Node administration
|
||||
|
||||
You can create and modify Node objects using
|
||||
{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}.
|
||||
|
||||
When you want to create Node objects manually, set the kubelet flag `--register-node=false`.
|
||||
|
||||
You can modify Node objects regardless of the setting of `--register-node`.
|
||||
For example, you can set labels on an existing Node, or mark it unschedulable.
|
||||
|
||||
You can use labels on Nodes in conjunction with node selectors on Pods to control
|
||||
scheduling. For example, you can to constrain a Pod to only be eligible to run on
|
||||
a subset of the available nodes.
|
||||
|
||||
Marking a node as unschedulable prevents the scheduler from placing new pods onto
|
||||
that Node, but does not affect existing Pods on the Node. This is useful as a
|
||||
preparatory step before a node reboot or other maintenance.
|
||||
|
||||
To mark a Node unschedulable, run:
|
||||
|
||||
```shell
|
||||
kubectl cordon $NODENAME
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Pods that are part of a {{< glossary_tooltip term_id="daemonset" >}} tolerate
|
||||
being run on an unschedulable Node. DaemonSets typically provide node-local services
|
||||
that should run on the Node even if it is being drained of workload applications.
|
||||
{{< /note >}}
|
||||
|
||||
## Node status
|
||||
|
||||
A Node's status contains the following information:
|
||||
|
||||
* [Addresses](#addresses)
|
||||
* [Conditions](#condition)
|
||||
* [Capacity and Allocatable](#capacity)
|
||||
* [Info](#info)
|
||||
|
||||
Node status and other details about a node can be displayed using the following command:
|
||||
You can use `kubectl` to view a Node's status and other details:
|
||||
|
||||
```shell
|
||||
kubectl describe node <insert-node-name-here>
|
||||
```
|
||||
Each section is described in detail below.
|
||||
|
||||
Each section of the output is described below.
|
||||
|
||||
### Addresses
|
||||
|
||||
@@ -49,15 +149,23 @@ The usage of these fields varies depending on your cloud provider or bare metal
|
||||
|
||||
The `conditions` field describes the status of all `Running` nodes. Examples of conditions include:
|
||||
|
||||
| Node Condition | Description |
|
||||
|----------------|-------------|
|
||||
| `Ready` | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 40 seconds) |
|
||||
| `MemoryPressure` | `True` if pressure exists on the node memory -- that is, if the node memory is low; otherwise `False` |
|
||||
| `PIDPressure` | `True` if pressure exists on the processes -- that is, if there are too many processes on the node; otherwise `False` |
|
||||
| `DiskPressure` | `True` if pressure exists on the disk size -- that is, if the disk capacity is low; otherwise `False` |
|
||||
| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` |
|
||||
{{< table caption = "Node conditions, and a description of when each condition applies." >}}
|
||||
| Node Condition | Description |
|
||||
|----------------------|-------------|
|
||||
| `Ready` | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 40 seconds) |
|
||||
| `DiskPressure` | `True` if pressure exists on the disk size--that is, if the disk capacity is low; otherwise `False` |
|
||||
| `MemoryPressure` | `True` if pressure exists on the node memory--that is, if the node memory is low; otherwise `False` |
|
||||
| `PIDPressure` | `True` if pressure exists on the processes—that is, if there are too many processes on the node; otherwise `False` |
|
||||
| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` |
|
||||
{{< /table >}}
|
||||
|
||||
The node condition is represented as a JSON object. For example, the following response describes a healthy node.
|
||||
{{< note >}}
|
||||
If you use command-line tools to print details of a cordoned Node, the Condition includes
|
||||
`SchedulingDisabled`. `SchedulingDisabled` is not a Condition in the Kubernetes API; instead,
|
||||
cordoned nodes are marked Unschedulable in their spec.
|
||||
{{< /note >}}
|
||||
|
||||
The node condition is represented as a JSON object. For example, the following structure describes a healthy node:
|
||||
|
||||
```json
|
||||
"conditions": [
|
||||
@@ -72,20 +180,24 @@ The node condition is represented as a JSON object. For example, the following r
|
||||
]
|
||||
```
|
||||
|
||||
If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout` (an argument passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/)), all the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the apiserver is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node.
|
||||
If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout` (an argument passed to the {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), all the Pods on the node are scheduled for deletion by the node controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the API server is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the API server is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node.
|
||||
|
||||
In versions of Kubernetes prior to 1.5, the node controller would [force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)
|
||||
these unreachable pods from the apiserver. However, in 1.5 and higher, the node controller does not force delete pods until it is
|
||||
confirmed that they have stopped running in the cluster. You can see the pods that might be running on an unreachable node as being in
|
||||
the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce from the underlying infrastructure if a node has
|
||||
permanently left a cluster, the cluster administrator may need to delete the node object by hand. Deleting the node object from
|
||||
Kubernetes causes all the Pod objects running on the node to be deleted from the apiserver, and frees up their names.
|
||||
The node controller does not force delete pods until it is confirmed that they have stopped
|
||||
running in the cluster. You can see the pods that might be running on an unreachable node as
|
||||
being in the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce from the
|
||||
underlying infrastructure if a node has permanently left a cluster, the cluster administrator
|
||||
may need to delete the node object by hand. Deleting the node object from Kubernetes causes
|
||||
all the Pod objects running on the node to be deleted from the API server, and frees up their
|
||||
names.
|
||||
|
||||
The node lifecycle controller automatically creates
|
||||
[taints](/docs/concepts/configuration/taint-and-toleration/) that represent conditions.
|
||||
[taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that represent conditions.
|
||||
The scheduler takes the Node's taints into consideration when assigning a Pod to a Node.
|
||||
Pods can also have tolerations which let them tolerate a Node's taints.
|
||||
|
||||
See [Taint Nodes by Condition](/docs/concepts/configuration/taint-and-toleration/#taint-nodes-by-condition)
|
||||
for more details.
|
||||
|
||||
### Capacity and Allocatable {#capacity}
|
||||
|
||||
Describes the resources available on the node: CPU, memory and the maximum
|
||||
@@ -104,48 +216,10 @@ on a Node.
|
||||
Describes general information about the node, such as kernel version, Kubernetes version (kubelet and kube-proxy version), Docker version (if used), and OS name.
|
||||
This information is gathered by Kubelet from the node.
|
||||
|
||||
## Management
|
||||
### Node controller
|
||||
|
||||
Unlike [pods](/docs/concepts/workloads/pods/pod/) and [services](/docs/concepts/services-networking/service/),
|
||||
a node is not inherently created by Kubernetes: it is created externally by cloud
|
||||
providers like Google Compute Engine, or it exists in your pool of physical or virtual
|
||||
machines. So when Kubernetes creates a node, it creates
|
||||
an object that represents the node. After creation, Kubernetes
|
||||
checks whether the node is valid or not. For example, if you try to create
|
||||
a node from the following content:
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "Node",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "10.240.79.157",
|
||||
"labels": {
|
||||
"name": "my-first-k8s-node"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Kubernetes creates a node object internally (the representation), and
|
||||
validates the node by health checking based on the `metadata.name` field. If the node is valid -- that is, if all necessary
|
||||
services are running -- it is eligible to run a pod. Otherwise, it is
|
||||
ignored for any cluster activity until it becomes valid.
|
||||
The name of a Node object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
|
||||
{{< note >}}
|
||||
Kubernetes keeps the object for the invalid node and keeps checking to see whether it becomes valid.
|
||||
You must explicitly delete the Node object to stop this process.
|
||||
{{< /note >}}
|
||||
|
||||
Currently, there are three components that interact with the Kubernetes node
|
||||
interface: node controller, kubelet, and kubectl.
|
||||
|
||||
### Node Controller
|
||||
|
||||
The node controller is a Kubernetes master component which manages various
|
||||
aspects of nodes.
|
||||
The node {{< glossary_tooltip text="controller" term_id="controller" >}} is a
|
||||
Kubernetes control plane component that manages various aspects of nodes.
|
||||
|
||||
The node controller has multiple roles in a node's life. The first is assigning a
|
||||
CIDR block to the node when it is registered (if CIDR assignment is turned on).
|
||||
@@ -168,6 +242,7 @@ checks the state of each node every `--node-monitor-period` seconds.
|
||||
#### Heartbeats
|
||||
|
||||
Heartbeats, sent by Kubernetes nodes, help determine the availability of a node.
|
||||
|
||||
There are two forms of heartbeats: updates of `NodeStatus` and the
|
||||
[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io).
|
||||
Each Node has an associated Lease object in the `kube-node-lease`
|
||||
@@ -188,13 +263,7 @@ a Lease object.
|
||||
|
||||
#### Reliability
|
||||
|
||||
In Kubernetes 1.4, we updated the logic of the node controller to better handle
|
||||
cases when a large number of nodes have problems with reaching the master
|
||||
(e.g. because the master has networking problems). Starting with 1.4, the node
|
||||
controller looks at the state of all nodes in the cluster when making a
|
||||
decision about pod eviction.
|
||||
|
||||
In most cases, node controller limits the eviction rate to
|
||||
In most cases, node controller limits the eviction rate to
|
||||
`--node-eviction-rate` (default 0.1) per second, meaning it won't evict pods
|
||||
from more than 1 node per 10 seconds.
|
||||
|
||||
@@ -220,62 +289,12 @@ completely unhealthy (i.e. there are no healthy nodes in the cluster). In such a
|
||||
case, the node controller assumes that there's some problem with master
|
||||
connectivity and stops all evictions until some connectivity is restored.
|
||||
|
||||
Starting in Kubernetes 1.6, the NodeController is also responsible for evicting
|
||||
pods that are running on nodes with `NoExecute` taints, when the pods do not tolerate
|
||||
the taints. Additionally, as an alpha feature that is disabled by default, the
|
||||
NodeController is responsible for adding taints corresponding to node problems like
|
||||
node unreachable or not ready. See [this documentation](/docs/concepts/configuration/taint-and-toleration/)
|
||||
for details about `NoExecute` taints and the alpha feature.
|
||||
The node controller is also responsible for evicting pods running on nodes with
|
||||
`NoExecute` taints, unless those pods tolerate that taint.
|
||||
The node controller also adds {{< glossary_tooltip text="taints" term_id="taint" >}}
|
||||
corresponding to node problems like node unreachable or not ready. This means
|
||||
that the scheduler won't place Pods onto unhealthy nodes.
|
||||
|
||||
Starting in version 1.8, the node controller can be made responsible for creating taints that represent
|
||||
Node conditions. This is an alpha feature of version 1.8.
|
||||
|
||||
### Self-Registration of Nodes
|
||||
|
||||
When the kubelet flag `--register-node` is true (the default), the kubelet will attempt to
|
||||
register itself with the API server. This is the preferred pattern, used by most distros.
|
||||
|
||||
For self-registration, the kubelet is started with the following options:
|
||||
|
||||
- `--kubeconfig` - Path to credentials to authenticate itself to the apiserver.
|
||||
- `--cloud-provider` - How to talk to a cloud provider to read metadata about itself.
|
||||
- `--register-node` - Automatically register with the API server.
|
||||
- `--register-with-taints` - Register the node with the given list of taints (comma separated `<key>=<value>:<effect>`). No-op if `register-node` is false.
|
||||
- `--node-ip` - IP address of the node.
|
||||
- `--node-labels` - Labels to add when registering the node in the cluster (see label restrictions enforced by the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) in 1.13+).
|
||||
- `--node-status-update-frequency` - Specifies how often kubelet posts node status to master.
|
||||
|
||||
When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and
|
||||
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled,
|
||||
kubelets are only authorized to create/modify their own Node resource.
|
||||
|
||||
#### Manual Node Administration
|
||||
|
||||
A cluster administrator can create and modify node objects.
|
||||
|
||||
If the administrator wishes to create node objects manually, set the kubelet flag
|
||||
`--register-node=false`.
|
||||
|
||||
The administrator can modify node resources (regardless of the setting of `--register-node`).
|
||||
Modifications include setting labels on the node and marking it unschedulable.
|
||||
|
||||
Labels on nodes can be used in conjunction with node selectors on pods to control scheduling,
|
||||
e.g. to constrain a pod to only be eligible to run on a subset of the nodes.
|
||||
|
||||
Marking a node as unschedulable prevents new pods from being scheduled to that
|
||||
node, but does not affect any existing pods on the node. This is useful as a
|
||||
preparatory step before a node reboot, etc. For example, to mark a node
|
||||
unschedulable, run this command:
|
||||
|
||||
```shell
|
||||
kubectl cordon $NODENAME
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Pods created by a DaemonSet controller bypass the Kubernetes scheduler
|
||||
and do not respect the unschedulable attribute on a node. This assumes that daemons belong on
|
||||
the machine even if it is being drained of applications while it prepares for a reboot.
|
||||
{{< /note >}}
|
||||
|
||||
{{< caution >}}
|
||||
`kubectl cordon` marks a node as 'unschedulable', which has the side effect of the service
|
||||
@@ -285,34 +304,40 @@ eligible for, effectively removing incoming load balancer traffic from the cordo
|
||||
|
||||
### Node capacity
|
||||
|
||||
The capacity of the node (number of cpus and amount of memory) is part of the node object.
|
||||
Normally, nodes register themselves and report their capacity when creating the node object. If
|
||||
you are doing [manual node administration](#manual-node-administration), then you need to set node
|
||||
capacity when adding a node.
|
||||
Node objects track information about the Node's resource capacity (for example: the amount
|
||||
of memory available, and the number of CPUs).
|
||||
Nodes that [self register](#self-registration-of-nodes) report their capacity during
|
||||
registration. If you [manually](#manual-node-administration) add a Node, then
|
||||
you need to set the node's capacity informaton when you add it.
|
||||
|
||||
The Kubernetes scheduler ensures that there are enough resources for all the pods on a node. It
|
||||
checks that the sum of the requests of containers on the node is no greater than the node capacity. It
|
||||
includes all containers started by the kubelet, but not containers started directly by the [container runtime](/docs/concepts/overview/components/#container-runtime) nor any process running outside of the containers.
|
||||
The Kubernetes {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} ensures that
|
||||
there are enough resources for all the Pods on a Node. The scheduler checks that the sum
|
||||
of the requests of containers on the node is no greater than the node's capacity.
|
||||
That sum of requests includes all containers managed by the kubelet, but excludes any
|
||||
containers started directly by the container runtime, and also excludes any
|
||||
processes running outside of the kubelet's control.
|
||||
|
||||
If you want to explicitly reserve resources for non-Pod processes, follow this tutorial to
|
||||
{{< note >}}
|
||||
If you want to explicitly reserve resources for non-Pod processes, see
|
||||
[reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
|
||||
{{< /note >}}
|
||||
|
||||
## Node topology
|
||||
|
||||
{{< feature-state state="alpha" >}}
|
||||
{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
|
||||
|
||||
If you have enabled the `TopologyManager`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/), then
|
||||
the kubelet can use topology hints when making resource assignment decisions.
|
||||
|
||||
## API Object
|
||||
|
||||
Node is a top-level resource in the Kubernetes REST API. More details about the
|
||||
API object can be found at:
|
||||
[Node API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
|
||||
See [Control Topology Management Policies on a Node](/docs/tasks/administer-cluster/topology-manager/)
|
||||
for more information.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
* Read about [node components](/docs/concepts/overview/components/#node-components)
|
||||
* Read about node-level topology: [Control Topology Management Policies on a node](/docs/tasks/administer-cluster/topology-manager/)
|
||||
* Learn about the [components](/docs/concepts/overview/components/#node-components) that make up a node.
|
||||
* Read the [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
|
||||
* Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
|
||||
section of the architecture design document.
|
||||
* Read about [taints and tolerations](/docs/concepts/configuration/taint-and-toleration/).
|
||||
* Read about [cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling).
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -30,6 +30,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
|
||||
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes.
|
||||
* [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod.
|
||||
* [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
|
||||
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.
|
||||
* [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
|
||||
|
||||
@@ -395,7 +395,7 @@ For in-depth documentation on the vSphere cloud provider, visit the [vSphere clo
|
||||
## IBM Cloud Kubernetes Service
|
||||
|
||||
### Compute nodes
|
||||
By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters).
|
||||
By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes).
|
||||
|
||||
The name of the Kubernetes Node object is the private IP address of the IBM Cloud Kubernetes Service worker node instance.
|
||||
|
||||
@@ -422,3 +422,15 @@ If you wish to use the external cloud provider, its repository is [TencentCloud/
|
||||
|
||||
The Tencent cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
|
||||
Note that the Kubernetes Node name must match the Tencent VM private IP.
|
||||
|
||||
## Alibaba Cloud Kubernetes
|
||||
|
||||
If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-alibaba-cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud).
|
||||
|
||||
### Node Name
|
||||
|
||||
Alibaba Cloud does not require the format of node name, but the kubelet needs to add `--provider-id=${REGION_ID}.${INSTANCE_ID}`. The parameter `${REGION_ID}` represents the region id of the Kubernetes and `${INSTANCE_ID}` denotes the Alibaba ECS (Elastic Compute Service) ID.
|
||||
|
||||
### Load Balancers
|
||||
|
||||
You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) .
|
||||
@@ -131,14 +131,14 @@ classes:
|
||||
namespace). These are important to isolate from other traffic because failures
|
||||
in leader election cause their controllers to fail and restart, which in turn
|
||||
causes more expensive traffic as the new controllers sync their informers.
|
||||
|
||||
|
||||
* The `workload-high` priority level is for other requests from built-in
|
||||
controllers.
|
||||
|
||||
|
||||
* The `workload-low` priority level is for requests from any other service
|
||||
account, which will typically include all requests from controllers runing in
|
||||
Pods.
|
||||
|
||||
|
||||
* The `global-default` priority level handles all other traffic, e.g.
|
||||
interactive `kubectl` commands run by nonprivileged users.
|
||||
|
||||
@@ -150,7 +150,7 @@ are built in and may not be overwritten:
|
||||
special `exempt` FlowSchema classifies all requests from the `system:masters`
|
||||
group into this priority level. You may define other FlowSchemas that direct
|
||||
other requests to this priority level, if appropriate.
|
||||
|
||||
|
||||
* The special `catch-all` priority level is used in combination with the special
|
||||
`catch-all` FlowSchema to make sure that every request gets some kind of
|
||||
classification. Typically you should not rely on this catch-all configuration,
|
||||
@@ -164,7 +164,7 @@ are built in and may not be overwritten:
|
||||
|
||||
## Resources
|
||||
The flow control API involves two kinds of resources.
|
||||
[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io)
|
||||
[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io)
|
||||
define the available isolation classes, the share of the available concurrency
|
||||
budget that each can handle, and allow for fine-tuning queuing behavior.
|
||||
[FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io)
|
||||
@@ -204,7 +204,7 @@ to balance progress between request flows.
|
||||
|
||||
The queuing configuration allows tuning the fair queuing algorithm for a
|
||||
priority level. Details of the algorithm can be read in the [enhancement
|
||||
proposal](#what-s-next), but in short:
|
||||
proposal](#whats-next), but in short:
|
||||
|
||||
* Increasing `queues` reduces the rate of collisions between different flows, at
|
||||
the cost of increased memory usage. A value of 1 here effectively disables the
|
||||
@@ -233,20 +233,21 @@ given mouse (low-intensity flow) is squished by the elephants (high-intensity fl
|
||||
an illustrative collection of numbers of elephants. See
|
||||
https://play.golang.org/p/Gi0PLgVHiUg , which computes this table.
|
||||
|
||||
{{< table caption="Example Shuffle Sharding Configurations" >}}
|
||||
|HandSize| Queues| 1 elephant| 4 elephants| 16 elephants|
|
||||
|--------|-----------|------------|----------------|--------------------|
|
||||
| 12| 32| 4.428838398950118e-09| 0.11431348830099144| 0.9935089607656024|
|
||||
| 10| 32| 1.550093439632541e-08| 0.0626479840223545| 0.9753101519027554|
|
||||
| 10| 64| 6.601827268370426e-12| 0.00045571320990370776| 0.49999929150089345|
|
||||
| 9| 64| 3.6310049976037345e-11| 0.00045501212304112273| 0.4282314876454858|
|
||||
| 8| 64| 2.25929199850899e-10| 0.0004886697053040446| 0.35935114681123076|
|
||||
| 8| 128| 6.994461389026097e-13| 3.4055790161620863e-06| 0.02746173137155063|
|
||||
| 7| 128| 1.0579122850901972e-11| 6.960839379258192e-06| 0.02406157386340147|
|
||||
| 7| 256| 7.597695465552631e-14| 6.728547142019406e-08| 0.0006709661542533682|
|
||||
| 6| 256| 2.7134626662687968e-12| 2.9516464018476436e-07| 0.0008895654642000348|
|
||||
| 6| 512| 4.116062922897309e-14| 4.982983350480894e-09| 2.26025764343413e-05|
|
||||
| 6| 1024| 6.337324016514285e-16| 8.09060164312957e-11| 4.517408062903668e-07|
|
||||
{{< table caption = "Example Shuffle Sharding Configurations" >}}
|
||||
HandSize | Queues | 1 elephant | 4 elephants | 16 elephants
|
||||
|----------|-----------|------------|----------------|--------------------|
|
||||
| 12 | 32 | 4.428838398950118e-09 | 0.11431348830099144 | 0.9935089607656024 |
|
||||
| 10 | 32 | 1.550093439632541e-08 | 0.0626479840223545 | 0.9753101519027554 |
|
||||
| 10 | 64 | 6.601827268370426e-12 | 0.00045571320990370776 | 0.49999929150089345 |
|
||||
| 9 | 64 | 3.6310049976037345e-11 | 0.00045501212304112273 | 0.4282314876454858 |
|
||||
| 8 | 64 | 2.25929199850899e-10 | 0.0004886697053040446 | 0.35935114681123076 |
|
||||
| 8 | 128 | 6.994461389026097e-13 | 3.4055790161620863e-06 | 0.02746173137155063 |
|
||||
| 7 | 128 | 1.0579122850901972e-11 | 6.960839379258192e-06 | 0.02406157386340147 |
|
||||
| 7 | 256 | 7.597695465552631e-14 | 6.728547142019406e-08 | 0.0006709661542533682 |
|
||||
| 6 | 256 | 2.7134626662687968e-12 | 2.9516464018476436e-07 | 0.0008895654642000348 |
|
||||
| 6 | 512 | 4.116062922897309e-14 | 4.982983350480894e-09 | 2.26025764343413e-05 |
|
||||
| 6 | 1024 | 6.337324016514285e-16 | 8.09060164312957e-11 | 4.517408062903668e-07 |
|
||||
{{< /table >}}
|
||||
|
||||
### FlowSchema
|
||||
|
||||
@@ -291,7 +292,7 @@ enabled has two extra headers: `X-Kubernetes-PF-FlowSchema-UID` and
|
||||
`X-Kubernetes-PF-PriorityLevel-UID`, noting the flow schema that matched the request
|
||||
and the priority level to which it was assigned, respectively. The API objects'
|
||||
names are not included in these headers in case the requesting user does not
|
||||
have permission to view them, so when debugging you can use a command like
|
||||
have permission to view them, so when debugging you can use a command like
|
||||
|
||||
```shell
|
||||
kubectl get flowschemas -o custom-columns="uid:{metadata.uid},name:{metadata.name}"
|
||||
@@ -363,7 +364,7 @@ poorly-behaved workloads that may be harming system health.
|
||||
* `apiserver_flowcontrol_request_execution_seconds` gives a histogram of how
|
||||
long requests took to actually execute, grouped by the FlowSchema that matched the
|
||||
request and the PriorityLevel to which it was assigned.
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -374,4 +375,4 @@ the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/maste
|
||||
You can make suggestions and feature requests via [SIG API
|
||||
Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
|
||||
|
||||
{{% /capture %}}
|
||||
{{% /capture %}}
|
||||
@@ -262,6 +262,10 @@ Lars Kellogg-Stedman.
|
||||
|
||||
Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [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)) that implement the CNI specification and 3rd party plugins (eg. [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)). In addition to it, Multus supports [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) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes.
|
||||
|
||||
### OVN4NFV-K8s-Plugin (OVN based CNI controller & plugin)
|
||||
|
||||
[OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking
|
||||
|
||||
### NSX-T
|
||||
|
||||
[VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) is a network virtualization and security platform. NSX-T can provide network virtualization for a multi-cloud and multi-hypervisor environment and is focused on emerging application frameworks and architectures that have heterogeneous endpoints and technology stacks. In addition to vSphere hypervisors, these environments include other hypervisors such as KVM, containers, and bare metal.
|
||||
|
||||
@@ -59,8 +59,7 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN
|
||||
|
||||
- Avoid using `hostNetwork`, for the same reasons as `hostPort`.
|
||||
|
||||
- Use [headless Services](/docs/concepts/services-networking/service/#headless-
|
||||
services) (which have a `ClusterIP` of `None`) for easy service discovery when you don't need `kube-proxy` load balancing.
|
||||
- Use [headless Services](/docs/concepts/services-networking/service/#headless-services) (which have a `ClusterIP` of `None`) for easy service discovery when you don't need `kube-proxy` load balancing.
|
||||
|
||||
## Using Labels
|
||||
|
||||
|
||||
@@ -81,6 +81,12 @@ The output is similar to:
|
||||
secret "db-user-pass" created
|
||||
```
|
||||
|
||||
Default key name is the filename. You may optionally set the key name using `[--from-file=[key=]source]`.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic db-user-pass --from-file=username=./username.txt --from-file=password=./password.txt
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Special characters such as `$`, `\`, `*`, `=`, and `!` will be interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing)) and require escaping.
|
||||
In most shells, the easiest way to escape the password is to surround it with single quotes (`'`).
|
||||
|
||||
@@ -9,9 +9,9 @@ weight: 1
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Containers are a technnology for packaging the (compiled) code for an
|
||||
Containers are a technology for packaging the (compiled) code for an
|
||||
application along with the dependencies it needs at run time. Each
|
||||
container that you run is repeatable; the standardisation from having
|
||||
container that you run is repeatable; the standardization from having
|
||||
dependencies included means that you get the same behavior wherever you
|
||||
run it.
|
||||
|
||||
|
||||
@@ -163,7 +163,7 @@ with the pod's tolerations in admission, effectively taking the union of the set
|
||||
by each.
|
||||
|
||||
To learn more about configuring the node selector and tolerations, see [Assigning Pods to
|
||||
Nodes](/docs/concepts/configuration/assign-pod-node/).
|
||||
Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/).
|
||||
|
||||
[RuntimeClass admission controller]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass
|
||||
|
||||
|
||||
@@ -106,7 +106,7 @@ as well as keeping the existing service in good shape.
|
||||
## Writing your own Operator {#writing-operator}
|
||||
|
||||
If there isn't an Operator in the ecosystem that implements the behavior you
|
||||
want, you can code your own. In [What's next](#what-s-next) you'll find a few
|
||||
want, you can code your own. In [What's next](#whats-next) you'll find a few
|
||||
links to libraries and tools you can use to write your own cloud native
|
||||
Operator.
|
||||
|
||||
@@ -129,4 +129,4 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
|
||||
* Read [CoreOS' original article](https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern
|
||||
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
|
||||
|
||||
{{% /capture %}}
|
||||
{{% /capture %}}
|
||||
@@ -86,7 +86,7 @@ Node components run on every node, maintaining running pods and providing the Ku
|
||||
|
||||
{{< glossary_definition term_id="kube-proxy" length="all" >}}
|
||||
|
||||
### Container Runtime
|
||||
### Container runtime
|
||||
|
||||
{{< glossary_definition term_id="container-runtime" length="all" >}}
|
||||
|
||||
|
||||
@@ -226,6 +226,6 @@ selector:
|
||||
#### Selecting sets of nodes
|
||||
|
||||
One use case for selecting over labels is to constrain the set of nodes onto which a pod can schedule.
|
||||
See the documentation on [node selection](/docs/concepts/configuration/assign-pod-node/) for more information.
|
||||
See the documentation on [node selection](/docs/concepts/scheduling-eviction/assign-pod-node/) for more information.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -494,7 +494,8 @@ kubectl create quota test --hard=count/deployments.extensions=2,count/replicaset
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl run nginx --image=nginx --replicas=2 --namespace=myspace
|
||||
kubectl create deployment nginx --image=nginx --namespace=myspace
|
||||
kubectl scale deployment nginx --replicas=2 --namespace=myspace
|
||||
```
|
||||
|
||||
```shell
|
||||
|
||||
+7
-6
@@ -155,7 +155,7 @@ value is `another-node-label-value` should be preferred.
|
||||
|
||||
You can see the operator `In` being used in the example. The new node affinity syntax supports the following operators: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`.
|
||||
You can use `NotIn` and `DoesNotExist` to achieve node anti-affinity behavior, or use
|
||||
[node taints](/docs/concepts/configuration/taint-and-toleration/) to repel pods from specific nodes.
|
||||
[node taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) to repel pods from specific nodes.
|
||||
|
||||
If you specify both `nodeSelector` and `nodeAffinity`, *both* must be satisfied for the pod
|
||||
to be scheduled onto a candidate node.
|
||||
@@ -226,10 +226,11 @@ The legal operators for pod affinity and anti-affinity are `In`, `NotIn`, `Exist
|
||||
In principle, the `topologyKey` can be any legal label-key. However,
|
||||
for performance and security reasons, there are some constraints on topologyKey:
|
||||
|
||||
1. For affinity and for `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity,
|
||||
empty `topologyKey` is not allowed.
|
||||
2. For `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, the admission controller `LimitPodHardAntiAffinityTopology` was introduced to limit `topologyKey` to `kubernetes.io/hostname`. If you want to make it available for custom topologies, you may modify the admission controller, or simply disable it.
|
||||
3. For `preferredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, empty `topologyKey` is not allowed.
|
||||
1. For pod affinity, empty `topologyKey` is not allowed in both `requiredDuringSchedulingIgnoredDuringExecution`
|
||||
and `preferredDuringSchedulingIgnoredDuringExecution`.
|
||||
2. For pod anti-affinity, empty `topologyKey` is also not allowed in both `requiredDuringSchedulingIgnoredDuringExecution`
|
||||
and `preferredDuringSchedulingIgnoredDuringExecution`.
|
||||
3. For `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, the admission controller `LimitPodHardAntiAffinityTopology` was introduced to limit `topologyKey` to `kubernetes.io/hostname`. If you want to make it available for custom topologies, you may modify the admission controller, or simply disable it.
|
||||
4. Except for the above cases, the `topologyKey` can be any legal label-key.
|
||||
|
||||
In addition to `labelSelector` and `topologyKey`, you can optionally specify a list `namespaces`
|
||||
@@ -391,7 +392,7 @@ The above pod will run on the node kube-01.
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
[Taints](/docs/concepts/configuration/taint-and-toleration/) allow a Node to *repel* a set of Pods.
|
||||
[Taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) allow a Node to *repel* a set of Pods.
|
||||
|
||||
The design documents for
|
||||
[node affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Kubernetes Scheduler
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
@@ -157,13 +157,13 @@ the three things:
|
||||
1. **wait** (with a timeout) \
|
||||
If a Permit plugin returns "wait", then the Pod is kept in an internal "waiting"
|
||||
Pods list, and the binding cycle of this Pod starts but directly blocks until it
|
||||
gets [approved](#frameworkhandle). If a timeout occurs, **wait** becomes **deny**
|
||||
gets approved. If a timeout occurs, **wait** becomes **deny**
|
||||
and the Pod is returned to the scheduling queue, triggering [Unreserve](#unreserve)
|
||||
plugins.
|
||||
|
||||
{{< note >}}
|
||||
While any plugin can access the list of "waiting" Pods and approve them
|
||||
(see [`FrameworkHandle`](#frameworkhandle)), we expect only the permit
|
||||
(see [`FrameworkHandle`](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md#frameworkhandle)), we expect only the permit
|
||||
plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod
|
||||
is approved, it is sent to the [PreBind](#pre-bind) phase.
|
||||
{{< /note >}}
|
||||
@@ -239,4 +239,4 @@ If you are using Kubernetes v1.18 or later, you can configure a set of plugins a
|
||||
a scheduler profile and then define multiple profiles to fit various kinds of workload.
|
||||
Learn more at [multiple profiles](/docs/reference/scheduling/profiles/#multiple-profiles).
|
||||
|
||||
{{% /capture %}}
|
||||
{{% /capture %}}
|
||||
+38
-38
@@ -10,16 +10,17 @@ weight: 40
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity),
|
||||
is a property of *pods* that *attracts* them to a set of nodes (either as a
|
||||
preference or a hard requirement). Taints are the opposite -- they allow a
|
||||
*node* to *repel* a set of pods.
|
||||
[_Node affinity_](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity),
|
||||
is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attracts* them to
|
||||
a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a
|
||||
hard requirement). _Taints_ are the opposite -- they allow a node to repel a set of pods.
|
||||
|
||||
_Tolerations_ are applied to pods, and allow (but do not require) the pods to schedule
|
||||
onto nodes with matching taints.
|
||||
|
||||
Taints and tolerations work together to ensure that pods are not scheduled
|
||||
onto inappropriate nodes. One or more taints are applied to a node; this
|
||||
marks that the node should not accept any pods that do not tolerate the taints.
|
||||
Tolerations are applied to pods, and allow (but do not require) the pods to schedule
|
||||
onto nodes with matching taints.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -65,12 +66,12 @@ Here’s an example of a pod that uses tolerations:
|
||||
|
||||
{{< codenew file="pods/pod-with-toleration.yaml" >}}
|
||||
|
||||
The default value for `operator` is `Equal`.
|
||||
|
||||
A toleration "matches" a taint if the keys are the same and the effects are the same, and:
|
||||
|
||||
* the `operator` is `Exists` (in which case no `value` should be specified), or
|
||||
* the `operator` is `Equal` and the `value`s are equal
|
||||
|
||||
`Operator` defaults to `Equal` if not specified.
|
||||
* the `operator` is `Equal` and the `value`s are equal.
|
||||
|
||||
{{< note >}}
|
||||
|
||||
@@ -204,7 +205,7 @@ when there are node problems, which is described in the next section.
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
|
||||
|
||||
Earlier we mentioned the `NoExecute` taint effect, which affects pods that are already
|
||||
The `NoExecute` taint effect, mentioned above, affects pods that are already
|
||||
running on the node as follows
|
||||
|
||||
* pods that do not tolerate the taint are evicted immediately
|
||||
@@ -213,9 +214,8 @@ running on the node as follows
|
||||
* pods that tolerate the taint with a specified `tolerationSeconds` remain
|
||||
bound for the specified amount of time
|
||||
|
||||
In addition, Kubernetes 1.6 introduced alpha support for representing node
|
||||
problems. In other words, the node controller automatically taints a node when
|
||||
certain condition is true. The following taints are built in:
|
||||
The node controller automatically taints a Node when certain conditions
|
||||
are true. The following taints are built in:
|
||||
|
||||
* `node.kubernetes.io/not-ready`: Node is not ready. This corresponds to
|
||||
the NodeCondition `Ready` being "`False`".
|
||||
@@ -236,19 +236,18 @@ with `NoExecute` effect. If the fault condition returns to normal the kubelet or
|
||||
controller can remove the relevant taint(s).
|
||||
|
||||
{{< note >}}
|
||||
To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/)
|
||||
behavior of pod evictions due to node problems, the system actually adds the taints
|
||||
in a rate-limited way. This prevents massive pod evictions in scenarios such
|
||||
as the master becoming partitioned from the nodes.
|
||||
The control plane limits the rate of adding node new taints to nodes. This rate limiting
|
||||
manages the number of evictions that are triggered when many nodes become unreachable at
|
||||
once (for example: if there is a network disruption).
|
||||
{{< /note >}}
|
||||
|
||||
The feature, in combination with `tolerationSeconds`, allows a pod
|
||||
to specify how long it should stay bound to a node that has one or both of these problems.
|
||||
You can specify `tolerationSeconds` for a Pod to define how long that Pod stays bound
|
||||
to a failing or unresponsive Node.
|
||||
|
||||
For example, an application with a lot of local state might want to stay
|
||||
bound to node for a long time in the event of network partition, in the hope
|
||||
For example, you might want to keep an application with a lot of local state
|
||||
bound to node for a long time in the event of network partition, hoping
|
||||
that the partition will recover and thus the pod eviction can be avoided.
|
||||
The toleration the pod would use in that case would look like
|
||||
The toleration you set for that Pod might look like:
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
@@ -258,20 +257,15 @@ tolerations:
|
||||
tolerationSeconds: 6000
|
||||
```
|
||||
|
||||
Note that Kubernetes automatically adds a toleration for
|
||||
`node.kubernetes.io/not-ready` with `tolerationSeconds=300`
|
||||
unless the pod configuration provided
|
||||
by the user already has a toleration for `node.kubernetes.io/not-ready`.
|
||||
Likewise it adds a toleration for
|
||||
`node.kubernetes.io/unreachable` with `tolerationSeconds=300`
|
||||
unless the pod configuration provided
|
||||
by the user already has a toleration for `node.kubernetes.io/unreachable`.
|
||||
{{< note >}}
|
||||
Kubernetes automatically adds a toleration for
|
||||
`node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable`
|
||||
with `tolerationSeconds=300`,
|
||||
unless you, or a controller, set those tolerations explictly.
|
||||
|
||||
These automatically-added tolerations ensure that
|
||||
the default pod behavior of remaining bound for 5 minutes after one of these
|
||||
problems is detected is maintained.
|
||||
The two default tolerations are added by the [DefaultTolerationSeconds
|
||||
admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds).
|
||||
These automatically-added tolerations mean that Pods remain bound to
|
||||
Nodes for 5 minutes after one of these problems is detected.
|
||||
{{< /note >}}
|
||||
|
||||
[DaemonSet](/docs/concepts/workloads/controllers/daemonset/) pods are created with
|
||||
`NoExecute` tolerations for the following taints with no `tolerationSeconds`:
|
||||
@@ -287,9 +281,8 @@ The node lifecycle controller automatically creates taints corresponding to
|
||||
Node conditions with `NoSchedule` effect.
|
||||
Similarly the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations.
|
||||
|
||||
Starting in Kubernetes 1.8, the DaemonSet controller automatically adds the
|
||||
following `NoSchedule` tolerations to all daemons, to prevent DaemonSets from
|
||||
breaking.
|
||||
The DaemonSet controller automatically adds the following `NoSchedule`
|
||||
tolerations to all daemons, to prevent DaemonSets from breaking.
|
||||
|
||||
* `node.kubernetes.io/memory-pressure`
|
||||
* `node.kubernetes.io/disk-pressure`
|
||||
@@ -299,3 +292,10 @@ breaking.
|
||||
|
||||
Adding these tolerations ensures backward compatibility. You can also add
|
||||
arbitrary tolerations to DaemonSets.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
* Read about [out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) and how you can configure it
|
||||
* Read about [pod priority](/docs/concepts/configuration/pod-priority-preemption/)
|
||||
|
||||
{{% /capture %}}
|
||||
+1
-1
@@ -93,7 +93,7 @@ hostaliases-pod 0/1 Completed 0 6s 10.200
|
||||
The `hosts` file content would look like this:
|
||||
|
||||
```shell
|
||||
kubectl logs hostaliases-pod
|
||||
kubectl exec hostaliases-pod -- cat /etc/hosts
|
||||
```
|
||||
|
||||
```none
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user