whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #15680 from simplytunde/release-1.15-merge-master

Browse Source 
Release 1.15 merge master
This commit is contained in:
Kubernetes Prow Robot
2019-08-05 16:03:50 -07:00
committed by GitHub
parent e30e6f5389 ca31485991
commit 37b17d92dd
386 changed files with 11538 additions and 4867 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Makefile
+1 -1
View File
@@ -26,7 +26,7 @@ check-headers-file:
production-build: check-hugo-versions build check-headers-file ## Build the production site and ensure that noindex headers aren't added
non-production-build: test-examples check-hugo-versions ## Build the non-production site, which adds noindex headers to prevent indexing
non-production-build: check-hugo-versions ## Build the non-production site, which adds noindex headers to prevent indexing
hugo --enableGitInfo
serve: ## Boot the development server.
OWNERS_ALIASES
+17 -4
View File
@@ -18,6 +18,16 @@ aliases:
- chuckha
- detiber
- dixudx
sig-docs-blog-owners: # Approvers for blog content
- castrojo
- kbarnard10
- zacharysarah
sig-docs-blog-reviewers: # Reviewers for blog content
- cody-clark
- mrbobbytables
- onlydole
- parispittman
- vonguard
sig-docs-de-owners: # Admins for German content
- bene2k1
- mkorbi
@@ -34,10 +44,12 @@ aliases:
- jaredbhatti
- jimangel
- kbarnard10
- kbhawkey
- makoscafee
- mistyhacks
- rajakavitha1
- ryanmcginnis
- shavidissa
- steveperry-53
- stewart-yu
- tengqm
@@ -48,6 +60,7 @@ aliases:
sig-docs-en-reviews: # PR reviews for English content
- jimangel
- rajakavitha1
- sftim
- stewart-yu
- xiangpengzhao
- zhangxiaoyu-zidif
@@ -105,21 +118,21 @@ aliases:
sig-docs-it-reviews: # PR reviews for Italian content
- rlenferink
- micheleberardi
sig-docs-ja-owners: # Admins for Japanese content
sig-docs-ja-owners: # Admins for Japanese content
- cstoku
- nasa9084
- tnir
- zacharysarah
sig-docs-ja-reviews: # PR reviews for Japanese content
sig-docs-ja-reviews: # PR reviews for Japanese content
- cstoku
- inductor
- makocchi-git
- MasayaAoyama
- nasa9084
- tnir
sig-docs-ko-owners: # Admins for Korean content
- ClaudiaJKang
- gochist
- ianychoi
- seokho-son
- zacharysarah
sig-docs-ko-reviews: # PR reviews for Korean content
- ClaudiaJKang
README-ja.md
+75
View File
@@ -0,0 +1,75 @@
# Kubernetesのドキュメント
[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
ようこそ！このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！
## ドキュメントに貢献する
GitHubの画面右上にある**Fork**ボタンをクリックすると、お使いのGitHubアカウントに紐付いた本リポジトリのコピーが作成され、このコピーのことを*フォーク*と呼びます。フォークリポジトリの中ではお好きなように変更を加えていただいて構いません。加えた変更をこのリポジトリに追加したい任意のタイミングにて、フォークリポジトリからPull Reqeustを作成してください。
Pull Requestが作成されると、レビュー担当者が責任を持って明確かつ実用的なフィードバックを返します。
Pull Requestの所有者は作成者であるため、**ご自身で作成したPull Requestを編集し、フィードバックに対応するのはご自身の役目です。**
また、状況によっては2人以上のレビュアーからフィードバックが返されたり、アサインされていないレビュー担当者からのフィードバックが来ることがある点もご注意ください。
さらに、特定のケースにおいては、レビュー担当者が[Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers)に対してレビューを依頼することもあります。
レビュー担当者はタイムリーにフィードバックを提供するために最善を尽くしますが、応答時間は状況に応じて異なる場合があります。
Kubernetesのドキュメントへの貢献に関する詳細については以下のページをご覧ください:
* [貢献のはじめ方](https://kubernetes.io/docs/contribute/start/)
* [ドキュメントの変更をステージする](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
* [ページテンプレートの使い方](http://kubernetes.io/docs/contribute/style/page-templates/)
* [ドキュメントのスタイルガイド](http://kubernetes.io/docs/contribute/style/style-guide/)
* [Kubernetesドキュメントの翻訳方法](https://kubernetes.io/docs/contribute/localization/)
## Dockerを使ってローカル環境でWebサイトを動かす
ローカル環境で本ページを動かすのに推奨される方法は、静的サイトジェネレータの[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)
### 行動規範
Kubernetesコミュニティへの参加については、[Kubernetesの行動規範](code-of-conduct.md)によって管理されています。
## ありがとうございます！
Kubernetesはコミュニティの参加によって成長しています。Webサイトおよびドキュメンテーションへの皆さんの貢献に感謝します！
README-ko.md
+6 -6
View File
@@ -3,13 +3,13 @@
[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
환영합니다! 이 저장소는 쿠버네티스 웹사이트 및 문서화를 만드는 데 필요로 하는 모든 asset에 대한 공간을 제공합니다. 여러 분이 기여를 원한다는 사실에 매우 기쁩니다!
환영합니다! 이 저장소는 쿠버네티스 웹사이트 및 문서화를 만드는 데 필요로 하는 모든 asset에 대한 공간을 제공합니다. 여러분이 기여를 원한다는 사실에 매우 기쁩니다!
## 문서에 기여하기
이 저장소에 대한 복제본을 여러분의 GitHub 계정에 생성하기 위해 화면 오른쪽 위 영역에 있는 **Fork** 버튼을 클릭 가능합니 다. 이 복제본은 *fork* 라고 부릅니다. 여러분의 fork에서 원하는 임의의 변경 사항을 만들고, 해당 변경 사항을 보낼 준비가 되었다면, 여러분의 fork로 이동하여 새로운 풀 리퀘스트를 만들어 우리에게 알려주시기 바랍니다.
이 저장소에 대한 복제본을 여러분의 GitHub 계정에 생성하기 위해 화면 오른쪽 위 영역에 있는 **Fork** 버튼을 클릭 가능합니다. 이 복제본은 *fork* 라고 부릅니다. 여러분의 fork에서 원하는 임의의 변경 사항을 만들고, 해당 변경 사항을 보낼 준비가 되었다면, 여러분의 fork로 이동하여 새로운 풀 리퀘스트를 만들어 우리에게 알려주시기 바랍니다.
여러분의 풀 리퀘스트가 생생된 이후에는, 쿠버네티스 리뷰어가 명료하고 실행 가능한 피드백을 제공하는 책임을 담당할 것입니 다. 풀 리퀘스트의 오너로서, **쿠버네티스 리뷰어로부터 제공받은 피드백을 수용하기 위해 풀 리퀘스트를 수정하는 것은 여러분의 책임입니다.** 또한, 참고로 한 명 이상의 쿠버네티스 리뷰어가 여러분에게 피드백을 제공하는 상황에 처하거나, 또는 여러분에게 피드백을 제공하기로 원래 할당된 사람이 아닌 다른 쿠버네티스 리뷰어로부터 피드백을 받는 상황에 처할 수도 있습니다. 뿐만 아니라, 몇몇 상황에서는, 필요에 따라 리뷰어 중 한 명이 [쿠버네티스 기술 리뷰어](https://github.com/kubernetes/website/wiki/Tech-reviewers)로부터의 기술 리뷰를 요청할지도 모릅니다. 리뷰어는 제시간에 피드백을 제공하기 위해 최선을 다할 것이지만, 응답 시간은 상황에 따라 달라질 수도 있습니다.
여러분의 풀 리퀘스트가 생생된 이후에는, 쿠버네티스 리뷰어가 명료하고 실행 가능한 피드백을 제공하는 책임을 담당할 것입니다. 풀 리퀘스트의 오너로서, **쿠버네티스 리뷰어로부터 제공받은 피드백을 수용하기 위해 풀 리퀘스트를 수정하는 것은 여러분의 책임입니다.** 또한, 참고로 한 명 이상의 쿠버네티스 리뷰어가 여러분에게 피드백을 제공하는 상황에 처하거나, 또는 여러분에게 피드백을 제공하기로 원래 할당된 사람이 아닌 다른 쿠버네티스 리뷰어로부터 피드백을 받는 상황에 처할 수도 있습니다. 뿐만 아니라, 몇몇 상황에서는, 필요에 따라 리뷰어 중 한 명이 [쿠버네티스 기술 리뷰어](https://github.com/kubernetes/website/wiki/Tech-reviewers)로부터의 기술 리뷰를 요청할지도 모릅니다. 리뷰어는 제시간에 피드백을 제공하기 위해 최선을 다할 것이지만, 응답 시간은 상황에 따라 달라질 수도 있습니다.
쿠버네티스 문서화에 기여하기와 관련된 보다 자세한 정보는, 다음을 살펴봅니다:
@@ -32,7 +32,7 @@
## 도커를 사용하여 사이트를 로컬에서 실행하기
쿠버네티스 웹사이트를 로컬에서 실행하기 위한 추천하는 방식은 [Hugo](https://gohugo.io) 정적 사이트 생성기를 포함하는 특 별한 [도커](https://docker.com) 이미지를 실행하는 것입니다.
쿠버네티스 웹사이트를 로컬에서 실행하기 위한 추천하는 방식은 [Hugo](https://gohugo.io) 정적 사이트 생성기를 포함하는 특별한 [도커](https://docker.com) 이미지를 실행하는 것입니다.
> Windows에서 실행하는 경우, [Chocolatey](https://chocolatey.org)로 설치할 수 있는 명명 추가 도구를 필요로 할 것입니다. `choco install make`
@@ -50,7 +50,7 @@ make docker-image
make docker-serve
```
브라우저에서 http://localhost:1313 를 열어 사이트를 살펴봅니다. 소스 파일에 변경 사항이 있을 때, Hugo는 사이트를 업데이 트하고 브라우저를 강제로 새로고침합니다.
브라우저에서 http://localhost:1313 를 열어 사이트를 살펴봅니다. 소스 파일에 변경 사항이 있을 때, Hugo는 사이트를 업데이트하고 브라우저를 강제로 새로고침합니다.
## Hugo를 사용한 로컬 사이트 실행하기
@@ -62,7 +62,7 @@ Hugo가 설치되었을 때 로컬에서 사이트를 실행하기 위해 (다
make serve
```
이를 통해 로컬 Hugo 서버를 1313번 포트에 시작합니다. 브라우저에서 http://localhost:1313 를 열어 사이트를 살펴봅니다. 소 스 파일에 변경 사항이 있을 때, Hugo는 사이트를 업데이트하고 브라우저를 강제로 새로고침합니다.
이를 통해 로컬 Hugo 서버를 1313번 포트에 시작합니다. 브라우저에서 http://localhost:1313 를 열어 사이트를 살펴봅니다. 소스 파일에 변경 사항이 있을 때, Hugo는 사이트를 업데이트하고 브라우저를 강제로 새로고침합니다.
## 감사합니다!
README-pt.md
+5 -11
View File
@@ -19,16 +19,10 @@ Para mais informações sobre como contribuir com a documentação do Kubernetes
* [Guia de Estilo da Documentação](http://kubernetes.io/docs/contribute/style/style-guide/)
* [Localizando documentação do Kubernetes](https://kubernetes.io/docs/contribute/localization/)
## Documentação do Kubernetes Localizando o `README.md`
Você pode contactar os mantenedores da localização em Português em:
### coreano
Veja a tradução de `README.md` e mais orientações sobre detalhes para contribuidores coreanos na página [README coreano](README-ko.md).
Você pode alcançar os mantenedores da localização coreana em:
* June Yi ([GitHub - @gochist](https://github.com/gochist))
* [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-ko)
* Felipe ([GitHub - @femrtnz](https://github.com/femrtnz))
* [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-pt)
## Executando o site localmente usando o Docker
@@ -68,7 +62,7 @@ Isso iniciará o servidor Hugo local na porta 1313. Abra o navegador para http:/
Aprenda a se envolver com a comunidade do Kubernetes na [página da comunidade](http://kubernetes.io/community/).
Você pode alcançar os mantenedores deste projeto em:
Você pode falar com os mantenedores deste projeto:
- [Slack](https://kubernetes.slack.com/messages/sig-docs)
- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
@@ -79,4 +73,4 @@ A participação na comunidade Kubernetes é regida pelo [Código de Conduta da
## Obrigado!
A Kubernetes prospera com a participação da comunidade e nós realmente apreciamos suas contribuições para o nosso site e nossa documentação!
O Kubernetes conta com a participação da comunidade e nós realmente agradecemos suas contribuições para o nosso site e nossa documentação!
README.md
+2 -1
View File
@@ -26,6 +26,7 @@ For more information about contributing to the Kubernetes documentation, see:
|[German README](README-de.md)|[Portuguese README](README-pt.md)|
|[Hindi README](README-hi.md)|[Spanish README](README-es.md)|
|[Indonesian README](README-id.md)|[Chinese README](README-zh.md)|
|[Japanese README](README-ja.md)||
|||
## Running the website locally using Docker
@@ -52,7 +53,7 @@ Open up your browser to http://localhost:1313 to view the website. As you make c
## Running the website locally using Hugo
See the [official Hugo documentation](https://gohugo.io/getting-started/installing/) for Hugo installation instructions. Make sure to install the Hugo version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L9) file.
See the [official Hugo documentation](https://gohugo.io/getting-started/installing/) for Hugo installation instructions. Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L9) file.
To run the website locally when you have Hugo installed:
assets/sass/_base.sass
+11 -10
View File
@@ -1125,6 +1125,16 @@ $feature-box-div-margin-bottom: 40px
#vendorStrip
display: none
// Add logo to CNCF section
section#cncf
padding-top: 60px
padding-bottom: 140px
background-image: url(/images/cncf-color.png)
background-position: center 100px
background-repeat: no-repeat
background-size: 300px
// OCEAN NODES
#oceanNodes
@@ -1174,7 +1184,7 @@ $feature-box-div-margin-bottom: 40px
position: absolute
top: 50%
left: 75%
width: 525px
width: 575px
padding-right: 80px
transform: translate(-50%, -50%)
color: white
@@ -1269,15 +1279,6 @@ $feature-box-div-margin-bottom: 40px
&:hover
border-color: white
// CNCF
#cncf
padding-top: 60px
padding-bottom: 140px
background-image: url(/images/cncf-color.png)
background-position: center 100px
background-repeat: no-repeat
background-size: 300px
// KubeWeekly
#kubeweekly
background-color: $light-grey
config.toml
+9 -3
View File
@@ -24,7 +24,9 @@ pygmentsStyle = "emacs"
enableGitInfo = true
# Norwegian ("no") is sometimes but not currently used for testing.
disableLanguages = ["no"]
# Hindi is disabled because it's currently in development.
# Italian is disabled until it meets minimum standards for quality.
disableLanguages = ["hi", "it", "no"]
[blackfriday]
hrefTargetBlank = true
@@ -252,6 +254,10 @@ language_alternatives = ["en"]
[languages.hi]
title = "Kubernetes"
description = "Production-Grade Container Orchestration"
languageName ="Hindi"
languageName = "Hindi"
weight = 11
contentDir = "content/hi"
contentDir = "content/hi"
[languages.hi.params]
time_format_blog = "01.02.2006"
language_alternatives = ["en"]
content/de/_index.html
+2 -2
View File
@@ -44,12 +44,12 @@ Kubernetes ist Open Source und bietet Ihnen die Freiheit, die Infrastruktur vor
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2019" button id="desktopKCButton">KubeCon vom 20-23. Mai 2019 in Barcelona</a>
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019" button id="desktopKCButton">KubeCon vom 18-21. November 2019 in San Diego</a>
<br>
<br>
<br>
<br>
<a href="https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019" button id="desktopKCButton">KubeCon vom 24-26. Juni 2019 in Shanghai</a>
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">KubeCon vom 30 März-2 Apr. 2020 in Amsterdam</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
content/de/docs/concepts/overview/what-is-kubernetes.md
+2 -2
View File
@@ -51,7 +51,7 @@ für Managementtools zu bieten, den Status von Kontrollpunkten zu ermitteln.
Darüber hinaus basiert die [Kubernetes-Steuerungsebene](/docs/concepts/overview/components/) auf den gleichen APIs,
die Entwicklern und Anwendern zur Verfügung stehen. Benutzer können ihre eigenen Controller, wie z.B.
[Scheduler](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md), mit
ihren [eigenen APIs](](/docs/concepts/api-extension/custom-resources/) schreiben, die von einem
ihren [eigenen APIs](/docs/concepts/api-extension/custom-resources/) schreiben, die von einem
universellen [Kommandozeilen-Tool](/docs/user-guide/kubectl-overview/) angesprochen werden können.
Dieses [Design](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) hat es einer Reihe anderer Systeme ermöglicht, auf Kubernetes aufzubauen.
@@ -155,7 +155,7 @@ Zusammenfassung der Container-Vorteile:
## Was bedeutet Kubernetes? K8s?
Der Name **Kubernetes** stammt aus dem Griechischen, beteutet *Steuermann* oder
Der Name **Kubernetes** stammt aus dem Griechischen, bedeutet *Steuermann* oder
*Pilot*, und ist der Ursprung von *Gouverneur* und
[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.
content/de/docs/reference/kubectl/cheatsheet.md
+1 -1
View File
@@ -145,7 +145,7 @@ kubectl get services --sort-by=.metadata.name # Listen Sie Dienste nach Namen so
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
# Erhalten Sie die Versionsbezeichnung aller Pods mit der Bezeichnung app=cassandra
kubectl get pods --selector=app=cassandra rc -o \
kubectl get pods --selector=app=cassandra -o \
jsonpath='{.items[*].metadata.labels.version}'
# Alle Worker-Knoten abrufen (verwenden Sie einen Selektor, um Ergebnisse auszuschließen,
content/de/docs/tutorials/kubernetes-basics/scale/scale-intro.html
+2 -2
View File
@@ -61,11 +61,11 @@ weight: 10
<li data-target="#myCarousel" data-slide-to="1"></li>
</ol>
<div class="carousel-inner" role="listbox">
<div class="item active">
<div class="item carousel-item active">
<img src="/docs/tutorials/kubernetes-basics/public/images/module_05_scaling1.svg">
</div>
<div class="item">
<div class="item carousel-item">
<img src="/docs/tutorials/kubernetes-basics/public/images/module_05_scaling2.svg">
</div>
</div>
content/en/_index.html
+5 -5
View File
@@ -44,12 +44,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
<br>
<br>
<br>
<a href="https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019" button id="desktopKCButton">Attend KubeCon in Shanghai on June 24-26, 2019</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019" button id="desktopKCButton">Attend KubeCon in San Diego on Nov. 18-21, 2019</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
content/en/blog/OWNERS
+2 -7
View File
@@ -6,15 +6,10 @@ options:
no_parent_owners: false
approvers:
- kbarnard10
- zacharysarah
- sig-docs-blog-owners # Defined in OWNERS_ALIASES
reviewers:
- vonguard
- castrojo
- mrbobbytables
- cody-clark
- parispittman
- sig-docs-blog-reviewers # Defined in OWNERS_ALIASES
labels:
- area/blog
content/en/blog/_posts/2018-07-10-coredns-ga.md
+1 -1
View File
@@ -148,7 +148,7 @@ You can also filter by namespaces or a label selector. This can allow you to run
In addition to the features described above, CoreDNS is easily extended. It is possible to build custom versions
of CoreDNS that include your own features. For example, this ability has been used to extend CoreDNS to do recursive resolution
with the [unbound plugin](https://https://coredns.io/explugins/unbound), to server records directly from a database with the [pdsql plugin](https://coredns.io/explugins/pdsql), and to allow multiple CoreDNS instances to share a common level 2 cache with the [redisc plugin](https://coredns.io/explugins/redisc).
with the [unbound plugin](https://coredns.io/explugins/unbound), to server records directly from a database with the [pdsql plugin](https://coredns.io/explugins/pdsql), and to allow multiple CoreDNS instances to share a common level 2 cache with the [redisc plugin](https://coredns.io/explugins/redisc).
Many other interesting extensions have been added, which you will find on the [External Plugins](https://coredns.io/explugins/) page of the CoreDNS site. One that is really interesting for Kubernetes and Istio users is the [kubernetai plugin](https://coredns.io/explugins/kubernetai), which allows a single CoreDNS instance to connect to multiple Kubernetes clusters and provide service discovery across all of them.
content/en/blog/_posts/2018-10-18-tips-for-first-kubecon-presentation-part-1.md
+1 -1
View File
@@ -8,7 +8,7 @@ date: 2018-10-18
First of all, let me congratulate you to this outstanding achievement. Speaking at KubeCon, especially if it's your first time, is a tremendous honor and experience. Well done!
<center>{{< tweet 1044345018490662912 >}}</center>
<center><blockquote class="twitter-tweet"><p lang="en" dir="ltr">Congrats to everyone who got Kubecon talks accepted! 👏👏👏<br><br>To everyone who got a rejection don&#39;t feel bad. Only 13% could be accepted. Keep trying. There will be other opportunities.</p>&mdash; Justin Garrison (@rothgar) <a href="https://twitter.com/rothgar/status/1044345018490662912?ref_src=twsrc%5Etfw">September 24, 2018</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></center>
When I was informed that my [KubeCon talk about Kubernetes Resource Management](https://www.youtube.com/watch?v=8-apJyr2gi0) was accepted for KubeCon EU in Denmark (2018), I really could not believe it. By then, the chances to get your talk accepted were around 10% (or less, don't really remember the exact number). There were over a 1,000 submissions just for that KubeCon (recall that we now have **three KubeCon events during the year** - US, EU and Asia region). The popularity of Kubernetes is ever increasing and so is the number of people trying to get a talk accepted. Once again, **outstanding achievement to get your talk in**!
content/en/blog/_posts/2018-10-26-tips-for-first-kubecon-presentation-part-2.md
+1 -1
View File
@@ -52,4 +52,4 @@ I hope some of these tips are useful for you as well. And I wish you all the bes
Besides my fantastic reviewers and the speaker support team already mentioned above, I also would like to thank the people who supported me along this KubeCon journey: Bjoern, Timo, Emad and Steve!
{{< tweet 992409364467200000 >}}
<blockquote class="twitter-tweet"><p lang="en" dir="ltr"><a href="https://twitter.com/hashtag/KubeCon?src=hash&amp;ref_src=twsrc%5Etfw">#KubeCon</a> <a href="https://twitter.com/embano1?ref_src=twsrc%5Etfw">@embano1</a> is laying down an homage to an earlier <a href="https://twitter.com/thockin?ref_src=twsrc%5Etfw">@thockin</a> presentation in his &quot;Inside K8S Resource Management&quot; session, if you didn&#39;t make it in the door, check out the deck here <a href="https://t.co/4xQq5CQ3aZ">https://t.co/4xQq5CQ3aZ</a> <a href="https://t.co/ObFEuKskhB">pic.twitter.com/ObFEuKskhB</a></p>&mdash; Steve Wong (@cantbewong) <a href="https://twitter.com/cantbewong/status/992400932968288256?ref_src=twsrc%5Etfw">May 4, 2018</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
content/en/blog/_posts/Kubernetes-setup-using-Ansible-and-Vagrant.md → content/en/blog/_posts/2019-03-15-Kubernetes-setup-using-Ansible-and-Vagrant.md
View File
content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md
+1 -1
View File
@@ -12,7 +12,7 @@ Kubernetes is a real winner (and a de facto standard) in the world of distribute
A few weeks ago I ran a poll on Twitter asking the community to specify their preferred option for running Kubernetes locally on Linux:
<center>{{< tweet 1093154369040773120 >}}</center>
<center><blockquote class="twitter-tweet"><p lang="en" dir="ltr">Ok, Twitter ✋<br><br>Your local Kubernetes cluster on Linux is deployed by:</p>&mdash; ihor dvoretskyi (@idvoretskyi) <a href="https://twitter.com/idvoretskyi/status/1093154369040773120?ref_src=twsrc%5Etfw">February 6, 2019</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></center>
This is post #1 in a series about the local deployment options on Linux, and it will cover Minikube, the most popular community-built solution for running Kubernetes on a local machine.
content/en/blog/_posts/future-of-cloud-providers.md → content/en/blog/_posts/2019-04-17-future-of-cloud-providers.md
+1
View File
@@ -1,4 +1,5 @@
---
layout: blog
title: 'The Future of Cloud Providers in Kubernetes'
date: 2019-04-17
---
content/en/blog/_posts/Introducing-kube-iptables-tailer-Better-Networking-Visibility-in-Kubernetes-Clusters.md → content/en/blog/_posts/2019-04-19-Introducing-kube-iptables-tailer-Better-Networking-Visibility-in-Kubernetes-Clusters.md
+1
View File
@@ -1,4 +1,5 @@
---
layout: blog
title: "Introducing kube-iptables-tailer: Better Networking Visibility in Kubernetes Clusters"
date: 2019-04-19
slug: introducing-kube-iptables-tailer
content/en/blog/_posts/Kubernetes-Cloud-Native-and-the-Future-of-Software.md → content/en/blog/_posts/2019-05-17-Kubernetes-Cloud-Native-and-the-Future-of-Software.md
+1
View File
@@ -1,4 +1,5 @@
---
layout: blog
title: 'Kubernetes, Cloud Native, and the Future of Software'
date: 2019-05-17
---
content/en/blog/_posts/2019-06-19-kubernetes-1-15-release-announcement.md
+2 -4
View File
@@ -21,7 +21,7 @@ The theme of the new developments around CustomResourceDefinitions is data consi
In this direction, we have rethought our OpenAPI based validation schemas in CRDs and from 1.15 on we check each schema against a restriction called “structural schema”. This basically enforces non-polymorphic and complete typing of each field in a CustomResource. We are going to require structural schemas in the future, especially for all new features including those listed below, and list violations in a `NonStructural` condition. Non-structural schemas keep working for the time being in the v1beta1 API group. But any serious CRD application is urged to migrate to structural schemas in the foreseeable future.
Details about what makes a schema structural will be published in a blog post on kubernetes.io later this week, and it is of course [documented in the Kubernetes documentation](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#specifying-a-structural-schema).
Details about what makes a schema structural will be published in a blog post on kubernetes.io later this week, and it is of course [documented in the Kubernetes documentation](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#specifying-a-structural-schema).
**beta: CustomResourceDefinition Webhook Conversion**
@@ -63,7 +63,7 @@ There are more smaller changes to admission webhook, notably `objectSelector` to
Work on making Kubernetes installation, upgrade and configuration even more robust has been a major focus for this cycle for SIG Cluster Lifecycle (see our last [Community Update](https://docs.google.com/presentation/d/1QUOsQxfEfHlMq4lPjlK2ewQHsr9peEKymDw5_XwZm8Q/edit?usp=sharing)). Bug fixes across bare metal tooling and production-ready user stories, such as the high availability use cases have been given priority for 1.15.
**kubeadm**, the cluster lifecycle building block, continues to receive features and stability work required for bootstrapping production clusters efficiently. kubeadm has promoted high availability (HA) capability to beta, allowing users to use the familiar `kubeadm init` and `kubeadm join` commands to [configure and deploy an HA control plane](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/). An entire new test suite has been created specifically for ensuring these features will stay stable over time.
**kubeadm**, the cluster lifecycle building block, continues to receive features and stability work required for bootstrapping production clusters efficiently. kubeadm has promoted high availability (HA) capability to beta, allowing users to use the familiar `kubeadm init` and `kubeadm join` commands to [configure and deploy an HA control plane](/docs/setup/production-environment/tools/kubeadm/high-availability/). An entire new test suite has been created specifically for ensuring these features will stay stable over time.
Certificate management has become more robust in 1.15, with kubeadm now seamlessly rotating all your certificates (on upgrades) before they expire. Check the [kubeadm documentation](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) for information on how to manage your certificates.
@@ -147,5 +147,3 @@ The simplest way to get involved with Kubernetes is by joining one of the many [
- Join the community on [Slack](http://slack.k8s.io/)
- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
- Share your Kubernetes [story](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
<!-- Docs to Markdown version 1.0β17 -->
content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md
+21 -16
View File
@@ -58,7 +58,7 @@ The **core of a structural schema** is an OpenAPI v3 schema made out of
In addition, all types must be non-empty, and in each sub-schema only one of `properties`, `additionalProperties` or `items` may be used.
Here is an example of our `MaintenanceJob`:
Here is an example of our `MaintenanceNightlyJob`:
```yaml
type: object
@@ -110,12 +110,12 @@ Some notable restrictions for these additional value validations:
As you can see also logical constraints using `oneOf`, `allOf`, `anyOf`, `not` are allowed.
To sum up, an OpenAPI schema is structural if
1. it has the core as defined above out of `properties`, `items`, `additionalProperties`, `type`, `nullable`, `title`, `description`,
2. all types are defined,
3. the core is extended with value validation following the constraints:
1. inside of value validations no `additionalProperties`, `type`, `nullable`, `title`, `description`,
2. all fields mentioned in value validation are specified in the core.
To sum up, an OpenAPI schema is structural if<br/><br/>
1. it has the core as defined above out of `properties`, `items`, `additionalProperties`, `type`, `nullable`, `title`, `description`,<br/>
2. all types are defined,<br/>
3. the core is extended with value validation following the constraints:<br/>
(i) inside of value validations no `additionalProperties`, `type`, `nullable`, `title`, `description`<br/>
(ii) all fields mentioned in value validation are specified in the core.
Let us modify our example spec slightly, to make it non-structural:
@@ -169,11 +169,12 @@ spec:
Pruning can only be enabled if the global schema or the schemas of all versions are structural.
If pruning is enabled, the pruning algorithm
* assumes that the schema is complete, i.e. every field is mentioned and not-mentioned fields can be dropped
* is run on
* data received via an API request
* after conversion and admission requests
* when reading from etcd (using the schema version of the data in etcd).
* is run on<br/>
(i) data received via an API request<br/>
(ii) after conversion and admission requests<br/>
(iii) when reading from etcd (using the schema version of the data in etcd).
As we don’t specify `privileged` in our structural example schema, the malicious field is pruned from before persisting to etcd:
@@ -181,7 +182,9 @@ As we don’t specify `privileged` in our structural example schema, the malicio
apiVersion: operations/v1
kind: MaintenanceNightlyJob
spec:
command: grep backdoor /etc/passwd || echo “backdoor:76asdfh76:/bin/bash” >> /etc/passwd || true
shell: >
grep backdoor /etc/passwd ||
echo “backdoor:76asdfh76:/bin/bash” >> /etc/passwd || true
machines: [“az1-master1”,”az1-master2”,”az2-master3”]
# pruned: privileged: true
```
@@ -192,7 +195,8 @@ While most Kubernetes-like APIs can be expressed with a structural schema, there
Because we want CRDs to make use of these types as well, we introduce the following OpenAPI vendor extensions to the permitted core constructs:
* `x-kubernetes-embedded-resource: true` — specifies that this is an `runtime.RawExtensions-like field, with a Kubernetes resource with apiVersion, kind and metadata. The consequence is that those 3 fields are not pruned and are automatically validated.
* `x-kubernetes-embedded-resource: true` — specifies that this is an `runtime.RawExtension`-like field, with a Kubernetes resource with apiVersion, kind and metadata. The consequence is that those 3 fields are not pruned and are automatically validated.
* `x-kubernetes-int-or-string: true` — specifies that this is either an integer or a string. No types must be specified, but
```yaml
@@ -202,9 +206,10 @@ Because we want CRDs to make use of these types as well, we introduce the follow
```
is permitted, though optional.
* `x-kubernetes-preserve-unknown-fields: true` — specifies that the pruning algorithm should not prune any field. This can be combined with `x-kubernetes-embedded-resource`. Note that within a nested `properties` or `additionalProperties` OpenAPI schema the pruning starts again.
One can use `x-kubernetes-preserve-unknown-fields: true` at the root of the schema (and inside any `properties`, `additionalProperties`) to get the traditional CRD behaviour that nothing is prune, despite being `spec.preserveUnknownProperties: false` is set.
One can use `x-kubernetes-preserve-unknown-fields: true` at the root of the schema (and inside any `properties`, `additionalProperties`) to get the traditional CRD behaviour that nothing is pruned, despite setting `spec.preserveUnknownProperties: false`.
## Conclusion
@@ -227,8 +232,8 @@ Any new feature for CRDs starting from Kubernetes 1.15 will require to have a st
* publishing of OpenAPI validation schemas and therefore support for kubectl client-side validation, and `kubectl explain` support (beta in Kubernetes 1.15)
* CRD conversion (beta in Kubernetes 1.15)
* CRD defaulting (beta in Kubernetes 1.15)
* CRD defaulting (alpha in Kubernetes 1.15)
* Server-side apply (alpha in Kubernetes 1.15, CRD support pending).
Of course [structural schemas](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#specifying-a-structural-schema) are also described in the Kubernetes documentation for the 1.15 release.
Of course [structural schemas](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#specifying-a-structural-schema) are also described in the Kubernetes documentation for the 1.15 release.
content/en/blog/_posts/2019-06-21-volume-cloning-alpha.md
+112
View File
@@ -0,0 +1,112 @@
---
layout: blog
title: 'Introducing Volume Cloning Alpha for Kubernetes'
date: 2019-06-21
---
**Author**: John Griffith (Red Hat)
Kubernetes v1.15 introduces alpha support for volume cloning. This feature allows you to create new volumes using the contents of existing volumes in the user's namespace using the Kubernetes API.
## What is a Clone?
Many storage systems provide the ability to create a "clone" of a volume. A clone is a duplicate of an existing volume that is its own unique volume on the system, but the data on the source is duplicated to the destination (clone). A clone is similar to a snapshot in that it's a point in time copy of a volume, however rather than creating a new snapshot object from a volume, we're instead creating a new independent volume, sometimes thought of as pre-populating the newly created volume.
## Why add cloning to Kubernetes
The Kubernetes volume plugin system already provides a powerful abstraction that automates the provisioning, attaching, and mounting of block and file storage.
Underpinning all these features is the Kubernetes goal of workload portability: Kubernetes aims to create an abstraction layer between distributed systems applications and underlying clusters so that applications can be agnostic to the specifics of the cluster they run on and application deployment requires no specific storage device knowledge.
The [Kubernetes Storage SIG](https://github.com/kubernetes/community/tree/master/sig-storage) identified clone operations as critical functionality for many stateful workloads. For example, a database administrator may want to duplicate a database volume and create another instance of an existing database.
By providing a standard way to trigger clone operations in the Kubernetes API, Kubernetes users can now handle use cases like this without having to go around the Kubernetes API (and manually executing storage system specific operations). While cloning is similar in behavior to creating a snapshot of a volume, then creating a volume from the snapshot, a clone operation is more streamlined and is more efficient for many backend devices.
Kubernetes users are now empowered to incorporate clone operations in a cluster agnostic way into their tooling and policy with the comfort of knowing that it will work against arbitrary Kubernetes clusters regardless of the underlying storage.
## Kubernetes API and Cloning
The cloning feature in Kubernetes is enabled via the `PersistentVolumeClaim.DataSource` field. Prior to v1.15 the only valid object type permitted for use as a dataSource was a `VolumeSnapshot`. The cloning feature extends the allowed `PersistentVolumeclaim.DataSource.Kind` field to not only allow `VolumeSnapshot` but also `PersistentVolumeClaim`. The existing behavior is not changed.
There are no new objects introduced to enable cloning. Instead, the existing dataSource field in the PersistentVolumeClaim object is expanded to be able to accept the name of an existing PersistentVolumeClaim in the same namespace. It is important to note that from a users perspective a clone is just another PersistentVolume and PersistentVolumeClaim, the only difference being that that PersistentVolume is being populated with the contents of another PersistentVolume at creation time. After creation it behaves exactly like any other Kubernetes PersistentVolume and adheres to the same behaviors and rules.
## Which volume plugins support Kubernetes Cloning?
Kubernetes supports three types of volume plugins: in-tree, Flex, and [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI). See [Kubernetes Volume Plugin FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) for details.
Cloning is only supported for CSI drivers (not for in-tree or Flex). To use the Kubernetes cloning feature, ensure that a CSI Driver that implements cloning is deployed on your cluster.
For a list of CSI drivers that currently support cloning see the [CSI Drivers doc](https://kubernetes-csi.github.io/docs/drivers.html).
## Kubernetes Cloning Requirements
Before using Kubernetes Volume Cloning, you must:
* Ensure a CSI driver implementing Cloning is deployed and running on your Kubernetes cluster.
* Enable the Kubernetes Volume Cloning feature via new Kubernetes feature gate (disabled by default for alpha):
* Set the following flag on the API server binary: `--feature-gates=VolumePVCDataSource=true`
* The source and destination claims must be in the same namespace.
## Creating a clone with Kubernetes
To provision a new volume pre-populated with data from an existing Kubernetes Volume, use the dataSource field in the `PersistentVolumeClaim`. There are three parameters:
* name - name of the `PersistentVolumeClaim` object to use as source
* kind - must be `PersistentVolumeClaim`
* apiGroup - must be `""`
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-clone
Namespace: demo-namespace
spec:
storageClassName: csi-storageclass
dataSource:
name: src-pvc
kind: PersistentVolumeClaim
apiGroup: ""
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi # NOTE this capacity must be specified and must be >= the capacity of the source volume
```
When the `PersistentVolumeClaim` object is created, it will trigger provisioning of a new volume that is pre-populated with data from the specified `dataSource` volume. It is the sole responsbility of the CSI Plugin to implement the cloning of volumes.
## As a storage vendor, how do I add support for cloning to my CSI driver?
For more information on how to implement cloning in your CSI Plugin, reference the [developing a CSI driver for Kubernetes](https://kubernetes-csi.github.io/docs/developing.html) section of the CSI docs.
## What are the limitations of alpha?
The alpha implementation of cloning for Kubernetes has the following limitations:
* Does not support cloning volumes across different namespaces
* Does not support cloning volumes across different storage classes (backends)
## Future
Depending on feedback and adoption, the Kubernetes team plans to push the CSI cloning implementation to beta in 1.16.
A common question that users have regarding cloning is "what about cross namespace clones". As we've mentioned, the current release requires that source and destination be in the same namespace. There are however efforts underway to propose a namespace transfer API, future versions of Kubernetes may provide the ability to transfer volume resources from one namespace to another. This feature is still under discussion and design, and may or may not be available in a future release.
## How can I learn more?
You can find additional documentation on the cloning feature in the [storage concept docs](https://k8s.io/docs/concepts/storage/volume-pvc-datasource.md) and also the [CSI docs](https://kubernetes-csi.github.io/docs/volume-cloning.html).
## How do I get involved?
This project, like all of Kubernetes, is the result of hard work by many contributors from diverse backgrounds working together.
We offer a huge thank you to all the contributors in Kubernetes Storage SIG and CSI community who helped review the design and implementation of the project, including but not limited to the following:
* Saad Ali ([saadali](https://github.com/saadali))
* Tim Hockin ([thockin](https://github.com/thockin))
* Jan Šafránek ([jsafrane](https://github.com/jsafrane))
* Michelle Au ([msau42](https://github.com/msau42))
* Xing Yang ([xing-yang](https://github.com/xing-yang))
If you’re interested in getting involved with the design and development of CSI or any part of the Kubernetes Storage system, join the [Kubernetes Storage Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG). We’re rapidly growing and always welcome new contributors.
content/en/blog/_posts/2019-06-24-kubeadm-ha-v115.md
+212
View File
@@ -0,0 +1,212 @@
---
layout: blog
title: 'Automated High Availability in kubeadm v1.15: Batteries Included But Swappable'
date: 2019-06-24
---
**Authors**:
- Lucas Käldström, [@luxas](https://github.com/luxas), SIG Cluster Lifecycle co-chair & kubeadm subproject owner, Weaveworks
- Fabrizio Pandini, [@fabriziopandini](https://github.com/fabriziopandini), kubeadm subproject owner, Independent
[kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/) is a tool that enables Kubernetes administrators
to quickly and easily bootstrap minimum viable clusters that are fully compliant with
[Certified Kubernetes](https://github.com/cncf/k8s-conformance/blob/master/terms-conditions/Certified_Kubernetes_Terms.md) guidelines.
It’s been under active development by [SIG Cluster Lifecycle](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle)
since 2016 and graduated it from beta to
[generally available (GA) at the end of 2018](https://kubernetes.io/blog/2018/12/04/production-ready-kubernetes-cluster-creation-with-kubeadm/).
After this important milestone, the kubeadm team is now focused on the stability of the core feature set and working on
maturing existing features.
With this post, we are introducing the improvements made in the v1.15 release of kubeadm.
## The scope of kubeadm
kubeadm is focused on performing the actions necessary to get a minimum viable, secure cluster up and running in a
user-friendly way. kubeadm's scope is limited to the local machine’s filesystem and the Kubernetes API, and it is
intended to be a _composable building block for higher-level tools_.
The core of the kubeadm interface is quite simple: new control plane nodes are created by you running
<strong><code>kubeadm init</code></strong>, worker nodes are joined to the control plane by you running
<strong><code>kubeadm join</code></strong>. Also included are common utilities for managing already bootstrapped
clusters, such as control plane upgrades, token and certificate renewal.
To keep kubeadm lean, focused, and vendor/infrastructure agnostic, the following tasks are out of scope:
* Infrastructure provisioning
* Third-party networking
* Non-critical add-ons, e.g. monitoring, logging, and visualization
* Specific cloud provider integrations
Those tasks are addressed by other SIG Cluster Lifecycle projects, such as the
[Cluster API](https://github.com/kubernetes-sigs/cluster-api) for infrastructure provisioning and management.
Instead, kubeadm covers only the common denominator in every Kubernetes cluster: the
[control plane](https://kubernetes.io/docs/concepts/#kubernetes-control-plane).
![Cluster Lifecycle Layers](/images/blog/2019-06-24-kubeadm-ha-v115/overview.png)
## What’s new in kubeadm v1.15?
### High Availability to Beta
We are delighted to announce that automated support for High Availability clusters is graduating to **Beta** in kubeadm v1.15. Let’s give a great shout out to all the contributors that helped in this effort and to the early adopter users for the great feedback received so far!
But how does automated High Availability work in kubeadm?
The great news is that you can use the familiar `kubeadm init` or `kubeadm join` workflow for creating high availability cluster as well, with the only difference that you have to pass the `--control-plane` flag to `kubeadm join` when adding more control plane nodes.
A 3-minute screencast of this feature is here:
[![asciicast](https://asciinema.org/a/252343.svg)](https://asciinema.org/a/252343)
In a nutshell:
1. **Set up a Load Balancer.** You need an _external load balancer_; providing this however, is out of scope of kubeadm.
* The community will provide a set of reference implementations for this task though
* HAproxy, Envoy, or a similar Load Balancer from a cloud provider work well
2. **Run kubeadm init** on the first control plane node, with small modifications:
* Create a [kubeadm Config File](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)
* In the config file, set the `controlPlaneEndpoint` field to where your Load Balancer can be reached at.
* Run init, with the `--upload-certs` flag like this: `sudo kubeadm init --config=kubeadm-config.yaml --upload-certs`
3. **Run kubeadm join --control-plane** at any time when you want to expand the set of control plane nodes
* Both control-plane- and normal nodes can be joined in any order, at any time
* The command to run will be given by `kubeadm init` above, and is of the form:
```
kubeadm join [LB endpoint] \
--token ... \
--discovery-token-ca-cert-hash sha256:... \
--control-plane --certificate-key ...
```
For those interested in the details, there are many things that make this functionality possible. Most notably:
* **Automated certificate transfer**. kubeadm implements an automatic certificate copy feature to automate the distribution of all the certificate authorities/keys that must be shared across all the control-planes nodes in order to get your cluster to work. This feature can be activated by passing `--upload-certs` to `kubeadm init`; see [configure and deploy an HA control plane](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/) for more details. This is an explicit opt-in feature, you can also distribute the certificates manually in your preferred way. \
* **Dynamically-growing etcd cluster**. When you're not providing an external etcd cluster, kubeadm automatically adds a new etcd member, running as a static pod. All the etcd members are joined in a “stacked” etcd cluster that grows together with your high availability control-plane \
* **Concurrent joining**. Similarly to what already implemented for worker nodes, you join control-plane nodes whenever, in any order, or even in parallel. \
* **Upgradable**. The kubeadm upgrade workflow was improved in order to properly handle the HA scenario, and, after starting the upgrade with `kubeadm upgrade apply` as usual, users can now complete the upgrade process by using `kubeadm upgrade node` both on the remaining control-plane nodes and worker nodes
Finally, it is also worthy to notice that an entirely new test suite has been created specifically for ensuring High Availability in kubeadm will stay stable over time.
### Certificate Management
Certificate management has become more simple and robust in kubeadm v1.15.
If you perform Kubernetes version upgrades regularly, kubeadm will now take care of keeping your cluster up to date and reasonably secure by [automatically rotating all your certificates](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#automatic-certificate-renewal) at `kubeadm upgrade` time.
If instead, you prefer to renew your certificates manually, you can opt out from the automatic certificate renewal by passing `--certificate-renewal=false` to `kubeadm upgrade` commands. Then you can perform [manual certificate renewal](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#manual-certificate-renewal) with the `kubeadm alpha certs renew` command.
But there is more.
A new command `kubeadm alpha certs check-expiration` was introduced to allow users to
[check certificate expiration](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#check-certificate-expiration). The output is similar to this:
```console
CERTIFICATE EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
admin.conf May 15, 2020 13:03 UTC 364d false
apiserver May 15, 2020 13:00 UTC 364d false
apiserver-etcd-client May 15, 2020 13:00 UTC 364d false
apiserver-kubelet-client May 15, 2020 13:00 UTC 364d false
controller-manager.conf May 15, 2020 13:03 UTC 364d false
etcd-healthcheck-client May 15, 2020 13:00 UTC 364d false
etcd-peer May 15, 2020 13:00 UTC 364d false
etcd-server May 15, 2020 13:00 UTC 364d false
front-proxy-client May 15, 2020 13:00 UTC 364d false
scheduler.conf May 15, 2020 13:03 UTC 364d false
```
You should expect also more work around certificate management in kubeadm in the next releases, with the introduction of ECDSA keys and with improved support for CA key rotation. Additionally, the commands staged under `kubeadm alpha` are expected to move top-level soon.
### Improved Configuration File Format
You can argue that there are hardly two Kubernetes clusters that are configured equally, and hence there is a need to customize how the cluster is set up depending on the environment. One way of configuring a component is via flags. However, this has some scalability limitations:
* **Hard to maintain.** When a component’s flag set grows over 30+ flags, configuring it becomes really painful.
* **Complex upgrades**. When flags are removed, deprecated or changed, you need to upgrade of the binary at the same time as the arguments.
* **Key-value limited**. There are simply many types of configuration you can’t express with the `--key=value` syntax.
* **Imperative**. In contrast to Kubernetes API objects themselves that are declaratively specified, flag arguments are imperative by design.
This is a key problem for Kubernetes components in general, as some components have 150+ flags. With kubeadm we’re pioneering the ComponentConfig effort, and providing users with a small set of flags, but most importantly, a **declarative and versioned configuration file** for advance use-cases. We call this _ComponentConfig_. It has the following characteristics:
* **Upgradable**: You can upgrade the binary, and still use the existing, older schema. Automatic migrations.
* **Programmable**. Configuration expressed in JSON/YAML allows for consistent, and programmable manipulation
* **Expressible**. Advanced patterns of configuration can be used and applied.
* **Declarative**. OpenAPI information can easily be exposed / used for doc generation
In kubeadm v1.15, we have improved the structure and are releasing the new **v1beta2** format. Important to note that the existing **v1beta1** format released in v1.13 will still continue to work for several releases. This means you can upgrade kubeadm to v1.15, and still use your existing v1beta1 configuration files. When you’re ready to take advantage of the improvements made in v1beta2, you can perform an automatic schema migration using the `kubeadm config migrate` command.
During the course of the year, we’re looking forward to graduate the schema to General Availability `v1`.` If you’re interested in this effort, you can also join [WG Component Standard](https://github.com/kubernetes/community/tree/master/wg-component-standard).
## What’s next?
### 2019 plans
We are focusing our efforts around graduating the configuration file format to GA (`kubeadm.k8s.io/v1`)`, graduating this super-easy High Availability flow to stable, and providing better tools around rotating certificates needed for running the cluster automatically.
In addition to these three key milestones of our charter, we want to improve the following areas:
* Support joining Windows nodes to a kubeadm cluster (with end-to-end tests)
* Improve the upstream CI signal, mainly for HA and upgrades
* Consolidate how Kubernetes artifacts are built and installed
* Utilize Kustomize to allow for advanced, layered and declarative configuration
We make no guarantees that these deliverables will ship this year though, as this is a community effort. If you want to see these things happen, please join our SIG and start contributing! The ComponentConfig issues in particular need more attention.
### kubeadm now has a logo!
[Dan Kohn](https://github.com/dankohn) offered CNCF’s help with creating a logo for kubeadm in this cycle.
[Alex Contini](https://github.com/alexcontini) created 19 (!) different logo options for the community to vote on. The public poll
was active for around a week, and we got 386 answers. The winning option got 17.4% of the votes. In other words, now we have an
official logo!
![kubeadm's logo](/images/blog/2019-06-24-kubeadm-ha-v115/logo.png)
## Contributing
If this all sounds exciting, **join us**!
[SIG Cluster Lifecycle](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle) has many different
subprojects, where kubeadm is one of them. In the following picture you can see that there are many pieces in the
puzzle, and we have a lot still to do.
![SIG Cluster Lifecycle Projects](/images/blog/2019-06-24-kubeadm-ha-v115/projects.png)
Some handy links if you want to start contribute:
* You can watch the SIG Cluster Lifecycle [New Contributor Onboarding](https://www.youtube.com/watch?v=Bof9aveB3rA) session on YouTube.
* Look out for “good first issue”, “help wanted” and “sig/cluster-lifecycle” labeled issues in our repositories
(e.g. [kubernetes/kubeadm](https://github.com/kubernetes/kubeadm))
* Join [#sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle), [#kubeadm](https://kubernetes.slack.com/messages/kubeadm), [#cluster-api](https://kubernetes.slack.com/messages/cluster-api), [#minikube](https://kubernetes.slack.com/messages/minikube), [#kind](https://kubernetes.slack.com/messages/kind), etc. in Slack
* Join our public, bi-weekly SIG Cluster Lifecycle Zoom meeting at Tuesdays 9am PT
* Check out the [Meeting Notes](https://docs.google.com/document/d/1Gmc7LyCIL_148a9Tft7pdhdee0NBHdOfHS1SAF0duI4/edit) to join
* Join our public, weekly kubeadm Office Hours Zoom meeting at Wednesdays 9am PT
* Check out the [Meeting Notes](https://docs.google.com/document/d/130_kiXjG7graFNSnIAgtMS1G8zPDwpkshgfRYS0nggo/edit) to join
* Check out the [SIG Cluster Lifecycle Intro](https://youtu.be/bA2M41J4wvg) or the
[kubeadm Deep Dive](https://youtu.be/spXSSIbZTqM) sessions from KubeCon Barcelona
### Thank You
This release wouldn’t have been possible without the help of the great people that have been contributing to SIG Cluster Lifecycle
and kubeadm. We would like to thank all the kubeadm contributors and companies making it possible for their developers to work
on Kubernetes!
In particular, we would like to thank the [kubeadm subproject owners](https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/OWNERS) that made this possible:
- Tim St. Clair , [@timothysc](https://github.com/timothysc), SIG Cluster Lifecycle co-chair, VMware
- Lucas Käldström, [@luxas](https://github.com/luxas), SIG Cluster Lifecycle co-chair, Weaveworks
- Fabrizio Pandini, [@fabriziopandini](https://github.com/fabriziopandini), Independent
- Lubomir I. Ivanov, [@neolit123](https://github.com/neolit123), VMware
- Rostislav M. Georgiev, [@rosti](https://github.com/rosti), VMware
content/en/blog/_posts/2019-06-25-recap-of-contributor-summit-bcn-2019.md
+58
View File
@@ -0,0 +1,58 @@
---
layout: blog
title: 'Recap of Kubernetes Contributor Summit Barcelona 2019'
date: 2019-06-25
---
**Author**: Jonas Rosland (VMware)
First of all, **THANK YOU** to everyone who made the Kubernetes Contributor Summit in Barcelona possible. We had an amazing team of volunteers tasked with planning and executing the event, and it was so much fun meeting and talking to all new and current contributors during the main event and the pre-event celebration.
Contributor Summit in Barcelona kicked off KubeCon + CloudNativeCon in a big way as it was the **largest contributor summit** to date with 331 people signed up, and only 9 didn't pick up their badges!
## Contributor Celebration
Sunday evening before the main event we held a **Contributor Celebration**, which was very well attended. We hope that all new and current contributors felt welcome and enjoyed the food, the music, and the company.
![contributor-celebration2](https://live.staticflickr.com/65535/46981485515_561bb324b2_z.jpg)
![contributor-celebration](https://live.staticflickr.com/65535/46981484655_8122564557_z.jpg)
## New Contributor Workshops
We had over **130 people registered** for the New Contributor Workshops. This year the workshops were divided into _101-level content_ for people who were not familiar with contributing to an open source project, and _201-level content_ for those who were.
The workshops contained overviews of what SIGs are, deep-dives into the codebase, test builds of the Kubernetes project, and real contributions.
Did you miss something during the workshops? We now have them [published on YouTube](https://www.youtube.com/playlist?list=PL69nYSiGNLP2WTJ6P8sQenhf0RY-JqF5L), with added closed captioning!
![img](https://live.staticflickr.com/65535/47897543541_a57d3b9ac9_z.jpg)
![img](https://live.staticflickr.com/65535/47108247174_5d60b60846_z.jpg)
## SIG Face-to-Face
We also tried a new thing for Barcelona, the SIG Face-to-Face meetings. We had **over 170 people** registered to attend the 11 SIG and one subproject meetings throughout the day, going over what they're working on and what they want to do in the near future.
![img](https://live.staticflickr.com/65535/47108254124_248a80ef1a_z.jpg)
![img](https://live.staticflickr.com/65535/47108250434_88afdf930a_z.jpg)
## SIG Meet and Greet
At the end of the summit, both new and current contributors had a chance to sit down with SIG chairs and members. The goal of this was to make sure that contributors got to know even more individuals in the project, hear what some of the SIGs actually do, and sign up to be a part of them and learn more.
![img](https://live.staticflickr.com/65535/47108248464_97eb2bbbb6_k.jpg)
![img](https://live.staticflickr.com/65535/47845452032_a3d478beb9_k.jpg)
## Join us!
Interested in attending the Contributor Summit in San Diego? [You can get more information on our event page](https://events.linuxfoundation.org/events/contributor-summit-north-america-2019/), sign up and we will notify you when registration opens.
## Thanks!
Again, thank you to everyone for making this an amazing event, and we're looking forward to seeing you next time!
To our Barcelona crew, you ROCK! 🥁
Paris Pittman, Bob Killen, Guinevere Saenger, Tim Pepper, Deb Giles, Ihor Dvoretskyi, Jorge Castro, Noah Kantrowitz, Dawn Foster, Ruben Orduz, Josh Berkus, Kiran Mova, Bart Smykla, Rostislav Georgiev, Jeffrey Sica, Rael Garcia, Silvia Moura Pina, Arnaud Meukam, Jason DeTiberius, Andy Goldstein, Suzanne Ambiel, Jonas Rosland
You can see many more pictures from the event [over on CNCF's Flickr](https://www.flickr.com/photos/143247548@N03/sets/72157680323974628).
content/en/blog/_posts/2019-07-18-some-apis-are-being-deprecated.md
+94
View File
@@ -0,0 +1,94 @@
---
layout: blog
title: "Deprecated APIs Removed In 1.16: Here’s What You Need To Know"
date: 2019-07-18
slug: api-deprecations-in-1-16
---
**Author**: Vallery Lancey (Lyft)
As the Kubernetes API evolves, APIs are periodically reorganized or upgraded.
When APIs evolve, the old API is deprecated and eventually removed.
The 1.16 release will deprecate APIs for four services:
* NetworkPolicy
* PodSecurityPolicy
* DaemonSet, Deployment, StatefulSet, and ReplicaSet
* Ingress
None of these resources will be removed from Kubernetes or deprecated in any way.
However, to continue using these resources, you must use a current version of
the Kubernetes API.
# Migration Details
* NetworkPolicy: will no longer be served from **extensions/v1beta1** in **v1.16**.
* Migrate to the networking.k8s.io/v1 API, available since v1.8. Existing persisted
data can be retrieved/updated via the networking.k8s.io/v1 API.
* PodSecurityPolicy: will no longer be served from **extensions/v1beta1** in **v1.16**.
* Migrate to the policy/v1beta1 API, available since v1.10. Existing persisted
data can be retrieved/updated via the policy/v1beta1 API.
* DaemonSet, Deployment, StatefulSet, and ReplicaSet: will no longer be served
from **extensions/v1beta1**, **apps/v1beta1**, or **apps/v1beta2** in **v1.16**.
* Migrate to the apps/v1 API, available since v1.9. Existing persisted data
can be retrieved/updated via the apps/v1 API.
* Ingress: will no longer be served from **extensions/v1beta1** in **v1.18**.
* Migrate to the networking.k8s.io/v1beta1 API. Existing persisted data can be
retrieved/updated via the networking.k8s.io/v1beta1 API.
# What To Do
Kubernetes 1.16 is due to be released in September 2019, so be sure to audit
your configuration and integrations now!
* Change YAML files to reference the newer APIs
* Update custom integrations and controllers to call the newer APIs
* Update third party tools (ingress controllers, continuous delivery systems)
to call the newer APIs
Migrating to the new Ingress API will only require changing the API path - the
API fields remain the same. However, migrating other resources (EG Deployments)
will require some updates based on changed fields. You can use the
`kubectl convert` command to automatically convert an existing object:
`kubectl convert -f <file> --output-version <group>/<version>`.
For example, to convert
an older Deployment to apps/v1, you can run:
`kubectl convert -f ./my-deployment.yaml --output-version apps/v1`
Note that this may use non-ideal default values. To learn more about a specific
resource, check the Kubernetes [api reference](https://kubernetes.io/docs/reference/#api-reference).
You can test your clusters by starting an apiserver with the above resources
disabled, to simulate the upcoming removal. Add the following flag to the
apiserver startup arguments:
`--runtime-config=apps/v1beta1=false,apps/v1beta2=false,extensions/v1beta1/daemonsets=false,extensions/v1beta1/deployments=false,extensions/v1beta1/replicasets=false,extensions/v1beta1/networkpolicies=false,extensions/v1beta1/podsecuritypolicies=false`
# Want To Know More?
Deprecations are announced in the Kubernetes release notes. You can see these
announcements in
[1.14](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md#deprecations)
and [1.15](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md#deprecations-and-removals).
You can read more [in our deprecation policy document](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api)
about the deprecation policies for Kubernetes APIs, and other Kubernetes components.
Deprecation policies vary by component (for example, the primary APIs vs.
admin CLIs) and by maturity (alpha, beta, or GA).
These details were also [previously announced](https://groups.google.com/forum/#!topic/kubernetes-dev/je0rjyfTVyc)
on the kubernetes-dev mailing list, along with the releases of Kubernetes 1.14
and 1.15. From Jordan Liggitt:
```
In case you missed it in the 1.15.0 release notes, the timelines for deprecated resources in the extensions/v1beta1, apps/v1beta1, and apps/v1beta2 API groups to no longer be served by default have been updated:
* NetworkPolicy resources will no longer be served from extensions/v1beta1 by default in v1.16. Migrate to the networking.k8s.io/v1 API, available since v1.8. Existing persisted data can be retrieved/updated via the networking.k8s.io/v1 API.
* PodSecurityPolicy resources will no longer be served from extensions/v1beta1 by default in v1.16. Migrate to the policy/v1beta1 API, available since v1.10. Existing persisted data can be retrieved/updated via the policy/v1beta1 API.
* DaemonSet, Deployment, StatefulSet, and ReplicaSet resources will no longer be served from extensions/v1beta1, apps/v1beta1, or apps/v1beta2 by default in v1.16. Migrate to the apps/v1 API, available since v1.9. Existing persisted data can be retrieved/updated via the apps/v1 API.
To start a v1.15.0 API server with these resources disabled to flush out dependencies on these deprecated APIs, and ensure your application/manifests will work properly against the v1.16 release, use the following --runtime-config argument:
--runtime-config=apps/v1beta1=false,apps/v1beta2=false,extensions/v1beta1/daemonsets=false,extensions/v1beta1/deployments=false,extensions/v1beta1/replicasets=false,extensions/v1beta1/networkpolicies=false,extensions/v1beta1/podsecuritypolicies=false
```
content/en/blog/_posts/2019-07-23-get-started-with-kubernetes-using-python.md
+230
View File
@@ -0,0 +1,230 @@
---
layout: blog
title: "Get started with Kubernetes (using Python)"
date: 2019-07-23
---
**Author**: Jason Haley (Independent Consultant)
So, you know you want to run your application in Kubernetes but don’t know where to start. Or maybe you’re getting started but still don’t know what you don’t know. In this blog you’ll walk through how to containerize an application and get it running in Kubernetes.
This walk-through assumes you are a developer or at least comfortable with the command line (preferably bash shell).
## What we’ll do
1. Get the code and run the application locally
2. Create an image and run the application in Docker
3. Create a deployment and run the application in Kubernetes
## Prerequisites
* A Kubernetes service - I'm using [Docker Desktop with Kubernetes](https://www.docker.com/products/kubernetes) in this walkthrough, but you can use one of the others. See [Getting Started](https://kubernetes.io/docs/setup/) for a full listing.
* [Python 3.7](https://www.python.org/) installed
* [Git](https://git-scm.com/downloads) installed
## Containerizing an application
In this section you’ll take some source code, verify it runs locally, and then create a Docker image of the application. The sample application used is a very simple Flask web application; if you want to test it locally, you’ll need Python installed. Otherwise, you can skip to the "Create a Dockerfile" section.
### Get the application code
Use git to clone the repository to your local machine:
```
git clone https://github.com/JasonHaley/hello-python.git
```
Change to the app directory:
```
cd hello-python/app
```
There are only two files in this directory. If you look at the main.py file, you’ll see the application prints out a hello message. You can learn more about Flask on the [Flask website](http://flask.pocoo.org/).
```
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "Hello from Python!"
if __name__ == "__main__":
app.run(host='0.0.0.0')
```
The requirements.txt file contains the list of packages needed by the main.py and will be used by [pip](https://pip.pypa.io/en/stable/) to install the Flask library.
{{< note >}}
When you start writing more advanced Python, you'll find it's not always recommended to use `pip install` and may want to use `virtualenv` (or `pyenv`) to install your dependencies in a virtual environment.
{{< /note >}}
### Run locally
Manually run the installer and application using the following commands:
```
pip install -r requirements.txt
python main.py
```
This will start a development web server hosting your application, which you will be able to see by navigating to http://localhost:5000. Because port 5000 is the default port for the development server, we didn’t need to specify it.
### Create a Dockerfile
Now that you have verified the source code works, the first step in containerizing the application is to create a Dockerfile.
In the hello-python/app directory, create a file named Dockerfile with the following contents and save it:
```
FROM python:3.7
RUN mkdir /app
WORKDIR /app
ADD . /app/
RUN pip install -r requirements.txt
EXPOSE 5000
CMD ["python", "/app/main.py"]
```
This file is a set of instructions Docker will use to build the image. For this simple application, Docker is going to:
1. Get the official [Python Base Image](https://hub.docker.com/_/python/) for version 3.7 from Docker Hub.
2. In the image, create a directory named app.
3. Set the working directory to that new app directory.
4. Copy the local directory’s contents to that new folder into the image.
5. Run the pip installer (just like we did earlier) to pull the requirements into the image.
6. Inform Docker the container listens on port 5000.
7. Configure the starting command to use when the container starts.
### Create an image
At your command line or shell, in the hello-python/app directory, build the image with the following command:
```
docker build -f Dockerfile -t hello-python:latest .
```
{{< note >}}
I'm using the :latest tag in this example, if you are not familiar with what it is you may want to read [Docker: The latest Confusion](https://container-solutions.com/docker-latest-confusion/).
{{< /note >}}
This will perform those seven steps listed above and create the image. To verify the image was created, run the following command:
```
docker image ls
```
<img src="/images/blog/get-started-with-kubernetes-using-python/docker-image-ls.png" alt="Docker image listing" />
The application is now containerized, which means it can now run in Docker and Kubernetes!
## Running in Docker
Before jumping into Kubernetes, let’s verify it works in Docker.
Run the following command to have Docker run the application in a container and map it to port 5001:
```
docker run -p 5001:5000 hello-python
```
Now navigate to http://localhost:5001, and you should see the “Hello form Python!” message.
### More info
* [Get started with Docker](https://docs.docker.com/get-started/)
* [Best practices for writing Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/)
* [Docker Cheat Sheet](https://www.docker.com/sites/default/files/Docker_CheatSheet_08.09.2016_0.pdf) (pdf)
## Running in Kubernetes
You are finally ready to get the application running in Kubernetes. Because you have a web application, you will create a service and a deployment.
First verify your kubectl is configured. At the command line, type the following:
```
kubectl version
```
If you don’t see a reply with a Client and Server version, you’ll need to [install](https://kubernetes.io/docs/tasks/tools/install-kubectl/) and configure it.
If you are running on Windows or Mac, make sure it is using the Docker for Desktop context by running the following:
```
kubectl config use-context docker-for-desktop
```
Now you are working with Kubernetes! You can see the node by typing:
```
kubectl get nodes
```
Now let’s have it run the application. Create a file named deployment.yaml and add the following contents to it and then save it:
```yaml
apiVersion: v1
kind: Service
metadata:
name: hello-python-service
spec:
selector:
app: hello-python
ports:
- protocol: "TCP"
port: 6000
targetPort: 5000
type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-python
spec:
replicas: 4
template:
metadata:
labels:
app: hello-python
spec:
containers:
- name: hello-python
image: hello-python:latest
imagePullPolicy: Never
ports:
- containerPort: 5000
```
This YAML file is the instructions to Kubernetes for what you want running. It is telling Kubernetes the following:
* You want a load-balanced service exposing port 6000
* You want four instances of the hello-python container running
Use kubectl to send the YAML file to Kubernetes by running the following command:
```
kubectl apply -f deployment.yaml
```
You can see the pods are running if you execute the following command:
```
kubectl get pods
```
<img src="/images/blog/get-started-with-kubernetes-using-python/kubectl-get-pods.png" alt="Pod listing" />
Now navigate to http://localhost:6000, and you should see the “Hello form Python!” message.
That’s it! The application is now running in Kubernetes!
### More Info
* [Learn Kubernetes Basics](https://azure.microsoft.com/en-us/topic/kubernetes/)
* [kubectl Cheat Sheet](https://kubernetes.io/docs/reference/kubectl/cheatsheet/)
* [kubectl for Docker Users](https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/)
## Summary
In this walk-through, we containerized an application, and got it running in Docker and in Kubernetes. This simple application only scratches the surface of what’s possible (and what you’ll need to learn).
### Next steps
If you are just getting started and this walk-through was useful to you, then the following resources should be good next steps for you to further expand your Kubernetes knowledge:
* [Introduction to Microservices, Docker, and Kubernetes](https://www.youtube.com/watch?v=1xo-0gCVhTU) - 55-minute video by James Quigley
* This is a great place to start because it provides more information than I could here.
* [Containerize your Apps with Docker and Kubernetes](https://github.com/PacktPublishing/Containerize-your-Apps-with-Docker-and-Kubernetes) - free e-book by Dr Gabriel N Schenker
* This is my favorite book on Docker and Kubernetes.
* [Kubernetes Learning Path: 50 days from zero to hero with Kubernetes](https://aka.ms/LearnKubernetes) - on Microsoft’s site
* This is a 10-page pdf that has tons of links to videos (with Brendan Burns), documentation sites, and a really good workshop for Azure Kubernetes Service.
## How to enable Kubernetes in Docker Desktop
Once you have Docker Desktop installed, open the Settings:
<img src="/images/blog/get-started-with-kubernetes-using-python/docker-settings-menu.png" alt="Docker settings menu" />
Select the **Kubernetes** menu item on the left and verify that the **Enable Kubernetes** is checked. If it isn’t, **check it** and click the **Apply** button at the bottom right:
<img src="/images/blog/get-started-with-kubernetes-using-python/kubernetes-tab.png" alt="Kubernetes tab" />
content/en/case-studies/chinaunicom/index.html
+1 -1
View File
@@ -89,7 +89,7 @@ quote: >
<div class="fullcol">
Platform Technology R&D team member Jie Jia adds that though "this technology is relatively complicated, as long as developers get used to it, they can enjoy all the benefits." And Zhang points out that in his own experience with virtual machine cloud, "Kubernetes and these cloud native technologies are relatively simpler."<br><br>
Plus, "companies can use the managed services offered by companies like <a href="https://www.docker.com/">Rancher</a>, because they have already customized this technology," says Jia. "You can easily leverage this technology."<br><br>
Plus, "companies can use the managed services offered by companies like <a href="https://rancher.com/">Rancher</a>, because they have already customized this technology," says Jia. "You can easily leverage this technology."<br><br>
Looking ahead, China Unicom plans to develop more applications on Kubernetes, focusing on big data and machine learning. The team is continuing to optimize the cloud platform that it built, and hopes to pass the conformance test to join CNCF’s <a href="https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/">Certified Kubernetes Conformance Program</a>. They’re also hoping to someday contribute code back to the community. <br><br>
If that sounds ambitious, it’s because the results they’ve gotten from adopting Kubernetes have been beyond even their greatest expectations. Says Zhang: "We could never imagine we can achieve this scalability in such a short time."
content/en/case-studies/spotify/index.html
+3 -2
View File
@@ -1,6 +1,6 @@
---
title: Spotify study Case Study
linkTitle: cern
linkTitle: Spotify
case_study_styles: true
cid: caseStudies
css: /css/style_case_studies.css
@@ -33,6 +33,7 @@ quote: >
<br><br>
<h2>Solution</h2>
"We saw the amazing community that had grown up around Kubernetes, and we wanted to be part of that," says Chakrabarti. Kubernetes was more feature-rich than Helios. Plus, "we wanted to benefit from added velocity and reduced cost, and also align with the rest of the industry on best practices and tools." At the same time, the team wanted to contribute its expertise and influence in the flourishing Kubernetes community. The migration, which would happen in parallel with Helios running, could go smoothly because "Kubernetes fit very nicely as a complement and now as a replacement to Helios," says Chakrabarti.
<br><br>
<h2>Impact</h2>
The team spent much of 2018 addressing the core technology issues required for a migration, which started late that year and is a big focus for 2019. "A small percentage of our fleet has been migrated to Kubernetes, and some of the things that we’ve heard from our internal teams are that they have less of a need to focus on manual capacity provisioning and more time to focus on delivering features for Spotify," says Chakrabarti. The biggest service currently running on Kubernetes takes about 10 million requests per second as an aggregate service and benefits greatly from autoscaling, says Site Reliability Engineer James Wen. Plus, he adds, "Before, teams would have to wait for an hour to create a new service and get an operational host to run it in production, but with Kubernetes, they can do that on the order of seconds and minutes." In addition, with Kubernetes’s bin-packing and multi-tenancy capabilities, CPU utilization has improved on average two- to threefold.
@@ -48,7 +49,7 @@ quote: >
<section class="section2">
<div class="fullcol">
<h2>"Our goal is to empower creators and enable a really immersive listening experience for all of the consumers that we have today—and hopefully the consumers we’ll have in the future," says Jai Chakrabarti, Director of Engineering, Infrastructure and Operations at Spotify. Since the audio-streaming platform launched in 2008, it has already grown to over 200 million monthly active users around the world, and for Chakrabarti’s team, the goal is solidifying Spotify’s infrastructure to support all those future consumers too.</h2>
"Our goal is to empower creators and enable a really immersive listening experience for all of the consumers that we have today—and hopefully the consumers we’ll have in the future," says Jai Chakrabarti, Director of Engineering, Infrastructure and Operations at Spotify. Since the audio-streaming platform launched in 2008, it has already grown to over 200 million monthly active users around the world, and for Chakrabarti’s team, the goal is solidifying Spotify’s infrastructure to support all those future consumers too.<br><br>
<br><br>
An early adopter of microservices and Docker, Spotify had containerized microservices running across its fleet of VMs since 2014. The company used an open source, homegrown container orchestration system called Helios, and in 2016-17 completed a migration from on premise data centers to Google Cloud. Underpinning these decisions, "We have a culture around autonomous teams, over 200 autonomous engineering squads who are working on different pieces of the pie, and they need to be able to iterate quickly," Chakrabarti says. "So for us to have developer velocity tools that allow squads to move quickly is really important."<br><br>
But by late 2017, it became clear that "having a small team working on the <a href="https://github.com/spotify/helios">Helios</a> features was just not as efficient as adopting something that was supported by a much bigger community," says Chakrabarti. "We saw the amazing community that had grown up around Kubernetes, and we wanted to be part of that. We wanted to benefit from added velocity and reduced cost, and also align with the rest of the industry on best practices and tools." At the same time, the team wanted to contribute its expertise and influence in the flourishing Kubernetes community.
content/en/docs/concepts/_index.md
+1 -1
View File
@@ -7,7 +7,7 @@ weight: 40
{{% capture overview %}}
The Concepts section helps you learn about the parts of the Kubernetes system and the abstractions Kubernetes uses to represent your cluster, and helps you obtain a deeper understanding of how Kubernetes works.
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 %}}
content/en/docs/concepts/architecture/nodes.md
+4
View File
@@ -30,6 +30,10 @@ A node's status contains the following information:
* [Capacity and Allocatable](#capacity)
* [Info](#info)
Node status and other details about a node can be displayed using below command:
```shell
kubectl describe node <insert-node-name-here>
```
Each section is described in detail below.
### Addresses
content/en/docs/concepts/cluster-administration/certificates.md
+1 -1
View File
@@ -162,7 +162,7 @@ Finally, add the same parameters into the API server start parameters.
}
}
1. Create a JSON config file for CA certificate signing request (CSR), for example,
`ca-csr.json`. Be sure the replace the values marked with angle brackets with
`ca-csr.json`. Be sure to replace the values marked with angle brackets with
real values you want to use.
{
content/en/docs/concepts/cluster-administration/cloud-providers.md
+2 -2
View File
@@ -336,10 +336,10 @@ should appear in the `[Metadata]` section of the `cloud.conf` file:
both configuration drive and metadata service though and only one or the other
may be available which is why the default is to check both.
##### Router
##### Route
These configuration options for the OpenStack provider pertain to the [kubenet]
Kubernetes network plugin and should appear in the `[Router]` section of the
Kubernetes network plugin and should appear in the `[Route]` section of the
`cloud.conf` file:
* `router-id` (Optional): If the underlying cloud's Neutron deployment supports
content/en/docs/concepts/cluster-administration/logging.md
+7 -1
View File
@@ -36,6 +36,9 @@ To run this pod, use the following command:
```shell
kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
```
The output is:
```
pod/counter created
```
@@ -43,6 +46,9 @@ To fetch the logs, use the `kubectl logs` command, as follows:
```shell
kubectl logs counter
```
The output is:
```
0: Mon Jan 1 00:00:00 UTC 2001
1: Mon Jan 1 00:00:01 UTC 2001
2: Mon Jan 1 00:00:02 UTC 2001
@@ -105,7 +111,7 @@ systemd is not present, they write to `.log` files in the `/var/log` directory.
System components inside containers always write to the `/var/log` directory,
bypassing the default logging mechanism. They use the [klog][klog]
logging library. You can find the conventions for logging severity for those
components in the [development docs on logging](https://git.k8s.io/community/contributors/devel/logging.md).
components in the [development docs on logging](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
Similarly to the container logs, system component logs in the `/var/log`
directory should be rotated. In Kubernetes clusters brought up by
content/en/docs/concepts/cluster-administration/manage-deployment.md
-1
View File
@@ -1,6 +1,5 @@
---
reviewers:
- bgrant0607
- janetkuo
- mikedanese
title: Managing Resources
content/en/docs/concepts/cluster-administration/networking.md
+12
View File
@@ -98,6 +98,14 @@ AOS supports the use of common vendor equipment from manufacturers including Cis
Details on how the AOS system works can be accessed here: http://www.apstra.com/products/how-it-works/
### AWS VPC CNI for Kubernetes
The [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) offers integrated AWS Virtual Private Cloud (VPC) networking for Kubernetes clusters. This CNI plugin offers high throughput and availability, low latency, and minimal network jitter. Additionally, users can apply existing AWS VPC networking and security best practices for building Kubernetes clusters. This includes the ability to use VPC flow logs, VPC routing policies, and security groups for network traffic isolation.
Using this CNI plugin allows Kubernetes pods to have the same IP address inside the pod as they do on the VPC network. The CNI allocates AWS Elastic Networking Interfaces (ENIs) to each Kubernetes node and using the secondary IP range from each ENI for pods on the node. The CNI includes controls for pre-allocation of ENIs and IP addresses for fast pod startup times and enables large clusters of up to 2,000 nodes.
Additionally, the CNI can be run alongside [Calico for network policy enforcement](https://docs.aws.amazon.com/eks/latest/userguide/calico.html). The AWS VPC CNI project is open source with [documentation on GitHub](https://github.com/aws/amazon-vpc-cni-k8s).
### Big Cloud Fabric from Big Switch Networks
[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) is a cloud native networking architecture, designed to run Kubernetes in private cloud/on-premises environments. Using unified physical & virtual SDN, Big Cloud Fabric tackles inherent container networking problems such as load balancing, visibility, troubleshooting, security policies & container traffic monitoring.
@@ -213,6 +221,10 @@ traffic to the internet.
[Knitter](https://github.com/ZTE/Knitter/) is a network solution which supports multiple networking in Kubernetes. It provides the ability of tenant management and network management. Knitter includes a set of end-to-end NFV container networking solutions besides multiple network planes, such as keeping IP address for applications, IP address migration, etc.
### Kube-OVN
[Kube-OVN](https://github.com/alauda/kube-ovn) is an OVN-based kubernetes network fabric for enterprises. With the help of OVN/OVS, it provides some advanced overlay network features like subnet, QoS, static IP allocation, traffic mirroring, gateway, openflow-based network policy and service proxy.
### Kube-router
[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer.
content/en/docs/concepts/configuration/assign-pod-node.md
+29 -37
View File
@@ -11,8 +11,9 @@ weight: 30
{{% capture overview %}}
You can constrain a [pod](/docs/concepts/workloads/pods/pod/) to only be able to run on particular [nodes](/docs/concepts/architecture/nodes/) or to prefer to
run on particular nodes. There are several ways to do this, and the recommended approaches all use
You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} to only be able to run on particular
{{< glossary_tooltip text="Node(s)" term_id="node" >}}, or to prefer to run on particular nodes.
There are several ways to do this, and the recommended approaches all use
[label selectors](/docs/concepts/overview/working-with-objects/labels/) to make the selection.
Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement
(e.g. spread your pods across nodes, not place the pod on a node with insufficient free resources, etc.)
@@ -20,9 +21,6 @@ but there are some circumstances where you may want more control on a node where
that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different
services that communicate a lot into the same availability zone.
You can find all the files for these examples [in our docs
repo here](https://github.com/kubernetes/website/tree/{{< param "docsbranch" >}}/content/en/docs/concepts/configuration/).
{{% /capture %}}
{{% capture body %}}
@@ -38,14 +36,12 @@ Let's walk through an example of how to use `nodeSelector`.
### Step Zero: Prerequisites
This example assumes that you have a basic understanding of Kubernetes pods and that you have [turned up a Kubernetes cluster](https://github.com/kubernetes/kubernetes#documentation).
This example assumes that you have a basic understanding of Kubernetes pods and that you have [set up a Kubernetes cluster](/docs/setup/).
### Step One: Attach label to the node
Run `kubectl get nodes` to get the names of your cluster's nodes. Pick out the one that you want to add a label to, and then run `kubectl label nodes <node-name> <label-key>=<label-value>` to add a label to the node you've chosen. For example, if my node name is 'kubernetes-foo-node-1.c.a-robinson.internal' and my desired label is 'disktype=ssd', then I can run `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`.
If this fails with an "invalid command" error, you're likely using an older version of kubectl that doesn't have the `label` command. In that case, see the [previous version](https://github.com/kubernetes/kubernetes/blob/a053dbc313572ed60d89dae9821ecab8bfd676dc/examples/node-selection/README.md) of this guide for instructions on how to manually set labels on a node.
You can verify that it worked by re-running `kubectl get nodes --show-labels` and checking that the node now has a label. You can also use `kubectl describe node "nodename"` to see the full list of labels of the given node.
### Step Two: Add a nodeSelector field to your pod configuration
@@ -74,17 +70,17 @@ the Pod will get scheduled on the node that you attached the label to. You can
verify that it worked by running `kubectl get pods -o wide` and looking at the
"NODE" that the Pod was assigned to.
## Interlude: built-in node labels
## Interlude: built-in node labels {#built-in-node-labels}
In addition to labels you [attach](#step-one-attach-label-to-the-node), nodes come pre-populated
with a standard set of labels. As of Kubernetes v1.4 these labels are
with a standard set of labels. These labels are
* `kubernetes.io/hostname`
* `failure-domain.beta.kubernetes.io/zone`
* `failure-domain.beta.kubernetes.io/region`
* `beta.kubernetes.io/instance-type`
* `kubernetes.io/os`
* `kubernetes.io/arch`
* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domain-beta-kubernetes-io-zone)
* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domain-beta-kubernetes-io-region)
* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)
{{< note >}}
The value of these labels is cloud provider specific and is not guaranteed to be reliable.
@@ -103,14 +99,15 @@ and influencing the scheduler to schedule workloads to the compromised node.
The `NodeRestriction` admission plugin prevents kubelets from setting or modifying labels with a `node-restriction.kubernetes.io/` prefix.
To make use of that label prefix for node isolation:
1. Ensure you are using the [Node authorizer](/docs/reference/access-authn-authz/node/) and have enabled the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
2. Add labels under the `node-restriction.kubernetes.io/` prefix to your Node objects, and use those labels in your node selectors.
1. Check that you're using Kubernetes v1.11+ so that NodeRestriction is available.
2. Ensure you are using the [Node authorizer](/docs/reference/access-authn-authz/node/) and have _enabled_ the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
3. Add labels under the `node-restriction.kubernetes.io/` prefix to your Node objects, and use those labels in your node selectors.
For example, `example.com.node-restriction.kubernetes.io/fips=true` or `example.com.node-restriction.kubernetes.io/pci-dss=true`.
## Affinity and anti-affinity
`nodeSelector` provides a very simple way to constrain pods to nodes with particular labels. The affinity/anti-affinity
feature, currently in beta, greatly expands the types of constraints you can express. The key enhancements are
feature, greatly expands the types of constraints you can express. The key enhancements are
1. the language is more expressive (not just "AND of exact match")
2. you can indicate that the rule is "soft"/"preference" rather than a hard requirement, so if the scheduler
@@ -126,9 +123,8 @@ described in the third item listed above, in addition to having the first and se
`nodeSelector` continues to work as usual, but will eventually be deprecated, as node affinity can express
everything that `nodeSelector` can express.
### Node affinity (beta feature)
### Node affinity
Node affinity was introduced as alpha in Kubernetes 1.2.
Node affinity is conceptually similar to `nodeSelector` -- it allows you to constrain which nodes your
pod is eligible to be scheduled on, based on labels on the node.
@@ -143,7 +139,7 @@ met, the pod will still continue to run on the node. In the future we plan to of
except that it will evict pods from nodes that cease to satisfy the pods' node affinity requirements.
Thus an example of `requiredDuringSchedulingIgnoredDuringExecution` would be "only run the pod on nodes with Intel CPUs"
and an example `preferredDuringSchedulingIgnoredDuringExecution` would be "try to run this set of pods in availability
and an example `preferredDuringSchedulingIgnoredDuringExecution` would be "try to run this set of pods in failure
zone XYZ, but if it's not possible, then allow some to run elsewhere".
Node affinity is specified as field `nodeAffinity` of field `affinity` in the PodSpec.
@@ -172,21 +168,17 @@ If you remove or change the label of the node where the pod is scheduled, the po
The `weight` field in `preferredDuringSchedulingIgnoredDuringExecution` is in the range 1-100. For each node that meets all of the scheduling requirements (resource request, RequiredDuringScheduling affinity expressions, etc.), the scheduler will compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node matches the corresponding MatchExpressions. This score is then combined with the scores of other priority functions for the node. The node(s) with the highest total score are the most preferred.
For more information on node affinity, see the
[design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md).
### Inter-pod affinity and anti-affinity
### Inter-pod affinity and anti-affinity (beta feature)
Inter-pod affinity and anti-affinity were introduced in Kubernetes 1.4.
Inter-pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to be scheduled *based on
labels on pods that are already running on the node* rather than based on labels on nodes. The rules are of the form "this pod should (or, in the case of
anti-affinity, should not) run in an X if that X is already running one or more pods that meet rule Y". Y is expressed
as a LabelSelector with an associated list of namespaces; unlike nodes, because pods are namespaced
labels on pods that are already running on the node* rather than based on labels on nodes. The rules are of the form
"this pod should (or, in the case of anti-affinity, should not) run in an X if that X is already running one or more pods that meet rule Y".
Y is expressed as a LabelSelector with an optional associated list of namespaces; unlike nodes, because pods are namespaced
(and therefore the labels on pods are implicitly namespaced),
a label selector over pod labels must specify which namespaces the selector should apply to. Conceptually X is a topology domain
like node, rack, cloud provider zone, cloud provider region, etc. You express it using a `topologyKey` which is the
key for the node label that the system uses to denote such a topology domain, e.g. see the label keys listed above
in the section [Interlude: built-in node labels](#interlude-built-in-node-labels).
in the section [Interlude: built-in node labels](#built-in-node-labels).
{{< note >}}
Inter-pod affinity and anti-affinity require substantial amount of
@@ -360,12 +352,6 @@ no two instances are located on the same host.
See [ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)
for an example of a StatefulSet configured with anti-affinity for high availability, using the same technique.
For more information on inter-pod affinity/anti-affinity, see the
[design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
You may want to check [Taints](/docs/concepts/configuration/taint-and-toleration/)
as well, which allow a *node* to *repel* a set of pods.
## nodeName
`nodeName` is the simplest form of node selection constraint, but due
@@ -405,4 +391,10 @@ The above pod will run on the node kube-01.
{{% capture whatsnext %}}
[Taints](/docs/concepts/configuration/taint-and-toleration/) allow a Node to *repel* a set of Pods.
The design documents for
[node affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)
and for [inter-pod affinity/anti-affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) contain extra background information about these features.
{{% /capture %}}
content/en/docs/concepts/configuration/pod-priority-preemption.md
+1 -1
View File
@@ -94,7 +94,7 @@ old-style command line options. Below is a sample component config to disable
preemption:
```yaml
apiVersion: componentconfig/v1alpha1
apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration
algorithmSource:
provider: DefaultProvider
content/en/docs/concepts/configuration/scheduling-framework.md
+4 -4
View File
@@ -18,7 +18,7 @@ scheduling "core" simple and maintainable. Refer to the [design proposal of the
scheduling framework][kep] for more technical information on the design of the
framework.
[kep]: (https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md)
[kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md
{{% /capture %}}
@@ -54,7 +54,7 @@ equivalent to "Predicate" and "Scoring" is equivalent to "Priority function".
One plugin may register at multiple extension points to perform more complex or
stateful tasks.
{{< figure src="/images/docs/scheduling-framework.png" title="scheduling framework extension points" >}}
{{< figure src="/images/docs/scheduling-framework-extensions.png" title="scheduling framework extension points" >}}
### Queue sort
@@ -238,7 +238,7 @@ decode and process the configuration.
The following example shows a scheduler configuration that enables some
plugins at `reserve` and `preBind` extension points and disables a plugin. It
also provides a configuration to plugin `foo`.
also provides a configuration to plugin `foo`.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1alpha1
@@ -274,7 +274,7 @@ calling default plugins is desired, default plugins must be `disabled` and
`enabled` in the desired order.
Assuming there is a default plugin called `foo` at `reserve` and we are adding
pluing `bar` that we want to be invoked before `foo`, we should disable `foo`
plugin `bar` that we want to be invoked before `foo`, we should disable `foo`
and enable `bar` and `foo` in order. The following example shows the
configuration that achieves this:
content/en/docs/concepts/configuration/secret.md
+33 -1
View File
@@ -359,6 +359,38 @@ echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
1f2d1e2e67df
```
#### Editing a Secret
An existing secret may be edited with the following command:
```shell
kubectl edit secrets mysecret
```
This will open the default configured editor and allow for updating the base64 encoded secret values in the `data` field:
```
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
kind: Secret
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: { ... }
creationTimestamp: 2016-01-22T18:41:56Z
name: mysecret
namespace: default
resourceVersion: "164619"
selfLink: /api/v1/namespaces/default/secrets/mysecret
uid: cfee02d6-c137-11e5-8d73-42010af00002
type: Opaque
```
## Using Secrets
Secrets can be mounted as data volumes or be exposed as
@@ -833,7 +865,7 @@ EOF
Apply all those objects on the Apiserver by
```shell
kubectl apply --k .
kubectl apply -k .
```
Both containers will have the following files present on their filesystems with the values for each container's environment:
content/en/docs/concepts/containers/images.md
+3 -4
View File
@@ -60,7 +60,7 @@ Credentials can be provided in several ways:
- Per-cluster
- automatically configured on Google Compute Engine or Google Kubernetes Engine
- all pods can read the project's private registry
- Using AWS EC2 Container Registry (ECR)
- 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)
@@ -93,10 +93,9 @@ 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 AWS EC2 Container Registry
### Using Amazon Elastic Container Registry
Kubernetes has native support for the [AWS EC2 Container
Registry](https://aws.amazon.com/ecr/), when nodes are AWS EC2 instances.
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.
content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+1 -1
View File
@@ -142,7 +142,7 @@ In order to monitor resources provided by device plugins, monitoring agents need
discover the set of devices that are in-use on the node and obtain metadata to describe which
container the metric should be associated with. Prometheus metrics exposed by device monitoring
agents should follow the
[Kubernetes Instrumentation Guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/instrumentation.md),
[Kubernetes Instrumentation Guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md),
which requires identifying containers using `pod`, `namespace`, and `container` prometheus labels.
The kubelet provides a gRPC service to enable discovery of in-use devices, and to provide metadata
for these devices:
content/en/docs/concepts/extend-kubernetes/extend-cluster.md
+3 -4
View File
@@ -16,7 +16,7 @@ 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
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
@@ -122,7 +122,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/
### Combining New APIs with Automation
Often, when you add a new API, you also add a control loop that reads and/or writes the new APIs. When the combination of a Custom API and a control loop is used to manage a specific, usually stateful, application, this is called the *Operator* pattern. Custom APIs and control loops can also be used to control other resources, such as storage, policies, and so on.
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
@@ -205,7 +205,6 @@ the nodes chosen for a pod.
* [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/)
* See examples of Automation
* [List of Operators](https://github.com/operator-framework/awesome-operators)
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
{{% /capture %}}
content/en/docs/concepts/extend-kubernetes/operator.md
+132
View File
@@ -0,0 +1,132 @@
---
title: Operator pattern
content_template: templates/concept
weight: 30
---
{{% capture 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 %}}
## Motivation
The Operator pattern aims to capture the key aim of a human operator who
is managing a service or set of services. Human operators who look after
specific applications and services have deep knowledge of how the system
ought to behave, how to deploy it, and how to react if there are problems.
People who run workloads on Kubernetes often like to use automation to take
care of repeatable tasks. The Operator pattern captures how you can write
code to automate a task beyond what Kubernetes itself provides.
## Operators in Kubernetes
Kubernetes is designed for automation. Out of the box, you get lots of
built-in automation from the core of Kubernetes. You can use Kubernetes
to automate deploying and running workloads, *and* you can automate how
Kubernetes does that.
Kubernetes' {{< glossary_tooltip text="controllers" term_id="controller" >}}
concept lets you extend the cluster's behaviour without modifying the code
of Kubernetes itself.
Operators are clients of the Kubernetes API that act as controllers for
a [Custom Resource](/docs/concepts/api-extension/custom-resources/).
## An example Operator {#example}
Some of the things that you can use an operator to automate include:
* deploying an application on demand
* taking and restoring backups of that application's state
* handling upgrades of the application code alongside related changes such
as database schemas or extra configuration settings
* publishing a Service to applications that don't support Kubernetes APIs to
discover them
* simulating failure in all or part of your cluster to test its resilience
* choosing a leader for a distributed application without an internal
member election process
What might an Operator look like in more detail? Here's an example in more
detail:
1. A custom resource named SampleDB, that you can configure into the cluster.
2. A Deployment that makes sure a Pod is running that contains the
controller part of the operator.
3. A container image of the operator code.
4. Controller code that queries the control plane to find out what SampleDB
resources are configured.
5. The core of the Operator is code to tell the API server how to make
reality match the configured resources.
* If you add a new SampleDB, the operator sets up PersistentVolumeClaims
to provide durable database storage, a StatefulSet to run SampleDB and
a Job to handle initial configuration.
* If you delete it, the Operator takes a snapshot, then makes sure that
the the StatefulSet and Volumes are also removed.
6. The operator also manages regular database backups. For each SampleDB
resource, the operator determines when to create a Pod that can connect
to the database and take backups. These Pods would rely on a ConfigMap
and / or a Secret that has database connection details and credentials.
7. Because the Operator aims to provide robust automation for the resource
it manages, there would be additional supporting code. For this example,
code checks to see if the database is running an old version and, if so,
creates Job objects that upgrade it for you.
## Deploying Operators
The most common way to deploy an Operator is to add the
Custom Resource Definition and its associated Controller to your cluster.
The Controller will normally run outside of the
{{< glossary_tooltip text="control plane" term_id="control-plane" >}},
much as you would run any containerized application.
For example, you can run the controller in your cluster as a Deployment.
## Using an Operator {#using-operators}
Once you have an Operator deployed, you'd use it by adding, modifying or
deleting the kind of resource that the Operator uses. Following the above
example, you would set up a Deployment for the Operator itself, and then:
```shell
kubectl get SampleDB # find configured databases
kubectl edit SampleDB/example-database # manually change some settings
```
&hellip;and that's it! The Operator will take care of applying the changes
as well as keeping the existing service in good shape.
## Writing your own Operator {#writing-operator}
If there isn't an Operator in the ecosystem that implements the behavior you
want, you can code your own. In [What's next](#what-s-next) you'll find a few
links to libraries and tools you can use to write your own cloud native
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 %}}
* 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
* Use existing tools to write your own operator, eg:
* using [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
* using [kubebuilder](https://book.kubebuilder.io/)
* using [Metacontroller](https://metacontroller.app/) along with WebHooks that
you implement yourself
* using the [Operator Framework](https://github.com/operator-framework/getting-started)
* [Publish](https://operatorhub.io/) your operator for other people to use
* 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 %}}
content/en/docs/concepts/overview/components.md
+12 -7
View File
@@ -18,7 +18,7 @@ deliver a functioning Kubernetes cluster.
## Master Components
Master components provide the cluster's control plane. Master components make global decisions about the
cluster (for example, scheduling), and they detect and respond to cluster events (for example, starting up a new pod when a replication controller's `replicas` field is unsatisfied).
cluster (for example, scheduling), and they detect and respond to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied).
Master components can be run on any machine in the cluster. However,
for simplicity, set up scripts typically start all master components on
@@ -82,11 +82,13 @@ Node components run on every node, maintaining running pods and providing the Ku
## Addons
Addons are pods and services that implement cluster features. The pods may be managed
by Deployments, ReplicationControllers, and so on. Namespaced addon objects are created in
the `kube-system` namespace.
Addons use Kubernetes resources ({{< glossary_tooltip term_id="daemonset" >}},
{{< glossary_tooltip term_id="deployment" >}}, etc)
to implement cluster features. Because these are providing cluster-level features, namespaced resources
for addons belong within the `kube-system` namespace.
Selected addons are described below, for an extended list of available addons please see [Addons](/docs/concepts/cluster-administration/addons/).
Selected addons are described below; for an extended list of available addons, please
see [Addons](/docs/concepts/cluster-administration/addons/).
### DNS
@@ -111,5 +113,8 @@ A [Cluster-level logging](/docs/concepts/cluster-administration/logging/) mechan
saving container logs to a central log store with search/browsing interface.
{{% /capture %}}
{{% capture whatsnext %}}
* Learn about [Nodes](/docs/concepts/architecture/nodes/)
* Learn about [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)
* Read etcd's official [documentation](https://etcd.io/docs/)
{{% /capture %}}
content/en/docs/concepts/overview/what-is-kubernetes.md
+2 -2
View File
@@ -48,9 +48,9 @@ Containers are becoming popular because they have many benefits. Some of the con
* Resource isolation: predictable application performance.
* Resource utilization: high efficiency and density.
## Why do I need Kubernetes and what can it do
## Why you need Kubernetes and what can it do
Containers are a good way to bundle and run your applications. In a production environment, you need to manage the containers that run the applications and ensure that there is no downtime. For example, if a container goes down, another container needs to restart. Wouldn't it be easier if this behavior was handled by a system?
Containers are a good way to bundle and run your applications. In a production environment, you need to manage the containers that run the applications and ensure that there is no downtime. For example, if a container goes down, another container needs to start. Wouldn't it be easier if this behavior was handled by a system?
That's how Kubernetes comes to the rescue! Kubernetes provides you with a framework to run distributed systems resiliently. It takes care of your scaling requirements, failover, deployment patterns, and more. For example, Kubernetes can easily manage a canary deployment for your system.
content/en/docs/concepts/overview/working-with-objects/common-labels.md
+2 -2
View File
@@ -145,10 +145,10 @@ metadata:
labels:
app.kubernetes.io/name: mysql
app.kubernetes.io/instance: mysql-abcxzy
app.kubernetes.io/version: "5.7.21"
app.kubernetes.io/managed-by: helm
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
app.kubernetes.io/version: "5.7.21"
...
```
@@ -161,10 +161,10 @@ metadata:
labels:
app.kubernetes.io/name: mysql
app.kubernetes.io/instance: mysql-abcxzy
app.kubernetes.io/version: "5.7.21"
app.kubernetes.io/managed-by: helm
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
app.kubernetes.io/version: "5.7.21"
...
```
content/en/docs/concepts/overview/working-with-objects/field-selectors.md
+1 -1
View File
@@ -56,5 +56,5 @@ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Alway
You use field selectors across multiple resource types. This `kubectl` command selects all Statefulsets and Services that are not in the `default` namespace:
```shell
kubectl get statefulsets,services --field-selector metadata.namespace!=default
kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default
```
content/en/docs/concepts/overview/working-with-objects/namespaces.md
+4 -4
View File
@@ -65,13 +65,13 @@ Kubernetes starts with three initial namespaces:
### Setting the namespace for a request
To temporarily set the namespace for a request, use the `--namespace` flag.
To set the namespace for a current request, use the `--namespace` flag.
For example:
```shell
kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx
kubectl --namespace=<insert-namespace-name-here> get pods
kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>
```
### Setting the namespace preference
@@ -80,7 +80,7 @@ You can permanently save the namespace for all subsequent kubectl commands in th
context.
```shell
kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here>
kubectl config set-context --current --namespace=<insert-namespace-name-here>
# Validate it
kubectl config view | grep namespace:
```
content/en/docs/concepts/policy/limit-range.md
+1 -1
View File
@@ -69,7 +69,7 @@ kubectl create namespace limitrange-demo
To avoid passing the target limitrange-demo in your kubectl commands, change your context with the following command
```shell
kubectl config set-context $(kubectl config current-context) --namespace=limitrange-demo
kubectl config set-context --current --namespace=limitrange-demo
```
Here is the configuration file for a LimitRange object:
content/en/docs/concepts/policy/pod-security-policy.md
+10 -6
View File
@@ -158,12 +158,16 @@ also be used to provide default values for many of the fields that it
controls. When multiple policies are available, the pod security policy
controller selects policies according to the following criteria:
1. If any policies successfully validate the pod without altering it, they are
used.
2. If it is a pod creation request, then the first valid policy in alphabetical
order is used.
3. Otherwise, if it is a pod update request, an error is returned, because pod mutations
are disallowed during update operations.
1. PodSecurityPolicies which allow the pod as-is, without changing defaults or
mutating the pod, are preferred. The order of these non-mutating
PodSecurityPolicies doesn't matter.
2. If the pod must be defaulted or mutated, the first PodSecurityPolicy
(ordered by name) to allow the pod is selected.
{{< note >}}
During update operations (during which mutations to pod specs are disallowed)
only non-mutating PodSecurityPolicies are used to validate the pod.
{{< /note >}}
## Example
content/en/docs/concepts/scheduling/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
title: "Scheduling"
weight: 90
---
content/en/docs/concepts/scheduling/kube-scheduler.md
+186
View File
@@ -0,0 +1,186 @@
---
title: Kubernetes Scheduler
content_template: templates/concept
weight: 60
---
{{% capture overview %}}
In Kubernetes, _scheduling_ refers to making sure that {{< glossary_tooltip text="Pods" term_id="pod" >}}
are matched to {{< glossary_tooltip text="Nodes" term_id="node" >}} so that
{{< glossary_tooltip term_id="kubelet" >}} can run them.
{{% /capture %}}
{{% capture body %}}
## Scheduling overview {#scheduling}
A scheduler watches for newly created Pods that have no Node assigned. For
every Pod that the scheduler discovers, the scheduler becomes responsible
for finding the best Node for that Pod to run on. The scheduler reaches
this placement decision taking into account the scheduling principles
described below.
If you want to understand why Pods are placed onto a particular Node,
or if you're planning to implement a custom scheduler yourself, this
page will help you learn about scheduling.
## kube-scheduler
[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
is the default scheduler for Kubernetes and runs as part of the
{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
kube-scheduler is designed so that, if you want and need to, you can
write your own scheduling component and use that instead.
For every newly created pods or other unscheduled pods, kube-scheduler
selects a optimal node for them to run on. However, every container in
pods has different requirements for resources and every pod also has
different requirements. Therefore, existing nodes need to be filtered
according to the specific scheduling requirements.
In a cluster, Nodes that meet the scheduling requirements for a Pod
are called _feasible_ nodes. If none of the nodes are suitable, the pod
remains unscheduled until the scheduler is able to place it.
The scheduler finds feasible Nodes for a Pod and then runs a set of
functions to score the feasible Nodes and picks a Node with the highest
score among the feasible ones to run the Pod. The scheduler then notifies
the API server about this decision in a process called _binding_.
Factors that need taken into account for scheduling decisions include
individual and collective resource requirements, hardware / software /
policy constraints, affinity and anti-affinity specifications, data
locality, inter-workload interference, and so on.
## Scheduling with kube-scheduler {#kube-scheduler-implementation}
kube-scheduler selects a node for the pod in a 2-step operation:
1. Filtering
2. Scoring
The _filtering_ step finds the set of Nodes where it's feasible to
schedule the Pod. For example, the PodFitsResources filter checks whether a
candidate Node has enough available resource to meet a Pod's specific
resource requests. After this step, the node list contains any suitable
Nodes; often, there will be more than one. If the list is empty, that
Pod isn't (yet) schedulable.
In the _scoring_ step, the scheduler ranks the remaining nodes to choose
the most suitable Pod placement. The scheduler assigns a score to each Node
that survived filtering, basing this score on the active scoring rules.
Finally, kube-scheduler assigns the Pod to the Node with the highest ranking.
If there is more than one node with equal scores, kube-scheduler selects
one of these at random.
### Default policies
kube-scheduler has a default set of scheduling policies.
### Filtering
- `PodFitsHostPorts`: Checks if a Node has free ports (the network protocol kind)
for the Pod ports the the Pod is requesting.
- `PodFitsHost`: Checks if a Pod specifies a specific Node by it hostname.
- `PodFitsResources`: Checks if the Node has free resources (eg, CPU and Memory)
to meet the requirement of the Pod.
- `PodMatchNodeSelector`: Checks if a Pod's Node {{< glossary_tooltip term_id="selector" >}}
matches the Node's {{< glossary_tooltip text="label(s)" term_id="label" >}}.
- `NoVolumeZoneConflict`: Evaluate if the {{< glossary_tooltip text="Volumes" term_id="volume" >}}
that a Pod requests are available on the Node, given the failure zone restrictions for
that storage.
- `NoDiskConflict`: Evaluates if a Pod can fit on a Node due to the volumes it requests,
and those that are already mounted.
- `MaxCSIVolumeCount`: Decides how many {{< glossary_tooltip text="CSI" term_id="csi" >}}
volumes should be attached, and whether that's over a configured limit.
- `CheckNodeMemoryPressure`: If a Node is reporting memory pressure, and there's no
configured exception, the Pod won't be scheduled there.
- `CheckNodePIDPressure`: If a Node is reporting that process IDs are scarce, and
there's no configured exception, the Pod won't be scheduled there.
- `CheckNodeDiskPressure`: If a Node is reporting storage pressure (a filesystem that
is full or nearly full), and there's no configured exception, the Pod won't be
scheduled there.
- `CheckNodeCondition`: Nodes can report that they have a completely full filesystem,
that networking isn't available or that kubelet is otherwise not ready to run Pods.
If such a condition is set for a Node, and there's no configured exception, the Pod
won't be scheduled there.
- `PodToleratesNodeTaints`: checks if a Pod's {{< glossary_tooltip text="tolerations" term_id="toleration" >}}
can tolerate the Node's {{< glossary_tooltip text="taints" term_id="taint" >}}.
- `CheckVolumeBinding`: Evaluates if a Pod can fit due to the volumes it requests.
This applies for both bound and unbound
{{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}}
### Scoring
- `SelectorSpreadPriority`: Spreads Pods across hosts, considering Pods that
belonging to the same {{< glossary_tooltip text="Service" term_id="service" >}},
{{< glossary_tooltip term_id="statefulset" >}} or
{{< glossary_tooltip term_id="replica-set" >}}.
- `InterPodAffinityPriority`: Computes a sum by iterating through the elements
of weightedPodAffinityTerm and adding “weight” to the sum if the corresponding
PodAffinityTerm is satisfied for that node; the node(s) with the highest sum
are the most preferred.
- `LeastRequestedPriority`: Favors nodes with fewer requested resources. In other
words, the more Pods that are placed on a Node, and the more resources those
Pods use, the lower the ranking this policy will give.
- `MostRequestedPriority`: Favors nodes with most requested resources. This policy
will fit the scheduled Pods onto the smallest number of Nodes needed to run your
overall set of workloads.
- `RequestedToCapacityRatioPriority`: Creates a requestedToCapacity based ResourceAllocationPriority using default resource scoring function shape.
- `BalancedResourceAllocation`: Favors nodes with balanced resource usage.
- `NodePreferAvoidPodsPriority`: Priorities nodes according to the node annotation
`scheduler.alpha.kubernetes.io/preferAvoidPods`. You can use this to hint that
two different Pods shouldn't run on the same Node.
- `NodeAffinityPriority`: Prioritizes nodes according to node affinity scheduling
preferences indicated in PreferredDuringSchedulingIgnoredDuringExecution.
You can read more about this in [Assigning Pods to Nodes](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/)
- `TaintTolerationPriority`: Prepares the priority list for all the nodes, based on
the number of intolerable taints on the node. This policy adjusts a node's rank
taking that list into account.
- `ImageLocalityPriority`: Favors nodes that already have the
{{< glossary_tooltip text="container images" term_id="image" >}} for that
Pod cached locally.
- `ServiceSpreadingPriority`: For a given Service, this policy aims to make sure that
the Pods for the Service run on different nodes. It favouring scheduling onto nodes
that don't have Pods for the service already assigned there. The overall outcome is
that the Service becomes more resilient to a single Node failure.
- `CalculateAntiAffinityPriorityMap`: This policy helps implement
[pod anti-affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
- `EqualPriorityMap`: Gives an equal weight of one to all nodes.
{{% /capture %}}
{{% capture whatsnext %}}
* Read about [scheduler performance tuning](/docs/concepts/scheduling/scheduler-perf-tuning/)
* Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
* Learn about [configuring multiple schedulers](https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/)
{{% /capture %}}
content/en/docs/concepts/configuration/scheduler-perf-tuning.md → content/en/docs/concepts/scheduling/scheduler-perf-tuning.md
+14 -8
View File
@@ -10,13 +10,19 @@ weight: 70
{{< feature-state for_k8s_version="1.14" state="beta" >}}
Kube-scheduler is the Kubernetes default scheduler. It is responsible for
placement of Pods on Nodes in a cluster. Nodes in a cluster that meet the
scheduling requirements of a Pod are called "feasible" Nodes for the Pod. The
scheduler finds feasible Nodes for a Pod and then runs a set of functions to
score the feasible Nodes and picks a Node with the highest score among the
feasible ones to run the Pod. The scheduler then notifies the API server about
this decision in a process called "Binding".
[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
is the Kubernetes default scheduler. It is responsible for placement of Pods
on Nodes in a cluster.
Nodes in a cluster that meet the scheduling requirements of a Pod are
called _feasible_ Nodes for the Pod. The scheduler finds feasible Nodes
for a Pod and then runs a set of functions to score the feasible Nodes,
picking a Node with the highest score among the feasible ones to run
the Pod. The scheduler then notifies the API server about this decision
in a process called _Binding_.
This page explains performance tuning optimizations that are relevant for
large Kubernetes clusters.
{{% /capture %}}
@@ -37,7 +43,7 @@ size of the cluster if it is not specified in the configuration. It uses a
linear formula which yields 50% for a 100-node cluster. The formula yields 10%
for a 5000-node cluster. The lower bound for the automatic value is 5%. In other
words, the scheduler always scores at least 5% of the cluster no matter how
large the cluster is, unless the user provides the config option with a value
large the cluster is, unless the user provides the config option with a value
smaller than 5.
Below is an example configuration that sets `percentageOfNodesToScore` to 50%.
content/en/docs/concepts/security/overview.md
+1 -1
View File
@@ -13,7 +13,7 @@ Kubernetes Security (and security in general) is an immense topic that has many
highly interrelated parts. In today's era where open source software is
integrated into many of the systems that help web applications run,
there are some overarching concepts that can help guide your intuition about how you can
think about security holistically. This guide will define a mental model for
think about security holistically. This guide will define a mental model
for some general concepts surrounding Cloud Native Security. The mental model is completely arbitrary
and you should only use it if it helps you think about where to secure your software
stack.
content/en/docs/concepts/services-networking/ingress-controllers.md
+2 -5
View File
@@ -32,11 +32,7 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i
* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508)
for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest).
* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io).
* [HAProxy](http://www.haproxy.org/) based ingress controller
[jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress) which is mentioned on the blog post
[HAProxy Ingress Controller for Kubernetes](https://www.haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/).
[HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for HAProxy Enterprise and
the ingress controller [jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress).
* [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for the [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/).
* [Istio](https://istio.io/) based ingress controller
[Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/).
* [Kong](https://konghq.com/) offers [community](https://discuss.konghq.com/c/kubernetes) or
@@ -44,6 +40,7 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i
[Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller).
* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the
[NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller).
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy
* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller
([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial
support by [Containous](https://containo.us/services).
content/en/docs/concepts/services-networking/ingress.md
+22 -22
View File
@@ -46,7 +46,7 @@ Traffic routing is controlled by rules defined on the Ingress resource.
[ Services ]
```
An Ingress can be configured to give services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.
An Ingress can be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.
An Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically
uses a service of type [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) or
@@ -56,14 +56,14 @@ uses a service of type [Service.Type=NodePort](/docs/concepts/services-networkin
You must have an [ingress controller](/docs/concepts/services-networking/ingress-controllers) to satisfy an Ingress. Only creating an Ingress resource has no effect.
You may need to deploy an ingress controller such as [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/). There are a number of
[ingress controllers](/docs/concepts/services-networking/ingress-controllers) you may choose from.
You may need to deploy an Ingress controller such as [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/). You can choose from a number of
[Ingress controllers](/docs/concepts/services-networking/ingress-controllers).
Ideally, all ingress controllers should fit the reference specification. In reality, the various ingress
Ideally, all Ingress controllers should fit the reference specification. In reality, the various Ingress
controllers operate slightly differently.
{{< note >}}
Make sure you review your ingress controller's documentation to understand the caveats of choosing it.
Make sure you review your Ingress controller's documentation to understand the caveats of choosing it.
{{< /note >}}
## The Ingress Resource
@@ -101,19 +101,19 @@ for directing HTTP traffic.
### Ingress rules
Each http rule contains the following information:
Each HTTP rule contains the following information:
* An optional host. In this example, no host is specified, so the rule applies to all inbound
HTTP traffic through the IP address specified. If a host is provided (for example,
foo.bar.com), the rules apply to that host.
* a list of paths (for example, `/testpath`), each of which has an associated backend defined with a `serviceName`
* A list of paths (for example, `/testpath`), each of which has an associated backend defined with a `serviceName`
and `servicePort`. Both the host and path must match the content of an incoming request before the
load balancer will direct traffic to the referenced service.
* A backend is a combination of service and port names as described in the
[services doc](/docs/concepts/services-networking/service/). HTTP (and HTTPS) requests to the
Ingress matching the host and path of the rule will be sent to the listed backend.
load balancer directs traffic to the referenced Service.
* A backend is a combination of Service and port names as described in the
[Service doc](/docs/concepts/services-networking/service/). HTTP (and HTTPS) requests to the
Ingress that matches the host and path of the rule are sent to the listed backend.
A default backend is often configured in an Ingress controller that will service any requests that do not
A default backend is often configured in an Ingress controller to service any requests that do not
match a path in the spec.
### Default Backend
@@ -151,12 +151,12 @@ this Ingress.
{{< note >}}
Ingress controllers and load balancers may take a minute or two to allocate an IP address.
Until that time you will often see the address listed as `<pending>`.
Until that time, you often see the address listed as `<pending>`.
{{< /note >}}
### Simple fanout
A fanout configuration routes traffic from a single IP address to more than one service,
A fanout configuration routes traffic from a single IP address to more than one Service,
based on the HTTP URI being requested. An Ingress allows you to keep the number of load balancers
down to a minimum. For example, a setup like:
@@ -189,7 +189,7 @@ spec:
servicePort: 8080
```
When you create the ingress with `kubectl apply -f`:
When you create the Ingress with `kubectl apply -f`:
```shell
kubectl describe ingress simple-fanout-example
@@ -215,7 +215,7 @@ Events:
```
The Ingress controller provisions an implementation-specific load balancer
that satisfies the Ingress, as long as the services (`s1`, `s2`) exist.
that satisfies the Ingress, as long as the Services (`s1`, `s2`) exist.
When it has done so, you can see the address of the load balancer at the
Address field.
@@ -299,11 +299,11 @@ spec:
You can secure an Ingress by specifying a {{< glossary_tooltip term_id="secret" >}}
that contains a TLS private key and certificate. Currently the Ingress only
supports a single TLS port, 443, and assumes TLS termination. If the TLS
configuration section in an Ingress specifies different hosts, they will be
configuration section in an Ingress specifies different hosts, they are
multiplexed on the same port according to the hostname specified through the
SNI TLS extension (provided the Ingress controller supports SNI). The TLS secret
must contain keys named `tls.crt` and `tls.key` that contain the certificate
and private key to use for TLS, e.g.:
and private key to use for TLS. For example:
```yaml
apiVersion: v1
@@ -317,7 +317,7 @@ data:
type: kubernetes.io/tls
```
Referencing this secret in an Ingress will tell the Ingress controller to
Referencing this secret in an Ingress tells the Ingress controller to
secure the channel from the client to the load balancer using TLS. You need to make
sure the TLS secret you created came from a certificate that contains a CN
for `sslexample.foo.com`.
@@ -397,7 +397,7 @@ Events:
kubectl edit ingress test
```
This should pop up an editor with the existing configuration in yaml format.
This pops up an editor with the existing configuration in YAML format.
Modify it to include the new Host:
```yaml
@@ -420,7 +420,7 @@ spec:
..
```
After you save your changes, kubectl will update the resource in the API server, which should tell the
After you save your changes, kubectl updates the resource in the API server, which tells the
Ingress controller to reconfigure the load balancer.
Verify this:
@@ -449,7 +449,7 @@ Events:
Normal ADD 45s loadbalancer-controller default/test
```
You can achieve the same outcome by invoking `kubectl replace -f` on a modified Ingress yaml file.
You can achieve the same outcome by invoking `kubectl replace -f` on a modified Ingress YAML file.
## Failing across availability zones
content/en/docs/concepts/services-networking/service.md
+163 -158
View File
@@ -5,7 +5,7 @@ title: Service
feature:
title: Service discovery and load balancing
description: >
No need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives pods their own IP addresses and a single DNS name for a set of pods, and can load-balance across them.
No need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them.
content_template: templates/concept
weight: 10
@@ -16,8 +16,8 @@ weight: 10
{{< glossary_definition term_id="service" length="short" >}}
No need to modify your application to use an unfamiliar service discovery mechanism.
Kubernetes gives pods their own IP addresses and a single DNS name for a set of pods,
With Kubernetes you don't need to modify your application to use an unfamiliar service discovery mechanism.
Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods,
and can load-balance across them.
{{% /capture %}}
@@ -26,18 +26,18 @@ and can load-balance across them.
## Motivation
Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}} are mortal.
Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}} are mortal.
They are born and when they die, they are not resurrected.
If you use a {{< glossary_tooltip term_id="deployment" >}} to run your app,
it can create and destroy Pods dynamically (e.g. when scaling out or in).
it can create and destroy Pods dynamically.
Each Pod gets its own IP address, however the set of Pods
for a Deployment running in one moment in time could be different from
Each Pod gets its own IP address, however in a Deployment, the set of Pods
running in one moment in time could be different from
the set of Pods running that application a moment later.
This leads to a problem: if some set of Pods (call them “backends”) provides
functionality to other Pods (call them “frontends”) inside your cluster,
how do those frontends find out and keep track of which IP address to connect
how do the frontends find out and keep track of which IP address to connect
to, so that the frontend can use the backend part of the workload?
Enter _Services_.
@@ -45,13 +45,13 @@ Enter _Services_.
## Service resources {#service-resource}
In Kubernetes, a Service is an abstraction which defines a logical set of Pods
and a policy by which to access them (you'll sometimes see this pattern called
and a policy by which to access them (sometimes this pattern is called
a micro-service). The set of Pods targeted by a Service is usually determined
by a {{< glossary_tooltip text="selector" term_id="selector" >}}
(see [below](#services-without-selectors) for why you might want a Service
_without_ a selector).
For example: consider a stateless image-processing backend which is running with
For example, consider a stateless image-processing backend which is running with
3 replicas. Those replicas are fungible&mdash;frontends do not care which backend
they use. While the actual Pods that compose the backend set may change, the
frontend clients should not need to be aware of that, nor should they need to keep
@@ -63,19 +63,19 @@ The Service abstraction enables this decoupling.
If you're able to use Kubernetes APIs for service discovery in your application,
you can query the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}
for Endpoints, that will be updated whenever the set of Pods in a Service changes.
for Endpoints, that get updated whenever the set of Pods in a Service changes.
For non-native applications, Kubernetes offers ways to place a network port or load
balancer in between your application and the backend Pods.
## Defining a service
## Defining a Service
A Service in Kubernetes is a REST object, similar to a Pod. Like all of the
REST objects, you can `POST` a Service definition to the API server to create
a new instance.
For example, suppose you have a set of Pods that each listen on TCP port 9376
and carry a label `"app=MyApp"`:
and carry a label `app=MyApp`:
```yaml
apiVersion: v1
@@ -86,37 +86,37 @@ spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
- protocol: TCP
port: 80
targetPort: 9376
```
This specification will create a new Service object named “my-service” which
targets TCP port 9376 on any Pod with the `"app=MyApp"` label.
This specification creates a new Service object named “my-service”, which
targets TCP port 9376 on any Pod with the `app=MyApp` label.
This Service will also be assigned an IP address (sometimes called the "cluster IP"),
which is used by the service proxies
Kubernetes assigns this Service an IP address (sometimes called the "cluster IP"),
which is used by the Service proxies
(see [Virtual IPs and service proxies](#virtual-ips-and-service-proxies) below).
The controller for the Service selector will continuously scan for Pods that
match its selector, and will then POST any updates to an Endpoint object
The controller for the Service selector continuously scans for Pods that
match its selector, and then POSTs any updates to an Endpoint object
also named “my-service”.
{{< note >}}
A Service can map _any_ incoming `port` to a `targetPort`. By default, and
for convenience, the `targetPort` will be set to the same value as the `port`
A Service can map _any_ incoming `port` to a `targetPort`. By default and
for convenience, the `targetPort` is set to the same value as the `port`
field.
{{< /note >}}
Port definitions in Pods have names, and you can reference these names in the
targetPort attribute of a Service. This will work even if there are a mixture
of Pods in the Service, with the same network protocol available via different
port numbers but a single configured name.
`targetPort` attribute of a Service. This works even if there is a mixture
of Pods in the Service using a single configured name, with the same network
protocol available via different port numbers.
This offers a lot of flexibility for deploying and evolving your Services.
For example, you can change the port number that pods expose in the next
For example, you can change the port numbers that Pods expose in the next
version of your backend software, without breaking clients.
The default protocol for services is TCP; you can also use any other
The default protocol for Services is TCP; you can also use any other
[supported protocol](#protocol-support).
As many Services need to expose more than one port, Kubernetes supports multiple
@@ -126,16 +126,17 @@ Each port definition can have the same `protocol`, or a different one.
### Services without selectors
Services most commonly abstract access to Kubernetes Pods, but they can also
abstract other kinds of backends. For example:
abstract other kinds of backends.
For example:
* You want to have an external database cluster in production, but in your
test environment you use your own databases.
* You want to point your service to a service in a different
* You want to point your Service to a Service in a different
{{< glossary_tooltip term_id="namespace" >}} or on another cluster.
* You are migrating a workload to Kubernetes. Whilst evaluating the approach,
you run only a proportion of your backends in Kubernetes.
In any of these scenarios you can define a service _without_ a Pod selector.
In any of these scenarios you can define a Service _without_ a Pod selector.
For example:
```yaml
@@ -145,13 +146,13 @@ metadata:
name: my-service
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376
- protocol: TCP
port: 80
targetPort: 9376
```
Because this service has no selector, the corresponding Endpoint object will *not* be
created automatically. You can manually map the service to the network address and port
Because this Service has no selector, the corresponding Endpoint object is *not*
created automatically. You can manually map the Service to the network address and port
where it's running, by adding an Endpoint object manually:
```yaml
@@ -170,16 +171,16 @@ subsets:
The endpoint IPs _must not_ be: loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), or
link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6).
Endpoint IP addresses also cannot be the cluster IPs of other Kubernetes services,
Endpoint IP addresses cannot be the cluster IPs of other Kubernetes Services,
because {{< glossary_tooltip term_id="kube-proxy" >}} doesn't support virtual IPs
as a destination.
{{< /note >}}
Accessing a Service without a selector works the same as if it had a selector.
In the example above, traffic will be routed to the single endpoint defined in
In the example above, traffic is routed to the single endpoint defined in
the YAML: `192.0.2.42:9376` (TCP).
An ExternalName Service is a special case of service that does not have
An ExternalName Service is a special case of Service that does not have
selectors and uses DNS names instead. For more information, see the
[ExternalName](#externalname) section later in this document.
@@ -219,7 +220,7 @@ Kubernetes v1.8 added ipvs proxy mode.
In this mode, kube-proxy watches the Kubernetes master for the addition and
removal of Service and Endpoint objects. For each Service it opens a
port (randomly chosen) on the local node. Any connections to this "proxy port"
will be proxied to one of the Service's backend Pods (as reported via
is proxied to one of the Service's backend Pods (as reported via
Endpoints). kube-proxy takes the `SessionAffinity` setting of the Service into
account when deciding which backend Pod to use.
@@ -235,19 +236,19 @@ By default, kube-proxy in userspace mode chooses a backend via a round-robin alg
In this mode, kube-proxy watches the Kubernetes control plane for the addition and
removal of Service and Endpoint objects. For each Service, it installs
iptables rules which capture traffic to the Service's `clusterIP` (which is
virtual) and `port` and redirects that traffic to one of the Service's
iptables rules, which capture traffic to the Service's `clusterIP` and `port`,
and redirect that traffic to one of the Service's
backend sets. For each Endpoint object, it installs iptables rules which
select a backend Pod.
By default, kube-proxy in iptables mode chooses a backend at random.
Using iptables to handle traffic has a lower system overhead, because traffic
is handled by Linux netfilter without the need switch between userspace and the
is handled by Linux netfilter without the need to switch between userspace and the
kernel space. This approach is also likely to be more reliable.
If kube-proxy is running in iptables mode and the first Pod that's selected
does not respond, the connection will fail. This is different from userspace
does not respond, the connection fails. This is different from userspace
mode: in that scenario, kube-proxy would detect that the connection to the first
Pod had failed and would automatically retry with a different backend Pod.
@@ -267,7 +268,7 @@ calls `netlink` interface to create IPVS rules accordingly and synchronizes
IPVS rules with Kubernetes Services and Endpoints periodically.
This control loop ensures that IPVS status matches the desired
state.
When accessing a Service, IPVS will direct traffic to one of the backend Pods.
When accessing a Service, IPVS directs traffic to one of the backend Pods.
The IPVS proxy mode is based on netfilter hook function that is similar to
iptables mode, but uses hash table as the underlying data structure and works
@@ -291,22 +292,22 @@ these are:
To run kube-proxy in IPVS mode, you must make the IPVS Linux available on
the node before you starting kube-proxy.
When kube-proxy starts in IPVS proxy mode, it will verify whether IPVS
kernel modules are available, and if those are not detected then kube-proxy
fall back to running in iptables proxy mode.
When kube-proxy starts in IPVS proxy mode, it verifies whether IPVS
kernel modules are available. If the IPVS kernel modules are not detected, then kube-proxy
falls back to running in iptables proxy mode.
{{< /note >}}
![Services overview diagram for IPVS proxy](/images/docs/services-ipvs-overview.svg)
In any of these proxy models, any traffic bound for the Service’s IP:Port is
In these proxy models, the traffic bound for the Service’s IP:Port is
proxied to an appropriate backend without the clients knowing anything
about Kubernetes or Services or Pods.
If you want to make sure that connections from a particular client
are passed to the same Pod each time, you can select session affinity based
are passed to the same Pod each time, you can select the session affinity based
the on client's IP addresses by setting `service.spec.sessionAffinity` to "ClientIP"
(the default is "None").
You can then also set the maximum session sticky time by setting
You can also set the maximum session sticky time by setting
`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` appropriately.
(the default value is 10800, which works out to be 3 hours).
@@ -315,7 +316,8 @@ You can then also set the maximum session sticky time by setting
For some Services, you need to expose more than one port.
Kubernetes lets you configure multiple port definitions on a Service object.
When using multiple ports for a Service, you must give all of your ports names
so that these are unambiguous. For example:
so that these are unambiguous.
For example:
```yaml
apiVersion: v1
@@ -326,14 +328,14 @@ spec:
selector:
app: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
- name: https
protocol: TCP
port: 443
targetPort: 9377
- name: http
protocol: TCP
port: 80
targetPort: 9376
- name: https
protocol: TCP
port: 443
targetPort: 9377
```
{{< note >}}
@@ -371,7 +373,7 @@ and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables,
where the Service name is upper-cased and dashes are converted to underscores.
For example, the Service `"redis-master"` which exposes TCP port 6379 and has been
allocated cluster IP address 10.0.0.11 produces the following environment
allocated cluster IP address 10.0.0.11, produces the following environment
variables:
```shell
@@ -385,7 +387,7 @@ REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
```
{{< note >}}
When you have a Pod that might need to acccess a Service, and you are using
When you have a Pod that needs to access a Service, and you are using
the environment variable method to publish the port and cluster IP to the client
Pods, you must create the Service *before* the client Pods come into existence.
Otherwise, those client Pods won't have their environment variables populated.
@@ -405,7 +407,7 @@ throughout your cluster then all Pods should automatically be able to resolve
Services by their DNS name.
For example, if you have a Service called `"my-service"` in a Kubernetes
Namespace `"my-ns"`, the control plane and the DNS service acting together will
Namespace `"my-ns"`, the control plane and the DNS Service acting together
create a DNS record for `"my-service.my-ns"`. Pods in the `"my-ns"` Namespace
should be able to find it by simply doing a name lookup for `my-service`
(`"my-service.my-ns"` would also work).
@@ -413,7 +415,7 @@ should be able to find it by simply doing a name lookup for `my-service`
Pods in other Namespaces must qualify the name as `my-service.my-ns`. These names
will resolve to the cluster IP assigned for the Service.
Kubernetes also supports DNS SRV (service) records for named ports. If the
Kubernetes also supports DNS SRV (Service) records for named ports. If the
`"my-service.my-ns"` Service has a port named `"http"` with protocol set to
`TCP`, you can do a DNS SRV query for `_http._tcp.my-service.my-ns` to discover
the port number for `"http"`, as well as the IP address.
@@ -422,86 +424,84 @@ The Kubernetes DNS server is the only way to access `ExternalName` Services.
You can find more information about `ExternalName` resolution in
[DNS Pods and Services](/docs/concepts/services-networking/dns-pod-service/).
## Headless services
## Headless Services
Sometimes you don't need or want load-balancing and a single service IP. In
Sometimes you don't need load-balancing and a single Service IP. In
this case, you can create what are termed “headless” Services, by explicitly
specifying `"None"` for the cluster IP (`.spec.clusterIP`).
You can use a headless Service to interface with other service discovery mechanisms,
without being tied to Kubernetes' implementation. For example, you could implement
a custom [Operator](
be built upon this API.
without being tied to Kubernetes' implementation.
For such `Services`, a cluster IP is not allocated, kube-proxy does not handle
these services, and there is no load balancing or proxying done by the platform
for them. How DNS is automatically configured depends on whether the service has
selectors defined.
For headless `Services`, a cluster IP is not allocated, kube-proxy does not handle
these Services, and there is no load balancing or proxying done by the platform
for them. How DNS is automatically configured depends on whether the Service has
selectors defined:
### With selectors
For headless services that define selectors, the endpoints controller creates
`Endpoints` records in the API, and modifies the DNS configuration to return A
For headless Services that define selectors, the endpoints controller creates
`Endpoints` records in the API, and modifies the DNS configuration to return
records (addresses) that point directly to the `Pods` backing the `Service`.
### Without selectors
For headless services that do not define selectors, the endpoints controller does
For headless Services that do not define selectors, the endpoints controller does
not create `Endpoints` records. However, the DNS system looks for and configures
either:
* CNAME records for [`ExternalName`](#externalname)-type services.
* A records for any `Endpoints` that share a name with the service, for all
* CNAME records for [`ExternalName`](#externalname)-type Services.
* A records for any `Endpoints` that share a name with the Service, for all
other types.
## Publishing services (ServiceTypes) {#publishing-services-service-types}
## Publishing Services (ServiceTypes) {#publishing-services-service-types}
For some parts of your application (e.g. frontends) you may want to expose a
Service onto an external IP address, one that's outside of your cluster.
For some parts of your application (for example, frontends) you may want to expose a
Service onto an external IP address, that's outside of your cluster.
Kubernetes `ServiceTypes` allow you to specify what kind of service you want.
Kubernetes `ServiceTypes` allow you to specify what kind of Service you want.
The default is `ClusterIP`.
`Type` values and their behaviors are:
* `ClusterIP`: Exposes the service on a cluster-internal IP. Choosing this value
makes the service only reachable from within the cluster. This is the
* `ClusterIP`: Exposes the Service on a cluster-internal IP. Choosing this value
makes the Service only reachable from within the cluster. This is the
default `ServiceType`.
* [`NodePort`](#nodeport): Exposes the service on each Node's IP at a static port
(the `NodePort`). A `ClusterIP` service, to which the `NodePort` service will
route, is automatically created. You'll be able to contact the `NodePort` service,
* [`NodePort`](#nodeport): Exposes the Service on each Node's IP at a static port
(the `NodePort`). A `ClusterIP` Service, to which the `NodePort` Service
routes, is automatically created. You'll be able to contact the `NodePort` Service,
from outside the cluster,
by requesting `<NodeIP>:<NodePort>`.
* [`LoadBalancer`](#loadbalancer): Exposes the service externally using a cloud
provider's load balancer. `NodePort` and `ClusterIP` services, to which the external
load balancer will route, are automatically created.
* [`ExternalName`](#externalname): Maps the service to the contents of the
* [`LoadBalancer`](#loadbalancer): Exposes the Service externally using a cloud
provider's load balancer. `NodePort` and `ClusterIP` Services, to which the external
load balancer routes, are automatically created.
* [`ExternalName`](#externalname): Maps the Service to the contents of the
`externalName` field (e.g. `foo.bar.example.com`), by returning a `CNAME` record
with its value. No proxying of any kind is set up.
{{< note >}}
You need CoreDNS version 1.7 or higher to use the `ExternalName` type.
{{< /note >}}
{{< note >}}
You need CoreDNS version 1.7 or higher to use the `ExternalName` type.
{{< /note >}}
You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expose your Service. Ingress is not a Service type, but it acts as the entry point for your cluster. It lets you consolidate your routing rules into a single resource as it can expose multiple services under the same IP address.
### Type NodePort {#nodeport}
If you set the `type` field to `NodePort`, the Kubernetes control plane will
allocate a port from a range specified by `--service-node-port-range` flag (default: 30000-32767).
Each node will proxy that port each (the same port number on every Node) into your Service.
Your service will report that allocated port in its `.spec.ports[*].nodePort` field.
If you set the `type` field to `NodePort`, the Kubernetes control plane
allocates a port from a range specified by `--service-node-port-range` flag (default: 30000-32767).
Each node proxies that port (the same port number on every Node) into your Service.
Your Service reports the allocated port in its `.spec.ports[*].nodePort` field.
If you want to specify particular IP(s) to proxy the port, you can set the `--nodeport-addresses` flag in kube-proxy to particular IP block(s); this is supported since Kubernetes v1.10.
This flag takes a comma-delimited list of IP blocks (e.g. 10.0.0.0/8, 192.0.2.0/25) to specify IP address ranges that kube-proxy should consider as local to this node.
For example, if you start kube-proxy with flag `--nodeport-addresses=127.0.0.0/8`, kube-proxy will select only the loopback interface for NodePort Services. The default for `--nodeport-addresses` is an empty list, and means that kube-proxy should consider all available network interfaces for NodePort. (That's also compatible with earlier Kubernetes releases).
For example, if you start kube-proxy with the `--nodeport-addresses=127.0.0.0/8` flag, kube-proxy only selects the loopback interface for NodePort Services. The default for `--nodeport-addresses` is an empty list. This means that kube-proxy should consider all available network interfaces for NodePort. (That's also compatible with earlier Kubernetes releases).
If you want a specific port number, you can specify a value in the `nodePort`
field. The control plane will either allocate you that port or report that
the API transaction failed.
This means that you need to take care about possible port collisions yourself).
This means that you need to take care about possible port collisions yourself.
You also have to use a valid port number, one that's inside the range configured
for NodePort use.
@@ -509,16 +509,17 @@ Using a NodePort gives you the freedom to set up your own load balancing solutio
to configure environments that are not fully supported by Kubernetes, or even
to just expose one or more nodes' IPs directly.
Note that this Service will be visible as both `<NodeIP>:spec.ports[*].nodePort`
Note that this Service is visible as `<NodeIP>:spec.ports[*].nodePort`
and `.spec.clusterIP:spec.ports[*].port`. (If the `--nodeport-addresses` flag in kube-proxy is set, <NodeIP> would be filtered NodeIP(s).)
### Type LoadBalancer {#loadbalancer}
On cloud providers which support external load balancers, setting the `type`
field to `LoadBalancer` will provision a load balancer for your Service.
field to `LoadBalancer` provisions a load balancer for your Service.
The actual creation of the load balancer happens asynchronously, and
information about the provisioned balancer will be published in the Service's
`.status.loadBalancer` field. For example:
information about the provisioned balancer is published in the Service's
`.status.loadBalancer` field.
For example:
```yaml
apiVersion: v1
@@ -529,26 +530,26 @@ spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
- protocol: TCP
port: 80
targetPort: 9376
clusterIP: 10.0.171.239
loadBalancerIP: 78.11.24.19
type: LoadBalancer
status:
loadBalancer:
ingress:
- ip: 146.148.47.155
- ip: 146.148.47.155
```
Traffic from the external load balancer will be directed at the backend Pods,
though exactly how that works depends on the cloud provider.
Traffic from the external load balancer is directed at the backend Pods. The cloud provider decides how it is load balanced.
Some cloud providers allow you to specify the `loadBalancerIP`. In those cases, the load-balancer will be created
Some cloud providers allow you to specify the `loadBalancerIP`. In those cases, the load-balancer is created
with the user-specified `loadBalancerIP`. If the `loadBalancerIP` field is not specified,
the loadBalancer will be set up with an ephemeral IP address. If you specify a `loadBalancerIP`
the loadBalancer is set up with an ephemeral IP address. If you specify a `loadBalancerIP`
but your cloud provider does not support the feature, the `loadbalancerIP` field that you
set will be ignored.
set is ignored.
{{< note >}}
If you're using SCTP, see the [caveat](#caveat-sctp-loadbalancer-service-type) below about the
@@ -567,13 +568,13 @@ Specify the assigned IP address as loadBalancerIP. Ensure that you have updated
{{< /note >}}
#### Internal load balancer
In a mixed environment it is sometimes necessary to route traffic from services inside the same
In a mixed environment it is sometimes necessary to route traffic from Services inside the same
(virtual) network address block.
In a split-horizon DNS environment you would need two services to be able to route both external and internal traffic to your endpoints.
In a split-horizon DNS environment you would need two Services to be able to route both external and internal traffic to your endpoints.
You can achieve this by adding one the following annotations to a Service.
The annotation to add depends on the cloud service provider you're using.
The annotation to add depends on the cloud Service provider you're using.
{{< tabs name="service_tabs" >}}
{{% tab name="Default" %}}
@@ -658,15 +659,15 @@ metadata:
```
The second annotation specifies which protocol a Pod speaks. For HTTPS and
SSL, the ELB will expect the Pod to authenticate itself over the encrypted
SSL, the ELB expects the Pod to authenticate itself over the encrypted
connection, using a certificate.
HTTP and HTTPS will select layer 7 proxying: the ELB will terminate
HTTP and HTTPS selects layer 7 proxying: the ELB terminates
the connection with the user, parse headers and inject the `X-Forwarded-For`
header with the user's IP address (Pods will only see the IP address of the
header with the user's IP address (Pods only see the IP address of the
ELB at the other end of its connection) when forwarding requests.
TCP and SSL will select layer 4 proxying: the ELB will forward traffic without
TCP and SSL selects layer 4 proxying: the ELB forwards traffic without
modifying the headers.
In a mixed-use environment where some ports are secured and others are left unencrypted,
@@ -680,12 +681,12 @@ you can use the following annotations:
service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443,8443"
```
In the above example, if the service contained three ports, `80`, `443`, and
In the above example, if the Service contained three ports, `80`, `443`, and
`8443`, then `443` and `8443` would use the SSL certificate, but `80` would just
be proxied HTTP.
From Kubernetes v1.9 onwrds you can use [predefined AWS SSL policies](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) with HTTPS or SSL listeners for your Services.
To see which policies are available for use, you can the `aws` command line tool:
To see which policies are available for use, you can use the `aws` command line tool:
```bash
aws elb describe-load-balancer-policies --query 'PolicyDescriptions[].PolicyName'
@@ -720,7 +721,7 @@ and cannot be configured otherwise.
#### ELB Access Logs on AWS
There are several annotations to manage access logs for ELB services on AWS.
There are several annotations to manage access logs for ELB Services on AWS.
The annotation `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`
controls whether access logs are enabled.
@@ -805,11 +806,15 @@ There are other annotations to manage Classic Elastic Load Balancers that are de
# A list of additional security groups to be added to the ELB
```
#### Network Load Balancer support on AWS
#### Network Load Balancer support on AWS [alpha] {#aws-nlb-support}
{{< feature-state for_k8s_version="v1.15" state="beta" >}}
{{< warning >}}
This is an alpha feature and is not yet recommended for production clusters.
{{< /warning >}}
To use a Network Load Balancer on AWS, use the annotation `service.beta.kubernetes.io/aws-load-balancer-type` with the value set to `nlb`.
Starting from Kubernetes v1.9.0, you can use AWS Network Load Balancer (NLB) with Services. To
use a Network Load Balancer on AWS, use the annotation `service.beta.kubernetes.io/aws-load-balancer-type`
with the value set to `nlb`.
```yaml
metadata:
@@ -824,13 +829,13 @@ on Elastic Load Balancing for a list of supported instance types.
{{< /note >}}
Unlike Classic Elastic Load Balancers, Network Load Balancers (NLBs) forward the
client's IP address through to the node. If a service's `.spec.externalTrafficPolicy`
is set to `Cluster`, the client's IP address will not be propagated to the end
pods.
client's IP address through to the node. If a Service's `.spec.externalTrafficPolicy`
is set to `Cluster`, the client's IP address is not propagated to the end
Pods.
By setting `.spec.externalTrafficPolicy` to `Local`, client IP addresses will be
propagated to the end pods, but this could result in uneven distribution of
traffic. Nodes without any pods for a particular LoadBalancer service will fail
By setting `.spec.externalTrafficPolicy` to `Local`, the client IP addresses is
propagated to the end Pods, but this could result in uneven distribution of
traffic. Nodes without any Pods for a particular LoadBalancer Service will fail
the NLB Target Group's health check on the auto-assigned
`.spec.healthCheckNodePort` and not receive any traffic.
@@ -856,12 +861,12 @@ specify `loadBalancerSourceRanges`.
```yaml
spec:
loadBalancerSourceRanges:
- "143.231.0.0/16"
- "143.231.0.0/16"
```
{{< note >}}
If `.spec.loadBalancerSourceRanges` is not set, Kubernetes will
allow traffic from `0.0.0.0/0` to the Node Security Group(s). If nodes have
If `.spec.loadBalancerSourceRanges` is not set, Kubernetes
allows traffic from `0.0.0.0/0` to the Node Security Group(s). If nodes have
public IP addresses, be aware that non-NLB traffic can also reach all instances
in those modified security groups.
@@ -869,8 +874,8 @@ in those modified security groups.
### Type ExternalName {#externalname}
Services of type ExternalName map a service to a DNS name, not to a typical selector such as
`my-service` or `cassandra`. You specify these services with the `spec.externalName` parameter.
Services of type ExternalName map a Service to a DNS name, not to a typical selector such as
`my-service` or `cassandra`. You specify these Services with the `spec.externalName` parameter.
This Service definition, for example, maps
the `my-service` Service in the `prod` namespace to `my.database.example.com`:
@@ -888,15 +893,15 @@ spec:
{{< note >}}
ExternalName accepts an IPv4 address string, but as a DNS names comprised of digits, not as an IP address. ExternalNames that resemble IPv4 addresses are not resolved by CoreDNS or ingress-nginx because ExternalName
is intended to specify a canonical DNS name. To hardcode an IP address, consider using
[headless services](#headless-services).
[headless Services](#headless-services).
{{< /note >}}
When looking up the host `my-service.prod.svc.cluster.local`, the cluster DNS service
will return a `CNAME` record with the value `my.database.example.com`. Accessing
When looking up the host `my-service.prod.svc.cluster.local`, the cluster DNS Service
returns a `CNAME` record with the value `my.database.example.com`. Accessing
`my-service` works in the same way as other Services but with the crucial
difference that redirection happens at the DNS level rather than via proxying or
forwarding. Should you later decide to move your database into your cluster, you
can start its pods, add appropriate selectors or endpoints, and change the
can start its Pods, add appropriate selectors or endpoints, and change the
Service's `type`.
@@ -907,9 +912,9 @@ This section is indebted to the [Kubernetes Tips - Part
### External IPs
If there are external IPs that route to one or more cluster nodes, Kubernetes services can be exposed on those
`externalIPs`. Traffic that ingresses into the cluster with the external IP (as destination IP), on the service port,
will be routed to one of the service endpoints. `externalIPs` are not managed by Kubernetes and are the responsibility
If there are external IPs that route to one or more cluster nodes, Kubernetes Services can be exposed on those
`externalIPs`. Traffic that ingresses into the cluster with the external IP (as destination IP), on the Service port,
will be routed to one of the Service endpoints. `externalIPs` are not managed by Kubernetes and are the responsibility
of the cluster administrator.
In the Service spec, `externalIPs` can be specified along with any of the `ServiceTypes`.
@@ -924,17 +929,17 @@ spec:
selector:
app: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
- name: http
protocol: TCP
port: 80
targetPort: 9376
externalIPs:
- 80.11.12.10
- 80.11.12.10
```
## Shortcomings
Using the userspace proxy for VIPs will work at small to medium scale, but will
Using the userspace proxy for VIPs, work at small to medium scale, but will
not scale to very large clusters with thousands of Services. The [original
design proposal for portals](http://issue.k8s.io/1107) has more details on
this.
@@ -969,7 +974,7 @@ In order to allow you to choose a port number for your Services, we must
ensure that no two Services can collide. Kubernetes does that by allocating each
Service its own IP address.
To ensure each service receives a unique IP, an internal allocator atomically
To ensure each Service receives a unique IP, an internal allocator atomically
updates a global allocation map in {{< glossary_tooltip term_id="etcd" >}}
prior to creating each Service. The map object must exist in the registry for
Services to get IP address assignments, otherwise creations will
@@ -1036,7 +1041,7 @@ through a load-balancer, though in those cases the client IP does get altered.
#### IPVS
iptables operations slow down dramatically in large scale cluster e.g 10,000 Services.
IPVS is designed for load balancing and based on in-kernel hash tables. So you can achieve performance consistency in large number of services from IPVS-based kube-proxy. Meanwhile, IPVS-based kube-proxy has more sophisticated load balancing algorithms (least conns, locality, weighted, persistence).
IPVS is designed for load balancing and based on in-kernel hash tables. So you can achieve performance consistency in large number of Services from IPVS-based kube-proxy. Meanwhile, IPVS-based kube-proxy has more sophisticated load balancing algorithms (least conns, locality, weighted, persistence).
## API Object
@@ -1049,13 +1054,13 @@ about the API object at: [Service API object](/docs/reference/generated/kubernet
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
You can use TCP for any kind of service, and it's the default network protocol.
You can use TCP for any kind of Service, and it's the default network protocol.
### UDP
{{< feature-state for_k8s_version="v1.0" state="stable" >}}
You can use UDP for most services. For type=LoadBalancer services, UDP support
You can use UDP for most Services. For type=LoadBalancer Services, UDP support
depends on the cloud provider offering this facility.
### HTTP
@@ -1068,7 +1073,7 @@ of the Service.
{{< note >}}
You can also use {{< glossary_tooltip term_id="ingress" >}} in place of Service
to expose HTTP / HTTPS services.
to expose HTTP / HTTPS Services.
{{< /note >}}
### PROXY protocol
content/en/docs/concepts/storage/persistent-volumes.md
+7 -4
View File
@@ -233,11 +233,14 @@ or is done when Pod is running and underlying file system supports online expans
FlexVolumes allow resize if the driver is set with the `RequiresFSResize` capability to true.
The FlexVolume can be resized on pod restart.
{{< feature-state for_k8s_version="v1.11" state="alpha" >}}
#### Resizing an in-use PersistentVolumeClaim
Expanding in-use PVCs is a beta feature and is enabled by default via `ExpandInUsePersistentVolumes` feature gate.
{{< feature-state for_k8s_version="v1.15" state="beta" >}}
{{< note >}}
Expanding in-use PVCs is available as beta since 1.15, and as alpha since Kubernetes 1.11. The `ExpandInUsePersistentVolumes` feature must be enabled, which is the case automatically for many clusters for beta features. Please refer to the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) documentation for more information.
{{< /note >}}
In this case, you don't need to delete and recreate a Pod or deployment that is using an existing PVC.
Any in-use PVC automatically becomes available to its Pod as soon as its file system has been expanded.
This feature has no effect on PVCs that are not in use by a Pod or deployment. You must create a Pod which
@@ -346,7 +349,7 @@ In the CLI, the access modes are abbreviated to:
| AzureDisk | &#x2713; | - | - |
| CephFS | &#x2713; | &#x2713; | &#x2713; |
| Cinder | &#x2713; | - | - |
| CSI | &depends on the driver | depends on the driver | depends on the driver |
| CSI | depends on the driver | depends on the driver | depends on the driver |
| FC | &#x2713; | &#x2713; | - |
| Flexvolume | &#x2713; | &#x2713; | depends on the driver |
| Flocker | &#x2713; | - | - |
content/en/docs/concepts/storage/volume-pvc-datasource.md
+5 -2
View File
@@ -52,8 +52,11 @@ metadata:
name: clone-of-pvc-1
namespace: myns
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
dataSource:
kind: PersistentVolumeClaim
name: pvc-1
content/en/docs/concepts/storage/volumes.md
+43 -6
View File
@@ -208,7 +208,7 @@ writers simultaneously.
You must have your own Ceph server running with the share exported before you can use it.
{{< /caution >}}
See the [CephFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/cephfs/) for more details.
See the [CephFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/) for more details.
### cinder {#cinder}
@@ -534,7 +534,7 @@ simultaneously.
You must have your own GlusterFS installation running before you can use it.
{{< /caution >}}
See the [GlusterFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/glusterfs) for more details.
See the [GlusterFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs) for more details.
### hostPath {#hostpath}
@@ -618,7 +618,7 @@ and then serve it in parallel from as many Pods as you need. Unfortunately,
iSCSI volumes can only be mounted by a single consumer in read-write mode - no
simultaneous writers allowed.
See the [iSCSI example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/iscsi) for more details.
See the [iSCSI example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) for more details.
### local {#local}
@@ -938,7 +938,7 @@ and then serve it in parallel from as many Pods as you need. Unfortunately,
RBD volumes can only be mounted by a single consumer in read-write mode - no
simultaneous writers allowed.
See the [RBD example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/rbd) for more details.
See the [RBD example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd) for more details.
### scaleIO {#scaleio}
@@ -1052,7 +1052,7 @@ spec:
```
For more information including Dynamic Provisioning and Persistent Volume Claims, please see the
[StorageOS examples](https://github.com/kubernetes/examples/blob/master/staging/volumes/storageos).
[StorageOS examples](https://github.com/kubernetes/examples/blob/master/volumes/storageos).
### vsphereVolume {#vspherevolume}
@@ -1313,6 +1313,43 @@ feature gates which must be enabled for this feature are `BlockVolume` and
Learn how to
[setup your PV/PVC with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
#### CSI ephemeral volumes
{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
This feature allows CSI volumes to be directly embedded in the Pod specification instead of a PersistentVolume. Volumes specified in this way are ephemeral and do not persist across Pod restarts.
Example:
```yaml
kind: Pod
apiVersion: v1
metadata:
name: my-csi-app
spec:
containers:
- name: my-frontend
image: busybox
volumeMounts:
- mountPath: "/data"
name: my-csi-inline-vol
command: [ "sleep", "1000000" ]
volumes:
- name: my-csi-inline-vol
csi:
driver: inline.storage.kubernetes.io
volumeAttributes:
foo: bar
```
This feature requires CSIInlineVolume feature gate to be enabled:
```
--feature-gates=CSIInlineVolume=true
```
CSI ephemeral volumes are only supported by a subset of CSI drivers. Please see the list of CSI drivers [here](https://kubernetes-csi.github.io/docs/drivers.html).
# Developer resources
For more information on how to develop a CSI driver, refer to the [kubernetes-csi
documentation](https://kubernetes-csi.github.io/docs/)
@@ -1342,7 +1379,7 @@ drivers. Flexvolume driver binaries must be installed in a pre-defined volume
plugin path on each node (and in some cases master).
Pods interact with Flexvolume drivers through the `flexvolume` in-tree plugin.
More details can be found [here](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md).
More details can be found [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md).
## Mount propagation
content/en/docs/concepts/workloads/controllers/deployment.md
+567 -528
View File
File diff suppressed because it is too large Load Diff
content/en/docs/concepts/workloads/controllers/garbage-collection.md
+1 -1
View File
@@ -93,7 +93,7 @@ collector deletes the object's dependents. Once the garbage collector has delete
the owner object.
Note that in the "foregroundDeletion", only dependents with
`ownerReference.blockOwnerDeletion` block the deletion of the owner object.
`ownerReference.blockOwnerDeletion=true` block the deletion of the owner object.
Kubernetes version 1.7 added an [admission controller](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement) that controls user access to set
`blockOwnerDeletion` to true based on delete permissions on the owner object, so that
unauthorized dependents cannot delay deletion of an owner object.
content/en/docs/concepts/workloads/controllers/replicationcontroller.md
+1 -1
View File
@@ -109,7 +109,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
```
Here, the selector is the same as the selector for the ReplicationController (seen in the
`kubectl describe` output, and in a different form in `replication.yaml`. The `--output=jsonpath` option
`kubectl describe` output), and in a different form in `replication.yaml`. The `--output=jsonpath` option
specifies an expression that just gets the name from each pod in the returned list.
content/en/docs/concepts/workloads/controllers/ttlafterfinished.md
+1 -1
View File
@@ -84,6 +84,6 @@ very small. Please be aware of this risk when setting a non-zero TTL.
[Clean up Jobs automatically](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
[Design doc](https://github.com/kubernetes/community/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
[Design doc](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
{{% /capture %}}
content/en/docs/concepts/workloads/pods/init-containers.md
+139 -141
View File
@@ -7,128 +7,103 @@ weight: 40
---
{{% capture overview %}}
This page provides an overview of Init Containers, which are specialized
Containers that run before app Containers and can contain utilities or setup
scripts not present in an app image.
This page provides an overview of init containers: specialized containers that run
before app containers in a {{< glossary_tooltip text="Pod" term_id="pod" >}}.
Init containers can contain utilities or setup scripts not present in an app image.
You can specify init containers in the Pod specification alongside the `containers`
array (which describes app containers).
{{% /capture %}}
This feature has exited beta in 1.6. Init Containers can be specified in the PodSpec
alongside the app `containers` array. The beta annotation value will still be respected
and overrides the PodSpec field value, however, they are deprecated in 1.6 and 1.7.
In 1.8, the annotations are no longer supported and must be converted to the PodSpec field.
{{% capture body %}}
## Understanding Init Containers
A [Pod](/docs/concepts/workloads/pods/pod-overview/) can have multiple Containers running
apps within it, but it can also have one or more Init Containers, which are run
before the app Containers are started.
## Understanding init containers
Init Containers are exactly like regular Containers, except:
A {{< glossary_tooltip text="Pod" term_id="pod" >}} can have multiple containers
running apps within it, but it can also have one or more init containers, which are run
before the app containers are started.
* They always run to completion.
* Each one must complete successfully before the next one is started.
Init containers are exactly like regular containers, except:
If an Init Container fails for a Pod, Kubernetes restarts the Pod repeatedly until the Init
Container succeeds. However, if the Pod has a `restartPolicy` of Never, it is not restarted.
* Init containers always run to completion.
* Each init container must complete successfully before the next one starts.
To specify a Container as an Init Container, add the `initContainers` field on the PodSpec as
a JSON array of objects of type
[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
If a Pod's init container fails, Kubernetes repeatedly restarts the Pod until the init container
succeeds. However, if the Pod has a `restartPolicy` of Never, Kubernetes does not restart the Pod.
To specify an init container for a Pod, add the `initContainers` field into
the Pod specification, as an array of objects of type
[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core),
alongside the app `containers` array.
The status of the init containers is returned in `.status.initContainerStatuses`
field as an array of the container statuses (similar to the `.status.containerStatuses`
field).
### Differences from regular Containers
### Differences from regular containers
Init Containers support all the fields and features of app Containers,
Init containers support all the fields and features of app containers,
including resource limits, volumes, and security settings. However, the
resource requests and limits for an Init Container are handled slightly
differently, which are documented in [Resources](#resources) below. Also, Init Containers do not
support readiness probes because they must run to completion before the Pod can
be ready.
resource requests and limits for an init container are handled differently,
as documented in [Resources](#resources).
If multiple Init Containers are specified for a Pod, those Containers are run
one at a time in sequential order. Each must succeed before the next can run.
When all of the Init Containers have run to completion, Kubernetes initializes
the Pod and runs the application Containers as usual.
Also, init containers do not support readiness probes because they must run to
completion before the Pod can be ready.
## What can Init Containers be used for?
If you specify multiple init containers for a Pod, Kubelet runs each init
container sequentially. Each init container must succeed before the next can run.
When all of the init containers have run to completion, Kubelet initializes
the application containers for the Pod and runs them as usual.
Because Init Containers have separate images from app Containers, they
## Using init containers
Because init containers have separate images from app containers, they
have some advantages for start-up related code:
* They can contain and run utilities that are not desirable to include in the
app Container image for security reasons.
* They can contain utilities or custom code for setup that is not present in an app
* Init containers can contain utilities or custom code for setup that are not present in an app
image. For example, there is no need to make an image `FROM` another image just to use a tool like
`sed`, `awk`, `python`, or `dig` during setup.
* Init containers can securely run utilities that would make an app container image less secure.
* The application image builder and deployer roles can work independently without
the need to jointly build a single app image.
* They use Linux namespaces so that they have different filesystem views from app Containers.
Consequently, they can be given access to Secrets that app Containers are not able to
access.
* They run to completion before any app Containers start, whereas app
Containers run in parallel, so Init Containers provide an easy way to block or
delay the startup of app Containers until some set of preconditions are met.
* Init containers can run with a different view of the filesystem than app containers in the
same Pod. Consequently, they can be given access to
{{< glossary_tooltip text="Secrets" term_id="secret" >}} that app containers cannot access.
* Because init containers run to completion before any app containers start, init containers offer
a mechanism to block or delay app container startup until a set of preconditions are met. Once
preconditions are met, all of the app containers in a Pod can start in parallel.
### Examples
Here are some ideas for how to use Init Containers:
Here are some ideas for how to use init containers:
* Wait for a service to be created with a shell command like:
for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
* Wait for a {{< glossary_tooltip text="Service" term_id="service">}} to
be created, using a shell one-line command like:
```shell
for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
```
* Register this Pod with a remote server from the downward API with a command like:
```shell
curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
```
`curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'`
* Wait for some time before starting the app container with a command like
```shell
sleep 60
```
* Clone a Git repository into a {{< glossary_tooltip text="Volume" term_id="volume" >}}
* Wait for some time before starting the app Container with a command like `sleep 60`.
* Clone a git repository into a volume.
* Place values into a configuration file and run a template tool to dynamically
generate a configuration file for the main app Container. For example,
place the POD_IP value in a configuration and generate the main app
generate a configuration file for the main app container. For example,
place the `POD_IP` value in a configuration and generate the main app
configuration file using Jinja.
More detailed usage examples can be found in the [StatefulSets documentation](/docs/concepts/workloads/controllers/statefulset/)
and the [Production Pods guide](/docs/tasks/configure-pod-container/configure-pod-initialization/).
#### Init containers in use
### Init Containers in use
The following yaml file for Kubernetes 1.5 outlines a simple Pod which has two Init Containers.
The first waits for `myservice` and the second waits for `mydb`. Once both
containers complete, the Pod will begin.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
annotations:
pod.beta.kubernetes.io/init-containers: '[
{
"name": "init-myservice",
"image": "busybox:1.28",
"command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"]
},
{
"name": "init-mydb",
"image": "busybox:1.28",
"command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"]
}
]'
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
```
There is a new syntax in Kubernetes 1.6, although the old annotation syntax still works for 1.6 and 1.7. The new syntax must be used for 1.8 or greater. We have moved the declaration of Init Containers to `spec`:
This example defines a simple Pod that has two init containers.
The first waits for `myservice`, and the second waits for `mydb`. Once both
init containers complete, the Pod runs the app container from its `spec` section.
```yaml
apiVersion: v1
@@ -151,9 +126,8 @@ spec:
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
```
1.5 syntax still works on 1.6, but we recommend using 1.6 syntax. In Kubernetes 1.6, Init Containers were made a field in the API. The beta annotation is still respected in 1.6 and 1.7, but is not supported in 1.8 or greater.
Yaml file below outlines the `mydb` and `myservice` services:
The following YAML file outlines the `mydb` and `myservice` services:
```yaml
apiVersion: v1
@@ -177,7 +151,7 @@ spec:
targetPort: 9377
```
This Pod can be started and debugged with the following commands:
You can start this Pod by running:
```shell
kubectl apply -f myapp.yaml
@@ -186,6 +160,7 @@ kubectl apply -f myapp.yaml
pod/myapp-pod created
```
And check on its status with:
```shell
kubectl get -f myapp.yaml
```
@@ -194,6 +169,7 @@ NAME READY STATUS RESTARTS AGE
myapp-pod 0/1 Init:0/2 0 6m
```
or for more details:
```shell
kubectl describe -f myapp.yaml
```
@@ -231,13 +207,42 @@ Events:
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634
```
To see logs for the init containers in this Pod, run:
```shell
kubectl logs myapp-pod -c init-myservice # Inspect the first init container
kubectl logs myapp-pod -c init-mydb # Inspect the second init container
```
Once we start the `mydb` and `myservice` services, we can see the Init Containers
complete and the `myapp-pod` is created:
At this point, those init containers will be waiting to discover Services named
`mydb` and `myservice`.
Here's a configuration you can use to make those Services appear:
```yaml
---
apiVersion: v1
kind: Service
metadata:
name: myservice
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
name: mydb
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9377
```
To create the `mydb` and `myservice` services:
```shell
kubectl apply -f services.yaml
@@ -247,104 +252,97 @@ service/myservice created
service/mydb created
```
You'll then see that those init containers complete, and that the `myapp-pod`
Pod moves into the Running state:
```shell
kubectl get -f myapp.yaml
```
```
NAME READY STATUS RESTARTS AGE
myapp-pod 1/1 Running 0 9m
```
This example is very simple but should provide some inspiration for you to
create your own Init Containers.
This simple example should provide some inspiration for you to create your own
init containers. [What's next](#what-s-next) contains a link to a more detailed example.
## Detailed behavior
During the startup of a Pod, the Init Containers are started in order, after the
network and volumes are initialized. Each Container must exit successfully before
the next is started. If a Container fails to start due to the runtime or
During the startup of a Pod, each init container starts in order, after the
network and volumes are initialized. Each container must exit successfully before
the next container starts. If a container fails to start due to the runtime or
exits with failure, it is retried according to the Pod `restartPolicy`. However,
if the Pod `restartPolicy` is set to Always, the Init Containers use
`RestartPolicy` OnFailure.
if the Pod `restartPolicy` is set to Always, the init containers use
`restartPolicy` OnFailure.
A Pod cannot be `Ready` until all Init Containers have succeeded. The ports on an
Init Container are not aggregated under a service. A Pod that is initializing
A Pod cannot be `Ready` until all init containers have succeeded. The ports on an
init container are not aggregated under a Service. A Pod that is initializing
is in the `Pending` state but should have a condition `Initializing` set to true.
If the Pod is [restarted](#pod-restart-reasons), all Init Containers must
execute again.
If the Pod [restarts](#pod-restart-reasons), or is restarted, all init containers
must execute again.
Changes to the Init Container spec are limited to the container image field.
Altering an Init Container image field is equivalent to restarting the Pod.
Changes to the init container spec are limited to the container image field.
Altering an init container image field is equivalent to restarting the Pod.
Because Init Containers can be restarted, retried, or re-executed, Init Container
Because init containers can be restarted, retried, or re-executed, init container
code should be idempotent. In particular, code that writes to files on `EmptyDirs`
should be prepared for the possibility that an output file already exists.
Init Containers have all of the fields of an app Container. However, Kubernetes
prohibits `readinessProbe` from being used because Init Containers cannot
Init containers have all of the fields of an app container. However, Kubernetes
prohibits `readinessProbe` from being used because init containers cannot
define readiness distinct from completion. This is enforced during validation.
Use `activeDeadlineSeconds` on the Pod and `livenessProbe` on the Container to
prevent Init Containers from failing forever. The active deadline includes Init
Containers.
Use `activeDeadlineSeconds` on the Pod and `livenessProbe` on the container to
prevent init containers from failing forever. The active deadline includes init
containers.
The name of each app and Init Container in a Pod must be unique; a
validation error is thrown for any Container sharing a name with another.
The name of each app and init container in a Pod must be unique; a
validation error is thrown for any container sharing a name with another.
### Resources
Given the ordering and execution for Init Containers, the following rules
Given the ordering and execution for init containers, the following rules
for resource usage apply:
* The highest of any particular resource request or limit defined on all Init
Containers is the *effective init request/limit*
* The highest of any particular resource request or limit defined on all init
containers is the *effective init request/limit*
* The Pod's *effective request/limit* for a resource is the higher of:
* the sum of all app Containers request/limit for a resource
* the sum of all app containers request/limit for a resource
* the effective init request/limit for a resource
* Scheduling is done based on effective requests/limits, which means
Init Containers can reserve resources for initialization that are not used
init containers can reserve resources for initialization that are not used
during the life of the Pod.
* QoS tier of the Pod's *effective QoS tier* is the QoS tier for Init Containers
and app containers alike.
* The QoS (quality of service) tier of the Pod's *effective QoS tier* is the
QoS tier for init containers and app containers alike.
Quota and limits are applied based on the effective Pod request and
limit.
Pod level cgroups are based on the effective Pod request and limit, the
same as the scheduler.
Pod level control groups (cgroups) are based on the effective Pod request and
limit, the same as the scheduler.
### Pod restart reasons
A Pod can restart, causing re-execution of Init Containers, for the following
A Pod can restart, causing re-execution of init containers, for the following
reasons:
* A user updates the PodSpec causing the Init Container image to change. Any
changes to the Init Container image restarts the Pod. App Container image
changes only restart the app Container.
* A user updates the Pod specification, causing the init container image to change.
Any changes to the init container image restarts the Pod. App container image
changes only restart the app container.
* The Pod infrastructure container is restarted. This is uncommon and would
have to be done by someone with root access to nodes.
* All containers in a Pod are terminated while `restartPolicy` is set to Always,
forcing a restart, and the Init Container completion record has been lost due
forcing a restart, and the init container completion record has been lost due
to garbage collection.
## Support and compatibility
A cluster with Apiserver version 1.6.0 or greater supports Init Containers
using the `.spec.initContainers` field. Previous versions support Init Containers
using the alpha or beta annotations. The `.spec.initContainers` field is also mirrored
into alpha and beta annotations so that Kubelets version 1.3.0 or greater can execute
Init Containers, and so that a version 1.6 apiserver can safely be rolled back to version
1.5.x without losing Init Container functionality for existing created pods.
In Apiserver and Kubelet versions 1.8.0 or greater, support for the alpha and beta annotations
is removed, requiring a conversion from the deprecated annotations to the
`.spec.initContainers` field.
{{% /capture %}}
{{% capture whatsnext %}}
* [Creating a Pod that has an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
* Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
* Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
{{% /capture %}}
content/en/docs/concepts/workloads/pods/pod-overview.md
+1 -1
View File
@@ -21,7 +21,7 @@ A *Pod* is the basic execution unit of a Kubernetes application--the smallest an
A Pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network IP, and options that govern how the container(s) should run. A Pod represents a unit of deployment: *a single instance of an application in Kubernetes*, which might consist of either a single {{< glossary_tooltip text="container" term_id="container" >}} or a small number of containers that are tightly coupled and that share resources.
[Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other container runtimes as well.
[Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other [container runtimes](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) as well.
Pods in a Kubernetes cluster can be used in two main ways:
content/en/docs/concepts/workloads/pods/pod.md
+1 -1
View File
@@ -186,7 +186,7 @@ You must specify an additional flag `--force` along with `--grace-period=0` in o
### Force deletion of pods
Force deletion of a Pod is defined as deletion of a Pod from the cluster state and etcd immediately. When a force deletion is performed, the apiserver does not wait for confirmation from the kubelet that the Pod has been terminated on the node it was running on. It removes the Pod in the API immediately so a new Pod can be created with the same name. On the node, Pods that are set to terminate immediately will still be given a small grace period before being force killed.
Force deletion of a Pod is defined as deletion of a Pod from the cluster state and etcd immediately. When a force deletion is performed, the API server does not wait for confirmation from the kubelet that the Pod has been terminated on the node it was running on. It removes the Pod in the API immediately so a new Pod can be created with the same name. On the node, Pods that are set to terminate immediately will still be given a small grace period before being force killed.
Force deletions can be potentially dangerous for some Pods and should be performed with caution. In case of StatefulSet Pods, please refer to the task documentation for [deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
content/en/docs/concepts/workloads/pods/podpreset.md
+5 -1
View File
@@ -74,7 +74,11 @@ In order to use Pod Presets in your cluster you must ensure the following:
1. You have enabled the admission controller `PodPreset`. One way to doing this
is to include `PodPreset` in the `--enable-admission-plugins` option value specified
for the API server. In minikube add this flag
`--extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset`
```shell
--extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
```
while starting the cluster.
1. You have defined your Pod Presets by creating `PodPreset` objects in the
namespace you will use.
content/en/docs/contribute/advanced.md
+21 -4
View File
@@ -29,8 +29,6 @@ The PR wrangler’s duties include:
- Ensure that the CLA is signed by each contributor.
- Help new contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md).
- Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to automatically remind contributors that haven’t signed the CLA to sign the CLA.
- Close any PR where the CLA hasn’t been signed for two weeks.
PR authors can reopen the PR after signing the CLA, so this is a low-risk way to make sure nothing gets merged without a signed CLA.
- Provide feedback on proposed changes and help facilitate technical reviews from members of other SIGs.
- Provide inline suggestions on the PR for the proposed content changes.
- If you need to verify content, comment on the PR and request more details.
@@ -59,6 +57,25 @@ reviewed is usually small. These queries specifically exclude localization PRs,
Determine whether any additional changes or updates need to be made for the PR to be merged. If you think the PR is ready to be merged, comment `/approve`.
- [Not against master](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If it's against a `dev-` branch, it's for an upcoming release. Make sure the [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) knows about it by adding a comment with `/assign @<meister's_github-username>`. If it's against an old branch, help the PR author figure out whether it's targeted against the best branch.
### When to close Pull Requests
Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure.
- Close any PR where the CLA hasn’t been signed for two weeks.
PR authors can reopen the PR after signing the CLA, so this is a low-risk way to make sure nothing gets merged without a signed CLA.
- Close any PR where the author has not responded to comments or feedback in 2 or more weeks.
Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Oftentimes a closure notice is what spurs an author to resume and finish their contribution.
To close a pull request, leave a `/close` comment on the PR.
{{< note >}}
An automated service, [`fejta-bot`](https://github.com/fejta-bot) automatically marks issues as stale after 90 days of inactivity, then closes them after an additional 30 days of inactivity when they become rotten. PR wranglers should close issues after 14-30 days of inactivity.
{{< /note >}}
## Propose improvements
SIG Docs
@@ -176,7 +193,7 @@ Responsibilities include:
- Learn and set best practices for the SIG by updating contribution guidelines
- Schedule and run SIG meetings: weekly status updates, quarterly retro/planning sessions, and others as needed
- Schedule and run doc sprints at KubeCon events and other conferences
- - Recruit for and advocate on behalf of SIG Docs with the CNCF and its platinum partners, including Google, Oracle, Azure, IBM, and Huawei
- Recruit for and advocate on behalf of SIG Docs with the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} and its platinum partners, including Google, Oracle, Azure, IBM, and Huawei
- Keep the SIG running smoothly
### Running effective meetings
@@ -190,7 +207,7 @@ To schedule and run effective meetings, these guidelines show what to do, how to
**Set a clear agenda**:
- Set a clear agenda of topics
- Publish the agenda in advance
- Publish the agenda in advance
For weekly meetings, copypaste the previous week's notes into the "Past meetings" section of the notes
content/en/docs/contribute/generate-ref-docs/kubectl.md
+121 -97
View File
@@ -48,64 +48,80 @@ information, see
{{% capture steps %}}
## Getting three repositories
## Setting up the local repositories
If you don't already have the kubernetes/kubernetes repository, get it now:
Create a local workspace and set your `GOPATH`.
```shell
mkdir $GOPATH/src
cd $GOPATH/src
go get github.com/kubernetes/kubernetes
mkdir -p $HOME/<workspace>
export GOPATH=$HOME/<workspace>
```
Determine the base directory of your clone of the
[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repository.
For example, if you followed the preceding step to get the repository, your
base directory is `$GOPATH/src/github.com/kubernetes/kubernetes.`
The remaining steps refer to your base directory as `<k8s-base>`.
Get a local clone of the following repositories:
```shell
go get -u github.com/spf13/pflag
go get -u github.com/spf13/cobra
go get -u gopkg.in/yaml.v2
go get -u kubernetes-incubator/reference-docs
```
If you don't already have the kubernetes/website repository, get it now:
```shell
mkdir $GOPATH/src
cd $GOPATH/src
go get github.com/kubernetes/website
git clone https://github.com/<your-username>/website $GOPATH/src/github.com/<your-username>/website
```
Determine the base directory of your clone of the
[kubernetes/website](https://github.com/kubernetes/website) repository.
For example, if you followed the preceding step to get the repository, your
base directory is `$GOPATH/src/github.com/kubernetes/website.`
The remaining steps refer to your base directory as `<web-base>`.
If you don't already have the kubernetes-incubator/reference-docs repository, get it now:
Get a clone of the kubernetes/kubernetes repository as k8s.io/kubernetes:
```shell
mkdir $GOPATH/src
cd $GOPATH/src
go get github.com/kubernetes-incubator/reference-docs
git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes
```
Determine the base directory of your clone of the
Remove the spf13 package from `$GOPATH/src/k8s.io/kubernetes/vendor/github.com`.
```shell
rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/github.com/spf13
```
The kubernetes/kubernetes repository provides access to the kubectl and kustomize source code.
* Determine the base directory of your clone of the
[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repository.
For example, if you followed the preceding step to get the repository, your
base directory is `$GOPATH/src/k8s.io/kubernetes.`
The remaining steps refer to your base directory as `<k8s-base>`.
* Determine the base directory of your clone of the
[kubernetes/website](https://github.com/kubernetes/website) repository.
For example, if you followed the preceding step to get the repository, your
base directory is `$GOPATH/src/github.com/<your-username>/website.`
The remaining steps refer to your base directory as `<web-base>`.
* Determine the base directory of your clone of the
[kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) repository.
For example, if you followed the preceding step to get the repository, your
base directory is `$GOPATH/src/github.com/kubernetes-incubator/reference-docs.`
The remaining steps refer to your base directory as `<rdocs-base>`.
In your local kubernetes/kubernetes repository, check out the branch of interest,
In your local k8s.io/kubernetes repository, check out the branch of interest,
and make sure it is up to date. For example, if you want to generate docs for
Kubernetes 1.9, you could use these commands:
Kubernetes 1.15, you could use these commands:
```shell
cd <k8s-base>
git checkout release-1.9
git pull https://github.com/kubernetes/kubernetes release-1.9
git checkout release-1.15
git pull https://github.com/kubernetes/kubernetes release-1.15
```
If you do not need to edit the kubectl source code, follow the instructions to [Edit the Makefile](#editing-makefile).
## Editing the kubectl source code
The reference documentation for the kubectl commands is automatically generated from
kubectl source code. If you want to change the reference documentation, the first step
The kubectl command reference documentation is automatically generated from
the kubectl source code. If you want to change the reference documentation, the first step
is to change one or more comments in the kubectl source code. Make the change in your
local kubernetes/kubernetes repository, and then submit a pull request to the master branch of
[github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes).
@@ -124,7 +140,7 @@ version that has already been released, you need to propose that your change be
cherry picked into the release branch.
For example, suppose the master branch is being used to develop Kubernetes 1.10,
and you want to backport your change to the release-1.9 branch. For instructions
and you want to backport your change to the release-1.15 branch. For instructions
on how to do this, see
[Propose a Cherry Pick](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md).
@@ -138,104 +154,115 @@ need to work with someone who can set the label and milestone for you.
## Editing Makefile
Go to `<rdocs-base>`, and open `Makefile` for editing:
Go to `<rdocs-base>`, and open the `Makefile` for editing:
Set `K8SROOT` to the base directory of your local kubernetes/kubernetes
repository. Set `WEBROOT` to the base directory of your local kubernetes/website repository.
Set `MINOR_VERSION` to the minor version of the docs you want to build. For example,
if you want to build docs for Kubernetes 1.9, set `MINOR_VERSION` to 9. Save and close `Makefile`.
* Set `K8SROOT` to `<k8s-base>`.
* Set `WEBROOT` to `<web-base>`.
* Set `MINOR_VERSION` to the minor version of the docs you want to build. For example,
if you want to build docs for Kubernetes 1.15, set `MINOR_VERSION` to 15. Save and close the `Makefile`.
## Building the brodocs image
For example, update the following variables:
The doc generation code requires the `pwittrock/brodocs` Docker image.
This command creates the `pwittrock/brodocs` Docker image. It also tries to push the image to
DockerHub, but it's OK if that step fails. As long as you have the image locally, the code generation
can succeed.
```shell
make brodocs
```
Verify that you have the brodocs image:
```shell
docker images
```
The output shows `pwittrock/brodocs` as one of the available images:
```shell
REPOSITORY TAG IMAGE ID CREATED SIZE
pwittrock/brodocs latest 999d34a50d56 5 weeks ago 714MB
WEBROOT=$(GOPATH)/src/github.com/<your-username>/website
K8SROOT=$(GOPATH)/src/k8s.io/kubernetes
MINOR_VERSION=15
```
## Creating a version directory
In the `gen-kubectldocs/generators` directory, if you do not already
have a directory named `v1_MINOR_VERSION`, create one now by copying the directory
The version directory is a staging area for the kubectl command reference build.
The YAML files in this directory are used to create the structure and navigation
of the kubectl command reference.
In the `<rdocs-base>/gen-kubectldocs/generators` directory, if you do not already
have a directory named `v1_<MINOR_VERSION>`, create one now by copying the directory
for the previous version. For example, suppose you want to generate docs for
Kubernetes 1.9, but you don't already have a `v1_9` directory. Then you could
create and populate a `v1_9` directory by running these commands:
Kubernetes 1.15, but you don't already have a `v1_15` directory. Then you could
create and populate a `v1_15` directory by running these commands:
```shell
mkdir gen-kubectldocs/generators/v1_9
cp -r gen-kubectldocs/generators/v1_8/* gen-kubectldocs/generators/v1_9
mkdir gen-kubectldocs/generators/v1_15
cp -r gen-kubectldocs/generators/v1_14/* gen-kubectldocs/generators/v1_15
```
## Checking out a branch in kubernetes/kubernetes
## Checking out a branch in k8s.io/kubernetes
In you local kubernetes/kubernetes repository, checkout the branch that has
In your local <k8s-base> repository, checkout the branch that has
the version of Kubernetes that you want to document. For example, if you want
to generate docs for Kubernetes 1.9, checkout the release-1.9 branch. Make sure
to generate docs for Kubernetes 1.15, checkout the release-1.15 branch. Make sure
you local branch is up to date.
```shell
cd <k8s-base>
git checkout release-1.15
git pull https://github.com/kubernetes/kubernetes release-1.15
```
## Running the doc generation code
In you local kubernetes-incubator/reference-docs repository, build and run the
doc generation code. You might need to run the command as root:
```shell
cd <rdocs-base>
make cli
```
## Locate the generated files
These two files are the primary output of a successful build. Verify that they exist:
* `<rdocs-base>/gen-kubectldocs/generators/build/index.html`
* `<rdocs-base>/gen-kubectldocs/generators/build/navData.js`
## Copying files to the kubernetes/website repository
Copy the generated files from your local kubernetes-incubator/reference-docs
repository to your local kubernetes/website repository.
In your local kubernetes-incubator/reference-docs repository, build and run the
kubectl command reference generation code. You might need to run the command as root:
```shell
cd <rdocs-base>
make copycli
```
## Adding and committing changes in kubernetes/website
The `copycli` command will clean the staging directories, generate the kubectl command files,
and copy the collated kubectl reference HTML page and assets to `<web-base>`.
List the files that were generated and copied to the `kubernetes/website`
repository:
## Locate the generated files
Verify that these two files have been generated:
```shell
[ -e "<rdocs-base>/gen-kubectldocs/generators/build/index.html" ] && echo "index.html built" || echo "no index.html"
[ -e "<rdocs-base>/gen-kubectldocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js"
```
## Locate the copied files
Verify that all generated files have been copied to your `<web-base>`:
```shell
cd <web-base>
git status
```
The output shows the new and modified files. For example, the output
might look like this:
The output should include the modified files:
```
static/docs/reference/generated/kubectl/kubectl-commands.html
static/docs/reference/generated/kubectl/navData.js
```
Additionally, the output might show the modified files:
```
static/docs/reference/generated/kubectl/scroll.js
static/docs/reference/generated/kubectl/stylesheet.css
static/docs/reference/generated/kubectl/tabvisibility.js
static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css
static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css
static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js
static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js
static/docs/reference/generated/kubectl/node_modules/font-awesome/css/font-awesome.min.css
```
## Locally test the documentation
Build the Kubernetes documentation in your local `<web-base>`.
```shell
modified: docs/reference/generated/kubectl/kubectl-commands.html
modified: docs/reference/generated/kubectl/navData.js
cd <web-base>
make docker-serve
```
View the [local preview](https://localhost:1313/docs/reference/generated/kubectl/kubectl-commands/).
## Adding and committing changes in kubernetes/website
Run `git add` and `git commit` to commit the files.
## Creating a pull request
@@ -257,7 +284,4 @@ topics will be visible in the
* [Generating Reference Documentation for the Kubernetes API](/docs/home/contribute/generated-reference/kubernetes-api/)
* [Generating Reference Documentation for the Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/)
{{% /capture %}}
{{% /capture %}}
content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
+119 -97
View File
@@ -5,8 +5,16 @@ content_template: templates/task
{{% capture overview %}}
This page shows how to update the generated reference docs for the
Kubernetes API.
This page shows how to update the generated reference docs for the Kubernetes API.
The Kubernetes API reference documentation is built from the
[Kubernetes OpenAPI spec](https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/swagger.json)
and tools from [kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs).
If you find bugs in the generated documentation, you need to
[fix them upstream](/docs/contribute/generate-ref-docs/contribute-upstream/).
If you need only to regenerate the reference documentation from the [OpenAPI](https://github.com/OAI/OpenAPI-Specification)
spec, continue reading this page.
{{% /capture %}}
@@ -18,8 +26,6 @@ You need to have these tools installed:
* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
* [Golang](https://golang.org/doc/install) version 1.9.1 or later
Your $GOPATH environment variable must be set.
You need to know how to create a pull request (PR) to a GitHub repository.
Typically, this involves creating a fork of the repository. For more
information, see
@@ -31,96 +37,78 @@ information, see
{{% capture steps %}}
## The big picture
## Setting up the local repositories
The reference documentation for the Kubernetes API is generated in two separate stages:
1. Generate an OpenAPI spec from the Kubernetes source code. The tools for
this stage are at [kubernetes/kubernetes/hack](https://github.com/kubernetes/kubernetes/tree/master/hack).
1. Generate an HTML file from the OpenAPI spec. The tools for this stage are at
[kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs).
If you find bugs in the generated documentation generated, you need to
[fix them upstream](/docs/contribute/generate-ref-docs/contribute-upstream/).
If you need only to regenerate the reference documentation from the OpenAPI
spec, continue reading this page.
## Getting three repositories
If you don't already have the kubernetes/kubernetes repository, get it now:
Create a local workspace and set your `GOPATH`.
```shell
mkdir $GOPATH/src
cd $GOPATH/src
go get github.com/kubernetes/kubernetes
mkdir -p $HOME/<workspace>
export GOPATH=$HOME/<workspace>
```
Determine the base directory of your clone of the
[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repository.
For example, if you followed the preceding step to get the repository, your
base directory is `$GOPATH/src/github.com/kubernetes/kubernetes.`
The remaining steps refer to your base directory as `<k8s-base>`.
Get a local clone of the following repositories:
```shell
go get -u github.com/kubernetes-incubator/reference-docs
go get -u github.com/go-openapi/loads
go get -u github.com/go-openapi/spec
```
If you don't already have the kubernetes/website repository, get it now:
```shell
mkdir $GOPATH/src
cd $GOPATH/src
go get github.com/kubernetes/website
git clone https://github.com/<your-username>/website $GOPATH/src/github.com/<your-username>/website
```
Determine the base directory of your clone of the
[kubernetes/website](https://github.com/kubernetes/website) repository.
For example, if you followed the preceding step to get the repository, your
base directory is `$GOPATH/src/github.com/kubernetes/website.`
The remaining steps refer to your base directory as `<web-base>`.
If you don't already have the kubernetes-incubator/reference-docs repository, get it now:
Get a clone of the kubernetes/kubernetes repository as k8s.io/kubernetes:
```shell
mkdir $GOPATH/src
cd $GOPATH/src
go get github.com/kubernetes-incubator/reference-docs
git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes
```
Determine the base directory of your clone of the
[kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs) repository.
For example, if you followed the preceding step to get the repository, your
base directory is `$GOPATH/src/github.com/kubernetes-incubator/reference-docs.`
* The base directory of your clone of the
[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repository is
`$GOPATH/src/k8s.io/kubernetes.`
The remaining steps refer to your base directory as `<k8s-base>`.
* The base directory of your clone of the
[kubernetes/website](https://github.com/kubernetes/website) repository is
`$GOPATH/src/github.com/<your username>/website.`
The remaining steps refer to your base directory as `<web-base>`.
* The base directory of your clone of the
[kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs)
repository is `$GOPATH/src/github.com/kubernetes-incubator/reference-docs.`
The remaining steps refer to your base directory as `<rdocs-base>`.
## Generating the API reference docs for publishing
The preceding section showed how to edit a source file and then generate
several files, including `api/openapi-spec/swagger.json` in the
`kubernetes/kubernetes` repository.
## Generating the API reference docs
This section shows how to generate the
[published Kubernetes API reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/),
which is generated by the tools at
[kubernetes-incubator/reference-docs](https://github.com/kubernetes-incubator/reference-docs).
Those tools take the `api/openapi-spec/swagger.json` file as input.
[published Kubernetes API reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
### Editing Makefile in kubernetes-incubator/reference-docs
### Modifying the Makefile
Go to `<rdocs-base>`, and open `Makefile` for editing:
Go to `<rdocs-base>`, and open the `Makefile` for editing:
Set `K8SROOT` to the base directory of your local kubernetes/kubernetes
repository. Set `WEBROOT` to the base directory of your local kubernetes/website repository.
Set `MINOR_VERSION` to the minor version of the docs you want to build. For example,
if you want to build docs for Kubernetes 1.9, set `MINOR_VERSION` to 9. Save and close `Makefile`.
* Set `K8SROOT` to `<k8s-base>`.
* Set `WEBROOT` to `<web-base>`.
* Set `MINOR_VERSION` to the minor version of the docs you want to build. For example,
if you want to build docs for Kubernetes 1.15, set `MINOR_VERSION` to 15. Save and close the `Makefile`.
For example, update the following variables:
```
WEBROOT=$(GOPATH)/src/github.com/<your-username>/website
K8SROOT=$(GOPATH)/src/k8s.io/kubernetes
MINOR_VERSION=15
```
### Copying the OpenAPI spec
The doc generation code needs a local copy of the OpenAPI spec for the Kubernetes API.
Go to `<k8s-base>` and check out the branch that has the OpenAPI spec you want to use.
For example, if you want to generate docs for Kubernetes 1.9, checkout the release-1.9
branch.
Go back to `<rdocs-base>`. Enter the following command to copy the OpenAPI spec from the
`kubernetes/kubernetes` repository to a local directory:
Run the following command in `<rdocs-base>`:
```shell
make updateapispec
@@ -129,43 +117,44 @@ make updateapispec
The output shows that the file was copied:
```shell
cp ~/src/github.com/kubernetes/kubernetes/api/openapi-spec/swagger.json gen-apidocs/generators/openapi-spec/swagger.json
cp ~/src/k8s.io/kubernetes/api/openapi-spec/swagger.json gen-apidocs/generators/openapi-spec/swagger.json
```
### Building the API reference docs
Run the following command to generate the API reference docs:
Run the following command in `<rdocs-base>`:
```shell
cd <rdocs-base>
make api
```
### Locate the generated files
Verify that these two files have been generated:
These two files are the output of a successful build. Verify that they exist:
```shell
[ -e "<rdocs-base>/gen-apidocs/generators/build/index.html" ] && echo "index.html built" || echo "no index.html"
[ -e "<rdocs-base>/gen-apidocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js"
```
* `<rdocs-base>/gen-apidocs/generators/build/index.html`
* `<rdocs-base>/gen-apidocs/generators/build/navData.js`
### Creating directories for published docs
Create the directories in `<web-base>` for the generated API reference files:
```shell
mkdir -p <web-base>/static/docs/reference/generated/kubernetes-api/v1.<minor-version>
mkdir -p <web-base>/static/docs/reference/generated/kubernetes-api/v1.<minor-version>/css
mkdir -p <web-base>/static/docs/reference/generated/kubernetes-api/v1.<minor-version>/fonts
```
## Copying the generated docs to the kubernetes/website repository
The preceding sections showed how to generate reference documentation for publication.
This section shows how to copy the generated reference to the
[kubernetes/website](https://github.com/kubernetes/website) repository. The files
in the `kubernetes/website` repository are published in the
[kubernetes.io](https://kubernetes.io) website. In particular, the generated
`index.html` file is published [here](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
Enter the following command to copy the generated files to
Run the following command in `<rdocs-base>` to copy the generated files to
your local kubernetes/website repository:
```shell
make copyapi
```
Go to the base of your local kubernetes/website repository, and
Go to the base of your local kubernetes/website repository, and
see which files have been modified:
```shell
@@ -175,15 +164,52 @@ git status
The output shows the modified files:
```shell
On branch master
...
modified: docs/reference/generated/kubernetes-api/v1.9/index.html
```
static/docs/reference/generated/kubernetes-api/v1.15/css/bootstrap.min.css
static/docs/reference/generated/kubernetes-api/v1.15/css/font-awesome.min.css
static/docs/reference/generated/kubernetes-api/v1.15/css/stylesheet.css
static/docs/reference/generated/kubernetes-api/v1.15/fonts/FontAwesome.otf
static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.eot
static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.svg
static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.ttf
static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.woff
static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.woff2
static/docs/reference/generated/kubernetes-api/v1.15/index.html
static/docs/reference/generated/kubernetes-api/v1.15/jquery.scrollTo.min.js
static/docs/reference/generated/kubernetes-api/v1.15/navData.js
static/docs/reference/generated/kubernetes-api/v1.15/scroll.js
```
In this example, only one file has been modified. Recall that you generated both
`index.html` and `navData.js`. But apparently the generated `navata.js` is not different
from the `navData.js` that was already in the kubernetes/website` repository.
## Updating the API reference index pages
* Open `<web-base>/content/en/docs/reference/kubernetes-api/index.md` for editing, and update the API reference
version number. For example:
```
---
title: v1.15
---
[Kubernetes API v1.15](/docs/reference/generated/kubernetes-api/v1.15/)
```
* Open `<web-base>/content/en/docs/reference/_index.md` for editing, and add a
new link for the latest API reference. Remove the oldest API reference version.
There should be five links to the most recent API references.
## Locally test the API reference
Publish a local version of the API reference.
Verify the [local preview](http://localhost:1313/docs/reference/generated/kubernetes-api/v1.15/).
```shell
cd <web-base>
make docker-serve
```
## Commit the changes
In `<web-base>` run `git add` and `git commit` to commit the change.
@@ -193,9 +219,6 @@ Submit your changes as a
Monitor your pull request, and respond to reviewer comments as needed. Continue
to monitor your pull request until it has been merged.
A few minutes after your pull request is merged, your changes will be visible
in the [published reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
{{% /capture %}}
{{% capture whatsnext %}}
@@ -204,5 +227,4 @@ in the [published reference documentation](/docs/reference/generated/kubernetes-
* [Generating Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/)
* [Generating Reference Documentation for the Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/)
{{% /capture %}}
{{% /capture %}}
content/en/docs/contribute/intermediate.md
+18 -42
View File
@@ -63,7 +63,7 @@ active participants.
Before you start reviewing PRs, make sure you are familiar with the
[Documentation Style Guide](/docs/contribute/style/style-guide/)
and the [code of conduct](/community/code-of-conduct/)
and the [code of conduct](/community/code-of-conduct/).
### Find a PR to review
@@ -101,7 +101,7 @@ more information about the responsibilities of reviewers and approvers, see
indicates that a PR is technically accurate by leaving a `/lgtm` comment on
the PR.
{{< note >}}Don't add an `/lgtm` unless you are confident in the technical
{{< note >}}Don't add a `/lgtm` unless you are confident in the technical
accuracy of the documentation modified or introduced in the PR.{{< /note >}}
- An approver reviews pull request content for docs quality and adherence to
@@ -109,13 +109,19 @@ more information about the responsibilities of reviewers and approvers, see
[style guide](/docs/contribute/style/style-guide). Only people listed as
approvers in the
[`OWNERS`](https://github.com/kubernetes/website/blob/master/OWNERS) file can
approve a PR. To approve a PR, leave an `/approved` comment on the PR.
approve a PR. To approve a PR, leave an `/approve` comment on the PR.
A PR is merged when it has both a `/lgtm` comment from anyone in the Kubernetes
organization and an `/approved` comment from an approver in the
organization and an `/approve` comment from an approver in the
`sig-docs-maintainers` group, as long as it is not on hold and the PR author
has signed the CLA.
{{< note >}}
The ["Participating"](/docs/contribute/participating/#approvers) section contains more information for reviewers and approvers, including specific responsibilities for approvers.
{{< /note >}}
### Review a PR
1. Read the PR description and read any attached issues or links, if
@@ -172,9 +178,9 @@ has signed the CLA.
provide technical review.
- To prevent the PR from being merged, add `/hold`. This sets the
label `do-not-merge/hold`.
- If a PR has no conflicts and has the `lgtm` and `approved` label but
- If a PR has no conflicts and has the `lgtm` and `approve` labels but
no `hold` label, it is merged automatically.
- If a PR has the `lgtm` and/or `approved` labels and new changes are
- If a PR has the `lgtm` and/or `approve` labels and new changes are
detected, these labels are removed automatically.
See
@@ -575,45 +581,15 @@ These guidelines are not set in stone and are subject to change.
not be assigned automatically. A bug is a problem with existing content or
functionality, and a feature is a request for new content or functionality.
The `kind/documentation` label is not currently in use.
- Priority labels: define the relative severity of the issue. These do not
conform to those outlined in the
[Kubernetes contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority), and can be one of `P1`, `P2`, or `P3`, if set.
- To add a label, you can use GitHub's **Labels** widget if you are a Sig Docs
approver. Anyone who is a member of the Kubernetes organization can add a
label by leaving a comment like `/label <label-to-add>`. The label must
- Priority labels: define the relative severity of the issue, as outlined in the
[Kubernetes contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority).
- To add a label, leave a comment like `/label <label-to-add>`. The label must
already exist. If you try to add a label that does not exist, the command is
silently ignored.
### Priorities
An issue's priority influences how quickly it is addressed. For documentation,
here are the guidelines for setting a priority on an issue:
#### P1
- Major content errors affecting more than 1 page
- Broken code sample on a heavily trafficked page
- Errors on a “getting started” page
- Well known or highly publicized customer pain points
- Automation issues
#### P2
This is the default for new issues and pull requests.
- Broken code for sample that is not heavily used
- Minor content issues in a heavily trafficked page
- Major content issues on a lower-trafficked page
#### P3
- Typos and broken anchor links
- Documentation feature requests
- "Nice to have" items
### Handling special issue types
We've encountered the following types of issues often enough to document how
We encounter the following types of issues often enough to document how
to handle them.
#### Duplicate issues
@@ -629,8 +605,8 @@ same problem.
Depending on where the dead link is reported, different actions are required to
resolve the issue. Dead links in the API and Kubectl docs are automation issues
and should be assigned a P1 until the problem can be fully understood. All other
dead links are issues that need to be manually fixed and can be assigned a P3.
and should be assigned `/priority critical-urgent` until the problem can be fully understood. All other
dead links are issues that need to be manually fixed and can be assigned `/priority important-longterm`.
#### Blog issues
content/en/docs/contribute/localization.md
+4 -2
View File
@@ -195,9 +195,11 @@ cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kube
Translation tools can speed up the translation process. For example, some editors offers plugins to quickly translate text.
{{< caution >}}
Use translation tools with care. Their output is not always accurate.
Machine-generated translation alone does not meet the minimum standard of quality and requires extensive human review to meet that standard.
{{< /caution >}}
To ensure accuracy in grammar and meaning, members of your localization team should carefully review all machine-generated translations before publishing.
### Source files
Localizations must be based on the English files from the most recent release, {{< latest-version >}}.
@@ -283,6 +285,6 @@ You can also help add or improve content to an existing localization. Join the [
Once a localization meets requirements for workflow and minimum output, SIG docs will:
- Enable language selection on the website
- Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/).
- Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/).
{{% /capture %}}
content/en/docs/contribute/participating.md
+17 -9
View File
@@ -201,21 +201,29 @@ If you are approved, request that a current SIG Docs approver add you to the
GitHub group. Only members of the `kubernetes-website-admins` GitHub group can
add new members to a GitHub group.
#### Becoming a website admin
#### Approver responsibilities
Members of the `kubernetes-website-admins` GitHub group can manage GitHub group
membership and have full administrative rights to the settings of the repository,
including the ability to add, remove, and troubleshoot webhooks. Not all SIG
Docs approvers need this level of access.
Approvers improve the documentation by reviewing and merging pull requests into the website repository. Because this role carries additional privileges, approvers have additional responsibilities:
If you think you need this level of access, talk to an existing website admin or
ask in the #sig-docs channel on [Kubernetes Slack](https://kubernetes.slack.com).
- Approvers can use the `/approve` command, which merges PRs into the repo.
A careless merge can break the site, so be sure that when you merge something, you mean it.
- Make sure that proposed changes meet the contribution guidelines.
If you ever have a question, or you're not sure about something, feel free to call for additional review.
- Verify that netlify tests pass before you `/approve` a PR.
<img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="Netlify tests must pass before approving" />
- Visit the netlify page preview for a PR to make sure things look good before approving.
#### PR Wrangler
SIG Docs approvers are added to the
SIG Docs approvers participate in the
[PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers)
for weekly rotations. All SIG Docs approvers are expected to take part in this
for weekly rotations. SIG Docs expects all approvers to participate in this
rotation. See
[Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)
for more details.
content/en/docs/contribute/start.md
+8 -7
View File
@@ -32,13 +32,14 @@ The Kubernetes documentation is written in Markdown and processed and deployed u
You can file issues, edit content, and review changes from others, all from the
GitHub website. You can also use GitHub's embedded history and search tools.
Not all tasks can be done in the GitHub UI, but these are discussed in the
Not all tasks can be done in the GitHub UI, but these are discussed in the
[intermediate](/docs/contribute/intermediate/) and
[advanced](/docs/contribute/advanced/) docs contribution guides.
### Participating in SIG Docs
The Kubernetes documentation is maintained by a Special Interest Group (SIG)
The Kubernetes documentation is maintained by a
{{< glossary_tooltip text="Special Interest Group" term_id="sig" >}} (SIG)
called SIG Docs. We communicate using a Slack channel, a mailing list, and
weekly video meetings. New participants are welcome. For more information, see
[Participating in SIG Docs](/docs/contribute/participating/).
@@ -68,9 +69,9 @@ We make use of the standard Hugo shortcodes, as well as a few that are custom to
the Kubernetes documentation. See [Custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) for
information about how to use them.
### Multiple languages
### Multiple languages
Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`.
Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`.
For more information about contributing to documentation in multiple languages, see ["Localize content"](/docs/contribute/intermediate#localize-content) in the intermediate contributing guide.
@@ -158,7 +159,7 @@ upcoming Kubernetes release, your process is a bit different. See
process guidelines and information about deadlines.
{{< /note >}}
### Sign the CLA
### Sign the CNCF CLA {#sign-the-cla}
Before you can contribute code or documentation to Kubernetes, you **must** read
the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and
@@ -299,7 +300,7 @@ conventions and etiquette and get used to the workflow.
PR, and if applicable, also look at any linked issues. If you see a problem
or room for improvement, hover over the line and click the `+` symbol that
appears.
You can type a comment, and either choose **Add single comment** or **Start
a review**. Typically, starting a review is better because it allows you to
leave multiple comments and notifies the PR owner only when you have
@@ -342,7 +343,7 @@ or follow the steps below.
Case studies highlight how organizations are using Kubernetes to solve
real-world problems. They are written in collaboration with the Kubernetes
marketing team, which is handled by the CNCF.
marketing team, which is handled by the {{< glossary_tooltip text="CNCF" term_id="cncf" >}}.
Have a look at the source for the
[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies).
content/en/docs/contribute/style/style-guide.md
+9 -2
View File
@@ -29,7 +29,14 @@ and representing feature state.
## Language
Kubernetes documentation uses US English.
Kubernetes documentation has been translated into multiple languages
(see [Localization READMEs](https://github.com/kubernetes/website/blob/master/README.md#localization-readmemds)).
The way of localizing the docs for a different language is described in [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/).
The English-language documentation uses U.S. English spelling and grammar.
{{< comment >}}[If you're localizing this page, you can omit the point about US English.]{{< /comment >}}
## Documentation formatting standards
@@ -209,7 +216,7 @@ Hugo [Shortcodes](https://gohugo.io/content-management/shortcodes) help create d
```
{{</* note */>}}
No need to include a prefix; the shortcode automatically provides on (Note:, Caution:, etc.).
No need to include a prefix; the shortcode automatically provides one. (Note:, Caution:, etc.)
{{</* /note */>}}
```
content/en/docs/reference/_index.md
+1 -1
View File
@@ -20,11 +20,11 @@ This section of the Kubernetes documentation contains references.
* [Kubernetes API Overview](/docs/reference/using-api/api-overview/) - Overview of the API for Kubernetes.
* Kubernetes API Versions
* [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
* [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
* [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
* [1.12](/docs/reference/generated/kubernetes-api/v1.12/)
* [1.11](/docs/reference/generated/kubernetes-api/v1.11/)
* [1.10](/docs/reference/generated/kubernetes-api/v1.10/)
## API Client Libraries
content/en/docs/reference/access-authn-authz/admission-controllers.md
+20 -4
View File
@@ -249,6 +249,22 @@ plugins:
...
```
Alternatively, you can embed the configuration directly in the file:
```yaml
apiVersion: apiserver.k8s.io/v1alpha1
kind: AdmissionConfiguration
plugins:
- name: ImagePolicyWebhook
configuration:
imagePolicy:
kubeConfigFile: /path/to/file
allowTTL: 50
denyTTL: 50
retryBackoff: 500
defaultAllow: true
```
The ImagePolicyWebhook config file must reference a [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) formatted file which sets up the connection to the backend. It is required that the backend communicate over TLS.
The kubeconfig file's cluster field must point to the remote service, and the user field must contain the returned authorizer.
@@ -292,15 +308,15 @@ An example request body:
"image":"myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d90ed"
}
],
"annotations":[
"annotations":{
"mycluster.image-policy.k8s.io/ticket-1234": "break-glass"
],
},
"namespace":"mynamespace"
}
}
```
The remote service is expected to fill the ImageReviewStatus field of the request and respond to either allow or disallow access. The response body's "spec" field is ignored and may be omitted. A permissive response would return:
The remote service is expected to fill the `ImageReviewStatus` field of the request and respond to either allow or disallow access. The response body's "spec" field is ignored and may be omitted. A permissive response would return:
```json
{
@@ -337,7 +353,7 @@ Examples of information you might put here are:
* a ticket number from a ticket system that documents the break-glass request
* provide a hint to the policy server as to the imageID of the image being provided, to save it a lookup
In any case, the annotations are provided by the user and are not validated by Kubernetes in any way. In the future, if an annotation is determined to be widely useful, it may be promoted to a named field of ImageReviewSpec.
In any case, the annotations are provided by the user and are not validated by Kubernetes in any way. In the future, if an annotation is determined to be widely useful, it may be promoted to a named field of `ImageReviewSpec`.
### LimitPodHardAntiAffinityTopology {#limitpodhardantiaffinitytopology}
content/en/docs/reference/access-authn-authz/authorization.md
+21 -9
View File
@@ -47,14 +47,21 @@ Kubernetes reviews only the following API request attributes:
* **extra** - A map of arbitrary string keys to string values, provided by the authentication layer.
* **API** - Indicates whether the request is for an API resource.
* **Request path** - Path to miscellaneous non-resource endpoints like `/api` or `/healthz`.
* **API request verb** - API verbs `get`, `list`, `create`, `update`, `patch`, `watch`, `proxy`, `redirect`, `delete`, and `deletecollection` are used for resource requests. To determine the request verb for a resource API endpoint, see [Determine the request verb](/docs/reference/access-authn-authz/authorization/#determine-the-request-verb).
* **HTTP request verb** - HTTP verbs `get`, `post`, `put`, and `delete` are used for non-resource requests.
* **API request verb** - API verbs like `get`, `list`, `create`, `update`, `patch`, `watch`, `delete`, and `deletecollection` are used for resource requests. To determine the request verb for a resource API endpoint, see [Determine the request verb](/docs/reference/access-authn-authz/authorization/#determine-the-request-verb).
* **HTTP request verb** - Lowercased HTTP methods like `get`, `post`, `put`, and `delete` are used for non-resource requests.
* **Resource** - The ID or name of the resource that is being accessed (for resource requests only) -- For resource requests using `get`, `update`, `patch`, and `delete` verbs, you must provide the resource name.
* **Subresource** - The subresource that is being accessed (for resource requests only).
* **Namespace** - The namespace of the object that is being accessed (for namespaced resource requests only).
* **API group** - The API group being accessed (for resource requests only). An empty string designates the [core API group](/docs/concepts/overview/kubernetes-api/).
## Determine the Request Verb
**Non-resource requests**
Requests to endpoints other than `/api/v1/...` or `/apis/<group>/<version>/...`
are considered "non-resource requests", and use the lower-cased HTTP method of the request as the verb.
For example, a `GET` request to endpoints like `/api` or `/healthz` would use `get` as the verb.
**Resource requests**
To determine the request verb for a resource API endpoint, review the HTTP verb
used and whether or not the request acts on an individual resource or a
collection of resources:
@@ -62,20 +69,25 @@ collection of resources:
HTTP verb | request verb
----------|---------------
POST | create
GET, HEAD | get (for individual resources), list (for collections)
GET, HEAD | get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources)
PUT | update
PATCH | patch
DELETE | delete (for individual resources), deletecollection (for collections)
Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:
* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) checks for authorization of the `use` verb on `podsecuritypolicies` resources in the `policy` API group.
* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) checks for authorization
of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
* [Authentication](/docs/reference/access-authn-authz/authentication/) layer checks for authorization of the `impersonate` verb on `users`, `groups`, and `serviceaccounts` in the core API group, and the `userextras` in the `authentication.k8s.io` API group.
* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)
* `use` verb on `podsecuritypolicies` resources in the `policy` API group.
* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
* `bind` and `escalate` verbs on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
* [Authentication](/docs/reference/access-authn-authz/authentication/)
* `impersonate` verb on `users`, `groups`, and `serviceaccounts` in the core API group, and the `userextras` in the `authentication.k8s.io` API group.
## Authorization Modules
* **Node** - A special-purpose authorizer that grants permissions to kubelets based on the pods they are scheduled to run. To learn more about using the Node authorization mode, see [Node Authorization](/docs/reference/access-authn-authz/node/).
## Authorization Modes {#authorization-modules}
The Kubernetes API server may authorize a request using one of several authorization modes:
* **Node** - A special-purpose authorization mode that grants permissions to kubelets based on the pods they are scheduled to run. To learn more about using the Node authorization mode, see [Node Authorization](/docs/reference/access-authn-authz/node/).
* **ABAC** - Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes, etc). To learn more about using the ABAC mode, see [ABAC Mode](/docs/reference/access-authn-authz/abac/).
* **RBAC** - Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. To learn more about using the RBAC mode, see [RBAC Mode](/docs/reference/access-authn-authz/rbac/)
* When specified RBAC (Role-Based Access Control) uses the `rbac.authorization.k8s.io` API group to drive authorization decisions, allowing admins to dynamically configure permission policies through the Kubernetes API.
content/en/docs/reference/access-authn-authz/controlling-access.md
-1
View File
@@ -1,6 +1,5 @@
---
reviewers:
- bgrant0607
- erictune
- lavalamp
title: Controlling Access to the Kubernetes API
content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
+9 -8
View File
@@ -690,7 +690,7 @@ or the server could power off before persisting the object.
Additionally, webhooks with side effects should skip those side-effects when `dryRun: true` admission requests are handled.
A webhook must explicitly indicate that it will not have side-effects when run with `dryRun`,
or the dry-run request will not be sent to the webhook and the API request fill fail instead.
or the dry-run request will not be sent to the webhook and the API request will fail instead.
Webhooks indicate whether they have side effects using the `sideEffects` field in the webhook configuration.
`sideEffects` may be set to `Unknown`, `None`, `Some`, `NoneOnDryRun`. The default is `Unknown`.
@@ -752,12 +752,13 @@ and mutating webhooks can specify a `reinvocationPolicy` to control whether they
* `Never`: the webhook must not be called more than once in a single admission evaluation
* `IfNeeded`: the webhook may be called again as part of the admission evaluation if the object
being admitted is modified by other admission plugins after the initial webhook call.
{{< note >}}
* the number of additional invocations is not guaranteed to be exactly one.
* if additional invocations result in further modifications to the object, webhooks are not guaranteed to be invoked again.
* webhooks that use this option may be reordered to minimize the number of additional invocations.
* to validate an object after all mutations are guaranteed complete, use a validating admission webhook instead (recommended for webhooks with side-effects).
{{< /note >}}
The important elements to note are:
* The number of additional invocations is not guaranteed to be exactly one.
* If additional invocations result in further modifications to the object, webhooks are not guaranteed to be invoked again.
* Webhooks that use this option may be reordered to minimize the number of additional invocations.
* To validate an object after all mutations are guaranteed complete, use a validating admission webhook instead (recommended for webhooks with side-effects).
Here is an example of a mutating webhook opting into being re-invoked if later admission plugins modify the object:
@@ -778,7 +779,7 @@ in an object could already exist in the user-provided object, but it is essentia
### Failure policy
`failurePolicy` defines how unrecognized errors and timeout errors from the admission webhook
are handled. Allowed values are `Ignore` or `Fail`. Defaults to `Ignore` in v1beta1.
are handled. Allowed values are `Ignore` or `Fail`. Defaults to `Ignore` in v1beta1, and v1 has changed the default to `Fail`.
* `Ignore` means that an error calling the webhook is ignored and the API request is allowed to continue.
* `Fail` means that an error calling the webhook causes the admission to fail and the API request to be rejected.
content/en/docs/reference/command-line-tools-reference/feature-gates.md
+32 -7
View File
@@ -72,12 +72,16 @@ different Kubernetes components.
| `CSIPersistentVolume` | `true` | GA | 1.13 | - |
| `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
| `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 |
| `CustomPodDNS` | `true` | Beta| 1.10 | |
| `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 |
| `CustomPodDNS` | `true` | GA | 1.14 | - |
| `CustomResourcePublishOpenAPI` | `false` | Alpha| 1.14 | 1.14 |
| `CustomResourcePublishOpenAPI` | `true` | Beta| 1.15 | |
| `CustomResourceSubresources` | `false` | Alpha | 1.10 | 1.11 |
| `CustomResourceSubresources` | `true` | Beta | 1.11 | - |
| `CustomResourceValidation` | `false` | Alpha | 1.8 | 1.8 |
| `CustomResourceValidation` | `true` | Beta | 1.9 | |
| `CustomResourceWebhookConversion` | `false` | Alpha | 1.13 | |
| `CustomResourceWebhookConversion` | `false` | Alpha | 1.13 | 1.14 |
| `CustomResourceWebhookConversion` | `true` | Beta | 1.15 | |
| `DebugContainers` | `false` | Alpha | 1.10 | |
| `DevicePlugins` | `false` | Alpha | 1.8 | 1.9 |
| `DevicePlugins` | `true` | Beta | 1.10 | |
@@ -89,8 +93,9 @@ different Kubernetes components.
| `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | |
| `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | |
| `ExpandCSIVolumes` | `false` | Alpha | 1.14 | | |
| `ExpandInUsePersistentVolumes` | `false` | Alpha | 1.11 | 1.13 | |
| `ExpandCSIVolumes` | `false` | Alpha | 1.14 | |
| `ExpandInUsePersistentVolumes` | `false` | Alpha | 1.11 | 1.14 |
| `ExpandInUsePersistentVolumes` | `true` | Beta | 1.15 | |
| `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 |
| `ExpandPersistentVolumes` | `true` | Beta | 1.11 | |
| `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | |
@@ -107,7 +112,8 @@ different Kubernetes components.
| `KubeletPluginsWatcher` | `false` | Alpha | 1.11 | 1.11 |
| `KubeletPluginsWatcher` | `true` | Beta | 1.12 | 1.12 |
| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - |
| `KubeletPodResources` | `false` | Alpha | 1.13 | |
| `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
| `KubeletPodResources` | `true` | Beta | 1.15 | |
| `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 |
| `LocalStorageCapacityIsolation` | `true` | Beta| 1.10 | |
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha| 1.15 | |
@@ -117,19 +123,23 @@ different Kubernetes components.
| `MountPropagation` | `true` | GA | 1.12 | |
| `NodeLease` | `false` | Alpha | 1.12 | 1.13 |
| `NodeLease` | `true` | Beta | 1.14 | |
| `NonPreemptingPriority` | `false` | Alpha | 1.15 | |
| `PersistentLocalVolumes` | `false` | Alpha | 1.7 | 1.9 |
| `PersistentLocalVolumes` | `true` | Beta | 1.10 | 1.13 |
| `PersistentLocalVolumes` | `true` | GA | 1.14 | |
| `PodPriority` | `false` | Alpha | 1.8 | 1.10 |
| `PodPriority` | `true` | Beta | 1.11 | 1.13 |
| `PodPriority` | `true` | GA | 1.14 | |
| `PodReadinessGates` | `false` | Alpha | 1.11 | |
| `PodReadinessGates` | `true` | Beta | 1.12 | |
| `PodReadinessGates` | `false` | Alpha | 1.11 | 1.11 |
| `PodReadinessGates` | `true` | Beta | 1.12 | 1.13 |
| `PodReadinessGates` | `true` | GA | 1.14 | - |
| `PodShareProcessNamespace` | `false` | Alpha | 1.10 | |
| `PodShareProcessNamespace` | `true` | Beta | 1.12 | |
| `ProcMountType` | `false` | Alpha | 1.12 | |
| `PVCProtection` | `false` | Alpha | 1.9 | 1.9 |
| `RemainingItemCount` | `false` | Alpha | 1.15 | |
| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | |
| `RequestManagement` | `false` | Alpha | 1.15 | |
| `ResourceQuotaScopeSelectors` | `false` | Alpha | 1.11 | 1.11 |
| `ResourceQuotaScopeSelectors` | `true` | Beta | 1.12 | |
| `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | |
@@ -139,14 +149,19 @@ different Kubernetes components.
| `RuntimeClass` | `true` | Beta | 1.14 | |
| `SCTPSupport` | `false` | Alpha | 1.12 | |
| `ServerSideApply` | `false` | Alpha | 1.14 | |
| `ServiceLoadBalancerFinalizer` | `false` | Alpha | 1.15 | |
| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
| `StorageObjectInUseProtection` | `true` | Beta | 1.10 | 1.10 |
| `StorageObjectInUseProtection` | `true` | GA | 1.11 | |
| `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
| `StorageVersionHash` | `true` | Beta | 1.15 | |
| `StreamingProxyRedirects` | `true` | Beta | 1.5 | |
| `SupportIPVSProxyMode` | `false` | Alpha | 1.8 | 1.8 |
| `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 |
| `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 |
| `SupportIPVSProxyMode` | `true` | GA | 1.11 | |
| `SupportNodePidsLimit` | `false` | Alpha | 1.14 | 1.14 |
| `SupportNodePidsLimit` | `true` | Beta | 1.15 | |
| `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 |
| `SupportPodPidsLimit` | `true` | Beta | 1.14 | |
| `Sysctls` | `true` | Beta | 1.11 | |
@@ -159,6 +174,7 @@ different Kubernetes components.
| `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 |
| `TokenRequestProjection` | `true` | Beta | 1.12 | |
| `TTLAfterFinished` | `false` | Alpha | 1.12 | |
| `VolumePVCDataSource` | `false` | Alpha | 1.15 | |
| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
| `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
| `VolumeScheduling` | `true` | GA | 1.13 | |
@@ -167,6 +183,7 @@ different Kubernetes components.
| `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | - |
| `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 |
| `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | |
| `WatchBookmark` | `false` | Alpha | 1.15 | |
| `WindowsGMSA` | `false` | Alpha | 1.14 | |
## Using a Feature
@@ -233,6 +250,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `CRIContainerLogRotation`: Enable container log rotation for cri container runtime.
- `CSIBlockVolume`: Enable external CSI volume drivers to support block storage. See the [`csi` raw block volume support](/docs/concepts/storage/volumes/#csi-raw-block-volume-support) documentation for more details.
- `CSIDriverRegistry`: Enable all logic related to the CSIDriver API object in csi.storage.k8s.io.
- `CSIInlineVolume`: Enable CSI Inline volumes support for pods.
- `CSIMigration`: Enables shims and translation logic to route volume operations from in-tree plugins to corresponding pre-installed CSI plugins
- `CSIMigrationAWS`: Enables shims and translation logic to route volume operations from the AWS-EBS in-tree plugin to EBS CSI plugin
- `CSIMigrationAzureDisk`: Enables shims and translation logic to route volume operations from the Azure-Disk in-tree plugin to Azure Disk CSI plugin
@@ -248,6 +266,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `CustomPodDNS`: Enable customizing the DNS settings for a Pod using its `dnsConfig` property.
Check [Pod's DNS Config](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)
for more details.
- `CustomResourcePublishOpenAPI`: Enables publishing of CRD OpenAPI specs.
- `CustomResourceSubresources`: Enable `/status` and `/scale` subresources
on resources created from [CustomResourceDefinition](/docs/concepts/api-extension/custom-resources/).
- `CustomResourceValidation`: Enable schema based validation on resources created from
@@ -288,6 +307,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods.
For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
- `NodeLease`: Enable the new Lease API to report node heartbeats, which could be used as a node health signal.
- `NonPreemptingPriority`: Enable NonPreempting option for PriorityClass and Pod.
- `PersistentLocalVolumes`: Enable the usage of `local` volume type in Pods.
Pod affinity has to be specified if requesting a `local` volume.
- `PodPriority`: Enable the descheduling and preemption of Pods based on their [priorities](/docs/concepts/configuration/pod-priority-preemption/).
@@ -302,6 +322,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
assigns a lowest possible score of 1 to a node that satisfies at least one of
the input Pod's cpu and memory limits. The intent is to break ties between
nodes with same scores.
- `RequestManagement`: Enable managing request concurrency with prioritization and fairness at each server.
- `ResourceQuotaScopeSelectors`: Enable resource quota scope selectors.
- `RotateKubeletClientCertificate`: Enable the rotation of the client TLS certificate on the kubelet.
See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration) for more details.
@@ -312,10 +333,12 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `ScheduleDaemonSetPods`: Enable DaemonSet Pods to be scheduled by the default scheduler instead of the DaemonSet controller.
- `SCTPSupport`: Enables the usage of SCTP as `protocol` value in `Service`, `Endpoint`, `NetworkPolicy` and `Pod` definitions
- `ServerSideApply`: Enables the [Sever Side Apply (SSA)](/docs/reference/using-api/api-concepts/#server-side-apply) path at the API Server.
- `ServiceLoadBalancerFinalizer`: Enable finalizer protection for Service load balancers.
- `ServiceNodeExclusion`: Enable the exclusion of nodes from load balancers created by a cloud provider.
A node is eligible for exclusion if annotated with "`alpha.service-controller.kubernetes.io/exclude-balancer`" key.
- `StorageObjectInUseProtection`: Postpone the deletion of PersistentVolume or
PersistentVolumeClaim objects if they are still being used.
- `StorageVersionHash`: Allow apiservers to expose the storage version hash in the discovery.
- `StreamingProxyRedirects`: Instructs the API server to intercept (and follow)
redirects from the backend (kubelet) for streaming requests.
Examples of streaming requests include the `exec`, `attach` and `port-forward` requests.
@@ -331,12 +354,14 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `TokenRequestProjection`: Enable the injection of service account tokens into
a Pod through the [`projected` volume](/docs/concepts/storage/volumes/#projected).
- `TTLAfterFinished`: Allow a [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) to clean up resources after they finish execution.
- `VolumePVCDataSource`: Enable support for specifying an existing PVC as a DataSource.
- `VolumeScheduling`: Enable volume topology aware scheduling and make the
PersistentVolumeClaim (PVC) binding aware of scheduling decisions. It also
enables the usage of [`local`](/docs/concepts/storage/volumes/#local) volume
type when used together with the `PersistentLocalVolumes` feature gate.
- `VolumeSnapshotDataSource`: Enable volume snapshot data source support.
- `VolumeSubpathEnvExpansion`: Enable `subPathExpr` field for expanding environment variables into a `subPath`.
- `WatchBookmark`: Enable support for watch bookmark events.
- `WindowsGMSA`: Enables passing of GMSA credential specs from pods to container runtimes.
{{% /capture %}}
content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
+1 -1
View File
@@ -948,7 +948,7 @@ kube-apiserver [flags]
<td colspan="2">--tls-cipher-suites stringSlice</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be use. Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used. Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA</td>
</tr>
<tr>
content/en/docs/reference/command-line-tools-reference/kubelet.md
-7
View File
@@ -59,13 +59,6 @@ kubelet [flags]
<td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address for the Kubelet to serve on (set to 0.0.0.0 for all IPv4 interfaces and `::` for all IPv6 interfaces) (default 0.0.0.0)</td>
</tr>
<tr>
<td colspan="2">--allow-privileged</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">If true, allow containers to request privileged mode.</td>
</tr>
<tr>
<td colspan="2">--alsologtostderr</td>
</tr>
content/en/docs/reference/glossary/cgroup.md
+17
View File
@@ -0,0 +1,17 @@
---
title: cgroup (control group)
id: cgroup
date: 2019-06-25
full_link:
short_description: >
A group of Linux processes with optional resource isolation, accounting and limits.
aka:
tags:
- fundamental
---
A group of Linux processes with optional resource isolation, accounting and limits.
<!--more-->
cgroup is a Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O, network) for a collection of processes.
content/en/docs/reference/glossary/cluster.md
+5 -7
View File
@@ -1,19 +1,17 @@
---
title: Cluster
id: cluster
date: 2018-04-12
date: 2019-06-15
full_link:
short_description: >
A set of machines, called nodes, that run containerized applications managed by Kubernetes.
A set of machines, called nodes, that run containerized applications managed by Kubernetes. A cluster has at least one worker node and at least one master node.
aka:
tags:
- fundamental
- operation
---
A set of machines, called nodes, that run containerized applications managed by Kubernetes.
<!--more-->
A cluster has several worker nodes and at least one master node.
A set of machines, called nodes, that run containerized applications managed by Kubernetes. A cluster has at least one worker node and at least one master node.
<!--more-->
The worker node(s) host the pods that are the components of the application. The master node(s) manages the worker nodes and the pods in the cluster. Multiple master nodes are used to provide a cluster with failover and high availability.
content/en/docs/reference/glossary/cncf.md
Executable
+23
View File
@@ -0,0 +1,23 @@
---
title: Cloud Native Computing Foundation (CNCF)
id: cncf
date: 2019-05-26
full_link: https://cncf.io/
short_description: >
Cloud Native Computing Foundation
aka:
tags:
- community
---
The Cloud Native Computing Foundation (CNCF) builds sustainable ecosystems and
fosters a community around [projects](https://www.cncf.io/projects/) that
orchestrate containers as part of a microservices architecture.
Kubernetes is a CNCF project.
<!--more-->
The CNCF is a sub-foundation of [the Linux Foundation](https://www.linuxfoundation.org/).
Its mission is to make cloud native computing ubiquitous.
content/en/docs/reference/glossary/cri-o.md
+1 -1
View File
@@ -10,7 +10,7 @@ aka:
tags:
- tool
---
A tool that lets you use OCI container runtimes witk Kubernetes CRI.
A tool that lets you use OCI container runtimes with Kubernetes CRI.
<!--more-->
content/en/docs/reference/glossary/kube-proxy.md
+12 -9
View File
@@ -2,21 +2,24 @@
title: kube-proxy
id: kube-proxy
date: 2018-04-12
full_link: /docs/reference/generated/kube-proxy
full_link: /docs/reference/command-line-tools-reference/kube-proxy/
short_description: >
`kube-proxy` is a network proxy that runs on each node in the cluster.
aka:
aka:
tags:
- fundamental
- core-object
- networking
---
`kube-proxy` is a network proxy that runs on each node in the cluster.
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) is a
network proxy that runs on each node in your cluster, implementing part of
the Kubernetes {{< glossary_tooltip term_id="service">}} concept.
It enables the Kubernetes service abstraction by maintaining network rules on
the host and performing connection forwarding.
<!--more-->
<!--more-->
`kube-proxy` is responsible for request forwarding. `kube-proxy` allows TCP and UDP stream forwarding or round robin TCP and UDP forwarding across a set of backend functions.
kube-proxy maintains network rules on nodes. These network rules allow
network communication to your Pods from network sessions inside or outside
of your cluster.
kube-proxy uses the operating system packet filtering layer if there is one
and it's available. Otherwise, kube-proxy forwards the traffic itself.
content/en/docs/reference/glossary/operator-pattern.md
Executable
+24
View File
@@ -0,0 +1,24 @@
---
title: Operator pattern
id: operator-pattern
date: 2019-05-21
full_link: /docs/concepts/extend-kubernetes/operator/
short_description: >
A specialized controller used to manage a custom resource
aka:
tags:
- architecture
---
The [operator pattern](/docs/concepts/extend-kubernetes/operator/) is a system
design that links a {{< glossary_tooltip term_id="controller" >}} to one or more custom
resources.
<!--more-->
You can extend Kubernetes by adding controllers to your cluster, beyond the built-in
controllers that come as part of Kubernetes itself.
If a running application acts as a controller and has API access to carry out tasks
against a custom resource that's defined in the control plane, that's an example of
the Operator pattern.
content/en/docs/reference/kubectl/cheatsheet.md
+2 -3
View File
@@ -1,7 +1,6 @@
---
title: kubectl Cheat Sheet
reviewers:
- bgrant0607
- erictune
- krousey
- clove
@@ -160,7 +159,7 @@ kubectl get services --sort-by=.metadata.name # List Services Sorted by Name
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
# Get the version label of all pods with label app=cassandra
kubectl get pods --selector=app=cassandra rc -o \
kubectl get pods --selector=app=cassandra -o \
jsonpath='{.items[*].metadata.labels.version}'
# Get all worker nodes (use a selector to exclude results that have a label
@@ -349,7 +348,7 @@ Kubectl verbosity is controlled with the `-v` or `--v` flags followed by an inte
Verbosity | Description
--------------| -----------
`--v=0` | Generally useful for this to ALWAYS be visible to an operator.
`--v=0` | Generally useful for this to *always* be visible to a cluster operator.
`--v=1` | A reasonable default log level if you don't want verbosity.
`--v=2` | Useful steady state information about the service and important log messages that may correlate to significant changes in the system. This is the recommended default log level for most systems.
`--v=3` | Extended information about changes.
content/en/docs/reference/kubectl/conventions.md
+14 -11
View File
@@ -1,7 +1,6 @@
---
title: kubectl Usage Conventions
reviewers:
- bgrant0607
- janetkuo
content_template: templates/concept
---
@@ -37,15 +36,19 @@ For `kubectl run` to satisfy infrastructure as code:
You can create the following resources using `kubectl run` with the `--generator` flag:
| Resource | api group | kubectl command |
|---------------------------------|--------------------|---------------------------------------------------|
| Pod | v1 | `kubectl run --generator=run-pod/v1` |
| Replication controller | v1 | `kubectl run --generator=run/v1` |
| Deployment (deprecated) | extensions/v1beta1 | `kubectl run --generator=deployment/v1beta1` |
| Deployment (deprecated) | apps/v1beta1 | `kubectl run --generator=deployment/apps.v1beta1` |
| Job (deprecated) | batch/v1 | `kubectl run --generator=job/v1` |
| CronJob (default) | batch/v1beta1 | `kubectl run --generator=cronjob/v1beta1` |
| CronJob (deprecated) | batch/v2alpha1 | `kubectl run --generator=cronjob/v2alpha1` |
| Resource | api group | kubectl command |
|-------------------------------------|--------------------|---------------------------------------------------|
| Pod | v1 | `kubectl run --generator=run-pod/v1` |
| Replication controller (deprecated) | v1 | `kubectl run --generator=run/v1` |
| Deployment (deprecated) | extensions/v1beta1 | `kubectl run --generator=deployment/v1beta1` |
| Deployment (deprecated) | apps/v1beta1 | `kubectl run --generator=deployment/apps.v1beta1` |
| Job (deprecated) | batch/v1 | `kubectl run --generator=job/v1` |
| CronJob (deprecated) | batch/v1beta1 | `kubectl run --generator=cronjob/v1beta1` |
| CronJob (deprecated) | batch/v2alpha1 | `kubectl run --generator=cronjob/v2alpha1` |
{{< note >}}
`kubectl run --generator` except for `run-pod/v1` is deprecated in v1.12.
{{< /note >}}
If you do not specify a generator flag, other flags prompt you to use a specific generator. The following table lists the flags that force you to use specific generators, depending on the version of the cluster:
@@ -75,4 +78,4 @@ flag, which provides the object to be submitted to the cluster.
* You can use `kubectl apply` to create or update resources. For more information about using kubectl apply to update resources, see [Kubectl Book](https://kubectl.docs.kubernetes.io).
{{% /capture %}}
{{% /capture %}}
content/en/docs/reference/kubectl/docker-cli-to-kubectl.md
-1
View File
@@ -2,7 +2,6 @@
title: kubectl for Docker Users
content_template: templates/concept
reviewers:
- bgrant0607
- brendandburns
- thockin
---
content/en/docs/reference/kubectl/overview.md
-1
View File
@@ -1,6 +1,5 @@
---
reviewers:
- bgrant0607
- hw-qiaolei
title: Overview of kubectl
content_template: templates/concept
content/en/docs/reference/kubernetes-api/index.md
+2 -2
View File
@@ -1,5 +1,5 @@
---
title: v1.14
title: v1.15
---
[Kubernetes API v1.14](/docs/reference/generated/kubernetes-api/v1.14/)
[Kubernetes API v1.15](/docs/reference/generated/kubernetes-api/v1.15/)
content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+2 -48
View File
@@ -206,55 +206,9 @@ point to the CA certificate and key.
### Managing the kubeadm drop-in file for the kubelet {#kubelet-drop-in}
The kubeadm package ships with configuration for how the kubelet should
be run. Note that the `kubeadm` CLI command never touches this drop-in file.
This drop-in file belongs to the kubeadm deb/rpm package.
The `kubeadm` package ships with a configuration file for running the `kubelet` by `systemd`. Note that the kubeadm CLI never touches this drop-in file. This drop-in file is part of the kubeadm DEB/RPM package.
This is what it looks like:
```
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
--kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating
the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably,
#the user should use the .NodeRegistration.KubeletExtraArgs object in the configuration files instead.
# KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
```
Here's a breakdown of what/why:
* `--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf` path to a kubeconfig
file that is used to get client certificates for kubelet during node join.
On success, a kubeconfig file is written to the path specified by `--kubeconfig`.
* `--kubeconfig=/etc/kubernetes/kubelet.conf` points to the kubeconfig file that
tells the kubelet where the API server is. This file also has the kubelet's
credentials.
* `--pod-manifest-path=/etc/kubernetes/manifests` specifies from where to read
static Pod manifests used for starting the control plane.
* `--allow-privileged=true` allows this kubelet to run privileged Pods.
* `--network-plugin=cni` uses CNI networking.
* `--cni-conf-dir=/etc/cni/net.d` specifies where to look for the
[CNI spec file(s)](https://github.com/containernetworking/cni/blob/master/SPEC.md).
* `--cni-bin-dir=/opt/cni/bin` specifies where to look for the actual CNI binaries.
* `--cluster-dns=10.96.0.10` use this cluster-internal DNS server for `nameserver`
entries in Pods' `/etc/resolv.conf`.
* `--cluster-domain=cluster.local` uses this cluster-internal DNS domain for
`search` entries in Pods' `/etc/resolv.conf`.
* `--client-ca-file=/etc/kubernetes/pki/ca.crt` authenticates requests to the Kubelet
API using this CA certificate.
* `--authorization-mode=Webhook` authorizes requests to the Kubelet API by `POST`-ing
a `SubjectAccessReview` to the API server.
* `--rotate-certificates` auto rotate the kubelet client certificates by requesting new
certificates from the `kube-apiserver` when the certificate expiration approaches.
* `--cert-dir`the directory where the TLS certs are located.
For further information, see [Managing the kubeadm drop-in file for systemd](/docs/setup/production-environment/tools/kubeadm/kubelet-integration/#the-kubelet-drop-in-file-for-systemd).
### Use kubeadm with CRI runtimes
content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
+1 -1
View File
@@ -131,7 +131,7 @@ using one of the other modes if possible.
**Example `kubeadm join` command:**
```shell
kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-verification 1.2.3.4:6443`
kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-verification 1.2.3.4:6443
```
**Advantages:**

Some files were not shown because too many files have changed in this diff Show More