@@ -0,0 +1,3 @@
|
||||
[submodule "themes/docsy"]
|
||||
path = themes/docsy
|
||||
url = https://github.com/google/docsy.git
|
||||
@@ -1,9 +1,16 @@
|
||||
DOCKER = docker
|
||||
HUGO_VERSION = $(shell grep ^HUGO_VERSION netlify.toml | tail -n 1 | cut -d '=' -f 2 | tr -d " \"\n")
|
||||
DOCKER_IMAGE = kubernetes-hugo
|
||||
DOCKER_RUN = $(DOCKER) run --rm --interactive --tty --volume $(CURDIR):/src
|
||||
NODE_BIN = node_modules/.bin
|
||||
NETLIFY_FUNC = $(NODE_BIN)/netlify-lambda
|
||||
HUGO_VERSION = $(shell grep ^HUGO_VERSION netlify.toml | tail -n 1 | cut -d '=' -f 2 | tr -d " \"\n")
|
||||
NODE_BIN = node_modules/.bin
|
||||
NETLIFY_FUNC = $(NODE_BIN)/netlify-lambda
|
||||
|
||||
# The CONTAINER_ENGINE variable is used for specifying the container engine. By default 'docker' is used
|
||||
# but this can be overridden when calling make, e.g.
|
||||
# CONTAINER_ENGINE=podman make container-image
|
||||
CONTAINER_ENGINE ?= docker
|
||||
CONTAINER_IMAGE = kubernetes-hugo
|
||||
CONTAINER_RUN = $(CONTAINER_ENGINE) run --rm --interactive --tty --volume $(CURDIR):/src
|
||||
|
||||
CCRED=\033[0;31m
|
||||
CCEND=\033[0m
|
||||
|
||||
.PHONY: all build build-preview help serve
|
||||
|
||||
@@ -36,16 +43,28 @@ serve: ## Boot the development server.
|
||||
hugo server --buildFuture
|
||||
|
||||
docker-image:
|
||||
$(DOCKER) build . \
|
||||
--network=host \
|
||||
--tag $(DOCKER_IMAGE) \
|
||||
--build-arg HUGO_VERSION=$(HUGO_VERSION)
|
||||
@echo -e "$(CCRED)**** The use of docker-image is deprecated. Use container-image instead. ****$(CCEND)"
|
||||
$(MAKE) container-image
|
||||
|
||||
docker-build:
|
||||
$(DOCKER_RUN) $(DOCKER_IMAGE) hugo
|
||||
@echo -e "$(CCRED)**** The use of docker-build is deprecated. Use container-build instead. ****$(CCEND)"
|
||||
$(MAKE) container-build
|
||||
|
||||
docker-serve:
|
||||
$(DOCKER_RUN) --mount type=tmpfs,destination=/src/resources,tmpfs-mode=0755 -p 1313:1313 $(DOCKER_IMAGE) hugo server --buildFuture --bind 0.0.0.0
|
||||
@echo -e "$(CCRED)**** The use of docker-serve is deprecated. Use container-serve instead. ****$(CCEND)"
|
||||
$(MAKE) container-serve
|
||||
|
||||
container-image:
|
||||
$(CONTAINER_ENGINE) build . \
|
||||
--network=host \
|
||||
--tag $(CONTAINER_IMAGE) \
|
||||
--build-arg HUGO_VERSION=$(HUGO_VERSION)
|
||||
|
||||
container-build:
|
||||
$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo
|
||||
|
||||
container-serve:
|
||||
$(CONTAINER_RUN) --mount type=tmpfs,destination=/src/resources,tmpfs-mode=0755 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0
|
||||
|
||||
test-examples:
|
||||
scripts/test_examples.sh install
|
||||
@@ -53,8 +72,13 @@ test-examples:
|
||||
|
||||
.PHONY: link-checker-setup
|
||||
link-checker-image-pull:
|
||||
docker pull wjdp/htmltest
|
||||
$(CONTAINER_ENGINE) pull wjdp/htmltest
|
||||
|
||||
docker-internal-linkcheck:
|
||||
@echo -e "$(CCRED)**** The use of docker-internal-linkcheck is deprecated. Use container-internal-linkcheck instead. ****$(CCEND)"
|
||||
$(MAKE) container-internal-linkcheck
|
||||
|
||||
container-internal-linkcheck: link-checker-image-pull
|
||||
$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture
|
||||
$(CONTAINER_ENGINE) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest
|
||||
|
||||
docker-internal-linkcheck: link-checker-image-pull
|
||||
$(DOCKER_RUN) $(DOCKER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture
|
||||
$(DOCKER) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest
|
||||
+6
-3
@@ -124,6 +124,7 @@ aliases:
|
||||
- girikuncoro
|
||||
- irvifa
|
||||
- wahyuoi
|
||||
- phanama
|
||||
sig-docs-it-owners: # Admins for Italian content
|
||||
- fabriziopandini
|
||||
- mattiaperi
|
||||
@@ -133,14 +134,15 @@ aliases:
|
||||
- mattiaperi
|
||||
- micheleberardi
|
||||
sig-docs-ja-owners: # Admins for Japanese content
|
||||
- cstoku
|
||||
# cstoku
|
||||
- inductor
|
||||
- nasa9084
|
||||
sig-docs-ja-reviews: # PR reviews for Japanese content
|
||||
- cstoku
|
||||
- bells17
|
||||
# cstoku
|
||||
- inductor
|
||||
- makocchi-git
|
||||
- MasayaAoyama
|
||||
# MasayaAoyama
|
||||
- nasa9084
|
||||
- oke-py
|
||||
sig-docs-ko-owners: # Admins for Korean content
|
||||
@@ -227,6 +229,7 @@ aliases:
|
||||
- MaxymVlasov
|
||||
sig-docs-uk-reviews: # PR reviews for Ukrainian content
|
||||
- anastyakulyk
|
||||
- Arhell
|
||||
- butuzov
|
||||
- idvoretskyi
|
||||
- MaxymVlasov
|
||||
|
||||
+1
-1
@@ -15,7 +15,7 @@ Weitere Informationen zum Beitrag zur Kubernetes-Dokumentation finden Sie unter:
|
||||
|
||||
* [Mitwirkung beginnen](https://kubernetes.io/docs/contribute/start/)
|
||||
* [Ihre Dokumentationsänderungen bereitstellen](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
|
||||
* [Seitenvorlagen verwenden](http://kubernetes.io/docs/contribute/style/page-templates/)
|
||||
* [Seitenvorlagen verwenden](http://kubernetes.io/docs/contribute/style/page-content-types/)
|
||||
* [Dokumentationsstil-Handbuch](http://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Übersetzung der Kubernetes-Dokumentation](https://kubernetes.io/docs/contribute/localization/)
|
||||
|
||||
|
||||
+1
-1
@@ -18,7 +18,7 @@ Para obtener más información sobre cómo contribuir a la documentación de Kub
|
||||
|
||||
* [Empezando a contribuir](https://kubernetes.io/docs/contribute/start/)
|
||||
* [Visualizando sus cambios en su entorno local](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
|
||||
* [Utilizando las plantillas de las páginas](http://kubernetes.io/docs/contribute/style/page-templates/)
|
||||
* [Utilizando las plantillas de las páginas](http://kubernetes.io/docs/contribute/style/page-content-types/)
|
||||
* [Guía de estilo de la documentación](http://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Traduciendo la documentación de Kubernetes](https://kubernetes.io/docs/contribute/localization/)
|
||||
|
||||
|
||||
+1
-1
@@ -23,7 +23,7 @@ Pour plus d'informations sur la contribution à la documentation Kubernetes, voi
|
||||
|
||||
* [Commencez à contribuer](https://kubernetes.io/docs/contribute/start/)
|
||||
* [Apperçu des modifications apportées à votre documentation](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
|
||||
* [Utilisation des modèles de page](http://kubernetes.io/docs/contribute/style/page-templates/)
|
||||
* [Utilisation des modèles de page](https://kubernetes.io/docs/contribute/style/page-content-types/)
|
||||
* [Documentation Style Guide](http://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Traduction de la documentation Kubernetes](https://kubernetes.io/docs/contribute/localization/)
|
||||
|
||||
|
||||
+40
-48
@@ -3,7 +3,31 @@
|
||||
[](https://travis-ci.org/kubernetes/website)
|
||||
[](https://github.com/kubernetes/website/releases/latest)
|
||||
|
||||
ようこそ!このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます!
|
||||
このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます!
|
||||
|
||||
## Hugoを使ってローカル環境でWebサイトを動かす
|
||||
|
||||
Hugoのインストール方法については[Hugoの公式ドキュメント](https://gohugo.io/getting-started/installing/)をご覧ください。このとき、[`netlify.toml`](netlify.toml#L10)ファイルに記述されている`HUGO_VERSION`と同じバージョンをインストールするようにしてください。
|
||||
|
||||
Hugoがインストールできたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/kubernetes/website.git
|
||||
cd website
|
||||
git submodule update --init --recursive
|
||||
hugo server --buildFuture
|
||||
```
|
||||
|
||||
これで、Hugoのサーバーが1313番ポートを使って開始します。お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。
|
||||
|
||||
## SIG Docsに参加する
|
||||
|
||||
[コミュニティのページ](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)をご覧になることで、SIG Docs Kubernetesコミュニティとの関わり方を学ぶことができます。
|
||||
|
||||
本プロジェクトのメンテナーには以下の方法で連絡することができます:
|
||||
|
||||
- [Slack](https://kubernetes.slack.com/messages/kubernetes-docs-ja)
|
||||
- [メーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
|
||||
|
||||
## ドキュメントに貢献する
|
||||
|
||||
@@ -12,63 +36,31 @@ GitHubの画面右上にある**Fork**ボタンをクリックすると、お使
|
||||
Pull Requestが作成されると、レビュー担当者が責任を持って明確かつ実用的なフィードバックを返します。
|
||||
Pull Requestの所有者は作成者であるため、**ご自身で作成したPull Requestを編集し、フィードバックに対応するのはご自身の役目です。**
|
||||
また、状況によっては2人以上のレビュアーからフィードバックが返されたり、アサインされていないレビュー担当者からのフィードバックが来ることがある点もご注意ください。
|
||||
さらに、特定のケースにおいては、レビュー担当者が[Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers)に対してレビューを依頼することもあります。
|
||||
さらに、特定のケースにおいては、レビュー担当者がKubernetesの技術的なレビュアーに対してレビューを依頼することもあります。
|
||||
レビュー担当者はタイムリーにフィードバックを提供するために最善を尽くしますが、応答時間は状況に応じて異なる場合があります。
|
||||
|
||||
Kubernetesのドキュメントへの貢献に関する詳細については以下のページをご覧ください:
|
||||
|
||||
* [貢献のはじめ方](https://kubernetes.io/docs/contribute/start/)
|
||||
* [ドキュメントの変更をステージする](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
|
||||
* [ページテンプレートの使い方](http://kubernetes.io/docs/contribute/style/page-templates/)
|
||||
* [ドキュメントのスタイルガイド](http://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Kubernetesのドキュメントへの貢献](https://kubernetes.io/ja/docs/contribute/)
|
||||
* [ページコンテントタイプ](https://kubernetes.io/docs/contribute/style/page-content-types/)
|
||||
* [ドキュメントのスタイルガイド](https://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Kubernetesドキュメントの翻訳方法](https://kubernetes.io/docs/contribute/localization/)
|
||||
|
||||
## Dockerを使ってローカル環境でWebサイトを動かす
|
||||
## 翻訳された`README.md`一覧
|
||||
|
||||
ローカル環境で本ページを動かすのに推奨される方法は、静的サイトジェネレータの[Hugo](https://gohugo.io)を動かすのに特化した[Docker](https://docker.com)イメージを使うことです。
|
||||
|
||||
> Windows上で環境を作る場合は[Chocolatey](https://chocolatey.org)を使ってインストール可能な追加のツールが必要になります。 `choco install make`
|
||||
|
||||
> Dockerを使わずに環境を構築したい場合は、[Hugoをローカル環境で動かす](#hugoをローカル環境で動かす)をご覧ください。
|
||||
|
||||
既に[Dockerが動いている環境](https://www.docker.com/get-started)であれば、以下のコマンドを使って`kubernetes-hugo`イメージをローカルでビルドします:
|
||||
|
||||
```bash
|
||||
make docker-image
|
||||
```
|
||||
|
||||
イメージが作成されたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます:
|
||||
|
||||
```bash
|
||||
make docker-serve
|
||||
```
|
||||
|
||||
お使いのブラウザにて http://localhost:1313 にアクセスすることでWebサイトが開きます。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。
|
||||
|
||||
## Hugoをローカル環境で動かす
|
||||
|
||||
Hugoのインストール方法については[Hugoの公式ドキュメント](https://gohugo.io/getting-started/installing/)をご覧ください。このとき、[`netlify.toml`](netlify.toml#L9)ファイルに記述されている`HUGO_VERSION`と同じバージョンをインストールするようにしてください。
|
||||
|
||||
Hugoがインストールできたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます:
|
||||
|
||||
```bash
|
||||
make serve
|
||||
```
|
||||
|
||||
これで、Hugoのサーバーが1313番ポートを使って開始します。 お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。
|
||||
|
||||
## コミュニティ内での議論、貢献、サポートなどについて
|
||||
|
||||
[コミュニティのページ](http://kubernetes.io/community/)をご覧になることで、Kubernetesコミュニティとの関わり方を学ぶことができます。
|
||||
|
||||
本プロジェクトのメンテナーには以下の方法で連絡することができます:
|
||||
|
||||
- [Slack](https://kubernetes.slack.com/messages/kubernetes-docs-ja)
|
||||
- [メーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
|
||||
| Language | Language |
|
||||
|---|---|
|
||||
|[中国語](README-zh.md)|[韓国語](README-ko.md)|
|
||||
|[フランス語](README-fr.md)|[ポーランド語](README-pl.md)|
|
||||
|[ドイツ語](README-de.md)|[ポルトガル語](README-pt.md)|
|
||||
|[ヒンディー語](README-hi.md)|[ロシア語](README-ru.md)|
|
||||
|[インドネシア語](README-id.md)|[スペイン語](README-es.md)|
|
||||
|[イタリア語](README-it.md)|[ウクライナ語](README-uk.md)|
|
||||
|[日本語](README-ja.md)|[ベトナム語](README-vi.md)|
|
||||
|
||||
### 行動規範
|
||||
|
||||
Kubernetesコミュニティへの参加については、[Kubernetesの行動規範](code-of-conduct.md)によって管理されています。
|
||||
Kubernetesコミュニティへの参加については、[CNCFの行動規範](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)によって管理されています。
|
||||
|
||||
## ありがとうございます!
|
||||
|
||||
|
||||
@@ -13,6 +13,7 @@ To run the website locally when you have Hugo installed:
|
||||
```bash
|
||||
git clone https://github.com/kubernetes/website.git
|
||||
cd website
|
||||
git submodule update --init --recursive
|
||||
hugo server --buildFuture
|
||||
```
|
||||
|
||||
@@ -40,7 +41,7 @@ Furthermore, in some cases, one of your reviewers might ask for a technical revi
|
||||
For more information about contributing to the Kubernetes documentation, see:
|
||||
|
||||
* [Contribute to Kubernetes docs](https://kubernetes.io/docs/contribute/)
|
||||
* [Using Page Templates](https://kubernetes.io/docs/contribute/style/page-templates/)
|
||||
* [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/)
|
||||
* [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
|
||||
|
||||
|
||||
@@ -0,0 +1,110 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 21.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
|
||||
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
|
||||
viewBox="0 0 503.1 89.5" style="enable-background:new 0 0 503.1 89.5;" xml:space="preserve">
|
||||
<style type="text/css">
|
||||
.st0{fill:#FFFFFF;stroke:#FFFFFF;stroke-width:5;stroke-miterlimit:10;}
|
||||
.st1{fill:#326DE6;}
|
||||
.st2{fill:#FFFFFF;}
|
||||
</style>
|
||||
<title>Kubernetes_Logo_Hrz_lockup_REV</title>
|
||||
<g id="Layer_2">
|
||||
<g id="Layer_1-2">
|
||||
<path class="st0" d="M82.3,21.3c-0.5-1.6-1.7-2.9-3.2-3.7L48.6,3c-0.8-0.4-1.7-0.5-2.5-0.5c-0.8,0-1.7,0-2.5,0.2L13.1,17.4
|
||||
c-1.5,0.7-2.6,2-3,3.7L2.6,54c-0.3,1.7,0.1,3.4,1.1,4.8l21.1,26.1c1.2,1.2,2.9,2,4.6,2.1H63c1.8,0.2,3.5-0.6,4.6-2.1l21.1-26.1
|
||||
c1-1.4,1.4-3.1,1.2-4.8L82.3,21.3z"/>
|
||||
<path class="st1" d="M82.3,21.3c-0.5-1.6-1.7-2.9-3.2-3.7L48.6,3c-0.8-0.4-1.7-0.5-2.5-0.5c-0.8,0-1.7,0-2.5,0.2L13.1,17.4
|
||||
c-1.5,0.7-2.6,2-3,3.7L2.6,54c-0.3,1.7,0.1,3.4,1.1,4.8l21.1,26.1c1.2,1.2,2.9,2,4.6,2.1H63c1.8,0.2,3.5-0.6,4.6-2.1l21.1-26.1
|
||||
c1-1.4,1.4-3.1,1.2-4.8L82.3,21.3z"/>
|
||||
<path class="st2" d="M77.6,52.7L77.6,52.7c-0.1,0-0.2,0-0.2-0.1s-0.2-0.1-0.4-0.1c-0.4-0.1-0.8-0.1-1.2-0.1c-0.2,0-0.4,0-0.6-0.1
|
||||
h-0.1c-1.1-0.1-2.3-0.3-3.4-0.6c-0.3-0.1-0.6-0.4-0.7-0.7C71.1,51,71,51,71,51l0,0l-0.8-0.2c0.4-2.9,0.2-5.9-0.4-8.8
|
||||
c-0.7-2.9-1.9-5.7-3.5-8.2l0.6-0.6l0,0v-0.1c0-0.3,0.1-0.7,0.3-0.9c0.9-0.8,1.8-1.4,2.8-2l0,0c0.2-0.1,0.4-0.2,0.6-0.3
|
||||
c0.4-0.2,0.7-0.4,1.1-0.6c0.1-0.1,0.2-0.1,0.3-0.2S72,29,72,28.9l0,0c0.9-0.7,1.1-1.9,0.4-2.8c-0.3-0.4-0.9-0.7-1.4-0.7
|
||||
c-0.5,0-1,0.2-1.4,0.5l0,0l-0.1,0.1c-0.1,0.1-0.2,0.2-0.3,0.2c-0.3,0.3-0.6,0.6-0.8,0.9c-0.1,0.2-0.3,0.3-0.4,0.4l0,0
|
||||
c-0.7,0.8-1.6,1.6-2.5,2.2c-0.2,0.1-0.4,0.2-0.6,0.2c-0.1,0-0.3,0-0.4-0.1h-0.1l-0.8,0.5c-0.8-0.8-1.7-1.6-2.5-2.4
|
||||
c-3.7-2.9-8.3-4.7-13-5.2l-0.1-0.8l0,0L48,22c-0.3-0.2-0.4-0.5-0.5-0.8c0-1.1,0-2.2,0.2-3.4v-0.1c0-0.2,0.1-0.4,0.1-0.6
|
||||
c0.1-0.4,0.1-0.8,0.2-1.2v-0.6l0,0c0.1-1-0.7-2-1.7-2.1c-0.6-0.1-1.2,0.2-1.7,0.7c-0.4,0.4-0.6,0.9-0.6,1.4l0,0v0.5
|
||||
c0,0.4,0.1,0.8,0.2,1.2c0.1,0.2,0.1,0.4,0.1,0.6v0.1c0.2,1.1,0.2,2.2,0.2,3.4c-0.1,0.3-0.2,0.6-0.5,0.8L44,22.1l0,0l-0.1,0.8
|
||||
c-1.1,0.1-2.2,0.3-3.4,0.5c-4.7,1-9,3.5-12.3,7L27.6,30h-0.1c-0.1,0-0.2,0.1-0.4,0.1c-0.2,0-0.4-0.1-0.6-0.2
|
||||
c-0.9-0.7-1.8-1.5-2.5-2.3l0,0c-0.1-0.2-0.3-0.3-0.4-0.4c-0.3-0.3-0.5-0.6-0.8-0.9c-0.1-0.1-0.2-0.1-0.3-0.2s-0.1-0.1-0.1-0.1l0,0
|
||||
c-0.4-0.3-0.9-0.5-1.4-0.5c-0.6,0-1.1,0.2-1.4,0.7c-0.6,0.9-0.4,2.1,0.4,2.8l0,0c0.1,0,0.1,0.1,0.1,0.1s0.2,0.2,0.3,0.2
|
||||
c0.3,0.2,0.7,0.4,1.1,0.6c0.2,0.1,0.4,0.2,0.6,0.3l0,0c1,0.6,2,1.2,2.8,2c0.2,0.2,0.4,0.6,0.3,0.9V33l0,0l0.6,0.6
|
||||
c-0.1,0.2-0.2,0.3-0.3,0.5C22.4,39,21.1,44.8,22,50.5l-0.8,0.2l0,0c0,0.1-0.1,0.1-0.1,0.1c-0.1,0.3-0.4,0.5-0.7,0.7
|
||||
c-1.1,0.3-2.2,0.5-3.4,0.6H17c-0.2,0-0.4,0-0.6,0.1c-0.4,0-0.8,0.1-1.2,0.1c-0.1,0-0.2,0.1-0.4,0.1c-0.1,0-0.1,0-0.2,0.1l0,0
|
||||
c-1.1,0.2-1.8,1.2-1.6,2.3c0,0,0,0,0,0c0.2,0.9,1.1,1.5,2,1.4c0.2,0,0.3,0,0.5-0.1l0,0c0.1,0,0.1,0,0.1-0.1S15.9,56,16,56
|
||||
c0.4-0.1,0.8-0.3,1.1-0.4c0.2-0.1,0.4-0.2,0.6-0.2h0.1c1.1-0.4,2.1-0.7,3.3-0.9h0.1c0.3,0,0.6,0.1,0.8,0.3c0.1,0,0.1,0.1,0.1,0.1
|
||||
l0,0l0.9-0.1c1.5,4.6,4.3,8.7,8.2,11.7c0.9,0.7,1.7,1.3,2.7,1.8L33.4,69l0,0c0,0.1,0.1,0.1,0.1,0.1c0.2,0.3,0.2,0.7,0.1,1
|
||||
c-0.4,1-1,2-1.6,2.9v0.1c-0.1,0.2-0.2,0.3-0.4,0.5s-0.4,0.6-0.7,1c-0.1,0.1-0.1,0.2-0.2,0.3c0,0,0,0.1-0.1,0.1l0,0
|
||||
c-0.5,1-0.1,2.2,0.8,2.7c0.2,0.1,0.5,0.2,0.7,0.2c0.8,0,1.5-0.5,1.9-1.2l0,0c0,0,0-0.1,0.1-0.1c0-0.1,0.1-0.2,0.2-0.3
|
||||
c0.1-0.4,0.3-0.7,0.4-1.1l0.2-0.6l0,0c0.3-1.1,0.8-2.1,1.3-3.1c0.2-0.3,0.5-0.5,0.8-0.6c0.1,0,0.1,0,0.1-0.1l0,0l0.4-0.8
|
||||
c2.8,1.1,5.7,1.6,8.7,1.6c1.8,0,3.6-0.2,5.4-0.7c1.1-0.2,2.2-0.6,3.2-0.9l0.4,0.7l0,0c0.1,0,0.1,0,0.1,0.1
|
||||
c0.3,0.1,0.6,0.3,0.8,0.6c0.5,1,1,2,1.3,3.1v0.1l0.2,0.6c0.1,0.4,0.2,0.8,0.4,1.1c0.1,0.1,0.1,0.2,0.2,0.3c0,0,0,0.1,0.1,0.1l0,0
|
||||
c0.4,0.7,1.1,1.2,1.9,1.2c0.3,0,0.5-0.1,0.8-0.2c0.4-0.2,0.8-0.6,0.9-1.1c0.1-0.5,0.1-1-0.1-1.5l0,0c0-0.1-0.1-0.1-0.1-0.1
|
||||
c0-0.1-0.1-0.2-0.2-0.3c-0.2-0.4-0.4-0.7-0.7-1c-0.1-0.2-0.2-0.3-0.4-0.5V73c-0.7-0.9-1.2-1.9-1.6-2.9c-0.1-0.3-0.1-0.7,0.1-1
|
||||
c0-0.1,0.1-0.1,0.1-0.1l0,0l-0.3-0.8c5.1-3.1,9-7.9,10.8-13.6l0.8,0.1l0,0c0.1,0,0.1-0.1,0.1-0.1c0.2-0.2,0.5-0.3,0.8-0.3h0.1
|
||||
c1.1,0.2,2.2,0.5,3.2,0.9h0.1c0.2,0.1,0.4,0.2,0.6,0.2c0.4,0.2,0.7,0.4,1.1,0.5c0.1,0,0.2,0.1,0.4,0.1c0.1,0,0.1,0,0.2,0.1l0,0
|
||||
c0.2,0.1,0.3,0.1,0.5,0.1c0.9,0,1.7-0.6,2-1.4C79.3,53.7,78.5,52.9,77.6,52.7z M48.7,49.6L46,50.9l-2.7-1.3l-0.7-2.9l1.9-2.4h3
|
||||
l1.9,2.4L48.7,49.6z M65,43.1c0.5,2.1,0.6,4.2,0.4,6.3l-9.5-2.7l0,0c-0.9-0.2-1.4-1.1-1.2-2c0.1-0.3,0.2-0.5,0.4-0.7l7.5-6.8
|
||||
C63.7,39,64.5,41,65,43.1z M59.6,33.5l-8.2,5.8c-0.7,0.4-1.7,0.3-2.2-0.4c-0.2-0.2-0.3-0.4-0.3-0.7l-0.6-10.1
|
||||
C52.7,28.6,56.6,30.5,59.6,33.5L59.6,33.5z M41.5,28.4l2-0.4L43,38l0,0c0,0.9-0.8,1.6-1.7,1.6c-0.3,0-0.5-0.1-0.8-0.2l-8.3-5.9
|
||||
C34.8,31,38,29.2,41.5,28.4z M29.3,37.2l7.4,6.6l0,0c0.7,0.6,0.8,1.6,0.2,2.3c-0.2,0.3-0.4,0.4-0.8,0.5l-9.7,2.8
|
||||
C26.1,45.2,27.1,40.9,29.3,37.2z M27.6,54.1l9.9-1.7c0.8,0,1.6,0.5,1.7,1.3c0.1,0.3,0.1,0.7-0.1,1l0,0l-3.8,9.2
|
||||
C31.8,61.6,29,58.1,27.6,54.1z M50.3,66.5C48.9,66.8,47.5,67,46,67c-2.1,0-4.3-0.4-6.3-1l4.9-8.9c0.5-0.6,1.3-0.8,2-0.4
|
||||
c0.3,0.2,0.5,0.4,0.8,0.7l0,0l4.8,8.7C51.6,66.2,51,66.3,50.3,66.5z M62.5,57.8c-1.5,2.4-3.6,4.5-6,6l-3.9-9.4
|
||||
c-0.2-0.8,0.2-1.6,0.9-1.9c0.3-0.1,0.6-0.2,0.9-0.2l10,1.7C63.9,55.4,63.3,56.7,62.5,57.8z"/>
|
||||
<g id="layer1">
|
||||
<g id="text4373">
|
||||
<path id="path2985" class="st2" d="M128.1,48.4c1.1-1.2,2.1-2.4,3.3-3.6c1.1-1.3,2.2-2.5,3.3-3.7c1.1-1.3,2.1-2.4,3-3.5
|
||||
s1.8-2.1,2.5-2.9H153c-2.6,2.9-5.1,5.8-7.5,8.5c-2.5,2.7-5.1,5.5-8,8.3c1.6,1.5,3.1,3,4.5,4.7c1.5,1.8,3,3.6,4.5,5.6
|
||||
c1.4,1.9,2.8,3.9,4,5.8c1.2,1.9,2.2,3.7,3,5.3h-12.4c-0.8-1.3-1.7-2.6-2.7-4.1s-2.1-3-3.1-4.6c-1.1-1.5-2.3-3-3.6-4.4
|
||||
c-1.1-1.3-2.3-2.5-3.6-3.5v16.7h-10.8V18.2l10.8-1.7L128.1,48.4"/>
|
||||
<path id="path2987" class="st2" d="M191.1,71.4c-2.3,0.6-4.7,1.1-7.1,1.4c-3,0.5-6.1,0.7-9.1,0.7c-2.8,0.1-5.5-0.4-8.1-1.3
|
||||
c-2-0.8-3.7-2-5.1-3.6c-1.3-1.7-2.2-3.6-2.7-5.7c-0.6-2.3-0.8-4.8-0.8-7.2V34.6H169v19.9c0,3.5,0.5,6,1.4,7.5s2.6,2.3,5.1,2.3
|
||||
c0.8,0,1.6,0,2.5-0.1s1.6-0.1,2.3-0.3V34.6h10.8L191.1,71.4"/>
|
||||
<path id="path2989" class="st2" d="M225.7,53.4c0-7-2.6-10.4-7.7-10.4c-1.1,0-2.2,0.1-3.3,0.4c-0.9,0.2-1.8,0.6-2.6,1.1v19.6
|
||||
c0.5,0.1,1.2,0.2,2,0.3c0.8,0.1,1.7,0.1,2.7,0.1c2.6,0.2,5.1-0.9,6.7-3C225,59.1,225.8,56.3,225.7,53.4 M236.7,53.8
|
||||
c0,2.8-0.4,5.6-1.4,8.3c-0.8,2.4-2.1,4.5-3.8,6.3c-1.8,1.8-3.9,3.2-6.2,4.1c-2.7,1-5.5,1.4-8.4,1.4c-1.3,0-2.7-0.1-4.1-0.2
|
||||
c-1.4-0.1-2.8-0.3-4.2-0.4c-1.3-0.2-2.6-0.4-3.9-0.7c-1.3-0.2-2.4-0.5-3.3-0.9V18.2l10.8-1.7v19c1.2-0.5,2.5-0.9,3.8-1.2
|
||||
c1.4-0.3,2.8-0.4,4.2-0.4c2.5,0,4.9,0.4,7.2,1.5c2,0.9,3.8,2.3,5.2,4c1.5,1.9,2.6,4,3.2,6.3C236.4,48.2,236.7,51,236.7,53.8"/>
|
||||
<path id="path2991" class="st2" d="M243.2,54c-0.1-3,0.5-6,1.5-8.8c0.9-2.4,2.3-4.5,4.1-6.4c1.7-1.7,3.6-3,5.8-3.8
|
||||
c2.2-0.9,4.5-1.3,6.8-1.3c5.4,0,9.7,1.7,12.8,5c3.1,3.3,4.7,8.2,4.7,14.5c0,0.6,0,1.3-0.1,2.1s-0.1,1.4-0.1,2h-24.5
|
||||
c0.2,2.1,1.3,4.1,3.1,5.3c2.2,1.4,4.8,2.1,7.4,2c1.9,0,3.9-0.2,5.8-0.5c1.6-0.3,3.2-0.8,4.7-1.4l1.5,8.8
|
||||
c-0.7,0.4-1.5,0.6-2.3,0.9c-1.1,0.3-2.2,0.6-3.3,0.7c-1.2,0.2-2.4,0.4-3.8,0.6c-1.3,0.1-2.7,0.2-4.1,0.2c-3.1,0.1-6.1-0.4-9-1.5
|
||||
c-2.4-0.9-4.5-2.3-6.3-4.1c-1.7-1.8-2.9-4-3.7-6.3C243.6,59.3,243.2,56.7,243.2,54 M268.6,49.9c0-0.9-0.2-1.8-0.5-2.7
|
||||
c-0.2-0.9-0.7-1.6-1.2-2.3c-0.6-0.7-1.3-1.3-2.1-1.7c-1-0.5-2-0.7-3.1-0.7c-1.1,0-2.1,0.2-3.1,0.7c-0.8,0.4-1.6,0.9-2.2,1.6
|
||||
c-0.6,0.7-1.1,1.5-1.4,2.4c-0.3,0.9-0.5,1.8-0.6,2.7L268.6,49.9"/>
|
||||
<path id="path2993" class="st2" d="M310.3,44.2c-1-0.2-2.1-0.5-3.4-0.7c-1.4-0.3-2.8-0.4-4.2-0.4c-0.8,0-1.6,0.1-2.5,0.2
|
||||
c-0.7,0.1-1.4,0.2-2.1,0.4v29.1h-10.8V36.6c2.2-0.8,4.5-1.4,6.8-1.9c2.9-0.7,5.9-1,8.8-0.9c0.7,0,1.4,0.1,2.1,0.1
|
||||
c0.8,0,1.6,0.1,2.5,0.3c0.8,0.1,1.6,0.2,2.5,0.4c0.7,0.1,1.4,0.3,2.1,0.6L310.3,44.2"/>
|
||||
<path id="path2995" class="st2" d="M317.9,35.9c2.3-0.6,4.7-1.1,7.1-1.5c3-0.5,6.1-0.7,9.1-0.7c2.7-0.1,5.4,0.4,8,1.3
|
||||
c2,0.7,3.8,1.9,5.1,3.5c1.3,1.6,2.2,3.5,2.7,5.5c0.6,2.3,0.8,4.7,0.8,7.1v21.5H340V52.5c0-3.5-0.5-5.9-1.4-7.4
|
||||
c-0.9-1.4-2.6-2.2-5.1-2.2c-0.8,0-1.6,0-2.5,0.1c-0.9,0-1.6,0.1-2.3,0.2v29.4h-10.8L317.9,35.9"/>
|
||||
<path id="path2997" class="st2" d="M358.9,54c-0.1-3,0.5-6,1.5-8.8c0.9-2.4,2.3-4.5,4.1-6.4c1.7-1.7,3.6-3,5.8-3.8
|
||||
c2.2-0.9,4.5-1.3,6.8-1.3c5.4,0,9.7,1.7,12.8,5c3.1,3.3,4.7,8.2,4.7,14.6c0,0.6,0,1.3-0.1,2.1s-0.1,1.4-0.1,2h-24.5
|
||||
c0.2,2.1,1.3,4.1,3.1,5.3c2.2,1.4,4.8,2.1,7.4,2c1.9,0,3.9-0.2,5.8-0.5c1.6-0.3,3.2-0.8,4.8-1.5l1.5,8.8
|
||||
c-0.7,0.4-1.5,0.6-2.3,0.9c-1.1,0.3-2.2,0.6-3.3,0.7c-1.2,0.2-2.4,0.4-3.8,0.6c-1.3,0.1-2.7,0.2-4.1,0.2c-3.1,0.1-6.1-0.4-9-1.5
|
||||
c-2.4-0.9-4.5-2.3-6.3-4.1c-1.7-1.8-2.9-4-3.7-6.3C359.2,59.3,358.8,56.6,358.9,54 M384.2,49.9c0-0.9-0.2-1.8-0.5-2.7
|
||||
c-0.2-0.9-0.7-1.6-1.2-2.3c-0.6-0.7-1.3-1.3-2.1-1.7c-1-0.5-2-0.7-3.1-0.7c-1.1,0-2.1,0.2-3.1,0.7c-0.8,0.4-1.5,0.9-2.1,1.6
|
||||
c-0.6,0.7-1.1,1.5-1.4,2.4c-0.3,0.9-0.5,1.8-0.6,2.7L384.2,49.9"/>
|
||||
<path id="path2999" class="st2" d="M402.6,25.1l10.8-1.7v11.2h13v9h-13V57c-0.1,1.9,0.3,3.8,1.2,5.4c0.8,1.3,2.4,2,4.9,2
|
||||
c1.2,0,2.4-0.1,3.5-0.3c1.2-0.2,2.3-0.5,3.4-0.9l1.5,8.4c-1.4,0.6-2.9,1-4.4,1.4c-1.9,0.4-3.9,0.6-5.9,0.6
|
||||
c-2.5,0.1-5-0.3-7.3-1.2c-1.8-0.7-3.4-1.9-4.6-3.3c-1.2-1.5-2-3.3-2.5-5.2c-0.5-2.2-0.7-4.5-0.6-6.7V25.1"/>
|
||||
<path id="path3001" class="st2" d="M431.9,54c-0.1-3,0.5-6,1.5-8.8c0.9-2.4,2.3-4.5,4.1-6.4c1.7-1.7,3.6-3,5.8-3.8
|
||||
c2.2-0.9,4.5-1.3,6.8-1.3c5.4,0,9.7,1.7,12.8,5s4.7,8.2,4.7,14.6c0,0.6,0,1.3-0.1,2.1c0,0.8-0.1,1.4-0.1,2H443
|
||||
c0.2,2.1,1.3,4.1,3.1,5.3c2.2,1.4,4.8,2.1,7.4,2c1.9,0,3.9-0.2,5.8-0.5c1.6-0.3,3.2-0.8,4.7-1.5l1.5,8.8
|
||||
c-0.7,0.4-1.5,0.6-2.3,0.9c-1.1,0.3-2.2,0.6-3.3,0.7c-1.2,0.2-2.4,0.4-3.8,0.6c-1.3,0.1-2.7,0.2-4.1,0.2c-3.1,0.1-6.1-0.4-9-1.5
|
||||
c-2.4-0.9-4.5-2.3-6.3-4.1c-1.7-1.8-2.9-4-3.7-6.3C432.3,59.3,431.9,56.6,431.9,54 M457.2,49.9c0-0.9-0.2-1.8-0.5-2.7
|
||||
c-0.2-0.9-0.7-1.6-1.2-2.3c-0.6-0.7-1.3-1.3-2.1-1.7c-1-0.5-2-0.7-3.1-0.7c-1.1,0-2.1,0.2-3.1,0.7c-0.8,0.4-1.6,0.9-2.2,1.6
|
||||
c-0.6,0.7-1.1,1.5-1.4,2.4c-0.3,0.9-0.5,1.8-0.6,2.7L457.2,49.9"/>
|
||||
<path id="path3003" class="st2" d="M487,65c1.4,0.1,2.9-0.1,4.2-0.6c0.8-0.4,1.3-1.3,1.2-2.2c-0.1-1-0.7-1.9-1.6-2.2
|
||||
c-1.5-0.9-3.2-1.7-4.9-2.2c-1.7-0.6-3.2-1.3-4.6-2c-1.3-0.6-2.4-1.4-3.5-2.4c-1-1-1.7-2.1-2.2-3.4c-0.6-1.5-0.8-3.1-0.8-4.7
|
||||
c-0.1-3.3,1.4-6.5,4-8.5c2.7-2.1,6.3-3.1,10.9-3.1c2.2,0,4.5,0.2,6.7,0.7c1.7,0.3,3.4,0.7,5.1,1.3l-1.9,8.5
|
||||
c-1.4-0.5-2.7-0.8-4.1-1.2c-1.6-0.4-3.3-0.5-4.9-0.5c-3.4,0-5.1,0.9-5.1,2.8c0,0.4,0.1,0.8,0.2,1.2c0.2,0.4,0.5,0.7,0.9,1
|
||||
c0.4,0.3,1,0.6,1.7,1c0.7,0.4,1.7,0.8,2.9,1.2c2,0.7,4,1.6,5.8,2.6c1.4,0.7,2.6,1.6,3.6,2.8c0.9,0.9,1.5,2,1.9,3.3
|
||||
c0.4,1.4,0.6,2.8,0.6,4.2c0.2,3.4-1.4,6.7-4.3,8.6c-2.8,1.9-6.8,2.9-12,2.9c-2.9,0.1-5.7-0.2-8.5-0.9c-1.6-0.4-3.1-0.9-4.6-1.4
|
||||
l1.8-8.8c1.8,0.7,3.7,1.3,5.6,1.7C483.1,64.8,485,65,487,65"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 11 KiB |
@@ -0,0 +1,108 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 21.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
|
||||
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
|
||||
viewBox="0 0 500.6 84.5" style="enable-background:new 0 0 500.6 84.5;" xml:space="preserve">
|
||||
<style type="text/css">
|
||||
.st0{fill:#326DE6;}
|
||||
.st1{fill:#FFFFFF;}
|
||||
.st2{fill:#326DE5;}
|
||||
</style>
|
||||
<title>Kubernetes_Logo_Hrz_lockup_POS</title>
|
||||
<g id="Layer_2">
|
||||
<g id="Layer_1-2">
|
||||
<path class="st0" d="M79.8,18.8c-0.5-1.6-1.7-2.9-3.2-3.7L46.1,0.5c-0.8-0.4-1.7-0.5-2.5-0.5c-0.8,0-1.7,0-2.5,0.2L10.6,14.9
|
||||
c-1.5,0.7-2.6,2-3,3.7L0,51.5c-0.3,1.7,0.1,3.4,1.1,4.8l21.1,26.1c1.2,1.2,2.9,2,4.6,2.1h33.7c1.8,0.2,3.5-0.6,4.6-2.1l21.1-26.1
|
||||
c1-1.4,1.4-3.1,1.2-4.8L79.8,18.8z"/>
|
||||
<path class="st1" d="M75,50.2L75,50.2c-0.1,0-0.1,0-0.1-0.1S74.6,50,74.5,50c-0.4-0.1-0.8-0.1-1.2-0.1c-0.2,0-0.4,0-0.6-0.1h-0.1
|
||||
c-1.1-0.1-2.3-0.3-3.4-0.6c-0.3-0.1-0.6-0.4-0.7-0.7c0-0.1-0.1-0.1-0.1-0.1l0,0l-0.8-0.2c0.4-2.9,0.2-5.9-0.4-8.8
|
||||
c-0.7-2.9-1.9-5.7-3.5-8.2l0.6-0.6l0,0v-0.1c0-0.3,0.1-0.7,0.3-0.9c0.9-0.7,1.8-1.4,2.8-1.9l0,0c0.2-0.1,0.4-0.2,0.6-0.3
|
||||
c0.4-0.2,0.7-0.4,1.1-0.6c0.1-0.1,0.2-0.1,0.3-0.2s0.1-0.1,0.1-0.1l0,0c0.9-0.7,1.1-1.9,0.4-2.8c-0.3-0.4-0.9-0.7-1.4-0.7
|
||||
c-0.5,0-1,0.2-1.4,0.5l0,0l-0.1,0.1c-0.1,0.1-0.2,0.2-0.3,0.2c-0.3,0.3-0.6,0.6-0.8,0.9c-0.1,0.2-0.3,0.3-0.4,0.4l0,0
|
||||
c-0.8,0.8-1.6,1.6-2.5,2.2c-0.2,0.1-0.4,0.2-0.6,0.2c-0.1,0-0.3,0-0.4-0.1H62L61.2,28c-0.8-0.8-1.7-1.6-2.5-2.4
|
||||
c-3.7-2.9-8.3-4.7-13-5.2l-0.1-0.8l0,0l-0.1-0.1c-0.3-0.2-0.4-0.5-0.5-0.8c0-1.1,0-2.2,0.2-3.4v-0.1c0-0.2,0.1-0.4,0.1-0.6
|
||||
c0.1-0.4,0.1-0.8,0.2-1.2v-0.6l0,0c0.1-1-0.7-2-1.7-2c-0.6,0-1.2,0.2-1.6,0.6c-0.4,0.4-0.6,0.9-0.6,1.4l0,0v0.5
|
||||
c0,0.4,0.1,0.8,0.2,1.2c0.1,0.2,0.1,0.4,0.1,0.6v0.1c0.2,1.1,0.2,2.2,0.2,3.4c-0.1,0.3-0.2,0.6-0.5,0.8l-0.1,0.1l0,0l-0.1,0.8
|
||||
c-1.1,0.1-2.2,0.3-3.4,0.5c-4.7,1-9,3.5-12.3,7l-0.6-0.4H25c-0.1,0-0.2,0.1-0.4,0.1c-0.2,0-0.5-0.1-0.6-0.2
|
||||
c-0.9-0.7-1.7-1.5-2.5-2.3l0,0c-0.1-0.2-0.3-0.3-0.4-0.4c-0.3-0.3-0.5-0.6-0.8-0.9c-0.1-0.1-0.2-0.1-0.3-0.2s-0.1-0.1-0.1-0.1l0,0
|
||||
c-0.4-0.3-0.9-0.5-1.4-0.5c-0.6,0-1.1,0.2-1.5,0.7c-0.6,0.9-0.4,2.1,0.4,2.8l0,0c0.1,0,0.1,0.1,0.1,0.1s0.2,0.2,0.3,0.2
|
||||
c0.3,0.2,0.7,0.4,1.1,0.6c0.2,0.1,0.4,0.2,0.6,0.3l0,0c1,0.6,1.9,1.2,2.8,1.9c0.2,0.2,0.4,0.6,0.3,0.9v0.1l0,0l0.6,0.6
|
||||
c-0.1,0.2-0.2,0.3-0.3,0.5c-3.1,4.9-4.3,10.7-3.4,16.4l-0.8,0.2l0,0c0,0.1-0.1,0.1-0.1,0.1c-0.1,0.3-0.4,0.5-0.7,0.7
|
||||
c-1.1,0.3-2.2,0.5-3.4,0.6h-0.1c-0.2,0-0.4,0-0.6,0.1c-0.4,0-0.8,0.1-1.2,0.1c-0.1,0-0.2,0.1-0.4,0.1c-0.1,0-0.1,0-0.2,0.1l0,0
|
||||
c-1.1,0.2-1.8,1.2-1.6,2.3c0.2,0.9,1.1,1.5,2,1.4c0.2,0,0.3,0,0.5-0.1l0,0c0.1,0,0.1,0,0.1-0.1s0.2-0.1,0.4-0.1
|
||||
c0.4-0.1,0.8-0.3,1.1-0.4c0.2-0.1,0.4-0.2,0.6-0.2h0.1c1-0.4,2.1-0.7,3.2-0.9h0.1c0.3,0,0.6,0.1,0.8,0.3c0.1,0,0.1,0.1,0.1,0.1
|
||||
l0,0l0.9-0.1c1.5,4.6,4.3,8.7,8.2,11.7c0.9,0.7,1.7,1.3,2.7,1.8l-0.4,0.8l0,0c0,0.1,0.1,0.1,0.1,0.1c0.2,0.3,0.2,0.7,0.1,1
|
||||
c-0.4,1-1,2-1.6,2.9v0.1c-0.1,0.2-0.2,0.3-0.4,0.5s-0.4,0.6-0.7,1c-0.1,0.1-0.1,0.2-0.2,0.3c0,0,0,0.1-0.1,0.1l0,0
|
||||
c-0.5,1-0.1,2.2,0.8,2.7c0.2,0.1,0.5,0.2,0.8,0.2c0.8,0,1.5-0.5,1.9-1.2l0,0c0,0,0-0.1,0.1-0.1c0-0.1,0.1-0.2,0.2-0.3
|
||||
c0.1-0.4,0.3-0.7,0.4-1.1l0.2-0.6l0,0c0.3-1.1,0.8-2.1,1.3-3.1c0.2-0.3,0.5-0.5,0.8-0.6c0.1,0,0.1,0,0.1-0.1l0,0l0.4-0.8
|
||||
c2.8,1.1,5.7,1.6,8.7,1.6c1.8,0,3.6-0.2,5.4-0.6c1.1-0.2,2.2-0.6,3.2-0.9l0.4,0.7l0,0c0.1,0,0.1,0,0.1,0.1
|
||||
c0.3,0.1,0.6,0.3,0.8,0.6c0.5,1,0.9,2,1.3,3v0.1l0.2,0.6c0.1,0.4,0.2,0.8,0.4,1.1c0.1,0.1,0.1,0.2,0.2,0.3c0,0,0,0.1,0.1,0.1l0,0
|
||||
c0.4,0.7,1.1,1.2,1.9,1.2c0.3,0,0.5-0.1,0.8-0.2c0.4-0.2,0.8-0.6,0.9-1.1c0.1-0.5,0.1-1.1-0.1-1.6l0,0c0-0.1-0.1-0.1-0.1-0.1
|
||||
c0-0.1-0.1-0.2-0.2-0.3c-0.2-0.4-0.4-0.7-0.7-1c-0.1-0.2-0.2-0.3-0.4-0.5v-0.1c-0.7-0.9-1.2-1.9-1.6-2.9c-0.1-0.3-0.1-0.7,0.1-1
|
||||
c0-0.1,0.1-0.1,0.1-0.1l0,0l-0.3-0.8c5.2-3.1,9-7.9,10.9-13.6l0.8,0.1l0,0c0.1,0,0.1-0.1,0.1-0.1c0.2-0.2,0.5-0.3,0.8-0.3h0.1
|
||||
c1.1,0.2,2.2,0.5,3.2,0.9h0.1c0.2,0.1,0.4,0.2,0.6,0.2c0.4,0.2,0.7,0.3,1.1,0.4c0.1,0,0.2,0.1,0.4,0.1c0.1,0,0.1,0,0.2,0.1l0,0
|
||||
c0.2,0.1,0.3,0.1,0.5,0.1c0.9,0,1.7-0.6,2-1.4C76.7,51.2,76,50.4,75,50.2z M46.2,47.1l-2.7,1.3l-2.7-1.3L40,44.2l1.9-2.4H45
|
||||
l1.9,2.4L46.2,47.1z M62.5,40.6c0.5,2.1,0.6,4.2,0.4,6.3l-9.5-2.7l0,0c-0.9-0.2-1.4-1.1-1.2-2c0.1-0.3,0.2-0.5,0.4-0.7l7.5-6.8
|
||||
C61.2,36.5,62,38.5,62.5,40.6L62.5,40.6z M57.1,31L49,36.8c-0.7,0.4-1.7,0.3-2.2-0.4c-0.2-0.2-0.3-0.4-0.3-0.7l-0.6-10.1
|
||||
C50.1,26.1,54.1,28,57.1,31z M39,25.9l2-0.4l-0.6,10l0,0c0,0.9-0.8,1.6-1.7,1.6c-0.3,0-0.5-0.1-0.8-0.2L29.8,31
|
||||
C32.3,28.5,35.5,26.7,39,25.9z M26.8,34.7l7.4,6.6l0,0c0.7,0.6,0.8,1.6,0.2,2.3c-0.2,0.3-0.4,0.4-0.8,0.5L24,46.9
|
||||
C23.6,42.7,24.6,38.4,26.8,34.7z M25.1,51.6l9.9-1.7c0.8,0,1.6,0.5,1.7,1.3c0.1,0.3,0.1,0.7-0.1,1l0,0l-3.8,9.2
|
||||
C29.3,59.1,26.5,55.6,25.1,51.6z M47.8,64c-1.4,0.3-2.9,0.5-4.4,0.5c-2.1,0-4.3-0.4-6.3-1l4.9-8.9c0.5-0.6,1.3-0.8,2-0.4
|
||||
c0.3,0.2,0.5,0.4,0.8,0.7l0,0l4.8,8.7C49.1,63.7,48.5,63.8,47.8,64z M60,55.3c-1.5,2.4-3.6,4.5-6,6L50.1,52
|
||||
c-0.2-0.8,0.1-1.6,0.9-2c0.3-0.1,0.6-0.2,0.9-0.2l10,1.7C61.4,52.9,60.8,54.2,60,55.3z"/>
|
||||
<g id="layer1">
|
||||
<g id="text4373">
|
||||
<path id="path2985" class="st2" d="M125.7,45.9c1.1-1.2,2.1-2.4,3.3-3.6c1.1-1.3,2.2-2.5,3.3-3.7c1.1-1.3,2.1-2.4,3-3.5
|
||||
s1.8-2.1,2.5-2.9h12.8c-2.6,2.9-5.1,5.8-7.5,8.5c-2.5,2.7-5.1,5.5-8,8.3c1.6,1.5,3.1,3,4.5,4.7c1.5,1.8,3,3.6,4.5,5.6
|
||||
c1.4,1.9,2.8,3.9,4,5.8c1.2,1.9,2.2,3.7,3,5.3h-12.3c-0.8-1.3-1.7-2.6-2.7-4.1s-2.1-3-3.1-4.6c-1.1-1.5-2.3-3-3.6-4.4
|
||||
c-1.1-1.3-2.3-2.5-3.6-3.5v16.7h-10.8V15.7l10.8-1.7V45.9"/>
|
||||
<path id="path2987" class="st2" d="M188.6,68.9c-2.3,0.6-4.7,1.1-7.1,1.4c-3,0.5-6.1,0.7-9.1,0.7c-2.8,0.1-5.5-0.4-8.1-1.3
|
||||
c-2-0.8-3.7-2-5.1-3.6c-1.3-1.7-2.2-3.6-2.7-5.7c-0.6-2.3-0.8-4.8-0.8-7.2V32.1h10.8V52c0,3.5,0.5,6,1.4,7.5
|
||||
c0.9,1.5,2.6,2.3,5.1,2.4c0.8,0,1.6,0,2.5-0.1s1.6-0.1,2.3-0.3V32.1h10.8L188.6,68.9"/>
|
||||
<path id="path2989" class="st2" d="M223.2,50.9c0-7-2.6-10.4-7.7-10.4c-1.1,0-2.2,0.1-3.3,0.4c-0.9,0.2-1.8,0.6-2.6,1.1v19.6
|
||||
c0.5,0.1,1.2,0.2,2,0.3c0.8,0.1,1.7,0.1,2.7,0.1c2.6,0.2,5.1-0.9,6.7-3C222.5,56.6,223.3,53.8,223.2,50.9 M234.2,51.3
|
||||
c0,2.8-0.4,5.6-1.4,8.3c-0.8,2.4-2.1,4.5-3.8,6.3c-1.8,1.8-3.9,3.2-6.2,4.1c-2.7,1-5.5,1.4-8.4,1.4c-1.3,0-2.7-0.1-4.1-0.2
|
||||
c-1.4-0.1-2.8-0.3-4.2-0.4c-1.3-0.2-2.6-0.4-3.9-0.7c-1.3-0.2-2.4-0.6-3.3-1V15.7l10.8-1.7v19c1.2-0.5,2.5-0.9,3.8-1.2
|
||||
c1.4-0.3,2.8-0.4,4.2-0.4c2.5,0,4.9,0.4,7.2,1.5c2,0.9,3.8,2.3,5.2,4c1.5,1.9,2.6,4,3.2,6.3C233.9,45.7,234.3,48.5,234.2,51.3"
|
||||
/>
|
||||
<path id="path2991" class="st2" d="M240.7,51.5c-0.1-3,0.5-6,1.5-8.8c0.9-2.4,2.3-4.5,4.1-6.4c1.7-1.7,3.6-3,5.8-3.8
|
||||
c2.2-0.9,4.5-1.3,6.8-1.3c5.4,0,9.7,1.7,12.8,5c3.1,3.3,4.7,8.2,4.7,14.6c0,0.6,0,1.3-0.1,2.1s-0.1,1.4-0.1,2h-24.5
|
||||
c0.2,2.1,1.3,4,3.1,5.2c2.2,1.4,4.8,2.1,7.4,2c1.9,0,3.9-0.2,5.8-0.5c1.6-0.3,3.2-0.8,4.7-1.4l1.5,8.8c-0.7,0.4-1.5,0.6-2.3,0.9
|
||||
c-1.1,0.3-2.2,0.6-3.3,0.7c-1.2,0.2-2.4,0.4-3.8,0.6c-1.3,0.1-2.7,0.2-4.1,0.2c-3.1,0.1-6.1-0.4-9-1.5c-2.4-0.9-4.5-2.3-6.3-4.1
|
||||
c-1.7-1.8-2.9-4-3.7-6.3C241.1,56.8,240.7,54.1,240.7,51.5 M266,47.4c0-0.9-0.2-1.8-0.5-2.7c-0.2-0.9-0.7-1.6-1.2-2.3
|
||||
c-0.6-0.7-1.3-1.3-2.1-1.7c-1-0.5-2-0.7-3.1-0.7c-1.1,0-2.1,0.2-3.1,0.7c-0.8,0.4-1.6,0.9-2.2,1.6c-0.6,0.7-1.1,1.5-1.4,2.4
|
||||
c-0.3,0.9-0.5,1.8-0.6,2.7L266,47.4"/>
|
||||
<path id="path2993" class="st2" d="M307.8,41.7c-1-0.2-2.1-0.5-3.4-0.7c-1.4-0.3-2.8-0.4-4.2-0.4c-0.8,0-1.6,0.1-2.5,0.2
|
||||
c-0.7,0.1-1.4,0.2-2.1,0.4v29.1h-10.8V34.1c2.2-0.8,4.5-1.4,6.8-1.9c2.9-0.7,5.9-1,8.8-0.9c0.7,0,1.4,0.1,2.1,0.1
|
||||
c0.8,0,1.6,0.1,2.5,0.3c0.8,0.1,1.6,0.2,2.5,0.4c0.7,0.1,1.4,0.3,2.1,0.6L307.8,41.7"/>
|
||||
<path id="path2995" class="st2" d="M315.4,33.4c2.3-0.6,4.7-1.1,7.1-1.5c3-0.5,6.1-0.7,9.1-0.7c2.7-0.1,5.4,0.4,8,1.3
|
||||
c2,0.7,3.8,1.9,5.1,3.5c1.3,1.6,2.2,3.5,2.7,5.5c0.6,2.3,0.8,4.7,0.8,7.1v21.5h-10.8V50c0-3.5-0.5-5.9-1.4-7.4
|
||||
c-0.9-1.4-2.6-2.2-5.1-2.2c-0.8,0-1.6,0-2.5,0.1c-0.9,0-1.6,0.1-2.3,0.2v29.4h-10.8L315.4,33.4"/>
|
||||
<path id="path2997" class="st2" d="M356.4,51.5c-0.1-3,0.5-6,1.5-8.8c0.9-2.4,2.3-4.5,4.1-6.4c1.7-1.7,3.6-3,5.8-3.8
|
||||
c2.2-0.9,4.5-1.3,6.8-1.3c5.4,0,9.7,1.7,12.8,5c3.1,3.3,4.7,8.2,4.7,14.6c0,0.6,0,1.3-0.1,2.1c0,0.8-0.1,1.4-0.1,2h-24.5
|
||||
c0.2,2.1,1.3,4,3.1,5.2c2.2,1.4,4.8,2.1,7.4,2c1.9,0,3.9-0.2,5.8-0.5c1.6-0.3,3.2-0.8,4.7-1.4l1.5,8.8c-0.7,0.4-1.5,0.6-2.3,0.9
|
||||
c-1.1,0.3-2.2,0.6-3.3,0.7c-1.2,0.2-2.4,0.4-3.8,0.6c-1.3,0.1-2.7,0.2-4.1,0.2c-3.1,0.1-6.1-0.4-9-1.5c-2.4-0.9-4.5-2.3-6.3-4.1
|
||||
c-1.7-1.8-2.9-4-3.7-6.3C356.7,56.8,356.3,54.1,356.4,51.5 M381.7,47.4c0-0.9-0.2-1.8-0.5-2.7c-0.2-0.9-0.6-1.7-1.2-2.4
|
||||
c-0.6-0.7-1.3-1.3-2.1-1.7c-1-0.5-2-0.7-3.1-0.7c-1.1,0-2.1,0.2-3.1,0.7c-0.8,0.4-1.6,0.9-2.2,1.6c-0.6,0.7-1.1,1.5-1.4,2.4
|
||||
c-0.3,0.9-0.5,1.8-0.6,2.7L381.7,47.4"/>
|
||||
<path id="path2999" class="st2" d="M400.1,22.6l10.8-1.7v11.2h13v9h-13v13.4c-0.1,1.9,0.3,3.8,1.2,5.4c0.8,1.3,2.4,2,4.9,2
|
||||
c1.2,0,2.4-0.1,3.5-0.3c1.2-0.2,2.3-0.5,3.4-0.9l1.5,8.4c-1.4,0.6-2.9,1-4.4,1.4c-1.9,0.4-3.9,0.6-5.9,0.6
|
||||
c-2.5,0.1-5-0.3-7.3-1.2c-1.8-0.7-3.4-1.9-4.6-3.3c-1.2-1.5-2-3.3-2.5-5.2c-0.5-2.2-0.7-4.5-0.6-6.7L400.1,22.6"/>
|
||||
<path id="path3001" class="st2" d="M429.4,51.5c-0.1-3,0.5-6,1.5-8.8c0.9-2.4,2.3-4.5,4.1-6.4c1.7-1.7,3.6-3,5.8-3.8
|
||||
c2.2-0.9,4.5-1.3,6.8-1.3c5.4,0,9.7,1.7,12.8,5c3.1,3.3,4.7,8.2,4.7,14.6c0,0.6,0,1.3-0.1,2.1c0,0.8-0.1,1.4-0.1,2h-24.5
|
||||
c0.2,2.1,1.4,4,3.1,5.2c2.2,1.4,4.8,2.1,7.4,2c1.9,0,3.9-0.2,5.8-0.5c1.6-0.3,3.2-0.8,4.7-1.4l1.5,8.8c-0.7,0.4-1.5,0.6-2.3,0.9
|
||||
c-1.1,0.3-2.2,0.6-3.3,0.7c-1.2,0.2-2.4,0.4-3.8,0.6c-1.3,0.1-2.7,0.2-4.1,0.2c-3.1,0.1-6.1-0.4-9-1.5c-2.4-0.9-4.5-2.3-6.3-4.1
|
||||
c-1.7-1.8-2.9-4-3.7-6.3C429.8,56.8,429.4,54.1,429.4,51.5 M454.8,47.4c0-0.9-0.2-1.8-0.5-2.7c-0.2-0.9-0.7-1.7-1.2-2.4
|
||||
c-0.6-0.7-1.3-1.3-2.1-1.7c-1-0.5-2-0.7-3.1-0.7c-1.1,0-2.1,0.2-3.1,0.7c-0.8,0.4-1.6,0.9-2.2,1.6c-0.6,0.7-1.1,1.5-1.4,2.4
|
||||
c-0.3,0.9-0.5,1.8-0.6,2.7L454.8,47.4"/>
|
||||
<path id="path3003" class="st2" d="M484.5,62.5c1.4,0.1,2.9-0.1,4.2-0.6c0.8-0.4,1.3-1.3,1.2-2.2c-0.1-1-0.7-1.9-1.6-2.2
|
||||
c-1.5-0.9-3.2-1.7-4.9-2.2c-1.7-0.6-3.2-1.3-4.6-2c-1.3-0.6-2.4-1.4-3.5-2.4c-1-1-1.7-2.1-2.2-3.4c-0.6-1.5-0.8-3.1-0.8-4.7
|
||||
c-0.1-3.3,1.4-6.5,4-8.5c2.7-2.1,6.3-3.1,10.9-3.1c2.2,0,4.5,0.2,6.7,0.6c1.7,0.3,3.4,0.7,5.1,1.3l-1.9,8.4
|
||||
c-1.4-0.5-2.7-0.8-4.1-1.2c-1.6-0.3-3.3-0.5-4.9-0.4c-3.4,0-5.1,0.9-5.1,2.8c0,0.4,0.1,0.8,0.2,1.2c0.2,0.4,0.5,0.7,0.9,1
|
||||
c0.4,0.3,1,0.6,1.7,1c0.7,0.4,1.7,0.8,2.9,1.2c2,0.7,4,1.6,5.9,2.6c1.4,0.7,2.6,1.6,3.6,2.8c0.9,0.9,1.5,2.1,1.9,3.3
|
||||
c0.4,1.4,0.6,2.8,0.6,4.2c0.2,3.4-1.4,6.7-4.3,8.6c-2.8,1.9-6.8,2.9-12,2.9c-2.9,0.1-5.7-0.2-8.5-0.9c-1.6-0.4-3.1-0.9-4.6-1.4
|
||||
l1.8-8.8c1.8,0.7,3.7,1.3,5.6,1.7C480.5,62.3,482.4,62.5,484.5,62.5"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 10 KiB |
@@ -0,0 +1,36 @@
|
||||
/*
|
||||
Copyright 2018 Google LLC
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
You may obtain a copy of the License at
|
||||
https://www.apache.org/licenses/LICENSE-2.0
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
*/
|
||||
|
||||
(function ($) {
|
||||
"use strict";
|
||||
|
||||
var Search = {
|
||||
init: function () {
|
||||
$(document).ready(function () {
|
||||
$(document).on("keypress", ".td-search-input", function (e) {
|
||||
if (e.keyCode !== 13) {
|
||||
return;
|
||||
}
|
||||
|
||||
var query = $(this).val();
|
||||
var searchPage = "{{ "docs/search/" | absURL }}?q=" + query;
|
||||
document.location = searchPage;
|
||||
|
||||
return false;
|
||||
});
|
||||
});
|
||||
},
|
||||
};
|
||||
|
||||
Search.init();
|
||||
})(jQuery);
|
||||
@@ -0,0 +1,834 @@
|
||||
@import "reset";
|
||||
|
||||
// header
|
||||
$full-width-paddingX: 20px;
|
||||
|
||||
$main-width: 100%;
|
||||
$main-max-width: 100%;
|
||||
|
||||
$header-height: 80px;
|
||||
|
||||
$logo-width: 180px;
|
||||
|
||||
$nav-buttons-margin-left: 30px;
|
||||
|
||||
$hamburger-size: 50px;
|
||||
|
||||
// main nav
|
||||
$main-nav-padding: 140px 0 30px;
|
||||
$main-nav-h5-margin-bottom: 1em;
|
||||
$main-nav-h3-margin-bottom: 0.6em;
|
||||
$nav-box-width: 20%;
|
||||
$nav-box-sibling-margin-left: calc(20% / 3);
|
||||
$main-nav-main-sibling-margin-top: 60px;
|
||||
$main-nav-left-button-size: 50px;
|
||||
$main-nav-left-button-font-size: 18px;
|
||||
|
||||
// hero
|
||||
$hero-padding-top: 80px;
|
||||
$headline-wrapper-margin-bottom: 40px;
|
||||
$quickstart-button-padding: 0 50px;
|
||||
$vendor-strip-height: 88px;
|
||||
$vendor-strip-font-size: 16px;
|
||||
|
||||
// video
|
||||
$video-section-height: 200px;
|
||||
|
||||
@import "size";
|
||||
|
||||
////////////////////////////////////////////////////////////////////////////////////////////////////
|
||||
////////////////////////////////////////////////////////////////////////////////////////////////////
|
||||
////////////////////////////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
body {
|
||||
background-color: white;
|
||||
}
|
||||
|
||||
section {
|
||||
position: relative;
|
||||
background-color: white;
|
||||
}
|
||||
|
||||
section,
|
||||
header,
|
||||
footer {
|
||||
.main-section {
|
||||
position: relative;
|
||||
margin: auto;
|
||||
}
|
||||
|
||||
p {
|
||||
font-size: 14px;
|
||||
font-weight: 400;
|
||||
}
|
||||
|
||||
.button {
|
||||
display: inline-block;
|
||||
border-radius: 6px;
|
||||
padding: 6px 20px;
|
||||
line-height: 1.3rem;
|
||||
color: white;
|
||||
background-color: $blue;
|
||||
text-decoration: none;
|
||||
font-size: 1rem;
|
||||
}
|
||||
|
||||
#cellophane {
|
||||
position: fixed;
|
||||
top: 0;
|
||||
left: 0;
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
// HEADER
|
||||
|
||||
#hamburger {
|
||||
display: inline-block;
|
||||
position: relative;
|
||||
margin-left: auto;
|
||||
vertical-align: middle;
|
||||
padding: 0;
|
||||
border: 0;
|
||||
background: none;
|
||||
|
||||
div,
|
||||
&:before,
|
||||
&:after {
|
||||
position: absolute;
|
||||
left: 15%;
|
||||
width: 70%;
|
||||
height: 2px;
|
||||
background-color: $blue;
|
||||
transition: 0.3s;
|
||||
content: "";
|
||||
}
|
||||
|
||||
div {
|
||||
top: calc(50% - 1px);
|
||||
}
|
||||
|
||||
&:before {
|
||||
top: 24%;
|
||||
}
|
||||
|
||||
&:after {
|
||||
bottom: 24%;
|
||||
}
|
||||
|
||||
&:hover {
|
||||
div,
|
||||
&:before,
|
||||
&:after {
|
||||
background-color: white;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// HERO
|
||||
.header-hero {
|
||||
background-image: url(/images/texture.png);
|
||||
background-color: $dark-grey;
|
||||
text-align: center;
|
||||
padding-left: 0;
|
||||
padding-right: 0;
|
||||
margin-bottom: 0;
|
||||
position: relative;
|
||||
|
||||
&.bot-bar:after {
|
||||
display: block;
|
||||
margin-bottom: -24px;
|
||||
height: 8px;
|
||||
width: 100%;
|
||||
background-color: transparentize(white, 0.9);
|
||||
content: "";
|
||||
}
|
||||
|
||||
&.no-sub {
|
||||
h5 {
|
||||
display: none;
|
||||
}
|
||||
|
||||
h1 {
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.td-home .header-hero:after {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.header-hero {
|
||||
background-color: $dark-grey;
|
||||
|
||||
h5 {
|
||||
margin: 20px 0;
|
||||
line-height: 28px;
|
||||
}
|
||||
}
|
||||
|
||||
#vendorStrip {
|
||||
position: relative;
|
||||
|
||||
ul {
|
||||
float: left;
|
||||
}
|
||||
|
||||
li {
|
||||
display: inline-block;
|
||||
height: 100%;
|
||||
}
|
||||
|
||||
a {
|
||||
display: block;
|
||||
height: 100%;
|
||||
color: white;
|
||||
font-size: 0.75em;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
li + li {
|
||||
margin-left: 0;
|
||||
}
|
||||
}
|
||||
|
||||
.pi-accordion {
|
||||
& > .container:first-child > .item:first-child > .title:first-child {
|
||||
padding-left: 0;
|
||||
font-size: 1.5em;
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
& > .container:first-child > .item.yah:first-child > .title:first-child {
|
||||
margin-left: -20px !important;
|
||||
}
|
||||
|
||||
.item {
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
.title {
|
||||
color: $dark-grey;
|
||||
position: relative;
|
||||
padding: 7.5px 10px 7.5px 18px;
|
||||
cursor: pointer;
|
||||
transition: 0.3s;
|
||||
|
||||
&:hover {
|
||||
color: $blue;
|
||||
}
|
||||
}
|
||||
|
||||
a.item > .title {
|
||||
color: black;
|
||||
|
||||
&:hover {
|
||||
color: $blue;
|
||||
}
|
||||
}
|
||||
|
||||
div.item > .title {
|
||||
&:before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
top: 12px;
|
||||
left: 2px;
|
||||
border-style: solid;
|
||||
border-width: 5px 0 5px 8px;
|
||||
border-color: transparent transparent transparent $blue;
|
||||
transform: rotate(0deg);
|
||||
transition: 0.3s;
|
||||
}
|
||||
}
|
||||
|
||||
.wrapper {
|
||||
position: relative;
|
||||
width: 100%;
|
||||
transition: height 0.3s;
|
||||
}
|
||||
|
||||
.content {
|
||||
padding-left: 20px;
|
||||
opacity: 0;
|
||||
transition: 0.3s;
|
||||
}
|
||||
|
||||
.item.on {
|
||||
& > .title:before {
|
||||
transform: rotate(90deg);
|
||||
}
|
||||
|
||||
& > .wrapper > .content {
|
||||
opacity: 1;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
dt {
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
|
||||
dd {
|
||||
margin-bottom: 16px;
|
||||
}
|
||||
|
||||
.pi-pushmenu {
|
||||
display: none;
|
||||
position: fixed;
|
||||
top: 0;
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
opacity: 0;
|
||||
transition: opacity 0.3s;
|
||||
|
||||
&.on {
|
||||
opacity: 1;
|
||||
}
|
||||
|
||||
.overlay {
|
||||
position: fixed;
|
||||
top: 0;
|
||||
left: 0;
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
background-color: rgba(0, 0, 0, 0.4);
|
||||
}
|
||||
|
||||
.sled {
|
||||
position: absolute;
|
||||
top: 0;
|
||||
width: 0;
|
||||
height: 100%;
|
||||
background-color: white;
|
||||
overflow: auto;
|
||||
transition: 0.3s;
|
||||
}
|
||||
|
||||
&.on .sled {
|
||||
width: 400px;
|
||||
max-width: 100vw;
|
||||
}
|
||||
|
||||
.top-bar {
|
||||
height: 0;
|
||||
line-height: 60px;
|
||||
background-color: #444;
|
||||
}
|
||||
|
||||
ul {
|
||||
margin-top: 25px;
|
||||
}
|
||||
|
||||
li {
|
||||
position: relative;
|
||||
display: block;
|
||||
width: 100%;
|
||||
min-height: 45px;
|
||||
padding: 0 60px 0 20px;
|
||||
border-bottom: 1px solid #cccccc;
|
||||
}
|
||||
|
||||
a {
|
||||
display: inline-block;
|
||||
width: 100%;
|
||||
height: 45px;
|
||||
line-height: 45px;
|
||||
font-family: "Roboto", sans-serif;
|
||||
font-size: 20px;
|
||||
color: $blue;
|
||||
}
|
||||
|
||||
.button {
|
||||
background: none;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
ul ul {
|
||||
padding: 0 20px;
|
||||
|
||||
li {
|
||||
min-height: 40px;
|
||||
}
|
||||
|
||||
a {
|
||||
height: 40px;
|
||||
line-height: 40px;
|
||||
font-size: 18px;
|
||||
color: lighten(#222222, 20%);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.push-menu-close-button {
|
||||
position: absolute;
|
||||
top: 0;
|
||||
right: 0;
|
||||
width: 50px;
|
||||
height: 50px;
|
||||
|
||||
&:before,
|
||||
&:after {
|
||||
content: "";
|
||||
position: absolute;
|
||||
top: calc(50% - 1px);
|
||||
left: 25%;
|
||||
width: 50%;
|
||||
height: 2px;
|
||||
background-color: black;
|
||||
}
|
||||
|
||||
&:before {
|
||||
transform: rotate(45deg);
|
||||
}
|
||||
|
||||
&:after {
|
||||
transform: rotate(-45deg);
|
||||
}
|
||||
}
|
||||
|
||||
// ocean nodes
|
||||
$ocean-nodes-padding-Y: 60px;
|
||||
$ocean-nodes-main-margin-bottom: 60px;
|
||||
$ocean-nodes-h3-margin-bottom: 30px;
|
||||
|
||||
// video
|
||||
$video-section-height: 200px;
|
||||
|
||||
// features
|
||||
$features-h3-margin-bottom: 20px;
|
||||
$feature-box-div-width: 100%;
|
||||
$feature-box-margin-bottom: 0;
|
||||
$feature-box-div-margin-bottom: 40px;
|
||||
|
||||
// Home-specific
|
||||
|
||||
.td-home {
|
||||
&.flip-nav,
|
||||
&.open-nav {
|
||||
.logo {
|
||||
background-image: url(/images/nav_logo2.svg);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.header-hero {
|
||||
margin-bottom: 0;
|
||||
padding-bottom: 1px;
|
||||
|
||||
.main-section {
|
||||
padding: 0 10px;
|
||||
margin-bottom: 30px;
|
||||
}
|
||||
|
||||
#vendorStrip {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
// Add logo to CNCF section
|
||||
section#cncf {
|
||||
padding-top: 60px;
|
||||
padding-bottom: 140px;
|
||||
background-image: url(/images/cncf-color.svg);
|
||||
background-position: center 100px;
|
||||
background-repeat: no-repeat;
|
||||
background-size: 300px;
|
||||
}
|
||||
|
||||
// OCEAN NODES
|
||||
#oceanNodes {
|
||||
padding-top: $ocean-nodes-padding-Y;
|
||||
padding-bottom: $ocean-nodes-padding-Y;
|
||||
|
||||
a {
|
||||
color: $blue;
|
||||
}
|
||||
|
||||
.main-section {
|
||||
margin-bottom: $ocean-nodes-padding-Y;
|
||||
min-height: 160px;
|
||||
}
|
||||
|
||||
.image-wrapper {
|
||||
max-width: 75%;
|
||||
margin: 0 auto 20px;
|
||||
text-align: center;
|
||||
|
||||
img {
|
||||
width: 100%;
|
||||
max-width: 160px;
|
||||
}
|
||||
}
|
||||
|
||||
.main-section:first-child {
|
||||
.image-wrapper {
|
||||
max-width: 100%;
|
||||
|
||||
img {
|
||||
max-width: 491px;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
h3 {
|
||||
margin-bottom: $ocean-nodes-h3-margin-bottom;
|
||||
}
|
||||
}
|
||||
|
||||
// Video thingy
|
||||
#video {
|
||||
height: $video-section-height;
|
||||
}
|
||||
|
||||
#video {
|
||||
width: 100%;
|
||||
position: relative;
|
||||
background-position: center center;
|
||||
background-size: cover;
|
||||
|
||||
& > .light-text {
|
||||
display: none;
|
||||
// position: absolute;
|
||||
// top: 50%;
|
||||
// left: 75%;
|
||||
width: 500px;
|
||||
padding-top: 2rem;
|
||||
// transform: translate(-50%, -50%);
|
||||
color: white;
|
||||
}
|
||||
|
||||
h2 {
|
||||
font-size: 32px;
|
||||
line-height: 44px;
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
|
||||
p {
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
|
||||
#desktopKCButton {
|
||||
position: relative;
|
||||
font-size: 18px;
|
||||
background-color: $dark-grey;
|
||||
border-radius: 8px;
|
||||
color: $white;
|
||||
padding: 20px 10px 20px 10px;
|
||||
}
|
||||
|
||||
#desktopShowVideoButton {
|
||||
position: relative;
|
||||
font-size: 24px;
|
||||
background-color: white;
|
||||
border-radius: 8px;
|
||||
color: $blue;
|
||||
padding: 15px 30px 15px 80px;
|
||||
margin-bottom: 15px;
|
||||
|
||||
&:before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
@include pureCenter(40px);
|
||||
width: 0;
|
||||
height: 0;
|
||||
border-style: solid;
|
||||
border-width: 10px 0 10px 20px;
|
||||
border-color: transparent transparent transparent $blue;
|
||||
}
|
||||
}
|
||||
|
||||
#mobileShowVideoButton {
|
||||
@include pureCenter;
|
||||
width: 80px;
|
||||
height: 80px;
|
||||
border-radius: 50%;
|
||||
background-color: transparent;
|
||||
border: 5px solid rgba(255, 255, 255, 0.2);
|
||||
overflow: visible;
|
||||
|
||||
&:after {
|
||||
@include pureCenter;
|
||||
left: 40px;
|
||||
content: "";
|
||||
width: 0;
|
||||
height: 0;
|
||||
border-style: solid;
|
||||
border-width: 20px 0 20px 30px;
|
||||
border-color: transparent transparent transparent #ffffff;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
#videoPlayer {
|
||||
@include fullScreen;
|
||||
background-color: rgba(0, 0, 0, 0.9);
|
||||
display: none;
|
||||
|
||||
iframe {
|
||||
@include pureCenter;
|
||||
@include maintain-aspect-ratio;
|
||||
}
|
||||
|
||||
#closeButton {
|
||||
position: absolute;
|
||||
top: 20px;
|
||||
right: 20px;
|
||||
width: 50px;
|
||||
height: 50px;
|
||||
border: 2px solid transparent;
|
||||
transition: 0.3s;
|
||||
|
||||
&:before,
|
||||
&:after {
|
||||
content: "";
|
||||
position: absolute;
|
||||
top: calc(50% - 1px);
|
||||
left: 10%;
|
||||
width: 80%;
|
||||
height: 2px;
|
||||
background-color: white;
|
||||
}
|
||||
|
||||
&:before {
|
||||
transform: rotate(45deg);
|
||||
}
|
||||
|
||||
&:after {
|
||||
transform: rotate(-45deg);
|
||||
}
|
||||
|
||||
&:hover {
|
||||
border-color: white;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// KubeWeekly
|
||||
#kubeweekly {
|
||||
background-color: $light-grey;
|
||||
padding-top: 30px;
|
||||
padding-bottom: 80px;
|
||||
background-size: auto;
|
||||
// font-family: "Roboto Mono", monospace !important;
|
||||
font-size: 24px;
|
||||
// font-weight: bold;
|
||||
|
||||
h5 {
|
||||
font-size: 20px;
|
||||
}
|
||||
}
|
||||
|
||||
.subscribe-button {
|
||||
border-radius: 6px;
|
||||
padding: 0 20px;
|
||||
line-height: 31px;
|
||||
color: white;
|
||||
background-color: blue;
|
||||
text-decoration: none;
|
||||
font-size: 14px;
|
||||
}
|
||||
|
||||
// Features
|
||||
#features {
|
||||
padding-top: 140px;
|
||||
background-color: $light-grey;
|
||||
background-image: url(/images/wheel.svg);
|
||||
background-position: center 60px;
|
||||
background-repeat: no-repeat;
|
||||
background-size: 60px;
|
||||
}
|
||||
|
||||
.feature-box {
|
||||
//padding: 50px 0
|
||||
width: 100%;
|
||||
overflow: hidden;
|
||||
clear: both;
|
||||
|
||||
h4 {
|
||||
line-height: normal;
|
||||
margin-bottom: 15px;
|
||||
}
|
||||
|
||||
& > div:first-child {
|
||||
float: left;
|
||||
}
|
||||
|
||||
& > div:last-child {
|
||||
float: right;
|
||||
}
|
||||
}
|
||||
|
||||
#features {
|
||||
h3 {
|
||||
margin-bottom: $features-h3-margin-bottom;
|
||||
}
|
||||
|
||||
.feature-box {
|
||||
margin-bottom: $feature-box-margin-bottom;
|
||||
|
||||
& > div {
|
||||
width: $feature-box-div-width;
|
||||
margin-bottom: $feature-box-div-margin-bottom;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Talk to us
|
||||
#talkToUs {
|
||||
h3,
|
||||
h4 {
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
h3 {
|
||||
margin-bottom: 15px;
|
||||
}
|
||||
|
||||
h4 {
|
||||
line-height: normal;
|
||||
margin-bottom: 50px;
|
||||
|
||||
br {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
#bigSocial {
|
||||
overflow: hidden;
|
||||
|
||||
div {
|
||||
width: 100%;
|
||||
float: left;
|
||||
padding: 30px;
|
||||
padding-top: 110px;
|
||||
background-position: center top;
|
||||
background-size: auto;
|
||||
background-repeat: no-repeat;
|
||||
}
|
||||
|
||||
div:nth-child(1) {
|
||||
background-image: url(/images/twitter_icon.png);
|
||||
}
|
||||
|
||||
div:nth-child(2) {
|
||||
background-image: url(/images/github_icon.png);
|
||||
}
|
||||
|
||||
div:nth-child(3) {
|
||||
background-image: url(/images/slack_icon.png);
|
||||
}
|
||||
|
||||
div:nth-child(4) {
|
||||
background-image: url(/images/stackoverflow_icon.png);
|
||||
}
|
||||
|
||||
div + div {
|
||||
margin-top: 20px;
|
||||
margin-left: 0;
|
||||
}
|
||||
|
||||
a {
|
||||
display: inline-block;
|
||||
color: $blue;
|
||||
font-size: 24px;
|
||||
font-weight: 400;
|
||||
text-decoration: none;
|
||||
margin-bottom: 15px;
|
||||
}
|
||||
|
||||
a,
|
||||
p {
|
||||
text-align: center;
|
||||
width: 100%;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.td-home {
|
||||
#talkToUs {
|
||||
.main-section {
|
||||
padding: 30px 0;
|
||||
}
|
||||
|
||||
h5 {
|
||||
font-size: 20px;
|
||||
}
|
||||
}
|
||||
|
||||
#caseStudiesWrapper {
|
||||
position: relative;
|
||||
text-align: center;
|
||||
margin-bottom: 30px;
|
||||
|
||||
img {
|
||||
padding-bottom: 1rem;
|
||||
}
|
||||
|
||||
div {
|
||||
position: relative;
|
||||
display: inline-block;
|
||||
vertical-align: top;
|
||||
width: 100%;
|
||||
min-height: 230px;
|
||||
margin-bottom: 60px;
|
||||
padding-right: 1rem;
|
||||
background-position: top center;
|
||||
}
|
||||
|
||||
p {
|
||||
font-size: 20px;
|
||||
}
|
||||
|
||||
a {
|
||||
position: absolute;
|
||||
bottom: -30px;
|
||||
left: 50%;
|
||||
transform: translateX(-50%);
|
||||
color: $blue;
|
||||
font-weight: 400;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Docs specific
|
||||
|
||||
#editPageButton {
|
||||
position: absolute;
|
||||
top: 50px;
|
||||
right: 25px;
|
||||
width: 50px;
|
||||
height: 50px;
|
||||
line-height: 50px;
|
||||
border-radius: 50%;
|
||||
white-space: nowrap;
|
||||
text-indent: 50px;
|
||||
overflow: hidden;
|
||||
background: $blue url(/images/icon-pencil.svg) no-repeat;
|
||||
background-position: 12px 10px;
|
||||
background-size: 29px 29px;
|
||||
}
|
||||
|
||||
.feedback--response__hidden {
|
||||
display: none;
|
||||
}
|
||||
|
||||
// GitHub info/edit buttons
|
||||
#pre-footer {
|
||||
margin-top: 2rem;
|
||||
|
||||
.button {
|
||||
font-size: 1.1rem;
|
||||
|
||||
&:first-of-type {
|
||||
margin-right: 0.75rem;
|
||||
}
|
||||
}
|
||||
|
||||
.lastedit {
|
||||
margin-top: 1rem;
|
||||
font-size: 1rem;
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,142 @@
|
||||
// SASS for Case Studies pages go here:
|
||||
|
||||
hr {
|
||||
background-color: #999999;
|
||||
}
|
||||
|
||||
h2 {
|
||||
margin-bottom: 15px !important;
|
||||
}
|
||||
|
||||
.subhead {
|
||||
padding-bottom: 2% !important;
|
||||
padding-top: 0% !important;
|
||||
}
|
||||
|
||||
.details {
|
||||
margin-left: 1.9%;
|
||||
padding-right: 5%;
|
||||
font-size: 16px !important;
|
||||
padding-bottom: 2% !important;
|
||||
}
|
||||
|
||||
.section1 {
|
||||
margin-bottom: 3%;
|
||||
|
||||
.cols {
|
||||
width: 80% !important;
|
||||
margin-left: 6.8%;
|
||||
padding-top: 1.5%;
|
||||
|
||||
.col1 {
|
||||
width: 52% !important;
|
||||
font-weight: 300 !important;
|
||||
}
|
||||
|
||||
.col2 {
|
||||
width: 46% !important;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.banner2text {
|
||||
width: 63%;
|
||||
padding-top: 10%;
|
||||
padding-left: 0% !important;
|
||||
float: initial !important;
|
||||
text-align: center;
|
||||
margin: 0 auto;
|
||||
position: relative;
|
||||
}
|
||||
|
||||
.banner3text,
|
||||
.banner4text,
|
||||
.banner5text {
|
||||
width: 63%;
|
||||
padding-left: 0% !important;
|
||||
float: initial !important;
|
||||
text-align: center;
|
||||
margin: 0 auto;
|
||||
position: relative;
|
||||
}
|
||||
|
||||
.fullcol {
|
||||
float: initial !important;
|
||||
}
|
||||
|
||||
body footer {
|
||||
background-color: #585858 !important;
|
||||
}
|
||||
|
||||
.section1 {
|
||||
float: left !important;
|
||||
}
|
||||
|
||||
.banner1 {
|
||||
padding-left: 11.9% !important;
|
||||
}
|
||||
|
||||
.banner2 {
|
||||
float: initial !important;
|
||||
padding-bottom: 2% !important;
|
||||
}
|
||||
|
||||
footer {
|
||||
padding: 0% 7%;
|
||||
}
|
||||
|
||||
.banner4,
|
||||
.banner3,
|
||||
.banner5 {
|
||||
float: initial !important;
|
||||
}
|
||||
|
||||
@media screen and (max-width: 910px) {
|
||||
.banner2text {
|
||||
width: 47%;
|
||||
padding-top: 45%;
|
||||
}
|
||||
|
||||
.details {
|
||||
margin-left: 0%;
|
||||
margin-bottom: 3%;
|
||||
}
|
||||
|
||||
.subhead {
|
||||
padding-bottom: 0% !important;
|
||||
padding-top: 0% !important;
|
||||
}
|
||||
|
||||
.banner3 {
|
||||
width: 100% !important;
|
||||
}
|
||||
}
|
||||
|
||||
@media screen and (max-width: 780px) {
|
||||
.section1 .cols {
|
||||
width: 100% !important;
|
||||
margin-left: 0%;
|
||||
padding-top: 5%;
|
||||
|
||||
.col1,
|
||||
.col2 {
|
||||
width: 100% !important;
|
||||
margin-left: 0% !important;
|
||||
|
||||
.fullcol {
|
||||
width: 90% !important;
|
||||
margin-left: 5% !important;
|
||||
|
||||
.banner1 {
|
||||
padding-left: 10% !important;
|
||||
margin-bottom: 6% !important;
|
||||
|
||||
.banner2text {
|
||||
padding-top: 60% !important;
|
||||
padding-bottom: 2% !important;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,393 @@
|
||||
/* GLOBAL */
|
||||
.td-main {
|
||||
.row {
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
main {
|
||||
img {
|
||||
max-width: 100%;
|
||||
}
|
||||
|
||||
table {
|
||||
margin-bottom: 1rem;
|
||||
display: initial;
|
||||
}
|
||||
|
||||
@media only screen and (min-width: 768px) {
|
||||
padding-top: 2rem !important;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
section {
|
||||
.main-section {
|
||||
@media only screen and (min-width: 1024px) {
|
||||
max-width: 1200px;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.td-outer {
|
||||
padding: 0 !important;
|
||||
}
|
||||
|
||||
#desktopShowVideoButton {
|
||||
border: none
|
||||
}
|
||||
|
||||
#videoPlayer {
|
||||
#closeButton {
|
||||
background: transparent;
|
||||
}
|
||||
}
|
||||
|
||||
/* HEADER */
|
||||
|
||||
.td-navbar {
|
||||
position: fixed !important;
|
||||
width: 100%;
|
||||
padding-bottom: 1rem !important;
|
||||
background: transparent !important;
|
||||
transition: 0.3s;
|
||||
|
||||
.navbar-brand {
|
||||
position: absolute;
|
||||
width: 45px;
|
||||
height: 44px;
|
||||
background-repeat: no-repeat;
|
||||
background-size: contain;
|
||||
background-image: url("/images/favicon.png");
|
||||
}
|
||||
|
||||
#hamburger {
|
||||
&:focus {
|
||||
outline: none;
|
||||
}
|
||||
}
|
||||
|
||||
@media only screen and (min-width: 768px) {
|
||||
.navbar-brand {
|
||||
background-image: url("/images/nav_logo.svg");
|
||||
top: 1.5rem;
|
||||
width: 180px;
|
||||
margin-left: 1rem;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.td-navbar-nav-scroll {
|
||||
overflow: visible !important;
|
||||
display: none;
|
||||
|
||||
.navbar-nav {
|
||||
overflow: visible !important;
|
||||
position: relative;
|
||||
display: flex;
|
||||
flex-direction: row;
|
||||
flex-wrap: wrap;
|
||||
justify-content: space-evenly;
|
||||
|
||||
.nav-item {
|
||||
position: relative;
|
||||
height: 10%;
|
||||
|
||||
.active::after {
|
||||
position: absolute;
|
||||
width: 100%;
|
||||
height: 2px;
|
||||
content: "";
|
||||
bottom: -4px;
|
||||
left: 0;
|
||||
background: #fff;
|
||||
}
|
||||
|
||||
.dropdown-menu {
|
||||
left: -80px;
|
||||
}
|
||||
|
||||
&.dropdown:hover {
|
||||
color: $medium-grey;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@media only screen and (min-width: 768px) {
|
||||
display: block;
|
||||
margin-top: 3.5rem !important;
|
||||
}
|
||||
|
||||
@media only screen and (min-width: 1075px) {
|
||||
margin-top: 1.5rem !important;
|
||||
}
|
||||
}
|
||||
|
||||
// Flip-Nav
|
||||
.flip-nav .td-navbar {
|
||||
background-color: white !important;
|
||||
box-shadow: 0 1px 2px $medium-grey;
|
||||
|
||||
.navbar-nav {
|
||||
.nav-item {
|
||||
&.show .nav-link,
|
||||
.nav-link {
|
||||
color: $dark-grey;
|
||||
|
||||
&:hover {
|
||||
color: $medium-grey;
|
||||
}
|
||||
}
|
||||
|
||||
.dropdown {
|
||||
&:hover {
|
||||
color: $medium-grey;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.navbar-nav .nav-item .active {
|
||||
color: $dark-grey;
|
||||
|
||||
&::after {
|
||||
background: $dark-grey;
|
||||
}
|
||||
}
|
||||
|
||||
#hamburger:hover {
|
||||
div,
|
||||
&:before,
|
||||
&:after {
|
||||
background-color: $dark-grey;
|
||||
}
|
||||
}
|
||||
|
||||
@media only screen and (min-width: 768px) {
|
||||
.navbar-brand {
|
||||
background-image: url("/images/nav_logo2.svg");
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/* FOOTER */
|
||||
footer {
|
||||
background-color: #303030;
|
||||
background-image: url("/images/texture.png");
|
||||
padding: 1rem !important;
|
||||
min-height: initial !important;
|
||||
|
||||
.footer__links {
|
||||
width: 100%;
|
||||
margin: auto;
|
||||
padding-bottom: 1rem;
|
||||
|
||||
nav a {
|
||||
display: block;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
@media only screen and (min-width: 768px) {
|
||||
nav {
|
||||
display: flex;
|
||||
flex-direction: row;
|
||||
justify-content: space-around;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
small {
|
||||
color: $light-grey;
|
||||
font-size: 0.64rem;
|
||||
|
||||
a {
|
||||
text-decoration: inherit;
|
||||
color: inherit;
|
||||
|
||||
&:hover {
|
||||
color: inherit;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/* SIDE-DRAWER MENU */
|
||||
|
||||
.pi-pushmenu .sled {
|
||||
.content ul {
|
||||
padding: 0;
|
||||
|
||||
li {
|
||||
&:first-child {
|
||||
display: none;
|
||||
}
|
||||
|
||||
a.nav-link {
|
||||
padding: 0;
|
||||
}
|
||||
}
|
||||
}
|
||||
.push-menu-close-button {
|
||||
background: transparent;
|
||||
border: none;
|
||||
|
||||
&:focus {
|
||||
outline: none;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/* DOCS */
|
||||
|
||||
.launch-cards {
|
||||
button {
|
||||
cursor: pointer;
|
||||
box-sizing: border-box;
|
||||
background: none;
|
||||
margin: 0;
|
||||
border: 0;
|
||||
}
|
||||
|
||||
ul,
|
||||
li {
|
||||
list-style: none;
|
||||
padding-left: 0;
|
||||
}
|
||||
}
|
||||
|
||||
// table of contents
|
||||
.td-toc {
|
||||
padding-top: 1.5rem !important;
|
||||
top: 5rem !important;
|
||||
|
||||
#TableOfContents {
|
||||
padding-top: 1rem;
|
||||
}
|
||||
}
|
||||
|
||||
// blockquotes and callouts
|
||||
|
||||
blockquote {
|
||||
padding: 0.4rem 0.4rem 0.4rem 1rem !important;
|
||||
}
|
||||
|
||||
// callouts are contained in static CSS as well. these require override.
|
||||
|
||||
.caution {
|
||||
border-left-color: #f0ad4e !important;
|
||||
}
|
||||
|
||||
.note {
|
||||
border-left-color: #428bca !important;
|
||||
}
|
||||
|
||||
.warning {
|
||||
border-left-color: #d9534f !important;
|
||||
}
|
||||
|
||||
// search & sidebar
|
||||
.td-sidebar {
|
||||
@media only screen and (min-width: 768px) {
|
||||
padding-top: 1.5rem !important;
|
||||
|
||||
.td-sidebar__inner {
|
||||
top: 8.5rem;
|
||||
|
||||
@media only screen and (min-width: 1075px) {
|
||||
top: 6.5rem;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.td-sidebar-nav {
|
||||
& > .td-sidebar-nav__section {
|
||||
padding-top: .5rem;
|
||||
padding-left: 1.5rem;
|
||||
}
|
||||
}
|
||||
|
||||
.td-sidebar__inner {
|
||||
form.td-sidebar__search {
|
||||
|
||||
button.td-sidebar__toggle {
|
||||
&:hover {
|
||||
color: #000000;
|
||||
}
|
||||
|
||||
color: $blue;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.no-underline {
|
||||
text-decoration: none !important;
|
||||
}
|
||||
|
||||
.hide {
|
||||
display: none !important;
|
||||
}
|
||||
|
||||
.td-sidebar-link__page {
|
||||
&#m-docs-search {
|
||||
display: none;
|
||||
}
|
||||
|
||||
&#m-docs-test {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
//Tutorials
|
||||
main.content {
|
||||
position: inherit;
|
||||
}
|
||||
|
||||
/* BLOG */
|
||||
|
||||
.td-blog {
|
||||
|
||||
.td-sidebar-nav {
|
||||
max-height: calc(100vh - 8rem);
|
||||
}
|
||||
|
||||
.widget-link {
|
||||
margin-bottom: 1rem;
|
||||
|
||||
.svg-inline--fa {
|
||||
width: 25px;
|
||||
}
|
||||
|
||||
span {
|
||||
margin-left: 0.5rem;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/* COMMUNITY */
|
||||
|
||||
.newcommunitywrapper {
|
||||
.news {
|
||||
margin-left: 0;
|
||||
|
||||
@media screen and (min-width: 768px) {
|
||||
margin-left: 10%;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/* CASE-STUDIES */
|
||||
|
||||
// Many of the case studies have small variations in markup and styles;
|
||||
// some issues cannot be addressed due to inlined !important rules.
|
||||
#caseStudies {
|
||||
section .cols {
|
||||
margin-left: 11%;
|
||||
|
||||
div {
|
||||
width: initial !important;
|
||||
h2 {
|
||||
margin-top: 1rem;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,99 @@
|
||||
$main-max-width: 1200px;
|
||||
$vendor-strip-height: 44px;
|
||||
$video-section-height: 550px;
|
||||
|
||||
@media screen and (min-width: 1024px) {
|
||||
|
||||
.td-home {
|
||||
.header-hero {
|
||||
#vendorStrip {
|
||||
display: block;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.td-home {
|
||||
|
||||
section,
|
||||
header,
|
||||
footer {
|
||||
.main-section {
|
||||
max-width: 1000px;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
#oceanNodes {
|
||||
.main-section {
|
||||
position: relative;
|
||||
|
||||
&:nth-child(1) {
|
||||
max-width: 1000px;
|
||||
padding-right: 475px;
|
||||
|
||||
h3,
|
||||
p {
|
||||
text-align: left
|
||||
}
|
||||
|
||||
.image-wrapper {
|
||||
position: absolute;
|
||||
max-width: 48%;
|
||||
transform: translateY(-50%);
|
||||
}
|
||||
|
||||
img {
|
||||
width: 425px;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
#video {
|
||||
height: $video-section-height;
|
||||
position: relative;
|
||||
background-position: center center;
|
||||
background-size: cover;
|
||||
|
||||
&>.light-text {
|
||||
margin-right: 10%;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
#talkToUs {
|
||||
h4 {
|
||||
br {
|
||||
display: block;
|
||||
}
|
||||
}
|
||||
|
||||
#bigSocial {
|
||||
div {
|
||||
width: calc(25% - 18px);
|
||||
}
|
||||
|
||||
div+div {
|
||||
margin-left: 20px;
|
||||
}
|
||||
}
|
||||
|
||||
.td-home #bigSocial {
|
||||
div {
|
||||
width: calc(33% - 15px);
|
||||
}
|
||||
|
||||
div:nth-child(3) {
|
||||
margin-top: inherit;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.td-home #caseStudiesWrapper {
|
||||
div {
|
||||
width: 24%;
|
||||
min-height: 260px;
|
||||
}
|
||||
}
|
||||
}
|
||||
Executable
+49
@@ -0,0 +1,49 @@
|
||||
// CONVENIENCE
|
||||
.clear {
|
||||
display: block;
|
||||
clear: both;
|
||||
}
|
||||
|
||||
.light-text {
|
||||
color: white;
|
||||
}
|
||||
|
||||
.right {
|
||||
float: right;
|
||||
}
|
||||
|
||||
.left {
|
||||
float: left;
|
||||
}
|
||||
|
||||
.center {
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
//mixins
|
||||
@mixin fullScreen {
|
||||
position: fixed;
|
||||
top: 0;
|
||||
left: 0;
|
||||
width: 100vw;
|
||||
height: 100vh;
|
||||
}
|
||||
|
||||
@mixin pureCenter($left: 50%, $top: 50%) {
|
||||
position: absolute;
|
||||
top: $top;
|
||||
left: $left;
|
||||
transform: translate(-50%, -50%);
|
||||
}
|
||||
|
||||
@mixin maintain-aspect-ratio(
|
||||
$width-factor: 16,
|
||||
$height-factor: 9,
|
||||
$target-width: 80vw,
|
||||
$target-height: 80vh
|
||||
) {
|
||||
width: $target-width;
|
||||
height: $target-width * ($height-factor / $width-factor);
|
||||
max-width: $target-height * ($width-factor / $height-factor);
|
||||
max-height: $target-height;
|
||||
}
|
||||
@@ -0,0 +1,20 @@
|
||||
section,
|
||||
#vendorStrip {
|
||||
padding-left: $full-width-paddingX;
|
||||
padding-right: $full-width-paddingX;
|
||||
}
|
||||
|
||||
#hamburger {
|
||||
width: $hamburger-size;
|
||||
height: $hamburger-size;
|
||||
}
|
||||
|
||||
.header-hero {
|
||||
padding-top: $hero-padding-top;
|
||||
}
|
||||
|
||||
#vendorStrip {
|
||||
height: $vendor-strip-height;
|
||||
line-height: $vendor-strip-height;
|
||||
font-size: $vendor-strip-font-size;
|
||||
}
|
||||
Executable
+5
@@ -0,0 +1,5 @@
|
||||
$blue: #3371e3;
|
||||
$light-grey: #f7f7f7;
|
||||
$dark-grey: #303030;
|
||||
$medium-grey: #4c4c4c;
|
||||
$white: #ffffff;
|
||||
@@ -0,0 +1,211 @@
|
||||
// header
|
||||
$full-width-paddingX: 20px;
|
||||
|
||||
$main-width: 100%;
|
||||
$main-max-width: 100%;
|
||||
|
||||
$header-height: 80px;
|
||||
|
||||
$logo-width: 180px;
|
||||
|
||||
$nav-buttons-margin-left: 30px;
|
||||
|
||||
$hamburger-size: 50px;
|
||||
|
||||
// main nav
|
||||
$main-nav-padding: 140px 0 30px;
|
||||
$main-nav-h5-margin-bottom: 1em;
|
||||
$main-nav-h3-margin-bottom: 0.6em;
|
||||
$nav-box-width: 20%;
|
||||
$nav-box-sibling-margin-left: calc(20% / 3);
|
||||
$main-nav-main-sibling-margin-top: 60px;
|
||||
$main-nav-left-button-size: 50px;
|
||||
$main-nav-left-button-font-size: 18px;
|
||||
|
||||
// hero
|
||||
$hero-padding-top: 136px;
|
||||
$headline-wrapper-margin-bottom: 40px;
|
||||
$quickstart-button-padding: 0 50px;
|
||||
$vendor-strip-font-size: 16px;
|
||||
|
||||
//video
|
||||
$video-section-height: 400px;
|
||||
|
||||
//features
|
||||
$features-h3-margin-bottom: 40px;
|
||||
$feature-box-margin-bottom: 60px;
|
||||
$feature-box-div-margin-bottom: 0;
|
||||
$feature-box-div-width: 45%;
|
||||
|
||||
////////////////////////////////////////////////////////////////////////////////////////////////////
|
||||
////////////////////////////////////////////////////////////////////////////////////////////////////
|
||||
////////////////////////////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
@media screen and (min-width: 768px) {
|
||||
@import "size";
|
||||
|
||||
#hamburger {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.td-home {
|
||||
#viewDocs,
|
||||
#tryKubernetes {
|
||||
display: inline-block;
|
||||
}
|
||||
}
|
||||
|
||||
#vendorStrip {
|
||||
display: block;
|
||||
text-align: center;
|
||||
|
||||
img {
|
||||
max-height: 24px;
|
||||
vertical-align: middle;
|
||||
margin: 0 30px;
|
||||
}
|
||||
}
|
||||
|
||||
#oceanNodes {
|
||||
h3 {
|
||||
text-align: left;
|
||||
margin-bottom: 18px;
|
||||
}
|
||||
|
||||
main,
|
||||
.main-section {
|
||||
position: relative;
|
||||
clear: both;
|
||||
display: table;
|
||||
height: 160px;
|
||||
|
||||
.content {
|
||||
display: table-cell;
|
||||
position: relative;
|
||||
vertical-align: middle;
|
||||
}
|
||||
|
||||
.image-wrapper {
|
||||
position: absolute;
|
||||
top: 50%;
|
||||
max-width: 25%;
|
||||
max-height: 100%;
|
||||
transform: translateY(-50%);
|
||||
}
|
||||
|
||||
&:nth-child(odd) {
|
||||
padding-right: 210px;
|
||||
|
||||
.image-wrapper {
|
||||
right: 0;
|
||||
}
|
||||
}
|
||||
|
||||
&:nth-child(even) {
|
||||
padding-left: 210px;
|
||||
|
||||
.image-wrapper {
|
||||
left: 0;
|
||||
}
|
||||
}
|
||||
|
||||
&:nth-child(1) {
|
||||
padding-right: 0;
|
||||
|
||||
h3,
|
||||
p {
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.image-wrapper {
|
||||
position: relative;
|
||||
display: block;
|
||||
float: none;
|
||||
max-width: 100%;
|
||||
transform: none;
|
||||
}
|
||||
|
||||
.content {
|
||||
display: block;
|
||||
}
|
||||
}
|
||||
|
||||
img {
|
||||
width: 100%;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
#video {
|
||||
height: $video-section-height;
|
||||
display: block;
|
||||
height: 500px;
|
||||
|
||||
& > .light-text {
|
||||
display: block;
|
||||
float: right;
|
||||
text-align: left;
|
||||
margin-right: 5%;
|
||||
}
|
||||
}
|
||||
|
||||
#mobileShowVideoButton {
|
||||
display: none;
|
||||
}
|
||||
|
||||
#features {
|
||||
padding-bottom: 60px;
|
||||
|
||||
.feature-box {
|
||||
margin-bottom: 30px;
|
||||
|
||||
&:last-child {
|
||||
margin-bottom: 0;
|
||||
}
|
||||
}
|
||||
|
||||
h3 {
|
||||
margin-bottom: $features-h3-margin-bottom;
|
||||
}
|
||||
|
||||
.feature-box {
|
||||
& > div {
|
||||
width: $feature-box-div-width;
|
||||
margin-bottom: $feature-box-div-margin-bottom;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
#talkToUs {
|
||||
#bigSocial {
|
||||
div {
|
||||
width: calc(50% - 15px);
|
||||
}
|
||||
|
||||
div + div {
|
||||
margin-top: 0;
|
||||
}
|
||||
|
||||
div:nth-child(2) {
|
||||
margin-left: 20px;
|
||||
}
|
||||
|
||||
div:nth-child(4) {
|
||||
margin-left: 20px;
|
||||
}
|
||||
|
||||
a {
|
||||
display: inline-block;
|
||||
color: $blue;
|
||||
font-weight: 400;
|
||||
text-decoration: none;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.td-home #caseStudiesWrapper {
|
||||
div {
|
||||
width: 48%;
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,13 @@
|
||||
/* This file is provided by Docsy as an entry point to styling.
|
||||
Add styles or override variables from the theme here. */
|
||||
|
||||
@import "reset";
|
||||
@import "skin";
|
||||
|
||||
//K8S-Docsy integration
|
||||
@import "custom";
|
||||
|
||||
//Media queries
|
||||
@import "base";
|
||||
@import "tablet";
|
||||
@import "desktop";
|
||||
+139
-7
@@ -1,6 +1,11 @@
|
||||
baseURL = "https://kubernetes.io"
|
||||
title = "Kubernetes"
|
||||
|
||||
# Hugo allows theme composition (and inheritance). The precedence is from left to right.
|
||||
theme = ["docsy"]
|
||||
|
||||
# Language settings
|
||||
contentDir = "content/en"
|
||||
defaultContentLanguage = "en"
|
||||
defaultContentLanguageInSubdir = false
|
||||
enableRobotsTXT = true
|
||||
@@ -10,10 +15,17 @@ disableKinds = ["taxonomy", "taxonomyTerm"]
|
||||
|
||||
ignoreFiles = [ "^OWNERS$", "README[-]+[a-z]*\\.md", "^node_modules$", "content/en/docs/doc-contributor-tools" ]
|
||||
|
||||
contentDir = "content/en"
|
||||
|
||||
timeout = 3000
|
||||
|
||||
# Highlighting config.
|
||||
pygmentsCodeFences = true
|
||||
pygmentsUseClasses = false
|
||||
# Use the new Chroma Go highlighter in Hugo.
|
||||
pygmentsUseClassic = false
|
||||
#pygmentsOptions = "linenos=table"
|
||||
# See https://help.farbox.com/pygments.html
|
||||
pygmentsStyle = "emacs"
|
||||
|
||||
# Enable Git variables like commit, lastmod
|
||||
enableGitInfo = true
|
||||
|
||||
@@ -23,6 +35,14 @@ disableLanguages = ["hi", "no"]
|
||||
|
||||
[markup]
|
||||
[markup.goldmark]
|
||||
[markup.goldmark.extensions]
|
||||
definitionList = true
|
||||
table = true
|
||||
typographer = false
|
||||
[markup.goldmark.parser]
|
||||
attribute = true
|
||||
autoHeadingID = true
|
||||
autoHeadingIDType = "blackfriday"
|
||||
[markup.goldmark.renderer]
|
||||
unsafe = true
|
||||
[markup.highlight]
|
||||
@@ -35,6 +55,10 @@ disableLanguages = ["hi", "no"]
|
||||
noClasses = true
|
||||
style = "emacs"
|
||||
tabWidth = 4
|
||||
[markup.tableOfContents]
|
||||
endLevel = 3
|
||||
ordered = false
|
||||
startLevel = 2
|
||||
|
||||
[frontmatter]
|
||||
date = ["date", ":filename", "publishDate", "lastmod"]
|
||||
@@ -64,7 +88,28 @@ baseName = "_headers"
|
||||
isPlainText = true
|
||||
notAlternative = true
|
||||
|
||||
# Image processing configuration.
|
||||
[imaging]
|
||||
resampleFilter = "CatmullRom"
|
||||
quality = 75
|
||||
anchor = "smart"
|
||||
|
||||
[services]
|
||||
[services.googleAnalytics]
|
||||
# Comment out the next line to disable GA tracking. Also disables the feature described in [params.ui.feedback].
|
||||
id = "UA-00000000-0"
|
||||
|
||||
[params]
|
||||
copyright_k8s = "The Kubernetes Authors"
|
||||
copyright_linux = "Copyright © 2020 The Linux Foundation ®."
|
||||
# privacy_policy = "https://policies.google.com/privacy"
|
||||
|
||||
# First one is picked as the Twitter card image if not set on page.
|
||||
# images = ["images/project-illustration.png"]
|
||||
|
||||
# Menu title if your navbar has a versions selector to access old versions of your site.
|
||||
# This menu appears only if you have at least one [params.versions] set.
|
||||
version_menu = "Versions"
|
||||
|
||||
time_format_blog = "Monday, January 02, 2006"
|
||||
description = "Production-Grade Container Orchestration"
|
||||
@@ -82,11 +127,24 @@ nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"
|
||||
githubWebsiteRepo = "github.com/kubernetes/website"
|
||||
githubWebsiteRaw = "raw.githubusercontent.com/kubernetes/website"
|
||||
|
||||
# param for displaying an announcement block on every page; see PR #16210
|
||||
announcement = false
|
||||
# announcement_message is only displayed when announcement = true; update with your specific message
|
||||
announcement_message = "The Kubernetes Documentation team would like your feedback! Please take a <a href='https://www.surveymonkey.com/r/8R237FN' target='_blank'>short survey</a> so we can improve the Kubernetes online documentation."
|
||||
# param for displaying an announcement block on every page.
|
||||
# See /i18n/en.toml for message text and title.
|
||||
announcement = true
|
||||
announcement_bg = "#000000" #choose a dark color – text is white
|
||||
|
||||
#Searching
|
||||
k8s_search = true
|
||||
|
||||
#The following search parameters are specific to Docsy's implementation. Kubernetes implementes its own search-related partials and scripts.
|
||||
|
||||
# Google Custom Search Engine ID. Remove or comment out to disable search.
|
||||
#gcs_engine_id = "011737558837375720776:fsdu1nryfng"
|
||||
|
||||
# Enable Algolia DocSearch
|
||||
algolia_docsearch = false
|
||||
|
||||
# Enable Lunr.js offline search
|
||||
offlineSearch = false
|
||||
|
||||
[params.pushAssets]
|
||||
css = [
|
||||
@@ -134,6 +192,80 @@ githubbranch = "v1.14.10"
|
||||
docsbranch = "release-1.14"
|
||||
url = "https://v1-14.docs.kubernetes.io"
|
||||
|
||||
# User interface configuration
|
||||
[params.ui]
|
||||
# Enable to show the side bar menu in its compact state.
|
||||
sidebar_menu_compact = false
|
||||
# Set to true to disable breadcrumb navigation.
|
||||
breadcrumb_disable = false
|
||||
# Set to true to hide the sidebar search box (the top nav search box will still be displayed if search is enabled)
|
||||
sidebar_search_disable = false
|
||||
# Set to false if you don't want to display a logo (/assets/icons/logo.svg) in the top nav bar
|
||||
navbar_logo = true
|
||||
# Set to true to disable the About link in the site footer
|
||||
footer_about_disable = false
|
||||
|
||||
# Adds a H2 section titled "Feedback" to the bottom of each doc. The responses are sent to Google Analytics as events.
|
||||
# This feature depends on [services.googleAnalytics] and will be disabled if "services.googleAnalytics.id" is not set.
|
||||
# If you want this feature, but occasionally need to remove the "Feedback" section from a single page,
|
||||
# add "hide_feedback: true" to the page's front matter.
|
||||
[params.ui.feedback]
|
||||
enable = true
|
||||
# The responses that the user sees after clicking "yes" (the page was helpful) or "no" (the page was not helpful).
|
||||
yes = 'Glad to hear it! Please <a href="https://github.com/USERNAME/REPOSITORY/issues/new">tell us how we can improve</a>.'
|
||||
no = 'Sorry to hear that. Please <a href="https://github.com/USERNAME/REPOSITORY/issues/new">tell us how we can improve</a>.'
|
||||
|
||||
[params.links]
|
||||
# End user relevant links. These will show up on left side of footer and in the community page if you have one.
|
||||
[[params.links.user]]
|
||||
name = "User mailing list"
|
||||
url = "https://discuss.kubernetes.io"
|
||||
icon = "fa fa-envelope"
|
||||
desc = "Discussion and help from your fellow users"
|
||||
|
||||
[[params.links.user]]
|
||||
name = "Twitter"
|
||||
url = "https://twitter.com/kubernetesio"
|
||||
icon = "fab fa-twitter"
|
||||
desc = "Follow us on Twitter to get the latest news!"
|
||||
|
||||
[[params.links.user]]
|
||||
name = "Calendar"
|
||||
url = "https://calendar.google.com/calendar/embed?src=nt2tcnbtbied3l6gi2h29slvc0%40group.calendar.google.com"
|
||||
icon = "fas fa-calendar-alt"
|
||||
desc = "Google Calendar for Kubernetes"
|
||||
|
||||
[[params.links.user]]
|
||||
name = "Youtube"
|
||||
url = "https://youtube.com/kubernetescommunity"
|
||||
icon = "fab fa-youtube"
|
||||
desc = "Youtube community videos"
|
||||
|
||||
# Developer relevant links. These will show up on right side of footer and in the community page if you have one.
|
||||
[[params.links.developer]]
|
||||
name = "GitHub"
|
||||
url = "https://github.com/kubernetes/kubernetes"
|
||||
icon = "fab fa-github"
|
||||
desc = "Development takes place here!"
|
||||
|
||||
[[params.links.developer]]
|
||||
name = "Slack"
|
||||
url = "https://slack.k8s.io"
|
||||
icon = "fab fa-slack"
|
||||
desc = "Chat with other project developers"
|
||||
|
||||
[[params.links.developer]]
|
||||
name = "Contribute"
|
||||
url = "https://git.k8s.io/community/contributors/guide"
|
||||
icon = "fas fa-edit"
|
||||
desc = "Contribute to the Kubernetes website"
|
||||
|
||||
[[params.links.developer]]
|
||||
name = "Stack Overflow"
|
||||
url = "https://stackoverflow.com/questions/tagged/kubernetes"
|
||||
icon = "fab fa-stack-overflow"
|
||||
desc = "Practical questions and curated answers"
|
||||
|
||||
# Language definitions.
|
||||
|
||||
[languages]
|
||||
@@ -313,4 +445,4 @@ contentDir = "content/uk"
|
||||
[languages.uk.params]
|
||||
time_format_blog = "02.01.2006"
|
||||
# A list of language codes to look for untranslated content, ordered from left to right.
|
||||
language_alternatives = ["en"]
|
||||
language_alternatives = ["en"]
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
---
|
||||
title: Konzepte
|
||||
main_menu: true
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Im Abschnitt Konzepte erfahren Sie mehr über die Bestandteile des Kubernetes-Systems und die Abstraktionen, die Kubernetes zur Verwaltung Ihres Clusters zur Verfügung stellt. Sie erhalten zudem ein tieferes Verständnis der Funktionsweise von Kubernetes.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Überblick
|
||||
|
||||
@@ -65,11 +65,12 @@ Die Nodes in einem Cluster sind die Maschinen (VMs, physische Server usw.), auf
|
||||
|
||||
* [Anmerkungen](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Wenn Sie eine Konzeptseite schreiben möchten, lesen Sie [Seitenvorlagen verwenden](/docs/home/contribute/page-templates/)
|
||||
für Informationen zum Konzeptseitentyp und zur Dokumentations Vorlage.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: Zugrunde liegende Konzepte des Cloud Controller Manager
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
Das Konzept des Cloud Controller Managers (CCM) (nicht zu verwechseln mit der Binärdatei) wurde ursprünglich entwickelt, um Cloud-spezifischen Anbieter Code und den Kubernetes Kern unabhängig voneinander entwickeln zu können. Der Cloud Controller Manager läuft zusammen mit anderen Master Komponenten wie dem Kubernetes Controller Manager, dem API-Server und dem Scheduler auf dem Host. Es kann auch als Kubernetes Addon gestartet werden, in diesem Fall läuft er auf Kubernetes.
|
||||
|
||||
Das Design des Cloud Controller Managers basiert auf einem Plugin Mechanismus, der es neuen Cloud Anbietern ermöglicht, sich mit Kubernetes einfach über Plugins zu integrieren. Es gibt Pläne für die Einbindung neuer Cloud Anbieter auf Kubernetes und für die Migration von Cloud Anbietern vom alten Modell auf das neue CCM-Modell.
|
||||
@@ -15,10 +15,10 @@ Die Architektur eines Kubernetes Clusters ohne den Cloud Controller Manager sieh
|
||||
|
||||

|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Design
|
||||
|
||||
@@ -235,4 +235,4 @@ Die folgenden Cloud Anbieter haben CCMs implementiert:
|
||||
|
||||
Eine vollständige Anleitung zur Konfiguration und zum Betrieb des CCM findest du [hier](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,18 +1,18 @@
|
||||
---
|
||||
title: Master-Node Kommunikation
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Dieses Dokument katalogisiert die Kommunikationspfade zwischen dem Master (eigentlich dem Apiserver) und des Kubernetes-Clusters.
|
||||
Die Absicht besteht darin, Benutzern die Möglichkeit zu geben, ihre Installation so anzupassen, dass die Netzwerkkonfiguration so abgesichert wird, dass der Cluster in einem nicht vertrauenswürdigen Netzwerk (oder mit vollständig öffentlichen IP-Adressen eines Cloud-Providers) ausgeführt werden kann.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Cluster zum Master
|
||||
|
||||
@@ -69,4 +69,4 @@ Dieser Tunnel stellt sicher, dass der Datenverkehr nicht außerhalb des Netzwerk
|
||||
|
||||
SSH-Tunnel werden zur Zeit nicht unterstützt. Sie sollten also nicht verwendet werden, sei denn, man weiß, was man tut. Ein Ersatz für diesen Kommunikationskanal wird entwickelt.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: Nodes
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Ein Knoten (Node in Englisch) ist eine Arbeitsmaschine in Kubernetes, früher als `minion` bekannt. Ein Node
|
||||
kann je nach Cluster eine VM oder eine physische Maschine sein. Jeder Node enthält
|
||||
@@ -13,10 +13,10 @@ und wird von den Master-Komponenten verwaltet.
|
||||
Die Dienste auf einem Node umfassen die [Container Runtime](/docs/concepts/overview/components/#node-components), das Kubelet und den Kube-Proxy.
|
||||
Weitere Informationen finden Sie im Abschnitt Kubernetes Node in der Architekturdesign-Dokumentation.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Node Status
|
||||
|
||||
@@ -244,4 +244,4 @@ Wenn Sie Ressourcen explizit für Nicht-Pod-Prozesse reservieren möchten, folge
|
||||
Node ist eine Top-Level-Ressource in der Kubernetes-REST-API. Weitere Details zum API-Objekt finden Sie unter:
|
||||
[Node API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
---
|
||||
title: Addons Installieren
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
|
||||
Add-Ons erweitern die Funktionalität von Kubernetes.
|
||||
@@ -12,10 +12,10 @@ Diese Seite gibt eine Übersicht über einige verfügbare Add-Ons und verweist a
|
||||
|
||||
Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenfolge impliziert keine bevorzugung einzelner Projekte.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Networking und Network Policy
|
||||
|
||||
@@ -53,4 +53,4 @@ Es gibt einige weitere Add-Ons die in dem abgekündigten [cluster/addons](https:
|
||||
|
||||
Add-Ons die ordentlich gewartet werden dürfen gerne hier aufgezählt werden. Wir freuen uns auf PRs!
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
---
|
||||
title: Controller Manager Metriken
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 100
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
Controller Manager Metriken liefern wichtige Erkenntnisse über die Leistung und den Zustand von den Controller Managern.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
## Was sind Controller Manager Metriken
|
||||
|
||||
Die Kennzahlen des Controller Managers liefert wichtige Erkenntnisse über die Leistung und den Zustand des Controller Managers.
|
||||
@@ -38,4 +38,3 @@ Die Metriken werden im [Prometheus Format](https://prometheus.io/docs/instrument
|
||||
|
||||
In einer Produktionsumgebung können Sie Prometheus oder einen anderen Metrik Scraper konfigurieren, um diese Metriken regelmäßig zu sammeln und in einer Art Zeitreihen Datenbank verfügbar zu machen.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -1,14 +1,14 @@
|
||||
---
|
||||
title: Proxies in Kubernetes
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 90
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
Auf dieser Seite werden die im Kubernetes verwendeten Proxies erläutert.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Proxies
|
||||
|
||||
@@ -61,4 +61,3 @@ Kubernetes Benutzer müssen sich in der Regel um nichts anderes als die ersten b
|
||||
|
||||
Proxies haben die Möglichkeit der Umleitung (redirect) ersetzt. Umleitungen sind veraltet.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -1,18 +1,18 @@
|
||||
---
|
||||
title: Images
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Sie erstellen ihr Docker Image und laden es in eine Registry hoch, bevor es in einem Kubernetes Pod referenziert werden kann.
|
||||
|
||||
Die `image` Eigenschaft eines Containers unterstüzt die gleiche Syntax wie die des `docker` Kommandos, inklusive privater Registries und Tags.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Aktualisieren von Images
|
||||
|
||||
@@ -334,7 +334,7 @@ Es gibt eine Anzahl an Lösungen um eigene Registries zu konfigurieren, hier sin
|
||||
- Generieren die Registry - Zugriffsdaten für jeden Mandanten, abgelegt in einem Secret das in jedem Mandanten - Namespace vorhanden ist.
|
||||
- Der Mandant fügt dieses Sercret zu den imagePullSecrets in jedem seiner Namespace hinzu.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
Falls die Zugriff auf mehrere Registries benötigen, können sie ein Secret für jede Registry erstellen, Kubelet wird jedwede `imagePullSecrets` in einer einzelnen `.docker/config.json` zusammenfassen.
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: Konzept Dokumentations-Vorlage
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
toc_hide: true
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< note >}}
|
||||
Stellen Sie auch sicher [einen Eintrag im Inhaltsverzeichnis](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) für Ihr neues Dokument zu erstellen.
|
||||
@@ -12,9 +12,9 @@ Stellen Sie auch sicher [einen Eintrag im Inhaltsverzeichnis](/docs/home/contrib
|
||||
|
||||
Diese Seite erklärt ...
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Verstehen ...
|
||||
|
||||
@@ -24,15 +24,16 @@ Kubernetes bietet ...
|
||||
|
||||
Benutzen Sie ...
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
**[Optionaler Bereich]**
|
||||
|
||||
* Lernen Sie mehr über [ein neues Thema schreiben](/docs/home/contribute/write-new-topic/).
|
||||
* Besuchen Sie [Seitenvorlagen verwenden - Konzeptvorlage](/docs/home/contribute/page-templates/#concept_template) wie Sie diese Vorlage verwenden.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
---
|
||||
title: Kubernetes Komponenten
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 20
|
||||
card:
|
||||
name: concepts
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
In diesem Dokument werden die verschiedenen binären Komponenten beschrieben, die zur Bereitstellung eines funktionsfähigen Kubernetes-Clusters erforderlich sind.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
## Master-Komponenten
|
||||
|
||||
Master-Komponenten stellen die Steuerungsebene des Clusters bereit. Master-Komponenten treffen globale Entscheidungen über den Cluster (z. B. Zeitplanung) und das Erkennen und Reagieren auf Clusterereignisse (Starten eines neuen Pods, wenn das `replicas`-Feld eines Replikationscontrollers nicht zufriedenstellend ist).
|
||||
@@ -107,6 +107,6 @@ Von Kubernetes gestartete Container schließen diesen DNS-Server automatisch in
|
||||
|
||||
Ein [Cluster-level logging](/docs/concepts/cluster-administration/logging/) Mechanismus ist für das Speichern von Containerprotokollen in einem zentralen Protokollspeicher mit Such- / Browsing-Schnittstelle verantwortlich.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
---
|
||||
title: Was ist Kubernetes?
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 10
|
||||
card:
|
||||
name: concepts
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
Diese Seite ist eine Übersicht über Kubernetes.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
Kubernetes ist eine portable, erweiterbare Open-Source-Plattform zur Verwaltung von
|
||||
containerisierten Arbeitslasten und Services, die sowohl die deklarative Konfiguration als auch die Automatisierung erleichtert.
|
||||
@@ -160,11 +160,12 @@ Der Name **Kubernetes** stammt aus dem Griechischen, bedeutet *Steuermann* oder
|
||||
[cybernetic](http://www.etymonline.com/index.php?term=cybernetics). *K8s*
|
||||
ist eine Abkürzung, die durch Ersetzen der 8 Buchstaben "ubernete" mit "8" abgeleitet wird.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [Bereit loszulegen](/docs/setup/)?
|
||||
* Weitere Einzelheiten finden Sie in der [Kubernetes Dokumentation](/docs/home/).
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
---
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
title: Zur Kubernets-Dokumentation beitragen
|
||||
linktitle: Mitmachen
|
||||
main_menu: true
|
||||
weight: 80
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Wenn Sie an der Dokumentation oder der Website von Kubernetes mitwirken möchten, freuen wir uns über Ihre Hilfe!
|
||||
Jeder kann seinen Beitrag leisten, unabhängig davon ob Sie neu im Projekt sind oder schon lange dabei sind, und ob Sie sich als
|
||||
@@ -15,7 +15,7 @@ Entwickler, Endbenutzer oder einfach jemanden, der es einfach nicht aushält, Ti
|
||||
Weitere Möglichkeiten, sich in der Kubernetes-Community zu engagieren oder mehr über uns zu erfahren, finden Sie auf der [Kubernetes-Community-Seite](/community/).
|
||||
Informationen zum Handbuch zur Dokumentation von Kubernetes finden Sie im [Gestaltungshandbuch](/docs/contribute/style/style-guide/).
|
||||
|
||||
{{% capture body %}}
|
||||
<!-- body -->
|
||||
|
||||
## Arten von Mitwirkenden
|
||||
|
||||
@@ -59,4 +59,4 @@ Dies ist keine vollständige Liste von Möglichkeiten, wie Sie zur Kubernetes-Do
|
||||
- Verbesserungsvorschläge für Dokumentprüfungen vorschlagen
|
||||
- Vorschläge für Verbesserungen der Kubernetes-Website oder anderer Tools
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Lokalisierung der Kubernetes Dokumentation
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 50
|
||||
card:
|
||||
name: mitarbeiten
|
||||
@@ -8,13 +8,13 @@ card:
|
||||
title: Übersetzen der Dokumentation
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Diese Seite zeigt dir wie die Dokumentation für verschiedene Sprachen [lokalisiert](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/) wird.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Erste Schritte
|
||||
|
||||
@@ -277,13 +277,14 @@ SIG Docs begrüßt Upstream Beiträge, also auf das englische Original, und Korr
|
||||
|
||||
Du kannst auch dazu beitragen, Inhalte zu einer bestehenden Lokalisierung hinzuzufügen oder zu verbessern. Trete dem [Slack-Kanal](https://kubernetes.slack.com/messages/C1J0BPD2M/) für die Lokalisierung bei und beginne mit der Eröffnung von PRs, um zu helfen. Bitte beschränke deine Pull-Anfragen auf eine einzige Lokalisierung, da Pull-Anfragen, die Inhalte in mehreren Lokalisierungen ändern, schwer zu überprüfen sein könnten.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Sobald eine Lokalisierung die Anforderungen an den Arbeitsablauf und die Mindestausgabe erfüllt, wird SIG docs:
|
||||
|
||||
- Die Sprachauswahl auf der Website aktivieren
|
||||
- Die Verfügbarkeit der Lokalisierung über die Kanäle der [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF), einschließlich des [Kubernetes Blogs](https://kubernetes.io/blog/) veröffentlichen.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
---
|
||||
title: Unterstützte Versionen der Kubernetes-Dokumentation
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
card:
|
||||
name: about
|
||||
weight: 10
|
||||
title: Unterstützte Versionen der Dokumentation
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Diese Website enthält Dokumentation für die aktuelle Version von Kubernetes
|
||||
und die vier vorherigen Versionen von Kubernetes.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Aktuelle Version
|
||||
|
||||
@@ -25,6 +25,6 @@ Die aktuelle Version ist
|
||||
|
||||
{{< versions-other >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -5,16 +5,16 @@ approvers:
|
||||
linkTitle: "Referenzen"
|
||||
main_menu: true
|
||||
weight: 70
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Dieser Abschnitt der Kubernetes-Dokumentation enthält Referenzinformationen.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## API-Referenz
|
||||
|
||||
@@ -58,4 +58,4 @@ Offiziell unterstützte Clientbibliotheken:
|
||||
|
||||
Ein Archiv der Designdokumente für Kubernetes-Funktionalität. Gute Ansatzpunkte sind [Kubernetes Architektur](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) und [Kubernetes Design Übersicht](https://git.k8s.io/community/contributors/design-proposals).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
---
|
||||
title: kubectl Spickzettel
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
card:
|
||||
name: reference
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Siehe auch: [Kubectl Überblick](/docs/reference/kubectl/overview/) und [JsonPath Dokumentation](/docs/reference/kubectl/jsonpath).
|
||||
|
||||
Diese Seite ist eine Übersicht über den Befehl `kubectl`.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
# kubectl - Spickzettel
|
||||
|
||||
@@ -335,9 +335,10 @@ Ausführlichkeit | Beschreibung
|
||||
`--v=8` | HTTP-Anforderungsinhalt anzeigen
|
||||
`--v=9` | HTTP-Anforderungsinhalt anzeigen, ohne den Inhalt zu kürzen.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Lernen Sie mehr im [Überblick auf kubectl](/docs/reference/kubectl/overview/).
|
||||
|
||||
@@ -347,4 +348,4 @@ Ausführlichkeit | Beschreibung
|
||||
|
||||
* Entdecken Sie mehr Community [kubectl Spickzettel](https://github.com/dennyzhang/cheatsheet-kubernetes-A4).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
title: Tools
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
Kubernetes enthält mehrere integrierte Tools, die Ihnen bei der Arbeit mit dem Kubernetes System helfen.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
## Kubectl
|
||||
|
||||
[`kubectl`](/docs/tasks/tools/install-kubectl/) ist ein Kommandozeilenprogramm für Kubernetes. Es steuert den Kubernetes Clustermanager.
|
||||
@@ -49,4 +49,4 @@ Verwenden Sie Kompose um:
|
||||
* Ein Docker Compose Datei in Kubernetes Objekte zu übersetzen
|
||||
* Von Ihrer lokalen Docker Entwicklung auf eine Kubernetes verwaltete Entwicklung zu wechseln
|
||||
* v1 oder v2 Docker Compose `yaml` Dateien oder [Distributed Application Bundles](https://docs.docker.com/compose/bundles/) zu konvertieren
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -2,10 +2,10 @@
|
||||
title: Setup
|
||||
main_menu: true
|
||||
weight: 30
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Diese Sektion umfasst verschiedene Optionen zum Einrichten und Betrieb von Kubernetes.
|
||||
|
||||
@@ -15,9 +15,9 @@ Sie können einen Kubernetes-Cluster auf einer lokalen Maschine, Cloud, On-Prem
|
||||
|
||||
Noch einfacher können Sie einen Kubernetes-Cluster in einer Lern- und Produktionsumgebung erstellen.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Lernumgebung
|
||||
|
||||
@@ -99,4 +99,4 @@ Die folgende Tabelle für Produktionsumgebungs-Lösungen listet Anbieter und der
|
||||
| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)
|
||||
| [Z.A.R.V.I.S.](https://zarvis.ai/) | ✔ | | | | | |
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
---
|
||||
title: Kubernetes lokal über Minikube betreiben
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Minikube ist ein Tool, mit dem Kubernetes lokal einfach ausgeführt werden kann. Minikube führt einen Kubernetes-Cluster mit einem einzigen Node in einer VM auf Ihrem Laptop aus, damit Anwender Kubernetes ausprobieren oder täglich damit entwickeln können.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Minikube-Funktionen
|
||||
|
||||
@@ -34,11 +34,11 @@ Minikube unterstützt die folgenden Treiber:
|
||||
|
||||
* virtualbox
|
||||
* vmwarefusion
|
||||
* kvm2 ([Treiber installation](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver))
|
||||
* kvm ([Treiber installation](https://git.k8s.io/minikube/docs/drivers.md#kvm-driver))
|
||||
* hyperkit ([Treiber installation](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver))
|
||||
* xhyve ([Treiber installation](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver)) (deprecated)
|
||||
* hyperv ([Treiber installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
|
||||
* kvm2 ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver))
|
||||
* kvm ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm-driver))
|
||||
* hyperkit ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver))
|
||||
* xhyve ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#xhyve-driver)) (deprecated)
|
||||
* hyperv ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperv-driver))
|
||||
Beachten Sie, dass die unten angegebene IP-Adresse dynamisch ist und sich ändern kann. Sie kann mit `minikube ip` abgerufen werden.
|
||||
* none (Führt die Kubernetes-Komponenten auf dem Host und nicht in einer VM aus. Die Verwendung dieses Treibers erfordert Docker ([Docker installieren](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) und eine Linux-Umgebung)
|
||||
|
||||
@@ -201,7 +201,7 @@ Hierbei wird ein alternatives Minikube-ISO-Image verwendet, das sowohl rkt als a
|
||||
|
||||
### Treiber Plugins
|
||||
|
||||
Weitere Informationen zu unterstützten Treibern und zur Installation von Plugins finden Sie bei Bedarf unter [TREIBER](https://git.k8s.io/minikube/docs/drivers.md).
|
||||
Weitere Informationen zu unterstützten Treibern und zur Installation von Plugins finden Sie bei Bedarf unter [TREIBER](https://minikube.sigs.k8s.io/docs/drivers/).
|
||||
|
||||
### Lokale Images durch erneute Verwendung des Docker-Daemon ausführen
|
||||
|
||||
@@ -431,7 +431,7 @@ Weitere Informationen zu Minikube finden Sie im [Vorschlag](https://git.k8s.io/c
|
||||
* **Ziele und Nichtziele**: Die Ziele und Nichtziele des Minikube-Projekts finden Sie in unserer [Roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md).
|
||||
* **Entwicklungshandbuch**: Lesen Sie [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) für einen Überblick über das Senden von Pull-Requests.
|
||||
* **Minikube bauen**: Anweisungen zum Erstellen/Testen von Minikube aus dem Quellcode finden Sie im [build Handbuch](https://git.k8s.io/minikube/docs/contributors/build_guide.md).
|
||||
* **Neue Abhängigkeit hinzufügen**: Anweisungen zum Hinzufügen einer neuen Abhängigkeit zu Minikube finden Sie in der [Anleitung zum Hinzufügen von Abhängigkeiten](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md).
|
||||
* **Neue Abhängigkeit hinzufügen**: Anweisungen zum Hinzufügen einer neuen Abhängigkeit zu Minikube finden Sie in der [Anleitung zum Hinzufügen von Abhängigkeiten](https://minikube.sigs.k8s.io/docs/drivers/).
|
||||
* **Neues Addon hinzufügen**: Anweisungen zum Hinzufügen eines neuen Addons für Minikube finden Sie im [Anleitung zum Hinzufügen eines Addons](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md).
|
||||
* **MicroK8s**: Linux-Benutzer, die die Ausführung einer virtuellen Maschine vermeiden möchten, sollten [MicroK8s](https://microk8s.io/) als Alternative in Betracht ziehen.
|
||||
|
||||
@@ -439,4 +439,4 @@ Weitere Informationen zu Minikube finden Sie im [Vorschlag](https://git.k8s.io/c
|
||||
|
||||
Beiträge, Fragen und Kommentare werden begrüßt und ermutigt! Minikube-Entwickler finden Sie in [Slack](https://kubernetes.slack.com) im #minikube Kanal (Erhalten Sie [hier](http://slack.kubernetes.io/) eine Einladung). Wir haben ausserdem die [kubernetes-dev Google Groups-Mailingliste](https://groups.google.com/forum/#!forum/kubernetes-dev). Wenn Sie in der Liste posten, fügen Sie Ihrem Betreff bitte "minikube:" voran.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
---
|
||||
title: Release erstellen
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
card:
|
||||
name: download
|
||||
weight: 20
|
||||
title: Release erstellen
|
||||
---
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
Sie können entweder eine Version aus dem Quellcode erstellen oder eine bereits kompilierte Version herunterladen.
|
||||
Wenn Sie nicht vorhaben, Kubernetes selbst zu entwickeln, empfehlen wir die Verwendung eines vorkompilierten Builds der aktuellen Version, die Sie in den [Versionshinweisen](/docs/setup/release/notes/) finden.
|
||||
|
||||
Der Kubernetes-Quellcode kann aus dem [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repo der heruntergeladen werden.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Aus dem Quellcode kompilieren
|
||||
|
||||
@@ -29,4 +29,4 @@ make release
|
||||
|
||||
Mehr Informationen zum Release-Prozess finden Sie im kubernetes/kubernetes [`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/) Verzeichnis.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -2,19 +2,19 @@
|
||||
title: Aufgaben
|
||||
main_menu: true
|
||||
weight: 50
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Dieser Abschnitt der Kubernetes-Dokumentation enthält Seiten, die zeigen, wie man einzelne Aufgaben erledigt.
|
||||
Eine Aufgabenseite zeigt, wie man eine einzelne Aufgabe ausführt, typischerweise durch eine kurze Abfolge von Schritten.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Webbenutzeroberfläche (Dashboard)
|
||||
|
||||
@@ -76,10 +76,11 @@ Konfigurieren und planen Sie NVIDIA-GPUs für die Verwendung durch Nodes in eine
|
||||
|
||||
Konfigurieren und verwalten Sie `HugePages` als planbare Ressource in einem Cluster.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Wenn Sie eine Aufgabenseite schreiben möchten, finden Sie weitere Informationen unter [Erstellen einer Pull-Anfrage für Dokumentation](/docs/home/contribute/create-pull-request/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -5,11 +5,11 @@ feature:
|
||||
description: >
|
||||
Skaliere deine Anwendung mit einem einfachen Befehl, über die Benutzeroberfläche oder automatisch, basierend auf der CPU-Auslastung.
|
||||
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 90
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Der Horizontal Pod Autoscaler skaliert automatisch die Anzahl der Pods eines Replication Controller, Deployment oder Replikat Set basierend auf der beobachteten CPU-Auslastung (oder, mit Unterstützung von [benutzerdefinierter Metriken](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md), von der Anwendung bereitgestellten Metriken). Beachte, dass die horizontale Pod Autoskalierung nicht für Objekte gilt, die nicht skaliert werden können, z. B. DaemonSets.
|
||||
|
||||
@@ -17,9 +17,9 @@ Der Horizontal Pod Autoscaler ist als Kubernetes API-Ressource und einem Control
|
||||
Die Ressource bestimmt das Verhalten des Controllers.
|
||||
Der Controller passt die Anzahl der Replikate eines Replication Controller oder Deployments regelmäßig an, um die beobachtete durchschnittliche CPU-Auslastung an das vom Benutzer angegebene Ziel anzupassen.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Wie funktioniert der Horizontal Pod Autoscaler?
|
||||
|
||||
@@ -161,12 +161,13 @@ Standardmäßig ruft der HorizontalPodAutoscaler Controller Metriken aus einer R
|
||||
|
||||
* Das Flag `--horizontal-pod-autoscaler-use-rest-clients` ist auf `true` oder ungesetzt. Wird dies auf `false` gesetzt wird die Heapster basierte Autoskalierung aktiviert, welche veraltet ist.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Design Dokument [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
|
||||
* kubectl autoscale Befehl: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
|
||||
* Verwenden des [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Installieren und konfigurieren von kubectl
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 10
|
||||
card:
|
||||
name: tasks
|
||||
@@ -8,17 +8,18 @@ card:
|
||||
title: Kubectl installieren
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
Verwenden Sie das Kubernetes Befehlszeilenprogramm, [kubectl](/docs/user-guide/kubectl/), um Anwendungen auf Kubernetes bereitzustellen und zu verwalten.
|
||||
Mit kubectl können Sie Clusterressourcen überprüfen, Komponenten erstellen, löschen und aktualisieren; Ihren neuen Cluster betrachten; und Beispielanwendungen aufrufen.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
Sie müssen eine kubectl-Version verwenden, die innerhalb eines geringfügigen Versionsunterschieds zur Version Ihres Clusters liegt. Ein v1.2-Client sollte beispielsweise mit einem v1.1, v1.2 und v1.3-Master arbeiten. Die Verwendung der neuesten Version von kubectl verhindert unvorhergesehene Probleme.
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Kubectl installieren
|
||||
|
||||
@@ -421,9 +422,10 @@ compinit
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
[Erfahren Sie, wie Sie Ihre Anwendung starten und verfügbar machen.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -1,28 +1,29 @@
|
||||
---
|
||||
title: Installation von Minikube
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
weight: 20
|
||||
card:
|
||||
name: tasks
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Diese Seite zeigt Ihnen, wie Sie [Minikube](/docs/tutorials/hello-minikube) installieren, ein Programm, das einen Kubernetes-Cluster mit einem einzigen Node in einer virtuellen Maschine auf Ihrem Laptop ausführt.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
Die VT-x- oder AMD-v-Virtualisierung muss im BIOS Ihres Computers aktiviert sein. Um dies unter Linux zu überprüfen, führen Sie Folgendes aus und vergewissern Sie sich, dass die Ausgabe nicht leer ist:
|
||||
```shell
|
||||
egrep --color 'vmx|svm' /proc/cpuinfo
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Einen Hypervisor installieren
|
||||
|
||||
@@ -106,13 +107,6 @@ Schließen Sie nach der Installation von Minikube die aktuelle CLI-Sitzung und s
|
||||
|
||||
So installieren Sie Minikube manuell unter Windows mit [Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal), laden Sie die Datei [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest) und führen Sie den Installer aus.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [Kubernetes lokal über Minikube ausführen](/docs/setup/minikube/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
## Eine bestehende Installation bereinigen
|
||||
|
||||
@@ -130,3 +124,8 @@ Müssen Sie die Konfigurationsdateien löschen:
|
||||
```shell
|
||||
rm -rf ~/.minikube
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [Kubernetes lokal über Minikube ausführen](/docs/setup/minikube/)
|
||||
|
||||
@@ -2,19 +2,19 @@
|
||||
title: Tutorials
|
||||
main_menu: true
|
||||
weight: 60
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Dieser Abschnitt der Kubernetes-Dokumentation enthält Tutorials.
|
||||
Ein Tutorial zeigt, wie Sie ein Ziel erreichen, das größer ist als eine einzelne [Aufgabe](/docs/tasks/).
|
||||
Ein Tutorial besteht normalerweise aus mehreren Abschnitten, die jeweils eine Abfolge von Schritten haben.
|
||||
Bevor Sie die einzelnen Lernprogramme durchgehen, möchten Sie möglicherweise ein Lesezeichen zur Seite mit dem [Standardisierten Glossar](/docs/reference/glossary/) setzen um später Informationen nachzuschlagen.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Grundlagen
|
||||
|
||||
@@ -64,12 +64,13 @@ Bevor Sie die einzelnen Lernprogramme durchgehen, möchten Sie möglicherweise e
|
||||
|
||||
* [Source IP verwenden](/docs/tutorials/services/source-ip/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Wenn Sie ein Tutorial schreiben möchten, lesen Sie
|
||||
[Seitenvorlagen verwenden](/docs/home/contribute/page-templates/)
|
||||
für weitere Informationen zum Typ der Tutorial-Seite und zur Tutorial-Vorlage.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Hallo Minikube
|
||||
content_template: templates/tutorial
|
||||
content_type: tutorial
|
||||
weight: 5
|
||||
menu:
|
||||
main:
|
||||
@@ -13,7 +13,7 @@ card:
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Dieses Tutorial zeigt Ihnen, wie Sie eine einfache "Hallo Welt" Node.js-Anwendung auf Kubernetes mit [Minikube](/docs/getting-started-guides/minikube) und Katacoda ausführen.
|
||||
Katacoda bietet eine kostenlose Kubernetes-Umgebung im Browser.
|
||||
@@ -22,17 +22,19 @@ Katacoda bietet eine kostenlose Kubernetes-Umgebung im Browser.
|
||||
Sie können dieses Tutorial auch verwenden, wenn Sie [Minikube lokal](/docs/tasks/tools/install-minikube/) installiert haben.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture objectives %}}
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
|
||||
* Stellen Sie eine Hallo-Welt-Anwendung für Minikube bereit.
|
||||
* Führen Sie die App aus.
|
||||
* Betrachten Sie die Log Dateien.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
Dieses Lernprogramm enthält ein aus den folgenden Dateien erstelltes Container-Image:
|
||||
|
||||
@@ -42,9 +44,9 @@ Dieses Lernprogramm enthält ein aus den folgenden Dateien erstelltes Container-
|
||||
|
||||
Weitere Informationen zum `docker build` Befehl, lesen Sie die [Docker Dokumentation](https://docs.docker.com/engine/reference/commandline/build/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture lessoncontent %}}
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
||||
## Erstellen Sie einen Minikube-Cluster
|
||||
|
||||
@@ -260,12 +262,13 @@ Löschen Sie optional die Minikube-VM:
|
||||
minikube delete
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Lernen Sie mehr über [Bereitstellungsobjekte](/docs/concepts/workloads/controllers/deployment/).
|
||||
* Lernen Sie mehr über [Anwendungen bereitstellen](/docs/user-guide/deploying-applications/).
|
||||
* Lernen Sie mehr über [Serviceobjekte](/docs/concepts/services-networking/service/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -3,9 +3,6 @@ title: "Production-Grade Container Orchestration"
|
||||
abstract: "Automated container deployment, scaling, and management"
|
||||
cid: home
|
||||
---
|
||||
{{< announcement >}}
|
||||
|
||||
{{< deprecationwarning >}}
|
||||
|
||||
{{< blocks/section id="oceanNodes" >}}
|
||||
{{% blocks/feature image="flower" %}}
|
||||
@@ -60,4 +57,4 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
|
||||
|
||||
{{< blocks/kubernetes-features >}}
|
||||
|
||||
{{< blocks/case-studies >}}
|
||||
{{< blocks/case-studies >}}
|
||||
+96
-259
@@ -4,70 +4,49 @@ date: 2017-01-30
|
||||
slug: running-mongodb-on-kubernetes-with-statefulsets
|
||||
url: /blog/2017/01/Running-Mongodb-On-Kubernetes-With-Statefulsets
|
||||
---
|
||||
_Editor's note: Today’s post is by Sandeep Dinesh, Developer Advocate, Google Cloud Platform, showing how to run a database in a container._
|
||||
_Editor's note: Today’s post is by Sandeep Dinesh, Developer Advocate, Google Cloud Platform, showing how to run a database in a container._
|
||||
|
||||
{{% warning %}}
|
||||
This post is several years old. The code examples need changes to work on a current Kubernetes cluster.
|
||||
{{% /warning %}}
|
||||
|
||||
Conventional wisdom says you can’t run a database in a container. “Containers are stateless!” they say, and “databases are pointless without state!”
|
||||
Conventional wisdom says you can’t run a database in a container. “Containers are stateless!” they say, and “databases are pointless without state!”
|
||||
|
||||
Of course, this is not true at all. At Google, everything runs in a container, including databases. You just need the right tools. [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/) includes the new [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) API object (in previous versions, StatefulSet was known as PetSet). With StatefulSets, Kubernetes makes it much easier to run stateful workloads such as databases.
|
||||
|
||||
If you’ve followed my previous posts, you know how to create a [MEAN Stack app with Docker](http://blog.sandeepdinesh.com/2015/07/running-mean-web-application-in-docker.html), then [migrate it to Kubernetes](https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d) to provide easier management and reliability, and [create a MongoDB replica set](https://medium.com/google-cloud/mongodb-replica-sets-with-kubernetes-d96606bd9474) to provide redundancy and high availability.
|
||||
If you’ve followed my previous posts, you know how to create a [MEAN Stack app with Docker](http://blog.sandeepdinesh.com/2015/07/running-mean-web-application-in-docker.html), then [migrate it to Kubernetes](https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d) to provide easier management and reliability, and [create a MongoDB replica set](https://medium.com/google-cloud/mongodb-replica-sets-with-kubernetes-d96606bd9474) to provide redundancy and high availability.
|
||||
|
||||
While the replica set in my previous blog post worked, there were some annoying steps that you needed to follow. You had to manually create a disk, a ReplicationController, and a service for each replica. Scaling the set up and down meant managing all of these resources manually, which is an opportunity for error, and would put your stateful application at risk In the previous example, we created a Makefile to ease the management of these resources, but it would have been great if Kubernetes could just take care of all of this for us.
|
||||
|
||||
With StatefulSets, these headaches finally go away. You can create and manage your MongoDB replica set natively in Kubernetes, without the need for scripts and Makefiles. Let’s take a look how.
|
||||
|
||||
_Note: StatefulSets are currently a beta resource. The [sidecar container](https://github.com/cvallance/mongo-k8s-sidecar) used for auto-configuration is also unsupported._
|
||||
While the replica set in my previous blog post worked, there were some annoying steps that you needed to follow. You had to manually create a disk, a ReplicationController, and a service for each replica. Scaling the set up and down meant managing all of these resources manually, which is an opportunity for error, and would put your stateful application at risk In the previous example, we created a Makefile to ease the management of these resources, but it would have been great if Kubernetes could just take care of all of this for us.
|
||||
|
||||
With StatefulSets, these headaches finally go away. You can create and manage your MongoDB replica set natively in Kubernetes, without the need for scripts and Makefiles. Let’s take a look how.
|
||||
|
||||
_Note: StatefulSets are currently a beta resource. The [sidecar container](https://github.com/cvallance/mongo-k8s-sidecar) used for auto-configuration is also unsupported._
|
||||
|
||||
**Prerequisites and Setup**
|
||||
|
||||
|
||||
|
||||
Before we get started, you’ll need a Kubernetes 1.5+ and the [Kubernetes command line tool](/docs/user-guide/prereqs/). If you want to follow along with this tutorial and use Google Cloud Platform, you also need the [Google Cloud SDK](http://cloud.google.com/sdk).
|
||||
|
||||
|
||||
|
||||
Once you have a [Google Cloud project created](https://console.cloud.google.com/projectcreate) and have your Google Cloud SDK setup (hint: gcloud init), we can create our cluster.
|
||||
|
||||
|
||||
|
||||
To create a Kubernetes 1.5 cluster, run the following command:
|
||||
|
||||
To create a Kubernetes 1.5 cluster, run the following command:
|
||||
|
||||
```
|
||||
gcloud container clusters create "test-cluster"
|
||||
```
|
||||
|
||||
|
||||
|
||||
This will make a three node Kubernetes cluster. Feel free to [customize the command](https://cloud.google.com/sdk/gcloud/reference/container/clusters/create) as you see fit.
|
||||
This will make a three node Kubernetes cluster. Feel free to [customize the command](https://cloud.google.com/sdk/gcloud/reference/container/clusters/create) as you see fit.
|
||||
|
||||
Then, authenticate into the cluster:
|
||||
|
||||
|
||||
|
||||
```
|
||||
gcloud container clusters get-credentials test-cluster
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Setting up the MongoDB replica set**
|
||||
|
||||
|
||||
|
||||
To set up the MongoDB replica set, you need three things: A [StorageClass](/docs/user-guide/persistent-volumes/#storageclasses), a [Headless Service](/docs/user-guide/services/#headless-services), and a [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/).
|
||||
|
||||
|
||||
|
||||
I’ve created the configuration files for these already, and you can clone the example from GitHub:
|
||||
|
||||
I’ve created the configuration files for these already, and you can clone the example from GitHub:
|
||||
|
||||
```
|
||||
git clone https://github.com/thesandlord/mongo-k8s-sidecar.git
|
||||
@@ -75,10 +54,7 @@ git clone https://github.com/thesandlord/mongo-k8s-sidecar.git
|
||||
cd /mongo-k8s-sidecar/example/StatefulSet/
|
||||
```
|
||||
|
||||
|
||||
|
||||
To create the MongoDB replica set, run these two commands:
|
||||
|
||||
To create the MongoDB replica set, run these two commands:
|
||||
|
||||
```
|
||||
kubectl apply -f googlecloud\_ssd.yaml
|
||||
@@ -86,341 +62,202 @@ kubectl apply -f googlecloud\_ssd.yaml
|
||||
kubectl apply -f mongo-statefulset.yaml
|
||||
```
|
||||
|
||||
|
||||
|
||||
That's it! With these two commands, you have launched all the components required to run an highly available and redundant MongoDB replica set.
|
||||
|
||||
|
||||
|
||||
At an high level, it looks something like this:
|
||||
|
||||
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
Let’s examine each piece in more detail.
|
||||
|
||||
|
||||
|
||||
**StorageClass**
|
||||
|
||||
|
||||
|
||||
The storage class tells Kubernetes what kind of storage to use for the database nodes. You can set up many different types of StorageClasses in a ton of different environments. For example, if you run Kubernetes in your own datacenter, you can use [GlusterFS](https://www.gluster.org/). On GCP, your [storage choices](https://cloud.google.com/compute/docs/disks/) are SSDs and hard disks. There are currently drivers for [AWS](/docs/user-guide/persistent-volumes/#aws), [Azure](/docs/user-guide/persistent-volumes/#azure-disk), [Google Cloud](/docs/user-guide/persistent-volumes/#gce), [GlusterFS](/docs/user-guide/persistent-volumes/#glusterfs), [OpenStack Cinder](/docs/user-guide/persistent-volumes/#openstack-cinder), [vSphere](/docs/user-guide/persistent-volumes/#vsphere), [Ceph RBD](/docs/user-guide/persistent-volumes/#ceph-rbd), and [Quobyte](/docs/user-guide/persistent-volumes/#quobyte).
|
||||
|
||||
The configuration for the StorageClass looks like this:
|
||||
|
||||
|
||||
The configuration for the StorageClass looks like this:
|
||||
|
||||
|
||||
```
|
||||
kind: StorageClass
|
||||
apiVersion: storage.k8s.io/v1beta1
|
||||
metadata:
|
||||
name: fast
|
||||
provisioner: kubernetes.io/gce-pd
|
||||
parameters:
|
||||
```yaml
|
||||
kind: StorageClass
|
||||
apiVersion: storage.k8s.io/v1beta1
|
||||
metadata:
|
||||
name: fast
|
||||
provisioner: kubernetes.io/gce-pd
|
||||
parameters:
|
||||
type: pd-ssd
|
||||
```
|
||||
|
||||
|
||||
|
||||
This configuration creates a new StorageClass called “fast” that is backed by SSD volumes. The StatefulSet can now request a volume, and the StorageClass will automatically create it!
|
||||
|
||||
|
||||
|
||||
Deploy this StorageClass:
|
||||
|
||||
Deploy this StorageClass:
|
||||
|
||||
```
|
||||
kubectl apply -f googlecloud\_ssd.yaml
|
||||
```
|
||||
|
||||
|
||||
|
||||
**Headless Service**
|
||||
|
||||
|
||||
|
||||
Now you have created the Storage Class, you need to make a Headless Service. These are just like normal Kubernetes Services, except they don’t do any load balancing for you. When combined with StatefulSets, they can give you unique DNS addresses that let you directly access the pods! This is perfect for creating MongoDB replica sets, because our app needs to connect to all of the MongoDB nodes individually.
|
||||
|
||||
The configuration for the Headless Service looks like this:
|
||||
|
||||
|
||||
The configuration for the Headless Service looks like this:
|
||||
|
||||
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
||||
kind: Service
|
||||
|
||||
metadata:
|
||||
|
||||
name: mongo
|
||||
|
||||
labels:
|
||||
|
||||
name: mongo
|
||||
|
||||
name: mongo
|
||||
labels:
|
||||
name: mongo
|
||||
spec:
|
||||
|
||||
ports:
|
||||
|
||||
- port: 27017
|
||||
|
||||
targetPort: 27017
|
||||
|
||||
clusterIP: None
|
||||
|
||||
selector:
|
||||
|
||||
role: mongo
|
||||
ports:
|
||||
- port: 27017
|
||||
targetPort: 27017
|
||||
clusterIP: None
|
||||
selector:
|
||||
role: mongo
|
||||
```
|
||||
|
||||
|
||||
|
||||
You can tell this is a Headless Service because the clusterIP is set to “None.” Other than that, it looks exactly the same as any normal Kubernetes Service.
|
||||
|
||||
|
||||
|
||||
**StatefulSet**
|
||||
|
||||
|
||||
|
||||
The pièce de résistance. The StatefulSet actually runs MongoDB and orchestrates everything together. StatefulSets differ from Kubernetes [ReplicaSets](/docs/user-guide/replicasets/) (not to be confused with MongoDB replica sets!) in certain ways that makes them more suited for stateful applications. Unlike Kubernetes ReplicaSets, pods created under a StatefulSet have a few unique attributes. The name of the pod is not random, instead each pod gets an ordinal name. Combined with the Headless Service, this allows pods to have stable identification. In addition, pods are created one at a time instead of all at once, which can help when bootstrapping a stateful system. You can read more about StatefulSets in the [documentation](/docs/concepts/abstractions/controllers/statefulsets/).
|
||||
|
||||
|
||||
|
||||
Just like before, [this “sidecar” container](https://github.com/cvallance/mongo-k8s-sidecar) will configure the MongoDB replica set automatically. A “sidecar” is a helper container which helps the main container do its work.
|
||||
|
||||
The configuration for the StatefulSet looks like this:
|
||||
|
||||
|
||||
The configuration for the StatefulSet looks like this:
|
||||
|
||||
|
||||
```
|
||||
```yaml
|
||||
apiVersion: apps/v1beta1
|
||||
|
||||
kind: StatefulSet
|
||||
|
||||
metadata:
|
||||
|
||||
name: mongo
|
||||
|
||||
name: mongo
|
||||
spec:
|
||||
|
||||
serviceName: "mongo"
|
||||
|
||||
replicas: 3
|
||||
|
||||
template:
|
||||
|
||||
metadata:
|
||||
|
||||
labels:
|
||||
|
||||
role: mongo
|
||||
|
||||
environment: test
|
||||
|
||||
spec:
|
||||
|
||||
terminationGracePeriodSeconds: 10
|
||||
|
||||
containers:
|
||||
|
||||
- name: mongo
|
||||
|
||||
image: mongo
|
||||
|
||||
command:
|
||||
|
||||
- mongod
|
||||
|
||||
- "--replSet"
|
||||
|
||||
- rs0
|
||||
|
||||
- "--smallfiles"
|
||||
|
||||
- "--noprealloc"
|
||||
|
||||
ports:
|
||||
|
||||
- containerPort: 27017
|
||||
|
||||
volumeMounts:
|
||||
|
||||
- name: mongo-persistent-storage
|
||||
|
||||
mountPath: /data/db
|
||||
|
||||
- name: mongo-sidecar
|
||||
|
||||
image: cvallance/mongo-k8s-sidecar
|
||||
|
||||
env:
|
||||
|
||||
- name: MONGO\_SIDECAR\_POD\_LABELS
|
||||
|
||||
value: "role=mongo,environment=test"
|
||||
|
||||
volumeClaimTemplates:
|
||||
|
||||
- metadata:
|
||||
|
||||
name: mongo-persistent-storage
|
||||
|
||||
annotations:
|
||||
|
||||
volume.beta.kubernetes.io/storage-class: "fast"
|
||||
|
||||
spec:
|
||||
|
||||
accessModes: ["ReadWriteOnce"]
|
||||
|
||||
resources:
|
||||
|
||||
requests:
|
||||
|
||||
storage: 100Gi
|
||||
selector:
|
||||
matchLabels:
|
||||
role: mongo
|
||||
environment: test
|
||||
serviceName: "mongo"
|
||||
replicas: 3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
role: mongo
|
||||
environment: test
|
||||
spec:
|
||||
terminationGracePeriodSeconds: 10
|
||||
containers:
|
||||
- name: mongo
|
||||
image: mongo
|
||||
command:
|
||||
- mongod
|
||||
- "--replSet"
|
||||
- rs0
|
||||
- "--smallfiles"
|
||||
- "--noprealloc"
|
||||
ports:
|
||||
- containerPort: 27017
|
||||
volumeMounts:
|
||||
- name: mongo-persistent-storage
|
||||
mountPath: /data/db
|
||||
- name: mongo-sidecar
|
||||
image: cvallance/mongo-k8s-sidecar
|
||||
env:
|
||||
- name: MONGO_SIDECAR_POD_LABELS
|
||||
value: "role=mongo,environment=test"
|
||||
volumeClaimTemplates:
|
||||
- metadata:
|
||||
name: mongo-persistent-storage
|
||||
spec:
|
||||
storageClassName: "fast"
|
||||
accessModes: ["ReadWriteOnce"]
|
||||
resources:
|
||||
requests:
|
||||
storage: 100Gi
|
||||
```
|
||||
|
||||
|
||||
|
||||
It’s a little long, but fairly straightforward.
|
||||
|
||||
|
||||
|
||||
The first second describes the StatefulSet object. Then, we move into the Metadata section, where you can specify labels and the number of replicas.
|
||||
|
||||
Next comes the pod spec. The terminationGracePeriodSeconds is used to gracefully shutdown the pod when you scale down the number of replicas, which is important for databases! Then the configurations for the two containers is shown. The first one runs MongoDB with command line flags that configure the replica set name. It also mounts the persistent storage volume to /data/db, the location where MongoDB saves its data. The second container runs the sidecar.
|
||||
|
||||
|
||||
Next comes the pod spec. The terminationGracePeriodSeconds is used to gracefully shutdown the pod when you scale down the number of replicas, which is important for databases! Then the configurations for the two containers is shown. The first one runs MongoDB with command line flags that configure the replica set name. It also mounts the persistent storage volume to /data/db, the location where MongoDB saves its data. The second container runs the sidecar.
|
||||
|
||||
|
||||
|
||||
Finally, there is the volumeClaimTemplates. This is what talks to the StorageClass we created before to provision the volume. It will provision a 100 GB disk for each MongoDB replica.
|
||||
|
||||
|
||||
Finally, there is the volumeClaimTemplates. This is what talks to the StorageClass we created before to provision the volume. It will provision a 100 GB disk for each MongoDB replica.
|
||||
|
||||
**Using the MongoDB replica set**
|
||||
|
||||
|
||||
|
||||
At this point, you should have three pods created in your cluster. These correspond to the three nodes in your MongoDB replica set. You can see them with this command:
|
||||
|
||||
At this point, you should have three pods created in your cluster. These correspond to the three nodes in your MongoDB replica set. You can see them with this command:
|
||||
|
||||
```
|
||||
kubectl get pods
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
|
||||
mongo-0 2/2 Running 0 3m
|
||||
|
||||
mongo-1 2/2 Running 0 3m
|
||||
|
||||
mongo-2 2/2 Running 0 3m
|
||||
```
|
||||
|
||||
Each pod in a StatefulSet backed by a Headless Service will have a stable DNS name. The template follows this format: \<pod-name\>.\<service-name\>
|
||||
|
||||
|
||||
Each pod in a StatefulSet backed by a Headless Service will have a stable DNS name. The template follows this format: \<pod-name\>.\<service-name\>
|
||||
|
||||
This means the DNS names for the MongoDB replica set are:
|
||||
|
||||
|
||||
This means the DNS names for the MongoDB replica set are:
|
||||
|
||||
```
|
||||
mongo-0.mongo
|
||||
|
||||
mongo-1.mongo
|
||||
|
||||
mongo-2.mongo
|
||||
```
|
||||
|
||||
You can use these names directly in the [connection string URI](http://docs.mongodb.com/manual/reference/connection-string) of your app.
|
||||
|
||||
|
||||
You can use these names directly in the [connection string URI](http://docs.mongodb.com/manual/reference/connection-string) of your app.
|
||||
|
||||
In this case, the connection string URI would be:
|
||||
|
||||
In this case, the connection string URI would be:
|
||||
|
||||
```
|
||||
“mongodb://mongo-0.mongo,mongo-1.mongo,mongo-2.mongo:27017/dbname\_?”
|
||||
mongodb://mongo-0.mongo,mongo-1.mongo,mongo-2.mongo:27017/dbname\_?
|
||||
```
|
||||
|
||||
That’s it!
|
||||
|
||||
That’s it!
|
||||
|
||||
**Scaling the MongoDB replica set**
|
||||
|
||||
A huge advantage of StatefulSets is that you can scale them just like Kubernetes ReplicaSets. If you want 5 MongoDB Nodes instead of 3, just run the scale command:
|
||||
|
||||
**Scaling the MongoDB replica set**
|
||||
|
||||
A huge advantage of StatefulSets is that you can scale them just like Kubernetes ReplicaSets. If you want 5 MongoDB Nodes instead of 3, just run the scale command:
|
||||
|
||||
```
|
||||
kubectl scale --replicas=5 statefulset mongo
|
||||
```
|
||||
|
||||
The sidecar container will automatically configure the new MongoDB nodes to join the replica set.
|
||||
|
||||
The sidecar container will automatically configure the new MongoDB nodes to join the replica set.
|
||||
Include the two new nodes (mongo-3.mongo & mongo-4.mongo) in your connection string URI and you are good to go. Too easy!
|
||||
|
||||
Include the two new nodes (mongo-3.mongo & mongo-4.mongo) in your connection string URI and you are good to go. Too easy!
|
||||
**Cleaning Up**
|
||||
|
||||
**Cleaning Up**
|
||||
|
||||
To clean up the deployed resources, delete the StatefulSet, Headless Service, and the provisioned volumes.
|
||||
|
||||
Delete the StatefulSet:
|
||||
To clean up the deployed resources, delete the StatefulSet, Headless Service, and the provisioned volumes.
|
||||
|
||||
Delete the StatefulSet:
|
||||
|
||||
```
|
||||
kubectl delete statefulset mongo
|
||||
```
|
||||
|
||||
|
||||
|
||||
Delete the Service:
|
||||
|
||||
Delete the Service:
|
||||
|
||||
```
|
||||
kubectl delete svc mongo
|
||||
```
|
||||
|
||||
|
||||
|
||||
Delete the Volumes:
|
||||
|
||||
|
||||
|
||||
Delete the Volumes:
|
||||
|
||||
```
|
||||
kubectl delete pvc -l role=mongo
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
Finally, you can delete the test cluster:
|
||||
|
||||
|
||||
|
||||
Finally, you can delete the test cluster:
|
||||
|
||||
```
|
||||
gcloud container clusters delete "test-cluster"
|
||||
```
|
||||
|
||||
|
||||
|
||||
Happy Hacking!
|
||||
|
||||
|
||||
|
||||
For more cool Kubernetes and Container blog posts, follow me on [Twitter](https://twitter.com/sandeepdinesh) and [Medium](https://medium.com/@SandeepDinesh).
|
||||
|
||||
|
||||
|
||||
_--Sandeep Dinesh, Developer Advocate, Google Cloud Platform._
|
||||
|
||||
+1
-1
@@ -76,7 +76,7 @@ Each Special Interest Group (SIG) within the community continues to deliver
|
||||
the most-requested enhancements, fixes, and functionality for their respective
|
||||
specialty areas. For a complete list of inclusions by SIG, please visit the
|
||||
[release
|
||||
notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#110-release-notes).
|
||||
notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#110-release-notes).
|
||||
|
||||
## Availability
|
||||
|
||||
|
||||
@@ -60,9 +60,7 @@ using `kube-apiserver --feature-gates DryRun=true`.
|
||||
If you have dynamic admission controllers, you might have to fix them to:
|
||||
|
||||
- Remove any side-effects when the dry-run parameter is specified on the webhook request,
|
||||
- Specify in the [`sideEffects`](/docs/reference/generated/kubernetes-api/v1.13/#webhook-v1beta1-admissionregistration)
|
||||
field of the `admissionregistration.k8s.io/v1beta1.Webhook` object to indicate that the object doesn't
|
||||
have side-effects on dry-run (or at all).
|
||||
- Specify in the [`sideEffects`](https://v1-13.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#webhook-v1beta1-admissionregistration) field of the `admissionregistration.k8s.io/v1beta1.Webhook` object to indicate that the object doesn't have side-effects on dry-run (or at all).
|
||||
|
||||
### How to use it
|
||||
|
||||
|
||||
@@ -71,7 +71,7 @@ Introducing CSI plugin support for out-of-tree providers, enabling Windows nodes
|
||||
|
||||
## Introducing Endpoint Slices
|
||||
|
||||
The release of Kubernetes 1.16 includes an exciting new alpha feature: the EndpointSlice API. This API provides a scalable and extensible alternative to the [Endpoints](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#endpoints-v1-core) resource, which dates back to the very first versions of Kubernetes. Behind the scenes, Endpoints play a big role in network routing within Kubernetes. Each Service endpoint is tracked within these resources - kube-proxy uses them for generating proxy rules that allow pods to communicate with each other so easily in Kubernetes, and many ingress controllers use them to route HTTP traffic directly to pods.
|
||||
The release of Kubernetes 1.16 includes an exciting new alpha feature: the EndpointSlice API. This API provides a scalable and extensible alternative to the [Endpoints](https://v1-16.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#endpoints-v1-core) resource, which dates back to the very first versions of Kubernetes. Behind the scenes, Endpoints play a big role in network routing within Kubernetes. Each Service endpoint is tracked within these resources - kube-proxy uses them for generating proxy rules that allow pods to communicate with each other so easily in Kubernetes, and many ingress controllers use them to route HTTP traffic directly to pods.
|
||||
|
||||
### Providing Greater Scalability
|
||||
|
||||
|
||||
@@ -43,14 +43,14 @@ Upon arrival at the handler, a request is assigned to exactly one priority level
|
||||
|
||||
* FlowSchema: FlowSchema will identify a PriorityLevelConfiguration object and the way to compute the request’s “flow identifier”. Currently we support matching requests according to: the identity making the request, the verb, and the target object. The identity can match in terms of: a username, a user group name, or a ServiceAccount. And as for the target objects, we can match by apiGroup, resource[/subresource], and namespace.
|
||||
* The flow identifier is used for shuffle sharding, so it’s important that requests have the same flow identifier if they are from the same source! We like to consider scenarios with “elephants” (which send many/heavy requests) vs “mice” (which send few/light requests): it is important to make sure the elephant’s requests all get the same flow identifier, otherwise they will look like many different mice to the system!
|
||||
* See the API Documentation [here](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io)!
|
||||
* See the API Documentation [here](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io)!
|
||||
|
||||
* PriorityLevelConfiguration: Defines a priority level.
|
||||
* For apiserver self requests, and any reentrant traffic (e.g., admission webhooks which themselves make API requests), a Priority Level can be marked “exempt”, which means that no queueing or limiting of any sort is done. This is to prevent priority inversions.
|
||||
* Each non-exempt Priority Level is configured with a number of "concurrency shares" and gets an isolated pool of concurrency to use. Requests of that Priority Level run in that pool when it is not full, never anywhere else. Each apiserver is configured with a total concurrency limit (taken to be the sum of the old limits on mutating and readonly requests), and this is then divided among the Priority Levels in proportion to their concurrency shares.
|
||||
* A non-exempt Priority Level may select a number of queues and a "hand size" to use for the shuffle sharding. Shuffle sharding maps flows to queues in a way that is better than consistent hashing. A given flow has access to a small collection of queues, and for each incoming request the shortest queue is chosen. When a Priority Level has queues, it also sets a limit on queue length. There is also a limit placed on how long a request can wait in its queue; this is a fixed fraction of the apiserver's request timeout. A request that cannot be executed and cannot be queued (any longer) is rejected.
|
||||
* Alternatively, a non-exempt Priority Level may select immediate rejection instead of waiting in a queue.
|
||||
* See the [API documentation](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io) for this feature.
|
||||
* See the [API documentation](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io) for this feature.
|
||||
|
||||
## What’s missing? When will there be a beta?
|
||||
We’re already planning a few enhancements based on alpha and there will be more as users send feedback to our community. Here’s a list of them:
|
||||
|
||||
+56
@@ -0,0 +1,56 @@
|
||||
---
|
||||
layout: blog
|
||||
title: Supporting the Evolving Ingress Specification in Kubernetes 1.18
|
||||
date: 2020-06-05
|
||||
slug: Supporting-the-Evolving-Ingress-Specification-in-Kubernetes-1.18
|
||||
---
|
||||
|
||||
**Authors:** Alex Gervais (Datawire.io)
|
||||
|
||||
Earlier this year, the Kubernetes team released [Kubernetes 1.18](https://kubernetes.io/blog/2020/03/25/kubernetes-1-18-release-announcement/), which extended Ingress. In this blog post, we’ll walk through what’s new in the new Ingress specification, what it means for your applications, and how to upgrade to an ingress controller that supports this new specification.
|
||||
|
||||
### What is Kubernetes Ingress
|
||||
When deploying your applications in Kubernetes, one of the first challenges many people encounter is how to get traffic into their cluster. [Kubernetes ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) is a collection of routing rules that govern how external users access services running in a Kubernetes cluster. There are [three general approaches](https://blog.getambassador.io/kubernetes-ingress-nodeport-load-balancers-and-ingress-controllers-6e29f1c44f2d) for exposing your application:
|
||||
|
||||
* Using a `NodePort` to expose your application on a port across each of your nodes
|
||||
* Using a `LoadBalancer` service to create an external load balancer that points to a Kubernetes service in your cluster
|
||||
* Using a Kubernetes Ingress resource
|
||||
|
||||
### What’s new in Kubernetes 1.18 Ingress
|
||||
There are three significant additions to the Ingress API in Kubernetes 1.18:
|
||||
|
||||
* A new `pathType` field
|
||||
* A new `IngressClass` resource
|
||||
* Support for wildcards in hostnames
|
||||
|
||||
The new `pathType` field allows you to specify how Ingress paths should match.
|
||||
The field supports three types: `ImplementationSpecific` (default), `exact`, and `prefix`. Explicitly defining the expected behavior of path matching will allow every ingress-controller to support a user’s needs and will increase portability between ingress-controller implementation solutions.
|
||||
|
||||
The `IngressClass` resource specifies how Ingresses should be implemented by controllers. This was added to formalize the commonly used but never standardized `kubernetes.io/ingress.class` annotation and allow for implementation-specific extensions and configuration.
|
||||
|
||||
You can read more about these changes, as well as the support for wildcards in hostnames in more detail in [a previous blog post](https://kubernetes.io/blog/2020/04/02/improvements-to-the-ingress-api-in-kubernetes-1.18/).
|
||||
|
||||
## Supporting Kubernetes ingress
|
||||
[Ambassador](https://www.getambassador.io) is an open-source Envoy-based ingress controller. We believe strongly in supporting common standards such as Kubernetes ingress, which we adopted and [announced our initial support for back in 2019](https://blog.getambassador.io/ambassador-ingress-controller-better-config-reporting-updated-envoy-proxy-99dc9139e28f).
|
||||
|
||||
Every Ambassador release goes through rigorous testing. Therefore, we also contributed an [open conformance test suite](https://github.com/kubernetes-sigs/ingress-controller-conformance), supporting Kubernetes ingress. We wrote the initial bits of test code and will keep iterating over the newly added features and different versions of the Ingress specification as it evolves to a stable v1 GA release. Documentation and usage samples, is one of our top priorities. We understand how complex usage can be, especially when transitioning from a previous version of an API.
|
||||
|
||||
Following a test-driven development approach, the first step we took in supporting Ingress improvements in Ambassador was to translate the revised specification -- both in terms of API and behavior -- into a comprehensible test suite. The test suite, although still under heavy development and going through multiple iterations, was rapidly added to the Ambassador CI infrastructure and acceptance criteria. This means every change to the Ambassador codebase going forward will be compliant with the Ingress API and be tested end-to-end in a lightweight [KIND cluster](https://kind.sigs.k8s.io/). Using KIND allowed us to make rapid improvements while limiting our cloud provider infrastructure bill and testing out unreleased Kubernetes features with pre-release builds.
|
||||
|
||||
### Adopting a new specification
|
||||
With a global comprehension of additions to Ingress introduced in Kubernetes 1.18 and a test suite on hand, we tackled the task of adapting the Ambassador code so that it would support translating the high-level Ingress API resources into Envoy configurations and constructs. Luckily Ambassador already supported previous versions of ingress functionalities so the development effort was incremental.
|
||||
|
||||
We settled on a controller name of `getambassador.io/ingress-controller`. This value, consistent with Ambassador's domain and CRD versions, must be used to tie in an IngressClass `spec.controller` with an Ambassador deployment. The new IngressClass resource allows for extensibility by setting a `spec.parameters` field. At the moment Ambassador makes no use of this field and its usage is reserved for future development.
|
||||
|
||||
Paths can now define different matching behaviors using the `pathType` field. The field will default to a value of `ImplementationSpecific`, which uses the same matching rules as the [Ambassador Mappings](https://www.getambassador.io/docs/latest/topics/using/mappings/) prefix field and previous Ingress specification for backward compatibility reasons.
|
||||
|
||||
### Kubernetes Ingress Controllers
|
||||
A comprehensive [list of Kubernetes ingress controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) is available in the Kubernetes documentation. Currently, Ambassador is the only ingress controller that supports these new additions to the ingress specification. Powered by the [Envoy Proxy](https://www.envoyproxy.io), Ambassador is the fastest way for you to try out the new ingress specification today.
|
||||
|
||||
Check out the following resources:
|
||||
|
||||
* Ambassador on [GitHub](https://www.github.com/datawire/ambassador)
|
||||
* The Ambassador [documentation](https://www.getambassador.io/docs)
|
||||
* [Improvements to the Ingress API](https://kubernetes.io/blog/2020/04/02/improvements-to-the-ingress-api-in-kubernetes-1.18/)
|
||||
|
||||
Or join the community on [Slack](http://d6e.co/slack)!
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
layout: blog
|
||||
title: A Better Docs UX With Docsy
|
||||
date: 2020-06-15
|
||||
slug: better-docs-ux-with-docsy
|
||||
url: /blog/2020/06/better-docs-ux-with-docsy
|
||||
---
|
||||
|
||||
**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).*
|
||||
|
||||
I'm pleased to announce that the [Kubernetes website](https://kubernetes.io) now features the [Docsy Hugo theme](https://docsy.dev).
|
||||
|
||||
The Docsy theme improves the site's organization and navigability, and opens a path to improved API references. After over 4 years with few meaningful UX improvements, Docsy implements some best practices for technical content. The theme makes the Kubernetes site easier to read and makes individual pages easier to navigate. It gives the site a much-needed facelift.
|
||||
|
||||
For example: adding a right-hand rail for navigating topics on the page. No more scrolling up to navigate!
|
||||
|
||||
The theme opens a path for future improvements to the website. The Docsy functionality I'm most excited about is the theme's [`swaggerui` shortcode](https://www.docsy.dev/docs/adding-content/shortcodes/#swaggerui), which provides native support for generating API references from an OpenAPI spec. The CNCF is partnering with [Google Season of Docs](https://developers.google.com/season-of-docs) (GSoD) for staffing to make better API references a reality in Q4 this year. We're hopeful to be chosen, and we're looking forward to Google's list of announced projects on August 16th. Better API references have been a personal goal since I first started working with SIG Docs in 2017. It's exciting to see the goal within reach.
|
||||
|
||||
One of SIG Docs' tech leads, [Karen Bradshaw](https://github.com/kbhawkey) did a lot of heavy lifting to fix a wide range of site compatibility issues, including a fix to the last of our [legacy pieces](https://github.com/kubernetes/website/pull/21359) when we [migrated from Jekyll to Hugo](2018-05-05-hugo-migration/) in 2018. Our other tech leads, [Tim Bannister](https://github.com/sftim) and [Taylor Dolezal](https://github.com/onlydole) provided extensive reviews.
|
||||
|
||||
Thanks also to [Björn-Erik Pedersen](https://bep.is/), who provided invaluable advice about how to navigate a Hugo upgrade beyond [version 0.60.0](https://gohugo.io/news/0.60.0-relnotes/).
|
||||
|
||||
The CNCF contracted with [Gearbox](https://gearboxbuilt.com/) in Victoria, BC to apply the theme to the site. Thanks to Aidan, Troy, and the rest of the team for all their work!
|
||||
@@ -17,7 +17,7 @@ cid: community
|
||||
<br class="mobile">
|
||||
</div>
|
||||
|
||||
<div class="navbar">
|
||||
<div class="community__navbar">
|
||||
|
||||
<a href="#conduct">Code of conduct </a>
|
||||
<a href="#videos">Videos</a>
|
||||
|
||||
@@ -1,71 +1,14 @@
|
||||
---
|
||||
title: Concepts
|
||||
main_menu: true
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
The Concepts section helps you learn about the parts of the Kubernetes system and the abstractions Kubernetes uses to represent your {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}}, and helps you obtain a deeper understanding of how Kubernetes works.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Overview
|
||||
|
||||
To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state.
|
||||
|
||||
Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:
|
||||
|
||||
* The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/).
|
||||
* Each individual non-master node in your cluster runs two processes:
|
||||
* **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master.
|
||||
* **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node.
|
||||
|
||||
## Kubernetes objects
|
||||
|
||||
Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) for more details.
|
||||
|
||||
The basic Kubernetes objects include:
|
||||
|
||||
* [Pod](/docs/concepts/workloads/pods/pod-overview/)
|
||||
* [Service](/docs/concepts/services-networking/service/)
|
||||
* [Volume](/docs/concepts/storage/volumes/)
|
||||
* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
|
||||
Kubernetes also contains higher-level abstractions that rely on [controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include:
|
||||
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
|
||||
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
|
||||
|
||||
## Kubernetes Control Plane
|
||||
|
||||
The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided.
|
||||
|
||||
For example, when you use the Kubernetes API to create a Deployment, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state.
|
||||
|
||||
### Kubernetes Master
|
||||
|
||||
The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master.
|
||||
|
||||
> The "master" refers to a collection of processes managing the cluster state. Typically all these processes run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy.
|
||||
|
||||
### Kubernetes Nodes
|
||||
|
||||
The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
If you would like to write a concept page, see
|
||||
[Using Page Templates](/docs/home/contribute/page-templates/)
|
||||
for information about the concept page type and the concept template.
|
||||
|
||||
{{% /capture %}}
|
||||
<!-- body -->
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
---
|
||||
title: "Cluster Architecture"
|
||||
weight: 30
|
||||
description: >
|
||||
The architectural concepts behind Kubernetes.
|
||||
---
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: Cloud Controller Manager
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
|
||||
|
||||
@@ -17,9 +17,9 @@ components.
|
||||
The cloud-controller-manager is structured using a plugin
|
||||
mechanism that allows different cloud providers to integrate their platforms with Kubernetes.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Design
|
||||
|
||||
@@ -200,8 +200,9 @@ rules:
|
||||
- update
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
|
||||
has instructions on running and managing the cloud controller manager.
|
||||
|
||||
@@ -212,4 +213,3 @@ The cloud controller manager uses Go interfaces to allow implementations from an
|
||||
The implementation of the shared controllers highlighted in this document (Node, Route, and Service), and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core. Implementations specific to cloud providers are outside the core of Kubernetes and implement the `CloudProvider` interface.
|
||||
|
||||
For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
{{% /capture %}}
|
||||
@@ -1,25 +1,24 @@
|
||||
---
|
||||
reviewers:
|
||||
- dchen1107
|
||||
- roberthbailey
|
||||
- liggitt
|
||||
title: Control Plane-Node Communication
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 20
|
||||
aliases:
|
||||
- master-node-communication
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This document catalogs the communication paths between the control plane (really the apiserver) and the Kubernetes cluster. The intent is to allow users to customize their installation to harden the network configuration such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud provider).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Node to Control Plane
|
||||
All communication paths from the nodes to the control plane terminate at the apiserver (none of the other master components are designed to expose remote services). In a typical deployment, the apiserver is configured to listen for remote connections on a secure HTTPS port (443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled.
|
||||
Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminate at the apiserver (none of the other control plane components are designed to expose remote services). The apiserver is configured to listen for remote connections on a secure HTTPS port (typically 443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled.
|
||||
One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) should be enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed.
|
||||
|
||||
Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
|
||||
@@ -32,9 +31,11 @@ The control plane components also communicate with the cluster apiserver over th
|
||||
As a result, the default operating mode for connections from the nodes and pods running on the nodes to the control plane is secured by default and can run over untrusted and/or public networks.
|
||||
|
||||
## Control Plane to node
|
||||
|
||||
There are two primary communication paths from the control plane (apiserver) to the nodes. The first is from the apiserver to the kubelet process which runs on each node in the cluster. The second is from the apiserver to any node, pod, or service through the apiserver's proxy functionality.
|
||||
|
||||
### apiserver to kubelet
|
||||
|
||||
The connections from the apiserver to the kubelet are used for:
|
||||
|
||||
* Fetching logs for pods.
|
||||
@@ -62,9 +63,10 @@ This tunnel ensures that the traffic is not exposed outside of the network in wh
|
||||
SSH tunnels are currently deprecated so you shouldn't opt to use them unless you know what you are doing. The Konnectivity service is a replacement for this communication channel.
|
||||
|
||||
### Konnectivity service
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the control plane to Cluster communication. The Konnectivity consists of two parts, the Konnectivity server and the Konnectivity agents, running in the control plane network and the nodes network respectively. The Konnectivity agents initiate connections to the Konnectivity server and maintain the connections.
|
||||
All control plane to nodes traffic then goes through these connections.
|
||||
As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the control plane to cluster communication. The Konnectivity service consists of two parts: the Konnectivity server and the Konnectivity agents, running in the control plane network and the nodes network respectively. The Konnectivity agents initiate connections to the Konnectivity server and maintain the network connections.
|
||||
After enabling the Konnectivity service, all control plane to nodes traffic goes through these connections.
|
||||
|
||||
See [Konnectivity Service Setup](/docs/tasks/setup-konnectivity/) on how to set it up in your cluster.
|
||||
Follow the [Konnectivity service task](/docs/tasks/extend-kubernetes/setup-konnectivity/) to set up the Konnectivity service in your cluster.
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: Controllers
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
In robotics and automation, a _control loop_ is
|
||||
a non-terminating loop that regulates the state of a system.
|
||||
@@ -18,10 +18,10 @@ closer to the desired state, by turning equipment on or off.
|
||||
|
||||
{{< glossary_definition term_id="controller" length="short">}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Controller pattern
|
||||
|
||||
@@ -150,11 +150,12 @@ You can run your own controller as a set of Pods,
|
||||
or externally to Kubernetes. What fits best will depend on what that particular
|
||||
controller does.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read about the [Kubernetes control plane](/docs/concepts/#kubernetes-control-plane)
|
||||
* Discover some of the basic [Kubernetes objects](/docs/concepts/#kubernetes-objects)
|
||||
* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
|
||||
* If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes.
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -3,11 +3,11 @@ reviewers:
|
||||
- caesarxuchao
|
||||
- dchen1107
|
||||
title: Nodes
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
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
|
||||
@@ -23,9 +23,9 @@ The [components](/docs/concepts/overview/components/#node-components) on a node
|
||||
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}, and the
|
||||
{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Management
|
||||
|
||||
@@ -332,12 +332,13 @@ the kubelet can use topology hints when making resource assignment decisions.
|
||||
See [Control Topology Management Policies on a Node](/docs/tasks/administer-cluster/topology-manager/)
|
||||
for more information.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* 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 %}}
|
||||
|
||||
|
||||
Executable → Regular
+70
-1
@@ -1,5 +1,74 @@
|
||||
---
|
||||
title: "Cluster Administration"
|
||||
title: Cluster Administration
|
||||
reviewers:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
weight: 100
|
||||
content_type: concept
|
||||
description: >
|
||||
Lower-level detail relevant to creating or administering a Kubernetes cluster.
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
|
||||
It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## Planning a cluster
|
||||
|
||||
See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*.
|
||||
|
||||
{{< note >}}
|
||||
Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
|
||||
{{< /note >}}
|
||||
|
||||
Before choosing a guide, here are some considerations:
|
||||
|
||||
- Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
|
||||
- Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
|
||||
- Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
|
||||
- **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
|
||||
- Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
|
||||
- Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
|
||||
latter, choose an actively-developed distro. Some distros only use binary releases, but
|
||||
offer a greater variety of choices.
|
||||
- Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster.
|
||||
|
||||
|
||||
## Managing a cluster
|
||||
|
||||
* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
|
||||
|
||||
* Learn how to [manage nodes](/docs/concepts/nodes/node/).
|
||||
|
||||
* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
|
||||
|
||||
## Securing a cluster
|
||||
|
||||
* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains.
|
||||
|
||||
* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
|
||||
|
||||
* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts.
|
||||
|
||||
* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
|
||||
|
||||
* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
|
||||
|
||||
* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
|
||||
|
||||
* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
|
||||
|
||||
* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
|
||||
|
||||
### Securing the kubelet
|
||||
* [Master-Node communication](/docs/concepts/architecture/master-node-communication/)
|
||||
* [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
* [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
|
||||
|
||||
## Optional Cluster Services
|
||||
|
||||
* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
|
||||
|
||||
* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
---
|
||||
title: Installing Addons
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
|
||||
Add-ons extend the functionality of Kubernetes.
|
||||
@@ -12,10 +12,10 @@ This page lists some of the available add-ons and links to their respective inst
|
||||
|
||||
Add-ons in each section are sorted alphabetically - the ordering does not imply any preferential status.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Networking and Network Policy
|
||||
|
||||
@@ -55,4 +55,4 @@ There are several other add-ons documented in the deprecated [cluster/addons](ht
|
||||
|
||||
Well-maintained ones should be linked to here. PRs welcome!
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,19 +1,19 @@
|
||||
---
|
||||
title: Certificates
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
When using client certificate authentication, you can generate certificates
|
||||
manually through `easyrsa`, `openssl` or `cfssl`.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
### easyrsa
|
||||
|
||||
@@ -249,4 +249,4 @@ You can use the `certificates.k8s.io` API to provision
|
||||
x509 certificates to use for authentication as documented
|
||||
[here](/docs/tasks/tls/managing-tls-in-a-cluster).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,16 +1,16 @@
|
||||
---
|
||||
title: Cloud Providers
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
This page explains how to manage Kubernetes running on a specific
|
||||
cloud provider.
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
### kubeadm
|
||||
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) is a popular option for creating kubernetes clusters.
|
||||
kubeadm has configuration options to specify configuration information for cloud providers. For example a typical
|
||||
@@ -99,7 +99,7 @@ Different settings can be applied to a load balancer service in AWS using _annot
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout.
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout.
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: Used on the service to enable or disable cross-zone load balancing.
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB.
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: Used to specify the security groups to be added to ELB created. This replaces all other security groups previously assigned to the ELB. Security groups defined here should not be shared between services.
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: Used on the service to specify additional security groups to be added to ELB created
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-internal`: Used on the service to indicate that we want an internal ELB.
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: Used on the service to enable the proxy protocol on an ELB. Right now we only accept the value `*` which means enabling the proxy protocol on all ELB backends. In the future we could adjust this to allow setting the proxy protocol only on certain backends.
|
||||
@@ -363,7 +363,7 @@ Kubernetes network plugin and should appear in the `[Route]` section of the
|
||||
|
||||
[kubenet]: /docs/concepts/cluster-administration/network-plugins/#kubenet
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
## OVirt
|
||||
|
||||
@@ -433,4 +433,4 @@ Alibaba Cloud does not require the format of node name, but the kubelet needs to
|
||||
|
||||
### Load Balancers
|
||||
|
||||
You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) .
|
||||
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) .
|
||||
|
||||
@@ -1,73 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
title: Cluster Administration Overview
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
|
||||
It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## Planning a cluster
|
||||
|
||||
See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*.
|
||||
|
||||
Before choosing a guide, here are some considerations:
|
||||
|
||||
- Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
|
||||
- Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
|
||||
- Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
|
||||
- **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
|
||||
- Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
|
||||
- Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
|
||||
latter, choose an actively-developed distro. Some distros only use binary releases, but
|
||||
offer a greater variety of choices.
|
||||
- Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster.
|
||||
|
||||
Note: Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
|
||||
|
||||
## Managing a cluster
|
||||
|
||||
* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
|
||||
|
||||
* Learn how to [manage nodes](/docs/concepts/nodes/node/).
|
||||
|
||||
* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
|
||||
|
||||
## Securing a cluster
|
||||
|
||||
* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains.
|
||||
|
||||
* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
|
||||
|
||||
* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts.
|
||||
|
||||
* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
|
||||
|
||||
* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
|
||||
|
||||
* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
|
||||
|
||||
* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
|
||||
|
||||
* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
|
||||
|
||||
### Securing the kubelet
|
||||
* [Master-Node communication](/docs/concepts/architecture/master-node-communication/)
|
||||
* [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
* [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
|
||||
|
||||
## Optional Cluster Services
|
||||
|
||||
* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
|
||||
|
||||
* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: API Priority and Fairness
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
min-kubernetes-server-version: v1.18
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state state="alpha" for_k8s_version="v1.18" >}}
|
||||
|
||||
@@ -33,9 +33,9 @@ the `--max-requests-inflight` flag without the API Priority and
|
||||
Fairness feature enabled.
|
||||
{{< /caution >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Enabling API Priority and Fairness
|
||||
|
||||
@@ -136,7 +136,7 @@ classes:
|
||||
controllers.
|
||||
|
||||
* The `workload-low` priority level is for requests from any other service
|
||||
account, which will typically include all requests from controllers runing in
|
||||
account, which will typically include all requests from controllers running in
|
||||
Pods.
|
||||
|
||||
* The `global-default` priority level handles all other traffic, e.g.
|
||||
@@ -366,13 +366,13 @@ poorly-behaved workloads that may be harming system health.
|
||||
request and the PriorityLevel to which it was assigned.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
For background information on design details for API priority and fairness, see
|
||||
the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md).
|
||||
You can make suggestions and feature requests via [SIG API
|
||||
Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -1,20 +1,20 @@
|
||||
---
|
||||
reviewers:
|
||||
title: Configuring kubelet Garbage Collection
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Garbage collection is a helpful function of kubelet that will clean up unused images and unused containers. Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes.
|
||||
|
||||
External garbage collection tools are not recommended as these tools can potentially break the behavior of kubelet by removing containers expected to exist.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Image Collection
|
||||
|
||||
@@ -77,10 +77,11 @@ Including:
|
||||
| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources |
|
||||
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources |
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
See [Configuring Out Of Resource Handling](/docs/tasks/administer-cluster/out-of-resource/) for more details.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -3,20 +3,20 @@ reviewers:
|
||||
- piosz
|
||||
- x13n
|
||||
title: Logging Architecture
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Application and systems logs can help you understand what is happening inside your cluster. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism; as such, most container engines are likewise designed to support some kind of logging. The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams.
|
||||
|
||||
However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution. For example, if a container crashes, a pod is evicted, or a node dies, you'll usually still want to access your application's logs. As such, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level-logging_. Cluster-level logging requires a separate backend to store, analyze, and query logs. Kubernetes provides no native storage solution for log data, but you can integrate many existing logging solutions into your Kubernetes cluster.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
Cluster-level logging architectures are described in assumption that
|
||||
a logging backend is present inside or outside of your cluster. If you're
|
||||
@@ -267,4 +267,4 @@ You can implement cluster-level logging by exposing or pushing logs directly fro
|
||||
every application; however, the implementation for such a logging mechanism
|
||||
is outside the scope of Kubernetes.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -2,18 +2,18 @@
|
||||
reviewers:
|
||||
- janetkuo
|
||||
title: Managing Resources
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features that we will discuss in more depth are [configuration files](/docs/concepts/configuration/overview/) and [labels](/docs/concepts/overview/working-with-objects/labels/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Organizing resource configurations
|
||||
|
||||
@@ -402,7 +402,7 @@ For more information, please see [kubectl edit](/docs/reference/generated/kubect
|
||||
|
||||
You can use `kubectl patch` to update API objects in place. This command supports JSON patch,
|
||||
JSON merge patch, and strategic merge patch. See
|
||||
[Update API Objects in Place Using kubectl patch](/docs/tasks/run-application/update-api-object-kubectl-patch/)
|
||||
[Update API Objects in Place Using kubectl patch](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
|
||||
and
|
||||
[kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch).
|
||||
|
||||
@@ -449,11 +449,12 @@ kubectl edit deployment/my-nginx
|
||||
|
||||
That's it! The Deployment will declaratively update the deployed nginx application progressively behind the scene. It ensures that only a certain number of old replicas may be down while they are being updated, and only a certain number of new replicas may be created above the desired number of pods. To learn more details about it, visit [Deployment page](/docs/concepts/workloads/controllers/deployment/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
- Learn about [how to use `kubectl` for application introspection and debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/).
|
||||
- See [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -4,21 +4,21 @@ reviewers:
|
||||
- brancz
|
||||
- logicalhan
|
||||
- RainbowMango
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 60
|
||||
aliases:
|
||||
- controller-metrics.md
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
System component metrics can give a better look into what is happening inside them. Metrics are particularly useful for building dashboards and alerts.
|
||||
|
||||
Metrics in Kubernetes control plane are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Metrics in Kubernetes
|
||||
|
||||
@@ -124,10 +124,11 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
|
||||
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics
|
||||
* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)
|
||||
* Read about the [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
reviewers:
|
||||
- thockin
|
||||
title: Cluster Networking
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
Networking is a central part of Kubernetes, but it can be challenging to
|
||||
understand exactly how it is expected to work. There are 4 distinct networking
|
||||
problems to address:
|
||||
@@ -17,10 +17,10 @@ problems to address:
|
||||
3. Pod-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
|
||||
4. External-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
Kubernetes is all about sharing machines between applications. Typically,
|
||||
sharing machines requires ensuring that two applications do not try to use the
|
||||
@@ -312,12 +312,13 @@ Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-pl
|
||||
or stand-alone. In either version, it doesn't require any configuration or extra code
|
||||
to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
The early design of the networking model and its rationale, and some future
|
||||
plans are described in more detail in the [networking design
|
||||
document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
---
|
||||
title: Proxies in Kubernetes
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 90
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
This page explains proxies used with Kubernetes.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Proxies
|
||||
|
||||
@@ -62,6 +62,6 @@ will typically ensure that the latter types are setup correctly.
|
||||
|
||||
Proxies have replaced redirect capabilities. Redirects have been deprecated.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
---
|
||||
title: "Configuration"
|
||||
weight: 80
|
||||
description: >
|
||||
Resources that Kubernetes provides for configuring Pods.
|
||||
---
|
||||
|
||||
|
||||
@@ -1,23 +1,23 @@
|
||||
---
|
||||
title: ConfigMaps
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< glossary_definition term_id="configmap" prepend="A ConfigMap is" length="all" >}}
|
||||
|
||||
{{< caution >}}
|
||||
ConfigMap does not provide secrecy or encryption.
|
||||
ConfigMap does not provide secrecy or encryption.
|
||||
If the data you want to store are confidential, use a
|
||||
{{< glossary_tooltip text="Secret" term_id="secret" >}} rather than a ConfigMap,
|
||||
or use additional (third party) tools to keep your data private.
|
||||
{{< /caution >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
## Motivation
|
||||
|
||||
Use a ConfigMap for setting configuration data separately from application code.
|
||||
@@ -60,7 +60,7 @@ metadata:
|
||||
name: game-demo
|
||||
data:
|
||||
# property-like keys; each key maps to a simple value
|
||||
player_initial_lives: 3
|
||||
player_initial_lives: "3"
|
||||
ui_properties_file_name: "user-interface.properties"
|
||||
#
|
||||
# file-like keys
|
||||
@@ -85,9 +85,9 @@ These different methods lend themselves to different ways of modeling
|
||||
the data being consumed.
|
||||
For the first three methods, the
|
||||
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} uses the data from
|
||||
the Secret when it launches container(s) for a Pod.
|
||||
the ConfigMap when it launches container(s) for a Pod.
|
||||
|
||||
The fourth method means you have to write code to read the Secret and its data.
|
||||
The fourth method means you have to write code to read the ConfigMap and its data.
|
||||
However, because you're using the Kubernetes API directly, your application can
|
||||
subscribe to get updates whenever the ConfigMap changes, and react
|
||||
when that happens. By accessing the Kubernetes API directly, this
|
||||
@@ -131,7 +131,7 @@ spec:
|
||||
|
||||
A ConfigMap doesn't differentiate between single line property values and
|
||||
multi-line file-like values.
|
||||
What matters how Pods and other objects consume those values.
|
||||
What matters is how Pods and other objects consume those values.
|
||||
For this example, defining a volume and mounting it inside the `demo`
|
||||
container as `/config` creates four files:
|
||||
|
||||
@@ -157,13 +157,99 @@ or {{< glossary_tooltip text="operators" term_id="operator-pattern" >}} that
|
||||
adjust their behavior based on a ConfigMap.
|
||||
{{< /note >}}
|
||||
|
||||
## Using ConfigMaps
|
||||
|
||||
ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other
|
||||
parts of the system, without being directly exposed to the Pod. For example,
|
||||
ConfigMaps can hold data that other parts of the system should use for configuration.
|
||||
|
||||
### Using ConfigMaps as files from a Pod
|
||||
|
||||
To consume a ConfigMap in a volume in a Pod:
|
||||
|
||||
1. Create a config map or use an existing one. Multiple Pods can reference the same config map.
|
||||
1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].configMap.name` field set to reference your ConfigMap object.
|
||||
1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the config map. Specify `.spec.containers[].volumeMounts[].readOnly = true` and `.spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the config map to appear.
|
||||
1. Modify your image or command line so that the program looks for files in that directory. Each key in the config map `data` map becomes the filename under `mountPath`.
|
||||
|
||||
This is an example of a Pod that mounts a ConfigMap in a volume:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: mypod
|
||||
spec:
|
||||
containers:
|
||||
- name: mypod
|
||||
image: redis
|
||||
volumeMounts:
|
||||
- name: foo
|
||||
mountPath: "/etc/foo"
|
||||
readOnly: true
|
||||
volumes:
|
||||
- name: foo
|
||||
configMap:
|
||||
name: myconfigmap
|
||||
```
|
||||
|
||||
Each ConfigMap you want to use needs to be referred to in `.spec.volumes`.
|
||||
|
||||
If there are multiple containers in the Pod, then each container needs its
|
||||
own `volumeMounts` block, but only one `.spec.volumes` is needed per ConfigMap.
|
||||
|
||||
#### Mounted ConfigMaps are updated automatically
|
||||
|
||||
When a config map currently consumed in a volume is updated, projected keys are eventually updated as well.
|
||||
The kubelet checks whether the mounted config map is fresh on every periodic sync.
|
||||
However, the kubelet uses its local cache for getting the current value of the ConfigMap.
|
||||
The type of the cache is configurable using the `ConfigMapAndSecretChangeDetectionStrategy` field in
|
||||
the [KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
|
||||
A ConfigMap can be either propagated by watch (default), ttl-based, or simply redirecting
|
||||
all requests directly to the API server.
|
||||
As a result, the total delay from the moment when the ConfigMap is updated to the moment
|
||||
when new keys are projected to the Pod can be as long as the kubelet sync period + cache
|
||||
propagation delay, where the cache propagation delay depends on the chosen cache type
|
||||
(it equals to watch propagation delay, ttl of cache, or zero correspondingly).
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
|
||||
|
||||
The Kubernetes alpha feature _Immutable Secrets and ConfigMaps_ provides an option to set
|
||||
individual Secrets and ConfigMaps as immutable. For clusters that extensively use ConfigMaps
|
||||
(at least tens of thousands of unique ConfigMap to Pod mounts), preventing changes to their
|
||||
data has the following advantages:
|
||||
|
||||
- protects you from accidental (or unwanted) updates that could cause applications outages
|
||||
- improves performance of your cluster by significantly reducing load on kube-apiserver, by
|
||||
closing watches for config maps marked as immutable.
|
||||
|
||||
To use this feature, enable the `ImmutableEmphemeralVolumes`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set
|
||||
your Secret or ConfigMap `immutable` field to `true`. For example:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
...
|
||||
data:
|
||||
...
|
||||
immutable: true
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Once a ConfigMap or Secret is marked as immutable, it is _not_ possible to revert this change
|
||||
nor to mutate the contents of the `data` field. You can only delete and recreate the ConfigMap.
|
||||
Existing Pods maintain a mount point to the deleted ConfigMap - it is recommended to recreate
|
||||
these pods.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* Read about [Secrets](/docs/concepts/configuration/secret/).
|
||||
* Read [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
|
||||
* Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for
|
||||
separating code from configuration.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Managing Resources for Containers
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 40
|
||||
feature:
|
||||
title: Automatic bin packing
|
||||
@@ -8,7 +8,7 @@ feature:
|
||||
Automatically places containers based on their resource requirements and other constraints, while not sacrificing availability. Mix critical and best-effort workloads in order to drive up utilization and save even more resources.
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
When you specify a {{< glossary_tooltip term_id="pod" >}}, you can optionally specify how
|
||||
much of each resource a {{< glossary_tooltip text="Container" term_id="container" >}} needs.
|
||||
@@ -21,10 +21,10 @@ allowed to use more of that resource than the limit you set. The kubelet also re
|
||||
at least the _request_ amount of that system resource specifically for that container
|
||||
to use.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Requests and limits
|
||||
|
||||
@@ -740,10 +740,11 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Get hands-on experience [assigning Memory resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/).
|
||||
|
||||
@@ -758,4 +759,4 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh
|
||||
|
||||
* Read about [project quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: Organizing Cluster Access Using kubeconfig Files
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Use kubeconfig files to organize information about clusters, users, namespaces, and
|
||||
authentication mechanisms. The `kubectl` command-line tool uses kubeconfig files to
|
||||
@@ -25,10 +25,10 @@ variable or by setting the
|
||||
For step-by-step instructions on creating and specifying kubeconfig files, see
|
||||
[Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Supporting multiple clusters, users, and authentication mechanisms
|
||||
|
||||
@@ -143,14 +143,15 @@ File references on the command line are relative to the current working director
|
||||
In `$HOME/.kube/config`, relative paths are stored relatively, and absolute paths
|
||||
are stored absolutely.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,17 +2,17 @@
|
||||
reviewers:
|
||||
- mikedanese
|
||||
title: Configuration Best Practices
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
This document highlights and consolidates configuration best practices that are introduced throughout the user guide, Getting Started documentation, and examples.
|
||||
|
||||
This is a living document. If you think of something that is not on this list but might be useful to others, please don't hesitate to file an issue or submit a PR.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
## General Configuration Tips
|
||||
|
||||
- When defining configurations, specify the latest stable API version.
|
||||
@@ -34,7 +34,7 @@ This is a living document. If you think of something that is not on this list bu
|
||||
|
||||
- Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure.
|
||||
|
||||
A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) may also be appropriate.
|
||||
A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/job/) may also be appropriate.
|
||||
|
||||
|
||||
## Services
|
||||
@@ -103,7 +103,7 @@ The caching semantics of the underlying image provider make even `imagePullPolic
|
||||
|
||||
- Use label selectors for `get` and `delete` operations instead of specific object names. See the sections on [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
|
||||
|
||||
- Use `kubectl run` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example.
|
||||
- Use `kubectl create deployment` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -4,11 +4,11 @@ reviewers:
|
||||
- egernst
|
||||
- tallclair
|
||||
title: Pod Overhead
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
@@ -19,10 +19,10 @@ _Pod Overhead_ is a feature for accounting for the resources consumed by the Pod
|
||||
on top of the container requests & limits.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
In Kubernetes, the Pod's overhead is set at
|
||||
[admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)
|
||||
@@ -188,11 +188,12 @@ running with a defined Overhead. This functionality is not available in the 1.9
|
||||
kube-state-metrics, but is expected in a following release. Users will need to build kube-state-metrics
|
||||
from source in the meantime.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [RuntimeClass](/docs/concepts/containers/runtime-class/)
|
||||
* [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -3,11 +3,11 @@ reviewers:
|
||||
- davidopp
|
||||
- wojtek-t
|
||||
title: Pod Priority and Preemption
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
|
||||
|
||||
@@ -16,9 +16,9 @@ importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the
|
||||
scheduler tries to preempt (evict) lower priority Pods to make scheduling of the
|
||||
pending Pod possible.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
||||
{{< warning >}}
|
||||
@@ -407,7 +407,8 @@ usage does not exceed their requests. If a Pod with lower priority is not
|
||||
exceeding its requests, it won't be evicted. Another Pod with higher priority
|
||||
that exceeds its requests may be evicted.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read about using ResourceQuotas in connection with PriorityClasses: [limit Priority Class consumption by default](/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -4,19 +4,19 @@ reviewers:
|
||||
- k82cn
|
||||
- ahg-g
|
||||
title: Resource Bin Packing for Extended Resources
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
|
||||
The kube-scheduler can be configured to enable bin packing of resources along with extended resources using `RequestedToCapacityRatioResourceAllocation` priority function. Priority functions can be used to fine-tune the kube-scheduler as per custom needs.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
|
||||
|
||||
@@ -132,23 +132,23 @@ CPU: 1
|
||||
Node Score:
|
||||
|
||||
intel.com/foo = resourceScoringFunction((2+1),4)
|
||||
= (100 - ((4-3)*100/4)
|
||||
= (100 - 25)
|
||||
= 75
|
||||
= rawScoringFunction(75)
|
||||
= 7
|
||||
= (100 - ((4-3)*100/4)
|
||||
= (100 - 25)
|
||||
= 75 # requested + used = 75% * available
|
||||
= rawScoringFunction(75)
|
||||
= 7 # floor(75/10)
|
||||
|
||||
Memory = resourceScoringFunction((256+256),1024)
|
||||
= (100 -((1024-512)*100/1024))
|
||||
= 50
|
||||
= 50 # requested + used = 50% * available
|
||||
= rawScoringFunction(50)
|
||||
= 5
|
||||
= 5 # floor(50/10)
|
||||
|
||||
CPU = resourceScoringFunction((2+1),8)
|
||||
= (100 -((8-3)*100/8))
|
||||
= 37.5
|
||||
= 37.5 # requested + used = 37.5% * available
|
||||
= rawScoringFunction(37.5)
|
||||
= 3
|
||||
= 3 # floor(37.5/10)
|
||||
|
||||
NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
|
||||
= 5
|
||||
@@ -194,4 +194,4 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
|
||||
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
reviewers:
|
||||
- mikedanese
|
||||
title: Secrets
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
feature:
|
||||
title: Secret and configuration management
|
||||
description: >
|
||||
@@ -10,16 +10,16 @@ feature:
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetes Secrets let you store and manage sensitive information, such
|
||||
as passwords, OAuth tokens, and ssh keys. Storing confidential information in a Secret
|
||||
is safer and more flexible than putting it verbatim in a
|
||||
{{< glossary_tooltip term_id="pod" >}} definition or in a {{< glossary_tooltip text="container image" term_id="image" >}}. See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Overview of Secrets
|
||||
|
||||
@@ -29,12 +29,13 @@ Pod specification or in an image. Users can create secrets and the system
|
||||
also creates some secrets.
|
||||
|
||||
To use a secret, a Pod needs to reference the secret.
|
||||
A secret can be used with a Pod in two ways:
|
||||
A secret can be used with a Pod in three ways:
|
||||
|
||||
- As files in a
|
||||
- As [files](#using-secrets-as-files-from-a-pod) in a
|
||||
{{< glossary_tooltip text="volume" term_id="volume" >}} mounted on one or more of
|
||||
its containers.
|
||||
- By the kubelet when pulling images for the Pod.
|
||||
- As [container environment variable](#using-secrets-as-environment-variables).
|
||||
- By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod.
|
||||
|
||||
### Built-in Secrets
|
||||
|
||||
@@ -725,7 +726,7 @@ data has the following advantages:
|
||||
- improves performance of your cluster by significantly reducing load on kube-apiserver, by
|
||||
closing watches for secrets marked as immutable.
|
||||
|
||||
To use this feature, enable the `ImmutableEmphemeralVolumes`
|
||||
To use this feature, enable the `ImmutableEphemeralVolumes`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set
|
||||
your Secret or ConfigMap `immutable` field to `true`. For example:
|
||||
```yaml
|
||||
|
||||
Executable → Regular
+40
-1
@@ -1,5 +1,44 @@
|
||||
---
|
||||
title: "Containers"
|
||||
title: Containers
|
||||
weight: 40
|
||||
description: Technology for packaging an application along with its runtime dependencies.
|
||||
reviewers:
|
||||
- erictune
|
||||
- thockin
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Each container that you run is repeatable; the standardization from having
|
||||
dependencies included means that you get the same behavior wherever you
|
||||
run it.
|
||||
|
||||
Containers decouple applications from underlying host infrastructure.
|
||||
This makes deployment easier in different cloud or OS environments.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Container images
|
||||
A [container image](/docs/concepts/containers/images/) is a ready-to-run
|
||||
software package, containing everything needed to run an application:
|
||||
the code and any runtime it requires, application and system libraries,
|
||||
and default values for any essential settings.
|
||||
|
||||
By design, a container is immutable: you cannot change the code of a
|
||||
container that is already running. If you have a containerized application
|
||||
and want to make changes, you need to build a new container that includes
|
||||
the change, then recreate the container to start from the updated image.
|
||||
|
||||
## Container runtimes
|
||||
|
||||
{{< glossary_definition term_id="container-runtime" length="all" >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read about [container images](/docs/concepts/containers/images/)
|
||||
* Read about [Pods](/docs/concepts/workloads/pods/)
|
||||
|
||||
|
||||
@@ -3,18 +3,18 @@ reviewers:
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: Container Environment
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This page describes the resources available to Containers in the Container environment.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Container environment
|
||||
|
||||
@@ -53,12 +53,13 @@ FOO_SERVICE_PORT=<the port the service is running on>
|
||||
Services have dedicated IP addresses and are available to the Container via DNS,
|
||||
if [DNS addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) is enabled.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
|
||||
* Get hands-on experience
|
||||
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -3,19 +3,19 @@ reviewers:
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: Container Lifecycle Hooks
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
This page describes how kubelet managed Containers can use the Container lifecycle hook framework
|
||||
to run code triggered by events during their management lifecycle.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Overview
|
||||
|
||||
@@ -112,12 +112,13 @@ Events:
|
||||
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about the [Container environment](/docs/concepts/containers/container-environment/).
|
||||
* Get hands-on experience
|
||||
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -3,24 +3,56 @@ reviewers:
|
||||
- erictune
|
||||
- thockin
|
||||
title: Images
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
You create your Docker image and push it to a registry before referring to it in a Kubernetes pod.
|
||||
A container image represents binary data that encapsulates an application and all its
|
||||
software dependencies. Container images are executable software bundles that can run
|
||||
standalone and that make very well defined assumptions about their runtime environment.
|
||||
|
||||
The `image` property of a container supports the same syntax as the `docker` command does, including private registries and tags.
|
||||
You typically create a container image of your application and push it to a registry
|
||||
before referring to it in a
|
||||
{{< glossary_tooltip text="Pod" term_id="pod" >}}
|
||||
|
||||
{{% /capture %}}
|
||||
This page provides an outline of the container image concept.
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Image names
|
||||
|
||||
Container images are usually given a name such as `pause`, `example/mycontainer`, or `kube-apiserver`.
|
||||
Images can also include a registry hostname; for example: `fictional.registry.example/imagename`,
|
||||
and possible a port number as well; for example: `fictional.registry.example:10443/imagename`.
|
||||
|
||||
If you don't specify a registry hostname, Kubernetes assumes that you mean the Docker public registry.
|
||||
|
||||
After the image name part you can add a _tag_ (as also using with commands such
|
||||
as `docker` and `podman`).
|
||||
Tags let you identify different versions of the same series of images.
|
||||
|
||||
Image tags consist of lowercase and uppercase letters, digits, underscores (`_`),
|
||||
periods (`.`), and dashes (`-`).
|
||||
There are additional rules about where you can place the separator
|
||||
characters (`_`, `-`, and `.`) inside an image tag.
|
||||
If you don't specify a tag, Kubernetes assumes you mean the tag `latest`.
|
||||
|
||||
{{< caution >}}
|
||||
You should avoid using the `latest` tag when deploying containers in production,
|
||||
as it is harder to track which version of the image is running and more difficult
|
||||
to roll back to a working version.
|
||||
|
||||
Instead, specify a meaningful tag such as `v1.42.0`.
|
||||
{{< /caution >}}
|
||||
|
||||
## Updating Images
|
||||
|
||||
The default pull policy is `IfNotPresent` which causes the Kubelet to skip
|
||||
The default pull policy is `IfNotPresent` which causes the
|
||||
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip
|
||||
pulling an image if it already exists. If you would like to always force a pull,
|
||||
you can do one of the following:
|
||||
|
||||
@@ -29,45 +61,18 @@ you can do one of the following:
|
||||
- omit the `imagePullPolicy` and the tag for the image to use.
|
||||
- enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.
|
||||
|
||||
Note that you should avoid using `:latest` tag, see [Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images) for more information.
|
||||
When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
|
||||
|
||||
## Building Multi-architecture Images with Manifests
|
||||
## Multi-architecture Images with Manifests
|
||||
|
||||
Docker CLI now supports the following command `docker manifest` with sub commands like `create`, `annotate` and `push`. These commands can be used to build and push the manifests. You can use `docker manifest inspect` to view the manifest.
|
||||
As well as providing binary images, a container registry can also server a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
|
||||
|
||||
Please see docker documentation here:
|
||||
https://docs.docker.com/edge/engine/reference/commandline/manifest/
|
||||
|
||||
See examples on how we use this in our build harness:
|
||||
https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=
|
||||
|
||||
These commands rely on and are implemented purely on the Docker CLI. You will need to either edit the `$HOME/.docker/config.json` and set `experimental` key to `enabled` or you can just set `DOCKER_CLI_EXPERIMENTAL` environment variable to `enabled` when you call the CLI commands.
|
||||
|
||||
{{< note >}}
|
||||
Please use Docker *18.06 or above*, versions below that either have bugs or do not support the experimental command line option. Example https://github.com/docker/cli/issues/1135 causes problems under containerd.
|
||||
{{< /note >}}
|
||||
|
||||
If you run into trouble with uploading stale manifests, just clean up the older manifests in `$HOME/.docker/manifests` to start fresh.
|
||||
|
||||
For Kubernetes, we have typically used images with suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
|
||||
Kubernetes itself typically names container images with a suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
|
||||
|
||||
## Using a Private Registry
|
||||
|
||||
Private registries may require keys to read images from them.
|
||||
Private registries may require keys to read images from them.
|
||||
Credentials can be provided in several ways:
|
||||
|
||||
- Using Google Container Registry
|
||||
- Per-cluster
|
||||
- automatically configured on Google Compute Engine or Google Kubernetes Engine
|
||||
- all pods can read the project's private registry
|
||||
- Using Amazon Elastic Container Registry (ECR)
|
||||
- use IAM roles and policies to control access to ECR repositories
|
||||
- automatically refreshes ECR login credentials
|
||||
- Using Oracle Cloud Infrastructure Registry (OCIR)
|
||||
- use IAM roles and policies to control access to OCIR repositories
|
||||
- Using Azure Container Registry (ACR)
|
||||
- Using IBM Cloud Container Registry
|
||||
- use IAM roles and policies to grant access to IBM Cloud Container Registry
|
||||
- Configuring Nodes to Authenticate to a Private Registry
|
||||
- all pods can read any configured private registries
|
||||
- requires node configuration by cluster administrator
|
||||
@@ -76,135 +81,59 @@ Credentials can be provided in several ways:
|
||||
- requires root access to all nodes to setup
|
||||
- Specifying ImagePullSecrets on a Pod
|
||||
- only pods which provide own keys can access the private registry
|
||||
- Vendor-specific or local extensions
|
||||
- if you're using a custom node configuration, you (or your cloud
|
||||
provider) can implement your mechanism for authenticating the node
|
||||
to the container registry.
|
||||
|
||||
Each option is described in more detail below.
|
||||
These options are explaind in more detail below.
|
||||
|
||||
### Configuring Nodes to authenticate to a Private Registry
|
||||
|
||||
### Using Google Container Registry
|
||||
If you run Docker on your nodes, you can configure the Docker container
|
||||
runtime to authenticate to a private container registry.
|
||||
|
||||
Kubernetes has native support for the [Google Container
|
||||
Registry (GCR)](https://cloud.google.com/tools/container-registry/), when running on Google Compute
|
||||
Engine (GCE). If you are running your cluster on GCE or Google Kubernetes Engine, simply
|
||||
use the full image name (e.g. gcr.io/my_project/image:tag).
|
||||
|
||||
All pods in a cluster will have read access to images in this registry.
|
||||
|
||||
The kubelet will authenticate to GCR using the instance's
|
||||
Google service account. The service account on the instance
|
||||
will have a `https://www.googleapis.com/auth/devstorage.read_only`,
|
||||
so it can pull from the project's GCR, but not push.
|
||||
|
||||
### Using Amazon Elastic Container Registry
|
||||
|
||||
Kubernetes has native support for the [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/), when nodes are AWS EC2 instances.
|
||||
|
||||
Simply use the full image name (e.g. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`)
|
||||
in the Pod definition.
|
||||
|
||||
All users of the cluster who can create pods will be able to run pods that use any of the
|
||||
images in the ECR registry.
|
||||
|
||||
The kubelet will fetch and periodically refresh ECR credentials. It needs the following permissions to do this:
|
||||
|
||||
- `ecr:GetAuthorizationToken`
|
||||
- `ecr:BatchCheckLayerAvailability`
|
||||
- `ecr:GetDownloadUrlForLayer`
|
||||
- `ecr:GetRepositoryPolicy`
|
||||
- `ecr:DescribeRepositories`
|
||||
- `ecr:ListImages`
|
||||
- `ecr:BatchGetImage`
|
||||
|
||||
Requirements:
|
||||
|
||||
- You must be using kubelet version `v1.2.0` or newer. (e.g. run `/usr/bin/kubelet --version=true`).
|
||||
- If your nodes are in region A and your registry is in a different region B, you need version `v1.3.0` or newer.
|
||||
- ECR must be offered in your region
|
||||
|
||||
Troubleshooting:
|
||||
|
||||
- Verify all requirements above.
|
||||
- Get $REGION (e.g. `us-west-2`) credentials on your workstation. SSH into the host and run Docker manually with those creds. Does it work?
|
||||
- Verify kubelet is running with `--cloud-provider=aws`.
|
||||
- Increase kubelet log level verbosity to at least 3 and check kubelet logs (e.g. `journalctl -u kubelet`) for log lines like:
|
||||
- `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API`
|
||||
- `aws_credentials.go:116] Got ECR credentials from ECR API for <AWS account ID for ECR>.dkr.ecr.<AWS region>.amazonaws.com`
|
||||
|
||||
### Using Azure Container Registry (ACR)
|
||||
When using [Azure Container Registry](https://azure.microsoft.com/en-us/services/container-registry/)
|
||||
you can authenticate using either an admin user or a service principal.
|
||||
In either case, authentication is done via standard Docker authentication. These instructions assume the
|
||||
[azure-cli](https://github.com/azure/azure-cli) command line tool.
|
||||
|
||||
You first need to create a registry and generate credentials, complete documentation for this can be found in
|
||||
the [Azure container registry documentation](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli).
|
||||
|
||||
Once you have created your container registry, you will use the following credentials to login:
|
||||
|
||||
* `DOCKER_USER` : service principal, or admin username
|
||||
* `DOCKER_PASSWORD`: service principal password, or admin user password
|
||||
* `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io`
|
||||
* `DOCKER_EMAIL`: `${some-email-address}`
|
||||
|
||||
Once you have those variables filled in you can
|
||||
[configure a Kubernetes Secret and use it to deploy a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
|
||||
|
||||
### Using IBM Cloud Container Registry
|
||||
IBM Cloud Container Registry provides a multi-tenant private image registry that you can use to safely store and share your images. By default, images in your private registry are scanned by the integrated Vulnerability Advisor to detect security issues and potential vulnerabilities. Users in your IBM Cloud account can access your images, or you can use IAM roles and policies to grant access to IBM Cloud Container Registry namespaces.
|
||||
|
||||
To install the IBM Cloud Container Registry CLI plug-in and create a namespace for your images, see [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started).
|
||||
|
||||
If you are using the same account and region, you can deploy images that are stored in IBM Cloud Container Registry into the default namespace of your IBM Cloud Kubernetes Service cluster without any additional configuration, see [Building containers from images](https://cloud.ibm.com/docs/containers?topic=containers-images). For other configuration options, see [Understanding how to authorize your cluster to pull images from a registry](https://cloud.ibm.com/docs/containers?topic=containers-registry#cluster_registry_auth).
|
||||
|
||||
### Configuring Nodes to Authenticate to a Private Registry
|
||||
This approach is suitable if you can control node configuration.
|
||||
|
||||
{{< note >}}
|
||||
If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
If you are running on AWS EC2 and are using the EC2 Container Registry (ECR), the kubelet on each node will
|
||||
manage and update the ECR login credentials. You cannot use this approach.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
This approach is suitable if you can control node configuration. It
|
||||
will not work reliably on GCE, and any other cloud provider that does automatic
|
||||
node replacement.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Kubernetes as of now only supports the `auths` and `HttpHeaders` section of docker config. This means credential helpers (`credHelpers` or `credsStore`) are not supported.
|
||||
Kubernetes as only supports the `auths` and `HttpHeaders` section in Docker configuration.
|
||||
Docker credential helpers (`credHelpers` or `credsStore`) are not supported.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
Docker stores keys for private registries in the `$HOME/.dockercfg` or `$HOME/.docker/config.json` file. If you put the same file
|
||||
in the search paths list below, kubelet uses it as the credential provider when pulling images.
|
||||
|
||||
* `{--root-dir:-/var/lib/kubelet}/config.json`
|
||||
* `{cwd of kubelet}/config.json`
|
||||
* `${HOME}/.docker/config.json`
|
||||
* `/.docker/config.json`
|
||||
* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
|
||||
* `{cwd of kubelet}/.dockercfg`
|
||||
* `${HOME}/.dockercfg`
|
||||
* `/.dockercfg`
|
||||
* `{--root-dir:-/var/lib/kubelet}/config.json`
|
||||
* `{cwd of kubelet}/config.json`
|
||||
* `${HOME}/.docker/config.json`
|
||||
* `/.docker/config.json`
|
||||
* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
|
||||
* `{cwd of kubelet}/.dockercfg`
|
||||
* `${HOME}/.dockercfg`
|
||||
* `/.dockercfg`
|
||||
|
||||
{{< note >}}
|
||||
You may have to set `HOME=/root` explicitly in your environment file for kubelet.
|
||||
You may have to set `HOME=/root` explicitly in the environment of the kubelet process.
|
||||
{{< /note >}}
|
||||
|
||||
Here are the recommended steps to configuring your nodes to use a private registry. In this
|
||||
example, run these on your desktop/laptop:
|
||||
|
||||
1. Run `docker login [server]` for each set of credentials you want to use. This updates `$HOME/.docker/config.json`.
|
||||
1. Run `docker login [server]` for each set of credentials you want to use. This updates `$HOME/.docker/config.json` on your PC.
|
||||
1. View `$HOME/.docker/config.json` in an editor to ensure it contains just the credentials you want to use.
|
||||
1. Get a list of your nodes, for example:
|
||||
- if you want the names: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')`
|
||||
- if you want to get the IPs: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')`
|
||||
1. Get a list of your nodes; for example:
|
||||
- if you want the names: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )`
|
||||
- if you want to get the IP addresses: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )`
|
||||
1. Copy your local `.docker/config.json` to one of the search paths list above.
|
||||
- for example: `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done`
|
||||
- for example, to test this out: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
|
||||
|
||||
Verify by creating a pod that uses a private image, e.g.:
|
||||
{{< note >}}
|
||||
For production clusers, use a configuration management tool so that you can apply this
|
||||
setting to all the nodes where you need it.
|
||||
{{< /note >}}
|
||||
|
||||
Verify by creating a Pod that uses a private image; for example:
|
||||
|
||||
```shell
|
||||
kubectl apply -f - <<EOF
|
||||
@@ -253,17 +182,13 @@ registry keys are added to the `.docker/config.json`.
|
||||
|
||||
### Pre-pulled Images
|
||||
|
||||
{{< note >}}
|
||||
If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
This approach is suitable if you can control node configuration. It
|
||||
will not work reliably on GCE, and any other cloud provider that does automatic
|
||||
node replacement.
|
||||
will not work reliably if your cloud provider manages nodes and replaces
|
||||
them automatically.
|
||||
{{< /note >}}
|
||||
|
||||
By default, the kubelet will try to pull each image from the specified registry.
|
||||
By default, the kubelet tries to pull each image from the specified registry.
|
||||
However, if the `imagePullPolicy` property of the container is set to `IfNotPresent` or `Never`,
|
||||
then a local image is used (preferentially or exclusively, respectively).
|
||||
|
||||
@@ -277,11 +202,11 @@ All pods will have read access to any pre-pulled images.
|
||||
### Specifying ImagePullSecrets on a Pod
|
||||
|
||||
{{< note >}}
|
||||
This approach is currently the recommended approach for Google Kubernetes Engine, GCE, and any cloud-providers
|
||||
where node creation is automated.
|
||||
This is the recommended approach to run containers based on images
|
||||
in private registries.
|
||||
{{< /note >}}
|
||||
|
||||
Kubernetes supports specifying registry keys on a pod.
|
||||
Kubernetes supports specifying container image registry keys on a Pod.
|
||||
|
||||
#### Creating a Secret with a Docker Config
|
||||
|
||||
@@ -292,11 +217,13 @@ kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SER
|
||||
```
|
||||
|
||||
If you already have a Docker credentials file then, rather than using the above
|
||||
command, you can import the credentials file as a Kubernetes secret.
|
||||
command, you can import the credentials file as a Kubernetes
|
||||
{{< glossary_tooltip text="Secrets" term_id="secret" >}}.
|
||||
[Create a Secret based on existing Docker credentials](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) explains how to set this up.
|
||||
|
||||
This is particularly useful if you are using multiple private container
|
||||
registries, as `kubectl create secret docker-registry` creates a Secret that will
|
||||
only work with a single private registry.
|
||||
registries, as `kubectl create secret docker-registry` creates a Secret that
|
||||
only works with a single private registry.
|
||||
|
||||
{{< note >}}
|
||||
Pods can only reference image pull secrets in their own namespace,
|
||||
@@ -306,7 +233,9 @@ so this process needs to be done one time per namespace.
|
||||
#### Referring to an imagePullSecrets on a Pod
|
||||
|
||||
Now, you can create pods which reference that secret by adding an `imagePullSecrets`
|
||||
section to a pod definition.
|
||||
section to a Pod definition.
|
||||
|
||||
For example:
|
||||
|
||||
```shell
|
||||
cat <<EOF > pod.yaml
|
||||
@@ -332,13 +261,14 @@ EOF
|
||||
This needs to be done for each pod that is using a private registry.
|
||||
|
||||
However, setting of this field can be automated by setting the imagePullSecrets
|
||||
in a [serviceAccount](/docs/user-guide/service-accounts) resource.
|
||||
in a [ServiceAccount](/docs/user-guide/service-accounts) resource.
|
||||
|
||||
Check [Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for detailed instructions.
|
||||
|
||||
You can use this in conjunction with a per-node `.docker/config.json`. The credentials
|
||||
will be merged. This approach will work on Google Kubernetes Engine.
|
||||
will be merged.
|
||||
|
||||
### Use Cases
|
||||
## Use Cases
|
||||
|
||||
There are a number of solutions for configuring private registries. Here are some
|
||||
common use cases and suggested solutions.
|
||||
@@ -346,7 +276,7 @@ common use cases and suggested solutions.
|
||||
1. Cluster running only non-proprietary (e.g. open-source) images. No need to hide images.
|
||||
- Use public images on the Docker hub.
|
||||
- No configuration required.
|
||||
- On GCE/Google Kubernetes Engine, a local mirror is automatically used for improved speed and availability.
|
||||
- Some cloud providers automatically cache or mirror public images, which improves availability and reduces the time to pull images.
|
||||
1. Cluster running some proprietary images which should be hidden to those outside the company, but
|
||||
visible to all cluster users.
|
||||
- Use a hosted private [Docker registry](https://docs.docker.com/registry/).
|
||||
@@ -354,7 +284,7 @@ common use cases and suggested solutions.
|
||||
- Manually configure .docker/config.json on each node as described above.
|
||||
- Or, run an internal private registry behind your firewall with open read access.
|
||||
- No Kubernetes configuration is required.
|
||||
- Or, when on GCE/Google Kubernetes Engine, use the project's Google Container Registry.
|
||||
- Use a hosted container image registry service that controls image access
|
||||
- It will work better with cluster autoscaling than manual node configuration.
|
||||
- Or, on a cluster where changing the node configuration is inconvenient, use `imagePullSecrets`.
|
||||
1. Cluster with proprietary images, a few of which require stricter access control.
|
||||
@@ -370,4 +300,6 @@ common use cases and suggested solutions.
|
||||
If you need access to multiple registries, you can create one secret for each registry.
|
||||
Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.json`
|
||||
|
||||
{{% /capture %}}
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read the [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md)
|
||||
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- erictune
|
||||
- thockin
|
||||
title: Containers overview
|
||||
content_template: templates/concept
|
||||
weight: 1
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Containers are a technology for packaging the (compiled) code for an
|
||||
application along with the dependencies it needs at run time. Each
|
||||
container that you run is repeatable; the standardization from having
|
||||
dependencies included means that you get the same behavior wherever you
|
||||
run it.
|
||||
|
||||
Containers decouple applications from underlying host infrastructure.
|
||||
This makes deployment easier in different cloud or OS environments.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Container images
|
||||
A [container image](/docs/concepts/containers/images/) is a ready-to-run
|
||||
software package, containing everything needed to run an application:
|
||||
the code and any runtime it requires, application and system libraries,
|
||||
and default values for any essential settings.
|
||||
|
||||
By design, a container is immutable: you cannot change the code of a
|
||||
container that is already running. If you have a containerized application
|
||||
and want to make changes, you need to build a new container that includes
|
||||
the change, then recreate the container to start from the updated image.
|
||||
|
||||
## Container runtimes
|
||||
|
||||
{{< glossary_definition term_id="container-runtime" length="all" >}}
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
* Read about [container images](/docs/concepts/containers/images/)
|
||||
* Read about [Pods](/docs/concepts/workloads/pods/)
|
||||
{{% /capture %}}
|
||||
@@ -3,11 +3,11 @@ reviewers:
|
||||
- tallclair
|
||||
- dchen1107
|
||||
title: Runtime Class
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
|
||||
|
||||
@@ -16,10 +16,10 @@ This page describes the RuntimeClass resource and runtime selection mechanism.
|
||||
RuntimeClass is a feature for selecting the container runtime configuration. The container runtime
|
||||
configuration is used to run a Pod's containers.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Motivation
|
||||
|
||||
@@ -180,12 +180,13 @@ Pod overhead is defined in RuntimeClass through the `overhead` fields. Through t
|
||||
you can specify the overhead of running pods utilizing this RuntimeClass and ensure these overheads
|
||||
are accounted for in Kubernetes.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
|
||||
- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
|
||||
- Read about the [Pod Overhead](/docs/concepts/configuration/pod-overhead/) concept
|
||||
- [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
title: Example Concept Template
|
||||
reviewers:
|
||||
- chenopis
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
toc_hide: true
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< note >}}
|
||||
Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
|
||||
@@ -14,9 +14,9 @@ Be sure to also [create an entry in the table of contents](/docs/home/contribute
|
||||
|
||||
This page explains ...
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Understanding ...
|
||||
|
||||
@@ -26,15 +26,16 @@ Kubernetes provides ...
|
||||
|
||||
To use ...
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
**[Optional Section]**
|
||||
|
||||
* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/).
|
||||
* See [Using Page Templates - Concept template](/docs/home/contribute/page-templates/#concept_template) for how to use this template.
|
||||
|
||||
{{% /capture %}}
|
||||
* Learn more about [Writing a New Topic](/docs/home/contribute/style/write-new-topic/).
|
||||
* See [Page Content Types - Concept](/docs/home/contribute/style/page-concept-types/#concept).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,4 +1,212 @@
|
||||
---
|
||||
title: Extending Kubernetes
|
||||
weight: 110
|
||||
description: Different ways to change the behavior of your Kubernetes cluster.
|
||||
reviewers:
|
||||
- erictune
|
||||
- lavalamp
|
||||
- cheftako
|
||||
- chenopis
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetes is highly configurable and extensible. As a result,
|
||||
there is rarely a need to fork or submit patches to the Kubernetes
|
||||
project code.
|
||||
|
||||
This guide describes the options for customizing a Kubernetes
|
||||
cluster. It is aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to
|
||||
understand how to adapt their Kubernetes cluster to the needs of
|
||||
their work environment. Developers who are prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also find it
|
||||
useful as an introduction to what extension points and patterns
|
||||
exist, and their trade-offs and limitations.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Overview
|
||||
|
||||
Customization approaches can be broadly divided into *configuration*, which only involves changing flags, local configuration files, or API resources; and *extensions*, which involve running additional programs or services. This document is primarily about extensions.
|
||||
|
||||
## Configuration
|
||||
|
||||
*Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary:
|
||||
|
||||
* [kubelet](/docs/admin/kubelet/)
|
||||
* [kube-apiserver](/docs/admin/kube-apiserver/)
|
||||
* [kube-controller-manager](/docs/admin/kube-controller-manager/)
|
||||
* [kube-scheduler](/docs/admin/kube-scheduler/).
|
||||
|
||||
Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.
|
||||
|
||||
*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
|
||||
|
||||
## Extensions
|
||||
|
||||
Extensions are software components that extend and deeply integrate with Kubernetes.
|
||||
They adapt it to support new types and new kinds of hardware.
|
||||
|
||||
Most cluster administrators will use a hosted or distribution
|
||||
instance of Kubernetes. As a result, most Kubernetes users will not need to
|
||||
install extensions and fewer will need to author new ones.
|
||||
|
||||
## Extension Patterns
|
||||
|
||||
Kubernetes is designed to be automated by writing client programs. Any
|
||||
program that reads and/or writes to the Kubernetes API can provide useful
|
||||
automation. *Automation* can run on the cluster or off it. By following
|
||||
the guidance in this doc you can write highly available and robust automation.
|
||||
Automation generally works with any Kubernetes cluster, including hosted
|
||||
clusters and managed installations.
|
||||
|
||||
There is a specific pattern for writing client programs that work well with
|
||||
Kubernetes called the *Controller* pattern. Controllers typically read an
|
||||
object's `.spec`, possibly do things, and then update the object's `.status`.
|
||||
|
||||
A controller is a client of Kubernetes. When Kubernetes is the client and
|
||||
calls out to a remote service, it is called a *Webhook*. The remote service
|
||||
is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of
|
||||
failure.
|
||||
|
||||
In the webhook model, Kubernetes makes a network request to a remote service.
|
||||
In the *Binary Plugin* model, Kubernetes executes a binary (program).
|
||||
Binary plugins are used by the kubelet (e.g. [Flex Volume
|
||||
Plugins](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)
|
||||
and [Network
|
||||
Plugins](/docs/concepts/cluster-administration/network-plugins/))
|
||||
and by kubectl.
|
||||
|
||||
Below is a diagram showing how the extension points interact with the
|
||||
Kubernetes control plane.
|
||||
|
||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
|
||||
|
||||
<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
|
||||
|
||||
|
||||
## Extension Points
|
||||
|
||||
This diagram shows the extension points in a Kubernetes system.
|
||||
|
||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
|
||||
|
||||
<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
|
||||
|
||||
1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.
|
||||
2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/overview/extending#api-access-extensions) section.
|
||||
3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/overview/extending#user-defined-types) section. Custom Resources are often used with API Access Extensions.
|
||||
4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section.
|
||||
5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources.
|
||||
6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/overview/extending#network-plugins) allow for different implementations of pod networking.
|
||||
7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/overview/extending#storage-plugins).
|
||||
|
||||
If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.
|
||||
|
||||
|
||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
|
||||
|
||||
<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
|
||||
|
||||
## API Extensions
|
||||
### User-Defined Types
|
||||
|
||||
Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`.
|
||||
|
||||
Do not use a Custom Resource as data storage for application, user, or monitoring data.
|
||||
|
||||
For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/api-extension/custom-resources/).
|
||||
|
||||
|
||||
### Combining New APIs with Automation
|
||||
|
||||
The combination of a custom resource API and a control loop is called the [Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies.
|
||||
|
||||
### Changing Built-in Resources
|
||||
|
||||
When you extend the Kubernetes API by adding custom resources, the added resources always fall into a new API Groups. You cannot replace or change existing API groups.
|
||||
Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API Access Extensions do.
|
||||
|
||||
|
||||
### API Access Extensions
|
||||
|
||||
When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow.
|
||||
|
||||
Each of these steps offers extension points.
|
||||
|
||||
Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/).
|
||||
|
||||
### Authentication
|
||||
|
||||
[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request.
|
||||
|
||||
Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs.
|
||||
|
||||
|
||||
### Authorization
|
||||
|
||||
[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It just works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision.
|
||||
|
||||
|
||||
### Dynamic Admission Control
|
||||
|
||||
After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. In addition to the built-in steps, there are several extensions:
|
||||
|
||||
* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers.
|
||||
* To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates.
|
||||
|
||||
## Infrastructure Extensions
|
||||
|
||||
|
||||
### Storage Plugins
|
||||
|
||||
[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
|
||||
) allow users to mount volume types without built-in support by having the
|
||||
Kubelet call a Binary Plugin to mount the volume.
|
||||
|
||||
|
||||
### Device Plugins
|
||||
|
||||
Device plugins allow a node to discover new Node resources (in addition to the
|
||||
builtin ones like cpu and memory) via a [Device
|
||||
Plugin](/docs/concepts/cluster-administration/device-plugins/).
|
||||
|
||||
|
||||
### Network Plugins
|
||||
|
||||
Different networking fabrics can be supported via node-level [Network Plugins](/docs/admin/network-plugins/).
|
||||
|
||||
### Scheduler Extensions
|
||||
|
||||
The scheduler is a special type of controller that watches pods, and assigns
|
||||
pods to nodes. The default scheduler can be replaced entirely, while
|
||||
continuing to use other Kubernetes components, or [multiple
|
||||
schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
|
||||
can run at the same time.
|
||||
|
||||
This is a significant undertaking, and almost all Kubernetes users find they
|
||||
do not need to modify the scheduler.
|
||||
|
||||
The scheduler also supports a
|
||||
[webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)
|
||||
that permits a webhook backend (scheduler extension) to filter and prioritize
|
||||
the nodes chosen for a pod.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/)
|
||||
* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
* Learn more about Infrastructure extensions
|
||||
* [Network Plugins](/docs/concepts/cluster-administration/network-plugins/)
|
||||
* [Device Plugins](/docs/concepts/cluster-administration/device-plugins/)
|
||||
* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
|
||||
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
|
||||
|
||||
|
||||
|
||||
@@ -4,20 +4,20 @@ reviewers:
|
||||
- lavalamp
|
||||
- cheftako
|
||||
- chenopis
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
The aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs.
|
||||
The additional APIs can either be ready-made solutions such as [service-catalog](/docs/concepts/extend-kubernetes/service-catalog/), or APIs that you develop yourself.
|
||||
|
||||
The aggregation layer is different from [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/), which are a way to make the {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} recognise new kinds of object.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Aggregation layer
|
||||
|
||||
@@ -34,13 +34,14 @@ If your extension API server cannot achieve that latency requirement, consider m
|
||||
`EnableAggregatedDiscoveryTimeout=false` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the kube-apiserver
|
||||
to disable the timeout restriction. This deprecated feature gate will be removed in a future release.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/).
|
||||
* Then, [setup an extension api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) to work with the aggregation layer.
|
||||
* Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/).
|
||||
* Then, [setup an extension api-server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) to work with the aggregation layer.
|
||||
* Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
|
||||
* Read the specification for [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -3,19 +3,19 @@ title: Custom Resources
|
||||
reviewers:
|
||||
- enisoc
|
||||
- deads2k
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
*Custom resources* are extensions of the Kubernetes API. This page discusses when to add a custom
|
||||
resource to your Kubernetes cluster and when to use a standalone service. It describes the two
|
||||
methods for adding custom resources and how to choose between them.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
## Custom resources
|
||||
|
||||
A *resource* is an endpoint in the [Kubernetes API](/docs/reference/using-api/api-overview/) that stores a collection of
|
||||
@@ -128,7 +128,7 @@ Regardless of how they are installed, the new resources are referred to as Custo
|
||||
|
||||
## CustomResourceDefinitions
|
||||
|
||||
The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
|
||||
The [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
|
||||
API resource allows you to define custom resources.
|
||||
Defining a CRD object creates a new custom resource with a name and schema that you specify.
|
||||
The Kubernetes API serves and handles the storage of your custom resource.
|
||||
@@ -178,17 +178,17 @@ Aggregated APIs offer more advanced API features and customization of other feat
|
||||
|
||||
| Feature | Description | CRDs | Aggregated API |
|
||||
| ------- | ----------- | ---- | -------------- |
|
||||
| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
|
||||
| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes |
|
||||
| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | Yes |
|
||||
| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
|
||||
| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes |
|
||||
| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | Yes |
|
||||
| Custom Storage | If you need storage with a different performance mode (for example, a time-series database instead of key-value store) or isolation for security (for example, encryption of sensitive information, etc.) | No | Yes |
|
||||
| Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | Yes, using [Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). | Yes |
|
||||
| Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | Yes |
|
||||
| Status Subresource | Allows fine-grained access control where user writes the spec section and the controller writes the status section. Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource) | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | Yes |
|
||||
| Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | Yes |
|
||||
| Status Subresource | Allows fine-grained access control where user writes the spec section and the controller writes the status section. Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource) | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource) | Yes |
|
||||
| Other Subresources | Add operations other than CRUD, such as "logs" or "exec". | No | Yes |
|
||||
| strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/run-application/update-api-object-kubectl-patch/) | No | Yes |
|
||||
| strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) | No | Yes |
|
||||
| Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes |
|
||||
| OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) schema (GA in 1.16). | Yes |
|
||||
| OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) schema (GA in 1.16). | Yes |
|
||||
|
||||
### Common Features
|
||||
|
||||
@@ -246,12 +246,13 @@ When you add a custom resource, you can access it using:
|
||||
- A REST client that you write.
|
||||
- A client generated using [Kubernetes client generation tools](https://github.com/kubernetes/code-generator) (generating one is an advanced undertaking, but some projects may provide a client along with the CRD or AA).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn how to [Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
|
||||
|
||||
* Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/).
|
||||
* Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
reviewers:
|
||||
title: Device Plugins
|
||||
description: Use the Kubernetes device plugin framework to implement plugins for GPUs, NICs, FPGAs, InfiniBand, and similar resources that require vendor-specific setup.
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
|
||||
|
||||
Kubernetes provides a [device plugin framework](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)
|
||||
@@ -19,9 +19,9 @@ The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand adap
|
||||
and other similar computing resources that may require vendor specific initialization
|
||||
and setup.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Device plugin registration
|
||||
|
||||
@@ -223,14 +223,15 @@ Here are some examples of device plugin implementations:
|
||||
* The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
|
||||
* The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
|
||||
* The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
|
||||
* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices
|
||||
* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) for Xilinx FPGA devices
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins
|
||||
* Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node
|
||||
* Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
|
||||
* Learn about the [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -4,12 +4,12 @@ reviewers:
|
||||
- freehan
|
||||
- thockin
|
||||
title: Network Plugins
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state state="alpha" >}}
|
||||
{{< caution >}}Alpha features can change rapidly. {{< /caution >}}
|
||||
@@ -19,9 +19,9 @@ Network plugins in Kubernetes come in a few flavors:
|
||||
* CNI plugins: adhere to the appc/CNI specification, designed for interoperability.
|
||||
* Kubenet plugin: implements basic `cbr0` using the `bridge` and `host-local` CNI plugins
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Installation
|
||||
|
||||
@@ -166,8 +166,9 @@ This option is provided to the network-plugin; currently **only kubenet supports
|
||||
* `--network-plugin=kubenet` specifies that we use the `kubenet` network plugin with CNI `bridge` and `host-local` plugins placed in `/opt/cni/bin` or `cni-bin-dir`.
|
||||
* `--network-plugin-mtu=9001` specifies the MTU to use, currently only used by the `kubenet` network plugin.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
{{% /capture %}}
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -5,11 +5,11 @@ reviewers:
|
||||
- lavalamp
|
||||
- cheftako
|
||||
- chenopis
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetes is highly configurable and extensible. As a result,
|
||||
there is rarely a need to fork or submit patches to the Kubernetes
|
||||
@@ -22,10 +22,10 @@ their work environment. Developers who are prospective {{< glossary_tooltip text
|
||||
useful as an introduction to what extension points and patterns
|
||||
exist, and their trade-offs and limitations.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Overview
|
||||
|
||||
@@ -50,7 +50,7 @@ Extensions are software components that extend and deeply integrate with Kuberne
|
||||
They adapt it to support new types and new kinds of hardware.
|
||||
|
||||
Most cluster administrators will use a hosted or distribution
|
||||
instance of Kubernetes. As a result, most Kubernetes users will need to
|
||||
instance of Kubernetes. As a result, most Kubernetes users will not need to
|
||||
install extensions and fewer will need to author new ones.
|
||||
|
||||
## Extension Patterns
|
||||
@@ -194,10 +194,11 @@ The scheduler also supports a
|
||||
that permits a webhook backend (scheduler extension) to filter and prioritize
|
||||
the nodes chosen for a pod.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/)
|
||||
* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
@@ -207,4 +208,4 @@ the nodes chosen for a pod.
|
||||
* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
|
||||
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
---
|
||||
title: Operator pattern
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
Operators are software extensions to Kubernetes that make use of [custom
|
||||
resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
to manage applications and their components. Operators follow
|
||||
Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-control-plane).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Motivation
|
||||
|
||||
@@ -113,9 +113,10 @@ Operator.
|
||||
You also implement an Operator (that is, a Controller) using any language / runtime
|
||||
that can act as a [client for the Kubernetes API](/docs/reference/using-api/client-libraries/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* Find ready-made operators on [OperatorHub.io](https://operatorhub.io/) to suit your use case
|
||||
@@ -129,4 +130,3 @@ 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 %}}
|
||||
+8
-7
@@ -1,18 +1,18 @@
|
||||
---
|
||||
title: Poseidon-Firmament Scheduler
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 80
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
|
||||
|
||||
The Poseidon-Firmament scheduler is an alternate scheduler that can be deployed alongside the default Kubernetes scheduler.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
||||
## Introduction
|
||||
@@ -102,10 +102,11 @@ Pod-by-pod schedulers, such as the Kubernetes default scheduler, process Pods in
|
||||
|
||||
These downsides of pod-by-pod schedulers are addressed by batching or bulk scheduling in Poseidon-Firmament scheduler. Processing several pods in a batch allows the scheduler to jointly consider their placement, and thus to find the best trade-off for the whole batch instead of one pod. At the same time it amortizes work across pods resulting in much higher throughput.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* See [Poseidon-Firmament](https://github.com/kubernetes-sigs/poseidon#readme) on GitHub for more information.
|
||||
* See the [design document](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/design/README.md) for Poseidon.
|
||||
* Read [Firmament: Fast, Centralized Cluster Scheduling at Scale](https://www.usenix.org/system/files/conference/osdi16/osdi16-gog.pdf), the academic paper on the Firmament scheduling design.
|
||||
* If you'd like to contribute to Poseidon-Firmament, refer to the [developer setup instructions](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/devel/README.md).
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
title: Service Catalog
|
||||
reviewers:
|
||||
- chenopis
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- overview -->
|
||||
{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
|
||||
|
||||
A service broker, as defined by the [Open service broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md), is an endpoint for a set of managed services offered and maintained by a third-party, which could be a cloud provider such as AWS, GCP, or Azure.
|
||||
@@ -14,10 +14,10 @@ Some examples of managed services are Microsoft Azure Cloud Queue, Amazon Simple
|
||||
|
||||
Using Service Catalog, a {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}} can browse the list of managed services offered by a service broker, provision an instance of a managed service, and bind with it to make it available to an application in the Kubernetes cluster.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- body -->
|
||||
## Example use case
|
||||
|
||||
An {{< glossary_tooltip text="application developer" term_id="application-developer" >}} wants to use message queuing as part of their application running in a Kubernetes cluster.
|
||||
@@ -222,16 +222,17 @@ The following example describes how to map secret values into application enviro
|
||||
key: topic
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* If you are familiar with {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}, [install Service Catalog using Helm](/docs/tasks/service-catalog/install-service-catalog-using-helm/) into your Kubernetes cluster. Alternatively, you can [install Service Catalog using the SC tool](/docs/tasks/service-catalog/install-service-catalog-using-sc/).
|
||||
* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
|
||||
* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
|
||||
* View [svc-cat.io](https://svc-cat.io/docs/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
---
|
||||
title: "Overview"
|
||||
weight: 20
|
||||
---
|
||||
description: Get a high-level outline of Kubernetes and the components it is built from.
|
||||
---
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user